| infinity | ScottK: What will fix x86? A new upload? | 00:45 |
|---|---|---|
| infinity | ScottK: If so, you can just reject the other binaries. | 00:45 |
| infinity | ScottK: Oh, hrm, I wonder why our gcc appears to be upset about -fuse-ld... | 00:50 |
| ScottK | infinity: I think -fuse-ld is fine, it's -fuse-ld=gold that's trouble. | 02:56 |
| ScottK | New upload is on the way. | 02:59 |
| ScottK | Rejected the old one. | 02:59 |
| ScottK | New qt4-x11 on the way. That should be OK to accept once it's built. | 03:02 |
| infinity | ScottK: The whole point of -fuse-ld is to pass =gold. :P | 03:06 |
| 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:07 |
| infinity | doko: Or, you could read up and comment on this, despite the fact that you're sitting next to me. :P | 03:08 |
| doko | infinity, you should use -B/usr/lib/compat-ld/ instead | 03:10 |
| 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. | 03:11 |
| xnox | cjwatson: ok, thanks. =))) quicker debian imports are always good. | 08:05 |
| === NCommand1r is now known as NCommander | ||
| ogra_ | infinity, so whom do i have to talk to about the arm chroots ? | 09:57 |
| ogra_ | (we really need to get the images building and i also want to switch to the new flash-kernel for A1) | 10:00 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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:12 |
| 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. | 10:15 |
| xnox | How often do transition trackers update? | 11:01 |
| cjwatson | Half-hourly IIRC | 11:03 |
| 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:05 |
| * 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:07 |
| xnox | we will get the overview page and the % trackers =)))) | 11:08 |
| xnox | it updated just now. | 11:09 |
| 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:26 |
| * xnox my left hand is faster than my right hand | 11:27 | |
| infinity | No comment. | 11:27 |
| * xnox 'gin' vs 'ing' typpo. | 11:27 | |
| * 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* | 11:28 |
| === ara is now known as Guest64238 | ||
| 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:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| * 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:22 |
| jamespage | xnox, yeah - been working through main first - nearly there - on the last few hard ones at the moment | 13:23 |
| 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:27 |
| ogra_ | pfft, thats less than 1% of the archive | 13:29 |
| 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:44 |
| * xnox sorry no clue | 13:45 | |
| tumbleweed | jamespage: http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-quantal.csv | 13:45 |
| * 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:46 |
| tumbleweed | look at lp:svammel if you want to file bugs / do something with the things programmatically | 13:47 |
| === jbicha is now known as Guest70781 | ||
| 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 | 15:06 |
| === Guest70781 is now known as jbicha_ | ||
| cjwatson | bdmurray: rejecting your duplicate apport sync to precise-updates | 15:24 |
| 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:25 |
| slangasek | so running sru-release puts it in the approval queue (even) if you're not a member of ubuntu-sru? | 15:26 |
| bdmurray | slangasek: yes, clint approved a couple for me yesterday | 15:28 |
| slangasek | ack | 15:28 |
| 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:32 |
| 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:33 |
| xnox | =) | 15:34 |
| cjwatson | not all the cups-filters bugs have been verified, according to the report | 15:34 |
| cjwatson | and I don't see your ptouch-driver upload in the queue | 15:36 |
| 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:37 |
| cjwatson | accepted system-config-printer | 15:38 |
| 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:41 |
| cjwatson | There are four unverified bugs, according to the report | 15:42 |
| knome | skaet, ? :) | 15:43 |
| skaet | knome, hiya | 15:43 |
| skaet | ? | 15:43 |
| knome | hey! may i PM? | 15:43 |
| tkamppeter | cjwatson, forgot the dput for ptouch-driver. Done now. | 15:44 |
| skaet | knome, k | 15:44 |
| tkamppeter | cjwatson, ptouch-driver has arrived now. | 15:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:55 |
| 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. | 15:56 |
| 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:01 |
| cjwatson | right, as I said | 16:02 |
| cjwatson | OK, it sounds like it's good to copy | 16:02 |
| tkamppeter | cjwatson, marked cups-filters tasks for Precise in the four mentioned bugs as invalid. | 16:09 |
| tkamppeter | cjwatson, thanks. | 16:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| cjwatson | slangasek: right | 16:13 |
| cjwatson | irritating | 16:13 |
| 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:16 |
| 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:19 |
| slangasek | rpcbind uploaded | 16:22 |
| slangasek | Unable to find rpcbind_0.2.0.orig.tar.gz in upload or distribution. | 16:32 |
| * slangasek glares at pristine-tar | 16:32 | |
| * 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:33 | |
| 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:35 |
| * cjwatson goes to write a client for that to see how well it works | 16:37 | |
| micahg | Laney: infinity: I think we wanted backports to work like Debian experimental in that the backports version is used if it's needed | 16:46 |
| === Pici is now known as Guest55530 | ||
| === Pici` is now known as Pici | ||
| 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? | 17:54 |
| stgraber | good to see the SRU list shrink! | 19:51 |
| === yofel_ is now known as yofel | ||
| 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:58 |
| cjwatson | Looks like they all landed in the same publisher run | 20:59 |
| cjwatson | (So good | 20:59 |
| cjwatson | ) | 20:59 |
| debfx | isn't 4 days a bit early to move KDE 4.8.3 to -updates? | 21:17 |
| === highvolt1ge is now known as highvoltage | ||
| 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:34 |
| 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 | 22:35 |
| === jbicha_ is now known as jbicha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!