#ubuntu-release 2011-02-14
<skaet> cjwatson - Bug #717699 showed up on the iso tracker for 10.04.2, can you have a look?
<ubot4> Launchpad bug 717699 in casper (Ubuntu) "Lucid 20110211.1-desktop and 20110211.3-alternate amd64, gfxboot bug (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/717699
<apw> cjwatson, is that not the bug triggered when the usb device is built on a system which is too far away from the system on the image ?  the gfxboot option thingy
<ev> might I kindly ask that someone NEW oem-config-slideshow-ubuntu
<cjwatson> skaet: what apw said.  I've duped it
<cjwatson> not a bug in 10.04.2 as such, more a bug in later releases
<apw> cjwatson, is this somewhere that the dreaded hybrid thingy might hep
<apw> help
<cjwatson> yes, but it's not quite that simple either - ev has been wrestling with it
<cjwatson> we still (potentially) have to make some modifications to the image
<cjwatson> ev: done
<ev> cjwatson: thanks bunches
<cjwatson> skaet: lucid DVDs are in place now
<cjwatson> jibel: ^-
<cjwatson> (for i386 too, I mean)
<jibel> cjwatson, thanks, syncing.
<jibel> skaet, there's no upgrade test cases on the tracker ?
<jibel> cjwatson, skaet , xubuntu i386 images failed to boot, with no bootable medium found.
<cjwatson> odd error.  can anyone else reproduce that?
<jibel> charlie-tca reproduce that
<cjwatson> it'll be three hours absolute minimum before I can look, as I'd already started rsyncing another image
<cjwatson> perhaps somebody else can track down what's wrwong?
<cjwatson> *wrong
<charlie-tca> bug 718749
<ubot4> Launchpad bug 718749 in ubiquity (Ubuntu) "Xubuntu i386 Lucid 10.04.2 images will not boot (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/718749
<cjwatson> not a ubiquity bug
<cjwatson> it's only a ubiquity bug if it actually gets as far as the installer
<cjwatson> (for the record)
<charlie-tca> sorry, I didn't know which package it was for sure
<cjwatson> install dumpet, see what it says for that image
<cjwatson> (dumpet -i foo.iso)
<charlie-tca> desktop image - does not contain an El Torito bootable image. BootRecordIndicator: 2
<ev> that would do it
<charlie-tca> alternate 386 is the same
<cjwatson> the only obvious thing that might have gone wrong is that it *really* doesn't like -joliet-long
 * cjwatson digs up the build logs
<cjwatson> oh shit
<cjwatson> +    echo -n "-joliet-long " > $N.mkisofs_opts
<cjwatson> > is NOT the same as >>
<cjwatson> sorry folks, mea culpa
<cjwatson> i386 DVD will be affected too
<charlie-tca> Thanks for looking
<cjwatson> thanks for spotting it.  will fix ASAP
<cjwatson> rebuilds in progress
<ogra> hmpf, someone edited the cdimage branch directly on antimony
<cjwatson> the branch, or the working tree?
<ogra>  /srv/cdimage.ubuntu.com shows me a diff
<ogra> in buildlive and publish-release
<cjwatson> yes, those are long-standing, please leave them in place until I figure out what to do about them
<ogra> hmm, and the buildlive change is from last year (!)
<ogra> ah, k
<ogra> if its on purpose i'm fine
<cjwatson> I know about it, at least
<ogra> k
<skaet> cjwatson, which images are slated for rebuild at this time?  (looks like some need to be marked rebuilding on the tracker, ubuntu DVD, Xubuntu, ???)
<cjwatson> I'll mark them now
<cjwatson> just Xubuntu plus Ubuntu DVD i386
<cjwatson> and DVDs weren't posted anyway
<skaet> Xubuntu marked now for rebuild
<skaet> jibel, upgrade test cases added for all except xubuntu,  will add those with the new images
<skaet> thanks for catching it.  :)
<jibel> skaet, seen that. Thanks.
<jibel> skaet, we have verified all the images excepted server. 2 major issues have been identified so far: bug 718749 (rebuilding in progress) and bug 645818 (not a bug in lucid)
<ubot4> jibel: Bug 718749 on http://launchpad.net/bugs/718749 is private
<ubot4> jibel: Bug 645818 on http://launchpad.net/bugs/645818 is private
<jibel> ubot4, you're wrong
<ubot4> Factoid "you're wrong" not found
<jibel> skaet, I've run the upgrades for K/Ubuntu desktop last week without any problem.
<charlie-tca> argue with the 'bot? ;-)
<skaet> jibel, thanks for the update.   Can someone with an existing lucid system confirm they can make usbs/cds and install a 10.04.2 system that way?  (ie. not impacted by 645818)
<jibel> sure, we'll find a volunteer :-)
<jibel> skaet, I'll change the notice on the tracker to mention the issue with USBs created on 10.10+, do you agree ?
<skaet> jibel,  good idea.  :)
<apw> skaet, this lbm filename limit prob, is there a bug for that ?
<skaet> cjwatson, ^^?
<apw> skaet, and can you remind me why this puppy is even on the CD ?
<skaet> apw,  its the image from bjf and sconklin we'll be using for 10.04.2
<apw> skaet, LBM seems a strange package to end up on a CD ever ?
 * skaet puzzles, and goes back to check some IRC logs...  LBM?
<apw> linux-backport-modules-*
 * skaet nods
<skaet> apw, bjf - [01:01] <cjwatson> genisoimage: Error: CD1/pool/main/l/linux-backports-modules-2.6.32/linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-generic_2.6.32-28.27_i386.deb and CD1/pool/main/l/linux-backports-modules-2.6.32/linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-generic-pae_2.6.32-28.27_i386.deb have the same Joliet name
<skaet> [01:01] <cjwatson> Joliet tree sort failed.
<tgardner> skaet, why are LBM packages being seeded on the CDROM ?
<cjwatson> phone, minute
<skaet> tgardner, will let the expert comment.  :)
<apw> skaet, the problem is that the meta packages are also too long in some cases,
<apw> so changing their name without a transitional package seems a problem
<apw> but having the transitional package will trigger the same problem
<tgardner> apw, those are _new_ meta packages since Lucid was released, right?
<apw> tgardner, the too long ones are new yes
<apw> in all cases the names which are too long were not in the -release pocket
<cjwatson> the DVD includes practically everything that's in supported
<cjwatson> (technically, supported-common, which includes supported-kernel-common)
<cjwatson> so linux-backports-modules has been there for a long time
<cjwatson> skaet: anyway, the new DVDs haven't finished building yet
<cjwatson> -joliet-long should have worked around all this
 * skaet will keep fingers crossed
<apw> cjwatson, ok so if we rename shorter which isn't impossible, what can we do about transitional pacages
<apw> packages, to pull people to the new names, is there some way we can exclude those from the CD?
<apw> DVD
<cjwatson> sure, but why don't we just ignore the problem for lucid
<apw> cjwatson, i am all for ignoring it :)
<cjwatson> and then we shouldn't have to worry about it since we don't do transitionals for LBM for lucid->? anyway
<tgardner> cjwatson, correct
<apw> ok as there is no point release maverick we only have to worry about natty
<apw> and we can fix these names before we do lbm for there
<cjwatson> we can just make sure that package names are unique in the first 64 characters in the future
<cjwatson> I only applied the debian-cd change for lucid i386, so it'll blow up on us in the future again if we violate that
<cjwatson> (and TBH, it may not be a massive problem as Joliet is just for Windows compat, but we should probably be a little careful in case we happen to change something that might affect Wubi - this shouldn't, though)
<apw> cjwatson, cool
<tgardner> cjwatson, we'll take steps to correct the meta package names for Natty and announce on ubuntu-devel, etc
<apw> cjwatson, is there an LP bug for this puppy?
<cjwatson> doesn't look like it
<cjwatson> I didn't mention one in the debian-cd commit message, anyway
<apw> cjwatson, ok don't think we need one just wanted to hoover it up if it was there
<skaet> apw, ack
<apw> skaet, so i think we have a plan... do nothing and don't mess up natty
<skaet> apw,  heh,  "do nothing" seems a bit ambiguous.  I read it as no change for lucid, email to u-devel about 64 char restriction so we don't mess natty.  ;)
<apw> yeah do nothing for existing releases, email out a warning for natty, and then get natty right
<skaet> :)
<cjwatson> since this is the first time it's bitten us in 6+ years, I'm not desperately worried about it being a pervasive problem
<apw> cjwatson, yeah, though it is always that annoying kernel team pushing the boundaries
<tgardner> apw, I pushed a patch to ubuntu-natty-meta that sets the format for future LBM compat-wireless package names
<apw> tgardner, you are a star
<tgardner> apw, which reminds me, we need to upload an LBM soon just as a placeholder or we'll end up having to write a MIR after the fact.
<apw> tgardner, ok ... what do we have which it would produce
<tgardner> apw, its always empty to begin with.
<apw> no compat wiress, no also, i guess smb's input might exist
<tgardner> I guess, if it hasn't gone upstream
<apw> if we didn't have to bump abi on all of these packages, it owuld be nice for them to be separate source
<tgardner> apw, don't go there :) way too much work.
<apw> yeah i konw, well unless we could make them dkms packages
<apw> we have 11.10 to think about that for
<Riddell> cjwatson: I removed a language pack from kubuntu lucid live if you want to respin it to stop oversizing
<skaet> cjwatson, pitti,  for the release change log,   should it be since 10.04.1 or since 10.04 - what's the precedent?
<cjwatson> since 10.04.1
<skaet> cjwatson,  thanks
<cjwatson> Xubuntu reposted
<charlie-tca> thanks
<cjwatson> er, oops, wrong version
<cjwatson> not December yet
<cjwatson> ok, fixed, and Ubuntu DVDs posted
<cjwatson> Riddell: ok, thanks - shall I just respin i386, since that's the only one affected?
<Riddell> cjwatson: yes
<cjwatson> ok, respinning
 * skaet -> lunch,  biab
<charlie-tca> Xubuntu amd64 desktop image should be okay now, did not resize the ppc images
<charlie-tca> Can respin that image only, please.
<cjwatson> to clarify: respin Xubuntu desktop amd64?
<charlie-tca> please. It should no longer be oversize
<cjwatson> Riddell: Kubuntu still oversized
 * skaet back
<marjo> skaet: https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/645818
<ubot4> Launchpad bug 645818 in usb-creator (Ubuntu Natty) (and 3 other projects) "10.04.1 image created in Maverick does not boot in my Dell Mini9 (affects: 58) (dups: 4) (heat: 178)" [Critical,Triaged]
<skaet> marjo,  yes?  jibel has documented workaround on isotracker.
<marjo> skaet: ack
<marjo> skaet: just FYI, per jibel's request,  I created a 10.04.2 bootable USB with usb-creator-gtk on Lucid. I was able to boot to a live session with this USB image.
<marjo>  System that booted is an Acer Aspire One Model ZA3.
<skaet> marjo,  excellent thanks - good to know.  :)
<ScottK> skaet: But the bug was for an image created on Maverick, not an image created on Lucid?
<skaet> ScottK,  yes,  I plan on marking it invalid, after I put out the release notes.   Just wanted it to show up so it didn't get overlooked.
<skaet> I put a comment in the bug to that effect.
<ScottK> Ah.  I see.
<cjwatson> skaet: please don't mark the bug invalid for natty
<cjwatson> we still want to figure something out for that - it's just hard
<cjwatson> (and maverick too)
<skaet> cjwatson,  ack, was just planning on it for lucid
#ubuntu-release 2011-02-15
<Riddell> hmm, the kubuntu CD still contains language-pack-kde-pl which I removed from the live seed
<Riddell> (lucid)
<Riddell> I might respin it again for good luck
<cjwatson> check the Task fields in lucid-updates first
<cjwatson> oh, heck, maybe even in lucid, I'm not sure
<cjwatson> hopefully it is actually possible to remove packages from tasks in stable releases ...
<cjwatson> (feel free to respin it after checking though)
<Riddell> cjwatson: language-pack-kde-pl-base in lucid-updates still has Task: kubuntu-live
<cjwatson> sigh
<cjwatson> let me think
<cjwatson> cron.germinate won't be run for lucid
<cjwatson> I could perhaps hit the overrides by hand
<cjwatson> done, but I'm also going to need a by-hand publisher run
<cjwatson> I'll do that after this normal one ...
<Riddell> cjwatson: why by hand?
<cjwatson> because the publisher only runs on a suite if it thinks it's dirty, and there's no way to mark it as such when you change something external to the Launchpad database
<Riddell> I see
<charlie-tca> cjwatson: we removed three language packs from the Lucid 10.04.2 seeds, but the image has not resized at all. I still see the image from yesterday (2011-02-14.2)
<charlie-tca> That is for the Xubuntu Desktop amd64 image
<cjwatson> same problem as Riddell
<cjwatson> argh, wish you'd told me 30 minutes ago :)
<cjwatson> which packages exactly did you remove?
<charlie-tca> sorry, not up yet
<charlie-tca> bn, hi, and ar
<charlie-tca> I don't know the exact packages, just the three language packs
<cjwatson> dealing with it now
<cjwatson> hopefully
<charlie-tca> thank you
<cjwatson> oh, DAMN IT
<cjwatson> missed a bit, have to go round again
<charlie-tca> if it fits a cd and works, I don't care if it has an extra package, do I?
<cjwatson> I need to make it consistent if I'm doing this kind of manual hackery
<cjwatson> otherwise on my head be it
<charlie-tca> correct,
<charlie-tca> sorry again. Will try harder to get things you need.
<cjwatson> ah well
<cjwatson> I think I've fixed it up; I'm not going to push directly to mirrors, though, but rather let the next auto run do that
<cjwatson> so that'll be about an hour
<cjwatson> Riddell,charlie-tca: rebuilding Kubuntu desktop i386 and Xubuntu desktop amd64 now
<jibel> skaet, cjwatson xubuntu alternate are uninstallable, abiword has broken dependencies
<jibel> Feb 15 13:44:17 in-target: The following packages have unmet dependencies:
<jibel> Feb 15 13:44:17 in-target:   abiword-plugin-grammar: Depends: liblink-grammar4 (>= 4.2.2) but it is not installable
<jibel> Feb 15 13:44:17 in-target:   abiword-plugin-mathview: Depends: libgtkmathview0c2a but it is not installable
<cjwatson> hm, yes, http://cdimage.ubuntu.com/xubuntu/lucid/daily/current/report.html agrees
<cjwatson> that's odd, it's fine in chdist
 * cjwatson checks more closely
<charlie-tca> bug 719389
<ubot4> Launchpad bug 719389 in ubiquity (Ubuntu) "Xubuntu alternate 10.04.2 cd's fail to install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/719389
<charlie-tca> My i386 desktop image installs without this fail
<cjwatson> I'm jigdoing it to check
<cjwatson> it might just have been unlucky wrt update timing and need to be refreshed
<skaet> charlie-tca, xubuntu amd64 posted to iso tracker
<charlie-tca> Thank you
<cjwatson> skaet: I'm test-installing Xubuntu now, but it's also dinnertime
<cjwatson> (test-installing so that I can run apt-get and debug)
<skaet> cjwatson,  ok,  I'll mark the images for Xubuntu alternate as needing rebuild
<skaet> charlie-tca, ^^
<charlie-tca> okay
<skaet> Riddell, cjwatson, Kubuntu DVD's posted
<Riddell> yay
<cjwatson> rebuilding Xubuntu
<cjwatson> (alternate)
<cjwatson> see bug 719389 for reasoning
<ubot4> Launchpad bug 719389 in debian-installer (Ubuntu Lucid) (and 2 other projects) "Xubuntu alternate 10.04.2 cd's fail to install (affects: 1) (heat: 6)" [Critical,Invalid] https://launchpad.net/bugs/719389
<charlie-tca> thank you
<cjwatson> skaet: erk, that got worse
<skaet> cjwatson, drat.   :(
<cjwatson> oh, wait
<cjwatson> false alarm, I was looking at natty
<skaet> lol
 * skaet glad we have a few weeks yet before those images go out ;)
<cjwatson> xubuntu alternate posted
<charlie-tca> syncing
<skaet> :)
<cjwatson> problems on the Ubuntu and Kubuntu DVDs:;
<cjwatson> www/full/lucid/dvd/current/report.html:<p align=right>(there were 1 all up)</p>
<cjwatson> www/full/kubuntu/lucid/dvd/current/report.html:<p align=right>(there were 8 all up)</p>
<cjwatson> Ubuntu is linux-backports-modules-wireless-lucid-server
<cjwatson> Kubuntu is language-pack-gv, language-pack-kde-gv, language-pack-kde-gv-base, linux-backports-modules-wireless-lucid-generic-pae, linux-backports-modules-wireless-lucid-server
<cjwatson> (the numbers are numbers of .debs, not numbers of unique package names)
<cjwatson> I don't think any of those are blockers?
 * skaet pondering
<skaet> what does "all up" actually mean?
<highvoltage> does Xubuntu have LTS releases now?
<cjwatson> skaet_: "all told" or "all together" - I was just grepping the summary line, it's a sum of all the errors above
<cjwatson> report.html lists all the uninstallable .debs in an image
<cjwatson> (doesn't work with live filesystems)
<cjwatson> highvoltage: they asked for us to build this and there seemed no reason not to
<highvoltage> cjwatson: ok
<skaet_> cjwatson, thanks for the explanation.
<highvoltage> cjwatson: is that at all possible for non-lts releases as well? edubuntu ships with a security bug if not updated and it would be quite nice to have that fixed out of the box
<cjwatson> highvoltage: non-LTS releases are a bit of a different question since that would mean doing a point release for them at all
<cjwatson> it's not out of the question I suppose but it is a noticeable amount of effort
<cjwatson> one-off update builds aren't a problem, but if it's not for lucid, ask me about it after 10.04.2 is done
<highvoltage> cjwatson: ok
#ubuntu-release 2011-02-16
<jibel> Riddell, Hi, coverage of Kubuntu test cases is below 50%, can you grab people from the kubuntu community to help with testing 10.04.2 ?
<highvoltage> cody-somerville: I just discovered Offspring, does it work yet?
<cody-somerville> highvoltage, Yup.
<highvoltage> cody-somerville: nice
<Riddell> jibel: kubuntu community never seem very enthused by CD testing, but I'll be doing some myself and I'll see if I can conjole people
<jibel> Riddell, Thanks, I'll help once I'm done with the remaining ubuntu cases.
<Riddell> cjwatson: there's no kubuntu-netbook images for .2 candidates, I'm not too fussed about having them but will it mess up the publishing at all?
<Riddell> jibel: how did you go the kubuntu netbook test? http://iso.qa.ubuntu.com/qatracker/result/5024/854
<Riddell> s/go/do/
<cjwatson> it won't mess up publishing, no
<jibel> Riddell, I synced it and a lucid-netbook-i386 has been downloaded, but its a 10.04.1 apparently :/
<NCommander> skaet_: ping, you about? I'd like to talk to you about the team being tracked for issues against the ARM port
<skaet_> NCommander, yup
<skaet_> ??
<NCommander> skaet_: its my understanding that for release critical bugs, the release team has been following ~canonical-arm
<skaet_> Hmm,  couple of ambiguities in that statement for me.   I am not following ~canonical-arm, but ogra may be.
<skaet_> what i look at is the milestoned & release targetted bugs, and then review them.  The ones that look like they are ARM related I try to group under the ARM team in the weekly agenda.
<skaet_> I know the linaro team also tags the specific bugs that are of interest to them, and there is some overlap.
<skaet_> Do you have suggestions on how to improve the tracking?
<ScottK> Riddell: I don't think it's worth the trouble to reroll netbook for 10.04.2.  I'd recommend any netbook user use 10.10 now.
<Riddell> ScottK: i agree
<skaet_> ScottK, Riddell,  ack.
<skaet_> NCommander ^^ ?
<NCommander> skaet_: sorry, the internet died on me
<skaet_> NCommander, no worries.   are my comments from 1/2 hour ago visible to you?
<NCommander> skaet_: I was under the impression that the release team was tracking ~canonical-arm. Appears I have misunderstood the issue :-)
<NCommander> skaet_: yup, that's for the clarification, I can strike a work item off my TODO list now :-)
<skaet_> NCommander,  if you've got suggestions on how we can improve the tracking, very interested.  Still a bit more manually based than I'd like, esp. with the overlap with the other groups.
<skaet_> Riddell, charlie-tca - do you have any change logs and overview information you want referenced in the 10.04.2 announcement?
<charlie-tca> I have to think about that, if it is okay?
<ogra> skaet_, you dont look at the workitem trackers anymore ?
<Riddell> skaet_: no I don't think so
<skaet_> ogra,  yup I look at it (a lot)  I was talking about how I track bugs.  hmm...???
<skaet_> charlie-tca,  sure, final version will go out tomorrow,  just wanted to get it on your radar.  :)
<charlie-tca> thank you
<skaet_> Riddell, ok.  Will insert general comments for Kubuntu overview, and point you at it to vet tomorrow.
<ogra> skaet_, ah, i thought NCommander referred to wiS
<skaet_> ogra,  in reading the backscroll it is ambiguous,  we'll let NCommander clarify :)
<skaet_> ogra,  I just backscrolled.    He did mention bugs
<ogra> (he had an action item for the WI tracker to be moved to ubuntu-armel for release team tracking, so i assume its that one)
<skaet_> ahh...
<ogra> i alreayd did that for the team report last friday though
 * skaet_ nods
<ogra> was just to make sure you are on the same  page
<skaet_> :)
<skaet_> thank you.
<NCommander> ogra: skaet_ indeed I was :-)
<ogra> be clearer next time ;)
<NCommander> ogra: didn't realize you did
<ogra> NCommander, you should follow the release meeting then, its intresting ;)
<skaet_> or read the minutes/logs... ;)
 * skaet_ --> lunch
 * skaet_ back
#ubuntu-release 2011-02-17
<bdmurray> I just noticed jaunty-updates is stil active as a milestone
<cjwatson> deactivated, thanks
<skaet_> cjwatson,  can you look into why http://iso.qa.ubuntu.com/qatracker/info/5001 doesn't have an image?
<cjwatson> the path is wrong, insert lucid/ before daily
<cjwatson> AFAIK iso.qa just doesn't know about stable builds
<cjwatson> I've never worked on the iso.qa code though
<skaet_> thanks cjwatson,  jibel,  ScottK ^^
<jibel> skaet_, its a known issue, on the todo list of fixes for this app.
<skaet_> jibel,  thanks.
<cjwatson> elmo: how tight is releases.ubuntu.com?  do we need to move 10.04.1 off before publishing 10.04.2?
<elmo> do you know how much extra space we're talking?
<elmo> looks like 6 Gb?
<cjwatson> on the order of 8GB
<cjwatson> cdimage@antimony:~/cdimage/www/simple$ find -path \*.pool/\*10.04.1\*.iso | xargs du -cs
<cjwatson> ...
<cjwatson> 7857564 total
<cjwatson> actually a bit less because Kubuntu netbook is staying at .1
<elmo> oh man that's so much cleaner than my method
<cjwatson> do I want to know?
<elmo> find . -name \*10.04\* | xargs ls -l | awk ' { x += $5 } END { print x / 1024 / 1024 / 1024 }'
<cjwatson> heh
<elmo> so, hum
<elmo> 40+6.  no, I think we'll be OK
<skaet_> elmo,  cool.  thanks!
<cjwatson> ok, planning to start publishing soon
<cjwatson> notwithstanding my utter lack of brain today
<jibel> Here is the status of 10.04.2 ISO Testing
<jibel> Mandatory Test Cases for:
<jibel>  * Ubuntu Alternate: All Done
<jibel>  * Ubuntu Desktop: All Done
<jibel>  * Ubuntu DVD: All Done
<jibel>  * Ubuntu Server: All Done
<jibel>  * Kubuntu Alternate: All Done
<jibel>  * Kubuntu Desktop: All Done - excepted Netbook (no image available)
<jibel>  * Kubuntu DVD: All Done
<jibel>  * Xubuntu Alternate: All Done
<jibel>  * Xubuntu Desktop: All Done
<jibel>  * Upgrade from 8.04.4, all flavors/arch: All Done
<jibel>  * Upgrade from 9.10, all flavors/arch: All Done
<jibel> Image Coverage:	26	26	100.00%
<jibel> Mandatory TestCases: 131	132	99.24%
<jibel> Run Once TestCases:	28	38	73.68%
<jibel> Overall:	159	170	93.53%
<jibel> the 2 main issues found:
<jibel> * bug 645818
<jibel> * bug 650703
<ubot4> Launchpad bug 645818 in usb-creator (Ubuntu Natty) (and 3 other projects) "Unknown keyword in configuration file: gfxboot (affects: 61) (dups: 4) (heat: 188)" [Critical,Triaged] https://launchpad.net/bugs/645818
<ubot4> Launchpad bug 650703 in ubiquity (Ubuntu Natty) (and 3 other projects) "oem-config-prepare works, but oem-config fails to start after reboot (affects: 11) (dups: 1) (heat: 66)" [Critical,Fix committed] https://launchpad.net/bugs/650703
<jibel> Other serious issues found are not reproducible or invalid
<jibel> any question/comment ?
<marjo> jibel: thx; nice summary
<jibel> skaet_, ^
<jibel> skaet_, not marjo's comment, the summary
<marjo> jibel: which 1 mandatory test case are you counting not done?
<jibel_> marjo, kubuntu netbook
<ScottK> It's not needed to be done, why mention it?
<marjo> jibel: but isn't that the one that's not needed?, therefore, mandatory is 100% ,right?
<jibel_> ScottK, because I'm binary
<jibel_> marjo, right
<marjo> ScottK: I agree, but jibel_ is "binary" :)
<ScottK> Think of it as notrequiredandtheisotrackeriswrongforlucid
<jibel_> ScottK, correct, but my query doesn't do fixthedatareturnedbyawrongisotrackerforlucidthatdisplaysnotrequiredmandatorytestcases, that's why it won't be appear in the final report.
<skaet_> thanks jibel.  :)
<skaet_> cjwatson,  go ahead and pushing the images.
<marjo> skaet_, jibel: thx!
#ubuntu-release 2011-02-18
<cjwatson> skaet_: pushing out now
<cjwatson> skaet_: if it looks wrong, either fix it directly or else let me know and I'll fix it in the morning
<skaet_> cjwatson,  thanks.
<skaet_> all,  10.04.2 is announced and on the mirrors.    enjoy.   :)
<highvoltage> skaet_: \o/
<Riddell> is .2 being announced?
<cjwatson> 03:07 <skaet_> all,  10.04.2 is announced and on the mirrors.    enjoy.   :)
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-announce/2011-February/000141.html
<jdstrand> I have re-enabled copy-report
<skaet_> cjwatson,  would it be possible to add ubuntu-release to lucid and the other active releases,  as a release-manager?    10.04.2 milestone needs to be made inactive, and the permissions currently only allow ubuntu-core-dev to make the changes.
 * skaet_ is also thinking about some EOL releases coming up too....
<cjwatson> I think it's only possible to have a single series release manager, and if I do that then I suspect that core-devs won't be able to nominate bugs?
<cjwatson> you're in ~ubuntu-drivers, so you should be able to make the change
<cjwatson> is that not so?
<cjwatson> I've deactivated 10.04.2, at any rate (and fixed its date)
<skaet_> cjwatson,  thanks for making the changes.   I'm only able to make milestone changes in natty, no prior release.
<bjf> skaet_, you realy around ?
#ubuntu-release 2011-02-19
<Baby> hi!
<highvolt1ge> hi
<Baby> can packages still be synced from debian for the next release?
#ubuntu-release 2011-02-20
<slangasek> Baby: yes, though at this point in the cycle packages only get synced when specifically requested
<Baby> I've uploaded love 0.7 to Debian sid (previous one was 0.5)  and love people wanted to know if it was possible to get it into ubuntu
<slangasek> Baby: please file a bug against https://bugs.launchpad.net/ubuntu/+source/love requesting a sync and subscribe 'ubuntu-archive' to the bug
<slangasek> (I would sync it right now, but it doesn't appear to have been published long enough for the mirrors to know about it)
<Baby> thanks! :)
<Baby> done, thanks slangasek!
#ubuntu-release 2012-02-13
<micahg> pitti: would it be better for me to release Firefox 10.0.1 in the next few hours, sometime later today, or does it not make a lot of difference?
<pitti> micahg: it's all the same to me,  so whatever fits you best
<micahg> pitti: was wondering specifically WRT 10.04.4
<pitti> micahg: the earlier the better, I'd say
<pitti> but a few hours don't matter much
<pitti> I'll rebuild images after it's in
<pitti> with that we still have plenty of time for testing them
<micahg> pitti: well, it'll either be ~09:00 UTC or ~19:00 UTC
<micahg> i.e. I can stay up tonight if it'll help
<pitti> oh -- then 9 UTC please
<pitti> 1900 UTC is essentially "tomorrow" for Daviey, QA, and me
<micahg> ok, thanks, will endeavor to accommodate then barring system issues
<micahg> that's why I asked :)
<pitti> thanks muchly
<micahg> pitti: still working, probably another 30-45 minutes until I'm ready to release Firefox
<pitti> micahg: thanks
<micahg> pitti: done, could you please copy âfirefox/{lucid-oneiric} from ubuntu-mozilla-security to $RELEASE-{security,updates}
<pitti> micahg: i. e. lucid maverick natty oneiric?
<micahg> pitti: yes, please
<pitti> micahg: should be all done now
<micahg> pitti: thanks
 * ogra_ wonders why his manual ubuntu-core build doesnt return, i see it in the processlist and it doesnt seem to have failed, but i cant imagine it can take 1h 
<ogra_> s/1h/more than 1h/
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/precise/ doesnt seem to have a 13.1 log either
 * ogra_ checks nusakan
<ogra_> hmm, nothng there either
<cjwatson> you need to look on the builder
<ogra_> oh, hmm
<cjwatson> however it was probably waiting for the kubuntu-mobile build to finish
<ogra_> well, the livefs build was done in a few mins, i'm actually waiting for the second part
<ogra_> but yeah, might be
<cjwatson> the livefs build is still in progress
<cjwatson>  9117 pts/8    S+     0:00          \_ ssh -t -o StrictHostKeyChecking no -o BatchMode yes buildd@annonaceae.buildd /home/buildd/bin/BuildLiveCD -l -f plain -d precise ubuntu-core
<ogra_> funny, i have feedback from all builders in my terminal
<cjwatson> I can see progress in http://annonaceae.buildd/~buildd/LiveCD/precise/ubuntu-core/latest/livecd-20120213.1-armel.out
<cjwatson> so just wait
<ogra_> yeah, will do
<cjwatson> I bet you don't have feedback from all *builds*
<ogra_> essentially i just want to see if my changes to make-web-indicies worked
<cjwatson> then why did you do a buildlive run?
<ogra_> oh, right, 3 out of 4
<ogra_> because i was lazy and just copy/pasted from crontab without proper thinking
<cjwatson> 'build-livecd-base ubuntu-core daily' would have been sufficient - there's a reason those are separate commands :)
<cjwatson> too late now of course
<ogra_> yeah
<ogra_> well, i'm not in a hurry
<ogra_> (was just wondering why it took so long, and didnt take kubuntu into account)
<Riddell> what will it take to make a kubuntu-active?
<Riddell> we now have a late addition of working packages I want to upload
<Riddell> kubuntu-active is the replacement for kubuntu-mobile
<Riddell> so it'll take adapting the seeds
<Riddell> adapting the livefs build script
<Riddell> adapting the cd build script
<Riddell> other things?
<cjwatson> probably a bunch of bits and bobs, do it well clear of a milestone so we can remember them all :)
<skaet> Riddell,  it there someone lined up to test it?   also,  will it be armhf or armel?
<Riddell> skaet: there is probably someone lined up to test it, I need to work out what arm machines we can test on but I have a pandaboard needing set up here
<Riddell> skaet: it would also have large labels saying "technology preview" or similar all over it
<cjwatson> do we get to stop building kubuntu-mobile at the same time?
 * ogra_ hopes so ... else we would need more live builders at some point
<ogra_> they already are close to build images back to back 24/7
<ogra_> (yes, i know that we will start using the package builders for that at some point, but until thats ready we're stuck with what we have)
<cjwatson> do you know how that project is going, incidentally
<cjwatson> ?
<ogra_> nope, all adams baby ....
<ogra_> and he was at linaro connect last week so we didnt talk much
<ogra_> (and i guess he didnt get much done for it alongside)
<Riddell> cjwatson: yes kubuntu-mobile will be replaced
<cjwatson> then can we just transfer over all the existing testers?
<skaet> cjwatson, RIddell - it was built and not tested all through Oneiric, so not sure how many testers there really are for it.   :/
<Riddell> cjwatson: yes
<Riddell> skaet: depends on how much of a mood rbelem has for rounding up volunteers it but this release at least has me as backup
<Riddell> skaet: he wouldn't have been in a mood for it during oneiric because upstream for -mobile had moved on to -active
<Riddell> it would be good if we can keep up
<Riddell> we'd be the first distro to have a community made tablet UI if we can do it
<skaet> Riddell, what I'm weighing it against is that we don't have adequate resources for the other arm image builds right now during respins.
<Riddell> skaet: maybe best if we just start on i386 only then
<cjwatson> skaet: I think that concern is removed by replacing the existing kubuntu-mobile build
<cjwatson> skaet: if it's a one-for-one swap we shouldn't have build time concerned
<cjwatson> *concerns
<Riddell> like -mobile it'll need only testing live image running, not installs
<skaet> cjwaton,  arm builds are main slow down right now on the respins, so since the kubuntu-mobile ones weren't being tested they weren't built for the last 2 releases.
<skaet> Riddell, restricting it to just i386 might be a solution if there are testers.
<skaet> s/releases/milestones/
<cjwatson> skaet: fine, but that isn't changed by renaming it to something else :-)
<skaet> cjwatson,  :)  true.   The concern over the arm builder bottleneck is still there,  just less if there are fewer images to build. ;)
<Riddell> we'll start off with i386 then and exand to arm if we know we have testers and builders
<skaet> Riddell,  ok.
<skaet> Riddell,  so I'll add i386 Kubuntu active to the manifest,  no support (tech preview only) - that suit?
<Riddell> yep
<Riddell> (a blocker might still turn up, we've only just got the packages working)
 * skaet nods
 * tumbleweed adds an opencv transition tracker (I see it started)
<jaustin> can someone please clarify what the process for getting packages synced from Debian before FeatureFreeze?
<jaustin> Is it as simple as raising a bug (that's what cjwatson said last year[1], but I can't see an equivalent message for 2012)
<jaustin> [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-January/thread.html
<cjwatson> same
<cjwatson> best to use requestsync
<cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
<cjwatson> jaustin: ^-
<jaustin> cjwatson: Thanks. I presume for the actual package maintainer, using the (new?) syncpackage tool is adequate?
<cjwatson> if the package maintainer has upload privileges to that package in Ubuntu, yes
<cjwatson> that isn't necessarily the case for the package maintainer in Debian
<jaustin> cjwatson: great, thanks.
<cjwatson> and yes, syncpackage will need to be fairly current
#ubuntu-release 2012-02-14
<pitti> Daviey: we got a new firefox version into lucid-security yesterday, apparently 20120213.1 already caught them, nice
<pitti> Daviey: so AFAICS we need to drop the maverick and perhaps natty kernel from the DVD, respin that, and we should be good?
<pitti> Daviey: oh, hang on, we need another respin for base-files; I guess now is a good time to push that to -updates?
<jibel> lucid doesn't autopublish to the tracker ?
<pitti> apparently not
<jibel> I'll add the images then.
<pitti> jibel: thanks; NB that they will still be rebuilt
<jibel> pitti, ok
<pitti> I'd like to check with cjwatson first what's necessary to drop the maverick, and perhaps natty kernel from the DVD -- just seeds, or d-i rebuild, etc.
<Daviey> pitti: if you can copy that across, that would be good.
<Daviey> We could make another spin after than, then we should be good, i believe
<pitti> yes, for desktop/alternate
<pitti> (DVD needs downsizing)
<Daviey> right
<pitti> Daviey: base-files is now in -updates; 10.04.4 is official then, I guess :)
<pitti> (still needs publishing)
<pitti> Daviey: do you want to respin them after it's published, or want me to?
<pitti> then they can go on the tracker and get the official testing
<Daviey> pitti: i can do it..
<Daviey> pitti: btw, seems there was a bit more to the process than just changing the cronjob.
<pitti> I overheard on IRC; sorry, I wasn't aware of this
<Daviey> np, bt of the fun :)
<Daviey> part*
<pitti> cjwatson: it seems cdimage also needs a corresponding fix for dropping the maverick and natty backport kernels (from reading bug 881529); does this require a d-i upload as well?
<ubot4`> Launchpad bug 881529 in debian-installer (Ubuntu Lucid) (and 2 other projects) "Natty and Oneiric LTS backport kernels need to get onto the Lucid 10.04.4 point release DVD. (affects: 2) (dups: 1) (heat: 18)" [High,Fix released] https://launchpad.net/bugs/881529
<cjwatson> pitti: we shouldn't need a d-i upload - the images are independent
<pitti> cjwatson: good morning
<cjwatson> it should be cdimage+seeds
<pitti> cjwatson: I asked because in that bug d-i was "rebuilt against the oneiric backport"
<pitti> cjwatson: ok, thanks; I guess it's ok to drop the natty kernel as well, as per Tim's confirmation?
<cjwatson> d-i/lucid ships a bunch of independent images for the lucid, maverick, natty, and oneiric kernels
<cjwatson> so it needs to be kept up to date with all of them ...
<cjwatson> I was a bit sceptical about the natty kernel mostly just because we haven't seen any evidence that either works for anyone :-)
<cjwatson> is there any other low-hanging fruit on amd64?
<pitti> other than cutting down the new kernels and some auxiliary language support I'm a bit wary of dropping stuff that we shipped before
<pitti> seed change committed
<pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.lucid/revision/1716
<pitti> Daviey: ^ FYI
<cjwatson> ack
<cjwatson> I've committed the debian-cd change
<cjwatson> and deplouyed
<cjwatson> -u
<pitti> ah, thanks; was just about to
<pitti> cjwatson: so $BOOT_IMAGES can keep the maverick/natty stuff?
 * cjwatson checks
<cjwatson> um, BOOT_IMAGES is constructed dynamically from BACKPORT_KERNELS
<cjwatson> unless you're looking at some other code from me?
<cjwatson>     for backport in $BACKPORT_KERNELS; do
<cjwatson>         BOOT_IMAGES="$BOOT_IMAGES $backport-cdrom/initrd.gz $backport-cdrom/vmlinuz"
<cjwatson> etc.
<pitti> cjwatson: I was just looking at r1737 and wondered what needs reverting
<pitti> +    BOOT_IMAGES="$BOOT_IMAGES maverick-cdrom/initrd.gz maverick-cdrom/vmlinuz natty-cdrom/initrd.gz natty-cdrom/vmlinuz oneiric-cdrom/initrd.gz oneiric-cdrom/vmlinuz"
<Daviey> pitti: has that made it insize?
<pitti> Daviey: i386 should be ok; for amd64 I'm not quite sure how much more we need to squeeze off
<pitti> we could do a build, and then get the precise delta from its log
<Daviey> pitti: do we only know once we spin, or can we easily predict?
<pitti> Daviey: with some more effort we can calculate it from the current one, if you substract all the maverick/natty package sizes
<pitti> Daviey: but figuring this out might take longer than the 20-or-so minutes to build the DVD, so I thought we'd do the lazy way
<pitti> Daviey: err, of course I wanted to say, "so that we'll know the correct size delta instead of an estimated one" :)
<cjwatson> pitti: it's been refactored since then so you don't need to revert anything there
<pitti> ah, great
<cjwatson> pitti: amd64 should be OK per my calculations last night
<cjwatson> it was something like 110MB or 120MB over, and the maverick and natty kernels were about 80MB apiece
<cjwatson> i386 was inside that, more like 40MB over
<pitti> Daviey: base-files 5.0.0ubuntu20.10.04.5 is published; so I think you can go ahead with respinning all three
<cjwatson> we could've just dropped the maverick kernel on i386, in fact
<Daviey> pitti: ok, thanks. Will do in a moment.
<Daviey> building in screen
<Daviey> did someone else trigger one aswell?
<Daviey> suprised we are up to .2
<cjwatson> the versioning is buggily shared with precise builds
<Daviey> oic
<Riddell> oh I broke soyuz somehow, queue command now blocks
<cjwatson> publish-queue is running, it's probably not your fault
<cjwatson> hm, does seem to be taking its time though!
 * cjwatson kills it
<pitti> NEW is quite large ATM
<cjwatson> can you kill your running queue and we'll try again from scratch?
<pitti> I'm waiting for the armel kernel build for binNEWing/d-i rebuild, after that it should become a lot smaller
<cjwatson> queue info doesn't normally take that much longer to even start responding just because the queue is long
<cjwatson> ok, there we go, it's fine now
<elmo> launchpad was having some DB issues
<elmo> which have just been resolved
<cjwatson> ah, thanks
<Riddell> yes, fixed, nice
<ev> hi there
<ev> so in whoopsie (the crash reporting daemon that's on its way into main as part of http://wiki.ubuntu.com/ErrorTracker ), we have a GNOME Control Center page for turning on and off crash reporting
<ev> at the system level (it talks to a dbus service that does the actual config file writing)
<ev> it's currently called Privacy, and we discovered about a week ago that another group of developers under contract created a Privacy page for handling zeitgeist settings
<ev> so Matthew Paul Thomas worked with Christian Giordano to merge the designs, which largely involved moving the contents of the Privacy page for whoopsie into a GtkNotebook tab in the zeitgeist settings
<ev> Is it okay if I just rename the whoopsie settings page to Diagnostics (which will be the name of the tab in the new design) for this week
<ev> and then merge the code into a GtkNotebook tab before UI freeze
<ev> the functionality wont be changing at all
<ev> it's just a placement thing
<cjwatson> doesn't seem like a feature freeze matter to me
<ogra_> well, isnt FF = UIF ?
<ogra_> ah, no, its separate
<jibel> skaet, Daviey I manually posted 10.04.4 builds to the tracker. Could you double-check there's no oversight ?
<ev> cjwatson: cheers
<skaet> jibel, thanks,  will do.
<skaet> Riddell,  did you want Kubuntu images released for 10.04.4?   For 10.04.3 we released DVDs,  what's up there now is Desktop and Alternate.
<skaet> ScottK ^  any opinions?
<skaet> jibel,  powerpc images weren't in 10.04.3 release,  am dropping them from the tracker.
<skaet> Daviey,  pitti, ^^
<Daviey> skaet: rocking
<Daviey> skaet: did you see scrollback BTW?
 * skaet goes to do the scrollback.... 
<Daviey> nothing too exciting, base-files now in the current iso build
<Daviey> So anything from now on is a release candidate.
 * skaet nods
<skaet> wDaviey,  can you see if you can find the Kubuntu DVD images and post them if they went out with 10.04.3 we should have them as an option up for 10.04.4 too.hey're already built (or rebuild them).   Since thy
<skaet> Daviey, ^ ignore (bad editing on the line looks like :P )
<skaet> Daviey,  10.04.4 Kubuntu DVD images,  can you post if they exist, else build them and post?
<skaet> jibel,  Daviey - Ubuntu Server armel+omap - was only an 18 month support (part of ARM EOL announce), so removing it too.
<Daviey> cool
<Daviey> skaet: will do, but in a meeting right now
<iulian> Laney: Thanks for the bug report. I was thinking of sending an email to -release about that.
<Laney> no probs hombre
<iulian> :)
<Riddell> skaet: hmm, will need to ponder about Kubuntu images for 10.04.4
<Riddell> just a question of manpower we have against manpower we need for 12.04
#ubuntu-release 2012-02-15
<jaustin> cjwatson: I've submitted a sync-request for autotools-dev (https://bugs.launchpad.net/ubuntu/+source/autotools-dev/+bug/932668), as it would be really great for people to be able to build packages and software for ARMv8 in Precise. I'm not sure what turnaround time on sponsorship usually is, but given the proximity to the FeatureFreeze I thought I'd check that there isn't anything else I should do...
<cjwatson> for syncs, we take into account the date of filing
<cjwatson> but sure, I'll sort this out, thanks
<jaustin> cjwatson: awesome, thanks :)
<cjwatson> jaustin: done
<jaustin> cjwatson: thanks again :)
<pitti> Daviey, skaet: 10.04.4 mumbling now?
<pitti> skaet: https://jenkins.qa.ubuntu.com/view/Lucid%20ISO%20Testing%20Dashboard/
<skaet> pitti,  yup.   Daviey - we're in desktop.
<skaet> http://iso.qa.ubuntu.com/qatracker/milestones/207/builds
<skaet> pitti, Daveiy ^
<pitti> Daviey: so, this is cdimage/www/simple/.manifest
<pitti> and apparently someone forgot to restore .manifest.full last time
 * pitti does now
<pitti> at least I think that's right
<pitti> cjwatson: ^ please confirm?
<pitti> cjwatson: .manifest only has oneiric, .manifest.full has everything; I think at this point .manifest should have everything, right?
<pitti> and we'll prune it for 10.04.4
<Daviey> pitti: thanks
<pitti> Daviey: ^ anyway, that's the file you need to prune
<pitti> Daviey: but don't do it right now, as .manifest is already trimmed; please keep .manifest.full around
 * pitti isn't 100% sure how this works either
<Daviey> it's black magic :)
<cjwatson> the point of trimming down .manifest is so that the mirror prober can run more quickly and tell us about only the release currently under consideration
<pitti> cjwatson: right; but it shouldn't stay trimmed permanently, should it?
<cjwatson> outside release mirroring periods, .manifest should generally have everything, yes
<pitti> Daviey: ok, .manifest restored; now the instructions will work
<pitti> cjwatson: thanks for confirming
<cjwatson> np
<ara> skaet, FF tomorrow 9pm UTC as usual?
<skaet> ara,   yes.
<ara> skaet, ta
<jamespage> rbasak, was brian going to check whether calxenda needed the entire distro switch to openmpi 1.5 or do they just need GA of that package?
<jamespage> doh! wrong channel
<seb128> hey
<seb128> skaet, slangasek, others: when does the feature freeze start?
<seb128> was there any email sent reminding of that?
<slangasek> cjwatson said 2100 tomorrow, but I don't know where that number came from
<seb128> we are unsure if it's tomorrow 0utc or 21utc, different people know differently
<seb128> that's very confusing ;-)
<skaet> seb128, 2100 UTC
<seb128> slangasek, I though you told me previous cycle that freezes were always at 0utc, my bad
<slangasek> well, previously they were... new RM, new rules, I think :)
<seb128> skaet, thanks, would still be useful to send a remainder email with the hour to ubuntu-devel-announce maybe?
<cjwatson> slangasek: it's what https://wiki.ubuntu.com/PrecisePangolin/FeatureLanding sayd
<cjwatson> *says
<slangasek> oh :-)
<micahg> it's also what the release schedule says although hidden at the top
<skaet> seb128,  I'll send one out at 2100 UTC today  ;)  saying less than 24 hours.    We kept on not holding to the 0000 UTC, and 2100 seemed to work fairly well, so are standardizing on that.
<seb128> skaet, great, I got bitten in the past the other way around, thinking it was thursday end of day and slangasek who told me it was 0utc ;-)
<seb128> but good to know we still have a day
<skaet> if folks have something that is landing late,  that might impact other teams,  would be good if they could put it on https://wiki.ubuntu.com/PrecisePangolin/FeatureLanding
<skaet> I may be asking some teams to explicitly hold off for a day or two, and stagger some of the high interacting ones in,  so we can try to keep the images work.
<skaet> new process this time around,  trying it out.
<skaet> I'll mention this in the email to ubuntu-devel-announce,  as well.
<stgraber> skaet: added LTSP 5.3 to that list, it'll most likely release upstream a few hours before FF and be uploaded a few minutes before FF
<stgraber> skaet: it's still undergoing work upstream and is being tested by quite a lot of people using PPA builds on Edubuntu, Ubuntu and Debian systems. (5.3 is a major LTSP release, we've been on 5.2 since 10.04)
<skaet> stgraber, Thanks!   I may request you hold off on the FF upload for a day or two of that so it doesn't get caught up with the churn from other packages.  Would you be ok with that?
<lamont> skaet: timing question for you....  if I want to take about a 2-3 hour maint window about noon tomorrow that will reduce your arm builder count significantly while I bring up the replacement pandas.
<lamont> noon london, that is
<stgraber> skaet: yeah, that'd work, though I'm not sure what we'd be avoiding doing it. LTSP is a fairly self contained feature, so our worst case scenario is either "LTSP won't install" or "LTSP won't boot", I don't see any way where LTSP could break anything in a default install or in the archive.
<stgraber> skaet: the only dependency changes we'll be doing (that could be problematic as LTSP is in main) is switching from some older font packages to the new ones (following changes in Ubuntu desktop) and switching from rdesktop to freerdp-x11 (same as done on the desktop so we can get rid of rdesktop eventually)
<skaet> stgraber,  ok,  then please hold to FF.  :)
<stgraber> skaet: ok :)
<skaet> lamont,  should not affect 10.04.4 since its not an arm release;  however we've got feature freeze tomorrow - so the builders are being pounded on.
<stgraber> (I know, one shouldn't complain about getting a few extra days for feature work, but I'm planning on being done with all the feature stuff for 12.04 on Friday ;))
<lamont> skaet: atm, arm* seem to be all precise rebuild test
<skaet> lamont,  yeah, FF is tomorrow
<lamont> specifically armhf/precise.  armel is where you'll lose the builders - kitalpha and satinash will remain, and are fast.  we can shuffle some from armhf to armel if there's a need for more width
<skaet> lamont,  can you delay for 24 hours,  I suspect loosing the builders before the FF will get some folks grumpy.
<lamont> they'll come back roughly 3x faster
<lamont> hence the tradeoff
<skaet> ogra_, infinity, ^^ I'm ok if you are?
<lamont> infinity: you want your pandas while you sleep tomorrow morning?
<lamont> skaet: I'll touch base with infinity today sometime - he's the one that's been pushing to get these done NAO NAO NAO this past week, so I expect he's +1
<lamont> and tghanks
<lamont> s/g//
<skaet> lamont,  thanks for letting me know about it too.  :)
 * ogra_ reads backlog ...
<ogra_> lamont, go for it, i dont think we have anything specifically urgent to build atm
<ogra_> skaet, ^^
<lamont> ta
<NCommand1r> skaet: lamont: loosing armel builders isn't a great loss since we're not doing anything sensitive with that archive ATM
<ogra_> NCommand1r, ots about arm* not just armel
<NCommand1r> eek
<NCommand1r> when didI become 1r
<NCommand1r> the only thing major coming down the pipe thats time sensitive is a d-i upload, and I can dorescore magic tokeep things running
<lamont> ogra_: well... if nothing is queued on armel, it's not much about armhf at all
<ogra_> k
<lamont> armhf/non-virt has no bbg3s atm
<broder> cjwatson: i wasn't aware that syncs filed before FF were still good to go through without FFe, and i suspect plenty of other people aren't too. is there a list somewhere of what does/doesn't have to be done before FF to be ok?
<broder> it might be nice to send that out before someone goes and marks everything in the sponsorship queue as needing FFes
<cjwatson> not sure; generally we just try to apply common sense, though I know that's a fuzzy concept
<cjwatson> I think what I may have meant is that if it hits the archive queue by FF then that's good enough; but of course we don't have much of an archive queue for syncs any more
<broder> oh also, is there another SRU for lucid's apt coming, or has all of that already happened? https://code.launchpad.net/~l3on/ubuntu/lucid/apt/fix-917845/+merge/90890 seems like a good candidate for incorporation
<cjwatson> I don't have any right now
<broder> are there point release implications for sponsoring that at this point?
<cjwatson> it wouldn't be accepted until after .4 is out
<cjwatson> no problem uploading it though
<cjwatson> as long as the upload's based on that in lucid-updates, obviously
<broder> right. i think it will likely need some adjustment
<infinity> lamont: Losing armel builders for a few hours is a no-brainer, do it.
<infinity> lamont: Any time lost will be made up for in, like, half an hour. :P
<infinity> lamont: (Has anyone designed and built a babbage catapult yet?)
<skaet> Daviey,  turns out the DVD image I posted was last year's,  got the dates confused.  :P    Have started the Kubuntu DVD builds off now.
<slangasek> not a babbage ballista?
<skaet> pitti, cjwatson, Daviey - had to restore the cdimage's crontab from the file version (with thanks for slangasek's help);  have disabled the LUCID daily builds in the new one.
<skaet>  buildlive kubuntu-dvd dvd lucid && DIST=lucid for-project kubuntu cron.dvd
<skaet> Daviey ^ this is what I've kicked off the DVD build with,   if you spot an issue.  Please flag it.
<Daviey> skaet: okaym looks good - thanks
<Daviey> skaet: Have kubuntu been notified?
<skaet> Daviey,  they were the ones who notice it was last year's posted,  not this years.  #ubuntu-testing
<Daviey> ahh
 * skaet goes off to compose the FF warning anounce,  and wonders what other finger fumbles she'll come up with... :P
<Daviey> skaet: why not defer it till next week?  We'll all thank you. :)
<skaet> Daviey,  hmmm ... late night planned eh?
<Daviey> skaet: What is a late night?
<skaet> Daviey,  anything 12 hours later than your normal time to go to sleep.  :)
<Daviey> skaet: sleep?  What is this? :)
 * skaet figures that explains some things.... 
<skaet> Lucid 10.04.4 Kubuntu DVD's posted to the iso tracker.
<skaet> Daviey, pitti - given the issues with getting the Kubuntu DVD posted,  can you please double check the publishing scripts have it right for them, if they get tested in time?
<Daviey> skaet: have an md5sum handy for what you are expecting?
<skaet> Daviey,  4e648b2fdbfbb41e6e8eb8576936e0b9 *lucid-dvd-amd64.iso
<skaet> 12111bc7ba90e50532dbca95dc5b33d1 *lucid-dvd-i386.iso
<Daviey> skaet: http://cdimage.ubuntu.com/kubuntu/dvd/current/report.html , concerning ?
<Daviey> (from Monday?)
<skaet> lucid
<Daviey> duh
<skaet> http://cdimage.ubuntu.com/kubuntu/lucid/dvd/current/
<Daviey> right, http://cdimage.ubuntu.com/kubuntu/lucid/dvd/current/report.html
<skaet> yup.
<skaet> hmm.... Daviey - lucid-desktop-amd64.OVERSIZED
<skaet> you and pitti discuss ^?
<Daviey> skaet: the PS3 version?
<Daviey> err, mac
<skaet> no,  amd64 desktop CD
<skaet> http://cdimage.ubuntu.com/kubuntu/lucid/daily-live/current/
<charlie-tca> skaet: it's 701MB, and will still fit a cd-r
<Daviey> skaet: ah, we should probably ask them to look for something to trim
<Daviey> charlie-tca: good point
<skaet> charlie-tca, :)  thanks we'll leave it alone then. *whew*
<charlie-tca> You are welcome
<charlie-tca> i burned it to one without realizing it was oversize
<Daviey> super!
<skaet> slangasek, ^  FYI.  :)
 * skaet wonders if some heuristics for CD images size need to be updated,  remembering some discussions at UDS on the subject and not sure where things ended up.
<slangasek> yeah, I've failed to follow through on that
<slangasek> the thing is, we know that the limits are unnecessarily small for *most* cases
<slangasek> and we haven't been able to pin down the details on where it's been a problem in the past
 * skaet nods
<skaet> slangasek, any thoughts as to why we could be seeing:  http://cdimage.ubuntu.com/lucid/dvd/20120214/report.html
<skaet> linux-meta 2.6.32.28.32 produces uninstallable binaries:
<skaet>      linux-backports-modules-wireless-lucid-generic-pae (amd64)
<skaet>    linux-backports-modules-wireless-lucid-server (i386)
<slangasek> looking
<slangasek> skaet: because -generic-pae makes no sense on amd64
<slangasek> and it depends on an i386-only package (linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-generic-pae)
<slangasek> so this is a bug in linux-meta
<slangasek> still looking at the second one
<slangasek> the second one is the reverse - linux-backports-modules-wireless-lucid-server depends on linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-server, which only exists on amd64
<slangasek> ah - but that one is NBS
#ubuntu-release 2012-02-16
<slangasek> skaet: the upshot is that neither of these packages should be on the DVD at all; but the best way to get them off of there is probably to remove them from the archive altogether
<skaet> slangasek,  thanks for figuring it out.
<slangasek> skaet: ok, those binaries are all cleaned up now
<skaet> slangasek,  thank you.  :)
<Daviey> pitti: BTW, i'll be in late.. burning the candle here.
<pitti> Good morning
<pitti> Daviey: urgh, that looks like a complete nightshift
<skaet> pitti, Daviey - can you get with jibel when he comes on line and decide if its worth respinning Ubuntu/Kubuntu DVD?   I've release noted the issue for now (see linux-backports-module issue in the backscroll) and can live with it, but wanted your thoughts if it was worth a respin.
<pitti> due to the oversize?
<pitti> oh, ubuntu, too?
<pitti> hm, it's not oversized
<skaet> pitti,  DVD - http://cdimage.ubuntu.com/lucid/dvd/20120214/report.html
<pitti> we don't have a meta fix, though
<pitti> so a respin alone wouldn't cure it
<skaet> slangasek thought cleaning up the archive should sort it out, but if we need that meta fix,  yeah, leave it as a release note.
<pitti> skaet: yeah, it's a wart, but not really visible to users IMHO
<skaet> release note it is then.
<slangasek> pitti: they were NBS packages on the archs; I've dropped them from the archive now, so a respin would drop them from the DVD as well
<pitti> slangasek: hm, how so? linux-backports-modules-wireless-lucid-generic-pae and linux-backports-modules-wireless-lucid-server are still built by current linux-meta
<slangasek> not on those archs
<pitti> oh, I see
<skaet> pitti, https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.4 - any review/polishing you can fit in, would be welcome (the linux part was duplicate crazines. :P - I'm still spotting some duplicates, but too tired now, zzz time.)
<pitti> skaet: thanks! will do over the day
<pitti> skaet: sleep well!
<skaet> thanks!
<pitti> jibel: hey
<pitti> jibel: the (k)ubuntu DVDs have two uninstallable packages from linux-meta on them; they don't really hurt, just show up in report.html; do you think it's worth rebuilding/retesting for this?
<pitti> jibel: 10.04.4 I mean
<jibel> pitti, what time is the release ?  if it's early afternoon, that's too short. if it's end of the afternoon that's fine we can retest Ubuntu.
<jibel> pitti, what is the impact if these packages are kept on DVDs ?
<pitti> jibel: our evening most probably; but I'd hate to waste any human effort on retesting on that really
<pitti> jibel: not much really; they are uninstallable if someone tries to install them from the DVD pool
<pitti> but they don't show up in software-center, or are advertised anywhere
<jibel> pitti, ok, it is very low impact and is release noted. If really we want to respin we can test DVDs before EOD today but I'd rather spend time on something else than retesting these images.
<pitti> jibel: yes, what I thought; thanks for confirming
<Daviey> pitti: heya
<pitti> hey Daviey
<pitti> Daviey: got some hours of sleep? I woke up about 30 minutes after you left..
<Daviey> pitti: heh. happy times :)
<pitti> I just went over https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.4 to beautify it a bit
<Daviey> pitti: Sorry, for not being here first thing.  What is the current status?
<pitti> Daviey: we noticed that the DVDs have an uninstallable package each, but IMHO that's harmless enough to not warrant a respin
<pitti> Daviey: testing looks good, including Kubuntu
<pitti> so please pre-publish if you haven't already
<pitti> Daviey: no other good or bad news AFAICS, looks on track
<Daviey> pitti: the kernel module thing?
<Daviey> on DVD
<pitti> Daviey: yes; they got removed from the archive, but are still on the DVD
<pitti> but as it's mostly a cosmetical thing (reports.html), it doesn't really warrant a respin
<pitti> as that would void the testing
<Daviey> pitti: right.. i spotted that last night :)
<Daviey> pitti: so, i would have expected pre-publish (now done) to create http://cdimage.ubuntu.com/releases/10.04.4/ .. but it hasn't?
<pitti> Daviey: no, it's not supposed to
<pitti> Daviey: it just adds the new images to a hidden directory, so that mirrors can grab them
<pitti> Daviey: adding .html, those dirs, etc. is the actual publishing
<Daviey> pitti: where does it create it?
<Daviey> ah, found it
<Daviey> pitti: --prepublish didn't advice of dvd commands.. is that expected?
<pitti> Daviey: yes; prepublish is only for stuff that lands on releases.ubuntu.com
<Daviey> ahhh
<Daviey> cool
<pitti> Daviey: DVDs, source, derivatives etc. go to cdimage.ubuntu.com which doesn't need prepublishing
<pitti> mirroring there is just to our own DC, which is fast
<Daviey> right, makes sense.
<pitti> lunch, bbl
<brendand> context menus are often not drawing immediately, is this an issue with compiz 5.4 (under testing)?
 * lamont gets started on that armel downtime window
<infinity> lamont: \o/
<infinity> lamont: And, to be clear, we're just knocking out the babbages for now, right?  The beagles are staying in place for a bit?
<infinity> lamont: (We want the beagles gone at some point too, but just checking what's going on today)
<lamont> correct
<lamont> we are decommissioning 10 of 13 bbg3 boards
<lamont> er, 10 of 15
<pitti> will they get replacements?
<pitti> asking because even with the babbages the current queue is 8 days
<pitti> oh, sorry, that's already with them taken down
<pitti> it was a couple of hours this morning, but constantly non-zero over the last week
<infinity> pitti: They're being replaced with Pandas as we speak.
<pitti> \o/
<infinity> (And I'll immediately steal a few to finish the armhf rebuild test faster)
<infinity> But, like, 4 Pandas should clear up the armel queue in no time. :P
<pitti> oh darn, the mrpt build was cancelled
<pitti> it already built for 1.5 days and was almost ready :/
<pitti> but *shrug*
<infinity> Shrug indeed.
<pitti> the pandas should be faster indeed
<infinity> lamont: Is caph manual for a reason, or was that an oops?
<lamont> that's either not my doing, or an oops
<pitti> . o O { what would it take for you guys to accidentally spill a cup of coffee or two into the powerpc buildds? }
<Daviey> red bull might make them work faster.
<cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=48569 made some progress recently ...
<Laney> nobody loves ppc :(
 * Laney strokes the old ibook
<infinity> lamont: Alright.  I'm going to give caph to armel for now, though.
<infinity> s/though/then/
<lamont> sure
<lamont> infinity: I'm going to assume that you're balancing, and ignore irc for a bit
<pitti> cjwatson: I'm actually more eager to get rid of it :) (livefs builds are not much of a concern as long as the bloody thing takes 3 days to get to a package build)
<infinity> lamont: Ignore away. ;)
<pitti> anyway, it was just trolling, sorry
<infinity> pitti: When livefs builds move to sulfur, we get royal as an lp-buildd.
<infinity> pitti: (And then when livefs builds move to launchpad, we get sulfur too)
<pitti> infinity: still doesn't change the fact that nobody cares about powerpc specific failures
<infinity> pitti: I do!
<infinity> pitti: And BenC did a mess of uploads.
<infinity> pitti: Just because no one's paid to care doesn't mean no one cares.
<pitti> ah, so I'll let you worry about build failures like vlc :)
<pitti> more seriously, I actually don't want anyone in platform to waste time on it
<pitti> we frankly have more urgent things to spend our time on
<pitti> if someone actually uses it as a platform and wants to, sure
<pitti> but for my part I refuse to spend any more time on it as part of stable+1
<pitti> I'm wasting enough attention on it already
<infinity> To be fair, with the exception of really bizarre toolchain issues, if people cared about the packages they upload, it wouldn't ever be much of a mess. :/
<infinity> (And while I realise it's hard to care about powerpc, I could say the same about arm, which we supposedly support)
<cjwatson> arm is way worse off than powerpc in termsof build failures.
<cjwatson> *terms of
<infinity> Yeahp.
<cjwatson> like, two or three times as bad.
<pitti> yes, but we support it and are interested in the platform, unlike powerpc
<infinity> That's sort of my point.
<infinity> We "support" it, and we still can't get people outside the ARM team to care much about failures in packages they upload. :P
<pitti> and people do test arm images, whereas nobody tests the powerpc ones
<infinity> Images, I care less about on PPC.
<infinity> But I will commit a fix to debian-cd soon so that PPC images actually boot on one of my machines.
<infinity> (Currently, it was installed with a Debian CD, and then cross-debootstrapped to Ubuntu)
<cjwatson> I love the way those nobodies who test the powerpc ones also file bugs
<cjwatson> They just don't *sign up as testers*
<cjwatson> (Which I wish they would and I do occasionally ask ...)
<infinity> I'll be sure to actually submit results to the ISO tracker once the ISOs work for me. :)
<pitti> well, *shrug*, I still consider it a waste of time, but that's just my personal opinion
<cjwatson> (er, for anyone reading the IRC logs out of context, that was gentle sarcasm, not implying that the people who test powerpc images are "nobodies")
<infinity> Up until now, I've had one machine that boots with BootX (clearly can't do installer testing), and one that could work, but needs a tweak.
<infinity> pitti: Let others waste their time on it, then. ;)
<infinity> pitti: I have more PPC machines in my house than x86.
<jibel> cjwatson, a tester just reported bug 933434 in kubuntu 10.04.4
<jibel> I don't think it's new but a consequence of bug 933433 with grub and XFS
<jibel> could you look into it ?
<cjwatson> well, certainly isn't grub
<cjwatson> far too early
<cjwatson> is it .4-critical?
<cjwatson> oh - my apologies, I should have read the entire syslog first!
<cjwatson> 933433 is grub, 933434 is not
<cjwatson> the latest comment on 933433 explains the situation accurately
<pitti> skaet: http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html
<Riddell> cjwatson: for bug 933433 you set to triaged, does that mean you know the cause?
<Riddell> what boot option do I add to get oem mode? (bug 645818 means I can't use normal boot loader)
<cjwatson> Riddell: the reporter already explained the cause in his most recent comment
<cjwatson> you can't install grub to a logical partition containing xfs; the problem is just that the installer doesn't tell you this but crashes instead
<cjwatson> OEM mode is oem-config/enable=true
<Riddell> cjwatson: ok so not a regression then
<cjwatson> indeed not
<cjwatson> Riddell: don't suppose you could have a look at bug 933434?  it's in a bit of the KDE UI I'm really not very familiar with
<cjwatson> no idea what an _ElementInterface is
<Riddell> cjwatson: not off the top of my head, I'll try and test and see if I can recreate and look into it if I can
<ogra_> skaet, hey, can we have the move to armhf mentioned in the FF announcement ?
<skaet> ogra_, give me the words you want and I'll add it in.  :)    Decision's been made then?
<ogra_> yes
<skaet> any email/announce somewhere already I can crib from?
<pitti> infinity, lamont: could we borrow some armhf builders for armel to make it catch up with the long build queue?
<pitti> armhf only has the autotest
<ogra_> skaet, "with the feature freeze of ubuntu precise ubuntu-arm moves to armhf as its default architecture, the armel architecture will go on to exist but not be supported by canonical anymore. image builds will be switched to armhf across the board with the exception of omap3 and ac100 builds still keeping armel builds around for compatibility with their respective binary drivers"
<pitti> well, not "only" of course
<pitti> but "also"
<ogra_> infinity, ^^^ does that look ok to you ?
<ogra_> skaet, we only announced it in the IRC meeting yet, the addition to the FF announcement would be the most official one then :)
<lamont> pitti:I was letting infinity do the balancing act - I'm close to throwing 5 or more pandas into the pool, with a total of 9 arriving today
<pitti> lamont: ah, that sounds sufficient indeed, thanks!
<infinity> pitti: Yeah, I was waiting for the new pandas to be online, but I can rebalance a couple right now.
<pitti> infinity: oh, that's ok; I thought we already had all the new ones, and some were moved to armhf
<skaet> ogra_  coolio.   THanks.
 * pitti is just eager to get some buildable armel images soon again
<infinity> ogra_: Other than the complete lack of capitalisation, and the run-on sentence, sure. :P
<infinity> ogra_: I'm sure skaet can un-German it a bit. ;)
<ogra_> infinity, pfft ... grammar, who needs that
<lamont> just _DO NOT_ unmanual the new ones
<infinity> lamont: Set them to disabled instead of manual.
<skaet> :)
<pitti> lamont: understood
<infinity> There.
<pitti> "ishigaq" /me tries to pronounce that in Klingon
<pitti> "today is a good day to build"?
<infinity> Hahaha.
<skaet> ogra_, infinity -   I'm happy to mention in the FF announce,  but it probably deserves its own announce and searchable subject line ;) with more details (and rallying of folks to help with cleaning up the uninstallable packages, and things not building, wouldn't hurt either...   )   Maybe someone on the arm team should issue that later today/tomorrow?
<ogra_> k
 * ogra_ will care for it 
<skaet> thanks ogra_  :)
<lamont> let's kick this pig, shall we infinity?
<infinity> lamont: Once I'm off the phone
<lamont> infinity: well, anyway, you have 5 new panda builders building with a track record on ishigaq of success or explainable failures.  I declare victory
<infinity> lamont: Or you can kick it. :)
<lamont> your other 2 will be online sometime soonish, with 2 others being virtual
<lamont> #10 is that special board that thinks it has no SD card even though it booted from it
 * infinity nods.
<lamont> and that was a tad more painful than I wanted it to be
<Riddell> does lucid work with alternate installs on netbooks?  I get "no common CD drive was detected"
<lamont> infinity: so... sycamore... is that still being used for livefs builds?
<infinity> lamont: Is it a babbage?
<lamont> it is
<lamont> so I want to kill it, of course.
<lamont> OTOH, that requires a tad bit more coordination
<infinity> lamont: It's used, but I can make that not true in pretty short order.
<lamont> and would your preference be to replace it with a beaglexm, or a panda?  either way you lose one
<infinity> A beagle.
<infinity> But let me look at things.
<infinity> We're dropping two armel images today, so I can probably just lose the builder and shuffle and no one will notice. :P
<lamont> ah, that'd be lovely
<lamont> if we still need one, I choose adoxaceae
<lamont> it pairs most nicely with annonaceae
<infinity> Heh.
<infinity> How many beagles do we have?
<infinity> I don't really want to create extra work for you, but the beagles are less than stellar for package bulding anyway.
<infinity> With 6 image targets, we could have 6 beagles. :P
<infinity> And make celbalrai an lp-buildd.
<skaet> Daviey, ping?
<Daviey> skaet: hola
<lamont> infinity: *aceae are beagles in the buildd world
<infinity> lamont: Aye, I knew that much.
<lamont> and I think that may be all of them, when you count annonaceae
<infinity> Mmkay.
<Daviey> ev: not still around are you? :)
<ev> Daviey: that depends on what you want me to do
<Daviey> ev: is there a refreshed wubi for 10.04.4?
<ev> Daviey: yes, it's ready and waiting at http://people.canonical.com/~evand/wubi/lucid/stable
<Daviey> ev: super, thanks
<ev> when 10.04.4 CDs are spun, that will be automatically included
<ev> sure thing
* ChanServ changed the topic of #ubuntu-release to: 10.04.4 Released!  Precise Feature Freeze in effect.  Archive:open  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<skaet> Thank you Daviey!  10.04.4 images are all available for download.  :)
<skaet> Thank you jibel and Riddell for coordinating the testing and checking that the images were good to send out.  :)
<cyphermox> skaet: sorry, NM got uploaded later than freeze time, I got confused by conversion and was still testing it up (and enabling the tests)
<cyphermox> and somehow it fails to build, oh god
<skaet> cyphermox,  as long as it doesn't cause the daily build to break...
<cyphermox> not really worried, it's an update with some bug fixes
<skaet> cyphermox,  ok.   as long as its fixed before the cron jobs trigger all should be good.
<stgraber> cyphermox: at least the ftbfs seems easy to fix (missing build-dep)
<cyphermox> yeah
<cyphermox> I should really have caught this early though
<cyphermox> on the bright side if I didn't screw up elsewhere, shutdown will now no longer take a minute to complete
<skaet> slangasek, pitti, cjwatson, Daviey, stgraber,  updated default_milestone on nusakan to "default_milestone=Precise Daily"
 * ScottK approved the first FFe of the cycle ....
<Laney> congrats
 * Laney finds one to deny :-)
 * ScottK cheers Laney on.
<ScottK> Mine was an easy one to approve because the only reason it didn't get sync'ed pre-FF was it wasn't out of Debian New in time.
<ScottK> Since we want to encourage going through Debian, easy decision.
<Laney> yeah, hyperair was DTRT there
<hyperair> DTRT?
#ubuntu-release 2012-02-17
<infinity> Doing the right thing.
 * micahg needs to file some FFes
<superm1> ScottK: i've got one like that too, but i uploaded day before freeze to avoid needing an FFe.  sounsd like it's finally going through new tomorrow.  shouldn't need an FFe to just sync instead now right?
<Daviey> superm1: depends if it's Featureful sync :)
<ScottK> superm1: You do need an FFe, but if it was uploaded to Debian before FF, I can virtually gaurantee I'll approve it.
<superm1> well it's identical to the one i uploaded the day before FF except s/unstable/precise and #update-maintainer
<ScottK> superm1: In that case, no FFe needed.
<superm1> otay, cool
<skaet> ScottK,  Laney,  could you please make sure there's a time limit window on any FFEs you end up approving.   Not so worried about those coming in over next day or so, but as we get close to Beta Freeze want to make sure things are scheduled so we can keep the images working.   Please add those packages that are seeded to https://wiki.ubuntu.com/PrecisePangolin/FeatureLanding
 * skaet needs to send a note out to release team,  but just spotted the first FFe approval and rejection and felt it better to comment here too... ;)
<ScottK> skaet: I think tracking FFes on a wiki page is overkill.  Generally when something has an FFe requested it should be ready to go, so the window between approval and upload should be small.  Developers are supposed to know the freeze schedule (or read UDA).
<ScottK> In cases where it looks like there will likely be some delay, I agree they should be time constrained.
<ScottK> I think it's interesting that Unity has pre-planned not making feature freeze again.
<skaet> ScottK,  that's what I'm looking for.    There were some surprises last cycle by things dragging on too long.
<ScottK> Sure, I just don't want another wiki page to remember to edit.  It doesn't scale very well.
<skaet> ScottK,  they were up front about it,  and I'd rather they have it tested properly than throw something in and break everyone.  Couple of others were approved for later too to maximize chance at stability/debugability.
<ScottK> Last time it ran right up to final freeze.
<skaet> WIKI page seemed the easiest mechanism of being transparent about what hadn't landed and still was planned (as best known at the time).
 * skaet just doesn't want a dog pile of FFes the day before beta freeze. 
<ScottK> Those are easy.  Just don't approve them.
<ScottK> I think the wiki is a good idea for major things that are planned.  I think it's too much for every FFe.
<Riddell> skaet: where is the list of who's tech driver for precise releases?  I expect mine is coming up
<Riddell> skaet: on https://wiki.ubuntu.com/ReleaseTeam can I change "Variants of Ubuntu" to flavours?  "variants" is yet another word to describe them and it would be nice to standardise
<Riddell> ah hah, March 1st https://wiki.ubuntu.com/PrecisePangolin/ReleaseTaskSignup  I'd best get in training then :)
<skaet> Riddell, yup, you're on for Beta 1.  :)  https://wiki.ubuntu.com/PrecisePangolin/ReleaseTaskSignup is where the list is.
<skaet> Riddell,  yes, please change the wording - its an oversite that should be fixed.  Very much behind getting the language consistent.  Oversite I missed that one.
<skaet> (and Thank you! )
<ralsina> skaet: hello, joshuahoover told me to come here to discuss inclusion of ubuntu one on the CD?
<skaet> hi ralsina,  we've got a meeting going on in #ubuntu-meeting right now,  why don't you join us there,  and ask question when ubuntu one is mentioned.    I'll ping your nick there.
<ralsina> skaet: ok, joining!
<joshuahoover> oops, sorry about that ralsina
<joshuahoover> too many channels ;)
<ralsina> joshuahoover: :-)
<NCommander>  anyone from ~ubuntu-release around besidemyself? I need a FFE to land armadaxp code
<NCommander> https://bugs.launchpad.net/ubuntu/+source/libdebian-installer/+bug/934451
<slangasek> huh, that's armada xp, isn't it, not arm ada xp - silly brainparser
<slangasek> NCommander: approved
<NCommander> slangasek: awesome
<superm1> ScottK (or someone else with release queue rights): that package I was referring to yesterday, ledmon just made it through debian new so i've sync'ed it.  can someone axe the original upload that was directly to ubuntu from the precise new queue in favor of that new one.  The package name is 'ledmon'
<slangasek> lookin'
<slangasek> done
<superm1> thanks
#ubuntu-release 2012-02-18
<infinity> Anyone have any objections with my syncing quickplot?  Leaf package in universe, no rdeps, builds, runs, and eliminates the Ubuntu delta.
<ScottK> infinity: Go for it.
#ubuntu-release 2012-02-19
<tumbleweed> ScottK: given LP's auto-confirming everywhere, it probably makes more sense to use Triaged instaed of Confirmed (that's what I've been doing)
<wgrant> tumbleweed: FWIW it's not everywhere -- only places that have explicitly asked for it, which is Ubuntu.
<Ampelbein> Can a member of the release team look at bug 905610 please if they have the time?
<tumbleweed> wgrant: right, but it affects most ubuntu process bug workflowss, which were using Confirmed in the past
<tumbleweed> Ampelbein: I was just looking at that
<tumbleweed> it seems reasonable, but will obviously have had less testing than if it was coming from Debian
<Ampelbein> Yes, that's true. I can give it a week's test in my daily work but that would put the inclusion date further behind.
<tumbleweed> yeah, probably makes more sense to ask the applicant to subscribe to mc's bugs
<Ampelbein> tumbleweed: Can you add a comment as member of the release team?
<tumbleweed> Ampelbein: I will. Reviewing diffs...
<tumbleweed> Ampelbein: there
<Ampelbein> tumbleweed: thanks!
<tumbleweed> re bug 936200. I don't know what the usual policy for these kinds of things is.
<cjwatson> Daviey: could you deal with bug 935763, please?
<cjwatson> (wubi/10.04.4)
<ScottK> tumbleweed: OK.
<ScottK> wgrant: It doesn't help us much with process bugs.
<tumbleweed> excuse the noise, I was sweeping out cobwebs from amongst our FFe bugs. Done now.
<Daviey> cjwatson: looking
<Daviey> cjwatson: "checksum-directory ." doesn't refresh enteries for filenames that already exist.
<Daviey> I didn't know this.
<Daviey> Fix Released
<mdeslaur> Could someone please grant me a freeze exception for LP: #936478, please?
<tumbleweed> sure
<mdeslaur> tumbleweed: thanks!
<wgrant> ScottK: Sure, I hate it. But Ubuntu asked for it :)
#ubuntu-release 2013-02-11
<jamespage> how are the packages associated with each team defined for the reports @ http://reqorts.qa.ubuntu.com/reports/rls-mgr/
<jamespage> ?
<jamespage> the server team are currently using this with another report and I'd like to consolidate on the official release management report
<jamespage> but I think the list of packages needs to be expanded.
<xnox> jamespage: if i remember correctly, bdmurray maintains package mapping in those reports.
<infinity> Is it not just based on bug subscriptions?
<infinity> If it isn't it probably should be, and those should be cleaned up.
<infinity> Maintaining parallel lists is silly.
<Daviey> Hmm.. it was maintained via a *spreadsheet*.. That might not still be the case.
<Daviey> Ursula and brad would be good contacts for that, i think.
<infinity> Daviey: I'm not arguing that it might not be in a spreadsheet currently, just that it shouldn't be. :P
<infinity> We demand bug subscriptions when we do MIRs and such, we really should just formalise that as the one canonical place for team blame.
<Laney> I think there was a BP to stop using the spreadsheet and do something else
<Laney> which is the part bdmurray was working on
<Daviey> well, that doesn't have a single poc when there are multiple subscriptions.
<infinity> (And before anyone mentions that more than one team can subscribe to a package and then bugs would show pu twice in the report, tell me how that's bad that two teams would care?)
<Laney> https://blueprints.launchpad.net/launchpad/+spec/other-p-package-mapping
<Daviey> infinity: It's bad, in the situation that both teams think the other will deal with it.  Which has happend :)
<Daviey> So having a single contact for the tracking/triaging, even if not the team solving it.. Is a good way IMO
<infinity> Daviey: One could short the reports to only display for one team once it's been assigned to a member of that team.
<infinity> Daviey: But I think the default assumption when unassigned should be "no one's looked at it yet".
<infinity> Daviey: Besides, it seems a bit weird for people to use the reports to find bugs they shouldn't be working on, rather than the inverse.  Look at your own section, silly. :P
<Daviey> hah
<cjwatson> I've disabled precise daily builds in preparation for 12.04.2
<cjwatson> infinity,plars: ^-
<infinity> cjwatson: Shiny.
<jamespage> xnox: thanks (and to *all for the general conversation - felt more difficult that is should have been)
<xnox> jamespage: if we were in bdmurray timezone it should have been more simple =)
<Riddell> ok I give up, how does xserver lts-quantal bits get on the precise CDs?  I don't see a seed change and I don't see it in the germinate output
<Riddell> but it's there in the ubuntu desktop manifest
<jamespage> xnox: indeed
<infinity> Riddell: livecd-rootfs magic.  Is this about the alternate CD bug?  I'm going to fix that today.
<infinity> Riddell: Or, at least, attempt to.  We'll see how it goes.
<Riddell> infinity: I'm wondering what to do to get it on the kubuntu 12.04.2 candidate images
<ogra_> btw, someone asked about documentation if you want to opt-in to the -lts package stack ... do we have any wikipage or so ?
<infinity> Riddell: Oh, you didn't sign up for it earlier?  Indeed you didn't.
<Riddell> ogra_: talking to me?
<infinity> Riddell: ScottK may have opted out in earlier discussions.  Perhaps you two should quickly agree on that point before we go emergency SRUing livecd-rootfs.
<infinity> ogra_: A wiki page for what?  For flavours, or users?
<ogra_> Riddell, to the room, or anyone involved with the -lts stack
<infinity> ogra_: Users can only opt in or out by either picking old/new install media, or manually changing packages.
<ogra_> infinity, well, my 12.04 wont automatically upgrade to the -lts packages
<infinity> ogra_: flavours were meant to opt in weeks ago, so we could make the right changes. :P
<infinity> ogra_: No, upgrades won't.  And there's no reason they should.
<ogra_> if i want the new stack, is there a meta or so i can install ?
<infinity> ogra_: The whole point was hardware enablement.  If your hardware works, why upgrade the stack?
<ogra_> because my steam games might run faster for example
<ogra_> with newer driver and kernel
<infinity> ogra_: You can install "xserver-xorg-lts-quantal linux-generic-lts-quantal" and you're there.
<cjwatson> Riddell: sorry, you'll have to revert, there isn't time now to get the new stacks in
<ogra_> infinity, rifght, *i* know that .... but there was someone asking of there is any documentation
<Riddell> ok, c'est la vie
<cjwatson> unless your images are broken without the new stacks
<cjwatson> in which case an emergency SRU is probably possible ...
<infinity> Given it's a straight cargo-cult from the other flavours, an emergency SRU is pretty low risk.
 * ogra_ is just playing cassandra here 
<cjwatson> well
<cjwatson> I guess I don't mind terribly, but do try to get all the pieces
<cjwatson> which I don't think Riddell's seed commit did
<cjwatson> ship-live: * linux-headers-generic-pae [i386] # Make sure we get the right headers
<infinity> Riddell: Talk it over with ScottK.  If you both feel pretty strongly about it, we'll talk.
<cjwatson> (that should probably be removed rather than substituted)
<infinity> cjwatson: Where's that commit?
<cjwatson> kubuntu.precise seeds
<infinity> Or, derp.
<infinity> But yes, headers shouldn't be there at all.
<cjwatson> it needs at least also (a) livecd-rootfs SRU (b) extend the thing in debian-cd/CONF.sh that sets BACKPORT_KERNEL=quantal
<infinity> Plus the bits I'm about to change for seeds/debian-cd love.
<cjwatson> (c) lib/cdimage/livefs.py search for quantal
<cjwatson> [generic vs. generic-pae]
<cjwatson> and it will involve switching Kubuntu over to metapackages in livecd-rootfs at the last minute, which means you need to do a test build, compare the resulting package lists, and add hacks for anything that gets added that shouldn't have been added (i.e. what I did for Ubuntu and Edubuntu)
<cjwatson> (the "libqt4-sql-sqlite notify-osd" bit)
<cjwatson> and you arguably ought to avoid adding SB support at the same time since all this is complicated enough
<cjwatson> there are enough moving parts - and I'm not absolutely certain I've remembered everything - that I really recommend against doing this at the last minute; it might be better to do a proper job, including SB, for .3?
<cjwatson> infinity: the metapackage hacks are why this isn't a straight cargo-cult
<infinity> cjwatson: Yeah, I agree it looks hairy as a last-minute thing.  Deferring to .3 is certainly less pressure.  Though, we should probably do it immediately post-.2, so no one forgets until the next last-minute.
<cjwatson> ... for all flavours, consistently
<cjwatson> (which probably means getting consent from everyone nowish - which is why I didn't do it originally, I think I asked some set of people and fixed things up for the ones who responded)
<cjwatson> (and being in a tearing hurry)
<Riddell> ok let's stick with the old stack for kubuntu 12.04.2
<cjwatson> sorry, I know this is basically my screwup
<Riddell> could someone respin the image to get rid of the linux change I made (I just reverted seed)
<infinity> Riddell: Will do.
<Riddell> infinity: new kubuntu 12.04.2 candidates on their way?
<infinity> Riddell: Yeah, I just need to hit enter in this terminal.  Wanted to make sure the world settled.
<infinity> Riddell: Building now.
<Riddell> thanks
 * ScottK didn't opt out of anything.
<infinity> ScottK: No, you may have just failed to opt in.  I could have sworn you were around and speaking up about it when we were discussing it in the channel with other flavours, but maybe not. :/
<ScottK> Not that I recall.
<infinity> ScottK: The backport stack stuff was all rather haphazardly organised, I'm afraid.
<infinity> For .3, we should just make sure both the backport stack and SB is just universally enabled and be done with it.
<infinity> (And soon after .2, so new dailies DTRT)
<ScottK> Makes sense.
<plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1122072 seems to be a regression for 12.04.1
<ubot2> Ubuntu bug 1122072 in xorg (Ubuntu) "[Precise amd64 on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed]
<plars> cjwatson: alternate images seem to be oversized at the moment?
<infinity> plars: Alternate images are being worked on for other reasons, we'll see where we end up.
<plars> infinity: what else is being worked on with them?
<infinity> plars: Making them use the enablement stack...
<bdmurray> jamespage: We are still using the spreadsheet but are planning on moving away from it
<infinity> bdmurray: Planning to move to what, out of curiosity?
<ogra_> a more shiny spreadsheed with colors
<ogra_> :P
<bdmurray> infinity: launchpad team subscriptions to packages
<infinity> bdmurray: Ahh, good, exactly what I suggested above.
<infinity> bdmurray: I appreciate when people have the same idea as me, spares a whole lot of time trying to convince them they're wrong.  *nod*
<bdmurray> infinity: Well, I'm certain you heard me talk about on the train in Copenhagen and that it was my idea first. ;-)
<jamespage> bdmurray: can i review/get that spreadsheet updated please?
<infinity> bdmurray: Crazy talk.  That implies I listen to other people.
<bdmurray> jamespage: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhTVBLlLWapNdHRpM2QyRGQ5NGFzZmF3ODNpZ2E3d1E&authkey=CJzt1xo#gid=0
<infinity> bdmurray: Not public readable?  Classy. :)
<rtg__> infinity, what do you suggest for libaudit-dev in Precise with regard to the Raring LTS kernel ? just don't build perf ?
<infinity> rtg__: Yeah.
<rtg__> my thoughts exactly
<infinity> rtg__: Unless you want to go to the hassle of tearing out whatever bits of perf reference libaudit.
<rtg__> ick
<rtg__> guess I could take a look
<infinity> rtg__: Probably not worth the effort unless it's a dead simple case of removing the header include and a few function calls.
<rtg__> infinity, maybe NO_LIBAUDIT in the Makefile will help. I'll keep digging
<infinity> linux-tools so needs to grow a proper configure.
<infinity> Actually, wait, I thought it had one?
<infinity> It spews bits about disabling things if GTK isn't there, etc.
<infinity> So, maybe the configure just needs to be smarter about audit. :P
<infinity> Or, we could just not care.
<rtg__> I'm leaning that direction.
<infinity> rtg__: perf is a pretty awesomely useful debugging tool, but I suppose it's more interesting in an active development release than an LTS.  Maybe.
<rtg__> infinity, I know cking has used it on older releases for a variety of profiling researches
<infinity> rtg__: There's you answer.  Punt to cking.  If he cares, he'll fix it to build without audit and submit the patch upstream. ;)
<rtg__> infinity, yeah, he'll punt it back to me.
<antarus> infinity: do you have the src for that kernel pruner thing we talked about on Friday?
<infinity> antarus: I'll upload it today and point you at it.
<infinity> antarus: (Or you could check raring, but if you're looking for it backported to precise, no point doing the work twice)
<antarus> infinity: whats the pkg name in raring?
<infinity> antarus: apt.  You've probably heard of it.
<antarus> heh
<antarus> I'll poke at it then ;0
<infinity> Heh.  I'll backport the relevant commits this afternoon.
<antarus> infinity: is there a launchpad bug for the backport?
<infinity> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876
<ubot2> Ubuntu bug 923876 in apt (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [High,New]
 * infinity sets that to In Progress, and gets progressing on it.
<antarus> thx
<balloons> It's been mentioned there's no upgrade test for 12.04.2 -- is this intentional? Did we simply not include it in the rollout?
<stgraber> those need to be manually added as they're not pushed by nusakan
<balloons> stgraber, ohh.. I do remember that now
<balloons> ok,  I was holding off because I thought there was a reason
 * balloons goes to add
<stgraber> balloons: for dailies I have a script bumping the version every week, but I'm not doing that for milestones
<balloons> hmm.. precise stll has the legacy stuff on it
<balloons> that makes it tricky too
<balloons> ohh ugh
<balloons> how did I not notice these were all linking to the old legacy testcases
<balloons> stgraber, well, since we're already chatting in here.. If I change and update the testcase links for everything, we re-write history and lose all of our old results, right?
<stgraber> yep, precise doesn't have the shiny new testcases
<balloons> but if we don't change the, we're stuck using the old stuff
<balloons> which actually has broken testcases at this point?
<stgraber> balloons: I haven't looked at the code in a while but I "think" accessing archived records should be fine even if you change the testsuites/testcases for precise
<stgraber> might be worth testing with just a product to check though
<stgraber> I don't keep an explicit history for those but results are linked to build and testcase
<balloons> stgraber, well, if possible, we should get precise updated to the new stuff
<balloons> I remember we avoided converting for simplicty
<stgraber> so if I did it correctly, accessing an older build should still show you the old testcases and results
<balloons> but since precise is going to keep coming up..
<stgraber> balloons: can you convert let's say, Edubuntu amd64 and then let me know so I can check?
<stgraber> balloons: I happen to know the testcaseid for Edubuntu by heart so if it ends up messing the history I can easily revert
<balloons> stgraber, yes, I'll do that.. I'll remove the legacy links and put in the proper ones
<stgraber> balloons: ok, let me know when you're done
<balloons> stgraber, k, done
<balloons> mm.. we lost today's results ofc
<stgraber> balloons: alright, let me take a look at the history
<stgraber> balloons: history's broken. Let me poke at it for a bit see if we can get that working with some configuration
<stgraber> balloons: ok, that doesn't work :( I thought I had written some code to detect cases where we had results for testcases and testsuites not currently linked to a product, but apparently I either didn't do that or the code is broken
<balloons> hmm.. well, so where does that leave us?.
<stgraber> nowhere particularly good, we don't have enough time for me to fix the code and land it and if we simply go ahead with swapping the testsuites and then land the fix post-release, it means we won't be able to access the results from any of the dailies which may be relevant
<balloons> stgraber, right.. so, I guess we continue as-is then.. I wonder if I can even change the upgrade tests
<balloons> I guess not
<stgraber> probably not and they'd end up being wrong if you did as they need extra testcases for LTS-to-LTS
<balloons> well, as you ca see I simply turned on the existing upgrade builds, with the old testcases
<balloons> thanks stgraber
<balloons> stgraber, ohh.. since this will come up again, can we at least note it in the bug tracker.. whenever you have time to open and proper bug with description.. I'd prefer you to do it since you can describe the technical limitations better
<stgraber> balloons: yep, I'll file a bug and get that fixed soon
<knome> release team (ping micahg_): the xubuntu team wishes to move to a 1GB image; do you need something from us or will you process?
<stgraber> it's actually a ping for the cdimage team :)
<stgraber> but yeah, I can bump the limit for you
<infinity> I was already there.
<stgraber> infinity: if you remember where it's, go ahead ;)
<stgraber> infinity: I vaguely remember cjwatson moving those bits to python so I was preparing to do some grepping around
<infinity> stgraber: Already done.
<infinity> knome: ^
<knome> infinity, cheers!
<knome> and thanks for stgraber too ;)
 * ogra_ doesnt get why the nexus7 build failed
<ogra_> the log doesnt show any errors
<ogra_> yet i got a failure mail
<infinity> ogra_: When?
<ogra_> 1.5h ago
<ogra_> which is weird, the build should have finished several hours ago
<ogra_> (it starts at 13:30 UTC or so)
<infinity> ogra_: I'm fiddling with some things, let me try again.
<ogra_> oh, err
<ogra_> thatt mail was from the 10th
<ogra_> LiveFS ubuntu-nexus7/raring/armhf+nexus7 failed to build on 20130210
<infinity> Oh, that was probably when the world was half exploded.
<ogra_> seems todays worked
<infinity> Anyhow, testing things now.
<infinity> Today's would have been on cadejo, the one I'm doing now will be on celbalrai.
<ogra_> still strange that nusakan held back the mail for 24h
<ogra_> hmm, evolution, the chromebook and livefs build logs go better together than my high end x86 desktop
<ogra_> (on my desktop evo crashes if i scroll to fast)
<antarus> chromebook++
<ogra_> yeah
<ogra_> its soo ugly, but works so well :)
<ogra_> (and properly working flash on ubuntu-arm is actually priceless)
<plars> sorry for the vagueness in this bug, but https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1122525 is blocking from testing ltsp on alternate. Also, shouldn't precise alternate images have apport in them? ubuntu-bug and apport don't seem to work there but it looks like it did at one time.
<ubot2> Ubuntu bug 1122525 in ltsp (Ubuntu) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,New]
<plars> it's virtually identical to an older bug that was fixed by stgraber, so hopefully the breakage should be clear
<plars> infinity: or is this related to the problem you mentioned earlier?
<infinity> plars: The ltsp bug is related to the lts backport stack, but not the thing I was fixing. :/
<infinity> stgraber: ^
<plars> infinity: I'll cc him on the bug
<infinity> stgraber: Looks like ltsp in .2 wants to be installing the lts-quantal kernel instead of -generic, if it's relying on the CD for its packages...
<stgraber> infinity: hmm, yeah, I should have thought of that... we have logic to figure out the right kernel in there which needs updating
<infinity> stgraber: Please with the emergency SRU? :)
<stgraber> infinity: yep. Busy with other things tonight but will try anyway, worst case will have something first thing tomorrow
<infinity> stgraber: Kay.  I'm airplaney tomorrow, but I'm sure you can convince someone else of the urgency and get it in. :)
<stgraber> infinity: yeah, hopefully the change will be very simple and very readable. I'll do any necessary nagging to get it in once it's all tested.
<skaet> stgraber, ScottK,  I just noticed there's a new kernel for raring 3.8.0-6.11 in -proposed.   Was it discussed with Edubuntu or Kubuntu teams during this alpha 2?
<skaet> slangasek,  does it make sense to turn off the autobuilds now for raring edubuntu and kubuntu - until the alpha 2 is out the door.
<skaet> ?
<skaet> smoser,  any thoughts on whether you want to pick up the new kernel or not for your Alpha2 images?
<infinity> I can block the migration if anyone cares deeply, but it should be fine.
<stgraber> skaet: well, d-i has been uploaded so it's too late to avoid it but I don't really care
<infinity> No one's asked for a freeze or anything.
<stgraber> I think I looked at the changelog and nothing looked scary
<slangasek> skaet: I'm assuming that someone from edubuntu and kubuntu will tell me when they want autobuilds disabled for testing purposes
#ubuntu-release 2013-02-12
<slangasek> stgraber, ScottK: ^^ should I turn off autobuilds, to let the stuff on http://iso.qa.ubuntu.com/qatracker/milestones/255/builds start being validated?
<skaet> slangasek, checklist for milestones still has 3 days before,  so folks may not be thinking to tell you explicitly.   Can you send email out to ubuntu release?
<slangasek> skaet: fair enough
<slangasek> stgraber, ScottK: so, disabling per the above
<skaet> highvoltage, Riddell (also)  ^ please let slangasek know when you want a rebuild.
<Riddell> ack
<stgraber> skaet: we're still discussing with highvoltage (in person) but there are good chances we'll do a last minute opt out from alpha-2 as the bits we wanted to land aren't quite there yet and we have 12.04.2 that's much more important to us
<infinity> plars: How long does it take you to spin up a quick alternate test install?
<infinity> plars: Comparing file lists, I think it's plausible that I've fixed https://bugs.launchpad.net/ubuntu-cdimage/+bug/1121179 in the latest precise dailies, but it needs an install test to be sure it all works.
<ubot2> Ubuntu bug 1121179 in Ubuntu CD Images "Ubuntu 12.04.2 alternate AMD 64 ISO image Feb 10 installing mesa 8.0.4 not 9.0.0 - LTS quantal" [High,Triaged]
<stgraber> infinity: so I have a fix for LTSP itself which I think will work, however I need to come up with some clever hack to test it as it could just be the bug hiding some more X-stack related problems
<infinity> stgraber: Well, it wouldn't have been x-stack-related at all, it was tripping up trying to install a kernel that's not on the media.
<stgraber> infinity: sure, but once it's past that step it'll try to install a bunch of packages which depend on the X stack and we can't see that going until the kernel problem is fixed
<infinity> stgraber: True.  Though, as long as it's not explicitly installing individual X bits, but rather just installing ubuntu-desktop or something, it should work.
<stgraber> it's installing individual X bits
<infinity> Oh, that could be fun. :)
<stgraber> that's why I'm worried ;)
<infinity> They should all be provided in one way or another.
<infinity> But we'll see.
<stgraber> right, for now I'm not changing any of the dependencies and hoping the provides will be enough, otherwise I'll have to add a bunch of XYZ-lts | XYZ to ltsp and ldm
<stgraber> infinity: is that the one I need for the X stack ^ or is 11.1 enough?
<infinity> stgraber: .1 should be fine, this one just drops a langpack.
<stgraber> ok
<antarus> infinity: sigh, I see your kernel upload for 3.2 and I just think 'damn why do I roll my own kernel'
<infinity> antarus: Yeah, why do you?
<infinity> &^@!$ 708MB and 705MB... So close to 703.
<infinity> Yet so very far.
<infinity> We've officially run out of languages to remove (other than English), this could get interesting.
<stgraber> who needs English, just ship with C.UTF-8 ;)
<infinity> Dude, I've been making that argument for a while.
<antarus> infinity: still trying to figure that part out ;)
<infinity> antarus: Our kernel SRU release process has gotten remarkably slick over the last year or two, I'd say you can't really go wrong.
<antarus> I'm fairly sure we have patches you won't take
<infinity> Try us.
<infinity> (Or, better yet, get them upstream)
<antarus> I'm fairly sure we have patches we can't release, period ;)
<antarus> certainly for new stuff
<infinity> Oh, that's problematic. :P
<antarus> I'm basically the guy that maintains the kernel
<antarus> and I don't know anything about kernels
<antarus> so...
<antarus> I mostly tell them to get linus to apply it
<antarus> and then I'll backpor tit
<infinity> Though, if your patches are sanely self-contained, you could look at just tracking our kernels and rebasing on them, which is cake.
<antarus> yeah
<antarus> we do that for upstream right now
<infinity> If you look at how Andy set up -lowlatency, tracking/rebasing as another flavour would be minimal effort.
<antarus> It was not clear to me why we selected upstream instead of you as the base
<antarus> but I was new to the team at the time
<infinity> I have a desperate need to take a break and watch cartoons.  Back in a bit.
<stgraber> infinity: got a successful install here. Will have the package uploaded in a few minutes once I confirmed the installed system is fine.
<infinity> stgraber: Does that successful install also mean my change to the alternates was fine (ie: can I close that bug)?
<stgraber> infinity: I think so, let me quickly check if my dpkg -l is full of -lts stuff
<stgraber> infinity: yep, installed system is full of -lts-quantal packages
<infinity> \o/
<smoser> skaet, we can re-spin to pick up a kernel, it can't hurt. whe nis that due ?
<smoser> utlemming, ^
<smoser> we're planning on tagging something as "alpha-2", so we'd like that to have the newest kernel available at the time.
<stgraber> infinity: there you go ^ it's only been tested on an hand-patched amd64 d-i install but I think the code is sane (unless you don't have any of those packages, but then, it should fail anyway)
<plars> infinity: back now if you have something you want me to try
<ScottK> slangasek: I just pushed up the same britney block we used for Alpha 1 (I was supposed to have improved it, but I haven't had time).
<ScottK> skaet, Riddel, stgraber: ^^^
<slangasek> ScottK: cheers
<stgraber> slangasek: infinity doesn't seem to be around at the moment, if you have a sec can you review ltsp in precise-proposed?
<slangasek> ooking
<slangasek> looking, too
<slangasek> stgraber: can you spell out a test case in the bug report quickly?
<stgraber> slangasek: oh, I assumed we had a better description in that bug ;)
<slangasek> the diff itself looks fine
<stgraber> slangasek: bug updated
<ScottK> It would be nice, if someone has a minute, to get the MRE updates for postfix into precise/quantal proposed while they are still an MR update of the version that's in raring (shortly they'll be the version that used to be in raring).
<ScottK> Personally, I'm running it in production, that's how confident I am of it.
<stgraber> slangasek: it's not really easy to test the new package without building the media with it though. The only way I could think of is to let it fail, undo what the first try did, use netcat to write the new script in place of the old version, then have d-i retry.
<slangasek> stgraber: is the media currently being built without -proposeD?
<stgraber> slangasek: indeed it's
<slangasek> stgraber: I guess we (you) could do a test build with -proposed back on, for validation?
<stgraber> slangasek: so my current plan is to md5sum the script in the new binary package against the one I used in my test VM, if they match, I'll just mark the bug verification-done because that'll be identical to me doing another install and will save me an hour
<slangasek> ok
<stgraber> right, just pulled from LP, md5sum of the script in the binary package matches the one on my working installed system
<stgraber> slangasek: looks like it's built everywhere already, so once that's published I guess we're good to have this copied and unless we're waiting on something else, then respin the alternate images
<smartboyhw> Hey Noskcaj
<Noskcaj> hey smartboyhw
<slangasek> stgraber: can you keep an eye on it and let me know when it's published so I can copy?  I'm only half here at the moment
<smartboyhw> chilicui1, would you like to fix Bug 1122293 or I do it?
<ubot2> Launchpad bug 1122293 in Ubuntu Manual Tests "Nautilus testcase needs clarified" [Undecided,New] https://launchpad.net/bugs/1122293
<stgraber> slangasek: LP says it's published (which I think is good enough for a copy)
<slangasek> stgraber: ack, copeied
<chilicui1> I've already done it smartboyhw, I'm just waiting input, I can't reproduce the issue which had balloons
<smartboyhw> chilicui1, I just realized: Wrong channel. Sorry release team?:P
<infinity> cjwatson: ^-- Probably way too late, but the backport is straightforward and obvious.
<didrocks> infinity: hey, do you know if some builders are stuck? on https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4293814, it's been at least 10 minutes that I spotted it doesn't move (and I doubt libappindicator is taking 8 hours to build as previous ones were ~26 minutes)
<infinity> didrocks: That's going to be an angry build, not an angry builder, I bet.  I'll look into it.
<infinity> didrocks: Does it have a testsuite that, say, backgrounds something (maybe dbus?) and then fails to clean up?
<didrocks> infinity: it's using dbus-test-runner, so I assume that yes, can it be stuck randomly because of that? (previous builds worked IIRC)
<didrocks> but dbus-test-runner has a 300s timeout though
<infinity> didrocks: Is that the same thing that keeps breaking hud builds? >:(
<didrocks> infinity: well, same upstream, so probably same issue :)
<infinity> didrocks: It's clearly not fixed, and it's really pissing me off at this point.
<didrocks> infinity: did you ping tedg about it?
<infinity> Yes.  Several times.
<infinity> And he put someone else on it, apparently.
<didrocks> do you know who this is?
<infinity> And then webops has had to clean up their builds every day.
<infinity> So, yay.
<infinity> No idea who.
<didrocks> infinity: ok, I'll check with him, sorry for the stuck build
<didrocks> and do both at the same time
<didrocks> and ensure it's timely done
<didrocks> infinity: what process is stuck? is it dbus-test-runner itself or a dbus-launch one?
<infinity> buildd   14255 98.5  0.1   2396  1116 ?        R    02:31 480:16 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
<infinity> buildd   14257  0.0  0.0      0     0 ?        Z    02:31   0:00  \_ [dbus-daemon] <defunct>
<didrocks> (if you have a bug report, it would be easier to track/beat the hammer ;))
<infinity> ^-- Those are the two we always have to kill.
<infinity> didrocks: I don't tend to file bug reports against private PPAs...
<infinity> (Which this has been, up until today)
<didrocks> infinity: it's good to know the HUD is also affected, I was going to add it to the public release this week
<infinity> didrocks: Also, we see it a LOT on quantal/i386, for some reason, though this was raring/armhf this time, so it's clearly not a Q-specific thing.  But that might make it easier to reproduce.
<didrocks> infinity: yeah, here it's against raring, I think dbus-test-runner is just killing itself and not the dbus daemon that is spaws reliably
<didrocks> infinity: FYI: bug #1122948
<ubot2> Launchpad bug 1122948 in dbus-test-runner (Ubuntu) "dbus-test-runner is not killing dbus reliably" [Undecided,New] https://launchpad.net/bugs/1122948
<infinity> didrocks: That would seem to be the gist of it, yes.
<infinity> didrocks: I pointed ted at the telepathy-glib testsuite that gets this right, and got snarky responses about dbus-testrunner being "better" and "more modern" or something.
<infinity> My argument is that it's clearly not better because it breaks. :P
<didrocks> infinity: ahah, I experienced the same when talking about direct dbus-launch :p
<didrocks> infinity: well, issues can happens when building something news, fixing timely though is required when it's a regression to what worked in the past
<infinity> I'm all for people fixing their crap.  I'm just annoyed that we asked, what, two weeks ago to "disable these builds until the bug is fixed", and got nothing.
<didrocks> infinity: I agree with you, I'll get that on their list for sure and tell we won't release it in ubuntu until it's done properly
<ogra_> infinity, cadejo dead again ? i just got an empty omap4 failure mail
<ogra_> and i cant reach its http server
<ogra_> from nusakan
<infinity> ogra_: Looks like.  Asking for a reboot 'n tidy.
<ogra_> thx ... dont forget the lock :)
<infinity> I didn't. :P
<ogra_> well, i promised to think of itt the next time :)
<ogra_> (so next time i can forget it again :P)
<infinity> Looks like it's possible unstabbable, ticket filed.
<infinity> The good news is that nexus7 builds are on celbalrai now, so that still works. :P
<ogra_> sigh
<cjwatson> infinity: How's .2 looking?  I guess we should hand off before you get on a plane
<ogra_> oh, cool !
<cjwatson> ogra_'s care factor for cadejo suddenly plummets
<ogra_> haha
<ogra_> well, we need to make a decision about panda desktop builds at some point
<infinity> cjwatson: The alternate x-stack snafu appears to be good, images are barely oversizes and we've run out of languages to drop, so not sure what we want to do with that, and my apt backport is in the queue and should be harmless, if you want to review it, but it's probably too late regardless.
<infinity> ogra_: cadejo seems up now.
<ogra_> (TI dropped OMAP and we will likely not recieve drivers anmore ... in that light we likely need to re-consider building desktop images on pandas)
<ogra_> but i also think we shouldnt drop desktop on arm completely ... since it will be base for things like U4A
<ogra_> infinity, thx
<cjwatson> infinity: I'll review the apt backport and probably let it into -proposed, but I don't think I'll take it for .2
<cjwatson> Oversized - I'll have a look but we may just end up release-noting
<cjwatson> I suspect today is mostly me going through release notes and working out what hasn't been written yet
<infinity> ogra_: cadejo should work.  Maybe.
<ogra_> k, we'll see what it spits out over the day ...
<infinity> cjwatson: Yeah, not a huge loss if the apt thing makes post-.2... It just means the .2 install kernel will me marked manually installed.
<infinity> cjwatson: But so are all the pre-.2 kernels, so...
<cjwatson> Exactly
<cjwatson> Autotests look good with the exception of one cloud test failure
<mdeslaur> cjwatson: am I ok to publish security updates for precise now?
<mdeslaur> ok, releasing updates now
<cjwatson> mdeslaur: hmm
<cjwatson> mdeslaur: I've disabled propagation to -updates just in case that comes in useful
<mdeslaur> cjwatson: ok. I've released postgresql already. I still have qt4-x11 to release. Would you rather I wait?
<cjwatson> Ideally
<mdeslaur> until tomorrow?
<cjwatson> Just till tomorrow so that I can be sure we're done?
<mdeslaur> ok, I'll wait until tomorrow for qt4-x11
<cjwatson> Great, thanks
<jdstrand_> cjwatson: in related news, what about openjdk-6 for precise?
<jdstrand> cjwatson: (and hello :)
<cjwatson> Hmm
<cjwatson> The only images I currently suspect I'll need to respin are the alternates, which don't have openjdk; but I'd still prefer you hold off as I haven't gone through iso.qa yet
<jdstrand> cjwatson: do you think you would know by 21:00 UTC or your EOD, whichever comes first?
<jdstrand> cjwatson: basically, I've got a nunch of stuff I can do til then, but I could plan on publishing then
<jdstrand> cjwatson: I'm fine with us pinging each other, or we could wait one more day if it is necessary
<cjwatson> jdstrand: If you can just wait one more day it would make life much easier
<cjwatson> I don't expect to need to respin after then
<jdstrand> ok
<plars> stgraber: is there going to be a respin soon to fix https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1122525 ?
<ubot2> Ubuntu bug 1122525 in ltsp (Ubuntu Precise) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,Fix released]
<stgraber> plars: there should be, yes
<plars> stgraber: I tried enabling proposed on my install and it seems I'm able to get past it now
<stgraber> plars: yeah, I tried the fix and it's good, we just need a respin to get it. Though I suspect infinity is still working on finding ways to fix the oversizedness of alternate.
<plars> right
<plars> ok thanks
<cjwatson> Uh, infinity's on a plane I think
<stgraber> or about to get on a plane, yeah
<cjwatson> I intend to release-note the oversizedness of alternate; it's only on amd64 and I don't see anything straightforward
<antarus> sadly 'snakes' is already taken as a nick ;p
<stgraber> ok, then we should respin alternate to get the LTSP fix
<cjwatson> I hadn't realised we hadn't already done so
<cjwatson> However, inclined to wait for mlankhorst's libpciaccess fix
<slangasek> infinity, cjwatson, ScottK: bug #1123379 looks like Kubuntu alternates for .2 are rather broken... which way are Kubuntu images supposed to go?  Using the quantal backport stack or not?
<ubot2> Launchpad bug 1123379 in Ubuntu CD Images "Kubuntu alternate install 12.04.2 2013_02_11 AMD 64 bit cannot find/load kernel modules" [Undecided,New] https://launchpad.net/bugs/1123379
<antarus> can someone with an Ubuntu box just confirm that /root is 755 ?
<antarus> hrm, examining base-files it looks like it should be 700
<slangasek> antarus: 0700 on a new install, here
<antarus> excellent
<antarus> tis a bug in our puppet manifests
<antarus> yay
<Riddell> slangasek: not using backported stack
<Riddell> slangasek: what's broken about them?
<Riddell> I found some issues
<slangasek> Riddell: the aforementioned bug shows the alternate CD failing to find kernel modules due to mismatched versions
<Riddell> it moans about no wifi firmware on install for me
<Riddell> sounds the same
<slangasek> no, this is a lot more than wifi firmware
<slangasek> "no kernel modules were found" - implies the udeb repo and the initramfs don't match
<slangasek> Riddell: do you see a different message with current images?
<Riddell> slangasek: yeah, something about can't find firmware for iw
<slangasek> philwyett: see above; use of the 3.2 kernel on the Kubuntu CDs is by design
<slangasek> hmm
<philwyett> slangasek: OK. Was informed previously that Kubuntu matches Ubuntu. But decision to use old stack is fine.
 * Riddell sleeps
<antarus> do I see another flash patch?
<antarus> heh
<cjwatson> slangasek: I'll see about sorting out those Kubuntu images
<cjwatson> (Had just seen the bug in mail - I was out for a bit, going to work for a few more hours now)
<slangasek> cjwatson: cheers
<cjwatson> ... as soon as my fingers work properly again.  damn it's cold out there.
 * cjwatson starts off a custom build for this libpciaccess thing
<cjwatson> Hmm, I'm going to have to do something desperately evil to disentangle Kubuntu udebs
<slangasek> presumably unrelated to the name of the package that's just landed in the new queue :)
<cjwatson> Indeed :)
#ubuntu-release 2013-02-13
 * cjwatson apologies profusely for kubuntu.precise r1164 and xubuntu.precise r906
<cjwatson> Grossly unpleasant hacks that they are - but we should be able to get rid of those for .3
<cjwatson> OK, respinning Ubuntu alternate (for bug 1122525) and Kubuntu and Xubuntu alternates (for bug 1123379)
<ubot2> Launchpad bug 1122525 in ltsp (Ubuntu Precise) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,Fix released] https://launchpad.net/bugs/1122525
<ubot2> Launchpad bug 1123379 in Ubuntu CD Images "Kubuntu alternate install 12.04.2 2013_02_11 AMD 64 bit cannot find/load kernel modules" [Critical,Triaged] https://launchpad.net/bugs/1123379
<cjwatson> Hopefully those are the last respins
<cjwatson> Should deal with Xubuntu alternate amd64's oversizedness too
<cjwatson> I thought cdimage had run out of ways to surprise me
<cjwatson> But now the Kubuntu images (at least) have nic-modules-* and others apparently without a Priority field
 * cjwatson fixes, I think
<cjwatson> Will need a couple of publication cycles, so I'll probably go for a nap before it's finished
<cjwatson> (Hence, tangentially, the copy of refit to precise-updates that some may have noticed on -changes.)
<cjwatson> Right, repeating all the earlier respins
<cjwatson> (Ubuntu, Kubuntu, and Xubuntu alternate)
<cjwatson> Those dailies are looking more plausible now.  Bed.
<plars> cjwatson: took a quick look at the new alternate images and on a physical machine, they install and desktop comes up fine, though it's telling me I have incomplete language support.  I've never had a clear answer on whether this is expected to be the case or not, but considering it had full access to download whatever it needed during the install I would think it shouldn't need to get more english language packs after install
<plars> let me know what you think on that...
<plars> but under virtualbox it has the same problems I mentioned earlier in bug# 1122072
<plars> bug #1122072
<ubot2> Launchpad bug 1122072 in libpciaccess (Ubuntu Precise) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [High,Fix committed] https://launchpad.net/bugs/1122072
<skaet> slangasek,  have removed Edubuntu from Alpha 2 manifest per email from highvoltage.   Added Ubuntu Cloud images to the manifest per IRC from smoser.
<slangasek> huh, ok
<slangasek> switching the cron around
<slangasek> ubuntu-server disabled in cron, edubuntu re-enabled
<skaet> thanks
<cjwatson> plars: It's unexpected and rather weird, but not a blocker given the general EOL nature of alternates
<cjwatson> plars: (I'll have a look if I have time, though.)
<psivaa> cjwatson: xnox: Are raring server images delayed today? Generally they appear earlier than the desktop ones.
<xnox> psivaa: "<slangasek> [05:27:37] ubuntu-server disabled in cron, edubuntu re-enabled"
<xnox> psivaa: something to do with alpha2 'soft-freeze' / release
 * xnox doesn't have access to that machine to actually check what's currently configured to build / is building.
<Laney> server is indeed commented out
<psivaa> xnox: Laney: ahh ok, thanks
<skaet> Laney, psivaa, xnox - hmm...   it was cloud images that are going to be added,  not server.   raring server should be re-enabled for the daily.
<cjwatson> I've re-enabled server and kicked off a daily build.
<psivaa> cjwatson: skaet: thanks :)
<Laney> What's the preferred way of SRUing when there's already a change in proposed? Upload the new change or try to get the old one to updates first?
<cjwatson> The latter if possible - it avoids tangles.  We can accommodate the former though.
<cjwatson> (If you stack SRUs, and the package in question doesn't already have a version in -updates, remember to use -v<version in release pocket> when upgrading.  Hopefully we'll get this LP bug fixed soonish.)
<Laney> I'll give the guy a few days to respond
<Laney> sure
<cjwatson> s/upgrading/uploading/
<seb128> Laney, you can usually upload, review time makes likely that the previous one will be in -updates before your upload gets accepted (if the previous one seems likely to be validated)
<psivaa> stgraber: cjwatson: bug 1124029 is still occurring but on amd64+mac image. Still trying on amd64 and i386 though.
<ubot2> Launchpad bug 1124029 in ltsp (Ubuntu) "'ltsp-client-builder' failed with error code 1 during LTSP server installation with 20120213.1 alternate images" [Undecided,New] https://launchpad.net/bugs/1124029
<Laney> it's not that likely in this case as it's been outstanding since November
<cjwatson> psivaa: sounds like it must be a different cause; the failure is a general one
<cjwatson> from before, I mean
<psivaa> cjwatson: ok, understand. but i was not sure if this will affect i386 and amd64 too
<cjwatson> psivaa: from the logs I just quoted in the bug, I suspect that it may be amd64-specific
<cjwatson> But it's not entirely clear
<cjwatson> Actually, maybe that apt warning is just noise for this purpose
<psivaa> cjwatson: ok thanks, ill confirm in a little while
<cjwatson> It's probably that touch failure that matters; maybe fallout from /run?
<seb128> Laney, if it's sitting there since november either we need to get it reviewed/in or it's invalid and we need it kicked out, what upload is that?
<Laney> seb128: gst-plugins-good0.10. I pinged the guy.
<seb128> ok, otherwise we can probably do a "it might or might not fix the issue for good but there is no regression and it fixes it for some users so let's mark it verified"
<cjwatson> Curious, though, since in-target has bind-mounted /run onto /target/run since oneiric
<psivaa> cjwatson: just added a note saying that this is also a side-by-side installation in the bug.
<cjwatson> *Probably* doesn't matter
<cjwatson> psivaa: Is this the alternate image?
<psivaa> cjwatson: yes
<cjwatson> I assume this means there are no automatic tests of LTSP
<psivaa> no there are not
<cjwatson> Since the dashboard is (effectively) clear
<cjwatson> psivaa: trying to reproduce it now
<rtg> why hasn't Raring linux-firmware been promoted from -proposed ? I thought that was automatic when all build dependencies were satisfied.
<jdstrand> cjwatson: ping regarding precise security updates (openjdk-6 for me, mdeslaur has others)
<psivaa> cjwatson: ack, sorry had to go out. the installation on i386 on an 8G hard drive dell mini has failed before going to Build LTSP chroot step because no space left on device.
<smoser> utlemming, when you arive, we need to get ISO tracker populated http://cloud-images.ubuntu.com/raring/20130213/ i guess would be our candidate.
<Riddell> anyone admit to rejecting cantata from New?
<cjwatson> jdstrand: I want to finish diagnosing psivaa's LTSP bug first
<cjwatson> rtg: It's blocked pending the community-flavour Alpha 2
<cjwatson> rtg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html lists that
<rtg> cjack
<cjwatson> (well, it shows it's a manual block, at least)
<rtg> cjwatson, ok. thanks
<jdstrand> cjwatson: ack
<stgraber> cjwatson: want me to look at LTSP on amd64+mac? (that'd be in a non-mac VM though)
<cjwatson> stgraber: Sure
<cjwatson> My install is still running
<plars> cjwatson: but it's also a problem on desktop, not just alternate
<cjwatson> plars: What is?
<cjwatson> Incomplete language support?
<cjwatson> Well, OK - but even then I think that message is a minor flaw
<Riddell> we want to get a SRU in of kde-workspace for bug 1123126 in 12.04.2 kubuntu
<ubot2> Launchpad bug 1123126 in kde-workspace (Ubuntu Precise) "12.04 plasma init script order wrong" [Critical,In progress] https://launchpad.net/bugs/1123126
<Riddell> who's good to look into that?  ScottK? infinity?
<Riddell> bdmurray?
 * ScottK can look.
<ScottK> Are we going to respin for this?
<ScottK> Riddell: ^^^
<ScottK> Riddell: I don't see it in queue yet.
<plars> cjohnston: the issue with X not starting under virtualbox - it's the same as I was seeing in the desktop image you built for me yesterday after we got past the libpciaccess bug
<Riddell> ScottK: yes it'll need a respin
<ScottK> OK.
<Riddell> are we using an etherpad to keep track of things?
<ScottK> Riddell: I don't suppose that while we're respinning there's anything we can do to shrink the live images?
<cjohnston> I'm guessing ^^ was for cjwatson
<Riddell> ScottK: I can't think of anything immediately
 * Laney hugs cjohnston 
<cjohnston> Laney: I feel so abused.. lol
<plars> cjohnston: we really gotta do something about your name
<plars> :)
 * Laney starts a "one, two, three, tab" campaign
<ScottK> At least the alternates fit.
<plars> having to type 3 characters rather than 2 in order to ensure accurate tab completion is far too inconvenient!
<cjohnston> Laney: +1
<cjwatson> Riddell: etherpad> no
<cjwatson> Riddell: kde-workspace> OK, get it in the queue and I'll have a look
<cjwatson> ScottK: You could lose a language pack, but it'd take a live-build SRU :-/
<cjohnston> Laney: much more convenient to tab complete someone else, and let everyone figure out what you really meant ;-)
<cjwatson> plars: Curious that there are two success reports in the bug ... needs an X developer to unpick
<ScottK> Ah.  A bit late for that now, I'd imagine.
 * xnox points people again to the option of "tab completion based on last used order" in most irc clients that gets me cjwatson on cj<tab>
<ogra_> xnox, ++
<plars> cjwatson: it works fine on hardware, just not under virtualbox
 * xnox ponders if I should upload it enabled by default in irssi & xchat
<plars> cjwatson: so maybe they aren't going far enough? psivaa: can you try it too?
<cjwatson> plars: So that indicates to me that it's a worthwhile improvement
<ogra_> xnox, would make sense i think ...
<cjwatson> plars: Perhaps we need the xorg-server change as well ...
<plars> cjwatson: it could be that this is just a new bug and unrelated to the previous one
<cjwatson> (Which isn't in -proposed because I didn't think we needed it yet)
<cjwatson> Ah, no, xorg-server in the queue is something quite different AFAICS
<cjwatson> plars: Could you file a separate bug so that we can split these?
<plars> cjwatson: I will
<cjwatson> So that means respinning ... uh, everything
<Riddell> cjwatson, ScottK: kde-workspace 4:4.8.5-0ubuntu0.3 (Waiting for approval)   you can fight over it
<cjwatson> Sigh
<cjwatson> Riddell: Looking
 * ScottK surrenders.
<ScottK> (wasn't much of a fight)
<cjwatson> Well, I don't mind, you probably know the package better
<psivaa> cjwatson: plars i could try another alternate install on vbox once the ltsp installation is over
<plars> psivaa: thanks
<cjohnston> ScottK: since your here, do you have any thoughts on bug #1070772 probably specifically comment #4
<ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
<ScottK> cjohnston: No opinion.  I don't use it either.
<cjohnston> ScottK: ok. thanks
<ScottK> cjohnston: OdYx is really the only one that knows that package AFAIK.
<cjohnston> I spoke to him and he didn't have any idea, nor any time to look into it.
<cjwatson> plars: Do you have a syslog (or just a bug ref with logs) for any of these incomplete-language-support cases?
<plars> cjwatson: I can get that in just a bit
<cjwatson> My LTSP test install worked ...
<cjwatson> So I think I'm dependent on stgraber having a look
<stgraber> cjwatson: mine is still running but it passed the chroot creation step and is compressing now, so it's very unlikely it'll fail
<cjwatson> So current state: most things (except server) need respinning for libpciaccess; LTSP problem apparently unreproducible; kde-workspace building; incomplete language support needs investigation
<ScottK> cjwatson: If most things need respin, is an SRU for live build to shrink the Kubuntu live images a possibility?
<cjwatson> ScottK: powerpc would be easy enough to shrink, but I don't see any spare language packs in amd64, and I don't think that removing German from i386 will gain you enough space to be back under whatever the limit is
<cjwatson> ScottK: So I'm not sure it's worth it?
<cjwatson> (I've now looked at it in more detail ...)
<stgraber> cjwatson: ok, so I identified what line failed for psivaa but it doesn't make any sense...
<stgraber> in-target /bin/touch /etc/resolv.conf
<cjwatson> Removing German would save about 6.5MB
<cjwatson> stgraber: Yeah, I alluded to that above
<cjwatson> 11:57 <cjwatson> It's probably that touch failure that matters; maybe fallout from /run?
<cjwatson> 11:59 <cjwatson> Curious, though, since in-target has bind-mounted /run onto /target/run since oneiric
<ScottK> cjwatson: OK.  Let's leave it then.  Thanks for checking.
<cjohnston> /63/27
<cjwatson> ScottK: I think the Kubuntu limit for precise was officially 1GB anyway ...?
<cjwatson> Though it's true that earlier releases fit on a CD
<ScottK> cjwatson: No.  We were still trying to fit on a CD.
<cjwatson> Ah, well, the cdimage code lies then
<ScottK> We didn't switch until quantal.
<smartboyhw> I heard Xubuntu quit of having CD releases
<cjwatson> I suspect somebody changed it without an appropriate release guard
<cjwatson> (grr)
<stgraber> cjwatson: hmm, right. I suppose the same would happen if /run/resolvconf didn't exist though, but in either case, the apt-get would then fail because DNS resolution would be horribly broken...
<cjwatson> Right, you'd think
<cjwatson> And netcfg doesn't *seem* to have fallen over in a heap earlier
<stgraber> psivaa: can you easily reproduce this? if so, can you let me know when you have a machine that just got that problem (and is still in d-i)?
<GridCube> smartboyhw, http://irclogs.ubuntu.com/2013/02/11/%23xubuntu-devel.html#t21:49
<smartboyhw> GridCube, I knew.... I looked at the meeting logs
<GridCube> :D
<cjwatson> so ... why did nobody report this to ubuntu-cdimage?
<cjwatson> ah, only two days ago
<cjwatson> GridCube,smartboyhw: Shall I take this as a request to change the limit in our code?
<smartboyhw> cjwatson, 1. Ask knome for official confirmation please
<GridCube> cjwatson, please do ask kees
<psivaa> stgraber: i am trying the amd64 image to confirm the issue, and will let you know if it hits the issue
<stgraber> psivaa: ok, thanks
<GridCube> s/ kees / knome
<smartboyhw> I don't want to get killed for confirming things
<cjwatson> knome: ^-
<smartboyhw> While I am not even  a Xubuntu guy
<GridCube> its going to happen anyway though, but i can't wear knome's hat
<cjwatson> knome: I have the patch for the above once approved
<plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1124214 is the latest bug for alternate not working under virtualbox, and I believe it to be similar to the situation I was seeing in the build you made yesterday but we are still at 20120211 for the desktop builds.  Is there going to be a respin for desktop at some point too?
<ubot2> Ubuntu bug 1124214 in xorg (Ubuntu) "X does not start on alternate after installing in virtualbox" [Undecided,New]
<cjwatson> plars: Yes, I will be respinning desktop
<cjwatson> But I would like to understand the incomplete-language-support thing first
<plars> cjwatson: that's next on my list
<cjwatson> I'm trying to reproduce it locally now
<plars> cjwatson: the bug with syslog attached is bug #1124230
<ubot2> Launchpad bug 1124230 in language-selector (Ubuntu) "Language selector comes up after 12.04.2 rc candidate installation in english" [Undecided,New] https://launchpad.net/bugs/1124230
<slangasek> skaet: the original comment from smoser said "opting in for cloud-images and for server ISOs"; doesn't that imply server image generation should also be paused?
 * ScottK would think so.
<smoser> server team is not opting-in for server ISO.
<skaet> slangasek,  my understanding from him was AMI's not ISO's - but its best that smoser comment directly.
<smoser> sorry for confusion there.
<skaet> thanks smoser
<smoser> we were considering ISO, but will instead simply have a call for testing of a daily.
<cjwatson> plars: Did you say you saw this on desktop too?  I'm not seeing it
<plars> cjwatson: not so far, but if its similar to bugs like this we've seen before, it may not happen every time
<slangasek> skaet, smoser: ok, all clear now, thanks
<cjwatson> plars: Well, the proximate cause here is in pkgsel, which isn't code that's directly in the desktop image
<psivaa> stgraber: i did not see the ltsp issue on the next amd64+mac installation
<psivaa> the amd64 installation did not complain but i can not restart the VM (using vbox) most probably due to the bug plars posted above
<cjwatson> plars: aha, got it
<cjwatson> Knew it looked vaguely familiar somehow :)
<plars> cjwatson: oh?
<cjwatson> Fix on its way
<cjwatson> slangasek,stgraber: ^- could I have urgent review of that for 12.04.2?
<cjwatson> Riddell,ScottK: How goes verification of kde-workspace?
 * ScottK looks at Riddell
<cjwatson> (I know it hasn't built on ARM/powerpc yet)
 * ScottK is tied up with $WORK ATM.
<Riddell> sorry got distracted by raring alpha 2
<Riddell> I'll get back to 12.04.2 now
<cjwatson> Let me know if you need a custom image build with -proposed
<stgraber> cjwatson: I'm happy to review but can't accept myself (not SRU team)
<Riddell> should be fine just installing on a live image and log in with a new user
<stgraber> cjwatson: is the fact that the variable type will change from a list to set cause a problem later on?
<stgraber> cjwatson: as in, should it be list(set( instead of just set( ?
<cjwatson> Addressed in the regression potential section of the bug :)
<cjwatson> And no - the only way that variable is used is by feeding it straight to sorted()
<cjwatson> Which takes any iterable
<stgraber> hehe, hadn't looked at the bug yet, sorry
<cjwatson> Sorry, forgot (again) you weren't SRU team
<stgraber> so yeah, perfectly safe if it's just sent through sorted()
<cjwatson> It's a straight cherry-pick from quantal and I double-checked the context
<ScottK> cjwatson: We should fix stgraber not being on the SRU team.
<cjwatson> We should
<cjwatson> bdmurray: Might you be around to review language-selector/precise for me?  (See above)
<cjwatson> Once kde-workspace is verified and copied, and language-selector is reviewed, verified, and copied, we can start respins
<Riddell> cjwatson: kde-workspace verified!
<Riddell> bug 1123126
<ubot2> Launchpad bug 1123126 in kde-workspace (Ubuntu Precise) "12.04 plasma init script order wrong" [Critical,Fix committed] https://launchpad.net/bugs/1123126
<plars> cjwatson: on the X problem I'm getting after intsalling alternate, I didn't realize, but Sarvatt pointed out that the 20120213.1 respin of alternate didn't have the libpciaccess0 fix in it. So when that respins it *should* work, but I'm still a bit leery on desktop because of the image I tested for you yesterday which had other problems.
<plars> as soon as we get the official respins of both, I'll take another look of course
<bdmurray> cjwatson: looking at it now
<bdmurray> cjwatson: accepted
<psivaa> stgraber: i have a machine with ltsp install failure with amd64+mac image, if you'd like  me to try anything with it
<stgraber> psivaa: ok, from a shell, can you do "ls -l /target/etc/resolv.conf" and "ls -l /run/resolvconf/"?
<smoser> utlemming, can you please provide slangasek with list of amis to populate tracker with ?
<smoser> and then have test done on those ? if you think we're ready for that.
<psivaa> stgraber: "wxrwxrwx 1 root root  29 Feb13 16.41 /target/etc/resolv.conf -> ../run/resolvconf/resolv.conf" for the first one but "/run/resolvconf/: No such file or directory" for the second
<stgraber> ok, the latter is the problem, though it's not an actual LTSP problem
<stgraber> (and as mentioned earlier, may cause a lot more problems as it essentially means you don't have DNS resolution in there...)
<stgraber> psivaa: can you pastebin: "ls -l /target/run" and "ls -l /run" (oh, and "ls -l /run/resolvconf" if it exists)?
<utlemming> smoser: yes, I'll populate the tracker now
<utlemming> slangasek, smoser: I have the ability to populate the tracker
<utlemming> smoser, slangasek: populated
<psivaa> stgraber: ok, in a minute, have to find a way to get those information from the console
<stgraber> psivaa: are you using libvirt?
<psivaa> stgraber: no this is on a real hardware
<stgraber> psivaa: ah, ok, you can go with something similar though.
<stgraber> psivaa: on your machine, do: nc -l 1234
<stgraber> psivaa: on the test machine do: <command> | nc <ip of your machine> 1234
<stgraber> that'll simply redirect the command's output over the network, you can then copy/paste it or even pipe it straight to pastebinit
<psivaa> stgraber: thanks for that, https://pastebin.canonical.com/84560/
<knome> cjwatson, yes, xubuntu wishes to switch to a 1GB image starting from Raring.
<knome> cjwatson, tell me if you need something else from me (please include nick so i'll notice). i thought infinity did something already, but not sure what exactly.
<cjwatson> knome: Not that I can see.  I've made that size limit change for you.
<cjwatson> Oh, BAH
<cjwatson> infinity: Please don't make that kind of change only on the deployment branch
<knome> cjwatson, ok, cheers! :)
<skaet> slangasek,  https://wiki.ubuntu.com/RaringRingtail/Alpha2/CommonInfrastructure - can you please review and update as needed any changes for the foundations portion.   It will get pulled into Kubuntu and Ubuntu Cloud release notes for Alpha 2.
 * cjwatson resolves the slightly different approaches infinity and he had taken
<stgraber> cjwatson: ok, so it looks like the problem is that in some cases we get /target/etc/resolv.conf as the usual symlink, pointing to /run/resolvconf which apparently exists! in /target but doesn't in /run, so the bind-mount of /run essentially hides it
<cjwatson> Perhaps the cheapest fix for now is a mkdir -p /run/resolvconf just before that in-target?
<cjwatson> It's a bit of a hack, but ...
<stgraber> cjwatson: yeah, I guess that'd work, assuming nothing tries to use the network from within the target after that
<stgraber> (I don't think we do in LTSP, but something else might)
<cjwatson> I don't think it can make the situation worse?
<stgraber> nope, won't make it any worse :)
<stgraber> I'll upload that hack now
<cjwatson> Ta
<stgraber> cjwatson: uploaded and paperwork done
<stgraber> psivaa: oh, were all the failing installs happening when you had no network?
<stgraber> psivaa: (just went through the initial syslog and noticed DHCP timing out)
<slangasek> skaet: we agreed at UDS that we weren't going to do "common" release notes via includes anymore except for documenting bugs
<slangasek> skaet: Secure Boot is certainly not relevant on cloud images, and is not a new feature in raring at all
<cjwatson> stgraber: Ah, heh, I'd been envisioning just mkdir -p without in-target, but as it happens since there's a bind-mount this should work too ...
<cjwatson> stgraber: please fix in raring too?
<stgraber> cjwatson: yeah, I figured that doing it through in-target would guarantee that it always get created at the right place (whether the bind-mount works or not)
<stgraber> cjwatson: I'd rather fix the actual bug in raring than upload the workaround and increase our delta with Debian
<cjwatson> Fair enough
<cjwatson> Accepted for precise, thanks
<stgraber> cjwatson: (not to mention we don't actually use that code path as we don't have alternate, only some weird people using netboot can still use those bits)
<cjwatson> True
 * cjwatson gets https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.2 into sync with reality
<cjwatson> plars: Curious, I could have sworn I'd included the new libpciaccess, but you're right
 * cjwatson â dinner
<cjwatson> I'll verify language-selector after dinner
<jdstrand> weird
<jdstrand> https://launchpadlibrarian.net/131163934/upload_4291631_log.txt
<jdstrand> INFO lxsession-edit_0.2.0-3ubuntu1_i386.deb: Version older than that in the archive. 0.2.0-3ubuntu1 <= 0.4.9.1~git20120828-0ubuntu1
<jdstrand> but I can't find 0.4.9.1~git20120828-0ubuntu1 anywhere
<skaet> slangasek,  common before was one page (Technical Overview) that had all the flavors on it ie;  https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3.   This is just a common section that can be embedded in each flavor announce page - so they get the common facts accurate, and all don't have to figure out the kernel version, etc.
<slangasek> skaet: and the decision at UDS was to not do this include because the content is not actually common
<slangasek> the commonality between edubuntu and ubuntu is completely different from the commonality between ubuntu and kubuntu, or ubuntu and ubuntu-server
<jdstrand> ok, 0.4.9.1~git20120828-0ubuntu1 corresponds to lxsession afaict, and it ships an lxsession-edit
<jdstrand> so I'll follow up with the uploader
<skaet> slangasek, same kernel and foundation projects.   Agree secure boot is not relevant on cloud images.   Left it there, since it wasn't working for Kubuntu for 12.10,  so its new to them.  But agree it probably shouldn't be in common, since it isn't relevant to the cloud ones.
<psivaa> stgraber: I am sure the failure on the second attempt was when there was no network ( comment #7) in the bug, but i am not really sure if that's the same case in the first attempt which i used to report the bug
<stgraber> psivaa: you didn't have network in the first one (or so says the log)
<psivaa> stgraber: ahh ok :)
<plars> stgraber: so on ltsp, I'm able to get the server side fully installed now, but the client is only getting as far as plymouth.  I've not tried on hardware yet, only in kvm and virtualbox with networking setup as recommended in the test case.  That should work though right?
<stgraber> plars: it worked in kvm here yesterday
<stgraber> (with server and client being both in kvm, two interfaces on the server, one to the internet, one to an isolated network with the other vm)
<plars> stgraber: that's what I'm doing, are you calling kvm directly or using something like virt-manager?
<stgraber> plars: through libvirt
<stgraber> plars: both VMs used cirrus graphic if that somehow matters
<plars> stgraber: that was for an older bug that doesn't seem to be affecting me here
<plars> stgraber: I'll try it again when we get the respins I suppose, I've not done much with libvirt and I'm not sure I trust vbox until the libpciaccess fix is included
 * cjwatson is back (subject to filial whims) and attempting to verify language-selector
<antarus> cjwatson: so when is ubuntu switching to systemd?
<cjwatson> Are you trying to distract me from 12.04.2? :)
<infinity> antarus: I'm going to assume that was trolling? :P
<mdeslaur> antarus: right after RHEL switches to Unity :P
 * mdeslaur can troll too
<cjwatson> stgraber: So LTSP is the last thing outstanding - how are things looking?
<stgraber> mdeslaur: well, they already use upstart ;)
<stgraber> cjwatson: well, the only easy way to test it is to spin images, so I'm inclined on marking verification-done and doing real testing once we get medias that psivaa can test
<stgraber> my standard way of patching those things during install relies on me having network and it looks like this bug happens only in networkless environment making things much trickier than usual
<stgraber> cjwatson: I can run a sanity check of the standard install path though if that makes you feel better :)
<antarus> mdeslaur: I'm not really trolling, is there a handy FAQ about it?
<antarus> cjwatson: I dunno, are you looking for a distraction? ;p
<slangasek> antarus: we have no plans to switch to systemd. Getting too much Lennart kool-aid? :)
<antarus> slangasek: I think we had bad experiences with hardy / lucid upstart, and now that we know it better..we are looking for more bad experiences?
<antarus> slangasek: its simply a common question that we get asked from our engineers ;)
<slangasek> heh
<psivaa> stgraber: will adding apt-setup/proposed=true help verify from proposed?
<antarus> I am actually going to start an unofficial internal faq that might hold this answer (and other, google-specific answers)
<mdeslaur> antarus: here: http://www.markshuttleworth.com/archives/1121
<slangasek> antarus: shall I draft you an answer about plymouth for the faq? :)
<slangasek> or has Marc Merlin stopped asking about that? ;)
<stgraber> psivaa: hmm, I may be wrong but I think this flag will only change the system's sources, it won't tell d-i to use -proposed as the udeb source
<antarus> slangasek: hahaaha hahahah haha haa....
<cjwatson> stgraber: You're wrong :)
<antarus> mdeslaur: helpful, thanks
<cjwatson> I hacked it up to work for udebs too
<antarus> slangasek: Marc still hates plymouth
<antarus> slangasek: I think even Gentoo is switching to Plymouth though
<stgraber> cjwatson: oh nice
<antarus> we are using bootsplash right now, which is unmaintained, there is a thread on gentoo-dev about it
<antarus> ;p
<slangasek> ouch
<stgraber> though in this case, there'd be little point setting this key as the bug appears only on internetless installs and so d-i wouldn't be able to pull the new udeb from the internet
<stgraber> cjwatson: anyway, I'm running a standard LTSP install now, should have the result in a bit less than an hour (sorry, very slow core2duo instead as my nice i7 is a useless brick at the moment...)
<stgraber> s/as/of/
<stgraber> ah no, s/instead // :)
<cjwatson> stgraber: OK.  I'll wander off for a while then and be back in a bit.
<cjwatson> Actually.  I could probably start some images building
<cjwatson> Right, respinning all precise images that contain X (for the libpciaccess fix) and that aren't Kubuntu (still waiting for kde-workspace to build everywhere) and that don't contain LTSP (so no alternates or DVDs, except Ubuntu Studio)
<cjwatson> $ set -x; buildlive ubuntu daily-live precise && DIST=precise for-project ubuntu cron.daily-live; buildlive ubuntu-core daily precise && DIST=precise build-livecd-base ubuntu-core daily; DIST=precise SUBPROJECT=wubi buildlive ubuntu && DIST=precise for-project ubuntu cron.wubi; buildlive mythbuntu daily-live precise && DIST=precise for-project mythbuntu cron.daily-live; buildlive ubuntustudio-dvd dvd precise && ...
<cjwatson> ... DIST=precise for-project ubuntustudio cron.dvd; buildlive xubuntu daily-live precise && DIST=precise for-project xubuntu cron.daily-live; UBUNTU_DEFAULTS_LOCALE=zh_CN buildlive ubuntu daily-live precise && DIST=precise build-chinese-edition; set +x
<stgraber> cjwatson: LTSP is good to go, just had a working install here (so at least it's not regression the d-i code)
<stgraber> I'll mark the bug verification-done in a sec
<cjwatson> Ah, brilliant, thanks
<cjwatson> No reproduction of the client problem plars reported?
<stgraber> nope, client worked fine here, got a working unity session on it
<stgraber> the server never started X though, but I'm blaming libpciaccess
<cjwatson> stgraber: The libpciaccess fix I know about is in precise-updates ...
<cjwatson> Well, I guess not if you were basing on the last alternate, though
<cjwatson> And kde-workspace is very close to done
<stgraber> cjwatson: right, I was installing from the latest alternate
<cjwatson> Gotcha
<cjwatson> stgraber: copied to -updates
<Logan_> jdstrand: I think that the lxsession-edit migration issue makes sense, as it wouldn't want to copy it to raring from raring-proposed if it had a binary with a lower version than one provided by another source package.
<Logan_> But I think a bug should be filed against lxsession to remove the lxsession-edit binary from that package, as it should be provided by the lxsession-edit source package, as it is in Debian.
 * cjwatson releases kde-workspace
<cjwatson> I really hope that's the last one
<plars> cjwatson: desktop on i386 still having some issues getting into live session that I'm not able to reproduce on amd64: bug #1124660
<ubot2> Launchpad bug 1124660 in xorg (Ubuntu) "Precise 20120213 i386 live session fails in virtualbox" [Undecided,New] https://launchpad.net/bugs/1124660
<plars> Sarvatt: ^
<cjwatson> OK, I think we knew virtualbox was likely to still be broken
<cjwatson> As long as it's virtualbox-specific I'm not going to consider it a blocker at this point; the last fix got in because it affected i915 too
<cjwatson> Just not enough time ...
<plars> cjwatson: yeah, I haven't had a chance to try it on hardware yet, but I'll be doing that this evening
<cjwatson> Sarvatt: I'd appreciate a release note written by one of the X cabal about this
<cjwatson> In /CommonInfrastructure I guess
 * plars -> supper, then back for more iso testing
#ubuntu-release 2013-02-14
<cjwatson> Respinning alternates/server (except Kubuntu alternate) for libpciaccess and LTSP
<cjwatson> $ set -x; DIST=precise for-project ubuntu cron.daily; DIST=precise for-project ubuntu-server cron.daily; DIST=precise for-project xubuntu cron.daily; set +x
<cjwatson> To be on the safe side, I'm leaving the Ubuntu and Edubuntu DVDs until kde-workspace has published, since I can't remember and the sequence would take a while to reach them anyway
<cjwatson> I should be able to start the last ones in 20 minutes or so, then go to bed
<cjwatson> Suppose I should write the announcement first though
<cjwatson> stgraber,Riddell,superm1,knome: I'd like advance notice of the URLs you're planning to publish 12.04.2 announcements at, if any
<cjwatson> I don't see any Ubuntu Studio contacts here just now ...
<cjwatson> Finishing the set now by respinning Kubuntu and the DVDs
<Riddell> cjwatson: http://www.kubuntu.org/news/12.04.2-release I'd say
<cjwatson> Thanks
<stgraber> cjwatson: sure, one sec
<stgraber> cjwatson: http://www.edubuntu.org/news/12.04.2-release
<cjwatson> stgraber: Thanks
<cjwatson> Riddell,ScottK: ^- in case you didn't notice the Kubuntu builds emerging above, BTW
<Riddell> cjwatson: I'll get on them first thing tomorrow
<Riddell> alpha 2 is all good except for arm
<Riddell> oh and upgrade isn't working either
<Riddell> need to do bug reports for them
 * Riddell snoozes
<highvoltage> night Riddell
<micahg> cjwatson: zequence is the Studio contact
<cjwatson> Thanks
<cjwatson> zequence: I'd like advance notice of the URLs you're planning to publish Ubuntu Studio's 12.04.2 announcement at, if any
<cjwatson> Sorry, terrible with names sometimes
 * cjwatson â bed
<zequence> cjwatson: there's the wiki https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuStudio, and then we're publishing on our website  http://ubuntustudio.org/2013/02/ubuntu-studio-12-04-2-lts-precise-pangolin-release-notes/ (not published yet). smartboyhw is actually doing this work for us atm
<smartboyhw> Actually the release notes are ready in the website
<smartboyhw> Just that people won't see it till 6:51 hours later
<xnox> cjwatson: website team is thinking to recommend "(windows8 logo) Using recent computer with Windows 8 and/or UEFI? Choose 64-bit image"
<xnox> and similar message that "currently Wubi is not compatible with windows 8"
<smartboyhw> xnox, agree. So many people are asking about this in Ask Ubuntu
<xnox> smartboyhw: website team wanted to find a very good written and complete up-voted question / answer
<smartboyhw> xnox, I think there is one
<smartboyhw> Wait
<xnox> cause this page: https://help.ubuntu.com/community/UEFI can be a little overwhelming
<smartboyhw> xnox, http://askubuntu.com/questions/221835/installing-ubuntu-on-a-pre-installed-uefi-supported-windows-8-system
<smartboyhw> Which is also overwhelming:P
<cjwatson> zequence: Thanks, it's just for a link in the announcement; I'll use the latter
<cjwatson> xnox: That sounds like a sensible approach
<cjwatson> I think the reasons we recommend 32-bit where it's usable stand, but that's a simple enough description of the exception
<xnox> yeap.
<xnox> smartboyhw: edited that answer to include 12.04.2 or 12.10+ 64-bit
<smartboyhw> xnox, good
 * xnox likes having spare askubuntu karma for such things =))))
<smartboyhw> xnox, you = dina?
<smartboyhw> weird:P
<smartboyhw> xnox, you have so much rep:(
<xnox> ÐÐ¼Ð¸ÑÑÐ¸Ð¹ = ÐÐ¸Ð¼Ð°
<xnox> easy
<smartboyhw> LOL
<cjwatson> That answer has actively untrue information
<cjwatson> Such as the claim that Windows 8 introduces UEFI
<cjwatson> (I don't have time to edit it right now, but I'd say that question/answer is rather too long and waffly for a website link)
<cjwatson> And it has an overblown claim about Secure Boot
<xnox> thanks.
<cjwatson> I think they're going to use help.u.c/community/UEFI which I agree is also a bit much but at least is intended as documentation
 * cjwatson starts pre-publishing
<cjwatson> Looking pretty good on testing so far with the exception of the known vbox bug
<cjwatson> (For which there's a known fix for 12.04.3)
<cjwatson> So either all that work yesterday was justified or testers are burned out :P
<knome> cjwatson, xubuntu not doing one.
<cjwatson> knome: Thanks
<cjwatson> (You still want the release, though, right? :-) )
<psivaa> cjwatson: #testing is ongoing and looking good, on hw and kvm. ltsp test is currently running
<smartboyhw> cjwatson, that's exactly what I want to ask
<smartboyhw> Woohoo thanks cjwatson
<smartboyhw> For the bug:P
<cjwatson> np, was just going through the tracker
<cjwatson> superm1,Daviey: So I think a Mythbuntu 12.04.2 announcement link (if any) is the only one I'm now missing
<cjwatson> And I still probably wouldn't object if there were more interesting high-profile features to add to https://wiki.ubuntu.com/PrecisePangolin/Announcement/12.04.2
<Daviey> cjwatson: Ah, i think tgm4883 was on the hook for that.  I'll check in with him when he arrives today.
<cjwatson> Aha, thanks
<cjwatson> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Mythbuntu is still headed by a 12.04.1 section; fine if that's what you want
<cjwatson> Hm, forgot to post netboot to the tracker
<smartboyhw> cjohnston, uh oh
<smartboyhw> Oops
<smartboyhw> cjwatson: Uh oh
<cjwatson> Not the end of the world, it's not like it's possible to not release them
<cjwatson> And should be fine, but I ought to do it anyway
<Daviey> Also, 2factor can burn in a fire.
<ogra_> ++
<ogra_> !!!!!!!!!!!!!!!!!!
<ogra_> Daviey, try U1 with an unregistered device :)
<ogra_> lots of fun
<Riddell> bah I still get no kernel modules found on precise i386 kubuntu i386 image
<smartboyhw> Report: The "kernel modules not found" doesn't exist on amd64
<cjwatson> Riddell: desktop or alternate?
<cjwatson> I guess must be alternate
<Riddell> yes alternate
<cjwatson> downloading
<Riddell> thanks
<davmor2> ogra_: what's the issue with u1 on an unregistered device?
<ogra_> davmor2, it wants 2Fa auth
<davmor2> Daviey: Allow me to stake out 2fa for you to pour on the petrol
<ogra_> davmor2, if i dont have my yubikey with me i'm screwed
<davmor2> ogra_: you could change 2fa down from always use, to use on sites that demand it and then u1 doesn't.
<ogra_> there is an option for that ?!?
 * ogra_ will need to read more docs it seems
<davmor2> ogra_: https://login.ubuntu.com/ just below personal details
<cjwatson> stgraber: Could you copy all the netboot builds from Precise Daily to Precise 12.04.2?
<cjwatson> I don't know if that's something I can do, or if so how to do it
 * ogra_ hugs davmor2 
<davmor2> ogra_: you still get hit on the site just not on the client etc  it'll cut it down by about 30-60% depending on where you go in your work day
<ogra_> well, at least i should be able to edit bugs without 2Fa requirement again
<ogra_> (public ones)
<ogra_> and U1 should work ... thats enough
<davmor2> ogra_: you'll still get it on LP if you login, but then it shouldn't require it
<Daviey> cjwatson: did you see my comment on bug 1116382 ?
<ubot2> Launchpad bug 1116382 in openvswitch (Ubuntu Precise) "openvswitch-datapath-dkms FTBFS with 12.04.2 3.5 kernel" [Critical,Fix committed] https://launchpad.net/bugs/1116382
<cjwatson> No
<cjwatson> I was bulk-moving all the milestones
<cjwatson> And I did say to jamespage that this had missed the boat and he said that was OK ...
<cjwatson> Daviey: If it isn't on the ISO, what does it matter if it lands an hour after the 12.04.2 image release? :)
<jamespage> ditto for iscsitarget
<jamespage> so long as they land in -updates as soon as possible after 12.04.2 it should be OK
<cjwatson> Yes
<Daviey> cjwatson / jamespage: Ok, i just didn't want an out-of-gate bad experience.. but hours is surely fine :)
<cjwatson> I may flush earlier, but I still need to sort out this Kubuntu thing ...
<smartboyhw> cjwatson, testing if Xubuntu has that problem too
<cjwatson> (Sorry for delay, my daughter cut her foot and needed immediate attention)
<cjwatson> smartboyhw: Thanks; though I suspect that once I've analysed it I'll be able to check centrally
<smartboyhw> cjwatson, OK
<mdeslaur> cjwatson: what's the status on me releasing qt4-x11 security updates today?
<cjwatson> That depends on what this Kubuntu problem is
<cjwatson> You'll be able to do so later today for sure
<cjwatson> Oh, blast, generic vs. generic-pae
<mdeslaur> cjwatson: cool, let me know when I can. Thanks!
<cjwatson> Hate everything
<smartboyhw> cjwatson, oh
<cjwatson> smartboyhw: Won't affect you, I don't think
<cjwatson> Since Xubuntu uses generic across the board
<smartboyhw> cjwatson, yes but anyway I still needed to test it
<cjwatson> Bah, hand-editing strikes again
 * smartboyhw gives a punchbag to cjohnston 
<smartboyhw> oops
 * smartboyhw gives a punchbag to cjwatson 
<cjwatson> Seriously.  Three letters then tab. :)
<smartboyhw> cjwatson, I'm lazy:P
<ogra_> or set up your IRC client properly
 * smartboyhw is stupid in IRC
<ogra_> there is an option for tab completion that isnt using A-Z
<ogra_> but completes based on who spoke last in the channel
<Riddell> cjwatson: what is -pae?
<cjwatson> The kernel flavour you're meant to be using
<cjwatson> I made a seed mistake.  Cleaning up now
<cjwatson> And actually Xubuntu is a bit wrong too ...
<smartboyhw> cjwatson, damn I am testing it right now............
<cjwatson> I *think* in the Xubuntu case this will only cause bloat
<knome> why you bloat us :P
<smartboyhw> knome, +1
<cjwatson> If nobody's tested it yet I could fix and respin
<smartboyhw> cjwatson, you mean which image?
<cjwatson> Xubuntu alternate i386
<smartboyhw> cjwatson, thank you I'm testing it RIGHT NOW in Testdrive
<smartboyhw> :(
<cjwatson> Hm, perhaps not
<smartboyhw> cjwatson, is it a big problem?
<cjwatson> It doesn't actually appear to have the generic-pae kernel on it
<cjwatson> So it should be fine
<smartboyhw> cjwatson, no
<cjwatson> OK, so it's just Kubuntu alternate i386
<smartboyhw> respin and I will test it immediately:P
<cjwatson> Respin what?
<cjwatson> Didn't realise you tested Kubuntu
<smartboyhw> cjwatson, yep. I and Riddell were testing it at the same time when Riddell told me of the bug
<cjwatson> Respinning
<Riddell> we kidnapped smartboyhw for kubuntu :)
<cjwatson> Heh
<smartboyhw> Riddell, no I volunteered:P (I always like helping flavors do their tests0
<smartboyhw> cjwatson, nobody doing Mythbuntu?
<cjwatson> Don't know
<smartboyhw> I asked in #ubuntu-mythtv-dev and nobody replied
<Daviey> smartboyhw: replied :)
<cjwatson> Riddell,smartboyhw: ^- respin
<cjwatson> Looks more sensible from a file listing
<smartboyhw> cjohnston, Ok
<Riddell> awooga, thanks cjwatson
 * smartboyhw really needs to set up his IRC client properly
<smartboyhw> cjwatson thx
<cjohnston> smartboyhw: 1 + 2 + 3 + tab
<cjohnston> We will call it the Laney meathod
<Laney> I got some t-shirts made
<smartboyhw> cjohnston, got it
<cjohnston> Laney: awesome
<ogra_> smartboyhw, what client do you use ?
<smartboyhw> ogra_, XChat
<ogra_> smartboyhw, so go to settings ... in the input field (or however it is called) settings there is a dropdown menu
<ogra_> switch it from A-Z to the other option
<smartboyhw> ogra_, OK
<ogra_> now your tab completion of "cj+tab" should completre to the last cj* who spoke in the channel automatically
<ogra_> *complete
 * cjohnston makes a note to never talk in a channel cjwatson is in again..
<cjohnston> crap.. I already failed
<smartboyhw> cjohnston, LOL:P
<smartboyhw> Sorry
<ogra_> cjohnston, well, indeed it only helps if not both of you babble in the same channel all the time :P
<ogra_> but often enough you are quiet while colin owns a channel conversation
<smartboyhw> ogra_, more LOL
<cjohnston> ogra_: very true, in most channels
<smartboyhw> cjwatson, actually all of Ubuntu Studio images are tested and OK (That small bug will have to wait till 12.04.3 as you marked) so we are now waiting for scott-work (again)
<cjwatson> smartboyhw: That's fine, thanks
<smartboyhw> cjwatson :)
<seb128> ogra_, there is also a mode where it doesn't autocomplete if there is a completion conflict, e.g my xchat-gnome lists the choices if I do cj<tab> but doesn't complete
<cjwatson> Ubuntu DVD testing is rather lacking, if anyone has time for that
<ogra_> seb128, hmm, cant see it in plain xchat
<smartboyhw> cjwatson, I would love to but no:P
 * cjwatson goes for power-nap before he falls over
<cjwatson> Aiming to release in two or three hours from now, I expect
<stgraber> cjwatson: yep, will do
<smartboyhw> cjwatson, that bug was completely fixed thank you
<smartboyhw> cjwatson, can we actually skip the Wubi testcases for Kubuntu? No testers AT ALL.....
<smartboyhw> Please forgive us...
<ScottK> smartboyhw: It's up to the product manager (Riddell) to decide if it's acceptable to skip a test or not.  No need to bug other people about it.
<smartboyhw> ScottK, sorry (I think he will ask for it anyway:P)
 * Riddell feels empowered
<smartboyhw> Riddell, you always are:P
<scott-work> good morning cjwatson, smartboyhw reports that the ubuntu studio 12.04.02 ISO have tested well and therefore i want to approve the issue
<stgraber> cjwatson: I'm going to do a selective copy of just amd64, i386 and armhf+* (looking at what we released for 12.04.1)
<Riddell> skaet, cjwatson: 12.04.2 kubuntu images are good to go
 * smartboyhw applauds loudly
<stgraber> Riddell: do you have a team on Launchpad I could delegate the kubuntu products to (that way you can mark them as ready yourself ;))?
<cjwatson> scott-work,Riddell: thanks
<cjwatson> scott-work: (marked)
<cjwatson> stgraber: thanks
<Riddell> stgraber: hmm lots, kubuntu-members, kubuntu-council, kubuntu-packagers.  what do others use?
<ScottK> stgraber: They are marked ready in the tracker.
<ScottK> (I have access to do this, so I assume Riddell does too)
<Riddell> I probably do
<ScottK> I went ahead an marked the Alpha 2 images as ready too.
<stgraber> right, you do because you both happen to be in ~ubuntu-release
<ScottK> So is Riddell.
<ScottK> That's also the set of people we want to be able to mark ready, so it's fine.
<stgraber> ok, if you ever want someone else to be able to do so, create a kubuntu-release team or similar on LP and let me know (currently only Edubuntu is setup that way with ~edubuntu-release)
<ScottK> OK.  I think we can wait until we need it to spend the time for all of us to get it set up.  Thanks.
<stgraber> sure
<cjwatson> Daviey,jamespage: OK, openvswitch and iscsitarget released
<cjwatson> Daviey: I don't remember - did you confirm or deny whether there's anything that should be added to the announcement as a high-profile server/cloud change for .2?
<cjwatson> It's OK if not but I wanted to explicitly check
<ScottK> cjwatson: Should I go ahead and drop my block on proposed migration (from Alpha 2)?  I'm about to disappear for several hours so it's ~now or in 7 hours.
<cjwatson> ScottK: Well, anyone in ~ubuntu-release can do it if you've said it's OK ...
<cjwatson> ScottK: I don't know the state of alpha 2, head full with 12.04.2
<ScottK> OK.
<ScottK> Kubuntu images are all done.
<ScottK> I don't know the state for cloud.
<ScottK> skaet_: In case I'm not around, feel free to drop my transition block when Alpha 2 is released.
<ScottK> cjwatson: Thanks.  That makes sense.  I hadn't thought it through.
<plars> cjwatson: is there a netboot release for 12.04.2? the urls pointed to in the iso tracker don't seem to be valid
<cjwatson> s/precise/precise-updates/
<cjwatson> It's not really a release as such - it's in the archive like it or not
<cjwatson> Would be nice if it were tested though
<bjf> infinity, i have a precise kernel that would like to go to -proposed
<plars> cjwatson: we're doing that now
<cjwatson> plars: Unfortunately I can't fix the download links because they just say /dists/SERIES/... which is substituted, and SERIES-updates wouldn't work for raring
<cjwatson> Can you cope with just manually substituting for the moment?
<plars> cjwatson: oh, certainly
<cjwatson> bjf: please wait until after .2
<cjwatson> Oh, -proposed, not -updates
<plars> cjwatson: just wanted tomake sure we're getting the right one
<cjwatson> Sorry, yeah, that's not a problem (not that I can deal with it right now)
<cjwatson> plars: Yeah, the version numbers are unique
<jamespage> cjwatson, thanks
<cjwatson> plars: The Ubuntu DVD is probably more urgent FWIW
<cjwatson> That's the only thing that will actually be meaningfully released that's mostly untested right no
<cjwatson> w
<plars> cjwatson: yes, we're looking at that too
<stgraber> cjwatson: actually, we can override per-series. Let me do that for precise.
<cjwatson> stgraber: Aha, thanks
<cjwatson> I got lost in the web UI
<cjwatson> It has the same problem as Launchpad that you need to understand the taxonomy before you can find your way around :)
<smartboyhw> GN
<stgraber> plars: links should have been fixed for those that had links (apparently a few products don't...)
<ogra_> cjwatson, do you happen to know what infinity was fiddling with the last days ?  the nexus7 images behave weird and it seems someone did a manual build on the 12th (which i assume was him)
<stgraber> (armel, armhf+armadaxp and armhf+highbank don't have any download links)
<ogra_> cjwatson, and funnily 20130212 as well as 20130213 dont work, but 20120212.1 (the apparent manual build) works fine
<ogra_> i know he was on something with the builders, but dont know what
<cjwatson> ogra_: I don't, sorry
<ogra_> thx
<cjwatson> stgraber: What's the difference between red and blue in test counts on http://iso.qa.ubuntu.com/qatracker/milestones/254/builds (e.g. look at netboot amd64 mandatory vs. i386)?
<smartboyhw> cjwatson that is orange not red
<smartboyhw> It means a test is in progress
<smartboyhw> Blue means no testcases are reported as passed, failed or in progress
<stgraber> cjwatson: blue is that nothing was done and nobody is working on it. Orange is for at least one of the testcases is being done by someone (in-progress)
<jdstrand> cjwatson: am I ok to push universe security updates to precise? (I saw the note earlier about other ones, so I will wait on openjdk-6 til you say so)
<infinity> bjf: 38.60?  Already copied it yesterday, and just didn't twiddle the bug yet.
<bjf> infinity, yup, that'd be the one
<infinity> bjf: I must have gotten distracted between the copy and the bug.  Workflow (and you) reminded me this morning. :)
<cjwatson> smartboyhw: Yeah, I guess
<cjwatson> Thanks
<henrix> infinity: while you're around... did you managed to get some time to verify the 2 bugs pending? :p
<cjwatson> jdstrand,mdeslaur: Go for it
<mdeslaur> cjwatson: thanks!
<jdstrand> cjwatson: ah, for everything?
<cjwatson> Yeah
<jdstrand> \o/
<jdstrand> cjwatson: thanks :)
<cjwatson> Anything showstoppily broken now is just not getting released
<infinity> henrix: Not yet, I'll try to corner a GSA to test today.
<henrix> infinity: sweet! thanks
<cjwatson> slangasek: Can I sign off on Ubuntu Core?
<cjohnston> Laney: since your not in the other channel, we need to branch out with 1 2 3 tab ;-)
<Laney> haha
<smartboyhw> cjwatson: we have one test left for Xubuntu 12.04.2: Desktop i386 live environment
<smartboyhw> And I can't find testers
<cjwatson> Has it been tested recently on previous spins?
<smartboyhw> Not sure
<cjwatson> stgraber: ^- is there any way to tell that?
<cjwatson> TBH I don't see a high probability of this being a problem given the other passes
<smartboyhw> yes
<cjwatson> slangasek: I've signed off Ubuntu Core on the forgiveness-rather-than-permission model :)
<slangasek> cjwatson: heh, +1
<cjwatson> Do you know if Jason is around to sign off desktop, or if somebody else should?
<cjwatson> Or I could just do it - it's looking good, we just need some DVD tests finished
<smartboyhw> cjwatson someone is doing the remaining Xubuntu test
<cjwatson> Great, thanks
<cjwatson> Daviey: How does server look for 12.04.2, in your opinion?
<cjwatson> utlemming: Are you able to sort out 12.04.2 cloud release soon?
<stgraber> cjwatson: checking the history, one sec
<stgraber> cjwatson: last passed in 20130210
<scott-work> stgraber: smartboyhw was saying that there might be a more "automated" way to mark releases by team instead of relying on IRC?
<ogra_> infinity, did you see my above question ?
<stgraber> cjwatson: http://iso.qa.ubuntu.com/qatracker/milestones/254/builds/37363/testcases
<scott-work> stgraber: if so, and especially if it makes it easier for you, i would love to assist setting this up
<cjwatson> stgraber: Thanks
<infinity> ogra_: I didn't change anything that should affect the images themselves, just where they were built (celbalrai instead of cadejo).
<cjwatson> stgraber: How do I navigate to that?
<infinity> ogra_: What's the expanded definition of "behaving weird"?
<stgraber> scott-work: yes, if you can give me a Launchpad team, I can grant it admin rights for your products, that way you can manage some of your testcases, mark images as rebuilding/ready, ...
<ogra_> infinity, X doesnt start
<stgraber> cjwatson: http://iso.qa.ubuntu.com/qatracker/milestones/254/history shows you the milestone history
<stgraber> cjwatson: there's sadly no magic way of checking by testcase yet though, so in this case I manually checked for the same product and looked for builds with results
<ogra_> infinity, the weird bit is that there were 0212 and 0212.1 images with 60sec mtime difference and while 12 was dead 21.1 worked fine .... and 13 is dead again
<ogra_> *12.1
<cjwatson> stgraber: Gotcha, thanks
<infinity> ogra_: And 14?
<ogra_> just untarring here
<ogra_> but 12.1 vs 12 is very weird
<ogra_> could it be that it got built on both builders that day ?
<infinity> ogra_: Two different hosts, and one may have actually been pulling a stale livefs?
<infinity> ogra_: It definitely built on both hosts one day, yes, when IS was fiddling with fixing celbalrai.
<ogra_> well, but then i would have expected 13 to be fine again
<infinity> ogra_: No, I mean 12.1 may have been a stale livefs, and 12-> could be broken because of, well, a bug in the software. :P
<ogra_> hmm, right
<ogra_> the .1 confused me
<ogra_> indeed it doesnt matter what has the newer name
<cjwatson> I'm going to sign off Ubuntu desktop and alternate - the one red bug there is one that I've discussed and know about, and that's in the release notes
<ogra_> sigh, no X on 0214 it seems :(
<ogra_> depressing
 * cjwatson hopes that going for coffee will shake out the remaining signoffs
<skaet_> utlemming, smoser - there are some alpha 2 cloud images not marked as tested,  anything ETA on when it will be done?   who's marking the images as ready for publishing,  smoser?
<infinity> If you still have all the images, unpack them, chroot in, and do a quick dpkg -l manifest and compare versions?
<smoser> utlemming, ^
<utlemming> skaet_: doing that now
<infinity> cjwatson: #-devel just reminded me, we had planned to continue offering old media for people who didn't want the HWE stack by default, right?
<infinity> cjwatson: Which is a departure from the usual 12.04 == 12.04.2 thing we do.
 * cjwatson signs off Mythbuntu on behalf of tgm4883
<cjwatson> infinity: https://wiki.ubuntu.com/Kernel/LTSEnablementStack says we'll offer them from old-releases
<infinity> cjwatson: Oh, fair enough.  I'm wondering if that should be publicised a tiny bit, or if we just assume the "I need the old media" usecase is small enough that people will find it themselves?
<cjwatson> I've just let Peter Mahnke know, rather belatedly, for the web team
<cjwatson> Since the plan is to link them from the website
<infinity> Check.
<cjwatson> skaet_,slangasek: When are you planning to kick out the alpha?  I'd like to freeze nusakan's sync-mirrors soon to prepare the 12.04.2 tree, and don't want to clash with you
<smartboyhw> cjwatson:  All xubuntu tests completed
<skaet_> cjwatson, Kubuntu's ready now.   just waiting for utlemming/smoser to weigh in.
<smartboyhw> Waiting knome
<skaet_> for alpha 2 images.
<cjwatson> smoser: Do you have any information on the remaining 12.04.2 server testing, and whether it should be signed off despite the handful of missing tests?  Daviey didn't answer me earlier
<utlemming> skaet_: eta 10 minutes
<skaet_> slangasek, ^   you able to start the publishing as soon as utlemming finishes?  (/me assuming no issues, its just book keeping now)
<cjwatson> Perhaps if .2 could go first - I'm a bit time-constrained due to web team interaction
<smoser> cjwatson, i'll dig on that.
<cjwatson> smartboyhw: I expect I will timeout and sign it off anyway in the next ten minutes or so - don't have a lot of time
<infinity> Doing .2 first was what we discussed on Monday, I thought?
<smartboyhw> uh oh
<cjwatson> Or rather, I'll probably just go ahead without signoff - testing is such that I'm not particularly worried at this point
<cjwatson> infinity: I wasn't there
<infinity> cjwatson: Oh, right.  You had the day off and skipped the call.  Smart man.
<cjwatson> In fact, I'm going to start publishing now, and just leave the unsignedoff images till last
<smartboyhw> cjwatson: ok
<infinity> cjwatson: Anyhow, we'd pretty much decided on .2 taking the lead, since if there was a screw-up/clash, accidentally half-publishing Alpha-2 with the 12.04.2 mirror pulse wouldn't be a big deal, but the inverse could suck.
<skaet_> infinity,  where was it documented.  Had been wondering....
<slangasek> skaet_, cjwatson: yes, I presume we should let .2 go first
<cjwatson> Starting publication now
<smartboyhw> :-D
<infinity> skaet_: Not sure that needed to be documented, per se, though clearly Colin needed to be told.
<skaet_> utlemming - can you mark your images as ready so cjwatson picks them up.  I'm not seeing them marked and the tools will need it.
<skaet_> infinity,  I would have liked to know as well.
<cjwatson> Heh, the tools are fungible, as it happens ;-)
<cjwatson> But I'd like the signoff anyway
<cjwatson> I use the tools as a guide, I don't necessarily let them rule me
<skaet_> cjwatson,  fair 'nuf.  :)
<infinity> skaet_: Sure, but the only two people who generally need to know who goes first down a ladder are the two people about to climb on.
<skaet_> infinity, aspect for me was that i gave guidance earlier to test 12.04.2 before 13.04 alpha 2 upgrades - if I'd known about this ordering decision,  I'd have provided different guidance.
<utlemming> skaet_: afaik, I don't have rights to mark something as ready.
<cjwatson> utlemming: Tell me and I can
<utlemming> cjwatson: they're ready
<cjwatson> skaet_: That sounds like correct guidance, with 12.04.2 releasing first ...
<skaet_> :)
<cjwatson> utlemming: Thanks
<cjwatson> utlemming: You ready to deal with releasing cloud images shortly too?
<utlemming> cjwatson: the pre-publishing is taking longer than usual. I started the job two hours ago, and its only about 60% done
<stgraber> utlemming: that can be arranged if you can give me a LP team to mark as owner for the cloud images
 * cjwatson races utlemming
<cjwatson> stgraber: this is for server I think
<cjwatson> we don't appear to have cloud on the tracker
<infinity> skaet_: Yeah, I'm confused as to why that would have been wrong.
<stgraber> cjwatson: ah, sorry got confused between server for 12.04.2 and cloud for alpha2...
<cjwatson> (no doubt the same applies to both, really)
<stgraber> utlemming: anyway, we can delegate stuff, so feel free to provide me with team names and product lists and I'll set it up for you (those teams should be fairly restricted for obvious reasons)
<utlemming> stgraber: sure, I'll get that over to you
<cjwatson> plars: Do you think we're mostly OK on the Ubuntu DVD now?
<cjwatson> plars: I'm inclined to go ahead ...
<plars> cjwatson: yes, we logged results on 64 and 32 bit, only thing I think is odd is that it goes to the text selector for install vs. live, but that's not new
<cjwatson> OK, can check that out at some later point I guess ...
<plars> cjwatson: things are looking good from our end, but continuing to test... only new thing we're seeing is that the language selector seems to come up still for netboot installs of desktop, but nothing serious
<cjwatson> plars: I think that's known - that's the other half of the bug I duped your earlier bug against, and I targeted it to 12.04.3
<plars> cjwatson: ack
<cjwatson> plars: bug 1056689, the pkgsel half
<ubot2> Launchpad bug 1056689 in pkgsel (Ubuntu Precise) ""Incomplete language support" for english after netboot installation" [Medium,Triaged] https://launchpad.net/bugs/1056689
<skaet_> utlemming, cjwatson - have gone and marked the 13.04 alpha 2 cloud images as ready.
<cjwatson> ah, wondered what that was
<cjwatson> knome,smartboyhw: I'm timing out now and marking Xubuntu as ready, since I really need to get on with the tail-end of this and the testing looks fine.  Thanks!
<smartboyhw> cjwatson:ok. Hope knome doesn't kill me or you for that
<ogra_> GRRR !!!!!!!!
<ogra_> so how come there is a /tmp/,X0-lock file in my tarballs !
<cjwatson> Dealing with old-releases at the moment
<infinity> henrix: So, we'll get to those SRU verifications tomorrow.  Looks like someone busted the serial console server's setup, which makes it sort of hard to test if the serial console works.
<henrix> infinity: ok, thanks. i'll remind you again tomorrow about it :)
<cjwatson> bdmurray: Could you please update changelogs.u.c/meta-release* to say 12.04.2?
<plars> cjwatson: jamespage and I have been discussing minimal virtual server installs oversized due to pulling in 150M of modules - see bug #1125408
<ubot2> Launchpad bug 1125408 in ubuntu-meta (Ubuntu Precise) "12.04.2 minimal virtual install is oversized" [Undecided,New] https://launchpad.net/bugs/1125408
<cjwatson> Mm, it's too late now whatever it is ...
<cjwatson> I've already done the publishing, waiting for mirrors
<plars> otherwise server has been ok so far
<cjwatson> But that's a matter of going over our own definition of limits, not anything external
<cjwatson> So I don't think it'd be a blocker anyway ...
<jamespage> cjwatson, well I agree its a limits failure; and not a blocker
<jamespage> but we are doing something different for 12.04.2
<jamespage> in that we no longer offer a 'minimal virtual' install of the kernel
<cjwatson> OK; but it is now too late to fix for .2 I'm afraid
<cjwatson> If it's a serious concern you can certainly add a release note and we can try to figure out what's going on for .3
<plars> jamespage, cjwatson: as near as we can tell, it's due to the move to 3.5 kernel and there's no linux-virtual for it
<cjwatson> Ah, heh
<cjwatson> -> kernel team :)
<plars> I'm do recall some discussion from the past about the fact that linux-virtual was not going to exist for 3.5, but I don't know the motivation behind it
<skaet_> cjwatson, slangasek - could you please flag it to Riddell, utlemming when they can send out the announce for the 13.04 alpha 2 images?
<bdmurray> cjwatson: done
<cjwatson> As far as I'm concerned slangasek can go ahead with publishing, but I wouldn't recommend running sync-mirrors yet because cdimage.u.c is still syncing 12.04.2
<cjwatson> And I don't mind when the announcement happens
 * cjwatson stops auto-syncs for Debian import freeze
<skaet_> thanks cjwatson.
<skaet_> slangasek,  could you please let Riddell know an ETA so he can check that the bits are in place before his announce goes out?
<cjwatson> Announcement queued up in my mailer; if anyone edits it in the wiki now, best to let me know
<cjwatson> I think I've run out of things to do other than waiting for mirrors to sync
<ogra_> *you* have run out of things to do ?!?
<stgraber> cjwatson: tried bittorrent yet? :)
<cjwatson> ogra_: for today ...
<ogra_> heh
<cjwatson> stgraber: Doesn't usually tend to work for me due to NAT madness, and I think magellanic is still syncing anyway
<cjwatson> Checking that is certainly on my list for when it gets a bit further along
<stgraber> cjwatson: ok. Yeah, the sync takes ages, the checksumming takes even longer and after that it usually needs a kick to actually start seeding
<zequence> stgraber: Hi. We discussed the possibility of using a Ubuntu Studio LP team for accepting a release ready for publishing. So, we agreed that ~ubuntustudio-core would be a good team for that.
<cjwatson> stgraber: Indeed
<stgraber> zequence: ok
<infinity> cjwatson: Still no new magellanic?  Sadness.
<cjwatson> infinity: Yeah, we're still running off my old ZX Spectrum
<cjwatson> Maybe if I buy magellanic a new keyboard membrane it will be happier
<infinity> cjwatson: I'm sure it's at least an Amiga A2000
<Riddell> here's an e-mail for alpha 2 http://pad.ubuntu.com/alpha-2
<Riddell> can I just send that to the ubuntu-devel-announce list now and it'll be approved at an appropriate time?
<cjwatson> s/Alpha-1/Alpha 2/
<cjwatson> and downcase "The" a bit before that
<cjwatson> Actually I'll just copy-edit in the pad, one moment
<cjwatson> OK, done.  But yeah, if that's easiest for you then go ahead.  slangasek has the moderator password so can deal with accepting it
<Riddell> ok in the queue for slangasek to approve at a good time
<Riddell> I'm out, text me if I'm needed, jriddell.org/contact.html
 * skaet_ heading out as well for a bit.    online again later.
<cjwatson> torrent.u.c rsync up to Ubuntu desktop
<utlemming> cjwatson, skaet_: cloud images are ready for final promotion
<ogra_> infinity, so if one of the images had a stale filesystem it must have been one of the two sitting on cadejo, right (likely the last one)
 * ogra_ tries to find out what was the last good image, i seem to get nowhere tring to debug the current one 
<infinity> ogra_: Seems likely that 12.1 was from cadejo, yeah, and the others were from celbalrai
<ogra_> ok
<ogra_> that should at least give me something to compare
<slangasek> utlemming: "final promotion" - are you handling that part, or is there anything you need me to do for the a2 publishing of them?
<slangasek> working on publishing kubuntu alpha2 now
<infinity> -gnome-settings-daemon  3.6.4-0ubuntu3
<infinity> +gnome-settings-daemon  3.6.4-0ubuntu5
<infinity> ogra_: At least that could be suspect.
<ogra_> yeah, well, i get it to work at times and dont know why yet
<infinity> ogra_: gvfs and gnome-keyring too.
<ogra_> we also fiddled with the unpacking of the tarball
<infinity> ogra_: That was long ago, you claimed it only just broke.
<ogra_> no, i had to revert it
<infinity> You did?
<ogra_> on tuesday
<ogra_> ah, no, wrong package
<ogra_> on friday
<ogra_> so that cant be it if the image from the 11th worked
<infinity> ogra_: Why did we roll back those bits?
<stgraber> zequence: done. You'll need to logout for it to take effect
<ogra_> tar did exit nonzero, remember we talked about introducing something like fixrtc later to fix it once and for all
<ogra_> i didnt get to that yet, but the rollback shouldnt do any harm (and the 0211 image seemingly works)
<infinity> Fair enough.
<utlemming> slangasek: I just need the okay to pull the trigger.
<utlemming> slangasek: by final promotion, it just means making the images public, and I do handle that bit
<stgraber> utlemming: done for cloud images too
<stgraber> (setting the ACLs that's)
<slangasek> utlemming: I think you're good to publish
 * utlemming makes cloud images public
<zequence> stgraber: Ok, so we'll get automatically assigned to a bug, when a new release is to be accepted (just being thorough)?
<stgraber> zequence: nope, what that gives you is simply more rights on iso.qa.ubuntu.com. Members of that team can now mark images as Ready (instead of asking a release manager to do so), you can also edit the results for your products and change the testsuites.
<zequence> stgraber: Ah, ok. That clears it up. Thanks
<utlemming> Okay, cloud images are published and public
<cjwatson> Can anyone check whether 12.04.2 torrents are working, please?
<slangasek> cjwatson: do you know what the size limit is on cdimage.u.c nowadays?
<cjwatson> website looks up to date
<cjwatson> slangasek: individual images or the whole thing?
<slangasek> the whole thing
<slangasek> http://cdimage.ubuntu.com/kubuntu/releases/raring/alpha-2/ doesn't seem to be updating with content
<cjwatson> 400+ G
<slangasek> well
<slangasek> we're at 459G used
<cjwatson> according to lamont a bit earlier
<cjwatson> no, I mean 400+ GB free now
<slangasek> oh, ok
<cjwatson> we don't have a space problem right now :)
<slangasek> ah, and indeed the files are trickling in now
<slangasek> very slow sync though, wonder what's up with that
<slangasek> torrents seem to check out (spot check only)
<cjwatson> promising
<antarus> is it time for booze yet?
 * cjwatson hits send
* cjwatson changed the topic of #ubuntu-release to: Ubuntu 12.10 and 12.04.2 released | Archive: Open | Raring Ringtail 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
 * ogra_ gives up trying to fix the nx7 images today ... cant really find the cause for teh breakage :(
<davmor2> ogra_: have you tried looking down the back of the sofa, I find that's where most things you can't find seem to wind up ;)
<slangasek> ok, kubuntu a2 images published; moderating the announcement
<ogra_> well, there is a wall but yeah, i should look between the pillows
<ogra_> :)
<ogra_> i'll find the issue tomorrow, i'm sure, its just that after hours of hacking on a portrait mode nx7 inside an initrd with a really bad tiny kbd i feel exhausted ...
<ogra_> and i'm through all the usual suspects now
<davmor2> ogra_: I empathise have you not got the Nexus 7 keyboard dock/case ?   I suspect if it was working with Ubuntu it might make your life a hell of a lot easier
<ogra_> i have a nice little keyboard for it ... which is fine for travelling and even occasional IRC ... but really painful if you need non std chars that are in non std places due to the reduced siye
<ogra_> *size
<ogra_> i.e. / right of backspace and such fun
<davmor2> ogra_: ah yeah muscle memory can bite you sometimes
<ogra_> well, not only that ... bad labeling (dark grey on black) too :)
<ogra_> and indeed, the keys are really tiny
<ogra_> (so are the labels)
<GridCube> p
<slangasek> ogra_: I have my n7 wired to my kvm ;P
<ogra_> heh
<slangasek> ScottK: can you clear your britney block?
<jdstrand> cjwatson: hey, did you turn copy-report back on?
<cjwatson> jdstrand: oh no, sorry.  done now
<knome> cjwatson, that's fine. thanks!
<jdstrand> cjwatson: thanks! :)
<jdstrand> wanted to make sure those qt4 and openjdks got mirrored
<ScottK> slangasek: Done.
<slangasek> ScottK: ta
#ubuntu-release 2013-02-15
<phillw> cjwatson: or anyone from Ubuntu Developers, any idea how I go about getting the 4.2 into raring? the link on https://launchpad.net/ubuntu/+source/virtualbox/4.1.22-dfsg-0ubuntu2 does not exist.
<didrocks> infinity: we have a tentative fix for the hanging (using the same groupid for all things that are launched by dbus-test-runner) so that nothing stall once killed. Just published to the distro (in 3 minutes)
<didrocks> infinity: keep us posted if you see more hanging
<davmor2> Hey guys quick question about the final release will we be promoting the 64bit version over the 32bit version this time?  Being as it contains the secure boot stuff.
<xnox> davmor2: we are releasing both images and both are in the same location.
<xnox> davmor2: w.r.t. which one should be the default download button on the www.ubuntu.com website, this can be discussed on ubuntu-devel mailing list.
<xnox> (there was a big thread around 12.04 release and there was one recent one)
<xnox> davmor2: uefi/secureboot is not the default across many machines, and practically all of them either use bios by default or can toggle to use bios.
<davmor2> xnox: okay I was just wondering I can see people grabbing the recommended version and then not being able to install it due to secureboot was all :)
<xnox> we are pushing warnings to the website indicating that UEFI/SecureBoot machines should choose 64-bit edition
<davmor2> xnox: ah right that is pretty cool then
<cjwatson> they're already there
<cjwatson> as of yesterday
<infinity> didrocks: Danke.
<ev> I don't suppose anyone has the power to unblock me from #ubuntu-devel
<xnox> !ircops ^
<ubot2> Factoid 'ircops ^' not found
<xnox> !ircops
<ubot2> Factoid 'ircops' not found
 * xnox can't remember the right command
<xnox> ev: ping folks on #ubuntu-irc channel
<xnox> they have magic powers
<cjwatson> I should have
<ev> but they're unclean
<cjwatson> Let me just try to remember how
<ev> cheers
<ev> is this going to be a bedknobs and broomsticks moment?
<cjwatson> ?
<ev> oh, I had assumed this was a staple of the standard british upbringing
<ev> trying to remember the correct spell
<ev> I guess it was a poor joke at best :)
<cjwatson> ev: try now?
<cjwatson> ev: I'm not actually sure you weren't already unbanned
<davmor2> ev: I'm not sure it was a good metaphor without a scene notation, you americans so much to learn still :)
<ev> :)
<davmor2> ev: I'd forgiven you if you had gone for, cjwatson so unblocking me will be like Mary Poppins Carpet Bag, all magic and unexplainable ;)
<xnox> davmor2: why like yoda, you speak? (RE: you americans so much to learn still)
<davmor2> xnox: Yoda is the master the Americans are the pupils, much to learn they have still hmmmmmmm :)
<phillw> hi good people, is there a ubiquity person about to have a quick look at an 'odd' bug, there is crash report but getting it to reproduce reliably is a problem
<slangasek> phillw: I can maybe have a look
<slangasek> phillw: what's the bug #?
<phillw> slangasek: we're trying to get it able to be reproducable, but there is a crash report. http://paste.ubuntu.com/1659776/ Nicholas is trying it on real machine, as it is only seen intermitantly on VM's.
<slangasek> phillw: where is the crash report?
<phillw> slangasek: on that link?
<slangasek> rather: why is this crash report in a pastebin, rather than submitted to errors.ubuntu.com / launchpad?
<phillw> slangasek: we're still trying to get a reproducable crash, as a bug that happens something like 1 in 10, is going to be really hard on the devs.
<slangasek> phillw: having this in a pastebin instead of in launchpad is worse
<slangasek> step 1) submit the crash report, step 2) figure out how to reproduce it :)
<phillw> okies.
<phillw> slangasek: bug 1126671
<phillw> slangasek: turns out it is dupe of https://launchpad.net/bugs/1123798
<ubot2> Ubuntu bug 1123798 in ubiquity (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed]
<phillw> not sure why I didn't get that one as it lubuntu named.
<slangasek> phillw: yep - one of the advantages of getting the crash report filed is that the dupe checker gets a crack at it ;)
<phillw> slangasek: thanks boss :)
<slangasek> phillw: so AIUI the problem is that lubuntu doesn't ship consolekit, and something is causing ubiquity-dm to now require it
<slangasek> the simplest solution, on the lubuntu side, would seem to be including consolekit
<slangasek> (I'm surprised it's not already there, TBH)
<phillw> slangasek: read the bug.... https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1123798/comments/5
<ubot2> Ubuntu bug 1123798 in ubiquity (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed]
<phillw> Noskaj will be along later, He's on AUS time.
<slangasek> phillw: well, I discounted that comment because it's a low-content followup and nobody reported this bug against Ubuntu; I can kick off a test here though
<phillw> slangasek: balloons is trying on real kit, but is waiting for the iso to copy over.
 * slangasek nods
<phillw> slangasek: if you would /j #ubuntu-quality that is where the discussion is. I do think that is the better channel to discuss on?
#ubuntu-release 2013-02-16
<xnox> slangasek: ubiquity-dm opens a ConsoleKit session for a while now due to bug 631538
<ubot2> Launchpad bug 631538 in ubiquity (Ubuntu) "[10.10 beta] Impossible to shutdown/restart/.. from the Welcome screen" [High,Fix released] https://launchpad.net/bugs/631538
<xnox> so something must have caused it to fall-off lubuntu seed.
<xnox> maybe ubiquity should depend on consolekit then?!
<slangasek> xnox: ck is present in the lubuntu image
<xnox> oh =(
<slangasek> but it seems not quite functional
<slangasek> there's a process with a lower pid running; then something tries to spawn a new one over dbus; this second attempt fails
<xnox> that statement is true regardless ;-0
<xnox> slangasek: is there a ps tree anywhere to look at?
<slangasek> xnox: not presently :)
<slangasek> xnox: the problem was 100% reproducible for me with the lubuntu daily fwiw
 * xnox downloads
<xnox> to be honest I don't like how ubiquity-dm is not a proper Xsession but an upstart job which pre-empts the login manager
<xnox> infinity: ^ should resolve bug 1097329
<ubot2> Launchpad bug 1097329 in ecere-sdk (Ubuntu Raring) "ecere-sdk: binary package conflict with eclib" [High,In progress] https://launchpad.net/bugs/1097329
<jamespage> ^^ high urgency fix to resolve regression with openvswitch dkms brcompat module
<jamespage> bug 1125611
<ubot2> Launchpad bug 1125611 in openvswitch (Ubuntu Quantal) "DKMS brcompat module circular dependency causes broken module" [Critical,In progress] https://launchpad.net/bugs/1125611
<jamespage> ^^ ditto for quantal (plus fix for bug 1088160)
<ubot2> Launchpad bug 1088160 in openvswitch (Ubuntu Quantal) "module-assistant install of openvswitch-datapath fails on quantal due to drop of _mod postfix" [Medium,Triaged] https://launchpad.net/bugs/1088160
<jamespage> cjwatson, Daviey: fix for regression introduced by the 3.5 kernel support changed for openvswitch in precise ^^
<infinity> xnox: Thanks for making that happen.
<xnox> infinity: no problem ;-) just cleaning up after myself really.
 * xnox ponders zsync i386 90.4% complete, yet amd64 is no local matching data found
 * xnox always syncs together.
<xnox> hehe permissions problem.
 * xnox <--- ignore him
<phillw> xnox: I get that with kvm, it does like to take ownership of the iso's. most annoying!
<xnox> phillw: yeah.
#ubuntu-release 2013-02-17
<lamont>  /37
#ubuntu-release 2014-02-10
<Riddell> cjwatson: I'm going to remove you block on massif-visualizer because I just removed it from trusty
<cjwatson> ok, thanks
<arges> Hi. Can an AA remove this package from proposed? bug 1186273, Precise: network-manager/0.9.4.0-0ubuntu4.4, Quantal: network-manager/0.9.6.0-0ubuntu7.1 . This will never be verified and its blocking other SRUs. Thanks
<ubot2> Launchpad bug 1186273 in network-manager (Ubuntu Quantal) "DUN via bluetooth with a password fails" [High,Fix committed] https://launchpad.net/bugs/1186273
<infinity> arges: How is it blocking other SRUs?
<arges> infinity: at least it was at some point. maybe those are unblocked now
<infinity> arges: (Happy to remove it anyway, but if the intent is to upload a new SRU, the current one isn't blocking that)
<arges> infinity: Yup, looks like those other ones went away. Regardless this will never be verified and could block future updates.
<infinity> arges: The blocking part is the part I'm arguing with. :)
<infinity> arges: If a new SRU needs to be done urgently, that's the best time to discuss tossing the changes.
<infinity> Bit annoyed that it got verified on raring but not precise, though.  Oh well.
<arges> infinity: ok. well any way to mark that bug in such a way that when a new SRU comes down the pipe it doesn't block things?
<infinity> arges: Not really, no.  But if you're positive no one's likely to pop up to verify it, I can delete it.  It's trivial, actually, to copy it right back in, binaries and all, if that situation changes before the version is superseded.
<arges> infinity: this was the other SRU bug 1254028 , but looks like it was resolved alrady
<ubot2> Launchpad bug 1254028 in network-manager (Ubuntu Precise) "[precise] network manager set incorrect /64 prefix from dhcpv6 client" [Undecided,Confirmed] https://launchpad.net/bugs/1254028
<infinity> arges: Not in precise, it wasn't.
<arges> https://bugs.launchpad.net/debian/+source/network-manager/+bug/1254028/comments/12 looks like mdeslaur marked it fixed released
<ubot2> Launchpad bug 1254028 in network-manager (Ubuntu Precise) "[precise] network manager set incorrect /64 prefix from dhcpv6 client" [Undecided,Confirmed]
<infinity> arges: Read more closely...
<infinity> arges: It's confirmed in precise, and pending the resolution of this other SRU.
<arges> confirmed
<infinity> So, yeah.  I'll remove this one to kill the ambiguity about its status.
<arges> infinity: thanks.
<infinity> arges: Done and done.
<arges> infinity: cool sorry about the disorganization with the request.
<highvoltage> dh: unable to load addon python2: Can't locate Debian/Debhelper/Sequence/python2.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python2 module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at (eval 13) line 2.
<highvoltage> (sorry wrong channel)
<knome> highvoltage, boo!
<highvoltage> knome: but I'll be happy to discuss any other topic with you if the channel has become lonely
 * knome huggles highvoltage :)
#ubuntu-release 2014-02-11
<Laney> did the ac100 kernel completely go away?
<Laney> IOW is the lubuntu-ac100 image dead?
<ogra_> it shouldnt be
<ogra_> did anyone talk to the ac100 people before killing it ?
<ogra_> (there is #ac100)
<Laney> ogra_: deletion message says "Unmaintained in trusty"
<ogra_> sigh
<ogra_> who deleted it without talking to anyone
<Laney> well, infinity did the deletion but I don't know what the discussions were
<Laney> apw: ^?
<ogra_> he could have mailed the ML (and he is even a resident in #ac100 so he could have asked there)
<ogra_> the kernel didnt change and doesnt need any changes
<ogra_> (since the HW doesnt change either sand mainline is still not ready)
<xnox> ogra_: Laney: can it not simply use "linux-generic" flavour?
<ogra_> xnox, not yet
<ogra_> xnox, with 3.15 or so it should be ready, but then flash-kernel needs changes too
<ogra_> for trusty it still needs to use the BSP kernel
<apw> Laney, not anything to do with me that i know of?  though i kernel which has no security, ugg
<Laney> I'm sure it isn't, just thought you might know
<ogra_> Laney, i know ppisati worked a bit with ac100 stuff in the past (not sure he still does)
<xnox> ogra_: apw: also hallyn was interested in updating ac100 kernel at one point.
<ogra_> xnox, well, the kernel itself might not be the prob as long as xfbdev can still run on it ...
<ogra_> xnox, but i think the mainline kernel doesnt work with the fastboot bootloader and flash-kernel kind of expects a -ac100 kernel ... the first one needs to be tested, the second one will need code changes/fixes
<apw> Laney, no i didn't hear anything specific on it sorry
<infinity> Laney, ogra_: No, indeed, I didn't consult with anyone on the topic.  It showed up in an archive report or other because of its sketchy packaging and weird intereaction with germinate, I realised that *no one* has uploaded it for anything except an FTBFS, and was pretty unhappy about shipping an ancient kernel with a ton of known security flaws.
<infinity> ogra_: flash-kernel changes are trivial.  Do we know if -generic *runs* on ac100 (I don't have one anymore).  If it does, that's the right way forward.
<ogra_> infinity, well, i'm pretty unhappy that we let down the ac100 community
<infinity> We let them down how?
<ogra_> -generic doesnt run with the bootloader
<infinity> I didn't uninstall the kernel from their computers.
<cjwatson> We must have been letting them down by not shipping security fixes to them
<ogra_> nio, but we dont give them any images anymore
<cjwatson> Removing the kernel is hardly the worst of our failings
<infinity> ogra_: No one's making new hardware, why do they need to reinstall every two days?
<ogra_> cjwatson, the preinstalled android 2.2 doesnt get any either on the ac100
<cjwatson> I don't think that's much of a justification, frankly
<ogra_> and it didnt bother anyone for the last few releases
<ogra_> why is it suddenly a problam
<ogra_> *problem
<cjwatson> So we just ship it forever?
<cjwatson> It has to become a problem at some point
<infinity> It's bothered me for a long while.  When it was first uploaded, I asked if anyone was going to maintain it, and was told "yes".
<infinity> This was obviously a lie.
<cjwatson> Mid-cycle isn't a terrible time
<ogra_> until we can provide -generic i was hoping
<infinity> And I didn't feel like shipping it in another LTS.
<ogra_> and that wont happen before 3.15
<ogra_> there are people working hard to make this happen
<infinity> ogra_: Why the magic 3.15 number?  If we know what patches are needed and they've just missed a merge window, maybe we can fix generic.
<ogra_> and i'm sure nobody will sit down and re-introduce the ac100 images in 14.10
<stgraber> this seems to suggest ac100 may run on 3.13 with the right cherry-picks: http://comments.gmane.org/gmane.linux.redhat.fedora.kernel/4750
<ogra_> infinity, well, you are in #ac100, marvin24 is the guy making the port ready upstream ... together with srwarren from nvidia
<infinity> Look, it took forever to find anyone to test ac100 images for the last release.  So much so that it caused some sort of drama when I accidentally released them and the Lubuntu people flipped out because they weren't tested.
<infinity> Building images we don't test on a kernel we don't support isn't doing anyone favours.
<ogra_> infinity, the point is that the installation of the image must be adjusted to flash u-boot over the old bootloader
<ogra_> infinity, there has a tester team formed for 14.04
<ogra_> and they actually did tests for A1 (i dont think anyone mailed the ac100 ML to ask for A2 tests, i'm sure they would have done it)
#ubuntu-release 2014-02-12
<doko> cjwatson, infinity, jibel: the autopkg tests for gcc-4.8 are still marked running: python-apt and pyqt5, but seem to have finished according the jenkins page
<jibel> doko, looking
<jamespag`> hello; I have a openvswitch-lts-saucy NEW upload which resolved bug 1262225
<ubot2`> Launchpad bug 1262225 in openvswitch (Ubuntu Precise) "openvswitch 1.4.6 is not compatible with the 3.11 saucy HWE kernel" [High,Triaged] https://launchpad.net/bugs/1262225
<jamespag`> could a member of the SRU team take a look? this is the same approach that we took for the raring kernel for precise
<rtg> infinity, could you NEW the linux 3.13.0-8.28 binaries please ?
<rtg> or maybe just approve them since the ABI didn't change
<infinity> rtg: Yeah, just needed to approve the amd64 EFI bits so linux-signed can build.  Sorted now.
<rtg> thanks
#ubuntu-release 2014-02-13
 * kaxing hello, I've noticed 12.04.3 image is not yet on http://old-releases.ubuntu.com/ 
<cjwatson> kaxing: It's possible I forgot to push that change, let me try
<cjwatson> (Even if this works it'll take ages though)
<kaxing> cjwatson, thanks!
<doko> please could somebody accept gccgo-4.9?
<med_> stokachu, thanks for http://astokes.org/customizing-fastpath-curtin-installations/
<stokachu> med_: np man :D
<rbasak> https://launchpad.net/ubuntu/+source/nginx/1.4.1-3ubuntu1.2/+build/5587112
<rbasak> "INFO Rejection during accept. Aborting partial accept."
<rbasak> Do I just need to hit the rebuild button for that?
 * rbasak hasn't seen that before
<infinity> rbasak: Yeah, that's LP pooping itself slightly, just retry.
#ubuntu-release 2014-02-14
<infinity> wgrant: Do we know what causes the above, BTW?  It is just some touchy hard-to-hunt-and-fix race, or scary corruption somewhere, or...?
<infinity> (I've always been inclined to not care deeply, sinc the workaround is easy and not a big deal unless it was a 24h GCC build, but... Sometimes it's a 24h GCC build)
<wgrant> infinity: That wasn't the actual error
<wgrant> The error was "Server said:"
<wgrant> It's some librarian network glitch, I believe.
<infinity> Server said: nothing?  Whee.
<wgrant> Right
<wgrant>   File "/srv/launchpad.net/codelines/soyuz-production-rev-16916/lib/lp/services/librarian/client.py", line 104, in _checkError
<wgrant>     raise UploadFailed('Server said: ' + response)
<wgrant> UploadFailed: Server said:
<wgrant> It should probably retry in that case, but it's a bit complicated.
<infinity> wgrant: Like I said, not a big deal, just a curiosity.
<infinity> (We still see the odd hash mismatch too, which is disconcerting, since we no longer have bitflip-prone hardware..)
<wgrant> Do we?
<wgrant> I haven't seen any of those recently :/
<infinity> Yeah, I see a failed hash upload once a month or so, maybe.
<infinity> Arch random.
<infinity> We're not abusing the same python-doesn't-do-http-post-properly misfeature of the chroot uploads, are we? :)
<wgrant> Fortunately not.
<infinity> Nah, can't be that, or it would die a lot more often.
<wgrant> Python sucking at MIME is unrelated to XML-RPC.
<infinity> And more reproducibly on builds of a certain size.
<infinity> wgrant: I forget, did we actually hack around that for the chroot case?
<wgrant> infinity: You don't want to know.
<infinity> I'm pretty sure I once knew.
<infinity> And forgot.
<wgrant> Keep it that way.
<infinity> Hahaha.
<infinity> Kay.
<infinity> Was it uglier than my "why not have the client null-terminate, and the server strip?" suggestion?"
<infinity> s/"$//
<wgrant> You asked for it: https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/distroarchseries.py#L172
<infinity> HAHAHAHAHAHA.
<infinity> So, yes, it's worse that my suggestion, from a performance POV.
<infinity> But, transparent.  So yay.
<wgrant> Right, the main point is that it's transparent to the client.
<wgrant> It works around the broken data from the client, while allowing a proper client fix later.
<wgrant> Without breaking protocol.
<infinity> I don't think you get to make fun of cprov's code for a week.
<infinity> Also, it would be infinitely better without the comment.
<infinity> "doesn't match?  add random shit and try again."
<wgrant> Heh
<darkxst> anyone able to bump mozjs24 through the new queue? so I can get the other bits (gjs/gnome-shell etc) uploaded over the weekend
<jamespage> please could a member of the SRU team review the openvswitch-lts-saucy source package I uploaded a while back to fix bug 1262225
<ubot2`> Launchpad bug 1262225 in openvswitch (Ubuntu Precise) "openvswitch 1.4.6 is not compatible with the 3.11 saucy HWE kernel" [High,Triaged] https://launchpad.net/bugs/1262225
<jamespage> its the same approach we took with the lts-raring kernel
<bdmurray> What are the release task wiki pages?  For new releases and making a release EoL.
<bdmurray> ah, I think I found it
<rsalveti> stgraber: we now have an i386 tarball published from cdimage, what needs to happen to get that tarball published via the system-image server?
<rsalveti> ogra_: ^
<ogra_> rsalveti, we only have the tarball
<rsalveti> ogra_: isn't that enough?
<rsalveti> or do we need a device tarball as well?
<ogra_> rsalveti, i assume you want the android package too
<rsalveti>  /tarball/images/
<rsalveti> right, for now just a tarball is fine
<rsalveti> as that's what is used by the ubuntu-emulator script
<ogra_> currently x86 skips in in live-build
<ogra_> rsalveti, it doesnt use any android bits ?
 * ogra_ assumed you want boot/system at least
<ogra_> rsalveti, i also havent enabled it by default yet ... will do so after didrocks' image has build
<rsalveti> ogra_: hm, true, the current one is extracting the kernel from the boot image
<rsalveti> but the previous one wasn't
<rsalveti> but having the system image for the rootfs tarball would already help me a lot
<ogra_> rsalveti, if you only use the tarball and no android system.img for the container i think that would need changes on the system-image,u.c side
<rsalveti> ogra_: well, the tarball is always generic, right?
<ogra_> (though if you only need the tarball i would just pull it directly=
<rsalveti> the android image I produce it myself
<rsalveti> ogra_: it's just that the logic we have pulls it from system-image
<ogra_> rsalveti, on cdimage it is generic ... system-image stuffs the system.img in place
<rsalveti> and we also use the system-image format when booting the emulator
<rsalveti> ogra_: thought that this was happening during flash
<rsalveti> ogra_: the rootfs tarball in system-image is still generic
<ogra_> rsalveti, well, it dumps links and dirs in place
<rsalveti> that's why we have the device tarball and the rootfs tarball there as well
<rsalveti> ogra_: but that's generic enough
<ogra_> right
<ogra_> rsalveti, http://paste.ubuntu.com/6931793/ (from rootstock)
<ogra_> rsalveti, thats the bit that system-image does in generatos.py
<ogra_> *generators
<ogra_> (which rootstock does during install)
<rsalveti> ogra_: right, and that's what I'm using locally :-)
<rsalveti> ogra_: that's why I said they are generic enough for the emulator, because I'm already using it :-)
<ogra_> well, i was wondering if we shouldnt just have the emulator wrapper script do that
<ogra_> it is trivial enough
<rsalveti> ogra_: why if we can just download the system-image rootfs?
<rsalveti> and that rootfs will be there anyway
<rsalveti> with proper id and such
<stgraber> I'd expect i386 emulator to be similar to the armhf emulator and we sure have a device tarball for that one
<rsalveti> stgraber: yeah, that will happen soon
<rsalveti> stgraber: it's just that we got the rootfs tarball already
<stgraber> system-image can be configured not to ship with a device tarball but only in a separate channel
<stgraber> and I don't think we want to create a separate channel just for the i386 emulator :)
<rsalveti> stgraber: but can't we just publish the rootfs tarball?
<rsalveti> or do you need a device image there as well?
<rsalveti> yeah, we don't want a separated channel, no
<stgraber> system-image won't publish an image if it's lacking any of the configured tarball for the channel, so no, for our existing channels, it's not possible to publish an image without a device tarball
<ogra_> you could surely do that if you clone stgraber
<ogra_> so he has time to chaneg the code :)
<rsalveti> right, will just push harder to get the device image in place
<rsalveti> :-)
<ogra_> rsalveti, i guess that needs some magic in the adnroid package then ... and we need to enable the android part in live-build
<ogra_> (since system-image pulls from cdimage and expects the device files there)
<rsalveti> ogra_: yeah
<rsalveti> but I got a bunch of things to do first anyway
<rsalveti> like qt packaging, mir and so on
<darkxst> anyone able to bump mozjs24 through the new queue? so I can get the other bits (gjs/gnome-shell etc) uploaded over the weekend
<lamont> anyone know anything about gccgo-4.9 being mode 0?
<seb128> lamont, see #is scrollback some 9 hours ago if you have it
<lamont> ta
<seb128> lamont, doko uploaded a version that nuked libgcc1 content and made apt, chroots and other things unhappy
<seb128> lamont, the binaries got chmoded to avoid users getting it
<lamont> right
 * lamont had just concluded that
#ubuntu-release 2014-02-15
<cjwatson> lamont: it should be happier now, fixed version superseded it some time back
<lamont> cjwatson: cool
<darkxst> infinity, any chance you could take a look at mozjs24 in NEW?
<infinity> darkxst: Is this going to Debian as well?
<darkxst> infinity, I imagine it will eventually, however not sure if they will use if for GNOME 3.10
<darkxst> mozjs17 only just landed in debian a month or two ago
<infinity> darkxst: I guess I was hoping the answer was "yes, a DD is involved in the packaging and it's being uploaded to Debian too", but oh well. :P
 * infinity gives it a quick review.
<darkxst> oh in that case no, however its a fairly simple update as far as packaging goes
<infinity> darkxst: Looks good.
<infinity> darkxst: But please do work with Debian to get it uploaded before we discover we disagree about SOVER hacks, etc.
<darkxst> infinity, thanks, will do
<darkxst> infinity, oh xnox broke the packing ;(
<darkxst> or mitya even
<darkxst> cp: cannot stat 'debian/MPL-1.1': No such file or directory
<darkxst> dh_installdocs: cp -a debian/MPL-1.1 debian/libmozjs-24-0/usr/share/doc/libmozjs-24-0 returned exit code 1
<darkxst> infinity, that file needs to be removed from debian/docs, but I don't have upload rights for that
<infinity> darkxst: I can have a poke at it.
<infinity> darkxst: Looks like debian/docs just needs to go away entirely.
<darkxst> possibly although I believe that came for the debian packaging
<darkxst> from
<infinity> Just giving it a quick test build here.
<darkxst> thanks
<infinity> This is a remarkably comprehensive testuite...
 * infinity taps his foot.
<darkxst> yeh, lots of tests in there
#ubuntu-release 2014-02-16
<darkxst> infinity, can bump gjs through?
#ubuntu-release 2015-02-09
<mdeslaur> infinity: I see you've done some SRUs...could you please release krb5 from trusty-proposed? One of the bugs doesn't have a verification-done, which is blocking it, but it's trivial
<mdeslaur> infinity: and I need to release a security update on top of it this week
<mdeslaur> anyone else from the SRU team? ^
<ScottK> mdeslaur: Looking
<ScottK> mdeslaur: Seems reasonable.
<ScottK> mdeslaur: Done.
<mdeslaur> ScottK: thanks!
<ScottK> yw.
<teward> those two nginx uploads are for this: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1216817
<ubot93> Launchpad bug 1216817 in nginx (Ubuntu Trusty) "[SRU] Using `fastcgi_cache` or `proxy_cache` with nginx-extras causes the push module to throw errors." [Low,Triaged]
<teward> (in case anyone cares)
<teward> oops i accidentally uploaded to -updates instead of proposed, in the changes... my bad... if you need me to recreate let me know.
<teward> oops, another issue, wrong pocket - please reject
<ScottK> teward: Rejected.
<teward> ScottK: thank you
<ScottK> yw
<teward> ScottK: also reject the precise one as well - 1.1.19-1ubuntu0.8
<teward> (there's two in there)
<ScottK> Sure
<ScottK> Done
<teward> this being the first actual upload for an SRU fix, i made a mistake on the upload.  thanks to rbasak for a review and guidance on fixing :)
<teward> (merges in the devel release are easy comparatively >.>)
<teward> ScottK: those two on the other hand should be in the right pocket now
<teward> (same SRU bug)
 * ScottK doesn't have time to process accept right now.
<teward> 'tis fine :)
<teward> no rush at all
<tkamppeter> Can someone reject the Trusty SRU upload of CUPS for bug 1386241 to free the SRU path for a Trusty SRU upload of CUPS for bug 1352809? thanks. The latter bug is more urgent.
<ubot93> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<ubot93> bug 1352809 in cups (Ubuntu Utopic) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<jderose> is there a new expected release date for 14.04.2 now?
<wxl> jderose: not this thursday, but next thursday
<jderose> wxl: awesome, thanks! just helps to know when to expect it :)
<wxl> jderose: there's some problems with the transition from tasks to metapackages that infinity is working on fixing, among other things
<wxl> jderose: if you'd like to test but have nothing to do, there's a fair amount of sru's requiring verification :)
<jderose> yes: "like testing"; no: "have nothing to do" :P
<wxl> hahahah
<wxl> jderose: well keep an eye out on the ubuntu-release mailing list for when we're officially back to testing
<jderose> but i might be able to take a stab at a few, especially if they can be seen as a priority for system76 (that's where i work)
<wxl> ah cool
<jderose> wxl: out of curiosity, why aren't new daily trusty (14.04.2) daily iso's getting built? last build was tuesday last week
<wxl> jderose: for most flavors, the issue with the metapackage transition has resulted in missing/additional packages, which is to say the tests ultimately fail. until that's resolved, it's sort of pointless.
<teward> wxl: that'd be the 19th right?  (for 14.04.2)
<jderose> wxl: happen to have  buglink handy for the metapackage issues? i'm not familiar with what's going on there, sounds like something i should learn about
<wxl> yes, sir, teward
<wxl> jderose: there are several, and honestly, i think only infinity truly understands the extent of the problem and how to resolve them. look at the red bugs on the tracker and those are inevitably them ;)
<jderose> wxl: er, red bugs here? or somewhere else? https://launchpad.net/ubuntu/+milestone/ubuntu-14.04.2
<wxl> jderose: http://iso.qa.ubuntu.com/qatracker/milestones/332/builds
<jderose> ah, that tracker :D
<jderose> wxl: sorry, one more question: where can i find a list of the SRUs that need verification?
<wxl> jderose: it's linked off of https://wiki.ubuntu.com/StableReleaseUpdates
<wxl> jderose: to save you the trouble, https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
<wxl> jderose: or better yet, right to it at http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
<jderose> ah, that's the money. i've wanted a list like that, so i can keep track of what might be coming down from proposed. thanks!
<wxl> jderose: no problem :)
<jderose> hehe, apparently support was definitely added - https://launchpad.net/ubuntu/+source/compiz/1:0.9.11.3+14.04.20150122-0ubuntu1
<wxl> hahahah
#ubuntu-release 2015-02-10
<infinity> mdeslaur: Looks like someone else beat me to it.
<Mirv> archive admins around? there's a new mir release that would appreciate an ack from you to add new binaries libmirserver29, libmirplatform6, mir-platform-graphics-mesa, mir-platform-graphics-android, mir-client-platform-mesa-dev - could you take a look?
<Mirv> the mir source package is built at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages and a summary of debian/ changes (+ build tools diff) is at https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/60/artifact/packaging_changes_mir_0.11.0+15.04.20150209.1-0ubuntu1.diff
<infinity> Mirv: Looks wrong at first glance, but I'm checking the current state of things before I say that. :P
<infinity> Mirv: So, mir-platform-graphics-* are replacing libmirplatform5driver-* right?
<infinity> Mirv: This doesn't affect transaction upgrades like phones, but for apt-get users, you should have the new Conflict/Replace the old to force a smooth upgrade, probably.
<Mirv> infinity: yes, the commit is https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982
<Mirv> infinity: but the new files are not named the same
<Mirv> so the upgrade wouldn't break
<Mirv> infinity: so is it ok or do you want something to be done still? I don't think Conflict/Replaces is needed as it's not conflicting/replacing any of the old files
<Mirv> I'll give any feedback back to the Mir team
<infinity> Mirv: The upgrade won't break due to file overlaps, but the old packages will stay installed for no good reason.
<infinity> Mirv: C/R together is a hint to apt to say "replace this package completely with this other one".
<infinity> Mirv: But you could just argue that apt-get autoremove will sort it later, if that package is always installed only as a dependency of other packages.
<infinity> Mirv: So, meh.  Not a hard NACK from me, just a style issue.
<Mirv> ok then
<LocutusOfBorg1> cjwatson, can you please sync guidedog from debian? (LP: #1407484)
<ubot93> Launchpad bug 1407484 in guidedog (Ubuntu) "[needs-packaging] guidedog needs packaging" [Wishlist,New] https://launchpad.net/bugs/1407484
<LocutusOfBorg1> it should require a manual hint...
<LocutusOfBorg1> (or anybody else, please tell me if I'm wrong somewhere)
<darkxst> can we get ddebs enabled for ppa:ubuntu-gnome-packaging/staging
<darkxst> moving forward that will become the official bridge between gnome3-staging ppas and the archive, rather than using a mishmash of personal ppa's for that task
<mvo> hi, could someone please reject the update-manager upload into precise-propsed? there is a incorrect bug reference in there
<cjwatson> infinity,Mirv: We don't normally use C/R for library transitions, surely; I'd be concerned that for this kind of thing it would make the upgrade unresolvable?
<cjwatson> or at least over-complex
<cjwatson> LocutusOfBorg1: done.  please check whether any of the changes in https://launchpad.net/ubuntu/+source/guidedog/1.0.0-6ubuntu1 need to be ported forward
<cjwatson> LocutusOfBorg1: no, it didn't require a manual hint, just required running syncpackage and then some queue processing
<LocutusOfBorg1> cjwatson, it is qmake now, so everything is fixed already
<LocutusOfBorg1> and BTW that bash-ism is fixed (I fixed it upstream prior to upload)
<LocutusOfBorg1> so yes, plain sync should be ok :)
<LocutusOfBorg1> thanks a lot
<cjwatson> ok
<LocutusOfBorg1> I'm looking at the diff, there is one patch I'm wondering if needed or not
<LocutusOfBorg1> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/guidedog/vivid/view/head:/debian/patches/alternative_shell_fixes.patch
<cjwatson> well, generally avoiding the shell in C/C++ code makes for better code; but afaik all /bin/sh providers in Debian/Ubuntu can cope with "export foo=bar", even though some non-POSIX shells require that to be done in two passes
<LocutusOfBorg1> so I'll fix in a later release without any hurry :)
<cjwatson> I might be missing something, try it with /bin/sh pointing to dash and see
<LocutusOfBorg1> I have sh pointing to dash already ;)
<cjwatson> IIRC the default shell on FreeBSD doesn't like "export foo=bar"
<cjwatson> compare http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=51e3c207a28e6973d034cab241e3c9af64538d22
<LocutusOfBorg1> thanks, I'll fix it :)
<cjwatson> actually, no, that's something slightly different
<cjwatson> I was thinking of http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=ce301be3082e376ef73dd079f0389115f619786f and so of course it was old Solaris
<LocutusOfBorg1> I had to do something similar once, but I never had such issues again
<LocutusOfBorg1> anyway seems worth a change
<infinity> cjwatson: It's a plugin, not a library, but fair point.
<cjwatson> infinity: So, how do we want to handle hints for non-devel proposed-migration runs?  Should we just share a single hints branch for everything, since versions generally aren't shared and if they are then a shared version is normally QAed for everything at the same time?
<cjwatson> infinity: Although that might make block-all cumbersome to handle.
<cjwatson> infinity: So if you'd prefer to create ~ubuntu-sru/britney/hints-ubuntu-$series, perhaps, that'd be good with me.  (It should probably be ubuntu-sru, not ubuntu-release)
<infinity> cjwatson: I think per-series makes more sense, probably owned by SRU, which is cumbersome for you to set up since you recused yourself. :P
<cjwatson> Yup. :-)
<infinity> cjwatson: Want to be reactivated for a bit, if this is something you're working on?
<cjwatson> I guess I could set it up and then immediately leave again.
<cjwatson> I'll just send you MPs for the britney branches, though (and possibly deploy live anyway)
<infinity> cjwatson: Reactivated for now; we can talk about it when I'm slightly more available.
<cjwatson> They shouldn't be complicated
<cjwatson> Sure.  Is it Connect or something?
<infinity> cjwatson: Yeah.
<cjwatson> Enjoy.
<infinity> cjwatson: Owned by SRU means we can make the unblock hints automagic via sru-release, which is the sane way, I think.
<infinity> cjwatson: Rather than having people actually twiddle files and commit.
<cjwatson> Yeah, true
<infinity> cjwatson: Though, in that case, I'll have to think of some way to clean them post-promotion, so people's hint files down grow without bound.
<infinity> But meh, that's a minor detail.
<cjwatson> Big hint files aren't a major problem
<infinity> Yeah, hence the minor detail comment.
<infinity> They're more messy than anything.
<cjwatson> I'll probably leave out block-proposed bug support entirely
<cjwatson> But everything else should be pretty simple
<infinity> cjwatson: If you can keep it, I think the kernel team wants to use it.
<infinity> cjwatson: To make their automated testing stop a kernel from being a migration candidate if, say, DKMS builds fail.
<infinity> cjwatson: Andy and I discussed such a thing last week.
<cjwatson> Huh, OK.  Shall I make it block-$SERIES-proposed in that case?
<infinity> cjwatson: Yeah, I guess, so we don't get weird overlap with the devel series.
<cjwatson> And probably make both block-proposed and block-vivid-proposed work so that people don't get confused.
<cjwatson> Or so that people get differently confused. :P
<infinity> cjwatson: Though, maybe block-proposed-$series, to match the convention for v-needed-* and v-done-*
<infinity> (Even if that means the suite is now backwards...)
<cjwatson> Forwards suite was my thought, but I suppose matching v-* is reasonable
 * infinity wanders off.
<cjwatson> infinity: Could you go over https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/+activereviews when you get a minute, please?
<cjwatson> infinity: I've created the SRU hint branches for lucid/precise/trusty/utopic and pre-emptively vivid
<cjwatson> (actually vivid is because I'm getting either proleptic or forgetful in my old age, but it'll be useful in a bit)
<mvo> hi, could someone please reject the previous  update-manager upload into precise-propsed? there is a incorrect bug reference in there and I uploaded a newer version this morning that fixes a incorrect bug reference
<mvo> eh, actually - just reject all precise-proposed update-manager upload, just found another typo
 * didrocks flushes
<teward> can a distro manager review and release nginx to precise-proposed and trusty-proposed?  There is a bug where the nginx cache manager and a module in nginx-extras don't get along in Trusty and Precise, allowing the cache to (1) not work correctly, and (2) expand beyond maximum set boundaries (i.e. if 1024MB is the max boundaries set, cache can expand beyond that).  If you have questions you can direct them at me.  https://bugs.launchpad.net/ngi
<teward> nx/+bug/1216817 is the relevant bug (set to Medium because you could run into an 'out of space' error with the cache allowing to grow beyond maximum bounds on resource-limited servers)
<teward> blah, whatever, i hate irc truncation.
<stgraber> would appreciate if those procps uploads could be processed shortly as the previous procps update combined with current LXC is causing upgrade failure to people right now.
<infinity> stgraber: Looking.
<infinity> stgraber: Did you forward that upstream and/or to Debian as well?  Looks like a sane fix.
<stgraber> infinity: apparently we never upstreamed the previous fix... I'll send a merge request upstream with the two combined
<infinity> stgraber: Also, I didn't check the constants, but from the naming, wouldn't ERR_PERMISSION_DENIED be more appropriate for ROFS than ERR_UNKNOWN_WRITING?
 * infinity goes string hunting.
<stgraber> infinity: at the top of the same file
<stgraber> though that's in precise only, more recent version of procps no longer have those strings
<stgraber> I figured I'd keep printing the exact same thing and just fix the return value in case someone was somehow looking at the output
<infinity> stgraber: Would explain why I can't find it in vivid. :P
<infinity> stgraber: So, yeah, permission denied is probably "better", but if it's only precise, I don't care.  The generic error is fine too.
 * infinity looks at trusty and beyond.
<infinity> stgraber: Althought, you went generic on the other ones too (ie: matching the default case instead of the eaccess case).  It's pure bikeshedding, though, so I'll let you sort it with upstream when you submit.  Not worth redoing for the SRUs.
<stgraber> xwarn does show the errno string, so I'm actually unsure as to why they special case EACCES to begin with
<stgraber> sysctl: setting key "vm.mmap_min_addr": Read-only file system
<stgraber> that's what you get with the generic code
<infinity> stgraber: Ahh, the full string with the errno looks totally sane.
<infinity> stgraber: So maybe it's the eaccess patch that's wrong. :P
<stgraber> yeah, very well may be :)
<stgraber> anyway, will sort it out when I send that branch upstream (waiting on the confirmation e-mail from gitorious)
<infinity> stgraber: If you can turn around some quick verifications this afternoon, I'll fasttrack releases when I wake up.
<stgraber> infinity: sure can do, thanks!
<stgraber> infinity: https://gitorious.org/procps/procps/merge_requests/37
<stgraber> hopefully that'll get merged soon
<stgraber> infinity: tested all the SRUs
<infinity> stgraber: Ta.
<infinity> stgraber: All released.
<stgraber> thanks!
<infinity> stgraber: NP, thanks for the quick fix.
#ubuntu-release 2015-02-11
<darkxst> can we get ddebs enabled for ppa:ubuntu-gnome-packaging/staging
<darkxst> moving forward that will become the official bridge between gnome3-staging ppas and the archive, rather than using a mishmash of personal ppa's for that task
<darkxst> ^ infinity ?
<infinity> darkxst: Add me to the team, and I can make that happen.
<infinity> darkxst: Alternately, I can ask someone with superpowers. :P
<darkxst> infinity, added you
<infinity> darkxst: Should be good to go.  Assuming I got the two options right.
<darkxst> infinity, thanks
<infinity> darkxst: Bumped up the quota a bit too, hopefully you'll have a bit of room to play.
<darkxst> infinity, ok thanks
<darkxst> I intend to avoid webkitgtk in there, so quota shouldnt be a huge problem ;)
<infinity> darkxst: Well, ddebs have the unforunate habit of being huge.
<infinity> darkxst: But avoiding webkit is a good start.
<infinity> darkxst: Avoiding webkit is a decent life goal in general, I'd say.
<darkxst> ~600MB just for ddebs in webkitgtk
<darkxst> infinity, yes, the ppa builders even struggle to build the bloated thing
<infinity> darkxst: That shouldn't be true with the new and shinier PPA builders.
<infinity> darkxst: If it still is, we'd like to hear about it.
<darkxst> infinity, well havent actually tried to build it in a while
<darkxst> last build was in October, and that is probably using the --no-keep-memory hack
<cjwatson> The new and shinier PPA builders went into production around the end of July.
<darkxst> cjwatson, yeh I think my battles building webkitgtk would pre-date that
<darkxst> cjwatson, though I have seen the odd build get stuck publishing for hours in recent times
<cjwatson> Publishing would be quite different.
<cjwatson> If anything is stuck for hours, there's probably some kind of central bug.
<wxl> infinity: any good enws on fixing our transition to metapackages?
<cjwatson> Or possibly the publishing is OOPSing, which occasionally happens due to races that cause file clashes, but that's rare.
<cjwatson> darkxst: Let us know nearer the time if you see that again.
<darkxst> cjwatson, sure will do
<infinity> wxl: Working on it today.
<darkxst> infinity, err what happened to tasks? dependency resolution on ubuntu GNOME is really broken without them
<wxl> infinity: thank you, sir!
<infinity> darkxst: We can't use tasks in conjunction with the HWE upgrades, because we can't change tasks post-release.  A bit annoying, but such is life.
<infinity> s/upgrade/updates/
<darkxst> infinity, so we are stuck with the u-c-c stack then? things like "unity-control-center | gnome-control-center" just don't work without tasks
<infinity> darkxst: No, you're not stuck with it, I just need to abuse livecd-rootfs a bit more to hint apt to DTRT.
<infinity> darkxst: I already fixed several such issues on the unity flavours, I just have to do the inverse for everyone else.  I have notes, and a plan. :P
<infinity> Possibly also a man and a canal.
<wxl> infinity: if you're messing with livecd-rootfs, will that have an affect on debian-installer? Lubuntu's alternate image uses that and seems to be afflicted with the bug, too
<darkxst> infinity, ok good to know
<infinity> wxl: The alternate image is a bit stickier.  I'm not entirely convinced we *can* fix it, and am leaning toward perhaps suggesting you drop the alternate for 14.04.2 and above.
<wxl> infinity: oh man, that's problematic. with lubuntu focusing on low-spec machines, it's sometimes a requirement.
<infinity> wxl: People who really need the alternate image can always use 14.04.1 and, honestly, are probably not the same set of people who really need shiny new kernels and X drivers.
<infinity> wxl: In fact, you just confirmed it. :P
<wxl> infinity: well, what about 16.04 for example?
<infinity> wxl: Low-spec/old machines don't need the HWE stack.
<infinity> wxl: Oh, for future full releases, we can still do alternates (though, some day, you may want to re-examine that, and tell people who love alterates to just use d-i netboot/mini.iso instead).
<wxl> infinity: so then, these low-spec machines just need to suffer with long update times :)
<infinity> wxl: It's specifically for HWE point releases where making alternates work perfectly seems... Curiously difficult.
<infinity> wxl: Update times?
<wxl> infinity: yeah, it's been a constant point of discussion. if this just affects 14.04, no worries.
<wxl> infinity: well the point releases are HWE + collected updates, no?
<infinity> wxl: Oh, you mean installing 14.04.1 and then having a long apt-get upgrade.  Sure.
<wxl> right right
<wxl> that's totally reasonable
<wxl> infinity: so i will assume you CANNOT fix alternate this cycle. if you find you can, let me know :)
<infinity> We can make them sort of work, I think.  We did make alternate ubuntu images kinda work in precise point releases.  But I'm not sure they were ever perfect.
<infinity> It's the last thing I'll look at, though.
<wxl> fine with me
<wxl> like i said, i'll assume the worst :)
<infinity> Desktop/Live CDs being the more commonly-used (especially by people with shiny video cards) option.
<infinity> wxl: I think it would be in your (lubuntu's) best interest, though, if we could sort out ways to shave off memory usage in ubiquity enough to make you happy with the desktop CD for all installations.
<infinity> wxl: Given that you're the only flavour with an alternate anymore.
<wxl> infinity: i know, i know. we're the black sheep of the family. :)
<infinity> wxl: For people who need the raw flexibility of d-i, there are always the mini/netboot images, but for a full desktop installer, it would be great to see you ship a single ISO like everyone else does.
<infinity> wxl: Anyhow, not worth talking about today.  But something to think about.
<wxl> infinity: if you have ideas on how we could shave memory usage, that's typically the problem. i'm always open to new ideas.
<infinity> wxl: Well, the most obvious way would be a text-only frontend, and skip X entirely.
<infinity> wxl: Or a fun d-i/live mix, like the server CD.
<infinity> wxl: Anyhow, another time.
<wxl> right
<wxl> thanks again and talk later about that :)
<darkxst> infinity, ok ddebs worked ;) thanks
<tkamppeter_> Hi, can someone reject ghostscript 9.15~rc1~dfsg-1 from vivid-proposed? Both the package and the version number (all synced from Debian) are broken. And I would like to upload a ghostscript 9.15~dfsg package.
<infinity> tkamppeter_: And how is this going to be fixed in Debian?
<tkamppeter_> infinity, I do not know how they will switch from the RC1 to the final.
<infinity> tkamppeter_: Perhaps we should do the same thing they do?
<tkamppeter_> infinity, but their RC1 has some things we are not able to sort out before our FF and so I want to stay independent of Debian for Vivid and return to sync after Vivid.
<infinity> tkamppeter_: Anyhow, the obvious way out would be to stop using ~ there.
<infinity> tkamppeter_: 9.15+dfsg-0ubuntu1 would sort higher.
<tkamppeter_> infinity, I also do not expect them to go to final before our FF, once final is out for months and second, working on this GS version is a pet project for the developer as Debian is in freeze )and new stuff is handled in experimental).
<infinity> tkamppeter_: And it would still be a good idea for you and OdyX to agree on a single 9.15+dfsg orig tarball, so syncing later isn't a pain in the butt.
<tkamppeter_> infinity, I am now building 9.15dfsg-0ubuntu1. Should also sort higher.
<infinity> tkamppeter_: +dfsg is the general convention, to keep it clearly demarcated from the upstream version.
<tkamppeter_> infinity, I think I will stay independent of Debian for 9.15 and get back to sync from 9.16 on. GS upstream updates every 6 months.
<infinity> In case upstream were to ship, say, 9.16a. :P
<infinity> Or 9.15a, or whatever.
<tkamppeter_> infinity, I think upstream has never done this, even with a small quirk they have bumped their minor by 1.
<tkamppeter_> infinity, and such an oops release would also happen very close after the release and not months later as now. So next is for sure 9.16
<infinity> tkamppeter_: Sure, maybe they wouldn't, it's still just generally nicer to keep the "dfsg" bit as clearly not part of the upstream version.
<infinity> tkamppeter_: I'm not bikeshedding here, just pointing out general Debian convention.  The part where ghostscript used ~dfsg instead of +dfsg is what lead to the hilarity.  May as well not make a slightly different mistake to cover it.
<tkamppeter_> infinity, OK, will use +dfsg.
<infinity> tkamppeter_: Ta.  I've made the same suggestion to OdyX.  We'll see if he changes his versioning in Debian for his next version. :P
<tkamppeter_> infinity, ghostscript at Debian is handled by Jonas Smedegaard, not by OdyX. So probably Jonas has introduced the broken version number.
<tkamppeter_> infinity, but thanks anyway for the suggestion od *dfsg.
<tkamppeter_> s/*dfsg/+dfsg/
<infinity> tkamppeter_: Oh, I saw some uploads from OdyX and assumed he was the culprit.
<tkamppeter_> infinity, can it be that Jonas creates the GS packages and OdyX uploads them?
<infinity> tkamppeter_: Looks like they both upload, I just picked on one of them.
<infinity> tkamppeter_: I've annoyed Jonas too now. :P
<tkamppeter_> infinity, the debian/changelog entry of the package which I have synced is "signed" by Jonas.
<infinity> tkamppeter_: Yeah, he was probably doing the experimental uploads, while recent unstable uploads were OdyX.
<tkamppeter_> infinity, +dfsg is now uploaded to vivid-proposed and accepted by the server. amd64 is already building.
<tkamppeter_> infinity, so the version number is correct.
<ogra_> infinity, did we drop the precise crontab entries on cdimage on purpose ?
<ogra_> (crontab -l output is stunningly short)
<infinity> ogra_: Yes, the last precise point release was 12.04.5, there will be no others, so no point in daily images.
<ogra_> ah, cool
<teward> thanks to whomever accepted nginx into precise-proposed.
<teward> any chance anyone can look at the trusty-proposed upload of nginx as well?  Same case as the precise-proposed one, just needs accepted into -proposed.
<teward> thanks to whomever accepted nginx to trusty-proposed as well
<ogra_> i have switched the system-image importer off for a coordinated device tarball landing
<wxl> infinity: the metapackage issue is not affecting vivid daily is it?
<cjwatson> wxl: shouldn't expect so, since tasks are updated in development series
<wxl> cjwatson: okie dokie. thanks. :)
<bdmurray> arges: Could you have a look at this gdb upload in the utopic queue? I'd just like a second opinion.
<arges> bdmurray: sure.
<arges> bdmurray: hmm why does the gdb changelog add vivid/experiemtal entries? so we're essentially applying a bugfix only stable update to gdb
<bdmurray> this bug sort of explains it better https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1394542
<ubot93> Launchpad bug 1394542 in gdb (Ubuntu) "SRU: gdb-7.8.1 for utopic" [Undecided,New]
<arges> bdmurray: any why wasn't a patch against 7.8-1ubuntu4 possible/
<arges> bdmurray: ah
<arges> bdmurray: yea this is a beast of a diff.
<arges> bdmurray: not sure what Binary files /tmp/ata_ZKYx4X/gdb-7.8/gdb/doc/gdb.info-7 and /tmp/AlEUppVBQj/gdb-7.8.1/gdb/doc/gdb.info-7 differ
<arges> is
<arges> bdmurray: so i think figuring out what that binary change was. the glob looks like we'd expect from a stable update. the 'non-linear' changelog isn't optimal either, but probably doesn't harm anything
<bdmurray> arges: okay, thanks for looking
<arges> bdmurray: hopefully that helps... reviewing the openstack stuff atm
<sil2100> Hey everyone! I re-enabled the image importer on system-image now
<tkamppeter> arges, hi
<arges> tkamppeter: hi
<tkamppeter> arges I tried already cups 1.7.2-0ubuntu1.3, but as this number was already used for the SRU in bug 1386241 which I have withdrawn, my attemt to upload the new SRU with this number got auto-rejected by the upload server. I was told then to use 1.4.
<ubot93> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<arges> tkamppeter: yea there was another fix for cups that was uploaded for 1.3, will it be a problem to use 1.4?
<tkamppeter> arges, no. I have uploaded it as 1.4 and you have rejected it.
<arges> tkamppeter: hmm i thought i rejected the other upload.
<tkamppeter> I got a reject message for the 1.4 which I have uploaded yesterday (or on Monday).
<arges> tkamppeter: hmm. Today I was looking at: bug 1352809
<ubot93> bug 1352809 in cups (Ubuntu Trusty) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<tkamppeter> arges, you have added a comment to that reject that I should use 1.3 instead of 1.4.
<arges> tkamppeter: give me one second to review. I'm unsure why your upload was rejected as I was trying to reject the upload for the bug I mentioned above.
<tkamppeter> arges, yes, for this bug (bug 1352809) I did the upload this week, with version 1.4, as 1.3 was already used up by the other bug.
<ubot93> bug 1352809 in cups (Ubuntu Trusty) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<tkamppeter> The SRU I want to be done now is the one for bug 1352809.
<arges> tkamppeter: ok so right now no cups fixes have been uploaded for either
<tkamppeter> arges so I will put that SRU back in as 1.4, then you accept it.
<arges> tkamppeter: Yes, I think that may work. Will you also include the fix for 1352809?
<arges> (Sorry, you already answered that)
<arges> Yes
<arges> tkamppeter: there it is. Reviewing it now.
<tkamppeter> arges, the other bug (IPP Everywhere) I will do later as the manufacturers need to do more IPP-overUSB testing.
<arges> tkamppeter: ok perfect. sorry about the confusion.
<tkamppeter> arges, it is a simple patch, same as for Utpic which you have accepted.
<arges> Yes, looks identical
<arges> tkamppeter: thanks
<tkamppeter> thanks for accepting.
<ari-tczew> can someone move cmdtest to main?
<ari-tczew> it's needed to build current xauth
#ubuntu-release 2015-02-12
<infinity> wxl: Don't see why it would be.
<bzoltan_> slangasek: I would like to publish static SDK rootfs images what will be used for click chroots. Who do I need to talk about it?
<ypwong> could someone from sru team give help to approve bug 1415792?
<ubot93> bug 1415792 in OEM Priority Project trusty "[SRU]After install ubuntukylin-theme the grub can't be updated" [Undecided,New] https://launchpad.net/bugs/1415792
<tmpRAOF> ypwong: Does that not reintroduce https://bugs.launchpad.net/ubuntukylin/+bug/1228462 ?
<ubot93> Launchpad bug 1228462 in ubuntukylin-theme "image build failed due to the grub-probe operation" [Critical,Fix released]
<ypwong> let me ask aron
<tmpRAOF> ypwong: I'm about to go to sleep, but the next SRU person to touch this is likely to ask the same question :)
<ypwong> tmpRAOF, alright, I will ask aron to put a comment in the bug, thanks :)
<cjwatson> slangasek,infinity: It'd be really helpful if I could get review of https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/+activereviews so that I can move forward with getting proposed-migration set up for stable releases
<tseliot> Riddell: are you around?
<Riddell> hi tseliot
<tseliot> Riddell: hi, I have 4 nvidia sources waiting in vivid NEW. Can you give me a hand, please?
<Riddell> tseliot: nvidia stuff scares me, it needs overrides set I guess
<tseliot> Riddell: let me check
 * Riddell runs queue fetch
<tseliot> Riddell: did you mean overrides for restricted?
<Riddell> yep
<Riddell> which is probably easy
<tseliot> Riddell: whatever is already there for -331 should work for -346, etc. if you replace the flavour
 * tseliot looking
<tseliot> Riddell: I don't see any for the nvidia packages (other than nvidia-prime)
<Riddell> tseliot: oh you have nvidia-graphics-drivers-340  and  nvidia-graphics-drivers-346 ?
<Riddell> can I just reject the 340 ones?
<Riddell> apt-cache showsrc nvidia-graphics-drivers-331-updates
<Riddell> that does say it's in restricted
<tseliot> Riddell: the 340 series should replace 331 (as a legacy driver), whereas 346 is for newer GPUs
<tseliot> it's not a mistake ;)
<Riddell> gosh
<tseliot> and no, I don't think they will drop out of restricted. To the best of my knowledge, nvidia packages never have
<Riddell> they do need an override added by archive admin, they're in universe currently says https://launchpad.net/ubuntu/vivid/+queue
<Riddell> I just ran the override command
<Riddell> oh indeed they're in restricted, all is good
<tseliot> good :)
<Riddell> W: nvidia-graphics-drivers-340 source: ancient-standards-version 3.8.0 (current is 3.9.6)
<Riddell> ancient!
<tseliot> Riddell: oh, I'll fix that in my next uploads
<tseliot> I'd like to have drivers that work with linux 3.19 that the kernel team is going to upload soon
<tseliot> so that things don't break
<Riddell> tseliot: accepted!
<Riddell> I guess you'll need to ping me in a bit for the binaries, keep an eye on https://launchpad.net/ubuntu/vivid/+queue
<tseliot> Riddell: thanks a lot! I'll ping you again later then
<Riddell> why ever has someone uploaded two packages both nearly identicle with 1 python script in each to change the folder colour in "nemo desktop environment" and "caja desktop environment" which both seem to be forks of nautilus
<sil2100> Hey release team! I filled in another standing FFe for vivid's ubuntu-touch packages, could someone check if it's alright?
<sil2100> https://bugs.launchpad.net/ubuntu/+bug/1421174
<ubot93> Launchpad bug 1421174 in Ubuntu "[FFe] standing freeze exception in vivid for Ubuntu Touch-specific packages" [Undecided,New]
<tseliot> Riddell: I can see all of the binaries but the ones for nvidia-graphics-drivers-346 (armhf) and for nvidia-graphics-drivers-346-updates (armhf)
<mdeslaur> can someone please reject the xorg-server-lts-utopic upload there? ^
 * mdeslaur messed up the pocket
<Riddell> mdeslaur: rejected!
<mdeslaur> Riddell: thanks!
<tseliot> Riddell: thanks again
<Riddell> de nada
<Laney> heh
<Laney> Was just going to send the beta 1 nag mail, check release schedule - it's in two weeks, not one. :)
<elfy> Laney: I have that nag mail written ...
<Laney> oh
<Laney> nice!
<Laney> elfy: I'm just used to doing it myself, but makes sense for you to if you want
<elfy> Laney: waiting for the rerun ofn trusty .2 before I sent it tbh
<Laney> one week is fine
<infinity> cjwatson: Too much wine to review, can you poke me again later?
<cjwatson> infinity: sure
<zul> can someone promote python-tempest-lib please (#1420006) its blocking a nova build
#ubuntu-release 2015-02-13
<elfy> infinity: re trusty .2 - did the changes get done and I just need to request rebuild? or something entirely different?
<infinity> elfy: Not quite done yet, sorry.  Will be trying to finish it up before I hop on a plane tomorrow.
<elfy> okey doke :)
<elfy> just thought I'd ask in case I'd missed something ;)
<ScottK> How often are seed updates published on p.u.c?  I pushed a change a couple of hours ago to kubuntu.vivid supported and it hasn't appeared yet.
<ogra_> usually immediately
<ogra_> i rarely see a few mins delay, usually the change is there if i hit reload in the browser after pushing
<ScottK> That's what I thought.
<ScottK> I just didn't want to scream bug right away.
<ScottK> Sigh.
<ScottK> infinity: If you could look at why my supported seed changes aren't getting synced, I'd appreciate it. bzr claims i pushed the changes to bzr+ssh://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.vivid/ (up to rev 1300).
<cjwatson> ubuntu-archive@snakefruit:~$ ps xf -o pid,start,args | grep seeds
<cjwatson> 32667   Jan 24 /bin/sh -c update-seeds
<cjwatson> 32680   Jan 24  \_ /bin/sh /home/ubuntu-archive/bin/update-seeds
<cjwatson>  3765   Jan 24      \_ /usr/bin/python /usr/bin/bzr pull -d mythbuntu.utopic --overwrite --remember http://bazaar.launchpad.net/~mythbuntu-dev/ubuntu-seeds/mythbuntu.utopic
<cjwatson>  8567 15:46:21          \_ python /home/ubuntu-archive/germinate/bin/germinate -S file:///home/ubuntu-archive/public_html/seeds/ -m file:///home/ubuntu-archive/mirror/ubuntu -s ubuntukylin.vivid -d vivid -c main,restricted,universe,multiverse
<cjwatson> that can't be helping
<cjwatson> (ignore the last line)
 * cjwatson kills that and breaks the lock
<cjwatson> ScottK: synced now, sorry about that
<ScottK> cjwatson: Thanks.
<cjwatson> infinity: re-reminding you about britney1 reviews, although I don't know what your flight schedule's like ...
<ScottK> cjwatson: How often does the packageset update cron job run (I just tried to update it for the first time and it'd be nice to know if I succeeded)?
<cjwatson> ScottK: 30 8 * * *              packageset-report ~/public_html/packagesets
<ScottK> Thanks.
<infinity> cjwatson: I think it's more realistic to expect that I'll have time when I get back to Canadia (in a day or two, so call it Monday).
<cjwatson> slangasek: you seem to have given me the same review twice on https://code.launchpad.net/~cjwatson/britney/output-prefix/+merge/249048 :-)
<slangasek> cjwatson: bah sorry
<slangasek> cjwatson: I was confused when my browser showed the review comment still in the text window, and clicked submit again ;)
<wxl> infinity: where can i go to track the progress on the metapackage transition in trusty? i mean i can keep bugging you every day butâ¦ âº
<elfy> wxl: tbh - I think that we'll know via mailing lists when it's done and the new images are ready for us to tell people about
<wxl> elfy: i would hope, but there's not even a record of the problem on the mailing list
<wxl> i keep telling people about it and they're like "where was this announced?"
<elfy> well if it doesn't turn up on a mailing list - I'm pretty sure we'll get told here and we can do *our* jobs and promulgate the info to our testers
<elfy> and https://lists.ubuntu.com/archives/ubuntu-release/2015-February/003208.html
<elfy> it was on the mailing list ;)
<wxl> well it was but it's not very speciffic
<wxl> "oopsies" is not very descriptive XD
<elfy> does it have to be specific - people should be able to see something is wrong
<DalekSec> elfy: I'd say it's decently important, will tasksel still work?  apt-get install kubuntu-desktop^ ?
<DalekSec> Stuff like that.
<wxl> yep
<elfy> DalekSec: no idea - and you know that I'd have no idea ;)
<wxl> elfy: but these are the sorts of questions that are being asked
<wxl> and ultimately aren't addressed in any sort of public way
<elfy> and I'm off now - really not my issue :)
<DalekSec> elfy: Of course, I'm just giving an example of questions.
<elfy> at the end of the day, my interest in here lies solely with Xubuntu, if I'm able to answer someone with a *generic* response I'll do so - but I'm not part of the -release team :)
<elfy> it often happens that an Xubuntu answer is going to be the same as one for Lubuntu - but that's as far as it goes
<elfy> and I would rather answer *that* and let them that are actually doing the work get on with it - if that makes sense :)
<ScottK> DalekSec: kubuntu-desktop isn't a function of tasksel, it's a metpackage.
<ScottK> Functionally, you get the same result though.
<DalekSec> ScottK: I understand this, but it does install the task (which yes, installs the meta.) and from my testing installing a task ends up with different results.
<ScottK> OK.
<DalekSec> Thanks for answering though.
<elfy> indeed
<elfy> it will come in useful in coming months for DalekSec :)
<infinity> wxl: I'll mail the list when I've sorted it all out.
<wxl> infinity: thank you, as always :)
#ubuntu-release 2015-02-14
<Logan> o_O
<teward> are sync requests still being processed?
<cjwatson> how do you mean?  sync requests are no different from any other sponsorship request nowadays, really
<Ukikie> teward: Not FF, so yes.
<cjwatson> sync requests aren't necessarily impeded by FF anyway
<cjwatson> it depends on what actually changes
<teward> cjwatson: substantial feature additions for `znc` package, but a bunch of security improvements as well (such as SSL Protocol selection ,Cipher selection, also the default disabling of SSLv3 for its SSL listeners per POODLE, etc.)
<teward> cjwatson: so this one would need FFe consideration if Freeze hit
<teward> already filed the request
#ubuntu-release 2015-02-15
<Logan> teward: synced :)
<teward> Logan: saw, thank you!
#ubuntu-release 2016-02-15
<chrisccoulson> Ukikie, thanks
<doko_> cjwatson, Laney: could somebody add a hint that netcdf is migrated together with openmpi?
<cjwatson> doko_: No point asking me, I can't.
<doko_> oops
<Laney> doko_: missing mpi4py freefoam ncl palabos tachyon nwchem at least
<doko_> Laney, mpi4py and tachyon uploaded, removed freefoam, asked pitti to ignore palabos tests
<Laney> when they are all candidates come back and look again at output
<Laney> hinting won't help
<doko_> the frustrating thing is that new uploads test against the release pocket, and then making these transitions invalid again
<flocculant> infinity: not sure if you want to know - but trusty .4 milestones are all working - until I try and upgrade them to 16.04
<jderose> infinity: do you expect to spin ISOs today for 14.04.4 that don't have proposed enabled?
<infinity> jderose: Yep.
<infinity> flocculant: What explodes on upgrade?
<flocculant> infinity: given ^^ -proposed - which I'd not noticed sadly - I wonder if what I saw was invalid
<flocculant> but bug 1545492 bug 1545709
<ubot5`> bug 1545492 in ubuntu-release-upgrader (Ubuntu) "upgrader hung at installing new version of /etc/gnome/defaults.list" [Undecided,New] https://launchpad.net/bugs/1545492
<ubot5`> bug 1545709 in ubuntu-release-upgrader (Ubuntu) "Failed to upgrade from 14.04 to 16.04" [Undecided,New] https://launchpad.net/bugs/1545709
<infinity> flocculant: Oh, it's quite possible it blew up due to HWE->non-HWE upgrades, that stuff might not be fixed in 16.04 yet.
<flocculant> right
<flocculant> I did a 14.04.3 updated to wherever it updates > 16.04 and 14.04.4 > 16.04
<flocculant> just thought I would mention it Monday rather than Thursday :p
<cjwatson> Ah good, openmpi et al made it
<cjwatson> Nice one
<cjwatson> infinity: Could you drop my click, python-click etc. hint from my hints file?  It's completed
<infinity> cjwatson: Yep.
<cjwatson> ta
<mapreri> cjwatson: something I can do to move #1531529 forward ? :)
 * mapreri feels himself very noisy now, sorry
<cjwatson> mapreri: should that be "please remove the pencil source" in the last paragraph?
<mapreri> cjwatson: wuops, fixed
<cjwatson> mapreri: sorry for the delay, done now
<mapreri> cjwatson: â¥ ta!
<jderose> infinity: i see ISO builds! :D i'll test as soon as i get back from lunch
<wxl> why did we have a global re-spin? getting rid of proposed?
<flocculant> wxl: afaik yep
<wxl> flocculant: kthx :)
<wxl> apparently http://launchpad.net/bugs/966480 is back for us in 14.04.4's latest version though it wasn't in the previous one. can anyone else confirm or deny?
<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]
<flocculant> wxl: not from livesession I can't
<wxl> flocculant: it was reported on an entire disk install fwiw
<flocculant> can't remember if it occurred when I did install - and tbh I tend to ignore that in vbox now
<wxl> i know the feeling
<flocculant> I can do a quick install
<wxl> thx!
<infinity> wxl: Ditched -proposed and s/Beta/Release/ on the disk labels.
<infinity> wxl: May or may not be the final build, but definitely worth treating it as RC just in case.
<wxl> infinity: as per usual :)
<infinity> wxl: Can you do me a favour and try to hunt down flavour people to make sure others are testing their images?  I'm concerned that some don't read ubuntu-release/ubuntu-quality. :P
<wxl> infinity: well i know lubuntu and xubuntu are taken care of. who else matters? XD
<infinity> wxl: Looks like gnome and ubuntu are covered too.
<wxl> flexiondotorg: you awake? just checking in on how mate is coming along with testing.
<wxl> and we never hear from kylin, so..
<infinity> wxl: Oh, and studio woke up and registered some results.
<infinity> wxl: But kubuntu might need love.
<wxl> i'll see what's up there
<wxl> let's see who's around from the kubuntu camp
<infinity> wxl: MATE didn't release with 14.04, so they're fine.
<infinity> stgraber: Anyone doing edubuntu 14.04.4 testing?
<infinity> wxl: Oh, and myth might not be awake either. :P
<infinity> superm1 / tgm4883: mythbuntu 14.04.4 testing, is someone on that?
<infinity> cyphermox: Is that mpath-tools update needed for .4?
<cyphermox> yes
<cyphermox> fixes a regression in an update that was otherwise all good
<infinity> cyphermox: Still has a missing verification.
<cyphermox> oh?
<infinity> LP: #1543430
<ubot5`> Launchpad bug 1543430 in multipath-tools (Ubuntu Trusty) "kpartx 0.5.0-7ubuntu11 fails to remove loop mapping on kpartx -d" [Undecided,Fix committed] https://launchpad.net/bugs/1543430
<cyphermox> ah, jes
<cyphermox> ugh lemme poke at it, I should have a VM ready
<stgraber> infinity: yeah, I'll take care of it
<wxl> infinity: kubuntu is out for 14.04.4. they're having some issues with debian merges and are short on packagers. so if you know any help to send their way..
<flocculant> wxl: 32bit install to entire disk - removed image and rebooted as expected
<wxl> infinity: flocculant: fwiw it's unknown if kubuntu is going to participate in 16.04 beta 1.
<wxl> flocculant: this is xubuntu you tested on right? i mean goes without saying but..
<infinity> wxl: They can't be "out", they committed to being an LTS.  I'll hunt someone down, I guess.
<wxl> infinity: flocculant: which is to say they are not sure if they're going to.
<wxl> infinity: well, yofel's the person you need to speak with
<flocculant> wxl: yea - I just didn't want to have to chase the world at the end of the week - I'll catch up with stragglers though
<flocculant> wxl:  and yes - xubuntu
<wxl> flocculant: yeah well, so you know, sounds like they're really freaking out. :)
<flocculant> well - they don't have to participate ofc
<cyphermox> infinity: verified.
<wxl> yes but it sounds like they have to participate in 14.04.4
<flocculant> yea
<wxl> flocculant: you using vbox?
<flocculant> wxl: I'm not doing more today - I'm all done testing tonight - but I'll see if I can confirm lubuntu tomorrow
<flocculant> wxl: yea
<wxl> flocculant: don't worry about it now. i've got some other people i can sick on it. i just wantewd a quick spot check and i appreciate you coming through :)
<wxl> have a good night, buddy!
<flocculant> :)
<infinity> wxl: Going to respin again for multipath-tools sometime later today, probablky.
<wxl> infinity: and by probably, you're referring to the when, not the if, right? :)
<infinity> wxl: Indeed.
<jderose> infinity: my trusty helper and i just finished our testing  of the 14.04.4 daily desktop ISO... everything seems shiny, no issues found
<infinity> jderose: That's promising news.
<wxl> infinity: when you do that re-spin, a heads up on the ubuntu-release ml would be most appreciated
<infinity> wxl: Sure.
#ubuntu-release 2016-02-16
<jderose> infinity: hmm, something seems screwy with the daily 14.04.4 server ISO (amd64): has the 3.19 kernel installed, still has proposed enabled
<wxl> jderose: only amd64?
<wxl> jderose: and is that what you see in live, in an installed version, or both?
<jderose> wxl: not sure, amd64 is all i tested (that all system76 uses at the moment)
<jderose> wxl: currently i'm looking at the installation... just found this. i'm about done for the day, so i'll have to investigate more tomorrow.
<wxl> jderose: k. i know infinity has another respin in the queue, so you might wait until you see a new version
<jderose> wxl: sounds good, thanks!
<wxl> jderose: weird that you're seeing 3.19, too. it's not even in trusty-proposed.
<wxl> well according hto the bots at least
<cjwatson> wxl: linux-lts-vivid
<cjwatson> you might be looking for just linux
<wxl> ahh right
<cjwatson> (are we actually releasing with the hwe-v kernel?  I've not been much involved in 14.04.4 ...)
<infinity> jdstrand: Err, that really shouldn't have 3.19...
<infinity> Oh, he left and I hilighted the wrong person.
<jderose> infinity: never mind what i said earlier about the 14.04.4 daily server ISO... i somehow must have been testing with the wrong image from our imaging server or something... everything in fact seems shiny with the 14.04.4 server ISO
<flocculant> jderose: unless you're now testing the new new iso - and the old new one had an issue :)
<jderose> flocculant: maybe so :)
<flocculant> :)
<flocculant> I'm going to not look at this one until Thursday - just in case there's a new new new one lol
<jderose> flocculant: generally the final iso will be the one built on wednesday... so if you want to help test, please at least test on wednesday rather than waiting till thursday :)
<flocculant> jderose: I'm joking - I'd find it hard to push my testers if I had put my feet up :)
<jderose> haha
<infinity> flocculant: I'm kinda hoping this is the last one unless something major pops up.
<flocculant> infinity: :)
<infinity> jderose: Good to hear, since I couldn't figure out what you were talking about. :)
<jderose> infinity: at further inspection, i can't figure out what i was talking about either :)
<infinity> jderose: Happy to chalk it up to temporary insanity.
<jderose> infinity: /etc/lsb-release still says 14.04.3... is that expected? this is from a desktop 20160216 install i just did
<infinity> jderose: Oh, crap.  Yeah, there'll be one more respin for base-files tomorrow. :P
<jderose> infinity: cool, glad i happened to notice that
<flocculant> jderose: bug 1544592 :)
<ubot5`> bug 1544592 in lsb (Ubuntu) "lsb_release not upgraded to 14.04.4 - papercut bug" [Undecided,Confirmed] https://launchpad.net/bugs/1544592
<jderose> infinity: i did see that queuebot disapproved base-files... just in case you didn't notice. mostly i'm just rearing to test more ISOs :P
<Trevinho> Hey, this silo (https://requests.ci-train.ubuntu.com/#/ticket/999) is failing because a component has no valid dependency on an arch... https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-040/excuses.html
<Trevinho> The thing is unity never built on s390x (because also nux has troubles, on tests IIRC).. So, generally this an error that is ignored
<Trevinho> how to do to that?
<Trevinho> Laney: do you happen to know this? ^
<apw> Trevinho, in the normal -proposed work that might be hintable, but if you know it can never build you also could remove the dep on that arch
<infinity> jderose: Looks accepted to me.  I'm respinning for it shortly, after looking at a potential server issue.
<bdmurray> infinity: do you have plans to fix base-files? bug 1544592
<ubot5`> bug 1544592 in base-files (Ubuntu) "lsb_release not upgraded to 14.04.4 - papercut bug" [Undecided,Confirmed] https://launchpad.net/bugs/1544592
 * bdmurray sees the change now
<infinity> bdmurray: Yeah, iz fixed, you can manually close the bug.
<bdmurray> infinity: I did like 5 minutes ago. ;-)
<infinity> bdmurray: Ta.
#ubuntu-release 2016-02-17
<davmor2> infinity, cyphermox: hmmm we might have the standard wifi doesn't install on mac issue will confirm momentarily
<davmor2> infinity, cyphermox: indeed it looks like it is bulking out somewhere again, I've run ubuntu-drivers list on the installed system and it show the bcmwl-kernel-source but hasn't installed it will check on the live cd now
<davmor2> infinity, cyphermox: right so live cd ubuntu-drivers list shows bcmwl-kernel-source too but just isn't installing it when 3rd party drivers is selected, let me try and install it from additional drivers and be sure it actually installs
<davmor2> infinity, cyphermox: okay so the driver is installed but doesn't seem to be working I assume it is the newer kernel maybe?  is there any way to see what is going on?
<davmor2> gaaahhhh I hate Macs
<infinity> davmor2: It's the kernel team's fault, I've got Leann on it.
<ogasawara> I've just nudged my doods
 * xnox kindly asks for a binary-deNEW for 	golang-github-azure-azure-sdk-for-go-dev_1.2~git20150611.0.97d9593-2ubuntu1_all.deb (a botched up update to a sync from debian to get it building)
<davmor2> ogasawara, infinity: thanks guys
<xnox> should get us docker-registry building, and maybe merged/updated docker.io from there.
<davmor2> infinity: it still doesn't make me like macs anymore though
<apw> infinity, ok that bug appears to be fixed in the version of bcmwl in trusty-proposed (to my eye)
<apw> infinity, do your images include -proposed ?
<davmor2> apw: doubtful should only be landed stuff in there
<apw> and i bet in early testing it was all in -proposed only, so it worked, so i guess that needs promoting
<davmor2> apw, infinity: anything needed to get that proposed package promoted at all?
<smb> arges, Not sure whther time allows you but if you pull the current source of Xen from lp and try to build it in a Xenial chroot. Does this work? This seems to have stopped working for me about 1 or 2 hours ago (time starts fleeting when one turns mad)
<arges> smb: i'll give this a shot
<smb> thanks...
<arges> smb: will be after lunch for me
<smb> arges, no worries. I'll hang around a bit longer.
<infinity> davmor2: Yeah, I need to know it works.  No one verified it.
<infinity> davmor2: Can you fire up a live session, add proposed to sources.list and install it... Assuming you have a USB ethernet dongle to get internet. :P
<infinity> davmor2: or just copy the deb and dpkg -i it.
<bjf> davmor2, infinity is 6.30.223.248+bdcom-0ubuntu0.2 the correct one you want tested? if so it works for me
<infinity> bjf: Ta.
<infinity> bjf: Wait, with lts-wily?
<infinity> bjf: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1529945 claims it doesn't work with lts-vivid, which was why it was verification-failed.
<ubot5> Launchpad bug 1481662 in bcmwl (Ubuntu) "duplicate for #1529945 bcmwl-kernel-source 6.30.223.248+bdcom-0ubuntu4: bcmwl kernel module failed to build [FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol 'flush_workqueue']" [High,Confirmed]
<infinity> bjf: Can you test that it builds with both?
<bjf> infinity, will try
<wxl> i just got word there are some bug fixes happening in lxde packages in upstream/debian this weekend that would be nice to get into LTS. since this is beyond DebianImportFreeze, what's the next step for us to make this happen?
<infinity> wxl: Bug fixes don't break feature freeze.
<infinity> wxl: And debian import freeze is when we stop *auto* importing.
<infinity> wxl: You can still manually sync.
<infinity> (Assuming the manual sync doesn't break feature freeze)
<wxl> infinity: okie dokie then. :)
<wxl> infinity: trying to get myself familiar with the entire process, though it's likely others that will do this. do you have a link to a page discussing manual sync?
<wxl> oh there's this https://wiki.ubuntu.com/SyncRequestProcess?highlight=%28CategoryProcess%29
<wxl> infinity: it says "After FeatureFreeze, syncs of a newer upstream version require a freeze exception." this is what you mean by manual sync?
<bjf> infinity, verified
<infinity> wxl: Manual syncs just mean running "syncpackage foo", but for new upstreams and new features, you need to file for a feature freeze exception before just syncing or uploading willy-nilly.
<infinity> bjf: You're my hero.
<teward> infinity: is there a specific time UTC at which FeatureFreeze comes into effect?  I'm trying to get in nginx 1.9.11 before FeatureFreeze, but I don't want to hit any issues, hence needing to know in UTC what the last-minute time for me being able to upload is. (unless it's already in effect?)
<infinity> teward: Vaguely 2100ish, but I'd rather it was correct than rushed.  We're pretty lax on FFes in the week or two following feature freeze, and get more strict as time runs out.
<teward> infinity: ack.  The FFe in this case would be super minor, given that the package isn't utilizing the other feature implemented yet, but the big delay in 1.9.11 getting uploaded direct is (1) Debian being slow, and (2) FTBFS in the nginx-extras (Universe) portions.
 * infinity nods.
<teward> i'm probably going to get this in by, oh, 2100 on 17 February 2016 (UTC-5), but feel free to stab me if I miss the timepoint and upload
 * teward probably deserves it at that point :)
<flocculant> infinity: do you happen to be a moderator on the -devel list? if you are could you moderate my mail to it please :)
<infinity> teward: I have to break feature freeze much more spectacularly than you will, don't worry too much about it in the first week or so, just be mindful that we *could* say no if you're being crazy.
<infinity> flocculant: I am not.
<flocculant> k
<teward> infinity: i highly doubt there'll be craziness, unless Debian decides to implement nginx dynamic modules, in which case we have a flurry of main/universe pocket changes, and additional corresponding headaches to deal with
<teward> not to mention Security Team overviews needed >.<
 * teward shivers
<teward> i think the likelihood of that is very low
<teward> but... *shrugs*
<teward> likely going to have two uploads for 1.9.11, though, one for the "get it in before FeatureFreeze" part, another for a merge from Debian getting any additional fixes/changes unless they try and implement dynamic modules
<teward> but it shouldn't be insane
<teward> thanks, infinity
<infinity> davmor2: I'll be spinning new images in an hour or so with the bcmwl fix.
<rbasak> infinity: while you're about, what's the situation with the PHP move? nacc needs some AA help and I know you're busy. So do you want an FFe filed or can we assume that we have one?
<infinity> rbasak: You can assume you have one, and I'll be helping when I'm done with the point release and this snappy sprint.
<rbasak> OK. Thank you!
<xnox> infinity, "fixed" docker-registry now ^
 * xnox guesses i only have a chain of gazzilion packages left to get to building updated docker.
#ubuntu-release 2016-02-18
<amjjawad> hi infinity when I go to: http://cdimage.ubuntu.com/ubuntu-gnome/trusty/daily-live/20160217.1/trusty-desktop-i386.iso .. I get an error message "Not Found"
<amjjawad> infinity, "The requested URL /ubuntu-gnome/trusty/daily-live/20160217.1/trusty-desktop-i386.iso was not found on this server."
<amjjawad> same for "Ubuntu GNOME Desktop amd64"
<jderose> yeah, i've been noticing weird things too... in the trusty/daily/ folder, 20160217.1 keeps appearing and disappearing but only have the i386 oversize warning file there
<infinity> amjjawad: It's probably rsyncing.
<infinity> jderose: ^
<wxl> except that it doesn't show rebuilding on the tracker
<wxl> which is what i'm accustomed to
<wxl> like Lubuntu's still building
<infinity> It's syncing from the primary build machine to the mirror frontends.
<infinity> It marks it as done when it's done on the primary.
<amjjawad> infinity, thanks for your reply. Any idea how long that would take? I'm on +11GMT and it's a huge hassle for me to keep up with those who are in your time zone for example ..
<infinity> So, just be patient.
<amjjawad> Ok, guess no other option but to be patient :)
<infinity> It's trying hard to push the bits around. :)
<infinity> wxl / amjjawad: Those images should be all happy now.
<amjjawad> infinity, seems so, many thanks :)
 * highvoltage checks in for testing time
<highvoltage> 
<davmor2> infinity: \o/ wifi on a mac \o/ \o/ \o/ and now back to testing
<Adri2000> I just got filezilla 3.15 and libfilezilla (NEW) uploaded into xenial, the latter being needed by the former. a bit feature freeze rush :)
<flocculant> infinity: marked xubuntu ready - grabbing the kubuntu images now - if no-one's touched them when I get back I'll at least make sure the images load in vbox and install
<tgm4883> Wild question and possibly not the right place to ask, but is there any way for a flavor to have a PPA enabled (either via asking the user, or automatically) in the ISO?
<cjwatson> All a flavour's packages have to be in the primary archive - that's part of the definition of being a flavour
<cjwatson> https://wiki.ubuntu.com/RecognizedFlavors
<lamont> does poilicy say that main should not Recommend: universe?
<lamont> cjwatson: remind me of update-excuses url?
<lamont> looking at why maas is still sitting in proposed (1.10 -> xenial)
<cjwatson> lamont: recommend> yes
<cjwatson> lamont: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> but you need http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt here
<cjwatson>     * amd64: maas-test
<lamont> cjwatson: as in recommend: never recommend universe? or it's ok to?
<cjwatson> lamont: as in main is meant to be closed under recommends
<lamont> ack
<lamont> cjwatson: what's the proces forgetting maas-test dropped from the archive?\
<cjwatson> lamont: file bug, subscribe ubuntu-archive
<cjwatson> lamont: I can't quite see what the actual problem here is - oh, is it that python-maas-client is dropped?
<lamont> yeah - and maas-test is deprecated and dead to us with python3
<tgm4883> cjwatson: I know. I was trying to find a way to get more users mythtv fixes builds
<tgm4883> currently, my plan is to bombard them with "you really should be using blah"
<spleak> Quick Q: Wondering about release date of 14.04.4. Wiki says today, that still holds?
<infinity> flocculant: Thanks in advance for the help with kubuntu.
<infinity> lamont: main is closed WRT recommends because we install them by default, and it would lead to different behaviour if you have universe enabled or not.
<infinity> (Hence why we don't make it a closed set for suggests, since those require purposeful action)
<lamont> right
<stokachu> what time today will the archive close?
<infinity> stokachu: If by "archive close" you mean feature freeze, somewhere vaguely around 2100 UTC.
<stokachu> yea feature freeze
<stokachu> ok cool thanks
<infinity> stokachu: Noted at the top of every ReleaseSchedule page: "Freezes normally happen around 2100 UTC time of the given date"
<stokachu> ah i see that now :)
<cyphermox> infinity: finishing the Changes report now...
<infinity> cyphermox: \o/
<infinity> cyphermox: Is the wiki r/w this morning?
<cyphermox> looks that way
<infinity> Shiny.
<cyphermox> can you confirm the last USN included was USN-2902-1 ?
<infinity> cyphermox: I have a call with Leann and $customer in 8 minutes, but after that I'll fix up the release notes, backup 14.04.3, create 14.04.4, and point to your summary page.
<infinity> cyphermox: 2903-1 (NSS)
<cyphermox> ah, cool
<cyphermox> I wasn't sure, so I went conservative
<cyphermox> the page will be at TrustyTahr/ReleaseNotes/ChangeSummary/14.04.4
<cyphermox> yah, it's saved now. I have a local copy of the whole file, if anything breaks.
<yofel> flocculant: we had one person testing kubuntu 14.04 yesterday or so. I just asked him again whether he had actually updated the iso tracker (I think he didn't)
<yofel> flocculant: thanks for the help!
<flocculant> yofel: welcome ofc - I did entire disk + livesession (just to make sure it worked) for both 64 and 32 bit
<flocculant> yofel: did you see ^^ - results on tracker anyway
<yofel> flocculant: didn't, thanks!
<flocculant> infinity: which one of you good guys is helping out next week for B1 ?
<infinity> flocculant: Not sure right now, but if no one's signed up, it might end up being me.  We'll see.
<flocculant> ok
<flocculant> I'll leave you in peace with trusty now :)
<smb> infinity, I am a bit despairing now. Since yesterday at some point (cannot pinpoint it exactly) sbuild of Xen in Xenial fails at a stage that has not changed (in fact the version currently in the archive now fails at the same stage). Manually entering the chroot and running the same command succeeds. And when building in my PPA succeeded as well I hoped the archive would succeed there as well. But sadly not.
<smb> https://launchpadlibrarian.net/240376638/buildlog_ubuntu-xenial-amd64.xen_4.6.0-1ubuntu3_BUILDING.txt.gz
<smb> I am at the end of my wits about what is going on there...
<wxl> what's the word, birds?
<infinity> smb: Colin's new sbuild upload should fix it.
<infinity> smb: Err, oh.  I didn't read your log. :P
<infinity> smb: I have no idea what's broken your build...
<infinity> jibel: We seem to be lacking any testing for server.
<infinity> davmor2: ^
<infinity> I'll do ppc/ppc64el.
<davmor2> infinity: don't the server team handle that normally
<infinity> davmor2: I like the theory, I'm unsure it's working in practice today.
<davmor2> infinity: well we'll just blame them when it doesn't work properly, I'll just tickle the last of these desktops that are running and then I'll have an install but it will be rough and ready as I say we don't normally touch server
<infinity> davmor2: Yeah, it doesn't need to be thorough, just a run-through with defaults and a reboot to make sure it boots/installs/reboots, and has the right kernel installed.
<infinity> davmor2: That's all I'm doing on ppc*
<infinity> davmor2: AFAIK, they're meant to have automated testing that is much more thorough, and they fill in the results, but I see no results filled in...
<infinity> smoser: Que pasa with 14.04.4 testing from your team?
<cyphermox> infinity: I can start some server install tests
<infinity> cyphermox: Sure.  I've got the powerpcs covered.
<cyphermox> ok
<cyphermox> 0218 is the right one?
<infinity> cyphermox: 217.1  There is no 28...
<infinity> Err, no 218
<infinity> cyphermox: http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20160217.1/
<cyphermox> I'm an idiot, I was looking at xenial
<davmor2> infinity: aren't server team the ones with access to s390x
<infinity> davmor2: A few of us do, not that that relates to trusty...
<davmor2> right tea is called so I will pick up when I get back
<Beret> I'd love to live where tea is called
<wxl> infinity: precise had 5 point releases. will trusty? or will 4 be it as with lucid?
<wxl> oh yikes looks like someone needs to update https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS too
<infinity> wxl: It'll have 5, with .5 including the lts-xenia kernel and X stacks.
<infinity> s/xenia/xenial/
<wxl> infinity: is that to be the *expected* trend from here on out?
<infinity> wxl: Yeah.
<wxl> infinity: thank you as always. :)
<infinity> Alright, core all tested.
<wxl> ok lubuntu's ready to go with release notes and everything
<wxl> well, i just got to uncommon the drafty bits
<wxl> ugh
<wxl> s/on/ent/
<smb> infinity, Somehow the only explanation for the error seen would be that the invocation of gcc only gets a partial file. But why is that always happening under sbuild control but not when using the exact same command (grep'ed from ps) when re-entering the exact same chroot environment that sbuild was using. I even threw away the whole build directory and re-created it with dpkg-source and still this would not break on
<smb>  the manual run.
<infinity> smb: Point me at the source package?
<smb> infinity, well as it is now, just do a pull-lp-source xen xenial
<infinity> smb: Oh, it's just the distro package?  Kay.
<smb> infinity, yeah. and since that now fails but did build in the past its at least some little proof that the "it was not me" has some reason
<davmor2> infinity: right last i386 test completed server images downloading now
<davmor2> infinity: right I have i386, amd64 and mac on the go now
<infinity> davmor2: Ta.
<davmor2> infinity: running check disk on amd64+mac, amd64 and i386 I'm just testing the installed selections are installed
<davmor2> infinity: done
<cyphermox> I have a preseed test running for server, the mandatory and run-one are already done for amd64.
<cyphermox> ah, well :D
<davmor2> cyphermox: yeah I got all excited and hit them with a hammer
<cyphermox> davmor2: good
<davmor2> infinity: so are we good?
<infinity> davmor2: Image-wise, yes.  Doing a bunch of pre-publishing and mirror bits and such now.
<infinity> And contemplating a quick lunch.
<davmor2> apparently the one guy is really desperate for us to know that intel 4500 gma gfx have an odd effect for him, but the intel part of my lenovo had no issues so no idea unfortunately
<infinity> Okay, mirrors syncing, lunch while that settles out, then announcements and web site updates.
<coreycb> infinity, can I get access to an s390 instance to test a dep8 failure?
<wxl> we there yet? :)
<infinity> coreycb: Possibly, but not by asking me.
<coreycb> infinity, ok doko maybe?
<doko> coreycb, that would be xnox
<spleak_> 14.04.4 out of the oven soon, I presume? :)
<coreycb> doko, ok thanks
<wxl> spleak_: that's the plan, but we';re waiting on the official go ahead.
<coreycb> xnox, I found an s390 machine
<wxl> infinity: thanks for the heads up about us going live!
<infinity> wxl: We're basically live.  I'm sending the announce now.
<wxl> infinity: you mean you just sent it :)
<infinity> Oh, was it moderated?
<infinity> Kay.
<wxl> luckily i'm on #ubuntu-news as they noticed it first :)
 * pleia2 on top of things
<pleia2> (it's on the fridge now)
#ubuntu-release 2016-02-19
<cjwatson> auto-sync switched to dry-run for Debian import freeze.
<wxl> oh, infinity, reminder to turn trusty dailies on again if you haven't already. since we are eventually leaving up to .5 :)
<infinity> wxl: Yes dear.
<infinity> cjwatson: Ta.
<wxl> infinity: hah, now you sound like me :)
<infinity> wxl: Done.
<wxl> infinity: thx, dear. :)
<flexiondotorg_> A new package synced from Debian yesterday, topmenu-gtk. I see it is in the Xenial proposed pocket. Is there something holding up its promotion to release?
<flexiondotorg_> infinity, cjwatson ^^^
<seb128> flexiondotorg_, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<seb128> lxpanel-plugin-topmenu/amd64 unsatisfiable Depends: lxpanel (>= 8)
<flexiondotorg_> Gah!
<flexiondotorg_> OK.
<flexiondotorg_> Thanks seb.
<seb128> yw
<flexiondotorg_> I'll bookmark that.
<seb128> dunno what's the status of lxpanel, launchpad seems to be down/erroring
<seb128> it's back
<seb128> https://launchpad.net/ubuntu/+source/lxpanel/0.8.1-1ubuntu2
<seb128> seems like somebody typoed 0.8 for 8?
<flexiondotorg_> Yeah, just saw that too.
<flexiondotorg_> I'll sort this in Debianland.
<doko> is britney stopped and needs manual action?
<infinity> doko: It last ran 5m ago, what makes you think it's stopped?
<doko> ohh, indeed, 5m ago
<doko> then waiting for the next publisher run
<xnox> doko, you can watch logs go by, to see if a run is in progress. sometimes it can take a while, in the log/ subdir.
<smb> infinity, Holy grep it's crap! I mean the other way round (my build failures of Xen seem to be caused by grep in the sbuild environment deciding in the middle of a file to switch from text to binary mode) [sorry for repeating but I though I started ranting here yesterday]
<smb> infinity, You can see the effect if you get the xen source from lp and then do a "LANG=C grep -v xxx xen/include/public/grant_table.h". (This would print the whole file in a Wily chroot but as of a few days ago in Xenial it only prints a few lines and then reports "Binary file ... matches")
<infinity> smb: Oh, that's all kinds of special.
<smb> Only hope for me is that I can work around this oddness by forcing grep into --text mode at one invocation
<infinity> smb: Does the file have unprintable chars?
<smb> infinity, You mean the ugly version of special, don't you? :)
<infinity> smb: I feel like this warrants a grep bug report to at least investigate further if grep's buggy or working as designed.
<smb> infinity, it has a few odder characters (though they print)
<smb> infinity, agree, will file one
 * infinity goes back to bed -- morning in Santa Cruz will come all too soon.
<smb> The fun part is that it acts again "normal" when LANG=en_US.UTF-8 ... really not sure whether bug of feature... But then I'd expect grep to decide before it prints portions of the file
<smb> morning always comes too soon
<infinity> smb: Oh, well, the simple workaround could just be to force LANG=C.UTF-8 in debian/rules.
<smb> infinity, that or as I said use "grep --text ..."
<infinity> smb: I had a master plan to switch buildds to C.UTF-8 this cycle anyway, which I still intend to do *if* we can land it and rebuild test the world in the next couple of weeks.
<infinity> Any later, and I'll have to defer.
<infinity> But no problem if some builds do it prematurely.
<infinity> s/builds/packages/
<smb> Ah ok. Hm, can try that as well
<doko> infinity, hmm, ucommon (6.4.4-2 to 6.4.4-2build1) still listed in update_excuses, -2ubuntu1 should be there
<flexiondotorg_> infinity, Any chance the Ubuntu MATE Base and Xubuntu Base stuff can be merged?
<infinity> flexiondotorg_: I'll be looking at that when I get home from this sprint.
<infinity> doko: Long publisher run is long.  I assume it'll sort itself on the next run.
<cjwatson> doko: The publisher only just finished its 2h40m run about two minutes ago.
<cjwatson> Chances of proposed-migration having caught up with that yet are pretty slim.
<flexiondotorg_> infinity, Great. WHat you sprinting on?
<infinity> flexiondotorg_: snappy and other things.
<doko> ta
<infinity> flexiondotorg_: I get home Saturday, be sure to annoy me later.
 * flexiondotorg_ like Snappy very much.
<rtg> please reject linux-raspi2 4.4.0-1001.2 from -proposed. It has some boot issues.
<xnox> hi
<xnox> there seem to be ppc64el autopkgtest machines missing.
<xnox> could somebody please hint juju-core through?
<xnox> we really really really need it for s390x
<teward> can someone check and see if the upload.ubuntu.com (where dput sent the last nginx upload) is actually having its items processed?  I just uploaded about 15 minutes ago a bugfix only upload that won't need an FFe, (it fixes several typos and provides accurate paths for php fpm in Xenial in a default config file, but doesn't change features) but I'm not seeing an acknowledgement from the system
<teward> it just picked it up a few minutes ago, so nevermind :)
<cjwatson> teward: yeah, the processor didn't get automatically started on reboot for some reason
<teward> cjwatson: related to the build farm issues, or a different one?
<teward> in any case my upload finally got through heh
<cjwatson> teward: only related in the sense that both problems were separately triggered by rebooting that host
<teward> ah okay
<lamont> oh hai.  can I sweet talk some archive admin into nuking the package as requested in bug 1547087 ?
<ubot5> bug 1547087 in maas-test (Ubuntu) "Please drop maas-test from the archive" [Critical,New] https://launchpad.net/bugs/1547087
<slangasek> lamont: done
#ubuntu-release 2016-02-20
<lamont> thanks!
#ubuntu-release 2016-02-21
<flocculant> cyphermox: am I right in assuming that ubiquity " Redesign the prepare screen for less clutter." is lose the internet warning and the disk size warning? note - I saw the disk size warning when it was too small :)
<slangasek> unblocked getting the new phpunit unstuck from -proposed, so it's now compatible with php7; there may be various test failures in update_excuses that now want retried
<flexiondotorg_> Is infinity about yet?
<flexiondotorg_> He definitely said I should annoy him ;-)
<infinity> flexiondotorg_: I forget what you were annoying me about.  Minimal cdimage merges for xu/mate?
<Ukikie> ...Alive on a weekend? :3
<flexiondotorg_> infinity, Yes please :-)
<flexiondotorg_> infinity, Would be good for testing in Beta 1.
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-base/+merge/284435
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/ubuntu-mate-base/+merge/284432
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate-base/+merge/284433
<doko> so gnutls is coupled with bind9 and linux; removed netexpect, trying to get filezilla done
#ubuntu-release 2017-02-13
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [s390x] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [ppc64el] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [i386] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnocchi [amd64] (zesty-proposed/universe) [3.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [powerpc] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [i386] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [armhf] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: case [amd64] (zesty-proposed/universe) [1.5.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [ppc64el] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [amd64] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [ppc64el] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [amd64] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [i386] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pydenticon [amd64] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [amd64] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: libdist-zilla-config-slicer-perl [amd64] (zesty-proposed/universe) [0.201-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinx-celery [amd64] (zesty-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [i386] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-karlseguin-expect [amd64] (zesty-proposed/universe) [1.0.1+git20160716.12.5c2eadb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [armhf] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [i386] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [arm64] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [s390x] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [i386] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [i386] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [arm64] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [ppc64el] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [amd64] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [ppc64el] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [amd64] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [ppc64el] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [armhf] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-goamz [amd64] (zesty-proposed/universe) [0.0~git20160206.0.f0a21f5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [armhf] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: gpiozero [armhf] (zesty-proposed/universe) [1.3.1.post1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [s390x] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: gpiozero [arm64] (zesty-proposed/universe) [1.3.1.post1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [s390x] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [armhf] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [arm64] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [s390x] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openoverlayrouter [powerpc] (zesty-proposed/universe) [1.1.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [powerpc] (zesty-proposed/universe) [1.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [arm64] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [arm64] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [armhf] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [powerpc] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sysvinit [powerpc] (zesty-proposed/main) [2.88dsf-59.9] (core)
-queuebot:#ubuntu-release- New binary: pandoc-citeproc-preamble [s390x] (zesty-proposed/universe) [1.2.3] (no packageset)
-queuebot:#ubuntu-release- New binary: sia [powerpc] (zesty-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [arm64] (zesty-proposed/universe) [1:5.0~svn294894-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: giac [amd64] (zesty-proposed/universe) [1.2.3.25+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- New: accepted giac [amd64] (zesty-proposed) [1.2.3.25+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [powerpc] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [arm64] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [powerpc] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted python-pyflow [powerpc] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted sia [armhf] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted sia [s390x] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted sysvinit [powerpc] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [arm64] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [armhf] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted sia [arm64] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted sysvinit [arm64] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [s390x] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted sia [powerpc] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [s390x] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted case [amd64] (zesty-proposed) [1.5.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-karlseguin-expect [amd64] (zesty-proposed) [1.0.1+git20160716.12.5c2eadb-1]
-queuebot:#ubuntu-release- New: accepted gpiozero [armhf] (zesty-proposed) [1.3.1.post1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [i386] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [s390x] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [arm64] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [i386] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [amd64] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [ppc64el] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-goamz [amd64] (zesty-proposed) [0.0~git20160206.0.f0a21f5-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-config-slicer-perl [amd64] (zesty-proposed) [0.201-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [ppc64el] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [armhf] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pandoc-citeproc-preamble [i386] (zesty-proposed) [1.2.3]
-queuebot:#ubuntu-release- New: accepted python-pyflow [amd64] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [armhf] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [ppc64el] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted sia [amd64] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted sia [ppc64el] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted gpiozero [arm64] (zesty-proposed) [1.3.1.post1-1]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [amd64] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pydenticon [amd64] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [i386] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted sia [i386] (zesty-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted sysvinit [amd64] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted sysvinit [i386] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted sysvinit [s390x] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [armhf] (zesty-proposed) [1:5.0~svn294894-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [arm64] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New: accepted sphinx-celery [amd64] (zesty-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted sysvinit [ppc64el] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted openoverlayrouter [ppc64el] (zesty-proposed) [1.1.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted sysvinit [armhf] (zesty-proposed) [2.88dsf-59.9]
-queuebot:#ubuntu-release- New: accepted python-pyflow [s390x] (zesty-proposed) [1.1.14-1]
-queuebot:#ubuntu-release- New binary: golang-github-karlseguin-ccache [amd64] (zesty-proposed/universe) [2.0.2+git20161222.2.12c7ffd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [armhf] (zesty-proposed/main) [1:5.3.0~rc3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [i386] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [powerpc] (zesty-proposed) [1:5.3.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted zaqar-ui [amd64] (zesty-proposed) [1.0.0~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnocchi [amd64] (zesty-proposed) [3.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-karlseguin-ccache [amd64] (zesty-proposed) [2.0.2+git20161222.2.12c7ffd-1]
-queuebot:#ubuntu-release- New binary: mkchromecast [amd64] (zesty-proposed/universe) [0.3.7+git20170130-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-proposed/universe) [4.4.0.1039.31 => 4.4.0.1046.38] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-snapdragon (yakkety-proposed/universe) [4.4.0-1039.43 => 4.4.0-1046.50] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-proposed) [4.4.0.1046.38]
-queuebot:#ubuntu-release- Unapproved: accepted linux-snapdragon [sync] (yakkety-proposed) [4.4.0-1046.50]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- New binary: autobahn-cpp [amd64] (zesty-proposed/universe) [0.2.1-1ubuntu1] (no packageset)
<ginggs> apw, Laney: FYI I skipped the failing test in nodejs and sent patches to Ddebian. Interestingly, node-isexe suddenly developed a test failure, due to node-tap update. Node-tap is an autopkgtest Depends, not a package Depends, so node-isexe didn't get triggered when it updated.
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [111.0.0-0ubuntu1~14.04.0 => 140.0.0-0ubuntu1~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.8 => 1:2.5+dfsg-5ubuntu10.9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (yakkety-proposed/main) [1:2.6.1+dfsg-0ubuntu5.2 => 1:2.6.1+dfsg-0ubuntu5.3] (ubuntu-server, virt)
<jbicha> please reject recipes/zesty, I will re-upload later as src:gnome-recipes
-queuebot:#ubuntu-release- New: rejected recipes [source] (zesty-proposed) [0.12.0-0ubuntu1]
<apw> jbicha, ^ done
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.2] has been marked as ready
<zul> can we get an SRU ack? please for https://bugs.launchpad.net/ubuntu/+source/aodh/+bug/1645772
<ubot5> Ubuntu bug 1645772 in ironic (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Incomplete]
<jbicha> apw: is looking at bug 1652537 on your to-do list?
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
<davmor2> infinity_: so are we good with the image I'm testing currently?  Amd64 seems okay working through I386 currently
-queuebot:#ubuntu-release- New binary: radiant [amd64] (zesty-proposed/none) [2.7+dfsg-1] (no packageset)
<Laney> ginggs: It does do that for source packages that have been built with dpkg-source â¥ 1.18.8
<Laney> (Testsuite-Triggers)
<ginggs> Laney: oh, nice!
<infinity> davmor2: No, it has one critical bug that will need a respin for, but we can do light smoketesting and spot-checks on that respin if we have deep testing on the current image.
<davmor2> infinity: is that one you mentioned Friday for grub signed?
<infinity> davmor2: s/grub-signed/linux-signed/ but yes.
<davmor2> infinity: okay thanks
<mapreri> I notice that diffoscope's autopkgtest takes nearly 3 hours on armhf (the last one even timeouted!!) but less than 20 minutes on the other archs.
<mapreri> What's so special about armhf that is so slow?
<mapreri> I'm now seeing one test that is stuck there since ~half an hourâ¦
<mapreri> Laney: â
<nacc> is anyone already tracking down the libreoffice failures in z-p? it seems like ant and liborcus-0.11-0 aren't being picked up (at least) as build-deps?
<xnox> nacc, i would assume SweetShark is
<nacc> xnox: ok, thanks
<teward> infinity: can I perhaps prod you to check the nginx SRU for Xenial and Yakkety?  SOme major HTTP/2 fixes from upstream that prompt a version bump...
<infinity> teward: Not today, sorry.
<teward> OK
<teward> just thought I'd check :)
<teward> *returns to poking the nginx merge-in-progress*
<mapreri> teward: you uploaded them 2 days ago only.  IMHO pinging people after so little is kinda pushyâ¦
<mapreri> And the weekend was in the middleâ¦
<teward> eh, good point, i'm a little impatient sometimes :P
<nacc> Laney: I think I'm missing some basic knowledge on libaws but I saw you submitted at least one rebuild of it (late 2016) to regenerate the .ali files. Do we need to do that again (the current 'regression's in excuses are for ppc64el and s390x specifically and all refer to .ali files being obsolete). Annoying, at least for src:liblog4ada, the logs of the success seem to be gone
<nacc> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/ppc64el/libl/liblog4ada/20160921_151941@/log.gz)
<nacc> doko: --^ you may know as well, as it seems like the 'obsolete' .ali files come from gcc-6?
<nacc> hrm, running the autopkgtest for liblog4ada against the release pocket also fails the same way...
<Laney> nacc: I don't know, I never got to the bottom of that
<Laney> it seemed to partially work but some arches never got there and I gave up
<nacc> yea -- but now libaws seems to be blocking a bunch of stuff in -proposed
<Laney> Right
<Laney> I'm basically saying that it needs looking at
<Laney> :/
<Laney> Probably reading out to a Debian ada person for guidance is a good way forward
<nacc> Laney: ack, I'll look at doing that today
<Laney> nacc: I remember finding an ada policy which sort of helped but didn't get me all the way there
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
<nacc> Laney: thanks, I'll look for that
-queuebot:#ubuntu-release- Unapproved: unity-control-center (xenial-proposed/main) [15.04.0+16.04.20160705-0ubuntu1 => 15.04.0+16.04.20170213.1-0ubuntu1] (ubuntu-desktop) (sync)
<jderose> infinity: when are you now expecting 16.04.2 to be released?
 * valorie is also listening for that information
<infinity> jderose: Expecting to finish mangling all the bits that broke with the HWE introduction for images tomorrow and a release on Thursday.
<infinity> After I find some sort of food.
<infinity> For desktop images, this should basically amount to just fixing that one linux-signed autoremoval bug and no other changes, so light smoketesting should get the job done.
<infinity> (If you find other grave bugs, please escalate ASAFP, so we can address them)
<valorie> infinity: the Kubuntu team did a lot of intensive testing on the "no auto-resize option" bug last night
<valorie> wxl may have more input on the BR later today
<infinity> That's not a regression from 16.04.1, is it?  It seemed to me it's just "working as designed" when there's not enough space on the target?
<flexiondotorg> infinity, I'd agree with that.
<infinity> (Granted, it could behave better, and I think it's probably crap UI design to not show the option at all as opposed to, say, greying it out with an explanation, but still not a regression)
<flexiondotorg> infinity, I've been head down in other stuff today. Is the release still on for today?
<infinity> flexiondotorg: Read 10 lines up.
<valorie> infinity: we had a tester who had a HUGE disk
<valorie> huge and empty
<infinity> Empty, except for an installed OS, I assume.
<valorie> anyway, I'll let those who were doing the work speak up about it
<valorie> yes
<flexiondotorg> infinity, Connecting from foreign computer. No backlog :-(
<infinity> Either way, if one can find a situation where it's clearly "wrong", have them check if 16.04/16.04.1 are similarly wrong.
<infinity> Cause yeah, bugs exist.  But we're only focussed on ones that make .2 somehow worse than .1
<valorie> sure
<infinity> flexiondotorg: RCs tomorrow, release Thursday.  If I can escape to get food and get back to my keyboard.
 * infinity escapes.
<flexiondotorg> Thanks infinity.
 * infinity unescapes for one more comment.
<infinity> valorie: Ultimately, I think this (and a few other new bugs) is fallout from my enlisting the kernel team's help to test.  They're very.  Uhm.  Thorough.
<infinity> valorie: So yay, more bugs, most of which we should target to .3, but I suspect none of them are new, just newly-noticed.
<valorie> right
<dmj_s76> Thorough is good!  +.1
<tsimonq2> infinity: So should we expect respins?
<tsimonq2> infinity: (meaning global respins)
<infinity> tsimonq2: Yes.
<tsimonq2> infinity: Alright, thanks.
<wxl> infinity: what exactly will we need to be smoketesting? or we don't know yet?
<asdblefeke> Hello. What's with ubuntu 16.04.2 release?
<asdblefeke> where can we expect *.2 iso to be released? Cant find any news on the Internet.
<tsimonq2> asdblefeke: Thursday.
<wxl> infinity: ^^ you may want to send an email to ubuntu-release with the information on the situation
<asdblefeke> tsimonq2: thank you
<dannf> infinity: i don't see ubuntu server isos on the 16.04.2 tracker, while i do in 16.04.1. is that expected?
 * dannf guesses they are still in progress after re-reading the wed update
#ubuntu-release 2017-02-14
<k1l_> hi, is there a new target date for the 16.04.2 release? we keep getting questions about the release in #ubuntu since the ML did mention friday or monday.
<tsimonq2> k1l_: Thursday.
<tsimonq2> k1l_: Adam said something earlier. ;)
<k1l_> alright
<blomstertj> I had a question about this 16.04.2 HWE thing
<blomstertj> From my understanding if you would install 16.04.2 from the ISO your kernel would be 4.8.  And if you were running 16.04.1 and upgrade to 16.04.2 (which my system is) the new kernel will NOT be upgraded.  So my question is when 16.04.3 comes out will my kernel be upgraded?
<slangasek> blomstertj: https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack should explain the current setup.  Also, if I'm not mistaken the plan is that installing 16.04.2 still gives you the 4.4 kernel by default
<blomstertj> slangasek: I have read that article but I'm just not comprehending that.  I'm not really familiar with how HWE stacks work because I have not run ubuntu long term
<cyphermox> slangasek: are you currently trying to create the 16.04.2 changes summary?
<blomstertj> So you have to manually enable the HWE stack?  The way it was worded seemed like after 16.04.2 that was changing that
<k1l_> blomstertj: you have to enable the hwe stack once with installing that metapackage.
<blomstertj> I was just wondering if 16.04.2 will by default use this Rolling model instead of never upgrading the kernel throughout the life of the LTS release
<slangasek> cyphermox: I am not curretnly
<k1l_> blomstertj: then 16.04 will still reveive kernel updates to the 4.4 kernel it was shipped with. but it will not upgrade the kernel automatically to the other kernel bases. it will stay on the GA kernel like told on the wiki page
<cyphermox> ok, just trying to figure out who might have started but not committed changes, it refuses to copy
<blomstertj> k1l_: The point releases will still stay on GA kernel as well then?
<blomstertj> k1l_: I say that because of this line: Desktop installs will continue to offer the HWE Stack option only and default to it.
<k1l_> blomstertj: when you install 16.04 and just run the updates it will become 16.04.2 by that and doesnt change something on the kernel at all
<blomstertj> k1l_: That's what I thought.  If you install 16.04.2 from the ISO image is that still the case?
<k1l_> blomstertj: that is when you run the 16.04.2 iso to make a complete new install. that is due to hardware support
<blomstertj> k1l_: So if you upgrade to 16.04.2 from an earlier release you stay on GA kernel.  But if you install 16.04.2 and on from an ISO you will be on HWE?
<k1l_> yes. the reason for that was the samsung notebooks that got brocken when run with an old kernel. from that on it always uses the hwe kernel on the iso. but not when you already are installed. since then the hardware works already.
<blomstertj> k1l_: I get it.  Thanks for the explanation
<k1l_> np
<b-yeezi> infinity, I was told by tsimonq2 to ping you regarding an issue I ran into running 16.04 and HWE
<b-yeezi> when It upgraded to kernel 4.8-36, I ran into this bug: ttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656618
<b-yeezi> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656618
<ubot5> Ubuntu bug 1656618 in linux (Ubuntu) "Any key pressed opens shutdown dialog (Asus X205TA)" [Medium,Confirmed]
 * tsimonq2 nods
<b-yeezi> I can't even boot into a previous kernel now.  error: symbol `grub_efi_secure_boot'  not found
<cyphermox> that doesn't look like a kernel issue, that rather looks like you have the wrong modules installed for grub
<b-yeezi> I got the same issue on a fresh install of 16.10 as well
<cyphermox> you should file a bug and include in it the logs from the installer (/var/log/installer/*) before you reboot to the installed system.
<b-yeezi> ok. I'll do that
-queuebot:#ubuntu-release- New binary: pygresql [i386] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [ppc64el] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [amd64] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [arm64] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [s390x] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [armhf] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygresql [powerpc] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: juju-core (trusty-proposed/universe) [1.25.6-0ubuntu1.14.04.1 => 1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: juju-core (trusty-proposed/universe) [1.25.6-0ubuntu1.14.04.1 => 1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1] (no packageset)
<apw> it seems unlikely that that version number is intended for trusty?
-queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (trusty-proposed) [1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1]
-queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (trusty-proposed) [1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1]
<apw> ^ not intended for the archive
-queuebot:#ubuntu-release- New: accepted mkchromecast [amd64] (zesty-proposed) [0.3.7+git20170130-1]
-queuebot:#ubuntu-release- New: accepted radiant [amd64] (zesty-proposed) [2.7+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: libappindicator (xenial-proposed/main) [12.10.1+15.04.20141110-0ubuntu1 => 12.10.1+16.04.20170213.2-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New binary: python-scrapy [amd64] (zesty-proposed/universe) [1.3.0-1~exp2] (no packageset)
<Laney> sil2100: Hey - if you've got a minute, could you review gst-libav/xenial UNAPPROVED please?
<Laney> It's a regression in -updates and I feel bad leaving it there
<sil2100> Laney: hey! Let me try taking a quick look in a minute
<Laney> thanks!
-queuebot:#ubuntu-release- Unapproved: libodb (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
<xnox> apw, if you can think of better version numbers in this case, I am happy to reupload something better. Above is constrained by 2.4.0-1 in both xenial & yakkety release; with 2.4.0-1build1 in zesty.
-queuebot:#ubuntu-release- Unapproved: libodb (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
<xnox> and this one too
-queuebot:#ubuntu-release- Unapproved: unity-control-center (xenial-proposed/main) [15.04.0+16.04.20160705-0ubuntu1 => 15.04.0+16.04.20170214-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20161003.1-0ubuntu2 => 15.04.0+16.10.20170214-0ubuntu1] (ubuntu-desktop) (sync)
<jbicha> in case there's an archive admin who's not subscribed to the ubuntu-release list, I'll repeat that I'd appreciate it if mozjs38 were reviewed and accepted into zesty soon since it blocks gnome-shell 3.24
<xnox> jbicha, just use webkit </iTroll> =)
<jbicha> xnox: do I hear a volunteer? :)
<xnox> jbicha, hahaha
<apw> jbicha, are we going to see that in debian too ??
<jbicha> yes, it's required for Debian to package GNOME 3.24
<apw> jbicha, and we are using a common orig with them
<jbicha> GNOME does plan to move to mozjs45 and then mozjs52 (when it's released), maybe GNOME 3.26 or so
<jbicha> I have been in contact with the mozjs24 maintainer (a few weeks ago), but if he doesn't want to maintain it then it'll probably end up being the Debian GNOME team
<jbicha> but yes I will forward my packaging to Debian
<sil2100> Laney: ok, checked and approved o/
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [source] (xenial-proposed) [1.8.3-1ubuntu0.2]
<Laney> thanks!
-queuebot:#ubuntu-release- New: accepted mozjs38 [source] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
<apw> jbicha, having reviewed it three times now, i think i am as happy as i can be ^^
<jbicha> 3 times?
<apw> jbicha, i reviewed it before not just today
-queuebot:#ubuntu-release- New: accepted pygresql [amd64] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [armhf] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [powerpc] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [s390x] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [arm64] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [ppc64el] (zesty-proposed) [1:5.0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygresql [i386] (zesty-proposed) [1:5.0.3-1ubuntu1]
<apw> wasn't sure, thought about it some more, asked you questions ... now happy
-queuebot:#ubuntu-release- New: accepted python-scrapy [amd64] (zesty-proposed) [1.3.0-1~exp2]
<jbicha> mozjs is an annoying package (it's intentionally not in Ubuntu main) but if we're going to use it, it's better to use a more recent version
<apw> jbicha, as it is a separate package space for each version, and us used an origin with a very specific version, most wrongness can be fixed if debian goes a different route
-queuebot:#ubuntu-release- New binary: mozjs38 [i386] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs38 [ppc64el] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
<LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/12005643
<LocutusOfBorg> failing now
-queuebot:#ubuntu-release- New: accepted autobahn-cpp [amd64] (zesty-proposed) [0.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: mozjs38 [s390x] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs38 [powerpc] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
<LocutusOfBorg> some update broke it
<LocutusOfBorg> meld of the build logs shows just a few packages
-queuebot:#ubuntu-release- New binary: mozjs38 [amd64] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs38 [arm64] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs38 [armhf] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
<jbicha> LocutusOfBorg: yes I think Laney is working on it now, thanks
<jbicha> I don't think it's a change in build-dependencies, perhaps just depends on how overworked the LP builder is
-queuebot:#ubuntu-release- New: accepted mozjs38 [amd64] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [i386] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [ppc64el] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [arm64] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [s390x] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [powerpc] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs38 [armhf] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
<LocutusOfBorg> jbicha, don't know I retried it a few times, and it is failing also in ppa
<LocutusOfBorg> I remember having the same issues when I transitioned libpng1.6
<ginggs> would someone please remove the armhf and powerpc binaries for theano?  it no longer builds on these architectures
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (zesty-proposed/universe) [17.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu3~16.10.0 => 20160930-0ubuntu4~16.10.0] (ubuntu-cloud)
<Odd_Bloke> An ACK of ^ in to -proposed so I can test it would be much appreciated.
<acheronuk> hi. I suppose packages in Xenial archive, even if utterly useless as they only work with plasma4 found in trusty and before, are destined to just stay there?
<LocutusOfBorg> acheronuk, probably yes
<LocutusOfBorg> but remove them from zesty :p
-queuebot:#ubuntu-release- New binary: python-scrapy-djangoitem [amd64] (zesty-proposed/universe) [1.1.1-1] (no packageset)
<acheronuk> LocutusOfBorg: yep, it was removed in Yakkety actually. just had someone moaning slightly on a forum that it was in zesty archive, but of no use.
 * acheronuk shrugs
<acheronuk> *Xenial archive I meant
<camako> Can I get a core dev to publish bileto #2435?
<camako> Please?
<xnox> camako, you should be pinging trainguards on #ubuntu-ci-eng
<camako> xnox, I am confused ... I 've previously been told by the trainsguards that I need to ask a core dev. :-)
<xnox> camako, this is not a place for core devs =)
<xnox> camako, this is more about ~ubuntu-sru | ~ubuntu-archive teams =)
<camako> xnox, ack, sorry about the noise :-)
<xnox> camako, most coredevs are in #ubuntu-devel and bileto friendly coredevs are in #ubuntu-ci-eng
<camako> gotcha
<camako> I did get sil on the ci-eng to help me
<xnox> camako, when things get stuck in proposed migration; or have NEW packages review; this channel is a good place to ask =)
<sil2100> Yeah, for Bileto it's best to try on #ubuntu-ci-eng, many of the trainguards are core-devs anyway
<camako> I see.. Thanks for patiently explaining :-)
<sil2100> But #ubuntu-devel can be a good place as well ;)
<sil2100> Still, some core-devs can not know how to use Bileto ;p
<camako> O I see. I'll stick with ci-eng from now on
<ginggs> would someone please 'force-badtest python-cobra/0.5.9-1/armhf' ? tests depend on python-pandas which is no longer installable on armhf
<apw> ginggs, will those tests be removed in the next upload, or is there a plan to fix python-pandas ?
<ginggs> apw: will which tests be removed?  i don't of anyone actually working on fixing pandas for architectures where it was removed
<nacc> but pandas is current built for 'all', shoudl it be rebuilt to not exist on some architectures?
<apw> welll i was asking if we were going to fix python-cobra to not run the test, or the python-pandas so it is installable
<nacc> right, it seems like this is a 'permanent' issue -- so we should fix it in the src(s)?
<ginggs> nacc: how do you propose to fix it in src?
<nacc> ginggs: i have no idea, but it seems like you skip the test in python-cobra on a particular arch or you drop the dependency on pandas on a specific arcch, or some other choice
<ginggs> isn't it britney that should be told not to run the test (or, at least ignore the failure)
<apw>  we dont want to skip test over and over, a one off because they broke is fine, but if the test in a package is invalid we should stop running it
<apw> bexause we can only ignore the whole suite on an arch, not individual tests
<nacc> ginggs: my thinking was what apw said, you don't want to have to ask someone to manually skip on every upload or every dependency-run
<apw> it is a blunt tool
<ginggs> hmmm
<nacc> it also seems bad if pandas is in the release pocket for armhf but uninstallable there?
<nacc> did a dependency change?
<ginggs> apw: look in p.itti's hints - please replace 'force-badtest python-cobra/all/s390x' with 'force-badtest python-cobra/all/armhf' - s390x is fixed now, armhf broken
<ginggs> nacc: no, new upstream pandas broke on a few (most) architectures
<nacc> ginggs: oh i see
<nacc> ginggs: but it's already in the release (so it had to work at some point?)
 * nacc will shut up, just confused :)
<Laney> arch:all packages don't have to be installable everywhere (just amd64)
<nacc> Laney: ah, that's it then :)
<Laney> presumably the arch-specific ones got removed at some point
<ginggs> Laney: yes, python-pandas-lib and python3-pandas-lib and their reverse-dependencies were removed (LP: #1643151)
<ubot5> Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,Fix released] https://launchpad.net/bugs/1643151
<apw> ginggs: this isn't about not knoeing how to disable those tests, it is about it being stupid to run them if they are broken alwaya
<Laney> Not sure how proposed-migration can nkow that
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (yakkety-proposed) [140.0.0-0ubuntu1~16.10]
-queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.5-0ubuntu1~ubuntu14.04.1 => 2.0.6-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [140.0.0-0ubuntu1~16.04.1]
<apw> Laney: indeed it cannot, other than by a different hint, but that is why broken tests should be removed
<Laney> apw: You're saying it should get an 'if not armhf' thing in the tests?
<apw> or the individual test if that is possible,
<apw> the only time it feels right to himt forever
<nacc> could we get an AA to look at LP: #1662654 ?
<ubot5> Launchpad bug 1662654 in tomcat8 (Ubuntu) "Please remove tomcat 8.5 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1662654
<apw> is if this is an unmodified debian package where thos would be the only delta
<apw> Laney: though you were keen we didnt hint overly, whst is your criteria
<ginggs> is it possible to 'if not armhf' in autopkgtests?
<nacc> LP: #1516959 seems to imply it is
<ubot5> Launchpad bug 1516959 in autopkgtest (Ubuntu) "debian/test/control: negative architecture restictions are rejected in dependencies" [Medium,Fix released] https://launchpad.net/bugs/1516959
<ginggs> apw: let's pretend pandas had never been installable on armhf, the python-cobra test would still always be run, the only difference is the result would be 'always failed' instead of 'ignored failure'
<ginggs> nacc: thanks
<nacc> ginggs: it's not clear to me if that is for specifying the test dependencies on a given arch, though (maybe that would be sufficcient?)
<nacc> ginggs: as opposed to saying a particular test is arch-dependent
<apw> true but it could go green, and then be useful, once it is ignored it is dead
<Laney> I think it's strange to encode a build failure in the tests like that, if someone's performed archive operations to make the package migratable
<Laney> What you want here I think is to be able to make something go back to always failed
<Laney> But we don't have that ATM
<apw> Laney: do we have that?
<apw> as i agree fhat is really what we want
<Laney> Well
<Laney> You could go in and hack the swift stuff to delete the result(s) which passed
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.6-0ubuntu1~14.04.1]
<Laney> That wouldn't be that hard
<Laney> But there's no operation to do it
<Laney> (Also then it might be necessary to delete pending.json on snakefruit to make britney re-download the results, don't remember offhand)
<apw> ...
<Laney> :D
<apw> i think then i can add that, but with some kind of header to trigger it to be deleted if we have a green ever
<apw> (lost irc briefly)
<apw> add that hint
<Laney> Worth a bug about making this better
<Laney> Maybe it would be a new reset the ratchet type of hint
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-backports/main) [2.0.6-0ubuntu1~ubuntu14.04.1 => 2.0.7-0ubuntu1~14.04.1] (ubuntu-server)
<apw> yeah
<apw> ginggs, ok done
<ginggs> thanks apw !
<ginggs> apw: except you made a type in your hints file
<ginggs> a typo, even
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu3~16.04.0 => 20160930-0ubuntu3~16.04.1] (ubuntu-cloud)
<Odd_Bloke> There are gce-compute-image-packages packages waiting in the yakkety and xenial queues; ACKs would be much appreciated.
<Odd_Bloke> (slangasek: ^)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.26 => 2.27] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.26+16.10 => 2.27+16.10] (no packageset)
<sergiusens> RAOF: are you around to accept these? ^^
<sergiusens> hmm, maybe slangasek, can you? Don't thing R A O F is on yet
<slangasek> sergiusens, Odd_Bloke: looking
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.27+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.27]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [140.0.0-0ubuntu1~14.04]
<slangasek> Odd_Bloke: the debdiff also contains a change to the perms on /dev/console, which seems unlikely to be related to the performance issue described in the bug report; mind spelling this out in the bug description?
<slangasek> can someone explain to me why there are autopkgtests being reported for "linux/blacklisted"?
<sergiusens> thanks!
<nacc> slangasek: would you be able to give an advice on LP: #1662654? the tomcat 8.5 in proposed is breaking dogtag-pki which is then gating many other packages in z-p.
<ubot5> Launchpad bug 1662654 in tomcat8 (Ubuntu) "Please remove tomcat 8.5 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1662654
<slangasek> nacc: why is it in -proposed again?  I'm sure someone removed it already
<slangasek> or maybe I looked at the wrong package name hmm
<slangasek> nacc: ok, sorry, I thought this was done already
<slangasek> nacc: I think I'll probably remove it regardless, under the circumstances; but for rationale it's good to understand if the problems are intrinsic to this tomcat8 package, or if it's an incompatibility with other packages which haven't yet been updated for compat with 8.5
<nacc> slangasek: ack, I can update the bug
<nacc> slangasek: it's a compatibility issue aiui, with 8.5 specifically
<nacc> err, that's poorly phrased
<nacc> it's a compatibility issue for other packages with tomcat 8.5
<nacc> which we will pursue in 17.10, but for 17.04 we want to stay on 8.0
<slangasek> nacc: package removed
<slangasek> bug update timing out in lp ;P
<nacc> slangasek: thank you -- will i need to manually rerun various tests in excuses? or will they trigger on that change?
<slangasek> nacc: they'll need manually retriggered
<nacc> slangasek: ack, thanks!
<nacc> tjaalton: jgrimm: --^
<jgrimm> \o/
<jgrimm> nacc, could you retrigger dogtag-pki (under nspr) for me when its appropriate. I don't have rights. :)
<nacc> jgrimm: ack, it's on my list
<jgrimm> thanks sir
<nacc> slangasek: i assume there is some time delay while the package is actually deleted? (e.g., rmadison reports it still present)
<tjaalton> nacc: excellent
<slangasek> nacc: yes. rmadison reads from a database, which is rebuilt from the archive, which publishes roughly once every half hour
<nacc> slangasek: ack, thanks!
<nacc> tjaalton: i'll start retrying tests -- and i'll redo those dogtag-pki builds, if that's ok with you?
<tjaalton> nacc: sure, go ahead
<tjaalton> did resteasy get synced already?
<nacc> tjaalton: thanks
<nacc> tjaalton: i think i saw it in excuses
<nacc> tjaalton: yeah, 3.1.0-2 is in z-p, blocked by dogtag-pki
<tjaalton> ah, right
<tjaalton> that too :)
<nacc> tjaalton: iiuc, the new dogtag-pki should fix this all up, along with retriggers as necessary
<tjaalton> actually build tomcatjss first
<tjaalton> oh sorry
<nacc> tjaalton: it needs a rebuild?
<tjaalton> it's not on excuses
<tjaalton> nah
<nacc> tjaalton: ack
<nacc> tjaalton: hrm, dogtag-pki still failed to build (resteasy issue still?): https://launchpadlibrarian.net/306421401/buildlog_ubuntu-zesty-amd64.dogtag-pki_10.3.5-7_BUILDING.txt.gz
<nacc> tjaalton: bah still picked up 8.5, i'll be more patient :)
<tjaalton> hehe
<nacc> tjaalton: sorry for the noise :)
<tjaalton> np
<nacc> tjaalton: does dogtag-pki need an update to use libresteasy-legacy.jar explicitly?
<tjaalton> nacc: oh right, i'll deal with it tomorrow
<nacc> tjaalton: i'm happy to try and do it -- if you can give a hint, I think I see how it's done. is it an update to the CMake stuff?
<nacc> tjaalton: actually, hrm, it seems like the build of libresteasy-java does not contain a resteasy-legacy.jar at all
<tjaalton> huh
<tjaalton> -rw-r--r-- root/root    256434 2017-02-14 10:41 ./usr/share/java/resteasy-legacy.jar
<tjaalton> that's what my localbuild has
<tjaalton> and the deb should have that too
<tjaalton> according to https://launchpadlibrarian.net/306405437/buildlog_ubuntu-zesty-amd64.resteasy_3.1.0-2_BUILDING.txt.gz
<nacc> tjaalton: hrm, strange, you're right
<nacc> tjaalton: i'll assume PEBKAC
<tjaalton> it needs changes in several places, not just for the build but runtime too
<nacc> tjaalton: ah i see that now
<tjaalton> <- EOD
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.13-0ubuntu0.16.04.1 => 7.0.15-0ubuntu0.16.04.2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.13-0ubuntu0.16.10.1 => 7.0.15-0ubuntu0.16.10.2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.2]
<jderose> infinity: so still no 16.04.1 RC ISOs? :)
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.13-0ubuntu0.16.04.1 => 7.0.15-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.13-0ubuntu0.16.10.1 => 7.0.15-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<nacc> tjaalton: fyi, will also need to backport https://git.fedorahosted.org/cgit/pki.git/commit/?h=DOGTAG_10_3_BRANCH&id=423c986c57a0baacf1dc8d817dc8b356b9cf0d06 for the build to succeed. Not sure if it's worth uupdating instead to the latest
<infinity> jderose: Tonight.
<jderose> infinity: cool, thanks. good luck :D
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.1]
<teward> aaaa i need someone to nuke an upload before it's accepted, I really hate myself for this
<teward> i uploaded an incomplete merge, i think
<teward> for nginx, can someone intercept and 'forget' it?
<teward> I think i uploaded, if not then sorry, I panicked for nothing :/
<teward> *yawns*
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.1]
<rbasak> nacc, mdeslaur: ^
<nacc> rbasak: thanks! i'll update the secondary bug with the SRU template
<rbasak> teward: to Zesty, I don't believe there's any point you can intercept. You can cancel builds but you'll still burn the version number.
<rbasak> nacc: good point, thanks.
<teward> blurgh
<teward> well I don't see an upload accepted thing so maybe I just imagined it?
<rbasak> nacc: I wasn't too concerned so didn't notice - because the fix is trivial and comes with an automated test case.
<rbasak> (and the microrelease carries far more regression risk than the bugfix)
<mapreri> (teward: this is not debian where there can be so much of 15 minutes between upload and accept)
<teward> well i made this fubar before and it was able to be caught and purged before it left proposed
<mapreri> That's not "before it's accepted"
<teward> well i just need it purged
<teward> but eh
<teward> i think i'm panicking over nothing 'cause I see no upload file heh
<mapreri> locking it in proposed, and/or removing from proposed it's feasible, but 1) the version number is gone 2) it's not nuked from existence
<mapreri> indeed :)
<mapreri> probably time for sleep instead :P
<teward> who has time for sleep lol
<nacc> rbasak: ack
<teward> okay, so I think this one won't blow up in my face heh
<teward> just... one question, do I upload the merge, then give the Release team a notice about how some newer packages need to be main and others as universe?
<teward> since we have some new packages thanks to the merge... :P
<teward> (dynamic modules)
<rbasak> teward: we'll get a component mismatch report.
<teward> and then we can fix accordingly.  That makes sense.
<rbasak> teward: you can file a bug (against nginx) and subscribe ~ubuntu-archive if you have further information I guess, or email ubuntu-release@. But normally they figure it out just from the report.
<teward> indeed.  It's not like it's additional external dependencies, that I"m aware of, but if there are I'll have to follow-up
<teward> IIRC that's not the case though
<teward> just stuff that's new from the debian packaging and rules, but still all from the packaging itself and nothing external to it :P
<teward> that's assuming these builds don't blow up in my face in the test repo
<teward> oh COME ON
<teward> ... stupid fatfingering...
-queuebot:#ubuntu-release- Unapproved: nano (xenial-proposed/main) [2.5.3-2ubuntu1 => 2.5.3-2ubuntu2] (core)
#ubuntu-release 2017-02-15
<tsimonq2> nacc: *takes this here* so I've been told upload NOTHING during freezes (prospective MOTU :P), is it an exception if seeded-in-ubuntu doesn't find anything, or do I still just not upload?
<teward> tsimonq2: FFe policies
<tsimonq2> teward: Which I'm asking about.
<teward> exceptions are security issues, bugfix-only, no version bumps.
<teward> FFe process: https://wiki.ubuntu.com/FreezeExceptionProcess  |  FeatureFreeze details: https://wiki.ubuntu.com/FeatureFreeze
<nacc> tsimonq2: it does depend on which freeze you mean
<teward> tsimonq2: FeatureFreeze, it needs approval by the release team I think it is to 'accept new features for a package.
<teward> final freeze is ***really*** really restrictive
<teward> and usually nothing is touched then
<tsimonq2> Confused after RTFMing: seeded-in-ubuntu - Determine whether a package is safe to upload during a freeze
<teward> tsimonq2: depending on *which* freeze, depends on the true answer
<teward> on Thurs, I think, we start FeatureFreeze
<teward> and FFe policies go into effect
<nacc> tsimonq2: yeah, i think that manpage probably needs an update too :)
<teward> ^ this
<teward> tsimonq2: #ubuntu-motu would also be a valid place to ask this, though it's far less active
<tsimonq2> teward: Ok, yeah, I thought this seemed like a releasey question :P
<teward> tsimonq2: well, true, but still
 * teward is more concerned about Perl holding **everything** up
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (yakkety-proposed) [0.8.2-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ostree [source] (yakkety-proposed) [2016.15-2ubuntu1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (xenial-proposed) [3.18.9-1ubuntu3.2]
<jbicha> RAOF: are you willing to accept bubblewrap, ostree and flatpak as new packages into xenial too?
<RAOF1> jbicha: I'm not able to do that, sorry. Need a fully-fledged AA to do NEW.
<jbicha> who are the real AAs then? https://launchpad.net/~ubuntu-archive/+members
<RAOF1> Both slangasek and infinity are real AAs and have been recently active :)
 * RAOF1 really should get to fully-fledged AA.
<slangasek> jbicha: what's the rationale for these as new SRUs in xenial?
<jbicha> slangasek: it's basically the same rationale as snap in trusty: it's a way to get new apps on a stable release
<jbicha> I'm trying to SRU chrome-gnome-shell too, for trusty and xenial bug 1652537
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
<slangasek> jbicha: ok, but snapd is part of the core Ubuntu platform in xenial and later; providing consistency with that would seem to have a bit more value in an SRU than $arbitrary_app_store?
<jbicha> slangasek: Ubuntu GNOME 17.04 includes flatpak now
<slangasek> jbicha: and are there things you currently go through cumbersome SRUs of that you would propose to provide instead via flatpak?
<mdeslaur> rbasak, nacc: thanks!
<slangasek> SRUing of snapd into trusty is a win because it means we can reduce the number of process-heavy SRU exceptions
<jbicha> The Flatpak maintainer asked if I could get flatpak into Ubuntu 16.04 LTS as they would like Flatpak 0.8 to be available in all LTS distros
<jbicha> currently, they are recommending xenial users use a PPA to get flatpak: http://flatpak.org/getting.html
<jbicha> honestly, I don't really use snap or flatpak; the target audience isn't someone who runs the Ubuntu development release
<jbicha> many GNOME apps are available via flatpak but I don't think are in the snap store yet and obviously the latest stable GNOME is not going to be SRU'd to xenial
<slangasek> jbicha: right.  I don't think I see any reason that this should be disallowed in xenial, but I also don't see any reason to prioritize it relative to SRUs of existing packages
<jbicha> sure, I can wait
<jbicha> I've been working on it since December but 2 bubblewrap security bugs had to be fixed in yakkety first
<jbicha> how about chrome-gnome-shell, which should be in -updates before Firefox 52 gets there next month?
<slangasek> jbicha: I don't understand, what's the relationship between those two things?
<jbicha> because Firefox 52 drops support for browser plugins so this is the workaround
<jbicha> the package name is unfortunate but it implement the chrome webextension api and was originally for chrome/chromium
<slangasek> jbicha: so what existing functionality is this replacing that will regress when firefox 52 drops?
<jbicha> does bug 1652537 answer your question?
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
<slangasek> jbicha: got it, thanks
<powersj>  /quit
<powersj> woops :P
<ginggs> apw: please check rev 2195 in your hints file, should be armhf ther instead of s390x
<apw> ginggs, bah fixed
<ginggs> apw: thanks
-queuebot:#ubuntu-release- New binary: lorene [s390x] (zesty-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lorene [powerpc] (zesty-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lorene [ppc64el] (zesty-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lorene [amd64] (zesty-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lorene [i386] (zesty-proposed/universe) [0.0.0~cvs20161116+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-scrapy-djangoitem [amd64] (zesty-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted lorene [amd64] (zesty-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lorene [powerpc] (zesty-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lorene [s390x] (zesty-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lorene [i386] (zesty-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lorene [ppc64el] (zesty-proposed) [0.0.0~cvs20161116+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (zesty-proposed) [17.04]
-queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.5.9-5ubuntu0.3 => 1:1.5.9-5ubuntu0.4] (core)
-queuebot:#ubuntu-release- New binary: npd6 [amd64] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [ppc64el] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [arm64] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [i386] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [armhf] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [powerpc] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: npd6 [s390x] (zesty-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [source] (xenial-proposed) [1.1.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (xenial-proposed) [1:1.5.9-5ubuntu0.4]
<Odd_Bloke> slangasek: I've updated https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1662491 to add a test for the other udev rule.
<ubot5> Ubuntu bug 1662491 in gce-compute-image-packages (Ubuntu Yakkety) "gce-compute-image-packages dropped udev rules that were present in gce-utils" [Undecided,New]
<Odd_Bloke> Which happens to be most of a fix for another issue GCE have filed. \o/
<Odd_Bloke> slangasek: Hmm, actually, the rest of the fix is just dropping a file in /etc/rsyslog.d, so I think it's probably worth doing that as part of this SRU rather than having to do all the busywork again.
-queuebot:#ubuntu-release- New: accepted npd6 [amd64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [armhf] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [powerpc] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [s390x] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [arm64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [ppc64el] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted npd6 [i386] (zesty-proposed) [1.1.0-1]
<Laney> were .manifest files always served up as application/x-ms-manifest?
<Trevinho> hi rbasak, can you please unqueue https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=libappindicator ?
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (xenial-proposed) [3.18.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (yakkety-proposed) [3.22.3-0ubuntu1]
<Laney> am I going mad?
<Laney> It looks like unity8 isn't installable in zesty
<Laney> can someone confirm?
<apw> Laney, i have it installed, if that counts any
<Laney> apw: Probably a component-mismatch
<Laney> Although
<apw> oh that likely
<apw> though if you mean in -proposed, then ... i am not helping :)
<Laney> wtf
<Laney> apw: Do you have the newest version?
<apw> Laney, from zesty-release yes
<Odd_Bloke> Same here.
<apw> unity8 is already the newest version (8.15+17.04.20170206-0ubuntu1).
<Laney> As far as I can see unity8-common has Depends: unity-application-impl-26 which doesn't exist
<Laney> Oh, unity8-tests in zesty/universe
<Laney> eww
<apw> oh did something move from main to universe while installed on your box perhaps
<jbicha> Laney: bug 1662608 and https://irclogs.ubuntu.com/2017/02/07/%23ubuntu-desktop.html#t16:45 :)
<ubot5> bug 1662608 in qtmir (Ubuntu) "unity8 should not depend on unity8-tests" [Undecided,Triaged] https://launchpad.net/bugs/1662608
<Laney> Right, but I didn't link that to a component mismatch
<apw> Laney, hehe that was you :)
<apw> quite how it got out of -proposed with that though
<Laney> at a guess, the thing doesn't deal with provides
<infinity> How is that bug still in the archive? :/
<infinity> I've been avoiding upgrading to not pull all that crap in.
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu16 => 229-4ubuntu17] (core)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (xenial-proposed) [229-4ubuntu17]
<infinity> Laney: Can you escalate and/or jfdi a fix for that bug?  Pulling in the whole X dev stack on upgrade is unpleasant, to say the least.
<infinity> Oh, I see an MP from a week ago.
<infinity> FFS.
<Laney> I'm asking in #-ci-eng
<jbicha> I set apt-mark hold on the unity8 tests because I didn't want that -dev stuff either :)
<infinity> I've just been upgrading instead of dist-upgrading for now.
<Laney> So it should be within a day, if this all-proposed run makes their tests go green
<Laney> There are lots of other fixes bundled up with the one we want
<Laney> The usual thing...
<apw> won't it autoremove off again when the bits are fixed ?
<infinity> In theory.
<Laney> I don't know
<infinity> Actually, no.
<Laney> Will you be moved from one provider to another?
<infinity> It won't.
<Laney> I don't see how
<infinity> Yeah, that.
<apw> hrm, why so, that seems counter-intuitive
<infinity> apw: It's not that it had a spurious dependency on foo-tests, it's that foo-tests and qtmir-thing both provide virtual-$version, but $version was wrong on qtmir.
<infinity> apw: So, you got foo-tests instead.  When qtmir is fixed, foo-tests will stick around because it still satisfies the dep.
<Laney> MMMmmmmmmmmmm
<Laney> So there's a libmirplatform transition
<Laney> qtmir -> miral -> libmirplatform
<jbicha> bump the depends/provides to impl-27?
<Laney> and miral FTBFS with a no-change rebuild against this new one
<Laney> There's a new upstream release which works apparently
<infinity> jbicha: Still wouldn't autoremove, it'd just upgrade unity8-tests to the one that provides the new virtual. :P
<apw> crap, and my machine is already infected with this mess
<apw> ii  unity8-tests:amd64
<jbicha> drop the unity8-tests package and create a new unity8-tests-oops-our-bad package ;)
<apw> so once i get a fixed unity (and a couple of pints of beer in compensation) i assume i can purge that one
<infinity> apw: Yeah, manually removing unity8-tests should autoremove all the rest of the junk at least.
<infinity> Manually removing it right now would also do very little harm, except for the bit where we have it in the desktop seed.
<Laney> Saviq is OKing me just uploading a Provides switch
<infinity> Which we never should have, IMO.  Should have been a separate meta, so people could whack it without consequence.
<infinity> Laney: Say, why didn't we do that?
<infinity> Wait...
<infinity> Removing unity8 doesn't remove ubuntu-desktop.
<infinity> I could have sworn it was in the desktop seed.
<Laney> Recommends
<infinity> Ahh.
<infinity> Well, that's my solution then.
<infinity> I was "dogfooding" it, but it's not like it's actually useful enough for me to do so.
 * Laney LA LA LAs at the lintian errors in qtmir
 * infinity purges libhybris too, to see what that takes with it.
<Laney> there we go
<Laney> I think this will not get involved with the mirplatform transition
<Odd_Bloke> So what's the solution to get rid of unity8-tests?  Can I just remove it now?
<Laney> If you wait for qtmir to migrate, then apt should offer to install (or upgrade) it when you try to remove unity8-tests
<Odd_Bloke> Right, whereas removing it now removes all of unity8.
<Odd_Bloke> OK, I shall wait.
<Saviq> Laney, btw, can you please upload the same change to xenial overlay?
<Laney> Saviq: sure, if that's allowed
<Saviq> Laney, yeah, it is
-queuebot:#ubuntu-release- Unapproved: postgresql-9.3 (trusty-proposed/main) [9.3.15-0ubuntu0.14.04 => 9.3.16-0ubuntu0.14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.3 [sync] (trusty-proposed) [9.3.16-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.5-0ubuntu0.16.04 => 9.5.6-0ubuntu0.16.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (yakkety-proposed/main) [9.5.5-0ubuntu0.16.10 => 9.5.6-0ubuntu0.16.10] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [sync] (xenial-proposed) [9.5.6-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [sync] (yakkety-proposed) [9.5.6-0ubuntu0.16.10]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-8.10] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu17]
-queuebot:#ubuntu-release- Unapproved: accepted nano [source] (xenial-proposed) [2.5.3-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.9]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (yakkety-proposed) [1:2.6.1+dfsg-0ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (xenial-proposed) [0.5.0+git1.656f8865-5ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (yakkety-proposed) [0.5.0+git1.656f8865-5ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted libodb [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu3~16.10.0 => 20160930-0ubuntu5~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu3~16.04.0 => 20160930-0ubuntu5~16.04.0] (ubuntu-cloud)
<Odd_Bloke> If anyone has a moment, they could reject gce-compute-image-packages 20160930-0ubuntu4~16.10.0 from the yakkety queue and 20160930-0ubuntu3~16.04.1 from the xenial queue.
<Odd_Bloke> slangasek: And these are the new gce-compute-image-packages ^
<arges> Odd_Bloke: sure
<arges> Odd_Bloke: does that look correct now?
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu4~16.10.0]
<Odd_Bloke> arges: Yep, thanks!
-queuebot:#ubuntu-release- Unapproved: libappindicator (xenial-proposed/main) [12.10.1+15.04.20141110-0ubuntu1 => 12.10.1+16.04.20170215-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-8.10]
-queuebot:#ubuntu-release- Unapproved: blktap-dkms (xenial-proposed/universe) [2.0.93-0.5ubuntu1 => 2.0.93-0.7ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: broadcom-sta (xenial-proposed/multiverse) [6.30.223.271-2 => 6.30.223.271-3~16.04.1] (no packageset)
<jgrimm> arges, would you be able to process curtin from Xenial today?
-queuebot:#ubuntu-release- Unapproved: dm-writeboost (xenial-proposed/universe) [2.1.1-1 => 2.1.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dm-writeboost [source] (xenial-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.7.1-1 => 2.8.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oss4 (xenial-proposed/universe) [4.2-build2010-5 => 4.2-build2010-5ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted oss4 [source] (xenial-proposed) [4.2-build2010-5ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: xtables-addons (xenial-proposed/universe) [2.10-1build1 => 2.10-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted blktap-dkms [source] (xenial-proposed) [2.0.93-0.7ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted broadcom-sta [source] (xenial-proposed) [6.30.223.271-3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [source] (xenial-proposed) [2.10-1ubuntu0.1]
-queuebot:#ubuntu-release- New binary: nginx [ppc64el] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libodb-boost (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-boost (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nginx [i386] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [s390x] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [powerpc] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [arm64] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [armhf] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [amd64] (zesty-proposed/main) [1.10.3-0ubuntu2] (kubuntu, ubuntu-server)
<teward> yes, unfortunately, package structure for nginx changed thanks to Debian and Dynamic Modules >.>
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.14+16.10ubuntu2 => 0.15+16.10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.14+16.04ubuntu2 => 0.15+16.04ubuntu1] (no packageset)
<dmj_s76> infinity: No new iso this morning?
<infinity> dmj_s76: Very shortly.  Just testing a build now.
<infinity> Or, rather, it's building so I can test it.
<dmj_s76> infinity: oh, great...we're eagerly waiting to test :)
<Odd_Bloke> slangasek: I'm EOD now; it would be lovely to wake up to gce-compute-image-packages packages in -proposed. ^_^
<slangasek> Odd_Bloke: .changes file ended up with no bug references; having a look at this, probably just a no-change reupload from me
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu3~16.10.0 => 20160930-0ubuntu5~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu5~16.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu5~16.10.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu5~16.04.0]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu3~16.04.0 => 20160930-0ubuntu5~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu5~16.04.0]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20170110.1-0ubuntu0.12.04.1 => 1:20170214.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170110.1-0ubuntu0.16.04.1 => 1:20170214.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170110.1-0ubuntu0.14.04.1 => 1:20170214.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20170110.1-0ubuntu0.16.10.1 => 1:20170214.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20170214.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170214.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170214.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20170214.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.2] (20170215.8) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.2] (20170215.8) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.2] (20170215.8) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.2] (20170215.8) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.2] (20170215.8) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.2] has been updated (20170215)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.2] has been updated (20170215.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.2] has been updated (20170215.2)
<wxl> infinity: what's new with the ISO?
<tsimonq2> wxl: I thought HWE stuff but I could be wrong
<wxl> tsimonq2: yeah well knowing that is always helpful XD
<wxl> if that's all it is, we'll mostly look at smoke testing
<tsimonq2> wxl: I could have sworn there was a way we can just diff the freaking ISOs!
<wxl> tsimonq2: well you could grab the manifest and diff them for sure
<wxl> maybe i'll just do that. sigh. :)
<wxl> of course the old manifest is overwritten :/
<wxl> and all the flavours have already built soooooo
 * tsimonq2 changes wxl's locale back to en_US from en_GB
<tsimonq2> :P
<wxl> no way man i use en_CA XD
-queuebot:#ubuntu-release- New binary: ht-el [amd64] (zesty-proposed/none) [2.1-1] (no packageset)
<tsimonq2> wxl: Aw what really? :P
-queuebot:#ubuntu-release- New binary: py-isort-el [amd64] (zesty-proposed/none) [2016.1-1] (no packageset)
<slangasek> the manifest for the previous image would still be under the previous build serial
-queuebot:#ubuntu-release- Unapproved: proftpd-dfsg (trusty-proposed/universe) [1.3.5~rc3-2.1ubuntu2.1 => 1.3.5~rc3-2.1ubuntu2.2] (no packageset)
<slangasek> for images where the old one rotated off, well, not so much
<wxl> tsimonq2: no. :)
<tsimonq2> wxl: Good. :P
<wxl> slangasek: yeah it's weird cuz when i looked this morning there was both 20170209 and 20170208 but now there's just one.
<slangasek> yes, they're expired based on age
<wxl> booo
<tsimonq2> slangasek: Where's the tooling that builds the images again?
<slangasek> tsimonq2: which piece? lp:ubuntu-cdimage?
<tsimonq2> slangasek: I mean the thing that builds the dailies.
<tsimonq2> slangasek: Like, installs the packages and such.
<slangasek> do you mean lp:livecd-rootfs?
<tsimonq2> Maaaybe...
 * tsimonq2 checks
<tsimonq2> slangasek: Hm so it doesn't LOOK like it. Maybe I'm not looking right?
<slangasek> well, I'm not sure which piece you're looking for
<wxl> hold on
<wxl> i think i can answer this
<tsimonq2> wxl: Yes siree please do :)
<slangasek> the chain is ubuntu-cdimage -> (launchpad-buildd -> livecd-rootfs -> live-build), debian-cd
<tsimonq2> Ooh, mkay.
<wxl> yeah that's what i was going to say based on the crontab
#ubuntu-release 2017-02-16
<infinity> wxl, tsimonq2: What's new is infrastructure changes to build the images correctly.  Packages (other than a couple of small security updates that snuck in) aren't different.
<infinity> Also, lubuntu i386 didn't build.  I'll need to retry that.
<wxl> infinity: i already got tsimonq2 on that
<infinity> wxl: Oh?  I don't see it building anywhere.
<wxl> infinity: well he said he was going to do it
<wxl> infinity: in any case, we can take care of that. don't worry about it
<wxl> infinity: do you have any idea what those security updates are?
<infinity> wxl: https://lists.ubuntu.com/archives/xenial-changes/2017-February/thread.html
<wxl> infinity: thanks :)
<infinity> wxl: Look for things accepted to xenial-updates after base-files/linux-hwe.
<infinity> Most of those weren't on ISOs.
<infinity> ffmpeg would be on most ISOs.
<infinity> And libgc is on some.
<infinity> That's about it.
<wxl> starting with debian-installer 20101020ubuntu451.10 (Accepted)  ?
<wxl> oops
<tsimonq2> wxl: Oh? I was just at dinner. :P
<wxl> that's proposed
<wxl> starting with open-vm-tools 2:10.0.7-3227872-5ubuntu1~16.04.1 (Accepted)
<infinity> wxl: The real changes were mangling the code that generates the bootloader configs and such.
<wxl> tsimonq2: well get off your butt and do your job :)
<tsimonq2> wxl: I'm on it dude jeez :)
<wxl> tsimonq2: :)
<tsimonq2> wxl: :)
<wxl> infinity: a d-i change? https://lists.ubuntu.com/archives/xenial-changes/2017-February/015941.html
<infinity> wxl: d-i isn't on your images. :P
<tsimonq2> wxl: Huh where which image?
<wxl> tsimonq2: amd64
<tsimonq2> wxl: No I mean which codename?
<tsimonq2> Xenial? Zesty?
<wxl> tsimonq2: xenial xanadu
<tsimonq2> :P
<wxl> xerxes xylophone
<infinity> Hrm?  lubuntu-xenial-i386 is the one that didn't build.
<infinity> I feel like I could have just fixed that for you 10 minutes ago.
<tsimonq2> infinity: Where? O_o
<wxl> http://iso.qa.ubuntu.com/qatracker/milestones/372/builds
<infinity> tsimonq2: What do you mean "where"?
<tsimonq2> infinity: nvm
<infinity> tsimonq2: Lemme know when you've sorted it (or just want me to do it), I'm blocking on you.
<infinity> (Need to build source DVDs, but won't do that until after lubuntu is sorted, or I'd end up blocking you for 4 hours)
<wxl> actually
<wxl> we may need to have you do it infinity
<wxl> at least assuming we can't request a rebuild while rebuilding
<wxl> i think the tracker's stuck in some weird state
<infinity> Ahh, did you try?
<wxl> because we have a build log for a successfully build image
<infinity> Then I might have to do it from my end, yeah.
<tsimonq2> infinity: Yeah looks like it
<infinity> Kay.  Stop touching it, I'll fix. :P
 * wxl slaps tsimonq2 's hand
<tsimonq2> :O
<tsimonq2> k
<wxl> in other news it looks like lubuntu has some ffmpeg libs, assumedly because we use ffmpegthumbnailer in pcmanfm
<wxl> so we'll probably want to check that just to be sure
<infinity> Yeah, most everyone has ffmpeg somewhere.
<infinity> To be fair, though, unless it breaks the *installer*, I don't deeply care, you can escalate regressions to the security team to fix after the release.
<wxl> could also affect video/audio players, i assume?
<infinity> And I don't think anyone plays video in their installer.
<wxl> XD
<wxl> YOU"D BE SURPRISED
<lynorian> infinity, live session
<tsimonq2> infinity: I can get you a PR in ~ 2 hours XD
<infinity> lynorian: Sure, you *can* play video in a live session.  But if "software in the live session has bugs" was release critical, we'd never release.
<infinity> Cause good luck having an ffmpeg or firefox or libreoffice with "no bugs".
<wxl> what is exactly the difference between the .manifest and the .list?
<infinity> wxl: manifest is the list of packages installed in the livefs.  .list is the file list on the ISO.
<wxl> ah
<wxl> um
 * infinity is pretty non-plussed with his body for decided that a 3 hours nap was enough after being up for over 24.
<wxl> ffmpeg is not in .list tho? that's iiiinteresting
<infinity> s/decided/deciding/
<infinity> wxl: Why would it be?
<infinity> wxl: Re-read what I wrong.
<infinity> wrong?
<infinity> wrote.
<infinity> re-read what I wrote. :P
<wxl> OH
<wxl> derp
<infinity> .list is the file list on the ISO.  Literally a directory listing of the CD.
<wxl> nevermind
<tsimonq2> infinity: You and teward should have landed some stuff last night (he was overly sleep deprived too :P) hehehehe
<infinity> desktop CDs have very few packages on the ISO, cause most of them are preinstalled in the livefs.
<wxl> right right
<wxl> got it
<infinity> wxl: Or, from a task perspective, livefs (and thus manifest) is minimal+standard+$flavour-desktop+$flavour-live
<infinity> wxl: While /pool/ on the ISO, and thus in .list is ship-live.
<powersj> infinity: forgive me if you have said this, but for server is the 20170215.8 ISO the final one?
<infinity> powersj: It's final unless someone finds a critical bug in it.
<infinity> Everything on http://iso.qa.ubuntu.com/qatracker/milestones/372/builds (except the rebuilding lubuntu/i386) is what I'm hoping to release.
<powersj> ok thanks
<powersj> server amd64, i386, and ppc64el ISO tests are kicked off. I'll update results later tonight
<infinity> powersj: Oh.  Yeah.  Server ISOs now have two kernels, which means the boot menus changed a bit.  If you're testing with preseeds, that shouldn't matter, but if you have infrastructure that scripts manipulating the bootloader menus, that might break.
<cyphermox> oh look, netboots still need testin'
<powersj> infinity: thanks for the heads up, that would explain why they are oversized :(
<infinity> Yeah, they're a bit bigger. :P
<infinity> Can't do much about that.
<powersj> yeah
<wxl> two kernels? whaaaaaa
<powersj> hwe
<wxl> oh
<wxl> bah
<xnox> infinity, the comment inside the hwe preseed is funny "If we're booting using the backported Vivid kernel, install it too."
<xnox> infinity, what's Vivid?
<infinity> Hahahaha.  Wow, I've missed that comment for how many years? :)
<xnox> infinity, i guess you are in a similar panic induced productivity mode each time =)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.2] has been updated (20170216)
<infinity> xnox: Oh well.  Can fix it on the next d-i build.  Comments aren't RC. :P
 * infinity kicks off a source DVD build and goes to figure out if he needs food or sleep or play or something else entirely.
<tsimonq2> Am I being impatient, or is kopete taking forever to migrate from zesty-proposed?
<infinity> xnox: Oh, it's possible I haven't missed it "for years".  It was probably right in lts-{utopic,vivid,wily,xenial}, but I bet I copied lts-vivid to make the new rolling hwe stuff.
<wxl> in general, tsimonq2, i would expect that the answer is you're being impatient.
<infinity> xnox: Hahahah.  Nope.  vivid, wily, and xenial all say Vivid. ;)
<infinity> tsimonq2: Definitely impatient.
<tsimonq2> I'm glad. :P
 * xnox kicks off auto testing of s390x with hacked up hwe stack tests. Let's see if they do the right thing or not.
<cyphermox> xnox: infinity: am i supposed to run a test (for netboot) with special settings to get the HWE kernel, or are we just looking to see the install completing normally without changes?
<xnox> cyphermox, hwe netboot has ./preseed.cfg that sets to install hwe kernel.
<cyphermox> good
<xnox> cyphermox, so if one boots with that netboot it should all be dandy. I replace preseed.cfg in my install tests, hence i'm checking it's there and then preseeding everything else as well.
<infinity> cyphermox: Yeah, what xnox said.  If you use an external preseed, they don't stack, and you need that altmeta line in yours.  If you just boot it raw and step through the menus, it'll DTRT.
<xnox> infinity, s390x server is not published to the 16.04.2 tracker =( and my automation tests old ISO
<xnox> and in daily stream it's marked as "rebuilding"
<infinity> Uh.  Oh.  Fun.
<infinity> It must have failed.
<infinity> Lemme look.
<xnox> infinity, there is no s390x in http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/20170215.8/ =(
 * xnox guesses that's what you want to actually ship
<infinity> xnox: It's possible I'm a moron.
<xnox> infinity, but you are way too nice to be a mormon
<infinity> xnox: But I'm going to blame you, cause you reviewed my stupidity. ;)
 * xnox blames canada
<xnox> although Justin Trudeau did so well in the white house. My facebook is full of memes of him looking down at Trump's tiny hands.
<xnox> our PM let Trump grab her by the waist
<wxl> ew
<infinity> xnox: Fresh build on the way.
<xnox> infinity, lovely
<xnox> infinity, that means i need to stay up. oh well. it takes about half an hour to spin & publish?
<xnox> or is it without livefs build?
<infinity> xnox: Fair point, I don't need to rebuild the livefs.
<infinity> I do need to kill the source DVD build, though.
<xnox> maybe you do need livefs too..... did things move, and when was the last one done?
<xnox> (we do use the livefs on s390x for the "no-network" install)
<infinity> xnox: The last livefs was built for the failed ISO build.  It's fresh.
<infinity> xnox: Built and mirroring now.
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.2] (20170216.1) has been added
<xnox> voila
<infinity> cello
<xnox> VoilÃ  != Viola, but puns are so ha-ha funny =)
<xnox> infinity, if only HMC would use fixed width fonts for descripltions =(
<xnox> visually rolling kernel is shorter than default kernel
<xnox> but it does look good.
<xnox> ..
<xnox> infinity, finished testing everything, s390x is good to go.
<xnox> good night.
<powersj> server amd64, i386, ppc64el look good
-queuebot:#ubuntu-release- New source: gnome-recipes (zesty-proposed/primary) [0.12.0-0ubuntu1]
<tsimonq2> infinity: How would I go about removing PowerPC Zesty Daily builds other than just disabling them on the tracker?
<tsimonq2> infinity: (I mean for Lubuntu)
 * tsimonq2 goes to bed, will fix in the morning
<infinity> tsimonq2: Pretty sure I already disabled them.  Just need to remove them from the tracker.
<cyphermox> infinity: on ppc64el should I not be getting kernel 4.8?
<infinity> cyphermox: That depends on your menu selections.  Did you ask for the HWE kernel?
<cyphermox> no, I did not
<infinity> cyphermox: Are you talking ISO, or netboot?
<cyphermox> I don't recall seeing a prompt for it
<cyphermox> netboot
<infinity> There are two netboots.
<cyphermox> ah, that will explain it
<infinity> Which reminds me, I should update cdimage/netboot to expose the HWE builds.
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/xenial-updates/main/installer-ppc64el/current/images/
<infinity> You'll see hwe-* variants there.
<cyphermox> yeah, I knew where to look
<cyphermox> just didn't realize I had to look.
<cyphermox> might as well kill this running amd64 test then
-queuebot:#ubuntu-release- New binary: rmlint [amd64] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [i386] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [i386] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [ppc64el] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [amd64] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [arm64] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [ppc64el] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [s390x] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [armhf] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rmlint [powerpc] (zesty-proposed/universe) [2.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [arm64] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [armhf] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [amd64] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [armhf] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [ppc64el] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
-queuebot:#ubuntu-release- New: accepted py-isort-el [amd64] (zesty-proposed) [2016.1-1]
-queuebot:#ubuntu-release- New: accepted rmlint [arm64] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted rmlint [i386] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted rmlint [ppc64el] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [arm64] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
-queuebot:#ubuntu-release- New: accepted ht-el [amd64] (zesty-proposed) [2.1-1]
-queuebot:#ubuntu-release- New: accepted rmlint [armhf] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted rmlint [s390x] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [i386] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
-queuebot:#ubuntu-release- New: accepted rmlint [powerpc] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- New: accepted rmlint [amd64] (zesty-proposed) [2.4.6-1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- New binary: zfs-linux [i386] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [ppc64el] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [s390x] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [amd64] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [powerpc] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [arm64] (zesty-proposed/main) [0.6.5.9-2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [armhf] (zesty-proposed/main) [0.6.5.9-2] (core)
<Odd_Bloke> slangasek: Ah, OK; I see they have gone through now, thanks!  Is there something I should have done to avoid the empty .changes file?
-queuebot:#ubuntu-release- New binary: gjs [i386] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [ppc64el] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [amd64] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [powerpc] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [armhf] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [s390x] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gjs [arm64] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: k3b [ppc64el] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: k3b [amd64] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: k3b [s390x] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: k3b [powerpc] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: k3b [i386] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: mutter [s390x] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: k3b [arm64] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: k3b [armhf] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: mutter [i386] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [powerpc] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [arm64] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New: accepted zfs-linux [amd64] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [armhf] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [powerpc] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [s390x] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [arm64] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [ppc64el] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [i386] (zesty-proposed) [0.6.5.9-2]
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [powerpc] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (zesty-proposed) [3.23.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (zesty-proposed) [3.23.90-0ubuntu1]
<tsimonq2> infinity: Got it, thanks.
<Odd_Bloke> bdmurray: Could you accept gce-compute-image-packages in to trusty-updates?  It's verification-done and has been baking for 13 days.
-queuebot:#ubuntu-release- New: accepted k3b [amd64] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [ppc64el] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [powerpc] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [s390x] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [arm64] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [i386] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted k3b [armhf] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [amd64] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [armhf] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [powerpc] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [s390x] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [arm64] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [ppc64el] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [i386] (zesty-proposed) [1.47.90-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libodb-pgsql (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-pgsql (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-qt (xenial-proposed/universe) [2.4.0-2 => 2.4.0-2build0~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-qt (yakkety-proposed/universe) [2.4.0-2 => 2.4.0-2build0~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-sqlite (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libodb-sqlite (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- New: accepted nginx [amd64] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [armhf] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [powerpc] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [s390x] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [arm64] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [ppc64el] (zesty-proposed) [1.10.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nginx [i386] (zesty-proposed) [1.10.3-0ubuntu2]
<Sweet5hark> seb128: Sweet5hark, you might want to ask on #ubuntu-release if they can skip the autopkg for that one, explaining that following upload is going to fix things but that we might get the new version in zesty before waiting for another build/infra round
<Sweet5hark> ^^ any strong positions on how to play that?
<Sweet5hark> talking about libreoffice, which is stuck in autopackage tests due to a missing dep (for the test)
<Laney> Sweet5hark: How do we know that these releases are good?
<Laney> 5.2.2 at least passed intermittently, but 5.3 never has
 * Laney goes to eat
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.15+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.15+16.10ubuntu1]
<ginggs> would someone please remove the armhf and powerpc binaries for theano?  it no longer builds on these architectures
<ginggs> LP: #1646827
<ubot5> Launchpad bug 1646827 in theano (Ubuntu) "Please remove armhf and powerpc binaries" [Undecided,New] https://launchpad.net/bugs/1646827
<ginggs> No reverse dependencies found
<santa_> hi
<santa_> dear release wizards, I have a question about britney behaviour with autopkgtests
<cyphermox> shoot; don't need to ask to ask, just ask ;)
<santa_> lets supose we have three source packages
<santa_> libfoo, libbar and baz
<santa_> libfoo produces the binary packages libfoo-dev and libfoo5
<santa_> libbar produces the binary packages libbar-dev and libbar5
<santa_> baz produces the binary package bazapp
<santa_> libbar-dev depends on libfoo-dev
<santa_> src:baz depends on both libfoo-dev and libbar-dev
<santa_> so the question is
<santa_> if we upload these 3 packages at the same time and they land in proposed...
<santa_> does this trigger the autopkgtests of src:baz twice?
<infinity> Yes.  And it should.
<santa_> so if I remove the libfoo-dev build depend of baz it would be autopkgtested once
<cyphermox> the fact that things are uploaded "at the same time" doesn't mean they show up at the same time, for starters, but they are also different libraries which need to be tested independently if you want to identify regressions correctly
<cyphermox> if you remove libfoo-dev as a build-depends of baz and baz does need it to build, it's wrong.
<infinity> santa_: Build-dependencies aren't the trigger, it's runtime dependencies.  If the binaries depend on both libraries, you'll get tests against each.
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.2] (20170216.1) has been added
<santa_> infinity: so it would be built twice, no matter what I do?
<infinity> s/built/tested/
<santa_> yeah, tested I meant
<infinity> Testing "too much" is never really a bug. :P
<santa_> cyphermox: keep in mind that i said that libbar-dev depends on libfoo-dev, hence the question
<santa_> infinity: well I had frameworks in mind
<santa_> http://gpul.grupos.udc.es/ka-iron-hand_reports/frameworks_archive/5.31_zesty_proposed_migration.pdf
<santa_> srlsy
<santa_> so I was just pondering about removing "redundant" build dependencies
<santa_> but if the zillions of autopkgtests are unavoidable lets get over it XD
<infinity> santa_: You may think in terms of frameworks, but proposed-migration thinks in terms of migrating individual packages.  We test each as if we were going to attempt a partial upgrade, then if that can't work, we test with deps in proposed to see if we can migrate in chunks, etc.
<infinity> santa_: The point of testing partial upgrades is to make sure your deps are correct.  If newapp works with oldlib (or oldapp works with newlib), we can migrate in smaller sets.  If the combination doesn't work, but you declare it does, there's a bug.  If the combination doesn't work, and you declare it doesn't, there's no bug, they just migrate together.  The way testing works, all this is determined without humans needing to evaluate each ...
<infinity> ... situation.
<Laney> You'd probably be happier if all of the KDE tests didn't perform a full build
<slangasek> Odd_Bloke: building with the -v flag so that all the relevant bits of the changelog were included
<Odd_Bloke> slangasek: Ah, `-v <version in -updates>`?
<slangasek> yes
<Odd_Bloke> Right, will endeavour to remember that next time.
<infinity> I've thought a few times about an extension to dpkg-genchanges (disabled by default, probably, because ew slow external network ickiness) that would check rmadison for you and apply the appropriate -v.
<ginggs> cyphermox: hi, are you aware of http://autopkgtest.ubuntu.com/packages/d/devscripts/zesty/s390x ?
<infinity> I am.
<ginggs> infinity: o/ would you respond to my mail sometime please?
<cyphermox> err?
<infinity> cyphermox: I assume he's poking you because you're the last uploader. :P
<cyphermox> yeah, i figured
<cyphermox> just don't know what that error is
<infinity> ginggs: The s390x devscripts thing isn't a devscripts bug, it's infrastructure.
<infinity> cyphermox: ^
<cyphermox> I had figured as much too; I had a similar issue building locally
<cyphermox> well
<cyphermox> aside from the obvious fr_CA <> C
<cyphermox> it might not be the same thing, but it looked like an issue due to some changes in gpg2?
<infinity> cyphermox: It's a curious interaction between gpg2 and containers.
<infinity> It's a bug, to be sure, but not a bug in devscripts. :P
<cyphermox> right
<ginggs> weird that it's ok on armhf
<ginggs> infinity: thanks for the theano removal - just got the mail now
<cyphermox> anyone else unable to boot the xenial armhf+raspi2 preinstalled server image?
<dannf> infinity: fyi, i see server isos in the tracker now, but looks like arm64 has no download link (others do)
<infinity> dannf: It also has no testcases, so whee.
<infinity> dannf: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/20170216.1/
<dannf> ah, then it can never fail! my job here is done.
<dannf> thx
<infinity> dannf: Give them a spin and lemme know what's what.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.7 => 2.408.8] (desktop-core)
<infinity> apw: ^-- Yo, pls accept blindly.
<dmj_s76> infinity: Is the release still scheduled for today?
<infinity> dmj_s76: Yes.
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.8]
<Laney> Pheature Phreeze
<sergiusens> bdmurray: slangasek can I get snapacraft into xenial-updates and yakkety-updates? armhf is failing on network timeouts and I was hoping to get a pass on those
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.2] has been marked as ready
<infinity> dmj_s76: Of course, if you're looking for some way to be helpful, looks like mythbuntu could use someone to smoketest their new images and make sure I didn't break them with the respin.
<tsimonq2> infinity: Just curious, ETA on Feature Freeze?
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-updates/main) [2.22.2 => 2.21] (desktop-core, ubuntu-server) (sync)
<Laney> I'll email about it in a bit
<infinity> tsimonq2: When Laney sends an email, apparently.
<Laney> Need to remember how to work svn first
<Laney> Not to send the email
<Laney> Although that would be quite a fun contraption
-queuebot:#ubuntu-release- Unapproved: rejected snapd [sync] (xenial-updates) [2.21]
<tsimonq2> Laney: hehehehehe +1
<tsimonq2> infinity: Ok, thanks.
<tsimonq2> Laney: What evil abomination still uses SVN? :P
<Laney> pkg-gnome
<infinity> Lots of things do.
<tsimonq2> Grrr :P
<Laney> It was actually painless in the end
<tsimonq2> I ironically added SVN support to Snapcraft :P
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1, Yakkety 16.10 | Archive: feature freeze, DIF | Zesty 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
<sergiusens> bdmurray: slangasek correction, only yakkety has the timeout, I retriggered in the meantime but it has ben painful as of late
<adamantium> so, will there be the 16.04.2 iso? delayed 4th or 5th time?
<adamantium> thanks in advance on any info on 16.04.2 iso.
<infinity> adamantium: There will be.
<adamantium> infinity: today?
<infinity> adamantium: Yes.
<adamantium> infinity: thank you
-queuebot:#ubuntu-release- New binary: nut [i386] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [s390x] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
<wxl> infinity: you got an eta for shipping 16.04.2?
<infinity> wxl: Today.
<infinity> wxl: (Probably late afternoon or early evening my time)
<infinity> "My time" being UTC-7
<wxl> great thanks :)
-queuebot:#ubuntu-release- New binary: nut [amd64] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
<dannf> infinity: arm64 installs w/ both kernels worked w/ no issue. will try to get a test case added - https://code.launchpad.net/~dannf/ubuntu-manual-tests/arm64-server-kvm/+merge/317539
<infinity> dannf: stgraber added test cases.
<infinity> dannf: Refresh the page.
-queuebot:#ubuntu-release- New binary: nut [arm64] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [powerpc] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [armhf] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
<infinity> dannf: They might be crap test cases, so feel free to still propose changes, but should be good enough for you to report some pass/fail and give me green text. :)
<dannf> infinity: ack
<flocculant> dannf: your test case is completely different than the one st graber used - I can just get that sorted now if it helps
<dannf> flocculant: it overlaps. i used qemu as the host to run his tests
<flocculant> yes I saw
<flocculant> well - read the mp - makes no difference to me - I can deal with that now if it helps
<dannf> flocculant: thanks! i don't think there's a rush, i've already ran it on 16.04.2 and it passed, but would be nice to have it there for the next release
<flocculant> dannf: ok - leave it with me and I'll get that done this week :)
<cyphermox> robru: so for transgui, looks like the issue on ppc64el is that fpc never got built for that arch, and building it depends on fp-utils which itself is built from fpc -- so either we need to get that bootstrapped somehow, or fp-utils isn't really required to build fpc.
<infinity> It needs bootstrapping.
<cyphermox> right
<infinity> Except it's not on ppc64el in unstable either, so it might just not be supported.
<ginggs> fpc needs porting for ppc64el first
<cyphermox> robru: I say move to another package.
<ginggs> shouldn't be a big job ppc64 works
<robru> alright
<cyphermox> robru: I suggest pcsc-lite or maybe fbset?
<cyphermox> oh, and I saw licensecheck too you could look at
<jbicha> bdmurray: is there a reason you accepted the nm packages for yakkety but not xenial? bug 1619354 bug 1645698
<ubot5> bug 1619354 in network-manager-applet (Ubuntu Xenial) "[SRU] Upgrade network-manager-applet to latest point release" [High,In progress] https://launchpad.net/bugs/1619354
<ubot5> bug 1645698 in network-manager (Ubuntu Xenial) "[SRU] Upgrade network-manager to latest point release" [High,In progress] https://launchpad.net/bugs/1645698
<cyphermox> robru: dub looks fun, too; it's D but you probably don't need to know D
<cyphermox> robru: I suggest you mention it here if you're looking at some package in particular from excuses/FTBFS/whatnot so that if someone else is about to look at it, we don't duplicate work
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (yakkety-proposed) [2.2.0-2ubuntu0.1]
<robru> cyphermox: yeah I was wondering how people know not to duplicate work
<cyphermox> we used to have a channel just for it, but there aren't many people working in this stuff -- might as well just say it here
<infinity> robru: As a general rule, people doing +1 type stuff are not a large army, so duplication doesn't really happen.  When we had people actively tasked with doing it, we coordinated on IRC.
<infinity> (I'd argue that the discussion belongs in #ubuntu-devel, though, not here)
<cyphermox> heh
<jbicha> yes, #ubuntu-devel please :)
<cyphermox> either works
<robru> two against one, it seems ;-)
<bdmurray> jbicha: I don't know but looking at it now there's an improper bug reference in the changelog.  "Add patches showing wwan options after logout/in (LP: #165019)"
<ubot5> Launchpad bug 165019 in Debian "stacks use experimental gui python" [Undecided,New] https://launchpad.net/bugs/165019
<bdmurray> bug 1651019
<ubot5> bug 1651019 in network-manager-applet (Ubuntu Xenial) "[SRU]nm-applet not show wwan options on menu after logout/in" [High,In progress] https://launchpad.net/bugs/1651019
<bdmurray> jbicha: it's supposed to be that one if you want to fix it
<jgrimm> infinity, for 16.04.2 release notes.. planning to call out that we are now  'ISO size > max CD media size' because of additional kernel?
-queuebot:#ubuntu-release- Unapproved: accepted spyder [source] (yakkety-proposed) [3.0.2+dfsg1-0ubuntu0.2]
<infinity> jgrimm: I wasn't deeply concerned about it, TBH, but if you feel the urge, the release notes are a wiki.
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (xenial-proposed/main) [1.2.0-0ubuntu0.16.04.4 => 1.2.6-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop)
<infinity> jgrimm: I might be wrong, but I suspect the number of people who install servers from actual physical CDs are a very tiny minority.
<jgrimm> infinity, cool. yeah i think worth mentioning as its been something we've made reasonable attempts to keep it to size up till now
<jgrimm> infinity, totally agree.. i don't think its really a big deal either, just being transparent
<infinity> jgrimm: Certainly, most larger deployments use some netboot/maas/cobbler/etc strategy, and one-offs are usually USB sticks, or if optical is all they have, a DVD drive if they're from this century.
<jgrimm> infinity, agree 100%
<infinity> jgrimm: But go forth and document.
<jgrimm> thanks sir
<jgrimm> powersj, ^^
<powersj> ok, shall I put my note there?
<jbicha> bdmurray: fixed; you're able to process new packages into stable releases, right?
<infinity> Oh, we didn't copy .1 notes out to .1 yet.  Should do that before people start editing.
<infinity> cyphermox: I thought you did that?  I guess not? :P
<cyphermox> Changes summary yes
<cyphermox> which i need to update again now
<jgrimm> powersj, yup and ask for the ISO size test to be updated too
<infinity> Ahh.
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (yakkety-proposed) [3.20.9-1ubuntu2.1]
<bdmurray> jbicha: I think so
<powersj> jgrimm: ok
<cyphermox> I can copy stuff too
<powersj> thx
<bdmurray> cyphermox: just copy or copy and paste?
<cyphermox> whatever will work, + replacing .1 with .2.
<infinity> Okay, 16.04.1 notes are archived.
<jbicha> bdmurray: bug 1652537 is high priority (chrome-gnome-shell for trusty and xenial), but I'm interested in bug 1649330 and bug 1656712 also (bubblewrap, ostree, flatpak > xenial)
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
<ubot5> bug 1649330 in bubblewrap (Ubuntu Xenial) "[SRU] bubblewrap unavailable on xenial" [Low,In progress] https://launchpad.net/bugs/1649330
<ubot5> bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress] https://launchpad.net/bugs/1656712
<infinity> jgrimm: Okay, https://wiki.ubuntu.com/XenialXerus/ReleaseNotes is for 16.04.2 now.  Feel free to peruse, remove stuff that you don't think is relevant, add you ISO size bit, whatever.  Enjoy.
<jgrimm> infinity, ack. and thanks!
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu2]
<cyphermox> infinity: do you know which was the last included USN?
<infinity> cyphermox: Lemme do some timezone math.
<cyphermox> checking to see if it was https://www.ubuntu.com/usn/usn-3197-1/
<infinity> cyphermox: Looks like libgc.
<slangasek> robru, Laney: what's the story with autopkgtests now returning 'blacklisted' as a result and causing proposed-migration stalls?
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (yakkety-proposed) [1.8.5-1ubuntu2]
<infinity> cyphermox: Which also gives you a reasonable SRU cutoff, based on libgc's position on https://lists.ubuntu.com/archives/xenial-changes/2017-February/thread.html
<robru> slangasek: first I'm hearing of this. example?
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (xenial-proposed) [1.9.6-1ubuntu1]
<slangasek> robru: upstart/blacklisted; linux/blacklisted in output for systemd
<robru> slangasek: no idea
<cyphermox> infinity: agreed. done.
<slangasek> robru: right, so someone else made the change on the autopkgtest end apparently, without coordinating ;)  hopefully Laney knows something
<cyphermox> infinity: are you still updating release notes? I see some thing wrong.
<infinity> slangasek: What's your proof that the change in UI is also what's stalling things?
<cyphermox> (for one, the kernel version may be misleading)
<infinity> slangasek: (systemd has other failing tests)
<robru> slangasek: Laney appears responsible: https://bugs.launchpad.net/auto-package-testing/+bug/1579090
<ubot5> Ubuntu bug 1579090 in Auto Package Testing "When a test is blacklisted, mark it as a failure" [Medium,Fix released]
<infinity> cyphermox: I'm not updating them currently.
-queuebot:#ubuntu-release- Unapproved: accepted wine1.6 [source] (xenial-proposed) [1:1.6.2-0ubuntu14.1]
<slangasek> infinity: update_excuses lists it as 'regression'.  If they're *not* blocking, then someone has a very funny idea of how the UI should look.
<robru> slangasek: all the examples of "blacklisted" that I'm seeing in excuses also say "ignored failure". what are you seeing that's actually a problem?
<infinity> autopkgtest for upstart/blacklisted: amd64: Regression â» , i386: Regression â» , ppc64el: Regression â»
<slangasek> robru: erm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd ?
<infinity> That would be his example.
<robru> oh I was looking at the one specifically for zesty
<infinity> I think it's fair to show the test is regressed, but also being ignored.
<slangasek> that one is for zesty
<infinity> I disagree that "blacklisted" is the best term.
<infinity> ignored would be clearer.
<slangasek> infinity: which is language we already use elsewhere, so saying it's a "regression" when in fact there was no test run is pointless
<infinity> Err, wait.  What does "blacklisted" mean?
<infinity> It's not the same as ignored, is it?
<infinity> Is this a new thing? :P
<slangasek> that was my question
<infinity> Cause I see "Ignored fialure" elsewhere.
<infinity> So confusing.
<slangasek> then you started defending it, so I was about to demand why you had knowledge of this that wasn't shared :-P
<infinity> Hah.  Yeah.  I assumed people had wiggled ignored around to be this.
<slangasek> "ignored failure" means we've overridden it with hints. "blacklisted" apparently means someone blacklisted the package on the autopkgtest end
<infinity> Oh, right.
<robru> rather I was looking at a stale copy that didn't have this problem
<infinity> That fits with what I'm seeing here.
<infinity> Cause linux/i386 is indeed blacklisted, due to murdering testbeds.
<infinity> So maybe it should also list the result as "ignored failure", I agree there.
<slangasek> there happens to be a test in the britney2 source to make sure 'blacklisted' is shown correctly
<infinity> Hard to tell without looking at code if it's actually hurting promotions, though, since there are other legit failed tests in that set.
<slangasek> but I don't see any actual code in britney to handle it specially
<slangasek> I've looked at the code, and there's nothing else in here that I see treating it as a "special" regression
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.2] has been updated (20170216.2)
<infinity> cyphermox: ^-- New one to test with Paolo's changes.
<infinity> Well, my changes implementing Paolo's suggestion.
<cyphermox> weee
<slangasek> furthermore, "maybe someone introduced two countervailing bugs instead of just the one you see and know about" is not a comforting response
<infinity> Heh.
<infinity> Right, definitely a UI bug, maybe a behaviour bug (yuor reading of the code would imply so)
<infinity> Well, not a behaviour regression, though.
<infinity> We already had to hint blacklisted stuff.
<infinity> But if we're going to the bother of mentioning it on excuses, we shouldn't block on it either.
<slangasek> yes, I think it's listed on excuses only because it shows up as an autopkgtest result with 'blacklisted' as the version number, e.g. http://autopkgtest.ubuntu.com/packages/u/upstart/zesty/amd64
<infinity> I like that upstart is now blacklisted on more arches than it's not.
<slangasek> so where does this blacklist happen?  this is the first I've heard of it
<infinity> Somewhere in the bit of autopkgtest I haven't learned about yet.
<infinity> Was that helpful? ;)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20170208.0.a34b091-0ubuntu1]
<slangasek> barry: you got some autopkgtest training, didn't you?
<slangasek> ah apparently it's swiftly answered just by looking at the production branch checkout
<slangasek> it's in worker-config-production/worker.conf, which is owned by ~ubuntu-release, so people could at least be updating that and hints files simultaneously
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20170208.0.a34b091-0ubuntu1~xenial1]
<infinity> slangasek: Yeah, but if britney can divine that something is blacklisted, hinting it twice is a colossal waste of time, so I'm all for making it a bit smarter.
<infinity> (Waste of time and error-prone)
<slangasek> infinity: yes. but in the meantime, britney's not doing that, so people shouldn't blacklist without also updating hints
<infinity> Fair point.
<infinity> upstart is hinted.
<infinity> linux could use an /i386 hint for now.
<slangasek> where do you see this upstart hint?  I only see one for upstart/1.13.2-0ubuntu35
<infinity> slangasek: Which is the current version.
<slangasek> yes, which is not the version that autopkgtest is reporting results for
<slangasek> it reports results for blacklisted as a *version*
<infinity> Oh, I see the hilarity there.
<infinity> Right, that's special.
<infinity> Maybe a hint for all/blacklisted/all would work? :)
<infinity> (using the package/version/arch spec)
<slangasek> probably not, but I'm syncing the list of all currently blacklisted packages
<infinity> It might work.  Britney does have a concept of "all" as a package hint key.
<infinity> (Think "block all")
<slangasek> maybe. anyway, trying this for now
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.2]
<slangasek> and the systemd/armhf test suite regression, which I can't reproduce on the porter box, seems to be an actual regression. Sigh.
 * tsimonq2 rings a large bell
<tsimonq2> 21 UTC ;)
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (xenial-proposed) [5.3.5-1ubuntu3.1]
 * acheronuk watches the FF portcullis of doom descend
<tsimonq2> ^
<tsimonq2> Darkness and clouds... :P
<Bashing-om> tsimonq2: Not looking good for the home team ?
<tsimonq2> Soo Laney or infinity or slangasek, Has It Begun yet? :P
<tsimonq2> Bashing-om: Give or take :P
<infinity> tsimonq2: It began 13 years ago.
<wxl> infinity: what are you talking about? i thought tsimonq2 was 15 XD
<tsimonq2> wxl: Noo I'm 14 but I turn 15 on 3/11 :P
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.2] has been marked as ready
<tsimonq2> infinity: I mean Feature Freeze :P
<infinity> tsimonq2: According to the topic and your INBOX, yes.
<infinity> yofel: Happy with marking Kubuntu ready?
<infinity> wxl / tsimonq2: Ditto for lubuntu?
<tsimonq2> infinity: wxl is Kubuntu guy now :P
<infinity> Err, that's not confusing.
<wxl> yeah well
<acheronuk> confuses me
<wxl> i'm filling in
<tsimonq2> infinity: Ping wxl for Kubuntu and me for Lubuntu
<wxl> we're almost there but not quite yet, infinity. another 30 mins or so?
<infinity> Sure.
<tsimonq2> infinity: Lubuntu is good to go. wxl is the one who calls Kubuntu. :P
<wxl> tsimonq2: you need me to mark lubuntu ready for you?
<teward> bdmurray: poke.  You can blame Perl for the holdup on -proposed -> zesty.
<teward> for the SRU, but i'm not as worried about the SRU as I am getting the final merge from Debian in :P
<tsimonq2> wxl: I can in a sec
<teward> (for nginx, for context)
<wxl> tsimonq2: well i'm looking at the tracker if you want me to
<tsimonq2> wxl: Sure actually
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
<wxl> done
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.2] has been marked as ready
<slangasek> well, I wonder if this 'force-badtest linux/blacklisted' is dtrt.  It kinda looks like it's forcing tests that /do/ have version numbers to be ignored.
<sergiusens> slangasek: bdmurray thanks for releasing snapcraft to yakkety-updates, any reason why xenial-updates is still missing? (which has no test rergressions even)
<slangasek> sergiusens: because I was distracted in the middle of releasing them, and was reminded to do the other release when I saw you pop back up on IRC ;)
<slangasek> (so, done before you asked)
<sergiusens> hah, well thank you very much!
<slangasek> barry: the systemd bits of LP: #1647031 have landed now in zesty; can you take care of reverting the NM revert?
<ubot5> Launchpad bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<barry> slangasek: i just saw that and was gonna ask you about it :)
<slangasek> :)
<barry> so... yep
<tsimonq2> I just saw that too ;)
 * infinity murders poor nusakan's SAN.
<slangasek> poor nusakansan
<tsimonq2> infinity: SAN?
<barry> you nuked nusakan?
<slangasek> the noose tightens
-queuebot:#ubuntu-release- Unapproved: pciutils (xenial-proposed/main) [1:3.3.1-1.1ubuntu1 => 1:3.3.1-1.1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: pciutils (yakkety-proposed/main) [1:3.3.1-1.1ubuntu4 => 1:3.3.1-1.1ubuntu4.1] (core)
<infinity> tsimonq2: http://lmgtfy.com/?q=SAN
<tsimonq2> infinity: Oh for pete's sake :P
<tsimonq2> infinity: But what if I use DuckDuckGo?
<wxl> !kick tsimonq2
<tsimonq2> wxl: hahahahaha :P
<jbicha> barry: you want to merge https://code.launchpad.net/~jbicha/network-manager/+git/network-manager/+merge/317560
<infinity> tsimonq2: http://lmgtfy.com/?s=d&q=SAN
<jbicha> I have upload rights but not git commit rights; happyaron is the opposite
<barry> jbicha: um, are you sure?  that diff has almost nothing in it
<jbicha> well I meant that as a question
<jbicha> barry: I already uploaded that to zesty hours ago so this is keeping git in sync with the repo
<tsimonq2> infinity: Excellent, thank you. :P
<barry> jbicha: oh i see.  okay, i can merge and push that to git
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
<roflcopter> 16.04.2 today, huh? , seems like it will never come
<Guest40327> 16.04.2 today, huh? , seems like it will never come
-queuebot:#ubuntu-release- Unapproved: accepted libodb-boost [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-pgsql [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-qt [source] (yakkety-proposed) [2.4.0-2build0~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-sqlite [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-sqlite [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-qt [source] (xenial-proposed) [2.4.0-2build0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-pgsql [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libodb-boost [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.1]
#ubuntu-release 2017-02-17
-queuebot:#ubuntu-release- Unapproved: appmenu-qt5 (xenial-proposed/main) [0.3.0+16.04.20151130-0ubuntu2 => 0.3.0+16.04.20170216-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
<infinity> wxl: So, moment of truth.  Kubuntu's going out without your say-so, unless you tell me to delete it. :P
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.2] has been marked as ready
<wxl> infinity: do it. sorry. was trying to put some other stuff together
<wxl> (unnecessary additional stuff)
<infinity> wxl: Alrighty.  Will be pushing big red buttons shortly.
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
<tsimonq2> infinity: How's button pressing going?
<tsimonq2> (no announcement email yet, just wondering)
<infinity> tsimonq2: There'll be an email in a few minutes. ;)
<tsimonq2> infinity: Thanks. ;)
<tsimonq2> infinity: Fancy, thanks
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.2, Yakkety 16.10 | Archive: feature freeze, DIF | Zesty 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
<mwhudson> infinity: congrats
<tsimonq2> infinity: DuckDuckGo was of no help here, what is DIF?
<tsimonq2> :P
<infinity> DebianImportFreeze.
<tsimonq2> Ahhhhhhh, gotcha.
<infinity> ie: we turn off the autosync mojo.
<tsimonq2> Yup, I got it, I've read the relevant docs, just didn't know about the acronym. ;)
<infinity> I'm not sure anyone uses the acronym, I just guessed Laney's intent based on what time of year it is. :)
<tsimonq2> infinity: As long as you don't start abbreviating Zesty to "ZZ," I'm fine. :P
-queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr437-0ubuntu1~16.10.1 => 0.1.0~bzr460-0ubuntu1~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: strongswan (yakkety-proposed/main) [5.3.5-1ubuntu4 => 5.3.5-1ubuntu4.1] (ubuntu-server)
<Laney> slangasek: The only new thing with that is that you can see them - previously the requests were just eaten invisibly
<slangasek> Laney: oh, ok
<ginggs> is there a know problem with i386 tests? tests seem to run, but their results don't go anywhere. update_excuses shows many 'Test in progress' for i386, but they don't seem to be running
<Laney> known-ish
<Laney> take one of them, for example strongswan
<Laney> look at the raw list of results (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/?format=plain&delimiter=@&prefix=zesty/i386/s/strongswan, documented at https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration)
<Laney> take the latest one, find its log.gz: http://10.24.0.175:8080/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/s/strongswan/20170217_045323_1a891@/log.gz
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/s/strongswan/20170217_045323_1a891@/log.gz
<Laney> -> it broke really early in setup
<ginggs> Laney: interesting, thanks
<Laney> mmm
<acheronuk> if a test has previously been triggered with all-proposed=1, is there a way to go back to re-running it without? looking at packages installed in a test and their versions, it seems to be remembering for the next triggering of the test even if all-proposed is them ommitted
<apw> acheronuk, i am not sure that is happening, even if it feels like it
<Laney> it's not
<Laney> look at the second line of the log
<Laney> the --apt-proposed bit
<Laney> --apt-pocket*
<acheronuk> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/k/kf5-kdepim-apps-libs/20170217_090015_2a4be@/log.gz
<acheronuk> --apt-pocket=proposed=src:kiconthemes
<acheronuk> that was triggered without all-proposed, but seems to be installing all the kde frameworks build deps from the proposed pocket
<Laney> That suggests that something requires those versions then
<acheronuk> right. so there is some flexibility there in the apt-pinning of those pockets, depending on other depends. i.e. if a something in the latest dep chain requires something else from the proposed pocket which is not the source or trigger, then it will get fetched from proposed no matter if all-proposed was set or not?
<xnox> Laney, working on zlib migrating from proposed, which leads to 1.2.8 -> 1.2.11 update. It has features, do I need FFe now, given that it did not migrate before the freeze?
<Laney> xnox: nah, I don't think so
<Laney> xnox: ...
<Laney> are you aware of the above udev/i386 bustage?
<xnox> as long as it migrates in a timely fashion.
<xnox> Laney, kill i386 = problem solved.
<xnox> Laney, no, i am not. Is there bug report about it?
<xnox> or is it adt only?
<Laney> if I could remember the qemu shizzle ...
<xnox> oooh, i think i see it
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/b/binutils/20170217_025857_c4f0d@/log.gz
<xnox> systemd-udevd is activating and fails to start =(
<xnox> that can't be good.
<Laney> right
<xnox> and that's with steve's systemd; let me retrigger that with 18ubuntu1
<Laney> no
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/s/strongswan/20170217_045323_1a891@/log.gz
<Laney> 18ubuntu1
<xnox> fun
<xnox> thanks i did not spot check find 18ubuntu1 as well.
<xnox> ok will debug now.
<Laney> just checking if I can get it locally
<Laney> https://cloud-images.ubuntu.com/zesty/20170215.1/zesty-server-cloudimg-i386.img <- has 232-8
<Laney> well I don't get it with autopkgtest-buildvm-ubuntu-cloud at least :/
<xnox> Laney, my host is xenial, and i don't get it either. horum.
<Laney> try in canonistack?
<xnox> Laney, is it a cloud problem?!
<xnox> Laney, yeah, that's what i am thinking now.
<xnox> gosh i have not logged into that in a while.
<Laney> me neither
<Laney> and nova in zesty is busted / incompatible so I can't try it myself
<Laney> :-)
<xnox> i had saved credentials for hte dashboard
<xnox> https://dashboard.canonistack.canonical.com/project/
<xnox> and apperantly i have some juju still spinning cycles there =/
<xnox> oh, they are shutoff, so that's good.
<Laney> heh
<xnox> i think it fails to spawn
<xnox> Laney, or it's not spawning because udev?
 * xnox ponders where CPC test images
<Laney> can you get the console-log?
<xnox> oooh it's active now.
<Laney> mine too
<Laney> looks like it's reproducing
<xnox> open port 22
<xnox> now i can ssh in.
<Laney> sudo apt update; sudo apt install udev
<xnox> and i guess we want to increase udevd debug level before doing that.
<Laney> think it accepts --debug
<xnox> Laney, Odd Bloke pointed me at fresh images that did build; test; published on i386 so it must be upgrades that are b0rked
<xnox> Laney, well i tweaked /etc/udev/udev.conf first
<Laney> well all the failures I saw happened while upgrading it
<xnox> Feb 17 10:53:16 testudev systemd-udevd[2399]: Check if link configuration needs reloading.
<xnox> Feb 17 10:53:16 testudev systemd-udevd[2399]: error getting socket: Protocol not supported
<xnox> fun
<Laney> awesome
<Laney> that leads to a bug + commit
<Laney> https://bugzilla.redhat.com/show_bug.cgi?id=1415358
<ubot5> bugzilla.redhat.com bug 1415358 in systemd "systemd-udevd and journald fail to start on i686 (systemd 232)" [Urgent,Closed: rawhide]
<xnox> Laney, which is in 232-18ubuntu1....
<xnox> and it does start
<Laney> doh
<xnox> but why did strongswan fail?!
<Laney> dist-upgrading the base systemd
<Laney> system
<xnox> right. so we need new image with -18ubuntu1? or retrigger all tests with extra systemd as trigger?
<Laney> why did dist-upgrading to 18u1 fail?
<xnox> 232-17ubuntu1 -> 232-18ubuntu1 is success; 232-8 -> 232-18ubuntu1 fails; 232-8 -> 232-17ubuntu1 also fails.
<xnox> doing start/stop after upgrade by hand succeeds.
<xnox> so e.g. restart fails; or -8 fails to re-exec / restart.... ?!
<Laney> we can test this theory by getting an image with 17u1 and trying systemd/i386
 * Laney kicks that
<xnox> pitti, https://launchpad.net/ubuntu/+source/systemd/+publishinghistory 232-9.. never migrated
<xnox> Laney, i think image with 17u1 will not help; as upgrade is still broken.
<Laney> you just said it works
<xnox> 232-8 -> 232ubuntu17 (timeout fail) -> 232-18ubuntu1 (starts) is what works.
<xnox> i didn't boot image with 17ubuntu1 to begin with.
<Laney> well this systemd run is going well so far
<xnox> =)
<Laney> however some of the i386 runs were a pass
<Laney> so it could be a fluke
<xnox> Laney, i do know that there are almost none i386 test results for src:systemd triggers for 18ubuntu1 =/
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
<Laney> right
<Laney> but not *actually* none
<xnox> and all of those tests are marked in progress and look lost.
<xnox> indeed.
<Laney> Setting up udev (232-18ubuntu1) ...
<Laney> addgroup: The group `input' already exists as a system group. Exiting.
<Laney> update-initramfs: deferring update (trigger activated)
<xnox> dandy
<xnox> does the infra self-update the base image to latest; or does it need manual proding to switch to latest i386 image?
<Laney> there's a cron to do that
<Laney> I ran it manually though
<Trevinho> tjaalton, slangasek: could you please approve the packages I've queued in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= ? :-)
<tjaalton> Trevinho: the syncs?
<Trevinho> tjaalton: yep
<tjaalton> there's not much to review since these don't have a debdiff
<infinity> tjaalton: You have to follow the copies back to the PPA, grab the source, and diff against the current xenial source.
<infinity> (which sucks, but there you have it)
<tjaalton> uh
<tjaalton> no wonder they pile up :P
<Trevinho> tjaalton: I think bdmurray probably wanted to updat the SRU tools to do this automatically from bileto ppa's or what?
<Trevinho> mhmh
<tjaalton> the ppa description seems to have diffs
<Trevinho> tjaalton: I think the sru-review -p option should help you
<tjaalton> still says no debdiff
<tjaalton> but the ppa diff is fine
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (xenial-proposed) [15.04.0+16.04.20170213.1-0ubuntu1]
<tjaalton> oh there were two..
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (yakkety-proposed) [15.04.0+16.10.20170214-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected libappindicator [sync] (xenial-proposed) [12.10.1+16.04.20170213.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (xenial-proposed) [15.04.0+16.04.20170214-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cups (trusty-proposed/main) [1.7.2-0ubuntu1.7 => 1.7.2-0ubuntu1.8] (core)
<tjaalton> Trevinho: are you sure the diff in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2464 is all for that one change?
-queuebot:#ubuntu-release- New binary: nut [ppc64el] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [i386] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [s390x] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [arm64] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [powerpc] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [amd64] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [armhf] (zesty-proposed/main) [2.7.4-5ubuntu2] (ubuntu-server)
<tsimonq2> infinity, slangasek et al: Who is lucky enough to do Nusakan for Beta 1? ;)
<infinity> Not I.
<infinity> I've got Beta 2 and Release.
<infinity> And I need a break before then. :P
<tsimonq2> infinity: So where should I go to "recruit" said person? :P
<infinity> tsimonq2: The intersection of ~ubuntu-cdimage and ~canonical
<infinity> (I recommend asking Laney nicely)
<Laney> when is it?
<infinity> Next week.
<tsimonq2> infinity: But isn't ~canonical a private team? I was hoping to write a hacky AI irssi script :P
<tsimonq2> Laney: Pretty please? *puppy eyes*
<Trevinho> tjaalton: yep
<Trevinho> a part the vala thing that was needed to get it compiling in xenial
<Trevinho> but it's just a GLib. prefix
<infinity> tsimonq2: In the absence of a bot, the intersection of people who have access and know the code/tools would be: adconrad (don't ask that guy, he sucks), cjwatson, laney, slangasek, stgraber
<infinity> I also note that the cdimage team needs some spring cleaning.
<Laney> I can help, sure, if I don't get pinged every 10 seconds to unblock things
<tsimonq2> Laney: \o/
<infinity> Laney: Just change your nick by one character, they'll never find you.  It's the IRC equivalent of Clark Kent's glasses, or maybe an evil moustache.
<tsimonq2> Laney: Put your name on the wiki? ;)
<Odd_Bloke> Laneish.
<tsimonq2> infinity: Just like it took me a few months to figure out you were Adam Conrad. :P
<tsimonq2> Well I'm off to school o/
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu4.1 => 0.6.5.8-0ubuntu4.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libappindicator [sync] (xenial-proposed) [12.10.1+16.04.20170215-0ubuntu1]
<tjaalton> Trevinho: would be nice to have xenial targets added to the bugs beforehand
<Trevinho> tjaalton: I've not the powers for doing that...
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/appmenu-qt5/+bug/1606246 did not have ubuntu/appmenu-qt5, surely you can add that?-)
<ubot5> Ubuntu bug 1606246 in Mir "Hard-coded X11 calls cause Unity 8 to fail to run on desktop" [Low,Triaged]
-queuebot:#ubuntu-release- Unapproved: accepted appmenu-qt5 [sync] (xenial-proposed) [0.3.0+16.04.20170216-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu15 => 0.6.5.6-0ubuntu16] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sni-qt (xenial-proposed/main) [0.2.7+15.10.20150729-0ubuntu1 => 0.2.7+16.04.20170217.1-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<Trevinho> tjaalton: thanks, the last one just got added to the queue
<Trevinho> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=sni-qt
<xnox> Laney, i wonder if we can land perl, zlib, systemd today =/
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu4.2]
<Laney> seems ambitious
<Laney> maybe we can run the new devscripts against perl
<Laney> and libgnupg-whatsit is the socket length bug
<Laney> so that can be skipped
<Laney> libembperl-perl wants looking at though
<tjaalton> Trevinho: it refers to an old bug which again has no bug target for xenial
<tjaalton> or that package for that matter
<Trevinho> tjaalton: I was just adding that
<Trevinho> it was just hanging
<Trevinho> ok now should be there
<tjaalton> thx
-queuebot:#ubuntu-release- Unapproved: accepted sni-qt [sync] (xenial-proposed) [0.2.7+16.04.20170217.1-0ubuntu1]
<tjaalton> Trevinho: the bug needs a test case
<Trevinho> yes, and that too... Although i i need to figure out what app is using that atm
<Trevinho> as legacy skype was, but not sure who else
<Trevinho> Except snaps I mean
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu16]
<apw> tjaalton, i was going to review pciutils if you arn't doing it already
<tjaalton> apw: go ahead, I'm about to EOW anyway
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (yakkety-proposed) [1:3.3.1-1.1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (xenial-proposed) [1:3.3.1-1.1ubuntu1.1]
<apw> ^ the two test failures in zesty are bogus, one after the tests completed successfully and the other a known issue with linux.
<caribou> Are debian syncs only blocked momentarily around the FF ?
<Laney> Autosync is off now for the rest of the release
<Laney> Use syncpackage to sync things manually
<Trevinho> tjaalton: test case added
<caribou> Laney: ok, but since I just found out that it was seeded, looks like it won't be so simple
<caribou> I uploaded it to debian early wednesday & hoped that it would make it in before FF
<tjaalton> Trevinho: good
<apw> caribou, so there are new features in "it" ?
<caribou> apw: that the sosreport' iscsi plugin enablement that was missing in Zesty for which I asked you to reject the SRU
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] (20170217) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 1] (20170217) has been added
<Trevinho> tjaalton: I didn't receive any mail about the bug verification, is that still in progress?
<apw> caribou, that is annoying ... it should be a slam-dunk regardless
<jbicha> wow, that's early for beta rc's
<caribou> apw: Looks like a FFE is in order now
<tjaalton> Trevinho: I accepted them from the queue page, sru-review -p didn't seem to work
<Trevinho> mh, weird
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (yakkety-proposed) [0.1.0~bzr460-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr460-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (yakkety-proposed) [5.3.5-1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (trusty-proposed) [1.7.2-0ubuntu1.8]
-queuebot:#ubuntu-release- Unapproved: accepted proftpd-dfsg [source] (trusty-proposed) [1.3.5~rc3-2.1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.22.2 => 2.22.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.22.2+16.10 => 2.22.3+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New source: os-faults (zesty-proposed/primary) [0.1.10-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.22.3+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.22.3]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.22.2~14.04 => 2.22.3~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.22.3~14.04]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.27 => 2.27.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.27+16.10 => 2.27.1+16.10] (no packageset)
<sergiusens> slangasek: might letting those into -proposed pretty please? ^
<elopio> slangasek: ping in case you are around now. snapcraft in -proposed would be useful :)
#ubuntu-release 2017-02-18
-queuebot:#ubuntu-release- Unapproved: puppet (yakkety-proposed/universe) [4.5.2-1ubuntu1 => 4.5.2-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: puppet (xenial-proposed/universe) [3.8.5-2 => 3.8.5-2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] (20170218) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] (20170218) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] (20170218) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] (20170218) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] has been updated (20170218)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] has been updated (20170218.1)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 1] has been updated (20170218.1)
#ubuntu-release 2017-02-19
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- New binary: gocryptfs [amd64] (zesty-proposed/universe) [1.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gocryptfs [i386] (zesty-proposed/universe) [1.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gocryptfs [armhf] (zesty-proposed/universe) [1.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gocryptfs [s390x] (zesty-proposed/universe) [1.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: rejected nut [amd64] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected nut [armhf] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected nut [powerpc] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected nut [arm64] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected nut [s390x] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected nut [i386] (zesty-proposed) [2.7.4-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [amd64] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [armhf] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [powerpc] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [s390x] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [arm64] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [ppc64el] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nut [i386] (zesty-proposed) [2.7.4-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted gocryptfs [amd64] (zesty-proposed) [1.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gocryptfs [i386] (zesty-proposed) [1.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gocryptfs [armhf] (zesty-proposed) [1.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gocryptfs [s390x] (zesty-proposed) [1.2-2ubuntu1]
-queuebot:#ubuntu-release- New binary: x265 [i386] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [s390x] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [powerpc] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [arm64] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [ppc64el] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [armhf] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [amd64] (zesty-proposed/universe) [2.3-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted x265 [amd64] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [armhf] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [powerpc] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [s390x] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [arm64] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [ppc64el] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted x265 [i386] (zesty-proposed) [2.3-1]
<santa_> good afternoon release wizards
<santa_> we have a problem right now with gpgme blocking the migration of most kubuntu's packaging out of -proposed
<santa_> gpgme is making another package FTBFS with -proposed enabled
<santa_> therefore that is making many autopkgtests fail
<santa_> we proposed a fix for this here https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1647204/comments/44
<ubot5> Ubuntu bug 1647204 in gpgme1.0 (Ubuntu) "1.8.0-2 FTBFS in zesty 17.04" [Undecided,Confirmed]
<santa_> but we would need an upload of this fix (we don't have any active motu on the team unfortunately)
<santa_> so if you could help us with this particular issue, that would be terrific. thanks in advance
<clivejo> apw: would you be able to help on the above? ^
<mapreri> santa_: gpgme1.0 is in main, so you'd need a core-dev, not a motu (so I can't help)
<santa_> mapreri: oh, thanks for the clarification. I still need to get more familiar with ubuntu's "bureaucracy" :)
<clivejo> https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1647204
<ubot5> Ubuntu bug 1647204 in gpgme1.0 (Ubuntu) "1.8.0-2 FTBFS in zesty 17.04" [Undecided,Confirmed]
<clivejo> should we sub the sponsor team again?
<mapreri> it's already subscribed
<mapreri> let me ask dkg if he'd upload that to debian
<apw> is the whole change the reduction in the thread count from 100 to 10 in those two tests ?  that feels like a rather arbitrary fix without context.
<apw> what is the symptoms when it is at 100 ?
<mapreri> launchpad-buildd hangs.
<santa_> apw: it doesn't build, let me dig a bit, to see if I can find the specific failure...
<santa_> apw: https://irclogs.ubuntu.com/2017/02/18/%23kubuntu-devel.html#t20:02
<apw> santa_, the patch implies but does not elucidate that you have confirmed that the failure it finds is not the intended failure mode tested but some other factor
<apw> santa_, ok that does tell me more what i wanted to know
<apw> it would be good if the patch said that we run out of memory in a fork-storm
<jbicha> yes, I subscribed ~ubuntu-sponsors to that bug several hours ago
<clivejo> thanks jbicha
<jbicha> have the Ubuntu Qt maintainers seen this bug? that QtCore error seemed odd
<mapreri> santa_: from dkg (gpg* maintainer in Debian): https://paste.debian.net/plain/915558
<mapreri> (guess it's a FYI)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 1] has been updated (20170219)
<apw> mapreri, santa_, that osunds liek the symlink makes no sense ...
<santa_> we could try to patch the kde package which is failing to build instead
<clivejo> apw: how should it be done?
<santa_> in any case that is meant to be a temporary thing to be droped later
<apw> santa_, it sounds like that is essentially a transition for the consumers of that library, if that change is dev library is expected
<clivejo> its a bit of a vicious circle
<clivejo> kf5-kdepim-apps-libs is the package that needs it
<apw> clivejo, well that is only a build-time depedency and we are uploading this to free built-binaries
<apw> clivejo, so why does it need that.  and if we are having to rebuild _that_ anyhow, it would be just as easy to fix it, in theory
<clivejo> KDE PIM
<apw> * libkf5gpgmepp-dev             (for libgpgme11-dev)
<apw> that is the only reverse-depends right?
<clivejo> huge beast of a thing and not having a working gpgme has lead to us having to hold it back for now
<apw> clivejo, will someone get round to fixing the reverse-depends if i let you bodge this, and remember to remove the bodge
<clivejo> If I recall kf5-kdepim-apps-libs is split out into new packages
<apw> oh gawd
<apw> someone on your side like to make your life hard
<clivejo> oh yes
<clivejo> remember that list of new packages I told you about?
<clivejo> approx 20 new packages for PIM
<apw> i guess now you have lots of FFEs to file too
<clivejo> but its either an all or nothing
<clivejo> so far we have held back the PIM packages to 16.04 and its deps
<apw> ok i'll look at this patch and perhaps mark that patch for not carrying forward in the next merge
<apw> so you have to do something about it then :)
<clivejo> can you hold back on it a sec
 * apw stops
<clivejo> would you be willing to force kf5-kdepim-apps-libs tests?
<clivejo> would the release team work with us to ensure the new packages are accepted and get in?
<apw> i assume if they ahve been accepted for the release (as in FFE or whatever equivalent it needed)
<apw> then i assume we would work with you to get them in
<clivejo> who would make that decision?
<apw> well at this stage i assume a big pile of updates would need an FFE, so that would be the place
<apw> to ahve the discussion.  i am assuming that if KDE wants KDE to be specific thing, and are committing
<apw> the effort to get it done, then it would get approved.  but i don't think i should make that decision on my own
<clivejo> well these are all the latest KDE Apps 16.12
<apw> so right now we have half of KDE as 16.12 and half as 16.04, which sounds like a bad idea from a support
<clivejo> but as we had problems with gpgme and 20+ new packages to get in, we have been holding off
<apw> point of view... and i assume it is that you would be asking to correct
<clivejo> our aim is to get everything to 16.12
<apw> and that sounds like a laudible and sensible plan to me, so would likely get my vote
<clivejo> but with PIM deps, one part of it not working, can bring the entire stack down
<apw> presumably that is an argument for it being in sync version wise
<santa_> I think we could do it
<santa_> but we need to get the NEW packages accepted
<santa_> right now we have good resources to update all of this
<apw> right the point of the FFE would be commiting both sides to it
<clivejo> we have no MOTU's on our team at the moment, and found it very difficult to get previous NEW packages accpted
<apw> clivejo, yep, someone would likely be voluntold to help with New reviews
<clivejo> so for the FFE, we would open it against something high up in that stack, like Kontact?
<santa_> apw: ok, I think the thing is doable in our side; what we can offer is 1. packages not ftbfsing, 2. most autopkgtests passing in amd64/i386
<santa_> about the autopkgtests I would expect a little bit of mercy on some things
<clivejo> esp on weird arch's!
<apw> clivejo, nominally on all packages you want to update (obviously not on the ones which do not exist) so perhaps the one you are splitting or something
<clivejo> most exist already, just split from source package
<clivejo> http://paste.ubuntu.com/24027977/
<clivejo> apw: that would take forever, PIM has a lot of packages
<clivejo> in the past we have selected one top tier package and opened an FFE for that to cover all the packages below
<apw> clivejo, do what you did before indeed; get all that information in the FFE and do send me the bug number where you get that
<clivejo> this is an example of Frameworks FFE - https://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1625392
<ubot5> Ubuntu bug 1625392 in plasma-desktop (Ubuntu) "[FFe] KDE Frameworks 5.26.0 into the Yakkety Archive" [Undecided,Fix released]
<apw> clivejo, whatever worked last time, do that
<clivejo> apw: is it possible to hold the entire packageset in proposed until we are happy everything is working as it should?
<apw> clivejo, we can cirtainly block things in -proposed
<clivejo> but like 50 odd packages?
<clivejo> apw: could you force-bad-tests kf5-kdepim-apps-libs for the time being?
<clivejo> its holding back 5 key frameworks from migrating
<apw> clivejo, if you make me a list of what you want held, it can be held
<apw> if there are some key libraries tha the remainder dep on we can hold those, and the rest get help as a result
<clivejo> ok, its more a thought at the moment
<clivejo> we know that KDE PIM 16.04 is working and is tested very well
<clivejo> 16.12 I know amd64 is working great, but we would need feedback for other arch
<santa_> I would like to note that we still have some problems with some archs
<santa_> http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_staging/16.12.1_zesty_retry_builds.pdf
<santa_> we will work on it
<santa_> we also have a private wannabuild/buildd infrastructure to check the autopkgtests
<apw> clivejo, ok that ADT failure is triggered by the fact the tests mandate a rebuild, which we know will fail
<apw> clivejo, so i think we can badtest that reasonable.
<clivejo> thanks
<santa_> apw: thank you very much, we are going to work on kde applications issues on our side
<valorie> Hi folks, I was just setting up torrents for seeding 16.04.2 and I see that Lubuntu i386 seems to be missing here: http://torrent.ubuntu.com:6969/
<valorie> I checked and it is marked ready, and was reported as such here in the chan
<valorie> infinity: ^^^
#ubuntu-release 2018-02-12
<slangasek> krytarik: fwupdate no-change rebuild should actually not have been needed; what was needed was removal of the stale libsmbios2v5 binary
<krytarik> slangasek: That would only have made it another way of uninstallable, because:-
<krytarik> -Depends: libc6 (>= 2.22), libefiboot1 (>= 32), libefivar1 (>= 32), libsmbios2v5
<krytarik> +Depends: libc6 (>= 2.22), libefiboot1 (>= 32), libefivar1 (>= 32), libsmbios-c2
<tsimonq2> New nodejs incoming that bumps its major version.
<krytarik> slangasek: "Provides: libsmbios2 (= 2.3.1-1), libsmbios2v5 (= 2.3.1-0ubuntu2)" - aha, ok. :D
-queuebot:#ubuntu-release- New binary: node-pinkyswear [amd64] (bionic-proposed/none) [2.2.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: centrifuge [i386] (bionic-proposed/none) [1.0.3~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: centrifuge [amd64] (bionic-proposed/none) [1.0.3~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [i386] (bionic-proposed/none) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [amd64] (bionic-proposed/none) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [ppc64el] (bionic-proposed/none) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [amd64] (bionic-proposed/none) [5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [s390x] (bionic-proposed/none) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [i386] (bionic-proposed/none) [5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [s390x] (bionic-proposed/none) [5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [armhf] (bionic-proposed/universe) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [armhf] (bionic-proposed/universe) [5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libodsstream [arm64] (bionic-proposed/universe) [0.4.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [arm64] (bionic-proposed/universe) [5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mclust [ppc64el] (bionic-proposed/universe) [5.4-1] (no packageset)
 * slangasek ponders LP: #783660
<ubot5> Launchpad bug 783660 in linux (Ubuntu Oneiric) "linux-tools: perf should link statically to libbfd" [Low,Fix released] https://launchpad.net/bugs/783660
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [160-1~ubuntu17.10.1 => 161-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [161-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [160-1~ubuntu16.04.1 => 161-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [161-1~ubuntu16.04.1]
<doko> apw, sforshee: when will the "blocking bug" be remove for linux in bionic-proposed?
* cjwatson changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Artful 17.10 | Archive: open | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
-queuebot:#ubuntu-release- New source: dptfxtract (bionic-proposed/primary) [1.2-0ubuntu1]
<apw> doko, that is gated on ADT/SRU testing on that kernel normally, i will deferr to sforshee on the status of that
<doko> apw: ok, but see what sl angasek mention about 783660 above
-queuebot:#ubuntu-release- New binary: python-daiquiri [amd64] (bionic-proposed/universe) [1.3.0-3ubuntu1] (no packageset)
<apw> doko, so we have fixed this before, sigh
<apw> i hate things like that that find a way to go missing long after everyone has forgotten
<xnox> apw, add an autopkgtest, that tests the .debs to not have bfd dependencies?!
 * xnox had to fix 3 times in systemd, to not kill processes on exit...
-queuebot:#ubuntu-release- New: accepted python-daiquiri [amd64] (bionic-proposed) [1.3.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-pinkyswear [amd64] (bionic-proposed) [2.2.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [amd64] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [armhf] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [ppc64el] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [amd64] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [armhf] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [ppc64el] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [arm64] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [s390x] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [i386] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted libodsstream [i386] (bionic-proposed) [0.4.12-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [s390x] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mclust [arm64] (bionic-proposed) [5.4-1]
-queuebot:#ubuntu-release- New: accepted centrifuge [amd64] (bionic-proposed) [1.0.3~beta-1]
-queuebot:#ubuntu-release- New: accepted centrifuge [i386] (bionic-proposed) [1.0.3~beta-1]
<sil2100> oSoMoN: hey!
<sil2100> oSoMoN: looking at the libreoffice artful SRU right now
<oSoMoN> sil2100, thanks!
<sil2100> oSoMoN: just wanted to get an idea if this is a problem or not: I see that the debian-l10n/config part has a "--with-build-version='1:5.4.4-0ubuntu0.17.10.1~ppa1'" in the diff instead of just 17.10.1
<sil2100> oSoMoN: not sure how this flag is used so just wanted to poke you about it
<sil2100> Is that still ok?
<oSoMoN> sil2100, afaik that's used in the about dialog of LO to display the build version, but in any case the ~ppa1 doesn't look right, and I don't have it here in my local build, I wonder how it sneaked in
<oSoMoN> let me check
<oSoMoN> sil2100, okay, I think I know what's going on
<oSoMoN> the source package for libreoffice-l10n is automatically generated from the source package for libreoffice
<oSoMoN> what you see in debian-l10n/config is used to generate debian/config for libreoffice-l10n
<oSoMoN> if you check the version number in libreoffice-l10n, it's correct
<oSoMoN> for some reason debian-l10n/config has been committed with that ~ppa1 suffix, but it doesn't affect the resulting package
<oSoMoN> so that should be safe
<sil2100> Ah, ok, so this is just a leftover in libreoffice's debian-l10n/config and basically doesn't do anything as is
<doko> xnox, apw: linux autopkg tests don't help. they always fail, and test results are ignored ;p
<sil2100> Ok, I'll let it in, some people might get the wrong version when building l10n by themselves from the libreoffice source, but yeah, it's not a biggie
<doko> Laney, slangasek: it might make sense to priotize http://autopkgtest.ubuntu.com/packages/o/octave-interval/bionic/armhf (mpfr4 transition)
<sil2100> oSoMoN: grrr, libreoffice is causing my tools to timeout when accepting the SRU
<sil2100> oSoMoN: anyway, I'll get it in today, but I'll have to do it manually after lunch
<oSoMoN> sil2100, no they shouldn't get the wrong version, because they would run "debian/rules update-l10n" first to generate the libreoffice-l10n source package, and that would fix the version number
<oSoMoN> sil2100, thanks!
<sil2100> Ah, so even better
<xnox> doko, har har
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-115.139] (core, kernel)
-queuebot:#ubuntu-release- New binary: sagemath [amd64] (bionic-proposed/universe) [8.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-115.139]
-queuebot:#ubuntu-release- New binary: sagemath [arm64] (bionic-proposed/universe) [8.1-3ubuntu1] (no packageset)
<xnox> slangasek, could you please RM two php packages, removed from testing, maintained "RC-autoremove them" rather them RM-ROM them. Blocking phpunit & php7.2 transitions.
<xnox> https://bugs.launchpad.net/ubuntu/+source/php-guzzlehttp-psr7/+bug/1748904
<ubot5> Ubuntu bug 1748904 in php-guzzlehttp-psr7 (Ubuntu) "RM: ROM Useless In debian, and in Ubuntu too" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (artful-proposed/main) [1:10.0-2ubuntu3 => 1:10.0-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (artful-proposed) [1:10.0-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (artful-proposed) [1:5.4.4-0ubuntu0.17.10.1]
<oSoMoN> sil2100, thanks for reviewing and approving the LO SRU !
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (artful-proposed) [1:5.4.4-0ubuntu0.17.10.1]
<sil2100> oSoMoN: yw!
<sil2100> Finally went through
<sil2100> (no LP timeouts)
-queuebot:#ubuntu-release- New binary: django-ipware [amd64] (bionic-proposed/none) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-labstack-gommon [amd64] (bionic-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gocarina-gocsv [amd64] (bionic-proposed/none) [0.0~git20180113.45cbb9c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assemblytics [amd64] (bionic-proposed/none) [0~20170131+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-rsc-qr [amd64] (bionic-proposed/none) [0.0~git20161121.48b2ede-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-publish [amd64] (bionic-proposed/none) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmailieer [amd64] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-common [amd64] (bionic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanook [amd64] (bionic-proposed/none) [1.26+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-etcd3gw [amd64] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-common [i386] (bionic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bd2k [amd64] (bionic-proposed/none) [1.14~alpha1.43-1] (no packageset)
<slangasek> doko: what's the resolution for linux-tools?  I can sort out octave-interval, but I haven't seen any decision yet on linux-tools which was the last blocker
 * tsimonq2 checks to see how much the queues were swamped after nodejs
<tsimonq2> Ah ok, might take a bit.
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ignition-common [arm64] (bionic-proposed/none) [1.0.1-1] (no packageset)
<tsimonq2> slangasek: Can you please process ubiquity-slideshow-ubuntu in Xenial Unapproved?
<tsimonq2> Would be good to get that over with.
-queuebot:#ubuntu-release- New binary: ignition-common [armhf] (bionic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted assemblytics [amd64] (bionic-proposed) [0~20170131+ds-1]
-queuebot:#ubuntu-release- New: accepted git-publish [amd64] (bionic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gocarina-gocsv [amd64] (bionic-proposed) [0.0~git20180113.45cbb9c-1]
-queuebot:#ubuntu-release- New: accepted golang-rsc-qr [amd64] (bionic-proposed) [0.0~git20161121.48b2ede-1]
-queuebot:#ubuntu-release- New: accepted python-bd2k [amd64] (bionic-proposed) [1.14~alpha1.43-1]
-queuebot:#ubuntu-release- New: accepted django-ipware [amd64] (bionic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-labstack-gommon [amd64] (bionic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted python-etcd3gw [amd64] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted gmailieer [amd64] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted nanook [amd64] (bionic-proposed) [1.26+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: ceph (artful-proposed/main) [12.2.1-0ubuntu0.17.10.1 => 12.2.2-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~17.10.1 => 17.2-35-gf576b2a2-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<xnox> tsimonq2, should the nodejs be actually a force sync, no?
<xnox> tsimonq2, it's using ssl1.1 now, which has always been disabled in both debian and ubuntu builds of openssl1.1?
<tsimonq2> xnox: No, that final bit of the delta is needed for autopkgtests to pass correctly.
<xnox> tsimonq2, please explain.
<ginggs> tsimonq2 xnox: probably not needed any more
<xnox> tsimonq2, note this new nodejs, is no longer using openssl1.0, but is using openssl1.1
<ginggs> tsimonq2: i asked you to test without it
<tsimonq2> Ah ok, I was talking with ginggs last night and I thought the final patch was still needed for tests.
-queuebot:#ubuntu-release- New binary: ignition-common [ppc64el] (bionic-proposed/none) [1.0.1-1] (no packageset)
<tsimonq2> xnox: Right, but that was only one part of the delta.
<xnox> tsimonq2, so in openssl1.0 in Ubuntu, we had sslv3 "visible" on the symbols and ABI level, but these were stub functions that did nothing. This was done in ubuntu to preserve ABI and not bump 1.0.0 to 1.0.2 like it was done in Debian.
<tsimonq2> xnox: Ah ok.
<xnox> with the 1.1.0 ABI neither Ubuntu nor Debian have sslv3 compiled, and we no longer ship the stub functions, thus it should be the same.
<tsimonq2> Understood, I'll force sync on the next Debian upload.
<xnox> tsimonq2, does nodejs pass the autopkgtests in debian ci?
<tsimonq2> xnox: afair, yes.
<xnox> cool.
<tsimonq2> (I'm on mobile, ftr)
<tsimonq2> So yeah, you know openssl better than I, I'll trust that the delta can be dropped :)
<tsimonq2> Thanks ginggs and xnox
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [s390x] (bionic-proposed/universe) [1:4.0.1-9] (no packageset)
-queuebot:#ubuntu-release- New binary: gnocchi [amd64] (bionic-proposed/universe) [4.2.0-0ubuntu1] (no packageset)
<nacc> slangasek: so symfony is stuck in b-p because of several other packages, which Debian appears likely to RM. (LP: #1748941) We would need to change src:civicrm ahead of Debian, but it already is uninstallable there. Would it be reasonable to move it to -proposed while we wait to see what Debian does to it? I'm checking on further reverse-deps.
<ubot5> Launchpad bug 1748941 in symfony (Ubuntu) "symfony 3.4.3+dfsg-1ubuntu4 stuck in bionic-propsed" [Undecided,New] https://launchpad.net/bugs/1748941
<xnox> nacc, i also am pondering if we need to drop monolog and/or its tests, as they fail with new phpunit and i'm struggling to fix them.
<xnox> upstream has stopped making releases; and their trunk is way ahead of what we currently ship.
<xnox> or should I just ship a snapshot of monolog?
<nacc> xnox: yeah i saw that :/
<nacc> xnox: so evenn with the namespaced test class, the tests faill?
<xnox> nacc, yes, and upstream checkout fails too.
<nacc> sigh
<xnox> missmatch of assertions thrown; no assertions made; etc.
<xnox> or uplaod with disabled tests....
<nacc> we'd need to patch symfony if we drop it, as it's a reverse-dep
<nacc> but that's ok
<slangasek> nacc: if the point is that we are not going to do the work to fix civicrm, which has an Ubuntu delta only because of the fixing we did of it for the *last* transition, then I would recommend just removing the package and letting it come back in only via Debian unstable
<xnox> nacc, i have fixed php-email-validator php-enum.
<nacc> xnox: thanks! i saw those go green :)
<xnox> nacc, so i think symfony should undo monolog integration package; and we should drop monolog too.
<nacc> xnox: i'm +1 on that
<nacc> slangasek: ack
<xnox> nacc, cause monolog and sabre-vobject-3 are the only two that are blocking phpunit at this point.
<xnox> nacc, could you unwind symfony & monolog then? I am past end of day....
<nacc> xnox: yep
<nacc> slangasek: subscribed ~ubuntu-archive to that bug, and put in an ordered sequence of removals. I believe that will together let symfony through and then I can do a follow-on version for what xnox just said
<nacc> xnox: in case you happen to still be EOD'd, did you already submit the retriggers for phpunit -> php-{enum,email-validator} ?
<nacc> *EOD'ing
<xnox> nacc, i can't remember. And i'm not seeing php-email-validator uploads anywhere, i must be blind and/or did not upload successfully.
<nacc> xnox: ok, i can look too, was it an upstream update?
<xnox> i believe so
<nacc> xnox: ok, i'll track it down, thanks!
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [ppc64el] (bionic-proposed/universe) [1:4.0.1-9] (no packageset)
<flexiondotorg> rbasak: Following on from earlier, is this in your remit?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/topmenu-gtk/+bug/1744912
<ubot5> Ubuntu bug 1744912 in topmenu-gtk (Ubuntu) "Please remove topmenu-gtk from the Bionic archive" [Undecided,New]
<nacc> flexiondotorg: no, that'd be an AA
<slangasek> nacc: awl just needed the retry button hit on its build failure; awl and davical should both come back into bionic shortly
-queuebot:#ubuntu-release- New binary: awl [amd64] (bionic-proposed/universe) [0.59-1] (no packageset)
<slangasek> nacc: you said "Remove src:drupal7 (for completeness)" but you didn't open a bug task on drupal7 here
<doko> slangasek: I pinged apw and sforshee, and apw deferred for sforshee for testing the kernels
<slangasek> doko: and what about temporarily breaking the linux-tools packages?
<slangasek> and what are the chances of properly fixing linux-tools again to statically link bfd+liberty instead of dynamically linking them?
<slangasek> since this is biting us in two different ways right now
<doko> I pinged them about it too
<doko> slangasek: and sure, I'm fine to break linux-tools. it's just some perf stuff
<nacc> slangasek: re: {awl,davical}, thanks! sorry for missing that
<nacc> slangasek: re: drupal7, task opened
<slangasek> sforshee, apw: ^^ I think doko and I are conspiring to leave the linux-tools-* packages broken in bionic release pocket until the new versions migrate.  And linux-tools should be re-fixed to statically link libbfd+libiberty instead of dynamically linking. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/783660
<ubot5> Ubuntu bug 783660 in linux (Ubuntu Oneiric) "linux-tools: perf should link statically to libbfd" [Low,Fix released]
<apw> slangasek: okies, I have a patch to stop tools using libbfd, is liberty also unversioned library nightmare?
<slangasek> apw: stop using, or static linking?
<apw> stop using, we have intended to all along but upstream stopped us from disabling it
<apw> by changing and breaking the opt-out
<slangasek> apw: it appears libbfd has the library versioning nightmare, libiberty does not
<slangasek> (I think because libiberty is *only* available static?)
<apw> but it continues to link liberty, then we ought to be OK
<apw> I will send that out tommorrow when tested better
<slangasek> confirmed, libiberty is static-only
<slangasek> tsimonq2: ironically, the slideshow SRU is to update the screenshot used; but the screenshot is already stale wrt the current lubuntu.me website
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (xenial-proposed) [113.1]
<tsimonq2> slangasek: It's the one from Bionic, and while it is indeed a little bit outdated, it's better than nothing :)
<slangasek> ok
<tsimonq2> slangasek: What's your opinion irt waiting the usual 7 days?
<tsimonq2> Keep it like the normal SRU policy or let it right in when confirmed?
<slangasek> tsimonq2: the 7 day waiting period is a default, not a mandate; but also, this doesn't seem like an SRU that we need to hurry, since it only affects the installer and we're definitely not going to miss the point release
<blackboxsw> infinity: I don't know if you have already been pinged on pending cloud-init SRU uploades for xenial & artful-proposed. If there is time today,  we've got a replacement for cloud-init 17.2.30 -> 17.2.35 which contains fixes discovered during SRU testing. So, we need to remove 17.2.30 from xenial/artful proposed and queue 17.2.35 instead.
<blackboxsw> our SRU bug has been updated accordingly.https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1747059
<ubot5> Ubuntu bug 1747059 in cloud-init (Ubuntu Artful) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2.30-gf7deaf15-0ubuntu1" [Medium,Fix committed]
<doko> apw, slangasek, yes libiberty is only static
<apw> doko, ok then this ought to be sufficient
<slangasek> apw: ok, in the meantime imma go break linux-tools-* now, thanks :)
-queuebot:#ubuntu-release- New binary: golang-github-gokyle-twofactor [amd64] (bionic-proposed/universe) [0.0~git20170918.eaad188-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-35.39] (core, kernel)
<doko> jbicha: any idea what keeps ruby* in main in -release? it already wants to demote in -proposed
<infinity> slangasek: Of course, building linux-tools statically against binutils implies you'd also be adding a Built-Using header, which should lead to the same block, if britney were properly respecting Built-Using.
<infinity> slangasek: (iow: this only fixes migration because you're taking advantage of bugs in the tools)
<slangasek> infinity: Built-Using is important to reconcile for release, but I'm not sure it should gate migration
<infinity> slangasek: It may still be correct to link bfd statically anyway (and if that's generally true, maybe it should stop providing a dynamic library to link against), but yeah, the kernel/binutils coupling in migration *should* exist regardless of static or dynamic linkage.
<infinity> slangasek: Examining all built-using a few weeks before release and making sure they're all sane would probably also be fine-ish, but that's not something we've done either.
<infinity> (note I say a few weeks, not a few days, because if a static link is lagging by months, it could take non-trivial time to unwind why and fix it)
<jbicha> doko: see the Dec 6 changelog for https://tracker.debian.org/media/packages/t/texlive-bin/changelog-2018.20180119.46378-1
<doko> jbicha: and?
<doko> no ruby mentioned
<jbicha> doko: "remove outdated deps on ruby, wish, python"
<doko> ahh, that's 2017.20170613.44572-7
<doko> and we should build with our recent poppler
<doko> hmm, do we?
<doko> slangasek: I'm not accepting the sagemath binaries in NEW (mpfr4 dependency)
-queuebot:#ubuntu-release- New: accepted awl [amd64] (bionic-proposed) [0.59-1]
-queuebot:#ubuntu-release- New: accepted gnocchi [amd64] (bionic-proposed) [4.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-gokyle-twofactor [amd64] (bionic-proposed) [0.0~git20170918.eaad188-1]
-queuebot:#ubuntu-release- New: accepted ignition-common [arm64] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ignition-common [i386] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ignition-common [amd64] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ignition-common [ppc64el] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ignition-common [armhf] (bionic-proposed) [1.0.1-1]
<doko> ohh, there some times when I love mail spams ... [ubuntu/bionic] * (Accepted)  102 times :-)
-queuebot:#ubuntu-release- New: accepted sagemath [amd64] (bionic-proposed) [8.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted sagemath [arm64] (bionic-proposed) [8.1-3ubuntu1]
<slangasek> doko: should actually be fine to accept sagemath since it's currently not in bionic
<acheronuk> slangasek: do you know if a autopkgtest for a package can be allocated to a builder with a larger disk space available. I have a new test in a package that "All benchmarks create a relatively large directory tree and then watch that recursively"
<acheronuk> but it gets out of space fails
<acheronuk> I'll probably disable it as even upstream CI seems to struggle. but I was curious
<slangasek> acheronuk: no; the autopkgtest infrastructure relies, in the same way launchpad does, on having generic units for scalability
<slangasek> acheronuk: actually, I take that back - we do have a whitelist of 'big packages' that take an m1.large instance instead of the default... I suspect those do have larger disk
<tsimonq2> slangasek: To be specific, this little gem: https://cgit.kde.org/kcoreaddons.git/commit/autotests/kdirwatch_unittest.cpp?id=421e85344db729f1be3042245c70289643215ab0
<slangasek> tsimonq2: is that actually a disk space problem?  a 'large directory tree' for inotify purposes shouldn't really require a lot of disk space, just a lot of inodes
<slangasek> from the description, this test seems like a profiling aid to inform development, not something that should be run as a regression test
<slangasek> like, the only circumstance under which this test should fail is if it's not a fit for the infrastructure (i.e. too small disk etc); so this test passing or failing tells you nothing about whether the package has been broken
<slangasek> and in particular if this is an expensive test, it's bad design to include it in your CI in such a form
<acheronuk> yes, which is why I was going towards disabling it.
 * slangasek nods
<tsimonq2> slangasek: Good question; I don't know much about the test, just providing context :)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-35.39]
-queuebot:#ubuntu-release- New binary: psautohint [s390x] (bionic-proposed/none) [1.1.0-1] (no packageset)
<tsimonq2> slangasek: SRU for ubiquity-slideshow-ubuntu> ah, just seeing this now, ack
-queuebot:#ubuntu-release- New binary: psautohint [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psautohint [i386] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psautohint [ppc64el] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psautohint [arm64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psautohint [armhf] (bionic-proposed/none) [1.1.0-1] (no packageset)
<tsimonq2> I just got the 65 day nag email about libindi. Fixing bug 1747306 will unstick that (and I filed it more than a week ago). Could someone please take a look?
<ubot5> bug 1747306 in indi-apogee (Ubuntu) "RM: obsolete and Ubuntu-only" [High,New] https://launchpad.net/bugs/1747306
<slangasek> tsimonq2: what about indi-sbig?
<tsimonq2> slangasek: I haven't considered that because it doesn't seem to be directly blocking the libindi transition, but that should probably go too, yes.
 * tsimonq2 checks rdeps real quick
<tsimonq2> All clear it seems.
<slangasek> tsimonq2: it does directly block it, but because it only exists on amd64+i386, depending on which architecture britney reports on first, you may not get info about it in update_output
<tsimonq2> slangasek: ah ok
<slangasek> tsimonq2: what does "part of the INDI modules source tarball" mean? Does this mean the indi-apogee package is redundant with something else in the archive?
<tsimonq2> slangasek: From what I can tell, upstream these leaf modules are now part of one "3rd party" tarball instead of separate tarballs.
<tsimonq2> slangasek: I haven't investigated this in a while, give me a min to see if there's a replacement in the archive :)
<slangasek> tsimonq2: ok - I just wasn't sure if "indi modules source tarball" maybe meant it was now provided by libindi.  If it's not, that's fine too
<tsimonq2> slangasek: nope, two separate tarballs
<tsimonq2> slangasek: And it seems that these two packages (apogee and sbig) are the only ones in Ubuntu. The upstream author has a PPA, but none of these are in the archive with the exceptions of the aforementioned packages.
<tsimonq2> To be honest, I haven't quite dug into whether or not multiple source packages sharing one tarball is possible, and if it is, if it's acceptable.
<tsimonq2> (two separate tarballs meaning libindi and 3rdparty)
<slangasek> generally you don't want two source packages sharing one tarball, you want one source package building multiple binary packages from that tarball
<tsimonq2> Right, that's what I thought.
<tsimonq2> I just don't know if that's in policy or not :)
<slangasek> the only case where you might want to use the same tarball in two source packages is when the two source packages need to be in different archive components
<slangasek> but we've thankfully gotten away from needing to do that most of the time
<tsimonq2> I thought archive administrators could cherry pick specific binaries into specific components?
<tsimonq2> I mean, with that existing, out of curiosity, in what scenario might that have to be done still?
<slangasek> tsimonq2: in principle, no package in universe or main should depend on or build-depend on anything in multiverse.  So if you have a package which is free software but some of its binary packages need non-free bits in order to build, *maybe* you want to split that into universe and multiverse sources.
<tsimonq2> slangasek: Ah, gotcha.
<tsimonq2> slangasek: I get the build-depends part of that because that's shared for the whole source package, but couldn't you have a binary that needs something in multiverse in a main/universe source package be cherry-picked into multiverse?
<slangasek> rbasak: do you happen to know any reason for rmysql to build-depend explicitly on mariadb instead of mysql-deafults?
<slangasek> tsimonq2: it's possible, and that may have been done here and there, though it also doesn't make me comfortable
<tsimonq2> slangasek: Me neither. :P
<tsimonq2> slangasek: Ok, thanks.
<tsimonq2> slangasek: indi-sbig> were you going to RM that too or should I file an additional bug?
<doko> slangasek: please update the bad-test for mercurial, or because that succeeded only for the very first time, maybe reset it?
<slangasek> doko: my mercurial hint is "testdep removed from the archive" on all archs, which is not the reason for the current failure on ppc64el
<doko> slangasek: so I should add it that it fails again, and then you update the hint?
<slangasek> doko: that's fine with me.  but if you want me to add a badtest hint for a different failure, I need analysis to go with it
<doko> well, I retry, failing network test
#ubuntu-release 2018-02-13
<doko> slangasek: it's failing the same way as in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/m/mercurial/20171118_082258_cef1c@/log.gz
<doko> for the version that you added the hint. so apparently your comment is not complete
<slangasek> doko: the hint I added was for all architectures because I knew it would be broken in a cross-architecture way.  the above confirmation is sufficient for me, I'll update the hint
<nacc> slangasek: when you get a moment, i believe i've got everything but monolog explained in LP: #1749001 (to unblock phpunit)
<ubot5> Launchpad bug 1749001 in phpunit (Ubuntu) "phpunit 6.5.5-1ubuntu2 stuck in bionic-proposed" [Undecided,New] https://launchpad.net/bugs/1749001
-queuebot:#ubuntu-release- New binary: davical [amd64] (bionic-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted davical [amd64] (bionic-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted psautohint [arm64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted psautohint [i386] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted psautohint [s390x] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted psautohint [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted psautohint [ppc64el] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted psautohint [armhf] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [ppc64el] (bionic-proposed) [1:4.0.1-9]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [s390x] (bionic-proposed) [1:4.0.1-9]
<slangasek> why does zorp's autopkgtest have stderr only on s390x? :P
<slangasek> doko: refreshed a stack of hints, a few more stuck packages should be happy to migrate now
<slangasek> xnox: what's the net on systemd/237-1ubuntu3?  seems to have regressed all the best autopkgtests
<nacc> xnox: i think i can get monolog's tests to pass, just need to find one more upstream patch to backport
<slangasek> nacc: what's the purpose of the phpunit task on that bug?
<slangasek> acheronuk: I see there are some manually triggered kde test runs with --all-proposed; are there any non-all-proposed tests we should kill in favor, to save the armhf queue?
<nacc> slangasek: my own bookkeeping
<tsimonq2> infinity: Mind taking another look at bug 1746807 when you have a chance?
<ubot5> bug 1746807 in debian-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<juliank> I have a few badtests for artful: https://paste.ubuntu.com/p/DWHsD6BfsT/ - this does not fully unblock the util-linux transitions, but the remaining failures (nm on arm64 and ppc64el) sound temporary.
<juliank> I'm rerunning those
<acheronuk> slangasek: all of them? for frameworks it would actually make sense for tests against to be delayed, then run against multiple triggers in the first instance. rather than have them queue up as individual ones
<rbasak> slangasek: no, but it looks like you've had them fix it?
<slangasek> acheronuk: well, I can't make britney automatically calculate the right trigger line; but given a list of package names, I can remove the currently-scheduled tests from the queue and let you add your own triggers manually
<slangasek> rbasak: yeah, it built fine here w/ changed build deps so I went ahead and uploaded
<acheronuk> slangasek: ./retry-autopkgtest-regressions --state RUNNING | grep 5.43.0 | grep armhf | awk -F"[=,&]" '{print $6}' | sort | uniq
<acheronuk> would that make sense?
<acheronuk> not up to full caffeine quota yet
<doko> slangasek: hmm, c-t-b demoted?
<doko> a little bit surprised
<doko> or I don't understand the email to bionic-changes
-queuebot:#ubuntu-release- Unapproved: iscsitarget (trusty-proposed/universe) [1.4.20.3+svn499-0ubuntu2.4 => 1.4.20.3+svn499-0ubuntu2.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: iscsitarget (xenial-proposed/universe) [1.4.20.3+svn502-2ubuntu4.4 => 1.4.20.3+svn502-2ubuntu4.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rtl8812au (xenial-proposed/universe) [4.3.8.12175.20140902+dfsg-0ubuntu2 => 4.3.8.12175.20140902+dfsg-0ubuntu2.1] (no packageset)
<doko> slangasek, infinity: why is glibc removed from -proposed?
<juliank> hints for artful, now complete for all wrong util-linux rdep regressions: https://paste.ubuntu.com/p/2VmbsNTBRF/
<juliank> I'd do a merge proposal, but since the files are named per member, that's kind of hard :)
<juliank> if somebody could apply them, util-linux artful SRU would be ready for release as well
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-35.39~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-116.140] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (xenial-proposed) [1.4.20.3+svn502-2ubuntu4.5]
<doko> $ sudo apt install lib32gcc1 libc6-i386
<doko> Reading package lists... Done
<doko> Building dependency tree
<doko> Reading state information... Done
<doko> Some packages could not be installed. This may mean that you have
<doko> requested an impossible situation or if you are using the unstable
<doko> distribution that some required packages have not yet been created
<doko> or been moved out of Incoming.
<doko> The following information may help to resolve the situation:
<doko> The following packages have unmet dependencies:
<doko>  libc6-i386 : Depends: libc6 (= 2.26-0ubuntu2) but 2.26-0ubuntu4 is to be installed
<doko> E: Unable to correct problems, you have held broken packages.
<doko> nice
<acheronuk> doko: is util-linux 2.32 likely to get into 18.04?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-35.39~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-116.140]
<doko> acheronuk: you should ask the one who did the last merge
<stikonas> doko: hi, I wanted to ask if util-linux-2.32 might be available on 18.04?
<doko> I don't know
<stikonas> now they have tagged rc1, so it should be released in about 4 weeks
<stikonas> oh ok
<acheronuk> doko: ok. was suggested to ask you. I will poke at the changelog
<stikonas> well, I only need one patch from 2.32... And 2.31.1 will probably be synced from Debian anyway
<acheronuk> xnox: are you able to comment on that? likelihood of  util-linux 2.32?
-queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (xenial-proposed) [4.3.8.12175.20140902+dfsg-0ubuntu2.1]
<DalekSec> acheronuk: What's so interesting about it?
<acheronuk> stikonas: ^^^ ? can you explain?
<stikonas> DalekSec: DalekSec: well, for me it is this commit https://github.com/karelzak/util-linux/commit/8175ed3d74adacc895657ded7546cb3c5deeabad
<stikonas> all other pathes that I need are in 2.31.1
<acheronuk> for kpimcore?
<acheronuk> *kpmcore
<stikonas> acheronuk: yeah, for kpmcore sfdisk backend
<stikonas> which will be necessary for KAuth support
<stikonas> acheronuk: libparted backend is just too hard to get working with kauth due to all library calls
<rbalint> could someone please force-badtest unattended-upgrades/all/arm64 ? the testbed seems to have issues with the systemd restart test but everything else is green
<acheronuk> stikonas: and this is so you can continue development of kpmcore using the LTS base?
<acheronuk> just asking for the logs if/when xnox can have a look
<stikonas> acheronuk: well, I don't develop on LTS base myself. But maybe some other people will
<acheronuk> right
<stikonas> or if somebody wants to have LTS base and newer kpmcore
<stikonas> so without that patch https://github.com/karelzak/util-linux/commit/8175ed3d74adacc895657ded7546cb3c5deeabad I can't deactivate boot flag on MBR partitions with sfdisk
<LocutusOfBorg> mapreri, ginggs tsimonq2 what is the status for libunistring? I'm preparing some no change rebuilds in my ppa in some minutes, and added a tracker
<LocutusOfBorg> anybody on release team can confirm please the transition?
<tsimonq2> LocutusOfBorg: No clue, sorry. But I'm willing to help if needed.
<juliank> LocutusOfBorg: Are they planning a transition?
<juliank> I already prepared a merge of libunistring 4 weeks ago for gnutls28, but ended up going with the internal one first.
<LocutusOfBorg> juliank, we are really using an old version, I think we should update
<juliank> I think so too
<juliank> I already have a 0.98-1ubuntu1 sitting around
<juliank> 0.9.8
<juliank> but if someone else wants too, I don't mind either. Just notify me so I can turn it on in gnutls28 too, or do it yourself.
<juliank> here, BTW: https://launchpad.net/~juliank/+archive/ubuntu/unistring2/+packages
<juliank> I delayed uploading it because the backlog was huge
<juliank> LocutusOfBorg: did you do your own merge?
 * juliank is just confused because he left a link on MoM for the unistring merge
<juliank> Oh, I see there is a bug I probably should have assigned to me :)
<tjaalton> can a package depend on a foreign package?
<juliank> from apt and dpkg's side, sure
<juliank> britney might not like it, idk
<tjaalton> ok
<tjaalton> well not depend, but recommend so that if multiarch isn't set up it would still install
<tjaalton> so an amd64 pkg could recommend: libfoo:i386
<LocutusOfBorg> I tried a sync, I honestly don't understand why a merge is needed... what about opening a silo and doing the transition there?
<juliank> LocutusOfBorg: The only remaining change I had was "Link test-lock with -Wl,--no-as-needed.", I honestly did not test whether it worked without the change.
<juliank> LocutusOfBorg: But yes, a silo would be nice.
<juliank> And if a sync works, that's better than a merge, obviously :D
<juliank> tjaalton: that should work
<tjaalton> ok good
<LocutusOfBorg> juliank, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa it builds fine
<juliank> LocutusOfBorg: OK. Should use copy-package to sync it to a silo PPA, though, I guess
<juliank> (rather than having a pointless build1 in it)
<juliank> The no-change rebuilds can be triggered semi-automatically
<LocutusOfBorg> I can also manually edit changes file :p
<juliank> LocutusOfBorg: That's silly
<LocutusOfBorg> :)
<juliank> copy-package is much nicer
<juliank> LocutusOfBorg: So should I help? I can create all the rebuilds in less than two minutes I guess, I'm heavily scripted :)
<LocutusOfBorg> ./copy-package --from=debian --from-suite=sid libunistring --to=ppa:ci-train-ppa-service/ubuntu/3141 --to-suite=bionic
<LocutusOfBorg> I did this
<LocutusOfBorg> :)
<LocutusOfBorg> I prefer sometimes to learn some new bits
<juliank> xnox gave me a secret weapon to do the no-change rebuilds automatically :D
<LocutusOfBorg> e.g. from-suite=unstable is wrong, from-suite=sid works
<LocutusOfBorg> juliank, I have one from Colin
<LocutusOfBorg> anyhow, now we should wait for it to build, and then I'll upload the no change rebuilds
<LocutusOfBorg> BTW; feel free to upload your gnutls28 pet package
<juliank> LocutusOfBorg: Well then knock yourself out with the no-change rebuilds, and I prepare a gnutls28
<LocutusOfBorg> thanks!
<LocutusOfBorg> btw my script is: copy-paste from there the packages
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/auto-libunistring
<juliank> well, what I do is run rebuild-for libunistring <package name> for each package
<LocutusOfBorg> do some cat foo |grep build |cut -d " " -f 1 |cut -f 1 -d "[" > list
<juliank> possibly parallel
<juliank> :D
<LocutusOfBorg> and then pass the output to my rebuild or rebuild-ppa script
<LocutusOfBorg> for i in `cat list`; do rebuild-ppa $i "reason"; done
<LocutusOfBorg> we should really get such scripts in ubuntu-archive-tools :p
<juliank> I think the rebuild script should be in ubuntu-dev-tools
<LocutusOfBorg> or ubuntu-release-tools
<LocutusOfBorg> yes sure ubuntu-dev-tools I meant
<LocutusOfBorg> (or the bzr repo from release team)
<LocutusOfBorg> since they issue a lot of rebuilds
-queuebot:#ubuntu-release- New binary: libgweather [ppc64el] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgweather [s390x] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
<juliank> LocutusOfBorg: I'm ready, I could even upload now - it goes into depwait due to b-d on >= 0.9.7
-queuebot:#ubuntu-release- New binary: libgweather [amd64] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
<juliank> LocutusOfBorg: Or ping me once you upload :)
-queuebot:#ubuntu-release- New binary: libgweather [arm64] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgweather [i386] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgweather [armhf] (bionic-proposed/main) [3.27.4-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [s390x] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
<LocutusOfBorg> juliank, safe to go :)
-queuebot:#ubuntu-release- New binary: vala [amd64] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (bionic-proposed/universe) [0.39.7-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted vala [amd64] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (bionic-proposed) [0.39.7-1]
-queuebot:#ubuntu-release- New binary: mesa [s390x] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
<juliank> ~ubuntu-sru: Just a reminder that I have some force-badtests for getting util-linux unstuck in artful: https://paste.ubuntu.com/p/DWHsD6BfsT/
-queuebot:#ubuntu-release- New binary: mesa [amd64] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
<rbasak> slangasek: could you look at mysql-5.7 in proposed for me please? It's been hung up on the PHP transition for weeks. I think it's pretty clear that it's not a regression in MySQL (which isn't a transition, just a microrelease bump). nacc says untangling horde is at least a week away, and I'd really like to get some wider testing on unrelated mysql-5.7 packaging changes we made a month ago. Could
<rbasak> you consider bumping it through please?
<LocutusOfBorg> xnox, util-linux merge please?
<blackboxsw> RAOF: if you are point on SRUs today, do you think there is time for a cloud-init proposed merge for xenial & artful. We need to reject 17.2.30 and propose 17.2.35 which has SRU-fixes.
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<Odd_Bloke> rbasak: Steve is out today and tomorrow, FYI.
<rbasak> Thanks
-queuebot:#ubuntu-release- New binary: mesa [i386] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: mesa [ppc64el] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libgpiod [s390x] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [s390x] (bionic-proposed/none) [10.8.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgpiod [amd64] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgpiod [i386] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgpiod [ppc64el] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgpiod [arm64] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mesa [arm64] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libgpiod [armhf] (bionic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mesa [armhf] (bionic-proposed/main) [18.0.0~rc4-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: texhyphj [amd64] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minidb [amd64] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [amd64] (bionic-proposed/none) [10.8.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [ppc64el] (bionic-proposed/none) [10.8.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [arm64] (bionic-proposed/none) [10.8.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1021.23] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1021.23]
<tsimonq2> Can someone please RM
<tsimonq2> ...indi-sbig from bionic?
<tsimonq2> (yay for \n in clipboard with the name of the pkg -_-)
<tsimonq2> See the discussion I had with slangasek last night for ref
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<jbicha> please move gnome-tweak-tool and gnome-orca to oldlibs, see LP: #1747033
<ubot5> Launchpad bug 1747033 in orca (Ubuntu) "Move gnome-tweak-tool and gnome-orca to oldlibs" [Undecided,New] https://launchpad.net/bugs/1747033
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<slangasek> juliank: the hint filenames being per-team member is a historical wart; feel free to raise an MP against mine, and members of the SRU team should feel free to accept your MP ;)
<slangasek> tsimonq2: bug report against indi-sbig as well, please
<tsimonq2> slangasek: per-team files> Is that a bug that can be fixed, or will it Just Stay Like That? Maybe like a "misc" file if not complete rework?
<tsimonq2> slangasek: indi-sbig> ack
<slangasek> tsimonq2: new filenames have to be added to the britney source tree first; we have broad agreement to fix this by moving hints to a single file named for the team, but no one has prioritized this
<tsimonq2> slangasek: And y'all accept MPs to Ubuntu's britney2 and the hints repo? :P
<slangasek> yes
<tsimonq2> I'll keep that in mind ;)
<juliank> slangasek: https://code.launchpad.net/~juliank/britney/hints-ubuntu-artful/+merge/337667
<juliank> Could create a file "contrib" and it to to britney :D
<slangasek> acheronuk: seems to me we don't want to filter only armhf out of that list; aren't there some of these in the backlog still on other archs?
<slangasek> acheronuk: I'm leaning towards this: retry-autopkgtest-regressions --state RUNNING | sed -n -e'/all-proposed/d; /5.43.0/s/.*package=\([^&]\+\).*/\1/p' | sort | uniq
<acheronuk> if that catches extra that would be better together, then I guess good. what state would cancelling test runs put them into on the excuses page?
<slangasek> acheronuk: they'll still be listed in state 'Test in progress', and you'll be able to reschedule the missing tests manually
<slangasek> acheronuk: let me pastebin the list of packages for you, so you have the full list of what I'm cancelling
<slangasek> acheronuk: https://paste.ubuntu.com/p/4zNXrmFt86/
<slangasek> I am being somewhat cautious and reviewing the matches for each package before cancelling, so it'll take me a little while
<acheronuk> ok, so I could still use --state=running to re-queue
<slangasek> but considering some of these have 5+ tests scheduled for the same package and all will fail (AIUI), this should help
<slangasek> acheronuk: yes
<acheronuk> slangasek: yeah, especially as I have new Plasma release nearly ready to upload
<acheronuk> this will be the last frameworks before feature freeze, and release cadence of plasma will slow down as well, so not as nasty as it sounds
<slangasek> juliank: ah, and the crash autopkgtest still failed, again w/ ddebs.u.c issues: http://autopkgtest.ubuntu.com/packages/c/crash/bionic/s390x
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [s390x] (bionic-proposed/universe) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [ppc64el] (bionic-proposed/universe) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [amd64] (bionic-proposed/universe) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [i386] (bionic-proposed/universe) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [armhf] (bionic-proposed/universe) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [arm64] (bionic-proposed/universe) [3.27.90-1] (no packageset)
<juliank> slangasek: bad timing
<juliank> slangasek: I just verified the file and it matches what the Release file says
<juliank> the ddeb retriever unfortunately is not very atomic at all
<slangasek> acheronuk: amd64, arm64, i386 queues down by ~160; armhf queue down by ~620. and plenty of room for you to manually schedule anything you need to
<juliank> I guess we should make it more atomic
<juliank> basically just do all writes into .new files, and then rename them all at the end
<juliank> or since we're rebuilding the indices for a changed pocket completely anyway
<slangasek> juliank: would be best practice, but not necessarily the highest priority :)
<acheronuk> slangasek: thanks. looks a scary list when I did a dry run, but must be better this way
<juliank> we can just replace the pocket almost atomically
<slangasek> acheronuk: I'm assuming that you're only batching one test for each package+arch to be tested, using multiple triggers / or all-proposed?
<juliank> by writing to bionic.new/, mv bionic bionic.old, and then mv bionic.new bionic
<juliank> also has the side effect of making it less possible to mess up stuff :D
<slangasek> juliank: why, I believe you've just described how the launchpad publisher works
<slangasek> anyway, afk now
<acheronuk> slangasek: both, which retry-autopkgtest-regressions essential does
<acheronuk> *essentially
<slangasek> hmm, ttbomk retry-autopkgtest-regressions won't auto-batch for you?
<acheronuk> slangasek: what do you mean by auto-batch?
<acheronuk> it's giving output such as: https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=armhf&package=libkf5sane&trigger=ktextwidgets%2F5.43.0-0ubuntu1&trigger=qtbase-opensource-src%2F5.9.3%2Bdfsg-0ubuntu4&all-proposed=1
<slangasek> acheronuk: if update_excuses shows multiple pending tests for the same package triggered by different uploads, it won't automatically translate that into a single test request with multiple triggers
<acheronuk> the test urls I'm getting beg to differ
<slangasek> that is interesting
<slangasek> possibly that behavior is only when you specify --all-proposed
<acheronuk> I'm only getting a sngle test request per package, per arch, with multiple triggers
<slangasek> (/hopefully/ it is)
<acheronuk> trying it to see
<acheronuk> slangasek: nope. without all-proposed gives me urls with multiple triggers as well
<acheronuk> it is how it has seemed to work for me since I started using that
<nacc> xnox: finally got php-monolog working!
<nacc> xnox: sending the massive patches to debian (there's already a bug filed ther
<RAOF> blackboxsw: if you're here, could you please re-upload cloud-init with *all* the changes since the last version in -updates in the _source.changes file?
<blackboxsw> bah I don't have upload perms for that yet .... Though I've started my https://wiki.ubuntu.com/ChadSmith/DeveloperPerPackageUploadApplication
<blackboxsw> I'll ping smoser my sponsor, but it's EOD for him. so probably tomorrow
-queuebot:#ubuntu-release- New binary: libreoffice [arm64] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<nacc> blackboxsw: if you just need a sponsor, i can help
<blackboxsw> nacc: that'd be excellent thank you sir.
<nacc> blackboxsw: sure, bug # and debdiff available?
<blackboxsw> nacc: family is calling for dinner help so I think I'll have to bail on this for today. I'd been working with MPs against cloud-init's upstream git branches  https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337516  to try to service our SRU bug: #1747059
<ubot5> bug 1747059 in cloud-init (Ubuntu Artful) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2-35-gf576b2a2-0ubuntu1~16.04.1" [Medium,Fix committed] https://launchpad.net/bugs/1747059
<blackboxsw> I can go through the motions of creating the debdiff for review sponsorship at that point.
<nacc> blackboxsw: RAOF: if it's just the same version with right -v, i can do it
<nacc> RAOF: did you already reject the upload that was done?
<RAOF> nacc: I haven't rejected it yet; I'm just reviewing the rest of it so that we don't have to bounce through multiple reviews.
<nacc> RAOF: ack, since i'd be reusing the same version, I assume I need to wait on your reject (it can be post-review)
<nacc> blackboxsw: i think i just need the orig tarball
<RAOF> nacc: Yeah, that's right. I shouldn't be too much longer.
<RAOF> nacc: You should be able to get the orig tarball from LP?
<nacc> yep, doing that now, i realize, RAOF :)
-queuebot:#ubuntu-release- Unapproved: tor (xenial-proposed/universe) [0.2.9.11-1ubuntu1~16.04.1 => 0.2.9.14-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (artful-proposed) [17.2-35-gf576b2a2-0ubuntu1~17.10.1]
#ubuntu-release 2018-02-14
<nacc> RAOF: if i'm reading it right, just one changelog stanza missing?
<RAOF> That's what it looks like to me, yes.
<nacc> RAOF: i'm ready to upload, if so, if that's good by you
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.1]
<RAOF> I've just rejected both. You might need to wait for LP to process the removals before it'll let you upload again, but as soon as it lets you upload you're good to go :)
<nacc> RAOF: i assume that one is the same rejection reason?
<RAOF> nacc: Correct; both xenial and artful need the changelog entries.
<nacc> RAOF: ack, i'll wait a bit and upload them both
-queuebot:#ubuntu-release- Unapproved: tor (artful-proposed/universe) [0.3.0.10-1 => 0.3.0.13-0ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tor [source] (xenial-proposed) [0.2.9.14-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted tor [source] (artful-proposed) [0.3.0.13-0ubuntu1~17.10.1]
<nacc> blackboxsw: RAOF: uploaded
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~17.10.1 => 17.2-35-gf576b2a2-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.2-35-gf576b2a2-0ubuntu1~17.10.1]
<nacc> blackboxsw: dpb1 --^ should be ok now, fyi
<blackboxsw> nacc:  thanks for the lift there. just got back
<blackboxsw> it saves another day of waiting on -proposed publish. thanks again
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.1]
<jbicha> RAOF: you're not a full Archive Admin, right?
<RAOF> jbicha (IRC) You are correct.
<jbicha> is there a list that shows which are full Archive Admins?
<tsimonq2> jbicha: My first guess would be https://launchpad.net/~ubuntu-archive/+members
<jbicha> we should just promote you and then we won't have this confusion :)
<tsimonq2> ahh
<tsimonq2> hm
<tsimonq2> Yeah, that is confusing if RAOF isn't a "full" AA
<RAOF> Yeah, yeah.
<RAOF> I've never *quite* got the training :)
<tsimonq2> Why don't you? :)
 * jbicha adds AA Training to RAOF's calendar
<RAOF> Partially because UTC+11 is not the most awesome timezone for AA overlap :)
<RAOF> But yeah, I just need to make scheduled time for it.
<dpb1> nacc: ty
<jbicha> RAOF: if you were, LP: #1747033 is interesting. it's not listed as a task at https://wiki.ubuntu.com/ArchiveAdministration
<ubot5> Launchpad bug 1747033 in orca (Ubuntu) "Move gnome-tweak-tool and gnome-orca to oldlibs" [Undecided,New] https://launchpad.net/bugs/1747033
<jbicha> I wonder how many mismatched packages like that we have. I had a test case in my original bug to demonstrate how it causes problems for transitional pkgs
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [amd64] (bionic-proposed/none) [0.22-1] (no packageset)
<cpaelzer> still waiting for an ack by a MIR Team member on bug 1744072 to then do the seed changes
<ubot5> bug 1744072 in NTP Charm "[MIR] Chrony in 18.04" [Medium,Triaged] https://launchpad.net/bugs/1744072
<cpaelzer> if a MIR Team member would have some time that would be great
<rbasak> The git "moved" URL at https://code.launchpad.net/~ubuntu-release/britney/britney2-ubuntu is broken
<rbasak> It should be https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu I think
<juliank> ping: https://code.launchpad.net/~juliank/britney/hints-ubuntu-artful/+merge/337667
<juliank> jbicha: It seems there needs to be a tool that checks for packages with oldlibs in the package, but different override
<juliank> at least
<juliank> Or something that checks for transitional package not in oldlibs
<juliank> the list is: http://paste.ubuntu.com/p/dRcv7pS5Rh/
<juliank> http://paste.ubuntu.com/p/myDqxwCfhH/
<juliank> ^ 359 packages that have transitional in their description, but not in oldlibs, hence preventing apt from migrating the autobit
<juliank> 2 might be false positives
<juliank> This list only contains packages where transitional appears in the short description: http://paste.ubuntu.com/p/phCsJgQ2D3/
<juliank> better lists: http://paste.ubuntu.com/p/Qf5gCDCB8m/ (long), http://paste.ubuntu.com/p/dCp6xWgqxz/ (names only)
<juliank> Found by: grep-dctrl -FDescription transitional --and --not -FSection oldlibs -s Package,Section,Size,Description  /var/lib/apt/lists/mirrors.ubuntu.com_mirrors.txt_dists_bionic*Packages | sort-dctrl
<juliank> um, I missed the ones with uppercase transitional
<juliank> 545 packages: http://paste.ubuntu.com/p/PDbWG2Zfvg/ (long), http://paste.ubuntu.com/p/gM8hFJ7TbX/ (names)
<juliank> 57 in main
<juliank> Now somebody just needs to xargs that list into change-override --section=oldlibs and we're done :D
-queuebot:#ubuntu-release- Unapproved: pulseaudio (artful-proposed/main) [1:10.0-2ubuntu3 => 1:10.0-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.7 => 1:8.0-0ubuntu3.8] (core)
<jbicha> juliank: sounds like good AA training material to me
<tjaalton> could an AA release mesa from bionic NEW?
-queuebot:#ubuntu-release- New: accepted mesa [amd64] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mesa [armhf] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mesa [ppc64el] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mesa [arm64] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mesa [s390x] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mesa [i386] (bionic-proposed) [18.0.0~rc4-1ubuntu1]
<tjaalton> hats off :)
<jbicha> libgweather too please
<xnox> slangasek, currently i'm blaming src:lvm2 which i want to demote to bionic-proposed; and push the artful's src:lvm2 back into bionic-release
<arges> rbasak: reviewing xenial upload queue atm. starting from the top
<rbasak> ack
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (artful-proposed) [2.9.0-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.4]
-queuebot:#ubuntu-release- Unapproved: ntp (artful-proposed/main) [1:4.2.8p10+dfsg-5ubuntu3.1 => 1:4.2.8p10+dfsg-5ubuntu3.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.7 => 1:4.2.8p4+dfsg-3ubuntu5.8] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (xenial-proposed) [1:4.2.8p4+dfsg-3ubuntu5.8]
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (artful-proposed) [1:4.2.8p10+dfsg-5ubuntu3.2]
<arges> rbasak: gotta run now, all yours
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.16 => 1.157.17] (core, kernel)
<ahasenack> hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
<ahasenack> python-sss is in main, that's the py2 version
<ahasenack> python3-sss is in universe
<rbasak> sil2100: are we duplicating effort on SRUs? I had been looking at util-linux. Looks like your released it earlier.
<rbasak> I was looking into adding force-badtests for all the s390x failures that Joy identified.
<LocutusOfBorg> anybody knows why gtk-doc fails the testsuite?
<LocutusOfBorg> it fails in sbuild but not pbuilder
<juliank> rbasak: I did a MP with the hints, and have been annoying here three times since yesterday I think
<juliank> sil2100: rbasak: but we do need the new util-linux approved into xenial-proposed now :)
<juliank> now that the old one is released, it's no longer blocked :)
-queuebot:#ubuntu-release- New binary: openssl1.0 [s390x] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: openssl1.0 [ppc64el] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
<rbasak> sil2100: also were you looking at the DPDK MRE?
-queuebot:#ubuntu-release- New binary: openssl1.0 [amd64] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: openssl1.0 [arm64] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: openssl1.0 [i386] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: openssl1.0 [armhf] (bionic-proposed/main) [1.0.2n-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-rvsao [ppc64el] (bionic-proposed/universe) [2.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-rvsao [arm64] (bionic-proposed/universe) [2.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-rvsao [armhf] (bionic-proposed/universe) [2.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-rvsao [amd64] (bionic-proposed/universe) [2.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-rvsao [i386] (bionic-proposed/universe) [2.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3-precis-i18n [amd64] (bionic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New source: ippsample (bionic-proposed/primary) [0.0+20180213-0ubuntu1]
<slangasek> xnox: I have no context for why you're blaming lvm2.  Rolling back versions is anyway not a long-term solution to anything
<xnox> slangasek, true, currently bisecting lvm2, and/or will try to disable udev synchronisation in cryptsetup
<xnox> slangasek, i believe "cryptsetup luks swap not working in ubiquity" is related to the "autopkgtest systemd fails in cryptsetup"
-queuebot:#ubuntu-release- Unapproved: gcc-4.8 (trusty-proposed/main) [4.8.4-2ubuntu1~14.04.3 => 4.8.4-2ubuntu1~14.04.4] (core) (sync)
<tyhicks> sbeattie, apw: ^ I've just copied over the retpoline GCC update for Trusty
<tyhicks> sbeattie: thanks for preparing that update!
<jbicha> LocutusOfBorg: gtk-doc tests pass in sbuild locally too :(
<LocutusOfBorg> jbicha, I'm doing some tests
<LocutusOfBorg> I think it is related to a) VERBOSE=1 being set in buildd or b) SBUILD_USER being different
<LocutusOfBorg> jbicha, I tried some rules-requires-root but nothing changes
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
<LocutusOfBorg> lets see now
<LocutusOfBorg> this is probably the last blocker for libunistring
<LocutusOfBorg> jbicha, should be fine now, uploading
<jbicha> LocutusOfBorg: do you want to do a merge proposal? https://salsa.debian.org/gnome-team/gtk-doc
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-10.11]
-queuebot:#ubuntu-release- Unapproved: fwupd (xenial-proposed/main) [0.8.3-0ubuntu1 => 0.8.3-0ubuntu2] (desktop-core)
<LocutusOfBorg> jbicha, as soon as I make it build :/ I did export V=0 VERBOSE=0 and it worked, but I want to understand which one did the job
<LocutusOfBorg> jbicha, please don't ask me to open a merge request for this
<LocutusOfBorg> http://launchpadlibrarian.net/357041139/gtk-doc_1.27-1ubuntu1_1.27-1ubuntu2.diff.gz
<LocutusOfBorg> export V=0 does the trick
<jbicha> ok
-queuebot:#ubuntu-release- New binary: libreoffice [i386] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<jbicha> LocutusOfBorg: big thanks for fixing gtk-doc :)
<sil2100> rbasak: I just released util-linux as I got a request for it, wasn't doing any other SRU work
<sil2100> rbasak: sorry if that caused issues for you
<sil2100> rbasak: and for DPDK I already approved the MRE, it's on the wiki page
<sil2100> rbasak: I though I gave cpaelzer a heads up on IRC, but maybe it was just my imagination
<rbasak> sil2100: OK, thanks
<LocutusOfBorg> jbicha, to you :)
<LocutusOfBorg> juliank, libunitstring is only missing guile-2.2 on arm64 and can go
<LocutusOfBorg> I'm trying a build with gcc-6 to see if the ENOMEM works there
<juliank> nice
<LocutusOfBorg> any ideas are appreciated for guile-2.2, the Debian RC bug has no hints
<LocutusOfBorg> and we need that to build :/
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/14351800
<LocutusOfBorg> this is the gcc-6 attempt
-queuebot:#ubuntu-release- New binary: libreoffice [armhf] (bionic-proposed/main) [1:6.0.1-0ubuntu1] (kubuntu, ubuntu-desktop)
<superm1> backports team seems to not have had a lot of movement in a long  time.  if I have a backport that has passed the items in the checklist can I prepare it targeted for the right pocket and upload?
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2build1 => 10-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2build1 => 10-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2build1 => 10-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2build1 => 10-3] (core)
<tsimonq2> infinity, cjwatson: Hi there. Could I please get eyes on bug 1746807? Lubuntu's Alternate ISOs aren't building correctly, likely because of network configuration failing and package pools being missing.
<ubot5> bug 1746807 in debian-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<tsimonq2> I'm very unfamiliar with the d-i internals, and I've had no success thus far trying to poke around on my own.
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [ppc64el] (bionic-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [s390x] (bionic-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [amd64] (bionic-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [i386] (bionic-proposed/universe) [0.22-2] (no packageset)
<acheronuk> tsimonq2: is this with calamares?
<tsimonq2> If only I had that fancy archive snapshot thing juliank was talking about so I could use a mini ISO :)
<tsimonq2> acheronuk: no, d-i
<tsimonq2> ...
<tsimonq2> (says that in the bug)
<acheronuk> oh. sorry. just scanned it
<tsimonq2> np
<tsimonq2> cyphermox: ^^^^^^^
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [arm64] (bionic-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgeo-shapelib-perl [armhf] (bionic-proposed/universe) [0.22-2] (no packageset)
#ubuntu-release 2018-02-15
<cpaelzer> rbasak: yes I knew about the DPDK MRE ack, sil also did the wiki update
<cpaelzer> rbasak: was there a follow on action I missed?
<cpaelzer> rbasak: or was this "just" still on your personal todo and I should have let you know that it is done?
<cpaelzer> rbasak: just checked the mail he sent and (now checking receipients more closely) see that it was only me and dpb1
<slangasek> looks like ubuntu-budgie builds are going to be broken for a bit, since they pull in linux-tools-*, which is the package we broke to let the mpfr4 transition finish.  But why does Budgie install linux-tools, anyway?
<LocutusOfBorg> folks, with guile fixed, I plan to land ticket 3141 in 10h if nobody complains
<LocutusOfBorg> the rebuilds have worked correctly, and silo is happy with the diffs
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.5]
<rbasak> cpaelzer, sil2100: I just figured out what happened. Christian's email to ubuntu-release@ on Jan 4 only got delivered to my inbox yesterday. So I thought he didn't know it was approved.
<rbasak> Perhaps due to moderation?
<rbasak> I thought he didn't know it was approved> i didn't know it was approved either as I hadn't seen the IRC conversation
<rbasak> So I thought it was still with sil2100
<bdrung_work> the test failure for salt-formula-ceilometer on i386 is a false positive (VirtSubproc.Timeout). The failed test runs for the salt dependencies salt-formula-* should be rerun since i fixed the regressions yesterday with new uploads. where is the correct place to report this?
<cpaelzer> rbasak: ok
<cpaelzer> rbasak: confusion resolved now at least :-)
<cpaelzer> rbasak: I replied to the list again so that it is known there, but that might take another 4 weeks :-)
<rbasak> cpaelzer: I seem to have got that one straight away
<sil2100> oh
<rbasak> Oh. No I didn't.
<rbasak> (get it straight away)
<rbasak> Anyway.
<rbasak> :)
-queuebot:#ubuntu-release- New: accepted libgweather [amd64] (bionic-proposed) [3.27.4-1]
-queuebot:#ubuntu-release- New: accepted libgweather [armhf] (bionic-proposed) [3.27.4-1]
-queuebot:#ubuntu-release- New: accepted libgweather [ppc64el] (bionic-proposed) [3.27.4-1]
-queuebot:#ubuntu-release- New: accepted libgweather [arm64] (bionic-proposed) [3.27.4-1]
-queuebot:#ubuntu-release- New: accepted libgweather [s390x] (bionic-proposed) [3.27.4-1]
-queuebot:#ubuntu-release- New: accepted libgweather [i386] (bionic-proposed) [3.27.4-1]
<LocutusOfBorg> jbicha, just to be clear, export V=1 makes gtk-doc fail to build also in Debian :)
<LocutusOfBorg> so, the problem is not an Ubuntu only, but probably an even upstream one
<LocutusOfBorg> maybe forwarding to upstream developers might help, also having a better error message, to avoid other linux distro having the same issue
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (artful-proposed) [2.02~beta3-4ubuntu7.2]
<jbicha> is "V=1" a convention?
<jbicha> ok, I see it's an automake thing
<LocutusOfBorg> jbicha, it is exported by ubuntu buildds, but in any case, I think docbook-xls is evaluating it
<LocutusOfBorg> upstream should probably be doing V=0 in testsuite, not Debian or Ubuntu
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (artful-proposed) [1.85.2]
<LocutusOfBorg> jbicha, https://patchwork.kernel.org/patch/7699771/
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.1 => 2.02~beta3-4ubuntu7.2] (core)
<sil2100> rbasak: I see you have commented/discussed on the libzstd SRU - should I leave it on your plate as you have the most context?
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (artful-proposed) [12.2.2-0ubuntu0.17.10.1]
<rbasak> sil2100: ack. Ah - I see it's in the queue.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.2 => 2.02~beta3-4ubuntu7.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (artful-proposed) [1:10.0-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.8]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.7 => 1:8.0-0ubuntu3.8] (core)
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (xenial-proposed) [1.157.17]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (xenial-proposed) [0.8.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.8]
-queuebot:#ubuntu-release- Unapproved: rejected libzstd [source] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
<sil2100> smb: hey! I'm looking at your iscsitarget SRU upload for trusty right now
<sil2100> smb: I remember it for xenial, but hm, the new upload is for fixing an ADT test - but I don't see any failures for the iscsitarget package that's currently in trusty-proposed - is it only because those ran a long long time ago?
<smb> sil2100, yes? That one is a combo. The part I did is only the test, the other part is from what alrady was in proposed
<sil2100> smb: does it mean that if the tests were re-run right now without the fix, they would fail?
<smb> sil2100, The dep8 failure is racy
<smb> So accidentally sometimes did work
<sil2100> Ah, ok, guess better to have it than not
<sil2100> Thanks
-queuebot:#ubuntu-release- Unapproved: accepted libzstd [source] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
<smb> sil2100, For detail, when checking for the daemon being running it sometimes took the start script as the running daemon (if system was slow enough)
-queuebot:#ubuntu-release- Unapproved: accepted libzstd [source] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (trusty-proposed) [1.4.20.3+svn499-0ubuntu2.5]
-queuebot:#ubuntu-release- New binary: libzstd [s390x] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [ppc64el] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
<rbasak> ahasenack: ^ that's confusing
<rbasak> I wasn't expecting a new binary called libzstd
<rbasak> It's not in debian/control
<ahasenack> isn't that the source name?
 * LocutusOfBorg is ready to land ticket 3141
<rbasak> Oh
<rbasak> That's the name of the source, not the new binary
<ahasenack> I think so
<rbasak> https://launchpad.net/ubuntu/+source/libzstd/1.3.1+dfsg-1ubuntu0.1/+build/14353830 has what I expected
<ahasenack> cool
<rbasak> Never mind. Sorry!
<ahasenack> np :)
-queuebot:#ubuntu-release- New binary: libzstd [s390x] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [arm64] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [armhf] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
<LocutusOfBorg> how ofter does britney run on bileto?
-queuebot:#ubuntu-release- New binary: libzstd [powerpc] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [amd64] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [i386] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [i386] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [arm64] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [amd64] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [ppc64el] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzstd [armhf] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (artful-proposed/main) [2:10.1.10-3 => 2:10.1.10-3ubuntu0.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (xenial-proposed/main) [2:10.0.7-3227872-5ubuntu1~16.04.1 => 2:10.0.7-3227872-5ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (trusty-proposed/main) [2:9.4.0-1280544-5ubuntu6.2 => 2:9.4.0-1280544-5ubuntu6.3] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.16 => 1.157.17] (core, kernel)
<LocutusOfBorg> why libunistring from silo didn't end up in binNEW queue?
<LocutusOfBorg> is publishing from silo something that avoids the queue? seems strange
<jbicha> LocutusOfBorg: yes
<LocutusOfBorg> wow, I don't understand the rationale for this but yeah
-queuebot:#ubuntu-release- Unapproved: walinuxagent (artful-proposed/main) [2.2.21-0ubuntu1~17.10.1 => 2.2.21+really2.2.20-0ubuntu1~17.10.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.21-0ubuntu1~16.04.1 => 2.2.21+really2.2.20-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.21-0ubuntu1~14.04.1 => 2.2.21+really2.2.20-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
<LocutusOfBorg> ack thanks
<jbicha> it's a bug
<apw> LocutusOfBorg, this is why releasing from biletto is meant to involve an AA doing the new review beforehand if there are any new binaries
<superm1> Hi, can an archive admin please help review unapproved today?  fwupdate is blocking fwupd build and migration
-queuebot:#ubuntu-release- Unapproved: libsmbios (xenial-backports/universe) [2.3.0-0ubuntu1.1 => 2.4.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libsmbios (trusty-backports/universe) [2.2.28-2 => 2.4.0-1~ubuntu14.04.1] (no packageset)
<nacc> slangasek: if you have a moment: LP: #1749745
<ubot5> Launchpad bug 1749745 in php7.2 (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New] https://launchpad.net/bugs/1749745
<nacc> that's at least one, which is currently blocking php-defaults
<slangasek> nacc: how is php-crypt-chap blocking?  it has a FTBFS but only Recommends: php-mcrypt
<nacc> slangasek: it build-depends on it
<slangasek> a build-depend doesn't block migration
<nacc> slangasek: we can't build it with php-defaults for 7.2
<nacc> as there is no php-mcrypt
<slangasek> and php-crypt-chap is arch: all
<slangasek> with no interesting dependencies that would block a transition
<nacc> the tests fail at runtime becuase it tries to load mcrypt
<nacc> (well, use mcrypt)
<slangasek> tests> right, that's the rationale I was looking for
<nacc> i don't know why it's a reverse-recommends only , as it seems like a hard dependency :)
<slangasek> howso?
<nacc> slangasek: as in, the code uses mcrypt explicitly
<nacc> afaict
<slangasek> it's reasonable for a testsuite to cover things that are optional
<slangasek> hmm ok
<nacc> slangasek: i didn't dig into it too much
<nacc> but afaict, if something is still using mcrypt (per ondrej) it's probably cruft
<nacc> even if optionally
<slangasek> yes, but that alone is not a rationale for us to remove it in advance of Debia
<nacc> slangasek: i guess i should have been clearer: a rebuild of php-crypt-chap will fail eventually (due to missing php-mcrypt) and the tests will always fail with PHP7.2
<slangasek> hngh and then I go and remove the wrong package
<slangasek> hi please trust me with your archive
<nacc> somehow it doesn't change my trust level :)
 * slangasek puts php-horde-passwd back
-queuebot:#ubuntu-release- New sync: php-horde-passwd (bionic-release/primary) [5.0.7-1]
<slangasek> nacc: any idea why serious bugs haven't been filed in Debian for these yet? (ex: yubikey-ksm)
<nacc> slangasek: i really don't know. the Debian side of this transition has been ... poor, IMO this time
<nacc> slangasek: lots (most) faililng dep8 all over
<nacc> some ftbfs
<nacc> slangasek: it's possible it's coming, or they will just be removed eventually
<nacc> slangasek: oh wait, i know why
<nacc> slangasek: debian has 7.1 and 7.2
<nacc> and i think 7.1 is the default (so php-mcrypt points there)
<slangasek> k
<nacc> xnox: have you checked the new php-doctrine-cache works?
<xnox> nacc, no! but i have high hopes; since upstream dropped the test suite =)
<nacc> xnox: lol
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.19 => 20101020ubuntu451.20] (core)
<bdmurray> balloons: So can bug 1744968 be considered verification-done?
<ubot5> bug 1744968 in nplan (Ubuntu Artful) "[SRU] Juju 2.3.2" [High,In progress] https://launchpad.net/bugs/1744968
<balloons> bdmurray, I was wanting cyphermox to chime in as well, so I didn't change the tags
<balloons> bdmurray, but I suppose netplan is waiting on juju, and there isn't any reason to hold juju.
<balloons> bdmurray, set to verification-done
-queuebot:#ubuntu-release- Unapproved: rejected salt [source] (artful-proposed) [2017.7.2+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (artful-proposed) [2:10.1.10-3ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (xenial-proposed) [2:10.0.7-3227872-5ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (trusty-proposed) [2:9.4.0-1280544-5ubuntu6.3]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (artful-proposed) [2.2.21+really2.2.20-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.21+really2.2.20-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.21+really2.2.20-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.20]
<wmww> Is this the place to bring up a package issue in 18.04?
<nacc> wmww: #ubuntu+1
<nacc> wmww: presuming you mean a bug or so
<wmww> nacc: Clang won't install due to dependency issue. I'll report it there.
<nacc> slangasek: if you could also look at LP: #1749783 when you get a chance.
<ubot5> Launchpad bug 1749783 in php-phpdocumentor-reflection (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,New] https://launchpad.net/bugs/1749783
<nacc> slangasek: also just updated to include the debian bugs fo rhte same
<nacc> i'm assuming whoever is doing the debian builds may be bootstrapping them in, which is leading to this mess on our side
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [s390x] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [ppc64el] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [i386] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [amd64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [arm64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [armhf] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected gcc-4.8 [sync] (trusty-proposed) [4.8.4-2ubuntu1~14.04.4]
-queuebot:#ubuntu-release- Unapproved: gcc-4.8 (trusty-proposed/main) [4.8.4-2ubuntu1~14.04.3 => 4.8.4-2ubuntu1~14.04.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-4.8 [sync] (trusty-proposed) [4.8.4-2ubuntu1~14.04.4]
<flocculant> infinity: re this  âminimal installâ option - how's that going to pan out for flavours? also reminding that we've been trying to get a Xubuntu minimal going for some cycles now
<flocculant> bluesabre: ^^
<superm1> flocculant, at least from the way it looks like it's been implemented in the PR it's a simple flat file that calls out what you want ripped out of your livefs while installing
<flocculant> PR ?
<flocculant> sorry - I do QA for us not coding :p
<superm1> flocculant, https://code.launchpad.net/~didrocks/ubiquity/minimal-install/+merge/337698 that's the merge request for it
<superm1> currently it points to everything in a file /usr/share/ubiquity/manifests/minimal_install_removal
<flocculant> superm1: oh right - I have enough trouble getting around bzr and mp - not a clue what PR is :D
<superm1> so I would expect the best thing for a flavor to do is dpkg-divert that and provide a list of what they want out
<flocculant> superm1: we've been looking at a completely seperate iso to do that
<superm1> you should probably discuss with didrocks and xnox specifically on the best way they want to see flavors do it
<superm1> but that seems like a plausibly good way to me
<flocculant> mmm
<infinity> superm1: Eh?  There's nothing to dpkg-divert.  The removal file doesn't come from ubiquity.
<superm1> infinity, it will though I thought
<superm1> i mean i guess nothing is accepted yet and it can change
<infinity> superm1: If the removal file isn't supplied during the image build, that's a massive and glaring bug. :P
<infinity> (And I'd push back hard on such a "design")
<flocculant> infinity: evening :)
<superm1> https://code.launchpad.net/~didrocks/ubiquity/minimal-package-list/+merge/337700
<infinity> Gross.
<tsimonq2> Oh jeez.
<tsimonq2> Please don't tell me that's a hardcoded list...
<infinity> It sure is.
<flocculant> so glad I'm just qa ...
<flocculant> if you can call - asking and being ignored that ;)
<infinity> flocculant: Sorry, not maliciously ignoring you, just literally have no answer.
<infinity> flocculant: Or, rather "the Canonical Desktop team landing hackish temporary features doesn't really have much impact on flavours".
<infinity> (Assuming the claim that they plan to ditch ubiquity entirely comes to fruition)
<slangasek> I don't understand that claim
<infinity> slangasek: I don't either, but it's right there in the MP. :P
<slangasek> yeah
<slangasek> I blame xnox
<slangasek> (by which I mean, "I summon xnox")
<infinity> slangasek: Now, I could dissect the claim as "we intend to use subiquity-style fs-stacking in ubiquity", which isn't the world's worst idea.
<flocculant> infinity: ack - never would assume you would do such a thing, if you wanted to - make it obvious :)
<infinity> And would neatly reduce the live removal stage of both ubiquity and live-installer to a no-op.
<cjwatson> An idea with a decade's pedigree
<infinity> cjwatson: Indeed.
<cjwatson> Which nobody ever got to work before, but that shouldn't stop people trying :)
<infinity> Well, the big problem is booting a functional desktop with stacked livefses.
<infinity> Where one was bad enough.
<tsimonq2> It doesn't help that OMG! Ubuntu! misinterpreted the commit message that Didier wrote, and since some people decide to pick that apart, the rumor has spread that Desktop is now switching to subiquity.
<tsimonq2> FTR.
<infinity> But things have matured a lot since the bad old days.
<infinity> tsimonq2: Yes, well.  Let's not let the press dictate our plans. :)
<tsimonq2> infinity: Stacked squashfses is something interesting.
<cjwatson> The big problem back then was unavoidable file overlaps between the livefses (e.g. /var/lib/dpkg/status), but yeah, filesystem technology has moved on.
<infinity> Right, and they almost mostly work now.
<tsimonq2> infinity: I agree, but in more than one channel this morning people lolwat'ted at that :)
<infinity> cjwatson: Well, if you're intentionally stacking linearly, that's not an issue.
<tsimonq2> infinity: stacked squashfses> Oh, that's cool. I'd hate to ask for an ETA, but will it land before Feature Freeze?
<infinity> cjwatson: ie: base > desktop > desktop-fat > live, then you peel back in inverse order.
<cjwatson> Yeah.
<infinity> cjwatson: It all goes to hell when people want to use that to define packagesets.
 * slangasek nods
<cjwatson> desktop-lardons, if you will
<cjwatson> (you probably won't)
<slangasek> desktop-evoo
<infinity> desktop-chubby?
<tsimonq2> desktop-apps maybe?
<infinity> However, I'm not sure if either the current hack or stacked fses addresses what Xubuntu wanted, which was a smaller image, not just a smaller install footprint.
<infinity> If they don't care about image size, then I think stacking is the right answer for everyone to be working on.
<infinity> (Or, rather, if the back down on the image size thing, despite caring?)
<infinity> s/the/they/
<infinity> A single image with two install options is much less hassle to QA as well.
<tsimonq2> Talking about image size reminds me to tell you infinity -- I tried removing no-follow-recommends on Lubuntu Next and it pulled in a Plasma desktop... :P so I guess I'll have to play with the recommends more on things, but 18.10 might see us lifting that, finally, for Lubuntu Next. I don't think we care about image size anymore as long as it's not ridiculous.
<flocculant> infinity: I can't answer that - though iirc we were looking more at a step between a mini.iso and the current full fat Xubuntu - bluesabre Ukikie are the people who could answer more speciffically
<tsimonq2> And Lubuntu Next might use stacking, I think that's a great idea, honestly.
<infinity> tsimonq2: Yeah, you might be able to enlist jbicha's help with your recommends issues (if he's up for it, I don't want to volunteer him).  He's very familiar with the tricks we had to pull when ubuntu-desktop and ubuntu-gnome had to somehow magically coexist without pulling each other in.
<tsimonq2> infinity: That sounds like that would have been *super* fun. /s
<infinity> tsimonq2: It was a bit of a headache making sure unity didn't pull in GNOME and GNOME didn't pull in unity, yes, but it kinda mostly worked most of the time. :P
<tsimonq2> :D
<tsimonq2> infinity: So, speaking of images as well... Lubuntu Next won't have an Alternate image. We might play with Calamares' netboot functionality but as far as direct d-i goes, we're likely going to be done with that. But we sort of need Lubuntu's Alternate images to work, for one last release, so we can ship them. :P
<tsimonq2> infinity: I mean, it would help if it could pull a kernel in :P *ahem*
<tsimonq2> (bug 1746807)
<ubot5> bug 1746807 in debian-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<tsimonq2> infinity: Something landed between the ISO landing on January 31st and February 1st that broke things, and I can't figure out what.
<tsimonq2> (s/landing/spinning up/ on that second occurrence :P)
<flocculant> tsimonq2: does that mean that eventually other people won't get asked to test Lubuntu Alternates right at the last minute when you run out of time :D
<tsimonq2> flocculant: It will, yes :D
<flocculant> ha ha
<tsimonq2> hahaha
 * flocculant waits ... but is available if necessary till then ;)
<tsimonq2> Right, we gotta get the LTS out.
<tsimonq2> Then we can cut the cruft.
<tsimonq2> (Well, we're already *kinda* doing that, but we aren't touching the LXDE edition except for bugfixes :) )
<flocculant> :)
<flocculant> what I'm trying to aim for is for us to only sign up to fix 'not diabolical' bugs which get reported on the tracker
<flocculant> I can then turn up 4 times a year and say we have no bugs unless I found them :D
<flocculant> I find more things in places like qemu than xfce packages
<xnox> slangasek, what did you mean by stacked squashfs? you mean like doing overlayfs and packing each layer as squashfs?
<xnox> slangasek, or am I out-of-date and squashfs naturally supports stacking somehow?
<slangasek> xnox: overlay between multiple squashes
<bdmurray> slangasek: Can you set the phased-update-percentage for compiz to 0 see #ubuntu-devel.
<bdmurray> ? for good measure
<xnox> slangasek, and we have tooling to build those? could be fun.
<slangasek> xnox: we effectively already do this for subiquity
<slangasek> it's only a two-deep stack
<slangasek> bdmurray: source package is compiz? which release?
<nacc> slangasek: compiz on xenial
<slangasek> nacc, bdmurray: done
<nacc> looks to have migrated about 4 hours ago?
<xnox> slangasek, ok.
<slangasek> xnox: and this is what we were talking about for the maas install options?
<nacc> slangasek: thanks
<xnox> slangasek, i thought so, yeah
<xnox> ?!
<slangasek> bdmurray, nacc: what's the follow-through? unity needs rebuilt and pushed?  does it need revalidated?
<slangasek> xnox: yes, that's why I'm surprised you didn't know we had tooling :)
<nacc> slangasek: i think unity at a minimum needs a rebuild
<nacc> it's the only reverse build-depends?
<bdmurray> there is a unity in -proposed
<xnox> slangasek, i was not involved in the subiquity livecd-rootfs stuff
<nacc> so they just need to migrate together, bdmurray ?
<slangasek> xnox: ack, I failed to give you context on the current state then
-queuebot:#ubuntu-release- New binary: ddnet [s390x] (bionic-proposed/universe) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbedtls [s390x] (bionic-proposed/universe) [2.7.0-2] (no packageset)
<slangasek> bdmurray: I should let you follow it up then?
<bdmurray> slangasek: I'm looking into it fwiw
<bdmurray> enabling -proposed makes the upgrade not want to remove unity
-queuebot:#ubuntu-release- New binary: ddnet [amd64] (bionic-proposed/universe) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbedtls [amd64] (bionic-proposed/universe) [2.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [i386] (bionic-proposed/universe) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbedtls [i386] (bionic-proposed/universe) [2.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New: rejected ukui-power-manager [source] (bionic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ddnet [armhf] (bionic-proposed/universe) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ddnet [arm64] (bionic-proposed/universe) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbedtls [arm64] (bionic-proposed/universe) [2.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mbedtls [armhf] (bionic-proposed/universe) [2.7.0-2] (no packageset)
<xnox> slangasek, could you please process openssl1.0 through new?
-queuebot:#ubuntu-release- New: accepted ddnet [amd64] (bionic-proposed) [10.8.6-3]
-queuebot:#ubuntu-release- New: accepted ddnet [ppc64el] (bionic-proposed) [10.8.6-3]
-queuebot:#ubuntu-release- New: accepted ddnet [arm64] (bionic-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted ddnet [i386] (bionic-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-rvsao [amd64] (bionic-proposed) [2.8.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-rvsao [armhf] (bionic-proposed) [2.8.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-rvsao [ppc64el] (bionic-proposed) [2.8.3-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [arm64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [i386] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [s390x] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted ddnet [arm64] (bionic-proposed) [10.8.6-3]
-queuebot:#ubuntu-release- New: accepted ddnet [armhf] (bionic-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-rvsao [arm64] (bionic-proposed) [2.8.3-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [amd64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [ppc64el] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [amd64] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [armhf] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [ppc64el] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted libgpiod [armhf] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted mbedtls [arm64] (bionic-proposed) [2.7.0-2]
-queuebot:#ubuntu-release- New: accepted ddnet [amd64] (bionic-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-rvsao [i386] (bionic-proposed) [2.8.3-1]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [amd64] (bionic-proposed) [0.22-1]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [i386] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted mbedtls [amd64] (bionic-proposed) [2.7.0-2]
-queuebot:#ubuntu-release- New: accepted mbedtls [s390x] (bionic-proposed) [2.7.0-2]
-queuebot:#ubuntu-release- New: accepted python3-precis-i18n [amd64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ddnet [s390x] (bionic-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [arm64] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted mbedtls [i386] (bionic-proposed) [2.7.0-2]
-queuebot:#ubuntu-release- New: accepted texhyphj [amd64] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [armhf] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted minidb [amd64] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [s390x] (bionic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted ddnet [s390x] (bionic-proposed) [10.8.6-3]
-queuebot:#ubuntu-release- New: accepted libgpiod [arm64] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libgpiod [ppc64el] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libgpiod [amd64] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libgpiod [s390x] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libgpiod [i386] (bionic-proposed) [1.0-1]
<bdmurray> slangasek: Yes, we just need the version of unity from -proposed
<slangasek> xnox: rationale for an openssl1.0 binary package that doesn't seem to exist in Debian?
<xnox> slangasek, security team must have openssl1.0 binary for SRU and security regression to support openssl1.0 in main
<xnox> slangasek, there is an LP bug linked....
<xnox> slangasek, hence i shipped them, non-coflicting, in /usr/lib/ssl1.0/ which should be good enough for security team.
<slangasek> xnox: got it, thanks
<slangasek> xnox: and I assume there's no requirement to seed this binary package into main
-queuebot:#ubuntu-release- New: accepted openssl1.0 [amd64] (bionic-proposed) [1.0.2n-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted openssl1.0 [armhf] (bionic-proposed) [1.0.2n-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted openssl1.0 [ppc64el] (bionic-proposed) [1.0.2n-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted openssl1.0 [arm64] (bionic-proposed) [1.0.2n-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted openssl1.0 [s390x] (bionic-proposed) [1.0.2n-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted openssl1.0 [i386] (bionic-proposed) [1.0.2n-1ubuntu3]
<xnox> slangasek, don't think so.
<bdmurray> slangasek: What else needs to happen with the compiz / unity xenial issue?
<bdmurray> unity has two unverified bugs
<slangasek> bdmurray: under the circumstances, with 20 verified bugs, 2 unverified bugs, and a critical regression, I was inclined to release without verification of the last 2
<bdmurray> slangasek: we could test for a regression in bug 1666359 using what is given
<ubot5> bug 1666359 in unity (Ubuntu Xenial) "Lock screen doesn't cover entire desktop on HiDPI display with draw-user-backgrounds unchecked" [Undecided,Fix committed] https://launchpad.net/bugs/1666359
<slangasek> bdmurray: could; but I think it's better to release the current package now and not block on further verifications
<bdmurray> slangasek: okay
#ubuntu-release 2018-02-16
<bdmurray> slangasek: "I think it's better" so bdmurray should do it?
<slangasek> bdmurray: I'm willing to push the button if you prefer :)
<bdmurray> slangasek: I have no preference lets just get it doen
<slangasek> bdmurray: ok, done
<slangasek> (modulo the delay of updating 22 bugs)
<jbicha> slangasek: do you have time to review libreoffice & gnome-desktop3 in the bionic NEW queue?
<slangasek> jbicha: no, because I'm currently reviewing older stuff in said queue
<jbicha> cool, thanks
-queuebot:#ubuntu-release- New: accepted nm-tray [source] (bionic-proposed) [0.3.0-0ubuntu1]
<tsimonq2> \o/
-queuebot:#ubuntu-release- New binary: nm-tray [amd64] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nm-tray [s390x] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nm-tray [ppc64el] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nm-tray [i386] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nm-tray [armhf] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nm-tray [arm64] (bionic-proposed/universe) [0.3.0-0ubuntu1] (no packageset)
<sarnold> for the unity / compiz thing I've duped a few bugs to 1749840
<tsimonq2> thanks
-queuebot:#ubuntu-release- New: accepted nm-tray [amd64] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nm-tray [armhf] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nm-tray [ppc64el] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nm-tray [arm64] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nm-tray [s390x] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nm-tray [i386] (bionic-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [amd64] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [armhf] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [ppc64el] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [arm64] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [s390x] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [i386] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted php-horde-passwd [sync] (bionic-release) [5.0.7-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [arm64] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [i386] (bionic-proposed) [1:6.0.1-0ubuntu1]
<doko> who's accepting binaries before they are built on all archs?
<nacc> doko: which one?
-queuebot:#ubuntu-release- New: accepted mbedtls [armhf] (bionic-proposed) [2.7.0-2]
<doko> that one
<slangasek> possibly me
<slangasek> because I don't see that it matters to not do so, or warrants spending the attention instead of just running new-binary-debian-universe
<doko> well, the next one looking at the NEW queue spends that attention why there is only a binary on one arch. not that efficient
<slangasek> you could also run new-binary-debian-universe ;)
<tsimonq2> up to seven dups: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1749840
<ubot5> Ubuntu bug 1749840 in compiz (Ubuntu) "apt-get install ubuntu-desktop doesn't work" [Undecided,Confirmed]
<tsimonq2> argh, I accidentally uploaded calamares-settings-ubuntu without running dch -r so it looks like it's from November...
-queuebot:#ubuntu-release- New source: calamares-settings-ubuntu (bionic-proposed/primary) [1]
<tsimonq2> Can someone reject please?
<tsimonq2> (There's an associated lintian warning with using a Standards-version newer than the changelog entry...)
-queuebot:#ubuntu-release- New source: calamares-settings-ubuntu (bionic-proposed/primary) [1]
-queuebot:#ubuntu-release- New: rejected calamares-settings-ubuntu [source] (bionic-proposed) [1]
<apw> tsimonq2, ^
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [amd64] (bionic-proposed) [10-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [armhf] (bionic-proposed) [10-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [arm64] (bionic-proposed) [10-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [i386] (bionic-proposed) [10-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [10-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [10-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [10-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [10-3]
<doko> who is working on Kylin these days?
<doko> asking for https://launchpadlibrarian.net/357258908/buildlog_ubuntu-bionic-amd64.ubuntu-kylin-sso-client_0.1.2.4_BUILDING.txt.gz
<doko> https://bugs.launchpad.net/ubuntu/+source/ubuntu-kylin-sso-client/+bug/1749924
<ubot5> Ubuntu bug 1749924 in ubuntu-kylin-sso-client (Ubuntu) "ubuntu-kylin-sso-client ftbfs in bionic" [High,Confirmed]
<rbasak> Could an AA review libzstd in Xenial binNEW please? It's related to maintaining the upgrade path in an SRU.
<sil2100> rbasak: you ACKed the SRU, right?
<rbasak> sil2100: yes
<sil2100> rbasak: in that case I can do that, one moment
<rbasak> ahasenack: ^
<ahasenack> thx
<sil2100> rbasak, ahasenack: done
-queuebot:#ubuntu-release- New: accepted libzstd [amd64] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [armhf] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [powerpc] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [s390x] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [arm64] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [ppc64el] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libzstd [i386] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
<ahasenack> thanks sil2100
<ahasenack> hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
<ahasenack> python-sss is in main, that's the py2 version
<ahasenack> python3-sss is in universe
<ahasenack> both come from the same source package which is sssd
<rbasak> sil2100: thanks!
<jbicha> doko: there is a #ubuntukylin-devel channel
<tsimonq2> apw: Thanks :)
<apw> ahasenack, have you found the MIR for that, that let the py2 in ?
<ahasenack> apw: I didn't check, since it was in main already (as is sssd itself)
<apw> ahasenack, ok found it
<apw> ahasenack, ok poked
<bdmurray> slangasek: FYI the unity phasing got stopped by the phased updater.
<bdmurray> slangasek: Its right - just thought it was worth noting.
<tsimonq2> Does anto
<tsimonq2> gerr
<tsimonq2> Does anyone happen to know what version of apt runs on Nusakan?
<slangasek> bdmurray: ah?
<slangasek> tsimonq2: I'm not sure apt is run at any point on nusakan as part of the builds
<slangasek> tsimonq2: what are you seeing?
<tsimonq2> slangasek: Curious about juliank's question on bug 1714451
<ubot5> bug 1714451 in libglvnd (Ubuntu) "please remove libglvnd from the archive" [Undecided,Invalid] https://launchpad.net/bugs/1714451
<tsimonq2> er
<tsimonq2> wrong one
<tsimonq2> bug 1746807
<ubot5> bug 1746807 in apt (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<tsimonq2> that :)
 * juliank too
<juliank> probably there are different version, but I don't remember
<juliank> I think we jumped from alpha5 to alpha7
<slangasek> tsimonq2: the version that's relevant there is the version run from inside the install target
<juliank> alpha6 introduced retrying for acquire items and the new mirror method, so it's possibles something got broken.
<slangasek> which is the version on the image
<slangasek> not on nusakan
<juliank> alpha5 was superseded on 2018-01-31 19:37:29 CET
<tsimonq2> slangasek: Ohhh and the timing matches up too, apt in Bionic got updated on 20180131 as well
<tsimonq2> juliank: It's likely that then I think
<juliank> Well, cdrom support is basically unmaintained and does not have much tests, so it breaks a lot
<xnox> most no longer have cdroms....
<juliank> But well, something must have broken.
<tsimonq2> OK
<juliank> Best next would be to get the image, and bisect apt-cdrom
<tsimonq2> I can do that if we know it's apt-cdrom.
<tsimonq2> (That would make sense.)
<juliank> Well, it's somewhere in the apt-pkg library probably
<juliank> but anyway, bisecting should be relatively easy I guess.
<slangasek> xnox: we use apt-cdrom also for USB sticks at install time
<juliank> yes, we do.
<juliank> unfortunately installs are not a common thing :D
 * tsimonq2 volunteers to do the bisecting
<juliank> at least for developers - so it's good to have testing for it :D
<tsimonq2> :D
<xnox> slangasek, because file:// would not do?
<juliank> correct
<slangasek> xnox: file:// semantics are wrong for removable media
<juliank> xnox: file:// has a fixed path, that does not really work
<juliank> cdrom:// looks up based on some media id label thingy
<xnox> ..... which systemd .mount unit could do too....
<juliank> We should probably symlink it to usb :D
<xnox> %i too
<juliank> it's a weird file in .disk-info  or something, and then it hashes the files to make sure it's the correct disk
<juliank> it's all fairly weird, but it makes sure you don't accidentally update/install something different just because it has the same name
<xnox> start an http server to serve cdrom:// over http?! =) as a mirror?! =)
<slangasek> last I knew, there were error code differences w/ absent cdrom sources as well
<juliank> probably
<juliank> anyhow, it's the right thing to do
<juliank> maybe we should allow usb:// as an alias? :D
<juliank> or disk://
<juliank> and disc://
<slangasek> twitch
<juliank> I don't know
<juliank> tsimonq2: I'll ask DonKult if he has an idea, he made all those big changes :/
<bdmurray> I think its .media-info
<juliank> ah
<xnox> juliank, hokey-rink:// too then!
<xnox> https://en.wikipedia.org/wiki/Bootable_business_card
<juliank> Nah
<juliank> bbc:// sounds nice, though
<juliank> Package it as apt-transport-bbc
<juliank> If only to annoy BBC folks
 * xnox suspects juliank is not trolling; and simply has no idea what bbc stands for on urban dictionary
<juliank> I meant the British one
<juliank> :D
-queuebot:#ubuntu-release- New binary: python-skytools [s390x] (bionic-proposed/none) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eo-spell [amd64] (bionic-proposed/main) [2.1.2000.02.25-55] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: quaternion [s390x] (bionic-proposed/none) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dxf2gcode [amd64] (bionic-proposed/universe) [20170925-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nvveen-gotty [amd64] (bionic-proposed/universe) [0.0~git20120604.cd52737-1] (no packageset)
-queuebot:#ubuntu-release- New binary: londiste [amd64] (bionic-proposed/universe) [3.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-coverage [amd64] (bionic-proposed/universe) [4.5+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-fossil [amd64] (bionic-proposed/universe) [2018.02.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-forked [amd64] (bionic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-opencontainers-go-digest [amd64] (bionic-proposed/universe) [1.0.0~rc1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-skytools [amd64] (bionic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pokemmo-installer [amd64] (bionic-proposed/multiverse) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-skytools [i386] (bionic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pokemmo [amd64] (bionic-proposed/multiverse) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-ljsyscall [amd64] (bionic-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-skytools [arm64] (bionic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quaternion [amd64] (bionic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-skytools [armhf] (bionic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quaternion [i386] (bionic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-skytools [ppc64el] (bionic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quaternion [arm64] (bionic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quaternion [ppc64el] (bionic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quaternion [armhf] (bionic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: supermin (xenial-proposed/universe) [5.1.14-2ubuntu1 => 5.1.14-2ubuntu1.1] (no packageset)
<nacc> chrisccoulson: infinity: glibc in bionic is versioned less than artful
<nacc> and i think is breaking some folks in #ubuntu+1
<nacc> i'm assuming the artful package should be copied forward?
<nacc> i think if a user did artful with the security update -> bionic, many packages with libc dependencies will fail to install in bionic
<nacc> they can manually workaround with libc6= libc6-dev= libc6-i386= to downgrade to the bionic version, but that's not great UX :)
<nacc> slangasek: --^ maybe you can help as i think it will take a AA
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-116.140~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-116.140~14.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (xenial-proposed/main) [3.18.0-2ubuntu1 => 3.18.0-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (artful-proposed/main) [3.22.3-1ubuntu1 => 3.22.3-1ubuntu2] (ubuntu-desktop)
<slangasek> nacc: it's a known temporary problem until glibc 2.27 is landed in bionic, which I don't have a current ETA on.  We would not normally copy directly to bionic from artful, but would copy to bionic-proposed instead, and I'm not sure the artful version would actually clear autopkgtests so I don't want to do that unless strictly necessary
<slangasek> infinity: ^^ what's the current status of 2.27?  are you still in package merge hell?
<bdmurray> slangasek: Now that ddebs is fixed - https://code.launchpad.net/~brian-murray/apport/lp-retracer-bionic-updates/+merge/337676
<slangasek> bdmurray: merged, thanks!
<tsimonq2> Out of curiosity, I wonder why ddebs.ubuntu.com doesn't have anything for *-security.
<slangasek> tsimonq2: I don't know if this is the rationale, but it would be redundant since everything published to -security is also copied to -updates
<tsimonq2> slangasek: What about the case where something is released to -updates that updates patch or minor version and there's already something in -security?
<slangasek> ah, the case where -security is non-empty and -updates is ahead
<tsimonq2> Yeah.
<slangasek> that's a good point, indeed
<infinity> slangasek: I'm fiddling with some theories, and was planning to upload today/tomorrow, but I also have no issues with copying artful-security -> bionic-release and skipping testing entirely.  The security upload regresses autopkgtests on armhf (and the arm64 build is regressed due to binutils), but I know of no other issues that would be worth doing the proposed dance on it.
<bdmurray> hunh, I wonder if we have any cases that fail to retrace because of that.
<slangasek> tsimonq2: OTOH, if you're running a system with only -security enabled w/ no -updates, are debug symbols actually useful to you, since you are evidently not going to be deploying any SRUs that fix a crash
<slangasek> infinity: I would be inclined to copy to bionic-proposed first, force-skiptest, and flush the autopkgtest requests, so I don't have to think about whether there's a risk of uninstallables
<slangasek> infinity: oops, in the time it took me to write that sentence I proved to myself there is no risk of uninstallables
<infinity> slangasek: If there are uninstallables with a non-version-bumped glibc, we've done something very, very wrong, but sure.
<slangasek> infinity: k, copying.
<slangasek> nacc: ^^
<slangasek> bdmurray: do you think this is important enough to put on our backlog?
<tsimonq2> slangasek: I can see a use case for it; I think even security updates have a nonzero potential to break. Even if it's rare, I don't (personally) see a reason why debug symbols shouldn't be available should someone need them.
<tsimonq2> slangasek: But also note that I don't have a very strong opinion either way, but rather I was wondering out of curiosity why -security ddebs aren't published with -updates et al
<bdmurray> slangasek: I think having a backlog item to think about it is a good idea.
<tsimonq2> slangasek: I also don't think (please correct me if I'm wrong) that there's *many* packages that have non-empty -security with -updates ahead, so while I'm not sure on numbers, adding it there might not impact resources on the server much.
<tsimonq2> Â¯\_(ã)_/Â¯
<slangasek> bdmurray: k, please drop me a card :)
<slangasek> tsimonq2: it absolutely isn't going to be a space issue for us - it's only the effort to implement and maintain
<bdmurray> tsimonq2: I'm pretty sure the debug symbols are available on LP if someone really needed them.
<tsimonq2> bdmurray: You can say the same for all other packages ;)
<tsimonq2> slangasek: right, ok
<nacc> slangasek: infinity: the user in question was on bionic and was unable to install nvidia-384
<nacc> slangasek: infinity: with forced apt versioning, it installed fine
<nacc> possibly because only libc6 was already installed and then libc-i386 was going to be installed? but only the bionic version was available and conflicted with the artful-security version?
<slangasek> yes
<slangasek> forced apt versioning> speewwwww
<nacc> slangasek: yeah, i mean apt install nvidia-384 libc=... libc-i386=... etc
<nacc> just to get them to the bionic packages
<slangasek> oh ok
<nacc> so it's not uninstallable in the traditional sense, but the effect to users is the same :)
<nacc> slangasek: and thanks for your feedback here, I have seen other users in the past few days hit it too, I just remembered to dig into it more today
<juliank> tsimonq2, slangasek: only -updates and -proposed are whitelisted in ddeb-retriever, I think all that's needed to enable security again (it's there for trusty) is http://paste.ubuntu.com/p/C4Dr8GmPw5/
<juliank> oh no
<juliank> one more
<juliank> http://paste.ubuntu.com/p/JVTHsZv63Z/
<juliank> this might cause quite some havoc if enabled since it would suddenly start fetching and scanning all debug symbols for all security releases
<slangasek> juliank: are there any assumptions about urls for indices of the base pockets?
<juliank> I think the reason it's not done is that there's a huge overlap with updates.
<slangasek> well, I guess http://archive.ubuntu.com/ubuntu/dists/foo-security/ exists anyway
<slangasek> juliank: raise an MP?  maybe ask cjwatson to review it :)
<juliank> right there's some mirroring
<juliank> Um, yeah.
<infinity> juliank: Overlap shouldn't matter if they share a pool (which they do), surely.
<juliank> infinity: It's only a matter of indexing runtime
<juliank> it's currently about 2 mins per architecture x pocket pair
<juliank> AFAICT
<infinity> post-release pockets should be faster, I'd think.
<juliank> we are adding about 33% more
<juliank> _should_ not matter if apt-ftparchive is using a cache database, but hmm, I'm not sure it does.
<infinity> juliank: Is it done in one big apt.conf, or one run per pocket?
<juliank> infinity: one run per pocket
<infinity> Pretty sure a-f caching was enabled for that.  It's much faster if you do all pockets in one big apt.conf, though.
<infinity> Otherwise, you risk flushing the a-f caches between each run.
<juliank> We might be able too
<juliank> It'd be good to setup a second test instance I guess with a copy view of the current state to play with or something
<infinity> For reference, post-release pockets on ftpmaster are seconds per arch/component in the a-f stage.  They're basically free.
<juliank> infinity: In any case, this requires some refactoring I've planned to make dists updates more atomic
<infinity> But that's because the caches are hot already (the first one is always noticeably slower, while the rest are free).
<juliank> Currently dists/<foo> is so slow people get hashsum mismatches a lot
<juliank> like 2 or 3 times last week I got complaints
<juliank> I wanted to make dists/<foo> (mostly) atomic, but if I want to do all in one apt-ftparchive run, I guess I'll just create dists.new and then swap it
<infinity> juliank: Following the publisher model of "update pool", "rsync dists dists.new", "update dists.new in a single apt.conf pass", "rm dists && mv dists.new dists" probably works best.  But then you also need a stay-of-execution concept to avoid cleaning things from pool too early.
<juliank> well, not rm dists && mv dists.new dists, but rather mv dists dists.old && mv dists.new dists && rm dists.old; but that's the goal.
<infinity> Well, "rm dists && mv dists.new dists" is not actually the model.  We "mv dists dists.old && mv dists.new dists" to narrow the window, plus it gives us a quicker rsync when we mv dists.old to dists.new and resync for the next pass.
<infinity> juliank: Jinx.
<infinity> juliank: ie: we never 'rm dists.old', we just always have two copies around, and freshen up old to new before the next run.
<infinity> juliank: Slight waste of disk space, but huge win on time.
<juliank> That's best
<slangasek> fs juggling
<infinity> (.old and .new also don't exist in the published tree, obviously)
<juliank> It also allows you to do some roll back I guess.
<juliank> although, not with ddeb-retrievers cleanup model
<juliank> It currently builds the new dists/ tree, and then goes through pool and removes unreferenced files
<infinity> juliank: Right, I alluded to that earlier, that you'd need a stay-of-execution concept to avoid windows where files disappear.
<infinity> juliank: But that's not too hard.  You make the cleanup pass mark files for deletion instead of actually deleting, and a second cronjob cleans things with deletion timestamps >> 24h.
<juliank> We don't _need_ it.
<juliank> It would just behave as it does now
<infinity> Also fair.
<juliank> the dists.new becomes the dists, and then we do the removal based on the new state.
<infinity> It's not a high traffic enough apt archive to worry too much about perfect internal consistency.
<juliank> but yes, it would be nice to keep stuff around a bit
<infinity> Oh.  If the removal pass is separate from the update pass, yes, that works.
<juliank> It is
<infinity> add-to-pool, update-dists, remove-from-pool
<juliank> exactly
<infinity> Yeah, I'm fine with that.
<infinity> And way simpler than the tricks we have to pull on high traffic mirrors.
<juliank> Though we can make the pass also just write all files to delete to a list, and then read the list and delete the files at the start of the next ddeb-retriever run
<juliank> this avoids some minor issues
<infinity> Nah.  Lists are complicated for other reasons.
<infinity> Notably the reappearance of versions, so you need to actually compare new published binaries against the list and remove matching lines.
<juliank> infinity: Oh, we actually have a keep_days option
<juliank> so it actually only deletes files older than a few days
<juliank> currently set to 30 days
<infinity> Gross.
<infinity> That seems hugely like overkill.
<juliank> it might make sense to reduce it to like 4 days or something
<infinity> Probably was due to lagging errors retracers.
<infinity> Which now will fetch from the librarian directly.
<juliank> maybe two days
<juliank> since clients do update automatically daily, they should never be more out of sync than that
<juliank> I'll send some pretty merge proposals in the next days :)
<juliank> ddeb-retriever is very interesting because the code is easy to follow.
<juliank> but it's next to impossible to test
<juliank> archive_tools in it has unit tests, but a lot of them fail
<juliank> ah just some import messup
 * juliank sends MP
<nacc> slangasek: could use some AA love to new packages in LP: #1749783
<ubot5> Launchpad bug 1749783 in php-sabre-xml (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1749783
<infinity> juliank: Also, is ddeb-retriever smart enough to only run a-f for suites that changed?
<juliank> slangasek, infinity: Fixes for test suite & retention: https://code.launchpad.net/~juliank/ddeb-retriever/misc-fixes/+merge/337899  ; add -security: https://code.launchpad.net/~juliank/ddeb-retriever/add-security/+merge/337900
<juliank> infinity: yes
<juliank> infinity: and since recently for empty ones that do not exist yet :D
<slangasek> nacc: you were not using 'new' as a verb there, were you
<infinity> juliank: Okay, good.  So, yeah, that's the point behind having two copies and the rsync refresh, so we have a complete dists and just refresh the ones that need changing, then switcheroo.
<juliank> you can tell it to regenerate all, I accidentally did that earlier
<juliank> this week I think
<juliank> Not by using the option of course, but with a coding bug :D
<juliank> I specifically requested cjwatson to review the security one, I think the other one is more harmless :)
<juliank> We probably want to get rid of vivid, yakkety, and zesty on ddebs too
<infinity> juliank: Commit message says "Import urllib.request instead of urllib", code imports both.  Which is it? :P
<juliank> ugh
<juliank> it should have been instead
<juliank> but it does not matter
<infinity> Spoken like a professional software engineer.
<infinity> How quickly you lose your student ideals.
<juliank> infinity: I'd care if it was git
<juliank> I'd rebase there
<juliank> but in bzr?
<infinity> In bzr, you'd just re-branch and try harder.
<infinity> Since it's not in trunk yet.
<infinity> Or stack an oops commit on top, whatever. :P
<juliank> I just uncommit, shelve, and commit and push overwrite
<tsimonq2> *cough* https://github.com/mnauw/git-remote-bzr
<tsimonq2> I never touch Bazaar now thanks to that.
<juliank> tsimonq2: how do you build bzr-buildpackage packages then? :D
<tsimonq2> Who does that anymore?!? >_<
<juliank> infinity: I overwrote the MP misc-fixes now with a nice history
<juliank> tsimonq2: some packages are still in bzr and nobody has time to convert all of them to git
<nacc> <cough>
<tsimonq2> juliank: "nobody has time to convert all of them to git" try me :D
<juliank> yes there's git-ubuntu, but that's a different topic
<tsimonq2> :D
<nacc> :)
 * juliank out.
#ubuntu-release 2018-02-17
-queuebot:#ubuntu-release- New: accepted quaternion [amd64] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted quaternion [armhf] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted quaternion [ppc64el] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted quaternion [arm64] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted quaternion [s390x] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted quaternion [i386] (bionic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (bionic-proposed) [2.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-skytools [amd64] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted python-skytools [armhf] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted python-skytools [ppc64el] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted python-skytools [arm64] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted python-skytools [s390x] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted python-skytools [i386] (bionic-proposed) [3.3-2]
-queuebot:#ubuntu-release- New: accepted dxf2gcode [amd64] (bionic-proposed) [20170925-1]
-queuebot:#ubuntu-release- New: accepted eo-spell [amd64] (bionic-proposed) [2.1.2000.02.25-55]
-queuebot:#ubuntu-release- New: accepted golang-github-opencontainers-go-digest [amd64] (bionic-proposed) [1.0.0~rc1-1]
-queuebot:#ubuntu-release- New: accepted lua-ljsyscall [amd64] (bionic-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted pokemmo [amd64] (bionic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted python-coverage [amd64] (bionic-proposed) [4.5+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted emacs-fossil [amd64] (bionic-proposed) [2018.02.15-1]
-queuebot:#ubuntu-release- New: accepted londiste [amd64] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-forked [amd64] (bionic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nvveen-gotty [amd64] (bionic-proposed) [0.0~git20120604.cd52737-1]
-queuebot:#ubuntu-release- New: accepted pokemmo-installer [amd64] (bionic-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New binary: python-pgq [amd64] (bionic-proposed/universe) [3.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plastex [amd64] (bionic-proposed/none) [0.9.2-1.2] (no packageset)
<acheronuk> hi. what part of the installer decides to install language-pack-kde-*yourlanguage* ?
<acheronuk> with our next applications uploads, we will likely want to stop installing kde language packs, as all translations will have moved to the apps themselves
<LocutusOfBorg> hello tjaalton, can you please look at freeipa autopkgtest failure? it is blocking migration...
<jbicha> acheronuk: my guess is language-selector's data/pkg_depends file
<acheronuk> jbicha: that seems to have kde-l10- for kdelibs5-data, but nothing wanting language-pack-kde-*yourlanguage*
<acheronuk> thanks
<jbicha> acheronuk: you could try asking GunnarHJ, he helps a lot with i18n issues
<acheronuk> thanks for the suggestion. I could just rip out all conflicting stuff from our old translations, and break/replace against older versions, but getting rid entirely would be neater
-queuebot:#ubuntu-release- New sync: haskell-regex-tdfa-text (bionic-proposed/primary) [1.0.0.3-1]
<tjaalton> LocutusOfBorg: which migration? i know of the failure, might need removing and blocking it for now
<LocutusOfBorg> libunistring tjaalton ...
<tjaalton> LocutusOfBorg: freeipa is green for it, tracker isn't
<jbicha> tjaalton: freeipa has to be rebuilt against libunistring for the transition and the rebuilt version doesn't pass its autopkgtests
<tjaalton> ok
-queuebot:#ubuntu-release- New binary: purple-discord [amd64] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-discord [s390x] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-discord [i386] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvpx [s390x] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: purple-discord [armhf] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-discord [arm64] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-discord [ppc64el] (bionic-proposed/none) [0.9.2017.12.27.git.9b7c3ad-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvpx [amd64] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libvpx [ppc64el] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libvpx [i386] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libvpx [arm64] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libvpx [armhf] (bionic-proposed/main) [1.7.0-3] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.17]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-36.40] (core, kernel)
#ubuntu-release 2018-02-18
-queuebot:#ubuntu-release- New binary: flex [s390x] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: bart-view [ppc64el] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flex [i386] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: node-gulp-load-plugins [amd64] (bionic-proposed/none) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mississippi [amd64] (bionic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postcss-load-plugins [amd64] (bionic-proposed/none) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nyx [amd64] (bionic-proposed/none) [2.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bart-view [s390x] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mdn-data [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ssri [amd64] (bionic-proposed/none) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-call-limit [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-normalize-range [amd64] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bart-view [amd64] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flameshot [ppc64el] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flex [ppc64el] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: gnome-usage [ppc64el] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jboss-bridger [amd64] (bionic-proposed/none) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postcss-load-options [amd64] (bionic-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-require-from-string [amd64] (bionic-proposed/none) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bart-view [armhf] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-usage [i386] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-is-directory [amd64] (bionic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-fitbit [amd64] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: flameshot [s390x] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postcss-minify-font-values [amd64] (bionic-proposed/none) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-usage [s390x] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bart-view [i386] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bart-view [arm64] (bionic-proposed/none) [0.1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flex [arm64] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: flameshot [i386] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-consolidate [amd64] (bionic-proposed/none) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flameshot [amd64] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flameshot [armhf] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flex [armhf] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: flameshot [arm64] (bionic-proposed/none) [0.5.0+git20180114-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-usage [amd64] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flex [amd64] (bionic-proposed/main) [2.6.4-5] (core)
-queuebot:#ubuntu-release- New binary: gnome-usage [arm64] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-usage [armhf] (bionic-proposed/none) [3.27.90-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-usage [amd64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-usage [armhf] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-usage [ppc64el] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-usage [arm64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-usage [s390x] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-usage [i386] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted flameshot [amd64] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flameshot [armhf] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flameshot [ppc64el] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flameshot [arm64] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flameshot [s390x] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flameshot [i386] (bionic-proposed) [0.5.0+git20180114-1]
-queuebot:#ubuntu-release- New: accepted flex [amd64] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted flex [armhf] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted flex [ppc64el] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted flex [arm64] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted flex [s390x] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted flex [i386] (bionic-proposed) [2.6.4-5]
-queuebot:#ubuntu-release- New: accepted bart-view [amd64] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted bart-view [armhf] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted bart-view [ppc64el] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted bart-view [arm64] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted bart-view [s390x] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted bart-view [i386] (bionic-proposed) [0.1.00-1]
-queuebot:#ubuntu-release- New: accepted jboss-bridger [amd64] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted node-consolidate [amd64] (bionic-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted node-is-directory [amd64] (bionic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted node-mississippi [amd64] (bionic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-load-options [amd64] (bionic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-minify-font-values [amd64] (bionic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted node-ssri [amd64] (bionic-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-call-limit [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-mdn-data [amd64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-load-plugins [amd64] (bionic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-gulp-load-plugins [amd64] (bionic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted node-require-from-string [amd64] (bionic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-normalize-range [amd64] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted libvpx [amd64] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted libvpx [armhf] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted libvpx [ppc64el] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted libvpx [arm64] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted libvpx [s390x] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted libvpx [i386] (bionic-proposed) [1.7.0-3]
-queuebot:#ubuntu-release- New: accepted purple-discord [amd64] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted purple-discord [armhf] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted purple-discord [ppc64el] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted purple-discord [arm64] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted purple-discord [s390x] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted purple-discord [i386] (bionic-proposed) [0.9.2017.12.27.git.9b7c3ad-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [sync] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted plastex [amd64] (bionic-proposed) [0.9.2-1.2]
-queuebot:#ubuntu-release- New: accepted python-pgq [amd64] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted nyx [amd64] (bionic-proposed) [2.0.4-2]
-queuebot:#ubuntu-release- New: accepted python-fitbit [amd64] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [ppc64el] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [s390x] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [amd64] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [i386] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [arm64] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-regex-tdfa-text [armhf] (bionic-proposed/none) [1.0.0.3-1] (no packageset)
<tsimonq2> juliank: I did what I could to try and find a solution for bug 1746807; I've figured out exactly which two lines of code are problematic but I can't seem to find out why those lines would be an issue.
<ubot5> bug 1746807 in apt (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<juliank> tsimonq2: thanks
<tsimonq2> juliank: yw, I learned how to use git bisect as a result of this :)
<juliank> tsimonq2: I think the difference is that getCompressorExtensions() only uses compressors c where if (c->Extension.empty() == false && c->Extension != ".")
<juliank> That might mean it ignores uncompressed files now, but did not before
<juliank> yup
<tsimonq2> aha
<juliank> tsimonq2: Is there an uncompressed Packages file on these discs?
<tsimonq2> juliank: sec, checking
<juliank> The error was "base-installer: Stat failed for /media/cdrom/dists/bionic/main/dist-upgrader/binary-all/Packages - stat (2: No such file or directory)"
<tsimonq2> Right
<juliank> which was misleading: It checked all compressors, but ignored uncompressed files
<tsimonq2> ahhhhh, that would make sense
<tsimonq2> juliank: That file is empty anyways
<tsimonq2> /media/cdrom/dists/bionic/main/dist-upgrader/binary-all/Packages.
<juliank> still
<tsimonq2> Right
<juliank> t
<juliank> tsimonq2: need to write a test case. boring!
<juliank> :D
<tsimonq2> juliank: want a test case from *me*? :D
<juliank> I want to integrate it into the test-apt-cdrom one
<tsimonq2> ok
<tsimonq2> Test cases are always good \o/
<juliank> Basically, after adding the cdrom, delete hte .gz Packages and do it again :)
<tsimonq2> Right :)
<juliank> not that easy apparently
<tsimonq2> juliank: ftr, even if it's not relevant here, we do have https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tests/test_build.py#L92 that I spotted the other day
<tsimonq2> juliank: I'm going to go to bed (2+ AM here) but do keep me posted
<tsimonq2> o/
<juliank> ok
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [amd64] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [armhf] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [ppc64el] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [arm64] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [s390x] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-regex-tdfa-text [i386] (bionic-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New binary: bulk-media-downloader [amd64] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mithril [amd64] (bionic-proposed/none) [1.1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [ppc64el] (bionic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: proxy-switcher [amd64] (bionic-proposed/none) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-fuel-tools [ppc64el] (bionic-proposed/none) [1.0.0+dfsg4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [armhf] (bionic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [arm64] (bionic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [s390x] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [amd64] (bionic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [i386] (bionic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-fuel-tools [amd64] (bionic-proposed/none) [1.0.0+dfsg4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [ppc64el] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-fuel-tools [arm64] (bionic-proposed/none) [1.0.0+dfsg4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-fuel-tools [i386] (bionic-proposed/none) [1.0.0+dfsg4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-fuel-tools [armhf] (bionic-proposed/none) [1.0.0+dfsg4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [amd64] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [i386] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [arm64] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jpype [armhf] (bionic-proposed/universe) [0.6.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apticron [amd64] (bionic-proposed/universe) [1.2.0] (no packageset)
-queuebot:#ubuntu-release- New source: gnome-themes-extra (bionic-proposed/primary) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-zglob [amd64] (bionic-proposed/none) [0.0~git20171230.4959821-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [i386] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [s390x] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [i386] (bionic-proposed/none) [1.0.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [s390x] (bionic-proposed/none) [1.0.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [amd64] (bionic-proposed/none) [1.0.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [arm64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [armhf] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [ppc64el] (bionic-proposed/universe) [1.0.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfnt2woff-zopfli [ppc64el] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [arm64] (bionic-proposed/universe) [1.0.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntpsec [armhf] (bionic-proposed/universe) [1.0.0+dfsg1-1] (no packageset)
#ubuntu-release 2019-02-11
-queuebot:#ubuntu-release- New source: golang-1.11-race-detector-runtime (disco-proposed/primary) [0.0+svn332029-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pkpgcounter [amd64] (disco-proposed) [3.50-8]
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [ppc64el] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [s390x] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [amd64] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [i386] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [arm64] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-nginx-vts-exporter [armhf] (disco-proposed/universe) [0.10.3+git20180501.43b4556+ds-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [amd64] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [armhf] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [ppc64el] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [arm64] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [s390x] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
-queuebot:#ubuntu-release- New: accepted prometheus-nginx-vts-exporter [i386] (disco-proposed) [0.10.3+git20180501.43b4556+ds-2]
<cpaelzer> vorlon: the autopkgtests in -devel are on the way through Debian MP is up
<cpaelzer> I considered that right away, I just wanted to avoid adding delta to sync it one week later
<cpaelzer> only if there is no response by Debian I'll upload the autopkgtest as delta to libpam-mount
-queuebot:#ubuntu-release- New: accepted golang-1.11-race-detector-runtime [source] (disco-proposed) [0.0+svn332029-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-1.11-race-detector-runtime [amd64] (disco-proposed/universe) [0.0+svn332029-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-1.11-race-detector-runtime [amd64] (disco-proposed) [0.0+svn332029-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-16.17]
<joalif> hi sil2100, could you please approve the upload of libguestfs for Xenial LP: #1632405 and #1814939
<ubot5> Launchpad bug 1814939 in libguestfs (Ubuntu Xenial) "[FTBFS] libguestfs fails to build on Xenial - dh_install --fail-missing" [Medium,In progress] https://launchpad.net/bugs/1814939
<ubot5> Launchpad bug 1632405 in libguestfs (Ubuntu Xenial) "virt-customize enters infinite loop: dhclient-script: cannot open /etc/fstab" [Medium,In progress] https://launchpad.net/bugs/1632405
<sil2100> joalif: sure! Let me review it in a few
<joalif> sil2100, thank you so much!!
-queuebot:#ubuntu-release- Unapproved: isync (bionic-proposed/universe) [1.3.0-1build1 => 1.3.0-1ubuntu0.18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: isync (cosmic-proposed/universe) [1.3.0-1build1 => 1.3.0-1ubuntu0.18.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-boto (bionic-proposed/universe) [2.44.0-1ubuntu2 => 2.44.0-1ubuntu2.18.04.0] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: python-boto (cosmic-proposed/main) [2.44.0-1ubuntu2 => 2.44.0-1ubuntu2.18.10.0] (ubuntugnome)
<ginggs> hi archive admins, is it possible to remove patchelf 0.9-51-g1fa4d36-0ubuntu18.04.1 from -proposed so that 0.9+52.20180509-1 can be sync'd?
<ginggs> unfortunately 0.9-51... seems to be a higher version than 0.9+52...
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (xenial-proposed) [1:1.32.2-4ubuntu2.1]
<apw> ginggs, doesn't that same problem apply to the version in -release as well ?
<apw> ginggs, seemingly not, though i a struggling to understand that
<ginggs> apw: dpkg --compare-versions 0.9+52.20180509-1 gt 0.9-1 && echo true
<apw> huh
<apw> ginggs, right, so if that is true, why is the other not true
<apw> it cirtainly is not intuitive
<ginggs> apw: yeah, i'm trying to remember the rule for multiple -
<apw> ginggs, does anything other than snapcraft use that ?
<ginggs> apw: pyside2 build-depends on patchelf
<cjwatson> The rule for multiple - is that the split is on the *last* -
<cjwatson> So they're usually a mistake because in the first case there the upstream version part is "0.9-51"
<cjwatson> Which probably isn't what anyone expected
<apw> which i assume is why debian seems to prefer +thingN on its versions
<cjwatson> Well, +thingN is for a revision of the upstream tarball, like +dfsg1 meaning "had to strip out some non-free files"
<ginggs> is the upstream part of the first 0.9-51-g1fa4d36 ?
<cjwatson> Er yes, I missed a bit
<apw> yeah that
<cjwatson> So I guess 0.9+52.blah is a snapshot?
<cjwatson> If so it should indeed not have "-" in the upstream revision part.
<cjwatson> I think I agree that removing the current one in -proposed makes sense assuming it maintains coherency
<apw> cjwatson, yeah will check that and action
<ginggs> thanks apw cjwatson
<apw> ginggs, ok both of the disco-release versions of snapcraft and pyside2 built using that broken one
<apw> ginggs, so ... i guess we could do with sync'ing the new debian version into a PPA, and building both of those against it, to be sure they arn't going to be a problem
<slashd> sil2100, o/ could you please approve the upload of pciutils for X & B (LP: #1815212)
<ubot5> Launchpad bug 1815212 in pciutils (Ubuntu Bionic) "[Xenial][Bionic][SRU] Update pci.ids to version 2018.07.21" [Low,In progress] https://launchpad.net/bugs/1815212
<ginggs> apw: ack, i'll try that
<apw> ginggs, let me know how it goes, thanks
<sil2100> slashd: looking in a minute!
<slashd> sil2100, tks
<sil2100> slashd: ok, the package seems to look ok, the test case could use some work though - it's not clear how to verify this, but since this is just updating the pci.ids, I guess there's no perfect test case here
<sil2100> So I'll accept it
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (bionic-proposed) [1:3.5.2-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (xenial-proposed) [1:3.3.1-1.1ubuntu1.3]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.3-2 => 1:1.6.5-1ubuntu1~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (cosmic-proposed/main) [1:1.6.4-2ubuntu1 => 1:1.6.5-1ubuntu1~18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: libxcb (bionic-proposed/main) [1.13-1 => 1.13-1.1] (core, xorg)
<ginggs> apw:  pyside2 builds ok, snapcraft failed; but that is expected i guess since it failed in the archive rebuild https://launchpad.net/ubuntu/+archive/test-rebuild-20181220/+build/15885022
<apw> ginggs, bah on snapcraft
-queuebot:#ubuntu-release- Unapproved: uvloop (bionic-proposed/main) [0.8.1+ds1-1 => 0.8.1+ds1-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1.3 => 1:9.11.3+dfsg-1ubuntu1.4] (core)
<ginggs> apw: the snapcraft build failure is two test failures due to two utilities subtly changing subtly their output
<ginggs> testtools.matchers._impl.MismatchError: 'Path "nonexisting.snap" does not exist' not in 'Usage: run sign-build [OPTIONS] <snap-file>\nTry "run sign-build --help" for help.\n\nError: Invalid value for "<snap-file>": File "nonexisting.snap" does not exist.\n'
<ginggs> testtools.matchers._impl.MismatchError: 'Missing argument "ci-system".  Choose from travis.' not in 'Usage: run enable-ci [OPTIONS] <ci-system>\nTry "run enable-ci --help" for help.\n\nError: Missing argument "<ci-system>".  Choose from:\n\ttravis.\n'
<ginggs> is it worth proving that in a PPA build?
<apw> ginggs, i guess the problem is ideally we would get this rebuilt to eliminate the going version ...
-queuebot:#ubuntu-release- Unapproved: libevent-rpc-perl (bionic-proposed/universe) [1.08-2 => 1.08-2ubuntu0.1] (no packageset)
<ginggs> apw: isn't patchelf just a utility that is used during the build? i miss what needs to be eliminated
<apw> ginggs, that that binary was built using it, so if we delete it it isn't reproducible any more, gpl etc
<apw> ginggs, anyhow i think we can dlete it and let the sync occur so we can throw rebuilds on top
<ginggs> apw: ok, thanks
<apw> ginggs, ok gone ...
-queuebot:#ubuntu-release- Unapproved: python-httplib2 (bionic-proposed/main) [0.9.2+dfsg-1 => 0.9.2+dfsg-1ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: python-imaplib2 (bionic-proposed/universe) [2.57-1 => 2.57-1ubuntu0.1] (no packageset)
<xnox> Laney, do we need to adjust our web ui? for "code 14" results? sed/universe) [2.57-1 => 2.57-1ubuntu0.1] (no packageset)
<xnox> * jhodapp (~jhodapp@108-90-17-180.lightspeed.cicril
<xnox> bah
<xnox> http://autopkgtest.ubuntu.com/packages/resource-agents/bionic/armhf
<Laney> looks like it
<Laney> should be treated like an error result?
<xnox> Laney, yeah, but i guess that's new
<Laney> dunno
<Laney> anyway, if you wanted to propose that, would be nice :-)
<Laney> does britney handle it well?
<xnox> didn't look yet
<bdmurray> cpaelzer: bug 1657409 was resolved but no team ended up being subscribed to the package
<ubot5> bug 1657409 in virglrenderer (Ubuntu) "[MIR] virglrenderer" [Medium,Fix released] https://launchpad.net/bugs/1657409
<bdmurray> doko: ^^
<slashd> sil2100, still around have time for another release ? apt on trusty (LP: 1815129)
<ubot5> Launchpad bug 1815129 in apt (Ubuntu Trusty) "apt segfaults when generating cache file" [Medium,In progress] https://launchpad.net/bugs/1815129
<sil2100> slashd: sure
<slashd> sil2100, thanks owe you a beer now
-queuebot:#ubuntu-release- Unapproved: accepted isync [source] (cosmic-proposed) [1.3.0-1ubuntu0.18.10.0]
<sil2100> slashd: no worries! Although hm, this apt upload is a bit strange
<sil2100> slashd: like, first of all, is that intentional that so many files in doc/en/* got dropped?
<sil2100> slashd: the changelog mentions 'Clean up some build artifacts' but this seems a bit much for a 'built artifact'
<sil2100> slashd: another thing, I'd say LP: #1815187 needs a better clean up and would be nice if Julian could mention if this affects only trusty
<ubot5> Launchpad bug 1815187 in apt (Ubuntu) "Fix crash when opening DepCache before Cache" [Undecided,New] https://launchpad.net/bugs/1815187
<sil2100> Like, a test case that doesn't have TODO in it ;)
<slashd> sil2100, I didn't read the sru tmpl as it's not my upload, will let julian answer theses question ;)
<slashd> sil2100, thanks anyway ;)
<sil2100> juliank: ^ regarding your apt changes, why are so many documentation files dropped?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-166.216] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted python-boto [source] (cosmic-proposed) [2.44.0-1ubuntu2.18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted isync [source] (bionic-proposed) [1.3.0-1ubuntu0.18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted python-boto [source] (bionic-proposed) [2.44.0-1ubuntu2.18.04.0]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-166.216]
<LocutusOfBorg> apw, http://autopkgtest.ubuntu.com/packages/v/virtualbox/disco/i386
<LocutusOfBorg> this needs an hint, because of the uninstallability there... :(
<LocutusOfBorg> making src:linux autopkgtestsuite sad
<jbicha> LocutusOfBorg: how about removing virtualbox-qt (and whatever other NBS i386 stuff)?
<LocutusOfBorg> feel free to open a bug, I requested the same in debian and worked, not sure what went wrong in Ubuntu
<juliank> sil2100: They are not dropped
<juliank> sil2100: They are generated at build time, but somehow ended up in a previous tarball
<juliank> sil2100: I think somebody built from an unclean tree once
<cpaelzer> bdmurray: I'll ping powersj again to subscribe us but he is on travels atm so it might take afew days
<cpaelzer> thanks for the hint
<cpaelzer> bdmurray: mail sent, will be done once he has network again
<bdmurray> cpaelzer: I can do it if that's the right team.
<cpaelzer> bdmurray: it will be ~ubuntu-server
<bdmurray> cpaelzer: cool, its done
<vorlon> coreycb: should python-formencode get merged this cycle?  listed as ubuntu-openstack owned package, last upload was by lamont in 2016
<coreycb> vorlon: yes looks like we still need it so i'll take a look
-queuebot:#ubuntu-release- New binary: pyparted [amd64] (disco-proposed/main) [3.11.2-2ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- New: accepted pyparted [amd64] (disco-proposed) [3.11.2-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (disco-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (disco-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (disco-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (disco-proposed) [1.2.4-1]
<sil2100> juliank: ACK!
<sil2100> Thanks
<juliank> sil2100: I rebuilt from git to get rid of this cruft that accumulated there
<juliank> :)
<juliank> and because I have patches in queues on git
<sil2100> juliank: hah, I saw the changelog entry about removing cruft but this seemed a bit much for cruft ;p
<sil2100> Now I know this is what you actually meant
<sil2100> Will pick it up tomorrow o/
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [amd64] (disco-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [ppc64el] (disco-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [s390x] (disco-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [i386] (disco-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [arm64] (disco-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-tags [armhf] (disco-proposed/universe) [3.4.0-1] (no packageset)
#ubuntu-release 2019-02-12
-queuebot:#ubuntu-release- New binary: python-opcua [amd64] (disco-proposed/none) [0.98.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libseccomp (bionic-proposed/main) [2.3.1-2.1ubuntu4 => 2.3.1-2.1ubuntu4.1] (core)
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1815567
<ubot5> Ubuntu bug 1815567 in virtualbox (Ubuntu) "remove virtualbox-qt on disco/i386" [Undecided,New]
<LocutusOfBorg> :)
<LocutusOfBorg> jbicha, ^^
-queuebot:#ubuntu-release- New: accepted python-opcua [amd64] (disco-proposed) [0.98.6-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [arm64] (disco-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [i386] (disco-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [s390x] (disco-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [amd64] (disco-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [ppc64el] (disco-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-tags [armhf] (disco-proposed) [3.4.0-1]
<LocutusOfBorg> seriously AA, what the hell is going on?
<LocutusOfBorg>  virtualbox-dkms | 5.2.24-dfsg-4build1                 | disco/multiverse           | all
<LocutusOfBorg>  virtualbox-dkms | 6.0.4-dfsg-5                        | disco/multiverse           | all
<LocutusOfBorg>  virtualbox-source | 5.2.24-dfsg-4build1                 | disco/multiverse           | all
<LocutusOfBorg>  virtualbox-source | 6.0.4-dfsg-5                        | disco/multiverse           | all
<LocutusOfBorg> all the vbox binaries seems to be having some sadness :(
<LocutusOfBorg> vorlon, ^^
<cjwatson> LocutusOfBorg: I think that's just because virtualbox-qt is NBS on i386
<cjwatson> so there are different versions of arch-dep binaries in the suite and so all the arch-indep ones get held
<cjwatson> LocutusOfBorg,vorlon: I've removed that, so the rest should clear out shortly
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.20]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-143.169] (core, kernel)
<LocutusOfBorg> yeah, vbox seems sorted out, lets see what happens now with autopkgtests
<LocutusOfBorg>  ./sil2100:force-badtest virtualbox-ext-pack/all/i386
<LocutusOfBorg> can we please add virtualbox/all/i386? same reason for it...
<LocutusOfBorg> sil2100, ^^
<LocutusOfBorg> it is blocking lots of stuff, e.g. libnotify, kernel xinerama qtbase...
<LocutusOfBorg> linux-signed and libnotify actually, maybe a versioned hint is enough, because a no-change rebuild of linux and libnotify might actually be enough to not trigger the new test at all
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-143.169]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190108.1-0ubuntu0.18.10.1 => 1:20190212.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190108.1-0ubuntu0.16.04.1 => 1:20190212.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190108.1-0ubuntu0.18.04.1 => 1:20190212.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20190108.1-0ubuntu0.14.04.1 => 1:20190212.1-0ubuntu0.14.04.1] (no packageset)
<fidencio> cyphermox: around? so, basically, I've got to your http://people.canonical.com/~mtrudel/preseed/full-bionic.cfg preseed. Were you able to have it working with live medias? What's the kernel command line you've used for that? I'm struggling really hard to have live medias (both server and desktop) to work with preseed as it doesn't pass the "Please choose your preferred language." screen
<jbicha> LocutusOfBorg: I rebuilt libnotify but we still got the virtualbox/i386 trigger
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (bionic-proposed/universe) [1.4.1-0ubuntu1 => 1.4.1-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (cosmic-proposed/universe) [2.0.0-0ubuntu2 => 2.0.0-0ubuntu2.1] (no packageset)
<cyphermox> fidencio: for preseeded live images (desktop, not server); you need a few different keys in
<cyphermox> a bit like what's in the utah-bionic.cfg file
<cyphermox> if you're talking about server-live, then I don't know how to preseed it
<fidencio> cyphermox: do you have the kernel command line somewhere that could be used for that? seems that the kernel command line is quite different for live and non-live medias
<cyphermox> sure. it's mostly the same actually
<cyphermox> you need to set url and 'automatic-ubiquity' IIRC
<fidencio> cyphermox: seems that if I don't pass boot=casper the boot up bails
<cyphermox> fidencio: right
<fidencio> and I'm stuck in initramfs screen
<cyphermox> I mean, everything that is normally on the kernel command-line
<cyphermox> you change url= from the standard desktop one, and add 'automatic-ubiquity'
<cyphermox> and that will only work for desktop images
<cyphermox> everything else stays the same; especially boot=casper. You can't get around that
<fidencio> cyphermox: okay, seems that I was using a server live media
<fidencio> cyphermox: just using automatic-ubiquity boot=casper + the very same preseed I had for the server image works as expected
<cyphermox> with server media?
<fidencio> cyphermox: no, with desktop media
<cyphermox> ok, got it
<fidencio> cyphermox: that was my mistake :-(
<fidencio> now, time to try to figure out what I do need to make a server live media to work
<cyphermox> well, not a mistake if you want to test the server media
<fidencio> cyphermox: I want both and, for some reason, I thought that starting with the server live would be easier
<fidencio> okay, okay
<fidencio> cyphermox: thanks *a* *lot* for the help
<fidencio> didrocks: out of curiosity, is ubuntu-18.10 live server already using the yaml files?
<fidencio> didrocks: *already using the yaml files for unattended installation
<didrocks> fidencio: yes, even 18.04 are using curtin, but it seems that subiquity needs its own preseeding still
<didrocks> so, it's not pure yaml only
<fidencio> didrocks: aha! 18.04 live server, right? not live desktop
<didrocks> but only people who worked on subiquity would really know at this stage (cyphermox, xnox, mwhudsonâ¦)
<didrocks> fidencio: yes, live server
<fidencio> didrocks: now it makes a lot of sense why I'm failing miserably to make the installation work with a live server
<didrocks> fidencio: normally, I think that preseeding should create the yaml file, but again, not a subiquity expert :p
<didrocks> the finale goal though (but will take some times) is to only have yaml for those anyway
<xnox> fidencio, hi, if you are preseeding, just use MAAS. server live is meant to be used interractively only, and unlike the d-i based server install, it only has a handful of screens to answer anyway.
<xnox> didrocks, there is no unattended install support in server live
<fidencio> xnox: perfect!
<fidencio> xnox: thanks a lot for the answer!
<didrocks> xnox: wondering why there are some debconf hooks (but I may be wrong, maybe there isn't)
<xnox> didrocks, that's in curtin....
<xnox> didrocks, and cloud-init can do that too
<xnox> didrocks, but that's not for installer.
<Laney> vorlon: juliank: sil2100: would any of you like to look into what is going on with armhf?
<Laney> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/r/r-bioc-delayedarray/20190212_142628_57297@/log.gz
<juliank> ack
<juliank> Laney: works for me
<juliank> Laney: were there a lot of failures like this?
<juliank> sounds like the server went out between update and install
<Laney> yes
<Laney> lots and lots
<juliank> this is odd
<Laney> look for /unknown on excuses
<Laney> but I've been retrying them so it doesn't look as bad as it really is
<juliank> Laney: I did 3 runs and could not reproduce the issue, so it's unclear to me what's going on. It looks like a networking issue, but who knows
<Laney> well yes, that's the problem
<Laney> Sometimes it happens in the middle of a run too, so some of the armhf regressions will be due to this
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.2] (20190210) has been added
<fidencio> cyphermox: last question, what's the way to avoid the "Please remove the installation medium, then press ENTER:" message that I get when using a live desktop media?
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190212.1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190212.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190212.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190212.1-0ubuntu0.14.04.1]
<cyphermox> fidencio: IIRC it's ubiquity ubiquity/reboot boolean true
<cyphermox> "ubiquity ubiquity/reboot boolean true" but it may or may not only deal with ubiquity's prompting.. it's been a while since I looked in that
<blackboxsw> ffe
<blackboxsw> sil2100:  I've queued an FFE bug that probably needs some attention at some point and I'm not certain of the next steps. UA Client is in progress and will be waiting on availability of an active backend service before I can attach package diffs for this FFE.  https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1814157
<ubot5> Ubuntu bug 1814157 in ubuntu-advantage-tools (Ubuntu) "[FFe] ubuntu-advantage-tools v.19" [Undecided,New]
<blackboxsw> sil2100: do you, or others have suggestions on next steps to ensure this FFe gets a review before freeze? Would I need wait until I can attach the intended package patch/diff and manual test runs against the backend services before trying to get a review on this FFe, per the docs https://wiki.ubuntu.com/FreezeExceptionProcess?
<blackboxsw> I thought it best to queue the FFe bug as early as possible for review, but maybe it just needs to wait until we have final package diff stable/complete.
<sil2100> blackboxsw: hey! There's still like 1.5 weeks until Feature Freeze for disco, do you mean the new ubuntu-advantage-tools version won't be available for upload before the deadline?
<blackboxsw> sil2100: my expectation is that the backend service code and published routes should be stabilizing this week and that we can shake out bugs over the next week and a half. Having an upload available in 1.5 weeks is a  tight timeline. but I think we'll have something verified by then.
<blackboxsw> sil2100: I didn't know if it was best to get review on the FFe prior to having that upload available in this case given that the timeline is tight for having an upload
<LocutusOfBorg> doko, may I upload the fixed ncurses? sed vwprintw -> vw_printw on debian/tests/build
<sil2100> blackboxsw: hmmm, I guess we could review this beforehand, just in case things slip - but anyway, let's try to get everything landed before FF, I'll take a look at the FFe in the meantime
<sil2100> But if the feature will land a week later, I still think it won't be a problem
<sil2100> But yeah, let me read the FFe bug you have provided, thanks for that!
<blackboxsw> sil2100: thanks for the looksie. I just didn't want to suprise folks if we end up missing by a few days due to not actually being able to validate against a live backend service yet
<blackboxsw> when I have something that is functional/tested against a running backend I'll update the bug accordingly and ping
<vorlon> mitya57: qtbase-opensource-src-gles seems to be stalled in -proposed because binaries end up uninstallable on arm64; I haven't had a chance to dig into it
-queuebot:#ubuntu-release- New binary: budgie-extras [amd64] (disco-proposed/universe) [0.8.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.17]
-queuebot:#ubuntu-release- New source: matplotlib2 (disco-proposed/primary) [2.2.3-5ubuntu1]
<LocutusOfBorg> please accept matplotlib2  [2.2.3-5ubuntu1]
<LocutusOfBorg> the sphinx build failure is fixed now
-queuebot:#ubuntu-release- New sync: matplotlib2 (disco-proposed/primary) [2.2.3-5]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.43]
#ubuntu-release 2019-02-13
-queuebot:#ubuntu-release- New binary: filemanager-actions [i386] (disco-proposed/universe) [3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-apptools [amd64] (disco-proposed/universe) [4.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: filemanager-actions [amd64] (disco-proposed/universe) [3.4-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [18.06.1-0ubuntu1.2~16.04.1 => 18.09.2-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.06.1-0ubuntu1.2~18.04.1 => 18.09.2-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [18.06.1-0ubuntu1.2 => 18.09.2-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: filemanager-actions [s390x] (disco-proposed/universe) [3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: filemanager-actions [ppc64el] (disco-proposed/universe) [3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: filemanager-actions [arm64] (disco-proposed/universe) [3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: filemanager-actions [armhf] (disco-proposed/universe) [3.4-2] (no packageset)
<Trevinho> please when anyone in the SRU team has team, give a look at the gnome-shell (stack) stuff we've prepared some weeks ago, as there are some wanted fixes that would be nice to get into proposed verification ASAP.
<jbicha> vorlon: if you're still around: https://code.launchpad.net/~jbicha/britney/add-vbox/+merge/363107
<mitya57> vorlon: I woke up and looks like it has migrated now
<mitya57> Ah, sorry, you mean -gles, not the normal qtbase package.
 * mitya57 will look a bit later
<vorlon> mitya57: well, now it's failing to migrate because of a newly-triggered autopkgtest that fails (soqt)
<vorlon> with a very strange error ; retrying
<vorlon> ah, it's an error that was fixed in a -1ubuntu1
-queuebot:#ubuntu-release- New sync: matplotlib2 (disco-proposed/primary) [2.2.3-6]
-queuebot:#ubuntu-release- Unapproved: linux-meta-hwe-edge (xenial-proposed/main) [4.15.0.45.64 => 4.15.0.46.65] (kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-hwe-edge [source] (xenial-proposed) [4.15.0.46.65]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [amd64] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [armhf] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [ppc64el] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [arm64] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [s390x] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted filemanager-actions [i386] (disco-proposed) [3.4-2]
-queuebot:#ubuntu-release- New: accepted python-apptools [amd64] (disco-proposed) [4.4.0-1]
-queuebot:#ubuntu-release- Unapproved: landscape-client (cosmic-proposed/main) [18.01-0ubuntu4.1 => 18.01-0ubuntu4.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3.2 => 18.01-0ubuntu3.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2.16.04.5 => 16.03-0ubuntu2.16.04.6] (ubuntu-server)
-queuebot:#ubuntu-release- New sync: binutils-mipsen (disco-proposed/primary) [2~c2]
-queuebot:#ubuntu-release- New: accepted binutils-mipsen [sync] (disco-proposed) [2~c2]
-queuebot:#ubuntu-release- New: rejected matplotlib2 [sync] (disco-proposed) [2.2.3-5]
-queuebot:#ubuntu-release- New: accepted matplotlib2 [sync] (disco-proposed) [2.2.3-6]
-queuebot:#ubuntu-release- New: accepted budgie-extras [amd64] (disco-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected matplotlib2 [source] (disco-proposed) [2.2.3-5ubuntu1]
-queuebot:#ubuntu-release- New sync: spirv-llvm-translator (disco-proposed/primary) [8.0.0-1]
-queuebot:#ubuntu-release- New binary: matplotlib2 [amd64] (disco-proposed/universe) [2.2.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1009.9~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted matplotlib2 [amd64] (disco-proposed) [2.2.3-6]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [sync] (disco-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [i386] (disco-proposed/universe) [8.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [amd64] (disco-proposed/universe) [8.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [amd64] (disco-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [i386] (disco-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- Unapproved: s390-tools (cosmic-proposed/main) [2.6.0-0ubuntu7.1 => 2.6.0-0ubuntu7.2] (core)
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu3.1 => 2.3.0-0ubuntu3.2] (core)
-queuebot:#ubuntu-release- New source: masakari (disco-proposed/primary) [7.0.0~b1-0ubuntu1]
<acheronuk> FYI 'networking infra issues' means non x86 build and autopkgtest queues have not moved for a few hrs. people are on it from what I was told in #launchpad though
-queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [source] (cosmic-proposed) [2.16-5ubuntu0.1]
#ubuntu-release 2019-02-14
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.2-0ubuntu9 => 3.30.2-0ubuntu10] (ubuntu-desktop)
<acheronuk> non x86 LP builders and autotest infra still not looking overly healthy this morning :/
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.2] has been updated (20190214)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.2] has been updated (20190214.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.2] has been updated (20190214.3)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (cosmic-proposed/main) [3.30.1-1build1 => 3.30.5-0ubuntu0.18.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: evolution-ews (cosmic-proposed/universe) [3.30.1-1 => 3.30.5-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1009.9~18.04.1]
-queuebot:#ubuntu-release- Unapproved: evolution-ews (bionic-proposed/universe) [3.28.1-1 => 3.28.5-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: evolution (cosmic-proposed/universe) [3.30.1-1build1 => 3.30.5-0ubuntu0.18.10.1] (ubuntukylin)
-queuebot:#ubuntu-release- New source: cross-toolchain-base-mipsen (disco-proposed/primary) [2ubuntu1]
-queuebot:#ubuntu-release- New: accepted cross-toolchain-base-mipsen [source] (disco-proposed) [2ubuntu1]
<mitya57> vorlon: yes, I fixed soqt. And qtbase-opensource-src-gles migrated yesterday \o/
<apw> fyi, /me is looking at the debian-installer breakage
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu2] (kubuntu, qt5, ubuntu-desktop)
<seb128> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1815579 might be worth having on the 18.04.2 list of problems to resolve
<ubot5> Ubuntu bug 1815579 in nvidia-graphics-drivers-390 (Ubuntu) "Broken dependencies with nvidia-driver-390 and xserver-xorg-hwe-18.04 in bionic" [Critical,Triaged]
<tseliot> apw: this ^ is breaking nvidia. I have a one-line fix, which I can upload today. How soon will we be able to release it?
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.77-0ubuntu0.18.04.1 => 390.77-0ubuntu0.18.04.2] (ubuntu-desktop)
<apw> tseliot, if it is obvious and verifiable, quickly
<apw> tseliot, but i asume we also need to coordinate with the point release
<seb128> apw, that's probably an issue we need solved before the point release gets out no?
<apw> seb128, i am sure it is, but that is for infinity/sil2000 to ack as much as anything
<apw> tseliot, get it in the queue asap
<seb128> apw, right, well I just want to make sure that the right people are aware, which I think you achieved with your ping :)
<tseliot> apw: I'm updating 340, and then everything should be ready
<sil2100> I have not been pinged!
<sil2100> The numbers are wrong!
<sil2100> ;)
<sil2100> Anyway, +1 on getting that fixed, it was already reported to me during the .2 testing
<sil2100> apw: are you reviewing it?
<tseliot> good point, I should've pinged you ;)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (bionic-proposed/restricted) [340.107-0ubuntu0.18.04.1 => 340.107-0ubuntu0.18.04.2] (ubuntu-desktop)
<apw> sil2100, can do
<tseliot> apw, sil2100: ok, both nvidia-graphics-drivers-340 and nvidia-graphics-drivers-390 are in the queue now
<sil2100> tseliot, apw: thanks!
<tseliot> :)
<apw> sil2100, ok for me to accept (assuming i like them?)
<sil2100> apw: +1 o/
<sil2100> apw: we'll leave it up to infinity to release it to -updates once he's up I guess, since he'll be around to do the image promotion anyway
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.107-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.77-0ubuntu0.18.04.2]
<apw> sil2100, tseliot ^^
<tseliot> apw: thanks!
<tseliot> Wimpress, seb128 ^
<Wimpress> tseliot: Awesome! Thank you :-D
<seb128> tseliot, great, thx
<tseliot> :)
<seb128> Wimpress, oh, you are on IRC, just ignoring me!
<Wimpress> seb128: DId you tag me?
<Wimpress> Not ignoring <3
<sil2100> apw: \o/
<seb128> Wimpress, I did /msg early in the afternoon but no worry
<Wimpress> Ah, I was out early.
<tjaalton> sil2100: I just verified bug 1815125, it's ready for bionic-updates
<ubot5> bug 1815125 in libx11 (Ubuntu Bionic) "constant video freezes in firefox with x-x-v-amdgpu 18.1.0" [Undecided,Fix committed] https://launchpad.net/bugs/1815125
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.2] (20190210) has been added
-queuebot:#ubuntu-release- New binary: postgresql-plsh [s390x] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.2] has been marked as ready
-queuebot:#ubuntu-release- New binary: postgresql-plsh [amd64] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dltlyse [amd64] (disco-proposed/none) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [amd64] (disco-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-pprof [amd64] (disco-proposed/none) [0.0~git20190109.e84dfd6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-plsh [i386] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [i386] (disco-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-plsh [ppc64el] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [s390x] (disco-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [ppc64el] (disco-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-plsh [arm64] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-plsh [armhf] (disco-proposed/universe) [1.20171014-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [arm64] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-data-dog-go-sqlmock.v1 [armhf] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [amd64] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [armhf] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [ppc64el] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [arm64] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [s390x] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-data-dog-go-sqlmock.v1 [i386] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [amd64] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [armhf] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [ppc64el] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [arm64] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [s390x] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted postgresql-plsh [i386] (disco-proposed) [1.20171014-3]
-queuebot:#ubuntu-release- New: accepted dltlyse [amd64] (disco-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-google-pprof [amd64] (disco-proposed) [0.0~git20190109.e84dfd6-1]
<cyphermox> SRU team: thanks for releasing shim-signed in xenial, but it really should go with dkms; otherwise it's uninstallable on UEFI (Breaks: dkms << 2.2.0.3-2ubuntu11.6)
<cyphermox> well, uninstallable on some setups; those that have dkms installed, etc. etc.
<infinity> cyphermox: I feel like that statement needs louder and more angry escalation.
<infinity> I only barely saw it in passing.
<infinity> cyphermox: dkms released now.
<cyphermox> infinity: shall take into advisement for next time, if there is a next time
<cyphermox> infinity: thanks :)
-queuebot:#ubuntu-release- Unapproved: freeipmi (xenial-proposed/main) [1.4.11-1.1ubuntu4~0.16.04 => 1.4.11-1.1ubuntu4.1~0.16.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: swayidle [ppc64el] (disco-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-zyedidia-pty [amd64] (disco-proposed/none) [1.1.1+git20180126.3036466-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaylock [ppc64el] (disco-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swayidle [s390x] (disco-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaylock [s390x] (disco-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swayidle [amd64] (disco-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaylock [i386] (disco-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swayidle [i386] (disco-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ulikunitz-xz [amd64] (disco-proposed/none) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaylock [amd64] (disco-proposed/none) [1.3-1] (no packageset)
<tsimonq2> infinity: How far are you in 18.04.2 publishing?
<tsimonq2> (I
<tsimonq2> (I'm just generally curious, nothing last minute (this time). :P)
<infinity> tsimonq2: Farish.
<tsimonq2> infinity: Alright. Do you have a rough time estimate?
<infinity> tsimonq2: Later than now, earlier than lots later.
<tsimonq2> infinity: Fair.
-queuebot:#ubuntu-release- New binary: swayidle [arm64] (disco-proposed/none) [1.2-1] (no packageset)
<wxl> according to softpedia it's already released https://news.softpedia.com/news/ubuntu-18-04-2-lts-released-with-linux-kernel-4-18-from-ubuntu-18-10-524961.shtml
-queuebot:#ubuntu-release- New binary: swayidle [armhf] (disco-proposed/none) [1.2-1] (no packageset)
<infinity> wxl: Well, then I guess I can stop.
<wxl> XD
-queuebot:#ubuntu-release- New binary: swaylock [arm64] (disco-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaylock [armhf] (disco-proposed/none) [1.3-1] (no packageset)
<vorlon> tsimonq2: nothing last minute> like adding snapd back in? ;)
<tsimonq2> vorlon: I said you were free to merge it. ;P
<vorlon> tsimonq2: you did? I don't think I saw this
<vorlon> oops
 * wxl hands tsimonq2 the wet fish
<vorlon> tsimonq2: our conversation was that I asked you if you wanted to sort it and you were noncommittal; I never saw you ack me merging
<vorlon> tsimonq2: oh, you mean on the MP now for devel
<vorlon> yeah, I'll land that
<tsimonq2> Yeah, sorry. Thanks.
<vorlon> merged
#ubuntu-release 2019-02-15
-queuebot:#ubuntu-release- Builds: 33 entries have been added, updated or disabled
<teward> was 18.04.2 released?  And if so did I miss an announcement email about it?
<guiverc> teward, i haven't seen it; I'm ~watching to put notice on fridge..
<teward> guiverc: yeah i didn't see an announcement either
<teward> I set up a poller on my locla mirror to tell me when 18.04.2 pulled down so I know it's present but
<infinity> teward: I mean, define "released".
<teward> infinity: as in "ready for use" :P
<infinity> teward: It's on mirrors.  I'm not sending the email and updating the topic until the website has the right versions/links, which should be in a few minutes.
<teward> ah, makes sense.
<teward> but it is on the mirrors so i'mi good to go.
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Cosmic 18.10 | Archive: Open | Disco 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
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1] (openstack, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 => 2.1.4-1ubuntu1.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 => 1.0.1-1ubuntu1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.2] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 => 1.84-1ubuntu0.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 => 2.7.15-4ubuntu4~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 => 2.0.9-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 => 3.7.2-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (cosmic-proposed/main) [1:12.2-0ubuntu4 => 1:12.2-0ubuntu5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.1 => 1:11.1-1ubuntu7.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted golang-github-ulikunitz-xz [amd64] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted swayidle [amd64] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted swayidle [armhf] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted swayidle [ppc64el] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted swaylock [amd64] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted swaylock [armhf] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted swaylock [ppc64el] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-zyedidia-pty [amd64] (disco-proposed) [1.1.1+git20180126.3036466-1]
-queuebot:#ubuntu-release- New: accepted swayidle [i386] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted swaylock [arm64] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted swaylock [s390x] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted swayidle [arm64] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted swaylock [i386] (disco-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted swayidle [s390x] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New binary: golang-github-zyedidia-terminal [amd64] (disco-proposed/universe) [0.0~git20180726.533c623-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-zyedidia-terminal [amd64] (disco-proposed) [0.0~git20180726.533c623-1]
<Laney> "Hmm, why are arm64/armhf's test queues not empty?"
 * Laney scrolls down
<Laney> "k, k, k, k, k, k, ..."
<Laney> The is-KDE-still-buildable network is in operation
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.37.2+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.37.2]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.37.2~14.04]
<apw> ^ these are going to be replaced shortly by a .3
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.8-0ubuntu0.18.04.2 => 12.2.11-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.0-0ubuntu1~18.04.3 => 2:10.3.5-6~ubuntu0.18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (cosmic-proposed/main) [2:10.3.0-0ubuntu3 => 2:10.3.5-6~ubuntu0.18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<tomreyn> hi. http://releases.ubuntu.com/18.04/ubuntu-18.04.2.0-live-server-amd64.iso.torrent , as found at https://www.ubuntu.com/download/alternative-downloads#bittorrents , returns a 404
<juliank> tomreyn: the .0 should not be there
<juliank> tomreyn: that is, http://releases.ubuntu.com/18.04/ubuntu-18.04.2-live-server-amd64.iso.torrent exists
<tomreyn> juliank: makes sense. do you know who could fix the url on the web page?
<tomreyn> juliank: looks like cpaelzer is taking care of it, thanks
<cpaelzer> "care" is the wrong word tomreyn :-)
<cpaelzer> I just pinged the people I thought coudl do something about it
<cpaelzer> juliank: in case you have the powers to do so, plese do so - I don't know what/who defines the content of the website
<juliank> I don't know what creates that particular site
<cpaelzer> ok, then I think we can stick to the highlights I have put in #ubunut-devel
<cpaelzer> the NUT :-/
<juliank> ah here we go https://github.com/canonical-websites/www.ubuntu.com/blob/master/templates/download/alternative-downloads.html
<infinity> juliank: Yeah, already poked the web team about it.
<juliank> ack
<infinity> cpaelzer: ^
<infinity> They're on it.
<cpaelzer> thanks infinity
<tomreyn> thanks all. also, this mirror, http://ftp.lug.ro/ubuntu-releases/ , has both 18.04.2 and 18.04.2.0 directories - was it like this on the main mirrors initially?
<infinity> tomreyn: It was like that briefly to paper over a different .0 bug on the website that was since fixed.
<infinity> tomreyn: mirrors will catch up and drop the .0
<tomreyn> alright :)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.4-1 => 1.2.4-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-46.49] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-46.49~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-46.49~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-46.49] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-46.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-46.49]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-46.49~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-46.49~16.04.1]
-queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.90ubuntu3.18.04.1 => 3.90ubuntu3.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (cosmic-proposed/main) [3.90ubuntu3.18.10.1 => 3.90ubuntu3.18.10.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected crash [source] (bionic-proposed) [7.2.3+real-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: crash (bionic-proposed/main) [7.2.1-1 => 7.2.1-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1028.29] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1028.29~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1028.29~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-143.169~14.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (disco-proposed/universe) [19.04] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.4-2 => 1.2.4-3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.4-2 => 1.2.4-3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.4-2 => 1.2.4-3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.4-2 => 1.2.4-3] (desktop-core)
#ubuntu-release 2019-02-16
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1011.11] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1011.11~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1011.11~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1028.29]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1011.11]
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (disco-proposed) [19.04]
#ubuntu-release 2019-02-17
-queuebot:#ubuntu-release- New binary: gnome-books [amd64] (disco-proposed/universe) [3.31.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-books [ppc64el] (disco-proposed/universe) [3.31.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-books [i386] (disco-proposed/universe) [3.31.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-books [arm64] (disco-proposed/universe) [3.31.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-books [armhf] (disco-proposed/universe) [3.31.90-1] (no packageset)
<bluesabre> Hello release team! How would I go about changing the max image size for the Xubuntu iso? We're receiving an oversized notification, and want to adjust it so these stop :)
-queuebot:#ubuntu-release- New binary: triehash [amd64] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [amd64] (disco-proposed/none) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apache-opennlp [amd64] (disco-proposed/universe) [1.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [s390x] (disco-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [ppc64el] (disco-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [i386] (disco-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [armhf] (disco-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone4 [arm64] (disco-proposed/universe) [4.0.1-2] (no packageset)
<mwhudson> bluesabre: i guess step 1 is waiting until the release team are not all on planes :)
<mwhudson> bluesabre: that said, i guess the answer is to submit a merge request on this code: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tree.py#L1901
<bluesabre> thank you mwhudson, I submitted the merge request here, https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/bionic_image_size/+merge/363298
-queuebot:#ubuntu-release- New: accepted apache-opennlp [amd64] (disco-proposed) [1.9.1-1]
-queuebot:#ubuntu-release- New: accepted capstone4 [arm64] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted capstone4 [i386] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted capstone4 [s390x] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted capstone4 [amd64] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted capstone4 [ppc64el] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted capstone4 [armhf] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted triehash [amd64] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: golang-github-thcyron-uiprogress [amd64] (disco-proposed/none) [0.0~git20171218.25e98ff-1] (no packageset)
#ubuntu-release 2020-02-10
<mwhudson> i don't suppose anyone who can log into autopkgtest infra is around?
<handsome_feng> Hi, ukui-menu 2.0.1-1 is blocked when migrating from -proposed to release because missing build on i386, but the i386 package (ukui-menu=1.1.12-1) is migrate from eoan to focal, how to deal with this situation? Thanks!
<xnox> mwhudson:  i think i actually have the right permissions to do that.
<xnox> mwhudson:  but after initial training, it might be a while for me to dig up the right hostnames to ssh into
<xnox> mwhudson:  what specifically are you after?
<mwhudson> xnox: do you have any way of deriving what is causing https://autopkgtest.ubuntu.com/running#pkg-docker.io to hang?
<mwhudson> xnox: it doesn't hang when i run it locally :(
<xnox> le sigh
<xnox> for that one may need to ssh all the way into the guest os, and i'm not sure i've done that, I only got to the queus and workers.
<xnox> it should be all local, cause it is importing a tarball and running it.
<mwhudson> actually i think it's possible you need to launch a job in a special way to allow a human to log into it, i forget
<xnox> unless dockerd is dead, or hung up, with a new kernel....
<mwhudson> xnox: it's triggered by the new containerd
<xnox> that also sounds like something familear
<mwhudson> (in focal-proposed)
<xnox> once it times out and fails, there should be a log right. i wonder if things are not happy with new kernel, new systmed, new apparmor and the like with the new containerd.
<xnox> plus i thought debian has broken networking
 * xnox wonders if ubuntu true test would just work
<xnox> although networking stuff should have been fixed by now
<xnox> horum
<xnox> i'm gonna finish my mint tea and go to bed =)
<mwhudson> xnox: nothing in logs iirc but maybe i should check an old failure indeed
<mwhudson> xnox: good night
<mwhudson> no nothing useful in artifacts
<mwhudson> xnox: i want to talk to you about vtoc tomorrow :)
-queuebot:#ubuntu-release- New: accepted gitless [amd64] (focal-proposed) [0.8.8-2]
<handsome_feng> Sorry, I got it, It's because it migrate from python to qt, and the architecture changes from all to any.
<wxl> handsome_feng: p.s. kylin's looking good in qt :)
<handsome_feng> wxl, Thanks! :)
<handsome_feng> And anyone know how to deal with this situation? I didn't find the document. :(
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-418 [amd64] (focal-proposed/multiverse) [418.116.00-3] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-418 [ppc64el] (focal-proposed/multiverse) [418.116.00-3] (no packageset)
<infinity> handsome_feng: Fixing ukui-menu (and panel appears to have the same issue).
<handsome_feng> infinity: Thanks!
-queuebot:#ubuntu-release- New binary: cinnamon-control-center [s390x] (focal-proposed/universe) [4.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cinnamon-control-center [ppc64el] (focal-proposed/universe) [4.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cinnamon-control-center [amd64] (focal-proposed/universe) [4.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cinnamon-control-center [arm64] (focal-proposed/universe) [4.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cinnamon-control-center [armhf] (focal-proposed/universe) [4.4.0-2] (no packageset)
<RAOF> So, now that Mir builds and passes it's !i386 autopkgtests, the thing try do is to delete the stale i386 binaries and everything is hunky-dory, right?
<doko> RAOF: did you you schedule the rebuilds for the soname change?
-queuebot:#ubuntu-release- New: accepted cinnamon-control-center [amd64] (focal-proposed) [4.4.0-2]
-queuebot:#ubuntu-release- New: accepted cinnamon-control-center [armhf] (focal-proposed) [4.4.0-2]
-queuebot:#ubuntu-release- New: accepted cinnamon-control-center [s390x] (focal-proposed) [4.4.0-2]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-418 [ppc64el] (focal-proposed) [418.116.00-3]
-queuebot:#ubuntu-release- New: accepted cinnamon-control-center [arm64] (focal-proposed) [4.4.0-2]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-418 [amd64] (focal-proposed) [418.116.00-3]
-queuebot:#ubuntu-release- New: accepted cinnamon-control-center [ppc64el] (focal-proposed) [4.4.0-2]
<RAOF> doko: To my knowledge there are no rdepends of Mir-built binaries (at present)
<RAOF> (At least, ones that are not built from the Mir source package)
-queuebot:#ubuntu-release- New binary: icu [s390x] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [i386] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [amd64] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [arm64] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [armhf] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
<locutus_> mwhudson, hello, I did sync python-traits, not sure but flaky tests seems to be not flaky anymore?
<locutus_> it built fine on first attempt
<mwhudson> locutus_: i don't remember that package i'm afraid
<mwhudson> i guess it's s good thing it's building :)
<tseliot> hello admins, I don't think nvidia-graphics-drivers-tesla-418 should have been synced, since we don't sync nvidia drivers from Debian
<tseliot> apw ^^
<tseliot> also sil2100 ^
<rbalint> sil2100, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378651 for systemd?
<apw> tseliot, i'll pull it, and that should also cause it to be blacklisted
<tseliot> apw, thanks, I think this one should go with it too https://launchpad.net/ubuntu/+source/nvidia-settings-tesla-418
<apw> tseliot, yeah ... both done
<tseliot> apw, thanks again
<cpaelzer> hiho, why is wal2json in update_excuses complaining about "missing build on armhf: postgresql-12-wal2json (from 2.0-1)"
<cpaelzer> the whole point of 2.0-2 was to drop armhf and i386
<cpaelzer> please do not that is misses the "2.0-1" binary
<cpaelzer> but this is for 2.0-2
<cpaelzer> or it misses the armhf binary "coming from 2.0-1"
<cpaelzer> but never the less - the current 2.0-2 doesn't want to have the armhf/i386 binaries
<cpaelzer> anything I can do to resolve that and get it moving again?
<cjwatson> Because 2.0-1 was built on armhf in focal-proposed and not migrated, and proposed-migration doesn't automatically handle that case
<cjwatson> I'll remove it by hand
<cpaelzer> Full discplaimer: in a few days hopefulyl there will be a 2.1-1 which will re-add armhf/i386 but I'd prefer not to rely on that
<cpaelzer> cjwatson: ah so it really is because 2.0-1 had armhf and it is now missing
<cpaelzer> thanks cjwatson
<cjwatson> done
<cpaelzer> great, checking back later how migration goes on then
-queuebot:#ubuntu-release- Unapproved: shim-signed (eoan-proposed/main) [1.39.1 => 1.41] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (eoan-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.41] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.5 => 1.41] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
<juliank> xnox: ^ shims for everyone :)
<juliank> Not sure how this is going to work SRU wise, as we don't have an SRU bug number
<juliank> last one did not have one either, though
<xnox> juliank:  blame the guy who quit! =)
<juliank> We can reuse my bug, and tag it update-excuses maybe?
<juliank> idk
<juliank> certainly we can tag it block-proposed-{xenial,bionic,eoan}
<juliank> idk
<xnox> oooh update-excuse yeah
 * xnox ponders if update-excuse tag should be renamed to udpate-excuses
 * RikMills wonders who decided that a test error should show a red grinning face emoji
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1071.81] (kernel)
<infinity> RikMills: I believe the "design" (I use that term loosely) of most of that UI was pitti.
<rbalint> sil2100, could you please drop current ec2-instance-connect srus from from the unapproved queue? I'm about to upload a new set instead
<juliank> hmm should I only have copied shim, and not shim-signed?
 * juliank confused
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-release/partner) [8.0.6.0-0ubuntu1 => 8.0.6.5-0ubuntu1] (no packageset) (sync)
<juliank> or should I have used proper backport SRUs for shim-signed, so that we get an SRU bug in there?
<juliank> wiki page just said copy binaries, but shim-signed seems to have been uploaded with version per release
<apw> juliank, if i am remembering correctly (and that is questionable) we have switched things like enforcement at different times which might have necessitated skew
<juliank> Hmm
<juliank> I think those should be hardcoded in the binaries, and they're the same
<juliank> but surrounding might be different
<juliank> e.g. update-secureboot-policy
<juliank> someone should probably reject the shim-signed uploads
<juliank> and then they need redoing
<juliank> Well, eoan probably nobody cares
<juliank> ah we do
<juliank> Yup gotta redo those
<apw> juliank, so reject the lot, or just -signed
<juliank> apw: just signed is fine, if you reject all, I could copy the unsigned ones back, though, it doesn't really matter
<apw> juliank, ack
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (bionic-proposed) [1.41]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (eoan-proposed) [1.41]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1071.81]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (xenial-proposed) [1.41]
<apw> juliank, ^
<juliank> thanks, apw
-queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (eoan-proposed) [0.102.1+dfsg-0ubuntu0.19.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (bionic-proposed) [0.102.1+dfsg-0ubuntu0.18.04.3]
<slashd> Big thanks sil2100 ^
-queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (xenial-proposed) [0.102.1+dfsg-0ubuntu0.16.04.3]
<sil2100> yw!
<bashfulrobot> infinity: I'm just curious. Are you by chance aware as to when the LTS applications have to be in by?
-queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (bionic-proposed) [1.1.12+dfsg1-0ubuntu2~18.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (eoan-proposed) [1.1.12+dfsg1-0ubuntu2~19.10.0]
-queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (xenial-proposed) [1.1.12+dfsg1-0ubuntu2~16.04.0]
<sil2100> vorlon: hey! Looking at the xenial queue, I see a new ibm-java80 for partner, but the target destination seems to be the Release pocket - guess when I accept it, it will bypass partner proposed, right?
-queuebot:#ubuntu-release- New source: python-gffutils (focal-proposed/primary) [0.10.1-1ubuntu1]
<vorlon> sil2100_: yeah, if it's targeted to the release pocket, that's the case
<vorlon> dannf: ^^
<dannf> vorlon, sil2100_ ah, sorry - probably me failing at trying to use copy-package again. should i retry w/ --to-suite xenial-proposed?
<vorlon> dannf: yes please :-)
<dannf> vorlon: ok - that looks better.
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.6.0-0ubuntu1 => 8.0.6.5-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.37~18.04.5] (core)
<vorlon> sil2100_: ^^ if you're doing reviews, this is a one-liner fix for a regression in the previous -proposed upload
<sil2100_> vorlon: on it o/
<sil2100_> vorlon: is this also fixing the previous issue? Since the previous LP bug got lost in the .changes, probably needs a reupload with -v
<vorlon> sil2100_: I can do that
<vorlon> plz reject
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.37~18.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.5]
<vorlon> rbalint, xnox: should LP: #1860432 be wontfix for systemd?  sounds like juju is going to change their behavior
<ubot5> Launchpad bug 1860432 in systemd (Ubuntu Focal) "juju agent fails to start on focal " [Undecided,Confirmed] https://launchpad.net/bugs/1860432
<xnox> i still wanted to at least file an upstream issue about it
<doko> so we still have a lot of b-d's on python and python-dev, which showed up in NBS a while ago. but not anymore. why not?
<vorlon> doko: because python and python-dev are not NBS because they have been removed?
<vorlon> they were uninstallable, so there was no reason in terms of archive consistency to keep them around in the release pocket
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [sync] (xenial-proposed) [8.0.6.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ibm-java80 [sync] (xenial-release) [8.0.6.5-0ubuntu1]
<doko> ok, then I assume we need to setup a transition tracker to point out the remaining ones
-queuebot:#ubuntu-release- New binary: icu [amd64] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [s390x] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [i386] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [armhf] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [arm64] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
<mwhudson> vorlon: ok https://autopkgtest.ubuntu.com/running#pkg-docker.io is hanging, if you could log in and run ps / lsof / strace any likely looking things / etc that would be great
<ddstreet> infinity i see you're listed in the sru rotation for today, though i'm not sure if that's still accurate, but if it is could you release qemu for b/e and network-manager for e
<vorlon> mwhudson: ps: https://paste.ubuntu.com/p/Yp84qQWhp2/
<vorlon> mwhudson: docker ps: https://paste.ubuntu.com/p/48jhgHGY7s/
<vorlon> mwhudson: lsof/strace on the 'docker run': https://paste.ubuntu.com/p/tTVWNJ79H9/
<vorlon> mwhudson: a second 'docker run' also hangs
<mwhudson> vorlon: can you strace the containerd-shim process?
<mwhudson> vorlon: also lsof
<mwhudson> vorlon: ideally before the test times out :)
<vorlon> mwhudson: there are 2 containerd-shim processes, do you know if I should be looking at parent or child?
<mwhudson> vorlon: i only see one in your first ps listing, is that because you ran docker run again?
<vorlon> oh, maybe?
<mwhudson> https://paste.ubuntu.com/p/Yp84qQWhp2/ only has 8092
<vorlon> right, it's not parent/child
<mwhudson> aiui docker run talks to dockerd talks to containerd
<vorlon> mwhudson: https://paste.ubuntu.com/p/bJ4CKfS6tS/
<vorlon> the thread eventually woke up again, but it's just more futex/nanosleep nonsense
<mwhudson> yeah that's doing a whole lot of nothing isn't it
<mwhudson> i wonder if there's any way to see what the eventpoll things are
<mwhudson> yeah i definitely think that containerd-shim should have exited
<mwhudson> biab
<mwhudson> vorlon: i don't suppose it'll reveal much but "ls -l /var/lib/containerd/io.containerd.runtime.v1.linux/moby/c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a/" ?
<mwhudson> vorlon: and maybe ls -l /run/docker/containerd/
<mwhudson> vorlon: also can you gdb -p to a containerd-shim and 'thread apply all bt' or whatever that command is?
<mwhudson> hm might need to install the ddeb for that to be at all useful :(
<vorlon> mwhudson: $ sudo ls -l /var/lib/containerd/io.containerd.runtime.v1.linux/moby/c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a/
<vorlon> total 0
<vorlon> prwx------ 1 root root 0 Feb 10 21:05 shim.stderr.log
<vorlon> prwx------ 1 root root 0 Feb 10 21:05 shim.stdout.log
<vorlon> $ sudo ls -l /run/docker/containerd/
<vorlon> total 0
<vorlon> drwxr-xr-x 2 root root 80 Feb 10 21:05 c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a
<vorlon> drwxr-xr-x 2 root root 80 Feb 10 21:50 f8d72d17248ce5eb41b87f63a63c7507332bee28f7bee0214a79e3f60c09cff7
<mwhudson> hm no we don't strip go things still
<mwhudson> hm no apparently we do but there is no ddeb on https://launchpad.net/ubuntu/+source/containerd/1.3.1-0ubuntu1/+build/18193736 ?
<vorlon> heh oops
<mwhudson> how did we manage that
<vorlon> ask the go maintainers
<mwhudson> yeah unfortunately that's me
<vorlon> mwhudson: yeah, a whole lot of No symbol table info
<mwhudson> ah upstream Makefile
<mwhudson> ifndef GODEBUG
<mwhudson>         EXTRA_LDFLAGS += -s -w
<mwhudson> ffffffffffffuuuuuuuuuuuu
<mwhudson> oh heh i have containerd 1.3.2 in git locally
<vorlon> I do not think I want to define a God EBUG
<mwhudson> oh wait maybe we want this fix https://github.com/containerd/containerd/pull/3857
<mwhudson> so maybe if i just upload things will start working by magic
<gitbot> containerd issue (Pull request) 3857 in containerd "Fix container pid race condition." [Cherry-Pick/1.3.X, Cherry-Picked/1.3.X, Priority/P0, Closed]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.7-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.7-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.7-3]
-queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [s390x] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [amd64] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [ppc64el] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
#ubuntu-release 2020-02-11
<xnox> vorlon:  https://people.canonical.com/~ubuntu-archive/transitions/html/auto-assimp.html as per that tracker please remove decruft assimp on i386, no longer in the whitelist and wants to migrate
-queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [armhf] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [arm64] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- New: accepted icu [amd64] (focal-proposed) [65.1-1]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (focal-proposed) [65.1-1]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (focal-proposed) [65.1-1]
-queuebot:#ubuntu-release- New: accepted qtlocation-opensource-src [arm64] (focal-proposed) [5.12.5+dfsg-5]
-queuebot:#ubuntu-release- New: accepted qtlocation-opensource-src [ppc64el] (focal-proposed) [5.12.5+dfsg-5]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (focal-proposed) [65.1-1]
-queuebot:#ubuntu-release- New: accepted qtlocation-opensource-src [amd64] (focal-proposed) [5.12.5+dfsg-5]
-queuebot:#ubuntu-release- New: accepted qtlocation-opensource-src [s390x] (focal-proposed) [5.12.5+dfsg-5]
-queuebot:#ubuntu-release- New: accepted icu [i386] (focal-proposed) [65.1-1]
-queuebot:#ubuntu-release- New: accepted qtlocation-opensource-src [armhf] (focal-proposed) [5.12.5+dfsg-5]
<vorlon> xnox: I think your tracker is wrong; there are no i386 binaries from assimp source in focal
<vorlon> xnox: and the blocker for assimp migration per update_output is rviz
<vorlon> xnox: which depends on python3-defaults, so
<xnox> vorlon:  right, so python-pyassimp is bad and there is no new built on i386, hence it is getting confused.
<xnox> so i should really fix python3-defaults
<xnox> vorlon:  sagemath / sagetex were removed in testing because sagemath is rc buggy.
<xnox> vorlon:  can we remove it too?
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.10 => 2.20.9-0ubuntu7.11] (core)
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu8.3 => 2.20.11-0ubuntu8.4] (core)
-queuebot:#ubuntu-release- New binary: libmysofa [amd64] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libmysofa [s390x] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libmysofa [i386] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libmysofa [ppc64el] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libmysofa [arm64] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libmysofa [armhf] (focal-proposed/universe) [1.0~dfsg0-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tupi [s390x] (focal-proposed/universe) [0.2+git08-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tupi [ppc64el] (focal-proposed/universe) [0.2+git08-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tupi [amd64] (focal-proposed/universe) [0.2+git08-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tupi [arm64] (focal-proposed/universe) [0.2+git08-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tupi [armhf] (focal-proposed/universe) [0.2+git08-2] (no packageset)
<vorlon> xnox: why does sagemath not show up on https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/rcbuggy-problem-packages.html as something we should remove?
<RAOF> Just to double-check: the way to resolve the Mir i386 autopkgtest failure is to remove the i386 binaries, right? They're not on the whitelist.
<vorlon> RAOF: the way to resolve the mir i386 autopkgtest failure is to fix my spelling of 'badtest' as 'badetst'
<RAOF> Heh.
<vorlon> xnox: so the reason it's not on the rcbuggy list is that sagemath has no RC bugs filed against it in Debian, so -EMOREINFO
-queuebot:#ubuntu-release- New: accepted libmysofa [amd64] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [armhf] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [ppc64el] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted python-gffutils [source] (focal-proposed) [0.10.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted tupi [arm64] (focal-proposed) [0.2+git08-2]
-queuebot:#ubuntu-release- New: accepted tupi [ppc64el] (focal-proposed) [0.2+git08-2]
-queuebot:#ubuntu-release- New: accepted libmysofa [arm64] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [s390x] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted tupi [armhf] (focal-proposed) [0.2+git08-2]
-queuebot:#ubuntu-release- New: accepted libmysofa [i386] (focal-proposed) [1.0~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted tupi [s390x] (focal-proposed) [0.2+git08-2]
-queuebot:#ubuntu-release- New: accepted tupi [amd64] (focal-proposed) [0.2+git08-2]
-queuebot:#ubuntu-release- New binary: python-gffutils [amd64] (focal-proposed/none) [0.10.1-1ubuntu1] (no packageset)
<handsome_feng> Hi, release team, If Kylin wants to release a ARM version for 20.04, dose Ubuntu platform support the creation of arm image? Or should we make the image ourselves?
<cpaelzer> cjwatson: hiho, you said you'd free wal2json in proposed but it is still stuck. I think it needs "one more" action
<cpaelzer> yesterday we talked about it showing up in update_excuses missing the build of binaries of the never-migrated 2.0-1
<cpaelzer> it show up still, but with a slight change, now it reports
<cpaelzer> missing build on armhf: postgresql-11-wal2json (from 1.0-5ubuntu1)
<cpaelzer> which is the former version that is in focal-release
<cpaelzer> does that need the same action by you or do we now need something else?
-queuebot:#ubuntu-release- New: accepted python-gffutils [amd64] (focal-proposed) [0.10.1-1ubuntu1]
<mwhudson> vorlon: so the next version of containerd passed tests, i'll read the upstream changelog first next time, sorry for wasting your time!
-queuebot:#ubuntu-release- Unapproved: spamassassin (bionic-proposed/main) [3.4.2-0ubuntu0.18.04.3 => 3.4.2-0ubuntu0.18.04.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: spamassassin (xenial-proposed/main) [3.4.2-0ubuntu0.16.04.3 => 3.4.2-0ubuntu0.16.04.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: spamassassin (eoan-proposed/main) [3.4.2-1ubuntu0.19.10.2 => 3.4.2-1ubuntu0.19.10.3] (ubuntu-server)
<cjwatson> cpaelzer__: ah yeah I guess, but looks like this has been superseded by 2.1-1 arriving and building on armhf
<cpaelzer__> oh it appeared now
<cpaelzer__> so the new version has surpassed resolving the old situation
<cpaelzer__> let me check if the old binary packages that are BS now are correctly gone to really call it done
<cjwatson> cpaelzer: (a) this is not really a thing you need to check on (b) I just removed them
<cpaelzer> thanks cjwatson for helping on this
<cpaelzer> I think I can now finally "activate" the remaining removal request for PG-11
<cpaelzer> cjwatson: which would be https://bugs.launchpad.net/ubuntu/+source/pglogical/+bug/1862601
<ubot5> Ubuntu bug 1862601 in postgresql-11 (Ubuntu) "[Remove] Please remove postgresql-11 from Focal" [High,Triaged]
<cpaelzer> cjwatson: do you have the time to consider and process that removal or should we keep it open until another AA has time for it?
<cjwatson> cpaelzer: I don't, sorry
-queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (bionic-proposed/universe) [1.1.12+dfsg1-0ubuntu1~18.04.0 => 1.1.12+dfsg1-0ubuntu3~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (xenial-proposed/universe) [1.1.12+dfsg1-0ubuntu1~16.04.0 => 1.1.12+dfsg1-0ubuntu3~16.04.0] (no packageset)
<cpaelzer> np, up for any AA then
-queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (eoan-proposed/universe) [1.1.12+dfsg1-0ubuntu1~19.10.0 => 1.1.12+dfsg1-0ubuntu3~19.10.0] (no packageset)
<mitya57> Hi! qtlocation-opensource-src fails to migrate because âmissing build on i386â. However it now has new build-dependencies which are not in i386 whitelist:
<mitya57> https://salsa.debian.org/qt-kde-team/qt/qtlocation/commit/a7ef4609bb54ee82
<mitya57> Please either add them to whitelist, or remove qtlocation.
<LocutusOfBorg> apw, is it possible to kick eviacam out? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950545
<ubot5> Debian bug 950545 in src:eviacam "FTBFS against opencv 4.2.0" [Serious,Open]
<apw> LocutusOfBorg, sorry i don't have a chance to look right now
<ddstreet> sil2100 i know it's not your sru day, but any chance you have a minute to release qemu for b/e, and network-manager for e?
-queuebot:#ubuntu-release- New binary: ubuntu-keyring [amd64] (focal-proposed/main) [2020.02.11.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1032.34] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1031.32] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1054.58] (kernel)
-queuebot:#ubuntu-release- New binary: polymake [s390x] (focal-proposed/universe) [4.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [amd64] (focal-proposed/universe) [4.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ubuntu-keyring [amd64] (focal-proposed) [2020.02.11.1]
-queuebot:#ubuntu-release- New binary: polymake [ppc64el] (focal-proposed/universe) [4.0-2ubuntu1] (no packageset)
<juliank> so component-mismatches shows apport-gtk Depends terminator, when it actually Depends on x-terminal-emulator
<juliank> something is off there
<cjwatson> If it has an unadorned dependency on a pure virtual package, then the results are not quite random but can be hard to distinguish from it
<cjwatson> It'll depend on the expansion of other "inner" seeds with respect to whatever seed's expansion contains apport-gtk
<cjwatson> Explicitly seeding a particular provider in the right place usually works around this sort of thing
<juliank> To be fair, apport-gtk should probably depends on gnome-terminal | x-terminal-emulator I guess
<cjwatson> It used to only Suggests: x-terminal-emulator
<cjwatson> So it wouldn't have mattered then
<juliank> ack
<juliank> just was very confused
<cjwatson> https://git.launchpad.net/germinate/tree/germinate/germinator.py#n1322 is more or less the relevant logic, if you love pain enough to want to try to follow it
<cjwatson> (who am I kidding, you maintain apt)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1054.58]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1032.34]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1031.32]
<juliank> cjwatson: that's lovely code, it's not pain
<juliank> I can understand it and fix it if it's broken
<juliank> can't say the same thing about apt's solver
<juliank> That said, I use my own germinate rewrite
<juliank> with less features
<juliank> Like it just is dumb and copies lines into shlibs
<cjwatson> oh good, I like more people who can understand germinate
<cjwatson> but yes, not having a scoring algorithm makes it easier to understand
<cjwatson> OTOH its specification, such as it is, means that any case where it produces different results from apt is probably necessarily a bug.  So there's that
<juliank> I need to get back to writing a new apt solver based on real math
<juliank> aka reusing general-purpose solvers like z3 (SAT) or clasp (ASP) for package solving
-queuebot:#ubuntu-release- New binary: polymake [armhf] (focal-proposed/universe) [4.0-2ubuntu1] (no packageset)
<LocutusOfBorg> doko, what do you think about kicking out mapnik 3.0.22+ds1-1build3 from focal, copy back mapnik 3.0.22+ds1-1build2 and let the transition move a little bit further
<LocutusOfBorg> wecan copy-back the build3 later
<doko> didn't look, and I'm afk in a few minutes
<LocutusOfBorg> maybe vorlon ^^ I'm trying to let gdal go in release
<LocutusOfBorg> with python3-defaults testsuites fixed, we should be mostly ready
<rbalint> vorlon, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378651  for systemd? i'm almost ready to land  244.2-1ubuntu1
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200114.1-0ubuntu0.18.04.1 => 1:20200211.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20191210.1-0ubuntu0.16.04.2 => 1:20200211.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200114.1-0ubuntu0.19.10.1 => 1:20200211.1-0ubuntu0.19.10.1] (no packageset)
<vorlon> rbalint: done, thanks
<RikMills> vorlon: when convenient, could you add libksysguard to the i386 badtest list please
<vorlon> RikMills: done
<RikMills> thanks!
<vorlon> LocutusOfBorg: mapnik> done
-queuebot:#ubuntu-release- New binary: opensurgsim [s390x] (focal-proposed/universe) [0.7.0-9] (no packageset)
-queuebot:#ubuntu-release- New binary: opensurgsim [ppc64el] (focal-proposed/universe) [0.7.0-9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20200211.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200211.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200211.1-0ubuntu0.16.04.1]
<bdmurray> sil2100: Could you review apport for bionic and eoan? bug 1847967
<ubot5> bug 1847967 in apport (Ubuntu Eoan) "oem kernel packages treated differently from generic kernel ones" [Undecided,In progress] https://launchpad.net/bugs/1847967
-queuebot:#ubuntu-release- New binary: opensurgsim [amd64] (focal-proposed/universe) [0.7.0-9] (no packageset)
<sil2100> bdmurray: sure, just need to jump out to the garage real quick first
<sil2100> (not for SRU tools though)
<sil2100> (I have those at home)
-queuebot:#ubuntu-release- New binary: polymake [arm64] (focal-proposed/universe) [4.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensurgsim [arm64] (focal-proposed/universe) [0.7.0-9] (no packageset)
-queuebot:#ubuntu-release- New binary: opensurgsim [armhf] (focal-proposed/universe) [0.7.0-9] (no packageset)
<sil2100> bdmurray: so there is already an ADT-fix-only apport in -proposed, I guess it would be good to have it included in the .changes?
<sil2100> So that we can close both bugs? Or should we just consider it fixed?
<sil2100> I guess this part of the SRU block-proposed process still needs to be discussed
<bdmurray> sil2100: ah right, I grabbed it from -proposed but forget about the .changes
<bdmurray> that's an easy reupload
<sil2100> Thanks o/
<bdmurray> sil2100: uploaded
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu8.3 => 2.20.11-0ubuntu8.4] (core)
<sil2100> On it
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.10 => 2.20.9-0ubuntu7.11] (core)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (bionic-proposed) [2.20.9-0ubuntu7.11]
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (eoan-proposed) [2.20.11-0ubuntu8.4]
<sil2100> bdmurray: what do you think about this? https://code.launchpad.net/~sil2100/ubuntu-archive-tools/remove-block-proposed-on-sru/+merge/378917
<sil2100> Since I always have to clear out the block-proposed tags by hand, once already I forgot about it
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.11]
<apw> sil2100, isn't that kind of a valid choice though asking for an SRU and blocking it in -proposed
<vorlon> apw: I guess the point is that if you're accepting a new SRU over one already in -proposed, the block-proposed tags on the bugs for the previous SRU must no longer apply?
<vorlon> but for bugs in the changes of the /new/ SRU we certainly shouldn't be clearing
<apw> vorlon, ahh yes i see your subtlty, if it is doing what you are saying it likely is sane
<vorlon> I'm not sure that is what it's doing
<vorlon> :)
<apw> me either :)
<locutus__> please vorlon htslib NBS in s390x (removed) hint: grabix/all/s390x htslib/all/s390x samtools/all/s390x vcftools/all/s390x
<locutus__> this makes the gdal/foo transition move forward
<vorlon> doko: ^^ your removal of htslib/s390x rdeps was incomplete, grabix depends on tabix (source:htslib)
-queuebot:#ubuntu-release- New binary: libdeflate [amd64] (focal-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdeflate [s390x] (focal-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdeflate [ppc64el] (focal-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pbsuite [amd64] (focal-proposed/universe) [15.8.24+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libdeflate [armhf] (focal-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdeflate [arm64] (focal-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hisat2 [amd64] (focal-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [s390x] (focal-proposed/universe) [0.16.3-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [amd64] (focal-proposed/universe) [0.16.3-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: actor-framework [ppc64el] (focal-proposed/universe) [0.16.3-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1013.14~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1013.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1013.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1013.14~18.04.1]
-queuebot:#ubuntu-release- New binary: actor-framework [armhf] (focal-proposed/universe) [0.16.3-0.3] (no packageset)
<doko> vorlon: thanks, the s390x test failures triggered by htslib should be ignored then
<vorlon> doko: yes, I've added the hints per locutusofborg's request above, and noticed the missed removal while doing due diligence on them
-queuebot:#ubuntu-release- New: accepted hisat2 [amd64] (focal-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted pbsuite [amd64] (focal-proposed) [15.8.24+dfsg-4]
<vorlon> I've also added a skiptest hint for python3-defaults now, I don't think we should wait for libreoffice/armhf test results which will tell us nothing new about the quality of python3 before getting information about the next round of blockers
-queuebot:#ubuntu-release- New: accepted libdeflate [amd64] (focal-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted libdeflate [armhf] (focal-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted libdeflate [s390x] (focal-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted libdeflate [arm64] (focal-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted libdeflate [ppc64el] (focal-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted polymake [amd64] (focal-proposed) [4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted polymake [armhf] (focal-proposed) [4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted polymake [s390x] (focal-proposed) [4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted polymake [arm64] (focal-proposed) [4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted polymake [ppc64el] (focal-proposed) [4.0-2ubuntu1]
<vorlon> xnox: what should we do with cegui-mk2?
<vorlon> xnox: looks like it needs fixes for symbols files?
-queuebot:#ubuntu-release- New: accepted opensurgsim [amd64] (focal-proposed) [0.7.0-9]
-queuebot:#ubuntu-release- New: accepted opensurgsim [armhf] (focal-proposed) [0.7.0-9]
-queuebot:#ubuntu-release- New: accepted opensurgsim [s390x] (focal-proposed) [0.7.0-9]
-queuebot:#ubuntu-release- New: accepted opensurgsim [arm64] (focal-proposed) [0.7.0-9]
-queuebot:#ubuntu-release- New: accepted opensurgsim [ppc64el] (focal-proposed) [0.7.0-9]
<xnox> vorlon:  i had a cunning plan to just upload with new symbols => because ember switched from deb to snap and there are no other reverse depends
<vorlon> >_<
<xnox> vorlon:  we should be renaming it, as it is abi break (it re-exports symbols that changed, because boost templates changed)
<vorlon> xnox: reexports but doesn't expose in headers?
<xnox> vorlon:  are you happy for me to rename the binary package to b171 for boost171?
<xnox> correct
<vorlon> if these are just templates that nothing will ever compile against, then I don't care about a rename
<xnox> but like apps will fail to load....
<vorlon> let upstream fix it properly by using a linker script to hide symbols
<xnox> as far as i understand
<vorlon> why will apps fail to load?
<xnox> good question, sometimes in the past ember did but maybe something else broke in the abi
<xnox> at the moment i only see changes in boosty sybmols
<xnox> i'll just upload that
<xnox> is it blocking things?
<vorlon> xnox: yes, it's one of the last uninstallables for the python3-defaults transition
-queuebot:#ubuntu-release- New binary: actor-framework [arm64] (focal-proposed/universe) [0.16.3-0.3] (no packageset)
<vorlon> xnox: but if a reupload is going to entangle with boost1.71, I'd rather rollback right now
<vorlon> to 0.8.7-5ubuntu1 if that's an option
<vorlon> xnox: let me roll back, and you can upload your change tomorrow
<doko> libreoffice-gtk still depends on libreoffice-gtk2 which isn't built anymore
<xnox> untangle yes
#ubuntu-release 2020-02-12
<vorlon> doko: yet nothing else depends on libreoffice-gtk, so we could temporarily let that be uninstallable
<doko> sagemath isn't going to be fixed soonish, so better remove it. however reverse-depends isn't working right now
<doko> so the last remaining would be rdkit, currently ftbfs
-queuebot:#ubuntu-release- New binary: vg [amd64] (focal-proposed/universe) [1.21.0+ds2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted actor-framework [amd64] (focal-proposed) [0.16.3-0.3]
-queuebot:#ubuntu-release- New: accepted actor-framework [armhf] (focal-proposed) [0.16.3-0.3]
-queuebot:#ubuntu-release- New: accepted actor-framework [s390x] (focal-proposed) [0.16.3-0.3]
-queuebot:#ubuntu-release- New: accepted actor-framework [arm64] (focal-proposed) [0.16.3-0.3]
-queuebot:#ubuntu-release- New: accepted vg [amd64] (focal-proposed) [1.21.0+ds2-1]
-queuebot:#ubuntu-release- New: accepted actor-framework [ppc64el] (focal-proposed) [0.16.3-0.3]
<xnox> vorlon:  doko: do you want rdkit against boost1.67 or boost1.71?
<vorlon> xnox: rdkit also boost1.67
<doko> xnox: no opinion
<vorlon> doko: "do you want rdkit to hold up python3-defaults until boost1.71 is ready" :
<vorlon> :)
<doko> it's connected anyway
<vorlon> doko: not that I see from https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt; only cegui-mk2 and rdkit both of which are ftbfs in -proposed with boost1.71 currently, so I'm breaking that connection
<xnox> vorlon:  rdkit with boost1.67 incoming
 * xnox doing test build
<vorlon> xnox: noooo
<vorlon> xnox: I was rolling that back also
<xnox> vorlon:  ok
<vorlon> -2ubuntu1 is good
<xnox> vorlon:  ok, in that case i'll stage it with boost1.71 somewhere
<vorlon> libreoffice/armhf: 4h24m and error
<vorlon> xnox: sounds good
<xnox> also, do we care about libreoffice on armfh?!
<vorlon> I mean
<vorlon> we're building it
<vorlon> I assume that's what all the Mate users are using their rpis for
<xnox> vorlon:  are there things that hold up boost-default or boost1.71 migration in notest? python-defaults?
<vorlon> xnox: evidently not
<vorlon> so get those tests passing :)
<xnox> i'll see what the state of things are tomorrow, but i think there are only individual arch issues left with packages
<xnox> and there are no issues left due to new boost
<xnox> i.e. i think all the ros-* things migrated by now
-queuebot:#ubuntu-release- New binary: htscodecs [amd64] (focal-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: htscodecs [arm64] (focal-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: htscodecs [armhf] (focal-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: htscodecs [ppc64el] (focal-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: micropython [amd64] (focal-proposed/universe) [1.12-1] (no packageset)
<cpaelzer> re-ping looking for an archive admin to resolve https://bugs.launchpad.net/ubuntu/+source/postgresql-11/+bug/1862601 please
<ubot5> Ubuntu bug 1862601 in postgresql-11 (Ubuntu) "[Remove] Please remove postgresql-11 from Focal" [High,Triaged]
-queuebot:#ubuntu-release- New: accepted micropython [amd64] (focal-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted htscodecs [amd64] (focal-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted htscodecs [armhf] (focal-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted htscodecs [arm64] (focal-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted htscodecs [ppc64el] (focal-proposed) [0.5-1]
 * doko curses matplotlib cyclic dependencies
-queuebot:#ubuntu-release- New binary: rust-quick-xml [amd64] (focal-proposed/universe) [0.17.2-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [armhf] (focal-proposed/universe) [0.17.2-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [s390x] (focal-proposed/universe) [0.17.2-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [arm64] (focal-proposed/universe) [0.17.2-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [ppc64el] (focal-proposed/universe) [0.17.2-1] (i386-excludes)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.4] has been marked as ready
-queuebot:#ubuntu-release- New binary: xen [amd64] (focal-proposed/universe) [4.11.3+24-g14b62ab3e5-1ubuntu1] (ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: xen [arm64] (focal-proposed/universe) [4.11.3+24-g14b62ab3e5-1ubuntu1] (ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: xen [armhf] (focal-proposed/universe) [4.11.3+24-g14b62ab3e5-1ubuntu1] (ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New: accepted xen [amd64] (focal-proposed) [4.11.3+24-g14b62ab3e5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [armhf] (focal-proposed) [4.11.3+24-g14b62ab3e5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [arm64] (focal-proposed) [4.11.3+24-g14b62ab3e5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [amd64] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [ppc64el] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [i386] (focal-proposed) [65.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-88.88] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-88.88] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-88.88]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-88.88]
<sil2100> Hello everyone! Just a heads up: I will be releasing 18.04.4 shortly o/
<apw> sil2100, ^5
<Laney> well done sil2100
<ginggs> would someone please 'force-badtest fastqtl/2.184+dfsg-7build2/s390x' ?  htslib is no longer built on s390x
<ginggs> and please kick the mercurial can along? 'force-badtest mercurial/5.2.2-1ubuntu4/arm64'
<LocutusOfBorg> together with fastqtl force-badtest qtltools/1.2+dfsg-2build1/s390x same htslib reason
 * apw has a look
<LocutusOfBorg> thanks for using the new force-test-reset :) I don't yet understand it completely but looks awesome
<apw> LocutusOfBorg, just a reset to 'having never worked'
<apw> so in theory it will just ignore the results until they pass again (which is unlikely)
<LocutusOfBorg> I'm still trying to fix htslib btw :D
<apw> and if you do then that should work too
<LocutusOfBorg> ls htslib*changes |wc -l
<LocutusOfBorg> 24
<LocutusOfBorg> I already uploaded 24 git bisect versions on my ppa, no luck :p
<LocutusOfBorg> not having an s390x machine handy is meh
<LocutusOfBorg> I can test debian, ohhhh
<ginggs> @apw so how is forece-test-reset actually different to force-badtest fastqtl/all/s390x ?
<apw> ginggs, yes, /all/ will let it go bad, bad, bad, fixed, bad
<apw> whereas force-test-reset will let bad, bad, bad, fixed, and go regression on the next bad
<ginggs> ah ok, so the version in force-test-reset means ignore passes before this version?
<apw> basically yes
<apw> it actually says if the mentioned version is a fail consider the global state alwaysfailed not fail
<apw> well thats not quite it, but close enough
<ginggs> apw: thanks
<apw> its applied to all fails <= to the version converting any fails to alwaysfailed
<LocutusOfBorg> nice
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1052.55] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1033.36] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1033.36~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1052.55]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1033.36]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1033.36~16.04.1]
-queuebot:#ubuntu-release- Unapproved: intel-microcode (eoan-proposed/main) [3.20191115.1ubuntu0.19.10.2 => 3.20191115.1ubuntu0.19.10.3] (core)
<ginggs> apw: for the mercurial hint you have 'force-test-reset' the others have 'force-reset-test'
<apw> ginggs, grrr
<Laney> :D
<apw> ginggs, and fixed
<ginggs> apw: ta!
<apw> Laney, why is that not force-resettest given the nameing of the others ...
-queuebot:#ubuntu-release- Unapproved: intel-microcode (bionic-proposed/main) [3.20191115.1ubuntu0.18.04.2 => 3.20191115.1ubuntu0.18.04.3] (ubuntu-desktop, ubuntu-server)
<xnox> Laney:  apw: https://bugs.launchpad.net/ubuntu/+source/gyoto/+bug/1862943 please badtest three results to make boost1.71 to be a candidate, which is entagled with the now "valid candidate" python3-defaults transition of doom
<ubot5> Ubuntu bug 1862943 in yade (Ubuntu) "failing autopkgtests with new boost1.71" [Undecided,New]
<xnox> meanwhile i have uploaded a rebuild of those three packages
<apw> xnox, and you are owning making them work or go away ?
<xnox> apw:  yes, hence the bug report
<apw> xnox, ok force-skiptest applied to boost1.71
-queuebot:#ubuntu-release- New binary: rsyslog [s390x] (focal-proposed/main) [8.2001.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [amd64] (focal-proposed/main) [8.2001.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [ppc64el] (focal-proposed/main) [8.2001.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [arm64] (focal-proposed/main) [8.2001.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [armhf] (focal-proposed/main) [8.2001.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1055.59] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-88.88~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1071.76] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1071.76]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-88.88~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1055.59]
-queuebot:#ubuntu-release- Unapproved: shim-signed (eoan-proposed/main) [1.39.1 => 1.39.2] (core)
-queuebot:#ubuntu-release- New binary: ovn [s390x] (focal-proposed/main) [20.03.0~git20200212.9a4e68ec8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.5 => 1.37~18.04.6] (core)
-queuebot:#ubuntu-release- New binary: ovn [ppc64el] (focal-proposed/main) [20.03.0~git20200212.9a4e68ec8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ovn [amd64] (focal-proposed/main) [20.03.0~git20200212.9a4e68ec8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ovn [armhf] (focal-proposed/main) [20.03.0~git20200212.9a4e68ec8-0ubuntu1] (no packageset)
<juliank> please reject shim-signed 1.37~18.04.6
 * juliank is still learning shim backporting, and missed stuff
-queuebot:#ubuntu-release- New: accepted rsyslog [amd64] (focal-proposed) [8.2001.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [armhf] (focal-proposed) [8.2001.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [s390x] (focal-proposed) [8.2001.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [arm64] (focal-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [ppc64el] (focal-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New: accepted rsyslog [arm64] (focal-proposed) [8.2001.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [amd64] (focal-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [s390x] (focal-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New: accepted rsyslog [ppc64el] (focal-proposed) [8.2001.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [armhf] (focal-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New binary: ovn [arm64] (focal-proposed/main) [20.03.0~git20200212.9a4e68ec8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ovn [amd64] (focal-proposed) [20.03.0~git20200212.9a4e68ec8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ovn [armhf] (focal-proposed) [20.03.0~git20200212.9a4e68ec8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ovn [s390x] (focal-proposed) [20.03.0~git20200212.9a4e68ec8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ovn [arm64] (focal-proposed) [20.03.0~git20200212.9a4e68ec8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ovn [ppc64el] (focal-proposed) [20.03.0~git20200212.9a4e68ec8-0ubuntu1]
<LocutusOfBorg> missing build on s390x: hilive (from 2.0a-3)
<LocutusOfBorg> can anybody please do it? ^^ htslib removed on s390x
<LocutusOfBorg> apw, ^^
<LocutusOfBorg> also, is a force-skiptest a valid use-case for http://autopkgtest.ubuntu.com/packages/m/mir/focal/s390x ?
<LocutusOfBorg> s390x is magically regressed because of one "neutral" and python3-defaults is not candidate anymore
<LocutusOfBorg> meh
<LocutusOfBorg> sagemath is fixed now
<LocutusOfBorg> we should mostly ready for migration
<LocutusOfBorg> maybe if somebody stops autosync....
<vorlon> mir/s390x badtested
<xnox> vorlon:  =( sad
<xnox> vorlon:  but ok
<vorlon> nothing sad
<vorlon> working around britney bugs
<doko> rafaeldtinoco: your pacemaker upload introduces component mismatches, please file MIRs, or git rid off those component mismatches: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<rafaeldtinoco> doko: it was intentional
<rafaeldtinoco> cpaelzer: ^
<rafaeldtinoco> https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/1862947
<ubot5> Ubuntu bug 1862947 in pacemaker (Ubuntu Focal) "crmsh should be taken back to -main" [Medium,In progress]
<rafaeldtinoco> and
<rafaeldtinoco> original mir (re-opened): https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/1205019
<ubot5> Ubuntu bug 1205019 in crmsh (Ubuntu) "[MIR] crmsh" [Critical,In progress]
<doko> rafaeldtinoco: promoted again
<rafaeldtinoco> doko: super nice. thx doko
<doko> xnox: so what's wrong with haskell?
* sil2100 changed the topic of #ubuntu-release to: Released: Bionic 18.04.4, Eoan 19.10 | Archive: Open | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<sil2100> o/
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (focal-proposed/universe) [20.04] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (focal-proposed/main) [1:6.4.0-0ubuntu5] (ubuntu-desktop)
<xnox> doko:  not sure yet
<xnox> is update excuses stuck?
<xnox> i have a package that was built and published 8 hours ago and it is still not in the excuses page
 * xnox reloads
<xnox> ah, force reload helped
<vorlon> anyone know if umockdev/arm* can be magicked to work with new gobject-introspection using the right trigger, or if we're looking at a regression?
<vorlon> xnox: not stuck, but current runs are clocking in at 1h+
<xnox> fun
<xnox> vorlon:  my current plan is to make boost-defaults & gnu-radio valid candidates, which seem to be entangled with the rest
 * vorlon learns that update_output_notest also doesn't care about things not being candidates due to component mismatches (ceph)
<vorlon> xnox: I don't see indications that boost is entangled, but gnuradio yes
<xnox> vorlon:  also boost-defaults now is in components missmatches due to boost1.71
<xnox> vorlon:  have you already promoted more of boost1.71 / boost-defaults packages to main?
<vorlon> xnox: boost-defaults isn't in c-m, boost1.71 is; I'm promoting it right now
<xnox> tah
<vorlon> that was the component-mismatch preventing ceph from being a candidate :)
<xnox> i am confused why transition tracker claims that ghc is not installable
<xnox> is it installable?
<xnox> oh, let me look at the real uninstallable counts
<xnox> rebuild gnss-sdr locally and now it doesn't segfault during autopkgtest; so uploaded a rebuild hopefully it will build & autopkgtest fine, then will retrigger gnuradio with it, and hopefully it should make gnuradio stuff a valid candidate
<xnox> vorlon:  can you please RM hilive from focal-release/s390x ? the build-dependency libhts-dev is removed on s390x, so new hilive cannot be build on s390x and thus doesn't migrate?
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (focal-proposed) [20.04]
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (focal-proposed) [1:6.4.0-0ubuntu5]
<vorlon> xnox: done
<xnox> tah
<xnox> vorlon:  also cannot really run ubuntu-cdimage image because there is no python-launchpadlib, testing running it under python3
<cjwatson> It works fine with py3.
<cjwatson> Note how ./run-tests tests with both if it can.
#ubuntu-release 2020-02-13
<xnox> cool
 * cjwatson looks: I ported most of it in 2012, and a few more bits in 2013/2014
<cjwatson> In fact I think I did the shell-to-Python port with an eye to py3 compat in the first place, and just had to fix a couple of minor mistakes in that plan
<xnox> nice
<xnox> uploaded nlopt which fixes alternative python3 extension name. The default one was renamed correctly, but the alternative pythons were not.
<doko> vorlon: please ignore the missing sagemath/armhf build, not built anymore
<doko> vorlon: is the vim/i386 autopkg test supposed to fail?
<doko> why doesn't assimp show up in update_excuses? v5 is in proposed
<doko> force-synced odil to get it rebuilt with boost1.71. hope that's all to let boost-defaults migrate
<vorlon> doko: the vim/i386 autopkgtest has been passing, I don't know why it started to fail
<vorlon> doko: sagemath doesn't need ignored, it needs the binaries removed from focal-proposed on armhf and s390x (why they're in focal-proposed for a source version that's in the release pocket, I don't know)
<vorlon> doko: (sagemath removals done)
<doko> ta
<vorlon> doko: it looks like we're down to 4 packages (libreoffice, kopanocore, assimp, link-grammar) so I'm going to shut off autosync for the moment just in case
<doko> vorlon: ugh, lo and odil already picked up icu, and I now uploaded to first batch of icu rebuilds
<vorlon> I don't see odil tied to the python3-defaults transition
<vorlon> libreoffice, we could roll back to the previous version and force breaking of the libreoffice-gtk stuff
<vorlon> (but you'd need someone else on the release team to do it, I'm not going to be up late enough to)
<vorlon> I definitely don't think we should wait for icu
<doko> odil is tight to ros
<vorlon> ok, would a rollback be sufficient there also?
<vorlon> I don't see a ros transition, only an assimp one
<doko> let me look, it should up blocking boost-dedaults
<vorlon> doko: so I'll do the libreoffice rollback and then maybe Laney can force break libreoffice-gtk during your day
<doko> vorlon: apparmor/ppc64el needs to be addressed or ignored, triggered by kopanocore
<doko> and kopanocore fails on armhf
<doko> and arm64
<doko> I love failing tests without any output
<RikMills> vorlon: if you have time today, could you add matplotlib to i386 blacklist please?
<LocutusOfBorg> vorlon, I can do link-grammar and kopanocore
<doko> link-grammar is uploaded
<doko> why does this need to stay like this for 5 days?
<LocutusOfBorg> doko, I was busy with some other 20 entangled packages. I spent yesterday fixing something else...
<LocutusOfBorg> btw with update excuses showing ton of stuff, I didn't notice they were broken!
<LocutusOfBorg> I mean, they were blocking
<LocutusOfBorg> (I still don't get what regressed kopanocore and now magically fixed it btw)
-queuebot:#ubuntu-release- Builds: 32 entries have been added, updated or disabled
 * Laney peers in
<Laney> what does force break mean in this context?
<LocutusOfBorg> apparmor ppc64el test should autoheal in a publisher run apparmor/focal/ppc64el because of evice just built on ppc64el
<LocutusOfBorg> vorlon, do you think libextutils-pkgconfig-perl [focal/i386] is elibigle for an hint?
<LocutusOfBorg> I see you also tried it...
<doko> Laney: it's build with the missing libreoffice-gtk2 binary package
<Laney> ah
<Laney> if we had a newer britney there's an allow-uninst hint for this :(
<apw> Laney, sigh
<Laney> doko: ok, so when libreoffice-gtk is the only thing listed we can do that I guess
<Laney> did someone tell the LO people already?
<doko> they are aware, see #u-d
<doko> also gnucash 1:3.8b-1build3 needs to be removed, restored by -1build2
<Laney> oh ok that's what ubuntu5 was fixing
<Laney> yeah, you can do that can't you?
 * Laney can't
<doko> I can remove -build3, will -build2 still be available?
<Laney> copy it back, I think that should work
<Laney> not sure if you have to wait for the removal to publish first
<doko> I'll wait
<apw> they are separate publishing records, so i would think there is no need to wait
<Laney> yeah I'd try it anyway, worst case it doesn't work, best case you save a cycle
 * doko looks up the syntax again for the restore
<doko> copied back
<Laney> zsh: /home/laney/bin/ubuntu-archive-tools/copy-package: bad interpreter: /usr/bin/python: no such file or directory
<Laney> doh
<Laney> so it looks like there's sagemath (ipython -> dask failures), ros-rviz (assimp -> assimp failures) apart from the known ones?
<doko> dask tests are still running, the scikit-learn in -proposed is removed
<doko> assimp is a real issue
<Laney> is the sync needed for the transition or can it be removed?
<Laney> looks like it is
<Laney> or could it be replaced by a rebuild of the version in focal release?
<doko> games-python2-dev still depends on python-pyassimp
<doko> and we have lot of dependencies on the new assimp in -proposed
<Laney> mmmmmmmmmmmeh
<doko> so somebody needs to have a look ...
<Laney> ok I'll hint it, Debian report would be appreciated
<Laney> "it's possible your package is broken on many arches"
<doko> pyassimp.errors.AssimpError: Could not import file!
<doko> trying: /usr/share/assimp/models/invalid/empty.smd
<doko> Error encountered while loading '/usr/share/assimp/models/invalid/empty.smd'
<doko> why are the trying to load invalid files?
<LocutusOfBorg> Laney, ipython is fixed
<Laney> good
<LocutusOfBorg> I mean, with doko fixing scikit sadness
<LocutusOfBorg> doko, TBH, I spent something like two weeks on assimp, reporting reopening reporting reopening debian rc bugs
<LocutusOfBorg> all the tests that fails are new tests, at some point we can just ignore
<LocutusOfBorg> https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/assimp/4032912/log.gz
<doko> LocutusOfBorg: please can you write that in a bug report, and then point the release team to it?
<LocutusOfBorg> pyassimp.errors.AssimpError: Could not import file!
<LocutusOfBorg> ** Loaded 264 models, got 54 assimp errors and 4 other errors
<LocutusOfBorg> Error:Invalid token "ï¿½" expected "{"
<LocutusOfBorg> command2             PASS
<doko> afk now, errand
<LocutusOfBorg> meh
<LocutusOfBorg> doko, http://bugs.debian.org/944742
<ubot5> Debian bug 944742 in src:assimp "assimp: testsuite regression" [Serious,Fixed]
<LocutusOfBorg> I did that
<LocutusOfBorg> many, many times
<LocutusOfBorg> also Debian for some reasons have the same failures with "pass" result
<Laney> I did hint it, this seems like not the best use of time to me
<rbalint> sil2100, could you please review the ec2-instance-connect srus in the unapproved queues?
<LocutusOfBorg> kopanocore green
<LocutusOfBorg> so with gnucash publish and libreoffice builds... migration=?
<LocutusOfBorg> new britney run in 5 minutes
<Laney> let's see now
<sil2100> rbalint: looking o/
 * doko has 220 [ubuntu/focal] messsages in the inbox \o/
<Laney> interesting
<Laney> don't really undetstand how that worked
<Laney> it looked like it failed due to libreoffice-gtk as expected, but then they were all accepted anyway
<doko> but you overrode that?
<Laney> no that happened before my hint
<Laney> I didn't notice that it worked
<Laney> if you look for "final:" in update_output.txt
<Laney> it accepted everything on the basis of an "easy" hint from the auto hinter that looks like it failed
 * Laney is confused
<doko> why did I get these emails?
<Laney> because it did work
<Laney> I just don't know why!
<Laney> perhaps uninstallability trading?
<vorlon> marcustomlinson: I don't think libreoffice 1:6.4.0-0ubuntu6 was needed, 0ubuntu5 had already been built against the new icu and I was going to bring that version back into -proposed now that python3-defaults is through
<doko> vorlon: not on ppc64el
<vorlon> ah ok
<vorlon> marcustomlinson: ^^ then nevermind, all good
<marcustomlinson> :|)
<vorlon> autosyncs reenabled, thanks Laney doko et al for getting that transition through
<Laney> np
<Laney> still unsure how it worked in the end
<Laney> but maybe I should let that be
<vorlon> Laney: ah did you not add a hint? :-) with so many packages migrating and a non-zero number of prior uninstallables, it's possible britney made a trade
<Laney> vorlon: Nope. Trading's the only thing I can think of, but not sure what the situation was like before
<Laney> ð¤·
<vorlon> it was probably a trade that fixed one of the packages doko had made uninstallable recently with removals :)
<Laney> heh
<Laney> someone needs to set infinity loose
 * doko doesn't feel guilty about debian-med removals
<doko> $ python
<doko> Command 'python' not found, but can be installed with:
<doko> sudo apt install python3         # version 3.7.5-1ubuntu1, or
<doko> sudo apt install python          # version 2.7.17-1
<doko> sudo apt install python-minimal  # version 2.7.17-1
<doko> You also have python3 installed, you can run 'python3' instead.
<doko> to be fixed too ...
<vorlon> xnox: reminder that rdkit is on you to fix
<vorlon> xnox: also cegui-mk2 IIRC
<xnox> yeap.
<xnox> i ignored them until after python3-defaults migrates, which it did now
<xnox> taking them
<rbalint> sil2100, how do you like it? :-)
<sil2100> rbalint: uh, my terminal window got lost somewhere and I forgot about it! Sorry, too much going on again ;)
<sil2100> Finding it now
-queuebot:#ubuntu-release- New binary: ibus [amd64] (focal-proposed/main) [1.5.21-5ubuntu1] (desktop-core, i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: blis [s390x] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: blis [ppc64el] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: blis [armhf] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: blis [amd64] (focal-proposed/universe) [0.6.1-2] (no packageset)
<xnox> vorlon:  did you complete the icu uploads? i don't think i see any for virtual provides/depends
<xnox> otherwise i'll do them once i'm back
-queuebot:#ubuntu-release- New binary: blis [arm64] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted blis [amd64] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted blis [armhf] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted blis [s390x] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted blis [arm64] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted blis [ppc64el] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted ibus [amd64] (focal-proposed) [1.5.21-5ubuntu1]
<vorlon> xnox: I ^C'ed because it was wrongly trying to pick up libreoffice, I'm continuing now that there's been a publisher cycle so that I'm not re-uploading all the things I already uploaded
<bdmurray> sil2100: I've update the meta-release files for 18.04.4
<sil2100> bdmurray: thank you o/
<vorlon> doko: why did you remove the gnucash that you uploaded for icu?
<RikMills> how often does the rdepends service update nowadays?
<tumbleweed> twice a day: 7   9,21 * *   *
<vorlon> xnox: bombono-dvd> lol failed rebuild against boost because of python3-incompatible scons, enjoy
<rbalint> sil2100, vorlon could you please merge this for systemd? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/379168
<vorlon> rbalint: done
<RikMills> tumbleweed: thanks!
<locutus_> can I sync ocaml?
<locutus_> doko, your delta seems to be not applicable anymore... :/
<locutus_> after a ton of bothering to remove hint htslib/s390x, I got an upstream fix, and uploaded it back :/
<locutus_> ocaml syncd, lets see what happens
<vorlon> locutus_: that wasn't very long to wait for objections
<vorlon> we're in the middle of rebuilds for the icu transition, might've been nice to let that finish first
<locutus_> actually I asked months ago for ocaml...
<locutus_> and pinged here from time to time, and FFe is approaching...
<locutus_> in any case I don't want to issue rebuilds today or tomorrow
<locutus_> for sure not before icu
<vorlon> yes, but the icu rebuilds are still /in progress/, so ocaml revdeps can get entangled
<vorlon> anyway, we'll deal with that if it happen
<vorlon> s
<locutus_> I wasn't aware of entangling between icu and ocaml...
<locutus_> if you look e.g. here https://release.debian.org/transitions/html/ocaml.html
<locutus_> there is no icu mention
-queuebot:#ubuntu-release- New binary: ocaml [amd64] (focal-proposed/universe) [4.08.1-8] (i386-whitelist, kubuntu)
<vorlon> I wouldn't expect 'icu' to be in the names of the revdeps there
<vorlon> anyway it's possible there's no entanglement
<locutus_> btw I'm already doing the haskell icu part...
<locutus_> something you did ftbfs
<vorlon> well, those were no-change rebuild
<vorlon> s
<locutus_> btw please libextutils-pkgconfig-perl/i386 hint if possible?
<vorlon> locutus_: done
<locutus_> ta
<vorlon> Laney, juliank: fwiw I was trying to launch an adt vm on lgw01 to debug vim/i386 and was hitting memory quota; nova list showed 6 adt-prepare VMs running for 12days+ which I've now nuked
<juliank> Thanks vorlon
<vorlon> Laney, juliank: also, the thing I'm debugging is that vim/i386 autopkgtest failed, then started to pass, now fails again due to wanting to install vim-tiny:i386 and remove vim-tiny:amd64 + ubuntu-minimal.  do you know of anything that would've changed on autopkgtest infra to explain why apt would flip-flop on this?
<juliank> No idea sorry
<sil2100_> rbalint: ok, I got completely side-tracked again
<jdstrand> vorlon: hey, so, iptables 1.8.4-2 is... let's just say problematic
<jdstrand> vorlon: you should see autopkgtests for ufw fail
<sil2100_> rbalint: seeing that vorlon did the previous review, I would anyway opt for you to reach out to him and see if he's okay with the new version now
<sil2100_> rbalint: if not, I can take a look at it on Monday
<jdstrand> vorlon: I tested the patch added to 1.8.4-3 this morning and all ufw tests pass with it. Please merge or cherrypick https://git.netfilter.org/iptables/commit/?id=8e76391096f12212985c401ee83a67990aa27a29
<jdstrand> vorlon: actually, that is only with the nft backend and the ufw autopkgtests don't try both nft and legacy, so the upload will probably make it. but as soon as someone uses iptables-restore-nft, they are in a world of hurt with 1.8.4-2
 * jdstrand makes a note to adjust the autopkgtests to do both
<jdstrand> vorlon: though, 1.8.4-1 drops the /sbin -> /usr/sbin compat symlinks (on fresh installs iirc) so ufw will die there as well
<jdstrand> vorlon: I have a ufw upload read for that, but was waiting for all the upstream fixes to flow into iptables. that happened this morning with 1.8.4-3 (also, check your email if you want to help a maintainer out ;)
<jdstrand> vorlon: if you need me to do the iptables merge with 1.8.4-3, let me know
<vorlon> jdstrand: please go ahead and do the iptables 1.8.4-3 merge, since you know what's up
<RikMills> vorlon: could you please action LP: #1757815
<ubot5> Launchpad bug 1757815 in qt-assistant-compat (Ubuntu) "Please remove from focal archive" [Undecided,New] https://launchpad.net/bugs/1757815
<RikMills> thansk
<RikMills> *thanks
<RikMills> also #1757816 #1757600
<RikMills> LP: #1757816
<ubot5> Launchpad bug 1757816 in qarecord (Ubuntu) "Please remove from focal archive" [Undecided,New] https://launchpad.net/bugs/1757816
<RikMills> LP: #1757600
<ubot5> Launchpad bug 1757600 in autopilot-qt (Ubuntu) "RM: Please remove from focal (Qt4 removal)" [Undecided,Triaged] https://launchpad.net/bugs/1757600
<vorlon> "'Dead upstream for ~10 years' but the last upload was in karmic, karmic wasn't 10 years ag.... oh."
<RikMills> vorlon: called 'flogging a dead horse' I think
<vorlon> RikMills: all done
<RikMills> vorlon: thanks! I will go though more qt4 things left tomorrow if no-one else does. I guess if we get down to just a few that 'might' get an upstream solution on next 2 months, we could bump those to proposed?
<vorlon> they should be removed from release pocket and from -proposed, and if an upstream solution becomes available they can be reuploaded
<vorlon> (or resynced)
<RikMills> even better
<xnox> vorlon:  hey, i think i have done waf conversion to python3 before. Unpacked/repacked waf (btw still my favourite build system) and then they had custom plugins i'm like "if 2to3 -w works, i'm uploading it"
-queuebot:#ubuntu-release- New binary: golang-ginkgo [s390x] (focal-proposed/universe) [1.12.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-ginkgo [ppc64el] (focal-proposed/universe) [1.12.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: efl [i386] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- New binary: golang-ginkgo [amd64] (focal-proposed/universe) [1.12.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: efl [s390x] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- New binary: golang-ginkgo [armhf] (focal-proposed/universe) [1.12.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-ginkgo [arm64] (focal-proposed/universe) [1.12.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cassandra-driver [amd64] (focal-proposed/universe) [3.20.2-1] (no packageset)
<xnox> vorlon:  i hope you enjoy my justification on https://bugs.launchpad.net/ubuntu/+source/bombono-dvd/+bug/1863185
<ubot5> Ubuntu bug 1863185 in bombono-dvd (Ubuntu) "RM RoM bombono-dvd" [High,Triaged]
-queuebot:#ubuntu-release- New binary: efl [ppc64el] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
#ubuntu-release 2020-02-14
-queuebot:#ubuntu-release- New binary: efl [amd64] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- New binary: efl [armhf] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- New binary: efl [arm64] (focal-proposed/universe) [1.23.3-7] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- New: accepted efl [arm64] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted efl [armhf] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted efl [amd64] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted efl [ppc64el] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted golang-ginkgo [amd64] (focal-proposed) [1.12.0-7]
-queuebot:#ubuntu-release- New: accepted golang-ginkgo [armhf] (focal-proposed) [1.12.0-7]
-queuebot:#ubuntu-release- New: accepted efl [i386] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted golang-ginkgo [arm64] (focal-proposed) [1.12.0-7]
-queuebot:#ubuntu-release- New: accepted efl [s390x] (focal-proposed) [1.23.3-7]
-queuebot:#ubuntu-release- New: accepted python-cassandra-driver [amd64] (focal-proposed) [3.20.2-1]
-queuebot:#ubuntu-release- New: accepted golang-ginkgo [ppc64el] (focal-proposed) [1.12.0-7]
-queuebot:#ubuntu-release- New: accepted ocaml [amd64] (focal-proposed) [4.08.1-8]
-queuebot:#ubuntu-release- New: accepted golang-ginkgo [s390x] (focal-proposed) [1.12.0-7]
<vorlon> xnox: bombono-dvd has a reverse-recommends, do you want to fix that?
<vorlon> xnox: you haven't closed LP: #1862267 yet, is LP still timing out for you?
<ubot5> Launchpad bug 1862267 in sqlite3 (Ubuntu) "sqlite3 3.31.1-1 is broken on s390x" [Undecided,Confirmed] https://launchpad.net/bugs/1862267
<xnox> vorlon:  no, because it's a bogus metapackage
<xnox> vorlon:  now closed.
<xnox> vorlon:  force syning debian-multimedia to see what happens
<Kamilion> any idea why my console's getting spammed with python warnings during package upgrades now?
<Kamilion> /usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
<Kamilion> http://puu.sh/FaoPe/4962557a5a.png
<Kamilion> https://paste.ubuntu.com/p/FFYGhB6m68/
<sarnold> ouch
<Kamilion> less than 24 hours since the last package update run, so something's gone south.
<Kamilion> i'll grab yesterday's daily iso and try again, see if it recurs.
<sarnold> I can't spot anything that looks related on https://docs.python.org/3/whatsnew/3.8.html . I wonder when this was introduced
<Kamilion> hm, yeah, I thought the warnings were supposed to come back for 3.9, not 3.8
<Kamilion> https://lwn.net/Articles/811369/
<Kamilion> yeah, recurs with yesterday's lubuntu daily iso -> today's packages
<Kamilion> autoremove just got rid of python3.7-minimal.
<xnox> Kamilion:  sarnold: https://bugs.python.org/issue32236
<xnox> it used to be silently ignored, now it complaints, but we have a lot of code that calls this somewhere up the stack, so the culprit is a package which is being configured/bytecompiled just before
<Kamilion> just tried some other python3 apps I had around, nothing else broke with 3.8. Getting warnings now when I wasn't before, however.
<Kamilion> most of the noise from the package manager seemed to be from hplip
<sarnold> xnox: python is sooo annoying
<Kamilion> small little quirks like sys.maxint -> sys.maxsize >.<
<xnox> doko:  can we turnoff that runtimewarning? at least during bycode compilation on package installation. Our users cannot do anything, and it looks add when they dist upgrade
<Kamilion> yeah, python will read the shebang line and parse it
<Kamilion> https://lwn.net/Articles/740804/
<Kamilion> #!/usr/bin/python3 -W default
<Kamilion> python itself will handle the split in "-W default"
<xnox> i am more thinking to fix dh-python, as it is called in the maintainer scripts upon package installation
<xnox> not changing packages themselves, or shebangs in them
<Kamilion> sure, just figure'd I'd point out how to suppress the warning
<Kamilion> and that python3 will handle argv[1]
<sarnold> I suspect we'd be better served to just fix the surprise bugs; otherwise a future python release may just outright break all these things
<Kamilion> as the first LWN link I posted implied (in 3.9)
<xnox> https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1863195
<ubot5> Ubuntu bug 1863195 in dh-python (Ubuntu) "py3compile should not emit python runtime warnings during dist-upgrade" [Undecided,New]
<xnox> sarnold:  sure, but we are all exhausted after completing python3.8 by default transition which took months to land.
<Kamilion> *nods*
<sarnold> xnox: remind me why anyone still uses this language?
<xnox> and emitting that, on every package install, to the users, is not showing it to the upstream maintainers who don't even have 3.8 enabled in their travis.yaml
<Kamilion> it's got an extremely conveniant REPL
<sarnold> Kamilion: well, true. it does.
<sarnold> xnox: it's like that stupid gtk pixbuf "you're not configured!" warning. I hate that thing.
<xnox> sarnold:  because it's the fast and free matlab with matrixes index right way around.
<Kamilion> and it's pretty easy to mix performance C extensions with a bit of python glue without having a massive boilerplate script
<xnox> (ipython / jypiter / numpy)
<Kamilion> ugh. You think that's bad, enlightenment's errors are egregious
<Kamilion> but now that I have done my Holly work, "Emergency. There's an emergency going on. ... .... It's still going on. It's still an emergency.", I shall digress and return to the ether
<sarnold> mmm ether. enjoy
<xnox> ooooh
<xnox> https://adamj.eu/tech/2020/01/21/why-does-python-3-8-syntaxwarning-for-is-literal/
<xnox> sounds scary
<Kamilion> i've made the same mistake before
<Kamilion> "is not None" is fine for example since all Nones are the same
<Kamilion> but `is not ""` is not, because not all ""s are the same
<Kamilion> or for small integers in CPython, which are allocated once and referenced all over, but not in micropython which lacks that performance-over-memory optimization.
<Kamilion> also, one of the other reasons of 'popularity', sarnold, is micropython itself, as many MCUs today offer lua, javascript (duktape), micropython, and if you're on ARM, a golang target. Xtensas and other esoterics have no functional golang/rust support, for example.
<Kamilion> of those choices, people tend to be most familiar with either python's syntax or javascripts (since lua has no batteries)
<sarnold> Kamilion: so crazy to think that a language that compiles down to machine code isn't on those platforms, but *python*, not known for being lightweight, is..
<Kamilion> micropython, specifically, which only requires like six posix-like libc functions to operate. Mainly just a working malloc/free.
<Kamilion> but yah, esp32s and such, lua/js/mpy...
<Kamilion> or you're stuck with the platform's memmap limit, since the instruction ram is separate from the data ram bus
<Kamilion> obviously a bytecode interpreter mixed with C extensions tends to win in that situation. :)
<sarnold> yeah, constrain what it can do enough and it'll run on those little tiny things :)
<sarnold> dinner time ;) have fun Kamilion, thanks for the bug report
<Kamilion> hugely popular among the makercrowd along with adafruit's circuitpython, the BBC's micro:bit, and the popularity of the raspberry pi genre of single board linux computers.
<Kamilion> that's the nutshell. hope that provides a little perspective :)
<Kamilion> enjoy your foodings.
<sarnold> thanks! :)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1072.82] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1072.82]
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (focal-proposed/main) [1:6.4.0-0ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: kdevelop [s390x] (focal-proposed/universe) [4:5.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [ppc64el] (focal-proposed/universe) [4:5.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: procps [amd64] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: procps [s390x] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: procps [i386] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: procps [arm64] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: procps [armhf] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: procps [ppc64el] (focal-proposed/main) [2:3.3.16-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: kdevelop [amd64] (focal-proposed/universe) [4:5.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [armhf] (focal-proposed/universe) [4:5.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [arm64] (focal-proposed/universe) [4:5.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New sync: caml-mode (focal-proposed/primary) [4.06-2]
-queuebot:#ubuntu-release- New sync: lwt-ssl (focal-proposed/primary) [1:1.1.3-1]
<locutus_> they are new packages, taken over from ocaml ^^
-queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (focal-proposed/universe) [20.04.0] (ubuntu-mate)
<juliank> ben in debian shows transition collisions, our ben does not seem to have that yet
<juliank> I think that would be convenient
<juliank> hmm it should
<juliank> but apt transition should collide with boost transition, and i don't see that?
<juliank> because aptitude depends on both
<Laney> vorlon: I'm not sure, it looks like sometimes apt is happy to remove vim-tiny:amd64 + ubuntu-minimal and sometimes not, more likely to be to do with something in the archive changing rather than autopkgtest changing
-queuebot:#ubuntu-release- New binary: qemu [amd64] (focal-proposed/main) [1:4.2-3ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (eoan-proposed) [3.20191115.1ubuntu0.19.10.3]
-queuebot:#ubuntu-release- New binary: gmic [s390x] (focal-proposed/universe) [2.4.5-1.1] (ubuntustudio)
-queuebot:#ubuntu-release- New: accepted gmic [s390x] (focal-proposed) [2.4.5-1.1]
-queuebot:#ubuntu-release- New: accepted kdevelop [arm64] (focal-proposed) [4:5.5.0-2]
-queuebot:#ubuntu-release- New: accepted kdevelop [ppc64el] (focal-proposed) [4:5.5.0-2]
-queuebot:#ubuntu-release- New: accepted kdevelop [amd64] (focal-proposed) [4:5.5.0-2]
-queuebot:#ubuntu-release- New: accepted kdevelop [s390x] (focal-proposed) [4:5.5.0-2]
-queuebot:#ubuntu-release- New: accepted kdevelop [armhf] (focal-proposed) [4:5.5.0-2]
<cpaelzer> apw: doko: I guess you are the AAs around atm - could one of you before the weekend takea look at qemu in the NEW queue?
<cpaelzer> we added an amd64 only package for some low-overhead isolation use-cases
<cpaelzer> this will have no dep, so once it passed new and migratd it should auto-demot to universe (for now)
<cpaelzer> but passing the new queue today would allow to have the tests running over the weekend
<LocutusOfBorg> question: is node-chokidar eligible for an hint-reset on s390x? http://autopkgtest.ubuntu.com/packages/n/node-chokidar/focal/s390x
<LocutusOfBorg> apw, ^^
<LocutusOfBorg> regressed in release btw
<apw> cpaelzer, done
-queuebot:#ubuntu-release- New: accepted qemu [amd64] (focal-proposed) [1:4.2-3ubuntu1]
-queuebot:#ubuntu-release- New binary: ruby-gollum-lib [amd64] (focal-proposed/universe) [4.2.7.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [amd64] (focal-proposed/universe) [0.16.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [arm64] (focal-proposed/universe) [0.16.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [armhf] (focal-proposed/universe) [0.16.9-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-gollum-lib [amd64] (focal-proposed) [4.2.7.7-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [arm64] (focal-proposed) [0.16.9-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [amd64] (focal-proposed) [0.16.9-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [armhf] (focal-proposed) [0.16.9-2]
-queuebot:#ubuntu-release- New binary: gitaly [ppc64el] (focal-proposed/universe) [1.78.0+dfsg-2] (no packageset)
<RikMills> An AA, perhaps apw free to action? LP: #1862105
<ubot5> Launchpad bug 1862105 in chinese-calendar (Ubuntu) "RM: chinese-calendar uses qt4 which is obsolete" [Undecided,Triaged] https://launchpad.net/bugs/1862105
<apw> RikMills, actioned
<RikMills> thanks :)
<vorlon> Laney: yep fair enough, so I've badtested vim/i386 now
<coreycb> sil2100: hello, would you be able to release pandas to bionic-updates on monday?
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [19.3-17-g50ffca46-0ubuntu1~18.04.1 => 19.3-26-g82f23e3d-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (eoan-proposed/main) [19.3-17-g50ffca46-0ubuntu1~19.10.1 => 19.3-26-g82f23e3d-0ubuntu1~19.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [19.3-17-g50ffca46-0ubuntu1~16.04.1 => 19.3-26-g82f23e3d-0ubuntu1~16.04.1] (ubuntu-server)
<LocutusOfBorg> vorlon, is it possible to node-chokidar reset failed counter on s390x? it is regressed in release I think
<rharper> tjaalton:  Hi, we've had some sru verifications failed, and I've uploaded new packages to address those issues, would you be able to look at getting the newer curtin uploads into -proposed? https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-01-30 - 19.3-17-g50ffca46-0ubuntu1" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: gitaly [amd64] (focal-proposed/universe) [1.78.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitaly [s390x] (focal-proposed/universe) [1.78.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitaly [arm64] (focal-proposed/universe) [1.78.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitaly [armhf] (focal-proposed/universe) [1.78.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [amd64] (focal-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toil [amd64] (focal-proposed/none) [3.24.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [s390x] (focal-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [arm64] (focal-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [armhf] (focal-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [ppc64el] (focal-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [s390x] (focal-proposed/universe) [0.29.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [amd64] (focal-proposed/universe) [0.29.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [arm64] (focal-proposed/universe) [0.29.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [armhf] (focal-proposed/universe) [0.29.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [ppc64el] (focal-proposed/universe) [0.29.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [s390x] (focal-proposed/universe) [0.29.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [amd64] (focal-proposed/universe) [0.29.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [arm64] (focal-proposed/universe) [0.29.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [ppc64el] (focal-proposed/universe) [0.29.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: cmark [armhf] (focal-proposed/universe) [0.29.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1039.44] (no packageset)
<Eickmeyer[m]> Can anybody provide some guidance on anything I need to change, if anything, in the ubuntustudio seed to get it building again? Seems like there's some conflict with libreoffice.
<cjwatson> Eickmeyer[m]: Doesn't look like your problem, more that libreoffice was in binary NEW, which I've just dealt with
<cjwatson> Though I assume it'll still need to get through proposed-migration
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (focal-proposed) [1:6.4.0-0ubuntu6]
<Eickmeyer[m]> cjwatson: Thanks. I'll go back to to my hole. :)
-queuebot:#ubuntu-release- New: accepted gitaly [amd64] (focal-proposed) [1.78.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitaly [armhf] (focal-proposed) [1.78.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitaly [s390x] (focal-proposed) [1.78.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libgclib [arm64] (focal-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted libgclib [ppc64el] (focal-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted toil [amd64] (focal-proposed) [3.24.0-1]
-queuebot:#ubuntu-release- New: accepted gitaly [arm64] (focal-proposed) [1.78.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libgclib [amd64] (focal-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted libgclib [s390x] (focal-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted gitaly [ppc64el] (focal-proposed) [1.78.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libgclib [armhf] (focal-proposed) [0.11.4-1]
<RikMills> Eickmeyer[m]: is there a good reason why you want libreoffice-gtk2 instead of -gtk3 ?
<wxl> please let gtk2 die already
<RikMills> Eickmeyer[m] wxl actually, looks like the libreoffice-gtk in proposed is an empty transitional package anyway
<RikMills> -gtk3 one in -release installs ok
<cjwatson> Yeah, I was just poking ricotz in #ubuntu-devel about the fact that it's totally empty
<RikMills> Eickmeyer[m]: ok. your seed is  * (libreoffice-gtk), that depends on libreoffice-gtk2, which is not useful even when it does come back
<cjwatson> Not sure I see the point of a transitional package that has no (meaningful) contents and no dependencies
<RikMills> yeah, it doesn't migrate you to the gtk3!
<RikMills> studio should probably switch to seeding just the gtk3 anyway
<cjwatson> Indeed
<cjwatson> Eickmeyer[m]: ^- I guess you can take care of that?
<rharper> vorlon:  Hi, we've had some sru verifications failed, and I've uploaded new packages to address those issues, would you be able to look at approving the  curtin uploads into -proposed? https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-01-30 - 19.3-17-g50ffca46-0ubuntu1" [Undecided,Confirmed]
<vorlon> sure thing
<rharper> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (eoan-proposed) [19.3-26-g82f23e3d-0ubuntu1~19.10.1]
<vorlon> xnox: does new gpgme1.0 need new gnupg?
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [19.3-26-g82f23e3d-0ubuntu1~18.04.1]
<vorlon> LocutusOfBorg: node-chokidar: done
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [19.3-26-g82f23e3d-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: gffread [amd64] (focal-proposed/universe) [0.11.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [s390x] (focal-proposed/universe) [0.11.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [arm64] (focal-proposed/universe) [0.11.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [ppc64el] (focal-proposed/universe) [0.11.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [armhf] (focal-proposed/universe) [0.11.7-2] (no packageset)
<vorlon> xnox: "seed future boost1.71" please keep the i386 seed clean to contain only those packages which we directly want to keep, overrides for bootstrapping should go into ubuntu-archive-tools update-i386-whitelist
-queuebot:#ubuntu-release- Packageset: Removed libdigest-sha-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libtrio from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed sgmltools-lite from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added fonts-urw-base35 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libarray-intspan-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added liblist-someutils-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libmoox-struct-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libobject-id-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added python-crypto to i386-whitelist in focal
<xnox> vorlon:  ok, why does the seed exist then? Should i drop it from the seed text, or did you already do it?
<xnox> vorlon: we need to document somewhere how to do transitive transition to whitelist things where source package names change.
<xnox> vorlon:   i don't know how gpgme1.0 at all works. I thought it's "just" a wrapper around the fork/exec of gnupg.....
-queuebot:#ubuntu-release- New binary: libfido2 [amd64] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfido2 [s390x] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfido2 [ppc64el] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfido2 [armhf] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.8-1 => 1.3.8-1] (core)
-queuebot:#ubuntu-release- New binary: libfido2 [arm64] (focal-proposed/universe) [1.3.0-1] (no packageset)
<Eickmeyer[m]> cjwatson: Yeah, I can fix that.
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.8-1 => 1.3.8-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.8-1 => 1.3.8-1] (core)
-queuebot:#ubuntu-release- New: accepted gffread [amd64] (focal-proposed) [0.11.7-2]
-queuebot:#ubuntu-release- New: accepted gffread [armhf] (focal-proposed) [0.11.7-2]
-queuebot:#ubuntu-release- New: accepted gffread [s390x] (focal-proposed) [0.11.7-2]
-queuebot:#ubuntu-release- New: accepted libfido2 [arm64] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted libfido2 [ppc64el] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted gffread [arm64] (focal-proposed) [0.11.7-2]
-queuebot:#ubuntu-release- New: accepted libfido2 [amd64] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted libfido2 [s390x] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted gffread [ppc64el] (focal-proposed) [0.11.7-2]
-queuebot:#ubuntu-release- New: accepted libfido2 [armhf] (focal-proposed) [1.3.0-1]
<Eickmeyer[m]> cjwatson, RikMills, wxl: Updated seed, now doing gtk3 variant directly instead of relying on the old transitional package, which was likely there long before my time.
<wxl> Eickmeyer[m]: that's ok. you should tell your users to get back to audio production and stop word processing anyways XD
<Eickmeyer[m]> wxl: Tell that to the publishing studios. :P
 * wxl hangs his head in shame
<Eickmeyer[m]> hehehe
#ubuntu-release 2020-02-15
<cjwatson> Eickmeyer[m]: Cool, thanks (and I see you updated ubuntustudio-meta too)
<Eickmeyer[m]> Yep, I have a good habit of updating the seed and the meta at the same time, cjwatson .
<vorlon> xnox: the seed is the list of things that we have specifically decided to keep, everything else should be handled via germinate, and for bootstrapping I've been putting the overrides in the script
<vorlon> xnox: as for documenting, this is so short-term I wouldn't spend much effort on it
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.8-1]
-queuebot:#ubuntu-release- New: accepted procps [amd64] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [s390x] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [arm64] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [i386] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [armhf] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [ppc64el] (focal-proposed) [2:3.3.16-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [amd64] (focal-proposed) [0.29.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [armhf] (focal-proposed) [0.29.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [s390x] (focal-proposed) [0.29.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [arm64] (focal-proposed) [0.29.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted cmark [ppc64el] (focal-proposed) [0.29.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted cmark [arm64] (focal-proposed) [0.29.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [amd64] (focal-proposed) [0.29.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted cmark [s390x] (focal-proposed) [0.29.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted cmark [ppc64el] (focal-proposed) [0.29.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cmark [armhf] (focal-proposed) [0.29.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted caml-mode [sync] (focal-proposed) [4.06-2]
-queuebot:#ubuntu-release- New: accepted lwt-ssl [sync] (focal-proposed) [1:1.1.3-1]
-queuebot:#ubuntu-release- New binary: caml-mode [amd64] (focal-proposed/none) [4.06-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted caml-mode [amd64] (focal-proposed) [4.06-2]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (focal-proposed) [20.04.0]
-queuebot:#ubuntu-release- New binary: hw-probe [amd64] (focal-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-thunderbolt [amd64] (focal-proposed/universe) [5.17.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-thunderbolt [s390x] (focal-proposed/universe) [5.17.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-thunderbolt [ppc64el] (focal-proposed/universe) [5.17.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-thunderbolt [arm64] (focal-proposed/universe) [5.17.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-thunderbolt [armhf] (focal-proposed/universe) [5.17.5-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted hw-probe [amd64] (focal-proposed) [1.4-3]
-queuebot:#ubuntu-release- New: accepted plasma-thunderbolt [arm64] (focal-proposed) [5.17.5-2]
-queuebot:#ubuntu-release- New: accepted plasma-thunderbolt [ppc64el] (focal-proposed) [5.17.5-2]
-queuebot:#ubuntu-release- New: accepted plasma-thunderbolt [amd64] (focal-proposed) [5.17.5-2]
-queuebot:#ubuntu-release- New: accepted plasma-thunderbolt [s390x] (focal-proposed) [5.17.5-2]
-queuebot:#ubuntu-release- New: accepted plasma-thunderbolt [armhf] (focal-proposed) [5.17.5-2]
-queuebot:#ubuntu-release- New binary: parsero [amd64] (focal-proposed/universe) [0.0+git20140929.e5b585a-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1039.44]
<nmrp3> HI - what's the channel for the ubuntu development version?
<Bashing-om> nmrp3: try #ubuntu+1 .
-queuebot:#ubuntu-release- New binary: autokey [amd64] (focal-proposed/universe) [0.95.9-2] (no packageset)
#ubuntu-release 2020-02-16
-queuebot:#ubuntu-release- New: accepted autokey [amd64] (focal-proposed) [0.95.9-2]
-queuebot:#ubuntu-release- New: accepted parsero [amd64] (focal-proposed) [0.0+git20140929.e5b585a-2]
-queuebot:#ubuntu-release- New binary: python-tesserocr [amd64] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [s390x] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [arm64] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [armhf] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtremoteobjects-everywhere-src [amd64] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtremoteobjects-everywhere-src [s390x] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtremoteobjects-everywhere-src [arm64] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtremoteobjects-everywhere-src [armhf] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [ppc64el] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtremoteobjects-everywhere-src [ppc64el] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-tesserocr [arm64] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [ppc64el] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted qtremoteobjects-everywhere-src [amd64] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted qtremoteobjects-everywhere-src [armhf] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted qtremoteobjects-everywhere-src [s390x] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [armhf] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted qtremoteobjects-everywhere-src [arm64] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [s390x] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted qtremoteobjects-everywhere-src [ppc64el] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [amd64] (focal-proposed) [2.5.0-1]
<joelkraehemann> hi all
<joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<joelkraehemann> could anyone solve this?
<locutus__> joelkraehemann, you should ask vorlon, reason is: missing build on i386: libinstpatch-doc (from 1.0.0-7)
<joelkraehemann> vorlon: ping
<cjwatson> joelkraehemann: I discussed that one with vorlon, we agreed on a fix, and I thought vorlon had done it, but apparently it didn't take for some reason.  I've removed libinstpatch-doc from focal seeing as it's no longer built as of 1.1.2-1; that should fix it
<vorlon> huh, wonder why it didn't takeu
-queuebot:#ubuntu-release- New binary: pygobject-2 [amd64] (focal-proposed/universe) [2.28.6-14ubuntu1] (ubuntu-mate, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New binary: rhinote [amd64] (focal-proposed/universe) [0.7.4-4] (no packageset)
