[00:00] <broder> slangasek: understand is a pretty strong word. i don't think i ever reached a point of understanding
[00:00] <broder> just possibly a point of being able to apply grep and sed thoroughly enough
[00:03] <TheMuso> @pilot in
[00:05] <slangasek> broder: so, I have a partial patch that gets root-system part of the way through a build w/ multiarch, but for some reason I can't discern, it fails to build the kerberos module
[00:08] <Ampelbein> TheMuso: hi, could you have a look at bug 725044 and if it looks good sponsor the upload?
[00:11] <TheMuso> Ampelbein: I am actually looking at that merge proposal now. :)
[00:12] <Ampelbein> TheMuso: ah, cool ;-)
[00:15] <slangasek> broder: bug #745850 if you care to save it; if not I think removal is the right thing to do
[00:18] <broder> slangasek: i have no interest in saving it, i just didn't want to see kerberos maligned for someone else's issues
[00:18] <slangasek> :-)
[00:44] <GunnarHj> ScottK: ping?
[00:51] <Ampelbein> hmm, when installing gcj-4.4-jre-headless (4.4.5-15ubuntu2) it segfaults on the configure stage in a clean pbuilder environment, but not on my worksystem.
[00:52] <Ampelbein> it is the same error in pbuilder as appears on the official builders. https://launchpadlibrarian.net/67807729/buildlog_ubuntu-natty-i386.checkstyle_4.4%2Bdfsg-5_FAILEDTOBUILD.txt.gz
[01:15] <lifeless> kees: FYI cve pages are fixed
[01:35] <kees> lifeless: cool, thanks
[01:36] <lifeless> properly even :) - that huge one is down to 2 seconds render time
[02:48] <ScottK> GunnarHj: Pong
[02:54] <GunnarHj> ScottK: Hi Scott! It's about a gdm security update in lucid and maverick leading to the backports binaries no longer being the latest versions. I wanted to ask if there is some shortcut available for dealing with the issue. What I'm about to do is making new backports branches that include the update.
[02:54] <GunnarHj> ScottK: After having thought about it, I assume that this is a general problem with backports. Is it so?
[02:55] <ScottK> GunnarHj: That's the right thing to do.  Normally backports have enough higher version this doesn't come up.
[02:57] <micahg> this is actually good in this case
[02:59] <GunnarHj> ScottK, micahg: But would it have been appropriate to set a higher version? I mean, in that case the backports users would not have been notified about the security update, right?
[02:59] <ScottK> GunnarHj: Backports are unsupported, so that's not unusual.  It's like using a Universe package.
[02:59] <micahg> GunnarHj: well, the version was appropriate for what was backported
[03:00] <micahg> GunnarHj: in this case, the users are better off secure, than with the backport, the solution is to rebase the backport, sometimes packages are backported and not updated for security fixes which can be problematic for backports users
[03:05] <GunnarHj> ScottK, micahg: Think I got it. As regards typical backports, even if they are official, they are unsupported, and users install them on their own risk with respect to possible updates afterwards.
[03:06] <ScottK> Yes.
[03:06] <ScottK> Generally though it's easy enough to backport an update that has the relevant security fix.
[03:08] <GunnarHj> ScottK: But not quite as easy in this case... Guess I have myself to blame. ;-)
[03:09] <micahg> GunnarHj: nah, gdm's just not the normal fare for backports, usually with leaf packages, you just backport the latest version assuming it'll build/run
[03:09] <ScottK> Fortunately you can diff the security update from the base package and it should be ~easy to figure out how to update your backport.
[03:09] <ScottK> micahg: No, we test that it builds/runs.  Not much more though.
[03:10]  * micahg wonders what he said wrong
[03:10] <ScottK> In fact builds/installs/runs is the exact test criteria.
[03:12] <sbeattie> GunnarHj: FYI, bug 746796 is about the gdm backports issue.
[03:13] <GunnarHj> ScottK: Yeah, not saying it's _that_ difficult. Btw, considering it's gdm, can you upload the new branches, or should I ask someone in ubuntu-desktop?
[03:13] <sbeattie> GunnarHj: also, the patch fixed in USN-1099-1 is self-contained; I would be highly surprised if it didn't apply cleanly.
[03:13] <ScottK> Please find someone else as I've got a $WORK project that's due today.
[03:13] <ScottK> GunnarHj: ^^^
[03:17] <GunnarHj> sbeattie: I know. Bug 746694 too. Yes, I don't anticipate any problems. Thanks!
[03:20] <GunnarHj> ScottK, micahg, sbeattie: Going off keyboard. Thanks all for helping.
[03:22] <sbeattie> GunnarHj: okay. I'm stepping away for a while, too. If you have any questions about the update patch, feel free to poke me about it.
[04:03] <TheMuso> @pilot out
[04:03] <TheMuso> 
[06:41] <micahg> StevenK: would you be available to add some binary overrides?
[06:41] <micahg> s/add/adjust/
[06:41] <StevenK> micahg: It depends -- are we still frozen?
[06:41] <micahg> StevenK: I don't think so
[06:42] <micahg> StevenK: this is for stable releases
[06:42] <StevenK> micahg: Er?
[06:42] <micahg> StevenK: security update for qt4-x11
[06:43] <StevenK> micahg: Okay, what do you need?
[06:43]  * micahg is getting the list
[06:49] <Dread> heya
[06:49] <Dread> latest updates screwed up my internet on my main machine
[06:49] <StevenK> micahg: It doesn't bode well that it's taken over 7 minutes to get the list.
[06:50] <micahg> StevenK: sorry, the script is inherently slow
[06:50]  * micahg has only needed to do this once before and forgot how slow it is
[06:50] <StevenK> micahg: Oh, you want a bunch of stuff copied from security to updates?
[06:50] <micahg> StevenK: no, there's a script that does that, I just need the overrides applied in -security
[06:56] <micahg> StevenK: http://paste.ubuntu.com/588128/, I'm still working on hardy, thanks
[07:03] <StevenK> micahg: All done.
[07:03] <micahg> StevenK: thanks, I'm fighting with the script at the moment for hardy, I might just make it manually if I can't get this to spit it out
[07:08] <micahg> StevenK: can you demote qt4-dev-tools and qt4-qtconfig in hardy-security?
[07:09] <StevenK> micahg: And not libqt4-core? That's been in every other.
[07:09] <micahg> StevenK: nope, that's in main in hardy
[07:10] <didrocks> good morning
[07:10] <StevenK> micahg: DOne.
[07:10] <micahg> StevenK: thanks!
[07:12] <StevenK> micahg: Welcome.
[07:14] <DreadKnight> was there some alternative network manager for natty? called conman or something?
[07:15] <DreadKnight> because latest updates broke my network manager, which makes my main machine kinda useless now
[07:15] <holstein> how about wicd ?
[07:16] <DreadKnight> hmm
[07:17] <DreadKnight> holstein: does it have indicator support by any chance?
[07:18] <RAOF> Connman is in the archives, yes.
[07:18] <ohsix> what broke?
[07:18] <DreadKnight> RAOF: so that's how you spell it xD geez
[07:19] <holstein> DreadKnight: well, it did
[07:19] <ohsix> nm has its own logging, you should probably look & report the breakage, chances are it isn't nm
[07:19] <holstein> not sure about how things are now though
[07:19] <holstein> i havent had a chance to look at wicd+natty
[07:19] <RAOF> Last time I tried it it was not particularly functional; it'd do brain-dead things like update hostname to a string based on the connection and wouldn't update routes when a wired connection got plugged in.
[07:19] <DreadKnight> fail
[07:20] <holstein> :/
[07:20] <ohsix> big fail
[07:20] <RAOF> DreadKnight: In short, I'd suggest working out why network manager isn't working and fix it :)
[07:21] <DreadKnight> I can fix other stuff, but when it comes to internet and not being able to at least have a wired connection...
[07:21] <DreadKnight> might as well reinstall or look for another distro :
[07:22] <holstein> theres other distros ?
[07:22] <holstein> ;)
[07:22] <holstein> DreadKnight: try updating a different way
[07:22] <holstein> aptitude or apt
[07:23] <DreadKnight> indeed....
[07:23] <ohsix> DreadKnight: what do you mean by not working, is the applet there?
[07:24] <DreadKnight> ohsix: it's there, but it's saying something like "device not administrated" (it's in my native language, sry for bad translation)
[07:24] <pitti> Good morning
[07:24] <ohsix> DreadKnight: ok, so that's working, you just need to find out why its ignoring the device
[07:25] <DreadKnight> ohsix: even got my restricted driver I didn't really needed and installed it..
[07:25] <holstein> DreadKnight: if you had a kernel update
[07:25] <holstein> try booting into the older one
[07:26] <DreadKnight> holstein: good idea; trying it
[07:27] <micahg> GunnarHj: did you test build, install, run the new version?
[07:27] <ohsix> hm /etc/NetworkManager/NetworkManager.conf references /etc/default/NetworkManager but it's not there
[07:28] <DreadKnight> ohsix: bad prank for 1 april i guess
[07:28] <ohsix> DreadKnight: i know it says that when i blacklist a device as unmanaged, but i do that in NetworkManager.conf, there are other places that can probably do it, i'd rule those out
[07:28] <ohsix> like /etc/network/interfaces
[07:28] <GunnarHj> micahg: I have test builds in my ppa. Haven't actually tested them.
[07:28] <DreadKnight> holstein: same crap on older kernel
[07:28] <ohsix> the nm logging in /var/log probably says when its ignoring a device and why, too
[07:28] <micahg> GunnarHj: that's a requirement for backports
[07:29] <holstein> DreadKnight: hmmm
[07:30] <holstein> not sure, it is still beta
[07:30] <DreadKnight> too much crap in /var/log/
[07:30] <holstein> updates break sometimes :/
[07:30] <GunnarHj> micahg: I know. Just felt it was a little urgent, and since it's effectively just a combination...
[07:30] <DreadKnight> holstein: I know; but this breakage is ultra lame
[07:30] <ohsix> DreadKnight: just how lame is it
[07:31] <ohsix> and that message indicates user configuration ...
[07:31] <micahg> GunnarHj: still needs testing though
[07:31] <GunnarHj> micahg: Stupid arguments, btw. Will test. Logging out for now. See you.
[07:31] <holstein> DreadKnight: im suspicious of the proprietary driver install you were talking about
[07:31] <holstein> you might want to look at that a bit more
[07:32] <DreadKnight> holstein: did that for the modem software; but was just a try out at fixing the issue
[07:33] <DreadKnight> probably I don't have anything to do with modems anyway
[07:34] <holstein> DreadKnight: i would probably sleep on it
[07:34] <holstein> and see if an update comes along that sorts you out
[07:35] <ohsix> that is, if you don't want to figure out what it is
[07:35] <DreadKnight> holstein: I won't be able to update anyway, would have to get packages on another machine in the best case scenario and move them via an usb hdd... but that makes things kinda complicates as I won't know when or what...
[07:35] <DreadKnight> d*
[07:35] <DreadKnight> and not even if*
[07:36] <holstein> i usually find that with things like that
[07:36] <holstein> its my own fault
[07:36] <ohsix> DreadKnight: hook it up to ethernet, dhclient eth0
[07:36] <holstein> im not saying thats the case with you
[07:37] <DreadKnight> ohsix: oh didn't know about that; getting another cable around :D
[07:37] <micahg> this conversation should probably move to #ubuntu+1 unless it's discovered there's a bug
[07:37] <ohsix> you're right, i'm over there too
[07:49] <DreadKnight> dhclient eth0 gives me some "Permission denied" errors
[07:49] <DreadKnight> SIOCSIFADDR: Permission denied
[07:50] <DreadKnight> and twitce for FLAGS
[07:50] <DreadKnight> SIOCSIFFLAGS: Permission denied that is
[07:50] <DreadKnight> ohsix: poke :D
[07:50] <ohsix> #ubuntu+1
[07:51] <GunnarHj> micahg: Still there? They both install and run fine.
[07:52] <micahg> GunnarHj: ok, I can't ACK it, as I'm not officially a backporter, but change the statuses to new, give a link to your built packages if they're not there already, and add an install/run comment to the bug
[07:56] <micahg> GunnarHj: actually, you can mark "confirmed" as you said it "runs well"
[07:56] <micahg> GunnarHj: BTW, what did you mean by:  Stupid arguments, btw.
[07:58] <GunnarHj> micahg: Done. I was talking about my own attempt to justify that I hadn't tested.
[07:59] <micahg> GunnarHj: ah :)
[08:00] <micahg> broder: do you have time to review a backport?
[08:00] <GunnarHj> micahg: If I understand it correctly, that's as long as you can help with it.
[08:00] <micahg> GunnarHj: yep, aside from trying to ping someone to review it :)
[08:01] <GunnarHj> micahg: You are too fast to me! :)
[08:03] <GunnarHj> micahg: Think I'll ask Martin. People tend to be nervous about everything gdm, and he is well updated on the backported changes.
[08:03] <micahg> GunnarHj: he's not a backporter AFAIK
[08:09] <GunnarHj> micahg: No... I know that a backporter is supposed to confirm that it's appropriate for -backports, but since Scott did that a few weeks ago, and I haven't changed anything, it should still be appropriate for -backports...
[08:10] <micahg> GunnarHj: right, but every upload requires the review again, should be a fast one if nothing changed :)
[08:18] <GunnarHj> pitti: Hi martin, any chance that you can upload the gdm branches linked to bug 746694? micahg has helped me as far as he can. No backporters review yet, but nothing in the backported code has been changed, Scott is off making money, and it's a little urgent. ;-)
[08:19]  * micahg doesn't claim to have reviewed the actual package, just that pieces are ready for a backporter to review
[08:27] <pitti> GunnarHj: will do; as this is a bug fix to an existing backport, it should be okay
[08:27] <GunnarHj> pitti: Great, thanks!
[08:28] <GunnarHj> micahg: ^^^
[08:29] <GunnarHj> micahg: Btw, thanks for helping out with this urgent issue. As usual I learned a thing or two. ;-)
[08:29] <micahg> broder: nevermind :)
[08:47] <micahg> pitti: do you think bug 747025 is critical?
[08:52] <mvo> dpm: do we have someone from the cjk community who could look at #206018 ? there is some config change in there for language-selector fontconfig magic, but I have no clue if it helps or not
[08:55] <pitti> micahg: ugh, indeed; targetted to natty
[08:55] <pitti> micahg: assigned to tim for checking/uploading
[08:55] <micahg> pitti: cool, thanks
[08:56] <dpm> morning mvo, let me ping the Chinese translation team, but I'm not sure they'll be able to do much, as I see some of them on the bug comments already
[08:56] <dholbach> good morning
[08:58] <mvo> dpm: well, if there is consens what to do I'm happy to do it :) but I can't judge whether or not its a improvement so I need someone with that knowledge to help
[08:59] <mvo> dpm: if we shouldn't do anything about it, it would be good to close it as "opinion"
[09:01] <dpm> mvo, ack. I can't find anyone around right now, but I'll try later on
[09:02] <mvo> dpm: thanks a bunch, not urgent, I just don't want to let it drop on the floor without some opinion
[09:02] <dpm> no worries :)
[09:58] <tkamppeter> pitti, hi
[09:59] <pitti> hey tkamppeter
[09:59] <tkamppeter> pitti, can you upload CUPS? It has 2 fixes queued on the BZR.
[10:03] <pitti> tkamppeter: sure
[10:11] <doko_> janimo: do you get emails about the arm-rebuild build failures?
[10:11] <janimo> doko_, I don't think I do
[10:12] <janimo> doko_, I got various FTBFS emails these days but they were PPA related and not all armels
[10:12] <janimo> some for Canonical-ARM ppa
[10:15] <doko_> hmm, so it didn;t help to create the test rebuild https://launchpad.net/ubuntu/+archive/test-rebuild-20110329-arm
[11:05] <pitti> GunnarHj: just looking at your gdm branches -- did you re-do them from scratch?
[11:06] <pitti> GunnarHj: I had expected that you'd just merge lp:ubuntu/maverick-security/gdm into your original one, and then just have a changelog which says "update to latest security update (LP: #746694)
[11:06] <pitti> GunnarHj: want me to reorganize the changelog accordingly?
[11:07] <pitti> GunnarHj: otherwise it looks fine
[11:13] <pitti> both uploaded
[11:16] <GunnarHj> pitti: Doing so was my first thought, but I became in doubt. I simply used Bazaar Explorer and uncommitted my revision, pulled the news from -update and committed my revision again.
[11:17] <pitti> GunnarHj: ok, all sponsored and approved
[11:17] <pitti> thanks!
[11:57] <cdbs> pitti: As for bug #722521 I tested the maverick fix on a newly-started EC2 instance. Since the proposed upload I have installed it on my instanced whenever I start a new one (this has happened 5-6 times). No regression. Would this be a verification of the SRU?
[12:01] <pitti> cdbs: sounds good, thanks for testing!
[12:01] <pitti> cdbs: can you please followup on the bug saying so?
[12:01] <cdbs> pitti: okay
[12:01] <cdbs> pitti: if I had known I would have done that quite a long time ago. I often keep building stuff on newly-started instances
[12:06] <cdbs> pitti: But I verified only on maverick, so should I tag it verification-done?
[12:06] <pitti> cdbs: I'll deal with this
[12:07] <cdbs> pitti: commented, thanks!
[12:14] <doko_> Daviey: could the server team have looks at the postfix and openldap build failures?
[12:31] <Daviey> doko_, yes, thanks for raising them.
[12:39] <Daviey> doko, hah, postfix builds fine... on checking, it seems slangasek multiarched it this morning. \o/
[13:03] <mdz> didrocks, silbs' crash is https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/747205
[13:04] <mdz> didrocks, I filed that by manually running apport-gpu-intel-error.py
[13:04] <mdz> so it's not exactly at the point where the problem occurred, but should have all of the debug
[13:05] <didrocks> mdz: thanks, I wasn't able to find a dup in launchpad, I'll ping your Xorg guys on that, still googling if something can be of help
[13:05] <mdz> didrocks, the dupe check found bug 721086
[13:06] <cdbs> pitti: Sorry for the late response but bug #747025 has an attached debdiff by me - still it was assigned to tgardner
[13:08] <didrocks> mdz: ok, that's nice to know, bryceh already look at something similar
[13:11] <didrocks> mdz: info sent FYI
[13:33] <pitti> cdbs: I assigned it to him for review/upload, as he uploaded the original change
[13:33] <cdbs> pitti: okay, thanks!
[13:42] <tjaalton> mdz, didrocks: sent it upstream, and I'll ask ickle to have a look
[13:49] <mdz> didrocks, info sent where?
[13:49] <tjaalton> hmm, do we not mount debugfs by default anymore?
[13:49] <pitti> tjaalton: we do, /sys/kernel/debug/
[13:49] <tjaalton> pitti: ok, thanks
[13:51] <tjaalton> mdz: can you get /sys/kernel/debug/dri/0/i915_error_state from the hung state and attach it to the bug?
[13:51] <mdz> tjaalton, no, sorry, Jane has rebooted
[13:52] <mdz> tjaalton, does the apport hook not collect that?
[13:52] <didrocks> mdz: pang the xorg guys directly as it's more in their field of competence ;)
[13:52] <mdz> i915_error_state: no error state collected
[13:52] <mdz> didrocks, ah, ok
[13:52] <tjaalton> mdz: it did for the other bug you linked to, don't know why not this time
[13:53] <tjaalton> maybe it doesn't include it if it contains just that
[13:53] <mdz> tjaalton, it's there: "no error state collected"
[13:53] <mdz> tjaalton, that's the actual contents
[13:53] <mdz> I think
[13:55] <tjaalton> mdz: ok, thanks for confirming
[13:55] <mdz> tjaalton, it just does this:     attach_file_if_exists(report, '/sys/kernel/debug/dri/0/i915_error_state', 'i915_error_state')
[13:58] <mdz> tjaalton, i915_debugfs.c:396:		seq_printf(m, "no error state collected\n");
[13:59] <tjaalton> mdz: yep, figured as much
[13:59] <tjaalton> ickle said it wasn't a hung gpu, but related to the drm error, and will follow up on the upstream bug later
[14:00] <doko> tkamppeter, pitti: could we re-add the dependency of ghostscript in gs-common for the release? just too many build failures left
[14:02] <pitti> no problem from my side; I still see about 20 reverse build deps, do they all fail because they mean "ghostscript" when they say "gs-common"?
[14:04] <doko> yes, /bin/sh: ps2pdf: not found
[14:10] <tgardner> pitti, I'm coming to the conclusion that conf files are a bad idea. if you screw them up then the carnage lasts forever. wrt module-init-tools, should I perpetuate the carnage, or just delete the conf files from the package and leave it at that? this version missed B1 so it won't be on a CD.
[14:10] <pitti> tgardner: I think in this case we can just have a preinst snippet which bluntly rm -f's it
[14:11] <pitti> tgardner: it's only been in natty for a day or two as you say, so we don't need to be concerned about keeping user changes
[14:11] <pitti> tgardner: please do check the dpkg --compare-version "$2" ..., though :)
[14:12] <tgardner> pitti, why bother? there is no version where intel-3945-iwlagn-disable11n.conf is valid.
[14:13] <pitti> tgardner: it might come back at some point, though
[14:13] <pitti> tgardner: it doesn't cost much and is safer
[14:13] <pitti> tgardner: but I guess we can drop the preinst code after beta-2 anyway?
[14:14] <tgardner> pitti, yes
[14:27] <tgardner> pitti, can you give this a quick look? https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/747025/comments/5
[14:39] <hallyn> interesting.  xdg-open does not fare well when executed 3 times in a row very fast (i.e. 'for x in 1 2 3; do xdg-open http://bugs.launchpad.net/$x; done').  Wonder if this is an actual bug in firefox
[14:43] <pitti> tgardner: re (sorry, door bell)
[14:44] <tgardner> pitti, np. I'm actually testing it first.
[14:46] <tgardner> pitti, ok, it appears to work as expected.
[14:47] <pitti> tgardner: with le -> le-nl it looks perfect
[14:47] <pitti> le won't do much harm, though
[14:48] <tgardner> pitti, how can the version be empty?
[14:49] <pitti> tgardner: on fresh installation
[14:49] <tgardner> pitti, hmm, ok
[14:59] <dpm> hi cjwatson, the e-mail announcement I sent yesterday about Ubuntu AppDeveloperWeek didn't seem to make it to ubuntu-devel. Could you approve it when you've got a minute? thanks!
[15:01] <pitti> dpm: ah, I only approved it to u-devel-announce@, I thought that was what you meant
[15:03] <dpm> pitti, yeah, I got confused because I thought only Colin was admin on ubuntu-devel, I've just noticed that it didn't make it there - thanks for approving it on -announce, though :)
[15:09] <cjwatson> dpm: done
[15:10] <dpm> awesome, thanks cjwatson :)
[16:24] <ScottK> mvo: Thanks for 745396.  Awesome responsiveness, much appreciated.
[16:24] <ScottK> mvo: BTW, LP changes for backports-not-automatic will land next week.  So we can (if the FFe is approved) actually turn that on this cycle.
[16:24] <Laney> \o/
[16:29] <mvo> ScottK: nice!
[17:58] <doko> pitti, seb128: what's the recipy for /bin/sed: can't read /usr/lib/libgobject-2.0.la: No such file or directory
[17:58] <doko> libtool: link: `/usr/lib/libgobject-2.0.la' is not a valid libtool archive
[17:58] <doko> make[2]: *** [bsepcmdevice-alsa.la] Error 1
[17:58] <doko> ?
[17:59] <seb128> doko, grep libgobject-2.0.la /usr/lib/*.la on the system where you build to figure what .la is buggy and get that one rebuilt
[17:59] <seb128> or clean_la-ed
[17:59] <pitti> because it's /usr/lib/x86_64-linux-gnu/libgobject-2.0.la now?
[18:01] <doko> pitti: maybe, packages in universe are a mess now :-/
[18:02] <micahg> slangasek posted a list the other day
[18:03] <slangasek> yes, sources needing no-change rebuilds for .la moves: http://people.canonical.com/~vorlon/broken-srcs-universe.txt
[18:03] <slangasek> (some of these may have already been rebuilt since the list was generated, I'll refresh it a bit later today)
[18:04] <doko> maybe we should give these packages in the test rebuild
[18:04] <penguin42> anyone fix a link typo on http://www.ubuntu.com/testing/natty/beta; the link to 'Download the Ubuntu 11.04 beta' goes to #Download%20Beta  where I think it should be #Download%20Beta%201
[18:21] <broder> slangasek, kklimonda_: did either of you start on the universe rebuilds? if not i'll just start working my way down from the top
[18:22] <slangasek> broder: I haven't started yet; let me regen the list right now and we can see what's been fixed already
[18:27] <kklimonda_> broder: I didn't have time yet, I hope to get some work done tomorrow.
[18:27] <slangasek> two fell off the list on their own, it seems
[18:27] <broder> cool. i'll start working from the top, then
[18:29]  * micahg was going to try to get a few on sunday at the global jam if time permits
[18:34] <bdmurray> @pilot_in
[18:34] <udevbot> Error: "pilot_in" is not a valid command.
[18:35] <broder> bdmurray: 2 words
[18:35] <bdmurray> broder: thanks
[18:35] <bdmurray> @pilot in
[18:39] <YokoZar> mvo: poke
[18:40] <YokoZar> mvo: I put in a bzr branch of app-install-data for you that cleans up an old wine workaround, but never actually told you :p
[18:55] <broder> slangasek: and you wanted me to start cleaning the .la files when i rebuild as well?
[18:55] <hrw> kklimonda_: will you attend UDS-O?
[18:56] <slangasek> broder: use your best judgement - the highest priority is to get them all rebuilt, but if we have time to also fix some along the way to proof them against future changes, that's better in the long run
[18:57] <micahg> well, now that we have the list, we can always "fix" them later
[18:58] <slangasek> yeah, though that's kinda double work
[18:59] <broder> i don't think it's too much trouble to take care of them now - there are fairly standard snippets for most of the standard build systems
[19:06] <kklimonda_> hrw: well, that depends. :)
[19:07] <kklimonda_> (on whether I'll get a sponsorship, or not)
[19:10] <slangasek> jani_: hmmm, why is removing the symbol from the .symbols file the right fix for bug #747047?  Symbols files exist to guard against accidental ABI changes that can break reverse-dependencies, is this symbol not needed here?
[19:15] <jani_> slangasek, from what I understood, the diff suggested by dh_shlibdeps is what is needed to fix such errors
[19:16] <slangasek> jani_: it's what's needed to *avoid* the error, but it takes someone looking at why the symbol is gone away to decide if this is a "fix" :)
[19:17] <jani_> slangasek, I admit I do not fully understend symbol files :)
[19:17] <jani_> so such fixes based on what dh_shlibdeps say are not actually fixes?
[19:18] <slangasek> jani_: so a previous version of the library in the libclutter-1.0-0 package exported a 'clutter_clone_get_paint_volume' symbol.  The package is configured with dpkg-gensymbols -c4 specifically to treat it as a fatal error when a symbol goes missing, because other packages in the archive may be relying on that symbol being available at runtime
[19:18] <jani_> so the bug is why the library no longer exports that?
[19:19] <slangasek> the questions then are: is the symbol's disappearance deliberate, or is it an accident?  And if it is deliberate, is it safe wrt the reverse-dependencies?
[19:20] <jani_> slangasek, just checked upstream
[19:20] <jani_> commit fd89dee1b01c01619110cd77968062aaf2a98b79
[19:20] <jani_> Author: Neil Roberts <neil@linux.intel.com>
[19:20] <jani_> Date:   Fri Mar 18 14:09:57 2011 +0000
[19:20] <jani_>     clutter-clone: Make clutter_clone_get_paint_volume static
[19:20] <jani_>     
[19:20] <jani_>     clutter_clone_get_paint_volume was being exported from the shared
[19:20] <jani_>     library because the function wasn't declared static. This function
[19:20] <jani_>     shouldn't be exposed because it should be accessed through
[19:20] <jani_>     clutter_actor_get_paint_volume.
[19:20] <slangasek> ok
[19:20] <jani_> so it is deliberate, as for reverse deps I don't know
[19:21] <jani_> from the description it seems it was not part of a publicised API
[19:22] <slangasek> so in fact the symbol disappeared on all architectures, and it's just the armel symbols file that didn't get updated
[19:22] <slangasek> so your change is fine :)
[19:22] <jani_> not sure why the armel file did not get updated as the others
[19:22] <jani_> phew
[19:32] <slangasek> jani_: probably because "all the others" shared a single .symbols file which is the one that got updated :)
[19:32] <slangasek> and if it builds on x86, it's good to upload ;)
[19:49] <broder> ok, maybe knowing the topo sort for these rebuilds would be helpful. the first two on the list depend on other rebuilds. oh well
[20:14] <broder> slangasek: hmm...are libraries that link multiarch'd libs supposed to have rpaths?
[20:18] <bdmurray> @pilot out
[20:25] <slangasek> broder: not *supposed* to, but that seems to be a common side-effect... will work on sorting that out in the next iteration
[20:25] <broder> slangasek: i actually have two packages that both use libtool, and it's only happening on one, which seems weird
[20:26] <broder> slangasek: but i won't worry about it too much
[20:27] <slangasek> yes, the principal problem with rpath is that it makes directory transitions hard later; temporarily introducing them as /part/ of a transition is no big deal as long as we eventually fix it up
[20:54] <hallyn> zul: is there anything you want from me for the lxc dput?  (i.e. if you don't want to 'bzr bd -S' it for some reason)  if not, i'll mark it as 'done' in my list.
[21:00] <bdmurray> @pilot in
[21:51] <broder> doko: did the ftbfs page for your most recent rebuild stop getting updated? the list of universe failures looks way too short
[21:52] <broder> oh, i guess the package i was curious about just hasn't built yet
[21:53] <slangasek> I don't know how frequent the job is that updates the page, but I think it's "not frequent"
[21:55]  * micahg thought it was once an hour
[21:56] <micahg> The status pages are updated hourly
[21:57] <slangasek> ok
[21:58] <broder> i'm starting on the lib* packages in an attempt to wriggle out of the dependency hell, which the rebuild hasn't gotten to yet
[21:58]  * slangasek nods
[21:58] <slangasek> I started from the tail end; currently stabbing xmlrpc-epi, which has some sick and wrong hard-coding of libexpat.la
[22:42] <Keybuk> jono: jef!
[22:45] <slangasek> Keybuk: is that your safe word?
[22:45] <Keybuk> slangasek: "the safe word for tonight is 'Spatula'"
[22:45]  * slangasek nods
[22:46] <chrisccoulson> it's been quite an entertaining april 1st today ;)
[22:46] <jono> Keybuk, LOL!
[22:46] <chrisccoulson> hi jono!
[22:47] <jono> hey chrisccoulson :-)
[22:49] <jdong> sigh, I love you, eclipse
[22:49] <jdong> "The word 'strex' is not correctly spelled". Quick fix #1 is to correct to "straw"
[22:51] <bdmurray> @pilot out