[00:15] unimatrix: packages.ubuntu.com is orphaned [00:18] ari-tczew how so? is there a replacement? [00:18] unimatrix: in http interface? no === dendro-afk is now known as dendrobates === fta_ is now known as fta === dendrobates is now known as dendro-afk === neeraj_ is now known as neeraj === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [03:42] hi guys, anybody running latest maverick, having their network wifi LED flashing on and off like mad? [03:43] i don't know how to explain this in a bug report lol [03:43] wifi is up and running, just the LED keeps flashing like its telling me morse code === dendro-afk is now known as dendrobates [04:01] How often do the moderators for ubuntu-devel-discuss@l.u.c approve messages? === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:28] DktrKranz: are you familiar with yasm? I see you touched the package about 2 yrs ago [07:10] Good mornin [07:11] (no 'g's just yet at this hour, sorry) [07:24] geser: yes [07:25] geser: sfcb depends on cim-schema, which still needs some work on licensing [07:25] geser: so at this point it needs to live in multiverse [07:25] and so do all the things that depend on it [07:29] hey ttx, feeling better? [07:30] pitti: slightly, meds starting to take effect. Thanks :) [07:33] micahg: no [07:49] pitti: do you know about yasm? [08:06] good morning! === lag is now known as tjmjigtx === tjmjigtx is now known as lag [08:26] micahg: I know it exists, not much else [08:26] pitti: k, I'm wondering if I can update the package in Ubuntu since Debian isn't being responsive and we're right before FF [08:26] sure [08:26] pitti: k, thanks [08:28] I think glib2.0 2.25.12-1ubuntu1 is badly broken (at least on i386): bug 614240. [08:28] Launchpad bug 614240 in glib2.0 (Ubuntu) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated" [Undecided,New] https://launchpad.net/bugs/614240 [08:28] If so, this is going to cause major headaches for maverick users tomorrow. :-( [08:29] robert_ancell: ^^^ [08:32] CDs failed to build the same way [08:33] micahg, yes, :( [08:34] occurs on i386, not amd64. Anyone care to test a fix? [08:37] http://cdimage.ubuntu.com/daily-live/20100806/maverick-desktop-amd64.manifest [08:38] MUAHAH! [08:38] no hal any more!! [08:38] \o/ [08:38] pitti, your quest is complete! [08:40] pitti: gz :) [08:42] pitti, do you have i386 hw? [08:43] robert_ancell: I have two amd64 installs [08:43] robert_ancell: but I can test something in a VM [08:44] i. e. boot the alpha-3 i386 VM and update or so [08:45] pitti, actually, the ppa is fast today, it's building there now. thanks [08:48] pitti, build failed, it's pulling in glib to build glib... can you try building lp:~robert-ancell/+junk/glib-i386-fix on i386 and see if there is the error reported in bug 61420 when it builds? [08:48] Launchpad bug 61420 in xorg (Ubuntu) "Xorg.conf AIGLX changes needed for 855GM cards" [Undecided,Invalid] https://launchpad.net/bugs/61420 [08:48] bug 614240 [08:48] Launchpad bug 614240 in glib2.0 (Ubuntu) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated" [Undecided,New] https://launchpad.net/bugs/614240 [08:58] seb128, hey [08:58] hey robert_ancell [08:58] seb128, been breaking stuff, sorry :( [08:58] robert_ancell, you did upload the new glib? [08:59] seb128, yup, wasn't getting any problem here - do you have any i386 hw? [08:59] "i386" in sense of non i686? [09:00] seb128, not sure, definitely broken on i386 [09:00] but yes my box is not amd64 [09:00] robert_ancell, I wrote you an email to tell you to not upload before having it tested by somebody who had the issue :-( [09:01] seb128, sorry, I misread that [09:03] robert_ancell, we missed the :03 run now, I will do a testbuild with -O0 there [09:03] did anybody tried that? [09:03] seb128, ok, thanks. I can't reproduce the problem but I have a possible fix in lp:~robert-ancell/+junk/glib-i386-fix [09:04] robert_ancell, want me to test that first? [09:04] seb128, yes please. Look for a warning after compiling gsignal.c [09:04] robert_ancell, did you try to upload to a ppa? ;-) [09:04] seb128, yes, but it pulled in glib to build glib - how do we get around that? [09:04] did it? [09:05] http://launchpadlibrarian.net/53153005/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz [09:05] bonjour seb128 [09:05] that's going to be fun [09:05] pitti, hey [09:05] pitti, help! [09:07] erm, why does glib b-dep on glib? [09:07] ah [09:07] libdconf2.0? [09:07] pitti, it may be because of the dconf depends [09:07] let's change it back to a recommends [09:07] robert_ancell: so, try the following: [09:08] - upload a glib2.0 without dconf and the fix [09:08] - let it build and publish [09:08] - reupload glib2.0 with dconf [09:08] just change it back to a recommend [09:08] that's a circular depends anyway [09:08] I will add the recommends to gnome-session or something [09:09] recommends sounds good enough as well [09:09] ok, uploading now [09:09] (to ppa) [09:11] * seb128 builds locally [09:11] I hacked the rules to not run make check, that takes hours [09:11] robert_ancell, sorry for not being clear in my email :-( [09:11] seb128, I should have checked the debian reports closer [09:12] did you find it now? [09:12] seb128, yes, afterwards when I knew the compiler error to search for [09:13] robert_ancell, oh, did they reassign it away from glib? [09:13] in any case update building there [09:13] seb128, no, but I didn't realise that bug was the problem we were facing. [09:14] I didn't realize it was not happening on amd64 ;-) [09:14] seb128, the weird thing is the compiler says "this is going to fail for sure" and then lets you keep compiling! [09:15] I've noticed reading your email, I didn't notice the build warning yesterday [09:16] robert_ancell, seems the warning is fixed [09:17] it's building the udeb variant now but I've no "//usr/include/bits/string3.h:86: warning: call to __builtin___memset_chk will always overflow destination buffer" in the log after the shared build [09:17] seb128, good sign... [09:19] oh come on [09:20] building rfgdbg now [09:20] why do need to build glib, gtk etc 3 times [09:21] robert_ancell, btw you should add the dh_installdirs call to the rules while you are at it [09:21] dh_install -i [09:21] + dh_installdirs -i [09:22] and same for the -s [09:22] robert_ancell, and be ready to upload if that build works ;-) [09:22] seb128, prepping now... [09:24] robert_ancell, ok, it's running the dh_ [09:25] hm, what's all this complaining from uscan in maverick? [09:25] dpkg: version ''2.31.6'' has bad syntax: invalid character in version number [09:25] robert_ancell, works! go go go upload it ;-) [09:25] ups [09:25] robert_ancell, wait [09:25] this seems to break bzr bd etc. [09:26] robert_ancell, no, don't [09:26] robert_ancell, any gtk software segfault on g_bsearch_array_lookup_fuzzy() [09:26] seb128, ? [09:26] the install worked [09:26] but gtk-demo or gedit or whatever still segfault [09:27] damn, plan B, can you upload with -O0? [09:27] pitti, should we block the binaries? it makes any gtk software segfault on i386 [09:27] robert_ancell, can try [09:29] seb128: ah, so the fix doesn't work? [09:29] or any workaround? [09:29] seb128: we could just upload the previous glib? [09:29] it'd be better than blocking binaries IMHO [09:30] ok [09:35] ok [09:35] pitti, robert_ancell: I've uploaded an untested version [09:35] building it locally now [09:35] a reversion to the previous glib? [09:36] pitti, no, a build with -O0 which the debian guys says workaround the compiler issue [09:36] pitti, I'm not sure the previous version wouldn't have the same issue [09:36] pitti, we are running into a gcc bug not a glib one [09:36] that code didn't change [09:37] eww [09:42] grrrr [09:43] #0 0x011eb53e in ?? () from /usr/lib/gio/modules/libgvfsdbus.so [09:43] #1 0x00761996 in _g_local_file_info_get [09:43] gtk-demo runs now but not gedit [09:44] seb128, I have to go sorry, can you handle this? [09:45] robert_ancell, yes, enjoy your evening, don't worry we will sort it [09:45] pitti, should we block the binaries or not? [09:45] seb128, thanks, I owe you a pile of beers [09:45] pitti, it makes all the gtk programs crash on i386 [09:45] which basically means no session for anybody upgrading I guess [09:46] and we will not catch a fix in the next publisher run now [09:47] pitti, or wait [09:48] hum no [09:56] pitti, hello? [09:58] seb128: so, your workaround didn't work either? does it work with -O0? [09:59] pitti, my workaround was -O0, that fixes a crash but anything using gvfs crashes still [09:59] I'm trying to rebuild the previous version now [10:04] pitti, bah === yofel_ is now known as yofel [10:04] pitti, does the buildds install recommends? [10:04] they don't, no [10:04] http://launchpadlibrarian.net/53155396/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz [10:05] The following NEW packages will be installed: [10:05] libdconf0 libmpfr4 [10:05] right, I'm wondering what brings libdconf0 in [10:05] I changed it to a recommends [10:06] hm, is that even the build-depends install already? [10:06] it could just be the initial chroot upgrade [10:06] Updating debian chroot for build 7d742a5eeb0eac0743fc0c3c1f21ea01fa1a5850 [10:06] glib is in the buildd chroot [10:06] :-( [10:06] darn [10:08] so, I'm afraid this needs lamont love [10:08] * pitti stops buildds [10:08] well, the i386 ones, anyway [10:08] other arches are not affected? [10:09] seb128, lamont: i386 buildds on manual, to avoid further FTBFSes until the chroot is sorted out === fta_ is now known as fta [10:09] seb128, lamont, elmo: I think what needs to happen is a manual chroot upgrade with ignoring the segfault in libglib2.0-0's postinst [10:10] and then build/publish a glib without the libdconf dependency [10:10] then the chroot should at least be able to upgrade itself again [10:10] pitti, well, I'm not so concerned about the buildds that about the fact that every i386 downloading that upgrade will get a non starting system [10:10] or rather graphical system === hunger_ is now known as hunger [10:12] seb128: good to know that I don't do a restart :D [10:12] sebner, well you shouldn't be able to start any gtk application either [10:12] seb128: so, you want the i386 .debs blocked? you need to ask #is about that, I'm afraid, I can't do that [10:13] pitti, well either we need to solve that quickly or we need to block the debs [10:13] pitti, what do you think? [10:13] seb128: uh great, good that I opened my browser and xchat already before the upgrade xD [10:14] seb128: blocking debs would probably be prudent, since we need to fix the chroots either way, and it's a couple of hours until lamont wakes up [10:14] ok [10:15] seb128: but I guess a simple glib downgrade fixes it? [10:15] * sebner waves at pitti btw :) [10:15] yes [10:15] hello seb128 [10:15] sebner, even [10:16] Where can I find some documentation on writing a Ubiquity plugin? I need to add some extra pages to Ubiquity for some Ubuntu-based boxes that we are making at the university. [10:17] I am currently reading through the sources of the existing plugins ... [10:18] * Adri2000 needs a core-dev to approve lucid task in bug #569365, please [10:18] Launchpad bug 569365 in mountall (Ubuntu) "mountall messages are showed untranslated in Plymouth" [Medium,In progress] https://launchpad.net/bugs/569365 === fta_ is now known as fta [10:27] seb128: worth a try: does it work with gcc-4.5? [10:28] pitti, how do I try that easily? [10:29] configuring with CC=gcc-4.5 should do it [10:29] and b-dep'ing on gcc-4.5 [10:29] it's in main [10:29] let me try [10:29] seb128: i. e. in configure-stamp rule, where CFLAGS= is set [10:29] (untested) [10:30] I'm finishing my 2.25.12.is.2.25.11 build and then test that [10:39] pitti, my 2.25.12.is.2.25.11 works === fta_ is now known as fta [10:39] nice [10:39] pitti, so at least we have something we can upload one the buildds are sorted [10:39] trying gcc-4.5 now [10:39] seb128: so it's not quite clear then whether it's a glib or a gcc bug? [10:41] pitti, other distros don't have the issue with that glib and the debian guys who investigated says it's a compiler issue [10:41] pitti, I'm trying gcc-4.5 next === amitk is now known as amitk-afk === lifeless_ is now known as lifeless [11:39] pitti: what's up? === cking-afk is now known as cking1 [11:41] lamont, hey! need help fixing the buildds [11:41] lamont, we got a libglib uploaded which segfaults on i386 [11:41] oh joy [11:41] seb128, lamont its also affecting the PPA builders [11:41] lamont, and we can't get a new version fixed because the buildds dist-upgrade pre-build fails on it [11:43] pitti, should we disable the PPA i386 buildd's too as they are pinging jobs to CHROOTWAIT [11:44] apw: manualing them now, but I'm pretty sure that's not what pinging means [11:44] lamping them to CHROOTWAIT perhaps :) [11:44] seb128: confirmed that armel and powerpc are affected too [11:45] seb128: given that sparc also succeeded, looks like a 32 bit only issue? [11:45] all stop! [11:45] glib doing something nasty to pointers? [11:45] MANUALing powerpc and armel [11:46] pitti, should I upload my downgraded version for now? [11:46] seb128: if that works, please do [11:46] done [11:46] seb128: then it'll be ready to try when the builders are working again [11:46] I'm away for a quick bite, will be back in 10 minutes or so [11:50] pitti: so we need all 32-bit maverick architectures? [11:50] lamont: seems so; i386, armel, powerpc AFAICS? [11:51] joy [11:51] lamont: what would you recommend here? manually upgrading the chroot and || true'ing the postinst of libglib? [11:51] lamont: or temporarily disabling dist-upgrade? [11:51] it fails during dist-upgrade of the chroot, before starting the actual build, AFAICS [11:51] pitti: I just rolled a fresh i386 chroot, and helped libglib2.0-0 to land well [11:52] lamont: ok; disabling dist-upgrade is harder to do/not advisable? === fta_ is now known as fta [11:52] produces a less reproducible result [11:53] lamont: just saying that with that hacked chroot this probably needs another update once glib is fixed? [11:54] once glib is newer, the dist-upgrade will take care of it each time [11:55] glib isn't a quick build. do we need the old glib to build the new glib, or is the gio-modules segv isolated? [11:56] lamont: it's not quite clear yet whether it's a gcc bug or a bug in the newer glib, but so far we don't have any other solution than to downgrade glib [11:56] lamont: we don't need the old glib for build, it was a circular dependency (now fixed) [11:57] ah, ok. [11:58] so I'm hearing that we want to disable the upgrade on 32-bit, upload the old glib as a higher version, let it publish, and then re-enable the dist-upgrade, yes? [11:59] lamont: sounds good [11:59] lamont: well, I don't insist on disabling the upgrade; I was just asking whether it might be easier for you [12:00] it might be a central change, as opposed to having to fiddle with N chroots twice [12:00] given the borked nature of the new build, and your promise not to reenable everything until I turn it back on, I'm happy [12:00] it's not a central change [12:00] ok; so whatever is easiest and works :) [12:00] i think if lamont wanted it to be simple we already would have a webUI to patch chroot etc. :-P [12:00] lamont: the new build is broken? [12:01] j/k [12:01] lamont: (sorry, I didn't actually follow the changes in glib; this time I was by and large a bystander) === fta_ is now known as fta [12:01] pitti: borked nature of a fresh chroot <-- forget what I said about "new build" [12:01] ah [12:04] pitti: use the following machines to build glib: palmer, ross, artigas, hawthorn [12:04] lamont: understood; I'll bump its build score to make sure it goes first [12:05] lamont, pitti: thanks! [12:05] thanks all for fixing this [12:05] once it's done and published, you can unmanual everything EXCEPT those 4. poke me to go undo the hack, pls [12:05] lamont: ack [12:05] https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.12.is.2.25.11-0ubuntu1 [12:05] hmm [12:05] lamont: just to make sure everythign is as expected, did we drop sparc and ia64 arches from maverick now? [12:06] final decision is slated for next week, iirc [12:06] because above build doesn't have build records for those [12:06] sorry, ia64 is there, but no sparc [12:07] cjwatson: Ciemon has been testing Maverick, and he encountered a bug which i haven't been able to reproduce yet. He's found that grub->recovery mode can give him a root console. Is there something that has changed in the last few days that could have caused that? [12:07] pitti: I wonder if it's still PaS on sparc [12:07] * lamont looks [12:08] glib? that'd ruin pretty much everything [12:08] given that upstart needs it [12:08] %glib2.0: !sparc # temporary workaround for buildd-killer [12:08] I win [12:08] pitti: sparc was dead in lucid [12:09] lack of a kernel and all that [12:09] * pitti sets artigas and sejong (sparcs) to manual [12:09] why? [12:09] ah, sorry, sparc is not affected [12:09] lamont: you said to use artigas for the glib build [12:10] no, sparc _is_ affectd [12:10] sorry, had a phone call in parallel (done now) [12:10] lamont: in general we still get sparc build records for maverick, so better to stop it [12:10] sparc has 2.24.0-0ubuntu4 [12:10] ah, so it's not affected because the broken glib failed? [12:11] indeed, https://edge.launchpad.net/ubuntu/+source/gnome-session/2.31.6-0ubuntu1 succeeded on sparc [12:11] (from ~ 1.5 hours ago) [12:11] sparc doesn't believe in glib of the current era [12:11] ok, sparc back on auto [12:11] lamont: so should I just ignore your "plz use those" for artigas then? [12:11] and you can undo the hack there? [12:11] hack gone on artigas, ignore artigas [12:12] * pitti puts the other three back on auto, and puts a sweet cherry on top of the glib build to lure them into grabbing the builds faster [12:13] pitti: on that, do you need anything more from me until glib is building? (I can actually remove the hack once the build is into installing build-deps) [12:13] there, they took the bait; I set them back to manual === MacSlow is now known as MacSlow|lunch [12:14] lamont: assuming that these builds will actually succeed, should be enough [12:14] cool [12:14] lamont: would it be okay to revert the hack in an hour or so? just in case.. [12:14] sure [12:14] we don't have a desperatingly long queue [12:14] so the outage of those three shoudln't hurt [12:15] seb128: ok, I'd like to grab some lunch, and those builds will take a bit anyway; do you need anything else right now? [12:16] pitti, no, thanks for helping there, I will email ubuntu-devel now [12:20] seb128: it's past the build-dep isntall stage on all three, anyway, so seems lamont's hack worked :) [12:20] * pitti & === didrocks1 is now known as didrocks [12:38] pitti, lamont: new glib failed to upload [12:38] "2010-08-06 11:35:00 WARNING Upload was rejected: [12:38] 2010-08-06 11:35:00 WARNING invalid literal for int() with base 10: '24\t.'" [12:38] wth? [12:38] http://launchpadlibrarian.net/53161958/upload_1907875_log.txt [12:38] "2010-08-06 11:34:50 ERROR Exception while accepting: [12:38] invalid literal for int() with base 10: '24\t.' [12:38] -> http://launchpadlibrarian.net/53161956/hMxV26MZk2BTThKsEzJvkTYKbvL.txt (invalid literal for int() with base 10: '24\t.') [12:38] " [12:45] seb128: That looks like the pkgstriptranslations issue from a few weeks ago. [12:45] (yes, the error message sucks) [12:46] lamont, did your changes brought back pkgstriptranslations to an old version or something? [12:46] seb128: pitti fixed that already in the past [12:46] seb128: that tarball was last upgraded some time ago [12:46] I didn't know that any chroots existed with the bad version held, though... [12:46] so you're saying you want pkgstriptranslations? any other packages vs weeks ago? [12:46] wgrant, lamont has been tweaking things to fix the glib screwup [12:46] wgrant: not held, we just completely skipped the dist-upgrade step [12:47] Hmm. I wonder why the chroots would have that version, though. [12:47] How odd. [12:47] what was the buggy version? [12:48] I forget... the one where it was uploaded like 5 times in one day. [12:48] * wgrant checks. [12:48] That bug was fixed in 73. [12:48] wgrant: they have the july 14 binaries [12:48] ish === fta_ is now known as fta [12:48] (all of the tarballs) [12:49] lamont: Hm, you recreated them during the brokenness? :/ [12:49] lamont, can you check the version on the builders? [12:49] then the dist-upgrade step brings them current [12:49] wgrant: I just looked at the timestamp on the tarball [12:49] Also, wouldn't this have been several hours easier if the old glib binaries were revived? [12:51] wgrant: yes and no [12:52] ii pkgbinarymangler 70 strips translations and alters maintainers d [12:53] lamont, can we update that and retry build? [12:53] lamont: I mean, surely it'd be nice to fix archive breakage quickly without screwing with chroots.... [13:01] argh [13:01] old ghosts come back then!? [13:01] seb128: and crunching along nicely now [13:01] pitti: you said no dist-upgrade... so you get july 14 bits [13:01] that was my point [13:01] lamont, thanks [13:02] seb128: it'd be nice if once we get this published, you did a fresh upload of the old bits one more time [13:02] lamont, you want another glib source upload? [13:02] lamont: right, but I didn't think of the possibility that of all possible times we'd catch the two hours with broken mangler :-( sorry about that [13:03] pitti: in other news, my plan (as of last night) was to build new chroots first thing this morning. [13:03] there's some irony or such in there somewhere [13:03] So, seriously, wouldn't stuff like this be easier if you could remove the broken binaries and bring back the old ones into the archive? That's quite doable. [13:03] wgrant: with a higher than broken version number? [13:03] lamont: Not critical if the chroots are old. [13:03] lamont: nice timing for the win! [13:03] except for the user [13:04] lamont, you need a source upload? when? [13:04] someone retried the glib i386 build then? [13:04] "started 5 mins ago" [13:04] lamont: Well, the intention would be to get builds unbroken, then get a newer version out to users once the world is fixed. [13:04] seb128: once the current one is published - I'll let pitti decide if he wants that to build (using current build-deps) before autoing the world, or if he's ok with the july 14 build-deps and letting it happen when it does [13:04] pitti: I did [13:04] with current pkgbinarymangler [13:05] why do you need a new source upload? === amitk-afk is now known as amitk [13:05] if you retried the current one [13:05] seb128: totally separate issue [13:05] seb128: the current build is bad, since it builds with an old toolchain, etc. [13:05] seb128: I'd like glib to be built with current build-deps, instead of 3-week old build-deps [13:05] ok, fair enough [13:05] s/build-deps/maverick/ [13:05] I'm still aiming at trying to fix 2.25.12 if I can [13:06] seb128: that'd be even better, of course :) [13:06] seb128: it's an exercise in git bisect, by and large? [13:06] if you give me a window where the world is happy, I'll freshen the chroots this morning [13:06] pitti, I'm not sure, 2.25.12 built from tarball doesn't crash [13:07] but I'm only LD_LIBRARY_PATH loading the libraries [13:08] seb128: do you get a crash if you have the working glib installed, and LD_LIB_PATH'ing the one from the known-broken glib .deb? [13:08] seb128: if that doesn't crash either, then apparently L_L_P doesn't work (enough); if it doesn't crash, then it might be a patch of our's? [13:13] pitti, yes [13:13] it crashes this way === amitk is now known as amitk-afk [13:16] seb128: ok, so LD_L_P is working to reproduce the crash, and it's something that we patched in our package? [13:16] seb128: i. e. I assume "build from tarball" means "from upstream"? [13:17] pitti, it means tar xzf orig.tar.gz; cd glib; ./configure --prefix=/usr && make [13:17] *nod* [13:18] pitti, I'm doing a deb build without distro changes now [13:19] seb128: my first suspect would be 71_gio_launch_handler.patch [13:19] it's not [13:19] debian doesn't have this change [13:19] ok; well, then good hunting! [13:19] I'm wondering if that could be due to the rules [13:19] LDFLAGS += -Wl,-O1 [13:20] for example [13:20] pitti, thanks ;-) [13:20] pitti, thank you for trying to give me hints as well ;-) [13:23] i386 finished [13:23] seb128: would you mind testing the binaries from https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.12.is.2.25.11-0ubuntu1/+build/1907344 ? [13:23] seb128: they were built with an older toolchain, so we can't assume that they work now (i. e. as in your local build) [13:25] pitti, trying [13:27] pitti, [13:27] pitti, works [13:28] \o/ [13:28] lamont: so, you can un-hack palmer/ross/hawthorn [13:30] pitti: all unhax0red. [13:30] pitti: ok if I leave the unmanual to you? if it's published, I'll go do it now if you want [13:30] lamont: yes, that's fine [13:31] I'll reanimate them [13:31]