#ubuntu-release 2010-04-19
<slangasek> so... someone's throwing back armel build failures until they stick?
<ScottK> slangasek: lamont threw back the entire stack last night.
<Laney> lamont did a mass give-back las... yeah
<slangasek> it's been more than once
<slangasek> I've gotten two mails each for all my failed uploads in the past two days
<ScottK> Hmmm.  I don't think so.
<ScottK> I only got one.
<slangasek> ah; then maybe a subset
<ScottK> One for the original failure and another for the give back or two extras?
<slangasek> the original failure was months ago - I got two build attempts of, e.g., 'imview' in the past two days
<ScottK> slangasek: Would you please source accept ibid from New.  The LP U/I is being unhelpful.
<slangasek> looking
<slangasek> is it unhappy because 'ibid' is a substring of 'python-pyfribidi'?
<ScottK> I don't think so.
<slangasek> accepted
<ScottK> I get a "you are not allowed here" error.
<slangasek> doh
<ScottK> It happens every now and then, usually for reasons that aren't clear.
<ScottK> One known cause is if a package I try to accept fixes a private bug I don't have access too, but that's not he case ehre.
<ScottK> here even
<slangasek> heh, wacky
<doko_> slangasek: now uploaded all packages which are statically linked according to the package name/description
<slangasek> ah
<ScottK> slangasek: A couple more syncs when you have a moment: http://paste.debian.net/69637/  We also want the new ipplan (0.92a), but I think it's still in incoming (see 565781)
<slangasek> we'll see how many of those we get to; I'll definitely be leaving some space in the build queue for emergency blocker builds
<slangasek> ScottK: ok, will look
<cjwatson> slangasek: yes, both gfxboot-theme-ubuntu and d-i I think
 * cjwatson goes for a late-night poke at those
<slangasek> ta
<cjwatson> "There are 142 file requests on the export queue".  Hmm
<cjwatson> tomorrow morning would be inconvenient, right?
<slangasek> yeah. can you give me instructions I could follow to do it myself tonight?
<cjwatson> nah, I'll just stay up a bit
<cjwatson> not quite sleepy yet anyway
<cjwatson> my scripts are a bit finicky ...
<slangasek> ok
<cjwatson> have been up late looking over the rather ... unusual state of UK politics at the moment :)
<slangasek> xserver-xorg-video-geode reviewed, follow-up question sent to Q-FUNK
<slangasek> oh?  what's the unusual part?
<cjwatson> third party (the one I happen to support) surging by something like 15% in at least some polls
<slangasek> oh, huh
<cjwatson> less in others but it appears to be statistically significant across the board
<cjwatson> interesting times ahead given that we have an election right before UDS :)
<slangasek> hurray for free TV exposure
<cjwatson> which I'll have to proxy-vote in, boo
<cjwatson> ah, here come the translation tarball mails
<cjwatson> haven't made any traction yet on sbeattie's worrying partitioning bug, btw - I'll have to attack that tomorrow and possibly fix it post-rc :-/
<cjwatson> I followed through all the maths in the code and couldn't find an error
 * slangasek nods
<cjwatson> oh, meep, and I promised Mark I'd change the CD boot splash branding
<cjwatson> so I mentioned in the release meeting that the design team had asked to blank the splash screen, as they were upset about the distortion evident on some systems (gfxboot doesn't know about widescreen etc.)
<cjwatson> I was alarmed about getting rid of the bottom icons (the rebus for "press a key") and clarified with Mark on Friday evening
<slangasek> "blank the splash screen" - urk, hadn't understood that from the meeting
<cjwatson> he wants the logo gone from the CD boot splash (i.e. gfxboot - plymouth stays as it is) but is fine with the icons remaining
<slangasek> ok
<cjwatson> I'll mail ubuntu-doc, they're bound to have screenshotted it but it should be very easy to redo
<slangasek> yes, with gimp and the rectangle tool ;)
<cjwatson> not really happy about this being announced two weweks out, but at least it is easy to deal with
<cjwatson> ooh, cute transliteration of Xubuntu in Bulgarian
<cjwatson> -msgstr "^ÐÐ½ÑÑÐ°Ð»Ð¸ÑÐ°Ð½Ðµ Ð½Ð° Xubuntu"
<cjwatson> +msgstr "^ÐÐ½ÑÑÐ°Ð»Ð¸ÑÐ°Ð½Ðµ Ð½Ð° ÐÑÑÐ±ÑÐ½ÑÑ"
<slangasek> Ksubuntu!
<cjwatson> nice digraph
<slangasek> they could've just gone with Chubuntu... :)
<ScottK> You could ask Mark to review the time zone map again if you're short on last minute crises.
<ScottK> ;-)
<cjwatson> argh
 * cjwatson remembers he needs to update the d-i translations first, *then* regenerate gfxboot-theme-ubuntu's font
<cjwatson> ordering ...
<cjwatson> one of these days I'll document all this
 * cjwatson wonders if he should remove the Kubuntu splash too
<cjwatson> I'm thinking just the one that was explicitly requested, i.e. Ubuntu
<cjwatson> but that requires a g-t-u code change
<ScottK> There's an open bug about updating it for Kubuntu to match the new branding, so going away would solve that.
<cjwatson> Riddell already dealt with that bug though
<ScottK> Oh, OK.
<Riddell> cjwatson: the Kubuntu splash is different though because we still have the menu items showing
<cjwatson> oh that's right, you aren't using the hidden-timeout mode
<cjwatson> Mythbuntu is though
<cjwatson> I can probably come up with a plan
<Riddell> consulting on hidden-timeout with seele is still on my todo, guess it'll roll over to UDS
<cjwatson> no rush from my end
<cjwatson> ok, that worked fine
<cjwatson> Riddell: to some extent, making it not a crazy hack for maverick is on hold until I decide whether to throw the whole lot away and move to grub
<cjwatson> slangasek: I've uploaded all the translation changes etc.; I've also committed and deployed the debian-cd changes for the CD splash thing on the basis that they're a no-op without gfxboot-theme-ubuntu 0.9.9
<cjwatson> slangasek: I'm going to go to bed shortly, so if you need to back anything out or fix anything or whatever, everything's in bzr
 * cjwatson looks at his mirror job and wonders idly if mrpt-doc is really useful enough to justify its enormous size
<cjwatson> sort of looks like a "Debian maintainer has too much bandwidth" case
<cjwatson> anyone know what happened to language-pack-gv{,-base}, and why the gnome language packs for gv exist without them?
<cjwatson> not in NEW ...
<slangasek> nope - just pinged ArneGoetje and pitti on -devel about it
<slangasek> cjwatson: what do these build/Makefile changes have to do with amd64/netboot-xen?  looks like a miscommit to me...
<slangasek> cjwatson: n/m, found
<stgraber> slangasek: Edubuntu is failing to build due to issues with the -gv langpacks. Poked ArneGoetje about it and it seems like the language pack itself was removed from the archive but not the -gnome and -support with both still depending on the langpack and so making our build to fail.
<stgraber> (as we install all -gnome, -kde, -base and -support in the live environment)
<slangasek> stgraber: already sorted on #ubuntu-devel; next builds will succeed
<stgraber> ok ;) I guess my laptop isn't up to date then as it still shows -support and -gnome in the archive :)
<stgraber> slangasek: can you trigger a rebuild once the archive is clean, either later tonight or tomorrow as our 20100419 build already failed ?
<slangasek> -gnome was removed 20 minutes ago, so the change won't be published for another hour; -support only suggests: the language pack, not depends
<slangasek> "later tonight", yes - I'll be starting the RC mastering tonight
<stgraber> great
<stgraber> I guess langpacks really were the biggest source of build failure for Edubuntu this cycle (though shortly followed by my LTSP live environment ;)). Seems like it's hard to have all the langpacks installed at the same time ...
<ScottK> slangasek: Next layer of perl MIR bugs is done.  Would you please pre-promote libexception-class-perl libb-keywords-per perltidy libreadonly-perl libreadonly-xs-perl libpod-spell-perl libfile-which-perl libstring-format-perl libfile-homedir-perl
<slangasek> ScottK: done
<ScottK> Thanks.
<ScottK> We'll know in ~70 minutes if that was it.
<ScottK> Every single one of that batch had an existing MIR that just had to be resurrected.
<slangasek> convenient
<ScottK> Yep
<ScottK> slangasek: Two more under that stuck.  MIRs resurrected for libclass-data-inheritable-perl libdevel-stacktrace-perl - would you please pre-promote those too?
<slangasek> done
<ScottK> Thanks.  With that, I think I'm off to bed.
<slangasek> ok, 'night
<slangasek> doko__: are syncs to the partner repo actually possible?
<pitti> ScottK: ugh, so many new perl MIRs? the fun thing is, you submitted a ton of MIRs which aren't necessary according to http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, but c-m has two perl modules which don't have MIRs..
<ara> morning all
<pitti> hey ara, how are you?
<ara> hey pitti, a bit sleepy, but doing fine :-)
<ara> pitti, yourself?
<pitti> ara: I'm great, thanks; had a really nice weekend
<ara> pitti, nice :)
<pitti> go-kart race and big party on Saturday, and enjoying the nice sun yesterday
<ara> pitti, wow, it sounds like a really nice weekend
<slangasek> pitti: they're all necessary, component-mismatches just doesn't show them because I've been pre-promoting in order to get builds done
<pitti> slangasek: ah, thanks
<slangasek> and it looks like we're *still* missing two more, for libperl-critic-perl build-deps, sigh
<pitti> slangasek: I just added tasks for them
<slangasek> cheers
<pitti> I'll review them together with the other bunch
<slangasek> ScottK: did you find out what we're meant to do with kde-l10n-sv?
<slangasek> FWIW, ISO mastering will be ready to start after the next publishing cycle (had to fix a d-i FTBFS on i386, I had demoted -generic-pae udebs because of component-mismatches, oops)
<pitti> slangasek: the -gv langpacks are sorted out now?
<slangasek> yep, seems they were empty - removed at ArneGoetje's request
<slangasek> we really ought to have a mountall upload for bug #553290 before RC, but a) we need to back out the change for bug #559761 from bzr unless Keybuk has come up with a fix for the bug in my plymouth patch that this tickles, b) I don't know if he's gotten any other feedback on his ppa test except for mine, or if he's expecting any
<ubottu> Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Fix committed] https://launchpad.net/bugs/553290
<ubottu> Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix committed] https://launchpad.net/bugs/559761
<slangasek> pitti: what's your gut feeling on taking ttf-takao-pgothic in for RC?  I can have it uploaded within the hour, if you're willing to push it through NEW
<pitti> slangasek: I thought that would also require a package split in ttf-vlgothic?
<pitti> slangasek: I'm fine for a quick NEWing if you still want to push it through
<slangasek> pitti: ttf-vlgothic is a different font; takao-gothic is the new one that ArneGoetje says we should be using in its place
<pitti> ah, right
<pitti> slangasek: that'd be great, this would complete this bug/spec
<slangasek> pitti: ttf-takao uploaded
<pitti> slangasek: ok, should hit the queue in 2 mins, will review then
<slangasek> if we do take the ttf-takao switch, that means another round of metapackage uploads, which "buys" us another publishing cycle before ISO mastering begins
<slangasek> so I'm going to look at getting mountall fixed in that window
<slangasek> pitti: and the vlgothic -> takao-pgothic switch saves us 600k packed, 1.5M unpacked; which appears to be enough to let us seed ttf-khmeros-core (220k), and fully complete the spec.  Is that ok with you?
 * ogra wonders why his ubiquity changes dont show up in the changelog for 2.2.18
<ogra> ugh, they dont even show up in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/changes
 * ogra wonders why ... i'm sure i pushed
<ogra> argh ... /me glares at https://code.edge.launchpad.net/~ogra/ubiquity/trunk and curses
<ogra> oh noes ... i pushed to an old branch
<ogra> slangasek, i'm ashamed to ask, but is there any chance to get http://bazaar.launchpad.net/~ogra/ubiquity/trunk/revision/4081 merged before release ?
<pitti> slangasek: absolutely, yes
 * ogra feels really dumb now
<pitti> slangasek: ttf-takao source-NEWed
<slangasek> ogra: ehm, so current ubiquity can't actually install omap?
 * pitti will watch builds and binary-NEW
<ogra> slangasek, yes, d-i should be able to though since the last rebuild
<ogra> (havent tested yet)
<slangasek> ogra: ok; please commit that change to the right branch, and upload it now
<ogra> slangasek, thanks a lot ... thats really embarassing
<slangasek> "now" meaning "within the next 20 minutes"
<ogra> yes, ding it now
<ogra> *doing
<ogra> sigh, if LP would stop timing out on me that would help
<slangasek> pitti: thanks for the source NEW - I've also uploaded mountall, the changes are Keybuk's and I've already reviewed and tested them myself, but I would prefer another set of eyeballs if you don't mind
<ogra> slangasek, meh, i know why my branch setup was wrong, i apparently cant upload to ubiquity trunk (though i'm in the installer team for d-i casper etc)
<slangasek> ah
 * ogra wonders ifg cjwatson is awake to approve him for the right team
<slangasek> in the meantime, please upload
<slangasek> and push a merge request in parallel
<ogra> ok, i need to fiddles with the changelog first, one sec.
<ogra> -s
<ogra> crap ... there is an additional change from ev in the trunk branch
<ogra> for bug #563309 apparently
<ubottu> Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Fix committed] https://launchpad.net/bugs/563309
<ogra> i guess i need to talk to ev first :/
<ogra> looks safe but i dont want to upload without his approval
<slangasek> please just upload your fix, then
<pitti> slangasek: takao binNEWed (to main)
<slangasek> we can sort out the paperwork afterwards
<slangasek> pitti: thanks
<ogra> ok
<pitti> slangasek: heh, you beat me to committing the seed change by a couple of secs :)
<slangasek> whoo I won \o/
<slangasek> ok, afk for a bit
<ogra> slangasek, uploaded
<slangasek> pitti: do you think you can review mountall?
<slangasek> I have the publisher on manual so we can grab the rest of these fixes in a single publisher run
<pitti> slangasek: I don't quite understand the "Don't run fsck while there's an uncleared error on the filesystem" part
<pitti> are those uncleared errors only set by fsck itself? (i. e. it runs the first time, but then avoids a loop)
<pitti> i. e. would an unclean shutdown not count as an "uncleared error"?
<slangasek> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/501801/comments/8 is the explanation, I believe
<ubottu> Launchpad bug 501801 in mountall "Infinite-loops in fsck when booting with damaged /" [High,Fix committed]
<ev> pitti, slangasek: I've uploaded a fix for bug 563309 as ubiquity 2.2.19 in case we have enough time to squeeze it in.
<ubottu> Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Fix committed] https://launchpad.net/bugs/563309
<slangasek> ev: midair collision - ogra already uploaded a 2.2.19 containing the changes to support armel+omap, but he didn't have commit rights on the branch and wasn't sure enough of your change to upload it himself
<slangasek> ev: can you merge and reupload as .20?
<ev> slangasek: will do
<slangasek> blah, metapackage updates take too long
<wgrant> slangasek: Why? because the task changes take two cycles to propogate?
<pitti> slangasek: so if you are sure about the fsck thing, it looks fine to me otherwise
<slangasek> wgrant: because downloading package files from the canonical<heehee> source takes too long
<slangasek> pitti: I haven't personally vetted that code, but Keybuk is confident in it, and user feedback indicates that it fixes the worst problems...
<pitti> ok, thanks
<pitti> slangasek: I can take a -meta update/upload if you want me to?
<pitti> slangasek: which one are you currently building?
<slangasek> pitti: I have all but one of them done now
<slangasek> (also, I'm hand-hacking a bit since ttf-takao-pgothic binaries aren't really in the archive yet)
 * pitti thought ttf-takao would need to get published first
<pitti> ah, heh :)
<ev> slangasek: done
<pitti> slangasek: for the "disable file a bug menu entry", "disable apport" and "disable kerneloops" changes, should we do them after RC? or for RC? (in the past we did them right after)
<slangasek> pitti: I seem to always be eager to change apport before you, both disabling and enabling. :)  I'm ok with doing it after RC if you think that's best
<pitti> slangasek: oh, I'm fine with doing the uploads now
<pitti> we have enough crash reports now, anyway :)
<pitti> in fact I'd prefer disabling it in the RC as well
<pitti> slangasek: launchpad-integration change is uploaded now; having that in the RC would be nice
<slangasek> ok
<slangasek> I'll review that and ubiquity, you can review *-meta :)
<pitti> since that's the first time that we do that change
<pitti> ack
 * pitti prepares apport and kerneloops uploads
<pitti> slangasek: apport and kerneloops uploaded
<slangasek> pitti: you say this lpi change isn't one we've made previously at release?  Do we have to worry about this invalidating documentations?
<slangasek> -s
 * pitti checks with mdke
<ev> thanks!
<slangasek> netbook-meta is the last
<pitti> I'm at it
<james_w> I'm on a-a duty today, what is it worth me looking at?
<pitti> oh, NBS already looks quite good
<pitti> james_w: if you have some minutes, getting that to 0 would be awesome
<slangasek> james_w: there are some sourceful new packages that I guess need to be decided
<james_w> pitti: doko says he is watching the java one, and I can't get a sensible answer on how to handle sugar
<slangasek> james_w: and components-mismatches still has some stuff that needs hunted down & beaten with the MIR-stick
<james_w> do we want any syncs today?
<pitti> james_w: it looks like sugar is at 0.88 now?
<james_w> pitti: yeah, but due to something to do with xpcom they couldn't upload the 0.88 browser, so that's stuck at 0.86
<cjwatson> so what's the current vs. desired state of ubiquity?
 * cjwatson has read scrollback
<slangasek> equal
<slangasek> at least AFAIK :)
<cjwatson> ah, I missed the bit where ev uploaded
<cjwatson> good
<cjwatson> ev: except bzr doesn't reflect this yet ... missing debcommit -r push?
<ev> cjwatson: fixed
<pitti> slangasek: so, after the ubiquity/meta/apport/etc. bits are in, we'll build images for testing; after that, should we review/accept further safe and small fixes for tomorrow's dailies, or do you plan that today's images are the RC ones? (barring critical installer fixes, etc.)
<slangasek> hmm, seems that ubuntu-docs normally takes >2h to build, boo
<slangasek> in that case, we should do a publisher run as soon as the -meta builds are up, then another when ubuntu-docs is up
<pitti> let's hope that the current security build isn't OO.o :)
<slangasek> pitti: I prefer that today's be the RC ones, barring critical fixes
<pitti> slangasek: ack; so should we discourage people from uploading stuff now?
<pitti> there's still a bunch of fixes; some of them  might go in right after RC, of course
 * pitti refers to the recent dbusmenu/indicator uploads, and similar
<slangasek> cf. my last message on #-devel
<pitti> ah
<slangasek> I certainly prefer that anything we *know* is going in be done before RC
<slangasek> and we have time for these, they'll still get done building before ubuntu-docs AFAICS
<slangasek> I'm reviewing indicator-messages, if you or cjwatson wants to take libdbusmenu
<mvo> what are the chances for getting software-center 2.0.2 in ? a small change, but helps performance a lot
<mvo> ups
<slangasek> mvo: 100% ;)
<mvo> mail old, nevermind, its in already
<mvo> lalala
<pitti> slangasek: taking libdbusmenu
 * mvo takes a cup of tea 
<james_w> http://paste.ubuntu.com/418478/ are todays syncs. the only one to main is the first, which apparently brings a ftbfs fix, ok to sync? (they all have ffe approval)
<pitti> james_w: hm, libgda4 is 4.0.4 -> 4.0.8
<pitti> libgda4 isn't on the CD images, but certainly on the DVD
<james_w> and apparently builds a gir package now
<pitti> james_w: was that the "would be nice to get back in sync" category, or does it fix critical bugs?
<james_w> bug 537379
<ubottu> Launchpad bug 537379 in libgda4 "Sync libgda4 4.0.8-1 (main) from Debian unstable (main)" [High,New] https://launchpad.net/bugs/537379
<james_w> claims that it is important
<james_w> oh, I've just seen the instruction to wait :-/
<james_w> and pychecker was actually in main before it was removed
<pitti> ^ jockey was a trivial and obvious patch, accepted
<slangasek> hmm, think I beat you to that one :)
<pitti> slangasek: ah, seems you did :)
<ogra> ev, cjwatson sorry for the mess, i wasnt aware i had no commit rights to ubiquity/trunk and didnt check where my bzr push went last week
<ev> ogra: no worries at all
<ogra> i was under the assumption that being allowed to push to d-i would also allow me to push to ubiquity ... but that seem to be different teams
<ogra> (and i forgot that i had set up the ubiquity branch differently last year)
<ev> yeah, d-i is maintained by core-dev
<ogra> right
<ev> at any rate, you're in ~ubuntu-installer now :)
<ogra> i'll do better next time, now that i know that :)
<ogra> yeah, thaks a lot :)
<ogra> *thanks too
<ev> sure thing
<slangasek> might be useful if someone could bump build scores on xubuntu-meta
<pitti> doing
<slangasek> well, that took a bit longer than intended, but metapackages should all be accepted in ~10 min (for amd64/armel/i386), then I'll fire off the publisher
<slangasek> publisher running
<doko__> slangasek: yes, cjwatson did sync it last time
<slangasek> doko__: I thought that when he synced it, he broke the archive... :)
<slangasek> cjwatson: ^^ does syncing to partner work now?
<cjwatson> err, I had to file several bugs as a result and it was generally a right mess
<cjwatson> we sort of got it working eventually
<cjwatson> I think at least some of the bugs have been fixed
<cjwatson> but I would not recommend trying it outside of a relaxed environment, i.e. not 1.5 weeks before release :)
<cjwatson> best just upload the same source package
<doko__> ok, I'll upload it manually
<ogra> slangasek, bug 563618 has properly tested code now that actually sets the rtc/system clock on boot to work around the infinite reboots with no rtc battery
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<slangasek> ogra: ok; I'll take a look later today
<ogra> sweet, thanks
<ogra> indeed you can only set the clock to rubbish anyway, but with that script we set it to at least usable rubbish :)
<ogra> ted tso agreed to fix fsck for us to completely ignore timestamps if teh e2fsck.conf override is set but that will surely take until maverick or maverick+1
<slangasek> *-meta published.  Waiting for synaptic to build before publishing the tasks and starting the ISOs
<slangasek> as well as ubiquity/armel, it seems
<ogra> sweet !
 * ogra is just testing netinst d-i ... bein very excited 
<ogra> *being
<slangasek> aah!  why did the OOo/armel build just restart?
<slangasek> lamont: is OOo killing armel buildds?
<pitti> the buildd?
<slangasek> now on satinash; but I thought that's where it was before, too
<lamont> slangasek: crabapple was not the build
<lamont> hubbard is another question
 * ogra sees a lot of 404's for security.ubuntu.com in his installation test log, isnt it time we enable that ? 
<pitti> ogra: they should have existed for months
<pitti> and in fact they did
<pitti> (with empty Packages.gz, of course)
<ogra> weird, probably not for armel
<pitti> right, just i386/amd64
<ogra> ah
<pitti> http://security.ubuntu.com/ubuntu/dists/lucid-security/main/
<pitti> ogra: seems they are on http://ports.ubuntu.com/dists/lucid-security/main/
<pitti> for armel
<ogra> ouch
<ogra> then our sources.lists are wrong
<ogra> probably on all arches, i havent done any non-omap tests for about four weeks now
<lamont> slangasek: hubbard was last seen building wordnet 1:3.0-22
<slangasek> pitti: ehm, that seems pretty critical to have fixed for RC
<cjwatson> pretty sure that apt-setup selects ports.ubuntu.com on non-x86 architectures
<cjwatson> for security
<cjwatson> if it doesn't, I need an installation log with DEBCONF_DEBUG=developer
<cjwatson> ogra: ^-
<ogra> cjwatson, will do  one after i fifnshed this install test (and actually check what ends up in the installed system)
<ogra> *finished
<hyperair> slangasek: got a minute? Bug #564506
<ubottu> Launchpad bug 564506 in banshee-community-extensions "libappindicator-cil-dev's .pc file points to the wrong place" [Undecided,Fix released] https://launchpad.net/bugs/564506
<hyperair> it's got a binary rename, but it's pretty low-impact, considering the only rdep of the renamed binary currently FTBFS, and is waiting for the new name.
<hyperair> not to mention that the current version of the said binary package in the archive is broken pretty spectacularly.
<slangasek> hyperair: why do the -cil and -cil-dev packages not have consistent names?
<doko__> any reason not to accept llvm-gcc-4.2? only builds on i386/amd64, 20min build time
<slangasek> hyperair: and why was the banshee-community-extensions package uploaded to build-depend on packages that haven't been accepted yet for lucid and might yet not be...?
<slangasek> doko__: no specific reason, just haven't looked yet
<hyperair> slangasek: because the previous version didn't build either.
<hyperair> slangasek: and because the previous version of indicator-application was broken pretty spectacularly
<hyperair> slangasek: as for the naming, the -cil version contains the ABI version, the -cil-dev contains the API version
<hyperair> slangasek: it's standard across all the CLI libraries in the archive.
<slangasek> well, blah
<slangasek> it's also not, AFAICS, relevant to the problem that's supposed to be getting solved in that bug
<hyperair> slangasek: er. the bug wasn't complete -- there were more problems than i realized.
<hyperair> slangasek: one of the duplicates complains about the library not getting into the GAC, for example.
<slangasek> the package may have problems, but I don't see how the package renames have anything to do with fixing the critical issues
<hyperair> slangasek: well it was a CLI policy violation.
<hyperair> slangasek: directhex decided to fix everything altogether in the patch.
<directhex> moo?
<hyperair> yay directhex
<slangasek> hyperair, directhex: I'd like to see an indicator-application upload with just the minimal changes necessary to make the package functional; at this stage I could care less about whether it conforms with policies on package names
<slangasek> that will mean another upload of banshee-community-extensions to fix the build-deps back
 * hyperair sighs
<hyperair> fine
<hyperair> slangasek: but is there a reason to be this resistant about a binary rename of a package that has no other rdeps?
<slangasek> hyperair: because packages from this source are on the CDs, and the window for changes to those packages is much smaller than for universe
<hyperair> ah right. the CDs. i forgot.
<ogra> ogra@beagle:~$ cat /etc/apt/sources.list|grep security|grep main
<ogra> deb http://security.ubuntu.com/ubuntu lucid-security main restricted
<ogra> deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted
<ogra> hmm
 * ogra does an install with DEBCONF_DEBUG=developer
<directhex> there are 4 major bugs in the package, ignoring the policy problems - everything in debian/rules , and the pcfile patch
<directhex> obviously the values in the patch i sent would need to be reverted back to incorrect locations, if the package naming is ruled out
<slangasek> directhex: do you think the risk is greater if making those location reverts?
<directhex> slangasek, i think the tying together of API, ABI, install location and package names, within policy, was as a direct result of pain elsewhere when dealing with partial changes, and leading to big long painful Conflicts: and Replaces: dances
<directhex> slangasek, my personal stance with canonical's bindings has been to go for unstable api/abi packaging, which is simpler & unversioned throughout, and a "safer" option for libs in flux. but i was overruled with libu1, and i simply play the hand i'm dealt
<directhex> slangasek, the only changes which really have any potential to impact the packages on the CD are the changes to debian/rules, and those need to happen ANYWAY
<directhex> (hint: as i understand CDBS, the one bit which *does* change the CD contents is the DEB_DH_MAKESHLIBS_ARGS_libappindicator0 which should really be there anyway)
<slangasek> directhex: OTOH, your patch *adds* the Conflicts/Replaces, which should be a one-time thing and shouldn't be any easier or harder if we do it now, or in maverick
<directhex> true. question is whether it's ever likely to need backporting
<directhex> since backporting from valid to invalid policy will add burden
<slangasek> the shlibdeps change may fix a bug, I don't know; if so, it's not a particularly serious bug, but I'll allow that change either way because the impact of getting it wrong is also roughly 0
<hyperair> makeshlibs, not shlibdeps
<slangasek> yes
<ogra> wohoo ... flash-kernel works in d-i
<directhex> hyperair, do you have time to strip out the renames from my debdiff? i need to pop to the bank
<slangasek> directhex, hyperair: alternatively, if you've extensively tested this out-of-archive and can assure me that there will be *zero* need for further uploads of indicator-application for lucid, I can see my way to taking the rename
<hyperair> i'm not sure about *zero* need for further uploads.. we'd have to ask tedg about whether he has any further issues.
<directhex> i tested the lib installed and could be built against as expected, i didn't rebuild b-c-e but can do that now
<directhex> hm...  Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998)
<directhex> there we go, picking up the dependencies properly now, that's a good thing
<directhex> yep, appindicator in banshee, working fine. just how nature intended
<slangasek> directhex, hyperair: so you're happy that if I accept this, any new issues that turn up are ones we'll be able to live with for release?
<hyperair> slangasek: yes.
<slangasek> if so, please get it uploaded and I'll accept it after RC
<hyperair> seb128: ^^
<directhex> hang on, i just want to double-check apt's handling of the conflicts
<directhex> yep, looks fine
<slangasek> cjwatson, pitti: so my rune for triggering ISO builds contingent on a package publishing has been properly scriptified now - cdimage/bin/wait-for-package
<slangasek> (could use better documentation, still...)
<pitti> ah, wait-for-package <package>_<version>
<pitti> sweet, thanks
<slangasek> yeah, it really just passes that to zgrep
<stgraber> slangasek: did you trigger that new edubuntu build ?
<cjwatson> slangasek: neat
<slangasek> stgraber: I'm doing the big batch of ISO builds now; it'll be a few hours yet before it reaches edubuntu in the queue
<cjwatson> slangasek: could do with mirroring build-image-set's semaphore handling around anonftpsync though - as it is it looks unsafe against parallel builds
<cjwatson> maybe even just bail out if it ever notices that another build is running
<slangasek> hmm
<slangasek> isn't that a problem in anonftpsync itself, then?
<cjwatson> depends where you think the locking ought to live :)
<slangasek> right :)
<cjwatson> at the moment, the practice is to do it outside anonftpsync
<slangasek> ok
<cjwatson> I don't object to moving it if that makes more sense; I think I did it outside because I picked up anonftpsync from elsewhere
<cjwatson> so I think I was regarding it as basically a contributed tool
<slangasek> build-image-set's semaphore still has the bug where a universe sync and a main sync in parallel can leave an inconsistent universe tree, right?
<cjwatson> there's only one lock - I think it's more complicated than that but I forget the details
<cjwatson> sorry :(
<slangasek> I think it's: main sync grabs the lock; universe build sees the lock so assumes it doesn't need to sync anything; lock clears, main is up-to-date but the Releases file isn't
<cjwatson> that does sound plausible
<slangasek> xserver-xorg-input-vmmouse> reviewed, if we have to respin RC for any reason, please accept this
<slangasek> james_w: do you have any more information about this sugar xpcom issue?  if the new version has an unsupportable xulrunner dep, then I guess the thing to do is to just drop the old package
<james_w> slangasek: I don't. lfaroane and ChrisCoulson know what's going on I think
<slangasek> ok
<ogra> cjwatson, bug 566639
<ubottu> Launchpad bug 566639 in apt-setup "omap install ends up with security.ubuntu.com urls in sources.list after install" [Undecided,New] https://launchpad.net/bugs/566639
<slangasek> lamont: what's the state of the acorn?
<slangasek> ogra: is it only reproducible with omap?
<lamont> slangasek: theoretically, it's full of love for livecd builds
<ogra> slangasek, i'll ask one of my team members to try to reproduce under imx51/dove
<slangasek> lamont: so should I point some of these RC builds over there?
<lamont> slangasek: is there something I should look at on it?
<lamont> slangasek: feel free
<lamont> it's all yours now
<lamont> well, I do plan to abuse it a little bit for a bootstrap of yet another universe package, but...
<lamont> shouldn't be any real impact to livecd builds
<jdstrand> I'm wondering if bug #521298 should really remain unmilestoned with no Importance set. so far 62 people have said they are affected by the bug...
<ubottu> Launchpad bug 521298 in plymouth "could not write byte broken pipe" [Undecided,Triaged] https://launchpad.net/bugs/521298
<ogra> slangasek, not reproducable on imx51 apparently
<slangasek> ogra: were both install tests done with the same kind of media?
<ogra> you mean imx vs omap ?
<ogra> i dont think so though it shows up for me in both omap installs (to SD as well as to USB) while imx can only install to USB
<slangasek> I mean the /install /media
<ogra> ah, i dont hink the guys actually test d-i based installs
<ogra> plars, ^^^ ?
<ogra> and even more rarely netinst images
<plars> ogra: the netinst images usually get tested at each milestone, but not the d-i (currently server) images
<ogra> ah
<slangasek> yes, these are variables to be eliminated before drawing conclusions about it not being reproducible on imx51
<ogra> (netinst is d-i too :) )
<slangasek> plars: tested, but does this bug manifest w/ netinst?
<plars> ogra: the install I'm looking at where I don't see the bug is netbook install, not netinst
<ogra> slangasek, well, i'll test -server now and once omap netbook is respun i'll test that one too and comment on the bug
<ogra> so i'll at least know if the install media has any influence ... but i rather suspect that apt-setup is missing some kind of subarch thing
<ogra> oh, heh
<ogra> # Awful Ubuntu-specific hack. *-security suites for ports architectures
<ogra> # aren't available on security.ubuntu.com, only on ports.ubuntu.com
<ogra> ....
<ogra>         db_get mirror/$protocol/hostname
<ogra>         if [ "$RET" = ports.ubuntu.com ]; then
<ogra> ...
<ogra> i was using my local mirror for the netinst
<ogra> so thats just a weakness in the matching
 * ogra comments in the bug
<slangasek> ah
<ogra> i guess that code should better use archdetect but i'm not sure what drawbacks that would imply
<jdstrand> 08:37 < jdstrand> I'm wondering if bug #521298 should really remain unmilestoned with no Importance set. so far 62 people have said they are affected by the bug...
<ubottu> Launchpad bug 521298 in plymouth "could not write byte broken pipe" [Undecided,Triaged] https://launchpad.net/bugs/521298
<jdstrand> slangasek: this was recently moved back to plymouth ^
<slangasek> jdstrand: I'm afraid I have no clue about that bug; Keybuk marked it 'triaged', but hasn't explained what the bug is, so there's only value in milestoning it if he's going to have time to work on it
 * ogra just saw the too on his beagle install 
<jdstrand> slangasek: perhaps, but I can tell you from first hand experience that it makes the boot experience look very unprofessional
 * ogra clocks the me too link
<ogra> *clicks even
<ogra> jdstrand, ++
<ogra> i thought it was armel specific since i hadnt seen it before
<jdstrand> ogra: I think it is anything that uses the plymouth text theme
<ogra> yeah
<jdstrand> I've seen it on at least 2 i386 boxes
<ogra> i dont run x86 boxes with text theme anywhere that would indeed explain it
<jdstrand> I'm blessed with old hardware :)
<ogra> heh, i'm cursed with new but powerless ARM hardware :)
<jdstrand> heheh
<slangasek> jdstrand: oh; can you put that in the bug description/title that it's easily reproducible with the text theme?  If I can reproduce it, maybe we can get some traction on it for release, yes
<jdstrand> slangasek: ok
<cjwatson> slangasek: I can reproduce it in a VM any time, but I have not been able to get any traction on stracing it
<cjwatson> slangasek: i.e. when I tried to strace plymouthd to find out if that was what was causing it, boot hung
<cjwatson> slangasek: if you'd like somebody with some basic familiarity with plymouth to be teleoperated, I can oblige
<slangasek> heh, ok
<cjwatson> slangasek: but FWIW all I did was a server install in kvm
<cjwatson> it doesn't quite reproduce every time, but often enough (at least one in two for me)
<jdstrand> interesting, latest plymouth on my T42 (ie, one of the machines that I've seen the bug on), recently started using plymouth-logo, with less than desirable results: number of colors seems to have defaulted to something far too low-- the 'fade in' of the logo is all wrong (bright greens, etc). shutdown has a similar but different look...
<slangasek> jdstrand: do you have the wrong version of the plymouth-theme-ubuntu-logo package installed?
<jdstrand> slangasek: I just dist-upgraded, let me get the version
<jdstrand> 0.8.2-2
<slangasek> hmm
<jdstrand> slangasek: ^ that is true for all packages seen with 'dpkg -l|grep plymouth'
<jdstrand> slangasek: http://paste.ubuntu.com/418633/
<slangasek> jdstrand: what's cat /proc/fb?
<jdstrand> should be radeonfb... let me check
<jdstrand> $ cat /proc/fb
<jdstrand> 0 radeondrmfb
<jdstrand> slangasek: you may recall that this was the system that has 32MB of ram on a radeon 7500, and the text theme was the default for a while
<slangasek> jdstrand: that'll be a kernel bug, then
<slangasek> er
<slangasek> and indeed, it'll be a new kernel bug, then
<jdstrand> it now switched over to logo
<jdstrand> for a second before gdm comes up (X starting I guess), it looks pretty
<slangasek> bug #564471
<ubottu> Launchpad bug 564471 in linux "Lucid: garbled video at boot on IBM X31 (radeon 7000)" [Undecided,New] https://launchpad.net/bugs/564471
 * ogra wonders if during initramfs it possibly overrides with vga16fb
<jdstrand> slangasek: that is it exactly-- and that is true on boot and shutdown (unsurprisingly)
<slangasek> jdstrand: confirm it, pester the kernel team? :)
<jdstrand> slangasek: though, I need KMS on this laptop (as you may also recall ;)
<jdstrand> apw: fyi ^ (bug #564471)
<ubottu> Launchpad bug 564471 in linux "Lucid: garbled video at boot on radeon 7xxx cards" [Undecided,New] https://launchpad.net/bugs/564471
<apw> slangasek, a new kernel bug ... we didn't enable kms on anything recently that i know of?
<slangasek> apw: new relative to Apr 2, I believe
<apw> the bug says it was the removal of 915.modeset=1 was the reason
<slangasek> apw: not bug #564471
<ubottu> Launchpad bug 564471 in linux "Lucid: garbled video at boot on IBM X31 (radeon 7000)" [Undecided,New] https://launchpad.net/bugs/564471
<jdstrand> that would be odd-- 915 is intel-- these are radeon
<apw> from the /etc/modprobe.d/radeon-kms.conf ...
<apw> sorry radeon.modeset=1
<apw> right file, wrong option name
<apw> but in theory all we did was went from 'enabled' to 'enabled' ...
<apw> given its reported enabled
<jdstrand> (please keep it enabled for my radeon 7500 ;)
<slangasek> apw: oh; ignore that bit of the bug description (or edit away, if you like) - I don't think the regression that user saw has anything at all to do with radeon-kms.conf, they probably also rebooted to a new kernel at the same time and didn't notice
<jdstrand> slangasek: I can say that a couple (few?) weeks ago we saw in bug #554143 that it was plymouth's detection that downgraded the 7500 to the text theme
<ubottu> Launchpad bug 554143 in plymouth "text logo theme used instead of graphical with radeon 7500 (single video output, pseudocolor fb)" [Medium,Triaged] https://launchpad.net/bugs/554143
<apw> if anything the bug comments imply we now enable kms where we did not before, or plymouth did not use it
<slangasek> yeah
<slangasek> jdstrand: plymouth hasn't gained any support for 16-bit framebuffers in the meantime
<apw> hrm, does that mean that plymouth is miss useing the framebuffer
<jdstrand> slangasek: yeah, which is why I was surprised to see a presumably 24/32 bit image shoved into the 16 bit color scheme
<slangasek> so if it's now showing up with the graphical splash, either the kernel is now exporting a truecolor fb, or it's writing to a vgafb; and cat /proc/fb kinda rules out the latter
<slangasek> apw: no, it means the framebuffer is wrong ;)
<apw> jdstrand, so i need you to boot back to a previous kernel and prove its a kernel change which triggered it, and let me know which one :)
<jdstrand> apw: k
 * jdstrand wonders why he seems to hit all these boot issues...
<jdstrand> slangasek: does this look right: http://paste.ubuntu.com/418644/
<apw> you have a heap of junk for a laptop ?  :)
<jdstrand> apw: dude... uncool
<slangasek> jdstrand: yep
<jdstrand> :)
<jdstrand> hey-- the T42 was quite a nice laptop back in the day
<apw> heh i had one of those, and it was never a nice laptop
<jdstrand> really? it always work well for me-- I rarely if ever had to do anything to get it to work with Ubuntu
<jdstrand> of course, I chose the radeon 7500 specifically cause I didn't want a proprietary driver...
<apw> jdstrand, mine exploded in the end
<jdstrand> my wife still has one and it is going strong
<apw> jdstrand, i can't tell from this bug if the thing is fine once plymouth is done or not
<jdstrand> I don't use mine as much, but it still works great (barring the recently fixed radeon/KMS bug and this plymouth thingie)
<jdstrand> apw: it is only the boot splash before X kicks in that is affected. everything else seems ok. but let me double check that
<apw> ok then i'd be interestied in knowing what your previous kernel was
<jdstrand> 18 uses the text logo
<jdstrand> (for boot-- shutdown uses logo)
<apw> do you have -19 ?
<jdstrand> booting into it now
<jdstrand> err-- 18 and 19 use the text theme on boot, logo on shutdown
<apw> jdstrand, ok that makes little sense then, for -21 to differ there
<slangasek> jdstrand: please make sure to use an up-to-date initramfs for these comparisons
<apw> yeah if you rebuild the -18 initramfs i suspect it may break
<slangasek> i.e., if you have cryptsetup installed, plymouth is in the initramfs, and you'll have an old version in the initramfs for the old kernel
<ScottK> The quassel upload is not needed until after RC.  It just converts patches we have into a nice release number.
 * jdstrand reboots again
<jdstrand> apw, slangasek: ok, after booting into 19, doing update-initramfs -u -k 2.6.32-19-generic and rebooting into it: degraded logo theme on boot and shutdown
<jdstrand> I'm afraid of 18 based on apw's comment
<apw> no i meant i suspected you would transfer the issue into it
<slangasek> jdstrand: you get the strange colormap with -19?
<jdstrand> slangasek: yes (what I meant by 'degraded')
<slangasek> hmm; and -19 was the one present at the time we last discussed this
<slangasek> let me double-check the upstream plymouth changes - I don't remember anything about this
<apw> jdstrand, is plymouth actually in your initramfs?
<jdstrand> slangasek: yes -- bug #554143 shows me as having 2.6.32-19-generic
<ubottu> Launchpad bug 554143 in plymouth "text logo theme used instead of graphical with radeon 7500 (single video output, pseudocolor fb)" [Medium,Triaged] https://launchpad.net/bugs/554143
<jdstrand> apw: well, I would assume so-- I am using splash and get the degraded logo. what do you want me to check specifically?
<slangasek> oh, I know what the difference is
<ScottK> pitti: re all those perl module MIRs - I don't have an opinion on if the entire mess needs to be in Main or not.  I was just trying to get it what was in main was buidable/installable.
<apw> jdstrand, i didn't think plymouth was in there
<slangasek> jdstrand: plymouth 0.8.2 switched us to using the drm renderer unconditionally on radeon, where before we used drm only for multi-head displays
<jdstrand> ah
<apw> hrm
<slangasek> so this is a plymouth/libdrm/kernel issue
<jdstrand> well, while I sould prefer the logo theme over the text, it is less than optimal atm :)
<apw> so either plymout doesn't grob the frambuffer, or the framebuffer is not right in the kernel
<jdstrand> s/sould/would/
<apw> jdstrand, what does VT1 look like once X starts?
<jdstrand> apw: normal-- login prompt
<apw> jdstrand, you are just being limited in your interpretation of pretty
<jdstrand> heh
<jdstrand> tbh-- a black screen until gdm comes up with no text would be beautiful at this point
<apw> you just need more drugs to fully apprecaite the green
<jdstrand> ie, if 'quiet' was really quiet, and lose splash
<jdstrand> hah
<apw> slangasek, so whats our next step
<jdstrand> slangasek: how do I force text logo in .21? update-alternatives --config default.plymouth didn't do it for me (or maybe there is more I need to do)
<slangasek> apw: assign the bug back to plymouth; the drm renderer isn't checking bpp
<jdstrand> I keep saying 'text logo'...
<jdstrand> text *theme*
<slangasek> (just verified the code)
<slangasek> jdstrand: boot with plymouth:splash=text
<jdstrand> slangasek: k, thanks
<apw> slangasek, will do
<apw> slangasek, done
<jdstrand> slangasek: that didn't do it-- related to the drm issue?
<slangasek> jdstrand: hmm, sec
<pitti> ScottK: sure, no problem; I didn't want to shoot the messenger, thanks for sorting this ot
<pitti> out
<ScottK> Understood.
<slangasek> jdstrand: really should've worked - is the text theme in your initrd?
<jdstrand> slangasek: looks like it: http://paste.ubuntu.com/418660/
 * jdstrand tries again
<slangasek> jdstrand: oh - plymouth:splash=ubuntu-text
<slangasek> sorry
<slangasek> 'text' doesn't work because it's looking for text/text.plymouth
<jdstrand> that didn't work either. let me super double check I didn't mistype it
<jdstrand> slangasek: should I lose 'splash'?
<slangasek> jdstrand: no
<jdstrand> slangasek: sorry, no. that didn't work
<jdstrand> I even said it out loud to myself 'plymouth' 'colon' 'splash' 'equals' 'ubuntu-text'
<jdstrand> eek
<jdstrand> my screen just faded to white
<jdstrand> and didn't get to the gdm screen
<slangasek> jdstrand: what was the filter on that pastebin?
<jdstrand> find . -name "*plymouth*"
<slangasek> ok
<slangasek> is /lib/plymouth/ubuntu-text.so also in the initrd?
<jdstrand> slangasek: yes
<jdstrand> (I had to reboot to get to a usable system)
<slangasek> hmm
<jdstrand> slangasek: do you want my initrd?
<slangasek> jdstrand: don't think it'll help; I'm missing something, but I have no clue what ATM
<jdstrand> slangasek: ok. well I wanted to test/comment more on the Broken pipe bug, but it'll have to wait until I can boot using the text theme (obviously)
<slangasek> heh, right
<ScottK> slangasek: FTBFS fix ^^^
<NCommander> slangasek: on the arm FTBFS of libgphoto2, is it acceptable if we drop doxygen from the build-deps so configure disables generating documentation? The package builds probably, it just appears that our buildds suck
<slangasek> NCommander: is the doxygen documentation currently shipped somewhere?
<slangasek> there's no arch: all -doc package
<NCommander> slangasek: its shipped in the -dev part of the package if memory serves.
<slangasek> please only drop the build-dep on armel, then
<NCommander> slangasek: that was my plan. I rather fix it so we have an arch all docs package, but the root canal needed to libgphoto2's configure scripts probably would be a bit excessive for an upload this late
<slangasek> ScottK: accepted, thanks!
<ogra> NCommander, err
<ogra> NCommander, i thought there was a request that the arch all stuff shuldnt be built on armel for gphoto, didnt you work on that ?
<slangasek> NCommander: why would any root canal be needed?  Making an arch: all -doc package would only require splitting it up in the debian/rules install or binary target
<slangasek> NCommander: though, in this case I think just dropping the docs for armel is best
<slangasek> due to the time
<ScottK> What's the deal with OOo on armel?  I see it got restarted again.
<slangasek> don't know
<jdstrand> slangasek: do you need a bug for the text theme issue?
<slangasek> lamont: did you find out anything about that OOo restart?
<slangasek> jdstrand: might as well - btw, if you want to switch to text semi-permanently, just remove plymouth-theme-ubuntu-logo...
<jdstrand> slangasek: I was afraid of doing that, since I got that weird white fade-out, but I'll try
<ScottK> I'd appreciate it if someone could throw http://paste.debian.net/69754/ at mass-sync.py.
<slangasek> jdstrand: har; weird bug in the commandline parsing, 'plymouth:splash=ubuntu-text' doesn't work when it's the last option on the boot line
<jdstrand> slangasek: oh heh
<jdstrand> slangasek: let me reinstall plymouth-theme-ubuntu-logo and try again
<jdstrand> slangasek: btw, that is bug #566762
<ubottu> Launchpad bug 566762 in plymouth "can no longer use text theme" [Undecided,New] https://launchpad.net/bugs/566762
<doko__> slangasek: please accept the sun-java6 package, the previous one does contain undistributable stuff
<slangasek> cjwatson: are you still able to reproduce bug #521298?  jdstrand and I appear to have both been trying, I haven't been able to and AIUI jdstrand hasn't either
<ubottu> Launchpad bug 521298 in plymouth "could not write byte broken pipe" [Undecided,Triaged] https://launchpad.net/bugs/521298
<slangasek> doko__: done
<jdstrand> slangasek: I saw a very brief flash of text once, but after 7 reboots the Broken pipe seems gone. shutdown is another story (see comment #44 in bug #521298
<ubottu> Launchpad bug 521298 in plymouth "could not write byte broken pipe" [Undecided,Triaged] https://launchpad.net/bugs/521298
 * slangasek nods
<cjwatson> slangasek: I'll give it another go shortly
<slangasek> the general problem of text being shown over the text-mode splash screen isn't likely to get fixed before final
<jdstrand> ogra: you might be interested in ^
<slangasek> shutdown messages, etc.
<jdstrand> slangasek: would it be possible to add a newline after the dots?
<slangasek> probably
<jdstrand> slangasek: I think it would look more acceptable with it
<jdstrand> I wonder if I am not seeing it now cause ureadahead is up to date...
<jdstrand> (the Broken byte issue)
<cjwatson> do you see it if you switch to tty7 after booting?
<slangasek> I'm guessing that was an effect of one of the mountall / plymouth bugs that were recently fixed
<cjwatson> because when I was seeing it I was doing oem-config stuff, which tends to land on tty7 in between things
<jdstrand> cjwatson: when should I go to tty7? gdm is there at present...
<cjwatson> oh, server installs I'm talking about
<cjwatson> easier to see there
<jdstrand> cjwatson: right, I was seeing it on desktop until recently
<cjwatson> yeah, but why not use the easy reproduction case :)
<cjwatson> I saw it in desktop OEM installs
 * jdstrand nods
<cjwatson> which flick to tty7 between ubiquity-dm and gdm
<jdstrand> it only ever bothered my on my laptop :P
<cjwatson> but that's hopeless for actual debugging
<jdstrand> I can crank up a VM to see
<cjwatson> I think I did see it rather less with plymouth 0.8.2
<cjwatson> I'm doing a server install now to check
<lamont> slangasek: the one where someone external to crabapple reset it?  yeah.  I know what happened there
<slangasek> lamont: does knowing what happened mean we can be assured of it not happening again? :)
<lamont> well... it would be very very beneficial to our future selves if the armel machines were actually server-class hardware, instead of naked boards with stuff plugged into them
<slangasek> heh
<slangasek> plars, GrueMaster: ETA 1h30 for arm netbook images
<GrueMaster> Roger that.
<slangasek> cjwatson, pitti: ^^ I don't expect I'll manage to be around at that time to post those, so if someone could post them to the ISO tracker when they're done, that'd be groovy
<ogra> jdstrand, i cant confirm because i'm continually reinstalling my beagleboard :) i'll check once i have an install that will persist longer than 20min ;)
<GrueMaster> slangasek: Why the respin?  It looks like there was an image already for today.
<slangasek> GrueMaster: because these are the candidate images for RC
<GrueMaster> Ok.
<slangasek> ubuntu, kubuntu DVDs will also show up in the next few hours; I'll post them after my nap if no one beats me to it
<ScottK> slangasek: ^^^ rebuild FTBFS fix.  Fine to wait for after RC.
 * slangasek nods
<ScottK> slangasek: Any chance of getting my sync's done from earlier today? http://paste.debian.net/69754/
<slangasek> looking
<ScottK> Thanks
<slangasek> running
<ScottK> Great
 * slangasek drops off for a bit
<pitti> slangasek: sorry, I need to leave for Taekwondo as well now, but I can have another look when I'm back in ~ 3 hours
<vish> !outyet
<ubottu> nope. Lucid is due 29th April. More info closer to the date.
<vish> grr..
<facundobatista> Hi all
<facundobatista> slangasek, ping
<GrueMaster> Have the arm images (imx51 & dove) finished building?  Would like to start downloading them so I can test this afternoon.
<facundobatista> slangasek, ping, I have this proposal that should get into Lucid (it's from early March):
<facundobatista> slangasek, https://code.edge.launchpad.net/~facundo/ubuntu/lucid/pyinotify/fix-path-overlap/+merge/21266
<facundobatista> slangasek, without it, pyinotify lies about the path where some MOVE_SELFs happen, which is critical for all the software using it (Ubuntu One between them)
<facundobatista> slangasek, kenvandine already sponsored it
<GrueMaster> Someone please update iso.qa.ubuntu.com with the ubuntu arm images asap so I can start uploading test info.
<cjwatson> GrueMaster: one moment
<cjwatson> GrueMaster: done
<cjwatson> slangasek: ^-
<GrueMaster> Thanks.
<cjwatson> slangasek: hm, so I indeed can't reproduce the EPIPE errors on a fresh install.  Maybe the case I was hitting got fixed
#ubuntu-release 2010-04-20
<slangasek> lamont: acorn appears to not be helping
<slangasek> cjwatson: ok
<slangasek> lamont: can you tell me what's going on with acorn? I've killed off the livefs attempts after 5h+ with no response
<doko__> uploaded a gcc-4.5 build to the devirtualized ubuntu-toolchain-r ppa, please kill it, if it blocks other builds (should only happen for powerpc, sparc and ia64)
<lamont> slangasek: lock file removed.
<lamont> go me
<lamont> and typo fixed in the @reboot crontab entry that should have done that
<slangasek> lamont: oh, bah
<slangasek> ok
<slangasek> lamont: well, that's much better than the alternative scenarios, then :) will switch back to acorn for the next builds
 * ScottK got a couple of armel livefs build failure mails for Kubuntu Netbook, but no logs attached.  Anything I need to worry about?
<lamont> slangasek: did you want the existing builds killed?
<slangasek> lamont: doesn't matter
<slangasek> ScottK: nope
<ScottK> OK
<lamont>  /bin/bash /home/buildd/bin/BuildLiveCD -s dove -d lucid kubuntu-netbook
<lamont> slangasek: ^^ that one is running now, I killed the other one.
<slangasek> ScottK: that was me killing off the builds on acorn to move them back to clementine - should have kubuntu-netbook/armel posted in a couple of hours
<ScottK> OK
<lamont> mostly I'm curious how long it takes
<ScottK> I'd appreciate it if someone would binary New libcatalyst-perl.  It's my upload so I shouldn't.  It's got another possible sync request behind it depening on how a depwait resovles itself.
<slangasek> lamont: less than an hour would be nice :)
<slangasek> ScottK: looking
<ScottK> Thanks.
<lamont> slangasek: lets see how we do
<ScottK> Should be clear enough, perl module sync'ed from Debian.
<slangasek> ScottK: done
<ScottK> Thanks.
 * ScottK hopes before the publisher started...
 * ScottK looks
<ScottK> Nope, after.
<ScottK> No biggie.
<ScottK> Would it be possible to respin just Kubuntu ia64 live and alternate?  They were built with obsolete packages because ia64 was behind.  It's caught up now.
<lamont> hrm.. that reminds me, I should burn ia64 install media and see how it does
<ScottK> I know that port has at least one actual user because I've seen a bug filed specifically mentioning it was with the ia64 version of a package.
<doko__> lamont: any idea on the glib2.0 issue on sparc?
<slangasek> ScottK: sure - I actually haven't done any ports spins yet except for kubuntu-netbook, I can fire that one off now
<ScottK> OK,  powerpc then too.
<ScottK> I've got actual testers lined up for that one.
<lamont> doko__: none at all.  go ahead and kill faure with it, just make sure you're capturing output off-machine
 * lamont updates the chroot
<doko__> lamont: I only have a remote machine for testing, so I'd like to play safe. Would you mind an upload not running the testsuite on sparc?
<lamont> doko__: try a testbuild of that on faure?
<doko__> lamont: just with the disabled testsuite?
<lamont> yeah
<doko__> doing ...
<lamont> slangasek: if you kick ia64 media, I'll go test that tonight, too
<lamont> doko__: dist-upgrade is still running, I'll install the build-deps when that finishes
<doko__> lamont: I'll try on my local machine first
<ScottK> slangasek: A few more Universe syncs if you have a moment: http://paste.debian.net/69817/
<ScottK> Also a stack of binary removals (I can put this in a bug if you want a paper trail, but it's in the spirit of the supportable binaries spec: http://paste.debian.net/69818/
<lamont> BEGIN fdupes <-- slangasek
<lamont> :-(
<lamont> doko__: build-deps all there on faure, fwiw
<lamont> doko__: if you get one that builds ok on faure, and I'm asleep/afk, feel free to have a GSA make the semi obvious change around 'glib2.0' in /usr/share/launchpad-buildd/slavebin/sbuild-package on one of the sparc buildds
<lamont> slangasek: well... the mksquashfs run _started_ before the hour was up...
<slangasek> hmm :)
<slangasek> well, at least it's parallel :)
<lamont> 2-3 minutes before, mind you
<lamont> one core.
<slangasek> lamont: well, there's http://cdimage.ubuntu.com/kubuntu/ports/daily/current/ if you want to test some ia64
<slangasek> (liveCD still building)
<slangasek> ScottK: syncs running; looking at the binary removals now, no bug, I'll just point at you by name in the removal message ;)
<ScottK> slangasek: OK.  Please just mention python2.5 being needed in there somewhere.
<slangasek> yep
<slangasek> done
<lamont> slangasek: I was thinking more ubuntu-server
<lamont> ia64 desktop seems "just wrong"â¢
<lamont> last night's daily server make any sense to play with?
<slangasek> you didn't specify ;)
<slangasek> let me get you a fresh one, < 30min
<lamont> coolorino
<lamont> you know, if we didn't squash it so hard, it'd squash faster
<slangasek> spend a penny to save a penny
<lamont> very true, 'dat
<lamont> slangasek: 83 minutes.  just fyi
<slangasek> not too bad then
<slangasek> ScottK: kubuntu-netbook/armel finished
<ScottK> slangasek: THanks.
<ScottK> So that worked.  The followon build to libcatalyst-perl succeeded.
<slangasek> lamont: ubuntu-server/ia64 done
<lamont> ta
<ara> morning
<pitti> Good morning
<ara> morning pitti
 * slangasek waves
<ara> slangasek, generic tests are not in the tracker for a good reason?
<slangasek> ara: sheer forgetfulness on my part about their existence; posted nowv
<ara> slangasek, ok, thanks
 * slangasek looks over the build set list to make sure he hasn't missed anything else
<slangasek> I think that's it
 * pitti reviews the current universe packages
<slangasek> pitti: mind that audacious is on ubuntustudio
<pitti> right, I have the x/myth/studio manifest files here for comparing
<slangasek> pitti: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1 helps, sets are marked
<pitti> slangasek: ah, nice; is that reliable enough to not having to consult the x/myth/studio CD lists?
<slangasek> dunno
<slangasek> cjwatson: ^^ is it? :)
<pitti> well, I think at this point I check them anyway
<pitti> seems the only candidate is mpich2
<cjwatson> I would double-check the CD lists if I were you
<cjwatson> treat it as a guide ...
<pitti> cjwatson: *nod*
<wgrant> It's as reliable as the information LP is given...
<cjwatson> wgrant: yes, I know - I'm the one giving it the information :-)
<cjwatson> so I know how (un)reliable that is as yet
<wgrant> Ah, right.
<slangasek> ev: bug #543032 is still marked as "fix committed"; is this resolved in the wubi we currently have on the RC images?
<ubottu> Launchpad bug 543032 in wubi "Selecting reboot doesn't reboot" [Undecided,Fix committed] https://launchpad.net/bugs/543032
<ev> slangasek: I just set it to Fix Released.  It's fixed on the RC images.
<slangasek> ta
<ogra> slangasek, i just hit a prob with a missing option in livecd-rootfs on omap. STRIP_VMLINUZ is not set to no so we dont have vmilnuz in the /target during install, http://paste.ubuntu.com/419134/ would fix that (and also clean up the ugly separate if statement)
<slangasek> ogra: what do you mean, "wouldn't save any space"?
<ogra> ?
<slangasek> your comment in the patch
<ogra> its not my comment
<slangasek> oh
<ogra> i just copied it 20 lines up
<slangasek> right
<ogra> so we can use the case statement instead of adding a complicated if
<ogra> makes no sense to handle it separately
<ogra> http://paste.ubuntu.com/419136/ has the full case statement after my change for better understanding
<ogra> save any space:  uImage is created additionally, either for use in flash or for use in /boot (fi /boot can be ext2 like in dove) stripping vmlinuz actually breaks the install (ubiquity tries to copy it from casper/ to not also have it in the squashfs)
<ogra> in dove or omap images casper only carries uImage not vmlinuz so it wouldnt "save any space" to remove a nonexisting duplicated file
<ogra> (that comment is super silly formulated not sure who wrote it)
<slangasek> right - it's not that it doesn't save space, it's that it breaks the install :)
 * ogra fixes the last sentence to make it clearer
<ogra> yeah
<ogra> http://paste.ubuntu.com/419150/
<lool> slangasek: Just pushed a qemu-kvm fixing the qemu-$arch and qemu-system-$arch man pages; do you think it is reasonnable to include between RC and final or shall I move to a SRU bug?
<slangasek> lool: well, doko wanted an update of this package anyway for the static binaries to rebuild against current glibc (which includes code fixes); if we get actual fixes of known bugs in the process, that's better
<slangasek> lool: but, since were revving anyway, please fix the qemu-kvm-extras-static postinst to not call 'start' directly as this isn't chroot-safe - it should use invoke-rc.d instead
<lool> slangasek: http://paste.ubuntu.com/419170/ is the debdiff I uploaded
<slangasek> (there was a discussion on #ubuntu-devel about this a few hours ago)
<lool> slangasek: that gives out warnings though
<slangasek> lool: not when called from a maintainer script
<lool> slangasek: Re-upload ubuntu7 or ubuntu8?
<slangasek> whichever you prefer
<lool> I'll go for ubuntu8 for bzr imports then
<ogra> slangasek, so would it be ok to upload livecd-rootfs with http://paste.ubuntu.com/419150/ to fix omap netbook images ? (only touches dove and omap)
<slangasek> ogra: is that the part that has to get uploaded, or the part that lamont has to pull from bzr?  I never remember
<lool> In theory this part is pulled daily
<ogra> i think lamont syncs the package to the live builder
<lool> or perhaps even updated before builds, I'm not sure
<ogra> and that happens daily
<lool> the part which required manual interaction in the past was the wrapper which calls the real script
<lool> (IIRC etc.)
<slangasek> the BuildLiveCD sample wrapper
<lool> yes
<slangasek> ogra: yes, please upload
<ogra> thanks :)
<slangasek> I imagine we need omap respun after this is published
<lool> slangasek: is ubuntu7 -> ubuntu8 http://paste.ubuntu.com/419174/
<slangasek> lool: looks good to me
<lool> kirkland, doko_: FYI couple of qemu-kvm uploads in unapproved
<lamont> BuildLiveCD comes from outside the chroot and is a manual propagation
<lamont> ogra: ^^
<doko_> lool: mine was just a rebuild
<lamont> doko_: does this mean that satinash is getting close on oo.o?
<lamont> Started 1 day, 1 hour, 17 minutes, 8.6 seconds  ago.
<cjwatson> I've managed to reproduce bug 558382
<ubottu> Launchpad bug 558382 in partman-base "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [High,In progress] https://launchpad.net/bugs/558382
<cjwatson> it looks as though it's something to do with maximising extended partitions
<cjwatson> which is nasty - it suggests that there's a possibility of problems any time you have free space around your set of logical partitions
<cjwatson> e.g. during auto-resize
<cjwatson> I'm working on gathering more information now that I have a saved kvm snapshot that reproduces it
<ev> for what it's worth, michaelforrest just ran into that and I'll have logs just as soon as he's done with an install, if you need them.
<doko_> lamont: the last succeeding one was 1d 19h ...
<ogra> slangasek, uploaded, there is another one char typo fix from lamont in the debdiff he didnt upload yet, hope thats ok
<cjwatson> ev: I think I'm good, thanks
<ev> okay, cool
<slangasek> ev: hmm, usb-creator-gtk gives a wholly non-obvious error message when it doesn't have permissions to read the source .iso... is that worth a bug report?
<slangasek> ("doesn't have permissions" -- NFS)
<ev> slangasek: yes please
 * Riddell cries over bug 567243
<ubottu> Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Undecided,New] https://launchpad.net/bugs/567243
<kirkland> slangasek: fyi, i'm looking at ttx's rackspace package renames
<cjwatson> Riddell: oh in ainm DÃ©, not another one
<Riddell> ainm D?
 * slangasek happily absorbs the Irish
<slangasek> kirkland: ack
<pitti> sounds similar to "nomen dei" -> "in god's name"?
<slangasek> yep
<cjwatson> yes
<cjwatson> D e-fada (e-acute) for the Unicode-impaired
<cjwatson> slangasek: right, I've figured out the partitioning problem
<cjwatson> the bug is an overenthusiastic application of optimal alignment to extended partitions in partman-base (it's only needed for partitions that directly contain filesystems)
<cjwatson> when we try to create a new logical partition next to existing logicals, partman maximises the extended partition to make room, and then minimises it again around the new set of logical partitions
<cjwatson> I was incorrectly constraining the maximised extended partition to optimal alignment (which is normally a 1MiB grain)
<slangasek> cjwatson: heh, nice!  errata for RC, or is this horrid enough to warrant a respin?
<cjwatson> this meant that if the extended partition was non-optimally-aligned at the end (e.g. cylinder-aligned from all sorts of possible older installations), we tried to maximise it, but sometimes actually ended up rounding *down* the end position
<cjwatson> which meant that maximising the extended partition failed, so there was no room to create new logical partitions inside it
<slangasek> heh
<cjwatson> horrid enough> so that's more or less my question
<cjwatson> it will fail rather than corrupt data, I think, and it's not new - at least beta-2 had the same problem and I think beta-1 as well.  OTOH I don't think we can release with partman this way, and in some ways I'd rather test it in the RC
<cjwatson> but I'm open to either
<cjwatson> the diff is http://paste.ubuntu.com/419280/
<cjwatson> and for the record it would require respinning everything
<cjwatson> so if that's too much of a headache, we can put it off
<cjwatson> I'm not sure how to errata it short of "the partitioner might just not work"
 * charlie-tca thought it was just my equipment failing at times
<slangasek> after hitting the failure, is there any way to recover, other than waiting for an ISO with the fix?
<slangasek> based on what I've seen of the ISO testing timeline for the betas, I think a broad-spectrum respin today would push us to Friday on the RC, unfortunately
<slangasek> unless we mustered a lot of extra testing support quickly, and that would probably expend our reserves for next week
<charlie-tca> For me, the only way out has been to run the liveCD, delete the partitions, then run the install again
<slangasek> I'm ok with an erratum of "the partitioner might just not work, and spit <error message>; if you hit this you can delete the partitions by hand, or wait for the final release next week"
<cjwatson> there might be fiddly technical ways to recover, such as manually resizing your existing logical partitions to slightly different boundaries
<cjwatson> deleting partitions wouldn't be a good recommendation since they'll be people's existing partitions
<slangasek> ah
<cjwatson> "wait for an ISO with the fix" is probably the sanest recommendation by some way
<slangasek> right
<cjwatson> ok, so I can drop this into the archive and we can land it last thing Thursday, or something
<slangasek> sounds good to me
<cjwatson> it should have occurred to me to just try manually laying out a disk matching the reported partman log, and then I'd have found it more quickly
<cjwatson> but hindsight is 20/20
<kirkland> slangasek: okay, rackspace stuff looks okay, i'm going to approve them from the new queue
<kirkland> slangasek: do i also need to remove the old ones from the archive?
<slangasek> kirkland: the old ones need removed from the archive, yes
<kirkland> slangasek: k
<kirkland> slangasek: done
<slangasek> kirkland: thanks - bugs reports closed?
<kirkland> slangasek: i'll blacklist too
<slangasek> ok
<kirkland> slangasek: changelog mentioned the bug number; i'll double check
<kirkland> is it too late to upload byobu with a newly merged set of translations?
<pitti> kirkland: but they would just get stripped anyway?
<kirkland> pitti: ?
<pitti> kirkland: you might upload the new .po files directly to LP, to shortcut their import?
<pitti> kirkland: packages in main don't ship translations (*.mo) anyway
<kirkland> pitti: oh?  okay.  where do their *.mo's go then?
<kirkland> pitti: how do they get sucked up?
<pitti> kirkland: https://wiki.ubuntu.com/Translations/TranslationLifecycle explains the whole process in detail
<pitti> kirkland: in short, the .mo files are stripped, the po files imported into LP, merged with translation updates, and re-exported into language-pack-*
<jdstrand> slangasek: I have an apparmor profile change to address bug #566207
<ubottu> Launchpad bug 566207 in evince "apparmor blocks evince from /usr/bin/dbus-launch" [High,Triaged] https://launchpad.net/bugs/566207
<jdstrand> slangasek: I'd like to add an abstraction to apparmor (already in trunk), and then update evince to use the new abstraction. if this is not appropriate, I can just adjust evince for lucid and make said changes in maverick
<kirkland> pitti: okay, i'm just realizing i haven't merged translations into byobu in several months, got some complaints from people who contributed translations and weren't seeing them in the package
<jdstrand> slangasek: what do you think?
<pitti> kirkland: they don't need to be
<kirkland> pitti: okay, thanks
<slangasek> jdstrand: I think it's appropriate to make the change for lucid, but I'm inclined to defer to SRU - from the bug log, it seems to me that this bug only affects certain remote-display configurations?
<jdstrand> slangasek: presumably, yes
<jdstrand> slangasek: I can adjust the bug accordingly for SRU
<slangasek> and AIUI doesn't block use of evince, just throws some errors
<slangasek> so yeah, I think SRU is best
<jdstrand> slangasek: no, it blocks evince on a remote display. but there may be an unrelated issue that makes that not work anyway
<slangasek> ah
<slangasek> still, --> SRU please
 * jdstrand nods
<ogra> jdstrand, in the case the user subscribes there you dont have any session dbus running
<ogra> so evince has nothing to connect to
<ogra> s/subscribes/describes/
<ogra> even fixing apparmor will not get him running evince
<jdstrand> ogra: right, so it tries to start one with dbus-launch (which fails due to apparmor)
<jdstrand> ogra: so it isn't possible to get evince running on a remote display?
<ogra> well, you need a session dubs running first
<ogra> *dbus
<jdstrand> ah right, I see what you are saying
<ogra> gnome-session does that automatically, if you log in via ssh that doesnt happen
<jdstrand> still, the profile should be adjusted, it is then up to the user to get the session bus going
<ogra> indeed
<ogra> the apparmor issue is definately valid but will likely not fix the issue for the user
<jdstrand> ogra: thanks
<stgraber> slangasek: ping
<doko__> slangasek: I'd like to upload gcj-4.4 for lucid, fixing stack-unwinding on armel, followed by an ecj upload. currently testing on jocote. ok, or sru?
<davmor2> Wubi isn't being pulled in on Xubuntu cd's
<charlie-tca> That wouldn't require complete retesting, but we do have users that use it
<stgraber> slangasek: Quick status update on Edubuntu, we're still waiting on the final artwork, for now we reverted on the old one and I'll try to call Iain Farrell tomorrow morning (just noticed I had written his office and cell numbers ;)). highvoltage is working on a small change in our scripts that will be uploaded in a few hours (I hope), we'll then need a respin to include these changes.
<highvoltage> slangasek: package uploaded
<lamont> doko__: any progress on glib2.0 vs sparc?
<doko__> lamont: no, can look at it tonight. would disabling the testsuite work for an upload? I fear, my machine will be not accessible as well
<lamont> doko__: put together a source package with the test suite disabled for sparc, toss that (signed) on faure, and start the build.  I'll check it later and see how it did and then pester slangasek about upload perms. sound good?
<doko__> lamont: ok
<cr3> I fixed a bug in checkbox which might be release critical, how can I assess whether it's really release critical or whether it should be an sru?
<doko__> seb128: while trying to build glib2.0
<doko__>  fakeroot debian/rules clean
<doko__> /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: lucid
<doko__> what does depend on that?
<seb128> doko__, don't bother about that one
<seb128> doko__, it's an hook to avoid experimental source upload to unstable in debian
<seb128> doko__, it just displays warning in other scenarios
<doko__> ok
<doko__> lamont: faure:~doko/tmp
<ScottK> Unless I'm just really unlucky, Bug 567536 may be important and no mvo.
<ubottu> Launchpad bug 567536 in update-manager "Upgrade failed due to OOo predepends problem" [Undecided,New] https://launchpad.net/bugs/567536
<ScottK> Also, the pending opendkim upload is mine, so I'd apprecaite it if someone would accept it.  The only non-bugfix bit is a build system change that defaults off.
<slangasek> stgraber: pong
<slangasek> doko__: gcj-4.4, ecj> SRU, I'm afraid
<doko__> ok
<slangasek> stgraber, highvoltage: ok; so you want a respin for RC with the edubuntu-artwork upload?
<highvoltage> slangasek: that would be very nice thanks
<slangasek> ScottK: 567536> looks like a duplicate of the one mvo has already been working on?
<ScottK> slangasek: OK.  ccheney wasn't sure if it was still a work in progress or a fix had already been 'done'.
<ScottK> (which I found out after I pinged here)
<ScottK> BTW, I used Ubuntu for the first time today.  The failed upgrade is a new Dell laptop that arrived today with Ubuntu preinstalled.
<slangasek> oh no, mvo was struggling with it all day today - I'm quite sure the fix isn't done
<ScottK> OK
<slangasek> highvoltage: so this upload is the rollback to the previous artwork?
<highvoltage> slangasek: eek, no, unless I did something horribly wrong
<slangasek> highvoltage: oh, all debdiff is showing me is that there are different logos; I was trying to understand what's going on based on stgraber's comments
<slangasek> highvoltage: is this the /final/ artwork, then?
<highvoltage> slangasek: we still don't have anything from Canonical, so I decided to replace the place-holders with the old Edubuntu logo, since we don't have any word on when it will be ready
<slangasek> highvoltage: ok :/
<highvoltage> slangasek: and I'm concerned that the archive might go into deep freeze with a bunch of "New Edubuntu Logo Here" messages in place
<slangasek> edubuntu-artwork accepted
<highvoltage> thanks again
<highvoltage> my dream is that one there will be an artwork team as efficient as the release team :)
<highvoltage> s/one/one day/g
<bdrung> can someone let audacious in?
<slangasek> edubuntu-artwork publishing, ISO trigger set
<slangasek> bdrung: it's seeded on the ubuntustudio images, so that would break the RC freeze?
<bdrung> ups
<bdrung> slangasek: what's the process for seeded packages in the RC freeze?
#ubuntu-release 2010-04-21
<slangasek> bdrung: we generally expect the archive to be in sync with the ISOs during RC validation, so either you'd need to get sign-off from the responsible listed on https://wiki.ubuntu.com/LucidLynx/ReleaseManifest for a respin this late, or it waits until after RC
<bdrung> ok, waiting is the solution. i just wanted to make sure that it hits the final release
<bdrung> slangasek: thanks for the information
<ScottK> bdrung: Is upstream planning to accept those changes or are the potientially permanent Ubuntu diff?
<bdrung> ScottK: they want to adopt the icon - two patches are cherry-picked from upstream
<ScottK> OK.
<bdrung> no permanent ubuntu diff
<slangasek> ScottK: opendkim in
<slangasek> just sponsored python-virtualenv, would appreciate a review
<slangasek> (when it lands in, say, 5 min)
<ScottK> The means you have time to review opendkim, right?
<slangasek> ScottK: already did it
<ScottK> Nevermind
<ScottK> Just noticed.
<ScottK> Don't see virtualenv yet
<slangasek> oh, because I failed to build with -sa
 * slangasek tries again
<doko__> slangasek, lamont: what about the glib2.0 update (fixing the sparc build). lamont, or did you have some kind of hack in mind?
<ScottK> It would be nice to start sooner rather than later on all the retries that would follow that fix.
<slangasek> doko__: not accepting it during RC validation; I realize that's going to set us back on retries, but I need the board clear for now
<slangasek> doko__: oh, but do please upload it if you have the fix - I thought the glib2.0 in the queue was the one you meant, but that's pitti's dbgsym fix
<slangasek> edubuntu rebuild started
<slangasek> is there anyone around who can do wubi testing?
<slangasek> charlie-tca and davmor2 both reported that wubi was "not present" on the Xubuntu desktop ISOs; but I can definitely see it on the ISO, and don't have Windows around to test with
<slangasek> ^^ there we go
<doko__> lamont, slangasek: glib2.0 uploaded
<slangasek> doko__: thanks
<sbeattie> slangasek: what did they mean by doesn't appear? I have an old win2k8 server prerelease instance that sees the wubi autorun instance with the iso inserted.
<slangasek> 15:52 < charlie-tca> When you try to install using wubi, it does not appear in any menu
<slangasek> 15:53 < charlie-tca> I put the desktop cd in the drive, there is no wubi to select
 * cody-somerville wonders if xscreensaver's 'New Login' feature being broken is a good enough bug to do an upload.
<slangasek> sbeattie: so if you're seeing the wubi menu, your guess is as good as mine
<slangasek> cody-somerville: are you asking, or just wondering? :)
<sbeattie> slangasek: has xubuntu been respun since then?
<slangasek> sbeattie: 20100419 is the latest
<cody-somerville> slangasek, Wondering with the hope someone might suggest if it is or not. I've tried asking mr_pouit a few times but he hasn't gotten back to me.
<slangasek> no respins because I haven't seen anything I could fix by respinning
<sbeattie> slangasek: oh, okay, I was going to try with 20100418
<cody-somerville> slangasek, http://bazaar.launchpad.net/~ubuntu-desktop/xscreensaver/ubuntu/revision/16 is the change to fix it
<slangasek> cody-somerville: oh, well, it's a bugfix so the release team wouldn't block it, but I think it's for you guys to decide if it's worth the upload
<ScottK> slangasek: virtualenv accepted.
<slangasek> thanks :)
<sbeattie> slangasek: I get wubi with 20100418 xubuntu daily-live i386 cd as well.
<slangasek> sbeattie: ok; we'll have to wait for them to resurface and give more detail, thanks for double-checking
<slangasek> ogra: omap netbook respun, finally; spent too long waiting for acorn to get its act together
<ScottK> slangasek: Some additional Unverse syncs for you if you have a moment: http://paste.debian.net/69990/
<ScottK> slangasek: Additional binary removals due to the lack of Python2.5: autodocktools mgltools-opengltk
<ScottK> slangasek: revised list: http://paste.debian.net/69994/
<slangasek> ScottK: syncs running
<slangasek> ScottK: autodocktools, mgltools-opengltk removed
<ScottK> Excellent.
<ScottK> The two recent Universe uploads in queue are mine if you could have a look ....
<ScottK> No rush.
 * slangasek gets a FTBFS mail for OOo/armel and screams
<slangasek> Session terminated, killing shell...make: *** [debian/stampdir/binary-arch] Terminated
<slangasek>  ...killed.
<slangasek> Build killed with signal 15 after 150 minutes of inactivity
<slangasek> lamont: ^^ why did satinash screw us over?
<ttx> Good morning
<ara> morning ttx
<ttx> slangasek: you don't have any plans to respin the server ISO, we can safely work on test coverage ?
<slangasek> ttx: no plans to respin
<ttx> slangasek: ok
<ev> slangasek: I've replied to your comment in bug 558488, but I'd like to get feedback on my suggestion before I go ahead and make that change.
<ubottu> Launchpad bug 558488 in ubiquity "(Lucid beta) Should use 10.04 LTS, not 10.04" [High,New] https://launchpad.net/bugs/558488
<slangasek> ev: hmm, sounds risky to me, precisely because other things may parse it
<ev> unfortunately I think all we have are risky options, but I'm open to further suggestions
<ev> I guess we could hardcode it for just this release
<slangasek> I think that would be least risky, yes
<ev> right, I'll work on patches to ubiquity and casper that do just that
<slangasek> also, I don't think anything sets DISTRIB_ID for flavors, does it?
<slangasek> (if it does, that's buggy, because this is a conffile)
<slangasek> before we entirely rule out editing of DEBVERSION, I guess I'd like to have cjwatson's take on it
<ev> okay
<ev> DISTRIB_ID> ah, my mistake for assuming that it was set for flavors.
<slangasek> really, the only place you can distinguish is in the install media; once you've installed, it becomes muddled
<slangasek> but .disk/info also includes the lavor name, doesn't it?
<ev> ah, wow
<ev> -ENOTENOUGHTEA
<ev> or something like that
<ev> way too many characters
<ev> anyway, yeah, we can just check the first field of .disk/info
 * slangasek puts mountall to the rack.  TELL ME YOUR SECRETS
<ev> lol
<cjwatson> my worry about doing it in ubiquity etc. is that it's hard to tell between LTS and non-LTS flavours there
<cjwatson> checking DISTRIB_ID seems ... likely to be messy
<cjwatson> and yeah, what slangasek said above
<cjwatson> in that case what I mean is "checking .disk/info for the flavour name seems ... likely to be messy"
<cjwatson> I think I'd be more comfortable with a flavour-specific change to DEBVERSION, THB
<cjwatson> TBH
<cjwatson> so, um - do CD-based upgrades from hardy actually work right now?
<cjwatson>   hardy)
<cjwatson>     export PREV_CODENAME=dapper # need to support upgrades from previous LTS
<cjwatson>   lucid)
<cjwatson>     export PREV_CODENAME=karmic
<cjwatson>     export CODENAME=hardy
<cjwatson>     export CODENAME=lucid
<cjwatson> hmm, maybe that doesn't matter since there's no release-upgrader-* in either hardy-backports or karmic-backports
<sbeattie> cjwatson: erm? I haven't done a hardy->lucid cd only upgrade yet for rc, but at least for the ubuntu-server amd64 iso, I know it's worked for the last two betas.
 * sbeattie has an amd64 machine that has a NIC that hardy's kernel doesn't recognize.
<ev> cjwatson: ubiquity> So to be clear, you think that we're okay to risk breaking tools that parse .disk/info over just hardcoding a check for ubiquity and kubuntu like so for a single release? http://paste.ubuntu.com/419733/ http://paste.ubuntu.com/419736/
<ev> err ubuntu and kubuntu
<cjwatson> sbeattie: 10:13 <cjwatson> hmm, maybe that doesn't matter since there's no release-upgrader-* in either hardy-backports or karmic-backports
<cjwatson> sbeattie: accounts for this working
<cjwatson> ev: the only thing I know of that actually *parses* .disk/info is wubi; otherwise, I believe parsing it to be very rare.  Can you think of anything else?
<cjwatson> that said wubi would actually break if we inserted LTS there right now, but the regex is easy to fix
<cjwatson> most things just display its contents or similar
<cjwatson> or log them
<cjwatson> so yeah, I think my personal preference would be to change .disk/info and fix wubi's regex
<ev> well, and ubiquity and casper, but yeah, I can't think of anything else that would
<ev> okay
<cjwatson> do they parse it?
<ev> ubiquity does
<cjwatson> mm, casper does some minimal parsing
<cjwatson> ./scripts/casper-bottom/10adduser:55:RELEASE="$(cut -d' ' -f1-2 /root/cdrom/.disk/info 2>/dev/null)" || RELEASE=""
<ev> indeed
<cjwatson> that wouldn't break, but it probably ought to be changed, since we want that to show LTS as well
<cjwatson> and same in ubiquity/ubiquity/misc.py
<cjwatson> on the flip side, changing .disk/info would mean that we wouldn't have to change things like cdrom-detect
<cjwatson> in wubi, http://paste.ubuntu.com/419742/ looks sufficient; I've checked all the callers and it doesn't display the version anywhere, it's just checking it against isolist.ini, so as long as we leave version in isolist.ini alone, we can just ignore "LTS ", I think
<cjwatson> (actually, http://paste.ubuntu.com/419743/ is clearer isn't it)
<ev> How does this look for ubiquity: http://paste.ubuntu.com/419744/
<ev> wubi> looks good
<cjwatson> don't you want the assignments outside the parens?
<ev> err wow, I'm way off the mark today
<ev> yeah
<cjwatson> >>> test('Ubuntu 10.04 "Lucid Lynx" - Release Candidate i386 (20100419.1)')
<cjwatson> 'Ubuntu 10.04'
<cjwatson> >>> test('Ubuntu 10.04 LTS "Lucid Lynx" - Release Candidate i386 (20100419.1)')
<cjwatson> 'Ubuntu 10.04 LTS'
<cjwatson> looks fine to me with that syntactic correction
<ev> okay
<cjwatson> wubi change committed - can you publish an updated wubi.exe at some point?
<ev> I'll do it now
<ev> done
<cjwatson> BTW, one reason I prefer it this way is that it's really quick to revert things just in cdimage if it goes wrong
<slangasek> true
<cjwatson> which admittedly would put us out of compliance with branding, but that's probably true with just about any failure mode here ...
 * slangasek nods
<cjwatson> grr, I didn't realise the translation import queue was quite so far behind
<slangasek> dpm mentioned it was slow; how bad is it now?
<doko_> slangasek: is there a buildlog left from the OOo build?
<cjwatson> "1-50 of 19038 results"
<cjwatson> it's backed up to the 16th
<slangasek> doko_: no, I restarted the build because the log was useless - it just hung after outputting openoffice.org-core
<slangasek> doko_: so the only relevant output is what I quoted in scrollback
<cjwatson> though it is catching up; it's up to late on the 16th, and it was only up to sometime on the 15th last night, so that's rather more than one hour per hour
<ogra> slangasek, hrm, seems acorn didnt have the new livecd-rootfs or my fix didnt work, there is no vmlinuz file in /boot
<slangasek> cjwatson: I don't follow all the implications - is that going to impact the ability to export langpacks in a timely manner this week?
<slangasek> ogra: the actual build was on clementine, acorn stiffed me
<ogra> lamont, can you check the livecd-rootfs version on clementine ?
<ogra> slangasek, ok
<slangasek> ogra: as for not having the new one - perhaps I wrongly assumed that the 'buildlive base; build-livecd-base' cronjob helped with this
<slangasek> I can retry it, clementine isn't doing anything else
<slangasek> (and lamont won't be around for a few hours, I'm sure)
<ogra> slangasek, i thought so too, but it might actually be a cronjob
<slangasek> ogra: hah - build-livecd-base doesn't know about armel
<slangasek> blast, and I just restarted the build on clementine
<ogra> heh, ok
<slangasek> well, that doesn't really seem to do anything useful on the buildds anyway... maybe this second build on clementine will work
<ogra> i'll check once there is an image
<cjwatson> slangasek: I *think* imports and exports are largely independent
<slangasek> but it may impact the up-to-dateness of the langpacks we export?
<cjwatson> the reason I care was that I was hoping to get a last-minute installer translation fix in, which is dependent on an import of d-i translations - but not the end of the world if it doesn't
 * slangasek nods
<cjwatson> maybe for the odd few upstream translations cycling through, although I noticed a huge pile of kde-i18n being imported
<cjwatson> I'd expect it to catch up fairly quickly when it hits the freeze
<cjwatson> but just a guess
<lamont> slangasek: acorn had multiple remaining issues, which I believe are all fixed, one of your livecd runs is now going, the other I killed since it was a dup
<slangasek> lamont: ok - how about logfile visibility?
<lamont> which machine and what url are you trying and not succeeding with?
<lamont> from which ...
<slangasek> lamont: antimony; was getting 404s before?
<lamont> and sample URL?
<slangasek> http://acorn.buildd/~buildd/LiveCD/
<lamont> try now?
<slangasek> lamont: there we go - thanks
<ogra> lamont, is livecd-rootfs 1.114 currently installed on either of  the amrel livefs builders
<ogra> *armel
<ogra> else we dont need to bother to rebuild omap yet
<lamont> ogra: both - acorn had 1.112 until moments ago
<lamont> omap is building with 1.114
<ogra> sweet, thanks :)
<slangasek> lamont: on which buildd is it building with 1.114?
<lamont> acorn
<slangasek> right, thanks
<lamont> wtf is up with oo.o/armel?
<lamont> I refuse to believe that it took > 2.5 hrs to do:  dpkg-deb: building package `openoffice.org-core' in `../openoffice.org-core_3.2.0-7ubuntu3_armel.deb'.
<hyperair> it might have =p
<hyperair> wait, 28M is kinda small..
<lamont> hyperair: if so, pushing it back to the top of the hill for another 2-day run at the problem probably isn't the answer
<hyperair> 2 days huh
<hyperair> that sounds painful
<lamont> yeah - it's a good thing they modularized the build so that it's not one big monolithic takes-forever pile, eh?
<lamont> oh wait.  that was just from my dreams
<slangasek> man, dreams about OOo, that's really taking your work home with you
<ogra> oh, come on, its not two days ... only 40h or so :P
<stgraber> ;)
<mvo> lamont: and the funny thing is that we may need another OOo upload before final
<mvo> (maybe not so funny)
<ogra> mvo, what ?!?
<mvo> bug #566584 and bug #516727
<ubottu> Launchpad bug 566584 in openoffice.org "unpack/configure order violation triggered by OOo pre-depends" [High,Confirmed] https://launchpad.net/bugs/566584
<ubottu> Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Confirmed] https://launchpad.net/bugs/516727
<mvo> the alternative is to remove ooo-evolution and ooo-filter-binfilter during the upgrade (well, before it starts)
<ogra> bah, sigh
<lamont> WTF does oo.o pre-depends something?
<lamont> well, other than the obvious, I suppose. but still SHEESH
<mvo> lamont: it pre-depends on TEH WORLD
<lamont> mvo: it IS the world.
<mvo> lamont: like -core, that needs the full gstreamer, all of gnome etc
 * ogra is happy we dont use it in any armel images anymore
<lamont> I'd really like to see the size of that beast treated as an RC bug for lucid+1
<mvo> lamont: don't ask why, I still have bad dreams from looking at it
<mvo> lamont: I *hope* that I found a solution, _rene_ helped a lot to explain me why certain stuff is needed (or done in the way its done)
<mvo> buy him a beer if you see him
<lamont> oh, goodl
<slangasek> lamont: is acorn still going?
<slangasek> Unable to fetch squashfs sort list; using a blank list.
<slangasek> but no output from mksquashfs after that
<lamont> mksquashfs
<ogra> didnt we quietenm that down ?
<stgraber> slangasek: do you have the URL to what will be the release announcement and release notes for RC ?
<lamont> the Unable... is normal
<slangasek> lamont: yes, the lack of output afterwards is not
<slangasek> stgraber: announcement: https://wiki.ubuntu.com/LucidLynx/RCAnnouncement; release notes: https://wiki.ubuntu.com/LucidLynx/ReleaseNotes; tech overview (which may have been what you meant by release notes): https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
<ogra> slangasek, yeah, there should at least be two additional lines
<stgraber> slangasek: thanks
<ogra> i think the progressbar will only be shown after it finished though
<lamont> http://paste.ubuntu.com/419834/ <-- slangasek: thoughts?
<slangasek> lamont: 22min without further output - so is that build still doing something, or did it die a mangled death?
<slangasek> lamont: is that the mksquashfs?
<lamont> root      6663 92.4 50.3 308968 241044 ?       Sl   13:20  20:28          \_ mksquashfs /build/chroot-livecd/ livecd.ubuntu-netbook-omap.squashfs -sort livecd.ubuntu-netb
<lamont> yes
<lamont> and the right side of my terminal window for the *snip*
<slangasek> doesn't look very healthy to me :/
<slangasek> well, let's let it run for another .5h or so
<ogra> probably use a bucket with water if the alarm clock doesnt suffice :/
<lamont> slangasek: about to run kids to school, will be afk for closer to 1.25h
<ogra> i really wonder what kind fo boards they sent you ...
<lamont> figure ~7am pacifc
<slangasek> ok
<ogra> why dont we see all these issues on our dev boards
<lamont> ogra: run livecd-rootfs in a lucid chroot on lucid on your boards?
<lamont> do you, that is
<ogra> lamont, i did that once, yes
<lamont> ogra: slangasek does it all the time.
<ogra> not atm, since i'm focused on omap, but for getting a squashfs to play with i do such stuff
<ogra> lamont, but on your silicon
<ogra> i dont get why you see these many issues on these new bbg3's
<lamont> maybe we're just lucky?
<lamont> dunno
<lamont> anyway, afk kids->school
<slangasek> hah; so I fix plymouth so that it will actually send mountall a 'c' when the user wants to cancel a fsck
<slangasek> which uncovers a crasher bug in mountall
<slangasek> apparently I'm the first person to ever hit this code path
<cjwatson> slangasek: FYI the beta-2-relnoted bug regarding RAID arrays larger than 2TB still exists
<slangasek> cjwatson: argh?  I thought I saw that the bug was closed - not so much?
<cjwatson> looks like I need to rebuild a generated file; in the meantime, I'm restoring the technicaloverview note
<slangasek> ah, you've just reopened, ok
<cjwatson> discovered as part of attempting to disentangle the hopelessly unintelligible dogpiled bug 527401
<ubottu> Launchpad bug 527401 in partman-base "grub-installer fails to install on a raid1 array" [High,Fix released] https://launchpad.net/bugs/527401
<slangasek> lamont: ah, must've been buffering or something; omap build finished successfully now
<stgraber> slangasek: updated the release announcement for edubuntu. We still have some annoying bugs, I'll release note them and an updated edubuntu-artwork package should be uploaded soonish (so we can test that extensively post-RC).
<ogra> slangasek, \o/
<slangasek> stgraber: could you please consolidate that into 4 paragraphs or fewer?
<ev> I imagine it's too late for Lucid, but can we get upgrade tests for wubi in 10.10?
<ev> in the iso testing tracker, that is
<ev> ara: ^
<ara> ev, noted
<ev> thanks!
<ara> are ubuntu studio cds always that big???
<ara> that does not fit in a CD, that's for sure
<slangasek> yes, it's meant to be a DVD image
<ara> slangasek, ok :)
<ara> slangasek, thanks
<lamont> slangasek: yeah - I think it does some serious processing, and doesn't bother to flush stdout
<ogra> slangasek, i'm happy to report that 21.2 has vmlinuz in /boot :)
<slangasek> yay
 * ogra now hopes there are not other bugs he didnt find yet
<ogra> running an install now ... i'll know more in ~2h
<ogra> yay for speedy HW
<cr3> hi folks, I would appreciate if someone could have a look at bug #567568 in case it might be considered release critical
<ubottu> Launchpad bug 567568 in checkbox "Candidate revision checkbox_0.9.2" [Undecided,New] https://launchpad.net/bugs/567568
<ogra> in-target: Read error on /dev/mtd2: Cannot allocate memory
 * ogra cries
<ara> network-manager is not being included in ubuntustudio's cd
<ara> no worries, it is there
<jdstrand> are server ISOs scheduled for a respin or can I go ahead with my testing on http://cdimage.ubuntu.com/ubuntu-server/daily/20100419.1/lucid-server-amd64.iso
<jdstrand> ?
 * ara wonders how not installing network-manager is seen as an improvement (http://ubuntustudio.org/KarmicKoala)
<jdstrand> slangasek: ^ (regarding server isos)
<pitti> ara: urgh, we had n-m on server ISOs before? that sounds kinda wrong..
<ara> pitti, I am talking about ubuntu studio
<pitti> ah
<ara> pitti, :)
<pitti> ara: ah, I misread jdstrand's comment :)
<jdstrand> heh, sorry
<jdstrand> ttx: do you know if the server isos need a respin? I want to test 20100419.1 but don't want to waste testing on it if it is going away
<slangasek> jdstrand: there are no respins planned
<jdstrand> ok cool
<slangasek> in general, respins will be marked on http://iso.qa.ubuntu.com/qatracker/build/all as such
<jdstrand> slangasek: excellent, that was my next question :)
<ogra> slangasek, so i guess omap has to skip netbook for RC ... i seem to hit that http://paste.ubuntu.com/419902/ and have no idea why
<ogra> funnily it works flawless in d-i
<highvoltage> slangasek: sorry to do it again, I uploaded another edubuntu-artwork package. this one should be the last one.
<mvo> slangasek: if you could have a look at https://code.edge.launchpad.net/~mvo/openoffice/3.2.0-lucid/+merge/23875 that would be much appreciated, this should solve two OOo upgrade issues. I did some testing already and will continue tomorrow with more
<sbeattie> slangasek: crap, live images are missing xfs and jfs utilities: bug 568024
<ubottu> Launchpad bug 568024 in ubiquity "xfsprogs,jfsutils missing from install / live CD, can not use XFS,jfs during installation" [High,Confirmed] https://launchpad.net/bugs/568024
<cjwatson> er, wot
<cjwatson> how'd we screw that one up?
<sbeattie> Dunno, I thought we hit that in the alphas, but got it fixed.
<cjwatson> looks like it may have been broken by the live-common seed split
<cjwatson> 'cept I don't entirely see why
<cjwatson> Package: xfsprogs
<cjwatson> Task: kubuntu-live, kubuntu-netbook-live, xubuntu-live, mythbuntu-live, netbook-live
<cjwatson> same for jfsutils
<sbeattie> cjwatson: what's the difference between casper/filesystem.manifest and casper/filesystem.manifest-desktop?
<cjwatson> ubiquity removes anything in the former but not in the latter after copying the filesystem to the live system
<cjwatson> er, to the installed system
<cjwatson> the difference between those two sets includes such things as the installer itself
<cjwatson> ah, I see the seed bug - slangasek, unfortunately the archive has to be told explicitly when a task spans multiple seeds like this
<cjwatson> there's a Task-Seeds field
<mvo> sbeattie: I uploaded https://edge.launchpad.net/~mvo/+archive/openoffice/+packages with the fixes we talked about. you can help by installing it once the ppa2 version is build (probably in +7h or so :/)
<sbeattie> ah, okay. xubuntu may be somewhat okay, as on it's livecd the former includes xfs-progs|jfsutils, but not the latter.
<cjwatson> yes, kubuntu kubuntu-netbook xubuntu mythbuntu (ubuntu-)netbook are all unaffected, per the Task line above
<cjwatson> affects ubuntu and edubuntu
 * mvo just noticed that ooo actually only took 3,5h to build, not bad
<cjwatson> I imagine this will increase livefs size a bit
<cjwatson> seeds fixed
<slangasek> highvoltage: do you mean that you want a respin of edubuntu for the new artwork upload for RC?
<slangasek> stgraber: ^^
<slangasek> cjwatson: Task-Seeds> sigh :/
#ubuntu-release 2010-04-22
<stgraber> slangasek: depends on when you plan to have RC out ? I can quite easily test amd64 and highvoltage can do i386 (or I can download both).
<stgraber> slangasek: from what I saw going in the archive today, that means having the new edubuntu-artwork and the xfs/jfs issue solved, if there's nothing else that changed, then I'd appreciate a respin yes
<stgraber> (just trying to avoid going from something that's almost-perfect to something worse ;) but the closer we are to the final image, the better)
<slangasek> stgraber: out in < 18h
<slangasek> stgraber: can you do the re-testing before then?
<stgraber> when would we get the new images ?
<slangasek> (and yes, that's all that's all that would change)
<slangasek> stgraber: well, just missed the publisher, so... in 3h40
<stgraber> 11pm here, still possible for me to do the tests, so yeah, please go ahead
<slangasek> stgraber: published; edubuntu respin started; ETA now 2h20; I'm going to be afk when they land, so I've marked them on the tracker preemptively so you have somewhere to report results
<stgraber> slangasek: ok (I could have added them on the tracker ;))
<slangasek> oh, hah, yes you could
<slangasek> :)
<ScottK> slangasek: re the discussion on wine, since it needs to build and then something needs to build against it too before we start final images perhaps it could be first out of the queue as we start to unfreeze?
<slangasek> how long is its build time?
<slangasek> we also have a weekend's-worth of langpack builds incoming
 * ScottK looks
<ScottK> slangasek: 40 - 45 minutes
<slangasek> alright
<slangasek> I think if we're going to accept it (and I haven't reviewed the actual content of the proposed change to confirm that's appropriate), we should do so in parallel with the RC publishing, then, to get a jump on it
<slangasek> (i.e., tomorrow once the trigger is being pulled)
<ScottK> Sounds reasonable.
<ScottK> I didn't review it either.
<ScottK> slangasek: If you have a moment would you please toss "sync 567673 -S unstable" at mass-sync.py?
<slangasek> tossing
<ScottK> Thanks.
<slangasek> done
<ScottK> Excellent.
<stgraber> slangasek: btw, we received the font for the Edubuntu logo this afternoon and I just played a bit with Inkscape to get something that looks like a new logo ;) I guess we'll be working on that with highvoltage tomorrow and so we'll have a new edubuntu-artwork package uploaded shortly after RC is out.
<ScottK> Cleared the non-partner stuff out of New.
<slangasek> stgraber: any progress on the edubuntu re-testing?
<ara> morning
<mvo> good morning ara
<ara> morning mvo!
<ttx> Good morning
<ara> morning ttx
<slangasek> morning, all
<ttx> Hey ara, slangasek !
<ttx> lovely morning for a RC.
<slangasek> mvo: I sent you some comments on the OOo merge in one of the bugs - did you get those?
<mvo> slangasek: thanks, let me check
<mvo> slangasek: thanks, those are good comment! I will answer in the bugreport
<slangasek> cjwatson: seems the fix for bug #515023 didn't cover all the cases where this bug will manifest - bug #567182
<ubottu> Launchpad bug 515023 in hdparm "ATA pass-through commands preventing external HDD to be mounted" [High,Fix released] https://launchpad.net/bugs/515023
<ubottu> Launchpad bug 567182 in hdparm "can't update acpi-support package on lucid running of an external hdd" [Undecided,New] https://launchpad.net/bugs/567182
<slangasek> (but I think that's SRU material at this point)
<slangasek> well, at least on the hdparm side - the acpi-support fix is straightforward
<mvo> slangasek: we may need a lib6 upload too for final, it currently seems to restart gdm happily on hardy->lucid upgrades (which is odd as around beta time I did test that on both real hardware and in kvm)
<slangasek> er, odd
<slangasek> mvo: or, not odd - sigh, a clear regression in the fix for bug #505838
<ubottu> Launchpad bug 505838 in eglibc "Logic to restart services on NSS upgrade misses some" [Undecided,Fix released] https://launchpad.net/bugs/505838
<mvo> yeah, I'm looking into it now
<mvo> oh, how wonderful
<mvo> I thought it might be this one
<mvo> bzr is still fetching the packaging branch
<mvo> anyway, I think I have a fix
<slangasek> well, wait... why would kill -HUP $(pidof gdm) cause a restart?
<slangasek> that's what 'reload gdm' should do
<mvo> its seems like "idlopt" need to be checked for "restart" instead of "idl"
<mvo> in line 337
<slangasek> oh
<slangasek> right, because it's sensitive to upgrade order, meh
<slangasek> mvo: so, be careful to handle both the case where gdm upgrades first (upstart job - idl=restart) and the case where libc6 upgrades first (init script - idlopt=restart)
<mvo> *urgh*
<slangasek> actually
<slangasek> even that won't do it, I think
<slangasek> gdm takes -USR1 as its reload signal, not -HUP
<slangasek> I don't know what gdm does on -HUP
<mvo> seb128 may know
<slangasek> and I'm not testing on this instance of it :)
<mvo> -HUP just killed it in my VM
<mvo> well, restarted it
<seb128> mvo, not offhand no
<mvo> slangasek: could we always use the init script for lucid? its provided for compatbility, right?
<mvo> in the restart of gdm I mean
<seb128>         case SIGHUP:
<seb128>                 g_debug ("Got HUP signal");
<seb128>                 ret = TRUE;
<seb128>                 break;
<seb128> it seems it's doing nothing fancy
<slangasek> mvo: the init script in lucid isn't an init script, it points at upstart-job and won't DTRT
<seb128> there is a comment in the code saying it should be fixed to re-read config, etc
<mvo> seb128: is that true on hardy as well?
<slangasek> seb128: so it ignores it, which isn't what we want either :)
<mvo> slangasek: ok, clearly bad
<slangasek> seb128: does the new gdm handle SIGUSR1 the way the old one did?
<seb128> mvo, it should, gdm didn't change too much in lucid
<mvo> slangasek: let me do a patch and ask for review
<mvo> seb128: ok
<slangasek> mvo: ok, thanks
<seb128> slangasek, what was the old one doing on SIGUSR1? reload config?
<slangasek> seb128: yes
<seb128> the new one seems to toggle debug mode on SIGUSR1
<slangasek> <snort>
<seb128> "                g_debug ("Got USR1 signal");
<seb128>                 /* FIXME:
<seb128>                  * Play with log levels or something
<seb128>                  */
<seb128>                 ret = TRUE;
<seb128>                 gdm_log_toggle_debug ();
<seb128> "
<slangasek> seb128: does the new gdm handle NSS and PAM in-process?
<slangasek> or does it spawn a helper?
<seb128> I don't know
<slangasek> ok
<seb128> pitti, ^ maybe you know?
<pitti> looking
<pitti> PAM is handled in /usr/lib/gdm/gdm-session-worker
<pitti> which isn't the daemon, just spawned when you create a new session
<pitti> hm, but apparently it's not terminated after starting the session
<mvo> slangasek: something simple like http://paste.ubuntu.com/420299/ ?
<slangasek> pitti: but is it terminated when you /close/ the session?
<slangasek> pitti: and are NSS lookups handled by that process, too?
<mvo> oh, so maybe we don't need to handle gdm at all?
<slangasek> mvo: at this point it doesn't appear we *can* handle gdm sensibly, so that may have to be the answer anyway
<slangasek> gdm-binary calls getpwnam, getpwuid
<mvo> thanks!
<slangasek> which means that gdm *should* get restarted (gracefully) after a libc upgrade
<pitti> slangasek: it's restarted when you log out, and gdm login screen comes back, yes
<slangasek> pitti: ok; unfortunately that doesn't help us with NSS, though
<pitti> slangasek: what do you mean with "NSS handling"? calling getpwent() and the like?
<pitti> gdm doesnt use nss.h
<slangasek> mvo: that paste will fix the problem of gdm crashing on upgrade; and it'll handle the upgrade from hardy; so that would be ok with me for upload, despite not fixing the fact that we have other dead code in there
<slangasek> pitti: yes, getpwnam, getpwuid, getXXbyXXX
<mvo> slangasek: ok, do you need a bug with it or can I just upload as it is?
<slangasek> pitti: those calls are the whole reason libc6 has restart handling in its maintainer script
<pitti> getpw* is used in the greeter (which restarts with every session close/user switch) and session-worker (restarts with session close), but also in gdm-binary which runs forever
<slangasek> mvo: if you're not going to make a bug, please make the changelog entry more verbose about what problem you're fixing
 * mvo nods
 * mvo adds a bug then
<pitti> but gdm-binary apparently only needs it to look up the "gdm" user
<pitti> which it runs the greeter session as
<pitti> not for actual real users
<slangasek> pitti: does it call that once and cache the answer?
<pitti> slangasek: no, it looks up "gdm" user/group, then seteuid()s, and forgets everythign
<slangasek> pitti: aha
<pitti> i. e. if the gdm user should change during dist-upgrade, things break
<pitti> but this really really ought not to happen
<pitti> (changing uids during upgrade, I mean)
<slangasek> pitti: that's not even a valid use case :)
<pitti> slangasek: oh, how is it not? pretty much every non-root daemon does it that way?
<slangasek> mvo: so we should only fiddle with gdm in the case that we have an init script, *not* an upstart job, because on upgrades, the switch from init script to upstart job is coincident with the switch from old gdm that needs SIGUSR1, to new gdm that needs nothing
<slangasek> pitti: the uid of the gdm user changing during dist-upgrade?  that's not a valid use case
<pitti> ah, ok
<pitti> *phew* :)
<pitti> mvo: in general, due to gdm's current architecture it doesn't really need a concept like "reloading", though; the daemon only reads custom.conf, and changing autologin on the fly doesn't make any semantic sense anyway
<pitti> mvo: everything else is a separate process
<mvo> do we need to care about reloading gdm at all then? or should this just be removed from the list of services checked by the postinst?
<pitti> it was necessary for hardy (gdm <= 2.20)
<slangasek> mvo: we should care about it as outlined above
<pitti> mvo: you mean s/reload/restart/?
<pitti> merely reloading config files won't make the running gdm use the new libc6
<slangasek> mvo: libc6 configures without reloading old gdm -> X crashes -> gdm still running -> bad
 * mvo nods
<slangasek> if [ "$idlopt" = restart ]; then if $idl reload > /dev/null 2>&1; then echo "done."; else echo "SQUIRRELS" failed="$service $failed"; fi; fi
<slangasek> then in maverick, we remove gdm from the list and kill the nasty special-casing
<mvo> sounds like a plan
<pitti> so, we are down to one NBS: sugar-0.86; this only has one reverse-recommends (sugar-chat-activity-0.86) which is already uninstallable due to missing python-sugar-0.86, so away with it
<slangasek> \o/
<pitti> slangasek: if we sync sugar-chat-activity-0.86 we make it installable again (-3 fixed dependencies to work with 0.88)
 * pitti checks whether it's on any image
<mvo> http://paste.ubuntu.com/420309/
<slangasek> pitti: if it were on an image and uninstallable already, we would've heard before now ;)
<pitti> true that (I thought about "ship")
<pitti> but it's not
 * pitti syncs
<slangasek> mvo: looks correct to me
<slangasek> pitti: nah, we get installability reports for alternate CDs too?
<mvo> thanks, I upload it into my test PPA and run a new upgrade test with it
<mvo> but it should be fine
<ogra> top
<ogra> bah, wrong kbd, sorry
<slangasek> 31337 ogra   10   0   50m  12m  18m S 95  5.3   32:25.67 xchat
<ogra> slangasek, so i found my issue with the ompa netbook image ...
<ogra> *omap
<slangasek> the omap-lomaps - what's the issue?
<ogra> its a bit tricky ... we bumped compcache to get the live session running, then found thats not enough and now omap netbook does only-ubiquity
<ogra> which turned out to always end the install in http://paste.ubuntu.com/419902/
<ogra> running swapoff and rmmodding both compcache modules before starting the install fixes it
<ogra> (since 256M are enough for only-ubiquity that works fine)
<ogra> i'm not really sure what to do about it
<pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt suddenly started to have a lot of -doc packages which want demotion, but I don't see any recent change to the Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj line; was something changed recently which caused that, or should I investigate more?
<slangasek> I honestly don't even know what compcache is, so I have a hard time following that
<slangasek> swap compression?
<pitti> doubledisk?
<slangasek> twitch
<ogra> yeah
<ogra> its the compression tool we use on low ram installs
<ogra> but it seems to have issues with the omap kernel
<ogra> essentially it creates a compressed swap file in ram
<slangasek> ogra: so compcache was bumped specifically for omap, but the reason for the bumping went away again?
<ogra> slangasek, right
<slangasek> and turning off compcache fixes the install
<slangasek> so isn't reverting the compcache change the right thing to do?
<ogra> slangasek, we need to test if its a general compcahce issue with omap or if dumping it back to 25% suffices
<ogra> i'm not sure its not the module collidign with the 2.6.33 kernel
<ogra> we dont use it in that context anywhere else
<slangasek> are lowmem installs on omap a major concern?
<ogra> yes
<ogra> the beagle we currently support has only 256M
<ogra> but we dont run the live session anymore and as soon as you have real swap all is fine (slow indeed, but stable)
<slangasek> oh, man
<slangasek> pitti: curious that these -doc demotions quite specifically cluster around java and gtkmm - but I also don't see what change would have triggered this
<Riddell> slangasek: do we have an ETA for release?
<elmo> Riddell: I hear the 29th is likely
<cjwatson> slangasek: hdparm> ok, will check
<cjwatson> pitti: no change I know wof - I'll investigate
<cjwatson> *of
<slangasek> Riddell: ETA: 10 more test cases
<slangasek> Riddell: I figure a couple more hours, at least
<slangasek> ttx, mvo: do either of you know if the warning at https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#MySQL%20upgrade still applies now that mysql-dfsg-5.0 is removed?
<mvo> I don't know, sorry
<slangasek> no worries
<cjwatson> pitti: the problem is that supported *MUST* be last in STRUCTURE - fixing now
<cjwatson> mvo: ^- note for future reference :)
 * slangasek waves
<mvo> cjwatson: ups, sorry, can we add a comment maybe in the file?
<slangasek> cjwatson, ttx: does the disabling of splash on server only apply to new installs?
<cjwatson> yes
<slangasek> ok
<stgraber> slangasek: amd64 done for edubuntu, I'll start i386 now
<slangasek> stgraber: great, thanks
<doko_> mvo: is this eglibc upload planned before the final?
<slangasek> doko_: it's fairly important to resolve ASAP, before users en masse start upgrading and having their GDM restarted out from under them
<mvo> doko_: so yes
<cjwatson> mvo: done
<cjwatson> mvo: (documented in germinate(1) too)
<mvo> thanks
<pitti> cjwatson: ah, cheers!
<doko_> mvo: will you upload? I don't have any patches pending, no fix for bug 417757
<ubottu> Launchpad bug 417757 in eglibc "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups" [High,Fix released] https://launchpad.net/bugs/417757
<mvo> doko_: sure, I can do that
<cjwatson> slangasek: so should we use udevadm info in hdparm_options if it doesn't already have $ID_PATH, do you think?
<stgraber> highvoltage: Hey, could you rsync i386 and test it quickly so we can make super-sure that it works ? ;)
<slangasek> cjwatson: is that the most effective means of getting the information, or is poking under /sys/block/$dev/device better?
<cjwatson> it seems the shortest way with least messing about
<cjwatson> http://paste.ubuntu.com/420367/ is what I'm thinking of
<cjwatson> maybe should add 2>/dev/null || true in there somewhere
<cjwatson> so http://paste.ubuntu.com/420368/
<slangasek> cjwatson: fair.  I assume that udevadm command is tested, since I'm unfamiliar with its semantics
<cjwatson> $ udevadm info -n /dev/sda -q property | sed -n 's/^ID_PATH=//p'
<cjwatson> pci-0000:00:1f.2-scsi-0:0:0:0
<slangasek> cjwatson: also, /usr/lib/pm-utils/power.d/95hdparm-apm might need some work, it calls 'hdparm -i' on each device before ever calling hdparm_options
<cjwatson> crap, yeah
<cjwatson> wish I'd never touched this package now :)
<slangasek> :)
<slangasek> cjwatson: I think this bit can reasonably be deferred to SRU given that so far only one user seems to have run into it, so if you have higher-prio bugs...
<cjwatson> the only other thing I'm working on right now is the apparent busybox shell bug I mentioned in the foundations meeting yesterday
<slangasek> ok
<cjwatson> which may be a "could do with a break" thing soon anyhoe
<cjwatson> *anyhow
<highvoltage> stgraber: doing now..
<highvoltage> (syncing, that is, but it should go fast)
<ara> stgraber, I am doing i386, almost finishing it
<lool> slangasek: Would you consider a kexec arm bugfix: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/568283 ?
<ubottu> Ubuntu bug 568283 in kexec-tools "kexec fails on ARM boards because initrd is placed too close to the kernel image" [Undecided,New]
<lool> I tested kexec with just a kernel some weeks ago, after fixing it, and it worked with just a kernel; this patch fixes it for initrd as well
<ogra> lool, tested on all armel arches ?
<lool> ogra: I was told by kernel folks that it is broken on all arches
<ogra> yeah, but was the fix tested on all arches ?
<lool> I can certainly believe that if the offset if fixed and the kernels are about the same size (== too big) on all Ubuntu subarches, it will appear on all subarches
<lool> ogra: No, but does it matter given that it's broken on all subarches?
<ogra> i wonder if you can just generalize in that 0x8000000
<lool> ogra: generalize?
<ogra> well, if 0x8000000 fits for all platforms
<lool> 0x800000 is 8.4 MB or so; I can certainly believe that all our Ubuntu ARM kernels are bigger than that uncompressed
<lool> In fact it's uncompressed size + compressed size
<ogra> i.e. are you sure there is no bootloader code in ram befor the kernel for example that would move the kernel to a later place
<ogra> i could imagine thats the case with redboot
<lool> ogra: I dont understand what you're proposing
<ara> edubuntu covered
<lool> ogra: This is for kexec
<lool> ogra: no bootloader is involved?
<ogra> lool, i'm proposing nothing, i was just asking
<ogra> lool, so the first kernel doesnt sit in ram ?
<ogra> the one you load the second one with
<slangasek> lool: would be considered, yes
<lool> slangasek: Ok thanks
<slangasek> ara: great, thanks!
<lool> slangasek: it's in supported-kernel, so probably only on the DVD, didn't see it in any task or other seeds
<slangasek> lool: correct
<lool> ogra: The kernel loading the other kernel is in RAM, yes; I am not sure what you're asking
<stgraber> ara: ok, I found quite a few bugs on edubuntu 32 and 64 bit, all of which are affecting the LTSP install, so don't worry about these, I'll get those fixed very soon and fixed for final
<slangasek> so that leaves only edubuntu i386 upgrade untested?
<stgraber> slangasek: seems like I'll actually need to upload both edubuntu-artwork and ltsp to fix our current bugs, though the ltsp change affects a file that's only used by edubuntu and won't affect ubuntu alternate (which works correctly)
<ogra> lool, well, 0x0 has possibly the bootloader that loaded the first kernel 0x0+$sizeof_first_kernel occupies some space -> kexec gets run new kernel gets loaded to 0x0+$sizeof_first_kernel up to 0x0+$sizeof_second_kernel ... or do i misunderstand the principle ?
<slangasek> stgraber: those are both post-RC, I guess (hope)?
<ara> slangasek, upgrade edubutnu is marked as started by sbeattie
<stgraber> slangasek: yeah
<cjwatson> grr, busybox sh does subtle and terrifying things with the stack
<slangasek> ara: excellent
<slangasek> Riddell: ETA> RSN
<ogra> lool, i was just wondering if 0x8000000 would suffice for that amount of stuff on all arches
 * Riddell gets excited
<sbeattie> slangasek: edubuntu upgrade eta completion in 10min or less.
<slangasek> cool
<slangasek> it's going to take me a lot longer than that to get everything published; guess I should get started :)
<lool> ogra: I'm not sure what memory you're considering; I'm not familiar enough with the kexec and early boot allocation steps, what I see is that the current offset is too small for the size of our uncompressed + compressed Ubuntu kernels, so bumping it b a factor of 16 sounds good
<slangasek> mvo: if you have the eglibc upload ready, I would accept that now to get a leg up on upgrades
<ogra> lool, ok
<slangasek> (rather, I would encourage another release team member to accept it since my hands are full)
<mvo> slangasek: ok, uploading now
<mvo> slangasek: what are the chances for OOo ? a auto upgrade test with the ooo ppa is currently running
<slangasek> mvo: please upload it; I'll want to give armel a little more time to get the last one built before accepting, but we should have time to get it built and on all images in time for next week's ISOs
<slangasek> (and in the meantime I'll push as much as possible through the queue)
<mvo> slangasek: ok, cool. I will do it, if needed I will do another upload (as I said, full end-to-end test is still running). but I think its final
 * mvo mubbles something about kvm being slow today for now obvious reason
<slangasek> ok
<ogra> slangasek, so plars tested 25% and 10% compcache and saw issues as well, i'd like to propose http://paste.ubuntu.com/420398/ (and adjust the default cmdline accordingly in debian-cd for omap)
<sbeattie> slangasek: edubuntu i386 upgrade complete.
<slangasek> sbeattie: huzzah
<ttx> slangasek: anything you need from the server team, except converging to 110% test coverage rate ?
<cjwatson>  * The size 504 was chosen because the Ultrix malloc handles that size
<cjwatson>  * well.
<cjwatson> how to tell the code you're working on is shiny and modern
<slangasek> ogra: have my hands full for the next couple of hours staging the RC for other stuff; perhaps cjwatson or pitti can review?
<slangasek> ttx: test test test!
<ogra> slangasek, oki
<ttx> slangasek: ok :)
<cjwatson> ogra: that patch is OK by me
<ogra> cjwatson, merci, so i can upload initramfs-tools to the queue ?
<ogra> (and adjust debian-cd om antimony)
<ogra> *on
<cjwatson> yes
<ogra> thanks (better asking twice at that stage of release :) )
<mvo> if someone from ubuntu-archive could check #567148 that would be nice (another relatively small upgrade issue)
<slangasek> ogra, asac: is bug #443147 still in progress for 10.04?
<ubottu> Launchpad bug 443147 in firefox "Firefox on ARM inappropriately adds scroll bars to many frames and images" [Unknown,Confirmed] https://launchpad.net/bugs/443147
<asac> slangasek: yes. we have a fix.
<asac> slangasek: but too late for RC ... i have committed it and chrisccoulson will push an update if nothing else pops up today
 * slangasek marks 'fix committed' then :)
<asac> thanks
 * cjwatson finds gross gross gross busybox bug that caused that RAID configuration difficulty
<cjwatson> http://paste.ubuntu.com/420414/
<ogra> oh my
<cjwatson> there's an identical fix already in dash since 2007, although my first working attempt actually reproduced that fix almost character by character without having looked at it
<ogra> -ETOOMANYSHELLS
 * cjwatson punts queuewards
 * slangasek pulls the mirror trigger
<ogra> wohoo
<slangasek> ogra: do we need to get that initramfs-tools upload in, so we can try again for omap?
<ogra> slangasek, did you plan to re-roll any images right now ?
<slangasek> ogra: just omap, if it helps get this sorted
<ogra> it can wait until next build imho, we know it works if we manually swapoff and unload the modules
<ogra> sure
<slangasek> better to do it now than tomorrow when the archive may be in flux
<ogra> yeah, indeed
<slangasek> cjwatson: ^^ you already reviewed the initramfs changes then, yes?  Can you go ahead and accept?
<cjwatson> the previous initramfs-tools change also in the queue was mine
<slangasek> cjwatson: btw, queuebot seems down
<cjwatson> could somebody review that?
<slangasek> ok, looking
<cjwatson> hmm, it seems to be still running here - I'll restart it
<cjwatson> (sorry, may be a bit noisy in a moment)
<slangasek> o hai bot
<cjwatson> err, wut
<cjwatson> um, I think it may be the server side that's busted
<cjwatson> not seeing initramfs-tools on http://people.canonical.com/~ubuntu-archive/queue/lucid/unapproved/
<slangasek> ah
<cjwatson> everything from ubuntu-mono on is missing
<slangasek> cjwatson: ack for initramfs-tools 75
<cjwatson> stuck on a lock - I've killed it
<cjwatson> should catch up in a few minutes
<cjwatson> ok, accepted
<slangasek> smoser: all ready for you to publish
<smoser> ok. just finishing the pages updates. you will promote-daily or you want me to
<slangasek> smoser: if you can do it great, otherwise I can do it in a bit
<smoser> k. i'll do it.
<slangasek> smoser: thanks
<slangasek> Riddell: wiki.kubuntu.org doesn't love me, but https://wiki.kubuntu.org/LucidLynx/RC/Kubuntu has a typo - s/Realease/Release/
<Riddell> fixed thanks
<Riddell> and you can just use wiki.ubuntu.com of course :)
<slangasek> yah, but by that point my browser didn't want to let go... :)
<ScottK> ogra: Is xf86-video-omapfb on the omap image?
<nhandler> lol, omgubuntu is already announcing the RC
<smoser> slangasek, i seem to be running into a problem.
<smoser>  /srv/ec2-images/releases/lucid/rc wasn't written as expected (not a dir)
<slangasek> smoser: ah?
<smoser> shoot.
<smoser> never mind.
<slangasek> ok
<smoser> actualy, no. i still need some help.
<slangasek> smoser: what've you got?
<smoser> so that error is from my script, expecting that when i invoked for-project ubuntu publish-release lucid 20100420 server-uec yes rc
<smoser> that it would create that dir above
<smoser> instead, i think its creating
<smoser>  /srv/ec2-images/simple/lucid/
<smoser> s/think/see that/
<slangasek> s/yes/named/
<slangasek> sorry
<slangasek> that's not at all obvious
<slangasek> the 'yes' is used when the directory structure is like the one on releases.ubuntu.com (well, more precisely, it's used when the target *is* releases.ubuntu.com)
<slangasek> and when you're publishing with per-milestone directories, 'named'
<smoser> so 'named' for 'release' also then, right ?
<smoser> that seems to have fixed it
<slangasek> yes
<smoser> alright. the 'all' acls are being set right now.
<smoser> and i've updated the ami pages.
<slangasek> spiff
<ScottK> Is it OK to start accepting seeded packages after review now or should it still wait?
<slangasek> ScottK: please accept them but keep an eye on the build queue as you do so, so it doesn't get too deep; there are some others that I wanted to get priority in the queue, but I don't now remember which ones they were and it'll be a bit yet before I can give it my attention, so no sense in leaving the builders idle in the meantime
<ScottK> OK.
<ScottK> Will do.
<mvo> slangasek: please reject openoffice - "libevoablx.so" has a different name depending on the architecture (i386/amd64)!
<slangasek> lamont: so is sycamore a little on the slow side?
<slangasek> mvo: done
<mvo> thanks
<slangasek> mvo: what name does it get on armel? :)
<lamont> slangasek: should be just like the others... let me go stare at the guts
<mvo> slangasek: I think the suffix there is "TAKESTOOLONGTOBUILD"
<slangasek> lamont: ok; then I'm probably just being impatient
<slangasek> ah crap, just rejected -dictionaries too
 * slangasek fishes it out of reject
<lamont> Started 1 day, 9 hours, 58 minutes, 39.1 seconds  ago.
<slangasek> lamont: ok, so that's just me being impatient :)
<lamont> yeah - still have a ways to go... ISTR 42 hours to the timeout fail last time
<lamont> which means I should peek in on it in about 5 hours or so
<slangasek> lamont: would be nice if https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 had the exact time, instead of "started on the 20th"
<slangasek> though I guess that's not your dept :)
<lamont> since this is the "well, lets see if it crashes at the bottom of the hill again" rebuild with no changes other than being on a different identical machine
<ScottK> slangasek: Careful with lamont or you may get the exact time he killed the build there.
<lamont> ah..  http://launchpad.net/builders/sycamore
<slangasek> lamont: oh, thanks :)
<slangasek> lamont: so if you check in on it in 5h and find that it *has* died, please prod here to have someone accept mvo's newer OOo upload
<lamont> so... why is xchat suddenly deciding that I must be in mid-text selection and highlighting the world?
<lamont> ah, ok
 * ScottK looks for arch all things to accept ...
<slangasek> not necessarily advantageous, we should be getting a langpack dump here soon too :)
<ScottK> There's i386 builders laying around waiting and amd64 already has quite a backlog
<lamont> slangasek: so... how would you feel about a 4 hour timeout on armel, instead of 2.5 hours?
<slangasek> ScottK: fair 'nuff
<slangasek> lamont: very sad
<maxb> slangasek: I think all of Launchpad's "friendly times" display the exact timestamp as a tooltip on hover
<slangasek> maxb: huh, nice
<lamont> yeah - but the stuff that times out elsewhere, sometimes just times out on armel... the timeout we saw on satinash was during dpkg-deb. the other solution is a packaging change in oo.o to not have insanely huge binary packages.
<slangasek> lamont: liposuction is not a packaging change
<lamont> totally is
<lamont> I can just see it.  openoffice.org-core-part{1,2,3,4,5,6,7,8}
<ScottK> We could probably lzma the .debs then.
<slangasek> isn't that what's actually being done here that's taking so long?
<slangasek> I thought OOo was opted in to lzma
<slangasek> lamont: oyah, how much ram does sycamore have?  it's probably deep in swap
<slangasek> since lzma compression is mem-intensive
<lool> slangasek: ericm did some testing of the kexec-tools binaries from a PPA on #ubuntu-arm and confirmed they fix the issue; I discovered that two of our 4 ARM kernels are broken WRT kexec -- but 2 out of 4 are working  ;-) -- so it's half useful, but we probably want to SRU kexec support in these kernels anyway
<lamont> 512M, just like all the boards
<slangasek> lool: sounds fine
<lool> slangasek: I uploaded the package seconds ago; will show up in unapproved soon
<lool> http://paste.ubuntu.com/420471/ debdiff
<lool> slangasek: bug #517841 tracks kexec borkenness in the kernel
<ubottu> Launchpad bug 517841 in linux-ti-omap "KEXEC support broken" [Undecided,Confirmed] https://launchpad.net/bugs/517841
<lool>  subject: [ubuntu/lucid] kexec-tools 1:2.0.1-1ubuntu3 (Waiting for approval)
<lamont> -$stalled_pkg_timeout = 150;
<lamont> +$stalled_pkg_timeout = 240;
<lamont> slangasek: wanna +1 that?
<slangasek> lamont: go for it
<lamont> well, will you, rather than do you want to.
<lamont> ta
<lamont> slangasek: so I fully expect the current build will spend too long in dpkg-deb
<lamont> I suppose I could be evil and tickle the build output via /proc/NN/fd
<slangasek> lamont: the change won't take effect until the next attempt?
<pitti> ooh, time for queue flush? :-)
<slangasek> pitti: cf my comment to ScottK above
<lamont> slangasek: correct
<cjwatson> hm, queuebot is suffering from excessive caching
<pitti> slangasek: if you need/want help with review, should we talk about criteria before?
 * cjwatson pokes
<lamont> unless you know how to modify perl variables in a running perl instance.
<slangasek> lamont: tickling would be nice then, but not essential
<pitti> slangasek: i. e. would you prefer only accepting bugs which aren't suitable for SRU (like installer fixes) and minimize package churn now, or also accept "safe and obvious" changes for RC bugs?
 * lamont goes to test the theory on some less time-gobbling build
<lamont> 'twould be nice if qbot did one line, instead of 99 million
<slangasek> pitti: for the moment I think the build queues don't need more help, let me finish getting RC out and then we can talk :)
<pitti> alright :)
<lamont> totally wicked cool.  tickling works.  with apologies to the eglibc/ppc build log.
<lamont> slangasek: in fact, I think I'll just do a while loop that tickles the oo.o build every 90 min or so
<slangasek> heh, k
<ogra> ScottK, nope, it isnt
<ScottK> ogra: OK.  Thanks.
<ogra> ScottK, buut users use it on omap for accelerating 2D
<ScottK> ogra: We since got an OK to accept stuff that was on an ISO, but I was wondering  at the time if I could go ahead and accept it.
<lamont> Compiling: sw/source/filter/html/wrthtml.cxx
<lamont> DEBUG: Thu Apr 22 16:13:21 BST 2010
<lamont> Compiling: sw/source/filter/html/SwAppletImpl.cxx
<lamont> the DEBUG: timestamps are all me.
<ogra> ScottK, ah
<slangasek> ogra: omap respin queued, btw; will fire off as soon as initramfs-tools finishes publishing
<ogra> slangasek, thanks :)
<ogra> slangasek, there is also still bug 563618 but i'm happy to discuss that tomorrow
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<ogra> since you are very busy it seems
<ScottK> But since it's armel only, it needn't wait.
<ogra> :)
<lamont> ogra: fix the clock?>
<ogra> lamont, without battery thats hard :)
<lamont> mountall bug which does not give the user a maintenance shell when fsck exits but makes it go into an endless loop
<lamont> HOW ABOUT WE FIX MOUNTALL?
<ogra> lamont, its not mountall and a fix is planned by ted tso
<ogra> fsck needs an option that actually ignores the clock instead of forcefully trying to fix it
<slangasek> the mountall bug is fix-committed
<ogra> he agreed with that
<slangasek> but at the end of the maintenance shell you would still have to reboot
<ogra> yeah
<ogra> thast why i set the clock to last mount time instead
<ogra> (+1 min to prevent a race)
<ScottK> pitti: There's a build slot open (the only pending am64 stuff in unseeded Universe).  I can accept something unless you've got something that's a priority?
<pitti> ScottK: gnome-keyring perhaps
<ScottK> pitti: If you've reviewed it, go ahead.
<pitti> ScottK: no, I uploaded it myself
<ScottK> Ah.
<pitti> ScottK: nvidia-graphics-drivers-96  then
<pitti> I can review it in a minute
 * pitti @ phone
<pitti> ScottK: accepted nvidia
<pitti> ScottK: for the next slot, mono is pretty clear -- it's a dependency fix which we need to fix for final (I uploaded it, so would be good to have it reviewed/accepted by someone else)
<ScottK> pitti: I'll have a look and see if I think I'm comfortable with reviewing it.
<pitti> I reviewed libgphoto2, that's also okay and unambiguously appropriate for final (armel ftbfs fix)
<ScottK> OK.
<pitti> so we spoonfeed the buildds now, instead of just building a queue?
<ScottK> Looking at mono now.
<ScottK> slangasek said he had some priority stuff and asked me not to let it get too backed up until they were in
<pitti> ack
<pitti> it doesn't help to have amd64 build wine and eglibc, of course
<pitti> but the nvidia driver is a quick one (just shuffling a few bits around)
<ScottK> Wine is only in there because there's another build that has to come after it and it's on Ubuntu Studo's ISO
<slangasek> yeah, eglibc and wine (if accepted, which it has been) were two of the priorities
<ScottK> mono is easy enough.
<cjwatson> I can find some review slots if needed, but given the above I won't jump in ad hoc
<ScottK> slangasek: Any others?
<slangasek> I have my brain back now, there are a couple more priorities which I'm just about to push through
<pitti> I can help with review, too, but before we start I'd like to have some consensus which level of fixes we still accept -- i. e. only the absolute minimum (installer and component-mismatches), or securityish ones like gnome-keyring, or also ones which we could SRU, but have safe fixes
<pitti> so that slangasek can get to some much needed sleep and rest :)
<ScottK> pitti: Makes sense.  I guess we wait for direction from the boss then.
<slangasek> pitti: let me finish my cherry-pick, then give me 15min afk, then we can pow-wow?
<pitti> slangasek: sounds good (I'll be at dinner then, but I'll be back later on)
 * pitti downgrades build score of the older glib2.0
<slangasek> ogra: omap build started 10min ago
<ogra> slangasek, thanks a lot
<slangasek> ok, done picking over the queue; afk for a few
<lamont> killed the glib2.0 ubuntu3 build on hubbard, since it's stale
<slangasek> pitti, ScottK: so the accept criteria I have in my head are: things that break the installer or upgrades; things needed to get the archive back in shape (component-mismatches, FTBFS fixes); gross security bugs (like gnome-keyring); and selectively, fixes for other high impact bugs *if* the change is obviously correct and carries minimal risk of regression
<ScottK> OK.
<ScottK> slangasek: Would you review gnomee-keyring then?  Sounds like it's a priority.
<slangasek> ure
<slangasek> sure
<ScottK> slangasek: clamav doesn't ~ fit that criteria, but debconf handling is reasonably broken with what we have and the peinding upload syncs us with with Debian (and that the maintainer is confident enough of he's putting it in Volatile for Lenny users)
<slangasek> oh, I think I have one more category in there - things that break users' ability to boot their systems
<slangasek> but chances are it'll be me uploading those, and someone else gets to review them :)
<slangasek> ScottK: looking at clamav now
<ScottK> slangasek: Thanks.
<slangasek> ScottK: hmm, haven't ruled it out, but too big for me to review at my current attention level
<ScottK> slangasek: I understand.
<ScottK> Iit's not urgent to get into today, I'd just really like it in for the release.
<pitti> slangasek: understood, thanks
<cjwatson> uploaded hdparm per our discussion earlier
<stgraber> slangasek: did you see ltsp -0ubuntu8 going through the queue ? I uploaded it this morning but can't find it in the queue or in the archive (last mail from LP was Waiting for approval)
<ScottK> stgraber: It's still in queue.
<stgraber> ScottK: ah, found the issue, I wasn't looking at "unapproved" ;)
<lamont> slangasek: what did you do to acorn? :-p
<lamont> slangasek: whatever livecd build you were doing on acorn, do it again maybe? (rebooted acorn from apparent faceplant)
<ScottK> lamont: I think he went for a nap.
<lamont> I don't blame him
<lamont> anyway, oh hai. I killed some dead thing. sry
<stgraber> slangasek, cjwatson: As edubuntu finally has its new artwork, we'd like to update our gfxboot logo, where should we do that and how ?
<slangasek> lamont: oh man, again? :P  Ok, re-launching
<lamont> sorry - have serial this time.
<ScottK> slangasek: I screwed up and accepted librsvg for lucid-proposed.
<ScottK> Arrgh.
 * ScottK takes a break.
<slangasek> lamont: um... failed again, much faster this time
<slangasek> ScottK: does that need removed back out again?  I don't think having packages in -proposed before final is out hurts anything - or were you just concerned about the procedure?
<slangasek> stgraber: I'll have to defer to cjwatson on that one, sorry
<ScottK> slangasek: I don't think there's any actual harm.
 * ScottK figures rapid confession of errors is a good policy right before release.
<ScottK> slangasek: I've been through most of the stuff that was obvious enough for me or I didn't upload it and amd64 is keeping up OK.
<slangasek> ScottK: ok, cool.  now that the more-urgent-y stuff is done, there's no reason to rate-limit the accepts since that'll just leave the queue empty later when we're all sleeping :)
<ScottK> OK.
<slangasek> lamont, ogra: oh, blast; we already have archive skew affecting armel, which is why the second omap retry failed - glib, mono uninstallable :(
<slangasek> ogra: will try again once that's cleared up
<ogra> slangasek, thanks, no hurry im sure it will work at some point
<slangasek> ScottK: quassel> so the only substantive Linux-affecting changes are the ones already in debian/patches - important enough to have the version number bumped to risk a build problem between now and Tuesday?
<ogra> and i'm confident its all fixed :)
<ScottK> slangasek: Technically the benefit is low, but I think the risk is low (we've never had any misbuild problems with the package), but the social benefits to the upstream relationship are worth the (IMO minimal) technical risk.
<pitti> oh, we are already accepting lucid-proposed uploads?
<pitti> (librsvg)
<pitti> or was that an accident?
<ScottK> pitti: Not on purpose
<ScottK> (it was an accident)
 * slangasek gets some sleep
<pitti> slangasek: sleep well!
<pitti> mvo: I'm currently reviewing OO.o, and TBH I don't understand the changes just by looking at the diff
<pitti> mvo: was that already discussed with ccheney/Debian?
<pitti> mvo: also, why was debian/openoffice.org-common.links dropped entirely?
<mvo> pitti: what can I do? should I write up the design in the bugreport?
<mvo> pitti: openoffice.org-common.links should not be dropped, let me check the diff
<pitti> mvo: I'm primarily interested in how much you trust this and how much it was tested
<pitti> mvo: and it adds several debian/*.links.in files
<pitti> which add retistere-components symlinks
<pitti> those look related to "change the way stuff is registered"
<mvo> pitti: I talked to _rene_ about it, but did not get that much feedback (other than a principal "that should work"). I talked to ccheny but did not get much feedback
<mvo> pitti: it adds two links.in files, yes and changes the way the postinst scripts run
<mvo> pitti: please reject it, the -common.links removal is a accident
<mvo> pitti: sorry for that
<pitti> mvo: (don't get me wrong, I trust you :) but for peer review to make any sense I want to at least roughly understand what's happening here)
<ScottK> pitti: There is a sync request pending for nautilus-share that ought to be reviewed by someone who understands Samba better than I do.  The diff is http://pastebin.com/CtNwdmYb.  If you're comfortable with it, the mass-sync rune would be "sync 565418 -S unstable".
<mvo> pitti: sure, and it already uncovered the removal of the -common.links file
 * pitti has NFC about samba, though; slangasek has, perhaps he can review that when he's back?
<pitti> mvo: I take it you already tested upgrades with that version?
<mvo> pitti: so, the reason why the pre-depends on openoffice.org-core were needed is that it needs  a working services.rdb file and a working uno (ure) to register the components
<mvo> pitti: but the pre-depends make apt fall over badly
<pitti> right
<mvo> pitti: so the idea is to make sure external components are identifyable via the links in the external-components dir
<pitti> mvo: those packages configure stuff in preinst? that seems wrong..
<ScottK> pitti: OK.  I thought you knew about everything. ;-)
<mvo> pitti: and then openoffice.org-core can unregister (revoke) all of them when it upgrades
<ScottK> I'll ask him when he returns
<bdmurray> bug 568628 would be worth looking at
<mvo> pitti: yes, preinst of -evolution is used to unregister the components
<ubottu> Launchpad bug 568628 in base-files "LTS not included in motd" [High,In progress] https://launchpad.net/bugs/568628
<pitti> ScottK: unfortunately I don't yet have that black belt :)
<mvo> pitti: ooo needs the component (from ooo-evolution) still loadable in order to unregister
<pitti> mvo: (rejected)
<ScottK> pitti: I do recall slangasek saying he wanted to give the current OOo build on armel a chance to finish.
<mvo> pitti: thanks, I already have a new one with the correct file ready
<pitti> ScottK: right, and it seems we need a new upload anyway
<pitti> ScottK: right, it's at dh_strip, looking good
<pitti> I'm eager to get it accepted soonish, so that it can finish on arm on time
<mvo> pitti: so now ooo-evo checks if it can register/revoke (if ooo-core is configured). if not, that is ok, ooo-core will take care of it, it will unregister components when it goes into unconfigured state and re-register them when finished
<pitti> mvo: did you run "install from scratch" and "upgrade from hardy/karmic" tests with that?
<ScottK> Last time it timed out on one of the dpkg-deb attempts, so we aren't home free yet.
<mvo> pitti: yes, that worked, but uncovered a bug in the version in my https://edge.launchpad.net/~mvo/+archive/openoffice/+packages PPA
 * pitti gives the buildd hamsters some more proteins
 * pitti hugs mvo, thanks for wrestling with this beast :)
<mvo> pitti: (broken symlinks because OOo has different names for the lib on different architectures, this is why there is a links.in file now :/
<asac> new ooo?
<asac> oh no
<mvo> pitti: yeah, its a challenge
<pitti> mvo: ok, so let's accept this after the current armel build finished and the new one is uploaded
<mvo> pitti: I did get various register/unregister/upgrade on my amd64 and once its build in my PPA I will do another i386 upgrade test
<asac> previous armel build didnt even finish :(
<ScottK> asac: It timed out during the build.
<asac> ScottK: ah ok. so its not in yet?
<ScottK> lamont installed some special magic that should help this time.
<ScottK> Not yet, no.
<mvo> pitti: hrm, openoffice.org-common.links needs to become openoffice.org-common.links.in otherwise it will clean it away, but there is no content change, just a rename
<pitti> mvo: sounds fine
<mvo> thanks
<ScottK> pitti and slangasek: I think we'll need to come to a decision about if we are going to allow Sparc's progress to gate what we let in for the release.  There's already more than enough stuff to retry to keep Sparc busy for quite a while.
<ScottK> My recommendation would be to not worry about archive skew and Sparc.  It will get as much built as it can.
<pitti> it says "six hours", no idea how reliable that is
<ScottK> That's so far.
<ScottK> I may be wrong, but I suspect it will run way behind.
<pitti> it'll build main first, right? so that CD images have at least a good chance to get done, and universe can catch up until the bitter end on Thursday
<ScottK> Yes.
<pitti> for my part, I'm pretty much done with unapproved, from what I feel able to sign off
<pitti> OO.o is still on the plan, and I'm currently reviewing busybox
<pitti> slangasek: ah, found the IRC discussion with directhex about indicator-application (I was going to reject it first, but asked him first); accepted and checked banshee-community-extensions; I'll watch/process binNEW/NBS for that
 * pitti waves good night
<ScottK> Good night pitti.
<mvo> pitti: I uploaded a new ooo, you may wait with accepting it a little bit though, the ppa should finish tonight
<mvo> pitti: and then I can run another test upgrade
<ScottK> We still want the current armel build to finish (or not) first in any case.
 * lamont looks in on it
<lamont> mmc0: Timeout waiting for hardware interrupt.
<lamont> asac: what are you guys doing to me?
<asac> ouch
<asac> lamont: not progress in build log forever?
<lamont> oh.  oo.o is in dpkg-shlibdeps.
<lamont> it's getting _close_
<lamont> well, to dpkg-deb which is where the pain is
<lamont> asac: that error was from acorn
<lamont> so maybe during a livecd-rootfs build
<lamont> anyway, I expect that we'll see oo.o  finish at some point.  and hopefully 4 hours of idle time is enough, otherwise I'll need to hack in the same "progress" hack
<lamont> while [ -d /proc/16409 ]; do echo DEBUG: $(date) >> /proc/16409/fd/1; sleep 90m; done & <-- I win
<asac> great. thats life ;)
<cjwatson> stgraber: erm.  it's kind of late.  could you check out lp:~ubuntu-cdimage/debian-cd/ubuntu (you won't be able to commit there, it's just a mirror) and send me image files that match data/lucid/edubuntu.{pcx,png} in dimensions and format?
<stgraber> cjwatson: I can certainly do that
<stgraber> cjwatson: for the kind of late, that's what I told the guys in Canonical design team over the last 6 weeks ;)
<ev> can someone remind me if freeze exceptions apply to wubi, or if I can upload a version with refreshed artwork to match the new branding
<cjwatson> stgraber: I can imagine ...
<stgraber> highvoltage: ^ I've got to go to a meeting, would be awesome if you could do that. We'll need to re-render the logo with the font in white and have it replace the current logo on both files.
<lamont> note to self:  2010-04-22 21:45
 * lamont wakes up and puts that in the build log where it'll actually have context
<highvoltage> cjwatson, stgraber: http://people.ubuntu.com/~jonathan/files/lucid/edubuntu/bootimages/
<doko_> how are the bets for the OOo build to die?
<ScottK> We're all cheering for it to succees, but I don't think anyone is willing to put up money that it will.
<ScottK> Of course, lamont's special magic may be enough.....
<lool> slangasek: The dash NEWS entry is useless in Ubuntu; is it useful to drop it?  (it's shown to apt-listchanges users which is in main, not sure if that's common); http://paste.ubuntu.com/420694/
<lool> slangasek: uploaded, but please reject if you feel that's too risky
<lool> the other entries were relatively relevant, except perhaps the xkeyboard-config one related to ctrl-alt-backspace which I think we also disable since a while
#ubuntu-release 2010-04-23
<doko_> slangasek: please consider llvm/clang before the final. basically disabling --with-oprofile
<kees> ScottK: okay, a refresh of the selinux refpolicy thanks to TreSys (and additional fixes for the upstart bits) have been uploaded in "refpolicy-ubuntu" and "selinux".  tests out well with vastly reduced warnings in selinux mode.  regression potential is low, since it doesn't actually work very well without this upload.  ;)
<kees> ScottK: LP: #568744 for reference
<ubottu> Launchpad bug 568744 in selinux "Lucid SELinux Policy Update" [Medium,Fix committed] https://launchpad.net/bugs/568744
<ScottK> kees: Accepted.
<kees> ScottK: okay, thanks.  I'm still working on refpolicy-ubuntu; LP surprise-rejected it.  not sure why
<ScottK> Because it can ....
<ScottK> OK
<kees> it's a src-format-3 package, so I assume I did something wrong.  though local builds are fine.
<lamont> you have got to be kidding.  is oo.o going to finish ?  only time will tell.
<lamont> but that 4 hour timeout idea?  not a win
<lamont> given that the dpkg-deb run started _8_ hours of output-free-lzma HELL ago
<slangasek> yeesh
<lamont> slangasek: what if we didn't lzma oo.o?
<lamont> buildd   27090 10.5 58.4 381060 279672 ?       D    Apr22  52:55      |                           \_ lzma -9c
<lamont> only need another 102MB of ram or so
<lamont> so wait. 8 hours runtime, 53 minutes of CPU...  my brain hurts now
<lamont> swaptastic
<slangasek> lamont: valid on armel since it's not on ISOs... can't do it for i386/amd64
<lamont> 163MB of swap used
<lamont> if we're doing another upload and we want it to finish before release, we probably want to turn of lzma for armel
<lamont> as in -ubuntu4, which is already pending
<lamont> anyway, faceplanting with some decorum before I do it without.
<lamont> g'night
<ttx> Good morning
<pitti> Good morning
<pitti> urgh, OO.o armel build still not finished, but looking good now
<pitti> (purging chroot)
<pitti> was a good time to wake up :)
<pitti> yay, it finished!
<pitti> asac, ogra ^
<ajmitch> morning pitti :)
<slangasek> ScottK, pitti: I'm not comfortable with that nautilus-share change, no; changing the default sharing ACL to allow the owner remote write access is not a clear bugfix, another option is changing the *description* of the option to say "remote users" instead of "other users"
<pitti> hi ajmitch
 * ajmitch obviously needs a faster computer & better cooling
<ogra> pitti, yeah, 36h+ fpr OO.o on armel
<ogra> *for
<ajmitch> *ouch*
<pitti> however, it seems that someone rejected the latest OO.o from the queue again, so I can't accept it
<pitti> waiting for mvo, I guess
<ogra> with 10.10 we'll get faster buildds (i think)
 * ajmitch has a perl upload to put in the queue (don't hurt me)
<ogra> pitti, i think it timed out from the queue
<pitti> the queue doesn't time out
<ogra> oh, k
<ogra> i thought i heard scott say something like that
<slangasek> ScottK: I think sparc being behind will influence what I'm willing to accept or not, but shouldn't be a blocker outright
<pitti> ah, mvo mailed about it
<slangasek> lool: apt-listchanges isn't used by default on Ubuntu; rejecting, you can always clean up the noise in SRU if you think that's necessary and still benefit most users
<pitti> slangasek: quick heads up: the xorg-server glx rollback got tremendous testing feedback on https://wiki.ubuntu.com/X/Testing/GEMLeak, so I'd really like to see this in final; but the current  upload fixes another bug which I'm not sure about, so I didn't accept it yet; I pinged bryce and will discuss first
 * pitti plays langpack accept whack-a-mole
<pitti> I hope I got them early enough for queuebot to not freak out
<ogra> hmm
<ogra> i cant nominate a bug for lucid anymore
<ogra> is that on purpose or did my LP account break ?
<pitti> certainly not on purpose
<ogra> well, clicking the nominate link doesnt list lucid
<ogra> https://bugs.edge.launchpad.net/ubuntu/+source/netbook-meta/+bug/568736
<ubottu> Ubuntu bug 568736 in netbook-meta "Having Evolution installed along with Desktop-Email is pointlessly redundant" [High,Triaged]
<ogra> lol
<ogra> i'm blind, persia already nominated it
 * ogra clicks approve
<ajmitch> yay, package almost finished building
<ajmitch> fix from debian for bug 568670 uploaded to the queue
<ubottu> Launchpad bug 568670 in perl "upgrade to lucid breaks completely when safe-rm is installed" [High,Confirmed] https://launchpad.net/bugs/568670
<fabrice_sp> Hi. Is this sync acceptable? (https://bugs.launchpad.net/ubuntu/+source/gorm.app/+bug/568619) It fixes a FTBFS and make 2 packages installables
<ubottu> Ubuntu bug 568619 in gorm.app "FFe: Sync gorm.app 1.2.10-1 (universe) from Debian sid (main)" [Wishlist,New]
<pitti> argh, sorry; I was too late in this round
<ajmitch> pitti: your accept whack-a-mole wasn't quite quick enough
<pitti> ok, I cleaned up components-mismatches now; AFAICS, the only real thing left is mod-wsgi
<pitti> oh, and gnugo/kigo
<pitti> thanks ajmitch
<slangasek> pitti: GEMLeak - did lool follow through on his CPU usage regression?  I agree it seems we should take that for final, anyway
<slangasek> pitti: OOo was rejected per mvo's mail
<pitti> slangasek: yes, it was determined to be unrelated to the update
<slangasek> pitti: ok, good
 * slangasek grunts sourly at the need for a perl upload
<slangasek> my first reaction reading that bug wasn't "we should accept perl", it was "we should remove safe-rm from the archive"...
<ajmitch> slangasek: sorry
<ajmitch> but from what I read, removing safe-rm wouldn't have fixed it
<slangasek> true
<slangasek> OTOH, do people actually install safe-rm?
<ajmitch> it was the safe-rm debian maintainer who filed the bug & poked me about it
<ogra> slangasek, bug 563618 has a branch linked now for review
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<slangasek> ogra: ack
<lool> pitti: FTR, couldn't reproduce the Xorg CPU consumption since; perhaps it was just bad timing that these two things happened the same day
<ogra> slangasek, and on a sidenote, omap netbook installs fine now (beyond a bug that it doesnt properly reboot at the end sitting at plymouth but the board has a reset button :) )
<slangasek> ogra: ok, great :)
<ogra> oh, geeez !
<ogra> it *does* reboot if i remove the SD
<ogra> tsk
<ogra> how could i know it actually *means* what it writes on the screen
<slangasek> anyone know offhand why kdebase-workspace-bin is uninstallable on sparc?
 * slangasek is failing to perceive the dependency order on http://people.canonical.com/~ubuntu-archive/testing-ports/lucid_probs.html
<ogra_beagle> yay
<asac> pitti: nice
<asac> slangasek: you consider seed change intrusive/risky?
<slangasek> asac: post-RC, for a low-priority bug? Yes.
<slangasek> especially when you're *un*seeding things
<slangasek> because that may uncover bugs caused by missing dependencies
<asac> slangasek: yeah. was an oversight before. too bad.
<asac> evolution-indicator might have given us a few more M  more ram ;) ... but ok.
<slangasek> yep, would've been nice, but not the week before release
<kees> ScottK: got another universe one for you... rng-tools in TPM mode wasn't starting at system boot, making that mode rather non-functional.  this upload fixes it.
<ttx> slangasek: given the buildd situation, am I right in assuming we should postpone everything that can be done as SRU to lucid-updates, to make room for things that /need/ to happen pre-release ?
<ttx> (except universe fixes that may run after candidate generation ?)
<slangasek> ttx: "buildd situation" - are you referring to something other than the queue of langpacks?
<ttx> no, the queue of langpack :)
<slangasek> ttx: but yes, everything that can be done as SRU should be pushed to lucid-proposed instead
<pitti> ttx: langpacks are quick, and don't block other builds (they have a low build scoree)
<pitti> (just FTR)
<slangasek> pitti: OTOH, we absolutely have to get the langpacks built before Monday :)
<ttx> pitti: right, but they still need to complete ;)
<ttx> heh
<pitti> right, was just saying that they don't completely block the lucid final queue at this point
 * pitti eyes the ubiquity upload in the queue
<pitti> oh, and we got another i386 buildd, nice!
<slangasek> pitti: was it you that accepted openoffice.org-hyphenation for bug #568514, btw?
<ubottu> Launchpad bug 568514 in openoffice.org-hyphenation "package openoffice.org-hyphenation-de 1:3.2.0-2ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/myspell/dicts/hyph_de_CH.dic', which is also in package openoffice.org-hyphenation ..." [High,Fix released] https://launchpad.net/bugs/568514
<pitti> slangasek: no, I didn't touch it
<slangasek> ok
<pitti> I saw it in the queue yesterday night, but this morning both oo.o and -hyphenation were gone
<slangasek> whoever did, overlooked another part to the bug
<slangasek> I'll upload the fix shortly; no sense waiting for ccheney to be awake again
<ttx> slangasek: ok, FTR, at this point we (server) don't have anything ready that would *need* to go in before release.
<ttx> emphasis being on /ready/, as we certainly have some annoying bugs.
<slangasek> ttx: the cloud-init bugs, or other stuff?
<ttx> slangasek: i'm updtaing the status page, just a sec
<ttx> slangasek: https://wiki.ubuntu.com/ServerTeam/ReleaseStatus
<ttx> see "under investigation"
<ttx> At that point I don't see how any of those might make release, except maybe the olcAccess (openldap) one
<ttx> the others we either don't have a solution yet for, or they are good SRU candidates
<ttx> will sync with team on all those before the meeting today
<ttx> (we are having a meeting today, right ?)
<ttx> another candidate would be bug 533029 -- if any of you have time to review chuck's latest proposal. Though it sounds like very late to change that now.
<ubottu> Launchpad bug 533029 in autofs5 "[FFE] autofs5-ldap doesn't work immediately after bootup" [High,Triaged] https://launchpad.net/bugs/533029
<slangasek> usr/share/hunspell/de_DE.aff                                text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami,text/myspell-de-de-oldspell
<slangasek> GAR
<slangasek> ttx: yes, meeting today
<ev> thanks for the quick approval on ubiqutiy
<slangasek> seb128: hi!  which part of this openoffice.org-dictionaries change was the rationale for the post-freeze upload?  Just the French changes, right?
<seb128> slangasek, hey, yes
<seb128> slangasek, I pinged you about that saying if you wanted the debian update or if I should just fix the french .install
<slangasek> seb128: ok; then I'm reverting the rest, because it's caused a buttload of file conflicts that we don't have time to sort out
<seb128> slangasek, but I didn't read your reply if you replied
<seb128> urg, sorry about that
<slangasek> well, someone accepted it and it's broken :)
<seb128> file conflict between what and what?
<seb128> just curious
<slangasek> and ccheney compounded the damage by uploading openoffice.org-hyphenation, dropping some of the conflicting files without setting Replaces/Conflicts - so I get to revert two packages, sigh
<cjwatson> agh, why do people try to optimise away setting the correct fields
<seb128> slangasek, the changes I cared about are to use the right names in openoffice.org-thesaurus-fr*
<cjwatson> it never saves time in the long run
<seb128> slangasek, ie th_fr to thes_fr
<slangasek> $ for pkg in myspell-th hunspell-de-at-frami openoffice.org-hyphenation-de myspell-it myspell-en-gb hunspell-de-ch-frami myspell-en-us openoffice.org-thesaurus-fr hunspell-de-de-frami; do zgrep $pkg /home/lp_archive/ubuntu/dists/lucid/Contents-i386.gz |grep , ; done | awk '{ print $2 }' | sort -u
<slangasek> text/hunspell-de-at,universe/text/myspell-de-at,universe/text/hunspell-de-at-frami
<slangasek> text/hunspell-de-ch,universe/text/myspell-de-ch,universe/text/hunspell-de-ch-frami
<slangasek> text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami
<slangasek> text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami,text/myspell-de-de-oldspell
<slangasek> text/hunspell-en-us,universe/text/myspell-en-us
<slangasek> seb128: ^^ those are the conflicts in lucid with the packages whose install files were touched in this upload, according to Contents
<slangasek> cjwatson: if by "correct fields" you mean "Conflicts/Replaces", I don't think optimization was the problem :)
<seb128> slangasek, hum ok, again sorry about that I sort of trusted debian on the change and I didn't notice the issue there since I don't have -de installed
<slangasek> though it's possible those packages already have conflicts with one another; lessee
<slangasek> ok, the remaining file conflicts are actually all declared
<slangasek> the only problem conflicts were the ones between openoffice.org-hyphenation-de and openoffice.org-hyphenation, which were fixed before the last Contents generation
<slangasek> so the easiest way out is forward
<slangasek> seb128: the actual bug for this is bug #568514
<ubottu> Launchpad bug 568514 in openoffice.org-hyphenation "package openoffice.org-hyphenation-de 1:3.2.0-2ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/myspell/dicts/hyph_de_CH.dic', which is also in package openoffice.org-hyphenation ..." [High,Fix released] https://launchpad.net/bugs/568514
<slangasek> seb128: so the reason the Debian maintainer didn't handle it is openoffice.org-hyphenation is Ubuntu-only
<seb128> oh, makes sense now
<seb128> slangasek, sorry again about those
<pitti> slangasek: ok for me to sync the new tzdata 2010i into lucid?
<slangasek> 'sok, we'll get it fixed :)
 * pitti thought that the DST change crazy period was over, but apparently not so
<slangasek> pitti: yes, go ahead
<pitti> (three DST rule changes, no structural differences)
<seb128> pitti, can we sync shotwell too?
<pitti> seb128: no idea, haven't looked at it; is there a bug/changelog/etc.?
<seb128> pitti, http://packages.qa.debian.org/s/shotwell/news/20100420T220717Z.html
<seb128> pitti, basically nmu to build with vala 0.8
<seb128> which we have in lucid
<pitti> to fix FTBFS?
<pitti> yes, that seems fine
<seb128> pitti, can you do it if you are doing syncs? thanks
<pitti> seb128: yep, doing
<slangasek> pitti, cjwatson: base-files, openoffice.org-dictionaries uploaded; please review
<pitti> base-files looks fine, accepted
<pitti> slangasek: oh heck, I need to update postgresql-common for this ^
<slangasek> for base-files?
<pitti> ah, no
<pitti> it checks lsb_release -rs
<pitti> which is still 10.04, not "LTS"
<slangasek> right, things checking that field is exactly why I didn't put LTS in it :-)
<cjwatson> review> you lot are too fast for me
<cjwatson> looks like somebody rejected landscape-client last night, but it's in the queue again.  What's the background on that?
<slangasek> wasn't me
<cjwatson> james_w: checksecurity: in the past, we've had the odd bug due to it being impossible to set I/O priorities in weird corner cases such as some virtualisation containers and the like.  Would it make sense to add the -t option, by way of being conservative?  That would require a dependency on util-linux (>= 2.15~rc1-1)
<pitti> langscape> me neither
<pitti> cjwatson: hm, it says it's in the queue for 20 hours?
<pitti>  i. e. doesn't look like "rejected"?
<cjwatson> 16:04 -queuebot:#ubuntu-release- New package: landscape-client (main) [1.5.0-0ubuntu0.10.04.0 â 1.5.0.1-0ubuntu0.10.04.0]
<cjwatson> 22:48 -queuebot:#ubuntu-release- Removed package: landscape-client
<cjwatson> 22:52 -queuebot:#ubuntu-release- New package: landscape-client (main) [1.5.0-0ubuntu0.10.04.0 â 1.5.0.1-0ubuntu0.10.04.0]
<cjwatson> which looks like "somebody discussed some flaw with the uploader, then rejected so that they could reupload"
<cjwatson> so presumably only whoever had that discussion can effectively review it
<slangasek> I don't see anything in rejected, I think that was just bot flapping
 * cjwatson once again wishes for better logging
<cjwatson> oh, I suppose it could be
<cjwatson> it's odd for it to explicitly say "Removed" unless it really is, that's all
<cjwatson> repeated "New" is a different matter
<slangasek> stgraber, highvoltage: how are we on final edubuntu-artwork?
<cjwatson> I haven't done the CD stuff yet, but I have the material from highvoltage
<slangasek> AIUI we also still need an upload of the package
 * ScottK notes OOo built on armel and congradulates lamont on the power of his special magic.
<james_w> cjwatson: if you think that's smart then I can make the change
<cjwatson> if you could, yes please
<cjwatson> just want to play safe at this point
<lamont> ScottK: somewhere between 8.5 and 9.5 hours into dpkg-deb, we got to pkgstriptranslations and output resumed.
<slangasek> ScottK, cjwatson, pitti: wrt OOo, I think lamont is right that we should fix the package to not use lzma on armel before accepting a new one; the tradeoff of lzma just doesn't make sense on armel, so long as we don't include it on release images
<ogra> ++
<slangasek> I don't think a bug has been opened for this yet, though
<lamont> slangasek: thank you.
<lamont> and no, I didn't file a bug
<james_w> ^ rejected
<ScottK> slangasek: IIRC it's still on KNR armel, but that image isn't size constrained so no lzma is fine.
<cjwatson> slangasek: yeah, I agree
<pitti> slangasek: OO.o> ack
 * pitti reviewes partman-*
<slangasek> cjwatson: bug #530027 still not deferred, does that mean it needs fixing before release?
<ubottu> Launchpad bug 530027 in ubiquity "nested progress bars don't work outside debconffilter" [High,Triaged] https://launchpad.net/bugs/530027
<slangasek> ScottK, Riddell: is anyone working on bug #551456?
<ubottu> Launchpad bug 551456 in kcm-touchpad "systemsettings crashes when clicking "Keyboard & Mouse"" [High,Triaged] https://launchpad.net/bugs/551456
<slangasek> (if not, should probably be deferred to SRU now)
<Riddell> slangasek: not that I know of, I'll ping Jonathan Thomas to check
<Riddell> slangasek: did you reject the kdeplasma-addons upload this week?
<slangasek> Riddell: yes
<slangasek> https://bugs.launchpad.net/ubuntu/+source/kdeplasma-addons/+bug/566127
<ubottu> Ubuntu bug 566127 in kdeplasma-addons "Picture of the day does not work" [Undecided,Fix committed]
<Riddell> oh aye
<lamont> slangasek: and I'm assuming someone else is doing the oo.o mod for armel
<slangasek> lamont: sure?
<slangasek> I think it's "whoever gets to it"
<lamont> as in I'm not preparing an upload
<slangasek> lamont: it's diff.gz only, really lightweight ;)
<lamont> for oo.o, yeah.  my dayjob tasks are interferring with my dev stuff
<slangasek> ^^ that one's mine, if someone could review
 * cjwatson looks
<slangasek> cjwatson: you already fixed the other half of that bug, so if you don't like it, don't hesitate to reject
<cjwatson> no, I'm fine with it, I see many more risks than benefits in applying it on upgrade
<cjwatson> accepted
<slangasek> ok, thanks
<cjwatson> err, wait!
<cjwatson> shouldn't that be --no-start?
<cjwatson> sorry, only spotted this after accept
<cjwatson> possibly -r as well, I forget the exact semantics
<cjwatson> but surely we *do* want to modify the postinst/postrm/prerm scripts
<cjwatson> to call update-rc.d
<slangasek> ah, quite
<slangasek> sorry, will fix
<lamont> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/568940
<ubottu> Ubuntu bug 568940 in openoffice.org "drop lzma from armel for lucid" [Undecided,New]
<lamont> and targeted to 10.04
<doko_> lamont: can't this wait until the first update?
<slangasek> doko_: dropping lzma?  not if we want the *pending* update to build on armel in a sane amount of time
<doko_> ahh, wasn't aware of *another* update
<mvo> another ooo update?!?
<mvo> then please, please merge my changes in as well
<doko_> slangasek: do you do that, or should I?
<slangasek> mvo: weren't we waiting for *you* to send us one? :)
<doko_> mvo: even better, take over! =)
<mvo> and I am waiting on my machine to finish building it, even debuild -b -nc takes ages
<slangasek> mvo: the "pending update" I meant was the one with your changes - we should get the lzma change added on to that
<mvo> yeah
<mvo> cool
<mvo> is it just "use_lzma_compress=n" ?
<mvo> in debian/rules ?
<doko_> I'll look
<mvo> thanks doko_
<mvo> so my plan is/was to upload to my ppa first (build etc ~4h), run a battery of upgrade tests against it and then upload to the main archive
<pitti> mvo: but on armel only
<mvo> the upgrade stuff is automatic and relatively fast, I just need to review the logs
<pitti> we certainly want to keep lzma for i386/amd64
<mvo> aha, ok
<slangasek> Riddell: there's an unanswered question for you from ev on bug #567243
<ubottu> Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Undecided,New] https://launchpad.net/bugs/567243
<ogra> slangasek, arm enhanced the hack on bug 563618 (branch with tested changes linked)
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<cjwatson> slangasek: I still don't get this - -r alone only prevents the prerm running init.d stop
<ogra> (yes, i know i'm annoying, sorry for that)
<cjwatson> looks like we want --no-start (which includes -r, looking at dh_installinit)
<cjwatson> with -r, the init script will still be run on postinst configure
<slangasek> cjwatson: mm, yes
<slangasek> cjwatson: reject, I'll reupload
<cjwatson> done
<slangasek> cjwatson: thanks for the scrutiny; I clearly don't have dh_installinit internalized as well as intended
<Riddell> slangasek, ev: bug 567243 answered
<ubottu> Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Medium,New] https://launchpad.net/bugs/567243
<slangasek> ogra: I'm afraid I'm going to have to take off again for a couple of hours; I'll be back for the release meeting, and will review the branch afterwards
<pitti> slangasek: so, it seems that all the vpnc faff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is really just due to KDE failing to build on sparc
<pitti> so I'm inclined to just ignore those
<pitti> auctex is also just a glitch AFAICS
<ogra> slangasek, ok, thanks
<slangasek> pitti: I tried to give KDE a kick start on sparc, but I can't figure out why kdebase-workspace-bin is uninstallable there
<pitti> right, same FTBFS reason like plasma-widget-networkmanagement
<slangasek> pitti: and faure gives an unfriendly error instead of useful debugging output :/
<slangasek> cjwatson: ^^ take 3
<cjwatson> pitti: last I checked, auctex was ultimately a result of emacs23 failing to build on ia64
<ogra> ScottK, do you have any beagleboard users in the kubuntu community ? if you have an armel build that was rolled after 22nd there might be value in knowing if kubuntu-netbook omap works ... (https://wiki.ubuntu.com/ARM/Beagle)
<pitti> cjwatson: aah, thanks
<pitti> cjwatson: given that c-m considers ports, it's in a surprisingly good shape :)
<Riddell> ogra: not that I know of, our main testers are ncommander and gruemaster's son
<ogra> ah, k
<cjwatson> slangasek: ok, accepted now, thanks
<highvoltage> slangasek: we received the new artwork yesterday \o/
<highvoltage> slangasek: I made the changes and uploaded the new package
<highvoltage> cjwatson: did you get my link yesterday with the new boot logos?
<pitti> ScottK: TBH, clamav has so many changes that I don't have the guts to accept it; was that discussed before with someone else?
<ScottK> pitti: slangasek was scared too.  All I can say is that this is based off the first revision the Debain maintainer was willing to upload to Volatile for Lenny users.
<ScottK> I know there are a number of sub-par things in the current debconf handling and I think it's unlikely this will be worse.
<ScottK> Based on the testing done with the Debian people and what I've reviewed  of the changes I think the risk of regression is low, but not non-existent.
<pitti> ScottK: ok; since it doesn't seem realistic to verify correctness by eyeballing the debdiff, this should rather be tested extensively then
<ScottK> pitti: Yes.  I think it has been tested fairly extensively in Debian already.
<ScottK> The two DDs most active on their clamav team beat in it pretty hard and stared at it for several days before uploading.
<ScottK> That's why it's coming so late.
<pitti> ok, thanks
<mvo> new OOo is uploaded, but please do not accept it just yet, I want to test the build from the PPA in a real upgrade secenario (I did test a local upgrade, but only ooo, not the full thing)
<mvo> and let me know if you see anything odd in the diff (I looked at it and it looks fine, but more eyes will not hurt :)
<cjwatson> highvoltage: I did, thanks, will process it today
<highvoltage> cjwatson: and thank you!
<pitti> ^ weirdest patch to remove scroll bars EVAR
<pitti> (discussing in #u-desktop right now)
<ttx> pitti: moin uploaded. I triplechecked by installing that package that following the existing instructions in Debian readme are sufficient to make it work.
<ttx> so it works and is consistent with existing documentation.
<cjwatson> highvoltage: committed and deployed; should be on the next CD
<highvoltage> cjwatson: great! I'll test it with the next build
<stgraber> slangasek: are we back to daily build until Tuesday or do we have to ask for a respin every time we want one ?
<ogra> stgraber, manual
<stgraber> ogra: ok, thanks
<stgraber> ogra: how's ARM going btw ?
<ogra> stgraber, see planet :)
<lamont> slangasek: any reason to not retry oo.o on sparc?
<lamont> other than  the "newer one coming" reason?
<lamont> and I wonder how many more glib2.0-caused failures we have out there
<highvoltage> oh right we probably want a respin of edubuntu when the artwork package hits the archive :)
<stgraber> ogra: how's ARM going btw ?
<ogra> stgraber, see planet :)
<pitti> slangasek: for the record, alternates have tons of space, I'll add back some langpacks (there are none except -en right now)
<ScottK> vlc is an interesting one as there are security fixes in there and I'm not confident at all we'll get them any other way than to accept the entire mess.
<slangasek> lamont: OOo on sparc> new one's coming, and there's other stuff in the build queue on sparc?
<slangasek> pitti: alternates> doh! thanks
<lamont> slangasek: right.
<lamont> IOW, no.
<lamont> slangasek: I expect that there are other glib2.0-induced failures that we should throw back in for sparc
<lamont> but nfc which ones
<lamont> and my level of caring is completely academic
<bdrung> ScottK: one security fix and 6 bug fixes
<stgraber> slangasek: Can you trigger a rebuild of Edubuntu once 0.1.0-69 is in the archive ?
<stgraber> edubuntu-artwork 0.1.0-69 that's
<slangasek> stgraber: trigger set
<stgraber> cool
<slangasek> pitti: ok, I don't actually find the discussion of the extra xorg patch in my scrollback that I thought was there
<slangasek> pitti: but the patch itself looks straightforward and important - did you have specific concerns with it?
<seb128> slangasek, he was concerned about the other change in the upload I think
<seb128> slangasek, he said there was 2 changes, the glx issue one + another one he was not sure if that was an intended change or an error
<seb128> slangasek, the confusion was about the 0ubuntu6 entry
<seb128> slangasek, it's not in the .changes and pitti was not sure it was meant to be in the upload or an error
<seb128> slangasek, bryce confirmed it's targetted to lucid
<seb128> slangasek, so feel free to accept the upload if you want
<seb128> slangasek, when have time to review it ;-)
<slangasek> seb128: great, thanks
<slangasek> stgraber: got a build failure on edubuntu, probably due to langpacks
<mvo> slangasek: the dapper->hardy->lucid with OOo from the PPA upgrade tests is successful, registering works, upgrade does no longer explodes. the karmic->lucid is still running though
<slangasek> mvo: ok - you want me to wait for that test too before accepting
<slangasek> ?
<slangasek> stgraber: sure enough, there's the mail - langpacks
<mvo> slangasek: it should be finishing in ~30 min or so, so I would say yes
<mvo> slangasek: unless you think its too urgent to wait
<slangasek> nope
<mvo> ok, i let you know when its there
<stgraber> doh, which one is broken this time ?
<stgraber> slangasek: can't see the build failure on people.c.c/~ubuntu-archive and didn't receive a build fail mail, do you have a link to that ?
<slangasek> stgraber: nope, sorry - the logs will be synced soon
<slangasek> stgraber: it's not something you can fix anyway, the langpacks just need to finish building :)
<slangasek> i.e., the build failure is simply due to mid-langpack-build skew, not a source bug that needs fixed
<stgraber> slangasek: ok
<slangasek> looks like langpacks are progressing at about 50/hr, so roughly 7 more hours to completion
<ScottK> slangasek: Does that mean it's OK to accept some Universe stuff now (since 7 hours isn't so long) or would you rather I waited?
<slangasek> doko, mvo: fwiw, it would've been more idiomatic to change the value of USE_LZMA_COMPRESS based on the architecture; especially since the DPKG_DEPENDS value is also redundant when we don't use lzma
<slangasek> ScottK: will those universe packages land ahead of the langpacks in the queue?
<ScottK> slangasek: They will.
<slangasek> ScottK: would be nice if the langpack build didn't stretch out too much longer, if it goes too late I won't be able to get stgraber his edubuntu respin until I land in London
<ScottK> OK.  I'll wait.
<slangasek> ScottK: ok, thanks
<slangasek> mvo: are we there yet? :)
<ScottK> slangasek: Currently on Kubuntu dial up networking is broken due to a permissions issue.  It's an easy fix and it's in kdenetworking so it's not a multi-hour build.  Since no network could interfere with the ability to get update, can this go in or SRU?
<slangasek> ScottK: yes, let's take it
<ScottK> OK.  Thanks.
<mvo> slangasek: the log looks good, components show as registered, upgrade almost finished, all looks well
<mvo> slangasek: I think we have a winner!
<mvo> slangasek: ok, OOo runs fine, still has evo as a datasource and the binfilters, logs look fine. I tested both hardy->lucid and karmic->lucid
<mvo> slangasek: both work now when they before failed
<slangasek> mvo: ok, accepted
<slangasek> mvo: thanks for taking care of this!
<ScottK> slangasek: kdenetwork was the dial up networking fix I mentioned.  I reviewed and accepted, so it's done.
<slangasek> ScottK: ok, cool
<mvo> slangasek: thank you! I'm happy that this is resolved now
 * mvo sends the updated diff to debian
<slangasek> so now everything upgrades perfectly, right? :-)
<mvo> everything that I tested â¦
<mvo> :)
<slangasek> want to test mysql server?
<slangasek> (hardy->lucid)
<mvo> bÃ¤
<slangasek> :-)
<mvo> I think matthias pointed me to a new bug about it the other day
<mvo> slangasek: I commited (and will test) a update-manager quirk, I don't think I will manage to debug the root cause tonight, but the quirk will ensure that it works when using u-m
<slangasek> mvo: ah; what's the bug?
<mvo> slangasek: I don't know yet, I think its something with the cluster package and the dependencies
<slangasek> right, unsurprising - is there a bug number or log, though?
<mvo> oh, yes
<mvo> sorry
<mvo> its bug #568606
<ubottu> Launchpad bug 568606 in update-manager "mysql-server removed when upgrading from 8.04 to 10.04" [High,New] https://launchpad.net/bugs/568606
<slangasek> (I'm poking about this because mysql upgrade path is already in the release notes)
<mvo> and the logs are good
<slangasek> great, thansk
<mvo> its trivial to add a quirks handler in u-m for it, I doubt it happens for all people, I don't see it in the server-tasks upgade profile (that is a server install with all tasks installed)
<mvo> I test the quirks thing now (more out of paranoia, its just a config file entry) and if its fine I will upload a new u-m with it
<mvo> will take ~45min or so
<slangasek> ok
 * mvo can reproduce the bug
<mvo> slangasek: uploaded new version, fixes this bug and a upgrade failure with gobuntu (pretty trivial and obvious)
<ScottK> Kubuntu powerpc images finally got a thumbs up for at least Live CD testing.
<ScottK> (the RC ones)
<ScottK> slangasek: FYI Bug #565294.  I don't think there's any imminent release team action required, but it bears watching.
<ubottu> Launchpad bug 565294 in rosetta "Plural translations are broken for Lithuanian language" [High,In progress] https://launchpad.net/bugs/565294
<slangasek> alright
<ScottK> The only possible pre-release solution would be to remove language-pack-kde-lt  and upload the KDE language pack to Universe where it won't get stripped.
<ScottK> I'm ~sure we don't want to do that.
<cjwatson> could somebody review hw-detect?  I'd like to upload a more-or-less-final debian-installer tonight, and hw-detect is in the initrd
<ScottK> ^^^ was a rejection, fyi.  It will be back.
<cjwatson> (review of partman-iscsi wouldn't hurt either but less urgent)
<slangasek> cjwatson: grabbing
<cjwatson> thanks
<slangasek> cjwatson: no bug ref in the changelog - why is backup support significant here?
<pitti> slangasek: ok, so xorg sorted out? great
<slangasek> pitti: yeppers
<pitti> slangasek, cjwatson: so I think we can consider http://people.canonical.com/~ubuntu-archive/component-mismatches.txt as "empty and done" now, right?
<pitti> unless someone is eager to untangle the KDE mess on sparc
<slangasek> it resisted me; as a last resort I was going to untangle it with a binary removal
<ScottK> No objections here to binary removal on sparc here.
<slangasek> ogra: ok, patch for bug #563618 reviewed and my lunch is staying down, so I guess it's ok for upload
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<slangasek> cjwatson: partman-iscsi accepted - still looking for clarification on hw-detect before accepting
<slangasek> oh, har
<slangasek> W: initramfs-tools: script-not-executable ./usr/share/initramfs-tools/scripts/panic/keymap
<slangasek> no wonder that wasn't working for me
<slangasek> ScottK, cjwatson: ^^ initramfs-tools needs an upload anyway for 563618, mind if I fix the perms on that script in the process?
 * ScottK defers to cjwatson.
<slangasek> ok
<slangasek> cjwatson: and btw, same bug exists in console-setup's panic script :/
<bdrung> will vlc be accepted?
<ScottK> bdrung: We aren't doing any Universe accepts until after the language pack run is done.
<ScottK> It hasn't been reviewed yet, AFAIK.
<bdrung> aha
<cjwatson> slangasek: ok, the reason I added backup support there was while investigating the various iscsi UI bugs ara reported, and realising that backup behaviour was inconsistent - it depended on whether you'd seen an error message yet or not.  (furthermore, the lack of backup support on the hw-detect path was getting in my way when testing)
<cjwatson> it's probably borderline, I won't fret too badly if you say no, it was just a "god, this UI actually kind of sucks"
<cjwatson> slangasek: perms OK by me - want me to upload console-setup to fix its perms too?
<cjwatson> (that's strictly an error path so I don't see how fixing it in initramfs-tools while you're there could cause a problem)
<slangasek> cjwatson: ok, hw-detect in; uploading initramfs-tools now; console-setup> actually, I dunno, if console-setup's code is broken could that cause a regression in users' ability to break into the initramfs for recovery?
 * slangasek looks at what the script does
<cjwatson> if it hung, I guess it could
<slangasek> looks safe enough
<slangasek> hmm
<slangasek> is it likely to hang?
<slangasek> there seems to be some duplication between keymap and console_setup, huh
<cjwatson> I shouldn't think so
<cjwatson> it's basically the same code as in initramfs-top
<cjwatson> in fact
<cjwatson>         sed -e "/^OPTION=/d" \
<cjwatson>                 < debian/console-setup.initramfs-top \
<cjwatson>                 > debian/console-setup/usr/share/initramfs-tools/scripts/panic/console_setup
<cjwatson> so if it breaks, then an initramfs with the framebuffer option would break in the same way
<slangasek> yeah, one difference I see is that top runs before plymouth, panic runs after
<cjwatson> keymap looks like a superseded strict subset of console_setup
<slangasek> with a different path to the keymap
<cjwatson> which doesn't exist in my initramfs
 * slangasek nods
<cjwatson> I think the kbd_mode call is all it actually does in practice
<cjwatson> but probably best resist cleaning it up right now
<slangasek> ok, so I'll not bother fixing those perms on initramfs-tools upload, since it wouldn't actually help
<slangasek> and console-setup... if you want to prep it, I'll put it through its paces before accepting, since I know my system's a good test case
<cjwatson> you want a binary?
<slangasek> nah, can grab from the queue
<slangasek> (if that's ok)
<cjwatson> or you could just 'chmod +x /usr/share/initramfs-tools/scripts/panic/console_setup'
<slangasek> true
<cjwatson> and update-initramfs -u
<cjwatson> since that's all I'm going to do
<slangasek> cjwatson: should the last change mentioned in the partman-iscsi changelog have fixed bug #568312? (no bugref)
<ubottu> Launchpad bug 568312 in partman-iscsi "Installer fails to find a target when using authentication" [High,Incomplete] https://launchpad.net/bugs/568312
<cjwatson> I'm not sure
<cjwatson> it fixed one problem I encountered while attacking that bug
<cjwatson> but I ran into problems described in a comment on that bug, which I'm not sure are representative of real-world situations since it's ages since I had this set up properly
<stgraber> slangasek: we just found a small issue in edubuntu-artwork with our plymouth theme, so another upload of that one is to be expected in the next hour or so to fix it (changing font color on the cryptsetup prompt so it's readable).
<cjwatson> I decided that I wasn't making any more progress and would be best off drawing a line for now
<slangasek> stgraber: ok
<slangasek> initramfs-tools uploaded
<cjwatson> console-setup on its way
<ScottK> slangasek: I'm heading out for a while.  Once the language packs are sufficiently drained, I think mythtv and xchat would be priorities for Universe.  Both looked sensible to me, but more review never hurts.
<slangasek> ScottK: sounds good
<ScottK> quickly is ~32K lines of almost all po/pot file changes.
<ScottK> vlc would be a priority too.  I wonder if anyone told kees he'd volunteered to review it.
 * kees knows, but is slow
#ubuntu-release 2010-04-24
<kees> ScottK: I'm happy with the vlc 1.0.6 upload from a source and patching delta perspective.  vlc tends to be pretty conservative normally.
<ScottK> kees: Thanks.
<kees> ScottK: so if jdong says it's good, I say ship it.
<ScottK> OK. I tend to agree.
<slangasek> langpacks are out of the queue now
 * ScottK is back.
<stgraber> can someone push edubuntu-artwork through the queue so it's ready for our next rebuild (once the langpacks have finished updating I'm guessing) ?
<ScottK> stgraber: lang packs are done.  Let me have a look
<ScottK> stgraber: Accepted.
<ScottK> slangasek: The LP U/I refuses to accept vlc, so I'll leave that to you.
<stgraber> ScottK: thanks
<ScottK> gdmap is distinctly odd.  It looks like it got autoreconfed or something and a bunch of stuff went missing.
<ScottK> If someone sees seb128 they might ask him to have another look at it.
<hyperair> ScottK: the code in banshee-extension-appindicator was originally duplicated from banshee's notificationarea extension. the code has received well enough testing. there will not be a regression.
<ScottK> hyperair: I realize there won't be a regression for notify-osd users.
<hyperair> ScottK: not for notification-daemon either.
<hyperair> ScottK: or any other notification daemon that suppots the notifications standard properly
<hyperair> like i said, it has been well tested
<hyperair> by Ubuntu users, and by non-Ubuntu users.
<hyperair> the fragment of the code that was removed by the patch was removed many banshee releases back. qense just added it because he thought it might be useful
<hyperair> it was never supposed to have been there in the first place.
<ScottK> Except currently the notification updates at start of stream, on update, and end of stream.  If I read the patch right, the start and end update are removed.
<ScottK> OK, well that's a totally different rationale than is in the bug.
<ScottK> The bug describes working around a notify-osd limitation.
<hyperair> sorry, i guess the bug was not worded properly
<hyperair> the end-of-stream notification would time out anyway
<ScottK> True, so I guess it's really just the start of stream notification that is affected.
<hyperair> yes
<ScottK> So with the patch there is no notification until some update happens instead of there being one at the start of the stream, right?
<ScottK> That doesn't make any sense to me.
<hyperair> ScottK: what?
<ScottK> I may be reading that patch wrong, but that's what it looked like.
<hyperair> there's a if (current_nf == null) somewhere
<hyperair> it starts off as null
<hyperair> when the first notification is fired, a Notification object will be created
<hyperair> and displayed
<ScottK> In case PlayerEvent.StartOfStream: it removes current_track = ServiceManager.PlayerEngine.CurrentTrack; and then ShowTrackNotification ();
<hyperair> i think there is code repetition
<hyperair> the code was already in ShowTrackNotification()
<ScottK> So that's just redundant?
<ScottK> That bit was the core of my concern.
<hyperair> ScottK: ah it's a switch statement, so it just coincides with the next one.
<hyperair> StartOfStream and TrackInfoUpdated
<ScottK> OK.
<ScottK> Good enough then.
<hyperair> yep
<ScottK> Accepted.
<ScottK> Sorry for the confusion.
<hyperair> np
<hyperair> and thanks =)
<ScottK> OK.  That's the end of the current batch I'm comfortable accepting.
<ScottK> flite is main and fixes FTBFS, so I'd appreciate it if someone would review.  Diff is trivial.
<iulian> ScottK: Am I qualified to review it?
<ScottK> iulian: I certainly hope so.
<ScottK> (it's adding a missing build-depends)
<iulian> ... on ed.
<iulian> It looks good to me.
<ScottK> iulian: OK.  So you'd like for me to accept it on your behalf?
<iulian> ScottK: Yes, please go ahead.
<ScottK> iulian: Done.  Thanks.
<iulian> ScottK: If there is anything else I can do, please let me know.
<ScottK> iulian: OK.
<ScottK> iulian: If there's anything in the queue you're comfortable signing off on, let me know and we can discuss it. For Main the RM wants to limit fixes to ones that fix FTBFS or don't make good SRU candidates because you really want them on the installation media, low risk/obvoius fixes.
<ScottK> For Universe we're more open about any bug fixes.
<iulian> ScottK: Alrighty.
<ScottK> iulian: ^^^ could you perhaps review these?
<iulian> ScottK: Sure.
<ScottK> iulian: Great.  I can let them in for you once you've reviewed.
<iulian> ScottK: gpsk31, gmerlin, gabedit, gcin and emerald look good.
<ScottK> OK
 * iulian is reviewing gamgi now.
<iulian> It looks like geser is pretty busy. :)
<ScottK> Yep
<ScottK> iulian: I'd appreciate a review for qd when it appears.  Since it's my upload, I can't be the reviewer.
<iulian> ScottK: OK.
<ScottK> Thanks.
<iulian> ScottK: gamgi, gentoo and gnote look good too.
<ScottK> iulian: Accepted.
<ScottK> iulian: There are two gdmap uploads in queue.  Tell me if you want geser's or seb128's.
<iulian> ScottK: Hmm, gdmap appears twice in the queue with different diff.gz
<iulian> Oh. :)
<ScottK> I looked at seb128's yesterday and it had a bunch of configure stuff in the diff I suspect wasn't wanted.
<ScottK> So have a look and let me know what you think.
<iulian> OK.
<iulian> ScottK: Indeed.  seb128's patch looks ugly.
<iulian> I'd go with geser's patch.
 * iulian looks at qd.
<ScottK> OK.
<ScottK> Done
<iulian> ScottK: I have no idea why 'uscan --force-downloads' shows up in the diff.
<iulian> Anyway, please accept it.
<ScottK> iulian: Becuase I added a missing newline.
<ScottK> OK
<ScottK> Done
<iulian> Ah, right.
<ScottK> iulian: I'd appreciate a review on foundry when it hits.
<ScottK> (just uploaded)
 * iulian gets the source.
<iulian> ScottK: From where have you cherry picked the fix?
<ScottK> iulian: The debian package in Testing/Unstable.
<ScottK> They've got a new upstream version, so I didn't want to pull that in.
<iulian> ScottK: OK, please accept it.
<ScottK> iulian: Done.  Thanks.
<iulian> No problem.
<ScottK> I'm heading out for a while.  If stuff comes in and you review it, just say so here and I'll process it when I get back.
<iulian> ScottK: OK.
<iulian> ScottK: Go ahead and accept python-django-djblets.
 * iulian has just reviewed it.
<ScottK> iulian: Thanks.
 * iulian goes to bed.
#ubuntu-release 2010-04-25
<bdmurray> ScottK: I just uploaded ipython do you need something more from me?
<ajmitch> queuebot must get confused, 0.14-1 is the current binary package version, 0.14-2 is FTBFS in lucid there
<ScottK> ajmitch: queuediff got it right.  Thanks for taking care of it.  Accepted
 * stgraber is rsyncing the latest edubuntu DVD image from the train on a 7Mb/s 3G network ! yeah for europe ;) (I wouldn't do that in Canada as the image is 4 times my monthly quota but the prepaid 3G in switzerland (5$/day) is unmeterred :))
<ajmitch> stgraber: to do that here wouldprobably cost several hundred $ :)
<james_w> ScottK: shall I just do a pass over all the eligible sync requests, or do you want to pass me a filtered list?
<ScottK> james_w: I can take a quick look and let you know if I think there are any that should not go in.
<ScottK> james_w: 569435 567208 568742 566933 are all good to go in.
<ScottK> slangasek: Would you please have a look at the sync requests in 569528 and 569531?  I think they should clearly go in, but they are my requests, so I think it's better if you (or another release team) member reviews.
<ScottK> Looks like no lzma cut the OOo build time on armel in ~half.
<nhandler> ScottK: 569528 looks fine to me
<nhandler> ScottK: Go ahead with 569531 as well
<ScottK> james_w: ^^^
<slangasek> ScottK: ah, I see nhandler's addressed it now, good - sorry, I'm pretty jet lagged right now so am not much good for reviews; it took my last bit of consciousness to get plymouth uploaded to the queue just now
<slangasek> (which it would be great to have someone's review of :)
<ScottK> OK.  I guess just waiting for james_w to have some time now.
<elmo> someone remind me when we usually have a candidate image by?
<elmo> slangasek/cjwatson: ^--
<ScottK> elmo: I think the plan is to have a first crack at one tomorrow.
<elmo> ScottK: ok
<james_w> syncs done
<Laney> there's 568850. Don't know if it needs RM approval.
<cjwatson> d-i rebuild on its way (I was going to update translations too, but none of them changed); would appreciate it being nudged through
 * cjwatson goes to catch his princely 5.5 hours of sleep before heading to London
<james_w> Laney: I just processed ones that ScottK had ACKed. Someone should get it tomorrow
<Laney> ok
<Laney> (it's a removal)
<james_w> ah
<slangasek> cjwatson: will look - btw, there's a plymouth in the queue and there'll be a mountall shortly, I expect you should sleep rather than looking at it now, but for the morning then :)
<cjwatson> lessee if it's easy
<slangasek> probably not, it's a cumulative upload of a number of subtle fixes
<cjwatson> mm, this requires brain, will look over morning coffee I guess
<slangasek> ok, thanks :)
<cjwatson> is get_next_node; remove_node verifiably safe?  I assume so from the careful ordering but seems like something to check
<cjwatson> anyway, yeah - zonk
<cjwatson> see you in London :)
<slangasek> indeed!
#ubuntu-release 2011-04-18
<gilbert> so, would anyone be able to take a look at #669211?  as-is, natty is going to ship with a completely broken xpdf package.  the fix is to revert to the pre-poppler conversion (as was done to fix the issue for maverick).  thanks.
<slangasek> kirkland: accepted
<kirkland> slangasek: thanks steve
<skaet> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-04-18 has an updated summary of the bugs, and is accurate as of sunday night.  It needs a scrub by the leads, since the status of the bugs in launchpad is crufty.
<stgraber> skaet: I guess it's probably a good idea to retarget bug 747325 to Oneiric ?
<ubot4> Launchpad bug 747325 in sqlite (Ubuntu Natty) (and 1 other project) "demote sqlite, or remove it from the archive (affects: 1) (heat: 237)" [Undecided,New] https://launchpad.net/bugs/747325
<skaet> stgraber,  yes retargetting to Oneiric is appropriate, avoiding optional churn on the archive is desirable.
<stgraber> skaet: ok, marked as Won't fix for Natty and nominated for oneiric, can you accept the nomination ?
<skaet> stgraber,  will do.  :)
<stgraber> I guess something changed in LP recently, I seem to remember being able to approve them not that long ago. I guess it's now restricted to ubuntu-release (which makes sense)
<ogra_> skaet, not sure you noticed, i moved one of the natty-updates bugs back to release ... fixing the bootloader in an update doesnt make much sense
<skaet> ogra_, thanks!   yup,  that makes sense.
<skaet> will we be able to fix it before we start off those final images on Thursday?
<ogra_> especially given that the bug already has a small patch attached
 * skaet nods
<ogra_> i will talk to jcrigby and rsalveti
 * skaet and crosses fingers that that fixes it too...
<skaet> thanks ogra_   :)
<ogra_> i think its small enough to upload it right away
<ogra_> skaet, unity-2d told me they have a final package for me tomorrow, hope thats ok
<skaet> ogra_, if its bug fixes,  that's cool.    If its new features - ...    less so.
<ogra_> heh, indeed its not new features
<skaet> ogra_, :)  goodness then.
 * skaet -> appt.    will check back later.
<bdmurray> bug 751018 is technically correct right?
<ubot4> Launchpad bug 751018 in ubuntu-meta (Ubuntu) "i386 installer CDs are named improperly (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/751018
<robbiew> ScottK: interested in your thoughts on bug 762505
<ubot4> Launchpad bug 762505 in rsyslog (Ubuntu) "Outdated in Natty, please merge from Sid (affects: 3) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/762505
<robbiew> is it too late to consider this for Natty, in your opinion?
<robbiew> pitti: thoughts? ^^
<pitti> robbiew: a jump from 4.6.4 to 5.8.0 in a rather central and also security sensitive package doesn't sound like something we should squeeze into natty now IMHO
<robbiew> pitti: cool...that's what I thought
<robbiew> but wanted some comfort from others :)
<genec> will there be any warnings (probably Release Notes since it was mentioned the Installer is frozen) that btrfs support is still highly experimental?
<micahg> I assume sync runs are still happening for appropriate syncs?
<ScottK> robbiew: Commented in the bug.  I think it'd be great for natty-backports after it's in oneiric.  SInce natty-backports is NotAutomatic, I'm not worried about it.  For lucid/maverick-backports I'd want some extra testing done.
<robbiew> ScottK: cool...thnx!
#ubuntu-release 2011-04-19
<stgraber> skaet: you may want to look at the screenshots I attached to bug 746028
<ubot4> Launchpad bug 746028 in gnome-settings-daemon (Ubuntu Natty) (and 1 other project) "Edubuntu: Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/746028
<stgraber> skaet: I just did a clean install of Maverick, made sure it's up to date, took two screenshots before upgrade, then the two same on Natty after upgrade and another of a new clean user.
<stgraber> only the new clean user gets the orangier (is that even a word ?) wallpaper
<pitti> ScottK, slangasek, any release member: ^ any chance to process this? it's blocking ev's ubiquity fix
 * ev hugs pitti 
<ev> nnnnnnnnnnnnnnnnnnnma/slideshow
<pitti> ev: did you do a full end-to-end test with this? I followed up to the PAE bug with a question
<ev> whoops
<ev> I tested it as far as it installed the right kernel and dpkg didn't error out on installing the nvidia driver
<ev> but I don't have the requisite hardware to test that it completely works
<ev> I'll have a look at the bug now
<pitti> ev: right, I just simulated it here as well, and just checked with dkms status
<ogra_> did someone let linux-meta-ti-omap4 out of new already ?
<ogra_> (armel images failed due to it)
<pitti> ogra_: I think I accepted it from unapproved this morning, was that wrong?
<ogra_> pitti, no, perfect :)
<ev> can anyone comment on the likelihood of getting a freeze exception for bug 6900926 (adding a "nowhere" option to the bootloader installation)
<ubot4> ev: Bug 6900926 on http://launchpad.net/bugs/6900926 is private
<ev> whoops
<ev> bug 690926
<ubot4> Launchpad bug 690926 in ubiquity (Ubuntu Natty) (and 1 other project) "Installer forces you to install grub somewhere (affects: 5) (heat: 28)" [Medium,Incomplete] https://launchpad.net/bugs/690926
<ev> note that maverick had this same behavior of only being able to disable bootloader installation via a flag to ubiquity (ubiquity -b)
<ogra_> if someone could let libqtbamf through i would appreciate that, a unity-2d upload is waiting for it
<pitti> currently reviewing the queue, will do
<pitti> Riddell: any chance you could have a look at apport and jockey?
<Riddell> pitti: can do
<pitti> cheers
<pitti> ogra_: done
<ogra_> super, thanks !
<Riddell> pitti: "+1.20.2 (UNRELEASED)" in apport NEWS file, accepting though
<pitti> Riddell: yes, it's just a merge from trunk, but there's no new upstream release yet
<pitti> thanks
<mvo> pitti: how is the free space on the cd looking currently? I got a new app-install-data upload with more icons (improvements to the crawler were made) but the result is that it take ~1mb or so more
<pitti> mvo: I added back some langpacks, so tomorrow's will be back up to 696 MB or so
<pitti> mvo: 1 MB? that's quite a lot of new icons indeed :)
<mvo> pitti: yeah, good new code!
<mvo> pitti: but to be fair, there are just a lot of icons
<pitti> $ du -hs /usr/share/icons
<pitti> 95M/usr/share/icons
<pitti> you bet
<mvo> :)
<pitti> mvo: but they are already getting squeezed in the pkgbinarymangler, so I guess there's not a lot we can win on them still
<pitti> except remove redundant/unneeded ones
<mvo> yeah, I wrote a script to compare that we really take the ones we need (and not duplicate from icon theme) for that, but only tiny win, maybe  ~15 icons or so
<mvo> I removed them now
<pitti> that's actually a significant potential there, /me shelves that for the next round of CD space fights
<pitti> 48M/usr/share/icons/gnome
<mvo> you think of something like pngcruncher? scour?
<pitti> 19M/usr/share/icons/Humanity
<pitti> I'm fairly sure that there's some overlap there
<mvo> yeah
<pitti> mvo: binarymangler uses optipng and advancecomp
<mvo> we do pngcrunch already, right?
<mvo> ok, cool
<mvo> in this case its quite possible that the result will actually be different as I build it locally and hvaen't factored in this
<pitti> ah
<mvo> (less additional space)
<mvo> *puhhh*
<mvo> thanks :)
<pitti> mvo: you can try by installing pkgbinarymangler, but don't worry too much
<pitti> it'll fit
<mvo> cool
 * mvo installs
<pitti> mvo: it'll probably take what feels like a year to build
<mvo> haha
<mvo> thats fine, I make a pot of tea in the meantime
<pitti> hah, always a good excuse!
 * pitti hugs mvo
<mvo> we got some nice additional high profile icons (like audacity) that used to be missing
<mdeslaur> please reject my isc-dhcp upload ^
<mdeslaur> I messed up the changelog
<pitti> *flush*
<mdeslaur> thanks pitti
<pitti> np :)
 * apw notes there was a compiler update yesterday, heads up that that may mean a kernel rebuild
<kirkland> just uploaded a trivial distcc fix, for a rather old bug
<kirkland> thanks
<stgraber> skaet: I just talked to didrocks and bug 746028 isn't Edubuntu specific. It affects Ubuntu as well but only for Maverick systems installed after the last ubuntu-wallpaper upload in Natty, thayt'
<ubot4> Launchpad bug 746028 in gnome-settings-daemon (Ubuntu Natty) (and 1 other project) "Edubuntu: Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/746028
<stgraber> *that's why it was a bit hard to reproduce for some :)
<stgraber> The caching system checks the timestamp of both the current cache and the wallpaper, has in my case my current cache (maverick's wallpaper) is newer than the wallpaper (natty's), it won't get updated and so I'll still have maverick's wallpaper after uprade
<skaet> stgraber,  thanks for chasing this down.
<skaet> stgraber,  thanks for tracking this down.
<bdmurray> skaet: has bug 751018 ever been discussed?
<ubot4> Launchpad bug 751018 in ubuntu-meta (Ubuntu) "i386 installer CDs are named improperly (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/751018
 * skaet looking
<skaet> bdmurray,   since it doesn't have an importance,  it appears to not have made the radar.
<SpamapS> skaet: talking with jhunt about getting bug #728531 fixed and we realized that there's a much bigger problem which has no report yet (he is filing now)...
<ubot4> Launchpad bug 728531 in upstart (Ubuntu Natty) (and 2 other projects) "chroot support is not reliable (affects: 2) (heat: 88)" [Medium,In progress] https://launchpad.net/bugs/728531
<SpamapS> skaet: the fix is already completed and has been tested (for both issues) for over a week.. we will probably need to get this new version of upstart in the release
<SpamapS> jhunt: ^^
<SpamapS> skaet: bug #766206
<ubot4> Launchpad bug 766206 in upstart (Ubuntu Natty) (and 1 other project) "user session support allows non-priv users to gain root privileges (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/766206
<skaet> SpamapS, jhunt,  ack.
<skaet> jhunt,  is there anything other than the fix in the new version of upstart?
<jhunt> aside from the oom bug and the user escalation issue, there is a fix for bug 707479.
<ubot4> Launchpad bug 707479 in upstart (Ubuntu) (and 1 other project) "service <service> restart does not use an updated job configuration (affects: 1) (heat: 43)" [Medium,Triaged] https://launchpad.net/bugs/707479
<jhunt> The final tweak is a change to the init-checkconf script which now checks script sections as well as the upstart config itself. The fact that the original init-checkconf didn't do this check was an oversight.
<jhunt> btw - init-checkconf is a script that users can choose to run if they so wish. It doesn't run as root (in fact it purposely disallows it)
<slangasek> did someone here reject gcc-4.4-armel-cross from binary NEW on Friday?  hrw says he didn't get an explanation for the reject and I don't see anything posted to ubuntu-archive
<ScottK> Not /me.
<slangasek> figured out the reason for the reject, we'll get it sorted
<skaet> jhunt, can you point me to a diff?
<jhunt> skaet: one sec...
<jhunt> https://code.launchpad.net/~jamesodhunt/ubuntu/natty/upstart/fix-chroot-sessions/+merge/58249
<jhunt> Note - the diff is quite big, but a lot of the changes are actually in the tests (init/tests/* and util/tests/*) which are only run at build time of course.
 * skaet looking
<jhunt> fwiw, cjwatson is aware of the need for these fixes (although I'm not sure he's looked at the code yet). I think he's back online tomorrow am.
<SpamapS> skaet: given the bugs that jhunt's branch fixes.. would you say it would be better to upload that package and let the release team approve it or get more feedback before that?
<skaet> SpamapS, after scanning through the changes,  I'd prefer that cjwatson be consulted before it get accepted in.   Feel free to upload, and cjwatson can approve or reject it when he's back tomorrow.
<skaet> jhunt, ^^
<SpamapS> skaet: thanks, will do
<jhunt> skaet: ack - thx.
<ScottK> I would appreciate it if some other releast team member would look at Bug 766386.
<ubot4> Launchpad bug 766386 in request-tracker3.8 (Ubuntu) "FFe: Sync request-tracker3.8 3.8.10-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/766386
<kirkland> could someone take a look at and ideally accept rabbitmq-erlang-client?  this fix enable us to rebuilt rabbitmq-stomp and fix its FTBFS
<Daviey> ScottK: Do you have a debdiff handy?
<kirkland> (all universe)
<ScottK> kirkland: Already accepted.
<kirkland> ScottK: just saw the mail, thanks!
<ScottK> Daviey: I can attach one to the bug.
<kirkland> ScottK: any idea how long to wait before sending the build-dependent package for a rebuild?  ie, i'll need to wait for a publisher run, right?
<ScottK> kirkland: If you build-dep on the new version you can upload right away.
<kirkland> ScottK: duh, good point
<kirkland> ScottK: wilco
<ScottK> No need to worry about archive skew then either.
<ScottK> kirkland: Accepted that one too.
<kirkland> ScottK: sorry, that one was a simple copyright change;  the FTBFS one is 1 last more coming
<ScottK> OK
<jbicha> hi, I'm looking for a sponsor for bug 426215
<ubot4> Launchpad bug 426215 in software-center (Ubuntu) (and 1 other project) "[UIF exception] apt:package-name isn't handled by the Store when appropriate (affects: 5) (heat: 35)" [Wishlist,Fix released] https://launchpad.net/bugs/426215
<kirkland> ScottK: okay, last two rabbitmq related changes, all to solve the FTBFS, which should be done after accepting and building rabbitmq-server and rabbitmq-stomp
<ScottK> Cool.
<ScottK> kirkland: Done.
<kirkland> ScottK: thanks
<stgraber> I'm guessing it's known that language-selector-common in maverick-security is failing in postinst ? breaking upgrade and netboot installs of maverick
<stgraber> pitti, jdstrand: ^
<jdstrand> stgraber: kees did that update
 * jdstrand goes to fetch him
<stgraber> language-selector-common's postinst returns exit code 2 (from what I can see in d-i's logs on a fresh maverick netboot install)
<pitti> I guess the kill should be || true'd?
<stgraber> indeed, redirecting output to /dev/null won't prevent kill from returning !=0 if the process doesn't exist
 * stgraber just finished reading the diff
<pitti> stgraber: kees is on it
<ScottK> stgraber: Did you follow the SRU regression procedure?
<ScottK> pitti: ^^^?
<jdstrand> ScottK: I don't think so, but kees is preparing updates as we speak
<ScottK> I think it's still useful for notification.  We just got questions about the update in #ubuntu-motu and I only knew the answer because I was on this channel.
<ScottK> Although I guess this is a security regression, not an SRU regression.
<ScottK> So it's a different process.
<stgraber> ScottK: as it was security we don't have a SRU bug open on LP. I'll open a bug report for the regression, mark critical and assign to kess (so he can close it with his upload)
<ScottK> jdstrand: Is ^^^ reasonable?
<jdstrand> fine by me
<stgraber> kees: please close bug 766534 in your upload (if you didn't upload already)
<ubot4> Launchpad bug 766534 in language-selector (Ubuntu) "Regression on maverick when updating to 0.6.7 (security upload) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/766534
<SpamapS> FYI: upstart package uploaded to natty, awaiting cjwatson's final review.
<kees> stgraber: the fix is already built in the security queue. I'll close it manually when it publishes. :)
<kees> incoming policykit-1 security update for natty...
<kees> (I put today's krb5 update into natty-security since it's not urgent, but policykit-1's update is semi-urgent)
<kees> (as in, nothing in the wild yet to exploit it, but is a local root escalation if someone can land it)
<genec> quick question (asked before; no answer): is it worth mentioning in the release notes that btrfs is still deemed experimental by kernel.org?
<ScottK> kees: Accepted.
<ScottK> genec: I'd vote yes.
<genec> ScottK: where would the best place be to raise this point?  here, a mailing list, an LP bug?
<ScottK> genec: File a bug against the ubuntu-release-notes project.
<genec> ScottK: I know support is coming along from all angles but the fsck is the one major point holding it back.  will do.
#ubuntu-release 2011-04-20
<genec> ScottK: bug 766654
<ubot4> Launchpad bug 766654 in ubuntu-release-notes "btrfs: still considered experimental by kernel.org (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/766654
<genec> oops.  somehow missed bug 619575
<ubot4> Launchpad bug 619575 in btrfs-tools (Ubuntu) (and 1 other project) "btrfs-tools fsck bug can cause data loss (affects: 4) (dups: 1) (heat: 28)" [Undecided,Invalid] https://launchpad.net/bugs/619575
<kees> ScottK: thanks!
<ScottK> You're welcome.
<skaet> hmm,  looks like there might be some archive synch up issues on the arm builds.
<skaet> The following packages have unmet dependencies:
<skaet>  libnux-0.9-0 : Depends: libnux-0.9-common (= 0.9.44-0ubuntu2) but it is not going to be installed
<skaet>  unity : Depends: unity-common (= 3.8.8-0ubuntu2) but it is not going to be installed
<ScottK> skaet: They failed to build on armel.  I just retried them.
<skaet> ScottK,   thanks!
<ScottK> nux is building.  Unity also needed the newer nux, so it failed again.   It'll need another retry after nux is build and in the archive on armel.
<pitti> skaet: scrutinizing the upstart diff in the queue now; was that the one you worried about?
<pitti> skaet: the changes look quite reasonable to me; I found one place which might cause a potential bug (commented on bug 766206), but it's defensive now and fails the right way around
<ubot4> Launchpad bug 766206 in upstart (Ubuntu Natty) (and 1 other project) "user session support allows non-priv users to gain root privileges (affects: 1) (heat: 10)" [Critical,Fix committed] https://launchpad.net/bugs/766206
 * pitti accepts and will take the bullets
<cjwatson> I haven't done a full diff review, but the general purpose of the upstart change has my approval, FWIW
<stgraber> skaet: for bug 746028 do we want the same "hack" I did for Edubuntu or should we wait to have an improved caching system (definitely post-natty) ? (touch the wallpaper in .postinst so that its timestamp gets bumped and triggers a cache update)
<ubot4> Launchpad bug 746028 in gnome-settings-daemon (Ubuntu Natty) (and 1 other project) "Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/746028
<skaet> stgraber,   I think the touch approach will be fine for Natty, its low risk, so would be good if we could get it in.
<stgraber> skaet: ok, I'll do a quick check to make sure it works fine with Edubuntu and if it does, will apply the same to Ubuntu and upload.
<skaet> stgraber,  thanks!!  agree that this should be revisted post-Natty though.  :)
<ara> good morning skaet
<skaet> good morning ara.  :)
<skaet> ara,  any worries on the hardware certification side?
<ara> skaet, are we having a release meeting this Friday, or are we skipping due to the holidays?
<skaet> ara,  will make a final call on it whether we have it or not tomorrow, when we have a better feel for how the initial images are building, and if there's any known kitten killers lurking.   Fingers crossed we won't need one.
<ara> skaet, OK, please, let us know
<ara> thanks!
<skaet> ara, will do.
<skaet> ara,  how are the results looking on the hardware cert tests?
<ara> skaet, they are looking good
<ara> skaet, we are preparing everything for the 11.04 certification testing after the release
<skaet> ara, thanks - could you send me a summary of what we're currently seeing?   Would like to review, and make sure to ask any questions tomorrow if possible.
<ara> skaet, nothing new apart from the bugs with blocks-hwcert tag
<didrocks> skaet: stgraber reading comments on https://bugs.launchpad.net/bugs/746028? did you read my last comment on how few people are impacted by the change? (and the wallpaper isn't really changed for ubuntu, not edubuntu)
<ubot4> Launchpad bug 746028 in gnome-settings-daemon (Ubuntu Natty) (and 1 other project) "Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 8)" [High,Triaged]
<stgraber> didrocks: yep, though if the touch does the trick, I don't see how it could hurt to do it
<didrocks> stgraber: hum, not sure about the future, seems a little win there (and we already got that for lucid/maverick then, without complain apparently)
<didrocks> it's just that the wallpaper was changed later, which has hidden the bug :)
<didrocks> anyway, I'll fix that upstream for GNOME 3.2 (didn't see bug report about it on bugzilla as well)
<didrocks> stgraber: I mean, little win for ubuntu-wallpapers, for edubuntu where the wallpaper is different, that's another story
<skaet> didrocks,  touch seems low risk and makes things a little more resiliant in future,  so don't see much downside to putting it in, and for those who notice subtle differences, it will stop bugs.
 * skaet --> heading out to QA meeting,  back on line later
<didrocks> skaet: well, we didn't get bugs for the 2 previous cycles even having the same issue (I expect people installing maverick *now* for upgrading are not the majority). However, I think we will have a lot of bug reports about the wallpaper not changing (even when they are not affected by this bug) because it didn't change visually ;)
<joshuahoover> the u1 team needs to release a new ubuntuone-client package to fix bug #764646 - can we get someone to review and give us the ok?
<ubot4> Launchpad bug 764646 in ubuntuone-client (Ubuntu Natty) (and 4 other projects) "music store widget dies with Â«TypeError: find_credentials() takes exactly 3 arguments (2 given)Â» (affects: 3) (dups: 2) (heat: 26)" [Critical,Triaged] https://launchpad.net/bugs/764646
<pitti> joshuahoover: pure bug fixes are fine and welcome at this point
<joshuahoover> pitti: ah ok, thanks!
<jibel> ev, ubiquity 2.6.6 is broken and today's desktop iso fails to install.
<ev> jibel: the fix is in trunk
<jibel> ev, ok
<pitti> oh? I just finished a test install two hours ago on today's desktop daily
<ev> I meant to upload it yesterday
<ev> but I got caught up in this apt-clone issue
<ev> pitti: are you sure it was today's desktop CD? The partitioner was very broken.
<pitti> .disk/info says Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110419)
<pitti> so apparently not then
<pitti> I rsynced it at 10:35 local, apparently I just missed today's one then, sorry
<pitti> (8:35 UTC)
<ev> no worries
<ev> I'm nearly ready to upload a fixed version
<jibel> ev, thanks.
<pitti> what a version jump!
<jibel> ev, once you uploaded the fix, can we rebuild the desktop images so we can try them today ?
<ev> yes
<ev> just waiting on the new console-setup to hit the archive
<cjwatson> yeah, dupload is less forgiving of the GPG error than dput is, I think
<cjwatson> reuploaded with dput
<cjwatson> (the first one landed in cocoplum:~lp_queue/ubuntu-queue/failed/)
<mvo> pitti: its all marketing!
<stgraber> mvo: so you're expecting it to be the real real final upload ? :)
<mvo> yes â¦
<mvo> YES!
 * pitti has that recorded!
<mvo> lol
<doko> pitti: please could you have a look at https://bugs.launchpad.net/ubuntu/+source/icedtea-web/+bug/767144
<ubot4> Launchpad bug 767144 in icedtea-web (Ubuntu) "FFe - update to current trunk/1.1 release (affects: 1) (heat: 8)" [Undecided,New]
<cjwatson> can somebody review console-setup?
<cjwatson> tiny change
<doko> am I allowed to? not member of the release team ...
<cjwatson> I think archive admin is sufficient for things that aren't feature changes
<jhunt> hi all - I've just raised an MP for bug 767053.
<ubot4> Launchpad bug 767053 in upstart (Ubuntu Natty) (and 1 other project) ""initctl status" no longer works as a non-privileged user (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/767053
<cjwatson> it's fine if it's uploaded today
<jhunt> orig.tar.gz in the usual place if required.
<cjwatson> can you get SpamapS to upload it?
<cjwatson> (dinnertime here)
<jhunt> cjwatson: ack
<jhunt> cjwatson: I've pinged SpamapS but he's away atm. I've gotta pop out but will try and check back later tonight...
<cjwatson> jhunt: I can't find the upstart .orig.tar.gz
<cjwatson> jhunt: can I have a link?  (I'm back now for a while)
<stgraber> sorry for uploading ubuntu-wallpapers twice. Got the GPG error someone mentioned earlier ...
<stgraber> they are both identical, so just reject one of them
<kirkland> can someone please accept rabbitmq-stomp from https://bugs.launchpad.net/ubuntu/natty/+queue ?
<kirkland> that has FTBFS until yesterday
<kirkland> but now it builds!
<cjwatson> stgraber: done (and accepted the other)
<cjwatson> kirkland: accepted
<kirkland> cjwatson: thanks
<jhunt> cjwatson, SpamapS: link is chinstrap:/home/jhunt/upstart/upstart-0.9.7.tar.gz
<Ampelbein> the apport upload from earlier broke installation and is generating lots of dupe-reports like 767496
<cjwatson> jhunt: thanks
<jhunt> np - sorry for the delay in replying.
<cjwatson> man's gotta eat
<cjwatson> I'm syncing up generated files with the tarball
<cjwatson> jhunt: uploaded; somebody who isn't me will need to review/approve it
<cjwatson> could somebody please review partman-auto (while I'm here to answer questions about it)?
<slangasek> cjwatson: taking a look
<cjwatson> http://lists.debian.org/debian-boot/2011/04/msg00333.html may be helpful for context
<cjwatson> there was a followup questioning the safety of doing this for swap partitions, which isn't relevant to this upload since I didn't enable that
<jhunt> cjwatson: thanks! I *will* fix that autogen problem when I get a chance :)
<cjwatson> jhunt: maybe we can run through it with a scratch branch at the release sprint
<jhunt> that'd be great, ta!
<cjwatson> hm, the preserve-existing-partition stuff in the installer doesn't work for btrfs
<slangasek> cjwatson: partman-auto accepted
<ScottK> cjwatson: Sounds like fodder for the release note that says "BTRFS is supported in the installer, but it's all still experimental."
<cjwatson> ScottK: could be, yeah
<cjwatson> not sure I want to attempt a fix now
<cjwatson> slangasek: thanks!
<ScottK> Anyone who relies on any data being preserved on BTRFS is asking for it.
<ScottK> We're already publishing updates through natty-security?
<ScottK> I mean we are, but is it on purpose?
<kees> ScottK: yes, I put non-essential updates into -security to avoid release archive churn.
<kees> ScottK: is that causing problems?
<ScottK> I don't think it's an actual problem, but I found it surprising that we were accepting them pre-release.
<cjwatson> I think we've done it before
<ScottK> OK.
<ScottK> I often get surprised by things I shouldn't.
<cjwatson> though I agree it seems odd at first, second, and third glance :-)
<jhunt> can we discuss a plan for bug 436936? As mentioned, the latest gdm.conf (comment 26) on that bug "works for me", but I don't have the hardware to fully test the change.
<ubot4> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) (and 9 other projects) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change (affects: 15) (dups: 2) (heat: 86)" [Medium,Triaged] https://launchpad.net/bugs/436936
<jhunt> I spoke to apw re the 2 udev events we're checking for (graphics-device-added and drm-device-added) and it seems the order they arrive in isn't necessarily well understood?
<stgraber> cjwatson: uploaded, just using "true" as an error handler did the trick
<barry> hi all.  is there still time, and are any sponsors available for a no-change rebuild to eliminate a mod_python error log message?
<ScottK> barry: Should be fine.
<ScottK> (although I don't volunteer to sponsor it)
<barry> ScottK: okay ;)
<cjwatson> stgraber: thanks, accepted
<ScottK> barry: Is this the same package we need the fix for to make the python3 version work with 3.2?
<ScottK> If so, it might make sense just to upload with that fix.
<barry> ScottK: no, it's a rebuild of libapache2-mod-python to get rid of an error log entry
<ScottK> Right, the other one was mod-wsgi.
<ScottK> Which means I probably made a wrong comment in a bug earlier today.
<cjwatson> grub-installer could use a review too - RC (IMO) installer fix
<barry> ScottK: oh well, it happens :)
<barry> ScottK: what bug were you thinking about?
<ScottK> The mod-python one about pulling in pyhon3.
<ScottK> Although it doesn't appear to have any python3 in it now, so maybe I got lucky.
<barry> could be bug 759943
<ubot4> Launchpad bug 759943 in mod-wsgi (Ubuntu) "mod_wsgi.so-3.2 gives errors (affects: 1) (heat: 12)" [Medium,In progress] https://launchpad.net/bugs/759943
<Daviey> barry, I need to upload that.
<barry> Daviey: thanks
<ScottK> Yeah.  That was the one.
<Daviey> ScottK, jamespage reworked the upstream patch to encapsulate all references to only do different behaviour on 3.2.  So the same patch is valid on 3.1 and 3.2.
<Daviey> He is going to fwd the patch to Debian.
<ScottK> Yeah. I saw.  Just accepted it.
<Daviey> groovy
<cjwatson> could somebody review grub-installer, please?
<cjwatson> it should be easy
<ScottK> cjwatson: Done.
<cjwatson> ScottK: thanks
#ubuntu-release 2011-04-21
<cjwatson> ha!  king of the grub
<cjwatson> http://paste.ubuntu.com/596733/ fixes the memtest86+ breakage
<cjwatson> 14:42  * apw notes there was a compiler update yesterday, heads up that that may mean a kernel rebuild
<cjwatson> apw: no kernel upload has happened - any reason why not?  time is getting tight!
<cjwatson> ogasawara: ^-
<cjwatson> if we can't take one at this point, what are the consequences?
<cjwatson> BTW, the btrfs changes in that grub2 upload are upstream backports fixing a problem that an Ubuntu user (Kurusitian, IIRC) has been reporting recently
<ScottK> Do we like this Ubuntu user?
<ScottK> ;-)
<cjwatson> well, he went and reported it upstream in such a way that upstream fixed it without me needing to intercede, which is a decent baseline ;-)
<ScottK> Absolutely.
<cjwatson> right.  preparing ubiquity and debian-installer roll-up uploads, and then I'm going to crash
<cjwatson> (sorry, Kurisutian, not Kurusitian)
<ScottK> Is grub2 | 1.99~rc1-13ubuntu1 | natty/universe | amd64, i386 correct?
<cjwatson> yes, the transitional package can stay in universe
<ScottK> OK.
<cjwatson> we generally use grub-pc
<ScottK> Is the version in grub.md5sum supposed to match the package version?  +965e5137eff659cded3adb640357c33d  maverick_1.98+20100705-1ubuntu1 does not.
<cjwatson> no, unfortunately ucf is run *after* a couple of substitutions are applied
<cjwatson> which is a bug, but I don't want to try to sort that part out for 11.04
<ScottK> OK.
<cjwatson> (because I'll doubtless get it wrong)
<cjwatson> the md5sum was from a test install of maverick-server-i386.iso
<ScottK> Also there's a grub2 in maverick-proposed.  Do we need to consider it?
<cjwatson> I'm going to supersede it and the one in lucid-proposed with versions that include a pile of wubi patches, as soon as I crawl out from under the pile of natty bugs long enough to be able to test them
<cjwatson> oh, you mean its /etc/default/grub
<cjwatson> that version doesn't change that file
<cjwatson> technically I probably ought to add the natty md5sum as well, but I didn't have a chance to do a test install to verify its clean state ...
<cjwatson> I can do that if you want, or we can just do that early in oneiric
<ScottK> I think that's fine.
<ScottK> On the list of current priorities, I think that's rightfully 'later'.
<ScottK> The rest seems reasonable.  Let's give it a shot.
<cjwatson> ace, thanks
<ScottK> Accepted.
<ScottK> You're welcome.
<cjwatson> now LP just has to send me a translation export for d-i ...
<cjwatson> (... or I need to poke exim into doing a queue run)
<ogasawara> cjwatson: I believe apw and skaet decided to hold off on the kernel upload.
<ogasawara> Apr 19 04/19/11:11:18:00 <skaet>  apw,  hold off on doing the upload to rebuild.  We'll go with the kernel we have for now unless we find a specific bug.   Most of the ecosystem is already known to work with this kernel.   We've been existing with some applications compiled with the flag, and some without for quite a while.
<ogasawara> Apr 19 04/19/11:11:59:59 <apw>  skaet, ok will do
<ogasawara> Apr 19 04/19/11:12:00:41 <skaet>  apw,  or not do, in this case actually.  ;)
<ogasawara> Apr 19 04/19/11:12:01:04 <apw>  skaet, ok will not do :)
<ogasawara> cjwatson: ^^ from #ubuntu-kernel
<cjwatson> ogasawara: OK, thanks
<cjwatson> could somebody please review ubiquity and debian-installer?  I hadn't asked because I'd hoped somebody would do it overnight, but they need to be on images ...
<slangasek> d-i accepted
<slangasek> looking at ubiquity
<pitti> icedtea-web looks ... nontrivial :/
<pitti> and no further information on the ffe
<skaet> Riddell, ScottK - bug 758614 doesn't look like its progressed much in the last 10 days.   I'm going to mark it as a natty-updates milestone target at this point, as it seems like something we can document in the release notes.   I've gone in and updated the milestone,  and add a release note task to it.   Please update the bug with the text you want in the release notes, or any updated status on it I may not be awa
<skaet> re of.
<ubot4> Launchpad bug 758614 in ubiquity (Ubuntu Natty) (and 2 other projects) "Kubuntu Wubi - Black screen during stage 2 (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/758614
<ScottK> I think you'd be better off asking ev or cjwatson about that since it's in Ubiquity.
<slangasek> ev: what's the reason for the change in ubiquity to repack debs in apt-clone? (no bug reference in changelog)
<slangasek> cjwatson: ^^ or if you know the answer - otherwise ubiquity looks fine to me
<skaet> ScottK,  since it appears to be Kubuntu specific and was going to affect the appearance of the boot of Kubuntu, it seemed appropriate to consult the Kubuntu leads to make sure it wasn't a "don't ship the images with it", in your judgement.
<ScottK> OK.  I'll defer to Riddell then.
<ScottK> So far I've managed to avoid knowing anything about wubi and I'd like to keep it that way.
<skaet> ScottK,  fair 'nuf.
<skaet> cjwatson, pitti - have we gotten the fresh set of language packs landed from the translation team?
<pitti> skaet: that's going to be exported today; I'll build them over the Easter holidays, so that they will be ready on Monday evening
<pitti> today is the deadline for translators, so we do the export today
<skaet> pitti,  yesterday was the deadline... :/
<pitti> deadline was yesterday
<pitti> skaet: right, sorry
<pitti> so the build started last night, and should be done in about 7 hours
<skaet> pitti,  thanks,  would be good if we could get them into the images being built today,  so we can get some community testing over the weekend on the candidates.
<pitti> skaet: today won't be possible; they need some 3 hours preparation and some 12 hours on the buildds
<pitti> but that doesn't block smoketesting of tomorrow's dailies, of course
<skaet> pitti, hmm...  will make note of that limitation in setting future deadlines.
<pitti> skaet: OOI, we aim for building the final-final images on Mon or Tue?
<pitti> well, we can leave the cron jobs on an then put either on the tracker
<skaet> pitti,  was hoping we could build the final images today... but if we're still missing languages.  not possible.
<pitti> skaet: why do we need them a full week before release?
<pitti> skaet: I thought the goal today was to have the archive in a consistent state, and buildable, non-oversized images, and then make a promise to not break any of that any more?
<pitti> that said, NBS is non-empty again, fixing
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is just noise
<skaet> pitti,  its because of the easter long weekend and lack of coverage during that period.
<pitti> I'm still not sure why usb-creator is uninstallable on arm; ogra, do you know why?
<pitti> otherwise http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html seems about as far as we can push it for natty
<skaet> we really only have today, tues and wednesday to get the final images locked and put through the iso tracker.
<skaet> pitti,  its not a holiday here in the US on Friday.   If we leave the daily tracker on tonight then, and it can pick up the language packs, I'll update the iso tracker with them on Friday.
<pitti> skaet: ok; I'll see to kicking off the builds this evening (hoping that the export will finish on time)
<skaet> pitti,  thanks!   If not ready when you call it an evening,  brief me on what to check for, and I'll kick off the builds.
<pitti> skaet: I'll ping you when I uploaded the packs
<pitti> skaet: after that, the thing to watch out should be "buildd queues are empty"
<pitti> (in general)
<pitti> http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html should not have outdated images and pending builds
<skaet> pitti, cjwatson,  other piece to make sure is in place for the image builds is the signed WUBI.    Do we have it?
<pitti> meh, alternate oversized, fixing
<pitti> skaet: I'm afraid I don't know what that is :/
<cjwatson> slangasek: not specifically, ev was talking about various apt-clone things yesterday and trying to make it work better in the absence of a network connection, and this may have been something he noticed due to that, but I don't have specific
<skaet> pitti,  cjwatson does. :)  signing key for WUBI is kept in controlled environment, and elmo needs to give us a signed version to include in the release.
<cjwatson> s
<pitti> skaet: next alternate builds will be in size limit
<skaet> pitti:  ok
<cjwatson> yeah, I can go chase down wubi later today
<skaet> thanks cjwatson
<apw> cjwatson, for completeness, we analyses the common use cases and dkms and all of those packages seem to be safe against the general compiler change, so for that change we decided we could wait.  for the armel potential miss compile, the decicison from the compiler folks and release team was that the combination we have was well tested and therefore the lowest risk strategy was to wait
<cjwatson> apw: *nod*
 * skaet -> few more hours of sleep,  back on later
<pitti> skaet: will there be a meeting tomorrow?
<pitti> skaet: oh, good night!
<mvo> good night!
<ev> slangasek: it was always intended to do the repacking, and at one time did, but the command line syntax for apt-clone was changed and ubiquity was not updated to reflect that
<ev> in practice, I don't see the repacking happening often at all, given that the option is disabled when there's no internet connection
<cjwatson> maybe somebody else could review ubiquity from the queue, based on slangasek's and ev's comments; I can't, since I uploaded it
 * ev volunteers ;)
<ogra_> pitti, in the past usb-creator had a syslinux dep (which doesnt exist on arm), not sure thats still there
<pitti> ah, of course
<pitti> ogra_: so that's nothing new really
<ogra_> nope, let me try to install it to see where it complains
<ogra_> The following packages have unmet dependencies:
<ogra_>  usb-creator-common : Depends: syslinux but it is not installable
<ogra_> E: Broken packages
<ogra_> there we go
<ogra_> feel free to ignore
<ogra_> (i thought we switched to grub here)
<cjwatson> not yet
<ogra_> ah, k
<cjwatson> not that that would help you for the time being anyway, since the grub arm port isn't finished
<ogra_> yeah
<ogra_> hmm, are overlay-toolbars seeded ? i just notice they are missing on armel installs
<ogra_> i seem to have them on x86
<pitti> desktop: * (overlay-scrollbar)
<ogra_> aww
<ogra_> k, i think i need to check the seed here
<pitti> indeed, missing from desktop-armel in ubuntu-meta
<pitti> perhaps it wasn't built at the time this got refreshed?
<ogra_> we dont use desktop on armel .... but i want it in netbook
<pitti> aah
<ogra_> which is separately maintained
<ogra_> pitti, hmm, looks like we have gone a bit out of sync in the seeds, i'll fix that and do a meta upload, there is more missing than just scrollbars
<pitti> ok, thanks
<pitti> this currently doesn't seem to be the best way to handle netbook/desktop seeds
<cjwatson> I thought this was what desktop-common was for
<pitti> cjwatson: d-common sohuldn't have gtk/gnome specific bits, though?
<pitti> since it's also used by Kubuntu and friends?
<cjwatson> oh, true, OK.  I thought there was something common to desktop and netbook, but maybe not
<cjwatson> (and now would not be the time to introduce it)
<ogra_> err
<ogra_> why was alsa-utils rejected ?
 * ogra_ is confused, i have an accepted as well as a rejected mail
<ogra_> oh, heh, seems luke did the same upload later
<ogra_> hmm, rfkill should be seeded in the desktop seed according to the changelog ... but its not there ?
<ogra_> ogra@osiris:~/Devel/seeds/ubuntu.natty$ grep rfkill *
<ogra_> ogra@osiris:~/Devel/seeds/ubuntu.natty$
<ogra_> actually its not there at all
<ogra_> that was horridly out of sync
<pitti> ogra_:
<pitti> Package: rfkill
<pitti> Task: ubuntu-desktop, kubuntu-desktop, kubuntu-mobile-desktop, kubuntu-mobile, edubuntu-desktop, xubuntu-desktop, ubuntu-netbook
<pitti> seems fine for desktop?
<ogra_> weird, i cant find it in the seed
<pitti> ogra_: it's in the platform seed, desktop-common
<ogra_> ah
<ogra_>   * Added rfkill to desktop ....
<ogra_> is a weird changelog entry then
<ogra_> that confused me
<pitti> ogra_: urgh
<pitti> ogra_: this includes packages which are pretty central to the desktop itself, thus will provide quite a different user experience than beta-2
<pitti> ogra_: you are the master of netbook, so if you are confident that you can test the next daily, and possibly revert some seed changes if they cause problems, fine for me
<ogra_> pitti, well, what should i drop ? i didnt want to keep the out of sync-ness
<pitti> ogra_: there's nothing that "shouldn't be there", I'm just saying that this introduces some new things like ginn which probably didn't get tested much in the netbook enviroinment yet
<ogra_> and wont i guess, isnt ginn a touchscreen thing ?
<pitti> gestures
<ogra_> ah
<pitti> so not limited to touchscreens, also affects touchpads
<ogra_> well, we have neither on a panda or beagle board
<ogra_> but people wanting to try out ubuntu on armel based touch devices will want it, so i dont think its wrong to include it
<ogra_> its really bad that we got so much out of sync though
 * ogra_ looks forward to O where we can drop the netbook seed
<pitti> do we actually need libsdl there?
<pitti> and gcc?
<pitti> not sure why gcc is even there, TBH
<ogra_> well, the comment in the seed file says its needed by the above gstreamer/pulse bits
<pitti> ok
<ogra_> gcc/build-essential is needed for dkms
<pitti> gcc/make/etc. will increase the image size quite a bit
<ogra_> i thought we actually had it on a lower seed already
<ogra_> i was surprised to find it in desktop but it was one of the differences
<pitti> ah, right, it's already there
<pitti> gcc has an ubuntu-netbook Task: header already
<pitti> so it's a no-op
<ogra_> image size is nothing we actually have to care about on armel
<ogra_> we have a few 100M free
<pitti> and then there's some noise from renamed packages, these should be ok
<ogra_> yeah
<ogra_> i wonder wh it didnt show on component mistmatches that we kept so many dropped things in -netbook
<ogra_> *why
<pitti> ogra_: we need the transitional packages until the next LTS for upgrades
<ogra_> ah, indeed
<pitti> of course they might actually pop up after we accept this
<pitti> but then we'll just seed them to supported
<ogra_> right
<ogra_> i didnt think of transitions
<ogra_> :)
<pitti> ogra_: ok, so shall we give that a try? perhaps GrueMaster can test tomorrow's dailies?
<ogra_> do i have a chance to roll back if anything fails ?
<ogra_> (how hard is the hard freeze ? :) )
<pitti> if we can roll it back tomorrow or on Sat, yes
<ogra_> ok
<pitti> otherwise it'll get pretty tight with the finals
<ogra_> then let it in, I#ll test myself too
<pitti> ogra_: otherwise the only really non-negotiable deadline is "Thursday", I think :)
<ogra_> heh, yeah
<ogra_> well, nux is blocking image builds atm
 * cjwatson wonders if it's worth including a GRUB patch for a bug that completely breaks amd64 EFI installations
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617388
<ubot4> Debian bug 617388 in grub-efi-amd64 "grub-install fails to work on grub-efi-amd64" [Normal,Open]
<cjwatson> inclined to say yes ...
<pitti> cjwatson, ev: caught up with scrollback now; that apt-clone change is the only thing that I don't understand, but ev answered it now
 * pitti waves through
<ev> yay
<ev> thanks pitti
<pitti> ev: no worries; thank you for fixing it! :)
<ev> :)
<pitti> ok, queue back down to icedtea-web and overlay-scrollbar, neither of which I'm comfortable accepting
<pitti> bbl, lunch
<mvo> I suppose I can not yet upload to natty-proposed, can I?
<cjwatson> mvo: you should be able to
<mvo> great! thanks
<Riddell> I get a crash on today's live images when loading the ubiquity partitioner page, kernel complains about btrfs
<cjwatson> known, ubiquity 2.6.7 would've fixed it (though it was too late for the CD build anyway), except it FTBFS
<cjwatson> btrfs complaint is irrelevant
<Riddell> sorted then
<mvo> mod-python should not be on the cd, so it should be fine
<Daviey> mvo: How come mod-python is NEW?
<Daviey> ah, scrub that.
<mvo> Daviey: not new, this is just a rebuild, I think the bot just tells us that its new-in-the-queue. its not on your server cd, is it? I looked at the file list and didn't see it at least
<Daviey> mvo: Yeah, i missparsed it. :(
<mvo> no worries
<Daviey> mvo: but yes, it is server-ship by the seems of it.
<Daviey> On the ISO at least.
<mvo> ok, thanks. if its not suitable anymore just let me know and I will push to natty-prposed, but its just a rebuild
<Daviey> mvo: Looks safe to me :)
<mvo> yeah :)
<bdrung_> how high is the chance to get a FFe for lintian 2.5.0~rc3?
<cjwatson> mvo: it's fine, we don't have a final ubiquity yet
<cjwatson> bdrung_: I'd say minimal
<cjwatson> bdrung_: I mean, unless there's a *stonkingly* good reason
<mvo> thanks
<pitti> oh, someone had the grit to accept icedtea?
<stgraber> can someone approve the nomination for Oneiric on bug 746028 ?
<ubot4> Launchpad bug 746028 in ubuntu-wallpapers (Ubuntu Natty) (and 5 other projects) "Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 8)" [Undecided,Fix released] https://launchpad.net/bugs/746028
<stgraber> I marked it as fix released for edubuntu-artwork and ubuntu-wallpapers as they now have a workaround, but the work on g-s-d should be targeted for oneiric
<pitti> stgraber: done; odd that you can't do it yourself
<cjwatson> pitti: I did - the other changes didn't look too serious compared to the complexity of the rest of icedtea, and I thought the note about non-redistributable PDFs in the changelog was sufficient reason for an update
<doko> pitti: it's the plugin, not the vm/jdk. and I'll prepare another update today or tomorrow, they are now ready to branch, so the thing is feature complete
<stgraber> pitti: I used to but something changed recently and I can't anymore
<pitti> doko: yeah, a further upgrade should be a lot smaller, I guess; I was just interested in the testing on current natty (as I asked in the bug)
<pitti> stgraber: perhaps it's because oneiric is not open yet, who knows..
<doko> pitti: honestly, this package belongs to the desktop team, chrisccoulson alrady did volunteer to mainain it ;-)
<pitti> splendid :)
<joshuahoover> pitti: not sure if this is the right place to ask (since it's for an sru on maverick) but... can we get someone to look at bug #709494 as an sru for maverick? (already in natty)
<ubot4> Launchpad bug 709494 in ubuntu-sso-client (Ubuntu Natty) (and 5 other projects) "[SRU] Missing user's name field (affects: 2) (dups: 1) (heat: 22)" [High,Fix released] https://launchpad.net/bugs/709494
<pitti> joshuahoover: it was already approved, wasn't it? just get it uploaded
<joshuahoover> pitti: maybe it was...hmmm...ok, we'll get it uploaded, thanks!
<ogra_> hmm, could i get a quick sync of abootimg from sid (its not in ubuntu yet and since 2 weeks in sid) ... its a helper tool to roll boot images for android based systems (and muchly used by ac100 devs)
<cjwatson> ogra_: please use requestsync --lp, and then it'll be easy
<ogra_> hmm, k ... i was actually to lazy to file a bug :) but will do
<ogra>  bug 768343 ...
<ubot4> Launchpad bug 768343 in ubuntu "Sync abootimg 0.3-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/768343
<pitti> ScottK: I acked all the no-code-change vdr plugins, looking at the six remaining ones
<pitti> (just saw your comment one one, so let's coordinate a bit here)
<ScottK> pitti: Great.  I'll leave it to you then.
<ScottK> I saw that one first in my bugmail, replied, then saw the rest and got a bit overwhelmed.
<pitti> for the others I'm not sure; I'll check the debian bts for new bugs, and depending on that ack or ask for a no-change upload
<pitti> ScottK: I left the difficult ones for the end :)
<pitti> yay, FTBFS due to test suite failures
<pitti> unity accepted
<pitti> sorry, ubiquity
<ogra_> too many Us
 * pitti dreams of a day when so many packages have builtin tests that you can basically say "it compiles, it works" for good
<ScottK> Does the apt upload in queue break U/I freeze since it adds strings to a CLI app?
<pitti> ScottK: note that this is an upload to -proposed
<ScottK> Ah.  Thanks.
<pitti> I think we should still wait a bit before we accept them, at least until next Tuesday ors o
<pitti> "or so"
<ScottK> Agreed.
<ScottK> I need to watch for that.  Thanks.
<pitti> ScottK: but does it?
<ScottK> It does add strings.
<pitti> ScottK: it changes the indentation of the clog <<, but the string itself looks identical to me
<ScottK> Oh.
 * ScottK looks again
<pitti> ScottK: right, those are new matches against dpkg output for filtering out bogus crash reports
<pitti> well, I might have missed something
<ev> new ubiquity uploaded that fixes the FTBFS test failure
<pitti> ev: already accepted :)
<ev> oh great
<ev> thanks!
<pitti> ev: 16:23:48        pitti | yay, FTBFS due to test suite failures
<pitti> ev: kudos for having a working test suite during package build!
<ev> thanks!
<pitti> ev: I figure that's not a trivial thing to do for a GUI installer
<ScottK> Reading it again, I think it's fine re string changes.
<ev> my goal is to integrate coverage.py and others as well
<pitti> ScottK: thanks for double-checking
<ev> pitti: not terribly.  Hitting it from both ends.  Unit tests for important functions, system level tests in the form of a netbook test farm driven by hudson/jenkins for everything the former misses
<ev> with the tests in the latter being ldtp
<cyphermox> i have a fix in ubuntu-mono for bug 746674 and bug 767186; pushing, stgraber would review it
<ubot4> Launchpad bug 746674 in ubuntu-mono (Ubuntu) (and 1 other project) "Animation displayed when connecting to a VPN is confusing (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/746674
<ubot4> Launchpad bug 767186 in ubuntu-mono (Ubuntu) "nm-signal-* icons break nm-applet (affects: 5) (dups: 2) (heat: 30)" [Low,In progress] https://launchpad.net/bugs/767186
<cyphermox> stgraber; the branch we were discussing is this: https://code.launchpad.net/~mathieu-tl/ubuntu-mono/animation-fixes/+merge/58691
<ScottK> Try again in the channel I meant...
<ScottK> Does the desktop-file-utils in queue affect systems where software center is not installed?
<ara> skaet, hello!
<cjwatson> skaet: Wubi is signed now, thanks to Ng and ev
<skaet> cjwatson, thanks!
<stgraber> cyphermox: looking at it now
<cyphermox> stgraber, ok, thanks
<stgraber> cyphermox: merged, pushed and uploaded. Just need to wait for an archive admin to review and see if that can still go on the final image.
<skaet> cjwatson, pitti - what's left before starting off the images?
<cjwatson> from my point of view: waiting for build queues to clear and publication to complete
<pitti> here as well
<pitti> plus the langpacks (but they don't block daily images and smoketesting)
<cjwatson> by the time it's done, I expect it will be time for dinner and church here, after which you aren't going to hear much from me until after Easter
<cjwatson> so unless somebody else does it, we could let tomorrow's cron jobs take care of the builds
<cjwatson> though that does mean no images until tomorrow, so dunno
<pitti> skaet: FYI, there's also apparently some debate going on about the overlay scrollbars
<Riddell> until after Easter Monday presumably, not the whole of the easter holy week
<cjwatson> anyone want to determine urgency of ubuntu-mono?
<cjwatson> Riddell: holy week is this week, not next
<pitti> skaet: I nacked turning them on by default in the bug, but I hear that there might be some override coming
<Riddell> oh, really?  I get that wrong every year
<cjwatson> Riddell: though yes, I don't mean "until after Eastertide", since people might like to hear from me sometime before Pentecost :-)
<pitti> cjwatson: u-mono> looking
<pitti> cjwatson: ah, that's the bug which fills your ~/.xsession-errors with megabytes per hour, checking
<cjwatson> there's a pile of vdr sync requests in the queue; I'll process them shortly, though they're universe so don't need to block image builds
<pitti> right
<pitti> cjwatson: 6 of them are new upstream versions; I've been meaning to take a closer look at them, but haven't found time yet
<pitti> (they aren't acked yet)
<pitti> I just acked the no-code-change ones
<cjwatson> I'm just running sync-helper, so will pick up just the acked ones I presume
<pitti> cjwatson: yes; the others don't have u-archive sub'ed yet
<pitti> cyphermox: the ubuntu-mono change is quite intrusive, can you please explain in more detail what that does?
<pitti> cjwatson: did you test this with vpn, normal wifi, and ethernet?
<cyphermox> pitti, sure, there's two things in there
<pitti> cyphermox: e. g. I don't understand why 22/nm-vpn-connecting12.svg changed
<pitti> it talks about resizing 16 pixel icons and dropping others, but not changing the other sizes
<cyphermox> pitti, one is fixing the issues with .xsession-errors filling up - that's resizing the icons in status/16 so that they're actually 16x16
<pitti> right, I understand that part
<cjwatson> pitti: I guess you mean cyphermox
<pitti> and the removed vpn connections are overlays?
<pitti> cjwatson: right, sorry
<cjwatson> np
<cyphermox> the nm-vpn-connecting-* icons that's fixing the animations, so bug 746674 ; where when you try to connect a vpn it shows up just a padlock at the lower right corner of the icon's spot that appears and disappears, switching between that and the normal "processing" waves thingy that goes up and down
<ubot4> Launchpad bug 746674 in ubuntu-mono (Ubuntu) (and 1 other project) "Animation displayed when connecting to a VPN is confusing (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/746674
<cyphermox> do you see what I mean? ;)
<pitti> cyphermox: they wren't removed either, but changed apparently?
<cyphermox> removed?
<pitti> Drop extra nm-vpn-connecting* animation icons from status/ directories, they don't belong in there anyway.
<cyphermox> right
* skaet changed the topic of #ubuntu-release to: Hard Freeze in effect! | Natty Narwhal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or whale food | melior malum quod cognoscis
<pitti> ah, right, they did get removed
<cyphermox> they were in status/, should have been in animations/, I removed them, and put new ones with the name name in animations to fix the animation
<pitti> cyphermox: I see, they are both in animations/ and in status/
<Riddell> cjwatson: you said that ~/cdimage/www/simple/kubuntu/HEADER.html can be hand edited, it's not in any revision control then?
<cyphermox> pitti, so the end result is instead of having a vpn connecting animation that looks funky, restoring the same behavior we had in maverick
<cjwatson> Riddell: nope
<pitti> cyphermox: ok, thanks for the heads-up
<cjwatson> Riddell: what are you planning on doing?
<cyphermox> pitti, sorry, maybe the changelog entries indeed were a little unclear
<Riddell> cjwatson: adding the extra div needed to tidy up http://releases.ubuntu.com/kubuntu/ and give it a kubuntu logo
<cjwatson> Riddell: ok, sure, styling changes are fine
<mvo> please let me know if the app-install-data-partner package has a chance still, if not I will upload it as a sru
<bdmurray> I'd like to see bug 767776 fixed in natty (soon) so we can also fix it in maverick
<ubot4> Launchpad bug 767776 in apt (Ubuntu Natty) (and 3 other projects) "apport report blocking of dpkg I/O errors is incomplete (affects: 1) (heat: 10)" [High,In progress] https://launchpad.net/bugs/767776
<mvo> is it ok to upload a new apt for natty at this point? if so, I will do it NOW
<mvo> (well, once I got the ok :)
<pitti> there's already a natty-proposed upload for it, so we can already do a maverick SRU, no?
<mvo> I think if we can, then all is good, most of the upgrade will be done with the maverick version of apt anyway so this is the important one
<pitti> mvo: please upload the maverick one, I can process it today
<pitti> mvo: then we can send it to -updates next wednesday or so
 * skaet nods
<pitti> (should still get some baking time)
<stgraber> skaet, cjwatson: Is bug 436936 something that we'd like to have fixed on the final image or should rather go in -updates ? jhunt says it'd need some testing on nvidia and other weird graphic cards before it can be uploaded. So I'm wondering if I should start looking for testers now or if we want to wait.
<bdmurray> okay, I'll work with the sru verification team to get it tested
<ubot4> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) (and 9 other projects) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change (affects: 15) (dups: 2) (heat: 86)" [Medium,Triaged] https://launchpad.net/bugs/436936
<pitti> mvo: although I expect that apt will get updated rather early?
<mvo> ok
<pitti> mvo: well, the old apt will still run at that tiem
<mvo> yep
<cjwatson> stgraber: oh, best leave it for an SRU, it's gone wrong once already this cycle
<cjwatson> stgraber: I just don't want it to be forgotten
<mvo> apt 0.8.3ubuntu7.1 is uploaded to maverick-proposed
<skaet> stgraber,  +1 with what cjwatson said.
<stgraber> cjwatson: Ok, I'll re-milestone to -updates then
<cjwatson> oho, I just did a successful wubi upgrade within lucid
<cjwatson> (with a PPA)
<cjwatson> now to get it all building in maverick too ...
<ScottK> The iptraf diff in queue will be absolutely trivial for any C programmer out there to review.
<dbarth> hi pitti; i've commented on https://bugs.launchpad.net/ayatana-scrollbar/+bug/766660
<ubot4> Launchpad bug 766660 in overlay-scrollbar (Ubuntu Oneiric) (and 3 other projects) "[FFE] Switch the ayatana-scrollbar on by default (affects: 1) (heat: 8)" [Undecided,Confirmed]
<pitti> dbarth: thanks, reading
<pitti> hm, it looks like the LP langpack export won't actually finish before tomorrow 1900 UTC (see https://translations.launchpad.net/ubuntu/natty/+language-packs)
<ScottK> Nevermind on iptraf.  Just noticed it's a -proposed upload.
<pitti> at least that's how I interpret the past dates
<pitti> unfortunately dpm isn't online any more to check with
<pitti> but I'll see to kick off the build Saturday morning
<ScottK> So does that mean another 24 hours for fixing?
<ScottK> Or do we still go into true kitten killers only mode today?
<pitti> ScottK: we still want solid images tonight, I think, so that we can start smoketesting and not jeopardize more than necessary; but critical fixes that pop up during smoketesting would still have a day, yes
<ScottK> OK.
<pitti> skaet's call in the end, I think
<dbarth> pitti: it feels to me like we've done our homework seriously, with lamalex and jibel working on it with the community
<dbarth> pitti: was that an information that you were missing when assessing the request?
<pitti> dbarth: it's still changing a lot of apps hours before building images :/
<pitti> and the package also does more changes
<pitti> like introducing a new xsession script, etc.
<dbarth> hmm, it was a tradeoff vs a code change, ie adding elements to a string list for the blacklist
<pitti> in retrospect it should never have had a whitelist to begin with, but now it's too late to correct that in the past :/
<dbarth> pitti: i understand your reluctance
<dbarth> do we have an SRU window open here?
<pitti> and it won't fix the inconsistency either way (firefox, gnome terminals, etc.)
<pitti> dbarth: i don't see why a new xsession script would be required at all here? if it wants to drop the whitelist query, it sohuld just do that
<dbarth> no indeed, that's not in the scope of what we could do this cycle
<dbarth> then we can change the whitelist function to just return TRUE, and never check what's in the list actually
<pitti> or just not call it
<dbarth> that would change the gtk patch
<dbarth> which we didn't want to do
<dbarth> leave gtk alone, and just change our part
<pitti> well, it would be the right solution, it just would be even more intrusive indeed
<pitti> (at this point)
<dbarth> again i understand the relunctance, and i don't want to crash the image preparation process
 * pitti -> out for a bit, back for TB meeting
<dbarth> pitti: ok, in all cases, i'll ask to have a better version of the update that doesn't add a session script
<dbarth> pitti: thanks
<cjwatson> dbarth: well, any changes now definitely have an effect on image preparation
<cjwatson> I don't really have an opinion on the bug at hand either way, but nobody should be under the impression that there is slack time remaining
<doko> cjwatson, pitti: updated icedtea-web, now built from the release branch
<cjwatson> doko: is this necessary?  see my comments just above
<doko> dvd images already building?
<cjwatson> doko: waiting for everything to publish before building images
<cjwatson> we do have to change base-files still, per the checklist; but everything else directly delays images
<cjwatson> doko: so I need a clear rationale?
<doko> well, will ask anyway for an sru for the final 1.1 version, so reject it
<dbarth> cjwatson: i am not implying or assuming any of this; i'll just shut my ... keyboard now and let you work; sorry for this
<doko> cjwatson: powerpc buildds are down, didn't get a reply from lamont. so images will have to be delayed
<cjwatson> doko: yes, sorry, this should go to SRU.  I accepted the previous one just because of the unredistributable-PDF thing you mentioned in the changelog
<cjwatson> doko: no, we can start with other images without waiting for powerpc
<doko> hmm, two i386 buildds down too, so either something is wrong, or somebody is working
<pitti> I revived some buildds this morning, but they don't seem to hold up very long
<cjwatson> dbarth: I didn't mean to be snappish, if that's how it came across
<doko> pitti: hmm, how do you do this?
<cjwatson> dbarth: can we consider this for SRU instead, perhaps?  It's unconventional for SRU, but it would let us test at more leisure
<pitti> doko: change builder details, check/clear the failure notice field, and check "buidler state ok"
<doko> and that does help?
<pitti> cjwatson: major UI changes in an SRU?
<cjwatson> I don't know if that's the right thing to do, just a suggestion
<pitti> doko: it seemed to help for most of the failed buildds this morning
<cjwatson> pitti: "unconventional" may be an understatement
<pitti> doko: apparently not here, though, they just failed again
<dbarth> cjwatson: nw, it's fine ;) yes, i'll work with this approach in mind
<cjwatson> skaet: base-files uploaded, debian-cd OFFICIAL set to Release; just noticed that the alpha warning is still present on ubiquity's language page in Kubuntu, so we'll need to flip the switch to disable that too
<cjwatson> base-files needs somebody to review it (hint)
<skaet> cjwatson,  just looked at with jdstrand.  Seems fine.  approved.
<cjwatson> skaet: which?
<skaet> base-files
<cjwatson> oh, right - thanks
<cjwatson> uh, so this late zsh upload added a new build-dependency that isn't in main ...
<pitti> skaet: ^ I uploaded a reversion of zsh to the previous version that worked, to fix this in a safe manner (see bug 762286)
<ubot4> Launchpad bug 762286 in zsh (Ubuntu) "Please merge zsh 4.3.11-4 from Debian (affects: 1) (heat: 10)" [Wishlist,Confirmed] https://launchpad.net/bugs/762286
<pitti> skaet: the debdiff to the current ubuntu version will look confusing, but I verified that debdiff to zsh_4.3.11-3ubuntu1.dsc is just the changelog
<pitti> skaet: mvo and blueyed were pinged in #u-devel, but if they don't reply soon, I recommend accepting this
<mvo> pitti: yep, sorry for this
<pitti> mvo: ok, thanks for checking
<pitti> skaet, ScottK, slangasek: could either of you please review/check my zsh upload?
<mvo> I just overlooked the new build-depend when I reviewed the diff
 * pitti hugs mvo, happens
<pitti> it never built, so it will have little impact on the images
<pitti> but we can't release like that
 * mvo nods
<slangasek> so we should take the revert, or is another fix being prepared?
<mvo> I will not work on a fix for this tonight, so +1 for reverting from me
<slangasek> ok
<slangasek> accepted
<pitti> cheers
<skaet> slangsek, pitti, mvo,  - ack.
<kenvandine> pitti, sabdfl had me copy and paste his response to bug 766660 for overlay-scrollbar
<ubot4> Launchpad bug 766660 in overlay-scrollbar (Ubuntu Oneiric) (and 3 other projects) "[FFE] Switch the ayatana-scrollbar on by default (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/766660
<pitti> skaet: I need to run now; do you have some time to sort this out? ^
<skaet> pitti, multiplexing on multiple fronts (sprint in progress),   just scrolled through the bug.
<kenvandine> pitti, have a great easter!
<skaet> kenvandine,  I've gone in and approved it.
<kenvandine> skaet, thx
 * lamont goes around stabbing dead builders
<lamont> pitti: re-enabling an 8002-failed builder is fruitless unless the slave launchpad-buildd has been restarted
<slangasek> is there any time left to include a plymouth upload for bug #566818?
<ubot4> Launchpad bug 566818 in plymouth (Ubuntu Natty) (and 3 other projects) "Cryptsetup passphrase prompt during boot: every character typed repeats the prompt (affects: 24) (dups: 4) (heat: 150)" [Medium,Confirmed] https://launchpad.net/bugs/566818
<slangasek> or should I rather point this to the SRU queue?
 * cjwatson quite annoyed about bug 722955 (my fault) and bug 762833 (totally not my fault)
<ubot4> Launchpad bug 722955 in wubi (and 2 other projects) "Wubi.exe on http://releases.ubuntu.com/lucid/ is the wrong version (10.04.1 instead of 10.04.2) (affects: 2) (dups: 1) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/722955
<ubot4> Launchpad bug 762833 in ubuntu (and 2 other projects) "http://www.ubuntu.com/desktop/get-ubuntu/windows-installer offers lucid wubi.exe and claims it's the most recent version (affects: 2) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/762833
<skaet> slangasek,   its medium a priority, so better to get it into SRUs at this point.   Too much churn on other fronts.
<slangasek> ack
<cody-somerville> ubuntuone-client 1.6.1-0ubuntu3 finished building on amd64 7 hours ago but hasn't published. Is this because natty is in pre-release freeze?
<slangasek> cody-somerville: no, freeze affects source not binaries (nor mirroring)
<slangasek> cody-somerville: looks like a mirroring problem - it's published correctly on cocoplum, and sure enough it finished building 7h ago
<micahg> this isn't the first time I've seen an issue with that package being mirrored, I'm also having trouble pulling ubuntuone-client from my local mirror
#ubuntu-release 2011-04-22
<skaet> ubuntu-desktop i386, amd64, amd64+mac images published for smoke test purposes
<cody-somerville> slangasek, maxb suggests that maybe the publisher is in manual mode?
<GrueMaster> ubiquity isn't building all packages on armel, which has caused a cascade failure for image builds.
<maxb> Purely a guess based on the timestamps at
<maxb> http://gb.archive.ubuntu.com/ubuntu/project/trace/
<maxb> cody-somerville: ah. He's already checked on cocoplum, ignore what I said
<skaet> GrueMaster, urk   thanks for flagging.
<slangasek> cody-somerville: putting the publisher in manual mode never affects mirroring
<cjwatson> GrueMaster: details?  looking at it on the archive master system doesn't seem to bear out that claim
<slangasek> I suspect he's looking at an artifact of syowa's mirroring problem (cf #is)
<cjwatson> it seems likely, yes
<cjwatson> ok, so that looks like it should be fixed soon
<skaet> ubuntu headless (omap3, omap4) are off the builder,  and have been posted.
<skaet> GrueMaster, ^
<GrueMaster> cjwatson: https://launchpad.net/ubuntu/+source/ubiquity/2.6.9/+buildjob/2491220
<GrueMaster> Or am I missing something?
<GrueMaster> I also had an image build failure email.
<slangasek> GrueMaster: those are the only two binary packages that are architecture-dependent
<GrueMaster> Ah.
<cjwatson> yeah, what he said.  notabug :)
<slangasek> the rest are architecture: all - so you could indeed have seen problems because the arch: all packages, built as part of the i386 build, were published but the armel ones not
<slangasek> (particularly given the aforementioned mirroring issue)
<GrueMaster> I'm going to assume a false positive somewhere.  The email I have is from the headless omap3 image failing to build, but it is now on cdimage.u.c
<GrueMaster> (nothing to see here, move along).  :P
<skaet> xubuntu desktop i386, amd64 posted
<kees> skaet: it looks like cyrus-sasl2-heimdal is not on the images, can I upload a fix for LP: #768707?
 * skaet looking
 * kees just added comment 1
<kees> and now the debdiff
<skaet> kees, can you give me some context on how its used?
 * skaet looking at the debdiff too now
<kees> skaet: when people use heimdal instead of mit kerberos with their sasl authentication, they need this package
<kees> skaet: so, like dovecot, postfix, sendmail, using kerberos, but not mit kerberos
<skaet> kees,  thanks for the context,  it was a new one for me.
 * kees will be back in a little bit to upload it if it's approved. thanks for looking!
<skaet> kees,  diff looks limited in scope,   go ahead and upload.  If we're in reasonable shape with the images we're smoke testing now, and a review of the dependencies doesn't reveal any surprises, we'll try to pull it in.  Otherwise we should be considering it as an SRU candidate.   Please also update the bug to reflect the importance, and milestone target.
<charlie-tca> Ubuntu 386 desktop has the progress data at the bottom of the install, 64bit does not in hardwarew
<ubot4> Ubuntu bug 386 in baz "change to removed files does not conflict" [Medium,Confirmed] https://launchpad.net/bugs/386
<kees> skaet: thanks, uploaded
<charlie-tca> ooops, eyes are getting tired. They both have the same progress reports
<skaet> charlie-tca,  :)
<charlie-tca> easier to see when I do them side-by-side
<ScottK> Unseeded Universe packages are still open, so no release review of the cyrus-sasl2-heimdal  package should have been needed.
<ScottK> kees: I don't like the hard coding.  Please have a look early in oneiric to put it back.
<skaet> Edubuntu dvd i386, amd64 posted
<skaet> kubuntu mobile i386 posted
<skaet> ubuntu netbook omap3 + omap4 posted
<skaet> GrueMaster, ogra_ ^^ fyi.
 * skaet --> calls it a night
<kees> ScottK: in oneiric it'll be totally dropped because cyrus-sasl2 merged heimdal finally
<kees> but for natty we ended up with a -heimdal newer than the base, so i had to hardcode the versions
<ScottK> kees: Great news.  Thanks.
<kees> np
<ScottK> Right, that's why I accepted it, just wanted to make sure the longer term got dealt with.
<slangasek> kees: cyrus-sasl2 merged heimdal, yes, but we haven't merged that version of cyrus-sasl2 into Ubuntu... I skipped over it because it would pull heimdal into main
<slangasek> is that the way we want to go?
<kees> slangasek: i'm not excited about it for oneiric, but this solves it for natty at least (still in universe)
<kees> slangasek: I assume we'll just keep the binaries in universe or something
<pitti> lamont: 8002> ah, good to know; it worked for some builders, but I think these just timed out
<ScottL> skaet, the qa iso release was a little surprising to me, did i misread natty schedule?
<ScottL> skaet, oops, nevermind, i see the r"elease image built" listing
<skaet> ScottL, if you've got questions about the plans for the next week, feel free to join us in #u-meeting,  as we do a last round table.
<skaet> :)
<robbiew> ScottK: sorry...so which bugs are you talking about?  the 2 listed on http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all ?
<ScottK> bug 557261
<ScottK> bug 656486
<ubot4> Launchpad bug 557261 in casper (Ubuntu) "The session live persistent with USB don't start, error in the prompt initramfs (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/557261
<ubot4> Launchpad bug 656486 in xserver-xorg-video-ati (Ubuntu Natty) (and 3 other projects) "error de Video - [DRM: radeon_ttm_backend_bind] * * ERROR no pudo enlazar 1.772 pÃ¡ginas (affects: 7) (dups: 1) (heat: 37)" [Medium,Confirmed] https://launchpad.net/bugs/656486
<ScottK> robbiew: Kubuntu images are marked failed by QA due to those, but they aren't Kubuntu specific, so I think foundations needs to assess if they are important enough to fix or can be release noted and dealt with later.
<robbiew> ScottK...ack
<robbiew> thnx
<robbiew> they can both be release noted, imo
<ScottK> Up to you.
 * ScottK just doesn't want them hanging on Kubuntu specifically.
<stgraber> skaet: Because of bug 695590 which won't be fixed for natty, we'll remove gally from Edubuntu. I'll be updating the seeds and meta soon. I'm just checking with highvoltage that we don't mention it anywhere on our website, documentation, screenshots, slideshow.
<ubot4> Launchpad bug 695590 in python-kde4 (Ubuntu) "pykdeuic4's processUi() calls compileUi() with 3 args instead of the 4 required by PyQt4.uic.Compiler.compiler (affects: 10) (dups: 8) (heat: 82)" [Medium,Triaged] https://launchpad.net/bugs/695590
<jibel> ScottK, robbiew looking at this bug it seems to be a kernel oops and hw specific. not related to kubuntu in any way.
<slangasek> ScottK, robbiew: what was this about failed images?  Is that http://iso.qa.ubuntu.com/qatracker/result/5544/51 ?
<skaet> stgraber,   thanks for letting me know.
<ScottK> slangasek: Yes.
<robbiew> slangasek: yeah...nothing to worry about, imo
<slangasek> agreed, seems these bugs are nothing new
<GrueMaster> Ok, I have narrowed down the oem-config issue on the headless images to between 2.6.5 & 2.6.6 release.  I believe it may be related to commit 4701 as that is the only one that looks like it touches the crash site.  Will remove this commit & see.
<maco> skaet: is it too late for a11y patches to ubiquity for some of the stuff jibel's noticing?
<maco> should i just send them to vinux?)
<robbiew> too late
<skaet> maco,  yeah,  best plan now is for them to be 0-day/SRU fixes - are there patches ready?  or still to be created?
<ScottK> slangasek: Agreed.  I was reacting to the QA report about failed images in the release meeting.  I didn't have a chance to review it.
 * slangasek nods
<maco> skaet: i have one that's sorta halfway-there, was going to attack it with accerciser tonight.  but can ubiquity bugs be SRU'd?
<ScottK> maco: I believe if you have internet access during the install it will update.
<slangasek> they can be, but it's less effective for non-LTS releases (but what ScottK said)
<maco> ok
<ScottK> Even though Universe unseeded isn't frozen left, I'd like to start leaving a Universe package in queue in case we need a publisher run.
<GrueMaster> So, do we have someone that can fix ubiquity, specifically oem-config?  I have it working by reverting revision 4701, but I am not familiar enough with the code to get a true fix for it.
<stgraber> ^ is the removal of gally discussed before. Would be great to have this one approved soon so I can rebuild weblive and work on upgrade testing + have it on the next daily.
<stgraber> thanks
<ScottK> stgraber: No problem to accept it.  Why are you removing gally?
<GrueMaster> skaet: Bug #769081 is release critical for ubuntu-headless-preinstalled-armel.  Marked it as high as I don't know if it affects other arches.
<ubot4> Launchpad bug 769081 in ubiquity (Ubuntu) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/769081
<ScottK> (We have a candidate kdebindings patch that should make it buildable that we'll likely get in as a 0 day SRU)
<stgraber> ScottK: maco asked us to remove it
<skaet> GrueMaster,  ok.   Will work with slangasek and robbiew to see if we can come up with options.
<ScottK> stgraber: Excellent reason then.
<maco> ScottK: until the rebuild happens, it wont even start up
<ScottK> So we'd need to get the bindings fix into -release.
<maco> and i dont think itd look good to have something crashing on the live cd
<ScottK> Agreed.
<ScottK> It's unfortunate, but I think that's the best solution.
<skaet> GrueMaster,  by other arches, armel ones,  or oem-config on other i386, etc.?
<GrueMaster> oem-config on other platforms.  This doesn't appear to be armel specific.
<GrueMaster> But it doesn't affect the netbook image.
<GrueMaster> It may be visible in alternative image installs.
<slangasek> I think you need cjwatson or ev for that (769081)
<ScottK> I targetted/milestoned it for 11.04.
<skaet> jibel,  ^^  can you see if you can get quick confirmation on the other archs if this is a problem?
<ScottK> stgraber: Accepted.
<stgraber> I can have a look at bug 769081 if cjwatson and ev aren't around, so we can have a fix by Monday
<ubot4> Launchpad bug 769081 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/769081
<stgraber> ScottK: thanks
<skaet> stgraber,  that would be awesome!  Thanks!
 * GrueMaster puts head back on and goes to test netbook.
<ScottK> skaet: The other uploads I thought ought to perhaps go in today are desktop-file-utils, svgalib, and ubuntu-docs (this is our other after the release meeting conversation).
<ScottK> slangasek: Could you take a glance at svgalib.  My non-C programmer brain suspects that's either obviously correct or obviously wrong to someone who knows C.
<skaet> ScottK,  agree on the ubuntu-docs, and have scanned it earlier today.
<ScottK> OK.  I'll accept that one then.
<ScottK> Done
<slangasek> ScottK: hmm, but the diff is to debian/rules? :)
<ScottK> Oh, I was thinking of a different one.  Sorry.
<ScottK> slangasek: Now that you've looked, what do you think?
<slangasek> it's an imperfect fix; if chmod (somehow) fails to set the perms on a file, the error is ignored
<slangasek> but that's pretty low risk
<ScottK> If you think it should go in, now's the time.
<slangasek> also pretty low gain, it only helps getting the package built on !x86 where it's also not particularly useful... but it's in universe... so pushing
<ScottK> skaet: I've looked at desktop-file-utils and it's not an RC kind of issue, but it's low risk, so I'd say go ahead (the discussion in the bug has resolved my concerns about it).
<skaet> ScottK,  right now confirming whether or not the langpacks did already get picked up.
<skaet> If they did, we may not respin.
<ScottK> Well you'll need to respin for docs anyway.
<ScottK> Plus I expect we'll have to fix Ubiquity for GrueMaster's bug.
<GrueMaster> Unfortunately, yes.  We have no way of updating this without a respin.
<skaet> ScottK,  GrueMaster, depends on the scope,  but yes,  the docs should go in and be ready.
<ScottK> It sounds like this is a fix it or don't release the headless images kind of situation.
<GrueMaster> exactly.
<skaet> if you and slangasek are comfortable with svgalib, I won't fuss.
<ScottK> skaet: The docs update that was in queue is in.
<skaet> ScottK, yeah, just saw that in the backscroll,  svgalib too.
<skaet> ScottK,  can I ask you to hold off on the desktop-file-utils though until I study it a bit.
<ScottK> So I think it's safe to say we're in for a respin independent of the language packs.
<skaet> ScottK, agree its likely, for some images at any rate, but scope of respinning will depend on what else is found.   (and langpacks).
<skaet> Edubuntu needs it
<skaet> and some of the arm images (at a minimum).
<ScottK> Plus the desktop images for the docs update.
 * skaet nods
<skaet> although the docs could be 0-day updates.
<ScottK> Docs are already in.
<ScottK> So it's a bit late for that.
 * skaet nods 
<slangasek> I apparently have the wrong branch of ubiquity checked out here; fixing that so I can see better what's going on with 769081
<slangasek> stgraber: you commented "fix by Monday" - does that mean you're not comfortable tackling it yourself today?
 * skaet -> lunch,  biab
<stgraber> slangasek: If I look at it, it's going to be later this afternoon (on the bus back to Sherbrooke) or tonight. So if someone knows how to fix it and has time to do it before then, go ahead.
 * stgraber lunch, back later
<slangasek> stgraber: no clue how to fix it; maybe that will change, we'll see
<stgraber> oops, that was meant for a /away :) anyway, talk to you later
 * slangasek waves
<slangasek> stgraber: yeah, I don't know my way around this code at all, I can't even figure out what self.ui is here
<slangasek> rather, I can see that it's a "PageDebconf", but not how that's supposed to work with any of the *other* stuff (like set_timezone())
<maco> slangasek: know where the "import debconf" pulls from?
<maco> nvm found /usr/lib/python2.6/dist-packages/debconf.py
<GrueMaster> Actually, self.ui.controller is defined in PageGTK (which we don't use in PageDebconf further down.
<maco> i dont see PageGTK in ubi-timezone.py
<slangasek> yes, I don't see where PageDebconf is supposed to inherit from /anything/ else... so is it also broken when trying to call self.ui.set_timezone, self.ui.set_timezone ?
<slangasek> maco: PageGtk
<maco> slangasek: i think PageDebconf inherits from plugins.PluginUI
<maco> class PageDebconf(plugin.PluginUI):
<slangasek> that's what the code says, yes
 * GrueMaster loves well documented code.
<slangasek> so either there are more latent bugs wrt self.ui, or I'm failing to understand the inheritance here
<maco> cant find plugins.PluginUI though. lots of things inheriting from it...not finding its definition though
<slangasek> plugins.PluginUI is a directory up in plugins.py
<GrueMaster> Well, when I change line 597-598 in ubi-timezone to only "i18n.reset_locale(self.frontend, just_country=True)", it works, so the other self.ui calls should be ok.
<slangasek> I think the other self.ui calls are just not being hit in the current code path
<slangasek> and they probably break oem-config under other circumstances
<maco> every other use of controller uses self.controller, not self.ui.controller
<maco> oh wait... ubi-language has 4 uses of it with ui, and usersetup has 1
<maco> related maybe?
<GrueMaster> I just noticed that PageGTK & PageKDE are very similar in definition, but PageDebconf is almost non-existent.  I wonder if it just needs to be defined.
<slangasek> given that we're all speculating, I'd say no solution we come up with should be pushed to the archive before review by someone who has an actual handle on ubiquity code
<cjwatson> I'm not really here, not enough to write a patch, but I can do patch review with some delay on request
<slangasek> ah, ok :)
<cjwatson> I agree this is delicate
<cjwatson> hm, thinking about it
<cjwatson> the set_timezone/get_timezone stuff probably isn't a problem, because the oem-config debconf frontend doesn't have enough UI to hit it
<cjwatson> but cleanup is called rather less conditionally
<cjwatson> so try http://paste.ubuntu.com/597539/ ?
<slangasek> GrueMaster: ^^ can you hot patch oem-config and give that a try?
<GrueMaster> Will do.
<cjwatson> maco: the ui element of a Page is a Page<Frontend>
<cjwatson> so in Page you'll find self.ui.controller.blah, but in PageGtk etc. you'll find self.controller.blah
<cjwatson> (I blame mterry)
 * slangasek throws a mixin
<cjwatson> yeah, run and ok_handler only get called in frontends that do debconf filtering, which the debconf frontend doesn't
<cjwatson> (too many things called debconf, sorry)
<cjwatson> so set_timezone/get_timezone aren't issues
<slangasek> ok, cool
<cjwatson> unless somebody rearranged everything some more while I wasn't looking
<GrueMaster> Give me ~15 minutes to get results.  Have to reflash then edit before execute.
<cjwatson> I'm off for dinner
<cjwatson> I'll look in later and can upload if it works
<skaet> ScottK,  could you look into:  kubuntu/daily-live: natty-desktop-amd64.iso oversized by 1269760 bytes (735272960)
<GrueMaster> cjwatson: Looks good!
<GrueMaster> Colors on oem-config are still wonky in screen, but it is during package removal so I'm not going to complain.  That can be resolved in Oneiric.
<GrueMaster> bug 769081 updated & patch attached.
<ubot4> Launchpad bug 769081 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 10)" [High,In progress] https://launchpad.net/bugs/769081
 * GrueMaster takes a small break.
<ScottK> skaet: Yes.
<ScottK> skaet: I just pushed the seed change.  IIRC it takes two publisher runs before you can rebuild the image.  I took advantage of the moment to add some language packs to the powerpc image since it's substantially under the size limit.
<ScottK> I'm going at accept fgrlx-installer to make sure the publisher runs.  We'll need a Kubuntu DVD respin anyway since I changed the seeds.
<skaet> ScottK,  have also accepted the desktop-file-utils,  agree with your assessment, and since we'll be respinning, it may as well be in.
<ScottK> skaet: I noticed LibreOffice is still building so any relevant armel images (probably just Kubuntu) will need a respin for that at some point.
<skaet> ScottK,  ok
<cjwatson> GrueMaster: cool, will deal with an upload shortly then
<jibel> skaet, I do not reproduce the oem-config-debconf crash on i386 and amd64 if that was your question. Are there specific steps to follow ?
<cjwatson> jibel: I think we've moved on from that now :)
<jibel> thanks :)
<ScottK> cjwatson: I fiddled the Kubuntu seeds a little bit ago to fix oversize on live amd64 (and I bumped live powerpc up on langpacks since it had a lot of room).  Is there time that it would be worth a test respin of those images now before the respin we'll need anyway for your Ubiquity fix?  The publisher run that just started would be the second one since the see change (I don't recall if the two publisher runs counts to when the second run
<ScottK> starts or when it finishes).
<Daviey> o/ There are two libcgroup in natty unapproved queue.  I uploaded twice when dput seemed to fail.  Seems to be a false error returned (https://answers.launchpad.net/launchpad/+question/152715).  Apologies.
<cjwatson> uploading ubiquity now; there's a slight discrepancy in tzsetup common.templates between 2.6.9 and 2.6.10, which I think is due to ev uploading from a built tree and tzsetup being a bit out of date with respect to tzdata.  I chose to leave this as it was rather than trying to do build system judo on a holiday; it shouldn't make much difference
<cjwatson> ScottK: somebody else is worrying about respins at the moment, I hope - I'm just here very briefly
<ScottK> skaet: The only seeded package pointed at -release now is Ubiquity.  Once there's a diff available I'll have a look at it.
<ScottK> cjwatson: skaet: Ubiquity accepted.
<ScottK> skaet: I gave an OK on #ubuntu-devel for some additional docs updates if they can be uploaded quickly (since we arleady are in respin territory).
<cjwatson> thanks
<ScottK> I'm glad you warned me about the timezone skew.
<cjwatson> it's a lot easier to read in wdiff than diff -u
<stgraber> cjwatson: Hi, any idea of what's the right way to fix bug 759545 for good ?
<ubot4> Launchpad bug 759545 in grub2 (Ubuntu Natty) (and 1 other project) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/759545
<ScottK> stgraber: I think that was fixed a few days ago.
<Daviey> I'm not sure it was... smoser commented on it to me last night.
<cjwatson> stgraber: I'm going to look at it with my Debian hat on post-natty, by rewriting all the ucf handling
<Daviey> Ah, might be a differing bug
<cjwatson> stgraber: it's not fixable for natty in a safe way now, IMO
<smoser> its not grub's fault.
<cjwatson> it sort of is, ish
<smoser> its my fault. and i think we have to live with it.
<cjwatson> I mean there are elements that are the fault of grub's packaging
<cjwatson> but as I say
<smoser> outside of adding "if this looks like a grub/default file that smoser screwed with, then be nice"
<cjwatson> the fundamental problem is that we're applying ucf to /etc/default/grub *after* applying debconf answers to it, which is wrong
<stgraber> cjwatson: ok, so we're fine having every upgrade prompting for /etc/default/grub ?
<smoser> which is, somewhat what I am proposing at bug 768625 (for sudo). I'd like someone to take a look at that.
<ubot4> Launchpad bug 768625 in sudo (Ubuntu) "user prompted for sudo changes on upgrade in ec2/uec image (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/768625
<cjwatson> (or else we need to keep copies around of all the old versions of /etc/default/grub so that we can patch them in the same way)
<cjwatson> stgraber: I'm not *fine* with it, but further attempts to fix it are too risky
<cjwatson> that code is insane and best not touched in a rush
<smoser> i would greatly appreciate it if someone could (offline from here) look at that sudo bug. it seems to me to be straight forward.
<stgraber> cjwatson: agreed. Do we want that targeted to natty -updates or should we skip Natty completely and just fix it for Oneiric ?
<cjwatson> oneiric
<cjwatson> it'll be too substantial for an SRU, IMO
<cjwatson> fwiw, it's not (at root) a new bug - we've had it in one form or another since we switched to grub2
<slangasek> I'm very sad that we still have such problems with grub2
<slangasek> is the fix not as simple as redirecting the debconf edits to whichever file ucf will use as input?
<slangasek> (this is how samba does it; it's not perfect, but it's pretty good)
<slangasek> and I realize the answer may well be a simple "no, it's not that simple" :)
<micahg> I have a few more security uploads but could hold off until sat night, should I leave the builders free?
<cjwatson> slangasek: that might end up being the answer, yes
<cjwatson> slangasek: this is pretty much the one bit of grub2 that I have so far steered clear of touching, because I hate config file mangling code; I expect I'll just have to hold my nose
<cjwatson> slangasek: how does samba deal with telling ucf the right set of md5sums, though?
<cjwatson> this file has changed maybe five times in two years, keeping the list of md5sums isn't onerous, but I can only do that for the file before the debconf edits
<slangasek> cjwatson: it never gives ucf md5sums, it always does 'ucf --three-way --debconf-ok "$NEWFILE" "$CONFIG"' where "$NEWFILE" is the file populated with the debconf answers
<slangasek> there was some transition code to handle the migration to this from pre-ucf versions, using the md5sums of the stock files from various Debian and Ubuntu releases; that's been dropped from the maintainer script now as obsolete, but I could dig it up
<slangasek> hmm, not the md5sums actually - bundled copies of the old default config files
<cjwatson> perhaps that's the answer, then
<cjwatson> I wouldn't mind looking at this with you at UDS, if we have time and I haven't fixed it by then already :)
<slangasek> sounds good :)
<ScottK> micahg: We're good on everything but powerpc,  I might be nice to let it catch up.
<micahg> ScottK: k, I'll hold off till sat night, will you be around this weekend?
<ScottK> I'll be gone most of the day tomorrow, but generally.
<micahg> ScottK: cool, might need a release ack on sunday, not sure yet
<ScottK> micahg: Shouldn't take that long to catch up, you can just monitor https://launchpad.net/builders
<ScottK> Universe is still open for bugfix uploads, so just keep them coming.
<micahg> ScottK: well, it's minitube, so might have new features, but idk if I have time for it
<ScottK> OK.
<ScottK> I'll be checking bugmail every now and then even during the day.
<micahg> cool, tuesday at noon UTC is the cutoff for universe?
<ScottK> IIRC, yes.
<ScottK> skaet: Everything that was pending is built and published and i386 and amd64.  All except LibrOffice is done on armel (which IIRC only affects the Kubuntu image).  powerpc has a ways to go.
<ScottK> So, modulo language pack exports, this is a good time for respins.
#ubuntu-release 2011-04-23
<ScottK> slangasek: If you're around, would you please trigger respins on Kubuntu desktop and alternate i386 and amd64 and kubuntu-mobile live on i386 and armel?
<ScottK> They ~all need doing, but I'm comfortable asking for those.
<GrueMaster> May as well add ubuntu netbook & headless to the mix.  I haven't found any other glaring issues on either that can't be SRU fixed at this point (aside from bug 769081 which is now fixed).
<ubot4> Launchpad bug 769081 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/769081
<slangasek> ScottK: scheduled
<slangasek> GrueMaster: not scheduled yet because I failed to notice your follow-up before hitting enter; I'll revisit after dinner
<skaet> slangasek, GrueMaster - have started headless and netbook
<stgraber> skaet: are we going to get an automatic daily build for both edubuntu dvds tonight or do we need to explicitly request that ?
<slangasek> stgraber: no automatic builds
<skaet> stgraber,  what slangasek said.
<stgraber> ok, cool. Can we get Edubuntu DVD rebuilt then ?
<stgraber> so we pick up the edubuntu-meta change that happened earlier today ?
<skaet> slangasek,  ScottK - kubuntu alternate (i386, amd64, amd64+mac) is posted.
<skaet> stgraber,  if slangasek hasn't started it already,  I'll kick it off.
<slangasek> I haven't started it
<skaet> slangasek,  which ones did you start?
<stgraber> skaet: great, thanks! I'll have it tested tomorrow. Hopefully everything should be fine at this stage but if it isn't, I'll have the remaining of the weekend to fix it :)
<slangasek> skaet: only the ones ScottK mentioned above
<slangasek> kubuntu desktop, alternate, mobile
<skaet> ok,  as soon as I see those finish off,  I'll queue up edubuntu and then the ubuntu desktop, alternate, dvd
<ScottK> skaet: Did you respin mythbuntu and ubuntustudio yet?
<ScottK> There's a FTBFS fix in queue that hits those images.  Might be nice to get it in if you didn't.
<skaet> ScottK,  no haven't spun mythbuntu, ubuntustudio,  go ahead.
<ScottK> OK  Done.
<ScottK> Also confirmed that the kubuntu oversize problem on amd64 is fixed.
<skaet> ScottK,  kubuntu desktop (i386, amd64, amd64+mac),  kubuntu-mobile (i386) posted
<ScottK> Yep.  I've pinged for testers.
<skaet> coolio. will post the rest as they emerge, either later tonight or tomorrow morning.  Will be around off/on for next couple of hours.
<ScottK> libquicktime unfortunately failed on amd64.  I've pinged the uploader.
<ScottK> slangasek: If you're around and have a moment to look at libquicktime, I'd appreciate it.
<skaet> ubuntu-headless (omap, ompa4) posted
<skaet> GrueMaster, ^^
<ScottK> lamont: On the off chance you are around, this isn't a particularly great time for a dead powerpc buildd ...
<ScottK> skaet: I think we're good for powerpc respins the the "main" flavors (Ubuntu/Kubuntu/Server).
<skaet> ScottK,  Ubuntu desktop just came off the builders, and has picked up powerpc, so fingers crossed.
<skaet> stgraber, edubuntu i386, amd64 dvd - posted on the tester.
<ScottK> I'd check what Ubiquity version is has.  If that's current, it should be fine.
 * skaet checking
<ScottK> skaet: FYI, my Kubuntu testing did not go well.  Two failed installs of three.  I think ev will have some work to do on Monday/Tuesday (not sure when he's around). http://iso.qa.ubuntu.com/qatracker/test/5578
 * ScottK is off to bed.
<skaet> ScottK,  thanks for flagging.  Sleep well.
<skaet> ubuntu desktop (i386, amd64, amd64+mac, powerpc) posted.
<ScottK> skaet: Ubunt powerpc is oversized.
<ScottK> It did get the right Ubiquity though.
<ScottK> OK, now off to bed.
<skaet> :)
 * skaet figures its time to head to bed as well...
<skaet> Images still building are ubuntu dvd, kubuntu dvd, ubuntu alternate, xubuntu alternate, ubuntu-server, ubuntu studio, ubuntu-netbook, kubuntu-mobile armel,  kubuntu armel...
<skaet> If someone sees they're finished and is able, feel free to post to iso tracker.
<jibel> xubuntu alternate, ubuntu server/netbook armel/alternate/dvd, kubuntu mobile armel and dvd, mythbuntu, ubuntustudio posted to the tracker.
<jibel> netboot is from 20110421, is it the version to post or there's a new build planned  ?
<cjwatson> jibel: that's the right netboot version
<iulian> Morning.
<iulian> Have you guys spun mythbuntu yet?
<iulian> Oh, and ubuntustudio.
<iulian> If we haven't, it might be worth to let libquicktime in.
<iulian> It fixes https://launchpadlibrarian.net/70221224/buildlog_ubuntu-natty-amd64.libquicktime_2%3A1.1.5-1ubuntu2_FAILEDTOBUILD.txt.gz.
<iulian> Hmm, it seems that ScottK already has it on his radar.  I will leave it to him to decide then.
<bdrung_> i am not the only one who want's lintian rc3 in natty (bug #769101)
<ubot4> Launchpad bug 769101 in lintian (Ubuntu) "[FFe] Please merge lintian 2.5.0~rc3 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/769101
<ScottK> skaet: I don't know where we are on images, but libquicktime should get in to fix the FTBFS on amd64 so we don't release with it out of date on one arch.  It only hits mythbuntu and ubuntustudio.  My recommendation is accept it and respin those.  I'll be offline most of today, but will be around late tonight.
<ScottK> lamont: reping over the dead powerpc builder.  It's kind of got us on hold at the moment.
<ScottK> (security is waiting for it to drain before they start pushing security uploads)
<skaet> thanks for doing the posting jibel :)
<skaet> ScottK,  in terms of images,  we're waiting for pitti to find out what is happening with the language packs.   If the scope of impact of libquicktime is mythbuntu and ubuntustudio, and those projects want it it,  I'm ok with it going in, if it lands before the language packs do.
<skaet> I'm going to be traveling for the rest of today,  and will be back on line at some point tomorrow when I'll be in the london.
<cjwatson> ScottK: both powerpc builders seem alive now ...
<cjwatson> we have sync requests open for bzr-builddeb and ubuntu-dev-tools.  Will they fit, or should they be pushed to oneiric?
<cjwatson> the former fixes a couple of regressions; less sure about the latter
 * cjwatson notes language packs pouring through
<iulian> cjwatson: Can you point me to the bug reports please?
<cjwatson> iulian: bug 768659, bug 769471
<ubot4> Launchpad bug 768659 in bzr-builddeb (Ubuntu) "Sync bzr-builddeb 2.7.3 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,Confirmed] https://launchpad.net/bugs/768659
<ubot4> Launchpad bug 769471 in ubuntu-dev-tools (Ubuntu) "Please sync ubuntu-dev-tools 0.122 (universe) from Debian unstable (main). (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/769471
<iulian> Ta.
 * iulian looks.
<cjwatson> I'm more concerned about whether it'll cause CD build scheduling problems than whether they're reasonable updates.
<cjwatson> I'm accepting language packs in a loop, BTW
<iulian> Indeed.  If they don't cause any problems, I'd say that we should definitely get bzr-builddeb in.
<iulian> ubuntu-dev-tools too.
<cjwatson> OK.  They're both Architecture: all.  I suspect that the extra build time will be negligible on top of all the langpacks.
<cjwatson> about 8 and 9 minutes.
<iulian> They are both also small packages, so they shouldn't take more than a few minutes to build.
<iulian> Right.
<cjwatson> bzr-builddeb synced, but ubuntu-dev-tools is still in incoming.
<cjwatson> so that one may or may not make it.
<cjwatson> build queue on i386: 8 hours 40 minutes.
 * iulian nods.
<cjwatson> er, dear queuebot, get a clue
<cjwatson> sorry about that
<iulian> Heh. I believe the poor guy, he must've been tired. :)
<lamont> cjwatson: would more i386 archive builders be helpful?  (at the expense of one or 2 amd64 archive builders...)
 * lamont stuffs allspice over
<lamont> that should help a little
 * highvoltage starts upgrade tests for Edubuntu i386/amd64
<cjwatson> lamont: yep, thanks
<cjwatson> lamont: it seems to be taking rather longer than the estimates anyway; do the chroots need to be refreshed?
<cjwatson> it's definitely doing a fair amount of upgrade work
<cjwatson> e.g. https://launchpadlibrarian.net/70251218/buildlog_ubuntu-natty-i386.language-pack-de-base_1%3A11.04%2B20110421_BUILDING.txt.gz
<lamont> cjwatson: would you like fresh ones?
<lamont> wow/
 * lamont rolls em
<lamont> cjwatson: do you remember what livecd rootfs build times are these days for i386/amd64?
<lamont> cjwatson: uploaded, I'll stick around to see them work
<lamont> cjwatson: they seem fine, feel free to tag me SMS or VoIP if there are issues - I'll be around (though afk) for probably the next 2.5-3 hours before I head off to dinner with my wife)
<lamont> Build needed 00:00:04, 2156k disk space
<lamont> heh
<lamont> I also pushed the "go faster" button where it was available. and I'll file a ticket to make that more permanent
<stgraber> Edubuntu looks good (both 32bit and 64bit), only bug I found is missing Chinese support due to broken regexp in our seed. For this cycle I just manually added them to the seed so they'll be there in the next build.
#ubuntu-release 2011-04-24
<micahg> is there a reason the en langpacks didn't get updated with the rest?
<micahg> bug 769759, I don't think it's serious enough to upload to natty before release since Firefox won't be updated, but I'd like to get the new version generated so I can push it out through -security with Firefox 4.0.1 if that's ok
<ubot4> Launchpad bug 769759 in language-pack-en-base (Ubuntu) "Firefox langpacks won't work with 4.0.x (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/769759
<ScottK> doko_: How bad do we need this gcc-snapshot update in and what's the risk it'll make something worse?  It's a ~3 day build on armel, so I'm a bit nervous about it.
<cjwatson> feel++ has been building on armel for a day.  Is it stuck?
<cjwatson> or is it just slow arm C++ compiler is slow?
<elmo> buildd   16867  7.9 72.9 963692 349012 ?       D    12:53  16:11      |                                   \_ /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.5.2/cc1plus -quiet -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -I/usr/include/libxml2 -I/build/buildd/feel++-0.90.0/contrib/eigen -I/usr/include/metis -I/usr/include/openturns -I/usr/include/python2.7 -I/usr/include/octave -I/build/buildd/feel++-0.90.0/obj-arm-linux-gnueabi -I/bui
<elmo> (the latter)
<cjwatson> hate C++
<cjwatson> (thanks)
<micahg> cjwatson: do you know about langpacks?  it seems the en ones weren't regenerated before release
<cjwatson> I don't, they're pitti/dpm's territory
<micahg> cjwatson: k, thanks
 * stgraber looks at bug 768469
<ubot4> Launchpad bug 768469 in software-properties (Ubuntu) (and 1 other project) "duplicate entries in the updates section with python-apt-common 0.7.100.3ubuntu5 upgrade (affects: 18) (dups: 3) (heat: 114)" [Undecided,Confirmed] https://launchpad.net/bugs/768469
<stgraber> seems to be related to my latest python-apt fix (dealing with -src lines properly so our ARM builds have a proper sources.list). It seems like it might be an issue in software-properties (not filtering to only get binary entries) instead of python-apt this time though.
<stgraber> ok, I found the issue and I have a fix. I'm just triple-checking with a clean Maverick install to make sure the behaviour after the fix is 100% identical. (as I found what I think was another bug but might very well be how it worked on Maverick ...)
<debfx> stgraber: the python-apt uploaded also causes bug #768363
<ubot4> Launchpad bug 768363 in software-properties (Ubuntu) (and 1 other project) "Not able to change software origins in software-properties-kde - TypeError: coercing to Unicode: need string or buffer, NoneType found (affects: 14) (dups: 1) (heat: 88)" [High,Confirmed] https://launchpad.net/bugs/768363
<stgraber> debfx: ok, this one seems to be a python-apt issue (missing _Description)
<stgraber> debfx: Is http://paste.ubuntu.com/598348/ fixing the kde issue by any chance ?
<debfx> stgraber: yes, seems to work fine
<stgraber> ok, so hiding the -src entries seems to fix both the gtk and the kde issue and reverts to Maverick's behavior
<stgraber> uploaded new python-apt. Finishing testing software-properties now, should be uploaded as soon as I'm sure it has the exact same behavior as in maverick.
<stgraber> and software-properties is uploading just now
<cjwatson> stgraber: your python-apt upload removes data/templates/Ubuntu.mirrors?
<cjwatson> (I'm used to some changes there, but not to the whole thing being removed)
<stgraber> hmm, it shouldn't have ... /me looks
<stgraber> cjwatson: http://paste.ubuntu.com/598389/ that's what I pushed in the branch ... looking at what went wrong in the source package now
<stgraber> oh, unless whatever generates .mirrors doesn't work on my laptop ... checking
<cjwatson> if you want to synthesise it and just copy the one in from the previous source package, that's good by me
<cjwatson> (if it doesn't work otherwise)
<stgraber> ok, found the issue, you need python-feedparser to generate a valid source package ... it's in universe so that's probably why it's not in build-dep ...
<cjwatson> stgraber: also it's "maintainer-depends" rather than build-depends ...
<ScottK> Sounds like something that ought to be promoted.
<stgraber> cjwatson: can you reject the current python-apt ? I'm uploading a new one now
<cjwatson> stgraber: rejected
<cjwatson> stgraber: thanks
<stgraber> no problem, hopefully that was the last python-apt related issue this cycle ...
<ScottK> I guess I didn't need to worry about how long it would take for gcc-snapshot to build.  Depwait on all archs.
#ubuntu-release 2012-04-16
<cjwatson> Searching.  (It takes a little while since it has to download all the build logs.)
<cjwatson> Bet it's faster than you clicking through all of them, though. :-)
<micahg> yes, thanks
<cjwatson> Were you build-testing them as well, or just throwing them back against the wall?
<slangasek> so what do people think of a sudo upload for bug #982684 and bug #979319?
<ubot2> Launchpad bug 982684 in sudo "sudo doesn't apply global environment settings from /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/982684
<ubot2> Launchpad bug 979319 in sudo "[FFe] sudo do not remember password when std(in|out|err) are not connected to a terminal" [Low,Triaged] https://launchpad.net/bugs/979319
<micahg> cjwatson: test building one arch first
<cjwatson> OK, I'll not bother :)
<cjwatson> If they fail, at least the new reason will be visible to all
<micahg> buildds are empty enough
<cjwatson> micahg: done  gconjugue gshutdown gtkmm-utils gxine lasso luakit medit monkey-bubble mrtrix mrwtoppm netams ofono olpc-kbdshim opensync pan pinot psimedia ruby-gnome2 sagasu scenic sigx strongswan tomoe  so far
<cjwatson> script still seems to be running so I guess there might be some more
<cjwatson> but I'm off back to bed now, so if you have more, ask somebody else :)
<micahg> cjwatson: ok, thanks for your help
<cjwatson> oh, I think that's it, it had started on superseded ones (it's not very smart)
<infinity> cjwatson: Yeah, I noticed it had been committed after I asked.
<slangasek> oh bah, sudo doesn't call pam_getenvlist(); I guess I can't fix that one so easily
<infinity> By the way, no one copy eglibc to the release pocket until gcc-4.6 is also ready to go.
<slangasek> infinity: how's eglibc itself coming on armhf?
<slangasek> documented on the pad
<jbicha> ^ that fix took me a while to figure out
<micahg> cjwatson: when you get up, can you do a a search in the rebuild for 'libgtk2.0-dev : Depends: libgtk2.0-0 (= 2.24.10-0ubuntu6) but it is not going to be installed' and retry?
 * micahg regrets not killing sqlite2 for precise
<pitti> Good morning
<pitti> infinity: the apport workaround fully fixes the problem for apport
<pitti> infinity: the GTK+ patch was reviewed upstream, I'll commit it upstream and merge it into today's GTK .1 upload
<pitti> infinity: as we have similarly large dupe lists in software-center and other places; I'll reassign those bugs and dupe them
<pitti> infinity: mvo's patch seems fine
<pitti> infinity: sru-release -r does the -proposed -> release copying, it's in lp:ubuntu-archive-tools
<pitti> stgraber: yes, our CDs have plenty of space now that linux-firmware went on a 5 MB diet :)
 * pitti starts with the GNOME 3.4.1 packaging, see last Friday's release meeting
<pitti> ^ FTR, I used --no-lp for the sync, as I uploaded to Debian and Ubuntu at the same time
<pitti> anyone who could review my GNOME 3.4.1 -proposed uploads?
<slangasek> pitti: I don't feel like I'm in the loop on this - you say these uploads were approved at the release meeting?
<pitti> well, not in the sense of pre-reviewing the chhanges
<pitti> only that we'll land the gnome 3.4.1 bits today
<pitti> as it's being released today, and tarballs come in
<pitti> the .1 tarballs are traditionally on a tight schedule
<slangasek> yeah
<pitti> glib/gtk have bigger changes, as expected; the others should be mostly harmless
<pitti> e. g. gdk-pixbuf is rather simple (and has a nice security fix, too)
<pitti> self-rejecting glib2.0, need to check something
<didrocks> pitti: unity ready ^
<didrocks> pitti: and the compiz-plugins-extra rebuilds for c-p-m ABI break ^
<pitti> didrocks: cheers
<didrocks> pitti: thanks :-)
<didrocks> ok, now that the morning ping is ended, let's finish the week-end email backlog :)
<didrocks> ok with this fix: https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/979770 ? quite safe, tested by seb128 and I
<ubot2> Launchpad bug 979770 in compizconfig-backend-gconf "[regression] Precise: GNOME Classic starts without any compiz plugins loaded for Guest and new users" [High,In progress]
<seb128> didrocks, I continued running that over the w.e, I confirm it works ;-)
<didrocks> great! ;)
<pitti> seb128: if only we had a glib which would provide g_free(), g_strdup0(), and all that stuff..
<pitti> err, didrocks ^
<pitti> didrocks: LGTM
<didrocks> pitti: life would have been wonderful right? But such things can't exist! :)
<didrocks> pitti: uploaded! (more seriously as they wanted to be desktop agnostic, they didn't want to use glib even if it's widespread in kdeâ¦ but wellâ¦)
<seb128> didrocks, right, though it's cc-gconf and gconf uses glib :p
<didrocks> seb128: ironic, isn't it? ;)
<doko> pitti, I think it's time to remove zope2.12 and python2.6, could you do that?  bug 979923
<ubot2> Launchpad bug 979923 in xpyb "Python 2.6 and several virtual packages are still available in 12.04" [Undecided,Fix released] https://launchpad.net/bugs/979923
<pitti> \o/
<pitti> doko: hm, do we have a newer zope in precise/
<pitti> ?
<pitti> -- precise/universe i386 deps on zope2.12:
<pitti> zope-maildrophost
<pitti> zope-mysqlda
<pitti> zope-replacesupport
<pitti> I can't find zope2.13 or zope2.14
<pitti> doko: ah, the description says; I guess those three should be removed along then?
<doko> pitti, I don't understand ...
<pitti> doko: I mean, above three packages depend on zope2.14 | zope2.13 | zope2.12 | zope2.11 | zope2.10 | zope2.9 | zope2.8
<pitti> doko: but AFAICS we don't have any other zope version packaged, so shoudl I just remove these three rdepends, too?
<pitti> well, in fact we don't have the zope2.12 binary either, so they are uninstallable anyway
<pitti> doko: both removed, blacklisted, bug updated
<infinity> +* Excessive dependencies have been culled from Requires: lines
<infinity> +  in .pc files. Dependent modules may have to declare dependencies
<infinity> +  that there were getting 'for free' in the past.
<infinity> pitti: ^--- That's a scary change for a .1 ...
<doko> pitti, which rdepends are you talking about?
<doko> ahh, zope-*
<pitti> infinity: I think that's catching up with changes that we already have; the actual diff doesn't change the .pc
<doko> yes, I think so
<infinity> pitti: Kay, fair enough.
<pitti> doko: kidn of a false postiive; as zope2.12 never actually built, these were uninstallable already
<pitti> doko: but I guess we can still remove them, but not blacklist?
<infinity> pitti: Other bits of the upstream changelog don't instill confidence either (behaviour changes that "may affect applications doing [X]"), but I don't know GTK+ well enough to know if any of it matter to the real world.
<pitti> infinity: where do you read this?
<pitti> infinity: I don't see it in NEWS?
<infinity> pitti: README.
<infinity> +* GtkApplication no longer uses the gtk mainloop wrappers, so
<infinity> +  it is no longer possible to use gtk_main_quit() to stop it.
<infinity> +* GTK+ now uses <Primary> instead of <Control> in keyboard accelerators,
<infinity> +  for improved cross-platform handling. This should not affect
<infinity> +  applications, unless they parse or create these accelerator
<infinity> +  manually.
<pitti> infinity: ah, same thing -- that's catchign up with changes that were introduced way earlier
<infinity> Those two both look like "we don't think people do this anyway, so no big deal" gotchas that might explode other people's code. :P
<pitti> all those changes would indeed be qutie scary for a .1
<infinity> pitti: Ahh, alright.  Fair enough.
<Riddell> I'm going to upload 55 kde-l10n packages to import the translations into launchpad, ok to upload to precise?
<pitti> they don't have build skew, so no need for -proposed IMHO
<infinity> pitti: I hadn't gotten to auditing source yet, I just found the README in the sea of gettext poop. ;)
<pitti> infinity: so you started with the hardest package first :)
<pitti> infinity: (gdk-pixbuf and screensaver are trivial against that, for consolation)
<infinity> ;)
<infinity> gtk's probably not that bad, I just need to download the diff and pipe it through filterdiff.
<infinity> All the autogenerated crap makes it impossible to manage in a browser.
<pitti> infinity: oh, indeed; I usually use "queuediff", and look at it in vim
<pitti> much easier to jump around with /^---
<infinity> Yeah, I need a browser extension to allow some simple regexes (actually, just the ^ anchor would be enough) in firefox text searches.
<infinity> This seems like it would be trivial to write.  For someone who spoke XUL.  Which I don't.
<Riddell> potential spamming in process
<infinity> Ugh.
<infinity> stgraber: queuebot needs to learn to ignore kde-l10n-*
<Riddell> infinity: happy for me to accept these?
<infinity> Riddell: Already done.
<Riddell> lovely
<infinity> And now we'll get spammed again. :P
<Laney> kick the bot for a minute :P
<pitti> thanks infinity
<infinity> Hrm.  Won't this metacity change mean that people who have their terminal application set to something !gnome-terminal will get a different behaviour on C-A-t?
<infinity> Or does GNOME no longer let you set a preferred terminal? :P
<pitti> infinity: that too
<pitti> infinity: I also left a comment in the bug and in the pad that this breaks translations
<infinity> pitti: Rejected for now, and noted why in the bug.
<stgraber> infinity: now ignoring kde-l10n-*
 * infinity hugs queuebot.
<pitti> bonjour stgraber
<infinity> Dearest soyuz, where did you put my eglibc binaries?
<infinity> Finished 7 hours ago (took 5 hours, 12 minutes, 7.4 seconds) (on armhf)
<infinity>      libc6 | 2.15-0ubuntu7 |       precise | amd64, armel, armhf, i386, powerpc
<infinity> ^-- No armhf
<infinity>      libc6 | 2.15-0ubuntu9 | precise-proposed | amd64, armel, i386, powerpc
<infinity> WTF?
<pitti> hm, nothing in NEW
 * infinity goes to look at publisher logs...
<infinity> I bet http://launchpadlibrarian.net/102105469/3Ixhqwb17uQG7eDWJryLXayy4i.txt relates. :/
<pitti> o_O
<infinity> And it's killing the publisher.  \o/
 * infinity works on getting that fixed.
<infinity> Okay, publisher should be fixed, but at ~60s per kde-l10n queue entry, it'll take a while to run. :P
<stgraber> Hallo pitti
 * pitti applauds infinifixitall
<infinity> pitti: Oh, after this publisher run, there's a preeeeetty fair chance that britney will explode and tell you that armhf is a mess of uninstallable packages (and image builds will have the same issue).
<infinity> pitti: It'll all normalize once gcc-4.6/eglibc get copied.
<pitti> infinity: oh, more missing armhf binaries?
<pitti> I thought they were only missing in -proposed
<infinity> pitti: (Unfortunate side effect of having to seed the world with a bootstrap archive, so anything newly-built on armhf depends libc6 (>= 2.15-0ubuntu8), which isn't in the archive yet)
<pitti> ah
<pitti> I just won't look for the next couple of hours then :)
<infinity> 7 or 8 hours, probably, given that gcc-4.6 on armel has a way to go.
<infinity> But yeah, it'll sort itself.
<infinity> Not an issue for the buildd pipeline, since those packages ARE available there, at least. :P
<infinity> Holy crap, Rosetta, why are you such utter fail?
<infinity> *sigh*
<infinity> Seriously, a minute per kde-l10n-* binary.
<infinity> pitti: You still care deeply about all thing translation, right?  Maybe you should look at that some day. ;)
<pitti> in my CFT
<infinity> Ed Zachary.
<infinity> On the plus side, maybe gcc-4.6/armel will finish before the publisher does? :P
<apw> can someone remind me where release note tasks go ?
<knome> is the final release notes page somewhere to edit?
<pitti> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<pitti> you can copy https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2 and then edit
<pitti> (please don't edit /Beta2)
<pitti> infinity: FTR, giving allspice back to amd64
<infinity> pitti: Mmkay.
<infinity> pitti: Did ev file an MIR for syslinux-legacy (or are we just assuming that since syslinux is in main, it's okay to promote)?
<pitti> I'm not in the MIR team any more, but I'd say it's ok, as it's not really new code
<pitti> new gnome 3.4.1 tarballs coming in, fortunately mostly trivial (translation updates only)
<infinity> Oh, there's an MIR anyway.
 * infinity reads.
 * infinity promotes.
<pitti> ^ one .po file update only
 * pitti eeks at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<pitti> Daviey: ^ is that under way, or will it be unseeded again?
<infinity> pitti: Just don't look at britney output. ;)
<pitti> ^ one simple bug fix, translation updates
<Daviey> pitti: still targeted.. there should be open MIR's.
<Daviey> *suck*
<infinity> pitti: Just one po file, eh?
<infinity> pitti: Did you forget the part where the 3 previous releases aren't in the archive? ;)
<pitti> infinity: err?
<seb128> infinity, did you forget the part where the queue diff stuff is buggy? ;-)
<pitti> I diffed locally
<pitti> there's autoconf noise, of course
<pitti> infinity: are you looking at http://launchpadlibrarian.net/102164255/gnome-desktop3_3.4.0-0ubuntu1_3.4.1-0ubuntu1.diff.gz ?
<Laney> it is using the last proposed upload
<infinity> Ahh.  Special.
<seb128> that's a bit buggy,stupid
<seb128> it's picking the wrong version as Laney said
<pitti> that indeed looks sad
<seb128> it did the same on friday with gnome-control-center and some others
 * infinity downloads and diffs manually.
<pitti> yay for having good tools
<seb128> dget && debdiff for the win ;-)
 * infinity nods.
<pitti> still, there's something wrong if it's harder to check a package than to package it in the first place :)
<infinity> That flashplugin-nonfree upload is just version/hash bumps to match the partner upload.
<pitti> argh, stuff fails on arm* now because gtk+3.0 arm{el,hf} is not published yet; I guess that might take a while if the publisher is broken for longer
<infinity> pitti: Should get picked up in the :03 run.
<pitti> infinity: ah, did it catch up with the kde-l10n* stuff?
<infinity> Yeah.
<pitti> cool
<pitti> I'll retry stuff after that
<pitti> ^ gtksourceview: upstream did a large patch to fix whitespace in the code, which balloons the diff
<infinity> Because point releases are always the best time for whitespace cleanups.
<pitti> well, better than breaking that silly and incomprehensible garbage _between_ the whitespace :-P
<infinity> I never look at that stuff.
<infinity> I just check to make sure everything's pretty.
<pitti> it's all *.bf anyway, isn't it?
<pitti> that would actually be fun: a brainfuck source with comments which translate the logic to C
<infinity> You have an odd sense of fun.
<infinity> Oh, FFS, argument wrapping too?
<infinity> I'm just going to assume those are all the same arguments on new lines, cause I really don't want to compare every one...
<infinity> Oh, I guess it wasn't that much.
 * infinity stops whining.
<infinity> I do wonder if I'm the only person who finds argument wrapping less readable, though.
<pitti> I personally prefer it if a single line spills over my screen line length
<pitti> since "nicely wrapped" >> "arbitrarily wrapped"
<infinity> Yeah, being dyslexic, you'd think I'd have the same argument.
<infinity> Cause for actual reading (like, fiction, websites, whatever), I can't handle long lines.
<infinity> For some reason, it irks me to wrap function calls, though. :P
<infinity> I might just be insane.
 * infinity waits impatiently on those last two compiler builds so he can upload 10 more.
<pitti> oh, I need to squeeze a glib in between that
<infinity> What's wrong with the glib that's building right now? :P
<pitti> http://git.gnome.org/browse/glib/commit/?id=6560b37450cd19c4a7c7b690e279fe97b7bfdcaa
<pitti> we want to revert that
<pitti> it's causing unnecessary spewage on package installation
<pitti> http://paste.ubuntu.com/932482/
<pitti> sorry, I missed that before
<infinity> Ahh.
<pitti> it doesn't really break, but looks ugly
<infinity> Yeah, noisy upgrades make me a sad panda.
<pitti> and we won't fix all pacakges now
<pitti> that's something for the start of next cycle
 * infinity nods.
<infinity> Are there plans to actually cleanse glib includes in all of universe next cycle, so we can stop re-adding-and-reverting the single-include stuff every 3 months?
<pitti> I think we should, yes
<infinity> I fix them when I run into them for other reasons, but we should probably just compile a list and go to town.
<infinity> The single-include fixy shell script works wonders.
<seb128> Debian is fixing those
<seb128> we can drop that patch next cycle
<infinity> pitti: Well, let's see that new glib, and we'll score it through the roof on PPC and get it in.
<infinity> And then I'll eat the buildds with compiler uploads in a couple of hours. ;)
 * ogra_ hands infinity some ketchup 
<infinity> Om nom nom?
<ogra_> or do you prefer buildds with mustard ?
<infinity> Mayo.
<infinity> pitti: gtk+3.0 on ARM should be happy on ftpmaster now, retry away.
<pitti> infinity: thanks, all poked
<infinity> Oh dear.
<infinity> Almost the entire mousetweaks diff is someone using a different version of diffstat. \o/
<pitti> ok, glib being quiet now
<pitti> I did a local build/install/test for paranoia's sake
<infinity> What's this "testing" you speak of?
<pitti> install, reboot, check that boot, lightdm, session works, and that sudo apt-get install --reinstall shotwell is quiet now
<pitti> it's just changing glib-compile-schemas, but oh well, with all those new compilers flying around.. :-)
<infinity> You didn't want to feel left out? ;)
<jbicha> what do you think of bug 982719 ?
<ubot2> Launchpad bug 982719 in mutter "FFe: Add Unity's window keyboard shortcuts to GNOME Shell" [Undecided,New] https://launchpad.net/bugs/982719
<infinity> jbicha: This would affect nothing but gnome-shell?
<pitti> at least mutter is not being used in unity, gnome classic, xfce, KDE, etc.
<infinity> jbicha: (The followup question would be "why isn't the Ctrl-Alt-t shortcut from the upload I rejected being handled in the same fashion?)
<infinity> ?
<infinity> Err.  Typing hard.
<jbicha> infinity: right
<jbicha> the Ctrl+Alt+T shortcut is more challenging since GNOME has dropped the run_command_terminal shortcut
<infinity> Oh, it's not configurable anymore?
<infinity> Boy, I <3 GNOME.
<jbicha> they didn't think it was important enough to clutter up the keyboard shortcuts panel
<jbicha> I mean who uses terminals these days any way?
<infinity> ...
<infinity> I have, like, 70 of them open.
<pitti> didn't we patch metacity to assing ctrl+alt+T by defualt?
<pitti> that's still working
<pitti> I'd notice very fast if not
<jbicha> pitti: it works every where except for GNOME Shell, & it'll stop working when we do the gsettings switch next cycle
<infinity> jbicha: So, could we make (for this cycle) just GNOME Shell launch gnome-terminal on c-a-t?
<infinity> jbicha: And then we can argue later about how to make this globally sane.
<jbicha> infinity: I'm not sure, I'll have to test that
<infinity> Anyhow, I have no issues with #982719.
<infinity> But trying to work the terminal shortcut into the same changeset might be nice.
<infinity> Two birds, one stone, no breaking other desktops (for now).
<infinity> pitti: You lost kov in the last 12 hours? ;)
<infinity> (or however long it's been between glib uploads...)
<pitti> debclean getting in the way again? it keeps updating Maintainers:
<infinity> Yeah, no big deal.
<infinity> But I found it funny that he was removed from Uploaders in such a short window. :P
<didrocks> skaet: pitti: infinity: FYI, bug #981168 on my radar, seems pretty serious (on netbooks only until now, but on 945GMA card which are widespread)
<ubot2> Launchpad bug 981168 in unity "Regression: Installing apps causes a terrible visual glitch on netbooks-- have to restart X.org." [Critical,Confirmed] https://launchpad.net/bugs/981168
<infinity> didrocks: Sounds fun. :/
<didrocks> it is, trying to get dx people working on it
 * infinity nods.
<infinity> Keep us posted.
<skaet> didrocks,  ack.
<didrocks> will do :)
<infinity> If it's a readable and reviewable fix (and soon!), we can totally get it in, otherwise, it's clearly SRU material.
<didrocks> skaet: infinity: the other change has just landed btw, with automated tests, I tried to trick it a lot as well ;)
<didrocks> infinity: that's what I told them
<infinity> Erm.
<infinity> So much for waiting for all arches before accepting binary NEW?
<infinity> Not that that's strictly required.
<pitti> erk, ppc missing; sorry about that
<pitti> that was me
<infinity> No big deal.
<infinity> It doesn't actually break anything except my mental ref counter.
<skaet> jibel,  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/982876,  trying to figure out if this is just isolated to french or is a pervasive problem for the non-english languages?
<ubot2> Launchpad bug 982876 in casper "Wrong keyboard layout in Live Session (French)" [Undecided,New]
<jibel> skaet, I haven't tested with another language. I have only french and US keyboards
<skaet> jibel,  fair enough.   does gema have a spanish one?
 * skaet only has us english... :(
<stgraber> jibel: that's bug 960096
<ubot2> Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096
<stgraber> jibel: something tells me mterry's workaround (calling gsettings through dbus-launch) only reduced the race, didn't fix it
<jibel> stgraber, it looks like it but it is 'fix released'
<stgraber> jibel: and it's also causing some more side effects (quite a few dbus-launch running for no good reason)
<stgraber> jibel: yeah, we need a "workaround releases" status in LP :)
<stgraber> jibel: feel free to mark yours as a duplicate and move back to Triaged and assigned to me
<jibel> stgraber, ack
<stgraber> jibel: I doubt I'll have a real fix for it because ultimately it's a desktop bug, but I thought of another workaround we might try which may give better results than the current one
<stgraber> (I'm off today/tomorrow but I'm happy to have a look at it on Wednesday)
<phillw> skaet: would you like me to try and dig out a tester with a non french & US keyboard?
<skaet> phillw,  thanks for the offer.   jibel,  is it needed? or does it sound like we've got the confirmation.
<jibel> skaet, that's fine, stgraber knows the problem. thanks phillw !
<stgraber> you really don't need a different keyboard ;) you just need someone to select Italian/French/whatever and check that the layout is non-US :)
<stgraber> but based on existing comments and jibel's new bug, I'm pretty sure we confirmed that the workaround proposed by mterry wasn't enough
<stgraber> (I'm usually testing these changes with French/German/Italian/Spanish/Swiss-french/Swiss-german/US/US-intl on a machine with a physical US keyboard, you just need to remember the different layouts)
<infinity> Does xkb still ship that handy utility that draws pictures of layouts?
<infinity> I forget what it was called.
<infinity> But handy for this sort of thing, cause you can just compare the picture to what's mapped where on your physical keyboard.
<stgraber> yeah, you can get a picture of your layout by clicking a "show layout" (or similar) option in the keyboard indicator
<stgraber> you can also access that option in the keyboard layout option in the system settings
<jbicha> is mutter one of the universe packages that is translatable in LP?
<infinity> pitti: So, I estimate that gcc-4.6 should be happy and ready for me to copy in ~2 hours, will you be around to review the next round of compilers I have to upload after that? :)
<pitti> infinity: unfortunately not, I'll be at TKD then
<pitti> but I will afterwards
<pitti> we have TB meeting at an abysmally late hour today
<infinity> Ahh, kay.  No big deal, I'm sure I can get slangasek to do it.
<pitti> so I can append another nightshift after sport and dinner
<infinity> I just want it all in and out of the queue as quickly as I can, as it probably represents a couple of days of build time.
<infinity> Have I mentioned lately how much I adore bikesheds?
<skaet> infinity, pitti - we may want to be careful around the builds of this to not block up the other critical stuff that needs to land in main.
<skaet> (or at least score it so it behaves nicely, once its uploaded)
<pitti> it should
<infinity> It'll be fine.
<pitti> I suppose most of whaht infinity wants to upload is the -cross stuff?
<pitti> which is universe, and thus schedules itself
<astraljava> Thanks pitti for the Studio-related uploads!
<infinity> pitti: gcj* cross* clang gdc gccgo gnat...
<pitti> astraljava: YW
<pitti> infinity: you do like the fun stuff, don't you
<infinity> Sure do. :/
<pitti> infinity: so, I'll be back around 2000 UTC
<infinity> Has anyone confirmed that python-qt4 in proposed fixes UbuntuOne yet?
<pitti> and will have a full hour to spend until TB, so plenty of time for pushing buttons
<infinity> pitti: How often is pending-sru.html updated?
<pitti> infinity: every 30 mins, after the publishers
<infinity> Mmkay.
<infinity> I suppose that makes some sense.
<pitti> infinity: there's again tons of ppc FTBFS due to arch skew, I'll retry them later
<infinity> pitti: I've just been looking at those.  Don't worry about it. ;)
<pitti> oh, thanks
<infinity> pitti: Do you actually prefer the ubuntu/<series>/+source URLs over the ubuntu/+source ones?
<infinity> (Drives me nuts that this page sends me to the series one, not the base one)
<pitti> infinity: actually I don'ot
 * pitti changese in lp:u-a-t
<infinity> Well, it also drives me nuts that those two UIs are different in soyuz...
<infinity> pitti: Same for the ones that go to +source/<version>, the non-series URL is much saner (IMO).
<pitti> full ack, changing
<pitti> infinity: committed and rolled out, next refresh should have it
 * infinity wonders why we've had NEW source in oneiric's queue since December, and if there's a reason no one's rejected it...
<pitti> I think I pinged zul about them the other day, but didn't get or forgot the response
<infinity> I'm going to go out on a limb and say that if it's been there for more than 4 months, no one cares.
<infinity> Plus, at least one of them claimed it was "targetted to precise", which it wasn't.
<pitti> ah, and live-manual was new, accepting that one
<infinity> Kinda curious about the process fail behind a partner package being stuck in there since October...
<infinity> Surely, someone should have complained about that one?
<pitti> TBH I don't really know how the partner archive works process-wise
<infinity> People upload, we accept after very cursory reviews, life goes on.
<infinity> But you'd think something that's been stuck for six months would have led to an inquiry by... Someone?
<pitti> yeah
<infinity> chrisccoulson: Are you planning to upload new flashplugin-nonfree packages to *-proposed to match your adobe-flashplugin bumps to partner, or should one of us do that?  (I already did precise)
<infinity> Holy crap, what kind of magic is that, Etherpad?
<infinity> When you block copy and paste, it keeps the author colors.
<infinity> That's awesome.
<pitti> infinity: wrt. pyqt4, I don't know what it fixes in U1; I asked the U1 girls/guys
<pitti> the bug description and dupes don't explain
<infinity> pitti: Perfect.  Yeah, I have no idea what it was breaking either.  ScottK might know, I dunno.
<pitti> looks like a good patch either way, and there's confirmation that it fixes the original bug
<pitti> infinity: hah, alecu _is_ the U1 guy :)
 * pitti rubberstamps in the pad
 * pitti copies over
 * highvoltage also does an action
<infinity> pitti: I don't know dbus well enough to know if it's a good patch.  To me, it looked like an attempt to shrink a race window, rather than close it.
<pitti> yes, the "if NULL" check certainly doesn't fix the root cause, but it looks regression proof to me
<infinity> Oh, it's certainly not worse than it was before, that's why I accepted it to proposed.
<seb128> do you guys have an opinion on https://code.launchpad.net/~charlesk/libunity/lp-981309/+merge/101998 (leak fix in libunity) for release or as SRU?
<infinity> That diff confirms my bias against Vala once again...
<infinity> seb128: I'm told that the unity folks are still working on some other last-minute fixes or some such?
<seb128> infinity, the .C part you mean? ;-)
<seb128> infinity, well libunity is a different source
<infinity> seb128: Ahh, so there's nothing in the works for libunity?
<pitti> err, wouldn't it be easier to show the actual vala diff?
<infinity> pitti: The vala diff is at the bottom.. It's a merge proposal. :P
<infinity> And the vala diff is vile.
<seb128> pitti, it's in there
<pitti> ok, that looks a bit magic
<infinity> Double-casting the same variable to try to make it generate sane code.
<pitti> I'm off for now, cu in some 5 hours
<infinity> seb128: The fix looks sane to me (in as much as fooling Vala into doing what you want ever looks "sane")
<infinity> I have no strong opinion on release versus updates for it.
<seb128> infinity, ok, thanks, i'm trying to figure how much is leaked and will come with an upload if it turns to be "enough that we want it fixed for release"
<infinity> But if we're doing other unity updates too, throw it at proposed, and see if it sticks? :P
<seb128> ok ;-)
<chrisccoulson> hi infinity. sorry, just went to do exercise
<chrisccoulson> mdeslaur_ has been handling the flashplugin-nonfree updates, but i can do that if i need to. i can't copy it to -security though ;)
 * jdstrand would be happy to sponsor them
<infinity> chrisccoulson: Oh, if you've got a process of some sort, I won't bug you. :P
<infinity> chrisccoulson: I just didn't want to accept all the partner uploads without matching ubuntu uploads.
<chrisccoulson> infinity, sure
<chrisccoulson> infinity, mdeslaur isn't around today. i'm just trying to sort out what's happening with it :)
<chrisccoulson> infinity, ok, we're sorted. could you approve the uploads to partner?
<infinity> chrisccoulson: Sure thing.
<chrisccoulson> thanks
<infinity> And since I beat queuebot to it, eglibc was in that sync/accept cycle too.
<skaet> thanks infinity
<stgraber> jibel: any chance you can do a few more tests for bug 960096?
<ubot2> Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096
<stgraber> jibel: my current guess is that it's racy, so would be great if you could confirm that
<slangasek> oh fun, why's upstart FTBFS on arm*?
<slangasek> infinity: what's changed on meissa and iara since April 10, or what's different about them from chort and caph, that would cause test failures when building upstart?
<infinity> Nothing, and nothing.
 * infinity tests locally...
 * slangasek throws one back to see if it's reproducible
 * SpamapS re-posts
<SpamapS> is precise-proposed 0-day SRU's now?
<SpamapS> or are we still using it to stage up things?
<slangasek> it's both
<slangasek> SpamapS: if you accept something into -proposed with the intent that it not go to -release, please document this on http://pad.ubuntu.com/ubuntu-frozen-archive so the release team knows
<infinity> (Mention it on IRC too, please)
<ScottK> infinity and pitti: Thanks for taking care of python-qt4.
<SpamapS> I think I'll just hold off then
<SpamapS> its not clear with any of the uploads
<slangasek> pitti: I'd like to kick defoma out of main; it's currently held there via fontconfig + x-ttcidfont-conf, x-ttcidfont-conf is only in main because of a spurious recommends from pango and two fonts - it's dead weight that doesn't actually provide anything interesting for us.  Do you think an upload of pango+fontconfig+2 fonts to kill it off would be ok?
<infinity> That frees up CD space too.
<infinity> I can't see how that's possibly bad. :P
<infinity> (But without x-ttcidfont-conf installed, don't some X bits lost access to defoma-using fonts?)
<infinity> Which could be non-obvious, if we still have such things in universe and they appear to "not work anymore".
<infinity> s/lost/lose/
<slangasek> there are no X bits that *care* about defoma-using fonts
<infinity> slangasek: And your rebuild worked.  Disconcerting.
<slangasek> ok, grand
<slangasek> infinity: if anything in X cared about defoma, there'd be a much better revdep pulling it in than pango, which a) has nothing to do with X, b) is pulling it in spuriously as an option for managing a config file that no longer exists
<infinity> Hah.
<infinity> That convinces me, then. :P
<slangasek> now, I should still look closely at fontconfig's usage before I chop it up
<infinity> I know what x-ttcidfont-conf used to do, I'm not up on the current state of fontery.
<slangasek> since fontconfig does integrate a bit better with X
<slangasek> OTOH, fontconfig supersedes defoma, so
<slangasek> hmm, pango /did/ have an ubuntu-desktop branch, but the current package's Vcs fields don't point to it and it hasn't been updated since oneiric... UDD it is then
<slangasek> ah, and the UDD branch is stale due to an import failure, how droll
 * infinity is a big fan of apt-get source. :P
<slangasek> hmm
<slangasek> ok, looking closely I see that /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType is on the X server's compile-time font path
<slangasek> so anything using X fonts *might* care about this
<slangasek> OTOH, what actually cares nowadays?
<infinity> Probaby nothing in main.
<slangasek> a further argument: pango in testing has already dropped ttcid, Debian bug #660062.
<ubot2> Debian bug 660062 in libpango1.0-0 "libpango1.0-0: please remove recommends on x-ttcidfont-conf" [Wishlist,Fixed] http://bugs.debian.org/660062
<infinity> And fontconfig?
<phillw> hi, there is abug being tracked (and for the life of me, i cannot find it) which would require the testing kernel to be used. Is this going to happen?
<infinity> ?
<infinity> "The testing kernel"?
<phillw> it is a proposed kernel, from what I read of the bug report.
<infinity> We're pretty unlikely to have another pre-release kernel upload, unless there's a dire issue.
<phillw> as I cannot find the bug in my logs, I was wondering if any of you were aware of a possible last minute kernel change.
<phillw> infinity: of that I am very aware of, but as the bug mentioned it as a fix - I have the lubuntu-qa team on stand by in case it happens. I really wish I could find the bug number! I just know it is someone from kernel team dealing with it.
<infinity> slangasek: ^--- Those 8 should be the last compiler uploads, now I just need to unbreak d-i.
<slangasek> infinity: "and fontconfig" - defoma dep still there in unstable, and it's the only one.  I'll have to look further.
<slangasek> infinity: compilers> ack; will review shortly.  since these are going to -release and need to be in sync by release date, do you have an estimate of the combined build time?
<infinity> slangasek: Well, they'll build mostly in parallel on arm*, so not a big deal there, I'd give it maybe an average of 3h per package on PPC?
<infinity> slangasek: At worst, a day for everything to catch up, I'd figure.
<slangasek> infinity: and is ppc itself caught up-ish right now?
<infinity> Yeah, PPC is caught up.
<slangasek> ok
<infinity> Well, modulo a couple of tiny packages.
<infinity> But basically caught up.
<hallyn> stgraber: ok, pushed a new lxc with utlemming's fix for cloud image creation of guests older than precise
<stgraber> hallyn: ok, I'll take a look when it hits the queue
<ScottK> stgraber: Didn't see your note here and accepted it.
<slangasek> infinity: analysis in bug #983274; dunno if you have anything to add
<ubot2> Launchpad bug 983274 in pango1.0 "pango should drop the recommends on x-ttcidfont-conf" [Medium,New] https://launchpad.net/bugs/983274
<infinity> slangasek: The "it's gone from Debian and no one seems to care" argument is pretty strong.
 * slangasek nods
<infinity> slangasek: Given that Debian users/developers are far more likely to care about old skool X font rendering than Ubuntu users are.
<slangasek> I checked the bugs filed against xorg-server, which was how I found the one requesting dropping it from the font path
<slangasek> el subproceso s'ha instaÅlat el script pre-removal se matÃ³ con la seÃ±al
<slangasek> grr, stupid word-by-word translations
<infinity> Does it require any code mangling, or it is really just dropped a Recommend?
<infinity> s/dropped/dropping/
<slangasek> infinity: just the recommend
<infinity> Cause if it's just mangling a relationship, I'm convinced.  Go for it.
<slangasek> ok
<infinity> If it turns out to be a Very Bad Thing, it's pretty trivial to revert. :P
<slangasek> yeah; uploaded, I'll be sure to do some testing today here with defoma+x-ttcidfont-conf purged to make sure nothing regresses
<infinity> Yeah, I'll dump it here and go for my semi-annual reboot, and see if my XFCE desktop gets wonky.
<stgraber> ScottK: ok, thanks for the review
<infinity> Oh, I was about to say "what about fontconfig", but that's only a suggests.
<slangasek> infinity: suggests but also a build-dep
 * infinity notices that he's hungry, and decides to do something about that.
<slangasek> I'll get there though - one thing at a time
<infinity> slangasek: Oh, I didn't check the source.
<micahg> infinity: reverse-depends -c main src:defoma -b :)
<infinity> Oh, shiny, someone reimplemented checkrdepends.
<infinity> Cause you can never have too many of the same tool!
<micahg> infinity: checkrdepends needs a local copy of the packages files :), this is service based
 * infinity nods.
<micahg> also, this one doesn't bother with in-source dependencies
<slangasek> micahg: neither does the current checkrdepends?
<micahg> slangasek: ah, I must have an outdated version then :)
<ScottK> Riddell: Do you want to respin the Kubuntu images now so we can double check for sizing?  That was if it's not fixed enough we have another shot today.
<infinity> roaksoax: Why sure, an FFe for #983091 seems reasonable, thanks for asking!
<Riddell> ScottK: doing
<infinity> slangasek: The buildds are bored and want compilers.  They told me.
<slangasek> infinity: in they go
<micahg> whoops ^^ ppa version
<slangasek> Daviey: ^^ rejecting that based on the version number
<roaksoax> infinity: could you please reject the maas upoad I just did please?
<roaksoax> or anyone else in the release team :)
<roaksoax> ah its done already, never mind
<infinity> The one that was already rejected?
<roaksoax> thanks :)
<ScottK> It was pre-rejected.
 * roaksoax needs to update dput.cfg :(
<pitti> slangasek: defoma kicking> +10 from me; most defoma stuff was already killed ages ago, seems we dropped the ball on the last meters
 * pitti clears the compiler stuff
<jibel> stgraber, I got 960096 systematically on a mac mini and an eeepc. but it works on another machine.
 * skaet just bumped into another timeout on the pad... grumble.
#ubuntu-release 2012-04-17
<infinity> stgraber: Where'd queuebot run off to?
<skaet> slangasek, https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure
<skaet> can you take a pass and add any other key feature changes that the foundations team has added this release?
<skaet> ogasawara, ^ I've put the kernel in the CommonInfrastructure too, and pulled together the bits from the other release notes.   Edit/improve as necessary
<skaet> :)
<infinity> skaet: I'm not sure we need to mention armhf linker changes in the release notes, given that there was no oneiric armhf release.
<skaet> infinity,  we do need to mention that armhf is now supported, and the default for arm ports though,  this is one way.
<cjwatson> skaet: upstart => James Hunt, not James Page
<skaet> but if the specific linker issue isn't worth mentioning in your judgement, am fine with that.
<skaet> oops
<skaet> thanks cjwatson, fixed.
 * micahg thought aufs was reenabled, did that not happen?
<cjwatson> It did.  Bug 943119
<ubot2> Launchpad bug 943119 in linux "aufs.ko missing from the Precise kernels" [Medium,Fix released] https://launchpad.net/bugs/943119
<cjwatson> People should still migrate though
<micahg> right, but shouldn't the release notes reflect reality though :)
<micahg> AUFS has been disabled, anyone needing AUFS is encouraged to migrate to overlayfs.
<cjwatson> Oh I agree
<cjwatson> Just saying
<micahg> I agree with what you're saying as well :)
<cjwatson> (Also, the above is a run-on sentence, which we should avoid)
<cjwatson> But it's >2:30am here, so bed
<micahg> skaet: ^^
<skaet> cjwatson, sleep well.
<micahg> skaet: this should probably also be mentioned under the kernel: https://lists.ubuntu.com/archives/ubuntu-devel/2012-March/034969.html
<skaet> micahg,  good point.   added.   Will let leann wordsmith a bit more.    ;)
<micahg> skaet: did you see the note about aufs above as well?
<skaet> yup,  just deleted the AUFS has been disabled, part.
<micahg> skaet: you might want to add that it will be disappear in future LTS backport kernels per https://lists.ubuntu.com/archives/ubuntu-devel/2012-March/034880.html
<skaet> michag,  will let ogasawara decide if we want to point out future plans, or leave it alone.   Thanks for bringing it up.
<skaet> ogasawara, ^  your call.
<micahg> sounds good
<slangasek> skaet: I'm puzzled by the overall structure of this page... this is far more technical detail than we've gone into for release notes in the past, is there guidance on who the audience is and the context in which this is going to viewed?
<slangasek> skaet: if it's really supposed to serve the same function as release notes in the past, I would cut everything about gcc/python/upstart, none of which rises to the level of warranting top billing in the release notes
<slangasek> (upstart logging is great, but users will discover that when debugging; until then they don't need it :)
<skaet> slangasek,  have broken it up to a per-product, and the kernel and foundations bits are in the common section.   Thought here is to give users an overview as to what's in the release and structure it in a way we can extend for the .1, .2, etc. release.
<skaet> slangasek,  guidance is to give a more general feature overview for the users.    If something is too detailed,  strike it.
<skaet> :)
<skaet> I was just merging technical overview information from the prior releases as a starting point.
<slangasek> right
<slangasek> fwiw in the past we've scratched the technical overview info and started from scratch when doing the final release notes, because there's such a big disparity in the level of technical detail we want to give alpha/beta testers vs. users who are going to see links to these notes in the installer/upgrader
<skaet> slangasek, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/982859 - is update-manager appropriate, or should this get directed to desktop/skype?
<ubot2> Launchpad bug 982859 in update-manager "Upgrade to 12.04 breaks if skype is installed" [High,Confirmed]
<slangasek> how is breaking this up by product going to work in practice?
<slangasek> because there's a single release note URL that's passed in the installer... is that going to only point to the desktop bits now?
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop
<skaet> is the Desktop one....
<skaet> working on the server one.
<skaet> want the installation requirements, instructions, etc. broken down per image.
<slangasek> looking at the skype bug
<skaet> then our point releases can be linked off of the pages that have LTS.
<skaet> skype is priority.   more on this tomorrow. ;)
<slangasek> this looks like not-a-bug
<slangasek> OTOH, most reports of skype causing upgrade problems look like not-a-bug to me, so let me be sure
<skaet> slangasek,  Ursinha is still around if you want more details.
<slangasek> Ursinha: can you please file a separate bug report with upgrade logs for your skype upgrade issue?  ^^ 10.04->12.04 vs 11.10->12.04 are going to need entirely separate debugging
<slangasek> Ursinha: and I expect that any analysis I do on the original submitter's logs is not going to apply to your case (non-multiarch vs multiarch, etc)
<Ursinha> I'll do
<infinity> Oh, since queubot's being unhelpful.
<infinity> slangasek: There's a compiz-plugins-extra upload in the queue that could use someone !me approving.
<slangasek> Ursinha: taking a stab in the dark, though, I would guess that: 1) you installed skype from the skype.com website; 2) you selected the .deb listed as "64-bit" on the skype website; and possibly 3) you don't have the partner repository enabled
<infinity> Actually, wait.  When does universe freeze?
<slangasek> infinity: "later"
<infinity> Maybe it doesn't need approval, it's a bug fix. :P
<slangasek> yeah
<Ursinha> slangasek, my skype was skype:i386
<slangasek> oh, interesting
<slangasek> I definitely want to see the logs then :)
<Ursinha> sure, will find them
<slangasek> it's also possible this was caused by another annoying instance of temporary multiarch uninstallability and that it'll be a non-issue for release... but we'd better make sure
<infinity> Most M-A upgrade bugs amount to that.
<infinity> Which is annoying, when trying to find the real bugs in the haystack. :/
<slangasek> well, the timing of this one is odd, because I thought everything of substance went through -proposed
<slangasek> in the past 24h
<slangasek>   skype:amd64 Depends on skype-bin [ amd64 ] < none > ( none ) can't be satisfied!
<slangasek> that's the original submitter's issue
<slangasek> and is specific to 10.04->12.04
<infinity> What was the default compiler in oneiric?
<slangasek> gcc-4.6
<slangasek> (.1)
<infinity> Oh, kay.
<infinity> Then I won't blame my gcc-4.5 upload for breaking Ursinha's upgrade.
<infinity> (gcc-*-base being MA:same and all...)
<slangasek> hmm
<slangasek> I think we might just need to un-blacklist skype
<slangasek> because new skype:amd64 wants an i386 dependency; old skype:amd64 wants ia32-libs; new ia32-libs wants an i386 dependency; old ia32-libs wants lib32v4l-0 which I may have killed with fire
<slangasek> sigh; unintended consequences
<Ursinha> hm, I guess one of the uninstallable packages today was lib32v4l-0... will check again
<slangasek> yeah, can't hold the stack back because it needs lib32v4l-0, which Depends: libv4l-0 (= 0.6.4-1ubuntu1), and we kinda don't want to hold that back
<slangasek> Ursinha: lib32v4l-0 is gone from the archive
<slangasek> it went away in oneiric
<slangasek> so that should not have been implicated in an oneiric->precise upgrade at all
<slangasek> although, libv4l-0's shlibs haven't changed since 0.5.0
<slangasek> if we held that back on lucid upgrades, it should dtrt... there'd just be a handful of packages left to upgrade once multiarch got applied
<slangasek> (handfull == skype+ia32-libs+libv4l-0)
<slangasek> +wine
 * infinity thinks it might be time to call it quits for the day.
 * ScottK thinks infinity must be getting old and weak.
<infinity> I won't disagree with that.
<infinity> But you forgot fat.
<ScottK> I haven't seen you in person in awhile.
<micahg> ScottK: lua-lgi synd
<micahg> *syncd
<ScottK> OK.
<ScottK> Did someone else accept it already?
<infinity> o/
<infinity> The fat man got there first.
<ScottK> OK.  Good for you.
<ScottK> All the armhf symlink farming didn't entirely rot your brain.
<infinity> Close.
<infinity> Best bug report ever: "Don't know what happened! I was browsing Launchpad through Chromium browser."
 * skaet pondering where to group Netboot images.... 
<infinity> In what sense?
<Sarvatt> infinity: someone typed something there.. are you saying you dont get bugs with "..." as the summary? want some? :)
<skaet> infinity,  group them with Server or Core or ...?
<skaet> own page
<infinity> Sarvatt: Heh.
<infinity> skaet: From the POV of release notes, I'm not sure they really need mentioning at all.
<skaet> infinity,  we put links into where they get downloaded from
<skaet> need to find a home for that
<infinity> I suppose.  Using netinst images is a pretty wildly technical thing, just pointing people at the installer-$arch directories doesn't help much.
<infinity> People who know they need them probably know where to get them.
<Ursinha> slangasek, odd enough I can't find any evidences that skype is the culprit right now looking at the logs
<slangasek> Ursinha: can you post them to a bug so I can have a look too (or post me the bug number if it's already filed)?
<Ursinha> slangasek, I haven't file a bug yet, am trying to find a clue of what happened so I can look for duplicates; I've uploaded the /var/log/dist-upgrade folder here so you can look: http://people.canonical.com/~ursula/dist-upgrade.tar.bz2
<Ursinha> *filed
<infinity> Oh, dangit, I forgot all the no-change rebuilds of cross-compilers.
<infinity> Do dee doo...
<slangasek> Ursinha: yours is bug #902603
<ubot2> Launchpad bug 902603 in taglib "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix released] https://launchpad.net/bugs/902603
<Ursinha> oh, it's fix released?
<slangasek> apt-term.log: (Noting disappearance of libjpeg8, which has been completely replaced.)
<slangasek> it's fixed /in precise/; needs backporting to oneiric in SRU
<skaet> slangasek,  mark it for release note?
<infinity> It really should be fixed in oneiric before we release.
<slangasek> skaet: even though it's intended to be published as an SRU before the release?
<skaet> if SRU for oneiric goes out before release,  then guess not.  :)
<slangasek> until it's SRUed, I wouldn't be able to write a useful release note anyway.
<slangasek> "sometimes your upgrade might fail.  If it does, turn it over, shake it, and try again."
<skaet> lol
<skaet> yeah, not ideal.
<Ursinha> slangasek, do you have a safe workaround for that? I almost had to reinstall everything in order to fix the mess
 * skaet --> zzz
<slangasek> Ursinha: dpkg -i /var/cache/apt/archives/dpkg_*.deb; dpkg -i /var/cache/apt/archives/libjpeg8_*.deb; apt-get -f install
<Ursinha> skaet, good night :)
<Ursinha> cool, adding that to release notes might do it for now
<Ursinha> and to the bug (if not there)
<skaet> Thanks Ursinha. :)
<slangasek> Ursinha: feel free to do so... in the meantime I'm going to get that SRU going :)
<Ursinha> great :)
<Ursinha> done
<Ursinha> and thanks sladen
<Ursinha> oops
<Ursinha> slangasek, even
<slangasek> ok, dpkg sru uploading
<infinity> Hrm, I should get added to ~ubuntu-sru so I can officially review and approve that for you. :P
<Ursinha> night all
<infinity> Ursinha: 'Night.
<pitti> Good morning
<infinity> pitti: o/
<pitti> hey infinity, how are you?
<pitti> rejecting vte3, asking for reupload to -proposed
<infinity> I'm alrightish.  Kinda hoping I sleep tonight. :P
<infinity> powerpc should recover from my compiler uploading pain in ~7h
<infinity> Really wish we had that 3rd buildd already. :/
<pitti> yeah, just noticed
<pitti> https://launchpad.net/ubuntu/precise/+builds?build_text=&build_state=pending
<pitti> still four compilers to go
<pitti> there are 3 or 4 remaining gnome 3.4.1 tarballs to do, doing now
<infinity> gdc-4.6 will fail in the first 30 seconds.
<infinity> And the others are all fairly quick builds, compared to gcc.
<infinity> (Or the evil gcc-snapshot...)
<pitti> -snapshot does the full fun of triple-bootstrapping and test suite, I guess
<infinity> And builds every compiler in the suite.
<infinity> That's the painful part.
<pitti> queuebot is AWOL?
<infinity> Yeah.
<infinity> stgraber: Seems to have discovered life outside of IRC and hasn't noticed. ;)
<pitti> queuebot: you'll get ice cream when you come back, promised!
<infinity> Err, 's/: S/ s/'
<pitti> <fake queuebot> cheese packaging is kindly waiting for a hug
<pitti> s/packaging/package/
<infinity> Hahaha.
<infinity> Accepted, and going to bed. :)
<pitti> infinity: sleep well
<cjwatson> skaet: if you're breaking the release notes up, please make sure that the web team knows about it for the table of release note URLs by product/release/architecture maintained on www.ubuntu.com, so that the installer will link to them properly
<stgraber> infinity: and it's back ;) with some basic reconnection code now, hopefully that'll help
<pitti> didrocks: ^ accepting, FYI
<didrocks> pitti: ah thans, the queue page is still not loaded here
<didrocks> pitti: tried to refresh 3 timesâ¦
<didrocks> thanks*
<mvo> I have a updated app-install-data upload, should that go to -proposed at this point or can/could it still go to the main repo?
<pitti> mvo: can go to precise, it's arch:all
<mvo> ta
<pitti> mvo: http://launchpadlibrarian.net/102317906/synaptic_0.75.9_0.75.9ubuntu1.diff.gz
<pitti> mvo: why does that add a 00list?
<mvo> pitti: it will use a different set of patches on ubuntu and debian (well, none on debian, some on ubuntu to set eg. changelog location). this is a side-effect of that its not a sync anymore
<cjwatson> Does the fix for bug 982883 require a UIFe?
<ubot2> Launchpad bug 982883 in ubiquity "Wrong color of top panel in ubiquity-dm" [High,Triaged] https://launchpad.net/bugs/982883
<cjwatson> It's a regression from 11.10 and looks fairly awful, so I'd like to get it fixed
<pitti> I consider it a bug
<pitti> but terminology aside, I'd also approve it as an UIFE
<cjwatson> I suppose I should tell ubuntu-doc@
<cjwatson> posted to -doc and subscribed ubuntu-release for the exception request
<stgraber> cjwatson: the panel was fine 2-3 weeks ago, so it's a very recent regression, don't think we need a UIFe for that
<stgraber> cjwatson: I spent a day doing bugfixes on the panel during the installer sprint and it was definitely black at that point :)
<cjwatson> ah, well, better safe than sorry
<stgraber> cjwatson: according to bzr, panel.png was dropped last thursday (12th)
<cjwatson> ha
<stgraber> probably part of "Remove the need for gtk2-engines-pixbuf in the gtk2 theme, save some CD space"
<cjwatson> rejected apt from oneiric-proposed per discussion on #ubuntu-devel
<ScottK> kdevelop was me.
<skaet> cjwatson,  re: release notes,  told web team about it last month,  they were fine with approach.  I'll be double checking the linkage as soon as they have the staging site up.
<skaet> pitti,  https://bugs.launchpad.net/unity/+bug/965323 seems to have a fix ready to go,  and fixes a nasty regression.    Any issues from your point of view (bad interactions) with other fixes already approved?
<ubot2> Launchpad bug 965323 in unity "Panel is transparent when Dash is open; no blur no average BG color" [Medium,In progress]
<Cimi> pitti, here I am for a discussion
<skaet> pitti,  affected are netbooks in particular.
<Cimi> all hardware not capable of opengl 2.x
<Cimi> so all netbooks and not recent laptops
<Cimi> was a regression introduced in unity 5.8.0 by a wrong commit, I basically reverted the commit so we can consider this patch safe and tested (it's the codebase of unity 11.10 and tested till 5.6.0, doesn't have any issue)
<pitti> hm, I have a deja-vu about this; wasn't this recently discussed already:
<pitti> ?
<Cimi> pitti, not that I am aare
<Cimi> *aware
<Cimi> pitti, well, maybe it was, but I fixed it safely so I'd like to see if we can ship 12.04 with that fix
<pitti> so, no objection from me
<Cimi> ubuntu is installed on lots of netbooks, and many people don't even run upgrade, having such a broken experience at first glance it a bit embarassing :\
<Cimi> great
<skaet> thanks pitti,  Cimi.
<Cimi> pitti, could you pls add your ack in the bug?
<pitti> done
<skaet> pitti,  will you upload the translations before end of day?   would like to get them included, and make any last minute size adjustment to the images for tomorrow, so we're ready with release candidates on Thursday.
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule (LanguagePackTranslationDeadline) is today.
<skaet> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AgtV30nnv18edFRBS1NNREM5bWdYTGM3eEVwRFdyX1E#gid=0
<stgraber> skaet: preparing the ubiquity-slideshow-ubuntu upload now, should be in the queue in ~10 min (depending on how quickly LP exports the translations)
<skaet> Thanks stgraber!  :)
<deej> I'm going to be doing a release upgrade on kapok and disabling builds on there while I'm doing it
<deej> Scream now if this is a terrible idea
<skaet> deej,  how long out of commission for?
<deej> skaet: Probably an hour or so
<deej> Hopefully less, but one never knows
<deej> hard -> lucid is a bit of a dance
<deej> *hardy
<skaet> deej,  not aware of anything critical in that period.   (a day would be different ;) ) no screams from me.
<deej> Sweet
<deej> I'll let you know when I start and finish
<deej> Cardamom will be next once I've done kapok and ensured nothing went horribly awry
<didrocks> pitti: skaet: so you really want that we pushes this. this code path has not been tested for few weeks. I fell unconfortable pushing that
<didrocks> pitti: skaet: meaning, if it crashes on some various netbook as it did in the past, you agree to take the chance?
<skaet> didrocks,  screen shots from netbook look seriously wedged without it.   do you have the bug numbers of the prior crashes?
<didrocks> skaet: we had some crashes on gboolean vs bool usage on amd64
<didrocks> and this changes that
<didrocks> you can look at debian/changelog for some crashes with it
<didrocks> skaet: and we released oneiric with worst top panel effect, I'm really unsure why you want this now and not in the first SRU
<didrocks> but anyway, if you feel confident, I'll push it. I just don't want to be guilty if there are side-effects
<skaet> didrocks,  warning appreciated.    We'll regress it out if side-effects occur.
<skaet> Cimi, ^
<didrocks> ok, I'm pushing the change
<didrocks> merging the patch, let's see how it goes
<cjwatson> grub2: tested successfully by manjo, isolated to EFI paths
<cjwatson> fixes abject boot failure
<Cimi> didrocks, gboolean vs bool is different
<didrocks> Cimi: is it
<didrocks> Cimi: doesn't seem in that case
<Cimi> didrocks, nux returns bool
<Cimi> didrocks, it was wrongly using FALSE
<Cimi> which requires an extra compiler instruction to translate FALSE into false
<Cimi> it is just saving one instruction, but the value is the same
<Cimi> I can use FALSE, but it is wrong
<didrocks> I still don't agree that's something that should get fixed now, it seems it didn't annoy anyone for the past 4 weeks (since 5;8)
<didrocks> but if you prefer it, ok, meanwhile, we still have wrong matching application on the launcherâ¦
<didrocks> Cimi: please propose a packaging branch I'll sponsor you
<Cimi> didrocks, fine
<Cimi> didrocks, remember that each of us do a different job: I take care of those bugs, other take care of bamf or crashers
<Cimi> didrocks, it's not my fault if nobody is proposing fixes for the launcher
<didrocks> Cimi: I do but we keep having small UI changes and changes of changes for the past 4 months because "last visual change was bad"
<Cimi> didrocks, unfortunately visuals are affected to regressions like other changes.
<Cimi> didrocks, we need to add a strong framework for reftests
<didrocks> well most of the time it's presented for "harmless visual though" :)
<Cimi> but it's another story, and I will propose a talk at the ps sprint
<didrocks> Cimi: ready once you propose the branch
<Cimi> didrocks, I am of the opinion that we should not make a fuss on visuals
<Cimi> ok
<Cimi> will do
<Cimi> didrocks, what shall I do, cherry pick the diff?
<Cimi> didrocks, and propose with ~ubuntuX
<didrocks> Cimi: create a changelog and bzr merge the commit from trunk
<Cimi> ok
<Cimi> cool
<Cimi> didrocks, shall I wait for my branch to be merged to trunk?
<Cimi> I might need an UNBLOCK :) https://code.launchpad.net/~unity-team/unity/unity.fix-965323/+merge/102278
<didrocks> Cimi: yeah, that tests passed and such
<didrocks> Cimi: no, we are not in freeze, so it will get merged at next run
<didrocks> let me look
<didrocks> Cimi: it's needs review still
<didrocks> Cimi: nobody approved the merge status itself
<Cimi> didrocks, I did
<didrocks> Cimi: next run is at 35, then 30 minutes for building and make check
<Cimi> ok
<Cimi> thx
<didrocks> yw
<didrocks> pitti: do you want to go with precise-proposed for that one as well? ^
<pitti> didrocks: if it's not too much trouble, yes
<didrocks> Cimi: please target precise-proposed in the changelog instead of precise FYI
<Cimi> ok
<Cimi> thx
<didrocks> hum, no Cimi? ok, doing the cherry-pick then
<didrocks> [Errno 111] Connection refused ?
<didrocks> am I the only one getting it?
<didrocks> ah, fine now
<skaet> doko,  I've rejected gcc 4.6, neither bugs listed appears to be release critical,   feel free to educate me if I'm overlooking something.
<didrocks> skaet: pitti: unity uploaded ^
<skaet> didrocks, waiting on diff.  thanks.
<pitti> skaet: apport/kerneloops uploaded now
<skaet> thanks pitti
<skaet> pitti, can you review the unity upload?
<pitti> sure
<pitti> skaet: I think we should queue at least apport for a while, and upload it at the last minute only
<pitti> especially while we are still getting new unity releases, etc.
<pitti> we don't want to miss crashes from those
<skaet> pitti,  fair enough,  will mark it as such on the pad
<skaet> oh,  speaking of which...
<pitti> kerneloops is probalby fine, we won't get a newer kernel now
<pitti> yeah, I think we need to fix those pads by UDS
<skaet> given our lovely timeout behaviours
<pitti> they didn't use to be so unstable
<pitti> and we are so going to need them for UDS
<skaet> do folks want me to switch to tracking on a WIKI instead
<skaet> at UDS,  we usually open and close, rather than come back to periodically,  so probably won't be such an issue for there.
<pitti> skaet: TBH, I'd rather reconnect every once in a while than always having to do the wiki overhead, but I don't have a strong opinion
<skaet> slangasek, cjwatson, ScottK, infinity,  (and other release team members who are using it ;) )  any strong preferences?
<skaet> on pad vs. wiki?
<ScottK> I'd prefer Gobby.
<Riddell> what's the downside of the pad?
<cjwatson> the pad is treacherous: it looks like it's up to date but half the time it fails
<cjwatson> I find it completely awful in nearly every way
<ScottK> Have to reconnect all the time and can't tell if what you have is up to date.
<Riddell> hmm I've never noticed that with etherpad, maybe notes.kde.org is more reliable :)
<ScottK> With Gobby you know if you're connected or not and there's not all the overhead of the wiki.
<ScottK> Riddell: I don't think it requires relogin like the Ubuntu one does.
<Riddell> Google docs is another option
 * infinity goes bouncing builds that failed due to ftpmaster being rebooted. :/
<Riddell> ScottK: right there's no login
<cjwatson> I don't really care whether it's dynamic or you have to reload
<cjwatson> half way in between is the worst of both worlds
<skaet> ScottK,  Gobby sounds interesting indeed.  Is there an instance set up somewhere we can use?
<cjwatson> gobby.ubuntu.com
<ScottK> Recall, the Ubuntu one is run by the same people that decided a pastebin that requires a login to download text would be a good idea.
<cjwatson> ScottK: which to be fair was due to widespread abuse
<skaet> thanks cjwatson, google search didn't show it.  :)
<cjwatson> (AIUI)
<ScottK> Dunno.  Other pastebins seem to manage without it.
<pitti> Riddell: right, and the pad didn't use to do that either
<pitti> seems like a recent regression
<pitti> in pad.u.c., not in etherpad in general I mean
<cjwatson> other pastebins expire much more aggressively, which seems like a different tradeoff
<Riddell> skaet: use notes.kde.org!
<cjwatson> also pastebin.com is notorious for hosting some fairly malevolent stuff that I'm not surprised ubuntu.com doesn't want to host
<ScottK> gobby.ubuntu.com isn't around anymore.
<cjwatson> oh, ok
<skaet> yeah,  was just there trying....  :(
<Laney> are other etherpad instances as bad? titanpad / pad.ubuntu-uk.rg
<Laney> org*
<skaet> Laney,  pad.ubuntu-uk.org had a nasty habbit of timeing out on me, and not letting me access it at the end of my day.... just when I wanted to do some updates.
<ScottK> I can probably provide a gobby server.  Give me a minute.
<doko> skaet, slangasek: now please could you coordinate your actions?
<doko> <doko> slangasek, infinity: now that gcc-4.6 is in precise, I assume it is ok to upload the two linaro regressions fixes to precise-proposed?
<doko> <slangasek> doko: should be, yes
<infinity> Doesn't Daviey have an etherpad that doesn't require login?
<infinity> I'd prefer not to have to run gobby just to do this.
<infinity> Ahh, yes pad.ubuntu-uk.rg.  Laney already mentioned it.
<Laney> We should get a Twitter account :P
<infinity> doko: I'll just accept it from rejected.
<slangasek> doko: if you want the release team to pre-coordinate, get the release team to comment on the bug instead of just on IRC :)
<skaet> infinity, would like some discussion first.
<slangasek> infinity: they should only be accepted as candidates for an SRU
<ScottK> skaet: mailout02.controlledmail.com port 6522 for Gobby.  I'll invent and easier hostname in a minute.
<infinity> skaet: The bugs should be fixed.  Neither is RC, as you note, but this is being staged for -updates.
<slangasek> which means a) the SRU team should be who accepts it, not the release team, b) it should be documented on the pad (or whatever replaces the pad)
<slangasek> documented that it's not for -release
<doko> thanks
<infinity> slangasek: Oh, fair point on the SRU team.  But you're on it. :P
<skaet> slangasek,  infinity - please note on the pad its purpose so we don't loose track.
<infinity> slangasek: And you already implied it was okay from your POV.
<slangasek> infinity: yep
 * infinity lets vorlon deal with it.
<skaet> slangasek,  they python patch there too,  same story?  or release critical?
<slangasek> skaet: that was discussed on #ubuntu-devel, I've been on the phone though so haven't followed the thread just yet - ScottK has commented though
<ScottK> It's not release critical, but doko would prefer it in.  I understand why he prefers it and since we're going via proposed, we can't break the archive like we did last time we tried it.
<doko> skaet, I don't care, as long as it get's into 12.04.01
<infinity> The only thing that breaks is if all arches don't build together.
<infinity> We can fix this.
<infinity> Though it means me offlining a PPC buildd to make it happen.
<skaet> ScottK,  is there a compelling reason we can't just get it in as an SRU at this point?
<ScottK> Ask doko
<skaet> doko,  would like more testing and ease it in as SRU if possible.   10.04.1 should be ok.
<doko> sure, we can do this. but then again, we'll have the parallel build issue, and that with hundreds of packages in sync
 * ScottK hands skaet at 12.
<doko> away now until midnight
<infinity> There's nothing (afaict) dangerous about the change, the danger is all in the build.
 * skaet isn't seeing a good option here.
<infinity> And we should have fixed that instead of reverting and forgetting about it, IMO.
<infinity> But oh well.
<skaet> infinity,  can we do this in proposed, after the current set clears out?
<ScottK> skaet: gobby.kitterman.com exists now if you want to use it.
<ScottK> I copied the current pad over if you want to look and see.
<infinity> skaet: We can do it any time, but let me block off a PPC buildd for it.
<infinity> skaet: It doesn't break builds while it's building, what breaks builds is if one arch lags and they skew.
<skaet> Thanks ScottK.  :)    Lets try it out, and see if we can reduce the coordination frustration factor.
<infinity> skaet: So, we accept at :04 (ie: right after a publisher run starts), and make sure all 5 arches build in the same 30 minute window, done.
<skaet> ScottK,  hmm...The server at gobby.kitterman.com is taking too long to respond.
<infinity> I'll have a PPC buildd for us to steal in ~23 minutes.
<ScottK> Odd
<infinity> So, we could do the python-defaults accept then.
<skaet> infinity,  go ahead and accept.   If you think we can pull this off.
<ScottK> skaet: What port number are you using?  Should be 6522.
<infinity> skaet: I will accept when we're ready, then.
 * infinity goes back to fixing *&$! linker issues for now.
<skaet> ScottK,  was just entering it as path  http://gobby.kitterman.com
<ScottK> skaet: Gobby needs you to use the gobby client.  You have to install the package and use that.
<ScottK> It's not a web service.
<skaet> ScottK,  sorry, didn't realize that.
<ScottK> Sorry I didn't mention it.  Since we used to use it for UDS, I assumed everyone knew.
 * skaet had forgot
<skaet> ScottK,  still seeing connection timed out from inside the Gobby client.
<skaet> probably user error still on my part.
<skaet> anyone else able to access?
<ScottK> What version do you have?
<skaet> Gobby 0.4.93 on this system
<ScottK> Looks like you installed gobby-infinote (which is too new).  You need just plain gobby.
<ScottK> Should be 0.4.12-2ubuntu1.
<infinity> Works for me.
<ScottK> And I see skaet made it.
<skaet> yup. had wrong version of the client
<ScottK> The server side for the newer version isn't packaged, AFAICT.
<skaet> is there a history mechanism with this?
<skaet> so we can see what's changing over time?
<infinity> Nope.
<ScottK> But, if you're connected and can see the document, you can be sure you're seeing the latest state.
<skaet> Hmm... history is useful.   If we could agree that things don't get deleted until the 1600 rendezvous time, it could be made to work (ie. snapshot off).  But that might be a bit more complicated than folks want.
<skaet> slangasek, cjwatson, pitti,  Laney, Riddell -  that reasonable ^ or just stick with pad?
<slangasek> I'm not thrilled with gobby as a solution for this
<slangasek> what was the problem with using a wiki page?
<cjwatson> Either gobby or wiki is fine with me
<skaet> slangasek,  overhead of waiting for it and refreshing.
<skaet> pitti's comments ^ earlier.
<cjwatson> which is strictly less than the overhead of reauthing to the pad
<cjwatson> certainly for me since it means I have to fish out two-factor-auth
<slangasek> heh
<skaet> yuck
<slangasek> I would still prefer the wiki as a solution, since it doesn't require me having to remember to launch another client
<slangasek> but if the consensus is for gobby, I'll cope
<infinity> Yeah, I'm not wildly fond of gobby as a solution.
<infinity> A stable (and not authed) pad would be fine too.
<slangasek> the pad is javascript-heavy and annoys me (and my CPU) for that reason alone
<cjwatson> GrueMaster just noticed that the linux-ti-omap4 udebs don't include ext2 despite it being modular in that kernel configuration, so effectively you can't do anything sensible with ext2 filesystems without horrible confusiong
<cjwatson> -g
<slangasek> hmm
<cjwatson> He's filing a bug, but thoughts on this being RC?  I'm not terribly happy about releasing that way
<slangasek> seems RC to me
<skaet> cjwatson,  we don't have much arm testing yet, and if its pretty much unusable without, yeah, possible RC.
<skaet> GrueMaster,  thanks for finding.    bug number please when you've got it filed.
<infinity> ARM is remarkably close to unusable and untestable until I fix initramfs-tools and d-i too. :P
<infinity> (Working on that right now.
<infinity> )
<cjwatson> so that needs linux-ti-omap4 upload (only affects arm) plus debian-installer upload when that's done (affects all arches)
<slangasek> "pretty much unusable" is an overstatement; it's only ext2 (not ext3 or ext4) that's affected
<GrueMaster> skaet: cjwatson:  bug 984180
<slangasek> what exactly is the impact?
<ubot2> Launchpad bug 984180 in linux-ti-omap4 "ext2 module missing from fs-core-modules udeb." [High,New] https://launchpad.net/bugs/984180
<slangasek> since we need FAT for the bootloader partition, not ext2
<GrueMaster> Verifying that it does/doesn't affect armadaxp as well.
<cjwatson> GrueMaster found it while trying to create an ext2 /boot
<GrueMaster> Actually, doing a manual netboot install with "Guided - Use entire drive".
<slangasek> right
<infinity> ^--- Doing co-ordinated build of python-defaults.
<slangasek> doesn't rise to the level of "pretty much unusable", but is something that's very easy to fix
<cjwatson> Ah yes, the default recipe uses ext2 for /boot
<cjwatson> We could change the recipe, but honestly, I'd rather see the kernel packaging fixed
<skaet> infinity, ack.
<slangasek> ext2 for boot is still sensible.  We don't need journals.
<cjwatson> Wow, gobby now makes the launcher pop up a wobbly icon whenever somebody joins or leaves.
<infinity> And python-defaults all built.
<infinity> cjwatson: Yeah, that seems like a really silly use of urgent window hints. /
<infinity> :/
<GrueMaster> My bad on the armadaxp.  I had thought they had seen it as well, due to the firestorm of issues this morning.
<cjwatson> Oh, could somebody review the UIFe in bug 982883 and ack/nack it?  ubuntu-doc@ seems fine with it.
<ubot2> Launchpad bug 982883 in ubiquity "[UIFe] Wrong color of top panel in ubiquity-dm" [High,Confirmed] https://launchpad.net/bugs/982883
<cjwatson> (stgraber has checked the concern Dylan raised there.)
<slangasek> so which is the authoritative page now?  Gobby or etherpad?
 * ScottK looks at skaet.
<stgraber> cjwatson: done
<cjwatson> thanks
 * ScottK wonders if the ubuntu-docs upload should be allowed in since it by definition affects documentation.
<cjwatson> I'll get that uploaded later, want to check bug 946663 first
<ScottK> ;-)
<ubot2> Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Triaged] https://launchpad.net/bugs/946663
<skaet> slangasek,   based on your comments and cjwatson's I was setting up a WIKI,   will point the pad to it.    Need the history feature,  and timeout feature on pad is causing too many problems.
<cjwatson> (dinner now)
<slangasek> ok
<ScottK> skaet: Should I shut down the Gobby then to avoid confusion?
<skaet> ScottK,  yes.  Thank you for setting it up to let us try.
<ScottK> OK.
<ScottK> It's gone.
<skaet> slangasek, cjwatson, ScottK, pitti, Riddell, Laney, infinity, https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus is up.   Have redirected the pad to it.
<pitti> skaet: ack, thanks
<slangasek> ScottK, doko, infinity: are we thinking python-defaults for -release then?
<slangasek> with the PEP394 fix
 * ScottK is not thinking about it.
<ScottK> It's clearly nothing RC about the changes (also nothing SRU worthy), but if someone wants them in, I don't object.
<infinity> slangasek: I think a few of us should test upgrades with -proposed on !i386 and make sure nothing went goofy before we discuss it. :P
<slangasek> I'm asking whether, in principle, we're considering it for -release
<slangasek> if *not*, I was going to mark it on the pad
<infinity> I think that was the kinda sorta consensus that led to me doing the build.
<slangasek> I didn't think the multiarch stuff needed to be .0; didn't know if folks had a different feeling on the python2 stuff
<slangasek> ok
<slangasek> pitti: ^^ accepting the sync
<pitti> thanks
<infinity> That initramfs-tools is more armhf linker fallout.
<ogra_> yeah, why would it be initramfs-tools, it didnt change
<infinity> http://paste.ubuntu.com/934301/ <-- Diff for the impatient.
 * pitti waves good night
<micahg> quick question, I forgot a bug in the changelog for the thunderbird stable release migration in natty, but the packages are already built (there are 2 other packages with it with the bug number), do you want me to respin (multi-hour builds) or can we copy them?
<infinity> micahg: I'm sure people can live without the bug ref.
<micahg> ScottK: ^^
<ScottK> Thanks.
<infinity> micahg: You can go all revisionist history and fix the old changelog entry in the next upload. :P
<micahg> infinity: indeed :)
<infinity> (And obviously close the bug task by hand this time around)
<infinity> Can someone review and (hopefully) accept that initramfs-tools upload?  It's blocks some testers from doing testy things.
<infinity> s/blocks/blocking/
<ogra_> infinity, it looks sane to me from your paste
<infinity> Thank god my shell is better than my English.
<ogra_> shouldnt it also cover arlem though ?
<ogra_> err
<ogra_> armel
<ogra_> .oO(how did i mess that up)
<infinity> ogra_: We didn't change the linker on armel.
<ogra_> ah, k
<ogra_> well, i'd say go for it and upload
<infinity> It's uploaded, I'm being a good boy and waiting for $another_archive_admin to accept it.
<ogra_> i have forwarded it to two guys in #ac100 that had the issue but havent heard back yet ... with luck we'll get some testing even before it is published
<infinity> ogra_: Patching mkinitramfs and running "update-initramfs -u" should fix them up.  But how they boot in the first place is another question. :/
<infinity> ogra_: I guess if their recovery is sane, they can boot recovery and chroot in.
<ogra_> they both have sosboot installed
<infinity> I tihnk I might have hosed recovery on my ac100...
<ogra_> (took me half my sunday to help them with that)
<ogra_> we should hack up the ac100-tarball-installer to just blantly dump sosboot.img into the recovery partition :)
<infinity> As for d-i (which will suffer exactly the same problem), it won't break until it's rebuilt, so I'll stage the change in bzr until we need an upload for another reason (which looks like it'll be an omap4 kernel bump).
<bdmurray> I'm pretty sure I have an upload of update-manager in oneiric-proposed that needs approval which affects upgrades from O to P.
 * infinity lunches for a bit before hacking d-i's Makefile.
<infinity> slangasek: Would love a review/accept of initramfs-tools when you get a chance.  It's tested locally to DTRT.
<ScottK> pitti: Why are we reintroduing postresql-8.4 for precise?
<ScottK> ...introducing...
<infinity> slangasek: If there's concern over "what if those things are symlinks" or similar, keep in mind that they got there via copy_exec, which does cp -pL
<infinity> ScottK: To be able to upgrade databases.
<ScottK> OK.  Makes sense.
<infinity> ScottK: Need the tools from 8.4 to dump, so 9.1 can reload.
<deej> skaet and any others who may be concerned by it, I wanted to make sure it was clear I was taking kapok/cardamom from hardy to lucid and make sure everyone was okay with doing that this close to release
<skaet> infinity, slangasek, ScottK ^ any issues on holding off?
<ScottK> On?
<infinity> deej: Was that my livefs builder ticket?
<deej> infinity: Why yes!
<skaet> s/on/to indicate we should/
<slangasek> skaet: for which?  the builder upgrade?
<skaet> slangasek,  builder upgrade
<infinity> deej: We might be getting too late to take advantage of that, though I'd really like to.
<slangasek> skaet: I think we should get it done
<infinity> Kay, let's do it, then.
<infinity> slangasek: Does this mean I get to switch wubi to ext4 too? :P
<slangasek> having the builder env closer to what everyone's using for development can only benefit us
<skaet> deej,  thanks for letting us know.
<slangasek> infinity: FFe bug and talk to ev?
<deej> I have been told there's no pressure but that I shouldn't fuck it up
<deej> So
<deej> You know
<deej> I'm sure it'll be fiiiiiiiiiiiiiiiiiine
<skaet> :)
<infinity> slangasek: ev and I already confirmed wubi will DTRT, I just need to un-revert the livecd-rootfs and cdimage changes I made earlier.
<slangasek> infinity: "already" in the recent past? :)
<slangasek> i.e., is he happy for this change to be made 2 weeks before release?
<infinity> slangasek: Oh, yeah, we haven't discussed doing it 1.5 weeks before release, no.  I'll re-discuss after lunch. ;)
<slangasek> ok ;)
<infinity> But, IMO, there's value in having wubi installs using the same default FS, and exercising the same codepaths.
<infinity> Since it's the only ext3 consumer right now.
<slangasek> yes, I agree
<deej> infinity: Sooooo, quick question, the ticket (51116) mentions i386 builders, but kapok is x86_64, do you care/does it matter?
<infinity> deej: The ticket says "x86".
<infinity> deej: One is amd64, the other is i386.
<deej> infinity: So it does, apologies, I thought I'd read i386 the first time through
<deej> Right on
<pitti> ScottK: see bug 905454, I left an explanation there
<ubot2> Launchpad bug 905454 in postgresql-8.4 "'postgresql-plperl-8.4' is marked for removal but it is in the removal blacklist" [High,Fix released] https://launchpad.net/bugs/905454
<infinity> deej: Heh, I had to go check to make sure I wasn't lying. ;)
<stgraber> infinity: looking at initramfs-tools, isn't it possible for someone to have lib/arm-linux-gnueabihf/ld-linux.so.3 in the initramfs but not /lib/ld-linux-armhf.so.3 outside of it?
<cjwatson> infinity: would it make sense for a d-i upload to wait until linux-ti-omap4 is in and built?
<stgraber> infinity: if initramfs-tools gets upgraded before eglibc
<infinity> cjwatson: Yeah, d-i won't break until it's rebuilt anyway.
<infinity> stgraber: Oh, perhaps it needs to depend on the latest eglibc, nice catch.
<deej> Alright, the upgrade is running on kapok and I've locked out the buildd user for the time being
<deej> Lest anything get started mid-upgrade
<infinity> cjwatson: So, I'll figure out how to fix it, and stage it in bzr for the next rebuild.
<infinity> stgraber: Wait, no, it'll already have that dep.
<ev> could someone please reject that apport upload
<infinity> stgraber: initramfs-tools (all) depends initramfs-tools-bin (any) depends libc6 (>= good_version)
<ev> I definitely sent it to the wrong place :)
<infinity> ev: Gone.
<ev> thanks
<ev> and thank goodness for frozen archives
<infinity> stgraber: The libc6 shlibs take care of that.
<infinity> ev: Since you're here...
<ev> wuh oh
<infinity> ev: deej is upgrading cardamon and kapok to lucid, which means we can finally switch wubi to ext4.  Are you comfy with me un-reverting my previous changes and making that happen?
<ev> absolutely
<infinity> \o/
<ev> mostly because on your head be it :-P
<slangasek> heh
<infinity> Hah.
<ev> but equally because it looks sensible
<ev> and as we already discussed, it should be fine
<ev> right, gone
<stgraber> infinity: oh, good. Then feel free to accept, that's the only potential issue I spoted.
<infinity> stgraber: Danke.
<slangasek> infinity: how do any shlibs take care of this?
<infinity> stgraber: (And I totally missed that implication, so thanks for making me trace it through to discover it was a non-issue) ;)
<slangasek> oh
<slangasek> n/m, read scrollback
<slangasek> infinity: why is it not sufficient to test for [ -e "${DESTDIR}/lib/ld-linux-armhf.so.3" ]?
<slangasek> likewise, why do you have to remove that and recreate it?
<infinity> slangasek: Oh sure, ask questions after I accept.
<slangasek> well you're a little quick on the trigger :P
<infinity> slangasek: stgraber told me to!
<slangasek> who ya gonna listen to!
<slangasek> anyway, accepted or not, I'd like to understand better what the actual issue is that it's fixing
<infinity> slangasek: If I think it through a bit more, perhaps you're right, that /lib/ld-linux-armhf.so.3 will always be there on new initrds.  I'd have to look more closely at the library reduction logic.
<slangasek> ok
<slangasek> then I think the check there is overbroad but not dangerous; I just wanted to make sure it wasn't needed for some other scenario I hadn't understood yet
<infinity> slangasek: The issue is fairly obvious (binaries wanting two linkers, but only one present), the fix might be a bit carpet-bombish, cause I was more interested in having it work than having it be elegant.
<infinity> slangasek: But yeah, you might be right that in a two-linker scenario, it'll always get reduced to only /lib/ld-linux-armhf.so.3, and I just need to link that.
<infinity> (This carpet bomb approach works for now, though)
<slangasek> yep
<ScottK> pitti: Thanks.  Makes complete sense.
<infinity> slangasek: I think I was thinking of a case where something actually checks the ELF headers for the PI, where things might end up feeling a bit non-deterministic, depending on the binaries included, and in what order.
<slangasek> fair enough
<infinity> slangasek: But copy_exec is dumber than that, it just checks ldd output, and on a two-linker system, ldd says "/lib/triplet/ld-linux.so.3 => /lib/ld-linux-armhf.so.3", which should always reduce to the new linker.
 * slangasek nods
<slangasek> s/dumber/saner/ :)
<infinity> slangasek: d-i/mklibs, on the other hand, try to be more clever, so I'll stick to the carpet bomb there to avoid an aneurysm. :P
<slangasek> ack
<ogasawara> we received a fix for bug 984180, is it okay to upload linux-ti-omap4 to precise-proposed?
<ubot2> Launchpad bug 984180 in linux-ti-omap4 "ext2 module missing from fs-core-modules udeb." [High,Fix committed] https://launchpad.net/bugs/984180
<infinity> ogasawara: Pretty please, mit sugar on top.
<ogasawara> infinity: thanks, uploaded
 * skaet --> lunch,  biab
<infinity> Oh, classy.  The one time I use gobby in the last 3 years, and it crashes on exit.
<infinity> Dear apport, tell me all about it.
<pitti> ScottK: I don't particularly like it, but it's IMHO much better than causing data loss and frustration for upgraders
<infinity> pitti: Do they then end up with two versions of postgres installed?
<ScottK> Agreed.
 * infinity wonders if https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/972208 really is a GnuTLS bug, or just gobby being gobby.
<slangasek> reviewing that kernel
<ubot2> Launchpad bug 972208 in gnutls26 "gobby crashed with SIGABRT in __libc_message()" [Undecided,Confirmed]
<ScottK> There is also Bug 984206 that I filed today.
<ubot2> Launchpad bug 984206 in gobby "gobby crashed with SIGSEGV in gtk_rc_style_finalize()" [Medium,New] https://launchpad.net/bugs/984206
<ScottK> Actually that's a different one.
<ScottK> Nevermind.
<cjwatson> linux-ti-omap4 looks good to me; accepted
<stgraber> cjwatson: ubiquity diff looks good
<slangasek> accepting update-manager
<pitti> infinity: yes, inevitably; that's how it has worked for the past 10 years or so
<pitti> infinity: there's a debconf note and docs how to do the upgrade, as there is really no solid way to do it in-place during dist-upgrade
 * pitti -> really off for the night now
<deej> infinity: kapok is back up if you guys want to give it a once over before I start in on cardamom
<infinity> deej: I'll poke it in a sec, I'm multitasking a bit too much right now. :)
<deej> Right on, no hurry
<slangasek> did these comments about apport/kerneloops on the wiki get added to the wrong section?
<slangasek> I don't see either of these packages in -proposed, but they're in unaccepted for -release
<slangasek> skaet: ^^ looks like this is your edit?
<skaet> slangasek,  yeah, my bad.   Thought they were going in proposed.   At any rate,  hold off on accepting based on timing in there.   Will fix.
<balloons> hello all.. continuing a conversation on non-pae kernel support here. it appears we are not shipping a non-pae kernel on our iso images for today..
<balloons> according to a few kernel members, the non-pae kernel support was kept, but it's not on the installer
<balloons> is this intended behavior or a bug?
<slangasek> balloons: intended behavior
<slangasek> it's available for upgrades only
<hggdh> slangasek: what happens if someone tries to install precise on a non-pae machine?
<hggdh> ah
<balloons> slangasek, why upgrades only?
<GrueMaster> hggdh: Failure.
<ScottK> slangasek: I thought it was meant to be different for Lubuntu?
<balloons> I'm not trying to stir up dirt here :-).. my apologies if I am.. I can simply take the answer
<hggdh> actually, seems to be worse, installation preceeds to end, and then fails on reboot
<slangasek> ScottK: Lubuntu may be using the non-pae kernel, I don't know
<slangasek> balloons: because supporting it for installs means taking up a very scarce resource - space on the CD
<balloons> slangasek, ScottK lubuntu is afaik.. I'm having the tester in question use it instead.. no negative feedback thus far, so I'm assuming it's working :-)
<balloons> slangasek, thanks for explaining
<sbeattie> hggdh: wait, what? we're shipping the non-pae kernel in the live cd but booting into a pae kernel? I don't think that's accurate...
<sbeattie> s/booting/after installation completes booting/
<infinity> hggdh: That seems unlikely, since the CD also uses the pae kernel.
<hggdh> balloons: ^
<slangasek> hggdh, sbeattie: we are certainly not shipping a non-pae kernel on the Ubuntu CD in precise
<slangasek> that was changed early in the cycle
<sbeattie> slangasek: right, but then I'd assume the livecd would fail to boot, not have a failure upon rebooting after the installation has completed.
<GrueMaster> I highly recommend release noting this at the very least, as a lot of system recyclers will be very displeased to learn they can't recycle older systems due to this issue.
<balloons> right.. I took that as the cd has pae kernel only.. archive has non-pae kernel
<slangasek> sbeattie: correct.  The CD will fail to boot.
<sbeattie> (hence my boggling at hggdh's failure description)
<GrueMaster> sbeattie: That is the behavior I am seeing here in VirtualBox with PAE/NX disabled.  Total boot failure on the cd.
<hggdh> sbeattie: heh. I was just the messenger
<sbeattie> ah, okay, I'll stop shooting bogglement bullets in your direction. :-)
<doko> slangasek, I'm fine with python-defaults as a sru
<slangasek> doko: ok
<Laney> ScottK: ^^^
<micahg> can someone take a look at the flashplugin-nonfree upload ^^
<ScottK> infinity: Is it you putting buildds on manual again?
<infinity> ScottK: Yep.
<ScottK> infinity: Would you please let haskell-bloomfilter go before you grab powerpc.  It's s quick build and getting it done will let me do another sync.
<infinity> ScottK: I have no intention of angering powerpc.
<ScottK> OK.
<ScottK> Excellent.
<infinity> ScottK: The only stuff on manual (other than two broken Pandas) are "old x86 builders", so we can give the new ones a workout.
<micahg> infinity: can you review flash?
<infinity> Did I break it?
<micahg> infinity: well, not upgrade is closer than break :)
<infinity> Huh.  I grepped.
<infinity> Let me guess, the SHA256 in the post-download-hook doesn't have the same variable name? :/
<micahg> infinity: sbeattie added a README.Debian to make it easier in teh future
<micahg> infinity: correct
 * infinity sighs.
<micahg> infinity: 'rgrep -i sha256 *' should've caught it
<infinity> Simple fix, s/SHA256SUM/Sha256/ in the other scripts, so it matches the hook, and an rgrep works.
<infinity> I didn't think to grep insensitively. :P
<infinity> Oh well.
<micahg> well, there's documentation now to help the next victim^Wvolunteer to look at updating flash
<sbeattie> as I've said elsewhere, the real fix is to only specify the version and sha256sum in one location, not three.
<infinity> Honestly, if you find the SHA256 in two places, you won't read a README to find out there's a third.
<micahg> yeah, that too :)
<infinity> You'll just think you're clever for having found two.
<micahg> there's a note above each telling you what else to update
<micahg> won't help if you're using sed though
<infinity> Oh, that's vaguely helpful. ;)
 * infinity needs food.
<skaet> is it my impression or is the wiki ...crawling....
<slangasek> I had a server-side error a little bit ago
<skaet> ack..
<skaet> slangasek, yes,  seeing Error reading from remote server now as well.  :P
<Laney> doomed to not communicate
<Laney> also, the topic could do with updating
<skaet> Laney, yup. meant to earlier
 * skaet handles that at least while she can't update WIKIs... :P
* ChanServ changed the topic of #ubuntu-release to: Archive: frozen | https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<skaet> Laney, done.
<Laney> excellent work
<skaet> we strive to communicate....  and yes, had to get the link from the pad.  *sigh*
<Laney> You should entertain my idea for a Twitter account. We could come up with an efficient set of hashtags :P
<ScottK> I'm not sure how the wiki is better than the pad was.
<ScottK> You still have to refresh it to get current data.
<skaet> ScottK, don't have to sign in to see it, was the hope.   but with the current behaviour....
<Laney> at least you know you have to refresh it
<ScottK> True.
<micahg> skaet: just use Daviey's pad if you don't want to have to sign in
<ScottK> Although I knew that by now about the pad.
<ScottK> micahg: Daviey's pad was deemed insuffiently reliable.
<ScottK> ..c..
<skaet> wiki appears to be working again...
<infinity> I never had issues with Daviey's pad, FWIW.
<infinity> But whatever.  We can stop caring again in 1.5 weeks. :P
<ScottK> Right.  That wasn't my assessment.
<slangasek> sbeattie: fyi, the problem in bug #983559 is by design; see bug #979477 for the unfortunate anti-bug
<ubot2> Launchpad bug 983559 in update-notifier "package-data-downloader utility does not honor apt http proxy settings" [Medium,Triaged] https://launchpad.net/bugs/983559
<ubot2> Launchpad bug 979477 in update-notifier "ttf-mscorefonts-installer installation popup and probable failure" [High,Fix released] https://launchpad.net/bugs/979477
<sbeattie> slangasek: except that the flashplugin-installer *is* pulling from a valid apt archive.
<sbeattie> where ttf-mscorefonts-installer was not.
<sbeattie> this suggests an inflexibility on configuration of package-data-downloader plugins
<slangasek> sbeattie: the fact that it's an apt archive is a curious implementation detail; it's not *using* it as an apt archive, it's not even downloading a .deb, and I don't expect the users who are affected by bug #979477 to have an apt proxy that knows about partner
<ubot2> Launchpad bug 979477 in update-notifier "ttf-mscorefonts-installer installation popup and probable failure" [High,Fix released] https://launchpad.net/bugs/979477
<slangasek> the real bug behind 983559 is not having the proxy configured for *non*-apt software, and flashplugin failures are just a symptom; probably bug #982684
<ubot2> Launchpad bug 982684 in sudo "sudo doesn't apply global environment settings from /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/982684
<slangasek> (filed in direct response to this issue, and being worked on)
<sbeattie> slangasek: well, I have to admit that I wish the flashplugin-installer did use it as a correct apt archive, so that it would pick it up from my local (non-distributed) mirror of the partner archive.
<slangasek> sure... I can't see any way to make that work in the general case though
<slangasek> except that flashplugin-installer does support debconf preseeding to point at a local file
<slangasek> (but not a local mirror)
#ubuntu-release 2012-04-18
<jbicha> bdrung: I don't think we need to have a trash icon by default in gnome-panel
<bdrung> jbicha: two reasons for it: we had it previously and we have one in unity
<jbicha> bdrung: and two reasons against it: upstream doesn't do it, and who needs trash on the desktop?
<jbicha> there's a half dozen folders I might be interested in having quick access to, but I almost completely ignore the trash folder
<jbicha> gjs will require a mini-transition for fixing the gir1.2-gjs-1.0 to gir1.2-gjsdbus-1.0 package name but gnome-shell is the only rdepends
<jbicha> bdrung: we also had the Firefox launcher, but I'm not planning to add that to gnome-panel by default either
<ScottK> jbicha: What packages?  Just gjs and gnome-shell?
<jbicha> ScottK: yes, gnome-shell is the only rdepends for the gjs gir package
<ScottK> jbicha: OK and does gnome-shell have it's build-dep versioning such that I can just accept them both and not worry about archive skew?
<ScottK> bdrung: I'm rejecting gnome-panel since it seems there's some controversy about it.  Please go to the ubuntu-desktop list, get some consensus, and then upload again if needed.
<jbicha> ScottK: in my test build, the gjs dependency worked out ok, it's a run time depends so it was added explicitly but without an explicit version
<ScottK> OK.
<micahg> jbicha: that's because Debian dropped the symbols file IIRC (don't remember if we took the change as well)
<micahg> jbicha: oh, nevermind me :)
<deej> infinity: Did you have a chance to poke kapok this afternoon?
<infinity> deej: Oh crap, not yet.  Can do so right now.
<infinity> deej: Though, I'm assuming some cron jobs have run by now.
<deej> infinity: I'm assuming you're right :)
<infinity> deej: Certainly seems like there've been a few successful builds, yeah.
<deej> infinity: Cool, I'll chalk it up as fine, I'm going to do cardamom unless you have an objection
<infinity> deej: No, no.  Please do. :)
<infinity> deej: We'll put them both through their paces a bit more heavily soon.  I've just been headless chickening all day, and you fell off the stack. :/
<deej> I figured, no worries, everyone's swapping hard on the run up to release
<ScottK> roaksoax: Where's the FFe for maas-provision?
<ScottK> New source during final freeze.  I love it.
<ScottK> Happens every cycle there is some new package or major feature that some Canonical project needs to get in during final freeze.
<infinity> It's universe, I assume.
<infinity> We've done universe debian syncs of new packages too.
<jbicha> please don't promote gnome-shell/mutter/gjs to -release yet, I'm getting this error when I try running it http://fpaste.org/ZRvq/
<ScottK> infinity: With FFe.
<ScottK> infinity: I don't mind doing FFe/sync of packages people want from Debian.  I don't mind if someone wants to do an FFe and some archive admin volunteers to review this one.
<ScottK> New source not from Debian takes a much finer tooth comb to review.
<ScottK> Given that Maas was such a priority, I guess I'd have thought they could have actually considered the release schedule.
<Daviey> ScottK: I'm taking maas-provision along with jdstrand
<ScottK> OK.
<Daviey> ScottK: It's to satisfy MIR requirements.
<ScottK> There should still be an FFe.
<ScottK> OK.
<Daviey> it's a rename/copy of cobbler package, that jdstrand wanted, and has already agreed to srcNEW review.
<Daviey> it was requested in the cobbler MIR
<ScottK> debian/changelog says "Initial maas-provision release"
<ScottK> Then I'll revise my rant to "If it's just a fickin' source rename, please say so in debian/changelog."
<Daviey> ScottK: it does have a debian/Debian.readme
<Daviey> err, .source
<ScottK> Yes, I think "renamed from ...." should make it into the changelog.
<ScottK> Since that is, in fact, a change.
<ScottK> I was going to reject it with a note that said "No FFe, reupload after you get an FFe", but I'll leave it for you to deal with then.
<Daviey> ScottK: wait.
 * ScottK isn't doing anything.
<Daviey> ScottK: it's not a 'rename' as the original package will still exist.
<ScottK> So were duplicating source in the archive under a new name?
<Daviey> ScottK: yes
<ScottK> Please tell me that's somehow actually more brilliant than it sounds.
<infinity> ...
<Daviey> ScottK: Security team doesn't want default cobbler in main.. The other option is to embded cobbler into the maas package, which i have less interest in.
<jbicha> what makes this cobbler any more delicious?
<micahg> why can't the universe cobbler use the main part?
<ScottK> micahg: My thought exactly.
<micahg> see libav/libav-extra spilt
<micahg> *split
<Daviey> "use the main part"?
<ScottK> Somehow I suspect that jdstrand wasn't actually begging to have duplicate source in the archive.
<Daviey> ScottK: He was.
<ScottK> Wow.
<infinity> micahg: I imagine the issue is that they're trying to shove something in main that depends on bits of cobbler.
<ScottK> Sounds like, but I think "then why not split just those bits out" is a reasonable question.
<infinity> Indeed, and have cobbler {Build-,}Depend on them.
<ScottK> I hope the answer isn't something like, "Yes, in theory, but this whole time based release thing threw us off - we needed more time."
<deej> infinity: FYI, cardamom is done, I'm about to close out the ticket, if you run across anything weird, just re-open it, it's enormously prioritized so we'll have a look sooner rather than later
<infinity> deej: Check, thanks.  They'll get a bit of a workout overnight, but I'll abuse them tomorrow to make sure they're all good.
<deej> Sounds good
<Daviey> ScottK: So, with maas.. we only use a subset of cobbler features.  Having duplicated source measn the security team only need to support vulnerabilities in the areas that maas uses.
<Daviey> Otherwise security would block the full MIR, as it seems to be quite vulnerability prone.
<ScottK> Right, but wouldn't it be possible to have cobbler use the part you want in Main so it's not duplicated?
<Daviey> ScottK: do you think it's reasonable to abuse an otherwise functional package and still keep the ame name?
<Daviey> people should be able to use cobbler still, no?
<ScottK> Sure.
<Daviey> ScottK: we use a subset of most of the binary packages.
<ScottK> I see.
<Daviey> ScottK: Spotted an issue with the source upload, can you reject it please?
<ScottK> Sure.
<Daviey> thanks!
<ScottK> Done.
<Daviey> ta
<jbicha> ^ ok that gnome-shell works
<infinity> Promise?
<ScottK> It's Universe.  He's got several more tries to throw it at the archive if he needs to.
<jbicha> works for me
<jbicha> works enough for me to go to bed
<infinity> jbicha: ;)
<ScottK> That was the "Universe not frozen" handwave.
<infinity> cjwatson: Did you want to refresh d-i translations at the same time as uploading for armhf/omap4 issues?
<infinity> cjwatson: My d-i bits are committed, at any rate, depends on mklibs being built and installed first.
<pitti> yay, we have an LP langpack export; /me goes to build packages
<infinity> pitti: Want to review my mklibs upload first? ;)
<pitti> infinity: waiting for diff, will do then
<infinity> pitti: Danke.
<micahg> pitti: have fun with 4 shiny new roseapples :)
<pitti> ooh!
<pitti> and new amd64, too
<pitti> still on manual, though
<micahg> pitti: yeah, by design
<infinity> pitti: The new ones aren't manual.
<infinity> pitti: The old ones are.
<pitti> infinity: OOI, why do we have so many armel PPA buildds?
<infinity> pitti: Effed if I know, that's a world I don't pay attention to.
<infinity> Since the PPAs I care about build on the distro buildds.
<pitti> if anything I had expected armhf, but most PPAs have neither after all
<pitti> anyway, was just curious
<infinity> pitti: Well, those are "virtual" PPA builders.  Which translates to "only a few special people build there".
 * micahg estimates 2.5 hours for the langpacks with the 4 new buildds
<infinity> pitti: Folks with devirt PPAs build on the distro machines.
<pitti> argh, mislooked, it's the export from Monday; so, more waiting
<infinity> pitti: So, I dunno, I assume IS knows what they're doing with the distribution of the "special" ones.
<pitti> infinity: right, hence my question why we have so many of them, I've never seen them doing anything
<infinity> pitti: Maybe they do it when you're not looking? ;)
<pitti> heisenbuilders?
<infinity> (I honestly have no clue, I suspect it may be Spads testing his qemu madness)
<pitti> lol
<slangasek> you laugh, but he's serious :)
<slangasek> I think that's probably what they are
<infinity> ScottK: Is all the dev* stuff in proposed to be copied to release?
<pitti> infinity: could I temporarily reactivate the older i386 builders for langpacks, or would that screw up anything?
<infinity> pitti: Go nuts.
<pitti> ok, great
<infinity> pitti: It's not broken, just disabled to make sure the new ones get a workout.
<pitti> export is estimated to be done at 0800 UTC
<pitti> with that much buildd capacity we can have them in the archive by 1200 UTC
<ScottK> infinity: No idea.
<infinity> slangasek: How do you feel about mklibs?
<micahg> pitti: if you just grab allspice and roseapple for i386 for the rebuild, you should be done in under 2 hours :)
<infinity> ScottK: They start with a K, you end with a K, I just assumed.
<micahg> err..I mean langpack build
<ScottK> Oh.  Looking.
 * micahg really needs to go to sleep soon
<slangasek> infinity: oh man, I haven't talked to mklibs in years, it'd be great to catch up
<slangasek> :P
<infinity> slangasek: Here's your chance, he's in the queue, pacing!
<ScottK> infinity: Yes.
<pitti> infinity: uh, it's not any more
<infinity> ScottK: Cheers.
<infinity> pitti: *raise brow*
<pitti> infinity: I mean, I accepted it, as you asked me to :)
<infinity> pitti: Oh!
<infinity> pitti: I was expecting challenging questions about the fine art of library reduction and WTF I was on.
<infinity> pitti: But thanks!
<pitti> infinity: it seemed quite consistant with the other changes (initramfs, etc.) you did thehre
<infinity> pitti: If I fall asleep before mklibs is published, want to sponsor (and tag) the debian-installer release sitting in bzr for me?
<pitti> at which point will we update base-files for lsb-release?
<pitti> infinity: sure, no problem
<infinity> pitti: Isn't there some countdown wiki that details when we do all that?
<pitti> https://wiki.ubuntu.com/ReleaseProcess
<pitti> it doesn't mention base-files, though
<infinity> Oh.
<pitti> oh, it does
<infinity> pitti: Does do.
<infinity> so.
<pitti> Release minus 3 days:
<pitti>     Make sure that /etc/issue, /etc/issue.net, and /etc/lsb-release are correct
<infinity> Yeahp.
<infinity> I got there just when you did. :P
<pitti> it's just well within the time when skaet wanted us to have actual release candidates
<pitti> so if we want to do that, we'd have to do it today
<pitti> as tonight she wanted to build the first RCs
<infinity> I think it's pretty optimistic to believe we won't upload a single package affecting any image after now.
<infinity> But sure?
 * micahg will get his blueman upload in before bed then
<pitti> oh, I agree; tonight's images won't be the final ones
<pitti> I thought the subtle difference was that they _could_ be
<pitti> i. e. there is nothing which is knowingly missing on them, etc.
<pitti> so that any further image we do is just to pick up opportunistic bug fixes
<infinity> pitti: Oh, since you might end up sponsoring d-i for me, want to check the diff in bzr now and review that, so you can pre-approve your own upload? :P
<pitti> r1676 is straightforward
<infinity> pitti: That's already uploaded.  1677 isn't. :P
<pitti> oh?
<pitti> I didn't see a "released..." bzr commit
<infinity> Hence why 1676 is tagged, and 1677 isn't.
<pitti> ah, you don't use dch -r/debcommit -r
<infinity> pitti: Follow the tags, not the commit messages.  Silly man. ;)
<pitti> so, I don't know what --ldlib does, but again that and the ln -s stuff seems consistent with the previous uploads
<pitti> infinity: yeah, I'm a huge fan of using UNRELEASED
<micahg> +1
<pitti> infinity: so, LGTM
<infinity> pitti: mklibs tries to heuristically find the linker via readelf on random binaries, which on armhf finds the wrong path first (nodeterministically, no less)
<infinity> pitti: Instead of trying to deal with the mystery of which one gets copied, --ldlib overrides the random search madness and just says "use that one, idiot".
 * pitti nods
<infinity> I so desperately want to rewrite mklibs to not be crap.
<infinity> And then make initramfs-tools depend on it.
<slangasek> ^^ death to defoma
<infinity> Cause they both get different things differently wrong.
<infinity> slangasek: Huzzah!
<micahg> even Debian's on board with death to defoma
<slangasek> most of Debian has been for quite some time; it just took a while to implement ;)
<micahg> can one of the distinguished AAs copy {thunderbird,enigmail}/lucid from ubuntu-security-proposed to *lucid-proposed*?
<pitti> can do
<infinity> Speaking of scary library reduction silliness.  Before I call this linker move "done", can anyong think of anything else that does this sort of small-filesystem-creation and might be broken?
<pitti> ubuntu-vm-builder?
<micahg> debootstrap?
<pitti> pbuildler --create
<pitti> and pbuilder, too
 * slangasek waits for infinity to rephrase the question :)
<infinity> None of those do reduction.
<infinity> They just install packages. :P
<infinity> Hrm, dracut's probably broken too, but who uses that?
<micahg> pitti: is it possible to do that copy w/out retrying the failed builds?
<slangasek> wow, why do we have dracut in the archive?
<infinity> We do.
<slangasek> ^^ why
<infinity> Also, it's written in /bin/bash, but implements its own arg parsing instead of using getopts.
<infinity> I wash my hands of this.
<pitti> micahg: I don't think so; I can only specify with or without binaries
<micahg> :(
<pitti> micahg: https://launchpad.net/ubuntu/+source/thunderbird/11.0.1+build1-0ubuntu0.10.04.1
<micahg> pitti: ok, meh, the powerpc build dies after an hour, ok, I can get the build killed I guess
<pitti> all building again :/
<pitti> enigmail copied, too
<micahg> well, if someone needs the powerpc buildd in the next hour, I'll go find someone to kill the build
<micahg> there's a second one free
 * micahg has to do another upload anyways to fix armel/powerpc, but wanted to get some initial testing in
<micahg> well, I don't have to, but I probably will
<infinity> Because you want a cookie?
 * infinity mails micahg porting cookies.
<micahg> heh, I don't like regressions ;)
 * infinity wonders what happened to the context for the debian/rules patch in http://launchpadlibrarian.net/102433012/fontconfig_2.8.0-3ubuntu8_2.8.0-3ubuntu9.diff.gz
<infinity> Oh diff, you playful scamp.
<infinity> pitti: Nevermind the d-i, I'll upload it myself. ;)
<pitti> ack
<infinity> pitti: Okay, linux-ti-omap4 and mklibs are published to ftpmaster, uploading d-i.
<pitti> will review in a bit with diff
<pitti> oh, already accepted apparently
<infinity> Oh?
<infinity> Looks like it's in the queue to me. :P
<pitti> weird, wasn't when I refreshed after queuebot's msg; anyway, there now
<pitti> diff from 20101020ubuntu133 to 20101020ubuntu134 (999 bytes)
<pitti> infinity: desperately wanted to stay below 1 kB? :-)
 * infinity hopes those are the last fires he needs to put out this week, but knows better.
<infinity> pitti: Hey, I had to tweak the changelog to get that diff size!
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg still makes me sad
 * infinity points pitti to the server team./
<pitti> infinity: I'll flush -proposed, but keep python-defaults as that has some "not me" tag in the pad^Wwiki
<infinity> pitti: Yeah, I still don't see the fear of python-defaults, but whatever. ;)
 * micahg figures it's too late to drop libwvstreams4.6-qt from wvstreams
<pitti> micahg: zero reverse dependencies, so technically possible; is it important to drop it?
<micahg> it's the last QT3 thing in main aside from lsb
<pitti> oh
<infinity> But since LSB is there, we can't drop QT3 anyway.
<infinity> So, meh.
<micahg> yeah, but the -dev packages would drop to universe ;)
<infinity> Is that a win?
<micahg> doesn't encourage use?  idk
<infinity> We enable everything by default these days, so I don't see how it discourages use.
<infinity> And anyone who knows how support works knows that we actually support by source package.  Cause we kinda have to.
<slangasek> pitti: what's your opinion on doing SRUs for multiarch library enablements?
<pitti> slangasek: at this point I don't fear simple .so multiarchification any more
<infinity> slangasek: It would probably require some more strict testing than the average SRU...
<infinity> slangasek: (All the rdeps, etc)
<pitti> I'm more wary of the special cases like per-arch plugin paths etc, as they are prone to unintended side effects and errors
<slangasek> I don't fear it, but I'm not sure it meets our SRU policy :)
<pitti> no, technically it doesn't
<pitti> except if these could be considered "safe and simple changes"
<micahg> we could theoretically use -backports since that'll require rdep testing anyways if SRU is out
<pitti> traditionally we've been more permissive on LTSes, so you can certainly find plenty of examples that don't match the letter of the policy
<pitti> but if we change a few libraries which actually cause pain to people, I think that would be okay
<pitti> slangasek: do you have a particular example in mind?
<infinity> Yeah, half the SRUs in an LTS.1 don't meet the policy, cause we try to "polish" the thing we have to support for 5 years.
<slangasek> pitti: orbit2, libart-lgpl, libbonobo, libbonoboui, and gnome-vfs
<pitti> oh, the old gnome 2 stack
<slangasek> yep
<micahg> yuck, why?
<slangasek> because software still uses them :)
<micahg> yes, but anything that needs multiarch installability?
<pitti> they don't have too many application rdepends, so that should be bearable IMHO
<pitti> slangasek: gnome-vfs might again be more tricky, though, due to modules
<slangasek> micahg: they're still in main, and there's binary-only software that wants them; so yes
<micahg> hmm, I guess there wasn't time to kill them properly
<pitti> there, new langpack tarball for real now
<stgraber> good morning
<pitti> hey stgraber
<micahg> well, so much for a blueman upload before bed, CDBS has outsmarted me at this hour
<pitti> what are you trying to do?
<micahg> pitti: can we discuss in -desktop or -motu?
<pitti> sure
<pitti> ^ I'll reupload with an additional single-digit bug fix
<pitti> ^ apport reuploaded with that bug fix, and now sent to -proposed
<pitti> so it can be accepted now, and we just defer the move to release; I updated https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus accordingly
<infinity> pitti: Looks good.
<pitti> and that won't ruin the nice tie that I have with seb128 in the bug stats :)
<infinity> He'll get more in.
<infinity> Just wait.
<pitti> nah, all to -proposed now
<pitti> which bdmurray's scripts don't seem to count
<infinity> I suppose I don't even register on this statistic.
<pitti> adconrad@ubuntu.com has 11 fixes
<pitti> everyone does
<infinity> 11.  Yeah.  Close enough to not registering.
<infinity> I need to start filing bugs for every upload I do, to make myself look better. :P
<micahg> pitti: do you want blueman in -proposed for extended testing?
<micahg> it's on 2 ISOs
<pitti> micahg: at least for keeping build skew/failures away, yes
<micahg> it's a quick build :)
<pitti> we don't actually test the bits in -proposed
<pitti> as soon as they are built and published, we copy them over, unless the pad says not to
<pitti> s/pad/wiki/
<micahg> pitti: right, I'm asking if you want extended testing :), I can ask the xubuntu/lubuntu folk to help
<pitti> they can be tested on a live system, of course (by downloading them manually)
<stgraber> right, finished catching up on IRC backlog and e-mails post-vacation, now to find some bugs to kill ;)
<pitti> micahg: can never hurt, but I thought it's just dropping one file?
<micahg> pitti: it's dropping a few files, yeah, I just don't know if any other components depend on them
<micahg> I picked a couple of simple fixes from Debian as well (control file only)
<micahg> stgraber: why is queuebot not picking up the lubuntu packageset? (see blueman above)
<stgraber> micahg: hmm, not sure, will have a look
<micahg> stgraber: thanks, one of the reasons I had it created was to help with this stuff :)
<pitti> infinity: so even roseapple now counts as "old" now?
<infinity> pitti: Only in the sense that it existed before elmo gave us new ones.
<infinity> pitti: I think we get to keep it.
<infinity> pitti: Like I said, I just had all the old ones on manual to make sure the new ones got a fair test.
<stgraber> micahg: well, queuebot does the right thing ... LP seems to lie though
<pitti> infinity: understood, thanks
 * infinity pokes the build history for all the new ones.
<micahg> stgraber: http://paste.ubuntu.com/935149/, LP seems to be right :)
<micahg> Task: xubuntu-desktop, lubuntu-desktop
<infinity> Poor lamiak hasn't seen a build yet.  All the rest seem fine.
<pitti> langpack import is at zh_TW
<micahg> infinity: wait until the langpack builds start ;)
<pitti> it'll get plenty of exercise RSN
<stgraber> >>> set([pkgset.package_set_name for pkgset in lp.distributions['ubuntu'].archives[0].getPackagesetsForSource(sourcepackagename = 'blueman')])
<stgraber> set([u'xubuntu'])
<stgraber> micahg: ^
<infinity> stgraber: Weird, cause it shows in the queue.
<stgraber> infinity: yeah and edit_acl.py shows it too... it's just when specifically using getPackagesetsForSource that it fails
 * micahg doesn't know the LP API enough to argue
<infinity> There, lamiak got a build.
<stgraber> micahg: I poked #launchpad
<infinity> pitti: Okay, you have more i386 than you could ever want now.  Enjoy.
<pitti> oh, you commissioned some amd64 ones, too?
<pitti> wow
<cjwatson> infinity: may as well - I'll go and do that now
<infinity> crested and yellow can keep up with the trickle.
<pitti> I think at this point building the sources and uploading them from macquarie will be slower than the binary builds :-)
<infinity> cjwatson: Oh see, if I'd thought you would want to, I would have not uploaded.  Oh well.
<infinity> cjwatson: Alternately, I could have done it myself, but I have no idea how. :P
<cjwatson> infinity: ah, never mind, I was still working my way through scrollback.  Not that important.
<cjwatson> I've requested a download from LP now just in case there's another.
<stgraber> sorry for that, should be working fine now ;)
<stgraber> micahg: so basically the call I was using to get the packagesets was the one used by LP to check for archive upload rights
<stgraber> micahg: which doesn't work with the lubuntu package set as it doesn't have any uploader
<stgraber> micahg: the bot now uses another API call that should return the right thing
<infinity> Huzzah.
<pitti> langpacks look good, uploading/accepting
<infinity> pitti: What do you know about this lightdm upload?  Sure looks featurey to me.
<pitti> infinity: not much; can review if you want
<pitti> i. e. I didn't get an advance warning about it or so
<infinity> I reviewed it, and is seems sane, but it's definitely new features.
<Laney> -proposed: maybe it's for SRU
<infinity> Possibly.
<infinity> We've blurred the lines a bit.
<infinity> Except, it doesn't meet SRU guidelines either. :P
<infinity> Again, new features.
<pitti> ah, to -set-defaults
<Laney> Yes, but then it's Not Our Problemâ¢ :P
<infinity> Not saying I'd reject it off-hand, and it looks sane and well-contained, and obviously not broken at a glance.
<pitti> not sure if these were requested by some derivative or OEM or whatnot
<pitti> I don't remember reading a bug about those
<infinity> pitti: Just get someone to formally ask for a FFe, so if another RM asks them about it, they can say "Release member X said I could." :P
<pitti> so l-s-d is for derivative mybuntu-defaults pacakges to change the lightdm defaults instead of hacking the config file
<infinity> pitti: It has my stamp of "looks correct to me, and I can see the value in it".
<pitti> err, perhaps I should use a slightly longer abbreviation
<pitti> infinity: *nod*
<infinity> Though, if they're going to keep hacking features into lightdm, for the love of the Flying Spaghetti Monster, can someone make it write to utmp/wtmp?
<infinity> I'm so sick of not being logged in when I'm logged in.
<pitti> infinity: you can reproduce that bug?
<pitti> please do tell Robert
<pitti> he and I can't, at least
<infinity> pitti: Bug?  What bug?  It's a missing feature.
<infinity> adconrad@cthulhu:~$ w
<infinity>  03:28:58 up 11 days, 11:00,  0 users,  load average: 0.04, 0.08, 0.05
<infinity> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
<infinity> adconrad@cthulhu:~$
<pitti> bug 870297
<ubot2> Launchpad bug 870297 in lightdm "Lightdm logins not being logged in wtmp" [High,Confirmed] https://launchpad.net/bugs/870297
<infinity> ^-- Are you saying you actually have sessions?
<pitti> I have 6 of them
<infinity> *blink*
<pitti> it's not trivial to reproduce, so perhaps robert can borrow an ssh to your box or something
<infinity> Sure.  I was always under the impression it was just a missing feature.
<infinity> It's easy to reproduce here. :P
<pitti> "last" uses the same db, right?
<infinity> last uses wtmp.
<infinity> I can't remember what w uses.  Probably the same.
 * infinity tries to remember the difference between wtmp and utmp, but it's been a while since he had to care.
<infinity> Ahh, "man wtmp" is helpful.
<pitti> "last" has data for every day here
<infinity> wtmp is logins, utmp is current session data.
<infinity> And yeah, I have neither, except for console logins.
<infinity> And ssh.
<infinity> So, I should invert that.
<infinity> I have everything, except for lightdm-spawned sessions. :P
<pitti> https://launchpad.net/builders  is a joy to look at
<infinity> pitti: The utmp/wtmp manpage seems pretty informative.  It's like a HOWTO for mangling them in C. :P
<stgraber> ^ affects the testing lab in Montreal at least, possibly some other setups too (not sure how many people actually netboot the live cd though)
<infinity> stgraber: Did you learn nothing 6 months ago?  All important casper uploads happen within ~12h of release.
<stgraber> I also noticed that the current code generating resolv.conf would generate an invalid file if no domain or search path are defined in the dhcp (fairly common for home networks)
<infinity> I should reject that just based on the above principle.
<stgraber> infinity: ;)
<stgraber> infinity: I'm happy to upload it next Wednesday if that makes you happy :)
<infinity> I'd be thrilled, but then it need to include a fix for a REALLY RC, CAN'T LIVE WITHOUT FIXING IT bug.
<infinity> So, go find one of those.
<infinity> I should try sleeping again.
<infinity> I can almost hear pitti giggling with childlike glee from here.
<pitti> 584 jobs (1 hour)  is really not that bad :)
<infinity> pitti: So, if I fix launchpad to dispatch arch:all (with no any) sources to *all* architectures, will that make you even happier?
<pitti> it certainly would :)
<infinity> You'd have an army of angry pandas.
<stgraber> I'm sure a lot of people would be quite happy to that
<infinity> Well, I really wanted to be able to do arch affinity at one point too (for things like openbios), but...
<infinity> That looks more painful to solve.
<infinity> Doing the above (just letting arch:all builds fly willy-nilly) would be fairly simple.
<infinity> Hrm.
<infinity> I wonder if I could fudge affinity, now that I think about it.
<infinity> If a package is listed as, say, "Architecture: all powerpc", I could then send it to PPC as a '-b' build.
<tumbleweed> building arch:all anywhere would certainly find us a bunch of interesting bugs :)
<infinity> tumbleweed: Bugs I'd love to fix, I don't see that as a bad thing.
<tumbleweed> but yes, some packages really do need affinity. We don't want to just give them back until they hit the right architecture
<pitti> we'd also need to find a solution for packages which are really arch:all, but don't work on some
<pitti> usb-creator and the like
<infinity> I'm having a nice lightbulb here.
<infinity> You can include packages in control that aren't actually built.
<infinity> So, we just have people include a dummy package that's for the arch they want affinity with.
<infinity> And if I see "all foo" where "foo" isn't a wildcard, I pass the build to a "foo" builder as a '-b' (instead of the usual '-B'), and done.
<infinity> There might be some broken assumptions in the queue code as well, but that should be fixable.
<infinity> But declaring it in the source package beats having some silly affinity database in LP.
<infinity> (I suppose instead of that hackish heuristic, we could define a new control stanza too)
<pitti> XS-Build-Architecture: ?
<infinity> Something like that.
<pitti> err, XC- probably
<infinity> C?
<infinity> S is source.
<pitti> S is .dsc, C is changes, right?
<pitti> I suppose .changes is the most important one, but S can't hurt either
<infinity> No, changes isn't important at all.
<infinity> LP throws it away once it's grabbed some bits.
<infinity> .dsc (S) is what matters.
<infinity> Besides, you want the hint to persist, if people apt-get source, etc.
<infinity> Or apt-cache source, rather.
<tumbleweed> is that the case for wanna-build too? (caring about .dsc rather than changes). Debian is intending to do arch-all builds at some point
<infinity> tumbleweed: .changes is only for queuebots.
<infinity> tumbleweed: .dsc is what matters (or should matter) to anything that processes source.  So, yeah, wanna-build as well.
<infinity> Unless someone broke wanna-build when I wasn't looking. :P
<tumbleweed> sounds sane :)
<infinity> Well, there's one place where .changes matters to wanna-build, I guess.
<infinity> But it doesn't read it.
<infinity> The queue bots have to tell w-b which Dist the upload was targetted to (which is only in the .changes)
<infinity> Beyond that, it's useless.
<Laney> Have fun bikeshedding it out with ftp-master :P
<infinity> (If you're setting up a new w-b, though, you just scan a source archive)
<infinity> And no, if I implement this in Ubuntu/LP, it'll be an XS header (ie: local), and people can argue about it later, I don't care. :P
<tumbleweed> :)
<infinity> It's probably been 6 or 7 years since I committed to wanna-build, I think I'd prefer to stay arm's length from whatever flamewar might come up.
<infinity> tumbleweed: Oh, as for Debian "wanting to do arch:all", the easy solution is just to make all i386 buildds build with -B by default, and you're done.
<Laney> I guess this wouldn't apply to so many packages, but it would be a shame if this were implemented differently over there
<infinity> tumbleweed: That's how we did it back when we used dak/w-b.
<infinity> tumbleweed: One sbuild config.
<tumbleweed> infinity: of course, but presumably that wouldn't happen in debian until there was affinity, or there'd be broken packages
<infinity> Well, not if they intend to turn off arch:all uploading at the same time, yeah.
 * tumbleweed wonders if we'll still be using maintainer-built debs in 10 years
<infinity> (I like right now that arch:all uploading is a way to get around Debian not allowing source uploads...)
<infinity> You can totally just do a source+all upload, and let all the binaries get cooked on the buildds. :P
 * tumbleweed should do that more
<infinity> I tend to go the other direction, and build on as many arches as I have the time for.
<infinity> But I'm not normal.
<infinity> Or sane.
<infinity> Laney: And yeah, affinity should, realistically, affect such a tiny subset of packages (I'd consider anything that doesn't NEED it to be buggy), that I don't think it matters if we implement it differently.  At worst, it's a few tiny diffs to carry, at best, we just change our implementation to accept their input.
<Laney> I was thinking in terms of your cost implementing it :-)
<Laney> (and then possibly reimplementing)
<infinity> The LP bits are costly.  Parsing a different header isn't. :P
<infinity> And if they implement it directly as a staple-on DB for w-b or something, we can't leverage that anyway.
<Laney> Yes, so as long as the general approach is the same then we're good.
<infinity> The only way it can be shared is source-level, which implies control fields, which means, at worst, we have to parse a new field.
<infinity> (The other option would be to extend P-a-s, but given the efforts to phase it out over the years, that would seem like an odd choice)
<tumbleweed> dependency availability will differ across archs, packages shouldn't end up in depwait because they hit an unsupported arch
<infinity> tumbleweed: That's readily solvable for Debian, since they do dep-waits pre-dispatch now.
<cjwatson> infinity: Debian were planning a field for affinity, I think.  Mark Hymers was talking about it at debconf.
<infinity> For us, I'm sure I could work something out in the dep-wait resolver.
<infinity> cjwatson: Cool, then we're on the same page logically, and the name really doesn't matter.  Names can change.
<infinity> Unless they're linkers.
<infinity> But I'm not bitter.
<tumbleweed> :)
<ev> finally getting around to tackling this arm build failure in whoopsie (while the world burns in our crashdb retracer farm) - how does one get build depends into porter-armel?
<cjwatson> sudo apt-get install
<ev> cjwatson: I think I'm missing a step there. Do I need to schroot into something?
<ev> as sudo apt-get install asks for my nonexistent password
<pitti> ev: yes, dchroot into the precise chroot
<pitti> there you can sudo
<ev> ah, dchroot
<ev> cheers
<cjwatson> schroot nowadays, not dchroot
<cjwatson> (per motd)
<ev> oops - I'm so used to seeing that bird that I skipped right past that
<infinity> ev: I'm still betting you're looking for something related to char signedness.  Unless it's pure coicidence that it fails on the 3 arches where that's different.
<ev> apols for that
<infinity> ev: Which means you might have a more pleasant time debugging on the powerpc porter.  It's faster.
<ev> infinity: cheers for the tip - I missed you pointing that out previously
<ev> ah indeed
<Q-FUNK> Would anyone happen to know what is the current status with esteid-browser-plugin in NEW?  chrisccoulson asked me to re-upload once upstream had fixed specific issues and it's now been taken care of.
<ev> fixed. It was not returning boolean from a glib callback
<infinity> Q-FUNK: Is that the firefox plugin that no one wants to accept, because having plugins in the archive means maintaining/updating them through 5 years of firefox releases?
<pitti> I guess we can put back the amd64 builders to normal duty?
<infinity> pitti: Sure.
<pitti> infinity: ok, doing
<infinity> I was alread. ;)
<infinity> already..
<pitti> ah, ok; I switched two over
<Q-FUNK> infinity: upstream has been doing a fine job at tracking firefox and thunderbird releases.
<infinity> Q-FUNK: Sure, but does that mean someone in Ubuntu (you?) is committed to doing the same?
<infinity> If not, we're better off having users install from upstream, as we do for pretty much all plugins.
<Q-FUNK> infinity: the package itself has been team-maintained in a PPA for the past 2 years already.
<infinity> That doesn't actually answer the question.
<Q-FUNK> yes, it does.  there's a team committed to maintaining it.
<Q-FUNK> this cannot be installed from upstream, because it accesses security modules and other stuff that is distro-specific.
<infinity> Alright.  Then I guess we're back to having one of us nitpick over the source.
<Q-FUNK> which is always welcome.  chrisccoulson's suggestion of submitting the code to mozilla for review was also a welcome idea.
<stgraber> partman-base looks good (did a manual diff as LP seems a bit slow at the moment)
<chrisccoulson> hi :)
<cjwatson> stgraber: thanks, accepted
<Q-FUNK> infinity: upstream himself is on the LP team.  he's also extremely receptive to code reviews and bug reports. this should help minimize the need for chrisccoulson or whoever else maintains FF from having to do anything more than file the occasional bug report.
<Q-FUNK> chrisccoulson: hey :)
<ev> ^ that fixes the powerpc and arm build failure. Ignore the giant diff. That's all backend code that does not get built into packages.
<stgraber> ev: having a look
<stgraber> ev: ouch, giant diff indeed, what did you do to make the source 25MB larger?
<ev> heh, new yui3
<stgraber> anyway, looks sane when ignoring backend/
<stgraber> ^ please someone accept whoopsie-daisy
<infinity> Done.
<stgraber> live-build looks good too (generates kernel-img.conf on ! alpha|amd64|hppa|i386|ia64|m68k|mips|mipsel with link_in_boot = yes) (so in our case, powerpc, armhf and armel)
<infinity> Seems sane.
<phillw> is bug 966403 going to get into the RC?
<ubot2> Launchpad bug 966403 in linux "Lubuntu Install (entire disk with encryption) doesn't prompt for disk password." [High,Triaged] https://launchpad.net/bugs/966403
<cjwatson> I suspect it'll stand a better chance if it's not on linux.
<cjwatson> Wait, /me reads the bug
<cjwatson> Wow, actually a kernel bug
<phillw> that was the one I mentioned that needed a new kernel & couldn't find.
<cjwatson> phillw: seems like a stretch.  All we know is that it's fixed in current mainline, but there's no possibility of updating to 3.4-rc2 in precise.
<cjwatson> It's a fair way from here through bisecting to find the specific commit that fixed it to backporting that.
<phillw> okies, thanks. I'll get something written up for our release notes.
<phillw> basically, they need to grab that kernel?
<stgraber> no, you don't want to recommend your users to run the mainline kernel builds
<cjwatson> I doubt that's a sane workaround for most people.
<cjwatson> Probably saner to use plymouth:force-drm as in comment 24.
<stgraber> gah, cjwatson was faster ;)
<ev> thanks stgraber and infinity
<phillw> okay. As long there is a workaround for it :) I'm a couple of thousand miles from my test rig on a course - so am 100% reliant on the lubuntu testing team :)
<stgraber> and it's also not clear exactly what hardware is affected or how widespread the problem is. It's also very unlikely to be Lubuntu specific, with it being a kernel bug, it should affect Ubuntu just as much
<cjwatson> indeed
<jdstrand> ftr, I felt that cobbler was unsupportable for 5 years and since the server team only needed a smallish part of cobbler for maas, but were under a time crunch, I gave them various options which would meet their timeframe and objectives while reducing the maintenance burden of both teams
<stgraber> phillw: I'm not sure it's even worth a release note entry, according to LP the same reporter had the issue on Lubuntu and Kubuntu but I don't see any other duplicate, making me think it's happening on a very specific piece of hardware
<jdstrand> a couple of those options included duplicate code, which is not ideal, but better than supporting all of cobbler for the lts
<infinity> jdstrand: Fair enough, as long as you're down with reviewing it all.
<jdstrand> yes, I signed up for that
<infinity> And as pennance, you get to review that firefox plugin in the queue too...
<infinity> *duck*
 * ogra_ grins
<stgraber> phillw: I think release noting would just make anyone with encryption problem set plymouth:force-drm which by itself can cause other problems (on systems with multiple video cards, like most new laptops). Might be better to just track that as a bug and hope it's fixed for the first point release. If we suddenly see duplicates appearing, we can always add an entry to the release notes post-release.
<jdstrand> my team also has a method for tracking duplicate/embedded code so neither will be forgotten about
<phillw> stgraber: okies, I'll have the workaround added to the lubuntu/FAQ/Workarounds so the support team have easy access to it.
<stgraber> phillw: sounds good
<jdstrand> oh that esonian plugin, thanks, but uhh, no thanks :)
<Q-FUNK> heheh
<jdstrand> infinity: I thought my penance was the initial review :P
<jdstrand> a pre-penance
<infinity> I like to keep thinking of new ways to make people suffer.
<infinity> I consider it proactive.
<jdstrand> you do have a knck for it
<jdstrand> knack*
<jdstrand> :)
<infinity> jdstrand: S'ok, my penance for past sins appears to be making 5 eglibc uploads to two distros in 3 days.
<jdstrand> haha
<jdstrand> ouchie
 * jdstrand hugs infinity 
<stgraber> cjwatson: can you do another rebuild of ubuntu desktop? last langpack finished building an hour ago, so everything should be published now.
<cjwatson> ah, yes, I was just about to do that
<cjwatson> running
<stgraber> thanks
<pitti> skaet wanted to do a full rebuild of everything tonight, FYI
<stgraber> pitti: her "tonight" or our "tonight"? :)
<pitti> stgraber: could very well be her "tonight", given that she said it
<pitti> so we can certainly fit in a rebuild now, if for nothign else than checking that the sizes are ok
<cjwatson> apt/oneiric LGTM now
 * pitti checks casper
<cjwatson> pitti: well, I hope so, since it's it's already running
<cjwatson> s/it's //
<pitti> casper not published yet on arm*
<pitti> but it is for the x86, so we can test that
<Q-FUNK> chrisccoulson: thanks for your e-mail.  I've personally tested the extension, but I'm unable to test the plugin without an estonian ID card. however, kalev uses the same code on fedora, afaik.
<infinity> pitti: casper's not used on arm, so that works.
<pitti> right, only missing for ppc (but I doubt it'll behave much different, and it's not like anyone would care today)
<stgraber> pitti: right, I quickly checked that casper was published on amd64 and i386 as it's where that change will be used, I don't think we do netboot desktop image testing of powerpc
<jdstrand> Daviey: is the maas-provision in NEW now the one you want looked at?
<cjwatson> oh, here, there are some new workarounds for openssl problems in upstream CV
<cjwatson> CVS
<Q-FUNK> cjwatson: anything that would help for Bug #972783 by any chance?
<ubot2> Launchpad bug 972783 in openssl "Crashes with segmentation fault operating asn1_meth_table" [High,Confirmed] https://launchpad.net/bugs/972783
<cjwatson> I looked but I'm not sure
<cjwatson> the changes don't seem to be on that particular code path, but it's openssl, who knows
<Q-FUNK> :D
<jbicha> ^ gnome-online-accounts has a new feature: Facebook support
<seb128> jbicha, did you check with kenvandine?
<seb128> jbicha, I think he has not concerns about how the work involved with maintaining support for handling of an online site which might change auth etc during the 5 years of the lts
<seb128> has some concerns*
<infinity> If it's just facebook chat, that's xmpp.
<infinity> I don't see how they'd plan to break it too badly.
<seb128> infinity, well it's account registration and stuff
<jbicha> seb128: no, I didn't ask him
<seb128> infinity, which might be different from im
<seb128> infinity, it would also not be the first time a such site is "unhappy" about third party clients which let you use them without advertisement or such
<seb128> infinity, or that would change rules about third party clients
<jbicha> we do already support Google & Windows Live there though...
<seb128> knowing that gnome-online-accounts is not used under Unity
<seb128> jbicha, yeah, i don't say it shouldn't be done, I'm just pointing it has issues over new code, it also has an implication on the 5 years support
<seb128> we never know what those websites might do in 2 years and what impact in will have on client code
<kenvandine> jbicha, that was added rather late and i didn't have time to really look at it before release
<kenvandine> jbicha, and of course the support issues in an LTS
<kenvandine> it is more than just the xmpp registration
<cjwatson> Q-FUNK: it certainly wouldn't hurt for somebody closer to that bug to file it upstream ...
<Q-FUNK> cjwatson: good point. this being ssaid, the exact same code works with the same openssl version on other non-debian-based distros.
<jbicha> well Debian & Fedora enable the Facebook provider, but I'll defer to your judgment
<kenvandine> jbicha, if it had landed earlier i would have probably enabled it
<kenvandine> but it came late
<cjwatson> Q-FUNK: Does it fail on Debian too?  We don't have a particularly extensive Ubuntu patch set here.
<cjwatson> comment 8 on the esteid bug, "I built OpenSC 0.12.2 with LibSSL 1.0.0e and this resulted the same bug." - I wonder if that was upstream openssl or Ubuntu's
<Q-FUNK> cjwatson: those estonian ID card support packages have not been submitted to debian yet but, afaik, someone compiled their own using our ubuntu packages and encountered the same issue.
<cjwatson> also strictly speaking "other non-debian-based distros" actually distro singular, the only success report is on Fedora
<cjwatson> and an unspecified version of Fedora at that, so could be older openssl?
<Q-FUNK> IIRC it also works on gentoo.
<Q-FUNK> no, that was specifically since 1.x
<cjwatson> Nobody mentioned that in the esteid bug
<Q-FUNK> cjwatson: could you add those comments to the LP bug?  tramm can then further precise on LP or upstream, as needed.
<seb128> jbicha, kenvandine: well, neither Debian or Fedora will actively support it for 5 years, it's easier for them to enable it ;-)
<cjwatson> done
<Q-FUNK> thanks!
<Q-FUNK> cjwatson: tramm is the one who filed this report.
<Q-FUNK> cjwatson: if there's anything else you need him to provide, please feel free to ask.
<cjwatson> Q-FUNK: realistically, I'm just drive-by-ing openssl for the purposes of sorting out all this TLS 1.2 stuff, I don't know it well enough to know what to ask really
<cjwatson> which is why I'm trying to narrow down whether this is Ubuntu-specific or not, as either Kurt (in Debian) or upstream will likely be able to help better
<ogra_> infinity, oh, should we drop the ti-omap4-ppa stuff from the archive before release (just struck me that its still there)
<Q-FUNK> cjwatson: does Kurt track issues at ubuntu as well?
<jbicha> ok, I filed an actual FFe bug for g-o-a, bug 984897
<ubot2> Launchpad bug 984897 in gnome-online-accounts "FFe: Sync gnome-online-accounts 3.4.1-1 (main) from Debian unstable & enable Facebook" [Wishlist,New] https://launchpad.net/bugs/984897
<cjwatson> Q-FUNK: not AFAIK
<cjwatson> openssl 1.0.1-4ubuntu2 uploaded to -proposed - please note I'd like to get this manually tested before promotion to precise (if it doesn't become an SRU instead)
<cjwatson> I'm hoping it will fix bug 969343 and at least not regress the other TLS 1.2 issues
<ubot2> Launchpad bug 969343 in wpasupplicant "Unable to connect to WPA enterprise wireless" [Undecided,Incomplete] https://launchpad.net/bugs/969343
<skaet> cjwatson, pitti - what's happening with respins?
<skaet> ie.  are any more already known to be needed?
 * skaet trying to figure out timing of switching over to release candidate on the tracker and defaults,  etc.
<pitti> skaet: langpacks are in, apport/kerneloops standing by, some other fixes are in from today
<skaet> pitti,  waiting to get signed WUBI in as well.
<pitti> there is still a python-defaults in -proposed which I'm not sure about (the wiki has a stop sign for that)
<cjwatson> handful of installer tweaks based on today's QA still to do
<pitti> and there's a lightdm in unapproved which is technically a new (small) feature
<cjwatson> and possibly this dpkg-divert bug depending on upstream feedback
<pitti> it looks alright to me, though; infinity reviewed the patch, and would feel better with a formal FFE bug, though
<ogra_> that recent mail about linker changes on ubuntu-devel-discuss looks a bit worrying
<pitti> so it's "accept now" vs. "wait for the paperwork"
<ogra_> (--as-needed vs --no-as-needed)
<jbicha> ogra_: but that changed months ago, didn't it?
<ogra_> jbicha, we just got a new toolchain upload
<ScottK> As long as someone has reviewed the details of the python-defaults change (I didn't), since it's built on all archs, it's probably better if it goes in.
 * ogra_ refers to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html
<skaet> pitti,  re:  python-defaults,  want slangasek in on discussion.   I thought he was agreeing with doko in channel yesterday it should be a 0-day SRU,  but given its built,  rather include it now,  if its been carefully reviewed.
<skaet> ScottK,  agreed.
<ScottK> doko said it could be either.
<seb128> ogra_, jbicha: well --as-needed was clearly "broken" during precise, like stuff would build with missing -l flags where they would fail i.e in gentoo or debian
<ScottK> I'm more of the "why wait" school as it'd be weird for -release to have no /usr/bin/python2 and for an SRU to add it.
<seb128> not sure if that "fixes" that, but yeah it seems late for a toolchain change if there is one
<ogra_> seb128, so you think that was fixed with the recent upload ?
<seb128> ogra_, could be
<ogra_> iirc the current toolchain change was arm only
<ogra_> at least it was supposed to be
<ogra_> but it touched the linker
<ogra_> it might even be that he is between two uploads (there were multiple ones) and it is fixed already ... just wanted to give a heads up since if it actually changed thats a bit worrying
<slangasek> skaet, ScottK: yes, the python2 part is not really SRU-suitable; so I think this is better to include in -release, though I'm not sure what testing the packages have gotten yet and think there should be some explicit testing before we copy
<skaet> pitti,  please copy it over and lets get itincluded.
<skaet> oops
<skaet> missed the last part of slangasek's statement
<doko> I did an update test, and double checked that the replaces are correct
<skaet> thanks doko  :)
<skaet> slangasek,  any other spot testing you recommend?
<ScottK> I'd suggest a Lucid -> Precise upgrade test since it has /usr/bin/python2 as well.
<doko> ScottK, lucid has python2?
<slangasek> yes, that'd be good - testing that it updates correctly from all of lucid, oneiric, and current precise
<ScottK> I thought.  Let me check.
<pitti> /usr/bin/python2 -> python2.6
<pitti> yep
<cjwatson> it did, that's why I filed that bug about the broken Replaces
<pitti> (in lucid)
<seb128> ogra_, seems others are not too concerned about it ;-)
<pitti> python-minimal: /usr/bin/python2
<cjwatson> bug 954609
<ubot2> Launchpad bug 954609 in python-defaults "/usr/bin/python2 overwrites file in old versions of python-minimal" [Medium,In progress] https://launchpad.net/bugs/954609
<ScottK> doko: Yes.  In python-minimal: http://packages.ubuntu.com/search?searchon=contents&keywords=python2&mode=exactfilename&suite=lucid&arch=any
<doko> ScottK, ahh, yes. in python-minimal, as now
<skaet> seb128, ogra_ - just tackling things in order....  ;)  we don't have .. and raise the hand syntax going.
<skaet> lol
<seb128> ;-)
<ogra_> seb128, well, then i'll go with the unwashed masses
 * ogra_ looks for a nose clamp though
<bjf> failing to install grub with today's daily-live iso .. amd64
<bjf> the usb key comes up as /dev/sda, i'm trying to install to /dev/sdb
<bjf> i get error dialog saying grub install fails
<cjwatson> logs
<bjf> it seems to be trying to install grub to /dev/sda
<bjf> cjwatson: will do
<skaet> doko,  is --as-needed change ( https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html ) a side effect of the last set of full rebuilds we include?
<ScottK> skaet: It appears there's still an open question about getting Maas into Main.  mass-provision (still in source New) is apparently required for that.  I don't know if that, in the end, implicates an image that's tested or not.
<doko> skaet, no, unchanged from oneiric
<cjwatson> we added --as-needed yonks ago.  https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
<skaet> ogra_, seb128 ^
<doko> cjwatson, but oneiric was the first release where we left it turned on for the final release
<ogra_> cjwatson, right, to me it just looked like it switched from that mail
<cjwatson> doko: sure
<cjwatson> ogra_: *shrug* I think he's misunderstanding something
<ogra_> and "within the last days" made me worry it changed due to the recent uploads (planned or not)
<cjwatson> maybe he meant to say that it was a change since lucid (true) but didn't express himself well
<cjwatson> it didn't
<ogra_> yeah, got tha now :)
<ogra_> *that
<seb128> ogra_, cjwatson: yeah, the stuff that lack -l option and shouldn't build still build, i.e no change, I still think there is something weird in there but I didn't have time to look at what,why this cycle to report a bug ;-)
<skaet> is there a bug for the man page update?  or can someone quickly handle?
<bjf> cjwatson bug 984989
<ubot2> Launchpad bug 984989 in grub-installer "grub install fails. installing from /dev/sda to /dev/sdb" [Undecided,New] https://launchpad.net/bugs/984989
<skaet> ScottK,   thanks,  hadn't checked that yet today.   Will be following up.
<ScottK> Beyond that, I don't know.  Daviey was on it last night.
<cjwatson> so a's the USB stick and b's the internal disk, hmm, it's supposed to handle this
<cjwatson> I thought there was even an automatic test for it, bah
<bjf> cjwatson: yes, that is correct
<cjwatson> bjf: any chance of an otherwise identical run with the 'debug-ubiquity' boot parameter?
<cjwatson> then 'apport-collect 984989'
<cjwatson> (when it fails)
<bjf> cjwatson: will try, it seems to have borked my usb stick, will rebuild it
<cjwatson> yeah, that's not impossible :-/
<cjwatson> bjf: I'd quite like to do some remote-hands debugging of it, timing permitting
<bjf> cjwatson: i'm yours to command
<cjwatson> the way it's supposed to work is that we look at where /cdrom is mounted from, and if that's the same as the GRUB installation location then we use the disk containing /boot instead, or failing that, just the next disk in the list
<cjwatson> either something's going wrong in that, or the output isn't being used
<cjwatson> the apport-collect logs will let me rule the latter in or out, but probably won't help much in debugging the former
<bjf> cjwatson: you just want me to add "debug-ubiquity" after boot=casper right?
<cjwatson> yeah
<bjf> cjwatson: it's telling me "No additional information collected" does that mean i didn't get the debug-ubiquity correct?
<slangasek> skaet: I've noticed that there are no milestones pre-created for 12.04.x point releases - I guess that should happen soon?
<cjwatson> bjf: no, err, it means apport doesn't work the way I think it does, I guess.  just attach /var/log/{syslog,partman,installer/debug} by hand
<bjf> cjwatson: will do
<skaet> slangasek,  I stuck them on the release notes,  but yup,  need to add them on the release itself.   They're on the ReleaseSchedule - can you review and let me know if you're aware of any changes?   Otherwise will go add them today.
<slangasek> skaet: oh, I'm not aware of any changes
<slangasek> anyway, you can change the target date of the milestone after it's added... but you can't target bugs to a milestone before it exists :)
<skaet> slangasek.  :)  doing now.
<skaet> precise-updates does exist though.  ;)
<slangasek> yep... using it
<slangasek> .1 is close enough now that I think it'd be useful to be more specific :)
<bjf> cjwatson: done
<skaet> :0
<skaet> :) even
<kirkland> cjwatson: I see that you uploaded a fix in ecryptfs-utils 96-0ubuntu3, but I'm not seeing the diff in launchpad;  I want to ensure that I commit the change to the upstream lp:ecryptfs branch
<kirkland> cjwatson: https://launchpad.net/ubuntu/+source/ecryptfs-utils I only see 96-0ubuntu2
<stgraber> kirkland: http://launchpadlibrarian.net/102498742/ecryptfs-utils_96-0ubuntu2_96-0ubuntu3.diff.gz
<stgraber> kirkland: not in the archive yet, currently in the release queue
<kirkland> slangasek: I saw some noise in -meeting about ecryptfs/btrfs...  I tested that a good bit in the 11.10 cycle, but I don't recall ever testing that in this 12.04 cycle
<kirkland> stgraber: thanks!  I'll commit upstream now
<cjwatson> kirkland: thanks.  in rather a rush, trying to get several pieces in place
<kirkland> cjwatson: understood, no problem
<cjwatson> in particular trying to unbreak lowish-mem amd64 encrypted-home installs
<kirkland> cjwatson: thanks, I've committed and pushed r675 to lp:ecryptfs
<slangasek> kirkland: ecryptfs/btrfs... all speculative at this point, don't really know
<kirkland> slangasek: mkay
<ev> skaet: the signed wubi is up, but I discovered bug 985050 while testing it
<ubot2> Launchpad bug 985050 in ubuntu "A Downloaded Wubi binary shows the autorun menu if an Ubuntu cd is inserted" [High,New] https://launchpad.net/bugs/985050
<skaet> ev,  fix coming today?
<ev> unlikely - I have to bolt in 40 minutes
<ev> I'lll see what I can manage in the time I have left
<skaet> ev,  thanks.   (and thanks for letting me know)
<cjwatson> the downloaded binary doesn't actually have to be on the released images, of course
<cjwatson> IWBNI they were in sync
<cjwatson> but the current signed one should be good enough for CD images?
<ev> yes
<skaet> thanks ev
<skaet> thanks jdstrand. :)
<jdstrand> skaet: np
<cjwatson> still working on bug 979350, but need to go and think about it for a while
<ubot2> Launchpad bug 979350 in ubiquity "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Confirmed] https://launchpad.net/bugs/979350
<Cimi> pitti, ping
<SpamapS> FYI, I have a fix for bug 981130 .. ceph.. its not on any CD that I know of.. but wanted to raise the heads up while I do my test build
<ubot2> Launchpad bug 981130 in ceph "python-ceph Depends on librgw1, which is no longer built" [High,In progress] https://launchpad.net/bugs/981130
<micahg> librados2 (from ceph) is seeded in:
<micahg>   kubuntu: dvd
<micahg>   ubuntu-server: daily
<SpamapS> kubuntu?
<SpamapS> Oh kvm
<micahg> librbd1 is as well
<SpamapS> right ok
<micahg> seeded-in-ubuntu FTW :)
<SpamapS> yeah I haven't tried that
<skaet> slangasek,   rt #52293 for those point release milestones.   FYI.
<slangasek> ok
 * skaet --> lunch
<cjwatson> skaet: why does milestone creation need an RT?  any member of the TB can do it
<cjwatson> actually, I thought release team could too, but TB certainly can
<skaet> cjwatson, both slangasek and I tried earlier.   Figured you were busy with the bugs.
<skaet> I'll forward you the details if you want to just take care of it.
<cjwatson> I'll do it when I'm back at my desk.  IS is contended enough that I think we should only bother them when necessary
<cjwatson> I can pick it up from RT
<skaet> cjwatson,  that will work.  Thanks.
<cjwatson> oh, bah, no permission to view ticket
<cjwatson> you should use the platform address so that doesn't happen :)
<cjwatson> please forward me the details, then
<cjwatson> (https://wiki.canonical.com/SysAdminRtUsageGuide#rt-queues)
<slangasek> cjwatson: both release team and ubuntu-drivers are shown as drivers on https://launchpad.net/ubuntu/precise/, but the button is missing for adding milestones; seemed like a LP weboppy thing from there
<cjwatson> I have an ajax thing for adding milestones
<cjwatson> perhaps it's because techboard owns the distribution
<cjwatson> silly permissioning if you ask me, but
 * skaet nods
<skaet> forwarding...
<slangasek> yeah, it's a regression in permissions vs. what we had previously then :)
<slangasek> skaet, cjwatson, ev: any of you know what's expected for the "Wubi upgrade" test case that's not already covered by the standard upgrade tests?
<slangasek> I'm not sure why we have that as a separate test, tbh
 * balloons is listening in
<ev> slangasek: If memory serves, we historically had a few upgrade failures that were specific to grub under wubi
<slangasek> ev: do you think that's still relevant now?
 * skaet applauds slangasek's effort to prune test cases out of manditory that don't add value ;)
<balloons> I guess that's our answer slangasek
<skaet> balloons,  we need to wait for ev's input,  but its the right question.  ;)
<balloons> skaet, well, I mean in theory it's different, but I was asking how much focus should we place on it compared to our other wubi fresh install testing
<ev> we landed the disk image stuff last cycle, so it hasn't been through a round of upgrade testing
<ev> I'd say yes, so long as I'm not volunteering at the same time :)
<skaet> ev,  we'll let balloons try to find a volunteer first ;)
<balloons> lol -- I have volunteers
<ev> oh thank goodness
<balloons> the question is to apply them to upgrade testing or new install
<ev> half and half please :)
<balloons> and I was asking slangasek for the old wubi versions to test them.. I'll have some folks go thru it
<ev> it's still pointed to from the website
<ev> the wubi binary, that is
<ev> from 11.0
<ev> 11.10 even
<slangasek> ev: is a full upgrade test the right thing to test?  Would it make more sense to ask for installing 11.10, then doing a test specifically for grub or kernel upgrades?
<ev> yeah, all I think that matters is that the thing boots
<slangasek> (faster, less affected by irrelevant bugs, etc)
<ev> does it pass grub does the kernel work
<ev> done
<phillw> slangasek: are the RC's still on cron-job for ~ 16:00 - 18:00 Thursday, or is it a manual build when you guys & gals are happy?
<phillw> (GMT)
 * slangasek redirects that question to skaet 
 * phillw offers skaet  cookies for an answer... :)
<skaet> phillw,  we'll leave the cron on tonight,  but it will redirect to release candidate milestone now.
<skaet> after tonight we're turning it off
 * skaet likes cookies....   thanks!
<phillw> I'll try and get some one at UDS-Q with paypal account and send some funds for cookies :)
<skaet> :)
<phillw> You'll be enjoying UDS-Q, i'll be on my final exmas.... fancy a swap?
<phillw> skaet: but joking aside, what sort of (GMT) do you expect the RC's to land on http://iso.qa.ubuntu.com/qatracker ?
<skaet> phillw,  look at the times of the ones today landed, and should be the same torrow.
<phillw> thanks, I'm GMT +5.5 over here, so time is a bit of a blur.
<skaet> We have more bugs than I'd like though right now, so manual respins should be expected.
<cjwatson> wubi upgrades have historically been a disaster, so (while I think we nailed most of the horrible ones a few cycles ago) I do think it's worth giving them some attention
<balloons> ev skaet, so i instructed to grab and install 11.10 wubi and then attempt a normal dist-upgrade to 12.04
<cjwatson> yeah
<balloons> and see if it boots :-0
<cjwatson> I don't care what the other packages do
<phillw> okay, that was the start of my email to the lubuntu-qa team.... "they will arrive, when they arrive, owing to -release wanting to get as many bugs squashed as is humanly possible".... Is that okay with you skaet?
<skaet> yup.  fair 'nuf.
<skaet> thanks phillw
<phillw> skaet: they're nagging :P
<skaet> phillw,  feel free to encourage them to start on today's dailies,  they're pretty close.
<skaet> to what will be there tomorrow.
<slangasek> how does this look? http://testcases.qa.ubuntu.com/Testing/Cases/WubiUpgrade
<cjwatson> milestones created now
<cjwatson> LGTM
<skaet> thanks cjwatson
<slangasek> balloons: ^^ if that description looks ok to you, I'll link it from the ISO tracker in place of what's currently there
<balloons> looks much nicer than before
<balloons> umm.. I was mentioning making some minor changes of your choice
<balloons> for extra flavor during the upgrade :-0
<skaet> slangasek,  looks good to me too.
<balloons> change desktop background, install an extra package.. otherwise it's exactly the same
<balloons> can you linky it?
<balloons> I've sent the links to the testcase.. they should all see your new version
<slangasek> testcase link fixed
<slangasek> balloons: so for the Wubi upgrade test case, I think we specifically want to limit the variables and not encourage making changes as part of the testing; the more holistic testing of other images already gives us that, for Wubi I'd rather we be short and to the point given that it's a challenge to get testing done at all
<balloons> slangasek, probably true
<balloons> noted
<slangasek> now for Wubi *install*, there are other paths worth testing
<slangasek> because there could be flavor-specific install failures
<slangasek> but the upgrade path, since what we care about is core common packages (kernel+grub), there's no sense throwing in sources of other possible bugs
<balloons> slangasek, yes.. so it's a different case than normal upgrade testing
<slangasek> stgraber: can you see any reason not to merge "Upgrade wubi i386" and "Upgrade wubi amd64" on the iso tracker?  They each have a single test case, and they're the same .exe anyway
<skaet> slangasek, stgraber - have added "Precise Pre-release" to the tracker, and updated nusakan to auto post to it.
<slangasek> ok
<skaet> stgraber, any problem if I do a test build and post images, while we still have the daily testing active?  (I figured turn off the Precise Daily just before the cron kicks in so we get as many results gathered as we can.
<slangasek> oh boo, stgraber is in the wrong timezone, guess I shouldn't expect a prompt reply and should just mangle the tracker horribly ;)
<stgraber> skaet: if we publish a candidate now we might as well turn of the dailies
<stgraber> skaet: as the dailies will have an older build
<skaet> stgraber, ok,  I'll hold off on testing.   Was just wanting to see if server had issues with all the recent changes landing, we could sort before EOD.
 * skaet wants to leave the dailies active until later.
<balloons> I have mentioned to everyone the dailies are live until tomorrow
<balloons> they won't be expecting a switch until then
<balloons> it would be good to leave them in place for now if possible
<skaet> hmm...  stgraber is it possible, or is it going to cause major issues with the database to have two milestones in testing.  (ie. Daily and Pre-release)
<skaet> ?
<stgraber> skaet: two milestones marked as testing is fine, I'm just worried about the confusion it'd create to have some builds in the final milestone and some others in daily
<skaet> no builds should be going to daily now.
<slangasek> balloons: wubi testing is now a single "product" on the iso tracker, cf. http://iso.qa.ubuntu.com/qatracker/milestones/204/builds/15333/testcases
<slangasek> with i386 and amd64 as test cases instead of as separate "products" 'cuz they aren't
<balloons> slangasek, did you break any links?
<skaet> we can turn off the daily after the publishing run tomorrow morning (your current time ;) ) and disable cron at that point.
<slangasek> balloons: nope
<skaet> that way,  folks can keep adding results across the timezones, rather than waiting for the cron to publish.
<balloons> ok good ;-)
<stgraber> slangasek: sorry, was just about to tell you it'll be a bit of a mess to do that specific change ;)
<slangasek> stgraber: doesn't look messy to me ;)
<stgraber> slangasek: because renaming the i386 product and dropping amd64 will break the history
<slangasek> well... I renamed the existing test case too
<slangasek> so it shouldn't break history too badly
<balloons> ahh  I see slangasek .. yea, we can turn off the other links after today's daily
<slangasek> it'll just change how it looks
<balloons> no reason to have upgrade wubi i386/amd64 anymore
<stgraber> slangasek: Sure but that just made it worse ;) if you now access the results from Oneiric, you'll see a Wubi product containing two test cases, only one of which has results and you'll see another Wubi amd64 product with a single testcase containing the remaining results
<ScottK> I'm pretty sure reviewing Wubi test case results from Oneiric is not on anyone's high priority TODO list.
<stgraber> ScottK: sure, but fixing the history later on will be even harder than fixing it now
<stgraber> ScottK: that's why my suggestion would have been not to do the change in the UI and let me move the results properly in the DB :)
<ScottK> Right.
<slangasek> stgraber: you can still do that now, if you like, yes?
<stgraber> slangasek: yeah, I'm trying to do that now
<slangasek> ok
<balloons> woot! a green label on wubi on the iso tracker
<skaet> :)
<stgraber> slangasek: done
<slangasek> stgraber: cheers
<slangasek> skaet: infinity's asked for an FFe to get the wubi fs image using ext4 instead of ext3; bug #859552 - this was blocked until this week by the livefs builders not having a new enough kernel to allow ext4
<ubot2> Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,In progress] https://launchpad.net/bugs/859552
<slangasek> skaet: I think we should do this so it's consistent with the defaults elsewhere - and in light of the wubi community testing, the sooner the better
<slangasek> balloons: ^^
<balloons> oh my
<balloons> wow
<balloons> SO late
<slangasek> yes
<infinity> Yep.
<infinity> The timing wasn't my choice, really. :P
<balloons> I don't see what we lose by staying with ext3?
<slangasek> balloons: the only thing it changes is the filesystem... which should really be a pass/fail thing
 * slangasek yields the floor to infinity 
<balloons> yes.. and ext4 isn't really new anymore, most of it's craziness with data loss etc has been wrapped up for years now
 * ScottK votes for wubi with btrfs.
<slangasek> wubtr
<cjwatson> arwubtrf
 * slangasek chokes
<slangasek> balloons: so am I reading you right that you think changing this now would make it a problem to get it re-tested?
<slangasek> because if so, I think that's the nail in the coffin for .0
<infinity> I should hope not...
<balloons> slangasek, I don't think it's a problem persay
<slangasek> ok
<infinity> If we can't retest wubi in the next week, we have bigger problems (like, if anything else changes)
<balloons> but most of the testing we're doing today is with ext3
<balloons> that's all
<balloons> :-)
<infinity> balloons: Sure, but will you even notice the change? ;)
<balloons> shouldn't nope
<slangasek> balloons: as long as there are *some* people still willing to help (re)test late today or tomorrow, I think that would cover us
<balloons> but i guess the testing won't be as crazy after this with wubi tis all
<balloons> we'll have a good poke tomorrow
<infinity> (As to "data loss crazines" and such, ext4 has been the default filesystem for all our other images for a long while... Which is the motivation to make wubi match; wubi's our only ext3 consumer, and it's a tiny subset)
<balloons> so get it in by then :-)
<slangasek> yeah, that's not a problem
<slangasek> I think we can have the ext4 image rolled up in <1h
<slangasek> infinity: is that right?
<infinity> slangasek: Or 1.5... It takes an upload/build/publish-cycle, thanks to something being hardcoded in a live-build patch.
<slangasek> ok
<infinity> But after that, yeah, one quick revert on cdimage, and I can spin test images.
<slangasek> balloons: so we can have the change in 2 hours, and can revert it in another 2 if need be
 * infinity goes to find a coffee, so he can deliver on this.
<balloons> slangasek, so are we going to get a new wubi.exe?
<slangasek> balloons: still waiting for skaet to comment
<infinity> wubi.exe doesn't need to change.
<infinity> Just the images.
<slangasek> oh, right
<slangasek> balloons: we will *hopefully* be getting a new wubi.exe as well, but definitely not today
<infinity> (and not related to this)
<slangasek> correct
<slangasek> ev: was there a bug number for the autorun issue?
<ev> slangasek: https://bugs.launchpad.net/wubi/+bug/985050
<balloons> so are the dailies getting vanquished early, or are we still ok?
<ubot2> Launchpad bug 985050 in ubuntu "A Downloaded Wubi binary shows the autorun menu if an Ubuntu cd is inserted" [High,New]
<infinity> slangasek: Looks like it'll be livefs afternoon for me, sulfur's getting set up too.
<slangasek> balloons: still ok
<slangasek> infinity: alrighty :)
<slangasek> bug #985190
<slangasek> boo
<slangasek> hmm, no bugbot
<slangasek> or none that loves me anyway
<slangasek> oh, that plymouth crash is a drm crash - yaay, I can pass the buck ;)
<infinity> Hahaha.
<phillw> balloons: is release on tuesday or thursday of next week?
<infinity> Thursday.
<phillw> infinity: can you give balloons a reminder :P
<balloons> infinity, phillw ? lol
<balloons> did I say release was Tuesday?
<balloons> if so -- tell me where, I've known it was thursday
<phillw> balloons: just as well meeting was not cancelled... it is now D-Day minus one :)
<balloons> that was a mistype :-)
<balloons> ohh -- did I say it in the qa meeting?
 * infinity should have made the wubi live-build hook autodetect targets, so he didn't have to upload a new version to change this.
<balloons> if so, it's on tape so to speak :-0
<phillw> yes, you did!
<balloons> slangasek, http://testcases.qa.ubuntu.com/Install/DesktopWubi can you update this at all? it's pretty cd-centric
<balloons> phillw, gotta watch this balloons guy
<ev> right, wubi is fixed as http://people.canonical.com/~evand/wubi/precise/wubi-r265.exe
<ScottK> doko: Here's a question for you: Why is /usr/bin/pyversions in python and /usr/share/python/pyversions.py and /usr/share/man/man1/pyversions.1.gz in python-minimal?  It seems like /usr/bin/pyversions should be in minimal with them.
<ev> skaet: ^ I've asked IS for it to be signed - that might have to wait until tomorrow when Spads is around
<slangasek> ev: thanks
<ev> as far as I can tell, that behaviour has been there for ages
<ev> my initial suspicion that it was the result of my autorun fix was wrong
<ev> slangasek: sure thing
<slangasek> balloons: hmmm, better if someone who knows it better can edit that one
<slangasek> balloons: though certainly the first test case there has become irrelevant because we no longer offer it from CD...
<infinity> slangasek: Fresh live-build uploaded with the wubi/ext* revert/re-apply.  Can be accepted once we have consensus, I guess.
<infinity> (Or rejected, if not)
<balloons> slangasek, yes, essentially the cd based ones can all be gutted right
<doko> ScottK, hmm, don't know a reason, and I can't remember that this is intentional
<balloons> does the cd boot helper still exist? is it possible?
<slangasek> balloons: I don't know if it does or not... needs someone with Windows running to verify ;)
<ScottK> doko: I can see some potential for race conditions when the two packages are in different states (I'm not sure).  Is it worth changing?
<balloons> slangasek, lolololol
<doko> ScottK, I don't think so, but if you want, go ahead
<ScottK> I won't mess with it for precise then.  I'll do it in Debian.
<ScottK> (then Ubuntu will get it in Q)
<tyhicks> I've attached a simple debdiff to bug 935407 to fix the refpolicy-ubuntu (in universe) FTBFS on Precise. I think it is a good candidate for a FFe.
<ubot2> Launchpad bug 935407 in refpolicy-ubuntu "refpolicy-ubuntu version 0.2.20091117-0ubuntu1 FTBFS on i386 in precise" [High,In progress] https://launchpad.net/bugs/935407
<micahg> tyhicks: bug fixes don't need an FFe
<tyhicks> micahg: Ah, thanks. I'll ping you privately for the next steps.
<Laney> ^ FTBFS fix. Probably needs FFe.
<infinity> skaet: Did you have an opinion on https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/859552 ?
<ubot2> Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,In progress]
<infinity> Laney: That's quite a version bump for an FTBFS.  Does it have impact on rdeps?
<infinity> (does it have rdeps?)
<infinity> I'm assuming from the package name that it does. :P
<Laney> no, it's just a frontend to the cabal library
<Laney> think gem
<infinity> Ahh.
<infinity> And eww.
<Laney> yes
<slangasek> gem, except written by someone who actually worked on a distribution
<highvoltage> heh
 * infinity wonders why the other language folks never got on board with the Debian/Perl ideal of "if it's in CPAN, and it's not in Debian, it's not worth using".
<Laney> ah, it will make haskell-platform uninstallable
 * Laney fiddles in Debian
<ScottK> infinity: Python and Pypi seems to be getting there.
<slangasek> doko: bug #983981> why would you assume the new python-minimal is unpacked at that point?
<ubot2> Launchpad bug 983981 in update-manager "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,New] https://launchpad.net/bugs/983981
<slangasek> doko: there's nothing in the python2.7-minimal dependencies that says python-minimal should be unpacked first
<slangasek> doko: maybe python2.7-minimal needs a Breaks: python-minimal (<< $our_ver)?
<ScottK> doko: I moved /usr/bin/pyversions to python-minimal in Debian.  If you end up having to upload for that ^^^ then I would suggest doing the same for precise.
<skaet> infinity,  would prefer slangasek and ev weigh in.    I want it in principle, but not sure we can react to making it happen in time.  Want to make sure all the blockers are fixed first.
 * skaet appologizes was otp
<slangasek> skaet: ev and I have weighed in already in favor, but wanted to make sure you were in the loop
<infinity> skaet: slangasek and ev have both already weighed in.
<infinity> What he said. ;)
<slangasek> infinity: so go ahead, and coordinate with balloons wrt the timing
<infinity> slangasek: Alright, accept my live-build upload, then? ;)
 * infinity goes back to fiddling with nusakan and sulfur for now.
<slangasek> righto
<skaet> slangasek, infinity,  thanks for making sure I'm in the loop.   :)
<skaet> slangasek,  did someoneles already accept the apport change?
 * skaet not seeing in the scroll back??
<slangasek> I don't know
<skaet> its not on the queue... or I'm blind.
<ScottK> In proposed?
<slangasek> scrollback here tells me pitti rejected the upload to -release and re-sent it to -proposed
<ScottK> There's an apport in proposed.
<slangasek> yep
<skaet> cool.  Thanks!
 * skaet accepting kerneloops
<skaet> slangasek, could you copy it into -release
<skaet> ?
<ScottK> ^^^ was due to FFe still in progress.
<ScottK> You may see it again if we decide it's a good idea.
<skaet> ack.
<ScottK> Laney: ^^^ for the same reason.  Until you're sure it's all sorted, I don't want it in queue and getting pushed through by mistake.
<Laney> ScottK: I was just dputting a fakesync of the platform
 * ScottK is looking at kubuntu-docs.
<Laney> maybe not fake sync, a --no-lp sync
<ScottK> Laney: OK.  We should be able to rescue it from rejected.
<Laney> yeah.
<skaet> infinity, could you take a look at the openssl one if you get a chance?
<ScottK> Kubuntu images will need respins for kubuntu-docs if nothing else.
<cjwatson> openssl is only for release if manual testing checks out in time.
<cjwatson> But I uploaded it to -proposed and it should be able to go in there any time.
<slangasek> skaet: apport copied
<skaet> cjwatson,  sorry - didn't see it on the wiki page.   Adding it now.
<ScottK> Laney: Accepted.
<ScottK> (platform)
<Laney> they both need to go in together ...
 * Laney is just writing the FFe
<cjwatson> skaet: not sure I put it there, mentioned on IRC earlier
<ScottK> Laney: FAILED: haskell-cabal-install (Can't resurrect rejected syncs)
<infinity> skaet: On it.
<ScottK> You'll need to sync it again.
<Laney> hah
<slangasek> infinity: see intervening discussion between cjwatson and skaet, openssl is not ready to be copied
<skaet> cjwatson,  IRC context fails with the volume of traffic,  hence pad desire in first place.     Sorry I missed it in the backscroll.
<infinity> slangasek: No, but still ready to be built in proposed.
<slangasek> oh
<Laney> ScottK: coming up
<infinity> slangasek: (Assuming it looks not broken)
<Laney> and that is it for me â goodnight
<slangasek> right, I misunderstood and thought it was already in proposed
<infinity> Patches look sane.
<skaet> good night Laney,   sleep well.
<cjwatson> slangasek: it's not in -proposed yet, no
<infinity> cjwatson: Is now.
<slangasek> :)
<cjwatson> skaet: sure, I was acting with an ordinary developer hat on, not a release team hat on
<skaet> :)
<cjwatson> skaet: we don't expect developers to edit the pad AIUI
<infinity> cjwatson: I'd say developers can certainly edit to say "Don't copy this without testing feedback" or other negative comments.
<infinity> cjwatson: It's developers editing to encourage accepting things that would be a bit unfortunate. :P
<slangasek> can but are not expected to
<cjwatson> indeed
<infinity> Oh, sure.
<skaet> infinity,  while I'm cleaning things up,  python-defaults went in - yes?
<infinity> skaet: Nope.  it built everywhere, but it's still in -proposed.
<infinity> There seemed to be some dissent among the ranks about what should happen to it.
<ScottK> skaet: I thought it was waiting for doko to do a lucid upgrade test with it.
<ScottK> (when last we discussed it)
<skaet> Thanks ScottK - that was it.  Long day
<skaet> will update wiki to denote that.
<slangasek> ^^ apt-setup accepted (discussed it with cjwatson already)
<infinity> cjwatson: How many of the uncommitted changes in ~cdimage/cdimage are yours?  I'm trying to tidy up a bit.
<cjwatson> infinity: none of them are anything I remember clearly enough to give you a rationale for
<cjwatson> not certain whether they're mine or not
<infinity> cjwatson: I've backed out one that was vorlon testing things, and one that was me.
<infinity> cjwatson: The rest seem like "if they work, they should probably be in bzr".  Just trying to hunt down authors. :P
<infinity> balloons: So...
<infinity> balloons: wubi/ext4 ... Assuming it's cool with you, I'm going to spin up images somewhere in the area of "now", and make sure the builds go okay.
 * skaet --> dinner,  back to check on the cron builds later
<infinity> balloons: (Alternately, if you don't respond, I can probably safely assume you don't mind terribly if I do so while you're away) :P
<skaet> infinity,  I think he's away from terminal for a while
<skaet> so go ahead.
<cjwatson> I think I have a fix for bug 979350 now
<ubot2> Launchpad bug 979350 in ubiquity "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Confirmed] https://launchpad.net/bugs/979350
<infinity> skaet: Oh, one more thing.  If I take ownership of testing it, do you mind if I turn on ubuntu-core for powerpc, now that we have a faster PPC builder (it's a tiny/quick build anyway)
<cjwatson> it only squeezes into memory if you don't run ubiquity from a live session
<cjwatson> but given that constraint it seems to be working
<infinity> cjwatson: So, it'll still fail is running from the desktop?
<skaet> infinity,  ok with it being in the dailies, but it hasn't participated in the betas, so shouldn't be part of release.
<infinity> cjwatson: Is ubiquity smart enough to know if it's running under ubiquity-dm, and not offer options that might fail? ;)
<cjwatson> infinity: it did in my tests, anyway
<cjwatson> it doesn't have exact enough knowledge about memory constraints
<infinity> skaet: It has, by virtue of being the base of everything else that's been in the betas.
<cjwatson> One of the purposes of ubiquity-dm is to be a bit more memory-lean
 * infinity nods.
<skaet> yeah, but not as its own image.   From discussions earlier in the cycle it was agreed to ship, it must have been in a beta.
 * skaet needs food.... l84
<infinity> *sigh*... I won't enable it at all, then.  Dailies are kinda pointless when they all get wiped out post-release. ;)
<cjwatson> All due respect but this is a daft policy in this case.  The Ubuntu Core "image" is a tarball ...
<cjwatson> If tar is breaking we have bigger problems.
<infinity> Indeed.
<cjwatson> I agree that the policy makes sense in general; but this seems like a common-sense exception.
 * ScottK votes the must be in the beta rule applies to images, not tarballs.
 * cjwatson tries this test again with a bug fixed so that it really enables the encrypted swap during installation.  Not that it's vital, but it might let the test finish this century.
#ubuntu-release 2012-04-19
<infinity> cjwatson: Is there a reason your user-setup has been stuck in the queue for 8 hours, or has it just not had a review?
<cjwatson> the latter, but it's about to have another upload anyway
<cjwatson> soon as I've stopped mucking up the tests
<infinity> Heh, kay.
<cjwatson> and the one in the queue is actually wrong, it's passing the wrong args to mkswap/swapo
<cjwatson> missing /dev/mapper/
<cjwatson> n
<infinity> Ahh, there's not enough context in the diff to make that ovious.
<infinity> Nor obvious.
<infinity> In fact, I'm missing context entirely here, cause from the small bit above, it seems like you should just be mkswapping $device.
<cjwatson> $device is the unencrypted one
<cjwatson> /dev/mapper/$name is the encrypted one
<infinity> Blowing away the physical volume backing an excrypted volume doesn't upset the higher level bits?
<cjwatson> Nothing's doing anything withit yet
 * infinity is woefully ignorant about how all this works, I guess.  I would have assume magic blocks or something.
<infinity> s/assume/assumed/
<infinity> cjwatson: Well, yeah, it's obviously not mounted, I just meant "there's nothing actually there?"
<infinity> Like, if this were a raid volume, "mkraid && zero physical && mkfs raid" would end badly.
<cjwatson> ah, um, *cough*, I think something needs to call cryptsetup
<cjwatson> sigh, this is going to be a late night isn't it
<infinity> Maybe I should read the code instead of the 5 lines of context. ;)
<cjwatson> it needs to be more like mkswap && cryptsetup && swapon
<cjwatson> err
<cjwatson> zero physical && cryptsetup && mkswap && swapon
<infinity> zero && cryptsetup && mkswap && swapon
<infinity> Yeah, that. ;)
<infinity> cjwatson: I assume it's prohibitively expensive to zero the crypt device?
<infinity> Cause that would actually be more secure.  Encrypted zeroes would do a ton more unrecoverable damage to the underlying data.
<cjwatson> Maybe I should be using cryptdisks.functions here.
<cjwatson> AFAICT it's a myth that the kind of data you write makes any difference.
<infinity> On magnetic media, it's fairly provable, isn't it?  Writing pure zeroes can still keep the old ones ghosted.
<cjwatson> There's an unclaimed prize for anyone who can actually do it.
<infinity> Writing randomly doesn't eliminate ghosting, but it sure makes it tougher to figure out what's "old".
<infinity> But this is probably NSA level recovery we're talking about, not average joe plugging in a hard drive and fishing.
<infinity> Like, you'd have to tear apart the physical disks and examine them.
<infinity> So, probably a non-issue. :P
<cjwatson> There was a paper a few years ago which gave the probability of recovering any single bit as 56%.
<infinity> That's bigger than zero!
<infinity> And therefor, not in the realm of CSI image enhancement.
<cjwatson> Now exponentiate ...
<infinity> But more in the realm of "really, really hard".
<cjwatson> Now where was the good article I found about this
<infinity> I agree, in practice, however, that being anal about how you shred disks is probably pointless.
<infinity> I just brought it up because I know there are anal people out there. :P
<infinity> That said, those anal folks probably shred their disks before installing.
<cjwatson> Possibly http://www.infosecisland.com/blogview/16130-The-Urban-Legend-of-Multipass-Hard-Disk-Overwrite.html
 * infinity will read this when he's done with sulfur.
<cjwatson> the WRIG08 citation there (which I haven't followed) is summarised as "a single overwrite using an arbitrary data value will render the original data irretrievable even if MFM and STM techniques are employed"
<infinity> lamont: Can you put openssl in precise-proposed through some abuse?  I know you were one of the people who had previous issues.
<infinity> cjwatson: Sure, but that "arbitrary" almost seems to imply random.
<infinity> cjwatson: I'm not disputing that multipass is silly, I'm claiming that writing pure zeroes will leave obvious ghosting.  That's simple electrical theory.
<cjwatson> My reading of the summary is that no matter what value you pick the probability of recovering anything useful is negligible.
<infinity> Hrm.  There's no sane way to parallelise the livefs log mirroring without making the script a lot more clever. :/
<infinity> Oh, wait.  It doesn't delete.  I guess it doesn't need to be clever.
<ScottK> Should the user-setup in the queue be rejected then?
<cjwatson> yeah
<skaet> infinity,  am spotting most of the builds not working from the daily cron.   Can you look into it?
<skaet> srv/cdimage.ubuntu.com/bin/find-live-filesystem: 104: Syntax error: ")" unexpected (expecting ";;")
<infinity> Woo.
<infinity> Go me.
<infinity> I tested buildlive, but not find-live.  Fixing. :P
<skaet> Thanks
<infinity> Oh, lolz.
<cjwatson> Heh, I was just fixing that
<infinity> I beat you to it. :/
<infinity> Unless you found more than the 4 spots I missed?
<cjwatson> nope
 * cjwatson misses one checkbox and has to redo a ten-minute test
<cjwatson> gah
<cjwatson> ^- reverts problem infinity spotted, introduces new paths which are a no-op without a ubiquity change to add a magic environment variable but are a prereq for fixing bug 979350
<ubot2> Launchpad bug 979350 in ecryptfs-utils "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [Undecided,Fix released] https://launchpad.net/bugs/979350
<skaet> Riddell, ScottK,  am still missing support timeframe for some of the Kubuntu images in the manifest.   Could I get you to update please and signoff that the plubishing locations/etc. are correct.
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<infinity> skaet: Oh, did you catch backscroll, re: core?
<infinity> skaet: http://paste.ubuntu.com/936297/
<infinity> Also, sulfur's alive as a 3rd PPC buildd.  Should try to aim large/scary packages at it, as it's got twice the CPU power as the other two.
<skaet> infinity, looking forward to seeing a speedup on those PPC builds.    If I trigger some manual runs, will pull the timings
<cjwatson> skaet: It's not a livefs builder.  It turned out not to speed things up, unfortunately.
<infinity> Yeah, what he said.
<cjwatson> skaet: So infinity's made it another package builder instead, since it actually is faster at that.
<infinity> I did test runs of sulfur against royal, and they both did ubuntu-live within ~30s of each other, so opted to make it a distro builder instead, where the CPU and RAM won't go to waste.
<slangasek> rejecting that first user-setup that seems to have not actually been rejected yet
<cjwatson> A disappointment, but there you go.
<cjwatson> And a third package builder will certainly help in a number of cases.
<slangasek> infinity: CPU and RAM> heh, but not enough to put the whole build on a ramdisk?
<skaet> re: PowerPC core images - lets just look at it as an option for 12.10.   Don't have a good feel there is demand/need for 12.04 and enough things broken I'd rather focus on getting fixed.
<infinity> slangasek: Only 4G... Not sure what the biggest PPC image is, pre-compression, but I know that wouldn't cut it for x86.
 * skaet looks at http://iso.qa.ubuntu.com/qatracker/milestones/204/builds/15572/testcases/1186/results/
<infinity> skaet: It's a 7-char patch to a file I'm already looking at, and I'm committing my own time to "testing" (which for core, is about 30 seconds) it.
<skaet> infinity,  yes, but there is the tracking, documenting, etc. associated with it.   Haven't heard who will use it either....
<infinity> Docume... What?
<infinity> We have one doc for core, it's not per-arch.
<skaet> UbuntuCore is a product set
<infinity> Yes...?
<skaet> whether it should be or not.... probably need revisiting
<cjwatson> What's a "product set"?
<infinity> As for "who would use it", it's the same group as use core for other arches.  Which is "amost nobody, until someone realises they really, really want it."
<skaet> What's on the manifest
<skaet> is a product set in my mind.
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<skaet> There's already armel for 12.04
<cjwatson> I guess I'm not sure how that has any bearing on adding powerpc to it.
<infinity> I would just add powerpc to the armel set there.  And both should be unsupported, not 18 months.
<infinity> And I should probably be the signoff for both, since I'll be the one testing them anyway. :P
<skaet> Please go update it to mark it as unsupported
<infinity> Will do.
<slangasek> infinity: is bug #985258 something that warrants fixing?  Smells like it might be a product of the preinstall images having a pre-populated apt cache
<ubot2> Launchpad bug 985258 in tasksel "[omap4] tasksel shows seeds unavailable in the preseed image" [Undecided,New] https://launchpad.net/bugs/985258
<infinity> If I accidentally misspell unsupported as "powerpc || unsupported", is that cool? ;)
<infinity> slangasek: It's an involved fix.
<infinity> slangasek: Honestly, I've heard not a single customer tell me that the preinstalled pool was useful to them, I'm almost tempted to just drop it and make the server image small.
<skaet> infinity, find me someone who will use it, and then you can make your spelling mistake
<infinity> slangasek: (Lots of people complain about the size, no one praises the package pool).
<infinity> skaet: Me.
<slangasek> infinity: it doesn't make sense for armel to be regarded as a community architecture when there's no community for it... we're carrying it for our own purposes
<cjwatson> So these preinstalled images use oem-config for the "installation", right?  Just trying to understand bug 985305
<ubot2> Launchpad bug 985305 in ubiquity "[omap4] /etc/network/interfaces not created on a no-network installation" [High,New] https://launchpad.net/bugs/985305
<infinity> slangasek: There's actually a reasonably large community for it (though, true, I hope they all move to armhf some day)
<slangasek> cjwatson: yes
<skaet> infinity,  but I know you can build it directly any time you need.   ;)   Someone else please.
<infinity> skaet: I could build it on Canonical infrastructure, sure.  A bit harder to build it locally when I'm suffering from chicken/egg issues of a machine that can't use installer/boot media and needs a rootfs to make a rootfs.
<slangasek> infinity: there's a user community, but that's not what I mean; we kept armel as an arch for nefarious purposes, not due to community demand
<jbicha> nefarious?
<infinity> skaet: (This isn't theoretical, I just used a PPC rootfs to reinstall one of my systems yesterday, and I had to use a launchpad chroot tarball...)
<slangasek> jbicha: best to assume everything involving ARM is nefarious, it's simpler that way ;)
<infinity> slangasek: Sure.  I'm not sure what we're arguing about, though.  That we should list armel-core as supported?
<slangasek> infinity: yah
<infinity> Not everything "done by Canonical" is "supported", but alright.  If you know something I don't about why we want to give core 18mo. :P
<slangasek> I don't know anything you don't, just framing the question differently
<cjwatson> bug 985280 - if this is release-critical then somebody with omap4 stuff set up is going to have to fix it
<ubot2> Launchpad bug 985280 in ubiquity "[omap4] Package installation completely fails silently if no network is available" [High,New] https://launchpad.net/bugs/985280
<slangasek> I'm skeptical of that being RC
<slangasek> what kind of server has no network?
<cjwatson> dunno, I said "if" :)
<slangasek> yep :)
<cjwatson> bug 985309 - how did this use to work?  Was there some component that sorted out fstab?  I don't think oem-config has ever done so
<ubot2> Launchpad bug 985309 in ubiquity "[omap4] /etc/fstab still has warning "UNCONFIGURED FSTAB FOR BASE SYSTEM", and is inconsistent with options" [Medium,New] https://launchpad.net/bugs/985309
<cjwatson> I vaguely recall some kind of refactoring ...
<slangasek> infinity: how does the preinstalled package pool relate to tasksel showing tasks that aren't available?
<cjwatson> I'm going to upload ubiquity now with user-setup 1.42ubuntu3 included, since I can't really wait any longer before bed, and it's closely tied up with a fix there
<slangasek> ack
<infinity> slangasek: Oh, erk, I only half-read the bug.  It doesn't at all.
<cjwatson> for source consistency, they should go together or not at all, although there's no run-time or build-time relationship
<infinity> slangasek: Actually, I'm really confused by what's happening here at all.
<slangasek> cjwatson: user-setup accepted now anyway
<infinity> slangasek: He claims it's a server image.  The server image has confusingly weird task issues (generally, the lack of tasks, not new ones)
<cjwatson> thanks
<cjwatson> kinda sounds like a missing apt-get update or something
<infinity> slangasek: Right, so I re-read the bug.  Basically, he's complaining that live images have the archive's Packages files.  I'm having a hard time considering that a bug.
<slangasek> don't we prune the archive's Package files from all the other live images?
<slangasek> I thought we generally regard them as a waste of space until proven networked
<slangasek> hmm, nope
<slangasek> -rw-r--r-- 1 root root 8099662 Mar 24 22:43 /mnt/install/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_binary-i386_Packages
<slangasek> so yeah, that seems not-a-bug?
<infinity> They may be a waste of space, but redownloading them is a waste of time and bandwidth.  Take your pick.
<slangasek> if you configure a different mirror than the default, it becomes a waste of all three ;)
<slangasek> but yes
<infinity> (And on a release image, they should be identical to the archive)
 * slangasek nods
<infinity> Assuming no mirroring, yeah.
<infinity> I dunno, cleaning those might be a good thing, but I don't want to know what breaks a week and a day before release.
<infinity> We probably used to in the livecd-rootfs days.
<slangasek> I'm not proposing that as a change now, no
<infinity> Yeah, we cleaned those in livecd.sh.
<slangasek> I was only asking about consistency with the other live images
<infinity> So, another thing to look at "later".
<infinity> But there's nothing inconsistent here, except that it's inconsistent with d-i images.
<cjwatson> I think I explicitly talked about that during the switch to lb
<infinity> Which is unavoidable, I imagine.
<slangasek> cjwatson: as a feature or a bug?
<cjwatson> feature
<slangasek> ok
<cjwatson> having trouble finding anything concrete though
<cjwatson> Can't find it.  Maybe it was a hallucination.
<cjwatson> But I've a feeling that other space tradeoffs meant that live-build was still a space win, and that this meant software-center worked more gracefully.
<cjwatson> Because it could display more things without needing an update first.
 * slangasek nods
<infinity> Yeah, having things in s-c/apt-cache seems like a win.
<infinity> And tasksel offering offline tasks is fine.
<infinity> But the bug about tasksel silently pretending everything went fine when you have no network sounds like a legit bug.
<cjwatson> Yes.
<slangasek> ubiquity accepted
<ScottK> skaet: I'm not sure I know all the answers.  I'll try to confer with Riddell on it tomorrow.
<skaet> thanks.  :)
<ScottK> skaet: It seems likely that we'll have some significant post-release updates to improve how Kubuntu Active is working.  I'd like to ask to get Kubuntu Active done for 12.04.1 as well even though it's not LTS.  We did it similarly for Kubuntu Netbook for 10.04.1 and we have testers.
<ScottK> Riddell: ^^^
<slangasek> infinity: did wubi happen?
<slangasek> infinity: doesn't seem to've, I don't see anything new in wubi/
<infinity> slangasek: Oh, I can spin it now.
<slangasek> thanks
<slangasek> want to make sure that's ready for balloons' testers
<infinity> slangasek: Though, it dailifies in 3.5 hours.
<infinity> Unless we're turning off cron before then.
<balloons> slangasek, fyi.. 4 reported good on iso tracker I see
<infinity> (I should spin a test build anyway)
<balloons> for wubi
<slangasek> balloons: cool
<slangasek> infinity: I'd do it now anyway, so anyone testing gets the new one
<infinity> slangasek: Check.  Doing.
<infinity> ... and this is where I find out that kapok and cadamom still don't support ext4, just wait for it.
<infinity> ^-- slangasek, balloons
<slangasek> infinity: could you escort that over to 'daily' by hand from 'pre-release', so that the testers are going to find it?
<infinity> slangasek: Err, oh, we're mangled out publishing?  I missed that memo.
<infinity> Oh, just the iso tracker.
<infinity> Right.
<slangasek> yes
<slangasek> doko_: in case you didn't know already, the architecture changes for bug #934593 are insufficient to make python-dev usable for cross-building
<ubot2> Launchpad bug 934593 in python-defaults "python-all-dev, python-dev must be Arch: any for multiarch" [Medium,Fix committed] https://launchpad.net/bugs/934593
<slangasek> doko_: doesn't hurt to have them Arch: any though, and that needs to be done eventually... so the main thing is to ensure we've got proper upgrades from lucid
<ScottK> ^^^ was me.
<ScottK> I shouldn't have synced it (didn't realize it was seeded)
<ScottK> slangasek: We also need to do something to provide /usr/bin/python2 since doko removed it from python2.7 (where upstream provides it) with the intent to provide it from python-defaults.
<micahg> ScottK: thanks for that :), it's not needed anyways
<ScottK> (yes, which I also failed to check)
 * micahg should've commented on the RC page
 * micahg does that now
<slangasek> ScottK: that's the relevant part of the python-defaults in -proposed
<ScottK> It's marked not important already, but if you'd fix the comment, that would be good.
<micahg> ScottK: I don't think I can
<slangasek> ScottK: so if someone verifies that it upgrades cleanly from lucid, I'll happily copy that to -release
<ScottK> slangasek: There's also the bug you assigned to doko dealing with having the new pycompile available.
<ScottK> IIRC doko was going to do that.
<micahg> ScottK: without bugging someone to run SQL, won't matter anyways as we have no diff
<slangasek> yeah; that one appears to need a python2.7 upload though
<ScottK> slangasek: Are we getting to the point where I should start leaving one unseeded package in queue to stimulate a publisher run if needed?
<slangasek> hmm, I'm not sure if that's still needed
<ScottK> OK.
<slangasek> cjwatson: ^^ how much have your publisher changes from this cycle made this a non-issue?
<ScottK> It'd be good to know.
<ScottK> I'll leave accerciser there for now in case.
<ScottK> Time for me to go to sleep.
<infinity> The last run didn't publish any binaries, but still updated all the metadata.
<infinity> Did this really not work in the past?
<slangasek> yes, it really didn't
<infinity> Oh, wait, no.  I lied.
<infinity> It still doesn.t
<slangasek> ok
<infinity> It generated some random uninteresting metadata. :P
<slangasek> then the only improvement is that we only need one package instead of two :)
<infinity> ... and I have no idea why.
<infinity> It should be borderline trivial to just make it unconditionally regenerate for devel/frozen releases.
<infinity> Then again, a lot of things that should be trivial in soyuz turn out not to be....
<pitti> Good morning
<pitti> skaet: apport> see wiki, I found that this is quicker (and it could already build)
 * infinity rearranges arm image builders again to account for timings of certain arches.
 * pitti wonders what we'll do with the remaining uploads now -- can we still accept good ones, or is everything going to be an SRU now?
<slangasek> that's meant to be taken case-by-case, surely?
<pitti> of course, but I'm still unsure how strict skaet wants to take the "yesterday's images are candidates"
<pitti> for example, the indicator-datetime fix looks perfectly reasonable
<micahg> can someone look at the cairo-dock-plug-ins upload?  it fixes an upgrade
<pitti> libnfsidmap, too
<infinity> pitti: We might be entering the "queue up reasonable updates, and accept them with urgent ones" phase.
<pitti> *nod*
<infinity> pitti: Where I'm sure indicator-datetime will probably get in anyway, but best to make sure it's getting in with something more awesome. :P
<slangasek> pitti: yesterday's images aren't candidates, though
<slangasek> apport was accepted in the past 24h
<pitti> slangasek: ah, I thought skaet wanted to spin images in  her evening
<pitti> but seems she didn't
<slangasek> I believe they've been left to be done by the cronjob
<slangasek> pitti: anyway, there's a ubiquity in -proposed right now, so real candidates should certainly wait until we publish that... so if you think some stuff in the queue is borderline on whether it would block the release, now's probably a good time to accept
<pitti> indicator-datetime and libnfsidmap both look good to me
<pitti> slangasek: do you know the current status of python-defaults?
<slangasek> pitti: someone needs to do an upgrade test with it; but that's somewhat blocked right now by bug #983981
<ubot2> Launchpad bug 983981 in python2.7 "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,Triaged] https://launchpad.net/bugs/983981
<slangasek> ubiquity published
<pitti> should we push openssl, too? or keep for SRU?
<slangasek> see the pad
<slangasek> er, the wiki
<slangasek> https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus
<pitti> right
<micahg> do we have any need for gcc-4.7 patches in precise?
<pitti> micahg: at this point IMHO they pose more risk than good
<micahg> pitti: figured as much, thanks
<micahg> pitti: do manpage updates qualify for SRUs?
<pitti> micahg: fine for me
<micahg> it's for mountall :)
<micahg> https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/100305
<micahg> pitti: ^^ if that's ok, can I upload now to -proposed or should I just leave a note to upload after release?
<pitti> micahg: it's ok to upload to -proposed now
<micahg> k, thanks
<micahg> pitti: wait, that'll be an SRU then, right?
 * micahg wants to know whether or not to open a bug task :)
<pitti> yes, isn't that what you asked about?
<pitti> right, you'll need a bug to track it
<micahg> it has a bug, I'll take care of it, thanks
<micahg> do we need UIFe's post release for SRUs?
<Riddell> micahg: yes, same rationale as before release
<pitti> micahg: yes, feature and UI freeze are never lifted again
<micahg> ok
<stgraber> good morning
 * micahg wonders why the casper bzr history is weird
 * infinity grumps at https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985452
<ubot2> Launchpad bug 985452 in apt "apt-ftparchive fails on scanning large repositories" [Critical,New]
<stgraber> micahg: can you define "weird"?
<stgraber> micahg: I think I'm touched-it-last, so I'm interested ;)
<micahg> stgraber: http://paste.ubuntu.com/936574/
<micahg> stgraber: let's move this to -devel
<Cimi> pitti, ping
<pitti> hello Cimi
<Cimi> ciao Martin
<Cimi> there's a regression in unity 5.10.0 which causes a slow slow dash, especially fullscreen
<pitti> right, I saw the discussion in scrollback
<Cimi> ok
<pitti> I thought it was already settled for SRU?
<Cimi> yes
<pitti> I don't see why it shouldn't be fixed, there will certainly be more fixes to Unity anyway
<Cimi> but after seeing the regression live, I thought this should have been in 12.04 not in the SRU
<Cimi> the fix is again a revert of the broken commit
<Cimi> and a queue_draw on the right widget
<pitti> the first time you open the dash it indeed takes very long, but that's hardly new?
<Cimi> can be related to this bug as well
<pitti> it's been like that since natty at least
<Cimi> surely with this bug takes _longer_ than it should
<Riddell> pitti: calligra-l10n in unapproved for your reviewing pleasure if you can
<Cimi> pitti, this is the commit I'd definitely cherry-pick https://code.launchpad.net/~andyrock/unity/fix-980924/+merge/102200
<pitti> Riddell: AFAICS it's not on any image? (at least that's what seeded-in-ubuntu says, just in "supported")
<Riddell> pitti: well next step is to get the language-pack-kde-xx to depend on calligra-l10n-xx
<Riddell> so it will be after next language pack update
<pitti> Riddell: NB that we don't add dependencies to langpacks usually, we have this handled by check-language-support
<pitti> like libreoffice-l10n-* and friends
<Riddell> or that yes
<pitti> Riddell: is there a libcalligra or calligra-common or some appropriate "trigger" package which should cause c-l10n-* to be installed?
<pitti> Riddell: oh, calligra-libs ?
<Riddell> pitti: yes calligra-libs
<pitti> Riddell: ah, we already have it
<pitti> tr::calligra-libs:calligra-l10n-
<Riddell> oh ok, cool
<pitti> ^ /usr/share/language-selector/data/pkg_depends
<pitti> Riddell: kubuntu-meta will mean a respin, you'll take the bullets?
<ev> skaet: signed and fixed wubi is in place
<pitti> skaet's upload blocker might not apply to derivatives
<Riddell> pitti: should be fine, we have no test results anyway
<pitti> Riddell: ok, please mark images for rebuild
<Riddell> voila
<Cimi> pitti, ping me back when you have finished with kde
<pitti> Cimi: I have
<Cimi> cool :)
<pitti> Cimi: so, it seems fine to upload to -proposed now and have a 0-day SRU
<pitti> then it can already be built, etc.
<Cimi> pitti, I think this is not a SRU
<pitti> if we will have a rebuild, there is a chance to pick it up into the release, but that needs to get past skaet
<Cimi> it should be in the precise package
<pitti> Cimi: well, it needs to go via -proposed either way
<Cimi> I know, so what do I need to do now?
<pitti> as we build everything non-arch-all in the staging area
<Cimi> wait kate?
<pitti> as I said, you can prepare the upload with didrocks
<pitti> (NB that it needs a linked bug in teh changelog)
<pitti> and we can accept it already
<pitti> then you can try and talk skaet into moving it to -release when we do another respin
<pitti> but that'll be a lot easier than uploading it at that point
<pitti> and in -proposed it can also be more easily tested in a live system
<Cimi> ok, thanks for exaplaining
<didrocks> I don't really have the time to deal with this one now. I'm not really happy as well as this was due to a late merge in 5.10 for changing some design thingy
<pitti> which once again proves why these late requests shouldn't be done :)
<didrocks> I agree and that's what I'm trying to prevent since Tuesday :)
<Cimi> didrocks, it won't be like that next cycle
<stgraber> can I get a respin of Edubuntu? our last build failed because of infinity ;)
<didrocks> especially that this was past unnoticed from 2 weeks of testing, and it's just a perf regression in the dash for 2 weeks
<didrocks> Cimi: don't promess such things :)
<Cimi> didrocks, I wouldn't really care that much if that was not such an important LTS
<didrocks> so as it took 2 weeks of noticing it, I still think that it doesn't worth the risk
<didrocks> can be fixed in a SRU
<Cimi> didrocks, SRU would be fine for another release, but this is an LTS
<didrocks> after a proper week of testing
<Cimi> didrocks, it took 1 or 2 days for noticing
<didrocks> Cimi: I personnaly have work to do now
<Cimi> didrocks, I will create a branch for you
<didrocks> not again arguing on yet another issue that is not important enough IMHO
<didrocks> Cimi: no
<didrocks> Cimi: I don't have the time to build it and again, won't sponsor something I'm not confident
<Riddell> stgraber: I can do that
<didrocks> I want a week of testing first
<didrocks> as it took 2 weeks for you to notice the slowliness
<Cimi> didrocks, you had months, this commit is a *revert*
<Riddell> stgraber: Edubuntu isn't in the iso tracker for "Precise Pre-release" is that just a box that needs ticked somewhere?
<didrocks> Cimi: it's not
<Cimi> it is
<didrocks> Cimi: no
<didrocks> Cimi: see the merge proposal
<didrocks> there is still a new fix
<Cimi> https://code.launchpad.net/~unity-team/unity/unity.fix-bottom-right-dash-decoration-corner
<Cimi> revert of that
<pitti> at least from here it doesn't look much differetn performance-wise
<Cimi> plus removed queue_draw
<didrocks> pitti: agreed
<pitti> the dash has always taken very long to open the first time
<didrocks> yeah, same here
<pitti> (and yes, that's very confusing)
<Cimi> pitti, open the dash fullscreen
<pitti> so if we can fix it, I'm all for it
<Riddell> Edubuntu rebuilding
<pitti> Cimi: how do I do that?
<didrocks> pitti: it won't change the perf you experience before 5.10
<Cimi> pitti, top left
<didrocks> experienced*
<Cimi> didrocks, what are you saying
<Cimi> didrocks, it's a commit in 5.10.0
<pitti> Cimi: ah, the maximize button -- didn't know that this worked
<didrocks> right
<didrocks> but
<didrocks> the revert as another fix
<didrocks> has*
<Cimi> the glitch is that in 5.10.0 the dash is *constantly redrawing*
<pitti> maximizing dash is basically instant here
<Cimi> on my macbook air (1000$), is *slow*
<didrocks> and this can be fixed in a SRU
<Cimi> pitti, move between items, or lenses
<Cimi> pitti, it's a bit sluggish
<pitti> I see some flicker there, yes
<Cimi> pitti, do you have a good computer?
<didrocks> Cimi: can I argue that on my computer it already took more than 6 seconds for the dash to show?
<pitti> Cimi: yes, I think so; ThinkPad X201, quad-core i5
<didrocks> Cimi: so we shouldn't release because of that?
<Cimi> pitti, imagine on slower machines, it's worse
<pitti> and still it takes some 5 seconds to open the dash first time
<Cimi> didrocks, we should fix
<stgraber> Riddell: it'll appear on the tracker with the first build
<didrocks> Cimi: so blocking the release? because it's a LTS?
<Cimi> didrocks, we have a safe fix
<didrocks> Cimi: this won't fix my 6 seconds issue everytime I open the dash
<Cimi> didrocks, but will improve at least
<didrocks> Cimi: and what Mirco did and that you approve was a "safe fix"
<Cimi> didrocks, because it asks less redraws
<didrocks> not in any noticeable manner
<Cimi> didrocks, the difference is that *I* approved
<Cimi> didrocks, while this *gord approved*
<didrocks> still, it took 2 weeks for you to notice it
<Cimi> and marco
<Cimi> and andyrock
<didrocks> and nobody reported sluginess
<didrocks> no bug report
<Cimi> didrocks, no no no
<Cimi> they did :)
<Cimi> on monday
<Cimi> mhr3
<didrocks> Cimi: ? can you point me on it?
<didrocks> Cimi: I meant, users
<Cimi> ask him
<Cimi> didrocks, it was easter
<Cimi> didrocks, I didn't really played with it
<didrocks> Cimi: we got a week of testing, and it's a week since this version is released in precise
<Cimi> didrocks, omer did notice a slowdown
<didrocks> SRU-0 seems still fine to me
<Cimi> andyrock did as well
<Cimi> a still lot of people don't upgrade
<didrocks> 11:10:56      mhr3 | Cimi, not really, i just saw it's repainting all the time, it didn't really feel like it's much slower though
<didrocks> doesn't seem to impact him then ^
<Cimi> didrocks, read below
<pitti> so, given how the last "urgent last fix" broke this in the first place, and I prefer a known small regression over an unknown one, I think it's totally fine to just wrap this into the next regular SRU
<pitti> so I agree with skaet and didrocks here
<Cimi> pitti, didrocks only quoted part of what that guy said
<didrocks> Cimi: what?
<Cimi> pitti, that guy has an nvidia card, rendering is so fast he can't spot difference in speed
<didrocks> so that's the "don't count"?
<Cimi> pitti, intel cards are affected
<pitti> I have intel here
<Cimi> especially not the newest
<didrocks> I just pasted what was told at the *same time*
<pitti> I'm not denying it's a regression and a problem
<didrocks> Cimi: stop making accusation, this really isn't the positive way, and still won't help
<pitti> I'm saying the benefit/risk ratio is not nearly high enough to warrant squeezing this into final
<stgraber> pitti: hmm, so if we want real RC today, I guess I should upload base-files? it's marked as release - 3 days on the wiki but without it, we don't have actual RC images...
<Cimi> pitti, it's a revert, risk is 0...
<didrocks> agreed with pitti, what I'm trying to argue with him since the other day
<pitti> stgraber: yes, I agree
<Cimi> high benefit / 0 = infinite
<pitti> except that the risk is never 0
<Cimi> infinite ratio :) !!
<pitti> and there was a reason for introducing the patch in the first place, so you'll rip something else open again
<pitti> mvo: ^ err...
<pitti> mvo: can this please go to -proposed?
<Cimi> pitti, I read code and I know what stuff did and why was done in that way, so I am absolutely confident of this commit so unity developers are
<Cimi> at the same time, I learnt how SRU, even 0, are useless for our target
<Cimi> people don't really upgrade as we do, new users don't care of upgrades
<Cimi> they just install, test, slow -> drop
<stgraber> pitti: uploaded
<Cimi> especially Windows users see upgrades like they were "security fixes" for windows (windows update), I have seen friends and my parents not upgrading because they were thinking it only would caused problems
<Cimi> for an LTS, delivering a smooth experience in the cd is absolutely crucial
<stgraber> pitti: I guess we'll update everything for the Q codename as SRU then ... unless sabdfl feels like blogging real soon...
<pitti> stgraber: yeah, at this point we can't update vim and friends any more, too intrusive
<Cimi> on unity, we aren't because of a regression, but we have a safe fix now
<pitti> stgraber: even lintian is on ubuntu-server and kubuntu for some reason
<micahg> pitti: for Q we can make that all use distro-info :)
<mvo> pitti: sure
<mvo> pitti: please reject and I will re-upload to proposed
<pitti> mvo: done, thanks
<Cimi> pitti, didrocks: did you read what I mean?
<pitti> Cimi: yes, I did
<didrocks> Cimi: I read it
<Cimi> I think we are underestimating the problem, SRU is not a solution
<pitti> but what shall I say, I can't magically make it appear in precise-proposed, I stated my opinion, and I don't want to  second- and third-guess didrocks and skaet
<pitti> the installer fetches updates, and we offer to install them; if SRUs were pointless, we wouldn't need to do them, and given how many people even respond to SRU bugs they clearly are useful
<pitti> and the SRUs will be wrapped into 12.04.x, too
<pitti> so eventually they will all go into the official media
<Cimi> pitti, we are targeting to a wider audience
<Cimi> pitti, audience which I think, won't install upgrades as we do
<Cimi> and we are forgetting all people from India without network
<Cimi> and other countries
<Cimi> where only the official media matters
<seb128> Cimi, somewhat the people who want a rocking stable lts will wait 12.04.1 anyway and have updated medias
<pitti> well, again -- before it is even _possible_ to consider this, this needs an upload
<Cimi> seb128, these are not our target, we are targeting to *new users*, not experienced users who know that ubuntu will release a 12.04.1
<Cimi> users see the new version and just download it
<Cimi> pitti, I need a sponsor then, will see if someone is keen to support a proposed package I'll build
<Cimi> pitti, and I will make sure skaet approves
<didrocks> I just want to underline that the fix is *not* a revert, it introduce a new call for redraw
<didrocks> compare https://code.launchpad.net/~andyrock/unity/fix-980924/+merge/102200 and https://code.launchpad.net/~unity-team/unity/unity.fix-bottom-right-dash-decoration-corner/+merge/101089
<Cimi> didrocks, before we were drawing the focus on the lens bar, now it is drawn on the icons of the lens bar
<didrocks> Cimi: so, it's not a "revert" as you told more than once
<Cimi> didrocks, thus andy removed all the redrawings of the lens bar, and added a queue_draw to the icon
<Cimi> didrocks, it's a revert plus removing useless calls
<Cimi> and calling the redraw to the right widget
<didrocks> and adding some calls
<didrocks> so please don't change the reality
<Cimi> one call, not "some"
<didrocks> and again, I remind you that was a late change on Friday before closing 5.10. a "safe" one
<didrocks> and it's not impacting everyone, and it's fixable in a SRU, and it's not making the product useless
<didrocks> so I made my point after too much discussion already and still against it
<Cimi> didrocks, we are on a totally different wavelength
<Cimi> didrocks, since you being the sponsor, I can't really get this in 12.04
<didrocks> now call who you want again, but keep pushing when 3 people: 2 members of the release team and the stack holder tells "no", you should listen to them
<Cimi> didrocks, I think this time you are wrong, but I will stop discussing
<didrocks> thanks :)
<Cimi> didrocks, who are the two members saying no?
<didrocks> skaet and pitti? see above
<Cimi> didrocks, skaet didn't reply
<didrocks> she told me that she answered no to it
<Cimi> didrocks, pitti asked to propose the package before
<Cimi> didrocks, when?
<Cimi> she's not here now
<didrocks> 11:12:07     pitti | so, given how the last "urgent last fix" broke this in the first place, and I prefer a known small regression over an unknown one, I think it's totally fine to just wrap this into the nex regular SRU
<didrocks> on that channel
<didrocks> Cimi: yesterday? when you started this discussion?
<Cimi> didrocks, maybe I was offline?
<didrocks> I don't think so
<didrocks> but again, no need for further discussion, I have work to do
<Cimi> I will speak again with skaet
 * stgraber points the auto upgrade tester to the pre-release milestone
<Cimi> I guess it was a misunderstanding
<Adri2000> I think the README.files in the cloud tarballs has a mistake
<Adri2000> for the .img file, it says "It can be bundled, uploaded and registered to EC2 or UEC as a Amazon Machine Image (aki/eki)."
<Adri2000> should be ami/emi
<ogra_> is there a reason why none of the arm desktop images show up on the tracker ?
<ogra_> (i see them in daily but not in pre-release)
<cjwatson> slangasek,ScottK: my attempt to move germinate handling into the database failed - it turned out to be much too slow, and I didn't have time to figure out how to make it faster - so that hack is as relevant as it ever was
<cjwatson> slangasek,ScottK: that said, don't sweat too much over it; things like changing a package's section override would also suffice to poke the publisher into action
<ScottK> cjwatson: OK.  Thanks.
<cjwatson> I've uploaded partman-target, and it'll need a ubiquity upload to pick it up.  The fix for bug 979350 caused a non-obvious chain of events that caused an occasional regression, bug 985526.
<ubot2> Launchpad bug 979350 in user-setup "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Fix released] https://launchpad.net/bugs/979350
<ubot2> Launchpad bug 985526 in partman-target "exit with error if encryption is selected" [Undecided,New] https://launchpad.net/bugs/985526
<stgraber> cjwatson: looking at partman-target now
<stgraber> cjwatson: looks good
<cjwatson> stgraber: thanks, accepted
<cjwatson> ogra_: today's arm desktop build failed for some reason - I'll retry
<ogra_> hmm
<cjwatson> IOW the previous build was before .isotracker.conf was changed to point to RC
<cjwatson> ooh
 * cjwatson demotes defoma
<cjwatson> testing-ports/precise_outdate.txt cleared as of next publisher run
<cjwatson> I'll start working through removals after an extremely belated breakfast
<ScottK> FYI, the maas upload in queue needs to come in to fix the MIR requirements for it, but the diff is sufficiently huge, I'll leave it for someone else to consider.
<ScottK> pitti: re gnome-online-accounts - In the bug you said it should be an SRU (facebook support).  Since we're clearly respinning everything, do you still think SRU (it's a new feature, not technically SRU material) or can it go in?
<Adri2000> who can do something about what I said earlier? (mistake in the README.files of the cloud tarballs)
<Adri2000> or can I file a bug in LP maybe?
<cjwatson> I'm not sure, ask Daviey or smoser
<ogra_> and you can always file a bug in LP :)
<pitti> ScottK: hm, though question; there is still no confirmation of testing in the bug, so I'd still prefer an SRU TBH
<ScottK> OK.
<ScottK> I see python-defaults is still in proposed.
<Adri2000> ogra_: tell me what's the right LP project for this and I'll do :)
<mvo> pitti: quick question, all uploads go to -proposed at this point, right? I have a small squid-deb-proxy fix ready
<cjwatson> It doesn't hurt to use -proposed.
<mvo> ta
<ScottK> pitti: Since you're both on the release team and the SRU team, I would appreciate it if you would review bugs 980773 and give feedback on what can/can't be done now.
<ubot2> Launchpad bug 980773 in fcitx "Sync fcitx 1:4.2.2-2 (universe) from Debian unstable (main)" [Wishlist,Won't fix] https://launchpad.net/bugs/980773
<pitti> ScottK: TBH that sounded really scary, updating umpteen packages and adding new ones
<pitti> with noone in the Ubuntu developer team to test this stuff
 * pitti follows up in the bug rather
<ScottK> pitti: Agreed.
<ScottK> Since I'm not on the SRU team, I don't feel I should give a verdict on that.
<pitti> sent to bug report
<pitti> TBH I don't know much about input support at all, so I default to being conservative there without more information
<skaet> thanks ev.   :)  we'll get it in with the next respin.
<ev> yay
<pitti> hey skaet
<skaet> hiya pitti,  read the backscroll.
<skaet> or reading rather....
<pitti> skaet: question about the lightdm upload -- the patch looks perfectly safe to me and should make derivatives/OEM's life easier; do you want some papertrail around it, or can I accept it for the next respin?
<skaet> Cimi,  putting it in -proposed as an SRU target is what's needed now.
<skaet> pitti,  re: lightdm - assume there's some bug numbers?
 * skaet needs to go dig
<pitti> skaet: just a merge proposal
<pitti> skaet: that's where the "papertrail" question comes in
<skaet> pitti,  yeah,  would prefer something documenting it, and tied to, in case we need to revert.
<skaet> thanks
<pitti> skaet: ok, I told robert his morning; this will become an SRU then
<jdstrand> skaet: fyi, I will probably be doing an openssl upload today
<seb128> pitti, I can open a bug for lightdm if you want, but SRU looks fine for that change, it's not really required in the release
<pitti> seb128: sure, sounds good
<pgraner> anyone else seeing 503 errors with the archive?
 * ScottK just had 404 errors, but that's because I can't spell updates correctly (working for me).
<cjwatson> jdstrand: based on precise or on precise-proposed?
<cjwatson> The reports in 965371 suggests that the version in precise-proposed is at the very least no worse (which my own testing bore out too) and appears to be an improvement for some sites, although it still doesn't fix everything.  Should we promote it?  I think I'd like to.
 * ogra_ wonders whats the issue with the arm livefs builders ... the preinstalled build seems to have failed again
<jdstrand> cjwatson: I was going to ask you about that. which do you prefer-- I need to respin for an upstream change anyway
<cjwatson> ogra_: I'll look shortly
<cjwatson> jdstrand: inclined to prefer -proposed.  what's the upstream change?
<jdstrand> cjwatson: I just assume use the -proposed one-- you got a lot of positive feedback
<jdstrand> http://www.openssl.org/news/secadv_20120419.txt
<jdstrand> http://cvs.openssl.org/chngview?cn=22439
<cjwatson> Of the Chinese translation bugs filed today, I've committed easy fixes for bug 985605 and bug 985614; the rest are fairly hard.  Are these worth uploading for?
<ubot2> Launchpad bug 985605 in console-setup "The keyboard config page should be translated into Chinese" [Undecided,Fix committed] https://launchpad.net/bugs/985605
<ubot2> Launchpad bug 985614 in debian-installer "Something wrong in the keyboard layout selection page" [Medium,Fix committed] https://launchpad.net/bugs/985614
 * ScottK is doing a lucid -> precise update test to test the new python-defaults.
<cjwatson> jdstrand: ok
<jdstrand> cjwatson: ok, so I will rebuild with -proposed, retest and upload to where, -proposed (since this could provide skew)?
<skaet> jdstrand, ack.
<cjwatson> Perhaps we could promote the existing package from -proposed to the release pocket first, if other release folks agree?
<ScottK> Seems reasonable.
<stgraber> sounds good
<jdstrand> skaet: I updated FrozenArchiveStatus
<cjwatson> ok, copied
<cjwatson> can somebody review ubiquity, please?
<stgraber> sure
<stgraber> cjwatson: looks good
<cjwatson> accepted then, thanks
<pitti> ah, stgraber beat me to it
<cjwatson> ogra_: fixed
<ogra_> what was it ?
<cjwatson> case error
<cjwatson> -                               case $subarch in
<cjwatson> +                               case $SUBARCH in
<ogra_> oh
<cjwatson> ogra_: ac100 was still broken, fixed for the next build
<ogra_> thanks !
<cjwatson> just tedious case rearrangement
<NCommander> morning
<skaet> Thanks jdstrand
<cjwatson> skaet: did you see my Chinese translation questions above?
 * balloons bringing up the pae / non-pae kernel issue again.. I take it we also don't have a non-pae kernel on the dvd's right?
<cjwatson> balloons: we do not currenty
<cjwatson> *currently
<jbicha> stgraber: you should probably take a look at the gnome-session proposed upload
<ScottK> Would someone please promote kdepimlibs5 back to Main.  It's needed for Lucid -> Precise upgrades.  I just pushed the corresponding seed change.
 * NCommander is reminded he has to tell omap4 lucid->precise upgrades :-/
<stgraber> jbicha: ok, will do
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<cjwatson> Not seeing the seed change though
<ScottK> The push failed.  Let me fix.
<ScottK> Worked that time.
<stgraber> jbicha: right, so that means we basically end up having to support cups-pk-helper for 5 years, though there's no Ubuntu delta and the code seems fairly simple
<cjwatson> gotcha, thanks
<stgraber> jbicha: is that what everyone else (other distros) are using for gnome-shell/gnome-fallback?
<cjwatson> Is somebody on top of all the remaining stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<cjwatson> It all looks like Daviey's team
 * ScottK agrees.
<ScottK> cjwatson: It's possible that accepting maas would help that.
 * ScottK however looked at the diff and decided EWAYTOOLONG.
<infinity> cjwatson: Err, oops on the subarch case sensitivity thing in find-live. :/
<jbicha> stgraber: I thought every other GNOME3 distro was using GNOME's printer panel, in Unity we use system-config-printer instead
<cjwatson> infinity: np
 * cjwatson fixes the lag on component-mismatches generation
<jbicha> perhaps it should be fixed by telling GNOME Fallback to use s-c-p too?
<jbicha> but I'm not sure how to do that, the OnlyShowIn: doesn't differentiate between GNOME Shell and GNOME Classic
<infinity> cjwatson: But... Doesn't moving the LIVECD="${LIVECD:-...} above all the cases make them no-ops?
<stgraber> jbicha: yeah, both of them showing with the same name is getting a bit annoying ;) OnlyShowIn=fallback would be handy
<ScottK> jbicha: Earlier I was discussing what to do about gnome-online-accounts with pitti and he pointed out there's still no reports of successful testing on Ubuntu.  So I think it needs that before it goes anywhere.
<cjwatson> infinity: oops
<stgraber> jbicha: I guess for 12.04, the easiest is to use cups-pk-helper, if it blows up completely, we can try to revert and get s-c-p in that case in an SRU
<cjwatson> infinity: should be at the bottom then, sorry, will move
<infinity> cjwatson: The only reason that appeared to work is because celbalrai has a (stale) copy of every image. ;)
<stgraber> jbicha: it's not our default session, it's just an install time option, so we can probably do some changes there as SRU if we feel the gnome3 dialog + cups-pk-helper won't work for the LTS
<cjwatson> it didn't appear to work, that change was after the most recent build
<infinity> Ahh.
<infinity> Well, it would have appeared to work anyway.
<stgraber> jbicha: for now, I'd just accept that new gnome-session
<cjwatson> so no harm done
<infinity> Oh, that's why my brain got the case wrong.  It's lower-case in buildlive.
<infinity> Yay consistency.
<stgraber> pitti: can you accept gnome-session based on discussion above?
<pitti> stgraber: is that scheduled for release or SRU?
<pitti> in the latter case it needs a bug
<stgraber> pitti: release
<pitti> (as above discussion says "SRU")
<pitti> ok, thanks, that wasn't entirely clear to me
<cjwatson> infinity: quite
<stgraber> pitti: without it you don't get a working printing dialog in Edubuntu when using gnome-session-fallback (install time option)
<pitti> ack
<pitti> stgraber: accepted, will copy to release when built
<stgraber> pitti: thanks
<stgraber> jbicha: thanks for spotting and fixing it
<pitti> accepted apt, too, and sent call for testing
<jbicha> stgraber: someone in the Ubuntu+1 forum mentioned it, I hadn't seen it before since I usually get GNOME Classic for free by installing GNOME Shell which already had the cups-pk-helper recommends
<pitti> we can then fold into release or SRU as appropriate
<infinity> pitti: If that's the fix I think it is, SRU is too late.
<infinity> pitti: It's breaking image builds.
<pitti> infinity: FD leak
<infinity> Yeah.
<infinity> That's breaking ARM server.
<pitti> infinity: either way, better to have it available for testing earlier than later
<pitti> infinity: ok, there goes our test case :)
<pitti> s/goes/is/
<infinity> Test case is simple, I'll test it as soon as it's built.
<cjwatson> so, we've got a week to clean up precise_outdate_all.txt, right? :)
 * cjwatson has a go
<infinity> Doesn't look too bad.
<ScottK> Cleaning up libreoffice-l10n would be a reasonably big chunk of it.
 * infinity nods.
<cjwatson> I think I just cleaned up libreoffice, at least.
<cjwatson> It's mostly individual not-built-any-more binaries that hold everything else in.
<cjwatson> yeah, that wasn't -l10n's fault at all, it was stale base-related binaries on armhf.
<skaet> sorry cjwatson, missed it in the multiplexing...   upload those you have fixes for to -proposed.   (as long as no risk of regression on non-chinese)   Rest will need to be SRU.
<skaet> We'll ask victor to check it out overnight,  and if solid,  move it to -release for subsequent respin.
<cjwatson> I'll have to tweak d-i to build out of -proposed.
<cjwatson> I don't know how Victor will check it out without a respin.
<cjwatson> I guess he could grab the netboot images from the archive.
<cjwatson> console-setup on its way; that ought to get a ubiquity reupload at some point ...
<infinity> pitti: Confirmed that apt fixes the bug, FWIW.
<ScottK> cjwatson: Are the template errors in http://paste.debian.net/163820/ something that ought to have a bug report (this is Lucid -> Precise).
<skaet> cjwatson,  hmm... maybe better flow we need to figure out then.
<stgraber> cjwatson: console-setup looks good (ignoring all the .gitignore changes)
<cjwatson> ScottK: lucid's debconf didn't support the @ there, but I think it's noisy rather than harmful
<ScottK> cjwatson: OK. Thanks.
<cjwatson> stgraber: accepted, thanks
<cjwatson> ScottK: (precise's definitely does, I think it was I who fixed that)
<cjwatson> yeah, debconf 1.5.34
<ScottK> Thanks for checking.
<cjwatson> not sure why the cheese copy from -proposed went wrong last time, but this should fix it
<pitti> infinity: yay
<pitti> infinity: arm builds still in accepted, we can copy after next publisher
<pitti> bbiab
<infinity> pitti: And I can go back to trying to fix the actual bugs that this blocked. ;)
<slangasek> cjwatson: ack, thanks
<jdstrand> skaet: fyi, I am going to build openssl in the security ppa and then pocket copy from there when I am done testing. I'll talk to you before doing it, but this will allow it to build on all archs before the copy while still allowing me to finish qa
<skaet> jdstrand,  sounds good.
<jdstrand> skaet: it's win/win! :)
<skaet> understood.
<skaet> :)
<phillw> How is the spinning going? I see kubuntu is being re-spun according to the page, no sign of lubuntu yet...
<cjwatson> There are enough installer changes that I think everything's being respun
<phillw> thanks, well hopefully that is one big gremlin out of the way :)
<cjwatson> quickly LGTM, accepting
<stgraber> yeah and we have things like gnome-session that was accepted earlier that even though it only affects edubuntu (gnome-session-fallback) would probably be good to have up to date everywhere (if only to avoid a pointless update post-install)
<stgraber> speaking of which, can someone copy gnome-session? looks like it's built everywhere
<NCommander> ogra_: infinity: where do we have it documented that omap4 server images must use serial to install?
<slangasek> cjwatson, stgraber: do you know where we are with the python2.7-minimal bug?
<slangasek> seems to still be open
<slangasek> and that's going to be CD-impacting
<slangasek> (unless we opt to SRU it I guess, since it's lucid->precise upgrades only...)
<cjwatson> stgraber: doing
<ogra_> NCommander, no idea, i never touched the server documentation, you and GrueMaster maintained the wikipage in the past
<stgraber> cjwatson: thanks
<ogra_> NCommander, if thats missing in the wiki, just add it ;)
<stgraber> 11:12 <doko> so the solution which should work is to include the new pycompile into the python2.7-minimal package, ugly solution, but this way we can make sure it's present when  used for the first time
<NCommander> slangasek: when doing release upgrading though, isn't it valid to upgrade to only precise/precise-security? (we don't require to have updates available)
<stgraber> slangasek: ^ that was from doko earlier today regarding that bug
<GrueMaster> NCommander: https://wiki.ubuntu.com/ARM/Server/Install
<slangasek> skaet: ^^ bug #983981 is one that potentially impacts all CDs since it's in the python2.7 package; it *can* be done in SRU, but definitely needs release-noted in that case to give extra discouragement to lucid users trying to upgrade to precise before the fix is in.  Do we want to try to get that on the CDs, or should we target -updates?
<ubot2> Launchpad bug 983981 in python2.7 "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,Triaged] https://launchpad.net/bugs/983981
<slangasek> stgraber: I'm not sure why the Breaks I suggested on the bug is insufficient?
<slangasek> oh, because Breaks doesn't enforce unpack order
<slangasek> duh
 * skaet looking
<jibel> slangasek, doko uploaded a version of python2.7 to a ppa for testing. I'll do the verification with this package tonight.
<slangasek> jibel: right, thanks - now the question is just whether we think we want this on the CDs
<NCommander> slangasek: upgrading with an alternate CD with no internet is a supported usecase
<slangasek> NCommander: as for it being valid to upgrade without -updates enabled, sure.  It's also valid to tell users who do this that they can keep both pieces when the upgrade bails in the middle due to $random_bug that we didn't get fixed before release
<slangasek> especially when it *will* be on the CD for .1, which is when we start recommending LTS->LTS upgrades
<skaet> slangasek,  what is likelyhood of regression on this one?
<ScottK> slangasek: I tested Lucid -> Precise with the python-defaults in precise-proposed three times and had no errors.  I also had the right default python version and python2 was there.  I'd suggest copy it over.
<ScottK> (the python2.7 question is a different one)
<slangasek> skaet: moderate, but easily mitigated by testing + review
<skaet> slangasek, ok, lets try as long as we can manage the risk.
<slangasek> skaet: I'm not concerned about regressions here as I think our process is adequate for that, just asking if you think it meets our criteria for a must-respin fix
<slangasek> ScottK: thanks
<slangasek> skaet: ^^ see above as well for python-defaults; I think we should copy this from precise-proposed to precise, is that ok?  Where are we currently with ISO spinning?
<ScottK> Since Ubiquity was just accepted 15 minutes ago, I think there's a lot of respins to do.
<slangasek> aha
<slangasek> skaet: in that case since we're respinning anyway I'll just copy python-defaults over, ok?
<stgraber> right, we have ubiquity + console-setup that will require respins of desktop and alternate images anyway
<cjwatson> console-setup wants another new ubiquity ideally
<cjwatson> for synciness
<cjwatson> anyone noticed anything else RC that would require a ubiquity upload?
<skaet> slangasek
<skaet> ok.
<stgraber> nope, I've been running a bunch of pretty complex Edubuntu install to try and stress ubiquity into crashing but couldn't find any problem so far
<slangasek> skaet: python-defaults copied
<skaet> thank you
<ScottK> doko: ^^^ re python-defaults.
<rsalveti> infinity: ogra_: http://cdimage.ubuntu.com/ubuntu-core/daily/current/precise-core-armhf.tar.gz
<rsalveti> it's actually armel
<rsalveti> var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_precise_main_binary-armel_Packages
<infinity> rsalveti: !
<ogra_> ts
<infinity> Oh, bother.
<infinity> I know why that is.
<infinity> Can't do two arches on the same machine, silly me.
<infinity> Well, not without some mangling I'm not going to do today.
<rsalveti> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-core/20120419/livecd-20120419-armhf.out
<infinity> And it all seemed so clever yesterday too.
<rsalveti> yeah, armel
<infinity> Actually, wait.  No, now I'm confused.
<cjwatson> doko: do you know what's happening with bug 935121?
<ubot2> Launchpad bug 935121 in gnat-4.4 "gnat-4.4 version 4.4.6-5ubuntu1 FTBFS on i386 in precise" [High,New] https://launchpad.net/bugs/935121
 * infinity looks closer.
<pitti> infinity: copying apt to -release, FYI
<cjwatson> infinity: are you still working on gnat-4.6 for the linker change?  it doesn't look desperately happy
<infinity> cjwatson: In what way doesn't it look happy?
<cjwatson> fails to build
<infinity> cjwatson: On armhf?  That's expected.
<infinity> cjwatson: It's not bootstrapped.
<cjwatson> armel too.  https://launchpad.net/ubuntu/+source/gnat-4.6/4.6.3-1ubuntu2/+build/3410800
<infinity> Oh, on armel too..
 * infinity looks.
<cjwatson> which makes it show up on precise_outdate_all, since it used to build.
<infinity> Oh, ugh.
<infinity> Looks like someone (doko?) enabled multilib for gnat-4.6
<infinity> So it fails on armel for the same reason it fails on armhf (not bootstrapped for armhf)
<cjwatson> remotely fixable for precise?  it has a bunch of reverse-deps
<infinity> If I can find where it was introduced.
<infinity> Great, in the 4.6.2->4.6.3 bump.  Fun diff.
<GrueMaster> infinity: Just fyi:  It was good on 20120315 (last image I officially tested).
<infinity> GrueMaster: "it"?
<GrueMaster> precise-core-armhf.tar.gz
<infinity> Oh, yeah.  I know, I broke it last night.
<infinity> I'm just trying to decide how, and how best to unbreak it.
<ogra_> intresting
<GrueMaster> Ah.
<ogra_> looking at the code it should theoretically only build armhf
<infinity> ogra_: Eh?
<ogra_> in buildlive you have no ubuntu-core case for armel
<ogra_> but you have it for armhf
<ogra_> pointing to annonaceae.buildd
<infinity> ogra_: It doesn't need a case.
<ogra_> ah, k
<infinity> ogra_: armel and armhf both point it at the same machine, that's the problem.
<ogra_> yeah
<NCommander> skaet: ubuntu server armhf+omap4 is missing from the ISO tracker
<infinity> ogra_: (That *shouldn't* be a problem, but we never thought of using the same machine for two arches, so the directories stomp on each other, and that's way too much effort to fix during release crunch)
<infinity> ogra_: So, I'll just move one to another box, but I need to sort out how that affects my precious parallelisation pipeline. ;)
<ogra_> so just s/annonaceae/araceae/ in the armhf case
<infinity> cjwatson: Something like http://paste.ubuntu.com/937076/ looks correct.
<infinity> cjwatson: Completely untested.
<cjwatson> I'll take your word for it, I don't know gnat at all
<infinity> That's more "knowing GCC packaging".
<infinity> But given that it takes 4 hours to fail on a panda...
 * infinity tries to rustle up a faster machine to test on.
 * NCommander screams in horror at the idea of trying to compile gnat
<skaet> NCommander,  may still be building.   Has anyone checked if the cron has kicked it out yet?
<NCommander> Not sure
<infinity> It may have suffered an earlier oops.
<infinity> I'll just do a manual spin.
<ogra_> skaet, teher are no builds of omap4 server for today yet so all is fine
<skaet> thanks ogra_.
<highvoltage> stgraber: anything we need to say for edubuntu-live... on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/EdubuntuDesktop ?
<skaet> NCommander,  ^
<stgraber> highvoltage: no, I think the existing LTSP entry is enough
<highvoltage> skaet: may I fix this sentence? normal people won't be able to parse it. "Until Ubuntu 11.10, the Unix group for administrators with root privileges through sudo had been admin. Starting with Ubuntu 12.04 LTS, it is now sudo, for compatibility with Debian and sudo itself. However, for backwards compatibility, admin group members are still recognized as administrators."
<skaet> highvoltage +1  (and thanks)
<ogra_> wow, what a sentence :)
 * skaet hoping to get editorial help from docs team....   (I know my limitations)
<ogra_> well, its a tricky problem to describe ...
<highvoltage> heh, I'm struggling with it too
<highvoltage> I got it to:
<highvoltage> """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 and hence forth sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent with Debian and how it's implemented upstream."""
<slangasek> s/and hence forth//
 * highvoltage was unsure about that :)
<ogra_> you forgot to mention that admin is still supported though
<NCommander> infinity: re: package pool in livecd-rootfs. It has to be fixed in the installer. I reproduced on x86 with a server CD
<ScottK> Is that something users actually care about (admin/sudo)?
<cjwatson> it'd be "henceforth" anyway, but I agree that removing that is better
<slangasek> how about "This makes Ubuntu more consistent with the implementation upstream and in Debian"?
<highvoltage> ogra_: ah nice catch
<slangasek> ogra_, highvoltage: does that part need to be in the release note though?
<ogra_> ScottK, only the ones that use visudo at times i guess
<pitti> highvoltage: thanks for fixing my broken English :)
<infinity> NCommander: "it"
<infinity> NCommander: Which "it" did you reproduce?
<ogra_> slangasek, i think ScottK has a point
<NCommander> infinity: rebuilding package cache
<ogra_> not really necessary
<slangasek> it's a significant behavior change to a core bit of the system; if we think users are going to notice, it's worth release-noting
<ScottK> If you use visudo, don't you also know enough to look in /etc/group and see what's up?
<slangasek> even if they don't care about sudo
<infinity> NCommander: Erm, what?  d-i CDs and preinstalled server CDs bear no resemblance here.
<NCommander> If you install with an alternate CD, after install, the cache isn't updated, so taskssel doesn't show any tasks until updated. I accidently broke my test environment but I think there are several more bugs lurking here that I need to flush out
<highvoltage> slangasek: it's in there at the moment. if it has to be in there I guess it has to be at least somewhat readable
<highvoltage> """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian."""
<highvoltage> (oops, I forgot about the compatibility part again)
<slangasek> highvoltage: I was only saying to not mention the fact that "admin" is still supported, since I don't think that adds anything useful
<phillw> How's "with the release of 12.04, the inconsistancy with normal sudo rules have been addressed. New administrators will be part of the sudo group. To ensure backwards compatibility, the existing administrators will automatically be assigned to this group."
<phillw> ?
<infinity> NCommander: Doesn't show any tasks, or doesn't show any new (ie: from the network) tasks?
<ogra_> what are "normal sudo rules" ?
<ogra_> :)
<slangasek> phillw: not a useful release note unless we actually say what the rules are
<NCommander> infinity: only shows tasks that were installed during installation
<NCommander> (plusmanual package selection)
<highvoltage> """Up until Ubuntu 11.10, root access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04 sudo access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian. For compatibility purposes, the "admin" group will continue to provide sudo/administrator access in 12.04."""
<infinity> NCommander: Okay, that's Yet Another Bug then, that doesn't relate at all to me fixing the local pool being broken.
<highvoltage> or maybe "sudo" should just be mentioned just once and "administrator" for the rest. that would make it slightly less jargonny and technical people will still know what it means.
<ogra_> highvoltage, how about s/root/administrator/ in the beginning of the sentence
<ogra_> for consistency
<ogra_> heh, snap
<phillw> with the release of 12.04, the inconsistancy with normal sudo rules from debian [1] have been addressed. New administrators will be part of the sudo group. To ensure backwards compatibility, the existing administrators will automatically be assigned to this group. [1] - Link to rules, for those bothered to read :)
<highvoltage> yeah :)
<infinity> NCommander: Also, a bit of a weird-sounding one.  Can you verify that from an unbroken x86 (ie: fresh install), and report against tasksel, and make it clear it's not yet another ARM bug? :P
<cjwatson> "inconsistency"
<highvoltage> I have it to this now but phillw's looks fine too:
<highvoltage> """Up until Ubuntu 11.10, administrator access using the sudo tool is granted via the "admin" Unix group. In Ubuntu 12.04, administrator access will be granted via the "sudo" group. This makes Ubuntu more consistent the upstream implementation and with Debian. For compatibility purposes, the "admin" group will continue to provide sudo/administrator access in 12.04."""
<phillw> cjwatson: I'm typing in a sticky note - no spell checker :)
<NCommander> infinity: I had reproduced before I broke my environment by connecting the internet
<ogra_> highvoltage, This makes Ubuntu more consistent *with* the upstream implementation and with Debian.
<infinity> highvoltage: s/tool is/tool was/ and s/consistent/consistent with/
<ogra_> beyond that i like it
<highvoltage> infinity: ah right. temporal language differences. In Afrikaans if you say "The admin tool was granted up until 11.04" it would mean it used to do that in those versions but it doesn't anymore :)
<ogra_> well, 11.10 still is used, i wouldnt have used past tense there either
<infinity> Until foo, X was the situation.  In product foo, X is the situation.  There's the temporal difference.
<ogra_> but grammar isnt necessarily logical :)
<ogra_> yeah, its the "until"
<highvoltage> ogra_: I believe Afrikaans inherited that from German so we're possibly just trained to think the same way about tense like that
<infinity> But I prefer to keep the current syntax and s/is/was/, because it's important to discuss it as past versus present/future.  Easier for people to grasp the New World Order.
<ogra_> we should just convince the americase to follow us then :)
<ogra_> *americas
<infinity> ogra_: I vill nefer do eet!
<highvoltage> infinity: I changed it on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure - edit at will!
<ogra_> LOL
<phillw> he he, where's pedro when you need him :P
<infinity> cjwatson: Testbuilding gnat-4.6 on one of OEM's speedier machines.  Will upload if it doesn't explode.
<highvoltage> does the ubuntu project has a position on serial commas? (and would that be pedantic?)
 * ogra_ only cares about serial ports ... as long as these work ...
<infinity> I'm not sure the project has positions on grammar at all.
<pitti> Daviey: will horizon be unseeded again, or will there still be a newer version with less dependencies? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
<infinity> highvoltage: Should you feel the need to do an UbuntuStrunk flavour, let me know.
<pitti> Daviey: I suppose python-coverage should be droppable, if the test suite can just deal with it not being present
<highvoltage> the confusing double negatives when it comes to smp support continues to amuse me :)
<jbicha> I split April's Tuesday events to separate lines in https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule I think it makes it more clear when things actually happen
<phillw> oh, btw, thanks for the 1st lubuntu alternates. It'll keep them occupied for a while :)
<pitti> good night everyone
<skaet> good night pitti
<infinity> pitti: *wave*
<highvoltage> good night pitti!
<skaet> jbicha,  please revert.   Its using the syntax agreed to at UDS.   We can revisit this for Q.
<skaet> Try it out on Q/ReleaseSchedule and we can discuss at upcoming feedback on P cycle at UDS
<phillw> skaet: this being the format that caused all the issues with translations? I do hope it is addressed at UDS-Q
<skaet> phillw, agreed.
<skaet> https://blueprints.launchpad.net/ubuntu/+spec/other-q-prior-release-feedback
<jbicha> skaet: ok, it's been reverted
<NCommander> infinity: I think I found the root of the tasksel problem: https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/985737
<ubot2> Launchpad bug 985737 in tasksel "Tasks selected in oem-config are downloaded, but not installed, or configured ..." [High,New]
<skaet> phillw, jbicha ^^ is the catch all for problems we've seen with processes, frustrations, etc.   Add concerns there, so it goes on the agenda.   If a topic is too involved (like weekly release meeting was last time), it will be spun out to separate session.
<infinity> NCommander: Commented.
<NCommander> infinity: commentedback
<ogra_> .oO(you guys have a weird way of communicating)
<infinity> ogra_: Well, the paper trail in the bug is vaguely important.
<ogra_> indeed :)
<stgraber> ogra_: kind of like people phoning you to see if you received their e-mail ;)
<infinity> ogra_: So, it's either talk on IRC and copy and paste, or comment on the bug and ping in IRC.
<infinity> ogra_: And who wants to talk to NCommander?
<ogra_> stgraber, haha, that was *exactly* what i had in mind
<ogra_> infinity, true :)
<slangasek> did you get that thing I sent ya
 * NCommander hits infinity with a big pointy stick
<ogra_> *g*
<infinity> slangasek: I got two, I think one might have been meant for your wife, though?
<infinity> slangasek: It doesn't fit *me*, at any rate.
<ogra_> NCommander, i would compare the Packages files from archive and local pool
<infinity> ogra_: Why?  I already know they're broken. :P
<NCommander> ogra_: right after I finish filing an installer bug on x86
<ogra_> infinity, do we know how ?
<infinity> NCommander: Don't bother debugging.
<infinity> ogra_: Yes.
<NCommander> infinity: different bug
<ogra_> ah, k
<NCommander> install CD isn't added to sources.list after installation
<infinity> NCommander: Which different bug?
<NCommander> (server/precise/i386)
<infinity> NCommander: No, no, I meant don't bother debugging local pool versus archive, as ogra suggested. ;)
<NCommander> heh
<slangasek> infinity: http://www.metacafe.com/watch/1572395/that_thing_i_sent_you/
 * NCommander should probably start doing the workload testing so I can file more bugs
<NCommander> :-)
<infinity> Hrm.
<infinity> Sound stuttering in flash.
<infinity> Joy.
<NCommander> infinity: I would think you'd use a nice FOSS alternative like gnash/swfdec/lightspark
 * NCommander ducks
<infinity> NCommander: I'm not sure I parse the word "nice" in that sentence.
<infinity> If any of those actually work sanely these days, I'm all ears.
<ogra_> WebM works
<ogra_> i just accidentially noticed that on my ac100
<infinity> ogra_: Sure, but not everything is webemmy.
<ogra_> yeah, else my surfing experience would be a lot more multimedial on my arm bedbook :)
<NCommander> sure you don't mean medival?
<balloons> skaet, what was the mac bug you mentioned? can you link to it?
<NCommander> .oO(where's my omap4 image)
<ogra_> NCommander, not built yet
<infinity> NCommander: Patience.
<cjwatson> ^- skaet acked debian-installer going to release rather than -proposed
<infinity> NCommander: It's squirting our as fast as it can.
<infinity> cjwatson: I assume your previous d-i component that went to -proposed has been copied? :P
<infinity> Whatever it was...
<infinity> user-setup?  console-setup?
<infinity> My brain is mush.
<cjwatson> infinity: console-setup, and yes
 * NCommander liquid-cools infinity's brain back into sometihng solid
<ogra_> NCommander, you mean you want to turn his brain into a brick ?!?
<NCommander> ogra_: meh, we could replace it under warrenty
<NCommander> I'm pretty sure the PO for infinity included a 10,000 bugs guarantee
<infinity> cjwatson: Accepted, under the assumption that all the gobbleygook I can't read was obviously valid and sane translation updates. :P
<infinity> cjwatson: (The bits I understood looked fine)
<cjwatson> Meh, you're supposed to speak every language on the planet in order to be an Ubuntu developer.
<cjwatson> (ta)
<NCommander> .oO(LP needs to add a real-time translation module to Rosetta)
<NCommander> ok, good, tasksel properly prompts for a CD when its not present
<NCommander> https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/985791 - CD not added after install on i386. I think apt-setup is responsible but I'm not sure
<ubot2> Launchpad bug 985791 in apt-setup "After installation from cdrom, apt-setup comments out the CD from installation" [Undecided,New]
<ogra_> NCommander, ^^^
<NCommander> \o/
 * NCommander goes and adds his ten bugs to it
<skaet> cjwatson,  ack.
<NCommander> bargh
<NCommander> Most of the tomcat6 examples seem broken EXCEPT the ones on the workload testing page
<micahg> hmm, is there an easy way to sync something to proposed?
<micahg> syncpackage seems to want to show every changelog entry
<infinity> Rebuilding ubuntu-core undo the previous oops with assigning two arches to the same buildd.
<infinity> micahg: Do a --no-lp sync to precise, then 's/Distribution: precise/Distribution: precise-proposed/' in the .changes, sign, upload.
<micahg> infinity: heh, ok
<infinity> micahg: (And no, that's not the answer you were looking for, but I'm not sure the internal tools handle it right)
<micahg> infinity: ooh, you can do -r precise-proposed with --no-lp and it seems to DTRT
<infinity> micahg: Including the right -V?
<infinity> micahg: Curious.
<micahg> infinity: doesn't need -v in this case :)
<micahg> well, an earlier -v
<infinity> micahg: Ahh, that's probably why it appears to DTRT. ;)
<micahg> ^^ re kadu, I sent it to proposed as it's a longish build with arch:all packages, the only questionable thing I can see is a new binary depends on libqt4-svg, but I'm guessing that was just missing before
<CareBear\> can I still get a new libusb package in? :)
<CareBear\> if available like soon
<infinity> CareBear\: Addressing which bug(s)?
<ogra_> skaet, so we had what we thought was a gtk-window-decorator bug in arm compiz/unity ... it turns out that the bvase branch the arm compiz patch was created from didnt contain the quilt patches the ubuntu package carries though, thats the cause of the decorator issue ... i would like to do a zero day SRU for this but i'm not sure how to proceed
<ogra_> (since that will indeed require a rebuild of more than just compiz)
<ogra_> i will discuss with didrocks tomorrow but want to give you a heads up warning
<skaet> ogra_ coordinate it with didrocks.    We'll pick a window for it to land (Tues/Wednesday).
<skaet> :)
<infinity> ogra_: Do you have new packages prepared already that we can look at diffs for?
<ogra_> infinity, no, we just discovered it and i dont trust my concentration to do it now, i will do it tomorrow monring first thing though
<infinity> ogra_: *nod*
<infinity> ogra_: Well, get it sorted, then ask. ;)
<slangasek> CareBear\: not unless it fixes a critical bug... no such bugs have been on our radar up to this point?
<ogra_> will do :)
<ogra_> infinity, btw, see #ac100 :)
<infinity> ogra_: If it's pretty broken, and obviously only affects ARM, we can probably get it in via proposed->release->rebuild.  If it's risky-looking, SRU.
<ogra_> seems srwarren treis to roll the hf binaries right now :)
<ogra_> yeah, its arm only
<ogra_> the quilt patch we use sits on top of all other quilt patches ... and reverts all the others :P
<infinity> D'oh. :/
<infinity> Respinning armhf desktop images for benchmarking purposes (and to resurrect ac100)
<slangasek> resurrect?
<CareBear\> slangasek : what constitutes critical? there are several bugfixes
<slangasek> CareBear\: a bug that renders Ubuntu uninstallable or causes an upgrade to fail or to cause data loss through normal use on install would be critical.  "several bugfixes" is probably not in that grouping...
<infinity> slangasek: Thinko in the cdimage scripts made it disappear slightly. ;)
<slangasek> infinity: heh
<CareBear\> slangasek : a future upgrade might fail, because the current package in Ubuntu was packaged by debian from an RC which was on a development branch and one public API has changed since that time. this is also the main reason I would want a non-rc version included.
<slangasek> "might fail" - that sounds like speculation, not a bug report
<slangasek> we certainly are well versed in dealing with API changes when they happen
<CareBear\> slangasek : it *will* fail if someone starts using the incorrect API, and then an upgrade is done to a real release of the package which doesn't have that API any longer
<slangasek> that's not how it works
<CareBear\> it could happen?
<slangasek> this is the same upstream version of libusb that was shipped in the past *two* LTS releases; we're not going to pull in a new upstream version of a library the week before release because it *might* save trouble for people writing new code against 12.04
<CareBear\> it is not the same version
<slangasek> and if APIs are dropped, that means an ABI bump, which is certainly not in the cards
<CareBear\> the two last LTS have 1.0.8 with patches. currently you have 1.0.9-rc3
<slangasek> hardy: 2:0.1.12-8   precise: 2:0.1.12-20
<slangasek> what packge are you talking about?
<CareBear\> no, no ABI bump, because the rc3 was from development branch
<CareBear\> libusb1
<CareBear\> I guess you call it?
<slangasek> there's no such package in Ubuntu
<slangasek> and the libusb package is at version 0.1.12
<CareBear\> yes, no, that's the wrong package :)
 * slangasek searches
<CareBear\> hold on - let me find it!
<micahg> libusb-10
<CareBear\> ah thanks!
<micahg> libusb-1.0
<CareBear\> yes
<micahg> it's still on images
<slangasek> right
<ogra_> and has rdeps
<slangasek> (blah, why do we have libusb besides then)
<CareBear\> slangasek : libusb and libusb10 provide different API and can coexist
<micahg> slangasek: too many rdeps for a transition
<ogra_> (upower for example)
<slangasek> CareBear\: yes, but we don't like having different libs with different APIs for the same thing ;)
<micahg> even a partial transition
<ogra_> and cupy :)
<ogra_> *cups
<micahg> luckily it's only ~50k
<CareBear\> slangasek : oh I don't like it either. libusb-0.1 (your libusb package) is deprecated since many years and unmaintained, but some packages still have not upgraded to the new API
<CareBear\> slangasek : at upstream we also provide libusb-compat-0.1 which uses libusb-1.0 to emulate the old libusb-0.1
<slangasek> CareBear\: can you give me a pointer to an explanation of this API change?  (or a diff)
<ogra_> hmm, we use both of them ?
<ogra_> libusb-0.1-4 is in minimal ... libusb-1.0-0 is in standard
<ogra_> (sounds liek something to clean up one day)
<slangasek> CareBear\: unfortunately, the answer is probably still going to be "no"; I would have been glad to get this done had it come to our attention earlier, but it's probably still too much churn to take at this stage
<ogra_> *like
<CareBear\> slangasek : it's pretty simple, but still. rc3 adds a libusb_has_capability() function which checks for named capabilities in the library. the first (and only) capability changed name from LIBUSB_CAN_GET_DEVICE_SPEED in rc3 to LIBUSB_CAP_HAS_CAPABILITY in current master
<CareBear\> slangasek : I did join here some time ago to somehow prepare for the change, but then there were interrupts and now it looks like it's too late then
<ogra_> is there a diff/patch somewhere to look at ?
<CareBear\> I'm happy to help clarify anything about 0.1 vs. 1.0 you may want to know
<CareBear\> ogra_ : hold on
<ogra_> CareBear\, 0.1 vs. 1.0 and moving to only one of them sounds like a great plan for 12.10 :)
<slangasek> CareBear\: right... sorry about that :/
<slangasek> CareBear\: my ISP seems to be giving me fits today and I'm not able to get to libusb.org; is there somewhere else I can look for the code/
<Laney> where does queuebot's code live?
<CareBear\> hold for links
<CareBear\> slangasek : http://git.libusb.org/
<Laney> found it
<CareBear\> ogra_ slangasek : rc3 has this commit: http://git.libusb.org/?p=libusb.git;a=commitdiff;h=69045343   master has this: http://git.libusb.org/?p=libusb.git;a=commitdiff;h=e1680513
<slangasek> mmk, can't get to git.libusb.org either, blah
<CareBear\> ogra_ slangasek : rc3 was tagged on a development branch that was since rewritten before getting into master. rc3 was meant for internal review, but was too eagerly pushed into debian.
<CareBear\> I'll pastebin
<slangasek> understood
<slangasek> have you spoken with the Debian maintainer, by chance?
<CareBear\> yes
<CareBear\> rc3:http://dpaste.com/734359/ master:http://dpaste.com/734360/
<slangasek> grr, I can't reach that site *either*
<ogra_> phew, thats half a year old
<ogra_> Mon, 17 Oct 2011 16:23:54 +0200
<CareBear\> yes, that may be when I started talking about it in here
<CareBear\> slangasek : what *can* you reach? :)
<NCommander> Do we have any tomcat gurus here?
<CareBear\> slangasek : any other pastebin?
<slangasek> buggeredifIknow
<slangasek> let's see
<ogra_> paste.ubuntu.com ?
<slangasek> CareBear\: paste.ubuntu.com is working for me... for the moment
<CareBear\> ok!
<ogra_> NCommander, there is that #ubuntu-server channel :)
 * NCommander can access the dpaste.com if someone wants a repost
<CareBear\> slangasek : rc3: http://paste.ubuntu.com/937357/  master: http://paste.ubuntu.com/937359/
<CareBear\> ogra_ : the 0.1 vs. 1.0 thing is important if one application wants to use both versions through different plugins or libraries. then the separate implementations can easily conflict, but in those cases using the compat library to get 0.1 API is the right solution. that's why it's there
<slangasek> CareBear\: does the libusb_get_device_speed API exist in master?
<CareBear\> slangasek : yes
<slangasek> ok
<ogra_> CareBear\, well, i just dont like to have two versions of the same thing twice on our images and would like to see how we solve that for the future, nothing for now though
<slangasek> so this is an entirely non-ABI-breaking API change
<slangasek> it will break compiles, but anything built against the old version won't fail to run with the released version
<CareBear\> slangasek : correct!
<CareBear\> slangasek : thanks for the clarity
<CareBear\> I understand this is not critical
<slangasek> still, from an upstream perspective you would obviously like developers to not have to hack around this when building on Ubuntu
<CareBear\> nod
<slangasek> we could cherry-pick that one commit, which would be a lot easier for us to squeeze in than reviewing a full upstream diff for the new release, at this point
<CareBear\> so revert the old and add the new?
<slangasek> CareBear\: if we could make that happen, would that be ok?
<slangasek> yes
<CareBear\> that would be lovely!
<CareBear\> can I help?
<slangasek> well, we still need to check to make sure nothing in the Ubuntu archive is already using that old API
<slangasek> so that we don't regress buildability
<CareBear\> I can make a branch off the rc3 with revert+new commit
<slangasek> CareBear\: it's a short enough fix that I don't think you should bother
<slangasek> micahg: any chance you could help with this?
<CareBear\> revert conflicts, I'll fix it and show you
<CareBear\> trivial but still
<slangasek> micahg: 27 revdeps, we'd want a source scan for LIBUSB_CAN_GET_DEVICE_SPEED... I assume you're well-versed in the security team tools that do this :)
<micahg> slangasek: I wish I was, you need someone with a local mirror, jdstrand could probably help with that or give someone with a local mirror pointers
<jdstrand> micahg: are you calling me a tool?
<ogra_> lol
<slangasek> skaet: ^^ and just to confirm, do we have room in the schedule for this minimal library change that affects all images?
<micahg> jdstrand: I suppose it could be read that way ;)
<jdstrand> what is needed? it usually takes several hours
<infinity> slangasek: I can do a source scan.
<slangasek> infinity, jdstrand: we only need a scan on the 27 packages build-depending on libusb-1.0-0-dev
<infinity> Oh, that's much simpler. :P
 * infinity does that now.
 * jdstrand has no context for this conversation, but gladly lets infinity do 'it'
<infinity> slangasek: LIBUSB_CAN_GET_DEVICE_SPEED is definitely the offensive bit?
<CareBear\> yes
<infinity> slangasek: If so, it's not found in any of those sources.
<slangasek> infinity: did you do a proper source scan with crazy-security-team-unpacking logic?
<CareBear\> I pushed the branch off rc3 to here: http://git.libusb.org/?p=libusb-stuge.git;a=shortlog;h=u1204   revert: http://paste.ubuntu.com/937377/  fix: http://paste.ubuntu.com/937378/
<slangasek> (tarball in tarball; tarball in watermelon; tarball on goofballs; etc)
<infinity> slangasek: I'm not sure how necessary that is, unless you think a debian/rules patch is cleverly doing a 's/CHEESEBURGER/SPEED/' in the source just to screw with me.
<ogra_> dput has watemelon support ?
<infinity> Oh, I suppose there's tarball in tarball.  I can quickly check for that. :P
 * ogra_ notes that down for the summer
<slangasek> infinity: this is why I was asking the security team, they have standard scanning tools
<infinity> It's only a few sources. :P
<infinity> And no tarballs.
<infinity> It's all normal.
<slangasek> ok
<CareBear\> amazing. thanks all!
<slangasek> infinity: thanks - can you grab that fix CareBear\'s offered us, and push it to -proposed today?
<infinity> Sure.
<skaet> slangasek,  we'll pull it in today then.
<infinity> CareBear\: Is there a Launchpad bug for this?
<CareBear\> infinity : no, but I can create one if you want?
<infinity> Not necessary.
<CareBear\> ok
<infinity> slangasek / skaet: Uploaded.
<jdstrand> hrmm
<infinity> Err, and rejecting.
<infinity> Cause I forgot to update-maintainer.
<infinity> La la la.
<ogra_> tsk, paperwork
<jdstrand> cjwatson: so, it turns out that your ubuntu2 upload causes qrt test failures (test_rfc5746(), test_rfc5746_dtls()) in test-openssl.py. I haven't looked at it yet
<infinity> Fixed and re-uploaded.
<CareBear\> what's the -2 part?
<ogra_> comes from debian
<CareBear\> ok
<jdstrand> cjwatson: ubuntu1 is ok, ubuntu2 is not and by extension, my ubuntu3 is not
<ogra_> we only add ubuntuX usually
<skaet> slangasek, infinity - crontab disabled now,   we're manual from here on out.
<CareBear\> got it
<infinity> skaet: Check.  That coincides nicely with me getting IS to mangle some live builders, since I don't have to disable things myself. :P
<skaet> infinity,  we're waiting for a few more things to land before the respins.   Let us know when #IS is done.
<jdstrand> skaet: ok, ready to copy openssl. my testing showed no regressions over ubuntu2 (which is already in the archive)
<slangasek> libusb-1.0 accepted for building
<skaet> thanks jdstrand
<jdstrand> skaet: 1.0.1-4ubuntu3 pocket copied
<skaet> infinity, slangasek, http://pad.ubuntu.com/ubuntu-release as been updated
<skaet> if there's anything else that needs to be waited for that I've missed, before the full rebuild is triggered.
<jdstrand> skaet: not we need a publisher run before openssl is ready
<jdstrand> s/not/note/
<skaet> jdstrand, yup,  but we have to wait for libusb-1.0 first, so,...   figured that would happen.   Have clarified though.
<infinity> The builder mangling will be the blocker anyway for preinstalled images.
<infinity> skaet: When we're ready, I'd like to do the preinstaller trigger myself, so I can get timings out of it.
<infinity> skaet: Trying to get the pipeline as short as I can with what I have to work with. :P
<infinity> preinstalled*
<skaet> infinity,  ok,  take over the respins.   (I'm interested in your timings....  can you post when done?)
 * skaet would like to compare to the ones she took with beta2
<infinity> Some images will be quite a bit slower (older hardware), but the overall "rebuild the world" should be quite a bit faster.
<infinity> Or, that's my hope.
 * skaet crosses fingers
<phillw> infinity: what sort of server do you need to assist in builds & what does it have to have to have installed?
<phillw> -have
<infinity> phillw: It has to be in our datacenter, so I suspect that's a non-starter for you donating cycles.
<phillw> okaym infinity - just seems a waste of an idle server :/
<skaet> phillw,  some of the localized image producers from the community might want to take you up on it, if there's an idle server sitting there.  ;)
<skaet> http://localized-iso.qa.ubuntu.com/qatracker/milestones/209/builds - is where those images will be landing eventually.  Just the italian's have started at this point
<phillw> skaet: I've put a request in via balloons to ask if Canonical would sponsor 4 IP addresses (12 GBP / IP address / year) for me to put Virtual Machines onto the server.
<skaet> k,  will follow up on it next week (when in london), if balloons doesn't have it sorted first.
<phillw> cheers, skaet . TheSII (upstream team) do not need the capacity of the 16G model of http://www.kimsufi.co.uk/ So it sits there at 0.1% cpu time!
<infinity> cnd: Was this xorg upload something you were hoping to get into release?
<cnd> infinity, I didn't think it had critical fixes, and we're well into final freeze, so I figured I'd prepare it as a 0day SRU
<cnd> I can propose it for the release if you think that's better
<infinity> cnd: No, no.  If you're cool with it festering until release, I'll leave it in the queue, and you can deal with the SRU team instead of me. :P
<cnd> :)
<infinity> cnd: But if any of it is kinda key to a not-shit user epxerience, we can/should discuss picking it up.
<cnd> infinity, if everyone used touchscreens I would say yes
<cnd> but in reality, there aren't *that* many ubuntu touchscreen users
<infinity> Yeah, all two of them.
<infinity> Check.
<cnd> and those that are can use a mouse to get an SRU
<cnd> though that reminds me I need to add a note in the release notes
<infinity> I'll let it sit in the queue for now, then.
<infinity> Though, if this is something you feel is important enough to Release Note it, we should go back to discussing fixing it. :P
<infinity> Release Noting things we HAVE a clear fix for, when we're still a week out, feels wrong to me.
 * skaet --> errands,  back in a few hours.
<skaet> infinity,  you have the baton.  ;)
<cnd> well, I was told to release note anything that might be broken in the release
<cnd> anything that was note worthy
<slangasek> libusb-1.0 copied to release
<infinity> Noteworthy is a matter of opinion. ;)
<cnd> even if it will be fixed by a 0 day SRU
<skaet> thanks slangasek
<infinity> If we noted every bug, the notes would be long and very unreaable. ;)
<cnd> I agree :)
<cnd> but someone suggested I note it
<infinity> slangasek: Again?
<infinity> I guess we can never have too many.
<cnd> infinity, if you want, take a look at the bug report and let me know what you think we should do
<infinity> cnd: Sure, when my tuits get a bit rounder tonight, I'll have a closer look.
<cnd> ok
<cnd> thanks :)
<slangasek> infinity: did you do this already?
<slangasek> it hadn't been published yet :)
<slangasek> ah, 'No packages copied', so.
<jbicha> I wouldn't expect hardware to magically work with updates, I'd just assume that version of Ubuntu didn't support the device if it didn't work from the Live CD/USB
<slangasek> then my statement is no less correct ;)
<infinity> slangasek: I think I accepted it before queubot had a chance to announce.
<infinity> jbicha: Except for explicit hardware enablement backporting, that's probably a fair assessment of the average user impression, yes.
<infinity> jbicha: On the flipside, we probably have all of 2.3 touchscreen users right now, and 12.04.1 will be out long before we have a ton more.
 * infinity takes this opportunity to accept lightdm, so people can stop waffling about it, based on /lastlog not telling me that anyone actually has concerns. :P
<infinity> ^--- Those are all broken, buyer beware.
<infinity> slangasek: Do you know the magic for just marking every image in the tracker invalid?  We're going to respin soon (fsvo "soon") anyway.
<slangasek> infinity: seb128 had said it was fine for SRU, so please don't accept lightdm into release if we don't need it
<slangasek> infinity: sure, I can do that
<slangasek> actually, if there's no bug number for lightdm, then it's an invalid SRU candidate
<slangasek> so that should have been a reject
<infinity> slangasek: To be fair, it was heavily discussed as being useful to derivatives.
<slangasek> and needed for .0?
<infinity> (Which would include people mangling images, I'd guess, but maybe not)
<slangasek> disablenated
<slangasek> not added, you cod
<infinity> queuebot: Oh shut up, can't you tell a tentative test click when you see one?
<infinity> Oh lord, and it's going to list all of the rest.
<infinity> I must not have made the cutoff.
<GrueMaster> infinity: Can you (when you get a chance) remove my gruemaster email from the CD Image failure reporting?  Thanks.
<infinity> GrueMaster: Done.
<stgraber> slangasek: oops, for some reason I forgot that this message is printed whenever something affects >= 25 entries and not just when adding entries as it did initialy, message updated to reflect that now :)
<slangasek> stgraber: :)
<stgraber> infinity: you were close, would just have needed an extra 7 entries to trigger the spam protection ;)
<infinity> I still think your threshold's too high. ;)
<infinity> "More than 0 entries changed, go find out for yourself."
<slangasek> thing happened; see Internet for details
<infinity> ^
<infinity>         exec update-initramfs.REAL "$@"
<infinity> Err.
<infinity> Thanks for whatever paste buffer had THAT in it...
<infinity> http://lmgtfy.com/?q=what+happened%3F
<stgraber> so what exactly are we doing for the upgrades on the tracker? are we resetting them everyday?
<stgraber> I'm wondering because they're currently all marked for rebuild which prevented the auto upgrade tester from publishing its results a few minutes ago (which basically is, edubuntu => OK, kubuntu => OK, mythbuntu and xubuntu => FAIL)
<infinity> Oh.  They're all disabled because they're all about to be respun.
<infinity> But what our normal practice will be for the rest of the week, I don't know.
<infinity> Probably not that. :P
<stgraber> I tend to prefer having a single upgrade "build" for the release week and let people add more pass/fail results to it as things evolve, but that's just personal preference based on the fact that it takes pretty much a day to get the automated upgrades done so we can't get an accurate view of the upgradability of the archive
<stgraber> in theory, any upload to the archive should trigger a bump of that product on the tracker, but I doubt it's reasonable considering how long it takes to run them ;)
<infinity> Alright, respinning the world, unless there are objections.
<slangasek> depends
<slangasek> do you want eglibc first?
<slangasek> (critical upgrade issue for kubuntu...)
<infinity> *blink*
<infinity> What did I break?
<slangasek> nothing
<slangasek> bug #985735
<ubot2> Launchpad bug 985735 in eglibc "update-manager restarts KDM and interrupts update process" [High,Incomplete] https://launchpad.net/bugs/985735
<infinity> Oh, fun.
<infinity> Hasn't it been like this for the last 7 years?
<infinity> One would assume not, I guess.
<slangasek> infinity: so this seems to be the first report of the problem all cycle
<slangasek> which means I'm not inclined to rush in a fix
<slangasek> infinity: you want to go ahead and respin the world then?
<infinity> Sure.  Incoming twirly world.
<infinity> Oh, oops.  This does me no good for timings, since I meant to also change the shell madness.
<infinity> Oh well.
<infinity> Twirly anyway.
<slangasek> so I'm looking now to see if this is a regression from 2.15-0ubuntu7
<infinity> Seems possible.
<slangasek> eglibc uploaded.  sigh and grr.
<slangasek> skaet: much apologizings for the above eglibc upload; it fixes a kubuntu-only regression introduced a week ago that was tricky to spot in the source diff, so I'm not surprised it didn't get caught in review
<slangasek> infinity, skaet: I think we have to get this into -release due to the horrid impact on upgrades, but there's no need to respin just for this since it's *only* an upgrade issue - we should plan to include it in the next respin, whenever there is one
<slangasek> well, let me think about that
<slangasek> is it ok to have this as a 0-day SRU?
<slangasek> skaet, infinity: alright, I've convinced myself this should be a target of opportunity: if we're respinning a substantial portion of the images after the current run, we should take eglibc and make it a global respin, otherwise we should 0-day SRU it
<stgraber> slangasek: 0-day SRU would break for people using kubuntu alternate as a pool for their upgrade.
<stgraber> but that's a very limited subset of people
<slangasek> now see, you're talking me out of it again
<slangasek> ok
<slangasek> anyway, it's on the pad now
<infinity> Get 60 more bytes in your diff and I'll accept it.
<slangasek> ?
<infinity> diff from 2.15-0ubuntu9 to 2.15-0ubuntu10 (606 bytes)
<infinity> Anyhow, reading more context to make sure the 1-line diff makes sense to me.
 * slangasek nods
<infinity> That's wildly unintuitive with the inline script substitution.
<infinity> Could probably do with a short "check goes in, services comes out" comment, or something. :P
<slangasek> could do with a few things
<slangasek> do you want me to reupload with that comment added? :)
<infinity> Kerosene?
<infinity> No, but if you could add said comment to debian's svn and ubuntu's bzr, that would be snazzy. :P
<infinity> Cause without it, I have a hard time blaming you for breaking it.
<infinity> Or any future person who breaks it similarly. :P
<slangasek> adding in bzr; will worry about debian svn later since it's not a clean merge
<infinity> Not even remotely, no.
<infinity> I want to try to get them more in line with each other next cycle to reduce my headaches.
 * infinity goes to grab a snack.
#ubuntu-release 2012-04-20
<infinity> Officially EODs, will unofficially be around to fiddle with images and check on the queue. :P
<skaet> slangasek,  ugh on the eglibc.
<micahg> third time's the charm for respins?
 * skaet crosses fingers.
<CareBear\> are the isos hosted somewhere?
<skaet> CareBear\  path to them is on the iso tracker
<skaet> basically on cdimage.ubuntu.com
<CareBear\> there are a few :)
<skaet> CareBear\, yup.
<skaet> :)
 * skaet --> zzz
<pitti> Good morning
<infinity> pitti: Can you prove that?
<pitti> hm; grey and rainy outside, and still a bit tired
<pitti> BUT!
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> beer-y!
<pitti> q. e. d.
<infinity> And who doesn't like beer on their cornflakes?
 * pitti should update the script to add a bowl of fruit before 1200 UTC
<pitti> or a Yoghurt shake
<infinity> pitti: I'm tempted to do one last mass-give-back to see if anything in universe FTBFS magically shakes out.
<infinity> pitti: Any objections?
<pitti> I'm all for that
<pitti> otherwise all those shiny buildds will just freeze to death, give them some work out :)
<infinity> ;)
<pitti> infinity: how many builds are we talking about? powerpc might not be able to catch up with all of them
<pitti> ah well, it's all opportunistic anyway
<infinity> PPC can catch up fine. :P
<infinity> 91 builds on PPC, most of which will probably fail/dep-wait in the first few minutes.
 * micahg will be doing Mozilla uploads over the weekend :)
<micahg> but I think it'll be fine as well
<infinity> micahg: Those will all be main, so they'll beat the universe give-backs.
<micahg> infinity: oh, yeah, and in a security PPA :)
<infinity> (Well, maybe not chromium, but you have friends who can fix that)
<infinity> Oh, in the PPA, even better.
<infinity> I'm kinda wildly shocked that i386 and amd64 FTBFS is so low (well, sorry, "not-built", not the same as FTBFS from rebuild tests, which is higher)
<micahg> infinity: +1 maintenance has helped :)
<ScottK> That and we really aggressively pruned old crap in Lucid.  It makes it easier now.
<ScottK> Everything in the archive with binaries has built at least once in the last two years.
<infinity> Speaking or pruning, removing libembperl-perl.
<infinity> Considering removing gnat-4.4, but it has r-bdeps.
<ScottK> You've got a few days to fix that.
 * micahg is wondering about ldc which is unbuildable
<micahg> has rdeps
<micahg> can someone go pruning again removing stuff removed from Debian?
<infinity> I'm sure we can, not sure I'm doing it at 11pm.
<infinity> But we still have a week to make sure universe is perfect and shiny.
<infinity> Hey look, something shook out!
<infinity> Shame it failed on i386. :P
<infinity> But, progress...
<infinity> You know, the archive would be in much better shape if we just dropped Haskell, Ada, and D.
<infinity> cnd: Upon further reflection (and reviewing the diff a few times), I accepted your xorg-server into -proposed, meaning it's a likely "respin opportunity" candidate.  Given that, can you make sure it gets some solid testing once binaries poop out the other end?
<micahg> fixes rebuild dep-wait ^^
<infinity> pitti: I'm thinking update-notifier wants accepting, but I'll leave it to you as a desktoppy fellow who cares. ;)
<infinity> pitti: (Also, because I'm thinking you can explain why it needs to import 5GB of po files)
<pitti> infinity: because LP again took the diff against the pre-last version, not against 0.119ubuntu8
 * pitti checks the real diff
<infinity> pitti: Oh.  That was only the 5-line change from Brian?
<infinity> pitti: That would be much more readable. :P
<infinity> pitti: (We need to fix that)
<pitti> I'm double-checking
<pitti> yes, just the "missing gettext" part
<pitti> Context not found: "ubuntu/precice-proposed"
<pitti> 2012-04-20 05:19:00 ERROR   Error encountered -- aborting current transaction
<pitti> err, what?
<pitti> $ q -Q unapproved -s precice-proposed fetch update-notifier
<infinity> ...?
 * pitti looks harder
<infinity> No can spell.
<infinity> preciCe?
<pitti> *blush*
<pitti> so, the gettext fix plus autoconf noise
<pitti> I'm not entirely sure whether the latter is justified
<pitti> it looks like Brian didn't have gnome-common installed
<infinity> There needs to be a law against using different versions of autotools in stable releases (and in the weeks leading up to).
<pitti> infinity: I think I'd prefer reuploading this with gnome-common installed, and fake-sponsor it for Brian
<infinity> If the noise is actually a problem in this case, go ahead and re-upload. :)
 * infinity nods.
<pitti> I can't tell for sure that it is a problem, but I'd rather avoid it
<infinity> Yeah, that's fair.
<infinity> When I do stable updates, I actually go out of my way to make sure autojunk gets replicated the same as the previous version.
<infinity> Just out of paranoia.
<infinity> Or OCD.
<infinity> Probably more the latter.
<infinity> (This is a surprising challenge when doing stable updates of apt, as mvo seems to randomly switch autoconf versions more than most people switch their underwear)
<pitti> http://paste.ubuntu.com/937864/ - now how is that
<infinity> pitti: ZOMG readable.
<infinity> pitti: And Brian's patch is "obviously correct".
<infinity> pitti: Does u-n have arch skew?
<infinity> pitti: If not, while you're sponsoring, jam it into release. :P
<pitti> hardly
<infinity> pitti: We already know we're rebuilding for eglibc, at least.
<pitti> I can reupload
<infinity> Just edit the Distribution line in .changes and reupload.
<pitti> done
<pitti> so you now have two, pick the one you prefer :)
<infinity> Hahaha.
<infinity> Brian's going to be so confused.
<pitti> infinity: eglibc? nice
<pitti> I left a comment for him in the bug
<pitti> infinity: kernel 3.3 would be nice, too!
<infinity> pitti: We (and be "we", I mean vorlon, but I'm not naming any (real) names) may have messed up the daemon restart logic, and ended up killing kdm on upgrades.
<infinity> pitti: kubuntu upgrade testers are unimpressed.
 * pitti does bug 985940 and gets rid of another FTBFS
<ubot2> Launchpad bug 985940 in libpgjava "FFE exception for Precise: libpgjava" [Undecided,Triaged] https://launchpad.net/bugs/985940
 * micahg just filed bug 986017 to rid another rebuild FTBFS
<ubot2> Launchpad bug 986017 in ruby-sequel "FFe: Sync ruby-sequel 3.33.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986017
<micahg> wait, what, are my eyes deceiving me?  I see a 3rd PPC build
<micahg> *buildd
<infinity> micahg: You do.
<micahg> \o/
<micahg> infinity: do you want to give back the rebuild as well?
<infinity> Not really.
<infinity> Mostly cause I don't have a script to do that, and I don't speak lplib well enough to do it by hand.
<infinity> Another thing I need to fix, now that the world's moving/moved to the LP API.
<pitti> 3rd buildd> ooh!
<micahg> infinity: ok, maybe when cjwatson arises
<infinity> Also, for parallel builds, sulfur should be about twice as fast as the others.
<infinity> So, aim your compilers and web browsers and office suites there. :P
<micahg> orly?  so libreoffice should be down to ~10hrs
<micahg> firefox won't parellelize ATM, but nice to know there's a chance for improvement
<micahg> although I have 4 builds at a time for it
<infinity> The other buildds are dual 2GHz G5s with 3G of RAM, sulfur's a quad 2GHz POWER5 with 4G of RAM.
<infinity> So, nearly identical for serial builds.
<micahg> so, if I ever get firefox to parallelize again, that means we can probably build an update in ~12 hours
<infinity> (We were going to make sulfur the livefs builder, but after testing it against royal, it came out almost identical, so I figured the two more cores made more sense for package builds)
<micahg> indeed
<micahg> we do have a lot of packages that can parallelize and more being added all the time
<infinity> *nod*
<infinity> I think you can kind of blame us for that.
<infinity> We forced the issue a while ago when I just 5-bladesed parallel building into the buildd network and watched the world burn. :P
<infinity> Patches made it back to Debian remarkably quickly back then, as I recall.
<infinity> (The number of people who thought it was appropriate to -jN debian/rules without testing it in any meaningful way was remarkable)
 * micahg likes dh --parellel
 * infinity raises his brow.
<infinity> ^-- What was that about?
<pitti> infinity: sorry for the spam; doing kernel SRU training with RAOF
<infinity> Ahh.
<pitti> I just fixed copy-proposed-kernel.py to use the async method
<pitti> we did the real SRU copyign with the old script still, which uses syncPackage() and thus doesn't hit +queue
<infinity> async sync just sounds odd. :P
<pitti> infinity: ok to accept u-notifier?
<pitti> yay, the LP diff is correct this time
<infinity> pitti: What update-notifier?
<pitti> that very :)
<infinity> mvo: Mornin'.
<infinity> mvo: Thanks for the quick apt fix.  You're my hero.
<mvo> infinity: your welcome, thanks for your report about it, that was right in time
<infinity> I probably should have found it earlier, but who reads build logs, right? :/
<infinity> Would have been embarrassing to trip over after release, if elmo decided to upgrade cocoplum. :P
 * mvo nods
<mvo> oh yes :)
<infinity> (At least, I'm assuming it would die in the same way on a "real" archive)
<mvo> it would, I'm pretty sure
<infinity> Unless file lists take it through a safer codepath.
<infinity> mvo: Do you still touch upstream apt, or have you backed away completely?
<infinity> mvo: Your (fairly critical) FD fix, and my (pretty much just cosmetic) FD fix should both get into Debian.
<infinity> mvo: I think I may have even linked the Debian bug in the changelog for mine.  If I was awake when I did it.
<infinity> Ahh, yeah, I did.
<mvo> infinity: yeah, I will merge it into debian too
<infinity> mvo: *hug*
<mvo> infinity: well, once bzr finishes upgrading my branch to whatever is the latest format that is not compatible with the one used in my other branch :/
<infinity> mvo: Hahaha.
<infinity> Waiting on gnupg (28932) to finish generating a key.
 * infinity taps his foot.
<micahg> pitti: can you please promote chromium in lucid to -updates and -security?
<pitti> micahg: on it
<pitti> micahg: ^ looks right?
<micahg> pitti: yes
<micahg> pitti: thanks
<micahg> pitti: chromium in natty-proposed is ready as well
<pitti> micahg: done
<infinity> doko_: Good morning. :P
<micahg> pitti: thanks
<doko_> infinity, did I wake you up? ;P
<pitti> infinity: FYI, jibel tested the python upgrade, working fine
<infinity> pitti: With the above upload?
<pitti> I'll review/accept into -proposed as soon as it gets diffy
<doko_> infinity, yes
<pitti> and then we can see for 0-day SRU or folding it into release, depending on whether we'll respin
<infinity> doko_: So, what do you (with a community hat on, I guess?) want to do about the FTBFS compilers in universe?
<doko_> infinity, which ones?
<pitti> doko_: thanks for the fix!
<infinity> doko_: gnat-4.6 has been FTBFS on armel since (accidentally?) turned on sf/hf multilib.
<infinity> doko_: gnat-4.4 is FTBFS on all arches.  I'd happily remove it, but it has reverse build-deps.
<doko_> pitti: my gdb upload is still pending?
<doko_> infinity, if gnat-4.4 has reverse-deps, then these should be removed, or built with 4.6
<pitti> doko_: someone blocked it on https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus
<micahg> infinity: I'll try to poke at gnat-4.4 rdeps over the weekend if you or doko don't beat me to it
<doko_> pitti: even for -proposed?
<infinity> micahg: Consider the lock yours, I'm on airplanes.
<infinity> doko_: So, micahg just took 4.4 off our hands.  Fixing 4.6/armel would be nice, though, since it used to work. :/
<doko_> pitti, ahh, I think it was slangasek. but the changes are bug fixes only
<infinity> doko_: I gave a quick pass at disabling sf/hf multilibs, but I clearly didn't grok the packaging well enough on the first pass.
<doko_> micahg, it doesn't make sense to "fix" 4.4, better try to remove it
<micahg> infinity: I can't promise due to the large number of other things I'm balancing on my plate
<micahg> doko_: yes, I plan to get the rdeps upgraded to 4.6 versions from Debian :)
<pitti> less risky in an SRU, of course, but as the bug neither has a test case (or something that's actually broken), nor a regression test plan, it won't be easy to get it to -updates
<stgraber> hmm, can we re-enable the upgrade entries on the tracker?
<stgraber> oh, I guess it'd make sense to wait for python though
<infinity> doko: My initial stab at fixing gnat-4.6 was http://paste.ubuntu.com/937997/ but it appeared to have no effect, so I suspect I'm missing a bigger picture. ;)
<doko> infinity, I'll have a look
<doko> micahg, libgtkada can't be built with 4.6?
<micahg> doko: I already filed the removal for libgtkada2
<infinity> doko: libgtkada2 was superseded by libgtkada, just to be confusing.
<doko> ahh, ok
<micahg> libgtkada is already built with gnat-4.6 FWIW
<infinity> micahg: Whose baby is reverse-depends(1) (or the web service it uses)?
<infinity> adconrad@cthulhu:~$ reverse-depends libgtkada2
<infinity> reverse-depends: Error: Unknown package
<micahg> infinity: tumbleweed wrote it I think, it's hosted on ubuntuwire
<infinity> As opposed to checkrdepends, which gets it right.
<micahg> infinity: you need src:
<micahg> yeah, requires more flags than checkrdepends
<infinity> Oh. --help doesn't say that. :P
 * micahg would love a current version of that :)
<micahg> infinity: polyorb removal: http://packages.qa.debian.org/p/polyorb/news/20120305T100750Z.html
<infinity> micahg: Nuked.
 * infinity removes narval from that same mailing list post.
<infinity> Oh, nevermind.  Already gone.
<micahg> yeah, we did that a while ago
<tumbleweed> infinity: patches welcome :)
<infinity> tumbleweed: This is just a documentation issue, apparently.
<infinity> tumbleweed: Or, it's an I can't read issue.
<tumbleweed> probably needs to say "binary package" so that it's more obvious what the problem is
<infinity> tumbleweed: src is there in help, just cleverly hidden in the middle of my terminal.
<tumbleweed> ah
<infinity> But yeah, a more informative error wouldn't hurt.
<tumbleweed> source packages probably should have been the default, it's all I use it for :/
<infinity> It could also use a slightly more machine-friendly output format.
<tumbleweed> there's an option for that
<infinity> Oh, -l
 * infinity tries.
<infinity> That's more pleasant.
<micahg> infinity: ok, filed 3 FFe, ghcl I think we can just remove with gnat-4.4, all that's left is apq* which I'm testing now
<infinity> tumbleweed: Okay, then once we get over my inability to read, I think my only remaining complaint is that I need to run it twice.
<infinity> tumbleweed: Since I can't seem to get it to give me both rdeps and rbdeps together.
<infinity> But maybe that's by design.
<micahg> yeah, I wish that would be fixed as well :0
<infinity> micahg: ghdl, you mean?
<micahg> yes :)
<infinity> That actually sounds remotely useful.
<infinity> Shame it's unmaintained. :/
<micahg> indeed, but we can backport it if it ever gets fixed and people want it
<infinity> micahg: Bugs for the FFes?  I'm too lazy to go hunting.
<micahg> give me a minute, filing 2 more
<infinity> I accept verbal FFe requests.  Especially for universe.
<micahg> bug #986073, #986077, #986086, #986094, #986095
<ubot2> Launchpad bug 986073 in opentoken "FFe: Sync opentoken 4.0b-3 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986073
<ubot2> Launchpad bug 986077 in gnade "FFe: Sync gnade 1.6.2-9 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986077
<ubot2> Launchpad bug 986086 in libaunit "FFe: Sync libaunit 1.03-7 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986086
<ubot2> Launchpad bug 986094 in apq "FFe: Sync apq 3.2.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986094
<ubot2> Launchpad bug 986095 in apq-postgresql "FFe: Sync apq-postgresql 3.2.0-2 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986095
<micahg> and we're almost done :)
<tumbleweed> infinity: that sounds pretty solvable :)
<infinity> micahg: The first three didn't need exceptions.
<micahg> infinity: new binaries need an FFe :)
<micahg> or so I've been told
<infinity> micahg: Just debian revision bumps with bugfixes (build-deps)
<infinity> Oh, meh.  They squirt out new binaries?
<infinity> Whatever. :P
<micahg> yes, hence the paperwork :)
 * infinity syncs.
 * micahg could sync them :)
<infinity> True.
<infinity> Do 'em all.
<micahg> I'll assume you've commented appropriately
<micahg>  do you want any of them in -proposed?
<infinity> micahg: release is fine.  But if that last one doesn't have properly versioned build-deps, make sure to stagger the uploads.
<micahg> ok
<micahg> deps are properly versioned
<infinity> Then sync away and close your bugs. ;)
<micahg> done and done
<infinity> Oh dear, this is unpleasant: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985852
<ubot2> Launchpad bug 985852 in apt "libapt-pkg regression: infinite loop on processing certain Pre-Depends" [High,In progress]
<micahg> infinity: once those publish, here's the removal: Bug #986096
<ubot2> Launchpad bug 986096 in gnat-4.4 "Please remove gnat-4.4 and its reverse dependencies from precise" [Wishlist,Confirmed] https://launchpad.net/bugs/986096
<micahg> that was a very productive half hour :)
<micahg> although sleep was on the schedule :)
<infinity> mvo: Do you know if that infinite loop affects us (ie: do we have an ORed Pre-deps), or is it SRUable?
<infinity> micahg: Sleep's overrated.
<infinity> I have a court date tomorrow, I'm trying to get as much work in as I can. :P
<infinity> So I can show up wild-eyed.
<infinity> It'll be great.
<micahg> infinity: oops, forgot one, hold off on removal :)
<infinity> micahg: I'm not removing until the rdep list is clear anyway. :P
<infinity> micahg: I *do* check these things.
<infinity> *blink*
<infinity> You don't have enough RAM to build PyPy.
<infinity> It's known to require >= 1400 MiB on 32 bit archs.
<infinity> Why does it need *physical* RAM?  Or is the Debian maintainer just a doofus?
<Laney> Ask him. The doofus is in here.
<infinity> tumbleweed: Hey, doofus.
<infinity> tumbleweed: See above. ;)
<tumbleweed> infinity: it'll take a week to build
<tumbleweed> probably more
<tumbleweed> the GC walks across all the memory quite often
<micahg> infinity: bug #986105
<ubot2> Launchpad bug 986105 in topal "FFe: Sync topal 75-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986105
<mvo> infinity: I think its SRUable and also needs a release-upgrader-apt upload for the lucid->precise upgrade
<mvo> infinity: I prepeared that but want to give it a testrun in jenkins first
<infinity> mvo: If you think it's worth a release-upgrade-apt build, then I think it should be in release, not an SRU. :P
<mvo> while the regression risk is tiny, I'm worried about $anything at this point :/
<infinity> tumbleweed: But I assume it's no that evil at runtime, right?
<mvo> infinity: but let me do a quick analysis
<tumbleweed> no
<tumbleweed> infinity: teh build process is "import everything into memory, perform type analysis, optimise, write C". Uses an insane amount of RAM
<infinity> tumbleweed: A week-long build doesn't really hurt my feelings (though, obviously a bit late for precise) unless you upload the package every 2 days..
<mvo> infinity: in the archive it seems to be pretty much only debconf, default-jre and udev | makedev
<infinity> mvo: That's a longer list than 0.
<infinity> mvo: That settles it for me, we want it fixed, IMO.
<infinity> (And not in an SRU)
 * infinity gets to reviewing.
<mvo> infinity: ok, I think I agree, probably I'm in too much of a OMG-stable mode currently
<infinity> mvo: No, that's the right mode to be in.
<infinity> mvo: But I don't want to take a chance on this asploding upgrades.
<infinity> mvo: The MaxLoopCount guard probably could have been avoided for a targetted fix, though...
<infinity> mvo: (Since I assume you also fixed the loop?)
<micahg> can someone approve the last gnat-4.4 rdep FFe from me above?
<infinity> micahg: Oh, looking.
<infinity> micahg: Seems slightly more featureful than the other syncs, but it's for the greater good. :P
<tumbleweed> infinity: I was being nice to the debian buildds. LP has less tiny-memory architectures
<micahg> infinity: indeed, thanks
<infinity> tumbleweed: Yeah.  I should spin it up on a Panda and see how it fares.  If it's alright, you can guard your guard in an lsb_release check for Ubuntu.
<tumbleweed> infinity: sure
<micahg> infinity: ok, going to sleep now, I'll check when I get up to make sure all the stuff that was supposed to build did, thanks for your help
<infinity> micahg: Thanks for looking. ;)
<mvo> infinity: right, I can do a upload to final without the MaxLoopCount, I would like to SRU it though later as its IMO useful, the unknown is how high this count needs to be
<infinity> mvo: Oh, I agree that the option's useful.  And the implementation even seems reasonable reviewable.  I just want tiny for fixes. ;)
 * micahg still can't believe we're shipping 4 versions of vala in the archive...
<infinity> micahg: How many in main?
<micahg> 2 last I checked
<infinity> :/
<infinity> I remember the good old days, pitti and I used to be draconian about duplication in main.
<Riddell> arguably vala is a duplication in itself </controvertial>
<infinity> mvo: Oh ick, and I've seen that modifier bug before.  I didn't spend enough time looking at it to realise what was happening.
<tumbleweed> infinity: btw, building pypy on a low-memory machine is almost certainly going to timeout sbuild. It's already timing out on a bunch of decent buildds in Debian (if sbuild was line-buffered, I think it'd be OK, but it isn't)
<micahg> tumbleweed: you could always grab the change that fta added to chromium that outputs something every 5 minutes
<tumbleweed> urgh :)
<infinity> GCC has a similar hack.
<infinity> Also, I take it back, I'm not spinning this up on my Panda, since my Panda needs to be in my suitcase in ~1.5 days.
<infinity> Silly me.
<infinity> tumbleweed: Remind me that I cared about this, and we'll look at it for Q?
<tumbleweed> :)
<infinity> tumbleweed: I'll test on a QuickStart too (which is what the Debian/armhf builders are), and if it's good on both, you can just turn it on there too.
<infinity> But yeah, it might need a logping hack or something if it's going to take days to do its thing.
<infinity> I believe it was GCC on m68k that drove doko to write that awful hack in the first place. :P
<tumbleweed> micahg: actually, I don't think that's even an option, as it does legitimately timeout too.
<pitti> infinity: https://launchpad.net/~ubuntu-cruft-busters!
 * micahg applies
<infinity> Ditto.
<infinity> Even if it is owned by NCommander. ;?
<infinity> ;)
<infinity> TYPING HARD.
<micahg> infinity: if we need an approbation, we can use the yada removal :)
<infinity> tumbleweed: Wait...
<infinity> tumbleweed: Is the ascii art how it keeps the build alive? ;)
<tumbleweed> yes. But the ascii art is based on events, not time
<infinity> Oh, and those events can really be hours apart?
<infinity> Shame.
<tumbleweed> 4k worth of dots can be hours apart
<infinity> Ahh.
<infinity> That's a solvable problem.
<tumbleweed> in my measuring, each line is always a lot less than that on a capable buildd
<infinity> Watching this is kinda soothing.
<tumbleweed> it's colour if you do it by hand :P
<infinity> Oooo.
<infinity> mvo: Okay, I've read this a few times, in both directions, uphill both ways, in the snow.
<infinity> mvo: I'm inclined to accept it as-is.  The two bugs are both worth fixing, and the MaxLoopCount looks safe and sane.
<infinity> mvo: When do we get a matching release-upgrader-apt?
<mvo> infinity: the release-upgrader-apt is uploaded to a PPA once the testing there is done I move that to lucid-proposed
<infinity> mvo: Mmkay.
<pitti> ^ your mass give back?
<cjwatson> oh, yes, I was going to look at a mass give-back for the test rebuild
 * cjwatson fires up lp-shell
<pitti> cjwatson: infinity did that this morning apparently
<cjwatson> he did that for the main archive, not the test rebuild
<cjwatson> there's stuff in scrollback abou tit
<doko> pitti, cjwatson, infinity: I'd like to fix bug 981037 for precise. 0-day sru?
<ubot2> Launchpad bug 981037 in openjdk-6 "The javac executable doesn't produce full paths for files on error" [Undecided,New] https://launchpad.net/bugs/981037
<pitti> doko: yeah, normal SRU seems fine; this isn't release critical for final certainly?
<doko> pitti, I'd like to build it in -proposed, so that jibel can test it. no, not for final
<pitti> sure
<jdstrand> cjwatson: fyi, the test-openssl.py qrt failures were because I needed to specify -tls1 to s_client. I think what is happening is s_server is defaulting to -tls1 and s_client is not
<jdstrand> cjwatson: I'm going to not worry about it at this point
<cjwatson> ah, that makes sense, I hadn't got round to looking at that yet
<cjwatson> come on, Launchpad, I'm only asking you to load 1472 objects
<cjwatson> ah, there we go
<cjwatson> I guess I want to give back only source packages without newer versions in the main archive
<cjwatson> >>> len(builds_not_superseded)
<cjwatson> 496
<cjwatson> that looks about right
<cjwatson> >>> for b in builds_not_superseded:
<cjwatson> ...  b.retry()
<cjwatson> builders are filling up now
<pitti> time for our new shiny builders to earn their money!
<pitti> or electrons
 * cjwatson â¥ launchpadlib
<pitti> i386 8 26 jobs (43 minutes)
<pitti> buildds with go-faster stripes!
<cjwatson> gah, just spotted a security flaw in apt-setup for extras.ubuntu.com handling
<cjwatson> we need a new ubiquity to sync up with console-setup anyway, so can I upload this?  it's just adding predownloaded Release/Release.gpg files so that the initial update is forced secure
<stgraber> sounds good
<infinity> cjwatson: While you're in there, add a nice comment block for security? ;)
<cjwatson> too late, sorry
<cjwatson> file a bug :)
<infinity> Oh, indeed.
<infinity> Curses, queuebot.
<infinity> I don't care deeply enough to file a bug.
<infinity> I always wipe my sources.list anyway. :P
<doko> pitti, openjdk-6 uploaded
<infinity> Just felt odd that it's the only one without comments.
<stgraber> apt-setup looks good
<stgraber> actually, why don't we have the .gpg too?
<cjwatson> we do
<cjwatson> it might not show up in the diff since it's a binary file
<stgraber> oh right, diff and binary, sorry
 * stgraber needs to add some visual way of spotting binary files in mc's diff viewer...
<pitti> stgraber: babeltrace has no bug refs, no open bug, and looks very intrusive; was that discussed before?
<cjwatson> It would sure have been nice if GLU ES had been packaged by somebody
<stgraber> pitti: we're trying to get on the full lttng 2.x stack that includes babeltrace 1.0, we were previously on a development snapshot, I now pushed the RC and we're expecting the final in the next few days
<stgraber> pitti: lttng is fully self contained at this point, nothing depends on it and it's not seeded
<pitti> stgraber: ok, I assume you tested with the new lttng-* packages and on precise?
<stgraber> pitti: yes, upstream develops on Ubuntu and have daily builds. I built them locally on my machine and am running with them
<pitti> ok, thanks
<pitti> Daviey: can you please review the maas upload in -proposed? I don't feel qualified to judge the patch/impact
<infinity> ^--- cjwatson is reviewing that upload for me already.
<cnd> infinity, I'll ask for testers on the ubuntu-x mailing list
<cnd> thanks!
<cjwatson> yep, livecd-rootfs is fine
<cjwatson> lots of arm preinstalled fixes
<doko> third powerpc buildd \0/   ... time to start a test rebuild on powerpc ;)
<infinity> doko: I'd love to after Debian imports settle down a bit, actually.
<infinity> doko: I'd really like to know how healthy the port really is (I suspect it's not as bad as people think, and most of it could be fixed easily)
<doko> openjdk-6 build did fail on amd64, one of the new machines ...
<infinity> doko: Very thread-sad... Too many cores confusing poor java? :P
<infinity> "Caused by: java.lang.IllegalMonitorStateException: current thread not owner
<infinity> Etc.
<cjwatson> infinity: even the normal FTBFS list is a good indication that it isn't particularly sad
<stgraber> infinity: who needs smp anyway?
<infinity> stgraber: Sun was pretty keen on SMP before they sold their souls to Ellison.
<pgraner> infinity, https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/986203  looks like fixing lp 985737  caused a new bug: lp 986203
<ubot2> Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,New]
<ubot2> Launchpad bug 985737 in livecd-rootfs "Tasks selected in oem-config are downloaded, but not installed, or configured ..." [High,Fix released] https://launchpad.net/bugs/985737
<ubot2> Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,New] https://launchpad.net/bugs/986203
<infinity> pgraner: That would be a neat trick, since I only *just* fixed the bug.
<pgraner> infinity, well something happened in the .2 build, I got prompted for tasksel and ticked off lamp & postfix, and it installed them
<pgraner> infinity, while prompting me for the same questions 3 times
<infinity> pgraner: Let's just call that build a complete wash, and you can revisit your new bug a bit later. ;)
<infinity> pgraner: (The new livecd-rootfs is still building, so... It'll be hours before any images squirt out the other end)
<infinity> pgraner: I'm actually mildly amused that no one filed (which means no one noticed) the most glaring bug most ARM images had for two days, which was that the armhf images were actually armel. :P
<infinity> pgraner: (Fixed now, but argh)
<pgraner> infinity, there are no test cases for that specifically
<infinity> No, but you'd think manual testing would lead someone to notice it visually at some point.
<infinity> apt-get update output, etc.
<pgraner> infinity, have you seen the manual testing steps?
<infinity> No.  I'm guessing they're a bit light on fuzz testing?
<pgraner> infinity, I've added it to the automated testing TODO list and I'm updating the manual tests now
<infinity> But yeah, checking the architecture seems like a good thing for automation.
<infinity> i386/amd64 could well suffer the same oops.
<pgraner> infinity, for your amusement here is the test case for server http://testcases.qa.ubuntu.com/Install/ARM/Headless
<infinity> Anywhere where the target hardware can support more than one arch, people wouldn't even notice... Until they did. ;)
<pgraner> infinity, yep, on the list
<stgraber> I guess we could do with a generic "Make sure your media matches its description (flavour, architecture)" entry in the testcase wiki pages :)
<pgraner> stgraber, fixing now
<infinity> pgraner: That's.  Uhm.  Err.  I.  Dude.
 * cjwatson waits the requisite forever for ugene to test-build on ARM
<infinity> cjwatson: Didn't you hear?  We're getting fast hardware ANY DAY NOW.
<infinity> cjwatson: Obviously, yours just got delayed in the post.
<cjwatson> s/mine/Canonical's/, given that this is scheat :-P
<skaet> cjwatson, pitti, infinity - why did eglibc move from opportunity target to a Rebuild trigger?    Thought slangasek yesterday decided it was opportuntity target.
<cjwatson> Nowt to do with me.
<cjwatson> But I found a security flaw in the installer anyway, so ...
<skaet> infinity,  not seeing livecd-rootfs on the pad.ubuntu.com/ubuntu-release as a rebuild trigger,  and based on your comments in the backscroll?
<cjwatson> And I think we still need this new apt.
<infinity> skaet: We have other things going on, I figured it would just happen when it happened. ;)
<infinity> (Like the new apt)
<infinity> cjwatson: I reviewed it about 7 times before I accepted it, it seems good and pure and true.
<skaet> infinity,  makes it hard to pick up at start of new shift, if its not accurate.  :P
<infinity> cjwatson: mvo's testing the release-update-apt copy in his PPA, and should have tests some day.
<cjwatson> That's the pre-dep regression, right?
<infinity> Yeah.
<infinity> And a modifier bug.
<infinity> But the pre-dep thing is the killer.
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669591 - ha, right, nasty-ish in itself, but I agree
<ubot2> Debian bug 669591 in apt "apt: 'apt-get remove g++' is intrepreted as an install command (iprobably any package with a + at the end)" [Serious,Fixed]
<infinity> skaet: eglibc would be a trigger for kubuntu-alternate, which means it needs to be in the release pocket, which means it now triggers the world, cause it's on every image.
<cjwatson> added apt to the pad
<skaet> infinity,  yes,  understand but rebuild triggers are forcing functions (like apt),  opportunity targets are things we want to pick up if we can (kubuntu alternate could be release noted if we don't do a respin.)
<skaet> thanks cjwatson.
<infinity> Reading release notes are scant comfort for a completely broken upgrade.  Anyway, other things were pulled in anyway, hence the opportunity was taken.
<cjwatson> in this case it's moot.  eglibc is already built everywhere.
<cjwatson> and published.
<infinity> (I'm not the one that marked it as a trigger)
<infinity> Though I did copy it.
<stgraber> skaet: IIRC the reason to consider it as a rebuild trigger for kubuntu alternate was that without it you couldn't upgrade to 12.04 using the alternate media. No amount of release noting would have worked around that, besides asking people to wait till the point release.
<infinity> stgraber: Well, release notes can work around it by telling people to use a network.  But that assumes they read the release note before they hose their system with a mid-upgrade explosion. :)
<cjwatson> "Ubuntu Netboot: [3]" is that a request for me to rebuild debian-installer against the new eglibc?
<stgraber> infinity: right and that someone who would have upgraded using the alternate CD (a pretty rare case) has internet connectivity ;) the only case where I use an alternate media as an upgrade source is precisely when I don't have connectivity...
<infinity> cjwatson: Ask the man in baby blue...
<skaet> stgraber,  infinity,  thanks.   Since we'll be respinning for the apt and ubiquity,  it will be picked up.
<skaet> cjwatson,  slangasek put in that indicator.
<skaet> I just updated the numbering so we could keep score,   best to get his input
<Laney> ^ fixes ppc ftbfs, bugfix
<cjwatson> it could well be that the formatting of the pad encourages just walking all the way down it blindly inserting [3].
<cjwatson> slangasek: do you really want a new debian-installer build for eglibc?  I wouldn't have thought a maintainer script fix made any difference, although I suppose you might want to pull in final binary objects
 * skaet nods
<infinity> cjwatson: Having the binaries match the archive is nice, ish.  Though, they don't match in the d-i case anyway.
<infinity> Cause mklibs does bad, bad, bad things to them.
<stgraber> hmm, looking at the pad, souldn't python2.7 be considered as a rebuild trigger for the same reason as eglibc then?
<stgraber> people upgrading using an alternate media will have the python upgrade failure unless the fixed python2.7 is on the media
<infinity> stgraber: Opportunity knocks.
<infinity> stgraber: Copy it before one of the other triggers is copied, and the debate's not worth having.
 * infinity points at livecd-rootfs.
<infinity> Oh, but it's still building on arm*. :)
<stgraber> yeah, ETA is less than an hour based on previous building time
<infinity> Oh, I should probably note xorg somewhere.
<infinity> Are we still wikiing for promotion?  Or padding?  I lose track. ;)
<cjwatson> sorry, my network is a bit flaky this afternoon
<cjwatson> 15:38  * cjwatson points at ubiquity.  Please review
<stgraber> cjwatson: looking
 * infinity heads out for an off day.
<stgraber> cjwatson: +1
<skaet> infinity,  why can't xorg-server be handled as SRU?
<cjwatson> stgraber: ok, accepted, thanks
 * cjwatson copies apt
<skaet> stgraber, infinity,    need MUCH more background before the xorg-server one is pulled in - not sure why it can't be considered SRU.
<skaet> (a bug number would be nice too)
<cjwatson> there is a bug number.
<cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<infinity> skaet: It makes touchscreens pretty much unusable without also having a mouse handy to upgrade to the SRU.
<cjwatson> copied to the pad now.
<cjwatson> (but having to copy all this stuff around manually is really error-prone)
<infinity> skaet: Not HUGELY critical, because we probably don't have many touchscreen-only users, but nice to fix.
<skaet> infinity - can it cause regressions on the other parts?
<highvoltage> stgraber: I just realised that the edubuntu wallpapers (the additional ones) doesn't show up in the gnome wallpaper list. is that something fixable (even if it's by SRU?)?
<skaet> or localized scope only.
<slangasek> doko, pitti: that gdb block is from skaet, not me
<pitti> skaet: gdb> we'll do it as an SRU, no need to squeeze into release
 * skaet nods
<chrisccoulson> hi. is there any chance of getting bug 985862 on the CD?
<ubot2> Launchpad bug 985862 in ubufox "Update the start page URL" [High,Triaged] https://launchpad.net/bugs/985862
<pitti> chrisccoulson: so AFAIK we'll need a respin for ubiquity and some others
<stgraber> highvoltage: should be fixable as SRU yes, can be uploaded to -proposed already and used as opportunity target if we need to rebuild edubuntu for some other reason
<pitti> chrisccoulson: so if you have an upload ready, please uplaod it RSN
<infinity> skaet: Looked pretty localized to me, but like I noted, wait for cnd to give testing feedback.
<chrisccoulson> pitti - ok, will do. do you want me to use proposed?
<stgraber> highvoltage: do you now exactly what's wrong and needs fixing? if it's trivial, I'm happy to fix that quickly now as we're planning a rebuild anyway
<pitti> chrisccoulson: it can never hurt, yes
 * infinity really goes now.
<highvoltage> stgraber: I don't have the exact details, but I guess I'd look at the package that installs the community wallpapers and do the same
<cjwatson> Laney: haskell-hashtables> nice, thanks, accepting
<pitti> chrisccoulson: did something at the google side change recently which made this necessary?
<cjwatson> would be nice to let the agda stack clear
<highvoltage> stgraber: sorry I don't have a more useful answer at this point... maybe I can have an answer for you in a minute or two
<Laney> yep. credit has to go to Joachim for investigating the fix though
<stgraber> highvoltage: ok, I'm having a look now while waiting for test installs to finish running
<stgraber> highvoltage: can you file a high priority bug against edubuntu-artwork for it please?
<highvoltage> stgraber: ok thanks a lot
<highvoltage> stgraber: yep
<stgraber> highvoltage: right, I have a fix for it, testing it now
 * skaet heading to weekly meeting in #ubuntu-meeting
<cjwatson> anyone know what's with libpg-java in NBS?
<highvoltage> stgraber: LP: #986231
<pitti>   * Change binary package name to libpostgresql-jdbc-java.
<pitti>       (closes: #336245)
<pitti> cjwatson: ^
<cjwatson> ah; is somebody sorting out the rdeps?
<pitti> cjwatson: I'll add a transitional package back
<cjwatson> ok
<pitti> not sure who requested that, perhaps the sync request says; looking
<Laney> https://lists.ubuntu.com/archives/precise-changes/2012-April/015366.html
<cjwatson> oh, yeah, I think he sent me mail about that
<cjwatson> expect he cared about the new upstream ...
<Daviey> pitti: I've just arrived home.. will catch up on this shortly.
<pitti> Daviey: ah, you were on a conference? welcome back
<Daviey> pitti: glad to be back.. :)
<slangasek> skaet: I put it as 'rebuild trigger' initially, then thought out loud some more, and never changed it on the pad... stgraber makes the point that not taking it will break one of the supported upgrade paths, i.e. using the kubuntu alternate CD as an apt repository.  But this is all moot now since I see eglibc 0ubuntu10 is in. :)
<slangasek> cjwatson: debian-installer build> eh, no - if I put that it's because I wasn't reading closely
<skaet> thanks slangasek for the clarification.
<cjwatson> slangasek: trigger dropped then, thanks
<kenvandine> the gwibber-service-sina and gwibber-service-sohu  uploads are important for the china-images
<stgraber> fix for bug 986231 uploaded. As marked on the pad, would be great if this could be in the next Edubuntu build. It's not critical as someone can certainly wait a few days to get their wallpapers but the bug was caused by an invalid .xml file, so that should be easy to review and is a quick build
<ubot2> Launchpad bug 986231 in edubuntu-artwork "Edubuntu wallpapers are not displayed in Gnome appearance properties" [High,Confirmed] https://launchpad.net/bugs/986231
<stgraber> (built and tested locally)
<stgraber> highvoltage: http://paste.ubuntu.com/938407/ is the fix. Apparently gnome-background's xml parser was being really nice to us in the past as these wrong tags have been there since maverick :)
<highvoltage> stgraber: ah, ok!
<stgraber> (the _name was meant for translations but we don't have the translation infrastructure (and never had))
<pitti> ^ should make http://people.canonical.com/~ubuntu-archive/nbs.html happy again
<pitti> review appreciated
<Riddell> pitti: looking
<pitti> Riddell: thanks
<cjwatson> ogra_: I realise that it helps for big updates if the linaro tree is synced up, but I don't see why it has to be that way for every single patch.  You could quilt push/quilt refresh and then it's just a question of conflict resolution
<cjwatson> and send the linaro people the resulting delta
<ogra_> cjwatson, putting the gles patch on top again and then doing a push and refresh reverts the fix from the patch, i have to diff from scratch again
<cjwatson> that's misuse of quilt somehow - this is perfectly doable
<cjwatson> but it's very hard to debug at a distance
<cjwatson> if this is still a problem by UDS then perhaps we should sit and walk through an example
<cjwatson> FWIW I do functionally equivalent stuff *all the time* with Debian vs. Ubuntu patches to grub2
<ogra_> well, the prob is that we have bzr trees where fixes are applied alongside with quilt patches in the compiz case
<cjwatson> that may require some extra thought, but it does not require rediffing from scratch
<stgraber> LP's done diffing edubuntu-artwork, would appreciate if someone could quickly review it
<pitti> stgraber: looking
<cjwatson> beat you
<cjwatson> looks sane, accepted
<stgraber> thanks
<pitti> stgraber: oh, were these meant for i18n, and be .xml.in?
<ogra_> bug 770283
<ubot2> Launchpad bug 770283 in compiz-core "[fglrx]title bar does not update on non-maximized windows" [Medium,In progress] https://launchpad.net/bugs/770283
<stgraber> pitti: yeah, I think we copy/pasted from ubuntu-wallpapers a while ago but didn't implement the translation infrastrcture :)
<cjwatson> ogra_: I'm not saying this is easy to get one's head around - just that this *is* doable with these tools without the level of difficulty you've been describing, and so we ought to figure out what difficulties can be smoothed over
<stgraber> pitti: for 12.10 I'll probably move that to .xml.in and add the po generation magic
<cjwatson> the bit about reverting the fix from the patch is definitely not an intrinsic property of your setup
<cjwatson> not saying it doesn't happen, I can see how it might, but it's a question of slightly different use of tools
<ogra_> yeah, probably
<cjwatson> probably a matter of making sure you're popped down to the common base patch level before merging
<Riddell> skaet: actually it might be !testers in #kubuntu-devel I forget which
<cjwatson> or something along those lines
<ogra_> well, i dontn really touch quilt manually, i only copy the .patch file in place the way it is now ...
<ogra_> both trees are set up in a way to have identical content apart from the linaro gles code changes so diffing betwen them is the easiest way, but indeed that means to update every time quilt in the package is updated
<NCommander> infinity: :-P
<stgraber> python2.7 is done building
<pitti> ogra_: you can't convince upstream to take the patch? :-)
<ogra_> pitti, not for 12.04, it will be in the 12.10 upstream tree
<ogra_> (note that this discussion is going on since two years, i'm massively happy to have *something* now, even though its horridly painful to maintain)
<ogra_> sadly it isnt just easily #ifdef'able
<ogra_> hmm, seems the ac100 .bootimg md5sums are incorrect once again
<pitti> http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> there, that's better
<pitti> cjwatson: ^ (empty again)
<cjwatson> thanks
<ogra_> skaet, so if uploading compiz today is mandatory for getting it into the images, the fix that blocks my upload is for bug 770283 ... looks like upstream is happy with it by the last comment on the bug
<ubot2> Launchpad bug 770283 in compiz-core "[fglrx]title bar does not update on non-maximized windows" [Medium,In progress] https://launchpad.net/bugs/770283
<skaet> Riddell,  ok.   I'll figure it out for the !testers call.
<skaet> Riddell,  how are ReleaseNotes looking for Kubuntu?   What's left?
 * skaet would like to get some docs team editors working through them,  so grammar/spelling/awkwardness gets polished up.
<stgraber> infinity: could that have been caused by the switch to ext4? https://launchpadlibrarian.net/102695780/wubi-12.04-rev265.log
<skaet> ogra_,  looking
<stgraber> (log above is from bug 986246)
<ubot2> Launchpad bug 986246 in wubi "Couldn't find valid filesystem superblock. during Wubi install" [Undecided,New] https://launchpad.net/bugs/986246
 * stgraber boots Windows
 * jibel tries wubi
<pitti> jibel: python 2.7.3-0ubuntu2 in precise-proposed was verified to work, right? and it just adds the conflicts
<pitti> jibel: would moving that to precise instead of 0-day SRU fix the bug with the offline cdrom upgrade?
<pitti> or is that a different cause?
<pitti> doko: ^
<pitti> anyway, I think we should copy it to -release
<pitti> skaet: ^ any objections?
<doko> pitti, the offline upgrade is another issue
<skaet> pitti,  is it just adding the conflicts?  nothing else?   if so,  no objections.  If something else in there... need to understand more.
<doko> which should be fixed in the release upgrader
<pitti> skaet: yes, http://launchpadlibrarian.net/102670659/python2.7_2.7.3-0ubuntu1_2.7.3-0ubuntu2.diff.gz
<pitti> and if it's not _that_ bug, it's still a bug you'd see when doing a cdrom upgrae
<jibel> pitti, 2.7.3-0ubuntu2 fixes main all upgrade.
<pitti> ok, copying
<skaet> thanks pitti,   no objections.
<skaet> ogra_ can we line up some immediate focused testing on your fix and this specific one that will end up included as well,  so we can revert if there are surprises?
<ogra_> skaet, i cant test fglrx ...
<ogra_> since i dont have the HW
<skaet> what I'm worrying about is that one is pervasive to all the platforms, and yours is specific to arm... less risk.
<ogra_> my patch was heavily tested by alf and rsalveti already
<ogra_> according to https://code.launchpad.net/~sil2100/compiz/workaround_770283/+merge/102505 lukasz fix has been tested though
<ogra_> and smspillaz nodded it off as well
<skaet> pitti,  any thoughts here?   from the changelog in the bug, and ogra_'s comments,  I'm tempted to take the risk,  and revert it out if problems show up over the weekend.
<skaet> on the other hand,  we need to keep the stability, and don't have apport on to alert us if we suddenly start seeing crashes.
<pitti> well, we'll have the reports in whoopsie, but I don't think that's accessible yet
<pitti> skaet: I'm afraid I don't have a qualified answer here, just gut feeling
<skaet> pitti, gut feeling please
<pitti> ogra_: this was tested on fglrx, was it tested on intel and nvidia, too? and arm/gles?
<ogra_> pitti, no, only the arm side has been tested
<pitti> skaet: I'd take it if we have, or can get, this ^ hw coverage
<ogra_> but according to the merge request the fglrx fix has been tested separately already
<pitti> right, that leaves nvidia and intel
<slangasek> skaet: I've not caught the full thread and am otp, but I'm concerned about the idea of compiz changes right now for things other than ARM... what's the bug proposed for fixing here?
<skaet> https://code.launchpad.net/~sil2100/compiz/workaround_770283/+merge/102505
<skaet> Its not release critical, and certainly SRU candidate
<skaet> but its getting in the way of ogra_'s changes.
<skaet> and untangling things in bzr is what he wants to avoid,  I think.
<ogra_> right
<skaet> ogra_'s fix is scope limited, and improves the situtation.
<skaet> the interaction of this blocking one is risky, and has regression potential.
<ogra_> especially since untangling now doesnt get me anywhere, i will have to untagle again after the SRU
<ogra_> so for the gles fix its either go now *with* the fix ... or wait until after (or with) the SRU
<jibel> I confirm bug 986246 . wubi's broken
<ubot2> Launchpad bug 986246 in wubi "Couldn't find valid filesystem superblock. during Wubi install" [Undecided,New] https://launchpad.net/bugs/986246
<stgraber> jibel: ok, I'm looking at it now
<stgraber> jibel: it might be fixable by upgrading resize2fs to a newer version
<pitti> skaet: it's a bit on the knee-jerk side for my taste, but I think your guess is as good as mine :/
<cjwatson> stgraber: ew
<skaet> ogra_ do you know any good way of getting some testing on the combination of fixes on nvidia and intel?   Yes,  I agree pitti - its feeling too risky.   We're going to need to play it safe and defer to SRU.
<cjwatson> stgraber: let's revert to ext3
<ogra_> well, if its really such a headdache ... we dont ship gles drivers on the images, people have to pull tem from the net post install, they would have to make sure to update to -updates them as well to have something working
<cjwatson> infinity: your livecd-rootfs changes don't seem to be pushed to lp:livecd-rootf
<cjwatson> s
<ogra_> while thats inconvenient it probably has less risk if i upload to proposed now and we leave it like that
<skaet> ogra_,   user base of this platform is more experienced than the others that could get impacted if we guess wrong.
<ogra_> thats indeed true
<ogra_> (as 0 day SRU i meant above)
<stgraber> cjwatson: right, that works too. I'll do a bit of debugging here and send a merge proposal against wubi trunk so that we have that fixed for 12.10 at least
<cjwatson> wait, why wubi trunk?  I thought you meant resize2fs in e2fsprogs
<cjwatson> oh god, it ships its own for Windows or something doesn't it
<ogra_> fun
<stgraber> cjwatson: right we have resize2fs.exe in wubi.exe
<stgraber> cjwatson: I'm guessing upgrading it to a newer version will fix it but I want to make sure
<cjwatson> ./blobs/resize2fs.exe
<cjwatson> shudder
<cjwatson> how is this not a GPL violation?
<skaet> ogra_,  pitti -  ok.  get it in -proposed,   and SRU will be the plan for it.    Lets try to round up testers and get the combination checked out on the other hardware.
<ogra_> k
<cjwatson> ev: ^-
<gema> skaet: we've found a problem in the arm server install, bug 986203
<ubot2> Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,Confirmed] https://launchpad.net/bugs/986203
<gema> skaet: the good news is that it installs in the end
<skaet> gema,  thats good news, so release notable then at least if we can't get a fix in time.
<skaet> slangasek, is there anyone with bandwidth to look at it today?  ^
<stgraber> cjwatson: I'm building a new wubi now here using what I think is a newer version of the blob that was used (basically extracted version of resize2fs.exe from the current cygwin release)
<slangasek> ogra_: so what's the real impact of the gles bug?  You said before "people sometimes don't get window decorations"; rickspencer3 tells me it's "compiz segfaults and that's all she wrote".  Sorry if I'm making you repeat yourself, but I'd like to understand if the impact on ARM is really something you should be busting your but to fix in .0 or if an SRU of the whole thing would be better
<ev> cjwatson: "An alternative method of satisfying the copyleft is to provide a written offer to provide the source code on a physical medium (such as a CD) upon request"
<ev> pretty sure that's just the mingw resize2fs
<cjwatson> gema: infinity wanted to wait until after his livecd-rootfs changes had landed to see what the effect of those on that bug would be
<slangasek> skaet: "today"> probably not, infinity is off and stgraber has migrated east for the spring, so it's pretty much EOD for the lot
<ogra_> slangasek, the first gles fix reverted all other quilt patches (the gles branch didnt have any of them applied) the window decorator bit is only one fallout
<cjwatson> ev: where's that written offer?
<gema> cjwatson: ack, we'll retest on monday then?
<slangasek> cjwatson: where in the pipeline are those livecd-rootfs changes now?
<slangasek> I can get out and push if need be
<ogra_> slangasek, if we dont have the gles patch in the package, compiz dsegfaults and doesnt run on arm at all
<cjwatson> slangasek: in precise, not in bzr
<cjwatson> I'd like to copy ubiquity though
<cjwatson> looks like it's built, so doing that now
<ogra_> slangasek, and as discussed above, i will now upload a 0 day SRU to -proposed so it gets testing on nvidia and intel
<ogra_> just quickly doing a testbuild on x86 before uploading to make sure everything is fine
<cjwatson> ev: (also, it sucks for us anyway, because it hamstrings our agility in e.g. applying patches to it or upgrading to a new upstream version)
<skaet> slangasek,   ^^ SRU will be the plan for it.
<slangasek> stgraber, cjwatson: FWIW I'm in favor of reverting to ext3 for wubi instead; that was the rough agreement when we flipped the switch late, I don't want us to be chasing "just one more bug" all week
<cjwatson> I'm absolutely in agreement
<cjwatson> I would have done it already if infinity's livecd-rootfs changes had been in bzr
<slangasek> aha
<cjwatson> wait, that change wasn't in l-r, was it
<stgraber> slangasek: yeah, I'm fine with that. I just want to have a wubi branch ready with ext4 support for 12.10
<slangasek> stgraber: sure, that's fine
 * skaet nods
<slangasek> cjwatson: bug #859552: live-build?
<ubot2> Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,Fix released] https://launchpad.net/bugs/859552
<cjwatson> Daviey: your debian-cd change for MAAS broke translations
<cjwatson> Daviey: tolerate or revert?
<cjwatson> Daviey: oh, meh, never mind, the MAAS version of that wasn't translated anyway :
<cjwatson> :P
<slangasek> ogra_: ok, if everyone's agreed that it's ok to punt compiz to SRU, I'm perfectly ok with that; otherwise I was going to offer to help untangle the merge today
<cjwatson> somebody should file a gfxboot-theme-ubuntu bug for that ...
<cjwatson> slangasek: yes, and cdimage I think
<slangasek> yep
<cjwatson> I'll deal with it then
<slangasek> cheers
<ogra_> slangasek, there is nothing to untangle ... its broken by design (though cjwatson seems to have an idea how to design such stuff better)
<ogra_> (for the future)
<skaet> :)
<slangasek> ogra_: "untangle" meaning "allow your patch to go in cleanly, on its own, against the package already in precise"
<ogra_> slangasek, thats no prob i could do that now ...
<slangasek> oh?
<slangasek> clearly I've misunderstood the concern then
<ogra_> slangasek, but i have to invest another half day to do it again right after the pending fix was uploaded
<ev> cjwatson: I agree that it's not ideal, but it's not like we put a GPL licensed body of work in some proprietary code. Last I checked, we didn't provide menu options for how you get the source code to all our packages.
<ogra_> the prob is that the gles patch is always the last quilt patch
 * skaet goes to get the pad caught up with the discussions in the last hour....
<ogra_> so as soon as one quilt patch changes underneath, the gles one has to be updated
<ev> I'm not trying to set up a strawman mind, I just don't see how this differs wildly from anything in the archive from a user perspective
<ogra_> (thats what i mean by broken design)
<cjwatson> ev: Oh come on, menu options != written offer
<slangasek> ev: everything in the archive has the source sitting alongside it in the same directory, and every binary package has a copyright file telling people the license
<cjwatson> there's a minimum legal requirement here and we aren't meeting it
<cjwatson> we can't excuse that using arguments about user-friendliness
<ogra_> ok, compiz uploaded
<slangasek> ev: you may not have noticed how strictly we adhere to the GPL elsewhere because this is all inherited from Debian and the bugs were shaken out long ago ;)
<slangasek> but it does matter... Ubuntu should not be playing fast and loose with free software licensing
<ev> so the legal requirement is that the license sit in a specific directory? I'm looking for this online but have not found it thusfar.
<cjwatson> No, the legal requirement is not that
<cjwatson> Please show me the written offer for corresponding source to resize2fs.exe
<cjwatson> (It should accompany every object-code distribution of resize2fs.exe)
<ev> so the full license merely has to be installed at the same time?
<cjwatson> A license isn't an offer of corresponding source
<cjwatson> Certainly we should install the licence
<cjwatson> But even I have no idea where to find the corresponding source for resize2fs.exe
<slangasek> ev: the requirement is that, when you distribute a binary, the recipient knows it's GPL and there's some way to trace it back to the source
<slangasek> like cjwatson says, if *we* can't even find the source, we're clearly not fulfilling that req ;)
<phillw> such things as the license are usually placed at the bottom of the man page for things like resize2fs?
<ev> I'm not arguing that we are meeting the requirement
<cjwatson> phillw: no, they're in /usr/share/doc/*/copyright
<ev> I am trying to get some understanding of how much flexibility we have here
<pitti> FWIW, we outright reject stuff in NEW which is GPLed and has no source
<cjwatson> I'm actually kind of worried by the suggestion that we need flexibility; Ubuntu should find it very easy to comply with the GPL
<phillw> cjwatson: never looked in there, but am on first name terms with man :D
<pitti> e. g. PDFs, and of course binary blobs
<stgraber> I think we should probably use the source tarball from cygwin and build it in our build process (so we know the binary matches) and ship the resulting resize2fs.exe in its own directory with the LICENSE
<stgraber> considering we already build Windows stuff in the wubi build process, it shouldn't be impossible to do that too
<cjwatson> phillw: there's no legal requirement that the licence be in any particular place; the standardised positioning in /usr/share/doc/*/copyright is for the benefit of archive admins, but that doesn't apply to Wubi since it isn't built as a standard binary package
<cjwatson> (well, not entirely for the benefit of archive admins, it's useful to other people too)
<slangasek> cjwatson, ev: I'm not sure we should consider this a stop-ship issue for wubi since it's not a new issue, but we should certainly fix it for .1
<stgraber> (or we can assume that the .src.tar.gz and the .bin.tar.gz on the cygwin ftp mirror match and then just write a reference to that in a file)
<cjwatson> I agree, it's just that I only just noticed it
<cjwatson> stgraber: which is fine as long as we can argue that our redistribution is "non-commercial"
<cjwatson> (GPLv2 3c)
<cjwatson> we generally don't use 3c because it's more trouble than it's worth in practice
<cjwatson> (for us)
<pitti> have a nice weekend everyone! please call my mobile if there's something urgent
<slangasek> later, pitti :)
<ev> so how hasn't all of Wubi been a GPL violation if the requirement is that the recipient knows that it's GPL? It surely doesn't say that anywhere in the UI.
<ev> Again, just trying to get an understanding of this.
<cjwatson> that's a misstatement of the GPL
<cjwatson> it doesn't require UI presentation (unless you received it that way, in which case GPLv2 does not permit you to remove it)
<cjwatson> the information has to "accompany" the object code
<cjwatson> you have "flexibility" in exactly where that information goes
<phillw> how are the alternate respins coming along, seems like all flavours are getting one?
<cjwatson> I expect a court would apply some kind of reasonableness test
<cjwatson> phillw: not started yet
<phillw> he he, that will explain the delay, then :)
<ev> so even though Wubi is built from a bzr branch that you have to know how to get at, this aside, it's perfectly in compliance with the GPL because the source lives in that branch and has license files in it?
<cjwatson> I don't recall right now whether our Wubi distributions have any kind of licence indication accompanying them
<cjwatson> It may well not be in strict compliance
<ev> okay
<slangasek> ev: has to accompany the *object* code... if there are parts of Wubi that are compiled, we're not in compliance there either unless the pointer to the source is included somewhere with what we ship
<cjwatson> slangasek: there are
<cjwatson> if nothing else it includes bits of grub
<slangasek> righto
<ev> the whole thing is compiled, surely. I mean, if nothing else we ship python byte code.
<slangasek> has anyone on the release team looked at this update-manager yet?
<cjwatson> please review live-build
<cjwatson> I'm pushing up the cdimage change now
<slangasek> update-manager is an LTS->LTS upgrade issue only, so it could be left for .1
<slangasek> skaet: ^^ should I ask mvo to reupload to -proposed?
<slangasek> cjwatson: looking
<skaet> slangasek, looking
<cjwatson> ev: I think that for example one way to be in compliance would be to put licensing information alongside wubi.exe on cdimage/releases and on the CD as a separate file, and for all links from our website to have a licensing link next to them
<slangasek> cjwatson: rejecting, you didn't change series
<slangasek> instaftbfs
<cjwatson> slangasek: didn't need to, it didn't revert the whole patch
<slangasek> oh
 * slangasek looks harder
<slangasek> ah indeed
<ev> cjwatson: okay
<slangasek> cjwatson: anti-rejecting ;)
<cjwatson> that is, if there isn't some other standard way to embed visible licensing information in a Windows binary
<cjwatson> well, I don't know if we might need to ensure that the licensing stays on the installed system since we're copying bits of object code around
<cjwatson> but that's a detail, I think
<cjwatson> slangasek: it does test-build cleanly locally, though I'll admit I hadn't previously checked :)
<slangasek> ubiquity sync is in the precise/unapproved queue, does that need a manual accept?
<slangasek> cjwatson: ok :)
<cjwatson> whoops, yes, done
<cjwatson> really must arrange some kind of auto-accept scheme there
 * slangasek nods
<skaet> slangasek,  want to get the LTS->LTS experience as shiny as possible out of the box.   Have scanned through it, and it also contains fix for kde update's  if you could take a review pass,  I'd rather let it in.
<slangasek> skaet: even though we don't encourage LTS->LTS upgrades until .1?
<slangasek> and the reason we don't is to put additional polish on that upgrade between now and then, which means anyone *actually* using the .0 alternate CD for an LTS->LTS upgrade is still going to have a poorer experience?
<slangasek> skaet: the kubuntu fix is nothing more than a change to the package description - zero-risk
<skaet> slangasek.   ok.   if kubuntu fix is zero -risk.   clean there.   what is the downside of accepting it now?
<slangasek> a) one more thing we have to wait for before respinning, b) I have no idea what that variable we're un-setting actually does and don't have time to dig deep on it
<skaet> (I am fine with it be reuploaded to -proposed, as an SRU, but fix would be nice to have if regression risk is low)
<slangasek> actually, it needs reuploaded to -proposed regardless
<slangasek> because it's arch: any/all skew
<slangasek> well... but let me check the build times
<slangasek> nah, ok, < 5 minutes to build
<slangasek> so if we accept it now, they'll all be in sync
<skaet> slangasek,  gah,  just rejected it.
<slangasek> skaet: but do we want to accept it, or do we want to SRU it and put it through a longer QA?
<cjwatson> that's what the rejected queue is for ;-)
<slangasek> we can always unreject ;)
<skaet> slangasek,  if we have a set of knowledgable eyes able to look at it, I'd prefer to accept.   We will revert, and I think it will get more testing if its in the candidate images for community testing this weekend.
<mvo> slangasek: well, its a cdrom upgrade issue only, so it would be good to have it on the cd
<skaet> s/revert/revert if any regressions/
<slangasek> mvo: again, it's a CD that we're a) not pressing, b) not going to tell people is good for LTS->LTS upgrades anyway
<mvo> slangasek: ok
<slangasek> but ok - at this point have spent more time discussing than the bug is worth ;)
<slangasek> so I'll accept it
<mvo> sorry
<cjwatson> of course people are going to use it regardless of whether we recommend it
 * skaet nods
<slangasek> skaet: I don't think you can count on community testing of CD-based upgrades... I don't think we even have an ISO test case for that?
<mvo> fortunately the auto-upgrader-tester will tell us any issues by tomorrow
 * slangasek nods
<slangasek> mvo: does the python-central fix need to be accepted at the same time?
<slangasek> I haven't reviewed that one yet
<mvo> slangasek: I don't know, doko will know though, my change is entirely based on what doko told me :)
<slangasek> ok
<slangasek> u-m accepted
 * skaet --> food,  biab
<slangasek> looking at p-c
 * mvo -> evening
 * slangasek waves to mvo
<slangasek> thanks :)
<doko> slangasek, no, if the update-manager patch is in, then the python-central change isn't really necessary, and it's universe now anyway ...
<slangasek> doko: so with the u-m patch, this p-c change only touches a dead code path?
<doko> slangasek, yeah, for the relevant case. but there were a fewer other unguarded ones
<slangasek> safe, per-se correct, universe - accepting
<doko> and away as well ...
<cjwatson> python-central (from python-central) is seeded in:
<cjwatson>   mythbuntu: daily-live
<cjwatson> but presumably we'll pick that up as a consequence of other things anyway
 * slangasek nods
<cjwatson> can I accept my own unseeded (per seeded-in-ubuntu) universe uploads?
<cjwatson> since those are only frozen due to LP inflexibility
<slangasek> AIUI yes
<cjwatson> good, that's what I thought
<slangasek> ogasawara: something's gone wrong on http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html, it consistently believes the desktop CDs are up to date :)
<ogasawara> slangasek: hrm, lemme investigate
<Q-FUNK> infinity: is there still any outstanding issue on that estonian FF plugin that needs to be fixed?
<highvoltage> stgraber: hmm, the distupgrade-fetcher seems to be failing in edubuntu atm
<highvoltage> stgraber: in the command line I also see "WARNING:root:file 'precise.tar.gz.gpg' missing". networking is fine and I also tried it with google dns just to make sure it doesn't happen because we hijack archive.ubuntu.com
<slangasek> fooey, update-manager managed to miss the publisher on armhf
<slangasek> so looks like a half hour wait before we can respin
<slangasek> skaet: other than that, AFAIK all the triggers on the pad are in - what do you want to do as far as respins today?
<skaet> slangasek,  based on what I'm seeing on the pad,  full set (except netboot) is appropriate.
<slangasek> right
<slangasek> sounds like we should hold off on edubuntu for the above though
<slangasek> at least until it's investigated
<skaet> agreed.
<slangasek> well, or at least until we know if it's getting investigated today, if stgraber is gone for the day :)
<skaet> slangasek,  did infinity share his timing results from last night's runs anywhere?
<skaet> re: edubuntu,  fine by me.  :)
<bdmurray> will the last update-manager upload fix bug 986201?
<ubot2> Launchpad bug 986201 in update-manager "fail to upgrade to 12.04 from 10.04" [Undecided,New] https://launchpad.net/bugs/986201
<slangasek> skaet: not to my knowledge, though AIUI that was mostly meant to be input for shuffling builders around server-side - should be invisible for us when running the pipeline
<skaet> if not,  I'll trigger the runs then when we're ready and pull out the timings I want.
<slangasek> bdmurray: yes
<skaet> ok
<slangasek> bdmurray: that's a duplicate of the bug in the changelog
<infinity> cjwatson: livecd-rootfs commit> left in a hurry, committed now.
<infinity> cjwatson: As for the resize2fs wubi thing, ARGH.
<infinity> skaet: If you don't mind, I'd like to trigger the preinstalled set on the next rebuild, but happy to cut and paste the results for you.
<infinity> skaet: (I haven't had a chance to test the latest iteration to see if it needs tweaking and/or straight-up fixing; was waiting for a rebuild trigger)
<slangasek> since it's only armhf that lagged behind on update-manager, and armhf is all preinstalled, I guess we could launch respins for the rest right now?
<infinity> Sure could.
<skaet> infinity,  if you're triggering cut and paste will work for me.
<infinity> slangasek: Do we have everything the other images want?
<slangasek> infinity: per http://pad.ubuntu.com/ubuntu-release, yes
<slangasek> (just double-checked that our "targets of opportunity" are all in -release, not -proposed)
<infinity> Check.
<slangasek> ok, I'll kick off the non-preinstalled run
<slangasek> (non-preinstalled, non-core)
<infinity> Go nuts.
<infinity> It'll bugger my preinstalled timing a bit, but I'll suffer. ;)
<infinity> update-manager-core | 1:0.156.14 |       precise | amd64, armel, armhf, i386, powerpc
<slangasek> can we drop the "or the long way" pipeline from the pad yet? :)
<infinity> ^--- u-m is fine now too.
<slangasek> infinity: yep - that one's all you anyway
<slangasek> respinning the world minus a forelimb
 * infinity looks as ps output on nusakan suspiciously.
<infinity> slangasek: You seem to have ubuntu building twice...
<slangasek> yes
<slangasek> know a reliable way to kill the first one?
<slangasek> my cut'n'paste caught a carriage return I didn't want :P
<infinity> D'oh.
<infinity> And no, on the builder side, it's all far too fragile to kill remotely.
<infinity> Human intevention, or wait out the ~15m.
<slangasek> I was going to let the first one spin itself out... should be fast enough
<Q-FUNK> gotta thank the horses for being such good sports in returning the carriage to the stables.
<skaet> yeah,  wait it out is best.
<slangasek> utlemming: are you steering cloud image spins?
<utlemming> slangasek: yes, sir
<slangasek> utlemming: so we have main quiesced for the moment and there are some fixes to be picked up, if you want to respin some candidates
 * skaet sees slangasek beating her to the next question on her checklist...  ;)
<skaet> lol
<slangasek> I'm trying to clear stuff off the pad ;)
<skaet> me hugs slangasek  :)
<utlemming> slangasek: okay, I do a respin, although I was planning on using Tuesday for the release candidate
<slangasek> utlemming: tuesday is rather late for us to fix if there are any problems
<infinity> Dearest nusakan, WTF?
<infinity> ubuntu preinstalled
<infinity> ubuntu-amd64 on kapok.buildd starting at 2012-04-20 18:31:01
<infinity> ubuntu-i386 on cardamom.buildd starting at 2012-04-20 18:31:01
<infinity> ubuntu-powerpc on royal.buildd starting at 2012-04-20 18:31:01
<infinity> ^--- Something's dreadfully wrong with this picture.
<cjwatson> haha
<cjwatson> hope I didn't lose a bit somewhere ...
<skaet> utlemming, getting some data now,  given alot of the churn that's been going on will be beneficial.
<utlemming> slangasek: right, we are doing daily builds of precise on EC2 up until the release
<skaet> utlemming,  anything thing significant showing up test case/bug wise on your radar?
 * infinity senses there may be some by-hand recovery here in a bit. :P
<slangasek> skaet: I may have forgotten to set CDIMAGE_POST_QA in my shell - is that still needed, or do we post everything to the tracker by default now?
<infinity> cjwatson: I'm failing to see how I can blame this on you.
<utlemming> skaet: none, yet. My dailies have been more or less clean for the last week, except for general EC2 bugginess
<skaet> slangasek,  its still needed as far as I can tell.
<skaet> and if you don't have it set,  manual time.
<infinity> slangasek: It happened automagically the last time I did builds.
<infinity> slangasek: YMMV.
<slangasek> skaet: ok, I checked and it is in my shell env after all
<cjwatson> rargh, I test-built ugene and now it FTBFS everywhere
<skaet> :)
<slangasek> hurray for never logging out of my shell
<cjwatson> Braces mismatch /build/buildd/ugene-1.9.8+repack/ugene.pro:37
<cjwatson> apparently I suck
<utlemming> slangasek: rebuild eta is 3 hours
<slangasek> utlemming: cheers :)
<utlemming> slangasek: I'll post the complete testing suite against this once its done
<cjwatson> obviously didn't test-build *that* one
<slangasek> infinity: can I assign bug #986203 to you for follow-through once the new images are out of the oven?
<ubot2> Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,Confirmed] https://launchpad.net/bugs/986203
<slangasek> or if you're ENOTIME I can kick it back to QA to re-test Monday
<infinity> slangasek: Well, I'll be testing Monday too.
<infinity> slangasek: Today, I think I might want to sort out why the heck "buildlive ubuntu daily-preinstalled" just tried to spit out all the non-preinstalled arches. :P
<slangasek> infinity: 'twas really a question of if you'd be testing today, since if we confirm the bug is still there some of us still on the ground might be able to poke at it blindly over the weekend
<infinity> slangasek: But after that, I might have time for testing.
<slangasek> yep
<slangasek> that's the priority, of course
<infinity> My Panda's oddly idle for the first time in a long time, so if I can coax images out, I'll spin one up.
<slangasek> oh, er, why are these powerpc builds still going to royal?
<slangasek> shouldn't that have been sulfur?
<infinity> You didn't get that memo? ;)
<slangasek> no
<infinity> sulfur's an lp-buildd now.
<slangasek> or maybe I got the memo but read it backwards
<infinity> I tested them against each other for live builds, and they were doing ubuntu-live within about 30s of each other.
<slangasek> right
<infinity> So, opted to throw the two extra cores at package builds.
<slangasek> yes - I got the memo and read it backwards ;)
<infinity> cdimage@nusakan:~/cdimage$ CDIMAGE_ROOT=. default-arches ubuntu daily-preinstalled precise
<infinity> armhf+ac100 armhf+mx5 armhf+omap4 armhf+omap
<infinity> Kay, so, I'm not insane.
<infinity> Maybe my environment in that terminal just got wildly buggered somehow.
<cjwatson> infinity: if you'd left ARCHES exported, that would override
<infinity> cjwatson: Nope.
<infinity> cjwatson: I'm pretty much just puzzled.
<infinity> But I'll wait until this run is done to worry about it.
<slangasek> infinity: could we at least get your extra powerpc build hard-killed, so royal isn't further bottlenecking?
<slangasek> since now there are 3 serialized builds of ubuntu holding things up when we only need one
<infinity> They're not even deterministically serialized.  I should fix that some day.
<infinity> (Just three processes spinning on a lockfile)
<slangasek> well, if you were to kill the currently-running build, that would be correct
<slangasek> since that's the one that my pipeline isn't going to see :P
<infinity> It's got to be almost done by now.
<infinity> I could kill mine from here.
<infinity> Maybe.  If I can sort out which ssh is me...
<slangasek> but killing the ssh client doesn't kill the queued job, AFAIK?
<slangasek> (remember my uncommitted changes futzing with tty passing?)
<infinity> There, killed mine.
<infinity> Oh, does it just disconnect and carry on its merry way?
 * infinity facepalms.
<slangasek> ye
<slangasek> s
 * infinity sighs.
<infinity> I'll go find a webop and see if we can unmess this.
<slangasek> do we need to raise SIGLAMONT?
<slangasek> ok
<slangasek> would love to get that fixed so we actually do have remote job control over them
<slangasek> since SIGINT is much cheaper to raise
<infinity> It might just be a question of changing authorized_keys to be slightly less draconian.
<infinity> I don't recall the contents of said file anymore.
<infinity> slangasek: I kinda want to blame the openjdk/amd64 build failure on your fontconfig changes, but I'm confused by why it didn't fail everywhere with the same errors.
<infinity> slangasek: And I think the response time on royal was a bit too long, we're down to only two BuildLiveCD jobs now.  Hopefully the active one is yours. :/
<infinity> slangasek: We could just kill the one that's still waiting on a lock; your cron.daily will pick up the latest livefs (which is obviously quite recent)
<infinity> Yeah, I'm going to do that.  Let's see if it's you.
<slangasek> infinity: wait
<infinity> ...?
<slangasek> doesn't that cause buildlive to exit non-zero?
<infinity> Oh, it does. :/
<slangasek> actually... that's ok
<infinity> At least, I think it does.
<slangasek> I can still just run cron.daily-live by hand
<slangasek> yah, kill it
<infinity> Did it go poof?
<slangasek> job from royal is gone, buildlive returned success, cron.daily-live running
<slangasek> so looks good
<infinity> Shiny.
<infinity> System administration via pastebin, it's all the rage.
<slangasek> so what's royal doing now?
<infinity> Still building the one I triggered, I believe.
<slangasek> ok
<slangasek> that's probably not worth futzing with further?
<infinity> I guess you want it for kubuntu, you greedy man?
<slangasek> I do at some point :)
<stgraber> highvoltage: I'll have a look. The automated dist-upgrade succeeded though so it's likely something to do with your setup (or some other upgrade weirdness)
<infinity> Well, get in line, I still have to build more ARM images on our PowerPC buildd.
<slangasek> fine, I'll build the powerpc images on my alpha
<infinity> You still have one that workd?
<infinity> s
<slangasek> <cough> no
<slangasek> I'm bluffing
<infinity> Hah.
<highvoltage> stgraber: ok, it was with a clean 11.10 install though, but anything is possible :)
<slangasek> stgraber: when you know the answer, please update the pad and ping me - I've held off respinning edubuntu in case other fixes are needed
<slangasek> grr, would it actually be faster for me to use jigdo on this alternate image download?
<stgraber> slangasek: I'll run another upgrade test now but in any case, our DVD only contains a livefs so can't be used for upgrades
<slangasek> stgraber: oh, so this is not DVD-affecting at all?
<stgraber> right
<slangasek> ok, I'll add edubuntu back into the pipeline
<slangasek> thanks
<stgraber> highvoltage: i386 or amd64?
<slangasek> stgraber: mazel tov, edubuntu gets to jump the queue for builds now because I've queued it in parallel
<skaet> :)
<highvoltage> stgraber: both do the same
<stgraber> yay!
<stgraber> highvoltage: ok
 * infinity wonders when we got 70 new packages that FTBFS on armhf...
<slangasek> infinity: link?
<slangasek> also, why do you think defoma is to blame for openjdk?
<infinity> slangasek: Oh, just complaints about missing font aliases.
<infinity> slangasek: But only on amd64, so it's hard to blame you.
<slangasek> what's the link for that one?
<infinity> https://launchpadlibrarian.net/102704979/buildlog_ubuntu-precise-amd64.openjdk-6_6b24-1.11.1-4ubuntu3_FAILEDTOBUILD.txt.gz
<slangasek> doesn't seem to be either in-archive or in the test rebuild?
<slangasek> ah, -proposed
<slangasek> so what's this about 70 new FTBFS?
<infinity> Maybe I snapshotted this at the wrong time, but I was pretty sure the above was before I did my mass-give-back.
<slangasek> is that related to cjwatson's give-back?
<infinity> And the bottom is now.
<infinity> http://lucifer.0c3.net/~adconrad/omgwtflol.png
<infinity> Colin's give-back was for the test rebuild, this is the archive.
<slangasek> hmm
<infinity> Given that ARM finished the give-back before powerpc, this can't have been mid-give-back.
<infinity> Since PPC is obviously on-par here, (modulo three things moving status)
<slangasek> so before these were given back, what were they?
<NCommander> yay
<infinity> Yeah, I have no idea.
<slangasek> k
<infinity> Wait, what?
<infinity> Where did those desktop builds come from?
<infinity> Oh.
<infinity> Hahaha.
<slangasek> not from me
<infinity> cron.daily did the right thing, even though buildlive didn't.  Of course.
<slangasek> heh
<slangasek> yep
<infinity> So, those desktop ones are useless.
<infinity> NCommander: The server ones should be okay, though.
 * slangasek disables the desktop ones again on the tracker
<NCommander> infinity: I didn't test the last spin, so I'll just spotcheck, and I need to finish the workload testing
<infinity> slangasek: And yeah, where those 70 builds came from, I have no idea, unless we're really synced 70 universe packages in the last 4 or 5 days that added arm to the arch list?  Seems unlikely.
<infinity> s/we're/we've/
<slangasek> infinity: yeah, I dunno
<infinity> Aaaand, I just nervously refreshed the old page when I meant to click on it and save the HTML so I could parse it.
<infinity> So, there's a mystery I'll never solve.
<infinity> Stupid habits.
<slangasek> stgraber: does the iso tracker no longer support declaring a default milestone?
<slangasek> (for adding builds to)
<NCommander> wow
<NCommander> new images
<stgraber> slangasek: correct, in the past it wasn't really a question of default milestone so much as the only milestone that wasn't archived
<stgraber> slangasek: now that more than one milestone can be active at the same time, the xmlrpc client needs to know which one to add the build to
<micahg> Daviey: skaet: I'm going to sponsor Bug #986314 and bug 986159 to -proposed, can we pick those up if there's an Ubuntu server image respin
<ubot2> Launchpad bug 986314 in squid3 "squid3 missing pie and bind-now hardening options" [Undecided,New] https://launchpad.net/bugs/986314
<ubot2> Launchpad bug 986159 in squid3 "squid3 open file descriptors limit is set incorrectly" [Undecided,Triaged] https://launchpad.net/bugs/986159
<slangasek> stgraber: hmm, I thought there used to be an option on the milestone page to set a "default" - given that some builds are still not added with the xmlrpc client, that could still be useful I guess
<slangasek> (but not a high priority)
<skaet> micahg,  ack.    we'll add to pad as opportunity target, if server team agrees, and we need a respin.
<cjwatson> infinity: I don't think ARM finished the give-back before powerpc.  I'm sure I looked earlier to see powerpc done and armhf still going.  And those ARM numbers look about right for pre-give-back to me.
<infinity> cjwatson: Mmkay.  I could just be losing my mind in my old age.
<infinity> I think it's turned to jelly and migrated to my abdomen.
<infinity> rsalveti: Speaking of xbmc (since the queuebot just reminded me), did you arm changes fall prey to ENOTIME?
<superm1> infinity: the changes that rsalveti did should be upstream now, and that's why i was requesting the s ync
<slangasek> infinity: I disclaim responsibility for that openjdk-6 failure; the defoma integration was trivial and removing it should have no impact on fontconfig's own cache
<infinity> superm1: I see no mention in the synced version of patches.
<superm1> although micahg just pointed out the builds are failing on experimental (https://buildd.debian.org/status/package.php?p=xbmc&suite=experimental)
<infinity> superm1: All he did was change it back to arch:any, he didn't actually fix anything.
<slangasek> the integration was for exposing fontconfig-registered fonts into defoma rather than vice-versa, so
<superm1> infinity: it's with the "new upload of eden branch" and then the separate patch to run with sytem tinyxml
<infinity> Oh.
 * infinity is too tired to keep track of pretty much anything at this point.
<infinity> Maybe it's time to veg out and do laundry.
<highvoltage> infinity: heh, I also do that when my brain stops braining
<stgraber> skaet, slangasek: Apparently something was broken on highvoltage's network when running the Edubuntu upgrades (likely that hidden transparent proxy ...). I'm not done running them here but I'm much further than where highvoltage was and didn't see any problem downloading precise.tar.gz here.
<Q-FUNK> chrisccoulson: please check your e-mail. :)
<stgraber> oh, more work, yay!
<slangasek> stgraber: ack
<skaet> stgraber,  good to hear.
<stgraber> slangasek: hmm, I'm wondering if the new python2.7 didn't break the upgrades...
<slangasek> it did
<stgraber> oh good, happy to know it's not an Edubuntu specific issue then ;)
<slangasek> who accepted this?
<slangasek> because there needs to be a lot careful consideration given to adding Conflicts to core packages the week before release
<infinity> I can tell you who copied it...
<slangasek> infinity: you, or?
<infinity> [ubuntu/precise] python2.7 2.7.3-0ubuntu2 (Accepted)   Martin Pitt
<infinity> Handy side-effect of that awful misfeature.
 * slangasek nods
<stgraber> oh, the whoever copies appears as the uploader feature :)
 * infinity nods.
<slangasek> skaet: jibel has just reported that all the oneiric->precise upgrades are broken by this python2.7 update
<infinity> Of course, all tests failed before this upload too..
<slangasek> no, the *other* tests failed before this upload
<slangasek> it was only causing lucid->precise upgrades to fail
<infinity> Oh, I missed the "oneiric" in your line there.
<infinity> Right.
<slangasek> the only reason lucid upgrades are faring better is because of the backported apt
<slangasek> and so the respins we just did are useless
<slangasek> ah no, it's not the backported apt that matters, it's that python-minimal depends on python2.7-minimal already in oneiric
<slangasek> jibel: thanks for letting us know about bug #986374
<ubot2> Launchpad bug 986374 in update-manager "oneiric->precise upgrade failed: E:Internal Error, Could not early remove python-minimal" [Undecided,Confirmed] https://launchpad.net/bugs/986374
<infinity> The real problem here is an unexpressed dependency, quite obviously.
<slangasek> jibel: how much time do you have available today for retesting?
<infinity> I wonder if the loop could be avoided with a gentle sprinkling of breaks.
<slangasek> no
<slangasek> breaks only enforces deconfiguration, not upgrade
<infinity> Oh, true.
<infinity> I dunno, loops aren't the root of ALL evil.  And it really does appear that 2.7-minimal depends on minimal, if it's calling its contents in postinst.
<slangasek> jibel: I would like us to not have useless images all weekend; if you can help with upgrade testing - of *both* lucid and oneiric paths - I would certainly appreciate it; but I understand if you're EOD
<stgraber> slangasek: I'll probably be around for the next two hours, my test system is Edubuntu currently but it seems to fail just as well as Ubuntu does
<slangasek> yes, I don't know why we didn't just add a circular dependency here
<slangasek> I may find out soon
<slangasek> stgraber: 2 hours won't be long enough; I'm going to need a full hour to get a fix in that I trust
<infinity> slangasek: Does it take a fairly fat system to reproduce, or does a chroot with python-minimal in it do the trick?
<slangasek> infinity: test your chroot and let me know ;)
<infinity> ;)
<slangasek> but we also want assurance that the full system upgrades work before we respin the planet again
 * infinity spins up some oneiric chrootiness.
<infinity> At least jiggling control files and repacking debs is simple enough.
<infinity> I'll just keep some pristine chroots handy.
 * skaet goes and plans on marking all the images as needing rebuild as they emerge on the tracker.   No point in folks using them then. 
<slangasek> I'm killing the pipeline
<slangasek> so there shouldn't be any more images coming to the tracker, for now
<stgraber> infinity: I have one base container of every supported ubuntu release and use lxc-start-ephemeral to start one of them with an overlayfs overlay on top of the template. Boot -> upgrade -> grab the logs -> exit -> everything gets wiped. That gives you a clean test environment in a few seconds
<infinity> stgraber: Well, then, I'll let you do this. :P
<stgraber> infinity: do-release-upgrader is running here, just waiting for package download
<stgraber> yep, it fails in the container too
 * infinity goes back to playing with Pandas.
<stgraber> SystemError: E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal
<stgraber> ERROR:root:SystemError from cache.commit(): installArchives() failed
<stgraber> ERROR:root:found exception: 'E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal'
<infinity> Oh, it's Essential?  No wonder it explodes.
<infinity> \o/
<slangasek> Why is the conflicts on << 2.7.3 instead of << 2.7?
<slangasek> yes
<slangasek> which is a historical bug in its own right, but
<slangasek> doko: ping
<infinity> Doesn't matter where the conflict is, it's almost always a bad idea to conflict against essential packages unless you really, really have to.
<infinity> And by "where", I mean "what version".
<slangasek> I'm not saying it's a good idea, but I'm trying to work out all the options for fixing
<infinity> The circular dep's technically more correct anyway, if B is calling A's binaries in postinst.
<slangasek> one of which may be to correct the version number of the conflict
<slangasek> circular deps have to be broken; the package manager may break them in the wrong place
<slangasek> both packages have postinst
<infinity> slangasek: If the loop involves many packages, yeah.  If it's only two, it has a cute side effect of getting them in the same unpack run.
<infinity> Both having postinsts makes their configure non-deterministic, but that's okay in this case, isn't it?
<infinity> We just want both unpacked.
<slangasek> hmm, maybe
<slangasek> best way to find out is by testing
<infinity> At least, that's how I read the bug.  Looks like we just need a new version of a binary, not a newly-configured package.
<infinity> (Not like I trust bug logs when the world explodes...)
<slangasek> yes, that should be correct
<ogasawara> slangasek: that was painful, but weather report should be updating properly now
<slangasek> ogasawara: cheers... :)
<jibel> slangasek, I'm here for the next 2 hours or so. if there's a fix during the night I can run the test first thing tomorrow morning
<slangasek> jibel: ok.  I'm going to leave the fix in -proposed this time until we get confirmed-good tests for all upgrades
<slangasek> jibel: so if you're the first one to be able to test in the morning, you'll want to use -proposed
<infinity> Can jibel's machinery test from a PPA? :P
<stgraber> is there an easy way to get update-manager to take from -proposed?
<stgraber> the upgrade code tends to disable everything in sources.list before the upgrade
<slangasek> I'm not going to screw around with a ppa
<stgraber> (sure we can simply hack that part of the code ;))
<jibel> slangasek, ok.
<slangasek> the previous upload went to a ppa first, and look what good that did us
<infinity> stgraber: Using the default setup, I'm pretty sure you can't.
<infinity> slangasek: Oh dear.  Right, nevermind. :P
<jibel> infinity, yes, it can test from a ppa.
<skaet> infinity,  can you disable image errasing on the iso tracker please.   i want to look at reverting back to prior versions, so testing can continue until this gets resolved.
<jibel> but I prefer propose
<jibel> d
<skaet> ooops
<skaet> s/iso tracker/nusakan/
<infinity> skaet: If you just want people testing images, the current ones are fine for all but being used for upgrades.
<infinity> (And have all the other bits we want tested)
<skaet> True
<infinity> The python thing has zero impact on fresh installs, just upgrades.
<skaet> ok,  we'll leave the upgrade tests invalid and post a note on the top, until this is resolved.
<stgraber> they are still useful to confirm the other fixes, it's just that they won't be the final images, so re-enabling everything but upgrades and adding a big warning at the top of the page should be fine
<stgraber> skaet: let me know if you need help making that very visible, I know the new tracker filters some html codes ;)
<infinity> Does it allow <h8>? :)
<infinity> Oh, wait, it's been a while since I did HTML.  Bigger is smaller, isn't it?
<stgraber> <h1> is the biggest IIRC, though I don't think those are allowed, you need <strong> or something like that IIRC
 * infinity goes back to playing with his "server" disguised cleverly as a cell phone reference platform.
<slangasek> why are the upgrades being disabled?
<slangasek> ah, n/m, scrollback read
<skaet> reenabled the 20120420.1 images.    Now to figure out if there should be any of the 20120420 images enabled.
<skaet> notice on status board placed.
<skaet> (using <strong>.  thanks stgraber ;) )
<skaet> ok,  I think I've found all the 20120420 images that should have been renabled.  If anyone spots some I've missed,  just ping.
<slangasek> infinity: ^^ please spot my bugs in python2.7
<infinity> slangasek: So, I can confirm https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/986203 on current images.  I desperately need a nap, though, so I'll have to poke it later.
<ubot2> Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [High,Confirmed]
<infinity> slangasek: And I was waiting on the queue diff, but I'll just download. :P
<slangasek> infinity: ah, if it's nap time, I can get someone else to look
<len> Ubuntustudio (32 and 64 bit) seem to be still disabled.
<skaet> thanks len, fixing
 * slangasek reenables all the flavors
<infinity> slangasek: Looks right to me.
<slangasek> which is not enough to make queuebot hold its tongue ;)
<infinity> slangasek: Clean revert + versioned dep.
<len> Thanks.
<slangasek> infinity: ok - if you're happy, please accept and we'll put it through the ringer
<infinity> slangasek: Accepted.  Nap time now.  stgraber's container madness should be a big help here. ;)
<superm1> could someone reject the xbmc sync, it was supposed to fix ftbfs on armel, but micahg double checked and it's still failing
<slangasek> infinity: nighty-night
<stgraber> oh and as that's python2.7, that means we won't have it built for the next 5 hours or so
<stgraber> (for armel and armhf at least)
<slangasek> stgraber: hnngh. ok
<slangasek> stgraber: well, it's arch-indep
<skaet> len,  date stamp on the current ones.  20-Apr-2012 03:16  which implies that they should stay as rebuilding (they're in progress on the builder)
<slangasek> I'm more concerned about getting it tested
<slangasek> which doesn't require arm
<slangasek> superm1: done
<stgraber> right, we can test it earlier, then wait the 5 hours for it to finish building before copying
<superm1> thanks
<skaet> len,  so I'll leave them disabled, since they won't have the new fixes we're trying to confirm.
<infinity> Still more than 2 hours on x86.
<infinity> You might want to do some by-hand deb-repacking to test.
<len> skaet OK.
 * infinity really naps now.
<slangasek> jibel: ^^ more than 2 hours before the python fix is available for testing, so I think you're off the hook for tonight ;)
<stgraber> slangasek: I think I'll just do a local build of it with the tests disabled, that should cut down the build time
<stgraber> though deb repacking would work too :)
<slangasek> stgraber: I'm happy for you to do that, but I'm going to insist that we get full testing of the package that's in the archive before we do another global respin
<slangasek> no reason to leave room for error here
<stgraber> sure but I'll let you do that one as I'm not going to be around when that build finishes
 * slangasek nods
<hggdh> slangasek: I can test the upgrade after a diner I have tonight
<slangasek> hggdh: much appreciated!
<hggdh> slangasek: KVM testing is OK, I hope
<hggdh> jibel: ^
<slangasek> yes
<hggdh> ack
<jibel> hggdh, I changed the config of the upgrader to point to -proposed. You'll just have to run the jobs precise-upgrade-* and it should just work. If it doesn't I'll do it tomorrow morning.
<hggdh> jibel: roger wilco
<jibel> hggdh, start with server and if it passes, start the others
<slangasek> yep
<jibel> heading to bed then, good night every one
<slangasek> night jibel
<skaet> good night jibel
<skaet> (and thank you!)
<skaet> slangasek,  I'm seeing ubuntu daily-presinstalled still active on the builders.    Do you know if infinity killed off the rest of the builds (and I should just reenable all on the tracker),  or if more should be emerging?
<slangasek> skaet: there's still a 'buildlive' process running on nusakan, so I suppose that might still spit out an image
<slangasek> only armhf preinstalled
<slangasek> I already reenabled everything except for upgrades though
<skaet> ok,  thanks.   thats probably best at this point.
<cnd> slangasek, would an SRU to free a static buffer in a library at exit be allowed?
<cnd> it's mostly a fix for a valgrind run
 * skaet --> dinner,  biab
<slangasek> cnd: I don't think that's worth an SRU on its own, no
<cnd> ok
<cnd> thought I'd ask instead of assume
 * slangasek nods
<cjwatson> zul: I've done bug 986258, but please use syncpackage yourself in future - there's no need to go through the archive admins for this any more
<ubot2> Launchpad bug 986258 in novnc "Sync novnc 2012.1~e3+dfsg+1-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/986258
<cjwatson> (and it'll be faster for you not to)
<rsalveti> infinity: yeah, in theory the support should be available at the debian package already, I'll check it again on precise to make sure
<stgraber> slangasek: apt seems happy with my local build of python2.7
<slangasek> stgraber: what tests have you done? lucid,oneiric->precise?
<stgraber> oneiric -> precise
<slangasek> stgraber: can you test lucid->precise as well?
<stgraber> yep, though sadly LXC only support upgrading without blowing up since Precise so I can make sure apt can resolve everything correctly and starts upgrading until it reaches udev or mountall, at which points it'll explode
<slangasek> ah
<stgraber> and I have to do it the non do-release-upgrade way because I still haven't found a way to get do-release-upgrade to keep my sources.list entries... I know what to change in the code to disable that bit, but as it's downloading a new signed copy and uses that, my local modification doesn't really help
<stgraber> so currently I'm running a dist-upgrade without the new python, make sure apt fails after download, add my packages as a local repository, try again and check that it resolves fine and starts upgrading (until it reaches mountall or udev)
<stgraber> hopefully the code doesn't drop -proposed in the same way, so once we have a package built we'll be able to test it
<cjwatson> bug 986147 induces despair
<ubot2> Launchpad bug 986147 in openssl "openssl 1.0.1-4ubuntu2 breaks a bunch of ciphers" [High,Confirmed] https://launchpad.net/bugs/986147
<cjwatson> I can't win
<cjwatson> openssl is a heap of junk, everything I backport breaks something different
<slangasek> cjwatson: sorry :/
<cjwatson> the real answer is a time machine so that I can go and say no to the request to take that perf work in the first place, but it's almost certainly too tightly wound to revert now
<cjwatson> so it's choice-of-bug territory until upstream get their stuff together
<slangasek> yep
<slangasek> can we nudge upstream to do that?
<slangasek> would be a relief to have this wrapped up for .1
<slangasek> but I know that might not be possible
<cjwatson> the upstream bug system already suggests a good deal of nudging
<slangasek> ok :)
<cjwatson> but yeah, I'll try to get things comprehensively forwarded upstream next week
<stgraber> slangasek: I found an ugly way of getting do-release-upgrader to work but now it's checking that everything comes from a signed repository ... getting quite late here so I'm going to give up for today (apparently I need to be awake in 6 hours)...
<slangasek> stgraber: don't sweat it - have a good night
<slangasek> stgraber: hggdh should have us covered later this evening
<hggdh> yes
 * skaet back
#ubuntu-release 2012-04-21
<cjwatson> ^- kexec-tools is on the Kubuntu DVD (no other images, according to seeded-in-ubuntu), but that's awaiting the python2.7 fix, and this is the right fix for one of the entries on http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt with no run-time source change; can we squeeze this in?
<slangasek> makes sense to me
<skaet> cjwatson, ok,  we've got the window and its low impact.
<skaet> s/impact/risk/
<slangasek> accepted
<skaet> hggdh, slangasek - looks like i386 and amd64 have published for https://launchpad.net/ubuntu/+source/python2.7/2.7.3-0ubuntu3.
<skaet> hggdh, can we trigger the autotesting off, without waiting for the built in delay?
<slangasek> that was the intent, yes
<doko_> slangasek, pong (for 15min online)
<slangasek> doko_: hey - the python2.7 change was never tested for oneiric->precise upgrades, there was a critical regression there
<slangasek> doko_: I've sorted it in the archive (I think), you'll want to pick up the changes from their for your bzr branch
<doko_> ouch, looking
<slangasek> doko_: as a general rule, please don't use Conflicts in essential packages - this kind of problem is exactly what you get :)
<doko_> slangasek, yeah, we discussed that on the channel, and didn't want the circlular dependency. and just a breaks wouldn't help
<slangasek> Conflicts are almost universally worse than circular deps
<slangasek> in this case, we probably could have kept the Conflicts with a lower version number that didn't break o->p
<slangasek> (and if any problems show up with the circular deps, that'll be my next step)
<doko_> right, not conflicting with the oneiric version sounds much better
<doko_> anyway, afk now, will check updates from lucide and from oeneiric tomorrow
<slangasek> ok - the QA team will also be testing that out ASAP
<slangasek> so there's probably no need for you to worry about it
<slangasek> anyway - g'night :)
<cjwatson> slangasek: do you think the qemu-linaro/powerpc build failure might be fixable by release?  it last built in only the previous upload, and its effects on precise_outdate_all are a little tricky to unwind with simple removals since there are some dependencies on its binaries
<slangasek> cjwatson: last time I looked at the build failure there, I couldn't work out how to fix it
<ScottK> Is netbook a seed we need to worry about for accepting packages (I'm guessing it's obsolete, but someone please tell me)?
<GridCube> im having an issue with today's release and i dont know if its a bug or not, if starting a sentence with sudo on a terminal, when trying to tab to complete the options, like with sudo apt-get i[tab] doesnt do anything, it used to complete the install, and then when writing the first letters of package, say exa[tab] doesnt complete exaile, or even gives option
<GridCube> it looks like tab to complete is broken to me
<GridCube> :/
<ScottK> GridCube: Try in #ubuntu-testing or #ubuntu+1.
<GridCube> ok
<ScottK> infinity: What do you think about syncing csound for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661197
<ubot2> Debian bug 661197 in csound "multiple vulnerabilities in csound" [Grave,Fixed]
<slangasek> ScottK: netbook is obsolete TTBOMK
<ScottK> slangasek: Thanks.
<ScottK> AIUI, the security team declined to support cobbler in Main, which is why maas-provision exists (to be the supported subset of cobbler in Main so maas can be in Main).  The upload that fixes the dependencies so cobbler can go back to Universe is in the queue, but the diff is (due to other reasons) not insignificant.
<ScottK> I think someone (not me) should either review the diff or we should reject it and ask for one that just does the dependency swap.
<skaet> ScottK,  ^ that was an error that proved I got the syntax wrong on some timing runs I was doing and didn't want to publish.   I'll revert it manually to the earlier image.
<hggdh> skaet, slangasek: testing upgrade from Lucid to Precise, AMD64, server
<ScottK> skaet: OK.  I hope I just downloaded the right one.
<ScottK> skaet: There's no testing on the current images, so it doesn't hurt to switch to a different one.
<skaet> unless you can download in 3 minutes,  I think you're safe.  :0
<hggdh> skaet, slangasek: this run (server) should take less than 20 min
<skaet> :)
<ScottK> I got 20120420.1
<skaet> ScottK,  yup that's the one I'll revert the tracker back to so you can record results against the right image
<skaet> hggdh,   Thanks for the estimate.  :)   we'll also need Lucid to Precise, desktop;   Oneiric to Precise, server;   Oneiric to Precise, desktop upgrade runs done as well.
<skaet> can they be started in parallel?
<hggdh> skaet: I started with (lucid|oneiric)->precise, server. If these pass, then I will start the others. It will delay just around 20min the full results, but it does not make sense to start all at the same time (not enough resources)
<skaet> hggdh,  coolio.  Makes sense.  Thanks!  :)
<hggdh> skaet: YW
<skaet> ScottK,  which upload are you commenting on in unapproved?    maas?
<ScottK> skaet: mass
<ScottK> err maas
<skaet> Daviey's agreed to review it.
<ScottK> It seems like we're kind of running out of time.
<skaet> however he's been traveling - so as soon as he surfaces, it should get resolved.
<ScottK> I'd suggest you set a deadline after which we just swap the dependencies and they can do the other stuff in an SRU if they want.
<ScottK> Does stuff in the ubuntu-server: daily seed end up on the server ISO?
<ScottK> Because maas is seeded in that seed.
<skaet> ScottK,  it needs to be resolved by Monday morning.
<skaet> hmm.  Let me go check what's in the latest published image...
<ScottK> BBIAB, need to reboot into a live session with this machine.
<skaet> ScottK,  yes it does.
<skaet> http://cdimage.ubuntu.com/ubuntu-server/daily/20120419/precise-server-amd64.list
<hggdh> skaet: oneiric-precise, server upgrade successful
<skaet> \o/
<hggdh> skaet: lucid-precise, server, AMD64 successful, i386 still going
<skaet> :)
<skaet> in the .list file is /pool/main/m/maas/maas_0.1+bzr462+dfsg-0ubuntu1_all.deb
<skaet> ScottK, ^
<hggdh> I will bite the bullet, and start the desktop upgrades; oneiric-precise takes ~ 20 min, lucid-precise takes ~ 40 min
<hggdh> the real heavy-weights, upgrades of all main and universe, for both ludic and oneiric will take ~ 8 hours to run
<skaet> hggdh,  thanks for that info,  ok,   looks like we'll need to let the main and universe run overnight then.
<hggdh> skaet: indeed :-)
<hggdh> desktop upgrades have started. All server upgrades are successful
<skaet> when slangasek gets back from dinner,   hopefully all of the targetted upgrades will be done,  and if all is well,  we can figure out a game plan.
<skaet> Thank you hggdh, :)    Will be looking forward to the data in ~40 minutes on the desktop.   (and then decide on bed time ;) )
<hggdh> bed time? What is bed time? ;-)
<hggdh> skaet: you can follow results here: https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
<hggdh> it may take a bit for them to be published (some stuck jobs, and we can only clean them up *after* release)
<skaet> Thanks hggdh. :)
<skaet> ScottK,   the unity-greeter fix looks targetted to kubuntu - can you review it if you want it in this next set of respins?
<ScottK> Back.
<ScottK> OK.
<skaet>  * debian/patches/recognize-kde-plasma.patch:
<skaet> +    - Recognize the "kde-plasma" session as "kde" so it gets a properly
<skaet> +      branded icon in the greeter.  LP: #986339
<ScottK> skaet: It seems like something one would want, but it's a unity fix, so it won't affect the Kubuntu images.  I'd say yes, but I'm not the one that has to retest stuff.
<skaet> ScottK,  ok,   it seems something that can be SRU'd easily enough,  so that may be option to take at this point.
<ScottK> I agree.
<ScottK> skaet: I expect a postfix upload from lamont sometime over the weekend that fixes an important bug.  It's not a regression and it's not essential for the CD, but it isn't something we want to leave laying around any longer than we have to.  I'd like to get it into precise-proposed and then, once it's tested, opportunistically copy to -release if there's a respin.
<ScottK> If not, it can go to -updates at release.
<infinity> ScottK: If it doesn't break anything, I don't have huge issues with acking the csound sync.
<ScottK> infinity: That's the if.  My view would be sync and get the security fixes and then if someone cares about breakage we can work on an SRU.
<ScottK> (breakage, if any)
<ScottK> Is the python-minimal upgrade loop fixed yet?
<infinity> ScottK: If by fixed, you mean "did we add a loop to fix the conflict breakage?", then yes.
<infinity> And the loop seems to be working.
<ScottK> OK.  I just saw mail on devel-discuss about it and I wasn't sure if that was just lag or not.
<infinity> ScottK: As for the sync, if you're willing to follow up on potential fallout, go for it.  Though, my guess is that it'll be fine, who knows...
<ScottK> Thanks.
<infinity> ScottK: It at least built on all the Debian buildds, so that's promising.
<ScottK> Yep.
<ScottK> I'll be all radical and test build on Ubuntu first.
<skaet> :)
<hggdh> skaet: all upgrade tests are queued. So far, so good
<skaet> thanks hggdh.  :)
<ScottK> OK.  DOne.
<ScottK> (csound)
<ScottK> infinity: I'm thinking flumotion might deserve similar treatment.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660553 - Looking at the Ubuntu bugs, I think it is extraordinarily unlikely we'll make it work.
<ubot2> Debian bug 660553 in flumotion "flumotion fails to start" [Grave,Fixed]
<ScottK> Is syncpackage "A new OAuth token consumer" in Launchapdspeak?
 * hggdh calls it a day, and goes to bed.
<skaet> thanks hggdh!   have a good evening.
<skaet> I'll continue to monitor the site, until I do as well.  :)
<hggdh> skaet: see you tomorrow, shabbat or not :-)
<skaet> :)
<ScottK> infinity: It builds fine.
<ScottK> FWIW, I just updated a system I hadn't touched since either precise Alpha 2 or Beta 1 and it upgraded just fine (took a VERY long time though).
<skaet> :)  nice to hear.
<skaet> infinity, slangasek, cjwatson, pitti - if one of you is awake when the python2.7 testing on the iso tracker completes, and the results look reasonable,  please start off the rebuilds.   Otherwise,  I'll start them when I wake up tomorrow (if testing ends up looking ok ;) before heading to airport.
<skaet> https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
<skaet> ^ site to check status of runs on.
<skaet> ScottK,  I've updated the pad, and think I've caught the issues you've raised this evening,  please correct anything I may have misinterpreted.  (also,  is there a bug number for lamont's upload?)
 * skaet --> zzz
 * ScottK looks
<ScottK> There is.  I'll find it.
<ScottK> skaet: The bug for postfix is Bug #980682.
<ubot2> Launchpad bug 980682 in postfix "postconf can't open main.cf with the result that /etc/resolvconf/update-libc.d/postfix fails trying to copy /etc/resolv.conf onto itself" [Undecided,Fix committed] https://launchpad.net/bugs/980682
<ScottK> If by pad you mean the wiki page in /topic then I don't see the changes.
<slangasek> so given the impact this python2.7 issue also has on upgrades in the wild, and given that we have evidence now that it fixes the oneiric->precise upgrade for at least the minimal case, I think we should probably copy it to -release now
<slangasek> and let the tests continue running overnight before kicking off the respins
<slangasek> ScottK, infinity: ^^ that sound right to you?
<ScottK> OK.
<ScottK> I have another respin worthy upload I'm about to make in any case.
<slangasek> python2.7 copied
<slangasek> so hopefully that will help the users
<slangasek> ScottK: what's the other upload?
<ScottK> Fix for Bug #986475
<ubot2> Launchpad bug 986475 in bcmwl "Jockey-kde failed to install broadcom STA wifi drivers from Kubuntu Desktop ISO" [High,New] https://launchpad.net/bugs/986475
<slangasek> aha
<ScottK> (you'll see in the bug it turns out to be bcmwl's fault.
 * slangasek nods
<slangasek> so that's obviously a "can't use the CD" issue that's worthy of a respin, yes
<ScottK> dput.
<ScottK> Please stare hard at the dependency change I made to make sure it work for upgraders that still have the non-pae kernel.
<slangasek> ack
<ScottK> I'm as certain as I can be at 2:21AM it's right.
<ScottK> At least the Groklaw Oracle vs Google day 5 summary is up so I have something to do while I wait to make sure it appears.
<slangasek> looks right to me, accepting
<ScottK> Thanks.
<ScottK> And good night.
<slangasek> 'night
<slangasek> skaet: ok, given that the lucid-main and oneiric-main upgrade tests have been running for 4 hours now without kicking out a failure, that gives me enough confidence to start the image respins; doing now
<jibel> oneiric and lucid main passed the upgrade calculation phase and is upgrading. other tests are back to normal.
<ogra_> hmm, could someone accept my compiz upload to proposed from yesterday so my testers can actually test it ?
<skaet> ScottK,  Thanks for tracking down the bug number.   pad I was referncing was: http://pad.ubuntu.com/ubuntu-release
<skaet> now that we're spinning images,  we're using it to track image respins/bugs.
<knome> is there a status of the adopt a iso -project somewhere? where do i know if xubuntu iso's are adopted or not?
<skaet> knome,  http://iso.qa.ubuntu.com/qatracker/reports/subscriptions shows the testcase that folks have subscribed to (and if you mouseover,  who has subscribed)
<skaet> just scan down to your product.   (there may be other mechanisms available)
<skaet> (that the testing team is using as well - but the one on the iso tracker is what I look at.
<skaet> ) :)
<ogra_> skaet, is there a reason the compiz upload wasnt accepted so we can actually have binaries for testing in precise-proposed ?
<cjwatson> I'm respinning server powerpc with a seed change to get it back undersized; it's had no tests as yet, so I assume nobody will much care
<cjwatson> ogra_: should be no problem with that - I'm looking into it now
<ogra_> thx
 * cjwatson peers at LP's bonkers idea of which diff to display
<ogra_> great, thanks a lot !
<skaet> ogra_,  state of what needed to and someone comfortable reviewing it didn't seem to happen.   It wasn't recorded on either https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus or on pad.ubuntu.com/ubuntu-release,  sigh.  That's fixed now at least.
<skaet> Thanks cjwatson for reviewing and accepting.
<ogra_> oh, should i have it noted there ?
<skaet> ogra_ yes.  There are so many variables in flight,  IRC only traffic for important things results in process fail.  (as illustrated ;) )
<ogra_> k, next time, sorry, my fault then
<cjwatson> skaet: FWIW the compiz change no longer qualifies as "pervasive change" as in [15], IMO
<cjwatson> one fglrx fix, and syncing up the gles patch
<skaet> cjwatson,  affects more hardware than just fglrx
<ogra_> yup
<cjwatson> though I agree it needs testing, it's just not as crazy as stated
<ogra_> needs testing on all non fglrx cards
<cjwatson> certainly
<ogra_> (and on arm indeed :) )
<cjwatson> but "pervasive change on tree" suggested to me that everything was totally rearranged, which isn't the case :)
<skaet> cjwatson,  not worries about the gles patch (localized scope) there.  but the other fix that's tangled in, in the tree needs much wider testing.
<skaet> cjwatson,  feel free to edit.  :)
<cjwatson> I've reworded the pad to be a bit more accurate
<skaet> :)  yup.  Thanks.
<cjwatson> hah, finally, daily-checks says "No problems found!"
<skaet> WOOT!!!!!
<knome> skaet, are those subscriptions reliable?
<knome> skaet, or can somebody subscribe but rarely ever do a test?
<skaet> knome,  anyone can subscribe but not test.   However they are getting emails when new images arrive,  if they have subscribed so...
<knome> skaet, ok, thanks
<knome> that's a good pieve of information altogether :)
<skaet> cjwatson,  am seeing /pool/restricted/b/bcmwl/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu6_amd64.deb in the latest builds (or at least ubuntu-desktop)
<knome> btw, there's a small technical glitch
<knome> scroll all the way down to xubuntu,and try to see the whole list of 12 subscriptors to desktop i386 install (man part)
<knome> (second to last item)
<skaet> so I think bcmwl made it in.   Haven't looked at all the affected images though so we may have some with,  and without.
<skaet> (just a risk,  not sure this is the case,  will try to check later if I get some online time at airport)
<skaet> strgaber, ^ see knome's comments.   Is there a project now for it - or should bugs be filed against https://bugs.launchpad.net/ubuntu-qa-website with [ISO TRACKER] in the subject?
<knome> skaet, thanks
<knome> stgraber, sorry ;)
<knome> bbl
<cjwatson> accepting gnome-games under SRU rules
<cjwatson> skaet: yes, is that wrong?
<cjwatson> skaet: that's needed to enable broadcom network cards in jockey
<skaet> cjwatson,  not wrong,  just wasn't sure about the timing of it landing by reading through the backscroll.
<skaet> ie.  did it make it in the builds or not,  timing wise
<cjwatson> sorry, I don't think I understand - you're talking about the version?
<skaet> it seems to have made it into one,  so likely all,   but risk is there until checked.
<cjwatson> ah, I see, timestamped this morning
<skaet> re: version.  right one should be:
<skaet> bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu6_amd64.deb
<skaet> will just make a note of it,  as I clean up the pad
<skaet> (and remove note when, have had a chance to review the other affected images
<skaet> )
 * cjwatson greps
<cjwatson> all current images have the newest version
<skaet> yeah that's what I was doing on ubuntu-desktop.   Feel free to educate on more efficient way to see widely.  ;)
<cjwatson> cdimage@nusakan:~/cdimage/www/full$ find -L -path \*/current/\*.list 2>/dev/null | xargs grep bcmwl-kernel-source | egrep -v '/(lucid|maverick|natty|oneiric)/'
<cjwatson> (not elegant, I couldn't be bothered to think of a neater way)
<skaet> looks good to me.  :)
<stgraber> skaet, knome: https://bugs.launchpad.net/ubuntu-qa-website/+filebug and tag with qa-tracker
<skaet> thank you.  :)
<cjwatson> right, sorry for previous misunderstanding, juggling family stuff
 * ogra_ now has a weird picture of cjwatson sitting on his desk jugglin babies 
<skaet> cjwatson,  no worries.
<cjwatson> not a million miles from the truth
<ogra_> heh
<ogra_> i hope you dont throw them in the air though :)
<stgraber> knome: I need to investigate a replacement code for the tooltip stuff, it's currently CSS only and so isn't terribly flexible. I also have some code around that allows you to click on the number of subscribers and navigate to a page showing you the list of subscribers and some more stats, that should fix the issue for images with a lot of subscribers
<skaet> jibel, hggdh,  can the auto update tester be kicked off again now (point it back to release)  - I'm wondering if some of the fails were due to package being copied from -proposed to -released before run was done?
<skaet> Anyhow,  would like to get auto test runs done on these latest images so we can understand the status.
<stgraber> skaet: I'm checking the status on flavour upgrades now, if it doesn't look good. I'll cancel and restart the test from scratch to get accurate results
<cjwatson> ogra_: it's OK as long as you catch them :)
<cjwatson> (and don't throw them too high ...)
<cjwatson> my children are going to grow up to be rollercoaster fans, I'm pretty sure
<skaet> stgraber,  not sure edubuntu should be affected.  It was just an ubuntu run for universe based off of -proposed last night to check all lucid, oneirc -> precise was sane.
<skaet> but if there are problems,  certainly want to hear about them.   :)
<jibel> skaet, 'main' and 'universe' are still running, that's why status is not updated. I'll remove proposed once it is finished.
 * skaet giggling at the images that cjwatson and ogra_  have just put in my head.   lol
<skaet> thanks jibel.     If you can kick off a clean set from the latest images that just got published,  would be helpful to have solid data tomorrow.
<stgraber> skaet: well, all past upgrades failed because of the python2.7 breakage, so the current run will at least confirm that we're no worse than we were before that
<skaet> stgraber,  oh definitely.  :)  Not saying not to do it,  just that the fails on the board may not have been relevant to you.
<jibel> skaet, tests are scheduled to start at 1700UTC
<skaet> jibel,  that will work.  :)  Thank you.
<skaet> http://pad.ubuntu.com/ubuntu-release has been updated.
<skaet> reenabling update testing on the tracker now as well...
<ScottK> skaet: Thanks.  Would you please put that in /topic then.
<ScottK> skaet: re bcmwl, it's availability was one of the things slangasek was tracking before he hit the respin button last night.
<ScottK> stgraber: Could you have a look at Bug #974667.  It seems to have come up again in ISO testing today.
<ubot2> Launchpad bug 974667 in dnsmasq "dnsmasq does not bind to a port" [Low,New] https://launchpad.net/bugs/974667
<stgraber> ScottK: commented. It might be some kind of race condition, hopefully having the syslog will clarify the problem a bit. cyphermox might be interested too
<ScottK> Thanks.
<ScottK> Sigh.  It looks like my bcmwl fix wasn't sufficient.
<ScottK> Laney: Since I know you're out there uploading stuff: What would you think about me syncing flumotion.  Looking at the RC bug fix it would bring (doesn't start) and the long list of Ubuntu bugs with the current package, it would seem unlikely to make things worse.
<Laney> ScottK: if it tests out, go for it
<ScottK> It builds.
<ScottK> I'll take that as a yes.
<Laney> I'd like it to at least have been run, but yes.
* ChanServ changed the topic of #ubuntu-release to: Archive: frozen | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate | melior malum quod cognoscis
<ScottK> OK.
<ScottK> starts
<hggdh> I do not think it is a big deal, but server amd64 JeOS install uses 680M, the test states <= 500M
<hggdh> I tend to pass it, and open a bug to update the test
<skaet> hggdh,  sounds ok,  thanks.
<Laney> back to the pad again?
<skaet> Laney,  yes,  as soon as we start working with images, back using the release pad.
<Laney> righto
<ScottK> Done.
<ScottK> skaet: It looks like the bcmwl change I did lastnight (while correct) was not sufficient to induce the with linux-source package onto the ISO.
<skaet> ScottK,  will you be working on something to queue up if we end up doing another respin?
<ScottK> skaet: Yes.
<ScottK> I think this is respin material all by itself as it can prevent you from getting online.
<skaet> Thanks for explanation.   Ok,  please keep the status of your efforts updated on the pad as you go.
<ScottK> I fixed it by adding the right package to the seed directly for Kubuntu (so I'm about to ask you to respin Kubuntu Desktop i386), but this likely means that any flavor that wants this fix will have to fix their own ship-live seed.
<ScottK> cjwatson or slangasek: If you're about, I have a question or so about the above problem and how to fix it.
<ScottK> Or infinity.
<skaet> I'm going to be offline for a bit now (traveling to London).    Colin Watson and NCommander have agreed to keep an eye on things,  as backup.
<NCommander> cya later
<skaet> infinity's also traveling to London this weekend.
<skaet> slangasek is reachable by phone in emergencies.
<ScottK> skaet: I don't suppose you could respin Kubuntu Desktop i386 before you go?
<cjwatson> hggdh: oversized jeos install has been a bug for most of this cycle
<hggdh> cjwatson: I agree. I think it is time to reconsider this limit
<skaet> ScottK,  just about to shut the computer off before heading to airport.   Is it all ready to build?
<ScottK> Yes.
<cjwatson> ScottK: I'm entertaining the children right now, but give me an hour or so
 * skaet doing.
<ScottK> It was just a seed change and it's done.
<ScottK> cjwatson: Thanks.
<cjwatson> question for me still outstanding?
<skaet> cjwatson, am handling now.   Then powering off.
<skaet> :)
<cjwatson> safe travels
 * skaet likes Screen ;)
<skaet> Thanks!   see you in London.
<Laney> are we still using ubuntu-release-notes?
<skaet> ScottK,   building now.
<ScottK> Thanks.
<ScottK> skaet: Also I've now discovered this only affects Kubuntu because (apparently) we ship linux headers differently than the other flavors, so it's more contained than I thought it was.
<skaet> ScottK,  that's good news.  Could you put the details of the package, and fix on the pad,  and mark that Kubuntu DVD will need respinning,  if this sorts it then?
<ScottK> It won't affect the DVD.
<ScottK> Will do.
<skaet> Thanks!
 * skaet --> airport
<ScottK> That took care of it.
<ScottK> cjwatson: (for when you get around to it): Unlike other flavors, Kubuntu doesn't have linux-headers-foo in the livefs, it's in the pool via live-ship.  Yesterday I changed bcmwl-kernel-source to properly depends on linux-headers-generic-pae [i386], but Kubuntu still had the wrong linux-headers-generic package on i386.  The other flavors where correct before.
<ScottK> I've directly seeded linux-headers-generic-pae [i386] in Kubuntu live-ship, but it seems like I shouldn't have had to.
<ScottK> The bcmwl-kernel-source depends on linux-headers-generic-pae [i386] | linux-headers-generic [amd64] | linux-headers should have been enough I'd have thought.
<ScottK> so that's what the question was.
<ScottK> (less urgent now that I've worked around it)
<slangasek> jibel, hggdh: thanks for all the support on retesting python2.7 yesterday; I'm happy to see green and yellow on jenkins today, so looks like we're good
<slangasek> ScottK: I'm not sure I understand exactly what the problem is currently.  You mention linux-source, which should never be required for a driver build; did you mean linux-headers?
<ScottK> Yes.
<ScottK> Sorry.
<ScottK> After the bcmwl fix last night, the respin still had the wrong header package on it.
<slangasek> ScottK: ah, you've already taken care of this, I see
<ScottK> I seeded it directly to work around whatever the source of that was.
<ScottK> Yes.
<slangasek> right, because of the seed being picked up and satisfying the dep wrongly
<slangasek> do you need a kubuntu respin for that?
<slangasek> happy to kick one off now if it's ready
<slangasek> (otherwise, I'm afk for the next 2h)
<ScottK> No, skaet already did it.
<slangasek> ok
<ScottK> I just downloaded the updated image and confirmed it's correct.
<ScottK> Thanks.
<slangasek> sure
<cjwatson> ScottK: I've only had time for a very quick investigation, but I think that germinate probably happened to follow the recommends of dkms first which permits linux-headers-generic, and then when it got to bcmwl-kernel-source it already had that disjunctive dep satisfied so didn't proceed further
<ScottK> cjwatson: That would make sense.
<cjwatson> A manual seed entry is a reasonable workaround, although it's slightly awkward that dkms doesn't have a preferred alternative matching the preferred kernel
<cjwatson> but the whole business of deps on kernel headers is a mess anyway *shrug*
<cjwatson> afk
<ScottK> Thanks.
<slangasek> yep - we need conditional depends ;P
<ScottK> Any thoughts on uploading a dkms to -proposed with the recommends fixed up to DTRT?  It could be there as a target of opportunity if we do a global respin or an SRU for 12.04.1?
<hggdh> slangasek: you are welcome :-)
<kklimonda> ^ this is a simple fix to the debian/rules so the package installs libraries in the proper (multiarch) location. Without it people have to create symlinks manually to get it to work
 * ScottK looks
<cjwatson> ScottK: I'm not opposed, although I think it's slightly rearranging-the-deckchairs; but it might reduce chance of error in image building, yes
<ScottK> kklimonda: Done.
<kklimonda> thanks
<ScottK> cjwatson: I'll take a shot at it then.
<ScottK> (I agree about the deckchairs)
<slangasek> ScottK: what's the impact of the dkms recommends being off?
 * Daviey checks in
 * slangasek waves to Daviey
<ScottK> slangasek: No immediate impact as I've worked around it in seeds.
<slangasek> is there a longer-term impact?  not understanding why it would even be SRU-worthy
<ScottK> slangasek: I think it'd be nice to get it in, at least for the point release, in aid of overall correctness and surprise avoidance.
<ScottK> I know I've worked around the case in seeds of which I was aware.
<ScottK> I can't promise there might not be some other case.
 * slangasek nods
<slangasek> I would tend towards wait-and-see
<ScottK> OK.
<ScottK> My view was that it's a low risk, obvious step towards correctness, so get it in if we have an opportunity for it.
<ScottK> But I'm the one playing normal developer here and you're the one playing release team, so wait and see it is.
<slangasek> :)
<slangasek> I can't see the downside to caution here, as any further issues that could arise would seem to be non-CD-affecting so an SRU would be just as good
<ScottK> I agree SRU is fine.
<slangasek> bjf: would be nice if http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html knew about the 12.04.1 milestone now that it exists
#ubuntu-release 2012-04-22
<micahg> ^^ Bug #986387
<ubot2> Launchpad bug 986387 in ubuntu "FFe: Sync django-celery 2.4.2-1 (universe) from Debian testing (main)" [Undecided,In progress] https://launchpad.net/bugs/986387
<micahg> ScottK: ^^
 * ScottK looks.
<micahg> ^^ Bug #986017
<ubot2> Launchpad bug 986017 in ruby-sequel "FFe: Sync ruby-sequel 3.33.0-1 (universe) from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/986017
<ScottK> slangasek: Bug #92782 has a branch with a proposed fix attached.  Seemed like something up your alley and perhaps a good early SRU candidate (if the fix is correct - I've no idea).
<ubot2> Launchpad bug 92782 in ubuntu "/var/crash/_usr_bin_beryl.1000.crash" [Undecided,Invalid] https://launchpad.net/bugs/92782
<ScottK> Bug #927828 would be it.
<ubot2> Launchpad bug 927828 in sudo "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [High,Triaged] https://launchpad.net/bugs/927828
<ScottK> jbicha: gnome-sushi is unseeded.  It can go straight to -release.  Would you please re-upload it (I'll reject this one, no need to change the version number).
<jbicha> ScottK: sure, I forgot it only ships one binary these days
<ScottK> Thanks.
<cjwatson> caph seems busted - failing to unpack chroots.  I've put it on manual for the time being.
<phillw> Hi, with Xubuntu & Lubuntu running on non-pae kernel for 32 bit, is there an option of non-pae kernel in the netboot area?
<phillw> Scrub that question... found it :)
<skaet> slangasek,  cjwatson,  looks like we may have an issue with grub-installer, based on some recent bugs that have come in.
<skaet> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986797
<ubot2> Launchpad bug 986797 in linux "package linux-image-3.2.0-23-generic 3.2.0-23.36 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 2 (dup-of: 916077)" [Undecided,Confirmed]
<ubot2> Launchpad bug 916077 in grub-installer "grub-install - /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?)." [Undecided,Confirmed]
<cjwatson> 986797 has nowt to do with grub-installer
<skaet> appears likely to be a duplicate of https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/916077
<cjwatson> incorrect duplication
<skaet> yup,  sorry
<skaet> https://launchpad.net/bugs/916077
<ubot2> Launchpad bug 916077 in grub-installer "grub-install - /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?)." [Undecided,Confirmed]
<cjwatson> which is isolated, I wouldn't worry about that
<cjwatson> in any event an upgrade problem cannot possibly be in grub-installer
<cjwatson> the logs in 916077 are something entirely different due to LVM or something which isn't supported in ubiquity anyway, so I'm ignoring that
<skaet> <ogasawara> skaet: looking at VarLogDistupgradeApttermlog, I'm seeing the following:
<skaet> * shadeslayer (~shadeslay@ubuntu/member/shadeslayer) has joined #ubuntu-kernel
<skaet> <ogasawara> run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
<skaet> <ogasawara> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
<skaet> <ogasawara> run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
<skaet> <ogasawara> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-23-generic.postinst line 1010.
<skaet> <ogasawara> dpkg: error processing linux-image-3.2.0-23-generic (--configure):
<skaet> <ogasawara>  subprocess installed post-installation script returned error exit status 2
<shadeslayer> what
<skaet> <ogasawara> skaet: which looks to actually indicate something going wrong with grub-probe
<knome> omzg, double flood
<skaet> sorry shadeslayer,  accidental pick up on the copy paste.
<cjwatson> no need to repaste that, it's just stuff from the bug
<shadeslayer> ok
<skaet> ok
<cjwatson> ogasawara: for the record, "issue with grub-probe" is kind of like "kernel hang", you can't just mark one a dup of another
<cjwatson> skaet: this is essentially an isolated instance, despite being multiple bugs from the same user, so I'm not going to panic
<cjwatson> skaet: I'm sure it's a real bug but it could well be confined to some particular weird mount layout
<cjwatson> I've posted a comment requesting more information
<skaet> cjwatson, fair nuf.   you've got the better instincts here (by far)
<skaet> cjwatson,  bjf did confirm it though,  but more data is definitely needed.
 * skaet goes to get some food... back later
<cjwatson> skaet: by my reading, that "confirmed" means "has sufficient logs".
<cjwatson> It could be something to do with doing an upgrade within aufs.
<cjwatson> Actually maybe not, that would only be in --sandbox mode which isn't a real upgrade IIRC
<cjwatson> Based on Erick's comments about having a working system afterwards, I suspect we may not be able to get more data
<cjwatson> I'll try a manual test upgrade in a vm tomorrow and see if it reproduces
<ogasawara> cjwatson: ack, noted for future reference.  will clean up the bugs.
<cjwatson> already done
<cjwatson> Erick's at least
<ogasawara> cjwatson: ah, thanks
<cjwatson> and yes, now analysed 916077 and it's definitely a different problem
<astraljava> skaet: other release team members: Should the link to the images once precise gets released point to http://cdimages.u.c or http://releases.u.c?
<astraljava> Oh sorry, this is re: release notes, of course.
<knome> btw, clicking on xubuntu in releases.u.c points to cdimages.u.c ;)
<knome> just notices
<knome> *d
<astraljava> Ahh... ok, I suppose that answers my question. Thanks.
<cjwatson> Xubuntu images live on cdimage.ubuntu.com not releases.ubuntu.com, yes
<cjwatson> Only the highest-traffic images are on releases
<cjwatson> It's a question of mirroring
<ScottK> cjwatson: re your comment on #ubuntu-devel awhile ago about making sure the New queue is clear: esteid-browser-plugin is waiting for a supportability ack from mozillateam (specifically chriscoulson).  Unless it gets that, it needed to be rejected again.
<cjwatson> (Also, please use cdimage.ubuntu.com rather than cdimages.ubuntu.com; they're aliases, but I consider cdimage the canonical name)
<cjwatson> ScottK: Right, I think Chris had informally acked that (possibly out of despair more than anything else) but I need to check that
<cjwatson> I did mean clear by any means for release, though :-)
<ScottK> Certainly.  Clear could go either direction and I wanted to make sure you were aware of the complications on that one.
<cjwatson> In fact, the DNS considers cdimage the canonical name, too
<cjwatson> I am :-/
<cjwatson> but thanks
<cjwatson> cdimages.ubuntu.com.    579     IN      CNAME   cdimage.ubuntu.com.
<Laney> clears! the! ghc! transition!
<astraljava> Thanks, cjwatson!
<skaet> Thanks cjwatson,  re: 986797.
<astraljava> What is the status of aptitude re: multiarch? I'm left with a confused mind after reading bug #831768 comments.
<ubot2> Launchpad bug 831768 in aptitude "aptitude cannot handle conflicts with multiarch enabled" [Unknown,Fix released] https://launchpad.net/bugs/831768
<astraljava> Am I to believe that we should still warn against using it for m-a setups?
<cjwatson> It doesn't seem exactly ideal for such setups, no.
<astraljava> Ok, thanks again.
<Laney> FTBFS fix
<stgraber> yay, was hoping for that one
<Laney> :-)
<stgraber> right, so it's seeded on Edubuntu. I'll do the review now but as we don't release for arm (where the FTBFS currently occurs IIRC), I'd just consider it an opportunity target
<Laney> it's arch:all
<Laney> but you shouldn't need to respin for it or anything
<stgraber> argh, right, that one is the arch:all one :) vnc is the arch:armhf one that we don't care a lot about (as we don't release armel/armhf and it never build anyway)
<stgraber> ah, right, it's a sync, so no diff for me... bad LP.
<Laney> yeah, that is annoying
<stgraber> right, diff looks good and that's giving us one less package with Ubuntu delta, +1
<stgraber> I'll add it to the pad as opportunity target for Edubuntu
<Laney> cheers
<slangasek> ScottK: yes, there are several bugs in the area of sudo's pam handling that I want fixed in early SRU - the other one I don't have a patch for quite yet.  I'd rather do them as a single upload next week
<slangasek> astraljava, cjwatson: I think the release note regarding aptitude multiarch could probably use refining however, as the current one seems to be based on the pre-0.6.6 behavior
<astraljava> slangasek: Right, so what would you suggest? I haven't been near a precise box for over a week now, so don't have a hands-on feel for it. Can test some scenarios though later this evening.
<slangasek> I would suggest that someone who uses aptitude document what the real issues are :-)
<slangasek> (I don't use aptitude, so I can't say much)
<astraljava> Yeah ok, well I suppose we can look at that during the final few days if someone who has more recent experiences steps up with the issues. I'll see whether I can find any.
<cjwatson> and that's the Perl 5.14 transition complete, whee
<maxb> heh
<maxb> So the latest on the subversion FTBFS is that I've got it to build... sometimes. But have run into at least one test which occasionally misbehaves, and still isn't fixed to pass consistently in upstream's trunk, and it's not trivial to do so.
<maxb> As such, the only way I see of having a reliably building Subversion right now would be the solution I originally proposed on ubuntu-devel@, of disabling the hash order randomization entirely
<maxb> (Or just making the testsuite non-critical to build success)
<maxb> Neither of which are exactly wonderful
<maxb> In any case, it's probably far far too late to do anything for release now anyway
<ScottK> maxb: Or disable that one test.
<ScottK> Looking at Debian Bug #668227, I'm thinking we should just sync links2.  I verified it builds on Ubuntu and I think whatever feature risk the new release brings, retiring the known security issues in more important.
<ubot2> Debian bug 668227 in links2 "links2: security bugs in links" [Grave,Fixed] http://bugs.debian.org/668227
<ScottK> If some other release team person will second that, I'll copy/paste into an FFe bug and do it.
<micahg> ScottK: I forgot gcc-mingw-w64 isn't a sync, but a sync+diff (our breaks/replaces version is different since our gcc is behind due to the freeze
<ScottK> micahg: OK.  Please upload a fix and I'll approve it.
<micahg> thanks
<micahg> should a sub-minute package with an arch-all component go to-proposed?
<astraljava> `gksudo update-manager -d` should mention of a devel cycle, correct? I'm not seeing it in my Xubuntu oneiric instance running in Parallels. Worth a bug, or does someone have ideas to try before I file one?
<micahg> astraljava: we might have the final tarball in now (base-files was updated already)
<astraljava> micahg: So, try again in an hour or so?
<micahg> astraljava: huh?  no, I'm just telling you why it might already be like that
<astraljava> Okay, then I'm not just understanding the cause -> effect chain here. :)
<micahg> astraljava: precise no longer says it's development since we're in RC mode :)
<astraljava> Ahh... ok, sorry for my dumbness. :D
<astraljava> But, without that switch it isn't mentioning precise either.
<knome> astraljava, no need to be sorry... i'm sorry *for you* for your dumbness.
<astraljava> Are we in some sort of state of transition or something?
<astraljava> knome: It will hit you at some point, though, and _then_ you'll be sorry.
<knome> muahah.
<ScottK> micahg: to -release is fine.
<ScottK> micahg: Would you re-upload gcc-mingw-w64 to -release pleaee.
<ScottK> please even.
<cjwatson> micahg: base-files isn't involved there, it's the meta-release* files on changelogs.ubuntu.com that govern that
<micahg> ScottK: that will cause uninstallability on systems with gcc-mingw32
<ScottK> micahg: I think it's a niche enough package that it's OK.
<micahg> cjwatson: ah, ok, so were those updated as well?
<cjwatson> dunno, haven't looked :)
<micahg> ScottK: you're the one pushing the button, reuploading :)
<cjwatson> mvo doesn't normally do them 'til release day though
<cjwatson> it's on ReleaseProcess
<micahg> astraljava: ^^ so maybe :)
<ScottK> micahg: Thanks.
<astraljava> micahg: Ok, I'll try again, maybe the started `do-release-upgrade -d` but cancelled at prompt put the system in a weird state for that.
<ScottK> Woah.  I see three powerpc builders.  \o/
<ScottK> cjwatson: ^^^
<Laney> NICE
 * Laney uploads both GHC and Mono in celebration
<astraljava> Hrm... no. Ok, I'll file one, then.
<ScottK> Laney: Thoughts on my comment about links2 above?
<Laney> let's look
 * micahg starts package the tar and feathers...
<micahg> s/package/packing
<Laney> ScottK: Looks good, and the 'several [â¦] security issues' make it seem worthwhile.
<Laney> The changelog doesn't even seem massively featureful, and I smoke tested it a bit. Go for it.
<ScottK> Thanks
<ScottK> OK.  That leaves us with asterisk having the only "Grave bug fixed in Debian and not in Ubuntu."
<Laney> s'alright, we've palmed that off to Daviey :-)
<ScottK> Not sure if it's going to stick or not.
<ScottK> He's also got a maas upload to review and then server-respins to handle.
<Laney> Yeah. Who prepared the update? Was it jtaylor? We could interrogate him if any testing has been performed.
<cjwatson> ScottK: aye, we got a present a few days back
<ScottK> Very nice.
<ScottK> I know it's been a long time coming.
<cjwatson> sulfur was intended to be a livefs buildd, but it turned out to be no faster at that than royal
<cjwatson> too I/O-bound
<cjwatson> so we made it an lp-buildd instead since it has twice the cores or something
<ScottK> Got it just in time for the first "Q" autosync.
 * cjwatson is looking forward to NOT using sync-source.py -a for that
<cjwatson> come to think of it non-C archive admins can do autosyncs now if they feel like it
<cjwatson> though I expect I'll keep on doing them routinely unless I'm on holiday or whatever
<ScottK> Did someone yet figure which day it is we can't progress towards opening the "Q" archive if sabdfl doesn't give us a name?
<cjwatson> Thursday
<ScottK> "It's going to be Quality Quail unless you give us a different one by Thursday ..."
<ScottK> skaet: ^^^  that's for you.
<ScottK> micahg: You have a gcc-mingw64 FTBFS on armel to look into ...
<micahg> ScottK: I know, I e-mailed the debian maintainer, it's in gcc code though :(
<ScottK> OK.  Thanks.
<Daviey> Laney / ScottK: Yeah, thanks for the reminder.
<Daviey> :)
<cjwatson> skaet: Hmm.  Nobody remembered to set OFFICIAL="Release" in debian-cd ...
<cjwatson> So we can't release the current image set
<cjwatson> (Though we don't necessarily have to respin the livefses)
 * cjwatson eyes the process pages
<cjwatson> (added to the pad)
<cjwatson> it's rolled out now, not doing respins just now though since we ought to talk about it first
<CareBear\> do you get overtime?
<CareBear\> or are you in Japan and it is Monday morning? :)
<cjwatson> Neither
<CareBear\> just crazy crunching on the weekend
<cjwatson> One of those times where it's easier to do more in advance
<CareBear\> absolutely! I love working nights and weekends because noone else is doing it
<CareBear\> well except you then
<cjwatson> Also I have kids, I can concentrate better at night sometimes
<cjwatson> At least for longer uninterrupted periods
<CareBear\> it would destroy productivity
<CareBear\> which is low as it is
<CareBear\> :)
<CareBear\> at least at times
<skaet> cjwatson,  thanks for catching and adding to pad.
#ubuntu-release 2013-04-15
<apachelogger> could someone please reject the pending konversation upload
<doko> apachelogger, done
<apachelogger> cheers
<chrisccoulson> final freeze is this week isnt' it?
<Laney> yes
<seb128> chrisccoulson, https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule says thursday
<chrisccoulson> seb128, thanks
<chrisccoulson> i wonder what the chances are of me getting 2 firefox uploads in this week? i want to temporarily turn a crash in to a runtime abort to try and get more info out of it ;)
<chrisccoulson> (and i have another crash fix and a packaging fix)
<Riddell> chrisccoulson: and fix the kubuntu issue?
<chrisccoulson> Riddell, yes, that would be one of them
<seb128> chrisccoulson, well, I guess you tried other ways to get debug infos without luck?
<chrisccoulson> seb128, all i have is crash reports that don't have enough info and with no contact details for the reporters
<seb128> chrisccoulson, the builders queue seems quite empty, I guess you can try to convince Laney (or whatever other r-t member you find around, which is likely not a lot at this time of the day)
<seb128> chrisccoulson, is that with the raring version? I should maybe run that rather than the ppa ... I guess you don't have steps to try reproduce the issue?
<Laney> seems tight ...
<chrisccoulson> seb128, it's actually with the current version in all releases
<chrisccoulson> seb128, i'd rather you ran the ppa version though ;)
<tseliot> hi, can any admin please reject nvidia-graphics-drivers-304-updates (304.88-0ubuntu2) and nvidia-graphics-drivers-310-updates (310.44-0ubuntu2) from raring-proposed?
<Laney> ok
<tseliot> thanks Laney!
<Laney> what was the problem?
<tseliot> Laney: there wasn't really a problem, I wanted to include more changes
<cjwatson> Could somebody please review my debian-installer upload from Friday?  We need to get new kernels in.
<Laney> seb128: is that unity-lens-friends upload alright?
<stgraber> cjwatson: I'll do that now
<stgraber> (then go back to pretending I'm not around ;))
<Laney> libappindicator could do with being looked at too; I can't because it's my change
<stgraber> Laney: gah, that one is a sync... we really need to teach LP how to diff those
<cjwatson> stgraber: thanks
<Laney> yeah ...
<Laney> I couldn't figure out how to use LP API to grab them even
<cjwatson> Damn, I meant to review doko's gcc-4.7 uploads before the weekend :-/
<doko> heh, I did use the time do some ppa builds, until the ppa repo didn't accept any more uploads due to size
<seb128> Laney, not sure about unity-lens-friends, better to check with Ken why social.scope.in.in has been dropped, I see no corresponding commit in the vcs
<stgraber> Laney: so I think I'm confused about that changelog entry. I clearly see the change to have the library installed in /usr/lib instead of the multi-arch path, but I'm not seeing anything about getting the pcfile into /usr/share/pkgconfig
<stgraber> Laney: nevermind, I'm blind
<stgraber> (I somehow missed the 3rd file in the debdiff)
<Laney> phew
<stgraber> accepted
<Laney> merci
<stgraber> Bitte sehr
<Laney> \o/
<Laney> seb128: should the pot have been dropped too?
<Laney> it seems to revert your upload
<seb128> Laney, yes, dh-translations will generate it at build time
<Laney> kenvandine: ^ I'll reject unity-lens-friends for safety until you check on the .scope.in.in dropping
<cjwatson> (rss2irc is a build fix, since I think that's unclear from the changelog)
<cjwatson> could somebody push through the latest set of haskell rebuilds?
<cjwatson> also ideally the haskell syncs in NEW from the end of last week
<Laney> looking (at the former)
<cjwatson> just did a batch of armhf removals too; getting close ...
<Laney> down to the wire
<Laney> did soemone else accept rss2irc?
<stgraber> cjwatson: speaking of removals, can you remove lttng-tools from raring, the binaries have been taken over by ltt-control (synced from Debian)
<stgraber> Laney: I did
<Laney> alright, great
<Laney> otherwise it would have been a queue bug
<cjwatson> stgraber: done - I reassigned the one open bug too
<Laney> tseliot: are the nvidia-graphics-drivers-experimental-{304,310} packages going away?
<Laney> ah, I see the bugs, yes
<tseliot> Laney: yep
<cjwatson> Sigh, more dep-wait
 * cjwatson syncs haskell-readargs for haskell-basic-prelude
<infinity> doko: Are you still checking rdeps for https://bugs.launchpad.net/ubuntu/+source/ecj/+bug/1165915 ?
<ubot2> Launchpad bug 1165915 in ecj (Ubuntu Raring) "FFe: update ecj to a version supporting Java7" [Undecided,Incomplete]
<doko> infinity, yes, done, now need to fix openjdk :-/ in progress
<infinity> doko: Kay, so we're not good to go on the update then?  Can you update the bug to reflect that, and I'll reject the current sync so no one bothers with it until that's sorted?
<cjwatson> (Note that you can't resurrect rejected syncs; it'd have to be re-requested.)
<infinity> Yeah, not hard to do a new one.
<doko> infinity, just reject
<infinity> doko: ^-- Already done.
 * infinity hugs sagari's gcc-4.7 build time, and wishes he could will a few more of those machines magically into the DC.
 * cjwatson removes the haskell-dummy binaries, and all of washngo
<cjwatson> actually I removed the haskell-dummy source too
<jpds> Packages in -proposed go to -updates after 7 days of maturity when verification is done?
<seb128> jpds, correct
<jpds> seb128: Parfait, merci.
<seb128> jpds, it's a manual process though, so tend to not happen between friday and monday
<xnox> jpds: 7 days since publishing in -proposed && verification is done. So e.g. something can be verified on day 3 and published in -updates on day 7. No publishing on fridays, saturday, sundays; unless we can agree and assign people to be online to handle regressions.
<xnox> bdmurray: ^^
<kenvandine> Laney, that scope file shouldn't have been there to start with, so it's fine
<kenvandine> Laney, and it wasn't installed in the previous version
<cjwatson> blimey, removing haskell-dummy took about 400KB (of ~29MB) off the uncompressed size of universe/i386 Packages (60KB of 7MB off gzip)
<infinity> cjwatson: Impressive...
<kenvandine> Laney, i'm re-uploading
<kenvandine> i just noticed seb128 had uploaded another change earlier on friday that wasn't included in my upload
<Laney> right, k
<Laney> just re-trigger the copy
<Laney> or was it a manual upload? if so I can fish it out
<seb128> kenvandine, yeah, that change was to discard
<seb128> kenvandine, it's superseeded by dh-translations use
<Laney> indeed
<kenvandine> ah, so i didn't need to?
<kenvandine> great
<seb128> kenvandine, no, it was just a workaround upload to get the template imported
<kenvandine> Laney, if you can recover it, that would be great :)
<seb128> kenvandine, I would have included it in the merge request otherwise ;-)
<kenvandine> ok :)
<kenvandine> Laney, i can re-upload if that is easier
<Laney> kenvandine: no, it's already done
<kenvandine> Laney, thanks
<debfx> virtualbox in precise-proposed contains an important bugfix that has been verified and two unverified less important fixes
<debfx> do you guys have a suggestion on how to get that fix (compatibility with the lts backport kernel) into -updates?
 * cjwatson removes ftphs binaries
<debfx> re-uploading it with only that one fix?
<cjwatson> debfx: 1031217 doesn't seem as though it should be hard for somebody with a 12.04 host system to verify.  I would be uncomfortable with dropping the patch for 1071344 - but for that I don't think we need to verify the fix, just regression-test that 64-bit guests still work, right?
<debfx> cjwatson: I tried to reproduce 1031217 on precise but failed. It's easily reproducible on quantal so maybe you can trigger the bug with a custom networkmanager config on precise.
<cjwatson> failed> as in the new package broke, or you just couldn't reproduce the original problem?
<debfx> I couldn't reproduce the origin problem on precise
<debfx> *original
<ogra_> ======================= Log of livefs.sh output follows =======================
<ogra_> sh: 1: /usr/sbin/ubuntu-touch-android.sh: not found
<ogra_> hmpf
<ogra_> argh !
<ogra_> how embarrasing
<cjwatson> looks easy to fix though?  or do you need a BuildLiveCD change ...
<ogra_> nah
<ogra_> already uploaded
<ogra_> just waiting for the bot ...
<ogra_> there we go ...
<ogra_> still something that makes me blush ...
<ogra_> but it seems that BuildLiveCD at least takes the correct path :) thats something
<cjwatson> ^- another missing build-dep of haskell-project-template; I think this is the last of them ...
<infinity> doko: What are the odd of getting http://sourceware.org/bugzilla/show_bug.cgi?id=14887 fixed before release (or, if you're too busy, mind if I roll/test/upload for that tomorrow?)
<ubot2> sourceware.org bug 14887 in gas "Error: ARM register expected -- `str r1,[ r0 ]'" [Normal,Reopened]
<infinity> doko: I'm not sure how many build faiures we have (or have fixed) as a result of that, but I know there's a couple.
<doko> infinity, ok, will fix it today
<doko> infinity, I assume you won't target a glibc update anymore?
<infinity> doko: If you have an ARM machine to test on, gmp is a good test-case.
<infinity> doko: I'm going to do one last conservative glibc upload tomorrow.
<doko> infinity, no, bus errors for everything now
<infinity> doko: Oh, that sucks. :/
<doko> xnox, yeah for the arm assembler openssl issue ...
<infinity> doko: LP bug for that binutils PR is https://bugs.launchpad.net/binutils/+bug/1166628
<ubot2> Launchpad bug 1166628 in binutils (Ubuntu) "New compile error on ARM" [Undecided,New]
<ogra_> hrm
 * ogra_ wonders if he killed kapok.buildd
<xnox> bdmurray: are you accepting openssl/precise as well at the same time? or do you want to publish quantal fully first?
<ogra_> infinity, hulp ...
<bdmurray> xnox: I'm getting to the precise one
<infinity> ogra_: Define killed...
<xnox> bdmurray: =)))) ok, thanks.
<cjwatson> ogra_: still responds to HTTP
<ogra_> cdimage@nusakan:~$ ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kapok.buildd /home/buildd/bin/BuildLiveCD -t android mako
<ogra_> /home/buildd/bin/BuildLiveCD: fork: Cannot allocate memory
<infinity> Hah.
<ogra_> and the log is definitely not updated
<infinity> Is ubuntu-touch-android.sh a DoS? :P
<ogra_> i'm running this script from BuildLiveCD http://paste.ubuntu.com/5710578/ ... the shebang was wrong so i guess the "set -e" has no effect
<cjwatson> Not sure how #! and set -e relate
<ogra_> you mean it would stop BuildLiveCD ?
<cjwatson> Ah, but IIRC there is some curious interaction between '.' and set -e
<cjwatson> I forget the details
<cjwatson> Do you mean that the version that was running was with #! /bin/sh?
<ogra_> nope
<ogra_> it was with !#/bin/bash
<cjwatson> Ah
<ogra_> flipped the chars :(
<cjwatson> You might want to ask IS to figure out what state it's in
<infinity> webops, rather.
<cjwatson> Er, yeah, that
<ogra_> theoretically i would expect set -e to stop it
<ogra_> though it would probably help if BuildLiveCD had set -e set
<ogra_> oh, it has
<ogra_> just quite far down
<cjwatson> Well, (a) set -e has no effect on things that precede it, (b) not totally sure what !#/bin/bash would do anyway, but if it does nothing then the worst case is probably that the script barrels on with /bin/sh
<cjwatson> And in any case set -e in BuildLiveCD is irrelevant here
<cjwatson> Since it checks the return code of that command explicitly
<ogra_> "sh: 1: /usr/sbin/ubuntu-touch-android.sh: not found"
<ogra_> thats the result of my run
<cjwatson> Find out what's actually happening on the machine.  Guessing is too hard work.
<ogra_> so i would have expected set -e to capture that as error and stop BuildLiveCD
<cjwatson> set -e is totally irrelevant to anything here.
<cjwatson> The error is inside 'if $LINUX32 sudo chroot ${DIR%/./*} sh -c "cd /${DIR#*/./} && $COMMAND" >> ${LOG} 2>&1; then', which is an explicit check
<cjwatson> So that should have gone into the else case, i.e. exit 1
<ogra_> oh
<cjwatson> set -e only applies to commands whose exit status isn't checked
<cjwatson> Like I say, find out what's really happening
<ogra_> oh, indeed
<cjwatson> grr, another haskell-yesod build-dep
<cjwatson> Laney: too slow old man :)
<Laney> oho
<cjwatson> tantalisingly close now, I think it's just those two syncs above
<cjwatson> I removed the haskell-platform binaries
<infinity> ogra_: Erm, hold on.  You realise that you're doing things in a chroot that doesn't get deleted, right?
<infinity> ogra_: So, you're adding a bunch of cruft that never gets removed.
<Laney> To an extremely well tested Haskell suite in 13.04 *ahem*
<cjwatson> Hey, it builds.
<cjwatson> Mostly.
<infinity> That's about as tested as it usually is.
<Laney> spoken like a true functional programmer
<ogra_> infinity, hrm, so should i debootstrap my own ?
<ogra_> i thought that one comes from a tarball freshly unpacked on every build
<infinity> ogra_: No, they definitely don't unpack fresh ones.
<ogra_> ok
<infinity> ogra_: The other curiosity is, if the build depends on i386 packages, why don't you build it on an i386 buildd?
<ogra_> i'll debootstrap then
<infinity> ogra_: Instead of focing multiarch on amd64?
<infinity> s/focing/forcing/
<ogra_> infinity, because the android tools expect an amd64 builder
<infinity> ...
<ogra_> yeah
<ogra_> its all pretty awful
<infinity> They expect an amd64 builder and i386 binaries?
<ogra_> ask rsalveti :)
<infinity> That sounds positively insane.
<rsalveti> yup, it's indeed
<ogra_> the tree also ships its own toolchain etc ...
<ogra_> its all pretty insane
<rsalveti> android way of doing it
<doko> ?
<doko> pff
<ogra_> android :0
<doko> "we only trust our own bugs"
<ogra_> infinity, so reject that upload, chrooting all that stuff will take a bit of a rewrite
<ogra_> sigh ...
 * ogra_ notes that testing  all that stuff locally gained him exactly nothing ... 
<ogra_> i know i'm not supposed to test in production ... but replicating the setup seems pretty impossible
<infinity> Replicating a livefs builder is easy.
<infinity> debootstrap a chroot in ~/build-raring-live/chroot-raring/ ; install livecd-rootfs in it, copy BuildLiveCD out to somewhere you can call it, edit BuildLiveCD to not mail logs all over the place, done.
<ogra_> infinity, well, set up an android mirror somewhere in my LAN to pull the 15G tree from, have a local package mirror as well etc etc
<ogra_> there is followup work :)
<ogra_> hmm
<ogra_>  chroot $builddir bash -c ". build/envsetup.sh && brunch $codename"
<ogra_> would that work ?
<ogra_> (to source the needed bits before running the brunch command)
<ogra_> oh, crap ... sigh ...
<ogra_> i guess i should just inject a script into the chroot ... that will work better
<ogra_> since the android bits will likely choke on absolute paths
<ogra_> infinity, mind taking a look at http://paste.ubuntu.com/5710991/ before i waste another version number ...
<ogra_> hmm, line 14 could just drop the check i suppose ... since i know already i'm on amd64
<infinity> ogra_: You might want proc and devpts mounted (and unmounted) in that chroot.
<infinity> ogra_: And to start your builds by cleaning out builddir, in case of previous cruft.
<infinity> ogra_: Otherwise, if that passes a local test, go nuts.  I'm not actually here today (and about to be a lot less here), so...
<ogra_> ok
<ogra_> ah, i just added proc and sys mounting ... forgot devpts :)
<ogra_> thanks !
<mdeslaur> can I upload a security fix for haproxy?
<ScottK> mdeslaur: Yes
<mdeslaur> ScottK: thanks
<phillw> with the dropping of alternate from all but lubuntu and server, is it still flagging up an issue where sudo /cdrom/cdromupgrade still then attempts to download over the internet instead of using the CD image?
<phillw> *is still worth flagging up*
<cjwatson> If it exists it should work
<cjwatson> There's the question of whether it's worth keeping that script on the images if it's only on a small number of images and thus not well-tested
<cjwatson> But that doesn't mean it isn't a problem as it stands, based on that report
<phillw> thanks cjwatson It's been a while since I've used an alternate image. I followed the instructions at http://linuxpoison.blogspot.co.uk/2011/06/how-to-upgrade-ubuntu-using-alternate.html and all went well until It decided to go and download stuff instead of using the ISO image that was mounted.
<phillw> I'd guess it is more an issue for server, where they may want to do a mass upgrade. I've not tried the update ISO yet.
<cjwatson> Realistically I can't imagine server users wanting to upgrade from a CD
<cjwatson> cdromupgrade was always a desktop-user use case
<cjwatson> Indeed I believe that cdromupgrade is not on the server image
<cjwatson> Because it can't work off the squashfs-base system
<phillw> cjwatson: that's fine. I'll try using the upgrade iso :) As ever, thank you for your time.
<cjwatson> there's no separate upgrade ISO ...
<phillw> cjwatson: There are lots of them at http://iso.qa.ubuntu.com/qatracker/milestones/243/builds :)
<phillw> lubuntu has not yet tested our set, I was just curious as to if the alternate still worked :)
<slangasek> no, there aren't; those are the tests for upgrading the OS, there is no "upgrade ISO" for any of these
<phillw> slangasek: sorry, you are entirely correct! there is no ISO!
<Laney> ghc.html looking nice
<phillw> Hmm, okies. So cannot upgrade using iso. not to worry :)
<stgraber> Laney: is that a good thing? It felt like the goal with ghc was to have it in some kind of constant transition ;)
<slangasek> stgraber: "looking nice" is subjective, of course; he didn't say it was looking empty ;)
<Laney> true, I'd better upload a new ghc :-)
<Laney> Also looks likely that the autohinter will manage to transition it
<stgraber> slangasek: oh indeed ;)
<cjwatson> Laney: Yep, it should do it this run
<cjwatson> Just waiting for the publisher
 * Laney is impressed
<cjwatson> If you don't want that you'd better block it quick ;-)
<Laney> and slightly sad that we don't get to construct a monster hint
<cjwatson> I think I can do without that
<Laney> seems that the gitit workaround didn't do the trick though
<Laney> ho hum
<cjwatson> Laney: That's just because I'm an idiot - I'm uploading a fixed version to experimental as I type
<cjwatson> Forgot that $? is spelled $$? in make
<Laney> oh, nice
<cjwatson> final: agda,agda-stdlib,cpphs,darcs,ghc,[...]
<cjwatson> CLANG
<cjwatson> SUCCESS (552/0)
<doko> a beer for every migrated package \o/
<Laney> glorious
<cjwatson> Not sure Laney's and my liver combined can handle 552 beers
<Laney> Might prevent us having to do this ever again if we try
 * cjwatson watches ackee try to keep up with the copies
<cjwatson> Even promote-to-release hasn't finished yet, and it's asynchronous!
<doko> interesting times for debian unfreezing ...
 * Laney starts receiving emails
<cjwatson> And I think it's done
<balloons> maybe it's better asked in here.. I'm helping get ubuntu touch added to the isotracker. So you should see a new family 'ubuntu touch' and products being listed.
<balloons> this doesn't affect the raring manifest, but I did want to make sure we got or have a product owner lined up for these
<cjwatson> Shockingly, this publisher run might take a while
<skellat> ScottK: Mark appears to have spoken: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1169238
<ubot2> Launchpad bug 1169238 in Unity "[UIFe] BFB icon swirl should run clockwise not anti-clockwise" [Undecided,Triaged]
<phillw> skellat: why was that a surprise?
<phillw> I actually agree with him (and that is a rare comment from me :P )
<sarnold> hello; in the course of preparing a security update for curl for our supported distributions, I have also prepared a new package for raring, containing the back-ported security fix from upstream.
<sarnold> is it okay to push this package to raring?
<Laney> yes
<sarnold> thanks Laney
<Laney> np!
<cjwatson> ... and update_excuses is readable again, yay
<Laney> surprised I only got 21 copies apparently
 * Laney attempts to bootstrap a codesearch instance
<doko> $ wc -l update_output.txt
<doko> 22 update_output.txt
<doko> my bad ...
#ubuntu-release 2013-04-16
<bkerensa> anybody from the release team around/
<micahg> ScottK: so, I looked at php-codecoverage, apparently, the version in precise requires an earlier version of php-codecoverage, the dependencies of that should be backportable hopefully...
<micahg> *version of phpunit in precise
<micahg> the alternative would be to backport the newer version of phpunit as well
<micahg> it has 2 rdeps though, so I'm not sure I want to do that
<ScottK> When it was all new packages to fix the bug, I was comfortable.
<ScottK> If it's updating existing packages with rdeps, that's different.
<ScottK> micahg: How about fix it backports and then see how it goes.
<micahg> ok
<cjwatson> +debootstrap --omponents=ain,universe $release $builddir $MIRROR
<cjwatson> ogra_: ^- really? :)
<cjwatson> (two typos)
<seb128> hum, nobody U.S based reviewed the unity stack during the night :-(
<seb128> can we get somebody reviewing those this morning? ;-)
<seb128> Laney, ^?
<Laney> seb128: yeah sure
<seb128> Laney, thanks
<ogra_> cjwatson, wow, no idea how that happened, before adding $MIRROR to that line it had no typos (i still have the pastebin here)
<ogra_> cjwatson, fix uploaded ... (thanks for spotting)
<stgraber> ogra_: is there a specifc reason to mix mount/chroot mount in livecd-rootfs?
<ogra_> mix ?
<stgraber> ogra_: you mount devpts from outside the chroot, then mount proc and sys from within
<ogra_> ah, that ... i wasnt sure if there isnt something looking at mtab
<ogra_> so i always make sure to mount proc and sys inside ... while i dont care for devpts apart from it being writable
<ogra_> old habit :)
<stgraber> ok :)
<stgraber> ogra_: build-android.sh uses /bin/bash because there are bashisms in what it sources?
<ogra_> yeah :(
<ogra_> especially about 1300 lines of arrays
<ogra_> i tried to make the android build system POSIX but gave up at some point
<stgraber> ok... unlikely to make any significant difference on a long build like that anyway
<ogra_> yeah
<ogra_> well, it isnt long ... takes ~20min ... but its big (the source tree is 15G)
<stgraber> ok, only other potential problem I'm seeing is the rm -rf still happening if one of the umount fails, though it shouldn't cause any dammage even if that happens (you can't rm stuff in proc/sys and devpts is a clean instance)
<ogra_> yeah ... well, it might block ... i'll add an -l to the umount in a later upload
<stgraber> ogra_: I think we'd want "umount ... || (echo "Failed to cleanly umount ..." && umount -l ...)" so we have a trace of what happened
<stgraber> anyway, that's fine for a latter upload
<ogra_> yeah
<ogra_> let me get at least one image out of it first :)
<ogra_> optimizationcan always happen later
<ogra_> thanks !
<stgraber> np
 * cjwatson finds a stale lock that was stopping the seed mirrors from updating for the last eight days - that probably caused an assortment of random weirdness
<cjwatson> including, certainly, component-mismatches madness
<cjwatson> images probably weren't affected as they're configured to prefer using bzr directly
<cjwatson> Ursinha: I've finally got round to sorting out the code for the extra germinate run and thus have deployed http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt - thanks!
<ogra_> perl: warning: Setting locale failed.
<ogra_> perl: warning: Please check that your locale settings:
<ogra_>         LANGUAGE = (unset),
<ogra_>         LC_ALL = (unset),
<ogra_>         LC_TIME = "de_DE.UTF-8",
<ogra_> heh
<ogra_> calling BuildLiveCD directly on nusakan ... i guess i should force LC_ALL to C in the script :)
 * ogra_ wonders about the ton of autoremovable packages in the log ... thats weird
<ogra_> bah
<ogra_> and mount doesnt get along with $builddir-proc
<ogra_> sigh
<ogra_> and anothe upload ...
<ogra_> +r
<ogra_> :/
<tjaalton> slangasek: ^
<tjaalton> slangasek: uploaded mesa to raring, all testing seems good, FFE bug description updated to match https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093
<ubot2> Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged]
<cjwatson> Has anyone filed an LP bug about the difficulty of getting hold of diffs / original source for copies?
<cjwatson> (When they show up in queues)
<cjwatson> Ah, of course, asking about it caused me to find it.  Bug 851562
<ubot2> Launchpad bug 851562 in Launchpad itself "Diff's not available for sync's on +queue page like for regular uploads" [High,Triaged] https://launchpad.net/bugs/851562
<Laney> is there some other tool also called queue?
<Laney> when I searched for this before I found bug #924537
<ubot2> Launchpad bug 924537 in Launchpad itself ""queue fetch" requires a changes file which copies sometimes lack" [Low,Fix released] https://launchpad.net/bugs/924537
<cjwatson> Laney: that's the old one that used to be in LP and run from the archive master system
<Laney> so it poked internal APIs presumably
<cjwatson> Laney: once I got the API version working, I killed the internal one
<cjwatson> Laney: Yes
<Laney> if you're fixing stuff in this are, can you make the PPA name into a link to the PPA too? :-)
<cjwatson> Laney: See my question in #launchpad-dev 12 minutes ago ...
<Laney> cjwatson: excellent
<JackYu> cjwatson: hi, would you please help us check the FFE of #1169525 and 1169517?
<cjwatson> If ~ubuntu-release is subscribed, it's in the queue
<JackYu> cjwatson: well, thanks. it seems that 18, Apr is the deadline.
<ogra_> thanks !
<cjwatson> JackYu: well, approved, although to be honest I don't think those needed feature freeze exceptions
<cjwatson> JackYu: I don't think the core ubuntu-docs show Kylin UI, but if you have any of your own screenshots and such then obviously they'll need to be updated
<JackYu> cjwatson: thanks.
<Ursinha> cjwatson, \o/ thanks :)
<seb128> Laney, can you review gvfs in the queue? the diff is non trivial and I would prefer it to be reviewed rather than earlier and while I'm around to answer questions
<seb128> Laney, https://git.gnome.org/browse/gvfs/log/?h=gnome-3-8 might be useful to see the list of changes
<seb128> Laney, the changes from alex should avoid quite some segfaults we are receiving
<Laney> seb128: sure, will look at it
<seb128> Laney, thanks
 * ogra_ twiddles thumbs ... come on publisher ...
<ogra_> i wonder why BuildLiveCD doesnt send mails for my failing build attempts
<ogra_> (i'm happy it doesnt spam the world, but curious why it doesnt)
<ogra_> ARGH !
<ogra_> mkdir -p $builddir/dev/pts
<ogra_> ....
<ogra_> mkdir: invalid option -- 'b'
<ogra_> Try 'mkdir --help' for more information.
<ogra_> i dont get it
<ogra_> builddir=$codename-build  ....
<ogra_> $codename is "mako"
<cjwatson> ref to full log?
<ogra_> kapok.buildd in the mako-android dir under raring
<ogra_> and the last BuildLive.out indeed
<ogra_> $codename comes from $1 ... which effectively is $SUBARCH in the calling script ...
<cjwatson> codename=$1
<cjwatson> builddir=$codename-build
<cjwatson> So you'll get that if $1 is empty
<ogra_> yeah
<ogra_> but $1 is obviously mako ... else i wouldnt have the sruff ending up in the mako dir
<cjwatson> Are you sure -s <something> is being passed?
<ogra_> ph sigh
<ogra_> *oh even
<cjwatson> mako is ${FS} surely?
<ogra_> ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kapok.buildd /home/buildd/bin/BuildLiveCD -d raring -t android -r android mak
<ogra_> thats how i call it atm
<ogra_> and yeah, i didnt call -s
<ogra_> silly me
<ogra_> cjwatson, thanks ...
<ogra_> lets try with just adding -s
<cjwatson> Consider whether the right answer is to use -s or to pass ${FS} instead
<cjwatson> If you pass -s mako then you'll get mako-android-mako
<cjwatson> Which is pretty weird
<ogra_> thats fine for now
<ogra_> but yeah i will surely need to tweak that stuff a bit ...
<ogra_> for now i just want to see the sub script working
<cjwatson> Sure
<ogra_> bah, and now i ended up in the queue ...
 * ogra_ goes to look for dinner
<alecu> hi, I'd like to ping this channel regarding https://bugs.launchpad.net/unity-lens-music/+bug/1168674
<ubot2> Launchpad bug 1168674 in Music Lens "Purchased songs won't download when not logged to U1" [Critical,New]
<ogra_> hmm
<ogra_> i wonder what the HW specs of kapok are ... i kind of assumed it would at least be as powerful as a std desktop ...
<ogra_> seems my build started but it has probs ot answer http requests
<ogra_> ah, no, its still the former build
<ogra_> infinity, do you happen to know what HW specs kapok has ?
<ogra_> it seems really slow even when only building  normal livefses ...
 * ogra_ starts to doubt it was a clever idea to use it for cross compiling
<infinity> It should be a reasonably beefy DL380 G5 or G6, I assume.
<infinity> But we probably shouldn't be compiling on the livefs builders...
<ogra_> well
<ogra_> we want to do it from cdimage builds
<infinity> Is there a reason we didn't just package this, so you can build once on a buildd, then pull the binaries into your image build?
<ogra_> err
<ogra_> its a 15G android source tree
<ogra_> you dont want to package this :)
<infinity> Smaller compressed, I assume. :P
<ogra_> it is what generates the HW layer of ubuntu touch images
<infinity> I'd rather package it than rebuild it every day for no reason.
<ogra_> yeah, i dont plan to rebuild it unconditionally
<ogra_> but atm the tree needs a multiarch capable amd64 to even build ... and you can not just pull parts of it but need the full thing locally to roll the "hwpack"
<infinity> I still question the absolute truth of the first bit.
<infinity> Needing the full thing is fine.  And I get a shallow export is smaller than 15G (and much smaller compressed).
<infinity> s/get/bet/
<ogra_> it builds a full OS
<infinity> Sure.
<ogra_> armel also :)
<infinity> But if you're saying the git clone is 15G, I'm saying an export is much smaller.
<infinity> That's just how VCSes work.
<ogra_> the only thing you gain when doing an export is that you doknt transfer the three other kernels for the arches you currently dotn build
<ogra_> thats in max 500M
<ogra_> the rest is all OS stuff you need during the build
<ogra_> including all deps
<ogra_> anyway, i'm not really concerned by the disk requirements ... i'm confident there is enough diskspace
<ogra_> but seeing the behavior of the machine while just rolling a rootfs image and not even answering to http requests for minutes makes me worry
<infinity> ogra_: I think you're not understanding what I mean by export.
<ogra_> infinity, apparently not ... i just know what it does when it builds ... it compiles the whole dependency chain like gentoo
<ogra_> and it needs the full tree for this
<infinity> Yes, but it doesn't need the history.
<ogra_> transferring the 15G from onbe machine in the DC to another isnt really an issue imho
<infinity> (probably muddies the waters that, unlike cvs, bzr, or svn, git doesn't have an "export" command, but it does have "archive")
<infinity> ogra_: No, but if we were to package it (as I'm suggesting), it should be a shallow export/archive, not 15G of uselessness.
<ogra_> and it needs the history for generating the chabnbgelog we ship alongside the images
<infinity> ogra_: And I still think packaging it is the sane thing to do.
<ogra_> how do you package a whole OS ?
<infinity> Eh?
<infinity> You build the bits and put the result in a deb that you later download and tear apart?
<infinity> No different than asking "how do you package a bootloader that you intend to use later on cdimage?"
<ogra_> it is the android layer ... it spits out four img zips  and needs to work with the android update/flash mechanism
<infinity> And we don't cross-build u-boot for every ARM image build.
<ogra_> no, and i dont intend to do that for the "hwpack" either
<ogra_> if i trigger a rootfs build for UTouch it should check if there are changes on the HW layer ... if not just use the existing last one
<infinity> If it's not meant to be built without a manual trigger, it should be packaged, not on the image builders.  That's sort of my point.
<ogra_> it is meant to be built like any other image
<infinity> Not to mention that we've put none of the same thought into making sure that image builders are clean buildd environments for anything other than live-build.
<ogra_> automated by chrontab
<ogra_> daily ...
<infinity> Daily, except not if it hasn't changed.
<ogra_> we do this already in OBS/jenkins
<infinity> So, not really daily.
<ogra_> currently it is daily
<ogra_> to make sure hybris and the platform api are fully in sync with the rootfs
<ogra_> else it wont boot
<ogra_> since the android side of both isnt packaged and links against the android bits during build
<ogra_> in the converged world that might even become more hairy ... since we need to build for all arches and all possible device types if rolling one daily
<ogra_> infinity, i wouldnt mid leaving it in IBS/OBS/jenkins but then we have zero control over the builds
 * ogra_ can never recall whats the right abbreviation for that black hole build system over there 
<infinity> IBS.
<ogra_> k
<infinity> Do we actually have an OBS instance in-house somewhere, or are you just having TLA issues? :)
<ogra_> http://10.97.2.10:8080/view/Phablet/job/ubuntu-touch-image/
<infinity> OBS == OpenSuse Build System.
<ogra_> thats what we have atm
<ogra_> oh, right :)
<ogra_> heh
<ogra_> indeed i meant IBS
<infinity> Pretty sure I'm not tunneled to the right VPN for that URL to be useful.
<ogra_> ah, ok
<ogra_> its the jenkins instance that also runs all QA tests
<ogra_> it spits out between one and five complete builds/day
<ogra_> (one automated, the others triggered manually on demand)
<ogra_> infinity, do you have any better idea than replicating whet they do over there atm ? to get dailies in place before S opens ? (we had UDS sessions and there is a spec btw)
<ogra_> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds
<infinity> If only I hadn't been double-booked for UDS...
<ogra_> i thought we (you and me) even talked about it before UDS
<infinity> None of this cross-building and compiling madness, certainly. :/
<infinity> This all needs to be packaged.
<infinity> If something on the Ubuntu rootfs needs to be linked against the Android stuff, that needs to be packaged too.
<ogra_> you mean the whole OS or all of its armel bits ?
<infinity> And that all solves the rather important (and glossed-over) bit about needing to provide source, too.
<infinity> I mean, anything that's being rolled into an image that we give people should be coming from a package, not a random one-off compile hidden on a livefs builder.
<ogra_> the hybris bit in the ubuntu rootfs only talks to the provided hybris abi
<ogra_> that side is packaged
<infinity> livefs builders should be taking binaries from the archive and turning them into images, not taking source from $somewhere and compiling it.
<ogra_> but thats not how android works sadly
<infinity> Uhm.  Dude.  Yes it is.
<infinity> Android is source.  That builds to binary bits.
<infinity> And you want those binary bits.
<ogra_> yeah, bit no packages
<ogra_> not at that level of the OS
<ogra_> the system image of android is one big blob
<infinity> Your "package" can just be something that builds the source and copies all the binaries you want to /usr/share/android-bits/
<infinity> You're looking at this too literally.  We don't need dpkg on the TARGET machine to be able to "install Android".
<ogra_> no, we need the img files
<infinity> We just need a conveyance to the buildd.
<ogra_> since all specs we did (image upgrades etc) revolve around the existing android design atm
<infinity> This is exactly no different than building a bootloader into a package and then tearing out the binaries we want to put them on a VFAT.
<infinity> You get that, right?  Calling it "a whole OS" doesn't change that it's just some random binary blob(s) spit out from a compile job.
<ogra_> yes i understand ... still if you want all pieces packaged to just merge them into one big blob in the end, whats the usecase ?
<ogra_> we *need* the one big blob
<infinity> ogra_: You've just argued that we shouldn't publish packaged software at all, but recompile the archive for every ISO build.
<ogra_> if you start ripping it into single packages  you will invest several months
<infinity> ogra_: In short, that's just not how we do things.
<infinity> ogra_: Plus, we already have an established avenue for providing source to people to keep with our GPL requirements, etc.
<ogra_> well, all designs we have atm revolve around exactly that setup
<infinity> ogra_: Who said anything about "single packages"?  I didn't.
<infinity> ogra_: You can do exactly what you're doing on kapok, but in a package.  And without the git clone stage, since that's the bit you upload (though a git archive instead, so it's much smaller).
<infinity> ogra_: I'm not talking about refactoring Android or any such insane time investment.
<ogra_> ah
<ogra_> i slowly get you ... though that would still be gigabytes of source
<infinity> So is libreoffice.
<infinity> *shrug*
<ogra_> given you need the kernel for your HW inside it, binary blobs etc etc
<ogra_> what we have here is the whole android without dalvik
<ogra_> including the blobs
<ogra_> s/including/but including/
<infinity> But humor me, do a 'git archive --format=tar --prefix=cyanogen-0.2013-04-16/ | gzip > ../cyanogen-0.2013-04-16.orig.tar.gz'
<infinity> And see how big it is.
<ogra_> infinity, let me finish what i'm doing atm ... and lets revisit it during S
<infinity> (Or whatever/wherever that git tree is actually from)
<ogra_> phablet.ubuntu.com
<infinity> Oh, that might need a HEAD in there before the pipe.
<ogra_> well, its not one git tree ...
<ogra_> its repo/brunch/breakfast
<balloons> slangasek, cjwatson infinity -- any of you have access to the script that auto-increments the version number for new builds on the isotracker? If so could you add a couple new products to it for me?
<infinity> ogra_: Sure, then you tar up multiple trees and make it a dpkg-v3 multi-orig package.
<ogra_> if i call git in the repo toplevel i just get an error
<ogra_> right
<ogra_> rsalveti, ^^^ if you have a spare minute please read the backlog
<infinity> balloons: I'm not sure I know what you're asking.  Builds get the build numbers assigned when built, but that has nothing to do with the isotracker or products therein.
<ogra_> infinity, i'm all for easier solutions, but for now i need images when S opens
 * rsalveti checking
<ogra_> and assume the current setup will work ... lets revisit it and rip it apart during the cycle
<infinity> rsalveti: TL;DR, it's insanity for image builders to be doing long (and often redundant) compiles of Android, that junk should be packaged (even if it's just one massive package that spits out the blobs you need at the end) and the results sourced by the image builders.
<ogra_> infinity, the prob here will be that we would actually have to put it into multiverse ...
<infinity> rsalveti: This is functionally no different than saying "image builders need u-boot to make a nice bootable VFAT, so we'll pull it from a .deb from the archive" instead of "I guess we'll cross-compile u-boot on every build".
<infinity> ogra_: That's not a problem.  Why would it be?
<ogra_> dunno
<ogra_> just saying ... we have binary blobs inside
<infinity> ogra_: We can't and shouldn't lie to our users about the freeness of this crap.  Putting it in multiverse drives that home just fine. :P
<ogra_> heh
<balloons> infinity, when a new build hits cdimage, a new version for that build needs to be entered into the tracker -- this is tracked via a script
<infinity> balloons: Well, that's all part of the same thing.  cdimage just pings the tracker when a build happens.
<rsalveti> infinity: ogra_: problem currently is that the resulted image is hardware dependent
<ogra_> balloons, thats the /pending vs /current thing ?
<rsalveti> and we're also investigating how to properly flip the container
<rsalveti> I'm sure that's the way to go
<ogra_> rsalveti, yeah
<rsalveti> it's just that currently we still need to build them the way we're currently building at jenkins
<balloons> ogra_, the pending vs current isn't what I'm talking about here :-)
<infinity> rsalveti: Multiple hardware-dependant images is just more argument for making this a packaged thing, not less.
<rsalveti> I don't mind building them outside cdimage while the "proper work" is not yet finished
<balloons> infinity, ok :-) Well I need that script to ping the tracker about the ubuntu-touch-preview images
<infinity> rsalveti: Cause blocking an image builder for hours/days to iterate over all of that is nuts.
<rsalveti> infinity: it's hard as they are bit, the build system is changing at the same time we're improving things and we need to avoid breaking the porters
<ogra_> rsalveti, infinity i do mind ... since we're nearly there with the current concept
<ogra_> i dont mind re-doing it later
<rsalveti> it'll be improved over the time, and we hope to separate the needed components into packages
<ogra_> but i doubt moving to a completely new concept at the dawn of an archive freeze and with the expectation that it is there as soon as the new release iopens isnt feasible
<rsalveti> and make that available at the archive, so it can be consumed by our builders
<infinity> balloons: Ahh, that's different.  Despite it being published to cdimage, it's not actually from there.  In fact, this is what Oli and I are arguing about right now. :P
<rsalveti> we're just not there *yet*
<ogra_> right
<ogra_> thats why i say that we should move to infinity's idea ... just not right now
<infinity> rsalveti: I wasn't arguing for refactoring into smaller packages.
 * balloons feels sheepish.. I should have read your backlog a bit more
<rsalveti> even building them in big packages
<infinity> rsalveti: Just for taring up the mess, making it an orig, and doing some like packaging that builds what you need and dumps it into /usr/share/whatever.
<ogra_> yeah
<rsalveti> the android part is currently generating all the images, so it's not easy to replace it
<rsalveti> currently android is still the main os
<rsalveti> not ubuntu
<infinity> rsalveti: Not that refactoring is a bad idea, but settling for the worst solution because "it's basically done" and arguing that we can't do better because "it needs to be perfect before we do" is a pretty big disconnect.
<cjwatson> balloons: it's certainly possible to post additional images to the tracker from nusakan manually; but stgraber would need to set up the product first, really
<rsalveti> so having them at /usr/share/whatever will not help us at this moment
<cjwatson> (on the tracker)
<infinity> rsalveti: I think you're not understanding what I mean.
<rsalveti> infinity: I'm not arguing that we can't do better
<cjwatson> balloons: but yes, as infinity says, this has nothing to do with build identifiers / version numbers
<ogra_> rsalveti, he means having a debian/rules that runs: phablet-foo-bar; repo sync, brunch $target ... and puts the zips into /usr/liv/foo
<rsalveti> I'm arguing that we'll do better, but currently we still need to build them this way (android-way)
<ogra_> and just use the whole repo as source package
<infinity> rsalveti: I know that Android builds these blobs you need.  I'm arguing that you build them ONCE in a package, then our image builder can tear apart that .deb and put them together how you need.
<rsalveti> not sure if that is a good idea
<ogra_> and i like the idea, its just not the time to change to it now
<infinity> rsalveti: Not arguing that a package magically make your final product, or that the target device be able to "dpkg -i android_thing.deb".
<ogra_> (took me a while to get that)(
<ogra_> :)
<rsalveti> or at least, not sure if we should spend time moving to a deb way of building it if we'll be replacing it later with something better anyway
<ogra_> thats true though
<infinity> rsalveti: It gets proper source publication for free, which is also pretty important.
<rsalveti> infinity: sure, but why solving this now?
<infinity> rsalveti: But mostly, this came about because we're compiling massive jobs on our one amd64 livefs builder, and that's (a) a bad idea, and (b) a bad idea.
<rsalveti> and not invest the time at the proper solution already
<ogra_> infinity, he is right though, the whole thing is a moving target that can change within weeks
<stgraber> balloons: where are those products being built? if they
<rsalveti> if we'd stick with this for months, I'd be +1, but this might change completely during the this/next month
<ogra_> nothing is finalized ... we could change it in two weeks from the ground up
<rsalveti> and we'll be discussing it at the sprint again, based on the container flip work
<cjwatson> rsalveti: it's quite possible that pushing the current design to our current build infrastructure will cause blocking problems during release week, next week
<infinity> livefs buildds are not in any way guaranteed to be sane and clean compilation environments.  Plus, there's just the resource contention.
<stgraber> balloons: *if they're built on nusakan, then we'll add them to the python magic, if not, whatever builds them should push the new builds to the tracker
<cjwatson> depending on just how long it takes
<cjwatson> stgraber: they're mirrored on nusakan
<ogra_> cjwatson, i dont plan to do builds once i know it works
<ogra_> this is S material
<balloons> stgraber, yes not built on nusakan
<cjwatson> that's not so bad I guess
<rsalveti> cjohnston: so if I understand properly the issue right now is consuming the cpu resources from cdimage to bulid the android part
<ogra_> it just should be ready in advance
<cjwatson> rsalveti: I'm not cjohnston
<rsalveti> crap
<ogra_> rsalveti, from the livefs builder
<infinity> rsalveti: If this could change again in the next month, I seriously don't see the point in Oli's work at all here.  Can't we just keep copying the Jenkins output to cdimage and then discuss this all in person in two weeks?
<ogra_> rsalveti, i didnt even do a build yet ...
<rsalveti> need a hard link for cjwatson
<cjwatson> rsalveti: and no, it's not CPU resources on cdimage, it's CPU resources on kapok (livefs builder).  But if it's not going to be running during release week I'm less immediately concerned
<ogra_> so lets wait for the first smoketest :)
<ogra_> cjwatson, i never planned to :)
<ogra_> its all for S
<ogra_> but i want to have alll livecd-rootfs bits in before freeze
<rsalveti> infinity: right, ogra_ was just working on moving the infra to another machine
<rsalveti> to be better integrated with the way we're currently publishing them
<cjwatson> stgraber: I'd prefer to post from nusakan, since the intent is for ubuntu-touch to eventually be coordinated from nusakan like everything else and I don't see the point in setting up a post-qa-a-like elsewhere
<rsalveti> but if that's indeed an issue (which we thought it would be ok during uds), we can postpone
<cjwatson> rsalveti: it's a little more than moving infrastructure to another machine
<ogra_> infinity, i promise you if we still have that design a week after S openend i will try to implement your idea
<cjwatson> he's doing integration work with the livecd-rootfs system
<balloons> I'd agree with cjwatson to keep everything synced in one place.
<stgraber> cjwatson: is it something pushing to nusakan or something on nusakan pulling from the outside? if the latter, then indeed it'd make sense for nusakan to just push the new version to the tracker.
<infinity> ogra_: If we don't have that design a week after S opens, your work was a waste of time.
<infinity> ogra_: So, no matter how you look at it, you're promising to rewrite it in two weeks? :P
<ogra_> the livecd-rootfs thing is a quick and dirty temporary solution to get the images moved over under cdimage control
<ogra_> infinity, if needed
<ogra_> we might even have a completely different concept in two weeks
<infinity> Right, see, I honestly don't see the point then.
<infinity> Either it changes in two weeks, or it stays the same and changes in two week.
<ogra_> like android living in a separate container
<cjwatson> stgraber: the latter
<infinity> Either way, how is implementing something that's untenable as an interim solution any better than just copying the currently-functional jenkins output?
<infinity> You could just stop altogether, cut your losses, stop making sunk cost arguments, and find something more fun to do.
<cjwatson> To be fair Steve has asked Oli to do this in order to keep momentum up - there's a problem that the build in Jenkins is effectively hidden from most Ubuntu developers
<cjwatson> Moving it into livecd-rootfs at least means that we can see what it's doing more easily, even if what it's doing is expected to change
<rsalveti> indeed
<infinity> Sure.  And moving it to a package would be even less opaque.  And wouldn't be a resource issue.
<infinity> And would be a few more hours of work.  Not unlike arguing on IRC. :P
<cjwatson> I generally agree with having binary outputs in packages as long as we advertise that the result is purely for image builder consumption
<cjwatson> (in package descriptions or whatever)
 * infinity nods.
<cjwatson> As you say, it's much like how boot loaders are handeld
<cjwatson> Or debian-installer initrds, although those are a bit weirder
<ogra_> so lets just do it that way
<rsalveti> that might be easier than moving stuff directly to cdimage indeed
<ogra_> once we are not three days before a freeze though
<cjwatson> rsalveti: To be clear, neither approach is directly on cdimage
<ogra_> right
<cjwatson> cdimage doesn't do livefs builds - it triggers other machines to do them
<ogra_> (you would notice if you would read the phablet sync logs i mail you every day :P )
<rsalveti> right, I'm not technically pointing the right machine, just saying to move to the cdimage infra or whatever we can call them
<ogra_> yeah
<cjwatson> I don't think final freeze is particularly relevant here, given that this isn't output for rarin
<cjwatson> g
<ogra_> i like infinity's idea, it will just not work with the current goals
<ogra_> which means to have images building once S opens
<cjwatson> Why not?
<ogra_> you mean i should just ignore the freeze and upload until the archive closes down ?
<cjwatson> It's possible it'll actually be faster, since everything will be more visible and the image-build phase will be faster
<ogra_> though that also means that rsalveti needs to prodice regular archive tarballs on phablet.u.c
<rsalveti> ogra_: can't we make that to happen when creating the source packagE?
<ogra_> the image build phase will ... but the paperwork around it wont
<cjwatson> Given that this is something users aren't expected to use and is just build support for something not in raring, I don't think it's subject to freeze
<rsalveti> automatically
<ogra_> rsalveti, hmm, that means  what 15G uploads for me ?
<rsalveti> no, the git export, which is way less
<balloons> cjwatson, stgraber ok so it sounds like you'll add the build notice for ubuntu-touch-preview to the python magic on nusakan?
<ogra_> cjwatson, its subjejct to the archive ... which freezes
<rsalveti> but sure, we can probably make that happen automatically there
<infinity> The archive is already frozen, nothing really changes in two days on that front, we can keep uploading things.
<ogra_> infinity, it will hard freeze and lock down ... i'm not referring to artificial frezes
<rsalveti> right, and this will only take effect at s anyway
<infinity> ogra_: It's already hard frozen and locked down. :P
<ogra_> infinity, nah
<infinity> ogra_: Unless you mean when we RELEASE in a week and a half, and then you just start uploading to S instead.
<ogra_> i mean the hard freeze once we have a release candidate
<ogra_> which usually adds an extra week of no uploads
<ogra_> and i mean *no* uploads
<infinity> Past -changes lists disagree with you.
<ogra_> or do we plan to do that differently this time
<infinity> We upload right up to release day.
<ogra_> hmm
<ogra_> i'm probably to main focused :P
<infinity> Especially for things like this that don't exist on shipping images.
<cjwatson> rsalveti: Can you confirm the size of the archive tarballs that would be produced?
<rsalveti> cjwatson: yup, checking now how this can be done
<rsalveti> and the size
<cjwatson> balloons: stgraber will need to add a product to iso.qa; I can then add support for it to lp:ubuntu-cdimage
 * ogra_ guesses with repo involved thats trikier than just one git tree
<ogra_> *trickier
<infinity> debian/rules get-orig-source can be made to do multiple git archive runs and build a multi-orig source, that's about 2 minutes of work.
<rsalveti> ogra_: yup
<infinity> (And a lot more than two minutes to actually do the exports, but whatever)
<rsalveti> infinity: but it'd be better to grab the list from the manifest and etc
<ogra_> infinity, execpt that i still only have a 2M line here :P
<ogra_> pulling the repo to make a port took me 3 days
<ogra_> hmm
<infinity> ogra_: Sure, but once you have a copy of the repo, you're just doing a quick git pull before a fresh git archive.
<ogra_> i think i killed kapok
<infinity> Unless you're deleting it and re-cloning every time.
<infinity> I which case, Double-U Tee Eff, mate.
<ogra_> infinity, well, i still produce tarballs that i need to upload
<cjwatson> Can't you build the orig tarball on a porter box in the DC?
 * ogra_ odered a vdsl 50M line this week ... but it will still take 4 weeks until that switch happens
<ogra_> cjwatson,  i fear i will have to
<rsalveti> I'm checking if that can be automatically published by phablet.u.c
<rsalveti> that will make it way easier
<infinity> Or have Ricardo produce tarballs for you, sure.
<cjwatson> Then dput it from there, or nc it to chinstrap and dput from there
<ogra_> yeah
<infinity> Then you can build the .dsc in the DC and sign it at home.
<ogra_> thats the reason my original idea was to use kapok
 * cjwatson <- also ~2M line, well used to this sort of thing :)
<ogra_> to not have to shovel gigs around through the internet
<infinity> I suspect that sort of thing is the libreoffice workflow for some people.
<ogra_> heh, yeah
<infinity> Though I just download the full source and play locally, cause I'm silly.
<ogra_> i fixed OO.o once for arm ... took half a day to upload
 * infinity wonders how many more times libnss-myhostname will bounce between main and universe.
<ogra_> cjwatson, didnt you get fiber once ?
<cjwatson> I wish
<cjwatson> http://cjwatson.dreamwidth.org/2827.html is part of the joys involved in attempting (and failing) to get fibre here
<ogra_> eek ADLS ?
<ogra_> err
<ogra_> ADSL
<ogra_> i at least have SDSL
<balloons> cjwatson, ahh a link to the magic! thanks! So when say add a product to iso.qa is there something more that needs to be done than what is there now? (aka "ubuntu touch" product)
<cjwatson> ogra_: SDSL is roughly unknown in the UK
<ogra_> yeah, i have to pay a hilarious price for it even in germany its rare
<cjwatson> balloons: There's a bit in lp:ubuntu-cdimage that maps cdimage's idea of images onto iso.qa products
<cjwatson> iso.qa came much later and does things rather differently
<ogra_> but so are fixed IPs nowadays ... finding the VDSL optiuon with IP wasnt easy
<infinity> I don't bother paying for a static IP because I get the same one from DHCP for a year or two at a time between network reorgs.
<infinity> And changing DNS once every two years doesn't seem like a big deal.
<ogra_> well, german telekom isnt that reliable ... and i like to have my mailserver recieve the mail
<ogra_> and since i have the space here i decided to not pay for a hosting provider anymore
<ogra_> (we dont even actively use a quater of the house ...  so i can run server cabinets and whatnot)
<balloons> cjwatson, of course. Just want to do as much as a can to help out -- if it's something I can accomplish, I'm happy to do it. And to understand of course :-) I think I'm understanding what has to change.. a new cron entry, potentially a new config (daily-preinstalled might work) and adding a ubuntu touch entry to the tree.. interesting :-)
 * slangasek eyes component-mismatches
<TheDrums> Would there be a chance that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679911#25 will make it into raring?  It is a bug fix.
<ubot2> Debian bug 679911 in sendemail "[sendemail] Fails when tls is enabled" [Important,Fixed]
<infinity> TheDrums: Done.
<TheDrums> infinity: Thank you!
<antarus> heh, I read that as 'sendmail' and i was very confused
<infinity> I did too, initially.
<balloons> sendmail bug fixed. yay!
<slangasek> it's the Old English locale version of sendmail
<slangasek> you know, the updated one
<stgraber> ogra_: gah, does that mean I'll have to stop making fun of your silly slow internet connection? :)
<rsalveti> cjwatson: ogra_: infinity: 6.7G for the bare files, but can be reduced once we drop our own kernel (and use the one provided by the kernel team)
<rsalveti> 2.1G just for the kernel sources
<rsalveti> 407M for the darwin-x86 prebuilt toolchain
<rsalveti> which I believe we can probably remove
<cjwatson> Why is the kernel source so much bigger than the standard kernel source?
<cjwatson> 107018407 linux_3.8.0.orig.tar.gz
<rsalveti> well, that's compressed
<cjwatson> Ah, what's the compressed figure?
<rsalveti> it's probably around 500MB
<rsalveti> cjwatson: still in progress
<cjwatson> $ zcat /mirror/ubuntu/pool/main/l/linux/linux_3.8.0.orig.tar.gz | wc -c
<cjwatson> 505661440
<rsalveti> yup
<cjwatson> That's still a factor of 4 difference
<rsalveti> we have kernel sources for 4 devices
<rsalveti> but in the archive we already have kernel packages for nexus 4 and 7
<rsalveti> cjwatson: ogra_: 2.4G for the tar.gz file
<cjwatson> Hm.  I admit that's quite a lot.
<cjwatson> Is that with or without kernels?
<rsalveti> we can probably reduce it a bit, not sure how much though, let me remove the obvious
<rsalveti> cjohnston: with
<rsalveti> will remove that and some prebuilt files to see
<rsalveti> argh
<rsalveti> cjwatson: ^
<rsalveti> cjwatson: 1.2G after removing most of the low hanging fruits (3.0G uncompressed)
<rsalveti> less, but still quite big
<infinity> rsalveti: Big, but not unreasonable.  Could be smaller still if it was xz.
<rsalveti> infinity: yup, just didn't want to kill my host :-)
<rsalveti> but probably around 1g still
<ogra_> rsalveti, thx
<rsalveti> ogra_: still trying to get the auto-dump at phablet, but facing firewall issues as usual
<ogra_> yeah
<cjwatson> ogra_: Certainly kapok is unhappy - were you chasing up recovery with IS already?
<ogra_> cjwatson, oops, nope, didnt yet
 * ogra_ notices the mail ... stale lock ... 
<ogra_> cjwatson, pinged #webops
<ogra_> rsalveti, hmm
<cjwatson> thanks
<ogra_> i'm just wondering ... if we could have the whole of phablet.u.c pulled in to a bzr branch on LP ... and set up a PPA autobuild job for a "package" we could probably get around having to shove around sourcecode at all
<ogra_> anyway ... calling it a day now
<cjwatson> Laney: https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links/+merge/159250, since you were asking
#ubuntu-release 2013-04-17
<tjaalton> are we frozen already?
<tjaalton> still trying to get the verdict on mesa
<tjaalton> slangasek: ping?
<tjaalton> infinity, cjwatson: can either of you take a look at mesa? the new version has seen a lot of testing during the past few weeks (and months before that on a smaller scale) as pointed out on the ffe bug
<infinity> tjaalton: I'll have a look.  Point me at the bug again?
<tjaalton> infinity: thx, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093
<ubot2> Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged]
<tjaalton> whoa :)
<infinity> tjaalton: I'd already gone over the source diff a few times in the last day or two.  Just needed to look at the testing trail on the bug to make a decision.
<infinity> tjaalton: So, thanks for being verbose.
<infinity> tjaalton: And please do watch very closely for regressions in the next few days.
<tjaalton> infinity: sure thing, we'll (ab)use the awesome balloons again in the future for point-releases too :)
<tjaalton> and yeah, mesa is top-priority now
<tjaalton> there's 9.1.2 in the works, so the stable branch might have cherry-pickable stuff until we sru the point-release
<infinity> Oh bah.  And this pulls llvm-3.2-dev into main.
<tjaalton> hmm
<tjaalton> it wasn't already? :/
<infinity> Nah, 3.1 is.  Not that I'm against moving to 3.2
<tjaalton> if it wasn't so late I'd push glamor-egl (new) for newer radeons too
<infinity> Curious if mesa is the only rdep of either.
<tjaalton> I think it is actually
<infinity> Yeah, it is.  So this is a simple flip.  No big deal.
<tjaalton> phew
 * infinity promotes 3.2 and lets the world sort itself.
<infinity> Actually, that brings mesa in line with llvm-defaults and clang.
<infinity> Maybe we can start dropping old llvm versions.
<infinity> \o/
<infinity> tjaalton: ... was this not tested in a devirt PPA? :/
<infinity> tjaalton: It's FTBFS on powerpc.
<tjaalton> hrm
<infinity> (A good reason to push this stuff to experimental too, it's good to get all-arch build test coverage)
<tjaalton> it was on two separate ppa's, but neither had powerpc
<tjaalton> the debian-x folks are busy with getting wheezy out :/
<infinity> Sure, but one could still upload a mesa to experimental, surely.
<tjaalton> there wasn't an upload of 9.0 either
<infinity> Anyhow, no big deal.  Just need to fix it.
<tjaalton> right..
<infinity> I can look at it in the morning.
<infinity> Or give you a PPC machine to play with tonight.
<tjaalton> yeah
<tjaalton> gimme
<tjaalton> could be one of the additional lib trickery patches by mlankhorst broke it, I'll let him have a look
<infinity> tjaalton: Oh, I took your "gimme" at face value and was setting you up on a host here. :P
<tjaalton> heh, that's ok
<tjaalton> I guess this is something dead-simple anyway
<tjaalton> probably building too much on ppc
<infinity> Grr.  Why does this machine come up in 1930?
<infinity> And, more importantly, why does dhclient flip out about that?
<infinity> (Which leads to no IP, which leads to no ntpdate, which leads to...)
<cjwatson> infinity: ghc's still stuck on llvm-3.0, I fear, though hopefully that'll be sorted out in the next mega-transition ...
<infinity> cjwatson: Right, but I don't think anything wants 3.1 anymore.
<infinity> cjwatson: So, maybe we can keep 3.0 and 3.2.
<cjwatson> erk, kapok dead in an RT-requiring way says #webops?
<cjwatson> not that I can find the ticket
 * infinity taps his foot waiting for this mesa test build on leviathan to finish.
<infinity> tjaalton: Looks good.  Want to double-check file lists at the end of the build log look sane and upload ASAP?
<tjaalton> infinity: yep
<ogra_> infinity, still awake ?
<infinity> ogra_: Not that I'm willing to admit to.
<ogra_> heh
<ogra_> so now thgat i slept (or rather didnt) sleep over it, i think packaging it is as insane as using a livefs builder ... we should have a dedicated android cross build machine i think
<infinity> Why?
<infinity> Using the package builders is an effective re-use of resources.
<infinity> A dedicated machine would be idle half the time.
<ogra_> because it will eb really hard to automate and to just quickly shove 2G around
<ogra_> more than half
<ogra_> but we will also build a lot more images in the future on it
<infinity> And if we're generating binaries that we're shipping to people, we need to be able to provide the matching source.
<ogra_> thats on phablet.u.c already
<infinity> (Sure, that can be done via other methods, but the archive works well for that)
<ogra_> i know that the archive works well
<ogra_> but you still force someone to shovel 2.1G through the net for every build
<ogra_> its not like it needs to be an overly expensive machine or anything
<ogra_> http://phablet.ubuntu.com/export/ has snapshot tarballs now ...
<ogra_> every new device will add to that and there will very likely be more over time
<infinity> Alright, but that's not forcing any uploader to jam 2.1G across their link then, is it?
<ogra_> so we might end up with 5G or so ... thats just crazy for moving it around
<infinity> You can build a source package remotely, and sign the .dsc and .changes locally.
<ogra_> well, if you only rebuild when git changes it means you need the new upstream tarball for every build
<infinity> Yeah, it sucks if you want to test-build, but you can do that with a local git clone as an approximation.
<ogra_> not talking about tests
<ogra_> a standard change in git will force you ro a new upstream tarball
<infinity> That's not true, that depends on how you package it.
<ogra_> unless yu want to pile up patches and merge them every now and then
<ogra_> you need regular upstream pulls
<infinity> Your orig could be an export based on the 4.2.1 tag (or whatever), and you could ship a git-updates.diff patch.
<infinity> (eglibc is packaged this way)
<ogra_> still, that stuff is not designed like being packaged, its a cross build tree and i would prefer to just have it cross built on a dedicated machine ...
<ogra_> it ends up to be a hell of a package and even if you package it with multiple tarballs you will have to merge regulary
<ogra_> even if you would do one tarball per git repo ... you will have to regulary upload the whole thing at times
<ogra_> no matter how you twist it, its 2G+ of data
<ogra_> (seems kapok took it swerious yesterday though .... its still not back)
<ogra_> -w
<cjwatson> I think it's unlikely you'll get a dedicated machine; IS budget is very very very squeezed
<cjwatson> My understanding is that for anything new it's canonistack or go home
<cjwatson> And Ricardo's numbers indicated more like 1G than 2.1G (that was for source, but it's rare that binaries come out significantly bigger than source)
<infinity> cjwatson: http://phablet.ubuntu.com/export/ came out to 2Gish.
<infinity> (Though xz instead of bz2 could potentially shrink that a fair bit)
<infinity> That might include some bits rsalveti was planning to cull, though.
<infinity> Including prebuilt toolchains...
<infinity> Man, this stuff is a mess.
<ogra_> cjwatson, see the tarball
<ogra_> its android ...
<ogra_> we should simply treat it like that
<cjwatson> Well, OK; but you still don't need to transfer binary components across the network to the livefs builder for bits of the source you don't build.
<ogra_> yeah
<ogra_> but they are massively smaller
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
<cjwatson> Ricardo's numbers from last night don't really support "massively".  Somewhat, maybe.
<ogra_> its all the armel files
<cjwatson> Unless you mean that the binary components we need to transfer around are massively smaller.
<ogra_> yes
<cjwatson> Right.  So that's not really shovelling lots of data around all that often, then.
<ogra_> i need the source first
<ogra_> and i would prefer if that wouldnt have to leave the datacenter for building
<cjwatson> No reason it should.
 * ogra_ is just downloading the tarball locally here for test builds ... 2h+
<infinity> This was why I suggested a pristine-tar/get-orig-source type thing.
<infinity> Locally, you should just have a git clone.
<xnox> ogra_: 12.3MB/s   in 2m 53s ;-)
<infinity> As for how much data is shoved around the DC for builds, surely a 2.1G orig beats a 15G git clone (which is the current method).
<ogra_> xnox, :P
<ogra_> oh, no doubt in that
<ogra_> though i'm not sure it will just work without networking since you need to do a repo sync first to make the brunch tool happy
<ogra_> (i'll see in 2h)
<xnox> one can totally rsync .repo off somewhere. it just works =)
<infinity> Surely that can all be done as part of preparing the source before building the source package?
<ogra_> (and indeed lillipily cant see phablet.u.c so that i could play in the DC)
<xnox> imho one actually just needs .repo as that's where all the git repos are and one does a "repo checkout" to unfold a working forest of git trees.
<ogra_> infinity, yes, my concern is what repo sync does ... i might end up with a 5G tarball in the end :)
<xnox> adjust manifest for source-builds to exclude pre-build toolchain and et.al. as was suggested yesterday.
<ogra_> which would make the whole effort moot
<cjwatson> ogra_: http_proxy=http://squid.internal:3128/
<ogra_> xnox, we cant exclude the toolchain ... which one would you use then (ubuntus doesnt work)
<cjwatson> or is this git protocol rather than http?
<ogra_> cjwatson, !
<ogra_> for the tarball its just http :)
<xnox> ogra_: ah, ok right. I'd upload toolchain separately as a separate package, as I don't think it moves as fast as daily android builds.
 * xnox "don't think" as in "would not expect"
<cjwatson> Hmm, doesn't seem to work through squid.internal either.  I think that's RT-worthy
<cjwatson> porter-amd64 gets a response through squid.internal but it's 403
 * xnox we could have https git repos.... with reasonable performance these days via smart git protocols
<ogra_> lillypilly doesnt even seem to get a response
<ogra_> Proxy request sent, awaiting response... 504 Gateway Time-out
<ogra_> 2013-04-17 09:36:40 ERROR 504: Gateway Time-out.
<ogra_> there we go
<infinity> Riddell: If you're going to make smokeqt build-dep on qwt5, were you planning on filing an MIR for the latter?
<ogra_> hmm, same thing from nusakan ... i thought we had a resolved RT that allows it to see phablet.u.c
<ogra_> but that was probably only kapok
<Riddell> infinity: oh, ug
<psivaa> cjwatson: xnox: not sure if you already know about amd64 raring server image: http://cdimage.ubuntu.com/ubuntu-server/daily/pending/report.html
<cjwatson> psivaa: the builder machine is dead
<ogra_> psivaa, the livefs builder is dead ...
<ogra_> webops is on it (at least i hope there was a proper handover to the next vanguard)
<infinity> Riddell: Or you might just want to revert that upload, given that we're a day from final freeze.
<Riddell> yes, I might
<psivaa> cjwatson: ogra_ ahh ok, thanks
<doko> infinity, cjwatson: please review the icedtea-web upload, security related release
 * infinity was hoping to see " * SECURITY: Stop allowing Java to run in browser plugins."
<doko> tjaalton, infinity: I don't know who did promote llvm-3.2. if the desktop teams wants to support 3.1 and 3.2, fine with me. but it won't be my task ...
<infinity> doko: I promoted it so mesa can build, once it migrates, 3.1 should be able to demote (or be removed).
 * ogra_ twiddles thumbs watching the 2G drip through his DSL
<xnox> ogra_: $ du --si phablet-ubuntu-20130417.tar.xz
<xnox> 1.4G	phablet-ubuntu-20130417.tar.xz
<xnox> that's with -9 and extreme compression algo.
<ogra_> yeah
<ogra_> still way to big imho
<ogra_> but good to know we save 600M
<xnox> ogra_: it would be nice to cut out some cull that was proposed yesterday, maybe we can get down <<1GB with xz then.
<ogra_> cut out what exactly ?
<ogra_> (we will rather add a few G over time ... )
 * xnox vaguelly remembers something mentioned last night. Maybe it was "cut out toolchain" when discussing some alternative plan.
<ogra_> xnox, the toolchain is built during the process .(like everything else of teh OS) .. while it might be possible to cut it out it wont gain us much and just add maintenance overhead imho
<xnox> i see.
<ogra_> we could re-introduce armel and package the whole :)  but that will take months i guess
<ogra_> (the whole in proper abndroid packages)
<cjwatson> We have an armel cross-compiler in the archive ...
<ogra_> with bionic toolchain ? :)
<cjwatson> ... maybe not
<ogra_> i know what we have and i know all that might be better to be done properly in lots of singel packages etc ... but getting the source to that point would cost us more time than we have
<ogra_> and given how temporary all that stuff is yet i doubt it would be clever to invest much time into modifications today
<cjwatson> On the other hand the attempt to do all this on kapok has apparently broken our ability to build amd64 images a week in advance of release ...
<ogra_> yeah
<cjwatson> Which isn't exactly ideal either
<ogra_> i honestly didnt expect that, sorry
<ogra_> RT#60878 is opened ...
<ogra_> yay, download done
<doko> cjwatson, could you have a look at python2.7? brings all the changes from the last python3.3 upload, plus (hopefully) error free autopkg tests
<cjwatson> Looks fine, thanks
<ogra_> wow, even unpacking on my fastest SSD takes 10min
 * ogra_ amusedly watches it building chromium libssl and busybox ...
<ogra_> hmm, i wuld have put my bets on it being faster to build than to unpack ... but seems i would have lost
<ogra_> ... wpa_supplicant ...
<ogra_> *twiddle*
<ogra_> oh, openssl *again*
<ogra_> and there we go ... 12min for building ...
<ogra_> (10 for unpacking)
<ogra_> so now ... how do i add multiarch build deps to a package ?
<ogra_> since it needs a lot of mixed i386/amd64 stuff
<xnox> ogra_: not supported as far as I know =)
<ogra_> oh, lovely ... so we can trash the idea or i hack around it by stacking chroots and scripted hacks
<ogra_> sigh
<xnox> we don't have :native. I guess if you are building $ dpkg-buildpackage -ai386 on the amd64 machine, then "Build-dep: foo:any, foo" will give you i386 & amd64 versions...... but you cannot e.g. "Build-dep: foo:i386"
<xnox> ogra_: pre-installing build-deps is the way to go =/
<xnox> i had to do it for libnih.
<ogra_> preinstalling ?
<ogra_> from an included script ?
<xnox> ogra_: well in my case I had an sbuild chroot variant with a few things installed.
<ogra_> well, my package needs to build on a std amd64 builder
<doko> cjwatson, same please for python3.3
<cjwatson> doko: done
<sergiusens> ogra_: xnox the toolchain used to build android is a linaro toolchain, prebuilt
 * sergiusens says sorry for eavesdropping
<ogra_> sergiusens, ah
<ogra_> well
<sergiusens> http://phablet.ubuntu.com/gitweb?p=platform/prebuilts/linaro-4.7.2.git;a=summary
<ogra_> sergiusens, it needs bionic support though, no
<xnox> sergiusens: hola =) it's the full bionic based?
 * ogra_ really wonders what all these mp4's in the android tree are and why we ship them
<ogra_> thats easily 100M we could save
<sergiusens> ogra_: not really sure about the bionic stuff
<sergiusens> ogra_: I can strip those
<ogra_>  /frameworks/base/media/tests/contents/media_api/videoeditor/ is full of them
<sergiusens> ogra_: we only ever had a git repo we could use in March, before that we had the full tree and applied patches ;-)
<ogra_> /frameworks/base/data/videos/ too ... and there are even some in the docs
<ogra_> yeah
<ogra_> sergiusens, not sure you got the news, but using the livefs builder doesnt work for building
<sergiusens> ogra_: good, now you hace a necessity for me to work on that, I'll get working on making the repo leaner
<sergiusens> ogra_: no I haven't
<ogra_> my build attempt killed  the amd64 builder badly enough that it is still not back up again
<ogra_> so suggestion is to actually roll a package
<ogra_> from a daily export from http://phablet.ubuntu.com/export/
<ogra_> (which ricardo set up last night)
<ogra_> and have the package spit out the right binary images which we can then just pull into a live-build build
<doko> sergiusens, ogra_: so why use yet another gcc?
<ogra_> doko, android requires it
<ogra_> it will likely not stay like it is today after all though
<doko> ogra_, but it's the linaro one
<ogra_> linaro-bionic
<ogra_> i dont think the toolchain has much effect in the tree ... size wise
<doko> is this patches on top of gcc-linaro?
<ogra_> that we cross build a whole OS with all its deps has though
<ogra_> doko, no idea
<doko> yeah
<ogra_> i'm sitting at the end of the chain here and just try to produce images before S opens
<ogra_> from the giant tree i'm given :)
<ogra_> that it is all armel and needs a mixed x86/amd64 build env doesnt help much either :)
<ogra_> but well ... shrug ... android ...
<ogra_> it is like it is
<ogra_> (i would just prefer to just build it as intended by its creators though)
<Mirv> hmm, how is haskell-platform missing from raring even though there is no mention it having been removed? https://launchpad.net/ubuntu/+source/haskell-platform/+publishinghistory
<xnox> Mirv: did you check the binary publishing history as well? one can remove binaries without removing source package.
<xnox> Mirv: see https://launchpad.net/ubuntu/raring/amd64/haskell-platform
<xnox> clearly removed with a comment and bug reference.
<Mirv> xnox: awesome, thanks.. I've always lived in a +source world in LP before this
<Mirv> funny. I need to bookmark that in order to remember that part of LP existing.
<xnox> Mirv: it's a brave new world!
 * xnox usually fiddles with the urls.
<xnox> starting from the: http://pad.lv/u/$srcpackage
<sergiusens> ogra_: sorry, internet crashed...
<sergiusens> ogra_: so why can't you build is as intended by _it's creators_?
<xnox> sergiusens: no place to do it securely.
<xnox> ogra_: we do scp wubi from ev's machine & publish onto CDs =)))))
<xnox> which is like uber-secure =)
<sergiusens> xnox: does that require /win 15
<sergiusens> meh, sorry
<xnox> sergiusens: one needs to become evalicious first =)
<ogra_> haha
<ogra_> well, i would just do it on lillypilly ... if i could actually get the source over somehow
<ogra_> it isnt like the build is massively demanding or so
<ogra_> its just the gigantic source tree thats disturbing
<cjwatson> Please don't build stuff on lillypilly
<ogra_> i would even do it in my home on nusakan ... but same issue there and beyond that i dont want to make cjwatson grumpy
<cjwatson> Use a porter box if you must
<cjwatson> (porter-amd64)
<cjwatson> You can bounce files around within the DC with nc, even if there isn't a direct path
<ogra_> hmm
<ogra_> is the porter box suitable for doing automated stuff (possibly several times a day)
 * ogra_ always thought it was only for one time things like porting stuff :)
<sergiusens> ogra_: can't we keep on using our ps-jenkins? Or does that not meet security requirements either?
<ogra_> sergiusens, i'm close to propose that yeah ... (i actually did to infinity yesterday when he came up with all that)
<ogra_> sergiusens, the point is that the cdimage team needs to be able to trigger it and that it needs to be chronnable once we build the rootfs in the cdimage infrastructure
<sergiusens> ogra_: well, the jenkins thing is the cron we use, but it can be anything
<ogra_> and iit is currebntly a black box from cdimage POV
<sergiusens> ogra_: well we can change that :-)
<sergiusens> ogra_: so the limitation is not hardware, but more so networking in your DC?
<ogra_> no, the limitation is actually hardware ... (imho)
<ogra_> if i would have a choice we would just have a dedicated android build machine
<ogra_> but that costs money which doesnt seem to be there
<sergiusens> ogra_: oh... that's too bad... well we should work on consolidating infrastructure
<ogra_> so the alternatives are: package builders  (meaning someone has to regulary re-roll the source package with fresh tarballs) ... porter-box (same issue, and i dont think it is desired to use it for automation) or ... keep it at jenkins breaking the cdimage workflow and control
<cjwatson> ogra_: the porter box is strictly less unsuitable than either lillypilly or nusakan :-)
<ogra_> sure
<cjwatson> But it's probably still basically unsuitable
<ogra_> but its still not thoguht for doing daily image builds
<sergiusens> ogra_: does cdimage workflow mean that cdimage triggers the build, or does it imply more?
<ogra_> it means that the cdimage team has control over the machines building as well as the code producing the builds
<ev> xnox: technically, there's nothing preventing you lot from doing wubi builds. You just have to update cdimage to look somewhere other than my public_html directory.
<cjwatson> Yeah, but we do need to know we're doing them in a reproducibly similar way
<ev> Sure
<alecu> hi everybody, any news on the FFe for this bug? https://bugs.launchpad.net/unity-lens-music/+bug/1168674
<ubot2> Launchpad bug 1168674 in Music Lens "Purchased songs won't download when not logged to U1" [Critical,New]
<Laney> alecu: Hey, looking
<Laney> can this go today?
<didrocks> Laney: no, tomorrow, the datacenter is broken for running autopilot tests and it's currently being fixed
<Laney> wah
<Laney> before Final Freeze then?
<didrocks> Laney: hardware failureâ¦
<Laney> :-)
<didrocks> yeah, that's why I put pressure that it's done before FF ;)
<didrocks> Final*
<Laney> still a review to sort out on the unity branch anyway it seems
<didrocks> Laney: right
<didrocks> Laney: so you can give a conditional +1 if you want, then I think alecu needs to have merged it today, before 00 UTC
<didrocks> that's the condition, I was quite clear with him about it :)
<Laney> commented
<didrocks> thanks Laney
<didrocks> alecu: now get it fixed/reviewed/merged before 00 UTC ^ :)
<ogra_> why 00 ? freezes are traditionally on thursdays at 21:00
<ogra_> plenty of time :P
<didrocks> ogra_: you need to build the whole stack
<didrocks> ogra_: have tests running
<didrocks> ogra_: this is before the upload
<ogra_> ah, long build, k
<Laney> well, if the hardware remains broken it'll be a manual upload
<Laney> but yes
<didrocks> Laney: the hardware is the hardware to *test* it
<didrocks> Laney: so no, if the hardware remains broken, we won't know the test status
<Laney> sure
<Laney> so it's rather no upload than upload with no tests?
<didrocks> nothing to do with daily release/manual uploads
<didrocks> Laney: right
<Laney> even though it's a "Critical" bug
<Laney> ...
<didrocks> Laney: well, it's in quantal TBH, so I don't agree with the urgency definition
<didrocks> but that's another story ;)
<didrocks> (and it's known for months by design)
<didrocks> but still good to have it fixed in raring
<Laney> hrm
<Laney> yet only filed 4 days ago
<didrocks> Laney: talk to design and their bugs handling :p
<Laney> could you lower it?
<seb128> to be fair they hoped to have it fixed by the "buy in the dash" feature
<didrocks> Laney: I think high will make more sense
<seb128> which didn't land at the end
<Laney> I don't like severity inflation on release bugs - makes me feel like I'm being pressured into approving
<seb128> Laney, johnlea will start arguing with you over the bug importance I'm sure ;-)
<didrocks> Laney: High it is :)
<Laney> haha
<Laney> thanks didrocks
<seb128> Laney, the bug leads to have the money taken from users' bank account and not get the song they bough downloaded in exchange
<didrocks> yw ;)
<seb128> Laney, which you can argue over the importance, but would be good to be fixed ;-)
<ogra_> pfft, whiners ... we'll send them a reciept for their tax declaration in return
<seb128> ;-)
<Laney> if we wouldn't upload out of process to fix it then I can't say that it's critical
<Laney> maybe it's a case for distro/upstream importance though
 * Laney moves on
<didrocks> anyway, alecu will get it in a mergeable state, and we'll have the hardware replaced today :)
<didrocks> so everything's fine
<Laney> oh, friends has the fix for notification spamming
<Laney> popey will be pleased!
<popey> \o/
<popey> there's only so many times I can see "Happy birthday Alan" from my cousins
<Laney> it seems slightly curious that it doesn't consider whether you've seen the notification before
<Laney> it just says "no notifications older than 5 days"
<Laney> robru: ^? is that accurate?
<kenvandine> Laney, it is accurate
 * Laney nods
<kenvandine> Laney, friends doesn't keep track if notifications have been seen or not, so to prevent spamming the user he limited it to the past 5 days
<seb128> kenvandine, so you will still get 5 days of backlog display every time?
<kenvandine> no
<kenvandine> it is just the first time the service starts
<Laney> I thought some people were complaining that they saw them at every startup
<kenvandine> it only notifies for new content downloaded
<kenvandine> the every startup was fixed separately, i think
<kenvandine> it caches what has been downloaded and doesn't download new content again
<kenvandine> so shouldn't notify for that
<Laney> alright, well I never saw it myself anyway
<kenvandine> but on first run you would get notifications for private messages and mentions from long ago... maybe even years :)
<Laney> I think popey was affected, hence the ping earlier, so maybe he can say if it still happens
<kenvandine> if i use it for twitter in a guest session i got notified for private messages from 3 years ago :)
<Laney> \o/
<kenvandine> not useful :)
<kenvandine> next cycle we want to implement a queue of some sort
 * popey updates
<kenvandine> same for errors
<kenvandine> so the UI can also present some of it
<kenvandine> and ack them
<kenvandine> etc
 * Laney petitions for twitter "list" support
<xnox> Laney: yeah, upon first upgrade I got popups for every @ mention I ever had. Since I'm a very active twitter user the total amount of popups was 8 bubbles.
<xnox> but I haven't seen anything since.....
<Laney> that's alright then - IIRC some people reported getting them again and again but if that's fixed then cool
<alecu> Laney, didrocks: thanks!
<rsalveti> ogra_: sergiusens: xnox: as I said yesterday, we can remove quite a few files there, like docs, video, kernel sources duplicates and such
<rsalveti> the work I did yesterday was just to dump the stuff at this point, we can work cleaning it up a bit at least
<ogra_> rsalveti, right, i noticed that when unpacking here
<ogra_> also xz would help a lot
<ogra_> i guess we can melt it down to ~1G compressed
<rsalveti> ogra_: yup, can easily change here
<rsalveti> xnox: what compress options did you use?
<ogra_> it builds just fine btw
<ogra_> at least mako
<rsalveti> ogra_: yeah, cool, built for mako and manta here
<ogra_> didnt try others but i dont expect them to be different
<rsalveti> ogra_: also, see that platform-api and hybris is not there by default
<xnox> rsalveti: -9e, that is maximum extreme compression, but without my host CPU specific optimisations.
<sergiusens> rsalveti: doing it as we speak...
<ogra_> rsalveti, ow ... how do we handle that
<rsalveti> ogra_: because they are from bzr
<rsalveti> check phablet-dev-bootstrap
<ogra_> right
<rsalveti> we basically clone that after cloning the tree
<rsalveti> so you'd need to do something similar
<ogra_> hmm, that would have to become part of building the source package then
<rsalveti> sergiusens: cool, let's sync then after the call
<ogra_> means the source packager needs to rebuild the tarball
<rsalveti> well, that's not part of phablet.u.c
<rsalveti> right
<ogra_> right
<sergiusens> ogra_: rsalveti you can get the debian source package for hybris and platform-api and dump them in the tree
 * ogra_ keeps that in mind then
<rsalveti> yeah, was thinking at something along that line
<ogra_> oh, i could just build dep on it then+#
<rsalveti> but they are not yet incorporated at th archive
<ogra_> and copy it from the host
<ogra_> ah, crap
<ogra_> ok
<ogra_> so repackaging the tarball it is then
<ogra_> rsalveti, i would still prefer just a dedicated builder even if we can shrink down the source
<ogra_> instead of jumping through hoops to wrap it in a package
<sergiusens> ogra_: +1
<rsalveti> xnox: let me change for that then and see :-)
<rsalveti> ogra_: sergiusens: also, I'm just generating the dump file if we actually changed something at the git trees
<ogra_> yeah, saw that
<ogra_> good move :)
<xnox> rsalveti: -9e takes ages to compress, -6 is relatively good speed & compression ratio. If you have multiple cores, you can use pxz -9e that will compress in parallel for a small tradeoff (3-6% compression penalty)
<rsalveti> xnox: yeah, will check here, thanks!
<darkxst> my gnome-shell/mutter SRU (MRE) has been stuck in the queue for like 7 weeks now!
<ogra_> my tegra video codec package has been stuck in the queue for 7 months now
<darkxst> ogra_, wow
 * xnox finds that whenever one complains about anything, somebody else can totally trump that =)
<barry> bug 1170003
<ubot2> Launchpad bug 1170003 in python-virtualenv (Ubuntu) "[FFe] python-virtualenv 1.9.1" [Undecided,New] https://launchpad.net/bugs/1170003
<barry> bug 1167351
<ubot2> Launchpad bug 1167351 in python-pip (Ubuntu) "[FFe] update python-pip to version 1.3.1" [Undecided,New] https://launchpad.net/bugs/1167351
<robru> Laney, twitter lists are implemented in the backend, it's just a matter of writing some Qml UI for it in lp:friends-app ;-)
<Laney> :)
<ogra_> yay, kapok is back
<Laney> yaypok
<ogra_> heh
<slangasek> infinity: llvm> right, it's in main exclusively for mesa's benefit; so provided we're satisfied that mesa's llvm driver passes regression-testing, no problems at all there
<infinity> slangasek: *nod*
<infinity> slangasek: I think doko just had a bit of a sad when llvm-3.2 was pre-promoted to satisfy the build-dep change.  Now that the dust has settled, 3.1 has gone to universe, and all should be well.
<slangasek> yep
<infinity> cjwatson: So, I was thinking, for things we can't fix in -proposed but don't want to remove (handbrake is a good example here, it's not actually "broken", it just needs a libav9 transition to work)...
<infinity> cjwatson: After we IFP from raring to s-series, shall we just batch-copy raring-proposed/* to s-series-proposed/ and then empty raring-proposed and call it done?
<infinity> cjwatson: (Cause removing and then reuploading with no changes seems silly)
<robru> Laney, hey. I have a fix for https://errors.ubuntu.com/problem/e3327729f0945e5fb94001ecd9b54bc658a69c1e on it's way (pending review from Ken). sorry to be a bother at the last possible second, but it's the #3 error so I'm hoping it will be well-received ;-)
<cjwatson> infinity: Yeah, I was thinking roughly that
<cjwatson> infinity: We probably just want to keep careful note of what's been uploaded to -proposed as a 0-day SRU
<infinity> cjwatson: Indeed.  Shouldn't be rocket surgery.
 * infinity decides to blindly handwave past ekg's obvious issue with building with -j24 for now.
<infinity> La la la.
<ogra_> infinity, just FYI, we'll keep the builds on jenkins for now ...
<Laney> robru: Do it. We can review in the queue.
<infinity> ogra_: Alright.  kapok thanks you.
<ogra_> and instead of rushing we'll try to split it all into little pieces and cross build packages
<ogra_> infinity, well, i made it have a vacation day ... it should thank me in any case
<kengyu> it will be very appreciated if one of the release team can review this bug: https://bugs.launchpad.net/ubuntu/+source/fwts/+bug/1166610
<ubot2> Launchpad bug 1166610 in fwts (Ubuntu) " [FFe] fwts 0.26.08" [Undecided,New]
<infinity> kengyu: Go ahead and upload, I'll review it in the queue.
<kengyu> infinity, thanks.
<pgraner> infinity, http://pastebin.ubuntu.com/5716794/
<infinity> pgraner: So, I'm curious what's pulling in indicator-applet on your upgrade.  Nothing here is, but I suspect that's your issue.
<pgraner> infinity, I don't know
<jpds> pgraner: sudo apt-get dist-upgrade -y -s # And see what drags it down?
<infinity> That could be a red herring anyway, since I can install that just fine here (though, it shouldn't be getting pulled in at all...)
<robru> Laney, ok, two bugfixes just landed in lp:friends trunk, do I have to push those manually now? autolanding is disabled, right?
<Laney> robru: No idea
<Laney> The cron job is still enabled on lillypilly, at least
<xnox> robru: is there lp:friends/13.04 branch?
<robru> xnox, no, we have a trunk-next where we've done some S-stuff, and kept lp:friends as the "official" raring branch
<Laney> oh no, I see it in lp:cupstream2distro-config r212
<Laney> Set raring to manual mode for Final Freeze.
<Laney> so I guess you have to kick a manual release, however in the world that happens
<Laney> cyphermox can probably advise :-)
<robru> Laney, crap, I guess it needs a manual upload (I don't have upload rights). Usually I let Ken do it but he's been busy today...
<Laney> I think there's a mechanism for doing that from the daily release machinery ... but I don't know what the proper way to do this is
<Laney> if it's urgent I can sponsor it normally though
<robru> Laney, just heard from Ken, he's on it.
<robru> Laney, but thanks.
<Laney> rocking
<Laney> kenvandine: For info/curiosity, what is the proper procedure? Is it https://wiki.ubuntu.com/DailyRelease/FAQ#Forcing_a_stack_publication ?
<kenvandine> Laney, i am not sure
<kenvandine> i think we just need to do a manual run
<kenvandine> and force push on the stack
<kenvandine> using c2ud
<kenvandine> i think it just isn't automatic anymore
<Laney> yeah, that's why I'm looking at that section of the FAQ ;-)
 * Laney leaves it to you
<kenvandine> robru, friends should be hitting the queue any moment :)
<robru> *huge sigh of relief*
<kenvandine> robru, *should*
<robru> kenvandine, the bugs we've fixed today I'm sure will stave off *hundreds* of duplicate bug reports to triage once raring is released ;-)
<kenvandine> yup
 * kenvandine hopes compiz hits :)
<robru> kenvandine, oh me too! if not we pretty much need to SRU that immediately.
<robru> Laney, ^^ :-D
<robru> Laney, last hassle from me, promise ;-)
<Laney> never make promises like that :P
<robru> Laney, no serious, that's all the time I have for Friends... rest of my day is shot working on didrocks' autolanding stuff.
<Laney> right - that's friends done for raring then I hope
 * Laney accepted
<Laney> thanks robru
<robru> Laney, thank you! all the major crashers are fixed, the only open bug reports I see here are wishlist features ;-)
<jdstrand> is it ok to upload xorg-server with a small security fix?
 * xnox remebers a "security" fix in dbus that broke ubiquity installer for Kubuntu....... =)))))
<doko> cjwatson, slangasek: final ( ;-P ) python2.7 and python3.3 uploads ...
<doko> the no-change uploads are independent of these
<jdstrand> it is this patch for raring: https://launchpadlibrarian.net/137637827/xorg-server_2%3A1.13.0-0ubuntu6.1_2%3A1.13.0-0ubuntu6.2.diff.gz
<xnox> jdstrand:  looks harmless to me. but then again i'm no release team.
<infinity> jdstrand: Go for it.
<jdstrand> yes, it is. I already published a USN for the stable releases :)
<jdstrand> infinity: thanks!
<cjwatson> doko: Ack, thanks
<cjwatson> Oh, somebody did it already :)
 * cjwatson submits an LP branch to help make diff generation more responsive
<doko> so I think the python-numpy upload looks ok
<doko> and the gdb uploads are minor fixes, plus going back to python2.7 for the pretty printers
<doko> and that's all for today from me
#ubuntu-release 2013-04-18
<cjwatson> infinity: d-i changes for linux and linux-ppc in bzr, but I'm not going to upload now since I won't be able to coordinate seed changes overnight; if you feel like doing so then be my guest
<infinity> cjwatson: There's an incoming linux-ti-omap4 too, plus the better-late-than-never s/omap/generic/ madness, so I'll get it.
<cjwatson> Righto
<hallyn> hi - has anyone looked into authorizing FFE for bug 1167939 ?
<ubot2> Launchpad bug 1167939 in libvirt (Ubuntu) "FFE for libvirt 1.0.4" [Undecided,New] https://launchpad.net/bugs/1167939
<infinity> hallyn: The 12MB debdiff attached to that bug is dedicedly unhelpful.
<hallyn> infinity: yeah it's two releases past what's in raring now.  But it also fixes qemu migration, even breakages in precise
<hallyn> also has passed all regression tests
<hallyn> the alternative to fix migration is a qemu update, of course we could just say migration isn't terribly important for the release cd,
<hallyn> and leave the fix for first day that r+1 is open
<infinity> If there's a fix that can be cherrypicked, that might be favourable...
<hallyn> for qemu there is a set that can be cherrypicked (plus my own one-liner which also fixes it :).  though i've only tested a 50-set fix, not the 4 or 6 patches which are supposedly all that is needed.  I point that out bc depending on context, porting 4 qemu patches can take days, or could be 30 secs.
<hallyn> i do wish zul were here to speak up :)
<infinity> I meant cherrypicks for libvirt.
<infinity> Since this is working around a qemu bug, right?
<infinity> Surely, that massive diff and changelog isn't all for the one bug.
<hallyn> it's for 2 releases worth of diff
<infinity> Well, yes.  I get that.  I'm saying that if the goal here is to fix a bug, that's a whole lot of diff for that.
<hallyn> yeah when i was first workign on it it still seemed early enough to push the whole thing.  at this point not
<hallyn> i'll test the fix backport tomorrow
<Mirv> hi. could the ubuntu-ui-toolkit 0.1.42 be approved? we'd like to have as up-to-date toolkit in raring archives as possible, and it's also now in sync with the upstream (from which there is a changelog inoptimality, ubuntu-sdk package was already dropped from raring)
<Mirv> the documentation updates are probably the most important stuff in addition to marking some API deprecated. the documentation is erronous in the current raring package.
<stgraber> ^ as usual, this one looks way harder to review than it's, just ignore the translation update and the diff will be easy to read ;)
<didrocks> whoever reviewed nux, there is the new stack of the day just comming (you can approve both or just one) ^
<didrocks> (well, one == the latest)
<cjwatson> so, after the next LP deployment, there'll be links to the source archive for syncs in the web UI, and a new copy_source_archive property on package_upload objects in the API
<Laney> excellent
<didrocks> cjwatson: oh nice!
<didrocks> Laney: btw, the unity+music lens contains what we discussed yesterday ^
<Laney> ok, looking
<cjwatson> diffs are going to be a bit harder to fix
<Laney> much easier to construct that yourself now though
<cjwatson> yeah, I think it should be possible to have queue/queuediff automate it
<cjwatson> (though slowly, if you have a narrow pipe)
<apw> infinity, linux{-meta,}-lowlatency should now both be in the queue for you delecation and delight
<infinity> cjwatson: New eglibc uploaded.  Should be a simple/quick review.  But can you do me a favour and not accept it until at least one arch (ppc will likely win) succeeds at https://launchpad.net/~adconrad/+archive/ppa/+packages ?
 * infinity needs to attempt a short nap.
<cjwatson> ok
<infinity> cjwatson: I disabled the testsuite in the archive version of the upload (to reduce security team pain), so I'm relying on the PPA to tell me that the world is still vaguely okayish.
<infinity> If the glibc testsuite wasn't so effin' sensitive to tiny kernel bumps and moon phase...
<Laney> are we sitting on fglrx-installer* for a reason?
<Laney> didrocks: will the daily release machinery be fine with me rejecting nux since it has no changes over the archive version?
<infinity> I was sitting on it while I had a lively debate with tseliot about it.  I think the debate was mostly resolved, but I might want to re-review it what that in mind.
<Laney> I'm guessing manual mode makes this ok?
<infinity> s/what that/with that/
<infinity> Which I should do with a fresh slightly-napped brain in the morning.
<didrocks> Laney: you will need to tweak nux trunk to remove the changelog though
<Laney> Would it cause problems to have it there next time?
<didrocks> Laney: yeah, there is a change from the version in distro, so it will try to rerelease
<Laney> even on manual mode?
<Laney> when you push a whole stack I suppose
<didrocks> Laney: well, in manual mode, it will be block before publishing
<didrocks> Laney: but it will still build daily
<didrocks> to know the current trunk state, running testsâ¦
<didrocks> Laney: so the best way is to remove the changelog entry in nux trunk
<infinity> I don't imagine there is/was a plan to do a final release upload of these bits without all the silly versioning?
<didrocks> infinity: we will still have daily release and some manual publishing for SRU, so it will still continue to use the same versioning scheme
<infinity> (Not that versions matter that much, it just looks a bit icky to have VERdailyDATE-MOREVER for everything.
<didrocks> infinity: better suggestion welcomed at the sprint to have an easier versioning that covers all the cases :)
<infinity> If the intent is for *all* uploads of these items to happen via daily automagic, dropping the "daily" from that string would make it much less icky.
<Laney> Hmm, it doesn't build daily anyway?
<didrocks> Laney: it's still building daily if there are changes, and running tests
<infinity> 4.0.1.13.04.15-0ubuntu1 is almost readable.
<didrocks> Laney: it's just not published to distro without a manual intervention
<didrocks> infinity: hard to tell the "upstream" version from the date though
<didrocks> infinity: but yeah, that's an option
<infinity> didrocks: 4.0.1+13.04.15 then. :P
<didrocks> it will be 4.0.1.13.04.15~13.04-0ubuntu1 btw
<infinity> Ew.
<infinity> Oh well.  I guess I should stop thinking of version numbers as something I want to read. :)
<infinity> Either way, the "daily" string is entirely redundant if it's now in every upload.
<didrocks> infinity: agreed, I wanted to make clear automated upload, but I think we can remove it
<infinity> didrocks: I think the datestamp makes it clear it's a snapshot of a VCS, how that snapshot got to the archive is less interesting (though the changelog tells the story).
<didrocks> infinity: and the + fixes the issue that the . doesn't: dpkg --compare-versions 4.0.1 gt 4.0+13.04
<didrocks> so + can be acceptable :)
<didrocks> Laney: going to propose a branch to nux then?
<infinity> Or, someone can accept that prematurely.  That works too. :P
 * infinity shrugs and figures it's probably fine anyway.
<Laney> didrocks: I suppose so. Feels quite heavyweight though.
<didrocks> Laney: well, what would you propose? :-)
<Laney> Automation ;-)
<didrocks> Laney: like, a reject remove the commit string?
<Laney> Something like that
<Laney> makes it stop publishing until someone resolves it maybe
<didrocks> Laney: it seems you want to ack on launchpad ;)
<didrocks> Laney: stop publishing?
<didrocks> Laney: we can have manual uploads to ppas meanwhile
<didrocks> Laney: so additional entry changelog
<didrocks> we can't force "top entry" == "distro"
<Laney> the problem now is that it'll keep uploading/building because it thinks there's a difference to distro?
<didrocks> (hence it's using -V)
<didrocks> Laney: right
<didrocks> because there is one
<cjwatson> infinity: wasn't me :-/
<infinity> cjwatson: Meh.  The diff itself was entirely harmless and really shouldn't have caused regressions.  I was just being paranoid because I haven't built glibc on the buildds with the current toolchain in a while.
<Laney> didrocks: Sorry, I can't really come up with an implementation other than to detect rejections and unilaterally block publishing until someone clears it
<Laney> or automatically create an MP with the reverse diff, or something
<didrocks> Laney: yeah, maybe we can create an MP for the reverse diff, but I just want to hilight that process-wise, it's tricky :)
<didrocks> Laney: let's just do a revert MP, ping me, I'll approve it
<Laney> will do
<didrocks> thanks :)
<Laney> I get that there's a load of hairy stuff here but we should try to identify areas where it's more work than the normal process and try to optimise those
<seb128> Laney, or just approve the most recent upload and be done with it? :p
<didrocks> seb128: that would have been way easier ;)
<didrocks> seb128: but I guess, it's too late now :p
<Laney> in general there might be cases where you want to reject an upload though
<seb128> Laney, it's already built, it's not even going to waste builder time...
<seb128> Laney, right, in which case you get to do the extra work
<seb128> Laney, which you could easily spare here ;-)
<Laney> Ideally I wouldn't have to treat these packages any differently to any other upload
<stgraber> infinity: I did the accept for eglibc as I didn't see any "don't accept" message on IRC. The diff looked good, matched the changelog and the diffs linked on those bugs. If you don't want stuff accepted, don't upload them ;)
<infinity> stgraber: A little under an hour ago in scrollback, but not a big deal.  I was just being overly paranoid combined with wanting it built while I was asleep.
<seb128> Laney, I've issue with people who only accept one of the uploads in the queue, it made me have some bugs not autoclosed this week
<seb128> Laney, what's the issue with just accepting 2 versions together when they are stacked in the queue? the publisher should deal just fine with those
<Laney> It's pointless to have it in the history of the package
<stgraber> infinity: ah, sorry missed that one as it was directed at cjwatson and before queuebot registered the upload.
<seb128> Laney, well, it's part of the upload history...
<infinity> Not to the archive, it isn't.
<seb128> like it's tagged etc in the vcs
<infinity> And, more to the point, saying that an AA who has a valid reason to reject something is then responsible for doing extra work to propose an MP to revert the thing he was rejecting for is silly.
<stgraber> infinity: anyway, looks like ppc succeeded
<seb128> infinity, what's the cost of accepting 2 versions together? is there any side effect?
<cjwatson> seb128: err, remember that people looking at the queue may not necessarily be immediately aware that uploads are "stacked"
<infinity> stgraber: Indeed.  <3 sagari.
<cjwatson> I often contribute small amounts of effort at a time to queue review; if you tell me that I have to assess the entire queue before accepting anything, I just won't do it
<infinity> stgraber: Shame the archive build will take 10 times as long. :P
<seb128> cjwatson, well, if there are e.g 2 nautilus revision in the queue and you review the most recent one and ack it, what happen to the older one?
<cjwatson> and bugs not being autoclosed for all intermediate versions is an LP bug which you should report, IMO
<cjwatson> hm, well, maybe.  complex.
<cjwatson> seb128: the rules are unclear
<seb128> cjwatson, well, closing is done from the .changes, so in theory whoever upload should -v from the current archive version I guess
<stgraber> infinity: it's almost tempting to switch the other ppc builders to manual once we hit final freeze so that anything that needs to get built will at least build quickly ;)
<seb128> cjwatson, but in practice when people work from a Vcs they just work and upload without checking the queue to see if they need -v
<cjwatson> seb128: but you saying you have an issue "with people who ..." is unhelpful
<infinity> stgraber: For small packages, they're actually faster than sagari, due to sagari's crap bandwidth in Boston.
<infinity> stgraber: So, it's a crap shoot until that gets resolved.
<infinity> stgraber: (But if we need an emergency linux-ppc or gcc or libreoffice or whatever, I'll aim it at sagari, yeah)
<cjwatson> I cleaned up most of the reasons why -v is necessary for SRUs; it would probably be worth looking at it for dev-series uploads too
<seb128> cjwatson, it's maybe not rightly phrased, but what would be wrong saying "if you accept the most recent revision on a package in the queue, accept the previous revision for it that are in the queue at the same time"
<stgraber> infinity: hopefully the shiny new calxeda hardware being installed in Lexington will make the priority of that RT even higher, because having to wait 30min for every armhf upload won't be fun at all
<seb128> cjwatson, e.g just "queue accept <source>"
<cjwatson> seb128: I can understand why people don't want to default to that behaviour, because it can be a considerable amount of build time
<cjwatson> it's not something you can always do
<infinity> stgraber: Exactly.  I'm using that very thing as leverage to get that ticket looked at a bit harder.
<seb128> cjwatson, builders are smart enough usually, from what I saw, to not try to build old versions when there is a new one accepted
<cjwatson> hahahahahahaha
<cjwatson> no they aren't
<infinity> They really aren't.
<seb128> ok, wrong observation then ;-)
<Laney> is that even guaranteed to work, given proposed-migration?
<infinity> They won't build for source that's marked "superseded", but that only happens AFTER the new one is published.
<cjwatson> and if the intermediate version was broken and you get unlucky with builder speeds, you can end up introducing broken stuff into -proposed which breaks other builds
<infinity> So there's a massive window there where you can build seven versions of the same source. :P
<cjwatson> so it's really not as simple as "just accept both
<cjwatson> "
<cjwatson> I'd rather try to make -v unnecessary
<seb128> cjwatson, I guess the best fix then would be to teach launchpad to close... what you are saying
<seb128> should I open a bug about that against launchpad?
<cjwatson> but it does interact in a complicated way with the semantics of Launchpad-Bugs-Closed
<Laney> Say both are built/published in proposed at the same time, I assume that proposed-migration will ignore the older version
<infinity> Laney: Two can't be published together.
<cjwatson> perhaps the right approach is to supersede old versions earlier or something
<Laney> infinity: what happens?
<infinity> Laney: If both build in the same publisher cycle, only the newer one will get published.
<Laney> So, same effect then
<cjwatson> seb128: I'd like a bug about the general situation please, but it might be best not to suggest a single solution to it, as I think a proper solution will require some thought
<Laney> Only the newer LP-Bugs-Fixed gets considered
<infinity> Laney: But none of that prevents the build from happening, just gurantees archive sanity after the fact.
<cjwatson> we might want to talk about this at the release team sprint if that ever happens
<Laney> I'm trying to argue that it doesn't even work in most cases, buildd time wasting notwithstanding
<infinity> cjwatson: AFAIK, it's happening, though we've failed to set a date.
<Laney> Aaaaaaaaanyway.
<infinity> Laney: Oh, I see what you're driving at.  Since source copies from proposed to release are what triggers bug closures.
<Laney> right
<cjwatson> no, it works a bit better than that
<infinity> Though that should be the same flow/usecase that Colin fixed for SRUs.
<infinity> In theory.
<Laney> Unless it unions LP-Bugs-Fixed
<cjwatson> it does
<cjwatson> on copy from proposed to release, it walks back through the ancestry to the most recent version in release and looks at all the .changes files
<Laney> shiny
<cjwatson> I think
<cjwatson> actually, I think on copy it might reparse the changelog, which is arguably wrong ...
<cjwatson> but in practice mostly has the same effect
<cjwatson> I think some confusion about semantics has crept in along the way
<infinity> Tsk, tsk, parsing the changelog...
<cjwatson> Yeah.  But it *could* walk the .changes. :-P
 * infinity doesn't want to admit that he's manually twiddles .changes to fix a bug closure on a source package he didn't want to re-pack.
<infinity> s/twiddles/twiddled/
<cjwatson> You're supposed to be allowed to do that :)
<infinity> I've also done that with Debian fakesyncs, adding LP bug closures to .changes where they weren't previously.
<infinity> That was back when I was far less lazy than I am now.
 * Laney accepts compiz despite the slightly borked changelog
<Laney> claiming to close a bug that it actually reopens
<cjwatson> Anyhow, I think the only way to get to what seb128 wants while preserving correct Launchpad-Bugs-Fixed semantics would be to accept all the intermediate uploads and arrange not to build them
<seb128> cjwatson, https://bugs.launchpad.net/launchpad/+bug/1170301
<ubot2> Launchpad bug 1170301 in Launchpad itself "It would be nice to have bugs-autoclosing working for intermediate revisions non accepted to the archive but included in a new upload" [Undecided,New]
<infinity> We need syntax for "reopens:" (Debian) and "UNLP:"...
<infinity> cjwatson: That only works if you accept the newest first, then you could immediately superses the others as you accept.
 * Laney claims a DEP number for that
<infinity> (Though, right now, I think they'd just fall into a reject/fail loop if you went in that order)
<infinity> Laney: Go for it.  It's annoyed me for a while that you just have to do an intentionally broken-syntax bug reference in your changelog and manually reopen.
<Laney> Oh crap, I was joking. /me goes dark
<cjwatson> infinity: Works the other way round too if either (a) you manage to accept them all before the first starts building or (b) we have the ability to reliably cancel builds
<infinity> cjwatson: I can make (b) one of my top priorities right after release.
<cjwatson> please do :)
<cjwatson> I'd love to have that
<infinity> cjwatson: (a) seems unlikely, given that we kinda want to make things faster, not slower.
<infinity> Totally time for a new buildd-manager rewrite.
<cjwatson> Yeah, though it's probably the common case right now
<Laney> Do you mean automatically cancelling builds when the source becomes superseded?
<cjwatson> Yes
<infinity> Yeah.
<infinity> And that's valuable regardless.
<cjwatson> Which depends on the ability to cancel builds at all without ops intervention
<Laney> That would be suhweeeeeeeeeeeeeet
<cjwatson> (non-PPA builds, that is)
<infinity> Anyhow, I've been experimenting with webops to make sure that my proposed method for build killery is vaguely foolproof, and it should be.
<infinity> So I just need to hook it into the right spots.
<infinity> And unbugger buildd-manager to not be so mind-numbingly stupid.
<cjwatson> Is that the sbuild kill-all-children approach?
<infinity> cjwatson: That approach no workie, misses processes that get reparented.
<infinity> cjwatson: This is the "walk /proc and slaughter everything in the chroot" approach.
<infinity> Aaanyway.  I was meant to be napping an hour ago.  I should get to that before the sun comes up and says mean things to me.
<infinity> Jerk sun.
<cjwatson> ah yes ok
<cjwatson> we should start accumulating things to do at the release sprint in a more structured way than "in our heads"
<infinity> Start a google doc and lose the URL.
<infinity> Alternately, start a mail thread.  I hear those used to work back in the dark ages of last year.
<cjwatson> or I hear we have a wiki
<cjwatson> Can somebody look at localechooser in NEW?  I'd like to upload a ubiquity containing it.
<cjwatson> Er, in UNAPPROVED that is
<stgraber> looking
<cjwatson> Thanks
 * cjwatson grabs another translation export
<seb128> tjaalton, slangasek, Laney: the libgl1-mesa-dri update makes unity segfault on start in vms
<seb128> go for new versions just before hard freeze :/
<cjwatson> does that include the one in the queue?
<seb128> cjwatson, no, current raring
<seb128> cjwatson, I can try building the one in the queue
<cjwatson> I asked on #ubuntu-devel
<cjwatson> but would be good to know
 * cjwatson goes for lunch
<seb128> cjwatson, trying a build, thanks
<seb128> libgl1-mesa-dri_9.1.1-0ubuntu3~ppa1_i386.deb from https://launchpad.net/~mlankhorst/+archive/ppa/+build/4501757 fixes the issue
<didrocks> Laney: you didn't review unity-lens-music on purpose?
<didrocks> Laney: as it's the second part for the FFe/UIFe :)
<Laney> perhaps I missed it or it appeared after I did the otehrs
<didrocks> Laney: should have been at the same time than the rest :)
<Laney> anyway, give me 5
<didrocks> Laney: high five! :)
<kenvandine> Laney, can you please reject ubuntu-ui-toolkit 0.1.42 and take a look at 0.1.43?
<kenvandine> it has some important fixes
<Laney> yes and no(t immediately) - going for lunch now
<kenvandine> sure :)
<kenvandine> enjoy your lunch :)
<Laney> stgraber: â? :-)
 * Laney runs
<stgraber> Laney: in a meeting but I'll try to take a look during/after it
<kenvandine> stgraber, thanks
<stgraber> kenvandine: do you have some kind of standing freeze exception for ubuntu-ui-toolkit?
<kenvandine> Mirv, ^^
<stgraber> kenvandine: also you appear to have included debian/bzr-builddeb.conf in that source package. I thought this was being sripped when using "bzr bd -S". Won't cause any problem, just noticed it in the review.
<kenvandine> oh, yeah i thought that got stripped
<kenvandine> stgraber, i pulled bug fixes in from trunk since 0.1.42, which had been sitting in the queue
<kenvandine> but there are features before that
<kenvandine> and since last upload...
<stgraber> right, 0.1.43 on its own would be fine, 0.1.42 not so much, unless there was some kind of agreement that this package wasn't subject to feature freeze
<Laney> I don't think there was
<kenvandine> stgraber, there was a FFe bug 1157191
<ubot2> Launchpad bug 1157191 in ubuntu-ui-toolkit (Ubuntu) "[FFe] API updates for MainView, PageStack and Tabs " [Medium,Fix released] https://launchpad.net/bugs/1157191
<kenvandine> and part of those changes include fixes related to that
<kenvandine> a couple bugs and documentation fixes
<kenvandine> it looks like the only real feature in there is the Icon component
<kenvandine> in 0.1.39
<kenvandine> oh, theming engine too
<kenvandine> but that actually fixed a pile of style bugs...
<stgraber> yeah, there's also:
<stgraber> +    - Added "make license" target
<kenvandine> stgraber, that is just for adding a test in the build
<kenvandine> i don't think that changes the resulting packaging
<stgraber> ah ok, that wasn't clear from the changelog
<kenvandine> sorry :)
<kenvandine> it is for a checklicense test that CI does
<kenvandine> makes sure all the files have the right copyright and license in the header
<rbasak> Is there still interest in FTBFS fixes for unseeded packages in Raring? Or shall I leave these now? And is there an easy way of determining if a given source package is unseeded?
<stgraber> so, who exactly is using that package at the moment? I see it's not shipped on any of our media
<stgraber> rbasak: we're still interested in FTBFS fixes. You can use seeded-in-ubuntu to check if it's seeded or not
<kenvandine> stgraber, it is in universe and the only package that uses it is friends-app
<stgraber> rbasak: if you find out that a package that FTBFSed is actually seeded, then it's a reason to fix it ASAP, not to ignore it because we're about to freeze ;)
<rbasak> stgraber: OK, great. And I didn't know about seeded-in-ubuntu - thanks!
<rbasak> Ah - good point.
<dtchen> rbasak: yeah, i could really use some help with them :)
<stgraber> kenvandine: ok, and is friends-app broken without the new version?
<kenvandine> stgraber, so very low risk and most of the fixes in 0.1.43 fix bugs reported in friends-app
<kenvandine> yeah, there are some textinput bugs
<kenvandine> which this fixes
<kenvandine> and the theming change too
<kenvandine> that fixes bugs found in friends-app
<stgraber> ok, so on the basis that the theming engine change makes it work for you (as opposed to breaking the world), I think I'm fine with this. Letting it through.
<kenvandine> great
<kenvandine> :)
<kenvandine> stgraber, thx
<hallyn> stgraber: infinity: ok, it seems the tiny debdiff at http://people.canonical.com/~serge/libvirt-migrate.debdiff fixes the libvirt-qemu migration bug 1157626
<ubot2> Launchpad bug 1157626 in qemu (Ubuntu) "Unable to use "virsh migrate" on two hosts after moving to raring" [High,Triaged] https://launchpad.net/bugs/1157626
<hallyn> I'm startign a set of regression tests, which should be done in an hour...  but i don't expect failures from that
<hallyn> that would replacethe (obviously now too late) FFE request for libvirt version 1.0.4 for raring
<smartboyhw_> Just asking: Is FinalFreeze on 21:00 UTC today?
<hallyn> yup
 * hallyn back in a bit
<stgraber> hallyn: maybe expand the changelog entry a bit, but if that's confirmed to work and not cause any regression, I'm happy to accept this into raring
<doko> Daviey, some weeks ago you did promise to look at the server related ones here ... http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<slangasek> doko: Daviey is at ODS this week, so you probably won't get much of a response
<doko> ahh, ok
<hallyn> stgraber: http://people.canonical.com/~serge/libvirt-migrate-v2.debdiff    all tests passed
<stgraber> hallyn: cool, go ahead with the upload
<hallyn> stgraber: great, thanks
<hallyn> pushed
<infinity> hallyn: Ahh, thanks for that cherrypick.  A 5-line diff seems slightly less scary than a 12MB one. :)
 * infinity raises his brow at queuebot.
<ogra_> oh, cool, we have netboot touch images !
<rsalveti> yeah \o/
<ogra_> infinity, that was sergiusens adding the touch image testcases ... seems the netboot shouldnt really be there
<sergiusens> infinity: that was balloons creating a tag for us to test the Ubuntu Touch builds
<sergiusens> on isotracker
<balloons> I don't know who added netboot
<balloons> that was random..
 * ogra_ shakes his fist at Mr. random 
<ogra_> evil guy you !
<ogra_> :)
<ogra_> stgraber, ^^^ can you probaby filter that from queuebot ?
<ogra_> (i guess all touch images , not only netnboot)
 * balloons took care of netboot and mr. random (he hopes)
<ogra_> :)
<stgraber> balloons: netboot is autoadded by my script, I need to make it aware of touch images ;)
<ogra_> better make it unaware ... i doubt to want to spam release with it yet
<balloons> stgraber, I figured as much :-)
<stgraber> ogra_: well, it's two things. I had to make my d-i monitoring script unaware of Touch so that it doesn't automatically add Netboot images to that milestone, then patch queuebot to stop spamming #ubuntu-release with the touch stuff
<ogra_> stgraber, yeah
<infinity> stgraber: Want to poke at that kmod?  It's just swapping our patches for upstream's.
<infinity> (And taking back TILM, so I don't misplace it later... *cough*)
<stgraber> infinity: sure, taking a look now
<infinity> It probably instills very little confidence that I'm always pleasantly surprised when one of my glibc upgrades goes smoothly, doesn't it?
<stgraber> infinity: are you sure we're not using that nfs4/nfs alias?
<infinity> stgraber: We're not using that alias file at all, so no. :P
<infinity> (Not using is it part of our delta elsewhere in debian/rules)
<stgraber> infinity: good ;)
<infinity> s/is it/it is/
<infinity> We probably should look at that at some point, but my kmod packaging goal in R was to make it look as close to identical to our m-i-t packaging as possible.
<stgraber> infinity: and you didn't feel like listing our delta in the changelog of the merge? (would have saved you the question) :)
<infinity> For S, I may revisit our delta with Debian (and Debian's with upstream) and see what we're intentionally missing that might be of value.
<infinity> (Like the 1700 foo.d directories littered all over the FHS namespace)
<infinity> stgraber: I have a severe distaste for reiterating "merged; remaining changes:" on every 5-line-change upload.
<infinity> stgraber: I do it at what feels like natural reset points (like new upstream versions, or whatever... Basically, when all the patches get mangled and the delta needs reviewing)
<infinity> Hrm, freeze in 1:19.
<infinity> Here's hoping everyone's happy with their packages.
<stgraber> I still have a last minute lxc upload to do, waiting for a quick review by barry though
<balloons> stgraber, ty. just make sure the builds are still being pushed for touch :-)
<barry> stgraber: ha! i just sent the ack
<infinity> I still have a last-minute d-i upload to do, I need to get to mangling that. :/
<barry> bdmurray: needs to upload ubuntu-release-upgrader
<bdmurray> speaking of that could someone have a look at bug 457221?  I was just gonna remove cups-pdf from ForcedObsoletes
<ubot2> Launchpad bug 457221 in ubuntu-release-upgrader (Ubuntu) "cups-pdf always classed as OBSOLETE and removed during update-manager process." [Medium,Triaged] https://launchpad.net/bugs/457221
<bdmurray> although its not that important
<bdmurray> stgraber, infinity: ^
<infinity> bdmurray: Huh.  ForcedObsolete seems a bit heavyhanded if it was just unseeded.  I wonder what the rationale was.
<infinity> If it works and doesn't horribly conflict with other things and is still in the archive (the latter is at least true), that seems silly.
<bdmurray> maybe there was some thing else wrong with it?
<infinity> Well, if it's fundamentally asplodey broken, it shouldn't be in the archive, IMO.
<bdmurray> Right, I meant the Intrepid version of it.
<infinity> But it looks like it was just removed from desktop seeds, and someone decided that meant no one should ever have it installed EVAR.
<infinity> (Which is silly, since the upgrader already does the "here's a list of stuff no longer supported" check)
<infinity> bdmurray: Anyhow, ACK on fixing that in your next release-upgrader upload.
<stgraber> so if someone is actually reading through the lengthy python patch in lxc, it's a cherry-pick of the following upstream commits:
<stgraber> https://github.com/lxc/lxc/commit/33892746e373449a8a69a4265d783bf701cb5784
<stgraber> https://github.com/lxc/lxc/commit/e649c8032f84b488cac8ea6c8fb9a77c424a0419
<stgraber> https://github.com/lxc/lxc/commit/2ebec36f271d4ee943281e32feb3552745115347
<stgraber> https://github.com/lxc/lxc/commit/6c5db2af1f706e8f21f2a5f074bada96e9011052
<phillw> stgraber: I'll have to have a read up on lxc, I'm very interested in learning it! FYI, on https://help.ubuntu.com/community/LXC the 2nd link gives a 404 error.
<balloons> you can edit to just http://lxc.sourceforge.net/
<phillw> balloons: as it seems stgraber knows about lxc and has made the 3 most recent edits. I use my 'do not edit stuff on wiki's you do not understand' clause :)
<stgraber> infinity: any chance you can review lxc?
<infinity> stgraber: Too bad, we're frozen.
<infinity> stgraber: (Yeah, I'll look in a second)
<stgraber> hehe, we may have sucky audit trail on that stuff, but we at least have a timestamp ;)
<stgraber> (thanks)
<stgraber> I'm looking at the nexus7 kernel
<stgraber> *nexus4
<stgraber> hmm, I wonder why rtg removed all the content of an old UNRELEASED changelog entry but not the entry itself...
#ubuntu-release 2013-04-19
<sarnold> hello; I'm preparing mysql-5.5 updates. it is my assumption I should prepare the mysql-5.5 for raring in the -security pocket for later release, but I'd like to confirm first that the release team wouldn't rather have it prepared for plain 'raring' for late inclusion.
<sarnold> (note that my packages aren't done yet; it's still a hypothetical question at this moment :)
<jdstrand> sarnold: let's plan on building in our ppa with raring-security. if the release team says its ok and its worth it, I can copy them to raring-proposed
<jdstrand> sarnold: but since they aren't done yet and will need to be tested, this sorta seems like the upload would happen on monday, which is probably too late now that I think about it
<sarnold> jdstrand: it does rather push the definition of 'freeze' :)
<jdstrand> heh, well, maybe you'll have it ready before then, so I'll let you take it from here (but like I said, I can push to -proposed from the ppa)
<ScottK> sarnold: jdstrand's suggestion is good.  If it's ready and we have to respin for other reasons, then it can be copied in.
<sarnold> thanks ScottK :)
<phillw> ScottK: are the builds planned on the cron the RC's ?
<ScottK> We haven't stopped the automatic builds yet, I don't think, plus I think there's a final language pack export to do, so not quite yet I don't think.
<ScottK> They are worth testing though so any issues can be identified early.
<phillw> ScottK: people do test the dailies, but I do not want to call testers in until RC is ready; I'd rather a delay of 24 hours than the situation of "let's respin the world" :)
<ScottK> phillw: I guarantee you there will be respins even after you call for testers.
<phillw> ScottK: there always is :D
<ScottK> Right, so as long as you say these aren't expected to be final, but close, I think a call for testing wouldn't be a bad idea.
<phillw> ScottK: so can I re-phrase that, as my grammer on phasing sentances has been mis understood before (dev-chromium build is one such). when the cron builds tomorrow, will -release team freeze and call them as RC as per http://iso.qa.ubuntu.com/qatracker ?
<ScottK> I don't think we've discussed exactly when that is.
 * ScottK looks over at infinity.
<phillw> 21:00 UTC today.. :)
<phillw> but, it's never happened in previous times :D
<ScottK> That was the freeze for seeded packages.
<ScottK> It's not the time when image building is automatically a candidate.
<ScottK> As I mentioned, that's probably a final language pack export to do over the weekend.
<phillw> ScottK: okies, so when should we have an RC to test? language pack excepted,
<ScottK> It depends on what you mean by that.
<ScottK> Up until we stop the cron jobs, it's hard to tell.
<ScottK> We aren't going to let seeded package changes in now except for important fixes, so the next build will be close.
<phillw> ScottK: okies, the when does -release team expect to alter http://iso.qa.ubuntu.com/qatracker and put on the RC?
<ScottK> I don't know.
<ScottK> Except there isn't a release candidate milestone.  It'll be release.
<phillw> ScottK: so, there is no RC?
<ScottK> phillw: It's a candidate until you decide to release it or respin.
<phillw> that should be fun to try and test :D
<ScottK> It's exactly the way it's been for a couple of years.
<ScottK> What we now call beta2, used to be called release candidate, but we changed it because it wasn't a release candidate.
<ScottK> No, "release candidate" means exactly what it says.  It's a candidate to be the thing we release.
<phillw> ScottK: no, it is not. RC gets put out... it is usually respun a few times, but people are not working on daily.
<ScottK> Yes.  A release candidate gets put out and it's either tested good or respun to fix issues.
<ScottK> But the milestone is called release
<phillw> so, beta2 is now the RC and so any work done on the dailies is useless?
<ScottK> No
<ScottK> Other way around.
<phillw> then, when is the RC released?
<ScottK> When we release 13.04.
<phillw> ScottK: oh, did they edit https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule without editing it>
<phillw> ?
<ScottK> No.
<ScottK> You're confused about what release candidate means on the schedule.
<phillw> ScottK: no, I am not. you guys may be. At what point do you want the maximum amount of testers to land on the RC?
<ScottK> Since I'm the one that came up with the current definitions, I'm reasonably certain I understand what I meant.
<phillw> ScottK: the rolling release has been dropped, we are back to standard release
<ScottK> yes.  We've used what I'm describing for years.
<phillw> ScottK: https://wiki.ubuntu.com/ReleaseCandidate
<ScottK> Testing soon is good.  There should be an increasing effort over the weekend and then full court press on Monday/Tuesday.
<phillw> do read what you wrote>
<phillw> I think you will find that was written by Kate.
<ScottK> Yes.
<ScottK> So?
<phillw> So, there is an RC
<phillw> when?
<ScottK> I give.  You're ignoring what I'm saying and I'm not going to start repeating myself.
<phillw> ScottK: okies, let me do the maths backwards?... Release is on 25th of this month? correct?
<ScottK> Yes
<ScottK> http://www.youtube.com/watch?v=sShMA85pv8M
<phillw> ScottK: RC is 7 days before.. https://wiki.ubuntu.com/ReleaseCandidate
<ScottK> RC is a milestone in the release process.
<ScottK> It's not an image we release.
<phillw> https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
<phillw> erm, who edits that page?
<ScottK> The release team generally.
<phillw> I know for a fact, I cannot
<ScottK> You shouldn't.
<phillw> then, that is the page which says what the time table is?
<phillw> ScottK: I would never dream of doing so.
<ScottK> Yes.  That's the page.
<phillw> So, what does it say?
<phillw> i do not require to watch you-tube. That is the reference page for every one.
<ScottK> It says we freeze the archive and start working on release candidates today.
<phillw> indeed it does. but you also said that there will be no RC on the iso tracker. I find your answers to be in contadiction and also against the 'rule' that we all know gets broken, which is to give the testers 7 days to crawl all over the RC.
<phillw> ScottK: the freeze was 21:00 UTC, we all know that it never 'actually' happens.
<ScottK> Of course it does.
<ScottK> I just don't think freeze means what you think it means.
<ScottK> It doesn't literally mean no more uploads.
<phillw> I'm all ears :) By the way, ScottK I'm not giving you a hard time.... I just want to learn this stuff :)
<ScottK> It seems like every release you whine about the release team doing last minute respins as if we're just trying to make life difficult for testers.
<ScottK> We aren't.
<ScottK> After this point we try to constrain updates to seeded packages to those that are really needed for release.
<phillw> ScottK: yes, I do. do I have permission to speak freely?
<ScottK> Certainly, but you're expectations are not reasonable.
<ScottK> Personally, I'm tired of non-constructive criticism.
<phillw> ScottK: my expectations are that the release team do not treat testers like mushrooms. things have changed; there is no longer the etherpad for people to look out for up coming re-spins for various bugs. We now are reliant on someone being able to / be bothered to put a note up on the http://iso.qa.ubuntu.com/qatracker
<ScottK> I don't recall a respin that wasn't discussed here.
<ScottK> It's not a closed channel.
 * hyperair wonders what mushrooms are treated like.
<ScottK> the Etherpad was a lot of work for little value.
<phillw> ScottK: it may come as a shock, but a lot of testers are not logged on here. It is a case of communicating things. In that respect, I can see why ether-pad was not too good, but instead of just dropping it for the discussions, why was it not linked to to "notice" on the iso tracker?
<ScottK> There's nothing stopping someone who is here from communicating with testers that aren't.
<phillw> We are going to respin xyz, we may respin abc if we get the chance.
<ScottK> I can't speak to the mechanics of the ISO tracker and respins since I don't work for Canonical, I don't have access.
<phillw> ScottK: you are a tester, I know. just how annoyed would you be if you had spent ~3 hours on various test cases and file them, for them to removed because of a planned re-spin?
<ScottK> Sure.  I get it.
<ScottK> Someone who wants to figure out how to improve communication should do it.
<ScottK> The release team should spoon feed the testers is not a solution.
<phillw> ScottK: well, we did have the ether pad, where the release team talked and we could watch. That has been removed. I'm quite sure that the release team still talk, just that the testers have no idea what they are talking about :(
<ScottK> I don't understand why following an IRC channel is harder the reading the pad?
<phillw> ScottK: not all testers can read everything going on in an IRC area. I certainly will be off-line for most of sunday coming, so cannot even look at IRC logs. On an ether pad, it was always there. As to 'Notice Board' on the iso tracker? Well, I have asked that some one do actually post on there a decision taken on here.
<phillw> hyperair: as you will well know... mushrooms are kept in the dark and fed on bull shit.... :P
<hyperair> phillw: oh.
<hyperair> phillw: i was thinking more along the lines of... eating mushrooms.
 * hyperair eats testers for breakfast.
<phillw> ScottK: It's late here (nearly 4 am). After the gales last night, me and my dad have been chain-sawing down the trees that blew down from our neighbour to remove further risk..... Which is my way of saying I'm sleepy.
<ScottK> I can imagine.
<phillw> ScottK: during 13.04 test cycle we have all learned a lot and the testing suite come 13.04 --> 13.10 --> 14.04LTS has made massive strides. Let us not forget the guys and girls who actually take the time out to 'test'. :)
<ScottK> I don't.
<phillw> ScottK: we may argue like cat and dog. But everyone on this channel actually cares; that is the most important thing :)
<infinity> phillw: ReleaseCandidate page on the wiki edited to clear up the confusion and document reality rather than fantasy.
<Noskcaj10> half the builds on the iso tracker are for the 19th, half for the 18th. shouldn't they all be up to the 19th now?
<stgraber> no
<Noskcaj10> ok
<cjwatson> The builds run throughout the day; look at etc/crontab in lp:ubuntu-cdimage if you want the full schedule
<Noskcaj10> ok, ty.
<cjwatson> I might redo this next cycle to be a bit simpler, since we don't have the same builds-must-not-overlap problems we used to, and it ties in with giving the ISO tracker more control over things
<cjwatson> ... oh well
<cjwatson> 09:32 <cjwatson> I might redo this next cycle to be a bit simpler, since we don't have the same builds-must-not-overlap problems we used to, and it ties in with giving the ISO tracker more control over things
<infinity> Comment: NBS
<infinity> 307 packages successfully removed.
<infinity> ^-- That might be the most I've done in one run.
<cjwatson> mm, quite a few flavours there
<smartboyhw> Hello Release Team, when will be the first RC images be produced? (Just asking)
<stgraber> I don't think we have an answer to that at this time. Currently waiting on langpacks
<smartboyhw> Thank you stgraber;)
<pitti> hello
<pitti> FTR, the network-manager upload in unapproved only adds some new autopkgtests, it doesn't change anything that actually gets built or installed
<pitti> (and I verified it with a local VM)
<pitti> so that should be safe
<jdstrand> fyi, the telepathy-mission-control-5 has an apparmor profile only change which only allows more access for libproxy. I verified it locally
<jdstrand> (telepathy-mission-control-5 in unapproved that is)
<plars> Do we know when we'll have a release candidate for testing on the iso tracker?
<phillw> plars: (11:48:31) stgr@ber: I don't think we have an answer to that at this time. Currently waiting on langpacks
<rtg> infinity, re: linux-lts-raring and linux-meta-lts-raring. would you like me to upload them directly to Precise, or would you rather copy them from a PPA (ppa:ubuntu-x-swat/r-lts-backport) ?
<balloons> cjwatson can you add the magic to nusakan to ensure the ubuntu touch builds update automatically?
<cjwatson> balloons: could you be more specific?
<cjwatson> which builds where?
<plars> phillw: thanks, missed that
<balloons> cjwatson, sure the
<balloons> cjwatson, the 'ubuntu touch' family of products; Ubuntu Touch Preinstalled grouper, Ubuntu Touch Preinstalled maguro, Ubuntu Touch Preinstalled mako, Ubuntu Touch Preinstalled manta
<cjwatson> balloons: You mean on iso.qa.ubuntu.com?
<balloons> cjwatson, yes, I want new builds to be pushed to the isotracker as new builds are created on cdimage
<cjwatson> I'll see what I can do
<balloons> ty :-)
<cjwatson> balloons: we only need this for raring, right?
<cjwatson> or $current_development_series I mean
<cjwatson> (having both quantal and raring in the same directory is non-standard for cdimage; it would be easier if I only had to deal with raring)
<balloons> cjwatson, yes, current development only :-)
<cjwatson> ogra_: Could you apply http://paste.ubuntu.com/5721754/ to your sync-phablet-images script, please?  (Patched version in /home/cjwatson/sync-phablet-images if you want to diff against that directly)
<cjwatson> ogra_: I'll try the post-qa commands manually
<cjwatson> ... seems to work
<ogra_> cjwatson, no prob ... given we will likely keep the jenkins builds around for a bit i'll push it to a proper bzr tree too
<ogra_> i didnt expect it to last so long :) ... and also didnt expect the sript to gow bigger than 10 lines when i started it
<ogra_> *script
<cjwatson> I don't want any shell scripts in lp:ubuntu-cdimage though
<cjwatson> So if it's going in there it'll need a rewrite in Python
<ogra_> no, in its own branch indeed
<cjwatson> OK
<ogra_> it shouldnt go in there ... it shjould go away :)
<ogra_> but as long as we keep jenkins bulds it cant
<cjwatson> Yep
<bdmurray> I'd like to upload ubuntu-release-upgrader fixing bug 1069745 and it also includes a new base-installer with the highbank / generic change
<ubot2> Launchpad bug 1069745 in ubuntu-release-upgrader (Ubuntu) "update-manager fatal error while upgrading from precise to quantal due to Ubuntu.mirrors not being available" [High,In progress] https://launchpad.net/bugs/1069745
<stgraber> bdmurray: can't hurt uploading. Do we need this on the release media?
<bdmurray> stgraber: no, well except maybe for derivatives that still have an alternate cd
<cjwatson> I was expecting to have another run of images anyway ...
<stgraber> cjwatson: I'll review ubuntu-release-upgrader now and let it in if it looks good. I'm also planning to do the same for maas unless roaksoax shows some doubts wrt its quality
<cjwatson> ack
<stgraber> I'm also tempted to accept juju as the changes have already been acked as a FFe and it's unseeded but it'll need an AA to New the binary rename
<doko> infinity, once gnat-4.6 migrates, I'll give back the non-superseded builds in the test rebuild
<stgraber> above reject was me, I'm not too happy about the way they did the split/rename of the packages (if you were to install juju-0.7 without juju, you wouldn't get any command in the PATH)
<slangasek> stgraber: are you also following up with the uploader about getting a proper fix?
<stgraber> slangasek: yep, I emailed him
<xnox> cjwatson: any idea with respect to git-annex build-failures? I thought it would have just work after completed ghc transition.  Or should we remove armhf & powerpc binaries to transition git-annex?
<xnox> Laney: ^
<Laney> mmm, dunno, probably worth some investigation
<xnox> Laney: "Could not find module `Control.Exception.Extensible'" is really helpful =)
<xnox> considering it seems like that is part of base/stadard ghc.
<Laney> haskell-extensible-exceptions
<Laney> maybe?
 * Laney goes away for a bit. We can carry this on in #-motu later if you want.
<dobey> can someone approve the rhythmbox-ubuntuone into quantal-proposed and precise-proposed please?
<infinity> rtg: If they're coming from a PPA, it should be one that's meant to be used for archive builds (like the kernel PPA).
<cjwatson> xnox,Laney: I was in the middle of looking at that.  We shouldn't remove the binaries because it FTBFS on primary arches for exactly the same reason ...
<Laney> Alright, cool. I'll make some time to look at it over the weekend if necessary.
 * Laney goes out
<cjwatson> I'm running the obvious possibility through sbuild now
<stgraber> infinity: are you sufficiently awake to look at those fglrx packages?
<infinity> stgraber: Yeah, I'll poke them while I pack.
<rtg> infinity, then I'll just upload directly to the archive (in a bit)
<infinity> rtg: That works too.
<cjwatson> Laney: fails with http://paste.ubuntu.com/5722334/
<cjwatson> (after adding Build-Depends: libghc-extensible-exceptions-dev)
<infinity> rtg: Is the firmware in linux-lts-raring just a temporary measure while you SRU that into linux-firmware?
<rtg> infinity, nope, that is a permanent change
<infinity> rtg: If they're all new firmware files, why not just have them in linux-firmware, then?
<rtg> infinity, getting new files into linux-firmware has been a giant pain in the ass. besides, there are a number of firmware files that are kernel version specific, though they also typically have different file names.
<infinity> rtg: But if we ship firmware in the kernel images themselves, those need to be in kernel-versioned directories (to avoid file conflicts), and you end up with multiple copies.
<rtg> infinity, they are in /lib/firmware/$(uname -r)
<infinity> rtg: And yeah, I realise the SRU process is a bit annoying for completely new firmware files.  We can probably be a bit handwavy about that, since new files don't run the same risks as updating existing ones.
<rtg> infinity, did you see my note that these kernel firmware files _are_ in kernel versioned directories ?
<infinity> rtg: Yeah, I did.  Doesn't solve the fact that they then end up needlessly duplicated.
<rtg> infinity, there is no dupe for the LTS kernels 'cause those files don't exist in the precise linux-firmware package.
<infinity> rtg: There's duplication when you have multiple kernels installed.
<infinity> And, really, one could make these same arguments about anything we ship in linux-firmware, and I think we'd both agree that moving all the firmware into linux-image would be the wrong thing to do.
<infinity> So, doing it selectively still feels suboptimal.
<rtg> infinity, compared to the duplication of modules ? we're only talking about a couple of files here, and not all that big to begin with.
<infinity> Modules are tied to ABI, firmware isn't.
<rtg> infinity, look, I'm fine with adding those files to precise linux-firmware if I can get 'em SRU'd.
<infinity> rtg: You can.  Work with me personally on it, and we'll get 'em slipped in.
<infinity> rtg: Like I said, *new* firmware files probably shouldn't have the same rigorous SRU validation process, since it usually just comes down to "the file exists" or "the file doesn't exist", rather than testing for regressions.
<rtg> infinity, OK, I'll pull those firmware patches from LTS raring once an updated linux-firmware is in place.
<rtg> infinity, OK, I'll get started on that.
<infinity> Danke.
<bdmurray> there is a crash that is first seen with a version of gvfs in quantal -proposed but there isn't a great SRU bug for it as it is a new upstream release
<bdmurray> I'd usually just comment on the SRU bug but I'm not sure that's best in this case
<rtg> infinity, uploaded precise linux-firmware. I've verified that all are new files since release, except for one BT firmware file fix from an upstream cherry-pick.
 * bdmurray talks himself into commenting on the bug
<ScottK> bdmurray: That's what I was going to suggest.
<ScottK> bdmurray: You might even mark it verification failed.
<ogra_> uh, ah .. argh ...
<bdmurray> ScottK: I'm going to
<ogra_> cjwatson, right after i copied your script over mine i remebered why i didnt use $date
<Laney> haha, someone actually did sync that
<ScottK> Clearly RC.
 * ScottK didn't accept it, but totally would have.
<infinity> Laney: I wasn't going to release without it.
<Laney> infinity: Indeed. Seeds changed and ubuntu-meta uploaded. Get to promoting.
<infinity> Laney: Pfft, we don't need seed changes for me to make it Essential: yes.
<phillw> Hi folks, is http://pastebin.com/aV53pqEf okay to send to the testing teams?
<infinity> phillw: Pretty much everything from here forward (well, as of today's crons, anyway) could be considered RC material.
<infinity> phillw: I'm not sure there's any point in saying "RCs aren't ready yet".  Everything we're producing this week is an RC until we stop spinning and declare a winner.
<infinity> phillw: (And the langpacks are in, as of ~8h ago)
<phillw> infinity: it is just at each daily, the test results get set back to zero :)
<infinity> phillw: Yes, but the goal of testing is to find bugs and fix them, not to pat ourselves on the back for 100% test coverage.
<infinity> phillw: If people aren't testing RCs, we won't know if the blessed "final" image sucks.
<infinity> phillw: So, I'd rather you just encourage people to test early and often all week, rather than fret over "the RC", of which there is none.
<infinity> (Or there are many, depending on how you look at it)
<phillw> I agree, but it makes it more difficult to see which ISO's still need testing :)
<infinity> All of them.
<infinity> And lots.
<infinity> Even when something *has* 100% test coverage, it STILL needs testing.
<infinity> Because not all testers are created equal, and some do weird things to find new and fun bugs.
<infinity> So, really.  Just ask people to beat the crap out of the ISOs over the weekend and file bugs.
<phillw> infinity: ooh, don't I know about that!
<phillw> infinity: okies, I will do :)
<infinity> (This is, really, why I hate blessed milestone images and testing cadences... If more people just performed random abuse of images at random times we wouldn't, for instance, always be scrambling to fix installer bugs at the last minute)
<phillw> well, I cannot speak for other teams, but the lubuntu testers constantly test the living daylights out of images :D
<phillw> I'll send the email :)
 * infinity wonders how he lost his Oyster card...
<ScottK> Is that a Canadian thing?
<infinity> London.
<cjwatson> ogra_: $date> oh?
<ogra_> cjwatson, needs to be $date.$counter
<ogra_> fixed it already
<cjwatson> ogra_: ah yes.  I think that's still better than sed everywhere :)
<cjwatson> sorry for missing that
<ogra_> thanks for pointing me to it ... :)
<cjwatson> balloons: in case ogra_ didn't tell you or you didn't guess, that means that touch images should be posted to iso.qa automatically now
<ogra_> there is branches/phablet-sync/ in my home now
<ogra_> cjwatson, oh
<ogra_> cjwatson, /srv/cdimage.ubuntu.com/log/ubuntu-touch-preview/quantal/phablet-sync-20130419..log
<ogra_> ah, crap, i see whats wrong ... my fault, sorry for bothering you
<ScottK> I just accepted Block xserver-xorg-video-intel, but put a britney block in place for it.  It looks like a good, but not essential for release fix.  If there's no opportunity to copy it in, then it can be an SRU.
<utlemming> inifinity: I think, wtih Windows Azure now GA, we should a tracker item for it
<utlemming> infinity: how do we go about getting a Windows Azure item added?
<ScottK> utlemming: I'd talk to stgraber.  I think infinity is traveling.
 * utlemming feel like an idiot...
<utlemming> ScottK: right, I should be talking to stgraber
<utlemming> stgraber: around?
<cjwatson> ogra_: yeah, looks like $counter is empty ...
<ScottK> This is not the release team member you are looking for ....
<ogra_> yeah, the mechanism that checks if jenkins has a newer build was tricked
<ogra_> since the 19.4 image is actually what 18.1 was ... i had to roll back a few versions on request
<ogra_> so indeed the image will always be older now until they build a new one
<ogra_> i kind of didnt expect to have to do rollbacks when i wrote the stuff :)
<ogra_> (rollbacks with higher version number even)
<balloons> cjwatson, :-) ty!
#ubuntu-release 2013-04-20
<ScottK> The xserver-xorg-video-intel in proposed is verified to fix the problem is was uploaded for, so I'm going to unblock it.
<tjaalton> ScottK: thanks!
<ScottK> You're welcome.
<stgraber> utlemming: hi
<stgraber> utlemming: Can you give me a list of "products" to add to the tracker?
<Kalidarn> hey guys, found a regression with the latest kernel 3.8.0-19 the e1000e network driver doesn't work anymore
<Kalidarn> booting an older kernel 3.8.0-16 seems to make it work again
<shadeslayer> there used to be a factoid for regression
 * shadeslayer doesn't remember it off the top of his head
<shadeslayer> !regression
<ubot2> Factoid 'regression' not found
<shadeslayer> hmmm ... nope
<Kalidarn> weird thing is nothing in error logs
<Kalidarn> but basically when you run 3.8.0-19 network manager will say it is "unplugged"
<Kalidarn> tried removing the module and replacing it and bringing the interface up, then down and running dhclient on it, none of that works
<ogra_> cjwatson, do you have any access to the cron logs on nusakan ? somehow my sync script doesnt send mail anymore and i cant really see why (not urgent to happen this weekend or so, but i dotn really want to fill crons logs in the long term)
<Kalidarn> hmm
<Kalidarn> shadeslayer: it seems to be working now :S and i think it booted into 3.8.0-19 which is really odd
<shadeslayer> 0.o
<Kalidarn> i did see an intermittent bug marked as not a bug
<Kalidarn> on the redhat bugtracker
<Kalidarn> ill keep an eye on it though!
<cjwatson> ogra_: No more than you do
<ogra_> cjwatson, ah, well, thanks ... i just found that suddenly the gmail spamfilter i route my mails through considered all nusakan mail as spam ...
<ogra_> so it wasnt nusakan at all
<ogra_> (not that i wasted half a day on it :P )
<phillw> ogra_:  yeah, the spam filter can be a pain at times :)
<ogra_> well, i would just have switched it off if i had even tought about that possibility ...
<phillw> I do view my spam area from time to time, just to ensure it is not getting toooooo keen on things. robot emails are high on its' kill list :)
<ogra_> i never use the gmail UI ... its my emergency fallback if i have no access to a normal machine while traveling etc ...
<phillw> I have an 'educational' gmail account system. Having my cell/mobile phone send me the PIN number to it whilst I was in India on a training course was pretty cool! (I'd taken my list of the 10 time sign on once codes with me).
#ubuntu-release 2013-04-21
<Noskcaj> should we have lubuntu as a default in testdrive?
<ScottK> Probably a question for -testing
<Noskcaj> -testing doesn't exist, -quality gives me no response
<ScottK> !weekend
<ubot2> It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<ScottK> I guess.
<Noskcaj> true
<ScottK> It looks like the 13.04 beta 1 and beta 2 milestones are still active in LP.  Someone who can should fix that.
<ScottK> That ^^^ will fix the nuitka FTBFS, so if I'm not around, someone please retry it after rst2pdf is published.
<micahg> would the release team be up for dropping gcj-4.6 at this stage?  2 rdeps, 1 is a sync from experimental (pdftk, needs FFe), 1 is a no change rebuild (postgresql-pljava)
 * micahg would go for gcc-4.6, but it seems to need a bit of work
<infinity> micahg: I'd be all for it if doko is.
<infinity> ScottK: nuitka is still FTBFS.
<ScottK> Yeah.  I saw.  Traded one problem for another.
<ScottK> The rst2pdf fix was still correct.
<ScottK> Not sure what to do about this one.
<infinity> I'm going to give the unstable one a spin.
<infinity> My hotel network hijacks all port 25 traffic.
<infinity> That's a bit creepy.
<infinity> At least, that's how I'd interpret the middle hop here: http://paste.ubuntu.com/5726823/
<ScottK> Common for hotels.
<ScottK> Submit on port 587.
<infinity> I guess I just never pay attention to headers.
<infinity> And yeah, I should switch my laptop to hitting 587 on my server.
 * ScottK tries that sleeping thing again ...
<infinity> Good luck.
<infinity> Bah, new upstream nuitka fails differently again.
<infinity> ScottK: I have a fix for nuitka (or, for the last FTBFS I ran into, still finishing the testsuite).
<infinity> This is one impressively long testsuite...
<phillw> has the iso tracker died? ( http://iso.qa.ubuntu.com/qatracker/milestones/243/builds )
<phillw> it's back :)
<ScottK> infinity: Cool.
<stgraber> infinity: I created the final milestone on the tracker. Whenever you switch off the dailies on nusakan, just go in the web UI and mark the milestone as "Automatically publish builds listed in the series manifest" (or ping me)
<stgraber> yofel: ping
<yofel> stgraber: pong
<stgraber> yofel: I'm looking at choqok in Unapproved. The changelog says its just a change in orig tarball to fix translations and I indeed see a lot of that in the diff, however I also see two plugins being removed without explanation
<stgraber> betternotify and translator
<yofel> ok, what happened:
<yofel> while I was looking at the translation issue, I noticed that the 1.3 orig tarball that we merged from debian has nothing to do with the choqok-1.3.tar.bz2 released by upstream.
<yofel> what debian used instead seems to be some git snapshot from 2 months after release
<yofel> that has no translations
<yofel> I haven't yet managed to reach the debian maintainer to ask why he did that
<yofel> so I went and uploaded the *official* tarball to get this reviewed by Scott (or you now) to clear up what the most sensible way to go is
<yofel> at least the betternotify was intentionally not included in the 1.3 release by upstream looking at the git log
<yofel> I have yet to look at what happened to translator
<stgraber> I went through the whole diff by hand and those two missing plugins are the only thing I noticed that aren't covered in the changelog. So it'd be good to know what kind of impact they'll have so we can decide to either re-introduce them to avoid last minute feature changes, get an FFe or just ignore them as they have no actual impact.
<yofel> ok, feel free to reject it then. I'll re-upload once I find out what happened to the other plugin
<stgraber> yofel: ok. I'll do that then. Make sure to mention your findings in the changelog of your next upload.
<yofel> will do, thanks for reviewing
<doko_> Laney, git-annex ftbfs on powerpc
#ubuntu-release 2014-04-14
<Thedemon007> Hello can update xserver-xorg-video-openchrome-lts-saucy ?? in saucy release new versiÃ³n see bug #1205643
<ubot2> Launchpad bug 1205643 in xserver-xorg-video-openchrome-lts-saucy (Ubuntu) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy & 12.04.4 candidate" [Undecided,Confirmed] https://launchpad.net/bugs/1205643
<maclin_> slangasek, thanks. The restart function of ubuntu kylin software center will be updated as your suggestion in next version after release:)
<Thedemon007> Ok i add a debdiff for update the package xserver-xorg-video-openchrome-lts-saucy in the bug #1205643  I think it will help.
<ubot2> Launchpad bug 1205643 in xserver-xorg-video-openchrome-lts-saucy (Ubuntu) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy & 12.04.4 candidate" [Undecided,Confirmed] https://launchpad.net/bugs/1205643
<Thedemon007> I guessed before that this is automatically updated to be updated package saucy. But apparently not the case :S
<infinity> ^-- Self-accepted that d-i, it's a no-change rebuild that I want done while I eat breakfast. :P
<RAOF> infinity: Hm. We were going to talk about AA training sometime...
<infinity> RAOF: Release week is probably not the best training week.
<RAOF> infinity: I was thinking that, yes.
<RAOF> Just a reminder to myself and you so that I don't forget entirely :)
<tjaalton> I have two commits to enable broadwell on mesa http://pastebin.com/TxMH72c9
<tjaalton> been running fine over the weekend, as emailed on ubuntu-release@ a minute ago
<tjaalton> ok to upload?
<infinity> tjaalton: Looks fine, upload quick.  I intend to get to spinning RCs when I get into the office.
<infinity> (Or, I guess, once that mesa migrates. :P
<infinity> )
<tjaalton> cool, thx
<tjaalton> there
<infinity> Thanks for the 1.6MB diff, LP...
<infinity> crontab gone manual, precise disabled too so it doens't get in our way.
<infinity> stgraber: Still awake, by any chance?
<infinity> stgraber: Hey you.  Fix lxc-unpriv-cgroup.conf on https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ to not break people's computers.  kthx.
<wgrant> (cgroup-lite was removed in yesterday's dist-upgrade, so that job prevented systemd-logind from starting, so everything was pretty bborked)
<jibel> Riddell, there are 2 serious installer issues in kubuntu: bug 1298251
<ubot2> Launchpad bug 1298251 in ubiquity (Ubuntu Trusty) "[kubuntu] Ubiquity crash when starting LiveCD with a chosen language" [High,Confirmed] https://launchpad.net/bugs/1298251
<jibel> and bug 1307291
<ubot2> Launchpad bug 1307291 in ubiquity (Ubuntu) "[kubuntu] crash when partitioning" [Undecided,New] https://launchpad.net/bugs/1307291
<jibel> Riddell, can you or someone from the kubuntu team have a look?
<jibel> Riddell, and not a crash but not nice bug 1299881
<ubot2> Launchpad bug 1299881 in ubiquity (Ubuntu) "[kubuntu] Strange characters in different locale" [Undecided,Confirmed] https://launchpad.net/bugs/1299881
<Riddell> jibel: thanks yeah I'll take a look
<jibel> cjwatson, bug 1306704 is another crash in parted_server easy to reproduce with a FAT32 FS
<ubot2> Launchpad bug 1306704 in parted (Ubuntu Trusty) "parted_server crashed with SIGABRT in ped_assert()" [Critical,Confirmed] https://launchpad.net/bugs/1306704
<cjwatson> Yes, I saw the mail, thanks
<cjwatson> Might need psusi's help though
<jamespage> please could the new rc's for swift and glance be reviewed/accepted for trusty (maybe Daviey if he's around?)
<jamespage> urgh - in actual fact please can the swift upload be rejected - the breaks/replaces for swift-object-expirer are still not right
<infinity> jamespage: Done.
<jamespage> infinity, thanks
<jamespage> uploading a new version now
<seb128> infinity, Laney, other: is there still room for an unity upload today?
<infinity> seb128: Depends on what it fixes and how.
<seb128> infinity, https://code.launchpad.net/~beidl/unity/unity-lockscreen-gestures/+merge/215569
<seb128> infinity, basically the new lockscreen let you trigger an "alt-tab" which shows preview of open programs, using gestures
<infinity> Ahh, I think wgrant saw that earlier.
<infinity> seb128: If that's well-tested, I think we definitely want that fix.
<seb128> infinity, I'm working on the review/testing part, I though it would still be worth letting you guys about it as well
<seb128> +know
<infinity> seb128: *nod*... That would end up having to be a 0-day security update if we didn't get it in the release pocket, IMO, so if it's sanely tested to both fix the bug and not regress, let's do it.
<seb128> k
<seb128> infinity, thanks
<infinity> seb128: So, wgrant also managed to invoke the dash via a gesture yesterday.  Does this fix that too?
<infinity> (We're not entirely sure *how* he did that)
<seb128> infinity, yes, that desactivate all gestures
<seb128> infinity, dash is "tap with 4 fingers" iirc
<infinity> Excellent.
<wgrant> I have a photo, but I cannot reproduce it the dash thing no matter how hard I try.
<seb128> wgrant, if you have a multitouch pad/screen tap with 4 fingers?
<wgrant> seb128: A double tap invokes the switcher, but I haven't managed to invoke the dash except when I was cleaning my screen yesterday
<wgrant> But I guess disabling all gestures will fix that :)
<seb128> wgrant, did you try to put 4 fingers at the same time on the screen?
<seb128> wgrant, https://wiki.ubuntu.com/Multitouch#Supported_Gestures
<wgrant> seb128: It works as expected when unlocked (four finger tap == dash, four finger double tap == app switcher). The second one always works on the lockscreen, but the first one I've only managed to do once, and only accidentally.
<seb128> k
<seb128> well anyway, let's land that fix and see if there are still issues remaining
<seb128> it's a step in the right direction in any case ;-)
<wgrant> Hm
<wgrant> I think I just invoked the dash under the lockscreen, but it at least wasn't visible.
<infinity> seb128: Is the fix for this only in unity?  (just checking seeds to see what I need to hold off respinning)
<seb128> infinity, yes
<infinity> Certainly looks like it from the diff.
<infinity> Kay.
<infinity> So, I'll respin the world minus kylin/edubuntu/ubuntu soon.
<infinity> And then those three after you land your unity.
<cjwatson> Whatever the parted thing above is is probably going to be a respin-world.
<infinity> cjwatson: Whee!
<infinity> cjwatson: This means I still have time for a last-minute "support ccTLD.ports" attempt, right? :P
<infinity> (Yes, we completely forgot to get to that... *sigh*)
<cjwatson> That's complicated ...
<infinity> Yeah, I know.  I think we should line it up for dot-1.
<infinity> Just a shame we kinda didn't get to it for release.
<cjwatson> .1 would allow more testing time, yeah ...
<cjwatson> infinity: OK, I think I can squeeze in this parted fix for you as well
<cjwatson> It's basically http://paste.ubuntu.com/7249046/
<cjwatson> Preparing an upload to unstable, but I think I'll do a separate upload to trusty rather than waiting for it to be syncable
<cjwatson> Turned out to be easily reproducible by just running "print 1" since I'm on a UEFI system and /dev/sda1 is an EFI System Partition (i.e. FAT).
<cjwatson> In parted that is.
<infinity> cjwatson: Awesome.  Thanks.
<cjwatson> infinity: ^- OK, parted and openssh should both go into a respin, I think.
<infinity> cjwatson: Kay.  I have a mono I'm about upload, if you'd like to "review" it with some serious airquotes.
<cjwatson> OK.  Need to go for lunch RSN though
<infinity> cjwatson: In the queue now.
<cjwatson> xorg-server probably wants a look from somebody ...
<infinity> cjwatson: Man, that's a noisy diff. :/
<infinity> (ssh)
<cjwatson> Yeah, sorry, Matthew had done a previous git-dpm thing with a different git version, apparently
<infinity> cjwatson: The reformatting of diffstat is weird.
<cjwatson> Right, different git version
<cjwatson> Matthew doesn't touch openssh often so it shouldn't happen much :)
<cjwatson> infinity: so, uh, yeah, "review" as you say
<cjwatson> infinity: have we done any testing of this on other architectures, and if so which ones?  It's a bit hard to see what it might affect
<cjwatson> Actually I guess it's obviously just powerpc isn't it
<cjwatson> But do we know it still works there?
<infinity> cjwatson: Oh, I didn't test ppc32, let me quickly spin that up.
<cjwatson> Yeah, looking at this I think that'd be a good idea.
<cjwatson> But if it works there we're probably good.
<infinity> cjwatson: Well, it'll "work", the key is no test regressions. :P
<infinity> (Because mono ignores his testsuite)
<cjwatson> Yes, I meant work not build :P
<jibel> infinity, I'm disabling trusty daily from the tracker.
<infinity> jibel: go nuts.
<seb128> can we get unity-settings-daemon in as well if we respin for the other stuff recently approved?
<qengho> Hi all. I have a new chromium-browser release that I would like in 14.04 in addition to my security updates to past releases. It fixes several CVEs.  I have it in my security-release staging PPA, https://launchpad.net/~canonical-chromium-builds/+archive/stage  .  What are the chances I can get it into 14.04?
<qengho> It's in universe, btw.
<infinity> qengho: How tested is it?
<infinity> qengho: It's in mythbuntu and ubuntukylin, so being in universe doesn't mean much.  We still need to make sure it's not going to regress anything last-minute.
<knome> hey, we need an ACK for bug 1307485
<ubot2> Launchpad bug 1307485 in network-manager-applet (Ubuntu) "Drop gnome-bluetooth to suggests (regression)" [Low,Triaged] https://launchpad.net/bugs/1307485
<knome> ubuntu studio has acked it's ok as well, but for completeness, i'm asking them to ack on the bug as well (but don't know when they'll get it)
<knome> *get to it
<knome> xub, studio, and myth are the three that are affected
<stgraber> infinity: I'll just remove it from the blog post, it was a temporary thing until we had cgmanager, which we now do
<infinity> knome: I thought we should JFDI, IMO.
<infinity> knome: When did this regress, do you know?
<knome> infinity, no idea... but we bumped into it when we tried to remove ibus from our seed and noticed it wasn't removed...
<knome> cyphermox has been on it, but if you have the time/motivation, feel free to do the change and upload
<infinity> cyphermox should be around shortly, I'll let him do it if he's on the case.
<knome> cheers
<knome> and that should be the last thing we need from the release team unless we magically find a solution to another bug
<knome> thanks!
<infinity> What's the "other bug" on your radar?
<knome> bug 1259339
<ubot2> Launchpad bug 1259339 in xfce4-power-manager "Xfce4 Power Manager does not restore screen power" [Medium,Confirmed] https://launchpad.net/bugs/1259339
<knome> it's not even triaged yet, which is why it looks unrealistic to come up with a fix...
<infinity> knome: Oh, hardly a new bug.
<knome> yep, that too
<infinity> knome: So, not release critical, though would be great to see an SRU to both 12.04 and 14.04 when you figure it out.
<knome> absolutely
<knome> other than that, we have had all of our 14.04-targeted bugs fixed \o/
<knome> https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-t-bugs
<infinity> knome: You either didn't have enough bugs, or you guys are machines.
<infinity> knome: Either way, congrats.
<cjwatson> infinity: Ah, did mono/powerpc break?
<infinity> cjwatson: Spectacularly.
<cjwatson> Ah yes, I see ...
<cjwatson> Glad I asked :)
<knome> we did have bugs, and we still have... but yeah, using a whip on the developers help on getting thinngs done O:)
<infinity> cjwatson: Might just need a bit more ifdeffery, but don't really have the time to look right now.
<stgraber> infinity: so I'm looking at the tracker config. Whoever set it up made a tiny mistake. The daily milestone must stay active until after release.
<cjwatson> didrocks: https://bugs.launchpad.net/ubuntu/+source/colord-gtk/+bug/1282372 - colord-gtk is currently on the list to move (back) to universe.  Did the reverse-dependency in question never happen, or get reverted, or something?
<ubot2> Launchpad bug 1282372 in colord-gtk (Ubuntu) "[MIR] colord-gtk" [Undecided,Fix released]
<stgraber> infinity: everything must be done against Trusty Daily and things will just get picked up by Trusty Final if it's on the manifest
<infinity> stgraber: jibel disabled it.  Go ahead and reenable.
<seb128> cjwatson, didrocks: the new panel codebase ended up having other issues and we decided to delay the update to next cycle
<seb128> cjwatson, didrocks: it can be demoted
<jibel> stgraber, sorry.
<didrocks> seb128: hum, so the "we'll seed it soon" was forgot to mention it needs demotion I guess
<didrocks> ok, demoting now
<cjwatson> thanks
<didrocks> (and reopening the bug)
<cjwatson> It can sit as Fix Committed or whatever, I guess.
<stgraber> jibel: np, it's not entirely obvious :)
<didrocks> yep
<seb128> didrocks, sorry about that, miscommunication with robert_ancell I guess (those happen with the little of tz overlap we get)
<seb128> didrocks, cjwatson: thanks
<didrocks> no worry!
<cjwatson> not a problem, indeed, just trying to clean up the last bits of archive cruft
<infinity> slangasek: Have you given up on the hope of understanding the icedtea-web business?
<infinity> qengho: ?
<stgraber> just uploaded a last minute LTSP, community members reported (on IRC...) a bunch of problems when booting with some realtek cards that take a while to initialize...
<stgraber> this cherry-pick all the current pending commits upstream which makes LTSP in 14.04 match with that distributed by some of the other upstream people in their PPA (and is used in hundred of schools at the moment)
<stgraber> (pending as in, commited a while back but never released as vagrantc has been busy with other things lately)
<Laney> libreoffice/autopkgtest is not having a good time
<Laney> I'll skip it to get mesa in
<qengho> infinity: sorry, have returned. I've had several testers. There's one regression I know of, in that the new internal toolkit that all of chromium is switching to in this version or next does not support the API that Flash players (et c) use. It dies now or in a few weeks, either way.
<qengho> stgraber: you tried my proposed chromium, yes?  Any complaints lately?
<infinity> qengho: Right, probably better to ship with the new API.  Does that require other archive changes too?
<tkamppeter> I have a problem with bug 1306344. One could solve it by installing the hplip-gui binary package. Could we ship Trusty with this package? Or do we still have the problem that dependencies make Trusty too big then?
<ubot2> Launchpad bug 1306344 in hplip (Ubuntu) "hp-setup crashes when adding new printer because hp-sendfax is not found" [Undecided,Incomplete] https://launchpad.net/bugs/1306344
<qengho> infinity: If I understand you, no. I now Recommend something in multiverse to get Flash functionality back, but I don't think it affects anything.
<qengho> tkamppeter tested the chromium too, for its touch support, which isn't perfect. Till, have any objection to that chromium you tried Thursday from going in 14.04?
 * qengho will just poll names of people he sees scroll by who tested.
<infinity> qengho: Right, well, if this chromium effectively breaks the world in ways that we'd be breaking it in the first security update, I think we're actually better off being broken from day 1.
<infinity> For some value of "broken".
<infinity> So people don't install plugins on 14.04 that work for a week and then stop.
<infinity> Or whatever.
<tkamppeter> qengho, the freezing of Chromium's main area by touching the tabs is a major problem, as users have to kill and restart the browser (especially if they are in the middle of a shopping/banking/registration transaction).
<tkamppeter> qengho, as it works with mouse as long as one never touches the tabs on the touchscreen we would at least need a very quick SRU.
<Trevinho> hi, I've discovered a regression that went in the last unity upload (due to a merge error that deleted a change), since we're doing a new landing in unity for a security fix, can we put this change back in?
<Trevinho> https://code.launchpad.net/~3v1n0/unity/alpha-windows-shadows-fix/+merge/215674
<Trevinho> unity
<stgraber> infinity: got a sec to look at that last minute LTSP upload? my plan here is to get that in, then respin Edubuntu and test the hell out of LTSP (and instruct folks in #ltsp to do the same), so hopefully we won't need any more last minute changes there...
<Trevinho> Laney: ^
<infinity> Trevinho: Yeah, I think that's fine to land with the other unity fix.
<stgraber> infinity: (I got pinged about old realtek not working this morning, wishing people would test that stuff a bit before release wekk...)
<Trevinho> infinity: thanks
<Laney> Get it added to the silo
<infinity> Trevinho: Speaking of shadows (and I don't expect this fixed for release), has anyone had any opinions on my "shadows shouldn't cross workspace borders" bug?
<infinity> stgraber: edubuntu needs respins for the pending unity anyway, but yeah, you can always spin it twice to get earlier testing it.
<Trevinho> infinity: I think I didn't see it, but yeah, indeed they should not
<infinity> stgraber: I'll poke the upload.
<infinity> Trevinho: I'd love to see that fixed in 14.10 and SRUed back to 14.04. ;)
 * infinity looks for the ref.
<infinity> Trevinho: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1299741
<ubot2> Launchpad bug 1299741 in compiz (Ubuntu) "Shadows shouldn't wrap around to other workspaces" [Undecided,New]
<Trevinho> infinity: SRUs will be very juicy I think
<infinity> Trevinho: Not sure if it's compiz or unity, was a shot in the dark on the filing. :P
<Trevinho> infinity: it's unity, that's wjy I didn't see it :)
<Trevinho> infinity: this is another small community contribuition that might be nice to land now (as it's small and we've the silo ready) https://code.launchpad.net/~sjakthol/unity/fix-1288789/+merge/215403
<infinity> Trevinho: Looks obvious and sane, do it.
<Trevinho> infinity: thank you
<infinity> Trevinho: But also please land things soon, don't dig for too many bugs to pile on. ;)
<Trevinho> infinity: well, I've not control on silos, so I can't define when releasing things...
<Trevinho> infinity: these fixes were noticed/proposed after FF, then... things might pile now a little
<zul> can someone reject glance rc2 as well please?
<stgraber> infinity: thanks!
<tkamppeter> Anyone can help me on the hplip-gui problem which I mentioned earlier here?
<Laney> tkamppeter: It seems to bring qt4 things and gksu, so I don't think so
<tkamppeter> Laney, or should I do an SRU which pulls in hplip-gui, so that people get it with the first update?
<tkamppeter> Laney, other solution would be to move over hp-setup into hplip-gui, so that it is not included in the Qt4-standard installation.
<stgraber> cgmanager probably ought to go in the release if we care about clean shutdowns (which we usually do).
<stgraber> lxc could technically be a 0day SRU (fixes the case where apt does two upgrade chunks and upgrades lxc ahead of apparmor, crashing on the postinst) but it's tiny, should be obviously correct and doesn't take long to build, so I'd feel better if we'd just take it
<tkamppeter> Laney, what about moving over hp-setup into hplip-gui, so that it is not included in the Qt4-less-standard installation?
<xnox> tkamppeter: 14.04 is shipping with qt4 installaed by default desktop.
<Laney> It's not any qt4, but it does pull in more stuff
<xnox> ok.
<zul> Laney:  can you reject glance rc2 for me please?
<Laney> tkamppeter: If -setup isn't usable without -sendfax then that probably makes sense
<tkamppeter> xnox, does it mean that if I let it pull in hplip-gui there is only hplip-gui added and nothing more?
<xnox> tkamppeter: check.
<Laney> zul: ok
<xnox> tkamppeter: boot livecd install it and see what deps are pulled in.
<Laney> gksudo is in there :-)
<slangasek> infinity: I hadn't given up hope of understanding, just had a busy weekend.  Shall I look at it this morning?
<infinity> slangasek: Please do. :)
<infinity> slangasek: (Or farm it out, but I know you had some context earlier)
<tkamppeter> Laney, gksudo dependency can be removed, as according to upstream release notes not meeded any more from 3.13.10 on.
<zul> Laney:  do you mind accepting glance please it fixes a couple of regressions (#1307518) and (#1302044)
<xnox> infinity: can we sneak in 3.15-rc1 into trusty? it has wifi driver for my laptop so i don't need to compile it with dkms any more.
<cjwatson> http://paste.ubuntu.com/7250262/ <- result of "germinate --no-rdepends -s ubuntu.trusty -d trusty -a i386 -c main,restricted,universe,multiverse --seed-packages=desktop/hplip-gui && cat hplip-gui" (do this in a scratch directory as it'll create lots of files)
<cjwatson> i.e. "please tell me what hplip-gui adds over and above what's already in desktop"
<infinity> xnox: Sure!
<Laney> tkamppeter: Yeah, it's not just that (see ^) - your other solution might be workable; I'd investigate that
<Laney> Do we have some way of installing hplip-gui on demand?
<Laney> zul: in a minute
<tkamppeter> Laney, I am currentrly downloading the beta to try it in a VM, so I can see what it will pull.
<Laney> tkamppeter: cjwatson just pastebinned that
<xnox> cjwatson: hm, whilst that's awsome that does show that ubuntu-sso-client-qt did not get back on to the cds but we need it to keep a few things functional in software-center
<xnox> (e.g. commenting, buying, oneconf, etc.)
<xnox> looks like it's only suggested by ubuntu-sso-client.
<xnox> i think i'll upload software-center with a depends added.
<tkamppeter> Laney, have found cjwatsons paste now, 16 MB of extra packages on ISO and 60 MB of extra disk occupation in the system.
<tkamppeter> Laney, load of gksu is negligible, libqtwebkit4 makes one half.
<tkamppeter> Laney, so I will look into moving over hp-setup to hplip-gui. Should I do this as SRU?
<utlemming> stgraber: can we rename the 'SA-East-1' products in the tracker? http://paste.ubuntu.com/7250330/
<tkamppeter> cjwatson, thanks for the investigation.
<xnox> infinity: software-center fix is ^ that should unbreak commenting, oneconf and purchasing features of software-center.
<xnox> (it could go in as an SRU)
<utlemming> strgraber: we have a mismatch between products
<utlemming> stgraber: oh wait, I can do it :)
<Laney> tkamppeter: Probably
<Laney> This depends xnox just added puts most of that qt4 stuff back though
<xnox> Laney: yeah, looking over cjwatson's output it seemed odd. as ubuntu-sso-client-gui was not pulled back onto the cd for software center.
<cjwatson> stgraber: Was ltsp-client's recommendation of zram-config intentionally dropped?
<cjwatson> (to Suggests)
<cjwatson> It's in component-mismatches
<stgraber> cjwatson: yes
<Laney> why was software-center rejected?
<seb128> qengho, Laney: ^
<Laney> ty
<seb128> yw!
<infinity> Those are very odd package versions.
<infinity> Why do I get the feeling that a lot of people don't actually know what "~" means?
<xnox> infinity: please seed ubuntuone-client-data and ubuntu-sso-client-qt into main?
<Laney> If only you could see the rejection reasons.
<xnox> Laney: some rejects are awesome! [ubuntu/trusty-proposed] software-center 13.10-0ubuntu5 (Rejected) Rejected by Adam Conrad: DIE DIE DIE
<Laney> I get that you're chatting in person, but not all of us are there
<xnox> Laney: not really much, i'm too loud so nobody talks to me =(
<qengho> infinity: yeah, sorry. Building huge packages on some wimpy archs takes a long time, so I made the PPA copyable, so there's no lag between testing and deployment. I don't know if any test is the final, and I don't know if I'll have a regular upload later, thus the ~pkgNNN.
<qengho> ARMHF would take 100 hours not long ago. When upstream releases about every 12 days, that's a long time.
<utlemming> stgraber (or another admin for the tracker): it looks like we're missing some EC2 products, can you add them: http://paste.ubuntu.com/7250483/
<stgraber> utlemming: I'll look into it
<utlemming> stgraber: thanks
<stgraber> utlemming: so is "Ubuntu Server EC2 HVM (Asia-Pacific-SouthEast-Australia) amd64" different from "Ubuntu Server EC2 HVM (Asia-Pacific-SouthEast) amd64"?
<utlemming> stgraber: I just fixed that one....it looks like we have "Pacfic" instead of "Pacific"
<infinity> stgraber: That systemd upload sure looks like an upstart bug/misfeature.
<stgraber> infinity: agreed, it'd be nice to be able to tell upstart that failure to set a limit isn't fatal for the job
<infinity> Trevinho: How goes that unity?
<infinity> seb128: ^
<seb128> infinity, dbus is acting up sometime on ppc64el and making test fail, build had to be retried and is still running
<Laney> Just built on ppc64el
<seb128> oh, great
<seb128> infinity, should be ready for copy to the archive once published them
<xnox> cjwatson: infinity: signed wubi at http://people.canonical.com/~xnox/wubi/trusty/wubi-r286-trusty-signed.exe please place binary in http://people.canonical.com/~ubuntu-archive/wubi/trusty/ and update stable symlink there.
<infinity> "acting up"?  Anyone have a log of that?
<seb128> but I'm about to call it a day, so bregma is handling that
<infinity> xnox: Ack.
<seb128> infinity, no, the retry cleared the log, it looks like dbus stops working from the log
<seb128> Trevinho might have details
<Laney> Is a universe to multiverse recommends alright?
<infinity> Laney: Recommends should usually be self-contained in components, IMO.
<infinity> Laney: (Which is why we enforce this between main and universe)
<infinity> Laney: Because recommends are installed by default, the behaviour shouldn't change if you turn components off and on.
<Laney> I was thinking about it from a freeness angle
<xnox> infinity: ^ refreshed meta for ubuntu-sso-client-qt.
<Laney> To be concrete, new chromium has a Recommends on pepperflashplugin-nonfree.
<cjwatson> wgrant: bug 1275270 - would doing this break LP deployments (eventually)?  That's the main reason I hadn't been removing this one
<ubot2> Launchpad bug 1275270 in bzr-pqm (Ubuntu) "Please remove bzr-pqm binary and source package from Ubuntu trusty" [Wishlist,New] https://launchpad.net/bugs/1275270
<infinity> Laney: From a freeness angle, it's also not ideal, but the self-containment thing is what's important.
<infinity> Laney: And I so didn't review the packaging diff before accepting it.
<Laney> That was all I was reviewing. :)
<Laney> Both things are important to me
 * xnox is doing pysendfile support -> dh_python2 conversion
<Laney> qengho: what if I upload to get rid of that recommends?
 * cjwatson re-promotes the ubuntu-sso stuff
<wgrant> cjwatson: It'll immediately prevent anyone from landing any change to Launchpad or Bazaar
<cjwatson> xnox: could you upload ubuntu-meta to sync it up with that once this override change is visible?
<infinity> cjwatson: I already did.
<Trevinho> infinity: I guess bregma will be soon about to hit the release button
<wgrant> Ah, and indeed the bug lists those two.
<infinity> cjwatson: Did you just double-override?
<cjwatson> ah ok
<Trevinho> infinity: I think he's about to test the ppa
<wgrant> Hm
<cjwatson> infinity: I think I Ctrl-c'ed in time
<infinity> cjwatson: I also did some demotions in this cycle.
<qengho> Laney: I don't have a big complaint. I dislike it too.
<wgrant> cjwatson: Probably sane to kill it from trusty, though
<cjwatson> wgrant: I'm confused about how both those statements can hold
<Laney> qengho: I hope something useful happens if you visit a flash page without it installed
<wgrant> cjwatson: Not enough people land changes to Bazaar or Launchpad to justify having it in trusty for the next half decade.
<wgrant> IMO
<Laney> (Thought it should already, given that recommends can be removed)
<cjwatson> Oh, I see what you mean.  Yes, mostly I was checking that it was only client-side
<wgrant> But I don't really care either way.
<wgrant> I believe that's just the client plugin, yeah
<qengho> Laney: I'm proud of this: The plugin-not-found pop-up sends users to a wiki.ubuntu.com page, instead of Adobe now.
<cjwatson> We can obviously just keep it installed locally
<Laney> qengho: Nice
<cjwatson> And direct people to binaries in saucy or whatever
<wgrant> Yeah
<infinity> qengho: If the flash-not-found page can instruct people that they need pepperthing-flash from multiverse, that would be much better than a recommends which won't work if people don't have multiverse on.
<infinity> qengho: (Also, that recommends won't work on flavours where multiverse isn't on during the build)
<cjwatson> wgrant: is gone
<wgrant> cjwatson: :)
 * Laney gets ENOSPC when unpacking chromium
<Laney> stab stabby stab
<qengho> infinity: https://wiki.ubuntu.com/Chromium/Getting-Flash
<qengho> Laney: big source.  :(
<Laney> big source, small ssd
<xnox> infinity: pysendfile should resolve pulling python-support into main by virtue of mir #1267557
<xnox> bug #1267557
<ubot2> Launchpad bug 1267557 in heat (Ubuntu) "[MIR] heat" [Medium,In progress] https://launchpad.net/bugs/1267557
<infinity> qengho: Downgrading that recommends to a suggest gives you a chance to also make the package version -0ubuntu1 :)
<infinity> qengho: (So, yes, please do that, and if the wiki page isn't quite ideal, update it to be better)
<infinity> Laney: Or if you want to take care of that short change.
<Laney> I'm doing it
<Laney> Woah it's doing some checksum verification thing while building the source package
<utlemming> realizing we're all working for 14.04's release -- do we have an EOL date for 12.10? It shows as being supported throught this month, but I don't see an EOL announcement
 * Laney swears more and sets TMPDIR
 * Laney discovers something lintian-ish doesn't respect that
<xnox> infinity: http://lwn.net/Articles/583238/
<qengho> Laney: Of checksum, I didn't want my uploading machine to the the weakest point when the NSA goes looking for a way into user's systems.
<rickspencer3> omg
<rickspencer3> cjwatson, app start up on my phone
<rickspencer3> soooo much better
<cjwatson> yay
<rickspencer3> (oops, meant to do that in #ubuntu-touch, nice that cjwtson is here too :) )
<apw> that xen package brings initial packaging for arm64 hypervisor, as requested
<ogra_> rickspencer3, well, app shutdown just got worse ...
<ogra_> (which has quite some impact for apps restarting in the background)
<rickspencer3> ogra_, ok, noted
<infinity> Laney: Thanks for the chromium.
<infinity> Laney: Can you make sure that ends up in qengho's packaging branch so it doesn't regress in security updates?
<infinity> cjwatson: We totally double-overrode ubuntuone-client-data
<infinity> cjwatson: Copying it back in...
<jamespage> I'm assuming someone from the release team would need to ack switching the default IPSec vpn daemon stack from ipsec to strongswan this close to release?
<jamespage> context bug 1266066
<ubot2> Launchpad bug 1266066 in unbound (Ubuntu) "[MIR] strongSwan" [Undecided,Fix committed] https://launchpad.net/bugs/1266066
<infinity> jamespage: So, on a scale of one to "ha ha ha"...
<jamespage> I was asked todo look at the seed changes, and although I agree it probably puts us in a better place that with ipsec-tools it feels to late....
<jamespage> infinity, quite
<xnox> jamespage: so i requested 3.15-rc1 to sneak in, i think ipsec change should go only after that lands to make sure it doesn't regress.
<xnox> =)))))
<jamespage> xnox, read ipsec == ipsec-tools - my mistake
<xnox> jamespage: i'm EOD, so i'm just trolling now =))))
<jamespage> xnox, I'm trying to eod - not succeeding right now :-(
<mdeslaur> does this help with the ipsec-tools/strongswan decision? https://lists.debian.org/debian-devel/2014/04/msg00075.html
<infinity> jamespage: So, the MIR just seems to be about seeing these in supported (or maybe ship?)
<infinity> jamespage: I don't see anything about switching the way things are integrated or function out of the box.
<infinity> jamespage: Or am I not reading between enough lines?
<jamespage> infinity, part of the change is to drop ipsec-tools and racoon from the supported/ship seeds
<jamespage> the security team understandably only want a single IPsec vpn toolset in main
<jdstrand> and one that has received upstream updates  within 3 years
<jdstrand> (ipsec-tools has not)
<jdstrand> that said, we aren't really pursuing the strongswan mir, our position is that since it is well supported upstream and withing Debian/Ubuntu and if it is going to main, lets stop supporting ipsec-tools
<infinity> jamespage: So, racoon is in because it's a dependency of openvswitch-ipsec...
<mdeslaur> oh, forgot about that dep...so raccoon stays
<jamespage> infinity, pushing that to universe was discussed but I was uncomfortable about that as well
<jdstrand> well
<jdstrand> openvswitch-ipsec is a single python script
<jdstrand> it could be moved to universe
<jdstrand> and that portion of the testsuite disabled
<infinity> Yeah, openvswitch-ipsec depends on ipsec-tools too.
<infinity> So... If the security team really wants this to happen, that little bit needs to be fixed.
<jdstrand> but jamespage mentioned upstream openvswitch doesn't have a strongswan substitute
<infinity> Otherwise, this is just trading some packages in server-ship, which isn't a big deal.  It's not like 'ship' defines default installation behaviours or anything.
<jamespage> indeed not
<jpds> infinity: cjwatson said that he was moving openvswitch-ipsec to universe.
<infinity> jpds: Well, it would need to be unseeded first.
<jdstrand> he probably did, but it was possible he didn't notice the testsuite would likely ftbfs the package if it wasn't modified
<infinity> jdstrand / jamespage: So, if you guys can sort out what needs fixing to make openvswitch appropriately crippled and/or happy, I don't much care if you swap packages in and out of server-ship.
<doko> infinity, looking at wxmaxima ... maxima itself was never built on arm64 and ppc64el
<infinity> doko: Need gcl bootstrapped.  I was looking at that.
<infinity> doko: If I run out of time for that, I'll just force it in.
<infinity> doko: Can you fix gnat/ppc though?
<doko> ohh, yes. will try tonight
<jdstrand> jamespage: so, I think it is clear what our perspective is. I'll take a look at openvswitch-ipsec going to universe
<jdstrand> jamespage: (our being the security team's and jpds' perspective)
<jamespage> jdstrand, ok
<jdstrand> jamespage: if you'd like, I can toss in writing the release note :)
<jamespage> jdstrand, yes please
<jamespage> jdstrand, I think openvswitch is OK - it does not BD on either of ipsec-tools|racoon
<infinity> zul: Dude.  Your heat upload attempts to chmod /etc/nova instead of /etc/heat.
<jamespage> so it probably is just a binary demotion
<jdstrand> jamespage: ok, so you handle the strongswan promotion and I'll handle the ipsec-tools demotion (openvswitch, release note, seed)
<jamespage> jdstrand, ack
<infinity> zul: Furthermore, even if that was correct, it would still be the wrong order, as you mkdir /etc/heat in the next line.
<jpds> jamespage / jdstrand: Thank you.
<infinity> zul: Also, why aren't you shipping those directories in the package instead of creating them in maintainer scripts?
<jdstrand> jamespage: thanks
<knome> bdmurray, can you be a bit more elaborate with comment on bug 1155167? do you want the log from when the dialog is shown, or after the system is installed?
<ubot2> Launchpad bug 1155167 in ubiquity (Ubuntu) "Upgrade from image prompts creating a new user" [High,Incomplete] https://launchpad.net/bugs/1155167
<infinity> zul:
<infinity> +	chmod 0750 /var/log/heat /etc/heat
<infinity>  	mkdir -p /etc/heat
<infinity> zul: That makes no sense.
<xnox> zul: hm.... i fixed pysendfiles to use dh-python instead of python-support thus you should not have dropped the dependency.
<xnox> zul: as soon as i saw a components missmatches notification.
<arges> Hi. Why is the upload for bug 1294163 in the 'New' queue instead of 'Unapproved'? looks/smells like an SRU...
<ubot2> Launchpad bug 1294163 in nvidia-graphics-drivers-331-updates (Ubuntu Precise) "Please update precise nvidia drivers to support 3.13 trusty backport kernel" [Medium,In progress] https://launchpad.net/bugs/1294163
<infinity> zul: 1) Punch baby in face.  2) Deliver baby.  3) Concieve child.  4) Have sex.
<infinity> zul: You may be doing this in the wrong order.
<bdmurray> knome: when the system installing is fine, it'd be /var/log/syslog. running ubiquity in debug mode would be great.
<knome> bdmurray, how does one run ubiquity in debug mode?
<bdmurray> ubiquity -d I believe
<knome> okay, we'll get that done today
<elfy> knome bdmurray - I'll do that shortly
<infinity> bregma: I can haz unity?
<wgrant> xnox: https://chinstrap.canonical.com/~wgrant/_sbin_init.1000.crash
<bregma> infinity, the Unity silo is migrating
<infinity> bregma: I see it in the queue, yeah.  Reviewing now.
<elfy> bdmurray: do you want the logs attached to bug 1155167 while I'm still in the live session - or boot it up and then attach them?
<ubot2> Launchpad bug 1155167 in ubiquity (Ubuntu) "Upgrade from image prompts creating a new user" [High,Incomplete] https://launchpad.net/bugs/1155167
<bdmurray> elfy: in the live session should be fine
<elfy> ok
<elfy> bdmurray knome - debug and syslog attached now
<elfy> bdmurray: if that's not what you need or want - let me know and I'll run through it again
<xnox> emacs-goodies-el & bbdb are the last two things holding emacs23 in main, gettext-el already prefers emacs24.
<bregma> infinity, unity 7.2.0+14.04.20140414.1-0ubuntu1 is ready eager and willing now
<infinity> bregma: The one that I accepted an hour ago?  I should hope so.
<jamespage> infinity, the seed changes have been made for the ipsec-tools/strongswan switch we where discussing earlier
<jamespage> only impacts server iso
<infinity> jamespage: Alright.  What about jdstrand's concern for testsuites blowing up?
<jamespage> infinity, the testsuite does not blow up
<jamespage> I suspect good mocking
<Laney> qengho: please could you put that change in your packaging branch?
<Laney> infinity: â
<qengho> Laney: I did it before you did.  :)
<Laney> you beaut
<jdstrand> re openvswitch testsuite-- yeah, I confirmed it does not
<cjwatson> infinity: Oops.  Thanks
<infinity> stgraber: Hey.  Still missing mythbuntu from the manifest.  Can you fix that?
<stgraber> infinity: sure
<stgraber> done
<jpds> jamespage: Do you still have a push pending for seeds?
<infinity> stgraber: Danke.
<infinity> So, I'm not entirely sure why openvswitch-ipsec wants to stay in main...
<infinity> Nothing seems to depend on it.
<infinity> And it's not seeded...
<jdstrand> infinity: it is in supported-misc-servers
<jdstrand> in platform.trusty
<cjwatson> infinity: It's also not in main.
<infinity> It's really not.
<cjwatson>  openvswitch-ipsec | 2.0.1+git20140120-0ubuntu2 | trusty/universe           | amd64, arm64, armhf, i386, powerpc, ppc64el
<jdstrand> I'm there now and will take care of it
<infinity> Filename: pool/main/o/openvswitch/openvswitch-ipsec_2.0.1+git20140120-0ubuntu2_amd64.deb
<cjwatson> I demoted it earlier today
<jdstrand> oh wait
<infinity> Oh.
<infinity> Kay, my apt cache is out of date.
<infinity> Check.
<jdstrand> cjwatson: you demoted that earlier, I assume?
<infinity> Okay, going to do the strongswan promotions unless someone else is double-overriding right now. :P
<jdstrand> infinity: I just did them
<infinity> Right, I won't touch it. :P
<infinity> And full world rebuild is go.
<infinity> server should happen late enough to pick up your changes.
<jdstrand> k, cause I am still doing ldns and the other one in the bug
<jdstrand> but I'll be done soon
<doko> preparing an apport upload, speeding up python interpreter startup time by 50% ...
<infinity> doko: Lovely.  I just started a respin of the world, but we'll almost certainly let that in for the next forced respin (which seems pretty likely, since it's only Monday)
<balloons> builds finally trickling in!
<balloons> infinity, can we get upgrades added to the final milestone? it shouldn't be depending on a build
<stgraber> done
 * knome bows
<balloons> ty ty
<infinity> (no one demote host, I just did)
<cmars> hi there, would it be too late to accept an upload of hockeypuck 1.0 into trusty universe (https://launchpad.net/ubuntu/+source/hockeypuck)?
<cmars> 0.9 was in raring, but that's horribly out of date. 1.0 supports recon with SKS
<infinity> cmars: Not too late, no.  Go for it.
<cmars> :)
<robru> hmmm, can somebody accept platform-api and mir? they should be under the phone FFe but for some reason queuebot only accepted unity-system-compositor and unity-mir
<cjwatson> robru: hm, ok - done
<robru> cjwatson, thanks!
<cjwatson> https://launchpadlibrarian.net/172827848/buildlog_ubuntu-trusty-arm64.mir_0.1.8%2B14.04.20140411-0ubuntu1_FAILEDTOBUILD.txt.gz  boo, so close
<cjwatson> must've missed that
#ubuntu-release 2014-04-15
<jamespage> please could the swift and neutron uploads for trusty be reviewed by the release team - they both contain high priority fixes (one for upgrades, the other for reboots)
<jamespage> and I don't want them to hold up final release versions later this week
<jibel> infinity, netboot is not on the qatracker for Trusty Final. Is there a switch to flip or must it be added manually?
<infinity> jibel: It would get added if there was a new d-i upload, I imagine.  Or if someone manually copies it over.
<infinity> stgraber: ^?
<ogra_> infinity, i re-enabled the touch cron job ...
<tjaalton> hmm, if syncing libva/intel-vaapi-driver proves working, could those be squeezed in? new upstream releases to add broadwell support, didn't notice debian had those before now
<tjaalton> both in universe
<jibel> infinity, I'll add them with the risk of doing another tiny mistake.
<infinity> jibel: Well, unless you're looking for a place to file bugs, they're almost meaningless there anyway.
<infinity> jibel: It's not like we're going to not ship d-i if someone doesn't mark it ready. :)
<tjaalton> crap, intel-gpu-tools is ancient
<infinity> tjaalton: Deltas on those might be nice to look at without blindly accepting.
<tjaalton> infinity: sure
<jibel> infinity, agreed, but I need a place to say "this has been tested"
<jibel> or not
<infinity> jibel: Yeah, true.  Well, try not to break anything. :P
<infinity> jibel: Or ask stgraber nicely to figure out the right way.
<jibel> infinity, no hurry, I can wait stgraber
 * infinity needs to go attack his face with an angry fork full of omelette.  Back in a few.
<tjaalton> infinity: intel-vaapi-driver http://pastebin.com/mCydS6q8 , libva http://pastebin.com/K8cHEZPu
<tjaalton> bumps both 1.2.x -> 1.3.0
<tjaalton> referenced as part of intel 2014Q1 "release" https://01.org/linuxgraphics/downloads/2014/2014q1-intel-graphics-stack-release
<infinity> tjaalton: That's... A lot of changes.
<infinity> tjaalton: I don't think that's remotely auditable, which means it needs to be very testable, which seems tough to do in a day and a half.
<tjaalton> libva is in testing already
<tjaalton> as i said they add broadwell support, which is bulk of the diff
<tjaalton> actually both of them are in testing
<infinity> tjaalton: How long have they beein in testing, and how many Debian bugs on either package post-date the uploads?
<tjaalton> been in testing since the 12th, this is the only bug I could find, with a patch from upstream https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743701
<ubot2> Debian bug 743701 in src:libva "libva1=1.3.0-1 with i965 makes all video "solid black" with mpv --hwdec=vaapi" [Normal,Open]
<tjaalton> happens only with opengl output sink
<infinity> tjaalton: Can you fix that bug, and we'll talk? :P
<tjaalton> sure, I'll test without it first
<infinity> tjaalton: (FWIW, this is probably a "no", but I understand the broadwell urge, so I'm thinking about it)
<tjaalton> thanks for considering it ;)
<Laney> Please consider releasing https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1174253 before trusty
<ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu Precise) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Fix committed]
<infinity> Laney: The comment directly above yours seems suspicious.
<infinity> Laney: Oh, I suppose that might just be a partial upgrade oops.
<infinity> Laney: Yeah, releasing.
<Laney> I think it's his fail
<Laney> Ta
<jamespage> Please can the neutron and swift upload for trusty be reviewed - they both fix high priority bugs and I'd prefer not to have anything pending when openstack cut final release tarballs if possible
<zequence> I'm going to need someone to help update ubuntustudio-meta. We were lacking xfce bluetooth support - also, I needed to update our indicator packages to gtk3
<tjaalton> infinity: actually, xserver 1.15.1 fixes that libva bug, so we're good already :)
<zequence> Besides, we have to rebuild our ISO anyway on account of Bug 1307485
<ubot2> Launchpad bug 1307485 in network-manager-applet (Ubuntu) "Drop gnome-bluetooth to suggests (regression)" [Low,Fix released] https://launchpad.net/bugs/1307485
<tjaalton> http://lists.freedesktop.org/archives/libva/2014-April/002049.html
<tjaalton> I'll test this combo on broadwell next, to see that it actually lowers cpu usage.. with mpv, vlc is crappy that it actually increases (!) cpu usage with vaapi
<knome> zequence, that should have been in in the first "final" image, at least was for xubuntu
<zequence> Ah, there was a new build yesterday evening!
<zequence> Anyway, we need bluetooth :P
<infinity> zequence: Yeah, can sponsor and respin.  Just a simple meta ./update needed?  Let me give it a spin and see the output.
<zequence> infinity: Yep, just an update required
<infinity> zequence: Testing right now.
<zequence> infinity: Oh, if you want to add a bug report to changelog, Bug 1307969
<ubot2> Launchpad bug 1307969 in ubuntustudio-meta (Ubuntu) "no XFCE bluetooth support in ubuntustudio-meta" [Undecided,New] https://launchpad.net/bugs/1307969
<infinity> zequence: http://paste.ubuntu.com/7254450/ <-- Is that what you were expecting to see?
<zequence> infinity: Yes. Looks good.
<jamespage> infinity, any chance you could look at my request above re neutron and swift pending uploads?
<zequence> infinity: Actually, we seem to have blueman in our latest ISO. I was assuming it wouldn't be there
<infinity> zequence: I assume you still need this meta I just uploaded, though? :P
<infinity> jamespage: I'll look.
<jamespage> ta
<zequence> infinity: The changes will be kept, absolutely :)
<zequence> but, it seems it was not as critical anymore.
<tjaalton> infinity: yep, vaapi works on bdw, not hitting that bug either
<tjaalton> tested snb too
<infinity> tjaalton: Alright, upload, I make no promises about it getting out of the queue, but we'll see.
<infinity> tjaalton: s/upload/sync/ if the Debian packages are alright.
<tjaalton> yeah they are
<tjaalton> thanks
<jibel> xnox, could you have a look at bug 1307983 ?
<ubot2> Launchpad bug 1307983 in ubiquity (Ubuntu) "System not localized after an OEM installation" [Undecided,New] https://launchpad.net/bugs/1307983
<infinity> Err, oh.  That one's not seeded anyway. :P
<infinity> tjaalton: So, I guess all I need to care about is libva.
<infinity> tjaalton: I hope intel-vaapi-driver doesn't break without the libva update...
<tjaalton> it depends on the new libva
<tjaalton> so boo :)
<infinity> tjaalton: Depends at the packaging level, as in won't migrate?
<infinity> tjaalton: Or as in "it'll break"?
<tjaalton> build-depends
<infinity> tjaalton: Okay, fine.  Then no crisis here.  If we don't accept libva, no harm done, it all moved to u-proposed.
<infinity> s/moved/moves/
<tjaalton> right
<tjaalton> is libva seeded then? it's in universe
<infinity> libva1 (from libva) is seeded in:
<infinity>   kubuntu-active: daily-live
<infinity>   kubuntu: daily-live
<infinity>   lubuntu: daily, daily-live, daily-preinstalled
<infinity>   mythbuntu: daily-live
<infinity>   ubuntukylin: daily-live
<infinity>   ubuntustudio: dvd
<infinity>   xubuntu: daily-live
<tjaalton> ah
<xnox> jibel: why is oemconfig also french?
<infinity> Seems like pretty much everyone who isn't Ubuntu uses it.
<xnox> jibel: (in that bug report)
<tjaalton> hehe
<infinity> Curiously.
<tjaalton> yeah there's also a MIR for it
<tjaalton> untouched since a long time
<infinity> Oh, possibly because of vlc.
<infinity> No, vlc is only in myth.
 * infinity shrugs.
<infinity> Anyhow, we have at least one more full respin coming for this apport change, if I choose to let that in, but waiting to see if slightly more urgent things happen that we can do in parallel.
<tjaalton> sure
<infinity> I'll pre-review libva, though, so I can let it in the same batch if I'm okay with it.
<jibel> xnox, I did the initial installation in french
<xnox> jibel: interesting.
<jibel> xnox, hm no, from my notes, for this test I redid it in english, only keyboard was in French
<jibel> xnox, confirmed, initial installation in english, tz and kb autodetected to French by ubiquity. end-user setup in german (UI and slideshow are in german) after the setup and reboot, system is in english with locale reporting a mix of en, de and fr http://paste.ubuntu.com/7254675/
<Riddell> I've a bunch of ubiquity fixes in progress
<infinity> jibel: That was the most confusing reproduction sentence I've ever read.
<Riddell> infinity, xnox: can I do an ubiquity upload?
<maclin> hi realese team, there is a critical bug of ubuntu kylin Bug #1298237 when upgrade from 13.10 to 14.04. I communicated with jibel and decided to add ubuntu-session dependency in ubuntukylin-default-settings. But We can't confirm wheather extra problems would be caused.
<ubot2> Launchpad bug 1298237 in Ubuntu Kylin "Cannot login the system after upgraded from 13.10 to 14.04" [Critical,Confirmed] https://launchpad.net/bugs/1298237
<Riddell> maclin: what's your question?
<Laney> maclin: It sounds sensible
<Laney> It's troubling that you don't have ubuntu-desktop - you might be missing other bits
<maclin> Riddelï¼Laney,  yes, I also wonder we should add ubuntu-session or ubuntu-desktop.
<Laney> maclin: ubuntu-desktop is removed because of ubuntukylin-default-settings in the first place
<Laney> i.e. you remove some packages that ubuntu-desktop Depends on
<infinity> Adding ubuntu-desktop would break a lot more.
<seb128> Laney, we had over similar cases, it made me wonder if we should make unity depends on ubuntu-session, but that would be a circular depends
<infinity> It would bring back packages they don't want, like firefox and ibus things.
<xnox> jibel: so we do not configure network / install language packs during oem-config, yet i would expect the language support to kick in and ask for installation additional language packs which did not happen.
<infinity> The real solution is for ubuntukylin to have a proper seed-based set of metapackages.
<Laney> Yep
<xnox> cjwatson: ^ can i talk to you about locales in a sec when you free after the ca-certificates-java.
<Laney> maclin: ubuntu-session is what you want for now, but you could try installing ubuntu-desktop and reading what that wants to pull in to see if you're missing anything else
<jibel> xnox, ok, I'm currently filing another report for this.
<jibel> xnox, only missing english langpacks are installed
 * Riddell waiting on a fix to pyqt as well
<arges> hey. whats the process for revewing things in this queue: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= . this is an nvidia driver fix for precise/3.13 that i'd like to test
<maclin> Laneyï¼the ubuntu-session is installed by default in the new installed ubuntu kylin 14.04. Does it mean I could just try to add ubuntu-session instead of ubuntu-desktop?
<jibel> xnox, bug 1308056
<ubot2> Launchpad bug 1308056 in language-selector (Ubuntu) "language packs not installed after a non-network installation in a non-english language" [Undecided,New] https://launchpad.net/bugs/1308056
<Laney> maclin: Yeah. You get it in 14.04 because ubuntu-desktop is installed for a little bit and then removed when ubuntukylin-default-settings has its hook run during the image build process. So there you do get its dependencies.
 * jibel not sure about language-selector, feel free to reassign
<Laney> maclin: I think you'll miss any other new dependency of ubuntu-desktop too, that's why I suggested test-installing it in a newly upgraded system to see what it tries to pull in
<xnox> jibel: right, that now makes sense, i'm suspecting it's all the same thing.
<xnox> jibel: thanks for that, let me see what is suppose to be triggering that.
<jibel> xnox, good, thank you.
<maclin> Laney, ok,  I will try it:)
<stgraber> jibel: hey there
<stgraber> jibel: oh, netboot, right, I was vaguely hoping we'd need to upload it for a reason or another yesterday and that it'd just show up then but since that's not the case, I'll push it by hand
<stgraber> they should all be there now
<jibel> stgraber,thank you
<zul> Laney:  ping could you have a look at cinder rc3 when you get a chance please?
<Laney> zul: Just going for lunch, but can after if stgraber or someone else can't do it meanwhile
<Laney> I guess we should look at neutron and swift too
<zul> Laney:  yes definently neutron and swift
<jamespage> that would be nice - thanks Laney
<infinity> stgraber: Ta.
<maclin> Laneyï¼ I tried to install ubuntu-desktop on a newly upgraded system and found 43 packages will be pulled. It is difficult to add so many dependencies.
<cjwatson> I expect most of those will be indirect
<maclin> cjwatsonï¼ do you mean we do not need to add those dependencies?
<cjwatson> maclin: I mean that ubuntu-desktop probably only depends on some of those directly, and the rest are indirectly pulled in by *their* dependencies; if you're mirroring ubuntu-desktop then you should generally only mirror its direct deps
<wgrant> uh
<maclin> cjwatson, that maybe a difficult for us to confirm direct deps and the correctness. Is there any simpler way to check that?  The remaining time is limited and we don't want to pull new more problems.
<cjwatson> maclin: "apt-cache show ubuntu-desktop"
<cjwatson> it isn't hard to "confirm" direct dependencies, you just have to look at them
<maclin> cjwatson, yeah,  it is also a long list of packages
<oSoMoN> hi all
<oSoMoN> webbrowser-app is sitting in the unapproved queue, this upload is a trivial one-liner that fixes bug #1307420, can someone have a look and ack?
<ubot2> Launchpad bug 1307420 in webbrowser-app "The 'Activity' header doesn't disappear after navigating to the activity screen" [High,In progress] https://launchpad.net/bugs/1307420
<infinity> oSoMoN: We'll pull it in if something more urgent triggers a respin.
<infinity> oSoMoN: We're not going to respin the release images just for webbrowser-app.
<oSoMoN> infinity, understood, thanks
<oSoMoN> infinity, so if IÂ were to request another landing for webbrowser-app (with another rather critical bugfix), it would be unlikely to land in 14.04, given the timeframe, right?
<infinity> oSoMoN: It would be as likely or unlikely as the current one in the queue.
<infinity> oSoMoN: In other words, go ahead.
<infinity> oSoMoN: If we can slip it in, we will, if not, it'll need to be pushed to an SRU.
<oSoMoN> got it
<cjwatson> We could at least put webbrowser-app into proposed and block it, couldn't we?
<infinity> We could, yes.
<cjwatson> It's blocked right now
<infinity> We could do that with all the bits in the queue that we're waffling on right now.
<infinity> As long as no one else comes along and unblocks. :P
<oSoMoN> if moving it from unapproved to proposed allows me to merge the changes back in trunk, then thatâd be great, as it would unblock the submission of this other landing request I was mentioning
<infinity> Sure.  We'll do that in a second.
<cjwatson> oSoMoN: ci-train waits for it to be in release or updates, at least at the moment
<cjwatson> but afaik that's overridable, so ask the landing team
<oSoMoN> cz
<oSoMoN> cjwatson, ah, thanks for the tip, will do
<oSoMoN> didrocks, can you comment on the above? ^^ i.e., if webbrowser-app lands in proposed, can I merge back the corresponding change in trunk?
<didrocks> oSoMoN: it's not going to be in -updates nor release?
<cjwatson> we haven't decided where to put it yet
<didrocks> oSoMoN: you can branch from this proposed trunk
<didrocks> no need to merge that back
<oSoMoN> didrocks, well I need the trunk to be up-to-date to submit another landing request, donât I ?
<didrocks> oSoMoN: as the publisher job is telling, you have it at https://code.launchpad.net/~ps-jenkins/webbrowser-app/trusty-proposed
<didrocks> for working and avoid conflicts
<didrocks> cjwatson: when this decision will be taken?
<didrocks> is it like hours or days?
<cjwatson> didrocks: hours not days
<didrocks> oSoMoN: what's your other request your are waiting on the lock to be off?
<Laney> Are you taking care of the queue?
<oSoMoN> didrocks, a fix for bug #1307735
<ubot2> Launchpad bug 1307735 in webbrowser-app "can't open links in twitter" [Critical,In progress] https://launchpad.net/bugs/1307735
<Laney> Like should I not worry about doing those openstack reviews zul asked for?
<cjwatson> didrocks: I think you should just override it for now though
<didrocks> oSoMoN: ok, so let's get you another silo. Just be aware that it means that your previous release is NOT delivered in Touch nor desktop
<cjwatson> (you plural)
<oSoMoN> didrocks, the title is misleading (Iâll update it), itâs actually worse than just twitter being broken, all hyperlinks that request a new tab wonât open at all
<didrocks> oSoMoN: in the m&c job, you have "ignore destination version", check that one
<didrocks> let me get the exact wording, one sec
<didrocks> oSoMoN: IGNORE_PACKAGES_NOTINDEST
<oSoMoN> didrocks, okay
<didrocks> with the hint "Ignore if some packages are not published in the destination"
<oSoMoN> didrocks, Iâll file a landing request in a minute
<didrocks> oSoMoN: ok, please track that one as well as the previous isn't landed/you don't have feedback when it will be available
<didrocks> fginther: when you asked me for the reason of all those possible overrides, here is one FYI ^
<Riddell> isn't http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html awefae long for release week?
<cjwatson> Riddell: anything not handled gets moved over to u-proposed
<cjwatson> doesn't have to be empty
<cjwatson> anyway, some of us have been working on it for weeks :P
<Riddell> cjwatson: fair enough
<Laney> cjwatson: Could you please answer my earlier question? â
<cjwatson> Laney: which one?
<Laney> I basically want to know if I should keep my hands off the queue now :-)
<cjwatson> Laney: -> infinity
<Laney> Fair
<Laney> Thought you were in the room of power
<cjwatson> yeah, but infinity has the master keys, or something
<infinity> Laney: hands off the queue, but if you think something's a good/sane/simple/etc opportunity candidate, go ahead and accept *only* if you block it first.
<infinity> Laney: Then if we're forced to respin for other reasons, we can let in all the blocked things we want.
<infinity> Laney: And if not, they'll carry over to u-proposed.
<Laney> Alright
<Laney> Thinking of block-all source any time soon?
<infinity> Laney: Check the block at the end of my hint, I've already blocked most of the queue as it stands.
<infinity> Laney: Could block-all source for a similar affect, but then we'd need to unblock universe/unseeded bits, and I'm not sure I want to.
<infinity> Laney: Maybe it's about time, though.
<jamespage> Laney, neutron swift and cinder don't end up on media if that helps at all
<infinity> Yeah, those openstack bits should be fine, if the reviews are sane.
<infinity> (I haven't reviewed them yet)
<infinity> (Someone else is free to :P)
<Laney> Got scared off by the aforementioned block
<Riddell> infinity: I'm after respinned images after python-qt4 is done compiling, shall I just click rebuild or should it be synced with anything else?
<jamespage> Laney, are you still good to review the openstack packages in the queue?
<Laney> jamespage: yeah, will do
<jamespage> Laney, thanks - sorry for hassling
<xnox> cjwatson: infinity: provisionally i'm thinking to fix all jibel reported bugs with http://paste.ubuntu.com/7256183/
<xnox> which is respin all but server i think.
<infinity> xnox: Server too, but that's fine.
<Laney> Someone else should look at the neutron diff
<Laney> It adds a wait-for-state call into pre-start of an upstart job
<Laney> I've not used that before to know if it's sane
<jamespage> Laney, for reference its the same code that's in the l3-agent and the dhcp-agent in the same package
<Laney> jamespage: alright then
<jamespage> Laney, I can explain how it works if you like
<Laney> jamespage: it's okay, I read about wait-for-state now
<stgraber> there will be an edubuntu-netboot upload coming in pretty soon
<smb> Hi, just wanted to bring up bug 1292467 as something that may be worth mentioning in the release-notes
<ubot2> Launchpad bug 1292467 in unity-greeter (Ubuntu) "Dual screen greeter can break 3D acceleration" [Medium,Triaged] https://launchpad.net/bugs/1292467
<stgraber> testing the fix now (turns out that last ltsp upload had the unfortunate side effect of breaking a sed in there...)
<jamespage> Laney, thankyou!
<Laney> yw
<Laney> I'm going to unblock them too unless someone screams in the next 5 minutes
<infinity> *scream*
<infinity> Laney: If you're unblocking the unseeded openstack stuff, that's fine.
<Laney> Ya
<Laney> also ta
<xnox> nicer diff in the works http://paste.ubuntu.com/7256369/
<stgraber> can someone please review that upload ^
<stgraber> we'll want to respin Edubuntu once that's landed
<infinity> stgraber: xnox is working on a world-respin trigger anyway.
<stgraber> infinity: ok
<stgraber> infinity: I'm working on a couple more edubuntu installer fix ups, nothing too critical, just trying to avoid having our installer resize itself twice during install :)
<elfy> we appear to have a bit of an issue going on as well - not sure how or when we'll be able to deal with it though
<infinity> stgraber: Wouldn't that be more future-proof if you match on something that will always be in the commandline, with a .*$?
<stgraber> infinity: yeah, ironically, looking at the bzr history, the only bit which didn't change upstream over the past 4 years is splash :)
<infinity> stgraber: ie "s/vt.handoff=7.*$/& nbdroot=:ltsp/" or something.
<infinity> stgraber: Oh, or did vthandoff go away entirely?
<stgraber> it did
<infinity> Right.  Kay.
<infinity> stgraber: What about the name of the line itself?  This is pxelinux, right?
<stgraber> the actual position on the cmdline really doesn't matter, the fact that vt.handoff got dropped with the last bugfix release of ltsp did break the stuff :)
<stgraber> infinity: yeah, in theory we could match on initrd, though the config file in question has a dozen of those too
<infinity> stgraber: Heh.  Fair enough.  Change looks fine regardless, just trying to save you from it breaking again. :P
<infinity> Laney: From your changelog in that gvfs upload, I assue you intend for that to be an SRU?
<Laney> infinity: That's what I expected
<Laney> but if you want to let it in that'd be fine too
<infinity> Laney: I'll give it a ponderance after I'm done "reviewing" maas.
<stgraber> tiny but much appreciated improvement for anyone installing Edubuntu ^ (since we'll be respinning anyway)
<robru> hi! can somebody accept webbrowser-app? it's a one-liner bugfix.
<robru> (same with webapps-applications actually)
<doko> slangasek, infinity: stgraber told me you would be missing some last minute toolchain updates. so here you are with an arm64 binutils (wrong code) fix
<stgraber> :)
<slangasek> um?
<Riddell> infinity: so can I respin?
<cjwatson> Riddell: stop
<cjwatson> Riddell: we're working on some other fixes
<cjwatson> (hence that localechooser)
<cjwatson> it'll be a respin-world due to all the locale damage
<cjwatson> bug 1307983
<ubot2> Launchpad bug 1307983 in localechooser (Ubuntu Trusty) "System not localized after an OEM or offline installation" [High,Confirmed] https://launchpad.net/bugs/1307983
<Riddell> gotcha, thanks
<infinity> Riddell: You can, but I'll end up doing it again in an hour or two.
<infinity> robru: So, wouldn't the second of seb's suggestions ("handle the missing schemas") have been saner than adding a library dependency that you'll need to manually track because you don't actually like the library?
<infinity> s/like/link/
<infinity> doko: Excellent.  Shall we rebuild all of arm64 now?
<robru> infinity, i don't follow.
<robru> infinity, it was crashing due to missing schema, so I added the schema dependency. what do you mean "manually track"?
<infinity> robru: You don't link to that library, so a simple rebuild won't magically bump your dependencies on ABI bumps and such, cause it's a manual hardcoded dep.  Does it really make sense to depend on the library instead of just gracefully handling it not being around?
<doko> infinity, we usually do this on ppc64el only
<robru> infinity, well, missing gsettings schemas are difficult to handle on purpose. upstream on that feels it's appropriate to crash your program when the schema is missing.
<infinity> doko: We can make an exception.  We have a whole day and a half before release, plenty of time to redo the whole thing.
<robru> infinity, that was something that I've struggled with in the past, so the manual tracking option seemed easier
<xnox> robru: schemas should be shipped in an arch:all package, of which we already have three.
<xnox> gsettings-shemaas, and then one for ubuntu and ubuntu-touch
<robru> xnox, the change I'm making isn't to the package that ships the schema
<infinity> robru: But why does the schema ship in the library package?
<robru> infinity, i have no idea. i didn't do that
<cjwatson> Effective diff from this incoming ubiquity upload is difficult to mentally untangle just by looking at it, but it's http://paste.ubuntu.com/7256955/
<xnox> gsettings-ubuntu-schemas, gsettings-ubuntu-touch-schemas, gsettings-desktop-schemas
<cjwatson> xnox: thanks for all your help untangling this locale thing (since I meant to mention you in the changelogs and forgot; I just happened to be in front of the keyboard when doing the final bit)
<xnox> infinity: ^ three packages which are all schemas for all desktops, unity7/8 common schemas, and unity8 only schemas
<Laney> -touch- is a transitonal package
<xnox> Laney: ok.
<xnox> Laney: robru: i believe when this schema change came up a few days back, i did point out that it should be shipped in one of the above schemas-only packages and i was told that will be done as part of review/silo thing.
<Laney> Sorry, I didn't know anything about this in advance
<robru> xnox, what schema change? I recall you talking about a schema change a couple days ago but I have no recollection of even which schema that was then. I'm not talking about making any changes to any schemas, just that I have a package that is missing a dependency on a schema that it needs
<infinity> But a schema being in a versioned library package is wrong on so many levels. :/
<robru> infinity, agreed, but I didn't put it there. can we really transition that out so close to release? My experience with that kind of transition is usually quite painful. can we just "manually track" this library dependency for the upcoming release and then fix "properly" the day U opens?
<infinity> robru: Breaking out the arch indep stuff and depending on it isn't a transition.
<infinity> robru: It's perhaps too late in the release, yes, but this library is not packaged like a sane library...
<Laney> Is this for the migration script?
<robru> infinity, whatever jargon you want to use, you have to breaks/replaces/whatever Just Right, such that there's a seamless switch from one package providing the schema to the  next. If there's any overlap, the packages will conflict
<robru> Laney, yes
<cjwatson> I'd tend to agree we shouldn't be trying to fix this Right Now, but we also shouldn't forget
<Laney> What about making it exit if the schema isn't found?
<Laney> source = Gio.SettingsSchemaSource.get_default()
<Laney> foo = source.lookup(UNITY_LAUNCHER_SETTINGS, True)
<Laney> print foo is None
<cjwatson> This sort of thing massively complicates the resolver's job on upgrade
<robru> Laney, because if it exited without the schema, it would completely fail to do the job that we need it to do, which would leave the user with broken/messy session state.
<xnox> robru: unity packaging is just wrong, a library should not ship anything bug usr/lib/*/*.so.*
<robru> cjwatson, when you say "massively complicates", is that an argument in favor of fixing it properly now, or later? I'm not sure what you meant.
<Laney> If you make it fail then it'll be re-run the next time
<Laney> i.e. exit with a bad code
<infinity> robru: He means that having a library that conflicts with the previous versions of itself completely confuses resolvers.
<cjwatson> robru: It was an argument in favour of fixing it :-)  I did say earlier "I'd tend to agree we shouldn't be trying to fix this Right Now"
<robru> right
<infinity> robru: Because you're effectively telling every unity upgrade that it needs to remove everything then install everything, instead of gracefully upgrading one package at a time.
<Laney> And unless something weird's going on they won't be able to launch unity without the library package installed anyway
<Laney> So it doesn't matter until then
<Laney> At which point the script succeeds
<xnox> robru: compare with precise, the library package is sane, and just has the library in it.
<Laney> I need to be off. There's my idea, take it or leave it :)
<robru> xnox, Laney: right, so if I'm understanding you correctly, fixing this The Right Way right now, will make the upgrade process messy. So we should just add this manual dep as a quick fix right now, so that users upgrading to trusty aren't immediately slapped with a session migration crash, and then when U opens we can get the unity library fixed properly.
<robru> I mean changing which package ships the library
<robru> ships the schema
<cjwatson> Fixing this the Right Way simplifies the upgrade process, but it's risky to do two days before release
<Laney> I've told you a way to avoid the ugly dep and having to do the packaging change, and argued that it's alright in reality too
<infinity> Laney: That doesn't solve the packaging problem, mind you.
<Laney> No, but that's not getting fixed for 14.04
<infinity> Laney: It could.  It's frankly trivial.
<robru> Laney, yeah, exactly. so whether we just accept what I already did or do it your way, they're both technical debt that we have to undo later
<Laney> Alright, I've made me points
<Laney> see you
<robru> Laney, thanks for the input
<xnox> so this goes back to
<xnox> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1193120
<ubot2> Launchpad bug 1193120 in unity (Ubuntu) "unity-common is not common" [Undecided,Fix released]
<cjwatson> So, slangasek made this change to fix update-manager having trouble auto-upgrading things
<cjwatson> I therefore don't think we should simply undo it because there was a known problem previously
<infinity> Alright.
<infinity> Nevermind that, then.
<xnox> sad, but such is live.
<xnox> *life
<infinity> robru: Meh.  I'll accept it as-is, and this can be discussed $later.
<robru> infinity, I'll file a bug and assign myself so I remember to do it
<robru> infinity, thanks
<slangasek> infinity, cjwatson: so would using Breaks instead of Conflicts here against the previous lib versions be viable?
<slangasek> I've missed among the scrollback what the root problem was that people are having problems with right now
<slangasek> but yes, splitting the schemas back out into a "common" package which itself is tied to a specific version of the lib doesn't address the fundamental problem
<cjwatson> slangasek: Conflicts wouldn't cause u-m to remove it ...
<cjwatson> slangasek: I think now is probably not the right time to figure it out :)
<slangasek> cjwatson: do you mean Breaks, rather than Conflicts?
<infinity> slangasek: Right, we went back through history and realized the library had a strict dep on the common anyway, so you hadn't actually made things worse.
<slangasek> ok
<robru> slangasek, I thought the consesus was to put the schemas in a "real" common package (not even part of the unity source package), and be genuinely common without depending on anything
<infinity> It just seems like a fundamentally broken design at play here, and sorting that might be a Hard Problem.
<infinity> Or a "la la la, who cares, it's fixed in unity8"?  (is it?)
<infinity> robru: They're only genuinely common if they can be... If we need versioned deps for those bits, it all fails miserably.
<cjwatson> slangasek: update-manager keys off Conflicts+Replaces for "remove this old package", which IIRC is what you were relying on
<slangasek> cjwatson: right, it probably was
<arges> whats the convention for a package version that was removed from -proposed (say ubuntu2.2), and later another fix is applied on top of ubuntu2.1 ?
<slangasek> arges: ubuntu2.3
<slangasek> (you can't reuse versions once they've been in the archive, even in -proposed)
<arges> slangasek: do I need to add the old changelog entry for ubuntu2.2 even though its not there?
<arges> or can it skip from 2.1 to 2.3
<slangasek> arges: it can skip
<arges> slangasek: ok thanks : )
<infinity> arges: Better to skip, or you confuse people when the things 2.2 claims to do don't happen.
<robru> infinity, so wait, what did we decide then? just going to leave that as-is?
<infinity> arges: (Unless 2.3 builds on top of 2.2, ie "* Fix the previous upload")
<infinity> robru: For now, I accepted your package.
<arges> infinity: ok will do. no its basically a re-do of 2.2 without the issues
<robru> infinity, right, thank you. but I mean for U, should I try to move that schema somewhere else? or leave it?
<infinity> robru: For 14.10 and/or SRUs, it would be nice to tear the problem apart a bit and figure out the best way, cause the current state seems questionable.
<infinity> robru: I'm also not convinced that I have much carefactor right now to have that discussion, though. ;)
<robru> infinity, ok
<robru> infinity, thanks again
<xnox> cjwatson: infinity: http://paste.ubuntu.com/7257234/
<xnox> looks odd, as it's duplicate source lines, thus apt-get update in live edubuntu gives errors.
<cjwatson> That is a bit odd; I forget what does that ...
<cjwatson> Non-fatal errors though, right?
<cjwatson> Ah, livecd-rootfs:live-build/auto/config
<slangasek> robru: so to make libunity work like "normal" libraries, there are basically two options.  Either make the schemas truly "common", so that old libraries continue to work with schemas from the new library; or version the schemas in step with the library so that the schema files are coinstallable (and ensure that they're compatible within each library ABI set)
<cjwatson> Um, a little confused about the history there, if it's non-fatal we should probably just file a bug and move on, right now
<xnox> cjwatson: not fatal, very ugly though. i can't remember, but I think it did propagate to the installed system.
<slangasek> robru: this is an upstream call to make; the current packaging is the best I'm able to come up with given the currently known constraints that the schemas are neither common nor versioned
<robru> slangasek, right, it seems to me that they should be either common or versioned ;-)
<slangasek> robru: when you say it like that it seems obvious ;)  and yet this is not what upstream has done
<robru> slangasek, how much churn really happens in the schema between releases? I would assume it ought to be pretty stable by now (I could understand high schema churn early in unity7's life...)
<slangasek> no idea - that's a conversation to have with upstream
<robru> slangasek, yeah. I can't speak for unity, but my experience with other schemas is that they are highly stable (unchanging over years), which is a strong case for making them common.
<robru> slangasek, right. I filed a bug to remind myself to poke them about it when U opens
<slangasek> I know that the strict versioned dependency on unity-common was added because the schemas were /not/ stable at the time
<robru> slangasek, ok, good to know, thanks
<infinity> robru: Whatever gets fixed for U, it would be lovely to also get it SRUed, if we can do it sanely.
<infinity> robru: It would make life nicer moving forward.
<robru> infinity, true
<robru> cjwatson, can you accept my unity8 upload? it was approved by QA.
<ogra_> is there any reason for unity8 to be blocked ?
<ogra_> (i can unblock myself if needed, but would like to know why it doesnt get through)
<ogra_> infinity, is there a general block in place or some such ?
 * ogra_ is used ot have touch packages auto-accepted
<ogra_> oh, there it is !
<infinity> ogra_: Patience. :P
<ogra_> infinity, well, it was sitting on excuses as valid candidate for quite a while
<ogra_> made me nervous :)
<infinity> ogra_: Yeah, due to a hack we have for unity8 in britney.
<infinity> Not exactly the first time this has come up...
<ogra_> hmm
<zequence> infinity: Are you about to respin all the images later+
<zequence> Apparently the guys who made the lmms package had based in the wrong branch (included a few experimental features)
<infinity> zequence: Yeah, pretty soon, once that debian-installer is in and the world settles.
<infinity> zequence: Do you need a quick lmms upload to go with your respin?
<zequence> It's been repackaged, and though I don't feel it would be absolutely needed to fix it now, if someone has the time, bug 1307591
<ubot2> Launchpad bug 1307591 in lmms (Ubuntu) "LMMS 1.0 baed off the wrong branch" [Undecided,Confirmed] https://launchpad.net/bugs/1307591
<zequence> infinity: I went through the diff a little bit. Gave it a test run. Seems to be ok
<infinity> zequence: Can you give me the source package you want to upload, so I can see a diff and sponsor if sane?
<stgraber> infinity: so what's th status wrt the mass rebuild?
<zequence> bzr branch lp:~israeldahl/ubuntu/trusty/lmms/lmms-1.0.1
<zequence> in PPA https://launchpad.net/~israeldahl/+archive/lmms-1.0.1/+packages
<zequence> The diff https://launchpadlibrarian.net/172870828/lmms_1.0.0%2Bbzr2569-0ubuntu1_1.0.1-0ubuntu1~ubuntu14.04.1.diff.gz
<infinity> stgraber: Once that d-i goes in and britney settles, the world spins.
<infinity> zequence: That's pretty unreadable.  But if you're okay with it, it only affects your images.  Your call.
<zequence> infinity: Yeah, I'm ok with it
<stgraber> infinity: ok. Guess I'll have to rely on highvoltage doing the testing for Edubuntu then unless I'm somehow sufficiently alive when I get back probably pretty late tonight :)
<infinity> stgraber: Well, the number of changes shouldn't be drastic between yesterday's images and tonight's, so you can certainly do some targetted testing instead of covering everything.
<stgraber> infinity: yeah, I did a dozen installs of the current one and things look good except the two things I uploaded earlier (and the bugs that are part of the mass respin)
<stgraber> so I'm pretty hopeful the next one will be releasable
<infinity> zequence: Alright.  So, what do we need to do here?  Do you have anyone who can upload this?  Do you need me to sponsor?  Do you just want the source package as-is from that PPA, or something else (different changelog, etc)?
<infinity> zequence: Oh, I guess as-is from the PPA is a no-go, that has a useless "auto build" changelog. :P
<infinity> zequence: So, can you prep a proper 1.0.1-0ubuntu1 with a sane changelog?
<zequence> infinity: sure
<infinity> zequence: Ta.
<infinity> zequence: You're going to have to be quick to catch me before I leave for the night, unless you're okay with a second respin tomorrow for you.
<zequence> infinity: i think i better take a second look at the source anyway. Probably better to not upload on second thought
<zequence> They can always do a SRU later. It's not a critical fix
<infinity> zequence: Alright.  There's time tomorrow to do it if you really want it in and can QA a respin.  If not, SRU it is.
<zequence> infinity: Ok, thansk a bunch
* infinity changed the topic of #ubuntu-release to: MASS RESPIN IN PROGRESS | Released: Trusty Final Beta | Archive: Final Freeze | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<cjwatson> robru: looks like Adam sorted out unity8 while I was at dinner
<robru> cjwatson, ahhh, thanks infinity
#ubuntu-release 2014-04-16
<infinity> stgraber: ^
<ypwong> slangasek, I find the ubuntu kylin team has a pending FFe, bug 1305187, wonder if it can still be approved? I know it's very very late now, but the package is quite self-contained and they think it's valuable to be on the image
<ubot2> Launchpad bug 1305187 in Ubuntu Kylin "[FFe] upload ubuntu-kylin-docs into archive" [High,New] https://launchpad.net/bugs/1305187
<slangasek> ypwong: I'm not going to update the bug at the moment, but in general the only rule about FFes for new packages is "if you can find an archive admin to approve it, it can go in".  So the best course is to get it sponsored into the NEW queue where it can be reviewed
<ypwong> slangasek, let me ping seb128 if he has bandwidth to do that
<ScottK> Subject says mass respin in progress.  Is that still accurate and for how long?
<ScottK> I may have a good to have, but certainly not worth a respin.
<ScottK> I guess that kind of tells me.  SRU it is.
<robru> hey guys, what happened to minidlna? it seems to be missing from trusty, not sure why. https://launchpad.net/ubuntu/+source/minidlna
<ScottK> robru: Look at the top entry on https://launchpad.net/ubuntu/+source/minidlna/+publishinghistory
<robru> ScottK, ah, didn't notice that those expanded until just now. Was about to ask "yeah, I see Deleted, but *why*?" kthx
<doko> cjwatson, infinity: is the debian "import" already turned off? unable to sync new debian versions
<michagogo|cloud> !respin
<ubot2> Factoid 'respin' not found
<sil2100> Morning release team! Could anyone of you give me some information on why an appmenu-qt5 release I prepared got rejected? Was something wrong?
<wgrant> doko: The debian import is never switched off. What is missing?
<jibel> xnox, language support is working fine now. Thanks!
<jibel> xnox, there is just a problem, unrelated to this change, with the keyboard layout. On first login the keyboard indicator shows FR but the real layout is US.
<xnox> jibel: in login screen, lock screen or the actual desktop?
<jibel> xnox, the actual desktop
<xnox> jibel: ack.
<apw> sil2100, if it was rejected there should have been a reject email with reasons in it
<xnox> apw: which probably went into ps-jenkins-private mailbox - /dev/null @ some canonistack instance =)
<apw> xnox, man that is just hopeless ... sigh
<sil2100> Right, as xnox mentioned - I for sure have no access to that mailbox
<jibel> xnox, language support is still broken in oem mode, and now gnome-language-selector crashes when I open it from system-settings
<maclin> hi release team, we have uploaded the ubuntukylin-default-settings for the critical bug: Bug #1298237, is there anyone who could help to review the package?
<ubot2> Launchpad bug 1298237 in ubuntukylin-default-settings (Ubuntu) "Cannot login the system after upgraded from 13.10 to 14.04" [High,In progress] https://launchpad.net/bugs/1298237
<maclin> hi release team, we have uploaded the ubuntukylin-default-settings for the critical bug: #Bug 1298237, is there anyone who could help to review the package?
<ubot2> Launchpad bug 1298237 in ubuntukylin-default-settings (Ubuntu) "Cannot login the system after upgraded from 13.10 to 14.04" [High,In progress] https://launchpad.net/bugs/1298237
<maclin> this bug is critical for common users when update from 13.10 to 14.04. We have add ubuntu-session dependency to solve it.
<xnox> jibel: hm, that's sad. i will rerun both tests now again and troubleshoot.
<jibel> xnox, see my last comment on 1307983
<jibel> the language the g-l-s wants to install is not the right one
<xnox> maclin: we are investigating it, no everyone is online yet. we will respin kylin for that, and a few other issues already identified in the defects report (keyring missing, and korean fonts missing)
<xnox> maclin: slangasek: archive.ubuntukylin.com:10006 is not signed with ubuntukylin-keyring, hence the bug #1306868
<ubot2> Launchpad bug 1306868 in Ubuntu Kylin "ä½¿ç¨âsudo apt-get updateâå½ä»¤ï¼æ¥æ²¡æå¬é¥" [High,New] https://launchpad.net/bugs/1306868
<maclin> xnox, we are updating the archive by rebuilding packages on launchpad for the keyring bug.
<seb128> ypwong, ^ in the queue, up to the release team to review/accept it next
<ypwong> seb128,  thanks a lot
<seb128> yw!
<xnox> maclin: excellent, that's the right way forward I believe. So no need to change anything on the CD, nor respin.
<maclin> xnox, yeap, JackYu is working on it:)
<maclin> xnox, you mean the ubuntukylin-default-settings will be reviewed  later and we do not need to request rebuild on tracker?
<xnox> maclin: please don't trigger the builds, cdimage team will.
<maclin> xnox, got it, we just wait for it to test^_^   thanks a lot :)
<cjwatson> +       "favicon_url": "www.baidu.com",
<cjwatson> +       "suggest_url": "www.baidu.com",
<cjwatson> Is it intended that these are host names, not URLs?
<cjwatson> Or should they be "http://www.baidu.com/" instead?
<cjwatson> ypwong: ^-
<sil2100> Hello release team! Sorry to repoke regarding the same question - does anyone know by any chance why the appmenu-qt5 upload from yesterday has been rejected?
<cjwatson> sil2100: It introduced a dependency on gtk2, afaik
<sil2100> Yes - is that a problem?
<cjwatson> Er, yes
<sil2100> appmenu-qt5 does basically the same that qtbase-opensource-src does right now
<cjwatson> Oh, wow, I hadn't seen the hard dep on libgtk2.0-0 in libqt5gui5
<sil2100> qtbase-opensource-src also depends on libgtk2.0-dev, as both are now using the same mechanisms
<cjwatson> I expect there was informative text in the reject message, but unfortunately there doesn't seem to be any way to actually feed that back to the requester in the ci-train case
<xnox>  yeah, i was porting qt5 to gtk3, but didn't get it all ready.
<xnox> cjwatson: i think we can pull it back from rejected.
<cjwatson> Well, not as such, the sync would need to be repeated
<xnox> unless we still want to do that thing where we stuff all shlibs into suggests.
<sil2100> I guess I can re-trigger a publishing from the CITrain side
<xnox> (which in this case will work, since even gtk2 will be pulled in by any qt5 app)
<cjwatson> sil2100: hold off a minute
<sil2100> Ok :)
 * xnox goes to propose that patch to appmenus.
<sil2100> I can, of course, try using gtk3 instead gtk2 as well
<sil2100> That was my original plan, but then I noticed the Qt platformplugin that we're trying to emulate uses gtk2
<cjwatson> sil2100: Incidentally the Suggests in appmenu-qt5 is wrong
<cjwatson> libqt5core5 -> libqt5core5a
<sil2100> Ah! It seems to be a leftover from the Qt 5.2 transition
<xnox> sil2100: no, gtk3 support is not yet available upstream, so you can't use gtk3 with qt yet.
<cjwatson> sil2100: OK, yes, I think we're OK with this - could you retrigger publishing?
<sil2100> cjwatson: thanks! Let me try doing that
<sil2100> cjwatson: the same version number will be ok, yes?
<ogra_> xnox, who cares as long as the dependency is gone :P
<cjwatson> sil2100: Yes
<cjwatson> ogra_: In practice right now libgtk2.0-0 is in all the same tasks as appmenu-qt5, so we shouldn't be blocking on that for trusty
<ogra_> cjwatson, i wasnt serious
<ogra_> cjwatson, nice haskell writeup btw :)
<Laney> haskhell
<ogra_> haha
<cjwatson> I've already had one local beer offer as a result, so worth the effort of the blog post ;-)
<sil2100> cjwatson: didrocks will repeat the sync :)
<didrocks> here you go ^
<xnox> didrocks: thanks a lot =)!
<didrocks> yw!
 * cjwatson wonders why ubuntu-kylin-docs is spelled thus rather than ubuntukylin-docs ... oh well
<sil2100> Thank you cjwatson, xnox, release team!
<cjwatson> OK, so we're definitely respinning everything that contains ubiquity, for the OEM thing
<Laney> We're building another webapps-applications to fix launcher icons being re-added for upgrades, also to do runtime detection of the schemas instead of the dependency.
<Laney> Going to upload (copy) it once built, could be SRU or go in as you wish
<cjwatson> We're about to go for lunch here; hopefully infinity will be in in a bit
<asac> do we have release notes drafts up somewhere already?
<asac> (guess desktop/server for now)
<Laney> hold on, dbarth is just checking that one
<Laney> okay, he says it's fine - accept or not as you see fit
<didrocks> asac: I guess https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes
<highvoltage> o/
<jibel> meh, upgrade from ubiquity failed, I cannot login :(
<zul> can someone from ceilometer rc3 please?
<cjwatson> zul: looking
<zul> cjwatson:  thanks
<jibel> I filed bug 1308530, any additional info I can provide? I'll retry without an encrypted home to narrow down the test case.
<ubot2> Launchpad bug 1308530 in ubiquity (Ubuntu) "Cannot login after an upgrade from Saucy to Trusty with Ubiquity" [Undecided,New] https://launchpad.net/bugs/1308530
<stgraber> infinity, cjwatson, Laney: can one of you pretty please review that one? ^
<stgraber> we'll need to respin Edubuntu once it lands
<Laney> okay
<Laney> is that new code?
<infinity> stgraber: Full respin about to happen for ubiquity (again) anyway.
<Laney> ah yes https://launchpadlibrarian.net/169438232/edubuntu-live_13.09.2_14.03.1.diff.gz
<Laney> Accepted
<infinity> Ta.
<infinity> stgraber: Want to pre-emptively unblock that?
<stgraber> infinity: I'll push the unblock yeah
<stgraber> Laney: thanks
<stgraber> infinity: what's the ubiquity bug this time?
<Laney> I don't think it is blocked
<Laney> is it?
<stgraber> Laney: not sure, checking
<stgraber> stgraber@castiana:~/data/code/hints-ubuntu$ grep -r edubuntu .
<stgraber> stgraber@castiana:~/data/code/hints-ubuntu$
<stgraber> apparently not
<infinity> Oh, cool.
<infinity> stgraber: Same bug as last night, different bit.
<stgraber> ok :)
<infinity> (If someone wants to review my kexec-tools, that would be lovely)
<stgraber> I'll do it
<stgraber> looks good and doesn't appear to be seeded anywhere, accepted
<infinity> stgraber: Ta.
<infinity> Alright, switched britney to "block-all source" and unblocked a few things that will block.
<infinity> Excplicit unblock required from here on in.
<Laney> Exciting
<infinity> And one more (should be the last, barring something so release-critical we have to delay the release) respin starting now.
<infinity> stgraber: You're far enough down the pipe that your -live should make it in before your build starts.
<stgraber> infinity: good to hear, Edubuntu takes a while to respin so best not to have to do it twice :)
<cjwatson> jibel: not a regression, I've updated the bug with my analysis
<cjwatson> jibel: entering the same password should work though
<cjwatson> I guess I should test that
<Riddell> infinity: do we have time to get one more fix in or is that it?
<jibel> cjwatson, thanks, I just tried with the same password and indeed it works
<cjwatson> ah good
<infinity> Riddell: If it only affects you, maybe.
<stgraber> infinity: if you do block-all source, should we also stop the auto-approve bot?
<infinity> Riddell: But pretty much from here on, unless you find something that literally sets computers on fire, I think we're done.
<infinity> stgraber: Nah, letting stuff in proposed is fine.
<cjwatson> A bunch of non-image stuff will still probably be fine as long as it has time to build.
<cjwatson> But we should indeed block it anyway to avoid accidental interlocks with stuff that's on images (especially with touch).
<cjwatson> I'm certainly still removing stuff :)
<kiko> hey there
<kiko> dustin and I just did a fresh trusty install
<kiko> and the dash search is failing to find terminal
<infinity> ...
<infinity> Wait longer?
<cjwatson> It would be better to talk to desktop people about this
<Laney> mhr3 in #ubuntu-unity is the guy for this kind of thing
<kiko> cjwatson, who should I talk to?
<Laney> I reported a similar bug the other day, so this kind of thing is known
<kiko> infinity, it's not a waiting problem, no applications are returned in the query at all
<cjwatson> kiko: I don't know
<kiko> duh
<cjwatson> But the release team aren't great people to debug dash problems :)
<Laney> ...
<kiko> cjwatson, okay, but if this is a verified problem it should be release critical
<Riddell> infinity: we're good to go once user-manager is in the archive â
<xnox> kiko: it does not affect installer, it can go in as a 0-day sru, if there is a fix available.
<infinity> Riddell: Ugh.  I guess you'll get a respin after the respin. :/
<cjwatson> I tend to agree with xnox
<kiko> xnox, I see
<jibel> kiko, it works fine here after a fresh install. If I try 'terminal' or 'spinach' it returns something relatively relevant.
<ogra_> it doesnt return a terminal for me if i search spinach though
<jibel> :)
<cjwatson> Sounds worth release-noting if the dash developers can nail down the conditions a bit more precisely.
<apw> kiko, same here after a fresh install (with network) i have a working dash with three results for terminal
<xnox> apw: bug #1307105
<ubot2> Launchpad bug 1307105 in linux (Ubuntu) "Kernel install fails due PAE checks" [Low,Triaged] https://launchpad.net/bugs/1307105
<cjwatson> We're going to need to revert the util-linux Depends: initscripts change from yesterday
<cjwatson> It seems to run into an obscure apt bug and (among other things) breaks an upgrade of a saucy minimal build chroot to trusty
<xnox> kiko: also tested fully offline case, and dash finds three terminals.
<kiko> xnox, fresh install?
<kiko> xnox, i.e. first log in?
<mvo> cjwatson: do you have the apt output of the bug? I can have a look
<bdmurray> is there anything to be done about bug 1279762?
<ubot2> Launchpad bug 1279762 in ubuntu-release-upgrader (Ubuntu) "upgrade to 14.04 from 13.10 failed - cinnamon fails to upgrade" [Medium,Triaged] https://launchpad.net/bugs/1279762
<cjwatson> mvo: https://launchpad.net/~zfs-native/+archive/staging/+build/5914177/+files/buildlog_ubuntu-trusty-amd64.spl-linux_0.6.2-2.1~trusty~10.gbpedccf5_CHROOTWAIT.txt.gz was the one we got in #launchpad
<cjwatson> mvo: http://paste.ubuntu.com/7262204/ was what I got locally
<cjwatson> (to rule out some problem with the mountall in that PPA)
 * shadeslayer taps fingers while waiting for user-manager to migrate
<mvo> cjwatson: uh, nasty
<cjwatson> we think it has something to do with mountall being present in the upgrade set, since builds that don't upgrade mountall don't seem to be failing
<infinity> shadeslayer: Don't worry, it'll migrate long before we need to respin anyway.  Sorting out an upgrade issue.
<shadeslayer> yay
<stgraber> FYI I'm failing to access bzr from nusakan, this may cause germinate and other things to blow up or at least hang
<stgraber> (mentioned to IS, waiting for someone to look into it, probably related to an earlier LP problem)
<shadeslayer> well, not so yay for other people
<cjwatson> stgraber: still?  there was a firewall overload problem a few minutes ago
<stgraber> cjwatson: yeah, still happening now
<shadeslayer> oh hm, so that's what that was
<stgraber> cjwatson: I'm trying a bzr up of /srv/cdimage.ubuntu.com and it's hanging
<cjwatson> mvo: infinity's going to reintroduce a util-linux -> upstart-job dependency, since that's what was present in earlier releases
<xnox> kiko: yes.
<cjwatson> Hopefully that'll perturb things back to sanity ...
<cjwatson> mvo: if that doesn't work then we revert entirely and drop the util-linux -> initscripts dependency
<mvo> cjwatson: ok, if you or infinity have a chroot that has the packages that cause the error, I would love to get a tar file of that, I try to build one now fwiw
<kiko> xnox, okay, can't reproduce then
<cjwatson> mvo: mk-sbuild saucy should be enough, though mine's an upgraded-for-a-while version - tarring it up
<cjwatson> mvo: be quick before Adam reverts this :)
<stgraber> bzr is happy again
<mvo> cjwatson: heh :) I will simply fake the broken one :)
<infinity> mvo: This gets so much more fun.
<infinity> mvo: If I depend on "upstart-job" instead of "initscripts", the loop unrolling failure moves about 10 packages later in the upgrade.
<cjwatson> mvo: yay for office bandwidth.  http://people.canonical.com/~cjwatson/tmp/saucy-amd64.tar.xz
<infinity> mvo: My conclusion here is that util-linux can't ever add dependencies.  Ever.
<cjwatson> mvo: set up in schroot, start session, saucy->trusty in sources.list, apt-get update, apt-get dist-upgrade
<mvo> infinity: I'm sure it is - I have some quick dinner and see what I can do
<mvo> cjwatson: thanks, downloading now
<infinity> mvo: I assume it relates to util-linux's deps being transitively essential, and maybe you unroll those loops more carefully or something?
<tgm4883> who needs the link to the Mythbuntu release page?
<xnox> tgm4883: see the release notes email on ubuntu-release mailing list
<xnox> tgm4883: you have a mythbuntu wiki page which you can update
<stgraber> infinity: so are we currently respinning stuff or waiting for something else to hit (util-linux?)? I'm asking because I'm not seeing nusakan doing much at the moment
<xnox> tgm4883: or add #reload stanza to redirect it to wherever you need it to go.
<tgm4883> xnox, I've got our release statement in a draft on our website
<tgm4883> hmm, #reload stanza...
<xnox> tgm4883: e.g. #refresh 0 http://example.com/
<tgm4883> let me test that, sec
<infinity> stgraber: Waiting on util-linux, then going for it.
<xnox> tgm4883: reload is for internal wiki, refresh is for external urls.
<infinity> stgraber: The world kinda blew up with the network blip anyway. :/
<stgraber> infinity: ok
<tgm4883> xnox, awesome, thanks I'll do that
<xnox> tgm4883: seems to work correctly.
<tgm4883> Yep, I just need to publish now
<tgm4883> On another note, is there a better way for us to get our ISOs on release day? Basically, I have to wait until Ubuntu releases to download our ISO to our rsync server and then our mirrors have to grab it from us
<cjwatson> Fetch current dailies first and then rsync
<cjwatson> Changes will be either small or nil
<tgm4883> cjwatson, and just rename them to their final name when I download them?
<cjwatson> Yes
<tgm4883> I suppose that's doable, still I'd rather not have the chance that lots of people download an old ISO. Our mirrors are all pulling from us, and they only check for udpates a few times a day
<olli_> hey
<olli_> infinity, slangasek suggested to ping you for an ETA at which time 14.04 will be released. Are you in a position to give a rough estimate?
<olli_> I am trying to coordinate a PPA
<stgraber> olli_: tomorrow, that's pretty much the best estimate you'll get since we're still in the middle of mass respins for critical bugs
<infinity> olli_: What stgraber said.
<olli_> :)
<cjwatson> jamespage: wanna have a look at my comment on bug 1294005?  we still just about have time
<ubot2> Launchpad bug 1294005 in jenkins (Ubuntu) "Please remove jenkins from trusty" [Undecided,Incomplete] https://launchpad.net/bugs/1294005
<jamespage> cjwatson, generally anything with *jenkins* in it that's a reverse dependency is really actually part of jenkins
<robru> cjwatson, hey, we have a new unity8 in proposed, can you accept it? bump the version number I think needs to be done for that. (not clear to me what it is about unity8 that requires manual acking each time)
<cjwatson> robru: one moment
<robru> cjwatson, sure, no worries
<cjwatson> robru: it's not about unity8 itself, it's a workaround for a dependency in indicator-something (network I think)
<robru> hmm
<cjwatson> we're lying and saying unity8 is available on all arches to avoid having to tear things out above it
<cjwatson> and I haven't yet got round to generalising that to avoid the version
<robru> ahhhhh its the arch issue again
<cjwatson> anyway, bumped
<robru> cjwatson, thank you
<cjwatson> jamespage: can you ack bug 1265920, since you reviewed the initial packaging?  it looks valid to me, just double-checking
<ubot2> Launchpad bug 1265920 in rds (Ubuntu) "RM: rds -- dead upstream" [Undecided,New] https://launchpad.net/bugs/1265920
<cjwatson> jamespage: jenkins> mm, yeah, I see that those three packages are in fact circularly build-dependent (whee)
<jamespage> cjwatson, its been fun :-(
<cjwatson> jamespage: do we actually need to tear out basically everything that matches *jenkins*?  that's rather more work :)
<jamespage> cjwatson, I'd probably just pull jenkins plus those two packages you identitified
<cjwatson> right
<jamespage> cjwatson, it is possible that someone might step up in Debian to pickup maintaining jenkins
<cjwatson> mkay, so I won't blacklist it
<jamespage> cjwatson, +1
<jamespage> cjwatson, +1 on the rds removal as well
<jamespage> cjwatson, I'd quite forgotten about that
<cjwatson> jamespage: OK, RIP jenkins packaging
<jamespage> cjwatson, thanks
<jamespage> I think
<ogra_> stgraber, is queuebot off ?
<ogra_> i see unity8 on the changes ml ...
<stgraber> it may not have liked the earlier network problem
<ogra_> :)
<shadeslayer> infinity: how long before respin?
<shadeslayer> Because I'll probably head home within 15-20 minutes
<infinity> shadeslayer: A few seconds.
<shadeslayer> oh ok
<infinity> (Respins happening now, if you find any more bugs from here on, too bad...)
<JackYu> infinity, would you please review the ubuntukylin-default-settings before respins...
<JackYu> infinity, we add  the ubuntu-kylin-docs uploaded today:)
<slangasek> I can look
<slangasek> JackYu: ubuntukylin-default-settings accepted, I trust that it will successfully be published before the respin-the-world reaches ubuntukylin ... and if not, we respin again
<cjwatson> slangasek: it should do, from the current respin order
<JackYu> slangasek, great, I think it would be, lol
<slangasek> oh, but that requires an explicit unblock too, better do that
 * shadeslayer is waiting for fresh ISO's :)
<Daviey> infinity: Hey, when you start pre-publishing - can you give tgm4883 & myself a ping, so we can get the mythbuntu iso into it's own mirror network?
<doko> cjwatson, slangasek: can one of you remove gcj-4.6? https://bugs.launchpad.net/ubuntu/+source/gcj-4.6/+bug/1276540
<ubot2> Launchpad bug 1276540 in gcj-4.6 (Ubuntu) "please remove gcj-4.6 in trusty" [Undecided,Fix released]
<cjwatson> doko: I did
<doko> ouch, didn't hit refresh
<ogra_> can someone give unity8 some love ?
<ogra_> ah, ignore that
 * slangasek snuggles up against unity8
<apw>  * slangasek gets bitten
<cjwatson> stgraber: is it intentional that "mark as rebuilding" or similar is no longer available on iso.qa?
<cjwatson> I'd like to be able to mark images as rebuilding even in the case where the rebuild was queued directly on nusakan
<cjwatson> doko: you might actually manage to get mpclib removable, by the looks of it :)
<doko> cjwatson, yep, still trying =) didn't want to keep 4.7 at all, but anyway ...
<infinity> Life's cruel.
<infinity> doko: Thanks for fixing gnat-4.8.
<stgraber> cjwatson: I think the old state and behaviour is now called disabled
<stgraber> cjwatson: in that mode, the build still exists and can be accessed but result reporting is disabled until a new build is published
 * balloons listens to cjwatson and stgraber about marking builds
<cjwatson> stgraber: ok, so if I did "Mark as disabled (prevents result reporting)" on a bunch of builds, that would be fine?
<stgraber> yep
<cjwatson> ok, cool, thanks
<ogra_> stgraber, hmm, so i seem to not be able to trigger a touch rebuild via the UI
<ogra_> at least it doesnt say "currently building" next to the images
<stgraber> ogra_: ok, just finished fixing a small glitch in the upgrade path of the stable channel, now looking at the tracker
<stgraber> ogra_: is it fine if I do end up triggering both of the touch builds?
<ogra_> yep
<utlemming> stgraber: do you have information about the mass respin?
<utlemming> infinity: ^^
 * utlemming tries to figure out if cloud images need re-generating
<infinity> utlemming: maas... Respin?
<ogra_> heh
<infinity> utlemming: There's no new maas other than the one that got in yesterday.
<utlemming> infinity: ah, do you have the bug link?
<utlemming> infinity: I meant s/maas/mass
<infinity> utlemming: Oh, I can't read.
<infinity> LA LA LA>
 * ogra_ hands infinity some window cleaner
<stgraber> ogra_: not seeing any trace of your rebuild request, however when I selected both here and clicked rebuild, I see it queued as expected
<ogra_> i thought you were joking :)
<smoser> utlemming, maas shoul dhave no affect on cloud images.
<infinity> utlemming: Yes, you want to regen your cloud images to match current binaries.
<infinity> smoser: I can't read.  He said mass.
<ogra_> stgraber, i selected the top checkbox, both rows turned yellow (never had that before)
<cjwatson> util-linux is definitely on cloud images. :-)
<ogra_> stgraber, and then i just clicked "update rebuild status"
<utlemming> cjwatson: ack, thanks
<stgraber> ogra_: same i did here, expected it worked for me :)
<ogra_> and it returned
<smoser> yes, util linux is in cloud image.
<ogra_> hmm, weird
<ogra_> as long as it works for others :) i can fall back to nusakan worst case :)
 * utlemming starts re-spinning
<stgraber> ogra_: not seeing anything from you in the log either. You may want to logout and login again in case it was your SSO creds failing somehow.
<ogra_> i opened the page afresh ... and got auto logged in
<ogra_> hmm
<ogra_> we'll know the next time i try :)
<stgraber> ogra_: this morning I noticed that the ACLs were wrong and apparently xubuntu was the team with access to the touch build (go figure), so I fixed that but you need to make sure your membership in the touch release team is passed through SSO (you need to tick a box in there) if you want to have access
<ogra_> ah, k
<ogra_> i'll make sure to re-login before the next build then
<slangasek> infinity: you mean you didn't trigger the mass respin with 'juju respin'?
<slangasek> doko: did you see that your gcc-4.7-armel-cross upload FTBFS?
 * stgraber grabs Edubuntu
<doko> slangasek, yes, fixed the wrong branch
 * doko would like to do some python work today too ...
<utlemming> infinity: can you mark the Cloud Images as superceeded, they are being rebuilt and tested now
<infinity> utlemming:
<infinity> utlemming: Yup.
<mvo> cjwatson, infinity: fwiw, bug #1308654 has the needed bits to reproduce the failure, I look into it next (probably in the morning, its getting late here)
<ubot2> Launchpad bug 1308654 in apt (Ubuntu) "configure order broken for util-linux in saucy->trusty" [Undecided,New] https://launchpad.net/bugs/1308654
<cjwatson> cool, thanks.  there's no huge rush right now
<mvo> cjwatson: thanks, good to know
<jibel> xnox, wrt. i18n issue in OEM mode, with 16.1, German is proposed for installation in "system settings -> language support" and first on the list, but there is no notification if you don't open language support.
<infinity> mvo: Yeah, we backed out the problematic change, but I figure this points to a reasonably nasty bug we want fixed Soon(tm), but not for release.
<mvo> infinity: indeed!
<jibel> xnox, even after a reboot, no notification to install the missing lang packs
<robru> hey guys, can somebody accept unity-firefox-extension? it's an important (and small) bugfix requested by seb.
<cjwatson> I can accept it, but it isn't going into the trusty release pocket at this point
<cjwatson> it'll have to be updates
<cjwatson> (because we don't have any more respin slots)
<cjwatson> well, not unless somebody discovers that our images burn computers
<wgrant> om nom nom
<robru> cjwatson, i'm ok with -updates, thanks
<infinity> robru: You're aware that there's a release in less than 24h, I assume. ;)
<robru> infinity, yes, that's why it's just a small bugfix ;-)
<cjwatson> it can go to -updates though once it's built
<cjwatson> (I agreed this with dbarth and it's on the whiteboard here)
<infinity> robru: Size doesn't matter, it's about respinning and testing images (which we won't do at this point, except for bugs that actually literally violate your mother).
<robru> infinity, oh btw, we're landing some new features in unity7, can you accept those? ;-)
<infinity> robru: But yeah, it could go to -updates as a 0-day SRU.
<robru> ah ok
<balloons> so, I'm curious what langpacks we have on the images atm, and wondering why we didn't add back german and french for instance when we stopped caring about image size
<cjwatson> look at the manifests
<cjwatson> we do care about image size a bit - somebody reported earlier today that we don't fit on a 1gb usb stick any more, which I think is unfortunate and would have tried to fix it if we had time
<cjwatson> bandwidth isn't unlimited and the bigger the image is the harder it is for people to download it
<doko> cjwatson, infinity, slangasek, stgraber: so for opening the u-series, there won't be many changes from my side (and I'll only be back on Tuesday morning, Fri and Mon bank holidays).
<doko> new binutils would be the only toolchain change
<doko> would be nice if we could open with the same ruby defaults as in debian
<davmor2> Guys just stumbled across bug 1308752  if you do an oem install in one keyboard layout then a user install of a different layout for some unknown reason the initial login for the user fails, reboot the system then you can login
<ubot2> Launchpad bug 1308752 in ubiquity (Ubuntu) "Oem install Login fails on first reboot to user when different keyboard layouts are used" [Undecided,New] https://launchpad.net/bugs/1308752
<zequence> I just realized I've missed an old bug and found a new one.
<zequence> Updated seeds for Ubuntu Studio
<zequence> We would like an update to ubuntustudio-meta
<zequence> Bug 1308755
<ubot2> Launchpad bug 1308755 in Ubuntu Studio "Two power manager applets in Trusty release" [Undecided,New] https://launchpad.net/bugs/1308755
<zequence> and Bug 1284635
<ubot2> Launchpad bug 1284635 in ibus (Ubuntu Trusty) "ibus does not support certain keyboard layouts" [High,Triaged] https://launchpad.net/bugs/1284635
<zequence> infinity: There has been some discussions about the packaging of lmms, but doesn't seem like that has been taken care of, so I doubt that will happen before release. Thanks for your help on that though
<infinity> zequence: Kay, lmms can be SRUed.  But you need some meta changes?
<zequence> infinity: Yeah. Think that should be all (holding my breath)
<infinity> zequence: http://paste.ubuntu.com/7263797/ <-- That look sane?
<zequence> infinity: Yep. that looks right
<infinity> zequence: Why is the response to an ibus bug to remove it? :P
<knome> infinity, because the bug can't be fixed in time
<infinity> knome: Kay.
<knome> infinity, ...and it's a nasty one, not letting you use your own keyboard layout
<knome> infinity, that's what xubuntu did - bail out since it doesn't work
<knome> there is a workaround, but it's not something that is (easily) describable in the release notes, and not something most people would like to do
<knome> most people do not need ibus anyway
<infinity> zequence: Uploaded.
<zequence> infinity: Thanks!
<knome> and the bug is actually mostly/only affecting those who *don't* use ibus...
<infinity> zequence: Might not make it in the current spin set, but if it doesn't, we can just respin again.
<zequence> infinity: Yep. I'll be going to sleep soon. But, will have plenty of time to do tests tomorrow (in less than 12h from now)
<infinity> zequence: Alrighty.
<doko> cjwatson, infinity: please update the version in the gcc-4.7-armel-cross unblock request
<infinity> doko: Already done.
<doko> and for u I get rid off the arm multilibs ...
<infinity> doko: A bash merge in the queue?  Really?
<infinity> doko: I assume that's intended to be an SRU and the bug needs to be updated accordingly?
<bdmurray> speaking of SRUs - infinity how do you feel about a rapid release of whoopsie for bug 1306175?
<ubot2> Launchpad bug 1306175 in whoopsie (Ubuntu Saucy) "whoopsie should not send some data to daisy" [High,Fix committed] https://launchpad.net/bugs/1306175
<infinity> bdmurray: I'll have an opinion in a sec.
<infinity> zequence: Kay, we can respin your images right now.  Doing.
<doko> infinity, it's targeted for trusty-proposed
<infinity> doko: Well, yes...
<infinity> doko: As all uploads are.
<doko> sure, I can re-upload later
<infinity> doko: Nah, just convert your bug to an SRU bug with justification, etc.
<doko> infinity, well is fixing a crash a justification?
<infinity> doko: Regression potential, etc.  But yes, fixing a crash is fine justification.
<utlemming> infinity: we're probably a good 4 hours off before the Cloud Image respin completes. I'm going to step away while this churns.
<infinity> utlemming: Alrighty.
<utlemming> infinity: I'll have testing done shortly after that.
<infinity> utlemming: Turns out we have a hilariously critical desktop bug that's forcing respins anyway, so you win.
<knome> infinity, did you catch my comment about the release notes?
<infinity> knome: Probably not.
<knome> infinity, summary: i think we should continue with what we have now, that is, flavors separated; they seem to have ridiculously different ways to do release notes
<knome> some do not list bugs, some do not list new features
<infinity> knome: Yeah, I agree.
<knome> and some use large screenshots
<infinity> knome: Normalized URLs need to happen though.  But that's not hard.
<knome> so that being said, should we purge the multiple flavor subheadings from the release notes, and add some other kind of links for them?
<infinity> knome: Linking would be nice, yes.
<knome> ...and that being said, does server count as a flavor, or should it stay on the main page?
<infinity> knome: We (Canonical) don't consider it a flavour, so much as just the slightly less graphical Ubuntu. :P
<knome> ok, i'll work on something with that idea in mind
<knome> i'll do it now, so if you are around, i'll ping you in maybe 5-10mins
<Riddell> evening, is there another mass respin in progress?
<knome> apparently
<Riddell> infinity: should I test kubuntu images or are new ones going to appear?
<stgraber> infinity: "we have a hilariously critical desktop bug that's forcing respins anyway", care to share?  is that the OEM bug?
<infinity> Riddell: Kubuntu is fine, the but I'm talking about it all Unity.
<infinity> Riddell: Your images should be final (I hope).
<infinity> s/but/bug/
<Riddell> ok thanks, time to test!
<doko> infinity, cjwatson: mpclib should be removable now, https://bugs.launchpad.net/ubuntu/+source/mpclib/+bug/1255062
<ubot2> Launchpad bug 1255062 in mpclib (Ubuntu) "please remove mpclib, replaced by mpclib3" [Undecided,Incomplete]
<infinity> doko: \o/
<stgraber> oh, I guess the bug is bug 1308572 (looking at other channel activity since it wasn't listed here nor on the iso tracker...)
<ubot2> Launchpad bug 1308572 in unity (Ubuntu) "Ubuntu 14.04: security problem in the lock screen" [Critical,In progress] https://launchpad.net/bugs/1308572
<knome> infinity, https://wiki.ubuntu.com/PasiLallinaho/TrustyReleaseNotesDraft
<infinity> knome: I'm going to lose that in backscroll when I sleep.
<knome> infinity, then don't sleep but look at it now ;)
<infinity> knome: Can you move your notes to wiki/TrustyTahr/ReleaseNotes/$flavour?
<infinity> knome: Oh, that's for the Ubuntu page.
<knome> yep
<knome> and the content is old
<infinity> knome: Yeah, that looks sane (I assume you mean the flavours section).
<knome> well, everything really
<knome> but it's not changed much except the flavors section, some headings made smaller (=== instead of ==), and limiting the TOC to 2 levels
<knome> infinity, re: flavor notes, our are at https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Xubuntu
<knome> and if we use the new layout, i'm much more happy to link directly to the main page for the known issues...
<knome> (instead of including)
<infinity> knome: Yeah, seems sane to me.
<knome> ok, i'll drop it to the main page with (r=infinity)
<knome> :P
<knome> infinity, the page is updated.
<infinity> knome: Ta.
<knome> and please at least take a little glance so it's still sane...
<infinity> knome: Thanks a lot for helping out with notes, BTW.  My least favourite part of release.
<infinity> knome: I'll look in the morning. ;)
<knome> i handle bureaucracy enough with xubuntu stuff, i guess it doesn't really hurt to do a little bit more...
<infinity> knome: It's greatly appreciated.
<knome> glad i can help :)
 * knome likes squatting messy things, even if it meant frustration and headache, as long as it's clean after...
#ubuntu-release 2014-04-17
* infinity changed the topic of #ubuntu-release to: ubuntu/kylin/edu respin | Released: Trusty Final Beta | Archive: Final Freeze | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<robru> question for you guys. now that we are literally in zero-hour, what's the story for touch landings? (I mean ones that are seeded in both, like webbrowser-app). let's say I have a webbrowser-app landing that I want to land. it's a bugfix mainly for touch. if I hit publish I guess it just gets caught in UNAPPROVED. can anything be done about that?
<robru> without interfering with the desktop landing
<alex-abreu> well Ideally we would land for desktop too
<alex-abreu> oxide fix (important) and webbrowser-app
<rsalveti> for desktop it could just be a normal SRU
<rsalveti> but not sure if it'd help us (touch)
<rsalveti> we'd need to spin a new image with -updates enabled
<rsalveti> it seems -updates is enabled already in livecd-rootfs
<robru> yeah it's not very clear to me what is happening with touch while desktop is in this final freeze. I mean most touch stuff has the FFe and just breezes through, but for stuff that's in both, I guess it's just frozen for real
<rsalveti> robru: yup
<rsalveti> that's why I believe we would need to land it as a SRU
<alex-abreu> robru, so what can we do at this point? nothing to land in desktop
<alex-abreu> ?
<robru> well we need somebody from the release team to comment if they were approached by asac about this.
<rsalveti> slangasek: ^ if still around
<alex-abreu> might have been didrocks or dbarth
<alex-abreu> that discussed that
<baker417> Very curious -- approximately what time (and time zone) will Ubuntu 14 be available for download? Thank you!
<Riddell> my testing of kubuntu all good tonight, sleeping now, phone me if something needs my attention (jriddell.org/contact.html)
<slangasek> rsalveti: if it's on desktop, yes, it's frozen for real
<rsalveti> yup, both are
<rsalveti> slangasek: who to proceed with a SRU here?
<rsalveti> anything special for 0-day SRUs?
<slangasek> rsalveti: nothing special
<rsalveti> robru: alex-abreu: then we'd need to SRU them
<alex-abreu> rsalveti, ok then ... & respin a touch image w/ updates enabled
<rsalveti> slangasek: thanks btw
<slangasek> sure
<rsalveti> slangasek: so was able to create an ubuntu-touch image for the x86 emulator with packages from https://launchpad.net/~rsalveti/+archive/touch-emulator-x86
<rsalveti> slangasek: the -gles ones are the new packages
<rsalveti> the rest are just rebuild & minor control file changes
<rsalveti> and was able to boot and so on, so it worked :-)
<rsalveti> will do a clean-up and pile them when "u" is open
<slangasek> rsalveti: great!  and how's the reverse-dependency tree looking?
<rsalveti> slangasek: just missing a few for touch, but was only rebuilding packages related with the ubuntu-touch image
<rsalveti> as I believe we'll have a rebuild in "u" anyway soon
<slangasek> hmm, why would there be a rebuild in u?  are we expecting another qt abi change?
<saiarcot895> Hi all. Can someone nominate for #1308794 for Trusty? I have a fix ready for SRU and everything (I think) (even though the archive is currently frozen)?
<saiarcot895> bug #1308794
<ubot2> Launchpad bug 1308794 in checkstyle (Ubuntu) "Checkstyle unusable on Trusty" [Undecided,In progress] https://launchpad.net/bugs/1308794
<rsalveti> slangasek: right, was mixing the test rebuild with the initial publishing for "u"
<rsalveti> I can just bump and rebuild the remaining, but the list is short
<rsalveti> did a rebuild of more than 30 packages already
<slangasek> yeah, I would expect that the touch builds already covered most of it
<rsalveti> so the good news is that we're close, and it worked :-)
<rsalveti> slangasek: thanks for the detailed email you sent a few days ago
<rsalveti> didn't know we could use shlibs that way :-)
<slangasek> :)
<alex-abreu> can someone also have a look at https://bugs.launchpad.net/webbrowser-app/+bug/1307735 for those in Trusty-updates ?
<ubot2> Launchpad bug 1307735 in webbrowser-app "Hyperlinks that request a new tab donât open" [Critical,In progress]
<alex-abreu> the fixes have been +1 in ci-eng
<alex-abreu> both packages have been already published (about to hit proposed)
<alex-abreu> published & unapproved
<alex-abreu> no proposed
<maclin> hi, release team, we find the cn.archive.ubuntu.com is not synced with the archive.ubuntu.com. This causes some problems in Ubuntu Kylin when downloading packages from apt source.
<saiarcot895> maclin: is this for Trusty or an earlier release?
<maclin> saiarcot895, we just tested in Trusty.
<saiarcot895> maclin: That's most likely because Trusty is yet to be officially released. I would give a day or two for packages to be fully synced.
<maclin> it is strange that there is only main branch in http://cn.archive.ubuntu.com/ubuntu/ubuntu/pool/
<saiarcot895> maclin: Even yesterday, my local Georgia Tech mirror had a few missing packages that was present in the US archive.
<slangasek> it has nothing to do with being released
<maclin> saiarcot895, we can upgrade yesterday  night, but this morning the upgrade failed because of failures of download from cn.archive.ubuntu.com
<slangasek> maclin: http://cn.archive.ubuntu.com/ubuntu/ shows that there's an archive sync in progress
<slangasek> but seems to be in progress for two hours
<maclin> slangasek, got it, can we confirm when will the sync finish?
<slangasek> maclin: well, I have no way of knowing
<slangasek> I guess the server is not one that the kylin team runs? :)
<maclin> slangasek, 'we' means the whole of us^_^
<slangasek> https://launchpad.net/ubuntu/+mirror/mirrors.sohu.com-archive suggests that it's a full week behind
<alex-abreu> slangasek, not sure if you could help w/ https://bugs.launchpad.net/webbrowser-app/+bug/1307735 it,s been published but still in unapproved
<ubot2> Launchpad bug 1307735 in webbrowser-app "Hyperlinks that request a new tab donât open" [Critical,In progress]
<alex-abreu> trying to have them as a SRU since we missed the cutoff
<slangasek> maclin: if we don't control this archive, then I think our only option is to get the cn.archive.ubuntu.com name directed somewhere else.  Do you know if there's one of the mirrors listed for China on https://launchpad.net/ubuntu/+archivemirrors that would be appropriate?
<slangasek> maclin: (our normal approach when a national mirror has a problem is to point the DNS at our server in the UK, but that probably wouldn't work well here)
<maclin> slangasek, I am not familiar with this and studying now:)
<utlemming> slangasek, infinity: Cloud Image respin has completed, tested, and marked ready.
<Mirv> is https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ wrong regarding support times, compared to http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-03-17-21.05.moin.txt ?
<slangasek> Mirv: yes
<slangasek> Mirv: please edit it to match the TB approvals
<Mirv> ok, doing
<slangasek> maclin: I'm told that we're going to redirect cn.archive.ubuntu.com to the US-based mirror to fix the problem in the short term; if you have contacts with one of the other mirror operators who might be willing to become the official mirror, I'm sure the mirror team would be happy to know about it
<slangasek> maclin: (it sounds like we are tentatively looking at Northeastern University)
<stgraber> ^ and that's Edubuntu ready to be released. highvoltage will take it from there in his morning.
 * stgraber -> bed
<didrocks> infinity: cjwatson: hey, sorry to ping you directly, not sure if robru reached any release team member yesterday
<didrocks> infinity: cjwatson: as they should have warned you, we are quite stuck and need to rebuild a Touch image. We need latest oxide-qt and webbrowser-app (which are in UNAPPROVED)
<didrocks> infinity: cjwatson: putting them in trusty-updates will enable us to build an image with it
<didrocks> slangasek: if you are still around as well ^
<didrocks> infinity: slangasek: cjwatson: autopilot as well (I see it in -proposed), whatever pocket you prefer
<asac> slangasek: you bounced off our oxide landing we worked all night on?
<asac> :)
<asac> sorry cant even read yet, just hearsay
<asac> Laney: around?
<asac> whoelse is on release team?
<asac> seems slangasek cjwatson infinity got already pingd by didrocks... so think we have everyone now :)
 * asac waits
<asac> sent slangasek an sms too
<sil2100> I think it's mid-night for slangasek right now, I guess we can only hope the UK-part of the release team to become available
<asac> steve is not known too be a morning person
<asac> seb128: when is Laney around usually?
<seb128> asac, 9uk
<seb128> e.g in 6 minutes
<asac> 1 minute :)
<Laney> asac: I don't know how to do that
<didrocks> Laney: can you review oxide and webbrowser-app meanwhile?
<didrocks> Laney: they still are in UNAPPROVED
<didrocks> we will win a publisher cycle :)
<Laney> hrm
<Laney> srsly, oxide is 223.704 MiB?!
<didrocks> Laney: chromium inside :p
<didrocks> sorry Â© ;)
<Laney> the tubes needed a workout anyway
<didrocks> ahah
<didrocks> Laney: I can provide you a debdiff if the download is going to be long
<cjwatson> here now
<asac> o/
<asac> :)
<cjwatson> there's a debdiff in the PPA, digging it out
<Laney> already got it
<cjwatson> Laney: I'll look at the others then, webbrowser-app plus pushing autopilot somewhere more useful
<cjwatson> oh, you did it
<didrocks> thanks cjwatson, Laney
<Laney> that one was quicker to download
<Laney> I should teach $script to go to the source PPA for diffs
<cjwatson> well, it's an LP bug that you don't get a diff in the queue for PCJs
<Laney> sure
<Laney> seems workaroundable though
<cjwatson> analysis in https://bugs.launchpad.net/launchpad/+bug/851562
<ubot2> Launchpad bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged]
<cjwatson> Laney: I think only sometimes
<xnox> maclin: you can discuss mirror problems on #ubuntu-mirrors. all mirrors should be complete by now, and #ubuntu-mirrors people can point to a different cn.* mirror to a different one.
<xnox> morning everyone.
 * xnox feels lonely here.
<Riddell> morning
<Laney> xnox: 'here'?
<maclin> xnox,  thanks,  I find that the "http://mirrors.sohu.com/" has updated now.
<xnox> Laney: physical, rather than virtual =)
<cjwatson> autopilot unblocked
<Laney> others at $hotel?
<xnox> Laney: no idea.
<xnox> Laney: i commute from home.
<cjwatson> looks like it was a late night last night with the unity debacle
<Laney> like a real person and all
<cjwatson> So, we can't unblock oxide-qt and webbrowser-app because they're also on desktop images, but we can move them to -updates once they're otherwise ready.  I can take care of that
<xnox> Laney: but it's hardly a wifi-enabled airconed coach i took to the city =) just a train flat packed with people =)
<Laney> I want to have a go at putting oxide and webbrowser in updates if that's ok
<Laney> oh ok
<cjwatson> oh, well, if you really want to :)
<Laney> xnox: yeah, that's what normal people so (so I hear)
<cjwatson> you'll need to first check that excuses declares them to be a valid candidate
<Laney> I just sit on the settee eating porridge until the radio beeps then walk upstairs
<cjwatson> (which isn't complete protection but better than nothing)
<Laney> yep
<xnox> Laney: smooth operator =)
<Laney> it's a good life
<mlankhorst> cjwatson: oh speaking of that package, i can't install liboxideqtcore0-dbgsym because it depends on oxideqt-codecs-dbg and oxideqt-codecs-extra-dbg, but installing both fails. :P
<maclin> xnoxï¼slangasek has redirected cn.archive.ubuntu.com to an US-based mirror temporarilyï¼ is it suitable to change it back?
<cjwatson> mlankhorst: err I don't actually know anything about oxide as such
<mlankhorst> ah k :p
<mlankhorst> me neither
<cjwatson> mlankhorst: but dbgsym issues won't/shouldn't block this
<Laney> He's trying to debug something else
<Laney> Probably not a release team matter :)
<infinity> Waking up was not my best decision today.
<cjwatson> grumble, wonder what to do about this cloud-installer that slangasek unblocked but which is uninstallable on powerpc
<infinity> cjwatson: I'd say let it be uninst, juju *should* exist on ppc, we just didn't get that far (needs a scary mongodb endian patch)
<cjwatson> yeah, I was coming to a similar conclusion
<cjwatson> I'll hit it with the big hammer
<infinity> cjwatson: Fixing it to drop the dep only on ppc is just one more thing to undo some day.
<didrocks> cjwatson: Laney: thanks for oxide and webbrowser-app, do we know to poke you to put then in -updates once they are published?
<Laney> no
<Laney> well, I don't know what you know :P
<Laney> but you don't /need/ too
<didrocks> Laney: the thing is that the whole Touch image build is blocked on it and then, it's a +8h to get full test results once it's published in -updates
<didrocks> that's why we are tracking that closely ;)
<didrocks> actually, they are published
<didrocks> cjwatson: mind putting them in -updates?
 * Laney blinks
<didrocks> (and same for autopilot)
<cjwatson> didrocks: Laney said he wanted to take care of the copies to -updates
 * Laney is doing it
<cjwatson> didrocks: autopilot has already migrated to trusty release
<cjwatson> (well, modulo publishing, but it's been copied)
<didrocks> thanks guys!
<cjwatson> it's not on non-touch images so we can be more lenient with it
<didrocks> excellent, thanks :)
<xnox> maclin: i'll check with is.
<maclin> xnox, thanks a lot:)
<JackYu> hi release, would you please review ubuntukylin-default-settings 1.1.9?
<JackYu> hi release team, it fixes bug
<JackYu> #1308889.
<maclin> #Bug 1308889 will make the help menu useless.
<ubot2> Launchpad bug 1308889 in ubuntukylin-default-settings "ubuntu-kylin-docs was not installed by default in latest image" [Critical,New] https://launchpad.net/bugs/1308889
<cjwatson> JackYu: the diff strongly suggests it doesn't change anything
<didrocks> Laney: cjwatson: this is the last one for Touch normally: same path? ^ (-updates or release pocket?)
<cjwatson> (also, does this mean you're asking for a respin?)
<cjwatson> didrocks: release, I'll take a look in a sec
<cjwatson> JackYu: http://launchpadlibrarian.net/173003237/ubuntukylin-default-settings_1.1.8_1.1.9.diff.gz
<didrocks> thanks :)
<Laney> touch only â release
<didrocks> cjwatson: sorry again to nag you today with this :(
<cjwatson> that's ok
<cjwatson> Laney: ok, are you unblocking it then?
<Laney> oh no, it was a general comment
<cjwatson> ah, I guess that was auto-accepted, I thought it was you :)
<JackYu> cjwaton, sorry, let us check:)
<Laney> not me guv
<xnox> maclin: cn.archive.ubuntu.com has been pointing to an uptodate mirror in china for the past 3 hours, the mirror.neu.edu.cn i believe.
<cjwatson> didrocks: unity-mir unblocked
<didrocks> thanks cjwatson, it will naturally migrate to the release pocket without any intervention then?
<didrocks> (well, in nothing in britney blocks it due to failing testingâ¦)
<cjwatson> didrocks: er, in that I have already intervened, I suppose yes :P
<cjwatson> hopefully no further intervention
<nhaines> This is where I pester people toa see if it's released yet, right?
 * nhaines ducks.
<maclin> xnoxï¼ yeapï¼ I got it now,  it was firstly redirected to an IP in UK, the current mirror works well, thanks :)
<cjwatson> nhaines: don't even joke about it, please ...
<cjwatson> with a late unity security fix last night, I suspect it'll be a long one
<nhaines> cjwatson: That's a drag.  I'm just sitting here being mad about webapps being broken.
<nhaines> So consider me a cheerleader.  I'm on your side. :)
<rww> you and your webapps
<nhaines> rww: they're important!  Especially when they break.  :P
<cjwatson> I assume that's the webapp fix that's landing at the moment.
<cjwatson> (oxide-qt, webbrowser-app)
<nhaines> No, it's the Unity integration for web apps.  Some update 3 days ago completely broke it.  Unfortunately I didn't have time to file any bugs (this makes me partly responsible, I know).
<didrocks> nhaines: not being able to get a link opened inside the web app?
<nhaines> didrocks: they no longer show as active unless run from the launcher or dash.  And then they only run in separate windows.
<nhaines> I tried to test with the live CD in case the SDK/core-apps was the culprit, but then there was no integration.
<didrocks> nhaines: ah something else, don't know about that one
<didrocks> that's for dbarth's I guess ^
<seb128> nhaines, what do you mean "show as active"?
<jamespage> morning folks; openstack are starting to produce final release tarballs - zul and I are working on them as they are released
<jamespage> they should all just be version changes only from the last rc's already in archive
<cjwatson> jamespage: none of those are on images, aiui?
<jamespage> cjwatson, that's correct
<cjwatson> should hopefully be fine then
<dbarth> nhaines: what's the error you're seeing?
<dbarth> nhaines: on desktop?
<Laney> Might want to carry on in #ubuntu-webapps :-)
<mlankhorst> ok, updated mesa :P
<mlankhorst> lets see if stuff breaks now
<nhaines> seb128: they show up in the launcher if I visit the page, but don't have the 'active' pip by them.
<dbarth> nhaines: i'm on #ubuntu-webapps
<nhaines> seb128: they can't be Alt-Tabbed to, and clicking on one opens a new, dedicated window instead of a new Firefox window or tab.
<nhaines> And then, of course, they keep pinning themselves to the launcher.
<dbarth> nhaines: that's normal, please join #ubuntu-webapps and i'll explain
<nhaines> dbarth: then I am rather upset.  But, over to #ubuntu-webapps!
<dbarth> wow
<Riddell> kubuntu is golden, any ETA on release?
<cjwatson> This probably depends on whether UbuntuKylin are going to actually tell us whether they want to respin for this ubuntukylin-default-settings changes
<cjwatson> *change
<rbasak> Am I still OK to edit the release notes?
<infinity> rbasak: By all means.
<rbasak> Thanks
<infinity> rbasak: There's no freeze for release notes.  :P
<rbasak> Not even release? :)
<cjwatson> rbasak: release notes are often by nature written after release :)
<cjwatson> bug 1308899, hmm, ouch
<ubot2> Launchpad bug 1308899 in scilab (Ubuntu) "Sync scilab 5.5.0-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1308899
<knome> infinity, reminder: did you look at the release notes? :)
 * cjwatson diffs that to check
<infinity> knome: Not yet! ;)
<cjwatson> I hope dropping libtoolize doesn't break on ppc64el, but worst case it sits in -proposed
 * knome smells like beer already
<knome> not because i've had too much, but because i broke a bottle...
<knome> :|
<knome> so that's it for the release preparations ;)
<nhaines> knome: just means you have to have two now.  :)
<knome> heh, i will, later...
<utlemming> infinity, cjwatson: link to the release notes?
<xnox> utlemming: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes ?
<xnox> utlemming: same place as always.
<knome> xnox, that can't be it... too obvious
<utlemming> xnox: thanks....its early for me
<xnox> utlemming: =)
<knome> somebody should update the download links
<knome> before we go live :P
<apw> zequence, hey are you still editing the releasenotes, can i haz lock ?
<xnox> apw: yeah next adj is ubiquitarianism =)
<cjwatson> that's a noun :)
<AlanBell> hi, who is the release manager now?
<cjwatson> we have a team ... what's the question?
<infinity> The answer is 3.
<AlanBell> who (if anyone) wants auto voicing in -release-party, it was skaet
<infinity> I'm not sure if any of us want to brave -release-party.
<cjwatson> probably folks in ~ubuntu-release should be
<cjwatson> commons-daemon should be a trivial one, if we have buildd time
<infinity> We have pleeeeenty of time.
<infinity> (And if it doesn't make it, we carry it over, meh)
<cjwatson> I should've put scilab on sagari.  Oh well
<cjwatson> took 1h18m on ross last time
<AlanBell> ok, anyone on the release team will be +v in -release-party, just marks those who know what they are talking about :)
<cjwatson> thanks
<knome> AlanBell, heyy... doesn't other people know what they are talking about?
<knome> AlanBell, like... flavor leads? ;)
<AlanBell> oh shush :) it doesn't mean that unvoiced people *don't* know what they are talking about :)
<knome> well if we start voicing people, we should voice everybody who fits the definition.
<Laney> haha, voice begging
<Laney> it's like op begging of old
<knome> lol
<elfy> knome: desperate to make the most of the last few hours as lead? :p
<knome> yes...
<knome> ;)
<knome> i was thinking earlier that all OPs could have a voice.
<AlanBell> knome: lets carry on this discussion in #ubuntu-ops
<cjwatson> infinity: ... want to accept it, then? :)
<jamespage> urgh - all of the openstack uploads are failing autopkgtest with "ubuntu-distro-info: Distribution data outdated."
<tumbleweed> jamespage: we need a name for U :/
<cjwatson> jamespage: oh for god's sake
<nhaines> tumbleweed: unctuous urchin
<cjwatson> do we have any way to tell that that's the only failure?
<xnox> stgraber: the set of netboot products for trusty on arm* doesn't make sense: opam, armadaxp, omap, omap4 are gone, generic-lpae is missing, and arm64-generic is missing.
<Laney> tumbleweed: this happens every cycle now ...
<tumbleweed> Laney: has someone beaten up sabdfl yet?
<Laney> maybe we could consider making distro-info fall back to stable or something
<cjwatson> It is absurd that distro-info has no fallback, still
<xnox> Laney: we did add fallback to distro-info, i thought.
<tumbleweed> the trick is to use distro-info carefully
<Laney> clearly not
<Laney> you have to make every consumer take care of this
<xnox> =(
<Laney> I think pull-lp-source does, for example
<tumbleweed> because there's no obvious right thing to do
<Laney> print warning, return stable
<Laney> unless i'm missing some way that is terrible
<tumbleweed> maybe we should give a few days grace
<cjwatson> jibel: is there any way we could hack run-adt-test to not fail everything for toda?
<cjwatson> *today
<cjwatson> jibel: e.g. http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-cinder/ARCH=amd64,label=adt/81/console
<jibel> cjwatson, yes, I'll fix this.
<cjwatson> jibel: thanks - I'd prefer not to force the openstack packages through without autopkgtests, if we can avoid it
<infinity> cjwatson: "it"?
<infinity> cjwatson: Oh, commons-daemon.
<infinity> Daviey: *nudge*
<cjwatson> yeah
<infinity> Daviey: Something something, mythbuntu, something.
<infinity> Building source ISOs.  Whee.
<cjwatson> good thing I updated ALL_PROJECTS a couple of minutes ago :
<cjwatson> :)
<zequence> infinity: Just marked us as ready. Thanks for helping us out so much these last days!
<jamespage> three more openstack components left - zul is doing heat, waiting on release for glance and neutron
<jibel> cjwatson, done. I re-ran failed jobs.
<cjwatson> xnox: any chance somebody with bandwidth could test that (a) they can reproduce bug 1307875 (b) the package in -proposed fixes it?
<ubot2> Launchpad bug 1307875 in scilab (Ubuntu) "GUI is not usable saying module gui is not installed on scilab" [Critical,Confirmed] https://launchpad.net/bugs/1307875
<cjwatson> jibel: thanks
<cjwatson> hopefully adt-britney will notice
<cjwatson> but I'll force it otherwise ...
<xnox> cjwatson: i can do that.
<cjwatson> thanks
<Daviey> infinity: thanks. duff, beer. don't mind if i do.
<infinity> Daviey: So, yeah.  Something about you guys needing/wanting to mirror images.  But also, they could use some testing in the iso tracker.
<infinity> Daviey: Pretty please on the latter.
<infinity> zequence: \o/
<Daviey> infinity: i would.. but cannot today. tried to drum up othera.
<infinity> Daviey: Try harder, please? :)
<infinity> Daviey: Even just a boot/install/reboot smoketest would be fine.  Don't care if it's thoroughly tested, just need to be sure it won't set computers on fire if we release it.
<cjwatson> xnox: any luck with scilab?  hopefully should just be a quick test ...
<Daviey> infinity: if nobody beats me, i can do it in 1hr.
<cjwatson> huh, why are oxide-qt/webbrowser-app republishing in -updates?  did we forget an override?
<cjwatson> oh, phased updates
<xnox> cjwatson: get loads of traceback from release, upgrading to proposed version now.
<xnox> cjwatson: -proposed looks better.
<xnox> at least doesn't vomit java tracebacks.
<cjwatson> and the ui starts up?
<xnox> cjwatson: yeap and i get the toolbox with drag&drop tools working.
 * xnox should stop playing with discrete signal generators
<jamespage> ok - everything apart from glance has now been uploaded - that just pending build testing by zul
<infinity> jamespage: Timing++
<infinity> cjwatson: We probably want to phase any 0-day SRUs at 100% out of the gate?
<cjwatson> xnox: ok, good enough for me - unblocked, thanks
<cjwatson> infinity: yeah, I would have done here if I'd noticed, but I'm sure this one will sort itself out
<jibel> infinity, I'll update the release notes with the most important bugs we found and send the testing report. Unless there is an emergency fix to verify, testing is over and Ubuntu Desktop is okay.
<infinity> jibel: Ta.
<jibel> jamespage, there is no result on the tracker for MaaS, raid1 and jeos
<infinity> jibel: Can you poke the lubuntu people about marking images ready and if they do or don't want to release ppc?
<jamespage> jibel, my maas people are not up yet
<jibel> infinity, I will
<infinity> jibel: You're a champion.
<jamespage> jibel, as soon as beisner is around he's got a rig setup to test this
<jibel> jamespage, thanks
<cjwatson> urgh, I didn't realise keystone was a 3h30m build
<infinity> We've got some time to get it through.
<cjwatson> 2h10m in
<cjwatson> at least its autopkgtests are quick
<jamespage> cjwatson, neither did I (realize its build took that long)
<infinity> cjwatson: Just gives up time to fix two more FTBFSes. ;)
<infinity> cjwatson: Oh, also, probably time to give up on gcl and force wxmaxima. :P
<cjwatson> Or we could just leave it given that the change doesn't fix anything important.
<cjwatson> https://launchpad.net/ubuntu/+source/wxmaxima/13.04.2-2 <- basically just porting anyway
<cjwatson> oh, that's a sync over an Ubuntu change
<cjwatson> -Build-Depends: debhelper (>= 9), libwxgtk2.8-dev (>= 2.8.4), autotools-dev
<cjwatson> +Build-Depends: debhelper (>= 9), dh-autoreconf, libwxgtk3.0-dev
<cjwatson> I guess the wxgtk version might matter.
<infinity> Yeah.
<cjwatson> OK, I'll force it
<highvoltage> o/
<jibel> mlankhorst, are you still editing the release notes, if not can you release the lock?
<mlankhorst> ok done
<jibel> thanks
<nhaines> I found a release note typo...
<cjwatson> It's a wiki, please do copy-edit and such
<nhaines> "Our 14.04 release image are now available for consumption" in the Touch/ How to install or update section should be "images".
<nhaines> Oh, not locked?  I'm on it then.
<cjwatson> Well, if the wiki edit lock isn't taken.
<nhaines> Also ping jibel.
<nhaines> cjwatson: I just wasn't expecting it to be world-editable, that's all.
<Riddell> ooh all ready :)
<nhaines> cjwatson: annndd it's immutable again.
<Aurvandill> hello
<Riddell> are we nearly there yet?
<Riddell> Aurvandill: join #ubuntu-release-party for chat about release
<Aurvandill> ok
<cjwatson> nhaines: Are you logged in?
<nhaines> cjwatson: yeah.  I had edit permissions, but of course there was an edit lock.
<nhaines> No, let me refresh.
<cjwatson> nhaines: anyway, I've fixed that line
<nhaines> cjwatson: thanks.  :)
<jibel> jamespage, in the release notes, in the section Server/MaaS 1.5, the link Kernel/LTSEnablementStack is broken
<cjwatson> jibel: I have the lock, I'll fix it
<cjwatson> it was just a backwards link
<Riddell> just for good luck â
<cjwatson> infinity: is the list of LTS flavours at the top of the release notes accurate?  I thought there were more this cycle
<cjwatson> or am I thinking of three-year support?
<infinity> cjwatson: I think that's right.  The LP change knows for sure.  Or the TB history.
<cjwatson> mkay
<infinity> cjwatson: Everybody's LTS this time (yay), but only those are 5y.
<nhaines> Just made a quick change to the Touch notes where a header wasn't marked up right.  Fixed the h4 markup.
<cjwatson> OK, right
<sil2100> Hello dear release team! We're in the middle of releasing a unity8-desktop-session fix that we would love as a 0-day SRU (it's rather severe for that project, LP: #1308891) - would anyone have time to make this happen?
<ubot2> Launchpad bug 1308891 in unity8-desktop-session trunk "[SRU] indicators not started" [Undecided,In progress] https://launchpad.net/bugs/1308891
<sil2100> It should be landing in UNAPPROVED shortly
<nhaines> Well that was timely.
<cjwatson> we could probably even still squeeze that into the release pocket, right?  it's not on any images
<infinity> Yep.
<infinity> Squeeze on MacDuff.
<infinity> I'll warn before I close the archive for good.
<cjwatson> ok, unblocking that then
<jamespage> sorry -keystone still building
<cjwatson> Saviq: initctl emit --no-wait is possibly your friend, btw
 * jamespage makes a note to see if its unit tests can be run in parallel like everything else does next cycle
<cjwatson> but since you've tested that I guess that job control works in that shell :)
<cjwatson> jamespage: ETA 25 minutes or so based on the last build
<john1999> !isitoutyet
<ubot2> No john1999, it's not out yet. It's due out some time on the 17th :)
<cjwatson> infinity: did you want to unblock python-taskflow as well as forcing its autopkgtests?
<cjwatson> john1999: please go to #ubuntu-release-party for that kind of thing.  This is a working channel
<infinity> cjwatson: Oh.  Yes, yes I do.
<john1999> you mean you guys r actually working on the build right now?
<cjwatson> john1999: yes, please leave us in peace to finish it
<john1999> cjwatson: just a question
<john1999> cjwatson: please
<john1999> cjwatson: how is ubuntu 14.04 minimal build comming along?
<cjwatson> There are several things you might mean by that and I have no idea which.
<cjwatson> But, regardless, now really isn't the time.
<john1999> cjwatson: ok
<john1999> cjwatson: mind if I just listen?
<cjwatson> We don't mind lurkers
<john1999> ok! i'm fully silent now!
<Saviq> cjwatson, indeed, thanks
<Bernard685> !help
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<Bernard685> !countdown
<ubot2> Please remember that #ubuntu, #kubuntu, #xubuntu, #edubuntu, and #lubuntu are support channels. To countdown to !Trusty release and then party once it happens, join #ubuntu-release-party - For in-person parties, see  http://loco.ubuntu.com/events/global/2702/
<knome> Bernard685, stop that.
<knome> Bernard685, join #ubuntu-release-party if you want to anticipate the release with others
<john1999> Bernard685: that will only delay the release
<Bernard685> Okay
<Bernard685> thx
<knome> Bernard685, john1999: you should both leave this channel.
<Aaruni> quick question : are these ~190 people the people who're working/testing/building/uploading the images ?
<cjwatson> OK, channel moderated for today so that we don't have to keep answering questions; I've tried to voice release/flavour-team/QA/web types, please let me know if you have a legitimate need to coordinate here and I've missed you
<knome> cjwatson, zequence
<cjwatson> ta
<knome> np
<Riddell> cjwatson: what needs to be done still for release? (my girlfriend wants to know when I'll take her to the beach :)
<cjwatson> Riddell: infinity has the master keys :)
<Riddell> infinity: my relationship is in your hands â
<knome> Riddell, lol, just go out ;)
<cjwatson> grumble, keystone now 10min behind schedule
<jamespage> sorry cjwatson and damn software which run tests in serial and have soooo many of them
<jamespage> cjwatson, at least neutron as the manners to run 27k of them in parallel if possible
<infinity> Riddell: I don't think you need to be around for the final push, do you?
<infinity> Riddell: Which will be in 2 or 3 hours, I imagine (last night's respin threw us off a bit).
<Riddell> infinity: web pages need publishing, tweets need tweeting.  plus it's always satisfying to be around for it
<infinity> Riddell: Heh.  Could you pass the web bit off to ScottK?
<Riddell> I have apachelogger helping lots and shadeslayer too
 * infinity nods.
<infinity> Riddell: So, I'll do the initial push soonish, but won't send the release announce until the mirrors settle a bit.
<infinity> Riddell: But you could certainly push out your blog stuff in between A and B.
<utlemming> infinity: let me know when to make the cloud images public
<infinity> Daviey: Any indication on the state of myth testing?
<infinity> And someone needs to tell me what's up with ubuntugnome.
<infinity> jibel: Find me GNOME and Myth people to say nice things about their images? :)
<Daviey> infinity: trying to test it now... but i am not in the most ideal of situations.
<jibel> infinity, for Myth it'll be hard, they didn't even test the release, I'll try to find ubuntu gnome people
<Daviey> jibel / infinity: tgm4883 is taking over the testing of Myth.  He'll have results in 1 hour.
<Daviey> (I was trying to test over 3g->ssh->vnc to a remote server.. wasn't so great)
<jibel> infinity, not much feedback from people on #ubuntu-gnome. I asked whoever is responsible of Ubuntu Gnome to join this channel and coordinate with you.
<knome> looks like their qa lead is amjjawad, not around now
<Laney> Tim said he might not be around for release, don't know about Ali
<Laney> Checking that the cat is still alive after installing ubuntu-gnome just in case nobody better turns up
<infinity> Laney: Yeah, they seem to have marked all their tests up, but no one marked the images ready, so just want to be sure.
<Laney> Yep
<Laney> I'll do it if it gets too late
<infinity> Laney: If I don't hear back, I'll publish them regardless, I think.
<Laney> Seems to ~work
<Riddell> it's this sort of scenario where you need phone numbers to hassle people
<cjwatson> jamespage: I assume we're kind of committed to waiting for keystone at this point, rather than shipping a mixed release ...
<jamespage> cjwatson, I'd rather yes
<jamespage> cjwatson, technically it is just a version change
<jamespage> I'm trying to calc how long its got left
<cjwatson> Yeah, it's towards the end of the test suite but still a fair bit to go
<Daviey> jamespage: it's just ascetics, no code change?
<cjwatson> aesthetics
<jamespage> cjwatson, Daviey: yes it is so we can go without it if need be
<Daviey> cjwatson: That aswell.
<jamespage> cjwatson, how much longer can we wait?
<cjwatson> OTOH I would rather we didn't have to try to flip the switch to release when there's actually a build in flight
<cjwatson> I'm not sure if that's allowed
<wgrant> Please don't.
<wgrant> We might be better off backreving the release pocket :)
<cjwatson> Clearly infinity can be pushing out images beforehand, if he isn't already
<wgrant> Oh
<wgrant> You mean mixed as in between openstack projects, not like a mixed keystone.
<cjwatson> Yes
<cjwatson> I'd rather not though, just 'cos it's so close
<stgraber> jamespage: are the numbers on the right how long it took for the test?
<stgraber> if so, 53min
<jamespage> yes
<stgraber> (based on the rc2 times for all remaining tests)
<jamespage> stgraber, but its running alot slower than the previous version
<cjwatson> I guess brownie is a chunk faster than lamiak
<cjwatson> If I'd realised I'd have forced it there four hours ago
<stgraber> jamespage: hmm, indeed, around 50% slower for the past few tests, so if that stays true, it should be done in 1.5h then...
<jamespage> I reckon about 1 hr
<rbasak> I make it 90% done through the tests (without weighting them for run time).
<rbasak> Assuming tests are the majority of the time there, that makes it ~26 minutes.
<stgraber> rbasak: unfortunately there is a big batch of long running tests later on so I'd expect things to take quite a big longer than that
<stgraber> anyway, not much we can do but wait
<rbasak> stgraber: well, I can weight it then. Now I make it ~49 minutes :)
<rbasak> (as in, that's what I can do while we wait :-)
<xnox> infinity: cjwatson: http://releases.ubuntu.com/14.04/ has beta2 images, or are those in progress to be purged?
<cjwatson> xnox: in progress
<xnox> cjwatson: ack.
<cjwatson> seems to be stuck pushing to acai at the moment
<cjwatson> Think about the practicalities for just one second.
<stgraber> ?
<knome> there needs to be a better release plan next time... especially with the 16.04 lts release.
<infinity> knome: What's wrong with this one?  It's still release day.
<jamespage> at last...
<knome> upload to a secret server, then when it's ready, point cdimage.ubuntu.com DNS to that?
<infinity> knome: People expecting a specific time of day are wrong.
<knome> infinity, well, cjwatson not being able to push updates to the server because it's hammered...
<knome> infinity, i'm not saying there should be a specific time.
<infinity> knome: Oh, yes, that's a problem.  We need to have less impatient users. :)
<infinity> knome: (And yes, we could make the infra saner)
<knome> i'm saying the developers need to be able to do their work...
<knome> that would also make us able to release sooner
<cjwatson> How about for once we talk about this when it *isn't* release day.
<highvoltage> +1
<jamespage> +1
<knome> i'm all for that, just saying.
<knome> is ther and agenda page for the release team meetings? either i can't see it or it doesn't exist
<cjwatson> We don't have release team meetings
<infinity> knome: The latter.
<cjwatson> Except sometimes at UDS
<knome> oh... weekly coordination?
<knome> oh, that's on the mailing list
<infinity> knome: Can we bring these things up next week? :P
 * knome hides under the table in shame
<knome> infinity, i was about to do that.
<cjwatson> oho, keystone finished
<cjwatson> so autopkgtest, copy, done
<cjwatson> *publish, done
<cjwatson> JackYu: You need to talk to infinity
<Daviey> infinity: Problem found with mythbuntu.  Probably affecting 25% or so of new installs.
<Laney> Something weird's going on with the moderation
<Laney> J_ackYu isn't voiced so I guess only cjwatson can see wha the's saying
<stgraber> cjwatson: you may want to voice JackYu
<Daviey> infinity: One line tested fix, can we upload & respin ? :)
<infinity> Daviey: ...
<cjwatson> Oh whoops
<Laney> Didn't know that it worked like that...
<cjwatson> 17:07 <JackYu> hi cjwatson, could we release a previous iso?
<cjwatson> 17:08 <JackYu> cjwatson, I mean http://cdimage.ubuntu.com/ubuntukylin/daily-live/20140416.3/, not 20140417 or 20140417.1
<cjwatson> 17:09 <JackYu> cjwatson, thanks
<cjwatson> 17:09 <JackYu> infinity, hi
<cjwatson> 17:10 <tgm4883> Daviey, 15%
<Laney> I guess that's why "Think about the practicailities" came out of nowhere too
<stgraber> JackYu: hmm, wouldn't that mean releasing with the critical unity bug?
<infinity> JackYu: Seriously?  I don't think that's remotely sane.  Why?
<JackYu> infinity, stgraber, we want to install ubuntu-kylin-docs instead of ubuntu-doc, but we got a problem that both of them are not there...
<infinity> JackYu: I thought 17.1 fixed that.
<Daviey> tgm4883: Can you prepare an upload, that we can at least prep for SRU.
<JackYu> infinity, not yet.
<tgm4883> Daviey, i'll work on it with superm1
<infinity> ubuntu-kylin-docs14.04.3
<infinity> JackYu: It's installed on your ISOs, I can see it in the manifest.
<cjwatson> Daviey: What's the problem here?
<Daviey> cjwatson: bug 1309084, postrm issue that is only exposed on an advanced style install.
<ubot2> Launchpad bug 1309084 in mythtv (Ubuntu) "Mythbuntu installer crashes when installing frontend only" [Medium,Confirmed] https://launchpad.net/bugs/1309084
<JackYu> infinity, let me check. ypwong did the test. I'm still downloading it...
<slangasek> cjwatson: thanks for taking care of cloud-installer.  where can I help this morning?
<Daviey> cjwatson: http://imagebin.org/306161
<cjwatson> Pici: Well, I'm not sure that was totally right ...
<Pici> uhh
<slangasek> knome: breaking a bottle?! we're releasing an OS, not a ship
<Daviey> cjwatson: Providing that ubiquity still pulls in updates from the archive, I think it's reasonable to release with this known issue - if we can 0day the fix.
<knome> slangasek, lol ;)
<knome> slangasek, don't worry, i'm making up for it by drinking more beer. i promise!
<Pici> cjwatson: sorry :/
<cjwatson> Sorry, this is a mess, I hate fancy IRC tricks
<Riddell> infinity: I'm running out, shadeslayer and apachelogger are in control of Kubuntu release
<cjwatson> 17:16 <ypwong> infinity, it's removed somehow by unknown reason (i haven't dug deeper) as can be seen in /var/log/installer/syslog
<knome> Riddell, have a nice day! :)
<cjwatson> Daviey: ubiquity can be told to, though it requires a server-side switch and isn't all that well-tested
<cjwatson> Daviey: I don't think we have time for a ubiquity update today though
<ogra_> stgraber, so we would like "flo mako manta generic generic_x86" 302 from devel/trusty to become 11 stable
<stgraber> ogra_: now or waiting for 14.04 to be actually released first?
<cjwatson> keystone is publishing to release now
<cjwatson> after that I think the archive is closed for business
<ogra_> stgraber, together with the release
<cjwatson> slangasek: spotting anything we've missed
<Daviey> cjwatson: It's a silly space issue, pretty easy to validate.  What would you suggest happens now?
<ogra_> stgraber, just wanted to make sure you have the arch list and numbers :)
<slangasek> ack. is there a release announcement draft somewhere?
<stgraber> ogra_: ok, I can turn off publishing and do it now, though if I do that, you won't have anything publishing in any channel until then
<cjwatson> Daviey: advanced case only?  can we release-note it?
<ogra_> stgraber, well, i dont think we will tinker with any image anymore now :) do as it pleases you and as it causes least work for you
<infinity> Daviey: Given that it's an LTS, release noting and fixing it for 14.04.1 might be good enough?
<Daviey> cjwatson: Tastes rubbish, but I think it's a reasonable thing.  It is recoverable, doesn't burn the system.
<cjwatson> Daviey: We can't turn around a ubiquity upload in much less than an hour, and then there would be image builds; we would be cutting it extremely fine
<cjwatson> And working on tired developers
<infinity> Tired developers that want cake. :/
<Daviey> cjwatson: Sorry, it's not a ubiquity issue. it's a mythtv package issue. Which is reasonably quick IIRC, but the publish and spin is time consuming
<stgraber> ogra_: adding/removing devices doesn't take any time, though the copy might, so may as well do it now
<stgraber> ogra_: so I'll do all that now, hands off cdimage/system-image until release then :)
<cjwatson> I want to see the diffs for both the mythbuntu and kylin fixes
<cjwatson> but I have a hard stop in <1h and will then be offline for the duration
<JackYu> infinity, hi, in this case, could we release a previous build?
<stgraber> ogra_: and just to confirm, you want me to drop grouper and maguro from there, not just keep them on an old version right?
<cjwatson> JackYu: there are no previous builds that don't have a fatal security flaw, as I understand it
<infinity> JackYu: A previous build still wouldn't have your docs, and would also not match the archive sources and moss out on other fixes.
<ogra_> stgraber, i want them to stay around
<infinity> s/moss/miss/
<stgraber> ogra_: ok, why?
<ogra_> stgraber, we dont want to drop the old releases for arches we dont build for anymore
<cjwatson> I don't think we have a lot of options here, in either the Myth or Kylin cases
<ogra_> stgraber, so people can still tinker with tehse devices if they need to
<JackYu> cjwatson, infinity, yep, but a previous version has the ubuntu-docs...
<infinity> JackYu: Could you hack around this by having an ubuntukylin-default-settings SRU that just depends on the docs and pulls them in post-install?
<stgraber> ogra_: ok, it may be slightly confusing to them that they'll get saucy on those and trusty for the others, but whatever :)
<cjwatson> JackYu: And a lock screen that can be bypassed in ten seconds.
<ogra_> stgraber, we dont remove armel images from releases.u.c either when we drop the arch ;)
<stgraber> ogra_: yeah but we don't exactly support saucy on touch either :)
<infinity> JackYu: Or your software-center fork, or something that's always on your images.
<JackYu> cjwaton, OK.
<cjwatson> I like infinity's suggestion here, if it's implementable
<stgraber> ogra_: anyway, I'm happy to keep them around and wipe them off system-image when saucy goes EOL in 3 months
<ogra_> stgraber, true, but i think its evil to just wipe old releases
<ogra_> ah yeah
<JackYu> cjwaton, infinity, so your suggestion is we fix this after this release?
<cjwatson> But basically our choices at this point are to release what we have with release notes (and maybe try to mitigate in SRUs, and certainly fix properly in the next point release) or not release the affected images at all
<ogra_> touch might also have a new release by then
<ogra_> :=
<ogra_> :)
<cjwatson> I don't think we have time and energy to go through another respin cycle
<JackYu> cjwatson, infinity, I agree:)
<cjwatson> The UK release team are all eight hours into their day after a week of pretty consistent overtime
<cjwatson> We *could* build myth and kylin out of updates and release them tomorrow, or something, but it's a public holiday in many places so that relies on Canonical release staff being available
<cjwatson> I won't be
<infinity> I'd prefer not to be.
<cjwatson> So those are the parameters, I think; the affected flavour leads need to decide
<cjwatson> I guess that's a decision from Kylin
<JackYu> cjwatson, :). It's Apr 18 here
<infinity> It sure is.
<cjwatson>  keystone | 1:2014.1-0ubuntu1                            | trusty           | source, all
<cjwatson> We should probably lock the archive soon
<Daviey> cjwatson: debdiff on way.
<slangasek> infinity: do you have a release announcement draft somewhere that I'm not finding?
<infinity> cjwatson: Yeah, methinks I shall lock it down now.
<infinity> slangasek: I haz something I can pastebin for review.
<slangasek> infinity: yes please
<stgraber> ogra_: system-image is ready. For some reason, the code fails to generate deltas for the stable channel but I don't think it's a big deal right now since forcing a full upgrade when moving from saucy to trusty is probably a good thing anyway.
<jose> infinity, slangasek: news team here, if we can have it as well to x-post in the Fridge asap it'd be awesome
<cjwatson> Daviey: OK.  I still think we need you folks to make a decision based on the parameters above, unless somebody volunteers to help with a Mythbuntu publication from an image built from -updates later tonight
<ogra_> stgraber, definitely ... we want to be sure boot.img gets upgraded ... i guess full upgrade is the safest for that
<stgraber> ogra_: I'll figure out what's going on with the deltas next week because those really should be generated on the fly when missing...
<ogra_> yeah
<ogra_> i doubt a delta between saucy and trusty would be a useful size anyway
<JackYu> infinity, hi the release note of Ubuntu Kylin is at: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Kylin
<infinity> JackYu: Lovely, thanks.
<knome> infinity, everything fine with the release notes? :)
<infinity> knome: Looks good enough to me.  And, hey, it's a wiki.
<knome> infinity, yep. goodie :)
<infinity> knome: So, if people don't like 'em, they can fix. ;)
<xnox> jose: we didn't push release announcement yet.
<jose> I'm aware :)
<knome> cjwatson, can you voice elfy?
<knome> or Pici..
<Pici> :)
<Daviey> cjwatson: see the upload ^^
<infinity> Daviey: Fun bug.  And would have been worth a respin for if people had tested yesterday.
<Daviey> infinity: indeed.
<Daviey> infinity: So, do we release note this? Or hope to do a respin in an hour?
<infinity> Daviey: I mean, ultimately, it's up to you guys if you'd prefer to pull the image and fix this later, but $later might be timed poorly with the long weekend, etc.
<Daviey> Either way, should I accept this into proposed as SRU?
<infinity> Daviey: I'll accept the upload, yeah, then we can figure out what to do with it.
<Laney> didrocks: you're expecting that to go to updates?
<infinity> Daviey: If you could smoketest very, very, very quickly, I could respin Myth tonight and release just you guys late. :/
<didrocks> Laney: yeah, no rush on it. I was discussing if they needed a whole SRU bug or if it was considered as 0-day SRU
<slangasek> infinity: everything's in the archive for myth to allow that?
<didrocks> Laney: as it's a crasher fix, I'm unsure a full SRU bug is needed (and for me, there is no rush anyway, as it will be only when we rebuild a Touch image, which will be on Tuesday I guess)
<Daviey> infinity: If you would be willing to do that, You'd earn yourself beer tokens and the appreciation of mythbuntu users worldwide.
<Laney> didrocks: Normally, yes, certainly - every SRU needs to come with a bug
<Daviey> infinity: Talking to superm1 and tgm4883, we are in agreement that we'd prefer to delay the release if need be for this.
<Daviey> infinity: So if you are willing to pull a respin, we'd be most grateful
<cjwatson> Perhaps somebody in the US could help instead / as well?
<infinity> Daviey: It'll need to earn me more than beer, but yeah, I can make it happen.
<Laney> Not sure exactly when SRU rules start to apply
<didrocks> Laney: yeah, I was exactly unsure of that ;)
<infinity> Daviey: I can also jam mythtv into the release pocket for you, if no one else ships it...
<infinity> And indeed, no one does.
<Daviey> infinity: Erm, superm1 is concerned that there is another issue. I think it's sounding safer just to defer this.
<didrocks> Laney: the bug attached to the MP is https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1297297
<infinity> ...
<ubot2> Launchpad bug 1297297 in unity-scope-click (Ubuntu) "Click scope crash during search when going out of WiFi" [Critical,In progress]
<infinity> Daviey: Eventually, we have to call it good enough.
<cjwatson> Defer to what?
<infinity> Daviey: Fixing the critical installer failure is one thing, but some bugs just need to be SRUed later.
<cjwatson> Are you suggesting not shipping Mythbuntu at all until 14.04.1?
<didrocks> Laney: it's not in the generated changelog? (should be) want me to check?
<cjwatson> (Which would be ... new)
<Laney> didrocks: it is
<infinity> superm1: What's the "other thing"?
<didrocks> ah, phew :)
<Laney> didrocks: I'm in one team but not the other one, you see
<Daviey> infinity: installs on Nvidia seems to be crashing the installer.
<didrocks> Laney: yeah, as it's not released, I was thinking it would go to -proposed
<Laney> Basically I'm saying I don't know if I should. :P
<didrocks> Laney: and then, copied over as the rest of things there
<didrocks> (that are in -proposed)
<Laney> I guess so
<infinity> Daviey: If that's really the case, and not some odd local problem, I think we should just pull it completely and revisit the option of maybe a week-late release for Myth or something.
<Laney> I just did a test kylin install and indeed ubuntu-kylin-docs was removed
<Daviey> I think it's a total failure on time based release, but pushing out an ISO a week later seems more sensible
<popey> Daviey: i can test mythtv install on my nvidia desktop if that's any use?
<infinity> Laney: Yeah, I don't doubt that.  But it's fixable in an SRU.
<Daviey> popey: That would be useful, you can probably get it faster from http://uk.weeklybuilds.mythbuntu.org/iso/mythbuntu-12.04.3-desktop-amd64.iso
<Laney> I'm sure it is, was just making sure
 * popey wgets
<cjwatson> Oh drat
<infinity> Daviey: We're itching to release the rest of the world, so I think we need to just take a hard line here soon.
<popey> Daviey: do you have a bug which details what I need to do to reproduce this?
<Laney> Daviey: 12.04.3?
<cjwatson> 17:56 <superm1> yes lets defer
<cjwatson> 17:56 <superm1> i'm investigating another bad issue that just popped up crashing install
<cjwatson> 17:57 <superm1> infinity: w/ real nvidia HW the installer crashes on one of the pages
<cjwatson> 17:57 <superm1> it's a crash in one of our plugins
<infinity> Daviey: I'm willing to help with a leisurely late release next week, instead of panicking today.
<cjwatson> 17:58 <superm1> yes i think that would be the way to go
<infinity> superm1: Ahh, kay.  Now that Colin pasted your messages.  Yeah, I'll just pull your images, and let's sort this next week.
<superm1> ok
<infinity> superm1: Very willing to help, just not willing to help under pressure, if that's cool.
<superm1> sorry guys :(
<Daviey> Sorry for the crappy panic.
<popey> superm1: got a bug number?
<tgm4883> infinity, i'll update our wiki to direct to a page with a statement
<superm1> popey: not yet, i'll get one filed momentarily
<popey> ok
<cjwatson> OK, I have to go and we're close enough ...
<Laney> didrocks: I'll accept it and then you can get the SRU team to deal with the next bit
<Laney> how about that
<didrocks> Laney: sounds good to me
<didrocks> thanks Laney!
<didrocks> Laney: I'm not a fan of the fix FWIW
<Laney> you should find out where the leak is coming from :-)
<didrocks> but I guess it's better than not having it :p
<whiskers75> I would suggest blocking releases.ubuntu.com to the general public.
<didrocks> Laney: agreed, that's up to upstream anyway :p
<cjwatson> whiskers75: Far too late
<cjwatson> We dealt with things
<popey> Daviey: you sure about that url... 12.04..?
<Daviey> popey: Yeah, i just PM'd yopu
<DASPRiD> whiskers75, why that?
<xnox> whiskers75: no.
<mdeslaur> the trusty release notes are a bit odd in the "upgrading from Ubuntu 13.10" section
<xnox> mdeslaur: let me check.
<mdeslaur> "Open Software Sources." followed by "Press Alt+F2 and type in "update-manager" "
<infinity> superm1: Alright, Myth images pulled, that's pushing to cdimage now.
<didrocks> thanks Laney!
<xnox> mdeslaur: the way i read it, 4 ways to upgrade. Not step by step.
<xnox> mdeslaur: do you want me to change into step by step lists instead ?
<cjwatson> That's definitely not four ways to upgrade.
<xnox> mdeslaur: it did give me a "?-/" face
<cjwatson> The second to fourth are clearly a sequence.
<Naxiz> 19:02 < whiskers75> I would suggest blocking releases.ubuntu.com to the general public.
<cjwatson> It looks like a leftover.
<cjwatson> Naxiz: Please stop.
<cjwatson> It is not the time to harp on a problem from an hour or two ago
<Naxiz> sorry i pressed wrong button
<furball707> People are spamming the servers still
<mdeslaur> yeah, second to fourth look good, but the "Open Software Sources" line probably can be deleted completely
<cjwatson> mdeslaur: done
<cjwatson> maclin: fyi your release notes lock timed out
<mdeslaur> cjwatson: thanks
<cjwatson> infinity: you should be able to edit stuff now
<popey> daviey / superm1: got that bug for me? I have a usb stick booted.
<superm1> popey: 1309119
<maclin> cjwatson, sorry, I finish update now^
<popey> superm1: ta
<superm1> sure
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final | Archive: Limbo | Undulating Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<popey> superm1: any specific options or just defaults?
<superm1> popey: it will reproduce with defaults if you have nvidia hw in system
<popey> ok
<whiskers75> infinity: so it's released into the repos?
<ogra_> whiskers75, please wait for the release announcement you will clearly notice
<whiskers75> ogra_: sure, sorry. do we have any etas?
<ogra_> any minute :)
<john1999> ogra_: is ubuntu minimal gonna be released soon?
<ogra_> stgraber, do you do the copying for the phone images ?
<xnox> website will go live first.
<whiskers75> ogra_: ooh good, finally ;)
<ogra_> john1999, together with everything else
<whiskers75> what about do-release-upgrades?
<cjwatson> This isn't #ubuntu-release-party, people.  If you aren't directly involved with the release, please stop asking.
<stgraber> ogra_: copy is done, I'll do the publish now
<john1999> ogra_: ok I wasn't sure you compiled it
<ogra_> awesome !
<ogra_> didrocks, see above
<cjwatson> There'll be an announcement soon enough.
<didrocks> ogra_: saw it, ready to send emails once the official announce is done :) THanks!
<ogra_> :)
 * ogra_ pets his phone 
<didrocks> stgraber: ogra_: thanks!
<stgraber> ogra: "description": "ubuntu=20140417,device=20140411.3,version=11",
<ogra_> yay
<ogra_> so phone is live :)
<PaulW2U> away back later
 * whiskers75 claps
<tgm4883> Can someone remove Mythbuntu 14.04 from torrent.ubuntu.com ? It seems that is a valid torrent right now
<cjwatson> tgm4883: doing
<whiskers75> tgm4883: that's been discussed, I think
<tgm4883> cjwatson, thanks
<cjwatson> tgm4883: done
<cjwatson> (modulo rsync)
<cjwatson> yeah, visible
<svineet> !isitout
<ubot2> No svineet, it's not out yet. It's due out some time on the 17th :)
<svineet> ubot2 good bot. Biscuit?
<ubot2> svineet: I am only a bot, please don't think I'm intelligent :)
<bdmurray> cjwatson: is somebody handling the meta-release file or shall I?
<cjwatson> bdmurray: check with infinity whether it's OK, I was about to sign out for Easter
<cjwatson> bdmurray: you know we aren't offering it for LTS upgrades yet, right?
<cjwatson> (until .1)
<bdmurray> cjwatson: right, I remember that
<Naughx> Have a great week-end. :)
<whiskers75> What does 'Archive: Limbo' mean?
<knome> cjwatson, thanks for everything, sorry for distracting before, and have a good holiday :)
<bdmurray> infinity: shall I take care of the meta-release change?
<Guest92736> whiskers75: it means it's neither 14.10 nor 14.04
<cjwatson> It means no uploads are going to be processed for a while; the new series needs to be created before much can happen
<whiskers75> cjwatson: as in 14.04?
<tumbleweed> and then we need a name...
<cjwatson> "new series" -> the one after 14.04
<xnox> cjwatson: the website is deploying.... very very slowly.... it will be a while until it's live.
<whiskers75> cjwatson: how does it get kicked out of limbo?
<xnox> cjwatson: after that release announce will be moderated.
<cjwatson> whiskers75: https://wiki.ubuntu.com/NewReleaseCycleProcess
 * cjwatson -> gone
<jose> thank you, cjwatson
<whiskers75> ah
<popey> superm1: Daviey yeah, confirmed..
<nhaines> Thank you to everyone. :)
<superm1> popey: i've got a simple fix that avoids the crash, but there is a little more to it because the driver isn't getting installed
<superm1> popey: could you hop to #ubuntu-mythtv-dev for a moment?
<superm1> i'll chat more with you there
<xnox> we are waiting for bzr to auto-repack websites assets repository
<Laney> I had a look into the kylin-docs problem
<Laney> It's in casper's manifest-remove, probably because it's installed using apt from their hook
<julien1> ubuntu 14.04 is not yet released ?
<knome> julien1, no, and please stop asking
<AlanBell> julien1: please wait in #ubuntu-release-party, it will be announced when everything is ready
<julien1> knome: sorry asking this question on a channel named "ubuntu-release"
<julien1> AlanBell: thanks
<DASPRiD> julien1, this channel is more for release organisation than "support" :)
<julien1> DASPRiD: ok, sorry, i wait for the announce on ubuntu-release-party ;)
<Laney> The Conflicts causes issues
<xnox> website live on some frontends
<Naughx> The website was updated. :o
<knome> does it echo here?
<john1999> the minimal cd is not yet ouy?!
<john1999> *out
<xnox> website is released, announce email is out.
<whiskers75> h00k: Will this release be available through software updater?
<whiskers75> s/h00k/xnox
<xnox> whiskers75: read release announcement.
<whiskers75> xnox: where?
<xnox> https://lists.ubuntu.com/archives/ubuntu-announce/2014-April/000182.html
<john1999> xnox: please publish mini.iso too?
<xnox> john1999: it's published in the usual location.
<yofel> kubuntu too, http://cdimage.ubuntu.com/kubuntu/releases/14.04/release/ is empty
<whiskers75> xnox: curse you and your 24th release date
<slangasek> infinity, cjwatson, stgraber, xnox, everyone else: yay, well done
<DASPRiD> congratz to the release everyone
<john1999> xnox: it doesn't appear! https://help.ubuntu.com/community/Installation/MinimalCD!
<whiskers75> xnox: ;P
<whiskers75> xnox: I'm on 12.04...
<slangasek> john1999: that page is not maintained by the release team
<Laney> nice one
<john1999> slangasek: so can you give me a link to it?
<yofel> john1999: copy the 13.10 link, replace saucy with trusty and you should get it
<slangasek> john1999: I would not recommend the minimal CD to anyone for use
<mrdevries> so the daily build of last night is in fact the final LTS? just got the e-mail :) congratulations guys, really awesome job :D
<whiskers75> 'Users of 12.04 LTS will be offered the automatic upgrade when 14.04.1 LTS is released, which is scheduled for July 24th'
<whiskers75> D:
<john1999> slangasek:  sorry I use my own WM (I can't do that unless I get the mini one!)
<Naughx> http://cdimage.ubuntu.com/lubuntu/releases/14.04/release/ ... No zsync file. :(
<xnox> yofel: checking.
<john1999> slangasek: I use dynamic window manager
<xnox> john1999: mini iso is published at http://cdimage.ubuntu.com/netboot
<xnox> whiskers75: no cursing, please.
<john1999> xnox I followed yofel instructions same thing
<whiskers75> xnox: Sorry, it was meant lightly
<john1999> are u sure it's not BETA?
<xnox> whiskers75: upgrades will be enabled on july 24th.
<gman> any idea how long it takes software update to pick up 14.04?
<xnox> Naughx: investigating.
<yofel> john1999: there is always only one image per release, so even if it says beta, it's not
<xnox> gman: until 24th of july, read the release announcement.
<bdmurray> slangasek: shall I take care of the meta-release changes? I already pushed them in bzr just need to update the server
<john1999> ok yofel I'm gonna install it and DWM
<gman> ah thanks
<whiskers75> xnox: thanks
<john1999> also did u fix the keyboard bug (13.10 doesn't work with any usb keyboard on my pc)
<slangasek> bdmurray: I think it's great if you take care of the metarelease changes, thanks.  Per the discussion earlier, I believe this is to update showing 14.04 as an available upgrade only to 13.10 users, correct?
 * xnox investigating missing Kubuntu and Lubuntu download iso on the cdimage.
<Aurvandill> hello you've linke xubuntu wrong
<shadeslayer> infinity: is cdimages.ubuntu.com exploding? The ISO's seem to be in a quantum state of existence
<infinity> bdmurray: elmo wanted some warning on meta-release changes.
<xnox> shadeslayer: investigating.
<infinity> shadeslayer: Yeah, I'm hunting that down.
<shadeslayer> sometimes the link works, while it doesn't at other times
<Aurvandill> if i'm right here
<shadeslayer> ah cool, thx
<bdmurray> infinity: ?
<mvo_> infinity: oh, why (just curious)?
<john1999> slangasek: btw my Dwmbuntu is personal distro (so I won't ever publish it)
<xnox> mvo_: which bit? kubuntu? it's correct on the master server, hunting #is to see how CDN is redirecting things.
<mvo_> xnox: just the bit about meta-release changes
<infinity> mvo_: For $reasons.  Just gimme a few.
<mvo_> infinity: no problem, like I said, I'm just curious about it
<davmor2> Riddell: what's up with your download page http://cdimage.ubuntu.com/kubuntu/releases/14.04/release/
<jibel> davmor2, the release team is on it.
<shadeslayer> davmor2: Kubuntu only supports Quantum computers with quantum ISO's
<shadeslayer> ;)
<davmor2> shadeslayer: haha
<infinity> mvo_ / bdmurray: IS is working on getting some archive servers back online, please hold off on meta-release until that happens.
<shadeslayer> though yeah, /me is waiting for someone to fix that so I can publish my blog post
<bdmurray> infinity: ack
<IdleOne> Thanks for all the awesome and hard work folks :)
<mvo_> infinity: ok
<infinity> shadeslayer: We're fixing the CloudFront redirects right now.  The page will still look goofy, but downloads will magically work regardless affter that.
<shadeslayer> infinity: ah that's good enough for me
<infinity> shadeslayer: ie: if you download http://cdimage.ubuntu.com/kubuntu/releases/14.04/release/kubuntu-14.04-desktop-amd64.iso it works, even though it's not actually mirrored on the cdimage frontends yet.
<shadeslayer> oh my
<shadeslayer> infinity: that link gives me weird cloudfront things right now ;)
<infinity> shadeslayer: That's what I'd expect it to do...
<shadeslayer> ah
<infinity> shadeslayer: Or, you mean really weird?
<infinity> Oh.  403.  Whee.
<shadeslayer> infinity: http://wstaw.org/m/2014/04/17/plasma-desktopfK2166.png
<shadeslayer> that sort of looks outside-the-box-weird
<shadeslayer> I guess temporary issue
<infinity> shadeslayer: Yeah.  Noted.  Fixing.
<infinity> La la la.
<infinity> shadeslayer: Okay, cloudfront should not 403 anymore.
<apachelogger> works here anyway
<shadeslayer> yep works
<shadeslayer> thx
<slangasek> infinity: who should we coordinate with on the IS side for this?  I'm assuming you will want to be having a nice warm English beer before long, and that bdmurray should work with IS directly :)
<infinity> shadeslayer: Hopefully, the rsyncs will clear up now.
<shadeslayer> infinity: <3
<shadeslayer> apachelogger: sending off email to kubuntu-devel then
<xnox> shadeslayer: \o/
<shadeslayer> xnox: {{hugs}}
<apachelogger> shadeslayer: waaaaait
<shadeslayer> apachelogger: already done :(
<jibel> infinity, is IS fixing cdimage for other flavors?
 * apachelogger throws a keyboard and hopes the revised version was sent
<infinity> jibel: It's all being sorted.
<jibel> ta
<shadeslayer> apachelogger: did you change something in the last 10 minutes?
<Naughx> That said the torrent files and zsync files are still unavailaible on cdimage.
<apachelogger> shadeslayer: no, correct version, it's all good
<apachelogger> phew
<shadeslayer> :)
<Naughx> or maybe I'm wrong.
<shadeslayer> pft, moderated on kubuntu-users
<infinity> Naughx: We know.
<infinity> Naughx: It's being sorted.
<Naughx> Okay. :)
<rpadovani> guys, until the last release there was a start-download page that sent users to mirrors. Now I don't find that page, so our LoCo website has to send users directly to releases.ubuntu.com, and this is not optimal for your servers. What's the solution?
<slangasek> rpadovani: does 'http://www.ubuntu.com/download/desktop/thank-you/?version=14.04&architecture=amd64' not suffice?
<Naughx> Looks like everything is working fine for me. Thanks. :)
<michagogo|cloud> rpadovani: you could also look at the mirrors list and find your local one
<michagogo|cloud> (or several local ones, idk where you're located)
<michagogo|cloud> There's a list at https://launchpad.net/ubuntu/+cdmirrors
<michagogo|cloud> Though idk if that shows mirrors that aren't synced up with the release yet
<rpadovani> slangasek, better than nothing, but so I have to have different versions for derivatives and server
<rpadovani> slangasek, until last release was http://www.ubuntu.com/start-download?distro='+edition+'&bits='+arch+'&release='+release
<slangasek> rpadovani: right, if you're looking for a single consistent url we don't have that (OTOH, I don't know why we would've been trying to maintain this before for flavors?)
<rpadovani> michagogo|cloud, I prefer to use ubuntu.com mirrors, so I haven't to check if someone has been deleted
<rpadovani> slangasek, ok, thanks, I'll update scripts
<michagogo|cloud> rpadovani: Oh, sorry. I didn't read your question carefully enough.
<michagogo|cloud> For some reason I thought you were talking about a release party or something
<rpadovani> np :-)
<slangasek> zul, jamespage: how did the openstack 0-day get on?  it sounded like everything was getting in under the wire so not actually an SRU at all, is that correct?  Or is there more help you need from the release team today?
<infinity> slangasek: I think they got it all.
<slangasek> ok
<slangasek> infinity: how about my earlier question of who in IS bdmurray should sync with on meta-release?  Is it elmo, or will there be a handoff to someone more tz-friendly?
<deej> slangasek: Might as well tell elmo
<slangasek> ok
<jamespage> slangasek, its all in
<slangasek> jamespage: great :)
<jamespage> thankyou release team for pushing the updates in so late
<jamespage> (and apologies for keystone)
<Sk1d> on lubuntu do-release-upgrade does not offer you to upgrade :/
<infinity> Sk1d: Not yet.  We're fixing some infrastructure issues before we flip that switch.
<Sk1d> thx
<Sk1d> infinity: is there a roughe ETA?
<infinity> Sk1d: Not just yet.  The archive mirrors are somewhat flattened right now, and we're trying to avoid making it worse.  But soonish.
<infinity> Sk1d: There's a reason the release announce said that automatic upgrade would happen "shortly" not "immediately".
<Pici> Is there a problem with telling our users in #ubuntu to use the -d switch?
<bdmurray> Pici: well it would use the same mirrors and would make things a bit worse
<Pici> bdmurray: will hold off then.
<bdmurray> Pici: additionally the upgrade process may time / fail due to the mirror not responding
<Pici> Understood. I'd like to keep the number of systems I break today to a minimum.
<infinity> Pici: The big problem with suggesting people use -d is that when we open 14.10, that may not quite have the results you were hoping for.
<infinity> Pici: But yes, it would also be nice to not contribute to our issues while we're trying to fix things.  *shrug*
<Pici> infinity: oh, I typically tell people to stay away from -d unless they know what they are doing.
<Pici> er, I guess I deleted the words in there that make that sentence make sense... oh well.
<infinity> It made sense to me.
<guest1> anyone know if the upgrade option is going online tonight
<lxgr> will running update-manager with the "-d" flag make a permanent change to my apt configuration (i.e. download 14.10 as soon as development starts)?
<saiarcot895> lxgr: it shouldn't
<saiarcot895> guest1: Isn't upgrade already available?
<guest1> i'm not seeing any option when i do software update
<Sk1d> saiarcot895: not for lubuntu
<lxgr> saiarcot895: no: http://changelogs.ubuntu.com/meta-release
<guest1> i'm on 13.10 xubuntu though
<lxgr> this seems to be the file update-manager checks to see if there is an update
<lxgr> so i suspect (hope) that the "-d" flag only changes that to meta-release-development
<bdmurray> lxgr: that is correct or m-r-lts-dev if you are on precise
<bdmurray> guest1: yes it should be appearing tonight, they are just working on mirror issues
<xnox> infinity: ccan you drop moderation on the channel and unvoice everyone?
<Laney> moderation is off already
<infinity> bdmurray: You going to still be around in a few hours?
<xnox> Laney: ok, thanks.
<bdmurray> infinity: yeah, although if it is going to be a few I'll take a break for a bit
<knome> any reason to keep the voices?
<infinity> bdmurray: You could also give me access to the branch...
<infinity> knome: Nah, just too lazy to undo it all.
<knome> infinity, oki, will get somebody to do it :)
<bdmurray> infinity: the branch has already been updated it needs to happen on the server manually
<infinity> bdmurray: Oh.  How's that happen?
<knome> infinity, apparently there is an autovoice for all ubuntu members and canonical employees. i would think that could go even "normally"
<Pici> :/
<Laney> Wee.
<Daviey> infinity  / bdmurray: It seems *every* release, the meta-release is forgotten to be refreshed.  I haven't checked, but is it in the release checklist?
<infinity> Daviey: This is intentional.
<infinity> Daviey: Not forgotten.
<Daviey> Ah, Ok. That differs from previously then :)
<Daviey> infinity: Also posting missing on the release blog?
<infinity> Daviey: That blog has been oddly silent since Saucy A1...
<ogra_> did we ever switch meta-release before .1 ?
<ogra_> (for LTS)
<infinity> ogra_: No, not for lts->lts, but we also haven't switched it for non-lts upgrades yet, because we're sorting some infra issues.
<ogra_> ah
<superm1> mythtv and mythbuntu-casper are both in proposed now; those were the two that we needed fixed for mythbuntu's last minute fiasco.   can someone with powers respin when you get a chance so we can have another look?
<superm1> *mythbuntu-common i mean
<Riddell> superm1: don't you have access from iso.qa site?
<Riddell> I'm not sure how you'd make images using -proposed though
<superm1> i thought the images are made using proposed by default
<superm1> i don't think i have access from iso.qa site
<Laney> No
<Riddell> it probably needs some code changes to make that happen
<Laney> You want to have them released to -updates
<Riddell> doesn't that need an sru person to do?
<superm1> oh, hmm.  well that's a bit of a catch 22 then, don't they need to be validated at installation to be released to -updates?
<doko> Montreal release party now ...
<superm1> but to validate at installation they should be on the CD
<stgraber> doko: oh yeah, I need to pack my things and head there too, see you in a bit
<Laney> The release team sometimes does them around release day for issues like this
<Laney> we did some for touch earlier on
<xnox> superm1: we have ability to spin daily image with -proposed pocket enabled.
<superm1> ah i thought so
<xnox> superm1: or one can stop ubiquity, add/refresh -proposed pocket, install with proposed enabled.
<xnox> superm1: depending if it's live package or pool problem.
<superm1> that works for one of the uploads, but the other is a live package problem
<superm1> i actually already verified the fix for the mythbuntu-common one by doing that
<superm1> but the mythweb one requires a new livefs
<Laney> You might get other random stuff if you build with proposed
<xnox> Laney: true, thus we will not release the image built with proposed, just use it for testing. Then publish to updates. Then rebuild iso with -updates only. Then retest. And then finally do mythbuntu release..... Maybe this is too elaborate.
<superm1> the fixes are both very small things
<superm1> i guess whatever you guys think is the best approach here, i'll validate
<xnox> superm1: which packages  / bug # is it? and are they all in -proposed? i might be able to reconstruct the image with just those locally and test.
<Laney> You could apply the diff for the mythbuntu-common thing yourself
<superm1> xnox: yes they're both in proposed.  https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/1309084 https://bugs.launchpad.net/ubuntu/+source/mythbuntu-meta/+bug/1309119
<ubot2> Launchpad bug 1309084 in mythtv (Ubuntu) "Mythbuntu installer crashes when installing frontend only" [Medium,Confirmed]
<ubot2> Launchpad bug 1309119 in mythbuntu-common (Ubuntu Trusty) "nvidia driver installation crashes mythbuntu installer" [Critical,Fix committed]
<Laney> (without needing to rebuild I mean)
<Laney> (since it's python)
<superm1> yeah that's the one i was able to validate
<xnox> Laney: yeap. I'll try to validate both tomorrow. tired today and falling asleep... didn't sleep enough all week.
<superm1> the other one i can validate just modifying the postrm  after it's copied over but before it runs the postrm and i can verify that works too
<superm1> if that's enough validation
<Laney> The other one is more obviously right
<Laney> Someone else can make the call though as I'm also off to bed
<superm1> thanks guys
<Laney> (release them to updates, respin iso)
<Laney> see ya
<infinity> superm1: Released both of those.
<superm1> cool thanks
<bdmurray> slangasek: how do you feel about an early release of whoopsie / whoopsie-daisy fixing bug 1306175 in S and P?
<ubot2> Launchpad bug 1306175 in whoopsie (Ubuntu Saucy) "whoopsie should not send some data to daisy" [High,Fix committed] https://launchpad.net/bugs/1306175
<infinity> bdmurray: Alright, elmo's given the green light to flip the switch.
<bdmurray> infinity: got it, do you have an opinion on that whoopsie SRU for S and P?
<bdmurray> infinity: meta-release done
<infinity> superm1: If I spin you another set right now, will you test 'em soonish?
<superm1> infinity: yep i can do it tonight
<infinity> superm1: I can release them in the UK morning if I fall asleep. :P
<superm1> that would be awesome
<infinity> superm1: Spinning now.
<superm1> thanks
<teward> with the 14.04 release, has 12.10 officially EOL'd?
<infinity> superm1: http://cdimage.ubuntu.com/mythbuntu/daily-live/20140417/
<tgm4883> infinity, is that the new spin?
<infinity> superm1: Let me know if/when they look good, and we'll jimmy them into place and call it done.
<tgm4883> I'll test them now
<tgm4883> superm1, you'll still need to test on hardware if you can though. I can do it later when I get home from work on my ION box
<infinity> I won't be around to release those for you for ~8h or so, probably.
<tgm4883> infinity, so we've got plenty of time to test then ;)
<tgm4883> oh I've been unvoiced :/
<infinity> tgm4883: We removed moderation from the channel.
<superm1> tgm4883: can you check the mythweb thing in VM
<tgm4883> superm1, yea doing it now
<knome> tgm4883, you can regain the voice by cycling the channel though :P
<superm1> I'll try the nvidia on hw
<tgm4883> infinity, ah yea, just thought I was talking to myself. Testing now :)
#ubuntu-release 2014-04-18
<jose> infinity: just so you know, voice will be automatically added when people re-join the channel, it's an automagic feature
<infinity> jose: I know.  I don't have the chanserv permissions to fix that.
<jose> ok then :)
<infinity> I'll let Colin deal with it later.
<saiarcot895> Is it true that upgrading from 12.04 to 14.04 is not possible yet?
<infinity> saiarcot895: lts->lts upgrades are only turned on after the first point release.
<ogra_> you can upgrade ...
<ogra_> it isnt offered automatically yet
<saiarcot895> ah, ok
<wgrant> The release announcement even says that :)
<wgrant> LTS upgrades are enabled after the first point release, usually around three months later.
<ogra_> yeah, but who reads that
<ogra_> if infinity had just mailed "It's out dudes !!!" that would have been enough :)
<infinity> I'll keep that in mind for next time.
<ogra_> heh
<Thedemon007> i have problem with chromium of 12.04, no played youtube videos say undefined errror :S
<ogra_> Thedemon007, general support is in #ubuntu
<saiarcot895> Thedemon007: 12.04 or 14.04?
<Thedemon007> 12.04
<infinity> saiarcot895 / Thedemon007: Please take it to #ubuntu
<Thedemon007> ok
<Thedemon007>  i add a debdiff for update the package xserver-xorg-video-openchrome-lts-saucy in the bug #1205643 .. I guessed before that this is automatically updated to be updated package saucy. But apparently not the case :S
<ubot2> Launchpad bug 1205643 in xserver-xorg-video-openchrome-lts-saucy (Ubuntu) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy & 12.04.4 candidate" [Undecided,Confirmed] https://launchpad.net/bugs/1205643
<michagogo|cloud> Hm, how come the LTS point release comes out after approximately 3 months?
<michagogo|cloud> In other words, why is it getting a point release when it's the latest release, and non-LTS don't get point releases?
<infinity> michagogo|cloud: Because only LTSes get point releases.
<michagogo|cloud> Um, I realize that
<michagogo|cloud> I'm wondering about the reasoning there -- why does an LTS need a point release when a non-LTS is fine the same 3 months after release?
<infinity> michagogo|cloud: LTSes get several point releases, that's just how we do things.  It's part of making them supportable for 5 years.
<michagogo|cloud> What's different about them that they need a PR in under 6m though?
<michagogo|cloud> Meh, nvm
<infinity> michagogo|cloud: What's different about them is that they get point releases.  I suspect you'll find this becomes a circular argument very quickly. :P
<infinity> michagogo|cloud: If you're insinuating that the point releases somehow mean the LTSes are broken, that's certainly not the case.  It's that we put a lot more effort into making them supportable for the long term we've committed to.
<infinity> michagogo|cloud: Which includes spinning new installer ISOs, polishing the upgrade processes as much as we can, etc, etc.
<michagogo|cloud> Ah, I see -- so because the image isn't going to be considered obsolete 3 months later, it's worth the effort to come out with new and improved images?
<infinity> michagogo|cloud: Something like that, yes.
<infinity> michagogo|cloud: As for the timing of the first, there are two reason.  The point releases are every 6 months and staggered against regular releases so they don't collide.  And the first one is in 3mo instead of 9mo because we use that 3mo to make sure it's as polished as possible before turning on lts->lts automatic upgrades.
<michagogo|cloud> Ahhhhhh.
<michagogo|cloud> Okay, I missed the staggering part :-)
<michagogo|cloud> Sorry to bother you, thanks for helping me understand
<superm1> infinity: between tgm4883 myself and popey we gave a few times over on the mythbuntu ISO's and things look good now
<infinity> superm1: Alright, I'll push those out and call it done, then.
<infinity> superm1: Done, and pushing out to mirrors.
<superm1> Thanks
<john1999> I got 1 question about ubuntu 14.04 (I hope I'm not bothering)
<john1999> why does it use /etc/X11/XF86Config instead of /etc/X11/xorg.conf (is it a newer version or a mistake?)
<ScottK> When it gets to be time to work on toolchain for "U", doko asked me to set up ruby2.1 as default Ruby.  Please let me know when I can sync ruby2.1 from Debian.
<infinity> ScottK: When Mark says so.
<ScottK> I know we're waiting on that, but I'd imagined it'd be a bit after before the archive was set up.
<infinity> ScottK: Not much time, really.  We're just not sure when that time will happen.
<ScottK> OK.
<infinity> ScottK: Maybe this is a subtle attempt to force everyone to back away from their computers and play outside for the weekend.
<ScottK> Maybe.
<Laney> Seems to be working well
<infinity> Laney: Well, I got to sleep in, so that's something.
<Laney> Yeah, I have been playing outside, to be fair
<Laney> Now I'm off to the seaside. Tara.
<rtg> infinity, the weather in London looks reasonably nice. maybe you should be finding a pub with a view.
<infinity> rtg: It's been nice all week, actually.
<rtg> what little you've seen of it ?
<xnox> rtg: we did take a stroll by the thames a least once every day, more or less.
<bdmurray> infinity: I was looking at the release announcement and noticed that it says "Users of Ubuntu 12.10 ... will be offered an automatic upgrade to 14.04" - I'm fairly certain this isn't the case.
<infinity> bdmurray: It was what we intended to happen.  Did we not actually make that happen?
<infinity> :/
<infinity> bdmurray: Or are we doing 12.10->13.10->14.04?
<bdmurray> infinity: No, we made upgrades from 12.10 to 13.10 happen because 12.10 went EoL before 14.04
<bdmurray> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-lts-upgrade-testing
<infinity> bdmurray: Dangit.  I think maybe I argued for 12.10->14.04 and it didn't happen.  Oh well.  Release announcements can be wrong.
<infinity> bdmurray: And, to be fair, if 12.10->13.10 has been working for a while, people who do automatic upgrades won't be on 12.10 anymore to notice I was wrong. ;)
<bdmurray> infinity: Well to be fair you are right and 12.10 to 14.04 was the original plan
<bdmurray> Anyway, about that whoopsie SRU and getting it release early...
<jose> news team, if you want to modify it I can discuss if it's possible to edit the announcement post we have on the fridge
<infinity> bdmurray: In theory, given that we support P->T and Q->S, Q->T probably Just Works anyway, but it would take some testing before we could just flip the bit, so maybe not worth trying.
<infinity> bdmurray: Right, lemme look at that whoopsie.
<infinity> bdmurray: Also, for 14.04 through 16.04, I think we should be heavily testing 14.04->* and *->16.04, which makes 14.04->16.04 trivial.  Cleaning up lts->lts messes post release is a silly thing.
<knome> good idea
<knome> is the infrastructure ready for that?
<infinity> It certainly is for Ubuntu.  I'd like to scale it out to provide upgrade testing for all flavours, not sure how much of that we do currently.
<infinity> I know we do some installer testing for flavours at least, and maybe some upgrade stuff.
<knome> right, i was thinking manual testing :)
<infinity> Manual testing is really all about the people having time.  Sky's the limit on what you can achieve if you have the motivation and the lack of other things to do. :P
<knome> yes, but it must be possible first
<knome> i wouldn't imagine we would do loads of test, but we might use that for some configuration migration smoketests etc. here and there
<knome> so if non-supported release path upgrades are possible... i'd like to know how :)
<infinity> knome: Oh, I see what you mean, as in being able to trigger do-release-upgrade to pick an arbitrary target instead of what meta-release says, for instance.
<knome> yep
<infinity> So, I think the "eaisest" way to do that right now would actually just be to MitM changelogs.ubuntu.com
<infinity> But I think we can come up with a more elegant solution. :)
<knome> yep... i'm sure :)
<bdmurray> it's not actually meta-release that requires changes but the dist-upgrader tarball which meta-release points to
<bdmurray> so you could modify the release-upgrader tarball on disk and not worry about meta-release
<knome> right...
<infinity> Ahh, fair point.
<knome> but anyway... i wouldn't mind more automated testing either
<knome> what do the automated tests output currently, and would it be possible to make them save certain files after upgrades or something?
<infinity> bdmurray: I assume you don't care about the quantal one here...
<bdmurray> infinity: right, we'll stop accepting uploads from it next week(?) when it goes EoL
<jibel> knome, https://jenkins.qa.ubuntu.com/view/Upgrade/ we than stdout, the content of /var/log/dist-upgrade and the results of the post-upgrade tests
<jibel> (everything is red today because the machine on which they run went AWOL)
<knome> jibel, mhm, would it be possible to expand that list for a specific flavor test?
<infinity> jibel: It's a long weekend, it's probably spending time with family.
 * elfy read all that knome - and agrees with more automated testing 
<elfy> frankly the more we can automate for images the better given we're having such a hard time with autopilot and packages
<jibel> infinity, that or someone turned it off before leaving for easter
<jibel> knome, yes it's possible, it's fairly easy to add a profile, the project is lp:auto-upgrade-testing , although we are limited by the capacity of the lab
<knome> elfy, right, and if we can get meaningful output from the tests, we can actually benefit more from them... consider if we got some information on how config files appear after upgrade
<knome> elfy, we could practically make sure they aren't broken on upgrades
<elfy> yep
 * elfy needs to spend some time with the jenkins reports for the other tests we have - I do have links
<bdmurray> I can't accept things into trusty-proposed
<bdmurray> (<PackageUpload at 0x2b6eb456a250>, 'acceptFromQueue', 'launchpad.Edit')
<bdmurray> I got a 401: Unauthorized
<bdmurray> stgraber: is that something you can help with?
<infinity> bdmurray: I'll sort that.
<stgraber> bdmurray: ah yeah, we need to do the post-release edit-acl
<infinity> bdmurray: Should be fixed.
<infinity> stgraber: ^
<bdmurray> infinity: thanks
#ubuntu-release 2015-04-13
<ogra_> can someone approve the initramfs-tools upload above please (this is slightly urgent to unbreak a certain phone image)
<ogra_> infinity, ^^^ once you wake up ^^^
<ogra_> Laney, ^^^ ?
<ogra_> (i see you are in ubuntu-release)
<davmor2> ogra_: you'd better fix it damn you, Or I'm jumping on a plane to Germany ;)
<Laney> ogra_: I don't really understand it
<Laney> also, please make it not refer to a private bug one way or another
<ogra_> Laney, what ?= the change ?
<Laney> yes
<ogra_> if root= is set to /dev/ram on the kernel cmdline and systempart is also set we dont want /dev/ram being taken into account ...
<Laney> I can read the shell :P
<Laney> I just don't know the context well enough to review it sensibly
<ogra_> sigh
<Laney> ogra_: OK, looks sane I think, just file a public bug please
<ogra_> will do
<Laney> thx
<ogra_> Laney, new bug new luck :)
 * ogra_ hugs Laney 
<flexiondotorg> Laney, I have forked versions of Ambiance and Radiance for Ubuntu MATE call Ambinat-MATE and Radiant-MATE.
<flexiondotorg> Laney, I've aligned them with ubuntu-themes 14.04+15.04.20150410-0ubuntu1 which incorporates many bugs fixes.
<flexiondotorg> Laney, As the Ambiant-MATE and Radiant-MATE themes are only used in Ubuntu MATE do you see any obstacles for a sponsoring request once I've prepared the debdiff?
<Laney> flexiondotorg: Technically no, but why do you need to fork instead of adding rules to the regular theme?
<flexiondotorg> Laney, Perhaps in 15.10 it will be possible to unify them again. But my merge proposals when unactioned (when unofficial) last year so I had no other option.
<flexiondotorg> *went unactioned
<Laney> Did you remind anyone?
<flexiondotorg> I tried. But to be fair, I don't know all the ins and outs of sponsoring back then either.
<flexiondotorg> So, they may not have been appropriately flagged.
<Laney> flexiondotorg: I guess it's https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-themes/mate-fixes/+merge/229649 ?
<Laney> (and other things?)
<Laney> Well, could you talk to larsu first and see what his opinion is?
<Laney> Then we can decide whether to fork or unify them
<flexiondotorg> Laney, kind of. That was an MP to add essential MATE compatibility.
<flexiondotorg> Laney, In my current forks I have a one line GTK3 tweak which suits MATE but is probably not suitable for Ubuntu. It override symbolic icons with full colour icons.
<flexiondotorg> Laney, And of course the colour theme is different in Ubuntu MATE compared to Ubuntu.
<flexiondotorg> Laney, I'll be happy to discuss this for 15.10 and see what can be done to remove the duplication.
 * ogra_ tickles the publisher with a feather ... 
<rbasak> infinity: could you look at syslinux-themes-debian in trusty-proposed and utopic-proposed when you process SRU today please? It'd be nice to have this landed before Vivid's release as they fix a do-release-upgrade problem.
<rbasak> (428 people marked "affected" from previous upgrades)
 * ogra_ glares at the top right of https://jenkins.qa.ubuntu.com/job/vivid-adt-linux/lastBuild/
<ogra_> doesn anyone know why 86 desktop kernels do their adt tests on a phone ?
<ogra_> unless krillin-08 isnt a phone anymore
<ogra_> evam i reading that page wrong ?
<ogra_> bah, no ev ...
<ginggs> hi release team, would someone look at approving an FFe please? LP: #1434814
<ubot93> Launchpad bug 1434814 in beignet (Ubuntu) "FFe: Sync beignet 1.0.2-2 (universe) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/1434814
<balloons> infinity, when do you plan to create the release milestone on the image tracker? Next Monday?
<infinity> balloons: Probably Friday afternoon.
<balloons> infinity, ack ty.
<flexiondotorg> infinity, Is it bad form to subscribe ubuntu-release to bug I think I release critical?
<flexiondotorg> infinity, If so, what is the correct way to raise awareness other than the QA tracker?
<infinity> flexiondotorg: Give it a rls-v-incoming tag.
<flexiondotorg> infinity, And I won't be treading on any toes by doing that?
<flexiondotorg> infinity, Thanks. Tags added.
<coreycb> arges, hi, friendly reminder on 2014.1.4
<sil2100> Hello everyone! I'll be disabling the importer on nusakan for a moment as the every-5-min runs conflict with my image copy intents
<arges> coreycb: ah, yea sprinting at this moment, i'll take a look
<coreycb> arges, thanks
<arges> coreycb: should be good, please check
<coreycb> arges, looks good, thanks!
<wxl> Riddell: there is some reason to believe that bug 1441843 affects kubuntu, too? sgclark and Kamilion had kind of suggested as such.
<ubot93> bug 1441843 in Ubuntu CD Images "X server fails to start on post-final Beta Lubuntu Vivid desktop images in virtual machines" [High,Confirmed] https://launchpad.net/bugs/1441843
<wxl> stgraber: ypwong: darkxst: zequence: you may want to check out bug 1441843 and see if it affects you guys as well
<ubot93> bug 1441843 in Ubuntu CD Images "X server fails to start on post-final Beta Lubuntu Vivid desktop images in virtual machines" [High,Confirmed] https://launchpad.net/bugs/1441843
<stgraber> edubuntu is lts only, so not caring very much
<wxl> okie dokie :)
<wxl> what about mate, flexiondotorg? is it affected by 1441843?
<wxl> â¦because, oddly, Xubuntu is NOT affected, apparently.
<jdstrand> infinity: thanks for cathing that think-o
<jdstrand> catching
<jdstrand> jeez
<wxl> infinity: i trust recent vivid dailies for ubuntu proper has no such problems in vms?
<infinity> wxl: Fairly sure I'd have people yelling at me if Ubuntu was broken that way.
<wxl> infinity: i would suspect as such, but it's worth looking into
 * tumbleweed is a terrible release team member. Just looking at things when I get privately asked :/
<sil2100> Hello! I re-enabled the importer again
 * Riddell uploading kde frameworks 5.9
<robru> infinity: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/BootTest/job/vivid-boottest-webbrowser-app/lastBuild can I get you to poke this boottest failure through? thx
<robru> Saviq: ok silo 25 landed and I pushed the changelog fix to trunk. will sort itself out next time you do a release (I won't bother doing a new release just for a changelog fix)
<darkxst> wxl, ubuntu GNOME is booting fine in VMware 11
<wxl> darkxst: good to hear. could you double check virtualbox and then update the description of that bug in the "does not affect" section? thanks in advance :)
<infinity> robru: Retried.
<robru> infinity: thanks
<darkxst> somebody uploaded the vivid fglrx to trusty-proposed, bug 1129409
<ubot93> bug 1129409 in fglrx-installer-updates (Ubuntu Utopic) "[SRU] Nvidia and AMD graphics drivers should indicate whether they provide libcuda.so.1, libOpenCL.so.1, etc." [Undecided,Confirmed] https://launchpad.net/bugs/1129409
<darkxst> well fglrx-installer-updates
<darkxst> i suppose it was intentional, but still its broken
<wxl> infinity: can you help us get our xserver-xorg-video-* packages back? https://bugs.launchpad.net/ubuntu-cdimage/+bug/1441843
<ubot93> Launchpad bug 1441843 in Ubuntu CD Images "X server fails to start on post-final Beta Lubuntu Vivid desktop images in virtual machines" [High,Confirmed]
#ubuntu-release 2015-04-14
<infinity> wxl: Huh, I thought we found and fixed that in the last beta.  I guess we'll fix it harder.
<Saviq> robru, yup, thanks!
<rbasak> Can someone look at syslinux-themes-debian in the trusty and utopic SRU queues please? It fixes an upgrade bug so will not be particularly useful to land after Vivid's release.
<arges> /quitq/quit
<jamespage> hi release team - the ceph upload in the vivid queue is fairly critical for release - upstream are recommending that people skip 0.94 if possible
<jamespage> .1 is good tho
<bdmurray> infinity: There doesn't seem to be a vivid-updates milestone
<infinity> bdmurray: Would you like one?
<bdmurray> infinity: yes, please
<infinity> bdmurray: You have one.
<sil2100> robru: https://bugs.launchpad.net/launchpad/+bug/730321
<ubot93> Launchpad bug 730321 in Launchpad itself "Launchpad REST API does not support JSONP" [Low,Triaged]
<sil2100> robru: no movement since 2011
<infinity> wxl: I think I have a fix for the missing X drivers bug, just regenerating some metas to see if the results look sane.
<wxl> infinity: you may not need to fix anything
<debfx> there are a bunch of removal requests in the ~ubuntu-archive queue. it would be nice if someone could put aside some time to process them before release.
<DalekSec> Though adding driver-all to platform should help and be useful anyway.
<wxl> infinity: now you messed everything up XD
<cyphermox> infinity: so, you mentioned before that there was a vervet somewhere?
<elfy> cyphermox: hey there :)
<cyphermox> elfy: hey hey!
<cyphermox> and I meant to ask you something, I just don't remember what
<elfy> so you'll know what I'll be saying next ... any movement on the crash on press enter at install end
<elfy> or s/crash/die
<cyphermox> that we fixed yesterday, so I already know :)
<elfy> thingy
<elfy> \o/
<cyphermox> it was something else
<cyphermox> xubuntu-related I think
<elfy> I've been machine less for a day or so - so ...
<elfy> cyphermox: icons on desktop at install ?
<cyphermox> I don't know anymore
<elfy> :)
<cyphermox> are there missing icons?
<elfy> no - but there is a specific xfce issue, which I believe we've a fix for (affects studio)
<elfy> bug 1437180
<ubot93> bug 1437180 in xubuntu-default-settings (Ubuntu) "Desktop Icons show on the install only desktop" [Low,Confirmed] https://launchpad.net/bugs/1437180
<cyphermox> ah, really
<cyphermox> but the install-only part would be one app too much being added to ubiquity-dm
<cyphermox> the fact that xfdesktop is running...
<cyphermox> unless that's also what paints the wallpaper or something
<Ukikie> cyphermox: That's what's painting the wallpaper.
<cyphermox> Ukikie: thought so
<infinity> wxl: Eh?
<infinity> wxl: I already fixed things last night to a certain extent, and was just tying up loose ends today.  What did I "mess up"?
<wxl> infinity: adding to recommends doesn't fix the problem since lubuntu doesn't follow recommends and your fix supercedes the one that gilir did that would actually fix the problem
<wxl> â¦as you can see on the bug report
<wxl> infinity: oh nevermind i see you cleaned it up :)
#ubuntu-release 2015-04-15
<RAOF> Do we have any way of surfacing the autopkgtest failures for people's SRUs?
<rbasak> RAOF: what are you asking for beyond what the links in http://people.canonical.com/~ubuntu-archive/pending-sru.html provide?
<RAOF> rbasak: I'm wondering whether the uploader of those SRUs gets notified.
<rbasak> Oh, I see.
<RAOF> Because there are a *bunch* of SRUs that would otherwise be releasable, but which have autopkgtest regressions associated with them.
<rbasak> The failures come from the Jenkins end, so maybe they do.
<RAOF> And I 'aint gonna be releasing those :)
<rbasak> RAOF: while you're looking at SRU, mind looking at syslinux-themes-debian in trusty and utopic please? It's trivial, and I'd like them in -updates before Vivid is released.
<RAOF> rbasak: Sure!
<rbasak> Thanks! I care more than average because it's an upgrade bug and needs to be fixed in the "from" release to have any effect. So if it's after Vivid, there will be a whole load more people affected.
<RAOF> Well, that's cute.
<RAOF> Someone's signed up to Launchpad with an address that replies to every email with âplease click this link to prove you're not a spammerâ in French.
<tjaalton> infinity: hey, should I push lts-vivid xorg bits? libdrm and xtrans are already waiting in the queue
<rbasak> I'm a bit confused as to why bug 1042511 didn't get a verification-needed tag when ROAF accepted it. But it's verification-done now anyway.
<rbasak> s/ROAF/RAOF/
<ubot93> bug 1042511 in syslinux-themes-debian (Debian) "postrm fails when syslinux-themes-debian is removed after extlinux has been removed" [Unknown,New] https://launchpad.net/bugs/1042511
<jamespage> hi release team - we're just putting rc1 of openstack kilo through testing - all updates should be uploaded by eod
<Laney> bdmurray: Shouldn't we use a buildX version for python-apt to have it autosynced next time?
<bdmurray> Laney: yeah, that'd make sense
<Laney> Righto
<infinity> tjaalton: Get it all staged, but don't push it to the queue until after release, IMO.
<tjaalton> infinity: that's thursday next week? sounds fine
<tjaalton> first cut is staged on canonical-x ppa already, put there by mlankhorst. mesa got updated in the meantime but rest should be fine
<infinity> tjaalton: You can always do upgrade and stack-swap testing before you push, of course.
<tjaalton> sure
<infinity> tjaalton: Since, historically, Maaarten did that a few months later, it seems, and we panicked to fix it all before the point release. :P
<tjaalton> yeah and cert team needs it quickly, skylake testing is pretty pointless without mesa, -intel even though they have the kernel already
<tjaalton> so i'll make sure it's working properly by end of next week
<infinity> tjaalton: Awesome, thanks.
<ScottK> jamespage: Looking at the stack of new dependency requirements for OpenStack Kilo "Release Candidate" 1, I am left wondering how you get to RC and don't know what your dependencies are.  It would help a lot on the stack of dependency FFe's your team is filing if the FFe listed the rdepends and which of those rdepends are part of OpenStack and which ones aren't.
<zequence> infinity: I'm going to need to refresh our meta and resping our ISO before tomorrow
<zequence> I'm testing it now. Bug 1444535
<ubot93> bug 1444535 in Ubuntu Studio "ubuntustudio-audio-core package missing in meta source" [Undecided,New] https://launchpad.net/bugs/1444535
<zequence> infinity: I've uploaded the meta, but it needs to be okayed.
<sil2100> infinity: hey! libgit2 is in the unapproved queue right now, I would need it in -proposed so that we can unblock the whole tranistion
<zul> ScottK:  they are all dependencies for openstack
<zul> ScottK:  they shouldnt affect packages outside of openstack, ie python-stevedore bump is needed otherwise openstack wont build, the oslo.* namespaces are only used by openstack as well
<infinity> sil2100: I'll look at it.
<sil2100> infinity: thanks o/
<jamespage> ScottK, those are all packages under the openstack namespace upstream - so its not un-anticipated that upstream may rev minimum versions of what in effect are internal dependencies between final beta and rc
<ScottK> jamespage: OK.  I find it surprising to modify dependency requirements post beta freeze, but every project is different.  In any case, an explicit statement that there are no non-OpenStack rdepends would be helpful.
<jamespage> zul: ^^ please can you check and update the bug reports please - ta
<zul> jamespage:  ack
<infinity> zequence: I don't see your meta upload...
<zequence> infinity: No?
<infinity> zequence: Did you sign it? :P
<zequence> infinity: Now that you say that, I might not have
<zequence> infinity: Should I bump it and do a new upload?
<zequence> infinity: Actually, I did an upload to my ppa to test it, and that went fine.
<zequence> lp:ubuntu/ubuntustudio-meta ?
<zequence> infinity: I'm going to need to hit the sack in a few moments. Will be around again in 6-7h. If there's anything I can do now, I'll do it, otherwise, I'll be back tomorrow. Sorry to catch this so late.
<infinity> zequence: Sorry, wasn't watching IRC.
<infinity> zequence: You can just sign and reupload, no need to bump the version.
<infinity> zequence: Or I can just upload your meta for you, since I just updated it here.
<infinity> zequence: Err, except that my update here found no changes...
<infinity> zequence: So, now I'm unsure what you're changing.
<infinity> zequence: Oh, I see what you did.  Yeah, I'll grab the bzr branch, refresh, and upload.
<infinity> bdmurray: Did you never reupload update-manager with that test dep fix?
<infinity> ScottK: Were you taking care of badgering the server team about the openstack/python vomit in the queue?  Backscroll seemed to imply you were.
<ScottK> infinity: Taking care of is a bit strong.
<ScottK> I was at least trying to prod them in the right direction.
<infinity> ScottK: Prodding, badgering, potayto, potahto.
#ubuntu-release 2015-04-16
<tumbleweed> I'll sync distro-info-data 0.26 in the morning (it's not registered in LP yet) but we really need a w-series name...
<Ukikie> Just go with Wombat.
<zequence> infinity: Thank you :)
<tjaalton> could someone ack this ^
<tjaalton> already tested by cert team
<tjaalton> I could do that myself but..
<zequence> infinity: I see it in the upload queue together with openstack. I can test it during the hours to come, so I'm available if needed.
<RAOF> tjaalton: It'd be good if you didn't accept that, because it had a malformed bug reference in the changelog :){
<tjaalton> bah :)
<tjaalton> reuploaded!
<RAOF> Now to wait for LP to process all the things and then I'll re-review :)
<tjaalton> right, thanks
<RAOF> tjaalton: Wait, is that actually correct?
<RAOF> tjaalton: The first hunk of the patch replaces an OUT_BATCH64 with OUT_BATCH64.
<RAOF> Although I guess it *does* add a comment :)
<RAOF> tjaalton: Accepted.
<tjaalton> heh, yeah
<tjaalton> fixed my gt3 as well
<RAOF> Woo!
<RAOF> I should apitrace Cities: Skylines. Intel *very nearly* renders it correctly.
<tjaalton> I'm afraid to try that out.. either it takes all my free time or it'd disappoint me
<RAOF> I don't think it'd disappoint, but I haven't played all that much yet :)
<tjaalton> I haven't finished my first CivV campaign that I started last year :)
<tjaalton> and HL2 has a strange bug where it loses all lighting at some point, the textures look bright and dull after that hits, so I stopped playing that too in hoping that the bug would get fixed later
<infinity> zequence: Oh, bah.  Accepted from NEW now, sorry.  Was out all night.
<jamespag`> ScottK, infinity: as zul did not get it done yesterday, I've reviewed the reverse-depends on the updates openstack dependencies for rc1
<jamespag`> the only one with anything outside of openstack is stevedore - looking at the two packages impacted now
<jamespag`> I've updated the bug reports with that detail and what testing we have done in PPA.
<jamespag`> I'm not intending on raising FFe bugs for the openstack projects themselves as I believe that the agreement we had on the mailing list to land RC's prior to release still stands
<LocutusOfBorg1> can anybody please process fglrx-*/trusty?
<mdeslaur> infinity, rbasak: oracle released their april security thingy. We need to update to 5.6.24. Is doing that now a possibility, or should we wait for a 0-day security update?
<mdeslaur> (mysql)
<mdeslaur> I gather updating a week before release would be insane, just want other's opinions
<rbasak> I'm fine with it from a server team perspective.
<rbasak> Whether it hits the security pocket before or after makes little difference to me from a regression point of view.
<rbasak> I guess it's just an issue of how it affects the images? infinity?
<zequence> infinity: What did do wrong last time? I forgot to add one dependency to one of the packages in the meta source. I'll need to add it and do another upload. Sorry for being so stupid.
<infinity> mdeslaur: If the testsuite passes and libmysqlclient symbols look sane, etc, I'm not generally opposed to it.
<mdeslaur> infinity: ok, thanks.
<infinity> zequence: No idea what you did wrong last time, since it never hit the queue.  But that tends to point to you possibly having not signed it.
<ScottK> ppp upload is a simple fix for a buffer overflow that can cause remote DoS.
<zequence> infinity: Ok, thanks
<jamespage> ScottK, hey - so I think I've annotated the FFe bugs for openstack dependencies with what you requested - specifically testing of the two reverse-depends on stevedore which are outside of the openstack project set
<ScottK> jamespage: I saw.  Thanks.  I was planning on taking a look at that in just a bit.
<jamespage> ScottK, awesome - much appreciated
<ScottK> jamespage: Would you do me a favor and run the change in the python virtualenv rdepend by barry?  He's been taking a lot of heat lately on getting that stuff working right and I'd really hate to accidentally undercut him.
<jamespage> ScottK, ack - will do
<jamespage> ScottK, when I can find him at least
<elfy> infinity: given that hopefully tomorrow we get RC images ... I am seeing something like bug1259525 again
<elfy> if I boot in kvm rather than vbox I get the same plus http://i.imgur.com/F2UKnm5.png
<Mirv> arges: thanks for trusty + utopic SRU handling
<ScottK> jamespage: Actually, nevermind.  I was thinking of the actual virtualenv, not the wrapper.
<ScottK> jamespage: All approved.
<arges> Mirv: np
<sil2100> Hello release team! I'm disabling the auto-importer on system-image once the current run finishes
<sil2100> I'll re-enable it instantly once I copy touch images to the stable channel
<ogra_> wheee !
 * sil2100 always gets interrupted by the import-images lock recently
<ogra_> yeah, snappy really keeps it busy
<ogra_> they should get their own server :P
<jamespage> ScottK, thanks - they are all in the queue if you feel like pressing the button :-)
<sil2100> ...aaand the image-importer is now re-enabled
<ogra_> yipiie
<sil2100> ...aaand disabled for a few more minutes, sorry for that
<sil2100> I need to do one more set of copies
<wxl> cyphermox: i'll kill ppc. we're lts only on it anyways.
<cyphermox> wait, it's till running
<wxl> oh wait
<wxl> i can't
<cyphermox> it looks like it should finish eventually
<cyphermox> (logs changed)
<wxl> ah k
<wxl> yeah it's at the end, too, no?
<wxl> built
<cyphermox> yeah
<cyphermox> well, I'm still unsure how the xubuntu user gets created on images, I can't seem to find the code for it
<wxl> have you looked at the logs to see what updated?
<cyphermox> wxl: what do you mean?
<cyphermox> brb, lunch
<mdeslaur> infinity, rbasak: ^ new mysql with minimal rules file changes to fix ftbfs. Symbols haven't changed, and I upgraded a wordpress install to test.
<wxl> sorry i mean you could compare manifests cyphermox
<ianorlin> hmm I sort of wish there was like a tool that showed diffs of manifests
<wxl> probably wouldn't be too hard to create
<wxl> AHEM :)
<Odd_Bloke> ianorlin: https://code.launchpad.net/~utlemming/+junk/mfdiff might help.
<zequence> infinity: Ok, think I got it right this time for the meta package. Uploaded and awaiting approval.
 * wxl sighs. 
<wxl> i want my isos already
 * wxl wonders when he should start freaking out that his ISOs will enver hsow up?
<cjwatson> it's taking longer than usual because there was a bug that caused cdimage's mirror not to have synced, so now that I've cleared that it's catching up
<wxl> thx cjwatson
<cjwatson> but it is making progress now
<cyphermox> wxl: ok, I broke many things, didn't notice an issue in a user-setup merge proposal. mea culpa.
<tjaalton> could someone check the trusty backports of libdrm & xtrans? they're needed for the vivid stack
<tjaalton> been on sru queue for a while
<infinity> mdeslaur: Do you know for sure that sneaking that -fPIC change in won't break anything?
<mdeslaur> one sec, I think it wa there before
<mdeslaur> infinity: it seems to be there in the old build log: https://launchpadlibrarian.net/201609382/buildlog_ubuntu-vivid-amd64.mysql-5.6_5.6.23-1~exp1~ubuntu5_BUILDING.txt.gz
<mdeslaur> infinity: we used to build it without and with, but I believe at some point mysql defaulted to it
<mdeslaur> which explains why debian killed it in git
<infinity> mdeslaur: mdeslaur Erm, you and I are reading this log differently...
<mdeslaur> infinity: I'm not very convincing, but that's the best I got :)
<mdeslaur> infinity: oh, how so?
<mdeslaur> for example: cd /build/buildd/mysql-5.6-5.6.23/builddir/extra/yassl && /usr/bin/x86_64-linux-gnu-g++   -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -Dget_tty_password=yassl_mysql_get_tty_password -Dget_tty_password_ext=yassl_mysql_get_tty_password_ext -O3 -DBIG_JOINS=1 -felide-constructors -fno-exceptions -fpermissive -fno-rtti  -fno-strict-aliasing  -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -I/build/buildd/m
<mdeslaur> ysql-5.6-5.6.23/builddir/include -I/build/buildd/mysql-5.6-5.6.23/include -I/build/buildd/mysql-5.6-5.6.23/extra/yassl/include -I/build/buildd/mysql-5.6-5.6.23/extra/yassl/taocrypt/include -I/build/buildd/mysql-5.6-5.6.23/extra/yassl/taocrypt/mySTL    -DHAVE_YASSL -DYASSL_PREFIX -DHAVE_OPENSSL -DMULTI_THREADED -fPIC -fvisibility=hidden -o CMakeFiles/yassl.dir/src/buffer.cpp.o -c /build/buildd/mysql-5.6-5.6.23/extra/yassl/src/buffer.cpp
<mdeslaur> it's in builddir, not builddir-pic and i's got -fPIC
<infinity> Hrm.  The first one I looked at was build/buildd/mysql-5.6-5.6.23/scripts/comp_sql.c which is PIC/non-PIC based on builddir.
<rbasak> I think there was some talk of changing something around that in Debian, if that's what you're saying. Eliminating one of them I think
<rbasak> what you're seeing
<mdeslaur> infinity: ah, yes, I see your example now
<mdeslaur> hrm
<infinity> mdeslaur: So, I dunno.  I'm down with "it should be PIC" being the correct position, but less convinced that we have time to validate that it won't regress something.
<mdeslaur> infinity: ok, reject it, I'll try and fix the ftbfs in another way
<infinity> mdeslaur: Especially given MySQL's history of playing fast and loose with compiler/linker bugs/quiks.
<infinity> s/quiks/quirks/
<mdeslaur> yeah
<wxl> cyphermox: so tl;dr everything's all messed up? :)
<cyphermox> wxl: tl;dr everything's messed up because of a stray '\'
<wxl> cyphermox: oh jeez. so fix uploading, request a rebuild later?
<cyphermox> wxl: fix was uploaded
<wxl> ah cool i'll get a rebuidl going cyphermox. what package was updated to which version?
<cyphermox> just waiting for user-setup to finish transitioning to release
<cyphermox> wxl: maybe wait a bit before requesting a rebuild, let's check if other builds are still catching up
<wxl> okie dokie
<wxl> a little error in an uplaod, Captonjamason
<wxl> one little out of place '\'
<wxl> always the stupid stuff :)
<infinity> cyphermox: Does ubiquity not need a rebuild too, or is user-setup not imported?
<wxl> fix is uploaded, just waiting on everything to sync u p
<cyphermox> infinity: it does
<cyphermox> I was wiating for user-setup to finish making it so I can do an upload
<cyphermox> (with other small changes for efi)
<cyphermox> but a new ubiquity isn't required to get user-setup to create the user in casper's scripts
<cyphermox> infinity: fwiw; changes are the following: http://paste.ubuntu.com/10834692/
<cyphermox> it would introduce a new button string that will need to be translated eventually, but I'm trying to make the whole question and process less confusing
<infinity> cyphermox: Yeah, that's not ideal, but it's probably better than the bug.
<cyphermox> this would conclude my playing with efi for now, hopefully
<jamespage> it would be nice if the openstack rc1 updates could be accepted into vivid please - the FFe's where acked earlier for the updates to dependencies
<infinity> jamespage: Yeah, getting to it.  I've done a few.
<jamespage> infinity, awesome thanks - I'll stop pestering then
 * jamespage shuts up and goes back to landing charm changes
<wxl> cyphermox: you just going to trigger a global rebuild when everything syncs up? seems like you'll have ot
<infinity> wxl: Everything is still cronned right now anyway.
<wxl> infinity: ah, so i should expect to wait until tomorrow then?
<infinity> wxl: Yeah, or you can trigger a new daily yourself.
<wxl> infinity: everything's sync'd up though, or should i wait some more?
<elfy> triggered
<cyphermox> now that I got interwebz again, I'll be able to upload ubiquity
<infinity> wxl: You should wait for cyphermox's ubiquity to hit the release pocket.
<infinity> elfy: Ditto.
<cyphermox> wxl: fwiw, I don't have access to trigger rebuilds.
<wxl> okie dokie thx infinity
<cyphermox> (at least, not that I know)
<infinity> cyphermox: You don't.
<cyphermox> except for touch
<wxl> cyphermox: no probs. just let me know when ubiquity's up and i'll trigger lubuntu
<wxl> thanks for the quick fix btw :)
<elfy> infinity: and in 12 hours= ~I'll trigger again
<infinity> elfy: Your daily might happen by then too.
<infinity> elfy: I'm not turning off cron until tomorrow night.
<elfy> infinity: ack
<wxl> oh hark :)
<elfy> we do tend to build ~10/11UTC
<cyphermox> wxl: ^ that doesn't mean it's in yet.
<wxl> cyphermox: i know, but it's in the queue
<cyphermox> yeah
<cyphermox> provided infinity doesn't reject it because I'm fr_CA :D
<wxl> hahahah
<wxl> quÃ©bÃ©cois?
<cyphermox> yes
<wxl> wonderful
 * cyphermox goes to translate that new string
<cyphermox> well, I would, later
<wxl> now that we have an accept, i just need to wait for the approve no?
<cyphermox> flexiondotorg: you around, by any chance?
<cyphermox> infinity: what's the bug number for the debconf passthrough thing for update-manager?
<infinity> cyphermox: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1434547
<ubot93> Launchpad bug 1434547 in glibc (Ubuntu) "package libc6 2.21-0ubuntu1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [High,Confirmed]
<infinity> cyphermox: And many duplicates filed on many packages that use debconf.
<cyphermox> interesting.
<infinity> cyphermox: Should be reproducible just upgrading an empty package with a single template and a db_go, I'd guess, but I haven't built such a simple package yet.
<cyphermox> that's the one that can't easily be bisected for upgrades?
<cyphermox> hmm
<cyphermox> infinity: upgrade, so I need to make two of the simplest test ever?
<infinity> cyphermox: Well, unless you can figure out how to make update-manager install a package.
<infinity> cyphermox: Given that its entire raison d'etre is upgrading...
<cyphermox> I would rather limit variables to the minimal
<cyphermox> so, no
<cyphermox> oh, but I guess I could fudge ubuntu-desktop to install a new package.
* stgraber changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Beta 2 | Archive: Final Freeze | Vivid Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<stgraber> infinity: there should be an e-mail in ubuntu-devel-discuss mod queue for you
<stgraber> s/discuss/announce/
<infinity> stgraber: Accepted.
<stgraber> ignore the odd armel and armhf ones up there, fixed
<stgraber> infinity: QA tracker is ready, all we'll have to do tomorrow is turn off cron, flip the auto-publish switch in the UI and then do a mass rebuild
<infinity> stgraber: Huzzah.
<wxl> try to hold back your excitement, infinity ;)
#ubuntu-release 2015-04-17
<mdeslaur> infinity: ok, new mysql, no big changes this time
<tjaalton> RAOF: if you're available I've got another -intel patch to get in pronto.. :)
<RAOF> tjaalton: Shoot.
<tjaalton> oh good, I'll build it first just in case, but it's bug 1445221
<ubot93> bug 1445221 in xserver-xorg-video-intel (Ubuntu Trusty) "[BSW] Backport fixes to solve promotion video playback issue" [High,In progress] https://launchpad.net/bugs/1445221
<tjaalton> there's also xtrans and libdrm for trusty in the queue, needed for the lts-vivid stack
<tjaalton> those are backports as before
<tjaalton> yeah -intel is fine, uploading
<tjaalton> RAOF: ^ in case you missed all that
<RAOF> tjaalton: I got it.
<RAOF> tjaalton: Would you kindly reupload with the previous SRU's changlog in the source?
<tjaalton> ok :)
<tjaalton> in 1.6
<tjaalton> ?
<tjaalton> or changes
<RAOF> Bah, I meant changes of course.
<RAOF> :)
<tjaalton> sure thing
<RAOF> Because we need all the bugs to appear on pending-sru :)
<tjaalton> right, was wondering about that
<tjaalton> so this was the usecase
<tjaalton> uploaded
<RAOF> And now waiting for LP to catch up.
<RAOF> Yeah, you need all the changes in -proposed to be in the .changes file, for two reasons: (1) So that we display an appropriate changelog in the software updater, and (2) so that all the SRU bugs get tracked
<tjaalton> makes sense
<RAOF> It occurs to me that I've been lax in reviewing your bug descriptions :)
<RAOF> tjaalton: Also, that seems to disable vsync on VallyView, too?
<RAOF> Although now that I look at the code more a bit more, it's replacing a return false with an extra stack frame, a couple of variable assignments, and a return false. So OK I guess.
<tjaalton> RAOF: yeah, thanks again
<Odd_Bloke> ianorlin: Further to what I mentioned yesterday, https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/mfdiff is the version that we use to produce the diffs on cloud-images.ubuntu.com.
<jamespage> -queuebot/#ubuntu-release- Unapproved: neutron-fwaas (vivid-proposed/main) [2015.1~b3-0ubuntu1 => 2015.1~rc1-0ubuntu1] (no packageset)
<jamespage> that makes no sense - its in main
<Laney> which bit?
<jamespage> Laney, its in main, but is in no packageset
<jamespage> that went through on auto right?
<Laney> jamespage: It's not automated; I just ran the script and now it's in ubuntu-server
<Laney> sorry for the delay - embarked on an epic yak shave before I actually ran it... :)
<Laney> (I do want to get this automated in the near future)
<jamespage> Laney, ah - ok - thankis!
<smoser> anyone able to take a look at my cloud-init upload ?
<smoser> wow, thank you queuebot
<infinity> smoser: It was me, not queuebot. :P
<smoser> well, i'm not thanking you, infinity
<smoser> :-)~
<infinity> smoser: </3
 * smoser is impressed with infinities emoticon knowledge.
<stgraber> hmm, why do we have langpacks in NEW? previously removed ones?
<infinity> stgraber: langpacks get new bits all the time.
<stgraber> infinity: well, those are new sources with a diff, so that's what seemed a bit odd
#ubuntu-release 2015-04-18
<elfy> if anyone with access to the tracker happens to notice this over the weekend - the upgrade tests for Vivid Final are pointing to 20150416 instead of 17.1
<cjwatson> elfy: Upgrade tests are usually set to refer to a date rather than an image, since upgrading is about the state of the archive not the state of images.
<elfy> cjwatson: ok cool - thanks
#ubuntu-release 2016-04-18
<slangasek> xnox: why exactly does doko what unity on s390x for running openjdk tests?  That's not what we're using to run openjdk tests on other architectures
<bzoltan_> xnox: doko: do you know anybody who could terminate a hanging autopkg test? This one os "running" for ages and blocks the package https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html
<infinity> bzoltan_: You might want pitti.
<slangasek> it's probably already lost and just needs one of us to retry it
<bzoltan_> infinity: Yes, last time he helped with the same problem
<slangasek> which infinity or I could do
<bzoltan_> slangasek:  that was exactly the case last time too
<bzoltan_> slangasek: \o/ please :) do
<slangasek> just requires me to figure out the syntax
<bzoltan_> Mirv:  do you know the syntax by head? ^
<slangasek> bzoltan_: I may or may not have triggered it
<slangasek> using something like 'run-autopkgtest -s xenial -a amd64 --trigger=ubuntu-ui-toolkit/1.3.1938+16.04.20160416 --ppa ci-train-ppa-service/landing-050 ubuntuone-credentials'
<bzoltan_> slangasek:  Thank you ... let's see
<Mirv> bzoltan_: no, sorry
<Mirv> slangasek: bzoltan_: seems to be running, thanks! http://autopkgtest.ubuntu.com/running.shtml#pkg-ubuntuone-credentials
<slangasek> I was sure it would run, I'm just not sure the results will go to the right place :)
<slangasek> doko: dude, seriously, why are you making nux build on s390x?  This package is not supportable there and now the unity team are stuck supporting it
<Logan> slangasek: because System x is the future, duh ;P
<Logan> er, z
<Logan> I should stop getting my IBM product lines confused
<Logan> (but actually, I don't see why a FTBFS on a new port means that it's something that has to be fixed - I thought the philosophy is usually to allow things to FTBFS rather than obscuring their build problems on ports)
<slangasek> Logan: yes; there was discussion up-scroll about wanting it for unity and wanting unity for openjdk testing.  This is not a sufficient reason to leave the desktop team holding the bag for this build
<slangasek> especially when unity will not meaningfully work on this architecture
<Logan> gotcha, I can see why that would be a problem
<Logan> I'm not going to try and figure out why you need a desktop environment to run OpenJDK tests
<slangasek> because there are graphical bits as part of the java classes
<Logan> oh yeah true. Swing and all that fun stuff
 * Kamilion scratches his head... why would you need a desktop environment to run the openjdk tests? Shouldn't a bare xserver with perhaps a window manager be sufficent?
<slangasek> yes
<slangasek> ;)
<Kamilion> incendenally, whom do i talk to about driver issues in that GUI stack? I've been having problems getting anything but xorg and xfce/lxde to work on ATI Rage XLs and Matrox G200s
<infinity> I'm amazed you can get anything to work on a G200 anymore.
<infinity> Or an old Rage...
<Kamilion> They're pretty common... Almost every supermicro board has one or the other.
<infinity> Oh, right, they still put them in server boards.  Ugh.
<Kamilion> generally as an ASPEED AST2100/2400 or Nuvoton
<infinity> I would have hoped that would die by now with Intel and AMD both having modern onboard graphics options.
<Kamilion> most of my dells also have the ASPEED
<infinity> That said, server boards are also not the target market for most desktop environments.
<infinity> Anyhow, I'm not sure how good the response or carefactor will be, but if the drivers are lacking, I'd suggest talking to upstream mesa/xorg.
<Kamilion> it's a little htpc actually
<Kamilion> well, the one I've got in front of me at the moment
<infinity> Most distros aren't going to deeply care.  If your server board can produce a suitable console for servery things, anything fancy you want to do might get you a response of "well, you have PCI/AGP/PCIe slots, right?  Buy a real video card".
<Kamilion> http://www.supermicro.com/products/chassis/Mini-ITX/101/SC101s.cfm
<Kamilion> it's got minipci
<Kamilion> so I guess I could cobble together some crazy chinese adapter
<Kamilion> one of those bitcoin PCI express extension cables
<infinity> I wouldn't call that an htpc, just a mini server.
<infinity> The "T" in htpc implies video capabilites that aren't 15 years in the past.
<Kamilion> that's just the VGA port
<Kamilion> the hdmi port is connected to the AMD chipset on that one
<Kamilion> ._.
<infinity> Ahh.  Well, that would be much less crap indeed.
<Kamilion> and I have no real problems playing back video on either the ATI or the matrox
<Kamilion> I've been mostly hanging around the lubuntu crowd because 'thats what works'
<infinity> I'd expect using the ATI video would work for pretty much all the desktops we ship.
<infinity> The G200 will be very hit and miss with compositors.
<Kamilion> and flexiondotorg was nice enough to make some lubuntu builds for the raspberry pi2s, and that worked REALLY well, it suprised me at how much faster I could drag windows around, lol
<infinity> It used to have the best OpenGL stack in the free software world, but that was literally more than a decade ago.
<Kamilion> yeah, that's what struck me as strange, both report opengl 1.1
<Kamilion> and glxgears goes at 600-1000 FPS
<Kamilion> and yet dragging windows around feels like sandpaper on bare skin
<infinity> glxgears is not a benchmark. :P
<Kamilion> yeah, but if it was in software it generally doesn't go over about 100-200ish when bound to a single core
<Kamilion> anotherwords "I know I have hardware acceleration on"
<infinity> Yeah, but that doesn't mean you have all the hardware accel you need for a modern compositor.
 * Kamilion nods
<infinity> The G200 is stuck deeply in the past.
<Kamilion> the ATI lacks hardware texture and lighting I think
<infinity> Partially because no one cares, partially because it's a 15yo part, and there's only so much you can do to make OpenGL 1.4 extension work on hardware that was designed for 1.1
<Kamilion> yeah.
<Kamilion> I'm itching to read http://lwn.net/Articles/683320/ but my LWN sub expired
<Kamilion> i would love to see these BMCs die a horrible insecure death
<Kamilion> most of them are just glorified framebuffer to VNC scrapers
<Logan> looks like your wish will be granted in three days
<Logan> to read the article, I should clarify
<Kamilion> or I could just resubscribe, I'm just busylazy
<Kamilion> or I could go bug a friend to 'send me a free link'
<Logan> also yeah, your followup question about a DE for tests was kinda what I was going for earlier
<Logan> but I don't know enough about programmatically testing GUIs
<Kamilion> yeah,  I figured it had some integration features which needed a pass/fail too
<Kamilion> there's lots more than just ICCWM these days I guess
<Kamilion> anyway, I'll shaddap and let this return to bot notices and proper release traffic
<Logan> there are lots of references in this conversation that predate me
<Kamilion> Logan: hardware has a longer tail than most people realize sometimes
<Kamilion> http://www.supermicro.com/solutions/IPMI.cfm   <-- Even the latest server management chips still use 10+ year old GPU cores, which is the crux of the conversation
<Kamilion> generally with their linux firmware on an unsecured SPI bus on a 16MB (128mbit) flash chip
<Kamilion> oh, right, keep forgetting this is wrong place for chatting. *foreheadslap*
<Logan> yeah, IPMI always has seemed like a scary backdoor to me
<pitti> infinity: looking into the two missing packs
<pitti> doko, slangasek: right, I thought of "embedded perl" as of something that gets copied/statically linked, but this isn't the case, so demotion is fine
<pitti> bzoltan_: whatever it was, s://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html is all good now
<slangasek> pitti: yeah I retriggered it successfully
<pitti> ah, thanks
<pitti> need to find out what that was
<mvo> if there is a chance it would be great if someone could look at the latest snapd upload, relatively small but import fix for the auth handling
<infinity> mvo: Looking.
 * mvo hugs infinity
<xnox> Good morning
 * xnox looks around blue fin like a confused John Travolta
<infinity> xnox: Start time is 9ish, not 8ish. :P
<infinity> xnox: But go on being confused.  I'll be there soon.
<xnox> infinity, i was hoping you are jet lagged, or something.
<xnox> =)
<xnox> infinity, plus it would take me twice the time commuting to get in for 9. so it's either 8 or 10 for me =)
<xnox> had breakfast upstairs, nom nom =)
<infinity> xnox: I'm jet-lagged indeed, I've been up since 4am.  Just didn't feel like hitting the office early.
<xnox> infinity, ouch =/
 * xnox should not ask why oxide-qt source package is larger than a server iso
 * xnox gueses it has Chrome OS + Full Qt forks
<smb> Oh they got real people in for release? I thought that was so 2014
<rbasak> infinity: welcome to this time zone!
<smb> rbasak, I guess physical time zone. who knows which one his mind still is :)
<infinity> smb: No one knows that, lease of all me.
<infinity> s/lease/least/
<smb> infinity, yeah I can imagine that. and I would only switch a fraction the times you do
<xnox> slangasek, cjwatson - would you look at debian-cd bundle (which is against the right branch...) on bug #1565889
<ubot5`> Error: Launchpad bug 1565889 could not be found
<xnox> https://bugs.launchpad.net/bugs/1565889
<flexiondotorg> Morning
<cjwatson> xnox: do you see where Steve said "the branch has been updated"?
<cjwatson> xnox: i.e. nothing to do
<xnox> yeah
<xnox> slangasek, sorry about it.
<pitti> infinity: ok, all langpacks in excuses now have landed
<infinity> pitti: Lovely.  You found the missing ones? :P
<pitti> yeah, reuploaded them
<infinity> pitti: Ta.
<pitti> I understand syncing from Debian is still broken due to some dak changes, hmm
<pitti> fakesync it is then
<bzoltan_> pitti: do you  see if that click-update-manager:i386 test really running? https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-050/excuses.html
<rbasak> infinity: https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-5.7/+sourcepub/6314843/+listing-archive-extra for trafficserver. That's no worse than the release pocket I think. Minor patched pulled from the proposed pocket for the ppc64el fix.
<infinity> rbasak: Alright, I can do that without the silly versioning over here.
<cjwatson> pitti: no, syncing from Debian is fine
<cjwatson> pitti: or at least was since the last round of complaints
<rbasak> infinity: sorry. It's convenient when the version is lower in the PPA for testing. Then I can see when the archive upload is done easily.
<infinity> rbasak: Indeed, no need to apologize.
<rbasak> infinity: I think the plan is to delete myodbc? Was this discussed with you?
<pitti> cjwatson: hm, I don't see 2.55.0-1 on https://launchpad.net/debian/+source/calibre yet, even though I uploaded it to Debian > 11 hours ago
<infinity> rbasak: Not in the last week or two.
<rbasak> infinity: slangasek is Debian maintainer. I think we're considering it unmaintained now. Only reverse depends is libreoffice which has alternatives available.
<infinity> rbasak: Yeah, I was fine with the possibility of removing it long ago.  And I think Steve pointed out that it doesn't actually work anyway. :P
<rbasak> OK, bug 1564856.
<ubot5`> bug 1564856 in myodbc (Ubuntu) "Please remove myodbc from the archive" [Undecided,New] https://launchpad.net/bugs/1564856
<cjwatson> pitti: Can you give it about another hour to see if the next import run picks it up?
<pitti> cjwatson: sure
<pitti> cjwatson: sorry, I assumed it was still related to the dak breakage you mentioned
<cjwatson> I don't see immediate evidence in the logs of stuff being broken
<cjwatson> You probably just hit near the worst case for latency
<flexiondotorg> infinity, I sent the email to the techboard mailing list requesting that Ubuntu MATE be a 3yr LTS.
<flexiondotorg> infinity, Does that need actioning prior to release day? You mentioned something about "tagging" the archive.
<xnox> infinity, hm... the iso that was popped out does not have the new files, and also absent from the logs.
<xnox> is the new debian-cd deployed?
 * doko curses ignored ruby autopkg tests in debian
<Kamilion> Oh wow, I wonder how badly 5.7's libmysqlclient is going to break some of my older applications...
<rbasak> Kamilion: the only real change in libmysqlclient itself is the dropping of symbols that weren't previously explictly marked private.
<Kamilion> rbasak: to be fair, trying to move over to drizzle broke them last time, so Iunno, if it breaks I'll fix. Just glad that I heard of it's change before the release, at least now I can check and warn some folks if it's no worky.
<infinity> flexiondotorg: We'll take action from here, thanks.
<xnox> infinity, http://paste.ubuntu.com/15910006/
<xnox> infinity, http://paste.ubuntu.com/15910012/
<smb> Hm, can someone remind me how to add a task for getting something added to the release notes?
<stgraber> smb: task against the ubuntu-release-notes project
<smb> stgraber, ah so "also affcts project" and then ubuntu-release-notes as the project name?
<stgraber> yep
<smb> ah... I had to use a link to change project there since it already picked one
<infinity> smb: Open "http://wiki.ubuntu.com/XenialXerus/ReleaseNotes" in a web browser and add it to the release notes, instead of making someone else do it.
<infinity> smb: That's the best way.
<smb> infinity, I try to do it myself. But also wanted a task to remind myself
<stgraber> you can assign the task to yourself :)
<smb> stgraber, thats what I did
<smb> :)
<flexiondotorg> infinity, Cheers.
<pitti> infinity: I understand bug 1570901 now, and I'd upload a simple revert of http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6411.2.2 to fix it
<ubot5`> bug 1570901 in ubiquity (Ubuntu) "Cd menu not booting to ubiquity try/install menu but always to live session" [High,Confirmed] https://launchpad.net/bugs/1570901
<pitti> infinity: this was supposed to fix bug 1567194 but doesn't, instead it caused this regression
<ubot5`> bug 1567194 in ubiquity (Ubuntu) "Unable to switch to console/ttys from ubiquity" [Medium,Triaged] https://launchpad.net/bugs/1567194
<pitti> I don't yet know how to fix that ^ bug, but I guess it's more important to have a working ubiquity now-ish rather than blocking on the above?
<pitti> (if I figure it out soon enough, we can still do a followup upload)
<pitti> cyphermox: ^ FYI
<pitti> I left all the info in the two bugs
<infinity_> pitti: Sounds reasonable to me.
<infinity_> pitti: Would be nice to fix both bugs, but I think your assessment of importance is sane.
<pitti> infinity_: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1567194/comments/4
<ubot5`> Launchpad bug 1567194 in ubiquity (Ubuntu) "Unable to switch to console/ttys from ubiquity" [Medium,Triaged]
<pitti> infinity: this needs some deeper thinking of how we use plymouth, and it's prone to rip open some other holes if we rearrange this now
 * pitti still painfully remembers the last time when we fought with the plymouth stuff for days during release week
 * ogra_` noticed hw has a black fsck screen flashing by on boot after upgrading to xenial ... never had that before 
<ogra_`> s/hw/he/
 * Kamilion grumbles, I've never had a release yet that plymouth worked correctly on all my systems with.
<Kamilion> most, but never all. ._.
<ogra_`> on my XPS13 i never had any issues since 12.04 ... it is the firet time i do
<ogra_`> *first
<infinity> pitti: Can we move the getty links around in casper?
<pitti> infinity: around where?
<infinity> s/links/services/ whatever.
<pitti> yes, we can
<infinity> pitti: Seems like that may be the only way to make this work.
<pitti> but I'm not sure to where
<pitti> well, there's little point in creating an impossible dependency situation in our *.services and then whacking it in casper
<pitti> we can just fix the dependencies properly
<infinity> pitti: I would think we'd want to move getty to be in parallel with ubiquity.service if -e ubiquity.service
<pitti> i. e. right now we start ubiquity before plymouht-wait-quit before getty
<infinity> pitti: It's only impossible in the case of ubiquity, I assume.
<pitti> I'm not sure why we force ubiquity.service to run before plymouth-wait-quit, though
<pitti> if anything I would have thought that we want to force it *after* it
<infinity> Not sure.  cyphermox may remember.
<infinity> May have been to avoid a bunch of flicker or something?  I dunno.
<pitti> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6363
<pitti> that was cjwatson's fix for bug 1527353
<ubot5`> bug 1527353 in ubiquity (Ubuntu) "ubiquity shows for a second goes to tty then starts live session. " [Critical,Fix released] https://launchpad.net/bugs/1527353
<pitti> remove-package -m AARGH plymouth   -- OOPS!
<infinity> Hah.
<pitti> hm, so why is my ubiquity debdiff so ridiculously large against 2.21.57, I just did "bzr bd -S -- -nc"
<infinity> Do it against the archive version.
<infinity> Or update all the d-i bits in your checkout.
 * pitti does that again with a proper debian/rules update before
<infinity> Yes.  That.
<infinity> I tend to do single-line fixes against pull-lp-source to avoid the annoyance.
<pitti> well, it's not only included stuff like the ubiquity-autopilot bits, I also get lots of d-i/ cache files
<infinity> -i -I?
<apw> how are those not the default
<pitti> infinity: ooh -- there was a merge in lp:ubiquity without adding a changelog entry
<infinity> pitti: Oh, that doesn't help. :P
<pitti> I added it now
<pitti> ok, diff is reasonable now, dput running
<pitti> infinity: ^ examinez, SVP ?
<infinity> pitti: Je ne lis pas Francias.
<pitti> cjwatson: calibre sync worked now, so it seems I indeed just got unlucky with dinstall run plus LP import
<pitti> qui est Francias ? âº
<pitti> I also see bug 1566465 everywhere now, and it leads to wrong times in cloud instances and the like, will look at that after lunch unless you have another urgent installer breakage on the radar
<ubot5`> bug 1566465 in linux (Ubuntu Xenial) "[regression]: Failed to call clock_adjtime(): Invalid argument" [Medium,Fix committed] https://launchpad.net/bugs/1566465
<infinity> pitti: Typing is hard.
<stgraber> flavor leads, please respond to: https://lists.ubuntu.com/archives/ubuntu-release/2016-April/003694.html
<pitti> argh, "fix committed"? I should reload my bug tabs more often :)
<infinity> pitti: Yeah, that's fixed in -proposed.
<pitti> infinity: I was about to ask you about that kernel -- is that still meant for images, or 0-day SRU?
<stgraber> pitti: image
<pitti> ack
<infinity> pitti: That would be the GA kernel if it wasn't broken.  There will be another.
 * apw looks appologetic
<pitti> oh, I didn't mean to say "I don't want this kernel", just wanted to know the plan
<pitti> (I do want that fix, it's really annoying :) )
<infinity> pitti: There are several fixes in -19 and -20 we want/need for release, there just happens to also be some massive breakage. :P
<infinity> Because whee.
<davmor2> pitti: remind cyphermox he owes you a beer ;) thanks dude :)
<cjwatson> pitti: good good
<flexiondotorg> infinity, During the 1604 Beta 2 you asked that the following wasn't forgotten about - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5`> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
<flexiondotorg> infinity, I'm still able to recreate that.
<flexiondotorg> Seen it on hardware and virtual.
<doko> the lz4 upload was test built in https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/6314969/+listing-archive-extra
<flexiondotorg> infinity, We have an update for ubuntu-mate-welcome to address some paper cut issues. Not required for the images but would be nice to have the archive.
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1571635
<ubot5`> Launchpad bug 1571635 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.9 bug fix and translations [dsc attached]" [Undecided,New]
<doko> damn lz4 ... on s390x. maybe I should use the known working seed?
<yofel> fix for a mysqld 5.7 startup error ^
<pitti> yofel: hm, can't the default be set in the code instead of changing a config file?
<pitti> yofel: I'm just wondering if that unnecessarily touches conffiles
<yofel> pitti: I could instead add it to the server startup command line if you think that's better? (We already had a required config update in 15.12.3, so I went that way)
<pitti> yofel: well, it's just a suggestion; but not touching conffiles generally makes upgrades much more robust
<yofel> pitti: right, but here we already changed it recently, so it doesn't make much of a difference
<pitti> yofel: ok; just don't rely on it then :)
<yofel> we *have* to rely on the previous config update (upstream change removing a key that 5.7 doesn't know), so that's that...
<pitti> yofel: ok, accepted (don't regard this as trying to bully you, just a spot check :) )
<yofel> np, thanks for the proper review ;)
<zequence> cyphermox: Since infinity pinged you about the two ubiquity and -slides-ubuntu merges, I'm guessing you are somehow extra involved in ubiquity stuff. Any chance we could get our two merges in before release? Been trying since before FF, and it's just updated artwork. Important for us, but a simple change for you guys.
<cyphermox> ok
<zequence> The merges are Bug 1568981
<ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [Final Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1568981
<zequence> and Bug 1569005
<ubot5`> bug 1569005 in ubiquity-slideshow-ubuntu (Ubuntu) "New ubiquity slideshow for Ubuntu Studio [Final Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1569005
<cyphermox> you'll be missing a ton of translations if any string changes in the slideshow
<cyphermox> ok nevermind, it's just screenshots
<zequence> Right. We aren't supplying the package that was mentioned there anymore, so had to remove it
<cyphermox> pitti: ok to land these two fixes ^ ?
<stgraber> yofel, superm1: can you respond to the tb+release thread when you have a minute? you're the only two missing flavours
<superm1> stgraber: i did respond?
<superm1> did it not come through?
<yofel> I wanted to gather some more opinions from the other kubuntu folks, but most likely my answer is "Short LTS". I'll reply by mail in ~4h
<xnox> yofel, most are going for 3 years.
<yofel> yeah, I saw, and I think that's best for us as well
<stgraber> superm1: moderated
<stgraber> superm1: got it
<superm1> ah okay
<infinity> yofel: Yeah, given the loss of Riddell and ScottK this cycle, I think I'd try to talk you into 3y even if you decided for 5, just because you need some time to recover and restaff before committing to the awful overlap that multiple 5y LTSes gives you.
<pitti> cyphermox: sounds fine to me; not sure if bug 1568981 needs a documentation update (screenshots)
<ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [Final Freeze Exception]" [Undecided,Confirmed] https://launchpad.net/bugs/1568981
<cyphermox> wha?
<cyphermox> it removes a line and updates the screenshots, should be good
<zequence> The ubiquity merge only deals with one line, changing the default wallpaper when choosing to install from boot, instead of trying the live ISO
<cyphermox> yep
<cyphermox> well, I'm preparing the uploads
<pitti> cyphermox: sorry, I meant the other bug which changes the wallpaper
<pitti> zequence: oh, that wallpaper, not the desktop one
<pitti> yeah, that's trivial then
<cyphermox> pitti: sorry, I didn't understand what change you meant
<pitti> cyphermox: nevermind, I read "new wallpaper" as "for the desktop"
<pitti> if that's just for ubiquity-dm, fine
<cyphermox> yeah, ok
<zequence> cyphermox: pitti: Thank you! (I owe you some beers)
<pitti> zequence: not me, I didn't do anything for these :) thanks for the updates
<zequence> Would have been a shame to release with the artwork from 14.04, so quite a relief to finally get all the pieces in.
<flexiondotorg> Laney, Can I get an ack on the please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1571635
<ubot5`> Launchpad bug 1571635 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.9 bug fix and translations [dsc attached]" [Undecided,New]
<Laney> flexiondotorg: You don't need an ack for bug fix releases still; go ahead
<flexiondotorg> Laney, ty. Just making sure :-)
<Laney> Stuff goes into the unapproved queue anyway, and if we're in respin land then it might turn into an SRU
<Laney> (But I didn't hear that we're there yet)
<flexiondotorg> Can someone here sponsor an upload please. A paper cut update -  https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/157163
<ubot5`> Launchpad bug 157163 in texlive-base (Ubuntu) "texlive-base-bin cannot be installed" [Undecided,Fix released]
<Laney> (Then again I'm not in the room)
<Laney> (Yet)
<flexiondotorg> Oops. Can someone here sponsor an upload please. A paper cut update -  https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1571635
<ubot5`> Launchpad bug 1571635 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.9 bug fix and translations [dsc attached]" [Undecided,New]
<flexiondotorg> Laney, Yeah if this doesn't make this image, no biggy.
<Logan> pitti: oops, didn't realize you were sponsoring that
<pitti> Logan: no harm done :)
<Logan> flexiondotorg: I'll look into that in around 15 minutes if someone else doesn't get to it first :)
<flexiondotorg> Logan, Thank you :)
<flexiondotorg> Logan, Many thanks!
<Logan> you got it :)
<xnox> cjwatson, as per infinity & stgraber germinate throws up running against wily/vivid, due to invalid dep in Built-Using in the removed from xenial unity-scopes-snappy
<xnox> http://paste.ubuntu.com/15916861/
<cjwatson> drop the comma after %s
<cjwatson> xnox: can you arrange to re-raise the exception unless field == "Built-Using"?
<cjwatson> i.e.   if field != "Built-Using": raise   in the exception handler
<cjwatson> I don't think we should get more permissive in the other cases
<xnox> ok
<xnox> cjwatson, volleyball first though =/
<xnox> cjwatson, i think that logic should go up into _parse_depends itself.
<cjwatson> xnox: I think it shouldn't be rearranged too much for now :)
<cjwatson> xnox: hm, though I guess _parse_depends is simple enough that we could afford to move it all in there
<cjwatson> it'd just entail also passing the field name
<Kamilion> is Bug 1547340 important enough to get a SRU if it's not fixed before release?
<ubot5`> bug 1547340 in gnome-disk-utility (Ubuntu) "gnome-disks crashed with SIGSEGV in g_dbus_object_get_interface()" [Medium,Confirmed] https://launchpad.net/bugs/1547340
<stgraber> sounds like it, yes
<Kamilion> Good; it'd be nice if it worked on the live media; but I'm fine with running a rebuild of my remix ISOs after a SRU if it doesn't make it in time.
<Kamilion> thanks for taking the time to look.
<mgz> hello lovely release team. I'd like to upload a new juju-2.0 package with extra debug stuff for the autopkgtest that's failing per bug 1571082 - would that be okay?
<ubot5`> bug 1571082 in juju-core (Ubuntu) "autopkgtest lxd provider tests fail for 2.0" [Critical,Triaged] https://launchpad.net/bugs/1571082
<stgraber> mgz: just run your test locally
<stgraber> mgz: /home/stgraber/.irssi/scripts/autorun/timezone.pl
<stgraber> doh
<mgz> stgraber: it passes locally - or at least it fails differently
<stgraber> mgz: http://packaging.ubuntu.com/html/auto-pkg-test.html
<stgraber> that one
<stgraber> mgz: are you running using adt-run locally? if not, it doesn't really mean anything
<mgz> yes. different virt backend, which apparently matters. but pitti ran with the qemu one and got a different failure
<mgz> I want the extra debug stuff so at least when people report results we have something comparible
<infinity> mgz: Is this debug stuff added to juju itself, or just to the tests?
<mgz> tests
<slangasek> mgz: I'll approve extra debug stuff in the tests, yes; let's get this sorted as quickly as we can
<mgz> I'll note that pitti's last failure looks totally external to juju so I'm not sure I can help much there
<slangasek> mgz: also, I have a small patch for debian/tests/normal-user.sh to make its use of adduser idempotent, so that in theory you can run multiple tests on the same testbed - not particularly relevant with the current test declarations, but where should I send this?
<infinity> slangasek: We were about to pack up and head out for the day, you cool with handling this juju thing?
<slangasek> infinity: yes, go away
<mgz> slangasek: sounds good, I'll include that
<slangasek> ;)
<infinity> :P
 * infinity kicks off a world respin before he goes away.
<mgz> slangasek: I also want some better log gathering, hardlinking stuff into $ADT_ARTIFACTS is I think the right way forward?
<slangasek> mgz: I have no idea, let's pretend I said "yes"
<mgz> slangasek: :)
<mgz> slangasek: specific to "where should I send this" is either put up bzr branch and I'll merge or pastebin a patch and likewise
<slangasek> mgz: merge it to where? The juju-core package lacks any Vcs-* fields in debian/control
<slangasek> mgz: merge it to where? The juju-core package lacks any Vcs-* fields in debian/control
<mgz> slangasek: I just have a branch under the ~juju-qa group at present, it's linked several times in the ffe bug
<mgz> slangasek: it's also the one I mention in comment #2 bug 1571082
<ubot5`> bug 1571082 in juju-core (Ubuntu) "autopkgtest lxd provider tests fail for 2.0" [Critical,Triaged] https://launchpad.net/bugs/1571082
<slangasek> mgz: ok
<cyphermox> tjaalton: looking at xorg for upgrades from trusty; I don't see xorg Conflict/Replace/Provide: xorg-renamed-package, is that normal or am I misunderstanding the upgrade magic for the -lts stacks?
<cyphermox> (to be clear, I was looking at the xorg packaging in xenial and I don't find it, it definitely is there for xorg-server-lts-vivid and xorg on trusty)
<stgraber> mgz: oh, is the problem that you can't download the ubuntu image?
<stgraber> mgz: because if it is, it's absolutely expected in an adt environment
<tjaalton> cyphermox: ok, i'll check it out tomorrow..
<mgz> stgraber: none of the problems given seem to be that
<stgraber> sorry, just came to me after you mentioned it being the lxd test :)
<mgz> stgraber: I'd also expect it.
<jtaylor> can universe unseeded bugfixes still be uploaded without approval?
<cyphermox> tjaalton: I could maybe handle it, if you agree this is what's missing
<stgraber> mgz: ok, well, if that fails, add this to your test "lxc config set core.proxy_http ${http_proxy} && lxc config set core.proxy_https ${https_proxy}" that will fix it for you
<cyphermox> tjaalton: fwiw this is bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1571677
<ubot5`> Launchpad bug 1571677 in ubuntu-release-upgrader (Ubuntu) "upgrading caused a broken apt cache due to *-lts-vivid packages conflicting with current X packages" [Undecided,New]
<tjaalton> cyphermox: upgrades failing?
<cyphermox> yeah
<mgz> stgraber: okay, I'll add that as well?
<stgraber> mgz: make it conditional to http_proxy and https_proxy actually existing in the environment obviously
<stgraber> so that it doesn't run and fail on systems that don't have a proxy defined
<mgz> I don't see why the juju lxd provider would do that for me
<cyphermox> tjaalton: asking you because looking at both X and u-r-u I don't see anything in the past u-r-u changes to point to anything special dealing with *lts-* stacks, and only something hinting to it in X
<mgz> but simple to add
<stgraber> mgz: sure. It could be that cloud-images.ubuntu.com is actually allowed in the test instance firewall, but I'm not sure
<cyphermox> in case you knew off-hand
<stgraber> mgz: the LXD testsuite doesn't touch the network so we're not affected there and the lxc1 testsuite knows what to do with those env variables so it would work in either case
<mgz> stgraber: yeah, I'm also not sure, but failure in adt happened before image fetch it seemed
<stgraber> mgz: certainly won't hurt to set the right proxy server in lxd, so that patch would be right anyway
<mgz> indeed, for this test it's at worst harmless
<tjaalton> cyphermox: mlankhorst dealt with this before leaving, but i'll have a look
<cyphermox> tjaalton: ok, thanks
<jtaylor> can universe unseeded bugfixes still be uploaded without approval?
<teward> jtaylor: does https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001181.html help?
<jtaylor> well free for all probably means yes
<jtaylor> but better safe than sorry, I haven't uploaded in quite a while ._.
<jtaylor> does that also fall under free-for-all? ;) https://bugs.launchpad.net/ubuntu/+source/openblas/+bug/1571811
<ubot5`> Launchpad bug 1571811 in openblas (Ubuntu) "FFe for openblas 2.18" [Undecided,New]
<barry> hello admins.  i have a fix for the python-virtualenv regression working its way through debian.  i'll be syncpackaging it as soon as lp picks it up.  15.0.1+ds-2 should fix the python-pip proposed migration failure
<tjaalton> cyphermox: heh, I see that precise/trusty got an updated xorg 6-7months after release. the changes were never in git
<cyphermox> ah
<tjaalton> actually not quite true, in git but on a separate branch so I never noticed until now
<tjaalton> and they were added to be compatible with the next lts stack, not to help upgrades
<tjaalton> so I'm not sure this is going to fix anything
<tjaalton> cyphermox: i'll put it in a ppa first to see if it actually fixes that bug
<cyphermox> tjaalton: thanks for looking into it on such short notice
<doko> trying: usb-modeswitch-data
<doko> skipped: usb-modeswitch-data (5 <- 0)
<doko>     got: 136+0: a-44:a-14:a-15:i-14:p-18:p-17:s-14
<doko>     * amd64: lubuntu-desktop, ubuntu-mate-cloudtop, ubuntu-mate-core, ubuntu-mate-desktop, usb-modeswitch
<doko>  finish: []
<doko> this looks like an obsolete source package
<tjaalton> cyphermox: xorg-lts-transitional needs to be added to xenial
<flexiondotorg> cyphermox, o/
<cyphermox> tjaalton: fun
<cyphermox> flexiondotorg: hey
<flexiondotorg> cyphermox, I'm bumping into this in my testing - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5`> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
<flexiondotorg> On hardware and Vms.
<cyphermox> doko: usb-modeswitch-data is probably not obsolete
<cyphermox> flexiondotorg: yeah, that's my current item
<flexiondotorg> cyphermox, I've got a few hours. Can I help?
<cyphermox> flexiondotorg: if you can easily reproduce it, try to run 'systemctl stop swap.target' just before running ubiquity
<cyphermox> partman otherwise is already doing the right "swapoff" dance right before doing the partitioning
<cyphermox> it's just that systemd is a little too eager to bring up swap partitions
<flexiondotorg> Yeah, that is my observation.
<flexiondotorg> Some of the guys have done clean installs at work. They all ran into this.
<cyphermox> so, I think that incantation might help ;)
<cyphermox> well, *hope* more than think.
<flexiondotorg> I said, just switch tty and swapoff -a. First issue, can't switch tty ;-)
<cyphermox> yeah.
<flexiondotorg> So, to live desktop. And swapoff and systemd bloody well activates swap again.
<flexiondotorg> OK, so I understand the work around.
<flexiondotorg> I'm offering testing assistance or log gather duties.
<cyphermox> lemme know if this works well, I'd be tempted to add it to ubiquity's start script
<cyphermox> not in the live environment, but when ubiquity starts
<flexiondotorg> cyphermox, Understood.
<flexiondotorg> cyphermox, I'll install some computers now and try that.
<cyphermox> thanks for the help
<flexiondotorg> But only after I first encounter the issue.
<flexiondotorg> To know that it works.
<tjaalton> cyphermox: ^
<cyphermox> tjaalton: oh, cool thanks. I was setting up a trusty vm to get started on that
<flexiondotorg> I've just been asked by the Lubuntu team if someone here has permission to respin all their images?
<tjaalton> cyphermox: spend some time testing that instead then :)
<flexiondotorg> There "man who can" in unavailable at the moment.
<flexiondotorg> Typos.
<flexiondotorg> stgraber, I saw you mail to Lubuntu about seeds.
<flexiondotorg> stgraber, I think I may have to do the same for Ubuntu MATE?
<flexiondotorg> stgraber, Actually, it seems I did most of the alignment with Ubuntu a while back.
<flexiondotorg> cyphermox, What timezone is infinity physically in right now? I know it is kind of irrelevant, but just want to know when it is reasonable to ping him :-)
<rbasak> flexiondotorg: he's in UTC+1
<flexiondotorg> Is he in my country?
<rbasak> Indeed he is.
<flexiondotorg> :-)
<stgraber> flexiondotorg: you guys don't have an alternate image though, do you?
<flexiondotorg> London?
<flexiondotorg> stgraber, No, we don't have an alternate.
<stgraber> flexiondotorg: infinity looked at and cleaned all the seeds for flavors which don't produce an alternate, so you're good
<flexiondotorg> stgraber, And I've checked their removals. Ubuntu MATE is fine :-)
<stgraber> flexiondotorg: lubuntu was special because they do produce an alternate image so we needed to have them check whether it was intentional for them to ship that stuff or not
<flexiondotorg> stgraber, Ah.
<flexiondotorg> Understood. Thanks.
<flexiondotorg> So, to my earlier question.
<flexiondotorg> Can anyone here respin the Lubuntu images for them?
<stgraber> flexiondotorg: and yeah, infinity and I are currently in London but I don't think he's still online. I'm also going to disappear very soon :)
<cyphermox> flexiondotorg: indeed currently in the release sprint
<flexiondotorg> Right.
<stgraber> and sure I can kick a lubuntu respin for you
<flexiondotorg> I might have to have beers delivered.
<stgraber> rebuild requested on the tracker, should show up within the hour if all goes well
<flexiondotorg> stgraber, Thanks. I'm a proxy. They've contacted me to ask hear because the release guys aren't available right now. A birthday or something.
<flexiondotorg> stgraber, Thanks.
<stgraber> I think infinity meant to respin everything but we were waiting for something to land in the archive before that. Not sure what's the state of that, so they may get another respin when things settle a bit more.
<flexiondotorg> stgraber, I'm expecting a respin for the boot directly to desktop bug that was fixed earlier.
<stgraber> anyway, we're expecting a new kernel to land tomorrow which will require another mass respin, so current images aren't real candidates anyway but are very useful to confirm that everything else looks good
<flexiondotorg> cyphermox, I have a snapshot that can reliably reproduce the swap issue.
<flexiondotorg> cyphermox, Trying your work around now.,
<cyphermox> would love to get that snapshot if the workaround doesn't work
<flexiondotorg> cyphermox, The 'systemctl stop swap.target' work around doesn't work.
<cyphermox> mmkay
<flexiondotorg> cyphermox, It's a Vbox snapshot.
<cyphermox> it did look like things behaved slightly differently then but I wasn't sure if it would be good enough
<flexiondotorg> Interested in a VBox export if I make one?
<flexiondotorg> cyphermox, ^^^
<slangasek> Laney: appstream in the unapproved queue, is this bugfix-only and did you mean to self-accept it so I don't have to figure out what it is? ;)
<cyphermox> flexiondotorg: yes definitely
<flexiondotorg> cyphermox, Oh er, I'll have to learn how to drive this thing.
<flexiondotorg> I only use it to test the Vbox hang on reboot thing.
<flexiondotorg> Which is still a thing.
<flexiondotorg> OVF 1.0 or 2.0?
<flexiondotorg> Going with 1.0
<flexiondotorg> Because defaults.
<xnox> cjwatson, yeap that's what i thought...
<xnox> however i do want germinate strict, and it's a shame it's only three releases later we have cought an invalid Built-Using.
<xnox> can i just not like SRU unity-scopes-snappy to fix the Built-Using in -updates, and that would be the end of the story?!
<stgraber> xnox: wouldn't germinate still read the release pocket and fail?
<cjwatson> xnox: I'll apply something like your change tomorrow
<cjwatson> gotta be pragmatic
 * xnox sees little point as to why germinate would be (a) running against willy & vivid (b) without -updates. Exercise of reproducible builds?!
<cjwatson> we run germinate against wily (not willy) multiple times a day from cron
<cjwatson> and indeed it is failing :-)
<cjwatson> also, -updates is irrelevant
<cjwatson> germinate still needs to parse each Packages/Sources file even if it's only to decide that a stanza is superseded by something in -updates
<cjwatson> so an SRU will not make any difference
<stgraber> ok, that's what I figured. And yeah, it was when manually running said cron job that I noticed the failure earlier today.
<flexiondotorg> cyphermox, You in Canada now?
<Kamilion> flexiondotorg: for what it's worth, i also see the hang-on-reboot in vmware workstation
<flexiondotorg> Kamilion, Yep, I read.
<flexiondotorg> I don't have VMware.
<teward> I do
<teward> whatcha need tested?
<flexiondotorg> But I did tidy my office the weekend. So have 11 laptops to test with.
<flexiondotorg> All shit.
<flexiondotorg> :-)
<flexiondotorg> cyphermox, 67% exported...
<Kamilion> just as another aside -- it happens with vmware workstation player -- the free one. (Workstation "pro" gets you remote management of esxi vm servers)
<teward> Kamilion: I have workstation pro if you want to xzip a copy for me to test on.
<Kamilion> I see it in vbox, vmware workstation player, vmware workstation pro, kvm, but not xen
<teward> to make sure the issue ex... oh you tested :P
<Kamilion> pretty sure it's something with systemd and the final 'halt' command
<Kamilion> but I am not a developer, just a sysadmin
<Kamilion> i've got my lubuntu-derived ISO rebuilding from the latest packageset right now; I'll check again to verify the behavior's still occuring.
<flexiondotorg> cyphermox, 13GB uploading. Will take ~ 9hrs because I'm on short wave radio here :-(
<flexiondotorg> cyphermox, You might be able to reproduce like this.
<flexiondotorg> Install 15.10 in a VM as full disk, do everything for me.
<flexiondotorg> Snapshot that.
<flexiondotorg> Try and install 16.04 over the rop of that installed system. Pretty sure you'll get the error.
<flexiondotorg> I'll leave the image uploading overnight.
<flexiondotorg> I have a server in Canada so you're download should be quite fast.
<flexiondotorg> cyphermox, Do the 15.10 install without lvm and without encrpytion.
<Kamilion> Aye, I can confirm that -- or if you can find some of the early dailys from november or december, those also exhibited the hang-on-reboot for quite a while
<Kamilion> from flex's description though, it sounds like the problem's either in a bash initscript or a unit file
<Kamilion> I havn't seen it for a while, not since I switched my base ISO from the december dailys to alpha 1 then beta 1
<Kamilion> but I've been building on an esxi vm and testing the isos on bare metal from a grub2-infused USB stick more and more as I've gotten a hold of more HW
<superm1> Can someone review the mythtv upload? We're intending it for final ISO
<slangasek> superm1: looking
<slangasek> superm1, tgm4883: fwiw, '^.\+\?' is probably more succinctly written '^.*'
<superm1> Thanks slangasek . tgm4883 take note of the above
<tgm4883> superm1: noted and pushed to packaging branch
#ubuntu-release 2016-04-19
<slangasek> mgz: so... somehow, when I raise an mp, lp tells me you do not have rights to view ~juju-qa/ubuntu/xenial/juju/xenial-2.0-beta4/ ?
<slangasek> oh, maybe it's angry because I didn't say lp:
<mwhudson> slangasek: hi, so you're still poking at this juju autopkgtest thing too?
<superm1> slangasek: after mythtv migrates from proposed would that be a safe time that a seed change to ship-live would be effective too for a re-spin?
<superm1> i /think/ the fix for https://bugs.launchpad.net/ubuntu/+source/mythbuntu-meta/+bug/1571781 is just seeding another package that somehow didn't resolve
<ubot5`> Launchpad bug 1571781 in mythbuntu-meta (Ubuntu) "Nvidia driver not installed" [Undecided,Fix committed]
<slangasek> mwhudson: not actively poking at the moment; had tried to see if the tests would pass for me in a different setup, to no avail
<slangasek> superm1: why waiting until it migrates before changing the seed?
<slangasek> superm1: I'd generally say it's better to change the seed sooner rather than later, since it doesn't need to block on the mythtv migration and that way you're not holding up any respins
<mwhudson> slangasek: ok
<superm1> slangasek: sorry wasn't clear - the seed change was already done
<superm1> i wasn't sure how fast migration was going to happen
<superm1> so i wanted to make sure the respin only happened after the migration was done
<slangasek> ah
<slangasek> yeah, that should be enough time for it to propagate
<infinity> superm1: When rmadison says it's in the release pocket, that'd be safe.
<infinity> superm1: Don't trust LP's "published" status for this.
<cyphermox> flexiondotorg: yes, I'm in Canada
<cyphermox> oh crap, please reject that, it wasn't meant for here. ^
<Logan> cyphermox: happens to the best of us :P
<Logan> fun fact, you can edit your dput.cf so that you must specify a host while dputting
<slangasek> mwhudson: hmm why does the manual provider care about the test user's shell?
<pitti> slangasek, mwhudson, mgz: I suppose it won't hurt if I run http://bazaar.launchpad.net/~mwhudson/ubuntu/xenial/juju/mwhudson on the production infra?
<pitti> cyphermox: hey, still here? mind reuploading ubiquity with a non-ugly version number? (2.21.59ubuntu1~mtrudel1 â 2.21.60); or was this mis-uploaded and supposed to go into a PPA?
<pitti> infinity: I reviewed unapproved stuff that's not on the images; left the three ones that are to avoid stomping on your feet
<pitti> infinity: if you want ubiquity, I'd rather reupload with a real version number, but I suppose we want the casper fix at least
<pitti> (and then take appstream when casper gets accepted)
<Logan> pitti: [00:36:39]  <cyphermox>	oh crap, please reject that, it wasn't meant for here. ^
<Logan> (re ubiquity)
<pitti> Logan: ah thanks,  rejected
<slangasek> mwhudson: ignore the question, I see why ;)
<pitti> slangasek, mwhudson: hm, running tests from that bzr branch still fails, I'll try building the package from that bzr branch too
<LocutusOfBorg> infinity, hi, can you please accept virtualbox again? the cherry-picked patch has been included in a stable release
<LocutusOfBorg> or anybody else :)
 * LocutusOfBorg leaves, but reads replies on irclogs
<mwhudson> pitti: sigh
<mwhudson> pitti: there's no diff to speak of between the non-debian/tests code in that branch and what's in -proposed
<mwhudson> slangasek: :)
<pitti> mwhudson: ah ok, so building packages indeed wasn't necessary; I just followed up to the bug with the full log
<jtaylor> is there still a chance bug 1571811 gets looked at? even if its just a quick no
<ubot5`> bug 1571811 in openblas (Ubuntu) "FFe for openblas 2.18" [Undecided,New] https://launchpad.net/bugs/1571811
<mwhudson> slangasek: the experience of ssh-ing to a user with /bin/false for a shell is pretty confusing
<pitti> mwhudson: does your test rely on lxd already being installed and the user being in the lxd group perhaps?
<pitti> mwhudson: (we run autopkgtests in minimized VMs)
<mwhudson> pitti: i ran the tests in whatever adt-buildvm-ubuntu-cloud -r xenial spat out :-)
<pitti> mwhudson: ok, that's minimized, no preinstalled lxd
<mwhudson> pitti: but it could be something like that i suppose
<pitti> unless you use an non-current version of autopkgtset
<mwhudson> lxd is listed in the test deps
<mwhudson> pitti: i'm up to date on xenia;
<pitti> if you use current xenial or trusty/wily-backports, lxd should not be present in the testbed
<pitti> mwhudson: oh wait, I mis-read
<pitti> Get https://10.0.8.1:8443/1.0/profiles: Forbidden
<pitti> this isn't a problem of local "lxd" group membership and the unix socket, this is over the bridge
<pitti> so maybe missing remote auth or whatnot
<mwhudson> uh yeah
<mwhudson> pitti: lxd is installed in the test bed fwiw
<mwhudson> pitti: http://paste.ubuntu.com/15925658/
 * pitti runs your branch locally in qemu
<pitti> mwhudson: hm, that looks like a non-current version of autopkgtest then
<mwhudson> pitti: i have 3.20.3 apparently
<pitti> mwhudson: hm,  * setup-commands/setup-testbed: Purge lxd and lxc.
<pitti> that was in 3.20
<pitti> mwhudson: when did you build that VM?
<mwhudson> pitti: 6 hours ago?
<pitti> hmm, that sounds like worth a bug report
<pitti> but anyway, at first sight it doesn't actually look like that's the problem
<mwhudson> i would agree with that
<pitti> an EPERM on the unix socket could be related to that
<mwhudson> so my successful run has 2016-04-19 02:20:15 DEBUG juju.tools.lxdclient client.go:73 connecting to LXD remote "juju-remote": "10.0.8.1"
<pitti> ooh, wait
<mwhudson> i don't know what 10.0.8.1 is
<pitti> mwhudson: yeah, it locally passes for me too
<mwhudson> pitti: ip conflict or something like that?
<pitti> mwhudson: presumably that's the network you put lxdbr0  on
<pitti> mwhudson: but this sounds like it could be a real IP in the data center
<mwhudson> pitti: "you"? :)
<pitti> mwhudson: which curiously is the very reason why lxd stopped configuring the bridge with hardcoded IPs by default and now requires you to set it up yourself
<mwhudson> i don't know a lot more about all of this than you do
<pitti> mwhudson: yes, the bridge is unconfigured by default; I suppose the test installs an /etc/default/lxd-bridge somewhere
<mwhudson> yeah
<mwhudson> grep for 10.0.8.1 :-)
<pitti> yep, that one
<mwhudson> it's in setup-lxd.sh
<mwhudson> can we exploit the feature in very new lxd where it guesses for you?
<mwhudson> or at least re-implement that
<pitti> but in the DC there is no "real" 10.0.8.1
<pitti> so it's not that after all I guess
<mwhudson> dammit
<pitti> mwhudson: let's move to #u-devel for further debugging to not clutter the release coordination even further
<mwhudson> pitti: +1
<jibel> morning
<jibel> it's surprisingly quiet for a release week
<pitti> bonjour jibel !
<pitti> jibel: yeah, it's suspicious
<jibel> Bonjour pitti
<pitti> the ubiquity issue yesterday was laughable compared to what we're used to
<pitti> what did we miss?
<jibel> it means Thursday will be hell :)
 * pitti is scared
<pitti> jibel: OOI, how are upgrades looking?
<pitti> I'm sure we've missed some bits at least there
<jibel> pitti, automated tests didn't find anything, neither did davmor2
<jibel> I'll dig into launchpad
<jibel> someone reported that ubuntu-gnmoe fails to start after an upgrade from Trusty
<davmor2> jibel: I didn't think ubuntu-gnome was an option in trusty
<davmor2> oh it's been around longer than I thought :)
<jibel> davmor2, bug 1571939
<ubot5`> bug 1571939 in ubuntu-release-upgrader (Ubuntu) "Ubuntu GNOME fails to boot after Trusty -> Xenial upgrade" [Undecided,New] https://launchpad.net/bugs/1571939
<davmor2> jibel: there is one last test for upgrades I want to perform, OEM install upgrade just to be sure it doesn't do anything daft
<jibel> davmor2, bug 1571679 I know you enjoy secure boot
<ubot5`> bug 1571679 in ubuntu-release-upgrader (Ubuntu) "fwupdate-signed doesn't get installed on upgrade" [Undecided,New] https://launchpad.net/bugs/1571679
<davmor2> jibel: I wonder if this is part of the mokutils stuff and if these users had secureboot enabled with 3rd party drivers installed, I can test that with ease 172468
<jibel> davmor2, it's an upgrade not an installation
<davmor2> jibel: yeap still kicks in
<davmor2> jibel: and it might be disabling the modules now too
<davmor2> jibel: that would affect wifi networking if it is broadcom and fwupdate-signed if they didn't disable secureboot
<pitti> jibel: well, at least we  still have the "OMG need to land juju 2.0" issue, so we aren't totally free of urgent things :)
<pitti> this calms me somewhat
<davmor2> pitti: aaaahhhh bless you think that is the only thing that still needs to land I love your optimism it's nearly infectious :D
<pitti> davmor2: no, it's not optimism -- I'm scared that we don't (yet) know about the catastrophes that are still coming :)
<seb128> hey there
<seb128> we need to rename "gnome-software" to be "ubuntu-software", part of it is changing the .desktop Name=
<seb128> we have two options
<seb128> - rename the current one (easier) and impact the flavors as well (Ubuntu GNOME stated they would prefer to keep the upstream name)
<seb128> - have a new.desktop and play with OnlyShowIn to have it only for Unity, but that would require to land unity with it to change the default and have user config migration
<seb128> do you have a preference?
<seb128> willcooke, ^ fyi
<seb128> I think we are leaning toward the first one
<seb128> easier and less potential to create issues
<jtaylor> unseeded universe is still free-for-all in terms of sync or do I need approval?
<infinity> jtaylor: See the freeze announcement.
<cjwatson> stgraber,xnox: germinate fixed in git and on snakefruit etc.; uploading to unstable, will sync that when I can
<jtaylor> infinity: so free for all?
<infinity> jtaylor: Ish.  With a sanity clause.
<jtaylor> ok thanks
<xnox> cjwatson, lovely
<pitti> hey infinity, good morning
<pitti> infinity: I'm handling juju-core
<pitti> infinity: just running last tests locally
<cjwatson> lazr.https://bugs.launchpad.net/bugs/1571899
<ubot5`> Launchpad bug 1571899 in ubiquity (Ubuntu) "Kubuntu Daily Image Ubiquity cannot connect to X server :0" [Undecided,New]
<cjwatson> oops
<pitti> infinity: you or someone accepted casper, so I guess free for another round of reviewing/accepting bug fixes on images?
<cjwatson> sorry, mispaste.  can we squeeze lazr.restfulclient in?  fixes python3 support bug, but is on a couple of images
<zequence> infinity: Saw you and cjwatson poke in our seeds cause of the build failure yesterday, so hopefully that is fixed. iso.qa.ubuntu.com says still building. Would like to trigger another one. Any help there, please?
<pitti> ah, someone accepted juju-core already; well, tests look good so far, so it's probably fine
<cjwatson> lazr.restfulclient> ta
<mwhudson> pitti: how long will it be until the autopkgtests run?
<mwhudson> i guess i'll be in bed by then
<pitti> mwhudson: package just finished building, so needs a publisher run; I'd say 45 minutes, give or take
<pitti> mwhudson: but go to bed, I'll have an eye on them
<pitti> mwhudson: if it still fails, it should be fairly shallow, and I know enough of what this is trying to do
<pitti> i. e. I should be able to handle it
<mwhudson> pitti: yeah, mostly just curious
<mwhudson> it's only 2143, it's not that late yet :)
<pitti> mwhudson: local run is at future-provider, other tests passed
<pitti> "local" == manual run in the production env, I mean
<flexiondotorg> seb128, Regarding the software center naming.
<flexiondotorg> seb128, Are you proposing changing the string in the .desktop file or the filename of the .desktop file?
<Laney> String
<flexiondotorg> OK.
<flexiondotorg> WHat about upgrades from 14.04? Will you now have to Ubuntu Software centres?
<flexiondotorg> Also, although Ubuntu MATE doesn't ship with Ubuntu Software Centre nor GNOME Software Centre, both are installable via Ubuntu MATE Welcome.
<Laney> I think it's Ubuntu Software and Ubuntu Software Center (awesome)
<cjwatson> Sounds like a great way to reduce user confusion
<flexiondotorg> So, please have MATE; in any OnlyShowIn setting.
<flexiondotorg> If you decide to make that change.
<davmor2> seb128, Laney: out of interest why rename it at all, currently it is just called software
<Laney> Something about reducing confusion
<cjwatson> Ho ho ho
<Laney> They want to rename the package too, but I'm pushing back on that
<Laney> We'll see
<pitti> infinity: ^ would be great if you could review/accept this apt SRU (trusty/wily), as bug 1560797 is still causing upgrade havoc
<ubot5`> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,In progress] https://launchpad.net/bugs/1560797
 * pitti will write SRU info now
<infinity> pitti: Will look.
<xnox> pitti, can i have an autopkgtest for upstream hosted in git on sourceforge?
<pitti> infinity: SRU info added
<xnox> or does it need like remote triggers off somewhere? e.g. shall i mirror it to github or launchpad and try to do webhooks for upstream autopkgtest
<pitti> xnox: we auto-trigger systemd's autopkgtest for upstream systemd pull requests on github, so from SF should not be fundamentally different
<pitti> xnox: but yes, you need something on the SF side to actually trigger the test, if you want this to happen automatically
<pitti> github has really nice webhooks for doing CI, not sure if SF learned anything in that regard in the past 5 years
<pitti> xnox: also, -> #u-devel I figure?
<davmor2> jibel: so it looks like those upgrade issues were what I thought they were looking at the issues I just hit, looks like if you don't disable secureboot through mokutil the system goes crazy,  I'll run a bunch of tests around it now.
<jibel> davmor2, thanks
<davmor2> netboot is missing from the iso tracker
<davmor2> jibel: is that something you can add?
<xnox> davmor2, it will be fixed shortly, when next respin is done.
<davmor2> xnox: thanks dude
<flocculant> xnox: are we expecting an imminent respin? cos something appears to be up with studio's build - tracker shows them rebuilding but https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntustudio shows built hours ago - was the same ~ 5 hours ago
<flocculant> though the imminent bit is me with xubuntu hat on :)
<mapreri> can you please ignore the virtualbox's autopkgtests and let virtualbox hit the release pocked?  (message proxied for locutusofborg)
<mapreri> pitti: â
<pitti> mapreri: yep, saw it, at it (we already have a hint, just needs a version bump)
<pitti> mwhudson, slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#juju-core is just landing \o/
<pitti> all green
<mapreri> pitti: ok, ta :)
<infinity> pitti: I'm fixing vbox to not have that bug, BTW.  Well, to not have half of that bug. :P
<superm1> infinity: okay can you respin myth?
<infinity> superm1: You can!
<superm1> I can?
<infinity> Well, if you have access to do so on the tracker.
<infinity> But lemme do it.
<infinity> Cause I should take a lock on that soon anyway.
<superm1> Oh I didn't know I might have access. Ok thanks
<cyphermox> good morning!
<flexiondotorg> o/
<flexiondotorg> cyphermox, My image upload died and I'm at work now and can't resume until later :-(
<flexiondotorg> Can someone here take car of the upload please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1571635
<ubot5`> Launchpad bug 1571635 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.9 bug fix and translations [dsc attached]" [Undecided,Fix released]
<flexiondotorg> Ag, wrong link.
<flexiondotorg> Please can someone upload this please - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1572120
<ubot5`> Launchpad bug 1572120 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.7 bug fix release [dsc attached]" [Undecided,New]
<cyphermox> flexiondotorg: bah, I'll get VB on some other computer and try to reproduce there
<cyphermox> or you know, on a laptop with spinny disks
<flexiondotorg> cyphermox, Give me a minute...
<flexiondotorg> cyphermox, I can't resume it :-(
<flexiondotorg> Going to take another 10 hrs.
<flexiondotorg> Sorry.
<cyphermox> flexiondotorg: don't worry
<cyphermox> flexiondotorg: I know what is wrong, I just haven't managed to reproduce it yet
<flexiondotorg> VirtualBox. Install Ubuntu 15.10 with full disk. No encryption. No LVM.
<cyphermox> it's very clearly systemd too happy to bring up swaps, and we "just" need to find a way to disable that only when in ubiquity
<flexiondotorg> Snapshot that. Then try install Ubuntu 16.04 daily over the top.
<flexiondotorg> cyphermox, Agreed.
<flexiondotorg> My best work around is "sudo swappoff -a" then start the install and dash through the first few menus.
<cyphermox> right, but partman already does a swapoff just before doing the swaps
<cyphermox> so it's a timing thing, you might be lucky, or might not
<cyphermox> I can still add swapoffs in ubi-partman.py but it probably won't fix it more
<flexiondotorg> cyphermox, It won't fix it. Because unless you do a Ubiquity speed run systemd will beat you to the punch.
<infinity> tjaalton: Do you plan to fix xorg-lts-transitional?
<tjaalton> infinity: fix how? it worked here
<infinity> tjaalton: Check excuses.  You depend on a bunch of packages that don't exist.
<tjaalton> ah
<tjaalton> oh, indeed
<jcastro> does anyone mind if I add a Juju section to the updated packages section of the release notes?
<tjaalton> infinity: hrm, I need to run out now, will fix it later today. guess I can drop the transitional -dbg packages at least and then let apt remove those on upgrade?
<rbasak> jcastro: please do. SHould that be in https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Ubuntu_Server?
<infinity> tjaalton: If apt will remove them.
<tjaalton> right, i'll test on a vm
<jcastro> rbasak: well, the client/UI bits had the biggest updates so I was going to put it below php7
<rbasak> jcastro: oh, I see. I wonder if people will look just at the server section for this kind of thing or not (even though it is also a client). Maybe PHP etc should be down there too.
<rbasak> jcastro: anyway, I'm bikeshedding, sorry. Let's get the text in and worry about where it belongs later.
<superm1> infinity: i tried to seed libc6-i386 into mythbuntu.xenial ship-live to fix bug 151781, but it appears to have had no effect in the respin, i'm unsure how to figure out what is wrong there to prevent it from coming in
<ubot5`> bug 151781 in kde-guidance (Ubuntu) "KDE resolution or screen changes makes Nvidia binary not to work" [Undecided,Won't fix] https://launchpad.net/bugs/151781
<superm1> bug 1571781 that is
<ubot5`> bug 1571781 in mythbuntu-meta (Ubuntu) "Nvidia driver not installed" [Undecided,Fix committed] https://launchpad.net/bugs/1571781
<teward> rbasak: do we still need a release notes for http/2 (Apache)?
<teward> oops wrong channel my apologies
<rbasak> Seems like the right channel to me :)
<pitti> infinity: may I nudge you about bug 1560797 again? I'd hope that we can expedite this SRU to intensely test this by Thursday and then release it
<rbasak> Yes we do, but I have some things I need to take care of first.
<ubot5`> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,In progress] https://launchpad.net/bugs/1560797
<infinity> pitti: apt?  Looking in a bit.
<teward> rbasak: ack
<infinity> pitti: ^
<pitti> infinity: cheers
 * mvo hugs pitti and infinity for this fix
<seb128> ^ I expect this one to be controversial, happy to reply to questions
<seb128> willcooke, ^ the gnome-software rename one, just fyi
<superm1> cyphermox: i think i figured out why libc6-i386 isn't ending up in the pool on ISOs - "Promoted libc6-i386 from ship-live to boot to satisfy grub".  is there actually a reason for grub (not grub2) to still be called out in platform.xenial's boot seed still?
<cyphermox> not that I can think of, but that would make libc6:i386 *be* in pool
<cyphermox> directly available on the CDs, basically
<superm1> cyphermox: well i'm trying to get libc6-i386 (not libc6:i386) to end up on amd64 mythbuntu ISO's
<superm1> and the reason it's not happening is that libc6-i836 is a dependency for grub
<cyphermox> sorry, that's what I meant
<cyphermox> ship-live makes it go in the pool/ directory on the iso
<superm1> right that's the goal
<superm1> but it's not ending up there even if explicitly seeded
<cyphermox> well it's not because of that message
<cyphermox> lemme see
<superm1> http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/xenial/daily-live-20160419.log is the log
<pitti> infinity: we'll still do a respin, right? for ^ (bug 1552539)
<cyphermox> I fail to read...
<ubot5`> bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix committed] https://launchpad.net/bugs/1552539
<cyphermox> superm1: sorry, I just can't read properly it seems
<cyphermox> so yeah, libc6-i386 gets promoted to the 'boot' seed because you have  * grub [amd64 i386]                      # lilo will be in supported  in that seed file
<superm1> well that comes from platform.xenial
<superm1> so that's why i was asking if it's actually used anywhere (to know if it could be removed)
<cyphermox> yep
<cyphermox> I don't know
<cjwatson> that stuff will need to be in sync with livecd-rootfs I think
<cyphermox> cjwatson: or debian-cd?
<cyphermox> ok, I see, ship-live depends on boot and live, fun.
<infinity> pitti: Yeah.
<cjwatson> possibly debian-cd/cdimage as well
<infinity> Why would anything else need changing to remove grub from boot?  We surely don't use grub anywhere anymore...
<cjwatson> one would hope
<cjwatson> but it might still be added to images somewhere else
<infinity> If it were, I'd assume it would be because of the seed.
<cyphermox> looks like it, it's in the boot seed.
<cjwatson> it's probably OK, just worth some grepping
<cjwatson> the boot seed is historically very weird
<cjwatson> subtle and quick to anger etc.
<cyphermox> ahah
<infinity> superm1: Anyhow, were that fixed, you could also revert your change (probably), since nvidia-thingee should pull in libc6-i386 without your help.
<cjwatson> but I think a grep through livecd-rootfs, maybe live-build, debian-cd, and cdimage would be sufficient
<superm1> infinity: yes
<infinity> cjwatson: Yeah, heading there.
<xnox> superm1, my dell xps 15 got offered a firmware update, it did end up in ./EFI/ubuntu/fw/fwupdate-j01CFS.cap
<xnox> superm1, however on reboot it did not boot into flash update
<xnox> i can go into flash update manually and find that file, but i thought this should happen automagically
<superm1> xnox: lets talk in PM to debug what happened
<xnox> or not?
<xnox> ack
<xnox> infinity, Laney https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1571679
<ubot5`> Launchpad bug 1571679 in ubuntu-release-upgrader (Ubuntu) "fwupdate-signed doesn't get installed on upgrade" [Undecided,New]
<Laney> merci
<slangasek> pitti: juju-core tests all fixed? nice!
<pitti> slangasek: yep, that was an interesting journey
<pitti> infinity: ok to accept lxc with a tests-only fix to make the tests green again? (will still rebuild the binaries, of course)
<pitti> infinity: or maybe the other way around, can you poke me, Laney, stgraber etc. to stop reviewing stuff from the queue once you want to lock down?
<stgraber> that lxc is to make apw happy basically :)
 * apw likes to be happy
<pitti> well, and to stop new kernels from breaking lxc too :)
<stgraber> we know lxc itself is good because we saw its tests pass before, but a change to the adt image broke things recently so that should make everything green again
<infinity> pitti: When I'm locking the world down, I'll put in a britney block.
<infinity> pitti: So if pepole keep reviewing, it'll all get stuck, and we can sort it out post-release.
<pitti> or rather, currently lxc depends on which of the clouds it runs on
<pitti> infinity: ah, fair enough; they'll end up as SRUs then
<zequence> Who can I poke about the tracker being stuck? We can't do rebuilds for Ubuntu Studio since it got stuck yesterday.
<stgraber> I'm about to board a plane so can't really help, but infinity should be able to have rebuild-requests cancel anything that's pending which will fix the web UI
<cyphermox> infinity: stgraber: should we have a cpc product in the iso tracker?
<slangasek> cyphermox: no
<cyphermox> ok
<slangasek> cyphermox: this is not a "cpc" product at all, and the fact that it's showing up that way currently on cdimage is a bug
<cyphermox> slangasek: I thought it should be in ubuntu-server indeed; but what I really meant is, should I be seeing a product entry for the raspi2 preinstalled images under server in iso.qa.u.c, or anywhere else?
<slangasek> ah ;)
<cyphermox> since I slapped it on my device and booted it, I might as well tick the tested box ;)
<slangasek> then yes, probably, but not until the image publishing is sorted properly ;)
<cyphermox> yeah
<cyphermox> infinity fixed up my initial merge, and then there was some extra magic to make it so ubuntu-cpc -> ubuntu-server
<slangasek> that part doesn't seem to be landed yet however?  at least there's no http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled
<infinity> cyphermox: There will be a tracker project in a bit when I fix the other thing.
<cyphermox> slangasek: no, it's currently under /ubuntu-cpc/daily-preinstalled
<cyphermox> infinity: do you want me to finish the work of fixing that up? preferrably with passing tests? ;)
<infinity> cyphermox: If you want to figure out how to move it from -cpc to -server and submit another MP, go for it.  If this one fails the testsuite, I'll fly to Montreal and stab you a little.
<cyphermox> just a little?
<infinity> cyphermox: Just a tad. :)
<Laney> gentle caress with a pointy thing
 * cyphermox is tempted to make the ubuntu-cdimage merge with the fix, plus an added test to test the fix, but leaving the test failing :)
<slangasek> infinity: where do we stand at the moment regarding candidate image mastering?  per discussions elsechan, it's been observed that snapd didn't get into the platform seed; doing this for 16.04 was discussed with flavor leads but the execution fell through.  If we seed it right now into desktop-common are you going to have a sad?
<davmor2> jibel, cyphermox: hey guys so I seem to hit an issue with upgrades.  The issue is as follows. Install 14.04, install binary drivers, upgrade, during upgrade you get the mokutils password setup, However if you don't see the menu the driver seems to go into some mad loop, you can't access the gui if it is a gfx driver or use wifi if it is that driver, but your tty fills with errors so you have no way to trigger
<davmor2> mokutils to fix it for gfx issue
<Laney> slangasek: He's out, but the metas are all being rebuilt anyway for fwupdate-signed
<cyphermox> infinity: https://code.launchpad.net/~cyphermox/ubuntu-cdimage/cpc-in-server/+merge/292297
<cyphermox> this does pass tests here.
<slangasek> Laney: "are being" meaning currently or at some point in the near future?
<cyphermox> davmor2: I'm not sure I follow what you mean. did you file a bug with screenshots or something?
<Laney> slangasek: Built on laptop but not uploaded yet
<cyphermox> "if you don't see the menu" ?
<slangasek> Laney: ok; am twiddling seeds now, do you happen to know the full list of metapackages that need uploading and would you like to help divide and conquer by chance?
<davmor2> cyphermox: no, no you miss understand, if you don't realise that you need to hit a key or you go off and make a drink while the system reboots so you miss it or don't modify it then it breaks
<Laney> slangasek: Adam's got a nice alias in his shell history that I'm sure he could re-run quite easily
<slangasek> Laney, infinity: snapd added to the seed
<slangasek> so it will get picked up in meta rerolls
<cyphermox> davmor2: you mean, do the upgrade, reboot, miss the MokManager blue prompts, it times out and you get no drivers?
<davmor2> cyphermox: bingo
<cyphermox> right.
<Odd_Bloke> infinity: There was murmuring about a kernel with fixes needing to land; which kernel was that?
<infinity> Odd_Bloke: -21
<infinity> Odd_Bloke: In proposed.  We're working on promoting it.
<infinity> Odd_Bloke: It'll be in the release pocket tonight.
<Odd_Bloke> OK, cool.
<infinity> slangasek: Right, I'm fixing some other seed bits, and will re-roll the world shortly.
<davmor2> cyphermox: the odd thing is that this only happens on upgrade. IE 14.04 install nvidia-binary, ignore the mokutil efi menu, and TTY7 is black with a white arrow and that is as much as loads
<davmor2> cyphermox: because the tty 1-6 is flooded with errors you can't login
<cyphermox> ok
<davmor2> cyphermox: also because the mokutil only shows the one time you need to be able to login to trigger it again.  I managed to do it via rescue mode but it is not fun or pretty
<bdmurray> infinity: I've the Wily SRU for bug 1560797.  Will having the new apt in -updates reach enough people though?
<ubot5`> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix committed] https://launchpad.net/bugs/1560797
<seb128> slangasek, Laney, if you do a seed change, can you gnome-software->ubuntu-software for desktop?
<Laney> not before the package exists
<slangasek> seb128: let's wait until that's in the archive for that, as it hasn't landed yet
<seb128> k
<zequence> infinity: Any chance you could fix the problem we are having at the ISO tracker? We can't do rebuilds. It's been stuck att (rebuilding) for 24h, since the build failure yesterday.
<seb128> slangasek, Laney, infinity, ^ new take, without renaming the .desktop but installing one to "/usr/share/ubuntu/..." with the same name, that path is at the start of XDG_DATA_DIRS in Ubuntu sessions so going to be preferred in Unity
<seb128> oh also creating the .desktop by copying the upstream one and caling sed in debian/rules to change the Name/Icon
<seb128> seems to work fine from my local testing
<seb128> willcooke, ^ just for info
<Laney> seb128: I need to add another commit
<seb128> Laney, queue is public, feel free to grab and merge another change or stack another upload on top
<Laney> seb128: it'll be a little bit easier if you push that to bzr
<Laney> if you have that
<seb128> no I don't
<seb128> attente gave me a ppa the other day and I forgot about the vcs
<seb128> need to reconciliate things
<seb128> I can try to have a look but I've a tennis match in 45 min and didn't get dinner yet :-/
<Laney> ok
<davmor2> cyphermox: oh oh oh pitti just fixed https://bugs.launchpad.net/bugs/1552539 can we get that in asap?
<ubot5`> Launchpad bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix released]
<cyphermox> I know
<cyphermox> not sure it really will fix it, we'll see
<slangasek> Laney: shall I hold off on review until you fix up, or shall I review/maybe-accept this one and then review again your next commit?
<Laney> I'll upload it in a minute, so you might as well wait
<seb128> Laney, I'm fixing the vcs, give me 30s
<Laney> seb128: already done locally, no worry
<seb128> oh ok
<seb128> thanks
<seb128> going to get some food then :p
<seb128> Laney, slangasek, I would appreciate if you could handle the seed change when the new package gets in, need to have dinner and go in ~30min
<seb128> otherwise I can have a look later tonight when I'm back
<slangasek> seb128: yes, I can have a look
<seb128> thanks
<pitti> davmor2, cyphermox: yeah, this is mostly just my best bet so far, so testing appreciated; it can be simulated reasonably well on the current image with breaks=casper-bottom and doing that rm there
<superm1> infinity: did you have a conclusion on grub (re boot seed) from looking at livecd-rootfs, debian-cd, cdimage et'al?
<infinity> superm1: I'll get there.
<superm1> infinity: okay.   i just wanted to say if it's gotta stay or it's hard to confirm if it's gotta stay, can another way to fix this be to seed "grub" in mythbuntu.xenial's ship-live seed to pull libc6-i386 into the pool?
<infinity> superm1: Won't help.
<Laney> slangasek: check yo'self
<infinity> slangasek: And/or wreck yo'self
<slangasek> Laney: I am here
<slangasek> check complete
<Laney> HAHA
<slangasek> adt-run --apt-source slangasek
<Laney> DONT CHECK ANYTHING
<Laney> INFACT STOP LOOKING
<slangasek> ahhh autotools wut
<infinity> -0ubuntu1-0ubuntu1 is brilliant.
<slangasek> "new upstream snapshot"
<Odd_Bloke> -0ubuntu1, Laney 2016: An effective commentary on the true meaningless of version strings when faced with the complexity of life
<Laney> lalala
<cyphermox> is that the version number length award for this cycle?
<rcj> rolls off the tongue
<cyphermox> I will not let gir1.2-networkmanager-1.0 0.9.7.995+git201301311547.17123fc-0ubuntu1 down so easily.
<Laney> I got a warning from lintian with the duplicate 0ubuntu1
<Laney> but I was like YEAH WHATEVER
<Laney> WHO CARES OLD MAN
 * ogra_ waits for the rollback ... with the +really-$version 
<Odd_Bloke> +really-0ubuntu1-0ubuntu1
<cyphermox> there wouldn't be reallys for non-upstream revisions
<ogra_> 3.20.1+git20160419.2.b8d2e40.ubuntu-xenial+really+git20160419.1.d7dc006.ubuntu-xenial-0ubuntu1
<infinity> slangasek: Please to re-review gnome-software so we can get that in and twiddle der seeden.
<ogra_> "twiddle der seeden." ... sounds like you have a dutch moment today :)
<slangasek> Laney, seb128: not sure this debian/rules sed of debian/ubuntu-software/usr/share/ubuntu/applications/org.gnome.Software.desktop in place will dtrt when we *do* have translations?
<infinity> According to Laney, "Dunno, won't fix it, **** off."
<slangasek> Laney: also, /usr/share/ubuntu/applications does not exist on my system at all currently, so what does this do?
<Laney> It's prepended dynamically
<Laney> by $something
<infinity> slangasek: Evidently, there's some hierarchy where the session name is checked first.
<Laney> according to $someone
<slangasek> infinity: that sounds an awful lot like "please reject"
<infinity> So someone says.
<infinity> I feel like this needs some testing once built. :P
<infinity> But we have the power to do that here.
 * infinity stares at the man to his left.
<slangasek> this non-DRY sed is also quite upsetting to me
<slangasek> anyway, accepted
<Laney> I *think* that translations will be okay since dh_translations adds X-Ubuntu-Gettext-Domain
<Laney> and XDG_DATA_DIRS is set up by an Xsession.d script AFAICS
<Laney> it's at least right here
<Laney> http://people.canonical.com/~laney/weird-things/lifeisgood.png
<Laney> quality
<cyphermox> that's a lot of software
<Odd_Bloke> Twice the software, still free.
<zequence> We would really like a rebuild for the Ubuntu Studio ISO, but can't do it ourselves, since the tracker is stuck at rebuilding since yesterday. Could someone help us out here, please?
<infinity> slangasek: New kernel appears to function the way we think it should WRT mok thingees now.
<infinity> slangasek: The UI for all of that is *vile*, though.
<teward> infinity: hate to add something to your list for FinalFreeze breaking, but, nginx 1.9.15, Bug #1572223, has some fixes to HTTP/2 handling to address Chrome issues, and two other bugfixes in HTTP/2.  It changes a runtime dependency for nginx-extras (Universe) which doesn't affect nginx-core, nginx-common (Main).  Happy to drop the nginx-extras changes if you NACK that, but the HTTP/2 changes should land.
<ubot5`> bug 1572223 in nginx (Ubuntu) "[FFe] Update nginx to 1.9.15" [Wishlist,New] https://launchpad.net/bugs/1572223
<teward> (that came out today)
<infinity> teward: I thought we had http/2 disabled?  Or am I stuck in the past?
<infinity> teward: But will look at it tonight.
<teward> infinity: ACK'd by the Security Team for 1.9.14
<cyphermox> kernel mok thingees?
<infinity> teward: Ahh, kay.
<davmor2> cyphermox: that's the technical term for it don't mok ;)
<teward> infinity: HTTP/2 in Apache is still disabled, but nginx's implementation was OK'd for enablement
<teward> which is one of the things the server team has wanted to land for Xenial
<teward> so, keeping the protocol handling is the main 'break the freeze' reason for nginx.
<infinity> teward: Check and check.  Will look in a bit.
<teward> no rush :)
 * teward goes and pokes at his builders which are choking on armhf builds
<Kamilion> sweet.
<Kamilion> it'll be fun to roll out letsencrypt and http2 on a fresh nginx, I have some 12.04 machines that are sorely due for an upgrade series.
<teward> Kamilion: indeed, though you still need Wily+ for *good* HTTP/2 - PPA for Wily, Xenial-native (1.9.14 or newer) for HTTP/2 to truly work - PPAs're going to lose HTTP/2 soon for pre-OpenSSL1.0.2 versions...
<Kamilion> good to know -- I'm on their stable PPA normally
<slangasek> infinity: it was implied up-thread that you would be doing mass rebuilds of meta packages; is anything blocking that? do you need an extra body?
<infinity> slangasek: I've got them all sorted except ubuntu, which is waiting on these bits to land.  It's sorted, though.
<infinity> slangasek: We're going to wait for the kernel and ubuntu-software to settle and then update metas, respin images, and go get drunk.
<slangasek> infinity: sorted how? I don't see them uploaded yet, and I think they ought to be
<infinity> slangasek: Was going to upload them all at once, but meh.
<slangasek> infinity: you're looking at at least another half hour delay for ubuntu (gnome-software build, new accept, proposed-migration); surely it's better at this late hour to not block the rest of the flavors on this
<infinity> slangasek: Sure, I'll upload all !Unity flavour metas.  Sec.
<apw> "is that your cursor" time
<teward> heh
<infinity> slangasek: Uploaded.
<slangasek> infinity: thanks, I shall reviewinate
<phillw> Hi good people, is there an estimate for the global respin with the new kernel? (The testers are nagging and straining at the leash to get their hands on it!!! )
<teward> phillw: tell the testers they have to learn patience
<teward> :P
<apw> phillw, the kernel is copying out as it is currently awol
<slangasek> infinity: ubuntustudio-meta-0.154/debootstrap-version lulwat
<phillw> teward:  we are to run with linux-headers-4.4.0-21 ?
<infinity> slangasek: Dropped it to the xenial version so ./update didn't have a fit. :P
<infinity> slangasek: (previous upload was from a sid machine, clearly)
 * slangasek nods
<slangasek> infinity: do you know why the ubuntu-mate refresh seems to have downgraded snapd to a recommends?
<slangasek> I guess ubuntu-mate had seeded it themselves already?
<infinity> slangasek: Yeah, they had it seeded in a seed that can't do recommends.
<slangasek> and gnome-software built/accepted
<Kamilion> I just learned that plymouth-theme-ubuntu-text is the default theme. I'd been assuming it had been broken and *falling back* to the text theme this whole time (after experiencing some of the older fancy animated themes in the past)
<Kamilion> I humbly retract my accusation that plymouth has been 'broken' for my machines
<slangasek> infinity: and all the other metanana accepted
<davmor2> slangasek: wasn't that a Bananarama song?
<cyphermox> Kamilion: it's only the default if you can't otherwise show the prettier graphics
<cyphermox> Kamilion: otherwise you'd normally get plymouth-theme-ubuntu-logo
<tjaalton> infinity: hope xorg-lts-transitional is fixed now.. I didn't drop packages, instead made them depend real ones
<infinity> tjaalton: Works for me.
<Odd_Bloke> infinity: I see a migrated kernel; shall we pull the trigger on a (potential) cloud-images RC, or is it worth holding off for anything else you know of?
<infinity> Odd_Bloke: Lemme look if there's anything else you're waiting on.
<Odd_Bloke> infinity: Danke.
<infinity> Odd_Bloke: You're waiting on at least lxc and snapd still.
<Odd_Bloke> infinity: Ack.
<Odd_Bloke> infinity: Is there an easy way for me to see whatever you just looked at?
<pitti> infinity: new linux is off the release now?
<infinity> pitti: s/the/to/?
<infinity> pitti: If so, yes.
<pitti> infinity: oh, it landed
<pitti> no, I actually meant "will not go in", I didn't see that it got unblocked
<rbasak> infinity: FYI, ^^ was the second last reverse dep for src:mysql-5.6. Remaining is pinba, which I'll look at with Skuggen tomorrow.
<rbasak> (and myodbc which is pending removal)
<rbasak> I'm a little worried about pinba, but we'll see tomorrow.
<Skuggen> Yeah, it uses the source itself to build, and there are significant changes
<infinity> rbasak: \o/
<infinity> rbasak: Right down to the wire on this one. :P
<rbasak> infinity: yeah, too close for my liking :-/
<phillw> Installing side by side the alternate installer reports fail at "Select and Install Software" Are there any logs that I could possibly get to flesh out the bug report (I'm using KVM, so do have guestfish to pull files out).
<slangasek> why do publisher runs seem to get slower at the end of the cycle right as there are fewer things it needs to publish?
<pitti> Odd_Bloke, infinity: lxc and snapd are currently landing, FTR
<infinity> slangasek: Because we become less patient.
<pitti> because more people stare at it?
<slangasek> infinity: I promise you I am impatient the rest of the cycle also
<slangasek> pitti: why were the snapd test regressions bypassed/bypassable?
<slangasek> I guess because they now include a test that looks for a package that doesn't exist on these archs?
<pitti> slangasek: this isn't a regression in 2.0.2, but a race condition/bug in the store; it happened before and mvo investigated it with Laney already
<infinity> slangasek: I've got the ubuntukylin-meta review, I synced them with the ubuntu seeds today, so checking to see if the outcome was sane.
<pitti> slangasek: a fix is being deployed to the store, but as this existed before and this blocks image builds we expedited it
<pitti> slangasek: see #u-devel discussion 50 mins ago
<slangasek> ok
<slangasek> +  * Added tuxmath to ubuntu-edu-primary-recommends [s390x]
<slangasek> important
<infinity> SUPER IMPORTANT.
<slangasek> but at least we got mono fixed for all archs, so we can have tomboy on our edubuntu arm64 deploys
<infinity> Hellz yeah.
<apw> party time
<infinity> \o/
<infinity> o/
<infinity> \o
<slangasek> rbasak: myodbc removal isn't in some way blocking on me, is it?  You asked about RoM from Debian, but I haven't decided yet what to do there and this shouldn't block its removal from xenial
<slangasek> (if myodbc later sneaks back into Ubuntu via sync from Debian, that by definition means the FTBFS has been fixed, so yay)
<slangasek> infinity: I hereby declare that the plural of 'meta' is 'metaxa'
<apw> tjaalton, your xorg-lts-transitional seems to be upsetting britney .... lots of uninstallables ...
<infinity> slangasek: Isn't meta already the plural, and each individual one is metum?
<slangasek> infinity: are you trying to stand in the way of my metaxa?
<cyphermox> who'd date?
<cyphermox> *dare
<knome> meti
<knome> metÃ¦ could work as well.
<cyphermox> slangasek: you'll be able to get plenty of metas very soon though.
<rbasak> slangasek: as long as an archive admin says it's blocking on Debian's removal or something, no it's not blocking.
<rbasak> Err, doesn't say, that is.
<mvo> pitti: thanks again for the 2.0.2 hint, fwiw, autopkgtest on amd64 worked now and autopkgtest on the i386 and ppc64el are running
<pitti> mvo: yeah, just saw the same, thanks
<mvo> pitti: I expect them to work as well after the store update
<mvo> pitti: maybe one more retrigger, I need to check if all snaps are already in
 * mvo does that now
<pitti> hit it hard! :-)
<mvo> ha!
 * mvo does so :)
<slangasek> infinity: hakuna metata, the metaxa are published in xenial (minus edubuntu+ubuntukylin+ubuntu)
<slangasek> and I'm updating ubuntu-meta now
<tjaalton> apw: still?
 * pitti waves good night
<tjaalton> bah
<tjaalton> infinity: soo, can you purge xorg-lts-transitional from proposed so that the i386 xspice packages get cleaned
<slangasek> or, I won't upload ubuntu-meta because somebody else uploaded it, somehow before ubuntu-software was published, and bypassed the unapproved queue <eye>
<slangasek> ok ;)
<slangasek> infinity: did you guys already skedaddle?  not sure what plans you had for respins today...
<slangasek> ("already" - it is quite late there, of course)
<flexiondotorg> Laney, http://people.canonical.com/~laney/weird-things/lifeisgood.png
<flexiondotorg> I'm so confused.
<infinity> slangasek: I planned to respin when I got back from drinks, which I've done (the getting back, not the respinning)
<cyphermox> infinity: console-setup upload I promised incoming, up to you to take or not.
<cyphermox> ru shows the right glyphs, vi is *better* but not quite fixed yet; but at least more readable.
<slangasek> infinity: right, could've saved you the trouble... :)
<infinity> cyphermox: console-setup requires a d-i respin, so it'll wait until tomorrow to see how high the carefactor is.
<cyphermox> yeah, no problem
<cyphermox> in the meantime I'll test one other non-ascii language, and see if I can fix vi for reals.
<infinity> cyphermox: Can you give me a matching ubiquity in the queue with a package refresh, and we'll sort it out tomorrow?
<cyphermox> yes
<infinity> Danke.
<cyphermox> oh wait
<cyphermox> no, I can't get ubiquity to refresh for console-setup unless it's in proposed.
<cyphermox> well..
<cyphermox> yeah, I suppose I can trick it to be happy
<infinity> cyphermox: I can get it in -proposed, that's fine by me.
 * infinity refiews.
<infinity> Or reviews.
<infinity> I haven't had alcohol, I promise.
<cyphermox> pfff
<infinity> (I had all the alcohol)
<cyphermox> don't drink and respin isn't a rule is it?
<infinity> +[ "$CODESET" != guess ] || CODESET=''
 * flexiondotorg hides the wine
 * infinity wraps his head around that.
<cyphermox> wait, that's wrong
<slangasek> is it wrong? looks ok to me
<infinity> +[ "$CODESET" != guess ] || CODESET=''
<infinity> +if [ -z "$CODESET" ]; then
<slangasek> if confusingly written
<cyphermox> what if you set CODESET to what you want alredy?
<cyphermox> oh
<infinity> Seems like it would be better written as "if [ "$CODESET" != guess ] || [ -z "$CODESET" ]"?
<cyphermox> I fail at logic.
<infinity> Err.
<infinity> Wait.
<cyphermox> not my code, in any case
<infinity> The changelog claims guess or unset is what we want.
<infinity> That doesn't say that, though..
<cyphermox> so that line will set CODESET to '' if it's == guess
<infinity> Right.  It's just weird logic for a drunk brain.
<cyphermox> and then if -z, it will do the magic.
<cyphermox> yeah
<cyphermox> I'm not drunk though, no excuse
<infinity> Hence "if [ "$CODESET" = "guess" ] || [ -z "$CODESET" ]"; then" would read better, I'd think.
<cyphermox> I think it really was just copied straight from setupcon
<infinity> Which, indeed, the FONTSIZE test does...
 * cyphermox looks again
<infinity> Ahh, cargo culting is a valid excuse. :)
<cyphermox> yeah, copied
<infinity> I'm all for duplicate code matching exactly.
<infinity> Kay.
<infinity> The logic works, it's just my brain that doesn't.
<infinity> Acceptiferated.
<cyphermox> well, the whole thing works, before, you get white squares. after, you get backwards Ns ;)
<infinity> Deliver me a ubiquity while I sleep.
<cyphermox> zug zug
<infinity> slangasek: unblocked your qemu.  Can you respin server when that lands?  I'll kick off !server now.
<infinity> tjaalton: xorg-lts-transitional NBS cleaned up, you should be good if :9 fixes all your woes.
<infinity> pitti: mvo seems to have left us, but can you two make sure his snapd hasn't actually regressed and nick highlight me with a yay or nay?  It's already migrated, but I want to know we've not migrated crap. ;)
<slangasek> infinity: yes. what's the proper way for me to respin at this point?  just a build from commandline?
<infinity> slangasek: Ticken ze boxes on der ISO tracker und clicken ze rebuild.
<slangasek> infinity: ok
<infinity> der boxen?
<infinity> Whatever.
<infinity> My faux German is suffering.
<slangasek> infinity: accusative plural ;)
<infinity> I'll accuse your plurals.
 * infinity waits for the current publisher run to be done.
<infinity> La dee da.
<infinity> slangasek: Oh, also, I haven't fixed up the tracker part of the cpc bits, so when you're about to respin server, you can also do "for-project ubuntu-cpc cron.daily-preinstalled" in parallel to test the merge you pulled from cyphermox.  If it fails to be useful, I can fix in the morning.
<infinity> Aaaand, !server respin is now in progress.
<infinity> Oh sweet, we have new NBS issues 2 days before release too.
<infinity> slangasek: Can you also hunt down someone cloudish (I'm guessing stokachu) and figure out WTF is up with the openstack-* stuff on NBS?
<infinity> (kernel NBS is cleaning now)
<infinity> slangasek: Thanks in advance, etc.  You can be my manager again in two days.
<phillw> infinity: is that going to be the server release with 4.4.0-20 kernel? Or should we expect another one?
<slangasek> infinity: did glibc 2.23 regress setenv() to crash on a NULL value where it didn't previously? https://errors.ubuntu.com/oops/6483e4a6-02f2-11e6-8b73-fa163e54c21f
<slangasek> infinity: ack to all the highlights in scrollback
<infinity> slangasek: Re: setenv() > maybe, though that seems unlikely.  Remind me in /msg in a few minutes when I walk away and stop obsessively checking IRC, and I'll poke that in the morning with a stick.
<stokachu> infinity: whats wrong?
<stokachu> how can i turn that frown upside down
<slangasek> stokachu: your latest openstack package, which has made it into xenial \o/,  drops the openstack-{landscape,multi,single} binary packages; these packages still have reverse-dependencies in the form of cloud-install-{landscape,multi,single}
<slangasek> as shown on http://people.canonical.com/~ubuntu-archive/nbs.html
<slangasek> er, check that
<slangasek> those are also built from the same source package
<slangasek> so the revdep problem is further up the stack, at...
<slangasek> at... I don't see it
<slangasek> so this may be a false-positive on the NBS report and maybe I just need to delete me some binaries?
<slangasek> ok here we go
<stokachu> go for it
<slangasek> there is a dead-end cloud-installer source package in xenial
<slangasek> which is not uploadable because its binaries are superseded by openstack
<infinity> Right, that likely all needs to go then.
<slangasek> but this means nbs is unhappy
<infinity> But I thought the transitional stuff was meant to live until post-16.04?
<infinity> I guess not?
<infinity> Cause current openstack drops it all.
<slangasek> it does, but I know nothing of the transitioning
<stokachu> so now that everything relies on juju2 and conjure, openstack and bigdata only need to rely on conjure
<infinity> 1.0.0 is where it all went away.
<slangasek> stokachu: but, would there be users who had cloud-install-* installed on trusty who will get a sad on upgrade because these packages dead-end rather than upgrading them to the openstack binary package?
<slangasek> at least, I am sure that the cloud-installer source is obsolete and needs culling; doing that bit
<infinity> stokachu: Is there an upgrade path from 14.04, or should there be?  You had an upgrade path from trusty all the way to wily, then dropped it right before the next LTS.
<phillw> Hi good people, I see a rebuild of lubuntu alternate, is there a server rebuild with new kernel due?
<infinity> slangasek: Ignoring that /msg highlight, assuming it's the reminder I asked for. :P
<stokachu> there is not a viable upgrade path from openstack 0.99 + juju1
<infinity> Kay.
<infinity> I mean, not "kay" in the sense of "okay", but "kay" in the sense of "oh, well I guess that's how it is, then".
<infinity> Perhaps better summarized as "Thanks Obama".
<slangasek> phillw: search scrollback for "server"
<stokachu> openstack 1.0.0 is a new release in a sense of non compatible backward changes
<stokachu> infinity: dont you mean The Hillary?
<slangasek> stokachu: just to confirm, this means that a user on trusty who had cloud-installer-* installed should not expect to have the openstack package installed on upgrade?
<stokachu> slangasek: correct
<slangasek> ok
<slangasek> then the rest will sort itself out imminently
<stokachu> slangasek: i think balloons wanted to try and do another upload of juju
<balloons> slangasek, yes, this has the dpkg-divert stuff we talked about yesterday. It's the juju-1.25 branch
<infinity> stokachu: The upload can happen, whether it gets into the final images will rely on other respin triggers, it's not a valid enough reason on its own.
<infinity> balloons: ^
<stokachu> infinity: ok thats what i wanted to confirm
<phillw> slangasek: I'm on pidgin... limited search tools. I was alerted that there was a respin due with a new kernel. So, if you would be so kind as to answer, it would be much appreciated as I've got a couple of test cases to run and want to check against server for https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1572306
<ubot5`> Launchpad bug 1572306 in debian-installer (Ubuntu) "Side by side fails at "Select and Install Software" step" [Undecided,New]
<balloons> infinity, ack
<infinity> But do upload, the world is blocked in proposed-migration right now, so we can sort it as we go.
<stokachu> balloons: yea ill be around
<stokachu> slangasek: i also have a package name change :(
<stokachu> was handed down on friday
<stokachu> conjure becomes conjure-up
<stokachu> which means bigdata and openstack would rely on that
<jderose> tjaalton: are you open to rebuilding mesa against llvm 3.6 for the sake of installable Xenial ISOs on certain Nvidia hardware? https://bugs.launchpad.net/oem-priority/+bug/1564156
<ubot5`> Launchpad bug 1564156 in System76 "xenial: invalid opcode when using llvmpipe" [Critical,Triaged]
<stokachu> balloons: ill be around just ping me when juju 1.25 is good
<jderose> tjaalton: and the post release, we can figure out the underlying problem, try to get mesa back on llvm 3.8 as an SRU?
<slangasek> stokachu: the sooner the better, though you're not up against the wall yet since none of this is seeded
<stokachu> slangasek: i see conjure is out of proposed so it will need a breaks/replaces << 0.0.8?
<balloons> stokachu, I'm happy with it, so I think let's build
<stokachu> slangasek: https://github.com/Ubuntu-Solutions-Engineering/conjure-up/blob/master/debian/control
<slangasek> stokachu: if it's a straight rename, conjure-up Conflicts/Replaces/Provides: conjure is preferred
<stokachu> ok
<jderose> infinity: what are your thoughts release-management-wise on https://bugs.launchpad.net/oem-priority/+bug/1564156 ?
<ubot5`> Launchpad bug 1564156 in System76 "xenial: invalid opcode when using llvmpipe" [Critical,Triaged]
<infinity> jderose: A day and a half before release, my thoughts amount to "ugh".
<infinity> jderose: But I'm removing myself from my keyboard, so I'll let more awake people examine it.
<slangasek> jderose: I think that's my cue
<jderose> infinity: i likewise have "ugh" thought about it :P unfortunately, i was at a trade show last week
<infinity> jderose: I'm not against a respin event for mesa, but it would need some rather broad testing to make me comfy.
<jderose> slangasek: much thanks :)
<slangasek> surely this shouldn't be a last-minute regression, though? i.e. if this was widespread, shouldn't it have been picked up sooner in the cycle?
 * infinity unlaptops and walks off.
<jderose> infinity: agreed. for the record, system76 is more than willing to test this on as much hardware as possible as quickly as possible :)
<slangasek> jderose: most likely scenario at this point: we have to release note it and fix it for .1
<slangasek> downgrading to llvm-3.6 for the build isn't really an option
<jderose> slangasek: why is that? as far as i can tell, llvm-3.6 is in main. what is the specific issue there?
<slangasek> but, let me see if there's anything obvious in the build history
<slangasek> errm, you're right it is in main, and wow is *that* a bug to have two versions of llvm in main
<slangasek> jderose: the switch to llvm-3.8 was for bug #1535500; dropping this means having to downgrade the supported level of OpenGL, 2months+ after the change was made in the devel cycle
<ubot5`> bug 1535500 in mesa (Ubuntu) "Enable OpenGL 4.1 with radeonsi driver on xenial" [Wishlist,Fix released] https://launchpad.net/bugs/1535500
<slangasek> so it's not a simple "just rebuild with old compiler" change
<jderose> slangasek: okay, gotcha
<slangasek> jderose: would you be able to check whether this problem exists with older llvm-3.8 builds of mesa? (11.1.2-1ubuntu1 and later)
<slangasek> this might let us identify a regression in llvm-3.8 (if we're lucky)
<jderose> slangasek: sure, i can definitely check that. any advise on the best way to do this? (I'm assuming those older binaries aren't around anymore in the archive)
<slangasek> jderose: you can browse links on https://launchpad.net/ubuntu/+source/mesa/+publishinghistory and pull binaries 1-by-1 from launchpad
<slangasek> (sorry, no aptable index)
<jderose> slangasek: gotcha, can do... checking 11.1.2-1ubuntu1 now...
<slangasek> jderose: the last 3 builds of mesa were all built with the same version of llvm-3.8, and the 3rd from last update was a minor change for glibc 2.23 compatibility; we should be able to pin this down with some certainty to an llvm vs. mesa induced regression
<slangasek> (I have my suspicions but won't interfere with your testing)
<doko> added a note about the toolchain updates to the release notes
<doko> that changelog for juju-core-1 doesn't look very complete
<mgz> doko: oh yeah, I was going to stick the pre-fork changelog on the bottom
<doko> I'll leave to slangasek
<doko> I'll leave that to slangasek, even
<mgz> doko: wait, I *did* stick the pre-fork changelog on the bottom
<mgz> doko: so, you just mean the 1.25.5 entry?
<doko> mgz, maybe you forgot to build with the -v option?
<mgz> doko: I didn't actually build the uploaded package, I don't have rights
<mgz> balloons: ^
<slangasek> ok, NBS cleared, stokachu is off the hook
<stokachu> \o/
 * balloons looks around
<balloons> so stokachu, who is holding the short straw?
#ubuntu-release 2016-04-20
<slangasek> balloons: oh did you think my suggested binary package name of juju-1-i-hate-progress was a joke?  I was expecting to see that in the new queue ;-P
<balloons> slangasek, you missed the contest earlier
<balloons> I was soliciting names, and well, sinzui picked alfred
<slangasek> ah but you still have to get it past AA
<balloons> I thought it was a much better name, don't you think?
<superm1> Laney: so is the service's autostart .desktop file changing for gnome-software?  you might need to adjust that casper thing I did a week or two ago to keep it from starting on live media then too
<jderose> infinity: FYI, oem-config-gtk and ubiquity-frontend-gtk are missing after doing an OEM install from the 20160419 daily ISO (I recall before you mentioning that this can happen when the local archive is out of sync when the ISO is built)
<flexiondotorg> infinity, slangasek cyphermox pitti I've just zsynced that latest image and I'm still seeing the swap issue - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5`> Launchpad bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix released]
<flexiondotorg> If I boot the live desktop /dev/sda is mounted now.
<flexiondotorg> Which was not happening previously.
<slangasek> balloons, stokachu: juju-1-default needs to ship its /usr/bin/juju in the package, not create/remove it in the maintainer scripts
<slangasek> flexiondotorg: well, please reopen the bug; I don't really have context on this particular issue, I guess it needs cyphermox to look at it
<slangasek> except he may be EOD so it may be pitti's turn next
<stokachu> slangasek: ^ the name change
<balloons> slangasek, ohh..
<balloons> slangasek, so you don't want to see a symlink, but rather a wrapper script installed in /usr/bin/jujuj?
<slangasek> balloons: no, I want the link shipped by the package (and have just uploaded this fix)
<balloons> slangasek, ack, gotcha.
<balloons> ty
<slangasek> infinity, cyphermox: ok, ubuntu-cpc/xenial/daily-preinstalled failed, with an error that I can't see is related to the latest change...
<slangasek> yep, reverted latest commit and it still fails
<slangasek> so, hmm?
<cyphermox> slangasek: looking
<cyphermox> all the last commit was supposed to do was to put it in ubuntu-server rather than ubuntu-cpc
<cyphermox> slangasek: because no filesystem to use to build the image?
<slangasek> cyphermox: that appears to be the error message
<cyphermox> yeah
<cyphermox> there is no filesystem build for today
<slangasek> cyphermox: erm
<slangasek> I have never seen this error before; there is a 'livecd-base' cronjob but I've never known this to be relevant
<cyphermox> I think we're missing some hooks
<cyphermox> the lp build wasn't triggered?
<slangasek> cyphermox: so, no new build attempts shown here. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/cpc
<cyphermox> right
<cyphermox> is that also happening from ubuntu-cdimage?
<slangasek> cyphermox: what do you mean?
<cyphermox> are the builds there triggered from ubuntu-cdimage code?
<slangasek> erm
<slangasek> cyphermox: that was what your patch was supposed to be implementing
<slangasek> trigger build, download result
<slangasek> publish
<cyphermox> right
<cyphermox> we got the download, rename result and publish done now, so I guess we're just missing the triggering
<slangasek> heh, ok
<cyphermox> I expected it worked, since infinity fixed my initial merge
<cyphermox> did you get any output from running for-project ubuntu-cpc cron.daily-preinstalled ?
<cyphermox> hrm
<cyphermox> maybe that was missing --live.
<cyphermox> slangasek: yeah, that's my best guess, the code that starts the livefs is user run_live_builds, which won't get called if you're not passing --live.
<cyphermox> this could do with a unit test
<rcj> slangasek, going to spin cloud images.  doesn't look like there's anything we're waiting on now but you might know better.  Shall I fire off builds?
<slangasek> rcj: I don't know of anything you'd be waiting on; http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is rather dull
<slangasek> cyphermox: '--live'  - heh, was not part of the commandline I cut'n'pasted from infinity, no
<rcj> slangasek, oh now that is indeed a very handy thing.  Thanks.  Just kicked builds.
<slangasek> rcj: once upon a time we did reports that would show what on your latest image was out-of-date wrt the release pocket, maybe we should do something like that for -proposed also
<cyphermox> slangasek: just my guess from looking at the code, I'm not at all familiar with how the images are built aside from looking at the logs in LP and p.u.c/~ubuntu-archive/cd-build-logs
<cyphermox> well, getting thrown in the deep end certainly helps a lot, but I'm just a young padawan.
<slangasek> cyphermox: you're right that almost all of these images are built with --live on the commandline, I forgot about it because I believe in sensible default behavior and Santa Claus
<slangasek> cyphermox: this command is running something instead of exiting immediately - thanks ;)
<cyphermox> yippee
<rcj> slangasek, yeah, we have a manifest diff tool to know if we need to build a daily, but -proposed is opaque to us (and mostly that doesn't matter, just on weeks like this)
<cyphermox> I get to wipe this rpi2 again soonish then
<bluesabre> the above thunar package does not completely close any existing bugs, but should significantly reduce the number of crashes our users have experienced in testing
<slangasek> infinity: hmm I think we can probably prune the various precise/daily* paths under www/full now
<cyphermox> aren't those used for the unit tests?
<slangasek> cyphermox: ... that is not a reason to keep cruft on our CD servers
<tjaalton> doko, slangasek: I'll try to bisect llvm-3.7..3.8, the llvmpipe bug trigger should be there, since older mesa is just as affected
<tjaalton> sigh, packaging still uses svn
<cyphermox> oh cool, the cpc build worked and dropped things in the right place
<slangasek> tjaalton: where did you see that older mesa was affected?
<tjaalton> slangasek: from the bug? the original description
<tjaalton> "Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper.."
<slangasek> tjaalton: ok, I wasn't considering the version currently in xenial "older mesa" ;)
<tjaalton> heh, right, new one was staged at that point
<slangasek> tjaalton: I did ask jderose to test with previous builds from xenial, so we could check whether this regressed when the llvm toolchain was switched or if it regressed at some other point.  I suspect something more recent, and that we weren't really completely broken for installs on nvidia for 2 months
<tjaalton> slangasek: well this is mostly limited to skylake I bet, during 11.2~ bringup some new tests were failing (switch to dh enabled them) that I reported upstream (mesa), but it only happened on skylake builds. turns out it was due to llvm afterall
<pitti> flexiondotorg: please reopen and attach a current installer syslog
<tjaalton> slangasek: mesa llvmpipe tests pass fine with llvm-3.9 snapshot.. there's at least a commit to "Added Skylake client to X86 targets and features" which sounds like we should get
<flexiondotorg> pitti, Doing now...
<flexiondotorg> pitti, Just up to the point I ge the swap dialog?
<flexiondotorg> Typical. Didn't do it this time :-(
<flexiondotorg> pitti, OK. Reproduced. Just syslog?
<pitti> flexiondotorg: partman log also can't hurt
<flexiondotorg> pitti, Any in-particular you'd like them?
<flexiondotorg> *Anywhere
<flexiondotorg> This most recent image appears quite broken.
<flexiondotorg> a11y indicator no longer working in Ubuntu MATE. oem-config stuff is absent.
<flexiondotorg> pitti, syslog - http://paste.ubuntu.com/15942262/
<pitti> flexiondotorg: can you please attach it to the bug?
<flexiondotorg> pitti, As requested. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5`> Launchpad bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix released]
<flexiondotorg> I have to go to work now.
<pitti> cheers!
<pitti> flexiondotorg: was that an UEFI/GPT install or mbr?
<jibel> pitti, morning
<pitti> bonjour jibel, Ã§a va ?
<jibel> pitti, what do you think about bug 1572325? There is one PPA but I don't think it is what is blocking the upgrade
<ubot5`> bug 1572325 in ubuntu-release-upgrader (Ubuntu) "upgrade bug 14.04 to 16.04" [Undecided,New] https://launchpad.net/bugs/1572325
<jibel> pitti, Ã§a va bien et toi?
<jibel> pitti, tu es Ã  Londres?
<pitti> Ã§a va bien aussi, merci; non, je suis chez moi
<pitti> virtual participant only :)
<jibel> me too :)
<jibel> pitti, it looks like the hwe stack is holding it back
<jibel> too many upgrade bugs reporting in lp
<pitti> meh, no apt term log
<pitti> just let me set up that test install, then I'll have a look
<pitti> tjaalton uploaded some metapackages for the hwe stack yesterday for upgrades, maybe/hopefully it's that
<jibel> pitti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1572325/+attachment/4640212/+files/VarLogDistupgradeAptlog.txt
<ubot5`> Launchpad bug 1572325 in ubuntu-release-upgrader (Ubuntu) "upgrade bug 14.04 to 16.04" [Undecided,New]
<jibel> the calculation fails
<jibel> so there is no term.log
<pitti> the first "Broken" which cannot be repaired is apparently: Broken xorg:amd64 Depends on xserver-xorg
<jibel> probably similar to bug 1572298
<ubot5`> bug 1571677 in xorg-lts-transitional (Ubuntu) "duplicate for #1572298 upgrading caused a broken apt cache due to *-lts-vivid packages conflicting with current X packages" [Undecided,Fix released] https://launchpad.net/bugs/1571677
<pitti> meh, this is impossibly hard to read; I wish we had the output of apt that it normally shows
<jibel> yeah it's terribly hard to read, must read backward, back and forth several times
<jibel> recursive reading
<jibel> with some practice it's readable but I didn't do it for a while.
<nhaines> willcooke: oh, do you have a moment?  :)
<willcooke> nhaines, just doing the school run.  Be back in 20 mins or so
<nhaines> willcooke: thanks.
<nhaines> Oh hey, I just found an error in my merge proposal, grr.  :)
 * pitti promotes the xorg-transitional lot to main
<doko> rbasak, fixed your percona-server-5.6 upload, but didn't test the test package
<willcooke> nhaines, back
<nhaines> \o/
<nhaines> willcooke: I have an update for the package 'example-content' that I'd like to get reviewed and uploaded to xenial before release.  Also seb128 you listen, too.  :)
<nhaines> I'm not sure whom to poke about it.
<jibel> nhaines, seb128 is the last uploader
<jibel> talk to him
 * nhaines waves to seb128.
<jibel> nhaines, or dholbach who is the original maintainer
<nhaines> jibel: since he and dholbach weren't around an hour ago, I was looking for other alternatives.
<jibel> nhaines, you'll find him on #ubuntu-devel
<nhaines> jibel: oh!  I was expecting him at least in -locoteams.  Thanks!
<seb128> shrug
<seb128> nhaines, first, good morning
<seb128> then I just joined IRC for like 1 minutes and you pinged me 3 times already
<seb128> let's call down please :-)
 * seb128 feels agresssed
<nhaines> seb128: sorry, been working for about 12 hours today and falling asleep.  I'm just hoping to set up an overview before I do lose consciousness!
<pitti> meh, no "prepare for OEM" icon on the desktop, /me files a bug
<seb128> pitti, on what desktop?
<seb128> nhaines, I can sponsor that in the next hour, unsure if the release team is wanting to take an update for it now though
<pitti> seb128: when you install in OEM mode, the  oem session used to have a "Prepare for OEM install..." icon
<pitti> that's also in the test case description on http://iso.qa.ubuntu.com/qatracker/milestones/359/builds/117327/testcases/1305/results
<pitti> that went AWOL
<seb128> pitti, oh ok, I didn't try OEM mode for a while
<seb128> had forgotten about that ;-)
<nhaines> seb128: great.  I know it's way too late, but there were all sorts of content licensing issues with the video submissions (that I subverted by just creating original content).  It turns out installing Ubuntu 24 times takes a very, very long time.
<jibel> davmor2, ^ did you notice that?
<jibel> pitti, usually it happens when oem-config on the iso and in the squashfs have different versions
<jibel> ubiquity* in the squashfs
<jibel> a respin should fix it
<jibel> argh and i386 has not been copied to current/
<seb128> jibel, just curious but in which way the icon fails to be created when those are out of sync?
<pitti> err, there's not even an oem-config-prepare command
<seb128> we should have an autopkgtest or something ensuring one doesn't migrate without the other one
<pitti> yes, and ubiquity should be  current on the images
<jibel> pitti, /pool/main/u/ubiquity/oem-config_2.21.59_all.deb is on the iso and ubiquity2.21.60 on the squashfs
<pitti> this is deeper, I think the whole ubiquity/oem packages are missing
<cjwatson> seb128: they're the same source package
<cjwatson> jibel: hm, that usually only happens when the mirror is stale on cdimage, but I fixed that class of problems a little while back I thought
<jibel> cjwatson, okay, so maybe it is not the problem then.
<cjwatson> jibel: it is the problem, I'm just looking into why :)
<jibel> ah :)
<davmor2> jibel: notice what?
<jibel> davmor2, no oem-prepare in the live session
<pitti> bug 1572436
<ubot5`> bug 1572436 in ubiquity (Ubuntu Xenial) ""Prepare for OEM install" icon missing on desktop" [High,New] https://launchpad.net/bugs/1572436
<cjwatson> unlikely to be a ubiquity bug given this
<pitti> err, I changed the bug title when filing the description, apparently that was ignored
<cjwatson> -rw-rw-r-- 1 cdimage cdimage 293029 Apr 20 06:56 rsync.log.0
<davmor2> jibel: there never is in the live session it is in the initial installed session, but I didn't bother with iso's yesterday as they were going to be respun
<cjwatson> ok, so that's recent
<davmor2> I'll try it now though
<davmor2> Last time I tried it was there though so that was Friday
<pitti> I attached the syslog
<pitti> oem-config* does not get removed, but there's no sign of them getting installed either
<jibel> davmor2, sorry, you're right
<pitti> jibel: well, if that's the reason, we need to respin anyway
<pitti> who can trigger respins these days?
<cjwatson> pitti: won't get installed if it's uninstallable
<cjwatson> pitti: I'm waiting for the rest of the London crew to get in before I start, just in case there's something else
<pitti> cjwatson: ah, strict dependency on ubiquity, sure
<flexiondotorg> pitti, It was mbr install.
<pitti> but updated
<pitti> flexiondotorg: ah, thanks
<pitti> yofel: how important is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#akonadi for the release? i. e. do we unblock and respin kubuntu for this?
<yofel> pitti: hold off for that, I'm just making another upload, and once that's up we will need a respin as akonadi in release doesn't work at all with mysql 5.7
<pitti> yofel: ack
<pitti> we might want a full respin for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup anyway (not sure if that's destined to an SRU or the final)
<flexiondotorg> pitti, I found that reproducing the swap issue using VirtualBox was the most reproducible way.
<flexiondotorg> So that test install was in VirtualBox.
<flexiondotorg> You can reliably recreate the situation as follows.
<cjwatson> this is certainly looking like full respin territory due to the cdimage mirror desync
<flexiondotorg> Install Ubuntu 15.10 in VirtualBox. Do a full disk install without any encryption and withoutout LVM.
 * adconrad glares at his colo machine going offline during release week.
<pitti> hey adconrad
<pitti> adconrad: wrt. your earlier ping, the new snapd is good; a test retry worked
<flexiondotorg> After installed, boot 16.04 iso in the same VM and attempt a full disk install over that disk. You should run into the swap issue.
<adconrad> pitti: Ta.
<cjwatson> I can't quite puzzle out exactly why this happened, unfortunately; the timings only tell me that there was a build which thought it was running in parallel at 21:52:40 UTC, but not what it was running in parallel with
<cjwatson> my suspicion is that we're locking the mirror a little too aggressively, for things that don't need the mirror, but meh
<jamespage> hi release team
<jamespage> we just hit a problem during final openstack testing on xenial today;
<jamespage> we test on an openstack cloud, using the daily image stream's
<jamespage> and the latest images are renaming the virtual network devices:
<jamespage> Apr 20 08:06:00 ubuntu kernel: [    3.491798] virtio_net virtio0 ens2: renamed from eth0
<adconrad> Is that not by design?
<pitti> jamespage: I thought the latest cloud-init does that now?
<tjaalton> jibel: do you have the transitional crap available?
<pitti> I mean, stop hardcoding eth0 and supplying net.ifnames=0
<pitti> and instead set up /e/n/i dynamically
<pitti> i. e. I thought net.ifnames=0 got dropped deliberately, not accidentally
<adconrad> jamespage: I suspect you want to talk to smoser, but pretty sure this is all working as he intended.
<jamespage> pitti, I don't know the context for this change in behaviour
<jibel> tjaalton, what do you mean?
<tjaalton> jibel: what xorg-lts-transitional provides in xenial
<tjaalton> use a mirror which has it
<jibel> looking
<nhaines> willcooke, jibel: everything got sorted with my issue.  Thanks for your help--now I get to go to sleep.  :)
<jamespage> adconrad, pitti: cloud init has not changed since 15th
<willcooke> nhaines, good stuff.  Enjoy sleep
<jamespage> did we have a blip in daily image production?
<adconrad> jamespage: Nothing else that would affect that has changed any more recently.
<Odd_Bloke> jamespage: That's intended behaviour that changed in the image.
<pitti> so what is the actual bug?
<jamespage> Odd_Bloke, when did that change?
<pitti> I suppose the net.ifnames= flag is not in cloud-init but in the cloud image build scripts (is that livecd-rootfs?)
<Odd_Bloke> jamespage: I can check the exact timing, but I think it was early last week.
<Odd_Bloke> Yeah, it's livecd-rootfs.
<Odd_Bloke> jamespage: This was to align us with the rest of Ubuntu (including -server).
<pitti> adconrad: apt in trusty/wily got fully tested with several upgrades and installs; any objection to me releasing now? might save a few failed upgrades
<Odd_Bloke> jamespage: And it arrived so late because some matching cloud-init work was needed for us to not completely break all of our clouds during the development cycle.
<jibel> tjaalton, I couldn't find a mirror with xorg-lts-transitional
<adconrad> pitti: Go for it.
<adconrad> jibel: Are you testing with universe enabled?  It needs seeding/moving to main, which I haven't done yet.
<pitti> adconrad: it's done
<pitti> but I only promoted them an hour ago or so
<adconrad> Oh.
<adconrad> pitti: Thanks.
<jibel> adconrad, yes, universe it enabled
<jibel> it is probably just not snyc to the mirrors yet
<yofel> pitti: ^
<pitti> adconrad: want me to unblock http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup now, so that we don't have to wait for that for the rebuild?
<pitti> adconrad: (need to rebuild anyway due to the above mirror desync)
<adconrad> pitti: It's not the only thing relevant to a new rebuild, I'll get everything at once.
<pitti> adconrad: ack, leaving to you then
<yofel> pitti: actually, please reject that
<pitti> I'll look at that swap thing then
<tjaalton> jibel: released one hour ago
<pitti> yofel: rejected
<yofel> thanks
<yofel> pitti: now ^
<tjaalton> doko: so llvm-3.8 needs backports to detect skylakes better. do you prefer a complete patchset with all the avx512-churn for xeons, or the bare minimum?
<pitti> yofel: ack, thanks, waved through
<yofel> pitti: thanks!
<pitti> yofel: (only into -proposed, still needs an unblock to actually land)
<rbasak> doko: ah I missed that. Thanks.
<doko> tjaalton, isn't llvm maintained by the desktop team? ;p
<adconrad> tjaalton: Is that the cause of jderose's complaints?
<tjaalton> guess that'd be me
<tjaalton> adconrad: most definitely
<adconrad> tjaalton: So, there's a *chance* to fix it for release?
<tjaalton> yes
<adconrad> \o/
<davmor2> jibel: confirmed oem-config is missing checking to see if it is on the system at all
<doko> tjaalton, well, take what is likely to appear in the llvm 3.8 branch
<rbasak> I think the build is a little unstable. I'll retry i386.
<tjaalton> doko: I checked git, there's nothing for this. is there an upstream I can yell at?
<jibel> davmor2, it's all right, don't waste your time one this
<jibel> on*
<pitti> davmor2: right, the oem bug is fully understood
<davmor2> nice so another re spin in 10.....9......8......
<pitti> davmor2: I think you should start counting at ~ 2000 rather
<doko> tjaalton, ENOCLUE
<jamespage> adconrad, pitti: just for full context on the behavioural change in the cloud-images - the change was made last week, but for various reasons the updated images did not get synced/into stream data until the last 24 hrs...
<tjaalton> doko: trying sylvestre..
<tjaalton> better yet, #llvm@oftc
<pitti> flexiondotorg: is that "Erase ubuntu 16.04 LTS and reinstall" or "Erase disk and install Ubuntu"?
<pitti> flexiondotorg: I think the former keeps the partitions but removes the files, the latter repartitions
<flexiondotorg> pitti, Minute. In the middle of server deployment at work. Give me 5...
<pitti> flexiondotorg: with the latter I get a correct mkswap/reactivate in syslog
<pitti> trying the former now
<LocutusOfBorg> asking a virtualbox exception in a few minutes
<LocutusOfBorg> :(
<flexiondotorg> pitti, "Erase disk and install Ubuntu"
<LocutusOfBorg> upstream asked to include this one line patch https://www.virtualbox.org/changeset/60565/vbox/trunk/src/VBox/Devices/Storage/DevLsiLogicSCSI.cpp#file0
<pitti> flexiondotorg: hm, that's what I tried
<LocutusOfBorg> ^^
<LocutusOfBorg> I also uploaded on debian, so we can just sync if needed
<rbasak> And...my laptop PSU seems to be dead. Good week for it.
 * rbasak watches his battery drop
<apw> rbasak, oh man that sucks, what kind of machine is it
<doko> LocutusOfBorg, the version number is wrong ...
<rbasak> Samsung ARM Chromebook. It's OK, I have a computer here I can use too.
<LocutusOfBorg> doko, what do you suggest
<rbasak> (as in a desktop)
<LocutusOfBorg> I uploaded -3 in debian, I want to sync
<LocutusOfBorg> and cjwatson suggested a build1 to let autosync do its job
<doko> LocutusOfBorg, well ... it has a delta. you don't know if you will have the time to sync ... but I don't care
<LocutusOfBorg> pick the one you want ^^
<LocutusOfBorg> :)
<adconrad> Neither.
<Laney> BOTH
<cjwatson> LocutusOfBorg: I think I would have suggested -3~build1, not -2build1
<LocutusOfBorg> well, ubuntu1 is fine, I can force sync after xenial
<LocutusOfBorg> :)
<Odd_Bloke> Laney: Needs more .0-ubuntu1? ^_^
 * Laney the version doctor
<doko> adconrad, the libsemanage rebuild didn't yet happen
<pitti> no, please no "ubuntu" version numbers for no-change builds
<adconrad> doko: Gah.  Doing over the next half hour.  Thanks for the reminder.
<LocutusOfBorg> pitti, I did a change
<LocutusOfBorg> it is a no change from debian -3 revision
<LocutusOfBorg> I mean, -2ubuntu1 is the same as the upcoming debian -3
<LocutusOfBorg> adconrad, upstream is looking at your modules patch
<Laney> OK, enough of the version porn :P
<LocutusOfBorg> BTW can anybody please make hedgewars migrate? it needs a rm of the powerpc binary I guess
<LocutusOfBorg> since fpc is broken there
<LocutusOfBorg> (also migrate fpc please)
<LocutusOfBorg> we have ffmpeg fixes on proposed, I want people to use video recording features
<adconrad> I might remove all the PPC rdeps of fpc for now, yeah.
<LocutusOfBorg> it will require a bootstrap anyway I think
<LocutusOfBorg> ta
<LocutusOfBorg> I still hope to plain sync it, I don't like deltas
<LocutusOfBorg> also adconrad "polybory/armhf" please remove
<LocutusOfBorg> broken, we don't know why, we removed that binary on debian too
<LocutusOfBorg> and nifti2dicom on powerpc
<LocutusOfBorg> I did a lot of work on it
<flexiondotorg> pitti, I'll try and create an image that will fail here.
<flexiondotorg> If I can do that, I can snapshot and transfer it.
<pitti> flexiondotorg: I'm currently trying with doing a manual install in the second round, someone got the error with that
<pitti> flexiondotorg: getting the base image is no problem at all I figure
<pitti> just have a swap partition on [sv]da5
<flexiondotorg> I tried doing this with cyphermox.
<flexiondotorg> pitti, Yes, just having swap seems to be sufficient, but not in an lvm.
<Laney> RAOF: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dovecot is making me sad with sadness
<yofel> pitti: akonadi is built, could you please unblock it?
<pitti> adconrad: ^ do you want to handle that together with your global sweep, or should I do that now?
<cjwatson> pitti: if I do https://bugs.launchpad.net/ubuntu/+source/language-pack-kde-wa/+bug/1527035 is your stuff going to try to reupload it in an SRU?
<ubot5`> Error: Could not gather data from Launchpad for bug #1527035 (https://launchpad.net/bugs/1527035). The error has been logged
<cjwatson> what.  anyway, that's a removal request
<pitti> cjwatson: as long as it stays below 5%, it won't; but if someone translates it enough it will come back, yes
<pitti> cjwatson: but not -kde-*, those are manually maintained, those aren't me
<cjwatson> ah ok
<adconrad> pitti: Aye.
<Laney> (xenial-amd64)root@nightingale:~# dpkg -L dovecot-core | grep --color=none so.0 | xargs ldd
<Laney> /usr/lib/dovecot/libdovecot-fts.so.0.0.0: linux-vdso.so.1 =>  (0x00007ffce4745000) libstemmer.so.0d => /usr/lib/x86_64-linux-gnu/libstemmer.so.0d (0x00007faa0cda3000)
<cjwatson> clickety
<pitti> cjwatson: oh, wait -- I guess they were actually
<pitti> cjwatson: we used to produce l-p-kde-*, but not for a long time; it still has a 14.04 version number
<pitti> I guess we only kept them for upgrades, and can remove them wholesale post xenial
<cjwatson> well, it was uninstallable anyway, so I've removed it
<pitti> right, for this particular one
<pitti> thanks
<davmor2> pitti: I have a box I can reproduce the swapspace issue on before todays iso, I'll try todays and see if I can still reproduce it, the fix didn't land until the latest iso though right?
<adconrad> rbasak: Can mysql-5.6 go now?
<pitti> davmor2: there's no fix yet
<rbasak> adconrad: as soon as percona-5.6 and pinba-engine-mysql have hit the release pocket, I think so, yes.
<pitti> davmor2: I thought this was only on GPT, there the casper change could have helped, but as it also happens on MBR there's no change
<rbasak> adconrad: what did you do to infinity?
<davmor2> pitti: I thought you made a systemd change that could potentially fix it
<adconrad> rbasak: The server infinity has been on for the last 4 years mysteriously died last night.
<pitti> davmor2: yes, but it didn't
<pitti> davmor2: I don't understand what happens so far, no luck in reproducing
<rbasak> infinity: along with my laptop PSU and my openstack instance? Sounds suspicious.
<davmor2> pitti: balls, I can see if I can reproduce the issue at least and enable ssh for you, you can dig around the system to your hearts content then
<pitti> davmor2: i. e. ssh to a live session where ubiquity will fail? ok
<pitti> not that I would actually know what partman is trying to do, but seeing it live might help
<davmor2> pitti: let me see if I can reproduce it in live session first
<Odd_Bloke> So I see that console-setup looks like it's going to migrate; is the plan to respin for that?  (And should I kick off a respin of cloud images once it lands?)
<Odd_Bloke> infinity: ^
<cjwatson> there needs to be a full respin anyway due to an image building snafu :-/
<infinity> Yeah.
<infinity> There's a full respin on the horizon.
<infinity> Odd_Bloke: I'll poke you when we re-freeze for another respin, so you can get cloudy.
<nhaines> Could someone review http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#example-content ?
<bluesabre> infinity: is there any way we can get https://launchpad.net/ubuntu/+source/thunar/1.6.10-2ubuntu1 out of proposed before the full respin? :-)
<infinity> bluesabre: It's on the way.
<doko> Apparently successful
<doko> final: console-setup,grilo-plugins,thunar,virtualbox
<nhaines> It's a non-binary new content update, with the remaining Ubuntu Free Culture Showcase results.
<bluesabre> infinity: thanks :)
<Odd_Bloke> infinity: Ack, thanks. :)
<rbasak> Struggling to edit the release notes - 500 Internal Server Error logging in :-/
<rbasak> Now logged in but the page is immutable.
<cjwatson> rbasak: bug 1564858 - I don't suppose you'd like to have a really quick look over "reverse-depends src:nagios-plugins"?  Some of those are false positives due to alternative deps, but at least some of the Recommends seem to be real and I'm loath to break those at the last minute
<ubot5`> bug 1564858 in nagios-plugins (Ubuntu) "Please remove nagios-plugins from the archive" [Undecided,New] https://launchpad.net/bugs/1564858
<rbasak> cjwatson: looking
<infinity> LocutusOfBorg: Oh, you upstreamed my vbox patch?  Thanks!
<LocutusOfBorg> yep :) thanks to you1
<LocutusOfBorg> they already applied it in a similar way (they added a -revision part, to handle people building custom svn versions)
<darkxst> vbox is the only thing holding us back from root-less Xorg ;(
<LocutusOfBorg> darkxst, NO
<LocutusOfBorg> NO NO :D
<LocutusOfBorg> all the bothering I did here in the last few days was to have a root-less xorg with vbox
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=cc16e5049641855149fe9d6b091415bebcc58d3d
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=97c3c9c3056c7d2c21670a23f8e758921ffc12f2
<darkxst> LocutusOfBorg, is that going to land before release?
<LocutusOfBorg> already landed
<LocutusOfBorg> :)
<LocutusOfBorg> I tested it on a clean xenial and unstable virtualbox guests
<LocutusOfBorg> everything is fine
<darkxst> LocutusOfBorg, when?
<LocutusOfBorg> yesterday
<LocutusOfBorg> and some days before
<LocutusOfBorg> the commit is from 6 days ago, and I tested it on debian
<LocutusOfBorg> but I re-tested 5.0.18 yesterday, when I pushed it on unstable and xenial
<rbasak> cjwatson: nagios-plugins and nagios-plugins-basic are taken over by src:monitoring-plugins as transitional packages. Here are my notes: http://paste.ubuntu.com/15944747/
<rbasak> cjwatson: I think that covers all of them?
<rbasak> cjwatson: I'd appreciate you double checking me here though.
<darkxst> LocutusOfBorg, our spin from about 12 hrs ago, doesnt work with root-less X
<LocutusOfBorg> darkxst, how did you test it
<darkxst> LocutusOfBorg, remove xserver-xorg-legacy and restart gdm3
<LocutusOfBorg> do you have a chan for discussing this?
<LocutusOfBorg> -release might not be the best place
<darkxst> #ubuntu-gnome
<cjwatson> rbasak: oh, right, I totally missed the transitionals
<cjwatson> rbasak: no-brainer then, thanks for the cluebat
<cjwatson> teward,infinity: one of you two want to weigh in on https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1529681 ?  I'm pretty sure the answer is "no" but could use a proper explanation
<ubot5`> Launchpad bug 1529681 in electrum (Ubuntu) "Please sync Electrum from Debian testing" [Undecided,New]
<cjwatson> teward: (never mind, infinity did it)
<cjwatson> sanity check, does https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1560512 still make sense given the current plan to keep both juju 1 and 2 in xenial?
<ubot5`> Launchpad bug 1560512 in juju-quickstart (Ubuntu) "Please remove juju-quickstart from xenial" [Undecided,New]
<cjwatson> jamespage: there's a question for you in https://bugs.launchpad.net/ubuntu/+source/openvswitch-dpdk/+bug/1549668; does it block removal?
<ubot5`> Launchpad bug 1549668 in openvswitch-dpdk (Ubuntu) "Please remove openvswitch-dpdk from xenial" [Medium,Confirmed]
<flexiondotorg> pitti, Anything useful I can do to help with the swap issue?
<jamespage> cjwatson, yeah - the openvswitch source package now provides the dpdk binaries directly
<jamespage> cjwatson, openvswitch-dpdk was a workaround for last cycle for universe...
<cpaelzer> jamespage: beat me with the reply :-)
<pitti> flexiondotorg: I guess the next steps is to find out what partman is doing precisely; if it issues shell commands, then running just those in a terminal might reproduce the issue as well
<jamespage> so no I don't think that blocks removal - I'll comment
<nhaines> Laney: could you take a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#example-content for me?  I'd like to get that into release since we're respinning images anyway.  It's the Ubuntu Free Culture Showcase results.
<pitti> flexiondotorg: there should be some swapoff, mkswap, swapon at least, maybe a wipefs too
<cjwatson> jamespage: that seems like a non sequitur, the question is about ovs-vswitchd
<cjwatson> (if that's dpdk-related, that's fine, but don't expect an archive admin to know that)
<jamespage> cjwatson, thats the main binary name for ovs
<jamespage> we have two versions - vanilla and dpdk enabled
<cjwatson> ok, don't tell me, tell the bug :)
<jamespage> cjwatson, I commented on the bug..
<cjwatson> ah ok
<cjwatson> thanks, that's all
<cjwatson> I don't need to learn about ovs, I'm just trying to get the ubuntu-archive subscribed bug list under control :)
<Laney> nhaines: Nothing to do there, it says it's a valid candidate
<nhaines> Laney: oh!  It updated on me!
<nhaines> infinity: thanks!  :)
<flexiondotorg> pitti, OK. Are the partman commands issued via code in ubiquity or code in partman? I'll look through the source and see what it is doing.
<pitti> flexiondotorg: I don't know for sure, but I think that's all partman
<nhaines> Laney: thanks to you too.  :)
<pitti> flexiondotorg: ideally partman.log would even tell the commadns it runs, but it doesn't
<flexiondotorg> pitti, OK. I take a look at lunch time. 1 hr from now.
<davmor2> pitti: see pm ssh all setup for you and system is in the warning screen
<pitti> davmor2: thanks; just finishing my current thing, will then have a look
<tjaalton> doko: how much does llvm need disk space when building?
<LocutusOfBorg> tjaalton, around 50GB
<tjaalton> sheesh..
<LocutusOfBorg> probably a little more now
<tjaalton> no wonder it didn't fit in my ramdisk..
<doko> tjaalton, below 50G, succeeding on the buildd's ;)
<LocutusOfBorg> doko, last time I checked it was increasing
<doko> tjaalton, ahh, but we remove some part of the build before installing ...
<LocutusOfBorg> well, with 3.8 there is an find *.a -delete before dh_install
<LocutusOfBorg> so we save some space
<tjaalton> heh, ok
<tjaalton> I'll build it elsewhere then
<infinity> doko: libsemanage sorted.
<LocutusOfBorg> tjaalton, ppa? DebOMatic?
<LocutusOfBorg> I can start a build if you give me a dsc
<tjaalton> LocutusOfBorg: nah, locally with schroot, just need to attach another ssd..
<LocutusOfBorg> as you wish
<tjaalton> disabling avx512 on skylake, that should fix most issues but would still leave hsw-e with a big WTF
 * LocutusOfBorg wonders if tjaalton found some brokeness on llvm
<tjaalton> yes
<LocutusOfBorg> please share :)
<tjaalton> it enables features on skylake only found on xeons
<tjaalton> breaks llvmpipe
<tjaalton> llvm-3.9 is fine
<LocutusOfBorg> :(
<tjaalton> but dropping avx512 is something 3.8 might get upstream
<tjaalton> so that's what I'll try
<LocutusOfBorg> I see the bug
<Laney> superm1: service> no, that bit is the same
<Laney> you just rm-ed the file right?
<xnox> Laney, cjwatson, infinity, apw: review please http://paste.ubuntu.com/15945830/
<tjaalton> hm, how come libsemanage1-dev is uninstallable? can't build sssd
<doko> tjaalton, proposed? infinity might need to re-upload the version which was removed before
<tjaalton> ahh ok
<tjaalton> saw that now
<infinity> doko: I did.
<infinity> tjaalton: Where are you seeing it uninstallable?
<tjaalton> infinity: here, trying to build a version with a new patch
<infinity> tjaalton: Seems installable to me...?
<tjaalton> is it on archive.u.c yet?
<infinity> tjaalton: Unless in conjunction with things like polkit in -proposed then, yes, wait a bit.
<tjaalton> ah
<tjaalton> yep
<infinity> Should be resolved in ~10m.
<tjaalton> cool, llvm build should finish about now so I'll just test that in the meantime :)
<xnox> cjwatson, show the other template
<xnox> which is like vlan_error
<xnox> or some such.
<xnox> which tells people to go away
<cjwatson> vlan_failed?
<xnox> cjwatson, netcfg/vlan_failed
<xnox> yes
<cjwatson> mkay, not ideal but would work
<cjwatson> superm1: hm.  should I remove mythnettv-gui as well as mythnettv?
<superm1> Laney: yes, sounds fine then
<superm1> cjwatson: yes
<cjwatson> superm1: all right, thanks, done
<superm1> Thanks
<tjaalton> infinity:  libsemanage1-dev : Depends: libsemanage1 (= 2.3-1build3) but 2.4-3build1 is to be installed
<cyphermox> flexiondotorg: pitti: I take it the swap is still an issue?
<pitti> cyphermox: yeah, keeping notes in the bug
<pitti> being completely ignorant what actually happens in partman & co I'm tryign to understand this from strace
<pitti> and of course totally not reproducible here
<cyphermox> pitti: SSD?
<pitti> I have an ssd, or QEMU etc., so faster devices, yes
<pitti> davmor2's is spinning rust
<cyphermox> yeah
<cyphermox> I'm also on SSD and using QEMU. I'll dust one of the older laptops
<cyphermox> so, I'll help testing on metal and spinning rust.
<pitti> cyphermox: and of course enabling debugging (systemd-analyze set-log-level debug) just got davmor2 past the point where it failed
<davmor2> pitti: and again
<cyphermox> ok
<davmor2> meh
<davmor2> oh hang on though you said swapon failed right?
<pitti> davmor2: again what? succeeded? I reset the log level back to info
<davmor2> pitti: if swap on failed then the system won't try and use it for swap right?
<pitti> davmor2: well, /dev/sda3 is in swapon -s, so whatever happened it's on right now
<davmor2> pitti: okay let me try it again then
<davmor2> pitti: error is back up
<cyphermox> swapon must be doing some syscall we could trace with systemtap, so we'd know exactly who tries to bring up swap in every single case
<pitti> cyphermox: the usual mechanics is that some program like mkswap open()s the device for writing, and on close() the kernel triggers a change uevent; this might then trigger $whatever
<pitti> that's how udev, mdadm, etc. learn about newly created partitions
<cyphermox> sure
<cyphermox> but then they must call swapon
<infinity> tjaalton: In a chroot?
<pitti> I don't know systemtap, if that can tell us what happens between swapoff and mkswap (as that's where the bug is, *before* swapon in ubiquity), that'd be great
<davmor2> pitti: I've given cyphermox the ssh access details too incase you need some extra eyes and I'm back on the error page
<infinity> tjaalton: I don't see that in either proposed or release.
<cyphermox> pitti: what do you mean before then?
<infinity> tjaalton: You have a broken chroot.
<cyphermox> davmor2: no, first I'll set up a pristine env in which I can reproduce
<pitti> davmor2: ah nice, thus now I have a debugging log with the original error
<cyphermox> pitti: the thing is, you kind of need to know what you're looking for to use systemtap.
<pitti> cyphermox: ubiquity doesn't get to swapon, it's already failing at mkswap
<tjaalton> infinity: alright then
<cyphermox> ok
<pitti> cyphermox: as it looks like, something (via udev) tries to call swapon while mkswap is still running/not done yet
<cyphermox> pitti: only because the swap is already brought back "on" by something?
<infinity> tjaalton: Looks like you half-upgraded to proposed at some point and then disabled it?
<cyphermox> pitti: I can probably trace both calls
<tjaalton> infinity: yep, for the mesa/llvm-3.9.. downgraded these bits now
<pitti> cyphermox: yes; in strace, swapoff is called from ubiquity, then it calls mkswap; but before mkswap even opens the device for writing, it checks /proc/swaps and there sda3 is already back on
<cyphermox> interesting
<cyphermox> pitti: is the strace output in the bug?
<infinity> pitti: What would be aggressively reenabling swap?
<pitti> so it's "swapoff" - (something in the background runs swapon) -- ubiquity calls mkswap -- whoops, busy
<infinity> pitti: That's a vile bug.
<pitti> cyphermox: yes, I left everything in the bug so far
<pitti> infinity: that's the answer we are looking for :)
<cyphermox> pitti: infinity: yes, that was my understanding too
<davmor2> pitti: could it be the size of the drive and memory in the system? It's a 1 TB drive and 8GB of memory that would make the swap bigger right?
<pitti> davmor2: I'd say it's less likely; swapoff worked, so your system did not run out of RAM; also, 8 GB is plenty
<cyphermox> pitti: that's why I was saying that I could maybe tell you which process calls swapon()
<pitti> cyphermox: right; I think that'd be very useful
<cyphermox> give me a sec, this should be a very simple script
<pitti> I suppose it's some magic from the dev-sda3.swap systemd unit, but I can't trigger that behaviour with CLI tools
<pitti> like, call swapoff manually, it doesn't come back on
<pitti> cyphermox: so in that sense, systemtap is a bit like attaching strace to every process?
<cyphermox> yeah
<pitti> cyphermox: so, I finally got a debug journal while that bug happens; I'll attach it to the bug
<pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.device: Changed dead -> plugged
<pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: Trying to enqueue job dev-sda3.swap/start/fail
<pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: Installed new job dev-sda3.swap/start as 2745
<pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: About to execute: /sbin/swapon /dev/sda3
<pitti> that answers *what* calls swapon
<pitti> now we need to understand how
<cyphermox> well, then we're past the point systemtap can help
<cyphermox> this would probably just be grepping through systemd
<pitti> err, why is the swap partition in /etc/fstab
<pitti> that's irritating
<pitti> (in the life system, I mean)
<pitti> anyway, need some time to ponder this
<cyphermox> could it be that we write to fstab before calling swapon/mkswap?
<knome> ;)
<knome> hmm, oops
<cyphermox> knome: that was an appropriate response actually ;)
<pitti> cyphermox: oooh, we do that?
<knome> happy i could help then :)
<pitti> cyphermox: because that would totally explain it
<cyphermox> pitti: I don't know, but I never checked *that*
<pitti> cyphermox: hm, no, no fstab in the strace
<pitti> cyphermox: I guess that's already done earlier, in casper maybe?
<pitti> that fstab line explains why there's a dev-sda3.swap unit in the first place
<pitti> it's read at boot, then /dev/sda3 gets an add/change uevent from the writing, systemd thinks "oh, my sda3 finally came online, let's mount/swapon this"
<cyphermox> pitti: in casper?
<cyphermox> oh, I see what you mean
<pitti> well, that still doesn't explain why I wouldn't get that on the command line
<cyphermox> I don't know, I thought it was maybe possible that when partman does the partitioning it would write to fstab before running mkswap
<pitti> right, sounds plausible, but we ought to see that in the strace then
<cyphermox> I don't know what you're tracing
<cyphermox> this is all shell scripts
<pitti> cyphermox: I basically just attached strace -fvvs1024 to the running ubiquity and then asked davmor2 to re-trigger the bug
<pitti> and the -f traces all children too
<cyphermox> well, I checked, the fstab.d scripts (what might write a swap entry to fstab) run from finish.d, so at the end, much after mkswap
<cyphermox> was worth just making sure that it was indeed the case even if I didn't doubt it
<pitti> ah, good, so this machine might be tainted now
<cyphermox> why?
<pitti> partman succeeded once, davmor went back to it to repartition to retrigger the bug
<pitti> I mean if this isn't origianlly in /etc/fstab
<cyphermox> oh, indeed
<pitti> cyphermox: hm,  but shouldn't partman write the /target's fstab, not the life system's?
<cyphermox> but we could reproduce this easily then
<cyphermox> pitti: /target of course, yes
<pitti> ok, nothign cares about that in the life system, so we can ignore that
<cyphermox> right
<pitti> /target isn't even mounted at this point
<cyphermox> fwiw
<cyphermox> scripts/casper-bottom/13swap:FSTAB=/root/etc/fstab
<cyphermox> scripts/casper-bottom/12fstab:DESCRIPTION="Configuring fstab..."
<cyphermox> scripts/casper-bottom/12fstab:FSTAB=/root/etc/fstab
<pitti> yeah, 13swap is what I meant
<pitti> my gut feeling is that a cheesy workaround for this would be to simply not write this to the life system's fstab
<cyphermox> ubiquity should probably remove swap entries from the live fstab, or if we can just run swapon directly instead of adding to fstab.
<pitti> I don't see why we actually need this -- we can swapon the partitions we find if we insist (although IMHO that goes a bit against "don't touch the hard disks")
<pitti> I'd still like to actually understand the bug, though
<cyphermox> pitti: not any more than zeroing it just before..
<cyphermox> oh wait, nevermind
<cyphermox> still, just adding it to fstab will have the same effect as running swapon
<pitti> so, I do swapoff
<cyphermox> yeah, then remove from fstab?
<pitti> I am now trying to tickle the system so that it auto-swapons
<cyphermox> oh ok
<pitti> I tried blkid -p /dev/sda3, dd if=/dev/sda3 of=/dev/null, and even udevadm trigger --verbose --sysname-match=sda3
<pitti> none of this triggers it, *grumpf*
<pitti> davmor2: can you reliably reproduce this with every life system boot?
<pitti> davmor2: I guess in order to try this you need to shut down the ssh session that you gave us?
<pitti> hm, so do we want to try the above workaround, or do we want to continue debugging on this box..
<pitti> not even mkswap triggers this
<davmor2> pitti: indeed,  I have been able to reproduce it reliably on this box and the macbook with spinning platters since around final beta
<davmor2> pitti: and I have been doing loads of installs on them so yes it is pretty reliable
<pitti> davmor2: ok, could you try this: reboot the live system with break=casper-bottom, in the shell rm /scripts/casper-bottom/13swap, then continue and see if you still get the bug?
<pitti> davmor2: (do you know where to add that breaks=?)
<pitti> (mind you, this is not a fix, but its results are an useful data point)
<pitti> and in the meantime I'll try to make some sense of this in a local VM
<davmor2> pitti: nope
<pitti> davmor2: ok:
<pitti> 1) press a key at the human == keyboard screen, ack the language
<pitti> 2) press F6, and then Escape to close the menu
<davmor2> pitti: ah so end of the kernel line
<pitti> you should now see a line "Boot options" ...
<pitti> then <space> break=casper-bottom<Enter>
<pitti> then you  should end up in a prompt like (initramfs)
<pitti> where you rm /scripts/casper-bottom/13swap
<pitti> and then just Ctrl+D to continue
<davmor2> pitti: slightly different this is a uefi system so just hit e to edit the line added the break=casper-bottom after the boot=casper and that dropped me to the initramfs busy box to rm the script
<pitti> davmor2: ah right, yes; that's a bit easier indeed
<davmor2> pitti: try number 2 still got to the location page with no error I'll give it another couple of tries just to be sure
<davmor2> pitti: try number 3 still no error
<pitti> yay
<davmor2> try number 4 no error
<pitti> davmor2: can you now restart the live session normally, and re-trigger the bug?
<davmor2> let me reboot now and see if I can still trigger it
<davmor2> beat me to it
<pitti> davmor2: another thing came to my mind which I'd like to see
<davmor2> pitti: on reboot I am back to error dialogue
<pitti> ok, good
<davmor2> pitti: whats the other thing you'd like to try?
<pitti> davmor2: I'm still figuring that out; I can do this in my own VM
<davmor2> pitti: righto
<pitti> but that at least means we have *a* way to prevent this
<yofel> Hi, there's another ubiquity patch I would like to get in, as auto-login for kubuntu is broken: https://lists.ubuntu.com/archives/kubuntu-devel/2016-April/010350.html
<yofel> (ubiquity doesn't chroot when editing the config)
<yofel> Until when would I have to find someone (who?) that could help me with applying that? I could at least make a debdiff if that helps
<cyphermox> I can apply the changes if it's fine for the release team to land this
<Odd_Bloke> infinity: Reminder that it takes us about 24 hours to publish cloud images, so we're beginning to push towards infringing on your drinking time tomorrow evening if we don't kick off our respin soonish. ;)
<infinity> Odd_Bloke: So, not something we can solve today, but is there something we can do to make that not a 24h process?
<infinity> Odd_Bloke: (And requiring us to be ready more than a day in advance because you need to be is... Special)
<Odd_Bloke> infinity: Not much; replicating to Azure just takes for-frickin-ever.
<infinity> Odd_Bloke: Is that being done from our DC, or from Azure itself?
<Odd_Bloke> infinity: We publish the image once from our DC, then tell Azure to replicate it internally.
<infinity> Odd_Bloke: (ie: if you pushed RC images to an Azure instance, rsynced Final images over them, and pushed from there...?)
<Odd_Bloke> infinity: ("tell" via API)
<Odd_Bloke> infinity: So the slowness is all on Azure's side.
<infinity> I'm not sure the entire release process should be at Azure's mercy. :P
<infinity> (That's never been true before)
<Odd_Bloke> infinity: IME, in the past we've normally gotten away with using an RC from Tuesday or earlier.
<infinity> Odd_Bloke: Who's "we"?
<Odd_Bloke> infinity: Once the RC is sync'd final release is an easy switch flip.
<Odd_Bloke> But we don't yet have an RC.
<infinity> Odd_Bloke: Do you mean the cloud people just don't bother respinning when the rest of us fix something on Wednesday?
<Odd_Bloke> Sorry, I realise I didn't make that clear.
<Odd_Bloke> infinity: Not if it's in installer or desktop stuff, no. :)
<pitti> davmor2, cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539/comments/27
<ubot5`> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Confirmed]
<pitti> I am now able to reproduce this with some shell code, with a plausible explanation
<pitti> cyphermox: that assumes that partman actually removes and re-adds the partition after swapoff and before mkswap
<Odd_Bloke> (That's what I mean by "getting away with"; changes not being in packages we have on our images :)
<pitti> cyphermox: which sounds plausible and right, just would like to confirm that this is what happens
<cyphermox> pitti: what?
<cyphermox> I suppose, but partman has been doing the same thing for swap in $forever
<pitti> cyphermox: I mean, does ubiquity/partman remove and add the swap partition in between swapoff and mkswap?
<pitti> cyphermox: yes, as I said this is correct behaviour, I'd just like to know if it actually happens that way
<cyphermox> ubiquity just does things via partman
<cyphermox> I suppose it does -- look at partman-basicfilesystems
<cyphermox> just running swapoff; mkswap will do that remove then add
<cyphermox> ie -- you're disabling it, wiping the old one to make a new one
<pitti> cyphermox: no, that doesn't reproduce it, as that leaves the actual /dev/sdaX in place
<cjwatson> Odd_Bloke: We haven't had actual RCs for years, but you could just pick the latest daily.
<pitti> i. e. the partition contents changes, but not the device for the partition itself -- you need to change the partition table for that
<pitti> and the latter is what triggers this bug (which is why I couldn't reproduce it with the commands before)
<cjwatson> Odd_Bloke: (but granted that doesn't help if we actually need to change something)
<cyphermox> pitti: you'd see which partitions change in the confirm dialog in ubiquity
<Odd_Bloke> cjwatson: Yeah, we use dailies for RCs, but infinity earlier said that there were changes coming for a respin so I've disabled our automatic build trigger so that we don't have a build in-progress when we want to kick off another build.
<pitti> cyphermox: right; and I suppose it just writes the new partition table to /dev/sda (trying to find that in the strace, not easy to see but I figure it's there somewhere)
<infinity> Odd_Bloke: The current state of the archive should be safe for you to do cloud builds.
<infinity> Odd_Bloke: Right up until pitti and/or cyphermox change something you use. :P
<pitti> infinity: so I pretty much understand the bug and we have *a* solution
<cyphermox> not planning on changing anything right now
<Odd_Bloke> infinity: OK, build kicked.
<Odd_Bloke> Thanks!
<infinity> pitti: Is the solution in casper/ubiquity?
<infinity> pitti: If so, cloudy people are safe. :P
<pitti> it's not necessarily elegant, but should do (davmor tested it)
<pitti> yes, casper, and cloud is safe
<infinity> Ta.
<infinity> Their modern new world seem to move a lot slower than our old, "obsolete" world. :P
<pitti> there might be a more complicated/elegant one, but at this point in time I'd frankly just go with changing the 13swap hook in casper to just call mkswap instead of adding to the life system's fstab
<pitti> or we leave swap alone entirely
<Odd_Bloke> infinity: Only Azure.  :p
<cyphermox> pitti: you mean swapon, not mkswap?
<pitti> err yes, sorry
<cyphermox> ok :)
<pitti> infinity, cyphermox: http://paste.ubuntu.com/15949514/
<pitti> as I said, not necessarily brilliant or elegant, but I think appropriate at this point
<cyphermox> pitti: let's just make sure that once the system is booted we really do have a swap available then
<pitti> meh, forget that patch
<pitti> no swapon in the initrd
<cyphermox> :(
<cyphermox> call the target's ? ;)
<pitti> heh, I figure we could do that (I'm just testing it in VM)
<cyphermox> it's going to be even uglier.
<pitti> yeah, /root/sbin/swapon does not find libmount.so, and chroot /root swapon doesn't have /dev mounted
<cyphermox> wow
<pitti> I'm beginning to understand why we wrote it to fstab instead of just calling swapon :)
<superm1> make a systemd job in the target to swapon once you pivot roots?
<cyphermox> could we inject a unit to swapon once?
<pitti> normally that job is "fstab" :)
<cyphermox> yeah, but we can't otherwise inhibit's systemd fiddling with partitions
<pitti> but yes, we can inject another unit into /root/run (but that's not mounted yet either)
<superm1> maybe uglier but how about another job after fstab finishes to delete lines from fstab related to swawp?
<pitti> thought about that too, or just disable the .swap unit
<pitti> or copy swapon into the casper initrd
<Laney> add a preset to disable *.swap?
<pitti> well, entirely disabling swap is much easier
<pitti> just remove that 13fstab script
<pitti> (that's what davmor tested)
<pitti> the other is copy_exec /sbin/swapon, and just call it from the life initrd
<pitti> LD_LIBRARY_PATH=/root/lib/x86_64-linux-gnu /root/sbin/swapon works, so it's just the libraries, nothing else
<pitti> or we change partman to disable the swap units which it touches, but that's more intrusive (affects d-i and cloud)
<pitti> well, not cloud
<tjaalton> infinity: I've got a working llvm by dropping all features from skylake that 3.9 thinks belong to server cpu's. but looking at what happened between 3.7..3.8 there's just one feature that got added to skylake ("protection keys"), I'll try dropping just that
<pitti> infinity, cyphermox: V2: http://paste.ubuntu.com/15949860/
<pitti> ^ same diff, in case you want to go with that
<pitti> I tested the copy_exec on a regular desktop install with installing that updated casper, and ensuring that /sbin/swap on was in the initrd (libmount.so already was before, though)
<jderose> infinity: I filed a bug about oem-config-gtk not being installed after an OEM install - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1572615
<ubot5`> Launchpad bug 1572615 in ubiquity (Ubuntu) "xenial 20160419: oem-config-gtk not installed after OEM install" [Undecided,New]
<cyphermox> what?
<seb128> jderose, bug #1572436
<ubot5`> bug 1572436 in Ubuntu CD Images ""Prepare for OEM install" icon and oem-config-prepare missing on desktop" [High,Confirmed] https://launchpad.net/bugs/1572436
<tjaalton> jderose: on that llvmpipe bug you mention that some haswells are affected.. are you sure it's the same bug?
<jderose> seb128: thanks! marked mine as a duplicate
<seb128> jderose, thanks
<cyphermox> infinity: user-setup for yofel's issue ^, that will also need an ubiquity refresh, as usual.
<jderose> tjaalton: not sure about Haswell (I'll check that shortly), but it does seem to effect Haswell-E. so I'm guessing it's only when certain CPU extensions are available that llvm is (seemingly) generating invalid code
<tjaalton> jderose: right, I've looked at llvm today and I can fix skylake, but HSW-E is weird, there should be no difference really
<jderose> tjaalton: you come across any upstream llvm 2.8.x fixes that seem promising?
<tjaalton> nah I'll drop a cpu feature that should be only for server cpu's
<tjaalton> right now I'm testing if it's enough to drop the only one that got added in 3.8
<tjaalton> and leave the others
<jderose> tjaalton: do you happen to have your llvm 2.8 patches with Skylake fixes available in a PPA so I can help test?
<tjaalton> not in a ppa, builds take far too long for that
<tjaalton> I'll put this somewhere once I know more
<jderose> tjaalton: awesome, thank you very much. please let me know anywhere i can help :)
<jderose> tjaalton: as soon as i'm in the office, i'll double check things on Haswell-E... but we were definitely having problems on these systems early last week
<tjaalton> sure, I need to know the cpu model id from /proc/cpuinfo
<jderose> k
<pitti> cyphermox: user-setup needs a corresponding ubiquity and d-i upload, right?
<cyphermox> no just ubiquity
<cyphermox> I don't know if you were going to be doing a respin though, and if it's worth putting in for that respin
<lamont> https://bugs.launchpad.net/ubuntu/+source/python-formencode/+bug/1569035 <-- do y'all care enough about that for us to upload it before release, or shall we just go for the 0-day -updates mentality?
<ubot5`> Launchpad bug 1569035 in python-formencode (Ubuntu) "Packaging error causing installation to /debain/usr/..." [High,Confirmed]
<pitti> cyphermox: I thought we'd respin for the swap issue anywa
<lamont> jamespage: ^^ any strong opinion to throw into the mix?
<cyphermox> ok, will get you a ubiquity update then
<jamespage> lamont, not specifically
<pitti> cyphermox: I let it into -proposed now, for testing etc.; infinity can still decide whether or not to let it in (it'll be blocked)
<pitti> cyphermox: and someone other than me still needs to review casper anyway
<lamont> jamespage: if release team decides they want it today, I'll smack it through (should be trival to fix), otherwise I'm gonna focus on other crits and worry about it post-release
<cyphermox> yep
<jamespage> lamont, fine withme
<jamespage> lamont, I think maas it the primary consumer of this right?
<lamont> possibly the sole consuimer
<pitti> it's seeded on ubuntu-server
<pitti> so in principle we don't already have another reason to respin it so far
<pitti> but if the server team can re-test new images, no objection from me
<jderose> tjaalton: isantop is in the office, is going to get /proc/cpuinfo output from our Haswell-E systems
<tjaalton> jderose: cool, thanks
<pitti> apw: new linux landed, but not http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-raspi2, is that intended?
<apw> pitti, we are about to get new ones ... for raspit
<stokachu> ive got a few last minute updates to my openstack package is it to late to upload?
<stokachu> even if i need to file a bug to have it processed once the release is done
<rbasak> infinity: I think we can remove src:mysql-5.6 now, but please double-check. reverse-depends is probably behind.
<rbasak> (yes, it is)
<coreycb> infinity, can we seed neutron-vpnaas and aodh into main for xenial?  their MIRs were just approved.
<isantop> jderose / tjaalton: Both cpuinfo files are attached to the LP bug https://bugs.launchpad.net/oem-priority/+bug/1564156
<ubot5`> Launchpad bug 1564156 in llvm-toolchain-3.8 (Ubuntu) "xenial: invalid opcode when using llvmpipe" [Undecided,In progress]
<tjaalton> isantop: thanks, nice machines..
<infinity> coreycb: Bugs?
<teward> infinity: have you had a chance to poke the nginx bug for a review for FinalFreeze breaking?
<infinity> teward: Not yet.
<seb128> do we have an edubuntu release (I saw stgraber graber about not being a LTS, but unsure if there is an iso)
<coreycb> infinity, bug 1482765 and bug 1546728.  jamespage said the seeds are ready to go.
<ubot5`> bug 1482765 in neutron-vpnaas (Ubuntu) "[MIR] neutron-vpnaas" [Undecided,Fix committed] https://launchpad.net/bugs/1482765
<ubot5`> bug 1546728 in aodh (Ubuntu) "[MIR] aodh" [High,Fix committed] https://launchpad.net/bugs/1546728
<infinity> lamont: lolz.
<teward> infinity: OK
<seb128> or asked differently, is software-center still on some iso? it losts its translations, I've an update to fix that
<infinity> lamont: Fix it fast, we're respinning "soon".
<seb128> unsure if that would mean respining somewhere though
<jamespage> infinity, coreycb: http://paste.ubuntu.com/15951098/
<jamespage> diff for seed
<lamont> infinity: ack.  is it on the media?
<infinity> lamont: It's on server media, yeah.
<lamont> sigh
<infinity> formencode-i18n (from python-formencode) is seeded in:
<infinity>   ubuntu-server: daily
<infinity> python3-formencode (from python-formencode) is seeded in:
<infinity>   ubuntu-server: daily
 * lamont makes it his top-of-day
<infinity> lamont: Top being RFN.
<infinity> jamespage: Commit the seeds, I'll sort the fallout.
<jamespage> infinity, done
<jamespage> infinity, not on media for reference...
<infinity> jamespage: Ta.
<coreycb> jamespage, infinity: thanks
<infinity> seb128: edubuntu isn't releasing, no.
<jderose> i added a bit about the new privilege separation features in Apt 1.2. those with more knowledge about it, please feel free to fact check me, refine it for accuracy - https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Apt_1.2
<seb128> infinity, k, the bot seems to suggest that the package is on mythbuntu though, but I guess that's getting a respin?
<seb128> infinity, thanks for accepting in any case ;-)
<infinity> teward: nginx FFe looks fine, any chance you planned to upload?
<infinity> seb128: The bot is wrong.
<seb128> I see
<infinity> (due to packagesets being out of sync with reality)
<slangasek> infinity: are you going to apply those packageset changes?
<infinity> slangasek: Yeah, Laney and Colin and I were literally just going to go through the list.
<slangasek> ok
<slangasek> infinity: I'm also posting it to ubuntu-devel
<infinity> After I re-run the update script yet again to reflect up-to-the-minute reality.
<infinity> slangasek: Sure.
<slangasek> ok, I'll wait for that list and then post it to ubuntu-devel :)
<infinity> slangasek: packagesets can be aletered post-release, so it's not world-ending if we get it a bit wrong, but I'd like it mostly right.
<lamont> infinity: verfied that it built the right files and e'rything
<infinity> Once the archive settles from the current crop of uploads, I think the next spin will be "final", barring something truly RC.
<infinity> lamont: Good, good.
<teward> infinity: yeah, i wanted your ACK on it first
<teward> it'll be uploaded in about an hour after lunch
<apw> infinity, the firmware respins ^
<ogra_> yay
<lamont> oops
<ogra_> infinity, note that needs changes in livecd-rootfs once these landed
<lamont> and... uploaded to ubuntu this time. :(
<ogra_> (the firmware bits)
<ogra_> apw, does the raspi one include the wlan firmware for rpi3 too ?
<infinity> ogra_: I know.
<infinity> ogra_: Already staged locally, pending my review of the name changes.
<ogra_> infinity, cool
<apw> ogra_, it includes whatever the old one did
<ogra_> apw, bah, not updated from upstream ?
<infinity> ogra_: We wanted to, but Paolo was unsure about breaking something.
<ogra_> (iirc the rpi firmware got updated on github to include the wlan bits for pi3)
<infinity> ogra_: So, we'll update post-release with proper testing, etc.
<apw> ogra_, no, ppisati said we could not because you would need to fix uboot or something
<ogra_> yeh, fine with me
<infinity> ogra_: This update was just to fix the naming.
<ogra_> cool then
<ogra_> apw, hmm uboot shouldnt care about linux-firmware :) ... but we'll sort it in an sru
<apw> ogra_, somrthing about the dtb moving ..
<ogra_> oh ?
<ogra_> well, i'll talk to him ... but given gadget and kernel snap are being re-worked completely in the next weeks i guess we can solve any blockers here
<infinity> lamont: Was dropping that find | rm intentional?
<flexiondotorg> I can see everyone's busy but if there is a sponsor for this it would be great - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1572120
<ubot5`> Launchpad bug 1572120 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.7 bug fix release [dsc attached]" [Undecided,New]
<flexiondotorg> Adds fixes recently added to Ubuntu. Does NOT have to be in for the upcoming image respin.
<lamont> infinity: hrm
<lamont> infinity: hrm.
<slangasek> infinity: ^^ so I notice we still don't have linux-snapdragon in xenial... do you know if that's supposed to be fixed before tomorrow?
<tjaalton> jderose, isantop: can you try building mesa on the haswell? enable tests by dropping the override in rules. if it's hitting the same bug then llvmpipe tests should fail
<infinity> slangasek: We're on it.
<slangasek> infinity: ok
<lamont> infinity: -0ubuntu5 uploaded, good catch.
<jderose> tjaalton: yup, sure
<pitti> lamont: p-formencode LGTM, accepted; but it'll be blocked by britney, I'll leave the unblock to Adam (if we want it on the final ISO), otherwise it's going to end up as an SRU
<jderose> tjaalton: so just drop the "override_dh_auto_test:" line in debian/rules?
<pitti> lamont: oh, I thought that was part of the fix
<tjaalton> jderose: yep
<jderose> k, on it
<lamont> pitti: it was fatfingers
<lamont> and only checking formencode-i18n :/
<infinity> tjaalton: So, llvm vs mesa.  What's the verdict?  You're pretty much out of time.
<pitti> lamont: ok; still waiting on the LP diff to get generated, then will look at 5
<lamont> ta
<slangasek> jamespage: hi, you've seeded aodh and neutron-vpnaas, I see approved MIRs for these two but the python-gnocchiclient dependency has an incomplete MIR
<tjaalton> infinity: I can drop avx512 and the subvariants(!) from skylake feature set. leaves the haswell-e out in the cold though
<cyphermox> ubiquity:  for user-setup, if you decide to land the fix for yofel's SDDM autologin issue ^
<infinity> tjaalton: Out in the cold in what sense?
<infinity> tjaalton: Degraded performance, or broken?
<tjaalton> infinity: jderoes says it has a similar issue as skylake on that bug
<tjaalton> but hitting this issue needs a gpu that isn't properly supported by oss drivers
<jamespage> slangasek, urgh
<pitti> cyphermox: ack, thanks; I'll review/accept (diff still pending) so that it is sitting in -proposed next to the updated user-setup; we either land both or none
<tjaalton> infinity: I'd say it's still something
<flexiondotorg> tjaalton, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1522922/comments/107
<ubot5`> Launchpad bug 1522922 in xserver-xorg-video-intel (Ubuntu) "Screen flickering in Intel i915 driver" [High,Triaged]
<tjaalton> flexiondotorg: they'll deal wit hit
<flexiondotorg> tjaalton, Out of interest, who is they?
<tjaalton> intel
<slangasek> jamespage: neutron-vpnaas is clean, I've promoted it now.  aodh will need something done with LP: #1536887
<ubot5`> Launchpad bug 1536887 in python-gnocchiclient (Ubuntu) "[MIR] python-gnocchiclient, python-gnocchi, python-pandas" [Undecided,Incomplete] https://launchpad.net/bugs/1536887
<infinity> tjaalton: No way to fix it for haswell-e as well?
<infinity> (And how common is haswell-e?)
<cyphermox> pitti: indeed
<jamespage> slangasek, I think thats a not this release then
<jamespage> slangasek, I'll unssed aodh
<tjaalton> infinity: I don't know what's causing it. HSW-E is the $400-600 six-core cpu
<slangasek> infinity, tjaalton: indeed, I would expect dropping that insn to just result in performance degradation, so that it "only" works as well as it does on other chips already
<slangasek> jamespage: cheers
<jamespage> slangasek, done
<infinity> tjaalton: Well, some fix is better than none.  If we could do the same fix for haswell-e, that would be nice.
<infinity> tjaalton: But we've run out of time, so if we're fixing anything, it needs to be NOW.
<pitti> lower performance for final and SRUing a better fix later on seems ok
<tjaalton> slangasek: yeah, and the real WTF moment hit me when the cpu model id on my low-power SKL-Y laptop is the same llvm checks for server features..
<tjaalton> infinity: I'll push it
<tjaalton> actually
<tjaalton> jderose: please test installing libllvm3.8 from http://koti.kapsi.fi/~tjaalton/skl/build2/
<slangasek> Even the lower performance fix is quite late in the game.  I think it would be saner to release note this and fix it for .1
<jderose> tjaalton: k, will do
<tjaalton> mesa might get a workaround by then
<tjaalton> or llvm fixed, but yes
<slangasek> infinity: ^^ my $.02
<tjaalton> your call
<infinity> slangasek: It would perhaps be, but I'm also not keen on screwing the OEM that works most closely with us to ship our releases on release day. :P
<tjaalton> also
<infinity> tjaalton: Does mesa need (re)building to fix this, or just llvm?
<tjaalton> turns out kabylake, which is has crippled kernel support on purpose (needs i915_bpo.preliminary_hw_support=1), is also seeing this bug
<tjaalton> infinity: just llvm
<jderose> slangasek: when do you expect .1 to come out? in the mean time, System76 will probably need to spin an updated ISO so our Nvidia using customers have a viable restore procedure, but that's fine
<slangasek> jderose: .1 is due in June
<pitti> cyphermox: got bored and generated the diff locally; accepted
<infinity> slangasek: Late july...
<infinity> (3mo after release, ish)
<slangasek> jderose: .1 is due in late July
<jderose> slangasek: gotcha, thanks. that's not too far away anyway
<tjaalton> workaround for KBL is to use that option post-install, the kernel module "protection" will get dropped for .1
<slangasek> ;)
<tjaalton> june!?
<infinity> The other Ju.
<tjaalton> ahh
<slangasek> infinity: sorry, don't know why I got that wrong, maybe we did 14.04.1 in june?
<tjaalton> phew
<slangasek> anyway
<pitti> 6.06 :)
<jderose> pitti: haha :P
<tjaalton> yeah 14.04.1 was in august
<tjaalton> iirc
<slangasek> ok maybe wishful thinking on my part ;)
<slangasek> anyway
<pitti> did anyone call dibs on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ? if not, I'll do the binary bits, they look reasonable
<slangasek> this is in a sense a hardware enablement bug
<slangasek> that comes too late for the normal process
<slangasek> and I don't think it should be a fire drill to get it in for .0 when .1 is around the corner
<slangasek> pitti: libgrilo-0.2-1-dbg can be ignored, it was NBS and I removed it.  The other binary changes look sane to me, go for it
<teward> infinity: just uploaded now :)
<slangasek> also, somebody promoted liblouisutdml and didn't close the MIR bug
<slangasek> pitti: ah the pymongo changes will be unnecessary because jamespage is unseeding aodh again per above discussion
<davmor2> pitti, cyphermox: I assume I can drop this ssh port now right?
<davmor2> and is the new iso going to be spun up soon?
<jderose> tjaalton: mesa builds fine with tests enabled on haswell
<tjaalton> jderose: not the same thing then I guess
<jderose> seems not
<infinity> slangasek: Hadn't closed it yet.  Multitasking something fierce here.
<slangasek> infinity: ok :)
<tjaalton> infinity, slangasek: uploaded it anyway, drop it if needed
<infinity> tjaalton: Ta.
<slangasek> tjaalton: s/drop/divert to -updates/ :)
<tjaalton> or that :)
<tjaalton> from the debdiff ^ CDI, DQI et al are subvariants of AVX512, confusing..
<cyphermox> davmor2: I think so (closing ssh)
<davmor2> cyphermox: thanks
<cyphermox> infinity: anything you can/want to delegate?
<infinity> arges: If you're the one doing kernel SRUs right now, could you hold off if you still have more?
<infinity> arges: It kinda cripples the publisher at a rather sensitive time...
<infinity> slangasek, tjaalton, jderose: So, I really wanted to get this llvm fix in for the release, but given the 8hr build time for llvm, I don't think it's realistic.
 * slangasek nods
<infinity> slangasek, tjaalton, jderose: Lining it up for a (near-)0-day SRU seems fine, though it certainly sucks that installs on skylake might be wonky.
<jderose> infinity: that's fine with me. as long as the fix is coming as an SRU soon, we can spin and updated ISO in the meantime, then point people to 16.04.1 once its out
<infinity> jderose: Yeah, I know you'll be alright, you know what you're doing. :)
<jderose> infinity: s/wonky/almost-totally-broken/ :P
<infinity> Less pleasant for random users, but random people buying new hardware tend to understand that Linux isn't always perfect on 2 month old configs.
<infinity> I wish we'd addressed this a couple of days ago. :/
<jderose> infinity: sometimes i know what i'm doing :P but it doesn't effect us for shipments as we pre-install the proprietary nvidia driver
 * ogra_ blames the manufaturers
<ogra_> +c
<jderose> infinity: yeah, sorry about that... i was out of town at a trade show. bad timing
<infinity> jderose: Ahh, so I can blame you? :)
<infinity> jderose: (Not like you're the only person in the world who could have seen this...)
<jderose> infinity: sure, if that makes you feel better, i'm fine with that :D
<infinity> But life's like that, I guess.
<infinity> jderose, tjaalton: Can I get one of you to write a release note entry describing the problem and what (if any) workaround there is to install on an affected machine?
<infinity> Please tell me there's a workaround..
<teward> rbasak: obvious ping, do you have something to add on the release notes for HTTP/2?  We're coming down to the time where that should get put into the notes, no?
<jderose> infinity: assuming tjaalton has the llvm 3.8 SRU available, you can work around it by installing using the "Install Ubuntu" option in the pre-boot menu, which in my experience you might need to try a few time for success. then once you get to your broken unit session, switch to a VT, login, and apt-get update && apt-get dist-upgrade
<jderose> s/broken unit/broken unity/
<jderose> infinity: but yeah, i'd be happy to add it to the release notes once i double check that my instructions are correct
<Kamilion> and I'm assuming running the alternate installer and letting it upgrade-during-install will also net you an operable system come next week.
<infinity> jderose: Oh, I suppose this doesn't affect ubiquity-dm, since it's not composited?
 * infinity hopes.
<infinity> jderose: If so, the workaround would just be to tick the "download updates while installing" box or whatever it is, and never try the live session.
<jderose> infinity: well, that was my feeling at first... but sometimes it still does seem to fail, and if i switch to a VT, i see the same thing in dmesg about invalid opcodes being trapped
<infinity> Oh, lovely.
<infinity> Okay, bigger hammer, then.
<jderose> infinity: yeah, "download updates while installing" is another option... a better one in fact. will just have to double check that it works as expected
<infinity> Kamilion: Yeah, using d-i would be fine, but given we only provide that as netboot, it's a steep learning curve for people who were expecting to click 4 boxes in ubiquity and go grab a coffee.
<Kamilion> as long as upgrading from 14.04 or 15.10 works, that's what I figure a lot of folks will experience in real world usage
<Kamilion> *I* intend to clean reinstall most of my systems this cycle, but I can wait till .1
<infinity> Upgrading will work once the SRU is in place, yeah.
<infinity> That said, people upgrading aren't likely to be affected by this bug in the first place, since they're not likely to have new enough hardware to be broken by it.
<Kamilion> bring half up through upgrades, and roll my own ISOs post-sru.
<Kamilion> yep.
<jderose> infinity: true, upgrades should be fine. it's only an issue for fresh installs
<Kamilion> and I'll roll my xen ISOs after I hear the SRUs are tested green
<Kamilion> since I expect to be running on primarily newish server hardware
<Kamilion> I also roll more often due to frequent security updates in the virtualization stack this last year.
<infinity> tjaalton: llvm accepted, so we can 0-day it once it's gotten testing.
<infinity> tjaalton: But it won't make images unless we have a *critical* respin (which we'd better not)
<pitti> infinity: your livecd-rootfs change still looks premature? linux-firmware-raspi2 doesn't exist in the archive yet, but raspberrypi2-firmware still does
<pitti> (i. e. known?)
<infinity> pitti: It's accepted.
<infinity> pitti: I'm smart enough not to respin until it's all in place. :P
<ogra_> did you fix the hack for the dragonboard in live-build/auto/build too ?
<pitti> I believe in slangasek's theory of publisher slowdown in release weeks :)
<tjaalton> infinity: ok, cool. skylakes using i915 graphics won't hit this issue, so it's limited to workstations that have new dGPU's
<tjaalton> and i can write a relnotes entry
<infinity> pitti: This was because arges pushed a bunch of kernel SRUs.
<infinity> ogra_: Quel hack?  I've not built offician dragonboard images yet.
<infinity> ogra_: So, no, didn't know there was one.
 * infinity looks.
<ianorlin> or just install with skylake and then update and then put in dGPU
<pitti> I'm off for a few hours for basketball, will check back in around 20:30 UTC
<ogra_> infinity, has a comment ... look for "metapackage"
<pitti> infinity: anything you particularly want me to look into tonight? (just in case you are at beer then, which I hope)
<infinity> ogra_: Oh.  That whole bit is wrong.  Awesome.
<pitti> otherwise, it'd be iso testing
<ogra_> infinity, nah, works fine with the PPA packages :)
<tjaalton> ianorlin: not if the cpu doesn't have gfx support
<stokachu> i see openstack 1.0.6 approved here but rmadison isn't showing it in proposed
<stokachu> did it hangup somewhere?
<ianorlin> which even most skylake E3 xeons have
<tjaalton> ok
<infinity> stokachu: It's not instant.
<Kamilion> like the E3-1220 v what?
 * Kamilion has some V2s and V3s around and knows V5 was released
 * cyphermox -> lunch
<stokachu> infinity: ok
<Kamilion> is it only the greenlow v5s?
<ianorlin> like there are quite a few with integrated
<pitti> infinity: FTR, casper is ready to promote, but blocked
<infinity> ogra_: Well, I'll let you deal with your ugly hacks.  None of that is sane for the archive.
<infinity> pitti: Yeahp, I'm unblocking en masse when I'm happy with the state of things and prepping for the Final Spin(tm).
<ogra_> it will just have to be switched to the meta
<infinity> ogra_: The meta doesn't depend on the firmware (it can't).
<infinity> ogra_: So, it'd be the meta and the renamed firmware.
<infinity> But sure, I can make those changes.
<ogra_> nah, i'm fine doing them ...
<ogra_> the only really ugly one is the dragonboard since we had no meta at all
<infinity> ogra_: Why on earth are you installing "linux-flavour" instead of "linux-image-flavour" for snappy builds?
<infinity> ogra_: Total waste of time and space to install the headers.
<ogra_> on x86 systems that pulls firmware in
<infinity> ogra_: No, it comes from linux-image-generic, not linux-generic
<ogra_> the firmware dep ?
<ogra_> oh
<infinity> ogra_: Yeah, linux-foo is linux-image-foo + headers.
<ogra_> well, then i'll use image :)
<ogra_> doesnt really matter for the resulting snap since the dirs are pre-defined
<slangasek> why does p-m think libsemanage is 0 days old?
<infinity> ogra_: Matters for build time, then.
<ogra_> yeah
<infinity> slangasek: Because it got deleted and copied back in because magic.
<infinity> slangasek: I could reset it in the state files, but meh.
<slangasek> infinity: ah.  why was it deleted?
<infinity> slangasek: To make room for the one I built in a PPA and slipped under the radar.
<slangasek> infinity: heh
<infinity> ogra_: Anyhow, if you're happy fixing this all, go for it.  It's not actually *on* images, so I don't care if livecd-rootfs changes as long as the code you fix is obviously contained to snaptastic things.
<ogra_> yeah ...
<slangasek> RAOF: your changelog entry for dovecot is incorrect; dovecot-core ends up with a dep on libstemmer0d
<slangasek> RAOF: see also http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dovecot
<jderose> infinity: roughly when are you expecting to fire off the next ISO builds?
<infinity> jderose: When the current lot of crap all migrates.  I'm done accepting new things.
<jderose> infinity: okay, thanks. just trying to best time when i drive to the office so i have access to all our hardware for testing
<ogra_> infinity, http://paste.ubuntu.com/15954073/ looks ok ?
<ogra_> (or do we have a dep for the raspi2 and snapdragon FW packages ?)
<infinity> ogra_: That looks correct.
<ogra_> ok
<infinity> ogra_: The raspi/snapdragon metas can't depend on the firmware because it's non-free.
<infinity> (multiveeeeeeerse)
<ogra_> ooooh indeeed
<ogra_> :)
<ogra_> uuuh
<ogra_> why does "dpkg-buildpackage -rfakeroot -S" get me a gui popup for the gpg passphrase
<ogra_> how irritating
<infinity> Because that's how gpg agents work.
<ogra_> not til i upgraded to xenial :)
<infinity> You can switch to the text pinentry method.  Somehow.
<infinity> I've not bothered to fill in that blank yet.
<ogra_> it breaks my workflow ... i'm used to type my passphrase twice !!
 * ogra_ has a spare passphrase in his brain now 
<Odd_Bloke> Type it here:
<infinity> If you're capable of typing your passphrase correctly twice in a row, it's too short/simple.
<ogra_> hunter2
<Odd_Bloke> ogra_: I HAVE YOU NOW
<Laney> <ogra_> *******
<ogra_> :D
<balloons> ogra_, don't lie.. it's snappysolveseverything
<balloons> :-)
<ogra_> lol
<Odd_Bloke> theresanassertionforthat
<balloons> So I'm the stereotypical, before release day bloke, looking for a friend who might be able to upload a new juju2 package for me. Any takers?
<balloons> Not everyone all at once now, I know this is the chance of a lifetime
<infinity> balloons: You've missed your chance.
<infinity> Oh.  juju's not on any images?  Really?
<infinity> I guess you haven't missed your chance.
<balloons> infinity, :-) I'm certainly not going to be 'that guy' pushing you to respin
<willcooke> tjaalton, hey did this get out of NEW yet?  https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1571677
<ubot5`> Launchpad bug 1571677 in xorg-lts-transitional (Ubuntu) "upgrading caused a broken apt cache due to *-lts-vivid packages conflicting with current X packages" [Critical,Fix released]
<willcooke> how can I find out?
<willcooke> tjaalton, ignore
<infinity> Heh.
<rbasak> teward: thanks for the reminder.
<teward> rbasak: you're welcome, sorry to poke :)
<superm1> infinity: just wanted to poke and remind on the grub in boot seed thing in case it fell off your radar
<infinity> superm1: Oh, balls.  Thanks.
<infinity> superm1: To be clear, that only negatively affected myth, right?  So, I can respin world minus myth, sort yours, and do you?
<infinity> I could have phrased that better.
<superm1> infinity: we're the only ones that install nvidia driver during install IIRC
<superm1> but yes i think i think youcould respind the world without us and then drop from teh seed, spin us and magic everything works
 * jderose drives into the office, be back soon... good luck ya'll, thanks for all the hard work!
<tjaalton> willcooke: sure did :)
<rbasak> infinity: I'm getting a bunch of postinst failure apport-filed bugs for mysql-5.7. This isn't really a regression from 5.6 but has always been a problem. Users customise their configs and then mysqld fails to start after upgrade. For 5.7 some customisations use directives that no longer work, too, including a conffile default in 5.6 packaging. What do you think about adding a fail-to-start-service
<rbasak> hook that just prints a warning instead, so dist-upgrades won't explode?
<rbasak> (this would be for upgrades only so won't need a respin)
<slangasek> rbasak: how about fixing up the config file on upgrade instead?
<rbasak> slangasek: we could do that for a couple of cases, but I hate to sed custom conffiles anyway - always feels risky to me.
<rbasak> And it wouldn't cover all cases.
<slangasek> rbasak: I am personally lukewarm about letting a package install succeed yet leave the service failed.  I know it doesn't do great things to an upgrade, but I personally feel it's more truthful to treat that as an upgrade failure
<slangasek> (and in a perfect world, fix that upgrade failure)
<slangasek> I also get squeamish about per-package deviations from the standard behavior of expecting services to start successfully on install/upgrade
<rbasak> I think this is a fundamental issue with server services. On desktop the expectation is that package that provide daemons just work out of the box. On server the intention usually is that the user customises after the install, often in a way that packaging can't really fathom. And then that changes with a new version.
<rbasak> (a new upstream version)
<rbasak> Packaging fixing it up is then hit and miss. And then release upgrades break.
<rbasak> This system is broken.
<rbasak> I also get the impression that production server users will either be able to fix it up later, or redeploy without doing a release upgrade. Having the release upgrade break is worse. I think the majority of mysql bugs reported in this fashion is from desktop users experimenting with server stuff, not production server users.
<rbasak> For that class of users, I think mysqld not starting is preferable to a release upgrade exploding.
<infinity> rbasak: How would it "not require a respin"?  (unless it's a 0-day SRU)
<rbasak> I'd also prefer not to receive a gazillion apport bugs from users who have broken mysql configs because they messed with them.
<rbasak> infinity: I mean a 0-day SRU would be fine.
<slangasek> rbasak: and again, I think that warrants a deep policy discussion, not a one-off package deviation the day before release
<Skuggen> We might be able to handle the simplest cases, but I don't think it's possible to fix all such issues automatically
<infinity> rbasak: We can discuss it when I'm not flat out trying to release, then, but I tend to agree with Steve, any attempt we can make to migrate, we should.  We can't catch every case, but those really should be failures.
<rbasak> slangasek: I'm not confident hacking up a sed a day before release. Too many untested/unknown edge cases IMHO.
<slangasek> rbasak: I'm happy to review seddery
<slangasek> infinity: you probably missed my question last night about removing all the precise/daily* directories under www/full
<infinity> slangasek: Go for it.
<infinity> slangasek: And yes, I missed everything overnight because that server that had an IRC client uptime of over four years died overnight.
<rbasak> Skuggen: would you like to attempt some seddery?
<Odd_Bloke> slangasek: Could you ACK the gce-utils upload in to partner/xenial-proposed, please?
<slangasek> Odd_Bloke: let's see!
<Skuggen> rbasak: Yeah, I can see if I can get something simple going. There are a couple of known options that could simply be renamed, but for others I guess we'd probably just have to comment them out?
<slangasek> Odd_Bloke: acked
<Skuggen> (And give some sort of noticeable warning that we've done it)
<slangasek> noticeable warnings optional
<Odd_Bloke> slangasek: I knew you could do it.  I always believed.
<Skuggen> slangasek: Yeah, during a full dist upgrade it would be pretty hard to make it noticeable :)
<slangasek> Skuggen: well, there's a mechanism for it, which is to pop a debconf error. But please don't ;)
<Skuggen> Maybe just add a note together with the commented-out option
<rbasak> Skuggen: maybe start with the two options present in the previous default conffile that got renamed?
<rbasak> Skuggen: and look for those only in that conffile?
<rbasak> Otherwise we'll get into questions about what files to scan, etc.
<rbasak> And yeah, definitely add a commented note in the file explaining that packaging did it.
<Skuggen> rbasak: Yeah. At most I think we could scan through /etc/mysql
<Skuggen> But we can detect this sort of issue by running mysqld --verbose --help in postinst
<slangasek> infinity: ignore me pushing changes to the ubuntu-cdimage branch and deploying them
<slangasek> xnox: why do we have 'Ubuntu Core s390x' as a local delta to etc/qa-products on nusakan?
<infinity> slangasek: WCPGW?
<slangasek> infinity: nothing, that's why you should ignore it ;)
<rbasak> Skuggen: scanning /etc/mysql is dangerous because of hitting MariaDB config, etc. But let's take this to #debian-mysql and come back here when we have a patch.
<infinity> slangasek: That's me.  I didn't commit it because I was mid-merge on the cyphermox branch.
<infinity> slangasek: I can commit my nusakan changes now.
<slangasek> infinity: k
<slangasek> infinity: why do we have Ubuntu Core s390x at all? that's not on the list of target deliverables
<infinity> slangasek: Because we have it for all arches, and it's the simplest/best livecd-rootfs/lp-buildd+livefs testcase.
<infinity> slangasek: They don't need to ever be aware of or care about it if they don't want, it takes me seconds to validate and release, so meh.
<slangasek> infinity: ok
<infinity> slangasek: I made a bit of a mess of committing that all, but it's there now. :P
<apw> tjaalton, llvm i386 seems to have exploded ...
<infinity> slangasek: Have you demoted pymongo binaries yet?  I don't want to stomp on you and hit the double-override bug.
<slangasek> infinity: you have the lock
<slangasek> infinity: (I hadn't seen they got promoted and haven't demoted)
<Odd_Bloke> Is there a reason that packages built for partner-proposed 35 minutes would still be "Pending publication"?  Am I just being impatient?
<infinity> Odd_Bloke: BTW, we did bump one package that affects cloud (tzdata), but I'm not super fussed if you don't respin for it, especially given that the license is public domain.
<slangasek> Odd_Bloke: yeah it takes a while.  I suspect that publication has gotten slower over the past week or two but don't know why
<Odd_Bloke> infinity: Cool, I think we'll skip the respin. :)
<Odd_Bloke> slangasek: It's finally arrived there, but several minutes after Launchpad stopped warning me that some files hadn't been published.
<slangasek> Odd_Bloke: yes, launchpad doesn't see all the way to the edge, its idea of published is different from yours
<jderose> tjaalton: hmm, looks like the i386 build of llvm-toolchain-3.8 failed - https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8-2ubuntu2/+build/9602931
<Odd_Bloke> slangasek: OK, I'll file that info away for the future. :)
<rcj> Odd_Bloke, Having just read the tzdata diff I can tell you that time travel is impossible.  We can hardly keep track of time when it is moving linearly.
<Odd_Bloke> slangasek: I've validated that gce-utils change; could you migrate it to release, please? :)
<slangasek> Odd_Bloke: done
<Odd_Bloke> slangasek: Thanks!
<slangasek> infinity: http://lucifer.0c3.net/~adconrad/packageset-changes-new.txt hasn't been refreshed; is the new one still coming?
<infinity> ###### FINAL RESPIN OF ALL FLAVOURS IN PROGRESS; PLEASE TEST ASAP ######
<davmor2> \o/
<infinity> slangasek: Oh.  I can finish re-rerunning it tonight.  Colin, Laney and I went through it all and it looked alright, though.  And, in Laney's words "I used to commit changes that large without review all the time, so meh."
<slangasek> infinity: well, I think this is a special case because of the main changes and we should give teams an opportunity to "rescue" some of these
<infinity> slangasek: So, the plan was just to commit tonight/tomorrow and call it good, rather than inviting people to bikeshed about it.  If people lose upload rights to something they really like, they can poke the DMB to fix it.
<ogra_> infinity, can you trigger snappy too, so I can see if anything fails after the change
<infinity> slangasek: But if you want it out for review, go to town.  Like I said before, packageset changes are per-series, not per-pocket, so we can (and do) mangle them post-release.
<slangasek> infinity: "go to town"?
<infinity> ogra_: You can.
<slangasek> you said you were going to generate an updated list, which I don't know how to do
<infinity> slangasek: As in, go for it.  Be my guess.  Bring it.  Etc.
<infinity> slangasek: Right, I'll provide the updated list when I get hotelward.
<slangasek> ok
 * infinity refreshes his local mirror from the office first, so he can skip that step on the hotel network. :P
<flocculant> :)
<infinity> Oh, ffs.
<infinity> ogra_: You broke my world respin (and two of us missed it in review).
<infinity> Fixing.
<davmor2> infinity: this isn't an iso blocker but can it be added to the release notes please as it is important https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1561647
<ubot5`> Launchpad bug 1561647 in software-properties (Ubuntu) "No mokutil prompt triggered when installing from additional drivers" [Undecided,New]
<davmor2> willcooke: ^
<cyphermox> ah, jes
<infinity> davmor2: Document away.
 * cyphermox goes to fiddle the software-properties UI to make this work
<davmor2> infinity: if this is the final spin why is there an unapproved livecd-rootfs above?
<infinity> 14:13 < infinity> Oh, ffs.
<infinity> 14:14 < infinity> ogra_: You broke my world respin (and two of us missed it in review).
<infinity> 14:14 < infinity> Fixing.
<infinity> davmor2: ^
<infinity> Going to head back to the hotel and re-trigger from there. :/
 * davmor2 shakes his fist and ogra_ and blames him for everything, include war and world hunger ;)
<slangasek> heh, what difference do those two little characters make
<cjwatson> srsly
<Odd_Bloke> Would have been fine in Python.
 * cjwatson commits a basic automatic syntax check of at least those files to bzr
<Odd_Bloke> Oh, right, infinity isn't here to troll about Python. ;.;
 * pitti waves, quoi de neuf ?
<ogra_> oh man
 * davmor2 hugs ogra_ :) hey dude :)
<ogra_> heh, thanks
 * ogra_ hugs davmor2 too
<pitti> ogra_: hey bearded man!
<ogra_> lol
 * pitti hugs ogra_ as well -- feels like release week!
<ogra_> YAY !
<pitti> a dozen people do hacks they aren't proud of, and at the end we get something that works, much to everybody's surprise :)
<ogra_> only for non snappy though ... in the snappy world the hard work only starts now
<infinity> Hard work's still in progress for the rest too. :P
<davmor2> ogra_: PFFFF Don't even get me started ;)
<ogra_> yeah, but you only need to approve these gazzillions of SRUs the snappy people push to the archive
 * ogra_ really wishes we had used the phone model for snappy and just used an overlay archive ... 
<jderose> infinity: slangasek: confirmed that tjaalton's test build libllvm3.8_3.8-2ubuntu1.1_amd64.deb fixes the issue on the first laptop i tested... now onto testing other hardware
<ogra_> "rolling release via SRUs" doesnt really leave me confident
<jderose> ogra_: the wave is always rolling, you just need to ride it carefully :P
<davmor2> ogra_: but surely they'll be no need to update things in main as long as snapd can install ubuntu-core and the apps that's it right it all upgrade automagically right :D
<slangasek> jderose: huzzah
<ogra_> davmor2, yeah, because snappy images arent using anything but snapd at all :)
<davmor2> ogra_: there you go then easy :P
<infinity> jderose: Now if only it worked on i386. :P
<davmor2> jderose: this is ogra_ he knows no fear he rides on the back of  laser toting shark across the rolling wave
<ogra_> Oh my
<phillw> infinity: are the lubuntu alternate images to also be respun. They landed before you mentioned a further issue?
<slangasek> phillw: lubuntu because they are alternate are unaffected
<flocculant> phillw: I saw that - I'd have to assume that anything that's live is going to be subject to the global respin
<flocculant> I'd certainly plan that way if I was Lubuntu and not Xubuntu
<phillw> slangasek: so we have an RC for alternate now?
<slangasek> phillw: should be, yes
<phillw> great, thanks.. just lets us concentrate resources on those while we await desktop to land :)
<flocculant> phillw: sorry - got confused there with you having that alternate
<tjaalton> apw, jderose, infinity: oh well, so it's expected that all tests pass on i386, others can screw it. so need to disable avx512 tests at least
<tjaalton> just need to figure out how..
<davmor2> infinity: any eta on the new, new isos?
<slangasek> davmor2: they're at least an hour out and probably more like 2; I don't know what Adam's transit time is back to the hotel, but the fixed livecd-rootfs isn't yet in xenial
<davmor2> slangasek: and with that I give up staying up to test oem install like I wanted and go to bed, night all
<slangasek> davmor2: wise choice. g'night!
<infinity> davmor2: The new livecd-rootfs is publishing, so I'll retry in ~30m.
<jderose> cyphermox: so it seems the grub-install is failing with nvme drives... ubiquity tries to install grub to /dev/nvme instead of, for example, /dev/nvme0n1
<jderose> found this on BIOS systems thus far, will test UEFI shortly (although these are BIOS systems that can boot from an nvme drive)
<superm1> jderose: why would you install in legacy mode on new systems?
<slangasek> pitti: I see sysvinit Breaks: systemd (<< 228-5ubuntu3), but that doesn't enforce systemd 228-5ubuntu3 being configured before sysvinit, which means the conffile may already be migrated away before systemd postinst runs... I think the right way to do this is with initscripts Pre-Depends: systemd, and for initscripts' preinst script to handle any conffile cleaning so that users are spared
<slangasek> conffile prompts on upgrade
<slangasek> pitti: (not for release of course, but I think this is advisable for SRU)
<jderose> superm1: well, because it used to work :P
<infinity> slangasek: Taking a lock on c-m.
<slangasek> infinity: copy
<jderose> cyphermox: actually, installing to a nvme drive in UEFI mode is fine... only BIOS mode is the problem. likely an issue with grub-pc i'm guessing
<slangasek> jderose: well, under UEFI grub always "installs" to the ESP and calls efibootmgr, so completely different code path vs. BIOS, yes
<slangasek> who's sitting on the s390x button?
<cjwatson> the mass retry you mean?
<cjwatson> that was Adam
<slangasek> cjwatson: yeah :)
<cjwatson> it'll finish in time, it's only a few hundred builds
<cjwatson> and s390x eats builds for breakfast
<infinity> Om nom.
<slangasek> yes, and probably half the build failure mails are to me ;P
<infinity> Lucky you!
<pitti> slangasek: ah, good point; this needs to be tested thoroughly, pre-depends have some habit of causing trouble;
<infinity> ##### FINAL MASS REBUILD IN PROGRESS FOR REALZ THIS TIME #####
<pitti> infinity: \o/
<cjwatson> slangasek: you have procmail, what are you complaining about
<pitti> slangasek: filed bug 1572752 about that
<ubot5`> bug 1572752 in systemd (Ubuntu Xenial) "improve UTC setting migration on upgrades" [Undecided,New] https://launchpad.net/bugs/1572752
 * pitti moves to sysvinit, but whatever
<teward> infinity: UNLEASH THE FLOOD OF EVILS!
<teward> s/EVILS/ERRORS/
<teward> (just kidding!)
<infinity> teward: It can't go worse than the last rebuild attempt...
<cyphermox> jderose: ok, but installing grub on a drive is installing grub on a drive, the target device isn't different if it's nvme or not
<teward> infinity: i... am glad I was busy building a deconstructed computer?  :p
<ogra_> infinity, but it was fast at least
<cyphermox> anyway, will fix now that dinner is out of the way
<pitti> ok, this mass rebuild is a bit too late for me to wait for, I'll get onto testing tmw morning then; good night!
<Kamilion> cyphermox: tell that to platform SD controllers *grumble*
<tsimonq2> infinity: awesome :)
<cyphermox> Kamilion: well, there was a need to do some extra handling for NVMe in grub-installer, but what I'm saying is that I don't recall how BIOS or UEFI would make a difference in this particular case
<Kamilion> I was grumbling because a lot of "platform SD controllers" are not bootable at all
<cyphermox> see, that I would expect a bit more from BIOS.
<Kamilion> vs your average SD-to-USB chip
<cyphermox> I don't have NVMe here to test though, and I suppose I should fix that
<infinity> And mysql-5.6 removed at the zero hour.
<flexiondotorg> jderose, I confirm "ubiquity tries to install grub to /dev/nvme instead of, for example, /dev/nvme0n1"
<flexiondotorg> On a BIOS system.
<jderose> flexiondotorg: thanks for confirming :)
<jderose> flexiondotorg: happen to know whether this was a problem with 14.04.4 and/or 15.10? i haven't tested those yet, but will try to shortly
<flexiondotorg> jderose, 15.10 also affected. Haven't tested 14.04.
<cyphermox> jderose: flexiondotorg: would either of you mind trying to re-do an install but adding -x to /usr/share/grub-installer/grub-installer
<cyphermox> (before ubiquity reaches that point of course)
<cyphermox> I fixed NVMe in some cases already, so something simple must be missing
<flexiondotorg> cyphermox, Not before release :-(
<flexiondotorg> Wil;l be using the nvme computer for VM< testing.
<cyphermox> or maybe there's enough info already in the installer logs, is there a bug open for this yet?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505
<ubot5`> Launchpad bug 1507505 in grub-installer (Ubuntu) "Unable to install GRUB in /dev/nvme" [Undecided,Confirmed]
<flexiondotorg> cyphermox, ^^^
<cyphermox> yippe...
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1561572
<ubot5`> Launchpad bug 1561572 in grub2 (Ubuntu) "Grub fails to install bootloader on NVMe drives" [Undecided,New]
<flexiondotorg> cyphermox, I've marked the second as a dupe of the first.
<cyphermox> thanks
<slangasek> cjwatson: procmail doesn't tell me who clicked the build button, so I don't have a way to filter build failures I care about from those I don't :)
<infinity> slangasek: I believe the response is "aww, schnookums".
<infinity> (Though I've long thought that repeated nags on retries are spam to the uploader)
<infinity> Not sure how trivial it wouldn't be to refcount and only spam on the first try.
<slangasek> infinity: hey, my pain is your pain; you don't want me complaining about pointless retries of failed builds, keep them out of my inbox ;-)
<infinity> ;)
<infinity> It's a harder bug to fix than one would think, which is why I've never done so.
<slangasek> yeah
<infinity> (it's fundamentally counter to how LP does retries, which is to wipe the record and reset to fresh)
<flocculant> infinity and -release team (wonderful that you are ofc) - have to crash now, when do you think respin will be ?
<flocculant> can I assume when I surface it'll have happened?
<slangasek> flocculant: as the bot says, builds are happening currently
<flocculant> I did send a pre-pre-respin warning out
<flocculant> slangasek: ok thanks - I'll assume that all went on then
<flocculant> have to go and do real job first thing
<flocculant> slangasek infinity - and when do - release hope to have ticks from the rest of us? UTC ish
<flocculant> given we do stuff in real life ;)
<slangasek> flocculant: release is expected to go out during business hours in London tomorrow; I don't know if infinity has a more specific target than that
<RAOF> Laney, slangasek: Urgh, sorry. I read the output of sbuild and missed that where I should have been grepping the output of dpkg --info. :(
<slangasek> RAOF: alrighty, fixed package accepted; I don't expect we'll let this into release though :)  It can go to y-proposed->y
<RAOF> That bug is annoying, and I hit it again recently, and thought âoh, yeah! We've made that change that main can build-depend on universe as long as runtime dependencies only apply to universe packagesâ.
<RAOF> I guess I'll have to try and fix it more invasively at some point :(
<RAOF> slangasek: Obviously there's no point in letting it into release; the delta against xenial is 2 changelog entries :)
<slangasek> yup!
<flocculant> slangasek: cool - not too worried, might have to smoketest a few, just wanted to ensure it wasn't going to be some crazy UK is wake now release is all :)
<flocculant> thanks
<flocculant> and we want to get some fixed thunar tests in too
<slangasek> Laney: what generate-freeze-block command did you run that generated the freeze hint?  ubuntu-server seems to not be frozen, and various things that aren't in any task are frozen
<infinity> slangasek: Not sure what his command was, but it's conceivable he missed server. :/
<slangasek> Laney: n/m, reverse-engineered :)
<infinity> slangasek: Going to add a dovecot block before that gets through?
<slangasek> infinity: already added that one by hand, and fixing the freeze rule as a whole
<infinity> slangasek: Ta.
<slangasek> infinity: and somehow Laney's hint froze linux-firmware-nonfree, which somehow lp says is not in the archive
<infinity> flocculant: If all goes well, we expect to release between 12 and 2 London time, so ticking things ready a couple of hours before that (say, 9 UTC) would be nice.
<infinity> slangasek: It was in the archive when he generated the block.
<slangasek> infinity: it's meant to be gone?
<infinity> Yeah.
<infinity> We've been doing cleanup. :P
<slangasek> ok
<cjwatson> Yeah, I removed that earlier today.
<cjwatson> Well, yesterday.  Whatever.
<infinity> cjwatson: It's "today" until we sleep.
<cjwatson> The removal bug had only been open for like five months.
<cjwatson> orphaned-sources hopefully sorted now.
<flocculant> infinity: ....
<infinity> cjwatson: Worse, given that the bug was prompted by an AA review, and the AA failed to follow up.
<infinity> *cough*
<infinity> Not naming any names, ADAM.
<flocculant> I just knew you'd  say that - so I will be working - and likely to land at home ~1pm UTC
<flocculant> infinity: so expecting that I shortly ago asked the rest of xubuntu release to give me acks etc
<infinity> flocculant: Righto.  You don't have to be the one who tests everything (yay, delegation), just tick the ready box when you're happy.  Should be able to do that from a phone on the train. ;)
<flocculant> infinity: dude ...
<flocculant> I drive a van - me ensures that everyone is completely aware that if I run into someone while driving - adam made me do it :-
<infinity> flocculant: My usual MO for late confirmation is to publish you anyway, and if you tell me you hate your ISOs, we can pull/fix/whatever right before I do the last push.
<flocculant> infinity: ack :)
<flocculant> afauik we are all cool - mostly just want some sort of +'ves on thunar things
<infinity> flocculant: Yup.  My bar for flavours is "does it boot/install/reboot and not blow up the computer", but obviously you can (and should) be stricter, as appropriate. :)
<infinity> flocculant: Yup.  My bar for flavours is "does it boot/install/reboot and not blow up the computer", but obviously you can (and should) be stricter, as appropriate. :)
<infinity> flocculant: Bonus points for also not stabbing users in the face via the installer.
<flocculant> infinity: yup I tend to assume (and check~) that if I can't install - Ubuntu can't too - if Ubuntu can't then phew ...
<flocculant> ubuntu can fix that ;)
<infinity> ;)
<flocculant> https://launchpad.net/~xubuntu-release
<flocculant> is  completely up to date
<infinity> cjwatson: Alright, everything from the out-of-date outdate is sorted.  Will see how much more is broken when the new report spits out.
<tsimonq2> infinity: so all the release-critical bugs are fixed?
<flocculant> infinity: I recently pointed my testers at the 'fixed' thunar - if we get fails on tracker for things we can't fix or shout about then I'm cool
<infinity> tsimonq2: Every bug in the distro is fixed -- we can go home.
<tsimonq2> \o/
<tsimonq2> infinity: how will flavors know when it's time to release? will there be something here?
<tsimonq2> just out of curiosity
<Kamilion> now we just have to deal with overly huge packages like fonts-noto-cjk
<infinity> Yup.
<Kamilion> </sarcam>
<Laney> slangasek: Ah. That's not on the whiteboard list of doom in the office, so I guess I forgot it. Sozzles.
<tsimonq2> infinity: cool, thanks, have a nice night, and best wishes releasing :)
<Laney> Don't think any troublesome uploads happened
<infinity> Laney: Yeah, the whiteboard list was for LTS support, so ubuntu-desktop and ubuntu-server were lumped together.  Oops.
<flocculant> infinity: anyway - I''ll be aronund early, will try to be about 11ishfor tea, then luch time
<flocculant> then bluesabre will be arounf
<Laney> infinity: and someone wrote "Desktop" on it. :P
<infinity> I blame Andy.
<tsimonq2> plame popey
<tsimonq2> *blame
<tsimonq2> http://blamepopey.com/
<Laney> Right. Night.
<bluesabre> I should be around at 11urc
<bluesabre> utc
<bluesabre> :)
<flocculant> infinity: I blame Thursday's pretend Friday
<flocculant> bluesabre: hey :)
<flexiondotorg> infinity, At this point do you have a release ETA for tomorrow, err later today? ;-)
<flocculant> bluesabre: pretty much relies on not loads of 'oh god Thunar'
<infinity> flexiondotorg: Just the one I mentioned above. :P
<infinity> 23:21 < infinity> flocculant: If all goes well, we expect to release between 12 and 2 London time [...]
<flocculant> flexiondotorg: seems like lunchtime ... corned beef and pickle ;)
<infinity> Err.
<infinity> flexiondotorg: ^
<bluesabre> flocculant: we should be safe
<flocculant> bluesabre: yup
<flexiondotorg> Shit, that early.
<bluesabre> I won't be around at the 12-2 window
<flexiondotorg> OK.
 * Kamilion is rolling a xen iso from the lubuntu ISOs just published
<infinity> bjf: Can I get you (or someone else you know with raspi2 HW) to smoketest http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20160420.5/ for me?
<infinity> bjf: It's not on the tracker, so just pinging me with "it's not crap" will do.
<Kamilion> lemme track down a blank SD and I'll give it a go (if I can find a blank)
<flexiondotorg> Kinda means I'm up all night then,
<infinity> cjwatson: Huzzah.  Fresh run of outdate_all didn't expose any new badness, so pending a publisher cycle or two, that should clear out, I think.
<infinity> And there's my server ISOs.
<flexiondotorg> infinity, the Ubuntu MATE images didn't make it to cdimage. Only amd64 is there.
<infinity> flexiondotorg: It's probably still syncing.
<flexiondotorg> Yeah, there are popping up. SOrry.
<flexiondotorg> infinity, Are bugs in Ubiquity consider release critical?
<infinity> flexiondotorg: Depends on the bug.  At this stage in the game, it's got to be pretty amazingly critical.
<mwhudson> got a request to upload docker.io, there's no reason not to do that right now? (it's universe after all)
<flexiondotorg> infinity, Understood.
<infinity> mwhudson: Yeah, not seeded in anything.
<infinity> flexiondotorg: There will be point releases (first one in 3 months) to fix installer/ISO bugs, so if things aren't completely perfect, help polish for .1 :)
<mwhudson> infinity: ta
<slangasek> cyphermox: ^^ if you're still around and want to test some rpi2
<slangasek> (make that ^^^^^)
<cyphermox> ah, sure
<cyphermox> you're making me wipe out the device early enough that I didn't start setting up maas yet :)
<infinity> cyphermox: Iz not in the tracker, and it's too late now for that to be a priority, so just IRC ping results.
<cyphermox> yeah no worries
 * cyphermox zsyncs the image
<cyphermox> flexiondotorg: still want to know about that ubiquity bug, especially if it's different than the NVMe issue you mentioned earlier
<cyphermox> hrm
<flexiondotorg> cyphermox, Nothing yet. zsyncing.
<cyphermox> slangasek: is it normal given how the image is made, that it's nearly a full download again?
<infinity> Yeah, xz isn't remotely rsync-friendly.
<cyphermox> ok
<infinity> If we wanted it to be, we could unxz and gzip --rsyncable
<infinity> Perhaps worth a ponder for another time.
<infinity> If anyone cares deeply.
<cyphermox> it's not that big a deal, the image is fairly small anyway
<slangasek> infinity: except gzip doesn't do sparse.
<infinity> slangasek: That only matters on unpack, mind you.  But yeah, not ideal.
<infinity> (The packed file is still small, because it's just a bunch o' zeroes)
 * slangasek nods
<infinity> Alright.  I think I've done all I can usefully do tonight.
<infinity> Will aim to be back in ~8h or less.
<slangasek> infinity: anything you want me to do overnight?
<slangasek> infinity: also, do I get a packageset delta report?
<infinity> slangasek: ISO testing until you can't stand it anymore?  Particularly prodding people (or yourself) to help where flavours seem to be lacking, once Canonical stuff has good coverage.
<slangasek> k
<infinity> slangasek: Hot off the press: http://lucifer.0c3.net/~adconrad/packageset-changes-new-new.txt
<slangasek> infinity: ta
<cyphermox> infinity: do we need to run some changes script for the .0?
<infinity> cyphermox: Nein.
<cyphermox> given how long it takes to run ;)
#ubuntu-release 2016-04-21
<cyphermox> ack
<infinity> cyphermox: Unless you really feel like documenting every bug fixed since wily.
<cyphermox> not especially
<infinity> ;)
<cyphermox> I want to be able to use my computer to test tomorrow
<flexiondotorg> cyphermox, jderose Doing an OEM install. Ubiquity doesn't prompt to join WiFi networks. So proceeds without a connection.
<cyphermox> and you might want LP to not decide I'm evil and never respond to me ever again
<jderose> flexiondotorg: hmm, that was working just a week or so ago
<cyphermox> flexiondotorg: you should see nm-applet
 * infinity crashes.
<flexiondotorg> The applet is there.
<flexiondotorg> And works.
<flexiondotorg> However, Ubiquity itself no longer prompts for join a wireless network.
<flexiondotorg> When wifi is available.
<cyphermox> d'oh
<cyphermox> I should unxz that image before I write it shouldn't I? :)
<cyphermox> flexiondotorg: I don't know that oem-config ever did
<flexiondotorg> cyphermox, Yeah, it did. Both during the initial install and also in after it had been prepared.
<flexiondotorg> VirtualBox has a regression.
<jderose> cyphermox: it definitely used to prompt you to join the wifi network, although it was broken in 15.10. but it was working in 16.04 not that long ago (it was at most 2 weeks ago when i last tested)
<flexiondotorg> Had this in 14.10 where the graphics are screwed in the guest and you have to switch tty and back to correct the corruption.
<cyphermox> ok well then oem-config has been broken this way since before wily, not critical enough to scramble to fix and respin the images
<cyphermox> jderose: weird
<cyphermox> I tried looking into this, since at some point the applet was missing too
<cyphermox> but all indicates it *should* work
<jderose> cyphermox: yeah, i think you had it 100% fixed. but sounds like something might have changed
<flexiondotorg> oem-config wifi worked in wily and in xenial, as jderose said, just a couple of weeks back.
<cyphermox> maybe I have some weird ordering issue in the panels for OEM that I didn't notice
<cyphermox> jderose: I didn't change anything relevant for the network prompts there.
<flexiondotorg> The new a11y indicator has been introduced since.
<cyphermox> flexiondotorg: well, I distinctly recall you guys mentioning that wifi prompts didn't work when we were preparing wily.
<jderose> flexiondotorg: grub-install fails with nvme drives in BIOS mode on 14.04.4 also... so longstanding bug, not a regression
<cyphermox> if things started working again, and then started not working again, it sounds like it wasn't my conscious doing :)
<cyphermox> jderose: possible we didn't add nvme in grub-installer until after the .4 release
<cyphermox> well
<cyphermox> in fact either way it would not work since it doesn't work in xenial
<cyphermox> slangasek: armhf+raspi2 looks good.
<flexiondotorg> cyphermox, wifi prompts do not work in any install mode right now :-(
<flexiondotorg> cyphermox, What jderose and I reported in Wily was that there was no network indicator in oem-config after the prepare had been done.
<cyphermox> oh, nmcli dev must report all your wifis are wireds?
<flexiondotorg> Maybe. How can I confirm that?
<slangasek> run 'nmcli dev'
<flexiondotorg> OK, preparing next test machine. Will do that.
<flexiondotorg> So those last minute VirtualBox changes are busted.
<flexiondotorg> nmcli dev is correctly reporting wifi devices.
<flexiondotorg> Like I say, the network indicator works. I can manually join a wifi network. The issue is that Ubiquity is no longer prompting to do so.
<flexiondotorg> cyphermox, ^^^
<cyphermox> yeah, I see
<flexiondotorg> jderose, ack the nvme testing. Thanks.
<flexiondotorg> jderose https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1572793
<ubot5`> Launchpad bug 1572793 in ubiquity (Ubuntu) "Ubiquity no longer prompts to join available WiFi networks" [Undecided,New]
<cyphermox> ugh
<cyphermox> flexiondotorg: I fail.
<cyphermox> not sure why it's doing that, I'll have a look.
<cyphermox> can you file a bug?
<flexiondotorg> Oh, OK. I thought you were saying you couldn't reproduce for a moment :-)
<Kamilion> lost the ability to fully shutdown or reboot in virtualbox.
<Kamilion> (from the lubuntu64 livemedia)
<cyphermox> flexiondotorg: nah, something is clearly broken
<flexiondotorg> OK, I've done what testing I can. Tracker updated. Night. Or morning ;-)
<tsimonq2> cyphermox: you guys need anything else that I can help with?
<tsimonq2> cyphermox: for release tomorroe
<tsimonq2> cyphermox: *tomorrow
<cyphermox> test any image you'd like.
<cyphermox> report findings on iso.qa.ubuntu.com, as usual :)
<cyphermox> (and open bugs when you see some)
<tsimonq2> alright
<tsimonq2> that's all?
<cyphermox> yeah
<tsimonq2> cool :)
<darkxst> can someone approve that ^, so I can re-spin
<cyphermox> slangasek: ^ if you're still around
<slangasek> darkxst, cyphermox: looking
<slangasek> darkxst: why such a late seed change?  and doesn't this imply you'll have an extra session type now on the image that needs validated for release?
<slangasek> (package accepted into -proposed for building, but not unblocking into xenial yet to give you time to reconsider / demand I comply :)
<darkxst> slangasek, the fallback to X11 is broken on some systems, and yes a "wayland" session will show up
<slangasek> "fallback to X11" - without this package, aren't you currently using X11 on all systems?
<darkxst> we will still call the "wayland" session experimental though
<darkxst> gdm tries to start on wayland first
<darkxst> when that fails it should use X11
<slangasek> so "experimental" but used by default? :)
<darkxst> the user (login) session is experimental
<darkxst> that would need to be manually selected when logging in
<slangasek> alright, well, it doesn't sound to me like a change that is going to improve users' experience overall, but it's certainly your call - unblock hint added as well
<darkxst> gdm running on wayland is well supported, but I could also force that off in the config
<slangasek> so feel free to respin when it lands in xenial
<darkxst> well landing at a blank screen at boot is not a great experience
<Kamilion> well, I'll certainly jump on that, darkxst, I've been meaning to try wayland on as many bare metal boxes as I can, and that seems like a good opportunity
<mwhudson> hm go 1.6.2...
<mwhudson> nothing very urgent looking though, could just sru after release
<darkxst> hmm actually I might revert that and just patch gdm conf instead
<darkxst> slangasek, are you able to reject the -meta upload?
<slangasek> darkxst: it's already accepted so can't be rejected, but can be removed
<slangasek> assuming it hasn't already published to xenial, let me see
<slangasek> darkxst: ah yeah, it's already published to xenial.  Sorry, was expediting to not hold up your respins
<slangasek> darkxst: so, if you want to revert you need another meta upload
<slangasek> darkxst: ^^ is there also an ubuntu-gnome-meta revert coming?
<darkxst> slangasek, yes uploading now
<slangasek> ok
<slangasek> darkxst: both accepted and unblocked
<darkxst> slangasek, thanks
<cyphermox> moar coffeee
<slangasek> ogra_: looks like the arm64 build doesn't want to pull from multiverse
<slangasek> cyphermox: failed xubuntu test case; am I doing something wrong with my setup? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1572842
<ubot5`> Launchpad bug 1572842 in ubiquity (Ubuntu) "xubuntu 16.04 image does not give auto-resize option on 8GB disk" [Undecided,New]
<cyphermox> isn't 8gb slightly too small?
<cyphermox> come to think of it, for xubuntu it should be fine I think
<slangasek> well, that's what I don't knowv
<slangasek> I looked at actual usage, and it seemed it should have been enough space
<cyphermox> you may be able to tell from running ubiquity --debug; at some point you'll see ubiquity SUBST the free_space templates, and you'd have the size there
<cyphermox> it does seem like it should be plenty though
<slangasek> mmm
<slangasek> I'll just make the disk a bit bigger and retry
<cyphermox> I also can boot up a xubuntu vm with the same conditions and try it
<cyphermox> need to zsync that image first
<cyphermox> ENOTENOUGHPOWEROUTLETSHERE
<apw> cyphermox, bigger battery required ...
<cyphermox> yeah, battery replacements for old spare laptops
<cyphermox> well, old testing laptops I guess
<slangasek> cyphermox: same problem reproduced with 10G disk
<cyphermox> ok
<cyphermox> wow, this release is terrible for the installer
<cyphermox> I'm starting the ppc64el netboot test, and finishing the others I have been running, and then logging off
<slangasek> cyphermox: ok I had resized the disk to 10GB but realize that there was still a swap partition in the middle of that.  Blew that away, resized the original partition up to fill the disk, and now I have the auto-resize option
<cyphermox> ah?
<cyphermox> why would it matter that it's a swap?
<cyphermox> oh wait, we do explicitly swapon them now..
<cyphermox> no, that wouldn't matter either
<cyphermox> slangasek: please leave the bug open, I wonder if it's not that we don't deal with the swap correctly for resizing
<slangasek> cyphermox: well, I expect it makes a difference because it means it can't make space for the new OS just by carving up the existing install partition
<cyphermox> right
<slangasek> cyphermox: also, just dropped another comment on the bug - spectacular failures
<slangasek> so I'm going to consider this a failure and move on
<cyphermox> yeah
<cyphermox> slangasek: is it too late to save the exact crash message?
<slangasek> cyphermox: yes.  the crash message was self-explanatory to me, it was an "out of space" error, and the partition table confirmed this
<darkxst> trusty -> xenial upgrade for Ubuntu GNOME seems to have dpkg diverts in place still
<darkxst> diverted by libgbm1-lts-wily to: /usr/lib/x86_64-linux-gnu/old.libgbm.so.1.0.0
<slangasek> darkxst: please file a bug against xorg-lts-transitional tjaalton ^^
<cyphermox> slangasek: right, but you said crash, so I'm curious where it crashed exactly, but I can just find out after rest.
<darkxst> ok
<tjaalton> I don't see where that divert comes from..
<tjaalton> ah
<tjaalton> now I do
<pitti> Good morning
<pitti> iso testing time! :-)
<slangasek> tjaalton: yeah, so the new package in xenial will need to un-divert :/
<tjaalton> sure
<cyphermox> pitti: good morning
<darkxst> there is also the gbm drm driver diverted
<darkxst> bug 1572855
<ubot5`> bug 1572855 in xorg-lts-transitional (Ubuntu) "libgbm.so.1: cannot open shared object file" [Undecided,New] https://launchpad.net/bugs/1572855
<tjaalton> yep
<tjaalton> I guess this has been carried over to newer lts stacks for no reason
<tjaalton> anyway
<slangasek> xnox: your mainframes netbooting ok?
<cyphermox> slangasek: was the ppc netboot test you?
<slangasek> cyphermox: no
<slangasek> cyphermox: tracker says user 'sqldatapoo'
<cyphermox> yeah, I just hadn't look far enough
<slangasek> no idea if the described system is one that this is expected to work on
<pitti> I find it a bit confusing that we still have these "ubuntu core" tarballs; seems this got overloaded quite a lot by now
<cyphermox> slangasek: if we really care lots I'll try to boot my G5 again in the morning
<slangasek> cyphermox: surely that's a matter for the powerpc community to care about... sooner than the day before release
<cyphermox> of course
<cyphermox> but I wouldn't mind upgrading that system anyway
 * cyphermox -> sleep; back in ~4-5 hours
<tjaalton> ^ tested
<slangasek> tjaalton: the postinst->postinst.in logic /should/ be done in the build target, not in the clean target; it's valid to call build on the unpacked source without first running clean.  But LP builds call clean so this is ok.  But the maintscript logic worries me a bit; why do you have to do the dpkg-divert query, is it not guaranteed that the package which owns the divert is the same one currently
<slangasek> running?
<tjaalton> slangasek: copied it from a similar case when it removed xrandr diverts
<slangasek> that it was copied doesn't make me feel better about it ;)
<tjaalton> hear that
<tjaalton> maybe for scriptability
<slangasek> tjaalton: so if this were me, this would be the entirety of the postinst.in: http://paste.ubuntu.com/15960926/
<pitti> WTF
<pitti> ubuntu desktop/i386 with OEM still seems broken
<slangasek> tjaalton: this way, each package only removes its own divert
<tjaalton> slangasek: ok I can do that
<slangasek> tjaalton: cool; I'll reject the previous one, please test the above
<tjaalton> crap, need another victim machine :)
<slangasek> heh
<tjaalton> or I'll just add manual diverts of course
<slangasek> pitti: but on the bright side, there are no i386 OEMs?
<pitti> heh, yes
<pitti> well, we might still respin that one, there aren't too many test cases yse
<pitti> yet
<pitti> or we ignore this indeed
<slangasek> pitti: is it broken in a way that's fixable without source uploads that touch every image?
<pitti> slangasek: yes, this looks like the mirror desync again
<slangasek> ok
<pitti> live system has ubiquity 2.21.63, pool/ still has 2.21.59
<pitti> i. e. prodding that mirror and rebuilding just that iso should fix it
<pitti> infinity, cjwatson ^
<pitti> updated bug 1572436
<ubot5`> bug 1572436 in Ubuntu CD Images ""Prepare for OEM install" icon and oem-config-prepare missing on Ubuntu desktop i386" [High,Confirmed] https://launchpad.net/bugs/1572436
<pitti> and pool/ being out of date for ubiquity probably also means out-of-date-ness for other debs
<pitti> and we are shipping a binary which we don't ship a source for
<slangasek> mmm, would this impact all i386 images?
<pitti> let's hope not
<pitti> I don't think it's arch specific
<pitti> yesterday we had that on the amd64 image, and the current one is good
<pitti> file-roller xenial-desktop-i386.iso and checkign the version in pool/main/u/ubiquity/ is a quick test that doesn't even need installation
<slangasek> or checking the .list files
<pitti> indeed
<pitti> hm, hang on
<pitti> .disk/info says 20160419
<pitti> I just downloaded this an hour ago..
<slangasek> from the wrong url?
<pitti> http://cdimage.ubuntu.com/cdimage/daily-live/current/
<pitti> well, who knows, rsyncing again
<pitti> (oh the joys of mirror rotation :) )
<jibel> pitti, I'm retriggering the job that makes the copy.
<pitti> jibel: how do you mean?
<jibel> pitti, the copy between pending and current didn't happen
<jibel> the node crashed during the nighrt
<pitti> oh
<pitti> http://cdimage.ubuntu.com/cdimage/daily-live/current/ looks okay
<pitti> so maybe that actually updated in the last hour after I downloaded, or it's only one mirror that is affected?
<slangasek> or it's a problem that affected only your rsync endpoint, not the http endpoint?
<jibel> pitti, it should be now, I did it 5 minutes ago
<slangasek> ah, heh
<pitti> aah
<pitti> ok, .disk/info is current now, and so is pool/, sorry for the noise
<pitti> retest o'clock
<tjaalton> slangasek: ^ there you go. btw, debuild -S runs clean, so the package itself comes with the .postinst's so there should be no way to not have them :)
<slangasek> tjaalton: except the postinst is supposed to be different on each arch - anyway, that's not a blocker
<tjaalton> oh indeed, hehe
<Laney> hi
<flexiondotorg> pitti, How did that i386 issue manifest? Ubuntu MATE i386 images were some of the last made, I tested them last night. No issues with oem mode.
<pitti> flexiondotorg: yes, you'd notice because OEM mode is broken
<flexiondotorg> pitti, Thanks.
<pitti> that was an issue on a lot of images yesterday, and was supposed to be fixed; so I just fell into that "old image" trap
<infinity> pitti: WTF?  I did a hard ftpsync before building anything.
<pitti> infinity: yes, it wasn't the internal mirror after all, just a cdimage mirror being out of date (see above, jibel fixed it)
<infinity> Oh, you were looking at current, not the dated dirs
<pitti> yes, my daily rsync scripts do that
<pitti> all good on the current image
<Laney> tjaalton: Did you see the llvm-3.8/i386 FTBFS?
<tjaalton> Laney: yes, and uploaded a new version
<Laney> tjaalton: Ahhhhh, in the queue.
<Laney> Um
<pitti> infinity: does it make sense to manually test ubuntu core? (on some less common arches like arm64 or ppc64el), or do we have some automagic for that?
<Laney> Can't you just disable the relevant tests?
<Laney> Or are they the only ones?
<infinity> pitti: I do a quick run across all arches, it's a 2 minute affair.
<pitti> infinity: yeah, I thought the same, nice thing to do while watching ubiquity install :) ok, I'll leave this to you then
 * pitti would need more like 3 minutes per arch, not 2 minutes for everything
<cjwatson> pitti: *phew*
<pitti> cjwatson: *phew*Â² indeed
<flexiondotorg> I was testing last night. Not sure if you guys have seen the backlog.
<cjwatson> infinity: We could do the cloudfront uploads now, right?
<flexiondotorg> The VirtualBox updates that were included yesterday are a bit busted. Has a regression that reintroduces video corruption.
<flexiondotorg> Requires switching ttys to restore a usable display.
<infinity> cjwatson: Yup.  I was just going to run officeward, but if you want to relay the info to IS while I walk, yay.
<cjwatson> infinity: Will do.  Presumably just the pre-published ones?
<infinity> cjwatson: No, they want everything, I believe.
<cjwatson> flexiondotorg: That should be fixable in SRU, I guess.
<flexiondotorg> Ubiquity no longer prompts to join wifi networks - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1572793
<ubot5`> Launchpad bug 1572793 in ubiquity (Ubuntu) "Ubiquity no longer prompts to join available WiFi networks" [Undecided,Confirmed]
<flexiondotorg> cjwatson, Yes, except installs right now on VirtualBox appear broken.
<cjwatson> flexiondotorg: Right, sure, but the virtualisation host is usually easily updatable to SRUs.
<flexiondotorg> The install is fine, but on first boot video is completely screwed.
<cjwatson> (once they exist)
<mapreri> they ask me if you could accept a last-minute sync of virtualbox, changing nothing from the current version in debian but the version (maintainer uploaded both in debian and ubuntu for fear of hitting dinstall last night and not having the upload done to ubuntu)
<flexiondotorg> pitti, I confirm the swap issue is totally fixed :-D
<infinity> virtualbox isn't seeded, if someone had a magic fix, I'd take it.  Otherwise, meh.
<infinity> The "not seeded" part also means that an SRU with magically fix it.
<flexiondotorg> infinity, Kernel modules.
<infinity> flexiondotorg: The kernel modules builtin to the Ubuntu kernel didn't change.
<infinity> flexiondotorg: Only the dkms packages did.
<mapreri> "an SRU with magically fix it" s/with/will/ ?
<infinity> flexiondotorg: So, if your image was fine N days ago and broke recently, it's all the unseeded packages being pulled in later.
<pitti> flexiondotorg: yay
<infinity> mapreri: Will, yes.
<mapreri> infinity: do you mean an SRU will magically be accepted?
<flexiondotorg> infinity, Something changed. Has worked fine throughout 16.04 cycle until image built yesterday.
<mapreri> if so, guess I'll tell him "just wait tomorrow"
<infinity> mapreri: No, I mean an SRU that fixes it would DTRT, since the images aren't broken, it's packages pulled during install.
<infinity> flexiondotorg: Again, it's not the *image*, though, it's the archive.
<infinity> flexiondotorg: It's the drivers being installed from the archive at install.
<infinity> flexiondotorg: Installing without network probably wouldn't reproduce the bug.
<mapreri> ok.  i'll forward the NACK.  To me it seems crazy anyway bugging for only a version change :)  ta.
<infinity> flexiondotorg: And, thus, an SRU post-release would also fix it.
<flexiondotorg> infinity, So I install from the current image, without network connected, and the video is corrupt in VirtualBox.
<rbasak> infinity: I'm assuming the MySQL 5.7 upstream update will need to be a 0-day at this stage? In which case, probably the security pocket?
<infinity> flexiondotorg: Then that can't be virtualbox's (the package) fault, since it's not anywhere near your ISO.
<infinity> rbasak: Coordinate with the security team, yes.
<rbasak> OK
<flexiondotorg> infinity, I see linux-firmware-nonfree is no longer in the xenial archive.
<flexiondotorg> Is that intentional?
<Laney> https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/1513589 Yes.
<ubot5`> Launchpad bug 1513589 in linux-firmware-nonfree (Ubuntu Xenial) "linux-firmware-nonfree should be removed from Xenial" [Undecided,Fix released]
<flexiondotorg> infinity, Thanks. I'll need to request an update to Ubuntu MATE Welcome.
<davmor2> cyphermox: you about?
<davmor2> infinity: wizard is missing the connect to wifi page
<infinity> davmor2: Reported a few times over the last day.
<davmor2> infinity: I'm wondering if it is the update to 1.93 changes that broke it
<infinity> flexiondotorg: Respinning for MATE welcome alone is probably not reasonable at this stage, unless it's completely busted.
<infinity> flexiondotorg: As for your vbox woes, what's the host machine?  Is that also up to date xenial?  I can see it perhaps having broken on the host side.
<davmor2> infinity: network-manager that is :)
<ogra_> slangasek, infinity http://paste.ubuntu.com/15961377/ does that look sane ?
<Laney> oh god an ogra_ diff
<ogra_> lol
<flexiondotorg> infinity, Not to respin the image. Just a package upload. Is that OK?
<infinity> flexiondotorg: Only as an SRU.
<infinity> flexiondotorg: Images should match the release pocket.
<infinity> ogra_: Probably not.
<flexiondotorg> infinity, So I should not file an package update in the usual way?
<ogra_> infinity, well, how else do i get multiverse into a dedicated chroot then ?
<Laney> flexiondotorg: Do an SRU in the usual way
<flexiondotorg> Laney, Never done one before.
<Laney> Then reading https://wiki.ubuntu.com/StableReleaseUpdates#Procedure is in your future. :)
 * ogra_ grumbles about last minute landing that make everything explode
<ogra_> *landings
<cjwatson> pot, kettle, ... :-)
<infinity> ogra_: That didn't "make everything explode", you were building from a PPA before. :P
<ogra_> infinity, well, i''m naggibng the kernel team since 6 weeks about the rpi kernel that was stuck in proposed
 * flexiondotorg is already reading about SRU
<ogra_> especially to avoid shuch crap
<infinity> ogra_: http://paste.ubuntu.com/15961413/
<infinity> ogra_: That's probably what you want.
<ogra_> infinity, that wont work
<infinity> Because?
<ogra_> because there is adedicated chroot freshly debootstrapped
<ogra_> will a plain debootstrap call pick up COMPONENTS= ?
<infinity> ogra_: Which you use the previous sources.list for.
<infinity> ogra_:       cp -a chroot/etc/apt/* chroot-device/etc/apt/
<ogra_> oh, wait ... i think i'm copying /etc/apt
<infinity> ogra_: So, yes, it'll work.
<ogra_> yeah :)
<ogra_> thanks !
<infinity> ogra_: If it didn't work, you wouldn't have a kernel either (since debootstrap only uses main, and your kernel is universe)
<ogra_> indeed
<jibel> anyone know if the wifi page has been removed from ubiquity on purpose?
<jibel> cyphermox, ^
<jibel> cf bug 1572793
<ubot5`> bug 1572793 in ubiquity (Ubuntu) "Ubiquity no longer prompts to join available WiFi networks" [Undecided,Confirmed] https://launchpad.net/bugs/1572793
<jibel> nevermind, I scrolled up
<ogra_> cjwatson, i assume i can land your livecd-rootfs change alongside ?
<cjwatson> ogra_: yes
<cjwatson> that was "I never want to see that particular mistake again"
<ogra_> heh
<pitti> o_O what happened to 2.407?
<ogra_> dch -i ... seemingly ...
 * ogra_ sighs
<Laney> :)
<ogra_> should i re-upload ?
<ogra_> ok
<infinity> And rename that tag. :P
<infinity> Well, delete that tag.
<Laney> Tag the taggy tag
 * ogra_ notes he cant win ... i spent nightshifts the last weeks making sure everything is fine and snappy builds rock solid ... to avoid exactly these last minute hacks ... :((((((
<ogra_> sigh
<ogra_> ssh: Could not resolve hostname bazaar.launchpad.net: Name or service not known
<cjwatson> I swear we haven't decommissioned it
<ogra_> haha
<davmor2> infinity, jibel: so the wifi page doesn't show in standard setup or in the End User setup in oem mode so I assume we need a fix for this right?
<davmor2> pitti: on a good news side of things No swap space error dialogue \o/
<infinity> davmor2: Not a fix in the sense of an ISO respin.  AFAIK, the nm-applet still works, so you can configure there instead.
<Laney> Sounds like a release note + SRU
<pitti> i. e. fix for 16.04.1?
<pitti> sucks a bit, but meh
<infinity> Sucks less than delaying the release for a day for it.
<infinity> (a day or more, since no one's quite sure what the bug is yet)
<flexiondotorg> Laney, Can an SRU be a point release "upgrade" or should it just be a patch to the existing version?
<infinity> flexiondotorg: I'm not sure I understand that question.
<flexiondotorg> ubuntu-mate-welcome is currently 16.04.9. I've pushed and change and built it in a PPA as 16.04.10
<flexiondotorg> Can the SRU introduce the newer version?
<Laney> Yes
<flexiondotorg> Laney, ty
<cjwatson> yofel: can nepomuk-widgets be removed?  it seems to have a bunch of uninstallables
<yofel> cjwatson: kill it
<cjwatson> yofel: awesome, thanks.  is it superseded by something I can log in the removal message?
<yofel> nepomuk itself was obsoleted by baloo, so nothing should be using nepomuk-* anymore
<cjwatson> ok
<cjwatson> yofel: how about declarative-plasmoids?
<davmor2> infinity: might be a secondary issue with wifi on oem mode just reinstalling to check on it
<yofel> cjwatson: "Depends: kdeworkspace-bin", that's kde4 and can go too
 * cjwatson nukes
<cjwatson> yofel: startactive too?  I think that's the last of the KDE-specific all-arch uninstallables
<yofel> cjwatson: yes, can go too
<cjwatson> done
<flexiondotorg> Laney, infinity Does this look like what you'd expect? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1572931
<ubot5`> Launchpad bug 1572931 in ubuntu-mate-welcome (Ubuntu) "SRU: ubuntu-mate-welcome 16.04.10 bug fix [dsc attached]" [Undecided,New]
<Laney> flexiondotorg: Sure, although I think you should apply some imagination to the regression potential section :)
<flexiondotorg> Laney, it's accurate :-)
<Laney> Yeah right
<flexiondotorg> So, I should also subscribe the sru verification team?
<Laney> No
<Laney> Nominate to xenial, then upload or subscribe sponsors
<flexiondotorg> Sponsors subscribed.
<flexiondotorg> Laney, Do I nominate xenial using tags?
<Laney> No, there's a link for it below the list of bug tasks
<Laney> But if you can't see it then don't bother
<flexiondotorg> Laney, I don't see bug tasks :-(
<Laney> k
<Laney> I don't remember what permissions it needed
<cjwatson> yofel: oh, one more, how about sentinella?
<cjwatson> cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797942
<ubot5`> Debian bug 797942 in src:sentinella "sentinella: build-depends on obsolete kdebase-workspace-dev" [Serious,Open]
<cjwatson> maybe I should demote that one to -proposed since there seems at least some chance that it might be fixed at some point, and it's synced from Debian
<cjwatson> yeah, I've argued myself into that, done
<davmor2> infinity, jibel: yeap confirmed second oem install and I have no wifi for the end user http://people.canonical.com/~davmor2/desktop-screenshots/wifi-broken.png
<davmor2> I need to reboot the end user session to get working wifi
<flexiondotorg> infinity, Using different 16.04 host, which is fully updated. Installing a VirtualBox guest I have no video corruption :-)
<apw> davmor2, "reboot the user session" means logout/in again ?
<flexiondotorg> infinity, Looks like you're right about host/guest mismatch.
<davmor2> apw: no means reboot the machine
<apw> davmor2, what what wifi driver is that using?
<davmor2> apw: 1 second
<davmor2> apw: Intel Corporation Centrino Wireless-N 2200 (rev c4)
<davmor2> apw: it works in the installer, let me see what happens if I enable it in oem user and enable it in enduser setup too
<apw> davmor2, nothing eosteric then, i would be a bit supprised broken kernel side ... /me looks sideways at network-manager
<Laney> darkxst: can haz testing?
<darkxst> Laney, if you mean on QA tracker, there was a late respin with a minor gdm change
<seb128> Laney, darkxst, I'm downloading a i386 GNOME iso for testing
<Laney> darkxst: OK, so you don't need to fully test everything then
<darkxst> Laney, I am pretty happy with 20.1 results for amd64, but yeh we are lacking for i386
<ginggs_> flexiondotorg: i nominated your ubuntu-mate-welcome bug for xenial
<flexiondotorg> ginggs_, Thank you :-)
<flexiondotorg> pitti, I confirm https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1572863
<ubot5`> Launchpad bug 1572863 in language-selector (Ubuntu) "no "incomplete language support" note in offline xenial install" [Undecided,Confirmed]
<pitti> flexiondotorg: seb128 told me that there were some deliberate changes there; so this might actually just be an outdated test description
<flexiondotorg> OK.
<pitti> I didn't check whether I got spell checking in LibO, I just ran check-language-support and got two handfuls of missing packages
<seb128> pitti, well, didrocks' changes inted was to have full support on the iso for the main languages afaik
<seb128> like opening language-selector shouldn't display you the  incomplete dialog
<seb128> if that's not the case then there is a bug
<Laney> pitti: Did you do some componenty stuff for xorg-lts-transitional? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xorg-lts-transitional needs some fixing up
<pitti> seb128: ok, I'll reinstall that scenario again and check this
<seb128> pitti, https://lists.ubuntu.com/archives/ubuntu-devel/2015-December/039028.html has the details
<pitti> Laney: they all got seeded, so I promoted them into main; I  guess for the universe packages those metapackags need unseeding?
<seb128> "1. Install full language support for those shipped on xenial image. It
<seb128> means that opening "language selector" won't request any additional
<seb128> package to install[1]."
<seb128> pitti, ^
<seb128> so yeah that was the intend
<seb128> unsure if that's working as expected or if we have a bug though
<pitti> just started a new VM test install, ETA 3 mins
<tjaalton> Laney: no, can't disable just some tests and filing a bug report just to fix a FTBFS is unnecessary paperwork I think
<pitti> (installing onto tmpfs is  fun!)
<davmor2> Okay so I am in oem mode right now and I see available Networks so it is fine there. Moving onto End user setup environment
<seb128> darkxst, is the GNOME iso supposed to boot to a "get me started" screen with any obvious installer link/icon?
<pitti> tjaalton: so I suppose the bits in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xorg-lts-transitional need unseeding?
<Laney> tjaalton: Not if you want to SRU it it isn't.k
<tjaalton> Laney: there is #1564156 already, should it be on every changelog entry?
<davmor2> Wifi networks are available in end user creation page
<tjaalton> pitti: where did all that come from..
<pitti> tjaalton: not sure, I suppose someone seeded the transitional metapackages into main wholesale without realizing that some drivers are in universe?
<tjaalton> pitti: oh, then yes drop those
<apw> tjaalton, there are two on that list that look odd ... the two libegl1-....-dbg ones depend on a non -dbg one in xenial ... is that rght ?
<tjaalton> apw: mesa doesn't build separate -dbg packages anymore
<apw> tjaalton, ack thanks, ignore me then :)
<davmor2> Bingo Nothing in the end user desktop session, seb128 I assume that means it's actually some config getting screwed up by oem-config setup thingy right?
<Laney> pitti: Looks like the "!" stuff doesn't work that way
<seb128> davmor2, having the logs would help to know
<Laney> pitti: Are you fixing it? It needs to specify the binaries individually
<pitti> Laney: haven't started looking yet, still figuring out an install bug
<tjaalton> apw: this was best I could figure out to make sure the lts dbg packages get replaced
<davmor2> seb128: yeap I just did another fresh install to figure out at exactly what point it broke
<tjaalton> than not depend on anything
<davmor2> seb128: I'm triggering the bugs now
<pitti> seb128: done, started language-selector, getting the "incomplete language support" dialog
<apw> tjaalton, right ... happy enough ... noticed the oddity so just wanted to make sure it was intended, which it is
<seb128> pitti, k, so bug :-(
<pitti> seb128: however
<seb128> suck
<seb128> which packages are missing?
<pitti> seb128: looking more closely, this only affects the English stuff and some -de-at and -de-ch
<seb128> ah
<seb128> you didn't pick proper de?
<tjaalton> apw: yeah, actually an empty depends would've worked just the same.. and is used for libopenvg-*
<seb128> oh
<seb128> you mean it lacks some de-at- and de-ch variants
<pitti> seb128: I do have -de-de actually
<pitti> so, it's actually fine
<seb128> k, gotchat
<seb128> so it might work with -it or -fr
<pitti> seb128: I suppose you'll also get the -en-gb stuff for fr or it
<pitti> but that's ok -- we really don't need to show a notification for those
<Laney> pitti: OK, looking here then
<seb128> right
<seb128> why does it want -en-gb on a de or fr install?
<davmor2> seb128: because en-gb is the most awesome language variant in the world obviously ;)
<seb128> rrrright ;-)
<davmor2> seb128: I'm sensing sarcasm in that rrrrright :D
<flexiondotorg> infinity, Have you started syncing the release images to the mirrors?
<seb128> you are seeing things... ;-)
<pitti> seb128: well, we also enable an English keyboard by default :)
<pitti> seb128: bug 1572863 updated, thanks for the heads-up
<ubot5`> bug 1572863 in language-selector (Ubuntu) "no "incomplete language support" note in offline xenial install" [Undecided,Won't fix] https://launchpad.net/bugs/1572863
<seb128> pitti, thanks
<seb128> pitti, the english keyboard is actually needed to get e.g ctrl-C to work on non latin locales
<seb128> so there is a valid reason
<davmor2> seb128: bug 1572956
<ubot5`> bug 1572956 in network-manager (Ubuntu) "Oem install end user has no wifi" [Undecided,New] https://launchpad.net/bugs/1572956
<davmor2> seb128: not sure if the logs will lie because I had to enable wifi to send the bug report
<seb128> davmor2, how did you enable wifi and at what time in that log?
<pitti> RAOF, infinity: do you see any reason to actually keep http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dovecot? ubuntu4 reverts ubuntu3, so IMHO we should just remove that from -proposed
<davmor2> seb128: you have to reboot to enable it
<infinity> pitti: We're just going to toss it into y-proposed.
<pitti> there is no net change
<seb128> davmor2, there is onlye one boot in https://launchpadlibrarian.net/254822439/WifiSyslog.txt
<infinity> pitti: Mostly to avoid versions going backwards and being confusing.
<seb128> davmor2, is that the first or the reboot?
<infinity> pitti: But yes, no net chage.
<davmor2> seb128: probably the reboot, the oem end user session is launched from the oem enduser installer so the boot stuff for that would be in other logs I guess
<seb128> davmor2, could you collect those logs then?
<davmor2> seb128: no idea what or where they would be but I can have a dig around
<seb128> davmor2, some people on this channel can probably help you
<pitti> Laney: I think you need to look at xenial, not trusty, for the components
<pitti> Laney: e. g. xserver-xorg-video-mach64 was demoted in xenial only
<pitti> so the transitional must be in universe, too
<pitti> ^ no heart attack, please; this is SRU material
<pitti> (0-day, or N-day for low N)
<davmor2> seb128: syslog I attached shows some stuff from both oem and dave as users where it changes from oem to dave there are some warnings around network-manager that don't seem to be further down which I assume is after reboot, will keep digging though
<Laney> pitti: Hm, then maybe I need to look at the *Depends* and not the package itself
<seb128> davmor2, yeah, I think you got the right log, unsure about the issue though, maybe cyphermox has a better clue
<seb128> Apr 21 11:28:18 oem-Lenovo-IdeaPad-Y580 NetworkManager[887]: <info>  [1461234498.2955] (21710752) ... get_connections (managed=false): return empty list.
<seb128> that looks wrong though
<seb128> hum, though it's doing that as well on the working boot..
<Laney> pitti: Re-running
<Laney> pitti: https://paste.ubuntu.com/15963110/ ?
<Laney> (pushed anyway)
<Laney> (so wait for the *next* c-m run please)
<ogra_> Setting up linux-firmware-raspi2 (1.20151118+b70b451-0ubuntu1) ...
<ogra_> cp: cannot create regular file '/boot/firmware/bootcode.bin': No such file or directory
<ogra_> dpkg: error processing package linux-firmware-raspi2 (--configure):
<ogra_>  subprocess installed post-installation script returned error exit status 1
<ogra_> Setting up linux-image-raspi2 (4.4.0.1009.9) ...
<ogra_> Errors were encountered while processing:
<ogra_>  linux-firmware-raspi2
 * ogra_ curses loudly 
<ogra_> apw, ^^^
<ogra_> what the hell is /boot/firmware even ...
<infinity> ogra_: The package always had that, that's not new.  I'm guessing you weren't using it before?
<infinity> ogra_: /boot/firmware is a vfat mountpoint, evidently.
<ogra_> infinity, the package was not accessible for me until yesterday late evening (the final snappy images were built yesterday monring)
<ogra_> (i'm just trying to rebuild the mess now, after that package was stuck 6 weeks in proposed)
<ogra_> apw, ppisati ^^^ can you fix that ?
<apw> ogra_, its where the firmware has to be i am told
<apw> is that _not_ true ?
<infinity> ogra_: "not accessible"?  rasperrypi2-firmware has been in the archive for months, we just renamed it.
<ogra_> apw, havging a hardcoded mountpoint check in the postinst makes the package uninstallable in chroots
<apw> infinity, we did change how the copy was done but still copied to there
<apw> ogra_, it has a do_chroot check round it
<infinity> ischroot, even.
<infinity> What it doesn't do is create the dir.
<infinity> Cause it's meant to be there, in theory.
<ogra_> ok,. i'll hack that into livecd-rootfs then
<ogra_> but the package needs fixing too
<infinity> Fixing to do what?
<ogra_> create the dir
<infinity> Maybe.
<ogra_> (i have no clue what that dir is supposed to do ... we definitely dont use it in snappy)
<apw> then we might want to stop copyuing things into it ...
<apw> ppisati, ^^^^^^
<ogra_> (and couldnt, since the gadget would over-mount something )
<infinity> If you "don't use it", then why are you installing that package?
<infinity> Given that its entire purpose it to install that boot-related firmware.
<infinity> It doesn't seem to have any runtime firmware.
<ogra_> infinity, i need whats in /lib/firmware ... which is supposedly the wlan fFW for the pi3
<ogra_> which is the whole purpose of me using that package
<ogra_> (and video stuff for the pi2 toop afaik)
<ogra_> err ...
<infinity> Nothing there looks like wifi firmware to me.
<ogra_> so looking at the package there is nothing if the stuff we had in the former pi2 firmware package
<ogra_> *of the
<ogra_> where is that gone ?
<infinity> It's *identical* to the previous rpi2 firmware package.
<infinity> Unless you mean some package you had in some PPA, which we weren't aware of.
<infinity> In which case, thanks for telling us about it.
<ogra_> infinity, all i ever did was copy package packagfes that were supposed to go to the archive from the kernel team to the snappy PPA
<rbasak> xnox: hey, edit conflicts in the release notes. Did you pay attention to my lock?
<pitti> Laney: thanks, shoudl have updated by now; http://people.canonical.com/~ubuntu-archive/component-mismatches.txt looks a little thin, though? or did you already demote some lot?
<xnox> rbasak, i have and i have cancelled my edit
<Laney> pitti: Needed some more Extra-Excludes
<pitti> Laney: like, shouldn't at least -mach be in there?
<infinity> pitti: Need another run after some more changes I made.
<xnox> rbasak, and re-did mine after yours...
<ogra_> anyway ... i'll drop the firmware package and pray tha the snappy images will at least boot with the new packages ...
<pitti> ah
<xnox> rbasak, is everything good or did we loose thigns?
<Laney> germinate is hard
<pitti> ok, let's give this another cycle then
<ogra_> i really diont get why that stuff has to land one day before release
<pitti> Laney: thanks
<infinity> ogra_: I guess your complaint is with Paolo then?  apw and I were only working with what was in the archive.
<infinity> ogra_: And nothing "landed" before release, except a package rename.
<rbasak> xnox: everything I wnated is still there. Can you check yours? Then I'll clear the markers.
<infinity> ogra_: Well, not for rpi2.
<ogra_> infinity, well, again ,... the rpi package was sitting in -proposed for weeks
<xnox> rbasak, my stuff is good
<infinity> ogra_: A new kernel was.  The old kernel and firmware had been in the release pocket for months.
<ogra_> and i was poking about it since at kleast 4 weeks
<infinity> ogra_: I know, because I was building images with it.
<rbasak> xnox: OK I'll clear the markers. I have another change to make, too.
<xnox> rbasak, imho it should be fine for multiple people to edit non-conflicting sections wikimedia stile.
<ogra_> all snappy images were built and tested yesterday ... everyone who could work on them is off today, i'm just trying to cover the fallout here now
<infinity> ogra_: You had a *long* time to test that firmware package in the release pocket and tell us it was wrong.
<infinity> "Published on 2016-02-12"
<infinity> https://launchpad.net/ubuntu/+source/raspberrypi2-firmware/+publishinghistory
<ogra_> i'm, talking about the kernel
<infinity> ogra_: Again, there was an older kernel in the release pocket too, just not the latest rebase.
<infinity> ogra_: Waiting on the latest to test things isn't helpful.
<ogra_> infinity, yes, that old kernel is in our snappy release today
<ogra_> we havent build rpi from the PPA for at least 6 weeks
<infinity> ogra_: Anyhow, you were complaining about firmware, not kernels, I'm saying the firmware has been in this state for months and no one thought to tell us it might be wrong.
<ogra_> (dragonboard was the only one having a PPA kernel til yesterday)
<rbasak> jamespage, jcastro, teward: right now new package version notes for server packages in the Xenial release notes are split between "Updated Packages" and "Ubuntu Server" - pretty inconsistent. How should we resolve this?
<infinity> rbasak: Please.
<rbasak> Yeah but how? Move updated server packages to the update packages section? Or pull server updated packages out of the updated package section?
<rbasak> Maybe the former?
<infinity> rbasak: Traditionally, we put server/desktop bits in their own sections.
<infinity> rbasak: And the "updated packages" section is for core stuff like kernel, systemd, whatever.
<rbasak> infinity: OK. I'll move the server stuff down.
<infinity> Frankly, most updates don't need to be documented anyway.
 * rbasak wonders if LXD is an updated package.
<Odd_Bloke> rbasak: I think we definitely want something in there about the bridge changes.
<infinity> It's only worth documenting if it's either a big press release bullet point ("Yay, juju2 is awesome" -- Fictional User), or if it's something people need to pay attention to ("New MySQL, watch for config breakage")
<rbasak> Yeah, but people seem to want to document the New Shiny in the release notes.
<rbasak> Odd_Bloke: do you mind writing that up please?
<jcastro> rbasak: you can copy our stuff into Server, that's fine, don't really feel strongly one way or the other
<infinity> rbasak: Yup, there's a section for shiny, just limit it to things that seem legitimately shiny.  Like "apache bumped from 2.2.7 to 2.2.32" is not shiny, for instance.
<jcastro> it's a major release that doesn't support upgrades though
<Odd_Bloke> rbasak: I would prefer it if stgraber or someone else on the lxd team did, as I don't think I have a full grasp of it. :)
<jcastro> well, let me rephrase, upgrading from 1->2 is non-trivial
<stgraber> Odd_Bloke: boarding a plain in 2 minutes so won't be able to help much with that, sorry :)
<Odd_Bloke> stgraber: How convenient. ;)
<stgraber> Odd_Bloke: I did tweak the "shiny" LXD paragraph earlier, I guess the bridge stuff should go separately in upgrade notes or something
<stgraber> Odd_Bloke: basically telling people to read their screen :)
<Odd_Bloke> stgraber: :)
<stgraber> we do show a pretty clear warning telling them exactly what's going on and what to do about it
<rbasak> OK, server stuff moved down. I decided LXD was "server" and moved it down too.
<rbasak> I put everything at the bottom. Feel free to edit the order.
<stgraber> Odd_Bloke: which boils down to, run "sudo dpkg-reconfigure -p medium lxd" and answer the questions
<rbasak> Is mvo not around? There's bug 1554121 which I think should probably be noted
<ubot5`> bug 1554121 in Release Notes for Ubuntu "unattended-upgrades defaults to installing security updates" [Undecided,New] https://launchpad.net/bugs/1554121
<infinity> rbasak: Works for me.  In my mind, virt/pseudo-virt (qemu, xen, lxc, lxd) should be "core", but our corproate structure disagrees with me. :)
 * stgraber diappears for 2-3 hours
<stgraber> *disappears too
<Odd_Bloke> https://twitter.com/ubuntu/status/723112408437284864 *facepalm*
<rbasak> infinity: opinion on unattended-upgrades note? I'd like to also say what users should do to disable it but I don't know what that is exactly.
<rbasak> bug 831487 suggests that it should be purgeable but germinate-output suggests otherwise to me.
<ubot5`> bug 831487 in software-properties (Ubuntu Xenial) "Dependency on package unattended-upgrades on Ubuntu Server" [High,Fix released] https://launchpad.net/bugs/831487
<flexiondotorg> Odd_Bloke, Everytime :-)
<ppisati> ogra_: infinity: apw: that's the raspi2 firmware from my ppa, i think it was never used to build a snappy | ubuntu img before
<ogra_> ppisati, yes, i falsely assimed it had firmware in it ... not bootloaders ...
<ogra_> i uploaded a new livecd-rootfs to archive and PPA and will do another testbuild
 * ogra_ hopes these kernels will at least still boot on snappy
<flexiondotorg> http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-download-new-features
 * ogra_ wishes creating a snappy image wouldnt be a multi hour process with all the manual snap uploads ... then downloading them again from the store ... yadda yadda .... 
<infinity> rbasak: You can change the preferences.  I'm not sure that telling people how to reduce their security is a thing that belongs in release notes, though.
<ogra_> ppisati, so if thats only bootloader stuff, wghere do i actually find the driver related firmware files for the raspberries ?
<flexiondotorg> infinity, How goes the sync? ETA?
<ppisati> ogra_: which one?
<infinity> flexiondotorg: It's in progress.  ETA is in the next hour or so.
<ogra_> ppisati, wlan for pi3 ... videocore stuff for both ?
<ppisati> ogra_: i think we never packaged those
<infinity> pitti: Are you mangling overrides?
<ogra_> hmm, k
<flexiondotorg> infinity, ty
<infinity> pitti: If not, I'll take a lock on it, so we don't stomp on each other.
<ppisati> ogra_: the wifi driver for thr pi3
<ppisati> let me think
<pitti> infinity: not ATM, I was waiting for c-m to update, which apparently happened now
<pitti> infinity: ack
<ogra_> ppisati, i remember we dug up the firmware file together
<ogra_> some weeks ago
<ogra_> ppisati, brcmfmac43430-sdio.txt and brcmfmac43430-sdio.bin iirc
<flexiondotorg> ogra_, Those firmware we updated recently.
<ogra_> flexiondotorg, in the archive ? (if so, in which package)
<flexiondotorg> ogra_, From the Raspberry Pi Foundation.
<flexiondotorg> ogra_, https://git.launchpad.net/ubuntu-pi-flavour-maker/tree/firmware
<flexiondotorg> I'm an "insider"
<flexiondotorg> Make the wifi much more reliable.
<ogra_> flexiondotorg, right, i'm talking about the archive ... the snappy images need to use everything form the archive now
<flexiondotorg> ogra_, OK.
<infinity> ogra_: We can SRU firmware fixes post-release, we'll sort this out.
<flexiondotorg> When the 16.04 release madness is behind us. I'd like to catch up with you on the Pi stuff.
<ogra_> infinity, yeah, i'm more scared that something doesnt boot now since these kernel packages didnt see any testing in the snappy world before ...
<ogra_> the build should at least besorted though :)
<ogra_> (one would hope :P )
<infinity> ogra_: changelog formatting is hard?
<ogra_> hmm ?
<infinity> +  * drop linux-firmware-raspi2, it does not actually contain driver
<infinity> +  firmware but bootloaders (and fails to install if its target dir
<infinity> +  is missing).
<ogra_> whats wrnmg with that ?
<infinity> "firmware" and "is" should be aligned with "drop"?
<ogra_> oh
 * ogra_ wonders why thats not automatic for him ... i only used dch ...
<ogra_> infinity, reject then, i have a new upload ready
<infinity> ogra_: Alright, after this, all new livecd-rootfs are SRUs.
<ogra_> ok
<infinity> slangasek: ^-- Committed the packageset changes, if anyone has any comments on things needing to be changed, we can do it post-release.
<de-facto> hmm what does this mean?
<ogra_> how big is main now ? are we down to three digits ?
<infinity> It's still pretty big.
<infinity> -rw-r--r-- 1 lp_publish lp_publish 1410686 Oct 22 12:48 wily/main/source/Sources.gz
<ogra_> heh ... 7me likes how s390x and ppc64el take less than 10mins for snappy images
<infinity> -rw-r--r-- 1 lp_publish lp_publish 1102679 Apr 21 13:12 xenial/main/source/Sources.gz
<ogra_> hmm, still a bit
<ogra_> i thought it would be more significant though
<cyphermox> good morning
<g4z> good afternoon
<tjaalton> editing release notes to mention the llvm issue on skylake
 * flexiondotorg sat in the back of the car. infinity are we nearly there yet?
 * ogra_ hands flexiondotorg an icecream cone
 * flexiondotorg rubs icecream into the upholstery out of boredom ;-)
<ogra_> !
<ogra_> infinity, hurry up ... he is making a mess !
<tjaalton> Laney: I've reuploaded llvm to include the previous changelog entry in .changes
<Laney> tjaalton: thanks
<Laney> I saw that
<Laney> pitti: ^^^ maybe if you're free you could review that for a 0-ish-day?
<nearffxx> wtf guys
<nearffxx> when it will be released?
<teward> nearffxx: not helping
<ogra_> sigh ... having to download something from cdimage on release day is like punishment :P
<teward> nearffxx: it will be released when it's ready to be released - you need patience
<g4z> lol... very helpful nearffxx :D
<cjwatson> (I'll make this channel moderated for the time being if need be; if you don't want that then please don't hassle us)
<pitti> Laney, tjaalton: is that actually an useful SRU? it sounds like something that should be stashed into git for the next real SRU?
<tjaalton> pitti: yes it's useful, read the entry on https://wiki.ubuntu.com/XenialXerus/ReleaseNotes :)
<pitti> it sounds like an update people would get for zero effect and nonzero risk
<tjaalton> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#A6th_gen_Intel_Core_CPU.27s_and_llvmpipe_software_rasterizer
<tjaalton> allows installing certain type of systems and then not fall over when logging in the first time
<nearffxx> what's the status of the building machine?
<rbasak> tjaalton: does that mean live mode won't work? Do we need to note that?
<pitti> tjaalton: ah, understood; was confused because the changelog doesn't refer to anything, but I missed the version already in -proposed
<tjaalton> rbasak: right, I'll add that
<rbasak> Thanks :)
<tjaalton> rbasak: also, the apache merge fail earlier; it was due to me just copying debian/ from the then-current package on top of git, so a file removal didn't show, duh..
<rbasak> tjaalton: np, it's sorted now. And handily with this being an LTS we can drop the conffile removal in the first upload of the new cycle.
 * flexiondotorg starts poking soggy wafer into the CD player ;-)
<jderose> infinity: slangasek: tjaalton: so i was going to wait for the new llvm-toolchain-3.8 package to at least hit proposed before i added instructions on working around the problem to the release notes, but now i'm thinking i should just add the instructions now even though i can't yet test it in real life. what do ya'll think?
<tjaalton> jderose: I'm writing them now, you can edit the grammar etc to your liking once I'm donw :)
<tjaalton> *done
<jdstrand> fyi, click-reviewers-tools uploaded (it is in universe). it is fine for release or as 0-day
<jderose> tjaalton: ah, thanks! you beat me to it :)
<jderose> tjaalton: but seems that builds haven't started yet for 2ubuntu3? https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8
<willcooke> tjaalton, are you still editing the release notes?
<willcooke> I can wait, just askin'
<willcooke> oh, just read the backlog - looks like yes you are
<teward> jderose: it looks to me like they're running now?  https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8-2ubuntu3
<jderose> teward: ah, yup, i didn't notice the "latest uploads" link
<tjaalton> willcooke: done now
<tjaalton> jderose: it got rejected once, will take some time
<flocculant> willcooke: if you're going to edit could you add https://xubuntu.org/news/xubuntu-16-04-release to the Official Flavours for me - pretty please :)
<xnox> flocculant, willcooke - ok
<xnox> flocculant, willcooke - done
<flocculant> thanks xnox :)
<flexiondotorg> willcooke, xnox Please can you add https://ubuntu-mate.org/blog/ubuntu-mate-xenial-final-release/ to the Official Flavours for me - pretty please :)
<flocculant> pffft - copycat there :p
<knome> flocculant, but our URL is shorter ;)
<flexiondotorg> flocculant, :-)
<flocculant> :)
<flexiondotorg> knome, But mine is longer ;)
<knome> TMI
<ogra_>  ..... 44,1KB/s  ETA 18m 21s
<ogra_> *sniff*
<ogra_> (downloading kernel snaps from cdimage to push them to the store)
<yofel> willcooke, xnox: on that topic: please also add https://kubuntu.org/news/ï¿¼kubuntu-16-04-lts-release-anouncement/ please :)
<flocculant> ogra_: nice ... at least it's KB/s one day last week for some reason I was pushed to get more than B/s ...
<ogra_> ppisati, FYI, dragon and pi2 kernels are good on snappy
<ogra_> flocculant, wow, thats bitter
<xnox> yofel, there is utf-8 things in your url for me.
<xnox> yofel, can you paste it again?
<ogra_> i usually get a few M, but it is release day :)
<flocculant> :)
<yofel> meh
<yofel> xnox: https://kubuntu.org/news/kubuntu-16-04-lts-release-anouncement
<Laney> ââ
<Phuket> whats the diff between this channel and ubuntu-release-party
<Phuket> fewer beverages?
<ppisati> ogra_: \o/
<balloons> if you have to ask, you belong in ubuntu-release-party
<balloons> :-)
<Phuket> well they said join this one so i had to ask.
<leftyfb> they shouldn't have said that
<hggdh> Phuket: who is "they"?
<teward> hggdh: i'll fill you in off channel
<hggdh> k
<pitti> ah, that "ubuntu-distro-info: Distribution data outdated." time again
<infinity> Yeah, I've already told mine that Xenial releases a week from now. :P
<Mez> infinity: your what ? (I just joined and irclogs isn't up to date yet!)
<xnox> apw, https://launchpadlibrarian.net/254865980/buildlog_ubuntu-xenial-ppc64el.p7zip_9.20.1~dfsg.1-5_BUILDING.txt.gz
<pitti> davmor2, infinity: a bit sad to realize that the ubiquity wifi bug can be fixed with literally flipping one bit..
<davmor2> pitti: possibly not mine bug though right unless you and cyphermox had a conversation I knew nothing about :)
<cyphermox> nah, just the panels stuff
<davmor2> pitti: see I find the interesting bugs ;)
<cyphermox> davmor2 means bug 1572956
<ubot5`> bug 1572956 in network-manager (Ubuntu) "Oem install end user has no wifi" [Undecided,New] https://launchpad.net/bugs/1572956
<pitti> yeah, I know
<cyphermox> (which I'm working on now)
<pitti> this wasn't really meant to start a serious conversation
<cyphermox> ok
<cjwatson> Getting images onto the CDN is taking somewhat longer than expected, but we're getting there.
<doko> is the release notes page now frozen?
<rbasak> Not for me.
<rbasak> I did have issues with it appearing immutable a few times over the last day or two though.
<doko> ahh, works on reload
<cjwatson> moin behaves a bit dodgily sometimes
 * nacc noticed issues primarily with the login service -- it would show me as not logged in at first, but on refresh it would show me was logged in
<rbasak> Sometimes I "log in" and it immediately things I'm not.
<rbasak> nacc: snap :)
<nacc> rbasak: :)
<rbasak> Also, thinks. My fingers seem to prefer thing.
<doko> barry, renamed the Python section from Python 3.5 to Python 3. do we know of more images without Python2 installed?
<barry> doko: yes, it should be off of cloud and touch, but it's not actually off of desktop because of samba :(
<doko> ouch, so we didn't change that ...
<barry> doko: desktop team overruled me
<doko> no comment
<doko> and server has openstack and 2 ... ok, so I'll change that to cloud and touch
<barry> doko: i thought we did remove it from server
<barry> i guess it came back :(
<doko> smoser, is python2 on the server images?
<smoser> doko, no. http://paste.ubuntu.com/15967494/
<barry> sweet
<doko> ok, re-adding
 * willcooke has a UOS session planned for SMB Py2 etc etc 
<infinity> wxl: So... I see no ppc testing for you guys.  Did you not want to release those?
<Laney> wxl: please to mark as ready?
<Laney> and, no ppc testing?
<teward> flexiondotorg: you pinged?
<teward> (elsewhere)
<flexiondotorg> teward, Laney and infinity are asking about PPC and marking images ready.
<teward> AFAIK that's wxl's territory
<teward> I've never touched the PPC stuff for any release
<teward> or any variant therein
<teward> sorry!
<flexiondotorg> OK, just know you're active in Lubuntu.
<Odd_Bloke> infinity: I assume we are go on cloud images?
<infinity> Odd_Bloke: Go for it!
<Odd_Bloke> *pushes buttons*
<Odd_Bloke> *pulls levers*
<Odd_Bloke> *looks busy*
<Laney> you sysadmin you
<teward> flexiondotorg: indeed, moreso because phillw and wxl poke me with alternate image thingies, and that issue on the 15.10 RPi images I discovered, but other than that, not as much with testing :P
 * teward returns to lurk mode
<phillw> ppc has been teted for lubuntu.. just still trying to get the tester to use the tracker!!!
<phillw> *tested
<Laney> phillw: Mmmkay, I'll mark it as ready then
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Xenial 16.04 | Archive: closed (SRUs pls) | Xenial Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<knome> hooray
<phillw> Laney: thanks
<teward> yay, now I can bust my head against nginx from Debian >.<
<infinity> @pilot out
<infinity> DERP!
<stgraber> infinity: enjoy the drinks! :)
<olli|> hooray
<olli|> congrats guys
<teward> infinity: i think you need this... *hands infinity some drinks* ... and then sleep :)
<teward> thanks to all thougH!
<Odd_Bloke> infinity: \o/
 * olli| wonders what his tap with the release-team is this cycle
<Laney> EPARSE
<Odd_Bloke> s/tap/tab/ ?
<olli|> tab
<olli|> this was in reference to "We accept payment in cash, check or beerta" and some ... discussions this week
<davmor2> olli|: don't worry about the release-team tab, wait till you get QA's
<pitti> congrats everyone!
<jcastro> nice work everyone, congratulations!
 * pitti goes to grab some ice cream for celebrations :)
<flexiondotorg> infinity, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> popey, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> cjwatson, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> dholbach, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> didrocks, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> Laney, Thank you for everything you've done for Ubuntu MATE!
<tgm4883> Who has access to the release notes wiki?
<flexiondotorg> sil2100, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> Trevinho, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> pitti, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> cyphermox, Thank you for everything you've done for Ubuntu MATE!
<popey> are you drunk?
<popey> :)
<flexiondotorg> mhall119, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> ogra_, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> seb128, Thank you for everything you've done for Ubuntu MATE!
<flexiondotorg> bregma, Thank you for everything you've done for Ubuntu MATE!
<cyphermox> flexiondotorg: you're not going to do through all the uploaders are you?
<flexiondotorg> Mirv, Thank you for everything you've done for Ubuntu MATE!
<barry> so, cjwatson, when does yakkity yak open?
<flexiondotorg> willcooke, Thank you for everything you've done for Ubuntu MATE!
 * rbasak hands flexiondotorg a compression algorithm :)
<tgm4883> willcooke: xnox can one of you add http://www.mythbuntu.org/home/news/mythbuntu1604released to the release notes?
<teward> lol rbasak
<flexiondotorg> https://ubuntu-mate.org/blog/ubuntu-mate-xenial-final-release/
<popey> heh
<ogra_> flexiondotorg, dude ! thank *you* for doing it ... we're all just little gears in a machine you drive ;)
<\9> rbasak: <flexiondotorg> \x1f\x8b\x08\x00\xfe\x00\x19W\x02\xff\xcbO/J\x8c\xd7Q\x08\xc9H\xcc\xcbV\xa8\xcc/UH\xcb/RH-K-\xaa,\xc9\xc8\xccK\x07\t\xa9\x97\xa5*\xa4\xe4\xe7\xa5\x82\xa5B\x93J\xf3JJ\x15|\x1dC\\\x15\x018\xb8b4<\x00\x00\x00
<\9> :v
<Mirv> flexiondotorg: you're welcome! :)
<Mirv> flexiondotorg: +1 on ogra's comment :)
<\9> also, congratulations everyone
<cholcombe> \o/
<cyphermox> \9, can we call you "tab"? ;)
<\9> heh
<Dataforce> Does http://changelogs.ubuntu.com/meta-release-lts update later then? :)
<knome> some of us are little rocks on the gears you drive too
<knome> :Ã
<ogra_> haha
<ogra_> Dataforce, lts only gets switched at the .1 release
<Dataforce> ogra_: I see - what about http://changelogs.ubuntu.com/meta-release?
<nearffxx_> https://kubuntu.org/news/%EF%BF%BCkubuntu-16-04-lts-release-anouncement/
<Odd_Bloke> Unless you're looking at `distro-info --lts`, then xenial has been the LTS since midnight. :p
<davmor2> popey: flexiondotorg is only tiddly he starts with IIIIIIi LLLLLLuvv you when he gets drunk
<yofel> thanks to the release team and everyone else for all the work over the last half year :)
<rbasak> yofel, sgclark: thank you for your patience and work with the MySQL switch. Sorry again that it landed so late.
<rbasak> And jamespage too.
<sgclark> np
<jamespage> ;)
<rbasak> I should have put out a call for testing when it landed in xenial-proposed really. It was sat there longer than we expected :-/
<tgm4883> flexiondotorg: Do you have the raspberrypi-dev package on a PPA for 16.04 somewhere? I had been using yours for wily stuff, but I can't find a xenial version
<phillw> tgm4883: there is an RC for both MATE and Lubuntu at http://phillw.net/isos/pi2/
<tgm4883> phillw: actually, just found what I was looking for. raspberrypi-firmware
<phillw> kk
<tgm4883> I need it in my building PPA for some openmax support
<wxl> ok ok i'm here
<wxl> infinity: i think we're confident enough to release ppc at this point, at least if flexiondotorg is willing to release mate :). i'll mark it ready in one sec.
<Trevinho> flexiondotorg: no worries, it was easy!you guys did the most. âºï¸
<Trevinho> Trevinho: thank you for the contributions
<davmor2> Congratulations all
<wxl> oh
<wxl> heh
<wxl> nevermind already done XD
<bladernr> Hey, I just wanted to verfiy something... the 16.04 images on releases.ubuntu.com are dated yesterday.  Are those the official GA ISOs or are there newer spins coming to the web shortly?
<bladernr> the torrent and zsync files are all dated today, but the ISOs themselves are dated 4/20
<bladernr> ummm anyone?
<bladernr> stgraber: infinity cjwatson ?
<Odd_Bloke> bladernr: I suspect they are all in a pub by now. :)
<bladernr> Odd_Bloke: yeah, probably :/ but I need the official GA bits for test work, so we're gated on that question. heh...
<Odd_Bloke> bladernr: I don't have the answer for you, I'm afraid.
<bladernr> Odd_Bloke: no worries
<Odd_Bloke> slangasek: You, presumably, aren't drinking yet; do you have an answer?
<slangasek> Odd_Bloke: not drinking yet? you wound me, sir
<nacc> heh
<slangasek> Odd_Bloke: I am deep in scrollback at the moment, one second
<rcj> bladernr, if you use a torrent link and check the result against the SHA256SUMS[.gpg] then you should be fine
<willcooke> tgm4883, done
<rcj> just a guess
<slangasek> cjwatson: sentinella> but if it's in sync and the current version will never work without a change, we can drop it and resync it later and keep -proposed nice and clean... :)
<slangasek> Laney, pitti: so what did happen with the xorg-lts-transitional stuff?  I see there were changes made to the seeds and I saw emails about c-m flapping, but this was all clean yesterday when I was done with it
<slangasek> infinity1: raspberrypi2-firmware was renamed to linux-firmware-raspi2? wat?  the contents weren't linux firmware...
<Odd_Bloke> slangasek: Heh, you weren't kidding about being deep in scrollback.
<slangasek> bladernr: so what's the concern with torrent/zsync files?  Just the timestamps on them?
<slangasek> bladernr: right, the torrent files are only generated when the images are published.  The images are built before they're tested for release, and the testing takes a while.  timestamp differences are expected
<slangasek> Odd_Bloke: hurray I survived
<slangasek> infinity1, cjwatson, Laney, pitti, apw, xnox: congrats on the lovely release
<LocutusOfBorg> <3
<DiamondSword> http://releases.ubuntu.com/xenial/ << here the desktop is last modified date is 20th of April. it says 16.04 is out on the front page. should I download the iso which it is stable(?) or download the torrent file becasue its last modified date is 21st ?
<LocutusOfBorg> [   ] ubuntu-16.04-desktop-amd64.metalink    21-Apr-2016 10:00   43K  Ubuntu 16.04 Final Beta (Xenial Xerus)
<LocutusOfBorg> please s/Beta//
<DiamondSword> beta? isn't this stable version?
<slangasek> DiamondSword: I literally just answered that question.  The timestamps are the date the image was created, which happens *before* the testing, which is not instantaneous.  Timestamp differences are expected.
<slangasek> LocutusOfBorg: where do you see that?
<DiamondSword> slangasek, so the iso is fine you say?
<slangasek> DiamondSword: yes.
<DiamondSword> thank you for the 16.04 :)
<DiamondSword> congratz!
<DiamondSword> I like the "X"
<LocutusOfBorg> http://releases.ubuntu.com/16.04/
<LocutusOfBorg> slangasek, ^^^ :)
<slangasek> LocutusOfBorg: thanks.  Fixed, dunno how long the mirror push will take
<LocutusOfBorg> thanks
<Laney> Hey slangasek
<Laney> There were some c-m problems on britney
<slangasek> Laney: ah, ok
<Laney> and cjwatson said that the "!" stuff doesn't work and don't ever use it
<slangasek> hah
<Laney> so I expanded the problem out into the positive sense
<Laney> and then good things were good
<slangasek> except it totally did work for c-m
<slangasek> and it was used in trusty
<slangasek> it was only p-m that didn't like it :)
<LocutusOfBorg> and now I start the question for libpng16 transition, do you have any ETA for the next archive opening? no asking about the auto import, but somewhen before it :)
<Laney> Bottom line was that things were in main that shouldn't be in main
<Laney> and now it is time for pub
<Laney> tata
<slangasek> Laney: enjoy :)
<Laney> :)
<slangasek> Laney: btw (async), do you know why juju-core didn't make it through unapproved automatically (and from there into release)? did the bot stop working?
<cjwatson> bladernr: images are always dated a bit old, they have to be tested after they're built.
<cjwatson> oh yeah, I see that above.
<bladernr> cjwatson: ok, I just needed to verify that the 4/20 dated ones were GA and not just a case of "haven't synced yet"
<bladernr> cjwatson: thanks
<slangasek> bladernr: they don't get published to releases.ubuntu.com until they're golden
<bladernr> slangasek: ack, just crossing the t's and dotting the lower-case j's
<bladernr> thanks both of you
<Kamilion> wow, people are really worried about an off-by-one date 'error'... That makes me happy (that people are paying attention)
<Basstard`> It was actually meant to be released yesterday but.. 4/20 happened.
<Kamilion> yeah, I know, I was here all day instead of Golden Gate Park.
<DiamondSword> you should put a downloads counter on the main page, people are very excited about this release :)
<tjaalton> are relnotes for "official" features only, or whatever someone with the community hat feels is worth mentioning?-)
<tjaalton> and by official I mean supported
<tjaalton> ..by C.
<slangasek> tjaalton: if it's a feature present in the distro, and you think it's worth mentioning, then we should at least consider it for the release notes... doesn't have to be just features that Canonical thought to trumpet :)
<tjaalton> slangasek: ok, well I'm pondering if freeipa 4.3.1 should be mentioned or if I'll just blog about it. supports replication too for the first time on debian/ubuntu
<slangasek> tjaalton: ah, a vanity release note ;-)  I think freeipa is awesome and important to certain users, but it's in universe/unseeded and one update among many
<slangasek> but a blog sounds perfect to me
<tjaalton> yeah, and a ml post to freeipa-users@, that'll do
<Pici> sorry to bug, but we're getting a lot of users saying that they're not being prompted to upgrade.  http://changelogs.ubuntu.com/meta-release looks like it doesn't advertize xenial.. is this just a mirror/cdn issue or??
<slangasek> bdmurray: ^^ is that something you have control over?
<Odd_Bloke> I thought we didn't prompt to upgrade until .1?
<slangasek> Odd_Bloke: we don't prompt LTS users to upgrade until .1.  wily users should get the prompt
<Odd_Bloke> Oh, right.
<tgm4883> Odd_Bloke: I think we do for 15.10 -> 16.04
<nacc> Odd_Bloke: that would be meta-release-lts
<Odd_Bloke> That makes a lot of sense now I engage brain. ^_^
<slangasek> Odd_Bloke, rcj, gaughen: I see the release notes call https://cloud-images.ubuntu.com/releases/16.04/release/ "Ubuntu Cloud Server".  Is that how you want them labelled?
<slangasek> GarÃ§on de nuages Ubuntu
<Odd_Bloke> I would prefer "Best Ubuntu".
<Odd_Bloke> "Ubuntu Cloud Server" does sound weird though.
<Odd_Bloke> gaughen: Probably one for you/Udi: ^
<slangasek> suggestions:
<slangasek> Ubuntu Servers on Ice
<slangasek> Ubuntu in the Sky With Diamonds
<slangasek> Ubuntu Cloud, Purple Rain Commemorative Edition
<gaughen> can't we just say Ubuntu Cloud?
<Odd_Bloke> Do You Want To Build A(n Ubuntu) Server
<gaughen> although I do like the commemorative edition
<gaughen> thanks for that Odd_Bloke, now I have that frozen song stuck in my head AGAIN
<Odd_Bloke> Ubuntu Cloud: This Time It's Cirrus
<gaughen> sigh
<rcj> We're clearly marketing wizards.  "Ubuntu cloud images"?  Seems to fit nicely with cloud-images.ubuntu.com.
<pitti> clearly the hardest part of the release :)
<rcj> pitti, oh we're still releasing cloud images
<balloons> naming is everything
<Kamilion> now if we could only get some licensing wizards to tell me how many trademarks I'm supposed to be removing
<Pici> Can anyone besides bdmurray take a look at the meta-release thing?
<bdmurray> Pici: I'll do it shortly
<Pici> bdmurray: thanks :)
<slangasek> gaughen: yes, we can certainly say that.  Done!
<slangasek> gaughen: 'Ubuntu Cloudy with a chance of eatballs'
<slangasek> Meatballs
<slangasek> that was the final answer, right?
 * balloons sings 'sunshine, lollipops and rainbows, everything that's wonderful is sure to come your way . . .' âª âª
<bdmurray> Pici: should be set, feel free to double check
<Pici> bdmurray: already got confirmation from impatient users in #ubuntu  thanks again :)
<daniele_> Hi guys, yesterday I just installed the daily build of ubuntu, and now I typed "apt-get upgrade" it only installed tzdata
<daniele_> I'm on the final version now?
<daniele_> is there any difference?
<Kamilion> I only got some cups-filters and an upgrade to nginx-common & nginx-extras
<Kamilion> oh, yeah, I got the tzdata update as well, almost missed that
<daniele_> Kamilion: thanks
<pmatulis> when does cloud-images.u.c get updated?
<Kamilion> daniele_: I don't see anything else really, http://puu.sh/oqVGc/569d0a7af6.jpg
<Kamilion> daniele_: don't forget to apt autoremove to clean up any old kernels, but I had this installed for a while, if yours was from yesterday you probably don't have any old ones to remove :)
<Kamilion> pmatulis: there was some traffic here about an hour ago of people talking about pushing the cloud images
<Kamilion> pmatulis: I assume they take some amount of time to publish and sync
<pmatulis> Kamilion: k
<Laney> slangasek: At a guess, it was after the script was turned off (which was about the same time we put a $world block on)
<slangasek> Laney: k
<slangasek> pitti: fyi, bug #1573240 reported already against the initscripts SRU.  I did test a wily->xenial upgrade with the new initscripts enabled, so I don't know why that didn't pick this up if it's really a breaks/pre-deps loop
<ubot5`> bug 1573240 in sysvinit (Ubuntu) "package initscripts 2.88dsf-59.2ubuntu2.1 failed to install/upgrade: pre-dependency problem - not installing initscripts" [Critical,New] https://launchpad.net/bugs/1573240
<infinity1> slangasek: The bot was disabled and the britney hint changed to "block all" to prevent anything happening as we neared final release.
<infinity1> slangasek: That said, despite release announcements, we've still not closed the archive, nor have we opened a new one, so if there's a valid argument for juju-core squeezing in, go for it.
<slangasek> infinity1: right; that seemed to happen somewhat early, the juju-core upload was yesterday?
<infinity1> slangasek: Eh?  I see one 4 hours ago.
<infinity1> slangasek: Or was there one well before that?
<slangasek> infinity1: that's the /reupload/ after Laney rejected my earlier one that got stuck yesterday without me noticing
<slangasek> the reupload for SRU, with bug ref
<slangasek> anyway, I'm not going to try to sneak it into the release pocket today, it can go via SRU
<slangasek> the difference between beta4 and beta5 being in the release pocket is negligible, neither is 2.0final
<Laney> Ah, an earlier one, sorry
<Laney> Then if it wasn't held because of seeding, it'll have been because it's in a packageset
<infinity1> slangasek: Neither is final, though the control file changes seem important?  Or was juju2 not a thing long enough for it to matter?
<slangasek> infinity1: it was only in a ppa
<slangasek> Laney: packageset> that seems buggy behavior by the bot, then?
<slangasek> anyway here's what queuebot actually said
<slangasek> Unapproved: juju-core (xenial-proposed/main) [2.0~beta4-0ubuntu2 => 2.0~beta5-0ubuntu1] (ubuntu-server)
<slangasek> so yeah, it is seeded, duh - just not on images
<slangasek> my mistake
<infinity1> slangasek: That upload has added git vomit too.  Yay.
<infinity1> I really wish -i -I were default for dpkg-buildpackage.
<slangasek> infinity1: it's in the upstream tarball so wouldn't change anything
<infinity1> Oh.
<infinity1> Gross.
<slangasek> ;)
<Laney> make distcheck, people
<Laney> slangasek: I think that *is* "(packagesets)" FWIW
<slangasek> hohum
<Laney> It's intentional, haven't thought about whether it's correct though
<infinity> It's intentional and correct.
<infinity> Packages in packagesets shouldn't sail through during a freeze period without review.
<Laney> I suppose the idea is that somebody actively cares about this thing and so it should be up for extra scrutiny
<infinity> (There is a whitelist for some that have been granted sailing privileges, like some touch stuff)
<slangasek> packageset just means it's been marked as having a particular uploader acl; it doesn't mean it's part of an image
<slangasek> or product, or whatever
<infinity> No, true.  It should probably actually match more closely what LP uses for supported fields.
<infinity> Which juju-core wouldn't be caught in because it's in universe.
<infinity> Though it shouldn't be.
<infinity> Cause this whole "we support it but the uploaders don't want to admit to it" thing is silly.
<infinity> I'll twiddle it to match in that direction next time.  I thikn that makes more sense.
<infinity> Since "supported" implies "we need to review that your upload is sane because we're agreeing to fix it after release if it's not".
<infinity> slangasek: Sound reasonable to you?
<slangasek> infinity: nah, juju-core (source) is in main, so it's right in this case that it /was/ caught, via seeds if not packagesets
<infinity> (That said, projects like juju should stop skipping the queue and get in server supported)
<infinity> Oh, I'm looking at "juju-core".
<infinity> The binary.
<slangasek> the overlooked non-autoapproval was my fault and nothing to do with the bot config.  But I do agree with your proposed bot change
<infinity> So, yes.   juju-2.0 is 5y supported, so absolutely should be stopped.
<infinity> Bot change on the todo anyway, I agree that random packageset created for a universe PPU is none of my business to stop uploads for.
<infinity> So, we've had a few clean publisher runs in a row.
<infinity> If that juju's an SRU, I'm closing xenial.
<infinity> And there it goes.
<slangasek> \o/
<doko> is there an expected release date for 16.04.1?
<doko> slangasek, infinity: ^^^
<slangasek> doko: estimated 3 months after .0, so "late July" (as I was corrected yesterday)
<slangasek> I don't know if infinity has put a target date on a calendar yet?
<doko> ta
#ubuntu-release 2016-04-22
<wxl> we going to wait until we got a name for y cycle before turning dailies on, i'm assuming
<wxl> ?
<slangasek> yes
<wxl> ko thx
<bjf> slangasek: we have a name and it is yakkity yak
<bjf> *yakkety yak*
<slangasek> my money was on yippee yappee yahooey
<doko> you lost your money, it always was tuples not triples
<infinity> slangasek: I've got targets in LP for 14.04.5 and 16.04.1, will mirror same to the release schedule(s) tomorrow.
<infinity> doko: ^
<infinity> Also, hahahahahahaha.  Yakkity (though misspelled?) yak won!
<slangasek> are we sure he really meant it? :)
<wxl> wait
<infinity> Hard to say.
<wxl> yakkity yak, really?
<wxl> oh please say it's true!
<slangasek> http://www.markshuttleworth.com/archives/1496
<wxl> oh.
<wxl> yakkety.
<wxl> sorry, what he says, goes. :)
<wxl> we're going to get REAAAAALY sick of typing yakkety.
<teward> wxl: i haven't typed it yet, and I am *already* sick of it >.<
<wxl> hahahahhaah
<wxl> well time to turn dailies on then XD
<bjf> infinity, which spelling are you going with?
<infinity> bjf: Well, it's either "Yakety" if the reference is "Yakety Sax" (the song), or "Yakkity" if the reference is "Yakkity Yak" (the TV show), but yakkety is wrong. ;)
<wxl> well, maybe that's the point
<wxl> it's wartier XD
 * tsimonq2 agrees with wxl, it's gonna be annoying after a while to type XD
<wxl> https://wiki.ubuntu.com/YakketyYak
<Kamilion> ?
 * tsimonq2 creates
<Kamilion> shouldn't that be yakkity?
<wxl> hahahah
<tsimonq2> I did Xenial so it's my turn again XD
<tsimonq2> (seriously, look at the XenialXerus page)
<wxl> not according to sabdfl
<Kamilion> Wow, we even get not invented here syndrome from release names now? <3
<tsimonq2> no I mean the wiki page
<tsimonq2> XenialXerus (last edited 2015-10-22 17:55:18 by tsimonq2)
<DalekSec> Kamilion: http://www.markshuttleworth.com/archives/1496
<tsimonq2> infinity: look good? https://wiki.ubuntu.com/YakketyYak
<wxl> tsimonq2: don't forget https://wiki.ubuntu.com/ReleaseSchedule
 * tsimonq2 gets that done
<wxl> aw someone should fix up https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS for into the future
<Kamilion> DalekSec: https://en.wikipedia.org/wiki/Yakkity_Yak
<DalekSec> Good for it?
<Kamilion> unless it's referring to the song? https://en.wikipedia.org/wiki/Yakety_Yak
<wxl> he said yakkety
<wxl> it is what it is :)
<Kamilion> either way, it's ke or i
<Kamilion> err
<Kamilion> ki or e
<Kamilion> not ke
<wxl> either way it SHOULD be
<wxl> but mark IS the dictator for life XD
<Kamilion> hence the "not invented here syndrome" joke
<wxl> oh i got it
<Kamilion> can't use wayland, gotta write mir
<Kamilion> ETC
<infinity> Confirmed with sabdfl that it's yakkety, as spelled in the blog post.
<wxl> hahahahhaah
<infinity> https://launchpad.net/ubuntu/yakkety
<Kamilion> ubuntu has a history of reinvention of the wheel, sort of
<wxl> hahahah
 * Kamilion points fingers at upstart
<Kamilion> <joke> it can't even launch apache! </joke>
<wxl> um, there's no wheel. that's unix, man. :)
 * Kamilion lmfao
<Kamilion> next you'll be telling me /usr is more than an RK-05 disk pack's worth of bytes
<wxl> XD
<Kamilion> In my day, we hand assembled binaries uphill in the snow both ways!
<Kamilion> with a needle and a very steady hand
<Kamilion> Alright, i'm done with the comedian act; back to seriousness
<wxl> someone needs to add the point release schedule to https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule at some point
<tsimonq2> infinity: mind acking https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule as well>
<wxl> we should expect the first around july, hm?
<infinity> tsimonq2: Those dates all need to be Thursdays.
<infinity> wxl: First point release is scheduled in LP for the 21st of July, I'll add it to the schedule soon.
<wxl> thx infinity
<tsimonq2> infinity: ok adjusting
 * tsimonq2 copied from Wily's
<infinity> tsimonq2: wily's should be a good base indeed, just needs minor shuffling.
<tsimonq2> infinity: also ack https://wiki.ubuntu.com/ReleaseSchedule while you are at it if you could :)
<infinity> slangasek: Do we have UOS dates?
<tsimonq2> May 3-5 I thought...?
<infinity> Ahh, indeed, summit.ubuntu.com has the dates.
<slangasek> yah
<infinity> I must have missed the usual email thread about it.
<tsimonq2> infinity: FWIW we have an extra week in June subtracted from July...same amount of weeks but I'd thought I would mention it
<infinity> tsimonq2: Yup, just shuffle the alpha up a week to keep it at the end of the month.
<infinity> (And fix the colours)
<tsimonq2> *sigh* thank god nothing is September 1...
<tsimonq2> yep, covered :)
<tsimonq2> that also means first week in October gets bumped up to September
<infinity> Yep, s'all good.
<infinity> Calendars suck.
<infinity> Thanks for doing the draft.
<tsimonq2> np
<tsimonq2> https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule look good?
<tsimonq2> as a suggestion, maybe put Ubuntu 16.04 somewhere by April 21, 2016
<tsimonq2> oh lol I forgot, it's all 2015, fixing
<tsimonq2> there fixed
<infinity> Heh.  You didn't fix the suffixes. ;)
<infinity> 23th, 22th, etc. ;)
<tsimonq2> I didn't?
 * tsimonq2 looks
<infinity> And Alpha1 should move to Jun30.
<tsimonq2> oh jeez
<tsimonq2> alright
<infinity> Semptember 1rd is my favourite.
<infinity> 1rd, yo.
<tsimonq2> hahahahahahahah
<infinity> And UOS is Tue-Thu, not Mon-Thu.
<infinity> Otherwise, looks good.
<tsimonq2> fixed?
<tsimonq2> and do you think it's relevant to put the release of 16.04 by April 21?
<infinity> Nah.
<infinity> I think it's generally taken as a given that a release happened before the release schedule. :P
<tsimonq2> hey, the first time I read the release scedule, I was checking the dates going, "OK, what?!? who screwed up the schedule?!?" XD
<tsimonq2> *schedule
<tsimonq2> *shrug* but if you don't think it's needed I won't put it XD
<infinity> Current state looks good to me.  Thanks.
<infinity> Just need to add a big "DRAFT, DO NOT RELY ON THIS YET" to the top so we can send it out for comment and reject^Wconsider people's complaints.
<tsimonq2> hahahahahah
<tsimonq2> need me to do that?
<infinity> Nein.
<tsimonq2> alright
 * tsimonq2 assumes that's no
<infinity> It is. :)
<tsimonq2> :)
<tsimonq2>  /o\ long day, it's _finally_ over
<tsimonq2> but still, Yakkety?! /me wonders what it's referring to...
<infinity> Yaks, of course.
<tsimonq2> hahahahahahahahah
<tsimonq2> and I thought Xenial Xerus would be hard to spell/remember
<tsimonq2> :P
<infinity> You might be too young to really appreciate the yakety yak, yakety sax, yakkity yak references.
<infinity> But it's making some of us giggle. :)
<tsimonq2> yeah I have no idea what those are... :P
<DalekSec> infinity: Don't talk back!
<tsimonq2> ?
<tsimonq2> Â¯\_(ã)_/Â¯
<infinity> tsimonq2: https://www.youtube.com/watch?v=PtTC3pGBjs4 -- educate yoself.
<tsimonq2> hahahahah
<tsimonq2> infinity: has lsb_release been updated yet?
 * tsimonq2 uses the devel alias
<infinity> tsimonq2: The archive doesn't exist yet, so no.  Patience.
<infinity> This is not actually an instant process.
<tsimonq2> ohhh gotcha sorry :)
<LocutusOfBorg> hi, can I sync libpng*?
<infinity> LocutusOfBorg: Maybe.
<LocutusOfBorg> it will end up in unapproved... and in new because of the soname change
<LocutusOfBorg> so, lets sync and leave the decision to release team
<LocutusOfBorg> oops unapproved, because somebody sync'd it before already
<LocutusOfBorg> well, I opened LP: #1573415 for the old libpng-dev removal
<ubot5`> Launchpad bug 1573415 in libpng (Ubuntu) "please merge libpng from debian" [Undecided,New] https://launchpad.net/bugs/1573415
 * LocutusOfBorg thinks about a transition tracker
 * flocculant lols at yakketyyak
<infinity> Hrm.  Might have to walk to the office to update chroot tarballs.
<infinity> Seems like everyone in this hotel woke up at once and started surfing porn.
 * infinity grabs a quick shower before heading in to finish opening.
<LocutusOfBorg> LOL
<flocculant> morning infinity - now the madness is over - thanks to you all :)
<infinity> flocculant: It's never really over.  Now I get to open yakkety, and people get to fix all the bugs we found in the release so we can have a better point release, and and and...
<flocculant> infinity: :)
<flocculant> still laughing at yakkety yak :D
 * infinity -> Bluefin.
<infinity> doko: Did you have any pre-opening toolchain bits for 16.10, or shall we just roll into it once the checklist is done?
<ogra_> infinity, seems 15.04 is gone from http://releases.ubuntu.com/ .... there were snappy images in there that are still valid
<davmor2> ogra_: 15.04 was dropped 3 months into 15.10 this isn't a new thing ;)
<ogra_> ha ha
<davmor2> ogra_: no I'm serious
<ogra_> i think there are pages linking to them, the 15.04 snappy image are supported until the 16.04 snappy release ... which is some time in summer (june/july)
<ogra_> *images
<infinity> ogra_: I can copy the snappy ones back, gimme time.  I'm multitasking a bit.
<ogra_> no hurry
<xnox> i'm gonna have so many laughs about
<xnox> yakkety security
<xnox> and yakkety backports
<xnox> and yakkety updates
<Laney> yakports
<infinity> xnox: Oh joy, a new boost.
<infinity> xnox: Do we want that built before we open?
<infinity> xnox: (ie: is there a defaults bump too?)
<xnox> infinity, default bump in progress
<xnox> infinity, i also believe this boost1.60 will fail to migrate on s390x, but we shall see.
<infinity> xnox: Well, that's not ideal.
<infinity> xnox: Don't really want autosync all backed up on boost.
<xnox> infinity, well i'm trying to sort out if britney is lying in debian, or there really is something fishy about s390x in debian/rules
<xnox> infinity, in any case i will be fixing this in debian and uploading there and syncing over, e.g. today.
<xnox> cause yeah i do want to open with new boost.
<infinity> xnox: Kay.
<infinity> xnox: I'll accept it then, and you'd better fix it ASAFP if you break anything.
<xnox> ack.
<clivejo> xnox: when do the +1 archives usually get created?
<infinity> clivejo: A few hours ago.
<clivejo> oh that was fast
<doko> why do you accept new boost before we change the toolchain defaults?
<infinity> doko: I can kill the builds.  Do you have a new toolchain prepped?
<doko> sure, however yesterday I was told I shouldn't expect opening today ...
<infinity> doko: Boost builds killed.
<cjwatson> Yesterday we didn't have a name and you know what expectations are like there.
<infinity> doko: I asked earlier this morning if you had toolchain bits, I guess you slept in (like most of us should have done).
<infinity> doko: So, waiting on you before I build anything else.
<doko> ta
<Laney> infinity: https://paste.debian.net/440208/
<infinity> Laney: Ta.
<xnox> that boost will have dropped binaries, there are mistakes in debian/control that smr did
<infinity> xnox: Well, it's cancelled anyway, so fix it. :P
<infinity> doko: Patch gcc-linaro.diff does not apply (enforce with -f)
<doko> yep
<xnox> new boost will be upload into debian, and then i guess we will want to wait for armhf to finish building gcc, before you accept that one.
<infinity> Yep.
<infinity> I'll delete the current one so no one's tempted to retry it.
<xnox> and test building debian build now, so off to buy neoprene sand socks in the mean time.
<xnox> infinity, sounds good.
<infinity> Done.
<doko> xnox, is this boost ready for GCC 6?
<Laney> xnox: https://www.youtube.com/watch?v=A6hNXUwOHKQ these guys aren't wearing socks
<doko> xnox, also please consider building icu from experimental before doing the new boost
<Laney> ur doin it rong
<ginggs> xnox, are you want to drop context/coroutine from arm64, i understood it was available there from boost1.59
<ginggs> are you sure*
<infinity> pitti: When can we have Yodeling Yam autopkgtests?
 * apw shouts at network-manager ... this new version is utter pants
<pitti> infinity: I like yodelling a lot better than yakkety!
<infinity> pitti: Too late.
<pitti> infinity: queues exist now, so britney can issue test requests
<pitti> they aren't served yet, still need to build containers and yakkety cloud images
<infinity> pitti: May have to reissue the batch that vim caused?
<pitti> will do that in a bit, need to run out for some errands
<infinity> Not sure where they went...
<infinity> If anywhere. :)
<pitti> into the void
<pitti> yes, I'll retry all the bits on excuses.html
<infinity> pitti: I assume "yakkety cloud images" are a xenial custom hack job, not you blocking on CPC, right?
<pitti> infinity: correct
<infinity> Check.
<doko> coq-float succeeded to build? strange
<infinity> Yeah.  Probably means we should have done one last give-back a week before release.  Oh well.
<doko> I did
<infinity> Two days before release? :)
<infinity> Pretty sure that changing the strings in os-release didn't fix it.
<infinity> I would hope...
<mapreri> there was this idea of importing libpng before everything, to avoid doing hundreds of rebuilds later, is that going to happen? :)
<infinity> mapreri: After the toolchain, but before the world, yes.
<apw> it is in the queue
<mapreri> cool
<xnox> ginggs, available empty package is not useful at all.
<ginggs> xnox: thanks for checking. yeah, empty package worse is than no package. i think they can be built for arm64, but maybe there's still a problem with the packaging
<Odd_Bloke> pitti: You do _eventually_ use our images though, right?
<Odd_Bloke> pitti: (I'm all for you not blocking on us for now, it'll be a few days before we have the infrastructure for yakkety in place :)
<infinity> Odd_Bloke: Well, he's using your images even in the hacked case. :P
<infinity> Odd_Bloke: Also, slaaaacker!  I'll have Ubuntu (and flavour) ISOs building in a few minutes.
<infinity> *cough*
<Odd_Bloke> infinity: ^_^
<Odd_Bloke> I didn't think we had packages in yakkety yet?  Or do we copy the xenial packages over and then all the toolchain things land etc.?
<infinity> Odd_Bloke: Yes, that.
<infinity> Odd_Bloke: yakkety is a fully-functional distro.
<infinity> Odd_Bloke: I'm running it.
<xnox> hm
<xnox> ginggs, maybe.
<xnox> i shall try that.
<Odd_Bloke> infinity: So hipster.
<infinity> Odd_Bloke: So hip I can't see over my own pelvis.
<Odd_Bloke> "chroot: failed to run command '/usr/bin/env': No such file or directory" <-- that's a livefs build error I've seen before, but I can't remember what causes it
<LocutusOfBorg> :( no libpng accepted makes me sad
 * LocutusOfBorg read about the archive opening on irclogs.u.c
<Odd_Bloke> Though I feel like I've normally seen in on s390x, now I think about it.
<mapreri> LocutusOfBorg: it's not open yet?
<infinity> LocutusOfBorg: Still building the initial toolchain.
<Odd_Bloke> infinity: Any ideas about https://launchpadlibrarian.net/255173456/buildlog_ubuntu_yakkety_amd64_cpc-development_BUILDING.txt.gz ?
<Odd_Bloke> infinity: ("Try waiting" is an acceptable answer :)
<infinity> Odd_Bloke: You need the debootstrap in proposed.
<infinity> Odd_Bloke: If you have a PPA you use with your builds, just copy it over.  Or build with PROPOSED=1.  Or wait a tiny bit.
<infinity> Oh, a bit more than a tiny bit, since its migration to the release pocket is blocked on pitti's autopkgtests.
<infinity> So, you'd be best off copying it.
<LocutusOfBorg> infinity, not a problem, but the issue is: I would like to have something more than just a libpng imported
<infinity> LocutusOfBorg: Well, you didn't ask for anything else. :P
<LocutusOfBorg> oh well, gcc-5 failed to upload
<LocutusOfBorg> https://launchpadlibrarian.net/255171857/upload_9610916_log.txt
<LocutusOfBorg> infinity, give me one sec
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libpng/+bug/1524328
<ubot5`> Launchpad bug 1524328 in libpng (Ubuntu) "libpng 1.6 transition" [High,Confirmed]
<infinity> doko: gcc-5 still builds gcc-6 binaries?
<LocutusOfBorg> message #12
<infinity> (libgcc, etc)
<doko> fixed
<xnox> Odd_Bloke, i'd love to spin up yakkety cloud-images in my ppa =)
<infinity> LocutusOfBorg: Seems the only absolute necessity there are both the libpng sources happening before the world opens.
<LocutusOfBorg> infinity, and gdk-pixbuf rebuilds maybe
<LocutusOfBorg> but yes, we can retry it until it builds
<LocutusOfBorg> the problem is gdk-pixbuf embedding somewhere a libpng broken pkgconfig, so the other tools will fail in configure
<Odd_Bloke> xnox: Hm?
 * apw will sort out debootstrap in the stables ...
<pitti> Odd_Bloke: yes, as soon as there are daily yakkety images, I'll build the adt images from them instead of from a dist-upgraded xenial one; same appraoch as for wily->xenial
<xnox> Odd_Bloke, because i can give experimental yakkety images to try out to others =)
<pitti> infinity: open> do you want a debhelper merge? that's traditionally on my list, can do after dealing with the yak images
<Odd_Bloke> xnox: Well, we can do that too... :p
<infinity> pitti: If you're in the mood.
<LocutusOfBorg> thanks for fixing boost1.60 delta <3
<LocutusOfBorg> aka thanks for archive reorg
<LocutusOfBorg> :D
<Odd_Bloke> infinity: Am I missing an easy way to copy archive/-proposed packages in to a PPA?  Should I just backportpackage it?
<cjwatson> copy-package
<cjwatson> --from ubuntu --from-suite whatever --to ppa:OWNER/ubuntu/NAME --to-suite whatever ...
<infinity> Odd_Bloke: copy-package --from=ubuntu --from-suite=yakkety-proposed --to=ppa:username/ubuntu/ppaname --to-suite=yakkety -b debootstrap
<pitti> cloudy autopkgtest (i386, amd64, ppc64el) are now yakified
<pitti> building lxc containers failed during debootstrap (armhf, s390x)
<willcooke> infinity, Should the vagrant images have a xenial options too?  http://cloud-images.ubuntu.com/vagrant/
<Odd_Bloke> willcooke: Nope, those have moved in alongside the other image files.
<infinity> ogra_: Your 15.04 snappy images should be back.  Sorry about that.
<Odd_Bloke> willcooke: e.g. http://cloud-images.ubuntu.com/xenial/20160420.3/xenial-server-cloudimg-amd64-vagrant.box
<ogra_> infinity, i must admit i dont care about them at all ... thibaut and didrocks do though :)
 * ogra_ is all 16.04 :)
<infinity> ogra_: Well, tell whomever cares that they're resurrected. :P
<ogra_> yep, doing so
<willcooke> Odd_Bloke, thanks.  I've been told that they're "not working" - are you happy everything is as it should be?
<Odd_Bloke> willcooke: I did a test yesterday that seemed fine, so if you could ask your source to file a bug at https://bugs.launchpad.net/cloud-images/+filebug ? :)
<ogra_> infinity, hmm, are we talking about http://releases.ubuntu.com/ ? i dont see 15.04
<willcooke> Odd_Bloke, ta
<ogra_> (sync mirro still running ? )
<infinity> ogra_: They were never on releases, were they?  I thought they were on cdimage.
<infinity> ogra_: Or am I mistaken?
<ogra_> they were on http://releases.ubuntu.com/15.04/
<infinity> ogra_: Oh, huh.  Someone had put them on releases.
<infinity> ogra_: Moving again. :P
<ogra_> http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz was the amd64 one
<ogra_> yeah, crazy :)
<ogra_> i would prefer to kleep them in cdimage.u.c/ubuntu-snappy/ for the future
<ogra_> we'll see if i'll have success with that once we have actual 16.04 releases :)
<infinity> ogra_: http://releases.ubuntu.com/15.04/
<ogra_> perfetto !
<willcooke> Odd_Bloke, I think this is it:  https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1573058
<ubot5`> Launchpad bug 1573058 in livecd-rootfs (Ubuntu) "Ubuntu 16.04 current not booting in Vagrant (gurumeditation)" [Undecided,Confirmed]
<willcooke> Odd_Bloke, and this is who my source is:  https://twitter.com/therealmarv/status/723485477328850944 ;)
<Odd_Bloke> willcooke: OK, in a meeting ATM so will dig in a few minutes. :)
<willcooke> Odd_Bloke, nw, thanks
<Odd_Bloke> Step 1) Actually manage to download something from our DC
<ogra_> infinity, hmm, if you want to save diskspace you might want to check why all images are duplicated on http://releases.ubuntu.com/15.04/
<infinity> ogra_: They're not, those are symlinks from the wrong names to the right ones. :P
<ogra_> lol
<ogra_> k
<ogra_> i only noticed they are duplicated in the MD5SUM too
<infinity> Yeah, checksum-directory will sum anything with a file extension it likes.
<infinity> I has to be dumb and follow links or the linking to ../pool magic would break.
<infinity> s/I has/It has/
<didrocks> thanks infinity, ogra_ :)
<didrocks> customers care about 15.04 btw :p
<infinity> didrocks: Anything else I can delete for you while I'm here? :P
<ogra_> didrocks, which is awful !
<LocutusOfBorg> can we have a libpng16 transition tracking page?
<infinity> LocutusOfBorg: Sure.
<LocutusOfBorg> <3
<LocutusOfBorg> thanks
<didrocks> infinity: please do delete everything, I would be relieved! :-)
<didrocks> ogra_: if there was a finale ubuntu core 16.04, I would agree fully :)
<ogra_> didrocks, just a few months :)
 * ogra_ wouldnt care so much about final ... but feature-functional would be good
<didrocks> like having config? :p
<ogra_> config ... a classic shell so you can actually build snaps ... (sicne we dont support cross building)
<Odd_Bloke> LocutusOfBorg: Hey, was https://launchpad.net/ubuntu/+source/virtualbox/5.0.18-dfsg-2build1 fixing an upstream issue (that users of Virtualbox 5.0.18 on other platforms might see)?
<ogra_> these are the two pressing items imho ... once  they are back we should really push everyone to use 16.04
<LocutusOfBorg> Odd_Bloke, yes
<LocutusOfBorg> a serious one
<LocutusOfBorg> https://launchpadlibrarian.net/254650006/virtualbox_5.0.18-dfsg-2_5.0.18-dfsg-2build1.diff.gz
<LocutusOfBorg> look at the diff
<LocutusOfBorg> +Description: fix https://www.virtualbox.org/ticket/15317
<LocutusOfBorg> upstream asked me to cherry-pick the patch
<infinity> Odd_Bloke: So, sounds like the self-important bug submitter who felt the need to call us out on twitter is just running a buggy version of VirtualBox. :P
<Odd_Bloke> infinity: Yep. ^_^
<infinity> Odd_Bloke: Shame his followers won't see that.
<Odd_Bloke> infinity: If only he were running Ubuntu, he would never have had this problem.
<infinity> (And seems unlikely he'll mention it)
<infinity> willcooke: ^
<LocutusOfBorg> I got a lot of bug reports about 5.0.18 without the patch and 5.0.16
<LocutusOfBorg> and *none* yet about the version landed in xenial
<Odd_Bloke> LocutusOfBorg: Yeah, I saw it when testing the Vagrant box pre-release.
<infinity> LocutusOfBorg: Find a large tree to knock on.
<Odd_Bloke> But upgraded and it went away.
<LocutusOfBorg> infinity, I didn't get it :)
<willcooke> thanks infinity
<LocutusOfBorg> thanks Odd_Bloke for confirming the fix
<Odd_Bloke> I did enjoy a moment of sheer panic though, when I _did_ think it was an issue with our vagrant boxes. ;)
<pitti> infinity: ^ prerequisite for merged debhelper
<doko> pitti: done
<pitti> doko, infinity: ^
<pitti> infinity: yakkety autopkgtests should be fully running; next britney run will re-issue the lost test requests
<infinity> pitti: Huzzah.
<doko> pitti, done
<Odd_Bloke> infinity: Luckily, he only posted about it in replies, so only people who follow the people he was replying to will see it. :)
<LocutusOfBorg> Odd_Bloke, link?
<Odd_Bloke> LocutusOfBorg: https://twitter.com/therealmarv/with_replies <-- a couple of tweets in there; I replied to one already :)
<LocutusOfBorg> so at the end we should thanks infinity for accepting the last minute virtualbox fix :D
<Odd_Bloke> Indeed. :)
<pitti> infinity: fun, the pbuilder regression looks pretty much like the failure to deboostrap a yakkety container that I experienced earlier
<infinity> pitti: All I see is 404s...
<infinity> Oh, I guess the log links work.
<pitti> 404s?
<pitti> oh, I see what you mean (I didn't try looking at the debci page)
<infinity> http://autopkgtest.ubuntu.com/packages/p/pbuilder/yakkety/amd64
 * pitti will fix that
<infinity> pitti: Ugh.  I think it's Steve's sysvinit.
<pitti> infinity: I wonder why that SRU was released already
<pitti> given that it had a regression
<infinity> pitti: It wasn't, it was copied from xenial-proposed to yakkety-proposed.
<pitti> oh, *phew*
<pitti> right, only the floating task is closed
<pitti> so, similar to bug 1573240 I figure (no debootstrap.log in the output)
<ubot5> bug 1573240 in sysvinit (Ubuntu) "package initscripts 2.88dsf-59.2ubuntu2.1 failed to install/upgrade: pre-dependency problem - not installing initscripts" [Critical,New] https://launchpad.net/bugs/1573240
<infinity> pitti: Seems he subtly perturbed dependencies just enough to get util-linux configuring before systemd, which it seems to be not fond of.
<infinity> slangasek: ^
<pitti> http://autopkgtest.ubuntu.com/packages/p/pbuilder/ (and others) are yaky now (some might still be missing, html generation isn't done yet)
 * pitti adds Launchpad apport retracer configs for yak
<slangasek> infinity: right, I didn't count on it being copied forward to yakkety so soon; do you want to revert that in yakkety?
<infinity> slangasek: Yeah.  Want to revert properly with a higher version?
<slangasek> infinity: sorry, I was suggesting you go ahead and do the revert, as it'll be about 3 hours before I can get to it
<infinity> Oh.  Kay.
<infinity> slangasek: Done.
<balloons> can juju-core be accepted?
<jderose> anyone know why `update-manger` isn't offering the upgrade to 16.04 for 14.04 users? on 14.04 systems, even `update-manager -d` seems to no longer offer the upgrade to 16.04
<teward> jderose: i know the 'standard' way for 14.04 to 16.04 without -d is not available until .1
<jderose> teward: okay, thanks. this is a new scenario, isn't it? i don't think i've ever encountered this before
<teward> I dunno, I've never went from LTS -> LTS until at least .1
<teward> :P
<hggdh> jderose: it is not new
<jderose> hggdh: do you know when this started happening? in the grand schema of things, it is new, because there was a time when Ubuntu didn't do LTS point releases :P
<hggdh> jderose: I do not remember from the top of my head; it already happened on 14.04, but I am unsure if it also happened on 12.04
<jderose> hggdh: okay, maybe it started happening with 14.04 then
<hggdh> i think it did, though...
<hggdh> reasoning is this allows for major issues to be found before production upgrades are started (I, for one, never upgraded to a new version of a distro (or OS) before at *least* a few months
<hggdh> (I mean on production servers)
<cjwatson> -d should work though.
<hggdh> yes
<cjwatson> both http://changelogs.ubuntu.com/meta-release-development and http://changelogs.ubuntu.com/meta-release-lts-development list xenial
<wxl> um, yakkety dailies are all set up on the tracker but it seems like the cronjobs might not have been turned back on
<Laney> It's the first day, the archive isn't properly open - be patient. :)
<wxl> patience?! i have isos that need updated!!!!! they're probably at least 0.0000001% different by now!
<wxl> ;)
<wxl> just making sure things get done, seriously. i know it's easy to forget things after release week phew
<cjwatson> please don't, we have a checklist
<cjwatson> asking about nearly the last thing on it isn't helpful :)
 * wxl hangs his head in shame
<jderose> cjwatson: perhaps it's issues with my internet, but today `update-manager -d` isn't working for me for 14.04 to 16.04 upgrades. which is fine, just a bit unexpected :)
 * apw installs a 14.04 install to confirm/deny that
<jderose> apw: thank you very much! maybe it's just an issue with me, mirrors i'm using, etc
<doko> pitti, are the s390x autopkg testers running?
<doko> xnox, do you want to do the boost transition before opening the archive for general uploads?
<infinity> doko: I think the intention was to get boost1.60 (and defaults) in as well as libpng16 (and the libpng12 that disables the -dev), and then open the flood gates to do both transitions.
<infinity> doko: Also, I'm going to be sleeping and then on a plane, so I trust you, cjwatson, pitti, etc have this all in hand and we'll be ready to release when I get home. :)
<doko> infinity, ok. but xnox didn't answer my question if boost1.60 is ready for GCC 6, and if we need another boost transition this cycle
<infinity> doko: Sure, if he gives you crap answers, don't wait on him. :P
 * doko looks at icu ...
<apw> jderose, ok mine insisted i updated my 14.04, but once it was shiney and updated "update-manager -d" is offering me an update to 16.04
<jderose> apw: so it did take `update-manager -d`, not just running the update manager normally? i'll try again shortly, currently i'm doing a 15.10-->16.04 test
<apw> jderose, yes the -d is needed to let it see the update before .1
<jderose> apw: okay, thanks! i'll try `update-manager -d` again shortly
<apw> jderose, if it says you have updates to the local version it won't consider an upgrade between them
<jderose> apw: hmm, strange. did you have any such local updates that you think should have triggered this behavior?
<apw> jderose, no just if you have any kinds of update it will always only consider applying those, once the system at its current version is up-to-date, then and only then it will offer you updates to new releases
<jderose> hmm, i did do an `apt-get update && apt-get dist-upgrade` first
<slangasek> infinity: are you happy taking a command-not-found SRU without a bug + verification (since it's a flat db update)?
<doko> slangasek, he's on a plane
<infinity> Not yet.  Sleeping currently.
<infinity> In theory.
<infinity> slangasek: Would pay big money for it to be done in the same locale as the previous update.
<infinity> To avoid sorting diffs like:
<infinity> -i386|main|qemu-system-ppc|qemu-system-ppcemb,qemu-system-ppc,qemu-system-ppc64le,qemu-system-ppc64
<infinity> +i386|main|qemu-system-ppc|qemu-system-ppcemb,qemu-system-ppc64,qemu-system-ppc64le,qemu-system-ppc
<infinity> Man, I was sure I saw mvo update this fairly recently too.  That's a lot of churn.
<jderose> infinity: you should sleep in practice, i expect you've earned it :D
<slangasek> infinity: "in the same locale" wut
<slangasek> so... I should set a German locale to run the update?
<slangasek> infinity: oh.  for that matter, the source of the new data is an scp from mvo's homedir, so... kinda not something changing my local locale will fix
<infinity> slangasek: Oh, it's not mangled on your machine after fetch?  That's even weirder.
<infinity> slangasek: Cause those flips (ppc for ppc64, _ for -) are classic locale sort mismatches.  Oh well.  I'll tell him to fix his crap to be consistent another time. :P
<infinity> slangasek: Looks like most of the updates were legit anyway, I only spotted the occasional sort inversion.
<infinity> slangasek: So, to answer your question, I don't think it needs a bug, but it does need either a human to read it, or a linter that can tell me it's at least not broken.
<infinity> (THough, perhaps c-n-f itself acts as a full linter...)
<slangasek> infinity: it spits out a diff as part of the updater script, which I reviewed and give my blessing to.  There were various last-minute removals which looked sane, a few new commands which is what was driving me to look at this update, and a whole bunch of main->universe demotions that make everyone happy
<infinity> slangasek: Check.  If the way c-n-f loads/parses the DB effectively also acts as a reasonable runtime check against mechanical breakage (and I suspect that's true), that all seem kosher to me.
<infinity> s/seem/seems/
<jderose> apw: i just tried a 14.04 to 16.04 upgrade again... Ubuntu Software Updater normally isn't prompted for the upgrade to 16.04, but `update-manager -d` is again working for me. it didn't work earlier for me, but that could have been an issue with my internet, isp caching, etc.
<infinity> jderose: Yeah, it's not meant to without -d for another 3 months, so that sounds all correct.
<jderose> infinity: okay, gotcha. guess i just never noticed this before :)
<infinity> jderose: Well, it's only LTS->LTS upgrades that we delay for the extra polish (partially for the UI/UX "polish", mostly because unwinding all the weird upgrade bugs for a 2yr span can take some SRUs to get right), so maybe you just don't do that often. :P
<infinity> I know I don't.
 * infinity decides to wander off and get some sleep after the last 36h stretch.
 * jderose suggests infinity get some sleep :)
<infinity> That's the plan.
<infinity> Some sleep and then a plane.
<infinity> I'll catch everyone when I'm back in Canadia.
<infinity> slangasek: FWIW (yes, really, I'm leaving), I would suggest that c-n-f probably belongs in https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases alongside tzdata, as long as we can document a "this is how you check that it's not completely busted" paragraph.
<infinity> slangasek: Cause keeping it updated through an LTS might not be stupid either.
<slangasek> infinity: I agree and will try to not let that fall off my stack
<DalekSec> I'd think so for geoip-databases too. :3
<infinity> Yeah, I manually reviewed the last geoipdb update, that wasn't fun.  Again, if there's a way to lint it, I think it belongs there too.
<infinity> As does wireless-regdb (which has the added bonus of actually putting you in a position of potentially breaking some local laws if you *don't* keep it updated)
<slangasek> we should tie the wireless-regdb updates to the tzdata updates, and only accept regdb updates for countries that haven't jerked us around on DST settings for the past year
<ogra_> what if they dropped DST completely ?
<slangasek> ogra_: as long as they did this with 6 months notice, all fine!
<ogra_> heh
<slangasek> instead of "oh we know DST starts next month but we decided to let the states vote on whether or not they're going to follow it this year, I hear their state assemblies are meeting in two weeks in order to vote on it"
<ogra_> lol
<slangasek> (for A completely hypothetical example that in no way Resembles a real thinG that Ever happeNed in a real counTry causINg us to hAve to do an emergency tzdata update)
<infinity> slangasek: whilE i aGree that slow democratic process sucks, You may find that military dictators who just change their timezone on a whim and exPect all the computers in their country to magically fix Themselves overnight are even more annoying.
<slangasek> :-)
<mdeslaur> hehe
<apw> infinity, looks like there is something wrong with adt testing on s390x, there appear to be no adt tests in progress, but s390x is still listed in-progress
<apw> infinity, so sysvinit ain't going anywhere
<apw> oh _now_ you refresh and it dissapears ... pththth
<pitti> doko: running in principle yes, but they all segfault like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/s390x/f/floodlight/20160422_142808@/log.gz in yakkety
<pitti> but that's for Monday morning
<xnox> doko, infinity - general uploads i don't care, before we start syncing from debian... probably yes.
<xnox> sorry that i was out playing beach volleyball, in british down-pour rain, in a wet suit, in a sand pit =)
<tumbleweed> sounds like xnox's life
<xnox> hehe
<doko> xnox, icu uploaded, will wait with any boost1.60 accept until that is built
<doko> do you know if 1.60 is ready for GCC 6?
<xnox> doko, nice one.
<xnox> doko, it should be yes.
<xnox> doko, are you default for gcc 6 already?
<xnox> syncpackage: Error: Debian version 1.60.0+dfsg-4 has not been picked up by LP yet. Please try again later.
<xnox> i can't sync the right boost yet
<xnox> slangasek, doko, infinity - $ syncpackage -r yakkety boost1.60 -V 1.60.0+dfsg-4
<xnox> when you need it.
<doko> ta
<doko> xnox, please add a transition tracker
<xnox> wgrant, could I please have equivalent of primary-xenial-s390x-release.html for yakkety on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/ ?
<xnox> i still think i have quite a few things that I could fix.
<xnox> Â¯\_(ã)_/Â¯
<mapreri> xnox: can you also sync gdk-pixbuf while the archive is still closed?
<xnox> mapreri, no, cannot sync cause it's missing my bug fix =)
<xnox> needs a merge =)
<mapreri> (message relayed.  /me feels like a homing pigeon)
<doko> mapreri, gdk-pixbuf really needs that unfulfillable dependency fixed: = on a arch any and an arch all package
<mapreri> doko: sorry, not sure about what are you referring to.  i was only aware of debian #819779
<ubot5> Debian bug 819779 in libgdk-pixbuf2.0-dev "gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev" [Serious,Fixed] http://bugs.debian.org/819779
<slangasek> sounds like he's describing non-binnmu-safe dependencies; which are only an issue for Debian, not Ubuntu
<doko> $ apt-cache show libgdk-pixbuf2.0-0|grep Depends
<doko> Depends: libgdk-pixbuf2.0-common (= 2.34.0-1)
<slangasek> sure
<slangasek> not a problem in Ubuntu :)
<mapreri> ah, yes, not a problem here.
<mapreri> though, there is not even a bug report in debian
<doko> filing one
<mapreri> ta
<xnox> that looks odd
<xnox> doko, what are you doing?
<xnox> ah icu, ok
<LocutusOfBorg> I'm not sure how we are left, but first thanks for the libpng1.6 accept, and second, pretty please --> https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1573839
<ubot5> Ubuntu bug 1573839 in gdk-pixbuf (Ubuntu) "please merge gdk-pixbuf from debian" [Undecided,New]
<LocutusOfBorg> I already prepared around ~20 packages to upload, when the archive will be open (they are ubuntu specific packages), and I hope the auto import will do most of the job with gdk fixed
 * LocutusOfBorg goes to sleep
#ubuntu-release 2016-04-23
<LocutusOfBorg> doko, I uploaded 7 packages, that had mostly "no change rebuilds" except for the libpng12-dev -> libpng-dev switch
<LocutusOfBorg> here we are ^^^
<infinity> apw: sysvinit revert fixed debootstrap for me, BTW.  Hoping that's true for you too. :P
<infinity> slangasek: ^
<infinity> ubuntu-core dailies built successfully, turning the rest of the world back on in cron.
<doko> LocutusOfBorg, please re-upload qtwebkit-source
<doko> LocutusOfBorg, please re-upload khtml, glmark2, kffmpegthumbnailer
 * doko steps away until the dust settles 
<LocutusOfBorg> doko, ^^^
<LocutusOfBorg> doko, ^^
<LocutusOfBorg> oops please reject fdclock
<LocutusOfBorg> and gimp-gap
<LocutusOfBorg> ok please accept qtwebkit-source khtml glmark2 kffmpegthumbnailer
<LocutusOfBorg> please accept vbaexpress
<LocutusOfBorg> please reject fdclock and gimp-gap
<LocutusOfBorg> <3
<LocutusOfBorg> mapreri, ^^
<mapreri> LocutusOfBorg: ta
<LocutusOfBorg> doko, lots of boost breakages
<LocutusOfBorg> I'm trying to look at them but I have not enough boost knowledge
<LocutusOfBorg> please accept castle-game-engine sync, fixing view3dscene
<LocutusOfBorg> everything wrt libpng ^^
<doko> gdal is a transition. can this be avoided?
<xnox> infinity, doko: looks like mpi portions of boost landed in main, instead of universe
<doko> xnox, which ones?
<xnox> -mpi1.60.0, -mpi1.60-dev, -mpi-python1.60.0, -mpi-python1.60-dev, -graph-parallel1.60.0, -graph-parallel1.60-dev should all be in universe
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#boost1.60
<xnox> do you have an icu tracker now too?
<LocutusOfBorg> tes
<LocutusOfBorg> doko, yes
<LocutusOfBorg> the transition needs to become a little greener, I can't find the issues with all this red
<LocutusOfBorg> I guess I'll take some rest
<LocutusOfBorg> doko, what do you think about my libvigraimpex sync?
<LocutusOfBorg> seems everything is upstream except for the -O2 on ppc64el
<LocutusOfBorg> well, transition?
<doko> LocutusOfBorg, i just uploaded with the fixed dependency. lets see if this works
<doko> xnox, demoted
<LocutusOfBorg> yep I saw :) thanks
<doko> hmm, gdal built for now ...
<LocutusOfBorg> pitti, can mapserver be syncd?
<doko> LocutusOfBorg, please lets try without these two syncs, rejecting for now
<LocutusOfBorg> ok
<doko> xnox, transition trackers at http://people.canonical.com/~ubuntu-archive/transitions/
<LocutusOfBorg> doko, getting strange fPIC related failures, e.g. https://launchpad.net/ubuntu/+source/hhvm/3.12.1+dfsg-1ubuntu1/+build/9619530
<LocutusOfBorg> or ghc
<doko> yes, I hope sbeattie will have a look
<LocutusOfBorg> ta
<LocutusOfBorg> please reject xbmc
<LocutusOfBorg> transitional package
<LocutusOfBorg> I finished the ubuntu merges
<LocutusOfBorg> the other stuff should be fix itself when the archive opens
<LocutusOfBorg> (and then we have to look at build failures :p )
<LocutusOfBorg> any eta for the archive opening?
<doko> did I break the transition tracker? not seeing updates anymore
<LocutusOfBorg> what does it mean openscenegraph on ppc64el and s390x? can't install ffmpeg libraries...
<LocutusOfBorg> doko, I think r-base will unblock vtk6
<LocutusOfBorg> I think I remember some issues vtk6 related fixed in some r-base upload
<LocutusOfBorg> doko, please retry emacs24
<LocutusOfBorg> both needed for kodi ^^
<daniele_> hi guys, how can I help with ubuntu codebase?
<infinity> xnox: Fixing boost components.
<xnox> infinity, thank you.
<knome> daniele_, #ubuntu-devel is probably a better place for that kind of questions, but even it might be quite on weekends
<knome> *quiet too
#ubuntu-release 2016-04-24
<slangasek> infinity: and that revert of sysvinit should be fine for yakkety anyway fwiw since the changes were strictly for an upgrade issue
<infinity> slangasek: Yeah, but we also need to be able to build xenial dailies. :P
<infinity> slangasek: So, need to sort this out better.
<infinity> Well, build dailies, and also not break d-i netboot.
<slangasek> infinity: build dailies from -proposed? surely not needed right now
<slangasek> infinity: I do intend to take a long hard look at the SRU on monday
<infinity> slangasek: No, no.  I just meant eventually, not today.
<infinity> Anyhow, going to head off and try to get into a vaguely correct timezone.
<LocutusOfBorg> doko, please syncpackage giflib -s costamagnagianfranco
<LocutusOfBorg> it should help feh
<LocutusOfBorg> also libcec please accept
<LocutusOfBorg> and please remove "xmbc" from yakkety, we don't needs such transitional package
<LocutusOfBorg> "xbmc"
 * LocutusOfBorg leaves, cheers!
<LocutusOfBorg> doko, syncpackage libpng1.6 -s costamagnagianfranco <-- multiarch -dev package yeah!
<ginggs> LocutusOfBorg, doko: i'll sync giflib and libpng1.6
<doko> slangasek, infinity, xnox, pitti: my hope was to fix some more things before opening the archive for general uploads.
<doko>  - finish the libpng/boost and icu transitions (although libpng and boost are untangled from icu)
<doko>  - find out about ghc and -fPIE, broken on amd64 and ppc64el, that will block everything in a very short time. although haskell packages seem to ftbfs everywhere
<doko>  - let gcc-5/gcc-6 migrate so people can get and see the new PIE defaults
<doko>  - I'm told that kernel modules are broken with -fPIE as the default
<doko>  - a lot of the phone stack ftbfs
<doko> so maybe give people a chance for fixes and only open on Monday late evening or Tuesday?
<infinity> doko: I don't see any point in finishing the transitions (and some will go better with auto-sync back on).
<infinity> doko: But gcc/pie investigations seem worthwhile.
<infinity> pitti: There still seems to be a lot of 404s for yakkety autopkgtest pages.
<doko> $ reverse-depends node-stringprep
<doko> reverse-depends: Error: Unknown release
<doko> infinity, ^^^ what needs fixing for this?
<infinity> doko: Whoever runs the ubuntuwire stuff needs to teach it about new suites.
<doko> wgrant, ^^^
<infinity> wgrant: ^ Do you have access to fix reverse-depends, or is that one of the other ubnutuwire people?
<infinity> We really should move those into the Canonical DC some day, given how much we rely on those tools.
<infinity> doko: You can use checkrdepends as ubuntu-archive@snakefruit instead.
<infinity> doko: It's more accurate anyway (just annoyingly on a remote machine).
<infinity> doko: http://paste.ubuntu.com/16034666/
<slangasek> infinity: reverse-depends is tumbleweed
<tumbleweed> and yes, I'd love someone to look after it :)
<infinity> tumbleweed: Where's the code live?
<infinity> tumbleweed: I'm sure we could move it to snakefruit or lillypilly if all it needs is a dists mirror and some TLC.
<infinity> (ie: to people.canonical.com)
<infinity> tumbleweed: And perhaps cloudify it later for HA and shininess.
<infinity> tumbleweed: Without looking, I'm assuming it's a combo cron job to populate a DB and CGI script to return the API?
<infinity> (hopefully a flat file db of some sort, not SQL-backed madness)
<tumbleweed> infinity: WSGI not cgi. and a sqlite db
<tumbleweed> https://code.launchpad.net/~stefanor/+junk/reverse-deps
<tumbleweed> infinity: anyway, I did a git pull on my distro-info-data checkout on ubuntuwire
<cjwatson> doko: hm, actually, this ghc thing might ring a faint bell from when I was bootstrapping s390x
<cjwatson> doko: will take me a little while to build suitable environments to test in, but I have an idea
<doko> ta
<cjwatson> (I vaguely remember that I may have had to do an extra cycle, the first with a wrapper in place of /usr/bin/ghc - will investigate that)
<infinity> I suspect we have a lot places where people thought it was a good idea to do "if s390x { -fno-pie -no-pie }" and we need to stop making that conditional.
<infinity> Since it's a no-op for no-pie arches anyway, I'd assume.
<infinity> doko: Is there a plan to move to gcc-6 this cycle too, or is that for 17.04?
<cjwatson> infinity: Yeah but that's not quite the problem here.  I think it needs a slightly bigger hammer the first time round to cope with the old ghc not emitting no-PIE flags
<infinity> cjwatson: Sure, I didn't mean for ghc, but rather in general.
<infinity> cjwatson: Rebootstrapping compilers is a special kind of suck.
<cjwatson> One reason it was conditionalised, IIRC, was that it hadn't been that long since -fno-PIE (or maybe -no-PIE) started existing at all.
<cjwatson> In fact I think I remember at one point it may only have been valid with the set of patches applied on s390x (but I could be misremembering that).
<cjwatson> Definitely remember running into something in that general area.
<infinity> I wish they'd picked a different TLA for that.  I get hungry every time it's mentioned.
<infinity> Mmm, PIE.
 * infinity considers a trip to the pie shop.
<infinity> The pie shop that cleverly waited until the lease was up on 314 10th Street and then made the building owners an offer they couldn't refuse.
<infinity> (Seriously)
<doko> infinity, I'd like to
<infinity> doko: For opening, or later in the cycle when more ftbfs bugs have been fixed?
<infinity> (Assuming the latter since you haven't changed -defaults yet)
<doko> infinity, not before 6.2 is released which will be late June/early July
<infinity> doko: Check.
<doko> hrm, haskell packages are not using Built-Using attributes ...
<infinity> The hashed runtime deps achieve basically the same result, I would think.
<doko> no, not if there aren't any
<infinity> doko: When are there ever not any?
<infinity> Every -dev package depends on the -dev packages it was built with.
<doko> infinity, haskell-text-icu builds a -dev package only
<infinity> doko: Yeah, check its deps.
<doko> not for non-haskell libs
<infinity> (base)adconrad@nosferatu:~$ apt-cache show libghc-text-icu-dev | grep ^Depends
<infinity> Depends: libghc-base-dev-4.8.2.0-0d6d1, libghc-bytestring-dev-0.10.6.0-9a873, libghc-deepseq-dev-1.4.1.1-614b6, libghc-text-dev-1.2.2.0-2c09c, libc6 (>= 2.2.5), libicu-dev
<infinity> Ahh, I see.  Yeah, no Built-Using for the C libs.
<infinity> That's probably something dh-haskell could fix.
<infinity> s/could/should/
<infinity> And thanks to Haskell transitions happening every 3 weeks, I assume a dh-haskell change affects the entire rdep tree pretty quickly. :P
<doko> cjwatson, just in case this gives you more information: https://launchpad.net/ubuntu/+source/haskell-text-icu/0.7.0.1-4build2
<mwhudson> yeah, the fun with -fno-pie is that it was only added around the same time s390x started defaulting to pie
<doko> xnox, would be nice if you could look tomorrow at the boost related ftbfs, which are blocking icu: osmium and mpd
<LocutusOfBorg> hi can an archive admin please explain that? https://launchpad.net/ubuntu/+source/libcec/3.1.0+dfsg1-4
<LocutusOfBorg> double publishing? cjwatson ^^
<infinity> That looks like an unpleasant race...
<infinity> wgrant: ^
<LocutusOfBorg> :I*
<LocutusOfBorg> seems so
<slangasek> cjwatson: the patches for -fno-pie were always present on all architectures, but it was only introduced in the 16.04 cycle, so if you wanted backportability to any arch that existed prior to 16.04, you would need to conditionalize
<infinity> Ahh, gross.
<doko> I was told these races were harmless
<infinity> doko: That race looks harmful, as it has duplicate build records, both of which succeeded.  So, no way to reconcile disk and librarian.
<doko> infinity, well, then re-upload
<infinity> (Most double build record races result in fail/success or fail-to-upload/success pairs)
<infinity> doko: Sure, I just want wgrant/cjwatson to look at the current state first to see WTF.
<infinity> doko: Reuploading it likely the short-term fix once they've had a look.
<doko> I think that's known
<infinity> s/it likely/is likely/
<cjwatson> doko: basically identical, as expected.  No point uploading haskell-* stuff until ghc is sorted.
<cjwatson> infinity: Just looks like the usual race when something's double-accepted from the queue or similar
<cjwatson> Indeed just reupload.
#ubuntu-release 2017-04-17
<bdmurray> infinity: Is there a zesty-updates milestone yet?
<bdmurray> infinity: Could you review xapian-bindings in the Zesty SRU queue?
<infinity> bdmurray: There is now.
<infinity> bdmurray: And LGTM.
<bdmurray> infinity: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted xapian-bindings [source] (zesty-proposed) [1.4.3-1ubuntu1]
<infinity> bdmurray: Did that icky xapian1.3 thing ever exist in Debian?  If so, you should forward this.  If not, make a mental note to drop the delta post-18.04
<slangasek> it did not
<mitya57> Can someone please review qtbase-opensource-src in Xenial SRU queue? I hope itâs not a problem that there were two subsequent uploads^W syncs, is it?
-queuebot:#ubuntu-release- Unapproved: cacti (xenial-proposed/universe) [0.8.8f+ds1-4ubuntu4.16.04.2 => 0.8.8f+ds1-4ubuntu4.16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cacti (yakkety-proposed/universe) [0.8.8h+ds1-5 => 0.8.8h+ds1-5ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cacti (zesty-proposed/universe) [0.8.8h+ds1-8 => 0.8.8h+ds1-8ubuntu0.1] (no packageset)
<bdmurray> slangasek: Could update-manager get fully phased for Trusty?
<slangasek> bdmurray: done
<apw> mitya57: which one do you want reviews the first or last
<nacc> apw: iirc (this was brought up over the weekend), the intent of the uploader is the second (which includes the first) is what should go through
<nacc> apw: but probably want mitya57 to double-verify that :)
<apw> nacc, yep i don't want to use my brain on choosing
<nacc> apw: ack
<tsimonq2> infinity, cyphermox: Hey there, is bug 1633913 worth looking into?
<ubot5> bug 1633913 in Ubuntu "lubuntu and ubuntustudio are missing pool; can not install without internet connection" [Critical,Triaged] https://launchpad.net/bugs/1633913
#ubuntu-release 2017-04-18
<infinity> tsimonq2: It might have been nice for someone to point it out (or fix it) before those two releases shipped. :P
<infinity> tsimonq2: But sure, it can be fixed for 17.10
<tsimonq2> infinity: Apologies.
<tsimonq2> infinity: But, I still don't necessarily get what the problem is, which is why I pinged you two.
<lyn||ian> I might have missed it somewhat because ubiquity crashes on this laptop with no internet because of a specific wifi card
<infinity> tsimonq2: For studio, I don't think this is a regression.
<infinity> tsimonq2: For lubuntu, it looks like someone rearranged your seeds and did it wrong.
<lyn||ian> yeah there was a time with the seeds that it entirely broke so might not have fixed it right
<infinity> tsimonq2: In yakkety, gilir split ship-live into a gtk and qt variant, and moved some bits to "ship-live-share".  Looks like he didn't actually get the structure right, and nothing pulls in ship-live-share.
<infinity> (Which is where the needed grub package is)
<tsimonq2> infinity: Great. </sarcasm> So how can this be fixed? :)
<infinity> tsimonq2: In the past, or the future? :P
<infinity> tsimonq2: In the future, someone can fix the seeds so this works properly.
<tsimonq2> infinity: We can't change the past, so I guess the future works? :P
<tsimonq2> infinity: What needs to be fixed?
<tsimonq2> infinity: I mean, I know *what* the problem is now, I just want to know *how* to fix it.
<infinity> tsimonq2: Not 100% sure without experimenting.  It all looks sort of right at first glance, but it's clearly not or the packages would be there.
<tsimonq2> infinity: Ok, so what package are we missing? grub-efi-amd64-signed?
<infinity> tsimonq2: Looks like your whole pool is missing.
<tsimonq2> infinity: Interesting...
<tsimonq2> infinity: Got some docs on this somewhere? I'm a newbie on this particular topic.
<infinity> Nope.
<tsimonq2> infinity: Ok, so I'll DuckDuckGo around. :P
<infinity> That likely won't help either.
<tsimonq2> Oh?
<infinity> Unless you think there are a lot of discussions on the interwebs about how debian-cd and seeds and germinate do their thing?
<infinity> Which is pretty specific to a workflow of about 3 people.
<tsimonq2> So what $words-on-some-page do I need to read to get familiar with this? Am I going to have to read through some code here or is there some other discussion somewhere? :P
<infinity> Code.  And I'm not sure which code, precisely, I'm grepping around myself.
<tsimonq2> Ah, ok.
<tsimonq2> infinity: For the sake of preventing this sort of thing in the future, maybe I should submit some more ISO QA tests to ensure that we always test the images with no internet connection?
<tsimonq2> infinity: I mean, sort of a stupid question, but there's no technical requirement saying that we have to have an internet connection, right? :P
<infinity> tsimonq2: Indeed, installation should work without teh internets.
<infinity> tsimonq2: That's really the whole point of ISOs, IMO.
<tsimonq2> infinity: Agreed, if it weren't for the lack of internet connections, we could all just use netboot and be done with it. :P
<tsimonq2> Such description, very beneficial. :P bug 1682499
<ubot5> bug 1682499 in systemd (Ubuntu Zesty) "disable dnssec" [Undecided,Confirmed] https://launchpad.net/bugs/1682499
<tsimonq2> "because pitti says so"
<tsimonq2> lol
<tsimonq2> infinity: bug 1683581
<ubot5> bug 1683581 in Ubuntu Manual Tests "Test needed: Installation with no Internet connection" [Undecided,New] https://launchpad.net/bugs/1683581
<tsimonq2> And on that note, sleepytime for me. Good night infinity, thanks for looking into that bug. :)
<fossfreedom_> LocutusOfBorg: Hi - quick question - there is a new version of budgie-desktop is available from upstream.  Given that stretch hasnt released yet, should I hold off requesting a review & upload to debian unstable until after the stretch release?
<LocutusOfBorg> fossfreedom, debian experimental?
<LocutusOfBorg> and synt to Ubuntu when opens?
<fossfreedom_> sounds like a plan - I suppose I should request here to sync from experimental?  I presume it doesnt happen automatically.
<LocutusOfBorg> fossfreedom, I can do it
<LocutusOfBorg> just make it syncable
 * LocutusOfBorg means by incorporating the Ubuntu delta
<fossfreedom_> thanks for the info.  much appreciated
<LocutusOfBorg> thanks to you for caring :)
<LocutusOfBorg> btw I can sync in Ubuntu only after AA opens :p
<LocutusOfBorg> just to understand... you want https://github.com/budgie-desktop/budgie-desktop/issues/588 fixed, right?
<fossfreedom_> LocutusOfBorg: aye - very nicely cleaned up now by upstream
<fossfreedom_> by virtue of a dumping of autotools and moving to meson build
<fossfreedom_> LocutusOfBorg: the only real Ubuntu delta is the fact I have to patch one file at build time. Not sure how to deal with that scenario to cope with a sync. Thoughts?
<LocutusOfBorg> yep I got the email when the bug has been closed :)
<LocutusOfBorg> fossfreedom_, why the patch can't be added in Debian too?
<fossfreedom_> it is the nm-applet - ubuntu has patching to cope with appindicators.  I need to patch to say "nm-applet --no-indicators" ... which throws an error in Debian because nm-applet is correctly vanilla
<apw> i assume some of that delta will go away this coming cycle
<fossfreedom_> true.  I suppose we can live the broken network applet up and until alpha 1/2 - hoping that nm-applet patching becomes more vanilla.  if not readd the ubuntu specific patch then.
<LocutusOfBorg> fossfreedom, in case:
<LocutusOfBorg> https://sources.debian.net/src/libpng1.6/1.6.28-1/debian/rules/#L19
<LocutusOfBorg> you can patch -p1 at runtime to have a zero-delta code
<LocutusOfBorg> override configure to patch before, and override clean to unpatch
<LocutusOfBorg> or do the quilt pop/push in a curl-similar hacky way https://sources.debian.net/src/curl/7.52.1-4/debian/rules/
<fossfreedom_> okey-dokey - will give that a try. cheers.
<LocutusOfBorg> :)
<LocutusOfBorg> I prefer no change delta from Debian and Ubuntu, and in case I prefer some hack un rules rather than having to manually upload them twice each times you upload in Debian
<LocutusOfBorg> but hacks are hacks, that patch might not apply on a new upstream release, and Ubuntu will fail to build (fail to patch), while Debian will be good
<LocutusOfBorg> so, please drop hacks
<LocutusOfBorg> when possible
<fossfreedom_> makes sense.
<FourDollars> Hi, do you know why https://launchpad.net/ubuntu/+source/update-manager doesn't appear in trusty-updates?
<FourDollars> It looks like only trusty-updates affected. http://packages.ubuntu.com/search?keywords=update-manager&searchon=names&suite=all&section=all
<rbasak> ?
<rbasak> 1:0.196.23 is in trusty-updates.
<cjwatson> only source
<cjwatson> binary has vanished, probably due to double-override bug
<xnox> slangasek, bileto's britney seems "slow" from queuing to actually creating execuses page and triggering the run of the test i see about an hour delay.
<xnox> from autopkgtest.ubuntu.com finishing running all the tests to updating the execuses - again it seems slow e.g. about an hour.
<xnox> the archive britney seems to run more often.
<FourDollars> How can we make update-manager 0.196.23 binary appear in trusty-updates again?
<cjwatson> I've copied it back in, which will hopefully be successful
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-updates/main) [1:0.196.23 => 1:0.196.23] (core) (sync)
<cjwatson> bdmurray: the phased updater really needs some locking; I suspect that's the problem here
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu2 => 232-21ubuntu3] (core) (sync)
<Lyoness> whois infinity
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.5 => 1.11.8-0ubuntu0.6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+17.04.20170328-0ubuntu1 => 15.04.1+17.04.20170418-0ubuntu1] (ubuntu-desktop) (sync)
<cyphermox> slangasek: still struggling with that livecd-rootfs SRU; I can't really think of why it doesn't work, everything seems to be in place. I want to send my new changes (to enable casper on that image) which I know is definitely required, and then try another build to debug the whole process.
<cyphermox> (it should show up in the queue anytime)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.1 => 2.441.2] (desktop-core)
<xnox> slangasek, infinity - systemd is in the unapproved. Sync from https://bileto.ubuntu.com/#/ticket/2719 - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2719/+packages
<xnox> all tests can be peppered over, I believe from https://bileto.ubuntu.com/excuses/2719/zesty.html
<xnox> the s390x/armhf have boot smoke failing - a test that reboots the instance and checks that no jobs are running.... but systemd-resolved ends up stuck starting up (or maybe shutting down) upon lxc/lxd instances reboot.
<xnox> Not sure what is going on there, given that zesty containers do restart for me.
 * xnox should open a bug about that
<xnox> and armhf has the still failing unit test.
<xnox> snapd/gvfs tests have been failing in release as well, so not a regression, no?
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [sync] (trusty-updates) [1:0.196.23]
-queuebot:#ubuntu-release- Unapproved: k3b (zesty-proposed/universe) [2.0.3a+git20170325-0ubuntu2 => 17.04.0-0ubuntu1] (kubuntu)
<slangasek> xnox, infinity: systemd SRU on my stack to review this morning
<slangasek> cyphermox: do you need more eyeballs on the livecd-rootfs stuff, or are you working through it?
<cyphermox> I wouldn't mind another head, but I'm not sure if it's livecd-rootfs or something odd in casper
<cyphermox> at least to think it through; I'm not seeing the difference between desktop's casper and my image's
<cyphermox> I do have to upload a fix for the netplan + NM upgrade issue first though
<cjwatson> FourDollars: update-manager/trusty-updates should be resurrected now, modulo mirroring
<FourDollars> cjwatson: Cool. Thx a lot.
-queuebot:#ubuntu-release- Unapproved: thermald (zesty-proposed/main) [1.5.4-4 => 1.5.4-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: thermald (yakkety-proposed/main) [1.5.3-4ubuntu1 => 1.5.3-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: thermald (xenial-proposed/main) [1.5-2ubuntu3 => 1.5-2ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (zesty-proposed) [2.441.2]
 * apw looks at thermald
-queuebot:#ubuntu-release- Unapproved: rejected thermald [source] (zesty-proposed) [1.5.4-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.1 => 2.441.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: thermald (zesty-proposed/main) [1.5.4-4 => 1.5.4-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: network-manager (yakkety-proposed/main) [1.2.6-0ubuntu1 => 1.2.6-0ubuntu1.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (zesty-proposed) [1.5.4-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (yakkety-proposed) [1.5.3-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (xenial-proposed) [1.5-2ubuntu4]
<infinity> cyphermox: There's a change in that livecd-rootfs upload that isn't represented in the changelog.
<xnox> infinity, slangasek: can i haz ubuntu-16.04.3 milestone for xenial series please?
<slangasek> milestone, yes.  does the calendar say what our date is for it?
<xnox> slangasek, no date yet.
<xnox> 16.04.2 was WW18
<slangasek> infinity: ^^ 16.04.3 date please
<slangasek> (milestone created w/o date in the meantime)
<xnox> tah
<xnox> 20th of July or some other suitable thing
<xnox> WW29
<xnox> seems early; but .2 was late =/
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (zesty-proposed) [2.441.2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (zesty-proposed) [232-21ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mozjs38 [source] (zesty-proposed) [38.2.1~rc0-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.1 => 2.441.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (zesty-proposed) [15.04.1+17.04.20170418-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.2]
-queuebot:#ubuntu-release- Unapproved: accepted cacti [source] (zesty-proposed) [0.8.8h+ds1-8ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted cacti [source] (yakkety-proposed) [0.8.8h+ds1-5ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted cacti [source] (xenial-proposed) [0.8.8f+ds1-4ubuntu4.16.04.3]
-queuebot:#ubuntu-release- Unapproved: muon (xenial-proposed/universe) [4:5.6.0-0ubuntu1 => 4:5.6.0-0ubuntu1.16.04.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: muon (yakkety-proposed/universe) [4:5.6.0-0ubuntu1 => 4:5.6.0-0ubuntu1.16.10.1] (kubuntu)
<tsimonq2> xnox: For what it's worth, I filed bug 1683581 as soon as I was aware there was an issue. In Lubuntu, we will make changes to prevent bug 1633913 in the future. :)
<ubot5> bug 1683581 in Ubuntu Manual Tests "Test needed: Installation with no Internet connection" [Undecided,New] https://launchpad.net/bugs/1683581
<ubot5> bug 1633913 in lubuntu-meta (Ubuntu) "lubuntu and ubuntustudio are missing pool; can not install without internet connection" [Undecided,New] https://launchpad.net/bugs/1633913
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.10]
<mwhudson> hmm why is https://launchpad.net/ubuntu/+source/golang-github-coreos-pkg is still in main?
<infinity> mwhudson: juju-core -> golang-github-coreos-go-systemd -> golang-github-coreos-pkg
<mwhudson> ah right
#ubuntu-release 2017-04-19
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.10 => 1:2.5+dfsg-5ubuntu10.11] (ubuntu-server, virt) (sync)
<xnox> tsimonq2, horum, that is bad.
<xnox> slangasek, could you please activate run-once no-network test case for lubuntu products?
<xnox> balloons, please add me to the https://launchpad.net/~ubuntu-testcase team =) i am lead for s390x product releases in the iso tracker.
<jamespage> please could someone reject neutron 2:8.4.0-0ubuntu2 from the xenial unapproved queue
<apw> jamespage, looking
<jamespage> apw: it needs pairing up with another neutron sru
<apw> jamespage, what about neutron-lbaas
<jamespage> apw: that ones ok as it
<jamespage> as is rather
<apw> jamespage, ack and done
<jamespage> apw: ta
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.24+17.04 => 2.24.1+17.04] (desktop-core, ubuntu-server)
 * apw looks at the snapd uploads ^
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.24.1+17.04]
<flocculant> xnox: all the current 'no network' testcases are based on doing other things - me and balloons were discussing it yesterday, https://irclogs.ubuntu.com/2017/04/18/%23ubuntu-quality.html
<flocculant> probably best to wait for tsimonq2 to write the testcase - I'm an admin on the manual stuff and watch for merges for that - so atm waiting for tsimonq2 :)
<flocculant> once that's done he'll be able to add it to his test list - at least once the tracker is set up for the AA release
<tsimonq2> flocculant: Tonight, I can't do it right now.
<flocculant> tsimonq2: even if you could - I can't I'm off again shortly :) if it's there 0700 uk time I'll look first thing
<tsimonq2> And flocculant has a point, I really don't think it's something we can just enable... so please wait, xnox
<tsimonq2> slangasek: ^
<tsimonq2> flocculant: Ack, I'll make it happen. :)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.24]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.24+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.24~14.04]
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.6+16.10 => 2.24.1+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.6 => 2.24.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.6 => 2.24.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu1 => 2:8.4.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.6+16.10 => 2.24.1+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.24.1~14.04] (no packageset)
 * apw deals with snapd ^
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.24.1+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.24.1]
<rbasak> "deals with" :-P
<mitya57> apw, right, I want the last qtbase which includes the first. (I uploaded the first, it was not accepted for some time, then I needed one more fix and uploaded it too)
<apw> rbasak, they were duplicates ...
<apw> rbasak, i am reviewing the rest, as i am familiar with the changes we asked for
<mitya57> If two uploads is a problem, I can squash them into a single one.
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (zesty-proposed/main) [2:10.1.5-5055683-1ubuntu1 => 2:10.1.5-5055683-1ubuntu1.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> bdmurray: should the pending-sru report maybe show a bug as green instead of purple when it's verified for *this* series that we're currently looking at?
<bdmurray> slangasek: because now if its purple you won't look at the bug, but if it's green you would?
<slangasek> bdmurray: if I have a mix of green and purple I have to look at the bug to see if it's fixed for this release; if it's all green I know it should be ready to release and can just load up all the bugs for one final check
<bdmurray> slangasek: ack, so it'd help with multi-bug SRUs.
<slangasek> bdmurray: imho yes
<howefield> x/exit
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.24.1+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected graphviz [source] (trusty-proposed) [2.36.0-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: graphviz (trusty-proposed/main) [2.36.0-0ubuntu3.1 => 2.36.0-0ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.24.1]
<apw> slangasek, bdmurray could we just get rid of verification-needed et al and _only_ have per series ones ...
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.24.1~14.04]
<rbasak> apw: +1
<rbasak> I've considered asking for that too.
<apw> we are afterall the only ones who put those in the request inside the bug via sru-foo
<apw> we can detect people who don't read and use the old ones and auto respond on those
<bdmurray> apw: I already made slangasek's change though! So you want to switch to tagging v-n-$series and v-d-$series?
<apw> bdmurray, personally i find it confusing we have a tag for all series and one per series
<apw> bdmurray, i assume so do people setting them
<apw> bdmurray, or you may yet tell me that is not what the v-n means of course and i demonstrate how confused i am
<bdmurray> apw: v-n captures that there is some kind of verification of the SRU needed so people could search LP for bugs needing verification with one tag.
-queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (trusty-proposed) [2.36.0-0ubuntu3.2]
<apw> bdmurray, ok so the sru-report will now essentially only show the state of the -series tags ?
<bdmurray> apw: For verification-done that's my intent.
<apw> bdmurray, i can see that that is useful as long as we are only using the -series ones
<rbasak> Also sru-review needs to change to munge the existing tags correctly (and create the correct new ones)
<apw> and that is just a convineince for "finding verification work"
<apw> bdmurray, though in some sense if verification-needed is meant to set if any v-n-* exists then we ought to be doing that via a robot
<bdmurray> Maybe we should open a bug so we can discuss this in a better medium than irc.
<bdmurray> https://bugs.launchpad.net/ubuntu-archive-tools
<bdmurray> I think I understand what y'all want but don't want to put effort into the wrong thing, nor lose track of the idea since its not a one line / one tool fix.
<rbasak> While we're on the subject...
<rbasak> The git workflow stuff is able to do SRU reviews from the queue now.
<rbasak> It's easier to review this way (IMHO anyway) because I can diff something in unapproved against anything in the archive currently (and indeed any tree in any upstream git repo)
<rbasak> I'm still using sru-review to accept currently, as it does some other checks as well potentially.
<rbasak> But I'd like to add queue accept and reject functions to the git workflow tool instead.
<rbasak> To do that, maybe I could factor out the actual checking bits of sru-review/accept/release into some kind of API and access that instead?
<rbasak> As I don't want to duplicate code.
<rbasak> Anyway, opinions welcome.
<rbasak> Perhaps if everyone wants to deprecate the current tools in favour of the git workflow, then duplicating the code for now and then ditching the old tooling would be easier.
<nacc> and i'm 100% on board with making the tooling more flexible to support the most generic cases
<nacc> don't want the tooling to dictate workflow, just to supprot it
<bdmurray> wxl: You might want to have a look at bug 1633913.
<ubot5> bug 1633913 in lubuntu-meta (Ubuntu) "lubuntu and ubuntustudio are missing pool; can not install without internet connection" [Undecided,New] https://launchpad.net/bugs/1633913
<wxl> bdmurray: thanks. we've been discussing what's up with that. it's a little unclear.
<bdmurray> wxl: was xnox's comment not clear re the test case being missing?
<wxl> bdmurray: i guess what i'm saying is we have no idea what change precipitated it.
<bdmurray> wxl: the test case used to be there?
<xnox> bdmurray, there is more discussion about it here and testing channels; as in the stock "No Network" tests as used in Ubuntu might not be suitable for Lubuntu.
<wxl> bdmurray: yeah obviously the tests are something that need to be added, but that doesn't necessarily fix the problem at hand, which i'm a bit more concerned about at this point.
<bdmurray> Okay, I hadn't seen the previous discussion and only looked at the bug. I justed wanted to make sure it was being discussed.
<flocculant> xnox:  on the other hand almost all of the install testcases say "Available options should represent the state of your system accurately" and the first option relates to network. So if I booted and knew network was available - but didn't see the Download updates option - then I would fail the test
<xnox> flocculant, the problem is that for a year, nobody did an offline test of lubuntu - e.g. start a VM without a network interface.
<xnox> everybody seems to configure network / wifi; or use VMs with networking
<flocculant> xnox: ohh I see - that's not something that we test either
<xnox> flocculant, well, for ubuntu desktop there is a run-once "No Network" install test cases. and doing that for lubuntu would have caught the bug of not shipping a repository with debs sufficient to complete offline installs.
<flocculant> xnox: right - I see that now - was perhaps reading things odd here
 * flocculant wonders what happens for me 
<flocculant> no surprises
<flocculant> tsimonq2: so when I see this testcase and deal with that side - you want it added to http://iso.qa.ubuntu.com/admin/config/services/qatracker/testsuites/297/edit at the same time?
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.0-0ubuntu5 => 2:10.0.0-0ubuntu5.1] (openstack, ubuntu-server) (sync)
<tumbleweed> ./win 34
<tumbleweed> win 34
<slangasek> bdmurray: +1 for dropping purple altogether, then
<slangasek> bdmurray: fwiw I thought it was useful to know "this bug was verified for some series but not this one" because it seems like that's low-hanging fruit to get the verification done by prodding someone on the bug
<bdmurray> slangasek: okay
<tsimonq2> bdmurray: fwiw I filed a bug about adding the test before xnox said anything, I picked up on that.
<tsimonq2> flocculant: Which testcase?
<slangasek> bdmurray: should I also drop the remaining reference to 'purple' in the text?
<bdmurray> slangasek: refresh, I caught that in 1094
<slangasek> bdmurray: done and merged, thanks!
<tsimonq2> What's this do? http://people.canonical.com/~ubuntu-archive/package-team-mapping.json
<slangasek> it occupies space on a disk
<tsimonq2> XD
<tsimonq2> slangasek: What's the file mean?
<tsimonq2> What's it's purpose?
<slangasek> it provides a cache mapping source packages to teams which are considered owners of those packages, in Ubuntu main
<infinity> As far as I can tell, its purpose is to point out that Foudnations is the bug subscriber for way too many things.
<tsimonq2> lol :P
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.11 => 17.04.12] (ubuntu-mate)
#ubuntu-release 2017-04-20
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.38-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.36-dfsg-0ubuntu1.16.04.2 => 5.0.38-dfsg-0ubuntu1.16.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.38-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caja (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.1-0ubuntu2] (ubuntu-mate)
<LocutusOfBorg> where are new releases announced? Mark's blog or ubuntu-announce? (me is looking for the new AA codename :) )
<Laney> Mark's blog is where the name comes out first
<apw> LocutusOfBorg, marks blog first ...
<Laney> Then everyone goes AAAAAARGH and writes it into the 9999 places where it's hardcoded
<Laney> and thinks "we should do this better next time"
<LocutusOfBorg> loooool true sad story
<LocutusOfBorg> and next time the code will be hardcoded in even more places
<apw> we have about a 30 step checklist just for the kernel when a new name comes
<Laney> haha
<LocutusOfBorg> anyway, now that buildinfo is fixed in lp, I really hope to see the new dpkg out, and pie enabled everywhere for 17.10
<Ukikie> But only if pumpkin pie.
<LocutusOfBorg> when the toolchain is uploaded.... that would be a nice timing for doing it :)
 * apw would settle for a name
<Ukikie> He's trying to break the record for longest time without a codename.
<LocutusOfBorg> probably :)
<jbicha> Ukikie: at least it's not May yet! http://markshuttleworth.com/archives/1468
-queuebot:#ubuntu-release- Unapproved: ceph (trusty-proposed/main) [0.80.11-0ubuntu1.14.04.1 => 0.80.11-0ubuntu1.14.04.2] (core) (sync)
<xnox> can cloud-init in xenial-proposed be released?
<xnox> it's all green and had 9 days
<sil2100> xnox: I can take a look at that
<sil2100> Wow, that's a lot of bugs
<sil2100> xnox: it's on my plate, will release it once I browse through all the bugs, might take a minute as we have a meeting in 5 minutes
<xnox> sil2100, cool. note that i guess you want to release yakkety at the same time as xenial. thus all the bugs need to be checked that they were tested for both releases......
<xnox> /o\
<sil2100> Yeah, this is why it'll take a bit
<sil2100> xnox: hmmm, looking at LP: #1669504 now - seeing smoser's comment I see he tested it twice on xenial instead of once for xenial and once for yakkety
<ubot5> Launchpad bug 1669504 in cloud-init (Ubuntu Yakkety) "net/sysconfig.py is broken with ipv4 + ipv6 interfaces" [Medium,Fix committed] https://launchpad.net/bugs/1669504
<sil2100> Let me get more info on that from him
<sil2100> Ok, all clear
<sil2100> (regarding this bug of course)
<sil2100> Still a few to go
<xnox> slangasek, could you please try releasing systemd 232-21ubuntu3 from zesty-proposed into zesty? As per https://people.canonical.com/~ubuntu-archive/pending-sru.html all bugs are green.
<xnox> however there are a few autopkgtests flagged up
<xnox> snapd -> as far as I know they always fail, imho snapd should be ignored failure, no?
<slangasek> they are certainly not supposed to always fail
<xnox> but they have been for most of zesty, i thought they are expected to only pass on xenial
<slangasek> that is not at all the expectation
<xnox> given that core is not doing a zesty / 17 release
<slangasek> snapd is a package in the archive, it's how snaps are used on classic Ubuntu, and it is expected to work
<slangasek> please don't make excuses for failing autopkgtests - we will override them as necessary, but let's not make ourselves victims of low expectations
<xnox> i'm pretty sure it is not a new regression caused by my systemd SRU. http://autopkgtest.ubuntu.com/packages/snapd/zesty/amd64
<xnox> also it looks like latest snapd did pass
 * xnox ponders if I should rerun snapd+systemd together as triggers
<xnox> snapd/2.24+17.04 was clearly bad.
<slangasek> running together would be nice
<xnox> there is also dovecot/armhf open-iscsi/amd64 that look crazy
<slangasek> open-iscsi > grraaaaahh
<slangasek> xnox: can you take care of triggering the snapd reruns with 2.24.1+17.04+new systemd?
<nacc> a timeout, hrm ...
<xnox> yes
<slangasek> I'm retrying open-iscsi
<xnox> slangasek, retriggered snapd with systemd&snapd triggers on amd64, i386 and ppc64el. snapd is failing on armhf and s390x (lxc/lxd runner problem? snapd tests should be marked as isolation-machine?)
<slangasek> they almost certainly should, yes
<xnox> slangasek, looking at http://autopkgtest.ubuntu.com/packages/dovecot/zesty/armhf it appears to be unstable/flaky on armhf. As it flip flops between passing and failing.
<slangasek> yes, I've just retriggered that one again
<xnox> it tries to create sockets, that should be allowed under lxd.... (to test imap4s protocol)
<slangasek> yes, and it does other network tests successfully before that
<Laney> They have the appropriate restrictions as far as I know.
<slangasek> xnox: and then the systemd test failures are the infra issue mentioned?
<xnox> and now let's talk about systemd failing tests.
<xnox> amd64 failing only one test - upstream FAIL timed out.
<xnox> which fails with
<xnox> KVM: entry failed, hardware error 0x0
<xnox> EAX=00000000 EBX=00000000 ECX=00000000 EDX=000206a1
<xnox> due to nested kvm busted in on of the regions. But there is a confirmation from security team that tests no longer hang and all pass on the linked bug reprot.
<xnox> also it passed here https://bileto.ubuntu.com/excuses/2719/zesty.html
<xnox> ..
<xnox> armhf has root-unittests failing (still unfixed, that test failure is not a regression as previously reported by you)
<xnox> ..
<xnox> armhf & s390x have "boot-smoke" test failing which reboots the "machine", lxc/lxd container in this case, and expects no jobs (i.e. units that neither failed or managed to start, aka "starting") to be running after a time-out
<xnox> that fails in the containers, with spurious random things still not fully booted.
<sil2100> xnox: ok, as for cloud-init, still awaiting confirmation on some doubts on two of the verified bugs
<slangasek> xnox: systemd/armhf has been failing, revved my hint versions
<slangasek> xnox: fwiw I would also take mps against lp:~ubuntu-sru/britney/hints-ubuntu-zesty
<Laney> Is there any chance someone's going to look at those failures?
<xnox> well, i was fixing actually critical bug reports on supported architectures....
 * xnox pretends raspbery pi does not exist, and we don't have any products or clouds on armhf
<xnox> slangasek, can we drop armhf because it is not 2038 year safe?
<slangasek> xnox: we do. armhf is a supported ubuntu-core IoT architecture
<xnox> slangasek, correct, but it's not a product with support contracts.
<slangasek> that does not mean it's ignorable/droppable
<xnox> sil2100, fair enough. thank you for review!
<slangasek> infinity, xnox: wrt not badtest'ing systemd for the infra issue, I did exactly that for the version prior to release so that the continuing failures wouldn't hamstring other migrations.  I think that's equally correct here, and the hint should be dropped when the infra is fixed
<slangasek> last successful run was Mar 10
<infinity> slangasek: Well, it was also actually broken in systemd for the previous version.
<infinity> slangasek: This upload fixes that, but not the infra. :P
<infinity> slangasek: But I'm not picky.
<slangasek> actually broken how? I had it marked in my hint as 'regressed on infrastructure (timeouts)'
<Laney> The timeouts were not an infrastructure bug
<infinity> One is, one isn't.
<xnox> slangasek, test-12 did actually hang and there is ADT fix to resolve the hang of test-12 -> bug in systemd tests, not infra bug
<infinity> Because confusing.
<Laney> The nested KVM failure we're now seeing is a kernel bug that you can arguably call infrastructure
<slangasek> they were a test behavior change not correlated with a code change in systemd
<Laney> it's easy to see that one from logs
<infinity> slangasek: It was a change in netcat that broke the test.
<slangasek> ok
<slangasek> netcat-as-infrastructure
<xnox> slangasek, infinity: can we force good region for adt tests on amd64?
<infinity> Netcat As A Service?
<infinity> xnox: I don't think we have the ability to force regions, but ICBW.
 * Laney doesn't answer as he wasn't asked
<infinity> We can force VM sizes, which might accidentally pick a region, if only one has large? :P
<xnox> well Laney did trigger the tests in specific region before.
<infinity> Laney: Hey, can you answer the above? ;)
<Laney> The answer is no, and no to the m1.large thing
<Laney> I ran the tests manually
<xnox> i see.
<xnox> ....
<Laney> It wouldn't be so hard to add a hack to autopkgtest-cloud for this though
<Laney> If the region is lgw01 and the package is <nested kvm packages>, don't pick it up
 * xnox ponders to run the upstream tests twice, once with qemu and once with nspawn, such that we get results for both. And can exect fail qemu ones, if the nested KVM is borked.
<slangasek> Laney: is that a change you want to make, instead of me hinting the failure into oblivion?
<Laney> I can probably do that quickly
<Laney> Thinking of the nicest way to do it
<Laney> Perhaps I extend the blacklist syntax to take a region
<slangasek> Laney: ok. if you're going to do that, can I ask you to retry the test for zesty once implemented?  (and maybe you wanted that for a test case anyway)
<Laney> sure
<slangasek> if you'll do that, then I'll ignore the current failure for letting through the SRU (and not twiddle hints)
<xnox> slangasek, about armhf bug report.... i need shell on an armhf machine. I'm told there is something like diamond for armhf, no?
<slangasek> xnox: porter-arm64.internal?
<slangasek> and the armhf chroots therein
<xnox> ... and porter boxes will not give me root, these tests fail under root only
<slangasek> you said shell
<xnox> slangasek, ^
<slangasek> if you need root, talk to dannf
<xnox> root shell =)
<xnox> dannf, could you please give me *root* shell on armhf?
<slangasek> xnox: you mean arm64, with armhf chroot ;)
<slangasek> (otherwise you're not reproducing the testbed accurately anyway)
<xnox> dannf, that ^
<infinity> I'd like to fix that.  I wonder if I can find time.
<slangasek> fix what?
<infinity> ("that" being the lack of actual armhf VMs in scalingstack/autopkgtest)
<infinity> It's not like it isn't doable, it's just a bit of effort.
<slangasek> and miss out on all the beautiful sigbus?
<infinity> We can make it sigbus too.
<infinity> For real armhf kernels, it's a proc twiddle.
<slangasek> xnox: any chance you want to help the other systemd SRUs through while you're at it?
<xnox> slangasek, i could.
<xnox> i did see them....
 * xnox needs to update packaging branches too, I guess to not loose it.
<dannf> xnox: yeah, i should be able to give you access to a maas for that.
<xnox> dannf, and a maas handbook =)
-queuebot:#ubuntu-release- Packageset: 6714 entries have been added or removed
<Laney> slangasek: ok, done, and both open-iscsi and systemd retried and landed on lcy01 this time
<Laney> annoyingly I think they landed there by chance and didn't actually exercise the new codepath
<Laney> still, hope they work
<Laney> guess I should try to do this for systemd-upstream too
<infinity> Laney: Time to teach autopkgtest about artful.
<Laney> Not now, time to go out.
<Laney> I'll do things first thing tomorrow
<Laney> I've not done a new release for autopkgtest before. Going to be fun. :)
<infinity> Kay.  I'll keep us frozen until that, because no britney = no fun.
<infinity> But at least people will have a queue to throw things at.
 * Laney gets scared at the lack of documentation for this on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure
<infinity> Laney: You'll be fiiiiine.
<Laney> I know about the seed-things-and-stuff script
<infinity> Laney: I'm also sure that pitti won't mind taking some time to help you out.
<Laney> Yeeeeeeeeeeah, what could go wrong?
<Laney> It'll be okay, I can trigger test runs as long as the archive exists
<infinity> The archive exists as of now.
<infinity> It'll even be in a usable state a bit later than now.
<Laney> Well job.
<Laney> Right, ttyl
<Laney> WOAH.
 * Laney fixes that messed up commit first
<infinity> Laney: Before you go... Remind me of something.
<infinity> Laney: For things I upload today, before autopkgtesting is ready, can we tell britney tomorrow to trigger tests for it all?
<infinity> Laney: Oh.  Nevermind.  I answered my own question, sort of.  We can just not enable britney for artful until after autopkgtesting is good to go, then all those uploads will be "new" in britney's mind.
<Laney> infinity: If there's a block-all source then tests won't get triggered either
<infinity> Which there currently is.
<infinity> So that works.
<Laney> Super sick safe solid sound
<Laney> BYE
<wxl> so we're officially artful aardvark? say it's not true
<cjwatson> aardvark never hurt anyone.
<wxl> yes, but artful? now we set ourselves up for trouble if we don't have the most gorgeous release ever XD
<Bashing-om> wxl: artful ?? we gonna call it arty ?
<wxl> yeah, that too
<jbicha> wxl: artful isn't just about art though
<wxl> um
<wxl> yes you can take liberties with the definition..
<jbicha> https://en.oxforddictionaries.com/definition/artful
<cjwatson> yeah, it's not so much taking liberties with the definition as, well, just being the definition.
<cjwatson> think the artful dodger :)
<wxl> question: do the bittorrents and/or zsync options that we publish use the published hash values to check the integrity of the downloaded file?
<wxl> i.e. are that somehow susceptible to man in the middle attacks?
<mdeslaur> is the publisher stopped, or just saturated from artful opening?
<infinity> mdeslaur: The latter.  It's thinking very, very hard.
<mdeslaur> thanks infinity
<infinity> wxl: torrents and zsync could be MitM, but you're meant to check the results against the signed hashes, just as you would for an http or rsync download.
<infinity> wxl: The transport is not going to save you from actually looking at the result.
<xnox> slangasek, just dovecot/armhf and systemd/armhf red now
<xnox> retried tests are all green (e.g. snapd on the three good arches)
<xnox> release?
<slangasek> xnox: dovecot just finished retrying and passed; systemd/armhf I had added a hint to but possibly forgotten to push; yeah releasing now
<xnox> winning
<slangasek> infinity: ^^ do I need to worry about the forward-copy to artful-proposed?
<infinity> slangasek: No.
<slangasek> ok
<infinity> slangasek: I'll do the world in a batch once the archive is done hating me.
<slangasek> infinity: so I do need to worry about not deleting it out of zesty-proposed, which is more what I was getting at :)
<infinity> slangasek: I'm smart enough to be able to fish things out of updates too.
<slangasek> ok
<infinity> For some value of both "smart" and "enough".
<slangasek> xnox: btw looks like there was also a lost test for freeipa/armhf ... that shows up in update_excuses but not the pending SRU report
<tumbleweed> err, where are we getting the name artful from? I don't see a sabdfl blog post?
<wxl> the repos, tumbleweed
<tumbleweed> so release team is now picking names?
 * wxl shrugs
<tumbleweed> but yeah, I see we have https://launchpad.net/ubuntu/artful so I guess I can update distro-info-data appropriately
<infinity> tumbleweed: Some of us talk to Mark via means other than his blog.
<tumbleweed> if there  isn't a big reveal, does that mean we can get names out of him sooner?
<infinity> tumbleweed: Can't say. :P
<tumbleweed> :P
<infinity> tumbleweed: My process for pestering him (and his response to said pestering) changes subtly from release to release.  I make no promises about the future.
<tumbleweed> sounds about right
<infinity> So far, his response has not been "holy crap you're annoying and, also, fired", so I think I'm winning.
<slangasek> infinity: is publishing currently on hold during opening?  imma waiting for an SRU to land
<infinity> slangasek: Not on hold, just dog slow.
<slangasek> ack
<infinity> slangasek: Methinks the LP DB servers need to learn to shove a whole new set of indexes in RAM/bcache.  They should learn soon enough.
<tumbleweed> does October 12 sound reasonable as a release date? it's the second thursday
<cyphermox> I'm happy to start writing the ReleaseSchedule page if nobody is already doing it.
<infinity> tumbleweed: It should be 26 weeks from now, looking at our current cadence.
<infinity> (April is meant to be 27 and October 25, but 17.04 was 26 due to Easter, so 26 for 17.10 would put us back on track)
<infinity> cyphermox: Feel free to copy/waste and fill in the blanks.  They should almost line up exactly with last cycle.
<cyphermox> yup
<infinity> tumbleweed: Assuming I can count, I think the 12th is right.
<tumbleweed> infinity: right, I think that makes October 12th correct
<tumbleweed> infinity: and EOL is then something like 2018-07-12
<infinity> EOL is always a bit fudgy anyway, but yeah that sounds close enough.
<infinity> "Exactly 9mo" is certainly the date people should be expecting.
<infinity> If I give them a free 3 days, that's a bonus. :P
<jbicha> tumbleweed: please let's do end of October
<tumbleweed> not my call :)
<tumbleweed> I'm just trying to predict what we'll do
<jbicha> I would like us to align better with https://wiki.gnome.org/ThreePointTwentyfive
<jbicha> GNOME pushed their release schedule forward a week this time just for Ubuntu (even before the Big Announcement)
<jbicha> if we pushed Artful back to at least Oct 19, then there's a full week to get 3.26.1 in (if we go GNOME 3.26) before the release
<jbicha> otherwise, it takes a few weeks to get the .1 SRUs published
<infinity> jbicha: Oct 4 -> Oct 12 should be more than enough time to rev the world? :)
<infinity> Well, Oct 4 -> Oct 7 or something.
<infinity> Oct 2, if "tarballs due" really means they'll all exist.
<infinity> Easter 2018 is Apr 1, so we could perhaps push back by a week across the board.  I do want a 27wk cycle for 18.04, though.
<infinity> Which had to still happen in April.
<infinity> Because 04.
<jbicha> for 3.24.1, it looks like gdm and gnome-session tarballs appeared on Wednesday and gnome-shell/mutter appeared on Tuesday of 3.24.1 release week
<jbicha> zesty was released on Thursday so that felt way too risky to be messing with those components that late
<infinity> (base)adconrad@nosferatu:~$ date -d 'october 12 27 weeks'
<infinity> Thu Apr 19 00:00:00 MDT 2018
<infinity> (base)adconrad@nosferatu:~$ date -d 'october 19 27 weeks'
<infinity> Thu Apr 26 00:00:00 MDT 2018
<infinity> So, if we do a 27wk schedule for 18.04, we release on the 26th.  Which is doable.
<infinity> Assuming a 27wk schedule for 17.10
<infinity> Then we'd go back to 25/27, ish.
<infinity> Except that Easter keeps breaking that every couple of years.
<infinity> Stupid 4-day weekend.
<jbicha> I would be happier if we never did early October again actually
<infinity> The point of 25/27 is that we lose a ton of development time over the year-end break.
<infinity> So 25/27 makes up for that, to a degree.
<jbicha> right, I remember the 10.10.10 release cycle; I'm skeptical of that theory though
<infinity> (base)adconrad@nosferatu:~$ date -d 'Thu Apr 26 00:00:00 MDT 2018 25 weeks'
<infinity> Thu Oct 18 00:00:00 MDT 2018
<infinity> Keeping that cadence would put us just past mid-October for 18.10.
<infinity> And then back to Apr25 for the next 04.  Which will break because Apr 21 easter.
<infinity> But that can be another 26 to compensate.
<infinity> Whee.
<infinity> So, I think what works here is "27wk Oct 19, 2017", "27wk Apr 26, 2018", "25wk Oct 18, 2018", "26wk Apr 18, 2019"
<infinity> And I refuse to plan further out than that.
<infinity> ^--- Thoughts, emotional responses?
<jbicha> and I would be happy with that, thanks! :)
<infinity> slangasek: ^-- Can I get a +1 on that?  Note the 19.04 release is 26wk due to Easter being the following weekend, like this year.  Easter 2018 is a more convenient Apr 1.
<infinity> cyphermox: Please toss the above scratch notes in the comments for AA/ReleaseSchedule, so we can crib from it when expanding to proper wiki pages.
<jbicha> I think the SRU team would be happier with fewer big SRUs immediately after release
-queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.0-0ubuntu1 => 1.48.2-0ubuntu0.1] (desktop-extra, mozilla, ubuntugnome)
<infinity> jbicha: The SRU team would be happy if no one ever uploaded SRUs.  Our users, however, would not.
<infinity> Clearly, we should fire our users.
<tsimonq2> infinity: You or someone else should possibly consider updating that topic :P
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty 17.04 | Archive: closed | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<infinity> I feel like "Artful Release Coordination" is an accurate description of what we do, and the topic need never change again.
<tsimonq2> XD
<tsimonq2> On another releasey related thing, I've been getting this recently after running sudo apt update: W: Conflicting distribution: http://us.archive.ubuntu.com/ubuntu devel InRelease (expected devel but got artful)
<tsimonq2> (but before, s/artful/zesty/
<tsimonq2> )
<infinity> Yeahp, that's a known misfeature.
<infinity> Using devel in sources.list isn't entirely sane.
<infinity> We might need to teach apt to relax that check or something, if people really want to use it.
<tsimonq2> infinity: Why isn't it sane? :P
<tsimonq2> And what's the issue? I want to file a bug. :P
<infinity> Well, I'm unconvinced that the "devel" symlink existing at all is sane.  But I lost the argument.
<infinity> That aside, though, it's just slightly not sane because of the tool issues you've noticed.
<tsimonq2> How can we fix these tool issues?
<infinity> Either by making apt less picky or by making the publisher right a separate Release file for devel (which would also imply devel not being a symlink anymore, but perhaps a hardlink farm)
<infinity> It's not something any of us have wasted much energy planning to fix.
<infinity> s/right/write/  I can't brain right now.
<infinity> It gets trickier for PPAs, since they're not forced to republish like the primary archive is.
<tsimonq2> infinity: ack
<tsimonq2> Republish?
<infinity> So PPAs that haven't been touched for 7 months have "devel" pointing to yakkety.
<infinity> Which is super gross.
<tsimonq2> EEW
<tsimonq2> I agree.
<infinity> This all came about when people were faffing on about "rolling" and how that was the New Hotness, and all cool distros "roll".
<infinity> The devel symlink was the compromise.
<infinity> But I consider it a failed experiment, and maybe we should just revert it.
<jbicha> Please reject gjs 1.48.1-0ubuntu1/zesty since it's been superseded by 1.48.2
<tsimonq2> infinity: Side note, I think it would be Super Duper Awesome if PPAs could act as their own mini archive. Like, you turn on an option and it enables britney etc. Just putting the idea out there. :P
<tsimonq2> Anyways, shiny squirrel.
<tsimonq2> infinity: Well I like to keep my sources.list on devel because I like that illusion. :P
<tsimonq2> But hey, it's worth the discussion if you want, infinity?
<infinity> tsimonq2: PPAs can do that, sort of.  It's functionality external to LP.
<infinity> tsimonq2: But it's something we're not currently dedicating resources to improving or making more widespread or self-serve.
<infinity> jbicha: That's... Weird.  The delta from 1.48.0 to 1.48.1 was 223K, the delta from 1.48.0 to 1.48.2 is only 22K.  Did they revert a mess of stuff from .1 to .2?
<infinity> Or maybe that's just all autotools vomit from .1 being built with a different version than .0 and .2
<jbicha> I blame autotools
<jbicha> the good news (?) is that many GNOME modules will switch to meson for 3.26 or 3.28 so there won't be all that junk in the diffs any more
<infinity> jbicha: Yeah, automake 1.14 versus 1.15, looks like.  Whee.
<jbicha> can I talk you into accepting gjs while you're looking at it?
<infinity> jbicha: I don't know what meson is, but if it's Yet Another Attempt to Replace Autoconf, I'll be skeptical.
<infinity> cmake only took a decade to almost sort of work, ish.
<jbicha> http://mesonbuild.com/
-queuebot:#ubuntu-release- Unapproved: rejected gjs [source] (zesty-proposed) [1.48.1-0ubuntu1]
<jbicha> it's written in Python and it's from Jussi Pakkanen
<infinity> jbicha: Yeah, looks like it has the same goals as cmake.  And will probably end up with the same mess of out-of-tree modules and horrible gotchas as people realise the default doesn't work for their use case.
<infinity> jbicha: But oh well.
<infinity> If it works for GNOME, cool for them.
<infinity> ("written in python" and "fast" is a bit of a disconnect, though)
<tsimonq2> infinity: Would you be okay with me creating the ArtfulAardvark wiki page?
<infinity> tsimonq2: Go for it.
<infinity> mdeslaur: I see a bunch of security pockets doing publishy things now, you should be in a happier place soon.
<infinity> jbicha: Do you want me to test this in a devirt PPA for you before I accept it and it fails? :P
<jbicha> infinity: yes please
<infinity> jbicha: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<tsimonq2> infinity: https://wiki.ubuntu.com/ArtfulAardvark
<tsimonq2> infinity: Looks like cyphermox already created the ReleaseSchedule page.
<slangasek> infinity: +1 on the release schedule question above; awkward that it throws us off the 25/27 right after we agreed to it, but seems like the right thing there
<infinity> slangasek: Yeah, rules are made to be broken.
<infinity> slangasek: Easter will forever be a thorn in our side (or crown?) unless we slip the whole shebang to 05/11
<slangasek> not to be confused with heimdal's debian/rules, which makes libroken
<infinity> I prefer libiberty.
<tsimonq2> infinity, slangasek: Question: Are there plans to align our release schedule with GNOME's a bit more, now that GNOME is going to be the default desktop?
<tsimonq2> Or is it already pretty aligned?
<jbicha> infinity: gjs built successfully :)
<mdeslaur> infinity: ah, yes, thanks!
<infinity> jbicha: So it did.  Yay.
<infinity> tsimonq2: It's always been more or less aligned, ever since we worked with them to align us all when they were our default desktop.
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (zesty-proposed) [1.48.2-0ubuntu0.1]
<infinity> tsimonq2: But we have to shuffle things around here and there for things like long weekends, so it's never perfect.
<infinity> tsimonq2: It's not a coincidence that we both release every 6mo in the same month.
<infinity> jbicha: "make[1]: Nothing to be done for 'test'."
<infinity> jbicha: That might explain it working everywhere.
<infinity> jbicha: (As in, there is no testsuite being run)
<tsimonq2> infinity: ack :)
<infinity> jbicha: So, I expect the same autopkgtest failure on s390x.  Which, at a glance, looks like it might be an endian bug $somewhere.
<Ukikie>  /lastlog distro-i
<Ukikie> Erm.
#ubuntu-release 2017-04-21
<mwhudson> infinity: when can i start doing go 1.8 transitions bits for artful? (not yet, i assume)
<infinity> mwhudson: Probably sometime tomorrow.
<infinity> mwhudson: Which I guess is the weekend for you, so Monday?
<mwhudson> monday for me then
<mwhudson> cool
<infinity> Jinx.
<tsimonq2> infinity: Apologies if it seems like I'm pushing too hard, but do we have an ETA as to when artful opens? :D
<infinity> tsimonq2: See above.
<infinity> tsimonq2: Though the exact time is extended by an hour every time someone asks.
<Ukikie> \o/
<Ukikie> infinity: So if I ping you every hour about it, can I extend it until release?
<infinity> Ukikie: Yup.
<Ukikie> Sweet!  I'm gonna cron it!  (Not really. :3 )
<infinity> Ukikie: I suppose it's a race then to see how quickly I'd get replaced, but I'm willing to take that chance.
<Ukikie> Ahaha. :D
<tsimonq2> infinity: What if I want to be evil and ask just enough times to land it at like 3 am Saturday morning with you being up all Friday? :P
<infinity> tsimonq2: I'm counting this as you asking again when it'll open.
<tsimonq2> infinity: XDDDD
<tsimonq2> LOL
 * tsimonq2 takes infinity's piece of chalk, runs up to the chalkboard, rambles to himself, makes a few tallies, then drops the chalk in a 50 gallon drum of hot water and sprints away
<tsimonq2> YAY base-files \o/ \o/ \o/ \o/ \o/ \o/
<tsimonq2> I'll see myself out... :P
<acheronUK> tsimonq2: damn. was going to post https://lists.ubuntu.com/archives/artful-changes/2017-April/000000.html
<tsimonq2> acheronUK: lol
-queuebot:#ubuntu-release- Unapproved: dpkg (artful-proposed/main) [1.18.10ubuntu2 => 1.18.23ubuntu1] (core)
<Ukikie> infinity: Thank you for the above.
-queuebot:#ubuntu-release- Unapproved: debhelper (artful-proposed/main) [10.2.2ubuntu1 => 10.2.5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (artful-proposed) [1.18.23ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debootstrap (artful-proposed/main) [1.0.81ubuntu3 => 1.0.81ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: binutils (artful-proposed/main) [2.28-3ubuntu1 => 2.28-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-6 (artful-proposed/main) [6.3.0-12ubuntu2 => 6.3.0-14ubuntu2] (core)
<infinity> tumbleweed: Not a huge deal, but your dates for zesty release and artful rollover are a week late (which I guess is why my tools only starting hating me today instead of release day :P)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (artful-proposed/main) [0.33 => 0.34] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (artful-proposed) [10.2.5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dpkg (artful-proposed/main) [1.18.10ubuntu2 => 1.18.23ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (artful-proposed) [1.18.23ubuntu2]
<tumbleweed> infinity: I was wondering why things seemed busy here a week ago :P
-queuebot:#ubuntu-release- Unapproved: dpkg (artful-proposed/main) [1.18.23ubuntu2 => 1.18.23ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (artful-proposed) [1.18.23ubuntu3]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.6 => 0.18ubuntu0.7] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.2 => 0.28ubuntu0.3] (core)
-queuebot:#ubuntu-release- Unapproved: debhelper (artful-proposed/main) [10.2.5ubuntu1 => 10.2.5ubuntu2] (core)
<infinity> tumbleweed:
<infinity> +    - Fix EOL date of Ubuntu 17.04 (9 months, not 18)
<infinity> tumbleweed: I see no such change in the actuall diff.
<infinity> (That is, the EOL was correct both before and after)
<tumbleweed> yeah, I just realised that
<tumbleweed> if you want to drop those 2, I can re-upload
<infinity> Will do.
<tumbleweed> the yakkety one I just uploaded has the rgiht changelog
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (trusty-proposed) [0.18ubuntu0.7]
<infinity> tumbleweed: Rejectified.
-queuebot:#ubuntu-release- Unapproved: distro-info-data (yakkety-proposed/main) [0.29ubuntu0.1 => 0.29ubuntu0.2] (core)
<tumbleweed> I trusted the "Copy data from 0.30" previous changelog entry :)
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (xenial-proposed) [0.28ubuntu0.3]
<infinity> tumbleweed: Thank you for using Adam's rejection service.  We understand you have a choice in which archive admin will flip your packages the bird, and we appreciate your loyalty.
<tumbleweed> lol, I must take advantage of this more often :)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.6 => 0.18ubuntu0.7] (core)
<infinity> (I might be losing my mind after a couple of days of reconciling dpkg and debhelper bugs/misfeatures to get them to behave the way I need them to)
 * tsimonq2 hands infinity a cup of coffee
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.2 => 0.28ubuntu0.3] (core)
<infinity> On the plus side, I now have a handy test package called "bollocks" that produces "bollocks.deb, bollocks-udeb.udeb, and bollocks-dgbsym.ddeb".
<Ukikie> infinity: May I ask why you strip buildinfo from changes?
<infinity> Ukikie: Because the LP buildinfo support turned out to be buggy.  I'll revert that revision after Colin fixes the infra.
<infinity> Ukikie: Should be back on in a few days, I imagine.
<Ukikie> Ah fantastic, sounds great.  Thanks muchly!
<Ukikie> Yeah that's fine, I was just hoping this wouldn't diverge.  As long as it doesn't release with it, is what I was looking forward to. :)
<Ukikie> (Sounds fun, LP breaking. :3 )
-queuebot:#ubuntu-release- Unapproved: distro-info-data (zesty-proposed/main) [0.33 => 0.33ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (artful-proposed) [10.2.5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: debhelper (artful-proposed/main) [10.2.5ubuntu1 => 10.2.5ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (artful-proposed) [10.2.5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (yakkety-proposed) [0.29ubuntu0.2]
<infinity> tumbleweed: All accepted.  Lemme know when you've verified they actually work.
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (zesty-proposed) [0.33ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (artful-proposed) [0.34]
<tumbleweed> infinity: righto, thanks
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (artful-proposed) [1.0.81ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (artful-proposed) [2.28-4ubuntu1]
<tumbleweed> infinity: all verified
<infinity> tumbleweed: Shiny.
<infinity> tumbleweed: All released.
<tumbleweed> thanks
<cpaelzer> the qemu SRU 2.5+dfsg-5ubuntu10.11 in xenial unapproved got surpassed by a security update
<cpaelzer> I'm re-preparing with a new version number
<cpaelzer> does this need to be rejected in the queue, or will a sync of a newer one just supersede it?
<apw> cpaelzer, if there is something in the queue which is definatly bad, rejecting it is best then it cannot be accepted by accident
<cpaelzer> apw: yeah if accepted now (that the sec update is in) it will at best version conflict and the new version is building
-queuebot:#ubuntu-release- Unapproved: rejected qemu [sync] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.11]
<apw> cpaelzer, ^
<cpaelzer> thanks!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-49.52] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-75.96~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-49.52~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-20.22~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-75.96] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-20.22~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-75.96]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-49.52~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-49.52]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-75.96~14.04.1]
<xnox> slangasek, on Ubuntu system, after $ sudo apt install debian-archive-keyring; do you expect for apt to trust all debian signing keys?
<xnox> or do you expect for them to be /available/ but not trusted.
<sil2100> hm, is there anything wrong with autopkgtests? http://autopkgtest.ubuntu.com/running gives me 'A server error occured' and my ubuntu-image PR didn't get tests run (still waiting)
<Laney> I'm updating it for artful, wait a few minutes.
<sil2100> ACK
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (artful-proposed) [6.3.0-14ubuntu2]
<infinity> xnox: I'd expect them to be trusted.
<xnox> ok
<infinity> Though I'm questioning why they're in xubuntu-desktop, ubuntustudio-desktop ...
<xnox> infinity, i think in the past, the /etc/apt/trusted.gpg was not updated with debian keys upon installing debian-archive-keyring, now they are shipped as snippets in /etc/apt/trusted.gpg.d and are trusted.
<xnox> but i need to verify that claim on something old.
<xnox> also i'm still pondering if /etc/apt/trusted.gpg.d/* key snippets should be conffiles or not.
<infinity> xnox: We never modified the package on import from Debian, so I imagine it was added to the system keyring before it was switched to snippets.
<xnox> i believe it used to call apt-key, which has a different master keyring for the apt-key update. and the ubuntu/debian master keyrings were encoded in apt-key, and thus src:apt
<xnox> but yeah, need to re-verify this.
<infinity> xnox: As for them being conffiles, it means the local admin can delete a key hey doesn't like and upgrades respect that.
<infinity> xnox: But yeah, I could see arguments for not trusting it.  I'd want that pushed back to Debian, though (ie: some dpkg-vendor magic to install to /etc/apt on Debian and /usr/share on Ubuntu) cause carrying a delta forever on a package we fundamentally don't care about is icky.
<xnox> yes.
<infinity> xnox: Well, /etc/apt on Debian, and /usr/share on *all* non-Debian derivatives seems the sensible split there.
<xnox> infinity, well, they still ship /usr/share/keyrings/debian-archive-keyring.gpg and /usr/share/keyrings/debian-archive-removed-keys.gpg
<xnox> and things like facy cowbuilders / pbuilders / schroots what not use that to authenticate debian debootstraps
<infinity> Ahh.  So it would just be a matter of not shipping the conffile ones.  Sure.  Same argument, though.
<xnox> yeap.
<xnox> i will follow up with debian about it, after verifying past behaviour.
<infinity> xnox: From my POV, my carefactor is low.  We implicitly trust Debian in so many ways that it doesn't bug me.  But not trusting their binary archives by default at least is maybe a small deterrent to users accidentally shooting themselves in the foot by installing from them?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-20.22] (core, kernel)
<xnox> it's 7 more keys we do not control, which can be compromised and execute impersanation attack on all ubuntu zesty systems.
<xnox> which have that package isntalled.....
-queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.3+git50-g3c0349b-2 => 3.4-1] (ubuntu-desktop, ubuntu-server) (sync)
<infinity> xnox: Yeah, the security surface bugs me a lot less than it bugs you.  If Debian had a key compromised, I think we'd all care even if no one used it to attack Ubuntu users. :P
<infinity> xnox: And we'd sort it ASAP.
<xnox> infinity, also I do not see it in the xubuntu-desktop =)
<xnox> where do you see that?
<infinity> $ apt-cache show debian-archive-keyring | grep ^Task
<infinity> Task: xubuntu-desktop, ubuntustudio-desktop
<infinity> Being pulled in as a dep of something else, I'm sure.  Didn't look closely.
<xnox> fun. the metapackage does not have it directly.
<xnox> =/
<xnox> yeah.
<infinity> Laney: Oh, your assertion that "block-all source" would prevent tests being triggered is clearly untrue, as all stable series' have that hint in place and get tests.
<infinity> Laney: But I haven't made britney run for artsy yet, so no big deal.
<infinity> (Working on that after I sort out why I'm awake at 6am)
<Laney> infinity: Oh well.
<Laney> They won't work anyawy, since no cloud image and no LXD image.
<xnox> Laney, i thought for archive opening pitti would do some hack to copy zesty images locally somehow and tweak the sources.
<xnox> or i wonder if Odd_Bloke can magically build artful images for us =)
<Laney> I know. I could do that for cloud images if there weren't 9999 jobs running.
<xnox> yeah =)
<Laney> Don't really fancy doing it for lxd though.
<Laney> Maybe stgraber can turn that on quickly.
-queuebot:#ubuntu-release- Unapproved: debootstrap (zesty-proposed/main) [1.0.81ubuntu3 => 1.0.81ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.28+17.04 => 2.29+17.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debootstrap (yakkety-proposed/main) [1.0.81ubuntu2.1 => 1.0.81ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.28+16.10 => 2.29+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.2 => 1.0.78+nmu1ubuntu1.3] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (trusty-proposed/main) [1.0.59ubuntu0.6 => 1.0.59ubuntu0.7] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (precise-proposed/main) [1.0.40~ubuntu0.11 => 1.0.40~ubuntu0.12] (core)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.28 => 2.29] (no packageset)
<apw> sergiusens, hey does that snapcraft upload for zesty fix the ADT test failures, the hard version on package hello ?
<apw> sergiusens, i assume not as there is no delta from yakkety to zesty
-queuebot:#ubuntu-release- Unapproved: devscripts (artful-proposed/main) [2.16.8ubuntu2 => 2.17.5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (artful-proposed) [2.17.5ubuntu1]
<slangasek> xnox: I have debian-archive-keyring installed here on my laptop; therefore, no
<xnox> slangasek, can you expand on the "therefore no"?
<xnox> slangasek, or you mean you run debian =)))))
 * xnox exposes slangasek 
<slangasek> xnox: I have it installed, I don't recall why, but I definitely don't have it installed with the intent of trusting Debian sources
<xnox> ack
<xnox> slangasek, you have it installed because you installed ubuntu-dev-tools
<slangasek> ok
<slangasek> then I *definitely* don't want apt trusting it just because
 * apw reviews zesty gnome bits ...
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (zesty-proposed) [3.24.1-0ubuntu1]
<apw> jbicha, gnome-control-center seems to have some alsa bits in it, is that right ?
<sergiusens> apw: yes it does -> the SRU but has a link to this, but here is my home work https://forum.snapcraft.io/t/in-progress-snapcraft-2-29/346?u=sergiusens
<sergiusens> apw: all adt runs for the final commit that made this a deb to dput are documented there
<sergiusens> apw: I would appreciate this being accepted, we can all be happy with the green in there ;-)
<jbicha> apw: yes, that's mentioned (briefly) in LP: #1682138 as changes to the Sound panel
<ubot5> Launchpad bug 1682138 in gnome-control-center (Ubuntu) "Update gnome-control-center to 3.24.1" [Medium,In progress] https://launchpad.net/bugs/1682138
<apw> sergiusens, so did you remove the hello=version in the snapcraft.yaml's in the tests ?  as they would have to differ now in zesty and yakkety and do not seem to
-queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [source] (zesty-proposed) [3.24.1-0ubuntu1]
<apw> jbicha, thanks
<sergiusens> apw: no, I use an rmadison style of check to get the version for hello
<jbicha> apw: it comes from the 2 libgnome-volume-control commits (which aren't loading for me right now)
<sergiusens> apw: https://github.com/snapcore/snapcraft/pull/1269/files
<apw> sergiusens, thanks that covers it ...
<apw> sergiusens, will re-review those after i've done the gnome ones
<stgraber> Laney: I'll sort out the LXD images (images: remote)
<Laney> cheers
<jbicha> thanks
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (zesty-proposed) [1:3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (zesty-proposed) [3.24.1-0ubuntu1]
<apw> jbicha, ^ ok i think that is all the gnome PR bits accepted ... have fun testing
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.29+17.04]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-20.22]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.29+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.29]
<apw> sergiusens, ^ all yours
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (zesty-proposed) [0.6.4-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (zesty-proposed) [2:10.1.5-5055683-1ubuntu1.1]
<sergiusens> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (zesty-proposed) [17.04.12]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-autohidetopbar [source] (zesty-proposed) [20161203-1ubuntu1]
<apw> acheronUK, hey ... i take it the version change is expected
<acheronUK> apw: k3b? yes. previous git snapshots were that 17.04 stable branch in reality anyway. now using that release tarball instead, we can call it what it really is
-queuebot:#ubuntu-release- Unapproved: accepted k3b [source] (zesty-proposed) [17.04.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-tx-tftp [source] (zesty-proposed) [0.1~bzr47-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected caja [source] (zesty-proposed) [1.18.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.0-0ubuntu5 => 2:10.0.0-0ubuntu5.1] (openstack, ubuntu-server)
<Laney> autopkgtest is good now
-queuebot:#ubuntu-release- Unapproved: rejected neutron [sync] (zesty-proposed) [2:10.0.0-0ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.0-0ubuntu5.1]
<infinity> Laney: Excellent.
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (zesty-proposed) [1.0.81ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (precise-proposed) [1.0.40~ubuntu0.12]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (trusty-proposed) [1.0.59ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (yakkety-proposed) [1.0.81ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: dpkg (artful-proposed/main) [1.18.23ubuntu3 => 1.18.23ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (artful-proposed) [1.18.23ubuntu4]
<stgraber> stgraber@castiana:~$ lxc image list images: | grep artful
<stgraber> | ubuntu/artful (3 more)          | 81b35bcddd7f | yes    | Ubuntu artful amd64 (20170421_14:51)     | x86_64  | 81.99MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> | ubuntu/artful/arm64 (1 more)    | baf9f38b9100 | yes    | Ubuntu artful arm64 (20170421_14:51)     | aarch64 | 75.98MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> | ubuntu/artful/armhf (1 more)    | f47e3c98e88c | yes    | Ubuntu artful armhf (20170421_14:51)     | armv7l  | 77.37MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> | ubuntu/artful/i386 (1 more)     | 64479ceb774a | yes    | Ubuntu artful i386 (20170421_14:51)      | i686    | 82.68MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> | ubuntu/artful/ppc64el (1 more)  | 53ffa4274eb1 | yes    | Ubuntu artful ppc64el (20170421_14:51)   | ppc64le | 80.38MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> | ubuntu/artful/s390x (1 more)    | 9e0cca6b9f75 | yes    | Ubuntu artful s390x (20170421_14:51)     | s390x   | 77.33MB  | Apr 21, 2017 at 12:00am (UTC) |
<stgraber> Laney: ^ very much untested
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (artful-proposed/universe) [17.04.12 => 17.10.0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.6-0ubuntu1~16.04.1 => 2.2.9-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.6-0ubuntu1 => 2.2.9-0ubuntu1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.6-0ubuntu1~16.10.1 => 2.2.9-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.6-0ubuntu1~14.04.1 => 2.2.9-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
<flexiondotorg> apw I see you rejected my SRU upload for Caja.
<flexiondotorg> I'm a bit confused, the bug is referenced in Changes.
<apw> flexiondotorg: it was referenced in the changelog but somehow not in .changes, and it is that the tools key off of
<apw> i don't know quite how that is possible
<flexiondotorg> I've download the change and the LP reference is there.
<apw> in .changes?
<flexiondotorg> From the rejection email, yes.
<infinity> flexiondotorg: It's not in .changes
<infinity> flexiondotorg: Did you build on Debian?
<flexiondotorg> infinity I built on Zesty.
<apw> flexiondotorg: in the changelog fragment or the foo-bugs: header
<apw> it is the latter which matters
<apw> and there was none to my eye
<flexiondotorg> I'll double check debian/changelog and rebuild.
<apw> check for a launchpad-bugs: header in _changes
<infinity> flexiondotorg: http://paste.ubuntu.com/24428437/
<infinity> flexiondotorg: When I regen your changes on zesty, I get that.
<infinity> flexiondotorg: Also, if you aren't a masochist, you might want to avoid "-sa".
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (artful-proposed/universe) [17.04.11 => 17.10.0] (ubuntu-mate)
<infinity> flexiondotorg: That just forces you to reupload .orig every time.
<flexiondotorg> infinity Not clear if I should I still re-upload?
<infinity> Well, I could upload this for you.  *shrug*
<flexiondotorg> I've done nothing different to how I'd normally upload, so I'm curious why this wasn't correctly formatted.
<infinity> Pretty much the only way to not get that header is for you to be running on !ubuntu.
<flexiondotorg> infinity I prepare uploads as follows: dpkg-buildpackage -d -S -sa
<infinity> Or for dpkg-vendor to not claim you're using Ubuntu.
<flexiondotorg> What would you suggest?
<infinity> flexiondotorg: Drop the '-sa' if you're uploading something that already has an orig in the archive, but that's not the source of this issue.  Just a convenience thing.
-queuebot:#ubuntu-release- Unapproved: caja (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.1-0ubuntu2] (ubuntu-mate)
<flexiondotorg> infinity I will re-upload and drop the '-sa'.
<infinity> flexiondotorg: I already did.
<flexiondotorg> Or not :-)
<infinity> See above.
<flexiondotorg> Thanks infinity.
<infinity> flexiondotorg: But, like I said, the '-sa' isn't the problem here, it's the lack of Launchpad-Bugs-Fixed: field.
<infinity> flexiondotorg: Which implies your dpkg-dev doesn't think you're using Ubuntu.
<flexiondotorg> Well, I've been uploading everything from that zesty VM for weeks, and some new packages for artful just now.
<infinity> flexiondotorg: Output of "dpkg-vendor --is ubuntu && echo Yay" and "ls -l /etc/dpkg/origins/" might be enlightening.
<flexiondotorg> infinity OK, found the issue.
<infinity> Colour me curious.
<flexiondotorg> I use direnv to switch DEBNAME, DEBEMAIL etc
<flexiondotorg> Because these packages are sent to Debian git direnv sets DEB_VENDOR="Debian"
<flexiondotorg> When in that directory tree.
-queuebot:#ubuntu-release- Unapproved: caja (artful-proposed/universe) [1.18.1-0ubuntu1 => 1.18.2-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: caja-extensions (artful-proposed/universe) [1.18.0-0ubuntu1 => 1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-icon-theme (artful-proposed/universe) [1.18.1-0ubuntu1 => 1.18.2-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (artful-proposed/universe) [1.18.0-0ubuntu1 => 1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.9 => 1.157.10] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164 => 1.164.1] (core, kernel)
<slangasek> infinity: I guess zesty-proposed -> artful-proposed copies aren't done yet?
<slangasek> (don't know where this is on the list without digging it up; vaguely interested in having the pending-sru report restored to sanity)
-queuebot:#ubuntu-release- Unapproved: acl (artful-proposed/main) [2.2.52-3 => 2.2.52-3build1] (core)
-queuebot:#ubuntu-release- Unapproved: aspell (artful-proposed/main) [0.60.7~20110707-3build1 => 0.60.7~20110707-3build2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: acpid (artful-proposed/main) [1:2.0.26-1ubuntu2 => 1:2.0.26-1ubuntu3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: attr (artful-proposed/main) [1:2.4.47-2 => 1:2.4.47-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: bcache-tools (artful-proposed/main) [1.0.8-2 => 1.0.8-2build1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cdrkit (artful-proposed/main) [9:1.1.11-3ubuntu1 => 9:1.1.11-3ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dctrl-tools (artful-proposed/main) [2.24-2 => 2.24-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: cron (artful-proposed/main) [3.0pl1-128ubuntu2 => 3.0pl1-128ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: diffstat (artful-proposed/main) [1.61-1 => 1.61-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: fcitx-configtool (artful-proposed/main) [0.4.8-3 => 0.4.8-3build1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dmraid (artful-proposed/main) [1.0.0.rc16-4.2ubuntu3 => 1.0.0.rc16-4.2ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: geoclue (artful-proposed/main) [0.12.99-4ubuntu1 => 0.12.99-4ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gfxboot (artful-proposed/main) [4.5.2-1.1-5 => 4.5.2-1.1-5build1] (core)
-queuebot:#ubuntu-release- Unapproved: gparted (artful-proposed/main) [0.25.0-1 => 0.25.0-1build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-system-log (artful-proposed/main) [3.9.90-4 => 3.9.90-4build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (artful-proposed/universe) [17.04.7 => 17.10.0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: gzip (artful-proposed/main) [1.6-4ubuntu1 => 1.6-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: irqbalance (artful-proposed/main) [1.1.0-2ubuntu1 => 1.1.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: ipvsadm (artful-proposed/main) [1:1.28-3 => 1:1.28-3build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: joyent-mdata-client (artful-proposed/main) [0.0.1-0ubuntu2 => 0.0.1-0ubuntu3] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libdumbnet (artful-proposed/main) [1.12-7 => 1.12-7build1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libpaper (artful-proposed/main) [1.1.24+nmu4ubuntu1 => 1.1.24+nmu4ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lsscsi (artful-proposed/main) [0.27-3 => 0.27-3build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lockfile-progs (artful-proposed/main) [0.1.17 => 0.1.17build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lupin (artful-proposed/main) [0.57 => 0.57build1] (core)
-queuebot:#ubuntu-release- Unapproved: min12xxw (artful-proposed/main) [0.0.9-9 => 0.0.9-9build1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: maas-enlist (artful-proposed/main) [0.4+bzr38-0ubuntu2 => 0.4+bzr38-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mlocate (artful-proposed/main) [0.26-1ubuntu2 => 0.26-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: mouseemu (artful-proposed/main) [0.16-0ubuntu9 => 0.16-0ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: mscompress (artful-proposed/main) [0.4-3 => 0.4-3build1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: mousetweaks (artful-proposed/main) [3.12.0-1ubuntu2 => 3.12.0-1ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: msr-tools (artful-proposed/main) [1.3-2 => 1.3-2build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: notify-osd (artful-proposed/main) [0.9.35+16.04.20160415-0ubuntu1 => 0.9.35+16.04.20160415-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: patch (artful-proposed/main) [2.7.5-1 => 2.7.5-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: pam (artful-proposed/main) [1.1.8-3.2ubuntu2 => 1.1.8-3.2ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: pcmciautils (artful-proposed/main) [018-8 => 018-8build1] (core)
-queuebot:#ubuntu-release- Unapproved: pkg-config (artful-proposed/main) [0.29.1-0ubuntu1 => 0.29.1-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: psmisc (artful-proposed/main) [22.21-2.1build1 => 22.21-2.1build2] (core)
-queuebot:#ubuntu-release- Unapproved: procmail (artful-proposed/main) [3.22-25 => 3.22-25build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pxljr (artful-proposed/main) [1.4+repack0-4 => 1.4+repack0-4build1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: quota (artful-proposed/main) [4.03-2 => 4.03-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: rasqal (artful-proposed/main) [0.9.32-1 => 0.9.32-1build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: raptor2 (artful-proposed/main) [2.0.14-1 => 2.0.14-1build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rfkill (artful-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu4] (desktop-core)
<infinity> slangasek: They're happening shortly.
-queuebot:#ubuntu-release- Unapproved: rtkit (artful-proposed/main) [0.11-4 => 0.11-4build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (artful-proposed/main) [1:4.3-3ubuntu2 => 1:4.3-3ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: sbc (artful-proposed/main) [1.3-1 => 1.3-1build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: syslinux-legacy (artful-proposed/main) [2:3.63+dfsg-2ubuntu8 => 2:3.63+dfsg-2ubuntu9] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: time (artful-proposed/main) [1.7-25.1 => 1.7-25.1build1] (core)
-queuebot:#ubuntu-release- Unapproved: tone-generator (artful-proposed/main) [1.5.4+15.10.20150731-0ubuntu1 => 1.5.4+15.10.20150731-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unity-lens-files (artful-proposed/main) [7.1.0+16.04.20151217-0ubuntu1 => 7.1.0+16.04.20151217-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: tinycdb (artful-proposed/main) [0.78 => 0.78build1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-geoip (artful-proposed/main) [1.0.2+14.04.20131125-0ubuntu2 => 1.0.2+14.04.20131125-0ubuntu3] (ubuntu-desktop)
<slangasek> infinity: sounds good
-queuebot:#ubuntu-release- Unapproved: unity-lens-music (artful-proposed/main) [6.9.1+16.04-0ubuntu1 => 6.9.1+16.04-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unity-scope-home (artful-proposed/main) [6.8.2+16.04.20160212.1-0ubuntu1 => 6.8.2+16.04.20160212.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unity-lens-video (artful-proposed/main) [0.3.15+16.04.20160212.1-0ubuntu1 => 0.3.15+16.04.20160212.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unzip (artful-proposed/main) [6.0-20ubuntu1 => 6.0-20ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: usbmuxd (artful-proposed/main) [1.1.0-2 => 1.1.0-2build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: uucp (artful-proposed/main) [1.07-23 => 1.07-23build1] (core)
-queuebot:#ubuntu-release- Unapproved: usbutils (artful-proposed/main) [1:007-4 => 1:007-4build1] (core)
-queuebot:#ubuntu-release- Unapproved: whoopsie-preferences (artful-proposed/main) [0.18 => 0.18build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: wireless-tools (artful-proposed/main) [30~pre9-8ubuntu1 => 30~pre9-8ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: x11-session-utils (artful-proposed/main) [7.7+2 => 7.7+2build1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: wvdial (artful-proposed/main) [1.61-4.1 => 1.61-4.1build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: x11-utils (artful-proposed/main) [7.7+3 => 7.7+3build1] (core)
-queuebot:#ubuntu-release- Unapproved: xdg-user-dirs (artful-proposed/main) [0.15-2ubuntu6 => 0.15-2ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: x11-xserver-utils (artful-proposed/main) [7.7+7 => 7.7+7build1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xdg-user-dirs-gtk (artful-proposed/main) [0.10-1ubuntu1 => 0.10-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: zip (artful-proposed/main) [3.0-11 => 3.0-11build1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xinput (artful-proposed/main) [1.6.2-1 => 1.6.2-1build1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted zip [source] (artful-proposed) [3.0-11build1]
-queuebot:#ubuntu-release- Unapproved: vlc (artful-proposed/universe) [2.2.4-14ubuntu2 => 2.2.5-1] (mozilla, mythbuntu, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: vlc (artful-proposed/universe) [2.2.4-14ubuntu2 => 2.2.5-3] (mozilla, mythbuntu, ubuntu-mate) (sync)
<tsimonq2> The person who did that looked at my bug, thank you whoever that is :D
<tsimonq2> (vlc)
<tsimonq2> For the record, it's not urgent to get in right away, as I was just looking at merges.ubuntu.com, but it should go in when the archive opens for development.
<mapreri> tsimonq2: it won't be approved anyway.  It'll stay in the queue with all the other ~80 uploads currently there waiting until the base toolchain for artful is laid, and then the queue will be disabled and emptied.
<tsimonq2> mapreri: Ah ok, I didn't know what happened to uploads pre-archive opening.
#ubuntu-release 2017-04-22
-queuebot:#ubuntu-release- Unapproved: xfce4-notifyd (artful-proposed/universe) [0.3.6-0ubuntu1 => 0.3.6-1] (xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: xfce4-dict (artful-proposed/universe) [0.7.2-1 => 0.7.99-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-mount-plugin (artful-proposed/universe) [0.6.7-1build1 => 1.1.2-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-genmon-plugin (artful-proposed/universe) [3.4.0-2build1 => 4.0.0-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-whiskermenu-plugin (artful-proposed/universe) [2.1.1-0ubuntu1 => 2.1.2-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: adequate (artful-proposed/universe) [0.15.1ubuntu2 => 0.15.1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adequate [source] (artful-proposed) [0.15.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [sync] (artful-proposed) [3.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (artful-proposed) [17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted acl [source] (artful-proposed) [2.2.52-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted aspell [source] (artful-proposed) [0.60.7~20110707-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted bcache-tools [source] (artful-proposed) [1.0.8-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted caja [source] (artful-proposed) [1.18.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cron [source] (artful-proposed) [3.0pl1-128ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted diffstat [source] (artful-proposed) [1.61-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-screensaver [source] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted acpid [source] (artful-proposed) [1:2.0.26-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted caja-extensions [source] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dctrl-tools [source] (artful-proposed) [2.24-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (artful-proposed) [17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted attr [source] (artful-proposed) [1:2.4.47-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-icon-theme [source] (artful-proposed) [1.18.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cdrkit [source] (artful-proposed) [9:1.1.11-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted dmraid [source] (artful-proposed) [1.0.0.rc16-4.2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted geoclue [source] (artful-proposed) [0.12.99-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-log [source] (artful-proposed) [3.9.90-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted gzip [source] (artful-proposed) [1.6-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted irqbalance [source] (artful-proposed) [1.1.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libdumbnet [source] (artful-proposed) [1.12-7build1]
-queuebot:#ubuntu-release- Unapproved: accepted lockfile-progs [source] (artful-proposed) [0.1.17build1]
-queuebot:#ubuntu-release- Unapproved: accepted lupin [source] (artful-proposed) [0.57build1]
-queuebot:#ubuntu-release- Unapproved: accepted min12xxw [source] (artful-proposed) [0.0.9-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted mouseemu [source] (artful-proposed) [0.16-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx-configtool [source] (artful-proposed) [0.4.8-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted gparted [source] (artful-proposed) [0.25.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted joyent-mdata-client [source] (artful-proposed) [0.0.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lsscsi [source] (artful-proposed) [0.27-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted mlocate [source] (artful-proposed) [0.26-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mscompress [source] (artful-proposed) [0.4-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted notify-osd [source] (artful-proposed) [0.9.35+16.04.20160415-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot [source] (artful-proposed) [4.5.2-1.1-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted libpaper [source] (artful-proposed) [1.1.24+nmu4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mousetweaks [source] (artful-proposed) [3.12.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (artful-proposed) [17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted ipvsadm [source] (artful-proposed) [1:1.28-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted msr-tools [source] (artful-proposed) [1.3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted maas-enlist [source] (artful-proposed) [0.4+bzr38-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (artful-proposed) [1.1.8-3.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pcmciautils [source] (artful-proposed) [018-8build1]
-queuebot:#ubuntu-release- Unapproved: accepted procmail [source] (artful-proposed) [3.22-25build1]
-queuebot:#ubuntu-release- Unapproved: accepted pxljr [source] (artful-proposed) [1.4+repack0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted patch [source] (artful-proposed) [2.7.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted psmisc [source] (artful-proposed) [22.21-2.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted pkg-config [source] (artful-proposed) [0.29.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted quota [source] (artful-proposed) [4.03-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (artful-proposed) [1.1.8-3.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pcmciautils [source] (artful-proposed) [018-8build1]
-queuebot:#ubuntu-release- Unapproved: accepted procmail [source] (artful-proposed) [3.22-25build1]
-queuebot:#ubuntu-release- Unapproved: accepted pxljr [source] (artful-proposed) [1.4+repack0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted raptor2 [source] (artful-proposed) [2.0.14-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rfkill [source] (artful-proposed) [0.5-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted sbc [source] (artful-proposed) [1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted syslinux-legacy [source] (artful-proposed) [2:3.63+dfsg-2ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted tinycdb [source] (artful-proposed) [0.78build1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-geoip [source] (artful-proposed) [1.0.2+14.04.20131125-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted patch [source] (artful-proposed) [2.7.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted psmisc [source] (artful-proposed) [22.21-2.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted rasqal [source] (artful-proposed) [0.9.32-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (artful-proposed) [1:4.3-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted tone-generator [source] (artful-proposed) [1.5.4+15.10.20150731-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-lens-music [source] (artful-proposed) [6.9.1+16.04-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-home [source] (artful-proposed) [6.8.2+16.04.20160212.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted usbmuxd [source] (artful-proposed) [1.1.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted uucp [source] (artful-proposed) [1.07-23build1]
-queuebot:#ubuntu-release- Unapproved: accepted vlc [sync] (artful-proposed) [2.2.5-3]
-queuebot:#ubuntu-release- Unapproved: accepted pkg-config [source] (artful-proposed) [0.29.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted rtkit [source] (artful-proposed) [0.11-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-lens-files [source] (artful-proposed) [7.1.0+16.04.20151217-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unzip [source] (artful-proposed) [6.0-20ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vlc [sync] (artful-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted wireless-tools [source] (artful-proposed) [30~pre9-8ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted x11-session-utils [source] (artful-proposed) [7.7+2build1]
-queuebot:#ubuntu-release- Unapproved: accepted x11-xserver-utils [source] (artful-proposed) [7.7+7build1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-user-dirs [source] (artful-proposed) [0.15-2ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-genmon-plugin [source] (artful-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted quota [source] (artful-proposed) [4.03-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-lens-video [source] (artful-proposed) [0.3.15+16.04.20160212.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie-preferences [source] (artful-proposed) [0.18build1]
-queuebot:#ubuntu-release- Unapproved: accepted x11-utils [source] (artful-proposed) [7.7+3build1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-dict [source] (artful-proposed) [0.7.99-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-notifyd [sync] (artful-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted xinput [source] (artful-proposed) [1.6.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted time [source] (artful-proposed) [1.7-25.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted wvdial [source] (artful-proposed) [1.61-4.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-mount-plugin [source] (artful-proposed) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted usbutils [source] (artful-proposed) [1:007-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-whiskermenu-plugin [source] (artful-proposed) [2.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-user-dirs-gtk [source] (artful-proposed) [0.10-1ubuntu2]
-queuebot:#ubuntu-release- New binary: caja-extensions [ppc64el] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: caja-extensions [i386] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty 17.04 | Archive: open | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- New binary: caja-extensions [amd64] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: caja-extensions [s390x] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: caja-extensions [arm64] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: caja-extensions [armhf] (artful-proposed/universe) [1.18.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (artful-proposed/universe) [17.10.0] (ubuntu-mate)
-queuebot:#ubuntu-release- New source: gtk+4.0 (artful-proposed/primary) [3.90.0-0ubuntu1]
<jbicha> by the way, I got "stuck in artful-proposed for 3 days" emails today for my zesty srus
<LocutusOfBorg> can I do the llvm-toolchain* game?
<LocutusOfBorg> infinity, ^^ :)
<LocutusOfBorg> (I consider llvm part of the toolchain, and there are some symbol versioning fixes that should be uploaded before the archive is opened)
<jbicha> LocutusOfBorg: archive is open but autosyncs haven't started yet
<LocutusOfBorg> thanks
<LocutusOfBorg> I read logs and I saw something like "monday"
<LocutusOfBorg> so, I'll start the game, llvm needs some bugfixes here :D
<LocutusOfBorg> I hope we have now pie enabled by default everywhere
-queuebot:#ubuntu-release- New sync: qtcharts-opensource-src (artful-proposed/primary) [5.7.1-3]
<LocutusOfBorg> nacc, doing the openldap merge
<LocutusOfBorg> what is the plan for openssl and openssl 1.0?
 * LocutusOfBorg goes AFK after ~15 uploads :p lets see tonight how llvm badly performed
-queuebot:#ubuntu-release- New binary: python-ase [amd64] (artful-proposed/universe) [3.13.0-1] (no packageset)
#ubuntu-release 2017-04-23
-queuebot:#ubuntu-release- New: accepted python-ase [amd64] (artful-proposed) [3.13.0-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (artful-proposed) [17.10.0]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [sync] (artful-proposed) [5.7.1-3]
<tsimonq2> jbicha: YAY! qtcharts-opensource-src \o/
 * tsimonq2 packaged that, happy to see it show up here \o/
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [ppc64el] (artful-proposed/none) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [i386] (artful-proposed/none) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [s390x] (artful-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [armhf] (artful-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [arm64] (artful-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtcharts-opensource-src [amd64] (artful-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [amd64] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [armhf] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [ppc64el] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [arm64] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [s390x] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted qtcharts-opensource-src [i386] (artful-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New sync: libva-utils (artful-proposed/primary) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New binary: libass [amd64] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libass [ppc64el] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libass [i386] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libass [s390x] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libass [arm64] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libass [armhf] (artful-proposed/universe) [1:0.13.6-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libass [amd64] (artful-proposed) [1:0.13.6-1]
-queuebot:#ubuntu-release- New: accepted libass [armhf] (artful-proposed) [1:0.13.6-1]
-queuebot:#ubuntu-release- New: accepted libass [s390x] (artful-proposed) [1:0.13.6-1]
-queuebot:#ubuntu-release- New: accepted libass [arm64] (artful-proposed) [1:0.13.6-1]
-queuebot:#ubuntu-release- New: accepted libass [i386] (artful-proposed) [1:0.13.6-1]
-queuebot:#ubuntu-release- New: accepted libass [ppc64el] (artful-proposed) [1:0.13.6-1]
 * infinity demotes large chunks of $world to universe.
<jbicha> infinity: we might want folks in main for gnome-contacts or gnome-maps
<infinity> jbicha: It can come back later if that's needed.  I assume lots of gnome will shuffle around.
<jbicha> that's probably several weeks anyway, thanks!
<infinity> jbicha: The only demotion so far that I've explicitly undone is network-manager-openvpn.
<infinity> jbicha: Yeah, as I go down this list, I'm guessing almost all of the telepathy stack will end up coming back.  But I'd rather keep the reports clean from day 1 for once.  I drove everything to 0 (for the first time in a long time) before zesty release, so good to try to keep it that way.
<infinity> (At least it'll come back by way of telepathy-glib instead of telepathy-qt ... I used to work on both at Collabora, and lemme tell you, one is a much nicer piece of software)
<jbicha> oh, I didn't know you were at Collabora
<jbicha> I believe telepathy is no longer required by our GNOME stack, so it might stay in universe
<jbicha> FYI, https://wiki.ubuntu.com/DesktopTeam/GNOME/MIR_List
<infinity> slangasek: I'm thinking we should drop /win 163
<infinity> Err.
<infinity> Yes.  Drop win 163.
<infinity> slangasek: I'm thinking we should drop ubuntu-touch from main.  At least, I tihnk that's what's still holding in a few bits and bobs.
<jbicha> If you really have 163+ windows, I think you should drop some! :)
<infinity> I have a few more, probably.
<mwhudson> oo i can actually do some work today
<zx2c4> I've got a rather pressing matter to discuss regarding the Ubuntu release process and a particular package that's posing some significant issues. Is there somebody from Canonical I could talk to in here? Thanks. --Jason
<infinity> zx2c4: Don't ask to ask, just ask.
<infinity> zx2c4: Although, specific issues with specific packages are usually better expressed as bug reports on said package, not a general issue with "the release process".
<infinity> (But I suppose that depends on the nature of the bug)
<zx2c4> hey infinity
<zx2c4> infinity: still there?
<zx2c4> i was just writing you an email
<cjwatson> This is about https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522, since zx2c4 seems to be averse to just coming out and saying so directly
<ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
<zx2c4> no im in the middle of typing my message!
<zx2c4> hold on
<infinity> zx2c4: While you were busy typing your message, I demoted it to proposed and blocked it from migrating.
<zx2c4> I'm working on a piece of software for the Linux kernel called WireGuard. It's currently experimental, but still very usable. It has not reached a 1.0 release or even an 0.1 release. I do occasionally tag snapshots in the repo, and distributions package these snapshots, because wireguard is very useful. But it's still clearly marked as being experimental and
<zx2c4> potentially dangerous. The pact between wireguard upstream and the distros is that if they package it, they _will_ keep their snapshot up to date. Thus, for Debian, Daniel Kahn Gillmor (dkg) has pinned the package in Debian `sid`, with a note that it shouldn't [yet] go into testing or stable, since it is experimental software. Ubuntu screwed up and somehow
<zx2c4> imported an ancient snapshot from Debian, which is absolutely unacceptable. Either Ubuntu should not package wireguard at all, or they should keep it up to date with the Debian package. I'd most certianly prefer the latter
<zx2c4> infinity: what does that mean exactly?
<infinity> zx2c4: Effectively the same thing as "keeping it in sid" means in Debian.  It'll never be in another stable release until that bug is closed.
<zx2c4> oh, interesting
<zx2c4> so I should bookmark this bug so that I can chime in once we do reach the 0.1/1.0 release
<infinity> zx2c4: Ubuntu didn't "screw up".  We import from Debian wholesale.
<zx2c4> Ahh
<zx2c4> I thought it was tagged in Debian with a special marking to prevent this?
<zx2c4> I'm not too familiar with the release internals
<infinity> zx2c4: We import from sid, not testing.
<zx2c4> Is there a way that you can set this package up to continually import from sid so that it's up to date?
<zx2c4> I'd love to have an up to date wireguard package -- and i know others would too, as it's being included in Docker's new Moby/LinuxKit project -- in ubuntu
<infinity> zx2c4: It will do so automatically in the devel release, sure.  We don't automatically import or update anything in stable releases.
<zx2c4> Ahhh, interesting
<zx2c4> So Zesty is what you call a "stable" releaes?
<infinity> As of 10 days ago, yes.
<zx2c4> Everytime you give something a number -- 16.10, 17.04, 17.10, 17.04... these are "stable" and are a snapshot of sid at the time
<zx2c4> Okay, so has this snapshot been entirely removed from Zesty now?
<jbicha> is it possible to make wireguard into a snap package?
<infinity> It's not a snapshot of sid, per se.  We do auto-imports from sid during our devel cycle, then stop near the end so we can stabilise and prep for release.
<zx2c4> infinity: i dont want users to install that old snapshot under any circumstances
<infinity> zx2c4: No, it hasn't been removed from zesty.  We don't alter released series' (except with bugfix/security updates).
<zx2c4> jbicha: the ubuntu wireguard people have this -- https://launchpad.net/~wireguard/+archive/ubuntu/wireguard -- which is a nice PPA.
<zx2c4> infinity: that's very unfortunate
<cjwatson> If it has to be removed from zesty then the only way would be to issue an "update" which is in fact an empty package.
<infinity> zx2c4: If the package is that dire for people to install, it could be replaced with an empty package with a note explaining the situation.
<zx2c4> infinity: i'd highly recommend doing what cjwatson recommends
<zx2c4> okay, let's do that then
<zx2c4> you could even point to the wireguard PPA
<zx2c4> (which is actively maintained)
<zx2c4> Would you like me to draft a note?
<infinity> Note that probably none of us are keen to go to that trouble on your behalf, but feel free to proposed a package on that bug for someone to sponsor for you.
<jbicha> zx2c4: it sounds like you want wireguard completely removed from Ubuntu so that it won't automatically import from Debian at all
<infinity> s/proposed/propose/
<zx2c4> infinity: how does that work?
<zx2c4> should I write an .deb package
<zx2c4> and attach a tarball?
<zx2c4> and then you'll get that tarball included?
<infinity> Attach a source package, sure.  Probably wants a NEWS.Debian that explains the situation for people who did have it installed.
<zx2c4> infinity: okay
<zx2c4> would you mind if i ask dkg to help me with this?
<zx2c4> He's a debian guy and will probably screw up less of the fine details than me
<zx2c4> (I'm just a measly kernel programmer)
<infinity> Sure.
<zx2c4> cool okay
<zx2c4> And then after it's posted, you can easily click some buttons to import it?
<zx2c4> Should the version number be the same but a "-2" instead?
<cjwatson> append ubuntu16.04.1
<zx2c4> cjwatson: okay
<zx2c4> ill get to work on this immediately
<zx2c4> infinity: cjwatson thanks so much for your help. really appreciated
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates is the process for stable updates
<zx2c4> i should have come in here and asked straight-up from the beginning
<cjwatson> (though that tries to cover all bases and "replace with empty package" is probably a bit simpler)
<cjwatson> Yeah, it would have been much easier if this had been noticed pre-release.
<infinity> Indeed, asking 11 days ago would have saved some hassle.
<infinity> Oh well.
<zx2c4> infinity: i didnt realize until a few days ago
<zx2c4> when i saw, "oh cool zesty is out I should see how wireguard runs on it"
<zx2c4> and then i imported the ppa but forgot to apt update after
<zx2c4> but then wireguard actually apt install'd okay
<zx2c4> and then i figured out what had happened
<jbicha> pkil gnome-software
<infinity> No command 'pkil' found, did you mean:
<infinity>  Command 'pil' from package 'picolisp' (universe)
<infinity>  Command 'pki' from package 'strongswan-pki' (universe)
<infinity>  Command 'pki' from package 'pki-tools' (universe)
<infinity>  Command 'pkill' from package 'procps' (main)
<infinity> pkil: command not found
<infinity> jbicha: HTH.
<cjwatson> Just thinking about avoiding this type of problem at the infrastructure level in future
<cjwatson> How about we only auto-sync *new* packages by default once they (not necessarily the same version) have hit testing ever?
<cjwatson> Or something like that
<cjwatson> If somebody wants to manually sync before that, that's fine, that implies that at least somebody thought about it
<jbicha> infinity: sorry, GNOME on Wayland has interesting behavior sometimes (like when your computer runs out of ram or something)
<infinity> jbicha: That's encouraging...
<cjwatson> We'd be a bit slower at picking up brand-new packages, but I think the rationale for syncing from unstable rather than testing mostly doesn't apply to those
<infinity> cjwatson: That would have worked in this case, as it never migrated, it wouldn't have worked for most of the previous cases (bitcoin stuff, famously) where they were removed from testing.
<cjwatson> Yeah, it's not a panacea, just thinking that it might make sense.
<infinity> Might do.
<jbicha> I typed that pkill command (probably with 2 Ls) in a different terminal and it ate the L and spat the command out here instead
<cjwatson> (We should probably separately track explicit manual removals from testing, since we often want to at least think about those)
<infinity> We *should*, but not sure who'd sign up to give that list love.
<infinity> And is there an easy way to distinguish manual removals from the hundreds of auto-removals we don't care about?
<cjwatson> Not sure offhand.
<infinity> Anyhow, I should see about untetheting myself from my desk and enjoying what's left of my weekend.
<zx2c4> infinity: im looking at this bitcoin stuff now actually to see how it works
<zx2c4> is there another reference i should study as well?
<Ukikie> owncloud.
<zx2c4> Ukikie: thanks
<zx2c4> cjwatson: you wrote " append ubuntu16.04.1"
<zx2c4> you meant i should appen 17.04, right?
<infinity> Yes.
<zx2c4> infinity: so previous changelog line was
<zx2c4> wireguard (0.0.20170214-1) unstable; urgency=medium
<zx2c4> new one will be:
<zx2c4> wireguard (0.0.20170214-2ubuntu17.04) unstable; urgency=medium
<zx2c4> seem correct?
<infinity> s/-2/-1/
<zx2c4> interesting okay
<infinity> And s/unstable/zesty/
<zx2c4> okay
<zx2c4> wireguard (0.0.20170214-1ubuntu17.04) zesty; urgency=medium
<infinity> That'll do.  Though the security team's version recommendations would make that 0.0.20170214-1ubuntu0.17.04
<infinity> (Because an upload of an ubuntu delta to artful would be 0.0.20170214-1ubuntu1, and should sort higher)
<zx2c4> okay i'll do that
<zx2c4> LANG=C date -R seems to work nicely
<infinity> dch generates the signature bits for you.
<infinity> But I suppose you're not doing this on Debian/Ubuntu.
<zx2c4> I am
<zx2c4> i just booted up a zesty VM
<cjwatson> zx2c4: er, yes, thinko.
<zx2c4> but am still using vim for it O_o
<zx2c4> and then i guess I can remove Build-Depends:
<infinity> Probably all but debhelper.
<zx2c4> interesting
<zx2c4> infinity:
<zx2c4> okay all set
<zx2c4> ill upload this to the bug report?
<zx2c4> or want to have a look at it here first?
<zx2c4> alright added to the bug report
<zx2c4> I can modify it if you need
<zx2c4> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522/+attachment/4867059/+files/wireguard_0.0.20170214-1ubuntu0.17.04.tar.gz
<ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: golang-defaults [ppc64el] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-defaults [arm64] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-defaults [armhf] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-defaults [i386] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-defaults [amd64] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-defaults [s390x] (artful-proposed/main) [2:1.8~1ubuntu1] (kubuntu, ubuntu-desktop)
<mwhudson> infinity: still awake/around?
#ubuntu-release 2018-04-16
-queuebot:#ubuntu-release- Unapproved: libgdf (bionic-proposed/universe) [0.1.2-2.0ubuntu1 => 0.1.2-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libgdf [sync] (bionic-proposed) [0.1.2-2.1]
-queuebot:#ubuntu-release- Unapproved: ddccontrol (bionic-proposed/universe) [0.4.3-1 => 0.4.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ddccontrol [source] (bionic-proposed) [0.4.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nmap (bionic-proposed/main) [7.60-1ubuntu4 => 7.60-1ubuntu5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinnamon (bionic-proposed/universe) [3.6.7-8 => 3.6.7-8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon [source] (bionic-proposed) [3.6.7-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu1 => 3.28.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kasumi (bionic-proposed/universe) [2.5-5build1 => 2.5-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kasumi [sync] (bionic-proposed) [2.5-6]
-queuebot:#ubuntu-release- Unapproved: qpdf (bionic-proposed/main) [8.0.2-1 => 8.0.2-3] (desktop-core, ubuntu-server) (sync)
<LocutusOfBorg> xnox, sorry I don't have the answer, it was just blocking another package from migration :)
<LocutusOfBorg> I'm sure tsimonq2 would appreciate qdpf being accepted before he wakes up, so he can look and make it migrate :D
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.8-dfsg-7 => 5.2.8-dfsg-10] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.8-1 => 5.2.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.8-1 => 5.2.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (bionic-proposed) [5.2.8-2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (bionic-proposed) [5.2.8-2]
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6~beta1 => 1.6~rc1] (core) (sync)
<mitya57> Dear release team, we are going to land Qt 5.9.5 (strict bugfix release of the 5.9 LTS series) in a few hours. Please let us know if you have any objections.
<mitya57> It is prepared here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3237/+packages
-queuebot:#ubuntu-release- Unapproved: libreoffice-dictionaries (bionic-proposed/main) [1:6.0.3-1 => 1:6.0.3-2] (personal-gunnarhj, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.0~rc2ubuntu2 => 1.6.0~rc3] (core) (sync)
<juliank> the python-apt sync adds a further bugfix (and brings the rest upstream), the apt sync needs FFe bug 1763839
<ubot5`> bug 1763839 in apt (Ubuntu) "[FFe] apt 1.6~rc1, zstd & hook support" [Undecided,New] https://launchpad.net/bugs/1763839
<xnox> slangasek, Assigning https://bugs.launchpad.net/ubuntu/+source/gdnsd/+bug/1764327 to you for guidance as to what to do with gdnsd w.r.t. addresses and ports it listens too.
<ubot5`> Ubuntu bug 1764327 in gdnsd (Ubuntu) "gdnsd fails to start, as it tries to listen to [::]:53" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: xen (bionic-proposed/main) [4.9.0-0ubuntu4 => 4.9.2-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<ginggs> would someone please accept autopkgtest from the bionic upload queue? 5.2 fixes the quoting bug we already have fixed on the live autopkgtesters, and 5.3 passes its autopkgtests
<apw> ginggs, looking
<ginggs> apw: thanks! the issue with the quoting bug is there are now a bunch of packages that passed on the live autopkgtesters, but will fail if run locally with 5.1
-queuebot:#ubuntu-release- Unapproved: example-content (bionic-proposed/main) [49 => 50] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [sync] (bionic-proposed) [5.3]
<ginggs> apw: and thanks for accepting
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [sync] (bionic-proposed) [5.2.8-dfsg-9]
<apw> ^ superceeded in the queue
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (bionic-proposed) [4.9.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcapi20-3 (bionic-proposed/universe) [1:3.27-2 => 1:3.27-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scim (bionic-proposed/universe) [1.4.18-1 => 1.4.18-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtvirtualkeyboard-opensource-src [source] (bionic-proposed) [5.9.4+dfsg-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (bionic-proposed) [0.62.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pastebinit (bionic-proposed/main) [1.5-1 => 1.5-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: pencil2d (bionic-proposed/universe) [0.6.0+ds-1 => 0.6.1-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected libcapi20-3 [sync] (bionic-proposed) [1:3.27-3]
-queuebot:#ubuntu-release- Unapproved: rejected scim [sync] (bionic-proposed) [1.4.18-2]
-queuebot:#ubuntu-release- Unapproved: rejected pastebinit [sync] (bionic-proposed) [1.5-2]
<apw> ^ duplicate in the queue ...
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (bionic-proposed) [0.9.9]
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (bionic-proposed) [1.6~rc1]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [sync] (bionic-proposed) [1.6.0~rc3]
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.188]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (bionic-proposed) [18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (bionic-proposed) [18.04.3]
-queuebot:#ubuntu-release- Unapproved: awscli (bionic-proposed/universe) [1.14.44-1 => 1.14.44-1ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: bind9 [s390x] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
<apw> ^ please hold that bind9 binary while it is investigated
-queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [amd64] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: lxde-metapackages (bionic-proposed/universe) [9 => 10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lxde-metapackages [sync] (bionic-proposed) [10]
-queuebot:#ubuntu-release- Unapproved: qpdf (bionic-proposed/main) [8.0.2-1 => 8.0.2-3] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- New sync: golang-github-bep-debounce (bionic-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected qpdf [sync] (bionic-proposed) [8.0.2-3]
<apw> ^ duplicate in the queue ...
-queuebot:#ubuntu-release- Unapproved: accepted qpdf [sync] (bionic-proposed) [8.0.2-3]
-queuebot:#ubuntu-release- New binary: bind9 [arm64] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [i386] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [armhf] (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.12-0ubuntu2 => 2.1.13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.13-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nmap [source] (bionic-proposed) [7.60-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted mate-power-manager [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-121.145] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-121.145]
-queuebot:#ubuntu-release- Unapproved: perl (bionic-proposed/main) [5.26.1-5 => 5.26.1-6] (core) (sync)
<apw> ^ !
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (bionic-proposed) [1.36.1-0ubuntu1]
<cjwatson> perl appears to be security fixes
<apw> yeah, looks to be just security, fun fun fun
-queuebot:#ubuntu-release- Unapproved: rejected libopenmpt [sync] (bionic-proposed) [0.3.8-1]
<LocutusOfBorg> why not sync perl 5.26.2 from experimental? :) (joke mode off)
-queuebot:#ubuntu-release- Unapproved: rejected pycryptodome [sync] (bionic-proposed) [3.4.11-1]
<sil2100> jibel: I already saw two uploads/syncs from you in bionic that were FF-breaking without a FFe - are you checking if the new versions are not breaking any freezes before uploading/syncing?
<sil2100> jibel: eh, ignore!
<sil2100> jbicha: ^
<sil2100> jibel: (stupid auto-complete), I meant jbicha
<jbicha> sil2100: could you be more specific?
<jbicha> also it looks like the person who requested a sync doesn't get emailed rejection notes?
<sil2100> jbicha: libopenmpt and pycryptodome sync requests came from you from what I remember, both have new features when looking at the changes files
<jbicha> they are both security fixes
<sil2100> Yes, but with new features
<jbicha> yes
<sil2100> Just because there are security fixes doesn't mean we can let new features in with them without FFe's
<sil2100> It's not like the security fixes make them no longer applicable to FF
<sil2100> That is my understanding
<jbicha> the upstream changes are https://www.pycryptodome.org/en/latest/src/changelog.html#id6
<jbicha> https://lib.openmpt.org/doc/changelog.html
<sil2100> I know the changes and as visible there are new features, yes?
<jbicha> I don't plan on working on ffe's or splitting out the security updates for them
<sil2100> I might be over-formal here so some more experienced release-team member can correct me, but features need someone to do FFe's for them, I don't know about a blanket exception for those because of security fixes
<LocutusOfBorg> my ethtool sync has been rejected and sadly we don't get such emails (it was a no-change sync just to remove the ubuntu delta)
<sil2100> (wasn't me!)
<LocutusOfBorg> I'm not blaming anybody, I'll sync after bionic is out :)
<LocutusOfBorg> just pointing that rejection emails would be an awesome feature
<sil2100> I actually expected those to go to the requester
-queuebot:#ubuntu-release- Unapproved: accepted mate-applets [source] (bionic-proposed) [1.20.1-2ubuntu1]
<sil2100> If they don't, then it's quite an issue IMO as indeed people might be scratching their heads not knowing why their uploads ended up rejected
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-notifyd [source] (bionic-proposed) [0.4.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (bionic-proposed) [18.04.5]
<jbicha> I don't care about either of those 2 packages to worry about it. I thought they might have been allowed in as bugfixes so I tried the syncs. I appreciate you doing your job :)
<acheronuk> sil2100: on that topic, regards skanlite in the queue. LP #1764370
<ubot5`> Launchpad bug 1764370 in skanlite (Ubuntu) "[FFe] skanlite 2.1.0.1-1 for Bionic" [Undecided,New] https://launchpad.net/bugs/1764370
-queuebot:#ubuntu-release- Unapproved: conntrack-tools (bionic-proposed/main) [1:1.4.4+snapshot20161117-6ubuntu1 => 1:1.4.4+snapshot20161117-6ubuntu2] (ubuntu-server)
<sil2100> acheronuk: ACK, I usually check for FFes when I see features, but it's convenient to have this here already - thanks ;)
<sil2100> jbicha: I'm a bit too new in the queue management so I prefer just following the rules - there might be some exceptions to the rules that I don't know of!
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (bionic-proposed/main) [2.7.14-3 => 2.7.15~rc1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted skanlite [sync] (bionic-proposed) [2.1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted konsole [source] (bionic-proposed) [4:17.12.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted eog [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted alkimia [sync] (bionic-proposed) [7.0.2-1]
-queuebot:#ubuntu-release- Unapproved: python-defaults (bionic-proposed/main) [2.7.14-4 => 2.7.15~rc1-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (bionic-proposed) [18.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (bionic-proposed) [18.04.6]
-queuebot:#ubuntu-release- New: accepted bind9 [amd64] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [armhf] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-bep-debounce [sync] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted bind9 [arm64] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [s390x] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [i386] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-defaults [source] (bionic-proposed) [2.7.15~rc1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (bionic-proposed) [2.7.15~rc1-1]
-queuebot:#ubuntu-release- Unapproved: accepted caja [source] (bionic-proposed) [1.20.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-msgpack [source] (bionic-proposed) [0.5.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (bionic-proposed) [18.04.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm [source] (bionic-proposed) [0.17.0-1ubuntu4]
-queuebot:#ubuntu-release- New binary: golang-github-bep-debounce [amd64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
<tsimonq2> As mitya57 stated before (and got no objections), I am now landing Qt 5.9.5, assuming Bileto lets me.
-queuebot:#ubuntu-release- Unapproved: accepted libcapi20-3 [sync] (bionic-proposed) [1:3.27-3]
-queuebot:#ubuntu-release- Unapproved: accepted scim [sync] (bionic-proposed) [1.4.18-2]
<sil2100> ugh
<sil2100> Ok
<tsimonq2> sil2100: Get a bouncer. ;)
-queuebot:#ubuntu-release- Unapproved: accepted pastebinit [sync] (bionic-proposed) [1.5-2]
<sil2100> And I was happy already that the queue is getting finally smaller
<sil2100> tsimonq2: it's bugfixes only from the Qt5 POV?
<tsimonq2> sil2100: Yep, upstream LTS.
<tsimonq2> 5.9.4 -> 5.9.5
<sil2100> Yeah, just want to make sure they didn't include any small feature changes inbetween
<sil2100> Ok
<tsimonq2> And then the no-change rebuilds for the convenience virtual ABI package bump.
<sil2100> I'm looking at the diffs on bileto and I'll probably just approve all of them once it looks good and all are in the queue
<acheronuk> "Qt 5.9 LTS has entered âStrictâ phase in the beginning of February. It continues to receive important bug fixes and significant performance fixes still during the âStrictâ phase. Intention is to reduce risk of regressions and behavior changes by restricting the changes to the most important ones."
<acheronuk> from Qt site ^^
 * sil2100 likes
<sil2100> Makes life easier
<apw> sil2100, they are likely to miss the queue if they are copied from a silo
<tsimonq2> This is why we plan on SRUing Qt once 5.9.6 comes out. ;)
<tsimonq2> apw: Oh?
<apw> sil2100, which is why we have the aa review for 'new' things coming from silo's in the silo before publish is hit
<tsimonq2> apw: I was told by an AA privately that Bileto goes through NEW but not through UNAPPROVED.
<tsimonq2> Could be wrong, though.
<apw> tsimonq2, i think it is more subtle than that, but the key is they are menat to be reviewed before they are published
<sil2100> apw: yeah, I think it should end up in the queue
<sil2100> I know SRUs from Bileto end in UNAPPROVED, but maybe for devel it's different
<sil2100> Anyway, we'll see soon I suppose!
<tsimonq2> apw: Nothing in here would have to go through NEW.
<Laney> that just happens for NEW I think
<apw> sil2100, i am prolly not taking into acount the geneal block
<Laney> binary NEW that is
<tsimonq2> ftr: forgot to do a final diff before publish in Bileto. Running now.
<cjwatson> the bug you are all talking about is https://bugs.launchpad.net/launchpad/+bug/993120
<ubot5`> Ubuntu bug 993120 in Launchpad itself "Copy from PPA with binaries evades NEW and puts new packages in their default component" [High,In progress]
<cjwatson> I had a go at fixing it a while back but it was wrong in some way whose details I've forgotten, and needs reworking
<tsimonq2> OK, *now* it should land.
 * tsimonq2 grabs a cup of coffee
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [sync] (bionic-proposed) [1.56.1-1]
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8-20180414-1ubuntu1 => 8-20180414-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tiff [sync] (bionic-proposed) [4.0.9-5]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [source] (bionic-proposed) [8-20180414-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: thunderbird (bionic-proposed/main) [1:52.6.0+build1-0ubuntu1 => 1:52.7.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
 * sil2100 waits for bileto to finish his work
<sil2100> tsimonq2: oh, publishing failed
<sil2100> tsimonq2: requires a packaging ACK
<sil2100> tsimonq2: did you tick the packaging ACK when publishing?
<apw> sil2100, that is your ack i am sure :)
<tsimonq2> sil2100: I did the first time, it failed, I forgot to check it when I pressed again, and then was trigger happy AGAIN -_-
<tsimonq2> tl;dr yes I ack, I just can't Bileto. XD
<tsimonq2> THERE we go. :)
 * acheronuk holds breath
<sil2100> apw: I'd prefer not to ACK it there so that I'm not to blame for any breakages this could cause!
<tsimonq2> Hehe
<sil2100> That being said, I'll be anyway to blame if I accept that into bionic
<sil2100> ugh
<tsimonq2> I expect very little breakage.
<Laney> going to trigger a lot of tests btw
<Laney> python-defaults is running, and there's a perl in the queue
<tsimonq2> Laney: Yep, which is why I didn't let Bileto+Britney get to it. ;)
<tsimonq2> Oh.
<tsimonq2> sil2100: All done. \o/  https://bileto.ubuntu.com/log/3237/publish/6/
<tsimonq2> Now we wait... ;)
-queuebot:#ubuntu-release- Unapproved: akonadi (bionic-proposed/universe) [4:17.12.3-0ubuntu2 => 4:17.12.3-0ubuntu3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: calibre (bionic-proposed/universe) [3.21.0+dfsg-1 => 3.21.0+dfsg-1build1] (edubuntu, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: dtkwidget (bionic-proposed/universe) [2.0.7.2-2 => 2.0.7.2-2build1] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: fcitx-qt5 (bionic-proposed/universe) [1.1.1-1build2 => 1.1.1-1build3] (input-methods, kubuntu, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: gammaray (bionic-proposed/universe) [2.7.0-1ubuntu7 => 2.7.0-1ubuntu8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gsettings-qt (bionic-proposed/universe) [0.1+17.10.20170824-2fakesync1build1 => 0.1+17.10.20170824-2fakesync1build2] (lubuntu, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: hime (bionic-proposed/universe) [0.9.10+git20170427+dfsg1-2build3 => 0.9.10+git20170427+dfsg1-2build4] (input-methods) (sync)
-queuebot:#ubuntu-release- Unapproved: analitza (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gcin (bionic-proposed/universe) [2.8.5+dfsg1-4build3 => 2.8.5+dfsg1-4build4] (input-methods) (sync)
<tsimonq2> Here we goooo :)
-queuebot:#ubuntu-release- Unapproved: kdeclarative (bionic-proposed/universe) [5.44.0-0ubuntu1 => 5.44.0-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.4-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libfm-qt (bionic-proposed/universe) [0.12.0-14build1 => 0.12.0-14build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: lxqt-qtplugin (bionic-proposed/universe) [0.12.0-6ubuntu2 => 0.12.0-6ubuntu3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: musescore (bionic-proposed/universe) [2.1.0+dfsg3-3 => 2.1.0+dfsg3-3build1] (edubuntu, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: openorienteering-mapper (bionic-proposed/universe) [0.8.1.1-1 => 0.8.1.1-1build1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pyqt5 (bionic-proposed/universe) [5.9.2+dfsg-1build2 => 5.10.1+dfsg-1ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: pythonqt (bionic-proposed/universe) [3.2-7build1 => 3.2-7build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (bionic-proposed/universe) [5.44.0-0ubuntu2 => 5.44.0-0ubuntu3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libqtxdg (bionic-proposed/universe) [3.1.0-5build1 => 3.1.0-5build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: kxmlgui (bionic-proposed/universe) [5.44.0-0ubuntu1 => 5.44.0-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-integration (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.4-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: maliit-framework (bionic-proposed/universe) [0.99.1+git20151118+62bd54b-0ubuntu17 => 0.99.1+git20151118+62bd54b-0ubuntu18] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qt3d-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu2 => 5.9.5+dfsg-0ubuntu2] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (bionic-proposed) [0.8.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: qtav (bionic-proposed/universe) [1.12.0+ds-4build2 => 1.12.0+ds-4build3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdoc-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtgraphicaleffects-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtimageformats-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtlocation-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pythonqt [sync] (bionic-proposed) [3.2-7build2]
-queuebot:#ubuntu-release- Unapproved: qtconnectivity-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtcurve (bionic-proposed/universe) [1.8.18+git20160320-3d8622c-5build3 => 1.8.18+git20160320-3d8622c-5build4] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmultimedia-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtpim-opensource-src (bionic-proposed/universe) [5.0~git20140515~29475884-0ubuntu24~6 => 5.0~git20140515~29475884-0ubuntu24~7] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtquickcontrols-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.4+dfsg-0ubuntu4 => 5.9.5+dfsg-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtcreator (bionic-proposed/universe) [4.5.2-3ubuntu1 => 4.5.2-3ubuntu2] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gammaray [sync] (bionic-proposed) [2.7.0-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: qtscript-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtsensors-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtserialport-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtspeech-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwayland-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu2 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtquickcontrols2-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtstyleplugins-src (bionic-proposed/universe) [5.0.0+git23.g335dbec-2build4 => 5.0.0+git23.g335dbec-2build5] (qt5, ubuntu-budgie, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtvirtualkeyboard-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu3 => 5.9.5+dfsg-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebchannel-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (bionic-proposed/universe) [5.212.0~alpha2-7build2 => 5.212.0~alpha2-7ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebsockets-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebview-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtsvg-opensource-src (bionic-proposed/main) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qttranslations-opensource-src (bionic-proposed/main) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtwebview-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: texmaker (bionic-proposed/universe) [5.0.2-1build1 => 5.0.2-1build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtx11extras-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (bionic-proposed/universe) [1.2.15-1 => 1.2.15-1build1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtxmlpatterns-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu2+2 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-kde (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.4-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [sync] (bionic-proposed) [1.2.15-1build1]
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.13-0ubuntu1 => 2.1.13-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted texmaker [sync] (bionic-proposed) [5.0.2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.13-0ubuntu2]
 * tsimonq2 sets up the transition tracker
<sil2100> Ok, approving those Qt uploads - just quickly resolve it before Final Freeze
<tsimonq2> Absolutely.
<tsimonq2> Thank you sil2100!
<sil2100> I hate transitions right before final freeze
<sil2100> yw
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [sync] (bionic-proposed) [4:17.12.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted calibre [sync] (bionic-proposed) [3.21.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx-qt5 [sync] (bionic-proposed) [1.1.1-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted gcin [sync] (bionic-proposed) [2.8.5+dfsg1-4build4]
-queuebot:#ubuntu-release- Unapproved: accepted hime [sync] (bionic-proposed) [0.9.10+git20170427+dfsg1-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted kdelibs4support [sync] (bionic-proposed) [5.44.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted kxmlgui [sync] (bionic-proposed) [5.44.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libqtxdg [sync] (bionic-proposed) [3.1.0-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted maliit-framework [sync] (bionic-proposed) [0.99.1+git20151118+62bd54b-0ubuntu18]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [sync] (bionic-proposed) [5.12.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted analitza [sync] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdeclarative [sync] (bionic-proposed) [5.44.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libfm-qt [sync] (bionic-proposed) [0.12.0-14build2]
-queuebot:#ubuntu-release- Unapproved: accepted musescore [sync] (bionic-proposed) [2.1.0+dfsg3-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted qtav [sync] (bionic-proposed) [1.12.0+ds-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted dtkwidget [sync] (bionic-proposed) [2.0.7.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [sync] (bionic-proposed) [4:5.12.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pyqt5 [sync] (bionic-proposed) [5.10.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gsettings-qt [sync] (bionic-proposed) [0.1+17.10.20170824-2fakesync1build2]
-queuebot:#ubuntu-release- Unapproved: accepted qt3d-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-qtplugin [sync] (bionic-proposed) [0.12.0-6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtcreator [sync] (bionic-proposed) [4.5.2-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtgraphicaleffects-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtlocation-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtpim-opensource-src [sync] (bionic-proposed) [5.0~git20140515~29475884-0ubuntu24~7]
-queuebot:#ubuntu-release- Unapproved: accepted qtquickcontrols2-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtsensors-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtspeech-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtsvg-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtconnectivity-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtdoc-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmultimedia-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtscript-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtstyleplugins-src [sync] (bionic-proposed) [5.0.0+git23.g335dbec-2build5]
-queuebot:#ubuntu-release- Unapproved: accepted qttranslations-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwayland-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebsockets-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtxmlpatterns-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtcurve [sync] (bionic-proposed) [1.8.18+git20160320-3d8622c-5build4]
-queuebot:#ubuntu-release- Unapproved: accepted qtquickcontrols-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qttools-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebchannel-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtx11extras-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtimageformats-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtvirtualkeyboard-opensource-src [sync] (bionic-proposed) [5.9.5+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-kde [sync] (bionic-proposed) [5.12.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtserialport-opensource-src [sync] (bionic-proposed) [5.9.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [sync] (bionic-proposed) [5.212.0~alpha2-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: virt-manager (bionic-proposed/universe) [1:1.5.0-0ubuntu1 => 1:1.5.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (bionic-proposed) [1:1.5.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32.3.2+18.04 => 2.32.5+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unity (bionic-proposed/universe) [7.5.0+18.04.20180409-0ubuntu1 => 7.5.0+18.04.20180413-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xe-guest-utilities (bionic-proposed/universe) [7.4.0-0ubuntu1 => 7.10.0-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (bionic-proposed) [7.5.0+18.04.20180413-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.13.10-1ubuntu1 => 1.13.12-0ubuntu1] (ubuntu-server)
<teward> Release team: There's an FFe bug for the nginx upload, it needs an FFe under the same basis of FFe for 1.13.10 and the 16.04 release cycle's precedent. https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1764447
<ubot5`> Ubuntu bug 1764447 in nginx (Ubuntu) "[FFe] Please update nginx to 1.13.12" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: qtubuntu (bionic-proposed/main) [0.64+17.10.20170707-0ubuntu5 => 0.64+17.10.20170707-0ubuntu6] (ubuntu-qt-packages)
<LocutusOfBorg> tsimonq2, ^^
<tsimonq2> sil2100: That's a no-change rebuild needed for the Qt transition, please approve. :)
<slangasek> xnox: gdnsd> no worries.  fwiw my understanding is that gdnsd would have previously failed on any system using dnsmasq (whether via NetworkManager or for something like lxd), so I wouldn't consider this a high priority bug.
-queuebot:#ubuntu-release- Unapproved: umbrello (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.32.5+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [source] (bionic-proposed) [0.64+17.10.20170707-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32.3.2+18.04 => 2.32.5+18.04] (desktop-core, ubuntu-server)
 * apw reviews snapd ^
<sil2100> apw: ACK!
<sil2100> I'm looking at xe-guest-utilities now, after which I'm done with the queue for today
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: lskat (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted xe-guest-utilities [source] (bionic-proposed) [7.10.0-0ubuntu1]
<Laney> LocutusOfBorg: what is the point of this virtualbox upload?
-queuebot:#ubuntu-release- Unapproved: kubrick (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksudoku (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
<xnox> slangasek, so "just badtest it"? or e.g. drop the right config file into the package for autopkgtesting? or make it not start by default?
<xnox> slangasek, previously it wouldn't start on some systems; now it doesn't start on any system.
<slangasek> xnox: badtest it first, then I will opine on what I think is a sensible way to fix it.  I don't think "if you install this local DNS server, your local resolver will stop handling large DNS records" is a sensible result either
-queuebot:#ubuntu-release- Unapproved: kspaceduel (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
<LocutusOfBorg> Laney, be in sync with virtualbox-hwe
<Laney> dunno what that means
<LocutusOfBorg> it means to keep the delta version-coherent
<LocutusOfBorg> because debdiffing them is troublesome
<LocutusOfBorg> and I want people doing debheckout to download the correct sources (moved to salsa now)
<xnox> slangasek, i'm not sure how it can bind to "any" but not fe80:: / 127.0.0.53
<Laney> three changelog entries is troublesome?
<xnox> slangasek, any excluding lo?
<LocutusOfBorg> debcheckout might be
<Laney> I don't think we should waste the build and test resources
<LocutusOfBorg> btw this is not a "3 changelog entries", but a change in VCS fields that makes the diff virtualbox/virtualbox-hwe not apply anymore on the first SRU
-queuebot:#ubuntu-release- Unapproved: ksnakeduel (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
<LocutusOfBorg> not a big deal for me, but it might be if somebody else want to play the security update
<LocutusOfBorg> anyhow, feel free to do whatever you prefer :)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [sync] (bionic-proposed) [5.2.8-dfsg-10]
-queuebot:#ubuntu-release- Unapproved: kreversi (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: konquest (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
<Laney> mapreri: we need to remove myspell-hr if we accept the new lo-dictionaries, right?
-queuebot:#ubuntu-release- Unapproved: kmousetool (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted example-content [source] (bionic-proposed) [50]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.32.5+18.04]
-queuebot:#ubuntu-release- Unapproved: kmag (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kigo (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.40+18.04.3 => 2.41+18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.41+18.04]
-queuebot:#ubuntu-release- Unapproved: kgoldrunner (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted awscli [source] (bionic-proposed) [1.14.44-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted perl [sync] (bionic-proposed) [5.26.1-6]
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.13.12-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (bionic-proposed) [1:52.7.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted umbrello [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: bugz (bionic-proposed/universe) [0.10.1-4 => 0.10.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bugz [sync] (bionic-proposed) [0.10.1-5]
-queuebot:#ubuntu-release- Unapproved: accepted lskat [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: polipo (bionic-proposed/universe) [1.1.1-7 => 1.1.1-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polipo [sync] (bionic-proposed) [1.1.1-8]
-queuebot:#ubuntu-release- Unapproved: scanbd (bionic-proposed/universe) [1.5.1-1build1 => 1.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted scanbd [sync] (bionic-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- Unapproved: wondershaper (bionic-proposed/universe) [1.1a-8 => 1.1a-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wondershaper [sync] (bionic-proposed) [1.1a-9]
<mapreri> Laney: yes, all binaries would be superseded, wouldn't the source be automatically removed or something?
<slangasek> xnox: followed up on the bug and unassigned
<xnox> slangasek, tah
-queuebot:#ubuntu-release- Unapproved: gnome-music (bionic-proposed/universe) [3.28.0.1-1 => 3.28.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.3-1 => 0.40.4-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: python-msgpack (bionic-proposed/main) [0.5.6-0ubuntu1 => 0.5.6-1] (ubuntu-desktop, ubuntu-server) (sync)
<Laney> mapreri: AFAIK we don't have anything like that
<tsimonq2> According to the transition tracker, I missed three packages for the Qt transition. That should be it.
-queuebot:#ubuntu-release- Unapproved: deepin-qt5dxcb-plugin (bionic-proposed/universe) [1.1.8.4+ds-1 => 1.1.8.4+ds-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: uim (bionic-proposed/universe) [1:1.8.6+gh20180114.64e3173-2build1 => 1:1.8.6+gh20180114.64e3173-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted deepin-qt5dxcb-plugin [source] (bionic-proposed) [1.1.8.4+ds-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted uim [source] (bionic-proposed) [1:1.8.6+gh20180114.64e3173-2build2]
-queuebot:#ubuntu-release- Unapproved: dde-qt5integration (bionic-proposed/universe) [0.2.8.3+git20180208-1 => 0.2.8.3+git20180208-1build1] (no packageset)
<tsimonq2> Ah, not in a packageset. Cool.
-queuebot:#ubuntu-release- Unapproved: accepted dde-qt5integration [source] (bionic-proposed) [0.2.8.3+git20180208-1build1]
<Laney> mapreri: I'll accept, but please could you file an RM? :-)
<mapreri> Laney: ack, will do later
<Laney> should be RoQAed out of sid I guess?
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-dictionaries [sync] (bionic-proposed) [1:6.0.3-2]
<Laney> or maybe they do have a thing like this there
<jbicha> it's arch:all so even in Debian it will need an explitir RM bug
 * Laney doesn't understand all the scripts in this area very well
-queuebot:#ubuntu-release- Unapproved: bind-dyndb-ldap (bionic-proposed/universe) [11.1-2 => 11.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (bionic-proposed/main) [4.3.5-3ubuntu6 => 4.3.5-3ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bind-dyndb-ldap [sync] (bionic-proposed) [11.1-3]
<jbicha> (explicit)
<slangasek> tumbleweed: why was the solution for python-xarray to add a badtest for a package that was only in -proposed, instead of disabling the new and failing tests in the source package?
-queuebot:#ubuntu-release- Unapproved: accepted kubrick [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ksudoku [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
<teward> release team: I see that nginx was accepted, thank you.  do you need to mark the FFe bug as handled, or should we just let it die off?
<Laney> teward: please close it, if it's accepted the FFe was implicitly approved
-queuebot:#ubuntu-release- Unapproved: python-pint (bionic-proposed/main) [0.8.1-1 => 0.8.1-2] (ubuntu-server) (sync)
<teward> Laney: ack.
<Laney> it'll probably get cleaned up eventually, but you can help that
<Laney> thanks!
<teward> Laney: helps when it's the bug I filed xD  just wanted to check.
<teward> Laney: it's been accepted to proposed but not yet released, so I assume that's "Fix Released" or "Fix Committed"?
<teward> released from proposed*
<teward> just want to make sure before I make a change :)
<nacc> teward: Fix commited, please
<teward> done.  i'll keep an eye for it to end up in bionic.  :)
<teward> (and not just in proposed)
<nacc> teward: thanks
<teward> yep.  *returns to kicking around an email gateway on his employer's network*
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.40 => 2.41] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (artful-proposed/universe) [2.40+17.10 => 2.41+17.10] (no packageset)
<sergiusens> infinity: hey there, do you mind looking at those two entries above for snapcraft? ^^
-queuebot:#ubuntu-release- Unapproved: autopkgtest (bionic-proposed/main) [5.3 => 5.3ubuntu1] (core)
<ginggs> would someone please accept autopkgtest from the bionic upload queue? this should fix its test failure on i386 and s390x
<bdmurray> I see the iso tracker has upgrade tests for Edubuntu and Mythbuntu. Should we drop those or is there a clear upgrade path from those flavors?
-queuebot:#ubuntu-release- Unapproved: kdevelop (bionic-proposed/universe) [4:5.2.1-1ubuntu3 => 4:5.2.1-1ubuntu4] (kubuntu)
<slangasek> bdmurray: we should drop them, since even if the tests fail there is no flavor team responsible for fixing them
-queuebot:#ubuntu-release- Unapproved: palapeli (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: qtubuntu (bionic-proposed/main) [0.64+17.10.20170707-0ubuntu6 => 0.64+17.10.20170707-0ubuntu7] (ubuntu-qt-packages)
<LocutusOfBorg> tsimonq2, ^^ this is really built against qtbase 5.9.5, please be careful about installation of the package next time!
<LocutusOfBorg> somebody please approve it
<tsimonq2> LocutusOfBorg: waaat, I thought qtbase had published
<tsimonq2> Sorry.
<LocutusOfBorg> no problem, this is a good learning experience :)
 * LocutusOfBorg goes to sleep
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (bionic-proposed/main) [3.22.29-3ubuntu1 => 3.22.29-3ubuntu2] (ubuntu-desktop)
<tumbleweed> slangasek: was hoping the test issues would be dealt with upstream
<slangasek> tumbleweed: ok; but as a rule I don't think we should badtest newly-broken things in -proposed without extenuating circumstances
<tumbleweed> fair enough
<slangasek> I am always liberal with badtest'ing things that are broken in the release pocket, because they are already broken in the release :)
<tumbleweed> given the single reverse-dep it seemed like much of a muchness either way
<tumbleweed> maintaining badtests vs maintaining a delta
<tumbleweed> but I guess the delta has an obvious maintainer :)
<slangasek> tumbleweed: the further difference is that adding a badtest hint weakens our CI
<slangasek> since if these tests fail /differently/, we don't know
<slangasek> s/these tests/the tests on this package/
-queuebot:#ubuntu-release- Unapproved: qtubuntu (bionic-proposed/main) [0.64+17.10.20170707-0ubuntu6 => 0.64+17.10.20170707-0ubuntu7] (ubuntu-qt-packages)
<mitya57> ^^ Sorry for duplicate upload, I did not notice there was -0ubuntu7 by LocutusOfBorg in the queue already. Anyway mine should be identical, so please approve it.
-queuebot:#ubuntu-release- Unapproved: plymouth (bionic-proposed/main) [0.9.3-1ubuntu6 => 0.9.3-1ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted conntrack-tools [source] (bionic-proposed) [1:1.4.4+snapshot20161117-6ubuntu2]
<slangasek> tsimonq2: what's the story with all the packages with an unsatisfiable dep on qtbase-abi-5-9-5?
-queuebot:#ubuntu-release- Unapproved: accepted kspaceduel [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
<slangasek> tsimonq2: n/m, resolved now after a reload of the page
-queuebot:#ubuntu-release- Unapproved: accepted ksnakeduel [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kreversi [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted konquest [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmousetool [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmag [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0~beta1-6799-g391e5f16d-0ubuntu1 => 2.4.0~beta2-6865-gec43e47e6-0ubuntu1] (ubuntu-server)
#ubuntu-release 2018-04-17
-queuebot:#ubuntu-release- Unapproved: avahi (xenial-proposed/main) [0.6.32~rc+dfsg-1ubuntu2.1 => 0.6.32~rc+dfsg-1ubuntu3] (core)
<tsimonq2> slangasek: Wat? O_o
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (bionic-proposed/main) [3.22.29-3ubuntu1 => 3.22.30-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu2 => 3.28.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: scim-anthy (bionic-proposed/universe) [1.2.7-6build2 => 1.2.7-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted scim-anthy [sync] (bionic-proposed) [1.2.7-7]
-queuebot:#ubuntu-release- Unapproved: remote-logon-service (bionic-proposed/universe) [1.0.1.1-2 => 1.0.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted remote-logon-service [sync] (bionic-proposed) [1.0.2.0-1]
-queuebot:#ubuntu-release- Unapproved: animals (bionic-proposed/universe) [201207131226-2 => 201207131226-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted animals [sync] (bionic-proposed) [201207131226-2.1]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.0-0ubuntu6 => 1:3.28.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-jsondiff (bionic-proposed/universe) [1.1.1-1 => 1.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-ruffus (bionic-proposed/universe) [2.6.3+dfsg-4 => 2.6.3+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-jsondiff [sync] (bionic-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-ruffus [sync] (bionic-proposed) [2.6.3+dfsg-5]
-queuebot:#ubuntu-release- Unapproved: python-csb (bionic-proposed/universe) [1.2.5+dfsg-1 => 1.2.5+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-csb [sync] (bionic-proposed) [1.2.5+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: python-qcli (bionic-proposed/universe) [0.1.1-2 => 0.1.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-qcli [sync] (bionic-proposed) [0.1.1-3]
<slangasek> tsimonq2: I don't know why it was showing up that way before but it's cleared up
<tsimonq2> slangasek: OK.
<tsimonq2> slangasek: Otherwise, I didn't break anything? :)
<slangasek> tsimonq2: so far as I saw
<tsimonq2> slangasek: Cool.
<tsimonq2> 4232 tests in the amd64 bionic huge queue o__o
<slangasek> yeah who's been uploading things
<tsimonq2> True.
<tsimonq2> Â¯\_(ã)_/Â¯
<valorie>  good thing we can't check things like that
<tsimonq2> hah
<tsimonq2> Honestly though, perl is most of that...
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.41+18.04 => 2.41+18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.41+18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (bionic-proposed) [0.9.3-1ubuntu7]
<Mirv> so familiar sight http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src :)
-queuebot:#ubuntu-release- Unapproved: rejected gtk+3.0 [source] (bionic-proposed) [3.22.29-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (bionic-proposed) [3.22.30-1ubuntu1]
<infinity> Mirv: I may have decided to slightly exercise the queues a little bit.
<infinity> And perl too.
-queuebot:#ubuntu-release- Unapproved: rejected qtubuntu [source] (bionic-proposed) [0.64+17.10.20170707-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [source] (bionic-proposed) [0.64+17.10.20170707-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted palapeli [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdevelop [source] (bionic-proposed) [4:5.2.1-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (bionic-proposed) [4.3.5-3ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (bionic-proposed) [5.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (bionic-proposed) [0.40.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted pencil2d [sync] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-msgpack [sync] (bionic-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pint [sync] (bionic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kigo [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kgoldrunner [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (bionic-proposed) [2.4.0~beta2-6865-gec43e47e6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-bep-debounce [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.415 => 1.416] (core)
-queuebot:#ubuntu-release- Unapproved: python-msgpack (bionic-proposed/main) [0.5.6-0ubuntu1 => 0.5.6-1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: volume-key (bionic-proposed/universe) [0.3.9-3 => 0.3.9-4] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.416]
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/universe) [1.0.7 => 1.0.8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ukui-menu (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-121.145~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-121.145~14.04.1]
-queuebot:#ubuntu-release- Unapproved: xfpanel-switch (bionic-proposed/universe) [1.0.6-0ubuntu1 => 1.0.7-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: brltty (bionic-proposed/main) [5.5-4ubuntu1 => 5.5-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: fonts-arphic-uming (bionic-proposed/main) [0.2.20080216.2-7ubuntu2 => 0.2.20080216.2-7ubuntu3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libmbim (bionic-proposed/main) [1.14.2-2.1 => 1.14.2-2.1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.15.16 => 4.15.0.17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (bionic-proposed/main) [4.15.0-15.16 => 4.15.0-17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-15.16 => 4.15.0-17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: make-dfsg (bionic-proposed/main) [4.1-9.1 => 4.1-9.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: sddm (bionic-proposed/universe) [0.17.0-1ubuntu4 => 0.17.0-1ubuntu5] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (bionic-proposed/main) [1.31.2-0ubuntu2 => 1.31.2-0ubuntu3] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (artful-proposed/main) [1.26.0-0ubuntu1 => 1.26.0-0ubuntu2] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (bionic-proposed/universe) [1.20.0-2ubuntu1 => 1.20.0-3ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.8]
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.0-0ubuntu2 => 2:12.0.0-0ubuntu3] (openstack, ubuntu-server)
<blackboxsw> RAOF: Wondering if there is time for a cloud-init 18.2-4-g05926e48-0ubuntu1~16.04.1 SRU release into artful and xenial. It's all queued and validated per bug #1759406
<ubot5`> bug 1759406 in cloud-init (Ubuntu) "sru cloud-init (17.2-35-gf576b2a2-0ubuntu1~16.04.1 update to 18.2-4-g05926e48-0ubuntu1)" [Medium,Confirmed] https://launchpad.net/bugs/1759406
<sergiusens> RAOF: hey, mind looking into accepting snapcraft into xenial- and artful-proposed?
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (bionic-proposed/main) [3.28.1-1ubuntu1 => 3.28.1-1ubuntu2] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: installation-locale (bionic-proposed/main) [1.7 => 1.7build1] (core)
<cjwatson> sil2100: ^-
<sil2100> On it!
-queuebot:#ubuntu-release- Unapproved: accepted installation-locale [source] (bionic-proposed) [1.7build1]
-queuebot:#ubuntu-release- Unapproved: rejected python-msgpack [sync] (bionic-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted volume-key [sync] (bionic-proposed) [0.3.9-4]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menu [source] (bionic-proposed) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xfpanel-switch [source] (bionic-proposed) [1.0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted brltty [source] (bionic-proposed) [5.5-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-arphic-uming [source] (bionic-proposed) [0.2.20080216.2-7ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (bionic-proposed) [1.14.2-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.17.18]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-17.18]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (bionic-proposed) [4.15.0-17.18]
-queuebot:#ubuntu-release- Unapproved: accepted make-dfsg [source] (bionic-proposed) [4.1-9.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm [source] (bionic-proposed) [0.17.0-1ubuntu5]
<sil2100> coreycb: hey! Looking at the python-oslo.versionedobjects upload for bionic now and was just wondering - you mention 'this reverts and changes the fix...' - I still see the old patch applied, not reverted, and wanted to know if that's intended
<coreycb> sil2100: hmm it should be reverted
<sil2100> coreycb: since I'd expect the previous fix to be reverted when reading this changelog entry, but yeah, maybe that's not what you had in mind
<sil2100> http://launchpadlibrarian.net/365992975/python-oslo.versionedobjects_1.31.2-0ubuntu2_1.31.2-0ubuntu3.diff.gz <- Fixing-uuid-coerce-function-for-unicode-non-uuid-form.patch is still in debian/patches/series
<coreycb> sil2100: well partially reverted i suppose
<sil2100> Or does this mean 'revert a piece of that fix from that patch'
<coreycb> sil2100: yes, that
<sil2100> Ok, then all good, this is what I wanted to know, thanks
<coreycb> sil2100: ok thanks.
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (bionic-proposed) [1.31.2-0ubuntu3]
<bdmurray> sil2100: Could you review my avahi upload in x-proposed?
<sil2100> bdmurray: sure thing, one moment
-queuebot:#ubuntu-release- Unapproved: gjs (bionic-proposed/main) [1.52.1-1 => 1.52.1-1ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.190 => 3.191] (ubuntu-desktop, ubuntu-server)
<foka> Hi! Is there a URL where I could read about how the "Unapproved: update-notifier" sync into Bionic work?
<foka> I was both horrified and pleasantly surprised to see that hugo (0.38-1) got synced a few days ago, replacing the 0.37.1-1 version which required a manual requestsync after the FeatureFreeze/DebianImportFreeze.
<jbicha> foka: what version of hugo do you want in bionic?
<slangasek> foka: drilling down into the entries on https://launchpad.net/ubuntu/+source/hugo/+publishinghistory shows you who synced the package (jbicha); you would have to ask him what his rationale was for syncing.  Because the package is not seeded in any Ubuntu flavor, it did not require manual review from the release team to be included, only a sync by an Ubuntu developer
<foka> slangasek, Thank you for your detailed explanation!  :-)
<foka> jbicha, Thank you so much for syncing Hugo!  A (tiny?) problem was that there was a regression in 0.38, leading to 0.38.1 and 0.38.2, but now 0.39 is out which is probably the best version right now.  :-)
<jbicha> ok, I was planning to sync 0.39 once launchpad picks it up from Debian
<foka> jbicha: Mind if I get back to you soon?  0.39 just came out yesterday, and 0.39-1 was uploaded to Debian some 12 hours ago  https://buildd.debian.org/status/package.php?p=hugo  and not showing up on packages.debian.org yet...
<foka> jbicha: Oh, cool!  Many thanks for keeping Hugo up-to-date!  I'm sure many Hugo users will be happy.  :-)
<jbicha> I selectively sync some universe packages late that are fairly standalone and where the new version seems helpful
<foka> jbicha: I sent a (Gitter) message to @bep (main Hugo author) as to whether he has discovered any bug or regression that would require a v0.39.1 bugfix release.  But yeah, v0.39 looks good so far.  Thank you very much jbicha!
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.31 => 0.96.24.32] (desktop-core, ubuntu-server)
<jbicha> but I won't be doing any hugo Stable Release Updates so I'll let you take care of any of that if you want
<teward> just a question, but I have a version numbering change for NGINX from 1.13.12 to 1.14.0 that has no other functional changes (the 1.14.0 branch was just released today and is essentially 1.13.12 that exists now).  Does this need an FFe or can this just be accepted once I upload it?
<foka> jbicha: True, Stable Release Updates (SRU), which, IIRC, happens after the final release (or the final freeze), and that follows a totally different process.
<teward> (I was going to file an FFe bug either way just in case though)
<cjwatson> teward: If it has no new features it doesn't need an FFe.  (This is not to say that the release team will necessarily accept a relatively late change though)
<foka> jbicha: But yes, thank you in advance for syncing hugo for us!  :-)
<foka> jbicha: I was wondering: could you sync golang-github-disintegration-imaging (1.4.1-1) and golang-github-spf13-pflag (1.0.1-1) while you are at it because hugo 0.39-1 was built with them on Debian?  :-)  Many thanks!
<teward> cjwatson: yeah it's up to the release team.  They did accept the 1.13.12 upload yesterday, though, so from that to today is not much bigger of a change.
-queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.13.12-0ubuntu1 => 1.14.0-0ubuntu1] (ubuntu-server)
<teward> there's precedent from 16.04 for this though; we ran into this on last LTS cycle but nginx released 1.10.x stable a day *after* we released 16.04; the version numbering change was in xenial-updates though, and then later in xenial-security when we started handling some security patches.
<teward> anyways, just wanted to make sure I didn't need an FFe bug.
-queuebot:#ubuntu-release- Unapproved: golang-github-disintegration-imaging (bionic-proposed/universe) [1.3.0-1 => 1.4.1-1] (no packageset) (sync)
<jbicha> foka: use requestsync to file a bug for golang-github-spf13-pflag, it has several rdepends so I'm not as comfortable with it
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-disintegration-imaging [sync] (bionic-proposed) [1.4.1-1]
<foka> jbicha: Good point about golang-github-spf13-pflag, thanks for the advice!  I'll do a requestsync.
<jbicha> explain why it's needed and what testing you've done to ensure it doesn't break other packages
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.41]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (artful-proposed) [2.41+17.10]
<sil2100> bdmurray: your avahi upload seems to revert changes from version ubuntu2.1 - were those conflicting/invalid/deprecated? I didn't see those mentioned in the changelog
<bdmurray> sil2100: Nope, that's a blunder.
<sil2100> bdmurray: I'll reject it in that case, poke me once you re-upload and I'll re-review
-queuebot:#ubuntu-release- Unapproved: rejected avahi [source] (xenial-proposed) [0.6.32~rc+dfsg-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: avahi (xenial-proposed/main) [0.6.32~rc+dfsg-1ubuntu2.1 => 0.6.32~rc+dfsg-1ubuntu2.2] (core)
<bdmurray> sil2100: sorted ^^
<slangasek> xnox: component-mismatches seems confused now about golang-github-spf13-cobra and its dep tree, despite me marking golang-github-ubuntu-ubuntu-report-dev Extra-Exclude; do you have any insights here?
<sil2100> bdmurray: thanks!
<jbicha> slangasek: is that because of Built-Using?
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (xenial-proposed) [0.6.32~rc+dfsg-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.10-0ubuntu1 => 8.0.5.11-0ubuntu1] (no packageset)
<foka> jbicha: On second thought, I think it is okay to keep golang-github-spf13-pflag the way it is, i.e., I think I won't bother with a requestsync, as the upstream Hugo is actually still using an older version and works just fine with it.
<sdeziel> I've been warned that it's probably too late for 18.04 but I opened LP: #1764807
<ubot5`> Launchpad bug 1764807 in zfs-linux (Ubuntu) "[wishlist] please add zfsutils-linux to the seed(s)" [Undecided,New] https://launchpad.net/bugs/1764807
<jbicha> foka: ok, that's easier for me too :)
<slangasek> jbicha: it sure is
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: lxd (bionic-proposed/main) [3.0.0-0ubuntu3 => 3.0.0-0ubuntu4] (edubuntu, ubuntu-server)
<Kamilion> ctrl-f'd through the backlog, but I didn't see anything relating to xen; looks like xen 4.10 isn't going to make it into bionic, but will it show up in a point release later?
<nacc> smb: --^ ?
<Kamilion> 4.6 eventually took over for 4.5 on xenial; i didn't really encounter any problems with that transition
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.0-2 => 3.28.1-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: musescore-sftools (bionic-proposed/universe) [20180222-2 => 20180325-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted musescore-sftools [sync] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New binary: musescore-sftools [ppc64el] (bionic-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [s390x] (bionic-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [amd64] (bionic-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [arm64] (bionic-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [armhf] (bionic-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fluidr3mono-gm-soundfont (bionic-proposed/universe) [2.315-2 => 2.315-4] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- New binary: musescore-sftools [i386] (bionic-proposed/universe) [20180325-1] (no packageset)
<jbicha> ^ the ffe for sftools & soundfont is bug 1761272
<ubot5`> bug 1761272 in musescore-sftools (Ubuntu) "Please sync musescore-sftools 20180325-1 (universe) and fluidr3mono-gm-soundfont 2.315-4 (universe) from Debian testing (main)" [Undecided,Fix released] https://launchpad.net/bugs/1761272
<slangasek> infinity: oh hey, and upstream response on your failing 31-bit tests, saying that it's a kernel bug
<slangasek> s/and/an/
<xnox> slangasek, as per pm, it's a built-using dependency chain trying to pull in source packages into main.
<slangasek> yes
<slangasek> xnox: arguing it with seb now on #distro ;)
<xnox> hehe
<xnox> and you had to quote an email from me about it too =)
<xnox> i'm glad i picked a memorable topic for said email, and was able to quote it =))))))
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu536 => 20101020ubuntu537] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu537]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.28 => 2.408.29] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.4-1 => 1.8.7-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.16 => 1:18.04.17] (core)
-queuebot:#ubuntu-release- Unapproved: ibus (bionic-proposed/main) [1.5.17-3ubuntu3 => 1.5.17-3ubuntu4] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.521 => 2.522] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: corosync (bionic-proposed/main) [2.4.2-3ubuntu1 => 2.4.3-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pacemaker (bionic-proposed/main) [1.1.18~rc4-1ubuntu1 => 1.1.18-0ubuntu1] (ubuntu-server)
<tjaalton> so, aiui it's only systemd autopkgtest on i386 which is blocking bind/isc-dhcp/bind-dyndb-ldap/freeipa from migrating?
<tjaalton> and that test seems to be failing quite often
<tsimonq2> Wait... did qtbase just migrate?
<tsimonq2> Meaning, that Qt transition took a little more than a day?!?
<tsimonq2> O_O!!
<tsimonq2> YAY
<valorie> \o/
-queuebot:#ubuntu-release- Unapproved: sddm (bionic-proposed/universe) [0.17.0-1ubuntu5 => 0.17.0-1ubuntu6] (kubuntu)
<teward> is it... unusual when autopkgtests fail because it can't find a specific package that is totally unrelated to the check being run?  (Two of the s390x nginx-related autopkgtests were stuck as "Regression" statuses only because the environments couldn't find `haveged` at the time, even though it's in the repositories)
<teward> (both failures were for s390x, and went away on a rerun)
-queuebot:#ubuntu-release- Unapproved: apparmor (bionic-proposed/main) [2.12-4ubuntu4 => 2.12-4ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: ifupdown (xenial-proposed/main) [0.8.10ubuntu1.2 => 0.8.10ubuntu1.3] (core)
<jdstrand> fyi, that apparmor ^ is just profile fixes
<xnox> teward, i know at least one case of non-atomic migrations from -proposed to -release; e.g. if a package is migrating, it may be deleted from -release and -proposed, but not yet published in -release, thus one can have intermittent state of "omg no package foo"
<xnox> teward, the only way to fix this, as far as I understand, is to make a package migration process a multi-pass process. Publish into -release, then in another publishing cycle "clean-up" -proposed. Like it is done for e.g. -proposed -> -updates publication of SRUs.
<xnox> teward, but in this case, haveged has not moved since artful.... do you have logs? or have you worked out what was the bug for haveged? the autopkgtest instance temporary networking failure?
<teward> no idea, it succeeded with other packages, and then only died on haveged; I was reading the logs and couldn't figure it out, it almost looked like someone had never run `apt-get update` on a fresh Ubuntu install so it doesn't know if a package exists or not.  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/n/nginx/20180417_130943_7f698@/log.gz was the one I remembered
<teward> to bookmark ...
<teward> xnox: ^
<teward> rerunning the autopkgtests made them resolve, so it might've been a temporary glitch
<teward> i'm a tad annoyed the system never *told* me autopkgtests failed
<teward> until today when it said it'd been sitting in proposed for a day
<xnox> teward, you should be getting emails, about your own upload, that it is stuck in proposed. I definately get such emails on daily basis.
<xnox> teward, were you the uploader?
 * xnox reads the log to see "the glitch"
<xnox> teward, ok, it is weird. In "test bed setup" i see that bionic-proposed is updated, but i do not see that 'bionic InRelease' is updated.
<xnox> and then later, i would expect haveged to not have installation candidate.
<xnox> it is odd that "bionic InRelease" is not fetched as part of the test bed setup, but bionic-proposed.... was.
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.11-0ubuntu1]
 * tsimonq2 thinks it would be nice to see which packages I have in devel-proposed; I lose track sometimes.
-queuebot:#ubuntu-release- Unapproved: ctioga2 (bionic-proposed/universe) [0.14.1-1 => 0.14.1-2] (no packageset) (sync)
<xnox> teward, opened https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1764884 to not forget about this.
<ubot5`> Ubuntu bug 1764884 in autopkgtest (Ubuntu) "An odd glitch in autopkgtest - package has no install candidates" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted ctioga2 [sync] (bionic-proposed) [0.14.1-2]
<tsimonq2> slangasek (or any other AA that's around): Could I please get lightdm-settings processed? It's a pretty small package with simple copyright, and both Ubuntu MATE and Ubuntu Budgie have expressed interest in having the package.
-queuebot:#ubuntu-release- New source: lightdm-settings (bionic-proposed/primary) [1.1.4-0ubuntu1]
<slangasek> tsimonq2: enotime today, sorry
<tsimonq2> slangasek: ack
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.8-dfsg-10ubuntu18.04.1 => 5.2.10-dfsg-1ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-1ubuntu18.04.1]
<teward> xnox: yes I was, at least of 1.13.12 which failed the tests.
<teward> and ACK on the bug being made on this
<teward> xnox: also sorry for slow responsiveness, fighting horrible internet today >.>
<teward> would an archive admin be able to accept nginx 1.14.0-0ubuntu1 into bionic-proposed?  Between 1.13.12 and 1.14.0 is no functional changes of any kind, just a version string shift.  Back in 16.04 NGINX released 1.10.x stable a day or two *after* Xenial release, so we post-release SRU'd the version string change, but I'd love to get that in before Final Freeze so that bionic itself has 1.14.0 (and so we don't need to do a post-release SRU)
<teward> SRU/MRE*
#ubuntu-release 2018-04-18
-queuebot:#ubuntu-release- Unapproved: focuswriter (bionic-proposed/universe) [1.6.11-1 => 1.6.12-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted focuswriter [sync] (bionic-proposed) [1.6.12-1]
-queuebot:#ubuntu-release- Unapproved: ostree (bionic-proposed/universe) [2018.4-1 => 2018.4-2] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gnumeric (bionic-proposed/universe) [1.12.35-1 => 1.12.35-1.1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: flent (bionic-proposed/universe) [1.2.1-1 => 1.2.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flent [sync] (bionic-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- Unapproved: mugshot (bionic-proposed/universe) [0.3.2-0ubuntu1 => 0.4.0-0ubuntu1] (ubuntustudio, xubuntu)
<bluesabre> ^ No functional changes, only translations, URLs, and version number bump to stable
-queuebot:#ubuntu-release- Unapproved: xubuntu-docs (bionic-proposed/universe) [18.04 => 18.04.1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [17.03.2-0ubuntu5 => 17.12.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (bionic-proposed) [17.12.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [17.03.2-0ubuntu1~16.04.1 => 17.03.2-0ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fslint (bionic-proposed/universe) [2.44-3 => 2.44-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fslint [sync] (bionic-proposed) [2.44-4]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (bionic-proposed/universe) [18.04.15 => 18.04.16] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.34.1 => 0.35] (core)
-queuebot:#ubuntu-release- Unapproved: keyutils (bionic-proposed/main) [1.5.9-9.2ubuntu1 => 1.5.9-9.2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: libreoffice-dictionaries (bionic-proposed/main) [1:6.0.3-2 => 1:6.0.3-3] (personal-gunnarhj, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: jss (bionic-proposed/universe) [4.4.2-6 => 4.4.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jss [sync] (bionic-proposed) [4.4.3-1]
-queuebot:#ubuntu-release- Unapproved: freeipa (bionic-proposed/universe) [4.7.0~pre1+git20180411-1 => 4.7.0~pre1+git20180411-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: dogtag-pki (bionic-proposed/universe) [10.6.0~beta2-3 => 10.6.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dogtag-pki [sync] (bionic-proposed) [10.6.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [sync] (bionic-proposed) [4.7.0~pre1+git20180411-2]
-queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.2 => 18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted keyutils [source] (bionic-proposed) [1.5.9-9.2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu6 => 1:2.11+dfsg-1ubuntu7] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (bionic-proposed/universe) [1.7-0ubuntu1 => 1.7-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xfsprogs (bionic-proposed/main) [4.9.0+nmu1ubuntu1 => 4.9.0+nmu1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [0.9.23-dfsg-2build1 => 0.9.24-dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.8-dfsg-7 => 5.2.10-dfsg-1] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.8-2 => 5.2.10-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (bionic-proposed) [0.9.24-dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (bionic-proposed) [5.2.10-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-17.18]
<LocutusOfBorg> please accept virtualbiox, this upload should make it work again as guest, with the GL native implementation
<LocutusOfBorg> (not enabled by default, I'll do a call for testing later once it is accepted!)
-queuebot:#ubuntu-release- Unapproved: kdeclarative (bionic-proposed/universe) [5.44.0-0ubuntu2 => 5.44.0-0ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-3 => 1.7.0-5] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.0.8 => 1.0.9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.3 => 0.6.5.11-1ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu20 => 0.6.5.6-0ubuntu21] (no packageset)
-queuebot:#ubuntu-release- New: accepted musescore-sftools [amd64] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [armhf] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [ppc64el] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [arm64] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [s390x] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [i386] (bionic-proposed) [20180325-1]
-queuebot:#ubuntu-release- Unapproved: accepted thermald [sync] (bionic-proposed) [1.7.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (bionic-proposed) [2.12-4ubuntu5]
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (bionic-proposed/main) [18.04.4 => 18.04.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (bionic-proposed/universe) [1.1.2-0ubuntu1 => 1.1.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-1ubuntu18.04.1 => 5.2.10-dfsg-2ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-2ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (bionic-proposed) [3.28.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mate-terminal [source] (bionic-proposed) [1.20.0-3ubuntu1]
<Laney> seb128: i'm reviewing this gjs... it seems a bit concerning at this point - how confident are you in it?
<Laney> it's hard to tell where the patches are from since they aren't properly attributed in d/patches/*.patch
<Laney> and there are different GC fixes in master atm
<Laney> which aren't in this upload
<Laney> so... it's confusing
<sergiusens> sil2100: hello there. Are you the current guardian of ubuntu-image? It seems to be blocking snapcraft on bionic due to an unrelated error on booting the created image
<seb128> Laney, duflu and Trevinho are confident it's not going to create issues and the problem it addresses as being judged as important for the release by will
<Laney> I understand that fixing what is apparently a big leak is important
<seb128> Laney, duflu mentioned on the bug that there are more fixes that could be backported indeed, but the ones in master didn't address the most important issue from what I understood
<Laney> This upload is quite difficult to review though
<sil2100> sergiusens: hey!
<seb128> right, I appreciate that, I had that conversation before upload with duflu on -desktop as you might have read
<sil2100> sergiusens: yeah, let me take a look
<sil2100> sergiusens: one ADT test there is flaky recently, it might be that
<seb128> Laney, it basically going to down on whether we trust duflu/Trevinho opinion on the fix
<Laney> not really
<sil2100> sergiusens: ok, re-running those, it looks like the usual flakyness ;/ Wasn't so flaky before bionic
<Laney> We could not have to go on trusting opinions if we use the SRU process to verify the fix
<Laney> in any event I would really appreciate proper attribution
<seb128> Laney, you mean "use the SRU process"? willcooke said he would do a call for testing once it's in proposed
<seb128> Laney, I can ask duflu to fix the attribution thing tomorrow, I'm unsure who wrote the patches and where he got them from
<seb128> he's eod by now though
<Laney> two of them are from https://gitlab.gnome.org/GNOME/gjs/merge_requests/114, which I found by searching
<ubot5-ng> GNOME bug (Merge request) 114 in gjs "Queue a GC when a toggle reference goes from >1 to 1" (comments: 15) [Opened]
<Laney> there is another patch that I can't find the source of though
<seb128> the cairo regression fix?
<seb128> that's from master afaik, dunno why they didn't commit it in .52 as well
<Laney> yes
<Laney> it says "Unreviewed" on it
<Laney> ok
<seb128> Laney, https://gitlab.gnome.org/GNOME/gjs/commit/8510bede
<seb128> the upstream commit includes that "Unreviewed" for some reason
<Laney> alright, so again proper attribution in the patches please
<seb128> like renaming it git_ and writting "backport from master" in the changelot?
<seb128> changelog
<Laney> Origin: upstream, <url>
<seb128> k, I though we usually didn't bother for backports of upstream commit
<seb128> people usually seem to throw a git format-patch patch in there
<seb128> but ok, if you want I can do that
<seb128> is the upload fine then once the attribution question sorted out?
<Laney> those are just things that make it harder to review
<seb128> I'm unsure we addressed the fact that you find the commits not easy to review or what would make it feel better about those
<seb128> right
<seb128> I can fix that part
<Laney> otherwise, I don't know, I'm worried about having a different behaviour here and that we'll be on our own when it comes to debugging
<seb128> I share that concern
<Laney> we'll have patches which aren't upstream, and we won't have patches which are
<seb128> but upstream isn't acting on a tempo that works for us
<Laney> and it's final freeze tomorrow
<Laney> which means any time to react and fix things is very limited
<seb128> right
<seb128> I argued about that yesterday on -desktop
<darkxst> Laney, I was hoping to do a proper review of the patches last night but its been a crazy week
<Laney> ok, I didn't follow that
<Laney> hey darkxst
<seb128> but our options are basically to take that upload
<seb128> or to have a big leak in the release
<seb128> will and others fear it might lead to bad reviews/user opinion
<Laney> and have more managed testing by using an SRU
<darkxst> Laney that is my feeling too from a quick review of patches
<seb128> will & duflu believed it would be a big error to release with that leak
<seb128> willcooke, ^ the gjs fix is being nacked it sounds like
<Laney> do they remember that upgrades aren't turned on until .1?
<seb128> yes
<Laney> right...
<seb128> seems like the interweb is already hating on us for thinking about releasing with a such leak
<seb128> and they fear it builds up as a negative PR against the release
<seb128> anyway I'm just the messenger there
<Laney> would it be more hateful to release with a buggy GC?
<Laney> or cause slowdowns or something
<seb128> that's the point where I said I trusted duflu & Trevinho
<seb128> they both believe it's not possible/likely
<seb128> and duflu said it tested it to no end
<didrocks> (I don't think "when people upgrade" is something to take into account as people reviewing/PReleasing/making noise about it are just installing it fresh in a VM/machine IMHO)
<Laney> OK, please remove the pressure from the press from me.
<seb128> I'm just the messenger there, I'm relying the argument that were made to me when I pushed back sponsoring yesterday
<darkxst> seb128, I am not against landing the patches, but wouldnt personally do it this late in the cycle
<seb128> neither would I
<seb128> but we are there now
<seb128> it's late with an issue some people arguing we can't release with
<seb128> so our options are limited
<Laney> Being able to say that we are carefully considering these fixes rather than rushing them in to satisfy some bad headlines is a fine story.
<seb128> " and duflu said it tested it to no end"
<seb128> I wrote that just before
<seb128> unsure if you saw?
<seb128> Trevinho and duflu believe it's a right move
<Laney> I did see that
<Laney> I know!
<seb128> I wouldn't say we are rushing
<Laney> But that's not the same as giving the change to everyone is it?
<seb128> no
<seb128> as said the people who know the best that stack in our team judge it's the right call at this point
<seb128> I don't know that codebase enough to judge
<Laney> ok, I think I abstain
<sergiusens> thanks sil2100
<Laney> someone that's not in the same team should review things like this
<seb128> Laney, k, I can understand that
<seb128> yeah, in fact I was not expecting you to pick on that
<seb128> but thanks for the review/sharing your opinion!
<darkxst> seb128, did you know the nvidia prop driver leaks caches into the reported gnome-shell memory usage that is actually in GPU RAM?
<darkxst> its a complex world and the reported gnome-shell memory usage is not always accurate
<Laney> I don't see a particular leak in the gnome-shell process here either
<willcooke> Wimpress, is that the same issue you mentioned re: nvidia driver ^
<seb128> duflu has been testing on intel
<Laney> and it's been running since April 05
<seb128> so it's not an nvidia issue we are talking about
<seb128> Laney, https://irclogs.ubuntu.com/2018/04/16/%23ubuntu-desktop.html#t09:59 has more context if you are interested
<seb128> again I'm only the messenger/uploader here
<seb128> Laney, darkxst, I'm glad you guys don't see the leak, the bug linked to the upload shows a real problem with lot of users unhappy about it so let's not dismiss there is a problem
<Laney> I believe it, and I'm not dismissing it
<Laney> it is different to a problem that is urgent for everybody
<Laney> ok, that's me, I need someone else to make a decision on this thing
<seb128> "duflu, I'm not arguing against the issue or shooting the messenger, I just think you overstate the proper by making it sounds like it makes GNOME unusable for everyone"
<seb128> that's what I wrote on that log in pointed out
<seb128> said differently I'm on the same line as you are
<seb128> anyway
<seb128> if r-t is unhappy about the fix for release maybe we can at least get it approved in proposed and block it there and see how it goes/turn it into a SRU if needed
<seb128> at least if it's in proposed it would get more testing
<darkxst> seb128, that was only an example, I have spent alot of time over the years looking into -shell memomry leaks
<seb128> shame that nobody has been doing that in recent cycles
<seb128> or we wouldn't be there
<darkxst> it is impossible to tell from the surface what are caches etc
<seb128> I think you should give more credit to duflu
<seb128> he spent most of his cycle digging in gnome-shell performances issues and got several fixes commited upstream
<seb128> he probably understand things better than you think he does
<darkxst> seb128, I'm not arguing that he doesnt understand things, more that its super late to be hastily landing GC patches
<seb128> darkxst, I think "hastily" is wrong
<seb128> duflu has been testing those carefully for weeks from what he said
<darkxst> who else has tested them?
<seb128> in anything the issue is that it hasn't been hasted, if we had uploaded before he tested them they would be in
<darkxst> apart from a few developers?
<seb128> what's your point?
<seb128> what fixes/commits are tested by more than a few developers before being commited?
<seb128> none
<didrocks> chicken & egg argument here :)
<willcooke> If they get in to proposed then we can do a wide call for testing this week
<seb128> right, I asked about that earlier but that didn't get a response
<seb128> anyway I need to get some food, I didn't eat anything since 7am and I feeling weak, back in half an hour
<willcooke> the people in the desktop team best qualified to comment on the suitablility of that patch say that its good, so I would really like to get more eyes on it from the general community
<jbicha> willcooke: PPA then?
<seb128> PPA doesn't give us enough visibility
<seb128> or at least less
<seb128> and if it's in proposed it can be a 0 day SRU
<willcooke> well, I really want it in for release so that would add more delay wouldn';t it?
<willcooke> what seb128 said
<seb128> Laney, willcooke, I need to talk to Trevinho later or duflu tomorrow, but upstream commited that to master 6 hours ago, https://gitlab.gnome.org/GNOME/gjs/commit/a6b6fc1342
<seb128> which I wonder is supposed/could address the same problem in a different way
<seb128> though upstream didn't comment on the other merge request/didn't close it as superseeded
<seb128> but unsure changing our strategy at this point would be wise
<seb128> even if it's commited in master it didn't get more testing than our patch
<seb128> and duflu made the work to verify that the patches he included fixes the issue we want to see resolved
<Laney> I think you've made your case
<seb128> we would have to redo the validation work on that other commit
<seb128> k, I guess that's a polite "please shut up now" :p
<seb128> which I guess is the signal I should really go and grab something to eat :)
<seb128> bbiab
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.0-0ubuntu5 => 3.28.1-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
<Laney> sil2100: or apw: in case you missed me saying above; please review gjs
<Laney> as you can see people from the desktop team are lobbying for it
<Laney> but I'm also in that team so I would like to not be the one deciding since it seems potentially risky
<Laney> (garnacho is still hoping for it to go in upstream though, I just asked him in #gnome-shell)
<willcooke> the same patch Laney?
<Laney> yeah
<willcooke> thx
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (bionic-proposed) [3.191]
-queuebot:#ubuntu-release- Unapproved: xfsprogs (trusty-proposed/main) [3.1.9ubuntu2 => 3.1.9ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32]
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.0-2 => 3.28.1-1] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fluidr3mono-gm-soundfont [sync] (bionic-proposed) [2.315-4]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.17]
-queuebot:#ubuntu-release- Unapproved: peony-extensions (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.1-0ubuntu2] (no packageset)
<LocutusOfBorg> apw, can you please remove hedgewars on ppc64el binaries? they have been building by luck, but never been supported at all, a simple no-change rebuild should make the FTBFS again, I already asked to remove such architectures in Debian too
<LocutusOfBorg> I tried a rebuild, but seriously, the support for BE machines is just broken
-queuebot:#ubuntu-release- Unapproved: peony (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.1-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [sync] (bionic-proposed) [1.8.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted ibus [source] (bionic-proposed) [1.5.17-3ubuntu4]
<cjwatson> LocutusOfBorg: ... abstaining on the general issue here, but you know that ppc64el isn't BE, right?
<LocutusOfBorg> cjwatson, let me do things more clear, thanks!
<LocutusOfBorg> upstream provides a clang-based pascal->C conversion stuff that makes things build even without fpc compiler
<LocutusOfBorg> but this sucks :)
<LocutusOfBorg> and yes, somebody should just bootstrap fpc everywhere, now it should work also on ppc64el
<ginggs> LocutusOfBorg: fpc support for ppc64el still not in released version
<LocutusOfBorg> this is why I prefer to just kick out hedgewars there
<LocutusOfBorg> we don't need to have angry bug reports about a game that crashes during online play :)
<LocutusOfBorg> people might loose and give the fault to the package and not their skills :p
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (bionic-proposed/universe) [1.3.7.10-1 => 1.3.7.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [source] (bionic-proposed) [1.3.7.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.416 => 1.417] (core)
<sforshee> Laney: we haven't been able to promote our raspi2 kernel for bionic because britney is waiting for arm64 test results. My understanding is that we won't get any test results because we don't have cloud images for it, what can we do about that?
<Laney> sforshee: Sure we do, but I'm not sure why results didn't come in, one second
<Laney> sforshee: hmm, ok, they all failed but I'm not sure right now why that didn't get associated with the request on update_excuses
<Laney> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/a/acpi-call/20180406_175859_b6c0d@/log.gz
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.522]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (bionic-proposed) [1.52.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm [source] (bionic-proposed) [0.17.0-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (bionic-proposed) [18.04.16]
<Laney> who's doing these reviews? I'd left a comment on the bug report for livecd-rootfs
<apw> no me
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (bionic-proposed) [4.9.0+nmu1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdeclarative [source] (bionic-proposed) [5.44.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (bionic-proposed) [18.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (bionic-proposed) [1.1.3-0ubuntu1]
<Laney> looks like seb128 got his gjs ;-)
-queuebot:#ubuntu-release- Unapproved: accepted peony-extensions [source] (bionic-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.417]
-queuebot:#ubuntu-release- Unapproved: accepted peony [source] (bionic-proposed) [1.1.1-0ubuntu2]
<sforshee> Laney: I don't suppose we have a console log for any of these test cases? Given that the kernel config for raspi2 is pretty specific to that hardware it wouldn't surprise me to find that it doesn't work in that environment
<Laney> sforshee: it's there at the end of that log
<sforshee> Laney: oh so that's all we got. In which case I think we can probably conclude that it's because of not having efi support
<seb128> Laney, yeah, I got lucky :)
-queuebot:#ubuntu-release- Unapproved: mate-menu (bionic-proposed/universe) [18.04.3-1 => 18.04.3-2ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-themes (bionic-proposed/universe) [3.22.16-1 => 3.22.16-2ubuntu1] (ubuntu-mate)
<sforshee> Laney: if we can get the results associated with the request in update_excuese we would at least be able to hint those
<Laney> sforshee: you can force-skiptest anyway
<Laney> if it's not supposed to work we probably shouldn't evne trigger those
<sforshee> agreed about that
<apw> Laney, i think you can only force-skiptest when a result is finished right ?
<apw> Laney, and britney thinks these are in flight
<Laney> apw: I think you can do it any time
<Laney> try it
<apw> vorlon:force-badtest linux-raspi2/all linux/all/armhf
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.35]
-queuebot:#ubuntu-release- Unapproved: youker-assistant (bionic-proposed/universe) [2.2.7-0ubuntu5 => 3.0.0-0ubuntu1] (ubuntukylin)
<Laney> skiptest
<apw> oh, derp, ok will try that
<apw> Laney, oh, but that will ignore all of its tests forever going forward right ?
<Laney> no it's just for the triggering package/version
<Laney> stgraber: wow at that upload :P
<Laney> didn't fancy doing a point release?
<stgraber> Laney: haha, no, not quite, we have a few more things we'll want in before we tag an actual point release
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu14 => 0.7.5-1ubuntu15] (core)
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.13-0ubuntu2 => 2.1.13-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.13-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted corosync [source] (bionic-proposed) [2.4.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnumeric [sync] (bionic-proposed) [1.12.35-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (bionic-proposed) [3.0.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (bionic-proposed) [3.22.16-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (bionic-proposed) [1.1.18-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.9]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-docs [source] (bionic-proposed) [18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (bionic-proposed) [18.04.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ostree [sync] (bionic-proposed) [2018.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.10-dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-dictionaries [sync] (bionic-proposed) [1:6.0.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted mugshot [source] (bionic-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted youker-assistant [source] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.32.3.2 => 2.32.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.32.3.2~14.04 => 2.32.5~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.32.3.2+17.10 => 2.32.5+17.10] (desktop-core, ubuntu-server)
 * apw looks at snapd
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32 => 0.96.24.34] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (bionic-proposed/main) [3.28.0-0ubuntu1 => 3.28.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.41+18.04.1 => 2.41+18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.41+18.04.2]
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (bionic-proposed/universe) [2.2.7-0ubuntu1 => 2.2.8-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-menus (bionic-proposed/universe) [1.1.2-0ubuntu1 => 1.1.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.1-1-g45564eef-0ubuntu1 => 18.1-5-g572ae5d6-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dogtag-pki (bionic-proposed/universe) [10.6.0-1 => 10.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dogtag-pki [source] (bionic-proposed) [10.6.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: freeipa (bionic-proposed/universe) [4.7.0~pre1+git20180411-2 => 4.7.0~pre1+git20180411-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (bionic-proposed) [4.7.0~pre1+git20180411-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected software-properties [source] (bionic-proposed) [0.96.24.34]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (bionic-proposed) [3.28.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kbuild (bionic-proposed/universe) [1:0.1.9998svn3149+dfsg-1 => 1:0.1.9998svn3149+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kbuild [sync] (bionic-proposed) [1:0.1.9998svn3149+dfsg-2]
<rbalint> hi, i'm seeking approval of two FFe-s, LP: #1764797 and LP: #1488620
<ubot5`> Launchpad bug 1764797 in unattended-upgrades (Ubuntu) "[FFe] please merge unattended-upgrades 1.1 (main) from Debian unstable (main)" [Critical,New] https://launchpad.net/bugs/1764797
<ubot5`> Launchpad bug 1488620 in initramfs-tools (Ubuntu) "[FFe] Add LZ4 support to initramfs-tools" [Low,New] https://launchpad.net/bugs/1488620
<rbalint> the first one is really critical, the second one is something that got a lot of positive feedback and it would be very nice to have in Bionic
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.0-0ubuntu3 => 2:12.0.1-0ubuntu1] (openstack, ubuntu-server)
<slangasek> tsimonq2: your ffmpeg sync is not migrating because it drops libav-tools, which has reverse-dependencies.  Please follow up.
<LocutusOfBorg> slangasek, I quickly checked, they are all "recommended"
<LocutusOfBorg> can we just ignore the issue?
<slangasek> LocutusOfBorg: are you responding wrt ffmpeg or something else?
<slangasek> LocutusOfBorg: if ffmpeg: p-m does not block on recommends.  Please look at the update_output results, those packages have depends, not recommends.
<LocutusOfBorg> yep, found that now, thanks! I was getting off the train
<LocutusOfBorg> alternate dependencies are fine? e.g. python*-woo
<rbalint> slangasek: i'm about to upload FFe-approved fix for LP: #1764220, can i go ahead now?
<ubot5`> Launchpad bug 1764220 in dpkg (Ubuntu) "[FFe] dpkg zstd support" [Undecided,Triaged] https://launchpad.net/bugs/1764220
<slangasek> rbalint: yes you can
<slangasek> LocutusOfBorg: proposed-migration checks for installability of the package, and does a very reliable job of it
-queuebot:#ubuntu-release- Unapproved: kbuild (bionic-proposed/universe) [1:0.1.9998svn3149+dfsg-2 => 1:0.1.9998svn3149+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kbuild [sync] (bionic-proposed) [1:0.1.9998svn3149+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-1 => 5.2.10-dfsg-2] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.10-1 => 5.2.10-2] (no packageset) (sync)
<rbalint> slangasek: thanks, it lands in a few minutes
<LocutusOfBorg> bouncing email for maintainer field are RC in debian ^^ I fixed vbox now
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (bionic-proposed) [5.2.10-2]
<slangasek> rbalint: wrt initramfs-tools, I'm nacking this; it's too late in the cycle, not a critical bug, and doesn't have the same rationale as the dpkg changes for needing to be landed in previous release by GA
<tsimonq2> slangasek: ack
<rbalint> slangasek: :-(, but ok
-queuebot:#ubuntu-release- Unapproved: dpkg (bionic-proposed/main) [1.19.0.5ubuntu1 => 1.19.0.5ubuntu2] (core)
<jbicha> slangasek: interested in removing gksu? bug 1740618
<ubot5`> bug 1740618 in umit (Ubuntu) "Remove gksu from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1740618
<slangasek> jbicha: reverse-depends points a finger at peony-extensions which is not in your task list?
<slangasek> jbicha: ah, has just been resolved to an NBS; removing
<rbalint> slangasek: do you have an opinion on the unattended-upgrades FFe, too?
<slangasek> rbalint: sorry, I have it queued up but haven't been able to review it yet (which means my opinion is that I think it should be approved, but I need to read the fine print)
<rbalint> slangasek: ok, np, thanks!
<fossfreedom> hi - anyone around that can help me diagnose why both the 32bit and 64bit daily Ubuntu Budgie 18.04 is booting straight to the live session - seems to miss the installer
<jbicha> fossfreedom: did that happen with the Final Beta also?
<slangasek> jbicha: if you believe Debian bug #496448 is sufficient rationale for removal of macchanger-gtk+libui-dialog-perl independent of gksu, can you please open that as a separate bug?  I do not consider a Recommends: on a removed package to be grounds for removal, and solving a Recommends: on a removed package by removing the recommending package doesn't do anything to improve the user's experience
<ubot5`> Debian bug 496448 in libui-dialog-perl "libui-dialog-perl: Dialog backend allows execution of arbitrary shell commands (CVE-2008-7315)" [Grave,Open] http://bugs.debian.org/496448
<slangasek> on upgrade
<slangasek> fossfreedom: LP: #1763739 and I'm looking into it (currently on xubuntu)
<ubot5`> Launchpad bug 1763739 in ubiquity (Ubuntu) "[xubuntu, budgie & mate] ISO boots directly to desktop" [Critical,Triaged] https://launchpad.net/bugs/1763739
<fossfreedom> thanks slangasek
<flocculant> fossfreedom: I had seen it - and commented in that on budgie ^^ think I also reported on the tracker against budgie (and mate for the record)
<fossfreedom> cheers - much appreciated
<slangasek> jbicha: btw, gksu is also seeded in ubuntukylin daily-live despite not having any revdeps there; please follow through on the seed cleanup w/ ubuntukylin team
<slangasek> jbicha: hmm or perhaps that's transitive and goes away now that peony-gksu is dropped; n/m
-queuebot:#ubuntu-release- Unapproved: leptonlib (bionic-proposed/universe) [1.75.3-2 => 1.75.3-3] (kubuntu) (sync)
<jbicha> filed bug 1765178
<ubot5`> bug 1765178 in macchanger-gtk (Ubuntu) "Please remove libui-dialog-perl; open security vulnerability" [Undecided,New] https://launchpad.net/bugs/1765178
<teward> is there a listing of the 'queue' of autopkgtests that are queued to run but haven't been run yet?
<jbicha> teward: https://autopkgtest.ubuntu.com/running
<teward> ah, the one page that takes eternity to load for me... which explains why I didn't see this earlier :P
<jbicha> it loads much faster when the queue is empty :|
<teward> i believe it.  (I'm keeping an eye on all the autopkgtests that nginx 1.14.0-0ubuntu1 triggered for any signs of the weird issue I found that xnox opened a bug about... or failures in general, but I don't think any of the triggers that nginx 1.14.0 set off have been reached yet...)
<slangasek> teward: nginx tests are queued behind glibc, because both glibc and nginx hit the threshold where their tests go in the 'large' queue and nginx was uploaded after glibc.  So you can expect to wait a while
<teward> indeed.
<teward> i'd expect that, but it's just still on my radar nonetheless :)
<tsimonq2> slangasek: Is there a way I can find out what other packages I have in proposed?
<tsimonq2> (Hm, I wonder if I could hack something up with UDD and launchpadlib?)
<slangasek> Â¯\(ã·)/Â¯
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> OK :)
<nacc> tsimonq2: packages you've uploaded to proposed, you mean?
 * tsimonq2 adds to post-release TODO list...
<tsimonq2> nacc: Yeah.
<tsimonq2> Sometimes I lose track.
<tsimonq2> (Look at how many packages I upload...)
<teward> *hands tsimonq2 a link* does https://launchpad.net/~tsimonq2/+related-packages help?
<teward> or rather, https://launchpad.net/~tsimonq2/+uploaded-packages
<nacc> the problem is the 'uploaded to' there isn't where it currently is
-queuebot:#ubuntu-release- Unapproved: tesseract (bionic-proposed/universe) [4.00~git2219-40f43111-1.2 => 4.00~git2288-10f4998a-2] (kubuntu) (sync)
<nacc> it's a release name
<nacc> but i do think that's roughly what you want
<teward> i think that's going to be an issue regardless, though, isn't it?
<nacc> tsimonq2: it would be nice to have a slightly more developer-focused view of that, and for +synchronized_packages
<nacc> *synchronised
<tsimonq2> I can probably query those via launchpadlib and cross-reference each upload with publishing history...
<nacc> tsimonq2: i think for each of those, you just need to go into the publishing state
<nacc> yeah :)
<ginggs> please accept tesseract, needed to fix autopkgtests on ocrmypdf, and leptonlib is a related package with only a CVE fix
<nacc> teward: right, i think that's just what laucnhpad web is surfacing, there is more data in the object in lplib (if i had to guess)
<tsimonq2> nacc: So, for me that'd be fine. I've only uploaded 289 times. But if I look at e.g. vorlon's page, that gets unmanageable...
<nacc> tsimonq2: right, i think you're right on a tool (ubuntu-dev-tools), i was just suggesting starting with bascially the query that produces that page
<tsimonq2> I could probably add launchpadlib integration to that fancy p-m script (that's hiding right now!) so I can just query that...
<tsimonq2> nacc: Thanks. :)
-queuebot:#ubuntu-release- Unapproved: gnocchi (bionic-proposed/universe) [4.2.0-0ubuntu4 => 4.2.0-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (bionic-proposed) [4.2.0-0ubuntu5]
<cjwatson> IMO the best place to surface that information would be in update_excuses
<tsimonq2> cjwatson: That has no uploader info.
<tsimonq2> But yeah, that's my plan.
<tsimonq2> (Parse that then find out who uploaded each.)
<cjwatson> tsimonq2: You misunderstand; I'm suggesting that that would be the best place to *add* this information
<tsimonq2> Ahh.
<slangasek> p-m already does have some concept of this, in order to generate the nag mails
<tsimonq2> If someone wants to report a bug and assign it to me, that'd be cool.
<tsimonq2> Otherwise I can do so myself, but post-release.
<jdstrand> can someone help me look at why all the apparmor autopkgtests are failing? eg: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/a/apparmor/20180418_173050_fb390@/log.gz
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-guide (bionic-proposed/universe) [18.04.3-0ubuntu1 => 18.04.4-0ubuntu1] (ubuntu-mate)
<jdstrand> it has to do with package dependencies not being installable. It isn't clear to me how the failures relate at all to my upload
<jdstrand> Depends: apparmor perl (not considered)
<jdstrand> hmm
<jdstrand> perl was in the mix with that log url
 * jdstrand notes all the other autopkgtests that consume apparmor pass, it is just the 'apparmor' autopkgtests fail on every arch
<tsimonq2> Perl has not migrated yet.
<tsimonq2> It could be that.
<jdstrand> maybe... I guess when perl migrates I could retry the tests
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (bionic-proposed/universe) [15.04.1+18.04.20180216-0ubuntu1 => 15.04.1+18.04.20180413-0ubuntu1] (mythbuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu3 => 3.28.0-2ubuntu4] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: mugshot (bionic-proposed/universe) [0.4.0-0ubuntu1 => 0.4.0-1] (ubuntustudio, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.24-1 => 0.09.25-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (bionic-proposed) [0.09.25-1]
-queuebot:#ubuntu-release- Unapproved: prewikka (bionic-proposed/universe) [4.1.5-1 => 4.1.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted prewikka [sync] (bionic-proposed) [4.1.5-2]
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu3 => 3.28.0-2ubuntu5] (ubuntugnome)
<slangasek> eta 40h for the amd64 autopkgtest queue to clear, hmph
#ubuntu-release 2018-04-19
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.6 => 18.04.7] (core)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-9-g49b562c9-0ubuntu1 => 18.2-14-g6d48d265-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ecj (bionic-proposed/universe) [3.13.2-1 => 3.13.3-1] (kubuntu) (sync)
<mdeslaur> can we please force pass xorg-server? I need it to go through so I can make sure we're getting proper permissions from the install media, and we're starting to cut it close
<mdeslaur> though, it may be close to migrating by itself, looks like only one test needs to finish
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu3 => 3.28.0-2ubuntu6] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: carrotsearch-hppc (bionic-proposed/universe) [0.6.1-4 => 0.6.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted carrotsearch-hppc [sync] (bionic-proposed) [0.6.1-5]
-queuebot:#ubuntu-release- Unapproved: csvjdbc (bionic-proposed/universe) [1.0.34-1 => 1.0.34-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted csvjdbc [sync] (bionic-proposed) [1.0.34-2]
-queuebot:#ubuntu-release- Unapproved: easymock (bionic-proposed/universe) [3.5.1+ds-1 => 3.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted easymock [sync] (bionic-proposed) [3.6-1]
-queuebot:#ubuntu-release- Unapproved: jboss-modules (bionic-proposed/universe) [1.7.0-1 => 1.8.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jboss-modules [sync] (bionic-proposed) [1.8.1-1]
-queuebot:#ubuntu-release- Unapproved: jug (bionic-proposed/universe) [2.0.0-2 => 3.1.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jug [sync] (bionic-proposed) [3.1.5-1]
-queuebot:#ubuntu-release- Unapproved: libcommons-validator-java (bionic-proposed/universe) [1:1.6-1 => 1:1.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-validator-java [sync] (bionic-proposed) [1:1.6-2]
-queuebot:#ubuntu-release- Unapproved: libhamcrest-java (bionic-proposed/universe) [1.3-6 => 1.3-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libhamcrest-java [sync] (bionic-proposed) [1.3-7]
-queuebot:#ubuntu-release- Unapproved: libhibernate3-java (bionic-proposed/universe) [3.6.10.Final-8 => 3.6.10.Final-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libhibernate3-java [sync] (bionic-proposed) [3.6.10.Final-9]
-queuebot:#ubuntu-release- Unapproved: libjgoodies-binding-java (bionic-proposed/universe) [2.13.0-1 => 2.13.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjgoodies-binding-java [sync] (bionic-proposed) [2.13.0-2]
-queuebot:#ubuntu-release- Unapproved: libpdfbox2-java (bionic-proposed/universe) [2.0.8-2 => 2.0.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libpdfbox2-java [sync] (bionic-proposed) [2.0.9-1]
-queuebot:#ubuntu-release- Unapproved: libproxool-java (bionic-proposed/universe) [0.9.1-9 => 0.9.1-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libproxool-java [sync] (bionic-proposed) [0.9.1-10]
-queuebot:#ubuntu-release- Unapproved: livetribe-jsr223 (bionic-proposed/universe) [2.0.6-1 => 2.0.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted livetribe-jsr223 [sync] (bionic-proposed) [2.0.6-2]
-queuebot:#ubuntu-release- Unapproved: sqlline (bionic-proposed/universe) [1.0.2-5 => 1.0.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sqlline [sync] (bionic-proposed) [1.0.2-6]
-queuebot:#ubuntu-release- Unapproved: trove (bionic-proposed/universe) [2.1.0-2 => 2.1.0-3] (openstack) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.29-1 => 8.5.30-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ecj [sync] (bionic-proposed) [3.13.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.30-1]
-queuebot:#ubuntu-release- Unapproved: accepted trove [sync] (bionic-proposed) [2.1.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.7]
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu3 => 3.28.1-0ubuntu4] (ubuntu-desktop)
<tsimonq2> slangasek: ffmpeg> Didn't get a chance to look tonight, but I'll do it tomorrow.
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [0.9.24-dfsg-2 => 0.9.24.1-dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (bionic-proposed) [0.9.24.1-dfsg-1]
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6~rc1 => 1.6] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.0~rc3 => 1.6.0] (core) (sync)
<juliank> sil2100: ^ final release bumps (+ making zstd optional in upstream build scripts for apt)
<juliank> um, cannot ftp to upload.ubuntu.com
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (bionic-proposed/main) [1.7-0ubuntu2 => 1.7-0ubuntu3] (no packageset)
<juliank> ^ it's working again :)
<juliank> wait, I forgot to close the bug report attached to the card.
<sil2100> juliank: I'll take care of it in a moment, just want to upload something myself
<juliank> sil2100: awesome :)
<juliank> I wonder if I should re-upload networkd-dispatcher or close the bug manually. Latter seems easier
<sil2100> There's no requirement for changelogs to devel to track bug numbers - even though it is a good practice
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32 => 0.96.24.32.1] (desktop-core, ubuntu-server)
<seb128> ^ that's an easy one line to add a missing build-depends from the previous upload from yesterday that ftbfses
<sil2100> Ok, looking at the queue now
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu1 => 1.178ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu15]
<seb128> cyphermox, next time there is a console-setup change that create issues for ubiquity and require it to catch up it would be good to track/document that with a milestoned bugs
<seb128> it would avoid having to "rediscover" the issue
-queuebot:#ubuntu-release- Unapproved: accepted indicator-china-weather [source] (bionic-proposed) [2.2.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menus [source] (bionic-proposed) [1.1.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.1]
<sil2100> I tested that locally, but I guess we'll have to keep an eye out if my re-removal of the xkb-keymap bits didn't break something that started depending on it
<sil2100> But seeing we did not have that before artful and it didn't seem to be followed up, I doubt it
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [18.1-5-g572ae5d6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (bionic-proposed) [1.6]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [sync] (bionic-proposed) [1.6.0]
<seb128> https://codesearch.debian.net/search?q=keyboard-configuration%2Fxkb-keymap&perpkg=1 gives an idea about where it's used in Debian
<seb128> not really likely to create issues, they just seem to be components that try to preseed the value but they do it also for the other keyboard variables
<seb128> would be to nice to get the gnome-initial-setup updates accepted as well
<seb128> they are basically still doing UI changes etc
<seb128> but that feature is late and improvements needed, which we know suck, but it is a requirement that has been imposed on us so not much way around
<seb128> the current version in the queue is getting closer from being acceptable for release though
<seb128> so it should stop changing UI after that
<sil2100> Yeah, I'll  get to it in a bit
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.10-dfsg-2]
<seb128> thx
<jibel> sil2100, how did you test? did you rebuild an iso?
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (bionic-proposed) [1.19.0.5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted leptonlib [sync] (bionic-proposed) [1.75.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (bionic-proposed) [18.04.4-0ubuntu1]
<sil2100> jibel: yes, modified the squashfs and recreated the iso
<jibel> okay, i'll try it too
<didrocks> sil2100: the fastest way I found as well to test a fix
<sil2100> seb128: re: gnome-initial-setup - the documentation team is aware of the ongoing changes for that one?
<sil2100> (do we have some UIFe-like thing for it?)
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2]
<seb128> sil2100, yes
<sil2100> oh my, 3 versions of it, I'll reject the 2 first and pick up the last one
-queuebot:#ubuntu-release- Unapproved: accepted mugshot [sync] (bionic-proposed) [0.4.0-1]
<seb128> sil2100, that was part of the ffe you acked
<seb128> thx
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.0.9 => 1.0.10] (no packageset)
<didrocks> ^ a one line change to get autopkgtests passing now that we use vendor deps. Tested locally on my autopkgtest vm
<seb128> documentation is not an issue since the feature is not in our desktop guide
<sil2100> ETOOMANYFFES
<sil2100> seb128: thanks
<seb128> thank you for the reviews!
-queuebot:#ubuntu-release- Unapproved: rejected gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.10]
<didrocks> thx!
<ginggs> thanks for accepting leptonlib!  please accept tesseract, needed to fix autopkgtests on ocrmypdf
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.2-14-g6d48d265-0ubuntu1]
<sil2100> ginggs: yw! I was looking at that, need to re-check it - since the sync seems to be of a new upstream snapshot, I need to check if there are no FF-breaking changes there
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.0ubuntu2 => 1.1ubuntu1] (desktop-core, ubuntu-server)
<ginggs> sil2100: ok, thanks - debian's changelog is quite verbose :)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.48-0ubuntu2 => 390.48-0ubuntu3] (ubuntu-desktop)
<tseliot> can an admin reject  nvidia-graphics-drivers-390 (390.48-0ubuntu3), please? I would like to add one more fix
<tseliot> tjaalton: ^
<apw> tseliot, done
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.48-0ubuntu3]
<tseliot> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.2.0-3ubuntu2 => 2:10.2.0-3ubuntu3] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: chrony (bionic-proposed/main) [3.2-4ubuntu3 => 3.2-4ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.7 => 18.04.8] (core)
<cjwatson> slangasek,infinity: So, can either of you still reproduce this "Lubuntu ubiquity runs plugininstall.py as non-root" thing?  I just spent some time trying to get it to happen with today's image (after applying the fix from 18.04.7 in-place using break=casper-bottom) and can't; plugininstall.py runs as root and it all works fine.  But maybe I'm doing something slightly different?
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.30-1 => 8.5.30-1ubuntu1] (kubuntu)
<tseliot> apw: it was a false alarm. I have re-uploaded nvidia
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.48-0ubuntu2 => 390.48-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.8]
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.8-2 => 5.2.10-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (bionic-proposed) [5.2.10-2]
<acheronuk> cjwatson: today's lubuntu iso seems to crash ubuitity-dm if install is selected in the boot menu and go straight to the live session
<cjwatson> acheronuk: see where I wrote "after applying the fix from 18.04.7 in-place"
<cjwatson> that's the fix for that bug
<acheronuk> ah. will have to wait for another iso to test that
<cjwatson> yep, that's why for now I just asked people I was sure were comfortable hacking stuff in-place using break=casper-bottom :)
<acheronuk> fair enough
<cjwatson> (and also who I knew for certain had reproduced this bug in the past)
<LocutusOfBorg> is it possible to process hedgewars removal on ppc64el?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1765392
<ubot5`> Ubuntu bug 1765392 in hedgewars (Ubuntu) "please remove hedgewars on ppc64el" [Undecided,New]
<acheronuk> cjwatson: well I got it when testing for previous milestone. but I'm leaving well alone now
<cjwatson> I believe you, but I don't know whether it's gone away on its own or whether I'm doing something different that doesn't provoke it
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.0.10 => 1.0.11] (no packageset)
 * acheronuk shrugs
<mdeslaur> why is xorg-server still set to "Not considered"?
<mdeslaur> I don't see any failures
<acheronuk> mdeslaur: kdevelop/4:5.2.1-1ubuntu4: amd64: Test in progress,
<acheronuk> passed @ 13:16:54 UTC so should be ok on next run?
<mdeslaur> acheronuk: ugh, I'm blind apparently
<mdeslaur> acheronuk: thanks :)
 * mdeslaur crosses fingers
<acheronuk> Apparently successful
<acheronuk> final: apt,console-setup,neutron,tomcat8,ubuntu-report,virtualbox,xorg-server
<acheronuk> :)
<mdeslaur> \o/
<jdstrand> the apparmor autopkgtest, afaics, are not passing due to perl deps not migrating (please correct me if I'm wrong). is there an update on perl's migration?
 * mdeslaur hides
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu6 => 2.3-3ubuntu7] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.33.1 => 1.34] (core)
<acheronuk> darkxst: is libzip 1.5 happening?
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.32.5+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.32.5]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.32.5~14.04]
<jbicha> acheronuk: ffe wasn't approved (yet)
 * sil2100 just promoted pv to main
<sil2100> Ok, spinning new base language-packs
<Laney> jdstrand: I think that's an autopkgtest bug :((((((((((((( https://salsa.debian.org/ci-team/autopkgtest/merge_requests/2
<ubot5-ng> CI bug (Merge request) 2 in autopkgtest "Remove the right autopkgtest-default-release file" (comments: 0) [Opened]
-queuebot:#ubuntu-release- Unapproved: xorg (bionic-proposed/main) [1:7.7+19ubuntu6 => 1:7.7+19ubuntu7] (core, xorg)
<jdstrand> Laney: ah. ok. tbh, I couldn't make heads or tails of the log. the failure seemed completely unrelated to my upload (which was only a handul of profile changes)
<Laney> you got a dependency on the latest perl
<jdstrand> Laney: thank you for taking a look. what do I need to do to resolve this?
-queuebot:#ubuntu-release- Unapproved: gnome-session (bionic-proposed/main) [3.28.1-0ubuntu1 => 3.28.1-0ubuntu2] (ubuntu-desktop)
<Laney> but that wasn't available when pinning just apparmor
 * jdstrand nods wrt latest perl
<Laney> we tried to fall back to using all of proposed
<Laney> but that didn't work
<Laney> two seconds and you can retry
<jdstrand> Laney: not, I retried amd64 an hour ago or so
<jdstrand> note*
<jdstrand> just for giggles
<Laney> well yes, but that was before I fixed it
<Laney> try now
<tjaalton> bah, reject that xorg upload
<tjaalton> I'll fix that first
<jdstrand> sure-- I was just saying it may still be running, etc, but I can keep an eye on that
 * jdstrand tries i386
<jdstrand> it looks like amd64 from an hour ago finished. if i386 passes, I'll do all the others
<jdstrand> Laney: thanks!
<jdstrand> (to be clear, amd64 from an hour ago finished and failed; I'll retry it after i386)
-queuebot:#ubuntu-release- Unapproved: xorg (bionic-proposed/main) [1:7.7+19ubuntu6 => 1:7.7+19ubuntu7] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (artful-proposed/main) [0.30-0ubuntu2 => 0.30-0ubuntu2.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (xenial-proposed/main) [0.27-0ubuntu25 => 0.27-0ubuntu25.1] (edubuntu, ubuntu-server)
<Laney> jdstrand: â it worked
<jdstrand> woo!
<jdstrand> Laney: thanks again :)
<Laney> np!
<mwilson-e> Hello, I was wondering if it would be possible to have ubuntu-report 1.0.11 pushed into the release? The package is currently waiting on unapproved.
<Laney> Everything in unapproved will be reviewed
<mwilson-e> Laney: Excellent, cheers.
<Laney> de nada
<doko> Laney: any idea about the pyfai uninstallability in the autopkg tests?
<Laney> doko: no, but see the previous conversation and maybe retry
<teward> I assume that someone's looking at the Perl Regressions in the autopkgtests?
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10~46-5ubuntu1 => 10.0.1+10-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (bionic-proposed) [10.0.1+10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (bionic-proposed) [8.5.30-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lightdm-settings [source] (bionic-proposed) [1.1.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: lightdm-settings [amd64] (bionic-proposed/none) [1.1.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: orca (bionic-proposed/main) [3.27.91-1ubuntu2 => 3.28.0-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.522 => 2.523] (desktop-core)
<slangasek> cjwatson: I hadn't tested with a more recent image, hmm
<cjwatson> I don't see anything that might plausibly have fixed it either, but given that we don't understand the root cause ...
-queuebot:#ubuntu-release- New: accepted lightdm-settings [amd64] (bionic-proposed) [1.1.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu4 => 25ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (bionic-proposed) [25ubuntu5]
<sil2100> infinity: new base langpacks prepared, uploaded, approved and building
<sil2100> Hopefully they're good, I only sanity-tested 2
<tjaalton> the queue has two uploads of 'xorg', drop the older one
<sil2100> k
<tjaalton> thx
-queuebot:#ubuntu-release- Unapproved: rejected xorg [source] (bionic-proposed) [1:7.7+19ubuntu7]
-queuebot:#ubuntu-release- Unapproved: udisks2 (bionic-proposed/main) [2.7.6-2ubuntu6 => 2.7.6-3] (desktop-core, ubuntu-server) (sync)
<sil2100> bdmurray: hey! I'll be releasing systemd for trusty now (just so you won't waste your time later by accident trying to re-publish it)
<bdmurray> sil2100: okay
<jbicha> slangasek: could you update your gvfs britney hint?
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (trusty-proposed) [3.1.9ubuntu2.1]
<sil2100> Ok, /me is done for today
-queuebot:#ubuntu-release- Unapproved: accepted ifupdown [source] (xenial-proposed) [0.8.10ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.11]
<slangasek> jbicha: done
<slangasek> cjwatson: confirmed, lubuntu install failure unreproducible; job done!
<teward> correct me if i'm wrong but in the autopkgtests update excuses file, "Depends: [packagename] perl (not considered)" means that the Perl autopkgtests need to pass and perl needs to be released from proposed as well, right?  (Just trying to chase down something..)
<slangasek> sigh
<slangasek> what the hell is wrong with perl deps
<slangasek> and is anyone working on getting it unblocked? mdeslaur ?
<slangasek> teward: yes your analysis is correct
<mdeslaur> slangasek: sorry, I'm not working on it, no
<slangasek> mdeslaur: could you? :) it's your package sync
-queuebot:#ubuntu-release- New sync: cpprest (bionic-proposed/primary) [2.10.2-3]
<slangasek> and dh_perl's shitty autogenerated deps are blocking other packages
<LocutusOfBorg> slangasek, I renamed src:casablanca to src:cpprest to match the binary package
<LocutusOfBorg> content is mostly the same, same upstream, I also install now the cmake bindings
<LocutusOfBorg> can you please consider processing it?
<LocutusOfBorg> (also, decruft or whatever you call src:casablanca :) )
<LocutusOfBorg> I opened the same decruft bug in Debian this morning
<LocutusOfBorg> btw I'm partially working wrt perl migration
<mdeslaur> slangasek: I'll take a look (remind me never to touch perl again)
-queuebot:#ubuntu-release- Unapproved: i2p (bionic-proposed/universe) [0.9.33-2 => 0.9.34-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted i2p [sync] (bionic-proposed) [0.9.34-1]
<ginggs> ocrmypdf is blocked from migrating from -proposed because of a test failure on s390x, but it is not even in -release, so how is this a regression?
<ginggs> btw, this is fixed by the tesseract sync which is not yet approved
-queuebot:#ubuntu-release- Unapproved: stunnel4 (bionic-proposed/universe) [3:5.44-1ubuntu2 => 3:5.44-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stunnel4 [source] (bionic-proposed) [3:5.44-1ubuntu3]
<mdeslaur> LocutusOfBorg: I took care of stunnel4, is there anything else in the perl migration you would like me to take a closer look at?
<cjwatson> slangasek: how very odd, but I won't complain.  I guess we should be prepared for somebody reporting it again during testing though
 * slangasek nods
-queuebot:#ubuntu-release- Unapproved: i2p (bionic-proposed/universe) [0.9.34-1 => 0.9.34-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted i2p [source] (bionic-proposed) [0.9.34-1ubuntu1]
<LocutusOfBorg> mdeslaur, I don't know, I think they all need care, but some of them are regressed in release so we might even ask to blacklist?
<LocutusOfBorg> I'll take a closer look tomorrow maybe
<sergiusens> bdmurray: hi there, mind letting snapcraft 2.41/2.41+17.10 into -updates ?
<sergiusens> there's an ubuntu-image error on s390x on artful which looks related to snapd and not snapcraft itself
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34]
<bdmurray> sergiusens: its only been in -proposed for a day. Is there a reason to waive the 7 day wait period?
<slangasek> bdmurray: the "if it survives its own autopkgtests, it must be good" reason
<sergiusens> bdmurray: we have an exception https://wiki.ubuntu.com/SnapcraftUpdates
<bdmurray> slangasek: Is that a new reason?
<slangasek> bdmurray: it's pretty much meant to be a standing reason in the case of snapcraft, from my perspective.  I don't recall if it was captured on the above wiki
<bdmurray> slangasek: oops, it is and I lasted updated that page
<slangasek> :)
<bdmurray> sergiusens: Could you elaborate on the ubuntu-image error being related to snapd?
<sergiusens> bdmurray: it seems to be an error coming from `snap prepare`, could be  store hiccup as well https://paste.ubuntu.com/p/Y6fdvK32Zk/
<sergiusens> but it is not from snapcraft :-)
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu7]
<sergiusens> bdmurray: can you followup with kyrofa, I need to go offline for a bit
<bdmurray> sergiusens: I released it
<sergiusens> oh, ty
<slangasek> nfct v1.4.4: netlink error: Device or resource busy
<slangasek> >_<
<tsimonq2> Final Freeze is in two hours, aye?
<tsimonq2> Hum, the contents of https://wiki.ubuntu.com/FinalFreeze don't seem to be current.
<slangasek> log4cxx autopkgtest failure impressive, declares a test that depends on a binary package that's NBS from its own source
<slangasek> so passed in -proposed, migrated to devel, NBS cleanup done, test fails. :P
-queuebot:#ubuntu-release- Unapproved: log4cxx (bionic-proposed/universe) [0.10.0-13ubuntu1 => 0.10.0-13ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted log4cxx [source] (bionic-proposed) [0.10.0-13ubuntu2]
<slangasek> cyphermox: netplan.io/0.35/amd64 test failure on glibc
<slangasek> doko: do you know why mercurial autopkgtests are now running 3h instead of 1h and hitting timeouts?
<slangasek> cyphermox: I thought you were dropping this test_mix_bridge_on_bond test a long time ago due to it being racy
<tsimonq2> slangasek: Might witty be a candidate for removal from devel-proposed? It's FTBFS in Ubuntu (with an associated RC bug in Debian) and piuparts in Debian also failed.
 * tsimonq2 contacts the Debian MIA Team about the maintainer.
<slangasek> tsimonq2: yes; question is why doko didn't remove it from -proposed as well when he removed it from release.  But the RC bug in Debian does not look "associated".
<tsimonq2> slangasek: Ah, OK.
<slangasek> anyway, removing now
<slangasek> tsimonq2: fwiw the build failure in Ubuntu is specific to the boost transition that has yet to start in Debian
<cyphermox> slangasek: I want to, but late in cycle didn't seem the right moment to do extra changes like this
<tsimonq2> slangasek: Thanks.
<slangasek> cyphermox: when we talked about it it was not late in cycle
<cyphermox> it's definitely a duplicate test, but having the intersection of (enough time to look and re-test) + (right moment) didn't work
<cyphermox> I know
<slangasek> cyphermox: and there is no wrong time to drop a broken test
<tsimonq2> slangasek: xwallpaper seems like a candidate for extra-removals.txt; it's depwait on nonexisting (in Ubuntu) boost packages.
<cyphermox> I don't want to drop it and find out the other mix_bridge_on_bond_vlan gets flaky then
<slangasek> cyphermox: ok.
<cyphermox> because I suspect it's not flaky, just bad environment setup/cleanup
<cyphermox> and it takes time to investigate, never quite reaching the top of my list
<slangasek> tsimonq2: no, it's dep-wait on doko cleaning up jpeg in Ubuntu to not be inconsistent with Debian; so not fit for extra-removals
<tsimonq2> slangasek: ack
<cyphermox> slangasek: I'll stage the change now in git so it's ready for the very next upload
<slangasek> doko: speaking of which, it seems you've not committed anything to extra-removals.txt, nor given me the list you said you would
<tsimonq2> node-d3-format might migrate now; it was FTBFS due to a failed upload(?)
<tsimonq2> node-d3-format> Er, wat?
<tsimonq2> slangasek: That could need some sort of AA cleanup ^
<tsimonq2> It's never been in the release pocket it seems, and I can't find the epoch in the publishing history.
<slangasek> glibc autopkgtest regressions resolved or badtested or in progress
<slangasek> tsimonq2: did you check if a binary of this name exists from another source?
<tsimonq2> node-d3-hierarchy and node-d3-request are depwait on node-d3-dsv which is depwait on node-csv-spectrum and that seems to be in neither Debian or Ubuntu, curious; perhaps *these* are candidates for removal? :)
<tsimonq2> slangasek: Double checking.
<slangasek> (d3-format)
<tsimonq2> (yep)
<slangasek> the newer node-d3-format package is fail-to-upload in Debian also
<jbicha> Debian bug 894532 is a mess
<ubot5`> Debian bug 894532 in src:node-d3-format "node-d3-format: Duplicates exisitng node-d3-format binary package" [Serious,Open] http://bugs.debian.org/894532
<tsimonq2> Ah. Nice one jbicha
<tsimonq2> slangasek: So, do we just leave node-d3-format? :)
<slangasek> tsimonq2: it will never migrate without a sourceful fix.  I'll nuke it from -proposed
<tsimonq2> ack
<tsimonq2> slangasek: What about the node-csv-spectrum issue?
<slangasek> tsimonq2: did you check if it's in the NEW queue?
<slangasek> tsimonq2: (debian new)
<tsimonq2> Good point. sec
<tsimonq2> Indeed it is...
<teward> slangasek: sorry for slow response.  Glad that my analysis is right, hopefully someone can fix the Perl stuff soon, because that's probably going to hold up a bunch of things.  And a lot of things in it show as regressions now.
<teward> s/a lot/a bunch/
<slangasek> coreycb: Debian now has python3-neutron but Ubuntu does not, which blocks updating of networking-arista.  I don't suppose that's trivially fixable for release?
<tsimonq2> slangasek: So then the correct course of action is to poke Debian to get that through then sync? Or would you prefer a different solution?
<slangasek> coreycb: (also, networking-arista in bionic currently fails to build)
<slangasek> tsimonq2: poking Debian about node packages in NEW is not worthwhile; and I don't care about any of the node stuff currently stuck in -proposed.  I think we should be focused on the things in -proposed that are actually useful to get unstuck and migrated before we need to start building candidate images
<slangasek> tsimonq2: which means only those things in -proposed that are 16 days old or newer
<tsimonq2> ack
<slangasek> (like, in principle it would be nice to zero out the backlog in -proposed, but now is not the time)
<tsimonq2> Got it.
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (bionic-proposed/universe) [1.222 => 1.223] (ubuntu-mate)
-queuebot:#ubuntu-release- New source: candid (bionic-proposed/primary) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
<slangasek> seb128: do you plan to follow through on the indicator-sound ftbfs?  Was previously on the list of test rebuild failures
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.522 => 2.524] (desktop-core)
<slangasek> doko: your puppet 5.4.0-2ubuntuX fails autopkgtests
<nacc> slangasek: i think i'm supposed to be investigating it -- i think we should revert it back to the ubuntu1 level
<nacc> slangasek: the ubuntu dep8 env is different from debian's
<slangasek> nacc: the autopkgtests failed with ubuntu1 also
<nacc> slangasek: ok, i'll need to look
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (bionic-proposed/universe) [0.31 => 0.32] (personal-fossfreedom, ubuntu-budgie)
<slangasek> jbicha: I guess you have no particular interest in pgbackrest, right, you were just syncing new version to see if it might fix the already brokenness in -proposed?
<slangasek> jbicha: (might be worth a bug report to Debian as they probably don't know the package is broken on armhf?)
-queuebot:#ubuntu-release- New: rejected candid [source] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
<ginggs> slangasek: in case i'm asleep before you get to it, ocrmypdf fails autopkgtest only on s390x, but it is not in -release, so is not a regression? but fixed by tesseract sync, not yet accepted (s390x autopkgtest passed in my PPA)
<slangasek> ginggs: oh, there's a fixed tesseract? looking, thanks
-queuebot:#ubuntu-release- Unapproved: accepted tesseract [sync] (bionic-proposed) [4.00~git2288-10f4998a-2]
<ginggs> slangasek: ta!
<slangasek> doko: you dropped Ubuntu delta when syncing rails, regressing xnox's sdoc fix; are you fixing up?
<seb128> slangasek, indicator-sound is on our list of things to look at yes
<slangasek> seb128: ok cheers
<slangasek> doko: what's the path forward on LP: #1762175? java-common and octave would both unblock at the same time anyway if octave-io and octave-symbolic/i386 autopkgtests were fixed
<ubot5`> Launchpad bug 1762175 in octave (Ubuntu) "keep java-common pointing to OpenJDK in -proposed" [Undecided,New] https://launchpad.net/bugs/1762175
-queuebot:#ubuntu-release- Unapproved: httping (bionic-proposed/universe) [2.5-1.1 => 2.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted httping [sync] (bionic-proposed) [2.5-2]
<Wimpress> Would someone be good enough to let ubuntu-mate-meta 1.223 through please.
<slangasek> Wimpress: are you sure you wouldn't rather have an ubuntu-mate-mate
<Wimpress> yes-mate
<slangasek> ubuntu-mutu-mutu
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (bionic-proposed) [1.223]
<Wimpress> That has a certain ring to it.
<Wimpress> slangasek: Thank you.
<Wimpress> slangasek: I'm sure fossfreedom would like ubuntu-budgie-meta 0.32 leeting in too.
<Wimpress> We're both seeding the same package.
<ginggs> slangasek: fwiw, octave-symbolic is flaky everywhere
<slangasek> ginggs: ah ok
<nacc> slangasek: ok, i remember this being relatively hard to diagnose earlier. It has to do with the network configuration of the dep8 runners ... hostnames, and such. For some reason, in Debian's env 'it just works', but in LP's it does not. And it's not trivial to reproduce the LP env at home (and if I just use autopkgtest with LXD, it passes locally, with or without our delta)
<nacc> slangasek: let me see i might have fixes actually (it looks like some of the tests maybe moved upstream)
<nacc> slangasek: lol ... fubar merge
<nacc> completely completely wrong
<nacc> slangasek: fixing it up now
<nacc> doko: tsk tsk :)
<darkxst> acheronuk, I dont know, Laney was going to look at it, but dont think he has and its now super late in the cycle
<acheronuk> thanks. not greatly fussed. was just curious
<darkxst> acheronuk, probably it will happen when CC opens
<nacc> slangasek: uploading a fix
<slangasek> nacc: cheers
-queuebot:#ubuntu-release- Unapproved: puppet (bionic-proposed/universe) [5.4.0-2ubuntu2 => 5.4.0-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (bionic-proposed) [0.32]
-queuebot:#ubuntu-release- Unapproved: accepted puppet [source] (bionic-proposed) [5.4.0-2ubuntu3]
<nacc> slangasek: afaict, some of that delta will always need to exist (there's a sysv-init specific test). I think I can send the rest of it to Debian. I'll try and do that tomorrow.
<Odd_Bloke> All the s390x builders seem to be stuck in Cleaning.
<slangasek> Odd_Bloke: flagged to LP
<Odd_Bloke> Danke.
<slangasek> what does it say that my fingers tried to autocomplete 'pyfai' to 'pyfail'?
<acheronuk> I was told on s390x "I/O error trying to launch instances, won't be trivial to resolve, may take until tomorrow"
<acheronuk> :/
<infinity> cjwatson: So, the one thing I did change was to seed python2 back onto their live image (by seeding samba-common, to work around it not being there due to no-follow-recommends), which had the side-effect of making pluininstall stop whining about pyversions not being there, but I swear I tested an image after that change and it still broke.
<infinity> cjwatson: I can't think of anything else that would have magically fixed things.
<infinity> cjwatson: (I can't see how that would have magically fixed things either, mind you)
<slangasek> jbicha: cacti 1.1.37+ds1-1 that you synced has failing autopkgtests in Debian and Ubuntu; there's a 1.1.38 in Debian that passes; should we sync it?
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34 => 1.34.1] (core)
<jbicha> yes the new cacti version should pass, syncing
-queuebot:#ubuntu-release- Unapproved: cacti (bionic-proposed/universe) [1.1.37+ds1-1 => 1.1.38+ds1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cacti [sync] (bionic-proposed) [1.1.38+ds1-1]
<xnox> slangasek, trumping your livecd-rootfs upload; my maas hook was tested by building the subiquity livefs in my ppa at https://launchpad.net/~xnox/+livefs/ubuntu/bionic/ubuntu-server-live/+build/129934 which is success, and did the right thing. Testing my subiquity changes on top of that now.
<wxl> did someone say drumpf?
 * LocutusOfBorg feels lintian syncy to make perl migrate, is trying in his ppa
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.1]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.523]
<jbicha> LocutusOfBorg: if you do it, it will need to be a merge because of Debian bug 895574
<ubot5`> Debian bug 895574 in src:lintian "lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf" [Normal,Open] http://bugs.debian.org/895574
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.524]
-queuebot:#ubuntu-release- Unapproved: morris (bionic-proposed/universe) [0.2-3build1 => 0.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: grhino (bionic-proposed/universe) [0.16.1-3 => 0.16.1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted grhino [sync] (bionic-proposed) [0.16.1-4]
-queuebot:#ubuntu-release- Unapproved: accepted morris [sync] (bionic-proposed) [0.2-4]
<cjwatson> infinity: Indeed - I have a fix for that bug locally, but I don't think it can possibly be related to this, so I'd rather commit it for post-bionic
<LocutusOfBorg> jbicha, do you feel lintian mergy? :)
<LocutusOfBorg> I won't be awake to click this link https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=lintian&ppa=costamagnagianfranco/locutusofborg-ppa&trigger=lintian/2.5.83ubuntu1
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
<jbicha> LocutusOfBorg: no :)
<slangasek> LocutusOfBorg, jbicha: regardless, lintian is clearly regressed in release; badtest hint added
<infinity> Looking at the nature of the failures, I was blaming LP: #1764701 for the lintian regression until someone proves otherwise.
<ubot5`> Launchpad bug 1764701 in gcc-7 (Ubuntu) "produces broken binary: Inconsistency detected by ld.so [regression gcc-7 7.3.0-15ubuntu2 => 7.3.0-16ubuntu2]" [High,New] https://launchpad.net/bugs/1764701
<infinity> Also, I think it's about time update_excuses.html grew some simple CSS to block tag all-green (or, I guess, all-green-or-yellow) pass lines with a toggle to not display them.
<infinity> Scrolling through all the green to find the few red hurts.
<jbicha> could you kick the s390x builders?
<slangasek> we can kick them but that will only hurt our toes
<jbicha> don't kick them with your sandals please
<cjwatson> Instance spawning isn't working, so the usual kind of kicking is futile
<infinity> If they're just stuck in failed reset hell, I can smack them, but... See above from Colin. :)
<cjwatson> qemu-img convert is complaining about I/O errors, which can't be good
<cjwatson> I made a few suggestions in the relevant sysadmin channel, possibly clueless ones
<infinity> Maybe we broke our mainframe and need to ask IBM for a new one.
<cjwatson> broken image is more likely, but not clear why
<slangasek> maybe Michael's is having a sale on frames
<cjwatson> anyway, I must sleep
<infinity> slangasek: Hrm.  I was going to correct you with "'frames", and now I'm not sure if the pun works better or worse using one form over the other.
<infinity> slangasek: These are the things that keep me awake at night.
<slangasek> so... zfs doesn't work on 32-bit, right?  therefore we should maybe not let a failing lxd/i386 autopkgtest block zfs
<infinity> slangasek: ZFS modules don't exist on 32-bit kernels, but 32-bit userspace is meant to work against 64-bit kernels.
<slangasek> and are you meant to use 32-bit lxd on 64-bit kernels with zfs?
<infinity> slangasek: Don't see why that wouldn't work, but the more relevant question is if this lxd failure even has anything to do with zfs.
 * infinity retries for kicks.
<infinity> BRB, quick run to the dry cleaner's before they close.
<slangasek> infinity: I already retried it too, let's race
<infinity> slangasek: The part where the failed test took 3 times longer than previous successful tests is a bit suspect.
<slangasek> nacc: that leaves ruby-rspec-puppet autopkgtests blocking
<slangasek> infinity: looks like both the lxd tests pasts; not sure which of us won
<slangasek> now if make would just stop breaking systemd
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Artful 17.10 | Archive: final freeze | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<infinity> slangasek: Do we know anything about this kylin-video that hit NEW last week?
<slangasek> infinity: I don't
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpprest [sync] (bionic-proposed) [2.10.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (bionic-proposed) [3.28.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg [source] (bionic-proposed) [1:7.7+19ubuntu7]
<infinity> Ugh, reviewing that nvidia upload looks "fun".
-queuebot:#ubuntu-release- Unapproved: accepted orca [source] (bionic-proposed) [3.28.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (bionic-proposed) [3.2-4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (bionic-proposed) [15.04.1+18.04.20180413-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.2.0-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted udisks2 [sync] (bionic-proposed) [2.7.6-3]
-queuebot:#ubuntu-release- Unapproved: gnome-video-arcade (bionic-proposed/universe) [0.8.8-2 => 0.8.8-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-video-arcade [source] (bionic-proposed) [0.8.8-2ubuntu1]
#ubuntu-release 2018-04-20
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.1+10-1ubuntu1 => 10.0.1+10-1ubuntu2] (ubuntu-desktop)
<doko> slangasek: re mercurial, no I don't know. it happens to pass after a few give backs
<doko> slangasek: re rails: I'll have a look
<doko> slangasek: re puppet: nacc's suggestion to force-sync. he wanted to have a look
<mwhudson> oh hi doko
<mwhudson> slangasek: wanna review that openjdk-lts upload?
<mwhudson> doko: https://paste.ubuntu.com/p/4hmWtqZB7J/
<slangasek> doko: ok.  I badtest'ed mercurial on amd64+arm64 for the flakiness due to timeouts, we still have good coverage on other archs
<slangasek> doko: so mercurial stuff is unblocked; puppet is sorted except for a failing revdep autopkgtest; and rails still needs attention
<doko> mwhudson: that change is fine, some was in openjdk-9
<mwhudson> doko: yeah i looked at a very small part of a 109 MiB diff first :)
<slangasek> tsimonq2: ffmpeg? :)
<tsimonq2> slangasek: I *just* got home. ;)  Yesterday I didn't get home until very very late...
<tsimonq2> slangasek: Expect something before I EOD
-queuebot:#ubuntu-release- Unapproved: hackrf (bionic-proposed/universe) [2017.02.1-1 => 2018.01.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libpam-chroot (bionic-proposed/universe) [0.9-4.2 => 0.9-4.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hackrf [sync] (bionic-proposed) [2018.01.1-2]
-queuebot:#ubuntu-release- Unapproved: airspy-host (bionic-proposed/universe) [1.0.9-1 => 1.0.9-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libpam-chroot [sync] (bionic-proposed) [0.9-4.3]
-queuebot:#ubuntu-release- Unapproved: accepted airspy-host [sync] (bionic-proposed) [1.0.9-3]
-queuebot:#ubuntu-release- New sync: musescore-general-soundfont (bionic-proposed/primary) [0.1.1-2]
<tsimonq2> infinity, slangasek: Was any progress made on that Lubuntu perms bug?
<tsimonq2> You know, now that we're getting ready tospin release candidates. :P
<slangasek> tsimonq2: yes; the progress we made was that cjwatson tested, and couldn't reproduce the original bug, and I tested, and confirmed his finding
<slangasek> so something changed, and it was good
<tsimonq2> So, all clear?
<slangasek> yes
<slangasek> tsimonq2: but if it shows up again in testing, yell
<tsimonq2> ack
 * tsimonq2 hopes for automated testing so I no longer have to throw an ISO at a machine 100 bajillion times anymore...
<doko> re: octave/openjdk need to look at that tomorrow. but it's working when those packages migrate in sync
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (bionic-proposed) [10.0.1+10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gegl (bionic-proposed/universe) [0.3.30-1 => 0.3.30-1ubuntu1] (edubuntu, ubuntugnome, ubuntustudio)
<slangasek> doko: but the autopkgtests are still failed and your comment on the bug suggested that the current failure was unrelated
<slangasek> ginggs: ocrmypdf autopkgtest still failed with tesseract/s390x from proposed
<slangasek> doko: oh hey, follow-up comment on LP: #1762175 looks promissing
<ubot5`> Launchpad bug 1762175 in octave (Ubuntu) "keep java-common pointing to OpenJDK in -proposed" [Undecided,New] https://launchpad.net/bugs/1762175
<slangasek> infinity: no touching nusakan www.prev for a bit
<tdaitx> mwhudson: as for the 109 MiB diff, iff you were looking for a debdiff between openjdk-9 versions, I highly recommend using --no-unpack-tarballs
<slangasek> tdaitx: I think he was trying to grab the launchpad-provided debdiff as a shortcut... and it wasn't very short :)
<mwhudson> yeah exactly
<mwhudson> i didn't know that option though
<tdaitx> yeah, been there, the launchpad provided diff is not that useful for openjdk when the source itself gets updated =/
<mwhudson> it was more an amusement than anything else :)
-queuebot:#ubuntu-release- Unapproved: gnustep-gui (bionic-proposed/universe) [0.26.2-2 => 0.26.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnustep-gui [sync] (bionic-proposed) [0.26.2-3]
-queuebot:#ubuntu-release- Unapproved: octave (bionic-proposed/universe) [4.2.2-1build1.1 => 4.2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted octave [source] (bionic-proposed) [4.2.2-1ubuntu1]
<tsimonq2> slangasek: ffmpeg> Just fixed rdeps. Should be good now, assuming those migrate.
-queuebot:#ubuntu-release- Unapproved: bombono-dvd (bionic-proposed/universe) [1.2.2-0ubuntu15 => 1.2.2-0ubuntu16] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mythexport (bionic-proposed/multiverse) [2.2.4-0ubuntu5 => 2.2.4-0ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mythexport [source] (bionic-proposed) [2.2.4-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted bombono-dvd [source] (bionic-proposed) [1.2.2-0ubuntu16]
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5 => 1.7.0-5ubuntu1] (core)
<tsimonq2> slangasek: That peruse upload I just syncpackage'd should have fixed everything, and now we're in sync with Debian. \o/
-queuebot:#ubuntu-release- Unapproved: peruse (bionic-proposed/universe) [1.2+dfsg-1 => 1.2+dfsg-2] (kubuntu) (sync)
<tsimonq2> slangasek: Er, you might need to approve that one. :)
<tsimonq2> I would argue that the package currently in the release pocket is broken enough that it shouldn't be shipped in the release.
<slangasek> tsimonq2: what specifically is broken?
<tsimonq2> slangasek: iirc: Not enough runtime deps, incomplete debian/copyright, appstream-metadata-in-legacy-location, the dependency on peruse-common is too loose.
<tsimonq2> But in that time, it passed through Debian NEW, got an RC bug, and I worked with lisandro and pino (in Debian) to do a good amount of polishing on the package.
<tsimonq2> s/Not enough/Missing/
<tsimonq2> (That's off the top of my head, granular details may be different.)
-queuebot:#ubuntu-release- Unapproved: tlslite-ng (bionic-proposed/universe) [0.7.0-3 => 0.7.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tlslite-ng [sync] (bionic-proposed) [0.7.4-1]
<slangasek> tsimonq2: from what I see there's no loose dep on peruse-common because there's no peruse-common binary package in the version currently in bionic ;)
<tsimonq2> slangasek: Oh, right. :)
<tsimonq2> slangasek: That's another thing, splitting of arch:all files into an arch:all binary.
<tsimonq2> slangasek: But, thanks. :)
-queuebot:#ubuntu-release- Unapproved: accepted peruse [sync] (bionic-proposed) [1.2+dfsg-2]
-queuebot:#ubuntu-release- New binary: peruse [amd64] (bionic-proposed/universe) [1.2+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu8 => 237-3ubuntu9] (core)
<xnox> infinity, ^ =)
-queuebot:#ubuntu-release- New: accepted peruse [amd64] (bionic-proposed) [1.2+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: pkgbinarymangler (bionic-proposed/main) [136 => 137] (kubuntu, ubuntu-desktop)
<slangasek> infinity: ^^ that's me trying to fix the failures to build the new linux-signed packages (spins forever waiting for a lock it will never get, because the lockfile claims foo-dbgsym is next).  I think it's generic and safe in the rare cases that it matters, but I'll leave it for your review
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.17.18 => 4.15.0.18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (bionic-proposed/main) [4.15.0-17.18 => 4.15.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-17.18 => 4.15.0-18.19+signed1] (core, kernel) (sync)
<slangasek> infinity: ^^ are you available to review the kernels or should I plan to review them a bit later this evening?
<slangasek> also it looks like this is a binary sync of linux-signed rather than source-only
<flocculant> slangasek: thanks for ubiquity fix
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (bionic-proposed) [4.15.0-18.19+signed1]
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-17.18 => 4.15.0-18.19+signed1] (core, kernel) (sync)
<ginggs> slangasek: ocrmypdf, weird, I'm pretty sure it passed when I tested against the version in my PPA - but failing an autopkgtest, when there is no ocrpdf in -release is not a regression, is it? would you force-badtest it on s390x?
<acheronuk> tsimonq2 slangasek: peruse is broken. https://i.imgur.com/ywzPhw6.png
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (artful-proposed/main) [2:10.1.10-3ubuntu0.1 => 2:10.2.0-3~ubuntu0.17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (xenial-proposed/main) [2:10.0.7-3227872-5ubuntu1~16.04.2 => 2:10.2.0-3~ubuntu0.16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> ginggs: it's a regression in the sense that we'd be letting in a package that we know to be broken
<acheronuk> slangasek: going to fix peruse that if ok? LP: #1765605
<ubot5`> Launchpad bug 1765605 in peruse (Ubuntu) "peruse fails to start - missing runtime dep on " [Undecided,New] https://launchpad.net/bugs/1765605
<slangasek> acheronuk: yes please
<acheronuk> hmmm. peruse 1.2 is a kirigami v1 based application, but debian removed kirigami 1 after stretch!
<acheronuk> so debian are going have a slight problem fixing there!
<acheronuk> we kept in case peruse could be got in
<acheronuk> *kept it
<infinity> slangasek: I'm around tonight and sort of on Andy's TZ.
<infinity> slangasek: Unless you're already on it.
<infinity> slangasek: Was planning to start "work" in an hour or so.
<slangasek> infinity: I haven't gotten there yet and am about to drop off
<slangasek> infinity: so I'm happy to leave it to you
<infinity> slangasek: Works for me.
<infinity> apw: Also, could we get a linux-signed that isn't a derp version number?  That version might have been burned in a PPA, but it wasn't burned in the archive.
-queuebot:#ubuntu-release- Unapproved: peruse (bionic-proposed/universe) [1.2+dfsg-2 => 1.2+dfsg-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cpprest (bionic-proposed/universe) [2.10.2-3 => 2.10.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cpprest [sync] (bionic-proposed) [2.10.2-5]
<apw> infinity, ack
<acheronuk> apw or other AA: please don't accept that peruse yet. may need another patch
<apw> acheronuk, shall i reject it, you can always upload it again
<acheronuk> fine by me
<infinity> apw: Going to go eat, then I'll be here all night to get those kernels rolling (and do some java boostrap thing, apparently), etc.
<apw> infinity, great, will go and sync my trees and find that signed source
-queuebot:#ubuntu-release- Unapproved: rejected peruse [source] (bionic-proposed) [1.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (bionic-proposed) [4.15.0-18.19+signed1]
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: peruse (bionic-proposed/universe) [1.2+dfsg-2 => 1.2+dfsg-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-17.18 => 4.15.0-18.19] (core, kernel)
<acheronuk> apw or other AA: ^^^ re-uploaded. I built and tested peruse with that patch I added. needed to fix access to store.kde.org 'newstuff'
<tjaalton> doko: hi, tomcat8.0 can now be removed, but sadly dogtag-pki still needs resteasy 3.0.x.. so I wonder if resteasy 3.1 should be made an ugly "really.3.0.19-1" or what?
<tjaalton> dogtag is the only thing that needs it. there's resteasy 3.5 which should be compatible with 3.0 plus stuff from 4.0~ but it turned out to be too much to package for me with little time
<mapreri> Could I ask you to approve the src:pencil2d sitting in the queue?  It's a very minor bugfix only releaseâ¦
<tseliot> apw: hey, are you going to have a look at my nvidia upload? A couple of metapackages will end up in NEW (as I renamed them)
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6 => 1.6.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted pkgbinarymangler [source] (bionic-proposed) [137]
-queuebot:#ubuntu-release- Unapproved: accepted gegl [source] (bionic-proposed) [0.3.30-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.1]
<infinity> tseliot: Do those :i386 deps actually work?
<infinity> I didn't think that was supported.
<infinity> Huh, so it does.
<infinity> Fancy.
<infinity> Also, holy crap, why is libnvidia-compute so huge?
<infinity> After this operation, 170 MB of additional disk space will be used.
<infinity> Unstripped binaries?
<tseliot> infinity: we are not allowed to strip the binaries
<infinity> I always used to strip them.
<infinity> Did they give us a slap?
<infinity> Can we ask them nicely to provide stripped ones? :P
<tseliot> good luck with that ;)
<infinity> Did they explicitly yell at us for stripping, or are you just inferring from the license that that constitutes modification and is thus bad?
<infinity> (cause I totally used to strip nvidia and fglrx in LRM and no one said a word)
<tseliot> infinity: this part comes from the Debian packaging: https://paste.ubuntu.com/p/wV4z2p6B6D/
<infinity> Actually, these *are* stripped.
<tseliot> it seems quite clear to me "provided that the binary files thereof are not modified in any way (except for unzipping of compressed files)."
<infinity> libnvidia-compiler.so.390.48 is just enormous.
<tseliot> well, nothing I can do about that
<infinity> Does it include an embedded copy of nvcc/icc?
<infinity> I bet it does.
<infinity> 46M
<infinity> Wow.
<infinity> tseliot: Alright, yes, not your fault.  I'm just going to back away slowly.
<infinity> Dearest nvidia, double-u tee eff.
<tseliot> :D
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (bionic-proposed/main) [0.8.7 => 0.8.8] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu9]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu20 => 0.6.5.6-0ubuntu21] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.3 => 0.6.5.11-1ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (bionic-proposed/universe) [1.20.0-3ubuntu1 => 1.20.0-4] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [source] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-17.18 => 4.15.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: pencil2d (bionic-proposed/universe) [0.6.1-1 => 0.6.1.1-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libnih (bionic-proposed/main) [1.0.3-6ubuntu1 => 1.0.3-6ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: sddm (bionic-proposed/universe) [0.17.0-1ubuntu6 => 0.17.0-1ubuntu7] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libdebian-installer (bionic-proposed/main) [0.110ubuntu1 => 0.110ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: manpages-de (bionic-proposed/universe) [2.4-1 => 2.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted manpages-de [sync] (bionic-proposed) [2.5-1]
<juliank> libnih, libdebian-installer fix tiny FTBFS due to changed parser results from libexpat, missing include
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: javabeans-activation-framework (bionic-proposed/universe) [1.2.0-1 => 1.2.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libdebian-installer [source] (bionic-proposed) [0.110ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: javabeans-activation-framework (bionic-proposed/universe) [1.2.0-1 => 1.2.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libnih [source] (bionic-proposed) [1.0.3-6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted sddm [source] (bionic-proposed) [0.17.0-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted javabeans-activation-framework [source] (bionic-proposed) [1.2.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pencil2d [sync] (bionic-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-terminal [sync] (bionic-proposed) [1.20.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted peruse [source] (bionic-proposed) [1.2+dfsg-2ubuntu1]
<acheronuk>  sddm, peruse, and mate-terminal builds all stuck on "INFO: pkgstripfiles: waiting for lock"
<cjwatson> (probably a pkgbinarymangler bug, or maybe something that uses parallelism in a way that confuses pkgbinarymangler)
<acheronuk> same for libdebian-installer
<acheronuk> pkgbinarymangler (137) bionic; urgency=medium "* Fix pkgstripfiles to not fail to clear the lock when processing dbgsym packages."
<apw> acheronuk, that likely is not installed in those builds
<cjwatson> ?
<cjwatson> pkgstripfiles wouldn't be complaining if it weren't installed
<apw> cjwatson, /me not clear enough
<apw> cjwatson, i think 137 is intended to fix that problem, and i was conjecturing it was too new to have been in the builds for peruse
<cjwatson> Oh, right
<apw> cjwatson, as it was only accepted 2 hours
<cjwatson> Sure, could be - cancel and retry?
<apw> ago ...
<acheronuk> 137 was published to release pocket 2hrs ago
<apw> sounds like a plan to me
<acheronuk> so launchpad says
<cjwatson> if you cancel and wait for the log, then it should tell you what version it used
<cjwatson> also I suppose it's possible there's a regression in 137
<Laney> https://launchpadlibrarian.net/366554696/buildlog_ubuntu-bionic-amd64.sddm_0.17.0-1ubuntu7_CANCELLING.txt.gz 137
<apw> Laney, that says there is a problem with 137 i think then
<acheronuk> ditto on peruse build I just cancelled
<apw> bah and that has made it to -release
<apw> cjwatson, would removing that from -release and publising 136 back work in this context ?
<cjwatson> In principle, yes, but a straight revert might actually be faster.
<cjwatson> (as well as easier to do -> safer)
<apw> cjwatson, can i build pkgmangler with this in play, i guess it only breaks -dbgsym packages
<cjwatson> Since all you have to do is get it published in -proposed in order for it to be used for builds, and -proposed is faster to publish.
<apw> lets try that then
<cjwatson> Good question.  Try it :)
<Laney> Hang on, let's spend 5 minutes looking at this
<apw> Laney, i dont' see why we need to wait for the lock for -dbgsym files, as we do nothing once we have the lock
<apw> Laney, but either way it looks 'fine'
<apw> it looks fine before without the change, in the sense i only uses the lock for not dbgsym packages
<apw> and though daft after the change it also looks fine
<Laney> ah right
<Laney> apw: so look in dh_builddeb, it initialises the lockfile with all packages
<Laney> and then those are cleared out by pkgstripfiles as it finishes
<Laney> but that initialisation doesn't include automatic debug packages
<Laney> so basically this upload looks wrong, but I'm not sure what problem Steve was seeing?
<Laney> peer review of those claims would be appreciated
<apw> Laney, so the problem he was seeing was we had to have our -dbgsym packages at the end of the control file
<apw> Laney, oh ... but of course _our_ dbgsym files are real, actually in control
<Laney> "our"?
<Laney> kernel?
<apw> "in the kernel package that triggered this issue" i think it was linux-signed specifically
<apw> that lead to that upload
<apw> sforshee, ^
<apw> _oh_ so that makes snese
<apw> packges have to be handled in _order_ from the "lockfile" right ?
<apw> and we would never remove a -dbgsym from the file, so if they are at the bottom
<sforshee> yes, that
<apw> we just don't notice there are 3 left, but if they are in the middle we will get stuck
<apw> becuase anything after the first one never gets to play
<apw> Laney, so i think it makes sense to check if we are in the lockfile and then do it, else not
<apw> _or_ always skip -dbgsym files as we did before
<apw> and have a bodge in wait_for_lock which removes anyting -sdbsym from the list
<apw> Laney, opinions ?
<apw> i can try either
<Laney> Is there a reason to be acting on dbgsym packages?
<Laney> You could filter them out in dh_builddeb too, so they never appear in the lockfile
<sforshee> apw: do we really need to do this business of putting unsigned in the name of the dbgsym file from the kernel package? If we didn't do that we wouldn't need those packages in meta.
<apw> sforshee, yes
<apw> sforshee, because launchpad won't accept a -dbgsym for a package you don't upload
<sforshee> ah
<apw> as i found out from teh upload failure i got when i did it the other way :)
<apw> Laney, how about: http://paste.ubuntu.com/p/8MVP54pzWs/
<apw> no that won't work either
<apw> becasue all those waiters will do it, derp
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.1 => 1:0.5.2] (desktop-core, ubuntu-server)
<Laney> one second
<apw> Laney, so i think _that_ would be safe, though vile: http://paste.ubuntu.com/p/2ytt32nyKB/
<coreycb> slangasek: i'll take a look at networking-arista
<apw> Laney, nope even that isn't safe, needs to be in the other order
 * apw casually wonders why this isn't just a lockfile, with like flock
<xnox> i'm late to the party, and apw/laney will fix the waiting for lock soon, right? cause systemd build is stuck doing that for 3h now. Which is not good.
<xnox> should i cancel and restart those builds? they typically take about 15minutes or so
<infinity> xnox: Canceling and restarting won't help as long as the bug isn't fixed. :P
<Laney> apw: I was thinking something like https://paste.ubuntu.com/p/Mw55mD3tSk/
 * apw wonders what Laney has planned if anything
<acheronuk> cancel now. restart later is the plan I hope
 * Laney sprays you all with a cold hose
<Laney> BECALM!
<apw> Laney, that looks sane enough to me, and beter than anything i have
<apw> didn't realise that was in pkgmangler too
 * xnox is a wet puppy now
<apw> Laney, assuming that is the only thing that is used for of course
<Laney> ya, have a look at dh_builddeb in pkgbinarymangler
<Laney> anybody else want to review?
<Laney> this is "a problem shared is a problem halved" working in a negative sense. :P
<Laney> just uploaded, please to review
<apw> Laney, yeah looks ok in the sense there is no consumers of "packages other than it
-queuebot:#ubuntu-release- Unapproved: pkgbinarymangler (bionic-proposed/main) [137 => 138] (kubuntu, ubuntu-desktop)
<Laney> apw: you probably want to check your original case
<Laney> I did a test build of sddm
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.3-0ubuntu3 => 1:3.26.3-0ubuntu4] (ubuntu-desktop)
<apw> Laney, yeah both bits look sane to me
<apw> Laney, this can't really break it any worse either
<Laney> could probably even remove that case statement now
<Laney> but it's belt and braces I guess
<apw> i am not sure we don't still process them the other ways right ?
-queuebot:#ubuntu-release- Unapproved: accepted pkgbinarymangler [source] (bionic-proposed) [138]
<apw> but whatever, it is definatly all of those belt-n-braces-n-string-n-gum
<apw> Laney, i don't know whether i am happy or sad this thing has such extensive tests
<Laney> :D
<Laney> clearly not quite extensive enough
<apw> there is that, well he should have added tests, and they would have failed
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-18.19] (core, kernel)
<slangasek> doko: octave-io is cleared; octave + java-common is just waiting for an override of the flaky octave-symbolic (unless the current retry happens to finally pass), plus closing the blocking bug
-queuebot:#ubuntu-release- New source: candid (bionic-proposed/primary) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
<nacc> doko: yeah, i had forgotten why we had the delta, but your merge was still wrong :)
<nacc> doko: totally my fault on the sync suggestion
-queuebot:#ubuntu-release- Unapproved: libcommons-lang3-java (bionic-proposed/universe) [3.5-2 => 3.5-2ubuntu1] (no packageset)
<Laney> xnox: acheronuk you can retry now
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-lang3-java [source] (bionic-proposed) [3.5-2ubuntu1]
<acheronuk> Laney: just did :)
<Laney> k
<acheronuk> some success on faster builders. waiting on the slower ones
-queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.7-1 => 1.8.8-1] (ubuntu-server) (sync)
<nacc> slangasek: --^ fyi, new haproxy sync which includes an up-to-now embargoed CVE fix
<slangasek> nacc: I'm on vacation today, infinity should drive the accepts in the run up to candidate image prep
<nacc> slangasek: sorry for the noise! Enjoy your vacation
<slangasek> apw, Laney: sorry for the pkgbinarymangler regression.  We probably could've done without 137 after sforshee changed the linux-signed debian/control, but
-queuebot:#ubuntu-release- Unapproved: surefire (bionic-proposed/universe) [2.20.1-3 => 2.20.1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (bionic-proposed) [1:3.26.3-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted surefire [source] (bionic-proposed) [2.20.1-3build1]
<coreycb> slangasek: jamespage: i uploaded a new version of networking-arista to bionic that reverts the py3 support back to py2 since we don't have python3-neutron in ubuntu yet
-queuebot:#ubuntu-release- Unapproved: networking-arista (bionic-proposed/universe) [2017.2.2-2 => 2017.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-arista [source] (bionic-proposed) [2017.2.2-2ubuntu1]
<xnox> coreycb, sad. Let's see if we can manage py3 openstack by 20.04. If not default, at least some deployment types.
<coreycb> xnox: we're planning to work on it in the coming release. note though that upstream openstack is still not fully py3 compatible.
<xnox> coreycb, yeah, i've been trying to track status. And it was a "release goal something" in the previous release, but not this one. Not sure how it is best to see or track upstream status for it.
<coreycb> xnox: there's this, though i've not looked in a while to see how updated it is: https://wiki.openstack.org/wiki/Python3
<coreycb> xnox: there are some 2018 notes in there so it seems to be maintained
<coreycb> xnox: anyway, planning to start digging in soon after bionic release
<xnox> cool
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.191 => 3.192] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New sync: jquery-i18n.js (bionic-proposed/primary) [1.1.2+dfsg1-2]
<tsimonq2> infinity: It would be good to get bug 1763611 fixed before the release.
<ubot5`> bug 1763611 in lubuntu-meta (Ubuntu) "Lubuntu bionic boots slower than the other Ubuntu flavours with some SSDs" [Undecided,Confirmed] https://launchpad.net/bugs/1763611
<tsimonq2> Could you please take a look?
<tsimonq2> I'm willing to bet that I'm missing a package.
<cjwatson> tsimonq2: Lubuntu builds with --no-install-recommends, and ureadahead is a Recommends of ubuntu-standard
<cjwatson> so that would be my first guess
<tsimonq2> Aha.
<tsimonq2> cjwatson: You're welcome to JFD that seed change, or I can later.
<tsimonq2> Thanks.
<cjwatson> Though it does seem to be in your live image.  But there may some some detail along those lines, anyway, it might depend on exact installation method
<tsimonq2> Ah.
<cjwatson> (and I don't have especially up-to-date seed checkouts either, so ICBW)_
<cjwatson> I don't do it, trying to get a few last-minute LP changes done before my EOW
<cjwatson> *won't
<tsimonq2> OK.
<cjwatson> I seem to be all about the typoes today
-queuebot:#ubuntu-release- Unapproved: update-notifier (artful-proposed/main) [3.186 => 3.186.1] (ubuntu-desktop, ubuntu-server)
<bdmurray> sil2100: Are you still about?
<tsimonq2> Typos or typoes? ;P
<gQuigs> tsimonq2: the linked bug's last comment indicates it's a swap file issue.. ..
<cjwatson> Probably typos
<tsimonq2> gQuigs: So then what might be the difference between Lubuntu and others?
<gQuigs> tsimonq2: I'd wager it's an ubiquity bug because  they use zram
<tsimonq2> Ah, I see.
<tsimonq2> Thanks for the pointer gQuigs.
<gQuigs> and the issue involves an extra resume file...  - https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py
<gQuigs> the resume_partition bits have a check for zram..
<sil2100> bdmurray: yeah
<sil2100> bdmurray: what's up?
<bdmurray> sil2100: an sru review of update-notifier would be nice.
<sil2100> bdmurray: oh, sure, on it in 5 mins
<sil2100> cjwatson: btw. the requested langpack export ended up a delta one, I guess the checkbox wasn't fully checked
<sil2100> cjwatson: should I checkbox it myself an request a re-run of the earlier command?
<sil2100> Would that be enough for triggering a full export?
<cjwatson> Should be.  Maybe Laurent forgot to submit that form first or something?
-queuebot:#ubuntu-release- Unapproved: linux-kvm (bionic-proposed/main) [4.15.0-1004.4 => 4.15.0-1006.6] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (bionic-proposed/main) [4.15.0.1004.4 => 4.15.0.1006.6] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-aws (bionic-proposed/main) [4.15.0-1003.3 => 4.15.0-1005.5] (kernel, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (bionic-proposed/main) [4.15.0.1003.3 => 4.15.0.1005.5] (kernel, ubuntu-budgie) (sync)
<sil2100> bdmurray: ok, sounds sane, better than having nothing
<sil2100> infinity: I'm approving update-notifier for bionic too ^
<bdmurray> sil2100: its not great but again better than nothing.
<sil2100> Not a release blocker for bionic, but we should have it in bionic to accept it for artful, and for artful I find it quite ekhm, important
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192]
<sil2100> bdmurray: both accepted, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (artful-proposed) [3.186.1]
<gQuigs> happy to help :)
<tsimonq2> gQuigs: I said thanks in the bug report, but thanks here. :)
<davecore> it looks like the 18.04 release notes have some issues with the daily image links   https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes
<davecore> 1) in https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Download_Ubuntu_18.04_LTS ,      this link really points only to desktop :    http://cdimage.ubuntu.com/daily-live/current/ (Ubuntu Desktop and debian-installer based Server)
<davecore> 2) and then in https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Server_installer     for the alternate installer  I think we should point  to   http://cdimage.ubuntu.com/ubuntu-server/daily/current   instead
<xnox> davecore, these are still beta notes, you may ignore all of that.
<xnox> davecore, testing of the milestone should be done based on the URLs from the ISO tracker
<xnox> davecore, release notes will point at the release locations, not at dailies, and not at RC image locations and names.
<xnox> final notes will not have links for dailies.
<davecore> xnox: understood, thank you
<slangasek> tsimonq2: ffmpeg still not migrating; now that the arch-any revdeps of libav-tools have been resolved, update_output shows some x86-only revdeps
<slangasek> tsimonq2: (dvdrip, pictor, videoporama)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-18.19]
<gaughen> slangasek, infinity, sil2100 - the fix for this bug - https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1765833 - needs to land before release imo.  It's a blocking issue for a cloud partner.
<ubot5`> Ubuntu bug 1765833 in netplan.io (Ubuntu) "bond intervals default to seconds; breaks existing configs" [Undecided,New]
<gaughen> rharper has a proposed fix
<gaughen> and cyphermox is going to review
<tsimonq2> slangasek: Gah. Thanks.
<rbalint> xnox, infinity, slangasek: can this go in before the release? using the fix fixed xenia - > bionic upgrade for me LP: #1748659
<ubot5`> Launchpad bug 1748659 in systemd (Ubuntu) "Windows 10 Ubuntu 16.04 upgrade to 18.04: package systemd 235-3ubuntu3 failed to install/upgrade: installed systemd package post-installation script subprocess returned error exit status 1" [Critical,Triaged] https://launchpad.net/bugs/1748659
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (bionic-proposed/universe) [4.15.0.1006.4 => 4.15.0.1008.6] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (bionic-proposed/universe) [4.15.0-1006.7 => 4.15.0-1008.9] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.16 => 2.20.1-0ubuntu2.17] (core)
<tsimonq2> infinity, slangasek: Lubuntu considers fixing bug 1763611 to be release-critical. MP here: https://code.launchpad.net/~tsimonq2/ubiquity/lp-1763611/+merge/343742
<ubot5`> bug 1763611 in ubiquity (Ubuntu) "Lubuntu bionic boots slower than the other Ubuntu flavours with some SSDs" [High,Confirmed] https://launchpad.net/bugs/1763611
<nacc> infinity: slangasek: fyi, the puppet revdep regression appears to also exist in debian, where it claims it has never passed
<nacc> infinity: additionally, I *think* the regression is actually in facter based upon some brief googling i did into the error a while ago
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu5 => 2.20.9-0ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: indicator-sound (bionic-proposed/universe) [12.10.2+17.10.20170829.1-0ubuntu2 => 12.10.2+18.04.20180420.3-0ubuntu1] (ubuntu-desktop) (sync)
<slangasek> rbalint: LP: #1748659 would from my perspective be best-effort for GA since we don't turn on upgrades between LTSes until .1 by default.  If someone uploads to the queue, we would evaluate it
<ubot5`> Launchpad bug 1748659 in systemd (Ubuntu) "Windows 10 Ubuntu 16.04 upgrade to 18.04: package systemd 235-3ubuntu3 failed to install/upgrade: installed systemd package post-installation script subprocess returned error exit status 1" [Critical,Triaged] https://launchpad.net/bugs/1748659
<slangasek> nacc: running 'retry-autopkgtest-regressions --blocks puppet --no-proposed | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O-' to confirm whether it's puppet-triggered
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.10-2 => 5.2.11-122181-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (bionic-proposed) [5.2.11-122181-1]
<nacc> slangasek: thanks
<tsimonq2> slangasek: ffmpeg> Should be good now, I think.
-queuebot:#ubuntu-release- Unapproved: dvdrip (bionic-proposed/multiverse) [1:0.98.11-0ubuntu6 => 1:0.98.11-0ubuntu7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: videoporama (bionic-proposed/universe) [0.8.1-0ubuntu6 => 0.8.1-0ubuntu7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pictor (bionic-proposed/universe) [2.38-0ubuntu1 => 2.38-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dvdrip [source] (bionic-proposed) [1:0.98.11-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted videoporama [source] (bionic-proposed) [0.8.1-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted pictor [source] (bionic-proposed) [2.38-0ubuntu2]
<tsimonq2> slangasek: This FTBFS is unrelated to what I changed (I just changed a runtime dep): https://launchpad.net/ubuntu/+source/dvdrip/1:0.98.11-0ubuntu7
<tsimonq2> Sigh.
#ubuntu-release 2018-04-21
-queuebot:#ubuntu-release- Unapproved: linux-azure (bionic-proposed/main) [4.15.0-1004.4 => 4.15.0-1007.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (bionic-proposed/main) [4.15.0-1004.4 => 4.15.0-1007.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (bionic-proposed/main) [4.15.0.1004.5 => 4.15.0.1007.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (bionic-proposed/main) [4.15.0-1003.3 => 4.15.0-1004.4] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (bionic-proposed/main) [4.15.0.1003.5 => 4.15.0.1004.6] (kernel) (sync)
<slangasek> tsimonq2: resume partition> yuck.  Ok, uploading / accepting; please tag your branch
<wxl> slangasek: tsimonq2: did you notice the ubiquity bug just fixed itself?
<tsimonq2> slangasek: Sure.
<tsimonq2> wxl: Yep.
<slangasek> wxl: the ubiquity-dm one?  I certainly noticed
<wxl> i.. don't even
<tsimonq2> wxl: I think it's safe to assume that I, Steve, Adam, and Colin are equally lolwat'ting at that.
<tsimonq2> Super werid.
<tsimonq2> *weird (just like my spelling of it, hah)
<tsimonq2> slangasek: jibel didn't tag 18.04.8.
<slangasek> tsimonq2: well, I can't fix either lack of tag, I can only ask people to tag :)
<tsimonq2> slangasek: tag 18.04.9> .
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.8 => 18.04.9] (core)
<tsimonq2> slangasek: asking people to tag> Why don't Core Developers have commit access to Ubiquity, so if an upload is *needed*, they can JFDI?
<slangasek> tsimonq2: because we have not succeeded in having a universal VCS import yet that guarantees usable VCS branches with the correct ACLs
<tsimonq2> slangasek: Ah.
-queuebot:#ubuntu-release- Unapproved: dvdrip (bionic-proposed/multiverse) [1:0.98.11-0ubuntu7 => 1:0.98.11-0ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dvdrip [source] (bionic-proposed) [1:0.98.11-0ubuntu8]
<tsimonq2> infinity, slangasek: So, moving forward with getting rid of opt-in milestones: https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004434.html
<slangasek> tsimonq2: ^^ dvdrip
<tsimonq2> slangasek: dvdrip> ack, much appreciated.
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [3.4.1-7 => 3.4.1-7ubuntu1] (no packageset)
<tsimonq2> slangasek: ubiquity? :)
-queuebot:#ubuntu-release- Unapproved: accepted gradle [source] (bionic-proposed) [3.4.1-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.9]
<tsimonq2> Cool, thanks.
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu5 => 25ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [21ubuntu2 => 21ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [21ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (bionic-proposed) [25ubuntu6]
<doko> how did the dh-ada-library autopkg test failure get resolved?
<slangasek> doko: ubuntu-release:force-badtest dh-ada-library/6.12
<slangasek> doko: "resolved" by confirming it regressed in the release pocket
<infinity> Awesome, new NBS in release week.
<infinity> (only affects universe, at least)
<infinity> Oh, but also affects studio.
<infinity> Whee.
-queuebot:#ubuntu-release- Unapproved: groovy (bionic-proposed/universe) [2.4.15-1 => 2.4.15-1ubuntu1] (no packageset)
<slangasek> infinity: libav-tools only has reverse-recommends and is safe to remove
<tsimonq2> Oh, that fun one. :P
<infinity> slangasek: Sexcellent.  Does that mean you've run the command?
<slangasek> infinity: now I have
-queuebot:#ubuntu-release- Unapproved: accepted groovy [source] (bionic-proposed) [2.4.15-1ubuntu1]
<slangasek> ah and it looks like you've retried the activemq build which I missed doing
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [sync] (bionic-proposed) [1.8.8-1]
<infinity> I did indeed.
<infinity> And it failed. :/
<infinity> [ERROR] Exit code: 1 - javadoc: warning - You have not specified the version of HTML to use.
<infinity> That might be an easy fix.
<infinity> slangasek: Lemme slam that localechooser in the queue for you, then I'll be "at work" in a couple of hours to get balls rolling.
<slangasek> perhaps it requires the fix for https://bugs.launchpad.net/ubuntu/+source/gradle-debian-helper/+bug/1765883
<ubot5`> Ubuntu bug 1765883 in groovy (Ubuntu) "gradle-debian-helper relies on an invalid java api directory" [Undecided,New]
<slangasek> infinity: ack
<slangasek> infinity: am currently working on trying to fix linux-signed to manually generate dbgsym packages that are actually ddebs instead of being shoved into the main archive; dunno if you have any experience doing this?
<infinity> slangasek: They just need to be renamed to ddeb, probably.
<infinity> Missed that in the review.  *sigh*
<slangasek> infinity: yes; but what's a sane way to do that? manually editing debian/files?
<slangasek> I guess dh_builddeb takes a --filename option
<infinity> slangasek: There's prior art in debian/rules.d/2-binary-arch.mk in linux.
<slangasek> ah, k
<infinity> slangasek: Grep for "Hokay", and the block there that ends with 9>$(lockme_file)
-queuebot:#ubuntu-release- Unapproved: accepted indicator-sound [sync] (bionic-proposed) [12.10.2+18.04.20180420.3-0ubuntu1]
 * infinity is AFK for a bit.
<tsimonq2> If I wanted one last fix in for Kubuntu that fixes a memory leak, am I cutting it too close? :P
<tsimonq2> (My guess is "no" because I don't see images yet. It'll need queue approval anyway.)
 * tsimonq2 sighs at bug 1765900 being thrown at me last minute...
<ubot5`> bug 1765900 in kdepim (Ubuntu) "Cherry-pick af23ae70e47d9d7e93c013d107397999df0ecb56 into BIonic to fix OOM crasher for certain calendar events" [Undecided,New] https://launchpad.net/bugs/1765900
-queuebot:#ubuntu-release- Unapproved: kdepim-addons (bionic-proposed/universe) [17.12.3-0ubuntu1 => 17.12.3-0ubuntu2] (kubuntu)
<tsimonq2> Now, I did also see a Ubiquity issue...
 * tsimonq2 hunts
<tsimonq2> Aaaand that'd be mine. ^^^^^^^
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-18.19 => 4.15.0-18.19+signed1] (core, kernel)
<tsimonq2> Scratch that Ubiquity bug.
<slangasek> infinity: ^^ linux-signed for your review; locally tested to DTRT; patches sent to the list
<slangasek> infinity: and I didn't see a localechooser upload yet
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-addons [source] (bionic-proposed) [17.12.3-0ubuntu2]
<infinity> slangasek: Oh, did I fail to upload that somehow?
<infinity> ... I uploaded the binary .changes, not the source.
<infinity> Brilliant.
-queuebot:#ubuntu-release- Unapproved: localechooser (bionic-proposed/main) [2.71ubuntu1 => 2.71ubuntu2] (core)
<slangasek> infinity: the languagelist changes regress translations?
<slangasek> infinity: the bits in 05localechooser could be done with a single grep+sed, which might be more readable/maintainable; but what's there looks ok
<slangasek> infinity: going afk again for a bit; I propose retaining 'No localization' as the string for C.UTF-8 and only introducing 'No localization (ASCII)' for C in order to minimize the translation skew if these are strings that are displayed; and +1 from me for you self-accepting with or without that single change
<infinity> slangasek: Those strings aren't translated, though?
<infinity> slangasek: Or, rather, the file is its own translation, and C was always just in English (just as English is...), given the assumption that you wouldn't choose C if you couldn't speak English.
<infinity> slangasek: So, yeah, I'll self-accept.
-queuebot:#ubuntu-release- Unapproved: accepted localechooser [source] (bionic-proposed) [2.71ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19+signed1]
<slangasek> infinity: ack
<slangasek> grumble, how did linux-signed ftbfs
<slangasek> grumble grumble
<slangasek> because I didn't test build after incrementing the version number
<slangasek> right, well, fixed, but now upload.u.c is timing out
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-18.19 => 4.15.0-18.19+signed2] (core, kernel)
<slangasek> there we go; self-accepting on grounds of triviality slash paper bag
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-18.19+signed2]
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.1 => 1.34.2] (core)
<slangasek> infinity: ^^ this is untested, but is possibly the fix for an upgrade failure in the version currently in -proposed
<infinity> slangasek: Well, I do love the word "untested".
<infinity> slangasek: Looks sensible, though.
<slangasek> we will separately need to fix LP: #1765905 however
<ubot5`> Launchpad bug 1765905 in shim-signed (Ubuntu) "package shim-signed 1.34.1+13-0ubuntu2 failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1765905
<slangasek> ... a bug which somehow I can't change the title of
<slangasek> infinity: shim-signed 1.34.3 uploaded for that.
<slangasek> and I'm out
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.1 => 1.34.3] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu9 => 237-3ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (bionic-proposed/main) [16.10+18.04.20180328-0ubuntu1 => 16.10+18.04.20180421.1-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu537 => 20101020ubuntu538] (core)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.3]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu538]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (bionic-proposed) [16.10+18.04.20180421.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rails (bionic-proposed/universe) [2:4.2.10-1 => 2:4.2.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rails [source] (bionic-proposed) [2:4.2.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: i2p (bionic-proposed/universe) [0.9.34-1ubuntu1 => 0.9.34-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted i2p [source] (bionic-proposed) [0.9.34-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rjava (bionic-proposed/universe) [0.9-9-1 => 0.9-9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rjava [source] (bionic-proposed) [0.9-9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: electric (bionic-proposed/universe) [9.07+dfsg-3 => 9.07+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted electric [source] (bionic-proposed) [9.07+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: uddi4j (bionic-proposed/universe) [2.0.5-3 => 2.0.5-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uddi4j [source] (bionic-proposed) [2.0.5-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: modulator (bionic-proposed/universe) [1.0-2 => 1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted modulator [source] (bionic-proposed) [1.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libjide-oss-java (bionic-proposed/universe) [3.7.2+dfsg-1 => 3.7.2+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libjide-oss-java [source] (bionic-proposed) [3.7.2+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-base (bionic-proposed/universe) [3.4.4-1 => 3.4.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-base [source] (bionic-proposed) [3.4.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.1+10-1ubuntu2 => 10.0.1+10-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (bionic-proposed) [10.0.1+10-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [16ubuntu3 => 16ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [source] (bionic-proposed) [16ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [9ubuntu1 => 9ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libdvd-pkg (bionic-proposed/multiverse) [1.4.1-1-1 => 1.4.2-1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libdvd-pkg [sync] (bionic-proposed) [1.4.2-1-1]
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [6ubuntu2 => 6ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (bionic-proposed) [6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gscan2pdf (bionic-proposed/universe) [2.0.3-1 => 2.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gscan2pdf [sync] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu3 => 20ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mbrola-af1 (bionic-proposed/multiverse) [0.0.20040426-2 => 0.0.20040426+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-af1 [sync] (bionic-proposed) [0.0.20040426+repack-3]
-queuebot:#ubuntu-release- Unapproved: mbrola-br2 (bionic-proposed/multiverse) [2.021-1 => 2.021+repack-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mbrola-br3 (bionic-proposed/multiverse) [2.021-2 => 2.021+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br2 [sync] (bionic-proposed) [2.021+repack-2]
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br3 [sync] (bionic-proposed) [2.021+repack-3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [source] (bionic-proposed) [20ubuntu4]
-queuebot:#ubuntu-release- Unapproved: mbrola-br4 (bionic-proposed/multiverse) [1.0-1 => 1.0+repack-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (bionic-proposed) [9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mbrola-cr1 (bionic-proposed/multiverse) [0.0.19981028-2 => 0.0.19981028+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-cr1 [sync] (bionic-proposed) [0.0.19981028+repack-3]
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br4 [sync] (bionic-proposed) [1.0+repack-2]
-queuebot:#ubuntu-release- Unapproved: mbrola-de1 (bionic-proposed/multiverse) [2.050-1 => 2.050+repack-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-de1 [sync] (bionic-proposed) [2.050+repack-2]
-queuebot:#ubuntu-release- Unapproved: electric (bionic-proposed/universe) [9.07+dfsg-3ubuntu1 => 9.07+dfsg-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted electric [source] (bionic-proposed) [9.07+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: i2p (bionic-proposed/universe) [0.9.34-1ubuntu2 => 0.9.34-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted i2p [source] (bionic-proposed) [0.9.34-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gradle-debian-helper (bionic-proposed/universe) [1.6 => 1.6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gradle-debian-helper [source] (bionic-proposed) [1.6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libws-commons-util-java (bionic-proposed/universe) [1.0.1-9 => 1.0.1-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libws-commons-util-java [sync] (bionic-proposed) [1.0.1-10]
-queuebot:#ubuntu-release- Unapproved: libtablelayout-java (bionic-proposed/universe) [20090826-3 => 20090826-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libtablelayout-java [sync] (bionic-proposed) [20090826-4]
-queuebot:#ubuntu-release- Unapproved: fast-zip-visit-clojure (bionic-proposed/universe) [1.0.2-1 => 1.0.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fast-zip-visit-clojure [sync] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted jquery-i18n.js [sync] (bionic-proposed) [1.1.2+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted musescore-general-soundfont [sync] (bionic-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted kylin-video [source] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: jquery-i18n.js [amd64] (bionic-proposed/none) [1.1.2+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [s390x] (bionic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-general-soundfont [amd64] (bionic-proposed/none) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [ppc64el] (bionic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [amd64] (bionic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [i386] (bionic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [arm64] (bionic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kylin-video [armhf] (bionic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted jquery-i18n.js [amd64] (bionic-proposed) [1.1.2+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted kylin-video [arm64] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kylin-video [i386] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kylin-video [s390x] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kylin-video [amd64] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kylin-video [ppc64el] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kylin-video [armhf] (bionic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted musescore-general-soundfont [amd64] (bionic-proposed) [0.1.1-2]
<sforshee> anyone around who can approve some kernels in the bionic queue?
<slangasek> the only thing worse than users installing from devel-proposed is users installing from yesterday's devel-proposed
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.3 => 1.34.4] (core)
<slangasek> infinity: ^^ shim-signed 1.34.4 in the queue, fixes one further upgrade failure.
<slangasek> (I didn't make the effort to guard this in the previous upload because I figured it was a safe assumption that a dkms package had at least one .ko :P)
<xnox> one would think so, right?! =)
<slangasek> yeah, but it seems necessary to be even more defensive
<slangasek> no assuming that your dkms packages have actual modules, no assuming that your hostname doesn't overflow x509, ...
<slangasek> in retrospect the status message I output there is probably insufficient - you might have the situation where there are multiple kernel versions installed and only some of them have the kernel module built
<slangasek> so that probably needs a refactor in the next round
<slangasek> and then there's LP: #1765939, which I have no idea about.  If someone spots a bug there that I'm missing, please shout
<ubot5`> Launchpad bug 1765939 in shim-signed (Ubuntu) "package shim-signed 1.34.1+13-0ubuntu2 failed to install/upgrade: Unterprozess installed shim-signed package post-installation script gab den Fehler-Ausgangsstatus 1 zurÃ¼ck" [Undecided,Incomplete] https://launchpad.net/bugs/1765939
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (bionic-proposed) [4.15.0-1006.6]
<infinity> slangasek: I missed this on the previous review, but does that pattern actually match things for you?
<infinity> slangasek: Ahh, NM, two competing directory structures in /var/lib/dkms, and I took the wrong one. :P
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.4]
<infinity> cyphermox: Was anyone looking at https://bugs.launchpad.net/ubuntu/+source/sound-icons/+bug/1762039 ?
<ubot5`> Ubuntu bug 1762039 in sound-icons (Ubuntu) "[MIR] sound-icons" [Undecided,New]
<infinity> cyphermox: It affects the contents of the images depending on which component it's in, so we need a decision or the recommends dropped.
<infinity> cyphermox: Given it's just icons, I'm tempted to just promote it and let you follow up. :P
<jbicha> infinity: seb128 didn't think sound-icons was needed but it's such a small pkg it didn't seem like much of a problem
<jbicha> I didn't get much response at https://lists.debian.org/debian-accessibility/2018/04/msg00000.html
<slangasek> infinity: be9dc78fccc80bb5045c67b435b5c7e36ea8a296.patch was not the only necessary fix to rails that was dropped on sync
<slangasek> the sdoc versioning stuff is also needed
<slangasek> but I'm not going to be TIL ;P
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (bionic-proposed) [4.15.0.1006.6]
<infinity> slangasek: Yeah, I was tired when I looked at the test log, I guess. :/
<infinity> slangasek: But also, I have a shower and cab ride between me and being stuck in the air, so it's not gonna be me.
<infinity> Going to set up the milestone and spin up a test set when I get to the airport.
<infinity> They'll intentionally not have the right volume label or base-files, since I know we need some more stuff to land (like, say, the kernel), but we should still start getting test results over the weekend.
<infinity> And for some reason, it's impossible to get people to test without a milestone.  Hopefully tsimonq2 has a master plan to fix people next cycle. :)
<tsimonq2> Hopefully it works. :P
<slangasek> infinity: shall I work on updating d-i for linux?  anything else that needs doing for that to land?
<infinity> slangasek: It might need jiggling to adjust for linux-signed stuff, maybe.  I was going to deal with it when I get to London, but if you're out of other interesting things to do..
<infinity> slangasek: I also got a (very vague) complaint that ubiquity translations seem incomplete compared to LP.  It might be overdue for an import.
<slangasek> infinity: AIUI the signed stuff was left unchanged for d-i in order to not have to mess with it.  But also, sforshee just gave me a headsup that this kernel isn't releasable
<infinity> Right, new kernel it is.  Yay.  I'll poke d-i when I get to London, hoping you've accepted a new kernel by then. :P
<slangasek> infinity: I don't know how to do that import if it's not something done by the bzr-builddeb hook
<infinity> slangasek: cjwatson, xnox, cyphermox should all know if it's not.  Not sure I've done it either.
<slangasek> infinity: k. and if it is done by the hook, well, that happened automatically on my latest uploads
-queuebot:#ubuntu-release- Unapproved: libbytesize (bionic-proposed/universe) [1.2-1build1 => 1.2-3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kgb-bot (bionic-proposed/universe) [1.42-1 => 1.48-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kgb-bot [sync] (bionic-proposed) [1.48-1]
-queuebot:#ubuntu-release- Unapproved: ros-image-common (bionic-proposed/universe) [1.11.11-2build2 => 1.11.11-3] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: hkl (bionic-proposed/primary) [5.0.0.2449-1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-image-common [sync] (bionic-proposed) [1.11.11-3]
-queuebot:#ubuntu-release- Unapproved: ros-resource-retriever (bionic-proposed/universe) [1.12.3-1build1 => 1.12.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-resource-retriever [sync] (bionic-proposed) [1.12.3-2]
-queuebot:#ubuntu-release- New: accepted hkl [sync] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] (20101020ubuntu538) has been added
-queuebot:#ubuntu-release- New binary: hkl [s390x] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hkl [ppc64el] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hkl [amd64] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hkl [i386] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-lambdabot-haskell-plugins (bionic-proposed/primary) [5.1.0.1-2]
-queuebot:#ubuntu-release- New: accepted hkl [amd64] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- New: accepted hkl [ppc64el] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- New: accepted hkl [i386] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- New: accepted hkl [s390x] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [sync] (bionic-proposed) [5.1.0.1-2]
-queuebot:#ubuntu-release- New binary: hkl [arm64] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lambdabot (bionic-proposed/universe) [5.0.3-4 => 5.1.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lambdabot [sync] (bionic-proposed) [5.1.0.1-2]
-queuebot:#ubuntu-release- New: accepted hkl [arm64] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- New binary: hkl [armhf] (bionic-proposed/universe) [5.0.0.2449-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- New: accepted hkl [armhf] (bionic-proposed) [5.0.0.2449-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] (20180421.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] (20180421.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] (20180421.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] (20180421.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Unapproved: mbrola-af1 (bionic-proposed/multiverse) [0.0.20040426+repack-3 => 0.0.20040426+repack-4] (no packageset) (sync)
<infinity> slangasek: All rebuilds triggered, call for testing sent to ubuntu-release.
-queuebot:#ubuntu-release- Unapproved: mbrola-br1 (bionic-proposed/multiverse) [2.021+repack-2 => 2.021+repack-3] (no packageset) (sync)
<infinity> tsimonq2: Can you bounce the above call for testing to other appropriate QA lists and IRC channels and the like, and help prod people to wake up and care?
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-af1 [sync] (bionic-proposed) [0.0.20040426+repack-4]
-queuebot:#ubuntu-release- Unapproved: mbrola-br2 (bionic-proposed/multiverse) [2.021+repack-2 => 2.021+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mbrola-cr1 (bionic-proposed/multiverse) [0.0.19981028+repack-3 => 0.0.19981028+repack-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br1 [sync] (bionic-proposed) [2.021+repack-3]
-queuebot:#ubuntu-release- Unapproved: mbrola-br3 (bionic-proposed/multiverse) [2.021+repack-3 => 2.021+repack-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mbrola-cz2 (bionic-proposed/multiverse) [0.2+repack-3 => 0.2+repack-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br2 [sync] (bionic-proposed) [2.021+repack-3]
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-cr1 [sync] (bionic-proposed) [0.0.19981028+repack-4]
-queuebot:#ubuntu-release- Unapproved: mbrola-de1 (bionic-proposed/multiverse) [2.050+repack-2 => 2.050+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-br3 [sync] (bionic-proposed) [2.021+repack-4]
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-cz2 [sync] (bionic-proposed) [0.2+repack-4]
-queuebot:#ubuntu-release- Unapproved: accepted mbrola-de1 [sync] (bionic-proposed) [2.050+repack-3]
-queuebot:#ubuntu-release- Unapproved: python-stringtemplate3 (bionic-proposed/universe) [3.1-3 => 3.1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-traceback2 (bionic-proposed/main) [1.4.0-4 => 1.4.0-5] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-stringtemplate3 [sync] (bionic-proposed) [3.1-4]
-queuebot:#ubuntu-release- Unapproved: python-sphinxcontrib.plantuml (bionic-proposed/universe) [0.5-3 => 0.5-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] (20180421.1) has been added
<infinity> slangasek: No britney block in place yet, as we're 100% sure these images aren't final, will probably drop the block in on Monday morning when we're more sure.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Unapproved: accepted python-sphinxcontrib.plantuml [sync] (bionic-proposed) [0.5-4]
<infinity> slangasek: Feel free to executive override that decision if the churn scares you, but things have looked pretty conservative so far, and we have the queue freeze to prevent the worst derp.
-queuebot:#ubuntu-release- Unapproved: accepted libbytesize [sync] (bionic-proposed) [1.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-traceback2 [sync] (bionic-proposed) [1.4.0-5]
<tsimonq2> infinity: Yepper.
 * tsimonq2 cracks knuckles
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] (20180421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] (20180421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] (20180421.1) has been added
#ubuntu-release 2018-04-22
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] (20180421.1) has been added
<tsimonq2> infinity: There. Poked in every place I can.
<tsimonq2> (Meaning, where I can post announcements ... :P)
<tsimonq2> slangasek: Since infinity is in the air right now, these links are dead: http://iso.qa.ubuntu.com/qatracker/milestones/389/builds/170821/downloads
<tsimonq2> Should I expect them to appear Shortly?
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] (20180421.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] (20180421.1) has been added
<ErichEickmeyer> Thatâs my cue, but Iâm stuck at work. Iâll alert the crew when I get home.
<slangasek> tsimonq2: apparently, since the links are live as of this moment
-queuebot:#ubuntu-release- Unapproved: ros-geometry (bionic-proposed/universe) [1.11.9-1 => 1.11.9-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-geometry [sync] (bionic-proposed) [1.11.9-3]
<tsimonq2> slangasek: Indeed.
 * tsimonq2 sighs
<tsimonq2> Expect patches for bug 1761592.
<ubot5`> bug 1761592 in ubiquity-slideshow-ubuntu (Ubuntu) "Kubuntu bionic slideshow's left and right arrow buttons use the same transition" [High,Confirmed] https://launchpad.net/bugs/1761592
<tsimonq2> And, Kubuntu has a UX flaw.
<tsimonq2> (In the installer.)
-queuebot:#ubuntu-release- New sync: libheif (bionic-proposed/primary) [1.1.0-2]
<valorie> tsimonq2: you are writing this patch?
<valorie> if so, \o/
<tsimonq2> Yep.
-queuebot:#ubuntu-release- Unapproved: gcc-5-cross (bionic-proposed/universe) [32ubuntu1 => 33ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross [source] (bionic-proposed) [33ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gcc-5-cross-ports (bionic-proposed/universe) [18ubuntu2 => 21ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross-ports [sync] (bionic-proposed) [21ubuntu1]
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu1 => 10.1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: gcc-5-cross [ppc64el] (bionic-proposed/universe) [33ubuntu2] (no packageset)
<sforshee> slangasek, infinity: all bionic kernels have been respun and are building, I'll copy them out first thing in the morning
<slangasek> sforshee: ok, thanks for the update
<tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/ubiquity/remove-encrypt_home-qt/+merge/343759
<tsimonq2> slangasek: I also have a ubiquity-slideshow-ubuntu MP in progress.
<tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/ubiquity-slideshow-ubuntu/lp-1761592/+merge/343760
<tsimonq2> slangasek: Can I please get those two merged/sponsored/accepted before the release? :)
<valorie> would be nice to test 'em.....
<tsimonq2> I did.
<tsimonq2> :P
<valorie> well, I mean, to test the installer
<valorie> silly
<valorie> in the next respin
<tsimonq2> hehe
-queuebot:#ubuntu-release- Unapproved: node-ultron (bionic-proposed/universe) [1.1.1-1ubuntu1 => 1.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-ultron [sync] (bionic-proposed) [1.1.1-2]
<slangasek> tsimonq2: are the kubuntu slideshows translated?  isn't this going to regress localization for the release?
-queuebot:#ubuntu-release- Unapproved: case (bionic-proposed/universe) [1.5.3+dfsg-1 => 1.5.3+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted case [sync] (bionic-proposed) [1.5.3+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (bionic-proposed) [4.15.0-1005.5]
<tsimonq2> slangasek: Punctuation is trivial enough that the translated meanings of things shouldn't change.
<slangasek> tsimonq2: except it invalidates the mapping of source strings to translations; see any of po/kubuntu/*.po
<slangasek> none of the software knows that the translation is still valid because it's "just" a punctuation change
<tsimonq2> slangasek: OK; I'll revert.
 * tsimonq2 *really* wishes people in Kubuntu would have paid more close attention... oh well
<tsimonq2> slangasek: .
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (bionic-proposed) [4.15.0.1005.5]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (bionic-proposed/main) [136 => 137] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (bionic-proposed) [137]
<tsimonq2> Thanks.
<tsimonq2> slangasek: (If you're still around) what about Ubiquity? ;)
-queuebot:#ubuntu-release- New binary: gcc-5-cross [arm64] (bionic-proposed/universe) [33ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-5-cross [amd64] (bionic-proposed/universe) [33ubuntu2] (no packageset)
<tsimonq2> infinity, slangasek: Bug 1766047 seems to be an interesting one.
<ubot5`> bug 1766047 in ubiquity (Ubuntu) "Impossible to choose a language when booting in UEFI, as Ubiquity never opens due to problematic grub config" [Undecided,New] https://launchpad.net/bugs/1766047
-queuebot:#ubuntu-release- Unapproved: fslint (bionic-proposed/universe) [2.44-4 => 2.44-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fslint [source] (bionic-proposed) [2.44-4ubuntu1]
<cjwatson> infinity,slangasek: I've committed a ubiquity translations update to bzr.  Somebody else can upload if they think it appropriate ...
-queuebot:#ubuntu-release- Unapproved: linux-azure (bionic-proposed/main) [4.15.0-1004.4 => 4.15.0-1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (bionic-proposed/main) [4.15.0.1003.5 => 4.15.0.1005.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.18.19 => 4.15.0.19.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (bionic-proposed/main) [4.15.0-18.19 => 4.15.0-19.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (bionic-proposed/main) [4.15.0-1003.3 => 4.15.0-1005.5] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (bionic-proposed/universe) [4.15.0-1006.7 => 4.15.0-1009.10] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (bionic-proposed/universe) [4.15.0.1006.4 => 4.15.0.1009.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-aws (bionic-proposed/main) [4.15.0-1005.5 => 4.15.0-1006.6] (kernel, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (bionic-proposed/main) [4.15.0.1005.5 => 4.15.0.1006.6] (kernel, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (bionic-proposed/main) [4.15.0.1006.6 => 4.15.0.1007.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (bionic-proposed/main) [4.15.0-1006.6 => 4.15.0-1007.7] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (bionic-proposed/main) [4.15.0.1004.5 => 4.15.0.1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (bionic-proposed/main) [4.15.0-1004.4 => 4.15.0-1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-18.19+signed2 => 4.15.0-19.20] (core, kernel) (sync)
<sforshee> slangasek, infinity: kernel packages are now waiting in the unapproved queue
<sforshee> there's also some obselete ones in there from friday
-queuebot:#ubuntu-release- Unapproved: spectre-meltdown-checker (bionic-proposed/universe) [0.36-1 => 0.37-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spectre-meltdown-checker [sync] (bionic-proposed) [0.37-1]
-queuebot:#ubuntu-release- Unapproved: taskcoach (bionic-proposed/universe) [1.4.3-6 => 1.4.3-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted taskcoach [sync] (bionic-proposed) [1.4.3-6]
-queuebot:#ubuntu-release- Unapproved: openhackware (bionic-proposed/universe) [0.4.1+git-20140423.c559da7c-4 => 0.4.1+git-20140423.c559da7c-4.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openhackware [sync] (bionic-proposed) [0.4.1+git-20140423.c559da7c-4.1]
-queuebot:#ubuntu-release- Unapproved: ros-rviz (bionic-proposed/universe) [1.12.4+dfsg-2build3 => 1.12.4+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-rviz [sync] (bionic-proposed) [1.12.4+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: impressive (bionic-proposed/universe) [0.12.0-1ubuntu1 => 0.12.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted impressive [sync] (bionic-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- Unapproved: dhelp (bionic-proposed/universe) [0.6.24-0ubuntu1 => 0.6.25] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dhelp [sync] (bionic-proposed) [0.6.25]
-queuebot:#ubuntu-release- Unapproved: pandas (bionic-proposed/universe) [0.22.0-2ubuntu1 => 0.22.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pandas [sync] (bionic-proposed) [0.22.0-3]
-queuebot:#ubuntu-release- Unapproved: ohcount (bionic-proposed/universe) [3.1.0-1ubuntu1 => 3.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ohcount [sync] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-18.19+signed2 => 4.15.0-19.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-proposed) [4.15.0.19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: rejected linux-azure [sync] (bionic-proposed) [4.15.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-azure [sync] (bionic-proposed) [4.15.0.1007.7]
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-raspi2 [sync] (bionic-proposed) [4.15.0.1008.6]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-azure [sync] (bionic-proposed) [4.15.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: rejected linux-gcp [sync] (bionic-proposed) [4.15.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: rejected linux-raspi2 [sync] (bionic-proposed) [4.15.0-1008.9]
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-gcp [sync] (bionic-proposed) [4.15.0.1004.6]
-queuebot:#ubuntu-release- New: accepted gcc-5-cross [amd64] (bionic-proposed) [33ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-5-cross [ppc64el] (bionic-proposed) [33ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-5-cross [arm64] (bionic-proposed) [33ubuntu2]
-queuebot:#ubuntu-release- New: accepted libheif [sync] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New binary: libheif [amd64] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [ppc64el] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [i386] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [s390x] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [arm64] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [armhf] (bionic-proposed/none) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: buku (bionic-proposed/universe) [3.6-1 => 3.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted buku [sync] (bionic-proposed) [3.7-1]
-queuebot:#ubuntu-release- Unapproved: lensfun (bionic-proposed/universe) [0.3.2-3 => 0.3.2-4] (kubuntu) (sync)
-queuebot:#ubuntu-release- New: accepted libheif [amd64] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libheif [armhf] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libheif [ppc64el] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libheif [arm64] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libheif [s390x] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libheif [i386] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: minissdpd (bionic-proposed/universe) [1.5.20161216-2 => 1.5.20180223-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (bionic-proposed/universe) [1.2.15-1build1 => 1.2.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted minissdpd [sync] (bionic-proposed) [1.5.20180223-1]
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [sync] (bionic-proposed) [1.2.17-1]
-queuebot:#ubuntu-release- Unapproved: xmlbeans (bionic-proposed/universe) [2.6.0+dfsg-2 => 2.6.0+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xmlbeans [sync] (bionic-proposed) [2.6.0+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: lemonldap-ng (bionic-proposed/universe) [1.9.15-1 => 1.9.16-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lemonldap-ng [sync] (bionic-proposed) [1.9.16-2]
-queuebot:#ubuntu-release- Unapproved: libhtml-wikiconverter-markdown-perl (bionic-proposed/universe) [0.06-1 => 0.06-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libhtml-wikiconverter-markdown-perl [sync] (bionic-proposed) [0.06-2]
-queuebot:#ubuntu-release- Unapproved: libmarc-transform-perl (bionic-proposed/universe) [0.003006-1 => 0.003006-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libmarc-transform-perl [sync] (bionic-proposed) [0.003006-2]
-queuebot:#ubuntu-release- Unapproved: libdata-format-html-perl (bionic-proposed/universe) [0.5.1-1 => 0.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libdata-format-html-perl [sync] (bionic-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- Unapproved: libnet-dns-zonefile-fast-perl (bionic-proposed/universe) [1.24-2 => 1.24-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libxml-structured-perl (bionic-proposed/universe) [1.01-2 => 1.01-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libnet-dns-zonefile-fast-perl [sync] (bionic-proposed) [1.24-3]
-queuebot:#ubuntu-release- Unapproved: accepted libxml-structured-perl [sync] (bionic-proposed) [1.01-3]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-19.20] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-19.20] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: flightgear-data (bionic-proposed/universe) [1:2017.3.1+dfsg-1 => 1:2018.1.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flightgear-data [sync] (bionic-proposed) [1:2018.1.1+dfsg-1]
<tsimonq2> infinity, slangasek: Could I please get that Ubiquity MP reviewed?
-queuebot:#ubuntu-release- Unapproved: pidgin-gnome-keyring (bionic-proposed/universe) [2.0-1 => 2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libgstreamer1-perl (bionic-proposed/universe) [0.003-2 => 0.003-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libgstreamer1-perl [sync] (bionic-proposed) [0.003-3]
-queuebot:#ubuntu-release- Unapproved: accepted pidgin-gnome-keyring [sync] (bionic-proposed) [2.0-2]
-queuebot:#ubuntu-release- Unapproved: libmodule-install-extratests-perl (bionic-proposed/universe) [0.008-1 => 0.008-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libmodule-install-trustmetayml-perl (bionic-proposed/universe) [0.003-2 => 0.003-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libmoosex-mungehas-perl (bionic-proposed/universe) [0.007-2 => 0.007-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libmodule-install-extratests-perl [sync] (bionic-proposed) [0.008-2]
-queuebot:#ubuntu-release- Unapproved: accepted libmoosex-mungehas-perl [sync] (bionic-proposed) [0.007-3]
-queuebot:#ubuntu-release- Unapproved: accepted libmodule-install-trustmetayml-perl [sync] (bionic-proposed) [0.003-3]
-queuebot:#ubuntu-release- Unapproved: libnetapp-perl (bionic-proposed/universe) [500.002-1 => 500.002-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libnetapp-perl [sync] (bionic-proposed) [500.002-2]
-queuebot:#ubuntu-release- Unapproved: python-changelog (bionic-proposed/universe) [0.3.5-1 => 0.3.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-changelog [sync] (bionic-proposed) [0.3.5-2]
#ubuntu-release 2019-04-15
<infinity> xnox: Well, linux-image isn't noawait, but it also almost certainly shouldn't be.  There's also no way for it to be in a loop with things like bamfdaemon and desktop-file-utils, though.
<infinity> xnox: ca-certificates might be a candidate.
-queuebot:#ubuntu-release- Unapproved: networking-ovn (disco-proposed/universe) [6.0.0~rc1-0ubuntu1 => 6.0.0-0ubuntu1] (no packageset)
<jamespage> morning ubuntu-release - sorry missed the upload for ^^ networking-ovn last friday...
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu1 => 2:19.0.0-0ubuntu2] (openstack, ubuntu-server)
<jamespage> and ^^ nova upload resolves an issue with the automated backport to 18.04 as openssl 1.1.1 is now in bionic-proposed
<jamespage> if they could be reviewed and accepted much appreciated!
<jamespage> thanks!
<seb128> confirmed bug #1824672, unsure if you consider that as an issue to fix or just cosmetic though?
<ubot5`> bug 1824672 in syslinux (Ubuntu) "Disco "check disc for defects" appears not to function" [Undecided,New] https://launchpad.net/bugs/1824672
-queuebot:#ubuntu-release- Unapproved: sip4 (disco-proposed/universe) [4.19.15+dfsg-1 => 4.19.15+dfsg-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: pi-bluetooth (disco-proposed/universe) [0.1.10ubuntu3 => 0.1.10ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected pi-bluetooth [source] (disco-proposed) [0.1.10ubuntu5]
-queuebot:#ubuntu-release- Unapproved: pi-bluetooth (disco-proposed/universe) [0.1.10ubuntu3 => 0.1.10ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pi-bluetooth [source] (disco-proposed) [0.1.10ubuntu5]
<seb128> gstreamer upload to disco to fix the current autopkgtest issue with parlatype which blocked the update in disco-proposed in the queue
-queuebot:#ubuntu-release- Unapproved: gfxboot-theme-ubuntu (disco-proposed/main) [0.21.0 => 0.21.1] (core)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (disco-proposed/main) [1.15.90-1~sync1 => 1.15.90-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (disco-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sip4 [source] (disco-proposed) [4.19.15+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot-theme-ubuntu [source] (disco-proposed) [0.21.1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [source] (disco-proposed) [1.15.90-1ubuntu1]
<Laney> Looking into that syslinux thing a bit
<mvo> sil2100: hey, can we release the "shadow" SRUs? I looked at the autopkgtest issues listed and one lxd failure is a "test timeout" and the other lxd one I have no clue but I can't see anything useradd/userdel related in there. and mariadb always fails it seems. I can dig into the second lxd test some more if you want though
<seb128> Laney, thx
-queuebot:#ubuntu-release- Unapproved: rejected blis [sync] (disco-proposed) [0.5.2-6]
-queuebot:#ubuntu-release- Unapproved: accepted latte-dock [source] (disco-proposed) [0.8.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-django-mptt [sync] (disco-proposed) [0.8.7-1]
<Laney> going to have to learn how it works first though /o\
<infinity> seb128: Huzzah for the gstreamer 32-bit fix.
<seb128> :-)
<sil2100> mvo: hey! I can take a lookie now
<infinity> seb128: Did you want to replace the gst-* ~sync1 uploads with real syncs while you're at it?
<mvo> sil2100: thank you!
<seb128> infinity, I can do if you prefer, it's mostly cosmetic
<infinity> seb128: Yeah, not super picky, just makes me feel icky. :)
<seb128> if you are fine waiting for another round of rebuilds/autopkgtest for that stack to migrate
<seb128> k, let me sync then
<infinity> seb128: Figured maybe you'd want to since this is about to retrigger testing $world anyway.
<ginggs> i have received the reject mail for blis 0.5.2-6 yet, so don't i know the reason.  can i sync 0.5.2-7 ?
<ginggs> s/have/have not/
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (disco-proposed/universe) [1.15.90-1~sync1 => 1.15.90-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (disco-proposed/universe) [1.15.90-1~sync1 => 1.15.90-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (disco-proposed/main) [1.15.90-1~sync1 => 1.15.90-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (disco-proposed/universe) [1.15.90-1~sync1 => 1.15.90-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (disco-proposed/universe) [1.15.90-1~sync1 => 1.15.90-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (disco-proposed/universe) [1.15.90-1~sync1 => 1.15.90-1] (ubuntustudio) (sync)
<seb128> infinity, done ^
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (disco-proposed) [1.15.90-1]
<sil2100> mvo: ok, looking at the shadow SRU - I guess the main reason it wasn't released by anyone before is because it seems like the SRUs had some additional LP bugs attached that haven't been verified yet
<sil2100> Can you take a look at those and see if maybe you could verify them? Or, well, if maybe they're not really relevant
<sil2100> mvo: for instance:
<sil2100> mvo: xenial and bionic have LP: #984390 and xenial LP: #1495580
<ubot5`> Launchpad bug 984390 in shadow (Ubuntu Bionic) "$PATH is taken from login.defs not /etc/environment" [Medium,Fix committed] https://launchpad.net/bugs/984390
<ubot5`> Launchpad bug 1495580 in shadow (Ubuntu Xenial) "chfn needs to learn about the --extrausers argument and use libnss-extrausers files when set" [Medium,Fix committed] https://launchpad.net/bugs/1495580
<sil2100> Very old bugs
<sil2100> Guess maybe it's just some leftover in the changelog
-queuebot:#ubuntu-release- Unapproved: python-h5netcdf (disco-proposed/universe) [0.5.0-1 => 0.7.1-1] (no packageset) (sync)
<LocutusOfBorg> can we please kick llvm-toolchain-snapshot out from disco?
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-snapshot (disco-proposed/universe) [1:9~svn354105-1~exp1 => 1:9~svn358327-1~exp1] (no packageset) (sync)
<infinity> LocutusOfBorg: It's not in disco.
<infinity> LocutusOfBorg: So... Done?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1824784
<ubot5`> Ubuntu bug 1824784 in llvm-toolchain-snapshot (Ubuntu) "kick out from disco" [Undecided,New]
<LocutusOfBorg> infinity, disco-proposed with block-proposed tag
<infinity> LocutusOfBorg: Yes, it's in disco-proposed.  Not in disco.
<infinity> LocutusOfBorg: So... What's the problem?
<LocutusOfBorg> that its now an experimental only package
<infinity> It'll move from disco-proposed to ee-proposed.
<LocutusOfBorg> no, not autosyncd anymore
<infinity> Oh, if you mean remove it entirely, sure.  But then why did you just request a sync?
<infinity> Like, 3 minutes ago
<LocutusOfBorg> infinity, because in case you nack the removal, I'm planning to keep it up-to-date manually
-queuebot:#ubuntu-release- Unapproved: blis (disco-proposed/universe) [0.5.1-11 => 0.5.2-6] (no packageset) (sync)
<infinity> LocutusOfBorg: Honestly, I suspect there's value in having it in proposed and manually refreshes occasionally, to see that it continues to build/work/etc.
<ginggs> i think a dingo ate my blis reject mail
<infinity> LocutusOfBorg: But your call, if you're the one maintaining it.
<LocutusOfBorg> in case you want to keep it around a little bit more, I want my changes in the packaging to go in the archive, so I can see if the testsuite is fixed
<LocutusOfBorg> as you can see I committed fixes from the 8 branch in the snapshot one
<LocutusOfBorg> infinity, I'm not in a position to have a decision, you are archive admin, I prefer you to decide on it
<LocutusOfBorg> we moved to experimental, because the binary packages moving to snapshot to "stable+1" version, were always missing breaks+replaces
<infinity> LocutusOfBorg: If you're going to keep it updated, I'll keep it.  If you're not, I'll remove it.  Up to you.
<infinity> :P
<LocutusOfBorg> so people had pain in upgrading
<sil2100> valorie, acheronuk: hey! So I see someone reported LP: #1824669 for kubuntu, did you see something like that by any chance?
<ubot5`> Launchpad bug 1824669 in syslinux (Ubuntu) "Live boot fails legacy boot Kubuntu 19.04" [Undecided,New] https://launchpad.net/bugs/1824669
<LocutusOfBorg> I just want people to stop having upgrades issues, the same we faced in debian
<infinity> ginggs: The reject message was something like "an experimental package that is changing literally daily isn't an ideal candidate for a pre-release stable sync".
<LocutusOfBorg> also "please remove this binary from foo" often resulted in ftpmasters removing the binaries from other llvm-toolchain-N packages
<LocutusOfBorg> so, I would prefer to stop having it around but really, if you think it is worth the effort, I can still sync it and check if it works or not
<ginggs> infinity: ack, debian maintainer told me yesterday 0.5.2-6 is the one we want, so i tested autopkgtests in my PPA an syc'd
<infinity> LocutusOfBorg: If you prefer to remove it, I'll remove it.  I don't want unmaintained packages hanging around for no reason, so if there's no value to you, meh.
<LocutusOfBorg> (I know end users shouldn't use devel-proposed at all, but backports are there...
<infinity> ginggs: And then he uploaded another one. :P
<LocutusOfBorg> I would like to drop it, if possible, I think also it would be easier for archive admins
<infinity> LocutusOfBorg: Kay.  Removing then.
<ginggs> infinity: but now he uploaded 0.5.2-7 this morning, so up to you if you want to let 0.5.2-6 through now
<LocutusOfBorg> because the new binaries often builds only in a subset of archs, and meh if I sync manually your automatic minions don't work
<LocutusOfBorg> I hope to don't make you angry if in the future we change idea!
<infinity> LocutusOfBorg: I'm always angry. :)
<infinity> LocutusOfBorg: (removed)
<LocutusOfBorg> <3 lovely thanks
<ginggs> infinity: it should migrate, and then i'll check with him again before release and do another sync if needed
<sil2100> valorie, acheronuk: oh, ok, I guess LP: #1824670 is related and duflu did take a look at it
<ubot5`> Launchpad bug 1824670 in nvidia-graphics-drivers-340 (Ubuntu) "Boot to black screen after Kubuntu 19.04 install" [Undecided,New] https://launchpad.net/bugs/1824670
<infinity> ginggs: If the Debian maintainer has higher confidence in experimental than in what we're currently shipping, that's probably a good enough argument, though we should likely take -7
<infinity> Since it looks like it has obvious bugfixes over -6
<ginggs> infinity: ack, please reject -6 (again) and i'll sync -7 when launchpad picks it up
-queuebot:#ubuntu-release- Unapproved: rejected blis [sync] (disco-proposed) [0.5.2-6]
-queuebot:#ubuntu-release- Unapproved: rejected llvm-toolchain-snapshot [sync] (disco-proposed) [1:9~svn358327-1~exp1]
-queuebot:#ubuntu-release- Unapproved: accepted python-h5netcdf [sync] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- Unapproved: puma (disco-proposed/universe) [3.12.0-2 => 3.12.0-2ubuntu1] (no packageset)
<LocutusOfBorg> infinity, ^^ I really want it to move forward, I don't know which network configuration your infrastructure has, but local tests pass, as well as in Debian, and DebOMatic... I hope we can wait for some new release, and in the meanwhile let me ask upstream (the test is ignored already on windows and somewhere else, like appveyor CI)
<mvo> sil2100: thanks, let me double check this (and sorry for the slow reply, was in a meeting)
<LocutusOfBorg> also, there is a new puma 3.12.1 that has changes in that exact particular test... interesting
<sil2100> mvo: infinity had a point with one thing - at least one of those bugs could be very suspicious if it's really fixed, so yeah, would be good to check that
<sil2100> Wonder why it was included in the .changes file
<sil2100> Oh, infinity is right, the six-digit one is *actually* explicitly in the changelog ;p (/me didn't look at that yet)
 * cjwatson eyes https://bugs.debian.org/926735 and wonders if we want that in disco
<ubot5`> Debian bug 926735 in libparted2 "Include upstream patch for extended partition size" [Serious,Open]
<cjwatson> Trying to construct a test case now ...
 * infinity eyes cjwatson and wonders if we want him on distro.
<cjwatson> :P
<infinity> We have a pretty solid testcase.
<LocutusOfBorg> "I want cjwatson on disco" so I can pull-lp-source him! :D
<LocutusOfBorg> everybody should have a local cjwatson instance :)
<cjwatson> I mean it'd be handy to be cloned
<cjwatson> Don't want my clones to have more fun than I do though
<LocutusOfBorg> you can pthread_join your forks eventually...
<cjwatson> All gets a bit Greg Egan
<LocutusOfBorg> but OTOH I don't want zombie cjwatson around... :D
<acheronuk> sil2100: I tried a 'legacy' live usb boot on a Dell Inspiron 15 5578 laptop last night to check, and all was fine. That laptop is wuite new, and  Darin's (bug reporter) are about 2009 with Nvidia (I have Intel) so maybe not a fair comparison
<acheronuk> sil2100: oh, I see your later comment. right
-queuebot:#ubuntu-release- Unapproved: multipath-tools (disco-proposed/main) [0.7.4-2ubuntu7 => 0.7.4-2ubuntu8] (core)
<xnox> infinity, https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=multipath-tools http://launchpadlibrarian.net/419367051/multipath-tools_0.7.4-2ubuntu7_0.7.4-2ubuntu8.diff.gz
-queuebot:#ubuntu-release- Unapproved: accepted puma [source] (disco-proposed) [3.12.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (disco-proposed) [0.7.4-2ubuntu8]
<sil2100> mvo: how does the ddtp-ubuntu stuff work? I mean, I guess we'd normally like that updated, I see you did an import from Debian into ddtp-pot-disco but the translations in launchpad don't seem to exist for disco?
<sil2100> mvo: anyway, it's probably not a priority to get that updated
<sil2100> mvo: was just wondering if that's anything that you're working on already?
<sil2100> For cosmic I guess we skipped the update?
<sil2100> acheronuk: yeah, in that case I guess this should also be an issue for Ubuntu, right?
<mvo> sil2100: I updated it for disco but its stuck apparently in LP approval of the templates
<mvo> sil2100: https://translations.launchpad.net/ddtp-ubuntu/disco/+imports
<mvo> sil2100: I'm not sure why this no longer gets approved, either in the "old" days people looked at this and don't anymore or a script has changed
<mvo> sil2100: with that approved I think I could upload new translations for disco
<infinity> tjaalton: Have you had more time to think about the nouveau modeset madness?
<sil2100> mvo: hm, I wonder what happened then, I guess I don't have the powers to approve that - but probably Gunnar has, let me reach out to him
<sil2100> mvo: anyway, not a top priority, but certainly would be nice if your work wouldn't go to waste just because of that
<infinity> tjaalton: It occurred to me just now that this means all nvidia systems will also be running the installer at 640x480, which is really suboptimal.
<mvo> sil2100: let me know if there is a way to automate this
<mvo> sil2100: please ping me once this is unblocked, the amount of work to upload the update is tiny
<acheronuk> sil2100: you would think so, be Darin said the Ubuntu iso booted ok. I'm afraid I don't have hardware I can reproduce this on, and not much time anyway today
<acheronuk> *but Darin
<sil2100> mvo: thank you!
 * acheronuk deliberately NEVER EVER buys laptops with Nvidia ;)
<tjaalton> infinity: on uefi systems it'll use efifb with the native resolution..
<infinity> tjaalton: EFI systems are still relatively newish.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190124+dfsg1-0ubuntu1 => 20190315-0ubuntu1] (core, ubuntu-cloud)
<tjaalton> sure
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (disco-proposed/restricted) [5.0.0-10.11 => 5.0.0-11.12] (kernel)
<tjaalton> infinity: a more refined patch would take more time, so if you prefer to revert for disco and rethink it for EE then that's fine
<sil2100> acheronuk: ok, that's a bit weird then!
<sil2100> ;)
<sil2100> But yeah, if only his laptop is affected (and only for Kubuntu), I'd say the importance of the bug has lowered a bit
<sil2100> I was worried it's an indication of something bigger
<sil2100> Wonder what's going on there
-queuebot:#ubuntu-release- Unapproved: rejected linux-restricted-modules [source] (disco-proposed) [5.0.0-11.12]
<infinity> tjaalton: Has the nouveau/firmware situation gotten significantly worse since cocmis?
<infinity> tjaalton: cosmic, even.
<infinity> tjaalton: Cause I'd prefer not to regress in the name of progression.
<tjaalton> infinity: i'm not sure, upstream said it's not the first tume
<infinity> tjaalton: I guess what I'm driving at is that if cosmic and bionic(+hwe) have the same issues you were trying to work around in disco, you're causing a regression to fix something that isn't.
-queuebot:#ubuntu-release- Unapproved: blis (disco-proposed/universe) [0.5.1-11 => 0.5.2-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted blis [sync] (disco-proposed) [0.5.2-7]
<LocutusOfBorg> rails migrated!
<LocutusOfBorg> I think we now need a rails that disables bootsnap only on armhf instead of everywhere...
-queuebot:#ubuntu-release- Unapproved: ruby-mixlib-install (disco-proposed/universe) [3.11.7-1 => 3.11.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mozjs60 (disco-proposed/main) [60.2.3-2build1 => 60.2.3-3] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mozjs60 [sync] (disco-proposed) [60.2.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-mixlib-install [source] (disco-proposed) [3.11.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (disco-proposed/restricted) [5.0.0-10.11 => 5.0.0-11.12] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.2-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: diaspora (disco-proposed/universe) [0.7.9.0+dfsg-4 => 0.7.9.0+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.20 => 237-3ubuntu10.21] (core)
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.8 => 4.0.0-1ubuntu8.9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [source] (disco-proposed) [5.0.0-11.12]
<infinity> LocutusOfBorg: That diaspora change looks wrong to me.
<infinity> LocutusOfBorg: ruby-handlebars-assets has an epoch in both Ubuntu and Debian, why would you remove it in the version check?
<infinity> LocutusOfBorg: The problem you're seeing in britney isn't the version, it's a component mismatch.
<infinity> ruby-handlebars-assets moved from contrib to main in Debian and we didn't follow suit (yet).
-queuebot:#ubuntu-release- New binary: linux-restricted-modules [amd64] (disco-proposed/restricted) [5.0.0-11.12] (kernel)
-queuebot:#ubuntu-release- Unapproved: rejected diaspora [source] (disco-proposed) [0.7.9.0+dfsg-4ubuntu1]
<infinity> LocutusOfBorg: Fixing.
-queuebot:#ubuntu-release- Unapproved: ruby-oauth2 (disco-proposed/universe) [1.4.1-1 => 1.4.1-1ubuntu1] (no packageset)
<LocutusOfBorg> sorry infinity I obviously made a mistake
<LocutusOfBorg> because I saw "hey diaspora is not main, how can be a mismatch"
<LocutusOfBorg> I didn't think about multiverse, you are right
<LocutusOfBorg> sorry
<LocutusOfBorg> ruby-oauth2 looks more legit
<infinity> LocutusOfBorg: All good.  Should be fixed in the next publisher run.
<LocutusOfBorg> lovely! I don't think it will migrate TBH
<LocutusOfBorg> but I want autopkgtestsuite results...
-queuebot:#ubuntu-release- Unapproved: accepted ruby-oauth2 [source] (disco-proposed) [1.4.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules [amd64] (disco-proposed) [5.0.0-11.12]
-queuebot:#ubuntu-release- Packageset: 44 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: ddtp-translations (disco-proposed/universe) [20180103.1 => 20190415.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ruby-concurrent (disco-proposed/universe) [1.0.5-2 => 1.0.5-2ubuntu1] (no packageset)
<LocutusOfBorg> ^^ that one is finally fixed yay
-queuebot:#ubuntu-release- Unapproved: pi-bluetooth (disco-proposed/multiverse) [0.1.10ubuntu5 => 0.1.10ubuntu6] (no packageset)
<ginggs> LocutusOfBorg: good work! please send that fix to debian bug #926782
<ubot5`> Debian bug 926782 in src:ruby-concurrent "ruby-concurrent: autopkgtest needs update" [Normal,Open] http://bugs.debian.org/926782
-queuebot:#ubuntu-release- Unapproved: accepted pi-bluetooth [source] (disco-proposed) [0.1.10ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-concurrent [source] (disco-proposed) [1.0.5-2ubuntu1]
<LocutusOfBorg> ginggs, already fixed an uploaded in debian too
-queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (disco-proposed) [20190415.1]
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu4 => 0.154.1ubuntu5] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (disco-proposed/universe) [0.35 => 0.36] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (disco-proposed) [0.36]
-queuebot:#ubuntu-release- Unapproved: libpng1.6 (disco-proposed/main) [1.6.36-6 => 1.6.37-1~exp2] (core) (sync)
<LocutusOfBorg> infinity, missing build on ppc64el: os-autoinst (from 4.5.1527308405.8b586d5-2)
<LocutusOfBorg> missing build on s390x: os-autoinst (from 4.5.1527308405.8b586d5-2)
<LocutusOfBorg> please can you do it? removed on debian, decruft NBS proposed
<vorlon> infinity, LocutusOfBorg: looking
<vorlon> infinity, LocutusOfBorg: done
<LocutusOfBorg> <3
<bdmurray> vorlon: I've verified bug 1822886 if you also feel it is worth releasing early.
<ubot5`> bug 1822886 in ubuntu-release-upgrader (Ubuntu Cosmic) "universe missing after bionic->cosmic do-release-upgrade" [Critical,Fix committed] https://launchpad.net/bugs/1822886
<LocutusOfBorg> last fix from my side for today
<LocutusOfBorg> vala-panel is ok
-queuebot:#ubuntu-release- Unapproved: vala-panel (disco-proposed/universe) [0.4.87+dfsg1-1 => 0.4.87+dfsg1-1ubuntu1] (ubuntu-mate)
<infinity> LocutusOfBorg: That patch could use a link to the upstream commit yuo took "part" of...
<infinity> LocutusOfBorg: And why on earth are you trying to sync libpng from experimental?
-queuebot:#ubuntu-release- Unapproved: rejected libpng1.6 [sync] (disco-proposed) [1.6.37-1~exp2]
<vorlon> bdmurray: released, thanks
<infinity> vorlon: What exactly did you do above to os-autoinst?
<infinity> (he asked, after removing the NBS binaries that weren't removed)
<LocutusOfBorg> infinity, because of arm* fixes
<infinity> Argh, and why did the VPN section of my panel disappear again?
<LocutusOfBorg> infinity, I'm the debian libpng maintainer...
<LocutusOfBorg> and I uploaded to experimental because of freeze, not because of instability
<infinity> LocutusOfBorg: That's nice.  We're in a hard freeze, and libpng is on every image.
<LocutusOfBorg> actually mostly all of the arm improvements are already in the current 1.6.36-6 version, but I would like to avoid having to maintain all the patches there, the new release included them all with some additional fixes
<LocutusOfBorg> but of course I see your point
<LocutusOfBorg> and you are RT, so I'll be happy whatever decision you make :)
<infinity> I already made it. :)
<LocutusOfBorg> :)
<LocutusOfBorg> btw I vala-panel is now updated, we should probably drop the file at all, but I prefer to keep changes minimal
-queuebot:#ubuntu-release- Unapproved: vala-panel (disco-proposed/universe) [0.4.87+dfsg1-1 => 0.4.87+dfsg1-1ubuntu1] (ubuntu-mate)
<vorlon> infinity: apparently what I did was typo '-a s390x' as '-b s390x' <shrug>
<infinity> Neat.
<LocutusOfBorg> pick the one you prefer infinity :) the last upload might even be better
-queuebot:#ubuntu-release- Unapproved: vala-panel (disco-proposed/universe) [0.4.87+dfsg1-1 => 0.4.87+dfsg1-1ubuntu1] (ubuntu-mate)
<infinity> LocutusOfBorg: Why not the whole commit, that actually deletes the file?
<infinity> I mean, in spirit, as it may not apply cleanly.  But you can do the 1-liner to CMakeLists, rm the file, then dpkg-source --commit.
<LocutusOfBorg> infinity, that is the second upload
<LocutusOfBorg> the reason for not deleting the file is that dpkg-source didn't pick deleted files...
<LocutusOfBorg> in any case this is already a commit part of 0.4.88 released version, so it will go away on next sync
<LocutusOfBorg> infinity, ^^ now you have the three flavours, the one with the function removed, the one with the cmake one-line and the one with also the file removed
-queuebot:#ubuntu-release- Unapproved: vala-panel (disco-proposed/universe) [0.4.87+dfsg1-1 => 0.4.87+dfsg1-1ubuntu1] (ubuntu-mate)
<LocutusOfBorg> next time I'll leave ricotz and seb128 the fixup of the sync from debian experimental :)
-queuebot:#ubuntu-release- Unapproved: mokutil (disco-proposed/main) [0.3.0+1538710437.fb6250f-0ubuntu2 => 0.3.0+1538710437.fb6250f-1] (core) (sync)
<vorlon> LocutusOfBorg: ^^ seriously?
<vorlon> we're in final freeze. *critical fixes only*, not "sync new upstream versions to be in sync"
-queuebot:#ubuntu-release- Unapproved: rejected mokutil [sync] (disco-proposed) [0.3.0+1538710437.fb6250f-1]
<vorlon> not even new upstream version; but regardless, no
<cyphermox> I may have a fix for casper in a minute; provided I manage to master this test iso properly
<cyphermox> (integrity check)
<tsimonq2> infinity, vorlon: How badly would the Release Team hate me if I wanted to upload a new Calamares module, assuming I take full responsibility for testing it?
<xnox> slitghtly concerts that lxqt-globalkeys took out 6 builders for 1h+ now, when normally the build takes just 2minutes.
<xnox> *concerned
<xnox> either the cloud is dead, or the lxqt-globalkeys is blocking 12 buildings in a hung state.
<xnox> *builders
<xnox> no, not 12 builders, 24 builders.
<xnox> tsimonq2, what's up with lxqt-globalkeys? do you have access to lubuntu ci? maybe we should cancel the builds, and retry them?
<xnox> https://launchpad.net/builders -> ctrl+f for lxqt-globalkeys
<xnox> i have rights to cancel these too.... it seems odd how they are hung.
<tsimonq2> O_o
<xnox> hm cancelling them doesn't help, as they get stuck in "cancelling" state then.
<xnox> launchpad is probably broken.
<tsimonq2> Yeah, it's that.
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been marked as ready
<Eickmeyer> BOOM!
<Eickmeyer> No blockers. :)
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.13.2-9ubuntu5 => 2.13.2-9ubuntu6] (core)
<fossfreedom> Eickmeyer, bit early? thought there is at least one more spin coming
<tsimonq2> There's Always one more spin coming.
<tsimonq2> Eickmeyer: I don't think infinity has updated base-files yet.
<tsimonq2> (At minimum.)
<Eickmeyer> Ohhhh.... :/
<Eickmeyer> *unmarks*
<tsimonq2> Eickmeyer: No need.
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been updated (20190413.1)
<Eickmeyer> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- Unapproved: rejected vala-panel [source] (disco-proposed) [0.4.87+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected vala-panel [source] (disco-proposed) [0.4.87+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected vala-panel [source] (disco-proposed) [0.4.87+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vala-panel [source] (disco-proposed) [0.4.87+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected apparmor [source] (disco-proposed) [2.13.2-9ubuntu6]
<infinity> Well, that apparmor didn't last long in the queue...
<infinity> Didn't even get to review it.
<jdstrand> sorry
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.13.2-9ubuntu5 => 2.13.2-9ubuntu6] (core)
<jdstrand> I wanted a quick patch comment. the new one is there
<infinity> Does this fix the issue you were discussing earlier?
<jdstrand> this isn't install critical, so sru is fine, but if you want to take it, it is super small
<jdstrand> it fixes part of it. I say part because this seems like twp parts
<jdstrand> there is a shiftfs interaction with apparmor that jjohansen needs to look at
<jdstrand> I fixed the easy part :)
<jdstrand> the details are in the bug
<jdstrand> if lxd didn't use shftfs or shiftfs was backed out, this would be good enough
<jdstrand> I'm not advocating for that per se, but mention it since that might be something you want to consider
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu6]
<jdstrand> thanks
<tsimonq2> xnox: (Technically, you also have access to the Lubuntu CI, being an Ubuntu Core Developer that is indirectly a Lubuntu Developer: https://ci.lubuntu.me/ )
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu3 => 1.10ubuntu4] (core)
<rbalint> infinity, bdmurray just marked one of the bugs rls-dd-incoming, and those issues are seen frequently on errors.ubuntu.com
<rbalint> full autopkgtest is still running locally, the changes are on review at https://github.com/mvo5/unattended-upgrades/pulls
<rbalint> u-u should run fine on default configs, thus it may be enough to release it as a 0-day sru, but wanted to show the most important patches
<infinity> rbalint: Conceptually, I don't have issues with a u-u upload right now while I'm working on migrating a kernel anyway.
<infinity> vorlon: I'm perhaps a bit too sleepy to give a good review to that u-u, could you give it some love?
<vorlon> ok
<rbalint> infinity, i'm too sleepy as well, thus i would not mind waiting till tomorrow or at least a review
<rbalint> infinity, but i can fix anything tomorrow that were not caught by the review
-queuebot:#ubuntu-release- Unapproved: linux (disco-proposed/main) [5.0.0-11.12 => 5.0.0-13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (disco-proposed/main) [5.0.0-11.12 => 5.0.0-13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: parted (disco-proposed/main) [3.2-24build1 => 3.2-25] (core) (sync)
<rbalint>  infinity, vorlon u-u autopkgtest passed locally in disco
<rbalint> running another in bionic
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu4]
<vorlon> infinity, rbalint: accepted ^^
-queuebot:#ubuntu-release- Unapproved: linux-meta (disco-proposed/main) [5.0.0.11.12 => 5.0.0.13.14] (core, kernel) (sync)
<rbalint> vorlon, thanks! i'll keep the remaining patches needed in stable releases for the 0-day sru
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (disco-proposed) [5.0.0.13.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- Unapproved: accepted parted [sync] (disco-proposed) [3.2-25]
-queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.403 => 1.404] (desktop-core, ubuntu-server)
<vorlon> LocutusOfBorg: so you're disabling tests in puma when you cannot account for what the failure means?
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (disco-proposed) [1.404]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-aws (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (disco-proposed/main) [5.0.0.1003.3 => 5.0.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (disco-proposed/main) [5.0.0.1003.3 => 5.0.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (disco-proposed/restricted) [5.0.0-11.12 => 5.0.0-13.14] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-azure (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (disco-proposed/main) [5.0.0.1003.3 => 5.0.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (disco-proposed/main) [5.0.0.1003.3 => 5.0.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-13.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (disco-proposed) [5.0.0.1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (disco-proposed) [5.0.0.1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (disco-proposed) [5.0.0.1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (disco-proposed) [5.0.0.1004.4]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-azure [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-gcp [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: linux-gcp (disco-proposed/main) [5.0.0-1003.3 => 5.0.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat9 (cosmic-proposed/universe) [9.0.16-3~18.04 => 9.0.16-3~18.10] (no packageset) (sync)
<tdaitx> sbeattie: vorlon: ^ tomcat9 build is finished now, I requested the binary copy
<sbeattie> thanks
<vorlon> tdaitx: accepted
-queuebot:#ubuntu-release- Unapproved: accepted tomcat9 [sync] (cosmic-proposed) [9.0.16-3~18.10]
#ubuntu-release 2019-04-16
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1004.4]
<infinity> Okay, the way things are looking, I think I'll just respin first thing in the morning instead of worrying about doing a hand-off, etc.
<infinity> Cause it'll be past NA bedtime by the time all this stuff is happy and moving.
-queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu569 => 20101020ubuntu570] (core)
-queuebot:#ubuntu-release- Unapproved: rejected linux-gcp [sync] (disco-proposed) [5.0.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (disco-proposed) [20101020ubuntu570]
-queuebot:#ubuntu-release- Unapproved: thunar (disco-proposed/universe) [1.8.4-1 => 1.8.4-1ubuntu1] (mythbuntu, ubuntustudio, xubuntu)
<bluesabre> infinity: can you go ahead and approve the above thunar upload so it makes it into tomorrow's respin? :)
<bluesabre> Including the (please) I forgot just now
<infinity> I'll leave that to vorlon.
 * infinity sleeps for a few hours.
<vorlon> looking
<bluesabre> infinity, vorlon, much appreciated :)
<vorlon> bluesabre: rather large patch, and the header says it's 1/3. how sure are you this fixes the issue?
<vorlon> oh, it's 3 patches serialized in 1 file  :P
<bluesabre> vorlon: yes, the patch submitted upstream was a 3-parter (parts 2 and 3 are in the same patch), https://bugzilla.xfce.org/attachment.cgi?id=8408
<bluesabre> :)
<vorlon> bluesabre: so you've already tested this locally and confirmed it fixes?
<bluesabre> as for how sure, I was 100% able to reproduce the issue before (was driving me nuts), and can no longer reproduce now
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (disco-proposed) [1.8.4-1ubuntu1]
<bluesabre> vorlon: thanks a bunch!
<mwhudson> infinity: about to release the hopefuly final subiquity to stable btw
-queuebot:#ubuntu-release- Unapproved: runc (cosmic-proposed/universe) [1.0.0~rc4+dfsg1-6ubuntu0.18.10.1 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Disco Final] has been updated (20101020ubuntu570)
-queuebot:#ubuntu-release- Unapproved: runc (bionic-proposed/universe) [1.0.0~rc4+dfsg1-6ubuntu0.18.04.1 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.2 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset)
<mwhudson> blugh
<mwhudson> can someon reject those containerd uploads? forgot something
-queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: containerd (xenial-proposed/universe) [0.2.5-0ubuntu1~16.04.1 => 1.2.6-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [18.09.2-0ubuntu1~18.10.1 => 18.09.5-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.09.2-0ubuntu1~18.04.1 => 18.09.5-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [18.09.2-0ubuntu1~16.04.1 => 18.09.5-0ubuntu1~16.04.1] (no packageset)
<mwhudson> infinity: released subiquity to stable now
<mwhudson> should be ready for any iso testing people still have time for ...
<teward> mwhudson: does that happen to contain a fix for 1821966 and search domains?
<teward> just curious :P
<mwhudson> teward: yes
<mwhudson> teward: although you should test tomorrow's daily to make sure!
<teward> well then I'll test tomorrow's daily :P
<mwhudson> tia!
<teward> mwhudson: any idea when the dailies generate?
<teward> so I know when tomorrow to test :p
<acheronuk> teward: disco dailies are turned off AFAIK
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (disco-proposed/main) [64ubuntu6 => 64ubuntu7] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset)
<LocutusOfBorg> doko, ^^ I tried to fix your kopanocore upload, but I'm not really sure about the fix...
<LocutusOfBorg> maybe the fix should go in src:apport?
<LocutusOfBorg> maybe juliank ^^ ? does apt need to read cputable?
<juliank> LocutusOfBorg: yes, it does
<LocutusOfBorg> does it have an apport profile?
<LocutusOfBorg> I don't get why kopanocore fails testsuite in that way
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190305_224317_8d7c5@/log.gz
<juliank> I don't think it does
<LocutusOfBorg> kopanocore fails because of that file being non accessable, the obviously fix is to add to the profile (looks like working on DebOMatic, but maybe that machine has no apport enforcement, not sure)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu4 => 1.10ubuntu5] (core)
<LocutusOfBorg> and in any case kopanocore doesn't directly access that file, so it might be a dpkg/apt bug hidden somewhere?
<rbalint> ^one more fix for the errors seen in disco and also fixing slowness in bionic
<juliank> LocutusOfBorg: I'm not sure why it's not accessible
<juliank> dpkg ships that file, and apt requires it being present
<rbalint> upstreadm review: https://github.com/mvo5/unattended-upgrades/pull/190
<gitbot> mvo5 issue (Pull request) 190 in unattended-upgrades "Adjust only transitive dependencies in the fallback" [Open]
<rbalint> juliank, i really want to do pinning only and not adjustments in u-u
<juliank> rbalint: well, then, do it I guess - I think the infra is there now, although a bit hacky
<LocutusOfBorg> AppArmor parser error for /etc/apparmor.d/usr.sbin.kopano-search in /etc/apparmor.d/usr.sbin.kopano-search at line 39: missing an end of line character? (entry: /etc/ssl/openssl.cnf)
<LocutusOfBorg> DAMN
<juliank> ^fun
<rbalint> juliank, also i measured u-u to be much slower
<rbalint> juliank, needs to move to low level apt api first, it seems
<LocutusOfBorg> devil is hidden in the details
 * LocutusOfBorg grabs coffee and prepares a big hammer
<juliank> rbalint: You should add an action group around the adjustment loop I think
<LocutusOfBorg> +  signal (send) set=("term") peer=unconfined,
<LocutusOfBorg> what is the problem on this?
<juliank> rbalint: because this is wreaking havoc in recalculating installability each time you adjust one
<LocutusOfBorg> oh no
<rbalint> juliank, the speed is not terrible and actiongroups caused problems with cache clear, thus i don't want to risk that now
<juliank> Well, yes
<rbalint> juliank, the side effects of action groups are not crystal clear
-queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset)
<juliank> Well, they are perfectly clear - the action group delays recalculating stuff in the dep cache
<juliank> Obviously, you can't re-initialize the depcache while you're holding an action group
<juliank> s/Obviously/It follows that/
<juliank> action groups should provide a drastic performance increase
<juliank> switching to low-level should offer basically no performance
<juliank> Probably should raise an exception when clearing a cache that has an action group
<juliank> rbalint: Or to be more clear, action groups, when released, re-calculate which packages are autoremovable and which are not
<juliank> rbalint: So, if you re-initialize the cache while holding the action group, you'll end up with wrong autoremovable states
<juliank> rbalint: But yes it will require some restructuring of u-u to work with that model
<juliank> though i do not understand _how_ it delays things
<juliank> Ah I see
<juliank> The code is super odd
<juliank> e.g. MarkInstall() keeps an ActionGroup during its call
<juliank> so, if there is no other action group, it will be released at the end
<juliank> same for set candidate version
<juliank> rbalint: What this means is that each time you adjust the candidate, or mark something for install/remove, apt traverses the entire set of packages reachable from the installed ones and marks them as reachable
<juliank> which is, um, slow
<rbalint> juliank, yes i can see that
<rbalint> juliank, and rather than trying to sped this up a bit i'd like to drop adjustments and use pinning
<juliank> But we can fix apt, so that Init() works with an actiongroup hold actually works well, then you can clear the cache as often as you like
<rbalint> that would also be wonderful and speed up other clients as well
<juliank> rbalint: oh, but you still have to release the action group before determining which packages are auto-removable
<juliank> But I'm wondering if python-apt could not automatically manage an action group for you
<juliank> basically, keep an action group until you are looking at autoremovable states
<rbalint> infinity u-u 1.10ubuntu5 autopkg passed locally in bionic vm
<juliank> it's a bit fragile if actiongroup behavior changes in the future
<rbalint> how about not changing it and seeing how u-u performs using pinning and low level apt api?
<rbalint> maybe automatic action group would just slow it down
-queuebot:#ubuntu-release- Unapproved: base-files (disco-proposed/main) [10.1ubuntu8 => 10.1ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2]
<juliank> rbalint: I just thought I'd have apt set a dirty bit instead when it makes the "autoremovable" cache dirty, rather than recalculating right then; and then when requesting autoremovable state, recalc it if it's dirty.
<juliank> should be a nice gain for most users and avoid the need for action groups
<rbalint> juliank, it would help a lot if there were info on action to not use https://apt-team.pages.debian.net/python-apt/library/apt.cache.html?highlight=actiongroup#apt.cache.Cache.actiongroup
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [sync] (disco-proposed) [64ubuntu7]
<infinity> LocutusOfBorg: That kapanocore change doesn't look sane to me.  At least, not from my reading of other apparmor profiles over the years.
<rbalint> juliank, ok, but can't i read autoremovable state of packages withot noticing the dirtyness?
<juliank> rbalint: Well, I'd replace the fields in apt's cache with accessor methods
<rbalint> juliank, does not sound like a speedup...
<juliank> that do bool Garbage() { if (dirty) MarkAndSweep(); return Garbage; }
<juliank> rbalint: It certainly is not a speedup for those who use action groups now, yes
<infinity> juliank: Can you review this u-u in the queue and give me a thumbs up or down?  It's a bit long for my python-hating brain this morning.
<juliank> It's also shorter than it looks because it's the same file two times
<juliank> infinity: I did look at it yesterday in github, and it looks ok
<juliank> -            marking_succeeded = self.call_checked(function, pkg, **kwargs)
<juliank> +            self.call_checked(function, pkg, **kwargs)
<juliank> is the only thing I'm confused about
<infinity> "it looks okay" shouldn't be followed by "but..." on another line. :P
<rbalint> juliank, i made minor edits
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu5]
<infinity> (already accepted it)
<infinity> But please, talk amongst yourselves, and if you have something better to upload, I'd like it in ~30m.
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (disco-proposed) [10.1ubuntu9]
<juliank> infinity: Well, it's OK, it just looks slightly odd, but the variable is not used afterwards, so it's technically fine
<rbalint> juliank, yep, it was an obsolete assignment
<LocutusOfBorg> infinity, you mean the first or the second upload?
<infinity> LocutusOfBorg: The seonc.
<infinity> second, too.
<infinity> -  /etc/ssl/openssl.cnf r,
<infinity> +  /etc/ssl/openssl.cnf r
<LocutusOfBorg> did you see the diff between -1 and -2 uploads?
<LocutusOfBorg> I mean the good and the bad one
<LocutusOfBorg> http://launchpadlibrarian.net/412007799/kopanocore_8.7.0-1build1_8.7.0-2.diff.gz
<infinity> .... and?
<infinity> -2 looks correct to me.
<LocutusOfBorg> :( so I don't know...
<LocutusOfBorg> LocutusOfBorg: ^^ seriously?	20:04
<LocutusOfBorg> vorlon	we're in final freeze. *critical fixes only*, not "sync new upstream versions to be in sync"
<LocutusOfBorg> ^^ vorlon I miss the context, I fixed other people syncs from experimental I didn't sync by myself from there
<LocutusOfBorg> and if you mean mokutils a) its mostly a no change sync (modulo some maintainer field and vcs fields updated), and it is from unstable, and blame tsimonq2 for this :)
<LocutusOfBorg> if you mean vala, I don't sync vala, for sure not from experimental :)
 * LocutusOfBorg would like to forbid experimental syncs
<infinity> 14:05 -queuebot:#ubuntu-release- Unapproved: rejected mokutil [sync] (disco-proposed)
<infinity>           [0.3.0+1538710437.fb6250f-1]
<infinity> 14:06 < vorlon> not even new upstream version; but regardless, no
<infinity> LocutusOfBorg: ^ That was the context.
<LocutusOfBorg> well, its a cosmetic change I sponsored for tsimonq2, in any case I don't think the end user will care about a wrong VCS field...
<infinity> LocutusOfBorg: And how does one blame someone else for your upload?
<Laney> Perhaps don't upload cosmetic changes in final freeze.
<LocutusOfBorg> yep sure, isn't VCS fields something end users care about?
<infinity> Laney: I'll be in the office in ~30... Got distracted working from the hotel and didn't notice the time. :P
<LocutusOfBorg> I mean, is debcheckout supposed to being run from ubuntu users?
<juliank> it's not
<juliank> I mean, think about it
<infinity> "regular users" use binary packages.
<Laney> infinity: I'mjust arriving into St PancrasinfI'm just arriving into St Pancras
<Laney> FML
<Laney> If this even sends
<Laney> see if you can tell from that that I'm on a train
<infinity> Laney: Hahaha.  It sent.  All the times.
<juliank> The Vcs field is only useful for devel
<juliank> if at all
<LocutusOfBorg> infinity, good point :) I would say "regular users don't use linux" probably :p
<Laney> WHICH STATION IS LANEY AT?
<Laney> 'k, see you soon
<juliank> Because the Vcs change often enough for a stable release to be outdated anyway, and we don't SRU Vcs field changes
<juliank> And since we do not SRU Vcs field changes, it's also not appropriate for an upload during final freeze
<LocutusOfBorg> juliank, yep, I happen to use it on Ubuntu, because all my packages are in sync, so I don't care about it being a Debian tool, but meh, you are right
<juliank> I could update the branch name in Vcs-Git for apt when doing stable releases, like I do debian/gbp.conf
<juliank> but I never bothered
<LocutusOfBorg> infinity, wrt apparmor you were right, that warning was from the previous upload, so yes you are right
<LocutusOfBorg> so any idea for this kopanocore upload?
<infinity> LocutusOfBorg: I haven't looked at the issue(s), just noted that removing that comma was wrong. :P
<infinity> LocutusOfBorg: Maybe I can poke later, after respin o'clock.
<LocutusOfBorg> http://launchpadlibrarian.net/419476735/kopanocore_8.7.0-2ubuntu1_8.7.0-2ubuntu2.diff.gz
<LocutusOfBorg> maybe the first version of my upload in the queue was better... not sure if DebOMatic is enough to trigger this issue
-queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2]
<juliank> So
<juliank> I don't really feel like it makes sense for packages to include files needed by apport implementation details in their apparmor profile
<juliank> Maybe we should move the files the python hook needs like cputable into the python abstractions
<juliank> because this does not affect only kopanocore - any crashing python app with a apparmor profile will fail to run the apport crash handler
<juliank> LocutusOfBorg: ^
<LocutusOfBorg> juliank, so you can fix it?
<LocutusOfBorg> and yes I agree that a general problem needs a general solution
<juliank> I'm not entirely sure what we need
<juliank> like we do know we need cputable
<juliank> but we'll probably also need read access to /var/lib/dpkg/status and /var/lib/apt/lists, and configuration files from apt
<sil2100> jibel: morning o/
<sil2100> jibel: did you notice LP: #1824905 during your testing so far?
<ubot5`> Launchpad bug 1824905 in ubiquity (Ubuntu) "Long pause when selecting 3rd party drivers during install" [Undecided,Confirmed] https://launchpad.net/bugs/1824905
<juliank> LocutusOfBorg: FWIW, I don't think it's a huge issue, and I'd focus on finding out why kopanocore fails rather than making the apport hook work
<sil2100> jibel: I wonder if that's reproducible only on specific hardware or maybe happens everytime
 * sil2100 downloads an iso
<juliank> It's unclear to me that just making the apport hook work (adding the file it needs) is the right approach
<juliank> because under normal operation, it will not run, and you give the code access to files it does not _really_ need
<jibel> sil2100, I commented on the bug report
<jibel> sil2100, it's when ubuntu-drivers runs
<juliank> So I think we should leave that up to security team
<jibel> and now it runs every time
<juliank> I'll report a launchpad bug for that
<jibel> sil2100, because we want to install free drivers too for example when running on vmware
<jibel> sil2100, I think the fix is to add some feedback
<juliank> LocutusOfBorg: reported https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824961
<ubot5`> Ubuntu bug 1824961 in apparmor (Ubuntu) "Blocks apport python hook from working" [Undecided,New]
<sil2100> jibel: ah, hm, ok! Thanks
<sil2100> jibel: anyway, since it's doing what it's supposed to, not a blocker - carry on!
<sil2100> ;)
<xnox> infinity, Laney - i am staying at home today, probably like until 2pm at least, because deliveries =(
<juliank> ugh deliveries
 * juliank has one tomorrow, already sad
<sil2100> xnox: aww
<LocutusOfBorg> juliank, what if I say "it doesn't fail on my machine?"
<xnox> infinity, https://code.launchpad.net/~xnox/ubuntu-cdimage/suru-fold-fix-offset-horizon/+merge/366092 better cdimage horizon (from the web team email)
<juliank> LocutusOfBorg: I don't see how that's relevant. There is an issue mapping the python .so file in the test case; that causes the apport hook to be loaded and fail, but it's not the apport failure causing the failure
<LocutusOfBorg> I think I got the issue
<LocutusOfBorg> infinity, ^^ looks like do ko updated the wrong apparmor profile in his patch
-queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset)
 * Laney pats xnox 
<juliank> LocutusOfBorg: hmm, does the profile not include <abstractions/python>
<juliank> I mean, that's why it exists
<juliank> it does contain
<juliank>   /usr/lib{,32,64}/python3.[0-9]/lib-dynload/*.so            mr,
<LocutusOfBorg> it does include yes
<juliank> but then it should just work
<LocutusOfBorg> you right
<LocutusOfBorg> I got it
<juliank> should I rerun that and ssh into it afterwards to see the dmesg?
<LocutusOfBorg> apparmor issue
<LocutusOfBorg> mmm no
-queuebot:#ubuntu-release- Unapproved: rejected mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
<infinity> LocutusOfBorg: On my local machine, I got an entirely different failure when running it.  Something to do with python3-magic. :P
<infinity> LocutusOfBorg: Are you testing any of these uploads, or just stabbing wildly in the dark?
<LocutusOfBorg> on my ppa
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> but I'm having troubles running tests...
<LocutusOfBorg> for some reasons this link doesn't work https://autopkgtest.ubuntu.com/request.cgi?release=disco&arch=amd64&package=kopanocore&ppa=costamagnagianfranco/locutusofborg-ppa&trigger=kopanocore/8.7.0-2ubuntu4
<LocutusOfBorg> is autopkgtestsuite having a sad day?
<infinity> Maybe
<LocutusOfBorg> if I put a wrong ubuntu3 version on the above link it answers "that version is not published in your ppa"
<LocutusOfBorg> and meh, my link should be good
<juliank> Again, if needed I can retrigger the autopkgtest and then ssh into it to debug why it failed
<LocutusOfBorg> yes please :)
<juliank> because so far, the fix attempts do not seem to make much sense
<LocutusOfBorg> none of them, even the ubuntu1 version...
<infinity> Indeed, I think doko's "fix" was misguided, but yours have been following down the same path so far. :)
<infinity> Can you not reproduce locally and iterate?
<Laney> LocutusOfBorg: should be fixed
<LocutusOfBorg> I'm not able to...
<Laney> please try, I didn't want to click your link for you
<LocutusOfBorg> it worked
<infinity> ^-- He means request.cgi
<juliank> I'm running the test manually now with --shell-fail
<LocutusOfBorg> thanks Laney I updated #launchpad to tell that :)
<Laney> Dunno why, but rabbitmq had fallen over with no apparent output
<juliank> I don't feel like it does anything, but I might be wrong
<LocutusOfBorg> is "sudo autopkgtest-build-lxc ubuntu disco" still the correct command to run?
<juliank> don't you want to use lxd?
<juliank> or a VM?
<LocutusOfBorg> "autopkgtest-build-lxd images:ubuntu/disco/amd64"
<LocutusOfBorg> is this still the correct command to run?
<LocutusOfBorg> :)
<LocutusOfBorg> juliank, if you have a link to the docs I'm happy to follow them, the commands I used in the past (artful) don't work anymore
<juliank> I think ubuntu-daily:disco is nicer?
<juliank> But the infra certainly uses the VMs
<juliank> that is, autopkgtest-buildvm-ubuntu-cloud
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.21]
<LocutusOfBorg> juliank, so just a "sudo autopkgtest-buildvm-ubuntu-cloud"?
<LocutusOfBorg> and then, how I run a local test on that package?
<juliank> -r disco, probably
<juliank> it generates an .img file
<rbalint> LocutusOfBorg, -- qemu ~/.img/autopkgtest-disco-amd64.img
<juliank> you then do autopkgtest <dsc/package name> -- qemu <img file>
 * Laney is a bit concerned that LocutusOfBorg is only right now learning this
<LocutusOfBorg> Laney, it didn't work and I started using the Ubuntu infra for this, and usually an sbuild/pbuilder chroot works just nicely, with manual test triggering
<rbalint> Laney, our infra works so well you don't need to know how to run tests locally ;-)
<LocutusOfBorg> I usually look at the debian/tests content, and run it manually
<Laney> You could say that for test builds too
<Laney> but I assume it's considered best practice for people to do those...
<LocutusOfBorg> btw usually failures are not on amd64, so I have to know anyway how to run them on the infrastructure
<LocutusOfBorg> Laney, trust me, I failed to find documentation for that... I'm sure there is, but I can't find it
<LocutusOfBorg> https://manpages.debian.org/testing/autopkgtest/autopkgtest-buildvm-ubuntu-cloud.1.en.html
<LocutusOfBorg> this is the best page I found so far, based on what you told me before
<juliank> test is running now
<juliank> and it worked fine
<juliank> LocutusOfBorg: Looking at the test, this was from over a month ago, and all tests since then have passed
<rbalint> LocutusOfBorg, http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test is a good place to start imo
<LocutusOfBorg> rbalint, sad that google doesn't return that page...
<LocutusOfBorg> I googled "ubuntu autopkgtest wiki" and the results don't help
<juliank> hmm, got kopano 8.7.0-1
<LocutusOfBorg> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Local_deployment
<LocutusOfBorg> this is what is returned
 * juliank used wrong commandline
<juliank> let's try again
<juliank> from this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190304_165158_f8fa9@/log.gz
<rbalint> LocutusOfBorg, google knows me :-) i also looked for "autopkgtest local reproduce"
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (cosmic-proposed) [2.4.46+dfsg-5ubuntu1.2]
<juliank> test's about to run
<juliank> AttributeError: /usr/bin/python3: undefined symbol: magic_open
<juliank> is the error now
<juliank> also seeing a
<juliank> [   42.630778] audit: type=1400 audit(1555407497.911:45): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/sbin/ldconfig" pid=2746 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<juliank> and [   42.629021] audit: type=1400 audit(1555407497.911:42): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/bin/x86_64-linux-gnu-ld.bfd" pid=2745 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<juliank> setting the profile to complain makes it work
<infinity> juliank: Yeah, the magic_open failure is what I got locally too.
<juliank> So I guess it needs
<juliank> /usr/sbin/ldconfig x,
<juliank> /usr/bin/x86_64-linux-gnu-ld.bfd x,
<juliank> with some proper flags
<juliank> but not entirely sure why
<infinity> Why is it running ldconfig?  And why on earth is it running ld?
<juliank> [   42.579760] audit: type=1400 audit(1555407497.859:38): apparmor="DENIED" operation="open" profile="/usr/sbin/kopano-search" name="/usr/sbin/" pid=2743 comm="kopano-search" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<juliank> infinity: that's a good question
<infinity> [119697.987051] audit: type=1400 audit(1555405334.972:218): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/kopano-search" name="/usr/lib/python3/dist-packages/magic/__pycache__/" pid=15645 comm="kopano-search" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<infinity> Oh python, you special.
<infinity> I also see it attempting to run GCC in my ringbuffer.
<juliank> I did not see that
<infinity> [119698.000187] audit: type=1400 audit(1555405334.985:222): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/bin/x86_64-linux-gnu-gcc-8" pid=15647 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
<juliank> nice
<juliank> some ctypes module?
<juliank> or something like that
<juliank> idk how that works
<infinity> Not sure I see the value in attempting to make this migrate.
<infinity> Also puzzled that -1 still works and -2 is a miserable failure.
<juliank> But yes, "python -c "import magic"" definitely executes ldconfig
<juliank> [pid 27144] execve("/sbin/ldconfig", ["/sbin/ldconfig", "-p"], 0x7f107a741ab0 /* 2 vars */) = 0
<juliank> magic!
<juliank> If I make ldconfig fail, it fails
<juliank> it then falls back to gcc and ld
<juliank> so all we need in the profile is to allow ldconfig, really
<LocutusOfBorg> why on earth is -1 happy?
<LocutusOfBorg> oh got it
<juliank> profile broken -> ignored
<willcooke> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824103
<ubot5`> Ubuntu bug 1824103 in linux (Ubuntu) "aplay record file failed always." [Critical,Incomplete]
<willcooke> infinity, ^
<juliank> LocutusOfBorg: should try reproducing this in Debian with AppArmor and then checking that it fails there and report an important (RC?) bug
<juliank> infinity: So the profile in -1 is not applied due to missing comma, and it thus works; and now the profile is applied, and it fails to execute ldconfig
<juliank> which means that -1 is less safe than -2 :D
<juliank> I wonder if adding ldconfig Ix would be OK
<juliank> I tried adding it, but I had no job control, and then pressed Ctrl+C, and it ended my shell...
<infinity> juliank: Ahh.  So updating -2 to warn would not be a regression over -1. :P
<juliank> The fix is to set it to complain, run kopano-search --help
<juliank> then run aa-logprof to update the profile
<juliank> and then cleanup formatting again :D
<juliank>   /sbin/ldconfig Pix,
<juliank> is what doko added to the profile
<juliank> ah and that fails because usr is merged?
<juliank> it needs to be {,/usr}/sbin/ldconfig
<juliank> or maybe it was there before
<juliank> anyhow, needs to account for /usr
-queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.6 => 2.27.1-6ubuntu3.7] (core)
<xnox> juliank, yes.
<juliank> So, I built a package with that change
<juliank> I'll run autopkgtest on it, and upload it if it works fine
<juliank> https://paste.ubuntu.com/p/N784NGD5Yt/
<juliank> if only apparmor would follow (some) symlinks when loading the profile
<xnox> looks good
<LocutusOfBorg> juliank, please also drop the patch
<LocutusOfBorg> from doko
-queuebot:#ubuntu-release- Unapproved: ruby-concurrent (disco-proposed/universe) [1.0.5-2ubuntu1 => 1.0.5-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-oauth2 (disco-proposed/universe) [1.4.1-1ubuntu1 => 1.4.1-2] (no packageset) (sync)
<juliank> LocutusOfBorg: I will, after verifying the change
<juliank> x86_64-linux-gnu-g++: fatal error: Killed signal terminated program cc1plus
<juliank> well, that's not what I expected
<infinity> *snicker*
<juliank> but let's give it 8 gigs of ram instead of 1
<juliank> I gave it 4 cores to compile with
<juliank> so it ran out of memory I guess
<juliank> 1 GB RAM for your autopkgtest vm is not a sensible default
<juliank> 1 GB * CPU core might be
<juliank> well, if it has to build the package
 * juliank does have 24 gig of ram, so I don't really care about giving 8 of that to the VM
-queuebot:#ubuntu-release- Unapproved: accepted ruby-concurrent [sync] (disco-proposed) [1.0.5-3]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-oauth2 [sync] (disco-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2]
<juliank> 4 cores, 8 threads; 24 gigs of ram
<infinity> juliank: 2G/thread is my usual go-to for C++.
<infinity> But 1G/thread is closer to what we do in the DC, I believe.
<infinity> Not positive now.
<juliank> if you told me in like 2010 that I'd have that in my laptop in 2019 (or 2018 when I got it), I'd have been totally amazed
<rbalint> juliank, i'm most impressed my nvme's speed
<juliank> that's nice too
<infinity> juliank: My modest desktop has 64G of RAM, and my brother reminded me that the "killer dual socket PPro workstation" we built in 1996 had 64MB.
<juliank> I don't think I could deal well with multiple machines
<juliank> hence I'm on a laptop all the time
<infinity> I live most of my life on laptops, but the desktop is much more comfortable for gaming.
<juliank> I don't want to know what my first desktop had
<infinity> And desktop parts are cheap enough that it's not really a big deal building one that's pupose-built just for fun.
<juliank> I only remember was an athlon
<infinity> Wow, you're young.
<infinity> I got my first Athlon 750 free at an AMD preview event in 1999.  It was the best thing EVER.
<infinity> And I was 22.
<juliank> I think I got it like 2001/2002 with XP
<juliank> prior to that we only had one family computer
<juliank> it came with Windows 98 SE
<infinity> That was also in the dark period when Intel and AMB both briefly thought that cartdiges were a good form-factor for CPUs.
<infinity> AMD*
<infinity> Also, cartridges.  Typing is hard.
<juliank> My dad also had a laptop with Windows ME if I'm not mistaken
<juliank> Oh, before that we had some other thing
<rbalint> Laney, does autopkgtest not pick up unattended-upgrades ubuntu5 or i'm not patient enough?
<Laney> I just had to make do with a copy of Turing's thesis.
<Laney> rbalint: check https://people.canonical.com/~ubuntu-archive/proposed-migration/log/ ?
<juliank> I don't know if it was an Atari or an Amiga
<juliank> or something like that
<juliank> and there was another DOS/Windows < 3.1 machine
<juliank> I fried that one by turning the switch to 110V on our 230V system
-queuebot:#ubuntu-release- Unapproved: redmine (disco-proposed/universe) [4.0.1-1 => 4.0.1-2] (no packageset) (sync)
<juliank> tar: ./debian/build/ECtools/archiver/helpers/.libs/StoreHelper.o: Wrote only 8192 of 10240 bytes
<juliank> hmm, I don't have any lucj
<juliank> just running out of space trying to build kopanocore
<juliank> and the other qemu seems stuck too
<juliank>    dh_dwz -O--builddirectory=debian/build
<juliank> and nothing after that
-queuebot:#ubuntu-release- Unapproved: gitaly (disco-proposed/universe) [0.129.0+debian-3 => 1.20.0+debian-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: golang-gitaly-proto (disco-proposed/universe) [0.123.0+dfsg-2 => 1.14.0+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: golang-google-cloud (disco-proposed/universe) [0.9.0-9 => 0.9.0-10] (ubuntu-mate) (sync)
<LocutusOfBorg> this should fix some golang packages migration ^^
<LocutusOfBorg> damn ubuntu-mate why did you seed it
<rbalint> Laney, thanks, it says pending - there is a lot pending :-(
<Laney> Maybe they got fubared when rabbitmq died earlier
<Laney> lemme see
<juliank> Building in https://launchpad.net/~juliank/+archive/ubuntu/kopanocore now
<juliank> I do remember this joystick: https://www.c64-wiki.de/images/a/aa/Competition_pro_blau.jpg
<juliank> but that does not help figuring out which machine it was back then
<juliank> must have been mid 90s, and like 5-10 years old
<juliank> (the machine that is)
<rbalint> Laney, thanks!
<Laney> there you go
<Laney> I skill shared the process to infinity :>
<juliank> Laney: It worked!
<juliank> um
<juliank> LocutusOfBorg: It worked!
-queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1 => 8.0.0+git20190314-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset)
<juliank> LocutusOfBorg: Uploaded and forwarded to Debian
<juliank> fwded to debian bug 927215
<ubot5`> Debian bug 927215 in kopanocore "kopano-search: AppArmor profile does not account for usrmerge" [Serious,Open] http://bugs.debian.org/927215
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.7-0ubuntu1 => 1.1.7.1-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (disco-proposed) [8.0.0+git20190314-0ubuntu2]
<infinity> handsome_feng: Your ukui-control-center breaks the indentation of the g_timeout_add() call.  Did you want to undo that so it's still readable?
-queuebot:#ubuntu-release- Unapproved: accepted gitaly [sync] (disco-proposed) [1.20.0+debian-1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-google-cloud [sync] (disco-proposed) [0.9.0-10]
-queuebot:#ubuntu-release- Unapproved: accepted golang-gitaly-proto [sync] (disco-proposed) [1.14.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted redmine [sync] (disco-proposed) [4.0.1-2]
<xnox> infinity, may i upload casper?
<infinity> xnox: Depends why.
<xnox> infinity, systemd-sysusers fails to start on overlayfs /, because it doesn't like .pwd.lock file resulting in non-quiet & degraded live-session boot
<xnox> with ugly messages on boot, on e.g. subiquity-live server image
<infinity> xnox: What's the proposed fix for this?
<xnox> rm /root/.pwd.lock; touch /root/.pwd.lock; touch /root/etc/passwd; touch /root/etc/passwd-
<xnox> infinity, i.e. ensure all three are "on the upper layer"
<xnox> aka safe fs, cause systemd cares
<handsome_feng> infinity: oh, Sorry, I didn't notice that, can you reject that and I will adjust the format
<infinity> xnox: Does this start before we create the ubuntu user (cause that should pull passwd up to the top layer)
<infinity> Done.
<infinity> handsome_feng: Done.
<handsome_feng> infinity, Thanks!
<xnox> we do: chroot /root /usr/lib/user-setup/user-setup-apply > /dev/null
<xnox> so yeah, the passwd files should be in the upper layer already. let me double check things again, by rebooting with break-bottom again.
-queuebot:#ubuntu-release- Unapproved: rejected ukui-control-center [source] (disco-proposed) [1.1.7.1-0ubuntu1]
<xnox> systemd-sysusers sees i/o error and ???? in ls -a /etc/.pwd.lock file
<infinity> xnox: I don't see why it would be seeing I/O errors there...
<xnox> there are other errors too
<xnox> infinity, http://people.canonical.com/~xnox/casper-bottom.png
<xnox> cause like subiquity has no display-manager, and like probably not enough of polkit-1 stuff
<xnox> cause enodesktop
<mwhudson> those squashfs errors are faaaiiirly new
<infinity> So some of that stuff needs [ -d ] and [ -f ] guards?
<mwhudson> eep need to be asleep
<xnox> mwhudson, yes, came with like v5 kernel. i do want kernel people to look at it... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824407
<ubot5`> Ubuntu bug 1824407 in linux (Ubuntu) " why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather" [Undecided,Incomplete]
<xnox> infinity, so .pwd.lock passwd passwd- are all in upper
<infinity> xnox: Okay, so... What are you proposing fixing? :P
<xnox> infinity, rm /root/etc/.pwd.lock i think now
<infinity> ...
 * xnox digs systemd code
<infinity> .pwd.lock is supposed to be there...
<xnox> infinity, http://people.canonical.com/~xnox/pwd-lock-fail.png
<xnox> that's how things look when booted.
<xnox> infinity, i wonder if it is bad that we have .pwd.lock in filesystem.squashfs and our mount is lowerdir=installer.squashfs:filesystem.squashfs with an upper dir on top.
<xnox> failing like everything.
<xnox> i wonder if livecd-rootfs should have cleaned up .pwd.lock in filesystem.squashfs
<xnox> hahhahahhaa
<xnox> infinity, http://paste.ubuntu.com/p/NsMGVTr66Z/
<infinity> I genuinely have no idea what that means.
<xnox> i wonder, if that's my squashfs errors too!
<infinity> apw: ^
<apw> infinity, i think that error says "you tried to create a file over a directory of the same name and that won't work here"
<xnox> so rm /root/etc/.pwd.lock definately "fixes" systemd-sysusers. But it feels like a bug in rootfs ontop of multi-lower squashfs
<apw> infinity, or the other way round
<xnox> i wonder if it would help if the middle layer would have had a /etc directory or the lock file, or like if the lowest layer didn't have .pwd.lock in it.
 * xnox tries my fix by editing things from like break=top
<infinity> xnox: I assume desktop ISOs don't see this?
<xnox> it maybe hidden by plymouth, let me check if they boot degraded or not
<xnox> (possibly multilowerdir issue -> in which case desktop single-layer ubiquity should not be affected)
<apw> xnox, yeah there is a directory on the lower layer and you are trying to copy-up-and-replace with a file
<apw> xnox, so it is not clear it should not fail with ENOWAY anyhow
<xnox> testing $ echo 'rm /root/etc/.pwd.lock' >> 25adduser => works like a charm, uploading casper.
<xnox> and can figure out what's wrong with our squashfs with apw whilst that is in progress.
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.7-0ubuntu1 => 1.1.7.1-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.5]
-queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.404 => 1.405] (desktop-core, ubuntu-server)
<Laney> xnox: tseliot was wanting to upload casper too, please to coordinate
 * xnox wishes we had an up todate repo for casper.
 * xnox nominates casper as a snap!
<cjwatson> ...
<Laney> (rejected, pending such coordination)
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (disco-proposed) [1.405]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (disco-proposed) [1.1.7.1-0ubuntu1]
<handsome_feng> Thanks!
<xnox> tseliot, this is my diff http://launchpadlibrarian.net/419512765/casper_1.404_1.405.diff.gz
<tseliot> xnox: sure, let me apply that, and re-upload
<xnox> infinity, Laney - on my way to the office.
<tseliot> Laney, xnox: uploaded
-queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.404 => 1.405] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curl (cosmic-proposed/main) [7.61.0-1ubuntu2.3 => 7.61.0-1ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (disco-proposed) [1.405]
<cyphermox> Laney: tseliot: xnox: can we just all agree to use git-ubuntu's snapshot then?
<cyphermox> (for next uploads)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (disco-proposed/main) [1:12.2-2ubuntu1 => 1:12.2-2ubuntu2] (desktop-core, ubuntu-server)
<LocutusOfBorg> archive admins, ushare has never appeared in Debian, and its in proposed-only since a while... can we kick it out completely, or is anybody having a look?
<LocutusOfBorg> (is it still needed?)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (disco-proposed) [1:12.2-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (cosmic-proposed/universe) [1:10.1.29-6ubuntu2 => 1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (disco-proposed/main) [1:12.2-2ubuntu2 => 1:12.2-2ubuntu3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (disco-proposed) [1:12.2-2ubuntu3]
<tseliot> cyphermox: I'm all for using git. I always use git when I make changes to packages. I wish casper were hosted somewhere, and that the CVS were mentioned in the debian/control file
<cyphermox> yeah, that's why I said that one; would just need to be listed in debian/control
-queuebot:#ubuntu-release- Unapproved: rejected mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
<rbasak> cyphermox, tseliot: casper is interesting for git-ubuntu, as it's never going to be in Debian and doesn't have an established VCS location
<rbasak> You could point Vcs-* to git-ubuntu, but then you wouldn't be able to have any pre-upload "holding area"
<rbasak> (which could be fine)
<rbasak> xnox also: ^
<vorlon> morning
<rbasak> Or if you want a holding area, that might have to be somewhere else eg. ~ubuntu-core-dev
<vorlon> infinity, sil2100: anything you need from me today for release?
<infinity> vorlon: All the testing ever, in about an hour.
<rbasak> However you could keep that in sync with git-ubuntu's imports if you wished
<infinity> Give or take.
<vorlon> heh
<cyphermox> rbasak: tbh I was just interested in taking the import as a basis; and then keeping the code under ~ubuntu-core-dev.
<rbasak> cyphermox: that would work
<cyphermox> infinity: so, spins coming up?
<vorlon> infinity: so new images currently awaiting respin? what's the critical path on that?
<rbasak> cyphermox: it might be a little painful if you get a non-VCS upload though. But no more painful than the same for any other package maintained in VCS.
<infinity> vorlon: casper and pulseaudio are the only triggers in proposed, the rest is migrated.
<vorlon> ok
<cyphermox> rbasak: yeah, well, there's only so much we can do
<rbasak> cyphermox: agreed, though my interest is: what can we do that will work and is better? :-)
<rbasak> (for git-ubuntu and all packages generally I mean; not just casper)
<rbasak> Finding best practice, etc.
<cyphermox> rbasak: ok
<tseliot> rbasak: I don't remember ever using git-ubuntu, but I'll have a look at the docs.  Thanks
<rbasak> tseliot: np. Sorry the docs are probably awful. It's still very experimental.
<rbasak> Feel free to ask questions etc.
<tseliot> rbasak: I found this: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<tseliot> but sure, if I have any questions I will ask :)
<tobikoch> sil2100: platonical and I are contacts for cloud-image related stuff during and after the upcoming release.
<platonical> lol beat me to it
<tobikoch> :P
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset)
<LocutusOfBorg> ^^ please accept the second version, I added in changelog the reference to the Debian RC bug I just opened
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset)
<vorlon> kenvandine: hi, so, I just checked the latest disco desktop image build and I see that it's pulling in both core and core18 snaps; are we not fully transitioned to core18?
<sil2100> tobikoch, platonical: thanks!
<kenvandine> vorlon: we are not
<vorlon> well, that certainly won't help the bandwidth question any
<kenvandine> vorlon: well all of our seeded snaps are core18 now
<vorlon> kenvandine: what was left untransitioned?
<platonical> sil2100, is there an ISO respin happening now, and do you know what triggered it?
<kenvandine> but we didn't want to drop the core snap late in the cycle
<kenvandine> which would require snapd + core18 snaps
<kenvandine> that hadn't been tested yet
<vorlon> kenvandine: what is pulling in core snap?
<kenvandine> so we're still use snapd from the core snap
<kenvandine> core is seeded to get snapd
<vorlon> kenvandine: we HAVE landed changes in livecd-rootfs to pull in core18 and snapd snaps
<vorlon> uh
<vorlon> unseed that
<kenvandine> oh
<kenvandine> well maybe we aren't then :)
<kenvandine> it was livecd-rootfs :)
<vorlon> oh
<kenvandine> great then
<vorlon> right, we fixed that but something else is still pulling core in as a dep
<vorlon> afaics
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (cosmic-proposed/universe) [1:10.1.29-6ubuntu2 => 1:10.1.38-0ubuntu0.18.10.1] (no packageset)
<kenvandine> cool, so that should be working then
<vorlon> yeah, I pushed on the team to get all of that sorted out in livecd-rootfs for 19.04
<vorlon>  /so that/ we wouldn't pull in two core snaps
<vorlon> but the log shows we're still pulling in core, which means it's a dep of something
<kenvandine> vorlon, willcooke: do we want to try to get gnome-3-28-1804 refreshed with the security fix for libxslt before you spin images?
<vorlon> infinity: ^^
<vorlon> kenvandine: (I'm not in London, I was just proxying based on earlier discussion here in channel)
<kenvandine> maybe gtk-common-themes?
<kenvandine> that doesn't have base: core18
<vorlon> kenvandine: yes, likely
<kenvandine> it doesn't stage packages and is arch all
<vorlon> is that all data?
<kenvandine> yeah
<vorlon> could we make it base: none?
<vorlon> (quickly?)
<kenvandine> i can do a quick test of that
<sil2100> base: none would still make it pull in core I guess
<vorlon> sil2100: why?  does livecd-rootfs treat none specially?
<vorlon> I thought base: none really means none :)
<sil2100> Ah, wait, maybe not, I know that snap-tool treats the lack of base: as core, but maybe base: none will do the trick?
<sil2100> nvm me then ;)
<vorlon> right, or maybe it'll break the build because snap-tool /doesn't/ know how to handle base: none ;)
 * sil2100 tries to check that quickly
<sil2100> I guess snap-tool will be fine
<vorlon> sil2100, kenvandine: ok I just checked snap-tool in livecd-rootfs, and I don't see that it knows how to handle base: none
<vorlon> it will look for it as the name of a snap to preseed
<kenvandine> :/
<vorlon> which AIUI is incorrect
<sil2100> Can't we switch it to base: core18 in this case? Since we anyway pull in core18 now from other snaps
<vorlon> that would probably be better yeah
<sil2100> I wonder if that would be acceptable for the snap though
<vorlon> and then we can make livecd-rootfs know about base: none at leisure
<kenvandine> my only concern is other snaps that aren't using core18 but are using gtk-common-themes will now suddenly pull in core18
<kenvandine> but that number should be low
<willcooke> kenvandine, do we have any data on that?
<kenvandine> yeah
<sil2100> I can quickly prepare a fix for snap-tool, but I think it's a bit lateish for fast-tracking a livecd-rootfs
<kenvandine> i can look at stats on gtk-common-themes to see which distros have installed devices
<kenvandine> anything bionic and newer will have core18 already installed
<vorlon> sil2100: I'm available to review (or maybe tobikoch is better)
<vorlon> I think we should at least start down that path even if we can't get all the way for 19.04
<kenvandine> agreed
-queuebot:#ubuntu-release- Unapproved: libxslt (disco-proposed/main) [1.1.32-2 => 1.1.32-2ubuntu0.1] (desktop-core, ubuntu-server) (sync)
<willcooke> kenvandine, ^ libxslt
<willcooke> so I think that yes, we should try and get the platform snap updated too.  Is it a big job?
<willcooke> kenvandine, i_nfinity said that time is short for the platform snap
<kenvandine> vorlon: the numbers are low for other distros, won't be a big impact
<kenvandine> i can kick off a build adding core18
-queuebot:#ubuntu-release- Unapproved: accepted libxslt [sync] (disco-proposed) [1.1.32-2ubuntu0.1]
<sil2100> kenvandine, vorlon: do we have some snap in the snapstore that has base: none already?
<tobikoch> sil2100, vorlon: instead of hacking snap-tool, I would suggest special-casing "none" in _snap_preseed (live-build/functions l. 494).
<sil2100> tobikoch: well, depending if this is a 'hack' or 'per-design'
<sil2100> ;)
<sil2100> tobikoch: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/366124
<sil2100> tobikoch: but yeah...
<sil2100> vorlon: is base: none a formal thing? I tried finding it somewhere in the docs, but couldn't
<tobikoch> sil2100: i'd say it is probably not
<tobikoch> sil2100: I think the change in that MP is not what we want. If base is reported as "" by snap-tool then livecd-rootfs assumes base core and pulls in core.
<tobikoch> So we really want the hack in livecd-rootfs and maybe get this formally specified later.
<sil2100> tobikoch: oh, ok, since I thought that the way it's done is that when base is None (so not defined), then *snap-tool*  defaults to core
<sil2100> And that livecd-rootfs doesn't have to do anythiing when seeing base: "", because if base is "" it should not pull in anything (as that means the snap is a base snap)
<tobikoch> sil2100: that logic isn't in snap-tool. snap-tool is only used to ask the API for info about the snap including its base. The API will report "" for snaps that have base core. So livecd-rootfs treates that as having to pull in core. If you modify the snap that causes core to be pulled in to explicitly specify its base as "none", then that needs to be treated in _snap_preseed.
<sil2100> tobikoch: wait, what about snap-tool line 207 then?
<sil2100> tobikoch: that line basically does self.is_core_snap() and sets base to "", core snaps have no base at all through the API from what I see?
<willcooke> kenvandine, re: snap(s) needing the new xslt - what can I do to help test?
<sil2100> tobikoch: and the next line sets "core" as the base of snaps that do not provide base at all
<tobikoch> sil2100: slow down a sec
<kenvandine> willcooke: refresh gnome-3-28-1804 from candidate and run the seeded snaps
<kenvandine> make sure they behave
<willcooke> doing....
<kenvandine> i'm testing on bionic now
<kenvandine> gtk-common-themes with base:core18 is building and should be in candidate soon
<kenvandine> we can verify that's sane soon
<kenvandine> vorlon ^^
<tobikoch> sil2100: take a snap that has base "core" and ask the API which base it has, then you will get back *no result* for that attribute. So snap_data["snap"]["base"] would not be set and snap_data["snap"].get("base") would return the special None object not the string "None". So all this line does is to populate that attribute with an empty string.
<willcooke> ð½
<tobikoch> sil2100: but if gtk-common-themes now has core18 and that works as expected, I'd shelve the hack until this can be discussed with the snap people later. My two cents.
<cjwatson> sil2100: https://bugs.launchpad.net/launchpad/+bug/1819196 has links
<ubot5`> Ubuntu bug 1819196 in Launchpad itself "support for base: none and build-base" [High,Triaged]
<cjwatson> may not completely help but ...
<tobikoch> cjwatson: how is "none" reported by the API?
<cjwatson> What API?
<tobikoch> cjwatson: /v2/snaps/refresh when I ask for the "base" field to be included.
<cjwatson> I would assume it passes it through literally because why would we change it ...
<willcooke> kenvandine, calc chars system monitor and snap store snap all tested, seems fine to me
<vorlon> cjwatson: ah, that blog of sergiusens's discusses it being supported in "upcoming releases" of snapcraft/snapd, do you know if that's landed?
<cjwatson> vorlon: Don't know, sorry
<kenvandine> willcooke: great, all good on bionic too
<willcooke> kenvandine, oh, that was Bionic too
<vorlon> (no harm in livecd-rootfs implementing that preemptively anyway)
<willcooke> stand by
<kenvandine> willcooke: oh, you tested both?
<cjwatson> tobikoch: Right, as far as I can tell the store just passes that straight through unmodified
<cjwatson> "none" as a string, not "None" or None
<cjwatson> (or null)
<tobikoch> cjwatson: actually, I get Python None, not "none" (e.g. snapd see https://pastebin.canonical.com/p/9K8jnKP27v/), but I also get that for snaps that have implicit base "core" (e.g. lpshipit see https://pastebin.canonical.com/p/CKnTZFCTVJ/).
<cjwatson> core isn't a real base and should result in null
<cjwatson> do not confuse the implicit core base with base: none
<cjwatson> snapd does not have base: none
<cjwatson> it has no base
<cjwatson> not the same thing
<cjwatson> (I didn't come up with this, just the messenger)
<tobikoch> cjwatson: hehe, ok
<tobikoch> cjwatson: know of a snap using "none" explicitly?
<cjwatson> I'm not sure there are any yet
<willcooke> kenvandine, same tests run on B & D.  All fine
<cjwatson> let me run a quick query
<cjwatson> snaprevs_production_standby=> SELECT DISTINCT snap_id FROM snaprevision WHERE base = 'none';
<cjwatson>  snap_id
<cjwatson> ---------
<cjwatson> (0 rows)
<kenvandine> willcooke: ok, now do the same thing with gtk-common-themes from candidate :)
<tobikoch> cjwatson: thanks :)
<cjwatson> np.  it's still in development I think so not too surprised
<cjwatson> none on staging either
<infinity> Or is it None on staging?
 * infinity ducks.
<sil2100> "none", none or None?
<tobikoch> vorlon, sil2100: ^ so if a snap had base set to "none" explicitly, snap-tool should print base: none and we should special case livecd-rootfs to not do anything when it sees "none". So livecd-rootfs/live-build/functions line 494. Printing the empty string instead will make livecd-rootfs assume implicit "core".
<tobikoch> sil2100: 'none' see cjwatson's sql above.
<willcooke> kenvandine, tested - all good
<kenvandine> willcooke: thanks
<kenvandine> all good for me too
<willcooke> kenvandine, so will you promote to stable?  Should we ping snap store first?
<kenvandine> willcooke: i've been talking to snapstore folks
<kenvandine> roadmr just finished generating deltas
<willcooke> kenvandine, super thanks!
<kenvandine> almost ready to promote it
<sil2100> tobikoch: no, so I disagree here - an empty string will not make livecd-rootfs assume implicit core from what I see, the empty string will only cause the check in _snap_post_process() to happen but it will result as a no-op as the snap name is not core or core18
<kenvandine> vorlon: does livecd-rootfs only seed snapd if the core snap isn't seeded?
<sil2100> tobikoch: but anyway, since this is not on fire right now, let's take this discussion to the MP
<vorlon> kenvandine: yes
<kenvandine> cool
<kenvandine> vorlon: i have gtk-common-themes ready with core18
<kenvandine> shall i promote it and see what the isos look like?
<tobikoch> sil2100: yeah, you're right! I'm getting it all mixed up myself. The empty string would also do the right thing.
<sil2100> tobikoch: I'm not saying I'm against moving the change from snap-tool to livecd-rootfs functions, I just feel it's more of a preference thing - anyway, let's discuss it further there ;)
<sil2100> tobikoch: we can bikeshed a bit more there about it
<tobikoch> ok, I'll add a comment
<sil2100> kenvandine: yes please o/ (hoping that won't break everything)
<vorlon> kenvandine: if you're satisfied that this doesn't have adverse impact on snaps outside of the desktop that depend on gtk-common-themes
<kenvandine> sil2100, vorlon: done
<kenvandine> Wimpress: ^^ gtk-common-themes is now core18, should make you happy too :)
<sil2100> kenvandine: thanks!
<kenvandine> sil2100: np, i'm anxiously awaiting isos to test :)
<Laney> don't hold your breath :P
<infinity> Go on.  Hold your breath.  I dare you.
-queuebot:#ubuntu-release- Unapproved: gedit (disco-proposed/main) [3.32.0-2 => 3.32.0-3] (ubuntu-desktop)
<sil2100> kenvandine: hey, ummm
<sil2100> kenvandine: so
<sil2100> kenvandine: is it possible that you could revert your gtk-common-themes change ;p ?
<sil2100> kenvandine: we just learned from the snapd team that we *need* to have core right now *anyway*
<sil2100> kenvandine: since even if none of the snaps use core as its base, we've been told we *anyway* need the core snap because of some bugs in the snapd snap
<sil2100> ...
<sil2100> ;)
<sil2100> willcooke: ^
<sil2100> infinity: ^
<sil2100> grrrr
<willcooke> do we need to revert though? Can we seed it?
<sil2100> willcooke: we could seed it, but vorlon said he'd prefer to revert the change instead
<infinity> Why do we need core?
<infinity> Gross.
<infinity> Yo dawg, we heard you like root filesystems.
<sil2100> infinity: yeah, we need to have 2 base systems shipped on disco now, yay
<infinity> I kinda feel like if we need core anyway, we shouldn't have anything using 18 yet. :/
<infinity> Oh well.
<sil2100> Moar..!
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1016.16~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1016.16] (kernel)
<sil2100> infinity: yeah, it seems to have been a miscommunication somewhere
<sil2100> A big one
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1016.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1016.16]
<vorlon> infinity, willcooke: yes, it seems that there are bugs that prevent snapd+core18 from being sufficient on a classic desktop system, so we still have to pull in core for now. I think reverting gtk-common-themes is the best option for now
<infinity> vorlon: Right, and I think that also means we don't want the snapd snap yet.
<vorlon> and core 19.04 the snapd team is supposed to remove the need for core snap
<infinity> Since we'll have snapd from core.
<sil2100> vorlon: per infinity's question here, I guess it'd be good to actually remove the logic that pulls in snapd
<vorlon> infinity: right, and I believe tobikoch's code is smart enough to figure this out
<sil2100> Yeah
<infinity> Is it?  Kay.
<infinity> If core is there, it won't snapd?
<vorlon> the log shows snapd snap being seeded to go along with core18, but it later un-seeds it again once core is pulled in
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.32.1-1ubuntu2 => 3.32.1-1ubuntu3] (ubuntu-desktop, ubuntugnome)
<sil2100> Ah, good!
<sil2100> phew
<vorlon> you should check the iso contents to confirm
<willcooke> kenvandine will be back in about 20 mins.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (disco-proposed) [3.32.1-1ubuntu3]
<platonical> vorlon, sil2100, I'm about to respin Disco bc I need to pull in a lxd fix. Is there anything else I should be waiting for?
<sil2100> platonical: so there's still a few packages that we're waiting to migrate before re-spinning
<platonical> sil2100, ok, do you know how long you expect that to take?
<vorlon> sil2100: which packages? casper should be migrated; do cloud images care about pulseaudio?
<vorlon> seeded-in-ubuntu says no
<vorlon> wait
<vorlon> libpulse0 is in ubuntu-server daily
<vorlon> .. which should only be the apt repo, not the server seed
<vorlon> so that's ok
<vorlon> but libxslt is a security fix and is on the server live seed
<sil2100> vorlon: we also have libxslt which is seeded in server, but on the other hand I indeed don't know what's up
<vorlon> ok
<vorlon> platonical: ^^ sounds like that's the blocker
<sil2100> *what's up with that
<vorlon> is someone poking at asterisk/i386 autopkgtest failure?
<platonical> vorlon, sil2100, ok thanks. ETA on that?
<sil2100> platonical: the tests are running, I'd suppose they won't take much longer, most are finished
<vorlon> platonical: once the autopkgtest results have finished and are all green on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libxslt , plus ~20minutes
<vorlon> (sorry, I don't have a good way to estimate completion of autopkgtests at a glance)
<platonical> ok thanks
<vorlon> uh libreoffice is in there
<vorlon> we should probably skip waiting for libreoffice test results :P
<sil2100> ugh
<vorlon> or else make the call to have this as a zero-day security update
<sil2100> vorlon: ok, so infinity will skip some tests for it to migrate soonish
<sil2100> vorlon: and I just confirmed that on the last image (which had both core18 and core) no snapd snap has been preseeded, so it's working as expected indeed
<infinity> vorlon: Yeah, I skipped the rest of libxslt tests, it's tested enough.
<kenvandine> sil2100: done
<infinity> And I'm going to build images as soon as kenvandine gets his thingee reverted.
<infinity> sil2100: Oh, was that "done" for the revert?
<infinity> So, I guess I'm waiting on britney, not Ken. :P
<vorlon> ok
<kenvandine> yup :)
 * infinity waits impatiently for gnome-initial-setup to publish.
<infinity> Guess I can start on base and server.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Final] has been updated (20190416.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Final] has been updated (20190416)
<bdmurray> fossfreedom: Having a link to the errors bucket in bug 1824229 would be helpful so that SRU team members can know what you are talking about.
<ubot5`> bug 1824229 in budgie-desktop (Ubuntu Cosmic) "[SRU] Cherrypick bug-fixes and usability issues for budgie-desktop" [Medium,In progress] https://launchpad.net/bugs/1824229
<fossfreedom> bdmurray, ok
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Unapproved: libsodium (xenial-updates/universe) [1.0.8-5 => 1.0.8-5] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libsodium [sync] (xenial-updates) [1.0.8-5]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Final] has been updated (20190416)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Final] has been updated (20190416)
<Eickmeyer> infinity: I'm assuming we'll be seeing a new RC email soon?
 * valorie is waiting to link to it
<cyphermox> rcj: any idea about maas streamed images, if they're RC?
<bdmurray> fossfreedom: given that there already is a bug for "Issue 1" in bug 1824229 why didn't you just use that? As an SRU team member its complicated for me to track multiple issues in one bug report.
<ubot5`> bug 1824229 in budgie-desktop (Ubuntu Cosmic) "[SRU] Cherrypick bug-fixes and usability issues for budgie-desktop" [Medium,In progress] https://launchpad.net/bugs/1824229
<bdmurray> fossfreedom: for me to verify that the sru verification was done properly I'm going to have to look through the bug with a mental checklist of all 4 issues and look for verification of each part which is a pain
<rcj> cyphermox: I'll defer to platonical as he's tracking release
<vorlon> Eickmeyer, valorie: I don't assume that a respin of RC images results in a new email
<platonical> rcj, cyphermox, what's RC?
<Eickmeyer> RC = Release Candidate
<Eickmeyer> vorlon: Thanks
<cyphermox> platonical: yeah, I mean, if I deploy disco on a machine from MAAS, am I testing anything useful?
<cyphermox> in case I can check off some test on the drive-by
<platonical> cyphermox, there's currently a 20190416.1 disco build in progress, that will probably be better to test than 20190416, as we've pulled in some essential fixes
-queuebot:#ubuntu-release- Unapproved: rejected containerd [source] (cosmic-proposed) [1.2.6-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected containerd [source] (bionic-proposed) [1.2.6-0ubuntu1~18.04.1]
<rcj> cyphermox: missing from 20190416 is an apparmor fix needed for lxd
<cyphermox> ok
<cyphermox> what I have here appears to be snapshot-20190416-193741 right nw
<cyphermox> that's probably 16, not 16.1
<cyphermox> I guess I answered my own question, this is the right ballpark timestamp to be testing very recent images
<platonical> cyphermox, I don't follow the snapshot syntax, where are you getting that from?
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Final] has been updated (20190416.2)
<cyphermox> platonical: straight from the filesystem on a MAAS rack server; in /var/lib/maas/boot-resources
<platonical> cyphermox: ah. well I can let you know when 20190416.1 is finished building if you like
<cyphermox> nah, it's fine, I'll watch what's on disk and in the logs
<platonical> ð
<cyphermox> it seems to be updating quickly enough
<fossfreedom> bdmurray, hmm - ok.  I can divide each issue into separate issue reports if that helps.
<bdmurray> fossfreedom: I think it really would but I'm just one member of the team. Its possible somebody could disagree with me but I'd be surprised. :-)
<fossfreedom> bdmurray, don't really mind.  Can you please reject the bionic and cosmic uploads so that I can reupload with the new issue numbers?
<bdmurray> fossfreedom: thanks, that'll help and sure I'll do the reject.
-queuebot:#ubuntu-release- Unapproved: rejected budgie-desktop [source] (cosmic-proposed) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: rejected budgie-desktop [source] (bionic-proposed) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (bionic-proposed/universe) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.1 => 10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.1 => 10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2018i-0ubuntu0.18.04 => 2019a-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (cosmic-proposed/main) [2018i-0ubuntu0.18.10 => 2019a-0ubuntu0.18.10] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2018i-0ubuntu0.16.04 => 2019a-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2018i-0ubuntu0.14.04 => 2019a-0ubuntu0.14.04] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-software (disco-proposed/main) [3.30.6-2ubuntu3 => 3.30.6-2ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been marked as ready
#ubuntu-release 2019-04-17
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.9 => 3.28.1-0ubuntu4.18.04.10] (ubuntu-desktop)
<valorie> thanks vorlon
<doko> vorlon, infinity: is there still time to upload the openjdk-11 security update for disco? will take ~14 hours to build
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.11 => 3.20.5-0ubuntu0.16.04.12] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+5-1ubuntu2 => 11.0.3+7-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: openjdk-12 (disco-proposed/universe) [12.0.0-3 => 12.0.1+12-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-12 [source] (disco-proposed) [12.0.1+12-1]
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.2-0ubuntu10 => 3.30.2-0ubuntu11] (ubuntu-desktop)
<vorlon> doko: we should let it start building; it's not seeded on any images
<tobikoch> `multipass launch http://cloud-images.ubuntu.com/disco/20190416.1/disco-server-cloudimg-amd64.img` does not produce a working vm (times out and goes into state unknown).
<tobikoch> sil2100, vorlon: I assume that might be a blocker?
<tobikoch> So now it's official Azure gen2 is not ready ready.
<LocutusOfBorg> as said, I'm worried about kernel 5 and virtualbox 6.0.4, because the canonical-made patches are too few wrt the upstream patches. This might require in issues with the iso testing in a virtualbox VM
<LocutusOfBorg> I hope you can accept them, but I can understand the bad timing (it took me half the night to upload them in debian)
<LocutusOfBorg> also, 15 security issues in this release are fixed, some scored 9.8/10 as severity
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (disco-proposed/multiverse) [6.0.4-1 => 6.0.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox (disco-proposed/multiverse) [6.0.4-dfsg-7 => 6.0.6-dfsg-1] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (disco-proposed/multiverse) [6.0.4-1 => 6.0.6-1] (no packageset) (sync)
<LocutusOfBorg> ok, the CVEs are only 12, and the highest risk is 8.8, not that bad
<LocutusOfBorg> vorlon, good morning, looks like seqan2 is now building fine on armhf (the version in Debian), so I'm thinking wrt stealing your merge and upload, the package is not seeded...
<mvo> rbasak: hey, do you think the shadow SRU for xenial and bionic can be released? afaict its ready and in proposed for a couple of days already
-queuebot:#ubuntu-release- Unapproved: seqan2 (disco-proposed/universe) [2.4.0+dfsg-8ubuntu2 => 2.4.0+dfsg-11ubuntu1] (no packageset)
<infinity> tobikoch: Is that multipass command meant to work? :P
<infinity> tobikoch: Launching that image in raw kvm gets me a login prompt.  I imagine I need cloud-init goop to actually be able to use it, though.
<tobikoch> infinity: I dunno, I mean it can just be a multipass problem, of course. Then not our problem.
<jibel> apart from nvidia/nouveau is there anything to verify in particular on image 20190416?
<Wimpress> jibel: WHat nvidia testing is required? I can help with that.
<jibel> Wimpress, booting with nouveau, but I've someone on it, so it should be fine.
<infinity> jibel: There was the asound/pulse thing.
<infinity> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1824103
<ubot5`> Ubuntu bug 1824103 in pulseaudio (Ubuntu) "aplay record file failed always." [Critical,Fix released]
<jibel> infinity, this pa bug, does it affect any system or only carbon ?
<infinity> jibel: Affected my T450s.
<infinity> jibel: And Will's.
<pieq> jibel, infinity ok thanks
<infinity> jibel: Likely most.
<pieq> I'll check then
<infinity> FWIW, the fix seems to work here.
<pieq> hm... I'm trying the steps described in comment #7 on a Dell precision device with pulseaudio 1:12.2-2ubuntu1 and it works
<pieq> so maybe it's related to Lenovo devices, not Dell
<pieq> jibel, infinity ^
<infinity> It's more than just Lenovo devices, but yeah, it won't be *all* devices.
<infinity> If you only have one sound device, things might accidentally work.
<infinity> Anyhow, I just tested again here, and it's happy.
<infinity> So if you can test that ubuntu3 doesn't regress that Dell, then we're good.
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (disco-proposed) [6.0.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (disco-proposed) [6.0.6-dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (disco-proposed) [6.0.6-1]
<seb128> saw bug #1824910, unsure if that ever worked/the drivers are supposed to be on the iso but I'm poiting it in case that's something to check
<ubot5`> bug 1824910 in ubuntu-drivers-common (Ubuntu) "ubuntu-drivers fail to install Nvidia divers without Internet connection in Lubuntu Disco Dingo" [Undecided,New] https://launchpad.net/bugs/1824910
<rbasak> seb128: looks like the importer hung a week ago :-/
<rbasak> I have plans to add a watchdog, but de-prioritised that when it seems more reliable.
<seb128> rbasak, oh, DOH :)
<rbasak> Looks like I need to bump the priority of adding that.
<seb128> (btw did you change channel on purpose? might interest people on the other one)
<rbasak> Oh, sorry
<infinity> LocutusOfBorg: Why did you drop amd64 from low mem arches in seqan2?
<infinity> seb128: We don't ship nvidia drivers on media, so...
<seb128> infinity, right, what I though, thx for confirming
<pieq> infinity, I checked and ubuntu3 works on the Dell Precision I have here
<infinity> pieq: Shiny.
<pieq> infinity, confirmed working on two different Dell devices (Precision and Latitude)
<infinity> Kay.
-queuebot:#ubuntu-release- Unapproved: dm-writeboost (bionic-proposed/universe) [2.2.8-1ubuntu3~18.04.1 => 2.2.8-1ubuntu3~18.04.2] (no packageset)
<LocutusOfBorg> infinity, looks like it builds fine with parallel=2, debian changed the else branch to take care of amd64?
<LocutusOfBorg> did I made a mistake?
<LocutusOfBorg> I tried in my ppa and it built correctly, only arm64 and ppc64el were sad
<infinity> LocutusOfBorg: I mean, that Debian change was there in Steve's too, but sure. :P
<infinity> LocutusOfBorg: If you tested it and it seems fine, whatevs.
-queuebot:#ubuntu-release- Unapproved: accepted seqan2 [source] (disco-proposed) [2.4.0+dfsg-11ubuntu1]
<LocutusOfBorg> the first person adding amd64 has been ginggs a couple of years ago https://launchpad.net/ubuntu/+source/seqan2/2.3.1+dfsg-3ubuntu1
<LocutusOfBorg> at that point there were no "else amd64 then parallel=2", but the default was the one on the machine
<LocutusOfBorg> I suspect amd64 has been copy-pasted in all merges without anybody trying to remove it
<LocutusOfBorg> I noticed an else switch and I preferred to use it and reduce the delta, I can't promise it will work forever, because you know the build might fail in a non-reproducible way (it is built ok in my ppa, but it might fail in a no-change rebuild due to different building parallelism or files)
<LocutusOfBorg> anyway, readding is quick in case it starts failing too much
<infinity> LocutusOfBorg: So the more interesting question is if we could move out "iffy" arches that we added to the parallel=2 case.
<infinity> LocutusOfBorg: But also don't care deeply.
<infinity> s/out/our/
<LocutusOfBorg> infinity, this sounds interesting, let me try in a ppa, having a build that takes 24 hours on armhf is sad
<infinity> Oh crap, I didn't look at that.  It takes 24h to build?
<LocutusOfBorg> but again, a newer toolchain might start failing because you know, memory increases everytime
<infinity> It might not make the release. :P
<infinity> We'll see.
<LocutusOfBorg>  Build started 21 hours ago on bos02-arm64-076 and finished 13 hours ago taking 7 hours 20 minutes â see the log
<LocutusOfBorg> well, I did make a mistake
<infinity> 7 hours, 24 hours, basically the same thing.
<LocutusOfBorg> lol
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa here the build with parallel=2 on arm64 and ppc64el
<LocutusOfBorg> infinity, FYI accepting golang-gopkg-sourcemap.v1 will make 3-4 golang packages unlock
<LocutusOfBorg> it failed because of internet access, I patched and opened an RC bug in debian
<LocutusOfBorg> I'm working only on leaf and non-seeded packages, FYI
<infinity> LocutusOfBorg: Disabling the entire testsuite seems like overkill.  Unless the whole testsuite uses the internet...
<LocutusOfBorg> ehm, considering the only test consists in "hey, lets do a query to jquery.org and see the result"... I don't think it is an overkill...
<LocutusOfBorg> https://salsa.debian.org/go-team/packages/golang-gopkg-sourcemap.v1/blob/debian/sid/example_test.go and consumer_test.go are doing internet communication
<LocutusOfBorg> there is a benchmark_test.go that might be useful, but I doubt it really is...
<LocutusOfBorg> here a build with internet access enabled, and disco baseline http://debomatic-amd64.debian.net/distribution#disco/golang-gopkg-sourcemap.v1/1.0.5-1build1/buildlog
<LocutusOfBorg> (btw autopkgtests are what really gives meaningful answers to this kind of "internet packages")
<infinity> LocutusOfBorg: Oh, if this testsuite runs as an autopkgtest, that's fine.
<infinity> But it doesn't. :P
<infinity> So, yeah, please don't suggest disabling testsuites without enabling them as autopkgtests instead.
-queuebot:#ubuntu-release- Unapproved: dkms (disco-proposed/main) [2.6.1-4ubuntu1 => 2.6.1-4ubuntu2] (ubuntu-desktop)
<LocutusOfBorg> yeah you right man! I saw the "autopkgtests" tab on debomatic... interesting
<LocutusOfBorg> anyway, Debian will fix properly then
<LocutusOfBorg> I don't want to loose time for a package that will go out from testing in one month, and we will just have the debian fix on next Ubuntu eventually
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927227 should start the autoremoval counter
<ubot5`> Debian bug 927227 in golang-gopkg-sourcemap.v1 "golang-gopkg-sourcemap.v1: attempts internet communication during build?" [Serious,Open]
-queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-sourcemap.v1 [source] (disco-proposed) [1.0.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-sourcemap.v1 [source] (disco-proposed) [1.0.5-1ubuntu1]
<xnox> infinity, paride - filed https://bugs.launchpad.net/qa-jenkins-jobs/+bug/1825156
<ubot5`> Ubuntu bug 1825156 in QA Jenkins Jobs "the results from server tests should use ISO Tracker API to push result good and bad result for every tested daily image" [Undecided,New]
<paride> xnox, thanks
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (disco-proposed/multiverse) [6.0.4-dfsg-7ubuntu19.04.1 => 6.0.6-dfsg-1ubuntu19.04.1] (no packageset)
<LocutusOfBorg> ^^ I forgot this one, fortunately it is not seeded
<ginggs> infinity LocutusOfBorg: debian limited max-parallel=2 on amd64 in seqan2 2.4.0+dfsg-3 - so dropping that part of the delta is correct
<LocutusOfBorg> yep! unfortunately while parallel=2 is good on ppc64el, it isn't on arm64 https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/16643928
<LocutusOfBorg> so, in order to have a reduced delta, better use parallel=1 on both...
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (disco-proposed) [6.0.6-dfsg-1ubuntu19.04.1]
<rbalint> sil2100, please reject gce-compute-image-packges from disco unapproved, i make it a bit prettier
<xnox> tobikoch, so, booting disco cloud image, with the seed that multipass uses, and it's all fine. so i suspect something is broken in multipass, and/or how it uses qemu options.
<xnox> (cause i tested the stuff in just /my/ way to launch vms)
<xnox> tobikoch, i suspect the disco cloud image is ok
<LocutusOfBorg> YAY with my ruby fixes ruby-gnome2 is now building!
<infinity> rbalint: Rejected.
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (disco-proposed) [20190315-0ubuntu1]
<tobikoch> xnox: kewl
<xnox> tobikoch, i have the answer
<tobikoch> :)
<xnox> tobikoch, they don't pass the cloud-config.iso correctly to qemu, hence the VM boots without a cloud-config.iso and well doesn't nothing.
<tobikoch> xnox: thanks for looking at that
<xnox> tobikoch, i bind-mounted qemu to be a `sleep infinity` and launched qemu-system-x86_64 by hand with -device ....config-drive.iso with -cdrom ....config-drive.iso and multipass "found" the vm and claimed it laucnhed successfully.
<xnox> (bind mounted into the snap)
<xnox> so multipassd launches the qemu VM broken.
<xnox> tobikoch, so i guess worth a multipass bug.
<xnox> tobikoch, also found other weird issues with qemu tooo....
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu4]
<vorlon> tobikoch: do you have any console logs or anything for that hung multipass?
<vorlon> oh, sounds like xnox has investigated
<vorlon> LocutusOfBorg: I certainly don't mind not being TIL on seqan2
<LocutusOfBorg> lovely thanks
<LocutusOfBorg> I just want some migration for what is still in proposed, and looks like we are mostly there for it
<LocutusOfBorg> vorlon, "ushare (- to 1.1a-0ubuntu11)" <-- kill it with fire?
<vorlon> LocutusOfBorg: should at least get a bug report first since it's an Ubuntu-specific package
<vorlon> oh, it has one
<vorlon> LP: #1818577 :P
<ubot5`> Launchpad bug 1818577 in ushare (Ubuntu) "Ubuntu-specific package; FTBFS, depends on obsolete libupnp6" [Critical,Triaged] https://launchpad.net/bugs/1818577
<xnox> apw, can we chat about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864 ?
<ubot5`> Ubuntu bug 1824864 in linux (Ubuntu Ee-series) "CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64" [Undecided,Confirmed]
<vorlon> LocutusOfBorg: ushare removed
<LocutusOfBorg> LOL wrt the bug author :)
<LocutusOfBorg> twice thanks!
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.3+git20190124-0ubuntu18.04.1 => 3.28.3+git20190124-0ubuntu18.04.2] (desktop-extra, ubuntu-desktop)
<LocutusOfBorg> where is the new iso spin done?
<LocutusOfBorg> *when
<infinity> LocutusOfBorg: There isn't one.  What made you think there was?
<LocutusOfBorg> it happens everytime, just one day before release, or the day of the release :)
<infinity> Don't jinx it.
<LocutusOfBorg> not my intention :)
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.2]
<LocutusOfBorg> I hope to see vbox 6.0.6 in the iso, and if it doesn't happen, not a problem, that is the reason for me asking if there is a spin ongoing
<vorlon> "in the iso"? has there been a seeded package accepted but not included in the last respin?
<infinity> It's not on any ISOs...
<infinity> LocutusOfBorg: Which ISOs were you expecting to see it on? :P
-queuebot:#ubuntu-release- Unapproved: tzdata (precise-proposed/main) [2016j-0ubuntu0.12.04 => 2019a-0ubuntu0.12.04] (core)
-queuebot:#ubuntu-release- Unapproved: rejected tzdata [source] (precise-proposed) [2019a-0ubuntu0.12.04]
<infinity> bdmurray: 1) Dangit, I was sure I did all of those updates two weeks ago.  I must have gotten sidetracked and never gone back. :(
<infinity> bdmurray: 2) precise goes through ESM, not the primary archive.  I can do that one.
<bdmurray> infinity: ah right, thanks
<LocutusOfBorg> mmm ok infinity
<LocutusOfBorg> I remember a while ago virtualbox-guest* included in the iso
<LocutusOfBorg> so probably now they are taken from the kernel...
<LocutusOfBorg> apw, ^^ sync them please on next kernel update?
<apw> sforshee, ^
-queuebot:#ubuntu-release- Unapproved: linux-ftpd-ssl (disco-proposed/universe) [0.17.36+0.3-2.1 => 0.17.36+0.3-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-ftpd (disco-proposed/universe) [0.17-36.1 => 0.17-36.1ubuntu1] (no packageset)
<LocutusOfBorg> btw I fixed two packages from proposed in the meanwhile ^^ the asneeded nightmare that will be ending soon (now that also debian is taking it)
<xnox> sil2100, ðð¥§
<xnox> sil2100, ðÏ
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2019a-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2019a-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2019a-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (cosmic-proposed) [2019a-0ubuntu0.18.10]
<infinity> bdmurray: Accepted, and uploaded a precise bump to esm-staging.
<sforshee> apw: methinks that is smb's problem now ;-)
<sforshee> but I can send a patch for it
<sforshee> LocutusOfBorg: can you file a bug agains the kernel for the vbox sync please?
<smb> sforshee, I have no problem in making it other peoples problem again. Whatever it is
<LocutusOfBorg> sure
<LocutusOfBorg> sforshee, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825210 assigned to you, so you can reassign to whoever you think is right :D
<ubot5`> Ubuntu bug 1825210 in linux (Ubuntu) "Please sync vbox modules from virtualbox 6.0.6 on next kernel update" [High,New]
<sforshee> ta
<LocutusOfBorg> thanks to you
<Wimpress> willcooke: Ho is the 19.04 desktop looking? Do you anticipate any respins?
<Laney> No
<willcooke> Wimpress, you are tempting fate there :)
 * Wimpress rubs a rabbits foots while standing a pentagram of rice
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (bionic-proposed) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (cosmic-proposed) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2]
<bdmurray> fossfreedom: thanks for cleaning up that budgie-desktop SRU
<sforshee> LocutusOfBorg: yikes, that's a lot of changes. Can you add some sru justification to the bug?
<sforshee> sigh, and they made a bunch of changes to the makefiles and broke our in-kernel build
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2 => 1.1.1b-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190124+dfsg1-0ubuntu1~18.04.0 => 20190315-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20190124+dfsg1-0ubuntu1~14.04.0 => 20190315-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (cosmic-proposed/main) [20190124+dfsg1-0ubuntu1~18.10.0 => 20190315-0ubuntu1~18.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190124+dfsg1-0ubuntu1~16.04.0 => 20190315-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190124+dfsg1-0ubuntu1 => 20190315-0ubuntu1] (core, ubuntu-cloud)
<rbalint> ^just for 0day and normal srus
<bdmurray> infinity: do you have plans to do the verification of tzdata or should I do it?
<infinity> bdmurray: I can tomorrow, or laaaaate tonight, but between now and then is some dinner out and about.
<vorlon> mwhudson: LP: #1819550 - actually, the reason it's still in Ubuntu is that Debian's unstable index is keeping golang-1.7 1.7.3-1 around, presumably because a Built-Using record somewhere that just won't die.  Do you want to chase those out in Debian? :)
<ubot5`> Launchpad bug 1819550 in golang-1.7 (Ubuntu) "please remove this package from ubuntu" [Undecided,New] https://launchpad.net/bugs/1819550
<infinity> bdmurray: If have to do the ESM one anyway, though, so I can do all of them.
<vorlon> mwhudson: looking at sid/amd64, I see docker-swarm, tendermint
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1030.32] (no packageset)
<vorlon> mwhudson: there are also 8 packages in disco that are Built-Using: golang-1.7, maybe we should rebuild those?
-queuebot:#ubuntu-release- Unapproved: openssl (disco-updates/main) [1.1.1b-1ubuntu2 => 1.1.1b-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1030.32]
-queuebot:#ubuntu-release- Unapproved: mono (disco-proposed/universe) [5.16.0.220+dfsg3-1ubuntu1 => 5.18.0.240+dfsg-2] (cli-mono, kubuntu) (sync)
<seb128> did we forgot to update ubiquity translations this cycle? looking on https://launchpad.net/ubuntu/+source/ubiquity/+changelog the most recent translations mention is for 18.10.10
<seb128> one translator was asking about 'when are the cycle translations going to be included' on https://lists.ubuntu.com/archives/ubuntu-translators/2019-April/007537.html
<seb128> respin material? ;)
-queuebot:#ubuntu-release- Unapproved: accepted mono [sync] (disco-proposed) [5.18.0.240+dfsg-2]
<vorlon> infinity, cyphermox: ^^ ?
<seb128> (it's probably not worth a respin but a bit of a shame if that was not done :/)
<vorlon> seems as though ubiquity translation updates should be an automatic part of the source package build
<cyphermox> right now it's not automated, it's a manual step to export translations from launchpad and import them. I don't know how to automate it for the uploads, but sure it should be looked into
-queuebot:#ubuntu-release- Unapproved: mono (disco-proposed/universe) [5.18.0.240+dfsg-2 => 5.18.0.240+dfsg-2ubuntu1] (cli-mono, kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted mono [source] (disco-proposed) [5.18.0.240+dfsg-2ubuntu1]
<vorlon> xnox: I tried to ditch gcc-5 by merging the new upstream version of mono which drops the s390x-specific build-dep; but apparently it now ftbfs in disco on s390x, both with or without the -O0 workaround patch
<mwhudson> vorlon: yeah we probably should
<xnox> vorlon, i am ok with shipping mono which is known to ftbfs and remove gcc-5
<vorlon> xnox: yet you are not an AA, so you can't pull the trigger ;)
<vorlon> and I am not planning to remove gcc-5 while mono in devel still build-depends on it
<xnox> vorlon, i am also ok to remove all of mono/s390x binaries.... if that can be done in a manner which doesn't increase uninstallable count or something ftbfs because it tries to compine mono bindings
<xnox> vorlon, i don't think .NET is huge on s390x
<xnox> mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb -> hmmm missing build-deps?!
<xnox> looks like mdoc / documentation fails to execute..... i wonder if it builds with docs disabled
<vorlon> reverse-depends src:mono -a s390x -> go fish
<vorlon> xnox: doesn't the gdb thing just mean it can't give you a better explanation /after/ the build has failed?
<vorlon> and mdoc was the bit that was crashing before, necessitating the Ubuntu patch
<xnox> vorlon, fedora claims it builds with (a) a patch (b) no-fpie => https://src.fedoraproject.org/rpms/mono/c/cb2069e8baa6814a1094b4ac700047ee42139f16?branch=master
<xnox> yeah, gdb is a nice to have when crashy crashy
<tjaalton> vorlon: hi, I assume you accepted intel-opencl-clang and -graphics-compiler? did you have a look at -compute-runtime? there was the issue of a binary blob used by some of the tests, wonder if that was a blocker or not..
<xnox> as found by reading https://github.com/mono/mono/issues/9009
<gitbot> mono issue 9009 in mono "[s390x] Fails to compile against recent glibc" [Area-Runtime: Jit, Os-Linux, Target-S390X, Closed]
<vorlon> tjaalton: I didn't get so far as to see if there was a binary blob; I have the source here for review, the licensecheck output was even more horrible than usual, so I didn't get through the review yet
<vorlon> tjaalton: still hoping to do it before the archive closes
<tjaalton> vorlon: yes, third_party/* is most of the horrible stuff I hope
<xnox> vorlon, ok, patch is already in debian cause can be reverse applied....
<tjaalton> it had some wildcard issues like the one you mentioned about i-g-c
<tjaalton> vorlon: anyway, thanks for having a look
<xnox> vorlon, https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/16646203
<xnox> still building.... and it's been longer.
<xnox> maybe it will finish in like 30min
-queuebot:#ubuntu-release- Unapproved: maas (disco-proposed/main) [2.5.0-7442-gdf68e30a5-0ubuntu1 => 2.6.0~beta1-7673-g850a92f90-0ubuntu1] (ubuntu-server)
<xnox> vorlon, it builds.... https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/16646203
<xnox> vorlon, uploaded into the queue for you to review/accept
-queuebot:#ubuntu-release- Unapproved: mono (disco-proposed/universe) [5.18.0.240+dfsg-2ubuntu1 => 5.18.0.240+dfsg-2ubuntu2] (cli-mono, kubuntu)
<vorlon> xnox: accepted, but now you get to defend to rbalint the decision to disable pie in mono ;)
-queuebot:#ubuntu-release- Unapproved: accepted mono [source] (disco-proposed) [5.18.0.240+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-ftpd [source] (disco-proposed) [0.17-36.1ubuntu1]
<bdmurray> I forget is the release notes link in ubiquity not supposed to work until after release?
<bdmurray> The url loaded was "https://wiki.ubuntu.com/Releases?os=ubuntu&ver=19.04&lang=en
#ubuntu-release 2019-04-18
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-sourcemap.v1 [source] (disco-proposed) [1.0.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-ftpd-ssl [source] (disco-proposed) [0.17.36+0.3-2.1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-gopkg-sourcemap.v1 [amd64] (disco-proposed/universe) [1.0.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-gopkg-sourcemap.v1 [amd64] (disco-proposed) [1.0.5-1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-robertkrimen-otto [amd64] (disco-proposed/universe) [0.0~git20180617.15f95af-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-robertkrimen-otto [amd64] (disco-proposed) [0.0~git20180617.15f95af-2]
<tsimonq2> xnox (cc vorlon): ack on the CSS changes.
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+7-1ubuntu1 => 11.0.3+7-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: golang-github-flynn-json5 [amd64] (disco-proposed/universe) [0.0~git20160717.7620272-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjdk-13 (disco-proposed/universe) [13~13-0ubunt1 => 13~17-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [source] (disco-proposed) [13~17-1]
-queuebot:#ubuntu-release- New: accepted golang-github-flynn-json5 [amd64] (disco-proposed) [0.0~git20160717.7620272-1]
<vorlon> tjaalton: intel-compute-runtime, note that this license should be labelled 'BSD-3-clause' in debian/copyright, not just 'BSD'
-queuebot:#ubuntu-release- New: accepted intel-compute-runtime [source] (disco-proposed) [19.13.12717-0ubuntu1]
<infinity> bdmurray: That's actually meant to be a redirect through ubuntu.com, which appears to have broken some time in the past.  I'll talk to the web team about it this morning.
-queuebot:#ubuntu-release- Unapproved: resolvconf (disco-proposed/universe) [1.79ubuntu12 => 1.79ubuntu13] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-compute-runtime [amd64] (disco-proposed/universe) [19.13.12717-0ubuntu1] (no packageset)
<tjaalton> vorlon: yes, fixed in git
<tjaalton> thanks!
-queuebot:#ubuntu-release- Unapproved: dde-qt-dbus-factory (disco-proposed/universe) [1.1.0-2 => 1.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted intel-compute-runtime [amd64] (disco-proposed) [19.13.12717-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (disco-proposed) [1.79ubuntu13]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Final] has been marked as ready
<acheronuk> morning. any issues cropped up demanding respins, or are we looking good over all?
<acheronuk> I'm assuming the later, as infin1ty just did block-all source
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Final] has been marked as ready
<acheronuk> infinity or anyone else who may know.. flavours such as Kubuntu supported 16.04 for 3 year, so do we get a EOL email sent out from Ubuntu, or does each flavour so their own. Plus where do we set the date? Exactly at the 3 year date? (e.g. 17th April for 16.04)
<acheronuk> April 21st I mean!
<acheronuk> also, there is some confusion about trusty eol date. 5 years would be 17th, but some sources (including a now removed statement on a Ubuntu blog) say 30th April
<infinity> acheronuk: https://lists.ubuntu.com/archives/ubuntu-announce/2019-March/000241.html <-- The official EOLish date
<infinity> acheronuk: As for the flavour 3y EOLs, no, I don't send notices for those.
<infinity> acheronuk: If you have flavour mailing lists and blogs, I'd suggest maybe mentioning it there, but I also expect flavour users to follow LTS to LTS, since that's what the 3y overlap is meant to facilitate.
<acheronuk> infinity: thanks. did not see that email
<acheronuk> on the overlap, yes, of course. some users are hard to shift onwards though ;)
<jibel> willcooke, infinity just finished netboot, unless you have something pending on your side, Ubuntu Desktop and netboot are good to ship for me.
<willcooke> jibel, woot. thanks!
<infinity> jibel: \o/
<sil2100> pi's look good as well
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Final] has been marked as ready
<willcooke> \o/ \o/ \o/
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Final] has been marked as ready
<bluesabre> high fives all around (and back to bed)
<sil2100> bluesabre: thanks o/
<luna> Ubuntu 19.04 Release party at TG LAN in Norway later tonight
-queuebot:#ubuntu-release- Unapproved: lighttpd (disco-proposed/universe) [1.4.53-3ubuntu1 => 1.4.53-4ubuntu1] (no packageset)
<LocutusOfBorg> CVE fixes ^^
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Final] has been marked as ready
<Laney> tsimonq2: might want to fix that lubuntu link in the release notes?
<tsimonq2> Laney: I assumed sil2100  would have done it. :P
<tsimonq2> I'll look.
<sil2100> No no no, I was only whipping about doing that
<tsimonq2> heh
<infinity> tsimonq2: Mark yourself ready too. :P
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Final] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted gedit [source] (disco-proposed) [3.32.0-3]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Final] has been marked as ready
<tsimonq2> infinity: .
<tsimonq2> I'll play with the wiki when I'm *not* on my phone. :P
<tsimonq2> Oh, nice. The wiki doesn't like me today.
<tsimonq2> The link is literally s/cosmic/disco/ with nothing else changed. Can someone please JFDI?
<tsimonq2> Laney, sil2100: ^
<Wimpress> tsimonq2: Are your RM for Lubuntu this release?
<acheronuk> tsimonq2: the wiki hates everyone today
<Laney> tsimonq2: ok, someone will need to make it not 404 then
<tsimonq2> Wimpress: I am by default, wxl had to fill in last cycle because I was deathly ill.
<tsimonq2> Laney: It'll stop 404ing when the ISOs come out. :P
<tsimonq2> Wimpress: (If I'm not around, wxl is my backup, and then it falls back to the Lubuntu Council.)
<tsimonq2> acheronuk: s/today/always/ :P
<tsimonq2> Oh, I actually see ISOs.
<acheronuk> tsimonq2: https://www.ubuntu.com/ says 19.04 is out. going to wait for the email still?
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Disco 19.04 | Archive: Closed | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<acheronuk> and instantly I sees infinity's email :)
<cjwatson> Well done
<ginggs> happy 19.04 everyone!
<tsimonq2> \o/
<tsimonq2> /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\
<tsimonq2> Congrats everyone!
<rbalint> \o/
<handsome_feng> \\\\0///
<gaughen> congrats all!
<mdeslaur> congrats!
<Eickmeyer> Congrats all!
<Ukikie> infinity: Congrats.
<sil2100> tsimonq2: I'm either on some unreliable network or the link to https://lubuntu.me/disco-released doesn't work ;)
<sil2100> tsimonq2: the announcement is out, I guess it's *time*
<LocutusOfBorg> do we have a codename for EE???
 * LocutusOfBorg is joking, just to be clear
<LocutusOfBorg> congrats everybody!
<cyphermox> LocutusOfBorg: Edgy Eft :)
<LocutusOfBorg> LOL
<LocutusOfBorg> for some seconds I took it seriously
<cyphermox> dead serious, only 13 years ago
<mdeslaur> Edgy Eft II
<LocutusOfBorg> http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
<LocutusOfBorg> for the first time, non canonical contributions are at the first place?
<Ukikie> LocutusOfBorg: One might notice https://lists.ubuntu.com/mailman/listinfo/Eoan-changes and https://launchpad.net/ubuntu/eoan
<infinity> Looks like that's been a trend for a couple of years.  I blame people who take over the job of autosync after we freeze and stop syncing. :P
<infinity> But also, Canonical contribution has obviously dropped off a bit since we dropped Unity.
<LocutusOfBorg> infinity, actually if you see the number of packages, haskell is probably to blame ;)
-queuebot:#ubuntu-release- Unapproved: kpatch (bionic-proposed/universe) [0.5.0-0ubuntu1 => 0.5.0-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xtables-addons (bionic-proposed/universe) [3.0-0.1ubuntu1 => 3.0-0.1ubuntu2] (no packageset)
<Odd_Bloke> Edgy Eft II: Electric Eoogaloo
<luna> http://releases.ubuntu.com/19.04/ubuntu-19.04-desktop-amd64.iso.torrent 0 day Ubuntu Linux warez
<LocutusOfBorg> but I think half of my effort is "syncing packages after pushing the delta to debian" and hopefully with gcc9 we will loose all our "wl-asneeded"
<LocutusOfBorg> is the archive open yet for eoan? :p
 * LocutusOfBorg wants to be the first to ask
<LocutusOfBorg> seriously, good job release team! its time to celebrate and party!
 * juliank moved up from 16th to 15th place
<juliank> this ubuntu-activity thing is fun
<juliank> but like a lot of the apt stuff I do is just synced
<juliank> :)
<infinity> juliank: Yeah, it doesn't record autosyncs, but if you beat the bot and sync yourself, it'll pick that up. :P
<infinity> At the end of the day, though, it's really just a way to see who does the most transitions.
<juliank> I mostly upload things so they are synced when I wake up the next day
<juliank> :)
<infinity> (And the Canonical/Community split is always an interesting non-metric)
<tsimonq2> sil2100: I would do it if I didn't have school to attend to. I'll publish during my lunch in a little more than two hours.
<LocutusOfBorg> infinity, I think we should remove the "buildN" uploads, we would have better results
 * infinity shrugs.
<LocutusOfBorg> (even if no change rebuilds with delta have "ubuntu" suffix)
<infinity> I don't think accuracy of results are really a goal.  Plus, "accuracy" changes depending on what you think it's meant to be measuring.
<tsimonq2> What is Eoan? Is it a misspelling of Eon?
<infinity> https://www.merriam-webster.com/dictionary/eoan
<LocutusOfBorg> what would happen if I propose to do only one release each year? do you have statistics of installation of LTS VS non-LTS releases?
<LocutusOfBorg> I think it might be time to relax a bit :D
<infinity> LocutusOfBorg: Releasing less often means longer freezes and bug-hunting periods.
<infinity> LocutusOfBorg: Releasing more often (or continuously, as some want) means never getting new features, because there's no time to fix bugs.
<infinity> LocutusOfBorg: 6mo feels like a sweet spot for a large OS-sized project.
<tsimonq2> infinity: Weird, a physical Merrium-Webster dictionary didn't have itm
<tsimonq2> *it.
<infinity> tsimonq2: Maybe Merriam would have, but your cheap knock-off Merrium didn't?
<tsimonq2> I don't know, it was a very large dictionary.
<tsimonq2> Â¯\_(ã)_/Â¯
<LocutusOfBorg> infinity, OTOH, who cares about installing something that will be thrown away in less than 9mo?
<infinity> LocutusOfBorg: Lots of people.
<tsimonq2> Anyway, as usual, once we have the noun, dibs on the wiki.
<LocutusOfBorg> ok, that was my request, do you have statistics?
<infinity> Not handy.
<LocutusOfBorg> ok :)
<infinity> Popularity definitely skews more toward LTS these days, but that's mostly due to cloud.
<LocutusOfBorg> it would be nice to compare LTS and non-LTS, to see how many are following the 6months releases
<LocutusOfBorg> infinity, that is my point, almost every people I know, are using LTS because of 5 years support
<tsimonq2> LocutusOfBorg: I heard LTS:non-LTS was 10:1. Don't quote me on that.
<LocutusOfBorg> with hwe LTS gained also new features
<infinity> tsimonq2: Stats like that count each cloud instance as an install, though, which is likely not a fair metric.
<tsimonq2> Fairn
<tsimonq2> *Fair.
<tsimonq2> (Typing on mobile.)
<tsimonq2> I do agree with infinity though.
<LocutusOfBorg> but do you agree that the sum of "new features" each release decreased in the last 10 years?
<LocutusOfBorg> I mean, ok I was probably a younger student 10 years ago, and students have lots of time to format the laptop
<infinity> I'm not sure I agree with that, no.
<infinity> We get a ton of churn.
<LocutusOfBorg> but meh, "updated kernel updated glib, updated gnome updated foobar", but nothing really heartbreaking
<infinity> And it's more each year.
<LocutusOfBorg> I don't think I got what you said
<Eickmeyer> Ubutnu Studio's update was huge. Our 25th release, and it was pretty feature-full.
<LocutusOfBorg> what is "churn?" :) -ENONATIVESPEAKER
<infinity> If by "new feature" you mean "holy crap, it suspends and resumes without crashing", sure, we get less of that, but that's because once you solve a problem like that, it's done.
<infinity> So, we're a bit more "boring" by virtue of the fact that we suck less.
<LocutusOfBorg> that is a fair point, but I mean like "hey we switched from gnome2 to gnome3" or something similar
<ginggs> was that a feature?
<LocutusOfBorg> :D
<infinity> LocutusOfBorg: "churn", constant movement of stuff.  Lots of changes.  More thousands of lines of code change per year now than 4 years ago or 8.
<LocutusOfBorg> infinity, of course code changes are big! but is end user experiencing something different at the end?
<tsimonq2> Instead of changing the release cycle, I would argue in 2019 you don't need 3 mo ths to upgrade if you're on the non-LTS anyway.
<tsimonq2> *months
<LocutusOfBorg> I mean, my bionic is stable, I never had to think wrt moving to cosmic or disco
<infinity> LocutusOfBorg: End user experience doesn't define our workload.
<LocutusOfBorg> maybe end user installation might define it a little bit, if we discover nobody is installing non-LTS because of $reasons...
<infinity> LocutusOfBorg: The bottom line is that lots of changed code means lots of work keeping it integrated.  The longer you allow unfettered churn, the longer you have to stop to fix it all.
<LocutusOfBorg> but less releases means also less SRUs
<infinity> LocutusOfBorg: Our freezes are much less painful than Debian's, and it's not because we're somehow more awesom, it's because we're dealing with smaller chunks of destabilisation.
<LocutusOfBorg> actually just to point my little experience, I discovered today I fixed a java11 issue in virtualbox in bionic, and I completely forgot about cosmic
<LocutusOfBorg> because 1) I wasn't aware of java11 going in cosmic 2) nobody pointed it out, so I forgot about it
<LocutusOfBorg> my guess is that I'm not the only one who in terms of fixing stable bugs has a tendency to consider only LTS and LTS-1 instead of everything else
<cjwatson> You're not, but I think that's OK - we don't have to fix everything
-queuebot:#ubuntu-release- Packageset: 6787 entries have been added or removed
<LocutusOfBorg> (not something I do on purpose!)
-queuebot:#ubuntu-release- Unapproved: gedit (disco-updates/main) [3.32.0-3 => 3.32.0-3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gedit [sync] (disco-updates) [3.32.0-3]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (eoan-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
<LocutusOfBorg> oh.... so you are already ready for eoan? surprising
<infinity> LocutusOfBorg: No.
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (eoan-proposed) [0.39ubuntu2]
<LocutusOfBorg> of course you aren't yet, but the work started quickly on that cicle
<LocutusOfBorg> *cycle
<Laney> It can start once we get the name, which happened in time this cycle.
-queuebot:#ubuntu-release- Unapproved: distro-info-data (eoan-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
<teward> *hands the Release Team beers*
 * Eickmeyer sends teward a quad-shot venti latte
 * teward absorbs through osmosis
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.11 => 0.18ubuntu0.12] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.37ubuntu0.3 => 0.37ubuntu0.4] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (disco-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (cosmic-proposed/main) [0.38ubuntu0.2 => 0.38ubuntu0.3] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.10 => 0.28ubuntu0.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (disco-proposed) [0.39ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (cosmic-proposed) [0.38ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (bionic-proposed) [0.37ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.11]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.12]
<tsimonq2> Nice, Eanimals are cool. Is that Australian? :P
<sil2100> I don't know, I'm not very knowledgable in animals! Especially e-animals
<sil2100> Electronic-animals
<sil2100> hm
<sil2100> Bionic animals?
<tsimonq2> XD
<vorlon> congrats, all!
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (eoan-proposed) [0.39ubuntu2]
<acheronuk> infinity: perhaps an impossible things to estimate, but do you have an ETA on updating the metadata to turn do-release-upgrades on?
<acheronuk> if not, then fine :)
<infinity> bdmurray: ^
<bdmurray> infinity: Do you want me to give an estimage? ;-)
<infinity> bdmurray: Sure. :)
<infinity> bdmurray: Or if you're not aware of any upgrade showstoppers, do the thing.
 * infinity needs to lie down for a bit to let these drugs clear his sinuses.
<bdmurray> infinity: I'm not aware of any because either nobody tests or its perfect
<bdmurray> acheronuk: real soon now maybe an hour at most
<acheronuk> bdmurray: I know in recent times it has been a few days. if we look like going sooner, I won't complain
<acheronuk> bdmurray: people have been asking, and all I have been able to do is cite past examples
<bdmurray> acheronuk: what release did we wait days? I'm not remembering one immediately
<acheronuk> bdmurray: I don't recall. the memory is insistent on the fact, but could be mistaken I guess
<acheronuk> something like release on Thurs but meta not updated until Monday
<acheronuk> honesly, I don't care if that memory or normal procedure is wrong. :)
<bdmurray> well if you are repeating it and its wrong...
<acheronuk> I did say it could be hrs to a few days, depending...
<acheronuk> point being that as said, only done if it seems no showstoppers. which I can only hedge bets on
<bdmurray> okay for bionic we did wait a couple of days
<bdmurray> https://bazaar.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu/revision/208#meta-release
<acheronuk> fair enough
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu0.14.04.2 => 10ubuntu0.14.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (bionic-proposed) [7.5.0+18.04.20190304-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (xenial-proposed) [7.4.5+16.04.20190312-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (trusty-proposed) [10ubuntu0.14.04.3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu0.14.04.2 => 10ubuntu0.14.04.3] (no packageset)
<ahasenack> vorlon: ^
<valorie> Thank you release team!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [10ubuntu0.14.04.3]
<tsimonq2> infinity, vorlon: Can I please get your AA hat opinion? https://github.com/lxqt/libfm-qt/issues/370#issuecomment-484671222
<gitbot> lxqt issue 370 in libfm-qt "Licensing question" [Closed]
<vorlon> tsimonq2: can you phrase that in the form of a question rather than a link to a nondescript comment in a github issue? :)
<tsimonq2> vorlon: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927380 two files were released with the wrong license.
<ubot5`> Debian bug 927380 in release.debian.org "unblock: libfm-qt/0.14.1-5" [Normal,Open]
<vorlon> that's still not a question
<tsimonq2> What is the appropriate action here?
<vorlon> merge the new version when Ergonomic opens?
<tsimonq2> Patch the source, or call it good since upstream explicitly patched it?
<tsimonq2> For Disco.
<vorlon> there are plenty of upstream license statements in source tarballs that are incorrect
<tsimonq2> That's the answer then, thanks!
<vorlon> we don't need to do extra work to make the upstream license statements match reality :)
<tsimonq2> Makes sense, just confirming :)
<vorlon> and AIUI the upstream fix was to correct the license statement to LGPL, in which case debian/copyright happened to already be accuarte
-queuebot:#ubuntu-release- Unapproved: dde-qt-dbus-factory (eoan-proposed/universe) [1.1.0-2 => 1.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected dde-qt-dbus-factory [source] (disco-proposed) [1.1.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2]
<tsimonq2> Ahh, got it
#ubuntu-release 2019-04-19
-queuebot:#ubuntu-release- Unapproved: rejected lighttpd [source] (disco-proposed) [1.4.53-4ubuntu1]
<infinity> Laney: Should I be concerned that I don't see eoan results at http://autopkgtest.ubuntu.com/packages/glibc yet?
-queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.1ubuntu9 => 10.1ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (eoan-proposed) [10.1ubuntu10]
-queuebot:#ubuntu-release- Unapproved: devscripts (eoan-proposed/main) [2.19.4 => 2.19.4build1] (core)
<tsimonq2> infinity: Two packages incoming to Eoan that are important but were forgotten last cycle (so I did them). devscripts needs a no-change rebuild to recognize Eoan as the current development release, and a patch needs to be made to Lintian to not complain when it's the release in debian/changelog.
<tsimonq2> Merge request in Lintian upstream: https://salsa.debian.org/lintian/lintian/merge_requests/198
<gitbot> lintian issue (Merge request) 198 in lintian "Add "eoan" as a known Ubuntu distribution." [Opened]
<tsimonq2> Both are small changes which I would argue are appropriate for this stage of the cycle.
-queuebot:#ubuntu-release- Unapproved: lintian (eoan-proposed/main) [2.12.0 => 2.12.0ubuntu1] (core)
<vorlon> infinity, Laney: I think http://autopkgtest.ubuntu.com/packages/glibc is #15 on https://wiki.ubuntu.com/NewReleaseCycleProcess which doesn't appear to have been done, so I'm running this now
<vorlon> except that part of https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Opening_up_a_new_series was definitely done, but I didn't find seed-new-release in the wendigo shell history
<tsimonq2> infinity: Oh, so those two are on the checklist. Regardless, they were forgotten last cycle, if I recall correctly. :)
<bdmurray> vorlon: If you have a moment https://code.launchpad.net/~brian-murray/apport/dp-and-eoan/+merge/366319
<vorlon> infinity, Laney: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Opening_up_a_new_series done now, but http://autopkgtest.ubuntu.com/packages/g/glibc still doesn't show eoan, I'm not sure how long that takes to show up
<vorlon> I am particularly unclear on the relationship between the autopkgtest.db on wendigo vs the one on the web unit
<vorlon> bdmurray: done
<vorlon> Laney, infinity: ok, I've upgraded distro-info-data on the web runner, I think that might've been the missing piece
<tsimonq2> vorlon: (I did notice it hadn't migrated yet, which is surely a result of Britney not being set up yet?)
<infinity> tsimonq2: Yes, britney isn't running yet, I'm getting to that now.
<infinity> vorlon: I still don't see eoan results or queues. :/
<infinity> (for autopkgtest)
<tsimonq2> infinity: Right, 'tis why I didn't want to make too big of a deal about it. :)
-queuebot:#ubuntu-release- Builds: 28 entries have been added, updated or disabled
<vorlon> infinity: the batch import of eoan results to the db is still running now
<infinity> vorlon: Ahh, I misinterpreted the distro-info-data-only-missing-piece bit.
<vorlon> infinity: the wendigo step does the swift hankey-pankey, then I had to tell the web runner eoan exists, now it's building the db
<infinity> Check.
<infinity> Might want to clarify that step (or make it 2 or 3) on the checklist for the next times soneone !Laney has to do it.
<vorlon> infinity: the checklist now links to the actual instructions on the other wiki page instead of just invoking Laney's name, and I've refined them into something I may or may not be able to follow
<infinity> Shiny.
<infinity> vorlon: Can you skip ahead in the checklist and see if you can do anything about #36, so when I branch livefses, there's a hope that images might build?
<infinity> I fear all the people who can deal with the desktop snaps might be AFK until Tuesday, but here's hoping.
<vorlon> kenvandine: ^^ are you around and able to open&close the 19.10 channels for the desktop snaps?
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16 => 1:19.04.16.1] (core)
<bdmurray> vorlon: ^ test case added for that
<infinity> vorlon: So, I know the store isn't down with teams, but there are "collaborators" or whatever.  Maybe we should make it a requirement that some subset of AAs be added as collaborators for all seeded snaps, then it can be a one-stop-shop on opening to run a script (hand-wavy) that scrapes seeded-snaps and twiddles channels.
<vorlon> bdmurray: ^postgresql-.*[0-9][0-9].* only matches if there are 2 digits in a row.  Is that your intent?
<infinity> vorlon: Not that I'm in a rush or impatient, I don't actually care if images build until Tuesday, it's just nice to not have the process hinge on "ping 7 different people and hope".
<vorlon> infinity: <nod>
<bdmurray> vorlon: Yes. Am I missing something?
<vorlon> bdmurray: it means the regexp no longer matches earlier versions of postgres packages from prior releases, and I'm not sure if that's ok / intended
<infinity> He added a regex, not replaced.
<bdmurray> that's true
<vorlon> right
<infinity> But indeed, it could have been collapsed into one.
<vorlon> missed that it was an add, ok
<infinity> ^postgresql-.*[0-9]+\.[0-9].*
<vorlon> infinity: that would still not match
<infinity> Or ^postgresql-.*[0-9]\.[0-9]+.*
<infinity> Err.
<infinity> Or ^postgresql-.*[0-9]+\.[0-9]+.*
<bdmurray> see this is why I added a line
<vorlon> none of those match the new
<vorlon> :)
<bdmurray> its Friday y'all
<infinity> Oh, the new doesn't have minor versions?
<vorlon> correct
<vorlon> ^postgresql-.*[0-9][0-9.].*
<vorlon> but no matter
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.1]
<bdmurray> Okay, here's the deal I was forward thinking to the day someone wants to remove the minor version line.
<infinity> ;)
<infinity> Even if that's not true, I'm down with pretending it is.
<infinity> bdmurray: Oh, while you're in release-upgrader mode, wanna slap together an eoan upload?
<infinity> Also, please add an intro screen to u-r-u with a pronounciation guide.
<bdmurray> infinity: maybe, I wasn't too keen on it since the animal name really appears in it.
<vorlon> on eoaupload
<infinity> bdmurray: Yeah, I'm consistent in my EANIMAL usage everywhere, so it's a simple regex replace to clean them all later, but totally understood if you'd prefer to wait for a bit.
<infinity> bdmurray: I'm sure Mark will have an animal selected sometime before October.
<infinity> (Honestly, I'd be okay with running with EANIMAL for the release, it's a good nerd joke)
<tsimonq2> infinity: When we did that last release for +/- a few weeks, some media outlets actually thought it was legit. :P
<infinity> tsimonq2: Some media outlets are staffed with nitwits.
<infinity> tsimonq2: I'm okay with that result.
<tsimonq2> infinity: Right, it makes that fact obvious when they do stuff like that. :P
<vorlon> infinity: tada http://autopkgtest.ubuntu.com/packages/g/glibc
<infinity> I thought the not-so-subtle bit where I had it in all caps was a solid indicator that it was a placeholder.
<infinity> On the other hand, with EANIMAL, that's much less obvious to a nerd who would see it as an errno. :)
-queuebot:#ubuntu-release- Unapproved: pastebinit (eoan-proposed/main) [1.5-2 => 1.5-2.1] (core) (sync)
<infinity> vorlon: Yay.  http://autopkgtest.ubuntu.com/running 500s, though.
<tsimonq2> I still think it should be Eagle, 'cause something something "'MURICA!", but what do I know.
<infinity> I've got good money on Ermine.
-queuebot:#ubuntu-release- Unapproved: pastebinit (disco-proposed/main) [1.5-2 => 1.5-2.1~ubuntu0.19.04.1] (core)
<tsimonq2> If Mark was American, I'm willing to bet it would have been "Electric Eagle". Heh.
<infinity> I'm also disappointed we didn't just go with Ermine Ermine.  Not that ermine is in the dictionary as an adjective, but I'm sure I've seen it informally used as one.
<vorlon> .qcy
<tsimonq2> Hah.
<infinity> Porcine Porcupine would also be a good one.
<bdmurray> I'm surprised my kid hasn't called me Ermine.
<tsimonq2> infinity: I guess I should mention that my pastebinit sync to Eoan was to satisfy the usual mantra of "devel version shouldn't be newer than stable". Reject or approve as you'd like.
<tsimonq2> Er, switch devel and stable in that statement.
<tsimonq2> infinity: I agree.
<infinity> bdmurray: Are you soft and fuzzy?
<bdmurray> infinity: I was looking at urban dictionary
<vorlon> amqplib.client_0_8.exceptions.AMQPChannelException: (404, "NOT_FOUND - no queue 'debci-eoan-armhf' in vhost '/'", (60, 70), 'Channel.basic_get')
<infinity> bdmurray: Oh, that's not as bad as I expected when you said "urban dictionary".
<bdmurray> yeah, that's tame!
<tsimonq2> "Last updated December 01, 2013" yeah, about right.
<vorlon> infinity: so https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Opening_up_a_new_series does mention having to check for ~ubuntu-archive/proposed-migration/code/b2/britney.conf.ubuntu.$series but I wonder if britney needs to also run to create the queue
<vorlon> or if I have to go figure out how to do that
<infinity> vorlon: I *think* the queue is meant to exist before the first britney run, but I could be wrong.
<infinity> vorlon: Probably no real harm in me getting britney ready and doing a run to find out.  Worst case, I have to delete the pending json and try harder.
<vorlon> infinity: well, I don't see anything on the autopkgtest side that creates the queues
<infinity> vorlon: Alright, I'll get all the reports going shortly, then.
<bdmurray> vorlon: bug 1825563 has been verified
<ubot5`> bug 1825563 in ubuntu-release-upgrader (Ubuntu) "automatically removed packages includes postgresql-10 which can result in cluster dropping" [High,In progress] https://launchpad.net/bugs/1825563
#ubuntu-release 2019-04-20
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (eoan-proposed/universe) [19.04.1 => 19.10.1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (eoan-proposed/universe) [1:19.04.4 => 1:19.10.1] (lubuntu)
<infinity> vorlon: Alright, archive-reports running.  Fingers very crossed.
<infinity> No matter how many times I do this, I'm about 378% sure I'll miss something *this* time.
<infinity> Well, it works for disco.
<infinity> eoan didn't trigger because no archive change and no pending tests.  Fugding that for now with an accept.
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (eoan-proposed) [2.19.4build1]
<infinity> And britney now running for eoan.  Crossing more fingers.
<infinity> So many fingers.
<tsimonq2> infinity: Maybe you should accept more packages so Britney likes you more. :P
 * tsimonq2 runs
<infinity> tsimonq2: Do they teach patience in that high school of yours?
<tsimonq2> XD
<infinity> Hrm.  I think I need new glasses.
<infinity> I know you typed XD.  I saw XD.  Then I got up, walked 8 feet away, looked back, and read NO, and thought "is he sassin' me?"
<infinity> Perhaps new glasses and a longer memory.
<infinity> Not sure the latter is for sale, though.
<tsimonq2> HAHAHA :)
<infinity> vorlon: Okay, so http://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html should have triggered some tests.
<infinity> vorlon: /running/ still fails to render, which is disconcerting.
<infinity> Hrm, also, some of the update_excuses bits don't exist for eoan.  _by_team* and .csv ... Are those done externally?
<tsimonq2> infinity: It's probably on cron, and assuming it's set to a non-release-specific yaml file, should be updated Eventually. Reference: https://git.launchpad.net/~ubuntu-dev/+git/pm-stats/tree/generate-team.py#n194
<tsimonq2> Except, hrm, maybe it is by release. Cosmic has it...
<infinity> Oh, there they are.
<infinity> Guess it happens later.
<infinity> And eoan added to madison.
<infinity> vorlon: Yeah, I'm about 98% sure you have no eoan queues still, so britney didn't magically make them for you.
<infinity> +Description: move away from deprecated platform functions
<infinity> + The linux_distribution function from the platform has been deprecated in
<infinity> + Python 3.5. `distro` is the natural sucessor, however it is a new dependency.
<infinity> tsimonq2: How is this meant to work without any changes to debian/control?
<infinity> tsimonq2: I'd expect something to pull in python3-distro, no?
<tsimonq2> infinity: Now I'm confused as to why this doesn't pull in python3-distro, I'm pretty sure I added that. O_O
<infinity> I see it neither in build-depends (if the build system auto-detects deps, that might be enough) nor depends (if it doesn't).
<tsimonq2> infinity: You are correct though, please reject from Disco and Eoan. I'll do another NMU in Debian and sync when that's ready + re-upload to Disco.
<infinity> And not shockingly, your built binaries in Debian don't depend on it.
<tsimonq2> The maintainer in Debian did ragequit, and I do have an Intent to Salvage open, so I'm not concerned with any potential ramifications of 0-day NMUing, especially because he didn't care about the last one and it's fixing a mistake.
-queuebot:#ubuntu-release- Unapproved: rejected pastebinit [source] (disco-proposed) [1.5-2.1~ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected pastebinit [sync] (eoan-proposed) [1.5-2.1]
<tsimonq2> Aww man, I even caught it in the middle of a dinstall. Now it'll be a 6+ hour wait before I can syncpackage again. Oh well.
<tsimonq2> It doesn't stop me from uploading to Disco though. :P
<infinity> tsimonq2: You also might want to consider joining https://launchpad.net/~pastebinit-developers/+members
<infinity> (which owns the upstream code)
<tsimonq2> stgraber: ^
<infinity> Oh, it's moved to github now, apparently.
<tsimonq2> (It's not an open team.)
<tsimonq2> Probably, since Rolf maintained all of his packages there.
<infinity> Oh, maybe it's just the Debian packaging to moved to github.
<infinity> Nevermind.
<infinity> LP is still upstream.
<tsimonq2> I would like to add support for Phabricator, and clean up code where possible.
<infinity> vorlon: Okay, wat?
<infinity> vorlon: There must be eoan queues, cause some of my eoan tests actually happened.
<infinity> vorlon: But /running/ is still not rendering, so.. Whee?
<tsimonq2> infinity: That Disco upload should contain much python3-distro.
-queuebot:#ubuntu-release- Unapproved: pastebinit (disco-proposed/main) [1.5-2 => 1.5-2.2ubuntu~0.19.04.1] (core)
<tsimonq2> infinity: (I *can* fakesync it to Eoan, but I've heard that's not best practice. :P)
<infinity> tsimonq2: Did you upload to Debian?
<tsimonq2> Yeah.
<tsimonq2> It'll be at least another hour before it even recognizes it though, because dinstall is running. :P
<infinity> tsimonq2: Still have all the original bits?
<tsimonq2> Yes.
<tsimonq2> $ debdiff pastebinit_1.5-2.1.dsc pastebinit_1.5-2.2.dsc | pastebinit
<tsimonq2> /usr/bin/pastebinit:42: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
<tsimonq2>   release = platform.linux_distribution()[0].lower()
<tsimonq2> /usr/bin/pastebinit:413: DeprecationWarning: pasteURLopener style of invoking requests is deprecated. Use newer urlopen functions/methods
<tsimonq2>   url_opener = pasteURLopener()
<tsimonq2> http://paste.ubuntu.com/p/Pfx8MZ2dm4/
<tsimonq2> So meta.
<infinity> tsimonq2: sed -i -e 's/Distribution: unstable/Distribution: disco/' foo.changes, debsign foo.changes, answer "yes" to "keep signature for .dsc", and Bob's your uncle.
<infinity> That's almost literally what a real sync is, so no "fake" involved.
<kenvandine> vorlon: i've opened and closed stable/ubuntu-19-10 for all the seeded desktop snaps
<infinity> (ie: byte-identical orig, diff, and dsc, new changes)
<tsimonq2> I assume you mean eoan, but will do.
<infinity> Err, yeah.
<tsimonq2> gpg.errors.BadSignatures: E27F2CF8458C2FA4: Bad signature
<tsimonq2> Fun.
<tsimonq2> Resigning works, so wat?
<infinity> tsimonq2: Does your text editor trim whitespace at the end of lines without your consent?
<tsimonq2> It's Vim, perhaps.
<infinity> That upload changed a package description. :P
-queuebot:#ubuntu-release- Unapproved: pastebinit (eoan-proposed/main) [1.5-2 => 1.5-2.2] (core)
<tsimonq2> Oh, well that bit is also in Debian. :P
<infinity> (I mean, just by trimming whitespace, but still, poor form for an NMU)
<tsimonq2> It didn't do it automatically, I did it.
<infinity> Oh.
<infinity> Very poor form, then.
<tsimonq2> If I wasn't 95% sure I'll be maintaining the package soon, I would completely agree. :P
<tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927231
<ubot5`> Debian bug 927231 in pastebinit "ITS: pastebinit -- command-line pastebin client" [Important,Open]
<infinity> vorlon: Also guessing from the state of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html that Laney didn't set up armhf/lxd madness.
<tsimonq2> infinity: I will admit that at first I thought you were referring to the newline at the end of the file. I can read, I promise.
<infinity> tsimonq2: *smirk*
<infinity> 20:16 < tsimonq2> Resigning works, so wat?
<infinity> tsimonq2: Wait, did you re-sign .dsc?
<tsimonq2> infinity: Yes, I did. dput threw the aforementioned GPG error when I tried to upload it otherwise.
<infinity> Well, then, that's no longer a sync.
<infinity> That error was almost certainly for .changes
<tsimonq2> It's a fakesync. :P
<infinity> You get prompted twice (reuse signature on changes, reuse on dsc)
<infinity> Obviously, you have to re-sign changes if you modify it.
<tsimonq2> https://paste.ubuntu.com/p/J7jdrdJYGj/
<infinity> Right, the bit where you answer "no" three times, should have been "no, yes, yes".
<infinity> I'll just steal it from incoming in a bit.
<tsimonq2> Well, I'm willing to bet that I can just SSH to the machine and grab my files. I did read the other day that you can upload to Debian via SSH, so I'm curious now.
<infinity> (And yes, not a big deal, but if the files match exactly, then you get the "1.2.3-4.5 (Debian)" tihng all over LP where it magically knows that A is B.
<tsimonq2> (I was going to ask but assumed it was some LP bookkeeping.)
<tsimonq2> Packages can also be uploaded via ssh to ssh.upload.debian.org; files should be put /srv/upload.debian.org/UploadQueue. This queue does not support delayed uploads.
<tsimonq2> Ooh.
<infinity> It'll be in http://incoming.debian.org/debian-buildd/pool/main/p/pastebinit/ shortly.  *shrug*
<tsimonq2> Yeah, I was curious though. My pastebinit upload *isn't* in /srv/upload.debian.org/UploadQueue on that machine.
<infinity> I wish I had thought to buy food before I decided it would be fun to pull an all-nighter before my flight.
<infinity> THis part of London is completely dead past 1am.
<tsimonq2> I heard in Europe that you can't go to a fast food restaurant at 3 AM and it makes me kinda sad.
<infinity> Europe's a large place.
<infinity> That's very not true some places.
<infinity> There are plenty of 24h McD's here, just not right by my hotel.
<infinity> Also, I want food, not regret.
<infinity> There might be a shop a few blocks over with... Something.  I'll be back in 10 if I don't get stabbed.
<tsimonq2> Have fun.
<tsimonq2> Oh, lookie: https://incoming.debian.org/debian-buildd/pool/main/p/pastebinit/pastebinit_1.5-2.2.dsc
<Ukikie> < tsimonq2> I would like to add support for Phabricator, and clean up code where possible. <<< Doesn't `arcanist` already have that feature?
<tsimonq2> Ukikie: Yeah, it was more of an example, though.
<tsimonq2> infinity: Here, catch. (Proper files in the queue.)
-queuebot:#ubuntu-release- Unapproved: pastebinit (eoan-proposed/main) [1.5-2 => 1.5-2.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected pastebinit [source] (eoan-proposed) [1.5-2.2]
-queuebot:#ubuntu-release- Unapproved: accepted pastebinit [source] (eoan-proposed) [1.5-2.2]
<tsimonq2> I was going to say, "what'd I do?" :P
<Ukikie> Hmm, I had flashes of you thinking depending on python3-phabricator would be fine, good to see that's incorrect.
<tsimonq2> Oh?
<tsimonq2> infinity: Do you plan on reviewing the Disco upload as well, or are you on your way home soonish
<tsimonq2> *soonish?
-queuebot:#ubuntu-release- Unapproved: openjdk-13 (eoan-proposed/universe) [13~17-1 => 13~17-2] (no packageset) (sync)
 * tsimonq2 goes to bed.
<vorlon> infinity: oh, indeed it seems to be /specifically/ armhf that's missing queues, not all of them, so let me see if there was something else I missed wrt the container runner
<vorlon> kenvandine: thanks!
<vorlon> infinity: tada; pkill -HUP worker on the lxd master
<vorlon> (which is documented as part of worker administration but not specifically in the new series stuff)
<kenvandine> vorlon: glad to see ee is open
<valorie> "open"
-queuebot:#ubuntu-release- Unapproved: accepted lintian [source] (eoan-proposed) [2.12.0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [sync] (eoan-proposed) [13~17-2]
-queuebot:#ubuntu-release- Unapproved: gcc-9 (eoan-proposed/main) [9-20190402-1ubuntu1 => 9-20190420-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (eoan-proposed) [9-20190420-1ubuntu1]
<infinity> vorlon: cdimage builds should be good to go once you do the db@limequat setup (number 40), and once snaps are sorted, for images with snaps.
<infinity> vorlon: Heading to LHR now, I'll double-check everything when I land, enumerate what bits of the checklist are still pending, and probably start up auto-sync then.
<tsimonq2> I went to create an eoan schroot but found that debootstrap didn't have the script yet; uploaded to Eoan (to scratch my own itch).
<tsimonq2> (I was also the last uploader, so there's that.)
-queuebot:#ubuntu-release- Unapproved: debootstrap (eoan-proposed/main) [1.0.112ubuntu1 => 1.0.114ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: vim (eoan-proposed/main) [2:8.1.0320-1ubuntu3 => 2:8.1.0320-1ubuntu4] (core)
<tsimonq2> ^ that was also annoying, but that should be it (for now).
<vorlon> infinity: limequat done; and Ken said he already took care of the snaps for the desktop side
-queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3.3 => 18.01-0ubuntu3.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (disco-proposed/main) [18.01-0ubuntu7 => 18.01-0ubuntu7.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (cosmic-proposed/main) [18.01-0ubuntu4.2 => 18.01-0ubuntu4.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (eoan-proposed/main) [18.01-0ubuntu7 => 18.01-0ubuntu8] (ubuntu-server)
<tsimonq2> vorlon: I'm going through the sponsorship queue and I came across bug 1798955. Is there a process for source NEW via SRU? How would you recommend I respond to the reporter in this case?
<ubot5`> bug 1798955 in gnome-subtitles (Ubuntu Bionic) "Sync Request: gnome-subtitles-1.4.1 from Debian testing to Ubuntu bionic and xenial" [Wishlist,New] https://launchpad.net/bugs/1798955
<vorlon> tsimonq2: I would regard that as a wontfix
<vorlon> and perhaps refer them to snaps
<vorlon> we only add new packages to stable releases when required in exceptional cases for the product
<tsimonq2> Alright, thanks.
<vorlon> (such as the openjdk-lts exception that was agreed before bionic released; or for hardware enablement; or recently, for backports of python libraries needed for the new client application to enable ESM on trusty)
<tsimonq2> Right.
-queuebot:#ubuntu-release- Unapproved: subversion (xenial-proposed/main) [1.9.3-2ubuntu1.1 => 1.9.3-2ubuntu1.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: fbxkb (eoan-proposed/primary) [0.6-2]
-queuebot:#ubuntu-release- Unapproved: pam (xenial-proposed/main) [1.1.8-3.2ubuntu2.1 => 1.1.8-3.2ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: ppp (eoan-proposed/main) [2.4.7-2+4.1ubuntu1 => 2.4.7-2+4.1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: cryfs (bionic-proposed/universe) [0.9.9-1ubuntu1 => 0.9.10-1~ubuntu0.18.04.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (bionic-proposed/universe) [1.6.0-3 => 1.6.0-3ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (cosmic-proposed/universe) [1.6.0-3 => 1.6.0-3ubuntu0.18.10.1] (lubuntu, ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (disco-proposed/universe) [1.6.0-3 => 1.6.0-3ubuntu0.19.04.1] (ubuntu-mate)
<foka> Hi!  Could you please help me check why hugo is stuck at 0.52-1 in disco?  And is it too late to have hugo updated in disco?  Many thanks!
<tsimonq2> foka: Hi! Let me take a look.
<tsimonq2> https://launchpad.net/ubuntu/+source/hugo/0.54.0-1
<tsimonq2> All of the builds are waiting on a newer version of golang-any.
<tsimonq2> foka: Aha, looks like it wasn't synced past Ubuntu's Debian Import Freeze.
<tsimonq2> Wait, that isn't right...
<tsimonq2> Ohh, that's because it has an Ubuntu delta.
<foka> tsimonq2: Many thanks for your investigation!
<tsimonq2> foka: Unfortunately it's too late to get the new release in Disco. If there's specific fixes, you can go through the Ubuntu Stable Release Update process: http://wiki.ubuntu.com/StableReleaseUpdates
<tsimonq2> No problem. :)
<tsimonq2> foka: For future reference, you might want to bookmark this link: https://wiki.ubuntu.com/ProposedMigration
<foka> tsimonq2: "Ohh, that's because it has an Ubuntu delta" -- Is that Ubuntu delta in golang-any or in Hugo?
<tsimonq2> foka: I found out what the problem was by going here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#hugo - that points to missing builds.
<tsimonq2> On golang-defaults.
<foka> Thanks for the links!  I'll bookmark them now
<tsimonq2> https://launchpad.net/ubuntu/+source/golang-defaults/2:1.10~4ubuntu1
<tsimonq2> np :)
<tsimonq2> foka: One other trick I'll tell you about is, if you use DuckDuckGo, "!upkg SOURCEPACKAGENAME` will bring you to the Launchpad page for it. That's where I just found that link.
<foka> Wow, these are awesome tips and tricks!  Thank you so much!
<tsimonq2> np :)
<tsimonq2> foka: Perhaps you should talk to mwhudson about merging golang-defaults from Debian once Eoan (the 19.10 cycle) opens.
<tsimonq2> That will free up your hugo build.
<foka> Great idea!  I'll keep that in mind.
<tsimonq2> Cool :)
<tsimonq2> foka: Let me know if you have any other questions.
<foka> Thanks again!  Happy Easter to you (soon)!
<tsimonq2> Happy Easter to you as well :)
-queuebot:#ubuntu-release- Unapproved: percona-toolkit (xenial-proposed/universe) [2.2.16-1 => 2.2.16-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kylin-nm (eoan-proposed/universe) [1.0.0-1 => 1.0.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: scite (bionic-proposed/universe) [4.0.0-1 => 4.0.0-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debhelper (eoan-proposed/main) [12ubuntu1 => 12.1.1ubuntu1] (core)
<infinity> tsimonq2: ^-- Mind if I reject that and steal debhelper TIL back from you?
<infinity> tsimonq2: (Also, whatever you're doing that's adding translation noise to the ubuntu/debian delta is somewhat distracting)
<infinity> tsimonq2: And your vim missed adding eoan to a file.
<tsimonq2> infinity: debhelper> Go ahead.
<tsimonq2> That translation noise has been there for several cycles now; I manually remove it from the delta patch when I apply it, but it's autogenerated.
<infinity> It's autogenerated on clean, yes.  I never clean dh when I build it for that very reason.
<infinity> And I never use MoM to merge it.
<tsimonq2> infinity: vim> I used the Disco one as a model, which file did I miss?
<infinity> tsimonq2: Compare to mine: http://paste.ubuntu.com/p/rpfJS537pm/
<infinity> tsimonq2: You only did the second hunk.
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (eoan-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected vim [source] (eoan-proposed) [2:8.1.0320-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: vim (eoan-proposed/main) [2:8.1.0320-1ubuntu3 => 2:8.1.0320-1ubuntu4] (core)
<tsimonq2> Oh, darn.
<tsimonq2> infinity: Yeah, I totally missed that, sorry.
<tsimonq2> infinity: debhelper> I manually apply the patch from patches.ubuntu.com and strip out the translations bits, but to build it, I run `debuild -S -d`. I guess I'm missing an argument?
 * tsimonq2 RTFMs for debhelper.
<tsimonq2> s/debhelper/debuild/
<infinity> -nc skips cleaning.  Not recommended unless you're sure your tree is actually clean.
<infinity> And sometimes cleaning is required, because silly packaging.
-queuebot:#ubuntu-release- Unapproved: accepted vim [source] (eoan-proposed) [2:8.1.0320-1ubuntu4]
<infinity> (looking at you, anyone with a control.in)
<tsimonq2> Good to know.
<infinity> Also, there's nothing technically *wrong* with the translation noise there.  It's correctly following our update to the docs.
<infinity> It's just that it makes upstream perusing deltas messier, and harder for them to spot actual useful code changes among the auto-generated junk.
<tsimonq2> Makes sense.
<infinity> Speaking of autogenerated cruft in deltas, I can't wait for dpkg to have upstream Zstd support. :/
<infinity> The noise from that is awful.
<tsimonq2> The changelog diff is still longer. :P
<tsimonq2> I agree though, after looking at it.
<infinity> Yeah, but it's one file.
<Ukikie> tsimonq2: Yeah that's part of the reason I asked about dropping it. :P
<Ukikie> One line change, that they're sort of looking to make conditional for us, would be nicer.
<tsimonq2> Oh, for sure.
<Ukikie> (Also some changelogs are sane to have, git log >> changelog is not.)
-queuebot:#ubuntu-release- Unapproved: debhelper (eoan-proposed/main) [12ubuntu1 => 12.1.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (eoan-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (eoan-proposed) [1.0.114ubuntu1]
#ubuntu-release 2019-04-21
-queuebot:#ubuntu-release- Unapproved: gnome-applets (disco-proposed/universe) [3.30.0-3 => 3.30.0-3build1] (desktop-extra, edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-applets [source] (disco-proposed) [3.30.0-3build1]
-queuebot:#ubuntu-release- Unapproved: rejected pastebinit [source] (disco-proposed) [1.5-2.2ubuntu~0.19.04.1]
-queuebot:#ubuntu-release- New binary: actor-framework [s390x] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [amd64] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [i386] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [armhf] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [arm64] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [ppc64el] (eoan-proposed/universe) [0.16.3-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [amd64] (eoan-proposed/universe) [4.1.5+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdmtx [amd64] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdmtx [i386] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: maint-guide [amd64] (eoan-proposed/universe) [1.2.43] (no packageset)
-queuebot:#ubuntu-release- New binary: libdmtx [s390x] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdmtx [arm64] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdmtx [armhf] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: pyglet [amd64] (eoan-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uim [amd64] (eoan-proposed/universe) [1:1.8.8-4] (no packageset)
-queuebot:#ubuntu-release- New binary: comix [amd64] (eoan-proposed/universe) [4.0.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: didjvu [amd64] (eoan-proposed/universe) [0.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: easygen [amd64] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elm-mode [amd64] (eoan-proposed/universe) [0.20.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dotenv-cli [amd64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [amd64] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easygen [i386] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: austin [i386] (eoan-proposed/universe) [0.6.1~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [amd64] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-dash-to-panel [amd64] (eoan-proposed/universe) [19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [i386] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-bluetooth-quick-connect [amd64] (eoan-proposed/universe) [0~git20190225-1] (no packageset)
-queuebot:#ubuntu-release- New binary: austin [amd64] (eoan-proposed/universe) [0.6.1~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-anmitsu-go-shlex [amd64] (eoan-proposed/universe) [0.0~git20161002.648efa6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-apparentlymart-go-rundeck-api [amd64] (eoan-proposed/universe) [0.0.1+git20170705.2c962ac-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cyberdelia-heroku-go [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [i386] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cactus-go-statsd-client [amd64] (eoan-proposed/universe) [3.1.1+git20190125.82b7a17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-apparentlymart-go-cidr [amd64] (eoan-proposed/universe) [1.0.0+git20180915.1755c02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gokyle-fswatch [amd64] (eoan-proposed/universe) [0.0~git20121217.1dbdf83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fofix-dfsg [amd64] (eoan-proposed/universe) [3.121-6] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-corpix-uarand [amd64] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fzambia-sentinel [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-safetemp [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jesseduffield-pty [amd64] (eoan-proposed/universe) [1.1.3+git20181218.02db52c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kevinburke-ssh-config [amd64] (eoan-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-minio-blake2b-simd [amd64] (eoan-proposed/universe) [0.0~git20160723.3f5f724-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-structtag [amd64] (eoan-proposed/universe) [0.0~git20150214.217e25f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hmrc-vmware-govcd [amd64] (eoan-proposed/universe) [0.0.2+git20190404.eea2584-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-michaeltjones-walk [amd64] (eoan-proposed/universe) [0.0~git20161122.4748e29-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-getlantern-ops [amd64] (eoan-proposed/universe) [0.0~git20190325.d70cb0d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nozzle-throttler [amd64] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jesseduffield-termbox-go [amd64] (eoan-proposed/universe) [0.0~git20180919.1e272ff-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-emirpasic-gods [amd64] (eoan-proposed/universe) [1.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-willf-bloom [amd64] (eoan-proposed/universe) [2.0.3+git20190228.25ba46e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vividcortex-mysqlerr [amd64] (eoan-proposed/universe) [0.0~git20170204.6c6b55f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xrash-smetrics [amd64] (eoan-proposed/universe) [0.0~git20170218.a3153f7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ruudk-golang-pdf417 [amd64] (eoan-proposed/universe) [0.0~git20181029.1af4ab5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vbauerster-mpb [amd64] (eoan-proposed/universe) [3.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kori-go-listenbrainz [amd64] (eoan-proposed/universe) [0.0~git20190329.2d7276a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rs-zerolog [amd64] (eoan-proposed/universe) [1.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-stvp-roll [amd64] (eoan-proposed/universe) [0.0~git20170522.3627a5c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-src-d-go-billy.v4 [amd64] (eoan-proposed/universe) [4.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: icingaweb2-module-ipl [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [i386] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [amd64] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-muesli-goprogressbar [amd64] (eoan-proposed/universe) [0.1+git20180221.8ba3888-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gitlab-lupine-go-mimedb [amd64] (eoan-proposed/universe) [1.33.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [amd64] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [i386] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-spkg-bom [amd64] (eoan-proposed/universe) [0.0~git20160624.59b7046-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knack [amd64] (eoan-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [amd64] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [amd64] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [amd64] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [i386] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ledger2beancount [amd64] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-stretchr-testify.v1 [amd64] (eoan-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-plantuml-filter [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-aboe-chrony [amd64] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirtop [amd64] (eoan-proposed/universe) [0.3.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-mode [amd64] (eoan-proposed/universe) [0.3+132.g7dee1b5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [i386] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: optimir [amd64] (eoan-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jamm [amd64] (eoan-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [amd64] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-opentimestamps [amd64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [i386] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-irodsclient [amd64] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [i386] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [amd64] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-deric-zookeeper [amd64] (eoan-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pem [amd64] (eoan-proposed/universe) [18.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [i386] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fracdiff [i386] (eoan-proposed/universe) [1.4-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-shinycssloaders [amd64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reentry [amd64] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-sigdump [amd64] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thrift [i386] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [i386] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [amd64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-multilevel [amd64] (eoan-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-maxitest [amd64] (eoan-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [amd64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-deprecated [amd64] (eoan-proposed/universe) [1.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-uroot [i386] (eoan-proposed/universe) [2.0-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fracdiff [amd64] (eoan-proposed/universe) [1.4-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thrift [amd64] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [i386] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-uroot [amd64] (eoan-proposed/universe) [2.0-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [amd64] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [i386] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [i386] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [amd64] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [amd64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [amd64] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [amd64] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syslog [amd64] (eoan-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-irdisplay [amd64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [i386] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [amd64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [i386] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [i386] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: select2.js [amd64] (eoan-proposed/universe) [4.0.5~dfsg2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-data-uri [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [i386] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [amd64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: silver-platter [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [i386] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [amd64] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [i386] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [i386] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [amd64] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [amd64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vmemcache [amd64] (eoan-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [i386] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: schleuder-gitlab-ticketing [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [i386] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syslog [i386] (eoan-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [i386] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [amd64] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: ryu [amd64] (eoan-proposed/universe) [4.26+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libdmtx [ppc64el] (eoan-proposed/universe) [0.7.5-2.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-periphery [amd64] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: django-measurement [amd64] (eoan-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aioice [amd64] (eoan-proposed/universe) [0.6.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [i386] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ellipsis [i386] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [amd64] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ellipsis [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-fire [amd64] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fis-gtm [amd64] (eoan-proposed/universe) [6.3-007-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fis-gtm [i386] (eoan-proposed/universe) [6.3-007-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [i386] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [amd64] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [i386] (eoan-proposed/universe) [1.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [amd64] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [amd64] (eoan-proposed/universe) [1.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easygen [s390x] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [s390x] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: austin [s390x] (eoan-proposed/universe) [0.6.1~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [s390x] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [s390x] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [s390x] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [s390x] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [s390x] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [s390x] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [s390x] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [s390x] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [s390x] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [s390x] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thrift [s390x] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [s390x] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [s390x] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [s390x] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [s390x] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [s390x] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [s390x] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [s390x] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [s390x] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [s390x] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [s390x] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [s390x] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [s390x] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syslog [s390x] (eoan-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vmemcache [s390x] (eoan-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [i386] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: austin [arm64] (eoan-proposed/universe) [0.6.1~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easygen [arm64] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [armhf] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [armhf] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: austin [armhf] (eoan-proposed/universe) [0.6.1~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [arm64] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easygen [armhf] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [arm64] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [arm64] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [armhf] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [arm64] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [arm64] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [arm64] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [s390x] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [armhf] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [armhf] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [armhf] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [arm64] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [armhf] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [arm64] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [arm64] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [armhf] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [amd64] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [arm64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [armhf] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [i386] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [armhf] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thrift [armhf] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [s390x] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [armhf] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thrift [arm64] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [s390x] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [armhf] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [armhf] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [armhf] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [armhf] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [arm64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [armhf] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [armhf] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syslog [armhf] (eoan-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [arm64] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [arm64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [arm64] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [arm64] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [arm64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [arm64] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [armhf] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [arm64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syslog [arm64] (eoan-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [arm64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [arm64] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [arm64] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [arm64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vmemcache [arm64] (eoan-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [armhf] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [armhf] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [armhf] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [armhf] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [arm64] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [armhf] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [arm64] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [arm64] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [armhf] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [armhf] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [arm64] (eoan-proposed/universe) [1.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [armhf] (eoan-proposed/universe) [1.0.16-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: geary (bionic-proposed/universe) [0.12.0-1ubuntu1 => 0.12.4-4~ubuntu0.18.04.1] (ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: easygen [ppc64el] (eoan-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [s390x] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: first-last-agg [ppc64el] (eoan-proposed/universe) [0.1.4-4-gd63ea3b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitbrute [ppc64el] (eoan-proposed/universe) [0~12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [ppc64el] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [ppc64el] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lyx (xenial-proposed/universe) [2.1.4-2 => 2.1.5-0ubuntu0.16.04.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: kma [ppc64el] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lyx (bionic-proposed/universe) [2.2.3-5 => 2.2.4-0ubuntu0.18.04.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmerresistance [ppc64el] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [ppc64el] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yappi [ppc64el] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [ppc64el] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilercr [ppc64el] (eoan-proposed/universe) [1.06+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: phat [ppc64el] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mozc (eoan-proposed/main) [2.23.2815.102+dfsg-2ubuntu1 => 2.23.2815.102+dfsg-4ubuntu1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ruby-thrift [ppc64el] (eoan-proposed/universe) [0.11.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blake2-rfc [ppc64el] (eoan-proposed/universe) [0.2.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gumdrop-derive [ppc64el] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxplot [ppc64el] (eoan-proposed/universe) [0.9.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lscolors [ppc64el] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-generator [ppc64el] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ident-case [ppc64el] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pretty-assertions [ppc64el] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-once-cell [ppc64el] (eoan-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-signal-hook [ppc64el] (eoan-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stringtie [ppc64el] (eoan-proposed/universe) [1.3.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-thread-scoped [ppc64el] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: translation-finder [ppc64el] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mozc (bionic-proposed/main) [2.20.2673.102+dfsg-2 => 2.20.2673.102+dfsg-2ubuntu0.18.04.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mozc (cosmic-proposed/main) [2.23.2815.102+dfsg-2 => 2.23.2815.102+dfsg-2ubuntu0.18.10.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mozc (disco-proposed/main) [2.23.2815.102+dfsg-2ubuntu1 => 2.23.2815.102+dfsg-2ubuntu1.0.19.04.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gringo (eoan-proposed/universe) [5.2.3-2ubuntu1 => 5.3.0-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: php-zeta-unit-test (eoan-proposed/universe) [1.0.2-4ubuntu1 => 1.1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [ppc64el] (eoan-proposed/universe) [1.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [armhf] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [ppc64el] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pylibsrtp [ppc64el] (eoan-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclamunrar [ppc64el] (eoan-proposed/multiverse) [0.101.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [arm64] (eoan-proposed/universe) [7.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [ppc64el] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [arm64] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freecad [armhf] (eoan-proposed/universe) [0.18.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: symfony (eoan-proposed/universe) [3.4.22+dfsg-1ubuntu1 => 3.4.22+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: lighttpd (eoan-proposed/universe) [1.4.53-3ubuntu1 => 1.4.53-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rails (eoan-proposed/universe) [2:5.2.2+dfsg-6ubuntu1 => 2:5.2.2.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (eoan-proposed/main) [1:7.0.1-8 => 1:7.0.1-8ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-8 (eoan-proposed/main) [1:8-3 => 1:8-3ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted austin [arm64] (eoan-proposed) [0.6.1~beta-1]
-queuebot:#ubuntu-release- New: accepted easygen [arm64] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [arm64] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted freecad [arm64] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted freecad [ppc64el] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted gitbrute [armhf] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [s390x] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted kma [arm64] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [arm64] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [s390x] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted austin [armhf] (eoan-proposed) [0.6.1~beta-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [armhf] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted gitbrute [arm64] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New: accepted gwave [s390x] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [armhf] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted lltdscan [arm64] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [s390x] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [arm64] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted php7.3 [i386] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted php7.3 [s390x] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted easygen [armhf] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [arm64] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [ppc64el] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted phat [s390x] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [ppc64el] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [ppc64el] (eoan-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted python-yappi [s390x] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-thrift [s390x] (eoan-proposed) [0.11.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [s390x] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [s390x] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted freecad [armhf] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted lltdscan [s390x] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New: accepted pilercr [s390x] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pyxplot [s390x] (eoan-proposed) [0.9.2-8]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [s390x] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [s390x] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [s390x] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-thread-scoped [ppc64el] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted stringtie [ppc64el] (eoan-proposed) [1.3.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted translation-finder [ppc64el] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted kma [s390x] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [ppc64el] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [s390x] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-syslog [s390x] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted stringtie [s390x] (eoan-proposed) [1.3.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted vmemcache [s390x] (eoan-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [armhf] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted rust-pretty-assertions [s390x] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted translation-finder [s390x] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [s390x] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-thread-scoped [s390x] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted austin [s390x] (eoan-proposed) [0.6.1~beta-1]
-queuebot:#ubuntu-release- New: accepted easygen [ppc64el] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [ppc64el] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted fis-gtm [amd64] (eoan-proposed) [6.3-007-1]
-queuebot:#ubuntu-release- New: accepted freecad [amd64] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted freecad [s390x] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted gitbrute [s390x] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [ppc64el] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted gwave [armhf] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted kma [armhf] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted django-measurement [amd64] (eoan-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [s390x] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted freecad [i386] (eoan-proposed) [0.18.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [armhf] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted gwave [ppc64el] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [ppc64el] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [arm64] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [i386] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted libdmtx [ppc64el] (eoan-proposed) [0.7.5-2.2]
-queuebot:#ubuntu-release- New: accepted lltdscan [ppc64el] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New: accepted easygen [s390x] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted gitbrute [ppc64el] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New: accepted kma [ppc64el] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [armhf] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted lltdscan [armhf] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [armhf] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted phat [amd64] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted phat [armhf] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted phat [ppc64el] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted pilercr [amd64] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fis-gtm [i386] (eoan-proposed) [6.3-007-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [amd64] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [arm64] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted phat [arm64] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [amd64] (eoan-proposed) [7.3.4-2]
-queuebot:#ubuntu-release- New: accepted pilercr [armhf] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pilercr [ppc64el] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-aioice [amd64] (eoan-proposed) [0.6.14-1]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [amd64] (eoan-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [armhf] (eoan-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted gwave [arm64] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [ppc64el] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted pilercr [arm64] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pyglet [amd64] (eoan-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [arm64] (eoan-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted python-pem [amd64] (eoan-proposed) [18.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [amd64] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [armhf] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [s390x] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-yappi [armhf] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [s390x] (eoan-proposed) [0.101.2-1]
-queuebot:#ubuntu-release- New: accepted pilercr [i386] (eoan-proposed) [1.06+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [i386] (eoan-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [arm64] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-yappi [arm64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted pyxplot [amd64] (eoan-proposed) [0.9.2-8]
-queuebot:#ubuntu-release- New: accepted pyxplot [armhf] (eoan-proposed) [0.9.2-8]
-queuebot:#ubuntu-release- New: accepted pyxplot [ppc64el] (eoan-proposed) [0.9.2-8]
-queuebot:#ubuntu-release- New: accepted r-cran-ellipsis [i386] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-irdisplay [amd64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted phat [i386] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted python-periphery [amd64] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted reentry [amd64] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-thrift [amd64] (eoan-proposed) [0.11.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-thrift [i386] (eoan-proposed) [0.11.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [amd64] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [armhf] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [ppc64el] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [arm64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-pylibsrtp [i386] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-uroot [amd64] (eoan-proposed) [2.0-9-1]
-queuebot:#ubuntu-release- New: accepted ruby-thrift [armhf] (eoan-proposed) [0.11.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [arm64] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [amd64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [i386] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [armhf] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [ppc64el] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [arm64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ellipsis [amd64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-thrift [ppc64el] (eoan-proposed) [0.11.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [armhf] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [arm64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [amd64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [i386] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [amd64] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [armhf] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [ppc64el] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [arm64] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-maxitest [amd64] (eoan-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gumdrop-derive [ppc64el] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [armhf] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [arm64] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [amd64] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [i386] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pretty-assertions [amd64] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pretty-assertions [armhf] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pretty-assertions [ppc64el] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [arm64] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-blake2-rfc [i386] (eoan-proposed) [0.2.18-1]
-queuebot:#ubuntu-release- New: accepted rust-lscolors [ppc64el] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [armhf] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pretty-assertions [arm64] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [amd64] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [i386] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-syslog [amd64] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syslog [armhf] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-thread-scoped [amd64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-thread-scoped [armhf] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-ident-case [i386] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-generator [ppc64el] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [armhf] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-syslog [arm64] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-thread-scoped [arm64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted ryu [amd64] (eoan-proposed) [4.26+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted select2.js [amd64] (eoan-proposed) [4.0.5~dfsg2-1]
-queuebot:#ubuntu-release- New: accepted stringtie [amd64] (eoan-proposed) [1.3.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted stringtie [armhf] (eoan-proposed) [1.3.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted translation-finder [amd64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-once-cell [i386] (eoan-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted rust-signal-hook [ppc64el] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted vmemcache [amd64] (eoan-proposed) [0.8-1]
-queuebot:#ubuntu-release- New binary: golang-github-jesseduffield-pty [amd64] (eoan-proposed/universe) [1.1.3+git20181218.02db52c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kori-go-listenbrainz [amd64] (eoan-proposed/universe) [0.0~git20190329.2d7276a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-muesli-goprogressbar [amd64] (eoan-proposed/universe) [0.1+git20180221.8ba3888-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rs-zerolog [amd64] (eoan-proposed/universe) [1.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-spkg-bom [amd64] (eoan-proposed/universe) [0.0~git20160624.59b7046-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vbauerster-mpb [amd64] (eoan-proposed/universe) [3.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-syslog [i386] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted translation-finder [i386] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New binary: golang-github-kevinburke-ssh-config [amd64] (eoan-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nozzle-throttler [amd64] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-stvp-roll [amd64] (eoan-proposed/universe) [0.0~git20170522.3627a5c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-willf-bloom [amd64] (eoan-proposed/universe) [2.0.3+git20190228.25ba46e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gitlab-lupine-go-mimedb [amd64] (eoan-proposed/universe) [1.33.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-stretchr-testify.v1 [amd64] (eoan-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [i386] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [i386] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted stringtie [arm64] (eoan-proposed) [1.3.5+dfsg-1]
-queuebot:#ubuntu-release- New binary: golang-github-minio-blake2b-simd [amd64] (eoan-proposed/universe) [0.0~git20160723.3f5f724-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vividcortex-mysqlerr [amd64] (eoan-proposed/universe) [0.0~git20170204.6c6b55f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-src-d-go-billy.v4 [amd64] (eoan-proposed/universe) [4.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gwave [amd64] (eoan-proposed/universe) [20190116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [amd64] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [amd64] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knack [amd64] (eoan-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [amd64] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirtop [amd64] (eoan-proposed/universe) [0.3.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-emirpasic-gods [amd64] (eoan-proposed/universe) [1.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xrash-smetrics [amd64] (eoan-proposed/universe) [0.0~git20170218.a3153f7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: icingaweb2-module-ipl [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmerresistance [i386] (eoan-proposed/universe) [2.0+git20180205.26467e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lltdscan [i386] (eoan-proposed/universe) [0+20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-plantuml-filter [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-mode [amd64] (eoan-proposed/universe) [0.3+132.g7dee1b5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-irodsclient [amd64] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted austin [amd64] (eoan-proposed) [0.6.1~beta-1]
-queuebot:#ubuntu-release- New: accepted comix [amd64] (eoan-proposed) [4.0.4-4]
-queuebot:#ubuntu-release- New binary: golang-github-ruudk-golang-pdf417 [amd64] (eoan-proposed/universe) [0.0~git20181029.1af4ab5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kma [i386] (eoan-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: optimir [amd64] (eoan-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-aboe-chrony [amd64] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted austin [i386] (eoan-proposed) [0.6.1~beta-1]
-queuebot:#ubuntu-release- New: accepted dotenv-cli [amd64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted easygen [i386] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [amd64] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted fofix-dfsg [amd64] (eoan-proposed) [3.121-6]
-queuebot:#ubuntu-release- New: accepted gitbrute [i386] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New binary: goxkcdpwgen [amd64] (eoan-proposed/universe) [0.0~git20181107.de898c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pekka-kana-2 [amd64] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted didjvu [amd64] (eoan-proposed) [0.8.2-2]
-queuebot:#ubuntu-release- New: accepted elm-mode [amd64] (eoan-proposed) [0.20.3-1]
-queuebot:#ubuntu-release- New: accepted gitbrute [amd64] (eoan-proposed) [0~12-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-dash-to-panel [amd64] (eoan-proposed) [19-1]
-queuebot:#ubuntu-release- New: accepted golang-github-apparentlymart-go-cidr [amd64] (eoan-proposed) [1.0.0+git20180915.1755c02-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cactus-go-statsd-client [amd64] (eoan-proposed) [3.1.1+git20190125.82b7a17-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cyberdelia-heroku-go [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-structtag [amd64] (eoan-proposed) [0.0~git20150214.217e25f-1]
-queuebot:#ubuntu-release- New binary: ledger2beancount [amd64] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted easygen [amd64] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hmrc-vmware-govcd [amd64] (eoan-proposed) [0.0.2+git20190404.eea2584-1]
-queuebot:#ubuntu-release- New: accepted golang-github-kori-go-listenbrainz [amd64] (eoan-proposed) [0.0~git20190329.2d7276a-1]
-queuebot:#ubuntu-release- New: accepted golang-github-muesli-goprogressbar [amd64] (eoan-proposed) [0.1+git20180221.8ba3888-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rs-zerolog [amd64] (eoan-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-spkg-bom [amd64] (eoan-proposed) [0.0~git20160624.59b7046-1]
-queuebot:#ubuntu-release- New: accepted golang-github-vbauerster-mpb [amd64] (eoan-proposed) [3.3.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-willf-bloom [amd64] (eoan-proposed) [2.0.3+git20190228.25ba46e-1]
-queuebot:#ubuntu-release- New: accepted first-last-agg [i386] (eoan-proposed) [0.1.4-4-gd63ea3b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gokyle-fswatch [amd64] (eoan-proposed) [0.0~git20121217.1dbdf83-1]
-queuebot:#ubuntu-release- New: accepted golang-github-minio-blake2b-simd [amd64] (eoan-proposed) [0.0~git20160723.3f5f724-2]
-queuebot:#ubuntu-release- New: accepted golang-github-ruudk-golang-pdf417 [amd64] (eoan-proposed) [0.0~git20181029.1af4ab5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-vividcortex-mysqlerr [amd64] (eoan-proposed) [0.0~git20170204.6c6b55f-1]
-queuebot:#ubuntu-release- New: accepted golang-gitlab-lupine-go-mimedb [amd64] (eoan-proposed) [1.33.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-stretchr-testify.v1 [amd64] (eoan-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [i386] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted gwave [i386] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted jamm [amd64] (eoan-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-corpix-uarand [amd64] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nozzle-throttler [amd64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xrash-smetrics [amd64] (eoan-proposed) [0.0~git20170218.a3153f7-1]
-queuebot:#ubuntu-release- New: accepted goxkcdpwgen [amd64] (eoan-proposed) [0.0~git20181107.de898c7-1]
-queuebot:#ubuntu-release- New: accepted icingaweb2-module-ipl [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted kma [i386] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [i386] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted ledger2beancount [amd64] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted lltdscan [i386] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New: accepted optimir [amd64] (eoan-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-jesseduffield-termbox-go [amd64] (eoan-proposed) [0.0~git20180919.1e272ff-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-src-d-go-billy.v4 [amd64] (eoan-proposed) [4.3.0-1]
-queuebot:#ubuntu-release- New: accepted kma [amd64] (eoan-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted knack [amd64] (eoan-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted mirtop [amd64] (eoan-proposed) [0.3.17-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [amd64] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted puppet-mode [amd64] (eoan-proposed) [0.3+132.g7dee1b5-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-deric-zookeeper [amd64] (eoan-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted python-irodsclient [amd64] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted python-yappi [amd64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-stvp-roll [amd64] (eoan-proposed) [0.0~git20170522.3627a5c-1]
-queuebot:#ubuntu-release- New: accepted kmerresistance [amd64] (eoan-proposed) [2.0+git20180205.26467e9-1]
-queuebot:#ubuntu-release- New: accepted pandoc-plantuml-filter [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-aboe-chrony [amd64] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted python-opentimestamps [amd64] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fracdiff [amd64] (eoan-proposed) [1.4-2-1]
-queuebot:#ubuntu-release- New: accepted gwave [amd64] (eoan-proposed) [20190116-1]
-queuebot:#ubuntu-release- New: accepted pekka-kana-2 [i386] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted python-yappi [i386] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted lltdscan [amd64] (eoan-proposed) [0+20180223-1]
-queuebot:#ubuntu-release- New sync: fbxkb (eoan-proposed/primary) [0.6-2]
-queuebot:#ubuntu-release- New: accepted python-deprecated [amd64] (eoan-proposed) [1.2.5-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [sync] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New binary: fbxkb [amd64] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fbxkb [s390x] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fbxkb [ppc64el] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fbxkb [arm64] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fbxkb [i386] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fbxkb [armhf] (eoan-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted fbxkb [amd64] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [armhf] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [ppc64el] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [arm64] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [s390x] (eoan-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted fbxkb [i386] (eoan-proposed) [0.6-2]
#ubuntu-release 2020-04-13
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (focal-proposed/main) [20.04.1 => 20.04.2] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: mate-tweak (focal-proposed/universe) [20.04.0-1ubuntu2 => 20.04.0-1ubuntu3] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (focal-proposed/universe) [1.12.3 => 1.12.4] (ubuntustudio)
<Eickmeyer> ^ That's a minor bugfix
-queuebot:#ubuntu-release- Unapproved: ldns (focal-proposed/universe) [1.7.0-4ubuntu1 => 1.7.0-4.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (focal-proposed) [1.7.0-4.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-weather (focal-proposed/universe) [3.36.1-0ubuntu1 => 3.36.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: auto-multiple-choice (focal-proposed/universe) [1.4.0-3ubuntu1 => 1.4.0-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted auto-multiple-choice [source] (focal-proposed) [1.4.0-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: natsort (focal-proposed/universe) [7.0.1-1 => 7.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted natsort [sync] (focal-proposed) [7.0.1-1]
-queuebot:#ubuntu-release- Unapproved: qevercloud (focal-proposed/universe) [3.0.3+ds-5ubuntu1 => 3.0.3+ds-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qevercloud [sync] (focal-proposed) [3.0.3+ds-6]
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.4.0-3ubuntu1 => 1:4.5.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ruby-bert (focal-proposed/universe) [1.1.6-1ubuntu2 => 1.1.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-bert [sync] (focal-proposed) [1.1.6-2]
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.4.0-3ubuntu1 => 1:4.5.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libfreenect (focal-proposed/universe) [1:0.5.3-1ubuntu2 => 1:0.5.3-2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: trash-cli (focal-proposed/universe) [0.17.1.14-2ubuntu1 => 0.17.1.14-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted trash-cli [sync] (focal-proposed) [0.17.1.14-3]
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (focal-proposed/main) [4.8.1-0ubuntu2 => 4.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: khronos-api (focal-proposed/universe) [4.6+git20180514-1ubuntu1 => 4.6+git20180514-2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: libtest-xml-simple-perl (focal-proposed/universe) [1.05-1 => 1.05-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libtest-xml-simple-perl [sync] (focal-proposed) [1.05-2]
-queuebot:#ubuntu-release- Unapproved: mistral-dashboard (focal-proposed/universe) [9.0.0-1 => 9.0.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mistral-dashboard [source] (focal-proposed) [9.0.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: opam (focal-proposed/universe) [2.0.5-1build1 => 2.0.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: parso (focal-proposed/universe) [0.5.2-1 => 0.5.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted opam [source] (focal-proposed) [2.0.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted parso [source] (focal-proposed) [0.5.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: photocollage (focal-proposed/universe) [1.4.3-2.1 => 1.4.3-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted photocollage [source] (focal-proposed) [1.4.3-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: prometheus-varnish-exporter (focal-proposed/universe) [1.5-1 => 1.5.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted prometheus-varnish-exporter [sync] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> Release team: Please accept darktable.
<Ukikie> The darkness abounds.
<Eickmeyer> The table is flat.
-queuebot:#ubuntu-release- Unapproved: pyqi (focal-proposed/universe) [0.3.2+dfsg-4 => 0.3.2+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pyqi [sync] (focal-proposed) [0.3.2+dfsg-5]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (focal-proposed) [4.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-controls [source] (focal-proposed) [1.12.4]
-queuebot:#ubuntu-release- Unapproved: accepted mate-tweak [source] (focal-proposed) [20.04.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: darktable (focal-proposed/universe) [2.6.3-1build2 => 3.0.1-0ubuntu1] (ubuntustudio)
<Eickmeyer> ^ Thank you!
-queuebot:#ubuntu-release- Unapproved: python-ftputil (focal-proposed/universe) [3.4-2 => 3.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (focal-proposed) [2.13.3-7ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted python-ftputil [sync] (focal-proposed) [3.4-3]
-queuebot:#ubuntu-release- Unapproved: accepted ibus-unikey [source] (focal-proposed) [0.6.1-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: darktable (focal-proposed/universe) [2.6.3-1build2 => 3.0.1-0ubuntu1] (ubuntustudio)
<Eickmeyer> ^ Yet, still not accepted?
-queuebot:#ubuntu-release- Unapproved: python-lepl (focal-proposed/universe) [5.1.3-2.1 => 5.1.3-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-lepl [source] (focal-proposed) [5.1.3-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libotr (focal-proposed/universe) [4.1.1-3 => 4.1.1-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: refpolicy (focal-proposed/universe) [2:2.20190201-7 => 2:2.20190201-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted refpolicy [sync] (focal-proposed) [2:2.20190201-8]
-queuebot:#ubuntu-release- Unapproved: songwrite (focal-proposed/universe) [3-0.1-2 => 3-0.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted songwrite [sync] (focal-proposed) [3-0.1-3]
-queuebot:#ubuntu-release- Unapproved: svnkit (focal-proposed/universe) [1.8.14-3 => 1.8.14-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted svnkit [sync] (focal-proposed) [1.8.14-4]
-queuebot:#ubuntu-release- Unapproved: twitter-bootstrap4 (focal-proposed/universe) [4.4.1+dfsg1-1 => 4.4.1+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted twitter-bootstrap4 [sync] (focal-proposed) [4.4.1+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: seqan3 (focal-proposed/universe) [3.0.1+ds-8 => 3.0.1+ds-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted seqan3 [sync] (focal-proposed) [3.0.1+ds-9]
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1d-2ubuntu6 => 1.1.1f-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: vdr (focal-proposed/universe) [2.4.1-4build1 => 2.4.1-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vdr [source] (focal-proposed) [2.4.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1d-2ubuntu6 => 1.1.1f-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: carla (focal-proposed/universe) [2.1~rc2-0ubuntu1 => 2.1-0ubuntu1] (i386-whitelist, ubuntustudio)
<Eickmeyer> ^ Bugfix/final version.
<valorie> Eickmeyer: it *is* Easter
<Eickmeyer> valorie: Wasn't my timing on that one. Literally just dropped 45 ago, at which point I packaged/tested it. :P
<valorie> you are quick!
<Eickmeyer> I even fixed a lintian warning.
<valorie> <3
-queuebot:#ubuntu-release- Unapproved: pangox-compat (focal-proposed/universe) [0.0.2-5build1 => 0.0.2-5ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted pangox-compat [source] (focal-proposed) [0.0.2-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ortp (focal-proposed/universe) [1:1.0.2-1 => 1:1.0.2-1.1] (kubuntu) (sync)
<wgrant> ortp is an FTBFS fix with GCC 9
-queuebot:#ubuntu-release- Unapproved: glewmx (focal-proposed/universe) [1.13.0-4ubuntu2 => 1.13.0-4ubuntu3] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: keybinder (focal-proposed/universe) [0.3.1-2 => 0.3.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted keybinder [source] (focal-proposed) [0.3.1-2ubuntu1]
<mitya57> Hi! xdg-desktop-portal-kde/riscv64 unsatisfiable Depends: xdg-desktop-portal â can that be hinted somehow? It is not a regression, and if I read excuses correctly, it is the only obstacle for Qt 5.12.8 migration.
-queuebot:#ubuntu-release- Unapproved: kdiagram (focal-proposed/universe) [2.6.2-4 => 2.6.3-1] (kubuntu) (sync)
<mitya57> â In addition to the above:
<mitya57> dtkwidget: libdtkwidget2/riscv64 unsatisfiable Depends: librsvg2-2 (>= 2.26.0)
<mitya57> qgis: qgis-providers/riscv64 unsatisfiable Depends: libhdf5-103
<locutus_> also remmina suffers from a similar issue...
-queuebot:#ubuntu-release- Unapproved: gcc-10-cross-ports (focal-proposed/universe) [4ubuntu1 => 5ubuntu1] (i386-whitelist)
<TJ-> can we get a regression, and a CVE fix, into weechat? bug #1866065 bug #1872425
<ubot5> bug 1866065 in weechat (Ubuntu) "weechat python.so not linked against libpython3 (undefined symbol: _Py_NoneStruct)" [Undecided,In progress] https://launchpad.net/bugs/1866065
<ubot5> bug 1872425 in weechat (Ubuntu) "CVE-2020-8955: backport 2.7.1 CVEs to 20.04 weechat-2.6" [Undecided,In progress] https://launchpad.net/bugs/1872425
-queuebot:#ubuntu-release- Unapproved: gmap (focal-proposed/multiverse) [2019-09-12+ds-1 => 2020-04-08+ds1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gmap [sync] (focal-proposed) [2020-04-08+ds1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross-ports [source] (focal-proposed) [5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-weather [sync] (focal-proposed) [3.36.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [sync] (focal-proposed) [20.1.1+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted khronos-api [sync] (focal-proposed) [4.6+git20180514-2]
-queuebot:#ubuntu-release- Unapproved: accepted lynx [sync] (focal-proposed) [2.9.0dev.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted mutagen [sync] (focal-proposed) [1.44.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (focal-proposed) [6.1.4-dfsg-4]
-queuebot:#ubuntu-release- Unapproved: libnftnl (focal-proposed/main) [1.1.5-1 => 1.1.6-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (focal-proposed/main) [4.8.1-0ubuntu2 => 4.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.4.0-3ubuntu1 => 1:4.5.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted glslang [sync] (focal-proposed) [8.13.3559+git3727-1]
-queuebot:#ubuntu-release- Unapproved: accepted kdiagram [sync] (focal-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted mm-common [sync] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: darktable (focal-proposed/universe) [2.6.3-1build2 => 3.0.1-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted golang-goprotobuf [sync] (focal-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted ortp [sync] (focal-proposed) [1:1.0.2-1.1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.9 => 20.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libfreenect [sync] (focal-proposed) [1:0.5.3-2]
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1d-2ubuntu6 => 1.1.1f-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected meson [sync] (focal-proposed) [0.54.0-1]
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (focal-proposed) [0.204]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (focal-proposed) [20.04.2]
<mitya57> sil2100: hi! do you know what we can do with these:
<mitya57> xdg-desktop-portal-kde/riscv64 unsatisfiable Depends: xdg-desktop-portal
<mitya57> dtkwidget: libdtkwidget2/riscv64 unsatisfiable Depends: librsvg2-2 (>= 2.26.0)
<mitya57> qgis: qgis-providers/riscv64 unsatisfiable Depends: libhdf5-103
-queuebot:#ubuntu-release- Unapproved: accepted libotr [source] (focal-proposed) [4.1.1-3ubuntu1]
<mitya57> These are not regressions, as the same situation is with -release versions.
-queuebot:#ubuntu-release- Unapproved: rejected gnome-weather [sync] (focal-proposed) [3.36.1-1]
<sil2100> Eickmeyer: hey! Looking at the new carla upload - adding a new plugin seems a bit late, so normally it's a thing I'd opt for an FFe, but then again carla is only seeded in studio - you sure you want that in for release this late?
<sil2100> mitya57: hm, sadly I'm not really up-to-date with our policies regarding riscv64 right now, I'll try to find out tomorrow
<mitya57> Ok
<sil2100> mitya57: for now I know I think we don't necessarily want to force-hint uninstallable things into the archive IIRC
<sil2100> (since that was what people recommended to me when I uploaded livecd-rootfs)
<RikMills> sil2100: it's already uninstallable in -release
<sil2100> I know, same for livecd-rootfs
<sil2100> Anyway, I don't know, I don't want to override the general policy per those that have more context on how we deal with those
<RikMills> other r-t members have already force hinted things
<sil2100> I think I was told we want to stop force hinting and fix things now to avoid issues in the near future
<RikMills> sil2100: ok. maybe vorlon etc might be about later usa time
<sil2100> RikMills: yeah, vorlon will know for sure what's the recommended way to go forward
<RikMills> sil2100: weirdly, update_output_notest.txt would migrate QT
-queuebot:#ubuntu-release- Unapproved: accepted guile-2.2 [sync] (focal-proposed) [2.2.7+1-4]
<RikMills> but there are not failing tests blocking
-queuebot:#ubuntu-release- Unapproved: accepted glewmx [source] (focal-proposed) [1.13.0-4ubuntu3]
<RikMills> sometimes whan I just about think I am getting a better handle on britney, it throws up weirdness like that! lol
<RikMills> sil2100: anyway, thanks for your time where most places it is a holiday!
<ginggs> how does a package get moved from multiverse -> universe?  gmap is no longer non-free
<mitya57> sil2100, RikMills: I can fix hdf5, it is just symbols diff.
 * RikMills longs for a Qt migration without weird issues
<mitya57> But for example librsvg can't be easily fixed, as it needs rust compiler.
<cjwatson> ginggs: file bug, subscribe ubuntu-archive
<ginggs> cjwatson: ta!
<wgrant> mitya57, RikMills: riscv64 will have rustc and librsvg in a day or two.
<wgrant> hdf5> oops, did I fail to upload that? I thought I did both it and libhdf4, but I may have missed one. If you could, since I'm afk...
<mitya57> wgrant: hdf5> I am looking at it, yes
<wgrant> Thanks
<wgrant> If not I'll get to it in the morning
<mitya57> Re librsvg, I would still prefer if dtkwidget is force-hinted, because every day of delay brings us closer to the releaseâ¦
<RikMills> wgrant: great, just getting frustrated, as I have another thing to get in that has to wait until Qt migrates, and I would prefer not to do that by the skin of its teeth on finalfreeze day
<RikMills> but what will be will be :)
<RikMills> thank you
<RikMills> mitya57: yep
<wgrant> Yeah, hinting that seems sane
-queuebot:#ubuntu-release- Unapproved: accepted strip-nondeterminism [sync] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted configobj [sync] (focal-proposed) [5.0.6-4]
-queuebot:#ubuntu-release- Unapproved: hdf5 (focal-proposed/universe) [1.10.4+repack-11 => 1.10.4+repack-11ubuntu1] (kubuntu)
<mitya57> sil2100: â riscv64 fix for hdf5 to unblock qgis
-queuebot:#ubuntu-release- Unapproved: linux-aws (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-aws (focal-proposed/restricted) [5.4.0-1008.8 => 5.4.0-1009.9] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (focal-proposed/main) [5.4.0.1008.10 => 5.4.0.1009.11] (core, kernel) (sync)
<mitya57> wgrant: by chance, do you know what is the problem with xdg-desktop-portal? It built on riscv64 in Debian but not in Ubuntu.
<mitya57> Looks like xdg-desktop-portal receives SIGTRAP, but not sure why.
-queuebot:#ubuntu-release- Unapproved: jtreg (focal-proposed/universe) [5.0-b01-1 => 5.0-b01-2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jtreg [sync] (focal-proposed) [5.0-b01-2]
-queuebot:#ubuntu-release- Unapproved: kubuntu-settings (focal-proposed/universe) [1:20.04.8 => 1:20.04.9] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: fcitx5-qt (focal-proposed/universe) [0.0~git20200118.2e38c95-1build2 => 0.0~git20200118.2e38c95-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fcitx5-qt [source] (focal-proposed) [0.0~git20200118.2e38c95-1build3]
-queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [ppc64el] (focal-proposed/universe) [5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (eoan-proposed/universe) [0.10.1-0ubuntu3 => 0.10.1-0ubuntu4] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: networking-bagpipe (focal-proposed/universe) [12.0.0~b3~git2020032508.4677785-0ubuntu1 => 12.0.0~b3~git2020041013.c15d5e0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-bagpipe [source] (focal-proposed) [12.0.0~b3~git2020041013.c15d5e0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu4 => 2:16.0.0~b3~git2020041013.e74c8f8c88-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-dynamic-routing (focal-proposed/universe) [2:16.0.0~b3~git2020032542.fd72823-0ubuntu1 => 2:16.0.0~b3~git2020041013.045811b-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [source] (focal-proposed) [2:16.0.0~b3~git2020041013.045811b-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (focal-proposed/main) [2:16.0.0~b3~git2020032431.d86582f04-0ubuntu1 => 2:16.0.0~b3~git2020041013.358d35202-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.0.0~b3~git2020032515.35240b0d8c-0ubuntu2 => 2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: aodh (focal-proposed/main) [10.0.0~b3~git2020032411.ed802044-0ubuntu1 => 10.0.0~b3~git2020041012.6ae7f90a-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (focal-proposed/main) [1:14.0.0~b3~git2020032414.56012eaa-0ubuntu1 => 1:14.0.0~b3~git2020041012.75b9d4e9-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1018.19~18.04.1] (no packageset)
<Eickmeyer> sil2100: It's a dummy plugin that acts as a fix to another bug, not really a feature.
-queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.0.0~b3~git2020032414.a0c0a9e23-0ubuntu1 => 2:16.0.0~b3~git2020041012.eb915e2db-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> sil2100: This is the "final" for the RC2 for Carla 2.1 in the repos now. If we can have the final for an LTS, then I'm all for it.
-queuebot:#ubuntu-release- Unapproved: designate (focal-proposed/main) [1:10.0.0~b3~git2020032414.dd359ba3-0ubuntu1 => 1:10.0.0~b3~git2020041012.9ed2623a-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu2 => 2:20.0.0~b3~git2020041012.d5a0ce18-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (focal-proposed/main) [1:14.0.0~b3~git2020032414.d8354d908-0ubuntu1 => 1:14.0.0~b3~git2020041012.2ef9f4bf3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.2.1~git2020032709.2c4470272-0ubuntu1 => 3:18.2.1~git2020041013.754804667-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ironic (focal-proposed/universe) [1:14.0.1~git2020032415.de2d907fc-0ubuntu1 => 1:14.0.1~git2020041013.af9e6ba90-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: keystone (focal-proposed/main) [2:17.0.0~b3~git2020032415.9f9040257-0ubuntu2 => 2:17.0.0~b3~git2020041013.7bb6314e4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: magnum (focal-proposed/universe) [10.0.0~b3~git2020032617.ce70da25-0ubuntu1 => 10.0.0~b3~git2020041013.01629398-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: masakari (focal-proposed/main) [9.0.0~b3~git2020032617.953e1d8-0ubuntu1 => 9.0.0~b3~git2020041013.94ec959-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (focal-proposed) [10.0.0~b3~git2020041013.01629398-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: masakari-monitors (focal-proposed/main) [9.0.0~b3~git2020032614.8711c07-0ubuntu1 => 9.0.0~b3~git2020041013.e225e6d-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mistral (focal-proposed/universe) [10.0.0~b3~git2020032611.8a5d35ac-0ubuntu1 => 10.0.0~b3~git2020041013.a7da00d7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (focal-proposed) [10.0.0~b3~git2020041013.a7da00d7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: murano (focal-proposed/universe) [1:9.0.0~b2~git2020020609.25ebd01d-0ubuntu2 => 1:9.0.0~b3~git2020041013.564f9cf3-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: murano-agent (focal-proposed/universe) [1:5.0.0~b1~git2019121815.2b2cc45-0ubuntu5 => 1:5.0.0~b3~git2020041013.b908aa8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted murano-agent [source] (focal-proposed) [1:5.0.0~b3~git2020041013.b908aa8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ocrmypdf (focal-proposed/universe) [9.5.0+dfsg-1 => 9.6.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ocrmypdf [sync] (focal-proposed) [9.6.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (focal-proposed/main) [4.8.1-0ubuntu2 => 4.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Packageset: 6799 entries have been added or removed
<Eickmeyer> sil2100: I know our times here don't overlap very well, so yes, I'm hoping for an ack on carla, and an ack on tjaalton's upload of darktable.
<Eickmeyer> sil2100: Regarding that plugin, it's internal to Carla (a Native plugin) and can't be used outside of it. https://github.com/falkTX/Carla/commit/678505e87f7535d08f715a867f56a7e75881f1e7
<Eickmeyer> sil2100: Its related bug: https://github.com/falkTX/Carla/issues/1038
<gitbot> falkTX issue 1038 in Carla "Allow CV -> Audio, but somehow change the UX to help some?" [Closed]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-installer (focal-proposed/universe) [0.07 => 0.08] (ubuntustudio)
<Eickmeyer> ^ Fixed a typo
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.140 => 1.141] (core)
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (focal-proposed/universe) [0.4.9 => 0.4.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu24 => 2.04-1ubuntu25] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (focal-proposed) [0.4.10]
-queuebot:#ubuntu-release- Unapproved: octavia (focal-proposed/universe) [6.0.0~b3~git2020032609.73fca169-0ubuntu1 => 6.0.0~b3~git2020041014.771a5d87-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (focal-proposed) [6.0.0~b3~git2020041014.771a5d87-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: panko (focal-proposed/universe) [8.0.0~b3~git2020032612.a725f644-0ubuntu1 => 8.0.0~b3~git2020041014.e66d3e75-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted panko [source] (focal-proposed) [8.0.0~b3~git2020041014.e66d3e75-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: placement (focal-proposed/universe) [3.0.0~b3~git2020032615.971c7aa7-0ubuntu1 => 3.0.0~b3~git2020041014.0f90d197-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted placement [source] (focal-proposed) [3.0.0~b3~git2020041014.0f90d197-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: jtreg (focal-proposed/universe) [5.0-b01-2 => 5.0-b01-2ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [arm64] (focal-proposed/universe) [5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: sahara (focal-proposed/universe) [1:12.0.0~b3~git2020032616.0825bdde-0ubuntu1 => 1:12.0.0~b3~git2020041014.0825bdde-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: senlin (focal-proposed/universe) [9.0.0~b3~git2020032615.d3bd9ef3-0ubuntu1 => 9.0.0~b3~git2020041014.4627fbfb-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (focal-proposed) [9.0.0~b3~git2020041014.4627fbfb-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vmware-nsx (focal-proposed/universe) [16.0.0~b3~git2020032711.f43adec12-0ubuntu1 => 16.0.0~b3~git2020041014.75cfea261-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [source] (focal-proposed) [16.0.0~b3~git2020041014.75cfea261-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: watcher (focal-proposed/universe) [1:4.0.0~b3~git2020032633.c17e96d3-0ubuntu1 => 1:4.0.0~b3~git2020041014.f3c427bd-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted watcher [source] (focal-proposed) [1:4.0.0~b3~git2020041014.f3c427bd-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: zaqar (focal-proposed/universe) [10.0.0~b3~git2020032614.22c457a5-0ubuntu1 => 10.0.0~b3~git2020041014.22c457a5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zaqar [source] (focal-proposed) [10.0.0~b3~git2020041014.22c457a5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: manila (focal-proposed/universe) [1:10.0.0~b3~git2020032516.cb016333-0ubuntu1 => 1:10.0.0~b3~git2020041013.ea90fd17-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (focal-proposed/universe) [1:13.0.0~b3~git2020032626.3cdcfac3-0ubuntu1 => 1:13.0.0~b3~git2020041014.8c3df10a-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (focal-proposed) [1:13.0.0~b3~git2020041014.8c3df10a-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
<vorlon> sil2100, RikMills, mitya57: we don't want to increase uninstallability on riscv64, but we also don't want to have packages held up because of britney policy when there is no regression in installability in the release pocket.  The trouble with 'force' hints is that it also bypasses running autopkgtests.  Anyway, I'm not sure the riscv64 unsatisfiable depends are actually what's blocking dtkwidget
<vorlon> and xdg-desktop-portal-kde now, they also have a dependency on qtbase-opensource-src which is not a candidate?
<RikMills> vorlon: not a candidate due to the ppa grouping policy as far as can see?
<vorlon> yes
<vorlon> and ah, xdg-desktop-portal-kde was uploaded to the ppa
<vorlon> (dtkwidget wasn't)
<vorlon> so it's possible there's bad interaction with the ppa grouping policy vs some of the architecture-forcing overrides
<vorlon> (riscv64 is listed in BREAK_ARCHES, which I thought was supposed to take care of this)
<vorlon> so yeah I'll double-check the britney results from the ppa and then add a force for xdg-desktop-portal-kde
<RikMills> they seem to be somewhat circular in invalidating the landing, yes
<vorlon> ... if I can find the autopkgtest results, since it appears the bileto ticket has been marked as 'landed' before it's cleared -proposed
-queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [amd64] (focal-proposed/universe) [5ubuntu1] (i386-whitelist)
<vorlon> well, no autopkgtests for that package or its revdeps anyway, so I'll proceed
<vorlon> but having the britney history for the bileto ppa go away before the packages have made it through proposed-migration is not ideal
<RikMills> vorlon: thanks. I don't think we let the tests/autosignoff run anyway, as with Qt it would be a huge number
<RikMills> but point taken
<vorlon> ah
<vorlon> ok, hint added, let's see what happens
<RikMills> like I don't run them for KDE frameworks, as L@ney would get p****d with me running them all twice
<vorlon> indeed :)
<RikMills> thanks!
<vorlon> and ok, I'm looking at other britney results here that clearly show BREAK_ARCHES is not a big enough hammer to get packages to flow smoothly :P
<RikMills> I have yet to look up what that does, but seems not
<vorlon> it's defined as "your uninstallability count may increase"
<vorlon> unfortunately in practice it only applies to the update_output phase, not the update_excuses phase
<RikMills> so can't apply if not a valid canditate to start with?
<vorlon> right
<RikMills> got it
-queuebot:#ubuntu-release- Packageset: Added jsunit to mozilla in focal
-queuebot:#ubuntu-release- Unapproved: clevis (focal-proposed/universe) [12-1ubuntu1 => 12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted clevis [source] (focal-proposed) [12-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
 * Eickmeyer is still looking for an ack on darktable, carla, and ubuntstudio-installer
-queuebot:#ubuntu-release- Unapproved: terminator (focal-proposed/universe) [1.91-4 => 1.91-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted terminator [source] (focal-proposed) [1.91-4ubuntu1]
<RikMills> found invalid grouped package qgis, will invalidate set
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.4-dfsg-4 => 6.1.4-dfsg-4ubuntu1] (ubuntu-cloud)
<xnox> vorlon:  ^ i think above will also unbreak building vagrant images, as per email.
<RikMills> vorlon: so qgis hint as well?
<vorlon> xnox: so you're implementing an opposite fix to the change mbiebl made in systemd git?
<LocutusOfBorg> sigh xnox http://bugs.debian.org/878074
<ubot5> Debian bug 878074 in virtualbox-guest-utils "Update virtualbox-guest-utils will remove a well running ntp" [Important,Fixed]
<xnox> LocutusOfBorg:  in ubuntu, ntp is not the default nor preffered time-daemon
<xnox> LocutusOfBorg:  and in our vagrant guest images, we want to use the virtualbox-guest-utils aka host-provided time.
<xnox> vorlon:  yes because ^^^^
<vorlon> xnox: I don't know that it's correct that virtualbox-guest-utils provides: time-daemon; I do know that it's incorrect for systemd-timesyncd to force virtualbox-guest-utils off the system
<xnox> vorlon:  true, systemd-timesyncd needs to drop virtualbox-guest-utils conflict.
<xnox> vorlon:  but systemd depends on time-daemon now, and something needs to provide it. and virgualbox-guest-utils does provide time-daemon
<vorlon> xnox: so if we drop systemd-timesyncd conflict with virtualbox-guest-utils, and allow both packages to be installed, what happens?
<vorlon> it only provides time-daemon if I accept your upload
<xnox> vorlon: good question, i don't know.
<LocutusOfBorg> in any case, please make sure you both agree, and then let me prior upload in debian and sync, instead of adding an ubuntu1
<LocutusOfBorg> I remember I did lots of testing on that conflict/replace, and I went to the current solution
<LocutusOfBorg> I don't want to regress again
<xnox> jchittum:  rcj: what happens when both systemd-timesyncd is installed / running and virtualbox-guest-utils provides system time too?
<vorlon> xnox: ok.  the parsimonious and freeze-friendly change is to drop the conflicts from systemd-timesyncd and leave the rest alone
<vorlon> since that's what we already had in Ubuntu prior to 20.04
<xnox> vorlon:  we did not have systemd-timesyncd split prior to 20.04
<vorlon> LocutusOfBorg: nack on waiting for it to be syncable from Debian
<vorlon> xnox: correct, which means we had the situation that systemd-timesyncd was installed and running, and guest-utils were also installed
<LocutusOfBorg> vorlon, I can upload *now*
<LocutusOfBorg> and copy-package or whatever
<vorlon> LocutusOfBorg: and it takes hours to actually be available for sync from the archive (as opposed to fake sync)
<vorlon> LocutusOfBorg: and I'm generally unsympathetic to the attitude that deltas need to be driven to zero on packages, post freeze
<LocutusOfBorg> we can upload as 6.1.4-dfsg-5, by tweaking changes file
<LocutusOfBorg> I'll make sure the same package is uploaded in sid
<LocutusOfBorg> :)
<vorlon> so then you've created a fake sync and broken launchpad version history
<vorlon> no thank you
<LocutusOfBorg> ok, that was mostly a question, rather than a suggestion, I never did that :)
<LocutusOfBorg> but I prefer to have virtualbox and virtualbox-hwe to be kept version in sync, at least
-queuebot:#ubuntu-release- Unapproved: accepted jtreg [source] (focal-proposed) [5.0-b01-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
<xnox> vorlon:  ok, reject my upload.
<xnox> (of virtualbox)
<vorlon> done
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.10]
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (focal-proposed) [6.1.4-dfsg-4ubuntu1]
<vorlon> xnox: the openssl upload is pretty unreviewable from a freeze perspective; how do we establish that openssl 1.1.1f is safe to take one week before release?
<xnox> vorlon:  looking in the guest-utils code there is VBoxServer/VBoxServiceTimeSync => somehow that needs to be forked into a separate subpackage, such that that portion of service is opt-in/opt-out.
<xnox> vorlon:  what we currently have is a snapshot of stable 1.1.1 series which was close to 1.1.1e release already. But i had refereted a patch that regressed things, which they shipped in 1.1.1d, then referted, and released 1.1.1f
<xnox> vorlon:  i guess i can find the commit id where we currently are on stable branch, and how far it is to get to 1.1.1f tarball.
<xnox> vorlon:  cause i can reach 1.1.1f with just more patches from stable.
<vorlon> well, if you're saying it's actually a small delta in practice, I can change how I'm diffing
<xnox> vorlon:  we are at 93c50f4680 + s390x patches, and new things are like just 38 patches.
-queuebot:#ubuntu-release- Unapproved: accepted darktable [source] (focal-proposed) [3.0.1-0ubuntu1]
<Eickmeyer> ^ Thank you!!!
<xnox> https://paste.ubuntu.com/p/7jTNDgXTYN/ is the new set of things that i'm adding
<vorlon> xnox: 38 patches does not give me any more confidence that this is safe 1 week before release
<xnox> vorlon:  https://paste.ubuntu.com/p/HwWZzkNngw/
<vorlon> xnox: looks like that filters out the noise from the copyright line changes; anything else?
<xnox> vorlon:  it's small bug fixes, and then testsuite changes, docs, and bump of new year. Well, our current behaviour matches 1.1.1d & 1.1.1f behaviour, but many projects will be keying on the fact that 1.1.1f is "good" one w.r.t. EOF errors.
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-settings [source] (focal-proposed) [1:20.04.9]
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu2] (kubuntu)
<xnox> (copyright change => is correct, they agreed in PRs that manpages additions for s390x stuff are dual-licensed)
<LocutusOfBorg> so vorlon am I correct in saying vbox doesn't need any change, but systemd needs fixes?
<vorlon> LocutusOfBorg: at this point in the cycle, yes
<vorlon> xnox: ok, I have it down to a reviewable diff size locally, I'll take a closer look later today
<LocutusOfBorg> thanks, this saved lots of time and testing for now :) because also virtualbox-guest-utils-hwe has the very same problem
<xnox> vorlon: tah, i care about SSL_get_servername() fixes & Revised BN_generate_prime_ex . Our EOF detection is correct, although 1.1.1f one is slightly improved / better, and some software is starting to key on 1.1.1f behaviour at runtime.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-installer [source] (focal-proposed) [0.08]
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> ^^ Thank you!!!!
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1018.19~18.04.1]
<RikMills> vorlon: did you see my comment about qgis. I know you must be busy, so if can't look until later, np at all
<mitya57> vorlon, RikMills: an alternative to forcing qgis is accepting my hdf5 upload, which should unblock it.
<RikMills> mitya57: oh, I missed that hitting the queue!
<mitya57> Though, hdf5 build may take several hours so I won't mind if you force qgis too :)
<RikMills> hmm. the one in release is rebuilding now. must have been poked by scriptery
<mitya57> Yeah. But armhf build took > 1 hour, and riscv64 is usually slower than it.
<RikMills> indeed. that is why I looked. to see how long it took to get to the symbols fail
-queuebot:#ubuntu-release- New source: openjdk-15 (focal-proposed/primary) [15~18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-15 [source] (focal-proposed) [15~18-1ubuntu1]
-queuebot:#ubuntu-release- New binary: pydicom [amd64] (focal-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pydicom [amd64] (focal-proposed) [1.4.1-1]
<Eickmeyer> vorlon, sil2100: Just to further explain my carla upload: it's the stable 2.1 release, the archive has RC2. Changelog says it introduces a new plugin, but that's a trivial internal plugin to fix a bug. No new features here, hence no FFe. See https://github.com/falkTX/Carla/issues/1038 and https://github.com/falkTX/Carla/commit/678505e87f7535d08f715a867f56a7e75881f1e7
<gitbot> falkTX issue 1038 in Carla "Allow CV -> Audio, but somehow change the UX to help some?" [Closed]
-queuebot:#ubuntu-release- Unapproved: octavia-dashboard (focal-proposed/universe) [5.0.0~b3~git2020032610.b96ac1a-0ubuntu1 => 5.0.0~b3~git2020041315.761408e-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted octavia-dashboard [source] (focal-proposed) [5.0.0~b3~git2020041315.761408e-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hdf5 [source] (focal-proposed) [1.10.4+repack-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (focal-proposed/universe) [14.0.0~b3~git2020032615.7db14da-0ubuntu1 => 14.0.0~b3~git2020041315.a92ba65-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (focal-proposed/universe) [12.0.0~b3~git2020032714.2525137-0ubuntu1 => 12.0.0~b3~git2020041315.b4f7dcd-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (focal-proposed) [12.0.0~b3~git2020041315.b4f7dcd-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: manila-ui (focal-proposed/universe) [1:2.19.2~git2020032617.e1bcac2-0ubuntu1 => 1:2.19.2~git2020041315.301fc4e-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (focal-proposed) [14.0.0~b3~git2020041315.a92ba65-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (focal-proposed) [1:2.19.2~git2020041315.301fc4e-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (focal-proposed/universe) [1:9.0.0~b3~git2020032617.90de7126-0ubuntu1 => 1:9.0.0~b3~git2020041315.b9ed51cb-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (focal-proposed/universe) [1:2.1.1~git2020032617.d57d35e-0ubuntu1 => 1:2.1.1~git2020041315.d49e7ef-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (focal-proposed) [1:2.1.1~git2020041315.d49e7ef-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (focal-proposed/universe) [1:10.0.1~git2020032711.4eefb42-0ubuntu1 => 1:10.0.1~git2020041316.14b425e-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [source] (focal-proposed) [1:10.0.1~git2020041316.14b425e-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: networking-arista (focal-proposed/universe) [2019.1.2~git2020032726.4b002ee-0ubuntu1 => 2019.1.5~git2020041316.382e8a9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-arista [source] (focal-proposed) [2019.1.5~git2020041316.382e8a9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (focal-proposed/main) [2.24.1~git2020032711.712bf3c9f-0ubuntu2 => 2.24.1~git2020041316.a495f1e32-0ubuntu1] (openstack)
<mitya57> vorlon: hi again, now that hdf5 is in, can you please force dtkwidget to migrate? It will be the last obstacle for Qt migration.
<mitya57> wgrant said he will fix rustc and librsvg for riscv64, but it may take a day or two, and IMO it would be better to not hold Qt because of that.
<RikMills> I have stuff waiting on Qt migrating, that I do not want to do right before the freeze comes down
<RikMills> so yes, getting that through tonight has my votes
<mitya57> (To give more context, the error is: dtkwidget: libdtkwidget2/riscv64 unsatisfiable Depends: librsvg2-2 (>= 2.26.0))
<vorlon> xnox: so openssl 1.1.1f will be the one package in the archive that builds cleanly if the build directory has a space in the path... useful ;)
-queuebot:#ubuntu-release- Unapproved: linux-aws (bionic-updates/main) [4.15.0-1066.70 => 4.15.0-1065.69] (kernel, ubuntu-budgie) (sync)
<Odd_Bloke> Very good news for my new architecture &nbsp;64.
<sarnold> :)
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (bionic-updates) [4.15.0-1065.69]
<vorlon> mitya57: forcing dtkwidget means not checking autopkgtests for any reverse-dependencies; do you know for sure that there aren't any?
<vorlon> looks like we're safe
<RikMills> vorlon: archived excuses from last upload on 23rd march shows no tests triggerd
<RikMills> oh, guess you looked somehow
<RikMills> :)
<vorlon> xnox: can you explain why we want the commit 63fa6f2e4b Revert "Stop accepting certificates signed using SHA1 at security level 1"?
<vorlon> xnox: I guess it's an upstream commit so we would want to follow... but does it degrade our security at all in Ubuntu?
<vorlon> xnox: double-checked and see that we're at level=2 instead of level=1 (which I vaguely remembered), so I guess this should have no impact on us by default
<vorlon> xnox: I suspect the upstream delta to test/recipes/25-test_verify.t may cause a test failure because it's now assuming -auth_level 1 by default for the sha1 test instead of passing it explicitly?
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (focal-proposed) [1.1.1f-1ubuntu1]
-queuebot:#ubuntu-release- New binary: python-dicompylercore [amd64] (focal-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libnftnl [sync] (focal-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted pango1.0 [source] (focal-proposed) [1.44.7-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (focal-proposed/main) [2.2 => 2.3] (core)
-queuebot:#ubuntu-release- Unapproved: apport-symptoms (focal-proposed/main) [0.22 => 0.23] (core)
-queuebot:#ubuntu-release- Unapproved: accepted resource-agents [source] (focal-proposed) [1:4.5.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-barbicanclient [source] (focal-proposed) [4.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-castellan [source] (focal-proposed) [3.0.0-0ubuntu1]
#ubuntu-release 2020-04-14
-queuebot:#ubuntu-release- Unapproved: rustc (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1 => 1.41.0+dfsg1+llvm-0ubuntu2] (i386-whitelist)
<wgrant> vorlon: ^^ if you're still about, riscv64 support for rustc
<wgrant> Which unblocks librsvg, mozjs68, etc.
<vorlon> whee
<wgrant> Well mozjs68 needs some minor porting but I have a working binary.
-queuebot:#ubuntu-release- Unapproved: accepted python-cliff [source] (focal-proposed) [3.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-dicompylercore [amd64] (focal-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted rustc [source] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu2]
<wgrant> Thanks.
<Eickmeyer> vorlon, doko: Heads-up, likely to have a new upload of ardour headed your way. Likely a no-changes rebuild against the newer libgcc doko pulled (RE: bug 1872555)
<ubot5> bug 1872555 in ardour (Ubuntu) "the included a-* plugins can not load because of the new version of the GNU C Library" [Critical,In progress] https://launchpad.net/bugs/1872555
-queuebot:#ubuntu-release- Unapproved: rasdaemon (eoan-proposed/universe) [0.6.0-1.2 => 0.6.0-1.2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rasdaemon (bionic-proposed/universe) [0.6.0-1ubuntu0.1 => 0.6.0-1ubuntu0.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ukui-menu (focal-proposed/universe) [2.0.5-1 => 2.0.6-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-glance-store [source] (focal-proposed) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (focal-proposed/universe) [2.1.0-1 => 2.1.1-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (focal-proposed) [4:5.18.4.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-glanceclient [source] (focal-proposed) [1:3.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [i386] (focal-proposed/universe) [5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted python-keystoneauth1 [source] (focal-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-keystonemiddleware [source] (focal-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected glance [source] (focal-proposed) [2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackdocstheme [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-neutronclient [source] (focal-proposed) [1:7.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-neutron-lib [source] (focal-proposed) [2.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-resource-classes [source] (focal-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-brick [source] (focal-proposed) [3.0.1-0ubuntu1]
<vorlon> pushed a fix to britney's sourceppa policy, on the next run it should take force hints into consideration before marking the packages from the qt ppa as non-candidates
-queuebot:#ubuntu-release- Unapproved: accepted python-os-traits [source] (focal-proposed) [2.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-win [source] (focal-proposed) [5.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstacksdk [source] (focal-proposed) [0.46.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-keyring [source] (focal-proposed) [2020.02.11.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.serialization [source] (focal-proposed) [3.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-argcomplete (focal-proposed/universe) [1.8.1-1ubuntu2 => 1.8.1-1.3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-argcomplete [source] (focal-proposed) [1.8.1-1.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: matplotlib (focal-proposed/universe) [3.1.2-1ubuntu3 => 3.1.2-1ubuntu4] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.rootwrap [source] (focal-proposed) [6.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.reports [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lubuntu-artwork (focal-proposed/universe) [20.04.2 => 20.04.3] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.privsep [source] (focal-proposed) [2.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libsdl2 (focal-proposed/universe) [2.0.10+dfsg1-2ubuntu5 => 2.0.10+dfsg1-3] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: grpc (focal-proposed/universe) [1.16.1-1ubuntu4 => 1.16.1-1ubuntu5] (no packageset)
<LocutusOfBorg> libsdl2 this one fixes mostly all the recverse deps failures ^^
-queuebot:#ubuntu-release- Unapproved: accepted grpc [source] (focal-proposed) [1.16.1-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: sqlmap (focal-proposed/universe) [1.4.3-1 => 1.4.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sqlmap [sync] (focal-proposed) [1.4.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [sync] (focal-proposed) [2.0.10+dfsg1-3]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menu [sync] (focal-proposed) [2.0.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [sync] (focal-proposed) [2.1.1-1]
<tjaalton> hi, vulkan-loader and spirv-headers/-tools from the queue are needed by vulkan-tools/-validationlayers/glslang in proposed
<tjaalton> xnox: how does the installer image pull the oem kernel? it should migrate to 5.6
<tjaalton> ..which is still in proposed, so maybe that's why
<mvo> hey, snapd is stuck in focal-proposed because of a failure of livecd-rootfs. looking at the autopkgtest results it looks like it started to fail way before snapd (already in a python-apt upload from 2020-04-09). could someone override please?
<RikMills> vorlon: did not work?
<RikMills> ah. pyside2
<mitya57> "shiboken2/riscv64 unsatisfiable Depends: libclang1-10 (>= 1:5.0~+rc1~)"
<doko> RikMills, mitya57: llvm-10 still building
<mitya57> The previous build took 19 hours and the was cancelled. But I think it really may take > 2 days.
<mitya57> *and then
<mitya57> So maybe a force hint makes sense here too.
<wgrant> Forcing makes sense, llvm-10 will take another 24 hours at least.
<wgrant> The test suite is slow and single-threaded.
-queuebot:#ubuntu-release- Unapproved: jtreg (focal-proposed/universe) [5.0-b01-2ubuntu1 => 5.0-b01-2ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.policy [source] (focal-proposed) [3.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.middleware [source] (focal-proposed) [4.0.2-0ubuntu1]
<wgrant> On the upside we should have librsvg2 and libsecret tonight, which just leaves llvm-toolchain-10, zeromq3 and vim.
<vorlon> RikMills: but also it didn't work because the code change I made to britney was insufficient. Hopefully the next run is better
<RikMills> right. thanks!
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.messaging [source] (focal-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.log [source] (focal-proposed) [4.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.i18n [source] (focal-proposed) [4.0.1-0ubuntu1]
<mitya57> vorlon: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.db [source] (focal-proposed) [8.1.0-0ubuntu1]
<RikMills> vorlon, mitya57 I: [Tue Apr 14 07:46:28 2020] - sourceppa: processing uim, found invalid grouped package qtbase-opensource-src, will invalidate set
<xnox> tjaalton:  we install metapackage, and images are only built with release pocket.
<RikMills> and many more in current run :/
<tjaalton> xnox: right, so I'm trying to make oem-5.6 to migrate
<xnox> mvo:  we are awaiting systemd fix, to unbreak autopkgtests, to allow things to migrate.
<xnox> tjaalton:  ack, let's check where it is stuck
<tjaalton> xnox: should be fine by now, but the adt test matrix still shows some tests 'missing' while they passed
<mitya57> RikMills: ð¥
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux-oem-5.6/+bug/1870978 => does not look like a normal linux tracking bug for uploads, with all the tasks, etc.
<ubot5> Ubuntu bug 1870978 in linux-oem-5.6 (Ubuntu) "v5.6.2 stable update" [Undecided,Fix committed]
<tjaalton> like lxc and systemd
<xnox> tjaalton:  why is the tracking bug so weird? =/
<xnox> ah, here it is https://bugs.launchpad.net/kernel-sru-workflow/+bug/1870496
<ubot5> Ubuntu bug 1870496 in Kernel SRU Workflow regression-testing "focal/linux-oem-5.6: 5.6.0-1007.7 -proposed tracker" [Medium,In progress]
<tjaalton> hmm, maybe I should mark regression testing invalid
<tjaalton> done
<xnox> tjaalton:  i think all of those missing ones, are actually ok.
<tjaalton> yes
<xnox> tjaalton:  "regression testing not applicable to oem-5.6 which is new" => is not true.
<tjaalton> it's not like that'll block anything
<xnox> apw has been enforcing regression testing. Because linux-oem-5.4 passed it, and because linux-oem-4.15 passed it.
<xnox> tjaalton:  the bot set the tag "block-proposed" on the bug, affecting the wrong source package =)
<xnox> no, the right package.
<xnox> so yes, linux-oem-5.6 is blocked by the adt-matrix bot from migrating
<tjaalton> I've marked automated-testing fixed
<xnox> tjaalton: horay =)
<xnox> hopefully bot will unblock, and it will migrate
<xnox> tjaalton:  bot is not happy
<xnox> reason:
<xnox>   promote-to-release: Holding -- master bug not ready for release
<tjaalton> "Holding -- master bug not ready for release"
<tjaalton> ngh
<apw> and why is the master not ready
<xnox> no idea what that means, never so that before. Is that about src:linux?
<apw> it is about the bug pointed to by master-bug: which will be focal:linux yes
<xnox> https://bugs.launchpad.net/kernel-sru-workflow/+bug/1871939 => is master? but that makes no sense.
<ubot5> Ubuntu bug 1871939 in Kernel SRU Workflow automated-testing "focal/linux: 5.4.0-24.28 -proposed tracker" [Medium,In progress]
<tjaalton> this is not a derivative of src:linux, but I guess there's no way around that?
<xnox> becuase oem is 5.6
<xnox> can we reconfigure the bug's master to some other master that was already released? =)
<apw> tjaalton, it is marked a derivative of focal:linux because you marked it a derivative of focal:linux
<tjaalton> ah ah..
<apw> tjaalton, as it is not one, you should take that our of ks.yaml and remove the ...master-bug: foo from the tracker
<tjaalton> done
-queuebot:#ubuntu-release- Unapproved: linux-meta-riscv (focal-proposed/main) [5.4.0.24.29 => 5.4.0.24.30] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-riscv [source] (focal-proposed) [5.4.0.24.30]
<RikMills> vorlon: ppa grouping policy still seems to be borking Qt?
<RikMills> I guess he might be gone
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.64-0ubuntu3 => 440.82-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted jtreg [source] (focal-proposed) [5.0-b01-2ubuntu2]
<RikMills> oh, there is a typo in Steve's hint!
<RikMills> apw, could you correct that if steve has gone to bed?
<apw> RikMills, if you hold my hand, yes
<RikMills> apw: it is this
<RikMills> 5.14.0.1 was put in instead of 5.14.0-1
<RikMills> https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/4748
<RikMills> vorlon: ^ if you are here
 * RikMills waits
<apw> RikMills, I can sort that out; cc:vorlon
<RikMills> ty :)
<apw> and in theory done
<tjaalton> xnox, apw: oem-5.6 is now ready, so it should migrate soon and then oem-5.4 can be removed \o/
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu610 => 20101020ubuntu611] (core)
<apw> tjaalton, thanks for the heads up
-queuebot:#ubuntu-release- Unapproved: gjs (focal-proposed/main) [1.64.1-2 => 1.64.1-2ubuntu1] (desktop-core, desktop-extra, i386-whitelist, mozilla)
<RikMills> apw: great. fingers crossed for it doing what was intended
<tjaalton> wonder if I still have time for another upload, pulling 5.6.4 and maybe some
<apw> tjaalton, kernel-freeze was some time ago
<tjaalton> true
<tjaalton> it's not critical I think
<apw> tjaalton, and yes you have a much lower risk profile, but that does not stop you adding it to the current SRU cycle
<tjaalton> so it'd get out the week after release? works for me
<apw> tjaalton, it'd essentially be a day 0 SRU
<tjaalton> right
<LocutusOfBorg> hello, somebody did break armhf testbed? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/libn/libnet-async-tangence-perl/20200414_082018_e1e55@/log.gz
-queuebot:#ubuntu-release- Unapproved: cbmc (focal-proposed/universe) [5.10-5build1 => 5.10-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cbmc [source] (focal-proposed) [5.10-5ubuntu1]
<rbalint> ubuntu-release please accept unattended-upgrades, it fixed the critical bug in debian
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (xenial-proposed) [1.1.14-2ubuntu1.7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.141]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-aws [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (focal-proposed) [5.4.0.1009.11]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu611]
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu25 => 2.04-1ubuntu25] (core)
<Laney> LocutusOfBorg: hmm, does look suspicious, let me take a look
<Laney> I'll probably just burn all the armhf nodes to the ground and re-provision them though
<Laney> (expect no armhf processing for a little bit)
<xnox> Laney:  sil2100: where can i get btmakemetafile ?
<Laney> what is that?
<xnox> Laney:  something that cdimage calls to make torrent files on nusakan?
<xnox> Laney:  unless i'm down a wrong code-path, and something else was supposed to create .torrent file for me
<Laney> I dunno, I just wanted a hint as to which context you were even talking in
<Laney> :)
<mitya57> Qt is migrating, thanks to everyone who helped!
<Laney> xnox: looks like 'bittornado' package
<xnox> Laney:  what's apt-cache policy for it?
<xnox> Laney:  cause it's not in ubuntu. Some PPA? locally installed?
<Laney> xenial
<xnox> ahah
<xnox> /usr/bin/btmakemetafile.bittornado
<xnox> and it's alternative, which is why i couldn't find it by obsolute name
<Laney> yeah there's alternatives involved indeed
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu25 => 2.04-1ubuntu25] (core)
<Ukikie> xnox: FWIW there's a Py3 version of that, also going forward maybe look into 'mktorrent'
-queuebot:#ubuntu-release- Unapproved: zfs-linux (focal-proposed/main) [0.8.3-1ubuntu11 => 0.8.3-1ubuntu12] (core)
<RikMills> sil2100: hi, I have this to land LP: #1872371
<ubot5> Launchpad bug 1872371 in kmail (Ubuntu) "[FFe] KDE PIM 19.12.3 into Focal archive" [Undecided,Triaged] https://launchpad.net/bugs/1872371
<RikMills> delayed due to Qt
<RikMills> could you perhaps let that through when it hits?
<RikMills> once that is done, I have no more surprises!
<rbalint> LocutusOfBorg, i see you committed https://salsa.debian.org/pkg-virtualbox-team/virtualbox/-/commit/3cd2bb6f5ea3782a5bc8b48496d3762c25ffe201 a few years ago, please take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956577
<ubot5> Debian bug 956577 in virtualbox-guest-utils "Please decide whether to add C/R/P: time-daemon" [Normal,Open]
<xnox> Laney:  thanks.
<rbalint> xnox, ^^
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu25]
<rbalint> this is now causing LP: #1872485 and i'm dropping systemd-timesyncd's conflict with virtualbox-guest-utils following Debian but it means timesyncd will be running in virtualbox vms
<ubot5> Launchpad bug 1872485 in systemd (Ubuntu) "virtualbox-guest-utils fails to install on 20.04" [High,In progress] https://launchpad.net/bugs/1872485
-queuebot:#ubuntu-release- Unapproved: akonadi-calendar-tools (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-contacts (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-calendar (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi (focal-proposed/universe) [4:19.04.3-0ubuntu6 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-import-wizard (focal-proposed/universe) [4:19.04.3-0ubuntu3 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-notes (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadiconsole (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: calligra (focal-proposed/universe) [1:3.1.0+dfsg-6ubuntu6 => 1:3.1.0+dfsg-6ubuntu7] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: grantlee-editor (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kalarm (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kblog (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcalutils (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdav (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-mime (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akregator (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kaddressbook (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcalcore (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 5:5.68.0-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdepim-addons (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-search (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kalarmcal (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: digikam (focal-proposed/universe) [4:6.4.0+dfsg-3 => 4:6.4.0+dfsg-3build1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcontacts (focal-proposed/universe) [4:19.04.3-0ubuntu3 => 5:5.68.0-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdepim-runtime (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kf5-messagelib (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kidentitymanagement (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kio-gdrive (focal-proposed/universe) [1.2.7-1build1 => 1.2.7-1build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kjots (focal-proposed/universe) [4:5.0.2-2build1 => 4:5.0.2-2build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kleopatra (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmail (focal-proposed/universe) [4:19.04.3-0ubuntu3 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmbox (focal-proposed/universe) [19.04.3-0ubuntu1 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmymoney (focal-proposed/universe) [5.0.8-1build2 => 5.0.8-1build3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kontact (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kf5-kdepim-apps-libs (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kimap (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kldap (focal-proposed/universe) [19.04.3-0ubuntu1 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmailtransport (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: knotes (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kopete (focal-proposed/universe) [4:19.04.3-0ubuntu3 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kpimtextedit (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kgpg (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmail-account-wizard (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kontactinterface (focal-proposed/universe) [19.04.3-0ubuntu1 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kpkpass (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kitinerary (focal-proposed/universe) [19.04.3-0ubuntu4 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: korganizer (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmime (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kraft (focal-proposed/universe) [0.90-2build1 => 0.90-2build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ktnef (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5eventviews (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5gravatar (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5ksieve (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5libkleo (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5mailimporter (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkgapi (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: pim-data-exporter (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: zanshin (focal-proposed/universe) [0.5.71-1build1 => 0.5.71-1build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ksmtp (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5grantleetheme (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5libkdepim (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5pimcommon (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: pim-sieve-editor (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5calendarsupport (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5mailcommon (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5incidenceeditor (focal-proposed/universe) [19.04.3-0ubuntu2 => 19.12.3-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: mbox-importer (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.12.3-0ubuntu1] (kubuntu) (sync)
<RikMills> sil2100: ^
 * RikMills hides
<sil2100> :<
<LocutusOfBorg> rbalint, will do, thanks!
<RikMills> sil2100: sorry, I did say. I will take full responsibility (or blame), including fixing if an issue
<sil2100> RikMills: will look into it in a few moments :)
<rbalint> sil2100, please accept unattended-upgrades
<sil2100> rbalint: looking
<sil2100> rbalint: oh, thought this would be a sync, but it's a normal upload, huh
<rbalint> sil2100, maybe i can sync now, a sec
<sil2100> rbalint: as long as those are the same sources, I don't think it matters
<rbalint> sil2100, i requested a sync now
<rbalint> sil2100, i guess going with the sync is nicer, please accept that then
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (focal-proposed/main) [2.2 => 2.3] (core) (sync)
<rbalint> sil2100, i just hoped someone coud accept the upload earlier before i can sync it
-queuebot:#ubuntu-release- Unapproved: accepted apport-symptoms [source] (focal-proposed) [0.23]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (focal-proposed) [2.3]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (focal-proposed) [2.3]
-queuebot:#ubuntu-release- Unapproved: murano (focal-proposed/universe) [1:9.0.0~b2~git2020020609.25ebd01d-0ubuntu2 => 1:9.0.0~b3~git2020041013.564f9cf3-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.cache [source] (focal-proposed) [2.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.config [source] (focal-proposed) [1:8.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.service [source] (focal-proposed) [2.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.utils [source] (focal-proposed) [4.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.vmware [source] (focal-proposed) [3.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.concurrency [source] (focal-proposed) [4.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.upgradecheck [source] (focal-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.context [source] (focal-proposed) [1:3.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslotest [source] (focal-proposed) [1:4.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-ovsdbapp [source] (focal-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-senlinclient [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-osprofiler [source] (focal-proposed) [3.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [source] (focal-proposed) [5.4.5-0ubuntu1]
<RikMills> sil2100: going to face supermarket queues, back later
<xnox> rbalint:  hi
<xnox> rbalint:  vbox-guest-utils currently does not implement "time-daemon". All it currently does is get the time of the host, and settimeofdate() to the one of the host. If the hosts' time is wrong, one is out of luck.
<xnox> rbalint:  i previous releases, we had both vbox-guest-utils & timesyncd installed and running together.
<xnox> (such that if host time is wrong, timesyncd/ntp are operating and fixing time)
<xnox> rbalint:  we do not want to regress that. Hence we want to upload systemd-timesyncd that drops the conflicts on vbox-guest-utils. Such that status quo continues.
<xnox> rbalint:  in longer term, i want to ask vbox-guest-utils to split the portion of the daemon that does settimeofday() to the host one, in to a separate subpackage. And have that one provide/conflicts/replaces time-daemon.
<xnox> but we are not going to get that done now.
<xnox> rbalint:  so please upload systemd, that drops conflicts on virtualbox-* stuff for now.
<xnox> rbalint:  my upload to re-add time-daemon to guest-utils was rejected yesterday.
<rbalint> xnox, it is built and being tested in bileto
<rbalint> xnox, ok i proposed the fix in the virtualbox bug
<sil2100> coreycb: hey! I'm looking at the new OpenStack packages in the queue right now - it all feels so risky with all those upstream version bumps
<xnox> rbalint:  horay!
<xnox> sil2100:  they did have FFe for this, beacause Openstack screwed up release schedule
<sil2100> xnox: ok, thanks for the info, I assumed that was the case - still, makes me all shiverish
<rbalint> sil2100, xnox i have not landed anything from bileto yet, should i just push publish?
<rbalint> (tyring to land systemd to focal)
-queuebot:#ubuntu-release- Unapproved: accepted python-cinderclient [source] (focal-proposed) [1:7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-octaviaclient [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-ironicclient [source] (focal-proposed) [4.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-saharaclient [source] (focal-proposed) [3.1.0-0ubuntu1]
<mitya57> Probably the last thing from me: can someone please look at bug 1871077?
<ubot5> bug 1871077 in retext (Ubuntu) "FFe: Sync retext 7.1.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1871077
-queuebot:#ubuntu-release- Unapproved: gnome-builder (focal-proposed/universe) [3.36.0-2 => 3.36.0-3] (desktop-extra) (sync)
<coreycb> sil2100: thanks for looking at those. upstream just released all their final dependency versions. the plan is to get those in and get as up-to-date as possible with core package snapshots before focal release. then we'll SRU the rest when upstream final releases in May.
<coreycb> sil2100: just for reference this is the schedule we're following: https://lists.ubuntu.com/archives/ubuntu-release/2019-November/004857.html
<coreycb> sil2100: risk shouldn't be too bad, we have a lot of testing going on along side the package updates
-queuebot:#ubuntu-release- Unapproved: openjfx (focal-proposed/universe) [11.0.2+1-2ubuntu1 => 11.0.7+0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [source] (focal-proposed) [11.0.7+0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (focal-proposed) [10.0.0~b3~git2020041012.6ae7f90a-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.0.0~b3~git2020041013.e74c8f8c88-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (focal-proposed) [2:16.0.0~b3~git2020041013.358d35202-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apache2 (focal-proposed/main) [2.4.41-4ubuntu2 => 2.4.41-4ubuntu3] (i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (focal-proposed) [1:14.0.0~b3~git2020041012.75b9d4e9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (focal-proposed) [1:10.0.0~b3~git2020041012.9ed2623a-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (focal-proposed) [1:14.0.0~b3~git2020041012.2ef9f4bf3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (focal-proposed) [2:16.0.0~b3~git2020041012.eb915e2db-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.2.1~git2020041013.754804667-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (focal-proposed) [2:20.0.0~b3~git2020041012.d5a0ce18-0ubuntu1]
<Laney> has anyone tried to understand the livecd-rootfs/amd64 autopkgtest failure yet?
<Laney> I see 999 people have retried it
 * sil2100 didn't retry it yet!
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (focal-proposed) [1:14.0.1~git2020041013.af9e6ba90-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (focal-proposed) [1:10.0.0~b3~git2020041013.ea90fd17-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (focal-proposed) [9.0.0~b3~git2020041013.94ec959-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted murano [source] (focal-proposed) [1:9.0.0~b3~git2020041013.564f9cf3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (focal-proposed) [2.24.1~git2020041316.a495f1e32-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (focal-proposed) [2:17.0.0~b3~git2020041013.7bb6314e4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (focal-proposed) [1:9.0.0~b3~git2020041315.b9ed51cb-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (focal-proposed) [9.0.0~b3~git2020041013.e225e6d-0ubuntu1]
<sil2100> Laney: I can look into it in a moment
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (focal-proposed) [1:12.0.0~b3~git2020041014.0825bdde-0ubuntu1]
<sil2100> Since I want livecd-rootfs to migrate (need one of it versions)
<Laney> I'm wondering how 2.657 migrated too
<Laney> don't see any hints
<Laney> oh no, there was a force hint :(
<sil2100> Oh?
<Laney> yeah, and those skip autopkgtests
<Laney> but they run now since xnox tweaked the deps
<Laney> (which shouldn't have been necessary since BREAK_ARCHES was set but that didn't work for some reason I didn't look into yet)
<Laney> sil2100: so I guess you could apply the 'regressed in release' rule if you wanted to given that force
<Laney> not great if we don't have test coverage of livecd-rootfs tho
<xnox> sil2100:  Laney: well systemd that should unbreak livcd-rootfs tests is incoming no?
<Laney> I have no idea, my opener was asking what the problem is
<xnox> Laney:  sil2100: i feel like livecd-rootfs/amd64 should be marked as bad-test for now. Or like make an upload that skips building vagrant images iff systemd is not new enough.
<Laney> where is this issue discussed?
<xnox> it is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1872485
<ubot5> Ubuntu bug 1872485 in systemd (Ubuntu) "virtualbox-guest-utils fails to install on 20.04" [High,In progress]
<xnox> Laney:  systemd-timesyncd has Conflicts on vagrant-guest-utils which doesn't have Provides: time-daemon, which results in them both uninstallable together.
<Laney> thanks
<Laney> I'm ok for badtest, the release pocket is already fubared
<xnox> and is in flight to be fixed via bileto
<Laney> I suspect systemd doesn't trigger livecd-rootfs?
<xnox> Laney:  something like that, or it didn't inject systemd from proposed, or it did inject but dependency resolution downgraded systemd to release pocket (at the time) to make it installable with virtual-guest-utils
<xnox> corner corner corner case
<Laney> nah this is like inside chroots, whatever autopkgtest did isn't relevant
<Laney> so the tests would need improving to poke the triggering package down into there ...
<Laney> and then systemd would need to be a trigger
 * Laney can guess what the likelihood of this happening is :-)
<Laney> sil2100: I added the skiptest for you
<Laney> what we need is for autopkgtest to make a proxy archive somewhere that the testbed can access, which exposes the correct view of the being-tested thing
<Laney> and then use that in sources.list
<sil2100> Laney: thanks, not the best option that is, but I agree on it being b0rked already in release anyway
 * sil2100 is busy trying to review the new KDE stack
<sil2100> 65 delicious packages
<Laney> then tests get "deb http://autopkgtest.host/ test test" in their sources.list, and no more weird pinning hacks are needed
<tjaalton> locutus__: hi, I'd need the commit from llvm-10 to ship polly libs in order to let mesa build against it. should I just push or do you have something queued?
<Laney> or transmit that to the testbed, and have a tiny proxy running in there that 302s everything to the real mirror
<rbalint> Laney, xnox i think teaching livecd-rootfs to bootstrap with triggering package from proposed needs rewriting it with mmdebstrap which i don't oppose at all :-)
<Laney> OR do it completely externally and have a cherry-pick-from-proposed magic mirror "http://proposed.archive.ubuntu.com/ubuntu/focal/livecd-rootfs/systemd focal main universe multiverse restricted"
<rbalint> Laney, xnox i've just requested publishing systemd from bileto and almost all tests are finished already
 * Laney stops dreaming
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-2ubuntu1 => 245.4-4ubuntu1] (core, i386-whitelist) (sync)
<rbalint> sil2100, ^ it has multiple fixes, but i think it is ok, since we are not in final freeze yet
<rbalint> sil2100, also, test results https://bileto.ubuntu.com/#/ticket/3801
<sil2100> Hopefully I'll get to it today ;)
<juliank> Laney: I have solver plans for apt, but not sure if I'll have time to pursue them, they should fix all problems
<juliank> Laney: because then you tell it what you want and it will give you a solution if there is one
<tjaalton> there's also spirv-headers/-tools and vulkan-loader to move the stack to vulkan version 1.2.135 and support VR ;)
<juliank> and not a broken one like the hacks
<rbalint> sil2100, it is wanted badly to unbreak virtualbox images
<juliank> solver stuff is tough
<rbalint> Laney, maybe you are interested in reviewing and landing systemd quickly, too ^^ ;-)
<Laney> rbalint: I am, got to upload ubiquity first though
<Laney> juliank: That'd be nice, I guess you do need a solver to do any of this proxy stuff
<Laney> I want to just see the needed packages from proposed, nothing else, and error if the trigger can't be installed really
<Laney> after the 'update_output.txt' phase would be a better time to run the tests, since the migration transactions are this
<juliank> Yeah, I mean, optimally you'd build pockets of proposed for each transaction, and then test in them
<juliank> you'd also remove the stuff you're migrating from the release pocket
<Laney> right
<Laney> which is what britney is doing
<juliank> Map trigger -> transaction, remove all binaries in transaction from release Packages files in, remove everything not in transaction in proposed Packages file
<juliank> Hack that all in using grep-dctrl on /var/lib/apt/lists :D
<Laney> this sounds familiar https://bazaar.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/view/head:/update-output-helper :-)
<juliank> Laney: Basically I want britney to give me a json file which contains a list of transaction, where each transaction is a list of source packages in that transaction
<juliank> Then autopkgtest can fetch that during run and manipulate /var/lib/apt/lists with it
<Laney> We execute the test results at the wrong time
-queuebot:#ubuntu-release- Unapproved: inkscape (focal-proposed/universe) [0.92.4-5ubuntu5 => 0.92.5-1] (i386-whitelist, ubuntustudio) (sync)
<Laney> at autopkgtest-time we're going to have to re-solve given the one trigger
<locutus__> tjaalton, commit id?
<tjaalton> locutus__: 636c28e4066f13d and the next two
<locutus__> damn
<locutus__> I asked on debianllvm to upload it
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [amd64] (focal-proposed) [5ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [i386] (focal-proposed) [5ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [arm64] (focal-proposed) [5ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [ppc64el] (focal-proposed) [5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5] (i386-whitelist) (sync)
<locutus__> kanashiro, ^^
<locutus__> tjaalton, uploaded in debian, lets sync later today
<locutus__> I hope in the meanwhile the current one finishes building
<locutus__> on riscv
<wgrant> As long as -3 remains published somewhere
<wgrant> So we might want to block migration of the new one
<tjaalton> locutus__: I discussed it with sylvestre, didn't know -3 was synced already
<kanashiro> locutus__: ack (and thanks for the sync)
<tjaalton> locutus__: -3 isn't tagged btw
<locutus__> ok wgrant you mean, -3 is already in release pocket, so we can sync even now
<locutus__> nice to know, seems legit
<wgrant> locutus__: As long as we block the new one from migrating.
<locutus__> indeed!
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-calendar-tools [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-contacts [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-calendar [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-import-wizard [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-notes [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akonadiconsole [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted calligra [sync] (focal-proposed) [1:3.1.0+dfsg-6ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted grantlee-editor [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kalarm [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kblog [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: spirv-headers (focal-proposed/universe) [1.5.1-4 => 1.5.1+git20200409-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: vulkan-loader (focal-proposed/main) [1.2.131.2-1 => 1.2.135.0-2] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-mime [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akregator [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kaddressbook [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (focal-proposed/main) [0~20191119-1 => 0~20200408-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-search [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kalarmcal [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted digikam [sync] (focal-proposed) [4:6.4.0+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: spirv-tools (focal-proposed/universe) [2020.1-2 => 2020.2-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kcalcore [sync] (focal-proposed) [5:5.68.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcontacts [sync] (focal-proposed) [5:5.68.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-addons [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kf5-kdepim-apps-libs [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kgpg [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kimap [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kitinerary [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kldap [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmail [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcalutils [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-runtime [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kidentitymanagement [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kjots [sync] (focal-proposed) [4:5.0.2-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted kdav [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kio-gdrive [sync] (focal-proposed) [1.2.7-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted kf5-messagelib [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kleopatra [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmail-account-wizard [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmbox [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmymoney [sync] (focal-proposed) [5.0.8-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted kontact [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kopete [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kpimtextedit [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmailtransport [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted knotes [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted korganizer [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmime [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kpkpass [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kontactinterface [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kraft [sync] (focal-proposed) [0.90-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted ktnef [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5eventviews [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5gravatar [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5ksieve [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5libkleo [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ksmtp [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5grantleetheme [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5libkdepim [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5calendarsupport [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5mailcommon [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5incidenceeditor [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5mailimporter [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkgapi [sync] (focal-proposed) [19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pim-data-exporter [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zanshin [sync] (focal-proposed) [0.5.71-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5pimcommon [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pim-sieve-editor [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mbox-importer [sync] (focal-proposed) [4:19.12.3-0ubuntu1]
<sil2100> Hey! Could someone else from the release team take a look at our netplan FFe?
<sil2100> https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1871825
<ubot5> Ubuntu bug 1871825 in netplan.io (Ubuntu) "[FFe] Update to netplan.io 0.99" [Critical,New]
<sil2100> We'd like to release this ASAP
<Laney> sil2100: Will do if I can swap for the ubiquity ones
<Laney> (uploading in a minute) :-)
<RikMills> Laney: thanks for ubiquity. is there a way to message translators in one go?
<Laney> there's a list (ubuntu-translators or something)
<Laney> #ubuntu-devel for installer btw
<Laney> :)
<RikMills> ok
<Laney> https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
<RikMills> .
<sil2100> Laney: just point me to it ;)
<Laney> sec
<Laney> just considering mwhudson's MP :-)
<Laney> (well, after this call)
<jibel> Laney, let me check something with download updates first
<Laney> jibel: I could leave it out for the .12 upload if you prefer
<Laney> I've got a feeling there's a nicer way to do this anyway, just trying to find what it is
<jibel> Laney, that's fine, I just finished the review and it's an improvement over what we have now.
<jibel> I'll add a comment, if you find something better go ahead.
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.11]
 * sil2100 is waiting
-queuebot:#ubuntu-release- Unapproved: mongodb (focal-proposed/universe) [1:3.6.9+really3.6.8+90~g8e540c0b6d-0ubuntu4 => 1:3.6.9+really3.6.8+90~g8e540c0b6d-0ubuntu5] (mozilla)
<sil2100> Laney: also started working on the release tracking doc, should have it nice and tidy tomorrow
<Laney> nice one
<Laney> sorry I got distracted making proposed-migration work
<Laney> someone who was editing archive-reports on snakefruit directly borked it
<cjwatson> FYI I've added a belt-and-braces check for an intermittent Contents file generation bug: https://wiki.ubuntu.com/ReleaseProcess?action=diff&rev2=126&rev1=125
<cjwatson> (yes, we should fix it properly, but limited time before release and we've already tried to fix it once)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (focal-proposed) [0.8.3-1ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (focal-proposed) [245.4-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-artwork [source] (focal-proposed) [20.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82-0ubuntu1]
<Laney> sil2100: it says preemptive, but it is ready now?
-queuebot:#ubuntu-release- Unapproved: bacula (focal-proposed/universe) [9.4.2-2ubuntu4 => 9.4.2-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bacula [source] (focal-proposed) [9.4.2-2ubuntu5]
<bdmurray> sil2100: Does that belt-and-braces check need adding to the release tracking doc?
-queuebot:#ubuntu-release- Unapproved: gvfs (focal-proposed/main) [1.44.0-1ubuntu1 => 1.44.1-1ubuntu1] (desktop-core, i386-whitelist)
<sil2100> Laney: so we have everything basically merged, I'll be preparing the release and upload 0.99 tomorrow
<sil2100> bdmurray: it will be added! I still didn't finish creating the tracking doc, so I'll make sure it's there
<sil2100> It's in the ReleaseProcess now so I'll pick it up for sure
<locutus_> doko, FYI automake is now python3 on debian
<Laney> sil2100: ah, nothing like cutting it fine
<Laney> ok, +1ed
-queuebot:#ubuntu-release- Unapproved: nginx (focal-proposed/main) [1.17.9-0ubuntu3 => 1.17.10-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libdrm (focal-proposed/main) [2.4.101-1 => 2.4.101-2] (core, i386-whitelist, xorg) (sync)
<mitya57> 0000Can someone please approve/decline ug 1871077? Universe package, not seeded, I am upstream.
<ubot5> bug 1871077 in retext (Ubuntu) "FFe: Sync retext 7.1.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1871077
 * mitya57 's IRC client got out of control, sorry for that markup :)
<Eickmeyer> sil2100: Did you get my messages regarding carla?
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20200311.1-0ubuntu2 => 1:20200414.1-0ubuntu1] (no packageset)
<sarnold> ^^^ that reminds me, can we unship flash from focal? :)
<sil2100> Eickmeyer: ah, let me find it in the logs
<sil2100> Laney: thanks! Yeah, sorry, I know it's terrible!
<sil2100> Eickmeyer: ah, I see it now, thanks for the info o/
<Eickmeyer> sil2100: Glad to help. Upstream saw that as the only way they could fix the bug.
<Eickmeyer> And with the way Jack MIDI works, they're 100% correct.
-queuebot:#ubuntu-release- Unapproved: accepted carla [source] (focal-proposed) [2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bamf (focal-proposed/universe) [0.5.3+18.04.20180207.2-0ubuntu1 => 0.5.3+18.04.20180207.2-0ubuntu2] (ubuntu-budgie, ubuntu-mate, ubuntukylin)
<Eickmeyer> THANKS! :)
<sil2100> \o/
<tumbleweed> the bamf FTBFS fix should fix ukui-menu's build on riscv64
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20200414.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200311.1-0ubuntu0.18.04.1 => 1:20200414.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200311.1-0ubuntu0.16.04.1 => 1:20200414.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200311.1-0ubuntu0.19.10.1 => 1:20200414.1-0ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (focal-proposed) [3.36.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (focal-proposed) [3.1.2-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (focal-proposed) [1.44.1-1ubuntu1]
<Laney> bah
<Laney> reverted shim-source breaks debian/rules update in ubiquity
<Laney> assuming I don't want to pull that one
<tumbleweed>  /38
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200414.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20200414.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200414.1-0ubuntu0.16.04.1]
<Laney> or maybe I do?
<Laney> well, I guess we can get that with .12
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.43.3~14.04]
<foka> jbicha: Thank you so much for bringing the latest versions of Hugo and LilyPond into focal!
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (focal-proposed/multiverse) [32.0.0.344ubuntu2 => 32.0.0.363ubuntu1] (no packageset)
<foka> Unfortunately, Hugo 0.68.3-1 is still stuck in proposal due to the following:
<foka> missing build on i386: golang-github-gohugoio-hugo-dev (from 0.59.1-1.1)
<foka> missing build on riscv64: golang-github-gohugoio-hugo-dev (from 0.59.1-1.1)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (focal-proposed) [32.0.0.363ubuntu1]
<foka> That is actually because golang-github-gohugoio-hugo-dev has been removed since 0.66.0-2.  I wonder why other architectures are OK with the binary package removal, but not i386 and riscv64.
<foka> Could someone look into getting hugo unstuck?  Many thanks!
<rbalint> is there anyone looking at glibc ftbfs on riscv64 ?
<rbalint> vorlon, maybe? ^
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.10 => 20.04.11] (core)
<Laney> sil2100: ok, ubiquity uploaded for your trade-payback o/ (two FFe bugs linked)
<vorlon> rbalint: it's a regression in the build environment.  I haven't had time to start reproducing / debugging yet
<rbalint> vorlon, how about i disable tests for riscv in the next upload if i need to perform one and we can restore the tests later?
<vorlon> rbalint: can you please disable just the 2 failing tests?
<rbalint> vorlon, ok, i'll try that then
-queuebot:#ubuntu-release- Unapproved: backstep (focal-proposed/universe) [0.3-0ubuntu7 => 0.3-0ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted backstep [source] (focal-proposed) [0.3-0ubuntu8]
<sil2100> Laney: ok, looking in a moment!
-queuebot:#ubuntu-release- Unapproved: ardour (focal-proposed/universe) [1:5.12.0-3ubuntu3 => 1:5.12.0-3ubuntu4] (ubuntustudio)
<Eickmeyer> ^ Critical bugfix, upload by cjwatson (THANKS! :) )
<Eickmeyer> sil2100: If you wouldn't mind ushering ardour through, that would be awesome. Huge usability bugfix.
<cjwatson> ^- diff a bit larger than you might expect; details in #ubuntu-devel, but basically the orig tarball was previously unnecessarily divergent from Debian, and this caused some of the patches needed in this version to fail to apply properly when building the source package.  Fortunately the two orig tarballs had different compression extensions so it was possible to substitute the Debian one in ...
<cjwatson> ... without too much trouble.
<cjwatson> The excess diff is mostly things like removing MSVC bits and bobs
<Eickmeyer> The main thing is the included audio plugins weren't failing to build with 3ubuntu3, but were failing to execute.
<RikMills> sil2100: KDE PIM migrated on 1st britney run it seems. thanks!
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (focal-proposed/main) [1:10.0.0-3 => 1:10.0.0-4] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: vlc (focal-proposed/universe) [3.0.8-4 => 3.0.9.2-1] (i386-whitelist, kubuntu, mozilla) (sync)
<LocutusOfBorg> not sure if vlc can be accepted or not, feel free to reject (we usually update it as SRU anyway)
<tjaalton> please ack libdrm, adds a patch to fix webgl on firefox with intel gfx
<tjaalton> not just intel, but amd/nouveau too
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (focal-proposed) [2.4.101-2]
<tjaalton> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (focal-proposed) [1:3.6.9+really3.6.8+90~g8e540c0b6d-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [sync] (focal-proposed) [2.7.0-5]
<vorlon> wgrant: https://launchpad.net/ubuntu/+source/rustc/1.41.0+dfsg1+llvm-0ubuntu2/+build/19157331 shows as built and published but it hasn't shown up on the mirrors 3 hours after build, do you know why?
-queuebot:#ubuntu-release- Unapproved: landscape-client (focal-proposed/main) [19.12-0ubuntu3 => 19.12-0ubuntu4] (ubuntu-server)
 * vorlon wonders if it was a race between publication of the binaries to -proposed and publication of the source to release
<RikMills> vorlon: thanks for the help and patience with Qt last night!
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (eoan-proposed) [3.30.6-2ubuntu10.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.15]
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (eoan-proposed) [1.0.6-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [source] (eoan-proposed) [0.10.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (eoan-proposed) [0.6.0-1.2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (focal-proposed/main) [2.28.0-1ubuntu2 => 2.28.1-1] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (bionic-proposed) [0.6.0-1ubuntu0.2]
<wgrant> vorlon: looks to me like the publisher might be very slow atm
<wgrant> https://launchpad.net/ubuntu/focal/riscv64/rustc will tell you if the binary was eaten by some race
-queuebot:#ubuntu-release- New binary: openjdk-15 [s390x] (focal-proposed/universe) [15~18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ufraw [source] (bionic-proposed) [0.22-3.1ubuntu0.1]
<teward> release team: as the past few LTS cycles, we've been keeping NGINX as close to the cut of NGINX Stable from NGINX Mainline.  To that end, we have an FFe that needs handled and nginx approved from the Upload queue - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1872774 - there's only one addition between 1.17.9 and 1.17.10 from upstream, a new directive in the system for authentication delays.
<ubot5> Ubuntu bug 1872774 in nginx (Ubuntu) "[FFe needed] Please update NGINX to 1.17.10" [Undecided,New]
<teward> would love for it to be approved :)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.43.3+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.44.2+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.44.1+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (eoan-proposed) [2.43.3+19.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (eoan-proposed) [2.44.2+19.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (eoan-proposed) [2.44.1+19.10]
-queuebot:#ubuntu-release- Unapproved: base-installer (focal-proposed/main) [1.158ubuntu5 => 1.158ubuntu6] (core, i386-excludes)
<xnox> Laney:  base-installer ^ is the beginning of a fix for https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1871523 => portions of base-installer that ubiquity wraps, never considered "hwe" "oem" "lowlatency" as valid kernels. Thus any images with more than one flavour, and at least one of the above, does weird things when installing the right target kernel.
<ubot5> Ubuntu bug 1871523 in ubiquity (Ubuntu Focal) "linux-modules-5.4.0-1002-oem installed after installing focal beta" [High,Triaged]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.43.3]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.44.2]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.44.1]
<xnox> Laney:  more fixes needed in ubiquity, which wrap portions of that base-installer code.
<xnox> so this is just prologue
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (focal-proposed/universe) [1.0.20200401-1ubuntu1 => 1.0.20200413-0ubuntu1] (no packageset)
<Ukikie> Can â get rejected?  The tests weren't included.
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (focal-proposed) [1.0.20200413-0ubuntu1]
<Ukikie> ....OK, or not.
<xnox> well, too slow =)
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (focal-proposed/universe) [1.0.20200401-1ubuntu1 => 1.0.20200413-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (focal-proposed) [1.0.20200413-0ubuntu2]
-queuebot:#ubuntu-release- New binary: openjdk-15 [ppc64el] (focal-proposed/universe) [15~18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wpewebkit (focal-proposed/universe) [2.28.0-1 => 2.28.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wpewebkit [sync] (focal-proposed) [2.28.1-1]
-queuebot:#ubuntu-release- Unapproved: broadcom-sta (focal-proposed/multiverse) [6.30.223.271-11 => 6.30.223.271-12] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted broadcom-sta [sync] (focal-proposed) [6.30.223.271-12]
#ubuntu-release 2020-04-15
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.1-4ubuntu1 => 3.36.1-5ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (focal-proposed/main) [1.447 => 1.448] (core)
-queuebot:#ubuntu-release- Unapproved: jtreg (focal-proposed/universe) [5.0-b01-2ubuntu2 => 5.0-b01-2.1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: flowblade (focal-proposed/universe) [2.4-1 => 2.4.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flowblade [sync] (focal-proposed) [2.4.0.1-2]
-queuebot:#ubuntu-release- Unapproved: mozjs68 (focal-proposed/main) [68.6.0-1 => 68.6.0-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: openjdk-15 [amd64] (focal-proposed/universe) [15~18-1ubuntu1] (no packageset)
<vorlon> wgrant: publisher, or mirroring?
<wgrant> vorlon: publisher, I think
-queuebot:#ubuntu-release- Unapproved: libinput (focal-proposed/main) [1.15.4-1 => 1.15.5-1] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-evdev (focal-proposed/universe) [1:2.10.6-1 => 1:2.10.6-2] (ubuntukylin, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (focal-proposed/main) [2:2.99.917+git20190815-1 => 2:2.99.917+git20200226-1] (desktop-core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: curl (focal-proposed/main) [7.68.0-1ubuntu1 => 7.68.0-1ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: wslu (focal-proposed/main) [2.3.2-0ubuntu4 => 2.3.6-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected wslu [source] (focal-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: wslu (focal-proposed/main) [2.3.2-0ubuntu4 => 2.3.6-0ubuntu1] (core)
<seb128> ^ wslu is important for the WSL team, would be nice to have it accepted
<seb128> they wrote rational and testing on https://bugs.launchpad.net/ubuntu/+source/wslu/+bug/1872879
<ubot5> Ubuntu bug 1872879 in wslu (Ubuntu) "update to land on ff-main before release" [Critical,New]
<tjaalton> is there something blocking llvm-toolchain-10? I have a pending mesa update which would migrate it to llvm-10 and adds a couple of bugfixes. the migration to llvm-10 itself is said to fix gpu hangs on certain amd cards (according to debian #956004)
<ubot5> Debian bug 956004 in src:mesa "Please build Mesa against llvm 10" [Wishlist,Open] http://bugs.debian.org/956004
<sil2100> seb128: will take a look
<sil2100> seb128: ok, this is by no means an issue, but wanted to point that out just in case: looks weird that some patches were just renamed with their patch numbers bumped for no reason, like 0006-Fix-empty-.config-wslu-baseexec.patch became 0009-Fix-empty-.config-wslu-baseexec.patch, but actually there is no 0006 patch used
<sil2100> seb128: so the numeration is now like 0004 then 0008, 0009, 0010 etc.
<sil2100> But as said, just pointing that out, not an issue ;)
-queuebot:#ubuntu-release- Unapproved: accepted curl [source] (focal-proposed) [7.68.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (focal-proposed) [2.3.6-0ubuntu1]
<seb128> sil2100, thanks for looking, yeah those changes are not needed at this point but I didn't want to go through another roundtrip :/
<seb128> but I agree with you
<seb128> I will give them the feedback for next time
<ginggs> would someone please 'force-reset-test octave-communications/1.2.2-1build1/ppc64el' ? octave-communications was removed on ppc64el
<seb128> thanks for accepting!
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu3 => 2:2.9-1ubuntu4] (core)
<xnox> tjaalton: llvm-toolchain-10 is in release, and it is the default version.
<xnox> tjaalton: where do you see llvm-10 having a block?
<tjaalton> xnox: -4?
<tjaalton> was synced
<tjaalton> on the queue
<xnox> tjaalton: yes, awaiting manual review. We are frozen for release and all seeded uploads go through human review. https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=
<Laney> apw: want to review xnox's base-installer in the queue?
<locutus__> we need the one in unapproved after riscv publishes
<Laney> I've a feeling I won't give the best quality oversight there:-)
<tjaalton> xnox: yes I know that
<xnox> Right ok. I don't think it is "blocked", it's just waiting.
<tjaalton> wgrant: you mentioned yesterday that the llvm sync (-4) can't migrate yet, because you needed -3 for something still?
<wgrant> tjaalton: -3 needs to remain published somewhere in the primary archive so the riscv64 build can complete
<tjaalton> ah
<wgrant> But it's in the release pocket now, so it would be sufficient to prevent -4 from migrating I suppose
<tjaalton> how long does it make to build? :)
<tjaalton> *take
<xnox> Days
<tjaalton> sigh :)
<tjaalton> what is this risc thing used for anyway? :)
<tjaalton> (nevermind)
<locutus__> wgrant, you can accept it *now* and I can open a block-proposed bug
<locutus__> so we don't loose days
<wgrant> locutus__: I'm not on the release team, but that sounds like a reasonable idea, yeah
<locutus__> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1872932
<ubot5> Ubuntu bug 1872932 in llvm-toolchain-10 (Ubuntu) "block the -4 until -3 publish on riscv64" [Undecided,New]
<locutus__> done
-queuebot:#ubuntu-release- Unapproved: openmpi (focal-proposed/universe) [4.0.3~rc4-0ubuntu2 => 4.0.3-0ubuntu1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.20-0ubuntu1 => 0.9.22-0ubuntu1] (ubuntustudio)
<tjaalton> locutus__: thanks
-queuebot:#ubuntu-release- Unapproved: gcc-10 (focal-proposed/main) [10-20200411-0ubuntu1 => 10-20200411-0ubuntu2] (i386-whitelist)
<RikMills> kubuntu and xubuntu ISOs failed to build today (maybe others) https://paste.ubuntu.com/p/rWXwnGdQrK/
<Laney> should be fixed if you retry
<mitya57> Can someone please approve/decline bug 1871077? Universe package, not seeded, and I would really like to have it in before the final freeze.
<ubot5> bug 1871077 in retext (Ubuntu) "FFe: Sync retext 7.1.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1871077
<mitya57> sil2100: maybe I can ask you? â
<sil2100> mitya57: looking now o/
<Laney> mitya57: Looks ok, you can go ahead (feel free to paste this into the bug)
 * Laney steals from sil2100 
<sil2100> eeek, ok, just gave a +1 on teh bug anyway
<sil2100> mitya57: so a +2 then, please sync!
<mitya57> sil2100: thanks a lot!
<mitya57> And thanks Laney too :)
-queuebot:#ubuntu-release- New binary: openjdk-15 [arm64] (focal-proposed/universe) [15~18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: retext (focal-proposed/universe) [7.0.4-1 => 7.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: yaru-theme (focal-proposed/main) [20.04.4 => 20.04.5] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted retext [sync] (focal-proposed) [7.1.0-1]
-queuebot:#ubuntu-release- Unapproved: chrony (focal-proposed/main) [3.5-6ubuntu3 => 3.5-6ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: chrony (bionic-proposed/main) [3.2-4ubuntu4.2 => 3.2-4ubuntu4.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted wpa [source] (focal-proposed) [2:2.9-1ubuntu4]
<jbicha> ubuntu-archive please take a look at some removal requests: bug 1872588 bug 1872590 bug 1872593 bug 1872598
<ubot5> bug 1872588 in pyrit (Ubuntu) "Please remove pyrit from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872588
<ubot5> bug 1872590 in ifupdown2 (Ubuntu) "Please remove ifupdown2 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872590
<ubot5> bug 1872593 in dh-kpatches (Ubuntu) "Please remove dh-kpatches from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872593
<ubot5> bug 1872598 in ipython-py2 (Ubuntu) "Please remove ipython-py2 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872598
-queuebot:#ubuntu-release- Unapproved: akonadi (focal-proposed/universe) [4:19.12.3-0ubuntu1 => 4:19.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksmtp (focal-proposed/universe) [19.12.3-0ubuntu1 => 19.12.3-0ubuntu2] (kubuntu)
<RikMills> sil2100: ^^ couple of fixes for PIM
<RikMills> Laney: thanks. retrying ISO :)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (focal-proposed) [4:19.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ksmtp [source] (focal-proposed) [19.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (focal-proposed) [1.448]
-queuebot:#ubuntu-release- Unapproved: what-is-python (focal-proposed/main) [3 => 4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: feedreader (focal-proposed/universe) [2.10.0-1 => 2.10.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted feedreader [sync] (focal-proposed) [2.10.0-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted what-is-python [source] (focal-proposed) [4]
-queuebot:#ubuntu-release- Unapproved: oem-somerville-three-eyed-raven-meta (focal-proposed/main) [20.04~ubuntu1 => 20.04~ubuntu2] (no packageset)
<ginggs> would someone please approve openmpi?  it would be nice to ship with the final release instead of release candidate 4.  upstream changelog mentions a couple of bugs squashed
<apw> Laney: looks ok ... done
-queuebot:#ubuntu-release- Unapproved: accepted base-installer [source] (focal-proposed) [1.158ubuntu6]
<Laney> merci!
-queuebot:#ubuntu-release- Unapproved: git (focal-proposed/main) [1:2.25.1-1ubuntu1 => 1:2.25.1-1ubuntu2] (core, i386-whitelist)
<Laney> locutus__: why are we taking a new version of meson now?
-queuebot:#ubuntu-release- Unapproved: base-files (focal-proposed/main) [11ubuntu4 => 11ubuntu5] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: python-launchpadlib (focal-proposed/main) [1.10.10-1 => 1.10.11-1] (core) (sync)
<locutus__> Laney, I dont' remember, python fixes, boost fixes, and some cmake integration of libsdl or similar, that IIRC was preventing something in the archive from building correctly, but after one week I forgot... I remember I wrote it here
<locutus__> https://mesonbuild.com/Release-notes-for-0-54-0.html
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu25 => 2.04-1ubuntu26] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.141 => 1.142] (core)
<Laney> well it's not like meson updates have always been plain sailing ...
-queuebot:#ubuntu-release- Unapproved: vim (focal-proposed/main) [2:8.1.2269-1ubuntu4 => 2:8.1.2269-1ubuntu5] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: mariadb-10.3 (focal-proposed/universe) [1:10.3.22-1 => 1:10.3.22-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.3 [source] (focal-proposed) [1:10.3.22-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: base-installer (focal-proposed/main) [1.158ubuntu6 => 1.158ubuntu7] (core, i386-excludes)
<xnox> Laney:  apw: now with extra testsuite FTBFS fixes
<Laney> nice to know it was test built ð°
<xnox> hahahhahahaha
<xnox> Laney:  yes because those alpha arch tests are real
-queuebot:#ubuntu-release- Unapproved: latte-dock (focal-proposed/universe) [0.9.10-0ubuntu1 => 0.9.11-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: smb4k (focal-proposed/universe) [3.0.3-1 => 3.0.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted smb4k [source] (focal-proposed) [3.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20200414.1-0ubuntu1 => 1:20200414.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted oem-somerville-three-eyed-raven-meta [source] (focal-proposed) [20.04~ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openmpi [source] (focal-proposed) [4.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (focal-proposed) [19.12-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (bionic-proposed) [3.2-4ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (focal-proposed/universe) [8u252-b07-1 => 8u252-b09-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [source] (focal-proposed) [8u252-b09-1]
-queuebot:#ubuntu-release- Unapproved: modemmanager (focal-proposed/main) [1.12.6-1 => 1.12.8-1] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (focal-proposed/main) [11.0.7+9-1ubuntu1 => 11.0.7+10-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.1-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pop-gtk-theme (focal-proposed/universe) [5.0.0~1576602011~19.10~7760154~ubuntu1 => 5.0.0~1576602011~19.10~7760154~ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pop-gtk-theme [source] (focal-proposed) [5.0.0~1576602011~19.10~7760154~ubuntu2]
<teward> just another poke but we're trying to keep as close to NGINX next-stable so when they cut it from Mainline it's only a version string change.  There's precedent in this from other cycles.  https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1872774 is the FFe request bug, and this is already in the Unapproved queue.
<ubot5> Ubuntu bug 1872774 in nginx (Ubuntu) "[FFe needed] Please update NGINX to 1.17.10" [Undecided,New]
<Eickmeyer> Release team: Please ack ardour, it's a critical bugfix upload. Version before (no-change rebuild against libgcc-s1) was failing in areas of key functionality.
<Eickmeyer> (bug 1872555)
<ubot5> bug 1872555 in ardour (Ubuntu) "the included a-* plugins can not load because of the new version of the GNU C Library" [Critical,Fix committed] https://launchpad.net/bugs/1872555
<teward> re: nginx - the intent is once 1.18.0 releases there's minimal changes (version strings only essentially) as a just-before-release or just-after-relase SRU to get us onto the proper version string (but also the proper set of revisions, etc.)
<teward> infinity is aware of such precedents in the last several LTS cycles as well (this isn't necessarily a new thing but it still needs FFe exception and approval from the queue)
-queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.3 => 0.4.4] (no packageset)
<cpaelzer> could someone cancel chrony 3.5-6ubuntu4 from focal-unapproved I identified another fix that we need
<cpaelzer> if not rejected but also not accepted once I have the next upload ready I'll upload a new version but include both in the .changes file - so really look at the version to cancel
<cpaelzer> just in case the newer one is already in -unapproved by then
-queuebot:#ubuntu-release- Unapproved: open-iscsi (focal-proposed/main) [2.0.874-7.1ubuntu5 => 2.0.874-7.1ubuntu6] (ubuntu-desktop, ubuntu-server)
<xnox> Odd_Bloke:  ^
<xnox> awaiting review
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (focal-proposed/main) [158 => 159] (ubuntu-desktop)
<Odd_Bloke> xnox: Thanks!  Who do we need to poke for review?
<xnox> Odd_Bloke:  ~ubuntu-release team
<xnox> Odd_Bloke:  they are reviewing things constantly though. so wait a bit i guess
<Odd_Bloke> Cool.
<seb128> could webkit2gtk from the queue be accepted? it's a .1 bugfix version and it usually takes some time to build/autopkgtest so would be nice to have it in today
<seb128> the ubuntu diff to fix ppc is in the new version
-queuebot:#ubuntu-release- Unapproved: sshguard (focal-proposed/universe) [2.3.1-1 => 2.3.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sshguard [source] (focal-proposed) [2.3.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.4]
<rbalint> ubuntu-release: needed revert per Ubuntu's decision to stick to iptables ^^
<rbalint> nevermind, it got approved automatically as i see
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (focal-proposed) [2.0.874-7.1ubuntu6]
<Odd_Bloke> \o/
<jchittum> w00 Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (focal-proposed) [11.0.7+10-2ubuntu1]
-queuebot:#ubuntu-release- Packageset: Added openjdk-12 to i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20200414.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-launchpadlib [sync] (focal-proposed) [1.10.11-1]
-queuebot:#ubuntu-release- Unapproved: manila-ui (focal-proposed/universe) [1:2.19.2~git2020041315.301fc4e-0ubuntu1 => 1:2.19.2~git2020041511.a2dcb0e-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (focal-proposed) [1:2.19.2~git2020041511.a2dcb0e-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.4-dfsg-4ubuntu20.04.1 => 6.1.6-dfsg-1ubuntu20.04.1] (no packageset)
<LocutusOfBorg> wgrant, I don't think llvm-toolchain-10 will ever end on riscv64
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.6-dfsg-1ubuntu20.04.1]
<LocutusOfBorg> tjaalton, where is xserver-xorg-dev-hwe-20.04?
<wgrant> LocutusOfBorg: A *really* well-timed network glitch made LP think the buildd had died. The build is still going in the background, and I'll fix LP's view of it in the morning.
<wgrant> Same with opencv
<wgrant> *great* timing.
<tjaalton> LocutusOfBorg: how so?
<tjaalton> LocutusOfBorg: I mean, why'd you need one?
-queuebot:#ubuntu-release- Unapproved: chrony (focal-proposed/main) [3.5-6ubuntu3 => 3.5-6ubuntu5] (core)
<cpaelzer> can someone please accept that chrony focal upload of 3.5-6ubuntu5 that we see above
<cpaelzer> that will avoid some issues due to systemd changes with timesyncd
<cpaelzer> rbalint: FYI ^^ this includes the test hardning for 1873031
<cpaelzer> let me know what you intend for 1873031 for systemd itself once you have decided on an approach, I'm interested to stay in the loop how all that goes forward
<cpaelzer> for requests like the one above, can we already group-highlight ubuntu-release the same way we can for ubuntu-archive?
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (focal-proposed) [2.4.41-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [sync] (focal-proposed) [3.36.0-3]
-queuebot:#ubuntu-release- Unapproved: rejected gcc-10 [source] (focal-proposed) [10-20200411-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (focal-proposed) [159]
-queuebot:#ubuntu-release- Unapproved: clevis (eoan-proposed/universe) [11-2 => 11-2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: clevis (bionic-proposed/universe) [8-1 => 8-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hedgewars (focal-proposed/universe) [1.0.0-4ubuntu1 => 1.0.0-5] (no packageset) (sync)
<LocutusOfBorg> tjaalton, shouldn't somebody provide the new 20.04 virtual package?
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (focal-proposed) [1.0.0-5]
<tjaalton> LocutusOfBorg: eventually
<Eickmeyer> Release team: Please ack ardour, it's a critical bugfix upload. Version before (no-change rebuild against libgcc-s1) was failing in areas of key functionality. (bug 1872555)
<ubot5> bug 1872555 in ardour (Ubuntu) "the included a-* plugins can not load because of the new version of the GNU C Library" [Critical,Fix committed] https://launchpad.net/bugs/1872555
-queuebot:#ubuntu-release- New: accepted openjdk-15 [amd64] (focal-proposed) [15~18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-15 [ppc64el] (focal-proposed) [15~18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-15 [arm64] (focal-proposed) [15~18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-15 [s390x] (focal-proposed) [15~18-1ubuntu1]
<sil2100> Eickmeyer: let me take a look
<ahasenack> hello, could someone please badtest mongodb i386? It's not built for that arch
<ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mongodb
<sil2100> Eickmeyer: I see the upload removes quite a lot of files as well, were those some unrelated leftovers?
<sil2100> Eickmeyer: like libs/ardour/msvc/msvc_libardour.cc etc
<Eickmeyer> sil2100: Yes, those were unrelated leftovers. Previous version of the .orig used a repack I did, this one's straight from the Debian archives with a bunch of patches.
<Eickmeyer> sil2100: cjwatson has further information in the backscroll, he did the upload.
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (focal-proposed/main) [3.36.1-1 => 3.36.1-2] (i386-whitelist, ubuntu-desktop) (sync)
<sil2100> Eickmeyer: ah, ok! ;)
-queuebot:#ubuntu-release- Unapproved: accepted ardour [source] (focal-proposed) [1:5.12.0-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.5 => 1:20.04.6] (core)
<bdmurray> sil2100: I'm deactivating milestones for 20.04 that have passed. Is that documented anywhere?
<Eickmeyer> Thanks, sil2100!!!
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.5.0-2ubuntu1 => 1:4.5.0-2ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted vim [source] (focal-proposed) [2:8.1.2269-1ubuntu5]
<Laney> bdmurray: that doesn't happen when the date passes?
<Laney> apparently not
<bdmurray> Ooh, we could make it LP's problem
<Laney> I checked ubuntu-18.04.3 which is in the past but still active
 * Laney is having fun pdb-ing britney2.py
<Laney> trying to find out why BREAK_ARCHES is not breaking the arch
<vorlon> Laney: from code inspection, I understand that it only affects the update_output phase, not the excuses phase; so a package which is a candidate is allowed to break OTHER packages on the arch and increase uninstallability count, but a package which has unsatisfiable deps will still not be a candidate even if it's already uninstallable in release :P
<seb128> could webkit2gtk from the queue be accepted? it's a .1 bugfix version and it usually takes some time to build/autopkgtest so would be nice to have it in today
<seb128> the ubuntu delta being dropped was not a mistake, the packaging changes are in debian
<seb128> the ppc fix is in the new upstream version
<vorlon> syncs are harder to review fwiw
<seb128> someone should improve the review tools, that keeps being an issue :-/
<seb128> it's not paying us back for being good citizen, we get our diff in Debian and lower work but that get in the way of the work to land :(
<sil2100> Reviewing source syncs for me got a bit easier after I made a stupid wrapper script that does the diff and diffstat for me
<sil2100> Binary syncs are still an issue
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (focal-proposed) [2.28.1-1]
<vorlon> Laney: oh, but then I also see that cairo-dock-plug-ins/riscv4 is a candidate, but not accepted because it increases uninstallability, shrug
<doko> sil2100: well, sometimes you are requesting those ;p
-queuebot:#ubuntu-release- Packageset: Added openjdk-13 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added openjdk-14 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added openjdk-15 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added openjdk-8 to i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: rejected meson [source] (focal-proposed) [0.54.0-1ubuntu1]
<Laney> vorlon: I'm looking at things being invalidated at excuses, like gvfs
<Laney> probably not going to get there tonight
<sil2100> doko: but here I know the diff beforehand ;)
<sil2100> But yes ;p
<jdstrand> hey, can someone push isc-dhcp through? it isn't migrating cause of chrony breakage wrt systemd changes: time-sources-from-dhcp-servers FAIL stderr: Failed to try-restart systemd-timesyncd.service: Unit systemd-timesyncd.service is masked.
<jdstrand> that seems related to bug #1872902
<ubot5> bug 1872902 in ubuntu-release-upgrader (Ubuntu) "Upgrade to Focal now removes chrony" [Critical,Confirmed] https://launchpad.net/bugs/1872902
<jdstrand> that might be the wrong bug
 * jdstrand looks
<jdstrand> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849156/comments/15
<ubot5> Ubuntu bug 1849156 in ntp (Ubuntu Focal) "systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: accepted bamf [source] (focal-proposed) [0.5.3+18.04.20180207.2-0ubuntu2]
<jdstrand> and the actual bug for this is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1873031
<ubot5> Ubuntu bug 1873031 in systemd (Ubuntu) "245.4-2ubuntu1 has broken dhcp based NTP updates" [Undecided,New]
<ahasenack> Laney: hi, around? Could you please add mongodb./i386 to your badtest hint? You have a section saying it's no longer built for armhf and i386, but only badtest armhf
<ahasenack> commit 2522
<Laney> ahasenack: I did add it then, it must have been dropped later, can you find that?
<ahasenack> does bzr have the equivalent of git log -S?
<ahasenack> :)
 * Laney dunno
<ahasenack> https://launchpad.net/bzr-grep
<cpaelzer> jdstrand: yes you found the right bug 1849156
<ubot5> bug 1849156 in ntp (Ubuntu Focal) "systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed" [Undecided,Confirmed] https://launchpad.net/bugs/1849156
<cpaelzer> jdstrand: a fix for that is waiting in focal-unapproved
<cpaelzer> that will make the test resilient against the stderr that is thrown until systemd has fixed it for real
<ahasenack> found it
<ahasenack> Laney:
<ahasenack> === revno:4277 ===
<ahasenack>   === modified file 'laney'
<ahasenack>     -force-badtest mongodb/all/i386
<cpaelzer> jdstrand: I'm waiting for someone in ubuntu-release to accept it and have pinged a few times already
<jdstrand> cool. I don't think that isc-dhcp in -proposed needs to be hung up on that though
<ahasenack> message:
<ahasenack>   drop many i386 hints that are no longer needed
<ahasenack> vorlon dropped it
<jdstrand> cpaelzer: ack, thanks
<cpaelzer> if that is the only thing left I agree
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (focal-proposed) [1.64.1-2ubuntu1]
<Eickmeyer> Release team: I think the missing piece of the puzzle is tjaalton's upload of rapid-photo-downloader needs an ack then Ubuntu Studio will be ready for Final Freeze.
<Laney> cpaelzer: Will add it back, but I'm not sure why the test got requested
<cpaelzer> Laney: what do you mean - why the chrony test got requetse don the isc-dhcp upload?
<Laney> oops
<Laney> I meant to ping ahasenack, sorry!
<Laney> you server people are all the same :p
<ahasenack> tall
-queuebot:#ubuntu-release- Unapproved: linux-aws (bionic-updates/main) [4.15.0-1066.70 => 4.15.0-1065.69] (kernel, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted base-installer [source] (focal-proposed) [1.158ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (focal-proposed) [3.5-6ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted rapid-photo-downloader [source] (focal-proposed) [0.9.22-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (focal-proposed) [3.5-6ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (focal-proposed) [20.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (focal-proposed) [1:2.25.1-1ubuntu2]
<TJ-> I added patches for weechat to fix a python3 linking regression, and recent CVEs, a few days ago but it doesn't seem to have been processed. Is there anyone could handle that before release?  Bug #1872425
<ubot5> bug 1872425 in weechat (Ubuntu) "CVE-2020-8955: backport 2.7.1 CVEs to 20.04 weechat-2.6" [Undecided,In progress] https://launchpad.net/bugs/1872425
-queuebot:#ubuntu-release- Unapproved: ruby-bunny (focal-proposed/universe) [2.14.4-2 => 2.14.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (bionic-updates) [4.15.0-1065.69]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-bunny [sync] (focal-proposed) [2.14.4-3]
<Eickmeyer> Thanks for the r-p-d accept!
-queuebot:#ubuntu-release- Unapproved: accepted mozjs68 [source] (focal-proposed) [68.6.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bind9 (focal-proposed/main) [1:9.16.1-0ubuntu1 => 1:9.16.1-0ubuntu2] (core, i386-whitelist)
<kc2bez> It looks like the Lubuntu iso build is taking a long time https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/lubuntu/+build/211713
<kc2bez> Is there a known issue? ^
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0~b3~git2020041013.e74c8f8c88-0ubuntu1 => 2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu1] (openstack, ubuntu-server)
<locutus_> ping please accept llvm-toolchain-10! it takes days to build
-queuebot:#ubuntu-release- Unapproved: pulseaudio (focal-proposed/main) [1:13.99.1-1ubuntu2 => 1:13.99.1-1ubuntu3] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (focal-proposed/universe) [1.0.20200413-1 => 1.0.20200413-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [sync] (focal-proposed) [1.0.20200413-1]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (focal-proposed/main) [1.57-0ubuntu1 => 1.57-0ubuntu2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.1-10-g71af48df-0ubuntu3 => 20.1-10-g71af48df-0ubuntu4] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: glib2.0 (focal-proposed/main) [2.64.1-1 => 2.64.2-1~fakesync1] (core, i386-whitelist)
<bdmurray> kc2bez: that looks like something we saw during the beta. Are any other images taking a long time?
<kc2bez> bdmurray: From what I looked at other flavors built in the normal time.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26]
<bdmurray> kc2bez: Okay, I'm looking into it
<kc2bez> Thanks.
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.142]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (focal-proposed) [11ubuntu5]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.620.1 => 2.620.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26 => 2.04-1ubuntu26] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26 => 2.04-1ubuntu26] (core)
-queuebot:#ubuntu-release- Unapproved: enigmail (focal-proposed/universe) [2:2.1.5+ds1-1 => 2:2.1.6+ds1-1] (mozilla) (sync)
<RikMills> vorlon: excuses says for kdepim-addons, missing build on amd64,arm64,armhf whic is not true https://launchpad.net/ubuntu/+source/kdepim-addons/19.12.3-0ubuntu1
<RikMills> Launchpad encountered an internal error during the following operation: copying package kdepim-addons.  It was logged with id OOPS-6ee96f352188b58513339ddcda5997f5.  Sorry for the inconvenience.
<RikMills> maybe that is why?
<RikMills> cjwatson wgrant?
-queuebot:#ubuntu-release- Unapproved: exo (focal-proposed/universe) [0.12.11-1 => 0.12.11-1ubuntu1] (ubuntustudio, xubuntu)
<wgrant> RikMills: That's a rare race condition in the copier, but the copy completed successfully.
<wgrant> Wow, what a mess
<RikMills> wgrant: excuses does not agree
<wgrant> Duplicate builds.
<wgrant> That's never meant to be able to happen. Quite possibly the copier succeeded but got very confused because the build state is invalid.
<RikMills> this is also fun https://launchpad.net/ubuntu/+source/kimap/19.12.3-0ubuntu1
<RikMills> in both release and proposed!
<wgrant> That at least is probably just a proposed-migration bug. That state is perfectly legal in the archive.
<wgrant> kdepim-addons, though... those duplicate builds are probably a Launchpad race.
<wgrant> One that has existed forever, but I don't think we've ever actually seen it happen.
<RikMills> aren't I lucky! lol
<wgrant> So, so lucky.
<wgrant> https://launchpad.net/ubuntu/focal/amd64/kdepim-addons <- proposed-migration deleted the binaries
<RikMills> wgrant: is kdepim-addons fixable, or should I just do a no-change rebuild and forget the ubuntu1?
<wgrant> https://launchpad.net/ubuntu/+source/kdepim-addons/19.12.3-0ubuntu1/+publishinghistory <- looks like two copies raced, creating the two sets of weird-arch builds. proposed-migration tried to migrate one of them, but the binaries didn't make it across and it left the other source publication around. So now it's trying to migrate again based on the surviving source publication, but the binaries are
<wgrant> already gone.
<wgrant> I think if I revive the binaries in -proposed it should all work.
<RikMills> wgrant: great if you could, as it is causing some users dep issues in release
<wgrant> hellooooo copier, are you there?
<wgrant> Ah, copy failed because of the duplicate builds
<wgrant> Let me see what I can do about those.
<wgrant> I already had some DB surgery planned for this morning anyway...
<RikMills> ty :)
 * wgrant also sees how many other violations there are, to see if he can just add a DB constraint\
<RikMills> for the record...
<RikMills> Launchpad encountered an internal error during the following operation: copying package kimap
<RikMills> Launchpad encountered an internal error during the following operation: copying package mbox-importer
<wgrant> I wonder if there were two proposed-migrations running in parallel, or it just got really unlucky.
<RikMills> those emails got 'filtered' by my client rules
<Ukikie> With regards to that exo upload I did, if you want a full diffoscope: http://paste.openstack.org/show/uH1u8QCjLep3WGSyRHOt/
<Ukikie> This should be fairly low impact, just !amd64 systems.
-queuebot:#ubuntu-release- Unapproved: fonts-beng-extra (focal-proposed/main) [1.0-6ubuntu1 => 1.0-7] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-deva-extra (focal-proposed/main) [3.0-4ubuntu1 => 3.0-5] (desktop-core, personal-gunnarhj) (sync)
<wgrant> RikMills: It was only kdepim-addons that lost the race here, though it's happened to seven other packages in the primary archive over time. I'll get it fixed up and revive its binaries, so proposed-migration can proceed as normal.
-queuebot:#ubuntu-release- Unapproved: fonts-gujr-extra (focal-proposed/main) [1.0-7 => 1.0.1-1] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-guru-extra (focal-proposed/main) [2.0-4ubuntu2 => 2.0-5] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-orya-extra (focal-proposed/main) [2.0-5ubuntu1 => 2.0-6] (desktop-core, personal-gunnarhj) (sync)
<RikMills> wgrant: thank you!
<Eickmeyer> Is ardour failing to migrate due to riscv64?
<Eickmeyer> Granted, it's only been 5 hours, just a little concerned.
<wgrant> missing build on riscv64: ardour (from 1:5.12.0-3ubuntu3)
<Eickmeyer> Yep, I was told I shouldn't have to worry about riscv64.
<Eickmeyer> Though, looks like it built the previous version, so likely this one will build fine too.
<Eickmeyer> Wouldn't think it would take 5 hours though, wgrant.
<wgrant> We're very used to having fast CPUs :)
<Eickmeyer> heh, indeed.
<wgrant> Though riscv64 will hopefully get faster in not too long.
<Eickmeyer> Looks like it's being emulated?
<wgrant> At present, yeah, though the actual chip I have on my desk is only faster in certain workloads :(
<Eickmeyer> Heh, oh well. Â¯\_(ã)_/Â¯
<wgrant> It's still a very slow in-order core. But there'll be some fancier ones coming in not too long, hopefully.
<Eickmeyer> Oh, that would be good.
#ubuntu-release 2020-04-16
-queuebot:#ubuntu-release- Unapproved: xfwm4 (focal-proposed/universe) [4.14.0-2ubuntu1 => 4.14.1-0ubuntu1] (i386-whitelist, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected exo [source] (focal-proposed) [0.12.11-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.1-10-g71af48df-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (focal-proposed) [1:9.16.1-0ubuntu2]
<Ukikie> Err...'devel' is an accepted convention, but I'll use focal and re-upload. :/
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (focal-proposed) [1.57-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libstaroffice (focal-proposed/universe) [0.0.6-1build1 => 0.0.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libstaroffice [sync] (focal-proposed) [0.0.7-1]
-queuebot:#ubuntu-release- Unapproved: po4a (focal-proposed/universe) [0.55-1 => 0.57-2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: debhelper (focal-proposed/main) [12.10ubuntu1 => 13ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu26 => 2.20.11-0ubuntu27] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: exo (focal-proposed/universe) [0.12.11-1 => 0.12.11-1ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.660 => 2.661] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted exo [source] (focal-proposed) [0.12.11-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu611 => 20101020ubuntu612] (core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.11 => 20.04.12] (core)
<xnox> ok, accept everything, migrate everything, and it's good enough for candidate images
-queuebot:#ubuntu-release- Unapproved: thunar (focal-proposed/universe) [1.8.12-1 => 1.8.14-0ubuntu1] (mythbuntu, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (focal-proposed/universe) [20.04.2 => 20.04.3] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: golang-defaults (focal-proposed/main) [2:1.13~1ubuntu1 => 2:1.13~1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kylin-nm (focal-proposed/universe) [1.2.3-1 => 1.2.4-1] (ubuntukylin) (sync)
<vorlon> RikMills: probably related to the publisher delays that wgrant was mentioning before - it's "published" in launchpad but hasn't made it out yet to where proposed-migration sees it
<vorlon> RikMills: oh n/m there was a lot more discussion after you highlighted me ;)
<wgrant> vorlon, RikMills: kdepim-addons should be fixed now
<wgrant> I did the DB surgery and then revived its dead binaries a few minutes ago
<vorlon> hurrah
<RikMills> wgrant: thank you :)
<wgrant> https://launchpad.net/ubuntu/focal/amd64/kdepim-addons <- published fine, so hopefully proposed-migration will catch it next time
<RikMills> great
-queuebot:#ubuntu-release- Unapproved: snapd-glib (focal-proposed/main) [1.57-0ubuntu2 => 1.57-0ubuntu3] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (focal-proposed/main) [11.0.7+10-2ubuntu1 => 11.0.7+10-2ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: boost-defaults (focal-proposed/main) [1.71.0.0ubuntu1 => 1.71.0.0ubuntu2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: keybinder-3.0 (focal-proposed/universe) [0.3.2-1 => 0.3.2-1ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-software (focal-proposed/main) [3.36.0-0ubuntu1 => 3.36.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (focal-proposed/main) [67ubuntu20.04.3 => 67ubuntu20.04.4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [20.0.4-1ubuntu1 => 20.0.4-2ubuntu1] (core, i386-whitelist, xorg)
<tjaalton> mesa ^ needs the llvm-10 sync
<tjaalton> locutus_: now llvm-10 -4 isn't tagged ;)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu26]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu26]
<tjaalton> oh, mesa ftbfs on ppc64el on debian. that's just great
<tjaalton> (because of llvm)
<tjaalton> scratch that then
<vorlon> xnox: so your livecd-rootfs is queue switches the desktop to use only generic-hwe-20.04 but I thought the plan was to offer both generic-hwe-20.04 and generic
-queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu8 => 2.31-0ubuntu9] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (focal-proposed) [1.57-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (focal-proposed) [2.31-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted resource-agents [source] (focal-proposed) [1:4.5.0-2ubuntu2]
<tjaalton> I'll upload a new mesa with just a couple of fixes in a bit
<seb128> hey there, could someone review/get in some of the pending desktop items?
<seb128> - glib2.0 first, it's a bugfix version and includes some fixes we would like to see in release, one being for a segfault that random apps are hitting (bug #1872153)
<ubot5> bug 1872153 in glib2.0 (Ubuntu) "SIGSEGV in g_source_set_ready_time()" [High,In progress] https://launchpad.net/bugs/1872153
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu1]
<seb128> - gnome-shell-extension-ubuntu-dock  has some rls targetted fixes as well
-queuebot:#ubuntu-release- Unapproved: libva (focal-proposed/universe) [2.7.0-1 => 2.7.0-2] (i386-whitelist, kubuntu) (sync)
<seb128> - and then pulseaudion evolution-data-server snapd-glib which have small but useful fixes
<tjaalton> libva ^ has a fix for mapping the proper vaapi driver to use on current mesa
<tjaalton> which uses 'iris' instead of 'i965' by default on intel
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (focal-proposed) [2.64.2-1~fakesync1]
<seb128> thanks!
<vorlon> seb128: I tried to review some of these and bounced off of the pulseaudio one, there's quite a long list of patches added without bug links so I wasn't comfortable with it
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (focal-proposed) [13ubuntu1]
<vorlon> maybe it needs more explanation, or maybe it needs someone reviewing it not at 11:30pm
<seb128> vorlon, pulseaudio we ship a rc and looks like stable isn't going to be on time for focal so I went to git and cherry picked the pending commits that looked useful, I can reduce to only the important ones if you prefer
<seb128> right
<seb128> let's see what the europeans say
<seb128> vorlon, evolution-data-server and snapd-glib should be trivial, the first one has a patch cherry picked from git and the second one is just adding dh_translations to the build so we can translate it
<vorlon> seb128: ah; an update to sync with current git would probably give me more confidence what no dependencies are missed from any of the cherry-picked patches
<seb128> vorlon, ok, feel free to reject and I will re-upload
<vorlon> bdmurray: I wonder if we should blacklist the systemctl package in Ubuntu, or if we expect folks to actually use that
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu612]
-queuebot:#ubuntu-release- Unapproved: accepted golang-defaults [source] (focal-proposed) [2:1.13~1ubuntu2]
<jibel> vorlon, hi, https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/376815 is still needed? I'm asking because there is no task for ubiquity in the linked bug report and it's fix released
<jibel> but not merged in ubiquity
<vorlon> jibel: well, in light of LP: 1869187 the implementation needs fixing
<ubot5> Launchpad bug 1869187 in shim-signed (Ubuntu Focal) "mokutil ignores timeout parameter" [High,Triaged] https://launchpad.net/bugs/1869187
<vorlon> but yes, it is still important to get this done
<vorlon> jibel: pushed a rebase + fix for LP: #1869187
<ubot5> Launchpad bug 1869187 in shim-signed (Ubuntu Focal) "mokutil ignores timeout parameter" [High,Triaged] https://launchpad.net/bugs/1869187
<jibel> thanks, I'll test and merge it
<vorlon> xnox: mentions of the community-maas seed still appear on https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
-queuebot:#ubuntu-release- Unapproved: evolution (focal-proposed/universe) [3.36.1-1 => 3.36.1-2] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-default-settings (focal-proposed/universe) [20.04.1 => 20.04.2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [20.0.4-1ubuntu1 => 20.0.4-2ubuntu1] (core, i386-whitelist, xorg)
<tjaalton> this ^ replaces the previous upload of mesa
-queuebot:#ubuntu-release- Unapproved: evolution (focal-proposed/universe) [3.36.1-1 => 3.36.1-2] (ubuntu-mate, ubuntukylin) (sync)
<LocutusOfBorg> tjaalton, we should ask sylvestre for that
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (focal-proposed/multiverse) [6.1.4-2 => 6.1.6-1] (no packageset) (sync)
<tjaalton> LocutusOfBorg: I did, he said it's mesa upstream bug
<tjaalton> anyway, mesa migration to llvm-10 is a post-release thing now
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (focal-proposed) [6.1.6-1]
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.4-dfsg-4 => 6.1.6-dfsg-1] (ubuntu-cloud) (sync)
<LocutusOfBorg> please accept vbox, its a bugfix only release with 3d guest/host acceleration fixes
<LocutusOfBorg> https://www.virtualbox.org/wiki/Changelog here the changelog
<Laney> I'm thinking
<Laney> this "upload, and then ping in the channel" thing that we have (no specific criticism of anyone)
<Laney> maybe we should give out some advice about saying the same justification you give in here in the debian/changelog instead (or a bug)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (focal-proposed/main) [1:13.99.1-1ubuntu2 => 1:13.99.1-1ubuntu3] (desktop-core, i386-whitelist, ubuntu-server)
<seb128> ^ reuploaded to match what Steve asked earlier, having a git cherrypick patch rather than individual commits
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.661]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.12]
<seb128> Laney, it makes sense imho to have the changelog describing enough to give a sense of the importance of the upload, it wouldn't hurt to recommend that yes
<seb128> (bit more problematic with syncs but at least doing it for uploads would be a positive step)
-queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.98-0ubuntu4 => 0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected spirv-headers [sync] (focal-proposed) [1.5.1+git20200409-1]
-queuebot:#ubuntu-release- Unapproved: rejected vulkan-loader [sync] (focal-proposed) [1.2.135.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected spirv-tools [sync] (focal-proposed) [2020.2-1]
<sil2100> Laney, apw, vorlon: the last-minute barely-on-time netplan 0.99 uploaded ^ (we have an FFe for it)
<Laney> not at all scary
<sil2100> I have test-built it and sanity tested it before uploading
<sil2100> That being said, we know how risky this is so both me and slyon will have eyes wide open for any regressions and ready for hotfix real quick
<tjaalton> someone rejected vulkan-loader/spirv?
<apw> not me
<tjaalton> vulkan-tools & -validationlayers, and glslang need to be removed from proposed then
<RikMills> who would be best to review (and maybe upload) a software-properties fix?
<sil2100> Not me as well, I'm busy trying not to blow up the whole world with this netplan thing
<LocutusOfBorg> tjaalton, you just need to provide information there https://bugs.launchpad.net/ubuntu/+source/vulkan-loader/+bug/1871754
<RikMills> lol. np
<ubot5> Ubuntu bug 1871754 in vulkan-validationlayers (Ubuntu) "FFE: update vulkan to 1.2.135" [Undecided,New]
<Laney> RikMills: try in #ubuntu-devel, no need for release team for that
<tjaalton> LocutusOfBorg: ah there it was
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-color-emoji [sync] (focal-proposed) [0~20200408-1]
-queuebot:#ubuntu-release- Unapproved: jackd2 (focal-proposed/main) [1.9.12~dfsg-2ubuntu1 => 1.9.12~dfsg-2ubuntu2] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected pyhamcrest [sync] (focal-proposed) [1.9.0-3]
<seb128> sil2100, we didn't get langpacks refresh this week, is that cron job still not working?
<ginggs> would someone please 'force-reset-test octave-communications/1.2.2-1build1/ppc64el' ? octave-communications was removed on ppc64el
-queuebot:#ubuntu-release- Unapproved: rejected inkscape [sync] (focal-proposed) [0.92.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (focal-proposed) [1.17.10-0ubuntu1]
<sil2100> seb128: the instance is inaccessible, probably due being out of free space - I'm trying to get it back with IS since yesterday, but anyway, me and Gunnar decided we'll just do the full refresh today/tomorrow instead
<sil2100> seb128: since we always refresh the base translations right before release
-queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [0.98.7 => 0.98.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted jtreg [sync] (focal-proposed) [5.0-b01-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlc [sync] (focal-proposed) [3.0.9.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted libinput [sync] (focal-proposed) [1.15.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted latte-dock [source] (focal-proposed) [0.9.11-0ubuntu1]
<seb128> sil2100, right, would just have been nice to be able to test/spot bugs before the base refresh...
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [sync] (focal-proposed) [3.36.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [sync] (focal-proposed) [2:2.99.917+git20200226-1]
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager [sync] (focal-proposed) [1.12.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-evdev [sync] (focal-proposed) [1:2.10.6-2]
<xnox> vorlon:  re:community-maas => horum will look
<xnox> vorlon:  debhelper diff is tiny, the biggest gain is marking lever 13 stable (the package version number change => debhelper-compat v13 provides is there)
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [sync] (focal-proposed) [2:2.1.6+ds1-1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-deva-extra [sync] (focal-proposed) [3.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-guru-extra [sync] (focal-proposed) [2.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-beng-extra [sync] (focal-proposed) [1.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-orya-extra [sync] (focal-proposed) [2.0-6]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-gujr-extra [sync] (focal-proposed) [1.0.1-1]
<xnox> vorlon:  in germinate-output community* things are empty. horum.
<tjaalton> Laney: thanks for pointing out that vulkan ffe didn't have u-r subscribed, the description is updated now
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-default-settings [source] (focal-proposed) [20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted jackd2 [source] (focal-proposed) [1.9.12~dfsg-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xfwm4 [source] (focal-proposed) [4.14.1-0ubuntu1]
<locutus_> wgrant, what happened to the riscv64 machine?
<locutus_> [BUILDING] Currently building on riscv64-qemu-lcy01-002 (8C, 20GiB) on riscv64-qemu-lcy01-002 (8C, 20GiB) Cancel build
<locutus_> is it building twice on the same machine? network error?
-queuebot:#ubuntu-release- Unapproved: libxcomposite (focal-proposed/main) [1:0.4.5-0ubuntu1 => 1:0.4.5-1] (core, i386-whitelist, xorg) (sync)
<wgrant> locutus_: A display artifact from the surgery to revive it
<wgrant> A harmless mistake on my part
-queuebot:#ubuntu-release- Unapproved: libxdamage (focal-proposed/main) [1:1.1.5-1 => 1:1.1.5-2] (core, i386-whitelist, xorg) (sync)
<locutus_> if its harmless, its ok then :)
-queuebot:#ubuntu-release- Unapproved: libxfixes (focal-proposed/main) [1:5.0.3-1 => 1:5.0.3-2] (core, i386-whitelist, xorg) (sync)
<Laney> ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²ð²
<Laney> think I understood what the BREAK_ARCHES problem is
-queuebot:#ubuntu-release- Unapproved: libxres (focal-proposed/main) [2:1.2.0-3 => 2:1.2.0-4] (i386-whitelist, ubuntu-desktop, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vmware (focal-proposed/main) [1:13.3.0-2build1 => 1:13.3.0-3] (desktop-core, xorg) (sync)
<Laney> the package gets rejected by the autopkgtest policy
<sil2100> apw: since Laney is probably deep in britney debugging now, maybe you would like to review the big netplan.io 0.99 FFe'd upload in the queue?
<locutus_> sil2100, I would appreciate a virtualbox review, its made of bugfixes on the guest 3d acceleration parts, something we really would like to have in our iso...
<locutus_> I can privately say something more if you are interested in what happened
<Laney> everything will be reviewed
<Laney> you might have noticed that I did a ton this morning already :-)
<locutus_> yep, and thanks for that!
<sil2100> locutus_: yeah, we're doing our best o/
<locutus_> sil is usually doing a great job on vbox part, this is why I ping directly :)
<locutus_> also, if you want to accept llvm-toolchain-10, there is a block-proposed bug already, that makes sure riscv64 finishes before going in release
<locutus_> it takes days to build, and it contains s390x fixes for mesa builds...
<locutus_> otherwise I can do in bileto and publish when the riscv64 build is fine, just let me know if you prefer this way
<cpaelzer> SRU Team (and or rbasak who reviewed the last one) - https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1872183/comments/17
<ubot5> Ubuntu bug 1872183 in chrony (Ubuntu) "package chrony 3.2-4ubuntu4.2 failed to install/upgrade: installed chrony package post-removal script subprocess returned error exit status 1" [Undecided,In progress]
<cpaelzer> the new chrony in bionic-unapproved will fix the test issues, I'd appreciate if it could get into bionic-proposed asap
<Laney> locutus_: yeah bileto makes me more comfortable tbh
-queuebot:#ubuntu-release- Unapproved: rejected llvm-toolchain-10 [sync] (focal-proposed) [1:10.0.0-4]
<locutus_> Laney, do we have riscv64 on bileto?
<locutus_> seems like we have it, I just opened one without
<locutus_> btw wrt inkscape delta, the ppc64el can be dropped, the python move not, mapreri will upload in debian later today
<locutus_> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/19167017
<locutus_> (but a plain sync of inkscape works with virtual python-dev provides)
<locutus_> wgrant, are you sure the build isn't stuck? https://launchpad.net/ubuntu/+source/llvm-toolchain-10/1:10.0.0-3/+build/19151969 the changelog looks always the same...
-queuebot:#ubuntu-release- Unapproved: chrony (bionic-proposed/main) [3.2-4ubuntu4.3 => 3.2-4ubuntu4.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (focal-proposed/main) [3.24.17-3ubuntu1 => 3.24.18-1ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected evolution [sync] (focal-proposed) [3.36.1-2]
-queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [0.98.7 => 0.98.9] (core)
-queuebot:#ubuntu-release- Unapproved: golang-1.14 (focal-proposed/universe) [1.14.2-1 => 1.14.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.14 [source] (focal-proposed) [1.14.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gpodder (focal-proposed/universe) [3.10.13-1 => 3.10.15-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpodder [sync] (focal-proposed) [3.10.15-1]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (focal-proposed/main) [1:3.36.1-1ubuntu4 => 1:3.36.1-1ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (focal-proposed) [6.1.6-dfsg-1]
 * sil2100 winks on the netplan.io upload in the queue
-queuebot:#ubuntu-release- Unapproved: smb4k (focal-proposed/universe) [3.0.4-0ubuntu1 => 3.0.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted smb4k [sync] (focal-proposed) [3.0.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (focal-proposed) [3.24.18-1ubuntu1]
<locutus_> is it possible to kick out golang-github-census-instrumentation-opencensus-proto from focal? new package, autopkgtest failure/flaky in debian too, not in testing, blocking golang-goprotobuf migration
<locutus_> also, please convert the camitk hint into a forget everywhere except amd64 or bump it...
<mwhudson> sadface? https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/daily-live-20200416.log
<sil2100> ;/
<Laney> There was some maintenance in Launchpad and several in-progress builds failed like that
<cjwatson> Right, we were switching DB master
<cjwatson> Now on full SSD
<seb128> \o/
<mwhudson> Laney: so what happens, start another build?
<mwhudson> actually i am going to bed
<Laney> mwhudson: Yeah feel free to retry
<mwhudson> Laney: don't have the power, i don't think
<cjwatson> (standby isn't on full SSD yet, but hopefully ASAP)
<Laney> I'm stupid and deleted the mails so don't have a list of the failures to hand
<mwhudson> i only care about focal live server
<Laney> sil2100: I'll look at netplan.io, finished with proposed-migration now I think
<Laney> if you wanted to be nice, you could review what I came up with there ðððððð
<sil2100> \o/ thank you! I'm checking now if all the non-langpack translations have been done
<sil2100> Sure, do you have an MP? Or did you commit already?
<Laney> just writing commit messages
<Laney> ah wait, need to take care of one more case (missing builds)
-queuebot:#ubuntu-release- Unapproved: fprintd (focal-proposed/main) [1.90.1-1 => 1.90.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gsettings-desktop-schemas (focal-proposed/main) [3.35.91-0ubuntu1 => 3.36.0-1ubuntu1] (i386-whitelist, ubuntu-desktop)
<sil2100> Laney: ok, this was supposed to be an MP but I prematurely pushed it to trunk: can I finalize and release https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/revision/2879 ?
<sil2100> Laney: it's a bump of the dates following the exact same schema as for bionic: https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/bionic/revision/2826
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (bionic-proposed) [3.2-4ubuntu4.4]
<sil2100> We probably want to make it dynamic, using distro-info-data, but now is not the time
-queuebot:#ubuntu-release- Unapproved: inkscape (focal-proposed/universe) [0.92.4-5ubuntu5 => 0.92.5-1ubuntu1] (i386-whitelist, ubuntustudio)
<Laney> sil2100: Looks OK to me, but marcustomlinson has a MP up which we should include in the next upload: https://code.launchpad.net/~marcustomlinson/update-manager/update-manager/+merge/382410
<sil2100> Laney: would you like me to review it and merge it?
<sil2100> I need to help out with lunch now, but I can do that when I'm back
<Laney> sil2100: If you're up for it, feel free
<Laney> here's my britney2-ubuntu MP too: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/382422
<Laney> should unblock some items like remmina
<sil2100> Ok, will do those two shortly :)
 * Laney lunches too, then netplan time
<kanashiro> could someone please take a look at this MP to unblock mysql-8.0? https://code.launchpad.net/~lucaskanashiro/britney/hint-update-mysql-connector-c++/+merge/382246
-queuebot:#ubuntu-release- Unapproved: fonts-monoid (focal-proposed/universe) [0.61-2 => 0.61-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fonts-monoid [source] (focal-proposed) [0.61-2ubuntu1]
<Laney> sil2100: nonon
<Laney> you're leaking symbols in this libnetplan0, e.g. you have one from GLib in there
<Laney> oh no that's not true
<Laney> but you are exporting a g_... function on the ABI which seems wrong
<sil2100> Which one? We actually define one symbol that looks like a GLib symbol ;p
<Laney> this ABI seems a bit wonky
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.620.2]
<Laney> I think you should scope them all with netplan_ prefixes
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1018.19~18.04.1] (no packageset)
<sil2100> Yeah, I guess the library part is not ideal yet, it's used only by netplan and one NM plugin (unreleased anywhere)
<sil2100> So technically just by netplan
<sil2100> We might look into namespacing it better
<Laney> you've got functions in there with *really* generic names like "parser_error" and "is_ip4_address" though :S
<sil2100> But I'd of course target that for uh, 0.100 ? Or whatever version we'll have next
<sil2100> We might drop most of those symbols once we flesh out the other work
-queuebot:#ubuntu-release- Unapproved: ddtp-translations (focal-proposed/universe) [20200110.1 => 20200416.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (focal-proposed) [20200416.1]
-queuebot:#ubuntu-release- Unapproved: shadow (focal-proposed/main) [1:4.8.1-1ubuntu4 => 1:4.8.1-1ubuntu5] (core, i386-whitelist)
<sil2100> Oh, yay, mvo uploaded ddtp-translations \o/
<didrocks> I thought this enthousiast was for my shadow upload :p
<sil2100> Laney: uh, ok, I wrapped my head around that MP of yours and approved, just some comment typos
-queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.4 => 0.4.5] (no packageset)
<Laney> merci
<sil2100> Was surprised it actually didn't work like that before already
<Laney> apw: around? wanting a second opinion on netplan.io, see my above comments (weird ABI, sil2100 wants us to overlook that)
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (focal-proposed/universe) [0.64 => 0.65] (personal-fossfreedom, ubuntu-budgie)
<Laney> +            self.log('Tests for %s: %s' % (source_name, tests))
<Laney> WOH
<Laney> that's not supposed to be there /o\
<sil2100> I thought it's additional logging
<Laney> yeah just added it while developing
<sil2100> Laney, apw: yeah, I'd appreciate letting that through, mostly because in theory it should be harmless - realistically there should be no consumers of this library, we actually split it out only for the NM read-write plugin, which is why the API isn't super well designed
-queuebot:#ubuntu-release- Unapproved: adduser (focal-proposed/main) [3.118ubuntu1 => 3.118ubuntu2] (core)
<sil2100> Guess the most interesting symbols are the ones with netplan_* anyway
<sil2100> We probably don't need to export any others, but uh...
<bdmurray> sil2100, Laney: What packages can I be reviewing in the Focal queue?
<seb128> could those desktop items get reviewed? they have fixes we would like to see in the release: pulseaudio software-properties gnome-control-center fprintd gnome-shell-extension-ubuntu-dock
<seb128> bdmurray, hey, good timing :p
<bdmurray> From your perspective!
<bdmurray> ;-)
<seb128> haha
<seb128> right :)
<tdaitx> would someone be so kind as to approve openjdk-lts in focal?
<sil2100> We'll get to it soon ;)
-queuebot:#ubuntu-release- Unapproved: ovn-octavia-provider (focal-proposed/universe) [0.0.1~git2020022414.000049c-0ubuntu1 => 0.1.0-0ubuntu1] (no packageset)
<doko> tdaitx, sil2100: please no, there's one package waiting in -proposed, and I already had prepared a build for the remaining issue
-queuebot:#ubuntu-release- Unapproved: accepted ovn-octavia-provider [source] (focal-proposed) [0.1.0-0ubuntu1]
<tdaitx> doko: is there one more issue than the one you pointed out yesterday and asked me to fix?
<sil2100> Should we reject?
<doko> please do, yes.
<doko> tdaitx: I asked you to apply it for the security updates, and that I would prepare the upload for focal
<tdaitx> doko ok, I mixed things up then, only thing is that my security updates "backported" this last upload, including version
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.17 => 1.173.18] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.22 => 1.157.23] (core, kernel)
<tdaitx> doko: please just make sure focal lands a higher version than 2ubuntu2
-queuebot:#ubuntu-release- Unapproved: rejected openjdk-lts [source] (focal-proposed) [11.0.7+10-2ubuntu2]
<sil2100> apw, Laney: I'd really appreciate a go/no-go for netplan before final-freeze - expecially that we're so late with everything, I'd like to have potentially more time for fixing issues in case those pop up ;)
<apw> sil2100, sorry, i'll look at the new enw
<sil2100> I know the library part is not ideal - we'll make it better, I promise
<apw> sil2100, tell me the one thing this brings that we cannot live without
<sil2100> apw: a lot, we'd need the libnetplan stuff for our ongoing uc20 NM read-write plugin work, and the new SR-IOV feature is our roadmap item that we want to release
<Laney> sil2100: https://paste.ubuntu.com/p/FPRdPXRfds/ there's maybe a start of some visibility work
<Laney> but if apw's ok-ish then I don't want to block
<sil2100> apw: and all the other features are also basically needed for the ongoing NM plugin work
<sil2100> Basically, we're trying to release this as it's necessary, we wouldn't release it if it only had things 'good to have' ;)
<sil2100> (not this late in the cycle)
<apw> Laney, i assume that would stop all these seemingly internal entries appearing in the .so list
<sil2100> Laney: oh, fancy
<Laney> I can't say if that's enough for this plugin though
<Laney> but yeah that's the idea
<sil2100> I don't know how much we'd actually need
<Laney> bdmurray: sorry forgot to reply to you
<sil2100> I could distro-patch something based on Laney's suggestion, but as said, not sure
<Laney> I'm reviewing from the end
<Laney> so you can start somewhere in the middle if you want
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (focal-proposed) [1.8.14-0ubuntu1]
<bdmurray> Laney: okay, its gonna be an hour before I can start
<bdmurray> Laney: Do you know anything about livecd image building times? I added some info to the doc
<apw> Laney, 99% of this diff appears to be changes due to the prefix on every single constant changing
<sil2100> apw, Laney: my personal recommendation would be leaving it as is and then, calmly, flesh out which symbols are needed and sort out the header situation as well with a future revision
<sil2100> (and bumping the soname of course)
<xnox> Laney:  https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/focal/daily-live-20200416.log looks sad
<Laney> xnox: same as the earlier failures
<Laney> can respin once your livecd-rootfs is published
<Laney> bdmurray: They reverted the hack/workaround so it might be slow again, there's a fix proposed but not reviewed yet, will put the hack back if necessary next week
<xnox> Laney:  perfect
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (focal-proposed/main) [19.10.2+git20200223-1 => 20.04.0-1] (ubuntu-desktop) (sync)
<apw> Laney, i see nothing horrific in this thing other than it being too big to review line by line; if it does what is claimed i think it is ok, and it does at least have tests.  we should insist on sil2000 doing the interface review
<Laney> apw: Right, I wasn't reviewing the upstream stuff because it's too big!
<Laney> I don't think I would want to link against this library so yeah good if there's a commitment to fix it
<sil2100> Laney, apw: I pinky-promise to fix this (since now we have slyon to help out!)
<vorlon> xnox: tiny debhelper diffs can have large effects on buildability, I'm standing by my nack of this
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1020.21~18.04.1] (no packageset)
<vorlon> juliank: btw should we have another shim-signed upload for the new (but unreleasable) shim with a roll-up of the packaging changes?
<vorlon> juliank: or should we just leave things in the current state until we have a new signed shim
-queuebot:#ubuntu-release- Unapproved: haskell-stack (focal-proposed/universe) [1.7.1-3build2 => 1.9.3.1-1] (no packageset) (sync)
<juliank> vorlon: doesn't really matter much i guess
<juliank> vorlon: Should merge focal branch into master though
-queuebot:#ubuntu-release- Unapproved: accepted haskell-stack [sync] (focal-proposed) [1.9.3.1-1]
-queuebot:#ubuntu-release- Unapproved: thunderbird (focal-proposed/main) [1:68.7.0+build1-0ubuntu1 => 1:68.7.0+build1-0ubuntu2] (mozilla, ubuntu-desktop)
<seb128> is there anything we can do to help desktop items to be reviewed?
<sil2100> seb128: I'll get to those shortly, we're in a meeting right now
<seb128> vorlon, I reuploaded pulseaudio with one git cherry pick but it didn't get reviewed again, if you want to maybe have another look?
<seb128> sil2100, ok, thanks
<Laney> seb128: there's no problem, we're just working our way through everything
-queuebot:#ubuntu-release- Unapproved: php7.4 (focal-proposed/main) [7.4.3-4ubuntu1 => 7.4.3-4ubuntu2] (i386-whitelist)
<seb128> Laney, freeze is today and I need to call it a day in not long, I'm just trying to make sure I'm still around if there are questions/comments and that we don't miss the freeze
-queuebot:#ubuntu-release- Unapproved: accepted po4a [sync] (focal-proposed) [0.57-2]
<Laney> you won't, things that were uploaded before the freeze will be reviewed
-queuebot:#ubuntu-release- Unapproved: accepted kylin-nm [sync] (focal-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (focal-proposed) [0.99-0ubuntu1]
<seb128> k, fair enough
<sil2100> \o/
<sil2100> Laney, apw: thank you for accepting netplan! I know it wasn't an easy choice, we'll be sure to deal with any consequences swiftly
-queuebot:#ubuntu-release- Unapproved: accepted boost-defaults [source] (focal-proposed) [1.71.0.0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted keybinder-3.0 [source] (focal-proposed) [0.3.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (focal-proposed) [3.36.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (focal-proposed) [20.0.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (focal-proposed) [67ubuntu20.04.4]
-queuebot:#ubuntu-release- New binary: netplan.io [amd64] (focal-proposed/main) [0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: netplan.io [s390x] (focal-proposed/main) [0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: netplan.io [ppc64el] (focal-proposed/main) [0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: netplan.io [arm64] (focal-proposed/main) [0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: netplan.io [armhf] (focal-proposed/main) [0.99-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libva [sync] (focal-proposed) [2.7.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (focal-proposed) [3.36.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [0.98.8]
-queuebot:#ubuntu-release- Unapproved: libgd2 (focal-proposed/main) [2.2.5-5.2ubuntu1 => 2.2.5-5.2ubuntu2] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libxcomposite [sync] (focal-proposed) [1:0.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted libxfixes [sync] (focal-proposed) [1:5.0.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted libxdamage [sync] (focal-proposed) [1:1.1.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted libxres [sync] (focal-proposed) [2:1.2.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vmware [sync] (focal-proposed) [1:13.3.0-3]
<oSoMoN> dear release team, please consider accepting thunderbird 1:68.7.0+build1-0ubuntu2 into focal-proposed, it's removing a patch that we don't want to carry for 5 more years (was done in firefox a while ago but overlooked for thunderbird, better late than neverâ¦)
-queuebot:#ubuntu-release- New binary: haskell-stack [amd64] (focal-proposed/universe) [1.9.3.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fprintd [source] (focal-proposed) [1.90.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gsettings-desktop-schemas [source] (focal-proposed) [3.36.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (focal-proposed) [1:3.36.1-1ubuntu5]
-queuebot:#ubuntu-release- New binary: haskell-stack [ppc64el] (focal-proposed/universe) [1.9.3.1-1] (no packageset)
<Laney> ok I'm done with the queue for today probably
<Laney> leave the rest of the fun for bdmurray
<tdaitx> vorlon: libgd2 no change rebuild is in the unapproved queue
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-desktop-icons [sync] (focal-proposed) [20.04.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (focal-proposed) [1:68.7.0+build1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted inkscape [source] (focal-proposed) [0.92.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (focal-proposed) [0.65]
<oSoMoN> thanks!
<sil2100> Laney: thanks!
<Laney> tdaitx: btw, would have been possible for me to accept if the changelog said what the rebuild was for
<Laney> but as it stood I didn't have enough information so left it
-queuebot:#ubuntu-release- Unapproved: accepted libgd2 [source] (focal-proposed) [2.2.5-5.2ubuntu2]
<tdaitx> Laney: ouch, sorry for that, it makes sense... I can't really remember seeing useful changelog entries for no change rebuilds, so I didn't stop to consider doing differently
<vorlon> Laney: yeah we had out-of-band context, sorry
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu3]
<vorlon> Laney: it was because the previous build was uploaded to the security pocket, which means riscv64 can't be built
<vorlon> tdaitx: mine always say why I'm rebuilding :)
<tdaitx> I clearly haven't been looking at enough of them
-queuebot:#ubuntu-release- New binary: haskell-stack [s390x] (focal-proposed/universe) [1.9.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [riscv64] (focal-proposed/main) [0.99-0ubuntu1] (core)
<tdaitx> or I have only looked at the wrong ones for some reason
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.6 => 1:20.04.7] (core)
-queuebot:#ubuntu-release- New: accepted netplan.io [amd64] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted netplan.io [armhf] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted netplan.io [riscv64] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted netplan.io [arm64] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted netplan.io [s390x] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted netplan.io [ppc64el] (focal-proposed) [0.99-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-keystoneclient (focal-proposed/main) [1:3.22.0-0ubuntu2 => 1:4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.1-10-g71af48df-0ubuntu4 => 20.1-10-g71af48df-0ubuntu5] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: python-heatclient (focal-proposed/main) [2.0.0-0ubuntu1 => 2.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-novaclient (focal-proposed/main) [2:16.0.0-0ubuntu2 => 2:17.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-manilaclient (focal-proposed/main) [2.0.0-0ubuntu1 => 2.1.0-0ubuntu1] (openstack, ubuntu-server)
<Odd_Bloke> Hey release team, ^ that cloud-init upload fixes a test failure that we only saw building on Launchpad once the package was accepted.  I've done a test build in a PPA to confirm that this version of the package builds successfully on a Launchpad builder.
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [sync] (eoan-proposed) [1.0.20200401-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [sync] (eoan-proposed) [1.0.20200319-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:3.1.0-0ubuntu1 => 1:3.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.policy (focal-proposed/main) [3.0.3-0ubuntu1 => 3.1.0-0ubuntu1] (openstack, ubuntu-server)
<sil2100> Odd_Bloke: looking
 * sil2100 is waiting for the debdiff
<Laney> vorlon: by the way, I merged some changes to britney2-ubuntu earlier to have the autopkgtest policy not wait for uninstallables / missing builds on non-adt or BREAK arches
<Laney> that should *not* by itself cause anything to migrate when it wouldn't have before
<Laney> but just have test results for those items
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (focal-proposed) [20.04.3]
<Odd_Bloke> sil2100: It's there now: http://launchpadlibrarian.net/474899794/cloud-init_20.1-10-g71af48df-0ubuntu4_20.1-10-g71af48df-0ubuntu5.diff.gz (Thanks for looking! :)
-queuebot:#ubuntu-release- Unapproved: barbican (focal-proposed/main) [1:10.0.0~b2~git2020020508.7b14d983-0ubuntu2 => 1:10.0.0~b2~git2020020508.7b14d983-0ubuntu3] (openstack, ubuntu-server)
<sil2100> Odd_Bloke: yeah, saw it!
-queuebot:#ubuntu-release- Unapproved: accepted adduser [source] (focal-proposed) [3.118ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.5]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (focal-proposed) [1:4.8.1-1ubuntu5]
<sil2100> (and now accepted)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.1-10-g71af48df-0ubuntu5]
<Odd_Bloke> \o/
<sil2100> I think I'm done with the queue for today as well
<powersj> Odd_Bloke, sil2100 thanks!
<sil2100> yw!
<sil2100> Ok, guess it's time to get the langpack export prepared
-queuebot:#ubuntu-release- New binary: haskell-stack [arm64] (focal-proposed/universe) [1.9.3.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.7]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1020.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1018.19~18.04.1]
<Laney> bdmurray: did you want to do the final freeze announcement later?
<bdmurray> Laney: later being when?
<Laney> 21:00 UTC is the usual time
<Laney> so depending on how precise you want to be, then or then abouts :-)
<jfh> hi - I assumed that there will be a new daily-live image in pending today - one with timestamp Apr-16 -- it's usually there at this time of the day, any ideas why it's not there today?
-queuebot:#ubuntu-release- New: accepted haskell-stack [amd64] (focal-proposed) [1.9.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-stack [ppc64el] (focal-proposed) [1.9.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-stack [arm64] (focal-proposed) [1.9.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-stack [s390x] (focal-proposed) [1.9.3.1-1]
<Laney> jfh: There was Launchpad maintenance earlier and a lot of in-progress image builds got abnormally terminated
<jfh> Laney: ah, didn't know - so maybe better to wait until tomorrow ...
<Laney> If you particularly need it then someone could request a rebuild, but otherwise yeah I expect tomorrow's builds to complete normally
<Laney> that'll have to be someone else
 * Laney goes away o/
<jfh> nah - waiting for another day is still okay - just wondered ...
<sil2100> bdmurray: so do you want to do it or should I?
-queuebot:#ubuntu-release- Unapproved: cbp2make (focal-proposed/universe) [147+dfsg-2build1 => 147+dfsg-3] (no packageset) (sync)
<bdmurray> sil2100: I can do it if you don't want to stick around.
-queuebot:#ubuntu-release- Unapproved: accepted cbp2make [sync] (focal-proposed) [147+dfsg-3]
<sil2100> bdmurray: we can battle over it when the time comes
<bdmurray> ðª
-queuebot:#ubuntu-release- Unapproved: singularity (focal-proposed/universe) [0.30c-1 => 1.0b1-2] (no packageset) (sync)
<vorlon> Laney: autopkgtest policy> thanks, sounds like just what we want
-queuebot:#ubuntu-release- Unapproved: accepted singularity [sync] (focal-proposed) [1.0b1-2]
<vorlon> Laney: ah, it seems you've added riscv64 to the arches in britney.conf, is that just for testing or does that impact the production configs? I expect that breaks the britney runs for stable series by adding a non-existent arch to the config?
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [0.98.9]
<vorlon> Laney: well, code/b2/britney.conf.ubuntu.eoan at least looks sane, so I guess things are fixed up appropriately somewhere :)
<vorlon> wgrant: is https://launchpad.net/ubuntu/+source/llvm-toolchain-10/1:10.0.0-3/+build/19151969 hung or are logs just really, really slow to update here
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.7 => 1:20.04.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-castellan [source] (focal-proposed) [3.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-keystoneclient [source] (focal-proposed) [1:4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-heatclient [source] (focal-proposed) [2.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: postfix (focal-proposed/main) [3.4.10-1 => 3.4.10-1ubuntu1] (core)
<mwhudson> can we get the focal live server iso built?
<mwhudson> last night's failed and i really want to test one that's core18 based
<mwhudson> vorlon, sil2100: ^
<sil2100> mwhudson: ok
<Laney> mwhudson: I'll trigger one (done)
<mwhudson> Laney, sil2100: thanks
<Laney> vorlon: The live configs are manually maintained afaik, but that unversioned one is used by the testsuite
<sil2100> Oh that Laney snatching stuff from under my feet!
<Laney> yeah I just wanted the ISO tracker karma
<sil2100> Oh yes, we all want that delicious karma!
-queuebot:#ubuntu-release- Unapproved: lxc (focal-proposed/universe) [1:4.0.1-0ubuntu2 => 1:4.0.2-0ubuntu1] (ubuntu-server)
<rbalint> bdmurray, ok, i found why systemd-timesyncd gets removed on upgrade, it is because it is in minimal task
<rbalint> bdmurray, where can we change the minimal task? seems not in ubuntu-meta
<rbalint> vorlon,^?
<bdmurray> rbalint: it == systemd-timesyncd?
<rbalint> bdmurray, yes
<rbalint> LP: #1872902
<ubot5> Launchpad bug 1872902 in ubuntu-release-upgrader (Ubuntu Focal) "Upgrade to Focal now removes chrony" [Critical,Triaged] https://launchpad.net/bugs/1872902
<bdmurray> well then I don't seem to know the answer :-|
<rbalint> bdmurray, thanks, i feel much better now :-)
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.1-3ubuntu1 => 3.36.1-3ubuntu2] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- Unapproved: pop-gtk-theme (focal-proposed/universe) [5.0.0~1576602011~19.10~7760154~ubuntu2 => 5.2.0~1586289568~20.04~f35b83b~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pop-gtk-theme [source] (focal-proposed) [5.2.0~1586289568~20.04~f35b83b~ubuntu1]
<rbalint> cjwatson, could you please help us out, how is systemd-timesynd added to the minimal task?
<mwhudson> rbalint: https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/minimal <- because systemd depends on it?
<mwhudson> although it's systemd-timesyncd | time-daemon
-queuebot:#ubuntu-release- Unapproved: accepted python-manilaclient [source] (focal-proposed) [2.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pop-icon-theme (focal-proposed/universe) [2.1.0~1571158475~19.10~6bf9347 => 2.1.0~1583343731~20.04~11f18cb~ubuntu1] (no packageset)
<rbalint> mwhudson, i suspect that's the (wrong) cause, but why is anything added that's being depended on?
-queuebot:#ubuntu-release- Unapproved: accepted pop-icon-theme [source] (focal-proposed) [2.1.0~1583343731~20.04~11f18cb~ubuntu1]
<rbalint> mwhudson, bdmurray  or u-r-u should not mark the packages in the seed, just the meta package ubuntu-minimal to install
<mwhudson> hrm
<juliank> rbalint, mwhudson seed is expanded recursively afaiui, and it will pick the real option if given real | provider, until you seed a provider explicitly
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu4 => 1:4.2-3ubuntu5] (ubuntu-server, virt)
<juliank> rbalint, mwhudson Now, the reason to install all packages in the seed is that it's more consistent
<juliank> e.g. now machines get upgraded to systemd-timesyncd, instead of having any random time-darmon
<rbalint> juliank, well i'd argue that it is also wrong, consistently :-)
<mwhudson> i get confused about which seed is which
-queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu6 => 6.0.0-0ubuntu7] (ubuntu-server, virt)
<cpaelzer> hi release team, after quite a bunch of extra verifications I have put qemu and libvirt into focal-unapproved and wanted to ask to accept that before the final freeze happens
<cpaelzer> In case it is needed, the referenced bugs and the merge proposals that you can reach from there have plenty of information.
<juliank> rbalint: I'd argue the easiest way to work around is to add a blacklist of stuff we don't want to explictly replace
<cpaelzer> bdmurray: sil2100: vorlon: apw: stgraber: ^^
-queuebot:#ubuntu-release- Unapproved: heat-dashboard (focal-proposed/universe) [2.1.0~git2020021314.7842190-0ubuntu1 => 2.1.0~git2020032615.7842190-0ubuntu1] (no packageset)
<cpaelzer> the uploads also include CVE fixes that mdeslaur assked me to add to focal
<rbalint> juliank, yes, it is easy
<juliank> rbalint: now, we do need dependencies expanded in the tasks, otherwise, installing tasks becomes unpredictable
-queuebot:#ubuntu-release- Unapproved: accepted heat-dashboard [source] (focal-proposed) [2.1.0~git2020032615.7842190-0ubuntu1]
<juliank> Which can be a problem
<sil2100> cpaelzer: looking
<cpaelzer> ok sil2100, let me know if there is anything
<cpaelzer> thanks in advance
<juliank> We had a related issue when apport depended on x-terminal-emulator, and germinate expanded that to terminator on i386, and that popped up in component mismatches :)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.1-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (focal-proposed) [3.4.10-1ubuntu1]
<stgraber> bdmurray: got a FFe for that ubuntu-support-status change? I believe that the removal of a command from all Ubuntu systems probably qualifies as a feature change.
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.8]
<stgraber> well, someone apparently disagrees? :)
<bdmurray> lol
<stgraber> should have rejected faster...
<Laney> block it in proposed!
<rbalint> juliank, ok, let's keep the task installation that way
<sil2100> Ok, that was me, and it was supposed to be qemu that's accepted?
<sil2100> But apparently someone accepted it earlier, and some other package's checkbox got checked?
<stgraber> I've already done qemu/libvirt
 * sil2100 sighs
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (focal-proposed) [1:10.0.0~b2~git2020020508.7b14d983-0ubuntu3]
<sil2100> Ok, sorry about fat fingering that one
<bdmurray> I'm looking at python-novaclient
<sil2100> Hate it when LP leaves the tick even when the package gets accepted
<stgraber> I'll just delete it from proposed then if that wasn't a deliberate accept
<stgraber> bdmurray: consider it rejected then
<cpaelzer> sil2100: you wanted to do the right thing - accept my uploads - it is the spirit that counts
<cpaelzer> stgraber: thank you as well then
<sil2100> Didn't know someone was reviewing those, then again maybe I should not be here at this hour
<stgraber> yeah, this is always a bit racy at this time in the cycle :)
<stgraber> bdmurray: to be clear, I'm happy to grant you an FFe for this, but I want to have a LP bug to track it as that may need to be in the release notes (covering both the field being gone, the tool being removed and what the alternative is)
<bdmurray> stgraber: okay
-queuebot:#ubuntu-release- Unapproved: accepted php7.4 [source] (focal-proposed) [7.4.3-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-glanceclient [source] (focal-proposed) [1:3.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [20.0.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-novaclient [source] (focal-proposed) [2:17.0.0-0ubuntu1]
<cpaelzer> sil2100: I just see you are also todays SRU-rota person - feel free to ignore in case the release frenzy makes you busy enough, but if you have a minute (shouldn't be more) this one is just waiting for release => https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1868012/comments/13
<ubot5> Ubuntu bug 1868012 in open-vm-tools (Ubuntu Eoan) "MRE for open-vm-tools to version 11.0.5" [Low,Fix committed]
<cpaelzer> and I pinged no one else to avoid concurrent handling :-)
<rbalint> bdmurray, juliank, cpaelzer https://code.launchpad.net/~rbalint/ubuntu-release-upgrader/+git/ubuntu-release-upgrader/+merge/382454
<juliank> rbalint: can that be changed to check that another time-daemon is installed already?
<xnox> juliank:  apw: Laney: vorlon: https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/382456
<juliank> rbalint: that is, add `and any(p.is_installed for p in self.get_providing_packages("time-daemon"))` to the if?
<vorlon> apw, we have nvidia vs lrm version skew in the release pocket /again/
<juliank> yikes
<vorlon> ii  nvidia-dkms-440 440.82-0ubuntu1 amd64        NVIDIA DKMS package
<vorlon> $ apt-cache show linux-modules-nvidia-440-generic|grep Prov
<vorlon> Provides: nvidia-dkms-440 (= 440.64-0ubuntu3)
<vorlon> $
* bdmurray changed the topic of #ubuntu-release to: Released: Bionic 18.04.4, Eoan 19.10 | Archive: Final Freeze | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<Laney> \o/
<mwhudson> ok how many times can we upload ubiquity in the next week team?
<Laney> One more this week, and then experience tells me probably twice next ...
<tsimonq2> Speaking of uploading critical packages, how bad would the Release Team hate me if I wanted to upload a few (tested) patches to util-linux to fix some Calamares issues?
<Laney> bad
<tsimonq2> I'm specifically looking at https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id={fa3ffa,ac762e}
<RikMills> bad object :P
<dax> he means https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=fa3ffa and https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac762e
<tsimonq2> Laney: Not surprising, but to be fair, there is a stop gap if they're ready to burn me at the stake, and they come from upstream Git.
<tsimonq2> dax: Correct.
<RikMills> dax: I know
<vorlon> sil2100: hey, the nvidia-graphics-drivers-440 that you accepted is a big problem
<vorlon> sil2100: it skews vs linux-restricted-modules and means we can't replace nvidia-dkms with linux-modules-nvidia at GA and give users signed modules like we're supposed to be doing
<Laney> vorlon: If there's special knowledge for RT members to know before reviewing classes of packages, could it be written down somewhere?
<Laney> I might have gotten that one wrong too myself
<vorlon> Laney: well it's a failure that a) this didn't respect kernel freeze and b) there is no autopkgtest gating in place
<vorlon> the kernel team is meant to be encapsulating the special knowledge in an autopkgtest that dtrt
<Laney> TBH I didn't know that kernel freeze would have applied there
<Laney> https://wiki.ubuntu.com/KernelFreeze is a bit lacking
<Laney> anyway I actually want to step away, I said what I wanted to, a bit of knowledge transfer would help me here
<Laney> see ya
<vorlon> bdmurray, sil2100: nvidia-graphics-drivers-440_440.82+really.440.64-0ubuntu4 now uploading; so far completely untested
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82-0ubuntu1 => 440.82+really.440.64-0ubuntu4] (i386-whitelist)
<bdmurray> stgraber: Can I reuse the same upate-manager version number given what happened?
<stgraber> bdmurray: no, you'll have to increase it
<bdmurray> stgraber: alright, that's what I thought
<bdmurray> stgraber: How does bug 1873362 look to you?
<ubot5> bug 1873362 in update-manager (Ubuntu) "remove ubuntu-support-status as its a confusing mess" [Undecided,New] https://launchpad.net/bugs/1873362
-queuebot:#ubuntu-release- Unapproved: gnome-software (focal-proposed/main) [3.36.0-0ubuntu2 => 3.36.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.12 => 20.04.13] (core)
<stgraber> bdmurray: commented
<bdmurray> You've really seen people use it?
<sarnold> bdmurray,stgraber, I thought I heard a rumour that the nice people working on the 'ua' tool were tasked with making a nice replacement
<bdmurray> sarnold: I'm actually that nice person
<sarnold> bdmurray: I've always said you were a nice person! excellent
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (focal-proposed) [3.36.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.13]
<stgraber> bdmurray: yep, I've seen people use it to confirm that they have no unsupported packages on their system, included in nagios checks
<jbicha> vorlon: could you reconsider your debhelper 13 rejection? my specific concern is that you can't currently use focal to build a package that Build-Depends on debhelper-compat (= 13)
<jbicha> I expect lots of Debian packages will switch to that
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.661 => 2.662] (desktop-core, i386-whitelist)
<bdmurray> jbicha: Your concern is that packages in focal will switch their Build-Depends after the release?
<jbicha> no, it just would be nice to be able to build newer packages from Debian or 18.10 on 18.04 LTS without needing to mess with the compat level
<jbicha> (workaround is to use debian/compat with 13 instead or lower the compat level to 12)
<cjwatson> Is it possible to get at the exact qemu images used by our autopkgtests?  I'm having trouble reproducing https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/python-launchpadlib/20200415_171509_0c21d@/log.gz
<xnox> stgraber:  bdmurray: "the new tool will be provided soon, which will report correct and accurate status not only for focal, but all series"
<xnox> cjwatson:  we have autopkgtest scripts that generate derivative autopkgtest image. It's simply uploaded into the autopkgtest account. I've tried glance image-download before, and it simply times out.
<xnox> cjwatson:  at best i can only launch a spare vm from the same image, and like grant ssh access to it.
<cjwatson> I could also run the same scripts locally if I knew where they were, I suppose
<cjwatson> I tried autopkgtest-buildvm-ubuntu-cloud and that apparently wasn't enough
<mwhudson> cjwatson: are you testing the binaries from the archive or building them as part of the run?
<cjwatson> The latter though I'd be slightly surprised if it mattered in this case
<mwhudson> cjwatson: autopkgtest builds the packages without proposed enabled
<cjwatson> But I can double-check
<mwhudson> so it can matter
<cjwatson> I agree in principle but it should just copy in identical Python code
<mwhudson> true
<mwhudson> i just lost a lot of time once getting confused by this
<mwhudson> agree for python it shouldn't matter though
<mwhudson> i hope there isn
<mwhudson> t a dh-python in proposed at this stage in the cycle :)
<cjwatson> mwhudson: Anyway "autopkgtest --apt-pocket=proposed=src:python-launchpadlib --apt-upgrade python-launchpadlib -- qemu ~/autopkgtest-focal-amd64.img" passes locally
<mwhudson> cjwatson: :(
<cjwatson> It's plausibly to do with an extra keyring provider being installed or something but I don't know exactly what
#ubuntu-release 2020-04-17
<Ukikie> jbicha: ...Or you could cheat and just add the provides to current debhelper, but that seems less than ideal.
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82+really.440.64-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82-0ubuntu1 => 440.82+really.440.64-0ubuntu4] (i386-whitelist)
<xnox> jbicha:  it was rejected.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.661 => 2.663] (desktop-core, i386-whitelist)
<xnox> cjwatson:  the one thing that is not nice, is that teh VMs are "upgraded" daily
<xnox> meaning one cannot quiete rebuild them independantly without knowing when/what they upgraded things to
<cjwatson> TBH even just getting a list of installed package names and versions from one of those VMs would be helpful
<xnox> git clone lp:autopkgtest-cloud
<xnox> has ./tools/build-adt-image-all-clouds
<cjwatson> If you can launch a VM from it do you think you could extract the output of "dpkg-query -W"?
<cjwatson> But I'll look at that too, thanks
<xnox> which does call from $ pull-lp-source autopkgtest => calls setup-commands/setup-testbed
<xnox> which does a lot
<xnox> like installing dbus & installing libpam-systemd
<xnox> potentially triggering session auditing and what not.
<cjwatson> dbus could well be relevant
<xnox> cjwatson:  right, but i'm about to sleep. Will do that for you tomorrow. Unless someone beats me to it. i.e. juliank maybe.
<xnox> also gpg is installed
<xnox> which means that systemd- user session jobs are probably started
<cjwatson> Thanks, me too.  Will see how far I get
<vorlon> bdmurray: nvidia-graphics-drivers-440 now build- and install-tested; I'll self-accept after a couple of hours if no one else is available to review
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.1-3ubuntu2 => 3.36.1-3ubuntu3] (desktop-core, desktop-extra)
<cjwatson> Ah, maybe I see the launchpadlib bug by zen debugging
<cjwatson> Possibly https://code.launchpad.net/~cjwatson/launchpadlib/postpone-keyring-errors-import/+merge/382465
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82+really.440.64-0ubuntu4]
<cpaelzer> cjwatson: for "exact images we use for autopkgtest" in one of such cases that I had (local  autopkgtest-buildvm-ubuntu-cloud) didn't reproduce it - someone (IIRC Laney) was able to upload the image used in the tests into canonistack
<cpaelzer> cjwatson: that way I was able to spawn exactly what the tests used
<cpaelzer> I read the backlog and was unsure if you got to a solution already, if you did please ignore the noise
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.662]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.663]
<seb128> does anyone know how we there is so much backlog on autopkgtest?
<seb128> we are in freeze, it's not like we had synced half of the archive or done a python transition
<RikMills> I guess glibc which triggers the world of tests under 'huge' is part of it?
<seb128> rikMills, right, I guess that could be it, unfortunate that one update can DoS the infra for over a day :-/
<RikMills> I guess at least it limits the immediate worker availability for !huge things.
 * RikMills shrugs
<juliank> ugh
<juliank> Laney: Apparently we got stuck with duplicate servers again in l{cy,gw}01, so we did not get updated images for a week
<juliank> Really gotta add some error reporting _somewhere_
<juliank> cjwatson: So, dpkg -l on the autopkgtest image https://paste.ubuntu.com/p/NvQqMTKjGC/
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.0-0ubuntu2 => 15.2.1-0ubuntu1] (desktop-core, ubuntu-server)
<juliank> I'll build some new focal images for amd64
 * juliank accidentally overwrote the logs for the other image builds
<juliank> lgw is exceeding quota, and hence, not building
<juliank> trying by hand
<juliank> So I guess modifying create-nova-image-new-release to delete any server with the same name as the one we're about to create will solve the issue
<juliank> I think the script is exiting somewhere due to set -e and not reaching the part where it does the removing
<juliank> Also, I hacked the script to not build i386 images on focal anymore
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.1-3ubuntu3]
<sil2100> hm, this is weird
<sil2100> seb128: so I ran my langpack sanity tests and noticed that most of the new base refreshes are basically dropping snapd-glib.po
<sil2100> Ah, ok, I see the translation strings are completely different now
<sil2100> Which is why probably most languages didn't translate it
<seb128> sil2100, right, it was not properly set for translation until yesterday :-/
<sil2100> seb128: ACK
<sil2100> I also see we MoinMoin.po and JabberBot.po being dropped in comparison to the last base refresh, but I suppose it's due to moin being removed from the archive
<seb128> likely
<sil2100> Anyway, thanks for the info, I'll start the upload process of those packs
<Laney> juliank: hacked> please commit it
<Laney> I'm not happy with the cowboys we're building up there
<Laney> cjwatson: if you change log.gz in your url to artifacts.tar.gz there's a 'testbed-packages' in there which is the stuff that was preinstalled in the testbed itself, perhaps that's useful to you
<juliank> Laney: I will
<Laney> xlnt
<juliank> Laney: I'm not sure what happened to the Cross-Test changes, why are they not committed?
<Laney> there's a MP and I gave some review comments on there, but they AFAIK didn't get addressed
<Laney> juliank: perhaps installing a 'trap' once we have an ID of an image-build instance would help
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.6-dfsg-1ubuntu20.04.1 => 6.1.6-dfsg-2ubuntu20.04.1] (no packageset)
<Laney> and not referring to instances by name probably
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.6-dfsg-2ubuntu20.04.1]
<juliank> Yeah, like trap  "openstack server delete $foo" EXIT
<Laney> yep
<juliank> oh well, with nova
<Laney> I tried to make this all much more robust in the new deploymment
<Laney> so hopefully it's better $soon
<juliank> I feel like deleting any leftover instances before booting a new one is probably easiest, though
<Laney> I would probably do both
<juliank> haha I was tailing the log and wondering why it did not exit, thinking it was the process itself
<juliank> amd64 images are uptodate now
<juliank> Laney: Does the new one also retry? Sometimes we fail on quota and need to retry later
<juliank> Or maybe we should fix our number of instances we use
<Laney> check it out in wip/mojo-juju-2
-queuebot:#ubuntu-release- Unapproved: yaru-theme (focal-proposed/main) [20.04.5 => 20.04.6] (desktop-core)
<Laney> there's a lot of retrying going on in there
<juliank> I think we don't account for building images in parallel to workers running tests
<juliank> like, building the image probably should pause one worker
<Laney> and indeed the trap that I just mentioned, forgot I did that!
<Laney> well we don't usually run at 100% of our quota
<Laney> because some tests require m1.large
<juliank> ok, but it's not exactly the first time I saw a quota failure
<juliank> ERROR (Forbidden): Quota exceeded for cores: Requested 1, but already used 30 of 30 cores (HTTP 403) (Request-ID: req-da4689aa-e861-4852-b4e3-2b8ded1af1a0)
<Laney> yeah, it's common
<Laney> I guess one suggestion would be to run the script more frequently - like, hourly - but have it exit 0 if the image it wants to make already exists
-queuebot:#ubuntu-release- Unapproved: strace (focal-proposed/main) [4.26-0.2ubuntu3 => 5.5-3ubuntu1] (core) (sync)
<wgrant> ooh
<wgrant> rbalint: Thanks for that, makes my weekend easier.
<rbalint> please see FFe in LP: #1873409
<ubot5> Launchpad bug 1873409 in strace (Ubuntu) "[FFe] Please accept strace 5.5-3ubuntu1 to Focal" [Undecided,New] https://launchpad.net/bugs/1873409
-queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu1 => 2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.24.29 => 5.4.0.24.30] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta [source] (focal-proposed) [5.4.0.24.30]
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.24.29 => 5.4.0.24.30] (core, kernel)
<sil2100> Will approve all the langpacks in a moment
<apw> sil2100, can i have linux-meta first :)
<apw> else it will take hours to build :)
<sil2100> Looking ;)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [source] (focal-proposed) [5.4.0.24.30]
<sil2100> apw: ^
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ironic (focal-proposed/universe) [1:14.0.1~git2020041013.af9e6ba90-0ubuntu1 => 1:14.0.1~git2020041013.af9e6ba90-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- Unapproved: openmpi (focal-proposed/universe) [4.0.3-0ubuntu1 => 4.0.3-6ubuntu1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (focal-proposed/main) [3.36.0-1 => 3.36.1-0build1] (desktop-extra, ubuntu-desktop)
<cjwatson> Laney: testbed-packages> oh, handy,  and thanks juliank
<cpaelzer> ubuntu-archve: hi the dbgsym seem to be out of date again
<cjwatson> hi we're already working on it
<apw> cpaelzer, it is known that ddebs.u.c is lagging and it is ... oh
<cjwatson> it's not "again", it's still.  stalled on 2020-04-02 and we only noticed a couple of days ago, so it has a big backlog
<cpaelzer> ok cjwatson apw
<cpaelzer> from my limited POV it was "again", didn't know there was a known lag
<cjwatson> it's about 50% through the catch-up
<cpaelzer> ok, thanks then
<cjwatson> 26 hours in or so
<cpaelzer> maybe just rechecking on monday then
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (focal-proposed) [20.04.6]
<locutus__> any archive admin, pleeeeeeeeease remove node-run-sequence from focal see debian bug: #954832
<ubot5> Debian bug 954832 in ftp.debian.org "RM: node-run-sequence -- ROM; Deprecated since node-gulp 4" [Normal,Open] http://bugs.debian.org/954832
<locutus__> ubot5, stop saying that closed bugs are open, thanks
<ubot5> locutus__: I am only a bot, please don't think I'm intelligent :)
<Laney> Wimpress / popey: (cc sil2100 jibel paride bdmurray): Yo ho de ho, for the release we were thinking of maintaining a 'status whiteboard' on Discourse that people can look at to find out what's going on with respins / bugs / etc. wdyt about giving us a wiki post in the announcements category that we can use for that?
<jamespage> cpaelzer: I think I can push the jwcrypto dependency from websockify to a suggests which would take MIR pressure off this late in cycle
<jamespage> testing now
<Wimpress> Laney, that's a great idea.
<paride> Laney, +1
<philroche> Laney: I'm happy to contribute to that dashboard for cloud images
<Wimpress> Do you want a reserved wiki post now Laney?
<Laney> philroche: nice, ok
<Laney> Wimpress: Yeah, that'd work
<Laney> if you can make it so that all of those CCed people + philroche can edit
<Laney> it
<Wimpress> popey: Can we get together in a bit and set that up? ð
<jamespage> cpaelzer: yep lgtm
-queuebot:#ubuntu-release- Unapproved: websockify (focal-proposed/main) [0.9.0-0ubuntu1 => 0.9.0-0ubuntu2] (ubuntu-server)
<jamespage> please can ^^ and the ironic upload I did today be accepted - they should unblock ubuntu-openstack proposed-migration blocks
<rbalint> sil2100, could strace go in today?
<sil2100> rbalint: ouch, that's a big jump
<Laney> indeed it is
<Laney> final freeze ...
<sil2100> I need to think about it, as this doesn't make me feel very happy
<rbalint> Laney, sil2100: indeed, it is, please see the FFe
<rbalint> i'm not sure how far we are from building riscv64 images, but strace is a blocker, i believe
<sil2100> rbalint: just for the record: did you look at if it's easy to identify which changes would make the test passing on riscv64? Or would that be hard to determine with all the changes?
 * Laney hasn't heard anything about images
<jamespage> and also the ceph 15.2.1 point release - it includes important upgrade and security fixes :)
<Laney> I think I lean towards saying that this should be moved to an SRU
<sil2100> I mean, I wouldn't mind pulling this into focal in principle somewhen, but doing it so late in the cycle is bad, this has a lot of behavior changes
<rbalint> sil2100, it seems hard, i have not looked (for 5.5)
<Laney> then (1) no risk to the focal release, (2) can have explicit verification and it can be rolled back if necessary
<rbalint> Laney, how would verification look like?
<Laney> You tell me
<Laney> how does verification of *this* look like?
<rbalint> Laney, builds and autopkgtests
<rbalint> Laney, i'm fine with postponing it to focal+1
<rbalint> Laney, interested people can sru later
<wgrant> strace, being mostly a debugging tool, seems relatively low risk to the release in general. It also doesn't have a massive history of regressions. But yes, big jump.
<rbalint> yes, imo is it is very low risk, but having old strace in focal missing syscalls is very annoying
<rbalint> we never had an strace sru/security update per rmadison
<juliank> just add the syscalls?
<popey> Wimpress sure thing
<rbalint> juliank, if someone else is interested i would not block her/him, but i'm not interested at all doing it , rather use strace from a ppa
<rbalint> how about having strace in -proposed but not letting it in until after the release? then riscv64 bootstrap can continue
<sil2100> I think this might be an option
<Laney> sounds possible
<sil2100> It's unlikely we'd have to do any release-blocking hotfixes for strace
<wgrant> I need to drop -proposed from the chroots for at least a bit to finish the haskell and rust trees because -proposed is a bit of a mess, but yeah, makes sense
<Laney> So we've definitely had strace being the cause of build failures / autopkgtest failures (more so these) in the past
<sil2100> Oh, we did?
<Laney> It's the kind of thing that I don't want to risk us having with not much time to get things aligned
<Laney> it should be ok in -proposed for the autopkgtest side, as this strace won't be pulled in unless requested
<rbalint> Laney, the test rebuilds and bileto tests should have minimized the potential disruption
<sil2100> Yeah, +1 - guess it would be easiest if we had the bug number attached in the changelog
<Laney> yeah but we know that we only catch first level regressions by these methods
<sil2100> Though I guess I can just do a block hint for it
<Laney> that's most of our problems in autopkgtest-land
<Laney> anyway I think blocking is ok
<Laney> if we do hit problems, it can always be removed then
<sil2100> Laney: I'll look at the diff, add a block hint and accept
<Laney> nod
<rbalint> sil2100, thanks!
<jbicha> ubuntu-archive please take a look at removal requests bug 1872598 and bug 1872593
<ubot5> bug 1872598 in ipython-py2 (Ubuntu) "Please remove ipython-py2 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872598
<ubot5> bug 1872593 in dh-kpatches (Ubuntu) "Please remove dh-kpatches from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872593
-queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.2.1~git2020041013.754804667-0ubuntu1 => 3:18.2.1~git2020041013.754804667-0ubuntu2] (openstack, ubuntu-server)
<Laney> sil2100: so about the discourse thing, some of the sections on the release document should move over there I think
<sil2100> Laney: ah, the discourse thread?
<sil2100> For release?
<Laney> yeah
-queuebot:#ubuntu-release- Unapproved: pepperflashplugin-nonfree (focal-proposed/multiverse) [1.8.4ubuntu2 => 1.8.6ubuntu1] (no packageset)
<Laney> status summary / current blockers / bugs to watch ?
-queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (focal-proposed) [1.8.6ubuntu1]
<Laney> if you agree, I'll do that and add a link once the post is created
<sil2100> Laney: +1 on that - did you create that thread already? Could you paste the link once you have it?
<Laney> see ^ - Wimpres_s and pope_y are on it
<sil2100> This will be something new for me as I never was a discourse person ;)
<Laney> ah, you can have 'wiki posts', so it'll not be too un-familiar for you
-queuebot:#ubuntu-release- Unapproved: accepted strace [sync] (focal-proposed) [5.5-3ubuntu1]
<sil2100> jamespage: holy shit 9MB of diff for ceph
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu1 => 2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu2] (openstack, ubuntu-server)
<sil2100> jamespage: the changelog in the diff has much more changes than the ones listed on the diff - whyyy is this so late
<sil2100> eh, let me try that again
<sil2100> jamespage: the changelog in the diff has much more changes than the ones listed on the bug - whyyy is this so late
<jamespage> sil2100: sorry which one?
<sil2100> jbicha: looking at some of those in a moment
<jamespage> the ceph diff?
<jamespage> sil2100: do you mean the list in doc/releases/octopus.rst ? I think upstream did a catchup in the docs from the 15.1.0 beta release between 15.2.0 and 15.2.1
<jamespage> sil2100: this point release only appeared this week and it takes me a while to validate due to build times
-queuebot:#ubuntu-release- Unapproved: cinnamon (focal-proposed/universe) [4.4.8-3 => 4.4.8-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon [sync] (focal-proposed) [4.4.8-4]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.2.1~git2020041013.754804667-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (focal-proposed) [1:14.0.1~git2020041013.af9e6ba90-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pdfchain (focal-proposed/universe) [1:0.4.4.2-1build1 => 1:0.4.4.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pdfchain [sync] (focal-proposed) [1:0.4.4.2-2]
-queuebot:#ubuntu-release- Unapproved: balsa (focal-proposed/universe) [2.5.9-4 => 2.6.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted balsa [sync] (focal-proposed) [2.6.0-2]
 * sil2100 AFK for lunch
<Wimpress> Laney: Re: release wiki post on Discourse. Do you want people to be able to comment?
<Laney> Wimpress: ideally not, we don't want to be replying there really
<kanashiro> could someone please take a look at this MP to unblock mysql-8.0? https://code.launchpad.net/~lucaskanashiro/britney/hint-update-mysql-connector-c++/+merge/382246
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (focal-proposed/main) [11.0.7+10-2ubuntu1 => 11.0.7+10-3ubuntu1] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (focal-proposed/universe) [8u252-b09-1 => 8u252-b09-1ubuntu1] (i386-whitelist) (sync)
<Wimpress> Laney: Here's your topic - https://discourse.ubuntu.com/t/focal-fossa-final-release-status-tracking/15366
<Wimpress> Release team members have write access to that category.
<Wimpress> When that post has something in it, I will pin it.
<Laney> Wimpress: Ta duck
<Laney> ooh
<Laney> it copies from google docs with proper formatting
<Laney> ok filled out with some initial content
<Wimpress> Great.
<Laney> sil2100: want to check you can edit that?
<Wimpress> sil2100: I could not find you in Discourse. So let me know your username.
<Wimpress> Laney: Post globally pinned until 23:59 on April 24th.
<Laney> ð
<Laney> Wimpress: popey:: Another idea for that category might be a post with some links giving people info on how to contribute to the release (testing), then I could link to it from the top of this wiki post
<Laney> Or maybe in the Quality category and we link to that as a place for testers to gather
<Laney> (if you like, just edit the release post and add a short sentence linking people to where you want them to go)
<popey> Knock yourself out :D
<Laney> sorry, to remove that doubt, I'm suggesting but not volunteering to write that content I'm afraid :-)
* Laney changed the topic of #ubuntu-release to: Released: Bionic 18.04.4, Eoan 19.10 | Archive: Final Freeze | Focal release status: https://discourse.ubuntu.com/t/focal-fossa-final-release-status-tracking/15366 | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: stress-ng (xenial-proposed/universe) [0.05.23-1ubuntu3 => 0.05.23-1ubuntu4] (no packageset)
<jibel> Laney, there is this post which already links to testing resources and daily builds https://discourse.ubuntu.com/t/testing-ubuntu-20-04-lts-official-ubuntu-flavors/14053
<tjaalton> Laney: hey, did you see my updates to the vulkan ffe?
<sil2100> Laney: thanks! Let me first try logging in
<sil2100> Laney, Wimpress: ok, I actually didn't even have an account - I have now created it
<sil2100> Wimpress: can you try adding me now?
<philroche> Wimpress: Should I be able to edit that post directly to update cloud image status? I don't seem to have perms to do so .. or is it pulling the updates from elsewhere?
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [sync] (focal-proposed) [8u252-b09-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (focal-proposed) [11.0.7+10-3ubuntu1]
<apw> sil2100, you ok with an update to the oem-5.6 kernel ?
<sil2100> ...we don't have it on any images now, right?
<Laney> sure we do
<xnox> apw:  i will upload ubiquity in a moment..... so yeah, they will respin.
<xnox> Laney:  sil2100: vorlon: paride reports that ssh -i /var/lib/jenkins/.ssh/cdimage cdimage@nusakan.canonical.com '/srv/cdimage.ubuntu.com/bin/mark-current -p ubuntu-server -s focal -t legacy-server -a amd64 20200417'
<xnox> fails
<xnox> when i run something similar, on my local machine..... it works.
<xnox> is there something missing? like clearing out the old 'focal-server-arm64.iso' from current & pending?
<xnox> or rather is stray published
<paride> xnox, did you try with "-t legacy-server" ?
<xnox> paride:  yes.
<sil2100> xnox: let me run that on nusakan and see how it fails
<xnox> Laney:  sil2100: vorlon: I think it is bad that "server" builds are listed on http://cdimage.ubuntu.com/ubuntu-server/daily/current/ together with "legacy-server" builds.
<xnox> paride:  but my local deployment has no "server.iso" builds.
<paride> sil2100, https://paste.ubuntu.com/p/m9cqKMmxjK/
<sil2100> huh
<paride> sil2100, note that is was passed "-a amd64" but still looks for an arm64 image
<sil2100> Need to see what current is right now, as I purged the old images from the latest publish directory
<sil2100> paride, xnox: I think I see the reason
<sil2100> paride: can you try now?
<apw> xnox, so are you happier if i drop it in now, rather than waiting ?
<xnox> sil2100:  the tree looks better!
<xnox> apw:  yeah, but oem kernel respins are cheap. It is only on the /pool => such that we can rebuild desktop iso, without rebuilding livefs.
<sil2100> xnox: yeah, stupid current was a mixture of different publish sets, and some were actually invalid symlinks because of my earlier purge
<xnox> apw:  it simply would redownload the old squashfs, and redo debian-cd add packages to the pool.
<xnox> apw:  ditto e.g. nvidia-*
<apw> xnox, ok then i will dump it in
<xnox> sil2100:  ful!
<xnox> sil2100:  fun!
<sil2100> apw: yeah, throw it at us
<apw> sil2100, if you are in agreement
<Laney> apw: you know you're not talking to a release team member for these acks right
 * Laney sees sneaky xnox 
<sil2100> ;)
<apw> Laney, which is why i am deferring to sil2100  :)
<sil2100> Oh, actually apw is a release team member, so he can ACK himself?!
<apw> sil2100, but one should not really count ones own ack in this context me thinks
<Laney> ok good
<paride> sil2100, mark-current -p ubuntu-server -s focal -t legacy-server -a amd64 20200417: success
<Laney> what is this new oem kernel for, out of interest?
<paride> thanks!
<apw> Laney, fixes for graphics and the like for supported platforms
<apw> Laney, and we get to make one last choice with britney yet
<sil2100> Laney: here's the changes file: https://launchpadlibrarian.net/474833166/linux-oem-5.6_5.6.0-1008.8_source.changes
<apw> by our standards tiny
<sil2100> I'd prefer not having a new release of that, but the GPU fixes sound legit...
<Laney> fair enough
<Laney> I was expecting it to be revved along with the GA kernel on that cadence but I just assumed that
<Laney> guess we're considering that kernel freeze only applies to the default kernel
-queuebot:#ubuntu-release- Unapproved: dbus-c++ (focal-proposed/universe) [0.9.0-8.1build1 => 0.9.0-8.1ubuntu1] (i386-whitelist, ubuntustudio)
<apw> Laney, it is a newer base, so yeah.  but we can hold this in -proposed and release it after too
-queuebot:#ubuntu-release- Unapproved: atk1.0 (focal-proposed/main) [2.35.1-1ubuntu1 => 2.35.1-1ubuntu2] (core, i386-whitelist)
<Laney> nod
-queuebot:#ubuntu-release- Unapproved: accepted dbus-c++ [source] (focal-proposed) [0.9.0-8.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted websockify [source] (focal-proposed) [0.9.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted atk1.0 [source] (focal-proposed) [2.35.1-1ubuntu2]
<sforshee> sil2100, Laney: fyi I'm respining the kernel for a couple of install-related issues
<sforshee> just the primary kernel, no derivatives
<Laney> sforshee: ok, eta?
<sforshee> Laney: I'm test building now, should upload within the hour
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1020.21] (core, kernel)
<sil2100> sforshee: thanks for the heads up o/
<Laney> probably be spinning images later than my normal EOD then!
<bdmurray> remember there's somebody in a different TZ who can help! ;-)
<sforshee> sil2100, Laney: we usually use a build ppa, would be eaiser this time if I just upload to -proposed instead?
<sforshee> *would it
 * apw would lean to the PPA as it gives us one more chance to not take it
<sil2100> sforshee: let's keep the PPA approach
<sforshee> ack
<sil2100> We already recommended that for other bigger things
<Laney> yeah it doesn't add much delay
<sil2100> And we can deal with bin-sync in such cases, since we're expecting those and know where to look
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1020.21]
-queuebot:#ubuntu-release- Unapproved: collectd (focal-proposed/universe) [5.9.2.g-1ubuntu4 => 5.9.2.g-1ubuntu5] (no packageset)
<sil2100> I'm pushing some NBS fixes if anything ^
-queuebot:#ubuntu-release- Unapproved: accepted collectd [source] (focal-proposed) [5.9.2.g-1ubuntu5]
<sil2100> Only few more left \o/
<sforshee> new kernel is building, should be done in ~8 hours
<xnox> Laney:  https://paste.ubuntu.com/p/vZX45YS8fB/
<xnox> Laney:  so, should i just upload this, or do i need to explain my head bashing aobut this?
<Laney> xnox: If you have more explanation, put it in the changelog itself so that future students can study your thoughts
<bdmurray> jibel: Have you looked at these upgrade (automatic testing) failures at all?
-queuebot:#ubuntu-release- Unapproved: automake-1.15 (focal-proposed/universe) [1:1.15.1-5ubuntu1 => 1:1.15.1-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted automake-1.15 [source] (focal-proposed) [1:1.15.1-5ubuntu2]
<sil2100> cjwatson, stgraber: hey guys, need a quick opinion about something: I want to get rid of the last thing from the NBS report - basically the whole libopencl-clang-dev libopencl-clang9 libllvmspirvlib9 chain - basically both libllvmspirvlib9 and libopencl-clang9 can be safely removed as this is all caused by a dangling old version of libopencl-clang-dev (9.0.0-1build1)
<sil2100> cjwatson, stgraber: so I'm wondering, why is libopencl-clang-dev both 10.0.0-2 and 9.0.0-1build1 visible still? There is no reverse-dependency explicitly depending on the old version, so I'd assume the binary should be superseeded and no longer visible
<sil2100> Should I also remove the 10.0.0-2 libopencl-clang-dev binary package manually in this case?
<sil2100> eh, I mean, remove 9.0.0-1build1
<sil2100> Or will everything go fine when I simply remove the chain of libopencl-clang9 and libllvmspirvlib9 ? I guess maybe that's holding it in somehow
<locutus__> the clang approach for NBS stuff is usually do it an cross fingers :D
<locutus__> in this case, they are not provided by llvm-defaults, so you should be good to let them go, I'm not even sure why they existed in first place, maybe some sync from experimental
<locutus__> oh indeed, they are not provided by llvm-* so meh
<cjwatson> libopencl-clang-dev is Architecture: all, so LP conservatively keeps it around as long as any arch-dependent binaries from the same source and version are still active
<sil2100> cjwatson: oh!
<cjwatson> you shouldn't need to remove it manually
<sil2100> cjwatson: ok, so it will resolve itself once I remove the other two, thanks! Yeah, this makes total sense
<cjwatson> it'll be automatically superseded by the dominator once the other binaries are gone
<cjwatson> right
<locutus__> Package: libopencl-clang-dev
<locutus__> Architecture: amd64 i386
<locutus__> not anymore fortunately
<cjwatson> right, it was arch: all at version 9.0.0-1build1
<locutus__> yep :)
<locutus__> also debian tracker is confused by it
<sil2100> Thanks guys
<sil2100> Ok, so hopefully when stuff migrates, we'll be able to remove the last NBS binaries and we'll have a clean report
<Laney> sil2100: next: focal_uninst.txt :-)
<sil2100> :(
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.663 => 2.664] (desktop-core, i386-whitelist)
<rcj> Could I get a review of livecd-rootfs in the queue?
<sil2100> Wimpress: hey! Can you give me the powers now to edit that post? ;)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664]
<sil2100> jamespage: ok, looking at ceph now again
<sil2100> jamespage: so as said the diff is huge, 9MB, and I guess I see a lot of huge directories being added - just wanted to make sure that's correct
<Laney> xnox: you going to upload that soon?
<Laney> please close bug #1873434 when you do
<ubot5> bug 1873434 in ubiquity (Ubuntu Focal) "default kernel left installed on systems which use oem kernel" [Undecided,New] https://launchpad.net/bugs/1873434
<xnox> Laney:  yes.
<sil2100> jamespage: there's like src/rocksdb added and src/civetweb and those seem to have like super a lot of source files
<Laney> merci merci
<jamespage> sil2100: reviewing now
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.13 => 20.04.14] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (focal-proposed/main) [1.448 => 1.449] (core)
<xnox> paride:  did things work, or not?
<xnox> paride:  sil2100: should sil2100 mark all latests builds as current himself? cause then he will see what's broken
<xnox> sil2100:  can you please ./bin/mark-current for -t legacy-server for 20200417 for all 4 arches?
<xnox> Laney:  ubiquity uploaded
<Laney> xnox: R O C K O N
<paride> yes xnox it works now, but for the other archs the jobs still have to run. UTAH needs to be rebuilt
<paride> but the promotion worked
<xnox> paride:  ah cool!
<xnox> sil2100:  unping
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-calendar [source] (focal-proposed) [3.36.1-0build1]
<jamespage> sil2100: leave it with me - I had a load of exclusions in d/copyright that have somehow got dropped between 15.2.0 and 15.2.1
<jamespage> hence the stupid diff
<Laney> xnox: no idea how having "${OEM_KERNEL}" there causes the default kernel to remain installed
<Laney> voodoo
<jamespage> sil2100: would you like to reject that version and I'll have another run at it...
<sil2100> jamespage: ok o/
<sil2100> jamespage: rejected, give me a poke when you re-upload o/
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (focal-proposed) [15.2.1-0ubuntu1]
<jamespage> me listens to xz running his fans hard
<bdmurray> Shouldn't we just stop listing Eoan as active on the isotracker?
-queuebot:#ubuntu-release- Unapproved: python-launchpadlib (focal-proposed/main) [1.10.11-1 => 1.10.12-1] (core) (sync)
<cjwatson> ^- should fix autopkgtests
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (focal-proposed) [1:4.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.14]
-queuebot:#ubuntu-release- Unapproved: accepted python-launchpadlib [sync] (focal-proposed) [1.10.12-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (focal-proposed) [1.449]
<Laney> bdmurray: ok I updated the discourse with the packages that I think we should wait for before spinning
<Laney> going now
<bdmurray> Laney: ack, thanks!
<philroche> bdmurray: Laney: Wimpress: Can CPC team have edit access to the post too  so we can update cloud image build progress? myself and rcj if possible.
<sil2100> Laney: o/
<Laney> philroche: can't help with that, sorry
<Laney> bdmurray: sil2100: btw there's an autopkgtest backlog and quite a few things waiting in proposed
-queuebot:#ubuntu-release- Unapproved: virt-manager (focal-proposed/universe) [1:2.2.1-3ubuntu1 => 1:2.2.1-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (focal-proposed) [1:2.2.1-3ubuntu2]
<Laney> we're probably going to want to make a call on remaining things on monday, and I guess punt some of them to SRUs
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.6-dfsg-1 => 6.1.6-dfsg-2] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1008.8] (no packageset)
<sil2100> Laney: yeah
-queuebot:#ubuntu-release- Unapproved: spirv-headers (focal-proposed/universe) [1.5.1-4 => 1.5.1+git20200409-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: spirv-tools (focal-proposed/universe) [2020.1-2 => 2020.2-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: vulkan-loader (focal-proposed/main) [1.2.131.2-1 => 1.2.135.0-2] (desktop-core, i386-whitelist) (sync)
<tjaalton> synced these ^ back for the ffe
<jamespage> sil2100: OK re-uploading - I think I've got it right now...
<jamespage> (ceph that is)
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.0-0ubuntu2 => 15.2.1-0ubuntu1] (desktop-core, ubuntu-server)
<cjwatson> Bah, http://autopkgtest.ubuntu.com/packages/p/python-launchpadlib/focal/amd64 still failing.  Not sure I'll manage to cram this into focal now :-/
<cjwatson> ddstreet: ^- FYI
-queuebot:#ubuntu-release- Unapproved: lxd (focal-proposed/universe) [1:0.8 => 1:0.9] (edubuntu, ubuntu-server)
<stgraber> ^ this is a tiny change but apparently quite critical for LTS to LTS upgrade on WSL
<stgraber> (the lxd deb isn't seeded, this is used during upgrades only to switch over to the snap)
-queuebot:#ubuntu-release- Unapproved: lxcfs (focal-proposed/universe) [4.0.2-0ubuntu1 => 4.0.3-0ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (focal-proposed) [4.0.3-0ubuntu1]
<matlock> ^lxd We discovered in testing under some circumstances a user who upgraded from 16.04 to 18.04 and then upgrades to 20.04 on WSL would have their upgrade stall and could leave them with a broken system. This patch better handles that scenario. https://bugs.launchpad.net/ubuntuwsl/+bug/1862550
<ubot5> Ubuntu bug 1862550 in Ubuntu WSL "Upgrading to 20.04 Attempts to Install LXD via Snap Store" [Critical,Fix committed]
<rbalint> vorlon, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/382530 for glibc? the rest seems just flakiness
<xnox> matlock:  ok.... do you have a question?
<xnox> matlock:  did you want to open a bugtask against "lxd" package in Ubuntu project for the focal series?
<vorlon> rbalint: done
<xnox> matlock:  nevermind, i see the request from stgraber now.
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.7 => 1:20.04.9] (core)
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-dashtodock (focal-proposed/primary) [67+git20200225-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-workspaces-to-dock (focal-proposed/universe) [52-1 => 52+git20200318-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-workspaces-to-dock [sync] (focal-proposed) [52+git20200318-1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.9]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-system-monitor (focal-proposed/universe) [38-2 => 38+git20200414-32cc79e-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-system-monitor [sync] (focal-proposed) [38+git20200414-32cc79e-1]
-queuebot:#ubuntu-release- Unapproved: valentina (focal-proposed/universe) [0.6.1~dfsg-9build1 => 0.6.1~dfsg-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted valentina [sync] (focal-proposed) [0.6.1~dfsg-10]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.1-0ubuntu1]
#ubuntu-release 2020-04-18
<sforshee> Laney: the new kernel will be ready to copy as soon as armhf publishes in the ppa
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.24.30 => 5.4.0.25.31] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (focal-proposed/main) [5.4.0-24.28 => 5.4.0-25.29] (core, i386-whitelist, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-24.28 => 5.4.0-25.29] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (focal-proposed/main) [5.4.0-24.28 => 5.4.0-25.29] (core, kernel) (sync)
<Kamilion> Just curious if xen is going to see an update past 4.11 in an SRU, perhaps to 4.13, or at least cherrypicking the python3 scripts landing?
<Kamilion> no biggie, i'd prefer not to ship python2 on my iso spin though.
-queuebot:#ubuntu-release- Unapproved: purple-discord (focal-proposed/universe) [0.9.2019.11.04.git.6552cde-1 => 0.9.2020.04.05.git.db7dc79-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted purple-discord [sync] (focal-proposed) [0.9.2020.04.05.git.db7dc79-1]
-queuebot:#ubuntu-release- Unapproved: pyhamcrest (focal-proposed/main) [1.9.0-2 => 1.9.0-3] (no packageset) (sync)
<vorlon> ^^ unsatisfiable python2 build-deps; but is seeded on server and has python-twisted-core as a revdep also
-queuebot:#ubuntu-release- Unapproved: twisted (focal-proposed/main) [18.9.0-8 => 18.9.0-11] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (focal-proposed) [5.4.0-25.29]
<vorlon> sforshee: linux-signed in the queue seems to be a binary sync from the ppa, but it needs to be a source sync so that it gets the archived signed binaries AFAIU?
-queuebot:#ubuntu-release- Unapproved: winetricks (focal-proposed/universe) [0.0+20190912-1 => 0.0+20200412-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted winetricks [sync] (focal-proposed) [0.0+20200412-1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- Unapproved: linux-signed (focal-proposed/main) [5.4.0-24.28 => 5.4.0-25.29] (core, kernel) (sync)
<vorlon> ummm ok, I tried the copy again without -b and I still see binaries in the queue
<vorlon> and it's trying to build now in the archive. alrighty then
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (focal-proposed) [5.4.0.25.31]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- New sync: pulseaudio-dlna (focal-proposed/primary) [0.5.3+git20200329-0.1]
-queuebot:#ubuntu-release- Unapproved: pdftk-java (focal-proposed/universe) [3.0.6-1 => 3.0.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pdftk-java [sync] (focal-proposed) [3.0.9-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1008.8]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-25.29] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-25.29] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-25.29] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-25.29] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: faudio (focal-proposed/universe) [19.12-1 => 20.04-2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: wcc (focal-proposed/universe) [0.0.2+dfsg-4ubuntu1 => 0.0.2+dfsg-4.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wcc [sync] (focal-proposed) [0.0.2+dfsg-4.1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-arc-menu (focal-proposed/universe) [38.3-dev-2 => 45-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-arc-menu [sync] (focal-proposed) [45-1]
-queuebot:#ubuntu-release- Unapproved: fish (focal-proposed/universe) [3.1.0-1.1 => 3.1.0-1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fish [sync] (focal-proposed) [3.1.0-1.2]
-queuebot:#ubuntu-release- Unapproved: r-cran-ranger (focal-proposed/universe) [0.12.1-1build1 => 0.12.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ranger [sync] (focal-proposed) [0.12.1-2]
-queuebot:#ubuntu-release- Unapproved: ugene (focal-proposed/multiverse) [33.0+dfsg-1 => 34.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ugene [sync] (focal-proposed) [34.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: php-parser (focal-proposed/universe) [4.3.0-1 => 4.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted php-parser [sync] (focal-proposed) [4.4.0-1]
-queuebot:#ubuntu-release- Unapproved: openjdk-15 (focal-proposed/universe) [15~18-1ubuntu1 => 15~19-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-15 [source] (focal-proposed) [15~19-1ubuntu1]
-queuebot:#ubuntu-release- New binary: ugene [amd64] (focal-proposed/multiverse) [34.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjdk-14 (focal-proposed/universe) [14.0.1+7-1 => 14.0.1+7-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: openjdk-15 (focal-proposed/universe) [15~19-1ubuntu1 => 15~19-1ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: openjdk-13 (focal-proposed/universe) [13.0.3+3-1ubuntu1 => 13.0.3+3-1ubuntu2] (i386-whitelist)
<RikMills> can someone hint software-properties past the crash/7.2.8-1ubuntu1 test failures, or retry the tests if it is likely to now find the missing ddebs?
<cjwatson> RikMills: is it just failing because ddebs.u.c is outdated then?
-queuebot:#ubuntu-release- New: accepted ugene [amd64] (focal-proposed) [34.0+dfsg-1]
<RikMills> cjwatson: Unable to locate package linux-image-5.4.0-24-generic-dbgsym
<cjwatson> RikMills: if so, it's about 80% of the way through a multi-day catch-up job; worth trying again at some point tomorrow
<cjwatson> I'll mention here when I notice that it's caught up
<RikMills> cjwatson: ok. I would just like a fix from that blocked upload is 1st RCs, but it is not absolutely crucial
<RikMills> thanks
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-15 [source] (focal-proposed) [15~19-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [source] (focal-proposed) [13.0.3+3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-14 [source] (focal-proposed) [14.0.1+7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libreoffice-dictionaries (focal-proposed/main) [1:6.4.0~rc2-1 => 1:6.4.3-1] (personal-gunnarhj, ubuntu-desktop) (sync)
<mapreri> FYI, the above libreoffice-dictionaries is because of LP#1873511
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu612 => 20101020ubuntu613] (core)
<hggdh> just a question -- how long after release can we expect to have 20.04 available on Azure?
-queuebot:#ubuntu-release- New sync: sugar-imageviewer-activity (focal-proposed/primary) [65-1]
-queuebot:#ubuntu-release- New sync: sugar-terminal-activity (focal-proposed/primary) [47-1]
-queuebot:#ubuntu-release- New sync: sugar-write-activity (focal-proposed/primary) [100-1]
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-easyscreencast (focal-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- New sync: sugar-chat-activity (focal-proposed/primary) [86-1]
-queuebot:#ubuntu-release- New sync: sugar-read-activity (focal-proposed/primary) [121-1]
-queuebot:#ubuntu-release- New sync: sugar-browse-activity (focal-proposed/primary) [205-2]
-queuebot:#ubuntu-release- New sync: sugar-calculate-activity (focal-proposed/primary) [46-1]
-queuebot:#ubuntu-release- Unapproved: torbrowser-launcher (focal-proposed/universe) [0.3.2-7 => 0.3.2-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted torbrowser-launcher [sync] (focal-proposed) [0.3.2-9]
-queuebot:#ubuntu-release- Unapproved: gnome-contacts (focal-proposed/universe) [3.36-1 => 3.36.1-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-contacts [sync] (focal-proposed) [3.36.1-1]
-queuebot:#ubuntu-release- New sync: sugar-jukebox-activity (focal-proposed/primary) [36-1]
-queuebot:#ubuntu-release- New sync: sugar-memorize-activity (focal-proposed/primary) [58-1]
-queuebot:#ubuntu-release- Unapproved: snort (focal-proposed/universe) [2.9.7.0-5build1 => 2.9.15.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted snort [sync] (focal-proposed) [2.9.15.1-2]
-queuebot:#ubuntu-release- New sync: sugar-datastore (focal-proposed/primary) [0.117-1]
<bdmurray> hggdh: I'm pretty sure right away but check with philroche
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (focal-proposed/universe) [1:20200402-0ubuntu1 => 1:20200418-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (focal-proposed) [1:20200418-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: weechat (focal-proposed/universe) [2.6-2ubuntu1 => 2.6-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted weechat [source] (focal-proposed) [2.6-2ubuntu2]
<vorlon> bdmurray: do you want to rule on pyhamcrest + twisted?  they're seeded, but pyhamcrest ftbfs in main due to python2 build-dep and both of them need updated to drop python2 support to be maintainable in focal
<vorlon> bdmurray: so if not updated, we'd be trying to drop python2 support in SRU if they ever needed an update
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu613]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Focal Final] (20101020ubuntu613) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Focal Final] (20101020ubuntu613) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Focal Final] (20101020ubuntu613) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Focal Final] (20101020ubuntu613) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Focal Final] (20101020ubuntu613) has been added
-queuebot:#ubuntu-release- Unapproved: virglrenderer (focal-proposed/main) [0.8.2-1 => 0.8.2-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu5 => 1:4.2-3ubuntu6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu7 => 6.0.0-0ubuntu8] (ubuntu-server, virt)
#ubuntu-release 2020-04-19
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5] (i386-whitelist) (sync)
<wgrant> virglrenderer, qemu, libvirt are the initial riscv64-supporting versions. ruby2.7 works around a symbols mistake I made during the final stages of the riscv64 bootstrap.
-queuebot:#ubuntu-release- New sync: sugar-write-activity (focal-proposed/primary) [101-1]
-queuebot:#ubuntu-release- New sync: sugar-pippy-activity (focal-proposed/primary) [75-1]
-queuebot:#ubuntu-release- New sync: sugar-read-activity (focal-proposed/primary) [123-1]
-queuebot:#ubuntu-release- Unapproved: python-nmea2 (focal-proposed/universe) [1.15.0-1.1 => 1.15.0-1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-nmea2 [sync] (focal-proposed) [1.15.0-1.2]
-queuebot:#ubuntu-release- Unapproved: tdiary (focal-proposed/universe) [5.1.0-1 => 5.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tdiary [sync] (focal-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New sync: libbpf (focal-proposed/primary) [0.0.6-1]
-queuebot:#ubuntu-release- Unapproved: php-text-captcha (focal-proposed/universe) [1.0.2-6 => 1.0.2-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted php-text-captcha [sync] (focal-proposed) [1.0.2-7]
-queuebot:#ubuntu-release- New binary: php-text-captcha [amd64] (focal-proposed/universe) [1.0.2-7] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-25.29]
-queuebot:#ubuntu-release- Unapproved: f2fs-tools (focal-proposed/universe) [1.11.0-1.1 => 1.11.0-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libbfio (focal-proposed/universe) [20170123-5 => 20170123-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted f2fs-tools [source] (focal-proposed) [1.11.0-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libbfio [source] (focal-proposed) [20170123-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: codeblocks (focal-proposed/universe) [17.12+dfsg-1build1 => 20.03-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted codeblocks [sync] (focal-proposed) [20.03-3]
-queuebot:#ubuntu-release- Unapproved: x2gothinclient (focal-proposed/universe) [1.5.0.1-3build1 => 1.5.0.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted x2gothinclient [sync] (focal-proposed) [1.5.0.1-5]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] (20200419) has been added
<jbicha> vorlon: python-twisted still has several reverse-dependencies in focal; you'll probably want to handle python-sphinx first
<cjwatson> ddebs update: the very long run apparently completed but didn't update dists, so it probably crashed shortly before the end; unfortunately there was a log rotation difficulty so I can't see exactly what happened.  Another catch-up run is in progress, and should be skipping over most of the stuff that it had already fetched.  Earlier today I discovered a DNS resolution issue on that machine and ...
<cjwatson> ... worked with IS to get it fixed (or at least worked around for now), so ddeb fetching is now going much faster - about 10s faster per file.
<cjwatson> Currently about a third of the way through this second catch-up.
<cjwatson> I don't think it will be any less than ten hours from here though.
<cjwatson> Must get https://bugs.launchpad.net/launchpad/+bug/1856774 fixed though - as well as helping with an awkward corner case, it should let us improve ddeb fetching performance across the board.
<ubot5> Ubuntu bug 1856774 in Launchpad itself "Export source_package_name and source_package_version on BPPH" [High,Triaged]
<RikMills> cjwatson: thanks for the update
-queuebot:#ubuntu-release- New sync: whipper (focal-proposed/primary) [0.9.0-1]
-queuebot:#ubuntu-release- Unapproved: lxc-templates (focal-proposed/universe) [3.0.4-1ubuntu1 => 3.0.4-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxc-templates [source] (focal-proposed) [3.0.4-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-launchpadlib (focal-proposed/main) [1.10.12-1 => 1.10.13-1] (core) (sync)
<cjwatson> python-launchpadlib: third time lucky
<cjwatson> (thanks ddstreet)
<LocutusOfBorg> wgrant, ruby2.7 has been rejected by vorlon because of some indentation
<LocutusOfBorg> "includes packaging changes, no freeze justification, and regresses risv64 support due to wrong indentation in debian/rules."
<LocutusOfBorg> unless kanashiro wants to fix ??
<LocutusOfBorg> (I mean sid)
<LocutusOfBorg> also symbols sadness on sid
<LocutusOfBorg> kanashiro, ^^ please upload in sid? its building on my ppa https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/11195317/+listing-archive-extra
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5ubuntu1] (i386-whitelist)
<xnox> vorlon:  Laney: reading https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/focal/daily-live-20191019.log it seems like it's using old /images/ from d-i?
<xnox> vorlon:  Laney: what is ftpsync configs? does it only sync /images/ and not /legacy-images/ ?
<xnox> can you purge focal/main/installer-*/*/images/ from nusakan?
<xnox> bah
<xnox> ignore me
<xnox> i should read a log from this year
<vorlon> jbicha: I don't see any references to twisted in python-sphinx's deps or build-deps?
<vorlon> Laney: we might need some desktop help figuring out LP: #1871960, we have just fixed update-manager to use the right debconf frontend on upgrade from 18.04 to 20.04 (gnome instead of readline, the latter means debconf questions are hidden by default in the terminal widget) and now we see reports of maintainer scripts segfaulting on upgrade
<ubot5> Launchpad bug 1871960 in pam (Ubuntu) "package libpam-modules 1.1.8-3.6ubuntu2.18.04.1 failed to install/upgrade: pre-dependency problem - not installing libpam-modules:amd64" [Critical,Incomplete] https://launchpad.net/bugs/1871960
<jbicha> vorlon: it's a long chain: python-sphinx > python-requests > python-urllib3 BD> python-tornado BD> python-twisted
<jbicha> I worked a bit on the sphinx stuff in Ubuntu but then I hit OpenStack stuff and I ran out of energy to handle those
<jbicha> could you look at bug 1872598 ?
<ubot5> bug 1872598 in ipython-py2 (Ubuntu) "Please remove ipython-py2 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1872598
<vorlon> jbicha: done
-queuebot:#ubuntu-release- Unapproved: forensics-all (focal-proposed/universe) [3.17 => 3.18] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted forensics-all [sync] (focal-proposed) [3.18]
-queuebot:#ubuntu-release- Unapproved: wifite (focal-proposed/universe) [2.5.0~git20191114-2ubuntu1 => 2.5.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wifite [sync] (focal-proposed) [2.5.2-3]
<tsimonq2> Last seed update for the cycle (hopefully) incoming.
<tsimonq2> This pulls the plug on the broken GRUB theme we have, and adds packages for riscv64.
<tsimonq2> A good question on that is whether it'll need to go through Binary NEW but I'd imagine not.
<tsimonq2> (I didn't plan on doing it this late but the flurry of GRUB theme bug reports made me pull the plug hard.)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (focal-proposed/universe) [20.04.6 => 20.04.7] (lubuntu)
<cjwatson> Binary NEW isn't required if it's just a new architecture for an existing binary package name.
-queuebot:#ubuntu-release- Unapproved: ardentryst (focal-proposed/universe) [1.71-6ubuntu1 => 1.71-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ardentryst [source] (focal-proposed) [1.71-7ubuntu1]
<cjwatson> ddeb-retriever chugging slowly through many apt-ftparchive runs now ...
