[00:15] <ari-tczew> unimatrix: packages.ubuntu.com is orphaned
[00:18] <unimatrix> ari-tczew how so? is there a replacement?
[00:18] <ari-tczew> unimatrix: in http interface? no
[03:42] <jturek> hi guys, anybody running latest maverick, having their network wifi LED flashing on and off like mad?
[03:43] <jturek> i don't know how to explain this in a bug report lol
[03:43] <jturek> wifi is up and running, just the LED keeps flashing like its telling me morse code
[04:01] <ansgar> How often do the moderators for ubuntu-devel-discuss@l.u.c approve messages?
[06:28] <micahg> DktrKranz: are you familiar with yasm?  I see you touched the package about 2 yrs ago
[07:10] <pitti> Good mornin
[07:11] <pitti> (no 'g's just yet at this hour, sorry)
[07:24] <ttx> geser: yes
[07:25] <ttx> geser: sfcb depends on cim-schema, which still needs some work on licensing
[07:25] <ttx> geser: so at this point it needs to live in multiverse
[07:25] <ttx> and so do all the things that depend on it
[07:29] <pitti> hey ttx, feeling better?
[07:30] <ttx> pitti: slightly, meds starting to take effect. Thanks :)
[07:33] <DktrKranz> micahg: no
[07:49] <micahg> pitti: do you know about yasm?
[08:06] <dholbach> good morning!
[08:26] <pitti> micahg: I know it exists, not much else
[08:26] <micahg> 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] <pitti> sure
[08:26] <micahg> pitti: k, thanks
[08:28] <andersk> I think glib2.0 2.25.12-1ubuntu1 is badly broken (at least on i386): bug 614240.
[08:28] <andersk> If so, this is going to cause major headaches for maverick users tomorrow.  :-(
[08:29] <micahg> robert_ancell: ^^^
[08:32] <pitti> CDs failed to build the same way
[08:33] <robert_ancell> micahg, yes, :(
[08:34] <robert_ancell> occurs on i386, not amd64.  Anyone care to test a fix?
[08:37] <pitti> http://cdimage.ubuntu.com/daily-live/20100806/maverick-desktop-amd64.manifest
[08:38] <pitti> MUAHAH!
[08:38] <pitti> no hal any more!!
[08:38] <pitti> \o/
[08:38] <robert_ancell> pitti, your quest is complete!
[08:40] <Chipzz> pitti: gz :)
[08:42] <robert_ancell> pitti, do you have i386 hw?
[08:43] <pitti> robert_ancell: I have two amd64 installs
[08:43] <pitti> robert_ancell: but I can test something in a VM
[08:44] <pitti> i. e. boot the alpha-3 i386 VM and update or so
[08:45] <robert_ancell> pitti, actually, the ppa is fast today, it's building there now.  thanks
[08:48] <robert_ancell> 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] <robert_ancell> bug 614240
[08:58] <robert_ancell> seb128, hey
[08:58] <seb128> hey robert_ancell
[08:58] <robert_ancell> seb128, been breaking stuff, sorry :(
[08:58] <seb128> robert_ancell, you did upload the new glib?
[08:59] <robert_ancell> seb128, yup, wasn't getting any problem here - do you have any i386 hw?
[08:59] <seb128> "i386" in sense of non i686?
[09:00] <robert_ancell> seb128, not sure, definitely broken on i386
[09:00] <seb128> but yes my box is not amd64
[09:00] <seb128> 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] <robert_ancell> seb128, sorry, I misread that
[09:03] <seb128> robert_ancell, we missed the :03 run now, I will do a testbuild with -O0 there
[09:03] <seb128> did anybody tried that?
[09:03] <robert_ancell> 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] <seb128> robert_ancell, want me to test that first?
[09:04] <robert_ancell> seb128, yes please.  Look for a warning after compiling gsignal.c
[09:04] <seb128> robert_ancell, did you try to upload to a ppa? ;-)
[09:04] <robert_ancell> seb128, yes, but it pulled in glib to build glib - how do we get around that?
[09:04] <seb128> did it?
[09:05] <robert_ancell> http://launchpadlibrarian.net/53153005/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz
[09:05] <pitti> bonjour seb128
[09:05] <seb128> that's going to be fun
[09:05] <seb128> pitti, hey
[09:05] <seb128> pitti, help!
[09:07] <pitti> erm, why does glib b-dep on glib?
[09:07] <pitti> ah
[09:07] <pitti> libdconf2.0?
[09:07] <robert_ancell> pitti, it may be because of the dconf depends
[09:07] <seb128> let's change it back to a recommends
[09:07] <pitti> robert_ancell: so, try the following:
[09:08] <pitti> - upload a glib2.0 without dconf and the fix
[09:08] <pitti> - let it build and publish
[09:08] <pitti> - reupload glib2.0 with dconf
[09:08] <seb128> just change it back to a recommend
[09:08] <seb128> that's a circular depends anyway
[09:08] <seb128> I will add the recommends to gnome-session or something
[09:09] <pitti> recommends sounds good enough as well
[09:09] <robert_ancell> ok, uploading now
[09:09] <robert_ancell> (to ppa)
[09:11]  * seb128 builds locally
[09:11] <seb128> I hacked the rules to not run make check, that takes hours
[09:11] <seb128> robert_ancell, sorry for not being clear in my email :-(
[09:11] <robert_ancell> seb128, I should have checked the debian reports closer
[09:12] <seb128> did you find it now?
[09:12] <robert_ancell> seb128, yes, afterwards when I knew the compiler error to search for
[09:13] <seb128> robert_ancell, oh, did they reassign it away from glib?
[09:13] <seb128> in any case update building there
[09:13] <robert_ancell> seb128, no, but I didn't realise that bug was the problem we were facing.
[09:14] <seb128> I didn't realize it was not happening on amd64 ;-)
[09:14] <robert_ancell> seb128, the weird thing is the compiler says "this is going to fail for sure" and then lets you keep compiling!
[09:15] <seb128> I've noticed reading your email, I didn't notice the build warning yesterday
[09:16] <seb128> robert_ancell, seems the warning is fixed
[09:17] <seb128> 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] <robert_ancell> seb128, good sign...
[09:19] <seb128> oh come on
[09:20] <seb128> building rfgdbg now
[09:20] <seb128> why do need to build glib, gtk etc 3 times
[09:21] <seb128> robert_ancell, btw you should add the dh_installdirs call to the rules while you are at it
[09:21] <seb128>  	dh_install -i
[09:21] <seb128> +	dh_installdirs -i
[09:22] <seb128> and same for the -s
[09:22] <seb128> robert_ancell, and be ready to upload if that build works ;-)
[09:22] <robert_ancell> seb128, prepping now...
[09:24] <seb128> robert_ancell, ok, it's running the dh_
[09:25] <pitti> hm, what's all this complaining from uscan in maverick?
[09:25] <pitti> dpkg: version ''2.31.6'' has bad syntax: invalid character in version number
[09:25] <seb128> robert_ancell, works! go go go upload it ;-)
[09:25] <seb128> ups
[09:25] <seb128> robert_ancell, wait
[09:25] <pitti> this seems to break bzr bd etc.
[09:26] <seb128> robert_ancell, no, don't
[09:26] <seb128> robert_ancell, any gtk software segfault on g_bsearch_array_lookup_fuzzy()
[09:26] <robert_ancell> seb128, ?
[09:26] <seb128> the install worked
[09:26] <seb128> but gtk-demo or gedit or whatever still segfault
[09:27] <robert_ancell> damn, plan B, can you upload with -O0?
[09:27] <seb128> pitti, should we block the binaries? it makes any gtk software segfault on i386
[09:27] <seb128> robert_ancell, can try
[09:29] <pitti> seb128: ah, so the fix doesn't work?
[09:29] <pitti> or any workaround?
[09:29] <pitti> seb128: we could just upload the previous glib?
[09:29] <pitti> it'd be better than blocking binaries IMHO
[09:30] <seb128> ok
[09:35] <seb128> ok
[09:35] <seb128> pitti, robert_ancell: I've uploaded an untested version
[09:35] <seb128> building it locally now
[09:35] <pitti> a reversion to the previous glib?
[09:36] <seb128> pitti, no, a build with -O0 which the debian guys says workaround the compiler issue
[09:36] <seb128> pitti, I'm not sure the previous version wouldn't have the same issue
[09:36] <seb128> pitti, we are running into a gcc bug not a glib one
[09:36] <seb128> that code didn't change
[09:37] <pitti> eww
[09:42] <seb128> grrrr
[09:43] <seb128> #0  0x011eb53e in ?? () from /usr/lib/gio/modules/libgvfsdbus.so
[09:43] <seb128> #1  0x00761996 in _g_local_file_info_get
[09:43] <seb128> gtk-demo runs now but not gedit
[09:44] <robert_ancell> seb128, I have to go sorry, can you handle this?
[09:45] <seb128> robert_ancell, yes, enjoy your evening, don't worry we will sort it
[09:45] <seb128> pitti, should we block the binaries or not?
[09:45] <robert_ancell> seb128, thanks, I owe you a pile of beers
[09:45] <seb128> pitti, it makes all the gtk programs crash on i386
[09:45] <seb128> which basically means no session for anybody upgrading I guess
[09:46] <seb128> and we will not catch a fix in the next publisher run now
[09:47] <seb128> pitti, or wait
[09:48] <seb128> hum no
[09:56] <seb128> pitti, hello?
[09:58] <pitti> seb128: so, your workaround didn't work either? does it work with -O0?
[09:59] <seb128> pitti, my workaround was -O0, that fixes a crash but anything using gvfs crashes still
[09:59] <seb128> I'm trying to rebuild the previous version now
[10:04] <seb128> pitti, bah
[10:04] <seb128> pitti, does the buildds install recommends?
[10:04] <pitti> they don't, no
[10:04] <seb128> http://launchpadlibrarian.net/53155396/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz
[10:05] <pitti> The following NEW packages will be installed:
[10:05] <pitti>   libdconf0 libmpfr4
[10:05] <seb128> right, I'm wondering what brings libdconf0 in
[10:05] <seb128> I changed it to a recommends
[10:06] <pitti> hm, is that even the build-depends install already?
[10:06] <pitti> it could just be the initial chroot upgrade
[10:06] <pitti> Updating debian chroot for build 7d742a5eeb0eac0743fc0c3c1f21ea01fa1a5850
[10:06] <pitti> glib is in the buildd chroot
[10:06] <seb128> :-(
[10:06] <pitti> darn
[10:08] <pitti> so, I'm afraid this needs lamont love
[10:08]  * pitti stops buildds
[10:08] <pitti> well, the i386 ones, anyway
[10:08] <pitti> other arches are not affected?
[10:09] <pitti> seb128, lamont: i386 buildds on manual, to avoid further FTBFSes until the chroot is sorted out
[10:09] <pitti> 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] <pitti> and then build/publish a glib without the libdconf dependency
[10:10] <pitti> then the chroot should at least be able to upgrade itself again
[10:10] <seb128> 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] <seb128> or rather graphical system
[10:12] <sebner> seb128: good to know that I don't do a restart :D
[10:12] <seb128> sebner, well you shouldn't be able to start any gtk application either
[10:12] <pitti> 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] <seb128> pitti, well either we need to solve that quickly or we need to block the debs
[10:13] <seb128> pitti, what do you think?
[10:13] <sebner> seb128: uh great, good that I opened my browser and xchat already before the upgrade xD
[10:14] <pitti> 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] <seb128> ok
[10:15] <sebner> seb128: but I guess a simple glib downgrade fixes it?
[10:15]  * sebner waves at pitti btw :)
[10:15] <seb128> yes
[10:15] <pitti> hello seb128
[10:15] <pitti> sebner, even
[10:16] <debarshi> 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] <debarshi> 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:27] <pitti> seb128: worth a try: does it work with gcc-4.5?
[10:28] <seb128> pitti, how do I try that easily?
[10:29] <pitti> configuring with CC=gcc-4.5 should do it
[10:29] <pitti> and b-dep'ing on gcc-4.5
[10:29] <pitti> it's in main
[10:29] <seb128> let me try
[10:29] <pitti> seb128: i. e. in configure-stamp rule, where CFLAGS= is set
[10:29] <pitti> (untested)
[10:30] <seb128> I'm finishing my 2.25.12.is.2.25.11 build and then test that
[10:39] <seb128> pitti, my 2.25.12.is.2.25.11 works
[10:39] <pitti> nice
[10:39] <seb128> pitti, so at least we have something we can upload one the buildds are sorted
[10:39] <seb128> trying gcc-4.5 now
[10:39] <pitti> seb128: so it's not quite clear then whether it's a glib or a gcc bug?
[10:41] <seb128> 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] <seb128> pitti, I'm trying gcc-4.5 next
[11:39] <lamont> pitti: what's up?
[11:41] <seb128> lamont, hey! need help fixing the buildds
[11:41] <seb128> lamont, we got a libglib uploaded which segfaults on i386
[11:41] <lamont> oh joy
[11:41] <apw> seb128, lamont its also affecting the PPA builders
[11:41] <seb128> lamont, and we can't get a new version fixed because the buildds dist-upgrade pre-build fails on it
[11:43] <apw> pitti, should we disable the PPA i386 buildd's too as they are pinging jobs to CHROOTWAIT
[11:44] <lamont> apw: manualing them now, but I'm pretty sure that's not what pinging means
[11:44] <apw> lamping them to CHROOTWAIT perhaps :)
[11:44] <pitti> seb128: confirmed that armel and powerpc are affected too
[11:45] <pitti> seb128: given that sparc also succeeded, looks like a 32 bit only issue?
[11:45] <asac> all stop!
[11:45] <pitti> glib doing something nasty to pointers?
[11:45] <pitti> MANUALing powerpc and armel
[11:46] <seb128> pitti, should I upload my downgraded version for now?
[11:46] <pitti> seb128: if that works, please do
[11:46] <seb128> done
[11:46] <pitti> seb128: then it'll be ready to try when the builders are working again
[11:46] <seb128> I'm away for a quick bite, will be back in 10 minutes or so
[11:50] <lamont> pitti: so we need all 32-bit maverick architectures?
[11:50] <pitti> lamont: seems so; i386, armel, powerpc AFAICS?
[11:51] <lamont> joy
[11:51] <pitti> lamont: what would you recommend here? manually upgrading the chroot and || true'ing the postinst of libglib?
[11:51] <pitti> lamont: or temporarily disabling dist-upgrade?
[11:51] <pitti> it fails during dist-upgrade of the chroot, before starting the actual build, AFAICS
[11:51] <lamont> pitti: I just rolled a fresh i386 chroot, and helped libglib2.0-0 to land well
[11:52] <pitti> lamont: ok; disabling dist-upgrade is harder to do/not advisable?
[11:52] <lamont> produces a less reproducible result
[11:53] <pitti> lamont: just saying that with that hacked chroot this probably needs another update once glib is fixed?
[11:54] <lamont> once glib is newer, the dist-upgrade will take care of it each time
[11:55] <lamont> 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] <pitti> 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] <pitti> lamont: we don't need the old glib for build, it was a circular dependency (now fixed)
[11:57] <lamont> ah, ok.
[11:58] <lamont> 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] <pitti> lamont: sounds good
[11:59] <pitti> lamont: well, I don't insist on disabling the upgrade; I was just asking whether it might be easier for you
[12:00] <pitti> it might be a central change, as opposed to having to fiddle with N chroots twice
[12:00] <lamont> 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] <lamont> it's not a central change
[12:00] <pitti> ok; so whatever is easiest and works :)
[12:00] <asac> i think if lamont wanted it to be simple we already would have a webUI to patch chroot etc. :-P
[12:00] <pitti> lamont: the new build is broken?
[12:01] <asac> j/k
[12:01] <pitti> lamont: (sorry, I didn't actually follow the changes in glib; this time I was by and large a bystander)
[12:01] <lamont> pitti: borked nature of a fresh chroot <-- forget what I said about "new build"
[12:01] <pitti> ah
[12:04] <lamont> pitti: use the following machines to build glib:  palmer, ross, artigas, hawthorn
[12:04] <pitti> lamont: understood; I'll bump its build score to make sure it goes first
[12:05] <seb128> lamont, pitti: thanks!
[12:05] <asac> thanks all for fixing this
[12:05] <lamont> once it's done and published, you can unmanual everything EXCEPT those 4.  poke me to go undo the hack, pls
[12:05] <pitti> lamont: ack
[12:05] <pitti> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.12.is.2.25.11-0ubuntu1
[12:05] <pitti> hmm
[12:05] <pitti> lamont: just to make sure everythign is as expected, did we drop sparc and ia64 arches from maverick now?
[12:06] <lamont> final decision is slated for next week, iirc
[12:06] <pitti> because above build doesn't have build records for those
[12:06] <pitti> sorry, ia64 is there, but no sparc
[12:07] <Daviey> 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] <lamont> pitti: I wonder if it's still PaS on sparc
[12:07]  * lamont looks
[12:08] <pitti> glib? that'd ruin pretty much everything
[12:08] <pitti> given that upstart needs it
[12:08] <lamont> %glib2.0: !sparc                                                     # temporary workaround for buildd-killer
[12:08] <lamont> I win
[12:08] <lamont> pitti: sparc was dead in lucid
[12:09] <lamont> lack of a kernel and all that
[12:09]  * pitti sets artigas and sejong (sparcs) to manual
[12:09] <lamont> why?
[12:09] <pitti> ah, sorry, sparc is not affected
[12:09] <pitti> lamont: you said to use artigas for the glib build
[12:10] <pitti> no, sparc _is_ affectd
[12:10] <pitti> sorry, had a phone call in parallel (done now)
[12:10] <pitti> lamont: in general we still get sparc build records for maverick, so better to stop it
[12:10] <lamont> sparc has 2.24.0-0ubuntu4
[12:10] <pitti> ah, so it's not affected because the broken glib failed?
[12:11] <pitti> indeed, https://edge.launchpad.net/ubuntu/+source/gnome-session/2.31.6-0ubuntu1 succeeded on sparc
[12:11] <pitti> (from ~ 1.5 hours ago)
[12:11] <lamont> sparc doesn't believe in glib of the current era
[12:11] <pitti> ok, sparc back on auto
[12:11] <pitti> lamont: so should I just ignore your "plz use those" for artigas then?
[12:11] <pitti> and you can undo the hack there?
[12:11] <lamont> 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] <lamont> 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] <pitti> there, they took the bait; I set them back to manual
[12:14] <pitti> lamont: assuming that these builds will actually succeed, should be enough
[12:14] <lamont> cool
[12:14] <pitti> lamont: would it be okay to revert the hack in an hour or so? just in case..
[12:14] <lamont> sure
[12:14] <pitti> we don't have a desperatingly long queue
[12:14] <pitti> so the outage of those three shoudln't hurt
[12:15] <pitti> 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] <seb128> pitti, no, thanks for helping there, I will email ubuntu-devel now
[12:20] <pitti> seb128: it's past the build-dep isntall stage on all three, anyway, so seems lamont's hack worked :)
[12:20]  * pitti &
[12:38] <seb128> pitti, lamont: new glib failed to upload
[12:38] <seb128> "2010-08-06 11:35:00 WARNING Upload was rejected:
[12:38] <seb128> 2010-08-06 11:35:00 WARNING     invalid literal for int() with base 10: '24\t.'"
[12:38] <seb128> wth?
[12:38] <seb128> http://launchpadlibrarian.net/53161958/upload_1907875_log.txt
[12:38] <seb128> "2010-08-06 11:34:50 ERROR   Exception while accepting:
[12:38] <seb128>  invalid literal for int() with base 10: '24\t.'
[12:38] <seb128>  -> http://launchpadlibrarian.net/53161956/hMxV26MZk2BTThKsEzJvkTYKbvL.txt (invalid literal for int() with base 10: '24\t.')
[12:38] <seb128> "
[12:45] <wgrant> seb128: That looks like the pkgstriptranslations issue from a few weeks ago.
[12:45] <wgrant> (yes, the error message sucks)
[12:46] <seb128> lamont, did your changes brought back pkgstriptranslations to an old version or something?
[12:46] <geser> seb128: pitti fixed that already in the past
[12:46] <lamont> seb128: that tarball was last upgraded some time ago
[12:46] <wgrant> I didn't know that any chroots existed with the bad version held, though...
[12:46] <lamont> so you're saying you want pkgstriptranslations?  any other packages vs weeks ago?
[12:46] <seb128> wgrant, lamont has been tweaking things to fix the glib screwup
[12:46] <lamont> wgrant: not held, we just completely skipped the dist-upgrade step
[12:47] <wgrant> Hmm. I wonder why the chroots would have that version, though.
[12:47] <wgrant> How odd.
[12:47] <seb128> what was the buggy version?
[12:48] <wgrant> I forget... the one where it was uploaded like 5 times in one day.
[12:48]  * wgrant checks.
[12:48] <wgrant> That bug was fixed in 73.
[12:48] <lamont> wgrant: they have the july 14 binaries
[12:48] <lamont> ish
[12:48] <lamont> (all of the tarballs)
[12:49] <wgrant> lamont: Hm, you recreated them during the brokenness? :/
[12:49] <seb128> lamont, can you check the version on the builders?
[12:49] <lamont> then the dist-upgrade step brings them current
[12:49] <lamont> wgrant: I just looked at the timestamp on the tarball
[12:49] <wgrant> Also, wouldn't this have been several hours easier if the old glib binaries were revived?
[12:51] <lamont> wgrant: yes and no
[12:52] <lamont> ii  pkgbinarymangler                70                        strips translations and alters maintainers d
[12:53] <seb128> lamont, can we update that and retry build?
[12:53] <wgrant> lamont: I mean, surely it'd be nice to fix archive breakage quickly without screwing with chroots....
[13:01] <pitti> argh
[13:01] <pitti> old ghosts come back then!?
[13:01] <lamont> seb128: and crunching along nicely now
[13:01] <lamont> pitti: you said no dist-upgrade... so you get july 14 bits
[13:01] <lamont> that was my point
[13:01] <seb128> lamont, thanks
[13:02] <lamont> 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] <seb128> lamont, you want another glib source upload?
[13:02] <pitti> 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] <lamont> pitti: in other news, my plan (as of last night) was to build new chroots first thing this morning.
[13:03] <lamont> there's some irony or such in there somewhere
[13:03] <wgrant> 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] <lamont> wgrant: with a higher than broken version number?
[13:03] <wgrant> lamont: Not critical if the chroots are old.
[13:03] <pitti> lamont: nice timing for the win!
[13:03] <lamont> except for the user
[13:04] <seb128> lamont, you need a source upload? when?
[13:04] <pitti> someone retried the glib i386 build then?
[13:04] <pitti> "started 5 mins ago"
[13:04] <wgrant> 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] <lamont> 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] <lamont> pitti: I did
[13:04] <lamont> with current pkgbinarymangler
[13:05] <seb128> why do you need a new source upload?
[13:05] <seb128> if you retried the current one
[13:05] <lamont> seb128: totally separate issue
[13:05] <pitti> seb128: the current build is bad, since it builds with an old toolchain, etc.
[13:05] <lamont> seb128: I'd like glib to be built with current build-deps, instead of 3-week old build-deps
[13:05] <seb128> ok, fair enough
[13:05] <lamont> s/build-deps/maverick/
[13:05] <seb128> I'm still aiming at trying to fix 2.25.12 if I can
[13:06] <pitti> seb128: that'd be even better, of course :)
[13:06] <pitti> seb128: it's an exercise in git bisect, by and large?
[13:06] <lamont> if you give me a window where the world is happy, I'll freshen the chroots this morning
[13:06] <seb128> pitti, I'm not sure, 2.25.12 built from tarball doesn't crash
[13:07] <seb128> but I'm only LD_LIBRARY_PATH loading the libraries
[13:08] <pitti> 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] <pitti> 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] <seb128> pitti, yes
[13:13] <seb128> it crashes this way
[13:16] <pitti> seb128: ok, so LD_L_P is working to reproduce the crash, and it's something that we patched in our package?
[13:16] <pitti> seb128: i. e. I assume "build from tarball" means "from upstream"?
[13:17] <seb128> pitti, it means tar xzf orig.tar.gz; cd glib; ./configure --prefix=/usr && make
[13:17] <pitti> *nod*
[13:18] <seb128> pitti, I'm doing a deb build without distro changes now
[13:19] <pitti> seb128: my first suspect would be 71_gio_launch_handler.patch
[13:19] <seb128> it's not
[13:19] <seb128> debian doesn't have this change
[13:19] <pitti> ok; well, then good hunting!
[13:19] <seb128> I'm wondering if that could be due to the rules
[13:19] <seb128> LDFLAGS += -Wl,-O1
[13:20] <seb128> for example
[13:20] <seb128> pitti, thanks ;-)
[13:20] <seb128> pitti, thank you for trying to give me hints as well ;-)
[13:23] <pitti> i386 finished
[13:23] <pitti> 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] <pitti> 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] <seb128> pitti, trying
[13:27] <seb128> pitti,
[13:27] <seb128> pitti, works
[13:28] <pitti> \o/
[13:28] <pitti> lamont: so, you can un-hack palmer/ross/hawthorn
[13:30] <lamont> pitti: all unhax0red.
[13:30] <lamont> pitti: ok if I leave the unmanual to you?  if it's published, I'll go do it now if you want
[13:30] <pitti> lamont: yes, that's fine
[13:31] <pitti> I'll reanimate them
[13:31] <pitti> lamont: and seems seb128 just found the root cause
[13:31] <pitti> so we now at least have a much better workaround
[13:32] <lamont> yay
[13:32] <didrocks> hum, I get some "Failed to upload", I think this is related to previous chroot/builder issue? (https://launchpad.net/ubuntu/+source/zeitgeist-extensions/0.0.3-0ubuntu1/)
[13:33] <pitti> didrocks: yes, you can just retry those
[13:33] <didrocks> pitti: ok, thanks :)
[13:46] <didrocks> pitti: still the same upload issue
[13:46] <pitti> didrocks: hang on, will look later
[13:46] <seb128> didrocks, what does the upload log say?
[13:46] <didrocks> sure, no hurry, good luck with you current debug stack :)
[13:47] <didrocks> http://paste.ubuntu.com/474019/
[13:47] <didrocks> 2010-08-06 12:36:42 WARNING Upload was rejected:
[13:47] <didrocks> 2010-08-06 12:36:42 WARNING     Duplicated ancestry
[13:47] <pitti> didrocks: ah, that's not mangler then
[13:47] <didrocks> I don't remember we uploaded it before…
[13:47] <pitti> didrocks: someone promoted a package to main or universe while it was built
[13:47] <pitti> you need to wait for a publisher
[13:48] <didrocks> pitti: "a package"? I don't really understand where the error is here TBH
[13:48] <pitti> didrocks: zeitgeist-extensions?
[13:49] <pitti> didrocks: look at https://edge.launchpad.net/ubuntu/+source/zeitgeist-extensions/+changelog
[13:49] <pitti> didrocks: it's published twice
[13:49] <pitti> apparently it was moved to main within this our
[13:49] <didrocks> oh ok, this is possible even if the first binary wasn't NEWed? ok, I understand now :)
[13:49] <didrocks> pitti: thanks, I'll wait for the publisher so
[13:57] <lamont> pitti: are we just waiting on a publisher run for the unmanual?  or are you waiting for another glib2.0?
[13:58] <pitti> lamont: publisher, and https://edge.launchpad.net/builders/hawthorn to finish
[13:58] <lamont> oh yeah.  hawthorn
[13:58] <lamont> that has the current pkgbinarymangler, fwiw
[13:58] <pitti> lamont: I'd like the packages to be published before I let any other package buildl
[13:58] <pitti> otherwise we have to retry even more
[13:59] <lamont> verily
[14:57] <jcastro> mpt: any clue as to where to report bugs on the apt.ubuntu.com redirector thing?
[14:57] <mpt> jcastro, no -- no-one is assigned to work on it
[14:58] <jcastro> is it going away eventually or will it be superceded by something or ... ?
[14:58] <jcastro> (trying to figure out if we should tell people to use it)
[15:06] <hyperair> Can't locate Dpkg.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/dpkg-source line 22.
[15:06] <hyperair> BEGIN failed--compilation aborted at /usr/bin/dpkg-source line 22.
[15:06] <hyperair> what happened? O_o
[15:10] <mpt> jcastro, I nagged rickspencer3 about finding someone to develop it at Guadec. More nagging would help. :-)
[15:14] <jcastro> mpt: I am born to nag, I just need the name of the person who touched it last
[15:16] <mpt> jcastro, Andrew Glen-Young iirc
[15:18] <pitti> seb128: I think I can set the buildds back to auto now
[15:18] <pitti> libglib2.0-0 | 2.25.12.is.2.25.11-0ubuntu1 |      maverick | amd64, i386, ia64, powerpc
[15:19] <lamont> pitti: woot!
[15:19] <lamont> pitti: you say so, I'll do it
[15:19] <pitti> palmer and ross back on auto
[15:19] <pitti> lamont: not yet armel
[15:19] <pitti> that still needs 40 mins for publishing
[15:19] <pitti> lamont: but the rest looks okay
[15:20] <seb128> pitti, thanks
[15:20] <lamont> pitti: so... terranova samarium lansones lychee actinium lemon litembilla rothera papaya hassium seaborgium thorium iridium thallium vernadsky adare muntries sandpaperfig radium rosehip nannyberry doubah uranium einsteinium dubnium shipova, yes?
[15:21] <lamont> done
[15:21] <pitti> lamont: https://edge.launchpad.net/builders looks good now
[15:22] <pitti> lamont: oh, you have an en-masse way to enable/disable them? I usualy click through all of them on above page
[15:22] <lamont> pitti: btw, you forgot ivy and kaylaberry when you did the manual thing... though I think we're safe there
[15:22] <Lukian> testing an upgrade from lucid to maverick results in dpkg: parse error, in file '/var/lib/dpkg/status' near line 48098 package 'virtualbox-3.1': error in Version string `3.1.6-59338_Ubuntu_karmic': invalid character in revision number -- should I file this bug against virtualbox or dpkg?
[15:23] <pitti> lamont: oops, indeed; wasn't aware that we had armel PPA builders
[15:23] <lamont> pitti: nothing actually uses them quite yet that I've seen
[15:23] <seb128> Lukian, known dpkg bug
[15:23] <Lukian> known bug? cheets
[15:23] <lamont> though in theory, that's going to change
[15:23] <seb128> Lukian, it's filed in launchpad and debian already
[15:23] <Lukian> cheers*
[15:24] <seb128> Lukian, you can edit your available and status files to workaround the issue
[15:24] <seb128> it does't like the _U..._
[15:24] <Lukian> already done ;)
[15:24] <pitti> seb128: how is that a dpkg bug?
[15:24] <Lukian> pitti, because it's a semi-valid version number? :>
[15:25] <pitti> how is 3.1.6-59338_Ubuntu_karmic a valid version number?
[15:25] <pitti> it's clearly not
[15:25] <Lukian> haha indeed
[15:25] <Lukian> but yeah, it still needs to be filed and fixed
[15:25] <pitti> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[15:26] <Lukian> pitti, maybe one day Sun will even lowercase the executable from "VirtualBox" to "virtualbox"
[15:26] <Lukian> Oracle*
[15:27] <seb128> pitti, well dpkg allowed people to install it at some point so it should allow them to get out of it
[15:35] <jcastro> didrocks: feature requests for banshee-meego that are ubuntu-specific should go in launchpad?
[15:35] <didrocks> jcastro: if it's ubuntu specific, yeah it should
[15:36] <didrocks> jcastro: if we can have the udev branch merge next week, it will be awesome. I'll be then on holidays for two weeks…
[15:36] <jcastro> ok let me see
[15:37] <jcastro> didrocks: next wednesday fine?
[15:37] <jcastro> that's 1.7.4
[15:37] <didrocks> jcastro: yeah, it is :)
[15:38]  * Laney hopes we can get banshee back in sync
[15:58] <hrw> hi
[15:59] <ttx> pitti: got one for you. Due to bug 614393 I consider reverting a recent upload to antlr3-3.2 and go back to antlr3-3.0.1 we had in lucid
[15:59] <hrw> http://hrw.pastebin.com/PNhm3K5Y - can someone help me with debian/control file to make it pass lintian?
[16:00] <ttx> pitti: I don't think we raelly want 30+ MIRs over this one
[16:00] <ttx> pitti: I should do a 3.2-really3.0 upload ?
[16:02] <pitti> ttx: ooh, please do
[16:02] <ttx> pitti: I need some guidance on the process, I never did that.
[16:02] <geser> hrw: on which architectures should the package get build? i386, amd64, armel, etc or a subset or only one specific?
[16:03] <ttx> pitti: is it just about uploading a new "version" that is 3.0.1 but as 3.2-really3.0.1.orig.tar.gz ?
[16:03] <hrw> geser: any basically
[16:03] <pitti> ttx: right, rename hte old tarball accordingly, and bump debian/changelog
[16:04] <ttx> pitti: what should the version name look like ?
[16:04] <geser> hrw: then add "Architecture: any" to the source stance in debian/control to get rid of the error (E:)
[16:04] <ttx> lucid has  3.0.1+dfsg-4ubuntu2, maverick has FTBFS 3.2-4
[16:04] <hrw> ok
[16:04] <pitti> ttx: 3.2.is.3.0.1-0ubuntu1 perhaps?
[16:05] <ttx> pitti: that would force us to stick with it until debian goes to 3.3, right (not that I care, but...)
[16:07] <pitti> ttx: but if you reuse 3.2-*, then you can't upload a new orig.tar.gz
[16:07] <geser> hrw: and you can ignore the warning about "linux-source" as it's is a real-package, and the other warning looks like you missed the XSBC- before Original-Maintainer
[16:08] <pitti> ttx: so 3.2 can't be built without the new dependencies?
[16:09] <ttx> no, upstream migrated to maven build system and debian followed suit
[16:09] <ttx> that's something we'll have to do at one point
[16:09] <ttx> but I'm pretty sure this is not the right moment in cycle to do it
[16:10] <ttx> especially with the possible outcome of breaking eucalyptus by upgrading a few libs in the process
[16:10] <pitti>  ttx 3.2.is.3.0 it is, then?
[16:10] <geser> ttx: as your are currently talking about a MIR (and AFAIK take also care about java packages): could you comment on bug 614000 (as additional input for the MIR team)
[16:10] <ttx> yep, will do
[16:10] <ttx> geser: looking
[16:11] <ttx> sounds reasonable, at least for axis
[16:12] <ttx> libservlet2.4-java is getting deprecated, shouldn't have anything in main depending on it anymore
[16:13] <ttx> geser: commented
[16:13] <geser> thanks
[16:17] <ttx> pitti: thanks for your input !
[16:28] <pitti> seb128, lamont: FYI, I switched the armel buildds back to auto as well now
[16:28] <seb128> pitti, thanks
[16:29]  * pitti hugs seb128 "hero of maverick"
[16:29] <lamont> pitti: woot.
[16:29] <pitti> seb128: note that the previous upload somehow didn't create a sparc build, but I guess/hope the next one will again
[16:29]  * seb128 hugs pitti back
[16:29] <lamont> I'll cook a set of tarballs today, and get blessings on them before deploying them monday
[16:29] <pitti> but then again, let's just ditch it
[16:29] <seb128> thanks again for helping sorting that
[16:29] <pitti> lamont: we shold wait on the next upload from seb128 with the real fix, I think
[16:29] <pitti> (for "good" chroots)
[16:30] <pitti> have a nice weekend everyone!
[16:31] <lamont> pitti: true
[16:31] <lamont> seb128: poke me when it's uploaded, mk?
[16:31]  * lamont -> town, afk
[16:38] <sconklin> what's the right place for pure python app  modules to install? I'm working on packaging one and the original app installed to /usr/share/appname/, but the debian packaging tools want to put it in /usr/lib/pymodules/python2.6/appname/
[17:17] <mathiaz> kees: once you've gone through all your daily USN, would you mind poking at libdbi MIR (bug 608552)?
[17:18] <kees> mathiaz: yup, MIR is on the list for today. :)
[17:19] <mathiaz> kees: \o/ - think ya
[17:19] <kees> oar welcome
[17:27] <RoAkSoAx> can someone please take a look to the following MIRs: bug #515996 bug #527155 bug #527142 bug #527182
[17:29] <Daviey> jdstrand: Hey.. Are you thinking of doing a libvirt 0.8.3-1 merge?
[17:29] <jdstrand> Daviey: yes
[17:29] <jdstrand> Daviey: probably first thing next week
[17:31] <Daviey> jdstrand: Okay, that's great - could i ask that you keep me posted on it.. i'd like to test it as soon as.. thanks.
[17:31] <jdstrand> Daviey: sure
[17:32] <Daviey> thanks!
[17:32] <jdstrand> Daviey: I should qualify the 'first thing next week' -- that is when I will start it. it is a complicated merge and there is likely a migration script I need to finish writing
[17:33] <jdstrand> Daviey: I'm not sure when it'll be done, but libvirt is my priority next week
[17:33] <Daviey> jdstrand: yeah.. the delta looks kinda scary :(...   The migration script will be a debian/ maintainer script?
[17:34] <jdstrand> Daviey: initially, yes. depending on my findings I may push to Debian and upstream
[17:34] <Daviey> jdstrand: Well, if you want me to do some smoke testing with it against UEC before it hits the archive, i don't mind.. just point me to a branch :)
[17:34] <jdstrand> k
[17:34] <jdstrand> thanks
[17:34] <Daviey> np
[17:34]  * Daviey dashes.
[19:22] <tkamppeter> pitti, hi
[19:27] <geser> tkamppeter: he fled into weekend 3h ago
[19:39] <hakzsam_> hi all
[19:40] <hakzsam_> I try to install rhythmbox from the sources, I downloaded them with 'git clone git://git.gnome.org/rhythmbox'
[19:40] <hakzsam_> but I have a problem with the './configure' script
[19:40] <ion> topic
[19:41] <hakzsam_> the error message is here : http://pastebin.com/6tNs0dtr
[19:41] <Pici> hakzsam_: This isn't a support channel, please see the topic.
[19:41] <hakzsam_> Pici, okay, but where is the topic ?
[19:42] <Pici> hakzsam_: /topic should tell you
[19:42] <hakzsam_> Pici, thanks !
[19:53] <ebroder> Hmm...what happens if you build a live CD with a ureadahead pack? Are there too many differences across different hardware for it to help?
[19:54] <ebroder> Could I build a live CD, generate a pack, drop the pack in and then re-squash the fs? Or is that going to re-arrange everything to the point that it does more harm than good?
[19:56] <LucidFox> "Taking the time to fix all the reported bugs is likely to mean that the fully open beta will be somewhat delayed." <-- What :S
[19:56] <ScottK> ebroder: If I tell you it's a bad idea will you give up?
[19:56] <ebroder> ScottK: If I say no will you tell me how to do it? :-P
[19:57] <ScottK> ebroder: No, because I don't know how.  I suspect you'll only be satisfied by trying it, so you should just go do that.
[19:57] <ebroder> How can it be a bad idea, in theory at least? Let's see...I could drop the pack in the initramfs and copy it over to the aufs mount, so that would keep me from mucking with the squashfs...
[19:59] <ScottK> Which reinforces my point.
[19:59] <ebroder> Fair enough. I'm mostly curious if I can avoid duplicating someone else's work, but I'll probably just give it a go
[20:00] <ScottK> If you are duplicating someone's work, it's not mine.
[20:15] <hdon> hi all. i am debugging a program freeze in Pidgin on Lucid Lynx. (http://pastebin.mozilla.org/763072) i have installed libgtk2.0-0-dbg but gdb still doesn't know simple things like function prototypes to show me the arguments of functions on the stack automatically. please help :)
[20:49] <hdon> .....
[20:55] <LucidFox> Hmm
[20:55] <LucidFox> how can I get an @ubuntu/member IRC hostmask?
[20:56] <cody-somerville> LucidFox, If you're a Ubuntu member, you can ask the IRC Council.
[23:18] <RoAkSoAx> kees: I'm wondering why you changed MIR's bug #527155 bug #527182 bug #527142 to incomplete, when I intentionally changed them back to new (by first updating the necessary information) to be processed?
[23:19] <RoAkSoAx> without any further explanation
[23:22] <kees> RoAkSoAx: heartbeat was already approved (so it should stay in "In Progress" state)
[23:23] <kees> RoAkSoAx: cluster-glue is still missing manpages
[23:23] <kees> RoAkSoAx: cluster-agents depends on cluster-glue
[23:24] <kees> I didn't add any comments because the changes back to "new" looked accidental, and included no comments either. :P
[23:25] <verb3k> Previous releases of ubuntu used to list CD/DVD drive device names in fstab, but in Lucid this is no more, why?
[23:33] <RoAkSoAx> kees: oh ok, I thought it was because they were still unseeded... anyways, thank you :)
[23:36] <kees> RoAkSoAx: they should go from In Progress to Fix Released once they're seeded and an archive admin promotes them
[23:40] <RoAkSoAx> kees: ok. Thanks. I'll keep an eye on them till they get seeded. Thank you!
[23:43] <kees> RoAkSoAx: cool; thanks!