[01:09] <Keybuk> isn't natty's git-core package missing a dpkg pre-depends for mainthelper?
[01:19] <cjwatson> Keybuk: where does it use it?  I'm not seeing that
[01:21] <Keybuk> preinst
[01:21] <Keybuk> https://gist.github.com/c5e2da31a7db46b46243
[01:21] <Keybuk> (installing natty git-core on lucid)
[01:22] <broder> what's sensitive about apport bugs from kernel panics? the core dump?
[01:24] <cjwatson> Keybuk: oh, git, not git-core
[01:25] <cjwatson> Keybuk: yes, that looks like a bug to me as you describe
[01:32] <Keybuk> would you like me to file the bug?
[01:33] <cjwatson> yes please
[01:34] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618708
[01:36] <cjwatson> so fixed (albeit IMO oddly) in oneiric, but could use an SRU.  I don't see why we couldn't just add the Pre-Depends in an SRU, personally.
[01:36] <cjwatson> though I suppose that would be more inconvenient for the use case you described than the solution adopted in oneiric
[01:37] <cjwatson> so maybe a direct backport would be better
[01:43] <Keybuk> yeah, this was just a "clearly needs the p-d, but I should backport"
[01:47] <cjwatson> broder: I expect that the core dump could contain all sorts of random sensitive things from whatever you happened to be doing ...
[01:48]  * cjwatson crashes, not that way
[03:16] <bcurtiswx> all you quilt experts, when i'm in a bzr bd-do and i'm using quilt to fix patch issues, when i'm done what do I do to make sure my changes are sabed ?
[03:16] <bcurtiswx> saved*
[03:53] <RAOF> quilt refresh for each changed patch (before you pop).
[05:19] <pitti> Good morning
[07:13] <sladen> you're up early pitti
[07:14] <pitti> sladen: yeah, my wife gets up at 6 for work, so I'm doing the same
[07:24] <slangasek> my wife gets up at 5 for work, I try not to still be up when she does :-P
[07:27] <pitti> I could sleep longer as well, but then I'd still work for a long time when she's already back home
[07:27] <pitti> so I try to synchronize better
[07:28] <pitti> slangasek: at least you could say good morning :)
[07:28] <slangasek> yeah, but it would be better if I were actually doing what you do :)
[08:08] <didrocks> good morning
[08:16] <dholbach> good morning
[08:56] <Laney> hiya
[09:13] <dholbach> ev, we made quite a bit of progress on http://reqorts.qa.ubuntu.com/reports/sponsoring-stats/ yesterday it seems :)
[09:13] <dholbach> there's still quite a bit of clean up to do though
[10:15] <ev> dholbach: that was surely mostly you - I got largely bogged down in phone calls and firefighting yesterday :-/
[10:15] <ev> @pilot out
[10:34] <ev> pitti, mdz, cjwatson, other tech board people: could someone let my post through to the mailing list?
[10:34] <pitti> will do
[10:34] <ev> thanks!
[10:36] <pitti> the "Εντοπίστηκαν τα γονίδια της κατάθλιψης" one, right? :-)
[10:36] <ev> hah, but of course
[10:36] <pitti> ev: done
[10:37] <ev> thanks!
[11:02] <cjwatson> mdeslaur: stealing the fuse merge - I need it to unblock grub2 builds
[11:02] <cjwatson> (sorry, only occurred to me that you were TIL after I'd already committed to lp:ubuntu/fuse ...)
[11:05] <mpt> ev, https://blueprints.launchpad.net/ubuntu/+spec/crash-tracker
[11:05] <maxb> Hello ~ubuntu-sru people. bug 707075 has been used once to carry a bzr SRU into maverick. Now we're doing a related SRU into lucid. Can someone verify that I've done things appropriately such that 707075 is showing as needing attention in whatver way ~ubuntu-sru tracks bugs needing their attention?
[11:06] <ev> thanks mpt
[11:17] <brendand> mvo - can you remind me how to use a specified Glade .ui file in when running update-manager?
[11:17] <brendand> mvo - i think you told me before, but i forget
[11:18] <brendand> mvo - heh, i found it in scrollback. it's ok
[11:57] <mvo> brendand: ok, sorry for the delay, was away for lunch
[12:39] <GunnarHj> Hi all, any backporter available to approve a fix of bug 778869 in lucid-backports and maverick-backports?
[12:46] <micahg> GunnarHj: still has to be in natty first :)
[12:50] <GunnarHj> micahg: It is, isn't it?
[12:52] <micahg> GunnarHj: only saw it in oneiric ATM
[12:55] <GunnarHj> micahg: https://code.launchpad.net/~ubuntu-core-dev/language-selector/natty Don't know why it hasn't showed up in natty-proposed yet (will ask somebody to look at it), but for the purpose of approving the backports you can consider it to be in Natty, right?
[12:56] <micahg> GunnarHj: no, the idea is that on upgrade, people not lose backport functionality
[12:56] <micahg> and -proposed isn't on by default
[12:57] <micahg> s/backport/backported/
[13:07] <lool> cjwatson: Oy; would you mind binary NEW-ing python-linaro-image-tools?  it replaces python-linaro-media-create and python-hwpack
[13:10] <GunnarHj> micahg: Aha, that does make sense. But in this case it is not about new functionality, but a fix of a regression due to previously backported changes (because of them the fontconfig feature is partly broken for Japanese and Korean users). So, for that reason, shouldn't it be more important to backport the fix asap than waiting til it reaches natty-updates?
[13:16] <micahg> GunnarHj: well, I'll leave that for broder or ScottK to decide since bug fixes in -backports is slightly unusual
[13:19] <GunnarHj> micahg: Ok. As usual, the backports I'm involved in are special cases. :) Do you contact any of them, or should I?
[13:20] <micahg> GunnarHj: they were highlighted with my comment and will respond when available
[13:20] <GunnarHj> micahg: Right. Thanks!
[13:20] <micahg> GunnarHj: thank you for helping to improve the archive :)
[13:22] <GunnarHj> micahg: Yeah, I don't want people to encounter problems because of something I missed...
[13:52] <pitti> ah, Lennart proposed systemd as GNOME dependency -- we had that coming, I guess
[13:52] <Chipzz> pitti: didn't I complain about that a couple of weeks ago?
[13:53] <Chipzz> "told you so" :S
[13:53] <pitti> Chipzz: no surprise -- it was extensively discussed a few months ago at plumber's, and I also threw that into the discussion
[13:54] <Chipzz> hrmyeah
[13:54] <Chipzz> I think I'll refrain from expressing my feelings about Lennart since that would probably violate a lot of the CoC
[13:55] <Chipzz> anyway, I hope the gnome ppl have the common sense to reject his proposal
[13:55] <pitti> Chipzz: why should they reject it?
[13:56] <pitti> from upstream's POV it would make sense to share code instead of duplicating it in gnome-session
[13:56] <pitti> and we ourselves talked about using upstart's new per-user jobs for session handling
[13:56] <Chipzz> because the init daemon is not part of gnome, neither should it be
[13:56] <pitti> Chipzz: architecturally, gnome-session and init have a lot in common
[13:57] <Chipzz> yes, but by forcing systemd down every distributions throat you're also causing a lot of unwanted side-effects
[13:57] <Chipzz> this doesn't affect just gnome, now does it?
[13:57] <pitti> it'll certainly make it harder for non-Linux platforms or non-systemd ones, yes
[13:58] <pitti> but to be fair that road has been taken years ago with the move away from hal to udev/udisks/upower
[13:58] <Chipzz> doesn't mean we should go further down that road
[13:58] <pitti> except for that we were on the winning side (and even worked on that migration ourselves heavily)
[13:58] <pitti> Chipzz: certainly not
[13:58] <Chipzz> UNIX != Linux
[13:59] <ScottK> micahg: Since there's already a backport, I think bug fixing it while the SRU is in progress is fine.
[13:59] <ScottK> It is a bit of a special case.
[14:00] <pitti> ScottK: my understanding is that all the followup -backport uploads we had just kept up with -security and -updates, and don't by themselves introduce new "backported features", so they ought to have an implicit approval?
[14:01] <ScottK> pitti: I'm not entirely comfortable with implicit approval, but certainly if the change is SRUable, I'm willing to accept that as good enough for backports.
[14:01] <seb128> pitti, the email from lennart is sort of a follow up of UDS discussions, we asked desrt to make sure that if GNOME was to use systemd features the depends wouldn't be added without a public discussion which is what is happening
[14:01] <pitti> seb128: yes, that's how I understand it
[14:01] <seb128> pitti, desrt wants to use XDG_RUNTIME_DIR for dconf at least
[14:01] <pitti> and we can certainly use the dbus backend helpers
[14:01] <pitti> they shouldn't conflict with anything else
[14:01] <seb128> pitti, I especially pointed to desrt that the systemd depends will be an issue for ie debian-bsd
[14:01] <pitti> and sooner or later we'll have the source at least in universe anyway
[14:02] <seb128> so GNOME should be clear if they decide to screw non linux systems and non systemd distros
[14:02] <pitti> ScottK: SRUable> I meant in the stronger sense, applying patches which were already SRUed or USNed
[14:02] <pitti> seb128: non-linux> cf. dependency on udev and friends
[14:02] <ScottK> Yes
[14:02] <ScottK> That's fine.
[14:03] <Chipzz> also tbh IMO there's things to be said about this starting to reek a lot like vendor lock-in
[14:03] <pitti> GunnarHj: ^ so, it's just a sponsoring issue, not approval
[14:03] <seb128> pitti, well still the discussion is an opportunity for those who have issues with the depends to argue it should stay optional
[14:03] <pitti> seb128: oh, perhaps I got misunderstood -- I'm totally in favor of having this discussion on desktop-devel@
[14:04] <ScottK> pitti: I just added a comment in the bug where I said I was in favor, but it should be tested in the target environment.
[14:04] <ScottK> e.g. lucid/maverick
[14:04] <pitti> *nod*
[14:04] <micahg> ScottK: I thought another round of testing was required before accepting those backports for security/SRU fixes
[14:04] <micahg> oops
[14:04] <micahg> nm
[14:05] <ScottK> micahg: Agreed.  It should be tested since we don't have the barrier of -proposed before it hits end users.
[14:06] <micahg> ScottK: I missed that you already said that :)
[14:06] <ScottK> No problem.
[14:08] <ogra_> cjwatson, do you have a spec for the live-helper stuff ? NCommander asked me to add a dependency for some of our specs
[14:09] <cjwatson> ogra_: NCommander has the details already
[14:09] <ogra_> that doesnt help my specs :)
[14:09] <cjwatson> I guess each one of your team is going to ask me in turn? ;-)
[14:09] <ogra_> he said you could only give him old info
[14:10] <ogra_> (a natty spec or so)
[14:10] <cjwatson> sure, it's in other-foundations-n-cd-build-speed, but that's still open and there's no reason you can't depend on it
[14:10] <ogra_> if thats the right one i'll use it indeed
[14:10] <ogra_> good, sorry for bothering
[14:10] <cjwatson> it was discussed this UDS but I can't remember in what session
[14:10] <ogra_> (i understood him that aou were planning to have a more recent one, else i wouldnt have asked)
[14:11] <ogra_> *you
[14:11] <ogra_> communication flaw apparently
[14:12] <cjwatson> the only difference would be that the new spec would be *-o-* - the action item would be the same
[14:12] <cjwatson> so it shouldn't make a difference from your POV
[14:12] <ogra_> yeah
[14:24] <jamespage> cjwatson: re the discussion we had re libjibx1.2-java and it absence from the archive yesterday;
[14:25] <jamespage> cjwatson: I've looked at the deps and it would have caused potential issues with the current version of eucalyptus
[14:26] <jamespage> cjwatson: I've resolved that issue (and tested with the other rdep in universe - freemind); so I think that it would be OK to allow libjibx1.2-java into universe.
[14:26] <cjwatson> what's "it" here?
[14:27] <jamespage> sorry - it = the libjibx-java provided by libjibx1.2-java
[14:27] <cjwatson> ok
[14:28] <jamespage> the two versions are not forwards or backwards compatible hence why they have been packaged separately.
[14:28] <cjwatson> but both eucalyptus and freemind will now be OK with the newer version?
[14:29] <jamespage> no - they use the libjibx1.1-java package so won't go near the new version
[14:30] <GunnarHj> ScottK, pitti, micahg: Added a comment about tests of the backports proposals to bug 778869. They were tested in Lucid respective Maverick.
[14:30] <cjwatson> jamespage: ah, you only just uploaded that eucalyptus change
[14:30] <ScottK> GunnarHj: Then it's just a matter of sponsoring then.
[14:30] <jamespage> cjwatson: yes - last 10 minutes or so (zul did it for me)
[14:30] <cjwatson> jamespage: let me wait for that to hit the archive, then, so that the tools don't need to be overridden
[14:31] <GunnarHj> ScottK: Ok, thanks.
[14:31] <jamespage> cjwatson: great
[14:52] <dholbach> ScottK, I took the liberty of copying the work items of the backports spec into the blueprint whiteboard
[14:56] <ScottK> dholbach: Thanks.
[14:56] <dholbach> (just trying to get an idea how bad my workload is going to be this cycle ;-))
[15:34] <ScottK> dholbach: Looking at your bottlenecks spec, "open backport requests" could look at three things potentially: Requested, not tested (New/Incomplete), Tested not approved (Confirmed/Triaged), Approved not done (In Progress).
[15:35] <dholbach> ScottK, thanks for letting me know - I'm happy to track all of them - for now I'll just copy the information to my notes, so I don't forget
[15:35] <dholbach> I'm sure I'll get back to you once I start working on it :)
[15:35] <ScottK> OK.
[15:35] <dholbach> thanks
[15:36] <broder> ScottK: are you using Incomplete for "needs testing"?
[15:36] <ScottK> broder: I use it for "I looked at it and it's not ready", which usually amounts to needs testing.
[15:39] <micahg> ScottK: on the subject of backports, if backports were to open after feature freeze, would the barrier for entry be the same as normal backports?
[15:39] <ScottK> micahg: Except for the must be in the development release first part, I'd imagine yes.
[15:39] <Laney> modulo "available in the development release"
[15:40] <Laney> Does NEW work for -backports?
[15:40] <micahg> ScottK: k, that's what I was hoping for :)
[15:47] <ScottK> Yes.
[15:47] <ScottK> (re New)
[15:48] <ScottK> This whole concept would have to be reviewed/approved by the tech board before we could do it.
[16:53] <sabdfl> i have a call at 1800 so won't deliay
[16:56] <maco> ooh i wonder if we'll hit 100,000 open bugs by the end of oneiric
[16:58]  * cjwatson wonders if that will happen before or after armel builds catch up
[16:58] <lool> slangasek: Oy; https://launchpadlibrarian.net/70129102/buildlog_ubuntu-lucid-i386.qemu-linaro_0.14.50-2011.04-1-0ubuntu1~ppa10.04.1_BUILDING.txt.gz (qemu-linaro lucid backport in linaro-maintainers/tools PPA) shows Pre-Depends: dpkg >= 1.15.7.2 for qemu-kvm-extras-static, but that dpkg isn't available in lucid; do you know what's happening there?
[16:58] <cjwatson> lool: linaro-image-tools> looking
[16:58] <cjwatson> sorry for the delay
[16:58] <Laney> 10 hours, not bad
[16:59] <slangasek> lool: not offhand, but let me check my marvelous bzr history
[16:59] <lool> cjwatson: thanks!
[17:00] <cjwatson> lool: wouldn't a Conflicts/Replaces be helpful to guide people's apt instances towards knowing to install this package instead?
[17:00] <slangasek> lool: that's for dpkg-maintscript-helper support; sorry, I didn't think to look at if that version was in lucid when doing the ppa upload, I guess that explains some of the behavior that's been reported to me
[17:00] <cjwatson> I guess the dependency from linaro-image-tools should do that
[17:01] <lool> cjwatson: there's a breaks/replaces
[17:01] <slangasek> lool: it's effectively a transition package anyway, so I'm not sure it's worth hacking around?
[17:01] <lool>  Breaks: qemu-kvm-extras-static (<< 0.13.50-2011.02-0~rc1-0ubuntu1)
[17:01] <lool>  Replaces: qemu-kvm-extras-static (<< 0.13.50-2011.02-0~rc1-0ubuntu1)
[17:01] <lool> cjwatson: in qemu-user-static
[17:01] <lool> cjwatson: oh sorry, mixing two conversations
[17:01] <lool> cjwatson: I guess it could; technically the other packages aren't broken
[17:01] <lool> cjwatson: I am happy to add them
[17:01] <cjwatson> yeah, up to you I guess, at any rate not a reject matter
[17:01] <cjwatson> lool: accepted
[17:02] <lool> cjwatson: thanks for the review
[17:02] <lool> slangasek: well apparently this confuses apt for lucid users
[17:02] <poolie> could someone please review this bzr MRE SRU for me? https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
[17:02] <lool> slangasek: But it looked like a bug somewhere; is this pre-depends in the packaging?  I thought it was generated by some tool we should fix, or perhaps the result of copying binaries between archives
[17:03] <slangasek> lool: no, it's in the packaging - it's the required pre-dependency if you're going to use dpkg-maintscript-helper, which didn't exist before that
[17:03] <lool> slangasek: aha
[17:04] <cjwatson> though it isn't necessarily in the packaging - if you use debhelper >= 8.1.0 and debian/package.maintscript, dh_installdeb will add that Pre-Depends
[17:04] <cjwatson> as long as you remembered to add Pre-Depends: ${misc:Pre-Depends} that is
[17:04] <lool> slangasek: I told this user to use apt-get install qemu-user-static qemu-kvm-extras-static-; I guess we could revert this pre-depends in lucid
[17:05] <cjwatson> I mean, not necessarily in the packaging for all packages
[17:05] <lool> hmm that might indeed be a good way to use the same source but not generate that pre-depends in the lucid build
[17:05] <cjwatson> well, no
[17:05] <cjwatson> not unless you make debhelper emit a load of manual code for it anyway
[17:06] <cjwatson> TBH I think it's better in such cases to revert to the previous method, and hold our noses until lucid stops mattering
[17:06] <cjwatson> or revert in a custom backport
[17:07] <cjwatson> speaking of NEW, if somebody could have a look at grub2, that would be good - the package reorganisation is already through Debian NEW
[17:14] <slangasek> lool: reverting the pre-depends would make the preinst fail :)
[17:21] <micahg> doko: should openjdk-7 be taking 8 days on armel for oneiric?
[17:28] <ScottK> barry: As a compromise on Bug 784662, would you be able to build and test the oneiric package on natty so we can just put it in natty-backports?  Testing doesn't need to be more than 'it runs'.
[17:29] <micahg> ScottK: has 2 rdepends as well
[17:29] <ScottK> micahg: Right.  I guess it depends on how broken it is at the moment.
[17:36] <doko> micahg: yes
[17:37] <doko> still progresses
[17:37] <micahg> doko: ok, thanks
[17:43] <maxb> Are there any ~ubuntu-sru members around who could confirm that bug 707075 is visible as something needing attention in due course?
[17:46] <lool> slangasek: Something like that http://paste.ubuntu.com/609602/ ?
[17:46] <slangasek> lool: I expect there are corresponding updates to the postinst and postrm required
[17:47] <lool> slangasek: yup
[17:48] <lool> http://paste.ubuntu.com/609605/
[17:48] <lool> just copied the preinst file
[17:50] <lool> Ah I forgot to remove the actual pre-depends
[17:52] <slangasek> lool: well, I don't think rm_conffile as such is what you want in each of the maintainer scripts... dpkg-maintscript-helper behavior is more subtle than that
[17:53] <slangasek> lool: so it might be that a single call to rm_conffile in one of the scripts is sufficient - we just need to make sure we aren't trying to call nonexistent dpkg-maintscript-helper from the others
[17:53] <lool> Ok; looks like I should actually read the dpkg-maintscript-helper man page
[17:54] <cjwatson> certainly shouldn't be the exact same code in all three
[17:54] <lool> it was the same dpkg-maintscript-helper calls, so disabling my brain I just copied the rm_conffile snippet, but that's indeed not a good idea
[17:54] <slangasek> it's the same call, but d-m-h is far too clever and knows which maintscript it's called from :)
[17:55] <lool> yup
[17:55] <lool> slangasek: BTW why not do that from the qemu-user-static package?
[17:55] <slangasek> because that's not the package that owned the conffile
[17:56] <lool> but isn't there the chance that the version with the maintainer snippets never gets installed?
[17:56] <slangasek> if the user is doing something other than a plain upgrade, yes
[17:56] <slangasek> s/upgrade/dist-&/
[17:57] <lool> so a non-purged package would leave the file on disk, and it's effect woudl continue
[17:58] <lool> slangasek: Apparently you can remove conffiles from other packages with dpkg-maintscript-helper; it seems that might be a better way to ensure it goes away?
[17:58] <slangasek> it would be a more comprehensive way
[17:59] <lool> I think I would do it only in qemu-user-static.preinst and qemu-kvm-extras-static.preinst; it seems to be enough
[17:59] <slangasek> if you're doing it in qemu-user-static, you don't need it in qemu-kvm-extras-static at all
[17:59] <slangasek> because the one depends on the other
[18:00] <lool> right
[18:03] <lool> alright, uploaded
[18:33] <mdeslaur> andreserl: mind if I merge virtinst?
[19:13] <broder> mdeslaur: does the test case in bug #336932 work for your compiz/screensaver stuff?
[19:15] <mdeslaur> broder: uhm...probably
[19:15]  * sebner hugs broder 
[19:15]  * broder waves at sebner :)
[19:15] <sebner> broder: it was a real pleasure to talk to you! :)
[19:15] <mdeslaur> broder: I know people see update manager when it pops up
[19:16] <broder> mdeslaur: at mit we ran into issues with the graphical zephyr client, but that's a little harder to setup and test with :)
[19:16] <mdeslaur> broder: sorry, I haven't had time to identify real testcases that I've personally tried yet
[19:31] <poolie> SpamapS: hi, could you have a look at an SRU for me?
[19:33] <mterry> kees, does my latest comment in https://bugs.launchpad.net/ubuntu/+source/seed/+bug/782972 make sense?
[19:33] <mterry> kees, oh you just commented!  i missed it
[19:33] <kees> hehe :)
[19:34] <poolie> specifically https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
[19:39] <sconklin> pitti: still around?
[19:40] <SpamapS> poolie: sure, which one?
[19:40] <andreserl> mdeslaur, sure go ahead :)
[19:40] <SpamapS> poolie: lucid bzr ?
[19:41] <mdeslaur> andreserl: cool, thanks
[19:41] <poolie> yes please
[19:45] <SpamapS> poolie: ahh, this may take a bit.. big diff. ;)
[19:45] <sconklin> SpamapS: are you able to copy a package from our ppa to -proposed?
[19:46] <SpamapS> sconklin: have not had any progress on that yet I'm afraid. :-/
[19:46] <SpamapS> pitti: ping, this is a reminder.. we need to do that archive training.
[19:47] <sconklin> jdstrand: are you able to copy a package from our ppa to -proposed?
[19:47] <poolie> SpamapS: it has a microrelease exception so
[19:48] <poolie> well, i'm not saying don't read the diff, but i just wanted you to be aware of it
[19:48] <poolie> which diff url are you looking at?
[19:48] <SpamapS> poolie: right I am just looking to make sure the diff is actually the diff from 2.1.1 to 2.1.4
[19:49] <SpamapS> Not going to try and grok all 11 bugs fixed. :)
[19:51] <jdstrand> sconklin: I've not talked to pitti yet, though I did review the process. I will send an email to kernel-sru today so we can get this unblocked for you. if this is blocking testing, I would recommend you have the testers get the packages (that you want copied to -proposed) directly from your PPA today
[19:52] <poolie> thanks SpamapS
[19:55] <SpamapS> poolie: looks good! accepting.. :)
[19:56] <sconklin> jdstrand: I don't think it's blocking testing. Stefan would know but he's also left for the day. Before he left he asked me to make sure it got copied to -proposed asap
[19:56] <sconklin> It was still building when he had to leave
[19:57] <poolie> great! thanks
[19:57]  * SpamapS sits and watches as sru-accept.py spams all the subscribers
[19:58] <SpamapS> poolie: speaking of new versions of bzr.. how do I get 2.4 on my natty system?
[20:05] <poolie> SpamapS: ppa:bzr/ppa or ppa:bzr/proposed or ppa:bzr/daily
[20:05] <poolie> from least to most excitng
[20:06] <poolie> that is a new record (low) for sru latency, which is just so good
[20:08] <SpamapS> poolie: micro release exceptions have definite benefits for pushing things into the stable release quickly. :)
[20:10] <poolie> yeah, and we're getting a better idea how to do them smoothly
[20:11] <poolie> and i think it's good for ubuntu too to have projects maintain these branches rather than be trying to pick branches out
[20:11] <poolie> assuming it's sufficiently stable
[20:18] <SpamapS> poolie: +1 , stable, responsive upstreams == happy ubuntu users
[20:19] <geser> anyone familiar with autotools have a minute to help me figure out why pidgin FTBFS after a autoreconf during build?
[20:21]  * sebner waves at geser
[20:22] <geser> Hi sebner
[20:59] <geser> any libtool expert around?
[20:59] <slangasek> if I say yes, am I going to have to look at libtool? :)
[21:01] <geser> slangasek: probably, I'm trying to understand why pidgin FTBFS in oneiric (https://launchpadlibrarian.net/71695867/buildlog_ubuntu-oneiric-amd64.pidgin_1%3A2.7.11-1ubuntu3_FAILEDTOBUILD.txt.gz)
[21:01] <geser> as one of the Ubuntu patches touches configure.ac, autoreconf is run during the build
[21:02] <geser> but I don't understand why it FTBFS after that
[21:03] <hallyn_afk> all right, having some toolchain trouble i think.  When I pull-lp-source seabios natty;  cd seabios-0.6.1.2;  debian/rules build  i get the error:
[21:03] <hallyn_afk> https://wiki.ubuntu.com/ServerTeam/Roadmap/OneiricPlanning/UDSBudapest
[21:03] <geser> it seems to be a libtool issue as after downgrading libtool to the version in natty, pidgin builds again fine
[21:03] <hallyn> I get that whether I"m build in natty or lucid, in fact
[21:04] <geser> hallyn: you sure you pasted the right url?
[21:04] <hallyn> uh, that's not it
[21:04] <hallyn> :)
[21:04] <hallyn> out/romlayout16.lds:695 cannot move location counter backwards (from 000000000000c9fa to 000000000000c9e0)
[21:04] <hallyn> that would be it
[21:05]  * hallyn curses xchat for using different clipboard from terminal
[21:05] <slangasek> geser: I think I agree that this is a libtool issue; libgnt.la is clearly being built immediately beforehand
[21:06] <hallyn> hm, i've tried this in schroots, containers, and on the host.  but lemme just push it to a ppa just to be 100% sure there's a toolchain regression, not a local weirdness
[21:08] <slangasek> geser: can you reproduce this with the Debian libtool and raise a bug on the Debian package?  I don't think there's anyone with deep knowledge of the libtool code who will dig into this on the Ubuntu side
[21:08] <geser> slangasek: when I compare the build/finch/libgnt directory from a build with libtool from oneiric I can only see a Makefile and gnt.pc, while in the same directory with libtool from natty there are also *.lo files and libgnt.la
[21:09] <slangasek> wow
[21:09] <geser> slangasek: can try, just downloading the libtool deb from Debian unstable and use this?
[21:09] <slangasek> oh wait
[21:09] <slangasek> oh, no, don't wait
[21:09] <slangasek> geser: yes, exactly
[21:09] <geser> slangasek: also calling "make libgnt.la" in build/finch/libgnt (with libtool from oneiric) doesn't show any error (exit code 0) but still no files there (perhaps somewhere else but I couldn't find them)
[21:10] <slangasek> nope, should be created in that dir
[21:10] <slangasek> anything output in .libs?
[21:11]  * sebner hugs slangasek 
[21:11] <sebner> slangasek: Just wanted to say that it was a real pleasure to talk to you!
[21:11]  * slangasek hugs sebner
[21:11] <slangasek> likewise :)
[21:15] <geser> slangasek: same error with libtool 2.4-2 from Debian unstable
[21:17] <slangasek> geser: cool, then Q_ can probably help
[21:18] <slangasek> geser: btw, maybe it's useful to test without --silent, to see what commands libtool is trying to run (if any)
[21:18] <geser> slangasek: see http://paste.ubuntu.com/609721/ for all files I've in that dir and the output of "make libgnt.la"
[21:23] <slangasek> geser: what happens if you try to run one of those libtool --mode=compile commands without the --silent?
[21:25] <geser> slangasek: http://paste.ubuntu.com/609725/ after modifying the Makefile and removing the --silent
[21:25] <slangasek> heh
[21:35] <hallyn> Yes, I get the exact same thing building for ppa:   https://launchpadlibrarian.net/71969868/buildlog_ubuntu-natty-i386.seabios_0.6.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[21:35] <hallyn> this is the exact same package as is currently in natty archive.
[21:35] <hallyn> kees: ^ is there some change in build flags that you know of htat woudl cause this?
[21:38] <kees> hallyn: nothing that I know about. how odd!
[21:39] <hallyn> kees: ok, thanks.  feh, i guess i might have to go read though and try ot actually understand it :)
[21:39] <hallyn> the weirdest thing is that it also now fails under lucid (the same way) to build
[21:40] <hallyn> so presumably it's some change which then got SRUd!
[21:43] <slangasek> geser: you said autoreconf was called during the build?
[21:43] <slangasek> I don't see that in a build log here
[21:44] <slangasek> in fact, I think that's the source of the problem - the generated libtool script is DOA
[21:44] <slangasek> probably because of mismatched ltmain.sh and autoconf macros
[21:44] <geser> slangasek: autoreconf was the wrong summary, there is a automake and autoconf between the the two configure runs in the log
[21:44] <slangasek> right
[21:44] <slangasek> you're missing libtoolize :)
[21:44] <slangasek> so, an explicit autoreconf should fix this
[21:45] <slangasek> (not a libtool bug then)
[21:50] <hallyn> kees: feh!   https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/756044
[21:58] <slangasek> geser: an explicit autoreconf fixes it here
[22:01] <geser> slangasek: thanks, running libtoolize fixed it (just tried it inside my pbuilder). Is using dh-autoreconf in debian/rules the right packaging fix (and filing the issue upstream)?
[22:02] <slangasek> dh_autoreconf is probably reasonable here, yse
[22:02] <slangasek> yes
[22:02] <slangasek> I'm not sure if there's anything here that should be filed upstream
[22:04] <geser> not?
[22:05] <slangasek> geser: well, the upstream rules seem to be working in the standard automake way
[22:08] <geser> why does it only happen when we modify configure.ac which triggers the regeneration? without that patch which modifies configure.ac it builds fine (with libtool 2.4 from oneiric)
[22:08] <slangasek> because only modifying the autotools source files triggers a build-time invocation of autotools
[22:10] <geser> why does the build with the old files and libtool 2.4 installed work while it fails with the regenerated?
[22:11] <ohsix> hyperair: any chance at #651931 in natty? i've got other crashers for click before paint if you're interested as well
[22:12] <slangasek> geser: because running automake && autoconf pulls in new versions of the libtool macros from the system directory, which don't match the ltmain.sh in the source tree
[22:12] <geser> and why shouldn't configure call libtoolize when it regnerates the files? as missing to call libtoolize seems to cause problems if the libtool version changed
[22:12] <slangasek> perhaps it should - but I don't think that's something that pidgin upstream is going to fix, the build glue all comes from automake
[22:13] <geser> ok
[22:14] <geser> then I just use dh-autoreconf and be done with it?
[22:15] <slangasek> or file a bug against *automake* upstream, if you wish :)
[22:17] <geser> nah, I'm happy to not have to file a bug somewhere :)