spine-o-saurus | i'm getting a 'not valid yet (invalid for another 5h 35min 29s) from apt update? | 06:47 |
---|---|---|
brocashelm | bad cmos battery? or is date and time accurate? | 06:50 |
brocashelm | what repo are you using on your apt's sources.list? | 06:51 |
spine-o-saurus | daedalus | 06:51 |
brocashelm | i meant the whole line you're finding updates for | 06:52 |
brocashelm | such as deb.devuan.org | 06:52 |
brocashelm | have you checked with hwclock or dpkg-reconfigure tzdata? | 06:53 |
brocashelm | ntp helps if you have it | 06:53 |
spine-o-saurus | ya the time is like a few sec's above ntp | 06:57 |
onefang | Or could be you caught a mirror half way through it updating. | 07:05 |
onefang | Also entirely possible the metadata files have a future date in them. I've seen that happen once before. | 07:05 |
spine-o-saurus | deb http://deb.devuan.org/merged daedalus main contrib non-free non-free-firmware | 07:06 |
onefang | Sooooo wait five hours and try again. | 07:06 |
onefang | Ah deb.devuan.org will randomly send you to one of our DNS RR package mirrors. When you have trouble with one of those, it helps us to know which IP you got that time, so we can check that particular mirror. | 07:07 |
spine-o-saurus | devuan.ipacct.com (195.85.215.180) 218.801 ms 220.724 ms 222.730 ms | 07:10 |
* onefang scrounges around for the admin of that mirror. Though it's not part of the deb.devuan.org DNS RR, but is one of our official package mirrors. | 07:22 | |
onefang | You did say you used deb.devuan.org though. | 07:22 |
onefang | https://sledjhamr.org/mantisbt/view.php?id=131 "Release files can be dated in the future?" is the TODO item I have for testing this on our mirrors. As you can see that was 4 years ago, and this is the second time this "not yet valid" issue has come up that I know about. | 07:27 |
onefang | Which is also why it's still "Priority: none". Happened twice in many years. | 07:28 |
onefang | brocashelm was correct the first time, it was badly set time on the users computer last time, so worth checking that first. | 07:30 |
rustyaxe | /usr/bin/libtoolize: 1: /bin/sed: not found | 07:32 |
onefang | Net split while I try to get several people to talk with each other. YAY! NOT! Pfffft | 07:32 |
rustyaxe | did sed move recently? this is like 5th breakage ive had recently | 07:32 |
rustyaxe | /usr/bin/libtoolize: 1: /bin/sed: not founddid sed move recently? this is like 5th breakage ive had recently | 07:33 |
rustyaxe | another was eudev's initscript ;( that sucked | 07:33 |
JackFrost | onefang: I'm done now, you're good. :> | 07:34 |
onefang | Thanks JackFrost. Welcome back the other net splitters. | 07:35 |
onefang | And if any one said anything in the last five minutes, might be worth repeating, now we are all back. | 07:36 |
onefang | Ah spine-o-saurus left just as the net split started. Pity, need more info about their problem to sort it out. Haven't found anything at our ends. | 07:39 |
onefang | Oops, I was wrong before. devuan.ipacct.com is part of the deb.devuan.org DNS Round Robin, I was looking at a different mirror with a very similar name. | 07:47 |
DelTomix | onefang: spine-o-saurus: The time issue happens to me sometimes when booting a system after cloning from different timezone or when hwclock isn't UTC. "apt -o Acquire::Max-FutureTime=28800 update" bypasses it and re-stamps the files, (once the system time is verified to be correct) | 08:11 |
onefang | Alas spine-o-saurus isn't here anymore. | 08:13 |
onefang | That might explain a 5 hour difference that's hard to notice. The time looks correct, but the timezone is different. | 08:14 |
DelTomix | oops sorry - yeah exactly | 08:14 |
rwp | rustyaxe, Are you on Unstable Ceres or Testing Excalibur? /usr/bin/libtoolize probably hard codes the path to sed. sed recently moved from /bin/sed to /usr/bin/sed as part of UsrMerge. There are various workarounds possible. One possible libtoolize workaround is "env SED=sed EGREP=egrep FGREP=fgrep GREP=grep libtoolize". This has always been a bug in libtoolize. | 08:26 |
onefang | Another "work around" is to just accept usrmerge, then it'll work again. | 08:31 |
* onefang runs away before the usrmerge haters jump on me. ;-P | 08:31 | |
brocashelm | they would if there was a #devuan-next | 08:32 |
rwp | onefang keeps saying that we should accept usrmerge and I will accept it if it is offered. So far it has never been offered to me. | 08:46 |
fluffywolf | muwahahahaa!!!! | 15:30 |
joerg | thanks | 15:31 |
spine-o-saurus | how do i get past this compile error, it says:/usr/include/wx-3.2/wx/wx.h:14:10: fatal error: wx/defs.h: No such file or directory #include "wx/defs.h" | 17:56 |
gnarface | spine-o-saurus: looks like you're missing the dev package for wx-windows maybe? | 17:59 |
gnarface | er, wxwidgets or whatever it's called | 17:59 |
gnarface | one of these, probably: apt-cache search ^wxw | 18:00 |
spine-o-saurus | no thats installed | 18:00 |
gnarface | is that file present? | 18:01 |
gnarface | if not, try apt-file search for it | 18:03 |
spine-o-saurus | ya under wx-3.2/wx | 18:03 |
gnarface | hmm, -I/usr/include/wx-3.2? | 18:03 |
spine-o-saurus | i made symlink to that and got past that but now it says wx/setup.h is missing | 18:04 |
gnarface | -I/usr/include/wx-3.2 to the compiler command-line options | 18:05 |
gnarface | ? | 18:05 |
gnarface | can't imagine why else it wouldn't be able to find them... | 18:07 |
gnarface | with sdl you can do something like CFLAGS=`sdl-config --cflags` LIBS=`sdl-config --libs` but i don't know if wxwidgets has anything like that | 18:08 |
spine-o-saurus | hmm i think that prog is busted then | 18:10 |
gnarface | what is it? | 18:15 |
gnarface | maybe it's for an earlier version of wxwidgets? | 18:16 |
spine-o-saurus | oh nm the includes were wrong | 18:27 |
rwp | When I am porting software and find such things it is not unusual to find that it is written for a different system and doesn't work on the Debian side of the family. | 19:05 |
rwp | The first thing I do is try to find if the file exists anywhere. "find /usr/include -name wx.h" for example to see if it is installed but perhaps in a different location. | 19:06 |
rwp | If I believe that it /should/ be installed by some package say foo-dev then I can look in those files "dpkg -L foo-dev | fgrep wx.h" and dpkg -L foo-dev | fgrep wx/wx.h" and so forth. | 19:06 |
rwp | If it isn't found then I know I am missing a required component. But most often I have been able to install the development files but that they are located in a location the source did not expect. In that case I need to adjust the CPPFLAGS most often to look in the current location directories. | 19:07 |
rwp | I have had to hack on the pc-config files sometimes when those are used. Figuring out the file locations is the first step and after that one takes action based upon what is found. | 19:08 |
rwp | Good luck! | 19:08 |
rwp | Just as a sidebar I am often doing "dpkg -L foo | grep bin/" after having installed some random package order to see what executables have been installed. And where. | 19:09 |
rustyaxe | rwp: testing, it broke the eudev initscript too, looks like PATH didnt have /usr/bin or such, i added /usr/bin to the sed calls to get back into GUI ;) | 22:29 |
rwp | rustyaxe, Hard coded paths have hurt me many times over the years. I don't know why people use them so often! | 22:40 |
rwp | If it were me I would sudo edit /usr/bin/libtoolize and remove those hard coded paths from the top of the script. That's only a temporary solution because it will require a fix on the next libtool package upgrade. Which is why I am loath to do it. But it would solve the problem by local fork. | 22:41 |
rwp | It should never have had those full paths in the script. There has never been a need for it. It's just rigid and fragile that way. | 22:42 |
rustyaxe | ya i fixed libtoolize for now, the eudev initscript was more annoying as it broke X ;) | 22:43 |
rwp | More annoying was that the update-mkinitramfs process is also completely broken, "blows chunks" trying to create a new initramfs, fails to boot, fails spectacularly. More hard coded paths problems all around. | 22:52 |
rustyaxe | oof | 23:00 |
* rustyaxe wishes for devuan without the X11 bits | 23:02 | |
rwp | rustyaxe, Don't install the X Window System bits? My headless servers don't have X installed. They are happier that way. Upgrades are more reliable. Smaller. Simpler. | 23:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!