[00:20] <micahg> hooray, thanks to the sync, we now have more FTBFS bugs than before :(
[00:31] <ajmitch> micahg: think of it as an opportunity :)
[00:31] <ajmitch> at least it could close a few "please upgrade" bugs
[00:32] <micahg> heh, yeah, but it makes it just that much harder for us to get that list down by release time :)
[00:32] <ajmitch> sadly yes
[00:32]  * micahg wanted a full sync run done for the open sync requests, but this was ridiculous :)
[00:33] <ajmitch> http://qa.ubuntuwire.com/bugs/rcbugs/oneiric/ may get a little shorter
[00:33] <micahg> yeah, although I filed requests for most of those already
[00:33] <ajmitch> ah, nice
[00:36] <ajmitch> how long was the ftbfs list for universe yesterday?
[00:38] <micahg> 411
[00:38] <ajmitch> 434 now, so not a huge jump
[00:38] <micahg> and we filed syncs that probably would've fixed at least 10 more
[00:39] <micahg> oh well, no use crying over spilled milk
[00:39] <ajmitch> it'd be a bit hard to go back
[00:39] <micahg> unfortunately, we also got caught up in some of the libjpeg-dev transition as well
[00:39] <ajmitch> messy
[00:40] <ajmitch> http://qa.ubuntuwire.com/bugs/rcbugs/oneiric/ is a lot shorter now
[00:41] <micahg> indeed :0
[00:41] <ScottK> Handy.
[00:41] <ajmitch> odd, there are a few -XbuildY packages that didn't get synced
[00:42] <micahg> yep, that was a bug in the new system
[00:42] <ScottK> That may be another bug.
[00:43] <ajmitch> gnat-4.6 was uploaded to sid more than a couple of days ago, didn't get synced (4.6.1-1 in oneiric)
[00:43] <ajmitch> so the autosync has a few bugs still :)
[04:39] <dnivra> highvoltage: ping ?
[07:05] <dholbach> good morning
[08:11] <tumbleweed> looks like about 2 weeks worth of new FTBFS packages: http://corelli.tumbleweed.org.za/ubuntu-qa/qa-ftbfs/oneiric-historical.html
[08:14] <Laney> oh yay
[08:16] <ajmitch> Laney: you were getting bored anyway
[08:18] <Laney> poor old universe getting disproportionately hit :(
[08:19] <dupondje> universe: 434 packages
[08:19] <dupondje> guess some work todo :D
[08:20] <Laney> I just heard someone at the derivatives roundtable say that they did an archive rebuild of squeeze and only got 10 FTBFS
[08:20] <Laney> jealous
[08:24] <geser> Laney: natty had only 16 known FTBFS and 4 depwait (on i386; amd64 was even better) at release, so not that bad
[08:25] <Laney> in all components?
[08:25] <dupondje> http://qa.ubuntuwire.com/ftbfs/natty.html
[08:25] <dupondje> universe 130 :P
[08:26] <Laney> i386/amd64 are pretty goofd really
[08:27] <dupondje> alot of linker issues in Oneiric FTBFS
[08:28] <jtaylor> wheren't those mostly handled already?
[08:28] <jtaylor> hm yes the autosync was not complete, e.g. the sugar-base versions where also not synced
[08:29] <jtaylor> uploaded on 25. in debian
[08:36] <dupondje> https://launchpad.net/ubuntu/+source/cipux-storage/3.4.0.2-6
[08:36] <dupondje> please trigger a rebuild
[08:36] <dupondje> was broken dep, is fixed :)
[08:40] <tumbleweed> dupondje: retried
[08:44] <dupondje> Successfully built on rothera (i386)
[08:44] <dupondje> one down ! :D
[09:06] <dupondje> https://launchpad.net/ubuntu/+source/easymp3gain/0.5.0-6
[09:07] <dupondje> retry plz ! :)
[09:14] <tumbleweed> dupondje: retried i386, if that builds, I'll do the others
[09:14] <jtaylor> should build, the change to -6 is a patch from me
[09:15] <dupondje> I tried locally also
[09:15] <dupondje> it builds :)
[09:17] <dupondje> libreadline5-dev is uninstallable ?
[09:19] <dupondje> ah should now use libreadline-gplv2-dev ?
[09:30]  * Laney spies persia in the NM queue :-)
[09:30] <tumbleweed> Laney: he was attempting to get through it during debconf. But his advocate is lagging :)
[09:30] <nigelb> \o/
[09:31] <Laney> you fast NMers
[09:31]  * Laney shakes fist
[09:31]  * tumbleweed attempted to advocate him, but I need a key that only his advocate has (and there are also key strength issues...)
[09:34]  * Laney wonders if anything on at debconf ATM is more enticing than listening to Pavement
[09:34] <Laney> haskell talk later :-O
[09:37] <dupondje> https://launchpad.net/ubuntu/+source/gitit/0.8.0.1-2 => also rebuild :)
[09:37]  * Laney smells some haskell
[09:37] <dupondje> indeed
[09:37] <dupondje> devscripts depend error ;)
[09:37] <Laney> mashed
[09:37] <nigelb> Laney: hat off to your sense of smell ;)
[09:37] <nigelb> *hats
[09:38] <Laney> :>
[09:43] <dupondje> https://bugs.launchpad.net/ubuntu/+source/hdbc/+bug/812454 fyi
[09:43] <Laney> why?
[09:47] <dupondje> As we are in sync again then?
[10:04] <dupondje> Could somebody do a testbuild of http://ftp.de.debian.org/debian/pool/main/libg/libgphoto2/libgphoto2_2.4.11-3.dsc on armel ?
[10:08] <c_korn> I have a problem with build format 3 (quilt). my series file is applied entirely but debuild -S -sa fails: http://pastebin.com/raw.php?i=q0N2gwjp
[10:10] <tumbleweed> can you pop and push your patches successfully? looks like thy are out of sync
[10:11] <c_korn> yeah, quilt pop -a and quilt push -a succeeds. but I think I know where the problem is. let me check...
[10:11] <jtaylor> I had the problem once when converting from 1.0 with direct upstream changes in debian.diff
[10:12] <jtaylor> 3.0 then tried to apply the patches a second time
[10:12] <c_korn> the problem was the upstream tarball
[10:12] <tumbleweed> what was wrong with it?
[10:12] <Laney> patching POTFILES.skip is the worst
[10:13] <c_korn> it has one top level directory which is not the package-version name but is "usr". debuild did not get it. had to repackage it include a new top level directory with the correct name and put "usr" under it.
[10:14] <tumbleweed> c_korn: ah. Yes if there is only one top-level directory, it is assumed to be the package name
[10:15] <c_korn> I should tell upstream to change this. I think it is the common way in the open source community and not a specific Debian/Ubuntu policy.
[10:16] <tumbleweed> more generally, it's common in tarballs :)
[10:16] <jtaylor> try getting windows upstreams to do that xD
[10:17] <tumbleweed> fortunatly they don't know what tarballs are
[10:17] <Laney> dpkg-source doesn't just rename the directory?
[10:18] <Laney> or create the right one and unpack into it
[10:18] <Laney> hmm
[10:18] <tumbleweed> dupondje: I couldn't test that under qemu, libgvc5 segfaulted in postinst
[10:19] <jtaylor> its configuring in mine
[10:21] <jtaylor> tumbleweed: did you hit bug 815933?
[10:21] <tumbleweed> jtaylor: yes
[10:52] <dupondje> tumbleweed: Well it was merged from debian with 'Disabled graphviz from the Build-Dependencies on ARM'.
[10:52] <dupondje> seems like we still need it :)
[10:52] <dupondje> or not ? a the bug is closed with Invalid ...
[10:52] <jtaylor> it seems to work on the builders
[10:53] <jtaylor> was that the reason for disabled graphviz?
[10:53] <dupondje> FTBFS on ARM
[10:53] <dupondje> but if thats fixed, we don't need to disable it anymore ofc
[10:54] <dupondje> see https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/567422
[10:58] <jtaylor> does not look related to this issue
[10:59] <jtaylor> but it could have been fixed in .11
[11:00] <dupondje> but to test that it needs to get a real testbuild on armel :)
[11:47] <dupondje> https://launchpad.net/ubuntu/+source/haskell-cprng-aes/0.2.1-1
[11:47] <dupondje> rebuild plz :D
[11:51] <Laney> doing
[11:53] <Laney> twidge needs updating, if you fancy doing that
[11:53] <Laney> i'll sponsor it as an nmu into debian for you
[11:55] <dupondje> Laney: http://packages.qa.debian.org/t/twidge.html is newest no ?
[11:55] <Laney> yes
[11:55] <Laney> it is broken, see the bugs
[11:56] <dupondje> I see
[11:56] <dupondje> let me look :)
[11:56] <Laney> should be easy
[12:01] <dupondje> if it builds on ghc7 yea :P
[12:02] <Laney> what was the way to work around the "gnomekeyring.IOError" in lpapi stuff? I can't remove python-gnomekeyring because some other things depend on it.
[12:05] <dupondje> HaXml >=1.13.2 && <1.19
[12:05] <dupondje> stupid thing :)
[12:06] <Laney> bet it works if you change that
[12:10] <dupondje> `Content' is not applied to enough type arguments Expected kind `*', but `Content' has kind `* -> *'
[12:10] <dupondje> boo ! :p
[12:13] <Laney> :'(
[12:15] <dupondje> contentToString :: [Content] -> String
[12:15] <dupondje> thats the line ... but god :) I don't know Haskell :)
[12:16] <tumbleweed> Laney: it's in launchpadlib's NEWS
[12:16] <Laney> ah yeah, I couldn't remember where it was
[12:17] <Laney> bah
[12:21] <tumbleweed> persia: now that my brain has unfogged, the advantage of my sponsorship miner over +related-packages is that it allows the sponsoree to see which sponsors to poke, and gives them an easy way to see the uploads they sponsored. Less useful for you, more useful for the sponsoree and endorser
[12:28] <dupondje> Laney: http://projects.haskell.org/HaXml/migrate.html
[12:28] <dupondje> :)
[12:29] <dupondje> but I don't understand a *** from it :)
[12:29] <dupondje> héhé
[12:34] <persia> tumbleweed: I'm not generally in favour of hard relationship between sponsors and endorsers: I'd rather see endorsements from people who interacted as peers in various places, rather than just from folk who sponsored diffs: I can read the diffs, so if the endorsement is just comment on the quality of the change, I have to infer the opinion of the endorser by mostly guesswork.
[12:35] <persia> tumbleweed: Conversely, if someone says "I've seen them answering lots of questions on IRC (or in email, or whatever), and they are a major contributor to ${DEVELOPMENT_TEAM}", that is a lot clearer to me.
[12:35] <persia> As a result, while I recognize the feature difference, I question it's value :)
[12:36] <tumbleweed> it was useful to me when endorsing people, as I am pretty forgetful :)
[12:36] <persia> tumbleweed: I suppose.  I'd rather read your endorsement based on you having a sense they are a good person, and have done good things, then because you did a review of their specific diffs, but that may just be me.
[12:37] <persia> Folk you remember are more likely to be your peers, to my way of thinking.
[12:37] <hrw> Can't locate Locale/gettext.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 /usr/local/lib/site_perl .) at /usr/bin/dpkg-cross line 6.
[12:37] <hrw> BEGIN failed--compilation aborted at /usr/bin/dpkg-cross line 6.
[12:37] <tumbleweed> persia: of course I remember them. I don't remember the details of everything I did with htem, which means I don''t know how rounded their experience is and how many issues I ran into with them
[12:37] <hrw> sorry
[12:38] <persia> tumbleweed: Ah, that's fair.
[12:38]  * tumbleweed wonders if its safe to dist-upgrade today
[12:43] <dupondje> Laney: fixing twidge doesn't seem as easy as expected. need to have some knowledge to adjust the code to build against newer HaXml
[12:43] <Laney> ok no worries
[12:44] <Laney> i will do it
[12:44] <dupondje> ok :D
[12:44] <dupondje> https://launchpad.net/ubuntu/+source/haskell-cprng-aes/0.2.1-1 => still this should build fine now? Tested it locally in a pbuilder
[12:46] <hrw> btw - is there a requirement that versions in debian/changelog do not contain holes? so 1.51 -> 1.53 should not be used
[12:48] <persia> hrw: There is no such requirement, but it's recommended to avoid this for native packages where possible.
[12:48] <dupondje> configure: error: Python.h not found
[12:48] <dupondje> mmmm :)
[12:50] <Laney> dpkg-deb: building package `twidge' in `../twidge_1.0.8.1+nmu1_amd64.deb'.
[12:51] <dupondje> Laney++
[12:51] <Laney> not sure I fully understand the new api
[12:51] <Laney> but ho hum
[12:52] <dupondje> :P
[12:52] <dupondje> its not really the sweetest coding language imo :)
[12:53]  * Laney fixes a laser stare
[12:54] <tumbleweed> Laney: haskell debconf talk time
[12:56] <Laney> oh!
[12:56] <Laney> good reminder
[13:06] <hrw> can someone take care of bug 817513 for me?
[13:06] <hrw> debdiff attached
[13:07] <hrw> persia: thx for info
[13:07] <dupondje> https://launchpad.net/ubuntu/+source/underscore/1.1.6-1
[13:07] <dupondje> builds fine now :)
[13:36] <dupondje> I wish I had a rebuild button :p
[13:37] <Laney> that should be done by the depwait checker
[13:38] <dupondje> but somehow it didn't :s
[13:38] <geser> dupondje: once you sponsors get sick of pushing buttons for you, they try to push you for MOTU
[13:38] <Laney> tumbleweed: recognise those graphs? :P
[13:38] <dupondje> geser: i'm working on it ;)
[13:38] <tumbleweed> Laney: I remember them being uglier :)
[13:39] <tumbleweed> dupondje: rebuilt
[13:39] <dupondje> libreadline5-dev got removed by a sync yesterday
[13:39] <dupondje> great :D
[13:39] <tumbleweed> Laney: IIRC the depwait checker is buggy
[13:40] <Laney> would have been a test case for wgrant then :-)
[13:41] <tumbleweed> I'm sure we'll find more :)
[13:44]  * Laney waves
[14:17] <dupondje> https://launchpad.net/ubuntu/+source/netifaces/0.5-2.1ubuntu1
[14:17] <dupondje> and this one seems to build fine also
[15:34] <hrw> argh... new day, new lintian warning learnt
[15:34] <hrw> patch-modifying-debian-files this time
[15:36] <Laney> all good fun
[15:37] <hrw> will move patches to debian/patches/gcc/ instead.
[15:39] <Laney> dupondje: erm, how did you build that?
[15:39] <Laney> it fails.
[15:39] <dupondje> netifaces? In pbuilder it worked here :s
[15:40] <Laney> well not here and not on the buildd
[15:40] <dupondje> weird :s
[15:41] <Laney> did you look at the failure reason and see if it still applied?
[15:41] <Laney> Found files in /usr/local/lib/python2.7 (must be in /usr/lib for python2.7).
[15:43] <Laney> zul: you might want to check the failure of netifaces (you uploaded it)
[15:43] <zul> its on my todo list
[15:43] <Laney> great, ty
[15:43] <dupondje> dpkg-deb: building package `python-netifaces-dbg' in `../python-netifaces-dbg_0.5-2.1ubuntu1_amd64.deb'.
[15:43] <dupondje> heh :s
[15:44] <Laney> have a look at the contents of the package though
[15:44] <Laney> i don't know what does that sanity check but you probably dont have it
[15:46] <dupondje> https://launchpad.net/ubuntu/+source/pidgin-skype/20110407+svn612+dfsg-1 => this one should build also now :)
[15:48] <Laney> no.
[15:50] <dupondje> dependency shizzle is fixed, but it fails indeed
[15:50] <dupondje> sorry
[15:51] <micahg> dupondje: no, I have a patch for that one
[15:51] <micahg> dupondje: that's a multiarch issue
[15:52] <Laney> it fails in debian too
[15:52] <Laney> file an rcbug
[15:52] <Laney> :-)
[15:52] <micahg> Laney: I'm going to send my patch to debian
[15:53] <Laney> excellent
[15:53] <micahg> but good to know it fails there now too, I'll use the virtual FTBFS status
[15:53] <Laney> if you don't get a response then i will sponsor an nmu for you
[15:53] <jtaylor> concerning all the as-needed patches I sent to debian, should I apply them in an ubuntu delta before the feature freeze or can that be done later too?
[15:54] <Laney> later, but don't forget
[15:54] <jtaylor> for those where there was no debian maintainer reaction
[15:54] <Laney> make sure to ping the bugs
[15:59] <dupondje> If we fixed a ftbfs with an ubuntu delta, and debian fixed it. Sync again or leave it ?
[15:59] <micahg> dupondje: leave it at this point unless there's some other interesting change
[16:00] <micahg> dupondje: unless it was fixed last cycle in which case syncing rebuilds with the new toolchain
[16:04] <Laney> note in merge-o-matic that the diff in ubuntuX is no longer needed
[16:04] <dupondje> mmm, apt-file broken ?
[16:05] <dupondje> Ignoring source without Contents File: http://archive.ubuntu.com/ubuntu/dists/oneiric/main/Contents-amd64.gz
[16:38] <dupondje> micahg:
[16:38] <micahg> dupondje: so, $_ is whatever the current array value is
[16:38] <dupondje> before it tries: http://archive.ubuntu.com/ubuntu/dists/oneiric/main/Contents-amd64.gz
[16:38] <micahg> if you remove it, then you can remove the surrounding loop as well
[16:38] <dupondje> after: http://archive.ubuntu.com/ubuntu/dists/oneiric/Contents-amd64.gz
[16:40] <micahg> dupondje: right, so that part is fine, it's just now the surrounding loop is useless :)
[16:40] <dupondje> you sure? cause it still need to loop over oneiric oneiric-updates etc ?
[16:40] <dupondje> the loop wasn't introduced into 2.5.0 neither btw
[16:41] <micahg> dupondje: that's not what that foreach does though
[16:41]  * micahg grabs the code
[16:44] <micahg> dupondje: it's splitting on white-space
[16:45] <micahg> dupondje: $_ represents whatever is in @extra one at a time, so it's just pushing the same thing multiple times into that reference
[16:45] <micahg> unless I'm missing something
[16:47] <micahg> dupondje: you're right, I'm quite confused
[16:47] <Laney> debian has contents in dists/.../main and dists/...
[16:47] <micahg> dupondje: ah, ignore me, I forgot about the implicit use of $_ in the pattern match
[16:47] <Laney> the latter is a symlink
[16:48] <micahg> Laney: I was just trying to figure out why the loop wasn't worthless
[16:48] <dupondje> Laney: indeed, but we don't have :)
[16:48] <dupondje> so its broken :D
[16:51] <Laney> I suspect the symlink wasn't there when debian made that change
[16:51] <Laney> you could talk to thijs about reverting it
[16:52] <Laney> (if ftpmaster plan on keeping it there)
[16:52]  * Laney is out, toodles
[17:05] <LaserJock> is there a FTBFS list for Universe?
[17:06] <jtaylor> LaserJock: http://qa.ubuntuwire.com/ftbfs/natty.html
[17:11] <LaserJock> jtaylor: thanks
[17:14] <geser> dupondje, Laney: pkgbinarymangler does the sanity check
[17:15] <micahg> LaserJock: there should be a link for oneiric on that page
[17:16] <jtaylor> or you just replace natty with oneiric when pasting ;)
[17:17] <geser> or just use http://qa.ubuntuwire.com/ftbfs/
[17:17] <Daviey> jtaylor: sounds to me that you have underestimated how lazy some of us are.
[17:17] <geser> links are there to be clicked :)
[17:23] <LaserJock> geser: heh, xchat had it buried
[18:43] <dupondje> bleh
[18:43] <dupondje> want to fix boinc, but seems I can't fix it :(
[18:43] <dupondje> :p
[18:45] <dupondje> gtk/taskbarex.cpp:20:21: fatal error: gtk/gtk.h: No such file or directory => So I need to add -I/usr/include/gtk-2.0
[18:45] <dupondje> but can't get it to it seems :s
[18:45] <micahg> dupondje: no, you need to use pkg-config
[19:38] <dupondje> boincmgr_CPPFLAGS = $(AM_CPPFLAGS) $(WX_CPPFLAGS) $(SQLITE3_CPPFLAGS) $(LIBNOTIFY_CFLAGS) $(CLIENTGUIFLAGS)
[19:38] <dupondje> is in the Makefile.am
[19:39] <dupondje> then added to configure.ac: CLIENTGUIFLAGS="${CLIENTGUIFLAGS} ${GTK_CFLAGS}"
[19:40] <dupondje> but seems the GTK_CFLAGS never get aded :s
[19:40]  * micahg isn't sure which is run first
[19:41] <micahg> dupondje: are GTK_CFLAGS populated in configure?
[19:42] <dupondje> there is m4/gtk-2.0.m4
[19:42] <dupondje> which should do that
[20:33] <dupondje> micahg: could you have a look with me or :)
[20:33] <micahg> dupondje: not right now, maybe later
[20:33] <dupondje> k
[21:14] <dupondje> https://launchpad.net/ubuntu/+source/libclaw/1.6.1-5 => is waiting for a dep
[21:14] <dupondje> that is in ubuntu ... :)
[21:15] <dupondje> and builds fine in my pbuilder
[21:17] <micahg> dupondje: dep doesn't exist
[21:17] <micahg> oh, maybe it does now
[21:17] <dupondje> libjpeg62-dev provides it
[21:19] <micahg> weird, both options are in main as well
[21:20] <dupondje> https://launchpad.net/ubuntu/+source/gargoyle-free/2010.1-2
[21:20] <dupondje> waiting for the same ...
[21:20] <dupondje> strange really :)
[21:20] <micahg> dupondje: there are a lot of packages like that
[21:21] <dupondje> yea indeed
[21:21] <dupondje> for some odd reason :)
[21:22] <dupondje> but gtg now
[21:22]  * ajmitch needs to check in an oneiric chroot, but it's possible that libjpeg62-dev & libjpeg8-dev both provide the same virtual package
[21:22] <ajmitch> since libjpeg6b hasn't been updated for 13 weeks
[21:22] <micahg> ajmitch: right, apt doesn't know which one to use so it fails
[21:22] <ajmitch> http://packages.qa.debian.org/libj/libjpeg6b/news/20110708T221903Z.html needs to be merged
[21:22] <ajmitch> so that the transition to libjpeg8 can go ahead
[21:23] <micahg> ajmitch: I asked about that in devel, we already have a few transitions that aren't done yet, I guess I should send a mail to ubuntu-devel about it instead
[21:23] <micahg> there are ~300 packages for the libjpeg transition
[21:23] <ajmitch> you'll see that in debian, there was a libjpeg8 & a libjpeg62 upload on the same day, switching which package Provides: libjpeg-dev
[21:24] <ajmitch> oh this'll be *fun*
[21:24] <micahg> ajmitch: we weren't supposed to get the new libjpeg8 :)
[21:24] <ajmitch> I know :)
[21:24] <ajmitch> now that we have it, who gets to coordinate this mess?
[21:26] <micahg> ajmitch: well, if the transition happens, we'll set it up in the tracker, the question is should it happen
[21:27] <ajmitch> right, someone needs to be able to decide that
[21:27] <micahg> TB?
[21:27] <ajmitch> probably
[21:28] <ajmitch> or just a mail to ubuntu-devel to see what people think
[21:28] <micahg> well, I'll send a mail to ubuntu-devel first
[21:28] <micahg> actually, I thought doko already did
[21:29] <ajmitch> nothing that I can see from him about it
[21:29] <micahg> nope, idk where I saw that...
[22:56] <micahg> ajmitch: sent to the release team w/a cc to ubuntu-devel
[22:59] <ajmitch> excellent
[23:30] <ajmitch> micahg: quick reply, at least
[23:33] <micahg> ajmitch: that's good, hopefully by tomorrow, a "fixed" version of libjpeg8 will get uploaded and we can gave all the FTBFS ones back
[23:34] <ajmitch> that should cut down the list a bit
[23:38] <ajmitch> hardest part of the upload is writing the changelog
[23:39] <micahg> heh