#ubuntu-release 2010-10-11
<pitti> jdstrand: yep, kees ack'ed it, too; it's in now
<apw> skaet, i wonder if 'open the work-items database for the new release' should be on the release checklist somewhere, it can be done as soon as a driver actually makes the release in launchpad i believe
<apw> (its done now in theory btw)
<skaet> apw,   am working through the checklist now.    If its not there,  I'll add it.
<apw> skaet, fun bedtime reading i am sure ... congrats btw on surviving the release :)
 * cjwatson is going round sorting out the seeds
<cjwatson> mvo: oh, I noticed a comment from you that the dist-upgrader-all directory was only in -proposed, not -updates - want me to fix that?
 * skaet is glad to see cjwatson,  and has some questions....
<cjwatson> congratulations on the release, seems to have gone smoothly :)
<skaet> cjwatson,  smoother than the stories robbiew has been telling me for the last couple of months at any rate ;)
<mvo> cjwatson: a fix for this would be much appreciated, ideally so that on copy from -proposed to -update the dist-upgrader-all dir is copied as well
<wgrant> Bug #231371
<ubot4> Launchpad bug 231371 in soyuz "support dist-upgrader pocket copy " [High,Triaged] https://launchpad.net/bugs/231371
<skaet> cjwatson,  which tasks from the checklist have you handled already?
<cjwatson> mvo: unfortunately it has to be manual, but I updated https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20update-manager%20updates
<cjwatson> s/updated/wrote/ actually
<cjwatson> mvo: or rather, it has to be manual unless Soyuz is enhanced ... anyway, you'll see it in -updates in an hour or so
<mvo> cjwatson: great, thanks cjwatson!
<cjwatson> skaet: none yet, I was just starting on creating the new seeds
<cjwatson> skaet: can you access https://launchpad.net/ubuntu/maverick/+driver ?  might as well do step 1 :-)
 * cjwatson runs 'for x in *.maverick; do bzr branch $x ${x%.maverick}.natty; done' and starts pushing those up
 * skaet has changed driver for maverick to ubuntu-core-dev.
<jml> hello
<skaet> cjwatson,  jml indicates that a Natty distroseries has been created with status FUTURE.   Should we move it to FROZEN?
<cjwatson> FUTURE?  wow.
<cjwatson> shiny new lp feature?
<cjwatson> hang on a sec, need to finish seeds first.
<jml> cjwatson: shiny new lack of buck
<jml> bug
<jml> I have no idea how I misspelled that
<cjwatson> I fixed its displayname
<wgrant> jml: Did you need DB hacking to do that?
<wgrant> I can't see it in the UI.
<jml> wgrant: no. there's an option to change the status
<jml> wgrant: perhaps it's a restricted view?
<cjwatson> natty seeds created, germinate output running (we don't need to wait for that)
<cjwatson> seed mirrors created too, so that's steps 2 and 3
<cjwatson> checked maverick release pocket queue, it's empty (step 4)
<wgrant> Ah, there.
<cjwatson> I assume we still ought to disable the publisher during distroseries initialisation?
<wgrant> Uh, yes.
<wgrant> Or boom.
<jml> :(
<jml> wgrant: is there a bug filed for that?
<wgrant> Hm, it's possibly OK if we do a careful run afterwards like the instructions say. But it's not tested TTBMK.
<cjwatson> publisher disabled
<cjwatson> jml: yes, please move natty to FROZEN
<wgrant> The publisher, i-d-s and transactions have an interesting relationship :/
<skaet> :)
<cjwatson> is it correct for both lucid and maverick to be CURRENT?
<cjwatson> IIRC before we've had the LTS be SUPPORTED.
<jml> cjwatson: need a losa to do that, I think.
<wgrant> Needs a LOSA, and yes Lucid should be supported.
<cjwatson> skaet: ok, you wanna chase a LOSA to change lucid -> SUPPORTED and natty -> FROZEN?
<cjwatson> I've created an ubuntu-11.04 milestone.  will go round and create the other milestones since I might as well
<skaet> cjwatson,  jml's volunteered.
<skaet> cjwatson, re: other milestones, sounds good.
<cjwatson> all milestones created
<cjwatson> https://launchpad.net/ubuntu/natty/+milestones
<skaet> \o/
<cjwatson> https://launchpad.net/ubuntu/+series indicates that the statuses are fixed
<cjwatson> oh, of course, germinate output won't work until the publisher has run, silly me
<cjwatson> more-extra symlinks created (step 9)
<cjwatson> wgrant,jml: in https://wiki.ubuntu.com/NewReleaseCycleProcess step 10 and 12, do both of those need to be LPCONFIG=ftpmaster-publish now?  I know that step 12 does, but not sure about i-f-p
<skaet> step 8 is verified, btw.
<wgrant> cjwatson: i-f-p shouldn't care.
<wgrant> cjwatson: It's all DB work.
<cjwatson> does it need an LPCONFIG environment variable at all, then?
<wgrant> It needs to run as a specific DB user.
<wgrant> Hm.
<wgrant> But that may be in the script.
 * wgrant checks.
<wgrant> Someone needs to check the configs (the key is archivepublisher/dbuser)
<wgrant> They're probably the same.
<cjwatson> any guess on filename?
<wgrant> Not sure where the production configs live on prod, sorry.
 * cjwatson guesses at production-configs/ :-)
<wgrant> Ah.
<wgrant> ftpmaster/launchpad-lazr.conf in there, then.
<cjwatson> no dbuser there
<wgrant> Inheritance yay.
<cjwatson> nor in ftpmaster-publish/
<wgrant> So they're the same.
<cjwatson> does meta/extends define the inheritance?
<wgrant> Yes.
<cjwatson> ah, in fact ftpmaster-publish/launchpad-lazr.conf is really simple
<wgrant> Just changing dirs?
<cjwatson> all it does is set error_reports/oops_prefix to FTPMASTERPUBLISH and error_reports/error_dir to /srv/launchpad.net/production-logs/lp_publish - otherwise it just extends ftpmaster
<wgrant> Doesn't matter, then.
<cjwatson> and some log file fiddling in the non-lazr stuff
<cjwatson> ok
 * cjwatson fixes the publisher steps in the process, where it does matter
<jml> it's going to be a few hours before we'll be ready to run the branch-distro script
<jml> (step 11)
<cjwatson> jml: ok, but you guys consider yourselves notified?
<jml> cjwatson: indeed we do.
<cjwatson> preparing to run i-f-p
<wgrant> The subsequent careful publisher could be amusing.
<wgrant> But we'll see.
<cjwatson> will use '-a amd64,armel,i386,powerpc' (per the note in the process page, which comes from StevenK)
<cjwatson> amusing?
<ogra> skaet, hmm, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest talks about the ARM releases living on releases.u.c (i'm not sure we want to move them, but the manifest page should be in sync)
 * ogra just noticed that now :(
<skaet> ogra, no worries.   let me look
<wgrant> cjwatson: Amusing in that it might fail, due to some stuff that was done a couple of weeks ago. But it should be OK.
<cjwatson> ogra: I explicitly checked with davidm and he said cdimage not releases
<ogra> cjwatson, perfect
<wgrant> The -a might be unnecessary now, but won't hurt.
<cjwatson> ogra: where does that page talk about ARM living on releases.u.c?
<ogra> (i personally dont like them on r.u.c because the download page gets confusingly full)
<cjwatson> i-f-p running
<cjwatson> 2010-10-11 10:23:02 ERROR   Parent series has pending builds.
<wgrant> Crap.
<ogra> ugh, i should have more coffee ...
<wgrant> Indeed.
<persia> cjwatson, Maybe just historical, but they did live on r.u.c for karmic/lucid.
<wgrant> Three pending armel builds.
<ogra> cjwatson, skaet sorry for the noise ... a discussion in another channel got me confused
<skaet> cjwatson, thankds for clarifying.
<wgrant> Investigating.
<cjwatson> https://edge.launchpad.net/ubuntu/maverick/+builds?build_text=&build_state=pending&arch_tag=all
<ogra> indeed its exactly the opposite of what i said. all is fine
<wgrant> cjwatson: Their DB state is corrupt.
<wgrant> cjwatson: There are pending, but not queued.
<wgrant> We'll need DB surgery to set them to some other state (probably Superseded).
<cjwatson> I'll go find a LOSA
<cjwatson> persia: indeed.  moving them was an explicit decision, I'm told
<persia> Ah, OK.  If it's intentional, it's good :)
<cjwatson> wgrant: mthaddon asked if he could have some SQL
<wgrant> cjwatson: They should have some already, I would have thought.
<wgrant> But otherwise:
<wgrant> http://paste.ubuntu.com/510797/
 * cjwatson isn't seeing anything relevant on the internal LPHowTo page
<cjwatson> but then, not a LOSA
<cjwatson> oh wait, there it is, it's on https://wiki.canonical.com/InformationInfrastructure/IS/BuilddFixing
<wgrant> Yeah, I can't exactly browse the internal wiki yet.
<cjwatson> ish
<cjwatson> well, quite
<cjwatson> but for mthaddon's benefit
<wgrant> Does that also specify deleting BuildQueues and BuildPackageJobs?
<cjwatson> yes
<cjwatson> and Job
<wgrant> I don't think they exist in this case.
<wgrant> Right, forgot that one.
<cjwatson> right - the context here is forcibly removing a build that kills buildds
<wgrant> Yeah.
<cjwatson> rerunning i-f-p, thanks mthaddon
<mthaddon> np
<cjwatson> 2010-10-11 10:48:54 ERROR   Parent series queues are not empty.
<cjwatson> gar
<cjwatson> does this really require non-RELEASE queues to be empty?
<wgrant> It shouldn't.
<cjwatson> shouldn't, looking at the code
<wgrant> I glanced over the code last night.
<wgrant> And it looked sane.
<cjwatson> oh, wait, NEW is non-empty
<cjwatson> hah, this is a bug
<wgrant> Oh?
<wgrant> Ah.
<wgrant> partner.
<wgrant> Indeed.
<cjwatson> partner is non-inherited, but i-f-p refuses if it has queue entries
<cjwatson> I guess I can just process these and then wait ...
 * cjwatson files a bug in the meantime
<wgrant> Or maybe convince someone to cowboy the extra arg into i-f-p.
<cjwatson> it's probably faster to process NEW ...
<wgrant> Unfortunately true.
<wgrant> And then wait for the publisher.
<wgrant> Oh.
<wgrant> But they're sources, so no publisher required.
<wgrant> If you're quick.
<jml> fwiw, I reckon it'd be a good idea to have some common tag for bugs associated with doing the NewReleaseCycleProcess
<cjwatson> bug 658256, if you want to give it one
<ubot4> Launchpad bug 658256 in soyuz "initialise-from-parent refuses if there are NEW queue entries for partner (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/658256
<cjwatson> wgrant: not entirely sure I want to play that kind of game :)
<jml> cjwatson: thanks
<wgrant> cjwatson: Well, i-f-p will work fine if you run it between accepting those sources and the builds finishing.
<cjwatson> hm, I guess it will
<jml> wgrant: did you say there was a bug for need to disable the publisher during distroseries initialisation?
<cjwatson> in that case, I should do a coffee resupply *first*.
<wgrant> jml: I don't think there is. In the context of the whole process (with the extra careful runs later on) it will probably work fine, but it needs testing.
<cjwatson> we'd have to disable the cron job for the manual careful runs anyway
<cjwatson> so the fact that the careful runs is needed is a bug, if you want to look at it that way
<cjwatson> (i.e. should be possible to initialise new series without fiddling with publisher setup)
<cjwatson> s/runs is/runs are/ what happened there ...
<wgrant> We want to make dirty pockets forcable for other reasons anyway, which would eliminate the need for the careful runs.
<cjwatson> indeed.
<cjwatson> partner packages accepted, i-f-p running.  third time's the charm
<cjwatson> wgrant,jml: bug 55211 is essentially this, BTW.
<ubot4> Launchpad bug 55211 in soyuz "shouldn't require careful publisher run when cloning new released distrorelease (heat: 4)" [Medium,Triaged] https://launchpad.net/bugs/55211
<jml> cjwatson: ta. I'll mark https://bugs.edge.launchpad.net/soyuz/+bug/658269 as a dupe of that then.
<ubot4> Launchpad bug 658269 in soyuz "Initializing new series requires fiddling with publisher setup (affects: 1) (heat: 6)" [Undecided,New]
<elmo> btw, when you guys get bored with natty, don't forget antimony is down to 5Gb on /srv
<jpds> Can we remove jaunty from releases/ yet?
<wgrant> It doesn't die for nearly three weeks, does it?
<jpds> Damn.
<wgrant> Ah, no, 12 days.
<cjwatson> antimony can be sorted by a mass purge of daily builds, I imagine
<cjwatson> elmo: also you could do an archive pass on /srv/cdimage.ubuntu.com/old-images/, if skaet didn't already ask for it
<cjwatson> 63G there
<elmo> cjwatson: ok - I'll RT that - who should be notified when that's done, you + skaet?
<cjwatson> please
<cjwatson> initial publish-distro run in progress for natty
<wgrant> cjwatson: i-f-p still happy?
<wgrant> Hah.
<cjwatson> yep, i-f-p completed
<cjwatson> oddly quiet by comparison with the VERY NOISY rest of LP scripts
<cjwatson> (i.e. no output on successful completion)
<cjwatson> jml: hm, though I notice that I said in 55211 that this wouldn't be a problem for normal non-released distroseries
<cjwatson> evidently I was confused
<wgrant> Well, i-f-p is brand new.
<cjwatson> or else it doesn't actually require the careful run and we've just been overparanoid for years ...
<wgrant> And less special than the publisher.
<cjwatson> wgrant: *blink*
<wgrant> Hm?
<cjwatson> i-f-p dates back to 2006
<wgrant> It was largely rewritten a month or two ago.
<cjwatson> ah, well, even so, it was always quiet
<wgrant> Ah.
<cjwatson> not that I'm complaining
<wgrant> The careful publisher is necessary to get -proposed, -updates, -security, -backports indices.
 * cjwatson notes that in the bug
<wgrant> (If not careful, it'll only publish indices for dirty pockets. And we don't copy non-RELEASE, so they'll be empty and clean.)
<wgrant> Has it made it into the domination phase yet?
<wgrant> I guess that should be quick.
<cjwatson> it's done
<wgrant> Yay.
<cjwatson> about four minutes from init to get into domination phase.  when you asked it was in a-f.
<cjwatson> just doing other checks before publishing partner
<wgrant> Hm, longer than I would have hoped.
<cjwatson> can send you the log if you want
<wgrant> Nah.
<wgrant> If it worked, should be fine.
<cjwatson> actually, I think I misrea.
<cjwatson> +d
<wgrant> There should have been nothing empty, so the publishing phase (A) should have been a no-op.
<cjwatson> 21 seconds to get to start of domination phase; domination took a bit under four minutes
<wgrant> Right.
<wgrant> That's about what I would have expected.
<wgrant> Domination should take < 20s, but that's a known issue.
<cjwatson> packages were correctly not copied to partner; deleting that NRCP step
<wgrant> Excellent.
<cjwatson> publishing partner
<cjwatson> package sets were automatically copied over - thanks StevenK (IIRC), deleting that NRCP step
<jml> wgrant: a known issue you say? does it have a bug?
<cjwatson> I like this business of processes getting shorter
<wgrant> jml: Bug 654372
<ubot4> Launchpad bug 654372 in soyuz "Source domination is inefficient (affects: 1) (heat: 19)" [High,Triaged] https://launchpad.net/bugs/654372
<jml> cjwatson: :)
<wgrant> Fix is easy, but I want to see if I can clean it up first.
<wgrant> Since temp tables make me sad.
<jml> wgrant: I agree with everything you just said.
<cjwatson> publisher re-enabled
<cjwatson> waiting for the first automatic run now
<wgrant> A couple of minutes past the hour, still?
<cjwatson> :03
<cjwatson> lamont: can has new buildd chroots?
<cjwatson> (for natty)
<cjwatson> lamont: oh, you'll need to wait for the first publisher run to happen, I guess
<wgrant> Is there a reason we don't just copy the maverick ones across?
<lamont> cjwatson: I have maverick release tarballs that claim to be natty
<cjwatson> wgrant: they have sources.list entries, don't they?
<cjwatson> lamont: that works
<lamont> cjwatson: launchpad overwrites sources.list
<wgrant> cjwatson: They've been overridden since PPAs were introduced.
<cjwatson> copying is fine then
 * cjwatson updates the process
 * lamont tosses tarballs nattywards
 * lamont looks forward to his 5 day weekend
<cjwatson> skaet: current status: steps 1-15 and 17 done (reload the process page if you haven't recently, since I deleted a couple of steps)
<lamont> cjwatson: once the flood gates are open for a bit (like say next monday), I'll roll newer, shinier, less stale tarballs
<lamont> natty done, tossing final-bits maverick tarballs in as well
<skaet> cjwatson, ack, will reload.
<cjwatson> doko: if you'd like to go ahead and upload new toolchain bits, they should at least not bounce now
<wgrant> NRCP does say to wait until the first normal run finishes. But that shouldn't matter for internal stuff.
<skaet> cjwatson,  have done first pass of the page updates UbuntuDevelopment, ReleaseSchedule, ArchiveAdmin.
<skaet> also sent note off to rosetta
<cjwatson> wgrant: it does, but for the upload queue I don't believe it matters
<cjwatson> NRCP doesn't express parallelisable things very well
<wgrant> cjwatson: Ah, for the queue, no.
<wgrant> But even builds should work as soon as the chroots and careful publisher are done.
<skaet> cjwatson,  18,28 in new page done.
<cjwatson> 'k
<cjwatson> queuebot should be looking at natty now
<lamont> cjwatson: as long as you're tweaking, you could add a similar bullet to upload fresh tarballs for the just-released suite as well (makes ppa/whatnot builds slightly faster via smaller dist-upgrades)
 * skaet breaking for lunch and to run an errand.
<cjwatson> lamont: done
<wgrant> Erm.
<cjwatson> lack of previous version is because rmadison isn't up to date yet
<wgrant> Ah, of course.
<cjwatson> that'll sort itself out in a few hours
<cjwatson> and the "New" bit there just means new in the queue
<cjwatson> (as opposed to "Updated" which is "there was already a package in the queue, but now there's a newer version as well")
<wgrant> Right.
<wgrant> Package set memberships seem to have been correctly copied as well. This is good.
<cjwatson> yep
<cjwatson> updated archive reports to point to natty (step 19)
<wgrant> Er.
<wgrant> a.u.c has directories.
<wgrant> But no indices.
<wgrant> Ah, there now.
<pitti> the official excuse is of course "just in case you need a package to check if the queues are working"
<wgrant> cjwatson: You might want to add a note that i-d-s -a probably won't be necessary in future, since it skips disabled archs.
<cjwatson> oh, I'll just delete that bit in the process then, thanks
<cjwatson> (YM i-f-p)
<wgrant> Er, yes, the method is iDS, but the script is still i-f-p.
<cjwatson> merge-o-matic updated (step 20)
<doko> cjwatson: gcc-defaults and binutils waiting for approval
<cjwatson> any ordering constraints?
<cjwatson> wgrant: are you sure it skips them?  I don't see that in InitialiseDistroSeries._copy_architectures
<wgrant> cjwatson: That bit wasn't CP'd, it seems.
<wgrant> It's definitely in db-devel.
<wgrant> So it will be there next time.
<wgrant> Bug #649717
<cjwatson> ok, I was looking in devel, didn't know it was behind db-devel
<ubot4> Launchpad bug 649717 in soyuz "InitialiseDistroSeries should not copy disabled DASes (affects: 1) (heat: 6)" [Undecided,Fix committed] https://launchpad.net/bugs/649717
<wgrant> Confusingly, production and db-devel have DistroArchSeries.enabled, but devel doesn't.
<wgrant> Since it was a late patch at the end of last cycle.
<cjwatson> ok, process edited
<cjwatson> doko: sorry, not sure you saw that was directed at you - does it matter if gcc-defaults and binutils build in paralle?
<cjwatson> parallel
<wgrant> I'm not sure how it wasn't CPd, though. It was in production-stable before my thing to not publish disabled indices was CPd :(
<doko> cjwatson: no
<doko> cjwatson: sorry, distracted with the ac100 ...
<cjwatson> ok, accepted, thanks
<cjwatson> doko: anything else after binutils, gcc-defaults, and the eglibc copy?
<doko> cjwatson: you'll get gcc-4.4, gcj-4.4 and gnat-4.4 in a few minutes. for 4.5, I'll have to merge tomorrow's linaro release first.
<doko> it should be ok to continue with the toolchainish bits
<cjwatson> ok.  I didn't understand your last sentence though?
<doko> debhelper, perl, cdbs, dpkg, etc
<doko> autoconf/automake
<cjwatson> oh, right
<cjwatson> doko: does gcc-4.4 need to wait for armel to finish with binutils?
<doko> cjwatson: no
<cjwatson> ok, accepted
<doko> cjwatson: preparing base-files. should issue mention 11.04, or something else?
<cjwatson> I already uploaded base-files
<cjwatson> ("Ubuntu natty (development branch)" is the standard form)
<doko> ahh, ok
<cjwatson> if you want to review/accept it from the queue, that would be good
<cjwatson> not that the different-reviewer protocol really matters at this point, the freeze is just for ordering purposes
 * cjwatson starts on dpkg
 * skaet back from picking up her Toshiba AC100 :D,  and wondering what still needs doing?
<skaet> cjwatson, which tasks are left?
<Riddell> release natty :)
<skaet> lol
<Riddell> quickly, before we add any bugs
<skaet> Riddell, in about 6 months .....
<skaet> and there's a few bugs there today (or so maverick's release notes indicate ;) )
<cjwatson> skaet: we're in the middle of step 21, which is mostly on doko
<skaet> cjwatson,  anything I can do to help with the reports?
<cjwatson> which reports?
<cjwatson> jml: any progress on the branch creation?
<jml> cjwatson: slow progress.
<jml> cjwatson: in 45 mins I'll be in a position to ask for a cherry pick, once the cherry pick is done, I'll be in a position to create the branches.
<cjwatson> will anything break if I push stuff to lp:ubuntu/natty/SOURCEPACKAGE in the meantime, for things I'm working on?
<jml> cjwatson: I don't know. Give me a moment in which to educate myself enough to guess.
<jml> cjwatson: probably not.
<cjwatson> hm, I bet the short name (ubuntu/natty/SOURCEPACKAGE) as opposed to the long name (~ubuntu-branches/ubuntu/natty/SOURCEPACKAGE/natty) doesn't exist yet, though?
<skaet> cjwatson,  ..."modify various reports (britny, anastacia, jessica) to point to new distroseries
<cjwatson> oh that's done
<cjwatson> (and reload the process page, since I updated the names ...)
<cjwatson> there's a lot of stuff that's basically really quick s/maverick/natty/g in a bunch of places; those ones require cocoplum access
<cjwatson> done step 26 (the cdimage stuff) - a lot of the later steps are parallelisable
<cjwatson> merges.ubuntu.com seems to be working broadly as expected - I think
<skaet> hmm,  I can't seem to access cocoplum,  should I have access?
<skaet> or do I need to wait to qualify for some group for that?
<cjwatson> no, but we should get you that RSN
<skaet> I've done 28 already earlier.
<cjwatson> RT sent to get you archive access
<skaet> thanks...  editing through the ArchiveAdministration page helped explain some of the things I had questions about. ;)
<cjwatson> right, that doubles as the page every new archive admin gets to read as part of training
<cjwatson> ... and traditionally, also edit to fix any inadequacies :)
<skaet> heh,  when I have access, will do the (now standard) read, review and clarify the ambiguities ;)
<cjwatson> ubiquity intro message restored for next upload (step 30)
<skaet> \o/
<skaet> I'll start working through the bugs that needed to be release noted then, and get them targeted to Natty.   Should I am to milestone them for Alpha 1, so we don't loose focus?
<skaet> or just release target them, and let teams set milestones?
<skaet> cjwatson,   all is good with the scripts to start generating natty_probs.html and natty_outdate.html?
 * skaet needs to change locations.   Back on line after dinner. 
<cjwatson> skaet: yep, those scripts are running
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
<cjwatson> skaet: release-noted bugs> I think some discretion is probably called for depending on the nature of the bugs ...
<cjwatson> for nasty ones, alpha-1 seems a good idea
<skaet> cjwatson,  fair 'nuf.   I was planning on reading each anyhow, so will be selective with the alpha-1 milestoning.
<cjwatson> release-targeting is definitely right either way
#ubuntu-release 2010-10-12
<doko> cjwatson: I don't see any emails for syncs to natty, anything not set up (maybe on my side)?
<cjwatson> doko: what sort of syncs?
<cjwatson> as in what command line?
<doko> sync-source.py -S incoming -f gnat-4.4
<cjwatson> you forgot -b
<cjwatson> if you don't say '-b doko', it counts as an autosync - autosyncs don't get mails sent
<doko> oops
<cjwatson> (because it gets really noisy)
<cjwatson> doko: is it OK to accept my perl upload at this point?
<doko> cjwatson: sure
<cjwatson> done
<doko> just waiting for the gcc-4.5 build to finish on armel
<doko> then we can open
<cjwatson> autoconf, automake, debhelper are already up to date; dpkg is merged; could perhaps do with a cdbs merge
<cjwatson> I'll look at that now
<cjwatson> err.  this looks complicated.  I think a cdbs expert had better merge this.
<cjwatson> (e.g. somebody who actually uses cdbs)
<cjwatson> we can probably open without cdbs without serious difficulty
<doko> asked pitti
<persia> Is the copy of all the maverick-updates stuff to natty part of the release-open checklist?
<cjwatson> persia: no (and generally can't be)
<cjwatson> given that much stuff continues to go only to maverick-updates afterwards, for a while
<persia> Can't be?
<cjwatson> easy to check later though
<persia> Oh, I'd think it would be the last step, after "open the archive for general uploads"
<cjwatson> krb5: 1.8.1+dfsg-5ubuntu0.1 > 1.8.1+dfsg-5
<cjwatson> openssl: 0.9.8o-1ubuntu4.1 > 0.9.8o-1ubuntu4
<cjwatson> postgresql-8.4: 8.4.5-0ubuntu10.10 > 8.4.4-2
<cjwatson> update-manager: 1:0.142.20 > 1:0.142.19
<cjwatson> I guess I can add a quick note
<cjwatson> persia: ok, noted
<cjwatson> and I'll copy those four packages over now
<persia> cjwatson, thanks.
<cjwatson> (list above generated by lp:~cjwatson/+junk/suite-diff)
<cjwatson> jml: any progress on the branch import?
<doko> cjwatson: perl build failure
<cjwatson> ugh
<cjwatson> will look
<doko> gcc-4.5 probably
<cjwatson> nothing in the Debian BTS
<doko> if it doesn't fail with 4.5 in maverick, then maybe it's the linaro merge
<cjwatson> argh.  silly me for not having primed a local natty mirror straight away
<jml> cjwatson: again, slow progress. the CP has landed, I'm waiting on a LOSA to deploy it.
<cjwatson> jml: ok, thanks
<cjwatson> doko: fails on maverick with gcc-4.5, same way
<doko> hrm
<cjwatson> http://paste.ubuntu.com/511622/ - diff between old and new _h2ph_pre.ph, looks wrong
<cjwatson> I don't like the __DBL_* stuff there, never mind the rest of it
<doko> hmm, there should be patches floating around, gentoo and fedora do already build with 4.5
<cjwatson> how recently was perl test-built in maverick?
<cjwatson> yeah, about to check upstream
<persia> lucas ran a reguild not so long ago, but the results seem to have been cleared from the report page: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
<cjwatson> Configure is setting cppsymbols wrongly, so at least that puts the bug somewhere that doesn't take too long to run
 * cjwatson dusts off memories of how perl is organised
<cjwatson> doko: seems to be basically due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 rather than anything Linaro-specific.  I can't find a proposed Perl fix in any of the usual places, though, which is very weird
<ubot4> gcc.gnu.org bug 448 in c "<stdint.h>-related issues (C99 issues)" [Enhancement,New]
<doko> cjwatson: my first thought was, a typo in the pr number :-/
<cjwatson> just a very long-lived PR ...
<cjwatson> anyway I think that's what introduced the new macros
<cjwatson> hardly gcc's fault, though - perl is doing evil things with the headers and probably just has to cope
 * cjwatson tries bleadperl to see what happens there
<doko> plplot had evil header perl parsing scripts too ...
<cjwatson> ah, never mind, I think I found it
<cjwatson> http://perl5.git.perl.org/perl.git/commitdiff/8d66b3f930dc6d88b524d103e304308ae73a46e7 looks promising
<cjwatson> __DBL_DENORM_MIN et al are still wrong though ...
<cjwatson> maybe I can just assume that won't be a problem
<cjwatson> bingo
<cjwatson> doko: do you want python2.6 in before opening?
<doko> cjwatson: yes, and preparing 2.7 too
<doko> just really waiting for the gcc-4.5 armel build for the general opening. this should finish tomorrow evening
<cjwatson> doko: hmm, several patches removed from python2.6 not mentioned in the changelog?
<cjwatson>  debian/patches/arm-float.dpatch               |  119 ------
<cjwatson>  debian/patches/profiled-build.dpatch          |   36 -
<cjwatson>  debian/patches/pydebug-path.dpatch            |  100 -----
<cjwatson>  debian/patches/subprocess-eintr-safety.dpatch |   81 ----
<doko> it's mentioned
<doko> and these are the old .dpatch files
<cjwatson> oh, "remove obsolete old dpatch files"
<cjwatson> ok, reading better now ...
<cjwatson> I got confused because it was attached to something about Lib/locale.py
<doko> yes, sorry
<jml> incremental progress on the branches. we've deployed the critical bugfix. I've now asked a losa to run the script to make them
<jml> if this goes smoothly, I'm going to update the NRCP process to say "ask a LOSA" instead of "Notify James Westby/Jonathan Lange"
<cjwatson> great, thanks
<jml> turns out we already have internal documentation for doing this :)
<jml> https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BranchUbuntu for the Canonically-enabled
<cjwatson> just found it, yes :)
#ubuntu-release 2010-10-13
<wgrant> cjwatson: My suspicion about the broken Maverick armel builds was correct. We've had some more show up and a LOSA confirmed that the queue record is missing.
<wgrant> So I'm not completely insane.
<ScottK> wgrant: Correction: That's not evidence of you being completely insane.
<wgrant> True.
<cody-somerville> Is there something wrong with hpijs-ppds in Maverick?
<jml> cjwatson: the thing to create the branches was kicked off overnight. Once I finish interviewing this candidate I'll check on the status and get back to you.
<doko> cjwatson: ok to promote llvm-2.8 (used by openjdk-6) and python3.2 (used by python3-stdlib-extensions)? new upstream versions
<cjwatson> yep
<apw> doko, ok the initial kernel is finialised and in the accept queue
<apw> cjwatson, i've pushed the initial kernel for natty, i believe doko wants that built to bootstrap the toolchain
<cjwatson> apw: looks like somebody beat me to accepting it :)
<apw> cjwatson, :)  thanks anyway
<doko> cjwatson: I did :-/
<doko> I won't interfer anymore after the initial bootstrap
<doko> security hits the buildds hard ...
<cjwatson> I didn't consider it interfering
<cjwatson> jml: ooh.  I spy a bunch of branches.
<jml> cjwatson: yes. the script is still running[1] afaik
<jml> [1] Where "running" means one of: actually running; stopping; waiting for someone to restart it
<doko> apw: how long do the kernel builds usually take?
<cjwatson> doko: are you still intending to upload python2.7?
<doko> cjwatson: hmm, no
<doko> cjwatson: so when the kernel headers are there, we could open natty
<jml> cjwatson: the branching process is done. some branches failed. we'll look into it, but not as an issue of critical importance.
<cjwatson> doko: last linux build was 2h on amd64, 15h on armel, 7h on i386, 4h45m on powerpc
<cjwatson> jml: great, thanks - I think that's good enough to open with
<cjwatson> doko: I'd like to run through at least one compiled package with the new linux, so that we won't get the situation where we open the floodgates and find that everything fails to build
<jml> cjwatson: cool. let me know if there's anything else I can do to help.
<cjwatson> *nod*
<cjwatson> doko: (there are plenty of random merges in the queue we could use)
<doko> cjwatson: yes, makes sense
<doko> xvfb still broken, no jtreg test results for openjdk-6, but at least the build doesn't take that long
<doko> again, firefox security uploads ... we'll never open this week with powerpc lagging that behind :-/
<cjwatson> we'll still be ahead of historical schedule for opening, I think
<cjwatson> depending on whether you count in calendar days or working days
<cjwatson> (I think calendar days are slightly more realistic for this purpose since much of the time is spent waiting around for computers)
<cjwatson> doko: I've scored up linux/powerpc, not that it will help hugely (UI says start in 7 hours)
<cjwatson> actually, that will have it finishing around the same time as linux/armel finishes, so that might be OK
<apw> doko, cjwatson the build will be about 6-7 hours total, armel is only one flavour right now
<cjwatson> ah, so powerpc will be the last one after all then
<apw> cjwatson, yeah i see, damnable security
<doko> apw, cjwatson: http://launchpadlibrarian.net/57569441/buildlog_ubuntu-natty-powerpc.linux_2.6.36-0.1_FAILEDTOBUILD.txt.gz should we ignore this, or fix it before opening natty?
<apw> doko, well its probabally an easy fix
<doko> apw: ok, I'll be awake for about 30min, let me know if you could prepare another upload
<apw> doko, i'll know shortly if its easy
<doko> thanks
#ubuntu-release 2010-10-14
<cjwatson> doko: meh.  I'd sort of like to be in sync
<cjwatson> otherwise we'll waste time diagnosing weird stuff
<cjwatson> bleh, who NEWed linux?  it's all gone to universe
<cjwatson> use kernel-overrides
 * cjwatson fixes it up with security-kernel-overrides
<cjwatson> or I would if LP hadn't apparently exploded
<cjwatson> ... downtime, I guess
<apw> cjwatson, yeah was some downtime
<cjwatson> 2200-0000 UTC, so that would be now
<apw> yeah ... bah
<cjwatson> any luck with the problem at hand?
<apw> i think i've sorted it out, am trying get a test build started to confirm
<cjwatson> I'd like to try test-building something on !powerpc to make sure that the new linux-libc-dev works, but I can try that in a chroot locally
<apw> cjwatson, good plan, before it polutes the chroots
<cjwatson> a not very randomly chosen sample of anna and man-db still compile
<cjwatson> which includes man-db's rather rudimentary test suite so binaries also still run
<cjwatson> LP's back up sufficiently to run change-override, so have moved things back to main where they belong
<apw> cjwatson, thats good news.  the build is looking plausable on ppc, not quiet sure how long it'll run yet
<apw> am inclined to upload it so you can new, and we can sleep
<cjwatson> sounds good
<cjwatson> need sleep myself, have to handle the kids tomorrow morning
<apw> building the package now
<apw> cjwatson, ok its uploaded, should be on the queue as soon as the queue runner finds it
<apw> ok it's there
<cjwatson> accepted, thanks
<cjwatson> just looking at that queuebot bug
<apw> cjwatson, heh it'll wait till tommorrow
<cjwatson> if I do that I'll forget
<cjwatson> (it's a one-liner anyway)
<cjwatson> (slightly too late to demonstrate the fix, unfortunately)
<stgraber> auto reconnect ?
<cjwatson> stgraber: no, code upgrade
<cjwatson> I'll add a "don't report initial queue" option for next time
<cjwatson> apw: hm, still broken on powerpc
<apw> cjwatson, ok that overnighter also failed to build for a new error, i have a fix for the error it hit, but am flying blind fixing it as i cannot do a full build on the porters due to chroot issues... do we want to hope this fixes it en-toto or wait for the porters to be fixed
<apw> (from -devel)
<apw> flying blind testing it
<cjwatson> hm, it got quite a distance through didn't it?
<apw> yeah i have fixed the build failure in that flavour
<cjwatson> I'd say upload blind but keep going on davis in parallel
<apw> ack
<apw> what is odd is the build seems to progress in a different order on a buildd than a full build with dpkg-buildpkg -B seems to
<apw> cjwatson, who owns the porters is that #is ?
<apw> cjwatson, ok porters fixed and testing done, sadly failed, another build failure in perf.  I have fixed that and have built all the components on the porter successfully
<apw> so i believe i now have a fixed source package, a full test is building as belt-and-braces
<apw> i beleive this should be the final version, and i suspect I should just upload it
<cjwatson> apw: I suspect so, from the sound of it
<cjwatson> interesting ride, this
<apw> cjwatson, ports can be a major pain at this stage, normally we can let them drift
<apw> i am not sure the kernel has gated the release before
<cjwatson> I don't mind letting them drift if they've built once, but I'm concerned about having the architectures out of sync for major toolchain components right at the start - the point of splitting off ports is to make them consume less developer time, and while I realise this is a bit of extra time at the start I think that having things too out-of-sync would consume more developer time in the long run
<cjwatson> and we're not behind schedule or anything so it seems worth spending a bit of time now for less hassle later
<apw> cjwatson, fair enough.  i am pretty hopeful from the testing i have managed to do that this one should build fine on all arches
<apw> cjwatson, we might need to rescore that ppc build
<cjwatson> apw: done
<apw> cjwatson, ok finally all those builds finished, so once powerpc is new'd we have a full set of linux-libc-dev
<cjwatson> looks like somebody's done it
<cjwatson> doko: do we need to wait for your new gcc-4.5?  I assume it'll take a while
<doko> cjwatson: no
<doko> binutils should be built however
<cjwatson> doko: did you NEW linux/powerpc?
<doko> cjwatson: yes. anything wrong?
<doko> did do the same for the other archs
<cjwatson> doko: if you could use the kernel-overrides script in future to make sure the overrides are synced up with the last ABI, that would be good
<doko> ahh, ok
<cjwatson> can fix it up after the fact, though not 'til it's finished publishing
<cjwatson> anyway, not urgent, linux-libc-dev will still be in main which is what matters for now
<doko> well, I did see that linux-libc-dev did end up in main, and that was good enough for me
<cjwatson> (the actual kernel and such has gone to universe)
<cjwatson> I guess not much depends on linux-headers any more
<cjwatson> binutils has finished building and seems to be published
<doko> ok, binutils is in the archive as well, so we can open
<cjwatson> we need to wait for linux-libc-dev/powerpc to be published
<doko> ahh, ok
<doko> another 20min
<cjwatson> ok, feel free to ask a LOSA for it, I'm off to bed :-)
<doko> will write the announce email tomorrow
<cjwatson> I can start an autosync pass tomorrow if you like
<doko> cjwatson: on #is or #soyuz?
<cjwatson> probably more likely to find somebody on #is
<cjwatson> though there's a reasonable number of sysadmins on #soyuz too
<doko> cjwatson: see #is
 * apw is glad to see that lot finally build
#ubuntu-release 2010-10-15
<wgrant> cjwatson: Natty looks open, but PPAs are not enabled. Was that step overlooked, or is it waiting on a LOSA?
<persia> There was talk about hunting a losa around the time it opened, so I'd presume the latter.
<wgrant> persia: That was probably top open Natty.
<wgrant> (since the status change still needs a LOSA, oddly)
<persia> That would have been requested about 7 hours ago, and matches, so likely, yes.
<persia> But it looked like the folk doing stuff were heading to bed around the same time, so it may just be that the process didn't get handed off to anyone in more westerly timezones, or easterly ones, and will get picked up again in a few hours when folks wake up.
<seb128> is somebody going to run an autosync run?
<seb128> or should I do it?
<seb128> cjwatson, ^
<cjwatson> seb128: I'll do it in a moment
<seb128> cjwatson, ok thanks
<cjwatson> wgrant: it's on the process page, just not done yet
<wgrant> cjwatson: OK.
<cjwatson> requested
<cjwatson> (and autosync running)
<cjwatson> mthaddon has opened PPAs for natty
<wgrant> cjwatson: Thanks.
<wgrant> cjwatson: armel needs adding to the list of PPA archs to enable on NRCP. Can I do that, or do you want to?
<cjwatson> wgrant: if you could edit NewReleaseCycleProcess and ask a LOSA for that, please do
<wgrant> cjwatson: LOSAing is in progress.
<wgrant> cjwatson: Both done. Thanks.
<cyphermox> hey, could someone please disapprove network-manager-openvpn for maverick-proposed? I messed up the LP: tag, and i think it will need some more investigation
<ScottK> cyphermox: Done.
<cyphermox> ScottK, thanks
<ScottK> You're welcome
#ubuntu-release 2010-10-17
<ikonia> test
#ubuntu-release 2011-10-10
<Daviey> My laptop takes ~4 mins to boot, but it might be a config issue..  I was going through it last week with slangasek.
<slangasek> Daviey: 870214 shows a broken /etc/network/interfaces.  What created this?
<Daviey> slangasek: I *believe* installing open-iscsi overwrites that file.
<Daviey> hmm, i'm not sure.
<Daviey> slangasek: http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-server.html#t17:13 , is all i know... looks like install time setting.
<Daviey> -> bed
<ScottK> Backlog is cleared less one package saved out for stimulating the publisher if needed.
<slangasek> cjwatson, stgraber: bug #870832 triaged, I've at least found two bugs in ubiquity-dm; will be interested to know if fixing those bugs addresses the problem
<ubot4> Launchpad bug 870832 in ubiquity (Ubuntu Precise) (and 1 other project) "Plymouth not shown during live disk shutdown. (affects: 2) (heat: 14)" [Medium,Triaged] https://launchpad.net/bugs/870832
<infinity> slangasek: I have no idea why your compressed manpages don't match.  Different versions of gzip for each build, maybe (though that seems unlikely).  Did a test rebuild in amd64/i386 chroots reproduce the problem?
<slangasek> infinity: I tested recompressing the different files with the amd64 and armel gzip, and I get output that matches the original i386 output; I'm not sure what else there could be affecting it
<slangasek> haven't done a full test rebuild... I figure I probably need to try to reproduce with all the $mangler packages if I'm going to do so
<infinity> Maybe, thought we don't mangle manpages, do we?  Unless pitti added something scary since the last time I looked. :P
<infinity> I guess my "two versions of gzip" theory is possible.  Just sees pretty unlikely.  Which package was it again?
<infinity> libpam-modules... *goes to look*
<infinity> And no gzip upgrades in either log.
<infinity> I wonder if it's time to add gzip_$version to the toolchain manifest at the beginning of builds. :P
<ScottK> So how did the Kubuntu alternates shrink 20MB all of a sudden?
<ScottK> (and can we add more language packs and respin?)
<wgrant> infinity: You could work it out from the chroot SHA1s.
<wgrant> If they differ, find when each first appeared.
<infinity> wgrant: Surely, we don't keep all the old chroots in the librarian?
<slangasek> infinity: note that neither gzip nor zlib have been updated this cycle, either
<infinity> slangasek: Yeah, I noticed that.
<infinity> slangasek: I dunno.  I'm stumped.
<slangasek> infinity: yeah; well, no-change rebuild SRU proposed now
<infinity> slangasek: Figuring out why it happened would be nice, though, since multiarch somewhat depends on various compressed files being identical.
<slangasek> right, but given that this is the first we've heard of it, it's uncommon
<slangasek> I've been running multiarch since natty and hadn't hit it
<wgrant> infinity: No, but you can work out when a chroot was created easily enough.
<wgrant> infinity: Which should be a good guide as to which version of a package it has.
<infinity> Ish.
<wgrant> Well, unless it wasn't upgraded when it was updated, in which case buildlogs will show the upgrade.
<wgrant> Very awkward and Launchpad, but doable if stuff breaks and necessitates such awfulness.
<pitti> cjwatson: auto-posting code> thanks, will look for this next time, and add to the pad
<wgrant> cjwatson: FYI the cocoplum Translations indexing deployment is going ahead at 0830, as expected.
<pitti> slangasek, skaet: right, as I wrote in the bug, the uploaded binutils looked very wrong anyway
<pitti> infinity: unless you enable pkgbinarygrammar :)
<pitti> infinity: no, it doesn't mangle manpages
<infinity> slangasek: Weird that amd64 was the only odd man out, the other 3 matched each other.
<slangasek> infinity: there were "wrong" files on each of amd64 and armel, but a different one in each case
<infinity> slangasek: Ahh, I was just looking at pam_shells.
<infinity> slangasek: That's even more disconcerting.
<slangasek> the files on i386 all matched the ones I get from zcat | gzip -9nf
<infinity> slangasek: Sort of rules out cosmic rays if armel had a different difference.
<slangasek> if it were cosmic rays, I wouldn't have expected the file to decompress cleanly
<pitti> oh, seems someone already posted the new ISOs, thanks
<pitti> slangasek: FTR, no off-hand idea about the manpage mismatch; certainly nothing the mangler touches
<slangasek> right, I wouldn't expect it to be anything the mangler is doing deliberately
<slangasek> but it's the part of the build process that I'm least familiar with, so it's where I'm casting aspersions ;)
 * pitti posts the remaining images, such as preinstalled
<pitti> done
<infinity> slangasek: This is just bizarre.
 * pitti goes through pkgbinarymangler with a fine comb, to see where it could possibly act up
<infinity> pitti: I don't see how it could possibly be involved in this.
<pitti> it matches "zip" in two places: truncating changelogs (where it re-compresses with gzip -9n)
<stgraber> slangasek: looking at bug 870832, shouldn't ubiquity-dm do an exit 1 which AFAIK should prevent lightdm/kdm from starting as ubiquity is started from a "on starting" event?
<ubot4> Launchpad bug 870832 in ubiquity (Ubuntu Precise) (and 1 other project) "Plymouth not shown during live disk shutdown. (affects: 2) (heat: 14)" [Medium,Triaged] https://launchpad.net/bugs/870832
<pitti> and compressing the _translations.tar.gz; it doesn't use -n there, but it's a hardcoded filename
<stgraber> slangasek: or doing "stop $JOB" (not sure if the exit 1 actually works with "on starting")
<pitti> the former is     dch=usr/share/doc/$PKGNAME/changelog.Debian.gz
<pitti> that can't possibly match a manpage
<pitti> hmm
<slangasek> stgraber: there's no reason that ubiquity-dm exiting 1 should prevent the dm from starting
<slangasek> moreover, the job is 'normal exit 0 1', so 1 is considered a reasonable exit status for the job anyway
<slangasek> nor does "stop kdm" help (see my comments in the bug about this hanging indefinitely...)
<stgraber> slangasek: ok, I'll have a look a bit later to add the signal handler to the code and have it wait after calling reboot rather than exit
<slangasek> stgraber: ok.  Have you seen the bug in question yourself, btw?
<slangasek> i.e., would you be able to test the fix out and confirm that it works
<slangasek> I haven't been able to get a graphical plymouth splash in a VM, myself
<infinity> slangasek: Unless there was just some underlying weirdness that day, the part where it happened on two files on two architectures in the same day is pretty high frequency.  Maybe we've just been lucky to not notice it so far?
<slangasek> infinity: how would we not notice it?  Every multiarch package has a changelog, all those changelogs have to be compressed the same to be installable
<slangasek> maybe dh_compress is somehow doing it wrong and pkgbinarymangler is doing it right, but I can't see how that would be
<pitti> let's first see whether the files now end up identical once pam is built; if it reproduces, we have at least something to look into
<infinity> slangasek: But is anyone running with every multiarch lib installed?
<slangasek> infinity: er, I am? :)
<stgraber> slangasek: nope, though maybe VirtualBox gives you a graphical plymouth, haven't tried yet. My current idea is to switch upstart into a very verbose mode and look at the log just before the actual reboot
<infinity> slangasek: dh_installman does do some utf-8 mangling on manpages, but given that the unzipped copies are identical, I fail to see how that could hurt.
<slangasek> granted, not *all*, just the relevant ones... which is about 90% of those currently in the archive
<slangasek> infinity: right
<slangasek> 95% even
<infinity> slangasek: Maybe you've been lucky to have the bug mostly hit armel and ppc, and you only have x86 installed? ;)
<infinity> I dunno.  I'm willing to believe there was just something weird going on on August 18th, but gzip being non-deterministic twice in a row is concerning.
<slangasek> $ dpkg -l '*:armel' | grep -c ^ii
<slangasek> 33
<slangasek> $
<slangasek> :P
<infinity> I guess I should shower and get ready for the commute across the river.
<slangasek> save time, swim across the river
<diwic> Hi, I believe bug 869420 should be release critical for Ubuntu Studio and that the attached debdiff should be uploaded right away
<ubot4> Launchpad bug 869420 in libffado (Ubuntu) (and 2 other projects) "jackd crashes with SIGABRT in raise() when jackd2-firewire is installed (affects: 16) (dups: 10) (heat: 128)" [High,Confirmed] https://launchpad.net/bugs/869420
<diwic> Is this the right channel to ask for such upload?
<pitti> it's just on the studio images, so doesn't invalidate the others
<pitti> diwic: you need sponsoring?
<diwic> pitti, yes I do
<pitti> uploaded
<pitti> markign studio for rebuild on the tracker
<diwic> pitti, thanks
<diwic> one more bug squashed :-)
<slangasek> stgraber: fwiw, in my own tests getting anything at all out of upstart log-wise was a challenge; maybe if I do a full install it'll work better.  Anyway, if/when you have a patch for the signal handler+reboot issue I'm happy to test
<pitti> diwic: will rebuild studio once it's published
<pitti> for release team, ^ marked so on the pad
<diwic> pitti, ok, ubuntu studio will be happy :-) I hope
<stgraber> slangasek: ok, working on that now
<skaet> hiya pitti,  why is ubuntu studio marked for rebuild?
<pitti> skaet: see a couple of lines up, bug 869420
<ubot4> Launchpad bug 869420 in libffado (Ubuntu) (and 2 other projects) "jackd crashes with SIGABRT in raise() when jackd2-firewire is installed (affects: 16) (dups: 10) (heat: 128)" [High,Fix released] https://launchpad.net/bugs/869420
<pitti> skaet: I updated the pad
<skaet> pitti,  thanks!!
<infinity> Bah, queuebot's dead?
<Laney> you set off sirens in skaet's house :-)
<infinity> pitti: Or did you just accept before the scan?
<pitti> infinity: could be; it's lagging behind for 5 or so minutes
 * infinity nods.
<pitti> I used mdebdiff on cocoplum to speed it up
<stgraber> slangasek: ok, so the wait indefinitely part is easy, adding is SIGTERM handler is quite easy too, having the SIGTERM handler do the right thing is going to make the diff a bit bigger though
<slangasek> stgraber: none of these changes are oneiric-appropriate, so I don't mind a bigger diff :)
<cjwatson> slangasek,stgraber: I have a test system I can do real-hardware installs on if that would help?
<slangasek> cjwatson: I do as well
<infinity> cjwatson: Are you still planning to come down, or have you opted against?
<cjwatson> infinity: tomorrow
<cjwatson> (to Thursday)
<infinity> Ahh.
<infinity> Kay.
<stgraber> slangasek: http://paste.ubuntu.com/705305/ is the general idea, haven't tried it though
<infinity> Hrm.
<infinity> Was https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/820028 RC, or should we get mvo to re-upload that to -proposed?
<ubot4> Launchpad bug 820028 in software-properties (Ubuntu Precise) (and 2 other projects) "software-properties-gtk crashed with UnicodeEncodeError in RemoveSource(): 'ascii' codec can't encode characters in position 99-100: ordinal not in range(128) (affects: 24) (dups: 15) (heat: 170)" [High,Fix committed]
<mvo> infinity: I'm fine uploading it to proposed too
<infinity> mvo: We'll leave it there for now.  If something else forces us to rebuild, I'll accept your upload too.
<infinity> mvo: If nothing does, I'll reject it and you can push to proposed.
<infinity> mvo: Sound good?
<mvo> sounds good, thanks
<slangasek> stgraber: maybe better to kill the server with SIGTERM first followed by server.wait(), to be sure there's no race in freeing the console?
<stgraber> slangasek: indeed
<stgraber> slangasek: http://paste.ubuntu.com/705321/
<Riddell> todays images still have the pre-beta release warning in ubiquity
<cjwatson> argh
<cjwatson> yay process
<cjwatson> ev: ^- could you fix that please?  I'm helping with archive firefighting at the moment (hence, probably not worth uploading urgently)
<stgraber> cjwatson: I'm already working on it
<ev> ah, thanks stgraber
<ev> mind you, that's just in Kubuntu
<pitti> new ubuntustudio posted with ffado bug fix
<skaet> thanks pitti
<infinity> mvo: Your update is in.
<pitti> infinity: oh, are we going to respin?
<ogra_> pitti, see above :)
<infinity> pitti: ubiquity.
<pitti> infinity, skaet, cjwatson: modified CONF.sh for OFFICIAL, too
<infinity> pitti: Danke.
<stgraber> http://paste.ubuntu.com/705341/ is the debdiff for the ubiquity that'll land in the queue in a few minutes
<skaet> pitti,  goodness.
<pitti> stgraber: thanks, looks good
<mvo> infinity: \o/
<mvo> infinity: I have another (rare) update-manager crash fix pending, but its not entirely clear to me yet what the best fix is, still working on it
<pitti> ^ grabbing for review
<pitti> building now
<pitti> will re-trigger all desktop-y images once it's built
<pitti> cjwatson, ogra_: I assume the alpha warning doesn't affect the preinstalled images?
<pitti> stgraber: ^
<pitti> i. e. only desktop/DVDs affected?
<stgraber> .disk/info still says Beta at least on Edubuntu
<pitti> stgraber: ah, right, that'd be the cdimage config change
<pitti> so we need alternates, too
<stgraber> I can't change that code (at least I don't know how), so would be great if someone could do it before we respin everything
<pitti> ogra_: do the preinstalled images have a .disk/info counterpart which needs updating to say "final"?
<pitti> stgraber: I just did it
<stgraber> pitti: ok, thanks
<cjwatson> pitti: could you commit that CONF.sh change, please?
<cjwatson> (bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd)
<cjwatson> (not the other bits that are cowboyed on antimony though)
<pitti> cjwatson: will do; there is another diff on antimony which changes the _MKISOFS options
<pitti> which I'll ignore
<pitti> right
<pitti> cjwatson: done
<pitti> I'll rebuild the alternates for now, to pick up the CONF.sh change
<infinity> pitti: No, preinstalled doesn't have any such thing.
<pitti> infinity: thanks for confirming; so not rebuilding those
<infinity> pitti: Eh?
<infinity> pitti: We can't ship them with an out-of-date package installed.
<pitti> infinity: ah, for oem-config, right
<pitti> good, marking for rebuild, too
<pitti> infinity: server armels could stay, though?
<pitti> and core
<slangasek> stgraber: confirmed that http://paste.ubuntu.com/705321/ fixes the ubiquity-dm handling of SIGTERM
<slangasek> stgraber: I still get the wrong dots-on-text though
<slangasek> as well as the problem that whatever's going on affects *all* VTs, so I can't get back to a command prompt for further debugging :P
<slangasek> (pressing Alt+F2 and having the dots follow you - annoying!)
<stgraber> slangasek: can you add an upstart script that mounts /target, dumps the process list to disk and unmount /target just before reboot?
<slangasek> stgraber: I suppose so.  I'm going to get some sleep first though :)
<stgraber> sounds like a good idea :)
<ev> There are four netbooks all with the latest daily-live on a USB stick in the corner of the room if anyone wants to do some smoke testing.
<infinity> pitti: server armel is still oem-config.
<infinity> pitti: core doesn't need rebuilding for any arch, though.
<pitti> ok, thanks
<ev> http://paste.ubuntu.com/705348/ - is what I've uncovered by smoke testing so far.  Nothing release critical though.
<ev> I'll file bugs as appropriate
<mvo> just fyi, the u-m upload is not essential, it fixes a crash in the rare case that the user has no "main" source on his/her system and u-m needs to adds it. if its rejected I would really like to get it in as a 0-day SRU
<stgraber> ev: I saw you had a machine installed in Chinese, did you try chinese input in the installer?
<ev> mm, I did not!
<ev> did that break it?
<stgraber> I'm doing another chinese test install in install-only and I can't input anything in Chinese
<stgraber> suspecting it works if you start ubiquity from live session though
<ev> Do we need ibus or something else running in the ubiquity-only session for this? I can't recall exactly how all those bits fit together.
<stgraber> yes, I think we need dbus + ibus running, I remember fixing ubiquity to use ibus if it's on, so we probably just need to tweak ubiquity-dm to start ibus
<stgraber> I'll make sure it works from live and file a bug so that we change ubiquity-dm to start ibus for P
<stgraber> and release-note for Oneiric that you need to use the live environment if you plan to enter characters that require ibus
<cjwatson> FYI BTW, the publisher is still on manual as we're firefighting i18n/Index issues
<cjwatson> so don't be too surprised about builds being slow to show u
<cjwatson> *up
<pitti> ah, good to know
<cjwatson> so I should update this channel on that and ask for feedback
<cjwatson> this morning's ftpmaster deployment was to turn on i18n/Index generation to fix bug 572128
<ubot4> Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Invalid] https://launchpad.net/bugs/572128
<cjwatson> this caused all oneiric builds to fail because the buildd chroots were running a slightly old version of apt which failed 'apt-get update' in the presence of any i18n/Index files
<cjwatson> this apt bug was fixed in 0.8.16~exp5ubuntu9
<cjwatson> unfortunately, 0.8.16~exp5ubuntu6 (which was buggy) was shipped with 11.10 beta-1
<cjwatson> this means that systems installed with beta-1 cannot be upgraded if we keep this change
<cjwatson> at least not without manual hackery
<cjwatson> if we back out this change, it means that debmirror archives don't get any long package descriptions, due to the work on moving long descriptions out of Packages and into Translation-en to reduce the bandwidth hit for multiarch
<cjwatson> so in order to fix that, we would also need to turn that feature off (which is a matter of an API request) for oneiric, and turn it back on for precise
<cjwatson> and we would furthermore need to make sure not to upload DDTP tarballs for oneiric-updates; historically we haven't done that anyway, although it does cause some problems (bug 672314)
<ubot4> Launchpad bug 672314 in apt (Ubuntu) (and 1 other project) "No translated package descriptions for -updates repository (affects: 3) (dups: 1) (heat: 9)" [Undecided,Confirmed] https://launchpad.net/bugs/672314
<infinity> cjwatson: I'm not sure that being able to upgrade beta->final from GUI tools is a huge deal, is it?
<ogra_> it will generate support
<cjwatson> historically we've promised that you can
<infinity> cjwatson: Well, wait.  Was this "broken" apt the same one that I was just using in the chroots?
<cjwatson> yup
<infinity> Cause, yeah.  It's grumpy on apt-get update, but it still works.
<infinity> It just exits non-0.
<cjwatson> oh?  what effect does that have on u-m then?
<infinity> That breaks the buildds, but that won't break update-manager.
<infinity> At least, it shouldn't.
<wgrant> Ah, here.
<infinity> Cause you still get new Packages files.
<cjwatson> mvo: ^- if you could test that, then, that would be lovely
<cjwatson> I don't care if beta-1 users get an irritating popup about apt failures before they finish upgrading; that's eminently release-notable
<infinity> If it was broken to the point where you didn't get packages files, fixing the chroots would have been much more annoying.
<infinity> But I didn't have to copy in a new apt and dpkg -i or anything, update/upgrade still worked.
<infinity> Just with a non-0 exit on update.
<infinity> Not big deal.
<infinity> s/Not/No/
<cjwatson> Hm, OK, that does sound less panic-worthy
<cjwatson> so as long as the GUI tools aren't a complete nightmare, it's tolerable
<infinity> mvo: *poke*
<mvo> infinity: *poke back*
<infinity> mvo: Okay, so, apt-get update works fine (thought exits non-0, but it does update the indexes)
<infinity> mvo: Are you concerned that u-m will do something extra broken on top of that?
<mvo> infinity: I'm not sure that it does not break stuff, it appears the "broken index protection" kicks in and it won't actually update the /var/lib/apt/lists files, not even the Packages list file, but I need to double check with a actual b1 apt
<ev> what's the typical lag time between the release and it starting to show up in update-manager? Is it roughly 1 day, given that's how often the apt-get update cron job fires?
<infinity> mvo: Well, the chroots worked.
<infinity> mvo: That's my point.
<infinity> mvo: The broken version we're all talking about just worked to upgrade 4 buildd chroots.
<infinity> mvo: The only reason the buildds didn't work automatically was because update exited non-0.
<infinity> mvo: But doing it manually, it went fine.
<cjwatson> but will python-apt-based programs raise IOError all over the show ...
<cjwatson> or aptdaemon raise TransactionFailed
<mvo> ev: it used to be about a day, but we changed it in oneiric to the same frequency as the regular updates (so 7 days)
<infinity> Even if they do, is it the end of the world to release note that people with that specific apt version from beta1 just need to "apt-get update ; apt-get install apt" from a console?
<infinity> We expect beta users to be vaguely technical.
<mvo> infinity: hm, good point
<cjwatson> That's certainly a possibility.  I'd like to know for sure though
 * mvo will test in a wee bit
<infinity> Alright.  I might go sandwich hunting.
<ev> mvo: okay, and if they hit "check" they'll see it straight away, right?
<mvo> ev: yes
<ev> thanks
<pitti> ubuntu/kubuntu/xubuntu/server alternates posted
<pitti> ^ oh, ok; ditching them again
<pitti> disabled, pad updated for update-manager build
<mvo> thnx
<pitti> skaet: FYI, I'll leave image rebuilds alone for the time being, until above apt issue was figured out, ok? /me leaves for lunch, bbl
<cjwatson> pitti: next time you need to post an image to the tracker, let me know, I'd like to test the new tool
<skaet> pitti,  ack.
<skaet> thanks
<pitti> cjwatson: ack, wanted to ask you about that at some time
<cjwatson> I'd actually forgotten to commit it until a moment ago
<mvo> infinity, cjwatson: good news, I just tested this with the b1 live-cd and while u-m complains and show a error it will display the updated apt and let me install it. after instlaling the updated apt everything works as excepted (no more error on check)
<cjwatson> oh, that is good news
<cjwatson> and b2 had the fixed version
<cjwatson> so release note and leave this turned on, then?
<mvo> I think so, yes
<mvo> essentially people just need to ignore the error message
<infinity> mvo: \o/
<cjwatson> I've filed https://bugs.launchpad.net/ubuntu-release-notes/+bug/871731
<ubot4> Launchpad bug 871731 in ubuntu-release-notes "Direct upgrades from beta-1 will produce annoying error message (affects: 1) (heat: 6)" [Undecided,New]
<cjwatson> publisher back on auto
<Riddell> stgraber: have you uploaded ubiquity 2.8.5 or am I able to get one more fix in?
<cjwatson> 11:36 -queuebot:#ubuntu-release- New package: ubiquity (main) [2.8.4 â 2.8.5]
<cjwatson> 11:40 -queuebot:#ubuntu-release- Removed package: ubiquity
<Riddell> updates it is then
 * cjwatson goes out for the better part of an hour
<pitti> skaet, infinity, cjwatson: new ubiquity and update-manager are in; shall I kick off new images, or are we waiting on something else?
<ScottK> pitti: Are you respinning alternates too?
<pitti> ScottK: yes, for update-manager and oem-config
<ScottK> pitti: I'd like to add more language packs to the Kubuntu alternate since it looks like it's got room.
<pitti> ScottK: you know langpack-size?
<infinity> pitti: Go for it.  I was just about to, but I'm happy to have you drive.
<ScottK> pitti: I usually guess ~5MB per.
<infinity> pitti: Well, once ScottK's done fiddling. :)
<ScottK> pitti: If I get it wrong, it's not like respinning an alternate takes long ...
<pitti> cjwatson: ah, or do you want to set off new builds with trying your new auto-tracker-posting magic?
<pitti> infinity: if you guys at the sprint want to drive this, fine for me (might be easier for coordination)
<pitti> ScottK: http://paste.ubuntu.com/705403/
<pitti> ScottK: you want the "K" column
<ScottK> Thanks.
<ScottK> Let me double check then.
<pitti> infinity: ah, cjwatson is still out, I figure
<infinity> pitti: No, no.  Be my guest.
<infinity> pitti: I'm chasing all sorts of things here.
<ScottK> pt is huge.
<pitti> infinity: alrighty; he said "when you post", so I guess this can build already
<ScottK> Let me back one off.
<pitti> ScottK: http://paste.ubuntu.com/705404/ <- complete list
<pitti> desktop/preinstalled running
<pitti> waiting for ScottK's signal to kick off alternates
<ScottK> pitti: Pushed the seed change in bzr.
<pitti> thanks; alternates builds started
<Riddell> ug, kubuntu/daily/20111010.1 oversized
 * ScottK looks
<pitti> ScottK: ^ seems one too much?
<ScottK> Yeah.  Just on i386 though.
 * ScottK fiddles
<cjwatson> pitti: just tell me when you're ready to post it and I'll try posting manually
<pitti> cjwatson: ah, back
<pitti> cjwatson: ubuntu alternate is ready to post
<ScottK> pitti: Fixed.
<pitti> cjwatson: the kubuntu one will be rebuilt, so if you can control this, please don't post that one yet
<cjwatson> ok, let me have a go
<cjwatson> ... oh, I need to set cdimage up as an admin, one moment
<stgraber> cjwatson: on the tracker? do you have access to Drupal's admin interface?
<cjwatson> stgraber: could you make ubuntu-cdimage an admin?
<cjwatson> I just created that account
<stgraber> cjwatson: done
<cjwatson> rock on.  set up
<pitti> cjwatson: xubuntu alternate, core, server preinstalled are now also waiting for posting, for the record (in case you want to check with output of your magic script)_
<cjwatson> $ post-qa 20111010.1 ubuntu/daily/oneiric-alternate-amd64+mac ubuntu/daily/oneiric-alternate-amd64 ubuntu/daily/oneiric-alternate-i386 ubuntu/daily/oneiric-alternate-powerpc
<cjwatson> worked
<cjwatson> I'll try the others
<cjwatson> that's only for if you need to post an image semi-manually; normally, 'CDIMAGE_POST_QA=1 for-project ubuntu cron.daily' etc. should just work
<cjwatson> I wonder if it will work after I log out in my browser
<pitti> ah, nice, will remember for teh next time
<cjwatson> apparently not ...
<cjwatson> (so don't use it yet, still working on this)
<pitti> cjwatson: added to the pad, with the "being tested" caveat
<pitti> I need to disappear for a bit, back later
<pitti> can someone post the images as they come in in the meantime?
<cjwatson> oops, misversioned ubuntu-core
<cjwatson> (fixed)
<cjwatson> pitti: server preinstalled dates from 20111009 - is that really waiting for posting?
<cjwatson> I've done the others
<pitti> cjwatson: ah, no; I guess the cron.daily-preinstalled is still running then, sorry
 * ogra_ thought there was a respin in progress
<ogra_> its 90min per image for the rootfs plus about 1h for the post processing for all images
<ogra_> (or 45min for the latter)
<cjwatson> looks like it's still in progress, yes
 * ScottK is reviewing ^^^
<ScottK> Kubuntu alternates are up and they fit now.
<ScottK> cjwatson: Could you post them to the tracker?
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<pitti> re
<pitti> cjwatson: do you want to publish the new images with your script for testing, or want me to?
<pitti> trying post-qa with server
<pitti> $ post-qa post-qa 20111010.1 ubuntu-server/daily/oneiric-server-amd64
<pitti> No iso.qa.ubuntu.com product found for 20111010.1; skipping.
<pitti> cjwatson: ^ apparently not the right incantation?
<pitti> erk, ignore me please
<pitti> cjwatson: studio and server i386/amd64 posted, but this fails:
<pitti> $ post-qa 20111010.1 ubuntu-server/daily/oneiric-server-amd64+mac
<pitti> KeyError: "Product 'Ubuntu Server amd64+mac' not found"
<ev> I have a ubiquity upload that I'm going to shove in the queue as soon as pbuilder finishes.  It mainly fixes bug 838048, which will only occur if you've disabled wireless and selected the "connect to this network" radio button on the wireless page.  I leave it to you lot to decide if that's sufficiently high priority to warrant a respin. :)
<ubot4> Launchpad bug 838048 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in __new__(): object of type 'NoneType' has no len() (affects: 8) (dups: 6) (heat: 62)" [High,Fix committed] https://launchpad.net/bugs/838048
<pitti> ah, we build them, but don't have amd64+mac in the tracker, I see
<stgraber> skaet: Edubuntu OEM install doesn't work because of one of my ubiquity plugins. I'm testing a fix now and I'll upload a new edubuntu-live fixing it. I'll want a respin of Edubuntu for that if possible (package is only shipped on Edubuntu)
<pitti> cjwatson: posted all pending images using post-qa, working fine
<cjwatson> pitti: I think everything we build ought to have a corresponding tracker product, and maybe this will help us discover omissions :-)
<cjwatson> we've had a few rather ridiculous conversations of the form "this image hasn't been tested" "but it isn't even in the tracker, so how can we expect it to be"
<ScottK> Riddell, IIRC had something he wanted to get into Ubiquity KDE.
<ScottK> ev: Do you know if Riddell committed anything for ubiquity-kde?
<ev> probably removal of the alpha warning
<ev> which stgraber took care of
<ScottK> OK.  Great.
<ScottK> He's not online now and he didn't say.  Thanks.
<pitti> ev: I don't think that was it
<ev> ah, fair enough
<ScottK> I just emailed him.
<stgraber> pushed a fix for the Edubuntu OEM bug. edubuntu-live should hit the queue soonish
<stgraber> debdiff: http://paste.ubuntu.com/705501/
<stgraber> pitti, skaet: would be great if this could go in and then rebuild Edubuntu ^
<pitti> so I guess I shouldn't bother posting the ones that are currently built then?
<stgraber> indeed
<pitti> now we need to rebuild all images for ubiquity, so that's no small cost
<ScottK> I have a report of crashes in language-selector-kde, which would affect all Kubuntu images and Edubuntu.
<ScottK> Details when I have them.
<pitti> stgraber: edubuntu-live accepted
<ScottK> "it crashes on startup all the time" <-- language-selector-kde
<ScottK> Bug being filed.
<ScottK> "* LanguageSelector/LangCache.py [change not affecting KDE]" was apparently wrong.
<pitti> ScottK: I had some serious trouble testing that; I tried beta-2 Kubuntu CD, and couldn't figure out for the life of it how language-selector was integrated
<pitti> so, test case appreciated
<ScottK> I have someoene working on both the bug and a fix.
<pitti> all images marked for rebuild in tracker for ubiquity/edubuntu-live/language-selector issue
<pitti> pad updated
<debfx> pitti: language-selector-kde is in System Settings -> Locale -> System Languages
<tseliot> can anybody approve my packages, please? As discussed with slangasek, I uploaded "nvidia-graphics-drivers" and "fglrx-installer" in oneiric-proposed (since they are on some dvd images) while the other packages "nvidia-graphics-drivers-updates", "nvidia-graphics-drivers-173", "nvidia-graphics-drivers-173-updates", "nvidia-graphics-drivers-96", "nvidia-graphics-drivers-96-updates" and  "fglrx-installer-updates" sho
 * skaet --> dinner, back on later
 * ev is going for a run. Will have my cell phone on me, but I forgot my armband so it'll be tucked away in my backpack.  Call if the installer catches fire and hopefully I'll hear it
<pitti> debfx, ScottK: I have a fix, is there a bug # for this?
<pitti> ah, got it
<pitti> ScottK: seems the London crowd is at dinner, maybe you can review?
<pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/revision/529 is the diff in bzr
<ScottK> Should be able to shortly.
<pitti> tested on both current Kubuntu CD and under GNOME
<ScottK> pitti: Accepted.
<doko> pitti, ScottK: I'll upload a gcc-snapshot package soonish (then building on armel too). this should be build overnight, so won't block the buildds, and should finish to build on armel even before Thu
<ScottK> doko: How long does it take?
<doko> ScottK, what?
<ScottK> We want 24 hours for mirrors after the last build finishes.
<pitti> https://launchpad.net/ubuntu/+source/gcc-snapshot/20110813-1ubuntu1/+build/2683651
<pitti> that was the last version that built, 3.5 days on armel
<pitti> which would be past release
<pitti> doko: can you upload to -proposed?
<doko> pitti, that's a build on a babbage ...
<pitti> the current ones are panda boards now; any idea how much faster they are?
<pitti> but still, if you upload to proposed, and it builds in time, we can copy it to final
<pitti> if it fails or takes too long, we copy to -updates
<pitti> would that work?
<doko> pitti: https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+build/2833269
<pitti> for you, I mean (it technically works fine on LP)
<doko> ok
<pitti> ah, so around a day, that'll still fit
<pitti> nice speedup :)
<pitti> doko: shouldn't be a problem to accept it right now, we have plenty of buildds at our disposal
<ScottK> No guarantee it lands on a panda is there?
<pitti> I think the non-panda ones are all on manual
<ScottK> Ah.
<pitti> but anyway, that's why I proposed -proposed
<doko> have to wait for my test build
<pitti> cjwatson, infinity: in about 10 minutes we should have ubiquity/language-selector/edubuntu-live on antimony; I prepared the commands to kick off new image builds, with CDIMAGE_POST_QA=1
<pitti> anything else we need to wait for which is on your radar?
<iulian> pitti: What's in London by the way?
<doko> rain
<charlie-tca> Is the tracker not updating, or is my firefox buggy now? I show very few images ready for testing.
<iulian> doko: It doesn't rain, no.
<ScottK> charlie-tca: Very few are ready for testing.
<charlie-tca> Okay, Then it looks right
<pitti> charlie-tca: I'm about to kick off new builds, see the etherpad
<cjwatson> iulian: release sprint
<pitti> anonftpsync done, antimony ready to go
<cjwatson> not the whole release team but a fair subset
<iulian> cjwatson: Oh blimey. Didn't know that. Was it announced somewhere?
<cjwatson> I don't think so, we've been doing it since dapper though
<iulian> When are you guys leaving?
<pitti> cjwatson: do you have anything else on your radar which is a blocker for new images?
<cjwatson> it's been a Canonical event so far although actually I don't see a particular reason we couldn't open it up if non-C people were interested
<cjwatson> we'll be here until at least Thursday
<cjwatson> I suppose I should ask the office people first, but if you want to pop round to Millbank at some point I'm sure something could be arranged :)
<cjwatson> pitti: not so far, though I've been offline for a couple of hours
<cjwatson> and am about to crash in preparation for getting up at ohgod tomorrow
<pitti> well, I'm sure that as soon as I press enter someone will ping with another bug :)
<pitti> anyway, pressing the three enter keys of doom
<pitti> and with that, good night everyone!
<pitti> should be back at my usual early time tomorrow morning to mop up the fallout (crossing fingers..)
<pitti> cjwatson: save travels!
<pitti> let's see how well this auto-posting works; but Colin wrote it, so it must be perfect!
 * pitti &
<iulian> cjwatson: Nice. I couldn't probably pop in for a bit. It's just a 20 minutes bus journey from uni to Millbank.
<iulian> s/couldn't/could
<cjwatson> pitti: *cough*
<cjwatson> iulian: we'll definitely need to make sure somebody warns building security in advance, though; they can be pretty strict
<cjwatson> I'll ask when I get in tomorrow
<iulian> cjwatson: Heh. I know that.
<Laney> But nothing bad could possibly happen at Millbank Tower!
 * Laney coughs
<iulian> cjwatson: We could always grab a drink after, if you and everyone else around is up to.
<cjwatson> that is *definitely* an option
<cjwatson> and there's the release party on Thursday
<cjwatson> (which was on ubuntu-uk I think)
<iulian> cjwatson: There's a pub 3-5 minutes away from Millbank, forgot its name. I'm sure you know it.
 * popey perks up
<cjwatson> the Morpeth
<iulian> cjwatson: Yea, that's it.
<popey> http://loco.ubuntu.com/events/ubuntu-uk/1283/detail/
 * popey coughs
<cjwatson> or there's the boat across the road from the Park Plaza (across the river from Millbank) which is also a standard haunt
<cjwatson> popey: oh good, nice and close by this time :)
<popey> cjwatson: i had to check the map to see if that was sarcasm or not âº
<popey> cjwatson: say hello if you come and I'll happily spring you a beer.
<popey> Gosh, I suddenly came over all american.
<elmo> gosh, darn it, jolly happenstance, what ho
<popey> Pip pip!
<cjwatson> rather
<infinity> Cheerio?
<tumbleweed> Laney: ^ I sponsored it. Your turn now.
<Laney> I already looked at the debdiff
<Laney> so yes, ack. ScottK: looks good ^^^
<ScottK> OK
<ScottK> Laney and tumbleweed: Accepted.
<Laney> ta
<Laney> think we pleased that chap
<tumbleweed> heh
<doko> pitti, ScottK: gcc-snapshot uploaded to -proposed, as discussed
<ScottK> doko: Accepted.
#ubuntu-release 2011-10-11
<GrueMaster> No one minding the store?  Still looking for armel desktop images.  ETA?
<pitti> Good morning
<pitti> nice, seems the auto-posting worked? except for ubuntu desktop
<ScottK> Meh.  Details.
<ScottK> How many people care about that one?
<ScottK> ;-)
<pitti> GrueMaster: should be there now
<pitti> post-qa 20111010.1 ubuntu/daily-live/oneiric-desktop-{i386,amd64,amd64+mac}
<pitti> for some reason that doesn't error out, but doesn't do anything
<pitti> posted manually
<pitti> erm, what? adding in the UI doesn't work either
<pitti> stgraber: help
<pitti> I reenabled the images, but they have a wrong version (10, not 10.1)
<micahg> I assume a seamonkey upload tonight is still fine in a few hours? (yes, I know it's close)
<slangasek> micahg: since it's in universe, yes
<slangasek> (and since we're still before the "1.5 days before release" cutoff for unseeded)
<micahg> hopefully for P it will be actively maintained
<cjwatson> gah
 * cjwatson misses the bus and furthermore does not have the correct change.  I may be a bit late to the office today
 * slangasek listens to a transformer explode in the distance
 * skaet will save a seat for cjwatson in the room
<cjwatson> ... mind you this taxi driver has made me want to take my glasses off, so maybe I won't be that late
<skaet> :)
<pitti> good morning
<pitti> .. cjwatson
<pitti> cjwatson: so you are back home?
<skaet> pitti, hiya,  I believe cjwatson's on his way into Millbank right now.
 * skaet --> breakfast, biab
<stgraber> pitti: good morning
<stgraber> pitti: so what needs changing on the tracker?
<stgraber>  6907 |         202 |        26 |  29315 | 20111010    | 2011-10-10 16:59:44 |      0 |                8 6904 |         202 |        26 |  29315 | 20111010.1  | 2011-10-10 16:59:16 |      3 |               10
<stgraber> hmm, that didn't copy/paste well
<stgraber> basically the DB shows that Ubuntu Desktop i386 has been updated twice within 30s, once for 20111010 and once for 20111010.1
<pitti> stgraber: the ubuntu deskto images ought to be 20111010.1
<pitti> stgraber: but neither with post-qa nor with the web UI I'm able to change it
<stgraber> yeah, that's because 20111010.1 is already in the DB
<stgraber> post-qa apparently posted it 30s before posting 20111010 over it
<pitti> strange
<pitti> stgraber: so this needs some DB hacking?
<stgraber> yes, I'm on it
<stgraber> ok, should be good now
<pitti> stgraber: thanks
<pitti> apparently thaht killed the existing results, but that's no biggie
 * pitti re-posts his results
<stgraber> ok, breakfast time, then running to Millbank
 * skaet heading in to millbank.
<stgraber> well, so much for breakfast, didn't feel like waiting half an hour to get in ;)
<cjwatson> stgraber: hm, that wasn't me as it happens, but maybe somebody else ran it by hand; the timestamps are such that I don't think those were automatic runs
<cjwatson> maybe at some point I'll refactor the interface to make it more robust
<jamespage> morning all
<jamespage> apologies for the late-ish upload of jenkins - I've been testing the fix locally for the last few days to make sure it was good
<jamespage> if it could be accepted much appreciated
<pitti> jamespage: that doesn't seem to be on the server image, is it?
<infinity> No.
<infinity> Server builds from main, so it can't be.
<jamespage> no - its in universe
<infinity> jamespage: Accepted.
<jamespage> infinity, thanks
<infinity> slangasek: Does that initramfs-tools upload fix my garbled plymouth?
 * infinity might test in a bit.
 * pitti reserves ross for ^
<pitti> slangasek, cjwatson: above ubiquity fixes bug 872119, which isn't a showstopper, but a bit of a wart
<ubot4> Launchpad bug 872119 in ubiquity (Ubuntu) ""Error occurred while copying the network settings" on bcmwl machine (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/872119
<pitti> skaet: ^
<cjwatson> yep, saw
<pitti> what's your feeling, is that worth a respin?
<pitti> (it's not limited to bcmwl)
<cjwatson> accepted
<cjwatson> yes it is
<cjwatson> I mean yes it is worth it; I'll take care of it
<pitti> ok
<pitti> you'll drive the rebuilds?
<cjwatson> yep
<stgraber> edubuntu-live should appear very soon including the exact same fix (that code was copy/pasted between the two)
<cjwatson> in between fighting with libdevel-bt-perl
<cjwatson> stgraber: already looking :)
<cjwatson> accepted
<pitti> made ubiquity/powerpc build jump the line all the way to the front, should start in a few mins
<infinity> slangasek: That initramfs-tools did nothing for my corrupt plymouth.  But I might fiddle with that idea a bit later.
<ogra_> i assume there will be another rebuild for the new ubiquity ?
<ogra_> oh, i should read backlog and not only -changes mails :P
<infinity> ogra_: Ideally, yes. ;)
<micahg> I hate to upload seamonkey like this, but I want to call it a night and the package works, also, it's not really any worse than it was before in terms of lintian unhappiness
<infinity> micahg: "Not any worse" is a ringing endorsement.
<micahg> it's pretty bad, the last 2 cycles, I've uploaded at the last minute, so not much cleanup has happened...now we hopefully have someone to care for it
<cjwatson> I can't make libdevel-bt-perl work on current kernels.  Although it's built on amd64/armel/i386, that's only because those buildds are on old kernels.  Does anyone object if I remove the binaries on all architectures?
<pitti> zero rdepends, sounds fine to me
<cjwatson> g
<cjwatson> (ops)
<cjwatson> to clarify, I can make it work, just not reliably :-/
<cjwatson> I think I have some async-signal-safety bug somewhere - it sporadically hangs
<micahg> can I get someone to reject the seamonkey upload?
<pitti> micahg: sure, doing
<micahg> ok, seamonkey issue was a false alarm, would it be possible to have it reviewed and unrejected/accepted?
<pitti> ugh, 58 MB diff, reviewing that won't make too much sense..
<pitti> I'll have a look at the debian/ parts
<micahg> pitti: thanks, for upstream, we have the exception anyways
<chrisccoulson> micahg, does seamonkey build with the official branding? the channel is set to "nightly" in the packaging still
<chrisccoulson> which should switch off official branding
<micahg> chrisccoulson: yes, I don't think seamonkey has unofficial branding
<chrisccoulson> are we also not creating translations for seamonkey?
<micahg> chrisccoulson: it's broke ATM and I wasn't going to spend time on it right now (not a regression)
<chrisccoulson> what's broken about it?
<micahg> chrisccoulson: let's go back to -mozillateam
<micahg> pitti: too late to leave rejected?, we're going to try one more time to get the locales to build if that's ok?
<pitti> micahg: already accepted, sorry
<micahg> pitti: ok, well, would you mind a second upload enabling translations then?
<pitti> micahg: fine for me
<Laney> ^ both of those should be ok (pitti acked the exceptions), please accept
<Laney> review debian/ if you like
<cjwatson> respins in progress
<cjwatson> ... and started the preinstalled respins too, which I forgot
<cjwatson> (but I forgot to set CDIMAGE_POST_QA=1 for those so I'll have to do it manually)
<ogra_> thanks :)
<tumbleweed> anyone on the server team seen https://code.launchpad.net/~gandelman-a/ubuntu/oneiric/cobbler/lp850880-850866/+merge/78904
<ScottK> Aren't we past the 1.5 day mark now?
<ScottK> Doesn't seem that's a showstopper.
<pitti> oh, are we? will we release Thu morning?
 * tumbleweed assumed evening too
<Laney> "unseeded universe
<Laney> final freeze will be on Oct. 11 at 1200 UTC. "
<Laney> from the mail
<pitti> ah, thanks
<pitti> we can't build anythign on powerpc right now anyway, unless we ask IS to kill the gcc-snapshot build (in an emergency)
<Laney> think we want to squeeze in one more universe upload
<Laney> then it will be done
<micahg> pitti: seamonkey is killable...but it should be done soonish (30 min-1hr)
<pitti> but seamonkey is release and also builds long, it must finish by tomorrow
<micahg> ah, true
<tumbleweed> ~4 hours left on gcc-snapshot going by the last build
<pitti> gcc shouldn't build for that long any more, though
<pitti> so if we want fwts (can't hurt to have it), we could get it this evening
<Laney> fwts and guichan, that'll be it
<Laney> oh, I can't change the topic. Wanted to add the Unseeded Universe Final Freeze in there.
<Laney> ^ looks good after some heavy filtering
<slangasek> infinity: why is your plymouth garbled?  I don't see a bug report from you :)
<infinity> slangasek: I'm not sure why mine is, and I don't care deeply right now.
<infinity> slangasek: However, people using binary nvidia drivers (not me) seem to have an option between either "no X" or "no consoles".
<infinity> slangasek: Daviey and davidm both have this issue.
<slangasek> infinity: as of when?
<infinity> Not sure.  davidm only upgraded today.
<infinity> And Daviey's had no consoles "for a long time" and never reported it.
<infinity> Special, no>
<infinity> slangasek: Basically, vesafb conflicts with nvidia, so the default failure mode is no X.  If you blacklist vesafb, you get X, but no consoles.  I'm trying to sort out a magical combination that might get both.
<slangasek> infinity: I have tested vesafb+nvidia here and saw no conflicts; and support for the vesafb fallback was landed back in natty
<slangasek> so I need an actual bug report to go on
<infinity> slangasek: I can file a bug on their behalf.  I'm not sure how that's more informative than the above. ;)
<infinity> I'm also not entirely sure who or what to blame.
<infinity> (ie: where to file)
<slangasek> no, make them file it with ubuntu-bug so we get useful hardware info
<slangasek> I don't want proxy bugs :P
<slangasek> they can file it on plymouth, that's what everybody else does ;)
<infinity> I will encourage such bug filings in a few minutes when I give up trying to sort out how to hackishly fix davidm's consoles.
<slangasek> infinity: do the affected systems have cryptsetup installed?
<infinity> slangasek: Yes, in davidm's case.  Not sure about Daviey.
<slangasek> ok
<infinity> Damnit, same breakage with uvesafb.  Consoles, but X doesn't start.
<slangasek> does cryptsetup need to prompt for a passphrase in the initramfs?
<slangasek> testing with FRAMEBUFFER=n forced could be illuminating
<infinity> No encrypted root here no.
<slangasek> right, so FRAMEBUFFER=n could be safe to test
<slangasek> (overriding cryptsetup's setting)
<infinity> slangasek: Forcing FB=no is most easily done with a snippet in conf.d still?
<slangasek> yes
<infinity> slangasek: FB=n gets me no consoles and a working X.
<slangasek> heh
<infinity> slangasek: Which sort of makes sense, since that's about the same as blacklisting vesafb.
<slangasek> no it isn't?
<slangasek> it just means vesafb is loaded at the end of boot (/etc/init/udev-fallback-graphics.conf), not from the initramfs (which would put it before nvidia module load)
<slangasek> https://wiki.ubuntu.com/BootGraphicsArchitecture btw, if you haven't seen it yet
<infinity> But udev skips modprobe blacklists, right?
<infinity> I vaguely recall that it did.
<infinity> Maybe not.
<slangasek> so you have vesafb explicitly blacklisted somewhere?
<slangasek> yes, udev skips modprobe blacklists
<infinity> Yeah.  I can undo that, but that tends to not end well. ;)
<slangasek> oh?  you've tested this scenario already (nvidia loaded before vesafb)?
<infinity> Well, re-testing now with the blacklist removed, though if you claim udev will load it regardless, this should be the same as the last boot.
<infinity> Oh, no.  This got me no X.
<infinity> I'm unconvinced the FRAMEBUFFER=n did anything.
<slangasek> well.  is there framebuffer stuff in the initramfs?
<infinity> Yeah.
<infinity> Possibly because I can't spell FRAME.
<slangasek> FWAMEBUFFAW
<ogra_> heh
<infinity> Well, no, even spelling it correctly, the initrd contains fb stuff.  But, wait, why wouldn't it?
<infinity> cryptsetup will still pull it in, even if it's not going to get loaded, surely?
<slangasek> you're meant to put the FRAMEBUFFER=n somewhere that it overrides the cryptsetup hook... I thought conf.d was late enough, maybe not
<infinity> Right, with correctly-spelled FRAMEBUFFER=n, I still get consoles and no X.
<slangasek> just mangle the cryptsetup hook to unset it and call it good
<infinity> And that gets me X and no consoles. ;)
<infinity> slangasek: dmesg confirms nvidia loading before vesafb, and fb0 being initialised, but no actual consoles displaying.
<infinity> slangasek: (and if the load order is the other way, consoles work, but X dies on init)
<slangasek> fb0 initialized - how about fbcon?
<infinity> slangasek: Nothing prefaced with fbcon.  Just "Console: switching to colour frambuffer device 160x50" (which seems sane, but...)
 * infinity scratches his head.
<infinity> There's no fbcon modules anymore?
<infinity> Built-in?
<infinity> I guess.
<slangasek> built in, yes - but does it show up in dmesg?
<ogra_> for boot speed iirc
<infinity> slangasek: Nein.
<slangasek> [    2.120016] fbcon: inteldrmfb (fb0) is primary device
<slangasek> that's the kind of thing you should get
<slangasek> what's /proc/cmdline?
<infinity> slangasek: Yeah, I get that on my nouveau drm system too.  No such luck on this vesafb boot.
<infinity> cmdline is root=foo ro i8042.nopnp quiet splash vt.handoff=7
 * infinity wonders what that i8042 thing is all about.
<slangasek> well, the 'switching to colour frame buffer' should also be decisive
<infinity> You'd think.
<infinity> I wonder if it may have something to do with missing VBE modes.
<slangasek> does grub come up graphically?
<infinity> It's giving me a 1280x800 vesafb, then we switch to a 1920x1080 mode for X.
<slangasek> hmm
<infinity> And vbeinfo from grub doesn't list the 1920x1080, plus I can't force it.
<infinity> So, it's really not there.
<infinity> I can force grub to 1280x800 (tested that), but it's coming up 640x400 (or whatever) by default.
<slangasek> ok
<charlie-tca> Could we have a little more communication for those of us not at the sprint please. Trying to grab images, test them. and keep hoping that another respin is not in progress is getting really difficult
<skaet> charlie-tca,  fair point.
<slangasek> respins appear to have been mentioned above on the channel - did they not get marked for respin in a timely manner on the tracker?
<skaet> Right now what's happening is we're finishing off the last builds.   Last night's builds to fix for OEM caused regressions.
<skaet> jibel,  please post in this channel any of the potential blockers bugs so that others know what we're investigating.
<charlie-tca> They got marked as being done, and they got marked as finished. We used to get told the images were being rebuilt and were ready, too. Now it is watch the ISO tracker or the server to see when they finished.
<charlie-tca> and the tracker doesn't always get updated to match the image server
<charlie-tca> Scrolling here and in #ubuntu-testing, I see nothing says Xubuntu got finished, or even were being respun. I found it looking at the tracker.
<skaet> charlie-tca,  we've been working on getting it automated, so it no longer needs to be a manual step (ie. wait for someone to notice).
<charlie-tca> skaet: when I am running tests, to find when entering stuff on the tracker that the images are being rebuilt, means I wasted a couple of hours, again.
<skaet> There were some issues with it that got debugged this morning.   Are any of the images up there right now not matching what's on the server.
<skaet> charlie-tca.  Your point is valid.  We should have been more verbose on this part as we were transitioning.
<slangasek> charlie-tca: are you not subscribed to the xubuntu test cases in the ISO tracker?  That's supposed to result in an email notification whenever a new image is available
<slangasek> now, I don't think that notifies that an image is down for respinning, mind
<charlie-tca> Yes, I am subscribed, and I get the emails, but there again, it is an instant notification process.
<charlie-tca> I synced last nite here, burned cd-r's as 9pm, got up at 6am, and and 7am find we are respinning images. it is now 9:20am, and I have two hours of syncing images, before I can even begin to test them
<pitti> eek, buildds are being kernel-ppa-ed
<pitti> I was hoping we could get in fwts
<infinity> fwts?
<pitti> in the queue
<infinity> pitti: It's universe anyway, does it matter if the builds don't happen immediately?
<pitti> infinity: no, just if they don't happen until tomorrow
<infinity> They will.
<pitti> I wouldn't like to release with an out of date pacakge
<pitti> we can score it up, of course, so that it builds after the next set of kernels
<infinity> Exactly.
<stgraber> charlie-tca: well, I'm in the room and I didn't know xubuntu finished building ;)
<charlie-tca> Hm, maybe you people ain't really getting the word either.
<stgraber> well, it's all automated now, so nobody has to add them to the tracker which means nobody knows they're done building unless they're subscribed to them or look on the tracker
<GrueMaster> stgraber: I haven't been getting notifications either, and afaik, I am subscribed (or I was).
<GrueMaster> Going through and resubscribing now.
<charlie-tca> I will say the way the tracker notifies now is really nice. It sends out an email for each item on the tracker, as they become available.
<charlie-tca> No more waiting to see both arches are ready
<stgraber> that's because cjwatson's script post them as they're done building, instead of having one of the ISO tracker admin check periodically and post them in batch
<pitti> good night everyone
<skaet> thanks pitti,  good night.
<charlie-tca> I do see notification as a "good thing" :)
 * GrueMaster twiddles thumbs while waiting for yar (yet another rebuild) to finish.
<slangasek> stgraber: did you see the open-isci bug I've assigned you?
<slangasek> stgraber: nevermind ;)
<GrueMaster> Rebuilds failed on arm (or at least that was the email I just got).
<ogra_> Generating MD5Sums of the images
<ogra_> /usr/bin/md5sum: write error: No space left on device
<ogra_> /usr/bin/sha1sum: write error: No space left on device
<ogra_> who drives antimony atm ?
<ogra_> seems we need some disk space cleanup
 * ogra_ has access but doesnt feel like randomly deleting images there
<jibel> skaet, bug 870214 -> release notes
<ubot4> Launchpad bug 870214 in open-iscsi (Ubuntu Oneiric) (and 2 other projects) "iSCSI root installation creates manual eth0 configuration + long boot (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/870214
<skaet> thanks jibel.
<ogra_> skaet, see above ... thats critical i guess
<ogra_> antimony ran out of space
<skaet> ogra_
<skaet> ack,  looking at it.
<cjwatson> I already have a ticket filed with IS
<cjwatson> they need to actually do it
<ogra_> (and armel will need a cron.daily-preinstalled run afterwards)
<cjwatson> I will go and kick them
<cjwatson> done some temporary mitigation of the space problems, rest is with IS
<cjwatson> only one image failed due to that, which I'm rebuilding
<cjwatson> two other problems which I can look at latere
<cjwatson> *later
<ogra_> thanks !
<ogra_> GrueMaster, should all be in order again in a few
<GrueMaster> sigh.
<ogra_> ??
 * GrueMaster re-enters holding pattern...again.
<ogra_> you can test everything already but omap4
<cjwatson> oh and TBH I think I've been about as communicative here as I would have been while at home; I did mention doing respins
<cjwatson> would it be better if I didn't rebuild your image? :P
 * ogra_ hugs cjwatson 
<GrueMaster> Well, actually since I had already downloaded and tested them prior to the respin...
<ogra_> GrueMaster, omap4 should be ready in a few mins as well, since it only needs the post-processing bit again
<GrueMaster> But I understand the need to get fixes in to final.
<cjwatson> ogra_: yep, and that's all I'm running
 * ogra_ thought so
<cjwatson> it'll be at least half an hour until kubuntu preinstalled comes out, probably a bit more
<utlemming> skaet: can we add http://uec-images.ubuntu.com/oneiric/20111011/ to the tracker for the Ubuntu Cloud images?
<cjwatson> unfortunately I forgot to export the magic variable in that shell so I'll have to post it by hand
 * ogra_ isnt sure who tests kubuntu preinstalled 
<ogra_> i guess thats scott
<skaet> ScottK,  ^^ kubuntu preinstalled.
<chrisccoulson> is it too late to do a removal from universe?
<skaet> utlemming,  trying now.
<chrisccoulson> i'd really like to get rid of webfav
<ogra_> or GrueMaster proxying him in his spare time :) not sure
<GrueMaster> ogra_: I usually end up testing it.  No one on kubuntu has omap/omap4 hw (they all have Efika systems).
<ogra_> GrueMaster, which doesnt help at all sadly
 * ogra_ hopes we'll get mx5 images that can actually run on efikas too next round
 * GrueMaster refrains from comment.
<infinity> I'd like to find the time to do that.
<infinity> But...
<infinity> It may end up being another subarch if I can't figure out a cleverly hackish way to unify them.
<infinity> And ew.
<ogra_> infinity, no, please dont, we have enough images :)
<infinity> Exactly.
<ogra_> i was expecting linaro to provide us better bits and pieces to make that work actually
<ogra_> with a single image
<infinity> A unified uBoot?  Good luck with that.
<infinity> There are 4 builds for mx53 alone.
<ogra_> a unified u-boot for one arch, yeah
<cjwatson> chrisccoulson: it should still be possible
<cjwatson> chrisccoulson: file a bug and subscribe ubuntu-archive, I (or somebody) will process the removal queue tomorrow morning
<chrisccoulson> cjwatson, thanks. i'll do that now
<infinity> I'm somebody!
 * infinity feels special.
<cjwatson> yay
<skaet> utlemming, I'm running into a script error.   Will figure it out when I get back from dinner.
<charlie-tca> I apologize for earlier ranting. I am aware the perceived lack of communication has nothing to do with the sprint.
<utlemming> skaet: np, enjoy dinner :)
<skaet> charlie-tca,  more communication should have been happening though.
<skaet> will try.  :)
<skaet> Team here in Milbank is breaking for dinner right now,  all images except a couple of the arm ones are posted on the iso tracker, and no rebuilds anticipated.
<ogra_> you should put some mics and a voice recognition SW up in the rooms and make it paste here :P
<skaet> ogra_,  it would mostly be picking up typing actually.  :)
<ogra_> heh, yeah
<cjwatson> I may not be able to post kubuntu preinstalled in a timely fashion; if it succeeds I would appreciate somebody posting it
<slangasek> cjwatson: eta?
<charlie-tca> um, let's see if I can get me in more trouble now.
<charlie-tca> bug 872374
<ubot4> Launchpad bug 872374 in onboard (Ubuntu) "Feature Freeze exception request: new version with GI, gsettings,... (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/872374
<charlie-tca> Probably too late, maybe advise for a SRU?
<ogra_> slangasek, <cjwatson> it'll be at least half an hour until kubuntu preinstalled comes out, probably a bit more
<ogra_> that was at 15 past the hour
<slangasek> mmk
<slangasek> kubuntu preinstalled built; publishing
<ogra_> GrueMaster, ^^
<GrueMaster> Yep, pulling all desktop images now.
<SpamapS> Can we still add things to the release notes?
<ScottK> Is it on purpose that software-properties was uploaded to updates and not proposed?
<kees> I have a confirmed fix for https://bugs.launchpad.net/ubuntu/+source/libdvdread/+bug/869003 should I upload to -proposed now, or hold off until release?
<ubot4> Launchpad bug 869003 in libdvdread (Ubuntu Precise) (and 3 other projects) "dvdbackup: symbol lookup error: /usr/lib/libdvdread.so.4: undefined symbol: dlopen (affects: 5) (heat: 32)" [Undecided,New]
<SpamapS> kees: seems like it belongs in oneiric-proposed
<SpamapS> ScottK: I just noticed that too.. seems odd
<sbeattie> kees: there are other things in -proposed already, so I believe its okay to upload to there now.
<SpamapS> kees: and bonus, I'm reviewing the proposed queue right now, so should land quickly. :)
<kees> SpamapS: oooh-ho, let me shove it in then, one sec
<ScottK> SpamapS: We're going to start uploading KDE 4.7.2 shortly.  No need to accept it until it's all there ...
<SpamapS> ScottK: thanks for the heads up
<SpamapS> I think I'm done with oneiric-proposed reviews for today
<skaet> utlemming,   images posted to the tracker now.
<utlemming> skaet: thank you kindly :)
<ScottK> Is the pad out of date?  Reading it, I'd be expecting rebuilds that I'm pretty sure we already did.
<cjwatson> right, phew, I think all respins are finally done
<cjwatson> I've updated the pad, I think
<slangasek> unless server team cares about getting that open-iscsi issue fixed for final, I guess
<slangasek> Daviey: ^^ are delays on first boot after installing on iscsi root critical to you?  (If not, we can fix it in SRU)
<cjwatson> I'm going to steal antimony for a little while to do some timings of mirroring
<cjwatson> and hopefully improving matters
<skaet> charlie-tca,  have looked at 872374 and commented in the bug.   Its too late for now, but we would like to pick it up in an update.   See comments in bug.
<skaet> slangasek,  I talked to Daviey earlier,  and he's ok with release noting it.
<slangasek> ok
<slangasek> stgraber: ^^ so open-iscsi to -proposed please :)
<Laney> could someone rescore fwts and guichan so they get built before release please?
<charlie-tca> skaet: thank you for looking
<ScottK> lamont: ^^^?
<ScottK> Probably too late for  pitti.
<lamont> ScottK: nearing EOD myself, maybe slangasek/skaet could poke the vanguard
<ScottK> Who is that?
<lamont> I think it's darrenS
<GrueMaster> skaet: I have a bug in omap images (bug 838200), but it can be worked around with a little hackery.  I've marked it as serious for netboot only, as networking is kind of critical for net install.
<ubot4> Launchpad bug 838200 in u-boot-linaro (Ubuntu Precise) (and 2 other projects) "No network support on Beagle XM (affects: 1) (heat: 9)" [Undecided,New] https://launchpad.net/bugs/838200
<lamont> ScottK: actually, dblawson, this channel, atm
<ScottK> Thanks.
<lamont> erm s/channel/server/
<GrueMaster> Linaro knows about it and I have documented a workaround.  Also, not all beagleXM users I have talked with are seeing it.
<ScottK> skaet: ^^^ would you please ask dblawson to do laney's rescores?
<ScottK> Looks like NCommander or doko could do it too.
<Laney> or anyone on the TB ...
<GrueMaster> ScottK: NCommander is afn.  Pulled an all-nighter.
<ScottK> Oh.  infinity still haz powerz too.
<doko> which package?
<ScottK> fwts and guichan
<lamont> so does doko
<slangasek> skaet: I see some text corruption in https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#New_App_Developer_Site - not sure what "the central point" is supposed to link to, if anything?
<ScottK> skaet: Looks like it's taken care of.
<skaet> ScottK,  ack.
<skaet> slangasek,  looking.
<doko> rescored
<cjwatson> I had a temporary brain failure as to how or I'd have beaten you to it
<cjwatson> :-)
<Laney> cheers lots
<ScottK> doko: Thanks.
<skaet> slangasek,  yup, looks like dpm had some issues in his input,  we need to get it cleaned up.   If you can figure out what it should be, feel free to change,  otherwise I'll work with him tomorrow morning.
 * skaet sees slangasek has it locked. :)
<slangasek> skaet: I really have no clue what page he wanted that pointed to
<slangasek> skaet: meh, ignore my lock
<slangasek> there should be a better way to release a lock
<skaet> slangasek,  ok, I'll take some guesses, and see if I can figure it out.
<slangasek> you know, like 'cvs checkin'
<slangasek> CVS > MoinMoin
<ScottK> You say that like it's news.
<skaet> slangasek,  ok,  think I've made it make sense.  flag if you disagree.
<cjwatson> woo, I think I may have fixed the slow universe sync to cdimage
<skaet> *\o/*
<cjwatson> just shelved it to do a timing of universe-ports
<cjwatson> but for universe that went from 11m26s to 30s
<cjwatson> and from 7000-odd files transferred for a no-op sync to 0
<stgraber> open-iscsi is now in oneiric-proposed
<skaet> smoser, utlemming - was reading through the ReleaseProcess checklist, and came across a stale link.   What should https://wiki.ubuntu.com/UEC/Images/Publishing be now?
<slangasek> https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing
<skaet> Thanks slangasek.
 * skaet editing now
 * cjwatson finds a slew of files in the primary cdimage mirror owned by non-cdimage users - definitely not all recent since some are e.g. owned by tfheen
<cjwatson> I reckon these date back a *long* way
<ev> :)
 * cjwatson fixes with a crowbar
<cjwatson> (can't chown without root, so cp -a'ing aside and moving back)
<elmo> cjwatson: I can offer you a cheap chown service
<cjwatson> elmo: ah, well, in that case, 'chown -R cdimage:cdimage /srv/cdimage.ubuntu.com/ftp /srv/cdimage.ubuntu.com/ftp-ports' would be much appreciated
<doko> is coke cheapter than beer?
<elmo> cjwatson: running
<cjwatson> elmo: great, thanks (looks done)
<cjwatson> ok, I've finished messing with antimony's mirroring, and hopefully it should work properly now
<slangasek> cjwatson: woot :)
#ubuntu-release 2011-10-12
<GrueMaster> iso.qa.ubuntu.com is down, it would appear.
<ScottK> GrueMaster: Same here: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
<GrueMaster> sigh.  Well, Kubuntu on omap4 has passed.  Starting omap soon, then I am done testing.
<ScottK> slangasek: If you've got some Canonical IS bat phone you can call to get iso.qa.ubuntu.com, it might not be a bad idea.
<ScottK> GrueMaster: Great.  Thanks for taking care of Kubuntu again.
<slangasek> hum, indeed
<slangasek> bats phoned (?)
<ScottK> Now let's see if I can remember what the DVD tests are ...
<GrueMaster> ScottK: What's the scoop with the kubuntu-mobile image?
<ScottK> GrueMaster: There won't be one.
<GrueMaster> Well, I noticed that.  Has rblem stopped working on it?
<ScottK> No.
<ScottK> With Riddell gone this cycle we ended up not getting a lot of non-core stuff done.
<GrueMaster> Ah.
<GrueMaster> This cycle has been...interesting all around.
<ScottK> Yeah.
<ScottK> qa tracker is back.
 * slangasek nods
<ScottK> slangasek: Is there somewhere you can stuff the powerpc images for Kubuntu so if we get a tester we can release them late?
<ScottK> (if me saving a copy locally if sufficient, I can do that)
<pitti> Good morning
<pitti> Laney: all built now
<ScottK> Looks like someone just retried mlton.
<ScottK> Not sure if it'll make it.
<ScottK> pitti: For Kubuntu we are short of anyone that can test wubi.
<ScottK> The rest of the testing seems to be going well.
<ScottK> slangasek: I just got the text mode splash (with the boxes) on shutdown after install.
<ScottK> It was an install without a live session first, so that's not inconsistent with your theory.
<slangasek> ScottK: ok, thanks for the data point
<slangasek> I've just now managed to grab a process list from one of these shutdowns... ubiquity-dm still running for some reason even though the job is marked as stopped
<slangasek> (and ubiquity-dm still running means X is still running, so that's the heart of the bug right there)
<slangasek> as far as stowing images... which ones do you want stowed and for how long?
<slangasek> I guess we don't need to worry about stowing until Thursday anyway, right?
<pitti> slangasek: I'd like to upload a new ubuntu-defaults-builder to fix bug 869546; apparently lightdm's/unity-greeter's lightdm.conf handling changed rather late in the game, which broke setting the default session for ubuntu-defaults-builder
<ubot4> Launchpad bug 869546 in ubuntu-defaults-builder (Ubuntu Oneiric) (and 1 other project) "default session of ubuntu-2d doesn't work (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/869546
<pitti> slangasek: and OEM needs that this week
<pitti> it's not on any of the images, arch:all, and builds in a minute
<pitti> I have a tested fix
<pitti> slangasek: do you think that'd be ok?
<ScottK> slangasek: http://cdimage.ubuntu.com/kubuntu/daily-live/current/oneiric-desktop-powerpc.iso would be the one.  And yes, not until Thursday.
<ScottK> pitti: Since mlton is still building, I suspect it's OK.
<ScottK> It won't be the driver for mirror sync.
<pitti> thanks, I uploaded it now
<ScottK> (unless of course it fails again)
<ScottK> Either way it should be fine.
<pitti> ah, gcc-snapshot built
<ScottK> pitti: We did the first bit of kde 4.7.2 last night.  Please don't accept any of it to -proposed until it's all uploaded (one of us will let you know).
<pitti> I'll copy to oneiric-final, as discussed yesterday
<ScottK> Right.
<pitti> ScottK: oh, oops
<ScottK> It won't hurt.
<ScottK> It's just kde4libs.
<pitti> right; well, I guess it doesn't introduce any kind of incompatibility?
<ScottK> No.
<pitti> ok; if so, I can easily remove it from -proposed again
<ScottK> It's SRU worthy per our microrelease exception.
<ScottK> Did you accept your own upload?  I'm not seeing it in the queue?
<pitti> ScottK: what, defaults-builder? It just hit the queue
<ScottK> OK.
<ScottK> I guess I'm impatient since it's late here.
<pitti> waiting until it gets diffy before I pester the channel again
<ScottK> Right.
<pitti> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntu-defaults-builder/oneiric/revision/116
<pitti> for pre-review
<pitti> unity-greeter uses this script, too, and it works quite nicely for both existing and nonexisting lightdm.conf
<pitti> doko_: FYI, gcc-snapshot moved from oneiric-proposed to oneiric-release
<ScottK> OK.
<ScottK> And we have a diff.
<ScottK> pitti: Accepted.
<pitti> cheers
<ScottK> pitti: I won't have any wubi testers before (even potentially) US tomorrow.  If you could have a chat with jibel of one of the test people who have Windows to test with, I'd really appreciate it.
 * ScottK needs to go crash.
<pitti> ScottK: sure, will do
<pitti> ScottK: sleep well!
<ScottK> Thanks.
 * NCommander shows signs of life
<ev> I'd offer to help Wubi testing, but my VirtualBox instance seems to have eaten itself again. :-/
<pitti> seems kubuntu wubi was successfully tested already
<cjwatson> bug 322830 has recurred - ouch
<ubot4> Launchpad bug 322830 in livecd-rootfs (Ubuntu) (and 2 other projects) "remove /var/lib/dbus/machine-id from installed image (heat: 2)" [Undecided,Fix released] https://launchpad.net/bugs/322830
<cjwatson> I think this is respin-worthy for live images, sadly
<cjwatson> the more widespread images with this bug are, the more serious the consequences
<stgraber> I marked all the images using a livefs as rebuilding
<ogra_> did you include preinstalled ?
<ogra_> not sure we have that bug, but we build a livefs
<ogra_> (so i would assume we suffer from it too)
<cjwatson> Adam is looking at it
<cjwatson> I figure he'll think of that :)
<ogra_> ah, k
<ogra_> he surely will :)
<stgraber> ogra_: yeah, I marked everything that uses live-build as being rebuilt
<ogra_> k
 * ogra_ knows tobin will love us :)
<stgraber> ;)
<cjwatson> so removing /var/lib/dbus/machine-id has a few side-effects
<cjwatson> things like gsettings and fontconfig-voodoo fall over in casper, so I think casper needs to run dbus-uuidgen --ensure fairly early
<cjwatson> infinity and stgraber are discussing whether preinstalled images are ok
<cjwatson> and I think seem to reckon they are
<davmor2> ogra_: Love yes that the word, honest.... hate and kill weren't the ones that sprang to mind at all :)
<ogra_> LOL
<stgraber> http://paste.ubuntu.com/706676/
<stgraber> http://paste.ubuntu.com/706677/
<Laney> ?
<pitti> stgraber: what was wrong with the gsettings call?
<seb128> pitti, I guess what cjwatson said an hour ago
<pitti> the dbus machine ID?
<pitti> aah
<stgraber> pitti: we don't have dbus in casper
<seb128> well just assuming from the log
<pitti> I thought that was the part "we need to run dbus-uuidgen --ensure"
<cjwatson> no the gsettings call was actually something else
<cjwatson> turned out that it was broken before, even with the machine-id present
<cjwatson> because dbus is not running at all during casper and cannot be launched
<cjwatson> we should just not rely on dbus during casper - safer
<pitti> ah -- funny that it seemed to have the intended effect anyway
<pitti> perhaps the indicator now has its own way of not showing itself under a live session somehow
<pitti> i. e. the user menu is hidden in current live system already
<cjwatson> the user menu is, but the screensaver lock disablement was observed to fail
<cjwatson> apparently the indicator doesn't show if you only have one user
<infinity> The user menu appears to... What he said.
<pitti> ah
<infinity> It doesn't show up on stgrabers system either, because he has Guest disabled.
<infinity> But who knows if they'll change that behaviour in the future. :P
<cjwatson> if you actually looked at the gsettings key in the live session, it hadn't been set
<stgraber> my guess is that it only shows up if you have more than one entry
<stgraber> which you don't when guest session is disabled
<pitti> that's right
<cjwatson> having the screensaver lock on you during install is fairly nasty; it's unlockable if you happen to know the password but ...
<cjwatson> now, this may be yet another bug, because ubiquity is supposed to poke the screensaver regularly during installation; but stgraber speculates that possibly this was at the end of the install, since an Edubuntu install takes 1.5 hours
<ScottK> On my test installs of Kubuntu the screen would eventually shut off, but it would come back on without needing the password.
<infinity> ScottK: Yeah, we correctly disable the kde screensaver.
<ScottK> Do the Kuubntu images actually need respinning?
<infinity> ScottK: To have the casper version in sync, yes.
<ScottK> Do I care?
<infinity> ScottK: It won't change anything for you, but it's bad form for the images to not match the archive, IMO.
<infinity> ScottK: Oh, and you need the dbus fix.
<ScottK> OK.
<infinity> ScottK: So, yes.  You need a rebuild.
<ScottK> Fine then.
<ScottK> I was losing track.
<ScottK> Thanks.
<Sjimmie> !timer
<ubot4> Factoid 'timer' not found
<Sjimmie> !countdown
<ubot4> Please remember that #ubuntu, #kubuntu, #xubuntu, and #edubuntu are support channels. To countdown to Natty release and then party once it happens, join #ubuntu-release-party - For in-person parties, see http://loco.ubuntu.com/events/global/744/detail/
<cjwatson> respins in progress
<ScottK> Sjimmie: This is a working channel.  Please don't mess around here.
 * ogra_ guesses that will finally include preinstalled too for consistency ? 
<ogra_> (reading infinity's comment above)
<Sjimmie> mybad
<cjwatson> ogra_: yes
<ogra_> k
<cjwatson> and accidentally included core, although I didn't mean to, but infinity says he doesn't mind
<ogra_> yeah
<ogra_> the test casde is a joke anyway :)
<ogra_> *case
<ogra_> (untar, chroot, run apt-get)
<slangasek> why did the tarball cross the road
<ogra_> tell us :)
<slangasek> so how's it going?  do we need to hustle some more American testing resources for today, or will the respins land early enough to get some testing at the release sprint today?
<skaet> slangasek,  yes please
<slangasek> ok
<skaet> respins should be starting to emerge in the next 1/2 hour or so.
<slangasek> do we have an ETA for the imageS?
 * slangasek nods
<skaet> will be emerging as the same order as the rebuild script on the pad
 * highvoltage is almost tempted to suggest dropping DVDs for the next edubuntu release and only supporting usb images (dvd writing failure write is scarily high, at least for the machines / discs we have here)
<highvoltage> s/write/rate/g
<stgraber> highvoltage: well, we can just tell everyone to dd the .iso to a usb key. Doesn't cost anything to keep them as .iso on the server
 * GrueMaster wakes up to a day of respins, groans and goes to find coffee.
<highvoltage> GrueMaster: I tested some coffee this morning, and it was at least one thing this morning that was working great for me
<GrueMaster> I think my coffee maker has an arm core.  It is a bit slow and doesn't multitask very well.
<GrueMaster> Any eta on the new images?  Remember, it takes hours to download over the pond for me (even with zsync).
<cjwatson> all I know is
<cjwatson> server preinstalled
<cjwatson> annonaceae.buildd starting at Wed Oct 12 14:40:22 UTC 2011
<cjwatson> sycamore.buildd starting at Wed Oct 12 14:40:22 UTC 2011
<cjwatson> unfortunately we seem to have lost timestamping in livefs build logs when we switched to live-build :-(
<cjwatson> so I don't have good historical data on how long it takes
<GrueMaster> Time is an illusion.  Lunchtime doubly so.
<Riddell> stgraber: can you dd to usb drives now?
<stgraber> Riddell: last I tried, yes, our .iso are hybrid
<cjwatson> yes, as of 11.10
<cjwatson> June or so
<Riddell> nice, we should ensure docs are up to date on that so people make usb disks from non-ubuntu linux
<GrueMaster> One thing I noticed on cdimage with the preinstalled images, there are two files required for imaging the AC100, but only one is in the MD5SUMS.  Can this be corrected?
<cjwatson> is that the .bootimg file?
<GrueMaster> yes
<GrueMaster> And it is critical that it matches with the tar.gz as it contains the md5sum of the tar.gz file.
<Daviey> utlemming: Hey, I assume /current AMI's have been posted to AWS.  When will they be changed private->public?
<slangasek> cjwatson: what's the link to the Qin images?
<Daviey> utlemming: A user reported they can see /current MAI's in us-east-1 - but not the other regions?
<cjwatson> GrueMaster: fixed - will sync out when the next image rolls out
<cjwatson> thanks
<cjwatson> slangasek: http://china-images.ubuntu.com/oneiric/daily-live/current/
<GrueMaster> cjwatson: Excellent, thanks.
<slangasek> ta
<cjwatson> GrueMaster: actually, that'll be a little while, so I've pushed it now
<GrueMaster> Meh.  Still need to wait for the new images to finish rolling.
<GrueMaster> Thanks, though.
<cjwatson> server preinstalled seems fairly close to done
<pitti> good night, time for some sports
<infinity> pitti: 'Night.
<utlemming> Daviey: that's odd
 * utlemming checks on /current
<smoser> current != 20111101
<smoser> tested == 20111101
<utlemming> Daviey: the release will go public when I get the go ahead to do so. The final images are not public
<utlemming> Daviey: the user is not looking at http://uec-images.ubuntu.com/releases/oneiric/ which is where the releases will land
<utlemming> Daviey: if they are not seeing current, my quess is that they are not using "--region ${REGION}"
<utlemming> http://paste.ubuntu.com/706807/
<Daviey> utlemming: thanks
<Daviey> utlemming: wait, that is 20111012
<Daviey> 20111011 is the release, right?
<utlemming> Daviey: yup...give me a minute to post the correct ones :)
<cjwatson> (PS isn't it cloud-images.ubuntu.com these days?)
<Daviey> cjwatson: yes.
<utlemming> cjwatson: both are active...I should be good boy and update my URL's
<Daviey> smoser: you opened an RT for a redirect, right?
<utlemming> cjwatson: both are active...I should be good boy and update my URL's
<utlemming> Daviey: yes, cloud-images.ubuntu.com works
<Daviey> yeah, sure - but i thought i read an RT for a redirect.
<smoser> i've opened no such redirect.
<Daviey> smoser: Hmm, /me greps logs
<utlemming> http://paste.ubuntu.com/706812/
<superm1> i just read in BT for -installer about an issue with /var/lib/dbus/machine-id being static in the rootfs.  are all ISOs getting a respin for this, or has it already happened?
<infinity> superm1: It's in progress.
<superm1> Ok thanks
<ev> anyone want to step out for food and then come back? - http://paste.ubuntu.com/706851/
<stgraber> diff from old i386 to new i386: http://paste.ubuntu.com/706870/
<cjwatson> grub is driving me slowly insane
<cjwatson> think I'll have to single-step this
<slangasek> what's this?
<GrueMaster> Any updates on the armel image rebuilds?  Server is tested, waiting for desktop.
<cjwatson> GrueMaster: it's built the first pair of livefses and is working on the second pair; ETA about 40 minutes I think, maybe a bit more
<cjwatson> guessing a bit there
<GrueMaster> ok, thanks.
<cjwatson> jamespage: is there a bug number for your grub raid failure?
<cjwatson> slangasek: install on raid-1 of two disks, first boot works, also works if you pull the second disk, but if you pull the first disk then grub starts but crashes
<cjwatson> looking like weird memory corruption somewhere
<slangasek> hmm
<slangasek> not planning to respin the world for that, are you?
<cjwatson> no, it's SRU material
<cjwatson> but I have the repro case in front of me and am trying to narrow it down while I do
<cjwatson> and before I forget
 * slangasek nods
<jamespage> cjwatson: no - I can raise one now if that helps
<jamespage> any package in particular I should be raising against? is it a grub issue?
<cjwatson> grub2
<cjwatson> it's absolutely a grub2 bug, it's crashing
<cjwatson> I can reproduce it, I can reproduce it with added debugging code, I'm just getting insane output
<cjwatson> as in a variable changing over the space of a few lines when it's not assigned to
<jamespage> cjwatson: bug 873009
<ubot4> Launchpad bug 873009 in grub2 (Ubuntu) "Unabled to boot degraded RAID-1 array from second disk (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/873009
<slangasek> -0001640 88 90 7c aa 97 1f 5c 56 fe 03 b7 69 e6 1e db 08
<slangasek> +0001640 88 90 7c aa 97 1f 5c fb ff 07 b7 69 e6 1e db 08
<slangasek> cjwatson: you read zlib fluently, right?  why's that word different? ;)
<slangasek> well... half word
<slangasek> (feel free to ignore in favor of grub, I'm just venting frustration :)
<cjwatson> I have absolutely no idea :-)  It would be useful to know which bit of the structure that word's in (e.g. I suspect perhaps it's in the Huffman tree)
<cjwatson> jamespage: ta
 * slangasek nods
<cjwatson> since a difference in an unused bit of the Huffman dictionary could produce no output difference
<cjwatson> although why you might have anything unused in a compressed file ...
<slangasek> yeah, I was thinking that a bit odd
<Daviey> bdmurray: Hey, are you around?
<bdmurray> Daviey: yes
<Daviey> bdmurray: bug 870281, i noticed you touched it recently... can't that be forgotten now?
<ubot4> Launchpad bug 870281 in flashplugin-nonfree (Ubuntu Oneiric) (and 2 other projects) "installer crash when user choose to install additional software: http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.3.183.10.orig.tar.gz doesn't exist (affects: 24) (dups: 24) (heat: 202)" [High,Fix released] https://launchpad.net/bugs/870281
<Daviey> it's well past fixed, right?
<bdmurray> Daviey: when I touched it I updated the description.  Some mirrors are out of date.
<Daviey> bdmurray: they will be updated by release, no?
<slangasek> they're supposed to be updated *hourly*
<bdmurray> Daviey: aren't they already *days* behind
<slangasek> so if they're out of date, assume they will remain so unless action is taken :)
<Daviey> some mirrors only sync daily tho, right?
<Daviey> but that package was fixed Friday.. we should be good now, surely?
<bdmurray> but we aren't
<bdmurray> I can provide you a test script if you'd like proof
<Daviey> bdmurray: what mirror did you see that on?
<bdmurray> Daviey: again its in the description
<ScottK> Daviey: Why are release notes only for bugs?
<bdmurray> wget -S http://dk.archive.ubuntu.com/ubuntu/pool/multiverse/f/flashplugin-nonfree/flashplugin-downloader_11.0.1.152ubuntu1_i386.deb
<bdmurray> that and es, no, se, si, and tr
<bdmurray> will all 404
<Daviey> ScottK: did i say they were?
<ScottK> Daviey: Sorry.  Wrong Dave.
<ScottK> No.  That was you.
<cjwatson> wubi built; now waiting for arms
<ScottK> Daviey: Bug 840135
<ubot4> Launchpad bug 840135 in software-properties (Ubuntu) (and 1 other project) "oneiric-backports enabled by default in software-properties (affects: 1) (heat: 8)" [Undecided,Invalid] https://launchpad.net/bugs/840135
<Daviey> ScottK: there is no changed user behavior, why does it need to be mentioned?
<ScottK> Daviey: The point is that it looks like it will.
<ScottK> Ask yourself why the user filed the bug.
<ScottK> I think it's a reasonable point to document.
<Daviey> ScottK: if you think so, feel free to re-enable it.. it just seems like if we documented everything like that, it would be a large book.
 * Laney doesn't like the "nothing to fear here" tone of the proposed text, but I think release noting it is reasonable.
<ScottK> Laney: Feel free to improve it.
<ScottK> That was what I could think of.
<Laney> hmm.
<Daviey> I really don't think we have 45 bugs which require release notes TBH.
<Laney> I just want to say something about how it's a safe way to get new stuff
<Daviey> ah, some of them are really old.
<micahg> I think the backports issue definitely should be release noted, if people don't understand it's pinned lower and won't pull in anything unwanted, they might turn it off out of fear
 * Laney wonders how many people go around disabling things on their system out of fear
<Laney> "at least one"?
<ScottK> cf the long thread on the Ayatana list re music search.
<Daviey> I don't feel too strongly either way, but i am leaning towards it being noise.
<micahg> Laney: it's a new "feature" of oneiric as a release, that alone should warrent it being release noted
<Laney> yes
<Laney> I want it to be presented in that way though
<micahg> ah, ok
<Daviey> Feature rather than a Known Issue.
<Laney> not in a "don't fear, we do not want to break your system" way
<micahg> yes, makes sense
<Laney> why is my computer making a scary noise?
<Laney> where are the release notes being staged?
<Daviey> Laney: they are not yet, i'm going through them as bugs at the moment - taking out ones which should have been dropped at prior release time.
<Laney> ok
<Laney> just wanted to see what kind of tone to take
<Daviey> Laney: so skaet might correct me, but i think it needs to go onto https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview , and from that - a smaller note will be created based on the vital things.
<Laney> yes, i am looking at that
<Laney> this could go into new features?
<Daviey> works for me
<Daviey> "Backports now more accessible"
<Laney> is my new wording any better?
<slangasek> Daviey: what are the criteria for these "smaller" release notes?  Because up to this week, skaet has been asking for more detail rather than less
<slangasek> on that page
<Daviey> slangasek: No, i just meant the very minimal "here it is"
<slangasek> ah
<slangasek> cjwatson: are hybrid CD/USB images new this cycle?  there's a stub for it on https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#Ubuntu_Common_Infrastructure... I thought those landed earlier
<Daviey> Does anyone object if i Invalid all ubuntu-release-note bugs which were raised before Oneiric?
<cjwatson> slangasek: new this cycle, yes - June
<slangasek> cjwatson: ah, alright.  Anything particular you want said there? ):
<slangasek> :)
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033495.html
<cjwatson> I'm happy to write something up tomorrow
<cjwatson> or you can cull from that post
<slangasek> I'll do the latter
<slangasek> Daviey: how are you determining which ones were raised before oneiric?  the bug number doesn't tell you when it was raised against the release notes
<cjwatson> right.  beer
<Daviey> slangasek: when the bug task was added.
<Daviey> the release-notes task
<slangasek> Daviey: right; seems like a lot of work to even determine that
<micahg> Daviey: might want to just make sure none affect 10.04.4
 * Daviey drops it and hits the pub.
<Laney> much more sensible
<ev> elmo: We're going to fix it tomorrow, but wubi disk image downloads are currently hardcoded to cdimage. We won't need to respin CDs for this, as Wubi on the CD won't need an image download.
<ev> We will need to resign though.
 * elmo twitches
<elmo> ev: ok
<slangasek> ev: (ah, I'll grab you here instead ;)  how does ubiquity currently select its mirror?
<elmo> slangasek: country + $CC.archive.u.c ?
<ev> apt-setup does it
<elmo> (I don't know how it determines country these days, but I assume it involves geo*.ubuntu.com)
<ev> Yes
<slangasek> ev: specifically, trying to understand the impact of bug #870281 and mirrors, and if it always points to cc.archive.u.c
<ubot4> Launchpad bug 870281 in flashplugin-nonfree (Ubuntu Oneiric) (and 2 other projects) "installer crash when user choose to install additional software: http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.3.183.10.orig.tar.gz doesn't exist (affects: 24) (dups: 24) (heat: 202)" [High,Fix released] https://launchpad.net/bugs/870281
<slangasek> to make sure that cleaning up the cc list is sufficient
<doko_> slangasek, cjwatson: when do you expect to open pedantic tomorrow?
<elmo> slangasek: yes, it will be
<doko_> ehh, precise
<slangasek> doko_: haha
<slangasek> doko_: I don't know if we have an expected timeline on that
<slangasek> elmo: ok, just making sure :)
<cjwatson> slangasek: yes, cleaning up cc.* will be sufficient
<slangasek> good, good
<cjwatson> doko_: my guess is starting around 3pm, but it's just a wild guess
<doko_> ok, thanks
<cjwatson> I'll update you tomorrow
<doko_> I'll be around until 17:30 UTC. will email you what is prepared/needs uploads
<slangasek> cjwatson: were you planning to take care of the dpkg merge for the buildflags stuff?  seems like that's probably important to get in early, not sure whose list it's on
<cjwatson> yes, I was planning to tackle that tomorrow morning
<slangasek> ok
<cjwatson> should've done it today really, but
<slangasek> ah, it's in the wiki page
<doko_> mu suggestion was to keep the current behaviour for p
<cjwatson> buxy has an updated multiarch branch, yes?
<cjwatson> I agree with doko
<slangasek> right, I agree with the plan of record (er, maybe the plan of IRC log) - keep exporting the variables from dpkg-buildpackage, but also make sure dpkg-buildflags is DTRT
<slangasek> I believe buxy is keeping the multiarch branch current
 * skaet --> leaving office,  back online a bit later.  
<slangasek> fwiw, I've been aggressively converting my own packages to dpkg-buildflags in Debian... samba is hardened this way, openldap is RSN
<micahg> the xfce packages are being hardened the new way as well
<mdeslaur> slangasek: we could always pocket copy the flash 11 package to the -security pocket also, assuming the installer has security.u.c turned on during installation
<slangasek> mdeslaur: out-of-date mirrors are a pretty fundamental issue anyway
<mdeslaur> slangasek: ok
<slangasek> that's a good idea as a fallback if we need it, but I'd rather we just let IS get on with fixing the root issue first
<cjwatson> slangasek: converting> me too
<GrueMaster> cjwatson:  md5sum mismatch with http://cdimage.ubuntu.com/daily-preinstalled/20111012/oneiric-preinstalled-desktop-armel+ac100.bootimg.
<GrueMaster> everything else in that directory matches ok.
 * slangasek has a look
<slangasek> well, that's not good
<slangasek> GrueMaster: I can confirm that it's also broken on the server; the md5sum I get is b8e73f114548af51edcc87c6297a4791, which is not what's listed in MD5SUMS
<slangasek> but the file is older than the sums data, so... not sure how that happened
<GrueMaster> I'll check the bootimg file.  It contains the md5sum of the tar file, which makes it critical to be in sync.
<slangasek> GrueMaster: if it doesn't match up, let me know and I'll work out how to rebuild the bootimg
<slangasek> (dunno how long that takes...)
<GrueMaster> ok.  One sec.
 * slangasek looks askance at bug #873080
<ubot4> Launchpad bug 873080 in plymouth (Ubuntu) "Splash screen not loading (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/873080
<slangasek> 3-4 years?  really?
<GrueMaster> Looks to be the correct bootimg, md5sum just didn't get updated properly.
<slangasek> GrueMaster: ok, I'll update the checksums files - thanks
<slangasek> GrueMaster: updated and pushed
<GrueMaster> Tested:  Passed.   Thanks, slangasek
<elmo> 23:20 < DarrenS> elmo: those mirrors all look ok
<elmo> slangasek: ^-- rest of $cc.archive.u.c
<elmo> fwiw
<slangasek> elmo: alright, thanks :)
#ubuntu-release 2011-10-13
<slangasek> cjwatson: bug #322830 still has an open task on casper that's marked 'critical' - is that accidental?
<ubot4> Launchpad bug 322830 in livecd-rootfs (Ubuntu) (and 4 other projects) "remove /var/lib/dbus/machine-id from installed image (affects: 2) (dups: 1) (heat: 20)" [Undecided,Fix released] https://launchpad.net/bugs/322830
<slangasek> s/accidental/left over/
 * slangasek calls it a day
 * GrueMaster has finished armel testing (yet again).
<Riddell> DVDs tested, time to snooze, send me a text if we suddenly release early
 * charlie-tca thinks the release notes and tests he can do are done
 * charlie-tca signed off Xubuntu tests completed on https://wiki.ubuntu.com/OneiricOcelot/ReleaseManifest
<pitti> Good morning
<pitti> cjwatson, infinity, skaet: pre-published the images
<pitti> I kept the beta-2 images for now (I guess we should remove them together with the publishing of final?)
<sebsebseb> hi
<wgrant> Is someone doing bad things to the LP cdimage prober?
<pitti> wgrant: not fiddling with it right now, but I did pre-publish the images some 2 hours ago; something wrong with that?
<wgrant> Well, it's been running for more than an hour, which is slightly abnormal. Perhaps it's just checking lots of images.
<wgrant> As long as it's not broken.
<ogra_> we have a bunch of new armel images
<ogra_> and i think also some more UEC ones than last time
<pitti> wgrant: that just added 10 images in total, does that count as "lots"? it's exactly the same number that we have pre-published for ages
<wgrant> Perhaps it's a combination of archive + cdimage mirror load just slowing things down.
<wgrant> Difficult to say. There's a lot of HTTP requests involved.
<wgrant> Finally finished. So it's working, but slow.
<GrueMaster> ScottK: Around?
<ogra_> GrueMaster, i signed off the armel images on the release manifest, if nobody says "respin" in the next hours we're good :)
<GrueMaster> Is this because of the livecd machineID thing?
<ogra_> ??
<ogra_> that was the last build :)
<ogra_> no worries
<GrueMaster> Ok.  Just was looking at the pad notes (see topic).
<ogra_> i think it just isnt updated until all images were tested
<ogra_> that bug was the reason for the last rebuild
<GrueMaster> ogra_: I'll start on armel release notes tomorrow.  Bed time here.
<ogra_> GrueMaster, dont bother, i'll take on all the work left with infinity, thanks a lot for teh hard work !
<GrueMaster> I was referring to the work-arounds for various things like netinstall and the oem-config issue.
<ogra_> the bugs are tagget for release notes already, right ?
<ogra_> so we should just be able to search them
<GrueMaster> I don't seem to have the ability to tag for release notes.  You should be able to see the bugs on the iso tracker.
<ogra_> right
<ogra_> no prob then, just relax, you deserve it
<ogra_> tsk, #u-r-p turned into a "desktop bashing and windows support" channel today
<maxb> ogra_: The first does not surprise me. Oneiric's desktop experience is particularly bash-inviting
<ogra_> heh, well, depends what you use ... unity-2d is cool
<pitti> I'm off for about 2 hours for a dentist appointment
<infinity> pitti: Yeah, we should remove beta-2 with the final push, I'd say.  And archive it to old-images on antimonry.
<infinity> pitti: antimony too.
<pitti> dentist for real now, back in ~ 2 hours
<cjwatson> slangasek: closed out that casper task now
<ogra_> do we have an upgrade fix for the dbus ID issue ?
<ogra_> or do people upgrading from beta need to manually remove the machine id ?
 * ogra_ thinks he only saw a fix in casper which wont fix existing installs
<ogra_> (and live-build indeed)
<infinity> ogra_: Did Tobin do kubuntu testing and forget to sign off?
<ogra_> i think he tested it, yes, but not sure it survived actually
<infinity> ogra_: And no, we don't have an upgrade path for people with broken machine-ids.
<infinity> ogra_: We're going to release note it.
<ogra_> all i see is that he tried to ping ScottK above
<infinity> ogra_: Hrm.  Well, I can test omap4/kubuntu here, can't do omap
 * ogra_ has no XM handy and doing desktop testing on a C4 (256M) isnt really helpful
<ogra_> i trust tobin that he mailed scott about any issues though
<infinity> ogra_: Well, looks like Tobin passed kubuntu/omap* in the isotracker.
<infinity> ogra_: So we just need signoff from a product owner.
<ogra_> which is scott
<ogra_> i guess he will do once he is up :)
<infinity> We might get Riddell to do the signoff.  Scott may be passed out. :)
<skaet> Riddell, ping?
<Daviey> bug 857816 looks interesting
<ubot4> Launchpad bug 857816 in xserver-xorg-video-intel (Ubuntu) "X fails to start on boot (affects: 3) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/857816
<cjwatson> starting release publishing
<cjwatson> sync-mirrors chmod -x'ed
<ev> I can haz windows testers? http://people.canonical.com/~evand/wubi/oneiric/wubi-r243.exe
<ev> ^ jibel
<ev> particularly testing if the UI remains responsive while downloading
<cjwatson> archived beta-2
<jibel> ev, k, I'm downloading it.
<cjwatson> running publish-image-set.py output
<jibel> ev, installation files download doesn't start.
<jibel> ev, actually that's the progress bar not refreshing
<ev> argh
<jibel> ev, there's also a traceback in the logs but the UI doesn't crash http://paste.ubuntu.com/707240
<ev> jibel: http://people.canonical.com/~evand/wubi/oneiric/wubi-r244.exe
<jibel> ev, looks good, I'll finish the install and run the uninstaller to make sure everything's fine.
<ev> brill, thanks
<ev> I'm doing the same in wubi, for what it's worth
<ev> as my virtualbox copy of windows is broken yet again
<jibel> ev, I ran 244 successfully with 32 and 64 disk images.
<ev> jibel: thanks!
<ev> jibel: http://people.canonical.com/~evand/wubi/oneiric/wubi-r245-signed.exe
<pitti> skaet: can I still edit https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes or is that frozen now?
<pitti> ah, seems it is
<skaet> pitti,  it depends.
<pitti> I wondered whether to add a paragraph about language-selector
<pitti> we removed the individual "just install fonts"/"just install dictionaries" etc. check boxes again, it's all or nothing now
<pitti> it's pretty much self-explanatory, but some users might wonder
<skaet> pitti,  prep up the paragraph, and we'll fold it into the next update.
<pitti> but perhaps that goes a bit far, given that gnome 3 changed so many things anyway
<pitti> skaet: on second thought I think I'll skip it; release notes shouldn't be a replacement user manual
<infinity> pitti: Yeah, if we release note every missing button or checkbox, it'd be a Stephen King novel.
<pitti> infinity: no, it wouldn't -- people read Stephen King novels from the first page to the last
<infinity> Not sane people.
<pitti> I think it might be just a tad more interesting than reading a telephone book :)
<pitti> infinity: as someone who read at least three SK novels in his life I formally protest
<infinity> pitti: Noted.
<pitti> heck, I managed to read 80% of "Das Kapital" from Karl Marx..
<pitti> anyway, getting OT
<ogra_> pitti, time to get one with it and finish the remaining 20 on y flight :)
<ogra_> *a flight
<seb128> pitti, reading the releasenotes, shouldn't deja-dup,backup be in the features?
<cjwatson> I'm sure I saw it there
<seb128> it's in "updated applications"
<seb128> but we didn't ship it by default before so that doesn't really fit
<ev> cjwatson: http://people.canonical.com/~evand/wubi/oneiric/wubi-r245-signed.exe is the one we want
<seb128> well, tb and lightdm are there as well
<ev> stable symlink updated
<cjwatson> thanks
<cjwatson> that's done, working on chinese images then mythbuntu
<ev> jibel: http://people.canonical.com/~evand/tmp/wubi-r248.exe
<jibel> ev, no crash with 248 and 245 still crashes, fix is in.
<ev> wooohooo!
<Riddell> cjwatson: any idea why this page says "Ubuntu 11.10 (Oneiric Ocelot)"? http://releases.ubuntu.com/kubuntu/
<cjwatson> hand-written, I'll fix it
<cjwatson> pushed
<Riddell> ta
 * Riddell wonders if it's safe to go for lunch or not
<ogra_> depends if its a 6 course menu or not :)
<Daviey> skaet: Possible to squeeze in one more known issue to the release notes?
 * Laney can't even load them atm
<skaet> Daviey, prep up the change you want.   We'll add them, as soon as we can.
<mdeslaur> is the publisher on manual today? can someone publish my postgresql security updates please?
<Sjimmie> 11 hours left :)
<infinity> mdeslaur: It's not on manual.
<cjwatson> Sjimmie: please don't do that here; #ubuntu-release-party exists
<mdeslaur> infinity: ok, thanks
* cjwatson changed the topic of #ubuntu-release to: Ubuntu 11.10 released! | 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 with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<pitti> wohoo! congrats everyone
<charlie-tca> Congratulations to everyone.
<charlie-tca> Also, a *big* thank you from Xubuntu for all the help with this release.
<ogra_> wohoo
<ogra_> its an ocelot !!!
<skaet> Thank you to the release team members! and all the ubuntu flavor leads and developers!   Nice work indeed.
<pitti> skaet, cjwatson, infinity: already have plans for this afternoon/evening? enjoy the beer!
<infinity> pitti: I'm planning on beer.
<nigelb> Congrats folks :)
<skaet> pitti,  will do.  Hopefully they left me some champagne in the kitchen.   ;)
<ogra_> skaet, i assume there is no release tem meeting tomorrow ? :)
<ogra_> *team
<pitti> huge congrats to whomever did http://www.ubuntu.com/tour -- that's awesome!
<ogra_> yeah
<skaet> ogra_,  no meeting tomorrow.   Next meeting after UDS.  :)
<ogra_> we should improve it and just ship a browser instead of a desktop :)
<ogra_> skaet, yeah, that was rather rethorical :)
<skaet> :)
<skaet> pitti,  web team rocks!  :)
<chrisccoulson> i wish libreoffice opened as fast on my machine as it does in the online demo ;)
<chrisccoulson> that's pretty cool though
<ogra_> ++
<nigelb> ogra_: http://quotes.burntelectrons.org/3161
<nigelb> heh, the future is here! :D
<chrisccoulson> nigelb, ha, how did you find that?
<chrisccoulson> you should ping bz and show him the future ;)
<nigelb> chrisccoulson: already did!
<nigelb> in #developers :D
<chrisccoulson> ah, yes. i see :)
<popey> Riddell: http://www.kubuntu.org/files/11.10-release-banner.png
<popey> oneirc -> oneiric
<Riddell> mm
<ogra_> awww, typos in pngs ... mean
<slangasek> skaet: congrats
<slangasek> and congrats to the rest of the team!
<ttx> congrats everyone !
<utlemming> cloud images are published
<Laney> :-)
<skaet> slangasek,  thanks!
<Pici> Hey folks, is someone here able to update https://help.ubuntu.com/community/UbuntuHashes with the new values.  I bugged -docs, but didn't get a reply.
<cjwatson> ISTR last time I wanted that I filed a bug on ubuntu-docs
<cjwatson> which indeed is what the page says.  I don't have edit rights
<Pici> Will do.
<mvo> if someone could review/accept my update-manager upload to oneiric-proposed that would be much appreciated
<mvo> and my upload of update-manager to natty-proposed too please :) ?
<cjwatson> doko: suggestion for next time: make debian/changelog of the PPAed toolchain uploads say q-series (or whatever), but fiddle the .changes to say Distribution: precise so that the PPA accepts it
<cjwatson> would be slightly less confusing, dependidng[D[D on your point of view :)
<doko> cjwatson, hopefully I'll remember =)
<slangasek> mvo: havin' a look
<slangasek> huh, a lot of stuff in -proposed
<cjwatson> doko: heh
<slangasek> mvo: your oneiric-proposed upload includes a change not mentioned in the changelog - seems to be a legitimate fix for fstab parsing, but not sure if you meant to document it?
<slangasek> (DistUpgrade/apt_btrfs_snapshot.py)
<mvo> slangasek: its auto-imported from the apt-btrfs-snapshot upload
<slangasek> ah
<mvo> but indeed, I should have mentioned it in the changelog
 * slangasek stabs lp credentials caching in the face
<slangasek> ah, and seahorse hangs
<slangasek> SpamapS: would you mind sru-accept'ing update-manager/oneiric (bug #873411)?  I've reviewed it but am having Tooling Problems here
<ubot4> Launchpad bug 873411 in update-manager (Ubuntu Oneiric) (and 1 other project) "Unable to upgrade to 11.10 using kpackagekit (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/873411
<SpamapS> slangasek: ack, accepting now
<slangasek> ta
<wgrant> cjwatson, doko: You don't even have to fiddle with the .changes if you don't want to: you can upload to /ubuntu/q-series instead of /ubuntu to override the .changes-specified series.
<wgrant> We're about to put the publisher on manual for an hour or so to create armhf.
#ubuntu-release 2011-10-14
<GrueMaster> Oh, joy.  Double my fun.
<wgrant> infinity, cjwatson: armhf all done. Just needs a manage-chroot/add-missing-builds when you're ready for builds. And might need some IS pokage to get it onto ports.u.c, I suppose.
<cody-somerville> lol. If I click 'Ask me later' on the 'Ubuntu 11.10 Upgrade Available' popup, nothing happens.
<infinity> wgrant: \o/
<wgrant> infinity: Have fun with NEW...
<wgrant> Although I guess you might have old scripts for that.
<infinity> wgrant: Oh ugh.  Did it drop all those arch_all copies into new?
<wgrant> infinity: No, but all the armhf binaries will.
<wgrant> Once we start building them.
<infinity> They... Shouldn't?
<infinity> I don't recall that happening with armel or lpia.
<infinity> Though it's been a while.
<wgrant> Oh, indeed, it falls back to other archs.
<wgrant> Forgot that bit.
<wgrant> I see you have quite the army of arm* builders now.
<infinity> Sort of, though we plan to get rid of all the babbages, so the current list is only temporarily exciting.
<wgrant> Bah.
<wgrant> Will be interesting to see how quickly the flock of pandas gets through the archive, anyway.
<infinity> We'll need more of them.
<infinity> And we're working on that.
<infinity> But it might not be too awful.
<infinity> I hope. :P
<wgrant> At least we're starting early this time :)
<infinity> Ish.  I seem to be taking vacation at a rather inconvenient time, but I hope to be babysitting builds be the end of next week.
<infinity> s/be the/by the/
<jdstrand> skaet: hi!
<jdstrand> skaet: I was asked to talk to you about bug #314432
<skaet> hiya jdstrand! :)
<ubot4> Launchpad bug 314432 in launchpad "It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed (affects: 4) (dups: 4) (heat: 60)" [High,Triaged] https://launchpad.net/bugs/314432
<skaet> jstrand,  classic.
<jdstrand> skaet: this is a real problem for my team, and I imagine it would be for you. do you think we can up that to Critical as flacoste mentioned in comment #18 this morning?
 * skaet looking
<jdstrand> I also wonder why I am not allowed to escalate it
<infinity> Only certain LP people can escalate LP bugs.
<skaet> jdstrand,  as a way of dealing with the backlog,    they are taking that input from the representative stakeholders that's all.
<jdstrand> sure, but this is getting on 4 years
<jdstrand> slipping is one thing, but we are missing stuff (still) because of it
<skaet> jdstrand,  yup
<skaet> its on the list now,  there are some other things there too.   archive skew,  and rebuild are there as well.
<jdstrand> skaet: ok, as my representative stakeholder, this is probably the most important bug the security team has
<jdstrand> skaet: thanks
<skaet> jdstrand.  gotcha.   :)
<skaet> thanks.
<jdstrand> skaet: would you mind commenting in the bug in whatever way is appropriate as my representative? :)
<skaet> yup,  doing it now. ;)
<jdstrand> \o/
<jdstrand> skaet: actually, you may want to look at bug #874250. this was discovered today and adversely affects our kernel cadence
<ubot4> Launchpad bug 874250 in launchpad "Nominations stop working when bugs have large number of projects (affects: 1) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/874250
<jdstrand> skaet: what this means is we have to skip these bugs entirely when doing our workflow. so, precise for example currently cannot be tracked
<jdstrand> skaet: I guess I should revise my comment and say "these are the two most important bugs the security team has" :)
<jdstrand> (cannot be tracked in those bugs where this LP bug bites)
<skaet> jdstrand, which of thw two is hightest priority?
<jdstrand> skaet: it would have to be kernel workflow at this point
<jdstrand> skaet: but I worry that it will go to Critical and the other stay at High and the other won't be fixed for another 4 years
<jdstrand> do I sound jaded?
<skaet> jdstrand,  understandably.  :/   Anyhow,  I'll reflect the order in my request in.
<jdstrand> skaet: k, sorry for not remembering the kernel workflow bug
<skaet> no worries.   :)   This is the problem the launchpad team has in spades,  hence the desire we prioritize amongst each of the stakeholder viewpoints a bit.
<jdstrand> skaet: well, while the old one affects more teams, the 2nd one is more strategic and there is no workaround
 * skaet nods
 * Laney promotes 648611 too
#ubuntu-release 2012-10-08
 * infinity wishes poor queuebot would come back.
<infinity> Thanks, mystery queue accepty person.
<slangasek> infinity: tested here, and the libisofs patch doesn't give me any more useful MBR tables than the previous version without -partition_offset 16
<infinity> slangasek: Well, that seems a bit special, then. :/
<slangasek> infinity: so -partition_offset 16 no longer breaks EFI hybrid booting, but I'm not sure if it's worth including this fix just to include the -partition_offset option
<infinity> slangasek: (We don't have a hidden static copy or something, do we?)
<slangasek> no
<slangasek> it's using the new version, and it does cause partition_offset to not break the GPT itself
<infinity> Ahh.
<slangasek> but the MBR seems to be totally useless on this image in both cases
<slangasek> by which I mean, the MBR /partition table/ is useless; obviously the MBR boot sector is working fine
<slangasek> so IMHO it's not worth fiddling with libisofs further right now unless something turns up in testing
<slangasek> considering we still have SB pieces to put together, which is going to take a bit of time
 * infinity nods.
<infinity> I'm too busy wasting my weekend with Pandas to have opinions. :P
<ara> good morning!
<ara> anybody around from the release team willing to review a FFe request?
<ara> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1060211
<ubot2> Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed]
<ara> <ara> good morning!
<ara>  anybody around from the release team willing to review a FFe request?
<ara>  https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1060211
<ubot2> Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed]
<ara> Laney, ^ ?
<Laney> hi ara, will look at the queue in a bit
<Laney> make sure it's New and has ubuntu-release subscribed
<ara> OK, I will, thanks
<ara> Laney, it is
<Laney> ok
<cjwatson> ^- asymptotically approaching working secure boot; Steve and I cross-reviewed each other's changes and at least my grub-install changes are battle-tested on relevant hardware
<cjwatson> would greatly appreciate quick review so that we have a chance of getting working images by ~tomorrow
<cjwatson> also it'd be nice to get my 20 no-change rebuilds this morning accepted; running out of time
<Laney> unapproved: the gift that keeps on giving
<cjwatson> thanks
<Laney> what's left?
<cjwatson> for sb?
<Laney> yeah
 * Laney eyes lplib
<Laney> I do not want to set a password for my keyring every time, thanks
<cjwatson> grub-efi-amd64-signed.postinst tweak to run grub-install and update-grub on configure; shim-signed upload with MS signature + possibly calls to things like sbkeysync; grub-installer change to install grub-efi-amd64-signed and shim-signed if SB active; debian-installer work to use gcdx64.efi.signed rather than building its own image; and possibly a cdimage tweak to make use of that
<cjwatson> oh, and probably something to arrange for the signed kernel to be installed
<cjwatson> so still quite a few elements but I think they are individually mercifully small by this point
<cjwatson> (it would all have been done a month or two ago if we hadn't been politically stalled for ages, but anyway :-/)
<Laney> fair do
<Laney> hopefully I'll be able to run it here
<cjwatson> ^- that'll be the amd64 binary for signing; an AA should accept it iff they feel that my most recent changes are not a security compromise
<ara> Laney, any news for my FFe? 0:-)
<Laney> ara: just replied
<Laney> also, punted some removals to the -archive queue
<ara> Laney, fantastic, thanks!
<apw> cjwatson, the above linux-meta carries the new linux-signed-* meta packages
<apw> cjwatson, the above linux-signed carries fixed up binary dependancies to include linux-image-extras so we get all of the modules
<cjwatson> apw: both look good, thanks
<cjwatson> Hum
<apw> hum sounds bad
<cjwatson> jdstrand: Can I promote linux-signed without an MIR?  The installer's going to want to install it, and it's just a signed copy of code maintained elsewhere
<cjwatson> I left linux-signed-{,image-}generic in universe for the time being
<apw> ahh yes, and now the installer will need them, croak
<cyphermox> I'm just finding out that the ModemManager orig tarball in the archive is bad and missing stuff; should I just upload the right one now (after re-testing) to make sure things still work, given that I had all the necessary FFEs?
<cyphermox> fwiw; the missing stuff appears to be just bugfix that should have made it but somehow didn't
<cyphermox> and the cause of the issue looks like it was because I'm working with a few versions of ModemManager at the same time, I handled the wrong tarball
<cjwatson> I'd say just upload it to the queue, obviously with a new upstream version number for the changed.orig
<cjwatson> *changed .orig
<cyphermox> cjwatson: alright
<TheLordOfTime> when's the final EOL date for 12.04?
<TheLordOfTime> s/12.04/11.04/
<TheLordOfTime> (yes, i failed to type 11.04, but the 1 and 2 keys are righ tnext to each other :P)
<cyphermox> https://wiki.ubuntu.com/Releases
<TheLordOfTime> cyphermox, it states October 2012, i was looking for a more specific date :P
<cjwatson> by default, exactly 18 months after original release
<cjwatson> whether that's actually when it happens depends on available effort
<jbicha> personally, I'd prefer the definition of "18 months" to be once the third release after comes out, I didn't like that maverick was EOL before precise came out
<cjwatson> Yeah, I don't really feel strongly about it either way; three releases give or take a few weeks is roughly what it's always meant, I think
 * smartboyhw agrees
<cjwatson> So, it looks as though the ARM buildd issues are fixed; we're catching up on some urgent security builds, and will then retry the current broken ones from quantal-proposed
<seb128> ^ libreoffice is Sweetshark second try at fixing the arm* builds
<cjwatson> seb128: the previous builds are still going though?
<seb128> cjwatson, well, he said that his test build on scheat finished before the buildds and failed on a packaging error (he didn't correctly update some part after disabling the plugins on arm)
<seb128> cjwatson, so the current builds are going to fail at some point
<cjwatson> Hm.  OK, but I'd like to not fill up the ARM builders with libreoffice just now
<seb128> your call
<cjwatson> Trying to spread things out a bit
<seb128> feel free to kill the current libreoffice builds there
<cjwatson> I can't
<cjwatson> Well, only by asking IS
<seb128> hum, k ... well anyway, when there is spare arm* builder time you might want to throw that new libreoffice at them ;-)
<cjwatson> Which I guess might not be a terrible idea
<seb128> seems worth it if you need arm* builds
<Laney> cyphermox: wowzers, that's quite the diff (modemmanager)
<cjwatson> OK, libreoffice builds killed, security builds at higher score already, accepted new libreoffice
<cjwatson> Well, accepting - IIRC last time it took a few attempts
<cjwatson> Currently nine geckos and two webkits building, so it'll take a while for much else to get a look-in
<cjwatson> Oh, good, libreoffice accepted first try
 * Laney checks how long webkit takes
<Laney> 1 day, 8 hours, 59 minutes, 10.0 seconds
<Laney> oh good
<cjwatson> Quite
<cyphermox> Laney: yeah, had a "major" issue with the upstream tarball
<cyphermox> this is how things should have been since Sep. 7
<cyphermox> I re-tested all my modems and those that worked still do, those that didn't work still don't (but I suspect it's a SIM issue more than the modem, I just didn't get a SIM for them yet)
<Laney> cyphermox: Righto ...
<bdmurray> Would it be possible to waive the 7 days in -proposed for bug 964674?
<ubot2> Launchpad bug 964674 in update-manager "update-manager fails to display an error message" [High,Fix committed] https://launchpad.net/bugs/964674
<ScottK> If someone can review/accept clamav today, I can start the microversion update process this evening ....
<doko> would it be possible to accept gcc-snapshot so that it builds once the arm queues get empty?
<ScottK> Looks like that'll be awhile.
<ScottK> I'll try and keep an eye on it though.
<popey> is there anything else missing from bug 1063133 to get it synced from debian?
<ubot2> Launchpad bug 1063133 in openshot "FFe: Sync openshot 1.4.3-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1063133
<doko> cjwatson, how many armv5 uploads are left?
<iulian> popey: I was looking at it earlier but I didn't realise that Len was in -studio-dev and thus I didn't do anything. It looks fine to me. Daviey ^
<Daviey> ogasawara: Hey, are we expecting a kernel upload soon?
<Daviey> iulian: Ah, thanks.. Processing now
<Daviey> popey: Done.
<popey> awesome, thanks chaps!
<cjwatson> doko: about 50
<doko> cjwatson, maybe just upload now?
<cjwatson> Yeah, I expect I'll do that before I go to bed tonight
<doko> the queues should be empty tomorrow, most of the mozilla builds will finish in the next hour
<cjwatson> I'll do a few now, but I'll need to go and spend time with K.  I'll be back later
<tkamppeter> I have posted a fix for critical bug 1059286 (Avahi).
<ubot2> Launchpad bug 1059286 in avahi "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,Fix committed] https://launchpad.net/bugs/1059286
<tkamppeter> Can someone upload the fixed avahi package?
<doko> looking
<cjwatson> doko: uploaded another dozen or so - as I say, I'll do the rest later tonight
<doko> tkamppeter, I think the patch itself looks ok. however this is an ABI change. I think you need to change the lib* package name(s), where this struct changes.
<doko> tkamppeter, is this change accepted upstream?
<doko> I think it would be good to coordinate with debian on the package name change
<cjwatson> It's too late to change avahi's soname for 12.10
<cjwatson> FWIW
<doko> cjwatson, please have a look at the patch, if my conclusion is correct
<cjwatson> No time now
<doko> ok
<cjwatson> Just saying that this is a constraint on what's reasonable for 12.10
<cjwatson> (And certainly not saying that it would be OK to change the ABI backward-incompatibly without changing the soname - it wouldn't, of course)
<cjwatson> Is struct AvahiDnsPacket part of the public API?
<cjwatson> I don't see it in the header files
<cjwatson> I mean the installed ones
<doko> you don't have time ;)
<cjwatson> Yeah, I found a bit after all :)
<cjwatson> Because I love you all so much
<doko> you better love K.
<cjwatson> Heh
<cjwatson> So, OK, this is in publicly exported symbols
<cjwatson> It depends how opaquely it's defined; if existing binaries outside avahi itself are not allowed to know about the layout of that struct, it's OK
<cjwatson> But it would still be worth checking with upstream
<tkamppeter> doko, I do not know whether it is accepted upstream, as there is no answer from an upstream developer.
<tkamppeter> doko, how does the ABI change look like? If it only adds stuff and does not remove anything or change parameter lists of functions is it then not harmless?
<cjwatson> tkamppeter: changes struct layout and size
<cjwatson> That *would* be an ABI change if (and only if) existing binaries linked against the library are allowed to know about the layout and size of that struct
<cjwatson> If all they do is treat it as a pointer to opaque stuff and use entirely accessor functions, it's OK
<cjwatson> That's why I was trying to work that out
<tkamppeter> cjwatson, doko, can this perhaps be fixed/worked around by marking the extra symbols/variables private?
<cjwatson> I think it's actually OK, because that header file isn't installed for public use, so nothing should be able to know about that struct
<cjwatson> This isn't C++
<cjwatson> But the header not being installed in /usr/include is a good guarantee anyway
<cjwatson> This is just an internal interface within avahi, AFAICS safe to change
<doko> indeed, http://packages.ubuntu.com/search?searchon=contents&keywords=dns.h&mode=exactfilename&suite=quantal&arch=any doesn't show anything about avahi
<doko> tkamppeter, cjwatson: avahi uploaded
<tkamppeter> doko, thank you very much.
<doko> tkamppeter, please could you ping this patch upstream?
<tkamppeter> doko, the patch is from upstream mailing list and was contributed by a SUSE developer, but I have emphasized anyway that it should go upstream.
<cjwatson> doko: Could you have a look at whether speex is OK for ARMv5t?  The recent changelog entries make me unsure about whether a simple rebuild is enough
<cjwatson> Stuff about FP
<doko> looking
<infinity> cjwatson: We probably just want to go back in sync with Debian for speex.
<infinity> doko: ^
<infinity> cjwatson / doko: Any objections to me just syncing speex, it seems to have picked up other things we'd want (hardening, etc)
<infinity> cjwatson / doko: And it's been cooking in unstable/testing for 3 months, should be pretty safe.
<doko> ugh, maintainer Ron Lee ..
<infinity> Well, yes, there's that.
<doko> and a rc report
<cjwatson> infinity: Not sure the cross-building patch is in Debian
<cjwatson> Is the fortify stuff?
<infinity> I don't see a cross-building patch.  Unless you mean multiarch?
<cjwatson> Uh, duh, sorry, wrong changelog
<infinity> The current Debian version is multi-archy.
<cjwatson> tcl8.4 != speex, shockingly
<infinity> In all respects, it looks like a sane sync to me, and one less useless delta to worry about.
<infinity> Yeah, I get them confused all the time too. ;)
<infinity> After looking at the diff, I'll just sync.
<cjwatson> If the diff's sane, sure
<infinity> You can hold me responsible if it breaks.
<doko> infinity, please could you review the proposed patch, and include it if appropriate?
<cjwatson> I don't see the RC report
<infinity> cjwatson: The PTS is confused, I think.
<doko> no, just out of date. it was downgraded
<cjwatson> Oh, just slightly out of date
<cjwatson> Yeah
<infinity> doko: Oh, indeed, the bug and patch look somewhat sane, I think.  Though, I might have to look at more context to judge that.
<infinity> cjwatson: You can reject my sync, if you like, I might do an ubuntu1 with the patch in the morning.
<doko> thanks
<infinity> Meh, I'll reject it myself.  The reject mail will be a reminder to do the merge. :)
<cjwatson> No harm doing the sync anyway, surely
<infinity> cjwatson: No, no harm except buildd time.  But I guess I'm curious to see that it builds correctly.  Fine, no rejecting.
<cjwatson> infinity: Looks fine.  Accepted.
<cjwatson> Feel free to follow up :)
<cjwatson> Now you have an accept mail as a reminder for the merge. :P
<cjwatson> doko: Do you think we should sync zope.interface?  Looks like the only Ubuntu delta was reverted, and the bug fixed in Debian looks potentially interesting
<cjwatson> So, aside from that, I just want to look into whether tcl8.4 and vte should be merged
<doko> cjwatson, zope.interface: ack
<cjwatson> I skipped linux-linaro-omap and linux-linaro-vexpress - I expect those are for userspace tools binary packages, but I really don't see the point as any actual ARMv[56] device is going to need a kernel package anyway
<cjwatson> doko: thanks, synced
<doko> hmm, there is no way to build python-stdlib-extensions for 3.3
<cjwatson> And everything else is uploaded now
<doko> or we promote it for main, which we'll do anyway for r
<cjwatson> Isn't there a python3-stdlib-extensions?
<cjwatson> Oh, right
<doko> same source
<cjwatson> Different source
<cjwatson> According to LP
<doko> yeah, but not in main
<doko> I mean, 3.3
<cjwatson> Mm
<cjwatson> Well, you're the one on the MIR team :)
<doko> proposing it hinders me to ack it
<cjwatson> Sigh, uninstallables.  My bad :-/
 * cjwatson does a bit of constructive rescoring
<doko> I'll ask security on the 3.3 promotion
<cjwatson> I expect the uninstallables will mostly clear as ARM builds flush
<cjwatson> Daviey: Any progress on freeipmi?
<cjwatson> Final freeze nears
<doko> we should rename component-mismatches to server-mismatches ;-P
<cjwatson> doh, think I retried pygobject-2/powerpc too early, was reading wrong uninstallables report
<cjwatson> hate the primary/ports split there
<cjwatson> Yep.  My bad
<bdmurray> If I want to upload a new version (same number) of update-manager to precise-proposed I should first use remove package to remove update-manager from precise-proposed correct?
<ScottK> Well, for once ppc isn't the slowest one.
<cjwatson> Ah, super-long publisher run, bah
<ScottK> bdmurray: Is it in the queue or has it been accepted already?
<cjwatson> ~18 minutes spent processing a libreoffice translations tarball
<cjwatson> bdmurray: You may not ever reuse a version number in the primary archive
<cjwatson> Removal won't help you (and if you manage to get it to, you're exploiting a bug)
<cjwatson> As ScottK implies, if it's only in the queue then you can reject that and reupload, and that's fine, but if it's accepted you must use a new version
<ScottK> Right.  That's where I was going.
<bdmurray> Got it thanks.
<cjwatson> Version numbers are cheap anyway. :-)
<ScottK> Right.  I just used clamav - 0.97.6+dfsg-1ubuntu0.11.04.1~10.04.1~ppa1 for a test package.
<ScottK> cheap and potentially ugly.
<cjwatson> ScottK: I'm finding it hilarious for powerpc to be so comfortably far ahead again
<cjwatson> I notice the absence of calls to drop ARM
<ScottK> Right, now that it's armv5, it'll run on lots of stuff Ubuntu couldn't run before.  Maybe people like it for that.  Dunno.
<cjwatson> Oh, I just meant ARM in general. :-)
<cjwatson> (armv5> As long as you didn't need chunks of universe.)
<ScottK> Right.
<ScottK> Stale chunks.
<cjwatson> Mmm.
<ScottK> I liked how some of your rebuilds to drop to v5, the previous changelog entry was a rebuild to bump to v7.
<cjwatson> ScottK: Me too :-)
<doko> the armel buildds cry for more armv5 uploads
<doko> finally, the last mozilla security upload is now building on armel
<ScottK> doko: I pushed some more through.
<ScottK> Actually I got an upload building sooner on powerpc than on armhf too.
<ScottK> cjwatson: Would you please rescore calligra.  It's a longish build and I'd like to see it get started on arm/ppc since AFAIK it's not been built on those archs before.
<ScottK> Plus, then I won't feel conflicted about accepting more of the rebuild uploads ....
<cjwatson> ScottK: sure, bumped up a bit
<cjwatson> hm, maybe a touch higher
<ScottK> cjwatson: There is a non-rebuild usb-modeswitch in queue.  How about if you review/accept that one and I'll reject your rebuild only upload.
<ScottK> Thanks.
<cjwatson> ah, sure, didn't notice that
<doko> ScottK, cjwatson: calligra rescores done
<ScottK> Thanks.
<cjwatson> cyphermox: hm, so I'm not totally comfortable with this
<cjwatson> cyphermox: strtok mutates its first argument, and getenv typically returns a pointer straight into environ
<ScottK> Are lpia ppa builders permanently gone?
<cjwatson> cyphermox: you should really strdup the return value of getenv before calling strtok on it
<cjwatson> ScottK: we can reassign x86 builders to lpia temporarily
<ScottK> Probably not worth the trouble.
<cjwatson> I do it in batches occasionally
<ScottK> OK.  It'd be nice to know if the clamav upload I just did for hardy to the ubuntu-clamav PPA will build on lpia.  It'll have to eventually ...
<ScottK> No rush though.
<cjwatson> cyphermox: So not comfortable with this as it stands and rejecting, but it should be OK if you add a strdup/free pair
<ScottK> cjwatson: Should I accept your rebuild then or assume he'll be back before release?
<cjwatson> ScottK: Happy to assume he'll be back
<ScottK> OK.
<cjwatson> ScottK: There are a couple of lpia builders there now.  I'll rebalance again later
<ScottK> I think my flight's about to board, so I'll likely vanish in a few minutes.
<ScottK> Thanks.
<cjwatson> Safe travels
<ScottK> LP claims a 6 hour wait for the lpia buildd.
<ScottK> I wouldn't wait up for it.
<ScottK> ;-)
<ScottK> All the rebuilds accepted.
<cyphermox> cjwatson: ah, sure. I didn't think of that
#ubuntu-release 2012-10-09
<slangasek> cjwatson: this grub2-signed downloads the gcdx64.efi.signed, but doesn't appear to install it (Makefile is unchanged)
<slangasek> cjwatson: reuploaded with this fix, and accepting
<cjwatson> slangasek: Whoops, thanks
<cjwatson> Quite right
<slangasek> grub-installer looks good
<slangasek> adding grub-efi-amd64-signed to the installer seed now
<slangasek> (supported-installer-common, to be precise)
<doko_> quantal, not precise?
<slangasek> I don't want to be quantal
<slangasek> I want to be precise
<doko_> ;)
<slangasek> I'm also assuming grub2-signed doesn't require an MIR since there's no new binary package code
<slangasek> so, promoted'n'such
<cjwatson> supported-installer-common isn't really right
<cjwatson> I think it should go in platform.quantal/d-i-requirements plus ubuntu.quantal/ship-live
<cjwatson> (And probably in general all seeds that currently contain grub-efi)
<doko_> afk now
<cjwatson> s/right/sufficient/
<slangasek> ok
 * xnox ponders how much stuff I have missed over the weekend...
<cjwatson> Well, some of the changes in tcl8.4 we kind of want, but I think it's too involved for 12.10 and I'm not certain whether it would break any dependent packages
<cjwatson> So I'm justs uploading a no-change rebuild for that
<cjwatson> *just
<cjwatson> vte has a fix to an Ubuntu bug that has been getting "so when are you going to apply my clearly sensible patch?" (and it is clearly sensible) for months, and two security fixes
<cjwatson> So I think I'll merge that
<cjwatson> vte merge uploading, and that's the last of the armel rebuilds, so *zonk*
<cjwatson> ARM builds starting to generally emerge from gecko, though it'll be ten more hours or so until those are entirely finished
<cjwatson> cyphermox: I've accepted usb-modeswitch as the only remaining problem I can see is a very unlikely scenario; but I think you should check getenv's return for non-NULL before passing to strdup, as right now I think this will segfault if you run it with PATH missing from the environment
<cjwatson> (not that it would probably work very well in that case anyway, but)
<cjwatson> thanks
<slangasek> ok, why was nvidia-graphics-drivers 304.51-0ubuntu1 let in during the freeze?
<slangasek> bug #1063969
<ubot2> Launchpad bug 1063969 in plymouth "No Plymouth Splash on Latitude E6420" [Undecided,New] https://launchpad.net/bugs/1063969
<slangasek> I'm getting rather sick of having to chase down last-minute regressions in plymouth support with nvidia drivers due to last minute changes to the packaging
<slangasek> cjwatson: ^^ from scrollback, it looks like you were probably the one who reviewed/accepted the nvidia packages; just a heads-up that there's a pattern of ill-tested last-minute packaging changes...
<Daviey> cjwatson: I wasn't able to touch it yesterday at all.  It will be done today.
<infinity> ^-- Who accepted those ppl binaries?
<infinity> You just skewed it on armel and armhf...
<infinity> Oh, nevermind, the only arch:all package is a -doc package anyway.
<infinity> Although, ppl-dev should have probably been NEWed to main.  So, I'm back to "who did that?"
<cjwatson> ^- should fix wrapitk-python/amd64 build failure
<cjwatson> slangasek: Yeah, that was me, sorry - was it the gfxpayload blacklist change?  I assumed that was fixing a disease that was worse than the cure, sorry ...
<slangasek> cjwatson: the "disease" it was fixing is entirely unsubstantiated in the referenced bug report :/
<infinity> cjwatson: Accepted.
<cjwatson> slangasek: *sigh*
<cjwatson> infinity: thanks
<infinity> slangasek: About the only validity the report appears to have is that it came from @nvidia.com, but yeah, it doesn't actually say what the problem *is*, just that there might be one.
<infinity> Always irksome, that sort of "bug".
<infinity> "This package might misbehave sometimes."
<slangasek> ah, I didn't catch the submitter's domain
<slangasek> but even so, bleh
<cjwatson> Yeah, I think I took that as authoritative
<slangasek> grr, grub2-signed override to main didn't take for the binary; promoting now
<slangasek> (so today's images missed including it; probably not worth a rebuild for just that, we might as well get the d-i piece done first too)
<cjwatson> slangasek: I already promoted
<cjwatson> Yeah, not worth a rebuild, not like we worked on SB yet anyway ...
 * slangasek nods
 * ogra_ wonders why its always cjwatson's uploads that remind me of the sins of my youth ... and files bug 1064271
<ubot2> Launchpad bug 1064271 in redboot-tools "please demote redboot-tools to universe" [Medium,Triaged] https://launchpad.net/bugs/1064271
<seb128> gtk reverts http://git.gnome.org/browse/gtk+/patch/?id=5debed5ae247c1dd440cb71d0a6d328df74b0844 ("Shut down a11y when an app shuts down") to workaround https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1056300
<ubot2> Ubuntu bug 1056300 in gtk+3.0 "If a GTK application quits the main loop and restarts it again, accessibility is lost." [High,In progress]
<seb128> e.g "ubiquity looses a11y midway"
<seb128> it's not a fix but it seems to safest option for release
<xnox> seb128: yes, please. I am also confused how they managed to slip such a big feature so late in the 3.6 cycle.
<seb128> it's not so much of a "feature" than an optimization...
<seb128> but GNOME is not very good nowadays to be conservative about their changes (well, the same way we have issues pushing back on #ps changes to be fair)
<xnox> seb128: well the point of that gtk commit, as far as I can see, is a workaround the apps that are not using GApplication(-shutdown) and hence don't clean up a11y resources at the end.
<xnox> I am not sure if ubiquity should be using GApplication or not.
<seb128> it's a good discussion to have with desrt at UDS ;-)
<seb128> I'm not sure but, ubiquity is not really a standard "application", well not in sense of desktop application
 * cjwatson tries to work out why wrapitk-python was deleted from quantal for other architectures
<Laney> rejecting gdm - confused, asking a question
 * Laney gets irritated at Launchpad wiggling in the launcher so often
<cjwatson> "NBS libgdcm2.0, and no rdepends for python-insighttoolkit3"
 * cjwatson suggests that removing non-NBS binaries of a source package still in the archive is not the best idea
<doko> asked the schooltool maintainers about a FFe
<Laney> you might want to reject so nobody accidently accepts then
<doko> I'm not -release
<Laney> or duplicates time reviewing
<Laney> oh woe
<cjwatson> ah, a simple rebuild would have fixed wrapitk-python, rather than removal, it seems
 * cjwatson does that
<jbicha> Laney: what was the gdm question?
<Laney> about the prerm change
<Laney> doko: I'm doing so. Please could you let them know what's happened?
<jbicha> I've uninstalled gdm a few times and it's killed my X session which is not nice, I'm not sure there's any need for uninstallation to kill gdm
<Laney> yeah possibly not
<doko> Laney, done
<Laney> ta
<doko> Laney, please accept zope.interface, synced by cjwatson yesterday
<Laney> looking at the rest now
<Laney> the base revision chosen by LP for the e-d-s diff is curious
<cjwatson> Probably the last one in -proposed
<seb128> Laney, it's the previous upload to that pocket? like if that goes through proposed
<cjwatson> The ancestry code is basically wrong
<cjwatson> Needs a complete overhaul AFAICT
<Laney> does indeed seem to be the previous -proposed upload
<Daviey> cjwatson: freeipmi uploaded (i missed the convention local function on the last upload, now used.)
<Daviey> kind to review sir?
<cjwatson> Sure
<cjwatson> When the diff arrives
<Daviey> http://pb.daviey.com/0Dxi/
<cjwatson> I needed code context anyway :)
<cjwatson> That looks better now, thanks - accepted
<cjwatson> Daviey: Per jdstrand, the MIR still needs these patches forwarded to Debian, and ubuntu-server added to bug subscribers
<Daviey> cjwatson: Yep
<cyphermox> cjwatson: no, it won't segfault. I tested this by itself in a quick little program by itself
<cjwatson> strdup(NULL) is not defined
<cyphermox> why am I duplicating words ;)
<cyphermox> cjwatson: oh wait, you mean if PATH is undef
<cjwatson> Unset, not empty
<cyphermox> right
<cyphermox> in the case where usb-modeswitch-dispatcher gets run (by udev), very unlikely to happen
<cjwatson> As I say, corner case and will probably fail somewhere else anyway - I just don't like leaving segfault cases around unhandled
<cjwatson> (Which is why I accepted with a comment rather than rejecting)
<cyphermox> sure. I'll fix it first thing in R; I'll start a list now
<cjwatson> ta
<doko> cjwatson, is it ok to update base-files for the rc?
<cjwatson> doko: We're not doing an RC as such
<cjwatson> Just incrementally better until release :)
<cjwatson> doko: But yeah, probably might as well
<doko> ok
<doko> python3-stdlib-extensions: needed to build the _gdbm and _tk extensions for 3.3. talked with jdstrand that it's ok to have it main for q
<cjwatson> seeding and promoting linux-signed - same rationale as slangasek gave earlier for grub2-signed
<smartboyhw> Jesus
<smartboyhw> There are 7 days left in the current cycle. That means that in order to complete all the work 90.29 workitems must be completed per day.
<smartboyhw> OMG
<chrisccoulson> hey, is someone able to approve flash, please? :-)
 * GridCube gives smartboyhw a chamomile tea
<smartboyhw> GridCube, thx:D
<ara> morning release team!
<ara> currently, many udev related tests in checkbox are broken, as they are not using udisk2
<ara> would this fix require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035
<ubot2> Ubuntu bug 1016035 in checkbox "Add udisks2 support to scripts/removable_storage_* scripts" [High,In progress]
<cjwatson> Reviews of base-installer and grub-installer would help unblock me a little - more secure boot madness
<didrocks> Laney: I think you may consider that upload for quantal finale. I tried to be as descriptive as possible in the changelog, but do not hesitate to ask me anything else :) ^
<stgraber> cjwatson: I'll take a look in a minute
<Laney> didrocks: oui mon ami
<didrocks> Laney: merci! :-)
<jdstrand> cjwatson: did you get an answer on linux-signed (sorry for the delay-- holiday)
<cjwatson> jdstrand: on which aspect?
<Daviey> Anyone object to me doing a server spin?
<jdstrand> cjwatson: you asked me about promoting it with a mir
<jdstrand> without a mir
<cjwatson> Daviey: component-mismatches looks pretty unresolved
<cjwatson> jdstrand: oh, I JFDIed that a little earlier today
<cjwatson> and figured I'd apologise if somebody objected
<jdstrand> cjwatson: ok, based on what you said a few days ago, I would have said as much\
<cjwatson> ok, good
<Daviey> cjwatson: I think c-m just needs a refresh
 * cjwatson looks at rmadison output
<cjwatson> mm, out of sync across architectures.  I'll fix
<Daviey> cjwatson: I have just fixed
<cjwatson> server spin is fine then as long as it's just amd64/i386
<Daviey> That is all i want for this spin
<cjwatson> Actually, freeipmi-common was in universe
<cjwatson> Oh, but that's NBS
<cjwatson> This is confusing :)
<cjwatson> I guess this will settle down in a bit.  At the moment I can't say whether a server spin is likely to work
 * Daviey leaves it another hour, for giggles
<cjwatson> Yeah, if I were you I'd let the automatic reports have a chance to catch up before spending any manual time on it
<Daviey> yeah, ok. Thanks
<stgraber> cjwatson: accepted
<cjwatson> stgraber: thanks
<cjwatson> ooh, webkit/armhf succeeded
<Laney> nice
<Laney> armel is nearly there too
<cjwatson> Yeah
<Laney> glorious
<Laney> I got some new puncture proof tyres for my bike over lunch too â truly a day for vanquishing broken old crap
<apw> the recent linux-meta upload fixes an issue where installing linux-crashdump on an efi system uninstalls your bootloader
<cjwatson> apw: haha
<cjwatson> We rule
<apw> cjwatson, i thought so :)
<cjwatson> Eh, that's not really right - grub-efi is a transitional package
<cjwatson> Should be grub-efi-ia32 | grub-efi-amd64
<ara> cjwatson, do you think this would require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035
<apw> cjwatson, if you reject it can we re-use the version number ?
<ubot2> Ubuntu bug 1016035 in checkbox "Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
<cjwatson> apw: yes
<apw> ok do that, lets git it right
<cjwatson> apw: ok, done, please pass on to smb
<cjwatson> ara: sorry, eyebrow-deep in secure boot right now, no spare brain
<cjwatson> if in doubt, upload, it'll be queued and reviewed anyway
<ara> cjwatson, OK, now worries
<ara> cjwatson, OK, thanks
<stgraber> zul: ping
<zul> stgraber:  whats up?
<stgraber> zul: cinder in the queue does a dh_fixperms -X on nova_tgt.conf but the rest of the diff refers to cinder_tgt.conf
<zul> stgraber: crap can you reject it please ill upload a fix
<stgraber> zul: ok
 * stgraber assumes we want to keep base-files in the queue until FinalFreeze and leaves it there
<skaet> ev, are there any more fixes expected for WUBI?   ( its time to ask IS to prepare the signed copy)
<ev> skaet: credit where credit is due, cjwatson has been doing all the fixes. I've just been building the binaries
<ev> I am unaware of any further changes that need to be made
<cjwatson> likewise, for the moment
<skaet> fair 'nuf ;)
<ev> so we can most certainly put in an RT for the signed copy
<cjwatson> not much changed this cycle
<ev> shall I sort that out then?
<skaet> thanks cjwatson, ev - doing.
<ev> ah
<ev> excellent
<ev> :)
<cjwatson> haven't had my recent fix for Tibetan verified, but well
<cjwatson> best-effort at this point given everything else :-/
<ogasawara> skaet: the kernel team would like to get a freeze exception for a kernel upload.  It would be to resolve the following: bug 1063061, bug 1061599, bug 1021471, bug 1030233, bug 717970
<ubot2> Launchpad bug 1063061 in linux "please backport support for EFI vars > 1KB" [Medium,In progress] https://launchpad.net/bugs/1063061
<ubot2> Launchpad bug 1061599 in linux "beagle: omap3: usb is dead" [Undecided,Fix committed] https://launchpad.net/bugs/1061599
<ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
<ubot2> Launchpad bug 1030233 in linux "not have bluetooth usb 0489:e046 Foxconn / Hon Hai" [Medium,Fix committed] https://launchpad.net/bugs/1030233
<ubot2> Launchpad bug 717970 in linux "After sleep, key presses get lost and trackpad is jittery" [High,Fix committed] https://launchpad.net/bugs/717970
<skaet> ogasawara,  will we need a d-i as well?
<ogasawara> skaet: I don't believe it is an ABI bump, so no
<skaet> ogasawara, ok,   have all the fixes been independently verified?  ( like we would for SRU?)
<ogasawara> skaet: yep, all thoroughly tested
<skaet> ogasawara, coolio.  If the kernel is ready to upload, rather get it in sooner than later.
<rtg> ogasawara, we don't have a patch set yet for 1063061
<ogasawara> skaet: ack I still need to get the final patch revisions for 1063061 from apw but am told it will be ready shortly
<ogasawara> rtg: ^^
<skaet> ogasawara,  understood.   just to confirm - plan is to revert if any issues found with this latest kernel?
<rtg> ogasawara, hmm, it had a lot of issues and I'm not sure we'll be able to test it sufficiently.
<ogasawara> skaet: indeed, that would be the plan if any regressions appear
<ogasawara> rtg: hrm, maybe we should make sure we're both on the same page with apw
<rtg> yeah
<cjwatson> ironically 1063061 is the only one of those I care about ;-)
 * stgraber cares about bug 1021471 (makes LXC almost unusable on 12.10)
<ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
<Laney> yes :-)
 * Laney is trying to do a stgraber on this new install and have no dev packages installed on the bare metal
<Laney> using lxc for dev
<cjwatson> skaet: there'll necessarily be at least one more d-i anyway
<cjwatson> so I don't think we should worry about that either way
<skaet> cjwatson,  ok.
<cjwatson> (general catchup; SB work)
<cjwatson> yay, webkit/armel finished
<doko> cjwatson, stgraber: webkit now built in -proposed for armel and armhf. please promote to quantal so that ephiphany can start building
<doko> heh
<cjwatson> doko: I'm going to wait for a publisher run
<cjwatson> I am taking absolutely no risks here
<cjwatson> At least process-accepted, anyway; actually getting it onto disk doesn't matter
<cjwatson> doko: copied
<cjwatson> ^- that grub2 upload is critical path for secure boot images
<stgraber> cjwatson: will review
<doko> cjwatson, could you have a look at the python3-stdlib-extensions upload?
<stgraber> cjwatson: can you review isc-dhcp and ifenslave-2.6 in exchange? :)
<cjwatson> one at a time :)
<stgraber> cjwatson: accepted
<cjwatson> doko: Have you already convinced somebody else on the MIR team that it's OK to promote python3.3?
<cjwatson> stgraber: shorter form: BOND_SLAVES="${BOND_SLAVES:+$BOND_SLAVES }$name"
<doko> cjwatson, from my point of view not needed, only a new upstream version. got approval from jdstrand from a security point of view, and from barry from a technical point of view
<cjwatson> But accepted the increasingly inaccurately named ifenslave-2.6
<cjwatson> doko: In that case it's fine - I assume you're ready to promote python3.3 so that this can build?
<doko> right
<cjwatson> OK, accepted
<cjwatson> stgraber: and isc-dhcp is fine too, accepted
<stgraber> cjwatson: thanks
<skaet> cjwatson, stgraber, infinity, Laney, and other members of the release team ;) - pitti is uploading apport shortly for the switch over to only have it reporting to errors.ubuntu.com.   Please don't accept it in until we're ready to try for the release candidates.
<Laney> do the standard reject/accept trick on it then?
<skaet> Laney, yeah, I think that best
<skaet> will you do the honors, or do you want me to?
<Laney> feel free
<stgraber> btw, shouldn't we have done the same with base-files? I just noticed it was accepted (removing the "dev release" tag from lsb_release and similar tools)
<skaet> stgraber,  yes.  anything with timing issues around it should go to reject,  so accidents don't happen.
<Laney> not really the end of the world though
 * skaet nods
<cjwatson> Sigh, could really use ARM catching up a bit - this is hard to manage
<stgraber> cjwatson: if you have a minute, can you look at ifupdown?
<bdmurray> I've an upload of update-manager to precise-proposed that may help with diagnosing upgrade errors so it would be good to get it in precise.
<cjwatson> stgraber,jodh: oh, nice catch (ifupdown)
<jodh> cjwatson: thanks :)
<zul> can you reject the horizon please?
<ScottK> zul: Done.
<zul> thanks
<balloons> slangasek, can you add back the amd64, i386 isos for ubuntu and ubuntu server for beta1?
<balloons> slangasek, http://cdimage.ubuntu.com/releases/quantal/beta-1/ s missing these images and they are needed for upgrade testing from beta1 to rc
<cjwatson> You can't expect old images to hang around after the next milestone is released
<cjwatson> If your process assumes that then your process needs to be fixed
<balloons> cjwatson, I know.. but I'm looking and seeing that beta2 has been gutted also
<cjwatson> Err, no
<Laney> No. You need to look on releases.u.c
<cjwatson> desktop and server images live on releases.u.c
<balloons> http://releases.ubuntu.com/quantal/
<cjwatson> Yes
<balloons> this was a request by skaet to test an install of beta1 and upgrade to current
<cjwatson> You'll have to get it from somewhere else
<cjwatson> In any case, you'd only be able to do a beta-1 install now if it were networkless ...
<cjwatson> Otherwise it'd be a hybrid
<Laney> Yeah, not massively sure any such test results will be useful
<balloons> fair enough. ty cjwatson and Laney
<cjwatson> skaet: what are you trying to learn from this that you wouldn't learn from an upgrade from precise?
<xnox> balloons: if he had snapshots archive, it would be interesting to install from beta1 archive snapshot & dist-upgrade to -rc archive snapshot or final.
<xnox> balloons: but we don't have archive snapshots.
<cjwatson> If we want to do this kind of thing, we would need to plan ahead - e.g. archive test installs done at beta-1 time
<cjwatson> I plan to clean beta-1 entirely off cdimage fairly soon - it should have been done at beta-2, really
<slangasek> balloons: hrm, why is upgrade testing from beta1 to rc anything that you are focusing on?
<slangasek> ah, see that's answered in scrollback
<balloons> slangasek, we'll have to await skaet for that answer. I believe she wanted to check unity regressions
<jdstrand> infinity: iirc, you asked over the weekend about firefox 16 going to quantal-- I think it needs to go, but we need to test a bit more
<infinity> jdstrand: Check.
<infinity> jdstrand: At least it's all built now. ;)
<jdstrand> infinity: indeed-- was that the main bit you cared about? ie, can I just pocket copy to quantal after testing?
<cjwatson> infinity: firefox/quantal-proposed is still needs-build, actually
<infinity> cjwatson: 16, not 15.
<cjwatson> If that's what you mean ...
<jdstrand> these are in https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages
<cjwatson> Oh
<cjwatson> Does that include the changes in quantal-proposed?
<jdstrand> chrisccoulson: ^
<chrisccoulson> jdstrand, cjwatson, yeah, it's got all of the changes from quantal-proposed
<infinity> And more, apparently.
<infinity> Newer version of globalmenu again.
<cjwatson> Then it would be ideal to copy it sooner rather than later and supersede -proposed
<cjwatson> Since we're short of build time and there's no point in duplicate ten-hour builds
<jdstrand> I'm happy to do that. we need to test i386 a bit more though
<skaet> cjwatson, balloons,  sorry, was otp.   Want to make sure that those end users who have installed beta 1 don't have any big surprises esp. on i386/amd64.    We can release note if the only issues are on arm - but it would be good to know what they'll be seeing.
<infinity> I can just delete 15 from proposed if we definitely plan to copy 16.
<jdstrand> the security issues warrant it
<infinity> Yeah, that's why I was pushing for it.
<cjwatson> skaet: it just seems like an oddly specific thing to focus on - one would expect that for the most part any issues seen upgrading from 12.04 would be a superset
<infinity> Doesn't seem to make sense to wait and do a 0-day security release.
<jdstrand> no
<cjwatson> skaet: and I really don't want to go resurrecting beta-1 images when QA apparently doesn't already have copies
<jdstrand> this one is pretty important based on the upstream advisories
<infinity> jdstrand: What about thunderbird 16, has it been tested?
<jdstrand> not yet, I'll be testing that next
<infinity> jdstrand: (Copying that one would also get us out of doing two long builds)
<jdstrand> that one hasn't been tested at all btw. firefox/amd64 has been
 * jdstrand is working on these as we speak-- tbird will be a little while though
<infinity> jdstrand: Alrighty.
<skaet> cjwatson, ??  Why were the copies of the beta 1 images removed for desktop and server?   They are still there for cloud...http://cloud-images.ubuntu.com/releases/quantal/beta-1/
<skaet> infinity, ^ ?
<cjwatson> skaet: We always remove the previous milestone when publishing the next one.  We have done ever since long before you joined
<cjwatson> skaet: Cloud has an entirely separate publishing process that is nothing to do with me
<slangasek> cjwatson: so we're not expecting gcdx64.efi to work for netboot at this stage, right?  Given that /.disk/info will not exist
<cjwatson> There isn't even a defined location where previous versions of the ones that go on releases.ubuntu.com mightgo
<cjwatson> slangasek: No, that would need the Fedora fw_path patch I think
<slangasek> ok
<skaet> balloons, can you please test for beta2 forward then.
<utlemming> skaet: the policy for the cloud images is to provide all milestones indefinately. There was a revolt a bit back on about removing previous milestones.
<cjwatson> Right, that is definitely not the policy for cdimage and never has been
<balloons> skaet, lol. I originally announced it as beta2, re-sent the clarification 30 mins ago that we wanted beta1
<infinity> utlemming: That's a strange policy.
<infinity> utlemming: Interesting for QA bisection, somewhat confusing to present users with an option to use images that aren't based on release versions (and probably lack an obvious route to the matching source, too)
<cjwatson> I don't want to reinforce any notion that it's just as OK for people to install beta-1 as beta-2 and that we'll support them both.  errors.ubuntu.com indicates that we have a hard enough time getting users to upgrade as it is.
<utlemming> infinity: the bisection is part of why they are there. But if you look http://cloud-images.ubuntu.com/releases you'll see that we have a whole library of all the images that have been declared "release" or "milestone"
<skaet> utlemming, cjwatson - something to discuss at UDS.   cjwatson, understand your point, keeping them accessible without heroics, so we can set expectations of the experience a bit better seems prudent if we have the space.
<skaet> but they shouldn't be an easy default.
<cjwatson> We don't have the space to do it for any more than a short period of time.
<utlemming> for the cloud-images, space is easy -- we use the cloud
<skaet> cjwatson,  maybe doing what utlemming is doing might make some sense?
<infinity> utlemming: There's probably some GPL violation going on there.
<cjwatson> skaet: I'd rather not.
<cjwatson> I'm honestly quite happy with the way it is ...
<infinity> skaet: People installing from old media has always been a problem, any publishing of old media just encourages it.
<cjwatson> I don't want us to have to maintain a full library of all milestones.  We build a much larger family of images than cloud-images does.
<cjwatson> And for bisection, it's usually enough to bisect between packages, and they're in the librarian.
<skaet> cjwatson,  am not advocating all milestones,  only the betas
<cjwatson> I don't think they're particularly special for this.
<cjwatson> It took errors.ubuntu.com much longer to stop showing errors from beta-1 than it should have done
<skaet> yeah,  I noticed that too.
<cjwatson> A ubiquity crasher fixed in beta-2 was the top crasher there for well after beta-2 was released
<cjwatson> That says to me that *any* increase in visibility of beta-1 would be a mistake
 * ScottK agrees with cjwatson
<skaet> Understood.   It leaves us without a good way of understanding what will happen to the beta1 users when they try to update to the release candidate, but that is the tradeoff then.
<Daviey> cjwatson: surely it's only a violation if a user requests the source, and it isn't provided?  Isn't this just a case of having binaries hanging around?
<Daviey> (with the source available)
<cjwatson> Daviey: I didn't mention violations.
<Daviey> Ah, my eyes are too slow.. it was infinity.
<cjwatson> But we are equally without a good way of understanding what will happen to the beta-1 users who'd last updated a week after beta-1, or two weeks after beta-1, and then upgraded to rc
<cjwatson> We do not in general encourage users to upgrade only at milestones; we strongly encourage them to upgrade continuously over the network
<cjwatson> (e.g. by popping dialogs up in their faces)
<ScottK> If you run the development release and don't update for weeks at a time, I think you own whatever happens
<skaet> closer to rc,  less update churn,  less concern.   Its the earlier ones that were lingering I was concerned about.
<infinity> Daviey: As long as launchpad keeps every source package ever (a promise we've not made for !release versions, though it may currently be true), then yes, it's only a violation in spirit to not provide a source CD, not in letter.
<skaet> However,  its moot for now.    A possible UDS discussion.   I agree its not worth resurrecting the beta 1 images.
<infinity> I, like Colin, see no real reason to discuss this at UDS.
<cjwatson> Dear gtk+3.0/armel: please finish building so that the world's installable again there
<cjwatson> (OK, in -proposed)
<cjwatson> infinity: You don't happen to know how to clear the stuck pyorbit build on chort, do you?  See #launchpad-ops backlog
<cjwatson> (FWIW, we keep the *logs* of old image builds available essentially forever, so that developers can do archaeology)
<infinity> cjwatson: Oh, weird.
<stgraber> Laney: I noticed you reviewed bug 1064232, can you also review bug 1051162?
<ubot2> Launchpad bug 1064232 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for installer slideshow in Ubuntu 12.10" [High,Triaged] https://launchpad.net/bugs/1064232
<ubot2> Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162
<stgraber> I'd prefer to do a single upload before we freeze for good (with updated translations and all the FF that were approved)
 * ogra_ has an ubuntu-meta upload pending ... anyone else wanting any seed changes before i generate the package ?
<stgraber> I know I could review bug 1051162 myself, but I really don't have an opinion on it.
<ubot2> Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162
<infinity> stgraber: Seems reasonable to me.
<infinity> cjwatson: armel-rebuild is done, I'm guessing, from your text file?  (linux-linaro-* don't need rebuilding, obviously, and I assume there's a reason you skipped zope.interface?)
<Laney> stgraber: yeah, sure, if gnome remix guys are happy with it
<cjwatson> infinity: zope.interface is building/recently-built
<infinity> Ah-ha.  So, done.  Yay.
<cjwatson> infinity: So yeah, it's done modulo publisher
<Laney> Doesn't seem to have reviews though, so you might want to check
<cjwatson> Let queue reviewers rejoice
<jdstrand> infinity: so, as it turns out, tbird won't be released by upstream until tomorrow
<jdstrand> infinity: when is the latest we could push it into quantal?
<cjwatson> infinity: still building, actually, on heka
<ogra_> slackers
<doko> cjwatson, looking at http://www.freedesktop.org/software/systemd/man/os-release.html /etc/os-release for precise. VERSION_ID may not contain white space, so either set it to 12.04, or 12.04-LTS?
<skaet> jdstrand,  so 0 day SRU.
<infinity> jdstrand: Tomorrow's fine with me.
 * jdstrand got conflicting responses
<cjwatson> doko: you're the os-release guru :)
<skaet> infinity,  how will that interact with the translations landing?
<skaet> we need to have the release candidates on Thursday.
<jdstrand> tbird has its own locales...
<cjwatson> doko: personally I'd be inclined to suggest just 12.04 there, from the description, but I suppose it could go either way
<jdstrand> eg thunderbird-locale-zh-tw
<doko> cjwatson, well, I would keep it as 12.04 for consistency. the pretty names include  the LTS anyway
<doko> ok
<cjwatson> "mostly numeric"
<infinity> skaet: What jdstrand said.
<infinity> skaet: thunderbird and firefox translations are completely decoupled from langpacks.  If they weren't, our policy of new upstream releases in security would be a nightmare.
<skaet> infinity,  its the build time I'm worrying about.
<infinity> skaet: It's already built.
<jdstrand> infinity: so, I guess we can't kill the tbird builds... if upstream delays past tomorrow, then we'd need 15 for the images
<slangasek> bweh, why is os-release needing backported to 12.04?
<jdstrand> skaet: these are staged in the ubuntu-mozilla-security ppa, all built and ready
<skaet> jdstrand,  if the are already build, then we have more flexibility.
<infinity> jdstrand: Honestly, if you guys have it well-tested, I'm happy squeezing it in just about any time, as long as there are other image builds going too.  Waiting a week for a 0-day security release seems silly.
 * skaet would like to understand what has been tested though
<ogra_> slangasek, to make myunity not source /etc/lsb-release ?
<ogra_> :)
<infinity> jdstrand: (But we may end up building 15 anyway, it's just not high on the queue right now)
<jdstrand> infinity: ok-- my amd64 testing looks good overall-- we need a newer enigmail and I've yet to test lightning yet, but it is solid overall
<jdstrand> infinity: I'll let you decide on 15 then
<jdstrand> (to build or not to build)
<doko> slangasek, was a request in the report. I think it's harmless, and only useful for third party vendors
<jdstrand> infinity: we also have reports that i386 is good too, so 16 seems pretty solid
<jdstrand> I'll report back if I have an issues
<skaet> jdstrand, how is arm looking
<infinity> jdstrand: Alright, cool.  Push enigmail (and lightning, if required) to the PPA ASAP too, so we can just do a batch copy if/when we want to.
<jdstrand> it is built. I don't have arm machines
<infinity> skaet: It can't be any worse than 15 on ARM, which hasn't built yet, so hasn't been tested. :P
<jdstrand> that may change in the future, but we currently only test i386 and amd64
<slangasek> doko: are there specific third-party vendors that need this?  Otherwise, it doesn't seem to me to be a good use of time to SRU for - especially since it would need to be SRUed into all supported releases to have the intended effect
<doko> stgraber, did you leave DISTRIB_RELEASE untouched by intent for the .1 release?
<jdstrand> infinity: re pushing-- lightning is there, it needs testing. enigmail also happens to be there, but we need a newer. ack
<stgraber> doko: yes, IIRC the documentation says not to touch DISTRIB_RELEASE
 * jdstrand resumes testing
<stgraber> doko: "Upload a new base-files package to -proposed to bump the lsb_release description (example for 8.04.4). Do not change the DISTRIB_RELEASE value, which is used programmatically by third-party software." <- https://wiki.ubuntu.com/PointReleaseProcess
<cjwatson> OK.  component-mismatches clear (next publisher), priority-mismatches clear, architecture-mismatches clear (once my fso-frameworkd upload is reviewed, built, and published), NBS will be clear once epiphany-browser finishes on ARM, quantal_probs not clear but I think it's just lagging builds, quantal_outdate_all probably the next hitlist
<cjwatson> Getting there
<skaet> Thanks cjwatson
<cjwatson> doko: Yeah, we've had trouble in the past from changing DISTRIB_RELEASE so we don't
<doko> slangasek, no specific. I'll add patches for python and openjdk to use it. and at least the openjdk updates tend to go to older releases too
<infinity> cjwatson: _probs all looks like armhf lag to me, yeah.  I was about to work on outdate_all as well.
<cjwatson> Be my guest.  EOD is somewhere in the near future for me.
<doko> stgraber, cjwatson: ok, doing the same with VERSION_ID
<slangasek> doko: that doesn't sound like third-party to me if you're talking about doing it in Ubuntu
<slangasek> nothing in Ubuntu should rely on /etc/os-release
<cjwatson> Wouldn't mind clearing some of those ruby build failures for real.
<infinity> cjwatson: Couldn't we just use copy tricks to fix fso-frameworkd?
<cjwatson> Not sure.  I preferred to keep it simple, really.
<infinity> cjwatson: Actually, is fixing it even necessary?
<cjwatson> It's only a five-minute build on one architecture.
<cjwatson> infinity: It shows up on architecture-mismatches, so I wanted to clear it properly.
<infinity> cjwatson: arch-mismatches is whining because the arch:all binary only exists on armel, but the arch:any binary only exists on armel...
<cjwatson> And it has some rdepends.
<doko> slangasek, not relying, just using it. platform.linux_distribution() is part of the standard library
<cjwatson> The arch:all binary should exist on armel, though, shouldn't it?
<infinity> cjwatson: It does.
<cjwatson> Right now it doesn't (well, not at the right version)
<doko> for openjdk, it's just used to identify the OS in core dumps
<infinity> cjwatson: At least, that's how I read it?
<cjwatson> It's an old version, according to rmadison
<cjwatson> I was trying to clear it out of outdate_all last week and I think I made a mistake
<cjwatson> (Nothing really reports on partial NBS so it has to be cleared by hand)
<infinity> Hrm.
<pitti> hello all
<infinity> Will rmadison actually show if :all exists in more than one version on different arches, or just pick one to report on?
<pitti> I just noticed that I forgot to sync udisks2 yesterday (I uploaded it to experimental on Friday, but it didn't get imported into LP in time)
<cjwatson> I think it collects them.
<pitti> it updates from our git snapshot to the official 2.0.0 release; it's got some nontrivial changes, but I'm happy to answer any question about it
<cjwatson> Hmm
<cjwatson> It's an architecture: all from a source not built on i386
<pitti> I've been running it on my machine since Thursday, and it has quite an exhaustive test coverage
<cjwatson> So actually there's no way to build it in our build system
<cjwatson> The Debian maintainer presumably does a -b build on armel ...
<infinity> Right, there isn't.
<cjwatson> So yeah, reject that then.  I'll just have to remove the arch all binary, and think about its rdepends
<doko> anyway, afk now
<infinity> cjwatson: Or drop fso-frameworkd-gta* from the packaging, so it's pure arch:all.
<cjwatson> That sounds like it requires thought.
<zyga> hi
<cjwatson> infinity: If you understand it can I convince you to do something about it? ;-)
<infinity> cjwatson: Yeah, sure.
<cjwatson> Awesome.
<infinity> cjwatson: It just means dropping some armel-only other bits too, which doesn't seem like a huge loss.
 * cjwatson rejects his upload
 * zyga is here for https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
<zyga> if anyone has questions -please ping me about it-
<infinity> (making "!x86 all" builds work might be a nice goal, though)
<cjwatson> Ooh, yay, NBS cleared.
 * infinity cheers.
<infinity> And it only took two weeks to build epiphany and do it.
<infinity> Oh, hey, only one week.  I guess I'm having temporal issues.
<infinity> Copied gtk+3.0 to release.
<skaet> :)
<jdstrand> skaet, infinity: fyi, enigmail is fixed, lightning works, and tbird testing shows it works fine. we are only waiting on upstream now
<jdstrand> (well, and enigmail to build in the ppa, but that won't take long)
<jdstrand> chrisccoulson: thanks ^
<skaet> jdstrand.  ok.
<infinity> jdstrand: In that case, are you okay with us killing all the tbird/ffox quantal 15 quantal builds and assuming we'll get 16 for sure in the next day or three?
<jdstrand> infinity: I think so, yes
<infinity> Right, then.  Removing ffox from proposed, and setting about killing some things to free up buildd time.
<ogasawara> skaet, infinity: I've uploaded the kernel (no ABI bump).  It just needs approval in the queue.  After discussion, we decided to wait to include the patches for bug 1063061 and handle it as an SRU instead.  So this upload is intended to fix the bugs I mentioned earlier, ie bug 1061599, bug 1021471, bug 1030233, and bug 717970
<ubot2> Launchpad bug 1063061 in linux "please backport support for EFI vars > 1KB" [Medium,In progress] https://launchpad.net/bugs/1063061
<ubot2> Launchpad bug 1061599 in linux "beagle: omap3: usb is dead" [Undecided,Fix committed] https://launchpad.net/bugs/1061599
<ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
<ubot2> Launchpad bug 1030233 in linux "not have bluetooth usb 0489:e046 Foxconn / Hon Hai" [Medium,Fix committed] https://launchpad.net/bugs/1030233
<ubot2> Launchpad bug 717970 in linux "After sleep, key presses get lost and trackpad is jittery" [High,Fix committed] https://launchpad.net/bugs/717970
<skaet> ogasawara, ack
<skaet> infinity,  you able to review it through?
<infinity> skaet: Aye.
<skaet> infinity, thanks.
<infinity> ogasawara: Any idea if ti-omap4 and armadaxp will get a final rebase to this version as well?
<ogasawara> infinity: we can likely get ti-omap4 rebased and uploaded.  I'll need to nudge ike about armadaxp.
<infinity> ogasawara: Both would be lovely, so they land in the release d-i.
<ogasawara> infinity: ack
<infinity> apw: lowlatency rebase, if you please, and a reminder about getting me access to that tree. ;)
<apw> infinity, waiting on your acceptance :)
 * infinity peers at the queue.
<infinity> Lies and subterfuge.
<infinity> Or you mean waiting on me reviewing and accepting linux?
<infinity> I suppose that's fair. :P
<infinity> I'm waiting on LP to provide me a useful diff, cause I'm tethering on 3G and have no urge to download the whole source package.
<ogra_> infinity, hmm. you added the touch for the oem-config enabling to live-build ... somehow that touched file isnt in the tarball (nothing that needs to be solved now ... just noticed it)
<infinity> ogra_: I suspect you're quoting distant past.  This relates to ac100 tarballs?
<ogra_> yeah
<ogra_> i'm abusing tehm for another project atm
<ogra_> and noticed the file isnt there
<ogra_> doesnt affect ac100 since that checks for it and touched it if its no available
<ogra_> *touches
<infinity> ...
<infinity> Then I'm not sure why live-build would have done it at all?
<infinity> Cause jasper did it too, didn't it?
<ogra_> yep
<roadmr> Hello! Is it still OK to upload a last-minute version of checkbox? (has udisks2 support which is rather important). https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
<infinity> ogra_: I see no mention of oem-config in live-build at all, I think you may be mistaken. :)
<ogra_> but we discussed it in the past and both aggreed it should be done in live-build instead
<ogra_> err, livecd-rootfs indeed
<infinity> ogra_: We may have discussed it, it clearly never happened.
<infinity> Oh, indeed.
<roadmr> our beloved sponsor is reviewing it but wanted to know if it's Ok to do the upload
<ogra_> sorry, mixing package names here
<infinity> ogra_: Although, I don't see it there either.
<infinity> ogra_: Unless you mean the config/oem-config-preinstalled bits?
<ogra_> infinity, exactly that
<infinity> ogra_: Which isn't about the tarball at all.
<zyga> hey, can we please get an exception for a pending merge request for checkbox
<infinity> ogra_: That's touching a file in the build directory, so we can know what mode we're in across invocations, that's all.
<infinity> ogra_: Which then allowed me to do things like set up a sane sources.list.
<ogra_> hmm
<infinity> ogra_: In fact, that's all that was used for, it looks like.
<ogra_> k, i thought i saw it touching the file in the tarball somewhere
 * ogra_ makes a note to fix that for R
<infinity> ogra_: In that same 'if [ -f config/oem-config-preinstalled ]; then' block, you could certainly also do the /var enabling magic, to get it out of initrd hack land.
<ogra_> yeah
<ogra_> nothing for quantal though
<ogra_> and for my other project i repack the tarball anyway
<cjwatson> Laney: I'm rather tempted to start removing FTBFS out-of-date haskell binaries on armhf.  What do you think?
<Laney> yes
<infinity> cjwatson: If we had the CPU time right now, I'd suggest one more give-back.
<cjwatson> Is there reason to believe it'd help?
<infinity> Nope!
<cjwatson> (Of course, we can always give-back after removal too)
<Laney> I believe it to be a genuine ghc bug
<infinity> Except that if they worked before, it's odd that they're broken now.
<infinity> Oh, if GHC is genuinely FUBAR, then screw it.  Remove away.
<infinity> That's not getting fixed this week.
<cjwatson> Laney: Do you have a reference or anything?  It'd be nice to be able to quote something in removal comments, even if it's speculative
<Laney> no :/
<Laney> I'll file a bug with "HEY IT'S BROKEN LOL"
<Laney> that we can use as a placeholder
<ogra_> Laney, cant you follow standards ?
<infinity> ogasawara: You reintroduced all the .gitignore files...
<ogra_> the proper wording is "doesn't work!!!11!"
<Laney> THAT'S IT, I'M MOVING TO SCHEME
<infinity> ogasawara: Or were those in your orig? :P
<ogasawara> infinity: they're in the orig
<ogra_> lol
<infinity> D'oh.  Kay.
<ogra_> git is so ignorant
<ogasawara> infinity: apw and I intend to sit down at UDS and sort out the file deletion issue we're seeing when packaging
<cjwatson> I'm seriously tempted to consolidate testing{,-ports}/quantal_outdate_all.txt
<cjwatson> Due to Architecture: all handling it's a lot clearer if you can see both at once
<infinity> cjwatson: Consolidating testing in general probably needs to happen anyway.
<Laney> cjwatson: do you see any similar problems on armel?
<cjwatson> Laney: haskell-chell (my current example) built on armel but not armhf, although I haven't compared ghc versions
<Laney> should be the same, I'm just wondering if all of the segfaults are armhf
<cjwatson> infinity: the whole thing is a bit less clear because quantal_probs.html is used as a green light in things like jenkins tests, Rick's morning web browsing, etc.
<cjwatson> infinity: but nobody except archive nerds looks at quantal_outdate_all.txt
<infinity> cjwatson: Maybe, yeah.  I dunno.  I think a goal of having _probs be unprobby on all arches isn't so awful anyway.
<cjwatson> Post-CI/britney/whatever I think that'd be good.
<infinity> Right.
<cjwatson> At the moment it's likely to be a lot of noise and increased stress due to perceived breakage in ports
<infinity> Auto-britney was kinda where I was going with "it needs to not have a ports split anymore soon".
<cjwatson> Yeah, that's like a couple of lines at the top anyway.
<cjwatson> I expect you'd be using a different instance.
<infinity> ogasawara: Accepting, after manual noise filtering.
<ogasawara> infinity: thanks
<ogasawara> apw: ^^
<apw> ack
<cjwatson> Laney: haskell-chart failed on armel with a segfault
<cjwatson> haskell-file-embed/armel with SIGILL (like haskell-chell/armhf)
<infinity> SIGILL?
<cjwatson> haskell-yesod-form/armel with SIGSEGV
<infinity> That's specially.
<infinity> special, too.
<cjwatson> Seems a bit of a mix, really.
<cjwatson> And oddly random.
 * Laney eyes trac
<Laney> "preview" appears to have submitted
<Laney> http://hackage.haskell.org/trac/ghc/ticket/7316
<Laney> cjwatson: ^ (mostly a placeholder)
<cjwatson> OK, http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate_all.txt is all-arches now, and .../testing-ports/quantal_outdate_all.txt redirects to it
<cjwatson> Laney: thanks
<roadmr> hi, sorry to pester again, I know everybody is busy :/ is it ok to upload checkbox 0.14.9? merge here https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
<cjwatson> roadmr: You should upload so that it can be reviewed in the queue
<roadmr> cjwatson: ok, will upload then. Thanks!
<cjwatson> This isn't me granting an FFe, just saying that's how we do reviews
<cyphermox> cjwatson: ah, there was a misunderstanding
<cyphermox> I was curious as to whether this kind of change warranted a FFe, I'm on the line for this one
<cyphermox> (I'm working on the merge and preparing the package)
<skaet> roadmr, it does require an FFE.   There's a new feature in it.    Can you please make sure you're following the FFE process, and especially document the testing done on it so far.
<roadmr> skaet: sure, I'll do that in the linked bug
<cyphermox> skaet: thanks;
<skaet> roadmr, ok.  please paste the link of the bug here, and make sure its targetted to quantal, and release team subscribed so it can be commented as the review happens.
<cjwatson> Heh, I just finished reviewing the udisks2 sync
<cjwatson> (And would have accepted it too)
<infinity> cjwatson: This is what you get for working past your EOD.
<infinity> cjwatson: Hands off my queue and go have a pint? :P
<skaet> jdstrand,  Daviey - what is the current status of openstack-resource-agents that's still in New?
 * jdstrand has done nothing with it
<cjwatson> Trying to get a baby to sleep - reviewing actually isn't a bad activity
<zyga> cjwatson:
<zyga> cjwatson: \o/
<infinity> cjwatson: Especially if you read the diff out loud?
<zyga> haha
<cjwatson> Speech synthesis, man.  Have you no love of gadgetry?
<infinity> cjwatson: Like those creepy voices could ever soothe a child.
<infinity> cjwatson: You need to make the diff into a story.
<skaet> :)
<cjwatson> "Once upon a time, there was a datadir that was equal to dot"
<cjwatson> I think it lacks a compelling sense of characterisation
<jdstrand> heh
<infinity> cjwatson: "And then the header was included, allowing the prototype to be defined correctly, and the compiler no longer complained about implicit declaration.  Can you say implicit?  ihm plih sit."
 * skaet giggles
<roadmr> skaet: https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1016035 I just updated the description and the build/install/upgrade logs are there too
<ubot2> Ubuntu bug 1016035 in checkbox "Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
<infinity> If I ever reproduce and my child's first words are "implicit declaration" or "buffer overflow" or something, I suspect I would have failed as a parent.
<infinity> And yet, also succeeded somehow.
<cjwatson> my mother once told some students in her charge - this was while as a teacher in um 1970s or so Northern Ireland - that they could say the Sinn FÃ©in slogan if and only if they could spell it
<cjwatson> sorry, not sure that was totally apposite, you just reminded me of it somehow :)
<apw> infinity, low-latency in the queue for you
<zyga> infinity: you can avoid the 'failed as a partent' part if your children can fix the buffer overflows ;-)
 * skaet a bit confused about what is so hard to spell about the slogan after looking it up on wikipedia, but *shrug*
<cjwatson> my stepson, whose father's a train geek, had his first word as "engine"
<cjwatson> skaet: oh, there are a couple.  I'm referring to https://en.wikipedia.org/wiki/Tiocfaidh_Ã¡r_lÃ¡
<ScottK> When I lived in Ireland (Dublin) I learned a few words of Irish.  The only way I ever learned to spell any word was to fully memorize it.  I was never able to divine any rules.
<cjwatson> It's actually more regular than English, just totally different.
<infinity> "Oh the English came, and they jumbled up the letters, but those brave Irish boys turned them into a word..."
<ScottK> Right.  I didn't say there weren't any, just none I could figure out.
<skaet> cjwatson,  yeah, that one makes the story make more sense.
<skaet> :)
<cjwatson> (BTW not endorsing the political sentiments of the above wikipedia page ...)
<infinity> apw: Reviewificating.
<skaet> fair 'nuf
 * cjwatson starts in on nuking OOD haskell builds then
<apw> infinity, linux-signed for linux in the queue
<Daviey> zul: Am i being daft.. is bug 1050359 also covered in the nova upload?
<ubot2> Launchpad bug 1050359 in nova "Tests fail on 32bit machines (_get_hash_str is platform dependent)" [Medium,Fix committed] https://launchpad.net/bugs/1050359
<zul> Daviey: fixed in a previous upload
<Daviey> -ubuntu-fix-32-64-bit-iss.patch
<Daviey> +ubuntu/ubuntu-fix-32-64-bit-iss.patch
<zul> Daviey:  i just moved the patch to the ubuntu directory so when we do SRUs we can just drop the patch
<knome> ugh, we need to get bug 1063453 through
<ubot2> Launchpad bug 1063453 in xubuntu-docs "references to 3rd-party intellectual property need to be displayed with trademark" [Low,Fix committed] https://launchpad.net/bugs/1063453
<skaet> Daviey, ^ what's the story on openstack-resource-agents - what's left, or should I just reject it from quantal?
 * skaet notes its been in NEW for over a week at this point.
<knome> skaet, can you give some opinion about that ^ so i can mentally prepare myself for things i need to do?
<Daviey> skaet: Good question, i've been tentatively thinking of reviewing it.  I'd quite like it in Quantal.. but it's not required.
<skaet> Daviey,  your call then.   either in or reject today please then.
<Daviey> (Good chance it will be main next cycle, and it's nice to expose stuff for a cycle first... right?)
<skaet> knome,  looking
<knome> skaet, thanks
<stgraber> rsalveti, ogra_, infinity: is the xf86-video-omap in the queue a request of one of you? (it's a sync so I can't know how to poke about it)
<rsalveti> stgraber: tjaalton pushed it, it's a minor upstream bug-fix only release, which I tested already
<ara> skaet, any chances to get the ffe for checkbox? or we should just give up
<tjaalton> stgraber: yeah, I uploaded it
<stgraber> tjaalton, rsalveti: ok. The delta at http://launchpadlibrarian.net/119246857/xf86-video-omap_0.4.0-0ubuntu2_0.4.1-1.diff.gz isn't terribily readable, but based on the changelog only, it's showing new features (xrandr rotation) that'd require a FFe
<skaet> ara,  if its not absolutely critical,  prefer not to introduce more churn.   If it is critical,  please give detailed summary of testing done so far, and why it is not introducing risk by including it.
 * skaet --> appt.   bbl
<stgraber> rejected xf86-video-omap for now, we can always get it back from rejected if needed
<ara> skaet, it is kind of critical, as checkbox is on the cd, and currently, all storage tests are broken
<ara> skaet, we will include the information
<rsalveti> stgraber: indeed, the rotation is a new feature there
<Daviey> xpra: accepting, dig into the debian RC bug.. Looks reasonable, and fixes buggy version.
<rsalveti> tjaalton: which is also not critical for us, so don't think it's worthy having the FFe for it
<rsalveti> tjaalton: the other fixes are useful though
<Daviey> barry: woooaaahhh.. mediathekview looks pretty extensive change.. bug 889117 doesn't seem very extensive.. what is the stauts?
<ubot2> Launchpad bug 889117 in mediathekview "new version of mediathekview -needs packaging" [Undecided,Confirmed] https://launchpad.net/bugs/889117
<barry> Daviey: i was looking at bug 1064451.  there are no rev-deps and it's universe so it seemed harmless, but i could be convinced otherwise
<ubot2> Launchpad bug 1064451 in mediathekview "Sync mediathekview 3.0.0-1 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1064451
<ara> stgraber, hey, could you have a look to FFe of https://bugs.launchpad.net/checkbox/+bug/1016035, please?
<ubot2> Ubuntu bug 1016035 in checkbox "[FFE] Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
<ara> we are losing our sponsor :)
<ara> or anybody else in the release team
<ara> Daviey, ?
<zyga> cjwatson: still up?
<zyga> stgraber: or you maybe?
<zyga> pitti: ^^ ?
<zyga> anyone that saw me during the last few years ;)
<zyga> please help
<Daviey> ara: heya
<ara> Daviey, trying to get a FFe from the release team for https://bugs.launchpad.net/checkbox/+bug/1016035,
<ubot2> Ubuntu bug 1016035 in checkbox "[FFE] Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
<ara> Daviey, it'd be great if you could have a look
<Daviey> ara: Can you get it into the queue for review there please?
<ara> Daviey, trying that, but the sponsor wouldn't want, let's try gain
<ara> again
<zyga> Daviey, ara: what does that mean, we need to dput the package to the review queue?
<ara> zyga, it means that even if cyphermox upload it (yes, with dput), it'll go to a queue
<zyga> ara: right, and isn't that the current goal?
<Daviey> zyga: yes, the archive is in frozen state meaning each upload is wedged pending review.  Where it will be accepted or rejected
<zyga> ok
<Daviey> ara: I'm trying to grok the changes, and it's too much for me to work out.  You are quite confident this is well tested and regression free?
<Daviey> ara: This wouldn't impact any other flavours would it?
<ara> Daviey, no, just Ubuntu
<Daviey> And I can't imagine this is covered in documentation, right?
<ara> Daviey, it is not part of Ubuntu Docs
<stgraber> ara: wrong, edubuntu ships it too
<jdstrand> infinity: firefox 16 is good. shall I copy now?
<stgraber> (as edubuntu ships all of ubuntu)
<Daviey> stgraber: Do you want to take this review? :)
<stgraber> Daviey: no
<Daviey> bah
<zyga> Daviey: note, there's a non-squashed version
<zyga> Daviey: if you want to read that instead
<infinity> jdstrand: Please do.
<stgraber> Daviey: I had a look at the change quickly and it's too big for me to review and not something I know much about (udisk2), so as it's, I'd just reject on the basis that it's way too late and that I prefer to stick with known limitations rather than get new problems.
<zyga> stgraber: known broken better than fixed by upstream but large delta?
<Daviey> ara: Impact on checkbox-cli ?
<stgraber> zyga: yep, because we know what's broken vs potentially getting something even more broken that we just don't know about yet
<ScottK> Since none of the udisk tests work, the downside risk seems likely low.
<zyga> stgraber: how can it be more broken if previous version just did not function anymore
<ara> Daviey, it impacts the scripts and tests, not the different interfaces, so, yes it impacts checkbox-cli as well
<zyga> stgraber: (anymore == since udisks2 became used)
<stgraber> zyga: yeah, that's why I didn't reject it myself. I'm still fine if someone from the release team actually goes through the code and confirms that it's perfectly contained to the tests that aren't currently working
 * zyga is sorry about being emotional, I'm sure that every developer wants their package in the repo at this late hour and it's a very difficult job to review all that code and be the one to make the call to reject or include it
<Daviey> zyga: passion is good :)
<knome> Daviey, the fruit?
<Daviey> yah
<knome> don't like that
<Daviey> cyphermox: Can you get it in the queue real soon?
<jdstrand> infinity: copied
<cyphermox> Daviey: yes, I'll get it now
<zyga> Daviey: the package is uploaded into the queue
<zyga> cyphermox: thanks a lot!
<cyphermox> Daviey: queuebot will notice it any second
<slangasek> hrm, is python2.7 broken?
<slangasek> https://launchpadlibrarian.net/119288447/buildlog_ubuntu-quantal-amd64.update-notifier_0.125_FAILEDTOBUILD.txt.gz
<slangasek> that didn't happen when I build-tested locally
<ScottK> That does look concerning.
<slangasek> probably on my side, since python2.7 hasn't revved lately
<cjwatson> slangasek: missing build-dep on python, so you only have python-minimal, I suspect
<slangasek> ah, doh
<slangasek> thanks
<cjwatson> you might be using slightly fatter chroots
<slangasek> yeah :/
<Daviey> slangasek: Are you using pbuilder or sbuild?  if sbuild, are they just mk-sbuild generated, or something fancier ?
<slangasek> Daviey: I have a comparatively-rich chroot that I use for development
<slangasek> it has things like 'bzr-builddeb' installed :P
<Daviey> ahh, ok :)
<Daviey> (last cycle i hit an issue i couldn't reproduce outside the archive.. it did turn out to be a differing chroot)
<slangasek> funny how turning on the test suite at build time turns up a bunch of modules that are missing from the package runtime deps
<stgraber> ScottK: updated the madwimax bug, not sure how I missed that one last time I pushed a bunch of network SRUs...
<cjwatson> grr, pycuda, you weren't supposed to fail again
<cjwatson> apw: linux-signed still trying to download from quantal rather than -proposed, apparently
<cjwatson> of course we could always source-copy and not care, but ...
<apw> cjwatson, that doesn't make any sense, it searches all of the connected pockets
<cjwatson> (or indeed copy linux once it builds everywhere, build linux-signed, copy that)
<cjwatson> I'll look at the source later and see if I spot anything obvious
<cjwatson> I think sleep may call for now
<Daviey> stgraber: So, this checkbox upload.. It's been explained to me such that it is required to give the same testing coverage as 12.04..  The team are confident it is regression free, and if it did - they are committed to super fast resolution.  They are also on the hook for resolving issues it introduces to other flavours (ubuntu server ships the cli variant)
<Daviey> Based on this, I am going to accept it, unless you scream otherwise.
<apw> cjwatson, yeah too tired to make any sense now, will have to look at it in the mornign
<apw> cjwatson, isn't the pool the same place regardless of the pocket the version is from ?
<stgraber> Daviey: I'm fine with that. I just wanted someone to actually confirm that the change only affects the code that wasn't working as it wasn't obvious from the attachments to the FFe bug.
<ogra_> apw, the pool is, the Packages file with the meta info isnt
<apw> ogra_, right and so for the signed files there is no difference in location regardless of which pcoket it is in then
<apw> cjwatson, those files are not in the pool at all
<infinity> apw:
<infinity> Downloading http://ftpmaster.internal/ubuntu/dists/quantal/main/uefi/linux-amd64/3.5.0-17.28/flavours ...
<infinity> apw: ^--- That's not the pool.
<apw> right
<infinity> apw: And that needs to look for quantal-proposed.
<apw> oh hmmm
<apw> then i just have to guess
<apw> ok
<apw> we can do that
<infinity> apw: Since it's looking for an exact version, that's fine.
<apw> cjwatson, ok i know what is wrong here, will get it sorted and uploaded
<apw> infinity, thanks ...
<apw> infinity, yeah indeed.  i don't think i can tell if i shoud check proposed or not
<infinity> apw: You can just test $series, $series-updates, $series-proposed in that order, and should be good to go.
<apw> infinity, ack thanks
<infinity> apw: Oh, and $series-security, on the off chance it's a security update before getting copied to updates.
<infinity> apw: But yeah, since you're doing exact version checks, and no version can ever exist in the archive twice (even in history, including removals), checking all the pockets is fine.
<infinity> apw: Heck, you could even make it backport-friendly by checking them last. :P
<infinity> apw: I think we'll leave that kernel in proposed intentionally until you're sure you've sorted pocket handling, since it'll become critical post-release.
<apw> infinity, yes please do, i'll do all of that :)
<RAOF> bg
<slangasek> cjwatson: initial shim-signed package (re)uploaded; can you review when it hits the queue?
 * skaet --> back
<skaet> Thanks Daviey for handling the checkbox
<Daviey> sbeattie: Hey, can you check that the best fix for bug 1061879 really is shifting from Depends to Recommends?  I suspect that isn't enough.. But it's certainly no worse than the current situation... So happy to accept it.
<ubot2> Launchpad bug 1061879 in apparmor "please have apparmor-notify Recommends libnotify-bin instead of Depends" [Medium,Triaged] https://launchpad.net/bugs/1061879
<apw> infinity, whats the backport pocket called, -backport or -backports
 * skaet sees unapproved as empty,   new with only the shim.   nice.  :)
<Daviey> On that note, i'm going to bed before it fills up again.
<Daviey> o/
 * Laney looks forward to the final freeze mail
<skaet> good night Daviey,   thanks.
 * skaet goes to send it out.
<sbeattie> Daviey: yeah, will do. Also, g'night!
<infinity> apw: -backports.
<skaet> Laney,  its sent now.   Should be making its way through the mail servers.
<Laney> groovy
<phillw> skaet: I've only just checked my email and see the one from Julian...  He would not ask for such a thing so late on. Your views on the FFe?
<skaet> phillw,  bug number again please?    lots going through.
<phillw> *Julien*
<phillw> skaet: https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1043129
<ubot2> Ubuntu bug 1043129 in lubuntu-artwork "[UIFe] Black borders on some active controls" [Undecided,Fix committed]
<phillw> Yes, i know I'm a PITA :D
<skaet> phillw,  Julien writes:  I currently can't include the fixed theme in 12.10 because there is too much changes, with too much potential regression or change in the UI.  I'm not seeing anything else contrary in the bug,  that gives confidence.
<skaet> that its been tested, and won't likely introduce more regressions than issues it sorts.
<skaet> Feel free to put more data in the bug if it exists.   This sort of change is probably best for 13.04 when it can get a lot more testing.
<phillw> skaet: http://pastebin.com/emtpgLDF
<phillw> you were emailed it (I saw you on the list of recpients, of which I was the other).
<skaet> phillw,  ok,  have to catch up with the email queue yet - mostly focusing on IRC today.
<phillw> skaet: It is, from my memory, very, very rare for Julien to make a plea. Basically, he and the artwork are stuck, (I see lots of little bugs flying about). Please help him & lubuntu on this one.
<skaet> phillw,  ok,  if Julien is will to revert and take the risk, we'll let it in.
<skaet> s/will/willing/
<phillw> skaet: It seems that he has no choice. It's not ideal, it's not perfect but it's the best that can be done :(
<phillw> him coming back from his 2 weeks away to recharge his batteries ill, and quite ill has really messed things up. :(
<phillw> skaet: thanks for that, I now owe you another favour! :D
<skaet> phillw,  please work to get it uploaded now in next couple of hours, and we'll call it even.
<phillw> skaet: anyone here know how to explain what I need to do?
<skaet> infinity,  can you help phillw?
<phillw> oh, heck, I'm so sorry infinity, you must really hate me for the stuff I ask for help on,
<infinity> phillw: All you need to do is work with your packager to get it uploaded.  I have nothing to review unless someone uploads a package.
<phillw> infinity: Â lubuntu-artwork0.34~ppa1Julien LavergneÂ (5 hours ago)
<phillw> what is the next step?
<phillw> He is an MOYU, I'm a mere mortal :)
<phillw> *MOTU*
<doko> better become immortal if you want to survive
<phillw> doko: I'm a QA person... we are the people who 'bug' you:)
<phillw> infinity: do you want to take this to -testing so as not to 'flame' the room?
<apw> infinity, ok i hope i have fixed linux-signed, if the diff looks sane (and it is tested locally) then if you could poke it through, if not reject it and i'll try again in the AM
#ubuntu-release 2012-10-10
<slangasek> skaet: so I'm starting to go through https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/CommonInfrastructure and clean it up a bit; what are the criteria for the bugs listed in the kernel section?  Because they seem quite scattershot to me, and many of the ones listed had never been confirmed on quantal
<slangasek> ("scattershot" in that they seem to be bugs of varying importance, I'm not sure why these are the kernel bugs that wound up in the release notes)
<skaet> slangasek,  I took them from the list that ogasawara reports on each week.   I expected they'd be pruned down but figured I'd leave it to her.
<skaet> slangasek, as you clean up, feel free to remove the status info I included from the blueprint scans.
<doko_> slangasek, https://launchpadlibrarian.net/119290440/buildlog_ubuntu-quantal-armel.update-notifier_0.125_FAILEDTOBUILD.txt.gz expected?
<infinity> doko_: Fixed in 0.126
<doko_> ohh, thanks
<stgraber> Riddell: http://paste.ubuntu.com/1270326/ <- seems like the langpack mess isn't quite solved yet
<slangasek> skaet: ah; I wouldn't have expected there to be any correlation between the list of worked / release-relevant bugs and the ones we would want to release note.  Ok, I'll let Leann take it from there.
<slangasek> skaet: as for blueprints, yes, I've cleaned up most of those; there are still a few that need followed through on
<skaet> slangasek, ack.
<slangasek> reuploading shim-signed, because we now have a signed shim \o/
<skaet> :)
<skaet> nice news to hear.
<skaet> stgraber, highvoltage - https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/Edubuntu - could you please review and have updated before Thursday?
<pitti> zyga: I am online now
<pitti> Daviey, stgraber: thanks for reviewing checkbox; we really need to move away from the old udisks 1.x stuff, and checkbox is the second-last package in main holding it
<pitti> zyga: nice to see you got it in, thanks muchly!
<Daviey> pitti: woot
<tkamppeter> pitti, cjwatson, yesterday I have uploaded the fix for bug 1014852. Will this get into Quantal?
<ubot2> Launchpad bug 1014852 in pyppd "openprinting-ppds crashed with UnicodeEncodeError in ls(): 'ascii' codec can't encode character '\ufffd' in position 92: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/1014852
<pitti> tkamppeter: I'm not on the release team any more
<pitti> but simple bug fixes have a good chance to make it, I think
<Daviey> tkamppeter: I don't see it in the queue?
<Daviey> ogra_: Hey, do you fancy looking into why LiveFS failed to build for server ompa/omap4?
<Daviey> armhf
<cjwatson> looked like a checksum error on some package or other iirc, which is usually transient
<tkamppeter> Daviey, it should be in quantal-proposed, and someone accepted it there.
<cjwatson> tkamppeter: I've copied foomatic-db to quantal now
<cjwatson> infinity: any luck with fso-frameworkd?
<mvo> is http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/revision/2553 acceptable at this point ? or SRU? its nr12 on errors.u.c for 12.10
<apw> mvo, the distro entry in that changlog is borked
<seb128> mvo, UNRELEASEDquantal
<seb128> what apw said
<cjwatson> mvo: Looks fine to me
<mvo> I know
<mvo> thanks, I will unbork/upload
<cjwatson> MIR folks: we need bug 1064899 looked at as a matter of urgency
<ubot2> Launchpad bug 1064899 in shim-signed "[MIR] shim, shim-signed" [Critical,New] https://launchpad.net/bugs/1064899
 * cjwatson copies libreoffice, finally
<tkamppeter> cjwatson, thanks.
<cjwatson> doko_,didrocks: ^- see my MIR above for shim/shim-signed (1064899)
<cjwatson> close to being blocked on this
<didrocks> cjwatson: looking
<didrocks> cjwatson: I guess the link to amd64 only and having shim only built for this arch is on purpose?
<cjwatson> didrocks: Yes - we're only attempting to support UEFI at all on amd64 at the moment
<cjwatson> (Which may have to change in the future, if we don't manage to avoid it, but that's not today's headache)
<didrocks> cjwatson: ok, of course, I'm not competent enough seeing the rush to do a full code review, will trust you on it :)
<cjwatson> I believe the security-sensitive bits are basically copied from Tianocore
<didrocks> cjwatson: hum, what about debian/copyright for shim-signed? From what I understand, it's a binary efi version we got signed from Microsoft, shouldn't that be mentionned in it?
<cjwatson> Actually Microsoft only supplied the signature
<cjwatson> Which I don't believe is copyrightable
<didrocks> ok, so no code change at all?
<cjwatson> No, it just has to be in a separate package because the process involves building shim, submitting through a Microsoft website, and then you get the sig back
<cjwatson> We've verified independently that the binaries match
<cjwatson> (cf. 'make check' there)
<didrocks> cjwatson: ok, good, just checking some small things and it should be ok :)
<didrocks> cjwatson: just for my personal knowledge, does Built-Using has any meaning?
<didrocks> I never saw it before
<cjwatson> It's a recent thing in Debian policy 3.9.4
<cjwatson> It's intended to influence garbage-collection in the archive
<cjwatson> Launchpad doesn't implement it yet; not even sure if the Debian archive does
<didrocks> well, the case of having a binary content built and slightely modified from another package is not widespread I guess :)
<didrocks> interesting :)
<cjwatson> There are a number of cases where it's relevant; consider debian-installer, say
<cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using
 * didrocks looks
<cjwatson> For now, we're just being excessively pedantic by including it, but hopefully eventually it'll actually be useful
<didrocks> cjwatson: shim-signed is enough on its own, right? on the targeted machine. it's the binary content + the signature in one file? (we don't need shim, hence the built-using instead of dep)
<cjwatson> shim-signed Build-Depends: shim
<cjwatson> But target machines don't need shim,no
<didrocks> yeah, it was what I meant :)
<cjwatson> We need both in main due to the build-dep
<didrocks> indeed
<cjwatson> But yeah, it includes the signature, it's not detached
<cjwatson> (sbattach(1) can manipulate this)
<didrocks> oh, interesting :)
<didrocks> ok, both looks good to me (apart from the code that I can't look in that rush, even not sure to be competent enough), do you want me to do the promotion?
<RAOF> Oooh, that was nice and quick.
<cjwatson> didrocks: If you want to just leave it approved for now, I can promote it a little later when I'm ready to upload debian-installer with a build-dep on it
<Laney> Ah, you are here!
<Laney> RAOF: I couldn't see that the patches are forwarded - are they?
<cjwatson> That way there won't be noise in component-mismatches in the meantime
<didrocks> cjwatson: sure, acked on the bug then :)
<cjwatson> Thanks!
<didrocks> yw ;)
<RAOF> Laney: I'm actually upstreamish on colord; the simple one is forwarded, the complicated one is... complicated.
<RAOF> Laney: colord-sane has been entirely removed in git, because libsane is a steaming pile of terrible. The complicated patch should work around the vagries of libsane, and once errors.ubuntu.com gives me confidence that it does, I'll re-introduce sane support upstream with that approach.
<Laney> Hm, alright
<Laney> Is it infeasible to fix libsane itself?
<RAOF> I think it is, yes. Partially because there are plugins involved, and I believe some are proprietary.
<RAOF> And the plugin interface is part of the problem.
<didrocks> Laney: just uploaded a small and simple fix for the video lens as it seems to start getting duplicates, maybe you want to consider it for finale (basically just type Ã and you get a crash) ^
<Laney> didrocks: OK, I can't reproduce that myself (perhaps because that has no results here?) but will look
<didrocks> Laney: yeah, it's when you have matching results
<didrocks> thanks :)
<Laney> unfortunate we got no webapp upload
<didrocks> yeah, let's see once ken is around
<didrocks> it's still really flacky for me
<didrocks> like not working yesterday at all but gmail
<didrocks> today, with no updates, working on youtube, linuxfr and launchpad
<didrocks> thanks Laney
<Laney> np
<Riddell> stgraber: what were you doing to get those langpack errors?
<Riddell> ah we still have the -kde-xx-base packages
<cjwatson> ^- please review - bug noticed while working on debian-installer, critical path for secure boot images
<cjwatson> Daviey,Laney: ^- sorry to ask directly but I need to unblock myself on this fairly urgently
<Laney> cjwatson: right
<Laney> build-efi-images is only called on amd64?
<cjwatson> Yes
<Laney> done
<cjwatson> thanks!
<cjwatson> end in sight.  or at least being able to test things for real.
<mdeslaur> I've got a security update for bind9 in quantal, can I upload it, or do I wait for a 0-day USN?
<cjwatson> I'd say upload it
<Daviey> cjwatson: Sorry, i was eating.
<cjwatson> Direct to quantal should be fine; no arch skew problems that I can see
<cjwatson> Daviey: np, Laney dealt with it
<mdeslaur> cjwatson: thanks
<doko> cjwatson, would you approve a libffi upload only touching arm64 files?
<cjwatson> Probably
<cjwatson> Oh no, grub2 failed to build
<skaet> :(
<cjwatson> Sigh, local .mtoolsrc made mtools laxer
<cjwatson> infinity: ^- oh, hah, I didn't notice fso-* in the queue earlier
<cjwatson> thanks for that
<psivaa> probably a very low priority one atm but just in case it has not been noticed, the precise alternate images seem oversized
<Daviey> psivaa: Yeah, i don't think anyone will look at that for the next 2 weeks
<psivaa> Daviey, yep understand, thanks
<cjwatson> What was wrong with libffi?
<cjwatson> Aha
<doko> sorry, added ppc64 symbol files in the second
<cjwatson> doko: Build-tested on any current architectures?
<doko> amd64 and i386
<cjwatson> (The only non-arm64/ppc64 changes here are testsuite, so I think that's all that could plausibly go rong)
<cjwatson> *wrong
<cjwatson> OK, thanks
<cjwatson> ^- please review - should actually work this time
 * cjwatson goes for lunch
<doko> cjwatson, skaet: the grub2 change looks plausible. can't accept myself
<highvoltage> skaet: will do
<jdstrand> cjwatson: per discussions from yesterday, thunderbird 16/quantal would be copied today (or later). I just got the go ahead from upstream that this is the final version and want to copy into quantal. is now an ok time?
<jdstrand> cjwatson: (this was discussed with inifinity and skaet. it's all built and just needs a copy)
<cjwatson> jdstrand: Now's fine
<jdstrand> thanks
<jdstrand> done
<skaet> doko, will do.  Thanks for reviewing.
<skaet> thanks jdstrand
<jdstrand> skaet: ah, didn't think you were here yet. np! :)
<stgraber> Riddell: sudo apt-get install language-pack-kde-.*
<Riddell> stgraber: gosh I never knew you could do that with apt
<Riddell> stgraber: anyway the -base packages should be really removed now
<stgraber> Riddell: ok, thanks. I'll retry after the next publisher run
<Riddell> stgraber: seems to work now
<doko> stgraber, while the buildds are idle, would it be possible to review and accept gcc-4.6 for precise? if if that is built, gccgo-4.7?
<cjwatson> I brought us down to two armel builders to get the test rebuild done faster, but we can always steal one back if need be.
<stgraber> doko: I'm not in -sru
<doko> stgraber, ahh, ok
<Daviey> hmm, anyone else seen "supported_versions: WARNING: Unknown Ubuntu release: 12.10" ?
<Daviey> http://pb.daviey.com/kvPM/
<cjwatson> I *think* that's from postgresql-common
<cjwatson> Maybe
<Laney> yeah
<Laney> knows about 12.10 here though
<Daviey> google seems to agree
<infinity> cjwatson: Were you going to release that d-i staged in bzr, or did you have more changes to go in first?
<skaet> cjwatson, infinity - ok to now accept that apport that's being held in reject queue now,  so that the next set of images (candidates hopefully ;) ) will have it.
<cjwatson> infinity: Waiting for next publisher run, then grub2-signed, then build+publish, then I'll upload it
<cjwatson> infinity: Otherwise I'll just have to rebuild again
<cjwatson> skaet: Fine by me
<skaet> k, doing
<infinity> cjwatson: Check, and check.
<infinity> cjwatson: I was going to take a stab at fixing bug #1040393, but that requires actual testing to make sure I don't blow up the images in the process, so maybe I'll hold off for SRU time.
<ubot2> Launchpad bug 1040393 in debian-installer "omap netboot partition too small for flash-kernel backup procedure" [Undecided,New] https://launchpad.net/bugs/1040393
<cjwatson> Your call, I never understood that stuff :)
<cjwatson> (Or wanted to)
<infinity> cjwatson: Well, the fix is simple, it's making sure it actually boots and installs after fiddling with it that takes a bit of time. ;)
<infinity> cjwatson: Maybe I'll play locally today, and if I get nowhere, postpone it.
<skaet> infinity, can you handle disabling the kerneloops for the candidates?
<infinity> skaet: I'm sure I have the technology to do that.
<skaet> :)  thanks infinity
<infinity> skaet: Ooooor, it's already been disabled. :P
<Laney> yeah, I was going to say that IIRC it's been off for half the cycle already
<infinity> (As in, it's been disabled for all of Q, except for a 3 day period when it wasn't)
<cjwatson> Oh, bah, we missed our publisher slot again
<cjwatson> So I'll upload this grub2-signed, but it'll need half an hour before it can build
<cjwatson> (It has tight build-deps so it doesn't matter if somebody feels like accepting it earlier)
<mvo> sorry for the last minute upload of python-apt but it would be great if that could go in, the new auth.py module breaks puchases in quantal right now :/
<mvo> (fix should be pretty obvious fortunately)
<Daviey> mvo: You also refreshed the mirrors list for python-apt?
<cjwatson> the pre-build hook does that
<cjwatson> it's safer to let it, ime :)
<Daviey> ahh
<Daviey> well sounds wise to have a later mirror listing anyway!
<mvo> its automatic
<infinity> Accepted.
<mvo> yeah :)
<infinity> mvo: ^
<mvo> thanks \o/
<infinity> And so did someone else. :)
<Daviey> I did.
<mvo> thanks to both of you!
<Daviey> cjwatson: grub2-signed.. you aren't waiting on anything for it, are you?
<cjwatson> Daviey: A publisher run; although it's OK to accept it early, since it has tight build-deps
<Daviey> Yeah, that is what i spotted.
<plars> psivaa: is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1065034 reproducible every time?
<ubot2> Ubuntu bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [Undecided,New]
<plars> xnox: ^ might be worth taking a look at
<xnox> plars: yeah. reading.
<psivaa> plars, yes on vm's it is
<plars> psivaa: have you tried it on hardware?
<psivaa> plars, yes only on mac and there this is not occurring, this is only occurring in vm's
<xnox> psivaa: it's interesting, i'll look into it.
<psivaa> xnox, plars thanks
<bdmurray> infinity: is there anything we can do about reducing the 7 day period though?
<infinity> bdmurray: Verify it faster, and ask nicely.
<infinity> bdmurray: Including re-verifying the bug that was fixed in the previous release, since it never passed through to updates.
<infinity> bdmurray: If you verify both bugs are well and truly fixed and poke me, we'll fudge dates. :P
<bdmurray> infinity: sounds good thanks!
<cjwatson> ^- next stage in secure boot critical path
<cjwatson> debian-installer, that is
<cjwatson> once that's built it's a one-liner to arrange for it to be on images
 * cjwatson reviews libqt4pas
<cjwatson> doko: Have you test-built this libqt4pas sync on powerpc?
<doko> cjwatson, no armhf only, but succeeded on debian unstable
<cjwatson> doko: I think I'd better try it, then - I can't read the symbols diff well enough to make sure
<doko> thanks
<cjwatson> doko: I think I might have to give up and remove aspectc++ and reverse-deps on powerpc, unless you have any better ideas
<cjwatson> I couldn't get BenC's suggested -mlong-double-64 trick to work
<doko> sounds fine. really need to figure out my access to davis again
<cjwatson> Can somebody review debian-installer, please?
<stgraber> cjwatson: I'll take it
<cjwatson> davis just works for me ...
<cjwatson> stgraber: thanks
<stgraber> cjwatson: ok, I won't pretend to have followed all the EFI/apt magic in my head, but it looks reasonable. accepted :)
<cjwatson> stgraber: Yeah, slangasek understands 2/3 of it and I understand the other 2/3 ;-)
<cjwatson> But it's been boot-tested in VMs at least
<slangasek> haha
<cjwatson> (That's actually almost literally true, because the extra 1/3 lives in grub2 ...)
<Daviey> Surely combined you understand more than the problem dictates ? :)  there is a remainder of 1/3? </pedant>
<slangasek> stgraber: pfft, you didn't push to the bzr branch for your nfs-utils upload :(
 * cjwatson replaces Daviey with a very small equation
<stgraber> slangasek: doh... sorry for that... I need to hack something on top of dput to make sure I push before I upload...
<slangasek> stgraber: I'm mangling the branch now so that I get my commit history back :)
<stgraber> slangasek: ok. I checked and I don't have the branch around anymore, otherwise I'd have checked that it matches the wanted history and used --overwrite
<slangasek> stgraber: bzr import-dsc && bzr push --overwrite done here
<gilir> is there someone available to review lubuntu-artwork ? The full story is on bug 1043129, but I can make a quick summary if it's needed :-)
<ubot2> Launchpad bug 1043129 in lubuntu-artwork "[UIFe] Black borders on some active controls" [Undecided,Fix committed] https://launchpad.net/bugs/1043129
<plars> xnox: I seem to recall a bug about it being impossible to remove physical partitions, and thus, encrypted volumes when doing manual partitioning, still seems to be the case
<plars> xnox: is that one of them that got lumped in with https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1042647 ?
<ubot2> Ubuntu bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New]
<xnox> plars: well revert does something sensible but results in even more confusing bug 1056744
<ubot2> Launchpad bug 1056744 in ubiquity "Ubiquity crashes after creating an encrypted partition manually" [Medium,Confirmed] https://launchpad.net/bugs/1056744
<xnox> plars: read description, title is a bit incomplete.
<plars> xnox: not as far as I can tell, reverting leaves me with /dev/mapper/sdaN_crypt volume
<xnox> plars: yeah. that's a bug I'm woring on fixing right now.
<xnox> plars: it's inconsistent.
<plars> xnox: ok, so you have a bug open for that already then?
<plars> wouldn't happen to have the bug# would you?
<xnox> that is my analysis/cause for bug 1056744 i.e. revert does something odd after partman-crypto has been activated.
<ubot2> Launchpad bug 1056744 in ubiquity "Ubiquity crashes after creating an encrypted partition manually" [Medium,Confirmed] https://launchpad.net/bugs/1056744
<xnox> either it should not leave /dev/mapper/sdaN_crypt around or it should fail to revert properly.
<plars> thanks xnox !
<cjwatson> doko: No, this libqt4pas sync fails on powerpc: http://paste.ubuntu.com/1271463/
<cjwatson> doko: I'm going to reject this as I don't think we should trade one FTBFS for another at this point; please could you upload a merge instead?
<doko> cjwatson, ok, later tonight, now afk
<cjwatson> thanks
<infinity> cjwatson: If you'd accepted the sync, it'd be painless to snag the log output on all 5 arches and bump the symbols.
<cjwatson> infinity: feel free if you know the runes
<cjwatson> and are prepared to chase it
<infinity> pke-kde-tools has a no-brainder "symbol merge from build logs" thingee.  Works great for people who insist on tracking C++ symbols.
<infinity> I'll do it.
 * infinity goes to accept.
<infinity> no-brainer, too.  Unlike typing.
<infinity> Oh, can't resurrect rejected syncs, right.
 * infinity resyncs.
<infinity> Oh.
<infinity> Except that this is just a new packaging update?
<infinity> Right.
<infinity> I'll merge. :P
<zyga> hey,I just tried the current alternate i386 iso and grub-pc cannot be installed at the end, has anyone reported this?
<xnox> zyga: which alternate?
<cjwatson> Not that I've seen
<infinity> Or, no.  I won't merge.  I'll use your pastebin. :P
<cjwatson> But yeah, alternate kind of dead
<cjwatson> Unless you mean some non-Ubuntu product
<cjwatson> Er, flavour
<xnox> no kubuntu/ubuntu alternates. (if there are any, they are stale)
<zyga> xnox: define which? do you want the checksum?
<cjwatson> zyga: Which URL, please?
<cjwatson> I don't want the checksum
<zyga> er, alternate
<cjwatson> Which URL, pleae
<cjwatson> *please
<zyga> it was daily, let me dig it up
<cjwatson> There are/were several
<zyga> http://cdimage.ubuntu.com/daily/current/quantal-alternate-i386.iso
<zyga> ah
<cjwatson> zyga: That's a month old and no longer supported - look at the timestamp
<xnox> cjwatson: purge it =)
<zyga> hmm
<cjwatson> I should probably nuke it at some point
<zyga> indeed
<cjwatson> Use server or netboot as appropriate
<zyga> that's confusing
<xnox> why?
<zyga> so where is the most current daily build now?
<cjwatson> It's gone now *sniff*
<cjwatson> zyga: alternate no longer exists
<cjwatson> what are you trying to do?
<zyga> ah, right
<cjwatson> daily-live for desktop; ubuntu-server/daily for server; netboot for netboot
<zyga> cjwatson: deploy a small VM to debug some things with multiple nics
<zyga> right, I want the latter than
<cjwatson> then server or netboot was probably more appropriate anyway, yeah
<zyga> thanks for the tip, I now recall alternate going away
<zyga> cjwatson: while we're on the topic, I'm interested in using those new network interface naming schemes
<zyga> cjwatson: do you know if it is possible to emulate that in a VM
<zyga> cjwatson: I'm looking for docs on the topic, some dell/redhad docs claim I need smbios 2.6
<cjwatson> I'm not sure
<cjwatson> Sorry
<cjwatson> Daviey,slangasek: doing an amd64-only server build to see how/if it works with secure boot
<cjwatson> And I'll try an amd64-only desktop build as well while I'm testing this.
<skaet> cjwatson, infinity - we're going to need to keep the arm builders clear later today/early tomorrow for a security fix landing that needs to go in release candidate
<cjwatson> How many packages?
<cjwatson> Source packages, I mean
<skaet> 11 hour window
<cjwatson> If it's just one, then we have enough builders that that won't be a problem.  It'll just pre-empt something in the test rebuild.
<cjwatson> (Even if we accept a fair bit of other stuff, we have 10 builders that aren't doing anything desperately long-running right now.
<cjwatson> )
<micahg> cjwatson: 10
<Daviey> cjwatson: works for me
<cjwatson> micahg: 10 source packages? *blink* Would appreciate details in /msg
<cjwatson> Anyway, can't keep them very much clearer than they are right now, really
<Daviey> rbasak (or anyone): Do you know why why maas-enlist precise was rejected?
<rbasak> Daviey: I wasn't aware of this, but I do know that roaksoax re-uploaded with a second fix (the IPMI enlistment stuff) after my fix (the subarch enlistment stuff). Is the rejection of the first upload what you're seeing? I still see a maas-enlist in the queue.
<Daviey> rbasak: i suppose it was, thanks
<balloons> skaet, btw, feedback on the ARM upgrades from beta1 is it does not work.. the desktop won't boot, or boots to pure graphics corruption
<cjwatson> How about ARM upgrades from precise?
<balloons> if we wish to diagnose, I have a dd'd image of the issue
<balloons> the dailies are installing usable images however
<balloons> cjwatson, I don't know :-) That's a more interesting case
<balloons> upgrading these things takes FOREVER
<slangasek> beta1?  weren't we still missing the binary video drivers at beta1?
<zyga> so, grub-pc failed to install on current daily server i386 iso
<zyga> cjwatson: ^^
<cjwatson> zyga: logs plz
<cjwatson> or a bug
<zyga> cjwatson: coming right up
<cjwatson> well, preferably in a bug :)
<skaet> ^ accepted  based on discussions with lubuntu yesterday that this was least risk path forward.
<skaet> balloons,  thanks for finding that out.   was worried something like that might be the case.     Please open a bug number, so we can track things there, and see if we can figure out best path forward.
 * skaet thinks likely to be a release note as long as dailies installing usable images
<skaet> balloons,  has anyone tried from beta2?
<cjwatson> skaet: I think we'll be OK, but I've worked out some timings with micahg and dropped doko a note in case we need to kill running GCC builds (I hope not).  Either infinity or I will rebalance builders as needed.
<skaet> thanks cjwatson.  :)
<zyga> cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1065163
<ubot2> Ubuntu bug 1065163 in grub2 "grub-pc fails to install at the end of installation from server iso" [Undecided,New]
<cjwatson> zyga: OK.  Dinnertime now - I'll look later
<zyga> k
<cjwatson> zyga: Er, no logs
<cjwatson> zyga: Can you get at the contents of the installed filesystem?
<cjwatson> zyga: I need /var/log/installer/syslog and /var/log/installer/partman - that is, if they've been copied
<zyga> trying to
<cjwatson> If not, I need /var/log/syslog and /var/log/partman from *before* rebooting the installer
<cjwatson> 'anna-install openssh-client-udeb' from tty2 and you can scp them out
<zyga> cjwatson: there's no /var/log/installer or did you mean from /target ?
<cjwatson> from /target
<cjwatson> but if you're in the installer environment, just grab /var/log/{syslog,partman} directly
<zyga> cjwatson: still not there /target/var/log/
<zyga> ok
<cjwatson> right, anyway, dinner
<balloons> slangasek, yes we were missing drivers @ beta1.. the installed system is really painful to use
<balloons> skaet, no one from beta2
<slangasek> blah, whose idea was it to make 'eject' of a USB disk cause the partition mapping to disappear from the kernel?
<infinity> Because "eject" != "umount"?
<highvoltage> it's been like that since... forever though
<slangasek> infinity: "eject" is the only option being shown
<slangasek> which means I can't, from the GUI, unmount the automounted installer image that I want to overwrite
<infinity> slangasek: Yeah, there used to be two options that were (mostly) redundant, except for that one difference, but I'm pretty sure that was crazy user-unfriendly.
<slangasek> right, so now it's just crazy-user unfriendly
<infinity> slangasek: I suspect the assumption is "people who want to umount but not make the device go away probably also know how to use command-lines for their weird use-case".
<slangasek> infinity: why would I *ever* care about making the device go away
<slangasek> I don't understand why this option is presented for a USB stick in the first place
<infinity> (Used to be "Eject" and "safely Remove" which was all kinds of confusing)
<infinity> slangasek: So, your contention is that when they removed one of the two options, they removed the wrong one?  Maybe.
<infinity> slangasek: Though, completely making it go away prevents other processes from remounting behind your back, or otherwise mucking with it.
<infinity> Which fits the "it's actually safe to pull it, honest" message.
<slangasek> infinity: for the USB disk case, yes, I think the wrong one is removed
<slangasek> ok, why am I getting an email that's telling me the exact opposite of http://people.canonical.com/~ubuntu-archive/component-mismatches.txt regarding the linux-ti-omap4 binary packages?
<infinity> Both are lies, ignore them. :P
<slangasek> infinity: is this your doing? :)
<infinity> No, it's just what happens when d-i and seeds and new kernel ABIs all interact slightly out of sync.
<slangasek> it is?  I wouldn't expect anything to say "these need promoted to main" as part of an ABI transition
<slangasek> which is what the mail says
<infinity> Hrm.  I don't have that mail.  Only the 212 to universe one.
<infinity> Which is a lie, cause it really means "delete please".
<infinity> Maybe I deleted the earlier mail.
<slangasek> yes, I know how to interpret "to universe"
<infinity> And it's entirely possible that whoever did the binary NEW missed the main promotion in the same breath.
<slangasek> these were 212
<slangasek> not 213
<slangasek> and it said "to main", not "to universe"
<stgraber> slangasek, cjwatson: bug 1065180
<ubot2> Launchpad bug 1065180 in grub2 "Wrong EFI boot entry on system with secure boot" [Undecided,New] https://launchpad.net/bugs/1065180
<infinity> Oh, you've had 212 going both directions?
<slangasek> infinity: the only mail I saw was "to main", which was the opposite of c-m; so maybe a bug in the mail-generating script
<infinity> That sounds more like someone demoted 212 instead of deleting it, but the seeds hadn't changed yet, and hilarity ensued.  Or something.
<slangasek> right
<infinity> Oh!
<infinity> I didn't read the subject!
<infinity> Silly me.
<infinity> I just read the body, which matched the file.
<infinity> Reading.  Hard.
<infinity> Need lunch.
<slangasek> so if that's the case, could people please stop moving things around in components before they show up on c-m?
<infinity> So, yeah, it could also just be the diffing script being daft.
 * skaet contemplating some lunch as well.
<infinity> Anyhow, old binaries removed now, it can stop annoying us. :P
<slangasek> stgraber: could you attach the output of 'sh -x /usr/sbin/grub-install --uefi-secure-boot'?
<stgraber> slangasek: done. http://paste.ubuntu.com/1271664/
<slangasek> stgraber: attach :)
<infinity> slangasek: Want to accept that lsb before you lose context and actually have to review it all over again? ;)
<stgraber> slangasek: I pasted the link on the LP bug too. Do we actually care about it being an attachment vs URL to a paste?
<slangasek> stgraber: yes
<slangasek> because paste.ubuntu.com is a PITA for grepping
<infinity> And, more importantly, pastes timeout and you lose context in old bugs.
<infinity> (which drives me BATTY)
<slangasek> also that
<slangasek> infinity: accepted
<stgraber> slangasek: alright, attached
<slangasek> stgraber: thanks :)
<cjwatson> infinity: although as it happens paste.ubuntu.com never times out (so I'm told), though other pastebins do
<infinity> cjwatson: Oh, curious.  Not that I'd count on that forever.
 * stgraber uses experimental pbget with paste.ubuntu.com support (pbget <URL> | grep ... is actually much easier than going to LP grab the attachment)
<slangasek> stgraber: so the grub-install output shows efibootmgr being called with the right option (-l \EFI\ubuntu\shimx64.efi), but this doesn't match the output you showed from efibootmgr after the fact
<slangasek> stgraber: is something else calling efibootmgr out from under us?
<slangasek> stgraber: and, does 'efibootmgr --verbose' currently show the right entry?
<stgraber> slangasek: hmm, it does now... that's odd. All I ran since it last returned the wrong thing was update-grub and grub-install --uefi-secure-boot
<stgraber> so it might have been that you need grub-install --uefi-secure-boot + update-grub to get it to update to the right value?
<slangasek> stgraber: no, the update-grub doesn't matter for this
<slangasek> and I don't see any bugs in grub-install
<stgraber> oh, hold on a sec, I think I know what happened, it's right around the time unattended-upgrades applies updates...
<slangasek> so I'm wondering what else could have happened *after* you ran grub-install --uefi-secure-boot to cause the entry to be overwritten with the wrong value
<slangasek> oh, hah
<slangasek> there you go then ;)
<slangasek> mind updating the bug and closing it as invalid?
<stgraber> yep, will do with a note to "reboot immediately after running grub-install --uefi-secure-boot" otherwise the entry will get overwritten whenever grub/shim updates
<stgraber> alright, let's see if that machine boots now :)
<TheLordOfTime> hate to be annoying, but... when's this being migrated to the repos for precise from -proposed?
<TheLordOfTime> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
<ubot2> Ubuntu bug 997978 in qemu-kvm "KVM images lose connectivity with bridged network" [High,Fix committed]
<stgraber> slangasek, cjwatson: so, different problem now :)
<micahg> TheLordOfTime: 7 days is up today, so probably soonish
<infinity> TheLordOfTime: Vaguely around nowish.  It only just hit 7 days.
<stgraber> the machine boots and gets the now usual "Image failed to verify with *ACCESS DENIED*". Hitting enter at that point gets me into grub, trying to boot something fails.
<stgraber> hmm, wondering if I have a signed kernel, /me reboots into setup mode again
<TheLordOfTime> micahg, infinity, its one of those "high priority" issues for an organization i work with, so... sorry for another prod about that one :P
<slangasek> stgraber: you shouldn't need a signed kernel
<slangasek> stgraber: why are you getting "Image failed to verify"?
<infinity> TheLordOfTime: When I say "nowish", I mean "now".
<TheLordOfTime> micahg, infinity, its one of those "high priority" issues for an organization i work with, so... sorry for another prod about that one :P:P
<infinity> TheLordOfTime: As in, just released.
<TheLordOfTime> oops
 * TheLordOfTime kicks xchat
<slangasek> stgraber: also, why does hitting enter get you to grub?!
<TheLordOfTime> infinity, nice.
<zyga> cjwatson: hey, I've added the logs that you've requested
<stgraber> slangasek: no idea ;)
<stgraber> firmwares don't seem terribly good at logging
<stgraber> so yeah, I'm getting: firmware splash => boot menu => select ubuntu => get access denied => hit enter => get to grub menu => try to boot anything hangs (purple screen)
<slangasek> stgraber: no, I mean, if it actually failed to verify the signature, it's a violation of the Win8 cert requirements for it to let you boot by pressing enter
<slangasek> oh, so you only get access denied after the grub boot menu?
<stgraber> nah, the "select ubuntu" part there means select the ubuntu entry in the EFI boot menu
<slangasek> hmm
<stgraber> only entry in grub that doesn't hang is the "System setup" entry which reboots the laptop and get me into the config screen
<stgraber> switched back to setup mode and it boots fine (first time I actually use the shim to boot)
<slangasek> hmm
<stgraber> if you want something even weirder :) I installed linux-signed-generic and it now boots
<stgraber> still showing the access denied error though
<stgraber> and the variable in /sys/firmware is now set to 1 as expected
 * stgraber reboots to confirm that the same unsigned kernel still won't boot
<slangasek> I'm not sure why you would be seeing this; I'm definitely able to boot an unsigned kernel here in secureboot mode
<stgraber> well, I confirmed that an unsigned kernel won't boot here. I edited the Ubuntu entry and removed .efi.signed from the kernel filename and hit F10 and it hangs
<stgraber> now, how can we debug that mess? (considering that dropping splash vt.handoff and adding verbose doesn't give me anything)
<psivaa> xnox, i see that the personal files are destroyed when i use live session path, in the Reinstall option, but the straight install does not destroy them
<TheLordOfTime> infinity, what's the time-to-build for stuff just moved from proposed to -updates (or similarly)?
<TheLordOfTime> or is it just a copy from proposed to whatever it goes to (probably -updates for precise)
<infinity> TheLordOfTime: It's just a copy, if it rebuilt, all the previous testing would be pointless.
<TheLordOfTime> you never know, so it never hurts to ask ;P
<stgraber> slangasek: I'll try to boot the Windows 8 install media to check that I'm not getting that weird access denied message with it
<stgraber> but I'd think Lenovo would have tested that as it's a production firmware I'm using...
<infinity> cjwatson: Should be a new lbqt4pas landing in the queue soon with sane symbols for armel, armhf, and powerpc (the latter being based on your build, so I hope your chroot was sane).
<slangasek> hmm, anyone else seeing firefox plugins broken by unresolved reference to libxul.so in /usr/lib/firefox/plugin-container ?
<slangasek> oh, ignore that
<slangasek> that's just me invoking it wrong from the commandline when debugging
<mdeslaur> can I upload a moin security fix?
 * skaet --> appt, bbl
<slangasek> stgraber: you said that the 'access denied' message came only after the grub menu, though?
<slangasek> not sure how that can be the firmware's fault
<stgraber> slangasek: no, that error shows up right before grub, possibly somewhere between the shim and grub2, no idea
<slangasek> ah, hmm
<stgraber> slangasek: though when trying to boot grub directly I get the access denied and then the laptop just gives me a blank screen
<slangasek> if you try to boot shim directly, do you get the access denied message?
<stgraber> so going through the shim certainly triggers a different behaviour that then lets me boot (but only a signed kernel)
<stgraber> slangasek: how do I do that?
<slangasek> perhaps the 'access denied' is in response to the firmware trying to boot some other image before it tries your configured one
<slangasek> stgraber: ah, well, every UEFI UI is different, so... I have no idea :P
<slangasek> stgraber: however, the ref platform I have here has a 'boot from file' option
<slangasek> which was what I had in mind
<slangasek> or if not that, then at least a boot menu to explicitly select the boot device?
<xnox> psivaa: please give me a little more context or a bug # .
<stgraber> yeah, I have a boot menu on F12 to choose what to boot, but it only lets me choose EFI boot entries
<stgraber> so I guess I need to add a couple of test entries with efibootmgr
<slangasek> stgraber: ok, if you explicitly choose Ubuntu from F12, do you still get the message?
<stgraber> yeah
<slangasek> right
<slangasek> so I'll consider that Not My Problem for now
<slangasek> I'm more concerned about the kernels not booting
<slangasek> does your firmware give you a UI for loading keys into KEK?
<slangasek> because effectively, for debugging a boot failure under SB, you're going to want direct control of being able to sign test images
<stgraber> not that I could find. All I can do is wipe all the entries or reload the Windows ones
<slangasek> ok
<stgraber> slangasek: do we have a signed CD image yet? I could try to write that to USB and see if I get a different result
<slangasek> stgraber: yes, the current daily server and desktop images use the signed bootloader
<slangasek> the server one gives me a garbled framebuffer; I'm struggling to sync the desktop one now to test
<stgraber> ok, grabbing the desktop image here
<Laney> ah, fun, /me tries too
<slangasek> Laney: you have UEFI?
<Laney> think so, checking
<Laney> I just got this hardware last week, so here's hoping
<stgraber> you may need a firmware update. I got my laptop last month and the UEFI firmware didn't have secure boot, I had to reflash to get the win8-compliant version with secureboot
<Laney> I have "UEFI/Legacy boot"
<slangasek> that's no guarantee of SecureBoot availability; but all the same you mind find it worth testing whether the images boot for you in UEFI mode
<Laney> yeah
<stgraber> Laney: no secureboot/windows8 option hidden in some security menu?
<Laney> dunno, I'm just looking at the manual
<Laney> dding the iso now
<stgraber> gah, cdimage is slow today, I'm just getting 700kB/s out of it...
 * xnox can't see any updates from my OEM, but they are Latvian so I am not holding my breath. Last time around it did not boot the CD in UEFI mode will try usb.
<psivaa> xnox, sorry dont worry that was a confusion on my part, ignore that
<xnox> psivaa: ok =) got me worried there for a second.
 * stgraber reboots
<cjwatson> stgraber: I'm a bit confused by you marking your own grub-install bug invalid; the --uefi-secure-boot option is not supposed to be required, and if grub is reinstalled - even by unattended-upgrades - while the system is in SB mode, it should install a signed version
<slangasek> cjwatson: he wasn't booted under SB mode when this happened
<cjwatson> stgraber: the grub-install trace you uploaded shows that the system was not ...
<slangasek> he was bootstrapping his way to it :)
<cjwatson> yeah, that
<cjwatson> ah, OK, I thought this was a fresh install
<psivaa> xnox, coincidently i had used the same username for ubiquity and different ones for for live session re-installs and that made me suspect the installer :)
<xnox> psivaa: =) I see.
<stgraber> slangasek: ok, so my machine is at least very consistent in its behavior :) botting the ISO from USB I'm getting the access denied, then once I select OK, I'm getting into grub and from there any attempt to boot a kernel hangs
<stgraber> (assuming that the kernel on the image isn't signed, that means I'm getting the exact same behaviour as my installed system)
<cjwatson> oh, yeah, the kernel on the image isn't signed
<cjwatson> blast, we're going to need to fix that
<stgraber> cjwatson: is it normal for grub to just hang on an unsigned kernel? (slangasek said earlier that grub should still happily boot an unsigned kernel)
<cjwatson> it isn't normal
<slangasek> cjwatson: in the meantime, I've successfully booted your latest desktop image to a desktop with secureboot enabled
<cjwatson> neat
<Daviey> \o/
<cjwatson> slangasek: do you think that using a signed kernel on the image (and hence efi handoff) would help with your efifb woes?
<slangasek> cjwatson: no
<cjwatson> at least efifb is built in so it shouldn't require d-i modifications to handle that ... hopefully
<cjwatson> slangasek: but we ought to do it anyway, yes?
<slangasek> cjwatson: I think the desktop CD works because it's switching to inteldrmfb, and it's possible the server image isn't
<cjwatson> slangasek: IIRC inteldrmfb is modular, so that would be quite plausible
<slangasek> cjwatson: yeah, I think we ought to get the signed kernels into the images
<cjwatson> isn't the efifb stride configurable with boot parameters?
<cjwatson> (not to mention that grub is supposed to handle configuring it properly ...)
<slangasek> is it configurable?  dunno
<slangasek> this was a kernel bug that mjg59 and pjones were hacking on during plugfest, fwiw
<slangasek> the fix must not have made the round trip
<slangasek> cjwatson: do you think d-i *should* be loading the same fb modules that get used in the desktop installer?
<cjwatson> I would hesitate to state that as a general principle
<slangasek> from the "dropping alternate" thread, I get the impression that not using the kms drivers may be a feature for some users
<Laney> aha, firmware update â secure boot options
<stgraber> slangasek: I copied the win8 installer bootloader in /boot/efi and added a boot entry, that one loads without the weird access denied error, though all it gets me is a blank screen (makes sense as I only copied the loader and not the actual install media)
<stgraber> slangasek: are you aware of any secureboot test binaries that are signed by microsoft? I'd like to check that it's really only the shim+grub2 that's triggering that weirdness
<slangasek> stgraber: uh, there is one, but I forget what it's called and where it lives; try pinging manjo
<slangasek> stgraber: he should know
<slangasek> cjwatson: desktop daily successfully installed and booted with SecureBoot=1
<cjwatson> gosh
<cjwatson> zen coding ftw
<slangasek> :)
<cjwatson> and it installed all the right -signed packages?
<slangasek> including the signed kernel packages, yes
<cjwatson> \o/
<slangasek> confirmed also that the grub.cfg got written correctly using the signed images
<cjwatson> tracked down zyga's bug earlier to a busted es.archive
<stgraber> slangasek: manjo said to ping jk but he's not around at the moment. Anyway, I successfully booted the MS countdown efi binary (Press any key to boot from CDROM... with a countdown) without getting the weird message from the BIOS
<slangasek> oh, you know what
<stgraber> slangasek: so apparently something in the shim/grub is triggering that weird behaviour on the Lenovo firmware
<slangasek> the reason he's redirecting you to jk is because of a test binary that's in the RT queue waiting for me to sign off on
<slangasek> sorry about that
<vanhoof> stgraber: ~5am for jk, he's usually on in a couple hours or so
<slangasek> (this is for getting our UEFI test app signed by MS)
<Laney> should I be disabling the CSM?
<stgraber> Laney: yes, you'll have to if you want to get secureboot enabled
<Laney> yeah, it refuses to boot with that because of my graphics card apparently
<slangasek> the Crawling Spaghetti Monster?
<Laney> "Disable the CSM to fully support the Windows Security Update and Security Boot."
<Laney> good old asu
<Laney> s
<slangasek> cjwatson: I believe this is the efifb stride patch in question: https://lkml.org/lkml/2012/7/27/307
<cjwatson> slangasek: I'm a little surprised that I can't find evidence of a corresponding boot loader patch to fix the GOP detection
<slangasek> ah, so grub2 never sets this bit anyway?
<slangasek> < helpful
<cjwatson> not afaics
<cjwatson> and if it did, we wouldn't need that patch ...
<slangasek> wouldn't we?
<cjwatson> (because presumptively it'd be getting things right)
<cjwatson> oh, ISWYM I think
<slangasek> my understanding of the problem is that the bootloader gets it right, then the kernel doesn't pay attention to what the bootloader did
<slangasek> and asks dmi again, which gives a wrong answer
<cjwatson> yeah, I misread
<cjwatson> Laney: compatibility support module - i.e. BIOS mode
<cjwatson> stgraber: "access denied" - I wonder if that's being printed by grub
<Laney> yeah, gleaned a quantum of insight
<cjwatson> stgraber: any chance of a screenshot or something?
<slangasek> cjwatson: mjg59 just confirmed on #ubuntu-kernel that there's no patch available for grub
<fginther> infinity, ping
<Laney> seems like this no VGA support business is a blocker
<slangasek> that they're using the kernel efi stub instead
<stgraber> cjwatson: sure, I can take a few photos
<cjwatson> slangasek: so using a signed kernel *would* avoid this
<cjwatson> because we'd use efi handover
<cjwatson> as I read it ...
<slangasek> would it?  or would it only do so with this patch?
<cjwatson> hmm
<slangasek> cjwatson: can you join #ubuntu-kernel?
<cjwatson> done
<cjwatson> you may be right
<cjwatson> for booting with the signed kernel: I'll have to add linux-signed-image-generic or whatever to the live seed, but that will affect non-SB systems since they'll have to ensure that that gets removed
<cjwatson> now, I *think* my ubiquity patches handle that
<cjwatson> though actually ... I don't think s
<cjwatson> o
<stgraber> cjwatson: http://www.stgraber.org/download/DSC02667.JPG http://www.stgraber.org/download/DSC02668.JPG http://www.stgraber.org/download/DSC02669.JPG
<infinity> fginther: Pong.  Might want to hit me up in /msg, I'm about to head to lunch and don't want to lose context.
<stgraber> cjwatson: that's when I get when turning on (first), pressing F12 (second), choosing ubuntu (third)
<stgraber> cjwatson: I then press enter at that last message and the system boots fine (so long as I'm using a signed kernel too, otherwise it hangs)
<cjwatson> OK, so not directly from GRUB, although I hope that isn't what happens when the shim fails to verify something
<cjwatson> I don't think it is though
<cjwatson> So that zaps my hypothesis and leaves me none the wiser really
<cjwatson> Unless perhaps the shim isn't installed
<cjwatson> That's an installed system, not a CD/USB image?
<stgraber> I'm 99% sure the message comes from the firmware as I'd get it when trying to boot grubx64.efi directly, though in that case it wouldn't let it boot at all
<cjwatson> The "press OK" "yeah, whatever" business is just bizarre
<stgraber> correct, that's an installed system, though I'm getting exactly the same behaviour when booting form the latest desktop daily (expect that the kernel won't boot as it's not signed)
<slangasek> I haven't inspected the shim's protocol handler very closely
<cjwatson> It doesn't contain that text
<stgraber> yeah, that message is weird but it doesn't look like selecting OK actually bypasses secureboot as the bit is still set to 1 after boot and booting grubx64.efi directly won't let me boot at all
<slangasek> could this be a firmware message output because grub does *not* verify under firmware?
<slangasek> and so shim trips the message, then applies its own check and boots it anyway?
<cjwatson> I thought it copied the tiano code rather than calling out to the firmware, though
<cjwatson> I mean, that's why it has its own embedded cryptlib
<cjwatson> why would it need to make a firmware call for that?
<stgraber> it certainly feels like the shim is doing a call that's rejected by the firmware but recovers from it and still lets me boot fine
<cjwatson> huh, except it *does* call LoadImage
<stgraber> and it could be that Lenovo implemented a nice visual error message instead of just silently rejecting it, which would explain why it doesn't show up on slangasek's system (really just guessing, but that'd kinda make sense)
<cjwatson> ah, it tries that first
<cjwatson> Yeah, that would make sense
<cjwatson> see shim/README
<stgraber> hmm, right, well, looks like we should remove the LoadImage/StartImage part if we want a reasonable user experience on Lenovo machines (apparently all the new ivy bridge laptops run essentially the same firmware as I have currently so will be affected)
<cjwatson> stgraber: can you arrange to have 'set debug=all' in the grub.cfg stanza that tries to boot an unsigned kernel (warning: should produce shedloads of output) so we can see how far grub gets?
<cjwatson> this'll be a "take photo of end of output" kind of deal
 * infinity lunches.
<stgraber> cjwatson: http://www.stgraber.org/download/DSC02670.JPG
<cjwatson> bah, that's really not especially helpful
<cjwatson> "hi, I read some stuff off the filesystem"
<cjwatson> does it behave the same way if you flip to setup mode and boot grub either (a) directly or (b) via shim?
<slangasek> IIRC in setup mode he had a clean boot
<cjwatson> I guess that may not signify much since grub checks internally whether SB is on
<stgraber> boots fine in setup mode both through shim and directly to grub
<cjwatson> and because you can't install your own keys the only way we can add more debugging is to upload stuff to the archive
<cjwatson> THANKS, EVERYONE
<stgraber> there may be a weird way of getting to some screen where I can manage the keys, though the new firmware is only a couple of weeks old, pretty much nobody is using it and there's no documentation on it...
<cjwatson> I really can't see anything wrong by code inspection :-/
<cjwatson> That doesn't look like enough output for it to have read the whole kernel
<cjwatson> Which it should have done before verifying the sig
<cjwatson> Oh, wait, wrong units
<cjwatson> It's read between 6291456 and 6815744 bytes, I think
<cjwatson> Does that match the kernel size?
<cjwatson> Though actually the first 1.5MiB or so of that is from a different location, so maybe I should just ask "how big's the kernel?"
<stgraber> -rw------- 1 root root 5129040 Oct  9 15:54 /boot/vmlinuz-3.5.0-17-generic
<cjwatson> OK, that's the above figure minus the three blocks from a different location
<cjwatson> So I can at least say that it's loaded the kernel, probably from linuxefi
<cjwatson> Tempted to stick a load more grub_dprintf in the next upload
<cjwatson> slangasek: ^-
<slangasek> cjwatson: looking
<slangasek> cjwatson: ^^ trade ya
<cjwatson> Already there
<cjwatson> Also have a ubiquity upload coming up, which I'd like to sneak in before the builders get eaten
<cjwatson> slangasek: looks ok - have you managed to boot-test or anything, even unsigned?
<slangasek> cjwatson: yes, have verified both allowed and denied boot paths with shim's handler
<cjwatson> OK, cool
<slangasek> SB enabled, boot Canonical-signed image: succeed; SB enabled, boot unsigned image: fail; SB enabled, boot unsigned image whose hash is added to db: succeed
<slangasek> (SB disabled, boot unsigned image: succeed)
<slangasek> cjwatson: efibootmgr accepted
<cjwatson> stgraber: I guess your mysterious inability to boot an unsigned kernel means that you can't verify whether you suffer from bug 1065263?
<ubot2> Launchpad bug 1065263 in linux "wrong stride for efifb on some systems" [High,Triaged] https://launchpad.net/bugs/1065263
<slangasek> :-)
<slangasek> cjwatson: except boot in setup mode works
<slangasek> and that bug isn't tied to SB
<cjwatson> Sure, but that means SecureBoot=0
<cjwatson> Which takes different code paths
<cjwatson> OK, so perhaps stgraber can verify that he doesn't suffer from it, but still can't actually test the server image
<slangasek> ah, right
<cjwatson> Which means we have zero QA of that right now
<slangasek> well
<slangasek> we had zero qa of it at all before
<slangasek> at least now we boot to a kernel :P
<cjwatson> slangasek: could I get a ubiquity review asap?  want to preempt some other builds ...
<slangasek> ah oops, yes
<slangasek> sorry, misread the bot as 'accepted'
<stgraber> cjwatson: I'll grab a new 64bit server image and try to boot it in setup mode see if I'm getting any corruption in d-i
 * stgraber kicks the download and gets back to packing
<slangasek> cjwatson: so I'm fine with this ubiquity change for now, but isn't one of the consequences that, when we do get the efifb bug fixed, only users running with SB=1 get the advantage of it?
<cjwatson> Yes (although we could set that capability bit in grub2 as well, in principle)
<cjwatson> If you think it's preferable to leave the signed image installed, I could live with that too
<slangasek> I think it is preferable
<slangasek> but I've already accepted :P
<cjwatson> Hah
<cjwatson> Well, I can revert before release if you like I guess
<slangasek> the kernel efi stub is going to be the better-supported path, on account of the work RH/Fedora are putting into it
<cjwatson> It's 5MiB extra download on every kernel update
<cjwatson> I guess these days that's lost in the noise
<slangasek> hmm
<infinity> Does someone want to review my libqt4pas that's hidden under all the langpacks?
<cjwatson> Now maybe not the optimal time for lots of queue flushing
<infinity> cjwatson: Oh, we can make ubiquity happy.
<cjwatson> Unless it's RC-critical
<cjwatson> I don't mean that, I mean the way security's about to sit on all the ARM builders
<infinity> If by "about to", you mean they already are.
<infinity> I didn't realise that happened while I was lunching.
<cjwatson> No, only some
<slangasek> cjwatson: could vmlinuz.efi.signed conceivably be synthesized at install time from vmlinuz + stub + sig?
<cjwatson> I did actually mean "all"
<slangasek> that would address the issue with duplicate download time
<cjwatson> slangasek: Yes, but we'd have to MIR sbsigntool
<slangasek> right
<cjwatson> slangasek: I think this would be sensible for R
 * slangasek nods
<slangasek> I might try to MIR sbsigntool yet this week anyway
<infinity> Yeah, if we rely on it, not supporting it seems silly. :P
<slangasek> since jk found a fix for the sbverify bug that was preventing me using it in shim-signed
<cjwatson> slangasek: moved linux-signed from ship-live to live; may eventually want to move into boot (not sure about for 12.10)
 * skaet starting to clean out some of the language packs translations that are in queue now....
<cjwatson> skaet: um
<skaet> cjwatson,  best not?
<cjwatson> I'd leave them until after the mozillathon
<cjwatson> hmm, so why are aatxe and lamiak idle
<skaet> cjwatson,  ok.    Please let them through tomorrow morning your time then.
<cjwatson> oh, please don't tell me it's that thing where a given PPA can only use up so much of the farm
<cjwatson> skaet: will do
<cjwatson> This is going to suck for ARM more than is strictly ideal
<infinity> cjwatson: Oh, it almost certainly is that, the real security PPA gets a pass, the mozilla security PPA is just a normal devirt. :/
<infinity> No idea how or where that free pass is given.
<infinity> If it's a simple twiddly on an admin page, we should untwiddle it.
<cjwatson> Trying to find it
<doko> cjwatson, this is easy, first make all armhf builders armel until armel builds, then make the opposite ...
<cjwatson> Bah
<infinity> Oh, actually, that would totally work. :P
<cjwatson> Way too much hand-management
<infinity> But eww.
<cjwatson> I'm not sure it would actually; 10/14 may be over the limit
<infinity> Plus, ubuntu-mozilla-security should have the same restrictions as ubuntu-security-proposed.
<cjwatson> (Given I don't know what the limit is, but 4/5 is over it)
<infinity> cjwatson: Make a bunch of x86 buildds manual and switch them to armel too.
<infinity> (Or wait until they have long builds and do so)
 * infinity vomits a little for suggesting this.
<cjwatson> Ewwwwwwwwwwww
<cjwatson> The limit is 80%
<cjwatson> So 10/14 might actually work, but ...
<cjwatson> (lib/lp/soyuz/model/buildpackagejob.py)
<doko> did do the dance on Monday
<infinity> Alright.  Let's just do that for now.
<doko> infinity, *that's* insane, but if it works =)
<infinity> doko: It would work.  But yes, disgusting, and we won't need to.
<stgraber> cjwatson: I tried the server amd64 image in setup mode, boots fine and no framebuffer corruption (right resolution and getting KMS)
<infinity> Anyhow, time to dance.
<slangasek> stgraber: you're getting kms within the installer?
<slangasek> stgraber: are you sure you mean kms, and not just fb?
<slangasek> stgraber: (what does /proc/fb say, at the point the installer first boots?)
<stgraber> slangasek: probably just fb, sorry, used KMS to mean "something that looks better than some kind of text mode"
<slangasek> stgraber: right - the distinction is material, because once inteldrmfb is loaded on this hardware here, the problem goes away
<slangasek> stgraber: so if you are managing to get a kms driver loaded by the installer, I'd be interested to know that
<stgraber> slangasek: I'll be able to retest some time on Friday, I just finished wiping that disk and packed it in my bag
<cjwatson> I don't think the installer has access to inteldrmfb - not in the relevant udebs
<slangasek> stgraber: ok.  by friday, we should in theory have an updated signed shim, so you might actually be able to test the server in SB mode
<stgraber> yay!
#ubuntu-release 2012-10-11
<cjwatson> slangasek: ^- avoid breakage from including signed kernel in image
<cjwatson> slangasek: does the .efi.signed image work when booted using a legacy BIOS, by any chance?
<cjwatson> OK, I'm going to have to defer booting images with signed kernels until tomorrow, just too tired
<infinity> cjwatson: Wait, we're shipping a signed and unsigned kernel?
<infinity> cjwatson: Wouldn't a signed one Just Work, even in the absence of anything that cares if it's signed?
<cjwatson> Well we have to ship an unsigned one somewhere due to the mechanics
<infinity> cjwatson: I meant in images, obviously the archive has one.
<cjwatson> As for images it depends how specific the format is to EFI, I forget
<cjwatson> Hence my question
<infinity> Yeah, fair.
<cjwatson> If anyone else wants to work on it, I think the steps are: for desktop, make livecd-rootfs move vmlinuz-*.efi.signed to kernel-$FLAVOUR if it exists - or possibly to kernel-$FLAVOUR.efi.signed depending on the answer to my question above, in which case debian-cd will need some work to handle that; for server, I have a suspicion that the easiest way is going to be to modify linux-signed to spit out a kernel-signed-image ...
<cjwatson> ... udeb so that debian-installer can use it
<cjwatson> again depending on the answer to my question above
<cjwatson> hopefully BIOSes can boot vmlinuz-*.efi.signed and it's all simpler
<infinity> Hopefully.
<infinity> Otherwise, this is all disgusting.
<infinity> Well, more disgusting than I thought it was.
<infinity> Which was already a pretty vile.
<infinity> cjwatson: In other news, that mlwhatever compiler is just awful.
<cjwatson> The underlying .efi file is just a copy of vmlinuz, extension notwithstanding
<infinity> cjwatson: It does some initial bootstrappy bits, and then just sits there with no output for (many) hours, doing... presumably... something to itself.
<infinity> cjwatson: Right, I has hoped it was just a vmlinuz, and I'm also hoping that the signing process took care to make sure it didn't mangle it in any awful ways.
<infinity> cjwatson: Thus leading to the theory that one can just ship a single signed image.
<infinity> cjwatson: (Which would also mean that linux-signed should be the one spitting out the linux-image-$(abi)-generic package, while the linux source just spits out linux-generic-raw to sign from, but it's a bit too late in the cycle to rearchitect that. :P
<cjwatson> The cert table goes at the end, so it's probably OK, but I was hoping somebody more awake had boot-tested it.
<cjwatson> Maybe I can install it here and ask kvm.  Yay multiarch.
<cjwatson> "error: premature end of file /boot/vmlinuz-blah"
<infinity> Lame. :/
<cjwatson> actually maybe that's just insufficient syncing
<cjwatson> 'kvm -snapshot -hda /dev/sda' is handy but produces nonintuitive results sometimes
<cjwatson> Right, that boots fine if I actually sync all the data to disk
<infinity> \o/
<infinity> So, this may sound awful and vile.
<infinity> But instead of moving things in build scripts, and other ickiness.
<infinity> Why not just, along with having linux-signed-image depend on linux-image (whatever), we also have it replace that same version, and install the kernel to vmlinuz-$(abi)-flavour and be done with it?
<cjwatson> I've already changed the installer to handle linux-signed-* specially in various ways, and GRUB to handle .efi.signed.  Changing package and file names would involve undoing or at least rethinking all of that.
<infinity> Replaces will keep it as the file installed, even if you reinstall the underlying kernel.
<cjwatson> IOW tell me this two weeks ago.
<infinity> Well, I just looked at it now. :P
 * infinity gets a time machine.
<slangasek> cjwatson: .efi.signed image> sorry, are you asking whether grub can boot the vmlinuz.efi.signed under BIOS?
<cjwatson> Happy to make it more rational for R.  For now I just need to make it work.
<cjwatson> slangasek: I was until I tested it and found that it can.
<slangasek> ok
<cjwatson> Actually what I care about is syslinux not grub, but I think the odds are good
<cjwatson> So that I can just have one /casper/vmlinuz and have it work on both
<infinity> cjwatson: Does Q have a plan for keeping signed images up to date, too?
<cjwatson> infinity: kernel team will just reupload linux-signed as part of each sru stack
<infinity> cjwatson: Yes, but...
<infinity> cjwatson: I see no meta for it.
<cjwatson> Look harder.
<infinity> Or, again, wasn't paying attention.  *looks*
<cjwatson> linux-signed-{,image-}generic
<infinity> Ahh, there it is.
<infinity> Check.
<cjwatson> base-installer will install that as appropriate.
<infinity> I missed that bit.
<cjwatson> Assuming I got all the code right.
<infinity> So, still feels better to not have two kernels installed, but otherwise, meh.  This works.
<slangasek> right, but that's not a last-minute-before-release kind of change
<infinity> Nope.
<infinity> See above, re: time machines.
<cjwatson> So actually this means my ubuntu-defaults-image approach is a bit suboptimal.  I'll upload a new version tweaking that.
<cjwatson> This is basically all the set of weird build script nonsense that I expected to have to change anyway :-)
<cjwatson> ogra_: You didn't push your most recent livecd-rootfs changes to bzr.  Fixing up by hand, but please bind your bzr branch so that this doesn't happen again.
<cjwatson> OK.  If somebody could review ubuntu-defaults-builder 0.43 and livecd-rootfs 2.90, that would be very helpful, and then at least the desktop images should be using a signed kernel in the morning.
<cjwatson> I'll figure out how to do the same for server tomorrow.
<stgraber> I'll review them
<cjwatson> Thanks.
 * cjwatson -> zonk
<stgraber> good night
<ScottK> jbicha: Does Bug #713423 need any changes for ubuntu-docs to be complete?  If not, please remove the docs task.
<ubot2> Launchpad bug 713423 in ayatana-design "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [High,Fix committed] https://launchpad.net/bugs/713423
<infinity> doko_: Oh, duh.  armhf takes so much longer than armel because the testsuite runs twice, I'm betting.
<infinity> doko_: unix + unix/-mthumb
<infinity> doko_: Err, wait.  That's all backward.  armel takes longer.  And both run -mthumb.
<infinity> doko_: Nevermind me.
<infinity> doko_: (Why DOES armel take so much longer?  Is v7 optimisation really that awesome?)
<ScottK> jbicha: Same for Bug #876017.
<ubot2> Launchpad bug 876017 in ayatana-design "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
<jbicha> I'd like to try to retarget 876017 to R but LP won't let me
<ScottK> Let me try.
<ScottK> Weird.  No "R" there for me either.
<infinity> There's a bug whereby a series disappears if... Some condition.
<infinity> Maybe when it's been targetted then rejected?
<infinity> Don't recall.
<ScottK> Thanks.
<ScottK> I unsubscribed the release team, so my caring factor has declined.
<infinity> Shouldn't matter anyway, since the default of "untargetted" is correct as soon as R is the current devel release. :P
<stgraber> looking at the bug history, that's because it was targeted at r-series then someone removed the bug tasks
<infinity> stgraber: Yeah, that's the bug.
<infinity> But, again, who cares?
<infinity> R = devel soon, = "Ubuntu" tasks are R.
<infinity> So, meh.
<infinity> Right, then.  Mozillafest is done on x86, I'm going to give i386 another buildd and open the langpack floodgates.
<ScottK> https://bugs.launchpad.net/~ubuntu-release from 95 bugs/tasks to 19.
<stgraber> thanks!
<micahg> yep, targeted then deleted task makes series disappear
<infinity> Yay, gcc-snapshot on armhf finished.
<infinity> In just about the right amount of time to make that thunderbird ain picks up finish around the same time as the last firefoxen.
<infinity> Serendipitous.
<micahg> all your arm* buildds are belong to us :)
<micahg> *working arm* buildds :)
<ScottK> https://launchpad.net/builders/primero is looking a bit schizophrenic at the moment.
<micahg> hrm, amsn is back, I guess that's fine for non-LTS...
<ScottK> It's allegedly maintained again.
<micahg> right...let's see what happens with that :)
<micahg> people seem to like it for some reason, and at this point, it's not any worse that some of the other software in universe
<infinity> Spoken like a dedicated MOTU.
<ScottK> jbicha TIL, so whatever, his problem.
<ScottK> infinity: ^^^ that's a dedicated MOTU.
<pitti> dpm asked me to upload the two packages which are affected by https://bugs.launchpad.net/launchpad/+bug/1048556
<ubot2> Ubuntu bug 1048556 in ubuntu-translations "Language pack translations export needs to add universe packages to domain map" [Undecided,New]
<pitti> they will drop the X-Ubuntu-Langpack header, so that they will use the upstream translations again and include them in the .debs
<pitti> instead of stripping them and relying on the langpacks to carry them
<pitti> (both are universe packages)
<pitti> gnome-panel and banshee
<pitti> I upload them to -proposed for being cautious, but they are intended for the final release
<pitti> as the final langpacks are uploaded now
<infinity> pitti: Want to let that neko in?  Just a rebuild (and moving a debian-changes patch), fixes an FTBFS on armhf for its r-build-deps.
<pitti> infinity: I'm not officially in ~ubuntu-release any more, but if you want to pretend for a moment that I was, I'm happy to review it :)
<infinity> I'm all for pretending.
 * pitti puts on his -release veteran hat
 * infinity curses the queue diffs, and diffs gnome-panel manually.
<pitti> infinity: LGTM, accepted; thanks for cleaning up that as-needed patch
<infinity> And the mozillathon is finally coming to a close.
<micahg> infinity: well, the mozilla buildathon :)
<infinity> micahg: Were the FTBFSes on sparc expected?
<micahg> infinity: yes, unfortunately
<infinity> <jemalloc>Compile-time page size does not divide the runtime one.
<infinity> ^-- Is that a fancy way of saying LOLALIGNMENT?
<micahg> I'm pretty sure Debian has the fix, just no one has had time to dig it out
<micahg> and since you can't install sparc from lucid media, we haven't cared too much
<infinity> Not even from d-i images?
<micahg> AFAIK, no
<infinity> Special.
<micahg> or did you fix that?
<infinity> Was I going to?
<infinity> What was broken?
<micahg> ISTR having this conversation with you before
<infinity> I made d-i stop FTBFSing on sparc, but that doesn't mean it works.
<infinity> I didn't know it didn't work, just that it didn't build.
<infinity> Oh, and that was on hardy.
<infinity> Which is what we're talking about.
<micahg> right
<infinity> Even if you said lucid. :P
<infinity> Oh, wait.
<infinity> No.
<infinity> You meant lucid.
 * infinity wonders what's wrong with lucid.
<infinity> Oh well, I have no hardware to test on anyway, so without blindingly obvious bug reports, I wouldn't be able to do much.
<micahg> yeah, powerpc was the only arch we got complaints about
<micahg> and BenC was kind enough to fix that
<infinity> Not so much kindness as being paid, I think.
<micahg> whatever gets the job done ;)
<micahg> PPC in quantal is in better shape than precise
<infinity> cjwatson: So, it was neko that was doing the wrong thing.  With neko rebuilt, neither haxe nor mercurial-buildpackage FTBFS (no need to rebuild either of those, mind you)
<infinity> micahg: Yeah, shame he didn't start on his crusade about 3 months earlier.
<micahg> heh, right
<infinity> micahg: Though he got precise in pretty decent shape.
<micahg> yeah, it's not bad
<infinity> micahg: Certainly good enough for most server workloads, which is actually what his employer cared about.
<infinity> micahg: I think fixing the rest of the world was just a point of pride, and cause whoever pays him didn't really understand that they didn't care. ;)
<infinity>   241 root      20   0     0    0    0 D   15  0.0 131:52.45 usb-storage
<infinity> 14520 adconrad  20   0  668m 352m  100 D    4 39.0  20:09.78 mlton-compile
<infinity> 14395 adconrad  20   0  678m 288m   80 D    3 31.8  20:02.58 mlton-compile
<infinity> ^-- Dear Santa, I'd like an ARM box with RAM, so I can stop spending more time swapping than compiling, kthx.
<infinity> ^--- Best version number EVAR.
<Laney> what in the
<Daviey> infinity: it could only be better if it regressed and we had to drop back with, 7.2~alpha5+cvs20101124-1+deb7u0ubuntu2~really7.2~alpha5+cvs20101124-1ubuntu1
<infinity> Daviey: Except that's the same upstream, so it would just be ubuntu2. :P
<Laney> is that a convention for tpu?
<pitti> (Don't forget the ~precise1 backport suffix)
<infinity> Laney: Apparently.
<Daviey> infinity: bah! :)
<cjwatson> pitti: ~ubuntu12.04.1 you mean :-)
<Laney> 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.246.0ubuntu1
<Laney> still wins
 * xnox I am tempted to make some software and actually call it 10.0.58.4.5, first upstream version will also match the name of the software.
<infinity> Aaaanyhow, if someone would like to review that instead of making fun of the version number... ;)
<infinity> I think that's the only legitimate FTBFS left in main.
<infinity> And I'm sick of staring at mlton bootstrapping, so I might go to bed.
<infinity> cjwatson: mlton bootstrappyness will happen in-archive tomorrow, by the looks of this local build.
<cjwatson> Cool.
<cjwatson> Impressed at somebody fixing libatomic-ops.  I tried and failed.
<cjwatson> (Like, last release.)
 * cjwatson goes cross-eyed at x86 asm
<cjwatson> Only one coffee ...
<didrocks> small internationalization fix to generate some javascript strings in pot which can be translated :p ^
<apw> linux-signed upload adding di integration as a step towards netboot support
<infinity> (and server)
 * cjwatson reviews
<cjwatson> LGTM
<psivaa> cjwatson, i notice source.list contains uncommented deb cdrom:[Ubuntu 12.10 _Quantal Quetzal_ - Beta i386 (20121010)]/ quantal main restricted after an i386 reinstall
<psivaa> cjwatson, is that intended?
<ogra_> hmpf, whats wrong with the arm builds
<cjwatson> psivaa: Sounds reasonable to me
<pitti> cjwatson: is that for installing network drivers etc. post-installataion?
<psivaa> cjwatson, ok, on amd64 i see that line commented though
<cjwatson> pitti: for example; also if you have the stuff locally then why not
<cjwatson> apt used to be irritating and ask for the CD, but it doesn't any more
<cjwatson> psivaa: honestly - it might be a micro-bug somewhere, but I'm doubtful that it's worth spending any time on
<psivaa> cjwatson, ack, software center asks for the CD when this line is uncommented
<cjwatson> !
<cjwatson> That bug was fixed in apt in, what, 2005?
<infinity> ogra_: You mean ARM image builds?
<cjwatson> psivaa: Sigh, file a bug on whichever installer you're using with logs, then
<ogra_> infinity, yeah
<infinity> ogra_: Could be suffering from skew since all the Pandas were busy with firefox/thunderbird all day.
<ogra_> infinity, livefs builds particulary
<infinity> ogra_: And I mean *all* the Pandas.
<infinity> ogra_: The queues will catch up in a bit.
<ogra_> oh, did we now switch to LP buildds ?
<infinity> ogra_: Hrm?  No, I meant that we could have had package skews due to ARM not building anything useful for 12h.
<ogra_> (i.e. is it pointless to look at celbalrai ?)
<Laney> psivaa: how did you get s-c to ask you for a CDROM?
<Laney> I can't get that here
<ogra_> oh, well, i dont even see build attempts for the last two days
<pitti> infinity: thanks for accepting udev; for quantal, did you intend to land this in quantal proper, or SRU? (I'm fine with final, it's quite straightforward and tested by two people)
<infinity> Oh, that's disconcerting.
<ogra_> right
<infinity> pitti: I was going to let it in.
<cjwatson> I got some empty error mails about ARM builds
<cjwatson> (livefs)
<pitti> infinity: cheers
<ogra_> ac100 has a build attempt yesterday with some weird chroot cleanup message
<pitti> banshee and gnome-panel look good, they now have translations
<ogra_> and omap/omap4 hanst even been attempted it seems
<ogra_> *hasnt
<psivaa> Laney, when you try to install something  using software center it asks for the cd,
 * ogra_ suspects a buildd issue
<Laney> no, I don't see that
<infinity> ogra_: Could be that someone needs to hard rm -rf chroot/build/*
<infinity> ogra_: Where's that log?
<ogra_> yep
<psivaa> well even if the line is uncommented?
<Laney> yes
<Laney> ah, perhaps I need apt-cdrom
<Laney> no
<infinity> ogra_: Oh, found it.
<pitti> Laney: merely adding the line won't help; did you actually add it in apt?
<Laney> ho hum.
<ogra_> http://paste.ubuntu.com/1272866/
<infinity> ogra_: Weird.  It has no errors.  Just doesn't configure.
<cjwatson> psivaa: desktop image, presumably?
<psivaa> cjwatson, yes
<Laney> pitti: I just uncommented it in sources.list
<cjwatson> psivaa: from DVD or USB?
<Laney> do I have to do more?
<pitti> apt-cdrom add, I think
<psivaa> cjwatson, usb
<cjwatson> And when you tested amd64, was that also from USB?
<infinity> ogra_: 20121009 was okay, though.
<psivaa> cjwatson, yes
<ogra_> yep
<infinity> ogra_: So, this is very recent.
<cjwatson> Curious.  I suppose the difference might relate to multiarch, since we've never really tidied up multiarch on the CD.
<ogra_> but there was no livecd-rootfs or live-build uploads or anything in that timeframe
<ogra_> i uploaded a change on the 3rd ... we had working builds since and colin uploaded the efi change today
<cjwatson> psivaa: FWIW my snap assessment is that commenting that out has a high risk of regressions both in the installer and in post-install tasks such as installing restricted network drivers
<cjwatson> So I'd much rather see software-center fixed to not ask
<cjwatson> But I'll have a look to see if it's something subtler
<cjwatson> (Which is quite possible)
<infinity> ogra_: Try a by-hand lubuntu-ac100 build?
<infinity> Or...
<infinity> Wait.
<ogra_> nothing suspicious in debian-cd either
<infinity> debian-cd wouldn't relate anyway.
<ogra_> well, neither in cdimage :)
<ogra_> yeah, let me try a manual buildlive
<infinity> I was just about to do a manual core.
<psivaa> cjwatson i actually did a reinstall from amd64 ->i386,  then i see the line uncommented -> when i use s-c it asks for a cd and after i comment the line the s-c does not ask for the cd
<cjwatson> what sort of reinstall?
<ogra_> infinity, are you running already ?
<infinity> ogra_: I will be, yeah.  Hands off for a sec.
<ogra_> lubuntu-armhf-ac100 on celbalrai.buildd starting at 2012-10-11 09:43:28
<ogra_> lockfile: Try praying, giving up on "/home/buildd/buildLiveCD.lock"
<ogra_> lubuntu-armhf-ac100 on celbalrai.buildd finished at 2012-10-11 09:43:30 (failed)
<ogra_> Null message body; hope that's ok
<ogra_> Error: no livefs builds succeede
<infinity> Ahh.
<psivaa> cjwatson, usb-> and the new Re-install option
<cjwatson> Not that new, but OK
<infinity> ogra_: Working with webops to fixify it.
<cjwatson> And the amd64 install was a fresh unmodified install of quantal?
<cjwatson> It'd be great if I could have exact directions rather than asking lots of questions :)
<ogra_> infinity, great, thx
<xnox> cjwatson: well it wasn't shown for dev-releases until I fixed it recently ;-) hence "new in quantal recently". I wonder if we should not allow cross-grading... or do some sanity to sources.list.
<psivaa> cjwatson, ill reproduce that and file a bug, with steps to reproduce
<infinity> ogra_: So, celbalrai went read-only.  That would explain the weird logs. :P
<ogra_> haha
<ogra_> yeah
 * ogra_ wants arm boards with 6G RAM and tmpfses for live builds !
<infinity> How about 4G of RAM and a filesystem that's not tethered to the machine with a USB cable?
<infinity> ogra_: Right, it's being escalated with some urgency.  For now, you has no livefses.  I hope you had other things to work on...
<ogra_> well, i was about to roll a ubuntu rootfs tarball :)
<ogra_> but yeah, i can do enough other stuff
<infinity> Oh, you can't be serious... libatomic-ops now segfaults on armel?
<infinity> FML.
 * infinity gives it back and prays that was cosmic rays screwing with him.
<xnox> infinity: welcome to this timezone ;-)
<ogra_> heh
<cjwatson> You say that as if infinity has a home timezone.
<infinity> xnox: I've been up for 22h, I'm not actually sure what TZ I'm in.
<xnox> infinity: clearly the odd one ;-)
<Daviey> infinity works 24x7 during freezes, and release times.  Outside of those times, he sleeps.
<infinity> The latter bit may not be true.
<infinity> *sigh*... And now it's gone into an infinite loop.
<cjwatson> Ooh, I can haz netbeans fix?
 * cjwatson reviews
<infinity> Why do I have a sinking feeling this isn't going to end well?
<smartboyhw> lol
<infinity> Ifinitely-looping testsuites make me sad.
<cjwatson> Would anyone object to syncing in sugar-base-0.88 and sugar-toolkit-0.88 so that sugar-moon-activity can build?
<cjwatson> (I might test-build them first)
<infinity> Oh, feh.  I see the problem with atomic-ops on armel.  I think.  I'll need to look at this in the morning.
<infinity> If this was on a v5 buildd, it would just happily SIGILL instead of doing Weird Things.
<cjwatson> -march FTW?
<infinity> cjwatson: You mean just force it to v7 and be done with it for now? :P
<cjwatson> I meant v5, but perhaps I misunderstand
<infinity> cjwatson: I was going to just backport the newer sysdeps/gcc/arm.h, since it actually properly deals with Thumb1/Thumb2.
<cjwatson> Ah
<infinity> cjwatson: The problem is the inline ASM in the old version of libatomic-ops we carry assumes thumb == thumb2, and does Very Bad Things.
<infinity> Well, that's *a* problem.  I can't tell if that's what just exploded aleya until I fix it.
<infinity> But yeah.  I need a nap.
<infinity> Will fix in the "morning", whenever that happens.
<cjwatson> OK, sugar-{base,toolkit}-0.88 build cleanly here, and should be enough to resolve that dep-wait, even if they don't represent a complete Sugar environment.
<cjwatson> So synced.
<cjwatson> Oh, that's where linux-signed got to
 * cjwatson curses -proposed, made me waste an hour
<infinity> cjwatson: Say, how did libatomic-ops miss your napalm rebuild-for-armv5 run anyway?
<infinity> cjwatson: Then this would have been your problem. ;)
<infinity> cjwatson: (Turns out I was wrong about the thumb thing, it is guarded elsewhere, so it never executes.. But this infinite looping testsuite has been seen on several arches in recent rebuilds on Debian too)
<infinity> Kinda tempted to just disable the test suite on armel and say screw it for now.
<cjwatson> infinity: Not quite sure.
<cjwatson> Possibly worth debugging if I had any time :-)
<infinity> I'm pretty sure I never should have collapsed the waveform on this one.
 * infinity naps for real this time, and hopes he doesn't dream of atomics.
 * cjwatson battles with ruby-fusefs
<ScottK> Apparently I mashed the wrong buttton on sugar and it can't be fixed:
<ScottK> FAILED: sugar-toolkit-0.88 (Can't resurrect rejected syncs)
<ScottK> FAILED: sugar-base-0.88 (Can't resurrect rejected syncs)
<Laney> yeah, re-sync them
<cjwatson> Yeah, you can't ... that.  I can resync.
<ScottK> Thanks.
 * ScottK tries again.
<cjwatson> Hmm, sugar-* still rejected
<cjwatson> Damn, it was deleted from quantal
<cjwatson> I wonder if I can re-copy it from precise
<cjwatson> Or even from quantal come to that
 * cjwatson tries
<cjwatson> Ha!  Master.  Hopefully that won't break the publisher.
 * infinity gives up on the mystery of libatomic-ops.  No, really.  Honest.
<cjwatson> You can review d-i instead :)
<cjwatson> Seeing as you're clearly failing to sleep
<infinity> I'm also failing to reproduce the failures the buildds are seeing.
<infinity> And it's making me a sad panda.
<cjwatson> barry: so, um, why is this python-mode sync appropriate during final freeze?
<cjwatson> While I understand the desire to get all one's own Debian packages in sync :)
<barry> cjwatson: dang, you noticed. :)
<cjwatson> barry: I'm wary of anything but crash/build/other-serious-bug-fixes and maybe some already-known feature freeze exceptions at this point, TBH
<infinity> cjwatson: Why not just ifdef; if -e; mv boot/$nameALT boot/$name; fi; endif, instead of duplicating the other mv with an else?
<cjwatson> infinity: I suppose if I did that *after* the other mv
<cjwatson> Oh, or I could read what you wrote
<barry> cjwatson: that's cool.  this does fix real problems people have with functionality, it's universe, but i have no problems sru'ing it after release if you prefer.
<cjwatson> Yeah, that would work
<infinity> cjwatson: It just seems a bit more readable to me that way.  And shorter.
<cjwatson> barry: Yeah, I'd rather that at this point, honestly.  More time to spot any new breakage.
<barry> cjwatson: np
<infinity> cjwatson: So, basically, just ditching the rm/else/mv, and then ending the ifdef, rather than elsing it.
<infinity> (elsing is totally a verb, right?)
<cjwatson> infinity: http://paste.ubuntu.com/1273151/ ?
<infinity> Why does diff insist on silly ordering I can't read.
<infinity> Yeah, that looks like what I'm driving at.
<cjwatson> mkay, will upload ubuntu183
<infinity> Ends up doing the same thing, but the smaller the unusual ifdef code blocks, the better, IMO.
<infinity> Easier to track WTF they're up to.
<infinity> I'll just reject 182, and you can re-tag it.
<cjwatson> I prefer a new version anyway
<infinity> Alright. :)
 * infinity probably abuses bzr tag --force a bit too often.
<cjwatson> Yay, resurrecting with copy-package totally works, admittedly with a couple of slight hacks only one of which I committed.
<infinity> My local copy-package is hacked to bits for that sort of thing.
<infinity> But not in any remotely committable way.
<cjwatson> Maybe I should write a dedicated undelete-package.  Except the opposite is called remove-package, and unremove-package doesn't sound right.  It sucks to be a pedant sometimes.
<infinity> Just, like, a ton of stuff commented out. :P
<cjwatson> I fixed lputils in a way that deals with most of what you usually complain about
<cjwatson> But you also have to comment out the target-same-as-source guard
<infinity> The opposite of remove would be insert, surely.
<infinity> insert-package
<cjwatson> Not really in this sense ...
<infinity> Cause that doesn't sound dirty at all.
<cjwatson> restore, but it looks too similar.
<cjwatson> Or resurrect.
<infinity> I think just giving copy an option to do it seems sane.
<infinity> Since it really *is* a copy.
<infinity> Just a weird one.
<cjwatson> It is, it's just that only people who know Soyuz will think of it that way.
<cjwatson> Laney: So I was looking at removing pandoc/armel, since I suspect that mysterious build failure isn't likely to go away
<ScottK> I like resurrect.
<infinity> revive?
<cjwatson> revive isn't bad
<cjwatson> Though even more similar to remove
<cjwatson> Laney: Looks like the rdepends stack that would need to be removed on armel would be: bup carettah imageshack-uploader purity-ng libnss-rainbow2 tempest-for-eliza
<cjwatson> What do you think?
<infinity> cjwatson: remove-package --not? :P
<infinity> --just-kidding
<cjwatson> remove-package --undo
<infinity> Alright, going to try harder to nap.  Maybe I'll dream of some way to reproduce this stupid test failure before I give up and disable the testsuite and make Daviey's day by being a hypocrite.
<infinity> cjwatson: undo-removal would work.  It doesn't HAVE to have 'package' in the name.
<Laney> cjwatson: feel free
<Laney> Someone who cares more could look into removing the pandoc BDs on those packages (at least some of them are likely to be for documentation only)
<infinity> cjwatson: Oh, by the way, if that paste was a pastebinit pipe, "pastebinit -f diff" makes it pretty (aliased to pastediff here, cause that's 99% of my pastes).
<cjwatson> My bin/ubuntu-paste is old-skool.  One of these days I might switch to pastebinit.
<cjwatson> Laney: OK, removed
<bdrung> hi, vlc 2.0.4 will be released on sunday. it contains a bunch of bug-fixes and adds support for opus (= only new feature). now likely is it to get a FFe?
<jdstrand> skaet, cjwatson: is now an ok time to pocket copy firefox and tbird?
<cjwatson> bdrung: I suspect an SRU at this point would be more likely
<cjwatson> jdstrand: yes
 * skaet has cup of tea in hand, and prepares to work through the back scroll.
<skaet> jdstrand,  ok by me,  but am just catching up on the overnight status.   cjwatson?  infinity?
<cjwatson> Yes, I said yes above :-)
<skaet> ah,  just saw cjwatson's yes
<jdstrand> skaet: it is built on all archs and tested
<skaet> sorry
 * skaet increases caffine intake.  ;)
<skaet> thanks jdstrand
<jdstrand> ok, firefox and tbird are copied. I hope we can stay out of your hair now
<ScottK> mvo: Is there a reason this software center upload can't go to -proposed?
<mvo> ScottK: it can go to -proposed, the reinstall previous purchases bug is important but its certainly ok if it goes into -proposed - I can reupload there
<ScottK> Thanks.  Will reject the current upload.
<mvo> ScottK: thanks, is there still a chance it may go on the CD in in case a rebuild is needed or is it stricly out of the question now?
<skaet> mvo, depends on what's in it, and risk
<Laney> when should we decron and stuff?
<skaet> Laney,  was thinking it was looking close to now actually.
 * skaet staring at her checklists ;)
<mvo> skaet: thanks, risk is small but non-zero (of course). I understand if -proposed is the way to go at this point of course
<cjwatson> My one remaining thing is that I'd like to get a grub2 upload in to help us debug stgraber's mysterious failure to boot unsigned kernels.
<skaet> cjwatson,  is there anything still pending from your perspective?  (am not sure from the backscroll if all the UEFI bits have been sorted into place yet)
<skaet> lol
<cjwatson> snap
<cjwatson> Just preparing that now - shouldn't be any functional change when debug is unset
<skaet> ok,  lets turn off the cron.
<ScottK> xubuntu-docs is in queue.
<ScottK> Doesn't affect anyone but them.
<skaet> yup, was waiting for diff, and don't see any problem with it going in on priinciple.
<skaet> low risk, affects them.
<ScottK> cjwatson: This memtest86+ upload needs in too, right?
<cjwatson> ScottK: It would be useful
<cjwatson> And fairly low risk AFAICS
<skaet> crontab disabled
 * skaet wondering why diffs are taking so long to generate
<skaet> its been 30 minutes now on xubuntu-docs
<ScottK> Seems reasonable then to get memtext86+, grub2, and xubuntu-docs in and then declare victory.
<Laney> a whoopsie just came in
 * Laney is amused that he got to type that
<ev> it did
<skaet> what's the backstory on it ev?
<ev> I'll give whoever lets that through a giant pile of candy
<skaet> yeah,  but while we wait for the diff to show up - what's it fixing?
<ev> skaet: it's needed for https://bugs.launchpad.net/whoopsie/+bug/1050853
<ubot2> Ubuntu bug 1050853 in apport "Not recorded whether an error is in a -proposed or -updates package" [Undecided,Fix committed]
<skaet> :)
<ev> I probably should've linked to that :)
<ev> the only change is that we send the Tags field up with the report
<ev> single line diff
<ev> I'll also backport it to precise in a bit
<skaet> ev,  thanks.   pending review, yeah would be good to get in.
<ev> wonderful
<cjwatson> Oh, and grub2 will need a grub2-signed later on too ...
<Laney> wasn't there a new shim?
 * cjwatson lobs it up quickly
<cjwatson> Laney: it's in -proposed pending mjg59 approval
<Laney> yeah, so that
<Laney> and then shim-signed presumably
<cjwatson> Which I think in practice will need to be around when slangasek wakes up
<cjwatson> But grub2 will take a little while to build anyway
<cjwatson> (Not horrible, but not instant)
<cjwatson> quantal_outdate_all is beginning to look almost tractable
<cjwatson> There's certainly more non-image stuff we need to fix
<skaet> cjwatson,  do we have the d-i bits all lined up too?
<cjwatson> yes
<skaet> :)
<cjwatson> We have at least one ubiquity patch queued, but not the end of the world if it doesn't land; in any event I would be surprised if we didn't have to upload ubiquity at some point over the next week
<cjwatson> Though I can hope
<cjwatson> dpm's asked for another translations sync if we do end up doing that
 * skaet can hope too
<cjwatson> doko: ^- is that to fix a build failure somewhere?
<doko> cjwatson, ibus-rime b-d
<cjwatson> gotcha, will look
<cjwatson> Can somebody review grub2?
<stgraber> cjwatson: doing that now (and memtest86)
<cjwatson> ta
<Laney> Conflicts/Breaks?!
<stgraber> cjwatson: accepted both. Will be offline for the next hour or so but should be available for another test after that (before leaving for the airport).
<slangasek> cjwatson: no word from mjg yet on the shim change
<cjwatson> Laney: changelog disagrees with control - it's Replaces/Breaks in control
<Laney> righto
<slangasek> so there's an armadaxp ABI change just landed; that's going to require a d-i upload, no?
<cjwatson> Already did that
<slangasek> ok
 * slangasek pushes the seed change
<cjwatson> Oh I forgot that, sorry
<slangasek> no worries
 * cjwatson stares at the long-running ruby-hdfeos5 failure
<cjwatson> I'm pretty sure that "Latitude" is being transformed into "LocalSgitude" at some point along the way
<cjwatson> Which is ... inventive
<ogra_> cjwatson, do we plan to have R build working from day one ? or is there the usual "dont care before A1" in place ?
<ogra_> *R builds
 * ogra_ is wondering ... with all these new policies etc ...
<skaet> ogra_,    hopefully from day 1,  or shortly thereafter.
<ogra_> skaet, good
<cjwatson> It won't be practical until after the auto-sync has settled, since we don't yet have automatic continuous integration from -proposed into release.
<cjwatson> Until then we shouldn't make promises we can't keep.
<cjwatson> This isn't quite the same as "don't care" - "can't quite commit yet".
<cjwatson> slangasek: ^- grub2, grub2-signed
<slangasek> cjwatson: do those need a staged accept?
<cjwatson> slangasek: no
<skaet> cjwatson,  has cd release-upgrader been set to ""useDevelopmentRelease=False" ?
<slangasek> cjwatson: ok
<slangasek> skaet: TTBOMK, cd release-upgrader has been obsoleted with the dropping of alternate CDs
<slangasek> rather, with the dropping of non-livefs CDs
<slangasek> (since server could use it, but server is also using livefses now)
<skaet> slangasek, ack.
 * skaet makes note to remove that line item from the checklist then.
<cjwatson> right
<skaet> cjwatson,   how are the langpacks going out with the images looking?
<cjwatson> skaet: You mean the ones uploaded last night?  infinity accepted them before I woke up; they've long since all built
<skaet> cjwatson,  was wondering which languages are going to be shipped by default,  and whether we have head room to add a few more back in actually.
<cjwatson> Oh, that I haven't looked at at all
<doko> cjwatson, uploaded a new minor version of visualvm, which builds using netbeans, then libnb-platform-java can be removed (ftbfs)
<cjwatson> doko: right, nice, will review
<cjwatson> doko: I got ruby-hdfeos5 to build!  Only took six months since I first looked at it
<doko> \o/
<skaet> cjwatson,  have taken care of setting up iso tracker, and .conf file,   so when we spin up the first set of images they should go to the right place.
 * skaet crosses fingers that first set is the last one.  ;)
 * skaet --> early lunch,  back later
<stgraber> cjwatson: installed grub2-signed 1.5, will reboot and get you a new photo
<stgraber> cjwatson: got an extra line of output, will upload the photo now
<stgraber> cjwatson: http://www.stgraber.org/download/2012-10-11_12-27-38_458.jpg
<Riddell> kdeplasma-addons for a very visual issue in kubuntu active on first boot
<Riddell> ScottK: fancy looking at that one? ^^
<cjwatson> stgraber: so I guess my debugging output wasn't quite perfect, but looks to me as though that's stuck inside shim
<cjwatson> slangasek: over to you? :-)
<cjwatson> slangasek,skaet: do you know if anyone's notified the web team about the demise of the alternate installere?
<xnox> cjwatson: I did, when me and ev had a "meeting" with them.
<cjwatson> oh, and the DVD ...
<xnox> cjwatson: as well as s/CD/DVD/ and the fact that server will probably not have i386.
<cjwatson> I think I should double-check
<xnox> in the offices.
<xnox> cjwatson: yeah, I haven't heard back from the meeting much, but they were "hungry" for information and taking action points / list of changes.
<slangasek> cjwatson: so it's stuck in shim_verify?
<cjwatson> slangasek: appears to be
<cjwatson> stuck or crashed
<slangasek> cjwatson: are these debug statements in the current grub2 in the archive?
<cjwatson> slangasek: yes
<cjwatson> xnox: sent a "better safe than sorry" mail, anyway
<xnox> cjwatson: ok.
 * cjwatson starts refreshing memory on how to top up images with language packs
<xnox> 8)
<ScottK> Riddell: Will look.
<cjwatson> skaet: I've topped up Ubuntu quantal-desktop-powerpc.iso, which was the only one that I felt needed it (I'm not going to bother topping up the ARM ones)
<cjwatson> I figure other flavours can manage this themselves if they want to
<slangasek> cjwatson: I guess it's unlikely that grub_efi_locate_protocol() is hanging or crashing?
<cjwatson> slangasek: Yeah, hence my comment about debugging being not quite perfectly granular, but it seems pretty unlikel
<cjwatson> y
<cjwatson> That's a straightforward wrapper over LocateProtocol
 * slangasek nods
<cjwatson> Ellen is out of the office; do we know who's covering for her on the web team?
<ScottK> Riddell: You verified this doesn't screw up non-Active images, right?
<popey> Ellen is no longer on the web team cjwatson
<cjwatson> Oh, we need to update our process pages then
<cjwatson> I wish Canonical made better use of role addresses for things
 * cjwatson pokes the directory and comes up with some possibilities, at least
<popey> cjwatson, I am informed Tanya Edwards is your contact
<cjwatson> Good, she was one of the three addresses I came up with
<cjwatson> skaet: OK, so I'm going to have to finish for today; the netinstall issue raised by the server team turned out to be not a relevant one for us at this point (it's something to do with precise, not quantal); after this publisher run (so call it half an hour for safety, though probably less), from my point of view we can start building candidates
<cjwatson> skaet: scrollback suggests Kubuntu might want to wait until this kdeplasma-addons problem is sorted out, not sure
<Laney> there's a webapp upload coming apparently
<Laney> from kenvandine
<Laney> I think it includes some deferrable-to-SRU changes, but ymmv
<seb128> is that a difference between SRU and release uploads from an uploader perspective?
<seb128> or it's just "upload to quantal-proposed" and then see when it gets accepted?
<Laney> for SRU you'll need the bug reference, but I suppose otherwise not
<Laney> however this webapp upload contains a change that we do want in the release which makes it more difficult
<seb128> Laney, why difficult? we still have an unity upload coming so we will need to respin isos anyway...
<Laney> more difficult to aim at proposed
<seb128> I'm annoyed by https://bugs.launchpad.net/ubuntu/quantal/+source/libreoffice/+bug/1064962
<ubot2> Ubuntu bug 1064962 in indicator-appmenu "Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed]
<seb128> but I guess it's too late at this point for such changes for release
<seb128> ?
<seb128> I still want to mention it
<Laney> seb128: doesn't look like there is even a fix for that yet?
<seb128> the bug is basically "if you double click on a lo-file in nautilus you will get no menus"
<seb128> Laney, no, they are working on it, just got discussed a bit earlier on #ubuntu-desktop
<Laney> I think basically SRU yeah, but I agree it is annoying
<doko> cjwatson, diagnostics is the last one for me today. please watch https://launchpad.net/ubuntu/+source/pandoc/1.9.4.2-2build1/+build/3744152 and give back optgeo once it's in the archive
<Laney> skaet: what do you think about the webapps stuff?
<Laney> in queue
<ScottK> Looks like SRU material to me.
<Laney> Yeah.
<Laney> kenvandine: I think it would be best for us to only take the API key stuff for account-plugins and get the rest into proposed
<Laney> Taking the API keys because you have to re-authenticate if they change which would be pretty crap post release
<xnox> also the diff looks very strange... was all the auto-generated stuff removed on purpose or by accident? why it's 2.4.1 and 2.4 in configure.ac?
<Laney> I'll do a safety reject out of unapproved/release
<skaet> cjwatson,  talked to the web team about the images at beta 2 time,  but its on the check list to doublecheck with them once they have the staging site up.
<skaet> ScottK,  Riddell - where is the kdeplasma-addons issues?   do you want the kubuntu images to wait for it?
<ScottK> skaet: If you have others to do, go ahead with them.  I'm waiting to hear back from Riddell on testing before accepting.
 * skaet now trying to figure out what's the issue webapps...
<skaet> ScottK,  ok.   won't spin up Kubuntu and Kubuntu active until I hear from you/Riddell
<didrocks> Laney: if you want to pre-test the legal notice we discussed, you can test unity from the ubuntu-desktop ppa once it's built
<Laney> did he quit?
<peterm-ubuntu> Laney is this the legal notice from Ivanka?
<Laney> No idea who it's from
<peterm-ubuntu> Laney untu.com/aboutus/privacypolicy/thirdparties.html ?
<Laney> peterm-ubuntu: I'm not sure, I haven't seen it
<peterm-ubuntu> wellâ¦ propery started
<peterm-ubuntu> ok
<Laney> it's a link from the dash to some legal notice
<peterm-ubuntu> because that one isn't quite right
<skaet> Laney,  yeah let me know what you and didrocks find out,  this is one of the other bits on the critical path for the images it seems.
<Laney> but I don't know wha tthe final design is or anything
<Laney> skaet: I'll be away, sorry
<Laney> I'm off tomorrow too
<skaet> Laney,  ack
<Laney> peterm-ubuntu: It needs to be right very soon
<Laney> we're in final freeze now.
<skaet> and are supposed to be spinning up the images now.... :P
<seb128> Laney, skaet: re. didrocks: yes, it's the "Legal notice" link from design,#ps
<skaet> seb128, is there a bug number so we can track progress that way?
<peterm-ubuntu> Laney sorry, I am playing catch-up, this happened on my ride homeâ¦ but I think it is meant to be a link to all the thirdparty privacy policies
<seb128> Laney, skaet: do you have any question about that?
<seb128> skaet, I don't think so, that has been handled in fire fighting mode over IRC today
<skaet> seb128,  when is it landing,  who's tested it so far,  how do we know no regression from including it.   (the usual ;) )
<seb128> skaet, seems it's a legal requirement in the U.K to have a link to those notes
<Laney> seb128: No, no question. I just don't want us to be caught in the middle of a design fight
<seb128> well, the ppa is a backport of what design,#ps agreed on, implemented
<peterm-ubuntu> Laney and it can't end in .htmlâ¦ so I think it needs to be: http://www.ubuntu.com/aboutus/privacypolicy/thirdparties
<ScottK> The bug number question is a good one.
<Laney> Where does this link go?
<ScottK> 404 ATM
<Laney> Sorry, unclear. Where will it be in the desktop?
<peterm-ubuntu> Laney are you asking me?
<Laney> peterm-ubuntu: anyone who knows ;-)
<peterm-ubuntu> Laney all I have is Peter,
<peterm-ubuntu> A last minute request from SteveG via Ivanka regarding a page that lists links to all the privacy policies for our third partys.  This page link will live on the 'dash' aside the link to our privacy policy (ubuntu.com/aboutus/privacypolicy).
<peterm-ubuntu> Ivanka needed to know ASAP the URL that we intend this link to be. Amrit, Ivanka and I discussed and logically it sits as a page off the Ubuntu privacy policy page (ubuntu.com/aboutus/privacypolicy), so therefore the new link would be ubuntu.com/aboutus/privacypolicy/thirdparties.
<peterm-ubuntu> ubuntu.com/aboutus/privacypolicy/thirdparties.html is what I included in the doc which will now land in Ubuntu.
<peterm-ubuntu> We will talk with U1 people tomorrow about creating the content for the page which is simply a list of third parties and links to their privacy policies so nothing fancy.
<peterm-ubuntu> Ivanka
<Laney> OK. I don't know where that existing link is TBH
<seb128> skaet, Laney: didrocks is not around anymore but bottom line is: preview is in the ppa, we will have a bug with all those infos tomorrow going with the official upload
<Laney> seb128: OK. I don't think I'll be able to look at it (away tomorrow), so someone else on the RT can
<seb128> Laney, ok, enjoy your W.E!
<Laney> beer festival - certainly will!
<seb128> nice!
<seb128> Laney, is that UDS training? ;-)
<skaet> Laney,  about the one you put on hold,  has the problem been fully solved,  or is it a partial?
<ScottK> Did we get firefox 16.0.1 in quantal yet?
<seb128> ScottK, yes
<skaet> ScottK,  yes,  copied over this morning by jdstrand
<ScottK> Cool.
<Laney> skaet: I left kenvandine a message with what I think should be done for the release
<Laney> which is to take just one of the fixes and leave the rest for SRU
<skaet> thanks Laney.   ok.   will follow up with him.
 * skaet shifting location,  back on soon.
<skaet> ScottK, ^ after kdeplasma-addons publishes, ok to spin your images up then?
<ScottK> skaet: I also want bluedevil in since we have a window.  It's just a copy from -proposed so it should be done first.
<skaet> ScottK,  ok.
<Riddell> thanks ScottK
<ScottK> bluedevil is done, so once you have kdeplasma-addons, it should be good.
<skaet> gilir,  anything you're waiting for, or can we start spinning up lubuntu?
<ScottK> Someone might rescore kdeplamsa-addons so it gets an earlier start on armel.
<stgraber> ScottK: doing that now
<skaet> infinity, ^ can you oblige?
<skaet> ah
<ScottK> Thanks.
<skaet> thanks stgraber,  never mind infinity
<ScottK> The rescore bought us about half an hour.
<gilir> skaet, no, you can start
<skaet> thanks gilir,   there will likely need to be respins (cjwatson's fix), so don't go wild testing them yet,  but I want to make sure no other surprises.
 * skaet  starting to spin up trial set of ubuntu, xubuntu, and lubuntu images -  will be respun later.
<kenvandine> Laney, skaet: account-plugins uploaded again
<kenvandine> thanks for looking at that
<skaet> thanks kenvandine
<skaet> could I get a second set of eyes on account-plugins in the queue?   its looking basically sane, but would appreciate a second opinion.
<infinity> Sure.
<slangasek> skaet: looks ok to me
<slangasek> er, excetp
<slangasek> --with-flickr-consumer-secret
<slangasek> doesn't look very secret, does it?
<infinity> And -with-twitter-consumer-secret
<infinity> I think this may be a different use of the word "secret" than I'm familiar with.
<slangasek> kenvandine: can you clarify? ^^ is it actually ok that these "secrets" are published for the world to see?
<kenvandine> slangasek, yes... that was the agreement we had with twitter for gwibber in the past
<slangasek> funky
<kenvandine> separating it from the source was "good enough"
<kenvandine> they said they couldn't guarantee they wouldn't revoke it... if it got abused
<kenvandine> but they said they wouldn't revoke it unless it was abused
<infinity> kenvandine: Same deal with flickr?
<kenvandine> we never talked to them about it
<kenvandine> afaik
<kenvandine> but we need it somewhere... better than in trunk
<infinity> I dunno.  I suspect the point's moot.  The "secrets" need to be there at some point, somehow, so they're never all that secret.
<kenvandine> infinity, right
<kenvandine> for open source apps... it's tough
<infinity> kenvandine: Even for closed source, it's no more secret.
<kenvandine> yeah
<infinity> kenvandine: If the secret has to be given to me by the app vendor (rather than having my own), then it's either compiled in or fetched somehow, and I can find it.
<kenvandine> it is really easy to find... segfault published most of twitter's own secret in one of his articles
<kenvandine> took him less than 10 minutes to find it
<infinity> strings | eyeball
<slangasek> this sounds like an uncomfortable habit
 * skaet drums her fingers waiting for ubuntu desktop to emerge on armhf....
<knome> skaet, in what rhythm? paranoid?
<skaet> knome, impatience with the speed.  :P
<infinity> Does this mean IS fixed celbalrai while I was asleep?
<skaet> infinity,  well it started....
<skaet> but that might explain it.   Can you check?
<infinity> Well, this morning it has a read-only filesystem, and some sort of make-it-gooder was being escalated for me by webops.
<infinity> Chasing that up.
<infinity> skaet: Nope, it's all fixed, just requires more patience. :)
<infinity> (If someone could accept that mlton sooner, rather than later, that would be nice, it's going to eat two buildds for the better part of a day)
<slangasek> infinity: can you make LP generate queuediffs faster? :)
<xnox> infinity: https://launchpad.net/ubuntu/+source/pandoc/1.9.4.2-2build1/+build/3744152 looks exactly the same as it did ~4h ago....
<xnox> infinity: never mind.... my browser is "overcaching"
<skaet> infinity,  looks like its being spit out now...
<infinity> slangasek: Sure.  Abraqueueudiffra.  They're faster now.  Enjoy.
<slangasek> infinity: huh?
<slangasek> queuediff relies on LP having already generated the diff
<infinity> Yeah, it just downloads it...
 * xnox ponders why armhf panda is building armel and confusing me.
<slangasek> right, so if it's not there yet that doesn't help
<slangasek> though in this case I simply forgot the -q quantal argument, thanks for the sass ;)
<xnox> infinity: https://launchpad.net/ubuntu/+source/pandoc/1.9.4.2-2build1/+build/3744152 looks stuck.
<infinity> Would probably be nice if, lacking a diff to download, it would fetch and diff instead.
<slangasek> infinity: dude why you wasting my time making me review a no-change rebuild
<infinity> slangasek: I asked someone to ACCEPT it, not review it!
<slangasek> mmhmm
<slangasek> pretty sure if you don't want review, you know how to do the accept yourself :)
<slangasek> (accepted)
<infinity> xnox: You're probably right.
<xnox> infinity: doko was hoping it would build...
<infinity> Sucks to be doko, I guess.
<doko> but why did it build on armhf?
<infinity> doko: Because GHC on armel is differently sad than on armhf.
<infinity> doko: Ask Laney.  I've been mostly ignoring that mess this cycle.
<xnox> infinity: at least doko got to keep his pythons ;-)
<Laney> colin said he was removing that
<Laney> if it's pandoc/armel
<xnox> yeap
<infinity> Right.
<infinity> Well, let me go free up that poor machine.
<TheLordOfTime> LTSes are every two years?
<TheLordOfTime> (8.04, 10.04, 12.04, kind of sets that assumptino)
<infinity> TheLordOfTime: So far, that's been the trend.
<TheLordOfTime> so unless something changes, 14.04's the next LTS?
<infinity> Yeahp.
<TheLordOfTime> cool.  thanks.  :)
<TheLordOfTime> just wanted to confirm before stating that "approximation of LTS release" standard in #ubuntu
<TheLordOfTime> :)
<tkamppeter> Can someone reject my HPLIP 3.12.6-3ubuntu4 upload? I have forgotten to fill the changelog entry in it.
<infinity> tkamppeter: Done.
<tkamppeter> infinity, thanks, new package will come in some minutes.
<cjwatson> kenvandine: that reminds me of one of my favourite Debian signature file entries
<cjwatson> <joeyh> # Note: the masterlist file is kept private since it contains
<cjwatson>         e-mail addresses
<cjwatson> * joeyh wonders again about the web team's drug levels
<cjwatson> <joeyh> "private" being a synonym for "in anonymously accessible CVS and
<cjwatson>         shipped on every Debian CD"
<kenvandine> :)
<tkamppeter> infinity, corrected version uploaded.
<skaet> gilir, lubuntu pre-candidate version has posted for alternates,  others coming.
<gilir> skaet, ok thanks
<ScottK> skaet: kdeplasma-addons should be in now.
<skaet> ScottK,  coolio.  Ok, starting that set off before I shift location.
<skaet> ScottK,  Kubuntu's started now.
 * skaet --> shifting location again now.
#ubuntu-release 2012-10-12
<skaet> infinity,  can you take a close look at the ubuntu desktop images, and verify all the points in the release checklist have actually been handled?      I'll be doing some updates as well.
<infinity> skaet: Yep, yep.
<skaet> thanks infinity :)
<cjwatson> slangasek: ^-
<cjwatson> parallel-accept-safe
<cjwatson> slangasek: If you could do debian-installer once grub2-signed has built and published, then I could go to bed :-)
<infinity> cjwatson: It just needs a rebuild?
<cjwatson> skaet: ^- that's the one
<cjwatson> infinity: Yeah
<infinity> cjwatson: I have the technology to do that. :P
<skaet> thanks cjwatson.
<skaet> thanks infinity
<cjwatson> So do I, but not the technology to stay up half the night again :P
<slangasek> cjwatson: yeah, we can take care of d-i
<infinity> cjwatson: Yeah, I realised that I'd been working for 24h when I went to bed this morning. :/
<infinity> (oops)
<slangasek> infinity: how much money did you raise for charity?
<skaet> :)
<infinity> slangasek: Two dollars and a discarded candy wrapper.
<slangasek> infinity: doing it wrong
<slangasek> so, this is interesting
<slangasek> cmp build/shim.efi.signed /usr/lib/shim/shim.efi
<slangasek> build/shim.efi.signed /usr/lib/shim/shim.efi differ: char 217, line 3
<slangasek> I'm quite certain that worked on the last binary
<cjwatson> Err
<cjwatson> Why would the signed and unsigned binaries be identical?
<slangasek> cjwatson: because I ran sbattach --remove :)
<cjwatson> Oh, and didn't change the filename :P
<slangasek> yeah
<slangasek> noted, will make that more obvious :-)
<slangasek> well hmm
<slangasek> downgrading sbsigntool and testing against the previous shim, the command fails in the same way
<cjwatson> So bug in new sbsigntool?
<cjwatson> Sucks to be Jeremy.
<slangasek> no
<cjwatson> Oh.  Reading comprehension.
<slangasek> possibly pre-existing bug in sbsigntool
<slangasek> but I swear I tested that part
<cjwatson> Then confused.  Did it actually work before?
<slangasek> maybe?
<slangasek> I have no logs to prove it ;)
<slangasek> need to look at the PE struct and see what's going on
<slangasek> fwiw the files are *largely* identical
<slangasek> -0000320 00 40 13 00 00 04 00 00 8d 0c 15 00 0a 00 00 00
<slangasek> +0000320 00 40 13 00 00 04 00 00 6a 8a 15 00 0a 00 00 00
<slangasek> -5112520 74 00
<slangasek> -5112522
<slangasek> +5112520 74 00 00 00 00 00 00 00
<slangasek> +5112530
<slangasek> aha, that's a length field, isn't it :)
<slangasek> grr
<cjwatson> All right, I'm off to bed.  Don't forget to accept those boot loaders. :-)  SMS me if there's a bug in my patch so that I can come back and fix it.
<slangasek> grub2 just accepted :)
<infinity> Was just about to click that...
<cjwatson> Yay.
 * infinity goes to have a spot of food instead of queue colliding.
<slangasek> and grub2-signed accepted
<skaet> :)
 * skaet stands by to kick off the full set of rebuilds,  once the publisher runs.
<ScottK> skaet: It'd be nice to get the first Kubuntu set out before you kick off another.
<skaet> ScottK,  Kubuntu set is building now and almost out.
 * skaet just went to check,   and yeah they are out.
<skaet> ScottK,  ^ they are available now.
<skaet> Kubuntu active build has started as well.
<ScottK> Thanks.  Will test shortly.
<skaet> :)
<infinity> skaet: Release checklist looks good from my end, BTW.  Looks like others took care of things while I was napping this morning. :P
<skaet> yup.   but a second set eyes (that are no longer sleep deprived) builds confidence.  ;)
<skaet> thanks
<cjwatson> slangasek: ^- grub2/amd64 waiting in unapproved there
<cjwatson> (I would be in bed but my daughter was suddenly ill ... :-/)
<slangasek> cjwatson: got it, thanks
<slangasek> cjwatson: aw :/
<infinity> Dearest libatomic-ops, PFO, kthx, no love, Me.
<skaet> cjwatson,  sorry.  :(
 * infinity is tempted to mail his magical Panda that CAN'T REPRODUCE THIS BUG to the DC to build this package...
 * ScottK stocks up on schadenfreud.
 * infinity beans ScottK in the head with a high velocity Panda.
<infinity> Tis driving me nuts.  I can understand not being able to reproduce the weird looping testsuite issue.  Seems entirely a timing thing, and maybe my Panda's just a little faster or something, I dunno.
<infinity> But then the segv that the buildds *all* see right after the loop doesn't happen.  That segv just doesn't exist here.
<infinity> Double-u, tee, eff.
 * skaet figures it all depends on the binsort of the part you've got on that panda, and its tollerances  :P
<wgrant> infinity, slangasek: Are you likely to miss a couple of publisher runs over the next few hours if we skip them?
<skaet> wgrant,  yes
<skaet> we're waiting on slangasek to review some grub2 patches,  and then get them built/published before kicking off the full set of candidate image builds.
<infinity> wgrant: Right now, yes.
<wgrant> Ah
<infinity> wgrant: Ask that again after a new d-i is built and installed, and the answewr's likely "no".
 * skaet nods
<slangasek> I guess I should expedite this shim-signed upload then :P
<wgrant> Thanks, will wait
<wgrant> We'd like to get some DB patches out before we can't do anything next week
<infinity> slangasek: Did d-i need to wait on your shim too?
<wgrant> But each means skipping a publisher run, basically
<infinity> wgrant: Understood.
<slangasek> infinity: yeah, it kindasorta does
<infinity> wgrant: We'll be a lot more slack pretty soonish.
<wgrant> Right, I thought you were already basically done in that respect
<infinity> slangasek: Then go forth and shimmy.  Colin implied I could d-i as soon as grub2-signed was published, so I'll back off the trigger. :P
<infinity> wgrant: Turns out that secure boot sucks and wants us all to die in the face.
<skaet> wgrant, no such luck.   blocker bugs discovered today.
<wgrant> Indeed
<slangasek> infinity: shim-signed uploaded to quantal-proposed; not sure a review is meaningful since the only diff is a binary blob, but if you want to accept that and then copy both shim+shim-signed from quantal-proposed to quantal once built, we should be good to go
<slangasek> (and sorry for the extra publisher cycle involved)
<slangasek> we could in theory push shim from quantal-proposed to quantal now and I could reupload shim to quantal instead of quantal-proposed if you prefer, but then the accept has to be delayed anyawy
<infinity> Meh, whatever.  I have nothing better to do tonight but delay wgrant's plans.
<wgrant> :)
<infinity> And, really, nothing fills me with greater joy.
<cjwatson> slangasek: Shouldn't necessarily be an extra publisher cycle.  I believe you can copy from accepted.
<skaet> slangasek,  you going to be around to review infinity's d-i?
<slangasek> skaet: yes
<skaet> :)
<skaet> thanks
<infinity> Not much to review.
<slangasek> cjwatson: oh, that's handy
<infinity> cjwatson: Can you?
<cjwatson> (I sometimes don't when being paranoid, but I really don't see why not.)
<wgrant> You can't copy binaries before the publisher runs
<infinity> ^
<cjwatson> Oh.
<wgrant> Binaries aren't published until they're in DONE
<cjwatson> Blast then.
<wgrant> Rather
<wgrant> Thank custom uploads :)
<infinity> Now, what you CAN do is time your copy so it happens between the two publisher runs.
<infinity> But that's tricky.
<wgrant> Right, if you're really fancy you can copy after process-accepted but before publish-distro
<infinity> And involves a lot of OOPSes while you hammer at trying to get it right. :)
<infinity> Not that I've done this...
<cjwatson> wgrant: Err.  The check for that appears to be after the bit that says "if it's the same series, the same archive, and include_binaries, then skip all further checks".
<wgrant> cjwatson: that doesn't mean it'll actually copy the binaries
<wgrant> It just means it won't create conflicting builds
<wgrant> The copier uses SPPH.getBuiltBinaries
<wgrant> Which returns a BPPH for each distinct BPR that's built by the source and published in the source's context
<wgrant> The BPPHs don't exist until process-accepted runs
<cjwatson> Oh, I missed that detail.
<cjwatson> Of course, still a PackageUploadBuild until then.
<cjwatson> Not that this is an insurmountable barrier, but it all starts looking rather like delayed copies if you aren't careful ...
<wgrant> Don't even think about it :)
<cjwatson> I think perhaps I should make attempt number two at going to bed instead.
<wgrant> We can create BPPHs at accept time if we make custom uploads sensible
<cjwatson> Yeah, custom uploads need a fairly substantial overhaul
<cjwatson> CustomUploadsCopier is a moderately decent band-aid by now, but it's fundamentally a hack ...
<wgrant> Pretty much
<wgrant> More hack than decent
<cjwatson> When really what it ought to be is "copy publication record, done"
<cjwatson> decent in the sense that it more or less meets our requirements
<cjwatson> despite sucking
<wgrant> Yes
<infinity> slangasek: shims copied, BTW.  Waiting on publisher run(s) now.
<infinity> slangasek: Say, do you have a non-ES Panda lying around with precise installed on it?
<plars> I think this is probably actually an ubuntu website bug, but bug #1065789 - I'm just getting sent to ubuntu.com when I click the release notes link
<ubot2> Launchpad bug 1065789 in ubiquity "release notes link in installer points to www.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/1065789
<slangasek> infinity: I have only an ES Panda
<skaet> infinity,  after publisher run,  d-i upload/build  then publisher,  then build isos?
<slangasek> skaet: precisely
<infinity> skaet: Yep.
<slangasek> though infinity could upload d-i now and let it sit in the queue until the publisher is done
<plars> more bothersome right now is that I can't install, at least in virtualization, if I've previously installed any other way besides lvm+crypted.  That seems to be bug #1065502
<ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman" [Undecided,Confirmed] https://launchpad.net/bugs/1065502
<infinity> slangasek: Dang.
<plars> I have to go kill the partitions manually before I can get it to proceed
<slangasek> infinity: ?
<slangasek> infinity: oh, the panda, not the upload - yep, sorry
<infinity> slangasek: Yeah, that. :P
<skaet> slangasek, infinity - any insight into the bug that plars is highlighting?
<slangasek> no insight
<infinity> Nein.
<slangasek> I can go digging and try to reproduce, but I need to step away for food first
<infinity> d-i bounce at the queue.
<infinity> bounced, too.
<plars> it seems to also happen if I'm trying to install on top of, or side-by-side with a precise system
<slangasek> skaet: btw, do you happen to have seen bug #1051306?  I've escalated it and targeted it, asking xnox to investigate; it's in a class of bug that potentially leaves the user with no way to get their machine back on the network if there are any bugs with Ubuntu drivers, so I think it needs to be followed up on before release and is a potential respin trigger
<ubot2> Launchpad bug 1051306 in os-prober "windows not found unless partion is mounted" [Critical,Confirmed] https://launchpad.net/bugs/1051306
<slangasek> it may also turn out to be a minor corner case that's been there forever and that we should ignore
<slangasek> but better safe than sorry
<skaet> thanks for flagging slangasek,  that one hadn't crossed my radar.
<infinity> Last thing in the syslog is udisks2 registering with dbus, can we blame pitti?
 * skaet adding it to the pad.ubuntu.com/ubuntu-release
<slangasek> stepping away for food now; back soonest
<skaet> k,  thanks.
<slangasek> infinity: is the publisher done?
<infinity> slangasek: Done enough for d-i to be building.
<infinity> Hence the self-accept up there.
<slangasek> ah
 * skaet was wondering who did... :P
 * slangasek goes back to his dinner :P
<infinity> Om nom nom.
<infinity> Fun.  armhf missed the publisher by about 5 seconds.
<ScottK> Wasn't the goal maximizing your interference with wgrant's plans anyway?
<infinity> Fair point.
<skaet> infinity,  can I turn over the kicking off of the full set of rebuilds to you?
<infinity> skaet: Sure.
<skaet> Thanks.
<skaet> I think I've got the pad updated to the key points now,  but if you spot anything else,  please add.
<infinity> Sure.  I'll mostly just be kicking things off and going away.
<infinity> But if something comes up...
<skaet> there have been a couple of somethings...   see the bugs on the pad.    any of them you can help with?
 * micahg hopes the publisher will be available in ~3.5 hrs
<infinity> skaet: Not sure on the 3 installer bugs listed at this point, though I may look into one or two later.  Certainly not for this round.
<skaet> ack.
 * skaet --> zzz 
<infinity> wgrant: All done with the publisher for now.
<infinity> wgrant: For bonus points, it overlapped by 2m, so it's not running right now.
<wgrant> infinity: Heh, thanks
 * infinity rules out lp-buildd's sbuild in his libatomic-ops hunt, and starts running out of ideas.
<wgrant> That's still not solved? :/
<infinity> wgrant: Depends on which "that".
<infinity> wgrant: Fixed it on i386, only to discover that it's now broken on armel.  But.  Only on the buildds.
<infinity> wgrant: Several different machines/setups/etc, and I can't reproduce at all.
<infinity> So frustrating.
<wgrant> (publisher disabled now, but should be back before the next run anyway)
 * slangasek eyes the build failures
<slangasek> where'd security.ubuntu.com go?
<infinity> Yeah, I was just seeing that.
<infinity> Oh, is that what failed the world?  Hadn't look at logs yet.
<infinity> slangasek: I need to take off soonish, might need someone else to restart this mess later.
<slangasek> infinity: just doing the stuff from the pad?
<infinity> Also curious if I can safely interrupt all of this...
<infinity> Probably, it'll just let the current livefs builds spin and quit, I assume.
<infinity> slangasek: Yeah, was just all 3 pipelines.
<infinity> slangasek: Though, I'll be back later tonight, I can re-spin before I nap.
<infinity> I might pick up that ubuntu-release-upgrader in proposed while I'm at it.
<slangasek> as long as we're waiting for Godot to fix security.u.c, why not
 * stgraber waves from the other side of the ocean
 * infinity waves back.
<wgrant> slangasek, infinity: Will you mind if we kill generate-contents-files today? We've run into its window now.
<slangasek> wgrant: I don't think we mind
<wgrant> That's what I suspected
<wgrant> DB update is done, publisher reenabled
<slangasek> wgrant: thanks
<slangasek> so since we're still waiting for security to be usable again, copying ubuntu-release-upgrader to -release
<ScottK> Finally got an ISO download finished.  I really miss my FIOS when I'm not at home.
<infinity> slangasek: It was already copied.
<infinity> slangasek: Notice your sync was [1:0.189 => 1:0.189]
<slangasek> infinity: erm; I guess the bot didn't notice because of the connectivity problems
<infinity> slangasek: The bot didn't notice because mine didn't go through the queue.
<slangasek> ah
<slangasek> infinity: mind letting the rest of the channel know what you're doing then, since it's hidden from the usual notification system? :)
<infinity> slangasek: Ahh, I thought I'd implied strongly enough that I was doing the copy. :)
<infinity> slangasek: No big deal.  Two won't hurt. :P
<slangasek> infinity: perhaps "might" expresses a different verb tense up north ;)
<infinity> Also, this pipeline is so going to completely run its course...
<slangasek> are you getting successful builds out?
<infinity> slangasek: "I might go out for poutine" is our way of saying "OH GOD, CHEESE CURDS AND GRAVY NOW".
<infinity> slangasek: Yeah, since that first batch of failures, everything else has been a success.
<slangasek> mmk
<infinity> slangasek: http://paste.ubuntu.com/1274384/ <-- progress, so far.
<infinity> If those end up being the only failures, cherry-picking some retries shouldn't be hard.
<infinity> slangasek: I'll be back in a few hours, I'll check my terminals and see what needs tidying.
<infinity> slangasek: Feel free to, like, sleep or something.
<slangasek> I will when I'm done fighting with sbsigntool
<infinity> Trying to fix the signature removal not returning the binary to its original state thing?
<slangasek> yes
<slangasek> concluded it's not (reasonably) possible because there's undeclared padding being added so we don't know the size of the pre-signed binary
<slangasek> I mean, *we* know it, but sbattach doesn't
<slangasek> so instead I'm going to see about recreating the signed binary using the extracted pkcs7 blob plus the original binary
<infinity> Your diff looks like more than just padding, though.
<slangasek> it's the padding, plus the resulting checksum
<slangasek> where the checksum algo adds in the file size at the end
<slangasek> also, I'm having to implement the checksumming
<infinity> Ahh.
<babyface> slangasek, for bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985634, I think it's obvious and easy to fix, could you have a look on it?       I(victor zhou) add some translation suggestion  here:  https://translations.launchpad.net/ubuntu/quantal/+source/apt/+pots/apt-all/zh_CN/498/+translate
<ubot2> Ubuntu bug 985634 in apt "Wrong translation during the installation process of Ubuntu 12.04 with choosing Simple Chinese as the installation language" [Low,Triaged]
<babyface> but don't know how to make it used in the current build
<slangasek> skaet: ^^ it looks like we have some bad translations in apt, which requires an apt package upload; this normally should be done immediately after the non-langpack translation deadline by somebody pulling the translations from launchpad and uploading, but apt wasn't on anyone's radar for this
<slangasek> skaet: should we pull this in?
<infinity> slangasek: If you hand-verify the diff to make sure the strings aren't broken.
<infinity> (Well, or lint them)
<slangasek> babyface: your comment on the bug also indicates that you've made a suggestion, which would not result in any changes to the translation export.  Someone on the translation team would need to ack this suggestion first...
<slangasek> infinity: hey, I always review all translations before uploading them.  My question was about the timing, because this would definitely push back the start of candidate images
<infinity> slangasek: I'd push to proposed, if I were you, and we'll pull it in as soon as we have another reason to rebuild (which, let's be realistic, we'll find one).
<slangasek> well
<slangasek> my hands are full, I'm not pushing it to proposed tonight
<infinity> And if we don't, well.  We can decide if it's worth rebuilding just for apt.
<babyface> slangasek, yes, I  talked this in #ubuntu-cn-translator, but got no reply   ;(
<ScottK> Bug #1065827 is a "It would really suck to release this way" bug.
<ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
<ScottK> Kind of need to get the network working from the ISO.
 * infinity blinks at https://launchpad.net/ubuntu/+source/grub2-signed/1.6/+build/3898519
<infinity> ^-- How did that only just finish 29 minutes ago?
<infinity> And did this just invalidate all our builds?
<slangasek> babyface: I would suggest talking to dpm, the Ubuntu translations coordinator, to see if he can help get this fixed
<slangasek> babyface: as a rule, I don't put myself in the middle of translation disagreements for languages I don't read
<micahg> infinity: amd64 wasin depwait
<infinity> micahg: Yeah, I'm assuming that, but on what?  grub2 finished 5h previously.
<slangasek> infinity: yes, yes it does
<infinity> Unless the auto-dep-waity cronjob was busted. :/
<micahg> infinity: the -bin package I thing
<slangasek> it would have been dep-wait on grub2 if anything
<babyface> slangasek, "dpm" ?  a person? which channel to find him ?
<infinity> slangasek: Yeah, it would have been, but like I said, that finished 5h ago.  So, ugh.  Something went south here. :/
<slangasek> babyface: David Planella; I think it might still be a little early for him to be around, but he can generally be found on #ubuntu-devel among others
<babyface> slangasek, ack. thanks.
<slangasek> infinity: I'm trying to think if this invalidates the d-i builds
<slangasek> or if it's just the images
<slangasek> I don't think d-i uses grub2-signed
<infinity> It doesn't use grub at all.
<slangasek> yes it does
<infinity> Except to pull in grub-installer.
<slangasek> incorrect
<slangasek> it generates EFI-bootable images
<infinity> Oh.  Right.
<infinity> EFI things.
<slangasek> but it does that by pulling them directly from archive.u.c
<slangasek> so if those were up-to-date, it should be ok
<slangasek> but I'm not sure how to check that other than by peeling apart the tarball
<infinity> The build log could help.
 * infinity goes a'greppin'.
<infinity> The log seems less than helpful here.
<infinity> slangasek: Yeahp, it was current.
<infinity> slangasek: The log wasn't helpful on the efi.signed bit, but it did show that the current grub2 was the latest, and then the actual code in d-i checks apt-cache policy and grabs the efi bits from the mirror from the versioned directory matching the grub2 it just installed.
<infinity> slangasek: So, that seems all good.
<infinity> slangasek: But all our amd64 ISOs certainly will need rebuilding.
<slangasek> yes
<slangasek> well, at least it's just amd64
<infinity> Still getting intermittent failures anyway, so IS is still not done.
<infinity> Right.  Back in a whileish.  Will redo the world anyway, since we accepted new packages.
<infinity> Or, a new package.
<slangasek> did we?
<infinity> ubuntu-release-upgrader
<slangasek> ah, so that was after the builds started
<infinity> Yeah, it was after we noted the issues with security.u.c
 * slangasek nods
<infinity> 22:59 < infinity> I might pick up that ubuntu-release-upgrader in proposed while I'm at it.
<infinity> 22:59 < slangasek> as long as we're waiting for Godot to fix security.u.c, why not
<infinity> Anyhow, that hits pretty much every image, so once the buildds quiet down (or, if I get IS to slap them around for me), I'll restart the mess.
<infinity> Once security/archive are also known-sane.
<infinity> Which doesn't seem true yet.
<infinity> So, back in a bit.  Respinning when I get back, ish.  Toodles.
<ScottK> balloons: We need the "Install (entire disk with lvm and encryption)" test case added for Kubuntu live builds.
<ScottK> infinity: When you get back, would you please look at Bug #1065827 and assign it to the right piece of the build infrastructure?
<ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
 * ScottK needs to go to bed.
<babyface> slangasek,  translation  suggested by me was reviewed by some guy in the translator team just now, so the change will affect in next build?
<jibel> ScottK, testcase added as mandatory
<ScottK> jibel: Thanks.
<ScottK> OK.  Bed time.
<Daviey> infinity: if you are still around, what was the fun and games building livefs?
<didrocks> Laney: hello, here is the change we discussed about the legal notice. It's been tested by 5 persons, (english and french locale) to confirm the correct locale is picked up. The html file just have few changes since yesterday's push to the ppa regarding the comments. No code change. (see linked bug) ^
<didrocks> cjwatson: hey, it seems Laney isn't around today, maybe you can have a look? (it's something on skaet's radar and legally required)
<didrocks> Daviey: ^ (continuing my small route of hunting release team people :p)
<xnox> skaet: I am marking bug 1065789 as ubiquity correctly reads the URL from the iso, and correctly goes there. The website then redirects to the homepage instead of quantal release notes.
<ubot2> Launchpad bug 1065789 in ubiquity "release notes link in installer points to www.ubuntu.com" [High,Invalid] https://launchpad.net/bugs/1065789
<xnox> skaet: I don't know the "making the release steps" so I don't know if the link was meant to be working already.
<xnox> skaet: it would be nice to make that link work through all the milestones though =/ not just final images.
<Laney> didrocks: yeah, sorry, I'm off today and won't have time to review
<didrocks> Laney: no worry :)
<Daviey> didrocks: hola
<didrocks> Daviey: hey hey :-)
<Daviey> didrocks: I am on holiday today...
<Daviey>  .. nah, just kidding :)
<didrocks> argh, you too?
<didrocks> tsss :p
<didrocks> Daviey: I would have continued my fallback list otherwise :p
<Daviey> didrocks: This is the unity upload in the queue?
<didrocks> Daviey: right, do not hesitate if you have any question
<cjwatson> didrocks: mm, yeah, sorry, better somebody who's more awake deals - security vuln last night and then was up half the night with a sick child
<cjwatson> somebody will probably need to add it to the pad as a rebuild trigger I guess
<pitti> so, skaet asked me to take bug 985634
<ubot2> Launchpad bug 985634 in apt "Wrong translation during the installation process of Ubuntu 12.04 with choosing Simple Chinese as the installation language" [Low,Triaged] https://launchpad.net/bugs/985634
<pitti> that means pulling the updated translation into apt and doing an upload
<didrocks> cjwatson: no worry, good luck with your child. I hope they'll get better soon
<pitti> infinity: ^ I think you already discussed that some hours ago?
<pitti> or is that just a minor thing not worth respinning?
<didrocks> Daviey: basically, it's the same version that QA tested on the ubuntu-destkop ppa yesterday. I just fixed some html links (no code change) since.
<Daviey> didrocks: is there a screenshot of the change in action?
<didrocks> Daviey: can do some, one sec
<cjwatson> xnox: invalid is incorrect, as it is still a bug although not in ubiquity.  I've reassigned to the proper place.
<cjwatson> deleted bug 1065789 from the list of potential respin triggers, as a website fix will not require a respin
<ubot2> Launchpad bug 1065789 in ubuntu-website-content "release notes link in installer points to www.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/1065789
<seb128> pitti, images will be respined anyway, there is an unity update that needs to go in
<pitti> it affects all images, though; server, flavours, etc.
<seb128> pitti, the shopping stuff needs a pointer to details about "what we do with your datas" to confirm to some UE laws
<pitti> don't get me wrong, I'm not particularly pushing here; if you guys say "don't bother", I'll be more than happy :)
<xnox> cjwatson: ok. I was not sure, hence mentioned it here.
<seb128> confirm->conform
<xnox> seb128: UE -> EU
<seb128> xnox, not in french :p thanks ;-)
<skaet> pitti, from my understanding from the backscroll,  I think the best course is to put it in -proposed,  and then we'll pick it up if possible.
<xnox> seb128: well conform is not in frech either ;-)
<seb128> dammit
<Laney> ah, it only shows once, that's better than I feared
<didrocks> Daviey: http://people.canonical.com/~didrocks/tmp/legal1.png this is the first time you open it
<didrocks> Daviey: once you clicked on the link, you get the webpage opened and then further dash opening will show http://people.canonical.com/~didrocks/tmp/legal2.png
<didrocks> clicking on the (!) icon opens the webpage again
<Daviey> didrocks: I assume legal have ack'd the implementation as suitably closing the bug?
<didrocks> Daviey: yeah, legal and design worked together on how this should be presented
<pitti> skaet, infinity: apt uploaded to -proposed queue FYI
<skaet> thanks pitti
<Daviey> didrocks: another upload on the way?
<didrocks> Daviey: I dputed -f 10 minutes agoâ¦ waitingâ¦
<didrocks> and checked the terminal that it took enough coffee :)
<Daviey> didrocks: sure it hasn't been rejected ?
<didrocks> Daviey: didn't get any email either
<Daviey> I would have expected it to show by now.. ok, will wait another 5
<didrocks> Daviey: I can try to dput again (but the last command succeeded)
<cjwatson> Launchpad was just down briefly for a database update
<Daviey> ah
<wgrant> Yeah, cronjobs will be back on in a couple of minutes
<cjwatson> So I expect the queue cron jobs were off
<didrocks> cjwatson: does it catchup or it's going to the void? :)
<cjwatson> It'll catch up
<didrocks> ah ok :)
<didrocks> thanks cjwatson, wgrant
<didrocks> Daviey: I was starting to think I needed to EOW now :p
<Daviey> didrocks: Can you add your screenshots to the bug report, and email ubuntu-docs to let them know.  I suspect it doesn't matter if they refresh the images or not for this, but they'll judge that.. It's clearly more important it lands.
<wgrant> Right, we just stop processing incoming for 10-15 minutes around DB upgrades. It'll process the queue as soon as it's turned back on
<didrocks> Daviey: indeed, doing it now
<Daviey> super
<cjwatson> wgrant: Although process-upload was apparently never turned off; I assume it's an earlier stage
<cjwatson> Oh, ignore me, I can't read
<cjwatson> "Disabled by DEFAULT section"
<wgrant> Yeah
<cjwatson> didrocks: it's in the queue now
<wgrant> We turn them off centrally with a config file now
<cjwatson> Yeah, I knew that but forgot :)
<wgrant> Rather than having to push out new crontabs to 20 machines
<didrocks> thanks :)
<didrocks> Daviey: ^
<Daviey> didrocks: will be lazy and wait for lp to generate a diff for me. :)
<didrocks> heh ;)
 * infinity catches up with the queue.
<infinity> pitti: Did we not want to refresh all of apt's translations?
<infinity> pitti: Rather than just the one?
<pitti> infinity: not sure, I was rather cautious
<infinity> pitti: Could you do a full import and see how big/scary the diff is?
<xnox> isn't apt in a langpack anyway?
<pitti> infinity: I guess we could, if you prefer that
<pitti> xnox: well, it is because it's not that trivial to filter out, but we ship the mo files in the apt package
<xnox> I see, ok. plus for the installer we want more langs than langpacks.
<infinity> pitti: I'd like to see the results of such an import, I guess, then I can decide which one to take. :P
<pitti> "Your request has been received. Expect to receive an email shortly."
 * infinity tries to sort out why libmotif bumped SOVER if it's supposedly binary compatible with the previous version...
 * infinity holds off on re-re-spinning until the apt translations are sorted out.
<wgrant> (that translation export finished a few minutes back, so the email should be there)
<infinity> wgrant: Stalker.
<infinity> Hey, I think pypy might actually build on armhf this time around.  Neat.
<wgrant> Just wanted to clarify that Launchpad really did mean "shortly" this time, and you don't have to wait for 3 hours :)
<xnox> wgrant: you remind me of the xkcd comic about progress dialog.
<infinity> cjwatson: I'm torn between "tear out cairo-5c from the archive, and its one rdep" and "beat Keith with a stick until he provides a source package that's (a) not crack, and (b) builds".
<infinity> Oh, I may have spoken too soon on pypy, it still has a day to go...
<didrocks> skaet: as unity will need to be rebuilt anyway and we need to respin an iso, can you have a look if we can sneak gsettings-desktop-schemas in? It fixes bug #1060249 which will be triggered by a lot of upgraders if they have a debconf question. It's a revert of a previous upload to readd a deprecated gsettings schema. ^
<ubot2> Launchpad bug 1060249 in debconf "frontend crashed with signal 5 in free_pending_nulls()" [High,Confirmed] https://launchpad.net/bugs/1060249
<didrocks> jibel: FYI ^
<infinity> didrocks: Impressive duplicate list.
<infinity> didrocks: Where's the diff?
<didrocks> infinity: isn't it? quite surprising we didn't see it on our radar first
<jibel> there are much more but all set to invalid because retracing failed
<pitti> infinity: http://people.canonical.com/~pitti/tmp/apt-translation-refresh.patch FYI
<didrocks> infinity: http://paste.ubuntu.com/1274710/
<infinity> didrocks: Anyhow, if you're confident I'll like the diff, upload now, so I can get it built.
 * xnox so wants that bugfix in. Isn't it one of the top crashes on errors?
<pitti> infinity: caution, 5 MB beast
<didrocks> infinity: it's in unapproved
<didrocks> infinity: the diff is trivial, and I built and installed it to check that the schemas indeed is there then (and seen by gsettings)
<infinity> didrocks: It's just an upgrade ordering issue?
<infinity> didrocks: Couldn't a Breaks solve this for you?
<jibel> xnox, does errors.u.c reports crashes that failed to retrace ?
<didrocks> infinity: right, we try to do that on the safe side, because for next LTS, we'll need to transition it anyway
<didrocks> infinity: and for that, we need the old schema around
<skaet> didrocks,  I'll go along with infinity's recommendation on this one.  (that is an impressive list of duplicates indeed.  :P )
<xnox> jibel: if you ask ev, he tells you the numbers =)
<didrocks> thanks skaet :)
<jibel> ev, ^ did errors.u.c catch #1060249 ?
<cjwatson> bug 1065827 - oh dear, I think that's a casper bug
<ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,Invalid] https://launchpad.net/bugs/1065827
<cjwatson> and a nasty one - I saw it on Ubuntu too
 * infinity tries to filter the noise out of that apt diff so he can read it before Tuesday...
<didrocks> thanks infinity :)
 * cjwatson adds 1065827 as a respin trigger and gets fixing
<skaet> thanks cjwatson.
<infinity> pitti: Yeah, pull the trigger on the refresh, assuming some po-linting thing thinks that's all formatted correctly.
<infinity> pitti: I saw a ton of strings in there with obvious fixes.
<infinity> (And I only read a few languages)
<pitti> infinity: LP does some consistency checks, yes
<cjwatson> pitti: Well, um, I'm not quite sure what's going on here with bug 1065827
<ubot2> Launchpad bug 1065827 in casper "Kubuntu 12.10 bcmwl install failure" [Critical,Triaged] https://launchpad.net/bugs/1065827
<cjwatson> The first part is a casper bug
<cjwatson> It's checking for /.disk/info rather than /root/cdrom/.disk/info
<cjwatson> So that much is an easy fix
<pitti> infinity: so do you want to reject the current upload then? Then I'll alter history in bzr
<cjwatson> After I do that, software-properties -> Additional Drivers is able to apply the change to bcmwl-kernel-source
<infinity> pitti: Alter away.
<cjwatson> But it doesn't actually load the wl module
<cjwatson> And if I load the wl module, I don't appear to get a wireless interface
<pitti> cjwatson: is that the same problem? i. e. apt not finding/using the package on the CD pool?
<cjwatson> The casper fix deals with that part of it
<pitti> your's sounds like you'd be a lot further
<cjwatson> We seem to have a pyramid of fail, though
<cjwatson> And I can't find much in the way of useful logs
<cjwatson> I have to fix casper anyway since that bug's likely to have all kinds of weird side effects, and it's a clear identified regression
<pitti> hm, it's green on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubuntu-drivers-common/lastSuccessfulBuild/ARCH=i386,label=albali/, but we only check that "modinfo wl" works
<pitti> not that it gets autoloaded or actually works (that wouldn't work in those tests)
<cjwatson> Do you have a system where you can reproduce this, or would it be helpful to teleoperate me?
<cjwatson> I was actually trying to reproduce a completely different bug, but seeing as I'm here ...
<pitti> cjwatson: ScottK says it happens in the kubuntu live system
<cjwatson> I'm running today's Ubuntu desktop amd64 image, from USB
<pitti> but that applied to the earlier problem of not finding the packages in pool
<cjwatson> With the casper fix applied manually using break=casper-bottom
<pitti> cjwatson: let me download the current i386 and test on my netbook
 * pitti trying to do 5 things at once
<cjwatson> Boot with break=casper-bottom, run   sed -i 's,.disk/info,root/cdrom/.disk/info,' /scripts/casper-bottom/41apt_cdrom   and exit 0
<cjwatson> You should then get a sensible sources.list
<pitti> infinity: I uploaded a new apt_0.9.7.5ubuntu3.dsc with full LP export
<infinity> pitti: Danke.
<cjwatson> I'll try i386 in case there's a difference
<pitti> cjwatson: I can try it on my atom netbook which is i386 only
<infinity> Oh crap, that apt was to proposed, I didn't even look.
<infinity> Oh well.
<cjwatson> I suspect we have enough to do that it won't matter that much
<pitti> infinity: wasn't it supposed to be?
<infinity> Yeah, it's just the cycle to squeeze it in when I notice it's done everywhere. :P
<infinity> pitti: Nah, we knew a respin was coming up anyway, so faster is better.
<pitti> infinity: copying requires publication in -proposed first?
<infinity> pitti: Yup.
<infinity> pitti: Can't copy unpublished binaries.
<pitti> infinity: ah, sorry; I got asked to upload to -proposed
<infinity> pitti: Nah, s'all good.
<infinity> pitti: Just blaming myself for not noticing the target. :)
<cjwatson> pitti: identical symptoms here on i386
<pitti> cjwatson: still waiting for usb-creator to finish
<pitti> cjwatson: so module builds fine, but doesn't actually work?
<cjwatson> why bother, just dd it
<pitti> ah, right; old habit
<cjwatson> indeed
<cjwatson> the PCI ID is 14e4:4315, which is in the list if I'm reading modinfo correctly
<cjwatson> Of course worth checking on your machine in case it's something bizarrely specific to this card ...
<pitti> right, otherwise neither jockey nor u-d-common would even detect it; it reads the modaliases from the pacakge header, which come straight out of modinfo
<cjwatson> slangasek: BTW, following last night, what's our dbx update plan for 12.10?
<infinity> Whoa.  Haven't seen the chroot tarball uncompress failure in ages.
<infinity> I thought it was gone. :/
<pitti> erk, apt armhf FTBFS?
<pitti> oh, CHROOTWAIT; I guess that's what infinity is looking at
<infinity> Uh, everything on meissa for a long while.
<infinity> Yeah, fixing.
<cjwatson> Oh my, yes.
<cjwatson> infinity: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3842217 is spurious data corruption too
<skaet> side effect of the launchpad work earlier?
<infinity> No.  side-effects of Pandas being awful.
<skaet> k  :P
<infinity> Nothing new there, just sad that it's not magically resolved in the last year or two.
<cjwatson> Yeah, been seeing it for ages.  It's just annoying.
<cjwatson> Although I do worry that it might show up for, like, real users.
<cjwatson> Launchpad database changes would have to be really inventive to manage to cause build failures; the build slaves are at arm's-length.
 * xnox ponders if I am a real or an unreal user.
<wgrant> Yeah, dropping DB tables and columns doesn't tend to corrupt files on buildds like that :)
<pitti> cjwatson: product ID 4315 here as well; seddery worked fine, package installed from pool; but just as you modprobe wl doesn't actually do anything
<infinity> wgrant: "Doesn't tend to" isn't ruling out the remote possibility.
<pitti> cjwatson: that worked in earlier releases, seems our bcmwl isn't compatible with our current kernel any more?
<wgrant> infinity: It's difficult to rule anything Launchpaddy out with certainty...
<cjwatson> Yeah, but there's also no point in postulating magic causes.
<cjwatson> pitti: I'm also suspicious about why wl wasn't auto-loaded; what's supposed to do that?
<cjwatson> (This may be a complex of three bugs, not two ...)
<pitti> cjwatson: normally udevtrigger at boot
<pitti> cjwatson: I suppose ubiquity's magic to build it for you in the background before it offers you to choose a network does a manual modprobe?
 * pitti RTFS
<cjwatson> Err
<infinity> pitti: udev isn't retriggered after we build modules?
<cjwatson> I mean, what's supposed to do that when you run software-properties to enable the proprietary module
<cjwatson> That's clearly neither boot nor ubiquity
<pitti> hm, I see nothing in bcmwl's postinst
<cjwatson> Didn't jockey use to do it, or am I misremembering?
<pitti> yes, it did
<pitti> but even after modprobe, I wonder why it doesn't actually detect any device
<cjwatson> So is it not a bug that the jockey replacement fails to modprobe?
<cjwatson> I agree that the failure to detect the device is yet another problem
<pitti> oh, it is a bug
<cjwatson> But currently you've changed the bug state such that there doesn't appear to be a bug task for the lack of modprobe
<pitti> it'd need to go into the postinst
<cjwatson> Oh, you think it should be there?  OK
<pitti> i. e. some clever udevadm trigger, perhaps not just a blunt modprobe
<pitti> well, my goal is to have "apt-get install bcm.." DTRT
<cjwatson> OK
<pitti> that doesn't affect the graphics drivers, but it does affect wl
 * cjwatson draws #ubuntu-kernel's attention to it
<infinity> Maybe udev itself needs a dpkg trigger that driver-related packages can register with (though that's way out of scope for a week before release)
<infinity> So we can just do one big udevadm at the end of a run.
 * pitti takes notes in the bug
<pitti> I'll figure out an udevadm invocation and post it there
<pitti> cjwatson: ooh
<pitti> cjwatson: it gets claimed by the b43 driver
<pitti> so bcmwl installs the blacklist file just fine, but apparently the postinst doesn't rmmod them
<pitti> right now that package is designed for "works after reboot"
<cjwatson> Ah, good catch
<pitti> yep, that's it
<cjwatson> Yes, modprobe -r b43; modprobe wl works
<pitti> rmmoding b43 ssb, modprobe wl, et voila
<cjwatson> Just after I'd unearthed a spare Ethernet cable :-)
<pitti> hmm
<pitti> the postinst actually has that already
<pitti> ah no, I misread
<cjwatson> Only if b44's loaded
<pitti> right, but that's just written into the blacklist file, not executed
<cjwatson> Well
<cjwatson> Since it's an 'install wl' rule, it'd be executed on modprobe wl
<pitti> so it seems to me the straightforward fix owuld be to add the rmmod || true and modprobe wl || true to the postinst
<cjwatson> If it had been written
<cjwatson> Which it hasn't
<pitti> cjwatson: what you see there is just a workaround for loading b44 and wl in the right order
<pitti> but that's just written into a modprobe.d file; it doesn't do anything to "run" those
<pitti> I followed up to the bug again
<pitti> want me to create/test/upload a fix?
<cjwatson> Like I say, 'install' commands in modprobe.d files are executed if the corresponding module is loaded
<cjwatson> I agree it doesn't do anything to load the module
<cjwatson> Sure
 * cjwatson moves on to the next bug :)
 * apw smiles ... great
<infinity> cjwatson: debian/rules reinvoking itself?  That seems an unorthodox way to write that. :P
<cjwatson> infinity: I was matching binary-arch
<cjwatson> It's certainly not the way I'd ordinarily write it, but when in Rome
<infinity> I was waiting for you to say it matched context, so I could die a little inside.
<cjwatson> That rules file is pretty awful.
<cjwatson> dh solved so many ills by getting people to throw away their inability to write make.
<infinity> Yeah, I'm wishing I hadn't read the context.
<pitti> infinity, cjwatson: bcmwl to release or -proposed?
<cjwatson> release
<pitti> uploaded
<pitti> admittedly I did some shortcuts to the testing; dpkg --unpack, scp the new postinst, and dpkg --configure -a
<pitti> (faster than tryign to set up a full build env on the netbook)
<pitti> that caused NM to see the device/networks right after configuration now
<infinity> dpkg-deb -R && edit DEBIAN/postinst && dpkg-deb -b && dpkg -i
<infinity> ^-- How I prefer to test maintscript mangling.
<infinity> And kinda required if it's a preinst instead of a postinst.
<cjwatson> I did not know about -R.
<cjwatson> Learn something new ... some days.
<infinity> cjwatson: I didn't until slangasek hit me with an RTFM bat after I mentioned I used ar and tar.
<cjwatson> Oh, this is cheating, it was added after 1999
<infinity> I think it's "new".  Which means "been around for years, but not since 199... Jinx".
<cjwatson> (Specifically, in September 2011)
<cjwatson> dpkg 1.16.1
<infinity> Oh, not even years.  Year.
<infinity> I don't feel so bad.
<infinity> But yeah, it's pretty handy.
 * infinity wonders if everyone goes through a phase of using ":" for "true" when they realise they're essentially synonymous builtins in most POSIX shells.
<infinity> Except, y'know, : is only readable to people with good eyesight. :P
 * skaet hands infinity a cup of coffee, as she pours one for herself.
<infinity> At this time of night, a gin would be more appropriate.
 * skaet hands infinity some "english coffee" then,  ;)  http://www.drinksecrets.com/drinks/english-coffee/d483
<infinity> Sounds like a poor man's Massive Destruction Weapon.
<skaet> yeah,  it is interesting what google turns up from paired keywords.  ;)
<infinity> There's pretty much no way to respond that and not make it dirty, so I'll refrain.
 * skaet laughing too much to type properly.
 * ogra_ would leave the coffee out of that reciepe and keep it for the next morning though
<ogra_> intresting that english coffee needs an irish glass :)
<infinity> The UK is a confusing place.
<infinity> I'm sure it's best served with cheese toasties too.
 * infinity glares at this ghostscript build to get it to finish before :33
<infinity> Hey, glaring worked.
<ogra_> heh
<skaet> infinity,  worth copying apt over from -proposed?
<infinity> skaet: Yeah, can't until after it publishes.
<infinity> I'm taking ghostscript too, hence the glaring.
<skaet> k
<infinity> So, in an hour or less, I'll be respinning the world, unless anyone has anything else that's a showstopper.
<didrocks> "world creator", that's impressive :)
<cjwatson> plars: I've chased the release notes symlink with the web team - it should be sorted later today
<cjwatson> infinity: I'd like to chase bug 1051306
<ubot2> Launchpad bug 1051306 in os-prober "Windows not found unless partition is mounted" [Critical,Confirmed] https://launchpad.net/bugs/1051306
<cjwatson> Currently restoring my sacrificial Windows install to see if I can reproduce it
<infinity> cjwatson: Alright.  If you make any progress (or complete lack) in the next hour, poke me.
 * infinity copies apt and ghostscript.
<cjwatson> :/true> : is defined as being a special built-in rather than a regular built-in, so it's marginally different
<infinity> cjwatson: In some shells, they're the exact same codepath, but yes, I realise they're not necessarily identical.  In the case of "foo || [blank]", though, "true" is the more readable option.
<cjwatson> I do tend to use "true" there, yes.
<infinity> (That was what I was poking fun at pitti for, he had "|| :" in that last upload.
<infinity> )
<pitti> infinity: c'est ne pas bon?
<pitti> infinity: I can reupload with || true if you prefer, but || : seems quite common in our scripts, too
<infinity> pitti: I accepted it, it's bon enough.
<pitti> the rmmod will always fail, as not all of the specified modules can be loaded at the same time (or even exist)
<pitti> so at least it survived the dpkg -i tst
<pitti> test
<infinity> pitti: Anyone who knows POSIX shell knows what it means, and anyone who doesn't should learn.  I just find || true more readable, personally.
<pitti> yeah, old "shell builtin vs. external program" thingy
<tkamppeter> slangasek, hi
<infinity> pitti: true is a builtin in most shells.
<infinity> pitti: It's /bin/true that isn't. :P
<pitti> infinity: yeah; I guess I shoudl change my habits
<pitti> we all know how easy that is!
<cjwatson> Also I prefer 'modprobe -r' to 'rmmod'
<cjwatson> But too late now and it should do
<infinity> pitti: Yeah, my habits need a pretty solid reason to change, generally.
<pitti> cjwatson: OOI, what's the difference?
<infinity> Plus, muscle memory.  Like, I've never switched to debuild from dpkg-buildpackage (for instance), not because I find debuild technically inferior (though it has some questionable defaults) but just because I type "dpkg-buildpackage -i -I -rfakeroot -uc -us -S -nc" so quickly, it's frightening.
<cjwatson> Very minor :-)
<cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
<infinity> And I'm pretty sure all or most of those switches are no longer necessary, even.
 * infinity glances at the nvidia flood.
<cjwatson> Oh, also special built-ins aren't guaranteed to be usable with execve.
<cjwatson> And regular built-ins can be preempted by functions, but special built-ins can't.
<cjwatson> true () { false; }
<infinity> On the other hand, if you redefine true(), you kinda deserve what you get.
<cjwatson> ^- how to confuse anyone reading your shell script
<infinity> Which is likely a punch in the face.
<cjwatson> Huh
<cjwatson> Actually, I think bash is non-compliant here
<cjwatson> You can redefine : in bash ...
<cjwatson> dash won't even let you try - you get "bad function name"
<cjwatson> But you can redefine, say, fg in dash too
<cjwatson> Oh, no, that's a regular built-in
<infinity> I must have missed the mention that specials can't be redefined.
<cjwatson> Can't redefine break
<infinity> Though, again, not sure why you'd want to.
<cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
<cjwatson> Ah, bash rejects : () { false; } in POSIXLY_CORRECT mode
<cjwatson> Damn, I thought I'd found that rare beast, a bash bug. :-)
<infinity> cjwatson: So, we totally distracted you with scintillating POSIX discussions.  How goes the OS probing?
<cjwatson> infinity: cannae reproduce here.  I'd suggest not blocking on respins for it for the meantime.
<cjwatson> I've asked the reporter for a bit more information
<infinity> Hrm.  Seems somewhat ironic that the last upload of gmap was by BenC to "fix FTBFS on many arches", but powerpc failed.
<infinity> cjwatson: Alright, respinning in ~20m then.
<infinity> And WTF, mate?  Where did armel's kgpg binary go?
<infinity> Oh, proposed.
<infinity> Partial/early copy.
<xnox> infinity: cjwatson: I use dpkg-deb -R but bash-completion doesn't know about it, so it's a pain.
<cjwatson> infinity: resurrectable, or no-change rebuild?
<infinity> cjwatson: Should be resurrectable.
<cjwatson> We need to make sru-release check for this, I think.
<infinity> Yeah, we do.
<cjwatson> People get it wrong so often ...
<infinity> cjwatson: Though, I'm not sure everyone uses sru-release -r for devel copying either.
<infinity> cjwatson: (At least, I assume vorlon was using copy-package or something that landed his copy in the queue, rather than bypassing it)
<infinity> Speaking of queues...
<cjwatson> Indeed.
<infinity> Let's see if that accepts or oopses.
<cjwatson> You can use copy-package --auto-approve.  It depends whether you're wearing a developer hat or an archive admin hat.
<infinity> cjwatson: Oh, also, fun on the ARMv5 rebuild.  libatomic-ops is totally a static library that gets included by a few compilers.  And it's been v7 on armel the whole time.
<cjwatson> Score
<infinity> Yeah, I'll need to try to trace just how bad that really is.
<infinity> GCC doesn't use it on anything except ia64.
<infinity> But GCJ uses it universally, I believe.
<cjwatson> Same way syncpackage *could* auto-approve for archive admins, but doesn't, because people who happen to be archive admins might well sync stuff from Debian acting as developers and want review.
<cjwatson> It's probably too late to rebuild GCJ now ...
<infinity> Yeah.  If only "reviewing" wasn't a pain in the butt for syncs.
<infinity> That's getting higher and higher on my annoyance list.
<cjwatson> Yeah, either I should fix that LP bug, or I should make queuediff magically do pull-debian-source; pull-lp-source; debdiff
<cjwatson> Fixing the LP bug might be easier ...
<cjwatson> (Given it probably already *has* the packagediff from somewhere else.)
<cjwatson> (Well, sometimes.)
<infinity> It generates it after accept, I think, not before.
<infinity> For syncs where it didn't have one for another reason.
<cjwatson> In Ubuntu, sure, but it might well have it in Debian.
<cjwatson> In any case, it ought to be trivial to get it to generate it
<infinity> Oh, sure, it may have a debian->debian diff.
<infinity> ubuntu->debian, it won't, but it should be made to.
<infinity> Though, if there's queue diff bug hunting afoot, the much simpler (I suspect) "make queue diffs consider all subset pockets" bug also needs stabbing.
<cjwatson> Hmm, rakudo at least gets past the buildd failure point on scheat
<cjwatson> That's sadly not especially simple.  The whole ancestry handling code is a 'mre.
<cjwatson> *'mare
<cjwatson> I've looked at it in the past and been reduced to leaving despairing comments.
<infinity> Oh, that's unfortunate.
<infinity> It sounds easy, in principle.  But I wasn't thinking along the lines of actual ancestry tracing.
<infinity> Just defining a table of pocket subset/superset, and searching down through your set for the most recent version to diff against.
<infinity> Might still goof up in the case of security, which isn't a superset of updates, but occasionally bases updates on updates.
<cjwatson> wgrant and I talked about it a while back.
<infinity> Otherwise, it's pretty linear.
<cjwatson> There are at least three different implementations of the same idea, arguably four
<cjwatson> I think there might be an excuse for at most two different behaviours
<cjwatson> The whole lot needs to be consolidated and done properly
<ScottK> cjwatson and pitti: Thanks for tackling my bcmwl bug.  I've got about 5 hours of solid meeting in front of me, but should have some time to do additional testing before my flight home.
<kenvandine> i have a an update for chromium for their stable channel, should i upload that to -proposed?  or let the security team put it in -security?
<infinity> Oh, hrm.  This kgpg was in the same set that Ridell broke before and ScottK and wgrant spent time rescuing.
<pitti> ScottK: yw; thanks for pointing this out, those were two rather general and important bugs
<infinity> kenvandine: If you plan to test and bless it by release, -proposed is fine, and we can move it to the release pocket.
<ScottK> infinity: We ended up reuploading everything.  I guess I missed one.
<kenvandine> infinity, can do
<infinity> ScottK: Oh.  Fun.  Care to do that one too? :P
<ScottK> Sure thing.
<cjwatson> infinity: meissa's exploding again
<infinity> Ugh, meissa, again?
<infinity> Jinx.
 * infinity sets to manual, and will deal with it after kicking off builds.
<infinity> So.  Rebuilding the world.  Any last objections?
<cjwatson> Is kgpg on any of the images?
<cjwatson> Kubuntu DVD apparently
<infinity> Oh, indeed.
<cjwatson> Which we don't seem to build any more
<cjwatson> So whatever :)
<infinity> Yeahp. :P
<xnox> cjwatson: infinity: my hand made grab-sync wrapper: does the two pull sources, debdiff and test build... that's how I "sponsor" syncs =) http://paste.ubuntu.com/1274916/
<cjwatson> Well, sure, I do something similar
<cjwatson> But it would be more helpful for LP to do it
<infinity> Especially for those of us with only 100Mbit at home.
<highvoltage> skaet: sorry for not looking at those release notes for edubuntu before (and thanks for taking care of it, it's looking good)
 * infinity is poverty-stricken, according to his Korean friends.
<pitti> "only" 100 MBit, *weep*
<ScottK> infinity: On the way.
<infinity> pitti: It's only 10Mbit up, if that makes you feel better.
<pitti> /quit patting my poor DSL line
<ScottK> infinity: It's in the queue, not sure why queuebot didn't notice.
<infinity> ScottK: Because queuebot is fickle.
<infinity> ScottK: (And also not in the channel)
<skaet> highvoltage,  adjust, sort, refine as needed.  :)
<ScottK> That would do it.
<Riddell> I just pushed a fix for visible formatting strings in kde frontend bug 1065989
<ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Confirmed] https://launchpad.net/bugs/1065989
<xnox> Riddell: that's not enough.
<xnox> Riddell: you should change the actual po files with sed and remove those bits as well.
<xnox> otherwise you loose the translations to that string across the board.
<cjwatson> skaet: I'm going to miss at least some of the update call today - there's a presentation I need to attend
<cjwatson> Assuming G+ likes me this time round
<smartboyhw> skaet, oh so there will not be a role of Release Manager ever?
<skaet> cjwatson, understood.
<skaet> thanks for letting me know.
<ScottK> smartboyhw: Prior to slangasek we survived some years without one.  Hopefully making it possible for non-Canonical people to run more bits of the release process will get done, so we can help out.
<smartboyhw> Ah:D
<cjwatson> bug 1051306 looking like a GRUB bug - whee
<ubot2> Launchpad bug 1051306 in grub2 "Windows not found unless partition is mounted" [Critical,Triaged] https://launchpad.net/bugs/1051306
<ScottK> There's a chromium-browser update in the queue.  Do Lubuntu/Mythbuntu want to try and land that if there is an opportunity?
<skaet> ScottK,  Mythbuntu isn't participating in 12.10 ;)
<skaet> gilir, ^ thoughts?
<ScottK> OK.  Well that narrows it down.
<gilir> ScottK, is there a package to test somewhere ? or the changelog ?
<infinity> ScottK: It's going in if/when it can.
<ScottK> http://launchpadlibrarian.net/119585836/chromium-browser_22.0.1229.79~r158531-0ubuntu1_source.changes
<ScottK> infinity: Any reason not to go ahead and get it building then?
<infinity> ScottK: Nope, just hadn't reviewed it yet.  If you want to poke, have a look.
<gilir> I would prefer to test it a bit just to be sure, or to push it as soon as possible to test it on the next ISO :)
<plars> xnox: hi, are you looking at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1065034 actively?
<ubot2> Ubuntu bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed]
<infinity> It's going to proposed, so we can test from there.
<xnox> plars: yes.
 * Riddell hugs skaet 
<skaet> Thanks Riddell
 * smartboyhw hopes that the Release Team will do better than before in 13.04!
<xnox> skaet: /me is sad.
<smartboyhw> skaet, /me also
<ScottK> The linux-firmware in queue looks like something we ought to have.
<smartboyhw> Actually who is NOT sad here raise up your hands please
<ScottK> skaet: I'm going to accept linux-firmware to proposed and we can copy it over when there's a window.
<skaet> ScottK,  ok
<rtg> ScottK, the linux-firmware update is for a staging driver and doesn't affect many folks yet, though we will likely begin to see more of these devices in the real world.
<infinity> "This commerts reverts to that older firmware."
<infinity> rtg: Not awake yet? ;)
<ScottK> Accepts.
<IdleOne> skaet: This is not a major issue but you should also accept cheques as payment
<ScottK> gilir: I accepted chromium-browser too, so there will be packages ~shortly.
<smartboyhw> IdleOne, isn't check = cheques?
<rtg> infinity, copy&paste from the original commit log entry.
<skaet> IdleOne,  can you open a bug?  (me assuming this is about contribute, etc.)
<cjwatson> what
<infinity> rtg: Corpies and pastes, surely?
<cjwatson> the comment was about the topic
<IdleOne> skaet: no the topic :) Sorry for disrupting, won't happen again
<rtg> surely
<skaet> IdleOne, sorry got confused with http://www.omgubuntu.co.uk/2012/10/ubuntu-adds-new-donations-page
<gilir> ScottK, ok thanks, I'll keep an eye on it
 * skaet did mass mark
<skaet> for rebuilding on iso tracker
 * infinity decides to take another stab at libatomic-ops before admitting defeat.
<smartboyhw> LOL
 * skaet is betting on libatomic-ops at this point, given the past commentary on the subject, and lack of sleep infinity has been having.  :P
<NCommander> jamespage, on bug #1065903, the Suggests change seems to be rather minimal, given it won't effect dependencies or even default apt-get behavior. Is there something I'm missing?
<ubot2> Launchpad bug 1065903 in glance "glance should Suggest: python-ceph, not ceph-common" [Medium,In progress] https://launchpad.net/bugs/1065903
<NCommander> morning skaet
<skaet> morning NCommander
<ev> ^ Another single line change that will bring much happiness. This lets us bucket KernelOops problems together.
<Riddell> skaet: I put bug 1065989 under rebuild triggers
<ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Confirmed] https://launchpad.net/bugs/1065989
<skaet> Thanks Riddell
<jamespage> NCommander, its a very minimal but highly accurate change :-)
<jamespage> I'd rather send out the right messages about how much we have tested ceph with openstack this cycle
<jamespage> and I think suggesting the correct packages is quite important
<jamespage> NCommander, I have a similar on for cinder which zul is working on ATM
<NCommander> jamespage, I don't disagree, but we don't even show suggests information in the software center (or do we?), or in APT by default. Forcing a rebuild to merely update a bit of metadata that isn't used anywhere in the default install (and is well hidden 90% of the time) seems a bit crazy given the time to final release
<jamespage> NCommander,  apt-cache show glance -> Suggests: ceph-common
<NCommander> the well hidden bit :-)
<jamespage> NCommander, not really concerned about software centre as this is a server related package
<skaet> jamespage,  put it to -proposed.   If there is a good opportunity it may get considered as an opportunity target, but at this point we need to keep churn down to only the critical bits.
<mvo> fwiw, software-center will use the "suggess" to display "addons" in the details page
<mvo> (no idea if that matters or not in this case, but still wanted to mention it ;)
<NCommander> mvo, good to know.
<jamespage> NCommander, skaet: OK - please reject then and I'll re-upload to -proposed
<infinity> ev: You would have made me much happier if that upload had been 2 hours ago.
<NCommander> jamespage, done
<ev> infinity: :)
<smartboyhw> skaet, is this page actually updated? https://wiki.ubuntu.com/ReleaseManagement/ReleaseImageContacts
<infinity> smartboyhw: Looks fairly stale to me.
<smartboyhw> infinity, er at least the Xubuntu one is not correct......How could the project manager not = knome?
<slangasek> infinity: oh huh; you didn't learn -R from me, -e was the one I pointed at
 * smartboyhw is puzzled
<infinity> smartboyhw: stale, meaning wildly out of date.
<slangasek> tkamppeter: hey there
<smartboyhw> infinity, oh hurray I learnt a new word!
<infinity> slangasek: You told me about -e when I was using ar and tar and then I read the manpage and decided -R was awesome.
<smartboyhw> stale:P
<slangasek> infinity: nice :)
<tkamppeter> slangasek, I have asked for some more info in the CUPS bug, and error_log with the "last words" of cupsd before dying, your cupsd.conf, and whether your cups is correctly broadcasting its queues via Avahi.
<slangasek> tkamppeter: ack
<skaet> smartboyhw, infinity is right,  that page is out of date, and we have been pretty much handling this by the manifest wiki page based on comments at last UDS.  I'll clean up the references.
 * skaet adds it to the list.
<smartboyhw> Yay!
<smartboyhw> Thx skaet
<jamespage> NCommander, re-uploaded to -proposed as requested
<smartboyhw> skaet, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuStudio#System_Requirements we will change it to 768MB but then the 2GB or more memory thing will still exist:D
<skaet> thats fine.  thanks smartboyhw,  just make the change.  :)
<smartboyhw> skaet, :)
<smartboyhw> skaet, changed it just now:D
<infinity> ^-- Me admitting defeat for now.
<cjwatson> Hah
<cjwatson> It'll have to do
<infinity> How are there no open Debian bugs on rhmessaging failing to build, like, everywhere?
<infinity> For 127 days...
<smartboyhw> Wow:D
 * infinity just dumps the outdated ppc binaries and carries on.
<smartboyhw> !
<smartboyhw> Does anyone know if ubuntustudio-default-settings 0.38 is accepted?
<cjwatson> https://launchpad.net/ubuntu/+source/ubuntustudio-default-settings
<cjwatson> Says yes
<infinity> Several days ago.
<smartboyhw> cjwatson, duh I am still seeing ubuntustudio-default-settings	0.37 in the manifest
 * smartboyhw is scratching his head
<cjwatson> You're looking at an old image then.
<cjwatson> Current one says 0.38/
<cjwatson> .
<smartboyhw> ...
<infinity> http://cdimage.ubuntu.com/ubuntustudio/dvd/current/quantal-dvd-amd64.manifest
<infinity> Definitely 0.38
<smartboyhw> oh damn it is what did I go on? Sorry cjwatson infinity
<slangasek> ^^ has a few bugfixes we want for our SB toolchain
<plars> seb128: I was looking at bug 1060368, and it appears that it may be fixed now
<ubot2> Launchpad bug 1060368 in libunity-webapps "reloading when a webapp is open causes the webapp icon to disappear from the launcher" [Medium,Confirmed] https://launchpad.net/bugs/1060368
<plars> seb128: however, https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1060274 still seems to be there, yet it is marked fix released
<ubot2> Ubuntu bug 1060274 in libunity-webapps "webapps do not show up in dash search after installation" [Undecided,Fix released]
<cjwatson> So, I have two choices for fixing this grub-mount bug
<cjwatson> I can implement full symlink support, making symlinks to directories show up properly
<ScottK> slangasek: Accepted.
<slangasek> ScottK: ta
<cjwatson> Or I can implement a quick-and-dirty (and possibly non-upstream) hack to ignore GRUB_ERR_BAD_FILE_TYPE when reading a directory and trying to get the properties of a non-directory, which will have the effect that symlinks to directories will behave oddly (missing from directory listings, you get ENOTDIR when trying to list them individually, etc.) but won't make the rest of the containing directory appear empty
<infinity> Okay, libatomic-ops can take a long walk off a short pier.  Now the testsuite's misbehaving on powerpc.
<cjwatson> I'm inclined to do the latter
<xnox> cjwatson: i am ok with a later. the OP had a symlink to directory. And os-probe doesn't require reading symlinks to directories to detect stuff.
<cjwatson> xnox: Indeed, that's part of what tipped me off to this being the pattern
<cjwatson> We hope it doesn't require reading symlinks to directories, anyway :)
<cjwatson> I suspect the odd corner case may still fail, but it will be a lot rarer
<cjwatson> You'd have to actually hit the sym->dir directly, rather than just trying to list a directory that contains one
 * xnox takes mental note to symlink /etc for fun
<cjwatson> Quite
<slangasek> wat
<slangasek> pretty sure Debian Policy doesn't guarantee the symlink won't reach up off the disk and strangle you if you do that
<cjwatson> I don't see what's wrong with symlinking /etc, as long as it's to somewhere on the same fs
<xnox> slangasek: who cares about Debian Policy, when we are crafting a test case to fail grub-mount when trying to os-detect Windows 7....
<cjwatson> After all this is part of the reason why dpkg doesn't automatically replace symlinks with directories and vice versa
<slangasek> cjwatson: well, there was a recent (< 2y) policy discussion about the rules for relative vs. absolute symlinks so maybe this has changed now, but it used to be that making symlinks out of system dirs would result in wrong traversals
<slangasek> doko, infinity: seeded, thanks
<cjwatson> slangasek: /etc -> /foo would be fine though
<slangasek> I suppose :)
<xnox> that was my cunning plan =)
<xnox> and see how much stuff fails =)
<plars> ogra_: yeah, on today's arm image (20121012.2) I'm getting this same issue with not being able to exit the installer and get to a live session
<ogra_> well, thats rather minor i would say as long as the installer does its duty :)
<ogra_> something we can release note
<plars> ogra_: going to retry the install, but that's how I noticed it actually, when installer crashed on me last night
<plars> ogra_: interestingly, if I ctrl-alt-f1 *before* quitting the installer, then I can get to a vt
<cjwatson> I've moved bug 1051306 to a rebuild trigger, since I just uploaded a fix.
<ubot2> Launchpad bug 1051306 in grub2 "Windows not found unless partition is mounted" [Critical,Fix committed] https://launchpad.net/bugs/1051306
 * ScottK is confused.  I see .3 ^^^, but the latest at http://cdimage.ubuntu.com/kubuntu/daily-live/ is .1.  Am I looking in the wrong place?
<cjwatson> ScottK: It's .3 on nusakan; it's probably just taking a while to sync to cdimage.u.c.
<xnox> ogra_: vt 7 handover not happening properly on panda for me as well.
<ScottK> cjwatson: Thanks.
 * ogra_ isnt sure what to make out of that ... everything worked fine in beta2
<plars> ogra_: yeah, ubiquity is crashing at the same place for me on arm.  I'll try it again with a different usb stick in a moment, but this is suspicious.  Rather than letting it kill the installer and restart my session this time, I just went to a text console
<ogra_> hmpf, i geuss i'll try an install myself
<rtg> ogra_, I did rebase ti-omap4 against master a couple days ago. I wonder if it introduced a regression.
<rtg> ppisati, ^^
<ogra_> hmm, probably
<plars> ogra_: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066046 is the bug, hggdh is also trying an install right now
<ubot2> Ubuntu bug 1066046 in ubiquity "ubiquity crashes after user info screen on panda" [Undecided,New]
 * ogra_ takes a look
<ogra_> plars, oh, yeah there is an oops in the syslog
<plars> ogra_: there's a python trace from install.py, and a slowpath warning from kernel, possibly from when I did ctrl-alt-f1
<ogra_> yeah
<infinity> rtg: The ARM coherent DMA stuff could relate.
<xnox> I think I have a fix for bug 1065034
<ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
<infinity> rtg: I'll note that the armadaxp rebase reverted a couple of those commits, claiming conflicts.
<xnox> it affects all images but: core, cloud and pre-install. I think. partman-auto bug.
<rtg> infinity, different source base, so Ike could well have had some patch conflicts.
<infinity> rtg: Oh, no, I'm sure it really did *conflict* in his case, and not yours.  My point is that if it's conflicted with the armadaxp stuff, it's likely something nasty and intrusive, cause so is their patch. ;)
<infinity> rtg: So, it may have broken ti-omap4, despite not actually conflicting in the patch sense.
<rtg> infinity, true, especially with DMA coherency. I'll get ppisati to have a look when he gets back.
<slangasek> cjwatson: so as of today, we have a server image that we think will boot on stgraber's laptop, correct?  (linux-signed + shim that avoids LoadImage)
<cjwatson> slangasek: I hope so
<slangasek> ok
<seb128> plars, can you ping #webapps or kenvandine about those?
<plars> seb128: already did
<seb128> plars, thanks
<plars> ogra_: I'm trying a different usb stick now, one that I've used before, and it seems to exit the installer at the same point but never gives me the screen saying it's going to restart the installer.  I'm left with just a spinning mouse cursor, and can't even exit to a text console
<jibel> bug 1066049 on server
<ubot2> Launchpad bug 1066049 in plymouth "No graphical boot screen on server installation" [Undecided,New] https://launchpad.net/bugs/1066049
<cjwatson> I didn't think there was meant to be.
<slangasek> there isn't
<jibel> after installation ?
<cjwatson> Netboot probably differs because it doesn't really know which product it's installing, in some sense.
<slangasek> jibel: yes.  This is as specified by the server team
<cjwatson> But the server ISO preseeds debian-installer/splash to false.
<cjwatson> If you netboot with debian-installer/splash=false as a boot parameter you'll get the same effect.
<jibel> ah ok, thanks, that was a quick fix :)
<jibel> sorry
<slangasek> :)
<ScottK> Is bug 1065034 considered RC?
<ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
<xnox> ScottK: yes
<ScottK> Riddell: Are your ubiquity changes committed?
<xnox> ScottK: have a fix. Doing final testing and will upload. actually it's a bug in partman-auto
<ScottK> xnox: When you upload, please make sure you've got Riddell's string fix.
<ScottK> slangasek: I have to head out, but if we've definitely got a new Ubiquity upload coming, I think linux-firmware should get copied to -release.
<cjwatson> xnox: have you committed the partman-auto fix?
<plars> ogra_: hggdh confirms this behavior on his board also
<cjwatson> ScottK: yeah, it's in bzr
<ScottK> I'll be back in a bit.
<ScottK> Thanks.
<xnox> cjwatson: didn't commit it yet. doing one last test, and then will push a branch for you to see merge proposal and then upload.
<ogra_> plars, yeah , looks like multiple bugs though
<cjwatson> xnox: or I can just have a quick look at a paste
<ogra_> but i cant find any upload the recent days that could have broken the user setup in ubiquity
<plars> ogasawara: any chance they could all be related to the kernel update that rtg mentioned?
<rtg> plars, yes, which is why I'd like ppisati to have a look (as I don't have HW)
<slangasek> ScottK: linux-firmware and ubiquity> confirmed, looking now
<slangasek> Riddell, skaet: AIUI, bug #1065989 touches ubiquity, so seems to be a respin trigger for all desktop images, not just the Kubuntu ones?
<ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Fix committed] https://launchpad.net/bugs/1065989
<infinity> slangasek: Check.
<slangasek> marked as such on the pad
<cjwatson> slangasek: Yes.  A bit moot given the grub2 upload though.
<slangasek> mm that too
<xnox> cjwatson: http://paste.ubuntu.com/1275233/ for the same reasons reuse choises was failing, the do_options fails as well (ro mount fails if journal replay is required, while grub-mount handles it fine)
<slangasek> cjwatson: well, it means we shouldn't start respinning other desktop images between the time grub and ubiquity land
<xnox> slangasek: *cough* partman-auto
<infinity> Dear qemu-user-static, please stop segfaulting.  Thanks.
<slangasek> xnox: context?
<xnox> slangasek: the ubiquity bug is actually in partman-auto.
<xnox> slangasek: and I did reproduce it with server images.
<slangasek> xnox: there are multiple ubiquity bugs in flight :)
<infinity> xnox: Two different u... What he said.
<xnox> slangasek: ah, sure. =)
<xnox> we will respin the world....
<slangasek> good times
<cjwatson> xnox: That looks right as far as it goes, but could you please also make automatically_partition/replace/choices use grub-mount in the same way for the same reason?
<cjwatson> (I think I commented on this when you fixed reuse/choices :-) )
<cjwatson> slangasek: true
 * xnox will be switching to gnome-session-fallback compiz is eating more cpu time than kvm
<xnox> cjwatson: heh. I feel like refactoring that snippet now.
<cjwatson> Perhaps, but not for 12.10 :-)
<cjwatson> I agree there's a lot of cut-and-pasting hre
<cjwatson> *here
 * infinity copies glance to the release pocket, since there's respinning afoot, and it's a harmless change.
<xnox> cjwatson: yeah, don't want to refactor 12.10 release out of 2012.
 * cjwatson fixes up 1065034's metadata
<slangasek> linux-firmware in
<xnox> cjwatson: what is replace option and how to test it?
<ppisati> rtg: ogra_ sorry, which bug i'm a bit lost
<ogra_> ppisati, well, all of them :)
<ogra_> seems everyone had display issues with today panda image
<rtg> ppisati, not sure a bug has been assigned, but I'll let ogra_ tell you about it.
<ogra_> *todays
<cjwatson> xnox: don't remember offhand, ev would know
<skaet> slangase,  Riddell,  is there evidence of it showing up anywhere else?
<skaet> slangasek, ^
<cjwatson> xnox: the code is very similar though so you ought to be able to apply it mechanically
<ogra_> ppisati, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066046
<ubot2> Ubuntu bug 1066046 in ubiquity "ubiquity crashes after user info screen on panda" [Critical,Confirmed]
<ogra_> ppisati, and the one you filed today
<ogra_> there might be more
<slangasek> skaet: of what?
<ppisati> well
<cjwatson> xnox: oh, it's "use entire partition" when there's already an existing Ubuntu installation there, I think
<ppisati> ogra_: jsalisbury with a yesterday image was able to complete an installation
<ppisati> ogra_: but the "black screen until you switch tty was there"
<slangasek> skaet: if you meant the kubuntu ubiquity bug, we can't exactly have the desktop images going out without an up-to-date ubiquity...
<ppisati> ogra_: he went back to beta2 and he said he was there too
<ppisati> ogra_: i remember i had this problem too when i couldn't test some patches from linaro
<cjwatson> skaet: we'll need an updated ubiquity for xnox's partman-auto fix anyway, which is more pervasive
<ppisati> ogra_: in fact i sent the kernel to rsalveti to test it
<skaet> yes,  that's the one.   Just wondering if the symptom was showing up elsewhere.
<ogra_> well, i havent seen it ever
<cjwatson> so it's moot
<ppisati> ogra_: but he said everything was ok
<skaet> cjwatson,  yup, that makes it moot.
<ppisati> ogra_: IMO today's ubiquity exploding has nothing to do with the video bug
<ogra_> no
<ogra_> i didnt claim that :)
<ppisati> ah ok
<ogra_> but until today i havent heard about video probs
<ppisati> you mean the screen switching problem?
<ogra_> thes seem to have shown up recently
<ppisati> lp 1065902
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<ppisati> this one?
<ogra_> there was another one
<ogra_> but yeah, that one as well
<xnox> cjwatson: ok. confirmed that reuse is fixed. now will test that replace works/doesn't explode and then will upload.
<xnox> http://paste.ubuntu.com/1275283/
<ppisati> ogra_: i'm downloading beta2 now
<ogra_> k
<cjwatson> xnox: Looks plausible except for the spurious change of "replace" to "reuse" in two places.
<xnox> cjwatson: aha.
<xnox> cjwatson: thanks.
<xnox> http://paste.ubuntu.com/1275289/
<xnox> why is kubuntu-alternate on the pad again....?!
<plars> ev: what's the story with wubi-r273-signed.exe? Should it not complain about the digital signature when you try to run it?
<slangasek> stgraber: jet lagged? :)
<slangasek> plars: -signed.exe should not complain about the digital signature.  What's the complaint?
<seb128> skaet, btw the thunderbird-messaging menu fix, we will aim at SRU, it's just too late to land that for release
<plars> slangasek: it's just the typical windows warning that it can't verify the publisher when I try to run it
<skaet> thanks seb128,  gotcha
<seb128> skaet, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop should be mostly good as well, so if people want to start proofreading of fixing style they are welcome to
<slangasek> ev: ^^ wubi signatures are still done through IS, right?
<seb128> of->or
<plars> slangasek: but it wasn't clear to me if that's expected, or needs an extra step to tell windows where to verify the signature
<infinity> xnox: It's not actually being built, no idea why it's listed.
 * infinity removes.
 * skaet hugs seb128 :)   will start bring others in then.  :)
 * seb128 hugs skaet back
<ppisati> jsalisbury: didn't you find lp 1065902 in beta2 images?
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<balloons> skaet, who on the call this morning was mentioning the ARM bug?
<jsalisbury> ppisati, yes
<ppisati> ogra_: ^
<slangasek> plars: fortuitously, the digital signature format should be the same as what's used for Secure Boot, so we might actually have some tools now that work for inspecting this.  What's the URL of the wubi you're using, and is there any chance you can get a more detailed error message out of Windows?
<jsalisbury> ppisati, I confirmed it with the daily build from yesterday
<ogra_> jsalisbury, what brand is your monitor ?
<slangasek> plars: but yes, the "signed" copy is the one that's explicitly supposed to be signed into the Microsoft PKI chain
<plars> slangasek: it does appear that it is signed, if I look at properties it says name: Canonical UK Ltd. Email: Not available, and has a countersignature from symantec time stamping services signer -G3
<slangasek> ok
<jsalisbury> ogra_, It's a Samsung P2350
<plars> slangasek: http://people.canonical.com/~evand/wubi/quantal/
<plars> slangasek: ah, I think I see the problem
<ogra_> jsalisbury, hmm, samsung here too ...
<plars> if I look at the certificate, it says it's valid from 10/6/2010 to 10/6/2012
<jsalisbury> ogra_, I'm using a HDMI cable through a HDMI to DVI converter
 * ogra_ remembers there were issues with samsungs EDID reporting in omap in the past
<ogra_> a converter ?
<slangasek> plars: the certificate itself expired, not the signature?
<ogra_> oh, your monitor only has DVI in ?
<jsalisbury> ogra_, well, adapter.  HDMI in on one side and DVI out on the other
<jsalisbury> ogra_, correct
<plars> slangasek: it would appear so, yes
<slangasek> ok
<ogra_> jsalisbury, and you attached to the DVI socket on the panda ?
<slangasek> fyi, sbsigntool segfaults on wubi, so I'm no help ;)
<skaet> balloons,  not remembering clearly,  sorry.
<jsalisbury> ogra_, yes.  I booted Oneiric and didn't have the issue.
<slangasek> plars: can you screenshot the full certificate output or something, so we can raise an RT?
<jsalisbury> ogra_, I could try precise as well and maybe perform a bisect
<infinity> zul: Can you reupload that nova to -proposed?
<zul> infinity: sure
<infinity> zul: Thanks.
<plars> slangasek: sure, let me see what I can get from this
<ogra_> jsalisbury, well, in quantal we have to ship the binaty x driver by default on the image, oneiric to precise is plain xfbdev
<ogra_> so there is quite some difference across the board
<jsalisbury> ogra_, ok
<ppisati> ogra_: i can confirm the same issue with beta2 img, pandaes and a benq monitor
 * infinity thinks it might be time for a siesta.
<infinity> FWIW, the last batch of builds are all done, so the livefs builders are unblocked once people are ready for another spinneroo.
<ogra_> ppisati, do you know if its still there after installation ?
<infinity> slangasek, skaet, whoemever ^
<ppisati> ogra_: yes, it's still there
<slangasek> infinity: ta
<ogra_> hmpf
<ogra_> rsalveti, any idea ? ^^^
<skaet> infinity,  ack.
<ppisati> are beta1 images available anywhere?
<jsalisbury> ogra_, I see it after every reboot
<skaet> ppisati, http://cdimage.ubuntu.com/releases/quantal/beta-1/
<ppisati> skaet: found them, thans
<ppisati> *thanks
<ogra_> http://cdimage.ubuntu.com/releases/quantal/beta-1/
<ogra_> bah, skaet beats me
<skaet> :)
<ogra_> :)
<ppisati> beta1 had the flickering issue
<ogra_> ah, yeah, indeed
<ogra_> i wonder if fbcon changed somwhow
<ogra_> that it could interfere here
<xnox> cjwatson: ^ uploaded
<xnox> note that ubiquity src needs to embed partman-auto.
<plars> slangasek: attached screenshot to 1066065.  Windows makes it stupidly difficult to get a screenshot these days it seems
<xnox> plars: prtscr button + open paint + ctrl-v no longer works? *sigh*
<plars> xnox: not here at least. They have another tool you can run to capture a region of the screen though, just had to find it
 * plars is just glad he only has to use windows for wubi testing :)
<xnox> plars: there is some ubuntu-one testing that needs to be done....
<plars> xnox: of course, but that's not part of the ubuntu release
<ppisati> ogra_: it's in beta1 too
<ogra_> ppisati, not for me
<ogra_> neither in B2
<ppisati> ogra_: just tried
<ogra_> yeah, i belive you
<ogra_> but i'm also 100% sure i didnt have it
<ogra_> i woudldnt have signed off the image if i had had it
<ppisati> i don't know what to say
<ppisati> i was even in vacation back then
<ogra_> yeah
<ogra_> beta2 also rsalveti tested
<xnox> ppisati: i believe i started to get the same bug as well. Can we figure out what's common between you and me, but different to ogra?
 * ogra_ uses a pretty std setup, usb key, mouse kbd and a samsung T240 monitor
 * xnox uses usb dongle for wireless keyboard & mouse, hdmi monitor, usb stick (32gb), sd card (8gb) dd'ed with the install image.
<ogra_> i just notice that i'm plugged into HDMI on the board
<ppisati> actually rsalveti said TI *might* have the same issue
 * jsalisbury is using a KVM switch, so my keyboard/mouse only use one USB port and I can share them with my laptop.  
<ogra_> jsalisbury, but no KVM for the displa i hope
<ogra_> *display
<ogra_> :)
<jsalisbury> ogra_, correct
<jsalisbury> ogra_, I use the vga port on the monitor for my laptop and the DVI port for the pandaboard
<balloons> ogra_, et la https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066064
<ubot2> Ubuntu bug 1066064 in ubiquity "Installer unrecoverable error during install of Ubuntu Quantal Final on Panda board" [Undecided,New]
<balloons> I'm going to try and confirm it now
<ogra_> balloons, yeh, plars already reported that, there must be something wrong with usersetup
<ogra_> i dont get why it only shows on panda though
<balloons> I thought someone might have mentioned it, hence my earlier question
<balloons> so will there be a respin?
<slangasek> plars: RT 56704 opened
<xnox> ogra, the logs are sparse
<ogra_> xnox, plars at least has a backtrace with a broken pipe
<ogra_> not much info in it either
<xnox> ogra_: well maybe it's no usersetup, but e.g. webkit failing to start the slideshow
<ogra_> i'll do an install with debug-oem-config set
<ogra_> that should shed some light
<MCR1> slangasek: Hi :) Got a minute ?
<slangasek> MCR1: hi there
<MCR1> I think you are the right person for SRU - am I correct ?
<slangasek> MCR1: I'm on the SRU team, if that's what you mean
<MCR1> I fixed 2 Unity bugs regarding showdesktop which need to get to Quantal and also be backported to Precise.
<MCR1> One has already been merged to trunk, the other is ready to land at the moment
<MCR1> didrocks said I need to take care of the SRU to get them in - both have 0 regression potential and are tested
<slangasek> MCR1: do I understand correctly that didrocks is saying to do an SRU for quantal, as well as to precise?
<ppisati> guys, i've people for dinner comming, i need to go
<ogra_> ppisati, did you have proper plymouth output on boot ?
<MCR1> Also they are imho important because both can heavily impact on user experience if not fixed
<ppisati> ogra_: yes
<ppisati> ogra_: plymouth was always working
<ogra_> well, installer comes up here with no probs at all
<MCR1> slangasek: I do not exactly know - I will re-read - back in a minute
<slangasek> MCR1: that's most likely correct, as we're in the last stages of finalizing images for release and there's no slack for any uploads to quantal that aren't show-stopper bugs
<slangasek> MCR1: just want to make sure you understand the implications
<MCR1>  didrocks: MCR1: if you want that in quantal, you need to make the bugs compliant with the SRU process
<MCR1> quote ^^
<slangasek> right
<slangasek> so, that's https://wiki.ubuntu.com/StableReleaseUpdates
<slangasek> MCR1: once you have the requisite information in the bugs and the packages are uploaded to quantal-proposed, I can help with getting them into the archive for SRU testing
 * ppisati -> dinner
<ogra_> xnox, hmm, your webkit idea sounds compelling
<xnox> ogra_: easy to test as well - purge slideshow package ;-)
<MCR1> slangasek: oh this all sounds very complicated, maybe I'll simply wait for them to land automatically...
<slangasek> MCR1: hmm, not sure what you mean by "automatically"
<MCR1> slangasek: In some future update
<MCR1> slangasek: they are already in Unity trunk, so... or better 1 is the other is waiting for the merge
<slangasek> packages do not automatically get updated in stable releases, and someone will still need to do the work around the SRU bugs to get them included in an update :)
<MCR1> slangasek: Maybe you want to take a look at the bugs then ?
<slangasek> MCR1: I'm rather busy with other aspects of the 12.10 release at the moment, can't really afford to go deep on this, sorry
<MCR1> slangasek: Otherwise I could also talk to sil2100, who AFAIK does the Unity releases - np - thanks 4 your help anyway. :)
<ogra_> xnox, well, purging anything isnt easy .. pitchblack screen ... not even consoles
<xnox> meh
<xnox> MCR1: PS are doing regularly scheduled SRUs of the unity stack following all the SRU procedures. Please get in touch with them to cherrypick that bug you want and ask them to do it properly =)
<slangasek> cjwatson: wubi doesn't actually need a respin for the grub change, does it?
<MCR1> xnox: PS ?
<slangasek> MCR1: Canonical Product Strategy team, the upstream for unity
<MCR1> ah ok, thx
<slangasek> cjwatson: can you review the partman-auto upload, or should I put my partman brain in?
<xnox> slangasek: cjwatson did review the diff I pastebined.
<slangasek> xnox: is that the same as the diff you uploaded? :P
<xnox> slangasek: yeah.
<slangasek> ok
<xnox> slangasek: with the typo fix, cjwatson pointed out. read scrollback =)
<xnox> tested as well =)
<slangasek> accepted
<slangasek> still in progress on the ubiquity side?
<xnox> slangasek: yeah. needs to update/embed partman-auto "udeb"
<slangasek> xnox: right; does that require it to be in the archive first?
<slangasek> I thought cjwatson sometimes takes a shortcut :)
<xnox> slangasek: I do. cjwatson does shortcuts that I don't like.
<slangasek> heh
<xnox> slangasek: I have added the bzr-bd pre-build script to ubiquity trunk, such that `$ bzr bd -S` does everything right or throws a fizzy fit =)))))
<xnox> kubuntu ubiquity & grub are in. cjwatson did translation sync earlier.
<xnox> so we maybe ready to upload ubiquity soon =)
<slangasek> perfect
<ogra_> xnox, i owe you a beer
<ogra_> works fine once the slideshow is removed
<slangasek> xnox: look out, you're going to have to drink beer
<ogra_> so i suspect webkit crashes the pvr driver somehow
<ogra_> :(
<ogra_> easily worked aroudn by a seed change but still :((
 * xnox *hehe*
<xnox> if all fails, blame webkit =)
<ogra_> hahah
<slangasek> launchpad translation exports make me sad
<xnox> ogra_: I don't drink beer. Ciders or tennessee whiskey is for me =)
<ScottK> Could we have another armel builder or so.  What we have isn't keeping up.
<slangasek> infinity, doko: ^^ if one of you can make magic happen?
<ogra_> seb128, so how well was your webkit upload tested on arm ?
<seb128> ogra_, "my"? last time I uploaded webkit was like in july?
<slangasek> plars: is bug #1062428 a priority from your side?  IIRC you referenced it in your release report, but it's marked 'incomplete' by pitti awaiting udev debugging info
<ubot2> Launchpad bug 1062428 in udev "omap4 desktop install image sometimes boots without keyboard working" [Medium,Incomplete] https://launchpad.net/bugs/1062428
<plars> slangasek: no, it's a minor thing
<seb128> ogra_, or your mean desktop? I guess "not"
<ogra_> seb128, err, sorry, cjwatson uploaded it apparently, it just has your name in the changelog for the new upstream
<slangasek> plars: ok, wiping it from my memory ;)
<plars> slangasek: I need to look into it more, but it's mostly been working for me lately.  It's one of those that comes and goes
<seb128> ogra_, which I would agree it's an issue, it took like a month to get the thing to build on amd64
<slangasek> xnox: er, bug #1066076 - does this mean base-files hasn't been uploaded yet?
<ubot2> Launchpad bug 1066076 in base-files "lsb_release: code name is not Capitalised during developement." [Medium,Confirmed] https://launchpad.net/bugs/1066076
<seb128> ogra_, Laney uploaded I think, cjwatson probably pocket copied
<ogra_> well, it completely trashes panda installs ... i can work around it though
<slangasek> xnox: I see "Ubuntu 12.10" in /etc/lsb-release here
<seb128> ogra_, :-(
<seb128> ogra_, how come that was not raised before?
<xnox> slangasek: no. base-files are fine. the screenshots are from stale / unupgraded quantal. hence for quantal it's invalid (unless I missclicked)
<ogra_> no idea, likely not to enough desktop testing
<xnox> slangasek: it's just a hint to open r-series as R-series (note the capitalisation)
<slangasek> xnox: ah ok
<ogra_> seb128, though the package only went in on tue.
<xnox> slangasek: when I saw the bug-titles - i was like please let it not be base-files (cause than it's really the whole world respin)
<xnox> it's fine =)
<cjwatson> slangasek: wubi.exe itself doesn't, but GRUB is in the Wubi filesystem tarballs
<xnox> ogra_: Laney cjwatson doko and others have been almost hand-building webkit on arm....
<cjwatson> xnox: It's much better now that the buildds have that their sysctl tweak
<cjwatson> s/that/had/
 * cjwatson stares at his fingers
<slangasek> cjwatson: ok
<ogra_> xnox, looks like that didnt help :)
<ogra_> i'll just drop the slideshow from the panda images, its just sad that we have again an image thats not 100%
<cjwatson> ScottK: rebalanced builders
 * xnox ponders if cjwatson need his fingers I/O sysctl tweak ;-)
<ScottK> cjwatson: Thanks.
<jdstrand> so, it finally dawned on me how important bug #1058356 is
<ubot2> Launchpad bug 1058356 in upstart "fails to install when kernel does not provide block_suspend capability" [High,In progress] https://launchpad.net/bugs/1058356
<jdstrand> this was originally reported against cups
<jdstrand> the problem is that when upgrading from 12.04 to 12.10, we are running a 12.04 kernel when cups is restarted
<jdstrand> the upstart job for cups correctly uses /lib/init/apparmor-profile-load usr.sbin.cupsd
<ScottK> infinity: Maybe you could take the golang-tip armel builds from the gophers/go PPA out back and shoot them in the head.  They are somewhat inconvenient at the moment.
<jdstrand> which itself calls apparmor_parser. apparmor_parser will fail though because of a new capability rule that is in the cups profile
<jdstrand> so cups unsuccessfully restarts which may affect upgrades
<cjwatson> ScottK: I might be able to temporarily lower that archive's score.
<cjwatson> If I can remember how.
<jdstrand> I have attached a minimal patch to upstart to make /lib/init/apparmor-profile-load not fail on apparmor_parser error. this has been discussed with the security team and we feel this is the best option at this point
<ScottK> That'd help.
<jdstrand> skaet: may I upload this to quantal-proposed?
<ScottK> Does permanently shooting the builds take lamont's special kind of love?
<slangasek> jdstrand: as an upgrade-only issue, this is SRUable; please upload to -proposed and SRUify the bug report
<skaet> jdstrand,  yes,
<xnox> jdstrand: and there is no pre-depend in cups you can use, because of the old kernel? or for example not restart cups.
<jdstrand> hmm
<skaet> jdstrand,  using quantal-proposed as target for SRUs.
<jdstrand> I could also adjust the cups upstart job
<cjwatson> ScottK: Yes, and I'd generally rather not.  I'll add another armel build instead.
<slangasek> xnox: we need upgrades to happen successfully on the old kernel, not require a second pass post-reboot
<ScottK> cjwatson: OK.  Thanks.
<jdstrand> but this is a better fix because it will fix all errors at this time-- and only one place to undo the workaround once apparmor_parser is smarter
<xnox> slangasek: true. just keep the old cups running. same way e.g. we keep mdadm running. otherwise it will not even be funny.
<cjwatson> Or two.  I'll rebalance back later.
<skaet> slangasek,  since I suspect that infinity and cjwatson may be zzz ing soon,  can you keep an eye on the respin triggering for the next couple of hours.   I've got an appt, and will be back online after.
<skaet> ?
<slangasek> skaet: oh, I thought I was already doing that ;)
<skaet> slangasek,  yeah,  just wanting to make it explicit.  :)
<slangasek> ack
<jdstrand> (in other words, there are other packages that ship upstart jobs that could run into this in the future)
 * skaet -> appt,  biab
<skaet> Thanks.  :)
<slangasek> jdstrand: just upload ;)
<xnox> jdstrand: i see. indeed it's a catch all this class of upgrade bugs, instead of fixing it on per-package basis.
<slangasek> jdstrand: btw, please be sure to commit to the bzr branch when doing so
<jdstrand> xnox: yeah
<jdstrand> slangasek: ack
<cjwatson> ScottK: Amusingly, the entire reason that ~launchpad-buildd-admins now has the ability to edit per-archive build scores is because of contention with ~gophers/go almost exactly six months ago. :-)
<xnox> jdstrand: please upload. and let the audience here look at the queuediff =)
<jdstrand> well, the queuediff is https://launchpadlibrarian.net/119603620/upstart_1.5-0ubuntu9.debdiff
<ScottK> cjwatson: Funny.  It does seem to consume a lot of buildd time on slow archs.
 * micahg has no idea why they need tip built on oneiric at this point anyways
<jdstrand> or at least, it will be
<lamont> ScottK: webops is the giver of buildd love these days
<cjwatson> micahg: I suspect inertia.
<jdstrand> slangasek: there is no Vcs line. I assume you mean ubuntu:quantal/upstart
<jdstrand> slangasek: is that right? or something else
<slangasek> jdstrand: yes
<jdstrand> k
<slangasek> jdstrand: feel free to add the missing Vcs field while you're at it (sorry about that)
<jdstrand> I just rejected that to add a Vcs line
<slangasek> jdstrand: meh, if you didn't get it already I'd rather just un-reject that upload and get on with it
<ScottK> cjwatson: Thanks.  That got partman auto built on armel.
<xnox> people bug 1065935 is not even funny.
<ubot2> Launchpad bug 1065935 in compiz "compiz eats 90% CPU time most of the time, more than kvm to run VMs" [Critical,New] https://launchpad.net/bugs/1065935
<slangasek> jdstrand: so is one of the implications here that cups (and related packages) are running unconfined after restart on upgrade, until restart?
<slangasek> until system restart
<ScottK> Between gophers/go and unity-team/staging PPAs have 5 of 6 working armel builders right now.
<jdstrand> slangasek: yes. the alternative is cups not running
 * slangasek nods
<slangasek> jdstrand: oh, or does the old pre-upgrade policy continue to be applied?
<xnox> jdstrand: the other alternative it to keep the old secured cups to be left running (e.g. do not restart)
<jdstrand> that's a good question
<jdstrand> I'm not particularly concerned about that
<slangasek> xnox: that would be a gross kludge
<slangasek> jdstrand: your changes aren't pushed to the branch yet AFAICS - are you waiting for the accept?
<jdstrand> the upgrade asks you to restart. the system is not going to behave well most likely for a whole bunch of other reasons
<jdstrand> I haven't uploaded yet
<jdstrand> I will momentarily
<xnox> slangasek: ok.
<slangasek> jdstrand: er, yes you did - I said I was going to accept from rejected
 * xnox learns a new noun & verb: kludge
<jdstrand> oh, I missed that
<slangasek> jdstrand: either way - I just don't want the UDD branch to blow up or fail to match :)
<jdstrand> slangasek: pushed without the Vcs change
<slangasek> thanks, accepting
<jdstrand> thanks
<ogra_> plars, balloons, hggdh, i removed the slideshow from the panda images, please test the next image and comment on bug 1066046
<ubot2> Launchpad bug 1066046 in webkit "pvr driver crashes when ubiquity-slideshow starts" [High,Confirmed] https://launchpad.net/bugs/1066046
<balloons> ogra_, will do
<slangasek> ogra_: so that's a ubiquity commit that will be included in the next upload?
<hggdh> ogra_: will do
<ogra_> slangasek, only a change to the live seed
<slangasek> ok
<ogra_> next publisher run should have it
<hggdh> ogra_: BTW, I asked retoaded to take a picture of the pandas in the lab
<ogra_> cool !
<ogra_> i'll do a followup bamboo feeder post
<hggdh> :-)
<hggdh> they will be nicely stacked...
<slangasek> jdstrand: one thing I'm confused about... why did this not trip in the jenkins autotests?
<cjwatson> ScottK: I was going to worry about that, but then I realised there wasn't much else in the queue.
<cjwatson> ogra_: Please remember that seed changes often take at least one more publisher run than people expect
<ScottK> It happens quite frequently that these PPAs take over completley on the slow archs for long periods.
<ScottK> I agree it's fine for now though.
<slangasek> jdstrand: this log clearly shows the cups service being successfully started on upgrade: https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/181/artifact/results/apt-term.log
<ogra_> cjwatson, well, i didnt expect immediate rebuiolds anyway :)
<cjwatson> The test rebuild should be done by the end of the weekend, and then we'll be back to way over capacity again
<slangasek> ogra_: rebuilds are coming almost immediately
<slangasek> ogra_: (as soon as ubiquity is in)
<ogra_> well,. then hold back arm please until the seed change got picked up
<xnox> ogra_: well. ubiquity will trigger a publish, so we are fine =)
 * slangasek nods
<ogra_> xnox, yeah, i thought so too
<cjwatson> It has to be a publisher run after a germinate run after the seed change.
<slangasek> ogra_, xnox: you may be missing the point that seed changes take two publisher runs to show up in the Packages file
<slangasek> which means we do have to wait for this to propagate before respinning
<slangasek> (at least, I'm hoping ubiquity is coming soon? :)
<ogra_> well, i think i made it before upstart went in
<cjwatson> Technically, as I say, one publisher run after the germinate run at the end of the previous publisher.
<cjwatson> The previous publisher doesn't have to have done anything.
<ogra_> so that would be two (if i made it, i didnt stopwatch :) )
<rsalveti> ogra_: the pvr issue must be related with the hardware/monitor used
<ogra_> geez, when did screen develop a screensaver function ?!?
<xnox> cjwatson: shall I upload ubiquity? partman-auto is ready now.
<ogra_> rsalveti, no, its webkit killing it, regardless which monitor
<rsalveti> ogra_: I mean, the blue/black thing
<ogra_> rasyeah, that one could be monitor .. i dont care to much about thais one
<ogra_> rsalveti, ^^
<ogra_> rsalveti, but that webkit can hang the board hard is a bit worrying
<cjwatson> xnox: please
<xnox> ok
<rsalveti> ogra_: yeah
<plars> seeing some dbus-server error on boot in i386-server, but I'm not sure how to figure out which application is hitting it.  Apparmor maybe?
<plars> process 318: arguments to dbus_server_disconnect() were incorrect, assertion "old_refcount > 0" failed in file ../../dbus/dbus-server.c line 786.
 * xnox pep8
<slangasek> plars: or something in upstart?
<plars> slangasek: I get another similar message, then the next thing in the boot log is:
<plars> Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
<plars> then Starting Apparmor profiles
<slangasek> I don't think the adjacency means anything
<jdstrand> dbus is not confined by apparmor
<slangasek> jdstrand: I think he was implying that apparmor was invoking dbus, which is obviously not the case :)
<plars> no, I'm saying that I have no idea what's throwing it, but it seems to happen pretty regularly around the same time as I get that in the log and I'm not sure at the moment what the offending application is
<jsalisbury> ogra_, should the Quantal omap4 server image install on a panda?  I downloaded it from http://releases.ubuntu.com/quantal/ubuntu-12.10-beta2-server-armhf+omap4.img  It hangs at the installer language selection screen
<ogra_> jsalisbury, try the serial install ... i know ppisati fixed the USb kbd issue but i think that was after beta2
<jsalisbury> ogra_, will do, thanks
<ogra_> jsalisbury, mount the first partition and copy preEnv.txt-serial over preEnv.txt
<slangasek> plars: which server tasks do you have installed?
<plars> slangasek: I installed them all
<xnox> lean cloud server, eh?! =) plars edition
<plars> xnox: heck yeah!
<plars> :)
<slangasek> plars: in theory, I think these are your suspects: http://paste.ubuntu.com/1275576/
<xnox> I wonder if all tasks simultaniously are even remotely supportable.
<slangasek> xnox: ubiquity upload in progress?   (not trying to rush you, just checking where things stand)
<jsalisbury> ogra_, serial install is working.  Thanks!
<ogra_> :)
<xnox> slangasek: just about. finished all unit-tests and sbuild.
<slangasek> xnox: spiff
<hggdh> jsalisbury: it does install, just did it
<hggdh> jsalisbury: but mine worked on DVI/keyboard at the panda
<jsalisbury> hggdh, hmm, I get a lockup at the install language selection screen, but serial install works.  It could be that I'm using a kvm switch for keyboard/mouse.  I'll try different configs.
<micahg> ogra_: only major difference on arm is webkit is built with -01
<hggdh> jsalisbury: I am using a usb switch
<micahg> and that's armhf actually
<ogra_> micahg, well, we should probabyl swithc to -O0
<jsalisbury> hggdh, me to.  Did you use this image: http://releases.ubuntu.com/quantal/ubuntu-12.10-beta2-server-armhf+omap4.img
<hggdh> jsalisbury: no, I used today's image
<jsalisbury> hggdh, ahh.  Let me try that :)
<xnox> thanks to new gtk (?!) ubiquity started to read more of itself with orca. -1 rsl-q-tracking bug
<xnox> AlanBell++
<xnox> slangasek: there you go =)
<slangasek> xnox: ta
<slangasek> xnox: so, before I accept this and go respinning the world - you still have four rls-q-tracking bugs on ubiquity all assigned to yourself. :)  Are these still being worked on for 12.10?
<slangasek> bug #1025420 bug #1045798 bug #1045803 bug #1053030
<ubot2> Launchpad bug 1025420 in ubiquity "AssertionError: Returned to partman/choose_partition with nothing to do" [High,Incomplete] https://launchpad.net/bugs/1025420
<ubot2> Launchpad bug 1045798 in ubiquity "Screen reader does not read mismatching passwords during installation" [High,Confirmed] https://launchpad.net/bugs/1045798
<ubot2> Launchpad bug 1045803 in ubiquity "Information about Installation Complete dialog is not read back by the screen reader installation" [High,Fix released] https://launchpad.net/bugs/1045803
<ubot2> Launchpad bug 1053030 in ubiquity "highly confusing UI on desktop when installation media is big enough and no external storage is attached" [High,Confirmed] https://launchpad.net/bugs/1053030
<slangasek> ah, there's the fixed accessibility bug
<slangasek> so, three ;)
<xnox> and the first one is Incomplete, the OP is not responding.
<xnox> So two in total.
<slangasek> hggdh: xnox thinks you don't like him (bug #1025420)
<ubot2> Launchpad bug 1025420 in ubiquity "AssertionError: Returned to partman/choose_partition with nothing to do" [High,Incomplete] https://launchpad.net/bugs/1025420
<slangasek> xnox: rather than leaving bugs 'incomplete' on this list, we should turf them if we're not committed to fixing them; rls-q-notfixing this one now
<xnox> 1045798 (best effort respin ) and 1053030 (best effort respin or respin pandas) I still hope to fix.
<xnox> slangasek: ok.
<slangasek> (otherwise, it's legitimate for a bug to be "we're committed to fixing this but are currently waiting for submitter feedback")
<slangasek> xnox: cool, leaving the other two on the list then; and ubiquity accepted
<xnox> slangasek: i think it's a legitimate bug, if we know the sequence of hoops the OP jumped through to get there.
<xnox> ....
<slangasek> yep
<slangasek> but "legitimate bug" is not the same as "we're committed to fixing this for release" :)
<xnox> =)
<jsalisbury> hggdh, todays daily image fixes the omap4 server installer issue, thanks!
<hggdh> slangasek, xnox: sorry, these have been hectic days. So far I have been unable to reproduce it
<hggdh> jsalisbury: perfect!
<slangasek> infinity: not sure if pad.u.c is telling the truth about name/color mappings; I'm confused about "rebuild trigger" 19, whoopsie/kerneloops integration
<slangasek> hggdh: ok, we're happy to deprioritize that bug in favor of ones you are hitting, then :)
<hggdh> slangasek, xnox: I suggest dropping it, yes
<xnox> slangasek: it was "if you respin the world, included that"
<xnox> slangasek: 19 that is.
<slangasek> xnox: ok.  I would say the pad doesn't clearly express that :)
<slangasek> anyone here aware of anything else pending, besides the arm task update and the ubiquity build+publication?
<xnox> slangasek: well it was a 3 line chat between ev & infinity. I'm surprised it even made it to the pad to be honest.
 * xnox thinks it's time to read how Katniss got a goat for Prim & configure znc bouncer
<slangasek> so I suppose I should test today's images on SB maybe
<slangasek> ogra_: seed change has taken effect.  Is it an issue that ubiquity-slideshow-ubuntu is still listed as part of the ubuntu-usb-live task?
<slangasek> (it's no longer in the ubuntu-live task)
<slangasek> AFAICS that task is only used for the no-longer-extant ubuntu-dvd images
<slangasek> ok, why is adding an attachment to a Launchpad bug broken for me?
<xnox> because cosmic rays are not shining onto armel buildds
<plars> slangasek: removing postfix seems to get rid of the error
<plars> slangasek: the dbus error
<slangasek> nice
<lamont> plars: I suspect that it's the lack of an MTA, not specifically postfix
<slangasek> lamont: er?
<slangasek> lamont: I suspect that you have an irc script that spits out random redirections in response to mention of postfix on Ubuntu channels )
<slangasek> ;)
<lamont> slangasek: well, highlighting on 'bind' turned out to just be silly.  postfix has far less false-positives
<slangasek> lamont: the context here is that plars sees a dbus-related error message on boot, only if postfix *is* installed
<lamont> sweet.
<lamont> I suspect that he'd see it if sendmail were installed, too
<slangasek> why?
<lamont> because postfix does nothing dbus-ish other than provide an mta.  things like cron recommend: mail-transport-agent, and then behave differently based on whether or not it is installed.
<lamont> alternatively, dbus hates chrooted things
<slangasek> cron does nothing dbus-ish either
<lamont> but that seems less likely, imo
<plars> easy enough to try :)
<plars> nope, I don't get the problem with sendmail, just postfix
<plars> slangasek: even still, do you think it's more likely to be upstart rather than postfix? Any suggestions of something I could look for?
<slangasek> plars: if I were to throw darts, I'd say avahi
 * xnox had a good darts throw with webkit & slideshow on panda =)
<slangasek> infinity: ubuntu core is not being built for armel but is still listed as such in the manifest; which is right?
<plars> slangasek: hmm, well with avahi-daemon removed, but postfix still in place, I still get the error
<slangasek> plars: then that dart hits me in the foot, ohwell
<slangasek> plars: consolekit?
<slangasek> there's not too many other options
 * plars starts with colord since it's a dep
<xnox> slangasek: not that foot again.... at least this time you don't need spanish or crutches.
<slangasek> or even canadian crutches, as they apparently call them
 * lamont is out of ideas, which was quick with dbus involved. :(  pardon my interruption
<slangasek> infinity, skaet: pipelines queued up to trigger on ubiquity 2.12.11 publication; wandering afk for a few
<Riddell> evening
<Riddell> ScottK: yes my fix to ubiquity is in, xnox was working on another fix so I didn't upload
<lamont> plars: thanks for tracking it down
<xnox> Riddell: it's uploaded now.... waiting to build & trigger rebuild.
<plars> lamont: well, I opened bug #1066144 as a placeholder, but so far I haven't been able to narrow it down past postfix
<ubot2> Launchpad bug 1066144 in postfix "arguments to dbus_server_disconnect() were incorrect" [Undecided,New] https://launchpad.net/bugs/1066144
<lamont> oh, and here I thought that it was beyond placeholder.  shucks
<plars> lamont it's easily reproducible at least :)
<retoaded> ogra_, hggdh: The Leaning  Tower of Panda has been constructed. You may be able to see the few pics at  https://plus.google.com/u/0/photos/111809657190034387974/albums/5798548368855386737
<ogra_> hmm, thats 403 for me
<slangasek> perhaps https://plus.google.com/photos/111809657190034387974/albums/5798548368855386737 (without the /u/0/)?
<slangasek> retoaded: missing from this picture is the lego mindstorm controller
<slangasek> after all, pandas are a /mobile/ reference platform, right?
<slangasek> infinity: heh, the 'wait' usage in the pipelines seems to have bitrotted a bit thanks to my aggressive backgrounding of processes... is that known?
<slangasek> so I see pad.ubuntu.com is back to being reliable
<retoaded> slangasek, I figured I'd pick all things lego at UDS.
<slangasek> haha
<slangasek> natch
<phillw> slangasek: you must have read my mind, I was just going to ask where
<phillw> what was happening :)
<slangasek> phillw: it appears I overlooked that the Lubuntu preinstalled image didn't need respinning, so it's currently in the pipe; we can discard it and roll back to 20121012.1 if that's the Lubuntu team's preference
<phillw> slangasek: is that the arm one?
<slangasek> phillw: yes
 * xnox it's not like that image will have a need for os-probing windows....
<phillw> you'd need to ask the arm guys, they are the ones looking after that.
<slangasek> oh right, lubuntu/ac100 is ogra_
<slangasek> ogra_: ^^
<slangasek> xnox: it's preinstalled, it doesn't even use ubiquity :)
<phillw> but, if it need not be respun, save the computer time?
 * ogra_ looks up 
<ogra_> slangasek, it does ... oem-config
<slangasek> phillw: too late, it's in the command pipeline
<ogra_> it doesnt use partitioning
<slangasek> ogra_: ah, then I suppose we keep it
<ogra_> so if changes are partitioner specific feel free to skip
<slangasek> ogra_: a) too late to skip, b) we don't ship images with out-of-date packages so you get to update anyway
<phillw> ogra_: thanks, sorry if that came acrross harsh, but I really have no kit whatsoever to even try it out on.
<ogra_> oh, indeed, i didnt mean for the final release :)
<ogra_> just for the convenience ot keep the builder free
<ogra_> phillw, no worries, i'll do the testing etc
<phillw> did you sort the slide show out?
<xnox> phillw: removed from seed =(
<xnox> which is "sorted out" to some degree =/
<ogra_> phillw, yep, resulted in a fix for all derivative distros in the end, thanks for pointing it out
<ogra_> xnox, wrong seed :)
 * xnox is confused
<ogra_> lubuntu slideshow is still in
<phillw> he he, well, thanks goes to Julien, he who said that was the most likely cause. He's a really nice guy :)
<xnox> ah, the bit about wrong slideshows used. yeap.
<ogra_> right
<xnox> happy respin?
<ogra_> i have high hopes the slideshow will work there
<ogra_> else i will have to drop it from ac100 too :/
<slangasek> yes, mass-marking the builds for respin on the tracker
<xnox> slangasek: alternates are done already?! well it's lubuntu only....
<phillw> xnox: I thought server also used alternate install?
<phillw> or so the etherpad says?!
<xnox> hmm.. you are right
<wgrant> infinity, ScottK: FWIW the bug that prevented us from recovering those binaries is fixed, so if it happens again we can try recovering without a reupload
<phillw> one of the big hopes for lubuntu to keep alternate for 13.04 :)
<slangasek> erm, ok, why is ubuntu desktop not in the etherpad pipeline
<slangasek> oh, because it's under 'arm'
<infinity> wgrant: Oh, well, I tried, but nothing seemed to happen.  Maybe I did it wrong.  Too late now to retest.
<wgrant> infinity: Yeah
<infinity> slangasek: "arm" unhelpfully means "anything that produces ARM" not "just ARM".
<wgrant> infinity: The trick is that the latest source publication has to be in the place with the binaries
<wgrant> So you have to copy it back to proposed first
<slangasek> infinity: yep, so I've gleaned
<infinity> wgrant: Ah-ha.
<infinity> wgrant: Coulda, shoulda, will next time this comes up.
<wgrant> infinity: We should probably add a source pocket argument, or let getBuiltBinaries examine the entire distroseries, maybe.~
<infinity> slangasek: As for core/armel, it's not being built because we only have one livefs buildd for ARM, and while one buildd can build mulitple arches, because of the way we name output, it can't build multiple arches of the same image.
<infinity> slangasek: So, no armel/core unless I either fix that misfeature of our build system (not happening this close to release, obviously), or a second buildd magically appears.
<slangasek> infinity: er, ok
<slangasek> infinity: how did we end up with only one livefs buildd for arm again?
<slangasek> (or maybe I mean "still")
 * xnox go
<infinity> slangasek: We were meant to get more when Mandabox 2.0 went live, and... It had/has issues.
<infinity> slangasek: And with the limited set of ARM images we build right now, no one was screaming particularly loudly.
<slangasek> right
 * skaet --> back
 * slangasek waves
<skaet> :)
<bkerensa> =o
 * infinity glares at another touches-every-image upload.
<slangasek> hmm?
<slangasek> it's in -proposed for a reason
<infinity> Yeah, I know. :)
#ubuntu-release 2012-10-13
 * infinity cleans out component-mismatches.
<infinity> ... and wonders why nvidia-settings-updates wants to drop from restricted to multiverse.
 * infinity fixes the seeds.
<slangasek> where was it seeded before?
<infinity> Nowhere, I suspect it was previously a depends/recommends of something.
<infinity> Since it's been in restricted for a couple of releases, and one would expect us to have noticed by now if germinate didn't love it.
<slangasek> nvidia-settings* themselves seem to be the only relevant packages uploaded today
<infinity> Maybe having them conflict with each other is what developed the demotion hatred?
<slangasek> huh, did I really just crash this machine by trying to feed it a fat partition over PXE?
<infinity> But seeding it explicitly should fix that, since an explicit seeding of experimental seems to have stuck.
<xnox> remember the bug with ubiquity "preferring" usb-drive for grub install? now there is recipocal bug filed, with internal drive being the preference now *sigh* bug 1066173
<ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [Undecided,New] https://launchpad.net/bugs/1066173
 * xnox wants to sleep...
<slangasek> are we sure that's a bug, and not by design?
<xnox> cjwatson should look at it =) he is the master of picking the right grub device ;-)
<xnox> slangasek: I can see an argument going for "by design"
<slangasek> well, the one thing that's obviously sketchy there is installing to the internal MBR but referencing the external disk for boot/grub
<xnox> slangasek: yeah, we used to have a bug of reverse ;-)
<xnox> imho the mbr of the disk which has /boot should be the "right" grub destination, regardless of how the machine was booted.
<slangasek> that's probably reasonable
<ScottK> I can report that yesterday's bmcwl problem is solved.  It installs from the live media, works right away, and installs/works with the installed system too.
<ScottK> wgrant: Thanks.
<xnox> fair enough. good night everyone =)
<doko_> slangasek, infinity: I assume the armel buildd issue is solved?
<skaet> ScottK,  good to know.  thanks.
<infinity> doko_: "The armel buildd issue" being?
<doko_> <ScottK> Could we have another armel builder or so.  What we have isn't keeping up.
<doko_> <slangasek> infinity, doko: ^^ if one of you can make magic happen?
<infinity> doko_: Oh, well, I see no queue, so yes. :)
<infinity> We get to rebalance sanely soon anyway, the armhf rebuild is finally almost done.
<doko_> nd just 371 armhf builds left
<phillw> Hi, anyone else getting disconnects from the ether pad?
<infinity> Only for the last year or so.
<skaet> phillw,  when you go to the page,  hit refresh before typing.  That usually avoids most of the silliness.
<skaet> (only most,  not all)
<TheLordOfTime> official Q release date decided yet, or no?
<TheLordOfTime> i know this month, i am seeking a specific day ;P
<skaet> TheLordOfTime, October 18th.   schedule for this cycle is: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
 * skaet --> EOD
<slangasek> skaet: 'night!
<skaet> good night slangasek,  thanks for keeping it sorted this afternoon.  :)
<infinity> cjwatson: FYI, I'm uploading quantal chroot tarballs with bootstrapping disabled for release, will re-enable in r-series chroots if/when we need it.
<plars> yay, panda lives!
<plars> but looks really funny without the slideshow :)
<plars> I am slightly worried about this "fix" though, of just killing the slides
<jibel> xnox, I'm still get bug 1065502 with ubiquity 2.12.11
<ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman (dup-of: 1065034)" [Undecided,Confirmed] https://launchpad.net/bugs/1065502
<ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Fix released] https://launchpad.net/bugs/1065034
<stgraber> slangasek: not too jetlagged actually though I've been busy with some social stuff ;)
<stgraber> anyway, I tested the new shim yesterday and my laptop booted without the error message from the firmware, so the shim looks good
<stgraber> I think I saw a couple of messages from grub though (non-blocking) relating to secureboot (looked like some grub modules that wouldn't load because of secureboot)
<stgraber> I'll try and grab an updated server image later today and see if I can boot that one
<ogra_> damned
<ogra_> seems the slideshow hangs on ac100 as well :/
 * ogra_ updates the pad for the above upload and related re-spin
<knome> why aren't flavors visible in http://status.ubuntu.com/ubuntu-quantal/ ?
<skaet> knome,  should be showing back up on next refresh of status.ubuntu.com.    Turns out to be a "feature" that marking them complete removes from display.  :P
<knome> skaet, heh, right. thanks. :)
 * smartboyhw is surpised....
<smartboyhw> There are 3 days left in the current cycle. That means that in order to complete all the work 198.00 workitems must be completed per day.
<smartboyhw> 198 workitems PER day?
<skaet> smartboyhw,  it illustrates that teams aren't as good about managing the workitems as they need to be thats all.   Note it doesn't mean they must be completed,  if its clear they aren't going to happen they should be postponed, and then it would show up ok, from status perspective.
<skaet> (although,  not from the original intent of what was wanted to be done :/ )
 * smartboyhw is waiting for status.ubuntu.com to be updated to see the progress for the Ubuntu Studio blueprints:D
<doko> this boy doesn't sound that smart
<smartboyhw> doko, is it a personal attack/assualt?
<skaet> smartboyhw, http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-flavor-ubuntustudio.html - the info is still there, not just linked from the to page until the next update happens.
<smartboyhw> thx skaet
<skaet> UbuntuStudio is in pretty good shape.    Its clear what's been postponed.
<skaet> (so can be used for planning for UDS-R ;) )
<smartboyhw> skaet, actually that page is not updated at all
 * skaet looks at it closely,  and realizes,  yeah.
<smartboyhw> skaet, last update time is 7th Oct, while in this past 6 days we changed quite a lot of workitems...Anyway to request a refresh
<smartboyhw> ?
<skaet> it should be updated on that next run.
<smartboyhw> yeah
<skaet> however the data on it generally indicates it is basically complete from a status point of view,  not that much left unsorted.
<smartboyhw> :)
<skaet> slangasek, cjwatson - around?
<smartboyhw> skaet, ha after the update of that page Ubuntu Studio got 100% YEAH!
<skaet> :)
<smartboyhw> First actually to reach 100% sounds like we did follow skaet's instructions very well:D
<skaet> Thank you.  :D
<smartboyhw> :D
<skaet> morning summary:   testing in progress.   Some bugs need further investigation/discussion.   latest knowledge is on the pad.
 * skaet --> saturday errands,  bbl
<smartboyhw> skaet, not sure if this is a blocker
<smartboyhw> I don't think so but
<smartboyhw> Bug 1066302
<ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [Undecided,New] https://launchpad.net/bugs/1066302
<ScottK> I tried out the chromium in quantal-proposed and it seems fine.  If there's a Lubuntu respin, I'd copy it over.
<ScottK> Sine the rebuild is done on armhf, having more than one working armel builder would be nice.
<xnox> i am confused about bug 1066302 was the installer update been enabled on the mirror?
<ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [Undecided,New] https://launchpad.net/bugs/1066302
<xnox> jibel: if you are still seeing that /tmp/ mounting bug or similar please file a new bug with logs. And I'l look into that.
<hggdh> humpf. On my panda setup, desktop installation does not show up until I ctrl-alt-f1/ctrl-alt/f7
<hggdh> not critical, but perhaps we should release-note it
<hggdh> skaet: ^ I will open a bug on it as soon as the install is done, want to grab dmesg and install logs
<xnox> hggdh: i'm sure we have seen that bug already.... please search for it first.
<xnox> me & ogra were discussing it yesterday.
<hggdh> xnox: will do, thanks.
<hggdh> xnox: yes, bug 1065902. I will tag on the ISO test result
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<slangasek> stgraber: cool - does the server image boot for you now too?
<xnox> hggdh: thanks =)
<slangasek> skaet: ish
<slangasek> ogra_: so the livecd-rootfs change only impacts the ac100 image?
<slangasek> hggdh: for bugs you think should be release-noted, don't hesitate to mark them on the ubuntu-release-notes project directly (done now for bug #1065902)
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<hggdh> slangasek: will do; I tend to be careful on that ;-)
<slangasek> hggdh: if by "careful" you mean "reluctant to do so", it's far better for us to have it visible that you think it should be release-noted... we can always wontfix if we disagree ;)
<hggdh> heh. Indeed, it would be more like "reluctant to do without additional confirmation". But I will be more, ah, careless in the future
<stgraber> slangasek: testing now
<infinity> cjwatson: Oh wow, it was passing -lc?  That would explain it.
<infinity> And pypy failed after 2 days, 3 hours, 4 minutes, 58.8 seconds.  Sadness.
<plars> hggdh: heya, have you tried server on arm?
<plars> hggdh: I'm trying to double-check now, but I think there might be an issue now with encrypted partitions
<plars> hggdh: now that the keyboard works for server installs, we can get to this, and it looked like keyboard doesn't work for entering the password
<plars> hggdh: installation about to finish up here
<stgraber> need to find another usb key, that fancy usb3 ssd won't show up in my "bios"...
<plars> hmm, yeah no keyboard
<stgraber> cjwatson: I got some secure boot errors from grub at boot time now. I'll send you a photo
<stgraber> (first checking that I'm up to date)
<plars> infinity: any ideas on this? Is it possibly a missing module or something in the uinitrd?
<infinity> plars: I'm confused.  That seems to boil down to "now that the keyboard works, the keyboard doesn't work"?
<plars> infinity: well, the keyboard works during install now (previously I could only do installs over serial)
<plars> infinity: so I can get it installed, and if I do a normal guided partitioning, everything is fine
<infinity> stgraber: Wait, is there some assumption that current server should work for you, while the previous didn't?
<plars> infinity: but if I select lvm+crypt then when it reboots and asks for the passphrase to unlock the disk, I cannot enter anything
<stgraber> infinity: where previous is from a few days ago, yes
<stgraber> infinity: basically hoping that new shim + grub will let me boot it
<infinity> stgraber: That seems unlikely, given that d-i wasn't rebuilt, and server's boot bits come from d-i...
<stgraber> hmm, indeed...
<stgraber> slangasek: ^
<infinity> plars: Oh, I see.  Post-install, no keyboard in the initrd.  Hrm.  I'm not sure why that would be different on ARM than x86, unless the keyboard bits are all built in to the x86 kernels.
<stgraber> cjwatson, slangasek: http://www.stgraber.org/download/2012-10-13_21-18-56_512.jpg
<stgraber> cjwatson, slangasek: btw, I don't actually have to press a key, there appears to be a 15-30s timeout
<plars> infinity: likely config madness, keyboard didn't work on server installs until just recently, so even different between arm desktop and arm server
<stgraber> cjwatson, slangasek: (that's on my installed system with up to date grub2 and shim)
<stgraber> good news is, I'm not getting the access denied message from the firmware though :)
<infinity> plars: Yeah, but I know the reason for that, since I fixed it. :P
<infinity> plars: (It wasn't kernel configs, it was the d-i initrd)
<plars> infinity: right, sorry
<plars> infinity: but back to my original question... do you have some idea why the keyboard would work during the installer, and post install on non-encrypted installs, but not at this point?
<infinity> plars: Yes, no keyboard modules in the initrd.  But I'm trying to sort out why.
<plars> I do see a message on the screen right before it asks for the password: cryptsetup evms_activate is not available
<plars> but I suspect that's unrelated
<infinity> plars: (The installer includes them explicitly, that was the bug I fixed earlier, and you don't NEED a keyboard in the initrd when you're not running crypt, so you didn't notice the lack of keyboard)
<infinity> plars: What's the bug # for this?
<plars> infinity: haven't filed it yet, doing that now.  Just put it in linux-ti-omap4?
<infinity> plars: No, initramfs-tools, probably.
<infinity> plars: The kernel is fine (though, I suppose we could "fix" it by building in the USB-HID stack, that seems heavy-handed and unnecessary).
 * infinity was pretty sure none of that was built in for x86 either, though, and is now a bit curious...
<stgraber> infinity: the new server image actually boots fine, so looks like the new shim and grub made their way there somehow
<infinity> stgraber: Curious, maybe it doesn't use the d-i cdrom bits, like it used to.
<plars> infinity: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376
<ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
<infinity> So, yeah.  USB HID stuff is modular on x86 too...
<infinity> plars: Can you confirm that this work on x86 with a USB keyboard?
<infinity> plars: Let me amend that.  Can you confirm this works on x86 with a USB keyboard and no BIOS USB->PCAT compat emulation? :P
<infinity> plars: (Cause it really shouldn't)
<plars> infinity: it worked in a VM with x86, haven't tried on hardware but it's probably pretending to be a usb keyboard
<plars> infinity: I can try it though, of course
<infinity> plars: I suspect that the VM is actually giving you an AT or PS/2 keyboard.
<hggdh> plars: I have not yet started with encrypted disk on arm server, it is the next
<infinity> plars: And most people's BIOSes also do "early boot keyboard emulation" which, again, is giving you a fake AT/PS2 keyboard.
<infinity> plars: With that option off, this should fail hard on x86 too.
<stgraber> infinity: so the shim's md5 on the media matches mine so it's clearly up to date, grub's doesn't, so I guess I have something slightly more recent on mine (or something...)
<hggdh> plars: whole disk encryption, or justg home?
 * infinity ponders how best to sort this keyboard mess... Adding the whole USB-HID stack to every initrd seems like some crazy bloat.
<infinity> hggdh: Whole disk.
<plars> hggdh: whole disk
<infinity> hggdh: And I'm sure you'll have the same problem.
<infinity> hggdh: I'm more curious for confirmation that it's also broken on x86 without BIOS keyboard emulation (which it should be).
<hggdh> on it now on ARM, will try later on AMD64
<infinity> This probably only *looks* like an ARM-specific bug because ARM doesn't ever provide you with fake keyboards, while PCs unhelpfully usually do, and sometimes don't. :P
<infinity> hggdh: Kay.  Assuming your amd64 machine has a BIOS option to disable keyboard emulation (might be called "early USB keyboard support" or similar), that's what needs to be off.
<hggdh> infinity: I will check
<infinity> And if it's a laptop, all bets are off, cause laptops refuse to let you disable the internal keyboard, for sanity reasons.
<infinity> (Though, you can still test with an external USB keyboard and emulation off)
<infinity> Anyhow.  I need to pack and be on a plane, but I have a good handle on what the bug *is*, not so much a good plan as to where/how it should be fixed right now.
<infinity> I'll think about it while I'm bored in the air. :P
<plars> infinity: have a good flight, and thanks
<infinity> Hrm.  The input-modules udeb is only 70k.  So, that leads me to believe I could add everything in that to the initrd and only grow it by, well, 70k.
<infinity> That might not be awful.
<infinity> And maybe worth doing universally, since I hear people like having keyboards in their initrds.  Though, I'd still prefer to believe that most omap4/server users would use serial consoles...
<infinity> plars: I assume this all works smashingly if you do it via serial instead?
<plars> infinity: it used to, but I haven't tried yet with this image
<infinity> plars: Right, well.  Please file the bug on initramfs-tools, assign it to me, and mention some of the above (It works in the installer's initrd, it works after a full boot (so, post-initrd), but doesn't work for crypted root (so, in the post-installed initrd))
<infinity> plars / hggdh: And if one of you can confirm that an x86 machine without BIOS emulation suffers the same issue, I'll just fix it universally, if not, I'll make it ARM-specific for minimal impact.
<infinity> plars: Oh, and once filed, throw it in the pad in the "consideration" section, so people bug me about it (or, so I can bug myself). :P
<plars> infinity: will do, thanks
<infinity> stgraber: Well, regardless of which bits come from where, we'll want one last d-i respin before one last image respin, once the grub/shim stuff's definitely settled, I think.
<infinity> stgraber: If you want to make a note of that so we don't forget, that would be snazzy.
<stgraber> infinity: I'll make a not locally and put it on the pad once it's all setup for release
<stgraber> *note
<hggdh> crap. Just locked myself out of the amd64
<plars> hggdh: ?
<hggdh> infinity: the only option I have on my system is "disable USB emulation"
<infinity> hggdh: That's likely the one.
<infinity> hggdh: If changing that makes it so you can no longer, for instance, fiddle with GRUB boot menus, that's what we want.
<hggdh> plars: I disabled USB emulation, now the keyboard does not work anymore. On anything (will try reboot, and F2)
<hggdh> infinity: I cannot even login to the system
<infinity> hggdh: Oh?  Once a system boots completely, the USB-HID stuff should be loaded.
<infinity> hggdh: Maybe your system is extra special. :P
<hggdh> infinity: it is a Dell, so yes, it is special ;-)
<hggdh> but BIOS setup works. Since this system had a Quantal B2, I will reboot on it, and grab dmesg via SSH
<hggdh> infinity: this might be related to the issue
<infinity> Well, if it doesn't work without BIOS emulation even post-boot, that's an entirely different bug/problem than the ARM one I was hoping to verify, and likely the answer is just "don't do that on that BIOS, then".
<infinity> Cause the Panda keyboard work fine post-boot, just not in early boot.
<infinity> s/work/works/
<plars> I just double checked, and if I enable serial console in the preEnv on panda, I can enter the password just fine
<infinity> plars: Right, that's expected.
<plars> yeah, but I said I'd check
<infinity> plars: And a fair workaround/recommendation, if I can't fix this before release.
<plars> yeah
<infinity> Since, well.  A "server" with a keyboard is wrong anyway. :P
<plars> well, for panda at least
<infinity> For anything with workable serial or ethernet management, really.
<infinity> So, anything other than a whitebox PC that needs a KVM cause it's crap.
<hggdh> oh, another bug -- on the install, when you get to the selection ((install Ubuntu server, Multiple servers installs with MAAS, etc), select "Boot from first hard disk" -- and you are thrown back into the "select language", and then to the install menu
<infinity> That entry probably just shouldn't be there.
<hggdh> well it has been there for quite a long time
<infinity> (You're still talking ARM?)
<infinity> If x86, then yeah, that's a bug that it doesn't work.
<hggdh> nope, AMD64 install, server
<infinity> Oh!
<infinity> Yeah, that's a bug.
<infinity> Please file.
<hggdh> I am oppening one against D-I
<infinity> Possible cdimage, but d-i works for now, especially if you note it in the pad so we can hunt it.
<infinity> s/possible/possibly/
<infinity> Oh, wait.  To be sure, this is on a system where there's something bootable on the first hard disk?
<infinity> Like, it's not trying to chain out and failing, is it?
<infinity> Cause if the system wouldn't boot anything without install media, there's nothing for us to chain into and boot for that option.
<infinity> Which should/would produce the sort of "loop back to the menu" behaviour.
 * infinity packs more.
<hggdh> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1066387
<ubot2> Launchpad bug 1066387 in debian-installer "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Critical,New]
<hggdh> in the pad now
<infinity> hggdh: Did you see the above?  Is/was there actually something bootable installed?
<infinity> hggdh: (ie: without the boot media in the drive/port, does it boot an OS?)
<hggdh> infinity: this system has B2 installed
<infinity> Alright.  They, yeah, sounds like a real bug.
<slangasek> infinity: what now?  d-i absolutely was rebuilt after the latest shim upload
<infinity> slangasek: After the last shim, not after the last grub2.
<infinity> slangasek: And yeah, I guess stgraber's bug was shim-related, which explains why his bug went away.
<infinity> slangasek: But we still probably need a rebuild for grub2-signed, too.
<hggdh> infinity: and I just confirmed it does have an installed system
<slangasek> infinity: mm; we ought to be rebuilding d-i to use the current grub, was that the issue you spotted the other night with grub2-signed landing much later than expected?
<slangasek> but yes, it was shim that we changed for stgraber, not grub2
<infinity> slangasek: No, this was a new grub2, a day after that non-issue.
<slangasek> ok
<infinity> slangasek: When you respun the world yesterday afternoon.
<slangasek> right
 * slangasek double-checks the grub changelog to refresh his memory
<infinity> Maybe I'll just do a d-i bump right now with a hope/dream that it'll be the last.
<infinity> And then future cdimage builds will just pick it up without thinking.
<slangasek> stgraber: are those errors when booting the image, or after install?
<slangasek> (the insmod errors)
<infinity> I have a sneaking suspicion there may still be a last-minute ti-omap4 revert or something, but I've lost t context on where Paolo is at with debugging recent oddities.
<infinity> Cause, well, weekend.
<slangasek> infinity: I would fully expect the USB-HID stack to be in the initrd and am surprised it's not
<infinity> slangasek: Alright, then we should just fix that.
<slangasek> infinity: so as for d-i, there's no reason to think grub and shim aren't already settled by this point; if a d-i upload and image respin is needed, we should do that ASAP
<infinity> slangasek: d-i's up.
<slangasek> "up"?
<plars> infinity: hmm, if I disable legacy support for usb, then I just end up at the grub menu with no keyboard control
<plars> infinity: but it looks like it's moot now
<infinity> slangasek: As in, uploaded.
<slangasek> and already accepted?  or still waiting to hit the queue?
<infinity> slangasek: It'll hit the queue in 45s.
<slangasek> ok
 * infinity eyeballs his ~/build/initramfs-tools directory and notes that it's nothing but Debian uploads.
<slangasek> infinity: although, note that fixing the module-loading errors in grub that stgraber just posted requires a new round of grub2
<infinity> slangasek: Hahaha.
<slangasek> cjwatson: do you think loadenv and keystatus are safe to add to the SB images?  (and while we're at it, what about tftp?)
<infinity> slangasek: Well, just leave that d-i in the queue, then.  Or reject it and wait.
<slangasek> infinity: so let's just leave that d-i sitting in the queue for the moment, yeah
<infinity> slangasek: Reject it, so no one's tempted to accept it and get all excited about respins.
<slangasek> done
<slangasek> stgraber: did the server image install successfully for you under SB, too?
<infinity> slangasek: Wouldn't tftp in grub provide a simple bypass?  signed-grub->tftp->new-bootloader->chain to whatever?
<infinity> Unless it would check that whatever it got from tftp was also signed before loading it.
<slangasek> infinity: tftp only implements a filesystem interface, it doesn't let you bypass the security checks on module loading or chaining
<infinity> Ahh.
<infinity> Kay.
<slangasek> but it does mean you suddenly have a network filesystem in your signed image, which is a potential source of bugs, and RH/Fedora are currently *not* including this in their SB images :)(
<plars> hmm, but I can still enter the password with legacy support disabled
<infinity> plars: "The password"?
<infinity> plars: You mean for a crypted root?
<plars> infinity: yes
<infinity> plars: Alright, then this may only be ARM that's missing those modules in the initrd.  Add this debugging bit to the bug for me?
<plars> in both cases, usbhid is loaded after boot
<infinity> plars: I'll mangle this first thing Monday.
<plars> ok
<slangasek> infinity: but basically we have no UEFI netboot support at present, and I'm trying to get that all sorted.  If you're not doing SecureBoot you can just drop the kernel and initrd in your memdisk, cook a custom grub.cfg, and go from there; but if you need SB, grub needs a way to access a kernel and initrd that are *not* included in the image
<infinity> (Though, *why* ARM would be missing those modules and not x86, I dunno... Not a lot of arch-specific stuff in initramfs-tools)
<slangasek> stgraber: if you have the time, I would appreciate a bug on grub2 with that screenshot, asking for keystatus+loadenv to be added to the UEFI images
<infinity> slangasek: Is doing this from the bootloader the expected way to do netboot on UEFI, or is this just a hackish workaround until we can build UEFI netboot images to complement the current PXE ones?
<infinity> slangasek: (Seems odd to me to ask one's bootloader to implement a network filesystem)
<slangasek> infinity: it's all debatable
<slangasek> infinity: regardless, I'm concerned about having SB-enabled grub support loading the kernel from the network, because that's how cobbler needs it to work
<slangasek> but I also have no idea if UEFI firmware is going to support the shim model
<slangasek> if it *can't*, then maybe making this work with signed images distributed from the archive doesn't actually matter
<slangasek> but I still don't want cobbler to have to work by implementing "here's a monolithic image containing all the possible kernel and initrds that you might want to boot, download this all at once and enjoy"
<infinity> plars: Can you give me the initrd from that affected system?
<plars> infinity: sure thing, I'll attach it
<infinity> plars: And lsmod from the running system.
<skaet> thanks hggdh
<infinity> plars: And dmesg from the system too.
<slangasek> xnox, jibel: is there a new critical ubiquity/partman bug report in our future?
<hggdh> plars: you have abug for the usb keyboard not working on arm?
<ScottK> Someone should let Mark know that he's already made the milestone of too late to update all the tools to know about the new release name, so he can announce it anytime now.
<skaet> ScottK, done.
<stgraber> slangasek: (replying in order of backlog). The errors are showing up on my installed system. I don't think they were showing up when booting from media, though I booted from media in debug mode, so they might have gone unnoticed in the rest of the log messages flying by
<stgraber> slangasek: I didn't install the server build as I don't have enough USB disks around to both boot and install on USB (and don't quite want to wipe my laptop). I just checked that d-i started fine and then rebooted
<stgraber> slangasek: I'll file a grub2 bug now
<stgraber> slangasek: bug 1066399
<ubot2> Launchpad bug 1066399 in grub2 "grub2 fails to insmod keystatus and loadenv when running with secureboot" [Undecided,New] https://launchpad.net/bugs/1066399
<stgraber> you may want to target/milestone if you think this should be fixed for release. It seems release notable to me as the machine boots fine and doesn't require any user interaction (though the error seems to indicate otherwise)
<stgraber> if you think this should be fixed, let me know once you have a signed grub2 around and I'll reboot to check the fix
<skaet> stgraber, have set it up with Release Notes project targetted to quantal so we don't forget it, at any rate
<stgraber> skaet: ok
<stgraber> I guess it'll end up depending on how much we care about the first boot experience on those systems
<stgraber> if we want it perfect, then we'll need the change (grub2 + grub2-signed) and respin the images, otherwise, a zero-day SRU will fix it post-install
 * skaet nods
<stgraber> oh, though I guess there's also the thing where it's likely that those errors will also show up whenever you boot the install media, so potentially more than just a one time thing for those using live medias pretty often
<stgraber> (but the intersection of people using live media extensively, on non-persistent storage and on systems with secure boot enabled, will likely be pretty small for 12.10 ;))
<skaet> will wait for slangasek's opinion, at any rate - its irritating, but not a real blocker.
<skaet> agree about the user pool forecast,  and scope of risk.    :)
<infinity> stgraber: We need to respin d-i and images for the previous grub2 upload anyway, so it's more a question of "do we want to make these grub changes", not "do we want to re-spin images".
<infinity> stgraber: And I think slangasek was mulling that over before deciding when to unreject my d-i upload.
<doko> lovely, traded two arm build failures for an amd64 one
#ubuntu-release 2012-10-14
<hggdh> crap again. Second install of MAAS on amd64 seems to fail
<hggdh> skaet, plars: http://launchpad.net/bugs/1066421 utter failure on MAAS install, AMD64, server
<ubot2> Launchpad bug 1066421 in maas "fresh MAAS install from ISO fails when opening the MAAS URL" [Undecided,New]
<slangasek> ScottK: mmh, cjwatson managed to extract the codename from him but we're apparently still waiting for the announcement
<slangasek> stgraber: ok; it would be helpful if you could test the server install under SB since I'm not able to, but if you can't you can't
<slangasek> stgraber: thanks for the bug report
<slangasek> skaet, stgraber: so I've targeted the grub bug to quantal, because we should fix it for 12.10; the question is whether it should be post-release or not.  I'm having a look now at whether this impacts the installer's grub.cfg - it may well not
<slangasek> stgraber, skaet, infinity: this bug doesn't affect the media, only the grub.cfg generated by update-grub; so I agree this is release-notable and have targeted to quantal-updates.  Will accept debian-installer now.
<slangasek> skaet: I believe the grub2 -> debian-installer -> debian-cd dependencies related to boot mean that we should be respinning all our bootable images to make sure they're up-to-date.  Should we do that sooner rather than later?
<skaet> slangasek, sooner rather than later would definitely be the preference.
<slangasek> ok.  should I queue up the builds then?
 * slangasek checks the pad for other targets of opportunity
<skaet> slangasek, update the pad, and go ahead.    I'll update the tracker.
<slangasek> skaet: pad updated, build triggers set
<skaet> slangasek, iso tracker has everything except cloud images and wubi now marked for rebuilding.
<slangasek> skaet: you targeted bug #1065686 to quantal-updates but it's still on the pad as an "opportunity target" - do we know where PS is with this?
<ubot2> Launchpad bug 1065686 in unity-scope-video-remote "remote video scope doesn't full switch off traffic when privacy option switched on" [High,In progress] https://launchpad.net/bugs/1065686
<skaet> go ahdead and start it off if you've got it up.
<slangasek> skaet: wubi is being rebuilt.  core is not.
 * skaet fixes core to indicate as such
<slangasek> oh, let me think; maybe wubi doesn't need a rebuild either
<skaet> slangasek, won't wubi need the rebuild once we get the certificates sorted
<slangasek> yes
<skaet> so, doesn't seem much point in spinning it now.
<slangasek> but I need to see how it gets its bootloader and whether it's affected by this d-i change
<skaet> ok
<slangasek> hmmm, I don't think wubi is affected; dropping it from my respin pipeline
<skaet> ok
<skaet> re: PS,  they've got a fix, but its probably tied in with other ones which we don't really want to pick up.
<skaet> go ahead without it,  but leave that one on the pad as an opportunity target if we can get a cherry picked update from them.
<plars> skaet: I added https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376 - keyboard doesn't work to enter password with panda and encrypted partitions under the investigation section, I believe infinity is looking into it but it could be worked around with serial
<ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
<slangasek> skaet: well, unless we're specifically pressing them for a cherry-picked update, I don't imagine we'll see one
<slangasek> anyway - pipelines are all queued up and I'm heading out for the evening
<slangasek> skaet, infinity: if something comes up before the pipes kick off (in ~1h) and you need to cancel them, it's 'killall -9 wait-for-package' on nusakan
<skaet> slangasek,  agreed.   kick'em off
<skaet> why the delay?
 * skaet figures PS is unlikely to be ready in next hour.
<skaet> slangasek,  my understanding is that infinity is traveling now,  so won't be online for a while.
<slangasek> oh, it is about that time, isn't it
<slangasek> skaet: the delay is because we can't rebuild images for the updated d-i until the updated d-i is published...
<skaet> slangasek,  gotcha.
<skaet> plars, ok.  we'll release note it if necessary.
<skaet> :)
<len-dt> skaet, would it be possible to get a ubuntustudio respin?
<len-dt> (after the above is approved..
<skaet> len-dt
<len-dt> ay
<skaet> there's a respin queue'd up now.
<skaet> I'll go in and review the ubuntustudio-meta,  and hopefully it will make it in time.
<len-dt> ok, will the meta package above make it in?
<micahg> skaet: respin is useless without the new meta
<skaet> micahg,  slangasek already queued up the respin,  its started now
<skaet> it may need another to pick up the ubuntustudio-meta though due to timing,  that's all
<len-dt> OK.
<skaet> len-dt, micahg - package looks ok.  it's approved
<skaet> not sure if it will build in time or not for the respin.
<skaet> if its not included in the next set of images, ping on this channel and one of the release team will kick off the respin to pick it up.
<len-dt> will do, I'll test it tonight (PDT -700)
<skaet> thanks
<len-dt> NP
<slangasek> hmm, why has the debian-installer publication not made it out to nusakan yet :P
<slangasek> so the builds haven't started yet, because the trigger has thus far failed
<slangasek> so good news for ubuntustudio, I guess
<slangasek> because there was a stale lock file, sigh
<slangasek> ok, image builds starting now
<ScottK> I guess that answers the question about if I should stay up and wait for a fresh build to do more testing tonight.
<slangasek> apparently
<slangasek> sorry :/
<ScottK> No problem.  Sleep is for the best anyway.
<stgraber> slangasek: ok, I'll figure some way of doing a server install on that laptop later today or (more likely) tomorrow.
<xnox> slangasek: maybe we do have a couple ubiquity bugs: bug 1066347 bug 1066302 bug 1065502
<ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
<ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [High,Confirmed] https://launchpad.net/bugs/1066302
<ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
<xnox> the middle one is funny... as the update this installer shouldn't be shown at all, because we did not trigger 0day ubiquity update.
<cjwatson> slangasek: keystatus and loadenv are simple and should be fine - adding those now.  I'm less sanguine about tftp; would rather do that at a bit more leisure.
<cjwatson> ^- cloud fix + secure boot fix.  The former at least needs a quick regression-test on real BIOS as well
<jibel> slangasek, there are 2 bugs that are important when installing over an existing installation bug 1065502 and bug 1066347
<ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
<ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
<jibel> first one hangs the installer, second breaks the 'reinstall' functionality
<xnox> cjwatson: doesn't loadenv -> reads & loads stuff from hard-drive & hence could be altered while machine is off leading to possibly doing something to bypass secure-boot or inject something?!
<jibel> I reproduced bug 1066445 - fresh desktop installation with latest amd64 image
<ubot2> Launchpad bug 1066445 in apt "Crashes doing update or upgrade operations" [Critical,Confirmed] https://launchpad.net/bugs/1066445
<ScottK> The massif-visualizer uploadis mine, so I can't accept it.  Should be an easy one for someone to review.
<cjwatson> xnox: It reads environment variable settings, but that shouldn't let you execute arbitrary code before ExitBootServices.
<cjwatson> doko: Your cairo-5c sync FTBFS ...
<cjwatson> ScottK: Accepted.  You can close bug 935294, I think.
<ubot2> Launchpad bug 935294 in massif-visualizer "massif-visualizer version 0.3-0ubuntu1 FTBFS on armhf in precise" [High,Confirmed] https://launchpad.net/bugs/935294
<cjwatson> xnox: Also, note that "arbitrary code" in this context specifically excludes being able to run arbitrary GRUB commands; we already know you can do that and the system is structured so that that should not be a problem.  It would only be a problem if you could somehow arrange to run arbitrary code which is not already exposed as commands.
<cjwatson> xnox: Remember that we *already* load /boot/grub/grub.cfg from the hard disk.
<skaet> cjwatson,  would you mind turning off image erasing?   we're starting to stradle multiple days now and the historical ones may be useful.
<skaet> (testing against at any rate)
<cjwatson> done
<hggdh> anyone confirmedhttps://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 ?
<ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,New]
<cjwatson> (not available for most of rest of today)
<skaet> thanks cjwatson
<ScottK> cjwatson: Thanks.  Forgot about the bug.
<hggdh> why is 'ubuntu' considered a weak password for an user, and a fair password for disk encryption?
<skaet> ScottK, stgraber, slangasek, infinity -  can one of you take a look at https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1066445?   we may need to revert that last apt upload.
<ubot2> Launchpad bug 1066445 in apt "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Critical,Confirmed]
<hggdh> skaet: is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 important enough?
<ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,Confirmed]
<skaet> hggdh,  ugh.   not recognizing there's data there isn't good.  :P
<hggdh> my thought also... adding to the pad
<skaet> am marking it critical for now.   slangasek may modify that - but want it looked at as soon as possible.
<hggdh> pad-added
<hggdh> skaet: I cannot reproduce 1066445, and I do have main, universe, multiverse, partners in the source.list
<skaet> hggdh,  interesting.    update from fresh install of precise?
<skaet> what did you start from?
<hggdh> skaet: I was already on quantal. I think this may be the difference
<hggdh> I can try from precise
<doko> cjwatson, known (as it was ftbfs before too), this was just for cleaning up the source package.
<jibel> skaet, it is not reproducible on every system. I haven't found a pattern yet but got it on hardware and VM, fresh installation, all amd64
<jibel> (re. 1066445)
<hggdh> jibel: were you upgrading?
<jibel> hggdh, no, right after a fresh installation
<hggdh> ok so I am without a failure indeed
<infinity> cjwatson: Accepted grub2, and uploaded a grub2-signed to go with it.
<infinity> (If anyone else wants to let the -signed through...)
<xnox> hggdh: actually both passwords use the same algo, so actually passwords should be reported as "the same strengthness"
<hggdh> xnox: somehow they are still shown as fair and weak. So... bug on it
<xnox> cjwatson: ok, thanks for explanation.
<xnox> about bug 1066480. There is currently no UI to activate encrypted partitions (but partman can do it) but the other thing is that there is no ui nor partman functionality to de-activate encrypted partitions, which maybe desired for wipe & reinstall. Maybe we need to release note it.
<ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480
<hggdh> xnox: and, on a server install, both passwords are shown as 'weak'
<xnox> hggdh: yes file bug. ubiquity != server cd. Ubiquity and debian-installer use different algorithms.
<hggdh> ack
<hggdh> will repeat to capture the data (original install is long gone)
<phillw> infinity: could you take a look at bug 1066435 thanks
<ubot2> Launchpad bug 1066435 in debian-installer "Debian-installer powerpc recursive fault" [Undecided,Confirmed] https://launchpad.net/bugs/1066435
<skaet> infinity, accepted grub2-signed
<skaet> lamont,  jibel saw the failure on hardware and VM,  fresh installation,  all amd64.  hggdh hasn't been able to see it though.   what are the specifics of the system you saw 1066445 on?
<lamont> skaet: I'd have to dig a bit, but I'm pretty sure this was an install from this year, call it precise, amd64, real hw.  do-release-upgraded to quantal at beta(1?), and dist-upgraded pretty much daily since then.  has quantal{,-{security,updates}} {main,universe,multiverse} (I should add restricted...sigh), as well as a ppa or 2
<lamont> and a local arhcive
<lamont> the mirror I hit is synced from us.archive at :50 each hour
<skaet> thanks lamont, can you add that to the bug, so we see if we can get the pattern figured out?
<lamont> sure
<skaet> hggdh - can you add the details of the configurations you've tried that work to it as well?   would like to get as much of the data summarized in one place as possible.
<skaet> thanks lamont
<lamont> posted, with spell checking, even
<skaet> :)
<hggdh> skaet: added. I do get it with main, universe enabled
<skaet> thanks hggdh
<slangasek> cjwatson: tftp> ack :)
<slangasek> cjwatson: there's no hurry, I'm still trying to prove to myself that I can actually get a working system using tftp
<lamont> slangasek: working how?
<slangasek> xnox: I was asking specifically about the bug that jibel said was still present after you fixed it... was that bug #1065502?
<ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
<slangasek> lamont: grub2 efi tftp
<lamont> ah
<lamont> that fails on my caring-scale
<slangasek> lamont: with grub.cfg and kernel all loaded via tftp from grub, not bundled in a memdisk
<lamont> at least for the moment
<xnox> slangasek: it's a newly introduced bug, but has similar symptoms.
<slangasek> xnox: hmm, ok
<xnox> slangasek: the root cause is unclean unmounting of the /target resulting with "journal replay required" on first mount.
<xnox> slangasek: which is cleared if you at least boot your system once, but not fine if you don't.
<slangasek> xnox: ah; so this is only a problem for people who are serial installers?
<xnox> it needs to be digged into why we are leaving the filesystem dirty at the end.
<xnox> =)))))))
<xnox> yes.
<xnox> or force power-cycle shutdowners.
<slangasek> xnox: then that shouldn't justify a respin on its own if that's the worst of the symptoms.  Unclean unmounting is obviously not good though, so please chase it up
<xnox> ack. ok.
<slangasek> skaet: the latest upload of apt only pulls in translation updates.  whatever this bug is, there's nothing to suggest it's tied to the latest upload (and therefore there's nothing to revert), nor evidence that it's widespread.
<slangasek> skaet: well, modulo the fact that jibel and lamont both mention in scrollback that they're seeing it.
<slangasek> skaet: anyway, the fact that a revert doesn't help still stands
<jibel> slangasek, I have an easy test case for the apt bug: default install with free software enabled. Then all apps that depends on libapt will crash.
<slangasek> jibel: except hggdh says he couldn't reproduce it?
<jibel> slangasek, he said he did in comments 13 and 14
<slangasek> ah, ok
<slangasek> jibel: could you attach the sources.list (+sources.list.d) from this system?  may help to reproduce it more quickly
<slangasek> also, the /var/cache/apt/pkgcache.bin that I asked for in the last comment
<jibel> slangasek, it's uploading
<jibel> removing the cache files does just make apt crash later when it recreates them.
<skaet> slangasek,   that was my understanding too, however the timing does seem a bit suspect.
<skaet> however,  finding root cause is the key at this point.
<jibel> slangasek, done uploading, it's enough to copy the sources.list file attached to the bug report to an existing system to reproduce the crash.
<hggdh> skaet: bug 1066556 should be either looked at, or release-noted. Which one?
<ubot2> Launchpad bug 1066556 in debian-installer "MAAS install via d-i/tasksel fails whe opening the browser to /MAAS" [Undecided,New] https://launchpad.net/bugs/1066556
<cjwatson> server team should look at that
<cjwatson> skaet: if the timing of the apt upload is relevant, then since there are no source changes other than translations, it must be because *any* upload (and hence recompile) would have broken it; and therefore a revert won't help
<cjwatson> but it could be something to do with the content of the Packages/Sources files
<cjwatson> infinity: Thanks.  I was going to fiddle with grub2-signed to make sure it fetches binaries from -proposed - I suspect it might fail to build until grub2 hits release (which it probably shouldn't)
<cjwatson> I'll sort that out tomorrow morning if nobody else has
<cjwatson> Yeah, I can reproduce this with jibel's sources.list, though not with what I had in my sbuild chroots
<skaet> cjwatson,  understand.
 * cjwatson attempts a debug build
<cjwatson> oh, for crying out loud, goes away when I try to debug it
<cjwatson> I suppose that's to be expected for something introduced by a no-relevant-changes upload
<cjwatson> oh, I forgot to put the relevant sources.list in place, whoops
<cjwatson> OK, reproduced with a debug build now, which'll help
<cjwatson> And under valgrind
<cjwatson> (But not desperately helpfully)
<cjwatson> God I hate C++
<cjwatson> And it's all tied up in the cacheiterators stuff which I've never really understood at the best of times
<cjwatson> Overly-clever Jason C++
<cjwatson> Ah - well, it'll take me a bit longer to actually fix it, but I've tracked it down to excruciatingly unlucky timing of cache remapping in a function unequipped to handle it
<cjwatson> So yeah, pretty sure reverting apt will make no difference worth mentioning
<cjwatson> Unfortunately there may be a hard-to-resolve upgrade problem with old versions of apt; don't know what we can do about that short of (a) randomly permute size of cache by continuing normal development (b) SRU whatever fix we come up with
<cjwatson> And possibly (c) release-note instructions for manually installing new apt
 * cjwatson gets a feel for the pattern of working code now
<skaet> cjwatson,  thanks for tracking that down.   Release noting is probably prudent based on the scenario you describe.
<cjwatson> Fairly sure http://paste.ubuntu.com/1280162/ is the fix, or something very like it
<cjwatson> The problem was that Prv->ProvideVersion was evaluated before the function assigning to it, which, in some very rare cases, changes Prv
<cjwatson> skaet: would you mind setting up a release notes task on that bug?  I haven't kept track of the current method for doing that
<skaet> cjwatson, will do.
<cjwatson> thanks
<skaet> cjwatson, release note task added, and have gone ahead and put bug and instructions on doing the manual update in the CommonInfrastructure  known issues section.
<cjwatson> apt fix on its way to -proposed now - please review.  Sorry for the giant po/ diff but I believe it's all just trivial line number changes and other similar rearrangements.  The previous uploader mustn't have used 'bzr bd -S', I guess.
<cjwatson> skaet: Yeah, that won't work :)
<cjwatson> If 'apt-get install apt' worked this wouldn't be hard
<skaet> cjwatson,  ah well, I hoped.   Adjust as needed.
<cjwatson> reverted to an XXX comment for now
<skaet> k
<cjwatson> Oh, thinking about it, I bet fiddling with APT::Cache-Start would work around it
<cjwatson> Too tired to write coherent release notes at the moment but let me quickly test that before bed while the problem is still reproducible
<cjwatson> Right, yeah, that worked fine.  Workaround in the bug now.
#ubuntu-release 2013-10-07
<infinity> tjaalton: Can you make up your mind about libatomic-ops-dev? :P
<infinity> tjaalton: Oh, it was doko who added it, not you.
<infinity> tjaalton: Why is it no longer necessary?
<tjaalton> infinity: the xmir patch on xorg-server got fixed
<infinity> tjaalton: Yeah, I sorted that eventually.
<rbasak> Could someone review bug 1209493 for an FFe, please? It's ready to land.
<ubot2> Launchpad bug 1209493 in subversion (Ubuntu) "[FFe] libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<infinity> rbasak: Why not merge instead of cherry-pick?  Some of nmu4 looks worthwhile too.
<rbasak> infinity: I was focused on a specific bug for the FFe since that's the one I wanted to justify.
<rbasak> I can do a merge instead if you're fine with that.
<infinity> rbasak: I'd prefer the merge, TBH.
<rbasak> np, I'll prepare a merge instead.
<rbasak> Thanks
<lool> ^ qtbase-opensource-src was tested by Mirv, I just sponsored it; it's a bugfix that he confirmed fixes what it was supposed to fix and he tested it doesn't regress apps on the touch image
<Mirv> I'm also running the qtbase update on desktop (Qt Creator etc), but most testing done on touch (all autopilot tests + manual testing)
<plars> infinity: we should be seeing rc candidate images at some point today I guess?
<jdstrand> can someone approve click-apparmor 0.1.11-- it is touch only and has been approved by #ubuntu-ci-eng
<xnox> plars: no.
<cjwatson> ^- I think libprelude will actually FTBFS, but I'm getting it back into sync before uploading a build fix, basically to avoid having to do a merge later
<cjwatson> forgot it'd be frozen ...
 * cjwatson attacks the last few Apache 2.4 stragglers
<Laney> seb128: I have a couple more patches for g-s-d
<Laney> can I reject yours and include them
<Laney> ?
<seb128> Laney, which ones?
<Laney> one from darkxst to fix media keys
<Laney> and https://code.launchpad.net/~attente/gnome-settings-daemon/non-latin-media-keys/+merge/189369 which I've not reviewed yet
<seb128> Laney, there is more work at flux for keyboard stuff but I was unsure if we wanted to mix it all, or get that obvious fix in and do anothe upload
<seb128> Laney, ok, your call on whether you want to delay/batch them
<seb128> I'm not picky
<Laney> you might want to review that
<seb128> I had a look, that's where I decided to upload the obvious one first and do another upload later :p
<Laney> fair
<seb128> Laney, I need to ask details to attente, I don't understand the problem/solution enough to make sense of the code
<Laney> well I at least want to do Tim's
<Laney> ta
<seb128> yw
<cjwatson> tjaalton: Could you look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725701 fairly urgently?  We need to get rid of the Apache 2.2 remnants in time for saucy.
<ubot2> Debian bug 725701 in 389-admin "389-admin: port to Apache 2.4" [Important,Open]
<seb128> Laney, hold a bit on the upload if you want to do one, discussing the patch on #ubuntu-desktop now
<Laney> ok
<Laney> rejecting anyway
<Laney> I'll push tim's thing to bzr
<tjaalton> cjwatson: oh, sure
<tjaalton> thanks
<cjwatson> self-rejecting gnutls26, slight bug, fixing
<tjaalton> sigh, the sponsor for 389-admin never pushed git, grr
<tjaalton> and haven't seen him since
<tjaalton> cjwatson: i wonder if a rebase to upstream 1.1.35 would be in order.. it's not like these are widely used
<tjaalton> 20 commits
<cjwatson> tjaalton: If it doesn't break FF
<cjwatson> tjaalton: I think you'd still need the patches I added/changed aside from apache-2.4.patch
<tjaalton> sure
<tjaalton> i guess it falls under bugfix-release
<cjwatson> jdstrand: accepted, sorry for the delay
<jdstrand> cjwatson: thanls
<jdstrand> thanks even
 * stgraber starts doing some queue review
<cjwatson> ^- better this time
<cyphermox> Laney: re: bug 1234887
<ubot2> Launchpad bug 1234887 in network-manager (Ubuntu) "[FFE] Update NetworkManager to 0.9.8.4" [Wishlist,Confirmed] https://launchpad.net/bugs/1234887
<cyphermox> ^ the soname doesn't change but there is a (minimal) new feature... so I've marked this as a FFE
<cyphermox> I'd very much like to land this as it contains quite a lot of useful bug fixes, but I realize it's quite late
<Laney> cyphermox: what's 4a4d58a libnm-glib: bump soname then?
<cyphermox> confusing -- http://paste.ubuntu.com/6205347/
<cyphermox> as a result, unless I'm misreading, the soname doesn't change
<cyphermox> appologies for the not diff -u output ;)
<cyphermox> I'll still do a build test for the reverse-deps, just saying it's not a transition
<Laney> cyphermox: mmm, seems fine then
<Laney> in that regard anyway
<Laney> has it been well tested?
<cyphermox> Laney: I'm still working on that
 * cjwatson self-rejects the libprelude sync in favour of a build-fixing upload
<Laney> Riddell: is opencv meant to remove debian/*.docs?
<Riddell> Laney: yeah that's deliberate
<Laney> Would be nice if it were in the changelog
<Laney> is it because installdocs installs it anyway?
<Laney> Riddell: Can you forward or ask the sponsoree to forward both of these things to Debian? It looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720092#22 is false
<ubot2> Debian bug 720092 in src:opencv "Please package ocl" [Wishlist,Open]
<Laney> At least assuming your build-dep is right
<Riddell> Laney: yeah will poke him
<Laney> ok
<Laney> accepting
<rbasak> infinity: I've prepared a merge for bug 1209493
<ubot2> Launchpad bug 1209493 in subversion (Ubuntu) "[FFe] libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<rbasak> infinity: could you provide a final ack now please, and I'll find a sponsor?
<slangasek> infinity: you're still killing off the linux-ti-omap4 package, right, so I can ignore the build failure here?: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130917-saucy.html
<ogra_> *sniff* ppor pandas
<ogra_> *poor even
<slangasek> they can still run the server images :)
<cjwatson> huh, can they if we remove that kernel?
<ogra_> faceless servers, yeah :/
<ogra_> cjwatson, they run fine with mainline
<ogra_> the GPU driver doesnt
<cjwatson> aha, ok
<ogra_> i wish we had decided to do a panda touch image ... that would come in so handy for test setups
<ogra_> (though that would have used the same kernel)
<infinity> slangasek: Yes, ti-omap4 is dying this week.
<Laney> does that include the xorg revert?
<infinity> Laney: Yes.
<Laney> excellent
<infinity> plars: Not unless today is Thursday and I slept in even longer than I thought.
<stgraber> queuebot was asleep but there's a very small lxc change in the queue if someone could review it
 * infinity snickers at all the "dnlcpp..." dependencies in the latest cross uploads.
<stgraber> Laney: that evolution-data-server change scares me a bit after FeatureFreeze and that close to release. What exactly will happen to existing users? will their existing accounts just disappear, will they magically still work, does that change affect the UI?
<stgraber> Laney: it seems like this falls under the "can't get any worse" reason for accepting but I'd prefer to confirm it first ;)
<Laney> stgraber: The accounts will still be in Online Accounts, but they won't be integrated with e-d-s any more
<Laney> If it somehow worked for you then that'll stop obviously and you will need to re-add them in evo
<Laney> I didn't think about the UIF aspect, but there are some toggles in Online Accounts that won't be there any more
<Laney> (If you like, you can test what happens with the current setup by removing evolution-data-server-uoa)
<stgraber> Laney: did we have that online account stuff enabled in previous releases?
<Laney> It's new in Saucy
<stgraber> ok
<stgraber> what's the likelihood that someone actually managed to use that thing at some point in the cycle?
<Laney> It wasn't completely busted
<Laney> but broken enough in bad enough ways
<stgraber> Laney: ok, get me an ubuntu-gnome lead to ack on this and I'll accept it
<stgraber> (since they're the only ones actually seeding evolution)
<Laney> ok, shouldn't affect them as I kept -goa as a Depends
<Laney> (why is evolution-dbg supported for ubuntu?)
<stgraber> Laney: probably somehow caught by the big regexp in supported
<stgraber> Laney: ah good point, if they don't ship ubuntu-online-accounts then that shouldn't affect them at all
<Laney> more flavours seed e-d-s btw
<stgraber> sure but they won't be nearly as affected as say a user actually using evolution who suddenly won't see any account when opening it
<Laney> There's the calendar integration in indicator-datetime
<Laney> darkxst: ^^^ want to confirm my e-d-s changes in saucy unapproved look ok?
<stgraber> Laney: ok, so that's edubuntu, ubuntu, ubuntu-touch and ubuntukylin then
<stgraber> Laney: as an edubuntu lead, I don't care, we just want the same as Ubuntu
<stgraber> Laney: touch I'm not sure about, isn't that how you're supposed to access your google contacts on the phone?
<stgraber> (no idea if that even works, I don't use google myself)
<darkxst> Laney, we use GOA so those changes wont affect us
<stgraber> Laney: ok, so you're left with ubuntu-touch and ubuntukylin (which I suspect will just want the same as Ubuntu anyway)
<Laney> stgraber: I think that touch thing syncs things into e-d-s
<Laney> hmm
<Laney> I've got to go, maybe do a safety reject and I'll follow up on those two tomorrow
<stgraber> Laney: ok, thanks. I'll reject and I'm always happy to accept from the reject queue once we've confirmed it's fine for everyone.
<Laney> k
<stgraber> crap
<Laney> hahaha
<Laney> block time?
<stgraber> wrong button and I wasn't quick enough
<stgraber> yep, I'll push a block
<stgraber> I don't like LP being fast these days, that escape was pressed within ms of me clicking the wrong UI button
<infinity> "fast"
<infinity> I don't think I've heard that accusation before.
<Laney> JackYu: ^ can you check/confirm that removing evolution-data-server-uoa (pretty badly broken) in saucy is ok for kylin?
<stgraber> bdmurray: ping
<stgraber> bdmurray: the delta for ubuntu-release-upgrader looks a bit weird. The changelog only mentions the switch to pkexec but looking at the diff, I see command line option removal and UI elements removal too...
<stgraber> (well, and the ton of usual ubuntu-release-upgrader changes whenever someone uploads it, but that I expected)
<bdmurray> stgraber: is there a url that you are looking at?
<stgraber> bdmurray: http://launchpadlibrarian.net/152567426/ubuntu-release-upgrader_1%3A0.204_1%3A0.205.diff.gz
<bdmurray> the UI element removal is related to showing the release notes which is redundant because do-release-upgrade shows them
<bdmurray> the --test-uri option was just to show the release notes which check-new-release-gtk will no longer be doing
<stgraber> ok
<stgraber> that's all I noticed so I guess that's fine then, accepting
<bdmurray> okay, thanks.  I'll be more verbose in the future.
<JackYu> Laney, sure, will check soon.
<jdstrand> fyi, per landing page, dbus and apparmor-easyprof-ubuntu uploads are coming
<lool> jdstrand: is there an usual reviewer for apparmor-easyprof-ubuntu?  I see it's seeded in supported
<jdstrand> lool: you mean an archive admin?
<lool> no, release team
<jdstrand> I seeded it, but it isn't on the desktop image
<jdstrand> no, not really
<jdstrand> it is only on touch
<lool> jdstrand: ok, because it's seeded outside of just touch it has to be reviewed by release team
<lool> jdstrand: and obviously same for dbus
<jdstrand> lool: I noted in the landing plan that I tested several webapps and click packages (the only things that use it)
<jdstrand> right-- I mentioned 30 minutes ago they were coming
<jdstrand> (in this channel)
<lool> jdstrand: yup, seen that, was just hoping someone was already used to reviewing these  :-)
 * jdstrand nods
<infinity> To be fair, that apparmor-easyprof-ubuntu upload is pretty much unreviewable.
<jdstrand> quite a bit of policy updates due to late landing and various changes
<jdstrand> infinity: oh?
<infinity> jdstrand: Well, not without taking hours to comb through it all. :P
<jdstrand> I've reviewed it quite extensively :P
<slangasek> if it's only on touch, it needs to be "reviewed" by the release team
<infinity> Yeah.
<slangasek> viz:
<infinity> I'm not putting much effort into it, just looking for obvious glaring hilarity.
<jdstrand> it is in the supported seed, but not any images other than touch
<infinity> Or, slangasek can beat me to it.
<jdstrand> I'm sponsoring the dbus one for tyhicks
<slangasek> jdstrand: does apparmor-easyprof-ubuntu go through daily-landing-meatgrinder?
<infinity> The dbus one, I'll have a closer look at.  But I also assume it's not as extensive?
<jdstrand> slangasek: if you mean the landing page-- lool and I have been discussing it. this has an important change for webapps due to hybris changes with gstreamer, but also is required for two other landings
#ubuntu-release 2013-10-08
<lool> jdstrand: I think he meant cu2d
<slangasek> jdstrand: I mean, are there integration tests for this before it gets uploaded to the archive
<jdstrand> infinity: I'll let you and tyhicks discuss it
<jdstrand> slangasek: there is a testsuite in the build. there haven't been integration tests due to lack of running click packages in the testing. that is changing and lool found the problem with webapps because of those tests
<infinity> slangasek: If it went through cu2d, it would have been a sync, not a sourceful upload.
<tyhicks> infinity: the dbus changes fix a few subtle bugs in the apparmor mediation code that I recently discovered
<slangasek> infinity: you're assuming I looked that closely ;)
<lool> slangasek: the AP test runs on the stack will pull it, but from the archive, so too late
<slangasek> lool: right
<cjwatson> slangasek: clue is that if it's a sync then queuediff doesn't work
<cjwatson> I'm assuming you at least looked at the diff briefly ... :)
<infinity> tyhicks: *nod*... If Jamie's happy with it, upload away.  I'll give it a quick twice-over in the queue.
<slangasek> cjwatson: idem
<slangasek> ;)
<slangasek> cjwatson: I really didn't, I pushed it through on the grounds that phone is not supposed to be frozen
<cjwatson> ah
<infinity> Oh, bugger.  I was going to update gdb to 7.6.1 for the tasty, tasty bugfixes, but zumbi rolls the Debian tarballs by hand, and I don't want to desync.
<infinity> (Among other things, it fixes the Most Annoying GDB Bug Ever: https://sourceware.org/bugzilla/show_bug.cgi?id=15415)
<ubot2`> sourceware.org bug 15415 in gdb "gdb resolves symbolic links when passing argv[0]" [Normal,Resolved: fixed]
<cjwatson> cherry-pick that one?
<tyhicks> jdstrand: do you need anything else from me prior to sponsoring the dbus upload?
<infinity> cjwatson: Yeah, but 7.6.1 is all bugfixes, probably makes sense to pull it anyway.  I'll see if zumbi's cut a tarball for it (or, indeed, why he does his own at all).
<jdstrand> tyhicks: no-- I uploaded it. just answer infinity's questions
<tyhicks> infinity: when doing your twice-over for the dbus upload, I listed the tests that I wrote and ran for this upload here: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1229280/comments/1
<ubot2`> Launchpad bug 1229280 in dbus (Ubuntu) "Eavesdroppers confined with AppArmor can see all method_return and error messages" [High,In progress]
 * jdstrand steps away for some food
<tyhicks> thanks jdstrand
<jdstrand> tyhicks: thank you! :)
<jdstrand> slangasek and infinity: and thank you for the reviews
 * jdstrand -> food
<infinity> tyhicks: Eww, 1233895 is an icky bug.
<tyhicks> infinity: it is, but jdstrand handled the policy updates in apparmor-easyprof-ubuntu and that was the only policy affected
<tyhicks> infinity: we were lucky that there isn't really any complex dbus policies outside of apparmor-easyprof-ubuntu
<slangasek> cjwatson: so I *think* lp:~vorlon/ubuntu/saucy/grub2/lp.1236625 is a right fix... this seems like it's important enough to get in for release IMHO
<infinity> tyhicks: So, dropping the compat bit.  What will that mean for people who upgrade from older releases?
<tyhicks> infinity: nothing - saucy is the first release to have apparmor mediation extended into userspace
<infinity> tyhicks: Sure, but when the userspace is upgraded and the kernel isn't, will things explode somehow?
<tyhicks> infinity: only if you're still on a dev release kernel from about a month or two ago
<smoser> hey. i just did a upload of cloud-init :-(. wish I did not have to. changes to last accepted version are very minimal. if someone could accept that would be wonderful to get it into a build tonight to fully test it.
<infinity> tyhicks: Okay, so if you're on raring's 3.8, it'll all just no-op cleanly, and if you're on a current saucy kernel, it's good, but if you're in between, the world goes sideways?
<tyhicks> infinity: sorry, my connection dropped for a few minutes after I said "only if you're still on a dev release kernel from about a month or two ago"
<infinity> 18:19 < infinity> tyhicks: Okay, so if you're on raring's 3.8, it'll all just no-op cleanly, and if you're on a current saucy kernel, it's good, but if you're in between, the world goes sideways?
<tyhicks> infinity: yes, but the "in between" is only a couple saucy dev release kernels
<infinity> tyhicks: Or, another way of phrasing that: "if I'm upgrading online from raring to saucy, and dbus gets restarted in this new version on my raring kernel, did you just hose my system until I reboot?" :P
<infinity> tyhicks: Kay.  If it's just a few dev kernels that explode, I don't care.
<tyhicks> infinity: dbus-daemon looks for /sys/kernel/security/apparmor/features/dbus, which doesn't exist when running a raring kernel
<infinity> Kay, cool.
<infinity> Acceptiferated, then.
<tyhicks> if that directory isn't there, then the apparmor mediation hooks are disabled
<tyhicks> infinity: thanks! (and good questions ;)
<cjwatson> slangasek: Thanks, staged locally and will think about it during my daytime (since it isn't trivial)
<cjwatson> slangasek: Would you mind renaming the patch to ubuntu_something.patch?
<cjwatson> I prefer to keep a stack of ubuntu_* at the top
<smoser> is this in the right state https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1233486 . i'm hoping for (i realize last minute) FFe.
<ubot2`> Launchpad bug 1233486 in software-properties (Ubuntu) "[FFe] add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Medium,New]
<lool> would be nice to get a britney run for dbus to migrate; it seems all autopkgtests ran now
<cjwatson> It'll get one, there's stuff publishing now
<lool> thanks
<lool> dbus valid candidate -- cool
<cjwatson> and accepted, more to the point :)
<lool> right  :-)
<infinity> doko_: Something went sideways with your contol.m4 magic.  All the cross packages have a broken dep on "dnlcpp-4.8-$triplet"
<slangasek> cjwatson: ok, renamed and pushed
 * slangasek looks blankly at launchpad.  mountall 2.51 accepted?  but er, that was uploaded weeks ago
<slangasek> oh, arm64 build \o/
 * slangasek scratches his head, noticing only now that it's called arm64, not aarch64
<cjwatson> You're too late if you want to object. :)
<infinity> slangasek: It's arm64 in the kernel too.  Linus had the same objection as I did to the silly name.
<cjwatson> slangasek: Did you get a mail about it or something?
<slangasek> cjwatson: I did
<infinity> (Though, I appreciate the GNU name being oddball, because it doesn't match arm*) cases)
<cjwatson> Uh
<slangasek> infinity: yeah, at least if it's consistent with the kernel
<infinity> cjwatson: Yeah, people get fresh accepted mails when britney does the copy.
<cjwatson> Oh, this was a build in PROPOSED
<cjwatson> Right, fine (ish)
<slangasek> :)
<cjwatson> Won't apply to the bulk of builds in the RELEASE pocket
<infinity> A bit confusing, since it's a full copy of the source again, and the mail has no indication that it's because a new arch caught up.
<infinity> But oh well.
<cjwatson> And the mail is kind of half-arsed IIRC.
<cjwatson> It's missing the changelog bit.
<cjwatson> Which is such an indication - but only if you know WTF it means
<infinity> slangasek: Well, it's consistent with the kernel source tree, not with uname.  Confused yet? :)
<slangasek> infinity: uname == aardvarch?
<cjwatson> Anyway, arm64 is building real stuff now, scored to try to supersede the bootstrap archive first
<infinity> slangasek: The Debian arch arm64 builds the GNU arch aarch64-linux-gnu on the kernel that reports aarch64 to uname -m, where the source is in arch/arm64.
<infinity> slangasek: NOT CONFUSING AT ALL. ;)
<cjwatson> It's not remotely in the right order so loads of stuff will depwait
<infinity> Tore through lapack fairly well.
<cjwatson> ~Twice the speed of akateko/kishi07, ~half the speed of allspice/sagari.
<cjwatson> But akateko probably doesn't count; I bet it was spending ages on docs or something.
<infinity> Yeah.
<cjwatson> The build log is certainly huger.
<cjwatson> Lotta docs.
<infinity> cjwatson: Hah, the one-line response to your well-thought-out gnulib/as-needed analysis is great.
<cjwatson> infinity: I think that's Paul's way of saying "please send a patch for your preferred option"
<cjwatson> (Paul is the star of my favourite Uli story, so I'm inclined to give him the benefit of the doubt)
<infinity> cjwatson: Or "can't type; cat in face".
<cjwatson> That story being essentially http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59829, especially http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59829#55
<ubot2`> Debian bug 59829 in libc6 "libc6: [PATCH] fnmatch() behaves oddly with *s and FNM_LEADING_DIR" [Fixed,Open]
<cjwatson> Uli demands bug report from somebody he's heard of: Paul says OK and copies and pastes my bug report verbatim
<JackYu> Laney, sure, it's ok for UbuntuKylin.
<infinity> cjwatson: Trade you reviews.
<cjwatson> infinity: Yep
<cjwatson> infinity: blt is basically for arm64 too although it's less urgent
<infinity> cjwatson: You could have skipped changing the build-dep if you used --with autotools-dev instead.
<cjwatson> I could've.
<infinity> (I intensely fear autoreconf unless knowingly patching configure.in and testing the result is sane, but to each their own)
<cjwatson> I do use that sometimes when it's significantly easier (not dhed yet, or autoreconf blows up)
<cjwatson> I test-built in this case
 * infinity nods.
<lool> (indicator-power was uploaded to fix a settings:/// link for touch but is seeded on desktop; it was tested by sil2100 successfully)
<infinity> lool: I'll look at it.
<Mirv_> lool: mirv, that is :)
<Mirv_> it's a one char change on the url_dispatcher's url that's used on touch.
<infinity> Mirv_: Developers are interchangeable parts.  Sufficient time in management teaches this.
<lool> Mirv_: oh sorry
<lool> Mirv_: braing bug
<Mirv_> so, the change is one char change in url string that is used on touch only (on_phone_settings_activated)
<lool> infinity: except you of course, you're unique!
<infinity> lool: I'm as unique as a snowflake tattoo on a hispter's neck.
<Mirv_> thank you
<infinity> cjwatson: ^
<happyaron> I think it's okay to upload a minor fix for a wrong dependency for packages in universe?
<infinity> happyaron: You think correctly.
<happyaron> thanks
<cjwatson> USE_LATEX_LOL_DOLPHIN_HASHTAG_YOLO
<cjwatson> blink
<davmor2> cjwatson: don't blink that's when the weeping angels get you :D
<cjwatson> I went to Edinburgh shortly after watching Blink the first time
<cjwatson> CITY WITH GARGOYLES EVERYWHERE
<cjwatson> It was suboptimal
<apw> cjwatson, ohhhhh that would be bad
<maclin> cjwatson, hi, could you help to take a little time reviewing the merge request of ubiquity for ubuntukylin? We just modify one line to change the background pic name.
<cjwatson> maclin: The weird bit for me was the claim that this was a "name rule" for Ubuntu
<cjwatson> It's not
<cjwatson> The reason Ubuntu is warty-final-ubuntu.png is basically that we made a mistake back in the 4.10 days and need to stick with it to preserve upgrades
<cjwatson> I don't understand why UbuntuKylin feels it needs to mimic this mistake
<cjwatson> ubuntukylin-default-settings.png is actually a better name for it, rather than having a bogus series name in there
<cjwatson> If you think this is a "name rule", then somebody has got the wrong end of the stick at some point
<maclin> oh, we just change it according to the name of ubuntu, we really don't know the mistake :P
<infinity> cjwatson: http://www.youtube.com/watch?v=FwK4eAhLGYg&feature=player_detailpage#t=18
<infinity> cjwatson: (Reference for the USE_LATEX frustration)
<cjwatson> maclin: I think you're making a mistake in trying to match Ubuntu here, and should revert whatever else you've done rather than changing ubiquity.
<cjwatson> Unless that's impossible at this point.
<maclin> cjwatson, yes, if it's true, we will change it back in default-settings. thanks:)
<cjwatson> maclin: Thanks.  Sorry, I think I may have reviewed another one of your changes and not noticed this; should have raised this earlier.
<xnox> cjwatson: maclin: next cycle I think i'll purge hard-coded names, and simply use gsettings (xfce-settings, etc) to figure out the default wallpaper and purge that duplication.
<maclin> xnox, +1, it's a great idea to identify the name out of ubiquity codes.
<mdeslaur> can I upload gnupg and gnupg2 security updates?
<cjwatson> mdeslaur: Yes
<mdeslaur> thanks cjwatson
<stgraber> I'm reviewing the rest of the queue but would be nice if someone could take that LXC upload
<slangasek> did someone review it that quickly, or was that an inadvertent autoaccept?
<stgraber> slangasek: can't have been auto-accept, it's in a package set and seeded on a bunch of images
<slangasek> stgraber: well, that's why I said "inadvertent" :-)
<Riddell> we can't get seem to work out a fix for qtwebkit-source on arm, since the current version also doesn't work on arm is it ok to force it?
<cjwatson> No, don't force it
<cjwatson> If the current version doesn't work and can't be made to work, perhaps it should be removed.  Does it have rdepends?
<cjwatson> ... a ton
<cjwatson> We can't release this way ...
<cjwatson> I wonder how the previous version got in
<cjwatson> Oh.  You forced it.  Don't do that
<Riddell> sorry
<cjwatson> Yeah, that was the thing I warned at the time would cause problems later.
<smartboyhw> Uh oh
<smartboyhw> Question: Should ~ubuntu-sru review requests go here or #ubuntu-devel?
<smartboyhw> The indication is not clear...
<cjwatson> Riddell: So I really think we need to fix this by release rather than continuing to ignore it; we can't ship out-of-date binaries.  What progress has been made?
<Riddell> cjwatson: shadeslayer had a fix disabling 3d stuff which I'm trying to look up, but he ran into another problem
<Riddell> building now with DEFINES+=WTF_USE_3D_GRAPHICS=0 on my pandaboard, let's see what result I get
<Riddell> result will probably be tomorrow
<happyaron> stgraber: why libchewing sync is rejected?
<Laney> it was me
<Laney> because there were two
<happyaron> ah
<Laney> oh no, someone rejected the new one
<Laney> ignore that
<happyaron> Laney: do I need to sync it again?
<Laney> you need to find out why it got rejected
<Laney> did you get an email?
<happyaron> no, no accept/reject
<Laney> Wouldn't be surprised if they are busted for syncs, sadly
<happyaron> what to do then?
<Laney> Wait for someone to own up
<stgraber> happyaron: I gave a reject reason when I rejected one of them. The diff is 1MB large, there are significant code change, a mile long changelog and at lease one new symbol added
<stgraber> happyaron: that's a bit much when we're past FeatureFreeze and that close to release
<Laney> I think the reject emails don't work for syncs
<stgraber> Laney: ah, that'd explain it
<Laney> https://bugs.launchpad.net/launchpad/+bug/830614
<ubot2`> Launchpad bug 830614 in Launchpad itself "Email not immediately sent for copied packages which end up in NEW" [Low,Triaged]
<cjwatson> Not certain that's the same thing
<cjwatson> (It might be, but would have to analyse)
<Laney> Can someone help to decide on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1234887 please?
<ubot2`> Launchpad bug 1234887 in network-manager (Ubuntu) "[FFE] Update NetworkManager to 0.9.8.4" [Wishlist,Confirmed]
<Laney> Lot of changes this late on but a lot of fixes
<doko> cjwatson, Laney: please could you approve gdb and elfutils (to fix arm64)
<jdstrand> hi!
<jdstrand> can someone review apparmor-easyprof-ubuntu? it is seeded in supported but only on touch
<jdstrand> two small fixes-- one for mir access and one for the upcoming kernel update
<stgraber> jdstrand: I'll take a look
<utlemming> question: how come the lastest kernel isn't making it to the CD Images?
<jdstrand> stgraber: thanks!
<utlemming> if you look at http://cdimage.ubuntu.com/ubuntu-server/daily/pending/saucy-server-amd64.list you'll see that the kernel is linux-generic_3.11.0.11.12_amd64.deb but the latest is linux-tools-3.11.0-11-generic
<stgraber> probably because either d-i or the seeds haven't been updated
<utlemming> stgraber: who usually handles the seed updates for that?
<stgraber> infinity
<utlemming> ah, thanks
<stgraber> utlemming: actually, I don't see anything wrong with that kernel version
<utlemming> stgraber: yeah, you're right, I was looking at the wrong package...I was waiting for .17, but it looks like .12 is getting served up
<stgraber> utlemming: current linux-image-generic is 3.11.0.11.12 and current linux-image-3.11.0-11-generic is 3.11.0-11.17
<stgraber> utlemming: the linux-image-generic one comes from the linux-meta source, the linux-image-x.y.z-* come from the linux source
<stgraber> so the first usually only changes when the ABI is bumped
<utlemming> stgraber: ack, okay that makes sense
<utlemming> stgraber: thanks for humoring my question
<jdstrand> stgraber: mind also taking a look at apparmor upload?
<jdstrand> stgraber: tyhicks has the details
 * jdstrand uploaded just a moment ago
<jdstrand> stgraber: my two things in the upload are simple policy updates. tyhicks has the details on the patches (and a couple other policy updates)
<tyhicks> jdstrand: I may also need you to chime in on 0072-lp1229393.patch, which is the patch to fix the cache location for the .features file
<jdstrand> that's fine
<jdstrand> tyhicks: but I didn't actually change the initscript or anything else, so it is really just your patch
<jdstrand> well, jj's patch, but yeah. I can comment
<tyhicks> ok
<jdstrand> I want to redo our policy load, but not for 13.10
<jdstrand> stgraber: not sure if you saw my ping re apparmor?
<jdstrand> stgraber: s/ping/request/
<jdstrand> stgraber: just in case you didn't: http://paste.ubuntu.com/6210598/
<jdstrand> meh, I chopped one off
<jdstrand> stgraber: http://paste.ubuntu.com/6210600/
<stgraber> jdstrand: I accepted it a couple of minutes ago
 * stgraber kicks queuebot
<jdstrand> stgraber: you accepted apparmor too? (not just apparmor-easyprof-ubuntu?)
<jdstrand> ah yes
<jdstrand> stgraber: thanks! :)
 * jdstrand hadn't gotten the email yet
<tyhicks> thanks!
<seb128> infinity, slangasek, bdmurray, sru team: could anyone review the libreoffice upload to precise that's waiting since august? it's a small diff with backported patches, not an updated version...
<Laney> re-ping about the NM bugfix upload ^^^
<Laney> I don't see that u* in the queue have any actual changes
<stgraber> 18:53 < stgraber> dobey: so is that waste of buildd time really necessary?
<stgraber> 18:54 < dobey> yes
<stgraber> I didn't get any better reason out of him, so I decided not to care and keep them in the queue for someone who cares more to deal with
<stgraber> (since my other alternative was a simple reject and I didn't feel like arguing for hours)
<Laney> sigh
<stgraber> infinity: around to look at that linux upload or shall I?
<Laney> maybe SRUers would be happy putting NM in that way to get it some extra testing
<infinity> stgraber: I am now, but it looks like you got to it. :P
<stgraber> infinity: yep, pretty small diff this time around
<tyhicks> Hello again - if someone could review evince, I'd appreciate it
<tyhicks> It is a small patch that only grants more permissions to the evince apparmor profiles
<tyhicks> most importantly, if grants access to the accessibility bus
<Laney> it already got accepted
<Laney> there's no need to ping right away :-)
<tyhicks> ah, thanks! :)
<cjwatson> ^- at the head of a build-dep chain on arm64 - can somebody have a look?
<infinity> Drat.  The aarch64 WIP port for elfutils not only doesn't quite work yet on arm64, it also breaks the x86 build.
<infinity> Now to decide how deeply I care about helping to fix that this week, or if I should just disable the failing tests on arm64 and scream "la la la, elfutils doesn't actually work with aarch64 binaries but I don't care, la la la".
<cjwatson> advantage of doing this kind of thing: I get to take touched-it-last on merges off people who were doing drive-by changes and clearly haven't cared for multiple releases
<cjwatson> disadvantage: I'll have to do those merges next cycle ;-)
<infinity> cjwatson: You already had TIL on opemipmi. :P
<cjwatson> I meant my next one
<infinity> ... twice.
<cjwatson> How's the graphviz cycle-breaking going?
<infinity> Sleep got in the way.  It's first on my list today.
<infinity> Well, it was second on my list after elfutils, but that's a black hole of doom I'll revisit after I've had a drink and found my Ballmer Peak.
<lool> can someone please reject ubuntu-touch-session-0.77 when it comes up?
<lool> I uploaded with a .orig + .diff but it's native
<infinity> lool: If it's native, where did you find an orig? :P
<lool> infinity: bzr bd was too smart
<lool> infinity: ^
<lool> quick before the * cron!
<infinity> Rejected.
<lool> thanks!
<infinity> Gah.
<infinity> No.
<infinity> The bot beat me.
<lool> I'm disappointed
<cjwatson> Upload a 0.78.
<lool> yeah
<lool> reuploaded after fixing bzr bd config in trunk to native = True
<cjwatson> infinity: libquvi's for arm64
#ubuntu-release 2013-10-09
<lool> Not clear to me why upstart-app-launch is listed here
<lool> would someone be able to review?
<lool> I mean, I'm surprized it's help up
<lool> ah via liburl-dispatcher1
<lool> via a Suggests?!
<lool> gah
<cjwatson> click is in Ubuntu desktop supported too
<cjwatson> Suggests are ignored
<lool> ah right click
<pitti> ^ for the upower sync, in the queue it's quite hard to review
<pitti> we currently have a git snapshot, and the effective delta is just two commits plus some test suite updates
<pitti> http://cgit.freedesktop.org/upower/commit/?id=db89e5a3
<pitti> http://cgit.freedesktop.org/upower/commit/?id=ecc4e37
<pitti> and we really really need those two fixes, they break a lot in GNOME
<pitti> (that is, the bug that they fix :) )
<pitti> oh, and http://cgit.freedesktop.org/upower/commit/?id=03c4ab
<pitti> cheers :)
<infinity> slangasek: ^-- If you're still around, care to give a once-over to those?  New upstream version, but only a handful of bugfixes.  The git log is only a few commits.
<dholbach> hiya, can somebody please take a look at bug 1235737? seems like another bug (already approved) in the sponsoring queue depends on it
<ubot2`> Launchpad bug 1235737 in postbooks (Ubuntu) "FFe: Sync postbooks 4.1.0-2 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1235737
<infinity> cjwatson: Since you're awake now, want to poke at those gdb/gdb-doc uploads?  bugfix-only, and rather minimal.
<cjwatson> infinity: Was just starting on them, indeed
<infinity> cjwatson: Sorry about the lazy copy/paste changelog from upstream, but, well.  Lazy.  I did test it, though. :P
<cjwatson> Yeah, no problem
<Laney> dholbach: sync away
<Laney> I'll subscribe u-sponsors to some other ones
<Laney> there's a little stack of postbooks things
<dholbach> thanks Laney
<ogra_> infinity, hmm, these touch kernels went through completely untested
<infinity> ogra_: Who was meant to test them and how?
<apw> ogra_, they weren't untested, all of yesterday was spent testing them
<ogra_> (they were not supposed to be uploaded yet)
<ogra_> apw, well, touch images have no landings without the landing team nodding it off
<ogra_> infinity, i was supposed to test them with the autopilot tests before they get uploaded
<apw> the rest of the bits of the landing landed already yesterday
<ogra_> apw, which AP tests did you run ? do you have a test matrix or something, did all tests pass ?
<apw> ogra_, not me
<apw> ogra_, i waas more pointing out the process is opaque and confusing to those of us using it
<ogra_> the ychanges touch click package behavior, apps might misbehave
<apw> they are presumably stuck in -proposed anyhow by your britney block
<ogra_> they just went into the archive
<ogra_> there is no britney lock for universe packages
<cjwatson> apw: It would if the touch landing team bothered to use the facilities I'd set up for them in any breadth
<infinity> ogra_: Touch people have the power to block their packages.
<ogra_> infinity, which doesnt help us, since android (which consumes the kernel) builds from proposed
<infinity> ogra_: Anyhow, if you're deeply concerned, test away.   But these changes went into the master kernel yesterday, and the userspace side is all landed.
<ogra_> infinity,  point is that per policy they would have gone through the spreadsheet stuff, which they didnt, without approval on that sheet nothing has to be uploaded
<cjwatson> Point is that you lose.
<cjwatson> I mean, it's inevitable with this process.
<cjwatson> Or lack thereof.
<ogra_> well we'll change the process to something more sane after release
<cjwatson> Pre-upload gating while choosing not to use the technical means available is infeasible.
<infinity> ogra_: I've uploaded a lot of stuff that's on touch images without the spreadsheet.  Why didn't you yell at me for glibc? :P
<ogra_> cjwatson, the technical means available will be used after release, i want that as much as you ... but currently all uploads are held for the Mir switch on touch ... if we need to fix a bug on the android side for this we cant rebuild it without pulling in the kernels now
<ogra_> infinity, i'm not yelling
<cjwatson> Well I don't know what you propose to do about it now.
<cjwatson> (And I will say: the arm64 porting work is not going to stop for this.)
<ogra_> nothing just pointing it out so it doesnt happen again
<cjwatson> (I know that's not about the kernel, but it is about other uploads.)
<infinity> ogra_: This was a change that was wanted.  The userspace side landed.  The kernel needed to.  The idea of gating things one upload per image is insane.  Full stop.
<infinity> ogra_: But dropping process arguments, the kernels are in.  Oh well.
<ogra_> infinity, discuss that with asac and lool  ... i'm just pointing out something so it doesnt happen again
<xnox> ogra_: security uploads trumps anything.
<cjwatson> It's likely to happen again.
<infinity> And again, and again.
<xnox> ogra_: and it was security upload.
<cjwatson> doko_: Curious.  No dh_autotools-dev_{update,restore}config in libsigc++-2.0?
<ogra_> xnox, ??
<cjwatson> doko_: And no clean handling
<ogra_> xnox, i'm talking about the fout touch kernels that were uploaded to saucy
<ogra_> *four
<xnox> ogra_: so do I.
<doko_> cjwatson, clean handling is there
<ogra_> and they were supposed to be held back
<doko_> using the existing one
<ogra_> until after Mir landed
<cjwatson> doko_: Oh, right, generic code
<doko_> cjwatson, didn't want to interfer with the manual autoreconf in this package
<lool> cjwatson: Problem here is that the kernels get copied into android; so we couldn't upload android anymore as soon as the kernels were uploaded to proposed (hints dont help this case)
<xnox> ogra_: have you seen the bug they are fixing together with the matching apparmor uploads? (ps it's 6 kernels, goldfish and normal as well)  see bug #1208988
<ubot2`> Launchpad bug 1208988 in AppArmor "AppArmor no longer mediates access to path-based AF_UNIX socket files" [High,Triaged] https://launchpad.net/bugs/1208988
<cjwatson> Also: if these were supposed to be held back, why did nobody tell the release team?
<lool> so completely not related to hints
<infinity> lool: Or, you could upload android and get the new kernels.  This is bad, why?
<ogra_> xnox, no, and thats not what this is about ...
<cjwatson> You can't not communicate about specific things that were supposed to be held back and then expect that to happen.
<lool> infinity: I might have to upload android and not want the new kernels
<cjwatson> Since pre-upload gating is infeasible.
<lool> infinity: but I can't technically stop that
<lool> and we had agreed to coordinate the uploads later today
<lool> but well
<lool> I guess there was a hiccup in this part
<ogra_> cjwatson, i just did ... for the next time :)
<infinity> lool: I understand that you might want that, I don't understand WHY you want that.  This apparmor change is, AFAIK, necessary.
<lool> cjwatson: I didn't expect anything to be held back
<infinity> lool: It's bizarre to slow yourself down by only testing one tiny thing at a time.
<xnox> ogra_: lool: apparmor changes went in (security bug) and if kernels didn't go in, your userspace and containment would be borked. Taking one without the other, means borked images.
<lool> infinity: it is, but there are other changes (ureadahead for instance) in the kernels, the toolchain changed, we need to test the kernels and we might have to land android to fix tests before we take new kernels
<lool> xnox: No, we actually confirmed they could go in in this order
<lool> xnox: and separately
<xnox> ogra_: lool: and android package makes it's own sources where it downloads the kernels from, so you can easily change it to pull kernels from -release pocket if you wish to do so. And then hints would gate keep it.
<lool> xnox: yeah, I can workaround this specific case
<infinity> lool: Erm, the ureadahead commit already existed in 2/4 kernels.  You intentionally want them to behave differently?
<infinity> lool: And that's literally the only change other than the apparmor stuff.
<lool> infinity: and being rebuilt
<xnox> ogra_: lool: but multiple times, i've been requested to pull from -proposed to speed up image respins with updates (e.g. hybris, initramfs-tool-ubuntu-touch, etc)
<lool> it's not like toolchains broke kernels in the past  :-)
<lool> xnox, infinity, cjwatson: I am personally fine with what just happened
<lool> I would like us to use hints more next cycle
<infinity> Then why are we talking about it?
<lool> they wouldn't help in this case
<xnox> lool: touch kernels are build with toolchain that doesn't change any more (4.6 and 4.7)
<lool> infinity: exactly  :-)
<apw> right the toolchain changes do not affect these kernels at all, because the kernle doens't work if you compile it with those; which of course is an epic recommendation for the compiler you are building the rest of the stuff with
<xnox> apw: =)))))
<lool> also, I think we actually copied the kernel binaries
<lool> which got tested
<lool> apw: do you know if cking tested on Mir too?
<infinity> I did copy with binaries, yes.
<cking> lool, I tested with Mir enabled on maguro + manta
<lool> cking: awesome
<lool> infinity: great
 * seb128 scratches head
<seb128> why did I receive an "[ubuntu/saucy] gtk+3.0 3.8.4-0ubuntu3 (Accepted)" email this night when that version as already in saucy for a while
<seb128> e.g https://launchpad.net/ubuntu/+source/gtk+3.0/+publishinghistory
<cjwatson> seb128: Probably arm64 port -> new copy
<cjwatson> Known to produce somewhat confusing mails when proposed-migration copies the new binary into the release pocket
<xnox> cjwatson: maybe it's useful to send an email to ubuntu-devel about the emails? cause pretty much every uploader of everything that gets build on the new port will receive these confusing emails?
<cjwatson> Actually no that's not true
<cjwatson> The bulk of builds are happening in the release pocket (because reasons)
<cjwatson> The only cases where you get confusing mails are uploads to -proposed after the port was initialised
 * xnox has been getting a lot of emails already and FTBFS emails as well, wrt arm64.
<cjwatson> Yeah, I realise that but that's tied up with details of hardware and I'm not sure what I can say publicly on that
<lool> did you just say arm64?
<cjwatson> I don't want to accidentally slag off a partner on a public mailing list. :-P
<xnox> ok.
<seb128> cjwatson, ok, thanks
<cjwatson> (And hopefully the major cause of odd build failures will be fixed soonish ...)
<cjwatson> lool: Yeah. :-)
<lool> hud in unapproved has notably a workaround for when upstart mis-sets the dbus env vars in user sessions (this is apparently an upstart bug with set-env -g that we're still looking into); hud crashing is causing lots of test failure noise on touch, so greatly appreciated if we can land this  :-)
<lool> there's a complex hud change coming up in the next hours/days to address deeper problems with it, but this one should help quite a bit already
<Laney> Is a binary-only promotion still OK to do?
<cjwatson> Should be
<Laney> I want to make sessioninstaller dep on python-commandnotfound for bug #1102434
<ubot2`> Launchpad bug 1102434 in gnome-control-center (Ubuntu) ""System settings -> Colour", fails due to missing "gnome-color-manager" package." [Low,Triaged] https://launchpad.net/bugs/1102434
<Laney> ta
<seb128> Laney, did you get the apturl fix tested/uploaded?
<cjwatson> No Python 3? :-(
<Laney> seb128: yeah
<seb128> Laney, great ;-)
<Laney> cjwatson: apparently not
<apw> the linux and linux-signed uploads are to fix the arm64 linux-libc-dev (and other cross environments) builds
<Laney> lool: where is the workaround?
<xnox> Laney: in user-session's init hud.conf.in
<Laney> xnox: Maybe I have the wrong diff
<lool> Laney: the hud thing?
<lool> Laney: in unapproved
<Laney> I don't believe that change is in the upload
<xnox> lool: Laney: well, we want http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/revision/326 which doesn't seem to be included in the unapproved upload.
<xnox> (sync)
<lool> Laney: checking
<Laney> queue -Q unapproved -s saucy-proposed fetch hud
<lool> Laney: you're right, it's not there
<Laney> :-)
<Laney> want to re-upload?
<lool> Laney: yes
 * Laney rejects
<lool> need to figure out by cu2d didn't pick up though
<lool> Laney: thanks
<jdstrand> xnox: fyi, regarding borked images because userspace was updated but the kernels weren't-- that actually wasn't the case this time. the userspace could go in before or at the same time. it was just the kernels couldn't go in before
<jdstrand> ah, I see someone mentioned that already
<xnox> jdstrand: right the argument was that whilst apparmor can have block and not migrate to release pocket, android package is built with pulling kernels from -proposed (avoiding all blocks)
<xnox> jdstrand: thus when everything is in -proposed, one had to take apparmor or otherwise be stuck with updated kernel & out of date apparmor.
<jdstrand> sure. I am not going to participate in that conversation except to say that while I understand the desire and utility to gate the touch images, the process needs improvement and I'm glad that it is on the agenda for the next sprint
<ogra_> xnox, that hud fix will not have your filtering i guess ... can we have that too ?
<xnox> jdstrand: ack.
<xnox> ogra_: upstart upload?
<ogra_> xnox, for the dbus bridge filtering
<ogra_> wasnt that upstart ?
<xnox> ogra_: there was no dbus bridge filtering, i had a patch for upstart-udev-bridge to drop that one event and not generate any upstart events for it. is that what you mean?
 * ogra_ checks the bug again
<ogra_> xnox, oh, righ t
<ogra_> thats what i mean
<xnox> ogra_: ok. jodh doesn't want it upstream, but it can be uploaded into the ubuntu package.
<ogra_> i think that would make sense
<ogra_> (so would having the udev side fixed too i guess)
<xnox> ogra_: it is unknown if mir needs the udev event or not.
<xnox> ogra_: as far as I understood yesterday's discussions.
<xnox> ogra_: but i guess that can be tested.
<ogra_> yeah :)
<xnox> ogra_: since kernel was changed to emit them....
<ogra_> well, it is only emitted on maguro
<ogra_> mako runs without it
<ogra_> so i dont think we need it outside of the kernel
<xnox> ogra_: yes, but propbably maguro's binary blobs want it.
<ogra_> right
<lool> Laney: ^
<xnox> ogra_: if you want about upstart upload, please make it go through all the right processes.
<xnox> ogra_: as you wish =)
<zul> can i get a release team meber to ack https://bugs.launchpad.net/ubuntu/+source/python-cinderclient/+bug/1236901
<ubot2`> Launchpad bug 1236901 in python-cinderclient (Ubuntu) "FFE for python-cinderclient 1.0.6" [High,New]
<lool> Laney: Still around for the hud thing?  :-)
<Laney> lool: back now, was lunching
<Laney> that workaround :(
<ogra_> Laney, well, look at the original start process of thge HUD
<ogra_> Laney, it fits well :P
<Laney> I like my eyes unbled :P
<seb128> Laney, did you accept it?
<Laney> ya
<seb128> that seems buggy
<seb128> http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz
<ogra_> (a dbus service, that calls a shellscript (with -hack- in its name actually) to trigger upstart to start an upsart job
<ogra_> )
<seb128> what is that apport hack
<seb128> it's not even documented in the changelog
<seb128> the printf line
<seb128> (dropping the author as well seems weird)
<Laney> I divined that they want to report when this situation happens
<Laney> "and reporting a bug"
<ogra_> looks like debug logging
<seb128> that should be documented in the changelog...
<seb128> shrug
<ogra_> well, pete-woods is in -touch
<seb128> it's coming from ted
<seb128> http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz
<ogra_> i think they cross review their MPS
<seb128> oh well, hacks on hacks
<ogra_> *MPs
 * seb128 uninstall huds
<ogra_> yeah
<Laney> I thought about arguing that they should be using normal dbus activation instead of this weird stuff
<Laney> but then I decided to stay away from the battlefield
<ogra_> http://paste.ubuntu.com/6213176/
<ogra_> thats the current hud startup process
<ogra_> so the patch fits in well :P
<ogra_> its all about keeping the style right :)
<seb128> hehe
<xnox> ogra_: well at least i patched it to use "sh" instead of "bash" =/
<ogra_> heh yeah
<ogra_> that will buy us precious bootspeed
<ogra_> every nanosecond counts
 * ogra_ would like ot get back under 30sec
<jodh> ogra_, jibel: could you try https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/44 ?
<ubot2`> Launchpad bug 1235649 in upstart (Ubuntu Saucy) "uevent spam causes session upstart to consume massive amounts of memory on Ubuntu Touch" [Critical,Confirmed]
<ogra_> jodh, yes (see #ubuntu-touch) will do soon
<jodh> ogra_: thanks
<ogra_> jodh, i fear it wont help on maguro with the uevent spam though
<jodh> ogra_: right. There are a few problems going on here :)
<ogra_> yeah
<ogra_> well xnox fix works pretty well
<ogra_> apart from the fact that udevd consumes a bit more CPU afterwards
<jibel> jodh, what do I need to do? patch Panel.qml and Shell.qml and verify if I can reproduce?
<ogra_> jibel, yeah, see if the session init ram consumption raises still ... on mako
<jibel> ogra_, okay, doing that now
<Laney> Probably â #-touch :-)
<Laney> stgraber: queuebot went away
<ogra_> having lunch too :)
<doko> please could somebody review python3.3 and openjdk-7 ? just needed for the aarch64 bootstrap
<cjwatson> python3.3 accepted, waiting for diff for openjdk-7
<cjwatson> oh, it's there
<cjwatson> really must apiify diffs
 * ogra_ hugs xnox 
<ogra_> YAY !!!!
<xnox> ogra_: can I have MIR on grouper please? =)
<ogra_> xnox, so be it ...
<ogra_> xnox, upgrade to 89
<ogra_> ;)
<xnox> ogra_: i do system image, is 89 published in devel-proposed channel? or which channel do I want?
<ogra_> saucy-proposed, yeah
<ogra_> (or devel-proposed)
<rsalveti> ricmm_: ^ once it gets approved
<ricmm_> rsalveti: great
<lool> (would be nice to get the libhybris upload reviewed; just adds a header)
<stgraber> queued cleaned up
<seb128> stgraber, thanks!
<Laney> excellent
<Laney> I loaded the ubuntukylin-default-settings diff and had to go off to mop up my tears
<stgraber> ;)
<Laney> not the change itself, but the context in the diff
<Laney> cp /some/logo /the/ubuntu/logo/in/g-c-c
 * seb128 pokes Laney in the eyes
<seb128> or maybe not
<Laney> then I get to have it read to me by a screen reader
<Laney> that seems worse :(
<seb128> Laney, yeah, sorry about that :/
<stgraber> right, I accepted the change because it wasn't making things any worse, actually it made things slightly better, but the context looked pretty scary indeed
<Laney> indeed
<seb128> but yeah, the kylin setting has quite some hacks
<ypwong> Hi all, at what time will saucy be frozen?
<happyaron> and this wallpaper package needs approval, for ubiquity to recognize the new wallpaper
<happyaron> I think cjwatson did not modified the settings in ubiquity so a link must be created for it here.
<ypwong> well, I meant about what time the final freeze will be in effect
<happyaron> Laney: well, yes, I tried to revert as many changes as possible in previous upload, if you looked at that version, you'll be scared even more...
<Laney> thanks for your efforts :-)
<Laney> ypwong: usually 2100 UTC
<ypwong> Laney, thx
<happyaron> oh, gosh, I need to upload another version of -default-settings, it ftbfs...
<ypwong> happyaron, the patch in the bug doesn't work?
<happyaron> it works, but removing the unity.mo make it fail
<happyaron> sorry everyone I'm in a big rush cuz I'll have no network in 2min...
<dobey> is there any way to tell who accepted a particular upload to saucy?
<slangasek> dobey: no
<slangasek> this causes great consternation for the team
<dobey> :(
<dobey> slangasek: can i convince you to accept the 3 uploads of mine that you rejected last night?
<slangasek> dobey: well, you can try, but I don't see why I would be persuaded that we should do no-change rebuilds of packages just to get 13.10 as the version number
<dobey> slangasek: because we want to have versioning consistency across the ubuntuone projects/packages. we have been doing this for several cycles now.
<slangasek> with freeze exceptions?
<dobey> freeze exceptions?
<slangasek> we're in post-beta freeze
<slangasek> and the RC is tomorrow
<slangasek> and package version number consistency is very low on my list of priorities
<dobey> well, the other 6 packages i uploaded were accepted without problem, with only a version number bump.
<stgraber> haha, looks like we've got a conflict here :)
<stgraber> I'll reject them both and re-upload one with both changes
<slangasek> dobey: right, I guess that's why you want to know who accepted a particular package?  But I presume those other packages were uploaded earlier
<slangasek> I guess if you can figure out who did the other accepts and talk them into un-rejected, I won't stand in your way
<stgraber> those were accepted by me as they weren't really causing any harm and there weren't too many of them, I then changed my mind after mentioning the problem to dobey so I'm not going to accept any more of those
<stgraber> (I wasn't the one who rejected the rest though)
<dobey> no slangasek rejected them
 * slangasek nods
<dobey> i don't see why it is a "problem"
<stgraber> you're wasting review time, buildd resources and libraring space for nothing
<dobey> i didn't even know they had to be reviewed until after i uploaded stuff and was getting "waiting for review" messages. final freeze isn't until tomorrow
<stgraber> we've been freezing the archive between the final beta and release for the past 2-3 cycles now
<dobey> and i wouldn't really call a very short build time on an emtpy build queue a "waste of resources"
<stgraber> I uploaded that lxc so would be nice if someone else could review it in the queue
<jdstrand> can someone look at apparmor-easyprof-ubuntu real quick? it is required for (at least) grouper with mir
<shadeslayer> could someone also approve user-manager ( has a bug fix that allows setting the user avatar ) and soprano ( fixes a bug when the db gets corrupted and causes problems in nepomuk )
<shadeslayer> ScottK doesn't seem to be around
<stgraber> shadeslayer: looks like you're adding/changing strings in there...
<shadeslayer> stgraber: which package?
<doko> whoever did accept exempi, thanks and please accept exiv2 too
<stgraber> shadeslayer: user-manager
<shadeslayer> stgraber: okay
<shadeslayer> stgraber: can we get it in either way? because apparently Riddell asked for some UI modifications which resulted in string changes
<shadeslayer> stgraber: we just didn't upload the updated git snapshot
<stgraber> shadeslayer: if you get a UIFe, then sure (you usually need whoever works on your documentation and translations to ack the change for that)
<shadeslayer> okay
<slangasek> stgraber: lxc, there are no linked bugs for either of the changes; verbose++ please?
<slangasek> stgraber: 0011-ubuntu-cloud-prep-hook-fix-debug-helper-to-not-inapp.patch at least is self-explanatory from the shell, but the apparmor change I feel I need context for
<stgraber> slangasek: bug 1237543 is for that cherry-picked patch (the bug was filed after hallyn fixed it upstream and in the package, that's why we don't have a LP:#xxxxx in there)
<ubot2> Launchpad bug 1237543 in lxc (Ubuntu) "lxc-create (or clone) of cloud template with '--cloud' exits failure" [Low,In progress] https://launchpad.net/bugs/1237543
<stgraber> slangasek: the other one was reported by vila on IRC. Basically the new apparmor blocks dbus by default.
<stgraber> slangasek: so a standard saucy container would be unable to use dbus with our current profile.
<zul> can someone look at python-cinderclient FFE please (#1236901)
<stgraber> slangasek: fixing that needs adding "dbus," to our default profile, but we can't just do it unconditionaly since the same source package is backported to all releases down to precise
<stgraber> slangasek: and any release < saucy will fail to parse an apparmor profile containing "dbus"
<slangasek> stgraber: ok.  So I'm generally pretty opposed to applying per-version hacks in debian/rules instead of just expressing those differences in different per-release VCS branches in the natural way.  Is there a reason that couldn't be done here, even though it's a backport?
<stgraber> slangasek: I'd rather avoid having to update 8 packaging branches and having to change all our automatic build scripts to know which branch to pick up when pushing new builds...
<slangasek> sure; whereas I'd rather avoid having debian/rules doing magic like applying dpkg --compare-versions to lsb_release ;)
<stgraber> (we support precise, quantal, raring, saucy in both upstream-daily and ubuntu form, so I alrady have to sync between two branches every time we change something, having to maintain per-series would be a bit of a pain)
<slangasek> in practice this delta would only require two extra branches (saucy vs. pre-saucy) if you wanted to do it that way
<slangasek> and effectively it would be safe to auto-merge
<slangasek> (except when it wasn't safe, which would probably be a clue to look at it :)
<stgraber> yeah but that'd still prevent us from using requestbackport since the automated backporting tools just take from a release and automatically spit out an updated source package ready for upload
<slangasek> there were provisions for sourceful backports, I thought.  requestbackport doesn't handle that workflow?
<stgraber> requestbackport takes a source series, a destination series and a source package
<stgraber> *source package name
<slangasek> yah
<slangasek> so I'll allow this, because my objections don't really have anything to do with the release freeze
<slangasek> but at minimum, I would recommend that you invert the debian/rules handling, to make the backports the special case so that 'dbus' is part of the actual source
<slangasek> (not for saucy, but for the future)
<stgraber> slangasek: well, my plan for the future is to move the apparmor profiles upstream and have it be a .in file
<slangasek> ok
<stgraber> since we already detect most distros in our configure.ac and I believe also export the distro version as a variable
<slangasek> anyway, the point I want to express is that I don't think it's a good idea for part of the "source" of the package to be hidden in debian/rules
<slangasek> and now I'll get off my soapbox :)
<stgraber> slangasek: oh I agree and I was pretty annoyed by it when I got the report today as none of the apparmor abstractions would give me something that worked on all the releases I care about... so I basically ended up with 3 choices 1) hackish debian/rules 2) separate source package for backports 3) only support session+system bus and block accessibilty bus
<stgraber> 2) meant quite a bit of time to invest in the coming years, 3) meant breaking the desktop QA test environment at least and 1) was just ugly, so ugly it ended up being :)
<jjohansen> stgraber: you supposed to pitch a fit at us and tell us how much this sucks so we are motivated to fix it
<jjohansen> stgraber: truth is this is bad, and something we need to fix, but I don't have a good solution atm
<stgraber> jjohansen: oh, I certainly wanted to blame you ;) but short of having the parser accept any invalid keyword, I'm not sure what you could have done differently.
<stgraber> block by default is always how apparmor worked, so that makes sense and the dbus keyword was only introduced this cycle, so any older parser will fail... I guess if we had a all-dbus abstraction around since precise that would have been mapped to "dbus," in saucy, then I could have used that, but you'd have had to be pretty good at predicting the future a couple years ago to do that ;)
 * mdeslaur hands jjohansen a crystal ball
<stgraber> well, actually there was a 4th alternative in my list above, backport apparmor to all releases where we backport lxc, but I figured this would probably cause even more problems ;)
<jjohansen> stgraber: well 2 things
<jjohansen> 1. the parser should be setting some conditional variables, then at the very least you could have wrapped the rule in if $COND_X in the policy  (this should have been done a long time ago)
<jjohansen> 2. there are plans to extent the parser so you can tell it how to parse new rules as part of policy, and a little rule to ignore dbus could have been done that way.
<jjohansen> Of course either of those mean backporting the changes
<jjohansen> mdeslaur: well its a problem we have known about for years
<jjohansen> stgraber: yeah, backports are a pita
<mdeslaur> jjohansen: yeah
<stgraber> jjohansen: ah, those two sound pretty nice, can we have that for 14.04? :)
<jdstrand> I'll answer that with 'unlikely'
<jjohansen> hehe
<stgraber> ok :)
<jdstrand> stgraber: we have a pretty big pile of stuff for 14.04 which includes lxc
<jjohansen> stgraber: well if you can find us some resources to work on it ... :)
<stgraber> anyway, on my personal apparmor priority list, stacking is way more important than that stuff for 14.04
<jdstrand> stgraber: *perhaps* 14.10 would get something like that, we'll see
<jjohansen> stgraber: you would say that :)
<jdstrand> stgraber: yeah-- stacking is coming and planned. I know we've been saying that for a while, but a lot of work was done for that already and we hope to deliver it in 14.04
<jdstrand> at least something quite a bit better than what we have now
<slangasek> stgraber: done differently> they could also have backported support for the 'dbus' keyword to older releases
<slangasek> even if it was a no-op
<stgraber> oh, apparently I'm TIL on irssi, I didn't know that (just got a build failure for arm64)
<infinity> Yeah, I've been discovering all sorts of things I forgot I was TIL on. :)
<infinity> doko: Erk, why are up updating config.{sub,guess} in patches?
<infinity> doko: That's just a recipe for failure next time.
<infinity> doko: Something like http://launchpadlibrarian.net/152821294/bind9_1%3A9.9.3.dfsg.P2-4_1%3A9.9.3.dfsg.P2-4ubuntu1.diff.gz is much saner, and doesn't lead to a painful-to-rebase patch.
<stgraber> I saw a few done with dh-autoreconf though I didn't check if there was a pattern there (!doko => dh-autoreconf, doko => massive ugly patch)
<doko> infinity, well, for two or three packages, I tried to introduce autoreconf, and it did fail
<slangasek> infinity, stgraber: you're both slackers, you should be more like me and make sure everything you touch gets in sync with Debian so that you can stop being TIL ;)
<doko> so I assume at this stage the patch is the safest way not interfer with a build system
<infinity> doko: Hence my pointing at the above that uses autotools-dev, not autoreconf.
<infinity> doko: (--with autotools-dev, if it's dh(1), or as above, if it's old-style)
<stgraber> slangasek: I'm TIL because I fixed a utf-8 related bug a while back, that got merged upstream so I've been doing standard Debian merges since as we patch irssi to suggest irc.ubuntu.com apparently...
<slangasek> stgraber: right :)
<doko> infinity, and this does work when files are in subdirs?
<infinity> doko: Yup, it finds all copies.
<doko> and figures out the right -I m4 flags?
<doko> I give it a try for the next package
<infinity> Err, what now?  It literally just replaces config.sub and config.guess.
<slangasek> stgraber: also, is 91_ssl_proxy.patch still in our delta? :)
<slangasek> ah, no apparently that's upstreamed in Debian \o/
<roaksoax> All. So we are looking to upload a new maas release that contains various fixes and improvements to the previous FFe upload we made. We have discovered a couple of regressions that we are currently working on fixing. So we are looking into doing the upload tonight if things go as expected
<infinity> doko: It's not a reconf (autoreconf is for that), it just updates config.{sub,guess}, but reliably, and at build-time.
<doko> ok, then let me redo irssi
<roaksoax> for which we might require delaying the release candidate remastering
<stgraber> slangasek: not according to my merge changelog at least
<slangasek> stgraber: yeah, so evidently my patch is not part of the delta, at least :-)
<doko> infinity, irssi & jigit
<TheDrums> tyhicks: Thanks for taking a look at the dbus bug, and for the quick fix.
<cjwatson> stgraber: Generally I use dh_autoreconf when the existing build system looks fairly recent and I've test-built to make sure it's safe and does the job, and dh_autotools-dev_* otherwise
<cjwatson> stgraber: And I brutalise all my own packages until dh_autoreconf is safe and does the job :-)
<infinity> cjwatson: "... and does the job" being a key point, as autoreconf seems to miss on updating config.* in some cases.
<cjwatson> infinity: Yes.  Fortunately I understand when and know how to deal with it.
<cjwatson> infinity: It's not a problem for packages that use automake as well as autoconf.
<infinity> Would be nice if it just used the same logic as dh_autotools-dev with the find-and-replace-all-copies thing.
<cjwatson> Yeah, it wouldn't hurt; though I sort of feel autoreconf itself should do that
<infinity> (If autogen/etc then goes and replaces again, it's not a big deal, as you just restore backups in clean, and life is good)
<cjwatson> Feels wrong for a high-level wrapper to be doing it
<infinity> Sure, auto* should get it right, but it doesn't always seem to.  The higher level wrapper papering over that wouldn't be bad, IMO.
<cjwatson> The reason it currently gets it wrong is that it basically just calls a sequence of lower-level tools, and the ones that update config.{guess,sub} are automake and libtoolize.
<slangasek> if someone would do me the honor of reviewing glm in the queue, that's a fix needed to unbreak cross-installability of unity8 build-deps
<cjwatson> autoconf on its own doesn't.
<infinity> cjwatson: Right.  Well, contrary to (documented) protests to the contrary, mixing dh_autoreconf and dh_autotools-dev works, if you get the sequence order right, but it's icky.  And would be nice if it was smart enough to just integrate one into the other to always get it right implicitly.
<cjwatson> I still prefer my recipe for it, since I know exactly how it interacts :-)
<cjwatson> (Would be nice if it worked OOTB, sure)
<stgraber> cjwatson: any known problem with autopkgtest?
<cjwatson> stgraber: first I've heard of it, but I've been out for a few hours
<stgraber> cjwatson: lxc was accepted over an hour ago, britney says it's waiting on autopkgtest but I don't see any test scheduled on Jenkins
<stgraber> http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ shows ubuntu9 and no ubuntu10
<cjwatson> The running one at the top is 10, I think
<stgraber> the one that showed up 10s ago, yep, looks like it ;)
<stgraber> guess I wasn't patient enough
<cjwatson> Maybe the first request got lost for some reason, not sure
<cjwatson> I think generally the next p-m cycle will re-request if that happens
<slangasek> cjwatson: so bug #1208800 was an MIR for click, which was accepted by jdstrand; it seems that this is the only reason click (and various dependencies that are still being iterated) are in the 'supported' seed, which has caused a couple of those to be caught in the queue that shouldn't have been.  Can we just drop this from supported and put in it the touch seed where it belongs instead (for now)?
<ubot2> Launchpad bug 1208800 in click (Ubuntu) "[MIR] click" [Undecided,Fix released] https://launchpad.net/bugs/1208800
<slangasek> click isn't any more or less "supported" than the rest of the phone image, AFAICS
<cjwatson> slangasek: It's in desktop because I expect people to install it there for development
<cjwatson> or in supported, whatever
<slangasek> but then wouldn't we want that pulled via the sdk package?
<slangasek> which is also not seeded
<cjwatson> well, I expect click to be used other than via the sdk
<cjwatson> and indeed there's the problem that that's not seeded
<cjwatson> can we just leave it as it is for now?  it's not all that big a problem
<slangasek> my point is that the current seeding is adding friction where I think it shouldn't
<cjwatson> we could make an exception for it in auto-accept rather than having to move it around in the archive
<slangasek> because the apparmor stack is (was?) still being worked on
<cjwatson> AIUI that's quite practical
<slangasek> for click-and-all-its-transitive-deps
<slangasek> ?
<cjwatson> it doesn't have *that* many
<cjwatson> half a dozen or so I think
<slangasek> ok
<slangasek> if you and stgraber can sort that out, then that's the thing I really care about
<slangasek> it just seemed inconsistent to me to have it directly seeded
<slangasek> so I thought that might've been the easier solution :)
<cjwatson> it just seems like a retrograde step to move it back
<slangasek> stgraber: could you please whitelist click and its dependencies (as indicated by cjwatson) for queue auto-accept?
<cjwatson> aha, new is now occasionally involving five binaries :)
<slangasek> whee
<stgraber> slangasek: I added a whitelist and whitelisted click, click-apparmor and ubuntu-system-settings
<jdstrand> stgraber: can you also whitelist apparmor-easyprof-ubuntu?
<jdstrand> stgraber: python3-apparmor-click (from click-apparmor) pulls it in
<stgraber> slangasek: I didn't whitelist any of their dependencies because it's not impossible that those may get seeded or put in the packageset for other reasons (if we noticed one that gets frequent update, I'm fine with individual whitelisting)
<stgraber> jdstrand: ok
<stgraber> done
<jdstrand> thanks
<cjwatson> stgraber: upstart-app-launch was the other one in my list
<jdstrand> stgraber: you just whitelist sources or binaries, or both?
<stgraber> jdstrand: source
<cjwatson> stgraber: ubuntu-system-settings was only in touch to begin with, at least according to seeded-in-ubuntu
<jdstrand> ok
<slangasek> cjwatson: yeah, I think ubuntu-system-settings was the one you fixed the lubuntu supported seed for earlier
<stgraber> cjwatson: ah, good, will unwhitelist it then. It used to get stuck in the queue because of lubuntu supported
<cjwatson> slangasek: right
<jdstrand> url-dispatcher may be another candidate
<cjwatson> stgraber: yeah, that was an obscure seed bug
<slangasek> stgraber: and yeah, upstart-app-launch was the other one I knew about - thanks
<cjwatson> jdstrand: no, that's in Ubuntu daily-live images
<cjwatson> I haven't checked why, but it's more deeply embedded than other things listed
<slangasek> cjwatson: it's in universe?
<stgraber> ok, updated. Any other I'll just add as I waive them through the queue during review
<slangasek> I mean, I see the same thing from seeded-in-ubuntu, but I'm confused by what it shows
<cjwatson> liburl-dispatcher1 | 0.1+13.10.20131003-0ubuntu1 |         saucy | amd64, armhf, i386, powerpc
<cjwatson> liburl-dispatcher1-dev | 0.1+13.10.20131003-0ubuntu1 |         saucy | amd64, armhf, i386, powerpc
<stgraber> so far the click apparmor stuff has been the one I had to let through the most I think
<cjwatson> url-dispatcher | 0.1+13.10.20131003-0ubuntu1 |         saucy | source
<cjwatson> url-dispatcher and url-dispatcher-tools binaries are in universe
<slangasek> oh right, source v. binary
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/ALL/liburl-dispatcher1
<slangasek> so no love for url-dispatcher
<cjwatson> reverse depends: indicator-bluetooth reverse recommends: unity
<slangasek> interesting
<cjwatson> and indeed several other indicators
<cjwatson> datetime, power, sound
<slangasek> yes, we want to make sure there's a common framework for dispatching those urls from your bluetooth headset, so that attackers don't have to search too hard ;)
<smoser> hey. i jus tuploaded a simplestreams simplestreams_0.1.0~bzr315-0ubuntu1.dsc . that replacews the bzr314 that i did earlier.
<smoser> if someone could nak the 314 that'd be thank ful.
<slangasek> done
#ubuntu-release 2013-10-10
<lool> slangasek, stgraber, or infinity: ^ hey would you mind reviewing this one?  changes from libmirserver5 to libmirserver6
<infinity> Hahahahahaha.
<infinity> Again?
<infinity> AGAIN?
<lool> unity-mir + platform-api + unity-system-compostor will come in shortly
<lool> infinity: of course!  this one is actually the ABI which is meant to be unstable  ;-)
<slangasek> lool: you've got a little Freud there
<infinity> lool: So they should have just called it libmirserver0 and required stricted shlibdeps.
<lool> infinity: I actually piled up too changes, the initial plan had two ABI changes, one some hours ago and one tomorrow
<infinity> s/stricted/stricter/
<cjwatson> I see my arm64 build-dep change wasn't included :(
<infinity> Anyhow.  Will review and override.
<cjwatson> merged but I guess too late
<lool> ah yes
<infinity> cjwatson: If you want your changes noticed, upload to the archive and wedge the autolander. :P
<lool> cjwatson: I can offer another upload immediately after this onr
<lool> one
 * infinity knows how to game the system.
<cjwatson> lool: that'd be good, thanks
<lool> but I'd like to get this one, then merged back etc.
<cjwatson> infinity: seems like a CLM at the moment
<cjwatson> for this package
<infinity> cjwatson: I did it all through the cycle, but I agree that I wouldn't do it right NOW. :)
<slangasek> infinity: so, you're claiming this one?
<infinity> slangasek: Yeah, I've got it.
<slangasek> ok
<infinity> If I can type on my laptop without my hands setting on fire.
<infinity> Parallel kernel and glibc builds are, apparently, a sweaty affair.
<lool> I'll queue the rebuild ones
<infinity> +  [ Robert Ancell ]
<infinity> +  * Bump version to 0.0.12
<infinity> +
<infinity> +  [ Kevin Gunn ]
<infinity> +  * bump version to 0.0.13
<infinity> +
<infinity> +  [Kevin Gunn]
<infinity> +  * bump version to 0.0.14
<infinity> I don't even...
<lool> ^ rebuilds
<lool> unity-mir has important other changes
<lool> platform-api has one fix
<lool> infinity: mind reviewing platform-api too?
<infinity> lool: Already on it.
<cjwatson> amd64: 0 uninstallables
<cjwatson> well, as long as you don't count arch: all, which I think will be next cycle's project
<slangasek> cjwatson: nice!  Is that the same as 100% superseding of the bootstrap archive?
<cjwatson> amd64 != arm64
<slangasek> oh geez
<slangasek> and so it begins
<slangasek> see, it *should* have been called aarch64 :P
<lool> but then you wouldn't be able to pronounce it!
<slangasek> lool: 'aardvarch'
<lool> arf
<lool> I mean arf64
<lool> so I've pushed hud and ubuntu-keyboard too
<lool> ubuntu-keyboard is not seeded in ubuntu
<lool> but hud is and has some important fixes for it to stop crashing unity8
<lool> and hud is the last one I have for tonight that needs review
<lool> (I hope :-)
<lool> infinity: are you looking at hud too?
<infinity> Only because you asked nicely.
<lool> thanks
<infinity> lool: These changes seem to represent a lot more than what the changelog implies...
<infinity> lool: Seems the universally disabled bamf, plus a ton of other stuff in here.  New upstart jobs, etc.
<lool> infinity: So not sure which one specifically, but indeed; usually one line in the changelog is one merge proposal potentially of a huge rework; perhaps it's easier to review the corresponding bzr log -n0
<lool> infinity: hud?
<infinity> Yes..
<lool> infinity: Yeah, so hud is essentially hmm "let
<lool> "let's quickly write a platform-api backend"
<lool> trying to be feature compatible with bamf
<infinity> Yeah, but no.
<infinity>  ifeq ($(DEB_HOST_ARCH),armhf)
<infinity>         ENABLE_PLATFORM_API = ON
<infinity> +       ENABLE_BAMF = OFF
<infinity>  else
<infinity>         ENABLE_PLATFORM_API = OFF
<infinity> +       ENABLE_BAMF = ON
<infinity>  endif
<infinity> That implies that on !armhf, bamf is meant to still be used.
<lool> if armhf  :-(
<infinity> But they dropped the build-dep.
<lool> yes
<infinity> And bamf isn't linked anymore AT ALL.
<lool> that seems a mistake
<infinity> However, platform_api would also not be used on my laptop anymore, due to the above.
<infinity> So, I get neither.
<lool> you wouldn't want platfomr-api on your desktop I think
<infinity> I'm not sure I care if I have either one, but I assume some people do care about regressing the bamfy bits a week before release.
<lool> yes
<lool> but this also unbreaks the touch image a lot
<infinity> lool: Rejected.  Please relay to whomever, since the mail goes to a blackhole.
<lool> infinity: BTW thanks for the review; yes, I'm passing this on or fixing it and I should have catched that in review
<lool> but missed reviewing this packaging diff, my bad
<lool> (we have a review step to look at the diff of control + CMake files etc.)
<lool> cjwatson: ^ arm64 fix
<infinity> lool: Danke, accepted.
<lool> infinity: ah it turns out the bamf bdep removal was intentional
<lool> infinity: it's now autogenerated calls from a xml file!
<lool> my gosh
<lool> infinity: it has a bamf dbus interface file instead of linking to the C lib
<lool> infinity: so I have a build here which is like the previous one, but readds the bdep; I've tested it locally, and hud starts, the upstart log says stuff about the voice engine starting that I dont know how to test, but it's not crashing
<lool> infinity: I'd like to followup with upstream tomorrow, but would you think we could take this change that is at least not breaking desktop startup as to unblock touch image?
<lool> well tomorrow == in some hours
<lool> but would like to have hud in a build
<lool> hmm maybe I've lost infinity
<lool> slangasek: still around?
<infinity> lool: I'm still here, just hacking away.
<lool> infinity: ah great
<infinity> lool: That seems like quite a change (C API to DBUS interface) to be making a week before release...
<lool> infinity: yeah, it's a port to platform-api
<lool> infinity: it's awfully large
<lool> infinity: but it's not crashing and burning
<infinity> "Not crashing" is hardly a testament to continued functionality. :P
<lool> infinity: desktop session is fine; I wont pretend I know how to test all the features (I never use hud), but I can commit to chekcing with ted and or pete-woods
<lool> pete comes in the morning
<infinity> But meh.  If the people responsible are willing to own this if it blows up and sort out the aftermath...
<lool> infinity: I'll take the blame if it breaks people desktops
<infinity> (I don't use hud either, so it's all a mystery to me how I'd test it)
<lool> reuploading it here
<lool> infinity: so I have a stupid change to readd the bdep now
<infinity> lool: Alright, well, I'm not sure why we'd need the b-d back, if it doesn't link the library anymore.
<lool> infinity: will remove once I have chatted with ted and/or pete
<lool> but it doesn't change anything
 * infinity nods.
<lool> the bdep was when using the C api
<infinity> Right.  I think someone needs to train these folks to use more informative merge commit messages.
<infinity> Make them all submit a few patches to linux or git to learn how to write useful changelogs. ;)
<lool> hmm I'm not confident cu2d pushed it
 * infinity spins up another eglibc build...
<lool> it seems not
<lool> so
<lool> there we go
<lool> will be there in 3mn
<lool> infinity: ^
<lool> (same as before, but with bdep added)
<infinity> lool: When it all goes south, I'll be sure to blame you. :)
 * lool hides in a cave
<lool> infinity: I've dropped an email to maintainers already to please test when they get up and tell me about any regressions
<roaksoax> slangasek: uploaded maas
<infinity> slangasek: If you're around, can you review that eglibc?  We need the last patch for arm64, I threw in a bunch of security updates for good measure. :P
<slangasek> infinity: you couldn't have left the security updates for the -security pocket, where we don't have to worry about them introducing regressions a week before release?
<infinity> slangasek: Marc was going to upload most of those security fixes a few days ago, I asked him to hold off while we looked into a few other bits.  But meh?  Testsuite passes, diffs all look sane.
<slangasek> wow, pt_chown goes away
<infinity> slangasek: Yeah, I have to think about how that will impact Debian, and if I have to re-enable it for non-Linux kernels, but the answer for Linux is simple, just make it go away.
 * slangasek nods
<infinity> slangasek: Apparently, someone has discovered how to use pt_chown to exploit fuse, which made its long-term known-insecure status much, much worse.
<slangasek> haha
<slangasek> ugh, are you sure this strcoll patch is sane? how thorough are the existing strcoll tests?
<infinity> Yeah, my response to Marc was "can't I just make libc6 conflict with fuse instead?"
<infinity> slangasek: There are a few strcoll tests, two for general sanity, and two for bugs.
 * slangasek checks, out of an abundance of caution, that the dirstream struct is genuinely opaque
<slangasek> s/caution/paranoia/
<slangasek> also, "dirp" is the best variable name the history of variables
<infinity> slangasek: That strcoll patch is already in the security PPA and tested, and mdeslaur was planning to release soon, AFAIK.
<infinity> slangasek: (Hence why he asked me to push to saucy)
 * slangasek nods
<infinity> slangasek: The only two I added that aren't in the PPA are the pt_chown and static pointer guard fixes.
<infinity> pt_chwon speaks for itself.
<infinity> And the stack guard thing is more testsuite than patch.
<infinity> (Admittedly unreadable patch, if you don't speak 7 versions of assembly...)
<slangasek> infinity: why patches/ubuntu/unsubmitted-dlopen-static-crash.diff?
<slangasek> no related regression test; no bug report; fixes a corner case (who calls dlopen from a statically-linked executable and can we have them flogged?)
<infinity> slangasek: That's to make our conftests stop segfaulting.  That's Colin's contribution to this upload.
<slangasek> hmmmm
<infinity> slangasek: Turns out that some 25% of autotools packages have conftests that do exactly that.  And segv.
<infinity> slangasek: Which is messing with my segv-scanning magic on the arm64 buildds. :P
<infinity> slangasek: But also just seems silly, if we can fix it anyway.
<slangasek> that's a surprisingly high percentage
<infinity> slangasek: Large portions of that are rewritten in 2.18.  I'll be testing if this is still a problem in 2.18/2.19 and submit it upstream with a proper testcase if it is.
<slangasek> ok
<slangasek> accepted
<slangasek> I don't suppose you have time to review maas, which was what I was planning to do instead of eglibc? :)
<infinity> Maaaaybe.
<infinity> Oh, doesn't look huge.  Sure.
<slangasek> cheers
 * infinity will regret that statement, won't he?
<infinity> I think ChangeLog/NEWS files nees a "Bugs created in this release" section under the "Bug fixed" section.  Would make it much easier to review.
<infinity> Waaaaitaminute.
<infinity> roaksoax: Did you really re-use an FFe from August for this upload? :)
<infinity> roaksoax: Also, why on earth does the maas-cluster-controller postinst check if apache2.2-common is installed?  It depends on it...
<infinity> roaksoax: Okay, seriously, not trying to be a jerk here, but it's a week before release, and this has a LOT of new features and pretty massive changes.
<infinity> roaksoax: And handwaving and saying "we got an FFe for an upload 1.5 months ago" doesn't cut it.
<slangasek> infinity: well, I read that changelog as saying "this is a bugfix-only upstream release fixing features that were already uploaded under the mentioned FFe"?
<infinity> slangasek: That's what the changelog says, it's not what the code says.
<slangasek> hmm
<infinity> slangasek: I think someone's using a rapid double-talk variant of the term "bug fix" to mean "fill in the blanks on all the features we half-implemented for our last exception", or similar.
<RAOF> That was certainly our plan :)
<slangasek> cjwatson: still a chance of getting bug #1236625 into grub?
<ubot2> Launchpad bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [High,In progress] https://launchpad.net/bugs/1236625
<infinity> slangasek: Poof.  It's done.  Bug #1236625 is in grub.
<ubot2> Launchpad bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [High,In progress] https://launchpad.net/bugs/1236625
<slangasek> infinity: thanks, appreciate you taking care of that for me ;P
<infinity> slangasek: Would you like me to add any more bugs to it while I'm being helpful?
<slangasek> infinity: would you be a doll and break ipv6 tftp support?
<infinity> Also done.
<infinity> ^-- Fixes an FTBFS in the testsuite, and a minor packaging tidy up.
<cjwatson> slangasek: yeah, was planning to look over that today
<infinity> cjwatson: ^
<cjwatson> looking
<cjwatson> oh is that the segfault on arm64 too?
<cjwatson> (or is that just a random one?)
<infinity> You mean the one in the current logtail?
<infinity> That's just random hate.
<cjwatson> Yep
<cjwatson> k
<infinity> At least, I hope so.
<infinity> It's mildly disconcerting that it spit out the bug report instructions instead of the "hey, we tried this twice and it's totally your crap hardware's fault, yo".
 * cjwatson belatedly moves python-commandnotfound to main
<cjwatson> (image build failures)
<infinity> Is it in poor form in certain circles to complain that I'm only getting 9MB/s from github tonight?
<cjwatson> lalala I can't hear you
<infinity> Oh, there we go, 12 is a little more respectable, I guess.
<cjwatson> and birch ICEs four minutes in
<cjwatson> infinity: ah, nice one for getting armhf to 0 uninst (soon)
<infinity> Alright, twombly.  Are we gonna have any problems here?  *stare*
<infinity> Whoa.  Wait a minute.  Does LLVM actually have a functional arm64 port, or is it just happily building arm64 binaries that can cross to every arch it DOES support, but no arm64 backend?
<infinity> (I mean, I know it must have a functional armv8 port internally at Apple, but I didn't remember seeing it in the packages.  Didn't look hard either, though)
<wgrant> Apple has withheld the A64 source for now AIUI.
<wgrant> So I doubt it's building anything particularly useful
<infinity> Right, so WTF is it building? :)
<infinity> I guess a generic frontend to all the other backends.
<infinity> So I can build i386 binaries on arm64.
<infinity> Can't wait.
<wgrant> twombly fail
<wgrant> Delicious ICE
<wgrant> Er
<wgrant> as segfaulted?
<infinity> Sure, why not?
<infinity> Everything segfaults.
<wgrant> It's usually cc1, but I guess as works too...
<infinity> It's only usually cc1 because cc1 spends more time on the CPU.
<cjwatson> That's two successive eglibc segfaults in <5mins
<infinity> Literally anything can be sniped by this hardware, so.  Whatever.
<wgrant> Only one of the last four builds got through the first 5 minutes :/
<infinity> I could superstitiously reboot some hardware.
<cjwatson> WCPGW
<infinity> But I imagine we're just victims of random distribution being, y'know, random, and human brains being unable to cope with that.
<wgrant> I don't think superstition is unwarranted with this hardware.
 * cjwatson starts building stone circles
 * infinity looks online for mail-order chickens.
<cjwatson> I'm seriously having continued trouble with the name "twombly", though.  Where did it come from?
<cjwatson> I keep getting an "Overground, underground, wombling free" earworm
<cjwatson> Or was it "Underground, overground"?  One of those.
<wgrant> The names were probably selected from the list of legendary creatures by the CPUs themselves.
<cjwatson> :-)
<cjwatson> https://www.youtube.com/watch?v=FZ2mJPSccvo
<cjwatson> The 70s really were on excellent drugs
<wgrant> Is the stop-motion version of the show I saw years ago a fraud, or is this music video an exception?
<cjwatson> I don't remember it being stop-motion, but it was a long time ago ...
<xnox> 8] omg
<wgrant> TWOMBLY
<wgrant> Why do you do this, twombly.
<wgrant> infinity: Any news on those chickens?
<infinity> Yeah, screw it, time for religion.
<infinity> birch is getting a completely unnecessary reboot once it goes idle.
<infinity> And little wobbly twombles too.
<cjwatson> https://www.youtube.com/watch?v=aCf_PpDUTdA does look awfully stop-motion to me, so perhaps wgrant's memory is better here
<wgrant> Yeah, that's the one.
<cjwatson> They were a bit of a peculiar 70s pop sensation as well though.
<wgrant> I would have seen them here in like '98. I had no idea they were so old.
<infinity> I think the only low-tech entertainment I miss is The Muppets.
<wgrant> infinity: Does birch particularly hate reboots?
<wgrant> And/or life in general?
<ogra_> hmm
<infinity> How or why has dh-python found its way into minimal?
<cjwatson> wgrant: Oh, we're on a new naming scheme, I hadn't noticed
<wgrant> cjwatson: orly?
<cjwatson> defunct US automobile manufacturers
<cjwatson> I blame Spads
<infinity> wgrant: No, it's okay with them, I decided to upgrade the base system too.
<wgrant> infinity: Ah
<wgrant> cjwatson: Heh
<ogra_> so i was just asked to seed webbrowser-app ... which i did, but now regenerating meta gets me " Unknown desktop package: webbrowser-app" ... even though madison sees it in saucy and b) it wants to seed dmidecode on armhf ?!?
<cjwatson> https://en.wikipedia.org/wiki/Twombly_%28cyclecar%29
<infinity> ogra_: It's in universe.  I'll re-promote it.
<infinity> ogra_: Well, once your seed changes go through...
<ogra_> infinity, ah, thanks, whats that dmidecode thing ?
<cjwatson> That's in standard, don't know why it would be explicitly listed in touch
<cjwatson> pastebin the full output from ./update?
<ogra_> cjwatson, ubuntu-meta :)
<cjwatson> Oh
<cjwatson> Well, that'll be because somebody got it to build recently
<cjwatson> https://launchpad.net/ubuntu/+source/dmidecode/2.12-2
<infinity> Wait, why is webbrowser-app landing in ubuntu-desktop?
<ogra_> http://paste.ubuntu.com/6217122/
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715139 "on-going work to enable SMBIOS on ARM"
<ogra_> infinity, because it is the new platform for all webapps
<ubot2> Debian bug 715139 in dmidecode "dmidecode: Build for armhf architecture" [Wishlist,Fixed]
<ogra_> lol
<ogra_> SMBIOS on ARM
<xnox> infinity: i love webbrowser-app, it's the only browser on ubuntu so far that scrolls on touch input, instead of selecting text. (kind of handy with convertable touch notebooks)
<xnox> also it's probably improssible to select text in webbrowser-app.
<cjwatson> -Architecture: all
<cjwatson> +Architecture: foreign
<cjwatson> +Multi-Arch: same
<cjwatson> go libaria
<cjwatson> (please, go)
<infinity> Hahahaha.
<infinity> Architecture: maybe
<cjwatson> I wonder which the maintainer meant
<infinity> Multi-Arch: very
<infinity> Who knows, really.
<cjwatson> I'm going to guess all/foreign, given that it's -dev-doc
 * xnox looks cross-eyed, does that even build?
<cjwatson> No
<cjwatson> Well, sort of
<cjwatson> It builds all the *other* binaries
<infinity> It'll just skip that binary
<xnox> excellent.
<cjwatson> And leaves that one in undocumented NBS
<infinity> Since it's not building for the arch "foreign".
<cjwatson> (i.e. listed in saucy_outdate_all but not actually in NBS proper)
<infinity> I can add it to dpkg's arch table, if you like.
<xnox> Architecture: sometimes
<lool> lol
<lool> Architecture: maybe made me laugh quite a bit too
<infinity> Alright, superstition engaged.  Begin swinging chickens.
<cjwatson> Well, the next Debian revision up fixes this but also adds Python bindings
<cjwatson> The changes look fairly harmless, though, so I'll probably sync that.  Just build-testing
<cjwatson> rebuilding Ubuntu desktop images
<cjwatson> (they failed due to component-mismatch)
<cjwatson> Riddell: I don't think that'll work, you have leading spaces instead of tabs which I expect make will object to
<cjwatson> +else ifeq ($(DEB_HOST_ARCH),armhf)
<cjwatson> +        ./Tools/Scripts/build-webkit --qt DEFINES+=ENABLE_JIT=0 DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 DEFINES+=WTF_USE_3D_GRAPHICS=0
<cjwatson> in that bit
<cjwatson> Riddell: could you replace those eight spaces with a hard tab and reupload?
 * cjwatson retries what looks like an ephemeral eglibc/amd64 failure
<cjwatson> (tst-robust8 timed out)
<wgrant> I spy a universe release package on twombly. I guess the main queue is finally all depwaited.
<infinity> Or twombly's just acting out.
<Riddell> cjwatson: arg sure
<cjwatson> wgrant: I scored up a couple of small things that proposed-migration mentioned waiting on
<cjwatson> oh, not arpwatch though
<cjwatson> So, yeah, main's probably depwaited
<wgrant> Yeah, the score was in the 1700s
<wgrant> https://launchpad.net/ubuntu/saucy/arm64/+builds?build_text=&build_state=pending is all <2000
<cjwatson> We'll probably get quite a few successful trivial builds
<wgrant> I noticed earlier that some armhf stuff is deadlocked in proposed-migration.
<cjwatson> such as?
<cjwatson> (do you mean armhf?)
<wgrant> Er
<wgrant> arm64
<wgrant> djvulibre
<wgrant> djvulibre is in -proposed, but djview won't be installable without djview4, which is in release depwaiting on libdjvulibre-dev
<infinity> And this is why building in the release pocket is a bit broken. :/
<infinity> We can do some manual copies from proposed to release.
<infinity> Sadly, not to much the other way (as in, we can't magically make release builds build in proposed...)
<infinity> Oh, but I could just add proposed to the chroots unconditionally for a bit. :P
<wgrant> Right
<wgrant> Heh
<infinity> Or we could copy the binaries from proposed to the bootstrap repo.
<infinity> Which seems saner still.
<infinity> Then they'll still get proper migration checks when they're ready to go.
<wgrant> Or just copy the source+binaries to release.
<infinity> Yeah, but copying them to release is skipping the checks that are holding them out.
<infinity> Feels dirtier.
<wgrant> Dirtier than putting them in a sources.list.d backdoor? :)
<infinity> Anyhow, let me do the bootstrap copy for djvuwhatever.
<infinity> wgrant: Well,the backdoor is only for build-deps, the actual migration of the package in the archive is still guarded by making sure it's installable.  Sort of.
<wgrant> True.
<infinity> (The britney hack kinda mucks with that too. :( )
<infinity> Can't wait for that to go.
<cjwatson> 41 packages left ...
<infinity> wgrant: Erm, djview4 was dep-wait on qt4-opengl.
<wgrant> At the moment, yes ;)
<wgrant> s/;/:
<infinity> Alright, well.  djwhosit-dev is in the bootstrap archive.
<wgrant> But once qt4 exists it'll still be stuck forever until someone prods it manually.
<infinity> So, that'll kinda sort itself.
<cjwatson> LP won't notice the dep-wait resolution in bootstrap, so it'll probably still need a retry
<infinity> cjwatson: Except it was dep-wait on qt4.
<cjwatson> Oh, right
<infinity> cjwatson: Because, way back when, whoever wrote that for me was too lazy to emulate the wanna-build ability to have multiple dep-waits.
<infinity> Or, so they told me.
<infinity> So I never fed them multiple from the slave side.
 * cjwatson nods
<cjwatson> Riddell: sorry, didn't notice that upload, re-reviewing now
<cjwatson> right, everything in http://people.canonical.com/~ubuntu-archive/testing/saucy_outdate_all.txt now looks like it's in progress
<cjwatson> strange libaria build failure though, worked locally, investigating
<infinity> cjwatson: I see no indication in the log that libAria is being linked to -lpthread or -ldl
<infinity> cjwatson: Not sure how that would work locally.
<cjwatson> Yeah, not sure why it worked locally
<cjwatson> Unless I fumble-fingered and test-built on unstable
<cjwatson> Which syslog suggests I did.  Whoops
<infinity> Say, did anyone proposed --as-needed as a jessie release goal? :P
<infinity> Yay, birch, I love you!
<infinity> ALL IS FORGIVEN.
<wgrant> Near the end of a publisher run, too
<infinity> wgrant: I'll just toss it in the bootstrap repo, so the world can benefit ASAP.
<wgrant> Oh, better plan.
<wgrant> cjwatson: germinate's been crashing today
<wgrant> 2013-10-10 09:50:29 INFO    Germinating for ubuntu-gnome/saucy/arm64
<wgrant> 2013-10-10 09:50:30 ERROR   Unhandled exception
<wgrant> KeyError: 'hunspell-en-us'
<cjwatson> ok, I'll have a look
<wgrant> OTOH it makes the publisher much faster :)
<cjwatson> I bet
<cjwatson> Though ubuntu-gnome is probably fairly late in the list
<wgrant> But arm64 is second
<cjwatson> Ah
<wgrant> So it does amd64, then part of arm64, then boom
<cjwatson> Forgot it was that way round
<ogra_> infinity, webbrowser-app is still unknown ...
<infinity> Oh dear lord, it's dragging the world in with it.
<cjwatson> Urgh, yeah, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't look good
<infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<infinity> Prettier in graph/blame form.
<Laney> didn't we already revert a webbrowser-app promotion because of that?
<cjwatson> That doesn't look desperately feasible for 13.10
<infinity> ogra_: Did anyone actually examine the rdeps here before deciding to do this 12h before final freeze?
<ogra_> infinity, no idea, there is an approved MIR and it is needed for webapps to work
<infinity> wgrant: Merry Christmas, have a wayland.
<wgrant> infinity: Is that why birch is manual?
<cjwatson> ogra_: There aren't approved MIRs for all the dependencies.
<infinity> wgrant: Yeah.
<cjwatson> Indeed several of them have been disapproved IIRC.
<wgrant> infinity: Wanna do gst-plugins-base0.10 as well? It has all the src:src segfaults and is the remaining qt4-x11 blocker...
<ogra_> hmm bug 1206268 was the one i looked at
<ubot2> Launchpad bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,Fix committed] https://launchpad.net/bugs/1206268
<infinity> ogra_: An approved MIR for webbrowser-app doesn't mean an approved MIR for every single one of its many rdeps.
<cjwatson> wgrant: You think libc will make any difference to that?
<wgrant> cjwatson: I don't think so.
<infinity> ogra_: Did you look at the rdep graph?
 * cjwatson starts retrying conftest bugs
<ogra_> infinity, nope
<wgrant> Remember that the conftest segfault only didn't happen on x86 because the build failure was ignored
<infinity> wgrant: Do you think the src:src stuff is harmless?  Do we know it is? :P
<cjwatson> Were alsa-lib and autogen conftest bugs?
<infinity> alsa-lib is.
<wgrant> Yes, just retried them
<wgrant> infinity: No, we don't, unfortunately. :/
<infinity> I'm inclined to just do a mass-give-back and see what sticks.
<infinity> Unless someone's been keeping a list.
<cjwatson> I'd rather check - we have such limited build time
<cjwatson> Going through the logs now
<infinity> Aaaaalso...
<infinity> https://launchpadlibrarian.net/153371510/buildlog_ubuntu-saucy-arm64.ircd-ratbox_3.0.7.dfsg-3_FAILEDTOBUILD.txt.gz
<ogra_> infinity, looking at the binary deps i dont see anything special (all stuff that unity8 will even need on the desktop and which was actually supposed to be MIRed long ago) ...
<infinity> ^-- New glibc in chroot, still has conftest faults.
<cjwatson> ogra_: We explicitly rejected the roaraudio etc. stack IIRC
<infinity> ogra_: Don't look at the binary deps, look at the graph I linked to you.
 * ogra_ doesnt see that in the binary deps ... 
<infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<ogra_> infinity, oh, ouch
<ogra_> thanks, i missed the link above
<xnox> infinity: ogra_: wasn't qtmultimedia-opensource-src be dropped from the ui toolkit?! Maybe that didn't happen this cycle yet?
<infinity> cjwatson: Oh, hrm.  That's an l3 permission fault instead of an l2 translation.  Fun.
<wgrant> libprelude is weird like that as well
<ogra_> xnox, might be, but seems currently it is still used
<wgrant> It has a non-0x8 FAR
<wgrant> But it runs the right test to trigger the 0x8 FAR
<infinity> ogra_: I just don't see this happening for release.  If we need this "for webapps to work", perhaps people need to rethink webapps working how they used to.
<infinity> (Or people need to go back in time and remember that Feature Freeze for non-touch was a month ago)
<ogra_> heh
<infinity> wgrant: Okay, no dmesg badness from pulse yet.
<cjwatson> Was libtool/arm64 a conftest bug?
<wgrant> 2013-10-10 10:03:57+0000 [QueryProtocol,client] Processing finished OK build PACKAGEBUILD-4960053 (arm64 build of aspell 0.60.7~20110707-1build1 in ubuntu saucy RELEASE) from builder twombly
<wgrant> We're good
<wgrant> cjwatson: No
<wgrant> cjwatson: It has a separate segfault that doesn't appear on amd64
<cjwatson> ok
<wgrant> gst-plugins-base0.10 lsof libtool mksh python3.3
<wgrant> are the five that were like that in core this morning
<wgrant> wayland (deliberate) udisks2 (deliberate) ibus (???) libtimezonemap (???) are reproducible on amd64, not sure if the last two are deliberate
<infinity> wgrant: Are you sure the libtool one might not be a manifestation of the same bug, though?  I mean, it's libtool.  Its job is to do stupid things with libraries.
<cjwatson> libtimezonemap is a bug
<ogra_> GRRRR !
<cjwatson> A fairly harmless one normally but still a bug
 * infinity tries libtool for kicks.
<ogra_> why did we have to name the display server Mir ....
<wgrant> libtool[7670]: unhandled level 3 permission fault (11) at 0x2000008a2c, esr 0x9200004f
<wgrant> That's no 0
<wgrant> But I guess
<infinity> Oh, it's l3.  Boo.
<wgrant> Well, no
<wgrant> We explicitly fixed the case where FAR=0x8
<ogra_> it got really hard to google any MIR wikipages nowadays (ubuntu wiki mir ...)
<wgrant> If we fixed anything else then the fix is horribly wrong :)
<infinity> ogra_: People don't use MIR wiki pages anymore...
<infinity> (Does anyone?)
<infinity> ogra_: Or do you mean the page that documents the process?
<ogra_> i link to them in bugs if people obviously didnt follow the process
<wgrant> alsa-lib success too
<wgrant> Oh, interesting question.
<wgrant> Does the test return yes or no now?
<infinity> ogra_:  https://wiki.ubuntu.com/MainInclusionProcess
<infinity> ogra_: First hit on google for "main inclusion report"
<ogra_> infinity, yeah, i was looking for "requirements" (linked from there though)
<infinity> wgrant: Which test was it?
<wgrant> checking whether a statically linked program can dlopen itself... no
<wgrant> So it still fails, but at least doesn't segfault
<ogra_> infinity, already commented on the bug :)
<infinity> wgrant: Pretty sure that should be a no.
<wgrant> It fails everywhere else too because it fails to link, just thought this fix might make it work on arm64.
<infinity> wgrant: dlopening yourself sounds like something libdl would take pretty seriously.
<wgrant> Sure, but it was segfaulting yesterday, I guess it must fail more pleasantly now.
<cjwatson> What was pygobject?
<wgrant> This error
<wgrant> https://launchpadlibrarian.net/152846674/buildlog_ubuntu-saucy-arm64.pygobject_3.10.0-1_FAILEDTOBUILD.txt.gz
<cjwatson> retried
<cjwatson> ah yes
<infinity> 4 times, no less.  Overachiever.
<wgrant> x4, but I guess it runs configure 4 times
<cjwatson> wgrant: It's yes for dynamic, no for static
<cjwatson> Which is fine
<infinity> If lazy upstreams didn't just say "yeah, I'll use all the default autoconf tests", we'd never hit this. :P
<wgrant> Yeah, creates config.status 4 times, so 4 faults is expected.
<infinity> Cause I can't imagine any of them actually care about if they can dlopen a static binary from itself.
<cjwatson> infinity: This one's from libtool, actually, I think
<cjwatson> I can imagine dlopening yourself being useful for a dynamic binary introspecting its own symbols by name or something
<cjwatson> A fairly crazy one, but not totally crazy
<wgrant> So all looking good so far.
<cjwatson> I love sunpinyin/arm64 failing in src/portability.cpp
<cjwatson> Subject: sunpinyin: misnamed source file
<wgrant> Heh
<infinity> Hah.
<wgrant> 2013-10-10 10:19:43+0000 [QueryProtocol,client] Processing finished PACKAGEFAIL build PACKAGEBUILD-5082847 (arm64 build of libprelude 1.0.0-11ubuntu1 in ubuntu saucy PROPOSED) from builder birch
<wgrant> conftest[8608]: unhandled level 2 translation fault (11) at 0x0a9648d8, esr 0x92000046
<wgrant> sigh
<infinity> Random kill, or different unresolved issue?
<wgrant> Different unresolved and repeatable issue.
<infinity> Balls.
<wgrant> Rather.
<wgrant> I thought it might have been some manifestation of the dlopen bug, given that it was the sole failure in a build that ran the buggy test.
<infinity> I'm beginning to wonder if maybe crashing conftests are just a way of life, and something I've never noticed until today.
<cjwatson> Seems somewhat likely
<wgrant> I don't think I've tested libprelude locally, actually.
<wgrant> So that's plausible.
<cjwatson> OK, I think that's all the conftest failures retried
<wgrant> Everything's passed so far except libprelude, and it was dubious anyway
<cjwatson> So even with some remaining issues we should be able to make progress
<infinity> On the other hand, we've still had weird things like random unreproducible faults in dpkg-* and such go unnoticed, which makes me wary of turning off the check.
<wgrant> Oh yeah, turning off the check entirely would be insane.
<infinity> But for the oddball ones, if we can determine they're a non-issue, I can slip in an extra filter for them like I did for wayland.
<wgrant> btw
<wgrant> easy way to determine which conftest failed
<wgrant> run ./configure on the console, look for interpersed kernel spew
<infinity> That's too easy for me to have thought of.
<infinity> Do we get to have both the gstreamers?  That should unsnag a chunk.
<wgrant> gstreamer1.0 should build, not sure 0.10 will
<wgrant> Oh yeah, both will
<wgrant> But we're still stuck on the 0.10 plugins
<infinity> Oh, right, that weird src:src thing.
<tkamppeter> Hi, I have uploaded cups-filters 1.0.40. It is a pure bug fix release. Besides some smaller bugs it fixes the problem that many users of Brother printers have margin problems and users of expensive Konica Minolta PostScript printers cannot print at all. So please take it into Saucy. Thanks.
<tkamppeter> Thanks.
<xnox> Please accepted ubiquity - fixes crasher in the U1 plugin when trying to sing-in or sign-up.
<wgrant> Is that like Android's face unlock?
 * xnox blinks to confirm i am alive
<xnox> wgrant: yes =)
<xnox> wgrant: or like apples touchID, with some people using other body parts instead of fingerprints....
<wgrant> So I've heard!
<xnox> thanks for ubiquity
<Laney> Not sure I'd like to try that on my laptop
<knome> hey, could somebody help xubuntu get pm-utils to our seed? we don't have uploaders available at the moment. bug 1232027
<ubot2> Launchpad bug 1232027 in xubuntu-meta (Ubuntu) "pm-utils not installed by default in 13.10" [Medium,Confirmed] https://launchpad.net/bugs/1232027
<infinity> knome: I can help with that.
<knome> infinity, cheers!
<knome> let me know if you need any additional information
<infinity> I'm actually a little puzzled as to how it makes it on ubuntu-desktop...
<infinity> Ahh, gnome-power-manager -> upower -> pm-utils.
<infinity> knome: Based on what kubuntu did, I'm guessing you might want a (upower) recommend, instead of a direct pm-utils dependency.
<knome> infinity, that works for me
<xnox> infinity: yeap, i have same analysis, but slower to work it out =)
<knome> upower seems to be in xubuntu 13.04. i assume that has changed for a reason or another for saucy
<infinity> knome: Something probably used to depend on it and you got it transitively.
<knome> yep
<infinity> knome: Or maybe you used to ship gnome-power-whatever.
<knome> that's probably it, but i can't remember clearly. but yeah, i'm fine with installing upower
<infinity> Wait.  xfce4-power-manager  Do you not ship that anymore?
<knome> afaik we should
<infinity> Then you should have upower in your desktop, and thus pm-utils.
<infinity> Oh.  Unless you ship something that provides systemd-services
<infinity> And germinate is outsmarting you.
<infinity> That's probably what's up.
<knome> heh
<knome> oki
<infinity> I'll just explicitly seed pm-utils.  Screw it.
<knome> worksforme
<knome> we can look at it for 14.04
<xnox> retoaded: ubiquity auto-pkg-test failure: I cannot reproduce it locally, and it looks like it's using 2.15.22 unit-tests, but running them against older binaries (? 2.15.21)? from the logs it's not obvious which versions of binary packages under test were installed.
<xnox> can it please be retried?
<retoaded> xnox, link?
<xnox> it was retried and it's blue now.
<xnox> (well passed)
<xnox> retoaded: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubiquity/
<retoaded> xnox, ack. While I have the ability to disable a test/job it is probably better to take that proposal to the owner/maintainer of the job. In this case it appears to be jibel or pitti.
<xnox> retoaded: ack.
<infinity> knome: ^-- That's for you.
 * knome bows
<jibel> xnox, run 221 is green or you still want a retry?
<xnox> jibel: all is good, it was retried and passed, and is in release pocket as off 5 minutes ago =)
<xnox> jibel: thanks.
<zul> cjwatson:  can you approve  #1236901 please?
<cjwatson> zul: done
<zul> cjwatson:  also can you approve swift rc1? as well
<cjwatson> zul: sounds big, kinda busy with arm64, maybe somebody else can?
<zul> cjwatson:  sure
<cjwatson> libpwquality/arm64 I think is best addressed by taking the new upstream bugfix release - only a couple of other fairly trivial changes
<sil2100> Hi guys! We need a new libunity released into -proposed (and to release) for touch related things, it's currently in the unapproved queue - can anyone push that forward?
<sil2100> cjwatson, infinity: ^ ;)
<sil2100> Pretty please with cherries on top! ;)
 * ogra_ thinks beers would work better 
<sil2100> Pretty please with beer on top..?
<ogra_> (see /topic)
<ogra_> :)
<sil2100> That somehow doesn't sound right ;)
<cjwatson> sil2100: looking
<cjwatson> accepted
<Laney> What happens with touch stuff after Final Freeze?
<sil2100> cjwatson: \o/ thank yoU!
<Laney> Either touch-only or touch-parts-in-other-things uploads
<ogra_> touch only should still go through
<ogra_> it is gated before entering usually
 * didrocks uploads the seed refresh then
<seb128> ogra_, what about e.g indicators?
<didrocks> Laney: this go through automatically as it's touch only or something changed since last week?
<seb128> I guess we should start getting those to saucy-proposed for SRU and build the image from there?
<ogra_> seb128, no idea, ask asac ?
<Laney> 'this'?
<didrocks> Laney: ubuntu-touch-meta
<apw> i thought it was a blanket feature freeze exception
<didrocks> I guess it's accepted
<apw> (for touch)
<ogra_> apw, well, everything needs to go through the spreadsheet for touch ...
<ogra_> apw, thats a way stricter process than a freeze
<apw> ogra_, i more meant, that is an exception for feature freeze, this is final freeze, a different freeze
<ogra_> apw, on -proposed  and release-team level it just goes through
<ogra_> ah
<zul> can an archive admin approve python-cinderclient and swift please
<zul> infinity: can you approve python-cinderclient and swift please?
<roaksoax> infinity: can you approve MAAS please?
<infinity> roaksoax: Did you read scrollback?
<infinity> roaksoax: When you filed that FFe a month and a half ago, was the intent really for it to cover every upload right up to final freeze?
<infinity> roaksoax: Cause this upload, despite its changelog claiming otherwise, is not a "bugfix release".  It's very featureful.
<roaksoax> infinity: yes! I had the understanding that the FFe was an standing FFe. maas-cluster-controller checks if apache2.2-common is present because we use maas against 2.2 and 2.4 (precise/saucy) and the module version needs to be rpesent in saucy (i got that from the debian migration notes for 2.2 to 2.4). And they are not really features, mostly bug fixes and improvements to what had already been uploaded
<roaksoax> smoser: thought the FFe for maas was an standing FFe... (so I was told)
<smoser> it largely was the intent of the ffe.
<roaksoax> infinity: ^^
<smoser> roaksoax, is there much that is not listed in that ffe that is feature?
<stgraber> probably best to ask slangasek then since he's the one who approved it
<smoser> i guess your moonshot work.
<stgraber> though "FFe granted for the changes described." doesn't really suggest an open FFe to me
<roaksoax> smoser: yeah i guess that's the only thing not really there,which is really hw enablement
<smoser> well, we can wait for slangasek, but my argument would be that the changes described there are now just landing
<roaksoax> smoser: yeah some of those granted on nFFe didn't land in the first upload
<slangasek> smoser: getting a feature freeze exception never implies "it's ok to upload this any time up until release".  It's meant to be understood that FFes are supposed to be acted on before beta freeze.  When roaksoax asked me about this upload last night, he said bugfixes, not new feature work
<infinity> roaksoax: I think my confusion was that you closed the FFe and then reused it, as if it were a standing exception.
<smoser> infinity, that confussion is quite reasonable.
<infinity> roaksoax: Either way, it's a far cry from "just bugfixes", but I can also sympathise that you don't want to ship with half-done features.
<smoser> ok...
<slangasek> so I would have to look closely at what's going on here, I'm not going to wave it through
<smoser> ok. so we need these changes in.
<smoser> what can we do to accomplish that.
<smoser> i do understand the confusion, pushback, and general "ITS 1 WEEK BEFORE RELEASE!"
<roaksoax> infinity: thank you! I also understand your frustation of me doing such an upload one week before release.
<roaksoax> but you are right, we don't want to ship with half-done features
<roaksoax> and some of those who were uploaded last night, where covered on the FFe that hadn't been uploaded in the first upload post requesting the FFe
<roaksoax> the only other new feature is moonshot stuff, which is hardware enablement that I just got tasked with by the end of last week
<didrocks> cjwatson: is britney down? it seems that last run was from Generated: 2013.10.10 13:55:26 +0000
<lool> Seems britney didn't run in an hour?
 * stgraber checks
<cjwatson>   File "/srv/ubuntu-archive/proposed-migration/code/b2/hints.py", line 69, in check
<cjwatson>     assert package.version is None, package
<cjwatson> AssertionError: eglibc/2.17-93ubuntu3
<stgraber> right
<cjwatson> I've fixed that block
<cjwatson> pretty sure they need to be unversioned
<stgraber> cjwatson: you're way too fast, I was just about to look at infinity's hint file ;)
<cjwatson> infinity: ^- FYI
<infinity> Oh, bah.
<infinity> Thanks for fixing.
<cjwatson> running p-m manually for you now
<smoser> hey...
<smoser> asking for pre-approval for uploading
<smoser> http://bazaar.launchpad.net/~smoser/simplestreams/trunk/revision/316
<smoser> oh well. to me it seems reasonable, there is a good positive and negative test included there. i'm gonna upload.
<roaksoax> slangasek: howdy! So I want to clarify a few things about the maas upload I did last night. This is the debdiff with what's currently on the archive with the package I uploaded yesterday. http://paste.ubuntu.com/6218653/
<roaksoax> slangasek: 1. the changelog that talks about the major new features is not for *this* particular upload/upstream release. It is simply the addition of the changelog with the new features that currently are in saucy.
<roaksoax> 2. the second major change is the new maas-import-ephemerals. In the newest upload, we simply replaced maas-import-ephemerals with maas-import-ephemerals.py (which is in archives) so there's really no change there, but rather we just renamed it and provided various bug fixes to it
<roaksoax> 3. the third major change is moonshot support, which is hardware enablement which I was tasked with just last week with the goal of having it released. Sorry for not including that in the FFe
<roaksoax> 4. other than that everything are bugfixes, including the changes to maas-import-ephemerals
<roaksoax> slangasek: so in reality, the only "new" feature in the last upload, is the moonshot stuff, everything else, are bugfixes
<slangasek> roaksoax: I haven't reviewed this at all yet, it's infinity who's said that the upload includes new features; I'll leave it to him to explain what he's seeing that constitutes feature work.  Maybe it's just the moonshot, I don't know.
<roaksoax> slangasek: alright! thanks!
<roaksoax> infinity: ^^ :)
<xnox> please reject gccxml i don't actually know if that works. Upload to archive by accident.
<roaksoax> thanks for the maas acceptance!
<balloons> how we looking for getting the rc images and milestone up and running ? :-)
<infinity> balloons: That'll be probably Sunday night.
<balloons> infinity, I thought we were good for today :-(
<balloons> I've been communicating that out; remember I wanted to ensure I gave people the proper timeline
<stgraber> that lxc fix (and a dbus change to follow in the next few minutes) are required to fix the desktop QA environment, would be nice if someone could review.
<infinity> Well, I'm sure stgraber can set up the milestone in the tracker for today, but I wouldn't count anything until Sundayish as an actual "RC".  That's not to say people shouldn't be testing now.
<stgraber> (I'll take care of the dbus review since I'm not the author)
<balloons> infinity, that's fair enough. If we're ok with migrating to an RC milestone today, that would be helpful.. Having people start now means a better image for sunday
<lool> infinity: FYI, Pete Woods and Ted Gould had tested new hud on desktop, and Pete Woods has now retested the new one in archive and it's all good!  They'll revert the useless bdep addition at some later point
<infinity> balloons: Agreed.
<infinity> stgraber: Can you set up the milestone in the tracker, so people feel comfy that they're testing the right thing over the weekend?
<infinity> balloons: I just sent the freeze announcement too.
<stgraber> infinity: sure, do you want all new builds redirected there already?
<stgraber> infinity: and do we actually do an RC milestone? last time we just went with Final as it was a huge mess to deal with RC => Final a few releases earlier (and confused people since we don't actually release an RC)
<infinity> stgraber: No, no RC milestone.  This is "RCs toward final", so Final it is.
<stgraber> ok
<infinity> stgraber: All new builds there is fine.  We won't bother de-cronning until the weekend, though.
<stgraber> infinity: ok, should I turn off e-mail+IRC notifications then?
<stgraber> until we de-cron that is
<infinity> It's not that much noise, but your call.
<infinity> Does the IRC notification also hit QA/testing channels, or just here?
<stgraber> also hits -testing
<infinity> If it hits QA channels, that might prompt people to test. :P
<infinity> I'm all for more testing.
<balloons> hehe
<stgraber> ok, I'll keep the notifications enabled, we can always silence them if it's a problem
<infinity> I look forward to xnox working 29 hour days for the next week to fix all the installer bug people should have found 3 months ago.
<infinity> s/bug/bugs/
<balloons> so people should anticipate new images into early next week before things really tighten down on respins, etc
<infinity> And I still have a few installer things on my plate to deal with before release too. :/
<infinity> But first, I need a nap (which is why I sent the announce 3h early).
<stgraber> infinity: does http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/37/manifest look vaguely correct to you? (since that's the list of builds that'll show up in the Final milestone)
<balloons> stgraber, I would note we need to remove Daviey and add jamespage in his place on the owners
<jamespage> balloons, please do
<jamespage> stgraber, please do
<jamespage> rather :-)
<infinity> stgraber: There's no more  armhf+armadaxp ... Hasn't been for a couple of releases.
<balloons> I don't want us both to edit it at the same time, so ;-) go for it
<stgraber> balloons: done
<stgraber> infinity: and I guess the two omap can die too, right?
<infinity> stgraber: omap == generic, and omap4 will be generic tonight or tomorrow, yeah.
<stgraber> infinity: right, do we actually have separate d-i images for those still or is that a generic d-i image too?
<infinity> stgraber: ubuntu-desktop armhf+omap4 is dead.
<infinity> stgraber: It'll all be one d-i target, though there are separate binaries with the uboot blobs wrapped around them.
<stgraber> infinity: ok, I'll just keep generic then, it's not like it actually matters anyway since it's not an iso
<infinity> (I'm also going to keep some symlinks in place so the maas people don't yell at me for moving things around at the last minute)
<infinity> stgraber: So, yeah.  desktop-armhf+omap4 goes away.  I'm not sure what will happen with server, I'll tell you later when I figure it out. :P
<infinity> stgraber: The rest looks good.
<stgraber> infinity: I guess the ubuntu server images should also get tweaked to be -generic instead of having both an omap and omap4 .img but I won't mess with that now
<infinity> stgraber: For a lark, if the bootstrap archive fills up completely with everything I need, I might hand-roll an arm64 ubuntu-core too. :)
<infinity> stgraber: No, the images need to have one for every target, because they include the bootloader blob. :/
<stgraber> infinity: that seems like a bit of a waste but ok ;)
<infinity> stgraber: So, we either drop arches (which I'd like to do, but that's the server team's call), or I make more than one.
<stgraber> infinity: I guess that's easier than to tell people to do offset dd with a separate .img for the bootloader ;)
<infinity> stgraber: Honestly, I'd prefer to drop all the armhf server images and just have netboot.
<infinity> stgraber: But, up to the server team.  I'll ask jamespage for an opinion when I'm awake.
<stgraber> (just noticed #ubuntu-testing is now #ubuntu-quality and queuebot didn't know about that)
<balloons> stgraber, oO
<balloons> stgraber, thanks for making the milestone. I'll share the news with everyone once the builds hit
<slangasek> would someone be willing to review the grub2 that cjwatson uploaded?  considering the actual changes are all mine, I probably shouldn't do the review :)
<slangasek> (and yes, I would rather like this into the candidate images, along with grub2-signed, since UEFI+LVM is currently broken in grub)
<stgraber> slangasek: I'll take care of it
<slangasek> stgraber: thanks!
<stgraber> slangasek: in exchange can I get you to review lxc? :)
<slangasek> stgraber: sure
<cyphermox> seb128: ^
<seb128> ^ would be nice to get that one it, it's an annoying issue with keyboard layouts, especially impacting non-latin users
<seb128> the fix is simple, it's to make the greeter codepath run only in the greeter
<seb128> e.g just a if() around some code
<seb128> cyphermox, thanks ;-)
<slangasek> ^^ please don't approve grub2-signed yet until grub2 has been accepted
<infinity> slangasek: Did you not set the build-dep on it?
<stgraber> slangasek: s/accepted/published/? because I accepted grub2 a few minutes ago
<infinity> Apparently not.
<slangasek> infinity: no, because it didn't get incremented last time either so I assumed we weren't doing that :)
<infinity> I do it, not everyone does. :P
<infinity> (Just lets it dep-wait nicely instead of having to wait for publishing and be sure)
<slangasek> yep
<infinity> Should probably mangle the packaging to work like the linux-signed packaging that looks for a specific version of the signed bits and fails hard when it doesn't find them, etc.
<infinity> Makes it somewhat idiot-proof.
<apw> plus we have an ./update-version ../linux incantation to do it for you
<knome> hey infinity, do you have a minute?
<shadeslayer> could someone accept kubuntu-meta ? has some fixes for non existent packages
<cyphermox> hey, would it be okay to upload a fix for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1238137 ? it's a minimal change and only affects touch, I already have the package ready and it was confirmed to fix the issue
<ubot2> Launchpad bug 1238137 in network-manager (Ubuntu) "Maguro: Network Manager is not reconnecting ofono's gprs connection after a cellular turn off" [High,Triaged]
<sil2100> didrocks: uh oh!
<didrocks> sil2100: hey (in a meeting) :)
<sil2100> didrocks: whaaaat? At this hour?!
<didrocks> sil2100: you are handling what's assigned to you? everything's fine?
<sil2100> didrocks: slowly, yes, HUD published, but in unapproved
<didrocks> sil2100: yeah, you were not in the end of the last meeting when I was aked to come :p
<sil2100> Looking for someone that could push it further ;)
<didrocks> sil2100: you need to bribe people!
<ogra_> sil2100, see /topic
<sil2100> FREE BEER! Anyone who pushes HUD from the queue gets free beer!
<didrocks> sil2100: maliit crash is under control?
<didrocks> sil2100: please, send to me and timo an email so that we can continue tomorrow morning
<didrocks> sil2100: robru as well
<sil2100> cjwatson: hello! Sorry to ask you for a second time, but can you push HUD further? ;)
<sil2100> didrocks: cyphermox was handling that from what I saw, let me take a look how it went
<stgraber> sil2100: accepted
<didrocks> sil2100: platform-api?
<cyphermox> sil2100: I didn't touch maliit..
<sil2100> stgraber: super awesome!
<didrocks> thanks stgraber
<sil2100> cyphermox: oh, I saw seb poke about that and you said you'll take care of that, but it seems you meant something else
<didrocks> sil2100: platform-api is in a good shape for landing?
<sil2100> cyphermox: I misread stuff then! Will tackle that later once I finish this here
<didrocks> sil2100: not wanting to harass you, but platform-api? (need an answering) :p
<didrocks> sil2100: you are handling that one + maliit then?
<sil2100> didrocks: yesss!
<didrocks> thanks!
<didrocks> sil2100: needing to go away, have a nice evening!
<didrocks> and good luck ;)
<sil2100> ;)!
<sil2100> Goodnight!
<didrocks> thanks!
<slangasek> cyphermox: that seems like an appropriate thing to get fixed, in terms of the bug impact; will have to review the patch once in the queue to say for sure
<slangasek> infinity: what's the timeline for starting to churn out candidate images?
<cyphermox> slangasek: ok
<slangasek> infinity, stgraber: do we want a proposed-migration added sometime soon, so that SRUs can be staged in -proposed without accidentally leaking across?
<slangasek> fyi, adding a block for libhybris gst-plugins-bad1.0 android, per discussion with rsalveti
<stgraber> I think your sentence above was missing a "block" but yeah, we probably should
<slangasek> yeah, it was ;)
<slangasek> according to the logs, for raring Colin added it on 4/22
<stgraber> what did we do last time? massive block?
<slangasek> that seems quite late to me
<slangasek> stgraber: no, 'block-all source'
<stgraber> if we do that we probably should also turn off auto-accept as otherwise we'll forget about those packages
<stgraber> it's reasonably easy to add stuff as unblock when accepting unseeded packages, but having to watch and manually check the proposed-migration list would be a pain
<slangasek> hmm.  I think we've given ourselves too many dials.
<stgraber> we'll have a late landing of dbus because of the ubuntu-touch testing madness. Sorry about that, the package has been ready and working for hours and doesn't even do any change that are touch-related.
<tyhicks> stgraber: will you be able to sponsor the debdiff as well? (I'm really sorry about all the time you've had to spend on this)
<stgraber> tyhicks: I'd rather not, if I sponsor it I'm not supposed to then accept it in the queue
<stgraber> tyhicks: and since there are more coredevs than release team member, it'd be more efficient for you to use another sponsor
<tyhicks> ok
<tyhicks> stgraber: kirkland will sponsor it for me once he takes a look at it and the AP tests finish running on your mako device
<stgraber> cool
<kirkland> stgraber: I'm looking at it now
<stgraber> my phone just finished reflashing today's image so I should have the results pretty quickly if I can get the damn thing to stay connected to the wifi for more than a minute (mako has the buggiest wifi driver I've ever seen)
<slangasek> stgraber: "doesn't even do any changes that are touch-related"?  so why is it landing at all?
<zul> slangasek:  can you ack python-cinderclient and swift when you get a chance please
<stgraber> slangasek: probably because tyhicks made the mistake of asking in ci-eng instead of just getting it uploaded to the archive
<slangasek> stgraber: that's not an answer to the question I asked
<slangasek> I asked "why is it landing", not "why is it late" :)
<stgraber> slangasek: do you mean, why do we want that in the archive?
<stgraber> slangasek: without that change dbus is busted in LXC and that prevents all of the desktop QA tests from running
<slangasek> only the desktop tests?  I thought there was discussion about unity8
<stgraber> that's unrelated, unity8 is failing because of Mir not because of dbus
<slangasek> ok
<stgraber> tyhicks: so all the webbrowser tests failed here, though I have no idea how they can ever succeed since apparently the app is called with invalid arguments
<tyhicks> ugh
<tyhicks> asac: is that expected ^
<stgraber> http://paste.ubuntu.com/6219840/
<stgraber> note how the app always complains about invalid options
<slangasek> zul: these are new upstream releases of components that don't appear to be listed in the micro-release exception; what's the justification for why these are safe and appropriate to include?
<slangasek> smoser, jamespage: ^^ the only bits of openstack that were mentioned to be missing from the MRE were ceilometer or heat; did you guys overlook some components?
<jamespage> slangasek, python-cinderclient would not fall under the MRE - its been approved under a FFe (see the changelog)
<jamespage> I thought swift already was
 * jamespage looks
<slangasek> ah, I see the FFe now; curse firefox for always opening the window on the *wrong* desktop
<jamespage> slangasek, but you are quite correct about swift...
 * jamespage sighs
<jamespage> they behave a bit differently upstream which is probably why - we don't get stable point releases from that project like we do the others
<slangasek> ok
<slangasek> that makes a new upstream RC the week before release rather worrisome to me
<slangasek> (python-cinderclient accepted, though)
<jamespage> slangasek, whats the best way to proceed with swift? we want to line up with what OpenStack havana is baselining against upstream
<jamespage> urgh - the timing on the releases sucks
<slangasek> jamespage: convince me that there's been rigorous testing to make up for the fact that this will have no burn-in time before release
<jamespage> slangasek, let me throw it somewhere and I'll give it a blast
<stgraber> tyhicks, asac: tried camera-app instead, that one looks sane:
<stgraber> Ran 11 tests in 45.055s
<stgraber> OK
<tyhicks> that's good
<tyhicks> anxious to hear about the expected results of the unity8
<stgraber> well, unity8 passed the tests on sf and failed as badly as it usually does on Mir, so no worse than before
<jdstrand> stgraber: thank you for doing that
<stgraber> tyhicks: anyway, wasted enough time over this, it's fairly clear to me that if we had a bug in that change, the phone wouldn't work at all, it does seem to work fine and the tests that aren't buggy appear to pass. I'll go do something more productive now and will do the queue review once it's uploaded.
<jdstrand> stgraber: yes. sorry about all that. your frustration is shared
<tyhicks> thanks for all your help, stgraber
* Laney changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: Frozen, final freeze | Saucy Salamander 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
<jdstrand> lovely
<asac> stgraber: webbrowser test should work
<asac> let me lok at your paste
<asac> stgraber: if camera is good i guess it fine.
<asac> webbrowser might need to unlock screen manuallyu frist
<jdstrand> stgraber: fyi, I got the ok to upload dbus
<asac> kk
<jdstrand> stgraber: I updated the landing page/etc with the testing
<jdstrand> stgraber: and uploaded just now
<stgraber> jdstrand: ok, I'll review it now
<stgraber> good, diff didn't change since I last reviewed, accepted
<jdstrand> stgraber: thanks!
<jamespage> slangasek, OK - so I've deployed 1.10.0 in our standard, 3 zone, 3 replica test deployment integrated into and openstack deployment via keystone
<jamespage> and I've run swift-bench against it which exercises object puts, gets and deletes on the deployment
<jamespage> all looks good; 0 failures on the 5 cycles of swift-bench I put the deployment through
<jamespage> zul, fyi ^^
<slangasek> jamespage: ok.  and those are the only things that we need to worry about testing?  There's a python-swiftclient in the archive; is there any risk that it will be broken by the update?  (not that this would strictly be a blocker anyway, since the new swift release is happening whether or not we include it in saucy and python-swiftclient ought be compatible :)
<jamespage> slangasek, fortunately swift-bench -> python-swiftclient -> swift HTTP api
<jamespage> so that test exercises the client as well
<slangasek> ok, great
<jamespage> slangasek, tbh of all of the openstack projects swift is the one I worry about least; its much more mature and generally moves at a slower pace
 * jamespage goes eod
<jamespage> until tomorrow folks
<slangasek> rightyo - accepted
<jamespage> slangasek, thanks1
<jamespage> I hate my shift key obviously
<jamespage> ttfn
<slangasek> cjwatson: why does click-dev depend on perl?  That's very unhelpful for a -dev package to do in multiarchland :)
<slangasek> cjwatson: dh_click itself seems to be perl-base-clean
<slangasek> cjwatson: or maybe click-dev should just be M-A: foreign, since it's Arch: any only "to avoid binNMU irritation"
#ubuntu-release 2013-10-11
<slangasek> ^^ this gets the cross-compiler in sync with gcc-4.7-source for release, which is probably a good idea; I actually want them in sync to try to pin down an issue where gcc-4.7 is reportedly behaving differently for certain code for native vs. cross building
<slangasek> (and the native compilation is giving buggy results, but that's beside the point... we don't know that the compiler itself is at fault)
<slangasek> oh, is the final freeze still advisory for universe? ok then
<darkxst> Is there some reason that there arent yet Ubuntu GNOME RC builds?
<infinity> darkxst: We created the milestone, and are just letting them cron in at their usual time.
<infinity> darkxst: Which for ubuntu-gnome, appears to be 15:32 UTC...  A bit of a wait.
<infinity> darkxst: I can do a manual spin for you, if you have confused testers.
<infinity> darkxst: Spinning you a set now.
<darkxst> infinity, thanks ;)
<ScottK> infinity: Thanks.
<infinity> Can someone do a quick review of that gdb upload I just made?
<slangasek> infinity: doh - right, I forgot about the efi binary new, didn't I
<slangasek> infinity: gdb> looking
<slangasek> or not
<infinity> slangasek: Does anything read /lib/init/fstab other than mountall, and ever before /etc/groups is available?
<slangasek> infinity: well, I had a conversation with stgraber and hallyn about possibly making lxc read it, but no.  Also, how can /etc/group ever not be available?  /etc must be on the rootfs
<infinity> slangasek: Well, it could be unavailable if something pulled that file and mountall into an initrd, for instance.
<infinity> slangasek: (Which doesn't ever happen currently, I assume?)
<infinity> slangasek: Anyhow, was just asking because of the "gid=tty" instead of "gid=5" in there, which would go awry if one couldn't resolve "tty" to anything useful.
<slangasek> infinity: yes, no mountall in initramfs
<infinity> I'm beggining to think maybe I should revert the pt_chown change for now.
<infinity> And maybe fix mount to add gid=5,mode=0620 to the "defaults" set.
<infinity> There's this curious feature where, even if your base system is booted and mounted correctly, if you "mount -t devpts devpts-foo foo/", all instanced of devpts (including the base system) pick up the new defaults.
<infinity> And lose the gid/mode bits.
<infinity> Which has always been true, but then pt_chown picked up the slack for this misconfiguration in the past.
<infinity> slangasek: On the other hand, Fedora already pushed this out as a security update a couple of months ago, and basically said "if stuff breaks, mount /dev/pts correctly, derp" in their announcement. :P
<didrocks> infinity: if you are still around, the mir one is for this touch image ^ (it's just a build-dep of xorg, but the fix is for touch only), not seeded anyway
<shadeslayer> stgraber: poke poke
<infinity> didrocks: I'm not here, and you can't prove it.
<infinity> didrocks: Oh, also: congrats.  Where was my invite? :)
<didrocks> infinity: ahah, thanks a lot! :-)
<ogra_> hey, i accidentially triggered an ubuntu-gnome build, hope i didnt cause havoc with this
<cjwatson> slangasek: Probably ought to be changed, yes.  Can you file a bug and I'll do it next cycle?  I don't think I should mess with it now for 13.10
<infinity> ogra_: They'll probably live.  There's going to be a cronned one today too, anyway.
<xnox> infinity: well i have two installer bugs fixed now, and if/when ubiquity upload will happen today. I'd love to respin all ubiquity images and test them before departing for the weekend.
<xnox> unless too late.
<infinity> xnox: Not too late.  I'm sure this won't be the last installed upload of the cycle (though one can always hope).
<infinity> s/installed/installer/
<infinity> xnox: The freeze pretty much explicitly doesn't apply to installers, since this is when we get all the good/juicy bugs.
<xnox> infinity: oh and base-files are not in yet, so yeah we will be respining =)
<infinity> Indeed, I'll upload that on the weekend, probably.
<infinity> Or maybe today sometime.
<infinity> Since I lost a bunch of my weekend to flying in the wrong direction.
<infinity> Silly timezones.
<Mirv> â and â indicators + unity stacks, fully tested on desktop, best autopilot results ever so seems pretty nice. indicators also tested on touch (manually) for the parts that are affected.
<Mirv> of course the best AP tests comes down to unity7 team fixing AP false alarms, but still, makes for nicer numbers
<mhr3> Mirv, so are there any issues with landing it?
<Mirv> mhr3: not that I know of, as mentioned good AP results, manual testing on touch fine.
<mhr3> Mirv, cool, pls ping me if there's any problem with it
<Mirv> mhr3: sure. if release team has any worries, they'll tell us here.
<asac> cjwatson: http://paste.ubuntu.com/6221814/
<asac> those are components that didnt make it it seems.
<asac> cjwatson: what are the options? what do you need from us?
<cjwatson> It was only 15 minutes ago :)  I'll review
<asac> cjwatson: ok cool. let me know. especially if we need to divert one of those to -updates or wait much longer
<asac> thanks
<cjwatson> (I'm mostly fixing a problem with the publisher right now, so if anyone else can help ...)
<asac> cjwatson: what kind of help? I assume that is "anyone from release team"?
<cjwatson> Yes
<cjwatson> asac: Is ido one of yours as well?
<asac> cjwatson: so thats all that is comnig from CI
<asac> we unfortunately have still desktop stuff in CI
<asac> fortunately actually, but in this case a bit awkward
<asac> asking didrocks
<seb128> ido has a desktop bug fix
<seb128> it doesn't impact touch
<asac> cjwatson: ido is also coming from CI, but its pure desktop only
<cjwatson> seb128: Do you know if the fix in ido affects anything in screenshots?
<cjwatson> It's fine otherwise
<seb128> cjwatson, it means the indicator-session avatar icon being properly aligned if you use a non default font size
<seb128> I doubt we have any screenshot of the bug
<cjwatson> Ah, so not screenshots
<asac> so yeah we missed ido
<seb128> means->makes
<seb128> asac, I'm glad you uploaded it :p
<seb128> that bugs annoys me ;-)
<seb128> asac, btw "unfortunately have still desktop stuff in CI" ... does it mean you plan to drop CI for desktop components?
<seb128> cjwatson, thanks
<Daviey>  /37
<cjwatson> asac,didrocks: all accepted now
<didrocks> cjwatson: thanks a lot :) one worrying things less :)
<asac> cjwatson: awesome!
<asac> what an amazing day
<asac> i will have to buy flowers for my wife still :P
 * asac puts that on his "nice to have TODO list" :)
<didrocks> asac: "nice to have" only?
<didrocks> I think qtdeclarative-opensource-src is unseeded, right?
 * didrocks checks
<cjwatson> can't be unseeded if it's in those packagesets
<cjwatson> but it looks fine, is it OK from the touch POV?
<didrocks> cjwatson: yeah, it's fixing the "unity8 is taking 100% of GPU" :)
<didrocks> CPU*
<didrocks> thanks colin!
<didrocks> ok, now touch-only uploads, all tested, fine, let's publish them
<asac> didrocks: yeah i should prioritze that more appropriately :)
<didrocks> heh
<cjwatson> infinity: Did you retry the failures due to lp-buildd vs. pt_chown?
<infinity> cjwatson: The one or two I knew about.  Were there many?
<cjwatson> I only knew of the ones you told me about :-)
<infinity> Fair.  I did those. :P
<Mirv> thanks seb128 cjwatson asac didrocks :)
<Mirv> I even got to eat proper food today, so I'm even more happy
<didrocks> Mirv: lucky you! :)
<seb128> Mirv, yw ;-)
<jamespage> openstack just pushed out a second rc for glance with a number of critical and high bug fixes - zul preparing and reviewing now
<zul> glance
<zul> oops
<didrocks> I think platform-api is what is freezing location-service ^
<xnox> ubiquity ^ diff will be large, but it's really one bugfix per commit on lp:ubiquity. Also note that majority of the diff is debconf-updatepo, which means unfortunately that many strings were not possible to translate up to now.
<shadeslayer> cjwatson: any reason why kubuntu-active ISO's aren't built?
<didrocks> (thanks to whoever accepted location-service ;))
<infinity> shadeslayer: I believe kubuntu-active was marked disabled in the ISO tracker, because someone didn't want them to be in milestones/release.  Has that position changed?
<infinity> shadeslayer: Active wasn't in any of the alphas or betas, only dailies.
<cjwatson> shadeslayer: check the build failures
<cjwatson> shadeslayer: it's been failing for a while
<shadeslayer> I don't know where :(
<cjwatson> I hadn't had a chance to look
<infinity> Oh, did you literally mean "not built" rather than "not posted to the tracker"?
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ somewhere
<shadeslayer> infinity: yes
<shadeslayer> ahhh
<shadeslayer> contour
<shadeslayer> cjwatson: infinity could you trigger a build now?
<shadeslayer> should be fixed
<cjwatson> as of when?  today?
<shadeslayer> I pushed fixes early today
<shadeslayer> https://launchpad.net/ubuntu/+source/plasma-mobile/1:0.5-0ubuntu2
<cjwatson> doing
<shadeslayer> thx
<infinity> I don't see how that would fix it.
<infinity> shadeslayer: If both contour and plasma-active are being installed, you've not improved the situation by adding an unversioned Breaks.
<shadeslayer> infinity: contour is no more
<shadeslayer> dropped it from the seed
<shadeslayer> removed from archive
<shadeslayer> https://launchpad.net/ubuntu/+source/kubuntu-meta/1.291
<shadeslayer> https://launchpad.net/ubuntu/+source/contour/+publishinghistory
<cjwatson> I guess we'll find out
<infinity> shadeslayer: Ahh, that was a bit more informative than the plasma-mobile link. ;)
<shadeslayer> :)
<shadeslayer> sorry about only providing half the info
<lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
<lool> (dobey is the uploader and has tested it "upstream" / in trunk)
<lool> (it's only seeded in touch)
<cjwatson> thanks
<xnox> stgraber: updating ubuntu-meta does "* Added shotwell to desktop-recommends [powerpc]" yet i was just removed "* Removed shotwell from desktop-recommends [powerpc]" by your last upload. is that correct?
<cjwatson> xnox: Looks like it was removed from powerpc at one point and then restored
<xnox> cjwatson: ok. uploaded.
<cjwatson> maybe?
<xnox> it's recommends and powerpc.... maybe it was removed/FTBFS at the time of last upload?!
<cjwatson> Yeah, https://launchpad.net/ubuntu/saucy/powerpc/shotwell, deleted from release entry #7
<xnox> cjwatson: otherwise it's a FTBFS fix.
<dbarth> hi
<lool> 17:36 -queuebot:#ubuntu-release- Unapproved: ubuntuone-credentials (saucy-proposed/universe) [13.10-0ubuntu1 => 13.10-0ubuntu2] (ubuntuone)
<lool> what does the ubuntuone package set mean?
<lool> does it have special rules for reviews or something?
<cjwatson> I think it's for upload perms
<dbarth> can i bring the case of bug #1206268 to your attention again
<ubot2> Launchpad bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,Fix committed] https://launchpad.net/bugs/1206268
<xnox> don't think so, just uploads perms & release-bug tracking / owners.
<mterry> Heyo folks!  There is a change that dbarth and folks would like to make to the ubuntu-sdk package.  ^ This would involve dropping a Recommends from that seed, and then changing qtmultimedia to stop building a certain package only referenced by the sdk metapackage.  How doable is that (we have branches, just looking for approval) at this stage?
<xnox> mterry: are all changes required reviewable somewhere? is it all the branches attached on the bug report?
<xnox> mterry: can you comment links with merge proposals against seeds and/or all packages involved?
<xnox> (comment on the bug that is)
<lool> stgraber: There might be some possible improvements to the autoaccept script if you like to: ubuntuone-credentials is only seeded in touch, but is stuck in queue because it's in a special upload packageset (ubuntuone)
<xnox> cause it's hard to see what the scope of changes is....
<mterry> xnox, sure.  let me link
<stgraber> lool: I'll whitelist that one
<dbarth> mterry: should Mirv also comment on the bug directly, with the plan he proposed earlier in the thread?
<lool> stgraber: thanks
<stgraber> lool: added to whitelist now
<ogra_> can someone please let livecd-rootfs through ?
<ogra_> (first is adding click packages to the manifest, second is a fix for a serious touch bug)
<mterry> dbarth, the plan is basically "land these three branches"
<stgraber> looking
<mterry> xnox, three branches added to bug in comments
<mterry> robru, ^ btw
<stgraber> ogra_: I'm a bit concerned by that manifest change, won't that break Ursinha's script and anything that expects packages listed in the manifest to be avaiable from the archive?
<ogra_> stgraber, it wont break my script, Ursinha's is still not merged afaik
<ogra_> stgraber, and jibel picks his data from my location
<ogra_> stgraber, in any case we need that info in the manifest
<stgraber> well, I'd argue we should have a separate manifest file for click
<ogra_> sure, we can do that later
<stgraber> cjwatson: I'd like your opinion on this if you have a minute?
<ogra_> stgraber, this is the quick variant to get it in before release
<ogra_> stgraber, i'l happily teach cdimage about a new file and how to publish it in T
<cjwatson> stgraber: I recommended the approach ogra_'s taken - I think manifest consumers should be prepared for the packages to be either .deb or .click
<dbarth> mterry: right
<cjwatson> If it breaks anything then surely it'll be straightforward to fix
<cjwatson> try: except:
<ogra_> the format is the exact same too
<stgraber> cjwatson: is there an easy way for something reading the manifest to determine whether it's a .deb or .click?
<ogra_> <pkgname> <version>
<cjwatson> stgraber: "does it exist in the archive as a .deb"
<cjwatson> I mean, it has to go looking for the changelog anyway, it can just check, no?
<ogra_> stgraber, most likely the namespace will be com.ubuntu.foo.bar.*
<cjwatson> ogra_: that's definitely not a reasonable thing to check for in the consumer
<cjwatson> if it would be helpful to prefix the package name with "click:" or something, that would be possible
<stgraber> sure, it's just going to be tricky to know whether something is a click package or a package coming from a PPA (even though we're not supposed to ever use PPA, the past as showed that we sometimes do)
<cjwatson> I dunno, I guess a separate file would be possible, I'd just like to avoid a proliferation of output files
<cjwatson> I think it's confusing
<ogra_> in any case a separate file is nothing for the week before release imho
<stgraber> I think I'd be fine with a click: prefix as it shouldn't break ogra_'s script and will let other parsers easily detect click and either act on it or ignore them
<ogra_> i dont want to do big plumbings in cdimage that close to release
<stgraber> xnox: do we really have to introduce a new string in ubiquity that close to release?
<stgraber> xnox: hmm, well, it doesn't really matter since none of the ubuntuone strings were translated anyway... I guess it's going to be one of those releases...
<xnox> stgraber: note that none of the other strings introduced this cycle in ubiquity didn't make it into .pot and were not translated due to not running debconf-updatepo this cycle at all. So in fact I am introducing new strings anyhow in that plugin.
<ogra_> stgraber, so do you let it in ? i urgently need the second fix
<ogra_> oh
<xnox> stgraber: it only affects ubuntu images, as nobody else seeded ubiquity-ubuntuone plugin.
 * ogra_ notes the mail
<ogra_> sigh
<stgraber> ogra_: I'll accept your /system/bin/sh change and reject the other
<ogra_> k, thanks :)
<xnox> stgraber: yeah, it is shame that translations will be bad..... (note U1 api only returns back errors in english =/ )
<stgraber> ogra_: hmm, actually I can't since you stacked the /bin/sh one on top of the manifest one... (I was hoping it was the other way around and I could simply pull the old one from the reject queue)
<stgraber> ogra_: if you re-upload adding a click: prefix to the manifest entries, I'll accept it. Alternatively, just upload the /bin/sh fix and I'll accept that.
<ogra_> ok that has to wait 1h then ...
<stgraber> ogra_: why?
 * ogra_ has meetings now 
<stgraber> ah ok
<ogra_> i'll re-work the click part ...
<ogra_> since we need that
<stgraber> thanks
<ogra_> (i doubt any of the scripts can handle columns in the package name though)
<stgraber> ogra_: ping me once it's back in the queue if I don't notice and I'll make sure it's reviewed quickly
<stgraber> ogra_: well, either they really care about the source name existing and they'll fail either way or they don't and a click: prefix won't make any difference
<cyphermox> ^ didrocks: signon-ui as requested
<stgraber> I'm reviewing it now
<cyphermox> stgraber: thanks
<ogra_> stgraber, cjwatson http://paste.ubuntu.com/6223092/ does that look ok to you ?
<alex-abreu> cyphermox, is the ball rolling for webbrowser-app ?
<stgraber> ogra_: did you mean "while read line"?
<cyphermox> alex-abreu: best I can tell you is it *did* for image 94, I don't know more
<ogra_> stgraber, not really, i tested that variant locally
<stgraber> ogra_: hmm, actually, both do the same, ignore me ;)
<ogra_> but i can tiurn it into a while loop :)
<stgraber> it's just the first time I see it done with for I believe ;)
<ogra_> stgraber, heh, now that i think about it, me too :P
<stgraber> ogra_: anyway, yes, that looks good to me
<ogra_> great, committing and uploading 2.194 then
<stgraber> ogra_: you know that you can just squash all the changes and upload 2.192 right? as none of those got accepted into the archive
<stgraber> cyphermox: are you familiar with the actual changes in that upload?
<ogra_> stgraber, i'm to lazy to roll back the bzr branch
<stgraber> ogra_: ok :)
<ogra_> its upstream committed
<ogra_> :)
<cyphermox> stgraber: I tested that you could still create accounts and such, and ran the autopilot tests
<stgraber> cyphermox: I'm not entirely confident that this is a bugfix only upload based on the wording of the changelog and the number of qml changes, does that upload cause any kind of user visible change?
<didrocks> thanks cyphermox!
<cyphermox> stgraber: not that I noticed
<cyphermox> didrocks: do you know more? ^
<stgraber> it's a bit hard to figure it out from the diff with all of those qml files being renamed/split/merged...
<stgraber> ogra_: just to confirm, that click change is in a touch specific section of auto/build, right?
<ogra_> stgraber, yep. ubuntu-touch and armhf even
<stgraber> ok, thanks
<stgraber> ogra_: there you go ^
 * ogra_ hugs stgraber 
<ogra_> thanks :)
<cjwatson> ogra_: "for line in read" runs the loop body once with $line set to "read"
<cjwatson> ogra_: that needs to be a while loop instead
<cjwatson> (I tested this ...)
<ogra_> cjwatson, eeek
<ogra_> will fix in a minute
<cjwatson> $ (echo foo; echo bar; echo baz) | for line in read; do echo $line; done
<cjwatson> read
<cjwatson> I would be very surprised if any POSIX shell did otherwise
<ogra_> http://paste.ubuntu.com/6223144/
<didrocks> stgraber: only on touch AFAIK
<didrocks> cyphermox: ^
<stgraber> ogra_: those don't look prefixed to me
<cjwatson> ogra_: that only works at all by sheer coincidence
<cjwatson> And indeed will never be prefixed
<ogra_> http://paste.ubuntu.com/6223153/
<cjwatson> ogra_: What that does is cause the shell to evaluate the output of "click list" as a file name, attempt to redirect stdin from it, and then emit an error message saying that that (ridiculous) file name doesn't exist
<cjwatson> ogra_: still broken
<cjwatson> ogra_: you need:
<stgraber> ogra_: FWIW I tend to prefer: Chroot chroot "click list | while read line; do ...; done
<cjwatson> Chroot chroot "click list" | while read line; do ...; done
<ogra_> ok
<cjwatson> And indeed your second version is broken for the same reason - <"$(...)" is basically nonsensical shell :)
<stgraber> right and cjwatson's will actually work since he didn't forget a " :)
<shadeslayer> cjwatson: ISO seems to have built \o/
<cjwatson> shadeslayer: cool
<ogra_> ok, final attempt http://paste.ubuntu.com/6223157/
<cjwatson> should work yes
<didrocks> thanks stgraber
<thostr_> we got a test failure on ppc https://launchpadlibrarian.net/153485520/buildlog_ubuntu-saucy-powerpc.mediascanner_0.3.93%2B13.10.20131011-0ubuntu1_FAILEDTOBUILD.txt.gz
<thostr_> however, mediascanner is currently not utilized by any desktop, it's only used for phone where it works
<thostr_> so, could we ignore the test error under those circumstances?
<cjwatson> We can remove the binaries on powerpc
<cjwatson> Sorting that out now
<cjwatson> It just needs unity-scope-mediascanner removed too
<thostr_> cjwatson: thanks
<cjwatson> done now pending the next publisher cycle
<stgraber> hmm, interesting, pre-release freeze isn't considered as development by Launchpad?
<stgraber> >>> list(lp.distributions['ubuntu'].getDevelopmentSeries())
<stgraber> []
<stgraber> (I noticed because I had to pass -s saucy to a few of our tools recently and finally got around to checking why)
<slangasek> stgraber: correct
<cjwatson> stgraber: .current_series
<cjwatson> stgraber: I fixed ubuntu-archive-tools for that fairly recently - you may want to update
<cjwatson> (r775 last week)
<stgraber> cjwatson: haha, I was indeed a bit behind on ubuntu-archive-tools! thanks for the fix
<xnox> looks like ubiquity 2.15.23 has landed, can we respin all ubiquity images?
<stgraber> we're still on cronned run
<xnox> stgraber: i know, but it has so many fixes and duplicate bugs are kept being filed.
<xnox> stgraber: can ubiquity images that have already been build today be respun? e.g. ubuntu-desktop at least?
<stgraber> xnox: ok, I'll trigger a rebuild of all images listed on the manifest
<xnox> stgraber: thanks.
<stgraber> done (selected all the desktop images listed under the Final milestone)
<rtg> infinity, re: bug #1236666 - should I request a sync ? get the source deb and upload manually, or go away and never mention it again ?
<ubot2> Launchpad bug 1236666 in msr-tools (Ubuntu) "[Feature] update msr-tools package to revision 1.3" [Low,New] https://launchpad.net/bugs/1236666
<mdeslaur> can I upload a fix for python-xlib? (LP: #1231453, and LP: #1221514). Looks like it's seeded on the edubuntu dvd.
<ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
<ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "duplicate for #1221514 get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
<mdeslaur> stgraber: ^
<infinity> rtg: Sell me on why we want a new version 6 days before release, and what it won't break.
<stgraber> mdeslaur: sounds reasonable
<mdeslaur> stgraber: thanks, uploaded
<rtg> infinity, why is msr-tools in main ? the new 1.3 version doesn't look like it has any compelling new features to warrant uploading right now. 14.04 ought to be soon enough.
<infinity> rtg: It's in main for cpu-checker
<infinity> rtg: Which, in turn, is in main for qemu.
<infinity> rtg: Which is in main because we hate our users and refuse to support Xen.
<infinity> QED.
<rtg> infinity, ok, I'll take option 3 (i.e., go away)
<infinity> rtg: Sure.  It's not modified in Ubuntu, so it'll autosync when we open 14.04.
<rtg> yep
<jdstrand> infinity: fyi, got approval from #ubuntu-ci-eng for the apparmor upload
<jdstrand> infinity: http://paste.ubuntu.com/6224151/
<jdstrand> $ apt-cache depends apparmor|grep python
<jdstrand>   Depends: python3
<jdstrand> before:
<jdstrand> $ apt-cache depends apparmor|grep python
<jdstrand>   Depends: python
<jdstrand> infinity: so, does your comment in #ubuntu-devel mean I can upload?
 * jdstrand uploads
<jdstrand> if there is a problem, reject it
<knome> hmph, apparently ubiquity slideshow translations weren't uploaded since a few weeks.
<stgraber> knome: hmm, that's unfortunate... let me do that quickly now
<knome> stgraber, cheers :)
<ScottK> jdstrand: Seems fine.
<stgraber> knome: uploaded
<ScottK> Oh, someone got it already.
<stgraber> yeah, I did
<jdstrand> stgraber, ScottK: thanks! :)
<stgraber> ^ that diff will likely be quite massive, it's a translation update from LP, so I'd recommend just checking that I'm not doing anything else :)
<knome> stgraber, thanks again! :)
<lool> hint-unblocked ubuntuone-credentials (touch only)
<slangasek> stgraber: diff looks fine, but is kind of late?  Why didn't the translation updates get done before final freeze?
<slangasek> and do we know for sure that we're having another set of images rolled, so that we should definitely accept this now?
<slangasek> lool: what unblocking is needed?  the fact that it's touch only means it should go through automatically, and anyway I don't see it uploaded
<lool> slangasek: just a followup to: 17:18 < lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
<slangasek> lool: ah
<lool> slangasek: I did my own blocking and unblocking basically, but wanted to keep the RT in the loop for hints
<slangasek> ack :)
<stgraber> slangasek: right, we apparently dropped the ball on that one and nobody updated the translations in weeks... knome noticed a bit earlier today
<slangasek> stgraber: so we're planning full ISO respins to pick this up?
<stgraber> slangasek: we're still running on cron at the moment and infinity is planning to turn off cron probably tomorrow/sunday
<slangasek> ok
<slangasek> accepting, then
<stgraber> thanks
<knome> slangasek, ta
#ubuntu-release 2013-10-12
<slangasek> ^^ systemtap is in core but not on any images, this is a safe change of a python dep to a python:any dep for cross-build support
<infinity> wgrant: Does graphicsmagick already build-dep on autotools-dev correctly?
<infinity> wgrant: Oh, I suppose it must have if it was copying config.sub by hand.
<wgrant> infinity: Yep, note how it used to symlink config.sub
<wgrant> It builds on amd64 now, at least.
<infinity> wgrant: Look at you, being all MOTU and uploadey.
<wgrant> It's been altogether too long.
<wgrant> Thanks
<ogra_> stgraber, is there any reason why system image was disabled in crontab ? we now have a half done touch image ...
 * ogra_ runs the system-image generator manually since people are waiting for tests since last night
<stgraber> ogra_, lool: oops, forgot to turn it back on. I had it disabled when I was creating saucy-surfaceflinger to avoid any image disappearing during the copy
<ogra_> ah, great
 * ogra_ thought it was just an oversight
<lool> stgraber: ah right, great
<cjwatson> webkit is the current blocker for a big build-dep chain on arm64, so a review would be good
<cjwatson> amazing how much stuff goes through browser engines
<slangasek> lookin'
<slangasek> accepted
<cjwatson> ta
<cjwatson> may need to run on birch, but I'll let it run on twombly for now
<slangasek> this does require a respin of the images
<slangasek> cjwatson: how much longer do you guys plan to continue making aarch64 changes for packages on the ISOs?
<cjwatson> the image cron jobs don't appear to be stopped yet
<slangasek> AIUI that's planned for today, right?
<cjwatson> not totally sure
<cjwatson> I thought I'd heard Monday at one point
<cjwatson> but CBW
<cjwatson> I'm not exactly sure - I guess we can stop when we need to stop but it'd be nice to be able to keep going over the rest of the weekend at least
<slangasek> ok
<cjwatson> however, with the exception of a kernel, I think we have most of a LAMP stack-type workload now
<slangasek> whoo
<cjwatson> And looks like the bootstrap archive is entirely superseded, I think
<slangasek> oh, nice
<slangasek> I did a spot check and saw 3000+ Arch: aarch64 binary packages the other day
<slangasek> not bad
<cjwatson> webkit is on the way round a ridiculously complicated set of intertwined cycles - if we could make it to the end of those and undo the hacks it would be nice
<cjwatson> but not the end of the world if we can't
<cjwatson> We've published 2097 arm64 builds (i.e. counted by source package) to the release pocket so far
<cjwatson> Probably ought to do something with the ubuntu-meta currently in -proposed - force the arm64 uninstallables, or drop it
<cjwatson> It actually probably ought to be refreshed since I bet the available set in minimal/standard has grown
 * cjwatson moves webkit/powerpc to sagari
<cjwatson> hm, I was going to add an arm64 build to ubuntu-core/saucy-, but we don't have a livefs builder for it
<cjwatson> shame we haven't had time to start doing that in LP yet
<doko> slangasek, infinity wrote in his email Sun evening
<slangasek> ok
<infinity> cjwatson: I'll do ubuntu-core/saucy when I get to London.
<yofel> could someone please accept digikam? It's the previous upload done right
<infinity> yofel: Done.
<yofel> thanks!
<cjwatson> infinity: What builder were you planning to use for it?
<cjwatson> I mean, I assume we don't want to do it just as a one-off
<infinity> cjwatson: I had originally planned to do it as a one-off, but adding a livefs setup to one of the boards would be trivial.
<infinity> cjwatson: And I was going to suggest birch, until it started acting up an hour ago...
<cjwatson> I guess we'll see if that carries on or if it's just having a bad night
<wgrant> Well, the old boards haven't ever died during build-dep install...
<wgrant> So a one of the old two, or even a revived old-birch could work.
 * infinity nods.
#ubuntu-release 2013-10-13
<wgrant> bah
<wgrant> slangasek: could you approve boost-mpi-source1.53?
<slangasek> wgrant: done
<wgrant> thanks
<doko_> please have a look at these two, m2crypto fixes a ftbfs on all archs, qt4-x11 is arm64 only
<jamespage> thanks to whomever accepted the openstack uploads in the last 24hrs - much appreciated
<infinity> jamespage: That was me.  Is the plan to 0day (ish) SRU the final release, or is there some vain hope it'll actually be out before final images spin? :P
<jamespage> infinity, 0-day sru most likely
<jamespage> bug 1236462
<ubot2> Launchpad bug 1236462 in swift (Ubuntu) "[SRU] update openstack packages to 2013.2 release tarballs" [Medium,Confirmed] https://launchpad.net/bugs/1236462
<cjwatson> infinity: ^- try that one
<infinity> cjwatson: That looks more plausible.
<Daviey> cjwatson: Are your partman-* precise SRU's in queue delayed for any reason, or are they straight forward uploads that can be processed ?
<micahg> infinity: will seeded uploads with dh_autotools-dev enabled still be accepted?
<xnox> micahg: yes.
<xnox> micahg: required for arm64 port enablement, as per infinity's final freeze email.
<micahg> I saw, but it's Sunday night :)
#ubuntu-release 2014-10-06
<jamespage> Laney, gah - looking
<jamespage> Laney, swift re-uploaded with out of VCS changes re-instated - nice catch!
<Laney> jamespage: thanks
<mlankhorst> can someone accept mesa-lts-trusty? mesa in trusty already has that version in -proposed
<jamespage> Laney, can you see reject reasons that the release team made?  I'm trying to sweep up the last rc for openstack (ceilometer) but I see it was rejected last week and neither zul or coreycb are up yet
<Laney> jamespage: nope, they only get emailed to the uploader
<jamespage> Laney, gah!
<jamespage> :-(
<Laney> jamespage: however that might have been me asking for FFe for the IPMI agent
<Laney> bug #1377218
<ubot2> bug 1377218 in ceilometer (Ubuntu) "[FFe] ceilometer 2014.2.rc1" [Undecided,Invalid] https://launchpad.net/bugs/1377218
<Laney> I didn't get to review that yet
<jamespage> Laney, I thought it might have been
<jamespage> Laney, let me complete that
<jamespage> Laney, there was some confusion last week - that's prob my fault
<jamespage> (no-one actually told me the release team asked for a FFe so I got coreycb to drop it)
<Laney> no harm done
<Laney> Will poke today if I'm not beaten
<jamespage> Laney, thanks - just reading it now
<jamespage> ^^ that point release is needed for the horizon
<dbarth> for note: signon and accounts-qml-module above have a packaging change ^^
<barry> Laney: btw i think you're on the release team.  could you have a quick look at LP: #1376736
<ubot2> Launchpad bug 1376736 in pycurl (Ubuntu) "[FFe] update to pycurl 7.19.5" [High,New] https://launchpad.net/bugs/1376736
<Laney> barry: in a bit, doing a couple of uploads first
<barry> Laney: np, and thanks!
<infinity> barry: I'd recommend soliciting ScottK's input, as he's more in touch with pythony things in general.
<infinity> (unless the FFe is a no-brainer slam dunk that any monkey could process with minimal fuss, I haven't looked)
<barry> infinity: it's probably just a bit more than obvious, so ScottK would be a good second set of eys
<barry> *eyes
<infinity> ScottK: ^-- Care to have a poke at barry's FFe above, if you have time?
<pfsmorigo> cjwatson, infinity: hi, we find an problem in the installer. it seems that if you format the disk before install ubuntu in it, grub-install will fail
<pfsmorigo> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1376973
<ubot2> Launchpad bug 1376973 in debian-installer (Ubuntu) "ppc64el: The 'grub-ieee1275' package failed to install" [Undecided,New]
<pfsmorigo> *a problem
<pfsmorigo> like  do a "mkfs.ext4 -F disk1.raw" before install ubuntu
<pfsmorigo> (I know that this command doens't make sense but cause the bug)
<cjwatson> Thanks, I'll look at that
<pfsmorigo> cjwatson: I just got a report that installing ubuntu on a powervm are having a similar problem. maybe it's the same cause
<cjwatson> pfsmorigo: no need for further information, have fixed
<pfsmorigo> cjwatson: what was the cause?
<cjwatson> pfsmorigo: wiping the bootdev needs to be done earlier now that grub-ieee1275.postinst runs grub-install
<cjwatson> oh, hm, my fix is buggy though now I think of it.  anyway leave it with me.  OT for this channel anyhow :)
<pfsmorigo> cjwatson: ok
<smb> repeating myself from ubuntu-devel: Can someone check the xen package in Utopic. Somehow the publishing history claims it should be moved to release but its not there (xen-4.4.0-0ubuntu8)
<cjwatson> the copy failed, probably because of a librarian snafr
<cjwatson> snafu
<cjwatson> this isn't the first, so rather than me fixing it straight away I'm going to see if I can scan for it
<smb> cjwatson, Ok. I suppose as I still have the source of that, it will be ok to base another upload on that and proceed from there
<cjwatson> cjwatson@carob:/srv/launchpad.net-logs/production/ackee/launchpad$ zcat celeryd-production_launchpad_job.log-20141002.gz | grep --count OOPS
<cjwatson> 13
<cjwatson> smb: can you let me fix it first just in case of confusion?
<smb> yeah, sure.... it is beer time anyway, so I can wait
<cjwatson> I shouldn't expect it'll take me too long
<cjwatson> But happy beering
<smb> cheers
<smb> :)
<cjwatson> smb: OK, fixed.  Five of the seven affected copies (python-oslo.vmware utopic-proposed -> utopic, lucid-{,meta-}ec2 PPA -> lucid-proposed, lucid-{,meta-}lowlatency PPA -> precise-proposed) had already been retried and had succeeded.  I've just retried the remaining two (pythonmagick/ppc64el utopic-proposed -> utopic, xen utopic-proposed -> utopic) and they've succeeded.
<cjwatson> The remaining six OOPSes from the log were merge review e-mails which I'm going to continue happily ignoring.
<smb> cjwatson, Heh ok, I can happily live with that :) thanks
<dobey> anyone can approve the FFe for https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1368252 please?
<ubot2> Launchpad bug 1368252 in unity-scope-click (Ubuntu) "[FFe] Repetitious language during uninstallation of Apps" [High,In progress]
<hallyn> ok so back to the FFE for bug 1374617 - wahtever solution we come up with for qemu/libvirt (for precise->trusty migration) we'll need this.  AFAIK there's no other route we'd want to take.  Can we start with the FFE for that and then go back to qemu? (libvirt patch being only for trusty so an sru not ffe matter)
<ubot2> bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,Confirmed] https://launchpad.net/bugs/1374617
<infinity> hallyn: Did we ever discuss how long we'd have to carry this ipxe-precise?
<infinity> hallyn: Like, at what point do we say "sucks to be you" and stop supporting pc-1.0-precise?
<infinity> hallyn: I would have assumed that point would be "post-trusty", which makes this not an FFe issue at all.
<hallyn> infinity: i would think the 'at some point' would be after precise is EOL.  (or never)  now, we *could* be harsher and say "you must migrate to trusty,and then you must change the machine type"
<hallyn> i find it rather hard to believe someone would need their machine to be around un-rebooted from 12.04 .. 16.04...  but ppl are whacky
<hallyn> but, if we were to not have it in utopic, then we wouldn't need the pc-1.0-qemu-kvm machine type in utopic either (that is, we *could* not have it as it requires the roms)
<hallyn> so then we don't need ffe for any of this, just SRU
<infinity> dobey: I'm not sure I agree with the departure from other UI bits to use Confirm/Cancel instead of Yes/No just because of the preference for verbs, but it seems a no-brainer otherwise.
<infinity> hallyn: Right, that's what I was driving at.  We don't support upgrades that skip LTSes.
<hallyn> infinity: but no this wouldn't e skipping LTSes
<infinity> hallyn: So, if we don't plan to support pc-1.0-precise $forever, we should draw the line earlier than later, IMO.
<dobey> infinity: i've yet to actually see a yes/no anywhere, and it's a time-tested bad practice of UI to do that (so not sure why anything else would use it, but i don't want to spend rest of my life trying to convince a designer of anything)
<hallyn> after you migrate pc-1.0 from p->t, it remains pc-1.0;  so you'd still need pc-1.0 in 16.04 if you're going to migrate it, unless you shut it down, convert the xml, and restart it as a new mt (potentially losing driver support)
<infinity> dobey: I was just going by the bug comments, to be fair, not an specific experience.
<infinity> s/an/any/
<hallyn> infinity: but i do like the idea of saying "after trusty you're out of luck"
<dobey> infinity: yeah, i gathered as much. :)
<infinity> dobey: Anyhow, FFe seems sane and reasonable, go for it.  Will this be translated to any meaningful degree by release?
<dobey> and whee, now lp is not bing responsive
<dobey> infinity: yes, should already be translated as it's landed into rtm already
<infinity> dobey: Shiny.
<dobey> just waiting to get the +1 comment on the bug from one of you release teamers, so i can poke the CI train machinery to get it merged to utopic
<infinity> dobey: Oh man, I have to comment myself now, you can't copy and paste and let me be lazy? :)
<infinity> dobey: Done.
<dobey> thanks :)
<hallyn> infinity: ok, gonna think a bit longer about downsides, but i sure like the idea of dropping the FFE and just doing this only for trusty
<infinity> Well, the obvious downside is that people would need to actually migrate after upgrading to trusty.  But I don't think it's reasonable to carry an old version of a package forever to avoid that.
<infinity> hallyn: The other way out of this mess is to have some clever upgrade scripts copy the old ipxe binaries to /var/lib/qemu/randomjunk and treat them as payload data for eternity.
<infinity> hallyn: But that doesn't help people who upgraded from precise to trusty and are currently broken. :/
<infinity> (Though, I assume those people have already found a manual way out)
<hallyn> infinity: of course one OTHER possibility (which i don't like) is to say "ppa:serge-hallyn/qemu-migration can be used to migrate p->t;  otherwise, unsupported"
<infinity> hallyn: I'm not fond of any out-of-archive solution to upgrade problems.
<infinity> hallyn: But I do also wonder how many people with this problem haven't already upgraded.
<infinity> hallyn: As in, are we trying to fix something that 99% of those affected have already worked around?
<hallyn> infinity: i actually don't think so;  i suspect there are plenty of ppl who have not yet updated (or at leas tnot yet completed update) to 14.04;  they're waiting for 14.04.2 or whatever so they can feel safer
<infinity> hallyn: 14.04.1 is our usual "safe upgrade" point.
<infinity> hallyn: But sure, there are always the people who wait a year or two.
<infinity> hallyn: Just wonder how those people intersect with people who migrate VMs.
<infinity> Since VMy people are usually all cutting edge ra ra, latest tech, etc.
<infinity> hallyn: Anyhow, probably not worth playing the what-if game, if it's trivial to sihp the binary in trusty and just be done with it.
<infinity> hallyn: But I don't think it's a solution we want to support into post-trusty releases.
<hallyn> ok.  How do I mark that in the bugs (for qemu and ipxe-precise), mark it wontfix for utopic and seek SRU?
<infinity> hallyn: People already need to do manual things to make this work, so if the documentation for those manual things also says "and you can't migrate past trusty without ditching the pc-1.0-precise machine type", that's not a big deal, IMO.
<infinity> hallyn: If this was all automatic, I might be looking for more clever here, but since it's all manual ANYWAY, supporting it for post-trusty is just creating work we don't need.
<hallyn> are there release notdes for point releases (or whatever '14.04.2' is called)?
<infinity> hallyn: Yeah, there are point release release notes.  I'm not convinced anyone reads them, but we write them.
<hallyn> hah.  more popular than manpages
<infinity> hallyn: The trusty release notes are a living document anyway, if you get this stuff in, you can amend the release notes as they are now, no need to wait for .2
<hallyn> infinity: ok, thanks.
<infinity> hallyn: And yeah, for the bug(s), summarize this discussion to some extent and mark utopic wontfix.
<infinity> hallyn: As for the SRUs, I don't think there's anything to "seek approval for" here, we've discussed it ad nauseum, upload something to get it reviewed.
<infinity> hallyn: This all needs to be redundantly documented all over the effin' place, so I expect some decent README in /usr/share/doc, or maybe even a NEWS.Debian that apt-listchanges helpfully displays, plus release notes, plus blog vomit when it lands in updates, etc.
<infinity> hallyn: Cause if people don't know about it, you've wasted your time implementing something no one will use.
<gaughen> slangasek, infinity - could I get one of you to give some love to the maas related ffes - https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1370628 and https://bugs.launchpad.net/ubuntu/+source/psycopg2/+bug/1366104  pretty please?
<ubot2> Launchpad bug 1370628 in maas (Ubuntu) "[FFe] MAAS New 1.7 Upstream Release" [Undecided,New]
<ubot2> Launchpad bug 1366104 in psycopg2 (Ubuntu) "[FFe] OperationError when large object greater than 2gb" [Wishlist,New]
<infinity> gaughen: Oh, Steve and I had a talk this morning and decided to remove MaaS from the archive.  I thought you knew?
<gaughen> infinity, I can believe that you two possibly talked about it. I'm hoping that slangasek thought he just being funny.
<gaughen> sorry, please insert the missing "was"
<infinity> gaughen: Yeah, so we didn't actually discuss that at all.
<gaughen> infinity, it was just a discussion in your own head?
<infinity> gaughen: That said, ScottK had some serious concerns about the psycopg2 FFe.
<infinity> gaughen: And none of that seems addressed.
<infinity> gaughen: This also flies in the face of the "no requirements for features not in trusty" thing that was promised by the MaaS team to stgraber and I.
 * gaughen hangs head in shame. 
<infinity> gaughen: Which was part of the commitment to make MaaS SRUable to trusty without altering deps.
<gaughen> I should have read that psycopg2 one first
#ubuntu-release 2014-10-07
<oSoMoN> could someone take a look at signon in the unapproved queue please? itâs holding off other landings
<jamespage> please could a release team member take a look at bug 1377218
<ubot2> bug 1377218 in ceilometer (Ubuntu) "[FFe] ceilometer 2014.2.rc1" [High,New] https://launchpad.net/bugs/1377218
<jamespage> I'd like to get that into the review queue today if possible please
<dbarth> hi; can you inspect the signon package which is currently in the unapproved queue? it's coming from a phone ci landing; thanks
<mlankhorst> can someone accept mesa? contains some fixes for mir
<hallyn> arges: hey, just a note, the fix for bug 1374617 is required for the test cases for bugs 1374622 and 1374612
<ubot2> bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,Confirmed] https://launchpad.net/bugs/1374617
<ubot2> bug 1374622 in libvirt (Ubuntu Trusty) "Support migration from 12.04" [High,Fix committed] https://launchpad.net/bugs/1374622
<ubot2> bug 1374612 in qemu (Ubuntu Precise) "[FFE] add pc-1.0-precise machine type" [High,Confirmed] https://launchpad.net/bugs/1374612
<arges> hallyn: did you upload the ipxe fix yet?
<hallyn> arges: I thought i did.
<arges> hallyn: ah its in the NEW queeu
<arges> queue
<hallyn> yup.  if that needs more time i can do the verificatoins with the pkgs out of ppa, but that feels like cheating :)
<arges> hallyn: you should ping an AA about approving that package. cjwatson / infinity ^^^ ipxe-precise in trusty/new queue
<hallyn> arges: oh, ok, thanks.  infinity: the ipxe-precise is the last bit for the p->t qemu vm migration drama
<dbarth> hi again; this is a quick nudge to ask for attention on the 'signon' package in the unapproved queue
<Riddell> dbarth: any bug number or other pointer to why it'll fix more problems than it'll add?
<cjwatson> sorry
<dbarth> Riddell: not really; the change is here and is meant to secure access from client apps better
<dbarth> Riddell: https://code.launchpad.net/~online-accounts/signon/packaging/+merge/237211
<dbarth> i guess i can ask mardy to comment on the original merge prop. to make a stronger case for it not creating compatibility issues for example
<infinity> hallyn: That s/ppc/ppc64/ thinko in your qemu changelog scared me.
<hallyn> infinity: well it was overly conservative, not overly liberal :)
<hallyn> was going to refuse running ppc64el-user under ppc64
<infinity> hallyn: No, no.  The typo.  Where you said you removed "Support-ppc64le.patch"
<infinity> hallyn: You meant ppcle.
<hallyn> oh
<hallyn> feh, yeah
<hallyn> those machine names are getting almost as nnoying as arm64/amd64
<infinity> *smirk*
<hallyn> i keep d/ling the wrong rootfs's now, thanks to arm64
<infinity> Anyhow, I suspect IBM (and others) will push back hard against people doing 32-bit LE or, at least, make sure they do it right, so dropping the premature support seems sane.
<infinity> hallyn: For your peace of mind, though, I can confirm that the be/le changes you just made are also correct.
<infinity> hallyn: ppc kernels are endian-specific, so running le on be or be on le isn't native.
<hallyn> infinity: ok, thx.  (slangasek had also confirmed it on #debian-qemu)
<infinity> hallyn: Check.
<hallyn> as for the 32-bit le, i figured better to drop it before release
<infinity> hallyn: I've praised IBM repeatedly for doing the right thing there.  They debated (for a long time) doing endian-neutral kernels with duplicated syscall tables, and I'm so glad they didn't.  It's a maintenance nightmare.
<infinity> (See x86/x86_64/x32, or the horror that is mips)
<slangasek> the thing that goes mips in the night
<slangasek> the x86 model is wrong, the syscalls should be associated with different kernel personalities
<hallyn> wouldn't that remove our compat syscall exploit fun?
<infinity> slangasek: Don't even get me started on personalities, and their completely inconsistent application across architectures.
<slangasek> ok then I won't
<infinity> slangasek: I feel strongly that's something someone should fix, but I also suspect it would require inventing a time machine.
<slangasek> also: ICBS
<slangasek> (which I'm pretty sure stood for intercontinental bowel syndrome?)
<infinity> Inter-Continental Ballistic Suck?
<slangasek> http://www.linuxmisc.com/1-linux-setup/f2cd5ed0c51dd5d6.htm
<mlankhorst> dat stoppen. Hieronder leest u hoe u dat kunt doen.
<mlankhorst> Hoe herken ik geadresseerde reclame?
<mlankhorst> oops
<infinity> I'm not going to bother translating that, and just assume it was erotic.
<infinity> Oh dear.  I went and translated it anyway, and the first line is so much better after my comment.
<YokoZar> Could someone on the release team please manually approve Wine1.6 for promotion for me?  Britney gets confused because the amd64 version has a cross-arch dependency.
<infinity> YokoZar: Oh, let me have a look.
<YokoZar> infinity: Thank you :)
<infinity> YokoZar: Fix committed, should migrate in the next run, if nothing else is broken.
<YokoZar> infinity: Excellent, thanks.  Will I need to do this every upload?
<infinity> YokoZar: Until we come up with a better way to figure this out, yeah.  A ping wouldn't hurt.
<hallyn> arges: infinity: so I went ahead and did the upgrade tests for qemu/qemu-kvm (and about to for libvirt) using the kvm-ipxe-precise from ppa.  still do need the ipxe-precise package in trusty to really call it fixed though.  (though the situation without that is no worse than the situation without these current qemu+libvirt packages, so technically they don't have to be blocked by it)
 * hallyn waiting on two parallel long-asse qa-regression-tests on his laptop
<arges> hallyn: cool
#ubuntu-release 2014-10-08
 * infinity self-accepts his libd-i 1-liner.
<tseliot> hi, can an admin please reject fglrx-installer-updates from precise-proposed?
<dbarth> Riddell: hey Jonathan, mardy file https://launchpad.net/bugs/1378660 to clarify the purpose of the signon changes from yesterday
<ubot2> Launchpad bug 1378660 in signon (Ubuntu) "Notification appears when applications need to be (re-)authorized" [Undecided,In progress]
<dbarth> or anyone in the release team willing to approve the signon package upload in the unapproved queue
<dbarth> thanks
<Riddell> dbarth: accepted, thanks for the extra info
<Riddell> dbarth: this is surprising given the qt build-deps :) "Section: gnome"
<tseliot> Riddell: can you reject fglrx-installer-updates from precise-proposed, please?
 * Riddell looks
<Riddell> tseliot: rejected!
<tseliot> Riddell: thanks a lot :)
<dbarth> Riddell: thank you
<cjwatson> infinity: nice catch on libd-i.  did you send that to Debian too?
<cjwatson> suspect they'd want it
<jamespage> Laney, could you take a peek at https://bugs.launchpad.net/ubuntu/+source/ceilometer/+bug/1377218
<ubot2> Launchpad bug 1377218 in ceilometer (Ubuntu) "[FFe] ceilometer 2014.2.rc1" [High,New]
<jamespage> and that would be for rc2 now; upstream just popped a new one with some fixes
<Riddell> any ubuntu-sru people around able to give a second opinion on bug 1378789 ?
<ubot2> bug 1378789 in kubuntu-settings (Ubuntu Trusty) "[SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty" [Undecided,New] https://launchpad.net/bugs/1378789
<Riddell> we want to sru the change in schduler back to linux defaults to keep baloo indexer working
 * Riddell eyes up stgraber as a desktop minded sru member â
<ogra_> stgraber, something is wrong with system-image mirroring to the external server ...
<ogra_> stgraber, i see a krillin 91 image in www/full/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/ ... since quite a while ... but http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/ doesnt seem to get it
<ogra_> stgraber, i even ran sync-mirrors manually on nusakan (assuming thats what s-i does as well) but with no result
<infinity> rtg: The latest linux-firmware doesn't appear to contain the fix for LP: #1378491
<ubot2> Launchpad bug 1378491 in linux (Ubuntu Utopic) "Utopic netboot initrd missing bnx2x firmware" [Undecided,Fix committed] https://launchpad.net/bugs/1378491
<infinity> rtg: What gives? :)
<rtg> infinity, it was a kernel fix, which I have not uploaded yet.
<rtg> bnx2x is boot essential, so it gets packaged with the kernel.
<infinity> rtg: Oh, err.  Really?  But nic-firmware.udeb comes from linux-firmware.  Is this particular one in kernel-image.udeb?
<infinity> rtg: Check, okay.
<infinity> slangasek: ^-- kernel fix, not l-f fix, will get done in the usual d-i respin for the new kernel.
<rtg> infinity, I'll likely wrap it up and upload later tonight, or tomorrow. I did update the LP bug
<infinity> rtg: Yeah, I missed that it was assigned to linux, cause someone implied it was l-f, not naming any names. :)
<infinity> rtg: I guess maybe we need some machinery to check linux-image.deb and kernel-image.udeb for firmware inconsistencies and bail?  If the argument for firmware in linux-image is that it's "boot essential", I can't see how that would be any less valid for the installer package.
<rtg> infinity, put that on your list of things to talk to me about next week. I have some questions about how we're doing that kind of firmware, but I'm in a class right now and kind of distracted.
<infinity> rtg: *nod*
<infinity> rtg: Oh, I guess my consistency check wouldn't help here, as that firmware wasn't in either package. :P
<infinity> And perhaps you're already doing the right thing and installing the same firmware to both packages.
<rtg> infinity, nope, it was only in linux-firmware
<infinity> At least, I hope you are, cause this commit doesn't seem to have anything udeb-specific.
<rtg> infinity, yup, its in both now, but I'd like to fix that.
<infinity> rtg: Sorry, I meant "both" as in linux-image and kernel-image, not talking about linux-firmware at all.
<infinity> rtg: As in, I assume/hope that all firmware in linux-image.deb is also in the kernel-image.udeb
<rtg> yes (IIRC). I'll check for sure later, but I think our packaging is consistent
<infinity> rtg: Oh, hrm.  No, looking at the packaging, this probably should be in nic-modules.udeb, which is defined at tree/debian.master/d-i/firmware/nic-modules
<infinity> rtg: So that goes back to the consistency check arguments, I guess.  We should ensure that the intersection of kernel-image, nic-modules, and scsi-modules contains the same firmware as linux-image+linux-image-extra.
<infinity> rtg: Anyhow, this bug (which was agaisnt d-i) won't be fixed by your commit, as I read this.  I think.
<rtg> infinity, my patch is consistent with previous bnx2x firmware packaging. I'm pretty sure it'll fix the netboot issue.
<infinity> rtg: Previous bnx firmware is listed in the file I pointed out.
<slangasek> infinity: ah oops yes, I knew that and misspoke
<infinity> cjwatson: Haven't committed that to Debian yet, as I wanted to actually do an end-to-end test and see what else is broken. :P
<infinity> cjwatson: Which is somewhat hampered by the utopic kernel bumping off my test machine fairly reliably.
<sil2100> slangasek: hey, do you know why the release of indicator-network for utopic that we just triggered through the train got put into the unapproved queue?
<sil2100> slangasek: common sense told me indicator-network is not touch-specific, but I see it in my FFe I filled in
<sil2100> slangasek: which means it has to be touch-specific
<slangasek> sil2100: everything goes in the unapproved queue, some things are just supposed to be let back out again semi-automatically
<slangasek> sil2100: indicator-network is only in ubuntu-desktop-next and ubuntu-touch, so it's ok to unblock; but if things are getting stuck in the unapproved queue when they shouldn't, I think that's a question for #ubuntu-release
<slangasek> oh, we're on that channel
<slangasek> I think it's a question for infinity or stgraber ;)
<sil2100> Yeah ;)
<sil2100> infinity: ^ can you help here?
<slangasek> sil2100: ^^ accepted in the meantime
<sil2100> Thanks!
<slangasek> but the underlying "why'd it stick" should be looked at
<infinity> The python script that does auto-accepts is a bit dumb, IIRC, and only looks at the moral equivalent of "seeded-in-ubuntu" without actually checking which seeds/packagesets something is in.
<infinity> We should probably make it smarter, but also entirely reasonable to just give us a poke with "hey, this is only in touch, can you let it through?"
<infinity> sil2100: ^
<Laney> It has a whitelist
<infinity> Oh, so it does.
<infinity> Hrm.
<infinity> Clearly, that's not working right. :P
<infinity> slangasek: Did you just accept everything in that state? :/
 * infinity was hoping for something in the queue he could manually run against.
<Laney> It'll be because it's in the ubuntu-desktop packageset
<sil2100> infinity: ok, thanks :)
<infinity> Laney: Ahh, that would perhaps do it.
<sil2100> infinity: not sure who approved those, but those were anyway safe to land as they only had touch-specific things in them
<infinity> sil2100: Some of those were auto-accepts (ie: working as designed) :)
<sil2100> Yay, well - I already knew that the auto-accept worked as I saw unity8 smoothly migrating just a moment ago, but yeah ;)
<slangasek> Laney: then it sounds like keying on packageset for the queue autoaccept is the wrong thing to do?
<Laney> I asked about that a few days ago
<infinity> slangasek: We've generally considered it the right thing to do because "in a packageset" maps nicely to "might want extra eyes on it".  Images aren't the only thing that matter.
<infinity> slangasek: But this specific case is a bit more special.  If only a couple of indicators are in this boat, we can just whitelist the packages for now.
<Laney> Not sure why indicator-network is in ubuntu-desktop, mind you
<Laney> Lemme re-run the script and see if it changes
<slangasek> infinity: "might want extra eyes on it" is not the same thing as "should be frozen".  Isn't everything in main in one packageset or another?
<infinity> slangasek: I'm not disagreeing, just stating that stgraber's original design was meant to be more conservative than permissive, I believe.
<infinity> Better to review a few extra packages than to have people break things that we really don't want broken.
<infinity> But I'm sure this could use some fine-tuning.
<Laney> oh
<Laney> There's an ancient (2010-07-08) exception putting indicator-network in ubuntu-desktop
 * Laney zzzap
<jibel> there is no desktop image since yesterday. CD build fails with cp: cannot stat `boot1/isolinux/lang': No such file or directory
<jibel> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/utopic/daily-live/tmp/utopic-i386/bootable-stamp] Error 1
<jibel> could anyone look at it?
<elfy> jibel: I'm assuming that all the other images would have the same error
<infinity> syslinux broken?  What a shock.
<infinity> ... except it hasn't been uploaded since June.
<infinity> jibel: Will look into it in a bit.
<jibel> infinity, it could be the fix for bug 1334189 ?
<ubot2> bug 1334189 in Ubuntu CD Images "pre-boot menu offers no OEM mode on Utopic live images" [Critical,Fix released] https://launchpad.net/bugs/1334189
<infinity> jibel: Could well be.  Haven't had a chance to look yet.  Usual morning headless chickening routine.
<jibel> infinity, or more likely r1899
<cjwatson> infinity,jibel: yeah, my code, I'll fix
<cjwatson> bah etc.
<cjwatson> ah inverted logic
<infinity> cjwatson: Ta.
<jibel> cjwatson, thanks
<cjwatson> fixed || â &&, sorry about that
<stgraber> ogra_: sorry, I'm on vacation until Friday. system-image doesn't use sync-mirrors but every run of import-images calls the ssh sync, so try running bin/import-images manually (as cdimage) and if that doesn't print an error message then it's something wrong on IS' end
<ogra_> stgraber, yeah, all solved ... nusakans / was full
<stgraber> ogra_: oh, right, that doesn't help and I suspect system-image was making it worse by trying to create a bunch of stuff in /tmp
<ogra_> heh, yeah, seemingly
<stgraber> I should make that configurable so we can use /srv/system-image.ubuntu.com/tmp or something like that instead of /
<ogra_> but now all is fine
<ogra_> i guess that can wait til after your vac. ;)
<stgraber> yeah
<ogra_> hmm
<ogra_> the last two images expose the same issue but nusakan does have plenty of diskspace
#ubuntu-release 2014-10-09
<xnox> Laney: shall I unblock btrfs-tools? or it has no chance of getting in?
<Laney> what about it?
<xnox> (and by ublock, i mean remove block-proposed tag...)
<xnox> Laney: it's an FFe request...
<xnox> it's been ages since i've done one, and i now wonder if i did it all wrong.
<Laney> it's pretty minimalist
<xnox> Laney: it's pretty, and that's all that counts right?! =)
<Laney> and most people wait until they are granted before uploading. :)
<xnox> Laney: you have queudiff and everything.
<xnox> Laney: in essence I'm trying to match the kernel though. And it's mostly bug-fixes.
<Laney> it's not in a queue :p
<xnox> oh, right, it's in propose.d
<xnox> meh. there is proposed-> release diffs, no?!
<Laney> yes
<xnox> darn, i wanted it to be in the queue.
<xnox> but it was before full freeze I think.
<Laney> I don't think I'm especially qualified to review it
<xnox> ogasawara: hey, do we want btrfs-tools matching the kernel for utopic? =)
 * xnox not a all trying to social engineer my way in ;-)
<mlankhorst> xnox: fix your super space bug first ;P
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1242572
<ubot2> Launchpad bug 1242572 in xkeyboard-config (Ubuntu Trusty) "xkeyboard-config, console-setup, and ubiquity should use Super+Space for switching keyboard layouts" [Low,In progress]
<xnox> mlankhorst: lolz =)
<bluesabre> swift indeed
<Laney> quite ...
<jamespage> don't joke
 * jamespage puts down his swift hammer
<jamespage> hoepfully other than changing the version number I won't have to touch that again this cycle
<jamespage> (but thankyou for accepting that so quickly)
<doko> well, fixes a ftbfs
<jamespage> doko, 0ubuntu2 fixed the ftbfs - that one fixes the autopkg tests :-)
<doko> meh
<jamespage> doko, that's not what I said ;-)
<rtg> please approve the Utopic kernel upload
<arges> cjwatson: infinity : can i have someone accept libvirt in utopic? creating VMs w/ qemu/libvirt is completely broken without that update
<infinity> arges: Looking.
<arges> infinity: thanks
<infinity> Laney: Please reupload that webkitgtk to the archive, syncing from a random tainted PPA (the build log shows packages that aren't in the archive) is not sane.
<infinity> Riddell: Around?
<Laney> infinity: did it have binaries?
<infinity> Laney: Err, it could have been a source-only sync, the UI doesn't make that particularly obvious.
<Laney> copy-package -s utopic --to-suite=utopic-proposed -p laney --ppa-name=arm --to-primary webkitgtk
<infinity> Laney: They kinda all look the same without fetching.
<infinity> Laney: If it was source-only, my bad.  Though also still a pain to review. :P
<Laney> What evs, just wanted to save uploading it since it was already on LP
<infinity> Hrm, who just accepted that kopete?
<doko> I accepted libaio, fixing the ftbfs
<infinity> Yeah, was just curious about the kopete accept, since it looked like it broke feature freeze, and was going to get Riddell/ScottK to comment first.
<infinity> But whatever. :/
<jamespage> Laney, jdstrand agreed todo the ceilometer archive-admin bits, but that is dependent on MIR's completing as its going to dep-wait for the moment
<infinity> ^-- Self-accepting the tzdata sync, it's just a trivial translation update.
<mdeslaur> rsyslog is a security update ^
<kenvandine> can someone please kill the ubuntu-system-settings that went to rtm proposed?
<kenvandine> before it goes to release
<kenvandine> infinity, ^^
<kenvandine> infinity, that silo was never tested and not ready to publish, but somehow citrain let it publish
<kenvandine> ubuntu-system-settings 0.3+14.10.20141007.2-0ubuntu1 in 14.09 proposed
<kenvandine> ah crap... it got promoted to release :(
<kenvandine> barry, ^^
<zul> can someone approve the python-glance-store upload it fixes downloading images from glance using the rbd backend
<barry> ken :(
<barry> kenvandine: :(
#ubuntu-release 2014-10-10
<elmo> anyone with cdimage access around?
<seb128> that sync ^ has no lp reference but the ffe is bug #1379344
<ubot2> bug 1379344 in glibmm2.4 (Ubuntu) "[FFe] Update glibmm to 2.42" [Medium,Triaged] https://launchpad.net/bugs/1379344
<seb128> it makes the binding be on the same serie as the lib and fix the current ftbfs
<cjwatson> stgraber: please can you make sure to run the test suite before committing to cdimage?
<cjwatson> fixing it up now ...
<stgraber> cjwatson: oops, sorry, I always forget that config changes also break the testsuite...
<stgraber> slangasek: so cjwatson reported bug 1379274 as a regression from the switch to python3 and switched import-images back to python2 which hit the bug again and filled up nusakan's disk. I've now added a test and pushed a fix for unicode handling in the removal list for python2.
<ubot2> bug 1379274 in Ubuntu system image "import-images fails under Python 3 when there are multiple images and at least one lacks a base" [Undecided,New] https://launchpad.net/bugs/1379274
<stgraber> slangasek: so for hte time being, we'll keep things running under python2 and I'll look into cjwatson's bug later, then do proper testing of python3 before we consider switching produciton to python3
<stgraber> system-image is back to normal, crontab entry re-enabled
<cjwatson> stgraber: thanks
<cjwatson> stgraber: would appreciate review of https://code.launchpad.net/~cjwatson/ubuntu-system-image/cdimage-custom/+merge/237942 if you get a chance - fairly urgent
<cjwatson> rationale's near the end of the linked (unfortunately private) bug
<stgraber> cjwatson: merged and deployed
<cjwatson> yay thanks
<cjwatson> glad I understood the model properly
<cjwatson> so we'll just need to add an extra cdimage-custom line to etc/config after deploying livecd-rootfs
<stgraber> more like changing the existing custom line to use the cdimage-custom generator instead of the http one, but yeah
<stgraber> reminds me I really need to split the generators out as separate files, generators.py is starting to be pretty messy :)
<cjwatson> right yeah
<cjwatson> I guess thinking about it we can safely land livecd-rootfs without that
<cjwatson> because nothing happens to the actual build until etc/config is changed
<cjwatson> oh no, that would drop those click packages from rootfs into a black hole
<stgraber> yeah, I think we'll need to be pretty careful, stop the system-image cron, land cdimage, build a new image, update system-image's config, run import-images by hand to confirm all is well, then turn cron back on
<cjwatson> land livecd-rootfs, but yeah
<cjwatson> I deployed the cdimage code already, since it should be a no-op if livecd-rootfs hasn't generated custom.tar.gz
<stgraber> ah right
<stgraber> an alternative would be to change livecd-rootfs to first both install the clicks in the rootfs and generate custom.tar.gz with the same clicks. Then we can land that, switch system-image, test everything and then land a second livecd-rootfs which stops including the clicks in the rootfs
<stgraber> that's all based on the assumption that click doesn't freak out if something is both in the system path and in /custom
<cjwatson> shouldn't any more following the click-apparmor changes
<cjwatson> ok, I'll follow up on https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905
<stgraber> cjwatson: are you the one holding the vim lock on etc/config ?
<cjwatson> stgraber: oh sorry, dropped
<stgraber> thanks
<jamespage> the neutron upload I did a few minutes ago resolves a blocking issue in our RC testing; however it does pull a new package into main (ipset) - MIR raised and apologies - missed that delta on the rc1
<stgraber> cjwatson, ogra_, slangasek: so who just switched system-image back to python3 again? :)
<stgraber> I'm getting tracebacks in my e-mails
<ogra_> stgraber, i didnt touch the code at all
<ogra_> (i ran import-images with python and python3 prefix manually this morning thouh ... to get the images out ... are you sure these mails are recent ?)
<stgraber> ogra_: yeah, they're pretty recent and I see that someone re-applied slangasek's change manually in /srv/system-image.ubuntu.com
<stgraber> so system-image is currently broken
<ogra_> ouch
<ogra_> i know lool just built an image, but i think he only touched crontab
<cjwatson> I didn't touch it
<lool> I've only touched crontab
<cjwatson> you sure it wasn't a merge conflict thing
<cjwatson> ?
<lool> and ran an rtm image build
<lool> I didn't bzr anything
<stgraber> I'm having doubts now :) I'm pretty sure I did uncommit+revert before pulling the updated code but maybe I forgot the revert and we've somehow been lucky not to hit the broken python3 codepath until now (because the past 20 or so runs were successful, it just started failing again about 20min ago)
<stgraber> anyway, just dropped all the local delta so the next run should succeed again
<cjwatson> (that's a binary sync; I took care because perl can easily make the archive grumpy if you end up with build skew)
<cjwatson> slangasek,infinity: would you have a minute to review debian-installer so that the new kernel can get in?  there's one ppc64el-specific change in there too
<slangasek> yes, looking
<infinity> cjwatson: oh, thanks for that, I got distracted.
<infinity> cjwatson: Are minicmd/reboot consistent with other arches?
<infinity> cjwatson: Oh, I guess we cargo-culted this from kfreebsd, which has an entirely different module selection.
<infinity> But minicmd is there, at least.
<infinity> slangasek: You still reviewing that, or okay for me to let it in?
<slangasek> infinity: no, and no!
<infinity> That answers that.
<infinity> ;)
<slangasek> yes, it's always nice to see the queuebot accepting a botch sync
<cjwatson> yeah there isn't really a perfect analogue elsewhere but I guess kfreebsd is closest right now
#ubuntu-release 2014-10-11
<cjwatson> livecd-rootfs fixes ubuntu-touch build failures
<cjwatson> not totally sure why that's still hardcoded, but not investigating that at 9am on a Saturday
<cjwatson> There's one merge and three rebuilds needed for Perl 5.20.1, that I know about.  Staging in my PPA
<cjwatson> And landing
<cjwatson> (libpar-packer-perl was auto-accepted)
<ogra_> can someone please let this in ^^^^ so we get working touch images again
<ogra_> stgraber, are you around ? we have a bad image on s-i
<asac> infinity: slangasek: stgraber: cjwatson: ^^
<asac> ogra_: whoelse?
<asac> there must be more
<ogra_> asac, dunno, LP should know who is -release
<asac> Laney: ^
<asac> ScottK: Riddell: ^^
<asac> tumbleweed: ^^
<asac> please check with ogra - emergency
<Mirv> https://launchpad.net/~ubuntu-release/+members
<tumbleweed> I could approve that, but I can't do anything about building new images
<ogra_> tumbleweed, i can ... we just need that in
<tumbleweed> ogra_: I've seen situations where ^ii isn't exactly what is wanted, and ^.i is more accurate, but I assume you've tested this or, we use similar constructions elsewhere in that file
<asac> tumbleweed: pleae approve!!
<asac> thanks!
<ogra_> tumbleweed, yes i tested that on a running system
<tumbleweed> ok, approved
<ogra_> (it will need smoe correction next week to not hardcode the 8 and 3 in the package names, but for an emergency fix it is good right now)
<Mirv> \o/
<bluesabre> SRU team, please release the above menulibre into trusty-proposed so we can begin verification
<bluesabre> xfdesktop MRE has also been sitting in an unaccepted state for a while now, https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1365965
<ubot2> Launchpad bug 1365965 in xfdesktop4 (Ubuntu) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,In progress]
<bluesabre> please let me know if there are any questions :-)
<infinity> tumbleweed: There aren't just some situations, ^.i is *always* what you want, unless you're actually testing for the desired state (which nearly no one is)
<infinity> tumbleweed: Luckily, in the case of livecd-rootfs, it's pretty unlikely that a package will be on hold, etc.
<infinity> ogra_: post-accept review of that upload.  Why are you manually setting the alternative if you've also made sure the right packages are installed?  Seems redundant?
<ogra_> infinity, i didnt make sure the right packages are installed ... there is dependency breakage that pulled the -mesa packages in additionally
<infinity> ogra_: Oh, you mean you're getting both now?
<ogra_> infinity, and depending on the  order apt installs tem in the chroot you might end up with the wrong alternative
<ogra_> right
<infinity> Gross.
<infinity> Please fix that?  Having useless packages installed is silly.
<ogra_> we need to fix the dep ... but i cant do a quick upload of mir
 * infinity nods.
<ogra_> so as emergency fix forcing the alternative is ok
<infinity> Yeah, that's fine, as long as the better fix is on the TODO.
<ogra_> and long term it will save us from the same issue if -mesa slips in again
<ogra_> (well, after i fixed the matching in the code ... that hardcoded numbers in tteh package names indeed need to go)
<ogra_> for now getting the phones out there to boot again is #1 prio :)
<infinity> ogra_: And the other bit, tumbleweed's mention of ^.i instead of ^ii is true.  We don't actually have anything on the livefses that's in a state other than ^i, but who knows if someone might decide to change that for some specific image for some weird reason, even if just a temp hack in a hook.  Better to always use the form that means what you want.
<infinity> ogra_: But also not a big deal.
<ogra_> well, i shoul dprobably drop the whole check
<ogra_> so that the build actually fails if the -android packages are not there
 * infinity nods.
<infinity> It's also, again, redundant because you ask for them by name in the install pass.
<ogra_> but it felt safer for an emergency fix to do it with a check for the moment
<infinity> But I imagine seeds might eventually do that right and you'll remove that.
<ogra_> right
<infinity> But yes, checking if a package is installed before doing a mandatory thing with it will miss errors, as you say.
<ogra_> well, i would like to keep forcing the alternative to make it future proof, as i said
<infinity> Could you not just make the android alternative prio higher?
<infinity> This is one of those cases where I can't see why a desktop user would ever install the android package.
<infinity> So it's safe to assume that if you install the android one, that's the one you want to win.
<ogra_> yeah, i dont think our issue are the desktop users that install stuff ... but the desktop-next seed
<ogra_> (which needs to use mesa)
<ogra_> theoretically there should always be a seed entry for -android in touch and -mesa in desktop-next
<ogra_> but if the package gets updated without seed change alongside such crap can happen
<tumbleweed> infinity: what I meant was situations where it ^ii doesn't work at all :)
#ubuntu-release 2014-10-12
<bluesabre> SRU team, please release menulibre, xfce4-weather-plugin, and xfdesktop4 into trusty-proposed so we can begin verification
<darkxst> would anyone be able look at bug 1376184
<ubot2> bug 1376184 in gnome-shell (Ubuntu) "[UIFe] Re-enable brightness widget" [Undecided,New] https://launchpad.net/bugs/1376184
<skellat> darkxst: Have you gotten sign off from Documentation?
<darkxst> skellat, no I haven't
<skellat> darkxst: Please consult https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
#ubuntu-release 2015-10-05
<smb> cyphermox, when you come online. you might want to upload a signed-grub2 along with grub2 to trusty proposed. I am getting partial upgrade-only mode again
<infinity> smb: I'll do that right now.
<infinity> cyphermox: ^
<smb> infinity, ah thanks
<infinity> ^--- Self-reviewing that, it's just a grub version bump.
<infinity> smb: Iz done.
<smb> infinity, ok cool. I will check a bit later for it (and what else is pending in proposed)
<infinity> tumbleweed: You around?
<infinity> tumbleweed: Who owns the reverse-depends(1) server-side bits?  And, if it's you, could I ask you to add the debian-installer components to the Packages files you consider?
<infinity> tumbleweed: Policy doesn't allow namespace overlap between debs and udebs, so it shouldn't cause any issues to just concat it all together.
<infinity> tumbleweed: (Well, I suppose it could cause issues in your scripts, depending on how you process Provides, in some curious corner cases, but if that's a concern, you could have it not included in the default component set and require a --di switch or something)
<doko> infinity, nodejs block-proposed ping. is this still necessary?
<infinity> doko: I think so.  My "rebuild node-*" attempt didn't end well.
<infinity> doko: I think we can maybe still get it in, but only if the rdeps get fixed up.  I've not had time to look at the failures, only to see that lots of stuff fails.
<infinity> doko: See node-* in https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+packages if you're curious.
<doko> looks more like a task for the x-series ...
<infinity> doko: Possibly, yes.  Though, it's also a bit curious.  See node-srs in wily-proposed.
<infinity> doko: That version was specifically updated for node4 support, and built in Debian, but failed in Ubuntu.
<infinity> doko: What's our toolchain delta these days?  Just --as-needed, or also still some tighter security/sanity flags?  Seems weird that these build logs should differ.
<infinity> doko: g++-5 in both cases, but the debian CXX object builds cleanly, on Ubuntu, it's warning/error city.
<doko> yes, security when the options are not passed using dpkg-buildflags
 * infinity wonders if maybe node's build system needs to relax some flags or some such.
<infinity> But yes, possibly an x-series task, if no one has the round tuits to dig deeper.
<doko> chrisccoulson, infinity: looks like oxide-qt is missing some architecture specific bits, which are present in the other plethora of webkit versions. any reason for that?
<infinity> I know nothing of oxide.
<infinity> doko: Actually, I wonder if this node issue isn't node at all, but gcc5.  I should retry my rebuild tests without proposed enabled, using the old nodejs.
<infinity> doko: (not that I'm saying gcc5 is broken, just that new warnings/error might have blown up the node world)
<infinity> Still curious that it's working in Debian, though.
<infinity> doko: Do the gcc-5 binary packages include a handy "here's the difference from Debian" note, or do I just need to read the source package and sort it out?
<doko> infinity, no, best thing would be the diff of the debian dirs, and then maybe grepping for distrelease / derivative / distribution
<infinity> doko: *nod*
<chrisccoulson> doko, oxide is not webkit
<doko> chrisccoulson, but it ftbfs in webkit ;-P
<infinity> It sort of is.
<doko> -- Running gyp
<doko> gyp: Undefined variable platform_heap_asm_files in /Â«PKGBUILDDIRÂ»/third_party/chromium/src/third_party/WebKit/Source/platform/blink_platform.gyp
<doko> CMake Error at CMakeLists.txt:178 (message):
<doko>   Running gyp failed
<chrisccoulson> On those architectures, It's missing amongst plenty of other things, compilers for V8
<doko> which is what nodejs 4.0 should provide ...
<infinity> Which is now a solved problem in upstream V8, so oxide could use an update.
<chrisccoulson> we use whatever chrome ships
<infinity> Yay for everyone including static versions of everything. :/
<infinity> (But bundling libraries is NEVER a problem!)
<doko> chrisccoulson, firefox dropped my build fix
<chrisccoulson> Trying to deliver frequent updates for something that has a dependency on a library with no stable ABI that's consumed by other applications in the archive would be significantly more of a problem
<chrisccoulson> doko, what fix?
<doko> http://launchpadlibrarian.net/219814387/firefox_41.0%2Bbuild3-0ubuntu1_41.0%2Bbuild3-0ubuntu2.diff.gz
<infinity> doko: Was the pkgconfig thing intentional in that diff, or just an oops?
<infinity> doko: (But thanks for the -latomic fix)
<infinity> I still consider it a gcc bug that -latomic isn't somehow autodected as needed on platforms where it's required.
<doko> oops
<infinity> But I think I've seen more than one upstream bug where people disagree with me on that.
<infinity> So I've never tried to argue it.
<doko> gcc-5 in wily now has a workaround, but as firefox is uploaded to released versions as well, it should carry that patch
<infinity> doko: Wasn't the gcc-5 workaround specifically about -latomic for some C++ atomics, not for the entire atomic family?
<infinity> doko: As in, powerpc (and a few arches we don't build for) is still a unique snowflake that needs -latomic for pretty much all atomics, even from C.
<doko> the former. but this was fixed upstream, but still showing on powerpc only
<doko> yes, because the builtins aren't resolved to some instructions, but are left "unimplemented". but some support is missing, like 8byte atomics. that's why I was looking into the insighttoolkit4 build
<doko> infinity, did you cancel the gdb build on armhf?
<doko> for the test rebuild
<infinity> Nope.
<infinity> I've only been babysitting the PPC builders, since they're "special", I haven't even looked at armhf.
<infinity> I'm tempted to just update the PPC builders to utopic kernels, so gdb and gcc stop killing them, but that feels like a total cop-out when we should be able to debug and fix 3.13.  But no one from either Canonical or IBM has found the time, so... :/
<doko> pitti, one more debhelper merge?
<pitti> doko: ENOVERB? I don't see any upload in unapproved?
<doko> pitti, no, was asking if you would do it? it's in unstable, not ready for upload =)
<Laney> I think he's asking for you to put one there
<Laney> as TIL
<Laney> cheeky
<pitti> doko: ah; https://tracker.debian.org/news/717055 looks rather intrusive, and has new depends in universe (dh-strip-nondeterminism)
<pitti> that looks a little intrusive at this point; are you looking for a particular fix?
<doko> pitti, isn't 05 dropping that?
<doko> th dh_movefiles thingy
<pitti> not according to https://tracker.debian.org/news/717170
<pitti> doko: ack, I'll cherry-pick that then
<pitti> doko: https://anonscm.debian.org/cgit/debhelper/debhelper.git/commit/?id=c530fe28c07 ?
<doko> pitti, yep
<pitti> doko: ack; test-building
<pitti> doko: ^
<infinity> pitti: +1 for removing the errant .rej file too. :P
<pitti> infinity: yeah, some dude forgot that on the last merge :)
<pitti> careless people that
<cyphermox> davmor2: I'm curious if it's the fact that it was missing a merge, or the fact that it was really really utterly broken, that makes my fixed usb-modeswitch work for you :)
<davmor2> cyphermox: sorry how do you mean?  You asked for someone with a huawei to test it so I did
<cyphermox> yes
<cyphermox> the package was very very broken, not just for huawei
<davmor2> cyphermox: I guess people don't use dongles as much so no one noticed
<davmor2> cyphermox: the original package you mean not your fixed one right
<cyphermox> yes
<cyphermox> the original wouldn't trigger for a lot of dongles, I expect. I'm surprised, it doesn't seem like much change to make that not as popular; except maybe tablets.
<davmor2> cyphermox: I have a mifi (3g accesspoint) so don't need the dongle
<tumbleweed> infinity: yeah, I own them
<tumbleweed> infinity: https://code.launchpad.net/~stefanor/+junk/reverse-deps
<davmor2> cyphermox: in fact I have to switch the sim out of my mifi and put it in my dongle cause the sim in it is defunct
<cyphermox> heh
<cyphermox> I washed the best dongle I had once too many times, it no longer works
<cyphermox> come to think of it, maybe it was the one good huawei dongle I had too
<cyphermox> yup, oops.
#ubuntu-release 2015-10-06
<doko> who should be asked for ubuntu-touch-meta changes?
<stgraber> that's a LXC bugfix release + security fix for wily so we should really get it in :)
<stgraber> I'll send the exact same thing as an SRU to vivid too under the LXC MRE
<stgraber> and that's the vivid SRU ^ (only delta with wily is that seccomp is still arch-restricted in there)
<flocculant> cyphermox: sorry ... you know the ubi-timezone bug you fixed - still being seen via the mini.iso - thought you should know
<cyphermox> flocculant: thanks
<flocculant> one of my lot saw it today
<cyphermox> this makes sense, tzsetup might be included, so I'd need to rebuild d-i for it
<flocculant> I thought something of that sort - though not anywhere as specific :)
<cyphermox> as long as it's fixed for ubiquity for the same person/system, then it would be good news
<flocculant> cyphermox: I'll double check on that for you
<cyphermox> thanks
<cyphermox> flocculant: nope, not included in d-i images
<flocculant> okey doke
<cyphermox> it's either not fixed, or maybe an old mirror? depends on the results of others who have been seeing the issue.
<flocculant> yep
<flocculant> cyphermox: might have been led up the garden path a bit here - will confirm as soon as I can - sorry
<cyphermox> no worries, let me know
<flocculant> yep
<flocculant> cyphermox: mmm - so I'm seeing something odd here - recognises me as Europe/London, if I say no - then I get a very limited choice of where I can be, either some US places or Samoa
<cyphermox> in mini.iso?
<flocculant> yea - just grabbed the wily one
<cyphermox> mkay
<cyphermox> I'll check it later
<flocculant> ok
<cyphermox> if you can file a bug about it, then it's less likely I forget :)
<flocculant> yea - was just on it - what package - tz-setup ?
<flocculant> or d-i ?
<cyphermox> make it against tzsetup
<flocculant> cyphermox: bug 1503379
<ubot93> bug 1503379 in tzsetup (Ubuntu) "Inadequate choices for timezone" [Undecided,New] https://launchpad.net/bugs/1503379
<cyphermox> flocculant: thanks
<flocculant> np
#ubuntu-release 2015-10-07
<arges> is there any way to target an ubuntu package to a series if its in this state -> bug 1386524 (trying to target to vivid)
<ubot93> bug 1386524 in valgrind (Ubuntu Trusty) "Update Ubuntu 14.04 with full Valgrind LE support." [Medium,Confirmed] https://launchpad.net/bugs/1386524
<rbasak> Is that the Launchpad bug where if you delete a bug task it's gone forever?
<arges> rbasak: yea, i'm not sure if the vivid task was deleted or just the development task... but maybe its a similar 'feature'
<rbasak> Looks like they all were
<rbasak> AIUI there's no way out of that.
<rbasak> Not sure what the bug reference is for this issue.
<rbasak> It has Affected Me Too.
<rbasak> Once you know, you can never delete bug tasks (Invalidate them instead) as a pre-workaround.
<rbasak> But it doesn't work unless everyone knows not to do it, which they don't.
<cjwatson> In [2]: lp.bugs[1386524].addTask(target='/ubuntu/vivid/+source/valgrind')
<cjwatson> Out[2]: <bug_task at https://api.launchpad.net/devel/ubuntu/vivid/+source/valgrind/+bug/1386524>
<ubot93> Launchpad bug 1386524 in valgrind (Ubuntu Trusty) "Update Ubuntu 14.04 with full Valgrind LE support." [Medium,Confirmed]
<cjwatson> done
<arges> cjwatson: thanks!
<cjwatson> I can't remember if that works in all situations, but it's useful enough to work around at least some UI problems
<arges> cjwatson: good to know, adding to my bag of tricks
<rtg> infinity, linux (wily) in the unapproved queue
<smoser> can someone review my curtin upload please ? https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=curtin . pretty simple. fixes busted install.
<infinity> rtg: Accepted and heading to bed, I'll check on it when I wake up to see if anything asploded.
<rtg> infinity, ack
<arges> cyphermox: hi looking at the multipath-tools upload for trusty, does that fix the failures seen in the -proposed version?
<arges> cyphermox: bug 1468897, does multipath -l work?
<ubot93> bug 1468897 in multipath-tools (Ubuntu Trusty) "multipath creates binding for Removable(USB) drives" [Medium,Fix committed] https://launchpad.net/bugs/1468897
<cyphermox> arges: yes, that's the point of that new upload :)
<arges> cyphermox: ok, wasn't exactly clear. which is why I was asking
<cyphermox> I can go do it again right now if you want
<arges> cyphermox: well you'll have to just re-verify it when it hits -proposed
<cyphermox> yep
<arges> cyphermox: cool thanks, i'll review that again soon
<cyphermox> arges: http://paste.ubuntu.com/12705401/
<cyphermox> no worries, when it gets to -proposed I and others will review/and verify it again
<arges> cyphermox: great! ok
<davmor2> infinity, cyphermox: did we get a final yay or neigh to wubi removal?
<cyphermox> don't look at me, I'm not release-team :)
<davmor2> cyphermox: oh fair enough over to infinity then
<cyphermox> I think he's sleeping for now, it may be a while before he responds
<davmor2> cyphermox: damn him and his different timezone ;)
<cyphermox> there is no such thing as a timezone :)
<slangasek> bdmurray: hmm, does adding the sssd team to package-subscribers imply this team is a recognized subscribing team for MIR purposes?
<bdmurray> slangasek: Yes
<slangasek> bdmurray: ok.  that seems dubious to me; it's a team with only two people and doesn't map to anything that's accountable to either Ubuntu (flavor teams) or Canonical (company teams)
<slangasek> I mean, we already have problems with some of the existing ownership mappings, I don't think we need to make it worse by introducing even more specialized teams :)
<bdmurray> I see your point.
<bdmurray> I'll dig into why I added them, it was a bit ago.
<slangasek> bdmurray: ok
<bdmurray> slangasek: fwiw bug 1491263 is the MIR that used the sssd team
<ubot93> bug 1491263 in uid-wrapper (Ubuntu) "MIR: nss-wrapper, uid-wrapper" [Undecided,Fix released] https://launchpad.net/bugs/1491263
<slangasek> bdmurray: hrm ok
<slangasek> bdmurray: and the original sssd MIR was https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/903752 - before we had the "must have subscriber" but, I think?
<ubot93> Launchpad bug 903752 in samba (Ubuntu) "[MIR] sssd" [Medium,Fix released]
<bdmurray> slangasek: yes, that sounds right
#ubuntu-release 2015-10-08
<zequence> Could someone please approve above (ubuntustudio-meta). We can't build our ISOs without it
<bdmurray> Could somebody fully phase ubuntu-release-upgrader for vivid?
<flexiondotorg> bdmurray, Just out of interest, what does that mean?
<rbasak> flexiondotorg: https://wiki.ubuntu.com/PhasedUpdates
<flexiondotorg> rbasak, Thanks.
 * flexiondotorg reads...
<bdmurray> flexiondotorg: SRUs go through a phased update process and sometimes there are false positives.
<bdmurray> http://www.murraytwins.com/blog/?p=127 that's a better explanation of how things really work
<infinity> bdmurray: I have the technology.  I can make it happen.
<infinity> bdmurray: When is your cronjob going to run?  I don't want to collide and disappear it.
<flexiondotorg> bdmurray, Thanks for the educational materials.
<infinity> bdmurray: Oh, it's at 0 right now, so I guess it was halted, and the cronjob won't touch it?
<infinity> bdmurray: Confirm/deny? :P
<bdmurray> infinity: The cronjob would only touch it if problem d2dd8d went away which it won't.
<bdmurray> infinity: and the job runs as ubuntu-archive on snakefruit I think every 8 hours
<infinity> bdmurray: Oh, that bin just collects every failure of do-release-upgrade due to dpkg exiting?  Ick.  Does anyone actually look at those to pick out the real bugs?
<infinity> bdmurray: Also, phased to 100%.
<bdmurray> Yes. No. Thanks!
<infinity> bdmurray: Do we trap enough info in those cases to actually examine and *find* the real bugs, assuming someone has the time to do so?
<infinity> bdmurray: The only I looked at just had the dpkg exit code, no useful logs, but maybe I wasn't looking in the right place.
<bdmurray> infinity: Nope, and that's probably the real issue.
<bdmurray> infinity: I'll dig into it a bit.
<infinity> bdmurray: Cool.  I suspect the real issue will be a matter of time, but without any debugging info to work from, there's little motivation to even find time to look. :P
<bdmurray> It'd also be better if we buckets with real counts to figure out where the actual problem lies.
<tdaitx> doko, are you ok removing libecap3 from -proposed so I can ask someone to sponsor libecap2 gcc5 from LP: #1504200? the current squid 3.3 only works with with libecap2 (0.20), it does not work with libecap3 (1.0)
<ubot93> Launchpad bug 1504200 in squid3 (Ubuntu) "libecap2 FTBFS due to gcc5 transition" [Undecided,New] https://launchpad.net/bugs/1504200
<tdaitx> doko, this way we can at least fix squid 3.3 FTBFS... and I also have an update for it from 3.3.8 to 3.3.14
<slangasek> bdmurray: your latest MP seems to have the sssd commit in it
<bdmurray> slangasek: Ah, okay. Fixing.
<bdmurray> Could we have a wily-updates milestone?
<doko> tdaitx, done, should be published in about 45 minutes
<tdaitx> doko, thanks!
<slangasek> bdmurray: done
<bdmurray> slangasek: What was done?
 * bdmurray figures out wily-updates was added
<slangasek> yes that :)
#ubuntu-release 2015-10-09
<ogra_> would be nice if the two livecd-rootfs uploads could be approved before 5am UTC so the next auto-build of snappy wily doesnt fail
<ogra_> slangasek, FYI i had to divert grub-install during rootfs build for snappy after adding the -signed packages
<infinity> ogra_: And why is that uniquely required for snappy?
<ogra_> dunno, why is grub-install run if i seed these packages ? it wasnt before it seems
<infinity> Adding signed wouldn't change anything.
<ogra_> no, it was a bigger change than that ...
<infinity> Well, you implied it was just that. :P
<ogra_> http://paste.ubuntu.com/12722981/
<ogra_> seems the postinists of these packages behave differently
<infinity> Well, you didn't have grub2 installed before.
<infinity> So, yeah.
<infinity> Quite different.
<infinity> Erm, nevermind.  Can't read.
<infinity> You didn't have grub2-efi installed before.
<ogra_> right
<ogra_> and we dont use the signed stuff yet but need it in the rootfs for ubuntu-device-flash consumption
<infinity> The grub-efi postinst isn't meant to fail when grub-install fails, mind you.
<ogra_> it complains about no such dir ...
<ogra_> might not have been the failure that the build choken on ... there were two postinsts failing
<ogra_> but both had the grub-install call
<ogra_> *choked
<infinity> The following packages have unmet dependencies:
<infinity>  grub-efi-amd64 : Conflicts: grub-pc but 2.02~beta2-28 is to be installed
<infinity>  grub-pc : Conflicts: grub-efi-amd64 but 2.02~beta2-28 is to be installed
<infinity> That looks more problematic.
<ogra_> that is why i seeded grub-pc-bin ;)
<infinity> I don't actually see the failure you're referencing, though.
<ogra_> i already did a test build with the same change on vivid ...
<infinity> Do you have a pointer?
<ogra_> https://launchpadlibrarian.net/220705208/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz
<ogra_> or https://launchpadlibrarian.net/220705134/buildlog_ubuntu_wily_amd64_ubuntu-core-system-image_BUILDING.txt.gz
<ogra_> if you want wily
<infinity> That wily one is where I pasted from. :P
<ogra_> and https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/40107/+files/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz passes after the change
<ogra_> oh
<ogra_> thats weird then
<infinity> Oh.
<infinity> grub-install: error: cannot find EFI directory.
 * ogra_ re-reads
<infinity> ^-- That?
<infinity> Maybe you should have an EFI directory?
<infinity> Instead of being hackish.
<ogra_> that and a few lines down there is another one
<ogra_> i really dont think we want to run grub-install at all ... i could be wrong though
<ogra_> we just need the binaries in the rootfs so u-d-f can pull them when it creates the actual image
<infinity> Possibly not.
 * infinity shrugs.
<ogra_> (our actual grub.cfg is also only 30 lines or so, quite different to a normal installation)
<infinity> Err, really?  You don't use update-grub?
<ogra_> (and snappy doesnt use update-grub either)
<infinity> Because why would someone want something that was familiar? :P
<ogra_> well, it messes up the rollback function ... snappy only needs to flick two vars back and forth, the rest is hardcoded anyway
<ogra_> http://paste.ubuntu.com/12723088/
<ogra_> the advamtage of creating complete disk images with hardcoded partitioning scheme ;)
<ogra_> infinity, thanks
 * ogra_ hopes it actually works without changed to u-d-f now :P 
<ogra_> *changes
<rcj> infinity, Could I have your help with an SRU in pending? bug #1473533
<ubot93> bug 1473533 in python-tz (Debian) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Unknown,New] https://launchpad.net/bugs/1473533
<rcj> infinity, it's been 6 or 7 days which is barely time but it's affecting the azure cloud streams and causing a juju breakage now.
<rcj> I was hoping that at least the precise package could be promoted to -updates today
<rcj> Scope of change is very small and risk is as well
<rcj> stgraber, arges, slangasek ^ Could one of you look at this SRU?  I just saw that infinity is under the weather.
<arges> rcj: looking
<rcj> arges, thanks. Not sure who can do what.  You were a sponsor on this upload
<arges> rcj: so typically we don't release on Friday's in case of regressions and people not being around during the weekend etc
<rcj> arges, I can understand that.  For me this is causing a Juju deployment breakage due to bad simplestreams data.  The fix is very narrow.  Without the fix the two functions will always throw an exception and do no meaningful work.  With the fix they will start returning a list of countries or timezones again.  But let me check that we can get the package applied in production if it were to be promoted.
<arges> rcj: ack
<ogra_> infinity, bah, crap ... there is another issue with hardcoded grub-pc in livecd-rootfs (i should have litened to you earlier :P )
<ogra_> *listened
<ogra_> infinity, ^^ that one actually fixes the conflict (i thoougth the seed change would have been enough, didnt know there was more hardcoding for grub-pc)
<slangasek> ogra_: hrm, ok, if grub-install wasn't previously being called from the rootfs build, I can see that being required
<slangasek> arges: are you releasing the SRUs for python-tz or still thinking about it?
<arges> slangasek: I can do it, waiting on rcj. is it alright if its a critical fix
<slangasek> it's certainly alright.  what is it you're waiting for?
<arges> slangasek: i'll just release, I know typically we dont release on fridays for regressions but this seems like a pretty cut and dried case
<rcj> arges, slangasek: thank you.  I had told arges that it could wait if I couldn't get it applied in production today.
<rcj> but it would help to have it in -updates
<slangasek> ah
<slangasek> yes, this is a one-liner change that's backwards-compatible.  I think it should just be released
<arges> ok doing it now
<slangasek> and I'll be around email this weekend, so if there are regressions and someone files a regression-update bug I'll see it
<smoser> anyone able to accept the cloud-init above for me?
#ubuntu-release 2016-10-10
<handsome_feng> Hi, release team, Could anyone help to approve the ubuntukylin-theme, ubuntukylin-wallpapers and ubuntukylin-default-settings. We are waiting for this to make test. Thank you !
-queuebot:#ubuntu-release- Unapproved: docker.io (yakkety-proposed/universe) [1.12.1-0ubuntu13 => 1.12.1-0ubuntu14] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (yakkety-proposed) [1.12.1-0ubuntu14]
-queuebot:#ubuntu-release- Unapproved: accepted pidgin [source] (yakkety-proposed) [1:2.10.12-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted kdelibs4support [source] (yakkety-proposed) [5.26.0-0ubuntu2]
<wgrant> pitti: https://translations.launchpad.net/ubuntu/yakkety/+language-packs has freshness for you. Sorry about the delay.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kjots (yakkety-proposed/universe) [4:5.0.1-2 => 4:5.0.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kjots [source] (yakkety-proposed) [4:5.0.1-2build1]
-queuebot:#ubuntu-release- Unapproved: zanshin (yakkety-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (kubuntu)
<slangasek> acheronuk, clivejo: kjots, zanshin uploaded
-queuebot:#ubuntu-release- Unapproved: accepted zanshin [source] (yakkety-proposed) [0.4.0-1build1]
<tsimonq2> Not release-critical, but this failure looks *weird*: https://launchpadlibrarian.net/288768577/buildlog_ubuntu_yakkety_amd64_lubuntu-next_BUILDING.txt.gz
<tsimonq2> Looks like a builder bug, not an issue with the seed or anything like that...
<tsimonq2> (I could be wrong)
<pitti> wgrant: yay, cheers!
<pitti> acheronuk: I wiggled it a bit, but the kdepim stack is still stuck; looking at that now
<acheronuk> pitti: yes. was just looking at that, then did a refresh and a lot seems to have shifted now?
<pishuilu> Hi, release team, Could anyone help to approve the ubuntukylin-theme, ubuntukylin-wallpapers and ubuntukylin-default-settings. We are waiting for this to make test. Thank you !
<pitti> acheronuk: oh, indeed! just kdelibs4support and kde-runtime
<pitti> acheronuk: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt , seems calligra, kdegames, kipi, libksane need to be updated for new kde-runtime? can you please have a look (e. g. in a yakkety-proposed schroot) what's needed there?
<pitti> curious that it only breaks -dbg packages
<acheronuk> I noticed that in one of the previous britney runs but hoped it would shake out. clearly not :/
<pitti> http://people.canonical.com/~ubuntu-archive/nbs.html has lots of -dbg which I cleaned up now; but those are different packages
<acheronuk> pitti: as an example: http://paste.ubuntu.com/23301843/
<pitti> acheronuk: ah, as the new kde-runtime dropped its -dbg
<acheronuk> aha indeed
<pitti> acheronuk: so that dependency needs to be dropped from the above -dbg (or they need to get dropped as well)
<acheronuk> so that is a NC rebuild of the affected packages?
<pitti> acheronuk: if the -dbg dep gets added dynamically, yes; if it's in d/control it needs to be changed there
<pitti> acheronuk: e. g. libkipi hardcodes it
<pitti> Depends: kde-runtime-dbg, libkipi11 (= ${binary:Version}), ${misc:Depends}
<pitti> acheronuk: and I believe the right fix is to just drop the -dbg package(s) entirely for these too
<acheronuk> pitti: I think ksane for example may be one of the packages that got rejected for v16.04.3 as KDE had not made any changes to it's source since 15.12.3
<pitti> Debian dropped it already
<acheronuk> ok
<pitti> acheronuk: just looked at libkipi, that can actually be synced
<pitti> the only difference is that debian installs 5 extra kipi.png icons
<pitti> http://paste.ubuntu.com/23301858/
<pitti> * Remove kipi.png from libkipi-data, those are now shipped by
<pitti> +    libkf5kipi-data. So keep them there and depend on it instead.
<pitti> oops, except for that, I think that's the icon diff
<pitti> so, that needs a merge
<pitti> acheronuk: so, since I'm that far already I can finish libkipi if you want; but someone else needs to fix the others
<acheronuk> pitti: if you don't mind. :)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openvpn [source] (yakkety-proposed) [1.2.6-2ubuntu1]
<acheronuk> do you know how long we have roughly to get these sorted? I know actual isos can't be that far off
<pitti> "last week" :)
<pitti> really, ASAP, should happen today
<acheronuk> yep. I got that. I was thinking more of a time rough time today actually. if that is possible to know.
-queuebot:#ubuntu-release- Unapproved: libkipi (yakkety-proposed/universe) [4:15.08.3-0ubuntu1 => 4:15.08.3-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted grub [source] (yakkety-proposed) [0.97-29ubuntu69]
-queuebot:#ubuntu-release- Unapproved: accepted libkipi [source] (yakkety-proposed) [4:15.08.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-default-settings [source] (yakkety-proposed) [1.3.15]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (yakkety-proposed) [16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (yakkety-proposed) [1.6.1.2]
<acheronuk> pitti: will a re-upload or rescue of the versions we has rejected do the job for some? e.g. https://launchpad.net/ubuntu/yakkety/+queue?queue_state=4&queue_text=kdewebdev
<pitti> maybe, not sure why they were rejected
<acheronuk> pitti: they got rejected for: Rejected by Steve Langasek: No changes in upstream source, this looks incorrect
<pitti> slangasek: your python-django-openstack-auth changes python-django-openstack-auth's python-keystoneauth1 to python3-keystoneauth1 -- that looks odd?
<acheronuk> where it fact it was correct, as KDE made new version tarball with unchanged source while porting of the packages in question to Qt5/kf5 was not finished yet
<pitti> acheronuk: oh, right
<pitti> ok, I can accept that then
<pitti> acheronuk: but this doesn't drop the -dbg package either
<pitti> infinity: uploading langpacks
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (yakkety-proposed/universe) [16.10.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted jfsutils [sync] (yakkety-proposed) [1.1.15-2.2]
-queuebot:#ubuntu-release- Unapproved: accepted libgd-perl [sync] (yakkety-proposed) [2.53-3]
-queuebot:#ubuntu-release- Unapproved: accepted openjade [sync] (yakkety-proposed) [1.4devel1-21.3]
-queuebot:#ubuntu-release- Unapproved: accepted alsamixergui [sync] (yakkety-proposed) [0.9.0rc2-1-9.2]
-queuebot:#ubuntu-release- Unapproved: accepted pycairo [sync] (yakkety-proposed) [1.8.8-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted calf [sync] (yakkety-proposed) [0.0.60-4]
-queuebot:#ubuntu-release- Unapproved: accepted csound [sync] (yakkety-proposed) [1:6.07.0~dfsg-4]
-queuebot:#ubuntu-release- Unapproved: accepted sooperlooper [sync] (yakkety-proposed) [1.7.3~dfsg0-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-radio-plugin [sync] (yakkety-proposed) [0.5.1-4]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (yakkety-proposed) [16.10.1]
<pitti> slangasek: changes the binary dependency, I meant
<acheronuk> pitti: ah, not, not on that one as the dbg package is in control
<acheronuk> going to have to go through all these later on
<acheronuk> calligra I'm not sure on, as that has been a problem build for ages
<acheronuk> pitti: I believe libkdegames is obsolete
<acheronuk> hi santa_ :)
<santa_> hi
<santa_> gonna check libkdegames
<acheronuk> reverse-depends kde-runtime-dbg
<acheronuk> Reverse-Depends
<acheronuk> ===============
<acheronuk> * calligra-dbg
<acheronuk> * kdebase-runtime-dbg
<acheronuk> * kdewebdev-dbg
<acheronuk> * libkdegames6abi1-dbg
<acheronuk> * libkipi-dbg
<acheronuk> * libkmahjongglib4-dbg
<acheronuk> * libksane-dbg
<acheronuk> oops
<santa_> pitti: the libkdegames6abi1-deb _binary_ package is obsolete, the latest src:libkdegames in proposed doesn't have that binary so we would need to remove that one from the archive
<santa_> pitti: same for kdebase-runtime-dbg, latest src:kde-runtime doesn't provide it
<pitti> santa_: right, that's also not in the complaint list
<pitti> amd64: calligra-dbg, kdewebdev-dbg, libkdegames6abi1-dbg, libkipi-dbg, libkmahjongglib4-dbg, libksane-dbg
<pitti> santa_: I sorted out libkipi already
<pitti> santa_: there is no kdegames in -proposed
<santa_> pitti: there is *lib*kdegames: https://launchpad.net/ubuntu/+source/libkdegames
<pitti> santa_: but libkdegames6abi1-dbg is from libkdegames4
<pitti> santa_: right, that already landed, but that's a newer versino
<acheronuk> libksane-dbg is also at 15.08.2-0ubuntu1, 2 versions behind our 16.04.3 kf5 package, so that is an obsolete -dbg as far as I can see?
<pitti>  libksane      | 4:15.08.2-0ubuntu1 | yakkety/universe | source
<pitti>  libksane-data | 4:15.08.2-0ubuntu1 | yakkety/universe | all
<pitti>  libksane-data | 4:16.04.3-0ubuntu1 | yakkety/universe | all
<pitti> that looks odd indeed
<santa_> pitti: ok, we we will need an uploade for libkdegames4, there's stuff still using it
<pitti> ah, that's now provided by libkf5sane
<santa_> correct
<pitti> santa_: but I can't just remove the old libksane source; it still builds libksane0 which is needed by kipi-plugins, ksaneplugin, tellico
<santa_> so we need an upload of that one too
<santa_> same for libkmahjongg4, kajonng is still using the old kdelibs4 based library, we need to upload a new version, removing the kde-runtime-dbg depend
<santa_> same for kdewebdev
<acheronuk> we need to get the proposed migration script/britney running against out staging ppas I think
<santa_> that will come later
<santa_> the old libkipi needs an update too, as it's still used
<pitti> santa_: I uploaded libkipi already
<pitti> (Debian merge)
<santa_> the old one, ok
<smb> pitti, could you do me a favour an accept libvirt into xenial. It is intended to replace the version currently in proposed
<santa_> and finally we need to update calligra too
<santa_> that one may be more difficult
<pitti> smb: done
<smb> pitti, thanks! erm Danke! :)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.5]
-queuebot:#ubuntu-release- Unapproved: rejected upstart [sync] (xenial-proposed) [1.13.2-0ubuntu21.2]
<pitti> xnox: ^ no LP bug ref
<santa_> pitti: we can prepare the rest of the affected packages if you are willing to sponsor, I would dig into calligra later as it's ftbfs'ing in -proposed and there's a new upstream bugfix release
<pitti> santa_: sure, I can  sponsor
<santa_> pitti: specifically, the affected packages are (source name): libkdegames4, libksane, libkmahjongg4, kdewebdev
<santa_> as I said calligra would come later
<pitti> that sounds right
<acheronuk> thanks santa_  ^^
<pitti> but the whole stack won't migrate without calligra
<santa_> I know, I plan to do it too
<santa_> I just want to start with the easy ones to clear up the road
<acheronuk> calligra has been a long term pain in the posterior
<santa_> nothing we can't fix
 * pitti chases down some s390x regressions, looks like some weird gpg issue
<pitti> running process-removals
-queuebot:#ubuntu-release- Unapproved: sudo (trusty-proposed/main) [1.8.9p5-1ubuntu1.2 => 1.8.9p5-1ubuntu1.3] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-logs (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0-0ubuntu1 => 1:7.0.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-logs [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: docker.io (yakkety-proposed/universe) [1.12.1-0ubuntu14 => 1.12.1-0ubuntu15] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-clocks (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra)
<mwhudson> pitti: ^
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (yakkety-proposed) [1.12.1-0ubuntu15]
<pitti> mwhudson: thanks! (apparently got auto-accepted)
<mwhudson> oh yeah
<pitti> mwhudson: diff is 666 bytes. well done!
<mwhudson> haha
-queuebot:#ubuntu-release- Unapproved: accepted python-django-openstack-auth [sync] (yakkety-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-clocks [source] (yakkety-proposed) [3.22.1-0ubuntu1]
<pitti> apw, infinity, Laney: did you accept python-django-openstack-auth? I had a question about that for slangasek above
<pitti> the binary dep change looks broken
-queuebot:#ubuntu-release- Unapproved: spark (yakkety-proposed/universe) [2012.0.deb-11 => 2012.0.deb-11build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted spark [source] (yakkety-proposed) [2012.0.deb-11build1]
<Laney> pitti: It was me - I noticed after accepting, queue should have a fix in a second
<Laney> pitti: It's better to reject & discuss to reduce the chance of errors
<pitti> Laney: ok, good point -- a sync is easy to re-do
<Laney> you can fish things out of the rejected queue in any event
<apw> review is a bit more widespread, the chances of error is going up
-queuebot:#ubuntu-release- Unapproved: python-django-openstack-auth (yakkety-proposed/main) [2.4.1-2 => 2.4.1-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pyzo (yakkety-proposed/universe) [4.2.1-1 => 4.3.1-1] (no packageset) (sync)
<Laney> what's up with this maas?
<Laney> speaking of things chillaxing in the queue
-queuebot:#ubuntu-release- Unapproved: accepted pyzo [sync] (yakkety-proposed) [4.3.1-1]
<pitti> last time I looked at it, it replaced a 2.0 stable with a 2.1 beta without an FFE
<apw> Laney, last i looked at it the FFe was not yet acked, and slangasek said "thats on me"
<pitti> bug 1629909
<ubot5> bug 1629909 in maas (Ubuntu) "[FFE] New upstream release MAAS 2.1" [Critical,New] https://launchpad.net/bugs/1629909
<pitti> Laney: accepted p-django, thanks; it looked like a packaging bug, but I wasn't sure whether it was deliberate for some binary instead of some python module
-queuebot:#ubuntu-release- Unapproved: accepted python-django-openstack-auth [source] (yakkety-proposed) [2.4.1-2ubuntu1]
<Laney> ty
<santa_> pitti: http://gpul.grupos.udc.es/sponsor/kdewebdev_16.04.3-1ubuntu1.dsc
<santa_> let me know if you find something wrong
<pitti> santa_: LGTM, thanks! uploaded
<acheronuk> santa_: thanks. :) I think I would get there eventually with these (except calligra), but you can clearly get through it quicker than me.
-queuebot:#ubuntu-release- Unapproved: kdewebdev (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kdewebdev [source] (yakkety-proposed) [4:16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161010)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161010)
<Laney> davmor2: can you remind me where the promote-pending-to-current job output lives?
<Laney> i386 isn't promoted
<davmor2> Laney: out of my league jibel might be able to help you
<Laney> ok
<pitti> Laney, davmor: perhaps that one? https://platform-qa-jenkins.ubuntu.com/view/ubiquity/
<pitti> ah no, this one: https://platform-qa-jenkins.ubuntu.com/view/desktop/
<pitti> https://platform-qa-jenkins.ubuntu.com/view/desktop/job/ubuntu-yakkety-desktop-i386-smoke-oem/108/console
<pitti> wow, UTAH, that's still a thing
-queuebot:#ubuntu-release- Unapproved: gnome-music (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra, ubuntugnome)
<Odd_Bloke> slangasek: Could you promote the google-cloud-sdk in partner/yakkety-proposed to partner/yakkety, please?
<Odd_Bloke> (Anyone else should feel free to do that as well. ;)
<jibel> Laney, https://platform-qa-jenkins.ubuntu.com/view/All/job/mark-pending-current/
<Laney> pitti: how did you find that? :P
<Laney> pitti: jibel: thanks
<Laney> is this VPN only?
<jibel> Laney, it shouldn't. I'll promote i386
<santa_> pitti: http://gpul.grupos.udc.es/sponsor/libksane_15.08.3-1ubuntu1.dsc
<santa_> pitti: â I'm not sure if this one should be 1+build1 instead of 1ubuntu1
<pitti> Laney: firefox remembered :)
<pitti> santa_: it should be a straight sync instead :) (I'll do that)
<pitti> santa_: what's your Launchpad login name?
<santa_> pitti: panfaust
<Laney> jibel: cheers - quite hard to navigate the job's output
-queuebot:#ubuntu-release- Unapproved: libksane (yakkety-proposed/universe) [4:15.08.2-0ubuntu1 => 4:15.08.3-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libksane [sync] (yakkety-proposed) [4:15.08.3-1]
<jibel> Laney, in this case the installation didn't even start
<santa_> pitti: thank you very much, I have also checked whats up with libkdegames4; in debian they don't have src:libkdegames4 but they have src:libkdegames-kde4 (which provides the same than our src:libkdegames) so maybe it's possible to delete libkdegames4 and replace it with the debian one?
<jibel> I just hope it was just some flakiness of the server
<santa_> * which provides the same than our src:libkdegames4
<pitti> santa_: so that drops libkdegames6abi1-dbg, which is fine (no rdepends)
<pitti> santa_: so I agree, we can sync that (doing) and remove libkdegames4 source
<pitti> santa_: always better to clean up pointless diff to debian :)
<pitti> santa_: OOI, is there a compose key to produce 'â' ? (I didn't find one, I only know â and â)
-queuebot:#ubuntu-release- New sync: libkdegames-kde4 (yakkety-proposed/primary) [4:14.12.3-2]
<pitti> hah, they were even proposed in https://lists.x.org/archives/xorg-devel/2010-December/017287.html but never accepted
 * pitti would have guessed <Compose> | ^  but that doesn't work
<santa_> pitti: here AltGr+Shift+U gets you the â
-queuebot:#ubuntu-release- New: accepted libkdegames-kde4 [sync] (yakkety-proposed) [4:14.12.3-2]
<Laney> ââ
<santa_> haha
<pitti> no AltGr here
<santa_> hmm, I don't know then
<pitti> santa_: I wait until https://launchpad.net/ubuntu/+source/libkdegames-kde4/4:14.12.3-2 built everywhere and britney is happy wiht it, then remove the old source
<santa_> ok
<Laney> jibel: looks good now!
<pitti> santa_: https://launchpadlibrarian.net/289074039/upload_11009094_log.txt
<pitti>  santa_ i. e. libksane needs a version bump
<pitti> santa_: oh, our libksane-data is built from libkf5sane
<pitti> santa_: so libksane needs to drop the -data binary
<pitti> the binary from libksane only contains three icons anyway
<santa_> yeah, there's a transitional package in our frameworks based libksane
<pitti> santa_: I'll drop it from the libksane source, ok?
<pitti> or do you want to handle it?
<santa_> pitti: let me check something first ...
<santa_> pitti: yeah, the new frameworks based package contains the same files and the libksane-data transitional depends on the new one, so yes, go ahead please
-queuebot:#ubuntu-release- Unapproved: libksane (yakkety-proposed/universe) [4:15.08.3-1 => 4:15.08.3-1ubuntu1] (kubuntu)
<pitti> Laney: ^ review, SVP ?
<pitti> santa_: OK, that leaves libkmahjongg4 and calligra
<santa_> yeah let me check the first one
<pitti> santa_: could just be a sync of https://tracker.debian.org/pkg/libkmahjongg and dropping our source?
<pitti> same binaries otherwise, same upstream version
<pitti> santa_: ^ diff between  those looks good
<pitti> i. e. just some packaging noise (Vcs-*) and dropping -dbg
<santa_> pitti: if I checked properly we have the following in ubuntu: src:libkmahjongg4 (based on kdelibs 4) src:libkf5kmahjongg (based on kdeframeworks) src:libkmahjongg (based of kde frameworks but superseeded by libkf5kmahjongg)
<santa_> pitti: while debian has src:libkmahjongg (based on kdelibs4) and src:libkf5kmahjongg (based on kdeframeworks)
<pitti> santa_: no, libkmahjongg is only in Debian, not in Ubuntu; we have an almost identical source libkmahjongg4
<pitti> santa_: i. e. syncing libkmahjongg and removing libkmahjongg4 would fix it
<santa_> pitti: oh, ok I checked this https://launchpad.net/ubuntu/+source/libkmahjongg but it's not on yakkety, so indeed it seems you are right
<pitti> santa_: ok, doing
-queuebot:#ubuntu-release- New sync: libkmahjongg (yakkety-proposed/primary) [4:14.12.3-3]
<pitti> santa_: so same story as libkdegames-kde4; I'll wait until it lands in y and remove the old source
-queuebot:#ubuntu-release- New: accepted libkmahjongg [sync] (yakkety-proposed) [4:14.12.3-3]
<pitti> so, down to calligra ;)
<santa_> allright
<pitti> santa_: there is a possibility to temporarily demote calligra to yakkety-proposed (no reverse dependencies), so that the other bits can land
<pitti> santa_: that should unblock Kubuntu image builds
<pitti> (it seems calligra is not seeded / not on the images)
<pitti> takes some pressure off
<santa_> pitti: what does it mean demoting to -proposed? "removing" it from yakkety so it would be only in -proposed? something else?
<pitti> santa_: right -- and it would land back in y once it gets fixed to build and drop the -dbg package
<Laney> pitti: 'k, would be good to drop the .install next time too
<pitti> Laney: oh, why? (I usually try to keep the diff minimal)
<santa_> pitti: ok, regarding calligra I would also consider to include the latest upstream bugfix release; I also remember it was failing wot build after gcc6 becoming the default, but I didn't have time to dig into it back then. so if we could fix it later even with the demoting I would say go ahead
<santa_> note that debian got recently a newer version of calligra, but I'm afraid we shouldn't sync it happily without resolving some things fisrt
<santa_> i.e. files located on different binary packages and such
<santa_> s/wot/to/
-queuebot:#ubuntu-release- Unapproved: accepted libksane [source] (yakkety-proposed) [4:15.08.3-1ubuntu1]
<santa_> pitti: ok it seems we got 2.9.11 in git https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/calligra/commit/?id=f501c73645fc2f721e2e31c508edce9821f7e8a6
<santa_> I'm not sure about its state so I will try to talk with clive about this ASAP
<clivejo> santa_: I worked on that a long time ago and memory is very bad
<clivejo> from what I remember there was issues with it building on yakkety, I assumed the gcc version, but didnt look into it
<clivejo> I couldnt get anyone to sponsor me for the wily and xenial releases so I just moved on
<santa_> clivejo: ack. if I can get it in a working state would you upload?
<davmor2> jibel: netboot just broke I'll try and get the log off the system if I can
<clivejo> Im a bit busy with my $ work today, but if you ping me on telegram Ill deffo upload when I get the chance
<jibel> davmor2, what did you break?
<davmor2> jibel: looks like it failed to get a package and threw up E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
<jibel> davmor2, can you retry? perhaps a networking issue
<davmor2> jibel: indeed just trying to figure if I can get the log off the system in kvm but am failing dismally with the limited command in the system shell
<cjwatson> tsimonq2: I don't think that's a builder bug, but it's indeed not obvious what's going on.  It's just saying that "lb build" exited non-zero, and the odd thing is that it did so without saying why.  Probably a bug somewhere in livecd-rootfs/live-build/auto/build, if I had to guess.
<stokachu> slangasek: you hear from any of the juju qa guys yet?
-queuebot:#ubuntu-release- Unapproved: qemu (trusty-proposed/main) [2.0.0+dfsg-2ubuntu1.28 => 2.0.0+dfsg-2ubuntu1.29] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu7 => 2.20.3-0ubuntu8] (core)
<pitti> ^ review appreciated (my upload), from the release checklist
<davmor2> jibel: so waiting till after Lunch seems to of fixed it :)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.434 => 2.435] (desktop-core)
<cyphermox> good morning!
<pitti> cyphermox: bonjour !
-queuebot:#ubuntu-release- Unapproved: python-pex (yakkety-proposed/universe) [1.1.14-1 => 1.1.14-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-pex [sync] (yakkety-proposed) [1.1.14-2]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [116 => 117] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: janest-core-extended (yakkety-proposed/universe) [113.00.00-2build2 => 113.00.00-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: janest-core-kernel (yakkety-proposed/universe) [113.00.00-3build1 => 113.00.00-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted janest-core-extended [source] (yakkety-proposed) [113.00.00-2build3]
-queuebot:#ubuntu-release- Unapproved: janest-core (yakkety-proposed/universe) [113.00.00-4build1 => 113.00.00-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocaml-textutils (yakkety-proposed/universe) [112.17.00-3build1 => 112.17.00-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted janest-core-kernel [source] (yakkety-proposed) [113.00.00-3build2]
-queuebot:#ubuntu-release- Unapproved: ocaml-re2 (yakkety-proposed/universe) [113.00.00+dfsg-2.1build1 => 113.00.00+dfsg-2.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted janest-core [source] (yakkety-proposed) [113.00.00-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml-textutils [source] (yakkety-proposed) [112.17.00-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml-re2 [source] (yakkety-proposed) [113.00.00+dfsg-2.1build2]
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop)
<jbicha> I think e-d-s ^ is a good candidate for handling as an SRU, I set block-proposed on bug 1631955 which should keep it from landing in yakkety proper accidentally
<ubot5> bug 1631955 in evolution-data-server (Ubuntu) "Update e-d-s to 3.22.1" [Medium,In progress] https://launchpad.net/bugs/1631955
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (yakkety-proposed) [2.435]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [117]
<pitti> jbicha: thanks, accepted; we can still decide later on wheter to land it in -release or -updates
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (yakkety-proposed) [3.22.1-0ubuntu1]
<jbicha> ok
<pitti> apw: can I nag you for reviewing apport? we need to disable LP crashes for the final release, and otherwise this just fixes some tests for gnupg2 and updates translations
<LocutusOfBorg> pitti, what did happen to linbox?
<LocutusOfBorg> I'm getting accepted emails
<LocutusOfBorg> blocking givaro transition, 3 RC bugs in Debian, no rdepends
<LocutusOfBorg> I see thanks
<LocutusOfBorg> and it migrated again
<LocutusOfBorg> well, this morning a new linbox has been uploaded in debian, fixing the transition
-queuebot:#ubuntu-release- Unapproved: python-llfuse (yakkety-proposed/universe) [1.1.1+dfsg-3ubuntu1 => 1.1.1+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-llfuse [sync] (yakkety-proposed) [1.1.1+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: linbox (yakkety-proposed/none) [none => 1.4.2-1~build1] (no packageset)
<LocutusOfBorg> pitti, ^^
<philroche> infinity, Just a heads up that I have been assigned lead on the cloud images 16.10 release task. I have updated https://wiki.ubuntu.com/YakketyYak/Beta2 accordingly.
-queuebot:#ubuntu-release- Unapproved: accepted linbox [source] (yakkety-proposed) [1.4.2-1~build1]
<infinity> philroche: We're a bit past beta2. :)
<pitti> LocutusOfBorg: I bumped it to -proposed indeed, but it seems it comes back before givaro
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (yakkety-proposed/main) [3.22.1-0ubuntu1 => 3.22.1-0ubuntu2] (ubuntu-desktop)
<pitti> LocutusOfBorg: so I need to use a stronger hammer
<philroche> infinity, Understood :) Should I create a new "16.10 Release" page?
<LocutusOfBorg> :)
<infinity> philroche: No.
-queuebot:#ubuntu-release- Unapproved: fflas-ffpack (yakkety-proposed/universe) [2.2.1-2 => 2.2.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mythbuntu-meta (yakkety-proposed/multiverse) [0.89 => 0.90] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: accepted fflas-ffpack [sync] (yakkety-proposed) [2.2.2-2]
<LocutusOfBorg> if fflas-ffpack goes well, linbox will be fine also on s390x, in my ppa built everywhere
<jbicha> it helps if I test-build the right version of e-d-s, this new upload should build
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (yakkety-proposed) [3.22.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gfxboot-theme-ubuntu (yakkety-proposed/main) [0.20.1 => 0.21.0] (core)
<cyphermox> infinity: ^ translations for zh_HK, + making it possible to translate "Try Ubuntu Studio without installing" (although I don't think we'll get many translations on time)
<cyphermox> also, there's a ubiquity-slideshow for ubuntukylin.
<pitti> another one?
<pitti> cyphermox: http://launchpadlibrarian.net/289100037/gfxboot-theme-ubuntu_0.20.1_0.21.0.diff.gz does not actually have any translations for "Try Ubuntu..", so that won't do anything to fix that bug?
<cyphermox> pitti: bootloader.pot contains the string now -- like I said, we don't have translations yet but at least it's possible to translate it
<pitti> ah, so the changelog is just misleading, ok
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot-theme-ubuntu [source] (yakkety-proposed) [0.21.0]
<pitti> santa_, acheronuk: everything except calligra landed now (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
<pitti> so, if you want to unblock image builds, we can punt calligra to -proposed; but whether that's the right thing to do is your call
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-367 (yakkety-proposed/restricted) [367.44-0ubuntu3 => 367.57-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-367 [source] (yakkety-proposed) [367.57-0ubuntu1]
<jderose> tseliot: ooo, are you trying to get an FFE for nvidia 367.57? myself and the other system76 folks can give it a good round of testing today, if that can help the FFE case
<tseliot> jderose: no FFE is needed. The legacy drivers are coming too
<infinity> (Testing wouldn't hurt)
<tseliot> indeed
<jderose> tseliot: infinity: yep, we'll still test. there's a regression in 367.44 that we're really hoping this fixes...
<jderose> tseliot: so is an FFE not needed because the driver isn't in main? 367.57 will hit yakkety by release?
<tseliot> jderose: nvidia has never really been affected by FF. It's not in the image,
<jderose> gotcha, makes sense
<tseliot> well, my ending a sentence with a comma sure is orginal :P
<jderose> hehe
<jderose> tseliot: how soon will 367.57 hit yakkety-proposed?
<infinity> jderose: When someone accepts it.
<infinity> Oh, wait.  It was auto-accepted.
<infinity> jderose: When the publisher gets around to it. :P
<apw> and someone made it sad *cough*
<jderose> okay, cool
 * pitti nags someone about reviewing apport and mythbuntu-meta
<tseliot> :)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (yakkety-proposed/restricted) [340.96-0ubuntu6 => 340.98-0ubuntu1] (ubuntu-desktop)
<slangasek> stokachu: I have mail about juju from over the weekend, yes
<slangasek> Odd_Bloke: done
<infinity> Attention release team: There's a new kernel (and matching d-i) making its way through the pipes, so have a look at excuses and queues and see of there are other thing we should be fixing and/or slipping in for the inevitable respin later today.
<Odd_Bloke> slangasek: Thanks!
 * Laney wants to slide 2 things in
<infinity> Laney: Oh my.
<Laney> Gird your loins
 * Laney wonders what "gird" means
<infinity> "Put on a jock strap" would be the modern equivalent.
<Odd_Bloke> GIRD is a microkernel, isn't it?
<slangasek> pitti: yeah I didn't look too closely at python-django-openstack-auth to make sure the Debian package didn't have bugs, just that it satisfied a versioned build-dep and the Ubuntu delta was obsolete
<santa_> pitti: could we upload calligra 2.9.11 later if we do that?  even if it ends up in yakkety-updates that would be fine
<slangasek> not to be confused with the hurdy-gurdy
<infinity> slangasek: It's too early in the morning for Swedish Chef.
<Odd_Bloke> That's GNU/hurdy-gurdy to you.
<pitti> santa_: sure; I'm off for dinner now, back in ~ 3 hours
 * infinity is now tempted to do a Swedish Chef rendition of the Free Software Song.
<infinity> This could be my ticket to fame and fortune.
<slangasek> jern Ã¥s nu and shur dee serftwer
<stokachu> slangasek: thanks, working with them now
<santa_> pitti: then when you are back, go ahead with the -proposed demoting of calligra please, I'm working on calligra 2.9.11 now
<slangasek> pitti: ^^ wrt juju, was streams.canonical.com at any point on the no_proxy list for autopkgtest?
 * infinity goes to find breakfast to fuel his (almost certainly long) day.
<Laney> would someone be so kind as to nuke indicator-keyboard/s390x please?
<Laney> new builds are depwait
<slangasek> Laney: doing
<cyphermox> infinity: would have a new ubiquity to land, trying to see if there are other fixed needed to go along with it.
<Laney> slangasek: cheers
<slangasek> Laney: what dep makes it uninstallable?
<Laney> slangasek: I think url-dispatcher
 * Laney looks
<slangasek> Laney: confirmed, thanks
<Laney> Yeah
<slangasek> Laney: done
<Laney> Now to wait for bileto to catch up with this fact
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (yakkety-proposed/main) [0.4+16.10.20160927-0ubuntu1 => 0.4+16.10.20160927-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-42.62] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-42.62]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-98.145~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-42.62~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-71.79] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-71.79~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-98.145] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-71.79]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-98.145~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-42.62~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-71.79~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-98.145]
-queuebot:#ubuntu-release- Unapproved: wine (yakkety-proposed/universe) [1.8.4-1ubuntu2 => 1.8.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (yakkety-proposed) [1.8.5-1ubuntu1]
<infinity> cyphermox: New ubiquity is fine if it happens soonish.  Make sure the translations are fresh too, while you're at it.
<cyphermox> waiting for the translation export...
-queuebot:#ubuntu-release- New binary: linbox [ppc64el] (yakkety-proposed/universe) [1.4.2-1~build1] (no packageset)
<LocutusOfBorg> pitti, ^^ needs removals of s390x and powerpc to migrate :/
<LocutusOfBorg> same on Debian
-queuebot:#ubuntu-release- Unapproved: nova-lxd (yakkety-proposed/main) [14.0.0~rc1-0ubuntu1 => 14.0.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: indicator-keyboard (yakkety-proposed/main) [0.0.0+16.10.20160808-0ubuntu1 => 0.0.0+16.10.20161010-0ubuntu1] (ubuntu-desktop) (sync)
<infinity> LocutusOfBorg: Because no one can be bothered to fix the endian bug in fflas-ffpack?
<infinity> LocutusOfBorg: That seems like a poor excuse to go deleting binaries.
-queuebot:#ubuntu-release- New binary: linbox [i386] (yakkety-proposed/universe) [1.4.2-1~build1] (no packageset)
<Laney> there's my two things (unity-settings-daemon & indicator-keyboard) for review
 * Laney takes off for a bit
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (yakkety-proposed) [2.20.3-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted mythbuntu-meta [source] (yakkety-proposed) [0.90]
<pitti> slangasek: no, it wasn't; looking into juju?
<pitti> slangasek: I believe the problem is that the proxy vars don't get copied into the created container
<LocutusOfBorg> infinity, upstream is working on it, and if I can choose between having linbox out of yakkety, or having linbox inside but without BE archs, I choose the latte
<LocutusOfBorg> latter
<LocutusOfBorg> but you are release team, I of course respect and follow your best opinion
<LocutusOfBorg> amd64 failed, this package deserves to be out
<infinity> LocutusOfBorg: Why is "out of yakkety" the other option?  It seems to be in yakkety right now.
<LocutusOfBorg> damn, in my ppa it didn't fail
<tsimonq2> cyphermox: ok
<tsimonq2> whoops
<tsimonq2> cjwatson: ok
<LocutusOfBorg> infinity, https://launchpad.net/ubuntu/+source/linbox/+publishinghistory
<LocutusOfBorg>  Deleted 2 hours ago by Martin Pitt
<LocutusOfBorg> blocking givaro transition, 3 RC bugs in Debian, no rdepends
<LocutusOfBorg> look above,
<LocutusOfBorg> for "LocutusOfBorg: so I need to use a stronger hammer"
<infinity> And the old version can't be rebuilt against the new givaro?
<LocutusOfBorg> no
<LocutusOfBorg> 3 RC bugs in debian about that issue
<infinity> Fun.
<LocutusOfBorg> this is why I syncd the two packages and BTW fflas-ffpack seems to be used only by linbox
<LocutusOfBorg> so, this is why I didn't care :)
<infinity> Then deleting it outright is probably the right answer indeed.
<LocutusOfBorg> nice to see I got it right, thanks :) I'm still a n00b in such britney stuff
<infinity> And blocking the current one in proposed to copy forward to ZZ.
<LocutusOfBorg> I think ZZ will be good, assuming upstream fixes that BE stuff
<infinity> Well, I guess it'll be blocked by its dep on the new fflas-ffpack anyway, which won't be migrating.
<LocutusOfBorg> and I prefer to focus on other stuff
<infinity> Oh, no, it has no runtime dep on fflas-fpack.  So, should block it artificially before deleting the old one.
<LocutusOfBorg> sorry but I failed to parse your sentences a couple of messages ago :p I fully support you! :D
<infinity> I fully support myself too.
-queuebot:#ubuntu-release- New binary: linbox [arm64] (yakkety-proposed/universe) [1.4.2-1~build1] (no packageset)
<infinity> Blocking bug filed, re-removing the old version from release.
<slangasek> pitti: yes, it was about juju, thanks.  I figured it was a proxy environment issue of some kind.  stokachu ^^ see pitti's comments above?
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- New binary: linbox [armhf] (yakkety-proposed/universe) [1.4.2-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lsh-utils (yakkety-proposed/universe) [2.1-9build2 => 2.1-9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lsh-utils [source] (yakkety-proposed) [2.1-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (yakkety-proposed/universe) [16.10.8 => 16.10.9] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubiquity (yakkety-proposed/main) [16.10.13 => 16.10.14] (core)
<cyphermox> infinity: ^
 * cyphermox -> lunch, back shortly
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-22.24] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-22.24]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (yakkety-proposed) [16.10.14]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (yakkety-proposed) [16.10.9]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.5 => 1:16.10.6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [source] (yakkety-proposed) [0.4+16.10.20160927-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.6]
<stokachu> slangasek: can you remove rc3 so I can reup?
<stokachu> otherwise i can just bump the package rev
<stokachu> ill just bump it
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.16 => 1:16.04.17] (core)
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu1.16.10.1 => 2.0~rc3-0ubuntu2.16.10.1] (ubuntu-server)
<balloons> slangasek, stokachu has uploaded what I hope is a fix. The short version is we were relying on the old lxd-bridge-proxy for our lxd tests. With the new lxd networking, the tests didn't get the proxy settings. It should pick up and be passed now, assuming HTTP_PROXY is set
<pitti> santa_: ack; I previously missed that it has already been in -proposed for 52 days, so removing from y-release; then kde-runtime should finally land and kubuntu images can build
-queuebot:#ubuntu-release- Unapproved: rejected camo [source] (xenial-backports) [2.3.0+dfsg-1~ubuntu16.04.1]
<pitti> ^ why the reject? bug 1615415 didn't get a response, particularly not a nack
<ubot5> bug 1615415 in Xenial Backports "Please backport camo 2.3.0+dfsg-1 (universe) from yakkety" [Undecided,New] https://launchpad.net/bugs/1615415
<pitti> infinity, apw, bdmurray, RAOF, any SRUer? ^
<micahg> I rejected as it was missing the bug #
<micahg> that was in backports
<slangasek> stokachu: yeah, once it's been accepted, you have to bump the version number anyway
<pitti> micahg: ah, ok
<slangasek> stokachu: (accepted)
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu2.16.10.1]
<cyphermox> infinity: slangasek: any idea if it's on purpose that ppc64el server installs don't get a preseed?
<cyphermox> ie. that yields a standard system, not one with the server seed installed.
<slangasek> cyphermox: that sounds like a bug to me.
<cyphermox> to me too, just checking
<infinity> cyphermox: It's a bug.
<infinity> One I should fix today so I stop forgetting.
<cyphermox> well, I'm filing the bug and I know what needs to be done, so I can just fix debian-cd
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1632078
<ubot5> Ubuntu bug 1632078 in debian-cd (Ubuntu) "ppc64el installs not preseeded via grub" [Undecided,New]
<infinity> cyphermox: Fixing it works too.
<cyphermox> infinity: https://code.launchpad.net/~cyphermox/debian-cd/ppc64el/+merge/308075
<infinity> cyphermox: Will look when LP gives me a diff.
<infinity> Someone needs to email me a shawarma.
<cyphermox> sorry, no. garlic sauce clogs up the interwebz pipez.
<infinity> :(
<infinity> I have a family Thanksgiving dinner in two hours, I suppose I should just wait patiently for turkey.
<valorie> infinity: Canadian Thanksgiving?
<cyphermox> yep
<valorie> already
<valorie> wow, here it is Indigenous Peoples day
<stokachu> slangasek: thanks man
<infinity> cyphermox: Is that a cargo-cult from x86?  At least the vga= is not PPC-friendly.
<cyphermox> it was
<cyphermox> so, woops.
<infinity> Not sure if we do the gfxpayload thing on PPC either.  Would have to check an installed system.
<cyphermox> fwiw though I have no clue why vga is set there on x86, it would be different than the other boot things
<cyphermox> ah, yeah
<cyphermox> that I can go check now
<infinity> I believe we set vga on x86 to force an 80x24 console or some such.
<cyphermox> well, maybe, but just for the MAAS entries?
<infinity> Good point.  Maybe the commit messages have a clue.  But also, not touching it this close to release.
<cyphermox> oh, they aren't just for maas
<cyphermox> ah, I see
<cyphermox> not applied for grub, applied for gfxboot
<infinity> gfxboot needs to die.  Legacy BIOS systems are going away.
<infinity> We either need a more accessibility-friendly way to grub, or... We need a more accessibility-friendly way to grub. :/
<cyphermox> oh, speaking of which
<cyphermox> I did want to make grub pretty
<infinity> Pretty would be nice, accessible is the real concern, though.
<infinity> Keyboard equals man and all that.
<cyphermox> there are some ways to do that, thought still unsure about how accessible it will be
<cyphermox> yeah, I know
<cyphermox> our accessibility option for gfxboot is that if you don't touch anything you get maybe-ubiquity though
<infinity> Anyhow, out of scope for this release.
<cyphermox> in my VM looks like set gfxpayload=keep does nothing at all, perhaps I should just get rid of it
<infinity> Is it there in the installed system?
<infinity> If so, it's obviously harmless, and I'm happy with the same useless option being on (or off) in both.
<cyphermox> if you'd asked before I nuked it, I would have been able to tell now
<cjwatson> It wouldn't at all surprise me if the effect of gfxpayload=keep were difficult to observe in a VM.
<cyphermox> cjwatson: sure, but even more on ppc64el I bet
<cjwatson> Oh indeed.
 * cjwatson <- context-free state machine
<cyphermox> no worries
<cjwatson> vga= was for performance (!), I believe
<cjwatson> debian-cd r1574
<cyphermox> if it's not there after install I'll remove it and we can think of adding it if someone uses a screen and notices an issue
<cyphermox> cjwatson: sound right. it's also not added for the grub entries on amd64, only for the isolinux ones
<cjwatson> I don't know if it's still true, but at the time d-i was agonisingly slow in kvm without it
<infinity> Hrm.  Actually remarkably hard to tell what it's set to on a running system, cause it's hidden behind a function I can't execute in my head.
<infinity> Ahh, but I do have vt.handoff on cmdline, which I think only happens if gfxpayload=keep
<infinity> So, yes, it's keeping on installed systems.
<infinity> cyphermox: Based on the above investigation, I'd say an updated MP that removes the vga= but is otherwise unchanged should be fine.
<infinity> Now, I wonder if this is responsible for one of the error messages we get on boot from grub.
<infinity> Which I kept meaning ti find time to debug. :P
<cyphermox> what error message?
<infinity> Do you not get annoying messages on grub on PPC anymore?
<infinity> I don't think I've booted a yakkety lately.
<cyphermox> we also don't set GRUB_GFXPAYLOAD_LINUX; which probably would be useful for gfxpayload=keep.
<cyphermox> I haven't noticed, but I need to quickly switch HDMI inputs at just the right time when booting to be able to see the messages
<infinity> cyphermox: I mean on ppc64el with a VM.
<cyphermox> you said PPC
<infinity> Well, same-same, but the PPC ISOs still use yaboot, which would make it harder to show off a grub issue. :)
<cyphermox> I don't know. we had some issues on trusty because of missing patches
<cyphermox> ppc64el d-i running now, will see soon
-queuebot:#ubuntu-release- Unapproved: e2fsprogs1.41 (yakkety-proposed/universe) [1.41.14-2 => 1.41.14-2ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: yaboot (yakkety-proposed/main) [1.3.17-2ubuntu1 => 1.3.17-2ubuntu2] (core) (sync)
<infinity> And speaking of yaboot... ^^
-queuebot:#ubuntu-release- Unapproved: accepted e2fsprogs1.41 [sync] (yakkety-proposed) [1.41.14-2ubuntu1]
<cyphermox> I don't see grub errors on ppc64el.
<infinity> Kay.  Maybe I'm living in the past.
<infinity> No "press any key" nonsense anymore either?
<infinity> On installed systems, not the ISO.
<cyphermox> nope
<infinity> Well, yay.
<cyphermox> press any key was fixed some time ago
-queuebot:#ubuntu-release- Unapproved: accepted yaboot [sync] (yakkety-proposed) [1.3.17-2ubuntu2]
<cyphermox> also, updated that code branch to remove vga=
<infinity> Ta.
<infinity> diff from 340.96-0ubuntu6 to 340.98-0ubuntu1 (192.5 MiB)
<infinity> ORLY.
<infinity> Diff, buddy, did you diff binaries for me?
<cyphermox> wat.
<infinity> Cause that would be super helpful.
-queuebot:#ubuntu-release- Unapproved: accepted indicator-keyboard [sync] (yakkety-proposed) [0.0.0+16.10.20161010-0ubuntu1]
<infinity> Oh, I bet it's a shar.
<infinity> Because nvidia lives in 1992.
<infinity> Definitely not clicking the link to find out.
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (yakkety-proposed) [14.0.0-0ubuntu1]
<tsimonq2> infinity: I volunteer to freeze up my web browser. Link?
<tsimonq2> :P
<tsimonq2> q
<tsimonq2> whoops
<tsimonq2> ah ok, grepped the logs and found out what you were talking about
 * Laney makes a face at ubuntu-system-settings' various excuses
<infinity> Someone must have forced that ppc thing before.
<infinity> Or it traded for a different uninstallable. :/
<Laney> It got promoted with the previous upload
<Laney> Would component-mismatches not yell?
<infinity> Oh.  It was in universe before?
<Laney> Ya
<Laney> unity 8 shizzle
<infinity> c-m might get confused about issues on only some arches.
-queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu1 => 1:45.3.0+build1-0ubuntu2] (mozilla, ubuntu-desktop)
<Laney> I wonder if this dependency is actually real or just a hack
<infinity> I wonder why  libubuntu-platform-hardware-api-dev only exists on some arches.
<infinity> Oh, gross, it depends on hybris.
<infinity> Because we totally need that on every non-Android system.
<tsimonq2> infinity: You were right, either it tried to diff binary or Vim is acting up... http://img.ctrlv.in/img/16/10/10/57fbff376a583.png
<infinity> Laney: I'm so glad unity8 still depends on Android bits years after I suggested that might be silly. :(
<Laney> Archive schmarchive
<infinity> Anyhow, the arm64 build suddenly failing only two weeks after the last build is more curious.
<infinity> We can hand-wave past the powerpc thing if we have to.
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (xenial-security/universe) [4.4.0.1030.22 => 4.4.0.1030.22] (kernel) (sync)
<Laney> Mirv's been going on abotu something that might be this
<infinity> But that regression should be sorted.
<infinity> Since arm64 is a unity8 target.
<Laney> Kernel/release upgrade on the buildds
<Laney> Making Qt stuff break in weird and wonderful ways
<Laney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630906
<ubot5> Ubuntu bug 1630906 in linux (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,Confirmed]
<infinity> cjwatson: ^^ Is there any way we can paper over that between now and release?
<infinity> Clearly warrants further investigation, but not sure NOW is the time.
<infinity> wgrant: ^^
<Laney> I bet this gnome-settings-daemon alt-dep can be switched to gnome-settings-daemon-schemas
<infinity> Is that a thing in main?
<Laney> Yeah, it's a package split that got done ages ago so that gnome-settings-daemon the binary could move to universe
<Laney> ages ago, but after that dependency came into existence
<infinity> Okay, I have to run off to family dinner soon.  Will be back later to garden excuses, migrate what I can, britney block the world, and spin new images.
<infinity> slangasek: ^
<infinity> (The dinner will be short, ish, they know I'm working this evening)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (yakkety-proposed/main) [0.4+16.10.20160927-0ubuntu2 => 0.4+16.10.20160927-0ubuntu3] (no packageset)
<Laney> ^- as discussed
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [source] (yakkety-proposed) [0.4+16.10.20160927-0ubuntu3]
<slangasek> infinity: cool, enjoy your canadian turkey and canadian stuffing
<cjwatson> infinity: So, um, I don't know.  It would be great if the kernel team could weigh in on the flag that can allegedly be flipped to avoid the problem.  apw?
<cjwatson> infinity: I acknowledge that dropping back to wily would be a quick fix, but I'm not sure I'm very comfortable with it.  Dunno what wgrant thinks.
<wgrant> cjwatson, infinity: Hm, is it the 48-bit VA change again, or something else?
<cjwatson> 48-bit VA apparently.
<wgrant> Ah yes
<wgrant> cjwatson, infinity: So my preferred solution to this would be to build a custom kernel with that unset, which we can relatively easily force into the images.
<wgrant> (I mean, preferred behind fixing Qt, which seems like it might be a non-starter due to the ABI break)
<cjwatson> Do we know that unsetting that has reasonably mild consequences?
<cjwatson> And would it be a long-term divergence?
<wgrant> cjwatson: Well all it does is fix more bits of the addresses, and it matches the behaviour we had until a week ago.
<wgrant> I assume we were 42 before but I haven't checked.
<wgrant> On Fri, Jan 29, 2016 at 06:23:35PM -0700, dann frazier wrote:
<wgrant> > On NUMA implementations of Cavium ThunderX, node1 memory addresses start with
<wgrant> > bit 40 set to 1, and therefore requires >= 41 bits of VA.
<wgrant> That was the motivation.
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.3-0ubuntu1~ubuntu16.04.1 => 2.0.4-0ubuntu1~ubuntu16.04.1] (edubuntu, ubuntu-server)
<wgrant> So wouldn't be a problem for scalingstack guests. The only downside I see is that anything that detects VA width (please no, surely not, but people do it with page sizes...) would continue to build for a smaller one, but that is still no worse than a week ago.
<cjwatson> It'll do for now, just worried about having to run a forked kernel long-term.
<wgrant> Oh sure, that wouldn't be ideal.
<wgrant> But releasing yakkety like that doesn't hurt us there.
<wgrant> xenial's the big problem and delaying the transition doesn't change that.
<wgrant> cjwatson: So I guess we prepare a one-off (since we don't care about security updates for the guests) -narrow variant of xenial's linux with CONFIG_ARM64_VA_BITS=39 and CONFIG_PGTABLE_LEVELS=3, and hack l-b-i-m to install it and remove -generic?
<cjwatson> Having to change the flavour is an annoying amount of work, but I guess there's no alternative if we don't want surprise sidegrades to generic.
<wgrant> cjwatson: Well we could also hack l-b-i-m to fix the -generic version I suppose.
<wgrant> Though that seems like it would require more invasive l-b-i-m changers.
<cjwatson> Some kind of apt preferences hack perhaps.
<wgrant> I guess if we stuck -meta in the PPA as well then preferences would work.
<cjwatson> We'd probably want to anyway.
<cjwatson> FSVO want.
<wgrant> OK, will prepare a kernel and add preferences support to l-b-i-m.
<wgrant> And that should do it I think.
<wgrant> (also, god help us when amd64 first makes use of the 52-bit extension)
<wgrant> Wait
<wgrant> cjwatson: isn't the rationale in https://lists.ubuntu.com/archives/kernel-team/2016-February/070897.html completely bogus?
<wgrant> The physical addresses have bit 40 set...
<wgrant> But that has no implications on VA size unless arm64 Linux is weird.
<cjwatson> Err.  Don't know this well enough to be able to work it out at gone midnight.
<wgrant> Fair.
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.4-0ubuntu1~ubuntu16.04.2 => 2.0.5-0ubuntu1~ubuntu16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.0.4-0ubuntu1~ubuntu16.04.1 => 2.0.5-0ubuntu1~ubuntu16.04.1] (edubuntu, ubuntu-server)
#ubuntu-release 2016-10-11
-queuebot:#ubuntu-release- Unapproved: gnome-devel-docs (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra)
<tsimonq2> sarnold: around? I'd like to get bug 1630700 fast-tracked through
<ubot5> bug 1630700 in kcoreaddons (Ubuntu Precise) "CVE - KMail - HTML injection in plain text viewer" [Undecided,In progress] https://launchpad.net/bugs/1630700
-queuebot:#ubuntu-release- Unapproved: ansible (xenial-proposed/universe) [2.0.0.2-2 => 2.0.0.2-2ubuntu1] (no packageset)
<infinity> wgrant: If a custom kernel will get us over the hump Right Now, let's do it.
<infinity> wgrant: Agreed it's a terrible long-term solution, but not being able to build things we want on images today is also pretty ungood.
<wgrant> infinity: Absolutely.
<infinity> wgrant: Other than kernel build time, which I'm intimately familiar with, what kind of turnaround could we get on that?
<wgrant> infinity: Soonâ¢
<infinity> (And said kernel could be neutered in debian/rules to exit 1 on DPKG_BUILD_ARCH != arm64, arm64 actually builds pretty fast compared to most)
<infinity> Err, HOST_ARCH.
<infinity> Though either would work in a non-cross env. :P
<wgrant> infinity: We can get new images out in less than half an hour one the packages are available.
<wgrant> Usually well less than half an hour, now that arm64 VMs aren't silly :)
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (xenial-security/universe) [4.4.0.1030.22 => 4.4.0.1030.22] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22]
<infinity> wgrant: Need any help wrangling kernel packaging, or are you good there?
<wgrant> infinity: I'm reasonably competent, particularly when not changing ABI :)
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22]
<infinity> wgrant: Heh.  When not changing ABI, the best trick is to append to the current changelog entry and NOT MAKE A NEW ONE.
<infinity> Then no ABI checker invoked, and magic.
<wgrant> Precisely.
<infinity> wgrant: Right, then I'll keep out of your hair.
<wgrant> It took me a couple of years to work that hack out.
<infinity> wgrant: Lemme know when you think it's ready for a spin, and I'll lob things at it.
<infinity> I should be up for a Very Long While still.
<infinity> In the process of reversing my clock.
<infinity> Well, inverting, not reversing.
<wgrant> infinity: It'll be a good while, currently in a couple of meetings.
<wgrant> Though hopefully wrapping up now, then will get onto it properly.
<infinity> wgrant: All good.  I intend to be awake all through London work day.
<infinity> wgrant: TO set a trend for the rest of the week.
<infinity> How I plan to do this, given that I woke up at 7am Calgary time, I'm not yet sure.
<infinity> But I suspect caffeine might come into play.
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu481 => 20101020ubuntu482] (core)
<tsimonq2> infinity: Staying on UK time zones are fun, I did that over my summer vacation for a few weeks. :P
<infinity> tsimonq2: I do it all the time, but it's always harder to shift one's clock on purpose rather than by accident. :P
<tsimonq2> infinity: I can agree with that.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu482]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-devel-docs [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (yakkety-proposed) [340.98-0ubuntu1]
<cyphermox> infinity: logging off for some sleep. use ancient communication methods should you really need me for some reason.
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161011)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161011)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Final] (20101020ubuntu482) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Final] (20101020ubuntu482) has been added
<apw> cjwatson, normally in 64bit all of physical memory is "direct mapped" so if the h/w is using a large physical space then we will chew a large chunk of KVA for the direct map
<apw> still not clear as to why that is visible in userspace in any sense
-queuebot:#ubuntu-release- New sync: openfoam (yakkety-proposed/primary) [4.0+dfsg1-3]
-queuebot:#ubuntu-release- Unapproved: python3.6 (yakkety-proposed/universe) [3.6.0~b1-1ubuntu2 => 3.6.0~b2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (yakkety-proposed) [3.6.0~b2-1]
-queuebot:#ubuntu-release- New: accepted linbox [arm64] (yakkety-proposed) [1.4.2-1~build1]
-queuebot:#ubuntu-release- New: accepted linbox [i386] (yakkety-proposed) [1.4.2-1~build1]
-queuebot:#ubuntu-release- New: accepted linbox [armhf] (yakkety-proposed) [1.4.2-1~build1]
-queuebot:#ubuntu-release- New: accepted linbox [ppc64el] (yakkety-proposed) [1.4.2-1~build1]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (yakkety-proposed/restricted) [304.131-0ubuntu5 => 304.132-0ubuntu1] (ubuntu-desktop)
<pitti> infinity, apw: I'm going to kill the currently running linux tests again, as they still keep breaking the testbed and are stuck in an eternal retry loop;  but I'll try to collect the console-log this time
<pitti> apw: filed bug 1632252 with some logs/details
<ubot5> bug 1632252 in linux (Ubuntu) "linux autopkgtest kills sshd in testbed" [Undecided,Confirmed] https://launchpad.net/bugs/1632252
<pitti> apw: sounds like sshd gets OOM-killed
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161011)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161011)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161011)
-queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
<pitti> infinity, slangasek: ^ this drops the hard python3-launchpadlib dependency again (from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz) and adds a graceful fallback
<pitti> this should clean up most of http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<cjwatson> which will mean that the PPA changelog handling randomly doesn't work for users depending on whether they happen to have python3-launchpadlib installed?
<cjwatson> I mean, I guess I see why you're doing it, but avoiding this was why I asked in review of that feature for it to be just made a dependency rather than conditional
<pitti> cjwatson: I'd rather seed python3-launchpadlib on desktop then, TBH
<pitti>  maybe the feature can also be reworked to do a single REST call via urllib, but I don't want to do this "under the gun"
<cjwatson> pitti: seeding in desktop seems like a reasonable compromise, if people are OK with that
<pitti> it doesn't do anything authenticated, so I guess getting a changelog with plain urllib should be fairly easy
<cjwatson> maybe as a Recommends
<pitti> *nod*
<pitti> not sure who has the last word on that, but I'm happy to make the seed changes and update ubuntu-meta if we want to go ahead with this
<cjwatson> It should be relatively easy to redo by-hand without lplib, indeed
<cjwatson> One problem with seeding in desktop is, which desktops
<pitti> hm -- how about we move the Depends: to update-manager?
<pitti> (it previously was on python3-update-manager which is in standard)
<pitti> update-manager is optional
<pitti> then we don't need seed changes, and this conceptually sounds "more correct"
<pitti> and to u-m-kde
 * pitti self-rejects and reuploads, that's better than fiddling with seeds
<cjwatson> Seems reasonable if you retain the optionality in the code
<cjwatson> This is how to do what u-m does by hand:
<cjwatson> $ curl -s 'https://api.launchpad.net/devel/archives?ws.op=getByReference&reference=%7Ecjwatson/ubuntu/ppa' | jq .self_link
<cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa"
<cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa?ws.op=getPublishedSources&source_name=ant&exact_match=true&version=1.9.7-3ppa1' | jq '.entries[0].self_link'
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (yakkety-proposed) [1:16.10.7]
<cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285"
<cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285?ws.op=changelogUrl' | jq
<cjwatson> "https://launchpad.net/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285/+files/changelog"
<cjwatson> but you do have to make sure that all the quoting is correct
<pitti> yeah, TBH that sounds more like a z thing
<cjwatson> https://api.launchpad.net/devel/archives is a hardcoded base, and all of reference, source_name, and version are inputs that must be URL-escaped
<cjwatson> Easy enough, but yeah, can be done in z
<cjwatson> (Do we have a name yet?)
<pitti> for the Zealous Zombie?
<Odd_Bloke> Zenial Zebra.
-queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
<acheronuk> some have been guessing at Zazzy Zorilla
<pitti> infinity, slangasek: ^ updated update-manager as per discussion with cjwatson; this is now self-contained (does not need seed changes)
<pitti> I think we can drop xml-core's Depends: perl, to clean up that from "standard" as well (only using modules from perl-base); will confirm and then upload/file Debian bug
<pitti> with these two, the remaining priority-mismatch items should be valid
<cjwatson> acheronuk: Yeah, I'm ignoring guesses because they're ~never right
<cjwatson> pitti: the changelog seems a bit wrong now?
<cjwatson> pitti: wait, maybe I'm suffering from caching
<pitti> cjwatson: ah, it should probably say "lower .. from python3-update-manager's Depends"?
<pitti> cjwatson: http://launchpadlibrarian.net/289188605/update-manager_16.10.7_source.changes is the current version that I uploaded
<cjwatson> no, I'm OK with it once I avoid looking at the old cached version
<cjwatson> (but am no longer release team, so not accepting)
<acheronuk> cjwatson: yep, my guess always seems wrong
-queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.15 => 0.15ubuntu1] (core)
<pitti> ^ will fix the perl priority-mismatches. This was a recent regression from https://anonscm.debian.org/git/debian-xml-sgml/xml-core.git/commit/?id=fed34e0
<pitti> i. e. accidentally dropping the dh_perl -d option
<pitti> (also filed as Debian bug 840410)
<ubot5> Debian bug 840410 in xml-core "xml-core: Drop perl dependency" [Wishlist,Open] http://bugs.debian.org/840410
<pitti> Laney: ^ as this is quite straightforward, mind reviewing/accepting this?
<pitti> reviewing u-m is also appreciated of course, to clean up most of priority-mismatches so that we can get it release-ready
<Laney> pitti: sure
<tsimonq2> cjwatson: I'm still voting for Zealous Zebu :P
<tsimonq2> s/voting/hoping/
<acheronuk> tsimonq2: lol. you changed your mind AGAIN?
<tsimonq2> acheronuk: no I only said Zazzy Zorilla because I thought Barry Warsaw leaked the codename, turns out he made it up... :P
<acheronuk> tsimonq2: I swear there is a subtle disinformation plot by canonical each year to keep the real one under wraps
-queuebot:#ubuntu-release- Unapproved: accepted xml-core [source] (yakkety-proposed) [0.15ubuntu1]
<tsimonq2> acheronuk: cjwatson linked me to a graph yesterday...
 * tsimonq2 finds it
<tsimonq2> acheronuk: http://people.canonical.com/~cjwatson/tmp/release-name-notice.png
<acheronuk> interesting
<Laney> pitti: unorthodox syntax on Suggests there
 * Laney built it to check it works (it does)
 * rbasak believes he predicted Yakkety Yak before it was named
<rbasak> Though in hindsight it was obvious I guess
<Laney> and argh at all the trailing spaces in update-manager/d/control
<Laney> (not new)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.7]
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-2 => 10.2.7-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-3]
<pitti> Laney: you mean trailling commas?
<pitti> Laney: trailing spaces> yeah, my vim loudly complains too, but minimal diff for review, etc.
<Laney> pitti: It's like
<Laney> Suggests:
<Laney>           python3-...
-queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~rc1+dfsg1-1 => 4.0.0+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu2.16.10.1 => 2.0~rc3-0ubuntu3.16.10.1] (ubuntu-server)
<cyphermox> good morning
<pitti> Laney: oh, oops
<pitti> Laney: fixed in bzr
<pitti> hey cyphermox
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [sync] (yakkety-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu3.16.10.1]
<pitti> apw: do you know about the fate of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux ?
<pitti> I suppose we should release that RSN so that we can rebuild images?
<apw> pitti as far as i can tell it is as good as the previous one, so i guess as those tests are not going to ever come in we'll need to hint it
<pitti> apw: oh right -- I was blindly assuming they would use a tracking bug
<pitti> apw: hinting
<pitti> seb128, jbicha: do we want to let bug 1631955 into yakkety, or remain as an SRU?
<ubot5> bug 1631955 in evolution-data-server (Ubuntu Yakkety) "Update e-d-s to 3.22.1" [Medium,Fix committed] https://launchpad.net/bugs/1631955
<pitti> (seb128, jbicha: we still have a kernel and two other packages to land before respinning images)
<seb128> pitti, letting jbicha comment, I didn't look at this update
<seb128> pitti, we don't plan respins after that?
<pitti> seb128: I don't know; just saying that the current images can't possibly be final
<seb128> pitti, it's a bit suboptimal that we have the current firefox blocked in proposed but I guess it is what it is now?
<seb128> k
<pitti> seb128: well, firefox is FTBFS, not much that we can do other than fixing it
<pitti> but that's fine as an SRU
<seb128> not optimal though
<seb128> there might be some security issues in the previous verison
<seb128> oh, also that's using an google api key that we revocated
<seb128> the new key was added in https://launchpad.net/ubuntu/+source/firefox/49.0+build4-0ubuntu1
<pitti> well, if we have a fix now/today, I'm sure everyone would be happy to get it in :)
<seb128> chrisccoulson, ^
<seb128> pitti, or we could declared firefox unsupported on ppc64el like it is on powerpc and s390x and delete the binaries like we did for those...
<chrisccoulson> I don't think I'll be able to spend time investigating a ppc64el-specific startup crash in Firefox tbh
<jbicha> pitti: I'm ok with letting e-d-s in now, it worked fine for me
<chrisccoulson> (which is what the build failure is)
<jbicha> the new e-d-s apparently doesn't actually fix the google authentication problem
<jbicha> I guess we can point ppc users to epiphany? since chromium isn't supported there either
-queuebot:#ubuntu-release- Unapproved: python-pycadf (yakkety-proposed/main) [2.2.0-2 => 2.4.0-1] (ubuntu-server) (sync)
<chrisccoulson> seb128, have you used firefox in proposed btw?
<seb128> chrisccoulson, not really, but I can give it a try if you want ... anything in particular?
<seb128> chrisccoulson, did you see the ping from rico early on ubuntu-devel btw?
<chrisccoulson> seb128, well, I just thought - the build in the release pocket is now so ancient that it was built with the old compiler
<chrisccoulson> I didn't see a ping earlier, let me check
<seb128> chrisccoulson, it was at 8:25 u.k
<chrisccoulson> ahh
<chrisccoulson> so, firefox has the same issue as https://bugs.chromium.org/p/v8/issues/detail?id=3782 which already affected chromium and oxide
<chrisccoulson> Firefox really needs a maintainer that cares about it ;)
<chrisccoulson> oh, apparently firefox doesn't have this problem, and the bug ricotz linked is thunderbird specific
<jbicha> chrisccoulson: I've been using firefox from y/proposed for several days and it seems ok
<apw> and the one from release is dire :/
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.5 (yakkety-proposed/universe) [1:3.5.2-3ubuntu1 => 1:3.5.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.5 [sync] (yakkety-proposed) [1:3.5.2-5]
<balloons> pitti, nothing is running in autopkgtest?
-queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu2 => 4.3.0+nmu1ubuntu3] (core)
<apw> ^ fixes fallout from v4.8 kernel headers ...
<davmor2> cyphermox: how are we looking for the new shim do you know anything yet?
-queuebot:#ubuntu-release- Unapproved: openorienteering-mapper (yakkety-proposed/universe) [0.6.3-2build1 => 0.6.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (yakkety-proposed) [0.6.5-1]
<pitti> balloons: no, we are in freeze :)
<pitti> balloons: juju is, actually (i386 and amd64 failed already)
-queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [7.11.90.20161005-0ubuntu1 => 7.12-0ubuntu1] (core)
<balloons> pitti, right it was of course what I was looking for. I saw amd64 failed, but I can't see the log proper until it finishes -- unless there's something I don't know
-queuebot:#ubuntu-release- New: accepted openfoam [sync] (yakkety-proposed) [4.0+dfsg1-3]
<cyphermox> davmor2: sorry, no news to be given
<pitti> apw: xfsprogs> cheers! is that an upstream backport?
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu3]
<apw> pitti, no that is allll me
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.12-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1 => 1.9-3.2ubuntu1.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (precise-proposed/main) [1.9-3ubuntu6 => 1.9-3ubuntu6.1] (kubuntu, netbook, ubuntu-desktop, ubuntu-server, unr)
-queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10 => 1.9-3ubuntu10.1] (core)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20160913.1-0ubuntu1 => 1:20161011.1-0ubuntu1] (no packageset)
<pitti> chrisccoulson, seb128: removing current ppc64el firefox binaries seems reasonable to me; Laney, infinity, opinions?
<chrisccoulson> pitti, I should point out, we don't block firefox security updates for build failures on those 3 architectures anyway
<chrisccoulson> And the updates are never tested on those architectures in any case
<seb128> pitti, +1 from me, it might require to delete/tweak a bit more due to rdepends, whoever handled the drop of powerpc earlier in the cycle should know the details of what is needed though
<pitti>  firefox | 49.0+build4-0ubuntu0.16.04.1   | xenial-security  | source, amd64, arm64, armhf, i386, ppc64el
<pitti>  chrisccoulson: I was wondering because it apparently did build for xenial still -- gcc 6, presumably?
<chrisccoulson> pitti, I uploaded thunderbird with a build failure fix, but I've since been made aware of https://bugzilla.mozilla.org/show_bug.cgi?id=1251576, so it won't run anyway (it's a similar issue to https://bugs.chromium.org/p/v8/issues/detail?id=3782, which we already worked around in chromium and oxide)
<ubot5> Mozilla bug 1251576 in General "GCC6 - TB crashes due to removed null pointer checks for "this"" [Normal,New]
<chrisccoulson> pitti, yeah, most likely
-queuebot:#ubuntu-release- Unapproved: libreoffice (yakkety-proposed/main) [1:5.2.2-0ubuntu1 => 1:5.2.2-0ubuntu2] (kubuntu, ubuntu-desktop)
<Laney> pitti: We forced it last time
<pitti> Laney: you mean with a britney hint, not removing packages?
<Laney> yep
<pitti> that seems a bit awkward
<Laney> why?
<pitti> Laney: hm, does that still turn up at NBS?
<pitti> our report doesn't show that, AFAIK it only runs for amd64
<jbicha> Firefox shows up at the bottom of /update_output.txt
<pitti> List of old libraries in testing (2):
<pitti>   firefox: s390x powerpc
<pitti> oh, this?
<pitti> well, we really should remove the old binaries properly
 * pitti â meeting, bbl
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92 => 0.92ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-tornado (yakkety-proposed/universe) [4.4.1-2ubuntu1 => 4.4.2-1ubuntu1] (ubuntu-desktop)
<slangasek> pitti, balloons, stokachu: seems that juju-core is still failing autopkgtests, has this been analyzed?
<pitti> slangasek: yes, balloons and I just debugged it
<pitti> slangasek: ballons is preparing a new .dsc, I'll sponsor
<balloons> slangasek, yes it's sorted. ^^
-queuebot:#ubuntu-release- Unapproved: accepted python-pycadf [sync] (yakkety-proposed) [2.4.0-1]
<pitti> building from bzr doesn't work (source and pristine-tar disagree), so I'll let him sort out the source build
<balloons> and sorry pitti, re-setting up vpn to upload dsc
<pitti> balloons: that or pastebin a debdiff if that's easier
<lunaphyte> hi.  i'm trying to upgrade an eol install [15.04] to 15.10 [this is all just to upgrade to 16.04].  but if i'm not mistaken, the old-releases repo doesn't have packages/indexes for 15.10 published, so i'm stuck, it seems.
<lunaphyte> however, us.archive.ubuntu.com still does.  so i'm a little confused as to how to go about upgrading.
<wxl> lunaphyte: #ubuntu for support.
<lunaphyte> [and, if this is the wrong channel, apologies]
<lunaphyte> wxl: i actually came here from #ubuntu-server
<wxl> lunaphyte: they suggested to come here? because that's strange. this channel exists to coordinate upcoming releases.
<lunaphyte> it seems though that vivid package indexes aren't listed at old-releases, yet they should be, hence my question here
<lunaphyte> wxl: no, they didn't suggest.  i spent time there troubleshooting, that's all.
<wxl> lunaphyte: i'd personally advice you grab /home and maybe /etc and do a fresh install re-using those
<lunaphyte> honestly, i'd just like to know who i can ask about 15.04 missing from old-releases
<wxl> lunaphyte: vivid and wily are both at archive.ubuntu.com
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.0~beta2+bzr5454-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: networking-hyperv (yakkety-proposed/universe) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (no packageset)
<lunaphyte> i thought since vivid is eol, it would be at old-releases.
<wxl> it will get there eventually, i'm sure
-queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (yakkety-proposed) [3.0.0-0ubuntu1]
<lunaphyte> inex retrieval at archive.ubuntu.com does work for vivid, yes, but upgrading fails, because it tries to upgrade to 16.04, but do-release-upgrade doesn't support it, of course.
<wxl> so like i said, fresh install
<lunaphyte> wxl: thanks, yeah, i guess that's my question, is what typically defines when that happens?
<chrisccoulson> pitti, are you able to approve partner uploads?
<lunaphyte> wxl: it's ok, i'll let the channel get back to the /topic
<wxl> infinity: could you answer lunaphyte's question as to why vivid and wily are not in old-releases but are instead still on archive?
<lunaphyte> hopefully my question isn't interpreted as "when will this be" - just would like to understand what the transition is based on
<wxl> many activities in release require manual activity (for example, turning dailies on and off in response to milestone testing)
<cjwatson> lunaphyte: Can't give you an accurate answer as to why it's not done yet (I suspect not-got-round-to-it for wily, and complicated stuff involving the Ubuntu phone codebase for vivid), but the process doc is https://wiki.ubuntu.com/EndOfLifeProcess
<wxl> that said, sometimes they just get temporarily forgotten or put off
<rbasak> There is no definite schedule. The EOL date is one bound.
<wxl> tl;dr lesson learned: upgrade BEFORE EoL :)
<lunaphyte> cjwatson: ah, thanks, that's informative
<lunaphyte> wxl: yeah, for sure.  life sometimes has other plans, unfortunately. :)
<lunaphyte> it's all good though.
<apw> well before EOL of the release which follows :)
<cjwatson> I'd probably just upgrade by frobbing sources.list and doing a dist-upgrade.
<wxl> apw: hahahah indeed
<cjwatson> Sure, do-release-upgrade helps, but it isn't mandatory.
<lunaphyte> if the end result is that eventually it will make it's way to old-releases, and then the nominal eol upgrade path will work as expected, that's fine
<rbasak> Somebody should figure out and document how to handle this better on the existing wiki page.
<pitti> chrisccoulson: technically, yes; procedurally I have no idea what to do with them/what to check, etc.
<lunaphyte> cjwatson: does frobbing sources.list mean switching from vivid to wily, in my case?
<rbasak> https://help.ubuntu.com/community/EOLUpgrades
<lunaphyte> i'm but a visitor here, but would a note somewhere there along the lines of "if you are doing an eol upgrade of a relatively recent release, it's possible that it may not work, until various transitions have fully occured - please try again later" be of any value?
<chrisccoulson> pitti, ah. I need adobe-flashplugin approving (I've uploaded yakkety so far, I normally wait until that's approved before uploading the other releases)
<chrisccoulson> pitti, the procedure is basically 1) approve, 2) I verify they're ok, 3) Copy to release pocket. Not sure if that helps you though :)
-queuebot:#ubuntu-release- Unapproved: casper (xenial-proposed/main) [1.376.1 => 1.376.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu3.16.10.1 => 2.0~rc3-0ubuntu4.16.10.1] (ubuntu-server)
<pitti> slangasek, balloons ^ now with 10% more testing love!
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu4.16.10.1]
-queuebot:#ubuntu-release- New binary: openfoam [s390x] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: indicator-network (yakkety-proposed/main) [0.8.0+16.10.20160930.5-0ubuntu1 => 0.8.0+16.10.20160930.5-0ubuntu2] (no packageset)
<cjwatson> lunaphyte: Yeah
<Laney> ^- fix for the live session
-queuebot:#ubuntu-release- New binary: openfoam [ppc64el] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
<pitti> chrisccoulson, Laney: I removed firefox ppc64el binaries; there are also some orphaned powerpc/s390x ones from 46.0.1+build1-0ubuntu1 and 47.0+build3-0ubuntu1, cleaning those too (this is why I don't like forcing without binary removal)
<chrisccoulson> pitti, thanks
<lunaphyte> cjwatson: thanks.  i suppose it's not necessarily kosher/supported, but your experience has been largely successful doing that?
<rbasak> lunaphyte: please do edit https://help.ubuntu.com/community/EOLUpgrades to make it better.
<rbasak> (you asked about adding a note?)
<lunaphyte> rbasak: oh, ok, will do
<rbasak> Looks like you have to ask to join the team, but contributors are welcome
<rbasak> https://help.ubuntu.com/community/WikiGuide
<rbasak> That's presumably to avoid spam.
<lunaphyte> sure, understood
<wxl> lunaphyte: or you could just become an ubuntu member and then you don't have to worry about that at all :)
<lunaphyte> wxl: hah!  that sounds like more responsibility :)
<wxl> lunaphyte: not necessarily. just need to sustain relevant contributions to the project
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1]
<rbasak> Fixing the doc sounds like a relevant but circular contribution :-)
<wxl> !membership | lunaphyte
<ubot5> lunaphyte: Ubuntu Membership means recognition of a significant and sustained contribution to Ubuntu and the Ubuntu community.  For more info see https://wiki.ubuntu.com/Membership/NewMember
<pitti> Laney: indicator-network> eek
<lunaphyte> wxl: thanks
<pitti> Laney: do any of the other unity8 upstart jobs now unexpectedly start in the unity7 session? it appears to me that this chagne needs to be replicated to all of those?
<wxl> lunaphyte: i'm on the membership board if you have other questions about it
-queuebot:#ubuntu-release- Unapproved: accepted indicator-network [source] (yakkety-proposed) [0.8.0+16.10.20160930.5-0ubuntu2]
<cjwatson> lunaphyte: Yes, but I've been doing the general equivalent since well before Ubuntu existed so I'm not a good sample case.
<pitti> Laney: I thought upstart had a less ugly way to do that, like start on starting DESKTOP_SESSION="unity8" or so?
<pitti> unity-panel-service.conf:start on desktop-start DESKTOP_SESSION=ubuntu
<pitti> Laney: ^ like this?
<pitti> Laney: (accepted, as this is just bikeshedding, but I wonder if that affects other services too0
<Laney> I copied it from the other job in the same source package which definitely works
<pitti> unity-panel-service.conf:# start on started unity7
<pitti> or even just that
<lunaphyte> wxl: well, i really do appreciate all of the info, but if i'm honest, it's probably not in the cards for me these days.  hopefully that doesn't come across as dismissive!
<Laney> I don't want to mess around at this point
<lunaphyte> cjwatson: understood, thanks
<wxl> lunaphyte: np. it will be there in the future.
<lunaphyte> gracias
<wxl> de nada
<Laney> maybe you could do desktop-start DESKTOP_SESSION=... and indicator-services-start
<Laney> Seems risky to me to experiment now
<pitti> Laney: "start on started unity7" (like unity-panel-service.conf) seems like the equivalent of WantedBy=unity7-session.target
<pitti> Laney: but yes, if it works, it's ok; as I said I mostly just wondered if that affects other unity8 services too
<Laney> It's waiting for some event, not just that unity8 is started
<Laney> and I don't know - at least I haven't heard that any of those actually crash like this one does ...
-queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu2 => 1:45.3.0+build1-0ubuntu3] (mozilla, ubuntu-desktop)
<Laney> I have something called indicator-transfer-service running, not sure if that's necessary or not
<Laney> seb128 / tedg: do you know if indicator-transfer is used or useful on unity 7?
<seb128> Laney, it's not used and probably not going to be useful
<seb128> it's supposed to indicate ongoing downloads
<seb128> but classic apps don't use the api to talk to it
<seb128> so probably not that useful
<Laney> thanks
<Laney> I'll give it the same love, but this is lower priority
<tumbleweed> I'm being arm twisted with beer, for some last minute universe FFes :)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [117 => 118] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
<slangasek> infinity, pitti: do we have a target time for the start of image respins, to guide evaluating the uploads in the queue?
<Laney> pitti: ^- same fix - this one is "just" a waste of resources
<slangasek> I'm a waste of resources ;(
<Laney> urgh, there's a waste of resources in my changelog
<infinity> slangasek: I was shooting for "very soon".  But will take another round of fixes if they don't need 4h to get through the sausage factory.
<infinity> slangasek: I was personally waiting on the arm64 buildd kernel hack (done), and ubuntu-system-settings building successfully (in progress) and migrating.
<infinity> I'm also curious to see what the fallout is from the firefox and thunderbird removals.
<infinity> I bet component-mismatches explodes.
<slangasek> infinity: what is "soon", realistically? we have maas which is currently publishing
-queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
<infinity> slangasek: After that maas, since it'll beat u-s-s to the release pocket.
<slangasek> ok
<infinity> slangasek: I dunno.  More than an hour, less than several.
<infinity> I hope.
<slangasek> infinity: it seems for some reason a gdb was accepted, which is seeded everywhere and needs 4 more hours to build on armhf
<slangasek> (appx)
-queuebot:#ubuntu-release- Unapproved: rejected indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
<infinity> slangasek: Whee.
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (yakkety-proposed) [304.132-0ubuntu1]
<slangasek> so maybe someone wants to speak up and explain why that was accepted
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [118]
<slangasek> pitti: ?
<slangasek> or Laney or apw or tumbleweed or stgraber ?
<Laney> nope
<slangasek> doko: or did you happen to accept this gdb yourself?
<Laney> I accepted thunderbird though, which needs quite a while on armhf
<Laney> Apparently the current one fails to start
<slangasek> Laney: ah, well, thunderbird is seeded in only half the places that gdb is
<infinity> Which is still many places. :P
<Laney> block-all source time?
<infinity> Not all.
<slangasek> only ubuntu-mate, ubuntu desktop, ubuntukylin FWIW
<infinity> But getting close to block all seeded.
<slangasek> oh. but also ubuntustudio + xubuntu, so that's fine
<slangasek> infinity, Laney: I suggest forcing thunderbird in before armhf is built, to unblock the image builds / tests on other archs and let armhf binaries catch up on their own time
<infinity> We'll see how the other arches fare.
<slangasek> (since I don't think any of those projects are building armhf images currently)
<Laney> ubuntu2/armhf actually FTBFSed
<Laney> So we'll see how this one does
<Laney> It'll need some forcing or removals in any event since arm64/ppc64el have regressed
<Laney> Might be one to punt
<Laney> Dunno how crap 38 is
<infinity> Has anyone looked into *why* they regressed?
<infinity> They build fine in xenial with the same upstream version.
<Laney> chrisccoulson: ^- (I'm guessing "no")
<Laney> u-s-s worked
<chrisccoulson> i didn't notice that ubuntu2 had been approved actually
<chrisccoulson> the armhf is a race condition that we keep seeing in the build. It'll probably work fine if it's retried
<chrisccoulson> the arm64 build failure is a crash when compiling the startup cache
<chrisccoulson> it most likely builds fine on xenial because it's not using gcc6
 * infinity notes that gcc-5 is still in yakkety.
<infinity> Not that that fixes the bugs, but it would defer the issue.
-queuebot:#ubuntu-release- Unapproved: gcr (yakkety-proposed/main) [3.20.0-2ubuntu1 => 3.20.0-2ubuntu2] (kubuntu, ubuntu-desktop)
<infinity> pitti: Are you on top of this indicator-transfer thing?
 * infinity eyes libreoffice suspiciously in the queue.
-queuebot:#ubuntu-release- Unapproved: accepted gcr [source] (yakkety-proposed) [3.20.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (yakkety-proposed) [4.4.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20161011.1-0ubuntu1]
<chrisccoulson> oh, who just approved flash?
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20160913.1-0ubuntu0.12.04.1 => 1:20161011.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20160913.1-0ubuntu0.16.04.1 => 1:20161011.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20160913.1-0ubuntu0.14.04.1 => 1:20161011.1-0ubuntu0.14.04.1] (no packageset)
<infinity> chrisccoulson: Moi.
<chrisccoulson> infinity, ah, thanks. I've just uploaded the rest of them now :)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop)
<slangasek> jbicha: ^^ this impacts images across 4 flavors, for which image spins are supposed to start imminently; why is it uploaded now?
<jbicha> slangasek: it can be an SRU right?
<slangasek> jbicha: if it meets SRU requirements; ok I see the SRU template in the one bug, thanks
<jbicha> it's not needed in the release images
<slangasek> jbicha: I'm asking because it's hard to coordinate across all the release team working the queue in parallel, so it's important to have clarity about the target for these uploads
<slangasek> ok
<flexiondotorg> infinity, Is the release going to be delayed?
<infinity> flexiondotorg: I shouldn't think so.
<flexiondotorg> OK
<flexiondotorg> The rumour mill is speculating. I'll pour water on that.
<infinity> flexiondotorg: Rumour mills are special.
<flexiondotorg> Indeed.
<infinity> flexiondotorg: Perhaps the rumour mill should be harder at work on testing, reporting, and fixing. :P
<flexiondotorg> That too.
<lunaphyte> thanks everyone for entertaining my questions, etc.
<slangasek> does a binary removal of an arch: all package on a specific arch DTRT? :P
<infinity> slangasek: no.
<slangasek> ok cool
<slangasek> so how do we get juju in?
<slangasek> I guess I can 'force' it
<infinity> No.
<slangasek> infinity: I hope you're planning on elaborating / presenting an alternative :)
<infinity> I'm looking at the situation first.
<slangasek> ok
<slangasek> summary from my side: juju dropped 32-bit arch supports, with my sign-off; no transitional packages for this in yakkety because the drop is retroactive to xenial so for 16.10 we just want the packages gone; in the process that means juju is migrating from an (uninstallable) arch: all package to an arch: some package; and britney doesn't want to let it in
<infinity> Check, and rmadison confirms.
<slangasek> and I guess, from the output, that the arch: all-> arch: some change was made only in the latest release, since previous release was getting autopkgtest results
<infinity> Okay, in that case, your propose arch-some removal might work.
<slangasek> ok
<infinity> The reason I said it doesn't is because all copies in LP are source-based, so binary removals always come back.
<slangasek> did that, let's see what happens - thanks
<infinity> And, thus, should be avoided.
<infinity> (And definitely avoided for arch:all, which is just confusing)
<infinity> But as a temp solution, it might DTRT.
<infinity> If it doesn't, just remove juju from the release pocket entirely.
<infinity> Still beats a force.
<infinity> Okay, and juju's not in any metapackages, so don't need a refresh.
<infinity> Though after the current things all settle, I'll do a world refresh of meta locally to see if any changes got missed.
<pitti> slangasek: I didn't accept it; it seemed a bit dubious/too intrusive to me
-queuebot:#ubuntu-release- Unapproved: wine-development (yakkety-proposed/universe) [1.9.19-1ubuntu1 => 1.9.20-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu1]
<pitti> infinity: do you want everyone else to stay away from unapproved now?
<pitti> or still want me to review the indicator-transfer thing?
<pitti> (I have a hunch that's going to be needed for the ubuntu desktops at least, but not blocking all other flavors)
<pitti> urgh, a LibO upload?
<pitti> dear http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt, pretty please update
<infinity> pitti: GO ahead and sort that, please.
<pitti> Laney: running these shell scripts is a nice waste of resources too, but hopefully a bit less :)
-queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
<pitti> jbicha: do you want that g-s-d on the images? diff looks sane enough to me, but at this point there's little margin for errors
<pitti> jbicha: did you test this on real hw with a battery? screen saver works ok?
<jbicha> pitti: did you see s_langasek's comment above about it ^
<pitti> no, /me reads backscroll
<pitti> meh, somehow my firefox/ppc64el removal didn't work?
<jbicha> I'd rather g-s-d just be an SRU actually; the bug fixes in it are fairly minor
<pitti> ack, they don't seem image-critical, unlike the indicator thing
<pitti> (relevant for live image)
<pitti> infinity: I guess you should put a propagation block in place now, so that we have more control over this?
<infinity> pitti: Yeahp.  Doing that now.
<pitti> infinity, slangasek: are you on top of the juju 32 bit removals so that this can land, or want me to?
<infinity> pitti: Steve's on the juju case.
<pitti> the transitional moved from arch: all to arch: [list]
<pitti> ack
<pitti> infinity: so I can deal with firefox; 46.x and 47.x are gone, but 48.x ppc binaries still exist
<infinity> pitti: The easier way to do that is just to remove source package by version.
<infinity> pitti: remove-package -e 48.blah firefox
<infinity> pitti: Way simpler than trying to hunt down the mismatched bits.
<pitti> infinity: that would entirely remove it from yakkety for a short blip of time, though?
<infinity> pitti: Do you care?
<pitti> I ran http://paste.ubuntu.com/23309737/ earlier, apparently that didn't work
<infinity> If the goal is to get 49 in ASAP.
<pitti> ok
<pitti> infinity: done
<infinity> pitti: I'm more worried about c-m exploding due to this.
<pitti> seems a bit awkward to remove "good" binaries temporarily from the release, but indeed, better than screwing it up for another publisher
<infinity> pitti: But maybe with archive-reorg, it won't.  The old "if we have no firefox, other browsers get yanked into main" thing *might* have been a build-dep issue.
<infinity> Here's hoping.
<infinity> I honestly don't recall if it was build-dep or runtime.
<infinity> Though, at the very least, we'll need a meta refresh.
<infinity> Which is on my TODO in a publisher cycle or three.
<pitti> infinity: after it updates, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt will still have some remaining bits -- e. g. libnuma1 on s390x only
<infinity> I'll hold off on the britney block for another cycle or two as well.
<pitti> oh wait, libnuma1 will then be in "optional" everywhere
<infinity> I thought I had a hint for numa.
<pitti> I was going to ask whether it's ok to have a different priority on a particular arch only
<pitti> but seems it's the other way round -- it currently differs, this will now make it equal to other arches
<infinity> You can't have mismatched priorities on arches, LP doesn't allow it.
<infinity> Unless something goofs up.
<infinity> Does architecture-mismatches show an issue?
<pitti> ah no - libnuma1 is in standard for other arches
<pitti> python* and perl* should be gone now -- I figure we need to promote this silly pinentry-curses now
<pitti> infinity: wow, I was completely ignorant of http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt
<infinity> I'll clean up the mismatches.
<infinity> So we don't stomp on each other.
<pitti> ack -- i. e. promote unity on arm64?
<infinity> And priority stuff as well.
<pitti> infinity: wait
<pitti> infinity: can you predict what it's going to look like? or were you just going to promote pinentry-curses?
<infinity> pitti: I'm fixing libnuma with a hint.  pinentry probably will want to promote.  But also waiting for the perl stuff to fall out.
<pitti> libnettle6 might be a transient dep of pinentry
<infinity> pitti: numa fix committed.
<infinity> And unity8 fixed.
<infinity> Finishing my lunch while I way for some archive settle.
<tyhicks> Hi
<tyhicks> we've just discovered that some confined programs are being denied access to the system bus due to the resolved changes in yakkety
<tyhicks> at least tcpdump and ntpd are affected
<pitti> that sounds SRUable?
<tyhicks> nss seems to be falling back to do traditional name lookups whenever apparmor denies access to the bus but I don't know if that's acceptable
<tyhicks> pitti: you would know best if the fallback is "safe" ^
<pitti> tyhicks: NSS in general does work; you mean for apparmor profiles of programs where NSS doesn't work?
<pitti> tyhicks: it's "safe" in yakkety as we disabled DNSSEC (and thus enforcement), so ATM falling back to "dns" is only a convenience/longer timeout/no caching issue
<pitti> tyhicks: and desktops use dnsmasq anyway (again), not resolved
<tyhicks> pitti: ok, so it sounds like we can fix this in an SRU
<pitti> tyhicks: so you mean tcpdump/ntpd do lookups via NSS and are being denied D-Bus access?
<tyhicks> pitti: correct
<pitti> ok
<sarnold> .. and everything else that aa-status reports as confined
<pitti> tyhicks: i_nfinity installed a propagation block now, so we should actaully be able to start SRU uploads now
<pitti> or rather, "soon" (block not yet active)
<tyhicks> pitti: do I need to explicitly upload to yakkety-updates or will they be automatically routed to -updates?
<pitti> tyhicks: no, *don't* upload to -updates, we need to reject this (and make sure we actually spot it)
<pitti> tyhicks: continue to upload to yakkety or yakkety-proposed
<tyhicks> thanks
<pitti> tyhicks: -proposed is the same for devel and SRUs, just the propagation changes from -release to -updates
<tyhicks> ack
<pitti> so, uploading is fine at all times, but I can only review it after we get a release block
<infinity> pitti: Yeah, the block will be in a couple of cycles, I don't want to block just to unblock everything in there right now.
 * pitti waves good night
-queuebot:#ubuntu-release- Unapproved: strongswan (trusty-proposed/main) [5.1.2-0ubuntu2.4 => 5.1.2-0ubuntu2.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.14 => 0.4.9-3ubuntu7.15] (core)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90 => 0.90ubuntu0.1] (desktop-core, ubuntu-server)
<brendand> who do i need to nudge to get cloud-init moving along from -proposed (in xenial)?
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (yakkety-proposed/multiverse) [11.2.202.635ubuntu1 => 11.2.202.637ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (yakkety-proposed) [11.2.202.637ubuntu1]
-queuebot:#ubuntu-release- Unapproved: icinga (xenial-proposed/universe) [1.13.3-2 => 1.13.3-2ubuntu0.1] (no packageset)
<wxl> we having a respin at some point?
<valorie> I heard "More than an hour, less than several"
<wxl> jj
<wxl> er
<wxl> s/j/k/g
<valorie> lol
<brendand> infinity, any chance of nudging the cloud-init (xenial) sru along? bugs are verified, it's aged a week, and it's hurting us badly. understand if you're busy though
<slangasek> valorie, wxl: right, and that was 3 hours ago
<slangasek> infinity: what's the long pole now?
<acheronuk> waiting until migration blocks are in place so I thought I read?
<infinity> slangasek: Waiting on firefox migration, at least.
<infinity> Less convinced about what to do with thunderbird.
<infinity> Oh, but it looks like it's built/failed everywhere it's going to.
<infinity> So maybe we can nudge that along too.
<infinity> But yeah, probably time for the block and unblocks.
<infinity> Doing that now.
 * valorie sends a thousand {{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}}} to the release team
<infinity> I only deal in pie.
 * valorie adds pie
<valorie> and beer
<valorie> and whisky for those who want it
 * wxl wants matÃ©
<valorie> some nice cider for those who don't
<cjwatson> infinity: priorities> LP allows it, we just try to avoid it because it's a pain to keep track of.  Maybe you're thinking of dak.
<infinity> cjwatson: Perhaps.
<acheronuk> valorie: I suspect strong coffee is also required
<infinity> cjwatson: The archive doesn't allow it, then. :P
<valorie> I'm willing to bet the team has laid in stores of coffee AND tea
<dannf> infinity: i'm not sure how to report this via the QA tracker (is that setup yet?), but arm64 ISOs need a fix - LP: #1632473
<ubot5> Launchpad bug 1632473 in Ubuntu CD Images "arm64 grub needs to load gzio" [Undecided,New] https://launchpad.net/bugs/1632473
<infinity> dannf: Is this already correct in the mini.iso?
<infinity> dannf: Cause I see no mention of gzio in d-i...
<dannf> infinity: checking
<dannf> infinity: mini iso boots - seeing if i can figure out why - side-effect perhaps?
<infinity> Side effect of what? :P
<dannf> some other preloaded module perhaps
<infinity> The grub.cfg on mini.iso is pretty sparse.
<dannf> hrm.. w/ debug=all, i don't see gzio ever load.
<dannf> infinity: ah - looks like the kernel on the iso is a gzip'd file w/ no UEFI stub
<dannf> whereas on the mini.iso, it's a gzip's kernel w/ a UEFI stub prefix like it should be
<infinity> *raise brow*
<infinity> That seems suboptimal.
<infinity> So, I get vmlinuz straight out of d-i.
<infinity> Why are you giving me two different kernels? :P
<dannf> indeed...
<dannf> oh - i'm not. i was just apparently testing the wrong mini.iso! egg/face
<infinity> Ahh, so d-i is also broken?  That's less confusing.
<dannf> yes. fixing.
<infinity> Right, do some test runs there to get something that works, and I can mirror it in debian-cd, if it's not just carried over in cd-info.tar.gz.
<infinity> dannf: A little late for grub uploads now, but I'd suggest that, perhaps, if gzio is required for arm64 now, it should probably be built-in. :P
<infinity> (I assume it is for x86?)
<infinity> Oh, hrm.  Won't this also break the installed system on reboot?
<infinity> Oh, no, looks like the installed grub.cfg has gzio just in case.
<dannf> yeah - i've been booting compressed kernels for a while  on EFI systems w/ no problem
<cyphermox> dannf: infinity: it's already builtin to the EFI images
<dannf> infinity, cyphermox : https://code.launchpad.net/~dannf/debian-installer/lp1632473/+merge/308199
<infinity> dannf: Please commit, tag, and upload.
<dannf> infinity: ack
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu482 => 20101020ubuntu483] (core)
<flexiondotorg> infinity, Just trying to organise some final MATE testing.
<flexiondotorg> Is a world respin planned?
<wxl> supposedly incoming soon flexiondotorg
<flexiondotorg> wxl For world?
<sarnold> flexiondotorg: perhaps define what you mean by "world respin"
<flexiondotorg> All the flavours.
<flexiondotorg> Having images recreated.
<slangasek> the world is constantly spinning, no "re" required
<slangasek> yes, all flavors need an updated image
<slangasek> stokachu, balloons, cyphermox: so, juju-core autopkgtest failure on ppc64el due to manual provider? expected?
<cyphermox> I hear it's expected, but needs to be fixed?
<cyphermox> slangasek: also, what do you mean, the world is spinning? isn't it constantly accelerating upwards at 9.8m/s^2?
<slangasek> cyphermox: what does "needs to be fixed" mean here?  Should I expect a new fixed package before release?
<cyphermox> slangasek: we discussed changes to this test this morning, but I don't know if you should be expecting a fixed package now
<cyphermox> balloons: ^
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.1 => 3.168.2] (ubuntu-desktop, ubuntu-server)
 * tsimonq2 buys the release team a virtual cup of coffee and/or Red Bull for whoever wants it 
<cyphermox> tsimonq2: good plan. I took a short video games break ... and it ended in a game over :(, but now coffee seems in order
<tsimonq2> cyphermox: cheers :)
#ubuntu-release 2016-10-12
<slangasek> infinity: so, what's the story with firefox?  currently blocked by autopkgtest failures?
<stokachu> slangasek: i was told that the juju agent was failing to connect to mongo
<slangasek> stokachu: seems to have resolved itself on a retry?
<stokachu> slangasek: yea i kicked it again and mongo played nice
<slangasek> ok
<stokachu> slangasek: that's all the issues i know of
<ahoneybun> heyo anyone know why this package is missing in YY archive? Package libpng12-0 is not installed.
<tsimonq2> !info libpng
<ubot5> Package libpng does not exist in xenial
<cyphermox> ahoneybun: it was transitioned to libpng1.6 in xenial, it seems. any package that depends on it needs to be rebuilt
<tsimonq2> cyphermox: seems like some Kubuntu packages are affected
<tsimonq2> ahoneybun: what is trying to install it?
<ahoneybun> virtual box
<ahoneybun> tsimonq2: ^
<sarnold> this suggests it depends upon libpng16-16 http://packages.ubuntu.com/yakkety/virtualbox
<ahoneybun> I'm grabbing it from the virtualbox website
<ahoneybun> that's why
<ahoneybun> they have not rebuilt it then
<slangasek> stokachu: yeah, it's migrating now
<ahoneybun> since the archive has 5.1.6 now I'll just grab from there for now
<ahoneybun> thanks cyphermox and sarnold
<stokachu> slangasek: cool thanks man
<slangasek> ok, I've retested y-u-no-validate and confirmed that it's a real regression introduced by the new firefox
<slangasek> whatever that does for us
<slangasek> I'm going to go ahead and force firefox in, on the grounds that this gives us the option to remove y-u-no-validate (or leave it broken) rather than waiting further
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu483]
<slangasek> infinity: I've triggered a set of rebuilds; I see that d-i hasn't published quite yet so we'll still need to trigger those in a little bit
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Final] has been updated (20101020ubuntu483)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Final] has been updated (20161012)
<infinity> slangasek: Then why did you do lubuntu alt? :)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Unapproved: budgie-wallpapers (yakkety-proposed/universe) [16.04.1.1 => 16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-wallpapers [source] (yakkety-proposed) [16.10]
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (yakkety-proposed/universe) [16.10] (no packageset)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- New source: budgie-desktop-environment (yakkety-proposed/primary) [0.4.17]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161012)
<slangasek> infinity: because I didn't notice it hadn't published until after I hit the button, so we get to build it again ;)
<infinity> Fair enough.
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Final] has been updated (20161012)
<slangasek> infinity: so for firefox, the binaries were dropped for powerpc?  Was someone going to take care of making lubuntu desktop installable again?
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Final] has been updated (20161012)
<ahoneybun> ohhh the machines are turning!
<slangasek> http://i1.kym-cdn.com/photos/images/original/000/242/631/382.gif
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Unapproved: proftpd-dfsg (yakkety-proposed/universe) [1.3.5a-1build1 => 1.3.5a-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted proftpd-dfsg [source] (yakkety-proposed) [1.3.5a-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: proftpd-dfsg (yakkety-proposed/universe) [1.3.5a-1ubuntu1 => 1.3.5a-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted proftpd-dfsg [source] (yakkety-proposed) [1.3.5a-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: qliss3d (yakkety-proposed/universe) [1.4-2 => 1.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qliss3d [source] (yakkety-proposed) [1.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (yakkety-proposed/universe) [1.343 => 1.344] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (yakkety-proposed/universe) [1.177 => 1.178] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (yakkety-proposed/universe) [0.161 => 0.162] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (yakkety-proposed/universe) [0.71 => 0.72] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (yakkety-proposed/main) [1.372 => 1.373] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.70 => 0.71] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (yakkety-proposed/universe) [2.207 => 2.208] (xubuntu)
<flocculant> infinity slangasek - hi - both the xubuntu images built according to ~ubuntu-cdimage/+livefs/ubuntu/yakkety/xubuntu, but the build logs say 32bit failed - and iso tracker agrees and only has 64bit
<flocculant> http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/yakkety/ that log ...
<infinity> Seems to have lost its mind slightly.
<infinity> flocculant: I'll retry it.
<flocculant> infinity: thanks :)
<flocculant> infinity: you expecting more rebuilds at all?
<flocculant> not including of course any 'arrrrgh we got to rebuid :|'
<pitti> meh, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt *still* hasn't updated since yesterday morning
 * pitti hunts for cronjobs to run manually
<infinity> pitti: Yeah, I noticed earlier that archive-reports seems to not be reporting.
<infinity> And I'm afraid of what they'll say. :P
<infinity> flocculant: Probably one last on late wed, I suspect, but please test, test, test,  so we can sort out what we need to fix. :P
<flocculant> yea I know the drill - if only I could get more people to join in :(
<pitti> infinity: you already have a hunch what's wrong?
<infinity> pitti: Well, there's all those metas I uploaded ^^
<infinity> pitti: Or if you mean archive-reports, no.  I haven't looked yet.
<pitti> infinity: ah ok, that "I'm afraid of what they'll say" seemed to apply to archive-reports; looking now
<infinity> pitti: Oh.  I don't know why they're failing to run.  I have a hunch that when they do run, we won't like the ouput (due to the firefox removal)
<infinity> But we'll see.
<infinity> And I still didn't cleam up all the prio mismatches because no report to tell me the current state of the world.
<pitti> so http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.yakkety/standard is updated anyway -- no perl and launchpadlib any more
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (yakkety-proposed) [16.10]
-queuebot:#ubuntu-release- New: accepted openfoam [s390x] (yakkety-proposed) [4.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted openfoam [ppc64el] (yakkety-proposed) [4.0+dfsg1-3]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Final] has been updated (20161012.1)
<flocculant> infinity: thanks :D
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (yakkety-proposed/universe) [1.6.1.2 => 1.6.2] (ubuntukylin)
 * infinity makes himself hotdogs for breakfast.
-queuebot:#ubuntu-release- Unapproved: qliss3d (yakkety-proposed/universe) [1.4-2ubuntu1 => 1.4-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qliss3d [source] (yakkety-proposed) [1.4-2ubuntu2]
<pitti> infinity: breakfast? are you in London?
<acheronuk> I think infinity decided to adopt London timezone for release week, hence late night hotdogs=breakfast?
<pitti> ah, mirror/ubuntu-germinate is out of date
<pitti> ah-haa! http://paste.ubuntu.com/23311716/
<pitti> cjwatson: ^ KeyError: 'Built-Using' in germinate
<pitti> cjwatson: trying naÃ¯ve fix: http://paste.ubuntu.com/23311741/
<infinity> pitti: It's been vomiting that Built-Using error a lot longer than the reports have been out of date, though.
<acheronuk> so... no firefox in latest images is expected?
<infinity> acheronuk: In which image(s)?
<pitti> infinity: still a bit weird -- http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.yakkety/standard is up to date, while snakefruit:mirror/ubuntu-germinate/ is not -- but update-germinate runs *on* snakefruit
<pitti> but:
<pitti> 1474560 Oct 11 08:48 ubuntu-germinate
<pitti> this totally coincides with archive-reports stopping to update
<acheronuk> infinity: the ones timestamped for 04:22 today http://cdimage.ubuntu.com/kubuntu/daily-live/20161012/
<infinity> acheronuk: On, x86 images?  No, definitely not expected.
<infinity> s/On/Oh/
<pitti> but indeed, update-germinate does not touch mirror/ubunut-germinate
<infinity> mirror is, well, a mirror.
<infinity> pitti: ubuntu-germinate is rsynced from pepo.
 * infinity checks the state of pepo.
<pitti> $ rsync -aq --include germinate.output --exclude _\* --exclude \*.new --include "*_yakkety_*" --exclude \* --delete --delete-excluded ftpmaster.internal::ubuntu-germinate/ "$HOME/mirror/ubuntu-germinate" -vP
-queuebot:#ubuntu-release- New sync: dasher (yakkety-proposed/primary) [4.11+git20130508.adc653-3]
<LocutusOfBorg> pitti, dasher seems fixed ^^ please let it go back in yakkety
<infinity> It's definitely been touched more recently on ftpmaster.
<pitti> I'm just running that manually, seems that actually works
<infinity> pitti: ...
<pitti> mirror/ubuntu-germinate/standard_ubuntu_yakkety_amd64 is now perl-free
<pitti> so why the heck doesn't it work from bin/archive-reports
<infinity> I dunno.
<infinity> And archive-reports will still perhaps fail to run now, since you updated the mirror manually, thus timestamps won't bump. :/
<infinity> But I guess we can hack that check out for a quick by-hand run.
<pitti> infinity: at it
<infinity> pitti: cron it!
 * pitti runnig with sh -x again to see what's going on (disabled in crontab)
<pitti> heh
<pitti> clearly a systemd bug anyway
<infinity> How could it not be?
<infinity> Well, that's not fair.  It could be a pulseaudio bug.
<infinity> Mirrors pulse.
<infinity> It adds up.
 * pitti misses the days of "ITZ GTK BUG!"
<infinity> Iz steel quite ooften gtk boog.
<infinity> Though, it's much harder to figure out when to blame GTK these days.
<pitti> particulary when most of our bits are Qt now
<infinity> I had a GL surface rendering oddity on my laptop and realized I had literally zero idea how to go about debugging if it was kernel, drm, mesa, compiz, unity, gtk, or... something else entirely.
<infinity> Because in our brave new world, literally everything on the screen is a textured GL surface pretending to be something else.
<infinity> "No, really, I'm a button."
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt updated (manual run)
<infinity> Ta.
<pitti> hm, that's a bit disappointing; I was hoping some of the libs were due to perl and launchpadlib
<pitti> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt updated, all clear
<infinity> Not super concerned about the libs.
<acheronuk> infinity: I see no change in kubuntu seeds since beta2 that could boot firefox off the iso
<infinity> acheronuk: No, but we've had some fun times with firefox today.  Will investigate.
<pitti> infinity: python3-yaml is due to netplan, I think that's correct
<infinity> pitti: Does netplan do python things at boot?  Can I hate you for that?
<pitti> infinity: argh, no; it's just a tiny C thingy, taking 1 ms or so
<infinity> pitti: Oh, phew.
<acheronuk> infinity: ok. thank you :)
<infinity> pitti: So just some support utility in python?
<pitti> infinity: the python thing is the "netplan" binary, for "force-apply my changed config" (but that's run manually)
 * infinity nods.
<infinity> Less gross.
<pitti> infinity: and that's also for migration from ifupdown (not enabled yet), and some heuristics later on -- really don't want to write that in C
<infinity> Kay everything in prio-mismatches looks vaguely sane enough.
<infinity> Pulling in all the heimdal stuff is a bit unfortunate, but looks like it was in standard anyway.
<infinity> So meh.
<infinity> pitti: A component-mismatches would be nice too.  That's the one I'm expecting to be ugly.
<infinity> (because of firefox)
<pitti> infinity: the main thing that stands out is pinentry-ncurses -- I doubt we are actually using/integrating that
<infinity> I hope I'm wrong.
<infinity> pitti: Hrm?  pinentry-curses is pretty much the only way to talk to gpg2 absent a GUI.
<pitti> infinity: does gnupg call that by itself then?
<infinity> pitti: So if gnupg2 is now important, so should pinentry-curses be.
<infinity> It's meant to DTRT based on your environment, yeah.
<infinity> pitti: Anyhow pinentry-curses is tiny, and the only pinentry guaranteed to work.  So, it should be there.
<pitti> ack
<infinity> pitti: The caveat is that you want pinentry-(fancy-gui-thing) seeded on each desktop.
<infinity> Which I think we did a cycle or two ago?
<pitti> yes, that exists
<pitti> infinity: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt updated; looks okay
<infinity> pitti: Phew.
 * pitti is getting good at playing cron monkey
<pitti> infinity: cleaning up the main->universe stuff
<infinity> pitti: I guess the firefox c-m issue was a build-dep, then.  So archive reorg fixed it.
<infinity> (Used to be that if firefox didn't exist on all arches, c-m lost its mind trying to pull in other random browsers)
<infinity> Oh, wait.
<infinity> No.
<infinity> I see a lynx on there. :P
<infinity> But that's way less dire than what used to happen.
<infinity> And if it's only libpango-doc, maybe that should just be fixed.
<infinity> Docs depending on a web browser is rather sill.
<infinity> y
<pitti> golang* sounds a bit suspicious -- as if some package (lxd/juju-core) switched from "archve packages" to "bundled" again
 * pitti leaves that for the moment, we can still do demotions tomorrow
<infinity> Tempted to drop the www-browser dep from pango-doc.
<pitti> infinity: can fix pango if you want, but that would require another respin
<infinity> But I guess we can also just ignore c-m's hint to promote lynx and fix it in Y+1
<pitti> so that's just on ppc64el now?
<infinity> pitti: We'll almost certainly respin anyway, but I don't think rebuilding pango for that is worth it, we can just ignore c-m's hint.
<pitti> ok
<infinity> s/ppc64el/everywhere without firefox/
<infinity> pitti: Actually, on second thought, sure, gimme a fixed pango.  We can shunt it to SRU/ZZ if it doesn't make a respin.
<pitti> infinity: let me do it in Debian svn
<pitti> (already at it)
<infinity> WFM.
<infinity> Docs depending on browsers is so 1996.
<infinity> (Plus, I assume it ships something other than just HTML, which makes the dep even more bogus)
<infinity> But maybe not.
<pitti> no, just HTML, but devhelp/chromium etc.
<pitti> https://anonscm.debian.org/viewvc/pkg-gnome?view=revision&revision=51383
<pitti> backporting that to our pango now
<pitti> (and  urgh @ svn)
<infinity> pitti: Also not uncommon to install *doc on a web server and share /usr/share/doc
<pitti> uploaded; so, ubuntu1 for yakkety, but package will be syncable again in z
<infinity> Kay.
-queuebot:#ubuntu-release- Unapproved: pango1.0 (yakkety-proposed/main) [1.40.1-1 => 1.40.1-1ubuntu1] (core)
<infinity> The fonts-noto/fonts-droid-fallback thing isn't resolved either. :/
-queuebot:#ubuntu-release- Unapproved: accepted pango1.0 [source] (yakkety-proposed) [1.40.1-1ubuntu1]
<infinity> pitti: Want to "review" all my metas?
<pitti> oh, sure
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (yakkety-proposed) [1.6.2]
<pitti> so with those, we can just as well land pango
<infinity> Yeah, likely.
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (yakkety-proposed) [1.344]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (yakkety-proposed) [0.72]
<infinity> The next respin will be The Last(tm), so I want to gather up whatever reporting we can and fix as many bugs as we can in the next ~6h or so.
<pitti> all those ubuntu-mate s390x desktop users!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (yakkety-proposed) [0.71]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (yakkety-proposed) [1.178]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (yakkety-proposed) [1.373]
<pitti> wow, this also mopped up some other recent seed changes
<infinity> Yup.  Some flavours were slacking on meta updates, looks like.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (yakkety-proposed) [0.162]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (yakkety-proposed) [2.208]
<infinity> I just did a for i in flavour update of the world.
<pitti> https://launchpadlibrarian.net/289284437/buildlog_ubuntu-yakkety-ppc64el.pango1.0_1.40.1-1ubuntu1_BUILDING.txt.gz
<pitti> WTF
<pitti> /usr/include/powerpc64le-linux-gnu/bits/sigthread.h:1:7: error: stray â\377â in program
<pitti> pango FTBFS due to new kernel on ppc64el now
<pitti> infinity: you were right with 3D textures and kernel being deeply interwoven now :(
<apw> pitti, what did we do now ?
<pitti> apw: the above pango1.0 failure on ppc64el
<pitti> not sure how to work around this in the pango source, it's a recursive include of a kernel header
<infinity> That's not just random corruption in the VM?
 * infinity retries.
<pitti> here's hope
<apw> pitti, also that isn't a kernel header
<pitti> apw: oh sorry, it's glibc
<apw> not that that makes it any different :)
<apw> worse if anything
<pitti> sounded very kernel-ish
<apw> yeah does indeed, i went and looked for it and everything
<pitti> well, /me crosses fingers for random solar radiation bug
<pitti> infinity: FAOD, did you process http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt already or want me to?
<infinity> pitti: No, but also no.
<infinity> Getting there.
<infinity> And I can't help seeing FAOD and reading FOAD.
<infinity> And I wondered how I hurt you. :P
<pitti> subtle spelling, big semantic difference, ouch :)
<infinity> pitti: And retry was fine.
<pitti> *phew*
<pitti> apw: sorry for the adrenaline kick
<infinity> Try not to think too hard about what this means for the packages in the archive.
<infinity> Reproducible builds would be a lovely way to guard against random memory corruption. :/
<pitti> I wonder if there ever was a case for a random one-bit change in openssl etc. that opened a security hole
<infinity> It's plausible, but rather unlikely.
<infinity> Much more common to just result in crashes (for binaries), or random garbled strings.
<pitti> sure (that was the "don't think too hard" bit, fail..)
<infinity> Heh.
<infinity> BUT I SAID DON'T.
<cjwatson> pitti: That's fast-path stuff; I think http://paste.ubuntu.com/23311990/ might be slightly better
<cjwatson> but not going to look at it more today, I'll just leave that in my tree for when I next have time
<pitti> cjwatson: thanks; also, while it's an actual bug it seems that's not what broke the mirroring anyway
<jbicha> infinity: did you forget to update the seeds when you pushed the -meta updates?
<infinity> jbicha: Eh?  meta updates pull fresh seeds from bzr.
<jbicha> I'm confused then, because I'd expect these pages to be updated:
<jbicha> https://code.launchpad.net/~lubuntu-dev/ubuntu-seeds
<jbicha> https://code.launchpad.net/~ubuntu-gnome-dev/ubuntu-seeds/
<infinity> Why?
<infinity> meta is a product of seeds, not the other way around.
<infinity> I didn't change seeds, I updates metas to match the seeds.
<infinity> (or, rather, to match the intersection of seeds and the archive)
<jbicha> oh ok
-queuebot:#ubuntu-release- Unapproved: linbox (yakkety-proposed/universe) [1.4.2-1~build1 => 1.4.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linbox [sync] (yakkety-proposed) [1.4.2-1]
<infinity> pitti: You know what's missing with a virtual sprint?  No fridge full of free Coke.
 * infinity might have to make a run to buy some non-free Coke.
<pitti> infinity: and I thought it was the all-day bitching while we are locked in a small room and torture your craptop :)
<infinity> pitti: Well, that too.
<infinity> pitti: I miss it in general.  Definitely won't make a habit of this format of "sprinting", IMO.
-queuebot:#ubuntu-release- New binary: linbox [amd64] (yakkety-proposed/universe) [1.4.2-1] (no packageset)
<LocutusOfBorg> yeah it built!
<davmor2> infinity, jibel: any idea how much longer for the ubuntu isos to build tracker still says re-building
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-367 (yakkety-proposed/restricted) [367.57-0ubuntu1 => 367.57-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-367 [source] (yakkety-proposed) [367.57-0ubuntu2]
<infinity> davmor2: Erm, good question.
<infinity> davmor2: They failed mysteriously.  Retrying.
<davmor2> infinity: thanks I'll make a start on netboot they take longer anyway
<chrisccoulson> bah, I hate thunderbird
<davmor2> chrisccoulson: don't hold back dude tell how you really feel ;)
<seb128> chrisccoulson, does it still segfault on yakkety?
<chrisccoulson> seb128, yeah, it crashes in the build on armhf and arm64 and crashes at runtime on x86
<seb128> :-/
<chrisccoulson> this sucks
<seb128> getting close from release
<chrisccoulson> And yakkety has a really ancient version of thunderbird, because previous uploads never got promoted (because they fail on various architectures)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Final] has been updated (20161012.1)
<infinity> chrisccoulson: Just build it with gcc-5?
<davmor2> infinity, cyphermox, jibel: Hmm amd64 netboot mini.iso I think there might be an issue. In kvm I get a the UEFI Menu on bios hardware I get the bios menu on uefi hardware I get no boot option at all
<chrisccoulson> infinity, i'm trying that now. the thunderbird crash appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=1245783
<ubot5> Mozilla bug 1245783 in JavaScript Engine: JIT "[GCC 6] Crashes rapidly in JIT engine, jit_test.py fails" [Normal,Resolved: fixed]
<Laney> pitti: you still looking into archive-reports?
<pitti> Laney: not right now, but still on my list, yes
<Laney> I'm going to poke quickly
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161012.1)
<Laney> Oh, is it just because the release isn't changing?
<pitti> Laney: /tmp/out is sh -x archive-report , in case that's useful
<pitti> Laney: no, it's not
<Laney> ok
<pitti> Laney: mirror/ubuntu-germinate/ was definitively out of date, and a manual rsync updated it; but archive-reports doesn't
-queuebot:#ubuntu-release- Unapproved: openfoam (yakkety-proposed/universe) [4.0+dfsg1-3 => 4.0+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openfoam [source] (yakkety-proposed) [4.0+dfsg1-3ubuntu1]
<acheronuk> infinity: are those meta updates going to fix? https://bugs.launchpad.net/bugs/1632616
<ubot5> Ubuntu bug 1632616 in kubuntu-meta (Ubuntu) "firefox missing from Kubuntu YY ISO" [Undecided,Confirmed]
<infinity> acheronuk: Not sure what went wrong there.  I'm about to look into it.
<infinity> It could have just been bad timing on STeve's part and he built the image when firefox literally didn't exist in the archive. :P
<infinity> We'll get fresh ones out soonish and see what's what.
<infinity> acheronuk: Are you still testing otherwise to see if there are any other bugs that can get knocked out?
<acheronuk> infinity: I only had time to do that quick test of live session earlier. I will do more extensive testing shortly. in next hr or 2.
<infinity> acheronuk: Kay.  I'd prefer to respin once and call it done rather than do a new image for every bugfix, so the more testing, the merrier.
<acheronuk> infinity: ack
<infinity> pitti: After another publisher run, priority-mismatches might end up empty.
<infinity> Unless I can't type.
<pitti> yay
<infinity> Which is possible.
<pitti> Laney, infinity: did you find out what was wrong with the mirroring? or manually ran it again?
<infinity> Neither.
<infinity> I thought you were abusing it.
<Laney> I'm abusing it
<Laney> but it just updated from a plain run, so I'm not really much wiser
<infinity> I need to carve out time to make all that triggered from ftpmaster and throw away the terrifying timestamp-comparison stuff.
<infinity> Next week looks good.
<infinity> Before I forget for another six months.
<chrisccoulson> infinity, build with gcc-5 seems to be good (it's running here ok, and the armhf build I'm running looks like it will complete successfully)
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (xenial-proposed) [1.9-3.2ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (precise-proposed) [1.9-3ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: accepted ansible [source] (xenial-proposed) [2.0.0.2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu3 => 1:45.3.0+build1-0ubuntu4] (mozilla, ubuntu-desktop)
<balloons> Laney, might you be able to look at https://bugs.launchpad.net/trusty-backports/+bug/1632496 sometime this week?
<ubot5> Ubuntu bug 1632496 in trusty-backports "Please backport juju-mongodb3.2 3.2.9-0ubuntu1 (universe) from yakkety" [Undecided,Confirmed]
<davmor2> infinity, cyphermox: you guys around properly now?
<cyphermox> I've been for a while
<cyphermox> totally failed at switching to a UK timezone for this week
<davmor2> cyphermox: damn you ;) did you get my message earlier about netboot mini.iso
<cyphermox> yep, was about to spin it up
<davmor2> cyphermox: seems fine on vm with ovmf to do virtual uefi and secureboot, but on hardware from a usb pendrive it isn't showing a boot option
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0-0ubuntu1 => 2:14.0.1-0ubuntu1] (openstack, ubuntu-server)
<Laney> balloons: I'll try, but release & off Friday
<balloons> Laney, ack. If you can just put it on the list to have a look at, I'd appreciate it. I know the release is priority this week
<Laney> pitti: I currently think archive-reports is because http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2016-10-12/13:14:08.log
<Laney> poking
<pitti> Laney: urgh, good catch; I wasn't aware that britney blocked everything else, I thought it was all parallel
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
<Laney> it has some synchronisation points
<Laney> archive-reports
<pitti> this is one of these rare bin-only packages there (top of the list); I don't even know what they mean
<Laney> I don't know what changed
<Laney> the build in question happened ages ago
<pitti> britney changed yesterday
<Laney> you rebased it?
<pitti> yes, I did
<pitti> I tested it against yakkety, but not xenial
<Laney> brave
<pitti> looking into what changed there
<Laney> sources['testing']['kicad'] == sources['unstable']['kicad']
<Laney> it thinks there's an arm64 binary for it in testing
<Laney> which is lies
<pitti>  kicad        | 4.0.2+dfsg1-4 | xenial/universe          | source, amd64, armhf, i386, powerpc, ppc64el
<pitti>  kicad        | 4.0.2+dfsg1-4 | xenial-proposed/universe | arm64
<pitti> wow, this looks really curious
<Laney> it managed to build after the release
<pitti> so that's what these three binary-only things mean on excuses.html
<Laney> some aliasing problem in britney I think
<pitti> should we just remove these three binaries?
<Laney> bet it got added to one of them and then the other by reference
<pitti> yes, that rings a bell
<pitti> I simplified merge_sources()/merge_binaries() a bit, as it didn't occur to me that this case could even happen
<pitti>  prometheus | 0.16.2+ds-1ubuntu1 | xenial-proposed/universe | ppc64el, s390x
<pitti>  kicad        | 4.0.2+dfsg1-4 | xenial-proposed/universe | arm64
<pitti> so I'd remove these three binaries from xenial-proposed
<Laney> leave them for now so we can fix this bug
<pitti> what would be the fix? print an error message and ignore the package?
<Laney> it definitely shouldn't say that testing contains the binary
<Laney> see what happens after fixing that
<ogra_> just convert it to snap during import ;)
<Laney> we can have this in devel legitimitely, and britney should copy the binary then
<pitti> Laney: does it say that? I thought KeyError in binaries_t would exactly say that testing does not have it?
<stokachu> when altering ForceObsoletes in the upgrader package; can set <package>:<arch> to specify only that arch be obsolete?
<stokachu> pitti: cjwatson ^ do you know?
<pitti> stokachu: sorry, no clue
<stokachu> sorry thats in ubuntu-release-upgrader
<stokachu> pitti: ok np
<stokachu> slangasek: do you know if ^ is possible?
<Laney> pitti: binaries_t['arm64'][0] doesn't have kicad but sources_t['testing']['kicad'] does have kicad/arm64
<Laney> where binaries_t is self.binaries['testing']
<pitti> Laney: ack, then I think I know what to fix -- merge_sources() needs to copy the SourcePackage objects, not just ref them
<pitti> merge_binaries() didn't (conceptually) change
<cyphermox> davmor2: I concur, not booting the USB.
<Laney> pitti: that looks plausible
 * pitti writes a test case
<davmor2> cyphermox: but on vm it does which is weird cause it displays the uefi monochrome menu and not the aubergine bios one
<Laney> I'll put archive-reports back on
<Laney> update the copy on snakefruit and there should be a run before very long
<davmor2> cyphermox: so no idea what is going on with that
<cyphermox> well, depends how your VM is setup I suppose
<cyphermox> davmor2: in a VM it works fine for me.
 * cyphermox writes the same image to another USB
<pitti> Laney: reproduced
<davmor2> cyphermox: yeah that's what I say it works on vm just not on hardware
<davmor2> cyphermox: does it matter where on the disk the uefi partition is? I think iirc on the default image it is the first partition and on the mini.iso it is the second just flashing an image to confirm that though
 * Laney accepts thunderbird
<Laney> Would be quite nice to have a non ancient one on the images
<davmor2> Laney: but why when there is a claws-mail snap ;)
<Laney> well, *I'm* fine - mutt has always worked :P
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu4]
<davmor2> Laney: hahaha
<Laney> actually it made me rewrite part of my configuration a few weeks ago
 * Laney fnar
<seb128> was there a reason to not accept libreoffice?
<ogra_> it is packaged by a grumpy hamburgian ?
<Laney> not that I know of now that the block is in place - I'm looking at it atm
<seb128> thanks
<Laney> eww
<seb128> hackish?
<Laney> static bool isUbuntuTheme
<davmor2> cyphermox: it's a weird one right
<seb128> yeah :-/
<infinity> davmor2: Is that a regression?  I have several laptops here where booting EFI from USB requires the BIOS to be in a very specific and non-intuitive setup.
<infinity> davmor2: Otherwise, I get variations of "boots the MBR instead", "boots nothing at all", or "forces me to select the bootloader manually".
<pitti> Laney: fix pushed: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=eac1bf30a
<pitti> Laney: thanks for spotting!
<davmor2> infinity: you can't select anything at all there is nothing shown in the settings if you try and add an entry point
<pitti> Laney: so we'll wait until http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html updated, and then remove the renegade binaries
<Laney> pitti: nod, thanks for fixing
<Laney> I guess there's not much point in those binaries, it's not like they can go to release
 * Laney inserts fingers in ears and accepts LO
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (yakkety-proposed) [1:5.2.2-0ubuntu2]
<jbicha> are we ok with other yakkety sru uploads or would it be better if I wait until tomorrow?
<infinity> jbicha: If it's clearly an SRU with paperwork to match, etc, it's fine to upload it now, but do make sure people know what's up.
<infinity> jbicha: OTOH, doesn't hurt to hold off a day or two. :P
<cyphermox> infinity: seems like a regression to me, booting to EFI from USB is something I do often on my X230 ;)
<stokachu> infinity: are you familiar with a way to make sure a dropped 32bit arch for a package gets removed during a release upgrade?
<pitti> Laney: LibO and tbird are SRUs at this point, right?
<Laney> pitti: Either way
<pitti> Laney: britney finished for xenial; no crash, excuses updated
<Laney> If there's a chance, whack them in - otherwise don't
 * cyphermox tries the previous d-i
<pitti> ... and renegade xenial-proposed binaries zapped
<Laney> wee
<Laney> what of the nova in the queue?
<infinity> cyphermox: Ahh, I missed the bit where you reproduced.
<cyphermox> I hadn't used a mini.iso to boot to USB though
<cyphermox> it's reproducible with 483 and 482 :/
<infinity> 483 and 482 are identical, save an arm64 change, so that makes sense.
<Laney> no bug ref, but only seeded in supported
<davmor2> cyphermox: so not new but very annoying
<Laney> OTOH it could go south in autopkgtest
<cyphermox> infinity: the point was to make sure the grub change really didn't have an impact.
<infinity> stokachu: Yes, provide an empty package. :P
<infinity> stokachu: There's no way to make people remove packages, no.
<Laney> Someone else decide. Food time here.
<stokachu> infinity: ok works for me
<infinity> cyphermox: It was pretty isolated.
<infinity> cyphermox: Anyhow, try xenial?
<cyphermox> yeah, that's next.
<cyphermox> otoh the mini.isos are meant to be *isos* and probably don't carry the extra magic for booting from USB in EFI if they're just plainly dd'ed to a usb key.
<cyphermox> xenial not worky.
<infinity> Right.  That's what I thought.
<infinity> Not a regression.
<ginggs> would someone remove starpu-contrib 1.2.0~rc2+dfsg-2 please? it is stuck dep-wait.  I want to upload 1.1.5-0ubuntu7
<davmor2> cyphermox, infinity: yay! is it something I should file as a bug so it is fixed in the future?
<infinity> ginggs: Where's libcnf-dev meant to come from?
<infinity> davmor2: Nah.
<infinity> davmor2: We have a handle on what needs doing, it's more about time than bugs.
<ginggs> infinity: it is not actually used
<davmor2> infinity: no worries
<infinity> ginggs: If it's not, then why not just fix 1.2.0 instead of reverting?
<cyphermox> infinity: do you still need access to this ppc box?
<ginggs> infinity: see http://metadata.ftp-master.debian.org/changelogs/contrib/s/starpu-contrib/unstable_changelog entry for 1.1.4+dfsg-6
<infinity> ginggs: For 1.1.4, sure.  If that's also true for 1.2.0, then...?
<infinity> ginggs: But I can do the removal instead.  Not picky.  Just curious.
<ginggs> infinity: 1.2.0 is still in NEW
<ginggs> infinity: i'd be more comfortable with our 1.1.5 at this stage
<infinity> ginggs: Fair.  Removing.
<ginggs> infinity: thanks!
<infinity> ginggs: Done.
<infinity> pitti: So, I think we're approaching another "unblock stuff, migrate world, respin world" breakpoint.
<infinity> pitti: Except I'm not sure what to do about thunderbird and its long build time.
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-367 (yakkety-proposed/restricted) [367.57-0ubuntu2 => 367.57-0ubuntu3] (no packageset)
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<pitti> infinity: ^ looks reasonable?
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-367 [source] (yakkety-proposed) [367.57-0ubuntu3]
<pitti> these all seem ppc64el specific binaries
<pitti> "to be"
<infinity> Uhh.
<infinity> They shouldn't be.
<infinity> Did someone much up.
<infinity> s/much/muck/
<pitti>  servicelog | 1.1.14-1 | yakkety | source, powerpc, ppc64el
 * infinity looks.
<pitti>  lsvpd | 1.7.7-1ubuntu1 | yakkety | source, powerpc, ppc64el
<infinity> I suspect Steve didn't do as I asked and seed them on both arches. :P
 * pitti sighs at lynx in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- still out of date mirror?
<infinity> Oh, or he can't spell. ;)
<infinity>  * ppc64-diag [powerc ppc64el]  # LP: #1417608
<ubot5> Launchpad bug 1417608 in iprutils (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,New] https://launchpad.net/bugs/1417608
<infinity> Lolz.
<pitti> argh, no, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pango1.0 -- looking
<pitti> infinity: :)
<infinity> pitti: Okay, the ppc stuff should be fixed.
<infinity> pitti: pango needs to migrate to remove lynx.
<pitti> yep, just saw; at it
<infinity> Laney: Can you subscribe the desktop team to fonts-android and fonts-noto?
<infinity> Laney: Or whoever is the right team, make them do it.
<infinity> Laney: Cause I'm promoting them.
 * pitti ponders -- wait for LibO test -- force -- wait for LibO test -- force ..
<infinity> pitti: Force.
<infinity> pitti: The LibO tests are sketchy anyway.  Assuming some other tests look good, you're good.
 * pitti tosses britney a note to pretty please let it in
<pitti> infinity: are you unblocking *-mate?
<infinity> pitti: *meta?
<infinity> And yes, I will.
<pitti> infinity: yes, in particular mate-meta :)
 * pitti clearly needs caffeine, grabbing a mate tea
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20161011.1-0ubuntu0.16.04.1]
<infinity> pitti: Yeah, I'm about to do a coffee run here too.
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20161011.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20161011.1-0ubuntu0.14.04.1]
<infinity> pitti: What's the deal with this golang-go stuff that wants to move to main?  It doesn't show up on the svg.  Does that mean it's explicitly seeded?
<infinity> Or something...
<pitti> infinity: you mean "to universe"
<infinity> Hrm.
<infinity> pitti: No.
<infinity> I mean to main.
<pitti> oh, these two -- no idea
<infinity> Oh.
<pitti> I'm also suspicious about the main â universe stuff -- that smells like something switched back from using shared libs to internal copies
<infinity> I bet those are source renames.
<infinity> Or maybe not.
<pitti> where "something" is most likely amongst {juju,snapd,lxd}
<infinity> Yeah.  Complete loss as to where golang-go* in u->m is coming from.
<infinity> I guess I need to grep the germinate output and make my eyes bleed.
<infinity> Could be a built-using thing, and the svg version doesn't know how to show those?
<slangasek> pitti: the package that switched from archive packages to bundled was snapd; we're going to need to do this anyway for trusty so it doesn't significantly impact the security support story, those can probably just be demoted now
<infinity> slangasek: Any idea about the golang* stuff moving the other direction?
<pitti> hm, so why are we doing that shared lib thing then?
<tsimonq2> Attention release team: https://lists.ubuntu.com/archives/lubuntu-devel/2016-October/000867.html
<slangasek> infinity: no, I haven't traced it yet.  maybe xnox can patch things for us to give us a better explanation than 'rescued from'
<infinity> tsimonq2: That's because slangasek jumped the gun on building your alternate, I suspect.  A rebuild will fix it.
<jdstrand> pitti: chrisccoulson mentioned a procedural question regarding flash updates yesterday. for the future, these are simple security updates that he owns and the only reason an archive admin is involved is because of a limitation in LP where he needs us
<infinity> slangasek: A little grep-dctrl or grepping of germinate-output will probably make it obvious.  I'll look after I get back from buying a giant coffee and a slightly less giant doughnut.
<jdstrand> pitti: as such, all I do is make sure he uploaded to the right release when accepting from unapproved, then I follow:
<jdstrand> https://wiki.ubuntu.com/ArchiveAdministration#Handling_updates_to_partner
<tsimonq2> thank you infinity
<jdstrand> pitti: and hello btw :)
<pitti> hey jdstrand!
<jdstrand> I'm happy to continue to be the go to person for those (I just happened to be off yesterday)
<slangasek> infinity: amusingly, golang-gocheck is brought in by ubuntu-push, which was also what was pulling in the *previous* batch that we asked them to drop instead of MIRing
<xnox> slangasek, golang-ubuntu-push-dev wants golang-go-xdg, but you found it too already. I'm slow =)
<slangasek> xnox: yes; I don't want you to look at Packages files for me, I want you to fix it so c-m reports it for me and I don't have to look elsewhere ;)
 * xnox ponders how to find all of that in the archive report.
 * xnox ponders to write dctrl-grep query for those, nothing better like multi-pass post processing =)
-queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu3 => 4.3.0+nmu1ubuntu4] (core)
<apw> ^ infinity that is the xfsprogs upload i mentioned, this should unblock the rdeps
-queuebot:#ubuntu-release- New binary: openfoam [amd64] (yakkety-proposed/universe) [4.0+dfsg1-3ubuntu1] (no packageset)
<bregma> hey archive admins, would it be possible to have Mir-0.24.1 copied from yakkety overlay PPA to the Ubuntu archives? evidently it missed landing in the yakkety archives proper because of the ongoing QA backlog, but it has some bugfixes for the Unity 8 desktop session
<infinity> bregma: Nope.
<slangasek> stokachu: I think none of us have looked at the ubuntu-release-upgrader code in years; sorry, I knew to point you in that direction because we used to use it a lot, but we haven't in a while and you'll have to look at the code and see what works or not
<infinity> bregma: (a) copying from an overlay to the archive is almost certainly wrong, (b) if it doesn't affect the images and live session, it can be an SRU.
<stokachu> slangasek: np, we determined that you can't just set juju:i386 in ForcedObsolete
<slangasek> ok
<stokachu> slangasek: so we'd still require a dummy package
<infinity> stokachu: You can obsolete in release-upgrader, but that does nothing for people upgrading without it.
<infinity> Upgrade quirks should be a last resort, not an excuse for not fixing the packages to upgrade properly, IMO.
<slangasek> well, we need a dummy package in xenial because it's obsoleted in that release and ubuntu-release-upgrader code only triggers on upgrades between releases
<stokachu> so we could ForcedObsolete=juju-32bit-package and that would take care of that scenario?
<stokachu> think they called the dummy package juju-32bit-unsupported
<slangasek> davmor2: why are you testing the mini.iso?  We don't even have test cases for that on the iso tracker
<cyphermox> well that's why I suggested putting the debconf prompt in juju, and let it Conflict: juju-2.0 [armhf i386 powerpc] ?
<cyphermox> stokachu: ^
<davmor2> slangasek: netboot install uses mini.iso
<stokachu> cyphermox: i never saw that
<cyphermox> that way you prompt, and don't need the transitional package
<cyphermox> that may not work though
<stokachu> cyphermox: that also doesn't solve the issue between release upgrades
<cyphermox> well, it means you won't have juju-2.0.
<infinity> stokachu: I'm confused about why this is a difficult problem to solve...
<jderose> pitti: if systemd "fails to deactivate swap" when trying to reboot after installing from the yakkety desktop ISO, could that make the reboot hang? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1632767
<cyphermox> what problem are you referring to then?
<ubot5> Ubuntu bug 1632767 in systemd (Ubuntu) "yakkety: desktop ISO fails to reboot after install: Failed deactivating swap" [Undecided,New]
<infinity> stokachu: You switched juju from arch:all to arch:(list).  juju should continue to exist on all arches, but be empty on some.
<stokachu> what happens during a release upgrade from juju arch:all to arch:(list)?
<stokachu> does that matter?
<slangasek> stokachu: nack on adding extra dummy packages just to be able to use ForcedObsolete.  The dummy package should be juju-2.0, which on upgrade should tell the user it's been neutered.
<slangasek> davmor2: no, netboot uses *netboot*
<infinity> stokachu: The archiness of the package matters not on upgrade.
<slangasek> davmor2: if you're testing the netboot test cases with the mini.iso, that's completely beside the point
<stokachu> slangasek: so im trying to understand what you meant when you said add juju to the obsoletes list?
<slangasek> and if the iso tracker test cases don't make this clear, we need to fix this
<xnox> a way to test netboot is with libvirt tftp provider and the netboot files.
<slangasek> stokachu: I meant for you to do what you tried to do and found it didn't work because arch-specific
<stokachu> slangasek: ah
<stokachu> so for xenial then we just change the arch and put a debconf template on juju-2.0?
<cyphermox> yes
<davmor2> slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/368/builds/133152/downloads check the iso to download this has been the way netboot has been tested for as long as I can remember
<cyphermox> stokachu: debconf should only prompt for 32-bit arches though
<stokachu> cyphermox: ah, .. so how do you do that? :)
<slangasek> davmor2: wow, ok.  that's completely wrong then and we should really stop having you waste your time doing that, because it does not actually test the netboot image
<davmor2> slangasek: that or rename it
<slangasek> davmor2: I suspect the problem here is that none of us who were actually testing these things before were looking at the download link :/
<cyphermox> stokachu: test for the architecture in debian/config; where you do the db_input.
<davmor2> slangasek: I was testing it in 6.10 that way
<slangasek> heh
<davmor2> slangasek: that what I say as long as I can remember it has been using mini.iso
<slangasek> davmor2: then I guess we've never tested the netboot images, and no one noticed any problems, so we can just stop testing them ;P
<davmor2> slangasek: it was my understanding that it used the same tools just pointing that the main archive for packages rather than a local network but I could be completely wrong
<cyphermox> stokachu: e.g. using dpkg --print-architecture; such as it's done by cups.config (check your /var/lib/dpkg/info/cups.config)
<stokachu> cyphermox: thanks relaying that now
<slangasek> davmor2: the whole point of a netboot test case should be to test that you can actually netboot
-queuebot:#ubuntu-release- Unapproved: mate-optimus (yakkety-proposed/universe) [16.10.0-1 => 16.10.1-0ubuntu1] (ubuntu-mate)
<stokachu> cyphermox: slangasek thanks
<stokachu> infinity: you to fine sir
<philroche> infinity, cpc question: Are you expecting any further changes to the packages we care about or are we in a position to build a release candidate for cloud images?
<davmor2> slangasek: let me have a play and see what I can cook up the fact that mini.iso is in the netboot infrastructure kinda make its seem like it is the thing that should be tested on the iso tracker :)
<infinity> philroche: Depends on which packages you care about.
<slangasek> davmor2: the mini.iso is entirely a byproduct of the netboot image build, both come out of the debian-installer package and we've left mini.iso around because it can be useful in some cases
<tsimonq2> So now hardinfo is no longer FTBFS but doesn't work.
<tsimonq2> (reportedly)
<davmor2> slangasek: right okay
<cyphermox> tsimonq2: yep.
<philroche> infinity, server seed essentially. I only see firefox and libreoffice being respun. anything else?
<tsimonq2> Fun...
<slangasek> philroche: infinity and I were just talking about the xfsprogs upload
<slangasek> which I'm not sure fixes anything we should hold up images for, vs. redirecting this to SRU
<tsimonq2> cyphermox: Can you please give me a hand? I'm at school...
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.1-0ubuntu1]
<philroche> slangasek, Thank you.
<cyphermox> tsimonq2: I will drive-by fix it later after I have a successful powerpc install here.
<tsimonq2> Thank you cyphermox
<tsimonq2> cyphermox: Please keep wxl in the loop as well.
<tsimonq2> He's in a morning meeting for another hour but he's technically the release manager. :P
<sewaddle> slangasek: and infinity - how are things looking for timings tomorrow.... still UK afternoon?
<infinity> sewaddle: That's my plan.
<Laney> infinity: MaaaaaaaaaaaaaAAAaaaaaaaaaaaaaAAAaaaaAAaaaaaaaaaaaybe; what pulls them in?
<infinity> Laney: ghostscript
<sewaddle> infinity: any more detail than that? time-wise?
<infinity> sewaddle: Not a precise time, no.
<infinity> sewaddle: I barely manage that when we're in the same room an hour before release. :P
<sewaddle> infinity: fair enough
<pitti> jderose: hm, I did three OVMF.fd (i. e. EFI bios) installs today, reboot worked; I'll have a closer look tomorrow
<jderose> pitti: i'll look more too. the only other "weird" thing i did was an oem install (under qemu, not on hardware)... so maybe it's something with the oem paths
<pitti> jderose: oh -- I think I actually tested manual partitioning without swap; will re-try with swap them
<pitti> then
<pitti> but, dinner/basketball/sleep time, so good night everyone!
<pitti> infinity: nice job on http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<jderose> infinity: so do you expect 20161012.1 to be the final ISO?
<jderose> pitti: actually, it just worked for me under QEMU in BIOS mode... so doesn't seem to fail every time, just some times
<infinity> jderose: Is that the one that doesn't exist yet?  If so, yeah.  All signs point to "it better be, or else".
<wxl> got out of the meeting early. are respins in process or what's the plan?
<jderose> infinity: er, 20161012.1/  doesn't exist yet?
<infinity> jderose: If it exists, then no.  The next one. :P
 * infinity isn't paying attention to serials.
<jderose> infinity: okay, gotcha :)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (yakkety-proposed/universe) [0.16 => 0.17] (ubuntukylin)
<infinity> slangasek: ^-- Missed a meta in my napalm run.
<slangasek> infinity: are you asking for review or are you self-accepting?
<infinity> slangasek: The former, though I could do the latter.
<slangasek> infinity: ok, looking
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161012.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161012.2)
<infinity> flexiondotorg: That mate-optimus, SRU or meant for your final image?
<flexiondotorg> SRU is fine.
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (yakkety-proposed/main) [2.14.0-1 => 2.14.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<infinity> flexiondotorg: Kay.  You're getting new images shortly, whether you want 'em or not, but that upload would delay you by another hour or so, hence the question.
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu5 => 0.125ubuntu6] (core)
<jbicha> webkit ^ is obviously just for sru, thanks
<flexiondotorg> infinity, Thanks for the consideration :-)
<flexiondotorg> But the crash only presents once nvidia proprietary drivers are install on hybrid graphics systems.
<flexiondotorg> So not being in the iso is fine.
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.3 => 0.122ubuntu8.4] (core)
<jbicha> infinity: whats't the respin for?
<infinity> jbicha: Cleaning up metas, fixing broken images in some cases where the mirror was out of sync, etc.  Mostly minor things (well, major in the case of flavors that didn't have a web browser...)
<infinity> Evidently, people like web browsers.
<jbicha> because Ubuntu GNOME's isos were fine and we only ship i386 and amd64
<jderose> infinity: nah, the web is a fad, no need for a browser :p
<slangasek> infinity: ubuntukylin-meta accepted - sorry for the delay
<infinity> jbicha: The meta still needed updating for archive consistency reasons.  Also, pango got an update, which affects every desktop image.
<infinity> jbicha: But if you're happy with the current images, zsyncing the new ones and applying light spot-checking is more than enough.
<jbicha> ok
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (yakkety-proposed) [0.17]
<infinity> jbicha: ie, boot, install, reboot, was anything pink that shouldn't be, was everything pink that should be, yay.
<slangasek> infinity: archive consistency> is that just consistency between the seed and the metapackage?  Or is it because the metapackage is built on all archs?
<infinity> (pick a random colour, I always seem to use "pink" because I dislike it)
<infinity> slangasek: The latter.
<slangasek> right
 * Laney orders thunderbird to hurry up :P
<slangasek> jbicha: so if you don't /support/ ubuntu-gnome on !x86, you can declare that in your metapackage source
<slangasek> otherwise, the packages need to be consistent
<infinity> (I'd not recommend doing that today :P)
<slangasek> indeed
<infinity> Laney: I'm not liking its odds.
<jbicha> well we did remove s390x because that architecture didn't seem worth it for gnome
<Laney> It's dpkg-debbing
<infinity> Oh, so it is.
<infinity> Does it have any tests to speak of, or will it sail right in?
<infinity> (Neither of those is a good answer right now, sadly)
<infinity> One means it'll take too long, the other means it won't be tested. :P
<infinity> But "it doesn't work at all right now" is a situation that can only improve, right?
<slangasek> jbicha: so by removing that architecture and not the others, you get to own the cost of inconsistencies on the other architectures requiring reuploads, even if you don't build images for those archs
<Laney> Looks like it triggers atk1.0
<Laney> No
<Laney> Other way around
 * Laney read gud
<infinity> Yeah, that way around makes more sense. :P
<Laney> Only takes a few minutes
<apw> infinity, did you take publishing manual or is there just a whole heap of stuff migrating ?
<infinity> apw: thunderbird's busy thudering.
<infinity> thundering, too.
<infinity> apw: Another one of those packages that highlights the publisher's O(lol) scaling with number of binaries.
<apw> infinity, O(lol) that should be a thing
<jderose> infinity: apw: bwahahaha, yes, O(lol) should definitely be a thing :D
<infinity> apw: It is a thing!
<infinity> apw: O(lol) is when solve difficulty appears (due to impatience) to be greater than linear.
<infinity> apw: O(whee) is when it seems to get faster with more inputs.
<apw> :)
<infinity> apw: And O(wat) is when solve time seems to be a sine wave.
<jderose> you're killing me, infinity, you're killing me :)
 * apw files a bug on launchpad "Publisher runs should be O(whee)"
<cyphermox> infinity: you're forgetting O(mg) for all those cases where you just can't do anything else but ^C.
<jderose> infinity: do you have new ISOs spinning now, or are you waiting for bits still?
<infinity> jderose: The latter, but getting there.
<jderose> infinity: cool, sorry to pester :)
<wxl> infinity: cypermox was talking about making some fixes to lubuntu's alternate installer. i assume that's one of the things you're waiting on?
<infinity> cyphermox: ^?
<cyphermox> infinity: yaboot.
<infinity> cyphermox: Oh, he didn't specify powerpc. :P
<wxl> cyphermox: oh so this only affects ppc? tsimonq2 seemed to suggest it was more general
<tsimonq2> sorry wxl
<cyphermox> hardinfo is more general, but I didn't get to that
<tsimonq2> that's correct
<infinity> wxl: I'll be looking at PPC later, but if it doesn't get fixed, it doesn't get fixed.  Best effort, etc.
<wxl> cyphermox: the problems i have seen certainly aren't architecture specific
<wxl> infinity: i could give a hoot about ppc
<infinity> wxl: Which problem(s) are you seeing?
<tsimonq2> wxl: O__o what problems?
<wxl> bug 1632675
<ubot5> bug 1632675 in debian-installer (Ubuntu) "Lubuntu's alternate installer: no kernel modules were found " [Undecided,Confirmed] https://launchpad.net/bugs/1632675
<infinity> wxl: Ahh, that should just be a rebuild away.
<infinity> wxl: Which is happening Very Soon.
<wxl> okie dokie
<wxl> carry on y'all :)
<infinity> And thunderbird built on all arches.  It's a Christmas miracle.
<Laney> Might even work if we're lucky
<Laney> Bet the arm64 upload fails
<infinity> Laney: Can you test whatever arch chrisccoulson was saying didn't work at all?  amd64?
<infinity> Laney: While I'm waiting on the sausage factory to squeeze things out.
<Laney> Am doing
<chrisccoulson> I did test amd64 earlier from a local build before I uploaded
 * Laney hopes that wget doesn't download these debug packages
 * tsimonq2 gives the release team another round of coffee and/or Red Bull
 * Laney wins at wget
 * acheronuk provides donuts
<Laney> infinity: This build is totes amazeballs
 * Laney unblocks
<davmor2> slangasek: so booting via netboot it is identical to mini.iso so I'll complete this and carry on
<slangasek> davmor2: when you say it is identical, you mean you get identical results?
<davmor2> slangasek: the initrd.gz seems to contain the same initial setup as the cdrom and it looks like the setup so far has been identical etc I'll complete it and confirm though
<slangasek> davmor2: ok.  yes, once you've managed to boot it everything *should* be identical from there on out
<slangasek> infinity: looks like *-meta have propagated, but xfsprogs did not because its binaries had not published before the britney run.  Should we divert that to SRU now?
<slangasek> and, it seems libwpd-doc now wants to bring another web browser into main (dillo)
<davmor2> slangasek: so these are the steps I followed https://help.ubuntu.com/community/Installation/NetbootInstallFromInternet so I did a base install so I had the boot stuff on the hdd and then wget'd the 2 files and then manually modded grub are those the steps you would be happier with?
<slangasek> that seems like something that can be fixed on the seed side
<slangasek> davmor2: ummmm "I wrote these files onto the hard drive" - also not testing *net*boot
<slangasek> davmor2: look, clearly this has never been tested right; we should fix that in the future so that we have meaningful netboot tests, but I don't think we're going to fix the test cases between now and 16.10 release
<slangasek> davmor2: and if you aren't actually familiar with how to netboot, I don't think it's worth you spending your time right now trying different tests that aren't actually netbooting
<davmor2> slangasek: then how should this be run as far as I can tell these are the only instructions for a pc to netboot from the archive, if this is meant to be a pxe boot from the bios then that would be another set of tests all together
<slangasek> davmor2: yes, it's precisely supposed to be a pxe boot from the firmware
<slangasek> davmor2: and I apologize that we never had eyes on these test cases to make sure they were sane
<davmor2> slangasek: no worries https://wiki.ubuntu.com/UEFI/PXE-netboot-install these are the right steps here then right?
<slangasek> davmor2: for UEFI, those should be reasonably correct yes
<slangasek> infinity: so I'm re-blocking xfsprogs, because it's now waiting on ceph autopkgtest results.  You know my position on whether xfsprogs is worth waiting for :)  If you disagree, you can always unblock it again
<slangasek> infinity: but I don't want it to slip into the release pocket right at the point where we're otherwise ready to pull the trigger on image builds
<flexiondotorg> slangasek, What is the implication of not having update xfsprogs on the iso?
<flexiondotorg> Just curious, it is the alternate file system I test with.
<slangasek> flexiondotorg: as far as I'm aware this package has no direct runtime impact, it's an upload to fix build failures
<Laney> slangasek: Looks like you missed the boat and it went in anyway
<slangasek> Laney: lulz ok
<slangasek> so, a half hour wait or so before we trigger anything
<slangasek> Laney: and what do we know now about thunderbird?  it's still unblocked, and has finished building but not publishing, so we're roughly an hour out?
<slangasek> I would suggest forcing it in now and letting the armhf + arm64 builds catch up in the next cycle, so we can start building images a half hour sooner
<slangasek> OTOH I guess you have autopkgtest results you want first
<slangasek> (maybe?  not sure where we landed on that discussion above)
<Laney> They look published to me now, so we should get adt triggered RSN
<slangasek> confirmed, published so the next p-m run will not block on out-of-date binaries anyway
<slangasek> by my reckoning, the following images are ready to respin as soon as xfsprogs publishes: kubuntu lubuntu ubuntu-gnome ubuntu-server
<slangasek> and also cloud images, gaughen rcj ^^
<slangasek> then the following need to wait for thunderbird (if we're waiting for thunderbird): ubuntu (desktop) ubuntukylin ubuntu-mate ubuntustudio xubuntu
<wxl> thank god we don't have thunderbird in lubuntu :)
<jderose> jbicha: hehe, thanks for fixing my bug description :D
<Odd_Bloke> philroche: See Steve's comment above. :)
<Laney> huh, no tests got triggered after all
-queuebot:#ubuntu-release- New source: python-mock-services (xenial-proposed/primary) [0.2-0ubuntu0.16.04.1]
<acheronuk> hopefully kubuntu will get firefox on this spin
 * acheronuk crosses everything possible that can be crossed
<Laney> I guess that debian/tests/control.in doesn't make Testsuite: autopkgtest get generated in the .dsc file, so they aren't run
<slangasek> heh
<slangasek> indeed
-queuebot:#ubuntu-release- Unapproved: evolution (yakkety-proposed/universe) [3.22.0-2ubuntu1 => 3.22.1-0ubuntu1] (ubuntugnome, ubuntukylin)
<jbicha> I'm fine with evolution being an sru
<jbicha> the email signature fix is nice though (and Kylin doesn't actually ship Evolution)
<slangasek> xfsprogs is published; requesting rebuilds for the first set identified above
<slangasek> rcj, Odd_Bloke, philroche, gaughen: ^^ I believe that means everything's settled for cloud image builds
<infinity> slangasek: Did you manually make sure the mirror was sane first?
<slangasek> infinity: yes
<infinity> Ta,
<philroche> slangasek, Thank you
<slangasek> infinity, Laney: I'm going afk in about 15 minutes and will be out for about 1.5h.  Is one of you in a position to trigger the remaining images once thunderbird publishes?  The list again AIUI is ubuntu ubuntukylin ubuntu-mate ubuntustudio xubuntu
<infinity> slangasek: Yup.
<slangasek> ok
<clivejo> how can I force sftp on dput ubuntu?
<xnox> slangasek, if i expand pkg->Built-Using->source->binaries and add those binaries as if they are reverse-depends on the binaries, things should just work no?
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Final] has been updated (20161012.1)
 * xnox is trying to pretend that Built-Using->source->binaries are a yet another "reverse-depends" type (Among with Pre-Depends, Depends, Recommends(sometimes))
<slangasek> xnox: yes, conceptually
 * xnox ponders if i need to add them as Depends for real.
<slangasek> xnox: oh, this is that horrible thing where Built-Using references source packages instead of binaries, isn't it
<slangasek> hnngh
<slangasek> which winds up being bad because we don't want to pull *all* the binaries from a given source into main
<slangasek> xnox: so you kinda sorta want the intersection of Built-Using->binaries and Build-Depends
<infinity> Or just the source.
<slangasek> heh, or that
<infinity> You can have the source in main and all the binaries in universe. :P
<slangasek> infinity: however, the -dev packages would then all get "rescued", so that's still c-m being uselessly incomplete at attribution
<xnox> infinity, that's what i currently have kind of. I force src in, and by that extension it pulls in all the rest of binaries rescued.
<xnox> slangasek, not that simple as intersection of binaries & Build-Depends, because it could be Built-Using->binaries & Build-Depends->pkg->depends
<xnox> and so on
<slangasek> xnox: I'm going to go hide in a corner now
<sudodus> I'll grab and test the Lubuntu Alternate asap :-)
<xnox> maybe all of Built-Using->binaries should be forced in as Build-Depends (old-style?)
<xnox> infinity, slangasek - in practice at the moment, it's only go, so all binaries go in.....
<slangasek> xnox: well, so, as an approximation I would prefer that to what we have now
<slangasek> but when it leads to c-m telling us to promote things that otherwise shouldn't need promoted, that'll be bad
<slangasek> xnox: oh, here you go.  Only do the Built-Using revdeps thing for binaries that are being rescued
<infinity> What it's telling us to pomote now seems correct enough, it's the missing reason that's the annoying bit.
<xnox> slangasek, i have a fix just for reason to change from: Rescued from src => Rescued from $binaries_that_list_built_using (Built-Using)
<xnox> in practice i simply do not have enough information. I only have source package.
<xnox> Maybe we should actually only be promoting source package for these?
<infinity> I think it's fair to say that if we're supporting the source due to built-using, the passive rescue of the source's -dev is probably what we want.
<infinity> But I could also be down with just promoting the source itself.
<slangasek> infinity: the behavior today of what gets rescued is fine, the lack of visible attribution is less fine
<infinity> But that means neutering germinate to not rescue binaries from packages that are promoted due to built-using.
<xnox> depends how we interpret the archive-reorg "you can always build with build-deps from universe" because we support "ubuntu-push" we do not support golang-foo-bar-baz for everything.
<infinity> slangasek: Right, I thikn I said exactly that. :P
<xnox> slangasek, but i thought your complaint was also that it is post-factum.
<xnox> before something promoted you get a bunch of messages about depends
<xnox> those are sorted
<xnox> promote, boom magical rescue stuff appears.
<slangasek> xnox: you can build with build-deps from universe, but if that build dep results in code being pulled into main (as a dep or as static linking), it has to go through MIR
<slangasek> xnox: the post-factum aspect is also annoying, yes
 * xnox changing rescue text/messaging will not help with promotion discovery (for components-missmatches)
<xnox> i think showing things earlier is better.
<slangasek> I agree
<infinity> xnox: britney refusing to act with "foo is built-using bar, which is not in the same component" would be nice, yes.
<xnox> britney currently refuses to act
<infinity> (It would also be nice if the message for "which is not installable" was less opaque to lay people :P)
<xnox> but pretends that "dependency is not satisfiable"
<infinity> Okay.
<xnox> right, that.
<infinity> So, again, just an incorrect string.
<infinity> But if britney refuses to act, how did we end up here?  britney trading bugs again, or did someone force this stuff in?
<xnox> britney prevents migration only
<infinity> Yes...
<jbicha> clivejo: have a ~/.dput.cf with something like https://paste.ubuntu.com/23314473/ but use your LP username
<infinity> xnox: I know what britney does.  But this mismatch is in the release pocket, not proposed.
<infinity> xnox: Hence, either you're wrong about britney preventing migration in this case, or someone forced it.
<xnox> so c-m shows missing deps; they are fixed; everything looks good; archive admin promotoes; _now_ c-m notices rescue & britney notices uninstalability
<infinity> Oh.
<infinity> Right, was in the release pocket in universe before someone made matters worse.
<xnox> it's probably package has migrated to release, and people are working on a MIR in the release pocket.
<infinity> Duh.
<infinity> Right, in that case, all we have is c-m to protect us.
<infinity> And it's post-facto.
<xnox> britney gap-stop was to pacify doko's claim that if we enable universe, things will rapidly pickup transitive built-using deps.
<infinity> And there's not much we can do about that.
<xnox> so, imho Adding expansion of Built-Using->binaries to be treated as yet another dependency tree is sane
<xnox> e.g. along with Pre-Depends, Depends, Recommends(sometimes)
<infinity> xnox: I think what happens now is fine, it just needs the reason.
<infinity> xnox: As in, it should be attempting to promote the source, and then let germinate rescue what it wants to.
<xnox> infinity, what happens now is frustration.
<xnox> because everybody (including AA) things everything is done, promote things, and shit happens.
<infinity> xnox: The frustration is because the report literally tells me nothing about why those things are promoting.
<xnox> ok.
<infinity> xnox: I'm not sure how you propose to fix the OTHER frustration, but that's just how MIRs in the release pocket go.
<infinity> And built-using is not special there.
<slangasek> infinity: there is also the case that, if it's behind a Built-Using, it does not show up on c-m until *after* the thing that's built using it has been promoted
<infinity> People promote or seed before deps are done and life sucks.
<slangasek> which does mean you get to what you think is the end of the MIR, then new stuff pops up
<slangasek> this is not a problem of the MIRs as a whole, and is specific to Built-Using
<infinity> slangasek: Sure, that means the MIR process needs to take built-using into account, just like any other dep.
 * xnox codes "Built-Using-Binaries" into the germinate world
<infinity> slangasek: It's not specific to built-using at all, it's just another dep.
<xnox> but first tea and biscuits
<flocculant> xnox: excellent call
<slangasek> infinity: mortals who try to traverse these deps manually for their MIRs get them wrong
<infinity> "Oh, I did an MIR for all my binary deps, but missed my built-using" is a failure of the process documentation today, the bug reporter after we fix the docs. :P
<slangasek> c-m should report it, while the MIR is in progress
<infinity> slangasek: c-m does report it, minus the useful attribution.  I feel we're talking in circles now.
<sudodus> Bug #1632675 'Lubuntu's alternate installer: no kernel modules were found' is squashed - the debian installer is running now :-)
<ubot5> bug 1632675 in debian-installer (Ubuntu) "Lubuntu's alternate installer: no kernel modules were found " [Undecided,Confirmed] https://launchpad.net/bugs/1632675
<infinity> sudodus: Good.  Please close it.
<slangasek> infinity: no, it *doesn't report it* until the reverse-built-using has been promoted
<infinity> slangasek: Eh.  That's true for all the deps too.
<infinity> Well, promoted or seeded.
<xnox> infinity, well, so when ubuntu-desktop gains dependency on "foo" the c-m lists a bunch of new things that need MIR. the whole chain of all deps, but none of the built-using.
<infinity> germinate has to want it to be in main before it'll decide what else should go with it.
<infinity> Oh.  Then that's just a bug.
<xnox> infinity, eventually once the last dep is promoted, magically the built-using of that last intermediate dep ends up in c-m.
<infinity> And one I don't understand why it exists.
<xnox> yes.
<infinity> Why does that bug exist? :P
<xnox> because my implementation of built-using is fake =)
<infinity> (Sorry, I didn't realize this bug was a thing, since we were talking about the attribution issue before)
<xnox> out of the blue, I add it to the set of packages to promote, with no links to seeds =)
<xnox> (in germinate brain, it's just there)
<infinity> Fun.
<xnox> which i'm now trying to fix =)
<xnox> properly, hopefully.
<infinity> So, I think how that should work is that when you see a built-using, the source package should be added to the same seed as the thing that triggered that.
<infinity> And then the rest should fall out correctly.  Rescues, etc.
<xnox> infinity, the biggest surprise would be: ubuntu-desktop add foo, all deps satisfied, please promoted, and then c-m explodes into gallizion of rescued golang-*-dev packages =)
<infinity> xnox: Right, okay, I agree that's awful, I didn't realize it was implemented in a way that caused that.
<infinity> Hence the confusion and talking past each other.
<xnox> infinity, i may all have landed on slangasek's plate alone... =)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Final] has been updated (20161012.1)
 * xnox kicks off autotest of s390x
<infinity> xnox: With a punch card printer and a little robot to feed them into the slot?
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Final] has been updated (20161012.1)
<Laney> PUBLISH, YOU
<infinity> Laney: It's working on it.
<Laney> MORE
<infinity> Writing out s390x indices now.
<infinity> source next, then some signing, then some dude named Bob joins your family out of the blue, and somehow instead of being creepy, it's a sign of success.
<xnox> infinity, honestly, my hackish scripts do involve using script, waiting for "screen to be ready for input", arbitrary sleeps and the like.
<xnox> i also want selenium web-browser automation to drive the missing pieces of the LPAR.
<infinity> xnox: Not impressed unless you involve a Roomba somehow.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Yakkety Final] has been updated (20161012)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Yakkety Final] has been updated (20161012)
<xnox> infinity, slangasek - i'm not entirely convinced by the rissotto recipes in hacked/wikileaked clinton emails.
<xnox> *risotto
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Final] has been updated (20161012.1)
<infinity> Laney: So, once this kubuntu build finishes, we should be in a position to refresh the mirror and do the rest.
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Final] has been updated (20161012.1)
<infinity> And there it is.  Forcing a mirror refresh.
<acheronuk> and the manifest says we have a browser. thank you :)
<infinity> acheronuk: Good, cause if you didn't, I'd have no idea why. :P
<Laney> Bonus diddlyonus
<infinity> Laney: I think that's just bone-diddly-onus.
<Laney> You bone your way and I'll bone mine
<infinity> "I'm a murd-durdilly-urdler!"
 * infinity taps his foot at rsync.
<xnox> infinity, kick of cdn mirroring too?
<infinity> Not yet.
<infinity> Laney, slangasek: remaining builds kicked off.
<infinity> Taking a bit of a coffee break, will check progress in a bit.
<Laney> Nice one
<clivejo> jbicha: when I use sftp Im getting Unable to connect to SSH host upload.ubuntu.com; EOF during negotiation
<clivejo> I can sftp to my ppa's
-queuebot:#ubuntu-release- Unapproved: hardinfo (yakkety-proposed/universe) [0.5.1-1.4ubuntu2 => 0.5.1-1.4ubuntu3] (lubuntu)
<jderose> infinity: so is there another Ubuntu desktop ISO coming still?
<wxl> jderose: waiting for thunderbird still i believe
<jderose> wxl: gotcha, thanks!
<wxl> np :)
<Laney> It's building now
<wxl> Laney: it meaning thunderbird, right? not the images themselves?
<Laney> No, the images
<Laney> https://launchpad.net/builders
<wxl> ooh yay
<wxl> Laney: thx for that link btw. didn't even know about that
<Laney> wxl: There's also https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu / https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu etc
<wxl> Laney: those i know about
<Laney> ok, well they show the same builds
<slangasek> xnox: risotto?  that's made with rice, that proves it's the Chinese not the Russians who are behind this
-queuebot:#ubuntu-release- Unapproved: zabbix (xenial-proposed/universe) [1:2.4.7+dfsg-2ubuntu2 => 1:2.4.7+dfsg-2ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Final] has been updated (20161012.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Final] has been updated (20161012.2)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Final] has been updated (20161012.2)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Final] has been updated (20161012.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161012.3)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161012.3)
-queuebot:#ubuntu-release- Unapproved: calligra (yakkety-proposed/universe) [1:2.9.7-0ubuntu18 => 1:2.9.11-0ubuntu1] (kubuntu)
<clivejo> ^^^ santa_
<infinity> jderose: ^
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.0~beta15-0ubuntu2.16.04.1 => 2.0~rc3-0ubuntu1.16.04.1] (ubuntu-server)
<jderose> infinity: that's what i'm talkin' about, daddy needs a new ISO. thanks!
<infinity> Heh
 * infinity decides to take a nap.
<santa_> pitti: â there you got it, our fixed calligra. I'm glad we demoted it temporarily to -proposed; it took some time to fix it
<santa_> clivejo: thank you very much for the upload
<clivejo> sorry it took so long, had issues with sftp!
<santa_> np
<clivejo> santa_: is there any way to get that patch for search in?
<clivejo> LP 1632848
<ubot5> Launchpad bug 1632848 in ktexteditor (Ubuntu) "Fix search on yakkety" [Undecided,New] https://launchpad.net/bugs/1632848
<santa_> clivejo: I have uploaded a fixed version to our ppa, I will test it tomorrow and give you a ping to upload it
<santa_> I hope it fits for -updates
<ginggs_> would someone accept the openfoam-examples package from NEW please? It didn't build the first time around because of OOM on amd64
<philroche> infinity, slangasek, I'm EOD now. As such I'm handing over cpc release lead to rcj
<rcj> philroche, thanks.  I'll drive from here.
<rcj> slangasek, infinity: we have images pre-publishing and testing
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161012.1)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (yakkety-proposed/universe) [16.10.10 => 16.10.11] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-netbook (yakkety-proposed/universe) [1.16.0-1 => 1.16.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (yakkety-proposed/universe) [1.16.0-1 => 1.16.1-1] (ubuntu-mate) (sync)
<tsimonq2> Thunderbird is unusable after the update for reading emails in another window
<tsimonq2> This is what it's stuck at: http://img.ctrlv.in/img/16/10/13/57fecd43b1209.png
<slangasek> tsimonq2: AIUI the previous version was also described as "unusable", was that not the case?
<tsimonq2> slangasek: it worked fine
<tsimonq2> slangasek: regression, is what I'm saying
<tsimonq2> I've been using the Thunderbird in the archive for MONTHS now
<slangasek> ok
<slangasek> tsimonq2: so, there's not really any runway for resolving this before release, unfortunately
<slangasek> tsimonq2: add it to release notes?
<slangasek> (file a bug, add to release notes)
<tsimonq2> slangasek: who ships with Thunderbird as the default?
<flexiondotorg> Ubuntu, Ubuntu MATE
<flexiondotorg> Xubuntu?
<tsimonq2> apt depends says...
<tsimonq2>   Recommends: xubuntu-desktop
<tsimonq2>   Recommends: ubuntustudio-desktop
<tsimonq2>   Recommends: ubuntukylin-desktop
<tsimonq2>   Recommends: ubuntu-mate-desktop
<tsimonq2>   Recommends: ubuntu-desktop
<tsimonq2> and that's it
<flexiondotorg> Yep, was just pasting ;-)
<tsimonq2> (there's a bunch more stuff, those are just the high-level metapackages
<tsimonq2> s/depends/rdepends/
#ubuntu-release 2016-10-13
<tsimonq2> I just grabbed the beta from ppa:mozillateam/thunderbird-next and it works fine
-queuebot:#ubuntu-release- New: accepted linbox [amd64] (yakkety-proposed) [1.4.2-1]
<tsimonq2> bug 1632893
<ubot5> bug 1632893 in thunderbird (Ubuntu) "Thunderbird can't open emails in new tabs" [Undecided,New] https://launchpad.net/bugs/1632893
<eylul> Hi. any chance the calligra package in the upload queue could be accepted at this stage? It seems the old calligra package was removed, and Krita (which is part of it) is a default program and seeded by ubuntustudio.
<tsimonq2> cyphermox: in your hardinfo upload, you forgot to update "Last-Update: 2016-10-01" in debian/patches/04-fix-ftbfs-shared-symbols.diff
<tsimonq2> cyphermox: if there's a way you can reasonably do that without too much hassle, I'd highly suggest doing so ;)
<tsimonq2> cyphermox: after all, it hasn't been accepted yet
<cyphermox> I don't think it's critical enough that it matters
<tsimonq2> ok fair enough
-queuebot:#ubuntu-release- Unapproved: preseed (trusty-proposed/main) [1.62ubuntu1 => 1.62ubuntu2] (core)
<cyphermox> slangasek: can you please reject preseed in trusty queue so I can reupload with a correct version number?
-queuebot:#ubuntu-release- Unapproved: preseed (xenial-proposed/main) [1.71ubuntu1 => 1.71ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: nvidia-cuda-toolkit (yakkety-proposed/multiverse) [7.5.18-4 => 8.0.44-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-cuda-toolkit [source] (yakkety-proposed) [8.0.44-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20161003.0.7ac7d1b-0ubuntu1 => 3.20.1+git20161013.0.d77d6cf-0ubuntu1] (ubuntu-desktop)
<slangasek> cyphermox: done
-queuebot:#ubuntu-release- Unapproved: rejected preseed [source] (trusty-proposed) [1.62ubuntu2]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (yakkety-proposed/universe) [0.14-0ubuntu1 => 1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (yakkety-proposed) [1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (yakkety-proposed/universe) [1.1-0ubuntu1 => 1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: snapd-glib [amd64] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [ppc64el] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [i386] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [arm64] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [armhf] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [powerpc] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [s390x] (yakkety-proposed/universe) [1.2-0ubuntu1] (no packageset)
<xnox> slangasek, just make texas blue, and everything will be fine....
<xnox> speaking of which ev appears to not be voting
<slangasek> ginggs: openfoam, 107 overrides of lintian errors does not give me warm fuzzies about accepting this package into a release.  are these existing errors in the Debian version?
-queuebot:#ubuntu-release- New: accepted snapd-glib [amd64] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [armhf] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [powerpc] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [arm64] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [ppc64el] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [i386] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [s390x] (yakkety-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dasher [sync] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New binary: dasher [i386] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [ppc64el] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [s390x] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [amd64] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [powerpc] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [armhf] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dasher [arm64] (yakkety-proposed/universe) [4.11+git20130508.adc653-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted dasher [i386] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [s390x] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [ppc64el] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [amd64] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [armhf] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [arm64] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- New: accepted dasher [powerpc] (yakkety-proposed) [4.11+git20130508.adc653-3]
-queuebot:#ubuntu-release- Unapproved: tcpdump (yakkety-proposed/main) [4.7.4-1ubuntu1 => 4.7.4-1ubuntu1.16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: apparmor (yakkety-proposed/main) [2.10.95-4ubuntu5 => 2.10.95-4ubuntu5.1] (core)
<sakrecoer> pitti, santa_ any chance we can haz calligra accepted? its apretty central piece to Ubuntu Studio..
 * sakrecoer winks with eye lashes.
<sakrecoer> also, greetings everyone! we are almost there!
 * sakrecoer chants a cover of infinity 's smash hit 'freesoftware song, swedish chef remix'
<sakrecoer> just, you know, to cheer :)
<tyhicks> those tcpdump and apparmor uploads are intended to be SRUs
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop powerpc [Yakkety Final] has been updated (20161013)
<pitti> sakrecoer: absolutely, thanks for fixing!
<pitti> Good morning
<pitti> est-ce qu'on est dÃ©jÃ  lÃ  ? :)
-queuebot:#ubuntu-release- Unapproved: accepted calligra [source] (yakkety-proposed) [1:2.9.11-0ubuntu1]
<slangasek> moi non plus
<pitti> now that britney has a freeze block I'll process the uploads for the urgent SRUs
<santa_> sakrecoer: we (=kubuntu's team) uploaded it, so now it's up to the release team to accept it
<sakrecoer> \o/ thank you pitti and santa_ :) indeed i didn't fixed much, just cheered and crossed my fingers :)
<slangasek> santa_, sakrecoer: that's more than a little late for reintroducing a package. what are you looking for here? reintroduce calligra, reupload ubuntustudio-meta, respin images?
<sakrecoer> slangasek: just hopeing for the best really, i thibk you are a better judge at what is possible than me ...
<sakrecoer> ultimately, the wish is to have krita back...
<sakrecoer> but maybe we can push it in via some SRU? my experience isn't the greatest in these things..
<santa_> slangasek: about kubuntu it's not on the iso, so no need to respin ours. from a kubuntu's point of view getting it in -updates would be enough
<santa_> slangasek: the thing with calligra was that it was blocking the migration of the last kde bits in -proposed, so we agreed to demote it to -proposed only to upload later a fixed version
<pitti> slangasek: when I demoted, calligra was not on any image, so that seemed like the best way forward
<slangasek> pitti: but in fact it is seeded on ubuntustudio AFAICS?
<pitti> seeded-in-ubuntu said no, hmm
<sakrecoer> pitti, slangasek, yes this cycle its been going back and forth.. but we sure seeded until  alpha 1 i think, then got back in for beta2..
<pitti> http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.yakkety/revision/1499
<pitti> indeed, krita is on studio
<slangasek> sakrecoer: we can estimate 2h for it to finish building on all architectures; then, assuming we unblock it ahead of time and it makes its way straight into the release pocket, assume about an hour and a half for that to publish; then a reupload of ubuntustudio-meta, which will take another 1.5h to publish to the release pocket; then another hour for the image respin
<slangasek> sakrecoer: so if we put this back into the release pocket, you wouldn't even have final images for testing until ~5h from now
<sakrecoer> slangasek: ok... i'm not sure how we are looking in terms of available testers...
<sakrecoer> is there any chance to have it back in during the way to 17.04?
<pitti> seems safer to just not put it into the default install IMHO -- upgrades will get it from -updates, and new installs can just install it afterwards?
<sakrecoer> i mean have it in 16.10 for some update (uneducated question sorry)
<pitti> sakrecoer: sure, it would almost automatically be back on 17.04, unless it starts FTBFSing again
<pitti> (i. e. the next really interesting target is 18.04 LTS)
<slangasek> pitti: in that case, we probably want to add a block hint for calligra now, so it doesn't auto-migrate?
<slangasek> (and leave inconsistency between ubuntustudio-meta and calligra in the release pocket)
<pitti> agreed; adding one
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (yakkety-proposed) [3.22.1-0ubuntu1]
<sakrecoer> thank you guys! sending you loads of power and good energy... need drop out for work now... coffe cup salute!
<sakrecoer> o/
-queuebot:#ubuntu-release- Unapproved: rejected mate-optimus [source] (yakkety-proposed) [16.10.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu6]
<infinity> slangasek: The other option is to let calligra slide in but not update meta until post-release.
<infinity> (And fix the seed to make it not be there now, and be there later)
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (yakkety-proposed) [2.14.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hardinfo [source] (yakkety-proposed) [0.5.1-1.4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (yakkety-proposed) [16.10.11]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (yakkety-proposed) [2.10.95-4ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted tcpdump [source] (yakkety-proposed) [4.7.4-1ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20161013.0.d77d6cf-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected mate-netbook [sync] (yakkety-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected mate-terminal [sync] (yakkety-proposed) [1.16.1-1]
<pitti> flexiondotorg: ^ sorry aobut the three rejections, I left comments in the mail
<ginggs> slangasek: re openfoam, i don't know what you are asking
-queuebot:#ubuntu-release- New: accepted openfoam [amd64] (yakkety-proposed) [4.0+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New binary: calligra [powerpc] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [s390x] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [ppc64el] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
<pitti> sakrecoer: ^ âº
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (yakkety-proposed/multiverse) [8.0.44-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-multi-writer (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-multi-writer [sync] (yakkety-proposed) [3.22.1-1]
-queuebot:#ubuntu-release- New binary: calligra [i386] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
<apw> ginggs, "lintian --no-tag-display-limit --show-overrides ~/Downloads/libopenfoam_4.0+dfsg1-3ubuntu1_amd64.deb" shows 107 libraries with dodgy names ... slangasek is asking if those errors are in Debian as well ...
<apw> ginggs, also did you notive it is ftbfs on a number of architectures
<ginggs> apw: yes, i see it FTBFS on 32-bits, there's a bug in Debian about that, but i don't think it is high priority - not many people want to do CFD on 32-bit archs
<ginggs> apw: i assume those errors are in Debian as well, since the lintian-overrides was done in the debian packaging - all i did was reduce the number of parallel processes used during the build to prevent the OOM on our amd64 buildds
<apw> slangasek, ^
<pitti> ISO testing is outright boring -- in the good sense
<pitti> it seems even qemu/plymouth/kernel etc. learned to deal with the graphical "encrypted partition unlock" input now \o/
 * apw shakes pitti to wake him from his pleasant dream
<pitti> I was positively surprised :) plymouth and cryptsetup hadn't been friends until xenial at least
<pitti> my bet is actually on qemu (needed to re-test xenial for that, but *shrug*)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (yakkety-proposed/multiverse) [8.0.44-0ubuntu1] (no packageset)
<pitti> meh, discovered an OEM setup bug, shouldn't have said that
<infinity> pitti: jderose is usually on top of finding all of those long before release, did you do something weird?
<pitti> infinity: I did an OEM install in German, and then selected French during oem-config (after install)
<pitti> but /etc/default/locale and the desktop is still German
<infinity> Oh, curious.
<infinity> That might go back to xenial and my locales changes.
<pitti> the French locale actually got created
<infinity> Seems more likely than ubiquity suddenly changing behaviour.
 * pitti files a bug
<infinity> pitti: Betting it's not a yakkety regression, anyway.
<infinity> (but sub me to the bug)
<pitti> err, wait -- now after another reboot it's actually better
<pitti> locale is now a wild mix, though
<pitti> so just "differently broken"
<flocculant> pitti: Gerch or Freman?
<pitti> c'est eine Ã©trange Sprache
<flocculant> Dutch then ...
<ginggs> would someone please process nvidia-cuda-toolkit through NEW?  I need these in -proposed so I can upload the four rdeps.
<pitti> infinity: bug 1632978, also linked from the ISO tracker
<ubot5> bug 1632978 in ubiquity (Ubuntu) "oem-setup misconfigures locale if install and user language differ" [Undecided,New] https://launchpad.net/bugs/1632978
<pitti> acheronuk, sakrecoer: do you know, is someone testing kubuntu/i386?
<acheronuk> pitti: I could do, but only in virtualbox
<pitti> that's fine I think (maybe you can try the live system on a real machine)
<acheronuk> zsyncin....
<acheronuk> +g om that :P
-queuebot:#ubuntu-release- New binary: calligra [armhf] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
<acheronuk> ok. need more coffee while that is doing, clearly!
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (yakkety-proposed) [8.0.44-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (yakkety-proposed) [8.0.44-0ubuntu1]
<pitti> infinity: need a hand with testing the "ubuntu base" tarballs, or will you do this with some script again?
<infinity> pitti: I'll sort them.
<ppisati_> infinity: FYI - Ubuntu Base armhf are 404s now (albeit a link is there)
<ppisati_> e.g. http://cdimage.ubuntu.com/ubuntu-core/daily/20161012/yakkety-core-armhf.tar.gz
<infinity> s/core/base/
<infinity> I guess no one updated the tracker URLs.
 * infinity shrugs.
-queuebot:#ubuntu-release- New binary: calligra [amd64] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [arm64] (yakkety-proposed/universe) [1:2.9.11-0ubuntu1] (kubuntu)
 * Laney eyes pending & current
<Laney> amd64 is old
<Laney> jibel: ^- hey, can you do the stab again please?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-43.63] (core, kernel)
<Laney> ppisati_: Fixed those for you
<Laney> Weird
<Laney> Urgh, you have to do every arch separately
<ppisati_> Laney: uhm. not really
<jibel> Laney, done, it'll be updated soon
<Laney> ppisati_: 33 seconds too late
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-43.63]
<ppisati_> Laney: ok, but now there's no download link anymore
<Laney> Wait.
 * ppisati_ waits
-queuebot:#ubuntu-release- Unapproved: eztrace-contrib (yakkety-proposed/multiverse) [1.1-2-1ubuntu1 => 1.1-2-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted eztrace-contrib [source] (yakkety-proposed) [1.1-2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: hwloc-contrib (yakkety-proposed/multiverse) [1.11.3-2 => 1.11.3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: starpu-contrib (yakkety-proposed/multiverse) [1.1.5-0ubuntu6 => 1.1.5-0ubuntu7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hwloc-contrib [source] (yakkety-proposed) [1.11.3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted starpu-contrib [source] (yakkety-proposed) [1.1.5-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: pycuda (yakkety-proposed/multiverse) [2016.1-1build2 => 2016.1.2+git20160809-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pycuda [source] (yakkety-proposed) [2016.1.2+git20160809-1ubuntu1]
<Laney> ppisati_: Try now, and give me a link to the page showing the bad link if you find something wrong please
<ppisati_> Laney: http://iso.qa.ubuntu.com/qatracker/milestones/368/builds/133154/downloads
<ppisati_> Laney: i don't see any download link
<ppisati_> Laney: only a grey line
<Laney> That's netboot, where you asked about base.
<ppisati_> Laney: you are right, base works now
<infinity> There, base testing done on all arches.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Yakkety Final] has been marked as ready
<Laney> Glad we touched base
<infinity> *groan*
<apw> ugg
<willcooke> hold tight for netsplit
<flexiondotorg> infinity, I see the various powerpc builds have all been disabled.
<flexiondotorg> Why?
<infinity> flexiondotorg: Because the installed systems don't boot.
<infinity> flexiondotorg: And I have exactly zero time to fix it.  Though I have a handle on why.
<flexiondotorg> That is a know issue with a documented workaround though right.
<infinity> flexiondotorg: Err, it's really not?
<flexiondotorg> Manually partition and create an ext2/ boot.
<infinity> flexiondotorg: Oh, yes.  That would indeed work.
<infinity> flexiondotorg: But also gross.  And not the right solution.
<infinity> flexiondotorg: (If this was known, how long was it known, and why didn't anyone poke me?) :P
<infinity> Had I investigated weeks ago instead of this morning, I could have fixed it.
<infinity> flexiondotorg: I guess your call if you want to release your PPC image with a big release note about the workaround.  But it also has no testing so far.
<flexiondotorg> infinity, I have release noted it.
<flexiondotorg> The few Ubuntu MATE PowerPC users are aware of the issue.
<flexiondotorg> I got poked about it last night.
<flexiondotorg> https://bugs.launchpad.net/bugs/1606089
<flexiondotorg> https://bugs.launchpad.net/bugs/1607128
<infinity> flexiondotorg: Right, so I wish someone had escalated those to me, but oh well.
<infinity> flexiondotorg: It's actually a change in mke2fs that creates filesystems in a yaboot-incompatible way by default now.
<infinity> flexiondotorg: So, a different workaround would be to let partman create the normal layout you want, then shell out, fix the root filesystem, then do the install.
<flexiondotorg> I don't do the PowerPC testing anymore. There are three guys in the community do that now.
<flexiondotorg> My release note says manually partition and create an ext2 /boot.
<infinity> Yeah, which is icky.
<infinity> And /boot partitions lead to pepole crying about them being too small, filling up with kernels, etc.
<flexiondotorg> Yeah, but most PowerPC users are used to tweaking things to get a working system.
<infinity> flexiondotorg: Alright, well, if we re-enable that ISO, will it have tests registered in the next hour, and someone signing off on it?
<infinity> flexiondotorg: Cause up until now, it had zero tests.
<flexiondotorg> I specify creating a 1GB ext /boot.
<infinity> flexiondotorg: Which sort of implied no one cared, or they were blocked by the boot bug.
<flexiondotorg> Well, all the other images were tested up until the respin last night.
<flexiondotorg> As in, the other powerpc images for this final have been tested.
<infinity> Anyhow, I recall lubuntu mentioning something about only doing PPC for LTS, so happy to keep theirs disabled.
<flexiondotorg> The powerpc guys have simply been using the workaround I described.
<flexiondotorg> And marking the bug about extire disk not work.
<infinity> flexiondotorg: So, where is this release note?
<flexiondotorg> It goes up on ubuntu-mate.org when the images are released.
<flexiondotorg> The wiki references the correct page.
<infinity> flexiondotorg: Oh.  Can it be under the boot/install section of https://wiki.ubuntu.com/YakketyYak/ReleaseNotes ?
<flexiondotorg> Sure.
<infinity> flexiondotorg: (Both if you like, but it's an arch problem, not a flavour problem)
<infinity> flexiondotorg: Alright.  Assuming someone will smoketest that PPC ISO, I'll reenable it.
<infinity> Not releasing it without someone saying that exact stream of bits does something useful though.
<flexiondotorg> infinity, Am doing...
<infinity> And lemme try a workaround install of server.
<willcooke> flexiondotorg, poke me when you're done editing release notes, I have some changes to make too
<flexiondotorg> k
 * flexiondotorg waits for wiki to auth me...
<flexiondotorg> infinity, willcooke Release notes added.
<willcooke> thanks flexiondotorg
<willcooke> made my change and savd
<willcooke> saved
<infinity> flexiondotorg: Confirming your workaround on server as well.
<infinity> flexiondotorg: So, the workaround is incomplete.  One also needs to move /etc/yaboot.conf to /boot/etc/yaboot.conf and symlink it back.
<infinity> But once that's done, it's all good.
 * flexiondotorg updates wiki...
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Final] has been updated (20161012.1)
<Laney> Someone's saved an edit conflict
<davmor2> Laney: damn was it mine sorry if so
<Laney> I'll fix it when the lock is released if nobody else does
<Laney> Nae bother
<flexiondotorg> Laney, I'm fixing.
<Laney> ta
 * tsimonq2 hands out cups of coffee to people passing by
<flocculant> flexiondotorg: can you change xubuntu note url to https://xubuntu.org/news/xubuntu-16-10-release while there
<flexiondotorg> flocculant, Sure.
<flocculant> bah - meant Laney who has lock :p
<Laney> I'll be done in a minute
<Laney> flocculant: go
<Laney> davmor2: bug links for those bugs appreciated
<davmor2> Laney: they were in there
<davmor2> Laney: bracketed at the end
<Laney> not in my browser they weren't
<Laney> wait
<Laney> not you :P
<Laney> willcooke: that's you ^- can we have bug links for the two unity 8 things please?
<flocculant> Laney: thanks - all done
<willcooke> Laney, ack
<willcooke> Laney, you want them here, or shall I just edit when you are done?
<Laney> I'm out already
<flocculant> willcooke: so am I
<willcooke> done one, doing the other in a sec
<willcooke> done
<Laney> win
<infinity> willcooke: You happy with signing off on ubuntu-desktop?
-queuebot:#ubuntu-release- Unapproved: magnum (yakkety-proposed/universe) [3.1.1-0 => 3.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted magnum [sync] (yakkety-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been marked as ready
<willcooke> infinity, sure
 * Laney has marked them
<willcooke> ah, thanks Laney
<Laney> willcooke: no problemo!
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Final] has been marked as ready
<willcooke> \o/
<infinity> sewaddle: We'll probably be at least another hour or two while the mirror world settles, but we're approaching That Time.
<infinity> sewaddle: Will ping harder when we're closer, but here's your "between 1 and 3 hours, ish" countdown. :P
<sewaddle> excellent infinity
<apw> infinity, we gained some new NBS are we ok to rip that still ?
 * Laney zaps the auto-accept bot
<infinity> apw: Yes.
<apw> infinity, zapping
<cyphermox> morning. what have I missed?
<pitti> apw: wow, how did that creep in
<infinity> cyphermox: We decided to delay the release for a week and it's all because your packages suck.
<cyphermox> zomg!
<cyphermox> which packages exactly?
<infinity> All of them.
<cyphermox> oh noes!
<infinity> Anything you've ever uploaded.
<cyphermox> :'(
<cyphermox> heh.
<mdeslaur> hehehe
<cyphermox> infinity: can I turn off the powerpc space heater in my office now or do you need it?
<infinity> cyphermox: I'm good, you can cut the power.
<davmor2> cyphermox: love it the powerpc space heater :D
<cyphermox> davmor2: it's not even a joke.
<cyphermox> this G5 has been running under my desk all night, the room's door was closed to avoid the cat destroying everything in the room, and it was very noticeably much hotter in the room than everywhere else
<davmor2> cyphermox: hahaha I believe you my first home server to play with was a power it eat power I think that is how it got it's name ;)
-queuebot:#ubuntu-release- Unapproved: preseed (trusty-proposed/main) [1.62ubuntu1 => 1.62ubuntu1.1] (core)
<sewaddle> infinity: how are things?
<infinity> sewaddle: Thingeriffic.
<infinity> sewaddle: Waiting on Spads to finish cloudfronting and giving mirrors a bit more catch-up time, but we could be there in 30-60m, I'd say.
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.0~beta2+bzr5454-0ubuntu1 => 2.1.0~rc1+bzr5480-0ubuntu1] (ubuntu-server)
<infinity> sewaddle: How much time do you need to do your thing (or rather, how long will it take once I say "go")?
<sewaddle> infinity: 20 mins
<cyphermox> infinity: hold on, we have the new shim, we should respin the world!
<infinity> sewaddle: Alrighty.  Then I won't say go yet. ;)
<infinity> sewaddle: But we're nearly there.
<cyphermox> (and I'm obviously not serious)
<willcooke> sewaddle, would you give me a poke when things are live too, I have some marketing stuff to make live
<infinity> sewaddle: Please print my photo from the directory and splash some wine on it in the break room after we release.
<willcooke> or I'll just watching here
<sewaddle> will - no problem
<sewaddle> infinity: printing
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.0~beta2+bzr5454-0ubuntu1 => 2.1.0+bzr5480-0ubuntu1] (ubuntu-server)
<roaksoax> Hi release team! I was wondering if someone would be so kind to process https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1633064 for 0-day SRU
<ubot5> Ubuntu bug 1633064 in maas (Ubuntu) "[0-day SRU] MAAS 2.1.0" [Critical,New]
<pitti> roaksoax: I suppose I can reject your rc1 upload from 13 minutes ago and just look at the one from 3 mins ago?
<roaksoax> pitti: yes please
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (yakkety-proposed) [2.1.0~rc1+bzr5480-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (xenial-proposed) [0.29-1ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: accepted libsmbios [source] (xenial-proposed) [2.3.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.17]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-proposed) [2.0.4-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.5-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.5-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (xenial-proposed) [1.376.2]
<pitti> roaksoax: hm, this takes a fair while to get diffy..
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.1]
<flexiondotorg> Oh ,have you heard - http://www.omgubuntu.co.uk/2016/10/download-ubuntu-16-10-new-features
-queuebot:#ubuntu-release- Unapproved: accepted icinga [source] (xenial-proposed) [1.13.3-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.2]
-queuebot:#ubuntu-release- Unapproved: accepted zabbix [source] (xenial-proposed) [1:2.4.7+dfsg-2ubuntu2.1]
<infinity> flexiondotorg: Yeah, responsible journalism hard at work.
<flexiondotorg> http://insights.ubuntu.com/2016/10/13/canonical-releases-ubuntu-16-10/
-queuebot:#ubuntu-release- Unapproved: accepted preseed [source] (xenial-proposed) [1.71ubuntu1.1]
<infinity> Though that one's more annoying. :P
<apw> you know those are all "at 15:00 post"
<apw> and if pitti accepts that maas it will be wrong on the first line :)
<pitti> diff just came in, looking at it as we speak
<pitti> in the meantime I slaughtered the xenial queue :)
<infinity> pitti: My hero.
<pitti> I left juju-core as that'll take some more concentration/commitment to do (debconf stuff etc.)
<pitti> (have at it if you like)
<infinity> I've been up since before you, I think I'm about ready to have a release party and get drunk.
<cjwatson> apw: well, yakkety already has 2.1.0~beta2 ...
<roaksoax> pitti: hehe i think it is up now :)
<apw> heh so it does, so oops
<pitti> infinity: oh, I didn't specifically mean you
<pitti> in fact I'm inclined to NOT let you review it today ;)
<pitti> infinity: sounds like an excellent plan
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.0+bzr5480-0ubuntu1]
<infinity> What's the current openstack release?
<infinity> Newton.
<pitti> The Unapproved queue is empty. /me bows
<infinity> pitti: I find the easiest way to do that is to reject everything.
<pitti> flexiondotorg: did you see the three rejects?
<Laney> We should think about seeding via s3 for a bit in future
<pitti> flexiondotorg: (just making sure that the email based process works)
<Laney> Some of these things I'm testing are c-r-a-w-l-i-n-g
<flexiondotorg> I saw mate-optimus this morning.
 * apw hands pitti a double gold star
<pitti> infinity: "if it was REALLY important, it'll come back"
<flexiondotorg> That has since been uploaded to Debian. Wait to sync.
<apw> pitti, did you reap new too ?
<cjwatson> queue reject -s yakkety -Q unapproved -m bored
<pitti> flexiondotorg: no, I rejected two syncs because these are NOT appropriate for SRUs
<apw> :)
<pitti> TGIRD
<flexiondotorg> mate-netbook references a an SRY formatted bug.
<flexiondotorg> *SRU
<flexiondotorg> But no, I didn't get email about mate-terminal or mate-netbook.
<pitti> hm, I thought sync rejects would send mail too -- anyway, reason was "no referenced SRU bug"
<infinity> budgie-desktop-environment in NEW two days before release.
<infinity> Yeah, that seems unlikely.
-queuebot:#ubuntu-release- Unapproved: evolution (yakkety-proposed/universe) [3.22.1-0ubuntu1 => 3.22.1-0ubuntu2] (ubuntugnome, ubuntukylin)
<pitti> this is like whack-a-mole :) ^
<pitti> (will look at it once it becomes diffy)
<flexiondotorg> New upstream bug fix release.
<flexiondotorg>     - Fix broken mate-window-picker-applet. (LP: #1608710).
<ubot5> Launchpad bug 1608710 in mate-netbook (Ubuntu) "mate-window-picker-applet built against GTK3+ doesn't function correctly" [Medium,Fix committed] https://launchpad.net/bugs/1608710
<flexiondotorg> pitti, mate-netbook sync has that ^^ in the changelog. Is that not sufficient?
<pitti> flexiondotorg: as long as it as, yes
<flexiondotorg> Shall I just sync it again then?
<infinity> sewaddle: You're a go.
<willcooke> wheee
<sewaddle> infinity: cool... we will kick it all off
<infinity> sewaddle: Shiny.  Lemme know when it's live.
<flexiondotorg> pitti, http://metadata.ftp-master.debian.org/changelogs/main/m/mate-netbook/mate-netbook_1.16.1-1_changelog
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (yakkety-proposed) [3.22.1-0ubuntu2]
<Odd_Bloke> infinity: Are we a go for cloud images yet?
<infinity> Odd_Bloke: You are.  Web team's doing webby things, I'll be mailing the official announce in 10 or 20m.
<bdmurray> infinity: Shall I take of the metarelease file or is somebody else doing that?
<infinity> bdmurray: Happy to leave metarelease to you.
<Odd_Bloke> infinity: Danke.
<infinity> bdmurray: You can give it the ol' swapperoo in 30+ mins (or later, if you prefer breakfast)
<bdmurray> infinity: Mmm, bacon
<infinity> I just had bacon.
<sewaddle> infinity: and willcooke just deploying
<xnox> now i want bacon
<sewaddle> (the final step)
<willcooke>  sewaddle ta
<sewaddle> and we are live
<willcooke> \o/
<willcooke> thanks sewaddle
<willcooke> and thanks infinity - rockin as always
<infinity> sewaddle: Oo.
 * infinity goes to click around a bit.
<acheronuk> :)
<sewaddle> infinity: we are fixing the torrent thing
 * bdmurray discovers he's out of bacon
<infinity> bdmurray: Is life even worth living at that point?
 * rbasak thought he left a while ago
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1, Yakkety 16.10 | Archive: closed | Zany 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
<mdeslaur> congrats release team!
<acheronuk> infinity: some things are worse than just 'no bacon' http://i.imgur.com/JU3VVKO.png
 * acheronuk shudders
<infinity> acheronuk: I honestly don't get the point.
<acheronuk> me neither
<infinity> acheronuk: No fake bacon can live up to bacon, so why try?  Find a tasty vegetable to enjoy instead if you don't eat meat.
 * acheronuk nods
<Laney> Sosssssssssssssages
<acheronuk> mmmm....
<xnox> acheronuk, https://img.rt.com/files/2016.09/original/57d30d4ac36188df388b4677.jpg tea in a can
<xnox> acheronuk, microwave fondue http://www.packworld.com/sites/default/files/styles/lightbox/public/field/image/emmi_fondu_tulip_karton_400g_usa.jpg?itok=9Rfs8U1Y
<infinity> And yakkety is closed in LP.
<xnox> X-Ubuntu: Brought to you by The Royal Canadian Kilted Yaksmen
<cjwatson> never tried quorn bacon, don't really want to.  halloumi is a much better substitute.
<infinity> xnox: You're too young for the reference.
<apw> infinity, ^5
<xnox> cjwatson, i bought quorn something, but i was scared to actually eat it, i think i still have in my freezer.
 * xnox ponders if i should get rid of it
<apw> xnox, mostly tasteless, takes on flavours well though
<cjwatson> lots of quorn stuff is OK.
<acheronuk> I always pity the sailors on http://www.royalnavy.mod.uk/quorn
<cjwatson> not really a good taste substitute but it haelps with texture.
<cjwatson> anyway, well done on release, I've had the luxury of mostly ignoring this one :)
<acheronuk> thank you very much to the all the release team for your help BTW :)
<pitti> I'll have a beer tonight to celebrate, although singing Yak(k)ety Yak in our Italian place might appear a little strange
 * Laney looks forward to breaking zygotic
<pitti> Laney: sorry, don't get it -- you want to damage a cell?
<Laney> Eh?
<Laney> I was just guessing what the adjective would be...
<infinity> Zany!
<flexiondotorg> zealous
<infinity> Oh, flexiondotorg might actually be right.
<infinity> That's a good Markish adjective.
<Laney> Say it as loudly as possible to remove it from the running
<flexiondotorg> A Zealous Zebu what make GNU happy.
<flexiondotorg> Personally, I would like to see a Zesty Zorro.
<Laney> echo "Zealous Zebra" | mail -s ZZ mark@ubuntu.com
<flexiondotorg> So we can once again bust out the rightful heir of the Linux mascot.
<infinity> ZOMG it's a Zebra!
<infinity> With the upload target mandatory as all-caps, or it rejects.
<jbicha> znappy
<infinity> zoinks?
<infinity> Anyhow.  I'm going to go remind myself what sunlight looks like.
<Laney> Grey.
<Laney> Filtered by clouds.
<infinity> Or, looking out the window, I'm going to remind myself what clouds look like...
<infinity> But maybe breathe some fresh air while I do so.
<tsimonq2> I want Zealous Zebu :P
<tsimonq2> infinity: when Mark announces, I call dibs on creating the wiki pages
<infinity> tsimonq2: Knock yourself out.
<tsimonq2> I did it for the last three releases and want to make it 4 :P
<roaksoax> pitti: so I think all bugs are verification-done now. When should we expect it landing in -updates ?
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20161013.0.d77d6cf-0ubuntu1 => 3.20.1+git20161013.0.d77d6cf-0ubuntu2] (ubuntu-desktop)
<pitti> roaksoax: that confused me -- the verification was done even before the package was actually available on archive.u.c. in -proposed
<pitti> roaksoax: does that verification step actually use those, or some PPA? (it smells like the latteR)
<Laney> Mmm
<Laney> That's going to be a component-mismatch ^-
<Laney> Is there a procedure for handling that in an SRU?
<roaksoax> pitti: we have PPA, the same package uploaded to -proposed is uploaded to a PPA
<roaksoax> pitti: the only thing that differs is the changelog, since I fix the changelog for Ubuntu
<roaksoax> https://launchpad.net/~maas/+archive/ubuntu/next/
<infinity> roaksoax: But part of the verification procedure is verfying the binaries in the archive are correct.
<infinity> roaksoax: Pre-verifying a different build doesn't do that.
<roaksoax> infinity: ok, let me do that now
<infinity> Laney: MIR for snapd-glib, mention it's not just for the devel series but also retroactive to yakkety (and xenial, if that's also a target), get it approved the usual way, then we can copy from yakkety/universe to yakkety-updates/main
<Laney> infinity: It is MIRed
<infinity> Laney: So, skip ahead to "get it approved, then..."
<Laney> Copy that shizzle
<infinity> Laney: Ahh, it was already approved.  Check.
<infinity> Laney: Shame it wasn't promoted before I closed the archive.
<infinity> Actually.
<infinity> I could reopen, promote, and close. :P
<infinity> cjwatson: It's not harmful to revert from stable to frozen (assuming no new series yet), is it?
<roaksoax> infinity: binaries verfied
<infinity> roaksoax: Tell pitti. :)
<roaksoax> pitti: ^^ binaries verified ::)
<infinity> Laney: Meh, I'll just copy it.
<infinity> Not in the mood to sort out if it's harmful to hack it up in release.
<cjwatson> infinity: Should be OK, I think.
<infinity> "I think"
<Laney> infinity: Ya. I think that's easiest.
<cjwatson> Not something we test a whole lot. :-P
<infinity> cjwatson: I won't bother risking it.
<cjwatson> Sensible.
<infinity> Laney: Any idea which binaries actually need promoting?
<infinity> Laney: Guessing libsnapd-glib-dev libsnapd-glib1
-queuebot:#ubuntu-release- Unapproved: snapd-glib (yakkety-updates/universe) [1.2-0ubuntu1 => 1.2-0ubuntu1] (no packageset) (sync)
<Laney> infinity: source libsnapd-glib-dev libsnapd-glib1
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [sync] (yakkety-updates) [1.2-0ubuntu1]
<infinity> Laney: Done.
<Laney> Ta
<infinity> Laney: Your SRU lacks a bug ref.
<Laney> I -ved it
<Laney> Description: Doesn't build. Verification: Check it builds.
<Laney> :P
<infinity> Ahh.
<bluesabre> Very concise. :)
<Laney> Then EVERY bug is a regression from the bug-free state of the previous upload
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20161013.0.d77d6cf-0ubuntu2]
<infinity> Laney: ^
<Laney> infinity: The Snap installing masses thank you
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Final] has been marked as ready
<bdmurray> Apt in trusty-proposed has an armhf test failure but this doesn't seem to be new.  http://autopkgtest.ubuntu.com/packages/a/apt/trusty/armhf Should this have a bad test hint then?
-queuebot:#ubuntu-release- Unapproved: mate-netbook (yakkety-proposed/universe) [1.16.0-1 => 1.16.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Builds: 41 entries have been added, updated or disabled
<flocculant> infinity et al - thanks for everything
<infinity> Al did most of the work.
 * flocculant is taking a rest from pointlessly asking people to test things for xubuntu, so next cycle akxwi-dave will be the one doing milestoney things :)
<bdmurray> infinity: Would you want a bug for this? https://paste.ubuntu.com/23319009/
<infinity> bdmurray: I don't want any bugs for anything.
<infinity> bdmurray: Oh derp.  No, that doesn't need a bug, IMO.
<infinity> bdmurray: Just fix it, and we'll jam it through.
<infinity> bdmurray: I'll review, you can self-release it after you've verified.
<infinity> (Because I'll be asleep)
<bdmurray> infinity: Sounds like a plan
<infinity> bdmurray: Quick, before I fall asleep. :)
<bdmurray> infinity: this prebuild script is slow...
<infinity> bdmurray: Yeah, I probably wouldn't have run it for a string change.
<bdmurray> infinity: well, it finished
<infinity> \o/
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
<infinity> bdmurray: Accepted, and napping.  Go ahead and sru-release when you're satisfied it didn't magically break somehow.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.7]
<bdmurray> infinity: thanks
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-updates/main) [1:16.10.7 => 1:16.10.7] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.2.0-0ubuntu1 => 2:8.3.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (xenial-proposed/main) [2:8.2.0-0ubuntu1 => 2:8.3.0-0ubuntu1] (openstack, ubuntu-server)
<bdmurray> slangasek: Did you see my question about apt's autopackage test for trusty-proposed?
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.1-0ubuntu1.1 => 2:13.1.2-0ubuntu1] (openstack, ubuntu-server)
<slangasek> bdmurray: did, but assumed someone else had answered, sorry.  looking
<slangasek> test-bug-717891-abolute-uris-for-proxies ... FAIL
<slangasek> did it fail because spelling?
<bdmurray> I was more looking at 2.12, 2.13, 2.14 having all made it into -updates
<slangasek> indeed
<slangasek> bdmurray: so the short answer is certainly "yes", but force-badtest gives me a sad so I was trying to figure out where to file the bug
<bdmurray> slangasek: what gives you a sad? I thought this'd be a good teaching lesson for rbasak
<slangasek> bdmurray: it gives me a sad when we have to add such hints, because any force-badtest'ed package is one that we no longer get test feedback on
<slangasek> bdmurray: but it's still the correct thing to do here
<slangasek> bdmurray: you'll add it to lp:~ubuntu-sru/britney/hints-ubuntu-trusty/ ?
<bdmurray> slangasek: okay got it, I think I'll add it tomorrow when rbasak is on-line just so we can go over it
<slangasek> bdmurray: and I say it's the right thing to do here because I've reviewed the test results, it's not a regression from previous uploads, and it's definitely a bug in the test itself (that we probably aren't going to take the time to fix for trusty)
<slangasek> bdmurray: oh, and I have force-badtest hints for the two previous apt SRUs in my hint file ;)
<bdmurray> slangasek: what part of the machinery is aware of the hints? maybe the pending report should mention theres a hint?
<slangasek> bdmurray: proposed-migration knows about it, so update_excuses will show that the failure is ignored
<bdmurray> slangasek: that's if you use the right version number though
<bdmurray> slangasek: I didn't know there was hint for 2.14
<tsimonq2> Wait, is Zany actually our next adjective?!?
<wxl> tsimonq2: you know where to check, no?
<tsimonq2> q
<tsimonq2> wxl: Well I just don't know if they are informed earlier than us by Mark. :P
<cjwatson> On occasions when the release team has been informed earlier, we've also generally been under pretty strict instructions not to leak it before Mark blogs.
<cjwatson> So until you see either a blog post from Mark or an entry on https://launchpad.net/ubuntu/+series, you should assume that people are just making up placeholder names.
<wxl>  1. nothing on mark's blog
<wxl>  2. nothing on insight
 * jderose rolls dice and murmurs, "come on Zany Zebra, come on Zany Zebra"
<wxl>  3. series is still "z-series"
<wxl> so: no.
<bittin> o/
<wxl> where's the wiki page with all the suggestions?
<wxl> https://wiki.ubuntu.com/DevelopmentCodeNames
<bittin> updating to Yakkety tonight :)
<wxl> https://wiki.ubuntu.com/DevelopmentCodeNames#A17.04
<wxl> i like zealous zorse :)
<tsimonq2> I like Zealous Zebu
<tsimonq2> cjwatson: ok, fair enough :)
<slangasek> zawesome zorangutan
<wxl> zomgwtfbbq zombie
<wxl> switch lightweight and functional
<tsimonq2> wxl: *ahem*
<wxl> i mean argh
<wxl> sheesh
<valorie> \o/ torrents are seeding
<valorie> so many thanks and beers to you all you release-team heroes
 * tsimonq2 hands out one last round of donuts and coffee
<bittin> same here seeding torrents as much as i can and burned a bunch of dvd disks :)
<wxl> bittin: are you seeding ALLL the torents? :)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.4 => 0.122ubuntu8.5] (core)
<cyphermox> ^ yay me.
<cyphermox> slangasek: the initramfs-tools revert we discussed.
<valorie> it's easy to seed all the torrents if you have the bandwidth and diskspace, which I do
<valorie> and as a bonus when I go to places like SeaGL I have all the ISOs available to burn to a DVD or thumbdrive
<xnox> cjwatson, sorry to bother you but I don't see "days without release codename" graph in the archive reports / ubuntu-archive-tools, could you commit it there or point out where it is hosted?
<bdmurray> infinity: I ran sru-release but ubuntu-release-upgrader isn't in -updates
<wxl> infinity: is it to be expected that releases will happen when they happen rather than necessarily waiting until release managers are ready and/or have marked images as such?
<wxl> can someone get lubuntu in http://old-releases.ubuntu.com/ please?
<Ukikie> http://archive.ubuntu.com/ubuntu/dists/yakkety/main/dist-upgrader-all/current/ReleaseAnnouncement.html links to yakkety's wiki for the release notes.
<tsimonq2> Ukikie: you have two nicks!!!
<valorie> Ukikie: that's the usual way to do it
<valorie> oh, I think you meant to say, links to Xenial's wiki page
<Ukikie> valorie: Ah yes, meant to say that.
<valorie> which is rather more serious
<valorie> bdmurray or whoever else is about ^^^
#ubuntu-release 2016-10-14
<infinity> bdmurray: That would be because I haven't given ubuntu-sru queue admin perms on yakkety-updates yet, and you're not an AA.  Accepted your copy. :P
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [sync] (yakkety-updates) [1:16.10.7]
<bdmurray> valorie: that'll fix it
<bdmurray> infinity: hmm, I think sru-release didn't complain
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.5]
<valorie> thanks, bdmurray
<cjwatson> xnox: it's a toy on my laptop, and mostly just a passive-aggressive thing that there's no way I'm committing anywhere
<valorie> hmmm, http://archive.ubuntu.com/ubuntu/dists/yakkety/main/dist-upgrader-all/current/ReleaseAnnouncement.html still links to the Xenial wiki page https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
<cjwatson> valorie: http://archive.ubuntu.com/ubuntu/dists/yakkety-updates/main/dist-upgrader-all/current/ReleaseAnnouncement.html
<valorie> \o/
<valorie> I wanted a good link to send to my lists
<valorie> thanks cjwatson
<bdmurray> valorie: I'll be changing where the meeta-release file points now so it goes to yakkety-updates
<valorie> cool
<wxl> bdmurray: i don't think the vegetarians will like that
<infinity> bdmurray: sru-release wouldn't complain, the copy worked.  It just got stuck in unapproved. :P
<pitti> roaksoax: someone recently copied it already, so maas is all good
-queuebot:#ubuntu-release- Unapproved: fcitx (xenial-proposed/main) [1:4.2.9.1-1ubuntu1 => 1:4.2.9.1-1ubuntu1.16.04.1] (input-methods, kubuntu, ubuntu-desktop)
<bittin> Updated to Yakkety at work now aswell :)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.14 => 0.4.9-3ubuntu7.15] (core)
-queuebot:#ubuntu-release- Unapproved: mate-optimus (yakkety-proposed/universe) [16.10.0-1 => 16.10.1-1] (ubuntu-mate) (sync)
<infinity> pitti: Incoming xenial glibc SRU.
<infinity> pitti: If you want to pre-review, the source is in https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<infinity> pitti: (Sadly, LP seems to have failed to provide a useful diff, so you get to diff locally)
<infinity> apw: ^-- Or you.
 * apw looks up, huh what, ok
<pitti> infinity: my minions will be pleased!
 * pitti kills the xenial linux test, apparenlty that's affected by the "kill sshd" bug as well
<infinity> pitti: You have minions?
<pitti> you don't?
<infinity> pitti: Oh, the signal6 XFAIL?
<pitti> infinity: no, bug 1632252
<ubot5> bug 1632252 in linux (Ubuntu Yakkety) "linux autopkgtest kills sshd in testbed" [Medium,Confirmed] https://launchpad.net/bugs/1632252
<infinity> It'll certainly make autopkgtest results look less crap.
<infinity> pitti: I meant the XFAIL would make your minions happy. :P
<infinity> I have no idea how to fix your other bug, sorry. :P
<apw> infinity, will pm you some questions on this upload
-queuebot:#ubuntu-release- New: accepted python-mock-services [source] (xenial-proposed) [0.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: python-mock-services [amd64] (xenial-proposed/universe) [0.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-mock-services [amd64] (xenial-proposed) [0.2-0ubuntu0.16.04.1]
<apw> infinity, overall that looks "large" but as it is coming from a stable upstream i think that looks fine to me
<infinity> apw: I assure you that the glibc stable branches are much more stable than a certain package you maintain. ;)
<apw> infinity, indeed fully believed :)
-queuebot:#ubuntu-release- Unapproved: glibc (xenial-proposed/main) [2.23-0ubuntu3 => 2.23-0ubuntu4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (xenial-proposed) [2.23-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (xenial-proposed) [2:8.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (trusty-proposed) [1.8.9p5-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: rejected multipath-tools [source] (trusty-proposed) [0.4.9-3ubuntu7.15]
-queuebot:#ubuntu-release- Unapproved: rejected multipath-tools [source] (trusty-proposed) [0.4.9-3ubuntu7.15]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (trusty-proposed) [5.1.2-0ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.14 => 0.4.9-3ubuntu7.15] (core)
-queuebot:#ubuntu-release- Unapproved: accepted preseed [source] (trusty-proposed) [1.62ubuntu1.1]
-queuebot:#ubuntu-release- Packageset: Added directfb to lubuntu in yakkety
-queuebot:#ubuntu-release- Packageset: Added libgsf to lubuntu in yakkety
-queuebot:#ubuntu-release- Packageset: Added nemo to lubuntu in yakkety
-queuebot:#ubuntu-release- Packageset: Added makedev to lubuntu in yakkety
-queuebot:#ubuntu-release- Packageset: Added libdca to lubuntu in yakkety
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (trusty-proposed) [0.4.9-3ubuntu7.15]
<balloons> Can someone have a look at juju-core upload into xenial?
<balloons> Happy post-release day to you all!
-queuebot:#ubuntu-release- Unapproved: ifupdown (yakkety-proposed/main) [0.8.13ubuntu2 => 0.8.13ubuntu3] (core)
<stokachu> bdmurray: you available to look at a SRU for juju-core?
<bdmurray> I think its slangasek's day
<stokachu> thanks
<stokachu> what happens if a package is uploaded to yakkety-proposed while the archive is closed?
<stokachu> does it go into zany automatically or do you have to reupload?
<nacc> stokachu: well, z will open with a copy-forward of y, i think
<nacc> i'm not sure how that plays with -proposed only packages, though
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.5-0ubuntu1 => 2.0.5-0ubuntu1.1] (ubuntu-server)
<stokachu> nacc: ok thanks for the info
<nacc> stokachu: funnily enough, i just asked slangasek the same sort of question in #ubuntu-devel :)
<apw> aiui we copy y-proposed forward to z-proposed normally when it opens
<nacc> apw: that would make sense
<stokachu> ok cool
-queuebot:#ubuntu-release- New source: ibm-java80 (xenial-proposed/partner) [8.0.3.0-3]
<slangasek> stokachu, balloons: I have some concerns about this xenial-proposed upload
<balloons> slangasek, ok, what's up?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-72.80] (core, kernel)
<slangasek> balloons: - changelog not derived from previous SRU, which makes it impossible to read; this should be condensed to a single changelog entry with a single bug reference for SRU tracking bug. - re-vendorizing of golang-golang-x-crypto, which I let into yakkety because of timing but am not willing to accept into xenial without an explicit Security Team signoff (I would prefer to see
<slangasek> golang-golang-x-crypto updated first).  - juju-2.0 changed from arch: any to arch: all, which is 100% wrong and broken. - unnecessary call to dpkg --print-architecture in config script, you can just use $DPKG_MAINTSCRIPT_ARCH from the environment instead. - would like to see the "your architecture not supported" message be more verbose, "not supported" doesn't quite express "this package no
<slangasek> longer does anything on your system"
<slangasek> fwiw your architecture matching can also be more succinctly written as case $ARCH in amd64|arm64|ppc64el|s390x) <do stuff> ;; esac
<stokachu> slangasek: i think the arch: any to arch: all we were told would not match existing systems with the 32bit package installed
<balloons> slangasek, I was hoping there was a better way to get arch, ack.
<slangasek> stokachu: who told you this?
<stokachu> cyphermox i believe
<stokachu> it was for the upgrade from xenial to yakkety
<slangasek> stokachu: changing it to arch: all means that the package will be built precisely once, on the amd64 builders
<balloons> right -- wow
<slangasek> so then you would be installing amd64 binaries on all architectures, and that's not what you want
<balloons> why is it all
<slangasek> I'm guessing cyphermox was describing something else when he said that
<balloons> perhaps the juju metapackage, which does makes sense as all
<balloons> anyways, slangasek I will update the package to GA then after fixing your concerns
<slangasek> ok
<balloons> it makes the diff even bigger, but I suppose makes more sense in this case.
<balloons> I was hoping to avoid the big diff
-queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (xenial-proposed) [2.0~rc3-0ubuntu1.16.04.1]
<slangasek> the diff is already big, and I'm not going to be line-by-line'ing the upstream diff anyway
<balloons> slangasek, yea, we're just adding more debian changes as we go.. GA will have more
<stokachu> balloons: it's probably worth then pulling the latest source down and updating your changelog with whats already there
<stokachu> that'll keep the changelog diff down to just a few lines
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-72.80]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-25.27] (core, kernel)
#ubuntu-release 2016-10-15
<Kamilion> just wanna bring this up for the zany gates to open: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/1493999
<ubot5`> Ubuntu bug 1493999 in xz-utils (Ubuntu) "xz-utils package is really, really old and should be updated to 5.2.2 with multi-core support" [Wishlist,Confirmed]
<Kamilion> it landed in debian on the 7th
<Kamilion> we get a big with with multicore decompression in apt once that lands
<Kamilion> *big win
<santa_> slangasek, pitti: hi, now that yakkety is released could we get the fixed calligra in -updates?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-25.27]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (yakkety-proposed/universe) [1:3.20.1-2ubuntu3 => 1:3.20.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: file-roller (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-99.146] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-99.146]
<tjaalton> slangasek: looks like freeipa got removed from yakkety by mistake.. the one that I synced was the new version that is maintainable
<tjaalton> slangasek: is there a way to add it back?
<tjaalton> sru is fine
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-72.80~14.04.1] (kernel)
#ubuntu-release 2016-10-16
<locutus_> hi, any ETA for the archive reopen? I'm asking because I would like to do some sync/transition before the archive opens
<LocutusOfBorg> e.g. ghc sync, cmake upload, and maybe openmpi transition
<cjwatson> LocutusOfBorg: you won't get an ETA until Mark blogs the name
<cjwatson> (IME)
<LocutusOfBorg> cjwatson, I'm refreshing such page daily :)
<cjwatson> right.  no need to ask here until that happens.
<LocutusOfBorg> but I don't care about one day or one month, I care about having some syncs before the archive opens
<LocutusOfBorg> I still hope to see ghc 8 for z :)
-queuebot:#ubuntu-release- Unapproved: lightdm (yakkety-proposed/main) [1.19.5-0ubuntu1 => 1.20.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-72.80~14.04.1]
#ubuntu-release 2017-10-09
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [source] (artful-proposed) [4.13.0.1004.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [source] (artful-proposed) [4.13.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: golang-1.8-race-detector-runtime (artful-proposed/main) [0.0+svn285455-0ubuntu1 => 0.0+svn285455-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.469 => 2.470] (desktop-core)
-queuebot:#ubuntu-release- New source: golang-1.9-race-detector-runtime (artful-proposed/primary) [0.0+svn285455-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.9-race-detector-runtime [source] (artful-proposed) [0.0+svn285455-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2-sharp [amd64] (artful-proposed) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2-sharp [armhf] (artful-proposed) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mapbox-wagyu [amd64] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted webkit2-sharp [i386] (artful-proposed) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2-sharp [arm64] (artful-proposed) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-1.9-race-detector-runtime [amd64] (artful-proposed/none) [0.0+svn285455-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-raspi2 [arm64] (artful-proposed/universe) [4.13.0-1004.4] (kernel)
-queuebot:#ubuntu-release- New binary: linux-raspi2 [armhf] (artful-proposed/universe) [4.13.0-1004.4] (kernel)
-queuebot:#ubuntu-release- Unapproved: 389-admin (artful-proposed/universe) [1.1.46-1 => 1.1.46-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-admin [sync] (artful-proposed) [1.1.46-2]
-queuebot:#ubuntu-release- Unapproved: intel-gpu-tools (artful-proposed/main) [1.19-2 => 1.20-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: bossa (artful-proposed/universe) [1.3~20120408-5build3 => 1.3~20120408-5.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bossa [sync] (artful-proposed) [1.3~20120408-5.1]
-queuebot:#ubuntu-release- New: accepted linux-raspi2 [arm64] (artful-proposed) [4.13.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-raspi2 [armhf] (artful-proposed) [4.13.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: ocaml (artful-proposed/universe) [4.04.0-2ubuntu3 => 4.04.0-2ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu1 => 3.26.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.0-0ubuntu2 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.470]
<slashd> sil2100, freyes, (re: python-neutronclient) I re-ran the test against the new nova package (1:4.1.1-2ubuntu1) and it passes now. No more regression for LP: #1692334
<ubot5> Launchpad bug 1692334 in Ubuntu Cloud Archive newton "neutron bash completion helper is not installed" [Undecided,New] https://launchpad.net/bugs/1692334
<slashd> nova package: 2:13.1.4-0ubuntu4.1 sorry ^
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (artful-proposed/universe) [1.357 => 1.358] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-gmail (artful-proposed/universe) [2.5-1 => 2.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-gmail [source] (artful-proposed) [2.5-1ubuntu1]
<tsimonq2> Can someone please accept my nodejs upload?
<ddstreet> sil2100 are you the vanguard today?  if so can you push lp #1718055 to -updates please
<ubot5> Launchpad bug 1718055 in initramfs-tools (Ubuntu Trusty) "update-initramfs fails for MODULES=dep when root is on LVM wich uses nvme device" [Medium,Fix committed] https://launchpad.net/bugs/1718055
<elopio> good morning
 * Laney accepts alllll the langpacks
<tsimonq2> Laney: pls accept nodejs, it's bugfix :3
<LocutusOfBorg> also ocaml (security) libsdl2 (followup little bugfix)
<Laney> everything's going to be reviewed
<Laney> no need to ping
<LocutusOfBorg> but yeah, bottom top is fine too :)
<Laney> once the langpacks are out the queue will be readable
<LocutusOfBorg> can we have langpacks auto-accepted? or do you need to do some manual foo for them?
<LocutusOfBorg> they really add a lot of noise in the queue
<Laney> some brief sanity checking
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu1 => 1:3.26.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libseccomp (artful-proposed/main) [2.3.1-2.1ubuntu2 => 2.3.1-2.1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (artful-proposed/main) [1:17.10.6 => 1:17.10.7] (core)
-queuebot:#ubuntu-release- Unapproved: ippusbxd (artful-proposed/main) [1.30-2 => 1.31-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nodejs (artful-proposed/universe) [6.11.2~dfsg-3ubuntu1 => 6.11.4~dfsg-1ubuntu1] (kubuntu)
<tsimonq2> But shouldn't sanity checking be done before the upload? :P
<LocutusOfBorg> tsimonq2, not for automatic packages
<tsimonq2> LocutusOfBorg: oh
-queuebot:#ubuntu-release- Unapproved: libsemanage (artful-proposed/main) [2.7-1 => 2.7-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (artful-proposed/universe) [0.25 => 0.26] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (artful-proposed/universe) [2.217 => 2.218] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (artful-proposed/universe) [1.204 => 1.205] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (artful-proposed/universe) [0.172 => 0.173] (ubuntustudio)
<LocutusOfBorg> maybe we should do something like: if signature belongs to language-packs@ubuntu.com than auto-accept :) but what if the auto-foo is wrong?
<tsimonq2> Then /me wonders what kind of sanity checking needs to be done
<tsimonq2> *shrug*
<LocutusOfBorg> check if the upload was good, e.g. the system didn't misbehave in generating it
<LocutusOfBorg> I admit, I trust more the language-packs auto builder than myself :p
<Laney> I assume the uploader sanity checks them too
<Laney> but that's the same for normal uploads and we also review those
<Laney> :-)
<ddstreet> Laney are you vanguard today?
<tsimonq2> ddstreet: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing ;)
<Laney> nein
<Laney> I'm not even in the SRU team, assuming that's what you mean
<ddstreet> tsimonq2 yeah i know, but it's a holiday for adam and sil2100 hasn't replied, tho he may be in a mtg
<sil2100> (yes, will finish the meeting soon and will move onto SRU work)
<sil2100> ;)
<tsimonq2> :)
-queuebot:#ubuntu-release- Unapproved: rejected partman-efi [source] (artful-proposed) [71ubuntu2]
<ddstreet> Laney ah ok, well related to that, any chance you can do a review of my MR for lp #1453330
<ubot5> Launchpad bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
<ddstreet> if you have time and are willing
<ddstreet> sil2100 thanks
<sil2100> ddstreet: done o/
<sil2100> slashd: checking and releasing if all is good, thanks!
<ddstreet> sil2100 thanks!  i have a couple more for you, lp #1712491 and lp #1617919
<ubot5> Launchpad bug 1712491 in initramfs-tools (Ubuntu Trusty) "Add backported bnxt driver to the initramfs" [Medium,In progress] https://launchpad.net/bugs/1712491
<ubot5> Launchpad bug 1617919 in mdadm (Ubuntu) "mdadm segfault error 4 in libc-2.23.so" [Low,In progress] https://launchpad.net/bugs/1617919
<ddstreet> to reivew/sponsor if you have time
<sil2100> ddstreet: let me take a look once I go through the queues
<ddstreet> sure no hurry, thanks
<ddstreet> sil2100 also if those are enough to provide an endorsement or even 'data point' as martin did, it would be appreciated https://wiki.ubuntu.com/ddstreet/UbuntuSRUDeveloperApplication
<tsimonq2> Laney: Hey, I'd like to merge qtdeclarative-opensource-src from Debian (because it contains bugfixes) but it has an ABI bump... since all of the changes are bugfix, all rdeps should have no problem building against the new qtdeclarative... Red light or green light? :)
<tsimonq2> Note, that as long as 5.9.2 doesn't bump ABI, I'd like to SRU that and other Qt 5.9.2 friends into 17.10 after everything is handled in Debian
<tsimonq2> That's why I'd like to do the ABI bump now, before the release, because I don't think it's a good idea to do ABI bumps in an SRU :P
<sil2100> tsimonq2: hey, I'm looking at releasing lubuntu-meta from -proposed to -updates in xenial - in the comments you mentioned a related lubuntu-default-settings that needs to go in at the same time
<tsimonq2> sil2100: yep
<sil2100> tsimonq2: is that one still in the UNAPPROVED queue?
<sil2100> Ah, I see it there
<tsimonq2> sil2100: I think so. But I remember explicitly testing the exact binaries that both of those sources produced on a fresh install with no issues
<sil2100> Ok, so I won't release it, I'll review the default-settings piece from the queue first
<tsimonq2> Ok
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (xenial-proposed) [0.46.1]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (artful-proposed/main) [0.8.4 => 0.8.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted python-heatclient [source] (zesty-proposed) [1.8.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-heatclient [source] (xenial-proposed) [1.1.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (artful-proposed/main) [367.35-0ubuntu1 => 384.69-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lxd (artful-proposed/main) [2.18-0ubuntu3 => 2.18-0ubuntu4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (zesty-proposed) [2.3-3ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [2.2.0.3-2ubuntu11.5]
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (zesty-proposed) [2.2.4-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (xenial-proposed) [2.2.4-0ubuntu0.16.04.1]
<seb128> hum, is anyone reviewed the artful queue? it didn't move much since thursday :-/
-queuebot:#ubuntu-release- Unapproved: gdm3 (artful-proposed/main) [3.26.0-1ubuntu1 => 3.26.1-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: poppler (artful-proposed/main) [0.57.0-2ubuntu2 => 0.57.0-2ubuntu3] (desktop-core, ubuntu-server)
<xnox> seb128, they are all sprinting?! =)
<slashd> sil2100, thanks much appreciated
<Laney> I reviewed loads of stuff on Friday
<Laney> would be good if some others can review it this week indeed, hard to find time here :-)
-queuebot:#ubuntu-release- Unapproved: dict-zu (artful-proposed/main) [20070207-5ubuntu1 => 20070207-5ubuntu2] (ubuntu-desktop)
<seb128> xnox, I guess so
-queuebot:#ubuntu-release- Unapproved: dict-ss (artful-proposed/main) [20070206-4ubuntu2 => 20070206-4ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (artful-proposed) [2.6.5-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [sync] (artful-proposed) [3.2.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted xkeyboard-config [source] (artful-proposed) [2.19-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libxfont1 [source] (artful-proposed) [1:1.5.2-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libxfont [source] (artful-proposed) [1:2.0.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-session [sync] (artful-proposed) [17.3.20+17.10.20171006-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [source] (artful-proposed) [2.3.1-2.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ippusbxd [source] (artful-proposed) [1.31-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accountsservice (artful-proposed/main) [0.6.42-0ubuntu2 => 0.6.42-0ubuntu3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: goocanvas-2.0 (artful-proposed/universe) [2.0.2-2 => 2.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goocanvas-2.0 [sync] (artful-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: dput (artful-proposed/main) [0.9.6.4ubuntu3 => 0.9.6.4ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: dput (artful-proposed/main) [0.9.6.4ubuntu3 => 0.9.6.4ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: goocalendar (artful-proposed/universe) [0.3-1 => 0.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goocalendar [sync] (artful-proposed) [0.3-2]
-queuebot:#ubuntu-release- Unapproved: sparkleshare (artful-proposed/universe) [1.5.0-2 => 1.5.0-2ubuntu1] (cli-mono)
-queuebot:#ubuntu-release- Unapproved: bubblewrap (artful-proposed/universe) [0.1.8-3 => 0.2.0-1] (ubuntugnome) (sync)
#ubuntu-release 2017-10-10
-queuebot:#ubuntu-release- Unapproved: accepted gsettings-ubuntu-touch-schemas [sync] (artful-proposed) [0.0.7+17.10.20170922-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (artful-proposed) [7.5.0+17.10.20171004-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pcre3 (artful-proposed/main) [2:8.39-5 => 2:8.39-5ubuntu1] (core)
<elopio> Hello. Is there a way to run autopkgtests when a PPA is updated?
-queuebot:#ubuntu-release- Unapproved: diagnostics (artful-proposed/universe) [0.3.3-12 => 0.3.3-12build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted diagnostics [source] (artful-proposed) [0.3.3-12build1]
-queuebot:#ubuntu-release- Unapproved: ivtools (artful-proposed/universe) [1.2.11a1-9 => 1.2.11a1-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ivtools [source] (artful-proposed) [1.2.11a1-9build1]
-queuebot:#ubuntu-release- Unapproved: rejected dput [source] (artful-proposed) [0.9.6.4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted dict-ss [source] (artful-proposed) [20070206-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted dput [source] (artful-proposed) [0.9.6.4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [source] (artful-proposed) [2:8.39-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dict-zu [source] (artful-proposed) [20070207-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.8-race-detector-runtime [source] (artful-proposed) [0.0+svn285455-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml [source] (artful-proposed) [4.04.0-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted libexif [sync] (artful-proposed) [0.6.21-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted libsemanage [sync] (artful-proposed) [2.7-2]
-queuebot:#ubuntu-release- New binary: dict-ss [amd64] (artful-proposed/main) [20070206-4ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (artful-proposed) [1.3.26-13]
-queuebot:#ubuntu-release- Unapproved: accepted nettle [sync] (artful-proposed) [3.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted libva [sync] (artful-proposed) [1.8.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (artful-proposed) [0.81]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (artful-proposed) [1.403]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (artful-proposed) [0.173]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (artful-proposed) [1.205]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (artful-proposed) [2.218]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (artful-proposed) [0.26]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (artful-proposed) [2.0.6+dfsg1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (artful-proposed) [1:17.10.7]
-queuebot:#ubuntu-release- New: accepted dict-ss [amd64] (artful-proposed) [20070206-4ubuntu3]
-queuebot:#ubuntu-release- New: accepted golang-1.9-race-detector-runtime [amd64] (artful-proposed) [0.0+svn285455-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python3-defaults (artful-proposed/main) [3.6.3-0ubuntu1 => 3.6.3-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: openoverlayrouter (artful-proposed/universe) [1.1.1+ds1-1 => 1.1.1+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openoverlayrouter [source] (artful-proposed) [1.1.1+ds1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (artful-proposed) [1.358]
-queuebot:#ubuntu-release- Unapproved: dcm2niix (artful-proposed/universe) [1.0.20170818-1.1~build1 => 1.0.20170923-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (artful-proposed) [3.6.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted dcm2niix [sync] (artful-proposed) [1.0.20170923-1]
-queuebot:#ubuntu-release- Unapproved: freeipa (artful-proposed/universe) [4.4.4-1 => 4.4.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [sync] (artful-proposed) [4.4.4-3]
-queuebot:#ubuntu-release- Unapproved: accepted sparkleshare [source] (artful-proposed) [1.5.0-2ubuntu1]
<doko> I accepted packages which should be uncontroversal. I left the others ...
<apw> doko, heh thanks, and ugg :)
-queuebot:#ubuntu-release- Unapproved: batik (artful-proposed/universe) [1.9-2 => 1.9-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: clojure (artful-proposed/universe) [1.8.0-2 => 1.8.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted batik [sync] (artful-proposed) [1.9-3]
-queuebot:#ubuntu-release- Unapproved: cobertura (artful-proposed/universe) [1.9.4.1+dfsg-4 => 2.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clojure [sync] (artful-proposed) [1.8.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted cobertura [sync] (artful-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- Unapproved: freehep-chartableconverter-plugin (artful-proposed/universe) [2.0-9 => 2.0-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freehep-chartableconverter-plugin [sync] (artful-proposed) [2.0-10]
-queuebot:#ubuntu-release- Unapproved: lombok-ast (artful-proposed/universe) [0.2+ds-2 => 0.2+ds-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: lombok-patcher (artful-proposed/universe) [0.22-1 => 0.22-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lombok-ast [sync] (artful-proposed) [0.2+ds-3]
-queuebot:#ubuntu-release- Unapproved: accepted lombok-patcher [sync] (artful-proposed) [0.22-2]
-queuebot:#ubuntu-release- Unapproved: maven-dependency-plugin (artful-proposed/universe) [3.0.1-1 => 3.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-37.41~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-37.41] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted maven-dependency-plugin [sync] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-37.41~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-37.41]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (artful-proposed/main) [3.26.1-0ubuntu1 => 3.26.1-0ubuntu2] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: openjdk-8-jre-dcevm (artful-proposed/universe) [8u112-1 => 8u112-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8-jre-dcevm [sync] (artful-proposed) [8u112-2]
-queuebot:#ubuntu-release- Unapproved: xmlgraphics-commons (artful-proposed/universe) [2.1-2 => 2.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xmlgraphics-commons [sync] (artful-proposed) [2.2-1]
-queuebot:#ubuntu-release- Unapproved: sikulix (artful-proposed/universe) [1.1.1-1ubuntu1 => 1.1.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sikulix [source] (artful-proposed) [1.1.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xorg-server (artful-proposed/main) [2:1.19.3-1ubuntu7 => 2:1.19.4-1ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20170921+dfsg1-0ubuntu1 => 20171006+dfsg1-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (artful-proposed) [20171006+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.1-0ubuntu1]
<apw> tseliot, in your artful nvidia-prime upload you update your debhelper depends version but not the compat version in debian/compat ... is this intended ?
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (artful-proposed) [2.18-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (artful-proposed) [0.57.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (artful-proposed) [3.26.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted accountsservice [source] (artful-proposed) [0.6.42-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (artful-proposed) [3.26.1-0ubuntu2]
<tseliot> apw: err... no, actually, if I update the debian/compat file, I can probably drop the "--with python3" in the debian/rules
<tseliot> apw: if you reject that, I'll reupload
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-prime [source] (artful-proposed) [0.8.5]
<tseliot> thanks
<apw> tseliot, ^
<apw> bdmurray, update-manager ... that introduces a new untranslated string, are we sure we want to do that right now ?
<sil2100> apw: I saw an e-mail from Brian about that, didn't see any translators replying though
<jibel> https://lists.ubuntu.com/archives/ubuntu-translators/2017-October/007414.html no one replied
-queuebot:#ubuntu-release- Unapproved: golang-1.9 (artful-proposed/universe) [1.9.1-2 => 1.9.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.9 [source] (artful-proposed) [1.9.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (artful-proposed/main) [0.8.4 => 0.8.5] (ubuntu-desktop)
<tseliot> apw: I still had to keep "--with python3". I also opted for compat 9, so that I can backport it to Xenial. You should be able to see the new upload in the queue
<apw> tseliot, ok
<apw> tseliot, is there any reason that is >= 9.0.0 rather than >= 9
<tseliot> apw: it was there before, I simply replaced one digit
<tseliot> so, no
 * apw looks why that might be
<apw> it does seem to be at odds with the norm for sure
<apw> but it sorts ok in xenial by luck, so perhaps i don't care
<tseliot> apw: it shouldn't really change anything. It's kind of useless in this case, as I'm not depending on, say, >= 9.0.2
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (artful-proposed) [0.8.5]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (artful-proposed) [384.69-0ubuntu1]
<apw> tseliot, indeed ^ ... fix it for the next one
<tseliot> apw: I will, thanks
<tseliot> apw: while you're at it, are you going to approve nvidia-settings too?
 * apw hates on sync some more
<apw> tseliot, ^
<tseliot> apw: it's just a new upstream release, to go with the new nvidia driver. I only had to refresh one patch with a couple of minimal changes.
<apw> tseliot, ^ i accepted them both together
<apw> tseliot, at least for me i have queuebot accept announcements for them both about 8 lines back
<tseliot> apw: sorry, I'm not sure how I didn't see that
<apw> tseliot, it is called confirmation-bias ... we see what we expect to see
<tseliot> apw: I call it sleep deprivation. Potato potahto :P
<LocutusOfBorg> doko, your jpeg change broke badly dcm2nixx
<LocutusOfBorg> https://launchpadlibrarian.net/340332056/buildlog_ubuntu-artful-amd64.dcm2niix_1.0.20170923-1_BUILDING.txt.gz
<LocutusOfBorg> dpkg: error processing archive /tmp/apt-dpkg-install-5dOQMo/49-libturbojpeg0-dev_1.5.2-0ubuntu3_amd64.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libturbojpeg.a', which is also in package libjpeg-turbo8-dev:amd64 1.5.2-0ubuntu3
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (artful-proposed) [2:1.19.4-1ubuntu1]
<ddstreet> xnox you've done some of the last few mdadm changes, can you review/sponsor lp #1617919 if you have time
<ubot5> Launchpad bug 1617919 in mdadm (Ubuntu) "mdadm segfault error 4 in libc-2.23.so" [Low,In progress] https://launchpad.net/bugs/1617919
<doko> LocutusOfBorg: of course "badly", whatever ...
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (artful-proposed/main) [0.97ubuntu2 => 0.98ubuntu1] (desktop-core, ubuntu-server)
<LocutusOfBorg> doko, how to fix? what is your plan?
<doko> LocutusOfBorg: ship that turbojpeg crap in the turbo specifc package
<LocutusOfBorg> :( ok
<LocutusOfBorg> basically return to the ubuntu2 package?
<doko> no
<LocutusOfBorg> can you please do it? I'm lost and I don't want to make things go again in main
<xnox> ddstreet, sure
<xnox> ddstreet, i am preparing a xenial sru as we speak, and i can include that bugfix too
<ddstreet> xnox thanks!
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.470 => 2.471] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.1-0ubuntu1 => 3.26.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.18 => 2.408.20] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gcc-6 (artful-proposed/main) [6.4.0-7ubuntu1 => 6.4.0-8ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.4 => 3.3-2ubuntu7.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (artful-proposed) [15.04.1+17.10.20171003-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (artful-proposed/main) [131 => 132] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: clutter-gtk (artful-proposed/main) [1.8.4-1 => 1.8.4-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (artful-proposed) [132]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.471]
-queuebot:#ubuntu-release- Unapproved: accepted nodejs [source] (artful-proposed) [6.11.4~dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (artful-proposed) [0.36.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-gpu-tools [sync] (artful-proposed) [1.20-1]
-queuebot:#ubuntu-release- Unapproved: libdrm (xenial-proposed/main) [2.4.76-1~ubuntu16.04.1 => 2.4.83-1~16.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted bubblewrap [sync] (artful-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- Unapproved: wayland-protocols (xenial-proposed/universe) [1.1-2 => 1.10-1~16.04.1] (no packageset)
<tjaalton> so, with powerpc dropped, would it be ok to leave it's mesa/llvm at the zesty versions for 16.04.4 because llvm-5 doesn't build on xenial?
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (artful-proposed) [0.98ubuntu1]
<LocutusOfBorg> tjaalton, why llvm-5 doesn't build on xenial?
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (artful-proposed) [6.4.0-8ubuntu1]
<tjaalton> LocutusOfBorg: https://launchpadlibrarian.net/340258360/buildlog_ubuntu-xenial-powerpc.llvm-toolchain-5.0_1%3A5.0-2ubuntu1~16.04.0_BUILDING.txt.gz
<tjaalton> if you can fix it then great :)
<tjaalton> or have ideas
-queuebot:#ubuntu-release- Unapproved: accepted clutter-gtk [sync] (artful-proposed) [1.8.4-2]
<tjaalton> I could try with -3
<bdmurray> apw: Yes, I am.
<apw> bdmurray, yeah sil2100 pointed me at an email thread you started, are we waiting on that or are you actually
<apw> bdmurray, saying the before change message was all shiney and new and not well translated either, so updating
<apw> bdmurray, it doesn't reduce its quality
<LocutusOfBorg> doko, debian/libturbojpeg.install:usr/lib/*/libturbojpeg.so.0*
<LocutusOfBorg> debian/libjpeg-turbo8-dev.install:usr/lib/*/libturbojpeg.a
<LocutusOfBorg> who should ship that .a file? this is actually the issue, it is ship in turbo8-dev and turbojpeg-dev
<bdmurray> apw: I'm not waiting on a response to that and it was not well translated either.
<apw> bdmurray, ok so your recommendation would be to let it go, i am leaning there too
<bdmurray> apw: Yes, I think helping people free space in /boot is important enough to do this now.
<apw> bdmurray, okies, based on that discussion i will accept it
<bdmurray> apw: Thanks, maybe you could also look at ubuntu-release-upgrader? Its essentially the same since it came out of update-manager so many years ago.
<LocutusOfBorg> tjaalton, https://launchpadlibrarian.net/310735908/llvm-toolchain-4.0_1%3A4.0-1_1%3A4.0-1ubuntu1.diff.gz enjoy
<apw> bdmurray, where is that hiding ...
<LocutusOfBorg> we dropped that patch when powerpc has been dropped
<tjaalton> LocutusOfBorg: ahh...
<tjaalton> good catch
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (artful-proposed) [1:17.10.11]
<bdmurray> apw: Ah, sorry it already got accepted. Still catching up.
<tjaalton> LocutusOfBorg: bring it back ;) Can drop after BB is released
<apw> bdmurray, ahh ok good
<tjaalton> LocutusOfBorg: alternatively remind me in 6mo :)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.1-0ubuntu2]
<elopio> bdmurray: do you know if there's a way to run autopkgtest every time a PPA is updated?
<bdmurray> elopio: I do not know.
-queuebot:#ubuntu-release- New: accepted uvp-monitor [source] (artful-proposed) [2.2.0.315-0ubuntu1]
<elopio> maybe cjwatson ^ ?
<apw> elopio, there is not currently ... it is something we have been thinking about but have no firm plans or scheme for it
<apw> elopio, personally i track missing tests for PPAs a care about and fire them off manually, likley that does not
<apw> elopio, solve the problem you are trying to solve
<elopio> apw: I can fire them manually if they run in the launchpad arm runners, but don't know how.
<elopio> Do you have docs for that?
-queuebot:#ubuntu-release- New binary: uvp-monitor [amd64] (artful-proposed/none) [2.2.0.315-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [armhf] (artful-proposed/none) [2.2.0.315-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [arm64] (artful-proposed/none) [2.2.0.315-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [i386] (artful-proposed/none) [2.2.0.315-0ubuntu1] (no packageset)
<cjwatson> elopio: I don't have much experience with the autopkgtest runners.  They run on scalingstack, so share infrastructure with the Launchpad build farm, but they aren't part of Launchpad.
<LocutusOfBorg> elopio, https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure
<LocutusOfBorg> can't you just do the corresponding query?
<tjaalton> LocutusOfBorg: looks like most of the patch is there, just not the part about powerpc
<LocutusOfBorg> tjaalton, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8351454/+listing-archive-extra copy into your ppa, so it won't get lost
<LocutusOfBorg> not sure if it works
<LocutusOfBorg> well, I think somebody fixed the powerpc toolchain in the meanwhile
<tjaalton> LocutusOfBorg: I'm almost done with the update, will push it there
<elopio> LocutusOfBorg: let me check that. I remember having problems with the trigger field, but maybe I was doing it wrong. If I can do the request with any SSO account that will work nicely, I think.
-queuebot:#ubuntu-release- New: accepted uvp-monitor [amd64] (artful-proposed) [2.2.0.315-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [armhf] (artful-proposed) [2.2.0.315-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [arm64] (artful-proposed) [2.2.0.315-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [i386] (artful-proposed) [2.2.0.315-0ubuntu1]
<LocutusOfBorg> https://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=XXXXX&package=YYYY&ppa=FOO/BAR&trigger=PACKAGE/VERSION
<LocutusOfBorg> elopio, ^^^
<LocutusOfBorg> you need to have upload permissions in the archive for YYYY
<LocutusOfBorg> tjaalton, just to make you aware, I won't remember you anything in 6mo :) I will forget all this stuff in a matter of seconds, while deleting it from my pppa
<tjaalton> LocutusOfBorg: hehe, fair enough
<LocutusOfBorg> :)
<LocutusOfBorg> I'll probably remember that fuzzer thing
<elopio> LocutusOfBorg: oh, upload permissions will probably be a problem. Can I get permissions just for snapcraft easily? Or do I have to follow the process to become an Ubuntu-Dev?
-queuebot:#ubuntu-release- Unapproved: libjpeg-turbo (artful-proposed/main) [1.5.2-0ubuntu3 => 1.5.2-0ubuntu4] (core)
<LocutusOfBorg> elopio, I can click something for you
<LocutusOfBorg> PPU is what you are searching (per package uploads)
<nacc> elopio: that's PPU, iirc (per package upload)
<LocutusOfBorg> doko, ^^ libjpeg-turbo is fixed
<LocutusOfBorg> not sure if it makes happy your main VS universe war
<elopio> ð
<elopio> Please, click!
<LocutusOfBorg> where?
<elopio> Nevermind. I thought you meant you could click something to make me a snapcraft ppu. I'm reading the wiki now, I'll apply to the next meeting of the board.
-queuebot:#ubuntu-release- New: accepted calc-stats [amd64] (artful-proposed) [1.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libjpeg-turbo [source] (artful-proposed) [1.5.2-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: libseccomp (xenial-proposed/main) [2.2.3-3ubuntu3 => 2.3.1-2.1ubuntu2~16.04.1] (core)
<xnox> tyhicks, ^
-queuebot:#ubuntu-release- Unapproved: dell-recovery (artful-proposed/universe) [1.50 => 1.51] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dell-recovery [source] (artful-proposed) [1.51]
-queuebot:#ubuntu-release- Unapproved: poppler (artful-proposed/main) [0.57.0-2ubuntu3 => 0.57.0-2ubuntu4] (desktop-core, ubuntu-server)
<LocutusOfBorg> elopio, you can give me an autopkgtest specific failure to trigger, but I can't make you a PPU
-queuebot:#ubuntu-release- Unapproved: guzzle-sphinx-theme (artful-proposed/universe) [0.7.11-1 => 0.7.11-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libb2 (artful-proposed/universe) [0.97-3 => 0.97-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted guzzle-sphinx-theme [sync] (artful-proposed) [0.7.11-2]
-queuebot:#ubuntu-release- Unapproved: accepted libb2 [sync] (artful-proposed) [0.97-4]
<elopio> LocutusOfBorg: yes, I got that now. It's not very useful to ask you to run them for me, because this needs to happen daily.
<elopio> I can currently trigger the tests, but only if there is an associated github PR. I made a crazy script that makes a PR just to get the daily execution of autopkgtests, but it's now a little too crazy for me, not easy to understand and hard to keep track of the results.
<elopio> I'm looking for an alternative.
<LocutusOfBorg> PPU
<elopio> the PPU sounds ok, but I would have to give my credentials to the bot, or do it manually when I wake up. I will apply anyway, because it will be useful in the future.
<elopio> but, I think that the perfect solution is an automatic execution every time the PPA changes. We have the daily recipe there, sync with the github branch, it will just be magic :)
<elopio> I could just use the bot to poll the results every day, and notify about problems.
<LocutusOfBorg> nope
<LocutusOfBorg> you have to do your cookie to the bot
<LocutusOfBorg> and once a month it will need a renewal
<LocutusOfBorg> (me never checked if the cookie is autopkgtest specific or not)
<elopio> ok, I will prepare my application, and when I'm PPU I'll bother you to review my script :) In the mean time, I think I can make the github crazy script less weird.
-queuebot:#ubuntu-release- Unapproved: gcc-5 (artful-proposed/main) [5.4.1-13ubuntu1 => 5.5.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (artful-proposed) [5.5.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (artful-proposed) [0.57.0-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.6~14.04 => 2.28.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.27.6+17.10 => 2.28.2+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.6+17.04 => 2.28.2+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.6 => 2.28.2] (desktop-core, ubuntu-server)
<tyhicks> xnox: thanks! lets coordinate on testing when the time comes
-queuebot:#ubuntu-release- Unapproved: p4est (artful-proposed/universe) [1.1-4 => 1.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted p4est [sync] (artful-proposed) [1.1-5]
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-17-g45d361cb-0ubuntu1 => 17.1-18-gd4f70470-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~16.04.2 => 17.1-18-gd4f70470-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~17.04.2 => 17.1-18-gd4f70470-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (artful-proposed/universe) [0.8.9-1 => 0.8.9-1ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-software (artful-proposed/main) [3.26.0-0ubuntu3 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (artful-proposed/main) [17.10.6 => 17.10.7] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.1-1 => 3.26.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.471 => 2.472] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.472]
#ubuntu-release 2017-10-11
-queuebot:#ubuntu-release- Unapproved: unity (artful-proposed/universe) [7.5.0+17.10.20171004-0ubuntu1 => 7.5.0+17.10.20171010-0ubuntu1] (ubuntukylin) (sync)
<rbasak> mariadb-10.1's dep8 failure in artful-proposed on ppc64el and s390x is due to Debian bug 878107 in libpcre3 rather than a problem in mariadb-10.1 itself. Can we force it through on that basis please? I believe it should still be installable even though the fixed src:pcre3 is also stuck in artful-proposed.
<ubot5> Debian bug 878107 in src:pcre3 "src:pcre3: stack frame size detection is broken" [Important,Open] http://bugs.debian.org/878107
-queuebot:#ubuntu-release- Unapproved: update-manager (zesty-proposed/main) [1:17.04.7 => 1:17.04.8] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.9 => 1:16.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: libjpeg-turbo (artful-proposed/main) [1.5.2-0ubuntu4 => 1.5.2-0ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: isoquery (artful-proposed/main) [3.2.1-2 => 3.2.2-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted isoquery [sync] (artful-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (artful-proposed) [17.10.7]
-queuebot:#ubuntu-release- Unapproved: accepted libjpeg-turbo [source] (artful-proposed) [1.5.2-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (artful-proposed) [3.26.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (artful-proposed) [7.5.0+17.10.20171010-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nvptx-tools (artful-proposed/universe) [0.20170301-3 => 0.20171010-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nvptx-tools [sync] (artful-proposed) [0.20171010-1]
-queuebot:#ubuntu-release- Unapproved: ftpwatch (artful-proposed/universe) [1.23 => 1.23+nmu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ftpwatch [sync] (artful-proposed) [1.23+nmu1]
-queuebot:#ubuntu-release- Unapproved: gpsmanshp (artful-proposed/universe) [1.2.3-5 => 1.2.3-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpsmanshp [sync] (artful-proposed) [1.2.3-6]
-queuebot:#ubuntu-release- Unapproved: libcdio (artful-proposed/main) [0.83-4.2ubuntu1 => 0.83-4.3] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libaal (artful-proposed/main) [1.0.6-3build1 => 1.0.6-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.28.2+17.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.28.2+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted libaal [source] (artful-proposed) [1.0.6-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.28.2]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.28.2~14.04]
<apw> ^ snapd being replaced shortly with a new upload
-queuebot:#ubuntu-release- Unapproved: debian-installer (artful-proposed/main) [20101020ubuntu521 => 20101020ubuntu522] (core)
<doko> apw: would you mind looking at the libdebian-installer ftbfs?
<apw> doko, got a link
<apw> doko, as that package looks to be built
<doko> apw: sure, seen on the last test rebuild
<apw> ahh
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (artful-proposed) [20101020ubuntu522]
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.27.6+17.10 => 2.28.3+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.6 => 2.28.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.6~14.04 => 2.28.3~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.6+17.04 => 2.28.3+17.04] (desktop-core, ubuntu-server)
<apw> ^ i have context on those snapd uploads so i will review them
<LocutusOfBorg> rbasak, ^^ I think I got the pcre3 "fix" (I increased the stack size on that test, as suggested in the debian bug), works on porterbox
-queuebot:#ubuntu-release- Unapproved: pcre3 (artful-proposed/main) [2:8.39-5ubuntu1 => 2:8.39-5ubuntu2] (core)
<apw> tjaalton, your xorg-server upload is cratering all over ADT
<tjaalton> they always do
<apw> lovely
<tjaalton> though not to this extent
<apw> testsuite            FAIL stderr: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ubuntu'
<apw> that seems to be the common new one
<tjaalton> yeah I'll check it out, thanks
<sil2100> Would be nice if we could get it migrating for the RC tomorrow
<tjaalton> can't see how this could be caused by xserver
<tjaalton> here's the full diff https://pastebin.com/1AaE3aU9
<tjaalton> unless
<tjaalton> it's the change to xvfb-run that causes tests to trip over because they get this "error" now
<tjaalton> so, should that be reverted for artful?
<tjaalton> 1.. 2.. done
<LocutusOfBorg> please let my pcre3 upload go in, and it will unblock mariadb
-queuebot:#ubuntu-release- Unapproved: xorg-server (artful-proposed/main) [2:1.19.4-1ubuntu1 => 2:1.19.4-1ubuntu2] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: leveldb (artful-proposed/main) [1.18-5 => 1.20-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: jackd2 (artful-proposed/main) [1.9.10+20150825git1ed50c92~dfsg-2ubuntu2 => 1.9.10+20150825git1ed50c92~dfsg-5ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted jackd2 [source] (artful-proposed) [1.9.10+20150825git1ed50c92~dfsg-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [source] (artful-proposed) [2:8.39-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted leveldb [sync] (artful-proposed) [1.20-1]
-queuebot:#ubuntu-release- Unapproved: accepted libcdio [sync] (artful-proposed) [0.83-4.3]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (artful-proposed) [2:1.19.4-1ubuntu2]
<LocutusOfBorg> ./RunTest: 448: ulimit: error setting limit (Operation not permitted)
<LocutusOfBorg> damn, how can we set ulimit in builds?
<LocutusOfBorg> I tried in debian porterbox and it worked, why LP is not allowing it?
<apw> because you arn't running as root ?
<LocutusOfBorg> in porterboxes I'm running as chroot... how can we increase ulimit in builds then?
<LocutusOfBorg> I'm going to take the hammer and disable that test otherwise
-queuebot:#ubuntu-release- Unapproved: libwmf (artful-proposed/main) [0.2.8.4-10.6ubuntu1 => 0.2.8.4-10.6ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (artful-proposed) [0.8.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libwmf [source] (artful-proposed) [0.2.8.4-10.6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libxcb (artful-proposed/main) [1.11.1-1ubuntu1 => 1.12-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: pcre3 (artful-proposed/main) [2:8.39-5ubuntu1 => 2:8.39-5ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libxcb [source] (artful-proposed) [1.12-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libxml2 (artful-proposed/main) [2.9.4+dfsg1-3.1 => 2.9.4+dfsg1-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [source] (artful-proposed) [2.9.4+dfsg1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: docker.io (artful-proposed/universe) [1.13.1-0ubuntu4 => 1.13.1-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.28-dfsg-2 => 5.1.28-dfsg-3] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (artful-proposed) [1.13.1-0ubuntu5]
 * apw has a query out on the snapd upload for artful ^
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [source] (artful-proposed) [2:8.39-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: parted (artful-proposed/main) [3.2-17 => 3.2-17ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (artful-proposed) [3.2-17ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu2 => 1:3.26.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: network-manager (artful-proposed/main) [1.8.4-1ubuntu1 => 1.8.4-1ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-orca (artful-proposed/main) [3.26.0-1ubuntu1 => 3.26.0-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (artful-proposed/partner) [1:20170912.1-0ubuntu1 => 1:20171010.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mdadm (artful-proposed/main) [4.0-1 => 4.0-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [sync] (artful-proposed) [4.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.1-18-gd4f70470-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gdm3 (artful-proposed/main) [3.26.1-3ubuntu1 => 3.26.1-3ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (artful-proposed) [1.8.4-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (artful-proposed) [5.1.28-dfsg-3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: calc-stats (artful-proposed/universe) [1.5-0ubuntu1 => 1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted calc-stats [source] (artful-proposed) [1.6-0ubuntu1]
<LocutusOfBorg> rbasak, mariadb is still not fixed on s390x
-queuebot:#ubuntu-release- Unapproved: accepted gnome-orca [source] (artful-proposed) [3.26.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (artful-proposed) [3.26.1-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20171010.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu3]
<chrisccoulson> thanks to whoever approved flash/partner. Would you mind approving it for trusty -> zesty too please? :)
<chrisccoulson> (just uploaded it now)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170912.1-0ubuntu0.14.04.1 => 1:20171010.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170912.1-0ubuntu0.17.04.1 => 1:20171010.1-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170912.1-0ubuntu0.16.04.1 => 1:20171010.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dell-recovery (artful-proposed/universe) [1.51 => 1.52] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dell-recovery [source] (artful-proposed) [1.52]
<apw> mwhudson, this docker thing is a bit of a mess ...
-queuebot:#ubuntu-release- Unapproved: totem (artful-proposed/main) [3.25.90.1-0ubuntu3 => 3.26.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected ppc64-diag [source] (trusty-proposed) [2.7.4-1~14.04]
-queuebot:#ubuntu-release- Unapproved: gnome-orca (artful-proposed/main) [3.26.0-1ubuntu2 => 3.26.0-1ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: network-manager (artful-proposed/main) [1.8.4-1ubuntu2 => 1.8.4-1ubuntu3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: yelp (artful-proposed/main) [3.25.3-0ubuntu1 => 3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: webkit2-sharp (artful-proposed/universe) [2.10.9+git20160917-1ubuntu1 => 2.10.9+git20160917-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted webkit2-sharp [sync] (artful-proposed) [2.10.9+git20160917-1.1]
-queuebot:#ubuntu-release- Unapproved: whoopsie-preferences (artful-proposed/main) [0.18build1 => 0.19] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-leveldb (artful-proposed/universe) [0~svn68-3build2 => 0~svn68-3build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-leveldb [source] (artful-proposed) [0~svn68-3build3]
-queuebot:#ubuntu-release- Unapproved: persistent-cache-cpp (artful-proposed/universe) [1.0.4+16.10.20160823-0ubuntu1 => 1.0.4+16.10.20160823-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted persistent-cache-cpp [source] (artful-proposed) [1.0.4+16.10.20160823-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted squid3 [source] (trusty-proposed) [3.3.8-1ubuntu6.10]
<rbasak> LocutusOfBorg: thank you for fixing pcre3!
<rbasak> I'm not sure what the mariadb10.1 situation is now
<LocutusOfBorg> the patch fixed ppc64el but not s390x
<LocutusOfBorg> do you have some other idea?
-queuebot:#ubuntu-release- Unapproved: persistent-cache-cpp (artful-proposed/universe) [1.0.4+16.10.20160823-0ubuntu1 => 1.0.4+16.10.20160823-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted persistent-cache-cpp [source] (artful-proposed) [1.0.4+16.10.20160823-0ubuntu3]
<rbasak> LocutusOfBorg: no idea. I can ask a s390x expert to take a glance next week, but I'm not sure how much time he'll have.
<rbasak> I suspect something along simliar lines to the patch ondrej identified
<rbasak> Only this time the optimizer is probably doing something subtly different
<rbasak> LocutusOfBorg: for bug 1717666, do you know about the community security upload process? If the intention is to fix CVEs, that seems more suitable to me than an SRU.
<ubot5> bug 1717666 in borgbackup (Ubuntu Zesty) "borgbackup: multiple security issues" [Undecided,In progress] https://launchpad.net/bugs/1717666
<rbasak> Then it'll go into the security pocket. Users may subscribe to that but not regular SRUs.
<rbasak> I'm dubious about things like "Add fuse dependency" for an SRU though
<LocutusOfBorg> rbasak, fuse has been a dependency since the begin
<LocutusOfBorg> the problem is that it wasn't listed, and people not having it expecienced failures https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855812
<ubot5> Debian bug 855812 in borgbackup "borgbackup: missing fuse dependency" [Minor,Fixed]
<LocutusOfBorg> so not exactly a new feature, but something that has always been there
<LocutusOfBorg> btw it is not really suitable for security, because they are not serious CVEs
<LocutusOfBorg> I have been asked previously to handle borgbackup with standard SRU procedure from them
<LocutusOfBorg> so please don't ask me to ping/pong :D
-queuebot:#ubuntu-release- Unapproved: empathy (artful-proposed/universe) [3.25.90-0ubuntu1 => 3.25.90+really3.12.14-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted empathy [source] (artful-proposed) [3.25.90+really3.12.14-0ubuntu1]
<rbasak> LocutusOfBorg: that's fine, but you should state those things in the bug if you don't want to be bounced around
<rbasak> LocutusOfBorg: adding a dependency in the general case could cause a regression if a user has something installed that conflicts with the new dependency
<rbasak> LocutusOfBorg: so that should be called out and considered in the SRU bug please (IMHO)
<xnox> rbasak, i think it is critical to ship mariadb, in a working state.
<xnox> rbasak, having broken pcre3 sounds scary
<rbasak> xnox: seems to me that it's broken by design assumptions (undefined C in the face of an optimizing compiler).
<rbasak> That is impacting ppc64el and s390x in a way that tests pick up
<rbasak> The current failure could just be an unrelated bug of course
<rbasak> AFAICT, MariaDB itself is fine. It's pcre3 that's broken.
<xnox> rbasak, smells like stuff we should be escalating to IBM toolchain team, as they have a promise to support us with -O3 on ppc64el at least.
<rbasak> (though that isn't certain with this current bug)
<xnox> rbasak, which one is the pcre3 bug?
<rbasak> xnox: AFAIK, the only thing left is the mariadb-10.1 dep8 failure. Start from there.
<rbasak> xnox: https://bugs.exim.org/show_bug.cgi?id=2173 describes how pcre3 is fundamentally broken.
<rbasak> Though perhaps it's just that function.
<rbasak> It's not really clear
<ubot5> bugs.exim.org bug 2173 in Code "stack frame size detection is broken" [Bug,Resolved: wontfix]
<rbasak> Because the current mariadb-10.1 dep8 failure is still pointing at pcre3.
<jbicha> btw, mono also ftbfs on ppc64el and s390x https://launchpad.net/ubuntu/+source/mono/4.6.2.7+dfsg-1ubuntu2
<xnox> rbasak, based on that discussion it seems like "there is pcre edition that does not use that broken code any more" and that "mariadb uses old edition of pcre by default"
<rbasak> Correct
<xnox> rbasak, have we moved mariadb in ubuntu to use "this new magical pcre edition" ?
<rbasak> But MariaDB's stable branch policy can't switch implementation
<xnox> rbasak, or is the magical pcre still in universe?
<xnox> rbasak, and we still want to ship those branches of mariadb, right?
<rbasak> Correct
<xnox> rbasak, no dice at distro-patching those stable brances in ubuntu to use new pcre3, right? (because pain / validation / regression tests / unicorns / lollipops / etc )
<rbasak> I don't see the 10.xx series packaged. Presumably it is?
<rbasak> xnox: this came up about two days ago. Nothing has been tried.
<jbicha> the new version of pcre3 is pcre2 LP: #1636666
<ubot5> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Incomplete] https://launchpad.net/bugs/1636666
<rbasak> MariaDB is in universe, so I'm not sure how much effort I should spend patching it
<rbasak> https://jira.mariadb.org/browse/MDEV-14024 is their bug
<rbasak> Doesn't look like they've done it yet
<rbasak> xnox: the rdepends list of libpcre3 is very long.
<rbasak> To fix this properly, you're basically asking for a transition.
<rbasak> Though admittedly the number of rdepends that use the broken function may be smaller.
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2.html
<rbasak> I think it's easier to fix the broken function. Which we did, but perhaps it didn't work.
<rbasak> Perhaps the remaining mariadb failure is something unrelated.
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.28.3+17.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.28.3]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.28.3+17.04]
<apw> ^ problem with breaks being fixed ...
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.28.3~14.04]
<xnox> rbasak, i should be able to escalate https://jira.mariadb.org/browse/MDEV-13412 to IBM
-queuebot:#ubuntu-release- Unapproved: libvirt (artful-proposed/main) [3.6.0-1ubuntu4 => 3.6.0-1ubuntu5] (ubuntu-server, virt)
<rbasak> Ah. Odd that we're seeing that on s390x but not on ppc64el.
<xnox> rbasak, difference w.r.t. debian could be higher compiler/abi versions we demand power8 and zEC12, vs power7 and z196
<xnox> and there is a comment stating that we do see this on s390x and ppc64el in artful
<sil2100> cyphermox: hey! Do you know if we're waiting for some additional changes for ubiquity? Since I'd like trunk to be released as I'd like the screenreader fix in the RC already
<sil2100> cyphermox: (asking you since you were releasing the last few versions)
<cyphermox> yes, need to do a translation import
<cyphermox> I can do that now
<sil2100> cyphermox: thanks o/
<infinity> rbasak: Re: mariadb versus pcre3, there's no harm in us shipping our pcre3 with the 1-line attribute change, I'd say.
<infinity> rbasak: If that's actually the bug you're seeing.
<rbasak> infinity: yeah I uploaded that already
<infinity> rbasak: Ahh, and two followups for build failure I see. :)
<rbasak> Right. But mariadb-10.1 dep8 still fails with a different error
<rbasak> Which I think xnox has identified as https://jira.mariadb.org/browse/MDEV-13412
<rbasak> I don't think it's certain whether that's mariadb-10.1 or pcre3
<infinity> If it's stack frame size detection, it's PCRE, but also, have you tested WITH THE NEW PCRE? :P
<infinity> (history says no)
<rbasak> Yeah but that doesn't stop the old one that everything links to being broken!
<infinity> ?
<rbasak> mariadb-10.1's test suite is exposing a bug in src:pcre3
<rbasak> Or at least, it might be.
<infinity> A bug that, for most people, doesn't matter at all.
<infinity> But yes, if you want to make mariadb explicitly depend on that version of libpcre3, you should do so.
<rbasak> Or, it's a latent bug in other things that will crash now.
<infinity> Personally, I don't much think partial upgrades are a deep concern here, and we should just test the two together and if that passes, call it a win.
<LocutusOfBorg> honestly rbasak that fuse is needed to umount partitions, I prefer people to remove borgbackup rather having one that doesn't do the umount correctly
<LocutusOfBorg> I'm talking about a backup tool, better safe than sorry
<LocutusOfBorg> so, if people complains about the new dependency, I'll answer them why they need it
<LocutusOfBorg> nobody complained in the last two years in Debian when we added it
<rbasak> infinity: AFAICT, the two current things still don't work together
<infinity> rbasak: Where's the evidence of that?
<infinity> rbasak: I see no autopkgtest results for that combination.
<rbasak> infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/m/mariadb-10.1/20171011_113411_fc9de@/log.gz says 2:8.39-5ubuntu3
<rbasak> for pcre3
<rbasak> But as I say, this one may not be stack frame size detection
<rbasak> It's not obvious to me.
<infinity> It could also be that mariadb needs rebuilding against the new libpcre3.  Automatic inlining is a disease that can spread.
<rbasak> I didn't think of that, thanks.
<infinity> That pcre patch also looks a bit weird to me.
<infinity> Sort of expecting an #else/#endif around the second declaration.
<infinity> But if it works... *shrug*
<rbasak> I did wonder, but assumed C allows it - as one is a declaration and one a definiton.
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (artful-proposed/multiverse) [27.0.0.130ubuntu1 => 27.0.0.159ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (artful-proposed) [27.0.0.159ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.472 => 2.473] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.473]
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12 => 234-2ubuntu13] (core)
-queuebot:#ubuntu-release- Unapproved: casper (artful-proposed/main) [1.384 => 1.385] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (artful-proposed) [1.385]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20171010.1-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-orca [source] (artful-proposed) [3.26.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie-preferences [source] (artful-proposed) [0.19]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (artful-proposed) [1.8.4-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted yelp [source] (artful-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20171010.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20171010.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.27.6+17.10 => 2.28.4+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.6 => 2.28.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.6~14.04 => 2.28.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.6+17.04 => 2.28.4+17.04] (desktop-core, ubuntu-server)
<jbicha> please reject totem/artful, it needs a bit more work
<sil2100> ACK
-queuebot:#ubuntu-release- Unapproved: rejected totem [source] (artful-proposed) [3.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (artful-proposed) [3.6.0-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: ubiquity (artful-proposed/main) [17.10.8 => 17.10.9] (core)
<sil2100> cyphermox: thanks for ubiquity!
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (artful-proposed) [17.10.9]
<tdaitx> slangasek, gnupg2 failed on the rebuild because home is set to /sbuild-nonexistent (artful build had HOME=/home/build), what caused that change?
<tdaitx> the gnups2 build does use the home dir for tests... maybe we need to force tests to run somewhere else?
<slangasek> tdaitx: that's probably an infrastructure change; it's valid for HOME in a package build to point to something nonexistent, and *invalid* for a package build to write to $HOME as specified in the environment
 * sil2100 bumped the ubuntu-fan force-badtest hint as the tests are still failing
<infinity> tdaitx: HOME (or GNUPG_HOME, or whatever) should be set in the testsuite, ideally, or debian/rules if an upstream fix isn't easy.  Pooping all over the build user's $HOME is wrong (and why newer sbuild unsets it)
<infinity> tdaitx: Something like 'export HOME=$(shell mktemp -d --tmpdir=/tmp)' would likely work.  Or less globally, set TEST_HOME and pass HOME=$(TEST_HOME) just for the testsuite.
<infinity> (And rm -rf TEST_HOME in the clean target, if you don't want to be a jerk)
-queuebot:#ubuntu-release- Unapproved: maas (artful-proposed/main) [2.3.0~beta1-6301-gca25180-0ubuntu1 => 2.3.0~beta2-6327-gdd05aa2-0ubuntu1] (ubuntu-server)
<Saviq> Laney: FYI: Mir is good to go, sorry for the delay
<Saviq> infinity: hey, would you have time to help us process bug #1722292? packages are to be copied from https://launchpad.net/~ci-train-ppa-service/+archive/2988/+packages and there's two removals to get through (see Laney's comment on the bug)
<ubot5> bug 1722292 in mir (Ubuntu) "[FFe] Mir 0.28 release" [High,Confirmed] https://launchpad.net/bugs/1722292
<Saviq> slangasek: hey, would you have time to help us process bug #1722292? packages are to be copied from https://launchpad.net/~ci-train-ppa-service/+archive/2988/+packages and there's two removals to get through (see Laney's comment on the bug)
<ubot5> bug 1722292 in mir (Ubuntu) "[FFe] Mir 0.28 release" [High,Confirmed] https://launchpad.net/bugs/1722292
<slangasek> Saviq: I'm afraid I don't, I'm at product roadmap sprint and contended :/
<Laney> Saviq: thx, hopefully someone can help you out
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu2 => 2.20.7-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: horizon (artful-proposed/main) [3:12.0.0-0ubuntu2 => 3:12.0.0-0ubuntu2.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.3-0ubuntu3 => 3:11.0.3-0ubuntu3.1] (openstack, ubuntu-server)
<cjwatson> tdaitx: if you're connecting the dots, this is indeed an infrastructure change, announced in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-September/001225.html - I agree that it's a package bug though
<tdaitx> cjwatson, thanks for the pointer, I am glad we can now catch this kind of problems
<tdaitx> shame we didn't catch this before, a merge would have solved it, too late for it now
-queuebot:#ubuntu-release- Unapproved: open-iscsi (artful-proposed/main) [2.0.874-4ubuntu2 => 2.0.874-4ubuntu3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.473 => 2.474] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.474]
-queuebot:#ubuntu-release- Unapproved: gnome-builder (artful-proposed/universe) [3.26.0-1ubuntu2 => 3.26.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: totem (artful-proposed/main) [3.25.90.1-0ubuntu3 => 3.26.0-0ubuntu1] (ubuntu-desktop)
<rbalint> could someone please let golang-github-opencontainers-selinux in to artful?
#ubuntu-release 2017-10-12
-queuebot:#ubuntu-release- Unapproved: nplan (artful-proposed/main) [0.29 => 0.30] (core)
-queuebot:#ubuntu-release- Unapproved: glibc (artful-proposed/main) [2.26-0ubuntu1 => 2.26-0ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (artful-proposed) [2.20.7-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (artful-proposed) [3:12.0.0-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted totem [source] (artful-proposed) [3.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (artful-proposed) [3.26.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (artful-proposed) [2.3.0~beta2-6327-gdd05aa2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (artful-proposed) [2.26-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (artful-proposed) [0.30]
-queuebot:#ubuntu-release- Unapproved: libaal (artful-proposed/main) [1.0.6-3ubuntu1 => 1.0.6-4] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: json-c (artful-proposed/main) [0.12.1-1.1 => 0.12.1-1.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.474 => 2.475] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.475]
-queuebot:#ubuntu-release- Unapproved: qemu (artful-proposed/main) [1:2.10+dfsg-0ubuntu1 => 1:2.10+dfsg-0ubuntu2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (artful-proposed/main) [2.56.1-1 => 2.60.1-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted json-c [sync] (artful-proposed) [0.12.1-1.2]
-queuebot:#ubuntu-release- Unapproved: accepted libaal [sync] (artful-proposed) [1.0.6-4]
<mwhudson> apw: hmm?
 * mwhudson is not here
<apw> mwhudson, i was commenting that the docker.io package seems to be in a lot of a mess, not working wise
-queuebot:#ubuntu-release- Unapproved: sssd (artful-proposed/main) [1.15.2-1ubuntu3 => 1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<tjaalton> ^ is a bugfix release, and fixes a CVE released yesterday
<tjaalton> does add a new package too (sssd-kcm)
<sil2100> A bit lateish!
<tjaalton> a bit
<tjaalton> but saves an sru (1.15.3)
<tjaalton> 1.15.3 has been in debian since late july though
<Saviq> sil2100: good morning, would you have time to help us process bug #1722292? packages are to be copied from https://launchpad.net/~ci-train-ppa-service/+archive/2988/+packages and there's two removals to get through (see Laney's comment on the bug)
<ubot5> bug 1722292 in mir (Ubuntu) "[FFe] Mir 0.28 release" [High,Confirmed] https://launchpad.net/bugs/1722292
<sil2100> Saviq: hey! I can certainly sync the packages from the silo to the archive, but for the AA bits you'll have to find someone else - I'm not trained yet to do NEW/removal reviews
<Saviq> sil2100: ack, congrats on your membership, btw :)
<apw> sil2100, i can have a look at that
<Saviq> please do whatever you can, and I'll bug others next
<Saviq> apw: thanks
<sil2100> apw: should I still copy the packages over to the archive, or you want to sync those?
<sil2100> (for ease of review, here's the content diff: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2988/2017-10-11_15:07:13/artful_mir_content.diff )
<apw> sil2100, i may as well do it as i will want to review it before i hit the publish button
-queuebot:#ubuntu-release- Unapproved: gnupg2 (artful-proposed/main) [2.1.15-1ubuntu7 => 2.1.15-1ubuntu8] (core)
<xnox> slangasek, could you please create artful-updates milestone?
-queuebot:#ubuntu-release- Unapproved: libcap2 (artful-proposed/main) [1:2.25-1 => 1:2.25-1.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: parted (artful-proposed/main) [3.2-17ubuntu1 => 3.2-18] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: etl (artful-proposed/universe) [0.04.19-1 => 0.04.19-1.1] (no packageset) (sync)
<sil2100> xnox: I can try doing that
-queuebot:#ubuntu-release- Unapproved: accepted etl [sync] (artful-proposed) [0.04.19-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (artful-proposed) [2.1.15-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted parted [sync] (artful-proposed) [3.2-18]
-queuebot:#ubuntu-release- Unapproved: accepted libcap2 [sync] (artful-proposed) [1:2.25-1.1]
<xnox> sil2100, if you have powers, yes please =)
<sil2100> I should have the power hm, but I don't see the button for this
<apw> Saviq, this new mir upload carries libmiral2, which used to be carried by miral, why does it not need a breaks/replaces
<apw> Saviq, for upgraders
<LocutusOfBorg> somebody please update virtualbox hint :)
<apw> LocutusOfBorg, reviewed and updated
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20171003-0ubuntu1 => 16.10+17.10.20171012.1-0ubuntu1] (core) (sync)
<didrocks> apw: sil2100: those are some theme fixes from Trevinho FYI. They don't really impact any screenshot at the core (and anyway, we don't have documentation on desktop before 18.04 from what Gunnahr told) ^
<sil2100> didrocks: let me take a look
<sil2100> didrocks: ok, so you confirmed that this doesn't impact the docs then
<didrocks> sil2100: indeed, it doesn't
<didrocks> and I made a lot of feedback for Trevinho when reviewing during the last week, ask him :p
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (artful-proposed) [16.10+17.10.20171012.1-0ubuntu1]
<didrocks> thanks sil2100 :)
<infinity> sil2100: You don't have the powers to do that, no.
<infinity> xnox: Milestone created.
<sil2100> infinity: oh, thought ubuntu-release is enough as they're the drivers - thanks!
<infinity> apw: What would it breaks/replaces?  Itself?
<Saviq> apw: it's a straight upgrade
<Saviq> just the source package changed
<infinity> Saviq: Yeah, that's what I was getting at above. ;)
<Saviq> yup
<infinity> Saviq: And you caught the thing I would have yelled at you about (the version going backwards), so yay.
<Saviq> note the binary version produced for libmiral2 is extracted from CMakeLists.txt, so it will be different to the source package version (thanks xnox!)
<Saviq> apw: â
<infinity> It is, of course, monumentally difficult to "review" the merging of two source packages.
<xnox> care was taken in generating binary packages version numbers to be incremental, unique, and ahead of the other source package which is being taken over.
-queuebot:#ubuntu-release- Unapproved: starjava-ttools (artful-proposed/universe) [3.1-2 => 3.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted starjava-ttools [sync] (artful-proposed) [3.1.1-2]
<apw> infinity, a good point, derp ok
-queuebot:#ubuntu-release- Unapproved: eag-healpix (artful-proposed/universe) [2017.02.26-2 => 2017.09.06-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eag-healpix [sync] (artful-proposed) [2017.09.06-1]
-queuebot:#ubuntu-release- Unapproved: r-base (artful-proposed/universe) [3.4.2-1 => 3.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-base [source] (artful-proposed) [3.4.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.28.4+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.28.4+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.28.4]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.28.4~14.04]
-queuebot:#ubuntu-release- New binary: snapd [amd64] (trusty-proposed/universe) [2.28.4~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd [i386] (trusty-proposed/universe) [2.28.4~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd [armhf] (trusty-proposed/universe) [2.28.4~14.04] (no packageset)
-queuebot:#ubuntu-release- New: accepted snapd [amd64] (trusty-proposed) [2.28.4~14.04]
-queuebot:#ubuntu-release- New: accepted snapd [i386] (trusty-proposed) [2.28.4~14.04]
-queuebot:#ubuntu-release- New: accepted snapd [armhf] (trusty-proposed) [2.28.4~14.04]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.8 => 0.103ubuntu4.9] (core)
<popey> Hello! Is it expected that a clean 16.04 install will offer an upgrade to 17.04? (I thought we only offered LTS to LTS by default)
<popey> (I just did a clean 16.04 install and mid way through a dist upgrade I got an "Ubuntu 17.04 Upgrade Available" popup)
<popey> (this was a 16.04 LTS install, not a 16.04.X install)
<ddstreet> sil2100 if you have a chance, can you approve the initramfs-tools upload for trusty, https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=initramfs-tools
<seb128> popey, if you go in software-properties, 3rd tab, what choice is selected in the bottom combo?
<popey> will check in a bit. its mid-dist-upgrade so lots of things are broken (can't take screenshots, dialogs are empty)
<popey> seb128: it says "For any new version" which I found surprising!
<seb128> yeah
<seb128> you are sure you didn't tweak that setting?
<popey> bear in mind this was an original 16.04 iso, not a point release I installed from, if that matters
<popey> it was a clean install an hour ago
<popey> literally the only thing i have done is login and dist-upgrade
<popey> its not even a very nice dialog. It's not the one that lists release notes and stuff, just a box with 3 buttons
<popey> https://imgur.com/a/KCuui
<seb128> popey, can you xprop it?
<seb128> that looks a bit like a fallback notification for notifications with actions
<popey> sadly not, had to reboot
<popey> will xprop if it pops up again
<seb128> popey, on a 16.04.3 livecd the parameter is "check for LTS only", but that's .3 and not the install result
<seb128> popey, in any case it's probably one of bdmurray when he gets up
-queuebot:#ubuntu-release- Unapproved: openvswitch (artful-proposed/main) [2.8.0-0ubuntu1 => 2.8.1-0ubuntu1] (ubuntu-server)
<seb128> but it does sound weird indeed
<popey> kk
<seb128> the setting should be LTS only
<popey> agreed
<jamespage> hi release team - the openvswitch upload I just made ^^ includes a new point release and a fix/skip for the ftbfs on s390x
<jamespage> I've tested the update with openstack per normal SRU update guidelines
<seb128> popey, https://protechgurus.com/upgrade-ubuntu-16-04-ubuntu-16-10-ubuntu-17-04/ suggests that the UI you got in the normal one, you should get the proper upgrader when clicking "yes, upgrade now"
<seb128> popey, so your issue is that the setting is on the wrong value
<popey> not sure how much of an issue this is 18 months later given we no longer offer 16.04 (non point) ISOs for download
-queuebot:#ubuntu-release- Unapproved: nspr (artful-proposed/main) [2:4.16-1ubuntu1 => 2:4.16-1ubuntu2] (core)
<LocutusOfBorg> [ubuntu/artful] llvm-toolchain-3.8 1:3.8.1-24ubuntu7 (Accepted) 13.39
<LocutusOfBorg> [proposed-migration] llvm-toolchain-3.8 1:3.8.1-24ubuntu7 stuck in artful-proposed for 17 days. 13.54
<LocutusOfBorg> so, I got the "stuck in artful-proposed" email 15 minutes after the package migration
<apw> mad
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (artful-proposed/universe) [1.3.6.7-5 => 1.3.7.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (artful-proposed) [1.3.7.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (artful-proposed/main) [3.26.0.1-0ubuntu1 => 3.26.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-getting-started-docs (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: sssd [ppc64el] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: sssd [s390x] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: sssd [i386] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: sssd [amd64] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: sssd [arm64] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: sssd [armhf] (artful-proposed/main) [1.15.3-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted sssd [amd64] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted sssd [armhf] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted sssd [ppc64el] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted sssd [arm64] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted sssd [s390x] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted sssd [i386] (artful-proposed) [1.15.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.475 => 2.476] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.476]
-queuebot:#ubuntu-release- Unapproved: netcfg (artful-proposed/main) [1.142ubuntu4 => 1.142ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (artful-proposed) [1.142ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.9]
-queuebot:#ubuntu-release- Unapproved: xinit (artful-proposed/main) [1.3.4-3ubuntu1 => 1.3.4-3ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: xorg (artful-proposed/main) [1:7.7+19ubuntu2 => 1:7.7+19ubuntu3] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-getting-started-docs [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nspr [source] (artful-proposed) [2:4.16-1ubuntu2]
<sil2100> jbicha: hey, you saw the software-properties ADT failures for gtk+3.0 ?
<sil2100> jbicha: looks like it's failing on amd64 and i386 only for this package
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (artful-proposed/main) [1:3.25.91-0ubuntu2 => 1:3.25.92-0ubuntu1] (ubuntu-desktop)
<bdmurray> popey: what does /var/lib/installer/media-info say?
<jbicha> sil2100: I saw but I probably won't be able to work on software-properties today
<popey> bdmurray: that doesn't exist
<popey> oh, you mean /var/log ;)
<popey> bdmurray: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307)
<bdmurray> popey: so that's nots the final image is it?
<popey> huh, wow, this is an old usb stick then!
<popey> sorry to bother you
<bdmurray> popey: no problem
<sil2100> Damn, we'd like to get that migrating somehow
<sil2100> Let me try looking at that
<jbicha> sil2100: if you're still talking about software-properties, we could ask bdmurray if he has time today since he's been doing recent uploads for it
<Laney> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1721828
<ubot5> Ubuntu bug 1721828 in gtk+3.0 (Ubuntu Artful) "gtk 3.22.24 breaks software-properties tests (Gdk-Message: setup.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.)" [High,Triaged]
<sil2100> Laney: oh, so it's on your plate then!
<sil2100> Thanks
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu3 => 3.26.1-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-screenshot (artful-proposed/main) [3.25.0-0ubuntu1 => 3.25.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: zfcpdump-kernel (artful-proposed/universe) [4.9-0ubuntu2 => 4.13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zfcpdump-kernel [source] (artful-proposed) [4.13-0ubuntu1]
<sil2100> willcooke: just reminding, be sure to keep the artful release notes up to date with latest desktop goodies
<xnox> sil2100, apw: please reject systemd from artful queue, i believe i want to redo it.
<sil2100> xnox: ACK
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (artful-proposed) [234-2ubuntu13]
<sil2100> jbicha: as for gnome-calculator - this doesn't change/add/remove any translatable strings, right?
<jbicha> sil2100: correct
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu6 => 2.02~beta3-4ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (artful-proposed) [1:3.25.92-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-screenshot [source] (artful-proposed) [3.25.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: debian-installer-utils (artful-proposed/main) [1.113ubuntu1 => 1.113ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer-utils [source] (artful-proposed) [1.113ubuntu2]
<sil2100> cyphermox: hey, could you take a look at LP: #1713696 ? Seems like people are seeing this issue on our images
<ubot5> Launchpad bug 1713696 in ubiquity (Ubuntu) "No "Remove media" prompt after installation finished" [Medium,Confirmed] https://launchpad.net/bugs/1713696
<bdmurray> balloons: Can you add some verification details to bug 1699354?
<ubot5> bug 1699354 in juju-mongodb3.2 (Ubuntu Zesty) "upgrade juju-mongodb3.2 to 3.2.15" [Undecided,Fix committed] https://launchpad.net/bugs/1699354
<balloons> bdmurray, sure
<jbicha> sil2100: that may be a dupe of LP: #966480, it's been an issue for a looong time
<ubot5> Launchpad bug 966480 in plymouth (Ubuntu Precise) "The prompt asking for media removal is not shown at the end of the installation" [High,Triaged] https://launchpad.net/bugs/966480
<cyphermox> sil2100: sure. I'll finish lunch and then take care of it :)
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (zesty-proposed) [0.1.0~bzr532-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr532-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [source] (zesty-proposed) [2.3.1-2.1ubuntu2~17.04.1]
<sil2100> jbicha: strangely, for final beta I remember seeing the prompt when testing ubuntustudio
<sil2100> But yeah
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (xenial-proposed) [1.108ubuntu15.4]
<bdmurray> xnox: your livecd-rootfs upload in the Xenial SRU queue has no bug number?
<xnox> bdmurray, it is a fix up or a regression introduced in the previous entry
<xnox> bdmurray, i did build it with correct -v
<xnox> previous entry was still in unapproved when we noticed a bug
<slangasek> xnox: if it was never accepted into -proposed, you are allowed to recycle version numbers, fwiw
<bdmurray> Yeah, I think that would have been cleaner.
<infinity> slangasek: It's totally "allowed" to reuse rejected versions, but in a world where we'd like to move to mechanisms like "build from tags" before the UNIX epoch, it might be worth reconsidering best practices.  Moving a published tag is a big VCS no-no.
<infinity> (As such, I have no issues with an upload having two or three versions in .changes)
<dannf> infinity, slangasek : this *should* be ready to go - mind giving it a review (and possible merge) when you get a minute? https://code.launchpad.net/~dannf/debian-cd/lp1692876/+merge/331671
<infinity> dannf: I think I need to catch up on all of Thomas's input, but will have a look.
<dannf> infinity: thx
<infinity> dannf: Didn't the original MP uncomment some bits that I'd commented?  Is that no longer necessary after the back-and-forth?
<infinity> dannf: The redundant grub bit.
<dannf> infinity: the original was just a revert of r1945
<infinity> dannf: Indeed.  So that bit was indeed redundant?
<dannf> infinity: appears to be, yes. i'm not sure why we'd want that
<infinity> dannf: I'm skeptical about this in general, even after reading the comment history.  Do we have hardware we can actually test this on once we spin up a test?
<dannf> infinity: yes. i've tested the iso i could build on hardware. though, both usb and cd in that case are emulated from the bmc, so i didn't actually burn anything
<infinity> (Not skeptical due to any concerns of competence, but just because xorriso's CLI is about as intuitive as eating a hamburger with a whisk)
<infinity> dannf: Kay.  I don't particularly care if it's real hardware or BMC, more that it's a platform that exposes the previous issue.
<dannf> i wasn't able to figure out how to build a real ubuntu-server iso though, so i'll do that once there's a daily (or a pre-daily test or whatever)
<dannf> infinity: it is - same system the reporter was using
<dannf> s/system/system model
<infinity> dannf: Also, would be nice to keep the options from debian-cd and d-i mini.iso in sync (and the latter is a much easier guinea pig for rapid iteration and testing)
<infinity> Though, d-i has the advantage of building with a more current xorriso, so still not a definitive test.
<dannf> infinity: *nod* - i can do an MP for d-i as well, but yeah - i'll probably do point el torito at the appended partition, so will be different
<infinity> jbicha: libsoup2.4 2.56.1 -> 2.60 seems like an ambitious sync right before final freeze.
<infinity> jbicha: Do you have a (good) rationale for it?
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (artful-proposed) [1:2.10+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xinit [source] (artful-proposed) [1.3.4-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg [source] (artful-proposed) [1:7.7+19ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (artful-proposed) [2.02~beta3-4ubuntu7]
<infinity> jbicha: Alright, I went through the diff, and it's almost entirely bugfixes (and a violent removal of the msvcc build system), so maaaybe it's okay.  Still a large delta to land.
<jbicha> infinity: there's some information in LP: #1717216
<ubot5> Launchpad bug 1717216 in libsoup2.4 (Ubuntu) "FFe: Sync libsoup2.4 2.60.0-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1717216
<infinity> jbicha: I wish the 2.60 sync had happened back when that bug was debated.  The .1 bump would have been a no-brainer.
<infinity> But... Here we go.
-queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [sync] (artful-proposed) [2.60.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (artful-proposed) [2.0.874-4ubuntu3]
<infinity> jamespage: I assume that SKIP_TEST is Really Poorly Named in openvswitch, and it's actually RUN_TEST?
 * sil2100 was reluctant to accept too many things so late
<infinity> jamespage: And how much investigation went into that s390x test disabling to determine it was an okay thing to do?
<infinity> jamespage: ie, is it definitely an "our infra is weird and I can't reproduce it on another s390x host" bug, or a "this only happens in lxd, meh" bug, or could it be an "s390x is our only big-endian arch and someone can't do math, leaving a dangling refcount" bug?
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7 => 2.02~beta3-4ubuntu7] (core)
<jbicha> infinity: are you sprinting this week?
<infinity> jbicha: Virtually, but not physically.
<jbicha> no ubuflu for you then? ;)
<infinity> jbicha: I'm sure I can go find a nerd to kiss to approximate the thrill.
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7 => 2.02~beta3-4ubuntu7] (core)
<infinity> tdaitx: Is there a grub2-signed upload coming to match that grub2, or should I bang one out?
<jbicha> wow, Ubuntu conferences have gotten more exciting since the last time I attended
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu7]
<jbicha> sometime I'd like to discuss what we want to do for LP: #1710318
<ubot5> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
<infinity> jbicha: I'd like webkit1 to die in a fire.  I'm guessing there wasn't as much movement as we'd hoped while I was indisposed?
<jbicha> webkit1 is nearly removed from Debian Testing
<jbicha> I believe slangasek still uses gnucash so maybe we don't want to remove it from 17.10 now?
<infinity> jbicha: Yeah, gnucash is used by many, AFAIK.
<jbicha> gnucash upstream aims to have at least a beta without webkit1 later this year
<infinity> jbicha: I'd consider fixing gnucash a hard requirement here.
<jbicha> so the question for 17.10 is whether we should remove some of the less-used stuff now
<infinity> jbicha: Also, as much as I despise wk1 (and many old versions of crap libraries that we ship multiples of, wk isn't alone), comitting to a 9mo release (or another 6mo on top of the last) isn't world-ending.  I think it's in all our best interest to punt it out before we carry it for 5 years in 18.04, though.
<jbicha> if we don't mind having gnucash temporarily removed from blushing bonobo, we could kill webkit1 as soon as 18.04 opens in my opinion
<jbicha> that ways devs and users for those apps should have plenty of warning and shouldn't be too surprised
<jbicha> there's a few on that bug that might be easy removals now: bibledit-gtk (duplicate of bibledit), blam, webkit-sharp
<jamespage> infinity: yes you are quite correct
<infinity> jbicha: I've been calling it Boris Bikes.
<infinity> I guess that should just be Boris Bike, as the animal is never plural.
<infinity> jamespage: Assuming that response was about the badly-named variable.  Didn't really cover the next bits. :)
<jbicha> not so sure that's an animalâ¦
<jamespage> infinity: yes - you mentioned LXD ?
<infinity> jamespage: Well, I mentioned all sorts of things.  It was a multiple choice question.
<jamespage> did we just start doing something different with s390x for archive builds
<infinity> jamespage: I guess what I want to know is if you *know* this is only a build-time issue.
<jamespage> infinity: I don't
<jamespage> leave it with me
<infinity> jamespage: Kay, I'll reject it for now.  We can resurrect from the rejected queue if you come back with interesting info.
<jamespage> okies
-queuebot:#ubuntu-release- Unapproved: rejected openvswitch [source] (artful-proposed) [2.8.1-0ubuntu1]
<tdaitx> infinity, cyphermox is working on grub2-signed right now, I was leaving if for EOD (failed to realize it was actually blocking grub2)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (artful-proposed/main) [1.84 => 1.85] (core)
<cyphermox> infinity: ^ your grub2-signed, sir
<infinity> cyphermox: Ta.
-queuebot:#ubuntu-release- Unapproved: kdenlive (artful-proposed/universe) [4:17.08.1-0ubuntu1 => 4:17.08.2-0ubuntu1] (kubuntu)
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.14]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.14]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.13 => 2.02~beta2-36ubuntu3.14] (core)
-queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.13.0-16.19 => 4.13.0-16.20] (core, kernel)
<LocutusOfBorg> please reject the kernel apw
<LocutusOfBorg> damn, I'm testing vbox, it got rejected twice in the ppa, not sure how I missed the target suite
<apw> LocutusOfBorg, ack
<LocutusOfBorg> sorry
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [17.1-17-g45d361cb-0ubuntu1~17.04.1]
<LocutusOfBorg> damn sorry
<LocutusOfBorg> at least can you look at the diff? it should be fixing vbox :)
<LocutusOfBorg> soooo at the end I'll probably ask you to merge it :p, but only after a deep test on my side
 * LocutusOfBorg goes back to sleep
-queuebot:#ubuntu-release- Unapproved: rejected linux [source] (artful-proposed) [4.13.0-16.20]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.13 => 2.02~beta2-36ubuntu3.14] (core)
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [17.1-18-gd4f70470-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (artful-proposed/main) [20101020ubuntu522 => 20101020ubuntu523] (core)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.1-17-g45d361cb-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (artful-proposed) [1.85]
<infinity> apw: A little trigger-happy on that d-i upload. :)
<apw> i figured it can sit in the queue
<infinity> Indeed it can.
<infinity> And it shall.
<apw> as i had prepped it
<apw> infinity, feel free to drop it into rejected if that is safer
-queuebot:#ubuntu-release- Unapproved: accepted kdenlive [source] (artful-proposed) [4:17.08.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-16.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-16.19]
<infinity> apw: Were you hammering refresh on the queue every 2s? :P
<apw> infinity, heh no, just lucky
<apw> you know how it is when you want to go to sleep, and you are waiting on something
<infinity> apw: Slipped it in about 5s before the cutoff for the publisher too.  You're having a good day.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.1-18-gd4f70470-0ubuntu1~16.04.1]
<apw> infinity, that will be the first time ever i got lucky with the publisher
<infinity> apw: She's fickle, but worth the effort.
<apw> :) what a though
<apw> t
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Zesty 17.04, Artful 17.10 Final Beta | Archive: final freeze | 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- Unapproved: accepted debian-installer [source] (artful-proposed) [20101020ubuntu523]
-queuebot:#ubuntu-release- New source: fscrypt (artful-proposed/primary) [0.2.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: docker.io (artful-proposed/universe) [1.13.1-0ubuntu5 => 1.13.1-0ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (artful-proposed) [1.13.1-0ubuntu6]
-queuebot:#ubuntu-release- Packageset: 6782 entries have been added or removed
#ubuntu-release 2017-10-13
-queuebot:#ubuntu-release- Unapproved: mythtv (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1 => 2:29.0+fixes.20171012.44dac01b21-manualbuildubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: profnet (artful-proposed/universe) [1.0.22-4build1 => 1.0.22-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted profnet [source] (artful-proposed) [1.0.22-4build2]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocgenerics (artful-proposed/universe) [0.22.0-1build1 => 0.22.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocgenerics [sync] (artful-proposed) [0.22.1-1]
-queuebot:#ubuntu-release- Unapproved: xorg-server (artful-proposed/main) [2:1.19.4-1ubuntu2 => 2:1.19.5-0ubuntu1] (desktop-core, xorg)
<tjaalton> ^ new xserver, one regression revert, 12 cve fixes and one other fix
-queuebot:#ubuntu-release- Unapproved: lintian (artful-proposed/main) [2.5.54 => 2.5.55] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocgenerics (artful-proposed/universe) [0.22.1-1 => 0.22.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocgenerics [source] (artful-proposed) [0.22.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libsdl2 (artful-proposed/universe) [2.0.6+dfsg1-2ubuntu2 => 2.0.6+dfsg1-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: r-bioc-s4vectors (artful-proposed/universe) [0.14.3-1ubuntu1 => 0.14.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-s4vectors [sync] (artful-proposed) [0.14.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (artful-proposed) [2.0.6+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected mythtv [source] (artful-proposed) [2:29.0+fixes.20171012.44dac01b21-manualbuildubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lintian [sync] (artful-proposed) [2.5.55]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (artful-proposed) [2:1.19.5-0ubuntu1]
<xnox> infinity, there will be d-i rebuild to pick up debian-installer-utils among other things?
<xnox> and netcfg
<xnox> and i guess all the things.
<infinity> xnox: There was a d-i 11 hours ago, was that too soon?
<xnox> i think so, let me double check
<infinity> xnox: Certainly looks newer than both d-i-utils and netcfg.
 * xnox was looking at release pocket, doh
<xnox> infinity, looks good the one in proposed =)
<infinity> \o/
<infinity> xnox: It'll meander out to release when Andy's happy with his kernel.
<apw> serendipidy
<infinity> (Which might be never, because is Andy really ever happy with the kernel?)
<apw> infinity, heh a point indeed.  this one is less terrible than average
<infinity> apw: Never go into sales.
<infinity> "Buy our product because it's 23% less crap than the competitors."
<apw> oh i think i would like sales people to be like that
<smb> sounds at least more honest that "we got shiny and flawless"
<apw> 23% less crap would be marvelous
<infinity> smb: I suspect that level of honesty would only work if universally applied.  When others focus on why they're better and you focus on why you're less bad, you just look negative.
<xnox> is this is where i was going wrong in my dating life?!
<infinity> xnox: We could probably make a list.
<xnox> *stack overflow* ?
<infinity> If you're asking stackoverflow for dating advice, that's your first mistake.
<smb> infinity, I find "less mad than <insert-scary-name>" rather positive
<infinity> smb: You've been hanging out with too many Brits. ;)
 * smb pleads guilty
<infinity> smb: But okay, <insert-scary-name> is an exception to the rule, I suppose.  This may be the one time in (my) political history, when I'd consider voting for someone because they're "not the other guy".
<apw> isn't less crazy than xnox some kind of invariant ?  :)
<infinity> smb: Usually, "not the other guy" is the most insulting platform/position you can put to your voters, customers, whatever.
<infinity> "I'm glad you're not the guy I dislike, but tell me why I should LIKE you, doofus."
<smb> Oh I wish they would start giving hints about that and not look like just a different colour of the shed
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu3 => 1:3.26.1-0ubuntu4] (ubuntu-desktop)
<seb128> ^ could that gnome-conctrol-center upload be considered for the iso? it fixes a quite visible theming regression in the settings that was created by another fix this week (and include as trivial fix that was pending as well)
<infinity> seb128: I'll consider it after LP graces me with a diff.
<seb128> infinity, thanks
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.1-0ubuntu4 => 3.26.1-0ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-h5netcdf (artful-proposed/universe) [0.4.1-0ubuntu1 => 0.4.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-h5netcdf [sync] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- Unapproved: wine (artful-proposed/universe) [2.0.2-1ubuntu1 => 2.0.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.1-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: dupload (artful-proposed/main) [2.9.0ubuntu2 => 2.9.1ubuntu1] (core)
<LocutusOfBorg> infinity, do you mind updating force-badtest udisks2/2.6.5-2ubuntu1/ppc64el to ubuntu2? thanks!
<LocutusOfBorg> oops s/infinity/ slangasek /g
<infinity> Only one of those people is awake.
<apw> (and it isn't infinity)
<LocutusOfBorg> I usually grep on hints repo for the person who "owns" the hint
-queuebot:#ubuntu-release- Unapproved: sane-backends (artful-proposed/main) [1.0.27-1~experimental2 => 1.0.27-1~experimental2ubuntu1] (desktop-core, ubuntu-server)
<LocutusOfBorg> and I forget to translate vorlon in the right correct nick :p
<LocutusOfBorg> apw, do you have a way to fix that ABI failure in my kernel ppa build? or alternatively, do you think we can get vbox merged and enabled again?
<apw> LocutusOfBorg, yes, you can either disble abi checks by adding ignore files in the right place
<infinity> LocutusOfBorg: Done.
<infinity> Easier to just not have a new changelog entry.
<LocutusOfBorg> infinity, <3 this will help glibc a little bit
<apw> LocutusOfBorg, or you can stop making a new top changelog entry and just modify the top one
<infinity> Disabling ABI checks is hard.
<LocutusOfBorg> seriously, not bumping changelog entry works? smart!
<infinity> LocutusOfBorg: Basically, the ABI checker will look at your ABI version, check if there's a previous one of the same ABI, and then trip.  If you just alter the top level entry (so there's only one -16.foo), then all is well.
<infinity> LocutusOfBorg: I mean, you want to change the version so it's not the same as the archive one, to avoid breaking your brain, but change it instead of adding a new one.
<LocutusOfBorg> oh ok,
<LocutusOfBorg> I would also make sure that the ubuntu/vbox is not built, but probably it doesn't matter
-queuebot:#ubuntu-release- Unapproved: libimobiledevice (artful-proposed/main) [1.2.0+dfsg-3.1ubuntu2 => 1.2.0+dfsg-3.1ubuntu3] (kubuntu, ubuntu-desktop)
<infinity> nacc: Around?
<infinity> rbasak: Or you?
<infinity> jamespage: Or maybe you? :P
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (artful-proposed) [1.0.27-1~experimental2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dupload [source] (artful-proposed) [2.9.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libimobiledevice [source] (artful-proposed) [1.2.0+dfsg-3.1ubuntu3]
<LocutusOfBorg> infinity, https://launchpadlibrarian.net/340734141/linux_4.13.0-16.20_4.13.0-16.21.diff.gz hopefully I did it right
<infinity> LocutusOfBorg: Should o.
<infinity> do.
<LocutusOfBorg> thanks
<rbasak> infinity: o/
-queuebot:#ubuntu-release- Unapproved: xchat-gnome (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu10 => 1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xchat-gnome [source] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
<infinity> rbasak: Hi!
<infinity> rbasak: You guys are the proud owners of the only outstanding node on component-mismatches.
<infinity> rbasak: And to make things more fun, it's a seeded package (tomcat8), so needs action pretty much now.
 * rbasak thought we were holding back on updating tomcat8
<infinity> Evidently not.
<rbasak> Looks like doko synced it
<infinity> rbasak: Anyhow, the simple fix would just be dmoting that recommends back to a suggests and revisiting for Boris Bike.
<infinity> rbasak: Or you can try to push an MIR in 12 hours, if you're feeling confident. :P
<rbasak> That's fine, but I remember being told to not sync it because it would break things
<LocutusOfBorg> Boris Bike... do we have a CODENAME?
<rbasak> So if it's indeed broken things, peraps the right thing to do is to gobackwards.
<rbasak> We have an infinityname
<rbasak> I'm sure we will have infinitely more :)
<infinity> LocutusOfBorg: If we had a codename, it wouldn't be a joke about London's public bike service.
<LocutusOfBorg> :)
<infinity> rbasak: I see no evidence anything's broken.
-queuebot:#ubuntu-release- New binary: xchat-gnome [i386] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
-queuebot:#ubuntu-release- New binary: xchat-gnome [s390x] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
<LocutusOfBorg> I found it after a googling
-queuebot:#ubuntu-release- New binary: xchat-gnome [ppc64el] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
<infinity> rbasak: Just a recommends that used to be a suggests.
<rbasak> 17:21 <nacc> cpaelzer: if we migrate tomcat8 to 8.5, dogtag-pki and tomcatjss will immediately break again
<rbasak> Perhaps that's now fixed
<infinity> Do either of them have tests?
<LocutusOfBorg> dogtag-pki ->   * control: Use tomcat8.0.
<LocutusOfBorg> I would say broken, tjaalton ^^
<infinity> https://launchpad.net/ubuntu/+source/tomcatjss/7.2.4-0ubuntu1 <-- Seems tomcat8 specific.
<infinity> Oh, we have tomcat8.0 as well as tomcat8.
<infinity> That's not confusing AT ALL.
<infinity> rbasak: I guess that was the compromise.
<infinity> rbasak: tomcat8.0 satisfies the two broken things.
<tjaalton> didn't doko sync tomcat8 already?
<infinity> tjaalton: Yes.
<infinity> tjaalton: rbasak was just trying to unwind if that was thought-out.
<infinity> And it seems like it was, given your tomcat8.0 uploads.
<tjaalton> the sync happened first
<tjaalton> then panic :)
<infinity> Heh.
<infinity> rbasak: Okay, so, the above has me convinced that panic and revert isn't necessary, just dealing with that recommends.
-queuebot:#ubuntu-release- New binary: xchat-gnome [amd64] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
<rbasak> tjaalton: what's the expecatation around upgrade path for users?
-queuebot:#ubuntu-release- New binary: xchat-gnome [arm64] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
<infinity> rbasak: And I think the right answer is probably "demote to Suggests and then push for an MIR in 18.04 as soon as it opens and revert back to Recommends".
<rbasak> tjaalton: you expect most of them to move to 8.5?
-queuebot:#ubuntu-release- New binary: xchat-gnome [armhf] (artful-proposed/universe) [1:0.30.0~git20141005.816798-0ubuntu11] (no packageset)
<tjaalton> rbasak: these are coinstallable, just that tomcatjss depends on 8.0
<tjaalton> it only ships a subset of tomcat
<tjaalton> we'll get rid of it in 18.04, with upstream support or without
<rbasak> OK thanks
 * rbasak wonders why he can't find a tomcat-native binary
<rbasak> Oh, a virtual package?
<rbasak> Seemingly not
<infinity> rbasak: tomcat-native is the source.
<infinity> rbasak: libtcnative-1 is the binary.
<rbasak> Oh
<infinity> tjaalton: Since you're around.  sssd-kcm.  Demote to universe, or should it be seeded somewhere?
<tjaalton> infinity: universe is fine
<infinity> Ta.
<tjaalton> no rdeps
<infinity> tjaalton: Indeed, if it had rdeps, component-mismatches wouldn't be telling me to demote. :)
<tjaalton> right
<rbasak> infinity: OK, all understood now. I'll do as you suggest.
<infinity> rbasak: As I Suggests?  Eh, eh?
<rbasak> :-)
<infinity> (It's 5am, pretend I'm funny)
<rbasak> libtcnative-1 is a Build-Depends-Indep as well as a Recommends. The former is fine with the new rules, right?
<infinity> rbasak: Yep.
<infinity> Also, weird.
<infinity> Do they know what "indep" means? :)
<infinity> (Does it really need libtcnative-1 to build the docs? :P)
<infinity> Oh, maybe they use it to accelerate building and testing the JARs, which are arch:all.
<infinity> Java is silly.
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu4 => 3.26.1-0ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (artful-proposed/main) [8.5.21-1 => 8.5.21-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<infinity> seb128: Did you mean to also revert the pinyin->sunpinyin change with that fix?
<seb128> no
<infinity> seb128: That change looked correct to me (ibus-sunpinyin is in the live seed, ibus-pinyin is not)
<seb128> thanks for pointing that
<seb128> must be a problem with the packaging vcs
<seb128> let me look
<infinity> seb128: Kay, rejecting.
<seb128> thanks
<infinity> seb128: Please debdiff against the archive before the next upload. :)
<seb128> right
-queuebot:#ubuntu-release- Unapproved: rejected gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu5]
<seb128> k, reuploaded without the revert
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.1-0ubuntu4 => 3.26.1-0ubuntu5] (ubuntu-desktop)
<infinity> seb128: Shiny.
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (artful-proposed) [8.5.21-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (artful-proposed) [2.0.2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: casper (artful-proposed/main) [1.385 => 1.386] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: graphicsmagick (artful-proposed/universe) [1.3.26-13 => 1.3.26-14] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: caribou (artful-proposed/main) [0.4.21-1 => 0.4.21-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (artful-proposed) [1.386]
-queuebot:#ubuntu-release- Unapproved: r-bioc-iranges (artful-proposed/universe) [2.10.2-1ubuntu2 => 2.10.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-iranges [sync] (artful-proposed) [2.10.5-1]
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (artful-proposed/main) [2:11.0.0~rc1-0ubuntu1 => 2:11.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-gpu-tools (artful-proposed/main) [1.20-1 => 1.20-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New source: llvm-toolchain-5.0 (xenial-proposed/primary) [1:5.0-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: numactl (xenial-proposed/main) [2.0.11-1ubuntu1 => 2.0.11-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.1-2 => 3.26.1-2ubuntu1] (desktop-extra, ubuntu-desktop)
<infinity> Laney: armhf autopkgtest seems to have gone kablooey.
<infinity> slangasek: ^-- If you remember how those bits work and get there first.
<slangasek> armhf autopkgtest stuff as a whole?
<infinity> slangasek: As in, no jobs being dispatched, no runners.
<infinity> 06:40 <apw> Stderr: ssh: connect to host 10.100.0.23 port 22: No route to host
<infinity> That sounds ungood.
<LocutusOfBorg> tjaalton, "CMAKE_EXTRA += -DLLVM_ENABLE_FUZZER=OFF" was it needed?
-queuebot:#ubuntu-release- Unapproved: accepted intel-gpu-tools [source] (artful-proposed) [1.20-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (artful-proposed) [2:11.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (artful-proposed) [3.26.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted caribou [sync] (artful-proposed) [0.4.21-2]
-queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (artful-proposed) [1.3.26-14]
<tjaalton> LocutusOfBorg: yep
<tjaalton> first batch of hwe pkgs for 16.04.4 is now on the queue (libdrm, wayland-protocols, llvm-5)
<LocutusOfBorg> why, the non-linux build has not
<tjaalton> huh?
<LocutusOfBorg> ifeq (,$(filter $(DEB_HOST_ARCH_OS),linux))
<LocutusOfBorg>         LIBFUZZER_ENABLE=no
<LocutusOfBorg> endif
<LocutusOfBorg> I woudl expected it to be the same, not with additional cmake flags
<LocutusOfBorg> so, the second line seems useless
<LocutusOfBorg> grep LLVM_ENABLE_FUZZER . -R returns nothing in the source tree...
<LocutusOfBorg> meh, doesn't hurt, but I want to know if non-linux builds are broken and needs it too
<tjaalton> ah, well copied what was on the old release
<tjaalton> 3.8/4.0 show no hits either
<tjaalton> must be magic then
<tjaalton> afk ->
-queuebot:#ubuntu-release- Unapproved: ubiquity (artful-proposed/main) [17.10.9 => 17.10.10] (core)
-queuebot:#ubuntu-release- Unapproved: xen (artful-proposed/main) [4.9.0-0ubuntu2 => 4.9.0-0ubuntu3] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<nacc> rbasak: yes, sorry, it's my todo, we can demote for aa
<nacc> (recommends -> suggests)
<rbasak> nacc: already done ;)
<rbasak> I left a MIR bug open
<nacc> rbasak: err, yes -- we probably want to MIR it for bb
<LocutusOfBorg> tjaalton, problem is that we build fuzzer, but all the code is inside ifeq (LIBFUZZER_ENABLE) so the check is not run and no segfault no install
<LocutusOfBorg> so again, that line is probably useless
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (artful-proposed) [17.10.10]
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (artful-proposed) [4.9.0-0ubuntu3]
<slangasek> Laney: I went looking at armhf runners; the arm64 instance had unaligned access in dmesg and defunct lxd runners.  I rebooted, and lxd appears not to have come back up automatically
<slangasek> Laney: I'm now rerunning the /var/tmp/setup scripts, is that what I should be doing?
<slangasek> (and I've so far only looked at one of the instances)
<slangasek> Laney: also, is it intended that we're using btrfs under lxd?
<tjaalton> LocutusOfBorg: what line?
<LocutusOfBorg> http://launchpadlibrarian.net/340751384/llvm-toolchain-5.0_1%3A5.0-3_1%3A5.0-3~ubuntu16.04.1.diff.gz
<LocutusOfBorg> tjaalton, CMAKE_EXTRA += -DLLVM_ENABLE_FUZZER=OFF
<LocutusOfBorg> that line
<tjaalton> ok, why was it put there in the first place then.. I grepped through several releases and found no hits
<tjaalton> anyway, I can drop it
-queuebot:#ubuntu-release- Unapproved: r-cran-filehash (artful-proposed/universe) [2.3-1ubuntu2 => 2.4-1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-filehash [sync] (artful-proposed) [2.4-1-2]
-queuebot:#ubuntu-release- Unapproved: mdadm (zesty-proposed/main) [3.4-4 => 3.4-4ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: lxd (artful-proposed/main) [2.18-0ubuntu4 => 2.18-0ubuntu5] (edubuntu, ubuntu-server)
<stgraber> ^ pretty small diff fixing a bunch of issues for people upgrading to LXC 2.1 (network patch) and those using a dir storage pool using a non-standard location (might affect juju)
-queuebot:#ubuntu-release- Unapproved: dell-recovery (artful-proposed/universe) [1.52 => 1.53] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dell-recovery [source] (artful-proposed) [1.53]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (zesty-proposed/main) [1:17.04.9 => 1:17.04.10] (core)
<andreas> infinity: hi, after some discussion, looks like they have settled on a final new alias for the "ubuntu-advantage" script in the ubuntu-advantage-tools package. If there is still time for artful, the bug has been updated: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1721272
<ubot5> Ubuntu bug 1721272 in ubuntu-advantage-tools (Ubuntu) "[FFe] Create 'ua' symlink pointing at 'ubuntu-advantage'" [High,New]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.22 => 1:16.04.23] (core)
-queuebot:#ubuntu-release- New: accepted xchat-gnome [amd64] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- New: accepted xchat-gnome [armhf] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- New: accepted xchat-gnome [ppc64el] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- New: accepted xchat-gnome [arm64] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- New: accepted xchat-gnome [s390x] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- New: accepted xchat-gnome [i386] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu11]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (artful-proposed/main) [0.125ubuntu11 => 0.125ubuntu12] (core)
<apw> ^ this is a adding a boot critical device to the initramfs
-queuebot:#ubuntu-release- Unapproved: gnome-shell (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu3] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.28.4~14.04 => 2.28.5~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.28.4+17.10 => 2.28.5+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.28.4+17.04 => 2.28.5+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.28.4 => 2.28.5] (desktop-core, ubuntu-server)
<valorie> any guesses as to when the RC will be spun? the list has nothing new
<jbicha> valorie: I believe we're waiting for several packages to migrate first like ubiquity and the langpacks
<jbicha> https://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html
#ubuntu-release 2017-10-14
-queuebot:#ubuntu-release- Unapproved: evince (zesty-proposed/main) [3.24.0-0ubuntu1.1 => 3.24.0-0ubuntu1.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted evince [source] (xenial-proposed) [3.18.2-1ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: accepted evince [source] (zesty-proposed) [3.24.0-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (artful-proposed) [3.26.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (artful-proposed) [2.18-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (artful-proposed) [0.125ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.28.5+17.10]
<valorie> thanks, jbicha!
-queuebot:#ubuntu-release- Unapproved: gnome-gmail (artful-proposed/universe) [2.5-1ubuntu1 => 2.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-gmail [sync] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- Unapproved: taglib (artful-proposed/main) [1.11.1+dfsg.1-0.1 => 1.11.1+dfsg.1-0.2] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted taglib [sync] (artful-proposed) [1.11.1+dfsg.1-0.2]
-queuebot:#ubuntu-release- Unapproved: starjava-util (artful-proposed/universe) [1.0+2017.03.17-1 => 1.0+2017.09.28-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted starjava-util [sync] (artful-proposed) [1.0+2017.09.28-1]
<tjaalton> LocutusOfBorg: turns out llvm-5 backport doesn't build on s390x
-queuebot:#ubuntu-release- New: rejected llvm-toolchain-5.0 [source] (xenial-proposed) [1:5.0-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-backgrounds (artful-proposed/universe) [3.26.1-1 => 3.26.2-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: hitori (artful-proposed/universe) [3.22.4-0ubuntu1 => 3.22.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hitori [sync] (artful-proposed) [3.22.4-1]
<xnox> infinity, apw, tjaalton  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1723619
<ubot5> Ubuntu bug 1723619 in linux (Ubuntu) "Ubuntu Desktop ISO fails to boot with nouveau" [Undecided,New]
<tjaalton> meh
-queuebot:#ubuntu-release- Unapproved: r-cran-xml2 (artful-proposed/universe) [1.1.0-1ubuntu2 => 1.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-xml2 [sync] (artful-proposed) [1.1.1-2]
<infinity> jbicha: Did you have any urge to try to figure out why gtk+3.0 regressed the software-properties testsuite?
<infinity> jbicha: Given that the same testsuite has been triggered successfully by other updates, it's pretty clearly upgrading GTK that breaks it.
<ginggs> infinity: i expected LP: #1717257 to fix the build of starpu-contrib https://launchpad.net/ubuntu/+source/starpu-contrib/1.2.0+dfsg-4build1 - but it didn't
<ubot5> Launchpad bug 1717257 in llvm-toolchain-3.8 (Ubuntu) "[bug / patch ]patch for glibc 2.26 to avoid errors in compiling with CUDA(NVCC)" [Undecided,Confirmed] https://launchpad.net/bugs/1717257
<ginggs> does something else need a rebuild first?
<jbicha> infinity: I haven't worked on it yet because I'd need to figure out how to set up an autopkgtest environment that can handle breaks-testbed
<jbicha> infinity: Laney assigned himself to LP: #1721828 so maybe he's working on it?
<ubot5> Launchpad bug 1721828 in gtk+3.0 (Ubuntu Artful) "gtk 3.22.24 breaks software-properties tests (Gdk-Message: setup.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.)" [High,Triaged] https://launchpad.net/bugs/1721828
<infinity> jbicha: Well, the easiest way is just to sacrifice a VM and run the tests as root.
<infinity> jbicha: Setting it up as an autopkgtest makes debugging a pain.
<infinity> jbicha: As for the CUDA thing, looks like GCC might also need a patch to hide #define _GLIBCXX_USE_FLOAT128 1
<jbicha> which CUDA thing?
<infinity> jbicha: Erm, that was for ginggs.
<infinity> ginggs: ^
<jbicha> oh good, I try to avoid dealing with compilers ;)
<infinity> A wise life choice.
<LocutusOfBorg> tjaalton, link?
<tjaalton> LocutusOfBorg: https://launchpadlibrarian.net/340770594/buildlog_ubuntu-xenial-s390x.llvm-toolchain-5.0_1%3A5.0-3~16.04.1_BUILDING.txt.gz
<infinity> ginggs: I suspect http://paste.ubuntu.com/25740823/ will fix it, but testing locally before blindly uploading GCC. :P
<LocutusOfBorg> CMake Error at /usr/share/cmake-3.5/Modules/CMakeTestCXXCompiler.cmake:54 (message):
<LocutusOfBorg>   The C++ compiler "/usr/bin/g++-5" is not able to compile a simple test
<LocutusOfBorg>   program.
<LocutusOfBorg> I would say gcc is broken in s390x?
<LocutusOfBorg> that cmake module creates a simple hello world and try to compile it
<infinity> LocutusOfBorg: I mean, you could say that, but then how did we built all the other packages?
<infinity> s/built/build/
<LocutusOfBorg>  5.4.0-6ubuntu1~16.04.5 is some days old
<infinity>   collect2: fatal error: cannot find 'ld'
<infinity> Perhaps s390x doesn't have gold?
<flocculant> infinity: am I likely to see rc images soonish?
<infinity> flocculant: Yeah, I'll spin some up this afternoon.  We're still waiting on some things for final images, but best to get people something to test in the meantime.
<flocculant> infinity: okey doke - cheers - I'll see them in my morning then :)
<LocutusOfBorg> infinity, why can't it find bfd?
<infinity> LocutusOfBorg: Because it's calling gcc with -fuse-ld=gold?
<LocutusOfBorg> oh... maybe llvm
<LocutusOfBorg> yep
<infinity> LocutusOfBorg: 4.0 had hacks to exclude gold from certain arches.
<infinity> Guessing 5.0 doesn't.
<LocutusOfBorg> tjaalton,  BINUTILS_GOLD_ARCHS := amd64 arm64 armhf i386 powerpcspe ppc64 ppc64el sparc sparc64 x32 s390x
<LocutusOfBorg> maybe remove s390x from that list and try again
<infinity> Or just a more inclusive list. :)
<infinity> -BINUTILS_GOLD_ARCHS := amd64 armhf i386 powerpcspe ppc64 ppc64el sparc sparc64 x32
<infinity> +BINUTILS_GOLD_ARCHS := amd64 arm64 armhf i386 powerpcspe ppc64 ppc64el sparc sparc64 x32 s390x
<infinity> Diff from 4.0 to 5.0
<LocutusOfBorg> yep
<infinity> So, in the interest of being safe for backports, removing arm64 might also be correct.
<LocutusOfBorg> so in the meanwhile s390x got gold support?
<infinity> Would seem so.
<infinity> tjaalton: ^-- Revert that line to 4.0's version, IMO.
<LocutusOfBorg> https://launchpadlibrarian.net/339397587/buildlog_ubuntu-artful-s390x.binutils_2.29.1-4ubuntu1_BUILDING.txt.gz
<LocutusOfBorg> confirmed
<tjaalton> infinity: alright
<LocutusOfBorg> thanks
 * LocutusOfBorg goes to sleep
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Artful Final] (20101020ubuntu523) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Artful Final] (20101020ubuntu523) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Artful Final] (20101020ubuntu523) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Artful Final] (20101020ubuntu523) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Artful Final] (20101020ubuntu523) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Artful Final] (20101020ubuntu523) has been added
#ubuntu-release 2017-10-15
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-8ubuntu2 => 7.2.0-8ubuntu3] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (artful-proposed) [7.2.0-8ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-backgrounds [sync] (artful-proposed) [3.26.2-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Final] (20171015) has been added
<valorie> \o/
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Final] (20171015) has been added
-queuebot:#ubuntu-release- Unapproved: lxd (artful-proposed/main) [2.18-0ubuntu5 => 2.18-0ubuntu6] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (artful-proposed) [2.18-0ubuntu6]
-queuebot:#ubuntu-release- New source: llvm-toolchain-5.0 (xenial-proposed/primary) [1:5.0-3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: freeipa (artful-proposed/universe) [4.4.4-3 => 4.4.4-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (artful-proposed) [4.4.4-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: umockdev (artful-proposed/universe) [0.9.2-1 => 0.9.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted umockdev [sync] (artful-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- Unapproved: autopkgtest (artful-proposed/main) [5.0 => 5.0.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [sync] (artful-proposed) [5.0.1]
-queuebot:#ubuntu-release- Unapproved: im-config (artful-proposed/main) [0.32-1ubuntu2 => 0.32-1ubuntu3] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (artful-proposed) [0.32-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: starpu-contrib (artful-proposed/multiverse) [1.2.0+dfsg-4build1 => 1.2.0+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted starpu-contrib [source] (artful-proposed) [1.2.0+dfsg-4ubuntu1]
<ginggs> infinity: thanks for gcc/cuda fix - starpu-contrib built now :)
-queuebot:#ubuntu-release- Unapproved: spdlog (artful-proposed/universe) [1:0.11.0-2ubuntu1 => 1:0.11.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spdlog [sync] (artful-proposed) [1:0.11.0-3]
-queuebot:#ubuntu-release- Unapproved: xorg-server (artful-proposed/main) [2:1.19.5-0ubuntu1 => 2:1.19.5-0ubuntu2] (desktop-core, xorg)
<mitya57> ^^ Nothing urgent, can be a 0-day SRU or a normal SRU. (Cc tjaalton, I asked Alberts MuktupÄvels to file a bug with reproduce steps as you requested.)
<infinity> ginggs: I know it did, cause it was also my upload. :P
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (artful-proposed) [2:1.19.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-clocks (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-clocks [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: sambamba (artful-proposed/universe) [0.6.6-1 => 0.6.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sambamba [source] (artful-proposed) [0.6.6-1build1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.476 => 2.477] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.477]
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (artful-proposed/universe) [10.1.26-1 => 10.1.28-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.1 [sync] (artful-proposed) [10.1.28-1]
<LocutusOfBorg> sigh infinity we didn't make ldc migrate for a reason... tilinx is broken
 * LocutusOfBorg points to #ubuntu-devel some hours ago
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/tilix/+bug/1721101
<ubot5> Ubuntu bug 1721101 in tilix (Ubuntu) "tilix crashes on execution" [Undecided,Confirmed]
<LocutusOfBorg> probably it is a matter of a rebuild, please accept it
-queuebot:#ubuntu-release- Unapproved: tilix (artful-proposed/universe) [1.6.4-1ubuntu2 => 1.6.4-1ubuntu3] (no packageset)
<jbicha> LocutusOfBorg: please test tilix first. When I did a test-rebuilt I still had the bug (maybe it's gtkd or something that needs rebuilt?)
-queuebot:#ubuntu-release- Unapproved: tilix (artful-proposed/universe) [1.6.4-1ubuntu2 => 1.6.4-2ubuntu1] (no packageset)
<LocutusOfBorg> this one ^^ ensures the dependencies are correctly picked up, test building and running right now
<infinity> LocutusOfBorg: Sorry, I missed that conversation.
<infinity> LocutusOfBorg: Hint, a blocking bug would have prevented the migration. :P
-queuebot:#ubuntu-release- Unapproved: rejected tilix [source] (artful-proposed) [1.6.4-1ubuntu3]
<LocutusOfBorg> it happened today, and I was doing some $dailywork :/
-queuebot:#ubuntu-release- Unapproved: accepted tilix [source] (artful-proposed) [1.6.4-2ubuntu1]
<LocutusOfBorg> I'm trying a gtk-d rebuild in my ppa and a tilix one
<LocutusOfBorg> seems to be still failing
<LocutusOfBorg> damn ABIs
<fossfreedom> sigh ... just noticed the conversation.... yeah Tilix is rather critical for us (ubuntu budgie) - it is our one and only terminal.
-queuebot:#ubuntu-release- New sync: golang-github-linuxkit-virtsock (artful-proposed/primary) [0.0~git20170720.0.0416e3d-1]
#ubuntu-release 2018-10-08
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.13 => 1.14] (lubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu6 => 2.02+dfsg1-5ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu6]
-queuebot:#ubuntu-release- New sync: r-cran-popepi (cosmic-proposed/primary) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-9.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-9.10]
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.02.f2dbc215fdb-1 => 10.4+git20180830.02.f2dbc215fdb-2] (personal-fossfreedom, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (cosmic-proposed/universe) [0.6.1-1 => 0.6.1-2] (personal-fossfreedom, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.0~rc2ubuntu1 => 1.7.0] (core) (sync)
-queuebot:#ubuntu-release- New sync: r-cran-xslt (cosmic-proposed/primary) [1.3-1]
-queuebot:#ubuntu-release- Unapproved: sunpy (cosmic-proposed/universe) [0.9.2-5 => 0.9.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sunpy [sync] (cosmic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (cosmic-proposed/universe) [1.5.0-0ubuntu1 => 1.5.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (cosmic-proposed) [1.5.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-session (cosmic-proposed/main) [3.30.0-0ubuntu3 => 3.30.0-0ubuntu4] (ubuntu-desktop) (sync)
<jamespage> well that's a little embarrassing - I should not straddle work over a weekend.
 * jamespage goes to fix his FTBFS
-queuebot:#ubuntu-release- Unapproved: python-imaplib2 (cosmic-proposed/universe) [2.57-3 => 2.57-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-imaplib2 [sync] (cosmic-proposed) [2.57-5]
-queuebot:#ubuntu-release- Unapproved: fpylll (cosmic-proposed/universe) [0.4.1+ds1-3 => 0.4.1+ds1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fpylll [sync] (cosmic-proposed) [0.4.1+ds1-4]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (cosmic-proposed/universe) [1.5.0-0ubuntu2 => 1.5.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (cosmic-proposed) [1.5.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.5]
<ginggs> is it an option to RM imexam on s390x? it would be good to get python-scipy to migrate
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu12 => 0.131ubuntu13] (core)
-queuebot:#ubuntu-release- Unapproved: accepted awscli [sync] (cosmic-proposed) [1.16.26-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdebian-installer [source] (cosmic-proposed) [0.110ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (cosmic-proposed) [1.16.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [source] (cosmic-proposed) [3.29.91-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted reiserfsprogs [source] (cosmic-proposed) [1:3.6.27-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (cosmic-proposed) [16.10+18.10.20181004.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (cosmic-proposed) [1:18.10.10]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (cosmic-proposed) [16.10+18.10.20181005-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [sync] (cosmic-proposed) [18.7.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (cosmic-proposed) [1:2.19.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (cosmic-proposed) [1.378]
-queuebot:#ubuntu-release- Unapproved: accepted babl [sync] (cosmic-proposed) [0.1.58-1]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (cosmic-proposed) [1.21.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted pikopixel.app [sync] (cosmic-proposed) [1.0-b9d-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (cosmic-proposed) [1.7.9.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-controls [source] (cosmic-proposed) [1.6]
-queuebot:#ubuntu-release- Unapproved: accepted libfm-qt [source] (cosmic-proposed) [0.13.1-5ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (cosmic-proposed) [18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected pikopixel.app [sync] (cosmic-proposed) [1.0-b9d-1]
-queuebot:#ubuntu-release- Unapproved: accepted gettext [sync] (cosmic-proposed) [0.19.8.1-8]
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (cosmic-proposed/main) [3.30.1-1 => 3.30.1-1build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: evolution (cosmic-proposed/universe) [3.30.1-1 => 3.30.1-1build1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (cosmic-proposed/universe) [18.10.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (cosmic-proposed) [0.10.5]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-globalkeys [source] (cosmic-proposed) [0.13.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (cosmic-proposed) [1.7.0]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [sync] (cosmic-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (cosmic-proposed) [3.30.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted jquery-goodies [sync] (cosmic-proposed) [12-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (cosmic-proposed) [10.4+git20180830.02.f2dbc215fdb-2]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (cosmic-proposed) [0.131ubuntu13]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (cosmic-proposed) [0.42.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (cosmic-proposed) [3.30.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.14]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-documents [source] (cosmic-proposed) [3.30.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-sushi [source] (cosmic-proposed) [3.30.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [source] (cosmic-proposed) [3.30.1-1build1]
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (cosmic-proposed/main) [3.30.0-0ubuntu1 => 3.30.1.2-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (cosmic-proposed/main) [1.14.2-2 => 1.14.4-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (cosmic-proposed/main) [1.14.2-1ubuntu1 => 1.14.4-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (cosmic-proposed/main) [1.14.2-1ubuntu3 => 1.14.4-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (cosmic-proposed/universe) [1.14.2-1ubuntu1 => 1.14.4-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (cosmic-proposed/universe) [1.14.2-1 => 1.14.4-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: okteta (cosmic-proposed/universe) [5:0.25.3-0ubuntu1 => 5:0.25.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: mesa (cosmic-proposed/main) [18.2.1-1ubuntu1 => 18.2.2-0ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: libqmi (cosmic-proposed/main) [1.20.0-1ubuntu1 => 1.20.0-1.1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: modemmanager (cosmic-proposed/main) [1.7.990-1ubuntu1 => 1.8.2-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-themes [sync] (bionic-proposed) [16.10+18.04.20181004-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (bionic-proposed) [16.10+18.04.20181005-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lightsoff (cosmic-proposed/universe) [1:3.28.0-1 => 1:3.30.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: evince (cosmic-proposed/main) [3.30.0-3ubuntu1 => 3.30.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: goocanvasmm-2.0 (cosmic-proposed/universe) [1.90.11-1 => 1.90.11-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goocanvasmm-2.0 [sync] (cosmic-proposed) [1.90.11-2]
-queuebot:#ubuntu-release- Unapproved: gnome-taquin (cosmic-proposed/universe) [3.28.0-2 => 3.30.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: numix-icon-theme-circle (cosmic-proposed/universe) [18.09.19-1 => 18.10.03-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-taquin [sync] (cosmic-proposed) [3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted numix-icon-theme-circle [sync] (cosmic-proposed) [18.10.03-1]
-queuebot:#ubuntu-release- Unapproved: network-manager-pptp (cosmic-proposed/main) [1.2.6-2 => 1.2.8-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mypaint-brushes (cosmic-proposed/universe) [1.3.0-1 => 1.3.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mypaint-brushes [sync] (cosmic-proposed) [1.3.0-1.1]
-queuebot:#ubuntu-release- Unapproved: dino-im (cosmic-proposed/universe) [0.0.git20180904-1 => 0.0.git20180921-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dino-im [sync] (cosmic-proposed) [0.0.git20180921-1]
-queuebot:#ubuntu-release- Unapproved: daisy-player (cosmic-proposed/universe) [11.4-1build1 => 11.6.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted daisy-player [sync] (cosmic-proposed) [11.6.1.1-1]
-queuebot:#ubuntu-release- Unapproved: inxi (bionic-backports/universe) [2.3.56-1 => 3.0.24-1-1~ubuntu18.04.1] (ubuntu-mate, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [sync] (cosmic-proposed) [3.30.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: thunderbird (cosmic-proposed/main) [1:52.7.0+build1-0ubuntu1 => 1:52.9.1+build3-0ubuntu0.18.04.1] (mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (cosmic-proposed/universe) [5.13.5-1ubuntu5 => 5.13.5-1ubuntu6] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (cosmic-proposed) [3.30.1.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted lightsoff [sync] (cosmic-proposed) [1:3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager [sync] (cosmic-proposed) [1.8.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted okteta [source] (cosmic-proposed) [5:0.25.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (cosmic-proposed) [1.20.0-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-pptp [sync] (cosmic-proposed) [1.2.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (cosmic-proposed) [18.2.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (cosmic-proposed) [5.13.5-1ubuntu6]
<wxl> when it comes to the upload queue, can someone tell me the difference between done and accepted?
<cjwatson> Accepted means that per-upload processing has happened but the publisher hasn't run on it yet.
<wxl> oh well that's a very useful difference! thanks cjwatson
<Trevinho> ah, sil2100 I forgot to thank you for the review :-)
<cjwatson> So it's a valid upload and will be processed, but it isn't yet in the Packages/Sources index files (even on the master system).
-queuebot:#ubuntu-release- Unapproved: libepoxy (cosmic-proposed/main) [1.5.2-0.3 => 1.5.3-0.1] (core) (sync)
<seb128> could I get a review for https://bugs.launchpad.net/ubuntu/+source/bolt/+bug/1795864 ? I would rather land that update early than late if possible
<ubot5> Ubuntu bug 1795864 in bolt (Ubuntu) "[ffe] Update to 0.5" [Wishlist,New]
<sil2100> Trevinho: yw!
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1023.26] (kernel)
<tsimonq2> infinity: How possible would it be to limit Lubuntu 18.10 to a six month support cycle? (i.e. Must upgrade to 19.04 as soon as it comes out)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (cosmic-proposed/main) [140 => 141] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (cosmic-proposed/main) [1:7-3 => 1:7-5] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected thunderbird [sync] (cosmic-proposed) [1:52.9.1+build3-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu5 => 1:3.26.4-0ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu5 => 1:3.26.4-0ubuntu6] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.4-0~ubuntu18.04.1 => 1:3.26.4-0~ubuntu18.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.4 => 229-4ubuntu21.5] (core)
-queuebot:#ubuntu-release- Unapproved: orc (cosmic-proposed/main) [1:0.4.28-2 => 1:0.4.28-3] (desktop-core, ubuntu-server) (sync)
<infinity> tsimonq2: Personally, I'd not be inclined to allow any flavour to do that.  Without the overlap, you're guaranteed to be leaving people unsupported for some period of time.
<tsimonq2> infinity: Is 9 months a hard limit or can something be decided on where 6 < x < 9?
<teward> infinity: not to mention users are 'lazy' and won't want to immediately upgrade every 6 months the moment we release - which is why i support 9 months because that gives a 3 month buffer where users SHOULD be moving their data to an upgraded system (and it doesn't cause headaches with support either different from the system)
<teward> (my two cents even though I don't have a say)
<infinity> tsimonq2: I could see an argument for the 9mo series' being 7mo instead to encourage faster upgrading, but if that's a discussion we were going to have, I'd rather have it for everyone, not just one flavour.
<infinity> tsimonq2: teward's point is one of the reasons it's currently 9mo, though.  It takes people a little while to evaluate a dist-upgrade.
<tsimonq2> But this is non-LTS.
<teward> tsimonq2: same point stands.
<tsimonq2> I think it's worth re-evaluating, personally.
<teward> tsimonq2: go to Ask Ubuntu.  Peruse the 17.10 tag for recent posts.  See how many people are still using 17.10 and haven't upgraded yet
<infinity> I mean, we did do so once.  It used to be 18mo. :P
<tsimonq2> :P
<teward> tsimonq2: you'll see exactly how many users fit into the "lazy" category of my point.
<infinity> Not that long ago, really.
<tsimonq2> infinity: I assume this is a TB-level decision? Mind if I make my case at the next meeting?
<teward> tsimonq2: if I may be so inclinde to ask
<teward> what *is* your reasoning other than "Upgrade faster"?
<teward> because there's no way we, the community / Ubuntu at large, can force users to upgrade.  They'll always be lazy and "not upgrade until they don't have a chocie"
<teward> even when it goes EOL we see this, which is why I said to peruse the 17.10 tag on Ask ubuntu for recent posts
<teward> (we close at least one or two a day for EOL reason)
<tsimonq2> Less resources spent maintaining near-EOL releases.
<infinity> teward: To be fair, that's an argument for faster EOLs, not slower. :)
<infinity> But we have the overlap for responsible users, not irresponsible ones.
<teward> infinity: while you're not wrong, users are still 'lazy' (the civil way of my categorization of 90% of the users)
<teward> infinity: +1 there
<infinity> We can't do anything about people who refuse to upgrade, we can do plenty for people who cautiously evaluate upgrades.
<teward> infinity: if anything i'm parital to 7-9month range, but not 6 :P
<teward> in case it's relevant :P
<teward> infinity: good question from simon thouhg, is that a TB discussion or something that all flavors need to be voiced in on rather than TB level alone?
<teward> (or is this something that SABDFL would have a voice on?)
<infinity> tsimonq2: How much time do you spend doing SRUs in that 3mo over overlap?
<infinity> teward: I think Mark was involved in the 18->9 switch, but I'm not convinced he'd have to be.  Either way, it's certainly something the TB would be involved in.
<infinity> tsimonq2: If you want to bring it to tomorrow's meeting, go for it, but I'd rather have hard data (about SRUs during the overlap, in months 1, 2, 3, for several 9mo releases, etc), than just based on feelings about "it's a waste of time, but I can't show how much".
<teward> infinity: when/where is the TB meeting tomorrow, if I want to lurk :P
<infinity> tsimonq2: My experience as that 95% of the SRUs to a short release are in the *first* 3mo after release, and most of what happens in the last 3mo are just security fixes, which are certainly a burden on someone, but that someone isn't you.
<infinity> s/as that/is that/
<infinity> (But my 95% was a made-up statistic, and real numbers would be interesting if we're talking about changing things)
<teward> infinity: the other reason I don't like 6 (but would be okay for 7-9) is because for business-critical resources sometimes you can't just jump within a month of a new release due to software versions, etc. in the corporate world - which is a reason to keep it at 9 months, in my opinion
<teward> (where I work we actually do have a fair amount of inertia for migrating between server versions, it's why I forced LTSes when I came on staff...)
<infinity> Right, I couldn't with a straight face call something "supported" if we forced upgrades the day a new release came out.  But I'm open to discussions of shrinking the window, if they're data-driven, rather than emotional arguments.
<infinity> Anyhow, back to Canadian Thanksgiving and Not Working(tm) with me.
<teward> HEH
<teward> enjoy infinity
-queuebot:#ubuntu-release- Unapproved: a2ps (cosmic-proposed/universe) [1:4.14-3 => 1:4.14-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted a2ps [sync] (cosmic-proposed) [1:4.14-4]
-queuebot:#ubuntu-release- Unapproved: mutter (cosmic-proposed/main) [3.30.0-4 => 3.30.0-6] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: openmpi (cosmic-proposed/universe) [3.1.2-5 => 3.1.2-6] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (cosmic-proposed/universe) [1.378 => 1.379] (kubuntu)
<wxl> it seems lubuntu images failed due to issues getting index files due to hash sum mismatches, but i didn't get a notification. is there some list i'm not on?
<acheronuk> wxl: is it because the livefs build succeeded, and the fail was later on in the iso build scriptery?
<wxl> it failed in "Building Lubuntu daily CDs"
<wxl> which is to say yes
<wxl> given that the previous step is "Downloading live filesystem images" which is to say it's got a squashfs to grab
<acheronuk> well, I thought the emails got sent on livefs fails. I could be wrong and they are both stages
<wxl> yeah nothing in spam. boo
<tsimonq2> infinity: Can do.
<tsimonq2> Since mdeslaur is on the security team, maybe he can attest to potential time saved there.
<tsimonq2> But I think he's also Canadian, thus holidaym
<tsimonq2> s/holidaym/holiday./
<wxl> any chance anyone can get to reviewing trojita today? perhaps someone not canadian? vorlon? :)
-queuebot:#ubuntu-release- Unapproved: accepted libepoxy [sync] (cosmic-proposed) [1.5.3-0.1]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (cosmic-proposed) [1:3.26.4-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (cosmic-proposed) [141]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (cosmic-proposed) [3.30.0-6]
-queuebot:#ubuntu-release- Unapproved: rejected nautilus [sync] (cosmic-proposed) [1:3.26.4-0ubuntu6]
<wxl> ugh i got the darn hash sum mismatch again but livefs built fine https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/cosmic/daily-live-20181008.1.log
<wxl> er wait
<acheronuk> not yet
<wxl> what did i just click on?
<wxl> nevermind XD
<acheronuk> the wrong log :P
-queuebot:#ubuntu-release- Unapproved: paraview (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2 => 5.4.1+dfsg4-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted paraview [sync] (cosmic-proposed) [5.4.1+dfsg4-3.1]
<acheronuk> wxl: still hash sum mismatch
<acheronuk> kubuntu iso did the same earkier
<acheronuk> *earlier
<wxl> actually it looks like budgie and kylin don't have images either
<wxl> kylin didn't try so don't know what's up with that
<wxl> but budgie did; hash sum mismatch
<wxl> ^^ bashfulrobot something weird with images today
-queuebot:#ubuntu-release- Unapproved: polari (cosmic-proposed/universe) [3.30.1-1 => 3.30.1-1ubuntu1] (no packageset)
<bashfulrobot> wxl: thanks for the heads up!
-queuebot:#ubuntu-release- Unapproved: accepted polari [source] (cosmic-proposed) [3.30.1-1ubuntu1]
<bashfulrobot> wxl: it looks like most failed today, no?
<tsimonq2> Yeahp.
<tsimonq2> infinity: ^
<wxl> well there's a bunch with images today
<wxl> the ones that i see that don't have them are lubuntu and budgie and though i think they did have them for today kubuntu's rebuilds failed
<wxl> i bet if you rebuilt everything everything would fail
<tsimonq2> vorlon isn't Canadian, maybe he's around? :P
<vorlon> tsimonq2, wxl: Columbus Day, which I'm kind of happy neither of you were aware of, but I'm still taking the bank holiday
<tsimonq2> vorlon: Alright.
<wxl> Indigenous People's Day, right
<tsimonq2> So that's what the grumblings on Twitter were about... huh
<wxl> (to hell with columbus)
<tsimonq2> That.
<vorlon> anyway, not clear on what you needed, I could push some buttons quickly while you have me at the keyboard
<tsimonq2> vorlon: Images broken because of hash mismatch.
<wxl> that
<wxl> the harder one is reviewing new package trojita but i doubt that's a couple pushes of the button
<wxl> unless you want to blindly give it your blessing :)
<vorlon> not so much
<vorlon> which images should I be trying to respin?
<wxl> lubuntu and kubuntu and budgie but we've already tried respinning and got the same error
<wxl> livefs builds fine
<vorlon> sure; I'm poking the ftp mirror first and then respinning
<vorlon> queued up
<tsimonq2> Thanks vorlon.
<tsimonq2> infinity: Are we thinking Thursday for RCs?
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.0-0ubuntu1 => 3.30.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accerciser (cosmic-proposed/universe) [3.22.0-5 => 3.22.0-6] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: iagno (cosmic-proposed/universe) [1:3.28.0-1 => 1:3.30.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted iagno [sync] (cosmic-proposed) [1:3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: nautilus-python (cosmic-proposed/universe) [1.1-6 => 1.2.2-1] (ubuntu-budgie) (sync)
<wxl> well kubuntu has images now
<wxl> not me
 * wxl cries
<wxl> vorlon: i know you're vacationing but do you have any further insight on this issue of our images?
#ubuntu-release 2018-10-09
<wxl> oh maybe i'm just being impatient
<wxl> the livefs's aren't fully built
<wxl> taking forever though
<jbicha> wxl: some parts of Canonical infrastructure weren't working well today
<wxl> hope everything's better
<wxl> i blame columbus
<jbicha> (don't know if it's related but maybe tomorrow will be better)
<jbicha> i blame akron
<wxl> well, at least it's ohio's fault
<wxl> it seems only 32 shows failed but that seems to break the whole darn thing
<wxl> @kc2bez huh?
<wxl> phew success
<wxl> go get the images
<wxl> yay we have images
<wxl> t/ld
<wxl> @kc2bez huh?
<wxl> in any case we have images again
<wxl> @HMollerCl your question is interesting because it seems that i386 failing causes them both to fail. this may be because i triggered them to rebuild at the same time. perhaps if i could have done 64 first, it would have succeeded and 32 could fail on its own
-queuebot:#ubuntu-release- Unapproved: python-botocore (cosmic-proposed/universe) [1.10.78+repack-1 => 1.12.16+repack-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [sync] (cosmic-proposed) [1.12.16+repack-1]
<tsimonq2> wxl: ECHAN
<wxl> @tsimonq2: ETIMEOUT
<tsimonq2> wxl: WSPAMMINGWRONGCHANNELS
 * wxl hands tsimonq2 some whitespace
<tsimonq2> BAD.
 * wxl hands tsimonq2 more whitespace
-queuebot:#ubuntu-release- Unapproved: pkgbinarymangler (bionic-proposed/main) [138.18.04.0 => 138.18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pkgbinarymangler (bionic-proposed/main) [138.18.04.0 => 138.18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.0-0ubuntu1 => 3.30.2-0ubuntu2] (ubuntu-desktop)
<vorlon> wxl: debian/trojita.postinst looks pointless
-queuebot:#ubuntu-release- New: accepted trojita [source] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New binary: trojita [s390x] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: trojita [ppc64el] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: trojita [arm64] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: trojita [armhf] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: trojita [amd64] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: trojita [i386] (cosmic-proposed/universe) [0.7-0ubuntu1] (no packageset)
<acheronuk> vorlon: thank you. (it's a kde project as well)
-queuebot:#ubuntu-release- Unapproved: bolt (cosmic-proposed/main) [0.4-0ubuntu2 => 0.5-1] (desktop-core) (sync)
<seb128> ^ the bolt upload is ffe bug #1795864 but I didn't want to do an Ubuntu diff upload only to include the bug reference
<ubot5> bug 1795864 in bolt (Ubuntu) "[ffe] Update to 0.5" [Medium,Fix committed] https://launchpad.net/bugs/1795864
-queuebot:#ubuntu-release- Unapproved: yelp (cosmic-proposed/main) [3.30.0-1 => 3.30.0-1build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.7-0ubuntu0.18.04.1 => 12.2.8-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (cosmic-proposed/main) [1.8.4-1 => 1.8.6-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-recipes (cosmic-proposed/universe) [2.0.2-3 => 2.0.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-recipes [sync] (cosmic-proposed) [2.0.2-4]
-queuebot:#ubuntu-release- Unapproved: mutter (cosmic-proposed/main) [3.30.0-6 => 3.30.1-1] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: inkscape (cosmic-proposed/universe) [0.92.3-3 => 0.92.3-4] (ubuntustudio) (sync)
<seb128> could someone review the gstreamer updates in the cosmic queue?
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.3-0ubuntu18.04.2 => 3.28.3-0ubuntu18.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-disk-utility (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted accerciser [sync] (cosmic-proposed) [3.22.0-6]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (cosmic-proposed) [1.379]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openvpn [sync] (cosmic-proposed) [1.8.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted orc [sync] (cosmic-proposed) [1:0.4.28-3]
-queuebot:#ubuntu-release- Unapproved: accepted bolt [sync] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [sync] (cosmic-proposed) [1:7-5]
-queuebot:#ubuntu-release- Unapproved: accepted openmpi [sync] (cosmic-proposed) [3.1.2-6]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted yelp [source] (cosmic-proposed) [3.30.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus-python [sync] (cosmic-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted inkscape [sync] (cosmic-proposed) [0.92.3-4]
-queuebot:#ubuntu-release- Unapproved: vala (cosmic-proposed/universe) [0.42.2-1 => 0.42.2-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (cosmic-proposed/main) [1.8.18-2ubuntu1 => 1.8.18-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.10-0ubuntu0.16.04.1 => 10.2.11-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (cosmic-proposed/main) [1:12.2-0ubuntu3 => 1:12.2-0ubuntu4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.35.4+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.35.4]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.35.4~14.04]
-queuebot:#ubuntu-release- Unapproved: shotwell (cosmic-proposed/main) [0.30.1-0ubuntu1 => 0.30.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (cosmic-proposed/universe) [18.10.2 => 18.10.3] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-disk-utility [source] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (cosmic-proposed) [1:12.2-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (cosmic-proposed) [0.42.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (cosmic-proposed) [1.8.18-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (cosmic-proposed) [18.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (cosmic-proposed) [0.30.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (cosmic-proposed/multiverse) [1.0.0-8build1 => 1.0.0-8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted caffe-contrib [source] (cosmic-proposed) [1.0.0-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grilo (cosmic-proposed/main) [0.3.6-1 => 0.3.6-1build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-click (cosmic-proposed/main) [6.7-5 => 6.7+git20180829-1] (edubuntu, kubuntu, ubuntu-server) (sync)
<xnox> current python-click FTBFS in ubuntu, this one ^ does build fine.
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.5 => 1.6.6] (core)
-queuebot:#ubuntu-release- Unapproved: lsof (cosmic-proposed/main) [4.89+dfsg-0.1 => 4.89+dfsg-0.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: jfsutils (cosmic-proposed/main) [1.1.15-3 => 1.1.15-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.28 => 1.2.29] (core)
-queuebot:#ubuntu-release- Unapproved: python-testtools (cosmic-proposed/main) [2.3.0-4ubuntu2 => 2.3.0-5] (ubuntu-desktop, ubuntu-server) (sync)
<xnox> current python-testtools FTBFS in ubuntu, the sync ^ fixes py3.7 test failures
-queuebot:#ubuntu-release- Unapproved: distro-info (cosmic-proposed/main) [0.18 => 0.18ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grilo [source] (cosmic-proposed) [0.3.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted lsof [source] (cosmic-proposed) [4.89+dfsg-0.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-testtools [sync] (cosmic-proposed) [2.3.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted jfsutils [source] (cosmic-proposed) [1.1.15-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-click [sync] (cosmic-proposed) [6.7+git20180829-1]
-queuebot:#ubuntu-release- Unapproved: rejected distro-info [source] (cosmic-proposed) [0.18ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-kvm (cosmic-proposed/main) [4.18.0-1002.2 => 4.18.0-1003.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (cosmic-proposed/main) [4.18.0.1002.2 => 4.18.0.1003.3] (kernel) (sync)
<flocculant> infinity - not able to do this on the tracker apparently - but I'm no longer the first call person to ping about Xubuntu - akxwi-dave is. I'd respond if needed of course like bluesabre
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (cosmic-proposed/main) [141 => 142] (kubuntu, ubuntu-desktop)
<xnox> Laney, salsa-as-a-service done https://salsa.debian.org/debian/distro-info/merge_requests/1/commits
 * Laney cuddles xnox
 * xnox ðð¤
-queuebot:#ubuntu-release- Unapproved: sqlmap (cosmic-proposed/universe) [1.2.9-1 => 1.2.10-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sqlmap [sync] (cosmic-proposed) [1.2.10-1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20180911.1-0ubuntu1 => 1:20181009.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (cosmic-proposed/universe) [4.18.0.1004.1 => 4.18.0.1005.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (cosmic-proposed/universe) [4.18.0-1004.6 => 4.18.0-1005.7] (kernel) (sync)
<wxl> vorlon: yeah, true enough. thanks for uploading it!
<wxl> approving it i mean
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20181009.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180911.1-0ubuntu0.14.04.1 => 1:20181009.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180911.1-0ubuntu0.16.04.1 => 1:20181009.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180911.1-0ubuntu0.18.04.1 => 1:20181009.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20181009.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20181009.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20181009.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (cosmic-proposed/multiverse) [1.0.0-8ubuntu1 => 1.0.0-8ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted caffe-contrib [source] (cosmic-proposed) [1.0.0-8ubuntu2]
<wxl> vorlon: so i guess i hadn't realized the binaries as well need to be greenlighted in the new queue. is that something you can do for trojita as well?
<vorlon> wxl: done
<wxl> vorlon: thank you very much!!!
-queuebot:#ubuntu-release- New: accepted trojita [amd64] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted trojita [armhf] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted trojita [ppc64el] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted trojita [arm64] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted trojita [s390x] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted trojita [i386] (cosmic-proposed) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accerciser (cosmic-proposed/universe) [3.22.0-6 => 3.22.0-7] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (cosmic-proposed/multiverse) [31.0.0.108ubuntu1 => 31.0.0.122ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (cosmic-proposed) [31.0.0.122ubuntu1]
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta1-7225-g817fb216d-0ubuntu1 => 2.5.0~beta2-7291-gd0345ced5-0ubuntu1] (ubuntu-server)
<tsimonq2> vorlon: Could I please get some eyes on bug 1757871 bug 1757778?
<ubot5> bug 1757871 in smokeqt (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757871
<ubot5> bug 1757778 in perlqt (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757778
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1023.26]
<tsimonq2> At the beginning of next cycle is when I'll probably go ahead and coordinate a KDE 4 removal with Kubuntu as a whole.
<k_alam> Hi, Is it still possible for release team to upload this for cosmic ?
<k_alam> https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1741027/
<ubot5> Ubuntu bug 1741027 in unity-settings-daemon (Ubuntu) "[FFE] Screen sharing panels abort using an non-existent vino gsettings key" [High,New]
<k_alam> https://code.launchpad.net/~khurshid-alam/unity-control-center/sharing-panel/+merge/341306
<k_alam> Please read what happened before here https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1741027/comments/13
<tsimonq2> k_alam: The Release Team just needs to ACK/NACK the FFe; from there, subscribe ~ubuntu-sponsors and someone (likely me) will get to it.
<tsimonq2> I'm not comfortable using the queue as a stop gap to wait for an FFe to be approved.
<k_alam> So, I subscribe ~ubuntu-sponsors now ?
<tsimonq2> Wait until the Release Team gives feedback on the FFe.
<tsimonq2> Once that's done, then yes.
<k_alam> tsimonq2: Will they comment on the bug report if they approve ?
<tsimonq2> Yes.
<k_alam> Ok. Fine I will wait for now.
<k_alam> Thanks.
<tsimonq2> Thanks.
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (bionic-proposed/main) [4.18.0-1002.2~18.04.1] (no packageset)
<wxl> lubuntu's i386 livefs failed to build. don't see any logs. should i just try a rebuild or any hints?
-queuebot:#ubuntu-release- Unapproved: arpack (cosmic-proposed/universe) [3.6.2-1 => 3.6.3-1] (kubuntu) (sync)
<ginggs> vorlon: would you consider removing imexam:s390x to help python-scipy migrate? i think the python-scipy i386 autopkgtests can be force-badtested, looks like FP precision
-queuebot:#ubuntu-release- Unapproved: squid (cosmic-proposed/main) [4.1-1ubuntu2 => 4.1-1ubuntu3] (no packageset)
<ahasenack> infinity: ^
<ahasenack> incidentally, could someone please put squid back into the server packageset, where squid3 was? I emailed devel-permissions@, but I'm not sure that is the right place
<ahasenack> (or if here is the right place)
-queuebot:#ubuntu-release- Unapproved: lammps (cosmic-proposed/universe) [0~20180510.gitaa1d815fe-4ubuntu1 => 0~20180822.gitb47e49223+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lammps [sync] (cosmic-proposed) [0~20180822.gitb47e49223+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: bzr-fastimport (cosmic-proposed/universe) [0.13.0+bzr361-1ubuntu1 => 0.13.0+bzr361-4ubuntu1] (bzr)
<infinity> ahasenack: Wasn't expecting that to be a 1-liner.
<ahasenack> heh
<infinity> ahasenack: Had to read the whole PR thread to convince myself it wasn't awful. :P
<ahasenack> yeah, not perfect
<ahasenack> but better than the alternatives so far
<infinity> *nod*
<ahasenack> at least we ressurrected an old bug upstream
-queuebot:#ubuntu-release- Unapproved: accepted squid [source] (cosmic-proposed) [4.1-1ubuntu3]
<ahasenack> thx
<mwhudson> force-badtest twisted/18.7.0-3 pls?
-queuebot:#ubuntu-release- New binary: lammps [amd64] (cosmic-proposed/universe) [0~20180822.gitb47e49223+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-characters (cosmic-proposed/main) [3.29.91-1ubuntu1 => 3.30.0-1] (ubuntu-desktop, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (bionic-proposed) [5.10~rc4-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: gnome-gmail (cosmic-proposed/universe) [2.5.4-3 => 2.5.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.10 [source] (bionic-proposed) [1.10.4-2ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-gmail [sync] (cosmic-proposed) [2.5.6-1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.4-0ubuntu1 => 18.4-5-g6ee8a2c5-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> hrm, I thought we were not in a final-freeze for cosmic until Thursday. bdmurray or RAOF, are you still on for SRU approvals? we are trying to fix a bug that's blocking ubuntu-minimal cloud-images per https://bugs.launchpad.net/cloud-images/+bug/1796917
<ubot5> Ubuntu bug 1796917 in cloud-images "cloud-init fails to run on latest cosmic minimal image" [High,Fix committed]
<RAOF> blackboxsw: I am on for SRU approvals; that does not appear to be an SRU, though :)
<tsimonq2> blackboxsw: Right now we're still in Feature Freeze, it's just Beta Freeze (and thus making it a hard freeze instead of a soft freeze)
<tsimonq2> So you're still probably looking for a member of the Release Team.
<RAOF> blackboxsw: You'd be looking for a member of the release team - if you've got an upload that fixes that bug, it seems like a reasonable bug to fix even in hard-freeze.
<RAOF> (Modulo details about how cloud-init interacts with the images)
<gaughen> vorlon, infinity would you give some love to blackboxsw's request above ^^
<gaughen> thanks RAOF!
<gaughen> and tsimonq2 !
<tsimonq2> Anytime :)
<blackboxsw> oops right RAOF, thanks for the clarification.   and gaughen much thanks for adding some priority here :)
<vorlon> gaughen: looking
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.14 => 1.15] (lubuntu)
<vorlon> blackboxsw: from a release risk pov, the fact that there are changes unrelated to this bug means it's not a slam dunk
<vorlon> blackboxsw: the change itself for this bug makes sense, but I don't see much discussion in the bug log about why these new devices are showing up at all.  Has a determination been made that the addition of this new virtual interface is not a bug in linux-kvm?
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [18.4-5-g6ee8a2c5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.6]
<blackboxsw> vorlon: Odd_Bloke was checking with the kernel folks about why the tunl device was showing up now so we could root cause it. But, it did expose  a bug in cloud-init as far as us rejecting matching "zero-based" macs
<vorlon> ack
<mwhudson> can someone reject dh-golang from bionic unapproved?
<mwhudson> stray crap in the tarball
<mwhudson> oh ffs
-queuebot:#ubuntu-release- Unapproved: dh-golang (bionic-proposed/main) [1.34 => 1.34.1] (core)
<blackboxsw> and per the instance-data related changes, we really were not reporting the correctly documented raw metadata in instance-data.json for ec2 in a standard format, so this was a pass at resolving that content documented in instance-data.json. That doc content change is not crucial to the operation of cloud-init, but it provides a simple reference for consumers that might want to see what cloud/region  their instance
<blackboxsw> is running on
<vorlon> blackboxsw: it's accepted now
<powersj> vorlon, thanks
-queuebot:#ubuntu-release- Unapproved: rejected dh-golang [source] (bionic-proposed) [1.34.1]
<blackboxsw> vorlon: thank you!!
-queuebot:#ubuntu-release- Unapproved: accepted dh-golang [source] (bionic-proposed) [1.34.1]
#ubuntu-release 2018-10-10
-queuebot:#ubuntu-release- Unapproved: libosl (cosmic-proposed/universe) [0.8.0-1.4 => 0.8.0-1.4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libosl [source] (cosmic-proposed) [0.8.0-1.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-cran-curl (cosmic-proposed/universe) [3.2-2ubuntu1 => 3.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-curl [source] (cosmic-proposed) [3.2-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ntpsec (bionic-proposed/universe) [1.1.0+dfsg1-1 => 1.1.0+dfsg1-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [17.12.1-0ubuntu1 => 18.06.1-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ffindex (cosmic-proposed/universe) [0.9.9.7+soedinglab+git20180802-1 => 0.9.9.7+soedinglab+git20180802.74550c8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ffindex [sync] (cosmic-proposed) [0.9.9.7+soedinglab+git20180802.74550c8-1]
-queuebot:#ubuntu-release- Unapproved: rust-simd (cosmic-proposed/universe) [0.2.2-1 => 0.2.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rust-simd [sync] (cosmic-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- Unapproved: rust-serde (cosmic-proposed/universe) [1.0.70-1 => 1.0.79-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: rust-heapsize [ppc64el] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-heapsize [s390x] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rust-serde [sync] (cosmic-proposed) [1.0.79-1]
-queuebot:#ubuntu-release- New binary: rust-heapsize [amd64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-heapsize [armhf] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-heapsize [arm64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-heapsize [i386] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New sync: python-shodan (cosmic-proposed/primary) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted python-shodan [sync] (cosmic-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New binary: python-shodan [amd64] (cosmic-proposed/none) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lammps [amd64] (cosmic-proposed) [0~20180822.gitb47e49223+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [amd64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [armhf] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [ppc64el] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted python-shodan [amd64] (cosmic-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [i386] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [arm64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-heapsize [s390x] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- Unapproved: colobot (cosmic-proposed/universe) [0.1.11.1-2 => 0.1.11.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted colobot [sync] (cosmic-proposed) [0.1.11.1-5]
-queuebot:#ubuntu-release- Unapproved: consul (cosmic-proposed/universe) [1.0.7~dfsg1-5 => 1.0.7~dfsg1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted consul [source] (cosmic-proposed) [1.0.7~dfsg1-5ubuntu1]
<handsome_feng> Hi, Could someone in release team accepted the ubuntukylin-wallpapers in cosmic new queue? Thanks!
-queuebot:#ubuntu-release- Unapproved: libxcb (cosmic-proposed/main) [1.13-3 => 1.13.1-1] (core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: libx11 (cosmic-proposed/main) [2:1.6.6-1 => 2:1.6.7-1] (core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: goxel (cosmic-proposed/universe) [0.8.0-1 => 0.8.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goxel [sync] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (cosmic-proposed) [18.10.1]
<slangasek> handsome_feng: done
<handsome_feng> slangasek: Thanks a lot!
-queuebot:#ubuntu-release- New sync: python-smoke-zephyr (cosmic-proposed/primary) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted python-smoke-zephyr [sync] (cosmic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- Unapproved: zhcon (cosmic-proposed/universe) [1:0.2.6-14 => 1:0.2.6-15] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted zhcon [sync] (cosmic-proposed) [1:0.2.6-15]
-queuebot:#ubuntu-release- Unapproved: restic (cosmic-proposed/universe) [0.9.2+ds-1 => 0.9.2+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted restic [sync] (cosmic-proposed) [0.9.2+ds-2]
-queuebot:#ubuntu-release- Unapproved: ivyplusplus (cosmic-proposed/universe) [1.28-1 => 1.28-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ivyplusplus [sync] (cosmic-proposed) [1.28-2]
-queuebot:#ubuntu-release- Unapproved: aspectj (cosmic-proposed/universe) [1.9.1-1 => 1.9.1+really1.9.0~beta5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted aspectj [source] (cosmic-proposed) [1.9.1+really1.9.0~beta5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: aspectj (cosmic-proposed/universe) [1.9.1-1 => 1.9.1+really1.9.0~beta5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: triplea (cosmic-proposed/universe) [1.9.0.0.7062-1 => 1.9.0.0.7062-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: svnkit (cosmic-proposed/universe) [1.8.14-2 => 1.8.14-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted svnkit [sync] (cosmic-proposed) [1.8.14-3]
-queuebot:#ubuntu-release- Unapproved: accepted triplea [sync] (cosmic-proposed) [1.9.0.0.7062-2]
-queuebot:#ubuntu-release- Unapproved: openjfx (cosmic-proposed/universe) [11+26-1 => 11+26-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (cosmic-proposed) [11+26-3]
-queuebot:#ubuntu-release- Unapproved: libxml-security-java (cosmic-proposed/universe) [2.0.10-1 => 2.0.10-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libxml-security-java [sync] (cosmic-proposed) [2.0.10-2]
-queuebot:#ubuntu-release- Unapproved: cup (cosmic-proposed/universe) [0.11a+20060608-8 => 0.11b-20160615-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cup [sync] (cosmic-proposed) [0.11b-20160615-2]
-queuebot:#ubuntu-release- Unapproved: aircrack-ng (cosmic-proposed/universe) [1:1.3-3 => 1:1.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aircrack-ng [sync] (cosmic-proposed) [1:1.4-1]
-queuebot:#ubuntu-release- Unapproved: network-manager-pptp (cosmic-proposed/main) [1.2.8-1 => 1.2.8-1build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: yaru-theme (cosmic-proposed/main) [18.10.5 => 18.10.6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted accerciser [sync] (cosmic-proposed) [3.22.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-pptp [source] (cosmic-proposed) [1.2.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [sync] (cosmic-proposed) [3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (cosmic-proposed) [142]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (cosmic-proposed/main) [3.30.0-3ubuntu1 => 3.30.1-2ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (cosmic-proposed/main) [1:7-5 => 1:7-5ubuntu1] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> testsuite passes in my local test now ^^
<LocutusOfBorg> wxl, hello, do you think you can fix libfm-qt?
<LocutusOfBorg> if you can... can you please help me in fixing ros-robot-state-publisher in the same way? I don't know that "take logs and update symbols file" approach
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu13 => 0.131ubuntu14] (core)
<xnox> ^ should help the installer to boot splashy splashy in virtualbox
<apw> xnox, ping me when the testing is done
<xnox> apw, well testing is post-boot... unless i re-roll a desktop image for willcooke, or like test stuff myself.
<apw> xnox, oh i thought he was going to test ... ignore me
<Laney> if you want to accept we can respin to test it
<Laney> in that case the other desktoppish things in the queue that I uploaded would be nice ð
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (cosmic-proposed) [0.131ubuntu14]
<xnox> new ubiquity slideshow, new gnome-shell, new netowrk-manager, new yaru-theme would be all nice to respin with
 * xnox can no review =(
<seb128> do we have any reviewer out of L_aney?
<seb128> I already asked yesterday but could someone review/let it the gstreamer update?
<seb128> better earlier than later if we can...
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (cosmic-proposed) [18.10.6]
<apw> seb128, they are huge ugg
<seb128> apw, there are stable GNOME updates which usually are just accepted on the basis that we trust upstream testing and that they are bugfix point releases
<xnox> there is gnome SRU policy thing exception right?!
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (cosmic-proposed) [3.30.1-2ubuntu1]
 * Laney snuggles apw ð¤
<apw> xnox, i see no slideshow and no network-manager ... so i assume laney did those in the past :)
<Laney> gstreamer would be good
<Laney> I'll have to sync gst-libav after those are built because it gets a tight dep
<Laney> and there is a chain of depwait there too, so it will take a while before they can migrate
<xnox> apw, ah, yes.
<Laney> the slideshow was only kubuntu stuff though iirc
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [source] (cosmic-proposed) [1.14.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (cosmic-proposed) [1.14.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [sync] (cosmic-proposed) [1.14.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [source] (cosmic-proposed) [1.14.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (cosmic-proposed) [1.14.4-1]
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu9 => 239-7ubuntu10] (core)
<xnox> Laney, apw - ^ has correct bug # references
-queuebot:#ubuntu-release- Unapproved: bagel (cosmic-proposed/universe) [1.1.1-2build1 => 1.1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bagel [sync] (cosmic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (cosmic-proposed) [239-7ubuntu10]
<apw> ^ rejecting the older duplicate
<tsimonq2> LocutusOfBorg: Uhm, fixed libfm-qt has been in the queue for a while now.
-queuebot:#ubuntu-release- Unapproved: aircrack-ng (cosmic-proposed/universe) [1:1.4-1 => 1:1.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aircrack-ng [sync] (cosmic-proposed) [1:1.4-2]
-queuebot:#ubuntu-release- Unapproved: linux-gcp (cosmic-proposed/main) [4.18.0-1001.2 => 4.18.0-1002.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (cosmic-proposed/main) [4.18.0-1001.2 => 4.18.0-1002.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (cosmic-proposed/main) [4.18.0.1001.1 => 4.18.0.1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (cosmic-proposed/main) [2:2.99.917+git20171229-1build1 => 2:2.99.917+git20180925-2] (desktop-core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: samba (cosmic-proposed/main) [2:4.8.4+dfsg-2ubuntu1 => 2:4.8.4+dfsg-2ubuntu2] (core)
<tsimonq2> Laney: Any chance I could get a review on lubuntu-meta and libfm-qt?
<tsimonq2> (In Cosmic UNAPPROVED)
<Laney> in a bit
<tsimonq2> OK, thanks.
-queuebot:#ubuntu-release- Unapproved: linux-aws (cosmic-proposed/main) [4.18.0-1001.2 => 4.18.0-1002.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (cosmic-proposed/main) [4.18.0.1001.1 => 4.18.0.1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-azure (cosmic-proposed/main) [4.18.0-1002.2 => 4.18.0-1003.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (cosmic-proposed/main) [4.18.0.1002.2 => 4.18.0.1003.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (cosmic-proposed/main) [4.18.0-1002.2 => 4.18.0-1003.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: virt-manager (cosmic-proposed/universe) [1:1.5.1-0ubuntu1 => 1:1.5.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (cosmic-proposed) [1:1.5.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: eog (cosmic-proposed/main) [3.28.3-1 => 3.28.4-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: file-roller (cosmic-proposed/main) [3.30.0-1 => 3.30.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.10-3ubuntu18.04.1 => 5.2.18-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-6ubuntu18.04.1 => 5.2.18-dfsg-2~ubuntu18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu25 => 0.6.5.6-0ubuntu26] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-6ubuntu18.04.1 => 5.2.18-dfsg-3~ubuntu18.04.1] (no packageset)
<fginther> Can someone please promote open-iscsi to -updates on xenial (and bionic) for lp:1791108? Thanks!
<fginther> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1791108
<ubot5> Ubuntu bug 1791108 in open-iscsi (Ubuntu Bionic) "open-iscsi uses domainsearch instead of search for /etc/resolv.conf" [Medium,Fix committed]
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.11-122181-1 => 5.2.18-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: iio-sensor-proxy (cosmic-proposed/main) [2.4-2 => 2.5-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.0-0ubuntu1~18.04.2 => 2:10.3.0-0ubuntu1~18.04.3] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-6ubuntu18.04.1 => 5.2.18-dfsg-3~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-6ubuntu18.04.1 => 5.2.18-dfsg-2~ubuntu18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gnome-weather (cosmic-proposed/universe) [3.26.0-4 => 3.26.0-5] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-photos (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: debian-policy (cosmic-proposed/universe) [4.2.1.1 => 4.2.1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-policy [sync] (cosmic-proposed) [4.2.1.2]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (cosmic-proposed/main) [1:3.30.1-1ubuntu1 => 1:3.30.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: amavisd-new (bionic-proposed/main) [1:2.11.0-1ubuntu1 => 1:2.11.0-1ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: json-glib (cosmic-proposed/main) [1.4.2-4 => 1.4.4-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: plymouth (cosmic-proposed/main) [0.9.3-1ubuntu9 => 0.9.3-1ubuntu9+laney2] (core)
-queuebot:#ubuntu-release- Unapproved: thunderbird (cosmic-proposed/main) [1:52.7.0+build1-0ubuntu1 => 1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: woff2 (cosmic-proposed/main) [1.0.2-1 => 1.0.2-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rhythmbox (cosmic-proposed/main) [3.4.2-4ubuntu1 => 3.4.2-4ubuntu2] (ubuntu-desktop)
<jbicha> please reject aspectj from cosmic queue, something glitched when I uploaded earlier
 * Laney rejects that plymouth too ;-)
-queuebot:#ubuntu-release- Unapproved: rejected aspectj [source] (cosmic-proposed) [1.9.1+really1.9.0~beta5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected plymouth [source] (cosmic-proposed) [0.9.3-1ubuntu9+laney2]
<cyphermox> Laney: out of curiosity, plymouth?
<Laney> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1795637
<ubot5> Ubuntu bug 1795637 in plymouth (Ubuntu Cosmic) "No login screen when booting Cosmic" [High,Triaged]
<cyphermox> ah, yeah
<Laney> it's giving me a hard time :-)
-queuebot:#ubuntu-release- Unapproved: accepted bzr-fastimport [source] (cosmic-proposed) [0.13.0+bzr361-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libfm-qt [source] (cosmic-proposed) [0.13.1-5ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.15]
<xnox> xdg-desktop-portal crashed with SIGSEGV in live-session
<xnox> is that known?
<Laney> yes
<xnox> cool
 * xnox does not send
<Laney> that's a #ubuntu-desktop topic but jamesh was fixing it earlier
-queuebot:#ubuntu-release- Unapproved: jflex (cosmic-proposed/universe) [1.6.1-3 => 1.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jflex [sync] (cosmic-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- Unapproved: gradle-jflex-plugin (cosmic-proposed/universe) [0.0.2-3 => 0.0.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle-jflex-plugin [sync] (cosmic-proposed) [0.0.2-4]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.5]
-queuebot:#ubuntu-release- Unapproved: casper (cosmic-proposed/main) [1.396 => 1.397] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lombok-ast (cosmic-proposed/universe) [0.2+ds-3 => 0.2+ds-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lombok-ast [sync] (cosmic-proposed) [0.2+ds-4]
-queuebot:#ubuntu-release- Unapproved: libquartz2-java (cosmic-proposed/universe) [2.3.0-1 => 2.3.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libquartz2-java [sync] (cosmic-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (bionic-proposed/main) [0.8.8.1 => 0.8.8.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.1 => 1:0.5.2.2] (desktop-core, ubuntu-server)
<xnox> vorlon, https://bugs.launchpad.net/ubuntu/+source/curl3/+bug/1797017
<ubot5> Ubuntu bug 1797017 in curl3 (Ubuntu) "RM superseeded by curl4" [Undecided,Triaged]
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (cosmic-proposed/main) [0.2.38 => 0.2.39] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.37 => 2.408.38] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.38]
-queuebot:#ubuntu-release- Unapproved: lxd (cosmic-proposed/main) [1:0.3 => 1:0.4] (edubuntu, ubuntu-server)
<Laney> apw: you good to review that linux stuff in the queue?
<xnox> hmmmm edubuntu still a thing in launchpad's brain?!
<Laney> it's a packageset
<Laney> I asked the DMB about dropping it some months ago but that didn't happen yet
<vorlon> xnox: replied / marked incomplete
<xnox> vorlon, because you trust outofdate reverse-depends service?!
<vorlon> xnox: I don't trust it, but I expect its results to be reconciled
<xnox> vorlon, where does it run?! cause it's been out of date for ages....
<vorlon> has it?  I haven't noticed it being more than a few hours out of date
<xnox> $ rmadison -S libxmltooling7
<xnox>  libxmltooling7 | 1.6.4-1ubuntu2 | bionic/universe | amd64, arm64, armhf, i386, ppc64el, s390x
<xnox> $ reverse-depends --list src:curl3
<xnox> flashplugin-installer
<xnox> libxmltooling-dev
<xnox> libxmltooling7
<vorlon> indeed, it seems to currently be 7 days out of date
<vorlon> per https://launchpad.net/ubuntu/cosmic/amd64/libxmltooling7
<vorlon> so yes, I use the reverse-depends service, because all other representations of this information are terrible
<xnox> i know, me too
<xnox> but i don't know what to kick
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.1-56-g3aafe77d-0ubuntu1 => 18.1-59-g0f993084-0ubuntu1] (ubuntu-desktop, ubuntu-server)
<vorlon> xnox: tumbleweed
<apw> Laney, sure
<xnox> tumbleweed, anything you ask, to update reverse-depends archive
-queuebot:#ubuntu-release- Unapproved: mokutil (cosmic-proposed/main) [0.3.0+1531796165.cca7219-0ubuntu1 => 0.3.0+1538710437.fb6250f-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (cosmic-proposed) [1:0.4]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (cosmic-proposed) [1.397]
-queuebot:#ubuntu-release- Unapproved: accepted rhythmbox [source] (cosmic-proposed) [3.4.2-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted woff2 [source] (cosmic-proposed) [1.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10]
<tumbleweed> hrm, let me have a look
<tumbleweed> I have noticed a lot of cron mail recently, now that you mention it
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (cosmic-proposed) [1:3.30.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (cosmic-proposed) [2:4.8.4+dfsg-2ubuntu2]
<tumbleweed> IOError: [Errno 28] No space left on device
<tumbleweed> well, duh
-queuebot:#ubuntu-release- Unapproved: vte2.91 (cosmic-proposed/main) [0.54.0-1ubuntu1 => 0.54.1-1ubuntu1] (ubuntu-desktop)
<tumbleweed> xnox: it's running now...
<vorlon> infinity: libreoffice does not need an upload for openjdk-lts 11 for release because this is a test failure and not a runtime failure; so we'll plan to pick it up opportunistically / via SRU.  clojure does need an update for runtime breakage, but this package is not seeded.  so in discussion with tdaitx, the plan is to: 1) skip-badtest current openjdk-lts 11 in -proposed; 2) upload the clojure fix
<vorlon> and make sure it migrates before release; 3) upload openjdk-lts with an added Breaks: against incompatible clojure and opportunistically take it for release (takes minimum 1d to build so won't be ready before final freeze); 4) fix libreoffice test
<vorlon> only image that openjdk is seeded on is kubuntu, so maybe they'd forgive us a respin
 * xnox can test kubuntu
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (cosmic-proposed) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1]
<smoser> anyone able to take a quick look at that curtin upload ? the version in cosmic contains a regression if curtin is told to effectively 'apt-get dist-upgrade' after installation
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.1+git20181009-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<bdmurray> vorlon: Is it expected that Contents.gz would have spaces in file names? e.g. https://pastebin.ubuntu.com/p/HBQ4NQMC2B/
<slangasek> bdmurray: it's not expected that it wouldn't :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (cosmic-proposed/main) [18.10.1 => 18.10.2] (personal-gunnarhj, ubuntu-desktop)
<cyphermox> vorlon: mokutil is in the queue for review ^^
-queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (cosmic-proposed) [0.3.0+1538710437.fb6250f-0ubuntu1]
<vorlon> tsimonq2: looks like you sponsored fuse-umfuse-ext2, which has a lower version in bionic (and cosmic) than in SRUs (version number was 0.4-1.1ubuntu0.1 when it should have been 0.4-1.1ubuntu1).  Can you fix this please?
-queuebot:#ubuntu-release- Unapproved: clamav (cosmic-proposed/main) [0.100.1+dfsg-1ubuntu3 => 0.100.2+dfsg-0ubuntu1] (ubuntu-server)
<mdeslaur> stable releases are getting that clamav update also ^
<vorlon> ginggs: arpack is seeded and I don't see any critical bugs fixed, so I'm rejecting this sync; if there's a reason it's needed, let me know and I'll rescue it
-queuebot:#ubuntu-release- Unapproved: partman-partitioning (cosmic-proposed/main) [120ubuntu1 => 120ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected arpack [sync] (cosmic-proposed) [3.6.3-1]
<ginggs> vorlon: ack, I thought the fix for #908648 would be useful, but it seems igraph needs fixing too
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (cosmic-proposed) [4.18.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (cosmic-proposed) [4.18.0-1005.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (cosmic-proposed) [4.18.0.1003.3]
<tdaitx> vorlon: fix for clojure1.8 at LP: #1796985
<tdaitx> although clojure 1.9 seems to run ok, I can't tell why it does so, it is supposed/expected to be affected as well since the upstream fix is aimed for 1.10 (currently in beta)
<ubot5> Launchpad bug 1796985 in clojure1.8 (Ubuntu) "clojure autopkgtest fails to run with openjdk-11" [High,Confirmed] https://launchpad.net/bugs/1796985
-queuebot:#ubuntu-release- Unapproved: accepted libxcb [sync] (cosmic-proposed) [1.13.1-1]
<vorlon> tdaitx: ok. and openjdk-lts 11~28-3ubuntu1 has migrated
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (cosmic-proposed) [4.18.0-1002.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (cosmic-proposed) [4.18.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (cosmic-proposed) [4.18.0.1005.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (cosmic-proposed) [4.18.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (cosmic-proposed) [4.18.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (cosmic-proposed) [4.18.0.1003.3]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.3 => 237-3ubuntu10.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libx11 [sync] (cosmic-proposed) [2:1.6.7-1]
-queuebot:#ubuntu-release- Unapproved: clojure1.8 (cosmic-proposed/universe) [1.8.0-7 => 1.8.0-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (cosmic-proposed) [4.18.0-1002.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (cosmic-proposed) [4.18.0-1002.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (cosmic-proposed) [4.18.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted clojure1.8 [source] (cosmic-proposed) [1.8.0-7ubuntu1]
<Laney> cyphermox: I am going to upload some cherry picks for plymouth if you want to peruse once it's in the queue
<Laney> there's definitely some bugs here around not releasing DRM devices before wayland/xorg wants to use them
<jbicha> vorlon: please look into hinting git in to cosmic. The snapd/amd64 test did pass for 2.19.0-1ubuntu1 and not much changed in 2.19.1
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (cosmic-proposed) [18.1-59-g0f993084-0ubuntu1]
<vorlon> jbicha: not a priority at the moment, especially as this was the package that I thought should've had an FFe but someone else accepted before I rejected
<jbicha> ok
<vorlon> tjaalton: xserver-xorg-video-intel doesn't look risk-free to me, the upstream snapshot seems to include changes unrelated to any bugs you've identified in the changelog as needing fixing
<ginggs> vorlon: would you consider removing imexam:s390x to help python-scipy migrate? i think the python-scipy i386 autopkgtests can be 'force-badtest'-ed, looks like FP precision
<tjaalton> vorlon: right, it's not used by default on other than very old gpu's, but as you wish
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [source] (cosmic-proposed) [1:7-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libdrm (cosmic-proposed/main) [2.4.94-1 => 2.4.95-1] (core, xorg) (sync)
<tjaalton> vorlon: this one though^ :)
<tjaalton> and if it's possible to consider the vulkan packages in new..
<vorlon> ginggs: the imexam/s390x build failure is itself some sort of fp issue, and s390x is not known for bad fp.  Have you ruled out that this is a regression triggered by python-scipy?
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.1-1ubuntu1] (desktop-core)
<ginggs> vorlon: imexam/s390x is a regression, but no fix seems forthcoming, which is why i'm asking about removal
<vorlon> ginggs: it's a regression, but what caused it? is it caused by the new python-scipy that's blocked in -proposed currently?
<ginggs> vorlon: i think that, or python 3.7
<vorlon> ginggs: the failing test I saw was with python2.7
-queuebot:#ubuntu-release- Unapproved: accepted eog [sync] (cosmic-proposed) [3.28.4-1]
<ginggs> vorlon: hmm, if i read http://autopkgtest.ubuntu.com/packages/i/imexam/cosmic/s390x correctly, the same failure occurred with python-scipy/0.19.1-2ubuntu1
<ginggs> vorlon: actually not, the test on 2018-08-27 22:39:11 UTC shows triggered by python-scipy/0.19.1-2ubuntu1, but the log shows python-scipy/1.1.0-1build1
<ginggs> so assuming the s390x failure was caused by the new python-scipy, is removing imexam on s390x an option?
-queuebot:#ubuntu-release- New sync: barrier (cosmic-proposed/primary) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (cosmic-proposed/universe) [1.14.2-1 => 1.14.4-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (cosmic-proposed/universe) [1.15.0.1+git20180723+db823502-1 => 1.15.0.1+git20180723+db823502-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (cosmic-proposed/universe) [1.14.2-1 => 1.14.4-1] (ubuntustudio) (sync)
<tjaalton> vorlon: since you're removing pkgs, there's also bug 1717998 still for cosmic
<ubot5> bug 1717998 in tomcat8.0 (Ubuntu) "Please remove tomcat8.0 before 18.04 releases" [High,Triaged] https://launchpad.net/bugs/1717998
<vorlon> tjaalton: is it being removed from Debian?
-queuebot:#ubuntu-release- Unapproved: plymouth (cosmic-proposed/main) [0.9.3-1ubuntu9 => 0.9.3-1ubuntu10] (core)
<tjaalton> vorlon: good point, it shoul be yes
<tjaalton> d
<tjaalton> I'll file a bug there..
<vorlon> ginggs: I would not remove the imexam/s390x binary to let a python-scipy that's regressed on s390x migrate, no
<vorlon> mwhudson: ^^ do you know anything about the state of python-scipy on s390x?
<mwhudson> vorlon: no, it's all very confusing :(
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-38.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1023.24] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1002.3] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-38.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1003.3] (kernel)
<vorlon> tjaalton: libdrm> not a review-friendly diff, but accepted now
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (cosmic-proposed) [2.4.95-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1002.3]
<tjaalton> vorlon: cool, thx
<tjaalton> and debian bug 910767 for tomcat8.0 removal filed
<ubot5> Debian bug 910767 in ftp.debian.org "RM: tomcat8.0 -- ROM; not needed anymore" [Normal,Open] http://bugs.debian.org/910767
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [sync] (cosmic-proposed) [0.2.39]
<tsimonq2> vorlon: fuse-umfuse-ext2> Apologies, I'll fix as soon as my desk is reassembled.
<vorlon> that's some serious yak shaving
<tsimonq2> Yeah.
<tsimonq2> Heh.
-queuebot:#ubuntu-release- Unapproved: accepted iio-sensor-proxy [source] (cosmic-proposed) [2.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.10 => 1:18.10.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted file-roller [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-weather [sync] (cosmic-proposed) [3.26.0-5]
<Ukikie> Sorry for the late barrier sync, but Synergy isn't going to be functional in Cosmic, so figured a late sync was worth it.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11~28-3ubuntu1 => 11~28-3ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted json-glib [sync] (cosmic-proposed) [1.4.4-1]
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (cosmic-proposed/universe) [3.30.0-1ubuntu1 => 3.30.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: leiningen-clojure (cosmic-proposed/universe) [2.8.1-7 => 2.8.1-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted leiningen-clojure [source] (cosmic-proposed) [2.8.1-7ubuntu1]
<xnox> vorlon, ^
<xnox> tdaitx, ^
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.2-0ubuntu2 => 3.30.2-0ubuntu3] (ubuntu-desktop)
#ubuntu-release 2018-10-11
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (cosmic-proposed) [11~28-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: trojita (cosmic-proposed/universe) [0.7-0ubuntu1 => 0.7-0ubuntu2] (no packageset)
<tsimonq2> >_>
 * tsimonq2 points at WillMoogle 
<tsimonq2> er
<tsimonq2> I mean, wxl
 * tsimonq2 kicks irssi 
<tsimonq2> calamares-settings-ubuntu is slideshow updates for Lubuntu and installer bugfixes.
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [23 => 24] (lubuntu)
<tsimonq2> So, we found out the hard way that libfm-qt and pcmanfm-qt are so tightly integrated that pcmanfm-qt segfaults if it isn't rebuilt after libfm-qt. No-change rebuild incoming, approval would be appreciated.
<tsimonq2> (Bad upstream is bad.)
-queuebot:#ubuntu-release- Unapproved: pcmanfm-qt (cosmic-proposed/universe) [0.13.0-2ubuntu1 => 0.13.0-2ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: papirus-icon-theme (cosmic-proposed/universe) [20180816-1 => 20181007-1] (lubuntu) (sync)
<tsimonq2> Last minute sync of the Papirus icon theme but it really makes a lot of icons look much, much better. I'd argue ot should go in before release (and it shouldn't require an FFe, it's just icons).
<tsimonq2> vorlon: fuse-umfuse-ext2> . - please help it get through queues.
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (bionic-proposed/universe) [0.4-1.1ubuntu0.1 => 0.4-1.1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (cosmic-proposed/universe) [0.4-1.1ubuntu0.1 => 0.4-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-ext2 [source] (cosmic-proposed) [0.4-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (cosmic-proposed) [18.10.2]
-queuebot:#ubuntu-release- Unapproved: mokutil (cosmic-proposed/main) [0.3.0+1538710437.fb6250f-0ubuntu1 => 0.3.0+1538710437.fb6250f-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-user-docs [source] (cosmic-proposed) [3.30.1+git20181009-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (cosmic-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (bionic-proposed) [4.18.0-1002.2~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-38.41]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1023.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-38.41]
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (cosmic-proposed/universe) [1.4.0.16-1ubuntu1 => 1.4.0.18-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (cosmic-proposed) [1.4.0.18-1]
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.1+git20181009-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<seb128> could someone let thunderbird in cosmic? that's the sort of upload that isn't going to get a full diff review anyway so no point holding because it's difficult to review, just ack it :-)
-queuebot:#ubuntu-release- Unapproved: libgd2 (cosmic-proposed/main) [2.2.5-4ubuntu1 => 2.2.5-4.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: remmina (cosmic-proposed/main) [1.2.31.4+dfsg-1ubuntu1 => 1.2.32+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: zenity (cosmic-proposed/main) [3.28.1-1 => 3.30.0-1] (ubuntu-desktop) (sync)
<Laney> vorlon: did you want to reject the xorg intel driver or not?
<acheronuk> [08:22] <handsome_feng> Hi, I noticed that the seeds of ubuntukylin.cosmic in http://people.canonical.com/~ubuntu-archive/seeds/ didn't updated after I modified the git branch(lp:~ubuntukylin-members/ubuntu-seeds/+git/ubuntukylin), Does anyone know what's the problem? Or what am I missing?
<seb128> Laney, vorlon, note that according to the archive rebuild the current version of that package ftbfs in cosmic (coincidence I was just starting a local build to see if that's still true)
<acheronuk> ^^ from #ubuntu-flavours
<seb128> I'm not saying that the update does resolve the build issue/is the right fix
<seb128> just as a point of info
<acheronuk> could someone perhaps see why those kylin seeds are not updating?
-queuebot:#ubuntu-release- Unapproved: libclc (cosmic-proposed/universe) [0.2.0+git20180917-1 => 0.2.0+git20180917-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libclc [sync] (cosmic-proposed) [0.2.0+git20180917-2]
<seb128> Laney, vorlon, tjaalton, so yeah, current -intel driver ftbfs, the new snapshot from debian fixes the build issue ... not saying it's enough of a reason to accept the sync, but if we don't then we need to fix the build by another upload
<Laney> seb128: ok, well I'll let vorlon weigh that comment
<Laney> 10/10 20:09:01 <vorlon> tjaalton: xserver-xorg-video-intel doesn't look risk-free to me, the upstream snapshot seems to include changes unrelated to any bugs you've identified in the changelog as needing fixing
<Laney> that was the previous remark
<seb128> right, I saw
<Laney> just ftr
<seb128> and Timo pointed out that -intel is not being used on lot of cards nowadays, just on old legacy hardware
<seb128> but yeah, I'm out of that call/decision
<tjaalton> I'll check the build issue
<seb128> I just now the intel ftbfs is on our trello :)
<seb128> tjaalton, https://launchpadlibrarian.net/391448820/buildlog_ubuntu-cosmic-i386.xserver-xorg-video-intel_2%3A2.99.917+git20171229-1build1_BUILDING.txt.gz
<seb128> "../../../src/sna/sna_render_inline.h:40:26: error: inlining failed in call to always_inline âvertex_emit_2sâ: target specific option mismatch"
<tjaalton> latest debian version has a pach for gcc8
<tjaalton> and works
<Laney> :>
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (cosmic-proposed/main) [2:2.99.917+git20171229-1build1 => 2:2.99.917+git20171229-1ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: python-apt (cosmic-proposed/main) [1.7.0~rc1 => 1.7.0] (core) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1023.24~16.04.1] (kernel)
<seb128> tjaalton, thx :) at least the build fix can go in while Steve is pondering what to do with the new snapshot ;)
<tjaalton> it was rejected
<seb128> ah, good
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1023.24~16.04.1]
<Laney> it was left in the queue
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (cosmic-proposed) [24]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (cosmic-proposed) [3.30.1+git20181009-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (cosmic-proposed) [1.14.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted papirus-icon-theme [sync] (cosmic-proposed) [20181007-1]
-queuebot:#ubuntu-release- Unapproved: accepted pcmanfm-qt [source] (cosmic-proposed) [0.13.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted trojita [source] (cosmic-proposed) [0.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (cosmic-proposed) [0.100.2+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (cosmic-proposed) [1.15.0.1+git20180723+db823502-2]
-queuebot:#ubuntu-release- Unapproved: accepted partman-partitioning [source] (cosmic-proposed) [120ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted zenity [sync] (cosmic-proposed) [3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (cosmic-proposed) [1.14.4-1]
-queuebot:#ubuntu-release- Unapproved: rejected libgd2 [sync] (cosmic-proposed) [2.2.5-4.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [source] (cosmic-proposed) [2:2.99.917+git20171229-1ubuntu1]
<Laney> remmina to me feels like it should have had an FFe
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [sync] (cosmic-proposed) [1.7.0]
<Laney> and I'm not sure about u-r-u, I guess mainly because of the late addition of new strings that won't be translated
-queuebot:#ubuntu-release- Unapproved: osinfo-db (cosmic-proposed/universe) [0.20180929-1 => 0.20180929-1ubuntu1] (ubuntugnome)
<Laney> the other three are my uploads and intel is hanging there as discussed above
<Laney> opinions / reviews from other release team members welcome please
-queuebot:#ubuntu-release- Unapproved: accepted osinfo-db [source] (cosmic-proposed) [0.20180929-1ubuntu1]
<seb128> LocutusOfBorg, ^remmina ffe comment, looking a tthe NEWS indeed it was non-bugfix-only changes
<apw> Laney, on u-r-u i am confused why it is not just saying if /var/run/reboot-required.pkgs exists then we should reboot
<apw> Laney, before upgrading ... seems odd to single out only libc6
<apw> Laney, and even if the reasons is only libc, it really ought to use more general language so it doesn't need to be translated again and again
<LocutusOfBorg> seb128, what in particular is your concern? I'm missing what new feature are you referring to
<Laney> apw: Right, I think it might actually be valuable to do it for any reboot-required reason probably.
<Laney> also, shelling out to grep when it could be done in python
<LocutusOfBorg> a new plugin is usually something that doesn't introduce regressions, and new error checks are not exactly new features :)
<seb128> LocutusOfBorg, I'm not r-t member, was just pinging you from L_aney's comment before
<LocutusOfBorg> "Add option to honour https_proxy and http_proxy environment variable." <-- this is what I call "bug fix", not honouring proxy settings in 2018 is... strange
<LocutusOfBorg> oh... got it :)
<Laney> new preferences, allowing wayland again, a new plugin ...
<Laney> come on
<LocutusOfBorg> Laney, feel free to reject it, if you feel like it is not worth the effort
<Laney> I feel like introducing new features should be explicitly tested
<LocutusOfBorg> wayland is only with good enough gtk
<Laney> so, thanks
<Laney> we have that gtk version
<LocutusOfBorg> damn :/ how dumb was my check, against gtk+2 :/
<LocutusOfBorg> "2.24 < 2.27" I seriously need eyeglasses
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (cosmic-proposed) [0.9.3-1ubuntu10]
<Laney> heh
-queuebot:#ubuntu-release- Unapproved: rejected remmina [source] (cosmic-proposed) [1.2.32+dfsg-1ubuntu1]
<LocutusOfBorg> (wayland is not enabled because of control file, but meh)
<LocutusOfBorg> I even went to gtk website to find how was it possible to have 2.27 release after all those years, and I only found a git repo
<apw> Laney, so am i right this gnome-terminal thing is sorting our unified menus ?
<apw> oh just makes it changable back to default
<LocutusOfBorg> can llvm-toolchain-7 be hinted? the autopkgtests are an ongoing effort, for some reasons they passed locally, but I need probably new dependencies, and I don't want to loose all this builders time to have it in cosmic
<Laney> apw: We had a similar thing already, it mainly changes how that works a bit so people can override it if they want
<Laney> the s390x thing is interesting too since we removed gnome-shell there
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (xenial-proposed) [1.2.8-1ubuntu0.1]
<Laney> also, for u-r-u I'll comment on the bug and safety reject it, someone else could fish it out of that queue if they wanted to
<apw> Laney, ack
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (cosmic-proposed) [0.54.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11]
<Laney> https://lists.ubuntu.com/archives/ubuntu-release/2018-October/004614.html
<Laney> why isn't gnome-shell Provides: notification-daemon enough?
<apw> hmmm, does seem odd
-queuebot:#ubuntu-release- New binary: thunderbird [ppc64el] (cosmic-proposed/main) [1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-castellan (cosmic-proposed/main) [0.19.0-0ubuntu1 => 0.19.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: barbican (cosmic-proposed/main) [1:7.0.0-0ubuntu1 => 1:7.0.0-0ubuntu2] (openstack, ubuntu-server)
<jamespage> hi release team - ^^ those two uploads backport a couple of small features that we need to integrate vault with barbican nicely
<jamespage> I've tested and documented in the bug reports
<apw> jamespage, and these don't need an FFe ?
<jamespage> apw: most likely yes
<jamespage> apw: I'll add the minor missing parts to the two feature bug reports
<jamespage> apw: tbh I think I've covered the required parts "testing including, builds (see PPA), installs and upgrades (see testing notes) and does not break packages which depend on it (castellan and barbican covered under same bug)"
<jamespage> documented in bugs explicitly as per FFe requirements, and ubuntu-release subscribed
<jamespage> I've not done one of those for a while...
-queuebot:#ubuntu-release- Unapproved: exim4 (bionic-proposed/main) [4.90.1-1ubuntu1 => 4.90.1-1ubuntu1.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.6 => 2.02-2ubuntu8.7] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.7 => 1.93.8] (core)
-queuebot:#ubuntu-release- New binary: thunderbird [amd64] (cosmic-proposed/main) [1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [i386] (cosmic-proposed/main) [1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [armhf] (cosmic-proposed/main) [1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dds (cosmic-proposed/universe) [2.9.0-3 => 2.9.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dds [sync] (cosmic-proposed) [2.9.0-5]
<cyphermox> hi, whomever promoted shim-signed to bionic-updates, please also promote shim
<cyphermox> (the two must go together)
-queuebot:#ubuntu-release- Unapproved: duplicity (cosmic-proposed/main) [0.7.17-0ubuntu1 => 0.7.17-0ubuntu2] (ubuntu-desktop)
<cyphermox> rbasak: sil2100: ^
<sil2100> Ah, uh
<sil2100> I didn't?!
<apw> not me
<sil2100> Ah, duh
<rbasak> It wasn't me.
<sil2100> cyphermox: apologies for that, it didn't have a bug so my brain missed it
<sil2100> Even though it's completely logical
<TJ-> sil2100: thanks - that'll keep a user happy. Was seeing "shim-signed" in "apt list --upgradeable" but the package wasn't offered for upgrade by apt
<rbasak> smoser had a branch to prevent such accidents. I don't see what happened to it.
<rbasak> https://code.launchpad.net/~smoser/ubuntu-archive-tools/package-sets/+merge/348334
<rbasak> Merged
<cyphermox> I was about to ask about that, should be easy to write a warning to avoid this
<rbasak> Is your ubuntu-archive-tools up to date sil2100?
<rbasak> Ah
<rbasak> shim and shim-signed need adding to the list.
<cyphermox> yup
<sil2100> seb128: hey! I'm going to request a full translation export and then a new base upload - I saw that you mentioned issues with the gnome translations, are you good now in case we do an export soon?
<sil2100> rbasak: I thought mine was
<cyphermox> sil2100: fwiw, not entirely your fault, shim didn't have any bugs linked to it either -- and I'm going to avoid that from now on by requiring a bug prior to any upload of shim to devel
<cyphermox> (since we copy shim across releases, etc.)
<seb128> sil2100, hey, I guess so, dunno who changed those settings but it screwed thing. I think I'm going to fix as much as I plan to do before cosmic, it's tedious work and we are not going to reupload all GNOME now (and import seem fine in most case, it seems the setting didn't change so long ago)
<smoser> yeah, the goal of that branch was that it if you tried to release grub2 without grub2-signed it would exit failure
<smoser> if you had > revision 1180, i'd like to figure out what you did do that didn't trip it.
<sil2100> smoser: it was about shim and shim-signed, apparently that's not added to the list
<sil2100> duh
<smoser> ah. well lets add them.
<smoser> if they do in fact have to be released together.
<smoser> https://code.launchpad.net/~smoser/ubuntu-archive-tools/shim-signed/+merge/356578
<cyphermox> smoser: thanks
<apw> smoser, hmmm, those groups are not series specific, which in fact a number of the sets are
<apw> like linux
<smoser> apw: improvements are welcome.
<smoser> the ones listed there are to my knowledge *not* release specific
<smoser> but you're right there are some such things that are, and thus cannot be modelled by the current implementation
<smoser> but, the current implementation will stop some stable release breakages.
<smoser> and no implementation due to lack of perfection will not.
<apw> linux only works because we only have linux and linux-meta in there; which leaves out the actual kernel in half the series :)
<smoser> i agree that it can/should be improved
<apw> smoser, all true, i'll try and fix it to add series support, and to sync the kernel sets from our tools
<smoser> that woudl be great.
<smoser> there are some tests that i added. you can run the thing as : ./sru-requests run-tests
<smoser> there was no other test suite in any of that, so thats the "just fix my thing" hack-job that i put in
<apw> smoser, ahh that is how you run those
<apw> smoser, i am used to finding a test_sru-release.py to test it, that all looks sensible
<smoser> tox and pycodestyle on those scripts woulc be wonderful.
<smoser> and some sort of enforcement :)
<smoser> but see the hole you go down... thus the hack.
<sil2100> seb128: ok, thanks!
<sil2100> I'll be requesting a new export shortly, still some time left for the languagepack deadline
<seb128> technically the schedule says the freeze is today
<seb128> https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseSchedule states 9pm UTC is the usual time
<seb128> so an export after 9pm sounds like it would be right
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1.2 => 1:9.11.3+dfsg-1ubuntu1.3] (core)
<sil2100> Yeah, will be running it around my EOD
<sil2100> I won't be probably waiting till exact 21 UTC as it's not a hard requirement as far as I know and well, I doubt there's much going on anyway
<sil2100> Since I want to be sure the export finishes around tomorrow before afternoon so that the language-packs are all uploaded and ready for the evening
 * sil2100 is updating now some non-langpack translations
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (cosmic-proposed/main) [3.30.1.2-1ubuntu1 => 3.30.1.2-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-38.41~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-38.41~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (cosmic-proposed/main) [142 => 143] (kubuntu, ubuntu-desktop)
<vorlon> Laney: xorg intel> well, I wasn't rejecting it outright, but I wasn't planning to accept it
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-38.41~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-38.41~16.04.1]
<Laney> haha
-queuebot:#ubuntu-release- New binary: thunderbird [arm64] (cosmic-proposed/main) [1:60.2.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (cosmic-proposed/main) [1:7-5ubuntu1 => 1:7-5ubuntu2] (kubuntu, ubuntu-desktop)
<vorlon> acheronuk, handsome_feng: the seeds mirror isn't updating because the script that does the mirroring expects all the source branches to be there and errors out if any have gone missing, and doesn't notify us.  Because lubuntu is aggressive about removing branches for unsupported releases, it was falling over due to artful EOL and I've updated lp:ubuntu-archive-scripts for this.  It looks like there
<vorlon> are still other failures that I'm looking into.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.8]
<vorlon> darkxst: please move all ubuntu-gnome seed branches for supported releases to git, instead of straddling git+bzr.  (trusty is missing from https://code.launchpad.net/~ubuntu-gnome-dev/ubuntu-seeds/+git/ubuntu-gnome and I will need to disable it from the mirror script)
<vorlon> darkxst: also, there was a missed step in switching to git, you didn't raise an MP against lp:ubuntu-archive-scripts for the change :)
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (bionic-proposed/universe) [3.28.0-1ubuntu1.2 => 3.28.0-1ubuntu1.3] (edubuntu)
<acheronuk> vorlon: thanks for looking into that.
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.4-5-g6ee8a2c5-0ubuntu1 => 18.4-7-g4652b196-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.7 => 2.02-2ubuntu8.7] (core)
<vorlon> acheronuk, handsome_feng: seed mirror updated
<sil2100> infinity: I requested the export now, a few hours earlier before the LanguagePackTranslationDeadline but I'd like to be sure that we have the langpacks built tomorrow
-queuebot:#ubuntu-release- Unapproved: gdm3 (cosmic-proposed/main) [3.30.1-1ubuntu1 => 3.30.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [18.4-7-g4652b196-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (cosmic-proposed) [3.30.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (cosmic-proposed) [143]
-queuebot:#ubuntu-release- Unapproved: accepted duplicity [source] (cosmic-proposed) [0.7.17-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (cosmic-proposed) [3.30.1.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.7 => 2.02-2ubuntu8.7] (core)
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (cosmic-proposed/main) [1.8.6-1 => 1.8.6-1ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: liferea (cosmic-proposed/universe) [1.12.4-1 => 1.12.5-2] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted liferea [sync] (cosmic-proposed) [1.12.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (cosmic-proposed) [1:7.0.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-castellan [source] (cosmic-proposed) [0.19.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openvpn [sync] (cosmic-proposed) [1.8.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-builder (cosmic-proposed/universe) [3.30.1-2ubuntu2 => 3.30.1-6ubuntu1] (desktop-extra)
<jbicha> sil2100: oh, I missed your message that you were intending to do the langpack build early
<jbicha> that's why I did the gnome-builder upload ^ since upstream added new strings post-3.30.1 :(
<jbicha> if we don't plan on doing langpack SRUs for non-lts releases, maybe we shouldn't use language packs for gnome-builder
<jbicha> maybe not for epiphany-browser either
-queuebot:#ubuntu-release- New source: biometric-authentication (cosmic-proposed/primary) [0.9.57-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (cosmic-proposed/universe) [2.2.8-0ubuntu1 => 3.0.0-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (cosmic-proposed/universe) [1.0.1-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin)
<jbicha> and we should probably opt webkit2gtk out of langpacks too
-queuebot:#ubuntu-release- Unapproved: comic-neue (cosmic-proposed/multiverse) [2.3-4 => 2.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted comic-neue [sync] (cosmic-proposed) [2.4-1]
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (cosmic-proposed/main) [2.22.2-1ubuntu1 => 2.22.2-1ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: insubstantial (cosmic-proposed/universe) [7.3+dfsg3-3 => 7.3+dfsg3-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: lwjgl (cosmic-proposed/universe) [2.9.3+dfsg-3 => 2.9.3+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted insubstantial [sync] (cosmic-proposed) [7.3+dfsg3-4]
-queuebot:#ubuntu-release- Unapproved: accepted lwjgl [sync] (cosmic-proposed) [2.9.3+dfsg-4]
-queuebot:#ubuntu-release- New binary: eclipse-platform-ui [amd64] (cosmic-proposed/universe) [4.7.3-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: javatools (cosmic-proposed/universe) [0.66 => 0.70] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted javatools [sync] (cosmic-proposed) [0.70]
-queuebot:#ubuntu-release- Unapproved: gdm3 (cosmic-proposed/main) [3.30.1-1ubuntu2 => 3.30.1-1ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (cosmic-proposed/universe) [3.30.1-1ubuntu1 => 3.30.1-1ubuntu2] (desktop-extra)
<jbicha> the builder string addition is minor enough I think I'll just let us keep using langpacks
<jbicha> but we might do new major releases of epiphany as SRUs (as we already do for webkit) so those should be opted out
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.10 => 1:18.10.11] (core)
-queuebot:#ubuntu-release- Unapproved: mokutil (bionic-proposed/main) [0.3.0-0ubuntu5 => 0.3.0+1538710437.fb6250f-0ubuntu2~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: paramiko (cosmic-proposed/main) [2.4.1-0ubuntu2 => 2.4.1-0ubuntu3] (edubuntu, ubuntu-server)
<cyphermox> vorlon: grub2 has binaries in unapproved for bionic, could you please review them?
<infinity> cyphermox: I got you.
<cyphermox> infinity: ya
<cyphermox> *ta
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: apport (cosmic-proposed/main) [2.20.10-0ubuntu11 => 2.20.10-0ubuntu12] (core)
<sil2100> jbicha: well, the export didn't happen yet, so maybe you made it in time?
<sil2100> But it will start soonish since there's someone on it right now
<jbicha> sil2100: could you accept gnome-builder/cosmic now then?
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (cosmic-proposed) [3.30.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (cosmic-proposed) [2.22.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (cosmic-proposed) [3.30.1-6ubuntu1]
<jbicha> thanks
<sil2100> It was probably infinity
<sil2100> I was too slow
<sil2100> ;)
<infinity> Nope.  I blame vorlon.
<jbicha> thanks team!
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (cosmic-proposed) [2.20.10-0ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted paramiko [source] (cosmic-proposed) [2.4.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (cosmic-proposed) [3.30.1-1ubuntu2]
<vorlon> infinity: I haven't touched anything in the past hour
-queuebot:#ubuntu-release- New: accepted thunderbird [amd64] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [armhf] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [ppc64el] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [arm64] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [i386] (cosmic-proposed) [1:60.2.1+build1-0ubuntu1]
<infinity> vorlon: Heh.
<vorlon> so, you know, invisible queue processors, no big deal
-queuebot:#ubuntu-release- New: accepted barrier [sync] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fonts-fork-awesome [sync] (cosmic-proposed) [1.1.2+ds3-3]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [sync] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [amd64] (cosmic-proposed) [4.7.3-2]
-queuebot:#ubuntu-release- New: accepted r-cran-popepi [sync] (cosmic-proposed) [0.4.5-1]
<infinity> Probably Laney then.  Or ghosts.
<stgraber> wasn't me
<infinity> We're all so good at not taking credit, though.  Look at us go.
<infinity> tjaalton: Tell me stories about these Vulkan things in NEW and why I should care.
-queuebot:#ubuntu-release- New binary: barrier [s390x] (cosmic-proposed/none) [2.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [s390x] (cosmic-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [ppc64el] (cosmic-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: barrier [ppc64el] (cosmic-proposed/none) [2.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [i386] (cosmic-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [amd64] (cosmic-proposed/none) [1.3-1] (no packageset)
<tjaalton> infinity: upstream split the old repo in four (vulkan-headers, -loader, -tools, -validationlayers), so the packaging had to follow. -headers is in already, but I've merged it back to -loader (made no sense to split it) so once these are in -headers can be removed
-queuebot:#ubuntu-release- New binary: r-cran-popepi [amd64] (cosmic-proposed/none) [0.4.5-1] (no packageset)
<infinity> tjaalton: Oh, this is a split of something already in the archive?
<infinity> (and what is that something?)
<tjaalton> infinity: old src:vulkan also embedded spirv and glslang for the layers build, but these have been packaged properly now
<tjaalton> yes, src:vulkan
<tjaalton> spirv-tools is needed by -validationlayers
<tjaalton> also in new
<infinity> tjaalton: Is this split in Debian NEW too?
<tjaalton> yes
<infinity> Ahh, for a month or so, I see.  WTB pet Debian ftpmaster to process that.
-queuebot:#ubuntu-release- New binary: barrier [i386] (cosmic-proposed/universe) [2.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [armhf] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-xslt [arm64] (cosmic-proposed/universe) [1.3-1] (no packageset)
<tjaalton> spirv-tools is even older
<tjaalton> 4mo
-queuebot:#ubuntu-release- New binary: barrier [amd64] (cosmic-proposed/universe) [2.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: barrier [armhf] (cosmic-proposed/universe) [2.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: barrier [arm64] (cosmic-proposed/universe) [2.1.2+dfsg-1] (no packageset)
<infinity> tjaalton: Any ABI transitions or anything hidden in here, or is this just the split plus upstream bugfixes etc?
<tjaalton> infinity: no, just the split and a new release
<infinity> Kay.
<tjaalton> some packaging bikesheds, since upstream calls the utils repo -tools, so it got renamed
-queuebot:#ubuntu-release- New binary: eclipse-platform-text [amd64] (cosmic-proposed/universe) [4.7.3-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apport (cosmic-proposed/main) [2.20.10-0ubuntu12 => 2.20.10-0ubuntu13] (core)
-queuebot:#ubuntu-release- Unapproved: coreutils (cosmic-proposed/main) [8.28-1ubuntu1 => 8.28-1ubuntu2] (core)
<tsimonq2> infinity: Topic change in here?
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.1, Cosmic Beta | Archive: Final Freeze | Cosmic 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.
<bashfulrobot> tsimonq2: Only you./... ð
<jbicha> please remove the gdm3/s390x binaries. It should be the last gjs removal for cosmic. Sorry about that.
#ubuntu-release 2018-10-12
-queuebot:#ubuntu-release- New sync: fontcustom (cosmic-proposed/primary) [2.0.0+ds4-5]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu6 => 2.02+dfsg1-5ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: snappy-java (cosmic-proposed/universe) [1.1.7.1+dfsg-1 => 1.1.7.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnucash (cosmic-proposed/universe) [1:3.2-1ubuntu4 => 1:3.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnucash [sync] (cosmic-proposed) [1:3.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted snappy-java [sync] (cosmic-proposed) [1.1.7.2-1]
-queuebot:#ubuntu-release- Unapproved: maven-shared-utils (cosmic-proposed/universe) [3.2.1-1 => 3.3.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-shared-utils [sync] (cosmic-proposed) [3.3.0-1]
<tsimonq2> bashfulrobot: hah
<tsimonq2> "It doesn't count if there's no topic change, amirite?"
-queuebot:#ubuntu-release- Unapproved: qdox2 (cosmic-proposed/universe) [2.0~M9-1 => 2.0~M9-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qdox2 [sync] (cosmic-proposed) [2.0~M9-2]
-queuebot:#ubuntu-release- Unapproved: libmiglayout-java (cosmic-proposed/universe) [5.1-1 => 5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libsejda-eventstudio-java (cosmic-proposed/universe) [1.0.6-1 => 1.0.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libmiglayout-java [sync] (cosmic-proposed) [5.1-2]
-queuebot:#ubuntu-release- Unapproved: mariadb-connector-java (cosmic-proposed/universe) [2.2.5-1 => 2.3.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libsejda-eventstudio-java [sync] (cosmic-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- Unapproved: golang-github-thejerf-suture (cosmic-proposed/universe) [2.0.3-1 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-thejerf-suture [sync] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-connector-java [sync] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- Unapproved: libitext5-java (cosmic-proposed/universe) [5.5.6-4 => 5.5.13-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libitext5-java [sync] (cosmic-proposed) [5.5.13-1]
-queuebot:#ubuntu-release- Unapproved: jcodings (cosmic-proposed/universe) [1.0.30-2 => 1.0.40-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jcodings [sync] (cosmic-proposed) [1.0.40-3]
-queuebot:#ubuntu-release- Unapproved: intellij-annotations (cosmic-proposed/universe) [12.0-1 => 16.0.2-3] (no packageset) (sync)
<handsome_feng> vorlon, acheronuk: Thanks! :)
-queuebot:#ubuntu-release- Unapproved: accepted intellij-annotations [sync] (cosmic-proposed) [16.0.2-3]
-queuebot:#ubuntu-release- Unapproved: aspectj-maven-plugin (cosmic-proposed/universe) [1.10-1 => 1.11-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aspectj-maven-plugin [sync] (cosmic-proposed) [1.11-1]
-queuebot:#ubuntu-release- Unapproved: eclipse-debian-helper (cosmic-proposed/universe) [1.1 => 1.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eclipse-debian-helper [sync] (cosmic-proposed) [1.3]
-queuebot:#ubuntu-release- Unapproved: jruby-joni (cosmic-proposed/universe) [2.1.18-1 => 2.1.23-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jruby-joni [sync] (cosmic-proposed) [2.1.23-1]
-queuebot:#ubuntu-release- Unapproved: hbci4java (cosmic-proposed/universe) [3.0.19+dfsg-2 => 3.0.20+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hbci4java [sync] (cosmic-proposed) [3.0.20+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.6 => 1:2.11+dfsg-1ubuntu7.7] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: krita (cosmic-proposed/universe) [1:4.1.3+dfsg-1 => 1:4.1.5+dfsg-1] (kubuntu) (sync)
<acheronuk> krita sync ^^^. would very much like that bugfix release in as there are a lot of fixes (note 4.1.3 -> 4.1.5 as they corrected a regression in 4.1.4 with a few hrs with a new release). if too late, then SRU fodder
<acheronuk> also depending on builder/arch, krita can take ~4 hrs to build, so that may bear on acceptance/respin
-queuebot:#ubuntu-release- Unapproved: trilinos (cosmic-proposed/universe) [12.12.1-5build2 => 12.12.1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted trilinos [source] (cosmic-proposed) [12.12.1-5ubuntu1]
 * sil2100 kicks off new language-packs
<sil2100> New language-packs on their way to the queue
<sil2100> (this will take a while)
<Laney> pack those langs
<sil2100> I already sanity checked a few of them before upload, but I'll double check and then approve them all
<sil2100> Yay for self approvals!
<sil2100> Laney: or maybe you want to do the approving?
<Laney> sil2100: feel free, it's really only a script that made those anyway
<sil2100> Ok, accepting!
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (cosmic-proposed/universe) [1.0.1-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.10 => 1:18.10.11] (core)
<darkxst> vorlon, ubuntu gnome had promised 3 years support for trusty, that make its unsupported in my mind, but can bring the seed across to git if that helps
<darkxst> vorlon, I will follow up with a MP for xenial, just been a crazy couple of weeks, moving home again
-queuebot:#ubuntu-release- Unapproved: shim-signed (cosmic-proposed/main) [1.37 => 1.38] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu553 => 20101020ubuntu554] (core)
<xnox> sil2100, Laney - kernel got unblocked yesterday and is a valid candidate, this is matching d-i rebuild. ^ please accept
-queuebot:#ubuntu-release- Unapproved: cloudcompare (cosmic-proposed/universe) [2.9.1+git20180223-1build1 => 2.9.1+git20180223-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cloudcompare [sync] (cosmic-proposed) [2.9.1+git20180223-2]
-queuebot:#ubuntu-release- Unapproved: colmap (cosmic-proposed/universe) [3.4-2 => 3.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted colmap [sync] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- Unapproved: protracker (cosmic-proposed/universe) [2.3d.r134-1 => 2.3d.r140-1] (no packageset) (sync)
<sil2100> xnox: looking
-queuebot:#ubuntu-release- Unapproved: accepted protracker [sync] (cosmic-proposed) [2.3d.r140-1]
<sil2100> xnox: so the kernel still didn't migrate?
-queuebot:#ubuntu-release- Unapproved: modplugtools (cosmic-proposed/universe) [0.5.3-2 => 0.5.3-3] (no packageset) (sync)
<xnox> sil2100, needs d-i rebuild, given the abi encoding d-i-udebs package.
-queuebot:#ubuntu-release- Unapproved: accepted modplugtools [sync] (cosmic-proposed) [0.5.3-3]
<xnox> sil2100, it's a valid candidate, awaiting d-i rebuild.
<sil2100> Yeah, see it there
<sil2100> In output
<sil2100> (accepted)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu554]
-queuebot:#ubuntu-release- Unapproved: ballerburg (cosmic-proposed/universe) [1.2.0-2 => 1.2.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ballerburg [sync] (cosmic-proposed) [1.2.0-3]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (cosmic-proposed/main) [2.541 => 2.542] (desktop-core)
<sil2100> ^ livecd-rootfs with changes required for enabling core18 builds
<sil2100> Those changes are unrelated to regular ubuntu, touching only a code path executed for ubuntu-image built images
-queuebot:#ubuntu-release- New binary: colmap [ppc64el] (cosmic-proposed/universe) [3.5-1] (no packageset)
<sil2100> Would appreciate it getting accepted since we'd like to build dailes for this flavor
-queuebot:#ubuntu-release- New binary: colmap [s390x] (cosmic-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: colmap [amd64] (cosmic-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (cosmic-proposed/main) [1.0.2-1 => 1.0.2-1ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: colmap [i386] (cosmic-proposed/universe) [3.5-1] (no packageset)
<sil2100> Laney, infinity, vorlon, apw: can I request one of you to check the livecd-rootfs in the cosmic queue?
<sil2100> I'd like to get that moving for core18
<cyphermox> anyone on the release team want to review a quick FFe? (adding HTTP support to grub, I just need to add the module to the prebuilt grub image for UEFI) https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1787630
<ubot5> Ubuntu bug 1787630 in grub2 (Ubuntu) "[FFe] Include HTTP support in pre-build GRUB module" [High,New]
<cyphermox> I reviewed the code for the module, looks sane.
-queuebot:#ubuntu-release- Unapproved: elinks (cosmic-proposed/universe) [0.12~pre6-13 => 0.12~pre6-13ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted elinks [source] (cosmic-proposed) [0.12~pre6-13ubuntu1]
<sil2100> Why so late?!
<xnox> cyphermox, ooooh that is so nice!
<xnox> sil2100, i think that goes hand in hard with maas beta; and i guess we will be SRUing that in, anyway.
 * xnox does gnutls28 FFe
<Laney> cyphermox: does that *have* to be in the release or could it be SRUed?
<cyphermox> so late because I couldn't get to it before; reviewing this takes a while to begin with and it's low on priority -- I just happened to be reminded of it yesterday
<cyphermox> it could be SRUed; usually I try to land features in release (even if late) rather than via SRU
<cyphermox> OTOH, this isn't so much a feature as allowing it to be used in Secure Boot
<cyphermox> (grub already has had the code for a while, we already build it, etc; but the module isn't included, and you can't load external modules in SB mode)
<cyphermox> I leave it up to the release team to decide if they feel it better go in as SRU :)
<Laney> I think it'd get better testing and not pose any risk to the release if it were to be SRUed
<Laney> personally
<Laney> sil2100: ?
<sil2100> I'd also prefer not to have new features right now
<Laney> thanks, seems we are in agreement
<Laney> do you want to comment?
<sil2100> Yeah, I can
<Laney> ð¤
<bdmurray> Could somebody comment on my ubuntu-release-upgrader upload? Its fine as an SRU for cosmic.
<cyphermox> Laney: sil2100: thanks!
-queuebot:#ubuntu-release- Unapproved: linux-meta (cosmic-proposed/main) [4.18.0.9.10 => 4.18.0.10.11] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (cosmic-proposed/main) [4.18.0-9.10 => 4.18.0-10.11] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (cosmic-proposed/main) [4.18.0-9.10 => 4.18.0-10.11] (core, kernel) (sync)
<vorlon> darkxst: oh, ubuntu-gnome wasn't a 5y LTS, fair enough!  then no changes needed; I've already adjusted the update-seeds script (as it falls over when any seeds are wrong and affects other flavors)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu6 => 2.02+dfsg1-5ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (cosmic-proposed/main) [1.108 => 1.109] (core)
<cyphermox> sil2100: Laney: seb128: grub2 / grub2-signed with timeout fix ^ careful, there's an older grub2 upload in cosmic queue.
<seb128> cyphermox, great,t hx
<sil2100> Looking
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (cosmic-proposed) [1.109]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu7]
<bdmurray> sil2100: Could you have a look at my u-r-u upload for cosmic? It can be a 0-day SRU, I just would like to know if its okay if I upload a bionic SRU.
<sil2100> bdmurray: on it
<sil2100> bdmurray: ouch, too bad this introduces a new string, we're past translation deadlines
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu7 => 2.02+dfsg1-5ubuntu7] (core)
<sil2100> I'm not really much knowledgable about the procedures, not sure if this won't require an UIFe? Maybe I'm wrong
<sil2100> Let me try reading a bit more into that
<sil2100> Anyway, I'd like to have both of the changes in cosmic if possible
<sil2100> Ah, yes, I see your rationale for the untranslated strings
<sil2100> I personally think that new strings aren't that big of a deal as modified strings
<sil2100> Since we anyway never block on applications not being translated, so this wouldn't be a blocker anyway
<bdmurray> L_aney had suggested emailing the translations team to get it fixed in bionic sometime as an SRU
<bdmurray> Which I'm happy to do
<sil2100> So I'd be happy accepting this, I think this is valuable enough for cosmic - and the erorr message now is nice and generic
<sil2100> Laney: would you be very angry if I accepted u-r-u from the queue?
<bdmurray> sil2100: it won't do anything if its accepted now vs a 0-day SRU. It really needs fixing in Bionic.
<Laney> not if you judge it to be acceptable to the release :-)
<bdmurray> sil2100: oh, actually the demotions and mirror update would be good
<sil2100> Laney: your concerns have been addressed, so let me accept it
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu7]
-queuebot:#ubuntu-release- Unapproved: rust-phf-shared (cosmic-proposed/universe) [0.7.23-1 => 0.7.23-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rust-phf-shared [sync] (cosmic-proposed) [0.7.23-2]
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [24 => 25] (lubuntu)
<wxl> lubuntu has a pretty crucial bug fix in calamares-settings-ubuntu 25 if we could get that approved right quick please (it's currently breaking installs)
<sil2100> wxl: looking
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (cosmic-proposed) [25]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu7 => 2.02+dfsg1-5ubuntu7] (core)
<sil2100> wxl: ^
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu7]
-queuebot:#ubuntu-release- New source: ukui-biometric-auth (cosmic-proposed/primary) [1.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New source: ukui-biometric-manager (cosmic-proposed/primary) [1.0.0-1ubuntu1]
<sil2100> infinity, vorlon: if you have a moment, please review livecd-rootfs in the cosmic queue - thanks!
-queuebot:#ubuntu-release- Unapproved: lximage-qt (cosmic-proposed/universe) [0.7.0-2build1 => 0.7.0-2build2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: lxqt-qtplugin (cosmic-proposed/universe) [0.13.0-0ubuntu4 => 0.13.0-0ubuntu5] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (cosmic-proposed) [1.38]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (cosmic-proposed) [2.20.10-0ubuntu13]
<wxl> thanks sil2100 (even though you're not here)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (cosmic-proposed) [4.18.0.10.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (cosmic-proposed) [4.18.0-10.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (cosmic-proposed) [4.18.0-10.11]
<tsimonq2> infinity, vorlon: Upstream also decided to tightly knit lximage-qt and lxqt-qtplugin with libfm-qt.
<tsimonq2> Accept the no-change rebuilds there?
-queuebot:#ubuntu-release- Unapproved: accepted coreutils [source] (cosmic-proposed) [8.28-1ubuntu2]
<infinity> tsimonq2: Already done.
<tsimonq2> Thanks.
-queuebot:#ubuntu-release- Unapproved: accepted lximage-qt [source] (cosmic-proposed) [0.7.0-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-qtplugin [source] (cosmic-proposed) [0.13.0-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal [source] (cosmic-proposed) [1.0.2-1ubuntu1]
<infinity> LocutusOfBorg: Your changelog for llvm says "ignore i386 failing test", but the code change looks more like "remove the test entirely from all arches"...
-queuebot:#ubuntu-release- Unapproved: accepted kylin-display-switch [source] (cosmic-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected indicator-china-weather [source] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted krita [sync] (cosmic-proposed) [1:4.1.5+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: bison (cosmic-proposed/main) [2:3.0.4.dfsg-1build1 => 2:3.0.4.dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.26 => 1:18.04.27] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted colmap [i386] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-10.11]
-queuebot:#ubuntu-release- New: accepted barrier [amd64] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted barrier [armhf] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted barrier [ppc64el] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted colmap [amd64] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted colmap [s390x] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-popepi [amd64] (cosmic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [arm64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [i386] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [s390x] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted barrier [arm64] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted barrier [s390x] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-text [amd64] (cosmic-proposed) [4.7.3-3]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [armhf] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted barrier [i386] (cosmic-proposed) [2.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted colmap [ppc64el] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-xslt [ppc64el] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- Unapproved: m4 (cosmic-proposed/main) [1.4.18-1 => 1.4.18-1ubuntu1] (core)
<smoser> can someone reject the curtin uploads in the xenial and bionic queue ? they have a bug (bug 1796968)
<ubot5> bug 1796968 in curtin "attempt to call string 'run_apt_upgrade' when testing proposed" [High,Fix committed] https://launchpad.net/bugs/1796968
<smoser> we will shortly upload a newer version
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.1-17-gae48e86f-0ubuntu1~16.04.1 => 18.1-59-g0f993084-0ubuntu1~16.04.1] (ubuntu-server)
<smoser> and there it is ^ with another coming for bionic. please reject the 18.1-56 versions to both.
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.1-17-gae48e86f-0ubuntu1~18.04.1 => 18.1-59-g0f993084-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
<vorlon> smoser: done
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (xenial-proposed) [18.1-56-g3aafe77d-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (bionic-proposed) [18.1-56-g3aafe77d-0ubuntu1~18.04.1]
<smoser> gracias
-queuebot:#ubuntu-release- Unapproved: accepted syslinux [source] (bionic-proposed) [3:6.03+dfsg1-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: gzip (cosmic-proposed/main) [1.6-5ubuntu1 => 1.6-5ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bison [source] (cosmic-proposed) [2:3.0.4.dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted m4 [source] (cosmic-proposed) [1.4.18-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gzip [source] (cosmic-proposed) [1.6-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnutls28 (cosmic-proposed/main) [3.5.19-1ubuntu1 => 3.6.4-2ubuntu1] (core) (sync)
<xnox> vorlon, since you are up - https://bileto.ubuntu.com/excuses/3470/cosmic.html is the gnutls28 above. all green. it has TLSv1.3 support. Not sure if we care though.
<xnox> it would up our TLSv1.3 coverage by at most 50 packages in main; and 207 package sin universe. openssl is obviously the biggest one.
<infinity> xnox: And it's just the gnutls28 sync in the queue, nothing needs rebuilding?
<xnox> infinity, correct.
<xnox> infinity, it even works right against tls1.3 nginx and a few other apps i've test-checked without rebuilding.
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [sync] (cosmic-proposed) [3.6.4-2ubuntu1]
<xnox> did not have enough time to do nss 3.39, but security team they do wholesome nss updates anyway... so it might land as a security update.
#ubuntu-release 2018-10-13
-queuebot:#ubuntu-release- Unapproved: flatpak (cosmic-proposed/universe) [1.0.3-1 => 1.0.4-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (cosmic-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (bionic-proposed) [2.9.2-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.6]
<acheronuk> hi release team. I have a LP: #1797643 cropped up, which is pretty sever for Kubuntu
<ubot5> Launchpad bug 1797643 in akonadi (Ubuntu) "akonadi fails to start for fresh user/install in Cosmic" [High,Confirmed] https://launchpad.net/bugs/1797643
<acheronuk> installing Bionic packages works, so I'm going to try a git bisect on upstream sources
<acheronuk> s/sever/severe
<infinity> acheronuk: Good thing we haven't released yet, then.
<acheronuk> infinity: yeah. looks like some changes to an apparmor profile shipped by akonadi might be needed
-queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu554 => 20101020ubuntu555] (core)
-queuebot:#ubuntu-release- New: accepted spirv-tools [source] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [source] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-loader [source] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [source] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fontcustom [sync] (cosmic-proposed) [2.0.0+ds4-5]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu555]
-queuebot:#ubuntu-release- New binary: fontcustom [amd64] (cosmic-proposed/universe) [2.0.0+ds4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-tools [s390x] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-tools [ppc64el] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-tools [amd64] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-tools [i386] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
<acheronuk> infinity: when are you planning RC spins?
-queuebot:#ubuntu-release- New binary: spirv-tools [arm64] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-tools [armhf] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
<infinity> acheronuk: First ones in the morning, but they'll be intentionally not the last.
<acheronuk> infinity: ok. test building a fix short. timewise, my main concern was that akonadi triggers a lot of tests of rdeps, but maybe should not be too bad with empty queues and fairly likely respins anyway
<acheronuk> thanks
<acheronuk> *shortly
-queuebot:#ubuntu-release- Unapproved: akonadi (cosmic-proposed/universe) [4:18.04.3-0ubuntu1 => 4:18.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: vulkan-tools [ppc64el] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-tools [s390x] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-tools [arm64] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-tools [i386] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-tools [armhf] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-tools [amd64] (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: equinox-framework (cosmic-proposed/universe) [4.7.3-4 => 4.7.3-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted equinox-framework [sync] (cosmic-proposed) [4.7.3-5]
-queuebot:#ubuntu-release- Unapproved: gscan2pdf (cosmic-proposed/universe) [2.1.6-1 => 2.1.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gscan2pdf [sync] (cosmic-proposed) [2.1.7-1]
<jbicha> please remove the gdm3/s390x binaries (needed as part of the gjs/s390x removal)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (cosmic-proposed) [4:18.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted fontcustom [amd64] (cosmic-proposed) [2.0.0+ds4-5]
-queuebot:#ubuntu-release- New: accepted spirv-tools [arm64] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-tools [i386] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-tools [s390x] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [arm64] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [i386] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [s390x] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-tools [amd64] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-tools [ppc64el] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [armhf] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-tools [armhf] (cosmic-proposed) [2018.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [ppc64el] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-tools [amd64] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: fonts-fork-awesome [amd64] (cosmic-proposed/universe) [1.1.2+ds3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [s390x] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [amd64] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [ppc64el] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [armhf] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [arm64] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-validationlayers [i386] (cosmic-proposed/universe) [1.1.82.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oregano (cosmic-proposed/universe) [0.70-3ubuntu2 => 0.84.40+dfsg.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted oregano [sync] (cosmic-proposed) [0.84.40+dfsg.1-1]
<tsimonq2> infinity: Lubuntu will also need one last Calamares settings package and we should be set.
<tsimonq2> Otherwise we are going to look at 0-day SRUing qtwebkit-opensource-src and libreoffice.
<tsimonq2> Oh, and the Cala change also needs a casper upload.
<tsimonq2> I plan on preparing that within the hour, assuming I can find some desk space. :P
-queuebot:#ubuntu-release- New sync: anbox (cosmic-proposed/primary) [0.0~git20180821-1]
<jbicha> ^ anbox should work now with Ubuntu's lxc
<tsimonq2> infinity: Assuming nobody finds anything else, those two packages I just uploaded should be it for stuff to get on the Lubuntu ISO before release.
<tsimonq2> So, huzzah.
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [25 => 26] (lubuntu)
<tsimonq2> It's just renaming the Calamares .desktop file to something sane and then using casper magic to make it a trusted executable, instead of doing horrible, hacky things with /etc/skel.
-queuebot:#ubuntu-release- Unapproved: casper (cosmic-proposed/main) [1.397 => 1.398] (desktop-core, ubuntu-server)
<infinity> tsimonq2: Explain the efi change to me.
<infinity> tsimonq2: Or, rather, explain why you fixed it wrong. :)
<infinity> tsimonq2: You want "if grep -q foo; then"
<infinity> tsimonq2: The part where it's wrapped in a subshell and then in a test is why it's going all weird for you, and the "fix" is relying on the string return evaluating true, which is vaguely undefined.
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (cosmic-proposed) [1.398]
-queuebot:#ubuntu-release- New: accepted anbox [sync] (cosmic-proposed) [0.0~git20180821-1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [amd64] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [armhf] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [ppc64el] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-fork-awesome [amd64] (cosmic-proposed) [1.1.2+ds3-3]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [i386] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [arm64] (cosmic-proposed) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [s390x] (cosmic-proposed) [1.1.82.0-0ubuntu1]
<tsimonq2> infinity: You're correct there, and I relied on "wxl
<tsimonq2> *"wxl's bash knowledge is much better than mine".
<tsimonq2> infinity: I'll patch that up and run it through a VM, thanks.
-queuebot:#ubuntu-release- New binary: anbox [amd64] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
<infinity> tsimonq2: Easily mockable (to remind yourself of correct syntax) with something like:
<infinity> if grep -q bogomips /proc/cpuinfo; then echo "I love bogomips."; fi
<tsimonq2> Heh.
-queuebot:#ubuntu-release- New binary: anbox [arm64] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
-queuebot:#ubuntu-release- New binary: anbox [armhf] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted anbox [amd64] (cosmic-proposed) [0.0~git20180821-1]
-queuebot:#ubuntu-release- New: accepted anbox [armhf] (cosmic-proposed) [0.0~git20180821-1]
-queuebot:#ubuntu-release- New: accepted anbox [arm64] (cosmic-proposed) [0.0~git20180821-1]
<tsimonq2> infinity: So, like this? "        -    command: apt install -y --no-upgrade -o Acquire::gpgv::Options::=--ignore-time-conflict grub-efi-$(if grep 64 /sys/firmware/efi/fw_platform_size; then echo amd64-signed; else echo ia32; fi)"
<infinity> tsimonq2: grep -q
<infinity> tsimonq2: 'if' is checking the return code, not the output.  You want to toss the output.
<tsimonq2> infinity: "        -    command: apt install -y --no-upgrade -o Acquire::gpgv::Options::=--ignore-time-conflict grub-efi-$(if grep -q 64 /sys/firmware/efi/fw_platform_size; then echo amd64-signed; else echo ia32; fi)"
<tsimonq2> That?
<infinity> tsimonq2: Yup.
<tsimonq2> Cool.
<infinity> tsimonq2: The reason it didn't work before was because it was wrapped in a test (and, for some odd reason, a subshell), so the test was testing the output of "grep -q ..." to see if it was true.  The output was null, which is false.
<infinity> tsimonq2: It got "fixed" when you dropped the -q, but that was now testing if "garbage string with 64 in it" was "true", which is undefined, and a big maybe.
<tsimonq2> infinity: Right.
<tsimonq2> infinity: So, unless my clipboard is whack, that follow-up upload should be good?
<tsimonq2> (Er, the one currently dput'ting.)
<infinity> Seems likely.
<infinity> I'll know when I see it. :P
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [25 => 26] (lubuntu)
<tsimonq2> Theeere it is.
-queuebot:#ubuntu-release- Unapproved: rejected calamares-settings-ubuntu [source] (cosmic-proposed) [26]
<infinity> LGTM.
<tsimonq2> Awesome.
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (cosmic-proposed) [26]
<infinity> tsimonq2: If you're ever mildly confused about [] in shell, remember it's just prettier shorthand for "test", and "help test" will tell you all about it.
<tsimonq2> Cool, thanks.
<infinity> ie: 'if [ "$foo" = "cat" ]; ...' is the same as 'if test "$foo" = "cat"; ...'
<infinity> But the former is about 1000 times more readable.
<tsimonq2> Heh, true.
<jbicha> the only one of the apps in LP: #1771025 that even *runs* for me in cosmic is bareftp ð­
<ubot5> Launchpad bug 1771025 in tomboy-latex (Ubuntu) "Please remove gnome-sharp2 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1771025
 * jbicha looks suspiciously at ncurses
-queuebot:#ubuntu-release- Unapproved: anbox (cosmic-proposed/multiverse) [0.0~git20180821-1 => 0.0~git20180915-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted anbox [sync] (cosmic-proposed) [0.0~git20180915-1]
<xnox> infinity, not sure if we care to upload nss with tls1.3 as well or not. the biggest win would have been chromium-browser, but that one clamps down tlsv1.3 to the draft versions only and thus does not gain final v1.3. and openjdk-8|lts execute no adt tests at all it seems. and libreoffice `regression` is observed in cosmic-release at the moment anyway.
<xnox> https://bileto.ubuntu.com/excuses/3479/cosmic.html
<xnox> will land into unapproved, but i have no strong feelings if we should or should not take it.
<infinity> xnox: I'd say no.
<infinity> xnox: cosmic isn't an LTS, there's plenty of time to fix this in DD.
<xnox> ack
<xnox> and testing is unconvincing.
<xnox> plus e.g. firefox/google-chrome embed their own nss anyway, and that will get v1.3 via usual code-drops anyway.
<infinity> Right.
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Cosmic Final] (20101020ubuntu555) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Cosmic Final] (20101020ubuntu555) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Cosmic Final] (20101020ubuntu555) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Cosmic Final] (20101020ubuntu555) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Cosmic Final] (20101020ubuntu555) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Cosmic Final] (20101020ubuntu555) has been added
<infinity> tsimonq2: Still doing lubuntu i386 for final?
<tsimonq2> infinity: Yup.
<tsimonq2> infinity: I believe Xubuntu is also still doing i386, too. :P
<infinity> tsimonq2: Figured.
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> We have testers, so I'm not complaining, really.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Cosmic Final] (20181013.1) has been added
<infinity> tsimonq2: I'd like to see the last two i386 ISOs die so people stop installing with i386 so they don't expect an upgrade path if/when we drop it.
<infinity> tsimonq2: I mean, it's going to suck regardless, but the earlier we tear off the band-aid, the better.
<infinity> tsimonq2: (But don't read that as me pressuring you to drop the ISO, I don't care deeply enough to bother doing that)
<infinity> tsimonq2: I've pressed The Button to rebuild $world (and sent a mail about it).  If you don't see some images by late tonight, please do annoy people (ie: vorlon) about missing stuff.
<tsimonq2> infinity: Can you say for certain that archive support (i.e. package builds) will be gone before 20.04 is released?
<tsimonq2> infinity: Sure, if you say so. :P
<infinity> tsimonq2: I can't.  That's still up in the air, and the decision isn't being taken until next year (not my call, I'd have dropped it the day after 18.04 released if we'd had my way :P)
<tsimonq2> infinity: (If I had it my way it would have been gone at the same time, but other team members and the community have grabbed pitchforks, so I've taken a "you test and support it, you can have it" approach. :P)
<infinity> Guess I'm boarding in a few minutes.  Time to pack up the laptop.
<tsimonq2> Have fun.
<infinity> See you on the flipside.
<tsimonq2> (If airplanes can be fun?)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Cosmic Final] (20181013.1) has been added
<jbicha> the mono app issue isn't as bad as it first looked; only problem now is mono doesn't build LP: #1797727
<ubot5> Launchpad bug 1797727 in mono (Ubuntu) "ncurses in cosmic breaks running many Mono apps from terminal" [High,Triaged] https://launchpad.net/bugs/1797727
#ubuntu-release 2018-10-14
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Cosmic Final] (20181013.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Cosmic Final] (20181013) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Cosmic Final] (20181013) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Cosmic Final] (20181013) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Cosmic Final] (20181013) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Cosmic Final] (20181013) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Cosmic Final] (20181014) has been added
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.0-1ubuntu2] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: libgxps (cosmic-proposed/main) [0.3.0-2 => 0.3.0-3] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: xwallpaper (cosmic-proposed/universe) [0.3.0-2 => 0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xwallpaper [source] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: xwallpaper [amd64] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xwallpaper [ppc64el] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xwallpaper [arm64] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xwallpaper [s390x] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xwallpaper [armhf] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xwallpaper [i386] (cosmic-proposed/universe) [0.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (cosmic-proposed) [3.30.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libgxps [sync] (cosmic-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted xwallpaper [amd64] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted xwallpaper [armhf] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted xwallpaper [ppc64el] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted xwallpaper [arm64] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted xwallpaper [s390x] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted xwallpaper [i386] (cosmic-proposed) [0.3.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-panel (cosmic-proposed/universe) [1:3.30.0-1ubuntu1 => 1:3.30.0-1ubuntu2] (desktop-extra, edubuntu, ubuntu-budgie)
<flocculant> infinity: any reason you know of why upgrading bionic to cosmic would decide to replace nouveau with nvidia? because it did ...
-queuebot:#ubuntu-release- Unapproved: sssd (cosmic-proposed/main) [1.16.3-1ubuntu1 => 1.16.3-1ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
<jbicha> ugh, sssd isn't 3.0 (quilt)
-queuebot:#ubuntu-release- Unapproved: sssd (cosmic-proposed/main) [1.16.3-1ubuntu1 => 1.16.3-1ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: wireshark (cosmic-proposed/universe) [2.6.3-1 => 2.6.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wireshark [sync] (cosmic-proposed) [2.6.4-1]
<infinity> trying: gnutls28
<infinity> skipped: gnutls28 (0, 3, 4)
<infinity>     got: 14+0: a-2:a-2:a-2:i-1:p-2:s-5
<infinity>     * amd64: mandos
<infinity> xnox: ^ what'd you do?
<infinity> Wait, no.  What on earth did the mandos maintainer do? :P
-queuebot:#ubuntu-release- Unapproved: vulkan-tools (cosmic-proposed/universe) [1.1.82.0+dfsg1-0ubuntu1 => 1.1.82.0+dfsg1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vulkan-tools [source] (cosmic-proposed) [1.1.82.0+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mandos (cosmic-proposed/universe) [1.7.20-1 => 1.7.20-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mandos [source] (cosmic-proposed) [1.7.20-1ubuntu1]
<infinity> flocculant: Do you have logs of the upgrade?  That doesn't sound like a thing that *could* happen.
<infinity> flocculant: Unless you mean you had both installed before upgrade, but had manually selected nouveau, and that config change went away?
<infinity> flocculant: Cause there's no way an upgrade would have gone and installed some non-free drivers for you.
<xnox> infinity, http://autopkgtest.ubuntu.com/packages/gnutls28 and http://autopkgtest.ubuntu.com/packages/gnutls28/cosmic/amd64 look as if we lost clound, and state as to what was successful or not?!
<xnox> cause there is like only one run there from 13th of october
<xnox> which cannot be true....
<xnox> infinity, also mandos looks very odd
<xnox> oh
<xnox> infinity, https://paste.ubuntu.com/p/hSpmGBPbYT/
<xnox> fun fact, ctype-OPENPGPG got removed in 3.6+ without changing api/abi. However, if one specifies it in the requested algos string, the whole thing fails with invalid request.
<xnox> so i think we actually need to patch mandos to remove '[+-]CTYPE-OPENPGP' everywhere.
<xnox> wait no
<xnox> "SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP:!RSA" -> means it really needs pre 3.6 gnutls28
<xnox> no normal certs; only openpgp certs.
<xnox> =(
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879538
<ubot5> Debian bug 879538 in mandos "mandos: (tries to) use GnuTLS OpenPGP support" [Normal,Open]
<xnox> or like vendorise gnutls inside mandos...
<xnox> feck
<xnox> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=deprecated-gnutls-3.6&user=ametzler%40bebt.de -> elinks is fixed for us.
-queuebot:#ubuntu-release- Unapproved: filezilla (cosmic-proposed/universe) [3.33.0-1 => 3.33.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted filezilla [source] (cosmic-proposed) [3.33.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ekg2 (cosmic-proposed/universe) [1:0.4~pre+20120506.1-15 => 1:0.4~pre+20120506.1-15ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ekg2 [source] (cosmic-proposed) [1:0.4~pre+20120506.1-15ubuntu1]
-queuebot:#ubuntu-release- Unapproved: echoping (cosmic-proposed/universe) [6.0.2-10 => 6.0.2-10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted echoping [source] (cosmic-proposed) [6.0.2-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: courier (cosmic-proposed/universe) [0.78.0-2ubuntu2 => 0.78.0-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted courier [source] (cosmic-proposed) [0.78.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: probert (cosmic-proposed/universe) [0.0.14.1build3 => 0.0.14.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted probert [source] (cosmic-proposed) [0.0.14.2]
<xnox> mwhudson, i guess i don't want to know what meth keywords are
<mwhudson> xnox: https://docs.python.org/3/c-api/structures.html#c.PyMethodDef
<xnox> yeah, was reading it.
<xnox> it is short for method
<xnox> clever.... i guess
<mwhudson> xnox: the worst part is that i fixed this in git a year ago
<mwhudson> it's a total violation of the c standard! but oh well
-queuebot:#ubuntu-release- Unapproved: probert (bionic-proposed/universe) [0.0.14.1build2 => 0.0.14.1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sweethome3d-furniture (cosmic-proposed/universe) [1.6.3-1 => 1.6.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d-furniture [sync] (cosmic-proposed) [1.6.4-1]
-queuebot:#ubuntu-release- Unapproved: sweethome3d-furniture-editor (cosmic-proposed/universe) [1.22-1 => 1.23-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d-furniture-editor [sync] (cosmic-proposed) [1.23-1]
-queuebot:#ubuntu-release- Unapproved: fonts-fork-awesome (cosmic-proposed/universe) [1.1.2+ds3-3 => 1.1.3+ds1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fonts-fork-awesome [sync] (cosmic-proposed) [1.1.3+ds1-1]
-queuebot:#ubuntu-release- Unapproved: libjlatexmath-java (cosmic-proposed/universe) [1.0.7-1 => 1.0.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjlatexmath-java [sync] (cosmic-proposed) [1.0.7-2]
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (cosmic-proposed/universe) [0.9.9-2 => 0.9.12-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-subtitles (cosmic-proposed/universe) [1.4-1 => 1.4.1-1] (cli-mono) (sync)
-queuebot:#ubuntu-release- Unapproved: regexxer (cosmic-proposed/universe) [0.10-3 => 0.10-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted regexxer [sync] (cosmic-proposed) [0.10-4]
-queuebot:#ubuntu-release- Unapproved: dh-golang (bionic-proposed/main) [1.34.1 => 1.34.2] (core)
#ubuntu-release 2019-10-07
-queuebot:#ubuntu-release- Unapproved: marco (eoan-proposed/universe) [1.22.3-0ubuntu1 => 1.22.3-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-themes (eoan-proposed/universe) [3.22.20-1 => 3.22.20.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (eoan-proposed/universe) [19.10.9 => 19.10.10] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: libproxy (eoan-proposed/main) [0.4.15-5 => 0.4.15-7] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: blitz++ (eoan-proposed/universe) [1:1.0.1+ds-5ubuntu1 => 1:1.0.1+ds-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: checkinstall (eoan-proposed/universe) [1.6.2+git20170426.d24a630-1ubuntu1 => 1.6.2+git20170426.d24a630-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rxtx [source] (bionic-proposed) [2.2pre2+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: iputils (eoan-proposed/main) [3:20190709-1 => 3:20190709-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-1ubuntu1] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (eoan-proposed) [2.7.1-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted intel-graphics-compiler [source] (eoan-proposed) [1.0.2652-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted inkscape [sync] (eoan-proposed) [0.92.4-4]
-queuebot:#ubuntu-release- Unapproved: accepted python-meshio [sync] (eoan-proposed) [3.1.6-1]
-queuebot:#ubuntu-release- Unapproved: totem (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted krita [sync] (eoan-proposed) [1:4.2.7.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (eoan-proposed/main) [1:3.34.0-1ubuntu1 => 1:3.34.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (eoan-proposed) [0.196]
-queuebot:#ubuntu-release- Unapproved: accepted marco [source] (eoan-proposed) [1.22.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-session-manager [source] (eoan-proposed) [1.22.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (eoan-proposed) [3.22.20.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (eoan-proposed) [19.10.10]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-initial-setup [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (eoan-proposed/main) [1:15.0.0~rc1-0ubuntu1 => 1:15.0.0~rc1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libpeas (eoan-proposed/main) [1.24.0-2 => 1.24.0-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-1ubuntu1] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.41+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.41]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (bionic-proposed) [5.3.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (xenial-proposed) [3.20.4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.2-1ubuntu1 => 1.20.4-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: linux-azure (eoan-proposed/main) [5.0.0-1018.19 => 5.3.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (eoan-proposed/main) [5.0.0.1018.17 => 5.3.0.1002.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (eoan-proposed/main) [5.0.0-1018.19 => 5.3.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.422 => 1.423] (desktop-core, ubuntu-server)
<mwhudson> xnox: if you want to upload your casper changes, please combine with ^
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (eoan-proposed/main) [11.0.5+6-1ubuntu2 => 11.0.5+9-1ubuntu1] (core)
<xnox> mwhudson:  ack
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (eoan-proposed/universe) [2.0.3-0ubuntu1 => 2.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (eoan-proposed) [11.0.5+9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (disco-proposed/main) [0.131ubuntu19.1 => 0.131ubuntu19.2] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.8 => 0.130ubuntu3.9] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.15 => 0.122ubuntu8.16] (core)
-queuebot:#ubuntu-release- Unapproved: command-not-found (eoan-proposed/main) [18.10.0~pre2 => 19.10.0] (core)
-queuebot:#ubuntu-release- Unapproved: fswatch (eoan-proposed/universe) [1.14.0+repack-9ubuntu1 => 1.14.0+repack-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (eoan-proposed/main) [3.24.11-1ubuntu1 => 3.24.12-1ubuntu1] (ubuntu-desktop)
<juliank> the command-not-found diff looks a bit big, but that's because I deleted all the Commands files from cosmic that we no longer use!
-queuebot:#ubuntu-release- Unapproved: accepted checkinstall [source] (eoan-proposed) [1.6.2+git20170426.d24a630-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (eoan-proposed) [1:3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted totem [source] (eoan-proposed) [3.34.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glib-networking [sync] (eoan-proposed) [2.62.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libproxy [sync] (eoan-proposed) [0.4.15-7]
<Laney> xnox: you providing a new casper?
<Laney> I want to reject that one because there's a weird #boot# file in there
<Laney> editor backup or something
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.423]
<Laney> was just wondering if I should fix it up or if there's a followup coming already then I wouldn't bother
<xnox> Laney:  i do have an approved merege proposal.
<xnox> Laney:  which i can incorproate and upload.
<xnox> Laney:  let me give you a url
-queuebot:#ubuntu-release- Unapproved: gnome-session (eoan-proposed/main) [3.33.92-1ubuntu1 => 3.34.1-1ubuntu1] (ubuntu-desktop)
<xnox> Laney:  https://code.launchpad.net/~xnox/ubuntu/+source/casper/+git/casper/+merge/373691
<xnox> Laney:  if you will be happy accepting above change too, then yeah i can prepare jumbo upload.
<Laney> looks acceptable to me
<Laney> well, fix those spelling comments first :-)
<xnox> yaas
<Laney> does this actually improve the shutdown situation?
<Laney> the smoke test has still been a bit flappy, not sure if you saw that
<xnox> Laney:  did not see smoke test results. It does improve boot & shutdown for subiquity and desktop. At the moment, there are systemd errors generated, which switches systemd into spew garbage to screen mode and one cannot see clearly "please remove installation medium" message on server image.
<Laney> xnox: ok, well maybe check them out
<Laney> we got one green one on oct 6th but otherwise red red red
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.422 => 1.423] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (eoan-proposed/universe) [2.0.7-1 => 2.0.9-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: gnome-keyring (eoan-proposed/main) [3.31.91-1ubuntu3 => 3.34.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted nvme-cli [source] (bionic-proposed) [1.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libgdata (eoan-proposed/main) [0.17.11-3 => 0.17.11-3build1] (ubuntu-desktop)
<seb128> Laney, ^ that's the 'unset proxy' solution which works, I used a build1 number since I commited to Debian as well, that way it autosync again next cycle without having to do manual work
<xnox> Laney:  new casper is in the queue
<Laney> k00l
<Laney> seb128: 'uhttpmock' ;-)
<seb128> Laney, DOH :p
<seb128> Laney, I'm fixing in Debian, I can reupload there as wlel if you want
<Laney> nah, that's OK for the next upload
<seb128> thx
<Laney> xnox: how is this unit actually installed?
<xnox> $ grep system debian/casper.install
<xnox> systemd/*.service               usr/lib/systemd/system
<xnox> arguabily it should be lib/systemd/system; but casper is only used on fresh media, which is usr-merged.
<Laney> but the directory is called system/
<xnox> har har
<Laney> and it's a .mount unit
<Laney> ...
<xnox> clearly i only tested it by live hacking the installer =)
<xnox> from break=bottom
<Laney> ð¤¦
<xnox> -rw-r--r-- root/root      1345 2019-10-07 12:06 ./lib/systemd/system/cdrom.mount
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.422 => 1.423] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keyring [source] (eoan-proposed) [3.34.0-1ubuntu1]
<Laney> why's this better than installing into /run via script like we do for snapd things?
-queuebot:#ubuntu-release- Unapproved: accepted libgdata [source] (eoan-proposed) [0.17.11-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (eoan-proposed) [3.24.12-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.423]
<xnox> Laney:  there is nothing dynamic about it. and it needs to enforce ordering with casper.service.
<xnox> and it's inert if cdrom.mount doesn't exist.
<xnox> (not pulled in by default)
<xnox> Laney:  longer term, if/when we split filesystem.squashfs & installer.squashfs on the desktop too, we should do most things simply in place. Rather than writing scripts, that run in initrd, to create files on the fly in ram.
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1058.67] (kernel)
<xnox> Laney:  not sure if queuebot notices, but fixed up casper is in the queue again (for the install file)
<Laney> 07/10 14:31:43 -queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.422 => 1.423] (desktop-core, ubuntu-server)
<xnox> ah, it did.
<xnox> sorry, never mind me
<Laney> :>
<Laney> give me a minute, just getting ubiquity in
<Laney> xnox: this unit is started automatically somehow?
<xnox> Laney:  yes, systemd reads mountinfo, and tries to load the matching .mount unit. If it can't find any it synthesises "a default" looking .mount unit, which for us doesn't work (it is attempted to be unmounted prior to caster & prior to /, whilst / is in fact depends on /cdrom)
-queuebot:#ubuntu-release- Unapproved: nautilus (eoan-proposed/main) [1:3.34.0-1ubuntu1 => 1:3.34.1-1ubuntu1] (ubuntu-desktop)
<xnox> Laney:  on your system you can check the output of $ systemctl list-units *.mount
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1058.67]
<xnox> can like cat vs show those units, to see which ones of them are "magic"
<Laney> xnox: ok, so it loads them as active automagically or something
<Laney> that's what I wanted to know thanks
<Laney> , thanks
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.423]
<xnox> Laney:  yeap. loaded and active, and then tries to reconcile reality. (ie. stock .mount has BindsTo=$what and then if the $what is stopped, it instantly tries to stop cdrom.mount etc etc)
<Laney> makes sense
-queuebot:#ubuntu-release- Unapproved: ukui-indicators (eoan-proposed/universe) [1.1.5-1 => 1.1.7-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: rygel (eoan-proposed/main) [0.38.1-2ubuntu2 => 0.38.1-2ubuntu3] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.6-1 => 1.25.7-0ubuntu1] (desktop-core, ubuntu-server)
<juliank> I'll re-upload c-n-f with some quotes around apt update
<juliank> and so I did.
-queuebot:#ubuntu-release- Unapproved: command-not-found (eoan-proposed/main) [18.10.0~pre2 => 19.10.0] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (eoan-proposed/main) [1:3.34.0.1-1ubuntu2 => 1:3.34.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Packageset: Added linux-meta-oracle to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-oracle to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-aws to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-azure to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-gcp to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-oracle to kernel in eoan
-queuebot:#ubuntu-release- Packageset: Added linux-signed-oracle to kernel in eoan
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-oracle (eoan-proposed/primary) [5.3.0-1001.1]
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle (eoan-proposed/main) [5.0.0.1003.28 => 5.3.0.1001.1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-oracle (eoan-proposed/main) [5.0.0-1003.4 => 5.3.0-1001.1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (eoan-proposed/main) [5.0.0-1003.4 => 5.3.0-1001.1] (core, kernel) (sync)
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-aws (eoan-proposed/primary) [5.3.0-1002.2+1]
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-azure (eoan-proposed/primary) [5.3.0-1002.2]
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-gcp (eoan-proposed/primary) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-aws to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-azure to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-gcp to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-oracle to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-meta-oracle to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-oracle to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-aws to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-azure to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-gcp to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-oracle to kernel in disco
-queuebot:#ubuntu-release- Packageset: Added linux-signed-oracle to kernel in disco
-queuebot:#ubuntu-release- Unapproved: gdm3 (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (eoan-proposed/main) [20101020ubuntu590 => 20101020ubuntu591] (core)
<sforshee> autopkgtest seems broken, a number of packages fail with "ERROR: erroneous package: rules extract failed with exit code 1"
<sforshee> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/b/bbswitch/20191007_151043_a3514@/log.gz
<sforshee> hmm, this looks suspicious - https://salsa.debian.org/ci-team/autopkgtest/commit/020ec6285a836d20ab799742649712f7224d61c8
<sforshee> ddstreet: ^
<Laney> doh
<Laney> vorlon or another admin: feel free to revert that if that seems like the best option
<sforshee> ddstreet: if (foundarch == 0 || archmatch == 1) thissrc[\\$1] = 1; ... I don't think that condition is possible. The regex which sets foundarch=1 is always going to match when the regex which sets archmatch=1 matches, no?
<ddstreet> sforshee no foundarch is set only when it finds any 'arch=' entry
<ddstreet> archmatch is set only when 'arch=...' has an entry matching the current arch, or all or any
<sforshee> +      if (\\$k ~ /^arch=/) foundarch=1;
<sforshee> +      if (\\$k ~ /^arch=(.*,)?(all|any|%(arch)s)(,.*)?\\$/) archmatch=1; }
<sforshee> how does the second match without also matching the first?
<ddstreet> if the second matches the first will as well
<sforshee> right, so you cannot have foundarch==0 && archmatch==1, right?
<ddstreet> that's why i used || not &&
<sforshee> d'oh, /me cannot read
<ddstreet> :)
<ddstreet> so the change breaks linux pkg tests?  that's not good, tho :-/
<ddstreet> oh, bbcache
<ddstreet> sforshee are other pkgs failing as well?
<sforshee> ddstreet: yeah, so far I've noticed bbswitch and kpatch, though there are others I suspect have the same issue
<sforshee> systemd
<ddstreet> systemd?  that's not good
<sforshee> ok, those are the only three I see affecting the linux package at least
<sforshee> ddstreet: so extract the awk script and run the output from "apt-cache showsrc --only-source bbswitch" through it, you get nothing
<sforshee> revert the changes and do the same and you get package names
<ddstreet> sforshee baaaaahh why is the arch=linux-any
<ddstreet> wtf kind of arch is that
<ddstreet> sigh
<sforshee> although reverting doesn't do anything for systemd
<ddstreet> same problem arch=linux-any
<ddstreet> for systemd
<ddstreet> Laney i think we'll need a autopkgtest patch to also check for arch=linux-any, i can open up a debian bug real quick for that
<ddstreet> i wonder if there are more surprise archs though
<infinity> ddstreet: dpkg has a tool for this instead of reinventing it with regexes.
<ddstreet> infinity what's the tool?
<ddstreet> dpkg-architecture?
<infinity> https://paste.ubuntu.com/p/Zqf8t8bSNc/
<infinity> It doesn't match for 'all', you'll have to special case that, but it'll get all the wildcards.
<infinity> Including ones you might not have thought of, like any-amd64 and linux-amd64
<ddstreet> i'm not sure an awk script can callout to another script, though
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1023.24~18.04.1] (kernel)
<ddstreet> yeah i was just going to add - as a valid delimiter
<ddstreet> but really, i want to completely replace this entire awk script
<ddstreet> but not right now
<infinity> You can fudge it for Ubuntu, where everything is linux-* anyway, but that would be Very Wrong for Debian.
<infinity> So, anything but using full dpkg logic is inappropriate for upstream.
<infinity> As well as for us as a downstream, consuming source packages that have binaries for, say, kfreebsd-amd64 or hurd-i386.
<ddstreet> yeah i'll add - as a another value delimiter (as well as ,) and use dpkg-architecture callout when replacing the awk script
<ddstreet> ugh, awk has system() it seems...guess that could be used
<cjwatson> Converting awk scripts to perl is pretty trivial
<cjwatson> As a starting point
<ddstreet> yeah but this is run in the testbed, i'm not sure perl is there
<infinity> As a side note, that would also make autopkgtest depend on dpkg-dev if it doesn't already.  (does this code run on the testbed, or server-side?)
<ddstreet> i'd prefer python myself
<cjwatson> ddstreet: That would be pretty astonishing since perl is Essential (and python isn't)
<infinity> ddstreet: perl's much more likely to be there than python. :P
<cjwatson> (Well, perl-base.  So steer clear of most modules.)
<ddstreet> i'm not sold on perl yet, but we'll see :)
<infinity> Ahh, autopkgtest runs dpkg-source in the testbed, so dpkg-dev is there.
<ddstreet> Laney sforshee infinity cjwatson i opened https://salsa.debian.org/ci-team/autopkgtest/merge_requests/64
<gitbot> Debian CI issue (Merge request) 64 in autopkgtest "autopkgtest: when checking binary pkg arch, allow *-$ARCH-* values also" [Opened]
<infinity> ddstreet: That will match kfreebsd-{any,amd64} on linux-amd64 and hurd-i386 on linux-i386 and maybe also any-amd64 on, say, armhf.  Those are all examples in the archive, though I'm not sure how many also have tests.
 * infinity shuts off his laptop and runs off to catch a plane.
-queuebot:#ubuntu-release- Unapproved: placement (eoan-proposed/universe) [2.0.0~rc1-0ubuntu1 => 2.0.0~rc1-0ubuntu2] (no packageset)
<blackboxsw> bdmurray: hi, I just verified your update-notifier-common SRU for trusty https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1842508
<ubot5> Launchpad bug 1842508 in update-notifier (Ubuntu Trusty) "motd messaging changes regarding apt updates" [Medium,Fix committed]
<blackboxsw> bdmurray: and cloud-init also has a fully verified SRU for xenial, bionic and disco per https://bugs.launchpad.net/cloud-init/+bug/1846535
<ubot5> Launchpad bug 1846535 in cloud-init "cloud-init 19.2.36 fails with python exception "Not all expected physical devices present ..." during bionic image deployment from MAAS" [Critical,Fix committed]
<blackboxsw> bdmurray: if there is time for either, they are 'ready for final SRU review/upload'
<bdmurray> blackboxsw: thanks, I'll see what I can do if I get out of these meetings ;-)
<Odd_Bloke> bdmurray: To be clear, that cloud-init update is a fix for a substantial regression in the previous SRU, so should take priority. :)
<blackboxsw> yes sorry, cloud-init above update-notifier-common (thought I expect bdmurray has a vested interest in both because he authored the update-notifier changes I think :) )
<bdmurray> blackboxsw: yes, I care about that deeply
<bdmurray> ;-)
<Odd_Bloke> All the more reason to tell him that cloud-init is more important then. ;)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1023.24~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1021.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (eoan-proposed/main) [3.34.0-1 => 3.34.1-1] (desktop-extra, ubuntu-desktop) (sync)
<bdmurray> Odd_Bloke: so because cloud-init is fixing a regression the 7 day waiting period should be waived?
<blackboxsw> bdmurray: I believe yes in this case, We only pulled in a cherry pick specifically to fix a known regression on that release and tested the heck out of it on all affected platforms
<blackboxsw> Odd_Bloke: concerns with that ^ ?
<blackboxsw> rharper: too ^
<rharper> blackboxsw: no concerns;
<mwhudson> Laney, xnox: thanks for fixing up my casper #boot# thing
<mwhudson> at least with non-native packages dpkg-source pokes you in the eye if you do that sort of thing
<mwhudson> eh i guess it wouldn't in debian/tests
<Odd_Bloke> bdmurray: Please!
-queuebot:#ubuntu-release- Unapproved: texinfo (eoan-proposed/main) [6.6.0.dfsg.1-2ubuntu1 => 6.6.0.dfsg.1-2ubuntu2] (core)
<mwhudson> blah the casper test fails on i386 because linux-image is uninstallable?
<mwhudson> i guess i can change the test dep to linux-image-generic:amd64
<mwhudson> (on i386 only)
<mwhudson> https://paste.ubuntu.com/p/5mbRPhgM7R/ <- will this work? worth uploading or easier to just badtest casper/i386 for now?
-queuebot:#ubuntu-release- Unapproved: rejected iraf [source] (eoan-proposed) [2.16.1+2018.11.01-2build2]
<vorlon> mwhudson: badtest casper/i386 in perpetuity (done)
-queuebot:#ubuntu-release- Unapproved: rejected fswatch [sync] (eoan-proposed) [1.14.0+repack-12]
<mwhudson> vorlon: i guess we could stop building it there ...
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (eoan-proposed) [1:15.0.0~rc1-0ubuntu2]
<mwhudson> (it's not like we make any install media for i386 any more)
<vorlon> mwhudson: there aren't any images using it, certainly
<vorlon> yeah
<vorlon> I could add it to the not-for-i386 packageset but there's also probably no hurry there
<mwhudson> yeah
-queuebot:#ubuntu-release- Unapproved: accepted openssl-ibmca [source] (eoan-proposed) [2.1.0-0ubuntu1]
<mwhudson> Laney: you git import-dsced ubiquity and now git has all the d-i goo in it
-queuebot:#ubuntu-release- Unapproved: rejected command-not-found [source] (eoan-proposed) [19.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (eoan-proposed) [19.10.0]
<bluesabre> Good evening release team! Please ack https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1846935 so we can upload the new Xubuntu wallpaper. :-)
<ubot5> Launchpad bug 1846935 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 19.10" [Undecided,New]
#ubuntu-release 2019-10-08
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (eoan-proposed/main) [2.26.1-1 => 2.26.1-2] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (eoan-proposed) [2.26.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (eoan-proposed) [20101020ubuntu591]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rygel [source] (eoan-proposed) [0.38.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted texinfo [source] (eoan-proposed) [6.6.0.dfsg.1-2ubuntu2]
<infinity> LocutusOfBorg: "Lower optimization level on ppc64el" isn't a useful changelog.  Why?
<infinity> LocutusOfBorg: If it was just to make the symbols file love you, there are tools to merge symbols.
-queuebot:#ubuntu-release- Unapproved: rejected fswatch [source] (eoan-proposed) [1.14.0+repack-12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libpeas [source] (eoan-proposed) [1.24.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-9 [sync] (eoan-proposed) [1:9-2]
-queuebot:#ubuntu-release- Unapproved: lxc (eoan-proposed/universe) [3.0.3-0ubuntu1 => 3.0.4-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdazzle [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted iputils [sync] (eoan-proposed) [3:20190709-2]
-queuebot:#ubuntu-release- Unapproved: accepted blitz++ [sync] (eoan-proposed) [1:1.0.1+ds-6]
<tjaalton> could the intel-* packages be accepted from the queue, thanks
<tjaalton> besides being new upstream versions, they migrate off llvm8
<tjaalton> well, compute-runtime does
<tjaalton> which needs newer gmmlib, and the media drivers a rebuild against it
<LocutusOfBorg> infinity, do you have links to docs?
<LocutusOfBorg> btw ppc64el has proven to be worse with -O3 wrt -O2 at least by looking at bugs and test failures...
<LocutusOfBorg> vorlon, ifreg has regressed tests in a way I don't get... this is the reason for no change rebuild...
<LocutusOfBorg> something in rules file I don't get
-queuebot:#ubuntu-release- Unapproved: evince (eoan-proposed/main) [3.34.0-1 => 3.34.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (eoan-proposed/universe) [3.34.0-2 => 3.34.1-1] (desktop-extra) (sync)
<Laney> mwhudson: whoopsie, didn't notice that, soz
<Laney> thanks to vorlon for fixing that up
<Laney> ah, and thanks ddstreet too
<mwhudson> Laney: yeah vorlon took the more constructive approach vs my just whining
<Laney> I assumed you couldn't commit :-)
<Laney> not sure if that's true
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/i/iraf/20191008_062545_1cbac@/log.gz
<LocutusOfBorg> any idea for this autopkgtest failure?
<LocutusOfBorg> it doesn't even start the test...
<LocutusOfBorg> autopkgtest [06:13:48]: ERROR: erroneous package: rules extract failed with exit code 1
<LocutusOfBorg> this seems an infrastructure regression to me...
<seb128> LocutusOfBorg, see #ubuntu-devel earlier
<Laney> yeah I retried it, hopefully is the same thing and will work now
<Laney> is running this time
-queuebot:#ubuntu-release- Unapproved: kubuntu-wallpapers (eoan-proposed/universe) [19.10.1 => 19.10.2] (kubuntu)
<LocutusOfBorg> thanks for retrying it
<LocutusOfBorg> it would be nice when autopkgtest starts to print its checkout id, or version string, so we can bisect from the "last good run"
<LocutusOfBorg> what do you think?
<Laney> it does
<Laney> that is the very first line in the log
<LocutusOfBorg> ok, thanks, it wasn't clear to me that it was the "gitlog"
-queuebot:#ubuntu-release- Unapproved: kubuntu-wallpapers (disco-proposed/universe) [18.04.0 => 19.10.1~ubuntu19.04~ppa1] (kubuntu)
<LocutusOfBorg> (I didn't find that commit on debian salsa repo, and I couldn't find references of the "git repository" for that checkout, so having the commit id is somewhat useless unless some more context is printed, at least from an external POV)
<bluesabre> Laney: Would you mind ack'ing https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1846935 ? :)
<ubot5> Launchpad bug 1846935 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 19.10" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (disco-proposed/universe) [1.383 => 1.386~ubuntu19.04~ppa1] (kubuntu)
<Laney> hey bluesabre
<bluesabre> hey! :D
<Laney> done!
<bluesabre> awesome
<bluesabre> thanks a bunch!
<RikMills> please reject kubuntu-meta. obviously should have been to a ppa
-queuebot:#ubuntu-release- Unapproved: gnome-music (eoan-proposed/universe) [3.32.1-1 => 3.32.2-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (eoan-proposed/universe) [19.10 => 19.10.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: python-pbr (eoan-proposed/main) [5.1.1-0ubuntu2 => 5.1.1-0ubuntu3] (ubuntu-desktop, ubuntu-server)
<apw> RikMills, and i assume kubunty-wallpapers ?
-queuebot:#ubuntu-release- Unapproved: rejected kubuntu-meta [source] (disco-proposed) [1.386~ubuntu19.04~ppa1]
<RikMills> apw: nope, kubuntu-wallpapers is wanted for eoan
<RikMills> thanks
-queuebot:#ubuntu-release- Unapproved: rejected kubuntu-wallpapers [source] (disco-proposed) [19.10.1~ubuntu19.04~ppa1]
<apw> RikMills, the one in disco with ~ppa1 as its version
<handsome_feng> Hi, Could some help to ack LP: #1843521 and LP: #1847101
<ubot5> Launchpad bug 1843521 in ubuntu-kylin-software-center (Ubuntu) "[FFe] Please upgrade ubuntu-kylin-software-center to 3.0.4" [Low,New] https://launchpad.net/bugs/1843521
<ubot5> Launchpad bug 1847101 in ubuntukylin-theme (Ubuntu) "[UIFe] Please upgrade ubuntukylin-theme to 1.8.3" [Undecided,New] https://launchpad.net/bugs/1847101
<RikMills> apw: oh, yes.
 * RikMills is having a bad morning
<apw> RikMills, they happen, and yay for queues
<Laney> yeah I once started a haskell transition by mistake
<RikMills> indeed!
-queuebot:#ubuntu-release- Unapproved: xorg-server (eoan-proposed/main) [2:1.20.5+git20190820-0ubuntu3 => 2:1.20.5+git20191008-0ubuntu1] (desktop-core, xorg)
<jamespage> apw: could you take a look at python-pbr - autopkgtests are currently blocking a python-defaults migration
<jamespage> its a bit of a stop-gap fix until next cycle
<apw> jamespage, nasty .. so it will be used and untested, fun
<jamespage> apw: yeah I was a bit bemused as to how python-stestr without py2 support actually got into the release pocket
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [source] (eoan-proposed) [5.1.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: grub-installer (eoan-proposed/main) [1.128ubuntu13 => 1.128ubuntu14] (core)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (eoan-proposed/main) [3.34.0-2 => 3.34.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected grub-installer [source] (eoan-proposed) [1.128ubuntu14]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu9 => 2.04-1ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.125 => 1.126] (core)
-queuebot:#ubuntu-release- Unapproved: binutils (eoan-proposed/main) [2.32.90.20190929-0ubuntu2 => 2.33-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (eoan-proposed/main) [20101020ubuntu591 => 20101020ubuntu592] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-suspend-button (eoan-proposed/universe) [0~git20180827-2 => 0~git20191005-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: u-boot (eoan-proposed/main) [2019.04+dfsg-2ubuntu3 => 2019.07+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (eoan-proposed) [2.33-1ubuntu1]
<seb128> could someone review the desktop updates in the queue? we would prefer to have the gnome point updates in earlier rather than later so they get a bit more testing
<seb128> (e.g gnome-session nautilus network-manager etc)
<seb128> apw, ^ you can help maybe? or unsure who else is doing queue reviews noaways?
<Laney> I've done a load, but usually towards the beginning and end of the day
<Laney> didn't quite get through the whole queue yesterday
<seb128> Laney, right, I know, and you are busy dealing with other days so would be nice if we had other reviewers :)
<seb128> sil2100, ^
<Laney> yeah, I guess more hands would be appreciated:-)
<seb128> other things*
<sil2100> I can take a look, I didn't do queue reviews today yet, only yesterday in the morning
-queuebot:#ubuntu-release- Unapproved: unbound (eoan-proposed/main) [1.9.0-2 => 1.9.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (eoan-proposed) [5.3.0.1002.19]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (eoan-proposed) [1.20.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle [sync] (eoan-proposed) [5.3.0.1001.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oracle [sync] (eoan-proposed) [5.3.0-1001.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oracle [sync] (eoan-proposed) [5.3.0-1001.1]
<sil2100> Laney: uh, looking at the gnome-session upload - this looks like a new upstream version, so I wanted to check the NEWS file for changes and see if this needs an FFe, but apparently NEWS is removed in this version?
<sil2100> Laney: do you know if that's intentional that the NEWS file is removed?
<sil2100> Also, I mean, maybe I'm forgetting about something (like some standing FFe or something), but is there an FFe for this? Or does this only have bugfixes?
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [source] (eoan-proposed) [2.0.9-0ubuntu1]
<Laney> sil2100: it's only bugfixes
<Laney> NEWS isn't deleted but upstream cleared out the old entries
<Laney> I did put those in the debian/changelog for helpfulness
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (eoan-proposed) [1:3.34.1-1ubuntu1]
<sil2100> Laney: ok, thanks, since I only saw '-'es in the NEWS file in the diff
<sil2100> Laney: I trust you, just wanted to make sure since it's a bump from 3.33.92 to 3.34.1, so usually those are not only bugfix releases
-queuebot:#ubuntu-release- Unapproved: accepted ukui-indicators [source] (eoan-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-9 (eoan-proposed/main) [9.2.1-8ubuntu1 => 9.2.1-9ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (eoan-proposed) [1:3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (eoan-proposed) [9.2.1-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (eoan-proposed) [3.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (eoan-proposed) [3.32.2-1]
-queuebot:#ubuntu-release- Unapproved: firefox (eoan-proposed/main) [69.0.2+build1-0ubuntu1 => 69.0.2+build1-0ubuntu2] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: grub-installer (eoan-proposed/main) [1.128ubuntu13 => 1.128ubuntu14] (core)
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (eoan-proposed) [2019.07+dfsg-1ubuntu1]
<didrocks> Laney: grub-installer tested and uploaded there ^
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (eoan-proposed/multiverse) [1.20190215-0ubuntu3 => 1.20190819-0ubuntu1] (no packageset)
<sil2100> didrocks: is that the fix for the install failure?
<didrocks> sil2100: yep, it will need a new ubiquity afterwards
<didrocks> well, failure only when using ZFS
<didrocks> or are you discussing another one?
<sil2100> didrocks: not sure, mwhudson in the morning mentioned he had a grub-install failure when testing eoan-desktop
<sil2100> But I guess this could have been it
<didrocks> I don't think this is related
<didrocks> because it's not ZFS-related AFAIK
<Laney> nah, that one turned out to be a bug in the change he was working on
<sil2100> hm, ok, since he mentioned that #ubuntu-desktop was on it, oh well!
<sil2100> Ah!
<sil2100> Ok
<Laney> the knowledge evolved over time
<sil2100> Laney: you want to review the grub-installer one? It looks good to me though, since I guess udevinfo/udevadm wouldn't return any useful errors there anyway
-queuebot:#ubuntu-release- Unapproved: accepted grub-installer [source] (eoan-proposed) [1.128ubuntu14]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.126]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-wallpapers [source] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (eoan-proposed) [19.10.1]
<sil2100> Laney: btw. if you'd have a moment, we have a linux-firmware-raspi2 package in the eoan queue that I'd need someone to accept, it's for the pi4 ongoing enablement
<sil2100> Laney: I don't want to self-approve that as I was the sponsor
<sil2100> Laney: if you have no cycles then no worries, I'll poke vorlon later
<Laney> ack, will do if I get some time shortly
<sil2100> Thanks ;)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1002.2] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1002.2]
<tumbleweed>  /36
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu10 => 2.04-1ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu10]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu10 => 2.04-1ubuntu10] (core)
 * Laney eyes queuebot 
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (eoan-proposed) [69.0.2+build1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unbound [source] (eoan-proposed) [1.9.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (eoan-proposed) [1.20190819-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (eoan-proposed) [2:1.20.5+git20191008-0ubuntu1]
<coreycb> hi release team, can someone take a look at accepting the placement eoan upload for openstack? it includes a bug fix and sqlalchemy change that will enable us to successfully deploy the service.
<sil2100> coreycb: o/
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu10]
<sil2100> Laney: thanks for linux-firmware-raspi2 o/
<coreycb> sil2100: o/
-queuebot:#ubuntu-release- Unapproved: accepted placement [source] (eoan-proposed) [2.0.0~rc1-0ubuntu2]
<Laney> NOOOOOOOOOOOOoooo problemoooo
<coreycb> sil2100: thanks :)
<sil2100> yw!
-queuebot:#ubuntu-release- Unapproved: gvfs (eoan-proposed/main) [1.42.0-1ubuntu1 => 1.42.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (eoan-proposed/main) [3.34.0-2ubuntu1 => 3.34.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kcov (eoan-proposed/universe) [36+dfsg-1build4 => 36+dfsg-1build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: looking-glass (eoan-proposed/universe) [0+b1-1build6 => 0+b1-1build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: naev (eoan-proposed/universe) [0.7.0-2build9 => 0.7.0-2build10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oprofile (eoan-proposed/universe) [1.3.0-0ubuntu8 => 1.3.0-0ubuntu9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu1 => 8.3.0-23ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu1 => 7.4.0-14ubuntu2] (core)
<vorlon> LocutusOfBorg: so, feel free to upload with a changelog that explains why we're rebuilding it :)
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (eoan-proposed/universe) [1:20191001-1ubuntu2 => 1:20191008-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.15 => 19.10.16] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (eoan-proposed) [1.42.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted looking-glass [source] (eoan-proposed) [0+b1-1build7]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-suspend-button [sync] (eoan-proposed) [0~git20191005-1]
-queuebot:#ubuntu-release- Unapproved: accepted naev [source] (eoan-proposed) [0.7.0-2build10]
-queuebot:#ubuntu-release- Unapproved: accepted kcov [source] (eoan-proposed) [36+dfsg-1build5]
-queuebot:#ubuntu-release- Unapproved: apache2 (xenial-proposed/main) [2.4.18-2ubuntu3.13 => 2.4.18-2ubuntu3.14] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted oprofile [source] (eoan-proposed) [1.3.0-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.16]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (eoan-proposed) [20101020ubuntu592]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (eoan-proposed) [7.4.0-14ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [source] (eoan-proposed) [8.3.0-23ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (eoan-proposed) [1:20191008-1ubuntu1]
<tsimonq2> Those two Lubuntu packages are targeted for this release. The last upload we may do is Calamares, prior to RC freeze.
-queuebot:#ubuntu-release- Unapproved: lubuntu-artwork (eoan-proposed/universe) [19.10.1 => 19.10.2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: lxqt-globalkeys (eoan-proposed/universe) [0.14.1-0ubuntu4 => 0.14.1+git20190923-0ubuntu1] (lubuntu)
<tsimonq2> If you have any questions, please let me know.
<infinity> tsimonq2: Why are they called apartments if they're all stuck together?
<Odd_Bloke> You're only ment to get a part of the building.
<doko> the apport and crash autopkg tests need to be overridden. no kernel anymore on i386
<doko> apw, vorlon: ^^^ and probably more that we don't know about
<tsimonq2> infinity: Huh? :)
<ginggs> tsimonq2: you said "any questions"
<infinity> ^
<vorlon> doko: hints added for crash and apport, thanks
<tsimonq2> infinity: They're distinct units sold separately. As one they are an apartment complex. Just like halloween candy. :P
<infinity> Just... Like... Halloween candy?
<infinity> That took a turn I wasn't expecting.
<tsimonq2> As in, many distinct units picked separately. Some are those crappy carmel hard candies and others are a bag of Skittles.
<tsimonq2> (carmel vs caramel is a Wisconsinism, fight me)
<xnox> twiddle thumbs
<infinity> Laney, vorlon: Do the amd64 and i386 autopkgtest guests use the same base VM spec, or did we have CPUs clamped differently for i386?
<infinity> (trying to figure out how, with the same kernel amd64 booted, a few 64-bit glibc tests would fail only on "i386" autopkgtest)
<infinity> s/kernel amd64/amd64 kernel/
<doko> that's x32. was that ever enabled in i386 kernels?
<infinity> doko: No, but it's enabled in amd64 kernels, which we now boot with.
<doko> exactly
<infinity> doko: My point is that the very same tests pass on the amd64-x32 build, and barring a binutils or gcc code generation bug that only exists with i386 userspace (unlikely), something else is goofy. :)
<doko> and the tests didn't run when the kernel doesn't support that personality
<infinity> doko: Not that any of this should block the world (and it won't), I'm just curious why.
<doko> ahh, I see
<infinity> I'll badtest i386 for now, and do some skipping in the next upload.
<doko> ta
<infinity> Undecided if I skip entirely, like it used to, or just take this as a new baseline (which seems clean except for those 4 tests, but also, who would install those packages ever anyway so do I care?)
<infinity> Wait.  lp_buildd has always built on amd64 kernels, runs the x32 tests, and those tests pass.  So yeah, I'm very suspicious of the i386 autopkgtest VMs.
<infinity> But maybe also slightly suspicious of the current archive state now. :)
 * infinity will try a test build in a PPA with proposed on.
<doko> vorlon, infinity: please override the python-fakeredis autopkg test. it's a missing python3-lupa binary on ppc64el in the release pocket, so no regression
<infinity> But that's been missing for years, and the failure started this month?
<xnox> infinity:  please RM debian-installer on i386 from eoan release https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1845714
<ubot5> Launchpad bug 1845714 in debian-installer (Ubuntu) "Drop i386 build for 19.10" [Undecided,In progress]
<xnox> infinity:  unless we wanna build i386 d-i with an amd64 kernel?! /me is not sure that anna knows how to use multiarch
<infinity> xnox: That'll require some manual archive surgery, I'll get there in a bit.
<infinity> xnox: And no, we don't want i386 installers.
<xnox> infinity:  urgh, ok. Not sure if removing just the debian-installer-udeb will be enough for britney to migrate the new kernel & the new d-i over, before removing the rest of it
 * xnox ponders if i386 builders should start using 'noudeb' build-profile
<infinity> Laney: Something broke in autopkgtest-satdep, I think?  It seems to be installing build-deps when not asked to.
<infinity> xnox: Britney knows nothing about random junk on disk, just debian packages in Packages files.
<infinity> xnox: So removing the one NBS package will migrate it.
<infinity> xnox: But also, pretty sure said migration isn't OMG NEXT SEVEN MINUTES urgent, so patience. :P
<xnox> infinity:  nah, not urgent
<infinity> xnox: And no, there's no harm in udebs existing on i386, changing how things build on one arch is silly.
 * doko welcomes the extensive testiing for this decision after feature freeze
<RikMills> can someone poke this to retry? https://launchpad.net/ubuntu/+source/ubiquity/19.10.16/+build/17864517
<RikMills> I have had a few PPA buidls fail like that without a log in the few hrs
<infinity> RikMills: Done.
<RikMills> thanks!
<infinity> Laney: Nevermind the comment about autopkgtest, was looking at the wrong control file, but am now differently confused. :)
<vorlon> infinity: afaik they're the same base vm spec
-queuebot:#ubuntu-release- Unapproved: urdfdom (bionic-proposed/universe) [1.0.0-2build2 => 1.0.0-2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: urdfdom-headers (bionic-proposed/universe) [1.0.0-1 => 1.0.0-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (eoan-proposed/main) [1.182 => 1.183] (core, kernel)
<vorlon> interesting that a subset of dkms modules now fail autopkgtests with i386 userspace and amd64 kernel
-queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.178.4 => 1.178.5] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.10 => 1.173.11] (core, kernel)
<fossfreedom> Hi all - just looking at the Ubuntu Budgie eoan manifest file - it says "linux-image-4.15.0-1018-oracle	4.15.0-1018.20" is installed.  Anyone know why this kernel is installed on our ISO?
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu1 => 242-7ubuntu2] (core)
<infinity> fossfreedom: Don't know off the top of my head, but I can investigate.
<infinity> * Chose linux-image-4.15.0-1018-oracle out of zfs-modules to satisfy zfsutils-linux
<infinity> Exciting.
<apw> o.O
<infinity> Ubuntu has the same breakage.
<infinity> I assume anyone who added zfsutils-linux to their meta (which they really shouldn't be) has this issue.
<infinity> That said, it's also clearly an apt resolver bug, since we're install linux-image in the same pass, so it shouldn't need to pick up ANOTHER linux-image to satisfy that.
<apw> doh apt ... just doh
-queuebot:#ubuntu-release- Unapproved: sylpheed (eoan-proposed/universe) [3.5.1-1ubuntu4 => 3.5.1-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (eoan-proposed/universe) [0.0~git20181101.0aadfc3-1ubuntu1 => 0.0~git20190625.f4822c6-0ubuntu1] (edubuntu)
<infinity> Hrm, actually, I can't reproduce that in a chroot.  I wonder if it's livecd-rootfs's task expansion doing something very silly.
<infinity> But it shouldn't be...
<infinity> Oh, hah.
<infinity> Yes, it's the task expansion, but only because germinate's a derp.
<infinity> And put that kernel in all the desktop tasks that asked for it.
<infinity> Task: ubuntu-desktop-minimal, ubuntu-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop
<vorlon> coreycb: are you on top of the nova autopkgtest failure on amd64?
<infinity> apw: Other than a few bespoke armhf kernels (and armhf generic), do we ship anything *without* ZFS anymore?
<infinity> apw: Maybe it's time to drop the dependency entirely and just assume people have ZFS modules.
<infinity> Which is a lie on our one remaining 32-bit arch, but oh well?
<coreycb> vorlon: yes more or  less just haven't gotten to it yet
<vorlon> ok
<coreycb> thanks
-queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (eoan-proposed) [3.5.1-1ubuntu5]
<vorlon> infinity: if anything we should resolve the lie on the remaining 32-bit arch by making the package unavailable, not uninstallable but broken?
-queuebot:#ubuntu-release- Unapproved: sylpheed (bionic-proposed/universe) [3.5.1-1ubuntu3 => 3.5.1-1ubuntu3.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sylpheed (disco-proposed/universe) [3.5.1-1ubuntu3 => 3.5.1-1ubuntu3.19.04.1] (no packageset)
<infinity> vorlon: Perhaps, yeah.  I tihnk the argument in the past for building it had something to do with being able to run 32-on-64 systems, or maybe being able to manipulate filesystems to a limited extent in userspace without kernel drivers or a combination of both.
<infinity> vorlon: But I honestly don't think anyone would expect zfsutils on armhf either, so I'd be fine with dropping it and dropping the modules|dkms deps.
-queuebot:#ubuntu-release- Unapproved: libssh (eoan-proposed/main) [0.9.0-1 => 0.9.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-globalkeys [source] (eoan-proposed) [0.14.1+git20190923-0ubuntu1]
<vorlon> tsimonq2: new binary packages from lubuntu-artwork the week before release, WHAT COULD GO WRONG
-queuebot:#ubuntu-release- Unapproved: accepted libssh [source] (eoan-proposed) [0.9.0-1ubuntu1]
<mwhudson> how many years until we can get away with just shipping an arm64 kernel?
<mwhudson> (lots and lots, sadly)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (eoan-proposed/main) [0.8.1-1ubuntu12 => 0.8.1-1ubuntu13] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (eoan-proposed) [0.8.1-1ubuntu13]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-artwork [source] (eoan-proposed) [19.10.2]
<xnox> mwhudson:  sadly armhw is not advanced enough to be affected by sometime like zombieload to accelerate its depreciation
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.14]
<tsimonq2> vorlon: ikr :P
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.615 => 2.617] (desktop-core)
<xnox> mwhudson:  infinity: ^
<xnox> with tags pushed
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.30 => 2.525.31] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.54 => 2.408.55] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.8 => 2.578.9] (desktop-core)
<infinity> rcj: ^
<rcj> infinity: Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.617]
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-software-center (eoan-proposed/universe) [1.6.8 => 3.0.4] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (eoan-proposed/universe) [19.04.0 => 19.10.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukwm (eoan-proposed/universe) [1.1.11-1build1 => 1.1.13-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-greeter (eoan-proposed/universe) [1.1.9-1 => 1.1.10-0ubuntu1] (ubuntukylin)
#ubuntu-release 2019-10-09
<vorlon> ah, I see someone fixed the openvswitch autopkgtest on i386 just in time
<vorlon> or did it fix itself when we moved to a 64-bit kernel? :)
<vorlon> huh no it's been passing for a while now?
<vorlon> tsimonq2: cough well it could just ftbfs and then the added binary package constitutes no problem whatsoever
-queuebot:#ubuntu-release- Unapproved: evolution (eoan-proposed/universe) [3.34.0-1 => 3.34.1-2] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: eog (eoan-proposed/main) [3.34.0-1 => 3.34.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: dconf-editor (eoan-proposed/universe) [3.34.1-1 => 3.34.2-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.617 => 2.618] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.618]
-queuebot:#ubuntu-release- Unapproved: libwacom (eoan-proposed/main) [0.32-1 => 1.1-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: python-pygal (eoan-proposed/universe) [2.4.0-2ubuntu2 => 2.4.0-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.437 => 1.438] (core)
<handsome_feng> Hi, Is it possible for someone in release team help to ack those: LP: #1847101 LP: #1847391, Thanks a lot!
<ubot5> Launchpad bug 1847101 in ubuntukylin-theme (Ubuntu) "[UIFe] Please upgrade ubuntukylin-theme to 1.8.3" [Undecided,New] https://launchpad.net/bugs/1847101
<ubot5> Launchpad bug 1847391 in kylin-nm (Ubuntu) "[FFe] Please sync kylin-nm 1.0.3-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1847391
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.9]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.31]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.55]
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.16 => 19.10.17] (core)
-queuebot:#ubuntu-release- Unapproved: python3.7 (eoan-proposed/main) [3.7.5~rc1-1 => 3.7.5~rc1-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.17]
-queuebot:#ubuntu-release- Unapproved: glib2.0 (eoan-proposed/main) [2.62.0-1 => 2.62.1-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.438]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [sync] (eoan-proposed) [3.7.5~rc1-2]
-queuebot:#ubuntu-release- Unapproved: binutils (eoan-proposed/main) [2.33-1ubuntu1 => 2.33-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (eoan-proposed) [2.33-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (eoan-proposed/main) [1.36.0-0ubuntu3 => 1.36.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gcc-9-cross (eoan-proposed/main) [12ubuntu1 => 12ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-9-cross-ports (eoan-proposed/universe) [10ubuntu1 => 10ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (eoan-proposed/universe) [31ubuntu1 => 31ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (eoan-proposed/universe) [24ubuntu1 => 24ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (eoan-proposed) [24ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross-ports [source] (eoan-proposed) [10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (eoan-proposed) [31ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross [source] (eoan-proposed) [12ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (eoan-proposed/universe) [1.386 => 1.387] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: networking-ovn (eoan-proposed/universe) [7.0.0~rc1-0ubuntu1 => 7.0.0~rc1-0ubuntu2] (no packageset)
<rbalint> rbasak, could you please release systemd/bionic in your sru shift?
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (eoan-proposed/universe) [0.0~git20181101.0aadfc3-1ubuntu1 => 0.0~git20181101.0aadfc3-1ubuntu2] (edubuntu)
<LocutusOfBorg> that is the fix for lxc sadness ^^ stgraber
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-easyscreencast (eoan-proposed/primary) [1.0.2+git20191008-1]
-queuebot:#ubuntu-release- Unapproved: evolution-ews (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.423 => 1.424] (desktop-core, ubuntu-server)
<seb128> ^ that casper upload is reverting the changes from the previous one that seem to have created bug #1847457
<ubot5> bug 1847457 in casper (Ubuntu) "No /cdrom mounted on live" [Critical,New] https://launchpad.net/bugs/1847457
<seb128> xnox, ^ since you don't seem to be around and we need to unscrew the desktop image I went for that, can be replaced/superseeded by a fix once you have one
<seb128> the current daily fails to install a kernel on the target system which as one can expect is problematic
<LocutusOfBorg> can I ask to drop some hints, e.g. abi-monitor/1.12-2/armhf abi-monitor/1.12-2/i386
<LocutusOfBorg> also ddcci-driver-linux/all/s390x can probably go...
<Laney> can you do a merge proposal?
<Laney> seb128: got to reject that sorry, the restored script isn't executable
<seb128> Laney, ah, thx for catching that
 * seb128 tries again
<seb128> stupid permissions :)
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.424]
<seb128> Laney, reuploaded
<Laney> thx
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.423 => 1.424] (desktop-core, ubuntu-server)
<Laney> will wait 1 hour or so for x_nox to have a chance to argue
<seb128> k
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extensions (eoan-proposed/universe) [3.34.0-1 => 3.34.1-2] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: dconf-editor (eoan-proposed/universe) [3.34.1-1 => 3.34.2-1] (ubuntugnome) (sync)
<LocutusOfBorg> Laney, please forgive me if I made mistakes in my bzr foo... https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/373867
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (eoan-proposed/main) [2.68.1-1 => 2.68.2-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dconf-editor [sync] (eoan-proposed) [3.34.2-1]
-queuebot:#ubuntu-release- Unapproved: rejected dconf-editor [sync] (eoan-proposed) [3.34.2-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-1ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.0.0~rc1-0ubuntu2 => 2:20.0.0~rc1-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mutter (eoan-proposed/main) [3.34.0-3ubuntu1 => 3.34.1-1ubuntu1] (desktop-core, desktop-extra)
<Laney> LocutusOfBorg: I'm not aware that /*/ works ...
<Laney> should be /all/
<jamespage> hi release team - a few openstack uploads in the queue if any has cycles
<jamespage> nova - workaround an autopkgtest failure
<jamespage> networking-ovn - cherry pick of fixes for SSL configuration
<jamespage> python-oslo.messaging - point release we missed on the last set of uploads
<jamespage> if someone has cycles to review mucho appreciated!
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (eoan-proposed) [2:20.0.0~rc1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (eoan-proposed) [7.0.0~rc1-0ubuntu2]
<apw> jamespage, ^ but do not see python-oslo.messaging
-queuebot:#ubuntu-release- Unapproved: accepted eog [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (eoan-proposed) [3.34.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-lxc-go-lxc.v2 [source] (eoan-proposed) [0.0~git20190625.f4822c6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [source] (eoan-proposed) [2.68.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (eoan-proposed) [1.183]
-queuebot:#ubuntu-release- Unapproved: accepted python-pygal [sync] (eoan-proposed) [2.4.0-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-software-center [source] (eoan-proposed) [3.0.4]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-greeter [source] (eoan-proposed) [1.1.10-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (eoan-proposed) [1.387]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (eoan-proposed) [1.36.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (eoan-proposed) [19.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-lxc-go-lxc.v2 [source] (eoan-proposed) [0.0~git20181101.0aadfc3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (eoan-proposed) [242-7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libwacom [sync] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukwm [source] (eoan-proposed) [1.1.13-0ubuntu1]
<Laney> guessing i raced with someone else reviewing the queue just then
<apw> Laney, yep
<Laney> |o\
<apw> Laney, no problem
<apw> (is there?)
<Laney> might have been if we'd made a different decision ;-)
<Laney> but no
<Laney> I've been avoiding that intel- stuff for some reason
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.424]
<tjaalton> Laney: no reason to ;)
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (eoan-proposed/universe) [19.10.0] (ubuntukylin)
<Laney> tjaalton: maybe someone else can
<Laney> half day, leaving now, sorry :((((
<tjaalton> okay
<tjaalton> they're all universe, should be simple
<LocutusOfBorg> Laney, I just reverted the previous commit...
<LocutusOfBorg> it has been working since the begin tbh
<LocutusOfBorg> but pushed
<jamespage> apw: messaging/versionedobjects
<jamespage> to many oslos...
<jamespage> thankyou!
<xnox> seb128:  le sigh about casper one.
<xnox> seb128:  i did test this in live sessions.
<xnox> seb128:  let me fetch current desktop iso to debug this.
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (eoan-proposed/universe) [1.8.2.1 => 1.8.3] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (eoan-proposed/universe) [1.255 => 1.256] (ubuntu-mate)
<seb128> xnox, thx for debugging!
-queuebot:#ubuntu-release- Unapproved: mysql-8.0 (eoan-proposed/main) [8.0.17-0ubuntu1 => 8.0.17-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (eoan-proposed) [1.256]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (eoan-proposed) [1.8.3]
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.7-0ubuntu1 => 1.25.8-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: kylin-nm (eoan-proposed/universe) [1.0.2-0ubuntu1 => 1.0.3-1] (ubuntukylin) (sync)
<rbasak> ^ Unapproved: mysql-8.0
<rbasak> I need that to unbreak mysql-router please. Perhaps I should have made that clearer in the changelog, thinking about it.
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (eoan-proposed/universe) [0.196 => 0.197] (ubuntustudio)
<stgraber> LocutusOfBorg: I had already sent an updated snapshot of go-lxc to fix building on newer Go releases
<ddstreet> rbalint i have some systemd sru's, are you preparing to upload for x, b, and/or d?
<rbalint> ddstreet, no, go ahead, thanks for asking
<rbalint> ddstreet, please also merge the changes to the git repo
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (eoan-proposed/main) [2:10.3.10-3build1 => 2:10.3.10-3ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: vala (eoan-proposed/universe) [0.44.8-0ubuntu1 => 0.44.9-0ubuntu1] (ubuntu-desktop)
<rbasak> ^ Unapproved: mysql-8.0
<rbasak> I need that to unbreak mysql-router please. Perhaps I should have made that clearer in the changelog, thinking about it.
<rbasak> I'm aware it's only been a couple of hours since I uploaded, but I'm concerned to get this into proposed ASAP since autopkgtests will take a while, and I don't want to hold up images
 * rbasak isn't sure who from the release team is on reviews
-queuebot:#ubuntu-release- Unapproved: u-boot (eoan-proposed/main) [2019.07+dfsg-1ubuntu1 => 2019.07+dfsg-1ubuntu2] (core)
<sil2100> Laney, apw: does one of you have some cycles to take a look at the u-boot upload in eoan Unapproved? It's critical to get our eoan pi images building again
<sil2100> rbasak: I didn't plan on doing queue reviews today but I can take a look at yours
<rbasak> Thanks!
<sil2100> ...and the desktop ones quickly too
-queuebot:#ubuntu-release- Unapproved: accepted mysql-8.0 [source] (eoan-proposed) [8.0.17-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: plymouth (eoan-proposed/main) [0.9.4git20190712-0ubuntu3 => 0.9.4git20190712-0ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (eoan-proposed) [3.34.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (eoan-proposed) [3.34.1-1ubuntu1]
<rbasak> Thank you!
<cpaelzer> sil2100: since I see you accepting packages before final freeze - there also is open-vm-tools which is not much code but fixes a mem leak. Since often vmware users are rather bad at updating images or inside images I'm considering this as important to get in before images are built.
<cpaelzer> if you could give that in the eoan queue a look as well that would be extra great
<sil2100> cpaelzer: ok o/
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (eoan-proposed) [2:10.3.10-3ubuntu1]
<sil2100> infinity: maybe you'd have a few cycles to take a look at u-boot in eoan Unapproved? It's a fix for the pi image build failure
-queuebot:#ubuntu-release- Unapproved: octavia (eoan-proposed/universe) [5.0.0~rc1-0ubuntu1 => 5.0.0~rc2-0ubuntu1] (no packageset)
<jamespage> hi release team - could the octavia upload above be acked - it resolves a security issue we're working on for dev.
<vorlon> Laney: hi, so do we have any tools to do the zapping of old contents from swift?
<vorlon> jamespage: done
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (eoan-proposed) [5.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.7-0ubuntu1 => 1.25.9-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (eoan-proposed/universe) [0.53 => 0.54] (personal-fossfreedom, ubuntu-budgie)
<Laney> vorlon: hey there, not really here (PTO), but 'swift delete' is OK for non-distro results
<Laney> for distro we need to drop from the DB too
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (eoan-proposed) [2019.07+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Packageset: 67 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (eoan-proposed) [0.9.4git20190712-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [sync] (eoan-proposed) [2.62.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extensions [sync] (eoan-proposed) [3.34.1-2]
-queuebot:#ubuntu-release- Unapproved: kdenlive (eoan-proposed/universe) [4:19.08.1-0ubuntu1 => 4:19.08.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Packageset: Added apt-setup to i386-excludes in eoan
<tsimonq2> infinity, vorlon: New Calamares and settings to match (as discussed), FTBFS fix for lubuntu-artwork, and nm-tray dependency cleanup (think: less ISO space used) all incoming. If you have any questions on those, let me know (although I'll happily clarify my position on apartment complexes).
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (eoan-proposed/universe) [1:19.10.6 => 1:19.10.7] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: calamares (eoan-proposed/universe) [3.2.12-0ubuntu1 => 3.2.14-0ubuntu1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: lubuntu-artwork (eoan-proposed/universe) [19.10.2 => 19.10.3] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: nm-tray (eoan-proposed/universe) [0.4.3-0ubuntu1 => 0.4.3-0ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (eoan-proposed/main) [0.7.9-3ubuntu4 => 0.7.9-3ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (eoan-proposed/main) [2.0.874-7.1ubuntu2 => 2.0.874-7.1ubuntu3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ppp (eoan-proposed/main) [2.4.7-2+4.1ubuntu3 => 2.4.7-2+4.1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (eoan-proposed) [0.7.9-3ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted ppp [source] (eoan-proposed) [2.4.7-2+4.1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (eoan-proposed) [2.0.874-7.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nm-tray [source] (eoan-proposed) [0.4.3-0ubuntu2]
<infinity> tsimonq2: http://launchpadlibrarian.net/446031099/lubuntu-artwork_19.10.2_19.10.3.diff.gz <-- Is it intentional to keep 1804 wallpapers there?
<tsimonq2> infinity: Yes.
<infinity> Okily dokily.
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-artwork [source] (eoan-proposed) [19.10.3]
<infinity> tsimonq2: Oof, that's a big Calamares upstream bump for a week pre-release.
<tsimonq2> infinity: Understandable, however it does include desirable GeoIP configuration changes.
-queuebot:#ubuntu-release- Packageset: Added base-installer to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added fusecram to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added grub-installer to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added lilo-installer to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added live-installer to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added netcfg to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added partman-auto to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added partman-base to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added partman-basicfilesystems to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added partman-crypto to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added partman-efi to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added system-integrity-check to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added vlan to i386-excludes in eoan
<tsimonq2> infinity: We're willing to sufficiently test this prior to release, if that's what you're implying.
<infinity> +- *KCoreAddons* is now a required dependency. This lets us drop a chunk
<infinity> +  of code that was copied from KCoreAddons years ago, and use the
<infinity> +  (maintained!) upstream version instead.
<infinity> tsimonq2: I don't see that represented in the debian/* delta.
<infinity> tsimonq2: Oh, looks like it's already a dep anyway.  Nevermind, then.
<tsimonq2> infinity: Was close to sending a message saying that. :)
<tsimonq2> Thanks.
<ogra> it is calamares ... the fix is in the mayonnaise ;)
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (eoan-proposed) [1:19.10.7]
-queuebot:#ubuntu-release- Unapproved: accepted calamares [source] (eoan-proposed) [3.2.14-0ubuntu1]
<tsimonq2> ogra: Hah.
-queuebot:#ubuntu-release- Unapproved: accepted kdenlive [source] (eoan-proposed) [4:19.08.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-nm [sync] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New binary: lubuntu-artwork [amd64] (eoan-proposed/universe) [19.10.3] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted vala [source] (eoan-proposed) [0.44.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yabasic (eoan-proposed/universe) [1:2.84.1-1 => 1:2.84.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-easyscreencast [sync] (eoan-proposed) [1.0.2+git20191008-1]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (eoan-proposed) [19.10.0]
-queuebot:#ubuntu-release- New: accepted lubuntu-artwork [amd64] (eoan-proposed) [19.10.3]
-queuebot:#ubuntu-release- Unapproved: maas-enlist (eoan-proposed/main) [0.4+bzr38-0ubuntu3 => 0.4+bzr38-0ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted yabasic [sync] (eoan-proposed) [1:2.84.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted maas-enlist [source] (eoan-proposed) [0.4+bzr38-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.7-0ubuntu1 => 1.25.10-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Packageset: Added clock-setup to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added net-retriever to i386-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added network-console to i386-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: multipath-tools (eoan-proposed/main) [0.7.9-3ubuntu5 => 0.7.9-3ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (eoan-proposed) [0.7.9-3ubuntu6]
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.2-36-g059d049c-0ubuntu2 => 19.2-36-g059d049c-0ubuntu3] (core, edubuntu, ubuntu-cloud)
<bdmurray> infinity: Is the ubuntu release notes project still useful for tracking release not work?
<bdmurray> s/note/
<infinity> bdmurray: It can serve as a reminder of things people want to write about later, yes.
<infinity> (that's all it ever was)
<bdmurray> Right, that was what I remembered. I'll add bug 1845571 just in case then.
<ubot5> bug 1845571 in partman-auto (Ubuntu Eoan) "ubiquity offers installation media as an install target" [High,Triaged] https://launchpad.net/bugs/1845571
<infinity> bdmurray: Though, given that release notes are a living document from the day they're created (which can be any time in the cycle, including opening day, if we want), I'd really prefer people write in them when they think about it instead of saving reminders for later, or hoping someone else will get to it.
<bdmurray> But writing words is hard!
<infinity> That's true.
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu7 => 2.20.11-0ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (eoan-proposed/main) [2.26.1-2 => 2.26.1-3] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: calamares (eoan-proposed/universe) [3.2.14-0ubuntu1 => 3.2.14-0ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (eoan-proposed/universe) [10.5-0ubuntu6 => 10.5-0ubuntu7] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (eoan-proposed/universe) [2.229 => 2.230] (xubuntu)
<bluesabre> Please approve the above xubuntu-meta, it enables the ZFS support in Ubiquity for us
#ubuntu-release 2019-10-10
<infinity> bluesabre: Why are pepole adding zsys for zfs installer support?
<infinity> (note that it's not there for Ubuntu desktop, cause it's in universe)
<infinity> Oh, Didied filed an MIR a month ago.  Whee.
<bluesabre> infinity: Suggestion by Wimpress for better support in 20.04, I believe.
<infinity> To be clear, I intent to have a long talk with the desktop team in the morning about their implementation here.
<infinity> No other filesystem/storagelayer requires tools be in the desktop seeds.
<infinity> This is not how we do this. :P
<bluesabre> :)
<infinity> But yes, we'll pick up your meta changes if I lose that argument or give up yelling.
<bluesabre> Iâm just following the pack, happy to make adjustments as you see fit.
<infinity> bdmurray: Removing the click hook feels more like an upstream change, not something to do in an Ubuntu revision, surely?
<infinity> (I realise we're also upstream, but it's not packaged natively)
<infinity> Oh, gross.  It *is* packaged natively, but not *versioned* natively.
<infinity> Ick, ick.
<rharper> hi, cloud-init has an upload to eoan to fix  a bug that can prevent cloud-init from running in lxd/kvm cloud images,  https://bugs.launchpad.net/cloud-init/+bug/1846511 ; would be good to get this in so eoan cloud-images don't have a busted config in the image
<ubot5> Launchpad bug 1846511 in cloud-init "cloud-init does not run after upgrade due to bad 90_dpkg.cfg" [Critical,Fix committed]
<infinity> rharper: Icky.  And accepted.
<rharper> infinity: indeed; thanks!
<infinity> rharper: I assume that same bug will need all the SRUs too?
<rharper> no, it only affected eoan
<infinity> Oh, lucky.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [19.2-36-g059d049c-0ubuntu3]
<rharper> very
<rharper> not looking for another critical sru for cloud-init any time soon
<rharper> this was too close for comfort
<infinity> I did appreciate the accidental recursion, though.
<rharper> hehe
<infinity> https://accidentallyquadratic.tumblr.com/
<infinity> Doesn't quite belong, but certainly in the spirit of it.
<rharper> lol
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: partman-auto (eoan-proposed/main) [134ubuntu10 => 134ubuntu11] (core, i386-excludes)
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.17 => 19.10.18] (core)
<xnox> updated description of https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1845571 most of the code for "installer media detection" fails on el-torito hybrid images and partman/parted is very confused about it, thus the strict /cdrom grep is the only thing that is preventing to autopartition the cdrom media one is booted from. And the grep needs expanding, now that we properly mount an el-torito
<ubot5> Launchpad bug 1845571 in partman-auto (Ubuntu Eoan) "ubiquity offers installation media as an install target" [High,Triaged]
<xnox> partition of the cdrom.
<xnox> Laney:  infinity: ^
<xnox> maybe vorlon too
 * xnox sleeps
<xnox> happy RC day
<tsimonq2> infinity: Oh yeah, so there's another Calamares.
<tsimonq2> infinity: Someone forgot to mention that we have an Apport hook that has that path hardcoded. Bleh.
<tsimonq2> infinity: Anyway, kc2bez handled it, so that Should be the last Cala for this cycle.
<tsimonq2> infinity: Ah, well, the bot that's in here must have derped, because it seems it was accepted. :P
<tjaalton> pretty please, intel-* from the queue finish my plate on migration to llvm9 (intel-comput-runtime needed a new version, which needed new -gmmlib, which forced rebuilds of intel-media-*)
-queuebot:#ubuntu-release- New: accepted backport-iwlwifi-dkms [source] (eoan-proposed) [7906-0ubuntu1]
-queuebot:#ubuntu-release- New binary: backport-iwlwifi-dkms [amd64] (eoan-proposed/universe) [7906-0ubuntu1] (no packageset)
<vorlon> tjaalton: it seems libigdgmm9 is seeded on pretty much all of the desktop flavors except for Ubuntu itself, so that's a risky transition to be handling at this point in the cycle; what's the impact if we don't migrate to llvm9 until FF opens?
<vorlon> infinity: ^^ and I'll defer to you on actually deciding what to do about these intel packages
-queuebot:#ubuntu-release- New: accepted backport-iwlwifi-dkms [amd64] (eoan-proposed) [7906-0ubuntu1]
<tjaalton> vorlon: really? the only rdepends for it are intel-media-va-driver* and intel-opencl-icd.. so the other images have the va-driver included?
-queuebot:#ubuntu-release- Unapproved: dmraid (eoan-proposed/main) [1.0.0.rc16-8ubuntu1 => 1.0.0.rc16-8ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.0-1ubuntu2 => 19.2.1-1ubuntu1] (core, xorg)
<tjaalton> mesa ^ is a bugfix release
<tjaalton> as for the impact on intel-compute-runtime still on llvm8 while spirv-llvm-translator and opencl-clang moved on to llvm9, I'm not sure
-queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (eoan-proposed) [134ubuntu11]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.18]
<tjaalton> libigc1 et al pulls in llvm9
<tjaalton> libllvm9
<tjaalton> I don't see compute-runtime (intel-opencl-icd) to use it directly, so could be fine as is
<infinity> tjaalton: I've decided to let it in anyway, please give it some abuse from whatever angles you can think of, though.
<infinity> tjaalton: It seems to be on flavour media due to weird twisty dependencies of things like libavcodec. :P
-queuebot:#ubuntu-release- Unapproved: accepted intel-compute-runtime [source] (eoan-proposed) [19.39.14278-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [source] (eoan-proposed) [19.2.1+ds1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [source] (eoan-proposed) [19.2.1+dfsg1-2ubuntu1]
<tjaalton> ah, via libva2
<tjaalton> and va-driver-all
 * infinity nods.
-queuebot:#ubuntu-release- Unapproved: accepted dmraid [source] (eoan-proposed) [1.0.0.rc16-8ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1] (kubuntu)
<tjaalton> thanks, I'll figure out a better test-case for opencl than darktable :)
-queuebot:#ubuntu-release- Unapproved: firefox (eoan-proposed/main) [69.0.2+build1-0ubuntu2 => 69.0.3+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<infinity> tjaalton: intel-gmmlib FTBFS on i386.
<infinity> tjaalton: And this one might be in the class of things we actually want working.
<tjaalton> bah
<tjaalton> I'll check
<infinity> [ RUN      ] CTestAuxTable.TestAuxTableContent
<infinity> /<<BUILDDIR>>/intel-gmmlib-19.3.2+ds1/Source/GmmLib/ULT/GmmAuxTableULT.cpp:244: Failure
<infinity> Value of: val
<infinity>   Actual: 281474827812864
<infinity> Expected: expected
<infinity> Which is: 18446744073560653824
<infinity> [  FAILED  ] CTestAuxTable.TestAuxTableContent (0 ms)
<infinity> Truncation of 64-bit type to 32-bit?
<infinity> Except 281474827812864 is a lot bigger than 32-bits, so no.
<tjaalton> this one got added in 19.3.2, nice
<infinity> tjaalton: Testing new code, or just new test exposing a bug that was already there?
<infinity> (or potentially new test that is, itself, buggy_
<infinity> )
<tjaalton> new test
<tjaalton> and code
<tjaalton> a09c68fd3244eee Add Pagetable manager  and auxtable  support.
<tjaalton> could just skip tests on i386 for now
<tjaalton> filed it upstream
<tjaalton> though they're kinda actively dropping support for 32bit
<tjaalton> the opencl runtime is amd64 only, for instance
<infinity> I don't mind dropping i386 if you can make sure the revdeps all get handled sanely.
<infinity> And by tomorrow. :P
<tjaalton> yeah I'm looking at it
<tjaalton> actually, I don't think the tests were run previously, since they need certain cpu features from the builder
<tjaalton> and the check was buggy in the past
<tjaalton> hmm no, this test is new and is just buggy
<infinity> I'd certainly prefer "fix buggy test/code", if the bug's jumping out at you.
<infinity> I'm going to go see if I can catch some sleep so I can catch EU before their EOD in the morning.
<infinity> tjaalton: If you find a fix, pass it by someone you trust for review, but feel free to self-accept a fixed upload after triple-checking the debdiff isn't bonkers.
<tjaalton> I'll poke them to provide a fix or I'll just skip tests for now. amd64 is proben to pass them now :)
<tjaalton> *proven
<tjaalton> got it
<infinity> tjaalton: Ditto for binary NEW.  It looks fine to me, but not accepting because of the arch skew.
 * infinity wanders off.
-queuebot:#ubuntu-release- Unapproved: python3.8 (eoan-proposed/universe) [3.8.0~rc1-1 => 3.8.0~rc1-3] (no packageset) (sync)
<apw> tjaalton, i am about if you have something to review
<tjaalton> apw: not yet
<tjaalton> but yes, i'll ping you once I do
-queuebot:#ubuntu-release- Unapproved: accepted python3.8 [sync] (eoan-proposed) [3.8.0~rc1-3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:19.10.13 => 1:19.10.14] (core)
<doko> xnox, ginggs: I see you had some successful give backs for http://autopkgtest.ubuntu.com/packages/p/python-sparse/eoan/i386. any idea?
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.23 => 1.0.1ubuntu2.24] (core)
<sil2100> apw: hello o/ Would you have a moment to take a look at ubuntu-release-upgrader? The diff is quite big, but it's due to demotion/translation changes, the actual diff is 3 lines
<sil2100> (in eoan of course)
<apw> sil2100, sure
-queuebot:#ubuntu-release- Unapproved: gnome-nibbles (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: quadrapassel (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
<ginggs> doko: six seems to be a common trigger in those that passed.  i've just triggered itself to try to see if it has regressed in release
<ginggs> maybe six needs another rebuild?  see https://launchpad.net/ubuntu/+source/six/1.12.0-1build1
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (eoan-proposed) [1:19.10.14]
<sil2100> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu10 => 2.04-1ubuntu11] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (eoan-proposed/main) [66ubuntu19.10.2 => 67ubuntu19.10.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-9 (eoan-proposed/main) [9.2.1-9ubuntu1 => 9.2.1-9ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.126 => 1.127] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (eoan-proposed/main) [19.01.4-1 => 19.10.2-1] (ubuntu-desktop)
<doko> ginggs: do you know why that rebuild was necessary? LocutusOfBorg?
<ginggs> doko: no idea, I just happened to see it in the changelog
<LocutusOfBorg> doko, actually it wasn't, at least to the test log... http://autopkgtest.ubuntu.com/packages/p/python-sparse/eoan/i386
-queuebot:#ubuntu-release- Unapproved: iproute2 (eoan-proposed/main) [5.2.0-1ubuntu1 => 5.2.0-1ubuntu2] (core)
<LocutusOfBorg> the fix has been in 1.12.0-2 with "Mark autopkgtests as superficial."
-queuebot:#ubuntu-release- Unapproved: gnome-maps (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
<didrocks> Laney: here is the grub2 update fixing the signed kernel filtering we discussed ^ (grub2, grub2-signed and ofc grubzfs-testsuite which was updated for autopkgtests to pass)
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4.3 => 0.4.4] (no packageset)
<apw> didrocks, did that 'optimisation' patch that was causing non-initialisation of the display get sorted in grub2
<apw> (i was expecting it to get dropped i think)
<didrocks> apw: hum, I'm unsure about which patch you are talking about, I'm a little bit out of context, was that something we discussed?
<apw> didrocks, hmmm, maybe, or maybe it was cyphermox ...
<didrocks> apw: that's the second time you are doing that to me on grub2-related things! :) we speak the same language, but with a different accent :p
<seb128> apw, is that one that has to do with flickerfree boot? do you have a lp reference?
<didrocks> (but more seriously, I think it was with him, because nor a patch not this discussion rings a bell to me)
<apw> seb128, right something to do with reducing flicker
<seb128> apw, reverting would add the flicker back ... is there a proper report explaining the issue?
<Laney> juliank: seems a bit late for that packagekit change ...
<juliank> Laney: packagekit?
<Laney> HEH
<Laney> forget it, I'm looking at disco
<juliank> oh that one
<apw> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1827203
<ubot5> Launchpad bug 1827203 in grub2 (Ubuntu) "2.02+dfsg1-12ubuntu2: terminal not initialised in GRUB_TIMEOUT_STYLE=menu" [Undecided,New]
<Laney> scared about it there too, but not my call thankfully :>
<seb128> apw, thx
<ginggs> doko, LocutusOfBorg: the passing test on 2019-07-30 12:35:34 UTC was with a rebuilt six, and so was 2019-09-02 08:43:44 UTC (0.2.0-2 was obviously built after 0.2.0-1)
<juliank> Laney: the change + aptdaemon followup to make that use it is planned to go back all the way to xenial; but need to come up with a better test case I guess
<apw> seb128, ok that patch is still in there ... for me i was able to downgrade to the version before that was added and got normal updates
<juliank> the current test case stats to check the socket is used and stuff still works correctly
<seb128> apw, you pinned your grub? or got it updated again to newer version and didn't see the issue again?
<juliank> but it does not actually state to like use a frontend and then close it while stuff is being installed
<apw> seb128, i repeatedly pushed it back to an older version which i have in my home
<apw> so manually pinned
<apw> seb128, let me upgrade now and con
<apw> confirm it is still sad
<seb128> k, we should investigate the issue then
<seb128> but it sounds a bit late to revert, especially that nobody else noticed/complained and cyphermox asked for debug details
<seb128> for what we know it could be an hardware issue specific to your machine
<apw> seb128, we talked about it at the time, and i had gotten the impression it was a somewhat dodgy change not yet accepted upstream; and it iwas going
<apw> seb128, i am sure it is h/w specific in some sense, though this is a common Dell
<apw> seb128, the bigger issue to my mind is mostly don't notice it if you don't have the menu turned on and your machine isn't broken
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.127]
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu11]
<didrocks> thx!
<ginggs> python-sparse/i386 passed in release https://autopkgtest.ubuntu.com/packages/python-sparse/eoan/i386
<seb128> apw, right, we should fix it. Reverting would be a bit sad since it would mean that we loose flickerfree boot
<apw> seb128, a bit less flicker boot, as we are still doing a panel reset to change the tiling
<apw> i guess an option to say, i am poo please don't use it would be fine
<seb128> well, that patch is supposed to avoid the mode change in the case the menu isn't displayed
<seb128> so it sounds like it's buggy
<seb128> also what panel reset is that that? I'm not expert on that stack but my understanding from the upstream work is that it was supposed to be fully flicker free on recent intel cards where i915.fastboot is default now
<apw> seb128, isn't the efi framebuffer defined as non-tiled and we want to be tiled by the time we get to X
<apw> seb128, but also, i am not keeping up, so take everything i say with a grain of salt
<apw> seb128, anyhow will update, reboot, and report back
-queuebot:#ubuntu-release- Unapproved: binutils-mingw-w64 (eoan-proposed/universe) [8.3ubuntu2 => 8.3ubuntu3] (no packageset)
<seb128> could be, as said I'm not familiar with those details
<seb128> apw, thx!
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (eoan-proposed) [10.5-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (eoan-proposed) [69.0.3+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted quadrapassel [sync] (eoan-proposed) [1:3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (eoan-proposed) [0.197]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.10-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-nibbles [sync] (eoan-proposed) [1:3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (eoan-proposed) [2.230]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (eoan-proposed) [0.54]
-queuebot:#ubuntu-release- Unapproved: intel-gmmlib (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1 => 19.3.2+ds1-0ubuntu2] (kubuntu)
<tjaalton> apw: ^ gmmlib skips all tests now
<apw> tjaalton, we couldn't just skip them on i386 ?
-queuebot:#ubuntu-release- Unapproved: python2.7 (eoan-proposed/universe) [2.7.16-4 => 2.7.17~rc1-1] (kubuntu)
<tjaalton> apw: the tests passed fine on amd64, and this is likely the last upload for eoan, so.. :)
<tjaalton> let me test (ha) something
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu11] (core)
-queuebot:#ubuntu-release- Unapproved: six (eoan-proposed/main) [1.12.0-2 => 1.12.0-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (eoan-proposed) [2.7.17~rc1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (eoan-proposed/universe) [66-1 => 67-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted six [source] (eoan-proposed) [1.12.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted binutils-mingw-w64 [source] (eoan-proposed) [8.3ubuntu3]
<doko> ginggs: ^^^ ok, one more no-change upload, the autopkg testers are idle, so it doesn't hurt
<tjaalton> apw: ok, I have another version to upload
<apw> tjaalton, go for it
<apw> seb128, ok confirmed it is the same with the latest version, i am pretty sure i do not have fastboot=1
<apw> (i see a bios 'hit return' thing which is what suppresses that right?)
-queuebot:#ubuntu-release- Unapproved: intel-gmmlib (eoan-proposed/universe) [19.3.2+ds1-0ubuntu1 => 19.3.2+ds1-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gcc-mingw-w64 (eoan-proposed/universe) [22~exp1ubuntu1 => 22~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.10-0ubuntu1 => 1.25.11-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted intel-gmmlib [source] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
<apw> tjaalton, ^
<tjaalton> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu11]
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu3 => 3.98ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu11]
-queuebot:#ubuntu-release- Unapproved: rejected flash-kernel [source] (eoan-proposed) [3.98ubuntu4]
<apw> doko, i assume this was not irony: "No-change rebuild. For what reason?"
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu3 => 3.98ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: intel-gmmlib [i386] (eoan-proposed/universe) [19.3.2+ds1-0ubuntu2] (kubuntu)
<LocutusOfBorg> apw, no irony, it worked in the past but we don't know why
<LocutusOfBorg> so, if the test automagically works, we can debug it further
<LocutusOfBorg> and I plan to do it
-queuebot:#ubuntu-release- New: rejected intel-gmmlib [amd64] (eoan-proposed) [19.3.2+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intel-gmmlib [amd64] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted intel-gmmlib [i386] (eoan-proposed) [19.3.2+ds1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: swift (eoan-proposed/main) [2.22.0-0ubuntu1 => 2.22.0-0ubuntu2] (openstack)
<doko> apw: no. see above: " ^^^ ok, one more no-change upload, the autopkg testers are idle, so it doesn't hurt"
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (eoan-proposed/universe) [2.7.16-2 => 2.7.17~rc1-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (eoan-proposed) [1.25.11-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (eoan-proposed) [9.2.1-9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [sync] (eoan-proposed) [67-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (eoan-proposed) [2.7.17~rc1-1]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (eoan-proposed) [5.2.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (eoan-proposed) [2.22.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-mingw-w64 [source] (eoan-proposed) [22~exp1ubuntu2]
<doko> rbasak: https://tracker.debian.org/pkg/python-trio  not in Debian, wondering why we need to ship that in Ubuntu?
-queuebot:#ubuntu-release- Unapproved: python-msrest (eoan-proposed/universe) [0.6.1-1 => 0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected python-msrest [source] (eoan-proposed) [0.6.1-1ubuntu1]
<rbasak> doko: what would you prefer to do for Ubuntu? It's fine for a non-LTS I think.
-queuebot:#ubuntu-release- Unapproved: linux-aws (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [5.3.0.1002.2 => 5.3.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.17.19 => 5.3.0.18.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (eoan-proposed/main) [5.3.0.1003.3 => 5.3.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: python-msrest (eoan-proposed/universe) [0.6.1-1 => 0.6.1-1ubuntu1] (no packageset)
<doko> rbasak: I'm currently looking at the python-msrestazure autopkg test failures, and python-trio is in the way, that's why I'm asking
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-aws (eoan-proposed/primary) [5.3.0-1003.3]
-queuebot:#ubuntu-release- New sync: linux-restricted-modules-gcp (eoan-proposed/primary) [5.3.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: linux-kvm (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (eoan-proposed/main) [5.3.0.1002.2 => 5.3.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-msrest [source] (eoan-proposed) [0.6.1-1ubuntu1]
<Laney> wtf
<rbasak> doko: looking
<Laney> doko: can you please stop accepting your own stuff :(
<Laney> I was going to reject that, you typoed override
<doko> ouch, ok
<Laney> also you didn't make it respect nocheck in DEB_BUILD_OPTIONS which you should really do when overriding dh_auto_test
<Laney> bonus also: that might have been accepted by auto-accept but someone has made a syntax error so that bot isn't functioning atm
<Laney> /o\
<doko> Laney: so, no, then please just override the python-msrestazure autopkg test. fails in the release too
<Laney> no you won't fix it?
<rbasak> doko: I'm not sure I understand yet. Do you mean the python-msrestazure autopkgtest failures in Ubuntu? How is it being blocked by python-trio?
<doko> Laney: no, it's a regression in release? and apparently not in debian
<doko> rbasak: I don't care to look. it's blocked in debian because -trio is blocked apparenty?
<Laney> this seems like a strange response to me pointing out a typo in your upload
<doko> Laney: I'll remove it in -proposed
<rbasak> doko: https://tracker.debian.org/pkg/python%2Dmsrestazure says it's in testing? I don't see anything blocked.
<apw> Laney, that explains why the autobot has been so quiet
<doko> rbasak: no, migration is stalled: https://tracker.debian.org/pkg/python-msrest
<rbasak> Ah that's a different source package
 * rbasak looks again
<Laney> I've just fixed the auto-accept bot, so any future upload will probably just sail in
<doko> rbasak: and python-msrestazure 0.6 apparently needs the new msrest
<xnox> doko:  although ~ubuntu-archive have powers to accept, process wise ~ubuntu-release should be processing the queue right now.
<xnox> doko:  and you are not ~ubuntu-release
<xnox> Laney:  yeah, i have noticed some things that was expected to auto-accept and weren't. But i thought maybe it needs manual review.
<Laney> xnox: apw: SyntaxError: invalid syntax
<Laney>   File "/home/ubuntu-archive/auto-accept", line 12
<Laney>     PACKAGESET_WHITELIST = {"ubuntugnome", "edubuntu", "i386-eoan-excludes", "i386-excludes"]
<Laney> /o\\\\\\\\\\\\\\\
<doko> xnox, I didn't accept my toolchain uploads
<xnox> doko:  ok. thanks.
<rbasak> doko: OK I think I understand what you're pointing out and why you pinged me now.
<rbasak> doko: are you expecting to take any action or asking me to take any action about python-trio?
<doko> rbasak: I asked Laney now to ignore the autopkg test failures as a stop gap. I see that we have inconsistant versions, and I don't want to spend time investing these universe packages
<Laney> I dunno what's going on to be honest
<Laney> I pointed out a typo, and then I got in response what seems like a very strange refusal to re-upload a fixed version
<rbasak> I think it's OK to kick out of the release pocket in Ubuntu anything that is being caught up by this, but I don't think it's necessary for python-trio itself.
<doko> sure, so that's why I'm asking to ignore the autopkg test for now
<rbasak> I would just kick python-msrest out of the release pocket
<rbasak> (which might need kicking out python-msrestazure too)
<rbasak> Or, consider the current version of 0.5.5-1 in the release pocket good, as it is in Debian
<rbasak> And that /0.6.1-1(ubuntu1)?/ is correct in not migrating
<rbasak> Since AFAICT the test is revealing a real problem here?
<doko> rbasak: it's already broken in the release: http://autopkgtest.ubuntu.com/packages/p/python-msrestazure/eoan/amd64
<rbasak> I've not looked in detail to confirm, but it seems to me that the autopkgtest failure in the release pocket is a different root cause
<rbasak> IMHO, either some MOTU volunteers to fix this (I'm suggesting that it's not the job of any Canonical employee to fix everything in universe) or we should kick out what we know to be broken in the release pocket.
<rbasak> Which might be just python-msrestazure then.
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu4 => 3.98ubuntu5] (core)
<doko> ... + python-azure, python-azure-storage, python-django-storages, ...
<rbasak> Laney: are you available to badtest hint the two reds for mysql-8.0 please? Or would you prefer one or two MPs?
<rbasak> Neither are caused by the mysql update
<rbasak> (as evidenced by recent failures in tests not triggered by mysql-8.0)
-queuebot:#ubuntu-release- Unapproved: python-defaults (eoan-proposed/universe) [2.7.16-1 => 2.7.17-1] (kubuntu)
<rbasak> ^ https://code.launchpad.net/~racb/britney/mysql-8.0-migration/+merge/373960
<didrocks> sil2100: are the ubuntu-images autopkgtests known to be flaky? The "mount" tests fails on both amd64 and s390x and the grub change we have is unrelated to it
<didrocks> (in the history, the tests seemed to be reliable)
-queuebot:#ubuntu-release- Unapproved: shoogle (eoan-proposed/universe) [0.1.4-7 => 0.1.4-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shoogle [sync] (eoan-proposed) [0.1.4-8]
<doko> RikMills: why is python2 (python-defaults) still in the kubuntu set?
<RikMills> doko: I have no clue. it is not seeded or 'supported'
<sil2100> didrocks: hmm, so I'd have to look at it again, but I feel like there has been some flakyness in mount in the past - can't remember for which arches, let me take a look in a moment
<didrocks> sil2100: sure! as long as tomorrow's image has the new grub, it's good :)
-queuebot:#ubuntu-release- Unapproved: gnome-session (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1-1ubuntu2] (ubuntu-desktop)
<cjwatson> python> https://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.eoan/rdepends/python-defaults/python near the end shows it: kubuntu-desktop Recommends: konversation Depends: konversation-data Recommends: python
<cjwatson> RikMills: ^-
-queuebot:#ubuntu-release- Unapproved: thunderbird (eoan-proposed/main) [1:68.1.1+build1-0ubuntu1 => 1:68.1.2+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<RikMills> cjwatson: ah. want that fixed
<didrocks> sil2100: ok, they were flaky
<sil2100> \o/
<sil2100> ;p
<sil2100> I mean, I shouldn't be happy about that
<didrocks> sil2100: heh, don't show it at least ;)
<doko> RikMills: fix uploaded, waiting in the queue
-queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
<RikMills> doko: did you fix the current FTBFS in proposed?
<doko> RikMills: oops, no. do you want to take the diff for your next upload?
<RikMills> needed: https://cgit.kde.org/konversation.git/commit/?h=1.7&id=4d0036617becc26a76fd021138c98aceec4c7b53
<doko> RikMills: do you want me to upload?
<RikMills> doko: Qt 5.13 in that is a fib ^^ it is another reason
<RikMills> doko: if you like, I am doing other things right now
<doko> ok, doing
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (disco-proposed) [0.131ubuntu19.2]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected konversation [source] (eoan-proposed) [1.7.5-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.16]
-queuebot:#ubuntu-release- Unapproved: openjdk-14 (eoan-proposed/universe) [14~14-2 => 14~18-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-14 [source] (eoan-proposed) [14~18-1]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (eoan-proposed) [1:68.1.2+build1-0ubuntu1]
<Laney> rbasak: I'll have a look (was out at lunch)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (eoan-proposed) [3.34.1-1ubuntu2]
<Laney> & getting stabbed in the arm with a needle
<Laney> looks like apw did it
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-aws [sync] (eoan-proposed) [5.3.0-1002.2+1]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-oracle [sync] (eoan-proposed) [5.3.0-1001.1]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-azure [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-gcp [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [149 => 150] (ubuntu-desktop)
<apw> infinity, i am assuming you will review the kernels in Unapproved; i have reviewed the corresponding lrms in New and you are free to accept them in sycn
<apw> (as i assume you are expecting them)
<rbasak> Laney, apw: thank you for poking at MySQL for me. It looks like it's all landed and done now.
<Laney> nice one
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-430 (eoan-proposed/restricted) [430.50-0ubuntu1 => 430.50-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-435 (eoan-proposed/restricted) [435.21-0ubuntu1 => 435.21-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (eoan-proposed/restricted) [340.107-0ubuntu6 => 340.107-0ubuntu7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.129-0ubuntu1 => 390.129-0ubuntu2] (core)
<tseliot> apw, Laney: hey, I know it's not ideal (given the date), but I think it would be worth having the two fixes for nvidia in, unless we want to break dist-upgrades from Disco, or we want suspend to be broken on some systems (see the changelog)
<tseliot> these nvidia ^^
<tseliot> help would be very welcome
-queuebot:#ubuntu-release- Unapproved: accepted python-defaults [source] (eoan-proposed) [2.7.17-1]
<doko> ginggs, LocutusOfBorg, apw: so yes, python-sparse/i386 succeeded with the "no-change" six upload
<LocutusOfBorg> meh, will look
<LocutusOfBorg> doko, no
<LocutusOfBorg> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 12:32:55 UTC	0h 03m 09s	doko	fail	log â artifacts â
<LocutusOfBorg> this run was bad, but with latest sparse
<LocutusOfBorg> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 14:33:35 UTC	0h 03m 29s	doko	pass	log â artifacts â
<LocutusOfBorg> this one is good with same packages
<doko> 0.2.0-1	python3-defaults/3.7.5-1	2019-10-10 14:33:35 UTC	0h 03m 29s	doko	pass
<LocutusOfBorg> yes, and the very same run with the very same installed packages failed two hours before
<LocutusOfBorg> I would say more flaky test rather than rebuild neede4d
<doko> vorlon: django-compat/unknown still needs on override
<Laney> tseliot: eek
<tseliot> Laney, I wouldn't ask if it weren't really urgent, especially LP: #1830961 . Sorry
<ubot5> Launchpad bug 1830961 in nvidia-graphics-drivers-430 (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Fix released] https://launchpad.net/bugs/1830961
<Laney> no worries
<Laney> but someone other than me might know better about the compiler flags stuff
<Laney> apw: got a chance to check them maybe?
<apw> sforshee, ^ i think you are our -fcf-protection guru
<Laney> delegation in action
<tseliot> apw, Laney: those flags are set by the kernel in Eoan, but they are not in Disco, which is a problem when dist-upgrading. sforshee commented here, but I don't know if the fix was backported to 19.04 https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/comments/36
<ubot5> Launchpad bug 1830961 in nvidia-graphics-drivers-430 (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Fix released]
<ginggs> doko: i have no idea how!  i diffoscope'd the binaries and they were essentially identical
<sforshee> Laney, tseliot: I did send those for sru to b/d, but seems they haven't been released yet
<ricotz> hello, vala is currently stuck in -proposed due to some unrelated automake-1.16 test failure, I hoping it is possible to force a transition to get it into the release -- https://launchpad.net/ubuntu/+source/vala/0.44.9-0ubuntu1
<sforshee> yes, looks like they are in the -proposed kernels
<apw> sforshee, the ones expected to release the monday after release; correct ?
<sforshee> apw: yes, unfortunately. When I sent them I thought they would be out before the release, either I was off or there was a delay in the cycle
<apw> sforshee, likley the extension of cycle-1 to 4 weeks has skewed things
<sforshee> yeah, wasn't paying close enough attention to that I guess
<bittin_> RC of 19.10 in 10 minutes
<apw> upgrades are triggered by our meta-data updates arn't they? so we might be able to wait on them
<tseliot> apw, sforshee: my patch in the nvidia drivers check if the flags are available in the default compiler, and disables that. This should work regardless of whether users have the updated kernel
<sforshee> tseliot: but other dkms modules are also affected
<sforshee> so unless we can make dkms do likewise ...
<apw> sforshee, so one of those "if the dkms upgrades first we are ok, otherwise not" situations
<sforshee> apw: well there's no such patch to dkms yet, but yes I suppose then we'd have that situation
<infinity> apw: We could delay the meta-release upgrade stuff, but we almost never do for more than a few days for non-LTS.
<apw> infinity, right, that, well the kernels for disco would release the monday after rellease
<infinity> apw: But if these are scheduled to go out on the Monday post-release, releasing them Wed/Thurs would only be a few business days early.  Maybe we can get testing all done by then?
<apw> infinity, would we need to do anyhing more than disco for this ?
<infinity> apw: Nope.
<apw> sforshee, ok so we need to go back to stable and tell them they need to expedite disco out early
<apw> slightly early
<infinity> apw: bionic needs to be fixed before disco EOLs (cause then the non-LTS upgrade path from bionic will be to eoan), but right now, bionic upgrades go through disco, so disco is the only place the fix must exist by eoan release.
<tseliot> sforshee, oh, right
<apw> infinity, i beleive all the kernls are fixed on that cycle, so monday right sforshee ?
<sforshee> correct
<infinity> apw: Sure, I gathered that, my point is that only disco needs to be expedited, cause the bionic fix isn't (yet) urgent.
<apw> infinity, ack, best to be utterly clear
<vorlon> infinity: there are some seeded nvidias coming in per tseliot's comments regarding criticality
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-435 [source] (eoan-proposed) [435.21-0ubuntu2]
<vorlon> there are linked bugs so if these need to be diverted to -updates they can be
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-430 [source] (eoan-proposed) [430.50-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (eoan-proposed) [390.129-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (eoan-proposed) [340.107-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: firewalld (eoan-proposed/universe) [0.7.1-1ubuntu9 => 0.7.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted firewalld [sync] (eoan-proposed) [0.7.2-1]
<tomreyn> the 19.10 RC bittin_ announced, would that go to http://cdimage.ubuntu.com/releases/19.10/ ?
-queuebot:#ubuntu-release- Unapproved: hedgewars (eoan-proposed/universe) [0.9.25-5build3 => 1.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (eoan-proposed) [1.0.0-2]
<infinity> tomreyn: I don't know who or what a bittin_ is, and no, RCs are just the dailies leading up to final release, there's no formal publishing for them.
<tomreyn> thanks infinity - i was referring to this above: <bittin_> RC of 19.10 in 10 minutes
<RikMills> what?
<infinity> Indeed, what? :)
<infinity> tomreyn: Let me reiterate the "I don't know who or what a bittin_ is", in the sense that he doesn't speak for the Ubuntu release team. :)
<RikMills> oh, in #ubuntu+1
<tomreyn> also here
<tomreyn> at :51
<infinity> So he did.  Right in the middle of a conversation I was in too.
<infinity> Mentally filtered it right out. :P
<tomreyn> thanks for clarifying, guess i got bittin_ rolled.
<infinity> tomreyn: We all get bittin_ sometimes.
<infinity> tomreyn: Anyhow, if you're curious about RCs because you want to help test a flavour or two, I expect based on the current state of things that are in flight that the first set will be posted to the ISO tracker sometime late tonight (US Pacificish time).
<infinity> Though that depends on how quickly sil2100 can shove langpack updates in.
<infinity> And some other bits and bobs.
<infinity> Not uncommon for me to spin the first RCs on Saturday from an airport, but I think we'll be earlier than that this cycle.  Maybe.
<RikMills> :)
<tomreyn> :) good luck there. i'll watch.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1021.21~18.04.1] (kernel)
<RikMills> don't watch. help test. ;)
<tomreyn> oh i most likely will (if maybe not the QA way). thanks for the invitation.
<sil2100> cwayne, plars, bdmurray: the pi respins have finished building: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20191010.1/
<sil2100> infinity: I'll try to be as fast as possible!
<cwayne> sil2100: ack thanks, should get pulled automatically for pi2/3, and plars can take care of 4
 * sil2100 whips language-pack-exporter
<sil2100> cwayne: thanks! Hopefully those should work on the pi4 fine - but that being said, I didn't check the manifests
<sil2100> Anyway, those are test images for now
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.22 => 229-4ubuntu21.23] (core)
-queuebot:#ubuntu-release- Unapproved: dbus (xenial-proposed/main) [1.10.6-1ubuntu3.4 => 1.10.6-1ubuntu3.5] (core)
-queuebot:#ubuntu-release- Unapproved: linux-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle (eoan-proposed/main) [5.3.0.1001.1 => 5.3.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-oracle (eoan-proposed/main) [5.3.0-1001.1 => 5.3.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-azure (eoan-proposed/restricted) [5.3.0-1002.2 => 5.3.0-1003.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (eoan-proposed/main) [5.3.0.1002.19 => 5.3.0.1003.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (eoan-proposed/universe) [5.3.0-1006.7 => 5.3.0-1007.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (eoan-proposed/universe) [5.3.0.1006.2 => 5.3.0.1007.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-oracle (eoan-proposed/restricted) [5.3.0-1001.1 => 5.3.0-1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (eoan-proposed/main) [5.3.0-1001.1 => 5.3.0-1002.2] (core, kernel) (sync)
<sil2100> Uploading language-packs, will approve them from the queue once they're all there
<cyphermox> seb128: vorlon: is ubiquity ready for upload?
<cyphermox> well, it doesn't matter really, I guess we'll definitely get a bugfix in to land the translation changes
<sil2100> infinity: packages being accepted right now
-queuebot:#ubuntu-release- Unapproved: linux-kvm (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (eoan-proposed/main) [5.3.0.1002.2 => 5.3.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (eoan-proposed/main) [5.3.0.1003.3 => 5.3.0.1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-aws (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [5.3.0.1002.2 => 5.3.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.17.19 => 5.3.0.18.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: konversation (eoan-proposed/universe) [1.7.5-1ubuntu2 => 1.7.5-1ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [149 => 150] (ubuntu-desktop)
<plars> sil2100: waveform: just to confirm - the pi2/3/4/cm3 all use the same raspi3 image now, correct? any plan to get rid of the raspi2 image there which seems to have a different checksum?
<sil2100> plars: ah, good catch! So actually we no longer build any raspi2 images, but apparently cdimage 'copies over' the old images everytime a new build is happening
<sil2100> So those images are actually from June
<sil2100> (the raspi2 ones)
<sil2100> Need to remove those, forgot about this cdimage functionality, just disabling the arch is not enough!
<infinity> sil2100: \o/
<rbalint> sil2100, could you please merge this for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373987
<rbalint> sil2100, infinity also could systemd please go in to eoan release?
<plars> sil2100: waveform: I have some fixups to somehow do to make some tests work with eoan so things may not show up on the image testing board for now.  But I'm at least booting and checking dmesg, apt-get, etc for now. So far most things are looking ok, but rpi3ap doesn't seem to boot in the lab. I'll try it at home too, but it only gets as far as "Starting kernel ..." then nothing
<ginggs> LocutusOfBorg: check in the log of the  	2019-10-10 14:33:35 UTC python-sparse/i386 test to see the actual version of python3-six that was installed
<LocutusOfBorg> ginggs, I melded them... no differences in apt
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: libpcap (eoan-proposed/main) [1.9.0-2build1 => 1.9.1-2] (core) (sync)
<vorlon> cyphermox: from seb's commit message I figured the .pot file might also need regenerating in the source branch; I hadn't looked that far yet, can you carry it across the finish line for upload?
<cyphermox> sure; I was questioning whether to wait for any last-minute fixes for something else
<cyphermox> otoh if we want any translations for it; there might be a chance to get some the sooner it's in rather than later
<cyphermox> OTOH, I think I see something odd there; there's already a translatable "Skip" string; looks like this was meant to be composited previously.... but it's also not going to work with shortcuts
<seb128>  cyphermox, "Skip" is another string even if technically it's the same word, the translation for that string exists in other templates (e.g nautilus) so it should be easy to just revalidate for translators
<cyphermox> seb128: what I mean is that I think this was meant to be composited in; but it never worked
<cyphermox> it's irrelevant anyway, we just need to remember how to update the templates.pot file now ;)
<cyphermox> I think I figured it out, just trying to get it right
<cyphermox> (templates.pot gets updated in one command, but the update is a bit wonky)
<cyphermox> heh, I just had the wrong command
<cyphermox> seb128: anyway; you okay with me uploading this now?
<seb128> cyphermox, well if there is no other change don't bother, I just did an upload of the template to launchpad manually
<seb128> so no need of a source upload
<cyphermox> ah, cool
<cyphermox> you mean debian/real-po/templates.pot manually edited to add _Skip ?
<seb128> cyphermox, I downloaded the current one from https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/+export , edited to add the string and uploaded on https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/+upload
<seb128> cyphermox, which worked, string is there, https://translations.launchpad.net/ubuntu/eoan/+source/ubiquity/+pots/ubiquity-debconf/fr/30/+translate
<cyphermox> cool
<seb128> cyphermox, we should use debconf-updatepo to update the tempalte/translations still before the next upload though otherwise my change will be overwriten by the import
<cyphermox> fwiw; updating debian/real-po/templates.pot from the debian/ubiquity.templates is as simple as running debconf-updatepo
<cyphermox> yup
<seb128> so if you want to do that and commit that would be useful
<seb128> thx
<cyphermox> (I'm applying that)
<seb128> great
<seb128> thx
-queuebot:#ubuntu-release- Unapproved: atk1.0 (eoan-proposed/main) [2.34.0-1 => 2.34.1-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: at-spi2-core (eoan-proposed/main) [2.34.0-2 => 2.34.0-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected at-spi2-core [sync] (eoan-proposed) [2.34.0-3]
-queuebot:#ubuntu-release- Unapproved: rejected atk1.0 [sync] (eoan-proposed) [2.34.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (eoan-proposed/main) [3.34.1-1 => 3.34.2-1] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.4-2ubuntu1 => 1.20.4-2ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (eoan-proposed/main) [19.10.2 => 19.10.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.24]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1005.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-32.34~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1025.28] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1005.9]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-32.34~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-32.34~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-32.34~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1025.28]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1022.22~18.04.3] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1022.22~18.04.3]
-queuebot:#ubuntu-release- Unapproved: gnome-2048 (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-tetravex (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (eoan-proposed/main) [1.58.0-1 => 1.58.1-1] (desktop-core, desktop-extra, mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: gpaste (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpaste [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-workspaces-to-dock (eoan-proposed/universe) [51-1 => 52-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-workspaces-to-dock [sync] (eoan-proposed) [52-1]
-queuebot:#ubuntu-release- Unapproved: ruby-gnome (eoan-proposed/universe) [3.3.8-2 => 3.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-gnome [sync] (eoan-proposed) [3.4.0-1]
#ubuntu-release 2019-10-11
-queuebot:#ubuntu-release- Unapproved: simple-scan (eoan-proposed/main) [3.34.0-0ubuntu1 => 3.34.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: hedgewars (eoan-proposed/universe) [1.0.0-2 => 1.0.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (eoan-proposed) [1.0.0-3]
-queuebot:#ubuntu-release- Unapproved: tcpdump (eoan-proposed/main) [4.9.3~git20190901-2 => 4.9.3-1] (core) (sync)
<LocutusOfBorg> tcpdump and libpcap fixes together ~26 CVEs, please accept...
-queuebot:#ubuntu-release- Unapproved: zfs-linux (eoan-proposed/main) [0.8.1-1ubuntu13 => 0.8.1-1ubuntu14] (core)
-queuebot:#ubuntu-release- Unapproved: zsys (eoan-proposed/universe) [0.2.1 => 0.2.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gdk-pixbuf (eoan-proposed/main) [2.39.2-3 => 2.40.0+dfsg-1] (core) (sync)
<RikMills> is FinalFreeze in effect? I can't see an email anywhere
<sil2100> I don't think it is
<RikMills> I don't want to do anything that would affect (apart from konversation in the queue). was just curious
<RikMills> oh, if it was I guess the britney freeze block would be in place. duh
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (eoan-proposed/universe) [3.0.0~b1~git2019061308.f722df5-0ubuntu3 => 1:2.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (eoan-proposed) [1:2.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (eoan-proposed/universe) [10.0.0~b2~git2019073018.9a62401-0ubuntu1 => 1:9.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [source] (eoan-proposed) [1:9.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ironic (eoan-proposed/universe) [1:13.0.0-0ubuntu1 => 1:13.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.5-1ubuntu1~18.04.1 => 1:1.6.5-1ubuntu1~18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (disco-proposed/main) [1:1.6.5-1ubuntu1 => 1:1.6.5-1ubuntu1.3] (core)
-queuebot:#ubuntu-release- Unapproved: manila-ui (eoan-proposed/universe) [3.0.0~b2~git2019073018.3f4d771-0ubuntu1 => 1:2.19.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (eoan-proposed) [1:2.19.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: four-in-a-row (eoan-proposed/universe) [1:3.28.0-2 => 1:3.34.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.438 => 1.439] (core)
-queuebot:#ubuntu-release- Unapproved: pikepdf (eoan-proposed/universe) [1.6.3+dfsg-1 => 1.6.4+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pikepdf [sync] (eoan-proposed) [1.6.4+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: tempest (eoan-proposed/universe) [1:19.0.0-4 => 1:22.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tempest [source] (eoan-proposed) [1:22.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.18 => 19.10.19] (core)
<didrocks> sil2100: hey! if you have time, it would be great to have ubiquity + ubuntu-meta (both are related) to tests the "let's try not to make zfs commands installed for everybody"
<didrocks> but as we changed tags, it means you need new zsys and zfs-linux as well
<didrocks> (but those 2 last should be trivial to review)
<didrocks> as we expect some people waiting for this week-end to try out ZFS, that will prevent breaking them
-queuebot:#ubuntu-release- Unapproved: ocrmypdf (eoan-proposed/universe) [8.0.1+dfsg-1ubuntu2 => 9.0.3+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ocrmypdf [sync] (eoan-proposed) [9.0.3+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: pyudev (eoan-proposed/main) [0.21.0-1 => 0.21.0-1ubuntu1] (ubuntu-desktop)
<doko> Laney, vorlon, sil2100: I'm trying to understand https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/k/kopanocore/20191010_172812_9fbe1@/log.gz
<doko> why is python not installable during the autopgkg test?
-queuebot:#ubuntu-release- Unapproved: accepted pyudev [source] (eoan-proposed) [0.21.0-1ubuntu1]
<xnox> doko:  it seems to me that intention is for this package to be python3 only, yet Use-python3-everywhere.patch doesn't patch a few scripts.
<xnox> doko:  these are left out?!
<xnox> ./tools/python-scripts/kopano-recreate-systemfolders:#!/usr/bin/python
<xnox> ./tools/python-scripts/kopano-localize-folders:#!/usr/bin/python
<xnox> ./tools/python-scripts/kopano-rules:#!/usr/bin/python
<xnox> ./tools/python-scripts/update-resource-recipients:#!/usr/bin/python
<xnox> ./tools/python-scripts/kopano-fix-ipm-subtree:#!/usr/bin/python
<xnox> ./ECtools/archiver/scripts/kopano-archiver-aclset:#!/usr/bin/python
<xnox> ./ECtools/archiver/scripts/kopano-archiver-restore:#!/usr/bin/python
<xnox> ./ECtools/archiver/scripts/kopano-archiver-aclsync:#!/usr/bin/python
<xnox> ./ECtools/utils/kopano-mailbox-permissions:#!/usr/bin/python
<xnox> doko:  as otherwise it appears to only install python3 module
<xnox> meaning python2 scripts will not work. Package bug?!
<xnox> *packaging bug
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (eoan-proposed/main) [1:15.0.0~rc1-0ubuntu2 => 1:15.0.0~rc1-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (eoan-proposed/universe) [8u232-b07-2 => 8u232-b07-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [source] (eoan-proposed) [8u232-b07-2ubuntu1]
<juliank> Laney: it seems we're hitting a bug (?) where http://autopkgtest.ubuntu.com/packages/a/apt/trusty/armhf is not being updated
<juliank> or did we somehow stop doing that for trusty?
<juliank> the tests are tming out
<juliank> it does work from the britney side :)
<doko> xnox: now succeeded. http://autopkgtest.ubuntu.com/packages/k/kopanocore/eoan/amd64
<xnox> doko:  fun!
-queuebot:#ubuntu-release- Unapproved: networking-l2gw (eoan-proposed/universe) [1:15.0.0~b2~git2019080116.364dd0a-0ubuntu1 => 1:15.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-l2gw [source] (eoan-proposed) [1:15.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4.4 => 0.4.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.5]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu12] (core)
<doko> xnox: so I think this is caused by pytest having different versions in -proposed and -released. this isn't supposed to work when the build uses the new version and the autopkg test the old version by default
<xnox> ew
<doko> now, fun relying on the "community" to get this migrated. it isn't in Debian either
-queuebot:#ubuntu-release- Unapproved: networking-hyperv (eoan-proposed/universe) [8.0.0~b1~git2019013104.83daa42-0ubuntu1 => 1:7.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (eoan-proposed) [1:7.3.0-0ubuntu1]
<doko> and many packages have fixes for the new pytest, so shipping the old one in eoan doesn't work either
<doko> more autopkg test failures in Ubuntu compared to Debian
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu2 => 242-7ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (eoan-proposed/multiverse) [1.20190819-0ubuntu1 => 1.20190819-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (eoan-proposed) [1.20190819-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (eoan-proposed/universe) [0.197 => 0.198] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: hedgewars (eoan-proposed/universe) [1.0.0-3 => 1.0.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (eoan-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- Unapproved: metacity (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (ubuntu-desktop) (sync)
<sforshee> can someone please approve my linux-firmware uploads for bionic/disco?
<apw> sforshee, there is already a l-f in bionic-proposed are you intending to replace that
<apw> as per PM i will reject those so you can replace them
<sforshee> ta
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (disco-proposed) [1.178.5]
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (bionic-proposed) [1.173.11]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.10 => 1.173.11] (core, kernel)
<sforshee> apw: new linux-firmware uploads incoming
-queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.178.4 => 1.178.5] (core, kernel)
<vorlon> xnox: https://bugs.launchpad.net/deja-dup/+bug/1847706 looks quite serious for eoan
<ubot5> Launchpad bug 1847706 in DÃ©jÃ  Dup "Deja Dup still tells python-gi (python 2) is required while duplicity is now python3" [Critical,Triaged]
<vorlon> seb128: ^^ xnox did the upload, but maybe desktop team wants to have a look at deja-dup state
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.17.19 => 5.3.0.18.21] (core, kernel) (sync)
<sforshee> infinity, apw: can the kernels in the eoan queue be approved? I'd like to get testing started asap
<infinity> sforshee: We're discussing it right now.
<infinity> sforshee: Just drawing straws for the review.
<infinity> sforshee: But also, how quickly can those be turned around and in a release pocket?
<sforshee> infinity: ack, thanks. Note that I just uploaded a new meta,  5.3.0.18.21, to fix snapdragon
<sforshee> infinity: the primary kernel is the same as what's in release except for snapdragon, so really I consider it already tested aside from snapdragon
<sforshee> so it should be fast
<infinity> sforshee: I'm okay with the new kernel not being in tonight's image, but it's pretty much got to be either deleted (because it sucks) or migrated (because it's awesome) by the end of the weekend at the latest, IMO.
<infinity> sforshee: Oh, if it's literally just one flavour (and quick boot smoketests on the rest, please?) maybe you can turn it around for tonight?  That would be ideal.
<sforshee> infinity: yeah, I think that's doable
<infinity> \o/
<xnox> vorlon: i think we had a custom patch for dynamic installation of dependencies, which should be dropped now.
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1027.30] (kernel)
<vorlon> infinity: are we missing an announcement of final freeze a la https://lists.ubuntu.com/archives/ubuntu-devel-announce/2019-April/001259.html ?
<infinity> vorlon: We sure are!  I blame the cuban restaurant last night.
<infinity> vorlon: I'll send one out shortly.  People got an extra day, yay them. :)
<vorlon> infinity: why, was doko there pouring mojitos?
<vorlon> infinity: ok
<infinity> vorlon: doko wasn't there, but the effect was indeed similar.
<xnox> vorlon:  testing a diff for deja-dup
<xnox> vorlon:  https://paste.ubuntu.com/p/Vtw3xmgMW4/ this might do it
<vorlon> xnox: what testing have you done, and what testing did you do before?
<vorlon> xnox: also, bug ref in changelog plz
<xnox> yeah, added the bug reference
<xnox> vorlon:  purging the dynamic dependencies now, trying to get old deja-dup going and asking for bad dependencies.
<vorlon> ok
<xnox> then will upgrade, to see if new deja-dup asks for better dependencies and works without asking for bad ones.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.439]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (eoan-proposed) [0.8.1-1ubuntu14]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.19]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (eoan-proposed) [0.2.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (eoan-proposed) [0.198]
<xnox> ok got dialog upon clicking backup now that i need bad packages
<xnox> with new one bad packages are not requested, only good ones, and then it can install them and asks for remote authentication to proceed.
<xnox> so all that seems to be good
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta [sync] (eoan-proposed) [5.3.0.18.20]
<xnox> not actually doing the backup, as i don't use deja-dup
-queuebot:#ubuntu-release- Unapproved: deja-dup (eoan-proposed/main) [40.1-1ubuntu1 => 40.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu12] (core)
<bdmurray_> xnox: I use deja-dup so could do a backup.
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.127 => 1.128] (core)
<xnox> bdmurray:  what do you backup to?
<infinity> That's exactly the sort of question I expect from a Russian.
<xnox> but like remove gvfs-backends python-gi pyhton-cloudfiles python-boto python-swiftclient
<xnox> install deja-dup compiled with the patch from the unapproved queue
<bdmurray> xnox: Some NAS
<xnox> kill deja-dup & deja-dup-monitor
<xnox> start deja-dup, and run manual backup it should ask to install things, and complete backup
<xnox> and it shouldn't ask to instally any python-* things, only python3-* things.
<xnox> bdmurray:  so i guess gvfs stuff, so remove gvfs-backends python-git
<xnox> bdmurray:  so i guess gvfs stuff, so remove gvfs-backends python-gi
<bdmurray> "install deja-dup" via dpig -i?
<xnox> bdmurray:  sudo apt install ./defa-dup_*.deb => after building it from the queue.
<xnox> dpkg -i is so last decade
<bdmurray> are you calling me old?
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu11 => 2.04-1ubuntu12] (core)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (eoan-proposed/universe) [0.54 => 0.55] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-18.19+1]
<bdmurray> xnox: I ended up with a bunch of unsatisfiable build-deps trying to build it
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
<xnox> bdmurray:  use sbuild?
<bdmurray> xnox: i did!
 * infinity grabs it.
<infinity> bdmurray: build-deps install fine here.
<infinity> bdmurray: I will send yuo the binaries by carrier pigeon.
<bdmurray> thanks, maybe its my mirror
<bdmurray> or manager brain
<powersj> ^ ha after 2 weeks
<infinity> powersj: He's a quick study.
<vorlon> :D
<infinity> bdmurray: lillypilly:~adconrad/deja-dup/
<bdmurray> Do I need to use the command line or something to get these? ;-)
<vorlon> apt install gvfs-infinity
<infinity> While attempting to fix the many Xen FTBFS bugs, I seem to have discovered a way to make a compiler use 40G of RAM.
<infinity> I might have done something wrong.
<xnox> bdmurray:  please don't use gvfs to get those =) teh deja-dup test needs gvfs-backends and python-gi uninstalled =)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (eoan-proposed) [5.3.0.18.21]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (eoan-proposed) [5.3.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (eoan-proposed) [5.3.0-18.19]
<bdmurray> xnox: https://pastebin.ubuntu.com/p/X6Z5j85n9w/
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu12]
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-18.19]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (eoan-proposed) [0.55]
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-17.18 => 5.3.0-18.19+1] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (eoan-proposed) [150]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-18.19+1] (core, kernel)
<bdmurray> The dpkg error was bug 1838711 fwiw
<ubot5> bug 1838711 in sendmail (Ubuntu) "package sendmail-bin 8.15.2-13 failed to install/upgrade: installed sendmail-bin package post-installation script subprocess returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/1838711
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (eoan-proposed) [1:13.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (eoan-proposed) [1:15.0.0~rc1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (eoan-proposed) [1.20.4-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (eoan-proposed) [19.10.3]
<tsimonq2> infinity: 40 GB? Those are rookie numbers.
<infinity> tsimonq2: I mean, it's all the RAM my laptop has.  I have no idea if there was an upper bound (but I'm assuming no).
<tsimonq2> infinity: Huh. Well, try compiling Chromium. :P
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-18.19+1] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-18.19+1] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-18.19+1] (core, kernel)
<infinity> bdmurray: Why on earth do you have sendmail installed?
<infinity> bdmurray: I wasn't calling you old before, but...
<infinity> tsimonq2: chromium uses much less...
<infinity> Like, an order of magnitude less.
<tsimonq2> infinity: When compiling?
<tsimonq2> Hm.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (eoan-proposed) [5.3.0.1007.3]
<infinity> tsimonq2: Uhh, yes?
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (eoan-proposed) [5.3.0-1007.8]
<infinity> tsimonq2: Given you can compile it on 32-bit machines with a 2:2 userspace:kernel split...
<tsimonq2> Huh.
<infinity> tsimonq2: Now, if you're running -j 40 or something and adding up ALL the compilers, sure.  But I was referring to one cc1 process. :P
<tsimonq2> Ahh, that's where we're different here.
<tsimonq2> "I don't compile with less than -j50." :P
<infinity> tsimonq2: You have a CPU with 50 threads?
<infinity> tsimonq2: Or you like things to be slower than they should be?
<tsimonq2> infinity: Nah, I usually go with -j6.
<infinity> Yeah, I'm 4 on my Intel (2 cores, SMT) laptop and 8 on my AMD (4 cores, SMT) laptop.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (eoan-proposed) [242-7ubuntu3]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-18.19+1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (eoan-proposed) [1.58.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [sync] (eoan-proposed) [3.34.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted libpcap [sync] (eoan-proposed) [1.9.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-2048 [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted tcpdump [sync] (eoan-proposed) [4.9.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tetravex [sync] (eoan-proposed) [1:3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted four-in-a-row [sync] (eoan-proposed) [1:3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted metacity [sync] (eoan-proposed) [1:3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gdk-pixbuf [sync] (eoan-proposed) [2.40.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted simple-scan [sync] (eoan-proposed) [3.34.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (eoan-proposed) [5.3.0.1003.3]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-aws [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-desktop-icons [source] (eoan-proposed) [19.10.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [sync] (eoan-proposed) [67ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.128]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-azure [sync] (eoan-proposed) [5.3.0-1003.3]
<infinity> xnox, bdmurray: Do we have any conclusions, re: deja-dup changes?
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (eoan-proposed/main) [5.3.0-1002.2 => 5.3.0-1003.3] (core, kernel) (sync)
<bdmurray> python-gi didn't get installed, I believe that is what xnox was fixing
<bdmurray> that's what the bug title is about too
<infinity> Well, what he was fixing was making sure py3 deps get installed instead of py2 ones, yes, but then it should also be tested to work. :)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-azure [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (eoan-proposed) [5.3.0.1003.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (eoan-proposed) [5.3.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (eoan-proposed) [5.3.0.1004.4]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules-gcp [sync] (eoan-proposed) [5.3.0-1004.4]
<bdmurray> infinity: I tested a backup but it was with a locally mounted nfs folder and now setting a storage location for an NFS server is failing
<bdmurray> Although it may have always failed and that's why I used a local mount.
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-gcp [sync] (eoan-proposed) [5.3.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.3.0-1003.3 => 5.3.0-1004.4] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-oracle [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (eoan-proposed/main) [5.3.0-1001.1 => 5.3.0-1002.2] (core, kernel) (sync)
<infinity> bdmurray: This is all very reassuring.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle [sync] (eoan-proposed) [5.3.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-oracle [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oracle [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (eoan-proposed) [5.3.0-1004.4]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oracle [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (eoan-proposed) [5.3.0.1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1027.30]
<xnox> hm
<xnox> bdmurray:  i was hoping for a successful backup end to end. with python3 only. i.e. the ssh one
<bdmurray> xnox: Okay, I've got an ssh backup running now
<xnox> bdmurray:  yeah =)
<bdmurray> Its the first backup so it'll be a bit.
<bdmurray> Hopefully before I go to to the airport!
-queuebot:#ubuntu-release- New: accepted salt-pylint [source] (eoan-proposed) [2019.6.7-1ubuntu1]
-queuebot:#ubuntu-release- New binary: salt-pylint [amd64] (eoan-proposed/none) [2019.6.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted salt-pylint [amd64] (eoan-proposed) [2019.6.7-1ubuntu1]
<infinity> RikMills: What's your take on the konversation in the queue?
<infinity> RikMills: doko missed documenting one patch in the changelog, but if the upload looks otherwise sane to you, let's take it?
<infinity> RikMills: (Maybe it should be tested to make sure the py2->py3 thing works)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1027.30~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: dkimpy-milter (eoan-proposed/universe) [1.1.2-1 => 1.1.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dkimpy-milter [sync] (eoan-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- Unapproved: spf-engine (eoan-proposed/universe) [2.9.0-4 => 2.9.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spf-engine [sync] (eoan-proposed) [2.9.1-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1027.30~16.04.1]
<RikMills> infinity: ok, I'll try some tests
-queuebot:#ubuntu-release- New sync: authheaders (eoan-proposed/primary) [0.12.0-1]
<RikMills> infinity: most scripts work. the scripts that are broken were broken before the switch, so looks fine to me
<RikMills> they are all non-essential anyway
<RikMills> but no regression I can see
<infinity> RikMills: So that's a +1 on accepting it?
<RikMills> infinity: yep
-queuebot:#ubuntu-release- Unapproved: accepted konversation [source] (eoan-proposed) [1.7.5-1ubuntu3]
<RikMills> :)
<bdmurray> infinity, xnox: okay the backup worked
<bdmurray> via ssh
 * bdmurray heads to airport
<infinity> bdmurray: Ta.
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (eoan-proposed) [40.1-1ubuntu2]
<vorlon> any core-devs want to review https://code.launchpad.net/~vorlon/ubuntu-release-upgrader/lp.1825655/+merge/373848 for me?
<infinity> vorlon: Looks reasonable to me.  Not using a browser logged into LP right now, so can't comment/approve on the MP.
<vorlon> infinity: ta
#ubuntu-release 2019-10-12
<sforshee> infinity: I have boot testing, everything passed but arm64. The logs in jenkins don't really let me see how it failed though, and there are no previous arm64 results for this test so I'm not sure if it was ever working
<sforshee> I don't have access to any arm64 kit to test it manually. arm64 autopktests are running fine
<infinity> sforshee: If arm64 autopkgtests show the new kernel in uname, then it's booting. :P
<sforshee> obviously
<infinity> autopkgtest [20:56:58]: testbed running kernel: Linux 5.3.0-18-generic #19-Ubuntu SMP Tue Oct 8 20:14:34 UTC 2019
<infinity> Looks sane to me.
<infinity> What isn't sane is that my window manager suddenly stopped raising on focus.  Wat.
<infinity> Or I accidentally set Firefox to always on top?  Extra Wat.
-queuebot:#ubuntu-release- Unapproved: debian-installer (eoan-proposed/main) [20101020ubuntu592 => 20101020ubuntu593] (core)
<infinity> sforshee: ^-- There's the d-i to unblock you.  Let it through with your blocking bug when you're ready.  I'll be back in a couple of hours.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (eoan-proposed) [20101020ubuntu593]
<sforshee> infinity: ack
-queuebot:#ubuntu-release- Unapproved: four-in-a-row (eoan-proposed/universe) [1:3.34.0-1 => 1:3.34.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: accerciser (eoan-proposed/universe) [3.34.0-1 => 3.34.1-2] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: weechat (eoan-proposed/universe) [2.4-1 => 2.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted weechat [sync] (eoan-proposed) [2.6-2]
-queuebot:#ubuntu-release- Unapproved: lepton-eda (eoan-proposed/universe) [1.9.6-1 => 1.9.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lepton-eda [sync] (eoan-proposed) [1.9.9-1]
-queuebot:#ubuntu-release- Unapproved: remake (eoan-proposed/universe) [4.1+dbg1.3~dfsg.1-2build1 => 4.1+dbg1.3~dfsg.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted remake [sync] (eoan-proposed) [4.1+dbg1.3~dfsg.1-3]
-queuebot:#ubuntu-release- Unapproved: tcpdump (eoan-proposed/main) [4.9.3-1 => 4.9.3-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted accerciser [sync] (eoan-proposed) [3.34.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted tcpdump [sync] (eoan-proposed) [4.9.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted four-in-a-row [sync] (eoan-proposed) [1:3.34.1-1]
-queuebot:#ubuntu-release- New sync: binutils-riscv64-unknown-elf (eoan-proposed/primary) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: gcc-riscv64-unknown-elf (eoan-proposed/universe) [8.2.0.2019.08+dfsg~rc1-1 => 8.3.0.2019.08+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-riscv64-unknown-elf [sync] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: popper.js (eoan-proposed/universe) [1.14.6+ds2-1 => 1.14.6+ds2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted popper.js [sync] (eoan-proposed) [1.14.6+ds2-2]
-queuebot:#ubuntu-release- Unapproved: twitter-bootstrap4 (eoan-proposed/universe) [4.3.1+dfsg2-1 => 4.3.1+dfsg2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted twitter-bootstrap4 [sync] (eoan-proposed) [4.3.1+dfsg2-3]
-queuebot:#ubuntu-release- Unapproved: vte2.91 (eoan-proposed/main) [0.58.0-1ubuntu1 => 0.58.2-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-usage (eoan-proposed/universe) [3.30.0-2 => 3.32.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-usage [sync] (eoan-proposed) [3.32.0-1]
-queuebot:#ubuntu-release- Unapproved: gitg (eoan-proposed/universe) [3.30.1-3 => 3.32.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gitg [sync] (eoan-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: freemedforms-project (eoan-proposed/universe) [0.9.4-2build1 => 0.9.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freemedforms-project [source] (eoan-proposed) [0.9.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: insighttoolkit4 (eoan-proposed/universe) [4.12.2-dfsg1-4ubuntu10 => 4.12.2-dfsg1-4.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted insighttoolkit4 [source] (eoan-proposed) [4.12.2-dfsg1-4.1ubuntu1]
<bittin> Ubuntu 19.10 RC2 on Monday and release on Thursday
<bittin> infinity, popey Wimpress Joining the Ubuntu 15 year party over IRC in 1 hour also updating to 19.10 RC2 and real release next week :)
<bdmurray> vorlon: Can you have a look at bug 1845529?
<ubot5> bug 1845529 in bash-completion (Ubuntu) "bash completion in 19.10 shows `awk: line 18: function gensub never defined` on ``umount /dev/<Tab>`" [High,Confirmed] https://launchpad.net/bugs/1845529
<bdmurray> jibel: Have you seen bug 1847785?
<ubot5> bug 1847785 in ubiquity (Ubuntu) "eoan: zfs install option - don't install on systems less than 4GB of memory" [High,Confirmed] https://launchpad.net/bugs/1847785
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (eoan-proposed/universe) [1.256 => 1.257] (ubuntu-mate)
<infinity> bittin: Can you please stop spamming people on IRC and email.  There's no such thing as "RC2", and I have no intention of attending an IRC party while I'm in an airplane.  You're not being helpful.
<bittin> sorry
<bittin> Happy 15th Birthday Ubuntu
<infinity> And now I feel old. :)
-queuebot:#ubuntu-release- Unapproved: gscan2pdf (eoan-proposed/universe) [2.5.5-1 => 2.5.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gscan2pdf [sync] (eoan-proposed) [2.5.7-1]
-queuebot:#ubuntu-release- Unapproved: iagno (eoan-proposed/universe) [1:3.32.0-1 => 1:3.34.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted iagno [sync] (eoan-proposed) [1:3.34.2-1]
-queuebot:#ubuntu-release- Unapproved: omins (eoan-proposed/universe) [0.2.0-7.1ubuntu2 => 0.2.0-8] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: slime (eoan-proposed/universe) [2:2.24+dfsg-1ubuntu1 => 2:2.24+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted slime [sync] (eoan-proposed) [2:2.24+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: cl-asdf (eoan-proposed/universe) [2:3.3.3-2ubuntu1 => 2:3.3.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cl-asdf [sync] (eoan-proposed) [2:3.3.3-3]
-queuebot:#ubuntu-release- Unapproved: golang-gocapability-dev (eoan-proposed/universe) [0.0~git20160928.0.e7cb7fa-2ubuntu1 => 0.0+git20180916.d983527-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-gocapability-dev [sync] (eoan-proposed) [0.0+git20180916.d983527-1]
-queuebot:#ubuntu-release- Unapproved: gsl-doc (eoan-proposed/multiverse) [2.3-1ubuntu1 => 2.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gsl-doc [sync] (eoan-proposed) [2.6-1]
-queuebot:#ubuntu-release- Unapproved: dieharder (eoan-proposed/universe) [3.31.1-7ubuntu1 => 3.31.1-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ess (eoan-proposed/universe) [18.10.2-1ubuntu1 => 18.10.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dieharder [sync] (eoan-proposed) [3.31.1-8]
-queuebot:#ubuntu-release- Unapproved: accepted ess [sync] (eoan-proposed) [18.10.2-2]
-queuebot:#ubuntu-release- Unapproved: jupyter-sphinx-theme (eoan-proposed/universe) [0.0.6+ds1-8ubuntu1 => 0.0.6+ds1-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Eoan Final] (20101020ubuntu593) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Eoan Final] (20101020ubuntu593) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Eoan Final] (20101020ubuntu593) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Eoan Final] (20101020ubuntu593) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Eoan Final] (20101020ubuntu593) has been added
-queuebot:#ubuntu-release- Unapproved: accepted jupyter-sphinx-theme [sync] (eoan-proposed) [0.0.6+ds1-9]
-queuebot:#ubuntu-release- Unapproved: python-csb (eoan-proposed/universe) [1.2.5+dfsg-4ubuntu1 => 1.2.5+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-csb [sync] (eoan-proposed) [1.2.5+dfsg-5]
<infinity> Laney: Did you have any hope that you'd fix glib before release?
<infinity> Laney: Unfortunately, gdk-pixbuf picked up a versioned dep on it. :/
<infinity> Laney: (and it stuck in proposed as a result)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (eoan-proposed) [1.257]
-queuebot:#ubuntu-release- Unapproved: accepted omins [sync] (eoan-proposed) [0.2.0-8]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (eoan-proposed) [0.58.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (eoan-proposed/universe) [2.230 => 2.231] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (eoan-proposed) [2.231]
<infinity> Britney block is going into place as soon as vte and the two above metas migrate.
<infinity> Unless VTE regresses, then sucks to be it.
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Final Freeze | 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, cheque or gin | melius malum quod cognoscis
-queuebot:#ubuntu-release- New: accepted authheaders [sync] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [sync] (eoan-proposed) [2.32.2019.08+dfsg-1]
<infinity> vorlon: Do you have any context on the 3 python modules (seem openstack-related) in the NEW queue?
<infinity> No one's bugged me about procressing them, so my assumption it they're not particularly critical, but they've been there a while.
-queuebot:#ubuntu-release- New binary: authheaders [amd64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [s390x] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [i386] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [ppc64el] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [amd64] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [arm64] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-riscv64-unknown-elf [armhf] (eoan-proposed/universe) [2.32.2019.08+dfsg-1] (no packageset)
<infinity> Oh, nevermind VTE, it's also going to get stuck behind glib2.0 :(
<jbicha> ð¢
<infinity> jbicha: Last I heard from Laney, the glib regression was legit.  So, get that fixed by Monday/Tuesday, and we can get gdk-pixbuf and vte in with it before the final spins.
<infinity> jbicha: Alternately, we can remove glib and rebuild some rdeps to not get the new binary dep.
<infinity> jbicha: But I'll discuss that with Laney on Monday.
<infinity> cjwatson: That copy-with-move stuff can't come soon enough.  Just lost an RC copy in flight.  Luckily, I noticed cause it was in a batch of all of 3 packages I was waiting on.
-queuebot:#ubuntu-release- Unapproved: sleepyhead (eoan-proposed/universe) [1.0.0-beta-2+dfsg-6 => 1.0.0-beta-2+dfsg-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sleepyhead [sync] (eoan-proposed) [1.0.0-beta-2+dfsg-7]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Final] (20191012) has been added
<cjwatson> infinity: *nod*
-queuebot:#ubuntu-release- Unapproved: beads (eoan-proposed/universe) [1.1.18+dfsg-3 => 1.1.18+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted beads [source] (eoan-proposed) [1.1.18+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted authheaders [amd64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [arm64] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [i386] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [s390x] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [amd64] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [ppc64el] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted binutils-riscv64-unknown-elf [armhf] (eoan-proposed) [2.32.2019.08+dfsg-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Final] (20191012) has been added
<infinity> wgrant: Any idea who maintains the other end of seeded-in-ubuntu (and/or how to get fixes in)?
<infinity> wgrant: It seems to be missing picking up some image manifests we'd want (like the server daily-preinstalled raspi images, for instance, meaning "linux-raspi2" isn't listed as seeded anywhere)
<infinity> Side note, we really should consider bringing some of these fairly critical ubuntuwire services in-house (while keeping commit rights for the community people who contributed them).
<infinity> At least seeded-in-ubuntu and reverse-depends get far too much use to not have an SLA.
 * infinity manually adds some raspi2 stuff to the britney block as a stopgap.
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Final] (20191012) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Final] (20191012) has been added
<tsimonq2> infinity: While you're at it, http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ would be really cool to migrate onto something less 2011.
<tsimonq2> I have sent patches to no avail.
 * tsimonq2 is curious about what exactly ubuntuwire.org is/was.
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [s390x] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [amd64] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [i386] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [ppc64el] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [arm64] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-riscv64-unknown-elf [armhf] (eoan-proposed/universe) [8.3.0.2019.08+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [amd64] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [armhf] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [ppc64el] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [arm64] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [s390x] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gcc-riscv64-unknown-elf [i386] (eoan-proposed) [8.3.0.2019.08+dfsg-1]
<xnox> infinity: hey, Ubuntu server subiquity s390x is missing from the manifest, but should be releasable. With added netboot it installs fine on LPAR onto zfcp drives. Which is the most common configuration of mainframes we support.
<xnox> Could you please add it to the release manifest?
<infinity> xnox: I can do, if we're sure we want to release it.
<xnox> Yes, we are.
<xnox> And the kernel is good, all s390x fixes are in.
<xnox> Thanks, good night, see you on Monday.
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Eoan Final] (20191012) has been added
<infinity> xnox: ^--- There you go.
<infinity> xnox: Althought, didn't we also have a requirement that sane automated testing also be in place?
<infinity> xnox: Anyhow, we can discuss with Steve, server team, etc on Monday and remove it again if needed.  It's there for now.
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:19.10.14 => 1:19.10.15] (core)
<infinity> tsimonq2: I'm boarding in minutes (seconds?) here.  Can you send a call-for-testing to ubuntu-quality, CC to ubuntu-release, noting that base-files and ISO labels are intentionally not final, but everything else is in a place where we want as much testing as possible going into next week?
<infinity> tsimonq2: Thanks in advance, release padawan. :P
<vorlon> bdmurray: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1845529/comments/6 ff is correct, this is a bug in bash-completion for not being compatible with POSIX awk
<ubot5> Launchpad bug 1845529 in bash-completion (Ubuntu) "bash completion in 19.10 shows `awk: line 18: function gensub never defined` on ``umount /dev/<Tab>`" [High,Confirmed]
<infinity> And I'll see everyone on the other side of the ocean.
<vorlon> infinity: no context on those NEW packages, no; likewise I've not been bugged so didn't prioritize them
<infinity> vorlon: If you can get anything out of the uploaders to indicate if we should either reject or process them, that'd be shiny.
 * infinity runs off as he's called to board.
#ubuntu-release 2019-10-13
<tsimonq2> infinity: Sure, on it.
<tsimonq2> .
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-release/2019-October/004840.html
-queuebot:#ubuntu-release- Unapproved: gap-grape (eoan-proposed/universe) [4.8.2+ds-1ubuntu1 => 4.8.2+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gap-grape [sync] (eoan-proposed) [4.8.2+ds-2]
-queuebot:#ubuntu-release- Unapproved: freefem++ (eoan-proposed/universe) [3.61.1+dfsg1-4ubuntu1 => 3.61.1+dfsg1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freefem++ [sync] (eoan-proposed) [3.61.1+dfsg1-5]
-queuebot:#ubuntu-release- Unapproved: expeyes-doc (eoan-proposed/universe) [4.3-1ubuntu1 => 4.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted expeyes-doc [sync] (eoan-proposed) [4.3-2]
-queuebot:#ubuntu-release- Unapproved: c++-annotations (eoan-proposed/universe) [11.1.1-1ubuntu1 => 11.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: stealth (eoan-proposed/universe) [4.02.00-1ubuntu1 => 4.02.00-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted c++-annotations [sync] (eoan-proposed) [11.1.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted stealth [sync] (eoan-proposed) [4.02.00-2]
-queuebot:#ubuntu-release- Unapproved: mathgl (eoan-proposed/universe) [2.4.4-3ubuntu1 => 2.4.4-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mathgl [sync] (eoan-proposed) [2.4.4-4]
-queuebot:#ubuntu-release- Unapproved: tstools (eoan-proposed/universe) [1.11-1ubuntu2 => 1.13~git20151030-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tstools [sync] (eoan-proposed) [1.13~git20151030-1]
-queuebot:#ubuntu-release- Unapproved: python-schema-salad (eoan-proposed/universe) [4.5.20190815125611-2ubuntu1 => 4.5.20190815125611-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-schema-salad [sync] (eoan-proposed) [4.5.20190815125611-3]
-queuebot:#ubuntu-release- Unapproved: goldencheetah (eoan-proposed/universe) [1:3.5~DEV1810-1ubuntu1 => 1:3.5~DEV1903-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pycode-browser (eoan-proposed/universe) [1:1.02+git20181006-3ubuntu1 => 1:1.02+git20181006-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goldencheetah [sync] (eoan-proposed) [1:3.5~DEV1903-1]
-queuebot:#ubuntu-release- Unapproved: accepted pycode-browser [sync] (eoan-proposed) [1:1.02+git20181006-5]
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [5.3.0.1003.3 => 5.3.0.1003.4] (core, kernel)
<sforshee> infinity, apw: I uploaded a new linux-meta-aws to add a missing linux-modules-extra-aws package
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [source] (eoan-proposed) [5.3.0.1003.4]
-queuebot:#ubuntu-release- New binary: linux-meta-aws [amd64] (eoan-proposed/main) [5.3.0.1003.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-meta-aws [arm64] (eoan-proposed/main) [5.3.0.1003.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-meta-aws [amd64] (eoan-proposed) [5.3.0.1003.4]
-queuebot:#ubuntu-release- New: accepted linux-meta-aws [arm64] (eoan-proposed) [5.3.0.1003.4]
-queuebot:#ubuntu-release- Unapproved: synaptic (eoan-proposed/universe) [0.84.6ubuntu1 => 0.84.6ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted synaptic [source] (eoan-proposed) [0.84.6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: sleepyhead (eoan-proposed/universe) [1.0.0-beta-2+dfsg-7 => 1.0.0-beta-2+dfsg-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sleepyhead [source] (eoan-proposed) [1.0.0-beta-2+dfsg-7ubuntu1]
<ginggs> infinity: sleepyhead ^
-queuebot:#ubuntu-release- Unapproved: commonmark-bkrs (eoan-proposed/universe) [0.5.4+ds-3ubuntu1 => 0.5.4+ds-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted commonmark-bkrs [sync] (eoan-proposed) [0.5.4+ds-4]
-queuebot:#ubuntu-release- Unapproved: tqdm (eoan-proposed/universe) [4.28.1-1ubuntu1 => 4.30.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tqdm [sync] (eoan-proposed) [4.30.0-1]
-queuebot:#ubuntu-release- Unapproved: git-lfs (eoan-proposed/universe) [2.8.0-2ubuntu1 => 2.8.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted git-lfs [sync] (eoan-proposed) [2.8.0-4]
-queuebot:#ubuntu-release- Unapproved: ghdl (eoan-proposed/universe) [0.35+git20181129+dfsg-3ubuntu1 => 0.35+git20181129+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ghdl [sync] (eoan-proposed) [0.35+git20181129+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: ngspice (eoan-proposed/universe) [30.2-1ubuntu1 => 31.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ngspice [sync] (eoan-proposed) [31.3-1]
-queuebot:#ubuntu-release- Unapproved: gedit-plugins (eoan-proposed/universe) [3.34.0-2~build1 => 3.34.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gedit-plugins [sync] (eoan-proposed) [3.34.0-3]
<infinity> ginggs: Thanks for the sleepyhead fix, that cleared out the last NBS.
<ginggs> infinity: np!
<RikMills> https://www.youtube.com/watch?v=h2XhccvmJCU
<RikMills> Live now
<RikMills> ^^ that was meant to be in #ubuntu-flavors
<xnox> infinity:  sane atuomated testing has been in place for s390x for a while now, using KVM
<xnox> infinity:  sane ability to netboot was not there.
<xnox> infinity:  arguably we should be adding netbooting tests to the CI
<xnox> infinity:  i.e. s390x autopromotion is in place.
<xnox> (not auto, but i mean like gated on CI auto tests)
<xnox> mwhudson:  so my reading is that we install linux-firmware in the modules squashfs stage, but don't package them in the squashfs nor mount it.
<xnox> mwhudson:  all kernel flavours for bare-metal depend on linux-firmware, imho that should simply be preseeded in the base layer. Although that will make us more different from a stock lxd-server squashfs.
<xnox> mwhudson:  where do you want to seed/install linux-firmware? in the filesystem.squashfs, instatter.sauqshfs, or the modules.squashfs?
 * xnox is slightly leaning more towards filesystem.squashfs but installer.squashfs will do for now too
<xnox> mwhudson:  context is inability to have network cards working during installation time, as kernel fails to find firmware blobs to upload into the network cards.
<xnox> https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/374059mwhudson:  infinity: as git
<xnox> mwhudson:   ^
<xnox> https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1847835
<ubot5> Launchpad bug 1847835 in livecd-rootfs (Ubuntu) "Firmware missing on Eaon Ermine live install media" [Critical,New]
<xnox> also uploaded into the queue
<xnox> or if there are other things to fix, there is just the change as a commit cherrypickable. without the tag/release commit.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.618 => 2.619] (desktop-core)
<mwhudson> xnox: argl
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.619]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (eoan-proposed) [1:19.10.15]
