[00:45] <infinity> ScottK: What will fix x86? A new upload?
[00:45] <infinity> ScottK: If so, you can just reject the other binaries.
[00:50] <infinity> ScottK: Oh, hrm, I wonder why our gcc appears to be upset about -fuse-ld...
[02:56] <ScottK> infinity: I think -fuse-ld is fine, it's -fuse-ld=gold that's trouble.
[02:59] <ScottK> New upload is on the way.
[02:59] <ScottK> Rejected the old one.
[03:02] <ScottK> New qt4-x11 on the way.  That should be OK to accept once it's built.
[03:06] <infinity> ScottK: The whole point of -fuse-ld is to pass =gold. :P
[03:07] <ScottK> Oh.
[03:07] <infinity> But that patch might not be upstream yet, it might only be in some dists.  I'll talk to doko when we're not being quiet in a session.
[03:08] <infinity> doko: Or, you could read up and comment on this, despite the fact that you're sitting next to me. :P
[03:10] <doko> infinity, you should use -B/usr/lib/compat-ld/ instead
[03:11] <infinity> doko: Is there a reason we're not carrying the -fuse-ld patch?
[03:11] <infinity> doko: More and more upstream code seems to be using it, and we've patched it out here and there.
[08:05] <xnox> cjwatson: ok, thanks. =))) quicker debian imports are always good.
=== NCommand1r is now known as NCommander
[09:57] <ogra_> infinity, so whom do i have to talk to about the arm chroots ?
[10:00] <ogra_> (we really need to get the images building and i also want to switch to the new flash-kernel for A1)
[10:03] <infinity> ogra_: Chasing webops now.
[10:03] <ogra_> infinity, whom do you talk to over there, i'll happily take over if you want
[10:04] <infinity> Whoever the current vanguard is.
[10:04] <ogra_> is there a special channel or just #is ?
[10:04] <infinity> #webops
[10:04] <ogra_> oh, ok
[10:06] <ogra_> infinity, k, now that this part is off my table, how about doing a plain sync of flash-kernel, then changing the packaging for the db and watch the fallout ?
[10:06] <infinity> That sounds potentially messy...
[10:06] <ogra_> (server team is warned about it and i think robbie already looks into the debian f-k)
[10:06] <ogra_> well, the arches we used to support should all work OOTB
[10:07] <ogra_> and i think we need images to work with to test changes properly
[10:07] <infinity> Except armada and highbank.
[10:07] <ogra_> right
[10:07] <ogra_> but i warned the server team already
[10:07] <infinity> omap/omap4, mx5, and ac100 should all be good?
[10:07] <ogra_> and i plan to write an announcement mail to ubuntu-devel
[10:07] <ogra_> yeah
[10:08] <infinity> I'm not sure an announce is worth the effort.
[10:08] <infinity> I don't announce every scary sync/merge I do. ;)
[10:08] <ogra_> mx5 is debians buildd platform for hf, so that should definitely work, ac100 was ported (and improved) from my hacks in ubuntu, omap and omap4 should work too
[10:08] <infinity> Debian may not install mx5 the same way we do.
[10:08] <ogra_> well, i know that people like TI realy on their f-k hacks
[10:08] <infinity> I wouldn't count on it.
[10:08] <ogra_> *rely
[10:09] <ogra_> so they should be informed that the old script is gone
[10:09] <ogra_> i count on nothing ;) thats why i want the time to test it with actual images before A1
[10:11] <ogra_> it would all break anyway once we switch to live ... i dont think flash-kernel-installer has all bits and pieces for all aarches yet, not even in our version
[10:12] <ogra_> so i think doing the big step first is the best move and wont cause more havoc than not switching (and i dont want to have to fix our old f-k)
[10:15] <tkamppeter> Anyone around from the SRU team? Can someone approve my ptouch-driver and system-config-printer SRUs? I get lots of bug reports of users due to printing problems.
[11:01] <xnox> How often do transition trackers update?
[11:03] <cjwatson> Half-hourly IIRC
[11:05] <xnox> thanks
[11:05] <xnox> Page generated on Wed, 30 May 2012 08:54:43 +0000
[11:05] <xnox> every 4hours based on 'debian dinstall'? =)))
[11:07]  * cjwatson blames something else
[11:07] <cjwatson> Need to finish deploying the new tracker anyway, argh.  Probably not much point nitpicking the current one.
[11:07] <xnox> =))))) yes please
[11:08] <xnox> we will get the overview page and the % trackers =))))
[11:09] <xnox> it updated just now.
[11:26] <xnox> infinity: thanks for boost ;-) another one bites to dust.
[11:26] <infinity> s/boost/glob2/ ?
[11:26] <xnox> infinity: well yeah, helpgin boost transition.
[11:27]  * xnox my left hand is faster than my right hand
[11:27] <infinity> No comment.
[11:27]  * xnox 'gin' vs 'ing' typpo.
[11:28]  * ogra_ tries to get a bottle of acid in his right ear to clean out the images in his brain now
[11:28]  * infinity goes back to relaxing with a movie.
[11:28] <infinity> ogra_: *snicker*
=== ara is now known as Guest64238
[13:13] <xnox> jamespage: about java7 transition: do we have a tracker for that? (if one is possible) e.g. http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[13:15] <jamespage> xnox, I've been trying to think of a good way track the transition - I think part of it could be covered by the transition tracker (anything that depends on openjdk-6-*)
[13:15] <jamespage> but tracking anything that depends on the default-* packages does not work that way (I think).
[13:15] <xnox> jamespage: source build-dep and/or binary depends ?
[13:16] <jamespage> xnox, spot on
[13:16] <xnox> jamespage: we also have .edos-check installable?
[13:16] <xnox> would that help?
[13:16]  * xnox knows little java packaging intrisics
[13:16] <jamespage> xnox, what does that do?
[13:17] <xnox> jamespage: e.g. http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html
[13:17] <xnox> let me try to explain, one sec.
[13:17] <tumbleweed> do things that build-depend on default-* need any attention at all?
[13:17] <xnox> jamespage: explaination / definition is here http://edos.debian.net/edos-debcheck/
[13:18] <xnox> jamespage: something like `if you attempt to apt-get install $pkg, the said $pkg may succeed in installing, as in it has no conflicts`
[13:18] <jamespage> xnox, ah - I see
[13:19] <jamespage> xnox, probably of limited value
[13:19] <xnox> does that help? or does the default-* stuff will simply install fine, but will not work.
[13:19] <xnox> jamespage: we can check for min dependency. Does the new default-* stuff generate 'depends: default-* (>> 7.X.Y)'
[13:20] <jamespage> tumbleweed, xnox: with regards anything that BD's on  default-jdk its really just a no-change rebuild to ensure it still builds
[13:20] <tumbleweed> you don't need to no-change rebuild for thta
[13:21] <jamespage> xnox, no - packages don't generate a versioned dependency in that way
[13:21] <jamespage> tumbleweed, I agree that an upload is not required specifically to check it builds
[13:21] <xnox> jamespage: have you seen http://qa.ubuntuwire.com/ftbfs/ ? a couple java packages are there.
[13:21] <tumbleweed> I thought javahelper did do things like that. It creates dependencies like java6-runtime
[13:22]  * tumbleweed has been fixing a couple of those FTBFS pcakages (places where the debian maintainer build-deps on openjdk 6)
[13:22] <jamespage> tumbleweed, yes it does - but javahelper only accounts for a small percentage of the total number of java packages
[13:22] <tumbleweed> true
[13:23] <jamespage> xnox, yeah - been working through main first - nearly there - on the last few hard ones at the moment
[13:27] <jamespage> have to admit that `reverse-depends -b default-jdk -c universe -l | wc -l` was a bit larger than I anticipated
[13:27] <jamespage> 788 packages - yikes
[13:29] <ogra_> pfft, thats less than 1% of the archive
[13:44] <jamespage> xnox, tumbleweed: is there a way to pull a straight list of packages which FTBFS? I'd like to cross reference those against the r-b-d's of default-jdk
[13:45]  * xnox sorry no clue
[13:45] <tumbleweed> jamespage: http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-quantal.csv
[13:46]  * ogra_ thinks the ubuntuwire page is the most reliable way to find FTBFS
[13:46] <ogra_> unless you write a script with lplib that loops over all recent uploads and checks them or some such
[13:46] <jamespage> tumbleweed, ta
[13:47] <tumbleweed> look at lp:svammel if you want to file bugs / do something with the things programmatically
=== jbicha is now known as Guest70781
[15:06] <Laney> infinity: Do you know if you'll be able to get to bug #888665 at some point soon? I think perhaps ignoring NotAutomatic for backports builds is fine. micahg?
[15:06] <ubot2> Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
[15:06] <Laney> We're hitting it relatively often now
=== Guest70781 is now known as jbicha_
[15:24] <cjwatson> bdmurray: rejecting your duplicate apport sync to precise-updates
[15:25] <bdmurray> cjwatson: duplicate? oh I'd run sru-release and then asked slangasek to approve it
[15:25] <cjwatson> well it'd been published and there was also a sync in the queue
[15:25] <slangasek> oh
[15:25] <cjwatson> LP isn't too good at avoiding dups here
[15:26] <slangasek> so running sru-release puts it in the approval queue (even) if you're not a member of ubuntu-sru?
[15:28] <bdmurray> slangasek: yes, clint approved a couple for me yesterday
[15:28] <slangasek> ack
[15:32] <cjwatson> yep, anyone can copy
[15:32] <cjwatson> well anyone with upload rights to the package
[15:32] <cjwatson> same rules as syncing from Debian
[15:33] <tkamppeter> slangasek, cjwatson, I have rather urgent SRUs for printing, I am getting many bug reports about these problems. Can you approve my ptouch-driver and system-config-printer SRUs? And can you move cups-filters to -updates?
[15:33] <xnox> cjwatson: add two factoroids about this new feature? And pipe it to everyone who asks? =)
[15:33] <cjwatson> xnox: can't say I was ever a fan of losing information in IRC bots' brains
[15:34] <xnox> =)
[15:34] <cjwatson> not all the cups-filters bugs have been verified, according to the report
[15:36] <cjwatson> and I don't see your ptouch-driver upload in the queue
[15:37] <cjwatson> I'm sure there must be a more pythonic approach to that sort than a giant list of if statements, but well, maybe not for SRU
[15:38] <cjwatson> accepted system-config-printer
[15:41] <tkamppeter> cjwatson, the two cups-filters bugs which are not verified are simply not verified because the original reporter is not available for one bug and the other is a private support bug and probably not visible for the original reporter. Should I decaouple these somehow from the SRU? And how should I do it?
[15:42] <cjwatson> There are four unverified bugs, according to the report
[15:43] <knome> skaet, ? :)
[15:43] <skaet> knome,  hiya
[15:43] <skaet> ?
[15:43] <knome> hey! may i PM?
[15:44] <tkamppeter> cjwatson, forgot the dput for ptouch-driver. Done now.
[15:44] <skaet> knome,  k
[15:46] <tkamppeter> cjwatson, ptouch-driver has arrived now.
[15:47] <cjwatson> tkamppeter: bug 668800, where the original reporter says that the fix doesn't help him, although it also doesn't appear to regress; bug 862167 which is private but the reporter is in Canonical Support and should be pressed to follow up on verifying that; bug 992982 which is a dup and as you say the original reporter is unavailable right now; and bug 997728 which you disconnected
[15:47] <ubot2> Launchpad bug 668800 in cups-filters "Printing speed problem" [High,Fix committed] https://launchpad.net/bugs/668800
[15:47] <ubot2> Launchpad bug 992982 in cups "Network printing fails. Worked before upgrade to 12.04 (dup-of: 973270)" [High,Fix committed] https://launchpad.net/bugs/992982
[15:47] <ubot2> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
[15:47] <ubot2> Launchpad bug 997728 in cups-filters "Ubuntu port of acroread degrades images (works on Win7)" [High,Invalid] https://launchpad.net/bugs/997728
[15:47] <cjwatson> tkamppeter: so I don't quite know, how much is 862167 just another instance of an identical bug somewhere else?  I haven't read through all these
[15:49] <tkamppeter> cjwatson, bug 668800: person for whom I linked it is Lorenzo Bettini (bettini), comment #42, but seems to have disappeared. What to do?
[15:49] <ubot2> Launchpad bug 668800 in cups-filters "Printing speed problem" [High,Fix committed] https://launchpad.net/bugs/668800
[15:49] <cjwatson> but the original reporter was oliver-raincode
[15:50] <cjwatson> So I think it doesn't fix his problem and you'll need to reopen the bug after this change goes to -updates - correct?
[15:50] <tkamppeter> cjwatson, for oliver-raincode it turned out that his problem is different, he has no PostScript printer, what to do then.
[15:50] <cjwatson> because it's his bug, not Lorenzo's
[15:50] <cjwatson> Lorenzo was just randomly dogpiling a bug, he doesn't get to take ownership of it
[15:51] <tkamppeter> cjwatson, should I reupload the package with these four bugs removed from debian/changelog?
[15:51] <cjwatson> So, as I say, I think you should reopen 668800 after this update goes out (there's no real way to stop it auto-closing the bug now)
[15:51] <cjwatson> No, don't reupload, waste of time
[15:51] <cjwatson> What about 862167?
[15:52] <tkamppeter> cjwatson, so I will reopen these four bugs (or make cups-filters invalid in them if it has turned out to be not actually cups-filters.
[15:52] <cjwatson> Basically I need a clear statement that all the bugs are either verified or have been made no worse, that being the point of the verification period
[15:52] <cjwatson> This is easy if the report is all green
[15:52] <cjwatson> If that's not the case then the uploader needs to help out by clarifying the situation
[15:55] <tkamppeter> Bug 862167 is a private support bug. It seems that the original reporter of the bug is a support person and not the person who has the problem. And the support person did not forward the question about testing to the customer. I think I make the cups-filter task invalid here, too.
[15:56] <tkamppeter> cjwatson, on none of the bug reports I got an answer that the situation got worse, everyone who answered and was really affected by this bug answered that his problem got solved.
[16:01] <tkamppeter> cjwatson, bug 997728 turned out to be a bug in Acroread and I have marked it invalid for cups-filters earlier.
[16:01] <ubot2> Launchpad bug 997728 in cups-filters "Ubuntu port of acroread degrades images (works on Win7)" [High,Invalid] https://launchpad.net/bugs/997728
[16:02] <cjwatson> right, as I said
[16:02] <cjwatson> OK, it sounds like it's good to copy
[16:09] <tkamppeter> cjwatson, marked cups-filters tasks for Precise in the four mentioned bugs as invalid.
[16:09] <tkamppeter> cjwatson, thanks.
[16:10] <tkamppeter> cjwatson, I will sort out the answers for the CUPS SRU soon. There are also no new regressions, but also bugs which did not get fixed by the SRU (and for which I did the system-config-printer SRU).
[16:11] <cjwatson> those cups-filters tasks were marked Fix Released as a result of accepting the upload into -updates; perhaps you could set them back to Invalid
[16:11] <seb128> @SRU team: could you copy gtk+3.0 as well? the bugs listed are verified and it is in proposed for 9 days
[16:11] <cjwatson> it's better to wait until the copy to -updates is done :)
[16:11] <seb128> it would make room for another upload, I've other fixes I would like to upload
[16:11] <cjwatson> seb128: yeah, it was next on my list ...
[16:11] <seb128> cjwatson, thanks ;-)
[16:12] <tkamppeter> cjwatson, will do, as soon as I get "Fix Released" notifications.
[16:12] <slangasek> cjwatson: bug #863741> looks like we need a no-change rebuild of rpcbind after all to fix this, as even though the priority is bumped in the precise-updates Packages file, apt entirely ignores the second source for the same package and takes the prio info from the first record it finds :P
[16:12] <ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix released] https://launchpad.net/bugs/863741
[16:13] <cjwatson> slangasek: right
[16:13] <cjwatson> irritating
[16:16] <slangasek> cjwatson: I'm wondering if I should upload straight to -updates for this considering it's a no-change rebuild?  Or do you think it's better to go through -proposed anyway just to guard against misbuilds?
[16:19] <cjwatson> slangasek: I think I'd still rather see it go through -proposed with the fixed override and test that that actually fixes the upgrade
[16:19] <slangasek> cjwatson: ok
[16:22] <slangasek> rpcbind uploaded
[16:32] <slangasek> Unable to find rpcbind_0.2.0.orig.tar.gz in upload or distribution.
[16:32]  * slangasek glares at pristine-tar
[16:33]  * xnox pristine-tar glares at bzr-builddeb removing files from the tree before commiting delta and not being able to reconstruct files needed for reconstructing a tarball
[16:35] <slangasek> mm?
[16:35] <slangasek> I haven't seen that one
[16:35] <cjwatson> waitaminute when did *PPH get an API-exported requestDeletion method?!
[16:35] <cjwatson> I was expecting to have to do that
[16:37]  * cjwatson goes to write a client for that to see how well it works
[16:46] <micahg> Laney: infinity: I think we wanted backports to work like Debian experimental in that the backports version is used if it's needed
=== Pici is now known as Guest55530
=== Pici` is now known as Pici
[17:54] <slangasek> well, bug #1002336 is a fun one
[17:54] <ubot2> Launchpad bug 1002336 in smokeqt "SRU tracking bug for KDE SC 4.8.3" [Undecided,Fix released] https://launchpad.net/bugs/1002336
[17:54] <slangasek> ScottK: do those KDE 4.8.3 SRUs need to go all in one batch?
[19:51] <stgraber> good to see the SRU list shrink!
=== yofel_ is now known as yofel
[20:58] <ScottK> slangasek: Looks like your question is OBE now, but there would be some uninstallability in a few cases if they don't go in ~together.
[20:59] <cjwatson> Looks like they all landed in the same publisher run
[20:59] <cjwatson> (So good
[20:59] <cjwatson> )
[21:17] <debfx> isn't 4 days a bit early to move KDE 4.8.3 to -updates?
=== highvolt1ge is now known as highvoltage
[22:34] <slangasek> ScottK: yah... since they looked on review to all be ready to go in, I played it safe and did them in one run :)
[22:34] <slangasek> debfx: 7 day waiting period?
[22:35] <slangasek> debfx: there were a few packages that had been in there 4 or 5 days, but there was nothing to suggest there was actually going to be separate regression-testing for these packages between now and then given that they're comparatively minor components
=== jbicha_ is now known as jbicha