#ubuntu-release 2010-11-29
<apw> skaet_, i wonder if the 10.04.2 release should be on the 'future releases' section of the Releases page
<pitti> cjwatson: I don't think that we can realistically fix the oversizedness for alpha-1; can we just release-note this?
<cjwatson> yes, I think so
<pitti> we still have a couple of things we are going to do for downsizing, so I'm not in panic for beta etc. yet
<pitti> but none of those are cheap to do
<ScottK> cjwatson: For Alpha 1 there's no point in spinning anything Kubuntu related on armel.
<cjwatson> do you want me to actively stop those builds, or can we just ignore the failures and not release it?
<ScottK> Ignoring is fine.
<cjwatson> ok
<ScottK> If they ever get in the way of anything that has some hope of being useful, then feel free to kill them off.
<skaet_> cjwatson,  what's the ETA on images to start to become available for QA folk?
<cjwatson> I don't have one yet; I was expecting to just let the normal cron jobs tomorrow morning do it, though
<skaet_> cjwatson, fair 'nuf.   Thanks.
#ubuntu-release 2010-11-30
<jibel> cjwatson, ping.
<jibel> skaet_, cjwatson, are there builds ready for publication?
<pitti> I tested today's daily on real iron (unity) and in kvm (classic gnome), and at least they boot into a live system
<pitti> but we really need the recent gnome-session on an image
<pitti> unity is quite horribly broken on today's image
<skaet_> pitti, ack.   who's looking into the unity issue?
<pitti> skaet_: already uploaded, needs a CD respin
<skaet_> pitti,  great.   you handling the respin?
<jibel> skaet_, if unity is broken, we need a respin of the desktop images. cant we publish the other flavours to the tracker or is there any other showstopper ?
<skaet_> jibel,  that's what I'm looking into now.
<pitti> skaet_: can do, if it is urgent
<skaet_> pitti, yes, please - would be very good to get testing started, and cjwatson's on vacation today.
<pitti> skaet_: ok, checking if gnome-session is properly published
<skaet_> pitti, thanks!
<pitti> skaet_: I'm in tech board meeting, so can you handle the iso tracker updates?
<skaet_> pitti,  if the images are ready,  can do.
<pitti> ok, g-session is published; images building
<pitti> skaet_: ETA 10 mins for Ubuntu alternates, about an hour for desktops
<skaet_> pitti,  ack.   standing by.
<skaet_> jibel, ^
<jibel> skaet_, ok, thx
<pitti> skaet_: hm, seems that building the alternates takes a lot more time now than it used to (in maverick)
<skaet_> pitti, hmm, something else to dig into in december I guess.  :(
<pitti> skaet_: http://cdimage.ubuntu.com/daily/20101130.1/ (i386 still syncing, ETA a minute or so)
<pitti> (there now)
<pitti> jibel: ^
<pitti> skaet_, jibel: FAOD, we'll have to live with the oversizedness for a1; needs to be release-noted
<skaet_> pitti,  have note in TechOver to make sure to write it up.
<skaet_> pitti,  much point in pushing out edubuntu (will it have the same unity/gnome-session we just respun for with ubuntu?)
<pitti> skaet_: can do
<pitti> skaet_: queued
<pitti> ubuntu desktops should finish soon
<skaet_> how about the other flavors?
<skaet_> have pushed out the kubuntu bits, and working on server right now.
<pitti> kubuntu doesn't need a respin for this
<pitti> nor server, obviously
<skaet_> :)
<pitti> not sure about mythbuntu and studio, though
<pitti> are they using unity?
<charlie-tca> xubuntu does not use unity. Will it need a respin?
<pitti> charlie-tca: no
<skaet_> thanks charlie-tca will push it out to the tester then.
<charlie-tca> Thank you
<skaet_> pitti, not seeing the alternates for xubuntu,  just the desktops - can you double check me.
<pitti> skaet_: I didn't rebuild xubuntu, it's not affected by the fix for unity
<pitti> skaet_: so today's autobuilt image (http://cdimage.ubuntu.com/xubuntu/daily-live/20101130/) shold be okay
<skaet_> yup.  I'm just not finding the images where I expected them to be.
<skaet_> daily-live is published (desktop images in there),  its alternate I'm not finding.
<charlie-tca> Xubuntu did not get a build for today's alternate images. The latest I got is 2010-11-29
<pitti> skaet_: http://cdimage.ubuntu.com/xubuntu/daily/current/ ?
<pitti> right
<pitti> apparently -30 failed to build
<cjwatson> looks transient to me, just kick a 'for-project xubuntu cron.daily' rebuild and it should be fine
<cjwatson> (not really here)
<charlie-tca> Thank you
<pitti> charlie-tca: you want one? starting it
<charlie-tca> Please
<pitti> running
<pitti> ETA 20 mins
<charlie-tca> thanks
<pitti> charlie-tca, skaet_: http://cdimage.ubuntu.com/xubuntu/daily/20101130.1/
<pitti> please add to tracker, I'm in desktop meeting
<pitti> and chairing
<charlie-tca> same fail
<pitti> skaet_, jibel: http://cdimage.ubuntu.com/daily-live/20101130.1/
<skaet_> pitti,  ack.  will do
<pitti> skaet_: FYI, we probably want to use tomorrow's dailies for A1 at least for ubuntu desktop
<pitti> but I suppose above build sohuld be by and large a first smoketest?
<skaet_> yup
<cjwatson> urgh.  I'll try to figure out what's wrong with xubuntu daily later today
<charlie-tca> Okay
<cjwatson> unless somebody not on holiday does it first :P
<charlie-tca> I asked Lionel to take a look if he can
<cjwatson> he can't
<cjwatson> I doubt it anyway.  will require shell access to antimony.
<charlie-tca> Well, enjoy your day then, if possible. I can wait until tomorrow
<pitti> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe-ports/dists/natty/m
<pitti> ain/binary-powerpc/Packages.bz2  Hash Sum mismatch
<pitti> E: Some index files failed to download, they have been ignored, or old ones used
<pitti>  instead.
<pitti> well, it still does look transient
<pitti> charlie-tca: retrying again for now
<pitti> (still in meeting, not much time, sorry)
<charlie-tca> No problem. I appreciate every bit of help with this.
<pitti> charlieS: ah, it takes significantly longer now, which is a good sign :)
<pitti> good night everyone
<pitti> skaet_: edubuntu DVD should finish soon
<skaet_> pitti, thanks!
<highvoltage> fwiw I tested the last edubuntu daily build and it was fine!
<charlie-tca> Thanks, pitti
<skaet_> thanks highvoltage,  will go ahead then and move it to tracker.
<skaet_> highvoltage, done
<highvoltage> skaet_: whohoo! is this the image we'll be testing for the alpha release?
<skaet_> highvoltage, yup, hot off the build farms.   :)
<highvoltage> great
<shadeslayer> ahh
<shadeslayer> wrong channel :P
<ScottK> Are we doing ec2 images for Alpha 1 or if so, is there a respin anticipated?  I'm wondering if I can go ahead and update pyyaml to support python2.7.
<charlie-tca> skaet_, the link on the iso tracker for the Ubuntu-netbook image is bad
<charlie-tca> instead of daily-live it should be http://cdimages.ubuntu.com/ubuntu-netbook/daily-preinstalled/current/
<skaet_> thanks, charlie-tca - will fix.
<charlie-tca> that is wrong too
<skaet_> ScottK,  its under discussion.  ec2 i386 images have problem, but not sure if fix will make it in from kernel team in time.
<charlie-tca> can't seem to find the right link yet
<ScottK> skaet_: So it's safe to say it either won't be released or will need a rebuild?
<skaet_> ScottK, sort of, ec2 amd64 should be testable, problem seems localized to i386.
<ScottK> I see.  Thanks.
<ScottK> skaet_: Do you mind if I go ahead and upload pyyaml?  It will result in python-yaml being out of date on ec2, but it will advance python2.7 support.  It can wait until Thursday, I'd just rather get it out of the way while I'm thinking about it.
<skaet_> ScottK, is it in the seeds of other images beyond ec2?
<ScottK> skaet_: No.  Just ec2.
<skaet_> ScottK,  ok, then.
<ScottK> Thanks
<chrisccoulson> hi, am i ok to upload tbird to fix bug 682748?
<ubot4`> Launchpad bug 682748 in thunderbird (Ubuntu Natty) (and 1 other project) "thunderbird doesn't build in natty due to linker changes (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/682748
<skaet_> chrisccoulson, yes, good to get in.
<chrisccoulson> skaet_, cool, thanks
<skaet_> ScottK, Riddell,  most recent kubuntu dvd image I can find is from 2010-11-22.   Should that get uploaded for testing, or should there be a more recent one?
<Riddell> skaet_: that's no use
<skaet_> Riddell,  ack.   do you have a pointer to a more recent one, or has one just not been built?
<Riddell> if it's not on cdimage then it hasn't been built
<skaet_> cdimage is where I found the 11-22 one.   Can you kick off the build for it?
<skaet_> (assuming we want it available with the alpha 1....)
<tgardner> skaet_, just uploaded linux_2.6.37-7.19 to fix bug #676245
<ubot4`> Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/676245
<skaet_> thanks tgardner
<GrueMaster> Anyone here that can fix iso.qa tracker entries?  Need the image link for natty-netbook-armel+omap4.img fixed and testcase added.
<ScottK> skaet_: I wouldn't worry about the Kubuntu dvd this time around.
<skaet_> ScottK,  ok.  thanks.   Can you give me a summary of which images you think are reasonable to ship for Kubuntu at this time?   (or if its easier, just look at the iso tracker and verify I've found the right ones...)
<ScottK> skaet_: I think what you have there is fine.
<skaet_> ScottK,  thanks!
<skaet_> GrueMaster, I can't edit it,  when asking earlier I think it needs to be jibel.
<GrueMaster> ok
#ubuntu-release 2010-12-01
<scott-upstairs> i noticed the ubuntustudio apha-1 image isn't available :(  anyone know why?
<charlie-tca> Not this one? http://cdimages.ubuntu.com/ubuntustudio/daily/20101130/
<charlie-tca> It is on the iso tracker, too
<charlie-tca> scott-upstairs, it won't get called alpha-1 until Thursday, or when it is released. The tests are all done with the daily
<scott-upstairs> hi charlie-tca , i got an email today about this: http://iso.qa.ubuntu.com/qatracker/info/4797
<scott-upstairs> but it says the image isn't available anymore
<scott-upstairs> oi, found it
<scott-upstairs> http://iso.qa.ubuntu.com/qatracker/test/4797
<charlie-tca> We got bad links on the tracker, but the iso is there for testing
<scott-upstairs> yeah, it looks like the link may be down :/
<scott-upstairs> downloading the image now from your link :)
<charlie-tca> The tracker links are acting strange, for reasons I don't know
<scott-upstairs> charlie-tca, now it appears that some canonical servers are down, i wonder if its related to the tracker links
<Riddell> data centre is dying/dead
<ScottK> Lovely.
<charlie-tca> That could be
<charlieS> no, it started 18 mins after you mentioned tracker links, charlie-tca
<charlie-tca> oh
<ScottK> Looks like stuff is coming back.
<skaet_> ScottK,   iso tracker and launchpad are up now again at least....
<quadrispro> hi all
<apw> skaet_, i see the kernel built ok over night
<cjwatson> do I need to rebuild the installer against it?
<apw> cjwatson, good question, let me see what they did the upload for
<cjwatson> [Config] Add bnx2 firmware to nic-modules udeb
<cjwatson> that sounds like a "yes"
<apw> cjwatson, heh yes it looks like it
<cjwatson> technically, most of the CD initrds don't have nic-modules in, and the alternate CDs were built late enough to just include the new nic-modules udeb directly
<cjwatson> server CDs weren't, though
<cjwatson> so might as well respin d-i and build with that
<apw> cjwatson, damn, i had assumed that the CDs were in manual mode during the freeze
<cjwatson> they probably ought to have been, but I was on vacation yesterday
<cjwatson> in this case, it's all to the good
<apw> cjwatson, hopefully we are good now.  there was much flapping yesterday
<cjwatson> well, I reuploaded d-i
<cjwatson> doesn't sound like the bnx2 firmware breakage justified massive panic TBH :-)
<cjwatson> though I suppose you might not have known the cause ...
<apw> cjwatson, i am told it affected some key server testing, but i would have thought fridays CDs would have been just as good too
 * apw goes sort out the VCS carnage inserting the extra upload had wraught
<cjwatson> you know your VCS is too complicated when ... ;-)
 * cjwatson ducks
<apw> cjwatson, heh nothing wrong with the VCS, something wrong with the interaction between the two users working on it at the same time, cause of an emergency
<charlie-tca> If all the images are new today, do we need to update the iso tracker to have them tested again?
<jibel> skaet_, can you remove kubuntu mobile i386, ubuntu studio alternate i386/amd64 from the tracker, there is no build associated with them. Thanks.
<charlie-tca> jibel, the studio builds are there. Something is wrong with the tracker link
<charlie-tca> the builds are at http://cdimages.ubuntu.com/ubuntustudio/daily/20101201/
<jibel> charlie-tca, thanks.  skaet_, per charlie's comment, kubuntu mobile i386 then, and update the links for ubuntu studio alternate
<charlie-tca> We couldn't get the links to work yesterday, either
<apw> is anyone reporting that natty as it is now is logging in to a blank screen, no toolbars etc
<apw> skaet_, ^^
<chrisccoulson> apw - bug 683531
<ubot4`> Launchpad bug 683531 in compiz (Ubuntu) "panel not there after maverick -> natty upgrade with no 3d (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/683531
<chrisccoulson> possibly ;)
<jibel> apw, bug 681294, on eeepc 1015 but before logging in.
<ubot4`> Launchpad bug 681294 in linux (Ubuntu) "[STAGING] X doesn't start with 2.6.37-6+ (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/681294
<charlie-tca> https://launchpad.net/bugs/683403
<ubot4`> Launchpad bug 683403 in gnome-session (Ubuntu) "natty 20101130.1 - 20101201 live session without panel (affects: 2) (heat: 12)" [Low,Fix released]
<jibel> charlie-tca, skaet_, links for ubuntu studio alternate are fixed.
<charlie-tca> thanks, jibel
<skaet_> jibel,  will remove kubuntu mobile i386.   was going to ask you to do the links for ubuntu studio alternate - but looks like you've done them.   have you managed to fix the links preinstalled omap one?  it needs it too.
<jibel> skaet_, no, I was unsure if it needed a fix or removal.
<jibel> skaet_, looking at it now.
<skaet_> thanks jibel,  was pointing to a /ports/ link - should be referencing: http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20101130/natty-preinstalled-netbook-armel+omap4.img.gz
<pitti> hey skaet_, good morning
<skaet_> good afternoon pitti, cjwatson.  :)
<cjwatson> hi.  can we catch up now rather than at the timeslot in your calendar invite?  I have a team meeting then ...
<skaet_> cjwatson, pitti - which images are ready to be refreshed on the iso tracker?
<skaet_> cjwatson, sure, hopping on mumble.
<cjwatson> hm, I think my sound is broken at the moment, sorry
<cjwatson> I'm about to respin server
<cjwatson> (for the kernel thing)
<skaet_> cjwatson,  ack.
<cjwatson> also, I think Ubuntu desktop powerpc builds might actually work for the next spin
<cjwatson> I'll do that right after server - was waiting for new compiz
<ogra> grmbl
<ogra> omap4 doesnt boot due to "unkonwn error" from run-init
<cjwatson> so: currently respinning Ubuntu server, then Ubuntu alternate/desktop.  Does anyone else have specific reasons for rebuilds?
<charlie-tca> missing wubi in Ubuntu/Xubuntu?
<charlie-tca> or can we just put that in the release notes for alpha1?
<cjwatson> good point: that's been fixed build-side, so just takes a respin.  We'll pick it up for Ubuntu, and I'll make sure we respin Xubuntu for you too
<cjwatson> just Xubuntu desktop CDs, I guess, if there's no other reason for a respin there
<cjwatson> mvo: can you look at bug 681382?
<ubot4`> Launchpad bug 681382 in ubuntu-extras-keyring (Ubuntu) "extras gpg key missing for natty (affects: 6) (dups: 1) (heat: 40)" [Medium,Triaged] https://launchpad.net/bugs/681382
<cjwatson> mvo: (maybe you should be subscribed to ubuntu-extras-keyring bugs?)
<highvoltage> For Edubuntu, would it be possible to go with the 20101130 build instead of the 20101130.1 one? 20101130.1 has some session issues and I'm not sure how long that will take to fix, while 20101130 was ok
<cjwatson> what's on the tracker right now?  (I'm rsyncing a CD, HTTP requests are taking forever ...)
<cjwatson> the release script will publish whatever's on the tracker
<highvoltage> cjwatson: .1
<highvoltage> (so the broken one)
<cjwatson> skaet_: ^- can that one be wound back to 20101130?
<skaet_> cjwatson, on it now.
<cjwatson> ta
<skaet_> highvoltage, should be good now,  can you confirm?
<mvo> cjwatson: I have a look now, I saw it yesterday evening but couldn't make sense of it
<highvoltage> skaet_: just got the confirmation email, thanks!
<cjwatson> new server build posted
<skaet_> cjwatson, have disabled the server image, ubuntu alternate and xubuntu alternate images for now.
<cjwatson> whoa
<cjwatson> re-enable server please, see above :)
<skaet_> yeah - I just figured I stomped.  sigh.
<cjwatson> rebuilding Ubuntu alternate then desktop now
<cjwatson> actually - Xubuntu alternate should be re-enabled, I think we only need to respin desktop there
<charlie-tca> That's right. Thanks
<skaet_> cjwatson, what about the ubuntu server EC2 & UEC builds?
<skaet_> charlie-tca, can you check I've got it accurate now?
<charlie-tca> looking
<cjwatson> skaet_: not sure
<skaet_> cjwatson, ok, will ping smoser
<charlie-tca> Perfect for Xubuntu
<charlie-tca> Are ubuntu desktop rebuilding, too?
<smoser> skaet_, images went through test, looking at results now.
<smoser> i think generally well enough
<skaet_> charlie-tca,  yes, desktop is rebuilding as well... will go mark.
<skaet_> smoser, so should be updated to today's build?
<smoser> oh. i didn't follow that.
<smoser> why should we update to today's build ?
<smoser> (sorry for being late to the party)
<skaet_> picked up a new kernel last night
<smoser> ah. then, yeah, i can re-spin tests on todays images
<cjwatson> the new kernel was just udeb changes though
<skaet_> smoser, bug #676245
<ubot4`> Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/676245
<cjwatson> it doesn't affect EC2
<cjwatson> or UEC
<cjwatson> that bug only affects images that use d-i
<smoser> no. wont affect us
 * cjwatson makes http://people.canonical.com/~ubuntu-archive/testing-ports/natty_probs.html wowrk
<cjwatson> *work
<smoser> no installer, *and* no bcm5709
<skaet_> smoser, ok.  we'll leave what's there already alone.
<tgardner> smoser, are you saying  bug 676245 _isn't_ fixed?
<ubot4`> Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/676245
<cjwatson> tgardner: it's not an issue for smoser's images (EC2/UEC).
<tgardner> cjwatson, I know that, but what he's saying  wasn't clear to me.
<cjwatson> "no installer, *and* no bcm5709" - i.e. UEC doesn't have an installer, and doesn't have a virtualised bcm5709 device even if it did
<tgardner> cjwatson, ah, context is everything
<smoser> if i had combined my two lines i think it would appear more clear.  the kernel bug/fix will not affect ec2 images because EC2/UEC have a.) no installer [other than debootstrap/vmbuilder] b.) no broadcom network adapters.
<tgardner> smoser, cool. I'm still awaiting positive confirmation that 676245 was just a firmware load issue.
<mvo> cjwatson: the extras.ubuntu.com key problem is fixed, lamont was kind enough to fix it (was a server side issue)
<cjwatson> thanks.  I guess I'll need to rev apt-setup then
<cjwatson> hm, I suspect all alpha-1 systems will fail to have a working extras.ubuntu.com ...
<cjwatson> or maybe not
<cjwatson> will apt mind if it initially has its extras Release/Release.gpg signed with one key, and then finds that the files on the network are signed with another?
<cjwatson> if you remember, we prepopulate signed Release files so that apt won't downgrade to unsigned
<lamont> cjwatson: the sync script was failing to resign the releases file.
<cjwatson> right, I guessed
<charlie-tca> I did a desktop install, and then ran upgrades, and it worked
<skaet_> charlie-tca, :)  thanks!
<cjwatson> Riddell,ScottK: should I respin Kubuntu desktop (ISO only, the livefs can stay the same) to include wubi on the CD?
<ScottK> cjwatson: I'd say no (I think wubi is very low priority for Alpha 1), but Riddell may feel differently.
<ScottK> (he should be around too)
<Riddell> cjwatson: we need to wait for kdebindings
<cjwatson> Riddell: does that mean Kubuntu needs a respin for alpha-1?
<Riddell> cjwatson: yes
<cjwatson> mvo: ^- can you look at the above analysis about apt-setup and let me know whether you think apt is going to be upset about having the wrong prepopulated Release.gpg?
<cjwatson> I'm going to upload fresh installer packages for that anyway, in case they get picked up in respins
<cjwatson> but I'd like to know whether Ubuntu desktop should be considered invalid due to this
<mvo> cjwatson: I think it will not mind, its only chcking careful for stuff comming from the net (or other external sources). once it in its local namespace/dirspace it trusts it
<cjwatson> ok
<cjwatson> thanks
<cjwatson> I think I've fixed the broken redirects for old ports URLs
<skaet_> jibel ^^^
<cjwatson> modulo syncing
<cjwatson> jibel: the ISO tracker should still update to remove ports/ from all cdimage URLs, though
<cjwatson> (if it hasn't already)
<jibel> cjwatson, sure, I appended that task to my todo list for post-A1. Thank you for fixing it.
<cjwatson> posted Ubuntu alternate/desktop
<skaet_> Riddell,  alternates needed for Kubuntu as well?  or just desktop?
<Riddell> we need both once kdebindings is in
<Riddell> which it doesn't seem to be yet
<skaet_> ok, will mark them both as rebuilding then.
 * skaet_ heading to lunch, biab
<Riddell> kdebindings is in the archive
<Riddell> cjwatson: are you doing cd building?  if so go with new kubuntu images
<cjwatson> Riddell: building
<cjwatson> charlie-tca: Xubuntu desktop posted
<cjwatson> Riddell: I'm going out to get dinner - perhaps somebody else can keep an eye on antimony and post Kubuntu images when they're finished
<charlie-tca> thanks
<skaet_> cjwatson, will keep an eye open for them.
<skaet_> Riddell, ScottK,  kubuntu impages posted to isotracker (20101201.1)
<ScottK> OK.
<cjwatson> BTW, I have an idea how to deal with the transient build failures that plague us on Xubuntu, but it's a bit complicated :-/
<cjwatson> what's happening (for the record) is that main/restricted and universe/multiverse are synced separately, because many images only need the former and syncing universe is pretty slow because it's so big
<cjwatson> (even if not much has changed, it takes an age to work out that there's nothing to do)
<cjwatson> we have a grotty symlink arrangement, but sometimes the Release files get out of sync
<cjwatson> so I think I need to adjust how debian-cd's sources.list is built, to use the two separate mirrors properly rather than relying on the symlinks
<cjwatson> either that or use lmirror, which I'm told is a lot more efficient than rsync.  that might be a good idea anyway ...
<skaet_> cjwatson, is there a good way to get the difference between 20101201 and 20101201.1 for ubuntu desktop & alternate?
<cjwatson> sure
<cjwatson> diff the two .manifest files (for the livefs) and the two .list files (for the iso9660 filesystem content)
<skaet_> was thinking of diffing the manifests, but figured there might be something less burte force.
<skaet_> lol
<skaet_> brute even
<cjwatson> that's what you've got
<skaet_> :)  thanks
<cjwatson> updated packages: compiz compiz-core compiz-gnome compiz-plugins evolution-data-server evolution-data-server-common gksu jockey-common jockey-gtk libcamel1.2-19 libdecoration0 libebackend1.2-0 libebook1.2-10 libecal1.2-8 libedata-book1.2-8 libedata-cal1.2-10 libedataserver1.2-14 libedataserverui1.2-11 libegroupwise1.2-13 libgupnp-1.0-3 libsyncdaemon-1.0-1 nvidia-96-modaliases python-ubuntuone-client ubuntuone-client ...
<cjwatson> ... ubuntuone-client-gnome xterm
<cjwatson> (on i386 but I imagine amd64 is similar)
 * skaet_ nods
<cjwatson> in terms of source packages, that's: compiz evolution-data-server gksu gupnp jockey nvidia-graphics-drivers-96 ubuntuone-client xterm
<cjwatson> amd64 confirmed the same
<cjwatson> the only change in the .list files is to add wubi
<ScottK> I don't suppose there is a server respin coming up?
<cjwatson> not on my list, why?
<ScottK> I've got a clamav security upload to do.
<ScottK> It's not bad enough to cause a respin, but if there was one already planned, I was going to see about getting it in.
<cjwatson> I think you might as well upload it anyway, and then it can be included if we need one
<ScottK> OK.
<ScottK> Let me just test it a bit ....
<ScottK> Uploaded.
<seb128> cjwatson, skaet_: unity fix uploaded
<rickspencer3> thanks ScottK
<ScottK> rickspencer3: For?  It wasn't me who uploaded Unity.
<rickspencer3> oh
<rickspencer3> ScottK well, thanks for just being awesome, then ;)
 * ScottK is pretty sure seb128 is a big boy and can upload his own packages ...
<rickspencer3> haha
<cjwatson> ok.  amd64/i386 accepted so I'm going to run the publisher by hand to hurry things along
#ubuntu-release 2010-12-02
<skaet_> Riddell, are you going to create a https://help.ubuntu.com/community/NattyUpgrades/Kubuntu page for alpha1?
<skaet_> Riddell, ScottK - can you confirm that http://releases.ubuntu.com/kubuntu/natty/alpha-1/ (Kubuntu)  is where the Kubuntu images will be going tomorrow.
 * cjwatson remembers to disable daily CD builds, in the nick of time
<cjwatson> skaet_: early milestones don't go to releases
<cjwatson> skaet_: http://cdimage.ubuntu.com/kubuntu/releases/natty/alpha-1/
<skaet_> cjwatson thanks.
<skaet_> :)
<skaet_> will edit.
<skaet_> cjwatson, my connection started acting up, and I lost part of the last hour of IRC traffic, do we have the packaged fix from desktop team?  (ie,  have the builds started?)
<cjwatson> the publisher's done
<cjwatson> skaet_: it'd be good if you could do the CD builds though - getting kind of late heere
<cjwatson> *here
<cjwatson> I think the sequence we want is:
<cjwatson> buildlive ubuntu daily-live && for-project ubuntu cron.daily-live
<cjwatson> for-project ubuntu cron.daily
<cjwatson> buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd
<cjwatson> buildlive edubuntu-dvd dvd && for-project edubuntu cron.dvd
<cjwatson> and possibly, if so probably before the DVDs:
<cjwatson> buildlive ubuntu-netbook daily-preinstalled && for-project ubuntu-netbook cron.daily-preinstalled
<skaet_> understand its late, and appreciate you're staying up so far.
<skaet_> let me get started with the first step, and then if environment's good,  I'll work through them.
<cjwatson> BTW, the desktop fix: https://launchpad.net/ubuntu/+source/unity/3.2.2-0ubuntu2
<skaet_> thanks!
<skaet_> was going to ask about that... ;)
<cjwatson> I'm doing a source DVD build as well, but that shouldn't interfere, can work in parallel
<cjwatson> I think you should assume that ubuntu-netbook preinstalled needs to be rebuilt unless you hear otherwise from #ubuntu-testing, since it does contain unity
<skaet_> ok
<rickspencer3> hmm
<skaet_> cjwatson screen session resumed from oct, ok. ubuntu daily-live started...  can you check looks ok from your point?
<cjwatson> it's running the right commands thus far
<cjwatson> not sure that says very much, but anyway :)
<skaet_> heh
<skaet_> will bug some of the other release team members if it looks like its going in the weeds...  sleep well.
<skaet_> ubuntu desktop i386 and amd64 are available on the iso tracker now (20101202)
<skaet_> ubuntu alternates for i386 and amd64 are availabe on iso tracker now (20101202)
<skaet_> ubuntu netbook preinstalled omap4 is available on the iso tracker (20101202)
<pitti> Good morning
<skaet_> good morning pitti
<skaet_> ubuntu dvd for i386 and amd64 have just been posted to iso tracker.
<skaet_> edubuntu is now building.
<skaet_> not sure if highvoltage will want to move up to it or not though.
<skaet_> haven't seen any bugs flagged against his 20101130 runs, but ... could be impacted by the bug fixed this afternoon.  not sure.
<skaet_> pitti,  could you keep an eye on the builds on animony, and when the edubuntu finishes, see if highvoltage want's it uploaded to iso tracker or not?
<skaet_> antimony even...
 * skaet_ is feeling like its time to zzzz...
<pitti> skaet_: sure, will do
<pitti> skaet_: I guess we can post it either way, and then choose to release it or not
<skaet_> thanks pitti!
<pitti> highvoltage: ^ does that work for you?
<pitti> highvoltage, skaet_: ah, since the current edubuntu DVDs are fully tested already, perhaps I sholdn't post them without highvoltage's exlicit ack
<pitti> skaet_, highvoltage: http://cdimage.ubuntu.com/edubuntu/dvd/20101202/ is ready; do you want this as a1 candidate, or the already tested 1130 one?
<apw> skaet_, when doing iso testing which desktop option are we meant to be testing
<apw> (as there are now two, and depending on h/w you get a different one)
<ogra> skaet_, so armel is blocked by bug 683683
<ubot4`> Launchpad bug 683683 in klibc (Ubuntu Natty) (and 3 other projects) "run-init on omap3, omap4 in natty dies with "run-init: Unknown error 17718852" (affects: 3) (dups: 1) (heat: 26)" [High,Invalid] https://launchpad.net/bugs/683683
<ogra> (its not klibc but busybox)
<cjwatson> ogra: why busybox?  run-init's in klibc
<cjwatson> oh, right, reading the bug now ...
<cjwatson> ogra: any way I can try this under emulation?
<Riddell> bug 684059 seems a bit of a showstopper for kubuntu, am investigating
<ubot4`> Launchpad bug 684059 in ubiquity (Ubuntu) "Kubuntu Live Session/Installer: NameError: global name 'QWidget' is not defined in /usr/lib/ubiquity/frontend/kde_components/PartAuto.py (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/684059
<cjwatson> Riddell: should be http://paste.ubuntu.com/538959/, right?
<Riddell> cjwatson: yes that's right
<Riddell> not sure how it managed to work before
<Riddell> CD installs fine apart from that issue
<Riddell> cjwatson: can we do an ubiquity upload then?
<cjwatson> please go ahead
<ogra> cjwatson, no idea why busybox, but replacing busybox-initramfs makes it work, i doubt you can try that in emulation easily since its in initramfs
 * ogra just did a build without -marm (though that shouldnt do anything) and under the maverick toolchain
<ogra> lets see if i can get it booting
<ogra> cjwatson, fyi the above boots
 * ogra has to find out if its -marm or the natty toolchain getting in our way here
<ogra> will do another rebuild now
<cjwatson> we only use -marm because you said something else broke beforehand :)
<ogra_ac> yes, that was thumb2 back in lucid and maverick
<ogra_ac> i guess we can drop it today
<ogra_ac> but i really doubt it is the issue
<ogra_ac> i bet on the toolchain
<rsalveti> ogra_ac: to drop it you should at least test the reboot -f, that didn't work without marm
<rsalveti> I think we should be fine with it, but would be good to test the same bug as before
<ogra_ac> sure
<ogra_ac> first of all i want run.init to work though
<rsalveti> it's probably a combination with the new toolchain
<ogra_ac> worst case jasper can pull reboot from the system in and not use the busybox one
<rsalveti> sure, if it makes the image usable, go for it
<ogra_ac> well, i dont count on A1 anymore anyway
<cjwatson> you could compare assembly of run-init
<ogra_ac> i didnt see assembly in it
<rsalveti> would be good to build the new busybox with the older toolchain
<rsalveti> to make sure it's related with it
<ogra_ac> thats what i did above
<ogra_ac> maverick toolchain and dropped -marm
<ogra_ac> now i'm doing the same with the natty toolchain
<rsalveti> oh, ok, I thought you just dropped -marm
<ogra_ac> and we'll see if its -marm only
<ogra_ac> which i doubt
<cjwatson> ogra: I mean generated assembly from the compiler
<cjwatson> although, you said that run-init didn't change, so I guess it's not that
<ogra_ac> right
<ogra_ac> klibc is the same as mavericks (not even rebuilt) as well as eglibc
<ogra_ac> and downgrading to mavericks busybox-initramfs makes everything work fine
<cjwatson> something to do with how it's executing subprocesses?
<ogra_ac> likely
<ogra_ac> run-init only calls execve() afaik
<ogra_ac> and it seems to fail in that
<cjwatson> or not subprocesses in this case, I hope we do 'exec run-init'
<cjwatson> do you have anything resembling a traceback or anything like that?
<ogra_ac> note really and its really hard to get it from the point where run-init runs since the calling pid needs to be 1
<ogra_ac> *not
<ogra_ac> i think NCommander managed to get an strace by hacking up /init
<ogra_ac> but he seeem to not have attached it to the bug (and isnt up yet)
<ogra_ac> *seems
<ogra> GRRRR !
<ogra> so it *IS* -marm
<ogra> boots fine when built with natty toolchain and -marm dropped
<ogra> uploaded
<cjwatson> go ahead and upload it with the -marm dropped, then
<cjwatson> ah yes :)
<cjwatson> thanks
<cjwatson> are you going to shoot for revalidating this in time for an alpha 1 release?
<ogra> when is ETA for A1 ?
<cjwatson> ASAP
<ogra> then just skip it, i think i saw an oem-config crash too when testing (but didnt pay much attention to that one since i was only validating initrd)
<cjwatson> Riddell: I assume you want a Kubuntu desktop rebuild as soon as this publisher run has finished?
<ogra> so its inlikely it will survive
<cjwatson> ogra: OK, presumably might as well do a test run to catch as much as possible now?
<ogra> yes, but i'm not tied to release A1 if this one doesnt work
<ogra> i know there were some ubiquity fixes (skaet said so) and i was testing yesterdays image
<ogra> so it might well be fixed already
<Riddell> cjwatson: yes please (assuming ubiquity is in it)
<highvoltage> pitti: the already tested 1130 one, please
<pitti> highvoltage: ok, thanks
<pitti> skaet_: ^ FYI
 * highvoltage needs to get up earlier on alpha days :)
<highvoltage> skaet_: I added Edubuntu to https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview - ideally I would've liked to be more terse, but pretty much all I added there is important
<cjwatson> Riddell: it is, except for armel
<Riddell> armel is our for alpha 1 for kubuntu for sure
<cjwatson> so can't build the preinstalled ones yet, but I assume that those suffer from the same issue as ogra's
<ogra_ac> heh, yeah
<cjwatson> oh yes of course, KDE is hosed there
<ogra_ac> right
<cjwatson> sorry, should have known that
<ogra_ac> no QT, no KDE
<ogra_ac> nah, its enough if Riddell and i know ;)
<cjwatson> Riddell: rebuilding now
<cjwatson> ogra: will you take care / have you taken care of letting management know that alpha-1 is toast on arm?
<ogra_ac> cjwatson, i will, if skaet_ is up, david is aware that we likely wont make it
 * skaet_ waves,   with cup of coffee in hand.
<ogra_ac> dont wave with a cup if there is coffee in it !!!!
<skaet_> lol
 * skaet_ ...I've spared the keyboard this time 
<pitti> hey skaet_, good morning
<skaet_> good afternon, pitti :)
<skaet_> pitti,   thanks for taking care of the Edubuntu last night.  :)
<skaet_> highvoltage,  ack - we'll release with the 20101130 ones.
<pitti> skaet_: well, I didn't really do anything :)
<skaet_> pitti,  it was sorted out when I woke up - that is something!!  :)
<doko> skaet_: if you do the release announcement, would it be possible that to add that the archive will become a bit uninstallable after the alpha for a day or two, because we update the python default to 2.7?
<skaet_> doko,  ack.   seems reasonable to add a warning.  (and good to get the python default change debugged)   might be a good idea to wait a day or two, rather than tackling it immediately on friday, since others are still trying to get their images into basic working condition.   We can talk about at release meeting tomorrow?
<cjwatson> are there any images that expect to release late, rather than just slipping to alpha-2?
<doko> hmm, ok, although I'd like to use the buildds on the weekend, so friday night would be good ...
<skaet_> cjwatson, just thinking it might be nice to get a workable arm image available, before everything breaks again.
<cjwatson> heh, somebody beat me to posting kubuntu desktop
<cjwatson> (got distracted)
<cjwatson> well, we can try to build one now with the fixed busybox
<cjwatson> but ogra expected other things to be broken
<skaet_> doko, if everyone agrees tomorrow - I'm cool with using the weekend build reseources.
 * cjwatson runs  buildlive ubuntu-netbook daily-preinstalled && for-project ubuntu-netbook cron.daily-preinstalled
<rsalveti> but the good thing is that the arm image will at least boot now
<ogra_ac> well, we could test at least
<ogra_ac> cjwatson, skaet_ ^^^
<skaet_> ogra_ac,  ack.
<cjwatson> you should have a build in, er, however long it takes
<ogra_ac> but i saw an error popping up with the old oem-config/ubiquity which i didnt pay attention to (due to being busy with initrd issues)
<ogra_ac> 90min
<rsalveti> ouch
<ogra_ac> but the image was a day old
<cjwatson> don't suppose anyone has a traceback?
<ogra_ac> nope
<ogra_ac> i can check if there is a log on the SD, gimme a sec
<jibel> skaet_, bug 684059 is a showstopper for kubuntu, any chance to fix it today ?
<ogra_ac> cjwatson, http://paste.ubuntu.com/539026/
<ubot4`> Launchpad bug 684059 in ubiquity (Ubuntu) "Kubuntu Live Session/Installer: NameError: global name 'QWidget' is not defined in /usr/lib/ubiquity/frontend/kde_components/PartAuto.py (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/684059
<jibel> Riddell, ^ ?
<Riddell> jibel: it's fixed
<cjwatson> jibel: 20101202
<jibel> cjwatson, Riddell, ok thanks.
 * cjwatson wonders why Riddell's upload didn't close the bug
<cjwatson> Riddell: ... you know, it's nice if you upload the same thing as is in bzr. :-)
<cjwatson> archive logs say:
<cjwatson> 2010-12-02 13:10:35 DEBUG     * Automatic update of included source packages: partman-auto
<cjwatson> 2010-12-02 13:10:35 DEBUG       93ubuntu2.
<cjwatson> bzr says:
<cjwatson>   * ubiquity/frontend/kde_components/PartAuto.py fix namespace on QWidget
<cjwatson>     LP: #684059
<cjwatson> the upload has the fix, it's just the changelog that's wrong
 * cjwatson closes the bug by hand
 * ogra_ac wonders what /var/lib/ubiquity/apt-install-direct is
<cjwatson> I'm fixing that bug
<cjwatson> notice that it fails trying to *create* that file - ergo the directory doesn't exist
<ogra_ac> ah
<cjwatson> fixed in bzr.  want me to upload?
<ogra_ac> and i was grepping myself to death :)
<cjwatson> I don't know if that's the only thing
<ogra_ac> well, at least iots one down
<cjwatson> perhaps if you try applying that fix by hand?
<cjwatson> r4446 in ubiquity
 * ogra_ac checks
<ogra_ac> grrr, need to bzr upgrade first
<ogra_ac> sigh ... slooow
<ogra_ac> ah, finlly
<ogra_ac> *finally
<pitti> good night everyone
<skaet_> good night pitti.
<cjwatson> sigh, arm build failed because ubiquity wasn't in sync
 * cjwatson restarts :-/
<ogra> yeah, just noticed that too
<ogra> test install running btw
<ogra> cjwatson, happily looking at a 2D netbook screen here, seems the fix is good to upload
<rsalveti> cool
<cjwatson> ok, good, will do
<ogra> beyond that natty seems to run really great
<lamont> I wonder if ppc will catch up before alpha1
<ogra_ac> we could try building it on arm ;)
<ogra_ac> seems to be faster
<lamont> ubiquity was what crabapple was building when it died
<rsalveti> ogra_ac: cjwatson: I can also confirm that the arm image worked fine after porting the busybox and ubiquity fixes
<rsalveti> running normal desktop now
<ogra_ac> ah, good to know
<marjo_> ogra_ac: are you testing http://iso.qa.ubuntu.com/qatracker/test/4865
<ogra_ac> marjo_, wont work without manually applying a ubiquity fix
<marjo_> ogra_ac: ack
<ogra_ac> the build before was tested, fixes for both bugs we identified were uploaded
<marjo_> ogra_ac: ack
<ogra_ac> given that we dont want to hold up A1 by re-rolling and re-testing another image we will skip A1 beyond what was tested and fixed
<marjo_> ogra_ac: makes sense at this time
<ogra_ac> we know that the dailies will work from now on, thats enough as a stop gap
<ogra_ac> GrueMaster, do you plan to test the above image ?
<ogra_ac> (with the manual ubiquity fix)
<GrueMaster> Does this image have the busybox fix?
<ogra_ac> yes, buut not the ubiquity one
<GrueMaster> ok, pulling now.  I had thought it was built before the busybox fix was uploaded (based on earlier discussions on the other channel).
<GrueMaster> Otherwise I would have tested it already.
<ogra_ac> let me check, but i think its the new one
<Riddell> skaet_, cjwatson: I'm off out for the evening, kubuntu images look good to release, I don't think we'll have any kubuntu release page done for alpha 1
<ogra_ac> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20101202.1/ should have the fixed busybox
<skaet_> Riddell, ok, I'll remove the refs from techoverview for the alpha1 for now.
<GrueMaster> Ok.  The test on iso.qa points to 20101202
<GrueMaster> and I just finished pulling it down.
<ogra_ac> yeah, just seeing that
<GrueMaster> Will restart zsync...again.
<ogra_ac> well, zsync to the new one should be fast
<ogra_ac> only a few byte have changed
<Daviey> Can the A1 image of Mythbuntu be canned... there is unlikely to be any testing, and the non platform delta with Maverick is none.
<cjwatson> Daviey: yes, superm1 communicated that to us
<cjwatson> we'll skip publishing it
<Daviey> ahh perfect, i missed that
<skaet_> Daviey, have gone ahead and disabled it in the tracker as well to make it clear.
<Daviey> skaet_: awesome.
<GrueMaster> Can someone update iso.qa with the correct ubuntu netbook armel image?  It is 201011202.1 not 20101202.  I don't want to enter data then have someone kill my data because of it being updated.
<cjwatson> I thought that that one was going to fail too, due to the lack of ubiquity 2.5.5?
<cjwatson> but I can certainly update it - doing so now
<cjwatson> done
<GrueMaster> ogra_ac asked me to test it after manually modifying the image with the ubiquity patch.  It seems to be working.  BTW:  Is there a bug filed for that patch?  Need it for tracker.
<ogra_ac> GrueMaster, just add a note about it, there was no bug since it was found and fixed immediately
<GrueMaster> I can't pass the image as is.  System doesn't work that way.
<ogra_ac> sure, mark it failed then, just so we have a datapoint for it
<GrueMaster> I need a bug number for that.
<ogra_ac> ??
<cjwatson> file one if you have to
<ogra_ac> just check the "failed" radiobutton and leave a note
<cjwatson> though the fix is already uploaded so it's just pushing paper ...
<ogra_ac> right
<GrueMaster> I understand that it is all paperwork at this point.  I didn't design the system.  But I can't mark it as passed as the image fails without the fix, and I can't mark it as failed without a bug number.
<GrueMaster> So, I will install ubiquity and file a proper bug report.
 * ogra_ac tries 
<cjwatson> you don't need to install ubiquity
<ogra_ac> wow
<cjwatson> this doesn't need logs, it can just be a placeholder bug
<ogra_ac> thats bad
<ogra_ac> GrueMaster, i understand what you mean
<GrueMaster> Bug filed and updated as Fix Committed.  iso.qa updated.  I'm breakig for lunch.  bbl.
<highvoltage> is it out yet?
 * highvoltage ducks
<ogra_ac> GrueMaster, thanks a lot
<cjwatson> GrueMaster: Fix Released
<cjwatson> (ubiquity 2.5.5)
<ogra_ac> GrueMaster, i will not ask you such stuff again but just strike it from the tracker in the future, that was silly (i didnt know the tracker is so bad in this regard)
<cjwatson> never mind, I've closed it now
<GrueMaster> ogra_ac: This is one of many issues I have with the tracker.  The biggest issue is that if we were to respin for any issue that is non-related to any test results previously posted, I can't pull them up and confirm that the status hasn't changed.
<ogra_ac> yeah, i remember you saying that before
<ogra_ac> do we have a project we can file bugs against ?
<ogra_ac> would be great if there could be a link in the tracker itself to file bugs against it
<cjwatson> ubuntu-qa-website, I think?
<cjwatson> though best check with somebody in QA
<marjo_> ogra_ac, cjwatson, GrueMaster: https://bugs.launchpad.net/ubuntu-qa-website/+filebug
<ogra_ac> perfect
<ogra_ac> GrueMaster, Bug 684404 and bug 684409 (if you want to subscribe to them)
<ubot4`> Launchpad bug 684404 in ubuntu-qa-website "the isotracker should have a "file bug against this tool" link i its menu (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684404
<ubot4`> Launchpad bug 684409 in ubuntu-qa-website "there should be a way to mark an iso test as failed even without a bug (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684409
<highvoltage> w/win 26
<ogra_ac> does the first w stand for "whash" ?
<highvoltage> I go through channels quite fast, so I guess it must be 'warp'
<ogra_ac> heh
<stgraber> ogra_ac: that's a new "feature" :) I didn't implement that in the tracker, with my code you could mark a failed without a bug number
<ogra_ac> stgraber, heh
<marjo_> stgraber, ogra_ac: the reason we put that feature in is to be able to track "failed tests with a bug number" i would prefer we don't go backwards!
<ogra_ac> well, for this case it cuased extra work for three people
<ogra_ac> but i understand that its a corner case
<marjo_> ogra_ac: understood
<marjo_> ogra_ac "most" of the time, when a tester claims a test failure, we want to track it
<ogra_ac> indeed
<ogra_ac> as i said to tobin above, in the future i will just wipe the image from the tracker
<ogra_ac> just felt more accurate to mark it properly failed with a comment
<marjo_> ogra_ac: ack
<cjwatson> smoser: http://uec-images.ubuntu.com/releases/natty/alpha-1/ says "Daily Build"
<smoser> yeah. i know.
<smoser> i'll see why
<cjwatson> ok, hadn't seen it on this channel
<bjf> skaet_, release schedule shows 10.04.2 as Jan 27th, is that still correct?
<skaet_> bjf,  hmm have missed an update or two.  :)
<skaet_> should be in Feb
<smoser> cjwatson, fixed now. http://uec-images.ubuntu.com/server/releases/natty/alpha-1/
<bjf> skaet_, maybe i'm looking at the wrong schedule? https://wiki.ubuntu.com/LucidReleaseSchedule
<skaet_> That's Lucid's...
<bjf> skaet_, and lucid is the 10.04 LTS
<charlie-tca> bjf, https://wiki.ubuntu.com/NattyReleaseSchedule shows Feb 17
<skaet_> I'll go in and update Lucid's if that's where folks will look
 * skaet_ figured I'd missed a couple.
<bjf> skaet_, it's also on: https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS
<skaet_> bjf,  cool.  willl take care of them all right now.
<ScottK> doko: Where did we agree to switch to Python 2.7 as default right after Alpha 1?
<cjwatson> foundations meeting yesterday
<cjwatson> though skaet_ asked that we wait until after the release meeting tomorrow
<ScottK> I thought we agreed for him to do an archive rebuild test.
<ScottK> The plan all along has to been to get 2.7 supported first.
<ScottK> We don't even have Main done yet.
<cjwatson> oh, I missed "as default", sorry
<cjwatson> http://irclogs.ubuntu.com/2010/12/01/%23ubuntu-meeting.txt:[16:41] <doko> in that case, I would like to make the test rebuild with 2.7 as the default, so we know immediately what needs to be fixed
<cjwatson> http://irclogs.ubuntu.com/2010/12/01/%23ubuntu-meeting.txt:[16:41] <barry> doko: do it
<cjwatson> I find that ambiguous
<cjwatson> at the time, I understood that to mean "switch the default, and immediately do a test rebuild so that we know what we need to plough through"
<doko> cjwatson: yes, the latter is what I meant
<ScottK> OK.
<ScottK> Not what I understood at all.
<ScottK> I thought that meant do a test rebuild so we'd know what needed to be done before we were ready to switch.
<ScottK> doko, cjwatson ^^^
 * ScottK doesn't understand the rush to break the archive?
<cjwatson> I don't mind, as long as we're not so leisurely that 2.7 misses natty
<doko> there is no rush. and I'll be surprised to learn how you'll avoid breakage for a short amount of time
<ScottK> doko: Until you've done the rebuild test and we've at least got 2.7 support in packages that will support both, how do you know it will be short?
<doko> yes, this is what was missed until now, but afaiu barry, the rebuild test was done
#ubuntu-release 2010-12-03
<ScottK> Just to pick one trivial example, debdonf doesn't currently support 2.7.
<ScottK> That one would be nice to fix before you change the default.
<cjwatson> I can do that right now if you want
<cjwatson> though there's a bit of an issue that it fails to build due to a missing MIR
<ScottK> Sure, but it's just an example of how it's not nearly time to switch.
<cjwatson> if somebody would like to respond to bug 681000 ...
<ubot4`> Launchpad bug 681000 in qt4-perl (Ubuntu) "[MIR] qt4-perl (affects: 1) (heat: 505)" [Undecided,New] https://launchpad.net/bugs/681000
<ScottK> I've got other work I'd planned for tonight than arguing for at least a rudimentary level of preparation before switching Python defaults.
<cjwatson> I really don't mind, I just want to get moving.  Can we enable 2.7 support tomorrow and aim for switching the default in time for Alpha 2?
<doko> I'm open for suggestions to delay such a switch for a fixed amount of time if I know that people do work on solutions.  But in the current state of development I do accept a certain breakage which can be fixed within days
<ScottK> 2.7 support is already enabled.
<doko> I'll upload ~350 rebuilds within the next hour
<cjwatson> doko: skaet asked to wait for tomorrow
<cjwatson> you agreed, I thought
<doko> ahh, ok
<cjwatson> er, by tomorrow I mean after the release meeting
<doko> cjwatson: that was with 2.7 as the default, not just adding rebuilds to get support for 2.7. this won't break anything. either the builds succeeds, or not
<ScottK> cjwatson: I agree that rebuilding with 2.6 default and 2.7 support is safe and sane.
<ScottK> support/supported
<cjwatson> doko: no cases where installability might temporarily suffer due to multi-binary packages with Architecture: all and any combined?
<cjwatson> the reason skaet was asking for a bit of a delay was that some images unexpectedly slipped from alpha-1 and she was contemplating the possibility of releasing them late
<cjwatson> speaking of which, having another go at building ubuntu-netbook/armel now ...
<doko> cjwatson: afaik, no. pending build failures on some architectures introduced by the toolchain
<doko> ok, I'll wait on this one
<cjwatson> we can probably cope with rebuilds that more-or-less-provably won't cause CD build failures
<doko> the thing is that CD sizes will increase, and I cannot tell easily which universe package may succeed to build without having the main rebuilds in the archive
<cjwatson> we're already oversized and not caring about it for alpha-1
<doko> I'll just fire up a handful of builds which are known to be built first, I'll delay anything else for later
<barry> sorry, i was at dinner.  "doing the archive test rebuild with python 2.7 as default" (and getting the results of that before switching to 2.7 as default permanently) was what i meant by "do it"
<skaet_> just back from dinner as well.   Thanks cjwatson.  doko would like to see if we can get an armel  image, before things go into high churn mode.
 * skaet_ just missed doko it appears.
<skaet_> bjf, I think I've synched the links up with the master schedule now.  Please let me know if you find others,  I'm collecting a list ;)
<bjf> skaet_, cool, have a good night
<skaet_> thanks bjf,  you too
<cjwatson> ogra,GrueMaster: does http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20101203/ work?
<cjwatson> I built that last night just before going to bed
<rsalveti> it should, but I'm downloading it to test
<cjwatson> if it does, we can potentially release it and you can have an alpha-1 after all
<rsalveti> cool, just writing it at the sd card and will report it back in some minutes
<rsalveti> cjwatson: installed fine here, and I'm now at the efl interface
<rsalveti> working nicely
<rsalveti> ogra: the audio worked fine, but just after the second reboot (the first boot, after finishing the installer didn't recognize the sound card)
<rsalveti> cjwatson: but I believe we can release it as a-1
<ScottK> ara: Do you take care of updating ISO test procedures for iso.qa.ubuntu.com?
<pitti> are we going to have a release meeting today?
<skaet_> pitti,  yes
<skaet_> There's an agenda up, but probably more important at this stage is to get some understanding of how python2.7 transition is going to happen, and make sure everyone has chance to comment.
<pitti> skaet_: *nod*
<cjwatson> skaet_: OK, sounds like we can release that new netbook armel image for alpha-1, if you're OK with that.  It looks like I forgot to put it on the tracker - I've done that now so that publish-image-set can see it
<cjwatson> skaet_: want me to just push it out now?
<ogra_ac> oh, that would be cool
<ogra_ac> it looks very good
<skaet_> ogra_ac,  great.
<skaet_> cjwatson, go ahead and push it
<skaet_> I'll go in and update the technical overview so it has reference to it again.
<skaet_> ogra_ac, any overview information and things to watch out for that should be added?
<cjwatson> mkdir: cannot create directory `/srv/cdimage.ubuntu.com/www/full/ubuntu-netbook/releases/natty/alpha-1': No space left on device
<cjwatson> oh FFS
<ogra_ac> nothing, it seems to behave identical to the maverick release (even better in some areas)
<ogra_ac> i havent seen any issues yet
 * cjwatson nukes the www.prev backup tree
 * ScottK makes a note of that acronym for future use.
<ogra_ac> you mean "FFS (full free software)" ?
<ogra_ac> :)
 * skaet_ needs to figure out that acronym...  
<pitti> skaet_: for f***'s sake
<skaet_> pitti, lol.   thanks!
<pitti> skaet_: I know, not exactly the classical British understatement :)
<cjwatson> that's OK, I'm not British ;-)
<cjwatson> (well, I am.  kind of.  but.)
<cjwatson> ok, I've pushed that image out now
<rsalveti> awesome, thanks a lot :-)
<cjwatson> is there any reason to consider the archive still semi-closed at this point?
<cjwatson> (http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/, when it's finished mirroring)
<pitti> cjwatson: oh, do we?
<cjwatson> well, I was avoiding syncs and the like in case we needed to respin late images.  but I think that's pretty unlikely at this point, right?
<pitti> I saw the "released" and threw a lot of rebuilds against the archive (mostly for space reduction, but also some bug fixes)
<ScottK> cjwatson: It would, however, to be nice to avoid the now almost traditional post-milestone that breaks the archive just as most everyone who could do something about it vanishes for the weekend.
<cjwatson> yeah, keeping the archive semi-closed is more or less impossible :)
<pitti> and #u-devel topic said "open", so sorry if that was premature
<ScottK> post-milestone upload ...
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html is looking basically no worse than just before the alpha
<GrueMaster> cjwatson: I am just now waking up, and I have a meeting downtown in an hour, so I won't be able to do any testing on the image until later today.
<cjwatson> GrueMaster: rsalveti has run it through and declared it OK, so I released it
<cjwatson> (on top of the ad-hoc testing from yesterday)
<apw> skaet_, i assume the milestone freeze came off today ?
<ScottK> It did
<apw> ScottK, thanks
#ubuntu-release 2010-12-04
<nhandler> I have been meaning to ask for a while, but I think it might be cool to have a classroom session about what an Archive Admin does (along with some Q&A). There isn't much info other than the AA wiki page, and I doubt many people realize or appreciate the amount of work that is done.
<cjwatson> sure, I'd be up for doing such a thing at some point
<cjwatson> though would need some warning, I take a while to compose talks
<Riddell> I wonder if that could attract some new archive admins, /me hopes :)
<nhandler> cjwatson: Whenever is good for you is good for us. And if you want to do the session with some other archive admins that is also fine (if you can convince them). We just need at least 1 week's notice to get everything setup on our end
#ubuntu-release 2011-11-28
<GridCube> stgraber, :) hello
<stgraber> hi GridCube
<GridCube> I wonder, we should start doing test already, pre-alpha1 tests, so we need to report them, can we use the current tracker? or is it not ready yet?
<stgraber> it should be ready in 5 minutes or so, loading the last export of the DB now
<GridCube> :o
<stgraber> I'll send an e-mail to ubuntu-devel, ubuntu-qa, ubuntu-testing and ubuntu-release when it's ready
<GridCube> :P im not part of any of those
<GridCube> add an x to a few and sure XD
<GridCube> one question if you can, whats XMLRPC?
<cjwatson> stgraber: that build seems to have succeeded, BTW, as did the cronned one
<cjwatson> http://en.wikipedia.org/wiki/XML-RPC
<cjwatson> specifically http://docs.python.org/library/xmlrpclib.html
<stgraber> cjwatson: yep, I did some testing on it, found a bug, fixed it and the fix maybe even made it for the cronned one :)
<GridCube> cjwatson, yes i read that already, its data transference protocol, but what for?
<cjwatson> the ISO tracker's API
<cjwatson> e.g. getting the list of products, posting a new build, etc.
<GridCube> oh, so its not for users?
 * cjwatson is not in a position to say whether that's true or not :-)
<stgraber> Eventually yes, when the API is stable and documented
<stgraber> currently users can only list milestones and products, so not that useful
<stgraber> for alpha-2 I expect users to be able to push new results using it and be able to query quite a bit more (list of results, list of builds, ...)
<GridCube> mmhmm i see
<stgraber> at the moment we mostly use it to post new builds to the tracker (and that's a pretty restricted call ;))
<GridCube> it was weird to me because it was under "user profile"
<stgraber> ok, so http://91.189.93.73 is running with the latest import, I re-imported the daily testing results and my sanity check of the DB looks good. Guess it's time to e-mail the lists.
<GridCube> another question, when i click on my nick where it says "hello GridCube" it sends me to "Access Denied"
<stgraber> GridCube: right, everyone can set an API key, what you can actually access is then based on your rights
<stgraber> GridCube: oh, I guess I should fix that (remove the link probably). On a regular Drupal that'd send you to some settings page, but as we use Ubuntu SSO, that page is disabled.
<GridCube> oh, ok
<GridCube> so where do i store the specs under the test was done? on a comment of the results? (like we use to do anyway?
<GridCube> XD
<GridCube> also its not possible to report test results that are "not" current? if i download an image and test it and when i go to report it it has changed, i cant report it?
<stgraber> GridCube: at the moment, I'd recommend storing the specs in the comment as the hardware specs is one of the feature that's disabled for alpha-1
<stgraber> GridCube: the tracker doesn't allow users to report results for superseded ISOs. If you're sure it'll affect the new version too, just report it against it and mention it in the comment field
<GridCube> stgraber, :) thanks
<GridCube> that sounds rasonable
<GridCube> sorry for being such a bother
<GridCube> :)
<pitti> Daviey, jibel: do you know whether the i386 server failure on https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/job/precise-server/lastFailedBuild/#showFailuresLink is a bug in the tests or an actual problem with the ISO?
<jibel> pitti, this is a bug with the test
<jibel> error: Failed to define domain from /var/lib/ubuntu-server-iso-testing/tests/b9fce8d5-8542-451f-94c0-8212bc3138b6/libvirt.xml
<jibel> the iso is good
<jibel> first time I see this error
<pitti> jibel: for example, the mysql one had some new unexpected default databases, presumably due to the migration to 5.5; but it's curious that this doesn't affect amd64, too?
<pitti> jibel: also, how far do the desktop/alternate tests go? do they just end at successful termination of the installer, or do they also check that the installed system boots into a desktop?
<jibel> pitti, the system is rebooted, then it runs some post installation tests, like checking that FS is RW, permissions of the encrypted home, if it's an LVM install that LVM is mounted properly.
<pitti> jibel: nice!
<jibel> one of the objective of this cycle is to extend the number of tests run post install.
<pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/ is indeed quite fast
<pitti> I mean with running and reporting the tests after new ISOs appear
<pitti> o_O I was going to ask you why i386 OEM was shown as failed, but I can't find info in the details; reloading https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/ now shows it as passed
<pitti> anyway, so much the better :)
<jibel> indeed, it could be improved if we used unsafe-io and tmpfs. The current bottleneck is disk and we can run only 8 to 10 tests at the same time.
<jibel> desktop installed failed because of the bug we talk about last friday.
<pitti> ah, so it was re-run and then succeeded?
<jibel> yes
<jibel> I did a test over the week and ran a desktop installation in a loop 20 times. 50% of the tests failed with an 'Invalid argument' error
<jibel> I did the same with an Oneiric image, and there was no failure.
<jibel> *week end
<pitti> ah, same host platform, I assume?
<pitti> so supposedly some kernel change
<jibel> same environment, same image and nothing else was running on the test env.
<jibel> right, I'll move it there and ask the kernel team to have a look.
<jibel> pitti, another user reported the same failure but with vbox on a mac.
<jibel> I have no report of this error on hardware yet.
<pitti> I just finished a successful install in kvm, but I might just have been lucky
<pitti> jibel: was this ever reproduced on a host running the precise kernel?
<jibel> pitti, not tested.
<pitti> (that's what I tested just now)
<pitti> jibel: I suppose you use virtio?
<jibel> pitti, yes
<pitti> I just did a 10000 times loop of copying /bin/bash to the mounted /dev/vda1, and it works fine
<pitti> I'll try installing the lucid kernel and booting the image in kvm when running that
<cjwatson> jibel: d-i uses unsafe-io for itself; maybe ubiquity should too ...
<cjwatson> at least if it just created the filesystem for itself and isn't working on an existing one
<pitti> jibel: just commented on the bug, seems I can't reproduce this :( having luck when not asking for it, I guess
<pitti> jibel: it could be worth a try if it also happens when using -hda instead of virtio, that should have fewer requirements for the involved kenrels
<pitti> that might be a good enough workaround for now
 * cjwatson moves *-mismatches generation to lillypilly
<cjwatson> Daviey: if you'd like to work on integrating component-mismatches-mir-track into component-mismatches proper, it's in lp:ubuntu-archive-tools now
<cjwatson> it's still not very nice code but I've cleaned it up quite extensively
<Daviey> cjwatson: oooo!
<Daviey> cjwatson: I'll do that.
<Daviey> cjwatson: I didn't realise you were looking at, component-mismatches-mir-track .. but the code that produces that is not suitable for open sourcing :)
<cjwatson> I wasn't, but you mentioned it a while back and I remember you wanting to get access to the underlying c-m code
<cjwatson> and I'd generally like to encourage efforts to improve those reports
<Daviey> ah, right
<cjwatson> jibel: hm, what's https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_encryptedhome/lastFailedBuild/ about?  the d-i syslog is empty
<jibel> cjwatson, the failure is the 'Invalid argument' error. syslog is empty because there's a bug in the framework and the output is not redirected to the log file on the host as it should be. I'll fix that.
<Daviey> cjwatson: lillypilly only has i386 and amd64 archive, right?  How is powerpc, armel and armf being checked?
<cjwatson> jibel: where is that error displayed?
<cjwatson> Daviey: lillypilly:~ubuntu-archive/mirror/ has dists/ for all architectures
<Daviey> ah, sneaky
<Daviey> thanks
<cjwatson> I got IS to poke some rsync holes for me
<Daviey> heh
<jibel> cjwatson, in the VM's syslog.
<cjwatson> I can't see that in the build artifacts?
<cjwatson> oh, "the output is not redirected to the log file on the host as it should be"
<cjwatson> ok
<knome> cjwatson, does example-content still ship *buntu* logos?
<cjwatson> knome: no idea
<cjwatson> I only ever do drive-by work on example-content
<knome> okay, who should i contact?
<cjwatson> I don't know - desktop team maybe? </flails>
<knome> mhmm
<stgraber> good morning
<infinity> Can't prove it.
<ogra_> mine was good ...
<ogra_> (for the statistics)
<infinity> So, who feels good about me uploading a new eglibc 3 days before A1?
<ogra_> o/
<ogra_> wouldnt be exciting without such uploads
 * infinity smirks.
<ogra_> well, we just found that our omap3 images arent working without a new kernel upload
<infinity> Good, then I'll get my armhf omap kernel too!
 * ogra_ loves the pre-milestone excitements and surprises
<infinity> Since apw committed the fix for that.
<apw> ogra_, whats up with -omap3, if leann aware?
<infinity> apw: Broken display driver, just came up.
<ogra_> apw, not sure, ppisati just discovered it ... seems there is a completely new display driver on omap
<ogra_> which is in our source but not enabled in the config
<ogra_> so its a simple config change =m to =y i think
<apw> god we should just throw arm out of the kernel :)
<ogra_> haha
<infinity> apw: *glare*
<infinity> apw: We're kinda trying to head in the other direction. :P
<apw> don't i know it
<apw> ogra_, is this omap4 ?
<ogra_> apw, sadly not
<ogra_> omap3
<apw> bah
<ogasawara> skaet: ^^ there's a patch to resolve the above omap issue but it will require a new kernel upload
<ogasawara> skaet: want to get your ack before uploading
<skaet> ogasawara, would be nice to have omap3 working for alpha1 for a change,  any other side effects?
 * skaet just reading the comments from oneiric's alpha1 about omap3...
<ogasawara> skaet: it's only a config change and only affecting arm, so shouldn't have other side affects
<ogra_> uuuh, dont !
<ogra_> :)
<skaet> ogra_, ...?    seriously??
<ogra_> i mean dont read the 11.10 comments :)
<skaet> *whew*
<ogra_> thats just depressing
<skaet> thanks for the head's up ogasawara,  go ahead then.
<ogasawara> skaet: the patch has been tested too -> https://lists.ubuntu.com/archives/kernel-team/2011-November/018002.html
<skaet> pitti ^^ fyi.
<ogasawara> skaet: thanks
<ogra_> skaet, thanks :)
<pitti> skaet: thanks for the ping
 * pitti will be gone now, Taekwondo time
<skaet> bye pitti,  have fun.
<infinity> skaet: FWIW, I'll be making an eglibc upload later today with similar "only affects ARM" properties.
<infinity> skaet: In fact, should be "only affects armhf", which is clearly not even part of Alpha 1. :P
<skaet> infinity,  if it only affects armhf,  what's the impact of it waiting until after alpha 1 is out?   eglibc does tend to have a fairly wide impact...
<cjwatson> it'd slow down the armhf bootstrap
<cjwatson> AIUI it's critical-path for it
<infinity> ^
<skaet> infinity,  if it only affect armhf, ack then.   Thanks for the head's up.
<skaet> infinity,  will it be able to land before 2100 UTC?  (soft freeze)
<infinity> skaet: In 4 hours?  Maybe, but I wouldn't hold my breath.  Still running through some test build mojo to make sure it's sane.
<infinity> skaet: More likely to land tonight my time, so several hours past freeze.
<cjwatson> eglibc isn't one of the packages that causes trouble if it's out of sync across architectures, at least
<infinity> Nope.
<skaet> infinity,  having troubles interpreting that Nope...  are you agreeing with cjwatson?
<infinity> skaet: Yeah.
<infinity> Sorry, I've been awake for $way_too_long, not very verbose.
<skaet> infinity,  please see if you can avoid the autobuilding,   or coordinate it with pitti if it gets that late.   Would like to make sure we get a clean set of initial images if possible.
<skaet> since we'll be testing out using the new iso tracker, and would like to try to keep the churn factors down.
<cjwatson> last armel build time was 5h35, other arches well under that
<infinity> Yeah, there's not much hope of squeezing in before the next armel builds.
<skaet> infinity, ping me or pitti then when its ready, and we'll see what best options are then.
<stgraber> skaet, pitti: btw, I mentioned during the release meeting that you can now leave notes on a per-build basis, that feature is fairly well hidden in the admin UI. If you want to do so, you'll need to go in Administration, then Builds and click on the version number in the right most column.
<infinity> skaet: Mmkay.
<skaet> thanks stgraber
<stgraber> skaet, pitti: if the build you want to change isn't in that column, you'll have to manually tweak the URL to include the right build ID
<stgraber> I guess I'll need to get myself a work item on making the admin UI a bit more consistent and potentially move all of the admin stuff in the admin UI instead of having admin actions in the user UI too
 * skaet likes consistency
<micahg> is alpha 1 freeze at 2100?
<stgraber> skaet: CCed you on a RT ticket (upgrades using update-manager being broken because of extras.ubuntu.com not containing precise). Not sure what our expectations are for upgrades from Oneiric to Precise for alpha-1
<stgraber> if you think it's critical that it works, you may want to poke IS about it (deej is having a look at it now) :)
<skaet> stgraber, thanks.
<skaet> micahg, yes 2100 is alpha1 softfreeze.   One known exception.
<stgraber> skaet: RT #49544
 * micahg rushes to upload chromium before the freeze
<pitti> skaet, infinity: so I guess I'll kick off a complete set of images tomorrow, after checking that the kernel and eglibc have built (although we don't really need to wait for eglibc, I guess)
<pitti> skaet, infinity: FTR, cron jobs disabled, will use the optimized pipeline tomorrow
<micahg> skaet: can I have 10 or so extra minutes to get chromium in, just waiting for a test build to complete?
<skaet> pitti,  ok.    If I kick off a set with just the kernel in it,  I'll let you know.
<skaet> micahg, yes,  would rather you get it in tested.
<micahg> skaet: oops, looks like this isn't going to happen, build failed, so I guess this update won't be in alpha 1, was for a minor regression + minor security issue, so no biggie
<pitti> skaet: ah, so you reached mvo
<skaet> micahg,  ok.   Thanks for letting know.  :)
<skaet> pitti,  yup.
<cjwatson> skaet: #ubuntu-devel conversation with hallyn - we're going to need a qemu-kvm upload in the freeze, since it's uninstallable on non-i386
<skaet> cjwatson,  thanks.   understood.
<tumbleweed> skaet: can we clarify that announcement, saying that non-seeded packages in universe aren't affected?
<skaet> tumbleweed,  good point,  I'll clean up the wording next time, and post a follow up now.
<tumbleweed> thanks
<micahg> technically, unseeded main packages also shouldn't be affected
<micahg> err, I meant non-image based main packages...
<stgraber> micahg: right, skaet's follow up e-mail reflected that
<stgraber> micahg: "Just to be clear - this soft freeze is only for seeded packages in main
<stgraber> and universe."
<stgraber> ah, you mean, seeded but not on media packages?
<micahg> right, i.e. in the "supported" seed :)
<micahg> but that's just me splitting hairs :), I don't expect it to impact anyone
<stgraber> "This soft freeze is only for seeded packages in main and universe that are shipped on one of our media (sorry, we don't really have a list of these)"
<stgraber> would have been more accurate, but the, we don't really have a list is a bit annoying :) (you can get it from the manifests but that's quite a bit of parsing to do)
<micahg> stgraber: well, not precisely (pun intended), build-deps for those packages would be included, just not stuff that's officially "supported", but not on media or related to building media based packages
<stgraber> oh, right, build-deps ;)
 * skaet will work on the wording to be a little clearer for alpha 2,  but doesn't think folk want to check lists of packages.  ;)
<stgraber> skaet: hehe, maybe Launchpad should just be aware of soft-freezes though we'd still have to maintain a package list... don't think it's worth the time at this point
<tumbleweed> skaet's wording was definitly better than mine :) But I'm mainly concerned about newish people working on universe who don't know how these things work yet. We expect core-devs to understand freezes :)
<Daviey> Can we paint it green please?
<micahg> skaet: no, what you put is fine, I'm just splitting hairs (it's only probably about 10 or so packages that would be included in the difference, I'm just causing trouble :))
<skaet> Daviey,  lol.   Am working on colors for the ReleaseSchedule right now - that's enough coloring for me.
<skaet> micahg, :)
<Daviey> skaet: You might need to setup a colour council to evaulate our options.
<stgraber> Daviey: :)
<skaet> Daviey, LOL.
<skaet> Daviey,  I did consider getting some of the usability team to evaluate my selections, but figured the only criteria I got from the UDS meeting was it had to be readable,  so figured there was a bit of freedom to JFDI.
<stgraber> skaet: readable from 30ft on a projector screen seems to be the criteria
<skaet> stgraber,  thank you for the clarification.  :)
<stgraber> I'm pretty sure Aubergine on Ubuntu Orange doesn't qualify so I'd just skip the ubuntu colors for that one :)
<skaet> :)
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseInterlock
<stgraber> should be readable, the yellow-ish background may appear as white on some projectors but at least the text will be readable
<skaet> goodness.   criteria met!
<skaet> ...or at least until I find a projector and test it properly.  ;)
#ubuntu-release 2011-11-29
<stgraber> skaet: do we want tonight's daily to be considered as candidates? (if so, I'll need to enable the milestone and someone will need to change the config on the CD image builder)
<skaet> stgraber,   pitti turned off the cron,  so please go ahead and enable the milestone.   The next set of builds should probably be posted.
<stgraber> skaet: ok, do you want the daily milestone completely gone from the UI or just read only (marked as released)? (I guess it depends if you want to make it easy to see the current daily results)
<skaet> stgraber,  I'm tempted to hide it to keep the confusion to a minimum,  but think it should be jibel's call.    Make it read only for now,  and lets see what he says tomorrow.
<stgraber> skaet: done
<skaet> Thanks stgraber. :)
<stgraber> pitti: when you start building, just set milestone to "Precise Alpha 1" in ~/.isotesting.conf
<cjwatson> ~/.isotracker.conf actually
<cjwatson> stgraber,pitti: I've gone ahead and done ^- that now
<stgraber> ah, right, isotracker.conf. Thanks
<infinity> pitti: Does your ddeb-scraping mojo handle armhf?
<infinity> pitti: Cause... We're building. ;)
<infinity> pitti: And I have a hello-debhelper.ddeb for you. ;)
<skaet> infinity,  \o/
<wgrant> And now we wait...
<infinity> And I keep sneakily seeding in more and more manually bootstrapped stuff to the stage-2 archive...
<infinity> skaet: Almost done my testing here to feel good about that eglibc upload.  It'll definitely be "before I got to bed".
<skaet> infinity,  coolio.   good to hear.
<micahg> ooh, armhf, pretty
<pitti> good morning
<pitti> stgraber: noted for next time
<pitti> infinity: not yet, hang on
<pitti> infinity: eek
<pitti> IOError: [Errno 28] No space left on device
<pitti> infinity: so much for mopping up the new armhf ddebs :(
<infinity> pitti: Erk.
<pitti> a few weeks ago I already killed some 60 GB worth of maverick ddebs
<infinity> pitti: Is that on your ddebination machine, or a buildd?
<pitti> infinity: on macquarie, aka ddebs.u.c.
<pitti> not the builders
<pitti> but this now hosts the shop, ddebs, langpacks, etc.
<infinity> Ouch.
<pitti> and video.u.c.
<infinity> video is likely the culprit...
<pitti> /dev/sda3             537G  529G  2.7G 100% /
<pitti> well, ddebs are huge, too
<infinity> But you might want to put in an emergency call to IS before ddebs start disappearing from the buildds.
<infinity> (I gave you 7 days or something, didn't I?)
<pitti> right
<infinity> It's been a while since all that insanity was written.
<pitti> "nothign lasts longer than a stopgap solution"
<pitti> I could also kill natty ddebs
<pitti> but I'll file an RT first and whine in #is
<pitti> but first I kick off a1 image buildls
<infinity> Killing ddebs for releases we support really seems suboptimal.
<infinity> Oh, thanks for the reminder that I need to upload eglibc and screw with your Alpha1. ;)
<infinity> (It shouldn't screw with anything)
<pitti> yes, it's the last resort indeed; I wasn't too attached to the maverick and powerpc ones, but it's still a pity
<pitti> (we stopped collecting powerpc altogether)
<infinity> ...
<infinity> Yeah, also not happy about that. :P
<pitti> ok, all builds are running, and shoudl auto-post
<pitti> noted so in the pad
 * infinity uploads eglibc, as promised earlier...
<tumbleweed> meh, I was just asking for more stuff to be put on video.u.c
<infinity> Those two services might need different machines. :P
<infinity> Or to be moved to the NAS.
<infinity> SAN?
<infinity> I can never remember.
<infinity> One of those.
<infinity> I propose "NASAN" to end the confusion.
<pitti> hm, so ddebs.u.c. weighs 308 GB
<pitti> video.u.c. is just 27 GB
<infinity> So, where's the other 200?
<tumbleweed> video.u.c is about 20G out of date (probably more)
<infinity> langpacks?
<pitti> that's also quite heavy
<pitti> but there's also a mirror on there
<pitti> and shop. and uds.
<pitti> and bugs-mirror.d.o, debzilla, and whatnot
<pitti> it's a "dump it all here" machine
<pitti> infinity: RT sent
<broder> :( is there any way i can slurp down the ddebs before you start purging natty ones? i still care about those
<infinity> pitti: I saw, thanks.
<pitti> I don't want to remove them today
<pitti> broder: I postpone armhf ddebs for the next 6 days (unless we get more space by then)
<pitti> broder: but in general, it's a standard archive layout, so debmirror should do fine
<broder> hmm, ok. now /me just has to go find 300G of spare space
<pitti> broder: no, 308 GB is the whole archive
<pitti> that is, {lucid,natty,oneiric,precise} x {i386,amd64,armel}
<broder> oh, ok. so probably 1/4 of that for natty or so?
<pitti> yes, or less if you only want one arch
<pitti> my "next against the wall" is natty armel, when it comes down to "now or never"
<pitti> http://91.189.93.73/qatracker/milestones/205/builds
<pitti> nice, images do appear
<broder> ok. i don't personally care about armel, so maybe i'll be ok :)
<pitti> âª It's a kind of maaaagiiiic â© â«
<pitti> err, desktop livefses are built in a mere 8 minutes now!?! wow
<pitti> our progress this cycle doesn't stop amazing me
<pitti> if it wasn't for powerpc ruining the performance, we'd have kubuntu built by now, too
<infinity> ppc will improve a bit "soon".
<jibel> skaet, I'l hide dailies during a1 testing to avoid confusion
<pitti> ah, thanks
<pitti> jibel: bonjour
<jibel> pitti, guten morgen
<pitti> jibel: is there a difference between the "Precise" and "Precise daily ISOs" views?
 * pitti figures it is currently autotesting the ubuntu desktops
<jibel> pitti, as far as I can see, there's not much difference. Precise = Precise daily ISOs + upgrades
<pitti> ah, upgrades and boot speed
<pitti> right, thanks
<jibel> right + boot speed
<pitti> jibel: maybe I'm just too impatient, but desktop amd64 have finished testing half an hour ago, but no sign of the i386 iso tests yet; not even a failed one
<pitti> or are other tests running in between?
<jibel> pitti, they crashed
<jibel> 'invalid argument'
<pitti> ah, so that wouldn't show up as a "fail"
<jibel> they will fail when the test will reach its timeout which is 60min
<pitti> ah, good to know
<jibel> I'll cancel the tests and run them again
<pitti> merci
<pitti> jibel: I'll try to find a simpler reproducer today, after I'm done with my current bug fix
 * tumbleweed kicks himself for not getting the aptitude + multiarch breakage into the oneiric release notes :/ I keep seeing people hitting it
<pitti> the "i386 on amd64" was a good hint, usually I'm using amd64 everywhere
<cjwatson> infinity: hmm, what's up with https://launchpadlibrarian.net/86161322/buildlog_ubuntu-precise-armhf.net-snmp_5.4.3~dfsg-2.3ubuntu2_FAILEDTOBUILD.txt.gz ?
<infinity> cjwatson: sbuild patch incoming.
<pitti> oh, a cj "I ought to be on holiday" watson!
<pitti> good morning
<jibel> pitti, thanks. jsalisbury is on the case too.
<infinity> cjwatson: base system dpkg doesn't know about armhf.  Fixing sbuild to use the dpkg-architecture in the chroot seems saner than trying to upgrade dpkg in every past release that's running on all the buildds.
<cjwatson> I am on holiday, I've just been rousted out of bed in order to make a trip to the doctor's surgery, and IRC/mail is a good way to wake up
<cjwatson> infinity: ah, good, yes
<cjwatson> that makes everything fail to build, yes? :)
<infinity> cjwatson: No, just anything with "Architecture: any all" and anything with "foo [linux-any]" style build-deps.
<cjwatson> ah, ok, not quite the whole world then
<infinity> cjwatson: No, just large portions of it. ;)
<mvo> is it ok to upload a new update-manager and software-center today (asking because of the soft freeze)
<pitti> mvo: what's the nature of the changes there?
<mvo> pitti: for u-m its merging back the recent security and some minor fixes, for s-c mostly the addition of the system-wide license key support
<mvo> pitti: I can wait with the s-c upload as it will also bring in a new dependency (software-center-aptdaemon-plguins)
<pitti> mvo: u-m sounds fine, please go ahead
<pitti> for s-c, I agree, let's wait until after a1
<mvo> thc
<mvo> ups, thanks
<pitti> that'll need an MIR?
<pitti> oh, source/bin NEW
<mvo> I guess, but its really part of s-c itself, its just the twisted setuptools that made me split it into its own package
<pitti> yeah, MIR should be trivial
 * mvo nods
<jibel> cjwatson, the logging issue with desktop tests is fixed, I'll update jenkins in the afternoon after Carlos review.
<pitti> jibel: so the i386 desktop tests worked now, nice
<jibel>  pitti , yes, just need to run it 2 or 3 times. this bug is painful. I can't reproduce it on HW which is good news.
<cjwatson> jibel: thanks
 * pitti retries the xubuntu daily, there's no obvious reason for the bzr branch checkout failure (checked with #bzr)
<pitti> looks like a glitch
<cjwatson> that looked like temporary network trouble to me
<pitti> cjwatson: right, that's what I hoped; and there it is
<pitti> (i. e. both buildds succeeded)
<wgrant> pitti: What time was it?
<wgrant> LP was down from 0831-0832ish.
<pitti> From cdimage@nusakan.canonical.com  Tue Nov 29 09:28:58 2011
<pitti> wgrant: so, could be
<wgrant> Hm.
<nigelb> pitti: the builds should go make tea when LP is down (I think the package importer had a bug for that)
<debfx> can I upload kde-workspace to drop kde-wallpapers (~40 MB) from the kubuntu image again?
<pitti> fine for me
<jibel> bug 897680
<ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "12.04 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/897680
<pitti> jibel: thanks
<skaet> pitti,  good morning
<pitti> hey skaet
<pitti> FYI, we have two reasons for respinning, see pad
<skaet> pitti,  looks like iso tracker is up, bugs getting reported, all flowing as it should,  will look at the pad now.
<skaet> pitti, re: libc one, ouch.   Do we need to find someone to help figure it out, or are you looking into it.
<skaet> ?
<pitti> skaet: mterry is looking into it for now, but I'll also have a look
<pitti> I spent most of the day on bug 894768 and bug 893826
<ubot4> Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 5) (dups: 4) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/894768
<ubot4> Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) (and 3 other projects) "symlinked docs are different between architectures, depending on dpkg-deb package order (affects: 19) (dups: 17) (heat: 172)" [High,Fix released] https://launchpad.net/bugs/893826
<pitti> skaet: I need to run out for a bit, but we'll continue to look into this
<cjwatson> pitti: I left a comment explaining bug 897680
<ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/897680
<cjwatson> judging from the archive, a respin with no changes should fix that
<cjwatson> I mean with no further uploads
<skaet> cjwatson, mterry - thanks.   :)
<pitti> cjwatson: oh, splendid
<skaet> pitti, so language selector appears build and published, kick off the respins?
<pitti> skaet: looks like it then
<skaet> :)
 * skaet looking forward to seeing this new stuff in action
<pitti> skaet: it's great
<pitti> I basically just did the image commands on nusakan, and posting and smoketesting happened fully automatically
<stgraber> good to hear nothing exploded :)
<pitti> so 897680 affects all desktops/DVDs
<pitti> so we can keep kubuntu alternate, server, and core
<skaet> won't language selector be needed for those?
<pitti> right
<pitti> skaet: ah, misinterpreted as "for the rebuilds"
<pitti> skaet: the language-selector crash only affects the -gnome flavour
<skaet> heh,  time for me to do some learning,  I was seeing the other binary packages built by this source, and figuring the scope was larger.
<pitti> skaet: ok, all builds running; had to wait for a bit with the alternates for l-s
<pitti> let the magic do its work
 * pitti really needs to run out now, bbl
<skaet> thanks pitti,  l8r
<skaet> stgraber,  where should the comments be in the tracker about the reason for the rebuild?
<stgraber> skaet: they'll appear at the top of a build page (testcase list, result list, download information, ...) in the notice board.
<skaet> stgraber,  am not seeing anything about the current rebuild there right now,  does the reason need to be manually added?
<stgraber> skaet: yes, someone to update it. It can be updated from the admin UI or when adding a new build (from either the admin UI or the API).
<skaet> stgraber, ok,  we'll need to make that explicit.   Let me try now.
<stgraber> I think the best would be to have that note be on nusakan and automatically pushed through the API when the new builds are ready. This way it'll get included in the notification e-mail.
<stgraber> so instead of saying why something is being rebuilt (that needs manually updating from the admin UI and won't notify the testers by e-mail), we tell them what's different when the new build is announced
<skaet> stgraber,  yeah that seems like a better flow.
<stgraber> cjwatson: do you want a patch for that one ^ (basically passing the content of a file to the note parameters of builds.add, currently set to '')?
<scott-work> skaet (and probably stgraber) if it's not too much trouble i would prefer not to publish and test the ubuntustudio alpha 1 image since there really isn't much difference from oneiric
<skaet> scott-work,  no trouble and your call,   we'll remove them from the alpha-1 list then.
<skaet> pitti ^ ubuntu-studio removed (but may reappear from your rebuilds).
<scott-work> skaet: would you prefer such a notice earlier?  is it bad form to ask this close to alpha1?
<skaet> scott-work,  earlier the better.  :)   I'll have the ReleaseImageContacts page sorted out soon,  and you can just indicate the milestones you want to participate in on there.
<scott-work> i'm creating a project lead/team "playbook" for ubuntu studio parsed by milestone that lists required activities and i'll place this in there as well
<cjwatson> stgraber: sure - if we want it for a1 get somebody else to review/apply/deploy it though, I'm not really here :)
<stgraber> cjwatson: oh right, I forgot you're not supposed to be around today ;)
<mterry> Hello!  Is bug 897380 important enough to break soft freeze for?  Debdiff in the bug
<ubot4> Launchpad bug 897380 in imagemagick (Ubuntu) "PerlMagick fails at runtime in precise (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/897380
<stgraber> pitti: that's the change to isotracker_xmlrpc.py I mentioned before: http://paste.ubuntu.com/753813/
<stgraber> pitti: then if present ~/.isotracker.note will be sent to the tracker, included in the notification e-mails and displayed in the header on the site
<pitti> stgraber: ah, thanks
<skaet> mterry,  change seems small,  not sure we'll respin for just it,  but if we need to respin for something else,  it wouldn't hurt to have it in I think,   pitti - feel free to disagree.  :)
<pitti> mterry: looks fine to upload
<mterry> k
<SpamapS> hmm seems amarok missed the libmysqlclient transition sweep..
<debfx> SpamapS: I've uploaded amarok yesterday, what's missing?
<SpamapS> hm never mind, its good
<SpamapS> for some reason my system showed it still needing libmysqlclient16
<debfx> SpamapS: do you know why mysql-client-core-5.5 gained so much weight compared to 5.1 (+ 6.5 MB installed size)?
<SpamapS> debfx: I don't, but I'll look into it.
<debfx> thanks
<SpamapS> debfx: I'm going to guess cmake has had a hand in this evil ;)
<SpamapS> debfx: doh!!!
<SpamapS> debfx: libmysqclient is statically linked in
<debfx> nice
 * SpamapS curses cmake
 * SpamapS also curses mysql's source release engineering.. or lack thereof
<nigelb> heh
<pitti> skaet: so, new builds trickle in and get properly auto-posted
<pitti> and jenkins jumps at them and tests them, too
<skaet> pitti,  i'm seeing,  and beeing delighted.   MUCH MORE EFFICIENT!
<pitti> you bet!
<pitti> skaet: can you take it from here?
<pitti> the fix for bug 897680 should be confirmed
<ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/897680
<pitti> but otherwise I'm not aware of outstanding blockers
<pitti> jibel mentioned OEM mode being slightly broken
<skaet> pitti,  let me check a couple of things quickly (ie. access is working ok0
<pitti> but that sounds like something we could document
 * skaet nods re: OEM stuff
<pitti> precise-desktop-i386_oem didn't re-test, I suppose it's another victim of the EINVAL bug
<pitti> so jibel or someone else needs to poke this to have it re-run
<pitti> but I can't do that eitehr
<utlemming> Cloud images are being respun -- eta is 22:00 UTC
<skaet> thanks utlemming
<skaet> pitti,  ok,  access check out.   I've got it for now.    Have a good evening.
<pitti> cool, see you tomorrow!
<pitti> skaet: will you remove the "rebuild in progress.." note from the tracker once all images are back in?
<skaet> pitti, yup, was planning on doing it after the last one landed.
<Daviey> skaet: currently cloud images for Alpha 1 do not boot in kvm or openstack.  The fix has been identified, but would require a kernel upload.
<Daviey> For alpha 1, I'm not sure it's worthy of a new kernel, unless one is needed for another reason.
<Daviey> ogasawara said that they can have a fix queued for upload as soon as you thaw the freeze, and we can have functional images 4-5 hours later.
<smoser> the -virtual kernel is never selected by the installer, is it?
<Daviey> no, not afaik
<smoser> i did not think so, but cjwatson would know. if it is, then this is more serious as it would affect all vm install.
<skaet> Daviey,  yup, was following in release channel.    Having it uploaded and ready in case we respin would make sense.    Do we want this just for the cloud images, or for all of them?
<smoser> or some subset of vm install.
<smoser> the -virtual kernel is not on the media so it would not affect ISOs i would not think.
<Daviey> skaet: it's the virtual kernel flavour which only makes sense on kvm/xen/cloud
<skaet> thanks smoser,  Daviey.
<skaet> Daveiy,  if its only for the virtual kernel, then yes, I'm fine with the timing you and ogaswara recommend.
<Daviey> skaet: In perspective, this is Alpha 1.  I'm really excited about rushing around to get this solid.  It's a benchmark in the cycle, and we have caught the fix that can be release noted.
<Daviey> smoser feels it's more pressing
<smoser> i feel that a -virtual kernel that is not useful in a virtual environment is a significant issue.
<smoser> but we would be running around like a chicken for 20 hours probably to get it fixed.
 * skaet scratches head over Daviey's comments "I'm really excited"... did he mean "I'm really not excited"?
<bjf> does QA use the -virtual kernel for any of their testing ?
<skaet> bjf,  good point.
<skaet> jibel, ^^
<smoser> the primary benefit to me is having alpha1 images that booted in openstack so we can later compare something against a known quantity.
<ogasawara> bjf: I'd guess no, if we're just seeing this now.
<smoser> if the image doesn't boot, then we can't do that.
<bjf> ogasawara: i agree, but i wanted to make sure
<smoser> ogasawara, i would also guess 'no', but we will be getting there with openstack testing. automatically testing latest images.
<smoser> but even if we were, we found this pretty soon after it landed in the archive.
<Daviey> skaet: yes, really not
<Daviey> I can confirm that precise worked for me on sunday, under kvm/openstack
<tgardner> Daviey, wouldn't that have been a 3.2 kernel ? It should have had the same issues.
<skaet> interesting,   we did pick up a new kernel but it should have been unrelated I would have thought.
<ogasawara> Daviey: which version?  the last upload we did was on Friday. but the 3.2 kernel we've had uploaded and in the archive for a while now.
<ogasawara> Daviey: correction, the last upload was yesterday, but that was only a config change that affected arm.
<Daviey> ogasawara: hmm, that doesn't make sense
<tgardner> ogasawara, when did you upload meta ?
<ogasawara> tgardner: apw uploaded meta yesterday?
 * ogasawara checks
<tgardner> ogasawara, I was just wondering when the 3.2 kernel might have actually been referenced.
<smoser> the last thing know i've booted in kvm with networking was from the 22nd.
<Daviey> Hmm, seems i am on 3.1 kernel
<smoser> ok..
<smoser> so another option we could pursue here is to respin cloud-images with a one time inclusion of 'linux-image-extra-virtual'
<ogasawara> smoser, Daviey, tgardner: yep the first 3.2.0.1.1 linux-meta package was uploaded on Nov 23
<smoser> which woudl get us the necessary modules. and i've verified that that gets me a booting system.
<smoser> it comes at a cost of 87M (per apt) of modules that we've not had before.
<Daviey> smoser: that wouldn't be removed on upgrades?
<smoser> well, if we added the meta-package, it would pull in the -extra for new kernels on upgrade.
<smoser> if we add just linux-image-extra-3.2.0-2-virtual, then we'd only get it for that kernel.
<smoser> i dont think *anything* (kernels) get deleted on upgrades
<tgardner> smoser, that true. besides, its a development problem. what a few extra MB ?
<smoser> at the moment i'm leaning towards that hack solution.
<ogasawara> smoser: +1
<smoser> as it limits the people who are running around like chickens without a head.
<tgardner> I resemble that remark.
<ogasawara> heh
<smoser> and i'm thinking to just add the linux-image-extra-3.2.0-2-virtual also so that upgrades wont get the -extra.
<ogasawara> smoser: yep, sounds good
<ogasawara> smoser: we can still have the official fix queued and I'll immediately upload upon Alpha1's release
 * skaet nods
<Daviey> smoser / ogasawara / tgardner: As long as it is removed on upgrades, works for me
<smoser> it wont be removed on upgrades.
<ogasawara> Daviey: it won't be removed on upgrades
<smoser> kernels are never removed on upgrades
<Daviey> then it sucks as a hack.
<smoser> (it matches linux-image, so it would not be).
<smoser> no more so than kernels are a hack.
<smoser> :)
<Daviey> i'd rather we defer the cloud image release by 24 hours TBH.
<tgardner> Daviey, I think smoser's hack would only apply to one kernel. The next ABI bump would be back to normal.
<smoser> right. you'd only get -extra on upgrades from alpha1 cloud images for that kernel.
<smoser> the 2 things that will suck about it that i can think of now are
<smoser> a.) 87M of wasted space (i'm not concerned about that)
<smoser> b.) you would not know that othe rmodules you needed are not going to be there later
<smoser> if someone is actually upgrading all the way to release from alpha1, they're going to have work around worse than having to 'apt-get --purge remove linux-image-extra-*'
<smoser> Daviey, ?
<Daviey> sure
<GrueMaster> stgraber: The links to images on the new tracker are off for all of armel & core.  Neither have "iso" files.
<stgraber> jibel: ^ (want me to fix that?)
<GrueMaster> I take it back.  Looks to be core only.
<stgraber> ok, if it's only core I can just fix them by hand now
<GrueMaster> http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.iso should be http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.img.gz (or whatever after the rebuild).
<GrueMaster> ac100 is perfect.  Has both the bootimg & rootfs tarball linked.  That is excellent.
<stgraber> GrueMaster: looks like ti affects desktop armel mx5 as well
<stgraber> ah right, just read backlog :)
<stgraber> so my query seems to match your list, good, fixing that now
<GrueMaster> I'm double checking the links now.  Core and desktop-armel+mx5 are the only ones so far.
<stgraber> qatracker=> SELECT DISTINCT qatracker_product_download.filename, qatracker_product.id FROM qatracker_product_download LEFT JOIN qatracker_product ON qatracker_product.id = qatracker_product_download.productid WHERE qatracker_product_download.filename ~ '.iso' AND qatracker_product.title ~'armel';
<stgraber>                   filename                  | id
<stgraber> --------------------------------------------+-----
<GrueMaster> omap/omap4 both look good.
<stgraber>  precise-preinstalled-desktop-armel+mx5.iso | 229
<stgraber>  precise-preinstalled-core-armel.iso        | 220
<GrueMaster> precise-preinstalled-core-[armel|amd64|i386] all should be .tar.gz.
<stgraber> GrueMaster: ok, I think I got them all
<stgraber> GrueMaster: can you also confirm that it's only the ac100 that requires a separate boot image?
<GrueMaster> Yes, it is at the moment.  Not sure what the future may hold if we can get more community enabled platforms.
<GrueMaster> We'll cross that when it happens.
<stgraber> good, just wanted to make sure I didn't forget any
<stgraber> GrueMaster: there you go for an ac100 image: http://91.189.93.73/qatracker/milestones/205/builds/7250/downloads
<stgraber> oh, interesting, seems like the table title is wrong, fixing that now
<stgraber> fixed
<GrueMaster> Excellent!
<GrueMaster> Now I just need to figure out the best way to test core images.  Was thinking lxc, but may just use chroot for now (less confusing and quicker).
<stgraber> GrueMaster: want an lxc one liner to start them?
<stgraber> (testing the idea on my panda quickly)
<GrueMaster> If you have one, that would be cool.  Need to be able to control on i386 & arm ideally.  I'm creating a jenkins job here now.
<stgraber> GrueMaster: looks like I have something that works (not exactly one line, but one script), just re-running to test, forgot how bad my panda is at I/O :)
<stgraber> currently using it as a mediacenter with xbmc using a network drive so I only really notice when messing with the system :)
<GrueMaster> My pandas are all running off USB-Sata, so I can get a little better performance.
<stgraber> GrueMaster: so that's what it looks like http://paste.ubuntu.com/754014/ and the script (prepare.sh) is http://paste.ubuntu.com/754015/
<stgraber> GrueMaster: you'll probably want to change some bits to make it entirely automated
<stgraber> but at least it unpacks, it boots and it shuts down
<stgraber> lxcguest is currently required so that mountall plays nice but we plan on fixing that this cycle so any regular Ubuntu system can boot in LXC without modification
<GrueMaster> I'll also have to ass a step to run apt-get update and install a test package, but thanks.  Helps out a lot.
<GrueMaster> Erm.  Add a step (sorry).
 * skaet notes that everything has now been rebuilt except the arm image in less than 4 hours...  sweet. 
<micahg> now if we can just get the builders to work that fast :)
<bdmurray> How do the meta-release files get updated on changelogs.ubuntu.com?  I ask as I just fixed a mistake in one of them
<infinity> Oh, FFS.  I completely forgot about the freeze and uploaded mono.
<infinity> (armhf-only fix, not impact on other arches except for a version bump)
<infinity> s/not/no/
 * skaet hopes those are not famous last words....  
<Laney> Is mono still on images?
<infinity> Oh, there's that.  We may have removed it by now anyway. :P
<infinity> skaet: It added one symbols file with an extension of .armhf, if that breaks other arches, then mono was already broken. ;)
<skaet> :)
 * skaet doesn't rule this out,  but last touch rule applies ;)
<tumbleweed> Laney: mono-runtime still seems seeded for edubuntu
<infinity> Yeah, I don't look forward to all the TILM I'll end up with.
 * skaet hopes we won't need to rebuild then. 
<skaet> no blockers showing up so far this afternoon that anyone has pinged me about.
<infinity> A bit of archive/image skew on alphas isn't the end of the world anyway.  And if a rebuild needs to happen for some other reason, fresh mono for edubuntu for free. :P
<Laney> good, I'm glad edubuntu knows what's right :-)
 * infinity keeps the soft freeze in mind and stages the rest of his armhf fiddling locally.
<Laney> infinity: do you have a build log perchance?
<infinity> Laney: Of..?
<Laney> I would be interested to see if the situation has improved since debian bug 639342
<ubot4> Debian bug 639342 in mono "mono: please add armhf support [PATCH]" [Important,Open] http://bugs.debian.org/639342
<infinity> https://launchpadlibrarian.net/86215844/buildlog_ubuntu-precise-armhf.mono_2.10.5-1_FAILEDTOBUILD.txt.gz
<Laney> a successful one ...
<infinity> Laney: That would be successful if the symbols file was right.
<infinity> Laney: (Which is what I just uploaded to fix)
<Laney> thought you might have a local one
<infinity> Nein.
<infinity> Though I'm now wondering if I wanted that --with-fpu hack from the Debian bug...
<infinity> Maybe it cleverly autoselects.
<Laney> I'm not sure it will work. Upstream were talking about an armhf port the other day, which implies that mainline is not (fully) ported.
<infinity> Hrm.  Well, it fails a few more tests than armel, but not a lot.
<infinity> Perhaps I should do some local fiddling.
<infinity> I still suspect my upload will be enough to get it built and function as a build-dep.
<Laney> yeah, 'least we can test
<stgraber> hmm, wondering why Edubuntu still has mono, thought we got rid of that...
<Laney> boo
<Laney> do you have gbrainy?
<infinity> Laney: Going to do some local testing now.
<infinity> Laney: It's that or java, and mono being installable makes it win.
<stgraber> we shouldn't have it, we're based on the ubuntu desktop seed, so we should have lost tomboy, banshee and gbrainy at the same time Ubuntu did
<Laney> ok. vargaz in #monodev is your man btw.
<stgraber> oh, found it, pdfmod is probably the one pulling mono
 * Laney sheds a tear for good apps
<stgraber> we're currently in the position where we'll drop mono for 12.04 if we are the ones who end up having to care for it for the LTS (5 years). If someone else is going to take care of mono anyway (because of bindings or whatever), then we'll seed gbrainy explicitly as well as make sure we keep pdfmod and maybe bring back tomboy (not sure about that one)
<stgraber> (where we means Edubuntu)
<Laney> meh, we never got that much support from non-mono-team anyway
<stgraber> Laney: yeah, it's just that for LTS approval I have to give a list of source packages that aren't seeded and that we ship, we're expected to take care of these for the 5 years of the LTS
<stgraber> and my personal goal is to make sure we don't have mono, java or any programming language on that list :)
<stgraber> I'm fine supporting apps for 5 years, not programming language and hundreds of libraries (that last one is mostly for our java stuff ;))
<stgraber> anyway, I need to clarify that for our proposal to the TB (exact list of Edubuntu-specific packages, list of these that we'll support ourselves, mostly these that aren't in main and list of these that we'll try to drop somehow)
 * Laney thinks mono could be advertised to people being held on other operating systems by .NET apps as a route to migration
<stgraber> it probably could yes, not sure what's the state of mono's winforms support nowadays, used to work decently last I tried as long as you the app wasn't using weird widgets and all new .net features
<Laney> not pretty, but works quite well ime
<GrueMaster> Oops.  Login screens all show 11.10 for our Alpha 1 image candidate.  Not that I am advocating a respin or anything.
<stgraber> GrueMaster: not Edubuntu ;) I fixed that one on Sunday (it's a .png in the lightdm greeter theme)
<stgraber> though I didn't think Ubuntu was still showing 11.10 or I'd have fixed it or at least poked Robert about it
<GrueMaster> Well, it is on armel desktop.
<infinity> I assume we're not abnormal there.
<GrueMaster> Don't know about the x86 world.
<infinity> Unless we have an old version of the theme.
<stgraber>  /usr/share/unity-greeter/logo.png also says 11.10 on my laptop, so definitely not arm specific
<skaet> hmm,  sounds release notable, but should be fixed and picked up if we respin.
<Laney> is there a "things to change at new release opening" checklist?
<skaet> Laney,  https://wiki.ubuntu.com/NewReleaseCycleProcess - probably a good thing to add in the "First weeks" section.
<stgraber> doh, skaet was faster :) took me a while to dig that wiki page, should bookmark it
<Laney> yep
<Laney> i tried to google it but failed
<skaet> :)
<stgraber> yeah, both google and wiki search fail usually :) so I went to the releaseteam wiki page and looked from there
 * skaet is glad it gets some use.  ;)
#ubuntu-release 2011-11-30
<skaet> GrueMaster,  can you please open a bug, so we can reference it?
<skaet> :)
<GrueMaster> Will do (once I figure out a few other more pressing issues).
<stgraber> GrueMaster, skaet: one already exists
<stgraber> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/892394
<ubot4> Launchpad bug 892394 in unity-greeter (Ubuntu) "Greeter logo needs to be updated for 12.04 (affects: 2) (dups: 1) (heat: 16)" [Medium,Triaged]
<GrueMaster> thanks stgraber.
<skaet> stgraber,  just heard about it from robert-ansell as well.  you're faster this time.  :)
<stgraber> hehe
 * skaet --> heading for dinner, back later
 * GrueMaster adds the but to the armel images on the shiny new iso tracker.
<GrueMaster> bug
<GrueMaster> This bug is old.  Surprised it wasn't updated before A1.
<stgraber> yeah, really weird as it's an easy one (just a .png to update, took me a good 2 minutes for Edubuntu) and Robert commented on the bug (though only recently)
<GrueMaster> I could have fixed it, and I am not artistic by nature.
 * skaet not seeing any blockers so far on the iso tracker,  calling it an evening.
<ScottL> stgraber, are you the person i would talk to about which test cases are being shown for ubuntu studio on the qa tracker?
<ScottL> also, do you know who i would talk to about editing the instructions for the test cases?
<ScottL> the first sentence is referencing the 'entire disc with encryption'
<ScottL> the second sentence references the link from http://91.189.93.73/qatracker/milestones/205/builds/7263/testcases goes to http://testcases.qa.ubuntu.com/Install/AlternateResize, which doesn't mention jackd 'real time previliges'
<stgraber> ScottL: I can do changes on the tracker (rename/change testcases and make them point somewhere else), though it's probably best to talk to jibel about it as he's coordinating the testing and knows more about the right way of doing things :)
<stgraber> and jibel has the same rights as I do
<stgraber> oh, fun, looks like we just got a new empathy (new major version)...
<micahg> stgraber: I think we have to go back to grilling people about freezes in DMB meetings :)
<stgraber> micahg: yeah, that sounds like a useful thing to do ;)
<micahg> fortunately, it can't build since it requires clutter-gst
 * stgraber waits for someone to upload a new clutter-gst still during the freeze
<micahg> stgraber: not seeded, doesn't matter
<stgraber> ah, it build-deps on something new that needs to be promoted?
<micahg> stgraber: worse, build deps on something we said we wouldn't promote :)
<stgraber> hmm, ok :)
<stgraber> Maybe we should send a friendly reminder for people to subscribe and READ ubuntu-devel-announce?
<stgraber> it's not really high traffic and should be a must subscribe for anyone with upload rights
<micahg> really, I think ubuntu-devel should be required reading for devs with upload rights, but certainly ubuntu-devel-announce at a minimum
<stgraber> ubuntu-devel can be high traffic at times, you should at least know what threads are going on and ignore these you aren't interested in, but -announce should definitely be a must read
<stgraber> I guess I'll add that to be before-voting list of questions :) "are you subscribed and do you read ubuntu-devel and ubuntu-devel-discuss every day? (that's at least every day where you contribute to ubuntu)"
<micahg> speaking of...
<infinity> micahg: I might need educating on freezes, yes. ;)
<micahg> infinity: not you :)
<infinity> micahg: I dunno, my accidental mono upload made me feel special. :P
<micahg> infinity: you at least caught it and apologized before I got the -changes E-Mail :), people make mistakes
 * stgraber just got his first armhf build failure!
<micahg> ooh, mono-devel is part of the DVD seed
<micahg> infinity: I would think getting armhf bootstrapped and building in the archive would make you feel special
<broder> wait, i'm supposed to be reading ubuntu-devel-discuss? :(
<stgraber> argh, s/discuss/announce/g :)
<stgraber> though I do read -discuss every day too but it's not nearly as useful as -announce :)
<broder> ah, good :)
<micahg> ooh, didn't catch that
<pitti> Good mornintg
<pitti> skaet: btw, the complete rebuild only takes 4 hours because of powerpc
<pitti> skaet: i386/amd64 desktop images now take 8 minutes, but have to wait for powerpc which takes some 35
<pitti> skaet: there's an RT for switching those to a faster machine
<pitti> infinity: I'm not worried at all about packages not  being up to date on the a1 images; that will basically never be true anyway
<pitti> infinity: as long as arch skew on mono doesn't cause uninstallability, that should not matter
<pitti> skaet: so, can't see any blockers right now, except for this infamous bug 894768; anything I need to watch out for during my day?
<ubot4> Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 6) (dups: 6) (heat: 58)" [High,Triaged] https://launchpad.net/bugs/894768
<pitti> infinity: hm, seems arch desync does cause trouble.. http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> let's hope that it finishes building soon
<pitti> armhf already finished, seems these builders are faster?
<pitti> cjwatson, skaet: FYI, I updated publish-image-set.py for the new tracker
<pitti> still had to use screenscraping, the XMLRPC API is missing some bits for this still (in particular, retrieving builds)
<pitti> skaet: FYI, added "general" and filled out the "Ubuntu" part of https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<infinity> pitti: Yeah, armhf has all the pandas right now.
<infinity> pitti: And sorry about the skew.  Was a complete oops on my part.
<pitti> infinity: np, it's all good now
 * ogra_ wonders if hf actually gains us compiler speed too
<ogra_> does that use the floating point engine massively in any way 8i would have thought not)
<pitti> skaet: also added some known bugs to TechOver now
<pitti> jibel: so aside from the dreaded EINVAL thing, I don't see any showstoppers so far; did you?
<jibel> pitti, I'm currently facing a problem with i386 installed on a server. jamespage says it could be due to powernap, I'm testing a workaround now
<jibel> problem = the server hangs and tells me bad things like http://paste.ubuntu.com/754743/
<jamespage> jibel: I'm pretty sure thats what its is - same symptoms as I saw in the openstack lab
<pitti> ah, offlining CPUs
<jibel> pitti, jamespage bug 898127
<ubot4> Launchpad bug 898127 in linux (Ubuntu) "system hangs and errors at /build/buildd/linux-3.2.0/arch/x86/kernel/apic/ipi.c:113 default_send_IPI_mask_logical+0xdc/0xf0() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/898127
<jibel> jamespage, no hangs with your workaround, could you update the bug report, and I'll add a release notes task.
<pitti> jibel, jamespage: do we want to upload a powernap workaround for this, or just release-note it?
<jamespage> Daviey: any opinion on ^^
 * Daviey looks
<Daviey> jamespage: Only impacts a subset of machines?
<Daviey> we've only seen it on Dell?
<jamespage> Daviey: in this instance it was machines with the ubuntu-orchestra-client installed which still recommends powernap
<jamespage> jibel: do you know what type of machine that issue happened on?
<Daviey> ubuntu-orchestra-client is still universe.. we don't install powernap by default, but shipped server-ship
<jibel> jamespage, PE R210
<jamespage> so a dell then
<Daviey> I really don't think this warrants a rebuild.
<jibel> right
<jamespage> Daviey: I don't think so either - is powernap even on the ISO?
 * jamespage goes to lookl
<Daviey> server-ship
<jamespage> so I see
 * jamespage should read things better
<Daviey> I don't think it even needs release notes providing there is a fix in the archive at release.
<lamont> putting several of the armhf builders on manual to minimize my pain from some maintenence to happen shortly
<bdmurray> How do the meta-release files at changelogs.ubuntu.com?  I fixed one of them yesterday and hit hasn't been updated.
<skaet> pitti,   good morning.   Thanks for the updates to TechnicalOverview.  :)
<stgraber> oh, technicaloverview alsmost forgot that one :) will need to update (not that there's much to say at this point)
<skaet> stgraber,  thanks!
 * skaet crosses one of the teams to remind off her list ;)
<bdmurray> mvo: ^?
<mvo> bdmurray: what did you fix, sorry I missed the context
<mvo> bdmurray: oh, indeed
<mvo> bdmurray: its a manual process currently, anyone in the changelogs group can update it
<mvo> I did that now
<bdmurray> mvo: okay, thanks
<skaet> jibel, mvo - has anyone started off the https://wiki.ubuntu.com/UpgradeTestingProcess?
<mvo> skaet: I haven't but I think that jibel has
<jibel> skaet, I did excepted cdrom upgrade
<skaet> thanks jibel, mvo
<jibel> skaet, wubi.exe is not on the desktop images and not listed in http://cdimage.ubuntu.com/daily-live/current/precise-desktop-amd64.list
<jibel> skaet, did I miss something or is it really missing ?
<skaet> pitti, ^
 * pitti looks
<skaet> jibel,  should be there,  will look into it too with pitti
<pitti> right, it's missing indeed
 * jibel adds a task to test the content of the images
<pitti> jibel: how can I find out what failed here? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=main-all,label=upgrade-test/
<jibel> pitti, go to the last failed or select job 58
<jibel> pitti, the logs are attached as artefacts
<pitti> jibel: ah, found it; thanks!
<jibel> in that case main.log says that 2011-11-30 06:54:46,720 ERROR Dist-upgrade failed: 'E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.'
<jibel> so you'll need to look at apt.log
<jibel> and you'll see there some dependency issue with tdsodbc
<jibel> Broken tdsodbc:i386 Breaks on libiodbc2 [ i386 ] < 3.52.7-2 > ( libs )
<jibel>   Considering libiodbc2:i386 3 as a solution to tdsodbc:i386 0
<jibel>   Holding Back tdsodbc:i386 rather than change libiodbc2:i386
<pitti> jibel: ok, will do that tomorrow; but sounds just like arch desync
<jibel> pitti, I'll look at it tomorrow morning with mvo because we also need to fix the base image for amd64
<pitti> I need to run for today, Taekwondo time
<jibel> good night pitti
<pitti> skaet: no idea about missing wubi.exe right now, I don't know how this works; need to RTFS tomorrow; perhaps ev knows
<skaet> RTFS?
<pitti> read the fine source
<pitti> cdimage scripts and so on
<skaet> :)  gotcha.
<mdeslaur> Is there an expert here or resources on packaging license dependencies?
<mdeslaur> I'm not sure where to ask about this
 * pitti waves goodnight, need to runu
<GrueMaster> Is no one testing kubuntu?
<skaet> mdeslaur,  I've got some background,  what's up?
<GrueMaster> I'm pulling the armel images now so I can whip through them.
<seb128> mdeslaur, don't ask to ask just ask I guess, worth case you get ignored :p
<skaet> GrueMaster,  I've posted in kubuntu-devel channel asking for some help, but no one's stepped forward.
<mdeslaur> seb128: pffff :P
<mdeslaur> skaet: I'm looking at bug 891192
<ubot4> Launchpad bug 891192 in ubuntu "Please sponsor the proposed qt4reactor packaging branch (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/891192
<skaet> RIddell is out due to car accident,  and not back on line yet.
<skaet> mdeslaur, looking
<mdeslaur> skaet: about sponsoring qt4reactor, but the reason it's not bundled with twisted in the first place is because twisted is MIT and pyqt is GPL
<ev> oh
<ev> pitti, skaet: entirely my fault
<ev> fixing now
<ev> (directory structure is missing in my public_html)
<skaet> thanks ev
<skaet> mdeslaur,  do they need to link together in some way (dynamic or static) to work?
<nessita> skaet: qt4reactor imports pyqt on a try-except block
<mdeslaur> skaet: it's python, which is why it's complicated :P
<nessita> skaet: if pyqt is not available (ImportError), it will try to use pyside
<mdeslaur> pyside is LGPL
<skaet> mdeslaur, heh,  yeah, see the issue, LGPL is better license for this sort of thing.
<skaet> mdeslaur,   let me ping around on this then.  imports aren't quite dynamic linking, but ... yeah, good question.
<ev> skaet: fixed
<skaet> jibel, ^
<mdeslaur> skaet: thanks.
<jibel> skaet, ev thanks.
<jibel> skaet, you'll rebuild the desktop images but not the squashfs ?
<skaet> jibel,  can do,  am also ok with release noting this, since some things have crept into the repository during soft-freeze that might have side effects.    What's the re-testing bandwidth like?
<jibel> skaet, not much.
<jibel> skaet, +1 for release noting for me.
<skaet> jibel,  anything else showing up from that testing that might provoke a respin?
<skaet> s/provoke/necessitate/
<jibel> skaet, nothing
<skaet> jibel,  ok,  lets plan on release noting it.
<skaet> jibel,  just talked to superm1 - they won't be releasing mythbuntu images with A1.  I've removed them from the tracker.
<jibel> skaet, k
<jibel> skaet, netboot images are not on the tracker but are good.
<skaet> jibel,  thanks for checking them
<skaet> stgraber, ^ I'm seeing netboot images as active,  any idea why they might not be showing up?   something need to be twiddled on nusakan?
<jibel> about netboot, precise is not listed at http://cdimage.ubuntu.com/netboot/
<skaet> jibel,  yup that would do it.
<davmor2> jibel: http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ and installer-i386 I imagine
<davmor2> jibel: as a temporary fix
<davmor2> jibel: if memory serves cjwatson does some hocus pocus and it appears in http://cdimage.ubuntu.com/netboot/ but that is the original link
<jibel> davidm, thanks, I know where to find it, just mentioning that it is not linked from cdimage.u.c
<davmor2> jibel: wrong david but I figured you might but always worth checking :)
<jibel> :)
<davmor2> jibel: assumption the mother of all *choose your expletive* ups ;)
<skaet> jibel,  I've gone in and added precise pangolin to the page,  but will need to wait for it to publish, and we'll see if it picks up the right pieces.   If not will get cjwatson to look at it tomorrow morning.  (he'll be back from vacation then).   Since the images are known to test out ok, that's the main thing.
<stgraber> skaet: netboot is an interesting one, as we don't build them daily but only when building a new d-i, they'll never show up automatically on the tracker, unless cjwatson does some magic to get them update when a new d-i is uploaded
<skaet> stgraber,  interesting,  lets find out how he wants to handle it then when he's back tomorrow.
<GrueMaster> I test omap4 netinstaller daily, and it works fine here.  After I run through the kubuntu armel images, I'll test the omap netinstaller.
<stgraber> skaet, jibel: LTSP failed on alternate, apparently something changed in ssh ... looking into that now
<skaet> stgraber,  ack.   thanks
<stgraber> skaet: I'll likely have a fix in the next 30 minutes (as in, I have a fix, it takes me 30 minutes to validate). Not sure if it's worth rebuilding though, your call.
 * skaet pondering
<stgraber> skaet: looks like the fix works (at least it didn't fail at the same place as before)
<stgraber> skaet: I should be able to check that a thin client can actually boot from that server in the next 10min or so
<skaet> stgraber, ok.
<stgraber> skaet: confirmed to work after reboot
<stgraber> skaet: should I upload a new LTSP with the fix?
<skaet> stgraber,  yes go ahead and upload.
<stgraber> (btw, the problem is Precise's ssh being picky about the permissions of /var/run/sshd)
<skaet> stgraber,  I think we can live with it being release noted, but want to get jibel's input.
<stgraber> skaet: right, only thing to be aware of is that I can't provide a workaround. Install will just fail, so workaround is to use a more recent daily.
<skaet> stgraber,   fair enough.
<stgraber> skaet: I don't feel like explaining how to modify the postinst script by hand at run time in the release notes ;)
 * skaet interprets that stgraber recommends a respin.
<stgraber> skaet: if we want/care about LTSP for alpha-1, then we need a respin
<stgraber> as usual it depends on how quickly we can get it re-tested
<skaet> stgraber,  yes, retesting is the concern at this point.
<skaet> jibel, ^^
<stgraber> at least it's limited to Ubuntu Alternate (i386 and amd64), Edubuntu's LTSP isn't affected
<skaet> thanks for confirming Edubuntu's LTSP isn't affected.
 * skaet goes and kicks off the Ubuntu Alternate respins
<stgraber> at least the current ones are fully tested, so we can always go with that
 * skaet nods
 * GrueMaster hears "respin", gets as nervous as a strung out long-tailed cat in a room full of mouse traps.
 * skaet reassures GrueMaster with phrase "Ubuntu Alternate" at this pont. 
<GrueMaster> Yea, saw that.
<skaet> :)
<stgraber> jibel: I'm sure you'll also be interested by http://91.189.93.73/qatracker/milestones/205/history (there's no link to /history in the UI at the moment as it's still fairly new)
<stgraber> skaet: I guess that between that page and jibel's report you should have a pretty good overview of what happened for a given milestone
<skaet> stgraber,  yes,  this is great!!!   Thank you very much!
<stgraber> skaet: that's for Oneiric Final: http://91.189.93.73/qatracker/milestones/202/history
 * skaet *hugs* stgraber.   
<skaet> sweet!!
 * skaet waiting for LTSP to actually publish before trying again.
<smoser> skaet, where should release notes be going ?
<skaet> smoser, https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<smoser> yeah, jst found thank you.
<skaet> :)
<skaet> LTSP published now.
<skaet> started respin of ubuntu alternate.
<skaet> pitti,  jibel - xubuntu won't have time to retest,  so leaving their images alone..  Haven't heard backfrom kubuntu or lubuntu yet on whether they want a respin.
<skaet> lubuntu just responded,  they'll stay with their current images.
<skaet> kubuntu responsed they'll stay with their current images in #kubuntu-devel channel.
<skaet> new ubuntu alternate images with LTSP posted.
<jibel> latest alternate looks good.
<jibel> I'll test wubi tomorrow morning when it's published somewhere.
<jibel> good night
<GrueMaster> skaet: Kubuntu armel images tested ok.
<skaet> Thanks Gruemaster
<skaet> jibel, thanks for confirming alternates look good.
<skaet> jibel,  unless pitti feels otherwise,  i recommend release noting the WUBI issue.
#ubuntu-release 2011-12-01
<smoser> skaet, updated https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<skaet> Thanks smoser!  :)
<smoser> we are generally a go with cloud images 20111130.
<smoser> https://jenkins.qa.ubuntu.com/job/precise-server-ec2/
<smoser> we've not recorded those test results in the iso tracker, bu tthey're there, and only 2 minior issues. one of which i've fixed.
 * skaet nods
<stgraber> skaet: we're back to i386 and amd64 ubuntu alternate fully tested
<skaet> stgraber,  excellent!!!  :)  thank you
<charlie-tca> skaet: all of xubuntu passed on hardware except wubi. I can not do wubi tests here.
<skaet> charlie-tca,   thank you.
<skaet> wubi tests won't work without the images being respun (see comments)
<skaet> pitti,  Technical overview has updates from the ISO tracker and some of the bugs from the Oneiric Release Notes that still seem to be present and folks might stumble into.    Its missing a few edits from the teams still.
<skaet> pitti,  If you start publishing images before I am online again,   given there hasn't been much testing there's some I don't think we should release.   amd64+mac, powerpc ones are lacking significant testing in Ubuntu.   Also,  there's been no definitive statement or evidence of much testing from the Kubuntu images by this point (other than the work Gruemaster did on the arm ones) so unless the picture drastically
<skaet> changes in the next few hours,   I recommend that Kubuntu not be released as part of alpha 1.
<skaet> pitti,  word from smoser and utlemming is that the cloud images are good, so even though they're not on the tracker, they should be good to publish.
 * skaet --> zzz
<pitti> Good morning
<pitti> skaet, jibel: for wubi we'd only need to respin the CDs, not the live images (so archive skew doesn't matter), but still, +1 from me for release-noting
<pitti> skaet: ok, I'll disable powerpc, but the diff of amd64+mac is tiny, I think we should releasea them
<pitti> skaet: kubuntu desktops got some testing; we could skip kubuntu alternates, as they weren't tested at all
<pitti> skaet: thanks for the summary
<pitti> stgraber, cjwatson: committed publish-image-set.py port to isotracker_xmlprc, thanks stgraber for adding the API!
<pitti> yay no more screenscraping
<jibel> pitti, while waiting for wubi, I can test kubuntu alternate.
<pitti> ah, I already pinged apachelogger
<infinity> pitti: What's the story with A1?
<pitti> infinity: I think we are as ready as we can be
<pitti> we'll skip kubuntu alternates, no testers (pinged apachelogger, no response)
<infinity> pitti: Oh good, so that klibc upload I just did can be considered post-freeze. ;)
<pitti> infinity: I was just about to lift the freeze
<infinity> (itchy trigger finger)
<pitti> infinity: see #u-devel :)
<ogra_> infinity, whats that bash ftbfs ?
<ogra_> do we have a fix for that ?
 * pitti publishes the images
<infinity> ogra_: I think we do.  Lemme refresh my memory.
 * ogra_ thought he heard doko say something 
<infinity> Yeah, I thought so too.
<pitti> smoser, Daviey: can you please publish the alpha-1 cloud images?
<pitti> (they'll need some time to mirror, I figure)
<pitti> I am currently publishing the a1 images
<smoser> pitti, they're all "pre-published", so 10 minutes it will be public. i will do that now.
<smoser> pitti, https://cloud-images.ubuntu.com/server/releases/precise/alpha-1/ is public.
<ogra_> pitti, http://cdimage.ubuntu.com/releases/precise/alpha-1/ misses the actual arm images (still mirroring ? or is that an oversight)
<ogra_> oh, mirroring delay
<ogra_> ignore me
<pitti> smoser: ah, I didn't know you do pre-publishing for alphas (ubuntu isos don't)
<pitti> ogra_: yes, mirroring
<stgraber> pitti: cool!
<smoser> pitti, basically after we test something we go through the entire publish process other than the ec2 equivalent of "chmod g+r".  that is what I call "pre-publish". it takes like an hour now so we do it ahead of time.
<pitti> skaet: mirroring of published images completed; release away :)
<stgraber> skaet, pitti: Just updated the TechnicalOverview for Edubuntu, sorry for not doing that earlier
<pitti> stgraber: cheers
<nessita> skaet: hey there! I was wondering if you had any news regarding what mdeslaur asked you yesterday re: licenses for the qt4reactor packaging
<skaet> pitti,   good day
 * skaet catching up on the backscrolll
<skaet> nessita,  yup gots some input from folks, but need to get release sorted out first,  I'll ping you and mdeslaur later in the day after that's sorted.
<mdeslaur> skaet: cool, thanks!
<nessita> skaet: thanks!
<pitti> hey skaet
<skaet> pitti,  I've just gone and looked at the iso tracker,  only 1/7 of the mandatory tests have been run on the desktops,  and no one from Kubuntu has bother to update the Techncial overview.   That's not good enough for release.
<pitti> skaet: ok, fair enough; I can reasily remove them from /relelases/ again
<pitti> "easily"
<pitti> skaet: what about lubuntu?
 * skaet looking
<skaet> pitti,  lubuntu's been well tested, and documented in the release notes - is there some issue I'm not catching?
<pitti> skaet: it wasn't in your release announcement that you sent to me
<pitti> skaet: I published it
<skaet> lol
<skaet> pitti,  it was an oversite in my announce - thanks for catching.  :)
<skaet> and publishing
<pitti> skaet: I replied to your mail, could be that there was something else, too
<pitti> but I think it was just that
<skaet> yup,  just scanned it now.   Will add in the changes.
<pitti> skaet: please let me know when you are done with wiki editing; I want to add that the i386 ubuntu desktop is oversized (or you do it while you are at it, I don't mind)
<skaet> pitti,  done.   There's already a statement in it at the top, but repeating won't hurt
<skaet> This release is for developers only. Most of these images are oversize; you can use either a DVD or USB for installation instead of a CD.
<skaet> pitti,  would appreciate you taking another pass at it,  and seeing if anything else needs to be tweaked.
<pitti> skaet: "most of" is really an exaggeration :) ok, fixing
<skaet> ;0
<skaet> :) even
<pitti> updated for oversized; doing another pass (had one this morning, but we got updates since then)
<skaet> thanks!
<brendand> skaet - i'll try and run a bunch of the kubuntu tests, can't do anything about the technical overview though
<skaet> brendand,  its too late now.
<brendand> skaet - ah, have we released?
<skaet> brendand,  on the last stages now.
<pitti> skaet: FYI, removing the two crash reports from known issues; we have client-side apport dup checking now
<skaet> brendand,  all the other images are tested and have been documented.   I don't want to keep the web-team and pitti around after their normal EOD at this stage.
<pitti> skaet: fixed a couple of "oneiric"s and typos, done now
<skaet> pitti,  thanks for catching those.  ;)
<skaet> brendand,  thank you for offering though,  and any testing you do do,  I expect the Kubuntu developers would appreciate getting feedback on the images and if there are other bugs that should be caught.
<jibel_> skaet, we should add to the release notes that Ubuntu can't currently be upgraded from Lucid ?
<pitti> skaet: FTR, cdimage cronjobs re-enabled
<skaet> jibel_, yes,  that one should be mentioned.    Please add.
<pitti> jibel_: oh, we can't? sounds like something the stable+1 team (*cough*) ought to fix ASAP
<pitti> jibel_: do we have an auto-tester for this?
 * skaet didn't know about it either.... good catch
<jibel_> pitti, yes I added it this week.
<pitti> nice
<pitti> jibel_: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=main-all,label=upgrade-test/ is for oneiric->precise, though, right?
<jibel_> pitti, there are resolving issues with the X stack, some ABI breakage I think, but didn't go into details
<cjwatson> bug 898482
<ubot4> Launchpad bug 898482 in update-manager (Ubuntu Precise) (and 1 other project) "Lucid to Precise upgrade fails: release upgrader fails to start (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/898482
<pitti> still trying to find my way there
<jibel_> cjwatson, that's another one, even with this one fixed, it won't upgrade
<cjwatson> ah
<mvo> "can't load DistUpgradeViewGtk (Unknown internal child: selection)
<mvo> " is fixed in bzr
<jibel_> I'll finish server profiles and will publish the results
<cjwatson> ah yes, bug 898551
<ubot4> Launchpad bug 898551 in update-manager (Ubuntu Precise) (and 1 other project) "lucid desktop i386 -> precise upgrade failed: Resolver failed to calculate the upgrade (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/898551
<jibel_> right
<jibel_> and with server upgrades, I can't connect with ssh after upgrade
<pitti> skaet: do you still need me for anythign? if not, I'd call it a day (you can SMS/call me if you need, of course)
 * skaet goes and looks at the process list....  
<skaet> pitti,  was the upgradetestingprocess completed?
<pitti> skaet: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/
<pitti> skaet: i. e. there's a corner case with full multi-arch and full main: which is failing (investigating), but the others are green
<skaet> when you switched cron back on,  has the default_milestone been changed to Daily, or is that still pending?
<pitti> skaet: oh, for ISO tracker, right
 * pitti tries to figure this out
<pitti> stgraber, jibel_: is that the "Daily CDs" milestone in http://91.189.93.73/admin/config/services/qatracker/milestones (currently "archived"), or should I create a new "Precise Daily" one? I'm not sure how it was disabled
<stgraber> stgraber: there's a "Precise Daily" milestone somewhere on there
<stgraber> doh :)
<stgraber> pitti: ^
<pitti> stgraber, jibel_: nevermind, found "precise daily"
<pitti> stgraber: so I flip alpha-1 to "released" and precise daily to "testing"?
<stgraber> pitti: yep
<pitti> done, and updated the notice
<pitti> http://91.189.93.73/ cross-check?
<stgraber> looks good
<cjwatson> remember to change ~cdimage/.isotracker.conf in sync too
<pitti> done
 * pitti documents on https://wiki.ubuntu.com/MilestoneProcess
<pitti> + 1. Update the ISO tracker to set the milestone to "released", re-enable the "daily", and update the notice.
<pitti> skaet: all set
<pitti> (MilestoneProcess already documented .conf)
<skaet> pitti,  Thanks for all your help today!   Have a good evening. :)
<mvo> re the upgrade failure lucid->precise, it appears that with the backported apt this works actually, the packages are currently in ppa:mvo/lucid-precise-upgrades but should move to lucid-backports eventually
<mvo> or lucid-proposed maybe, not entirely sure yet
<pitti> so, good night!
 * skaet waves to pitti
<skaet> mvo,  thanks - definitely want to make sure those get added in to lucid and well tested before 10.04.4
<stgraber> cjwatson: so skaet and I were wondering yesterday if we now have something in place to avoid images that were published on the tracker from being removed from cdimage
<stgraber> and if not, what would help to make that happen, I introduced builds.get_list yesterday but it only lists active builds, not superseded ones (that we usually like to keep too)
<stgraber> the new tracker also knows the path on cdimage for most/all of the builds, I could export that through the API too if that'd help
<cjwatson> well, we can't keep all superseded builds
<stgraber> not enough space?
<cjwatson> perhaps anything that was pushed for a milestone
<cjwatson> we only keep about two or three days of dailies normally
<stgraber> right, by superseded builds I meant anything that was posted on the tracker for a given milestone
<cjwatson> all superseded builds would be all dailies ever :)
<cjwatson> that would be OK
<stgraber> so whatever does the cleanup would look for builds associated with the milestone definied in ~/.isotracker.conf on the tracker (if the current milestone isn't a daily milestone) and never remove one of these
<stgraber> then when the milestone is no longer marked as testing, these will get cleaned up as usual
<stgraber> that'll avoid situations where we want to keep an image as a fallback and it ends up being removed from cdimage
<cjwatson> cdimage already knows how to map from its own idea of the world to the iso tracker, so probably no need to duplicate that
<cjwatson> give me a method to get all builds and I'll see what I can do :)
<stgraber> cjwatson: ok, code updated to support doing that, you'll need this applied to ubuntu-archive-tools: http://paste.ubuntu.com/756098/
<stgraber> default behaviour for get_builds remains that same, but you can now give a list of status that you want to list
<stgraber> if you want everything, you'll need to use [0,1,2,3] (0 = current, 1 = rebuilding, 2 = removed, 3 = superseded)
<cjwatson> mkay
<cjwatson> committed that
<ogasawara> skaet: I'd noticed pitti mentioned that archive is unfrozen now in #ubuntu-devel.  I just wanted clarification as I was under the assumption we're still frozen until you send the official announcement out?
<skaet> ogasawara,  yes, its a little out of order, but we'll not be respinning at this stage, so is ok.
<ogasawara> skaet: but just for future reference I assume I should wait for the announcement
<skaet> ogaswara,  yes please
<ogasawara> skaet: ack, thanks.
* skaet changed the topic of #ubuntu-release to: Alpha 1 released.  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> Alpha 1 is release!
<Laney> nice quote!
<skaet> Laney aka HOHOHaney  thanks!  :)
 * HOHOHaney jingles some bells
<skaet> :)
<skaet> mdeslaur, nessita - from the results of my pinging, there doesn't seem to be a lot of precedent discussed on this so far based on the folks I've talked to.  Standard disclaimers apply - I'm not a lawyer.    Feeling is since the MIT licensed code is dynamically loading the GPL/LGPL/other bits as it needs them,  the MIT code shouldn't be derived work, so things should be ok,  based on what I was reading in the channe
<skaet> l.   I haven't gone through and read the code though - so if I've gotten something wrong about the dynamic that's happening - please point me at the code bits inquestion.
<nessita> skaet: the piece of code that does the lib loading is this https://github.com/ghtdak/qtreactor/blob/master/qt4reactor.py#L44
<nessita> skaet: is a  python import inside a try-except block, and if the GPL lib (pyqt4) is not installed, it will try with pyside, which is a LGPL lib
 * skaet looking
<nessita> skaet: did you ask the legal guys? (I'm asking so I don't go a ping them again about the same :-))
<skaet> nessita,  yup thats who I was looking for input from yesterday.
<skaet> nessita,  it was informal discussion with a couple of lawyer friends though,   so if you have concerns and want to follow up,  no problems.
<nessita> skaet: ok, I will do that, thanks
<cjwatson> I think it's reasonably standard to say that if a piece of code can get by with any of multiple implementations under various licences, then your code isn't a derived work of any particular one of those implementations
 * skaet nods
<cjwatson> worst case the work as a whole is GPL; that does not affect the licensing of the MIT portion of the code
<cjwatson> (I'm coming into this conversation half-way)
<cjwatson> is this MIT code used by GPL-incompatible things?
<cjwatson> nessita: ^-
<nessita> cjwatson: hello there!
<nessita> cjwatson: so far no, we use it inside the Ubuntu One QT desktop apps which all are GPL v3
<mdeslaur> cjwatson: it's twisted (MIT) that uses qt4reactor (MIT) that uses pyqt (GPL)
<cjwatson> then there is unambiguously no problem
<cjwatson> the people who talk about the GPL being viral and forcing you to write GPL code as well are lying
<cjwatson> all you need is for it to be possible to distribute the work as a whole under the terms of the GPL
<nessita> mdeslaur: actually twisted does not use qt4reactor, but is a tiny detail. Our Ubuntu One apps use the qt4reactor (MIT) which uses twisted (MIT) and pyqt4 (GPL)
<mdeslaur> cjwatson: so stuff in the archive can possibly be GPL incompatible and still use twisted?
<cjwatson> that's more questionable
<cjwatson> it depends on whether you think that we're distributing a work as a whole by distributing it such that it uses pyqt by default
<cjwatson> perhaps we might need to arrange that there's never a situation where GPL-incompatible code that uses twisted ends up using pyqt, for example; that's probably a check-with-a-lawyer situation
<cjwatson> but it's absolutely fine for MIT code to use GPL code, it just means that you need to comply with the union of all the applicable licence terms when modifying/distributing the whole thing
<cjwatson> there is a wrinkle in that the debian/copyright file for python-qt4 is a bit confusing
<cjwatson> it says:
<nessita> cjwatson: what about when packaging the MIT code that list as requires the GPL code?
<cjwatson>   This program is free software; you can redistribute it and/or modify
<cjwatson>   it under the terms of the GNU General Public License as published by
<cjwatson>   the Free Software Foundation; either version 2 of the License.
<cjwatson> however http://www.riverbankcomputing.co.uk/software/pyqt/intro says "GPL (v2 and v3)"
<cjwatson> (GPLv2-only software isn't compatible with GPLv3 so that was worth checking)
<cjwatson> nessita: nothing wrong with that.  The GPL doesn't compel the twisted developers to licence their code differently; it merely means that you must comply with the GPL when doing things with the GPL part
<cjwatson> nessita: but since you can comply with the MIT licence and the GPL at the same time, that's OK
 * skaet nods
<mdeslaur> so, looks like it's fine then
<cjwatson> in any case, pyqt comes with a GPL exception that specifically says it's OK to use pyqt with a bunch of other licences
<cjwatson> GPL_EXCEPTION.TXT in the source package
<cjwatson> this specifically lists the MIT licence, so even if there were any doubt (which I don't think there is), that would cover it
<mdeslaur> ah! nice
<scott-work> cjwatson:  is this a convenient time for a brief discussion on a "libavcodec-extra-53 conflicts with libavcodec53" problem with ubuntu studio?
<cjwatson> scott-work: the precedent there is that ubuntustudio should be using libavcodec-extra-53 consistently throughout
<cjwatson> the point of the ffmpeg-common seed was to force that
<scott-work> i remember we made a change during natty and i reviewed the precise seeds and it appears to be inline for precise (hence my searching for you)
<scott-work> i reviewed http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise/files against the changes for https://bugs.launchpad.net/ubuntu/+source/ffmpeg-extra/+bug/685049
<ubot4> Launchpad bug 685049 in ffmpeg-extra (Ubuntu) (and 1 other project) "libavutil-extra-50 & libavcodec-extra-52 conflicts cause ubuntustudio natty alpha1 iso install to fail (affects: 1)" [Undecided,New]
<scott-work> aw, jeez, i think i see the problem...missing destkop-common
<cjwatson> are you sure that bug isn't simply closable?
<mdeslaur> cjwatson: thanks for the details on the licensing issue
<cjwatson> libavcodec isn't in the dependency-expansion of ubuntustudio.precise/desktop-common
<cjwatson> ah, it shows up in graphics, I see
<scott-work> cjwatson: yes, the old bug is probably closable, but the the precise dailies and alpha1 (apparently) have been reporting ""libavcodec-extra-53 conflicts with libavcodec53""
<cjwatson> scott-work: right, I have a fix - is there a bug number?
<scott-work> cjwatson: there is not at this point but i am happy to make one
<scott-work> shall i make one?
<scott-work> and can you explain the problem?
 * scott-work thinks he understands the problem in natty with forcing to choose the -extra packages based on desktop-common and ffmpeg-common
<cjwatson> no need to file one
<cjwatson> when germinate processes the graphics seed, it encounters something that depends on libavcodec53.  given the context it's operating in, it doesn't realise that it's supposed to choose libavcodec-extra53 for compatibility with other ubuntustudio bits.
<scott-work> i am hoping to better understand the problem because i speculate that i could have prepared fix to be checked and pushed to repos rather than bothering you for this
<cjwatson> the fix is to tell it that the graphics seed (and audio-plugins, for good measure) inherits from ffmpeg-common, whose purpose is to force the -extra variants to be selected
<cjwatson> I've committed a seed change for that
<cjwatson> don't feel too bad about not getting this, since to some extent it is dark wizardry
<scott-work> hehe, i can see that ;)
<cjwatson> not that that should prevent you from trying to understand it, just that it's not something widely understood right now
<scott-work> so you just added ffmpeg-common or desktop-common to the other seeds (graphics and audio-pluins) for this fix
<cjwatson> ffmpeg-common, not desktop-common (which wouldn't have helped)
<scott-work> aye
<cjwatson> http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise/revision/1279
<cjwatson> that should sort things out, but let me know if it doesn't
<scott-work> i presume this resulted in further changes in the seeds during precise, which explain why the fix during natty worked and oneiric but now yields a problem
<scott-work> thnak you very much cjwatson :)
 * cjwatson looks into the cause
<cjwatson> it happened because https://launchpad.net/ubuntu/+source/gimp-gap/2.6.0+dfsg-2 changed gimp-gap to start recommending mplayer rather than merely suggesting it
<cjwatson> which caused mplayer (which depends: libavcodec53 | libavcodec-extra-53) to be pulled into the dependency-expansion of the ubuntustudio graphics seed
<scott-work> it's a complicated web
<scott-work> thank you again
<ogasawara> skaet: just want to confirm that we still email out our weekly team status, but there won't be an actual meeting tomorrow?
<skaet> ogasawara, yes.  I'll send out a note to ubuntu-release to make it explicit and remove the meeting from the calendar.
<Daviey> That works well, as i wasn't sure i could attend. :)
<Daviey> Should we be sending status updates to the list for this week, still?
<scott-work> doh, and i was being all super aggressvie getting my email sent out on time :P
<skaet> Daviey,  scott-work,  yes please send status out to the list,   if there's anything critical showing up,  adhoc meeting will be called on monday,.  :)
 * skaet adding her bits to the agenda page,  so status for overall release is captured there right now
<jdstrand> skaet: where is the raw data for http://status.ubuntu.com/ubuntu-precise/ stored? eg, where is the data for http://status.ubuntu.com/ubuntu-precise/canonical-security.html?
<skaet> jdstrand,  I'm not sure which server the raw data is residing on these days,  I know we had some problems with it in oneiric.  pitti or cjohnston will know.   If you want to tweak the tend baseline, or something similar it can be done through a change to http://bazaar.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config/view/head:/config/ubuntu-precise.cfg
<jdstrand> skaet: I'm curious in the data, for my own reporting needs. pitti ^
<skaet> jdstrand,  data's on cranberry these days (just heard back from cjohnston)
<jdstrand> skaet: thanks!
#ubuntu-release 2011-12-02
<mdeslaur> pitti: we have a kernel ABI mismatch: http://paste.ubuntu.com/756659/
<mdeslaur> pitti: seems linux-ports-meta on lucid didn't get pushed
<mdeslaur> jjohansen: ^
<jjohansen> mdeslaur: ?
<jjohansen> mdeslaur: as in can you point me at what I need to do
<mdeslaur> jjohansen: linux-ports-meta on lucid is at ABI 35, but linux is at ABI 36
<jjohansen> mdeslaur: right I caught that
<mdeslaur> jjohansen: I usually tell pitti, the linux-ports-meta package needs to be pushed to updates also
<jjohansen> mdeslaur: ah, so when we get the breakage email we need to ping piti
<micahg> mdeslaur: jjohansen: he'll be around in ~3 hrs
<jjohansen> micahg: hrmm, he starts early if its only 3 hrs
<micahg> jjohansen: 6AM :)
<jjohansen> micahg: but thats like bedtime
<micahg> jjohansen: I know what you mean :)
<slangasek> mdeslaur, jjohansen: linux-ports-meta copied; SpamapS was driving those and trying to work out whether linux-ports-meta was among the ones supposed to be copied, I guess we have the answer now :)
<micahg> slangasek: ah, wasn't sure if you were around or not, so I didn't want to ping you
<infinity> pitti: We stole celbalrai.buildd as a livefs builder, so it no longer shows up on the /builders/ page.  You might want to suck the ddebs down from it by hand at some point, since I suspect your scraper script won't find it.
<mdeslaur> slangasek: thanks!
<pitti> Good morning
<pitti> infinity: we have 60 GB now on macquarie, I'll try whether that's sufficient now
<pitti> ogasawara: no, when we lift the freeze, it's fine to upload
<pitti> ogasawara: we usually do that at a time when it's clear that we won't respin any more, so no reason to further hold up development
<pitti> skaet: ^
<pitti> jdstrand: status.u.c. == cranberry.canonical.com
<pitti> jdstrand: you can get the db from http://status.ubuntu.com/ubuntu-precise/ubuntu-precise.db
<pitti> mdeslaur, jdstrand: seems someone already copied linux-ports-meta to -updates; I copied it to -security as well now
<pitti> infinity: celbalrai ddebs salvaged
<infinity> pitti: Danke.
<infinity> lamont: You can rm -rf ~buildd/public_html/ddebs/* on celbalrai, BTW.  pitti's harvested them all.
<pitti> stgraber: FYI, edubuntu DVD daily build should be fixed now, I uploaded a new nautilusy-python which ports the remaining stuff to GI
<pitti> mdeslaur, jjohansen, jdstrand: meh, whoever copied that linux-ports-meta/linux to -updates yesterday night made a pretty big mess out of it :(
<pitti> nothign on the tracking bug either; cleaning up now
<jibel> pitti, bug 897680 is back on a1
<ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 8) (dups: 7) (heat: 68)" [High,Triaged] https://launchpad.net/bugs/897680
<pitti> jibel: ah, thanks
<jjohansen> pitti: :(, thanks for cleaning it up.
<pitti> jibel: I'll investigate this today then
<jdstrand> pitti: re db> excellent, thanks! :)
<jdstrand> pitti: thanks for the kernel cleanup. if you find out who did it, can you point them to me? (I'd like to see if find-bin-overrides is working correctly)
<pitti> there's no logging for this unfortunately
<jdstrand> pitti: btw, are you using ubuntu-precise.db for your reports? (I would like to, and if you already know the db schema, that could be helpful :)
<pitti> jdstrand: "my" reports?
<pitti> jdstrand: no, I just use the status.u.c. date
<pitti> jdstrand: the schema is in the source, lp:launchpad-work-items-tracker
<jdstrand> pitti: I thought we broke some stuff down by member
<jdstrand> pitti: oh, excellent-- for some reason I was thinking this raw data on status was different from lp:launchpad-work-items-tracker
<jdstrand> pitti: great, that is all I need :)
<jdstrand> whoa, I've never seen this before:
<jdstrand>  3448803 | X- | pxe-kexec            | 0.2.4-1              | 1 hour 30 minutes
<jdstrand> 	 | * pxe-kexec/0.2.4-1 Component: universe Section: None
<jdstrand> pitti: what does the 'X' mean?
<jdstrand> sync
<jdstrand> interesting, I never noticed that before
<jdstrand> pitti: nm
<pitti> jdstrand: ah, I never saw that either, thanks; good to know
<mvo> hi, I prepared backports of apt/python-apt for lucid-backports, this will be used by the release upgrader plus it seems useful for users using apt-get dist-ugprade. any objections about the general approach (we talked briefly about it at uds)
<jibel> mvo, would it be possible to backport apt-clone to lucid or publish it to a PPA. I'd like to send a call for testing after alpha2 to collect lucid clones and try to upgrade them.
<mvo> jibel: oh, indeed! i will prepare that as well
<jibel> mvo, fantastic, thanks!
<stgraber> pitti: thanks
<pitti> stgraber: err, thank you, too! (but for what?)
<stgraber> pitti: 06:43 < pitti> stgraber: FYI, edubuntu DVD daily build should be fixed now, I uploaded a new nautilusy-python which ports the remaining stuff to GI
<pitti> ah, right; sorry, already fell out of my brain :)
 * pitti likes "nautilusy"
<cjwatson> mvo: makes sense to me - that's what we've done in the past, isn't it?
<mvo> cjwatson: the last time we (ab)used feisty-backports/debian-installer main, but I really would prefer to use the regular pocket this time as it seems cleaner and helps the manual upgraders
<cjwatson> regular pocket?  you said lucid-backports above
<cjwatson> oh, you mean you made it a udeb last time
<cjwatson> I'm OK with it being in -backports but the backporters team ought to sign off on it I think since it's an exception to the usual rules for that pocket
 * mvo nods
<mvo> yeah, thats fair enough - indeed, last time it was a udeb, this time I would like it to be a proper deb
<skaet> pitti, cjwatson.  https://wiki.ubuntu.com/MilestoneProcess - am reviewing, and the line pitti added (release-16) looks like its overlapping with (release-14) that cjwatson added.   Any issues with me consolidating and merging?  (or am I misunderstanding something)
<pitti> skaet: hm, where do ou see the overlap? one is the conffile on nusakan, the other is the ISO tracker
<skaet> pitti,  seems to me they're all related to getting the iso tracker back working with dailies.
 * skaet agrees that they are on separate environements though.
<pitti> skaet: I'm fine with merging them into one step
<skaet> pitti, thnx.
<skaet> pitti,  also trying to figure out how to clarify the unfreezing of the archive vs. announce going out.    In the steps archive does not unfreeze until after the announce goes out,  but I agree in practice for certain milestones its safe to unfreeze before, esp. for soft freezes.    However the checklist makes it explicit that the UpgradeTestingProcess is complete before the archive is unfrozen, and that's after the
<skaet>  announce.   What are the other factors that should weigh in to when to unfreeze archive.   When its clear we won't be respinning,  seems to me to be what I'm seeing used.
<skaet> ?
<skaet> cjwatson, slangasek, ^ any thoughts about when safe to unfreeze?
<cjwatson> I tend to think of it as we unfreeze once we're past point of no return
<cjwatson> so once we've decided to release and are just pushing buttons
<slangasek> yep
<skaet> cjwatson, slangasek, pitti - ok,  will make some updates to reflect that.
<mvo> jibel: apt-clone backport request is here https://bugs.launchpad.net/lucid-backports/+bug/899286
<ubot4> Launchpad bug 899286 in lucid-backports "Please provide apt-clone backport (affects: 1) (heat: 6)" [Undecided,New]
<mvo> jibel: once I get approval from the backports team, that should be fine, I ported it over to python-central
<mvo> cjwatson, slangasek: python-apt/apt backport request is written here https://bugs.launchpad.net/lucid-backports/+bug/899281 - feedback (as always) welcome!
<ubot4> Launchpad bug 899281 in lucid-backports "Please provide apt/python-apt multiarch backports (affects: 1) (heat: 6)" [Undecided,New]
<micahg> mvo: shouldn't this go to -updates?
<slangasek> mvo: ^^ same question as micahg; wasn't the plan to put these backports in as an SRU, to maximize mirroring and rely on the package names being different from anything in lucid to avoid them being incorrectly pulled into the system before the upgrader runs?
<micahg> Bug #899286 makes sense as a backport, but it'll also need to go to {maverick-oneiric}-backports
<ubot4> Launchpad bug 899286 in lucid-backports "Please provide apt-clone backport (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/899286
<mvo> slangasek: sorry for the delay in answering. so we could make the package name different, but then python-apt would have to have a different prefix or a different import name for "apt" and "apt_{pkg,inst}" plus the locales would have to be renamed or put into a different prefix as well. possible, but it seems like the -backport is actually both simpler and more useful (as the current approach will be useful for people wanting to perform a ma
<mvo> nual apt-get dist-upgrade as well).
<mvo> micahg: apt-clone> the version for lucid should be fine for maverick too and for oneiric we can use the current precise version unaltered
<broder> mvo: what micahg meant is that standard backport policies require backports to maverick, natty, and oneiric in addition to lucid
<broder> it's an upgrade path thing
<broder> but doing the dh_py2 -> dh_pycentral thing is fine - we tweak backports all the time to deal with toolchain changes
<mvo> broder: thanks, I see. indeed
<slangasek> mvo: oh.  we did discuss the -updates approach at UDS though, right, I didn't imagine that part?
<slangasek> if it's simply not practical, then by all means, do what needs doing :)
<mvo> slangasek: yes, we did :) let me think this through again, both approaches have some pros and cons and both will work, so in some sense its a good problem ;)
<mvo> slangasek: the upgrade path that broder mentioned is actually a (big) con against the approach to provide a full backport of apt/python-apt, and a pro for the more targeted approach we discussed at uds
 * mvo looks into this now
 * slangasek nods
#ubuntu-release 2011-12-03
<fabrice_sp> Hi. I just wanted to say that I wrongly synced 2 packages in Oneiric instead of Precise (by using the wrong web page). So don't hesitate in dropping them from New.
<infinity> fabrice_sp: felix-*
<infinity> fabrice_sp: ?
<infinity> fabrice_sp: Rejected.
 * ogra_ is surprised they dont get auto-rejected for released releases
<infinity> ogra_: Why would it?  It just gets pushed to a non-release pocket.
<ogra_> because we usually dont do straight syncs into released ?
<infinity> Sure do.
<infinity> Not into the release pocket, but into -updates.
<infinity> And anything targetted at oneiric gets turned into oneiric-updates, post-release.
<infinity> Hence, nothing wrong with the above.  Except that he pressed the wrong button. ;)
<fabrice_sp> thanks infinity!
 * skaet doing some build experiments (CDIMAGE_NOPUBLISH=1) this afternoon.   Should be done before daily cron kicks in.
 * skaet a bit surprised to find that images are published despite trying not to publish - something to investigate on monday it seems.  
<stgraber> skaet: maybe CDIMAGE_NOPUBLISH in this case means don't publish to the tracker but doesn't prevent them from showing up on cdimage.u.c? (just trying to guess, haven't looked at the code)
<skaet> stgraber,  wasn't expecting them to show up on cdimage.u.c - the variable seemed to work for the alternates when I was experimenting there.   But I suspect the answer will be in the code.   I've added trying to understand to my list for monday.
<skaet> or it could well be PEBKAC ;)
<cjwatson> skaet: I suspect a typo - I'd need to see shell history, though
<cjwatson> skaet: CDIMAGE_NOPUBLISH=1, if set correctly, prevents publishing to cdimage.u.c
<skaet> cjwatson, CDIMAGE_NOPUBLISH=1  buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd;
<cjwatson> typo
<skaet> gah...
<cjwatson> buildlive kubuntu-dvd dvd && CDIMAGE_NOPUBLISH=1 for-project kubuntu cron.dvd
<cjwatson> buildlive doesn't want that
<skaet> thanks!
<cjwatson> it's handled by build-image-set (called by cron.*)
<cjwatson> and the 'FOO=bar command' syntax only sets the variable for the immediately following simple command, not for an entire compound command
<skaet> thanks for the explanation,  PEBKAC indeed.  :)
 * cjwatson gets his replacement for most of cron.germinate down to about two minutes on his laptop
<cjwatson> (from more like ten)
<cjwatson> (on cocoplum)
<cjwatson> though still a few output differences I want to check over manually
<skaet> great!!  :)
 * skaet just hit into the mirror syncing - end of experiments for today.
<cjwatson> hm, I think I do still have some correctness issues
<cjwatson> ah, that's more like it now, although more like three minutes with that bug fixed
<cjwatson> still, not to be sneezed at, and I bet cocoplum will run it faster than my laptop does
<cjwatson> skaet: mirror syncing> actually I think you may have interrupted a manual run at an unfortunate point or something.  I just cleaned up a stale lock by hand
#ubuntu-release 2011-12-04
<skaet> thanks cjwatson - more for me to learn.
 * skaet needs to be able to clean up after her own messes. 
<cjwatson> I removed cdimage/ftp/Archive-Update-in-Progress-*
<cjwatson> after checking that no anonftpsync processes were in fact running
<skaet> thank you.   makes sense.   :)
<infinity> cjwatson: I'm about to fall asleep waiting for germinate in this publisher run; your shiny new version can't come too soon. ;)
<cjwatson> Is it taking longer than usual, or just the regular ten minutes or so?
<infinity> cjwatson: 10.5 minutes or so.  I'm just impatient.
<cjwatson> I'll hopefully release germinate 2.0 in the next couple of days (it's basically ready now), and sort out backporting it to lucid-cat.  That won't make much of a difference on its own, though - maybe a minute if you're very lucky.
<cjwatson> I haven't started writing the tests for the Launchpad side of it yet. :-(
<infinity> cjwatson: Does suite-diff.py exist anywhere more interesting than my INBOX from 2008?
<cjwatson> infinity: lp:~cjwatson/+junk/suite-diff, and it's in cocoplum:~lp_archive/bin/ too
<infinity> Yeah, just noticed it on cocoplum. ;)
<infinity> And thanks for the bzr pointer.
<infinity> Probably a bit too early to start running comparisons, but I didn't want to reinvent the wheel when I start doing armel/armhf diffs.
<infinity> cjwatson: Oh, that's less handy than I thought.  It doesn't consider "nonexistant" as an inequality.
<infinity> cjwatson: I might change that (or add another mode)
<cjwatson> infinity: I've had http://paste.ubuntu.com/758840/ lying around in my working tree for a while; I forget what state it's in
<cjwatson> infinity: I think I wanted to make it less hacky before committing it, but you might find it useful anyway
<infinity> Oh, shiny.
 * cjwatson goes to fall over
<infinity> 'Night.
 * skaet doing some more runs today.
#ubuntu-release 2012-11-26
<xnox> cjwatson: /me ponders where did I miss it.
<xnox> checking.
<xnox> yes.
 * xnox had a strange feeling something is wrong when plymouth migrated without dri-tools.
<xnox> please accept colord-gtk, split of libcolord-gtk library from the colord source package.
<infinity> xnox: Why the split?
<xnox> infinity: ask the uploader. /me has no clue, but as far as I can see something to do with not liking gtk portion of it.
<infinity> I thought you had some insight, since you were demanding it be accepted. :P
 * xnox just wants empty britney
<infinity> +commit fca4196ed897e086fd917f489c38d95278e4b1df
<infinity> +Author: Richard Hughes <richard@hughsie.com>
<infinity> +Date:	2012-06-18
<infinity> +
<infinity> +    Split out colord-gtk to a new sub-project to prevent a dep loop
<infinity> +
<infinity> +    At the moment GTK requires colord to build, but colord-gtk needs
<infinity> +    GTK to build.
<infinity> +    This makes bootstrapping a distro (or using jhbuild) harder than it
<infinity> +    needs to be.
<infinity> That seems to answer it.
<xnox> =)))
<xnox> colord: - Remove colord-gtk packages that are now in a different source package
<infinity> Yeah, your paste doesn't answer anything. :P
<infinity> As I'd still ask "and why are they in a different source package?"
 * infinity grabs the source to get all reviewy on its ass.
<xnox> =)))))
<xnox> ack, ack.
<xnox> thanks a lot =)
<xnox> why does britney not consider glew for transition?
<slangasek> xnox: because there are binaries in raring-proposed that are out-of-date (because they're NBS), and those need removed first; fixing
<xnox> slangasek: interesting. thanks.
<psivaa> xnox: Just wondering about the ETA of the fix for bug 1068178 :)
<ubot2> Launchpad bug 1068178 in ubiquity (Ubuntu Precise) "ubi-usersetup failed with exit code 1 on preseeded - encrypted-home installations on precise" [Undecided,Confirmed] https://launchpad.net/bugs/1068178
<xnox> psivaa: let me check.
<psivaa> Also i take precise desktop images being oversized is a known issue.
<xnox> cjwatson: I have cherrypicked the fix for the ^^^^^ ubiquity issue for precise. Are you planning to make a new upload of ubiquity to precise again soon or should the current upload pass verification first?
<infinity> xnox: Let the secure boot crap all pass and get promoted first, unless this bug's a showstopper.
<infinity> xnox: Pretty please.
<xnox> infinity: ack. It's a show-stopper for one test-case: automatic pre-seeding of default install with ecryptfs enabled.
<xnox> infinity: targetted for 12.04.2 to make sure we include it.
<infinity> xnox: Well, I'm sure it won't be the only bug we're trying to squeeze into .2 ;)
<infinity> xnox: (or bugfix rather)
<infinity> xnox: But yeah, the SB stuff kinda all needs to land in a big (hopefully working) group.
<xnox> psivaa: right. we currently have sru for ubiquity with 7 bugs to verify and I am sorry this bug did not make it into this sru. http://people.canonical.com/~ubuntu-archive/pending-sru.html After those are verified, I'll upload the fix for the encrypted-home bug. Sorry for the delay.
<psivaa> xnox: ok, hope it gets included in the next batch. thank you.
<xnox> it will.
<cjwatson> bdrung: In case you were wondering, I'm working on the reason that gworkspace didn't get copied to the release pocket (bug 1083131).
<ubot2> Launchpad bug 1083131 in Launchpad itself "Closing bugs OOPSes on invalid UTF-8" [Critical,New] https://launchpad.net/bugs/1083131
<bdrung> cjwatson: i haven't noticed it yet :)
 * ogra-cb__ wonders why he didnt see the plymouth issue when upgrading his nexus7 
<cjwatson> (I've confirmed that gworkspace is currently the only case where a publication was deleted from proposed without a successful copy to release and without having already been superseded by a later upload.)
<xnox> ogra-cb: btw. should there not be libdrm-omap?
<ogra-cb> i think its called libdrm2-omap (not sure, would need to check)
<ogra-cb> and yeas, theer shoulld eb the omap one and the radeon and nvidia ones shoud go away on arm :)
<ogra-cb> (as well as intel)
<xnox> ogra-cb: for the debs in plymouth. Ah.. it's libdrm-omap1
<ogra-cb> ah, right
<ogra-cb> i knew there was a number in the name
<ogra-cb> hmm, the nexus7 is really unhappy with the raring kernel :(
<bdrung> cjwatson: FYI, a fixed gworkspace is uploaded (the changelog had ISO-88... and UTF-8 mixed)
<cjwatson> I kind of wish you hadn't
<cjwatson> I was going to use it as a test case for the fix
<cjwatson> I guess I can still do that on dogfood
<cjwatson> But it wouldn't have been necessary if you'd asked ;-)
<bdrung> cjwatson: sorry. feel free to reject that upload
<cjwatson> Can't
<ogra-cb> hmm, the nexus7 build still fails on the plymouth issue
<ogra-cb> is something stuck in NEW by chance ?
<ogra-cb> http://paste.ubuntu.com/1389006/
<seb128> ogra-cb, NEW is https://launchpad.net/ubuntu/raring/+queue?queue_state=0
<xnox> ogra-cb: well I didn't add libdrm-omap1 dep on armhf, yet. I guess you need it like _now_
<ogra-cb> yeah, nothing there
 * xnox didn't understand the urgency earlier.
<ogra-cb> xnox, no hurry
<xnox> ogra-cb: did it work before?
<seb128> ogra-cb, try to sudo apt-get install libdrm-intel1 libdrm-radeon1 libdrm-nouveau2 plymouth-theme
<seb128> ogra-cb, to see what is the issue
<ogra-cb> 0.8.8-0ubuntu1
<ogra-cb> i have that one installed on the last nexus7 image
<ogra-cb> didnt cause build issues
<xnox> ogra-cb: and what is the current plymouth version?
<ogra-cb> hmm, i dont get that
<xnox> (for you / in that log failing to install)
<ogra-cb> so the build from the 24th failed
<ogra-cb> err
<ogra-cb> 25th
<ogra-cb> and todays too
<ogra-cb> bur the one from the 24th worked with the same plymouth version
<ogra-cb> http://cdimage.ubuntu.com/daily-preinstalled/20121124/raring-preinstalled-desktop-armhf+nexus7.manifest
<xnox> I see only 24th log here: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/raring/
<ogra-cb> libplymouth2	0.8.8-0ubuntu1
<xnox> where are the 25/26th logs?
<ogra-cb> failed
<ogra-cb> not sure why they arent copied, i got them by mail
<ogra-cb> both have the above pastebin error
<xnox> ogra-cb: can you forward them to xnox@u.c ?
<xnox> well it should be 0.8.8-0ubuntu2 across the board
<ogra-cb> ubuntu2 was only uploaded this night
<ogra-cb> 3am according to raring-changes
 * xnox was awake....
<xnox> ogra-cb: so libdrm-intel1 is not built for armhf since quantal and up.
<ogra-cb> well, i would assume a libdrm issue
<ogra-cb> doesnt smell like plymouth
<xnox> ogra-cb: but the later two are available, so why does the resolver tries to use the first one instead of any of the other two.
<ogra-cb> well, why does it use them at all :P
<ogra-cb> you will never find any compatible HW for either of these libs on arm
<ogra-cb> but iirc the prob was that the initrd stuff needs to be rewritten to be able to drop them
<cjwatson> ogra-cb: Hmm.  I assumed that that was due to needing s/libdrm-nouveau1a/libdrm-nouveau2/, which is why I asked xnox about that yesterday; but that isn't the problem any more.
<cjwatson> xnox: The resolver message indicates that none of the three are installable.
 * cjwatson sets up some raring-only chdist environments
<ogra-cb> yeah, whats really so confusing is that i got one successfull built on the 24th with the accused to be broken plymouth version
<ogra-cb> there was a libdrm upload on thesday it seems
<ogra-cb> *tuesday
<xnox> ogra-cb: and that was stuck in proposed until plymouth and dri-utils got rebuilt/fixed.
<cjwatson> Hmm, can't seem to reproduce in chdist
 * ogra-cb tries a dist-upgrade on the 20121124 image
<cjwatson> Wonder if I can run a test build on my Nexus 7 :-)
<cjwatson> It only really has to manage debootstrap, which should be fine ...
<ogra-cb> you surely can, but i would suggest using a USB key/disk via the otg cable ... might be faster
<cjwatson> Meh, debootstrap output isn't that large
<ogra-cb> well, yes, and it wont be eath shattering faster either
<ogra-cb> *earth
<cjwatson> I'll give it a try in a few minutes once I've upgraded it sufficiently
<hggdh> just a question -- are we now shipping kernel 3.5 by default on Precise?
<ogra-cb> everything but GLES stuff should be buildable just fine on the nexus
<cjwatson> hggdh: Yes, the quantal enablement stack
<ogra-cb> and i bet even way faster than on any panda
<hggdh> cjwatson: thanks
<ogra-cb> (just disk io isnt thrilling)
<cjwatson> ogra-cb: Once it has overlayfs support it should be a nice enough sbuild machin
<cjwatson> e
<ogra-cb> heh
<ogra-cb> if you could charge while having a HDD attached we could use a stack of them as buildd farm :)
<cjwatson> hggdh: For new installs, at any rate; nothing auto-upgrades existing installs
<hggdh> cjwatson: yes, makes sense. We were just surprised to see new installs with 3.5 in QA. I do not remember receiving any notice it would be done now
<cjwatson> ogra-cb: Are you running nexus7 builds by hand?  I don't see them in nusakan's crontab
<ogra-cb> dist-upgrade seems to work fine here btw
<cjwatson> hggdh: I probably assumed the kernel team would tell you :)
<ogra-cb> cjwatson, i added them for 13:32
<ogra-cb> right next to the lubuntu preinstalled ones
<cjwatson> ogra-cb: Oh, never mind, failure to read default-arches
<cjwatson> I was grepping crontab for nexus :)
<ogra-cb> heh
<Daviey> cjwatson: Hey, psivaa said they our precise daily images have quantal kernel?
<cjwatson> Daviey: Scroll up :)
<ogra-cb> aha
<ogra-cb> https://launchpad.net/ubuntu/raring/+source/libdrm/2.4.40-1 says it was only published at 24th
<ogra-cb> sad that it doesnt tell the time
<cjwatson> Hover
<ogra-cb> but i would guess its libdrm then
<cjwatson> As in, if you mouseover the date, you'll get a tooltip
<ogra-cb> since the image build of the 25th was the first that failed
<cjwatson> Or whatever you call it
<ogra-cb> hmm
<Daviey> cjwatson: I understood that this would not impact server.
<ogra-cb> 03:33 CET
<ogra-cb> os that would mean it was available on the 20121124 image
<ogra-cb> *so
<ogra-cb> (thanks btw, didnt know about the tooltip)
<ogra-cb> ARGH
<ogra-cb> that dist-upgrade made my initrd go from 1.5M to 3M
<cjwatson> Daviey: Perhaps it would make sense if all the people involved talked to each other.  It will be very very inconvenient to accommodate your request.
<cjwatson> Daviey: What is the reason behind your request?
<Daviey> cjwatson: I did just send a mail to those involved checking.. I thought that was what was agreed.
<Daviey> cjwatson: Having a higher reliance on dkms and other stuff that reaches into kernel spae, concerns me that we are doing this.
<Daviey> I thought server was purely sticking with the LTS kernel.. But i am checking for details now.
<cjwatson> Then y'all need to tell me very clearly what you actually need.
<cjwatson> And you won't get reliable secure boot support.  (You probably don't care, but I should be absolutely clear about this.)
<ogra-cb> cjwatson, could it be that there is some issue with the mirror used to build the images ? i cant really figure out whats wrong, manual dist-upgrade just works
<ogra-cb> as well as installing in a chroot
<cjwatson> ogra-cb: No, it's reproducible in a local build here
<ogra-cb> ah, good
<cjwatson> Just working on debugging it now.
<Daviey> cjwatson: Okay, yeah.. I'll stay shum until we have clarification.  Thanks
<cjwatson> Daviey: It may not be too horrible to fix, I guess, but I need total clarity or else there'll be chaos as we go back and forth.
<Daviey> cjwatson: yeah, just hold out.  It might be what was expected all along, but it wasn't what i heard.  So lemme get clarification
<cjwatson> (Since I did go to the effort of making it parameterised by a variable in CONF.sh, so I could make that project-specific.)
<cjwatson> ogra-cb: Ah.  I demoted libdrm-radeon1 from Priority: required to optional a bit too enthusiastically, apparently.
<ogra-cb> oh, hard to catch
<cjwatson> ogra-cb: The effect of this is that debootstrap's output has unsatisfied dependencies.
<cjwatson> Fixed in the archive now, for the next publisher run
<ogra-cb> k, i'll trigger a manual build in a few hours
<cjwatson> That was the cause of the powerpc image build failures too.
<ogra-cb> we really need to clean that up in an arch specific way some day ... on arm none of these libs make sense (apart from omap1)
<ScottK> ogra-cb: Start your list now for the UDS-S spec of "stuff I wish I'd had time for in Raring."
<ScottK> ;-)
<ogra-cb> heh
<ogra-cb> thats from the "list of things i wish i had had time for in natty"
<ogra-cb> its not like thats a new issue ... just rather complex due to the initramfs involvement
<GunnarHj> infinity: ping
<xnox> cjwatson: I think rsyncable is broken on the desktop iso's. Over the past week right now I have hit with zsync "no relevent local data found" will redownload the whole file.
<cjwatson> Don't know, I'm afraid; depends rather on squashfs-tools' behaviour
<xnox> cjwatson: and when ogra-cb & infinity were poking (one of the cd building softwares) they may have mentioned lack of gzip --rsyncable options.
<cjwatson> I don't recall there being a special option for it or anything
<cjwatson> But gzip isn't used ...
<xnox> hmmm
<cjwatson> At least not anywhere that matters much
<xnox> (it may have been something for nexus7)
<cjwatson> Anyway, AFAICS --rsyncable just isn't documented, but exists
<cjwatson> Compare the output of 'gzip --rsyncable' and 'gzip --garbage'
<ScottK> Shortly (once digikam is updated) we'll be in a position where only two packages block getting all of KDE 4.10 beta 1 (4.9.80) from raring-proposed to raring.  Those both need upstream porting due to API changes, so I think we don't want to wait.  Would the preferred approach be to force everything in despite those packages or to remove their binaries and then everything should migrate naturally?
<cjwatson> Hmm
<cjwatson> It screws users of those packages either way
<cjwatson> Are the packages on your images?
<ScottK> One of them is.
<ScottK> The part I don't understand though is why the impact isn't just two versions of the library for awhile?
<cjwatson> Then it's probably best to remove the binaries so that images can keep building, and file an RC bug as a reminder.  I'm concerned that this approach undermines the message about raring being continuously usable, though.
<cjwatson> Oh
<xnox> cjwatson: I do wonder how I can debug my zsync problem.
<cjwatson> ScottK: If that's all it is, it should be OK to force it
<ogra-cb> xnox, cjwatson, --rsycable isnt set fr tarballs inside live-build
<cjwatson> britney considers the situation as if all NBS were removed
<ScottK> Ah.
<ogra-cb> debian-cd uses it
<ScottK> Now I understand better.
<cjwatson> Or all NBS from the new source anyway
<ogra-cb> for the images themselves
<ScottK> Who can force stuff?
 * xnox adds a todo item.
<cjwatson> ScottK: ~ubuntu-release
<ScottK> Is there an ubuntu-archive-tools script for that or more properly, what wiki page or some such should I be reading instead of harassing you?
<cjwatson> ScottK: First time, you need to edit britney.conf in ~ubuntu-release/britney/britney2-ubuntu to add a hint permission for yourself (just follow the pattern)
<ScottK> OK.
<cjwatson> er with lp: on front
<ScottK> Gathered that bit.
<cjwatson> ScottK: Then create a file for yourself in lp:~ubuntu-release/britney/hints-ubuntu with the hints you want
<cjwatson> http://ftp-master.debian.org/testing/hints/README has the syntax
<ScottK> Thanks.
<cjwatson> I should probably wikify this at some point
<ScottK> Then once the packages move, the hint can be removed ....
<cjwatson> At your leisure, yes
<ScottK> Thanks.  I think I'm all set up now.
<ogra-cb> SHRIEK !!
<ogra-cb> http://paste.ubuntu.com/1389492/
<ogra-cb> so that build obviously failed
<ogra-cb> grmbl
<ogra-cb> there was no upload that could have caused live/build to break that way i think
<xnox> ogra-cb: well, seb128 did upload pyxdg
<ogra-cb> oh
<xnox> ogra-cb: and I wonder which file it's processing & fails on.
<ogra-cb> seb128, seems that broke update-apt-xapian-index somehow
<ogra-cb> obviously a kde one
<ogra-cb> but we dont log anything from subprocesses called in hooks during build it seems
<xnox> ... and there were plently of kde uploads lately migrating.
<ogra-cb> so its hard to get more info beyond the tracback
<seb128> ogra-cb, urg, sorry about that ... I was unsure how to test it so I mostly relied on the upstream test suit, seems that was not enough ... looks like a good case to add regression tests
<cjwatson> Run it locally and then you can just chroot in and try again
<seb128> ogra-cb, it traceback on /usr/share/app-install/desktop/spout:spout.desktop
<seb128> Categories:Application:Game:ArcadeGame
<seb128> it doesn't like that syntax error
<ogra-cb> bah, silly games
<seb128> that's the only issue
<seb128> if you move that .desktop away it works
<seb128> ogra-cb, want to fix app-install-data?
<seb128> ogra-cb, I need to run for ~1 hour but I can have a look later if needed, I will look at making pyxdg robust to those parsing errors but the easy fix is to update spout:spout.desktop to use "Categories=...;...;..;"
<seb128> that's the lack of "=" that makes the parser unhappy
<cjwatson> I'll fix the spout source package now
<seb128> cjwatson, thanks
<seb128> the pyxdg "bug" was introduced in http://cgit.freedesktop.org/xdg/pyxdg/commit/xdg/IniFile.py?id=39407c25769dd90ab9d5e8ee4c49b08f2d3f7089
<seb128> - index = line.find("=")
<seb128> - key = line[0:index].strip()
<seb128> - value = line[index+1:].strip()
<seb128> + key, value = line.split("=", 1)
<seb128> well it was probably buggy before but not hitting an exception
<cjwatson> uploaded; it'll need somebody to refresh app-install-data-ubuntu once that's in place
<cjwatson> Heh, upstream filed a bug on Ubuntu's spout package, even
<seb128> do we need/want a pyxdg workaround upload? like revert that diff?
<seb128> or is that ok to wait for app-install-data-ubuntu to be refreshed?
<cjwatson> Meh, it was busted, let's just fix a-i-d-u
<seb128> works for me
<cjwatson> I can poke it after dinner
<cjwatson> (i.e. manual refresh if necessary)
<seb128> thanks
<seb128> need to run, bbl
<infinity> GunnarHj: ?
<GunnarHj> infinity: Hi Adam, I was about to ask for your help to publish a few im-switch SRUs. ScottK seems to have done it already, though. Possibly he missed the quantal one. Maybe you can check if that's still in some queue?
<infinity> GunnarHj: I see nothing named im-* in the quantal queues.
<ScottK> I think I got that one.
 * ScottK looks
<infinity> Oh, unless by "queue", you mean "archive".
<ScottK> GunnarHj ...
<ScottK> --- Releasing im-switch ---
<ScottK> Proposed: 1.22ubuntu2.1
<ScottK> Release:  1.22ubuntu2
<ScottK> Copied to quantal-updates
<GunnarHj> infinity, ScottK: I don't see it yet at https://launchpad.net/ubuntu/+source/im-switch, but I just got an email, so it's probably in the archive soon. Thanks!
<infinity> GunnarHj: You want /$version/+publishinghistory on the end of that.
<infinity> GunnarHj: It should show you the pending records.
<GunnarHj> infinity: Aha, thanks for the tip.
<infinity> https://launchpad.net/ubuntu/+source/im-switch/1.22ubuntu2.1/+publishinghistory <-- For example.
 * ScottK went through and released all the verified SRUs within the last hour.
<infinity> ScottK: Thanks.  Now I get to flood proposed with a bunch of queue reviews today.
<ScottK> Yes.  Please.
<infinity> And the cycles continues...
<seb128> infinity, thanks in advance for doing queue reviews ;-)
<ogra-cb> cycling keeps you fit :)
<seb128> great, one of the two powerpc building just picked up libreoffice to build
<seb128> building->builders
<infinity> Yes, fat software needs building too.
<seb128> infinity, I'm more annoyed by the n_builder = 2 and the fact that nothing will move out of proposed to raring until the powerpc backlog is cleared :p
<ScottK> I've scored down builds on powerpc that I knew would fail to keep them from blocking up stuff until the queue is empty.
<seb128> oh, great, it failed
<ogra-cb> heh
<seb128> well, everything graphical is failing due to the out-of-sync-between-arch of fontconfig
<seb128> ok, dinner time, bbl
<ScottK> seb128: I just scored fontconfig up then.
<infinity> seb128: You can be annoyed about it all you want, but I'm not sure what good it will do. ;)
<mdeslaur> FYI, powerpc delay annoys the heck out of me too :P
<ogra-cb> arent we supposed to be over that soon ?
<ScottK> All it takes is a DCE to go revive sulfur.
<ScottK> Tomorrow apparently.
<infinity> Yeah, that's "all it's needed" for a while now.  Just a bit light on staff in London right now. :/
<seb128> infinity, well, the issue is that there is always a good reason and a solution "soon" but the fact is that powerpc is an issue again and again and again every cycle
<seb128> ScottK, thanks
<ScottK> At least there's a third builder down and down one = 2 and not =1.
<seb128> infinity, it's blocking SRUs, delaying normal work for 99% of users for the benefit of 1% etc
<ScottK> That last Main builds in the quantal backlog are building now.
<ScottK> Of course fontconfig becomes installable on powerpc just as the digikam build that I know will fail half way through starts ...
<infinity> Timig: iz everything.
<infinity> Timing, too.
<ScottK> You shouldn't have corrected yourself.  I thought that was some new lolcat dialect with which I was not familiar.
<cjwatson> Uploading that app-install-data-ubuntu update now.
<jamespage> please could the NEW packages for walinuxagent be accepted for raring; start of the SRU process for a critical fix....
<infinity> jamespage: Reading that bug and the fix kinda made me die a little inside.
<jbicha> please reject the previous gnome-shell upload and I hope I don't lose my place in the SRU line :|
<infinity> jbicha: Old one rejected, review rescheduled for January 3rd.
<infinity> jbicha: (I'm working on a bunch of reviews this afternoon/evening, we'll so how many I can get through)
<infinity> s/so/see/
<jbicha> infinity: yay! I should be able to get the paperwork done by January
<ScottK> OK.  Now that I retried everything that failed due to fontconfig uninstallibity, the powerpc build queue is looking suitably crappy again.
#ubuntu-release 2012-11-27
<xnox> ScottK: I love how _everyone_ cares about powerpc now that we have britney running.
<ScottK> ;-)
<jbicha> infinity: ^ that one will actually build
 * ogra_ is baffled
<ogra_> so when i got up i did a manual build of the nexus7 images, since yesterdays failed due to the xapian index issues
<ogra_> that build finished fine
<ogra_> now, 2h ago the normal daily buiold kicked in for that image ... and it fails with the same xapian index bug
 * ogra_ doesnt get why the first build worked
<cjwatson> rejecting tox as discussed with barry in /query (potential future .orig conflict)
<Daviey> cjwatson / barry: what is the potential conflict ?
<Daviey> (we care about tox aswell.)
<cjwatson> Daviey: if the same upstream version is uploaded independently to Debian and Ubuntu, we must make sure that they have identical .orig.tar.*
<cjwatson> Daviey: the version in the Ubuntu NEW queue had a different one than that in Debian NEW
<cjwatson> Daviey: but it's apparently been processed through Debian NEW now so we'll just let it autosync
<cjwatson> been / being / something
<Daviey> ahh
<Daviey> thanks :)
<Daviey> (I really wish reject mandated a comment)
<cjwatson> Yes, but my comment would have been exactly as I said on IRC above :)
<cjwatson> i.e. I'd just have said "potential future .orig conflict", I expect
<Daviey> yeah.. fair comment.
<highvoltage> looking at http://status.ubuntu.com/ubuntu-precise/ vs http://status.ubuntu.com/ubuntu-quantal/ vs http://status.ubuntu.com/ubuntu-raring/ it seems like the shorter UDS had an impact on the amount of work items :)
<Daviey> or the quantity of documented work items. :)
<highvoltage> indeed!
<xnox> Daviey: highvoltage: it could be due to natural causes. Both quantal & precise UDS summits were in much warmer conditions. ;-)
<xnox> *hint* *hint*
<Daviey> xnox: Well, since you've asked so nicely.. we should go back to warmer weather next time?
<xnox> =))))))
<ogra-cb> +++++++++++!!!1111oneoneone
<GridCube> brainfuck?
<xnox> ogra-cb: marvin, is that you?!
<jamespage> infinity, thanks for accepting those package; that bug made me cry *alot*
<xnox> jamespage: infinity: ++
<jamespage> xnox, thanks for your help with the fix as well...
<xnox> jamespage: let's just hope it's the worst bug found.
<xnox> (in any package)
<skaet> highvoltage,  Daviey -  suspect its teams not setting up their topic- statements to group things, so they're not visible yet.  :P
<infinity> Does anyone know why allspice.buildd was set to manual?
<ScottK> infinity: Wasn't me.
<infinity> Irksome.  I kinda want to turn it back on, but I kinda don't want to if there's a valid reason for it being off. :P
<cjwatson> Wasn't me either
<ScottK> Skynet arrives quietly ...
<stgraber> wasn't me either, but that still leaves quite a few people :)
<ScottK> Maybe it set itself on manual because it's busy eating the DCE that was supposed to fix sulfur.
<cjwatson> Yeah, that had problems powering on at last check
<cjwatson> infinity: Did Brian show up again this evening, or had he EODed by the time you got there?
<infinity> cjwatson: He spoke to me long enough to say he had to take 30m to do something else... And never came back. :P
<cjwatson> Ah :-/
#ubuntu-release 2012-11-28
<hggdh> infinity: I finally have the armada under control, tomorrow I will start coding & running the kernel tests on it
<infinity> cjwatson: Hrm.  I wonder if the whole "having to override everything again after copy from proposed to release" thing might actually have something to do with the race between britney both deleting and copying at the same time.
<infinity> cjwatson: Maybe leaving it no pubs to copy the overrides from?
<cjwatson> infinity: Mm, possibly.  FromExistingOverridePolicy.calculateSourceOverrides does include "SourcePackagePublishingHistory.status.is_in(active_publishing_status)".
<cjwatson> We could drop it if we caused something (sru-report?) to deal with the removals automatically.  I don't want it to be manual.
 * cjwatson -> bed, finally
<Laney> that reminds me
<infinity> Err.
<infinity> You accepted it with that version number?  Really?
<infinity> Ick.
<infinity> Oh, you're the one who uploaded it with that version. :P
<Laney> that's the backports versioning scheme
<Laney> ick away
<infinity> It... Is?
<infinity> With two ubuntus?
<Laney> yeah
<infinity> 0.8.0~rc1-4ubuntu38~12.04.1 makes more sense, surely.
<infinity> Where is this scheme documented?
<Laney> the second is for sorting purposes
<Laney> probably on some mailing list, and in the code for backportpackage
<infinity> For sorting against what?  Uploads that have a-t words there?
<Laney> We used to use ~SERIES<number>, then had the foresight to fix that before we wrapped around the alphabet (and before we got to 'u'-series)
<infinity> I recall being involved in this conversation.
<infinity> And pointing out that switching to ~<number> solves it fine, since backports are backports of new versions...
<infinity> So 1.2.3-1~oneiric1 will still be << 1.2.3-2~11.10.1
<infinity> Which is fine.
<infinity> And right.
<infinity> Any clash that ~ubuntu11.10.1 is trying to solve doesn't actually exist.
<Laney> All I can think of is re-backporting over the top of existing ones. Dunno. I didn't have these conversations - IIRC it was Colin and Evan at UDS-Q.
<Laney> or P?
<Riddell> cjwatson: remember that conversation about removing owncloud and how it can't be done?  seems I did remove it as far as launchpad is concerned in precise but not as you said from the archive https://launchpad.net/ubuntu/+source/owncloud
<infinity> Riddell: Sure, it can be removed from LP, but precise won't ever be republished, so that's meaningless.
<infinity> Riddell: But, why did you do such a thing? :P
<Riddell> infinity: lots of security issues in owncloud and upstream asked for it to be removed
<infinity> It would seem to me that the solution to "upstream says it's insecure" is to fix it, not delete it.
<infinity> Since deleting it doesn't magically get it off people's systems.
<Riddell> upstream's solution is to upgrade to the latest
<Riddell> but a backport isn't possible even if ~ubuntu-sru would be happy to do that as an update
<cjwatson> Riddell: That was, I think, what I said :)
<infinity> Not possible?
<cjwatson> Nothing will *ever* republish the release pocket indices
<infinity> cjwatson: Sorry, that "not possible" was to Riddell's assertion that the package can't be backported.
<cjwatson> So yes, OK, at one point LP forgot to sanity-check removal
<infinity> Riddell: Why is it "not possible"?
<cjwatson> infinity: Yeah, I understood
<Riddell> infinity: too many third party modules needed which all need to be updated too many of which require other dependencies to be updated
<infinity> Riddell: Is upstream willing to hilight what these security holes are, instead of just saying "iz broke, update it"?
<infinity> Riddell: And do they have, I dunno, some sort of VCS where perhaps they fixed these things?
<Riddell> infinity: yes, but no patches http://owncloud.org/security/advisories/
<infinity> Oh lord, it's PHP.
<infinity> Cause I've never seen badly-written PHP before.
<Riddell> right
<infinity> Looks like their recent advisories actually point to git commits.
<infinity> Divining the fixes for the older ones from logs might not be too hard.
<doko> infinity, next eglibc give back?
<infinity> doko: *sigh*.. Yes.  Different test failed this time.  The previous one passed.  If it explodes one more time, I'll reupload with the suite checker disabled (since I know it's fine) so gcc can build.
<doko> thanks
<infinity> But not happy about this.  Need.  Real.  ARM.  Hardware.  That.  Isn't.  Cell phones.
<ogra_> chromebooks for the DC !
<ogra_> hmm, so do i add the slideshow back to the arm images at the risk of having nexus7 get to big or not ...
<cjwatson> tumbleweed: I've belatedly merged and deployed your madison-lite cache locking fix; thanks!  I made one correction; you'd missed a take_cache_read_lock call when constructing the cache for a Sources file.
<cjwatson> So hopefully rmadison will be faster now.
<Daviey> cjwatson: still intolerably slow?  Will it take a while for the cache to be hot?
<Daviey> Ooo, first attempt was 17 seconds.. second was 3
<cjwatson> It still has to recache any time the archive changes.
<cjwatson> But it won't forkbomb lillypilly in the process.
<Daviey> cjwatson: well that is good news
<tumbleweed> cjwatson: ah, so I did
<tumbleweed> cjwatson: still seems dog slow, though :/
<cjwatson> It's certainly not a panacea
<tumbleweed> I could have just been the first caller after a publish
<tumbleweed> it seems snappier now
<didrocks> so, we have some kind of on ongoing debate and trying to understand how the promotion/demotion list worksâ¦
<didrocks> if I take gstreamer0.10-plugins-base-doc, it's not installed by default and the rdepends doesn't seem as well
<didrocks> (and it's in main)
<didrocks> it's not on the demotion list: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<didrocks> but on this list, there is libatk-adaptor-data
<didrocks> which has its source in main and other binary package of this source rdepending/seeded
<didrocks> so while this binary package (which hasn't a rdepends in main) is in this list, and not the -doc?
<didrocks> is there a special filters for -doc, -dbg?
<didrocks> (the debates is about if we promote some -utils/debug tools, do we need to add it to a seed or not and promoting the whole source, but first, I would prefer to understand the rule for something being on the promotion/demotion list ;))
<cjwatson> see seeds/ubuntu.raring/supported
<cjwatson> libatk-adaptor-data should be seeded explicitly somewhere if you want it in main
<cjwatson> Anything that matches the Extra-Include patterns in the supported seed doesn't need to be seeded explicitly
<didrocks> ah ok, so there is indeed some pattern for -doc, -dbg and so on in this Extra-Include
<didrocks> thanks for the explanation cjwatson :)
<cjwatson> Please note that the promotion/demotion list isn't calculated that way directly - it's a delta between the current state of the archive and what germinate says should be in main.  It's quite important to understand this otherwise you'll get confused (e.g. you might think that things currently in main are treated differently somehow)
 * didrocks reread
<cjwatson> If you're adding things explicitly then they may perhaps want to go somewhere like platform.raring/supported-SOMETHING-desktop instead of directly in supported
<cjwatson> This is used for a crazy scheme to try to autogenerate vaguely correct support lifetimes
<didrocks> cjwatson: I don't want to touch this libatk-adaptor-data (I'll let it to Luke), but I wanted to understand the difference between this one and the -doc and others one ;)
<cjwatson> Yeah, I can understand how it might not be obvious
<didrocks> cjwatson: I still don't get the "it's a delta between current state of the archive and what germinate says should be in main"
<didrocks> the only diff is a lag of one day? (well, since last daily iso)
<cjwatson> No
<cjwatson> There's no lag
<cjwatson> forget about ISOs, they're irrelevant
 * didrocks forgets ;)
<cjwatson> the publisher runs germinate at the end of every run
<cjwatson> this takes the seeds and dependency-expands them with respect to the current archive (considering all components)
<didrocks> until then, makes sense
<cjwatson> component-mismatches takes the output of the part of that germinate run for the Ubuntu seed collection
<cjwatson> (i.e. not Kubuntu etc. - only ubuntu.raring is currently constrained to be in main)
<cjwatson> and says "OK, all packages in the output of germinate for Ubuntu should be in main"
<cjwatson> then it compares that against what's actually in main in the archive, and the output of that comparison is what you see
<didrocks> yeah, that was my understanding :) so I think I missed a possible steps of misunderstanding you were afraid I had?
<didrocks> like, you need to be attach to a seed "root node" (or calling it something like that)
<didrocks> it's not only checking relationships betweens package in main, they need to be "attached" to this tree
<cjwatson> OK, so one confusion that sometimes arises is with virtual packages
<cjwatson> let's say you depend on a virtual package which is provided by real packages in main and in universe
<cjwatson> sometimes people believe that the one in main will be preferred, because it's in main
<cjwatson> but that isn't the case - germinate (at least in the publisher configuration) doesn't care, because it's the *output* of germinate that determines what goes in main
<cjwatson> it's certainly also true that a package can't stay in main without being referred to either directly or indirectly by the Ubuntu seed collection
<didrocks> ah ok, I've alread fallen into that trap few years ago ;) so used to it and knowing it needs to be explicit
<cjwatson> (where that indirectness includes build-dependencies)
<didrocks> yeah, there are deps and build-deps as relationship
<cjwatson> and recommends
<didrocks> indeed :)
<cjwatson> (usually)
<didrocks> cjwatson: everything is crystal clear! Thanks a lot for all the precisions
<ogra_> sigh, i wish FRAMEBUFFER for the initrd could be somehow decoupled from pulling plymouth in
<cjwatson> NP.  I look forward to your germinate patches? ;-)
<cjwatson> Grr, why is linux-signed-* *still* not on the precise images
<didrocks> cjwatson: ahah, there was a trap! I was sure about it ;) (more seriously, is there some area (I guess tricky if you didn't get to them yet) where some work is needed?)
<stgraber> cjwatson: oh, that reminds me that I need to test the new images to confirm that they now boot on my system. Will do that after our weekly meeting.
<cjwatson> Actually the code is pretty solid nowadays; the main problem is that documentation consists of "ask Colin how it works"
<cjwatson> germinate is python3-compatble and has a test suite and everything ...
<cjwatson> the main outstanding problem is that there's some hysteresis in the publisher
<didrocks> nice ;) yeah, doc, as usualâ¦
<cjwatson> germinate is run at the end of each publisher run, and is an input to the *next* publisher run
<didrocks> hysteresis? really?
<cjwatson> so in theory it's unstable
<didrocks> ah
<didrocks> yeah
<cjwatson> also, the publisher doesn't necessarily notice that germinate output has changed and so it needs to republish
<cjwatson> the fix is to call germinate in the middle of the publisher, with package data directly from the Launchpad DB
<cjwatson> I tried that a while ago but it was hopelessly slow because I was a bit naÃ¯ve about how to do bulk DB operations
<cjwatson> need to try again
<didrocks> interesting project, but yeah, calling every package with launchpad regular APIsâ¦ I can imagine it beeing very slow
<cjwatson> didrocks: Well, it wouldn't be the API, it'd be direct database access
<cjwatson> Or at most a special-purpose internal API
<cjwatson> Package copies (including promotions from raring-proposed to raring) are going to be queued for a while due to a hardware upgrade of the relevant script server
<cjwatson> Package copies should be back no
<cjwatson> w
<cjwatson> (for a while actually)
<cjwatson> ^- part of the SB extravaganza - could somebody review?
<Riddell> what's the secret to uploading to quantal-security?
<cjwatson> Riddell: You can't upload directly; only the security team is allowed to copy into it
<cjwatson> get them to issue a USN etc.
<Riddell> ]
<Riddell> ##
<Riddell> ]=44~=;;;##########
<Riddell> #
<Laney> (look how much he hates talking to the security team)
<xnox> Riddell: patches on a bug + subscribe ubuntu-security
<xnox> Riddell: or ubuntu-security-sponsors something like that.
<slangasek> cjwatson: appmenu-gtk/precise accepted now.. but I see that the quantal one is still in the queue :)
<slangasek> (along with some other, older ones)
<seb128> slangasek, great, one SRU in, only 90 to go, you can do it ;-)
<slangasek> heh
<ogra-cb> is this a sprint ?
<seb128> ogra-cb, it's a competition between the sponsoring queue and the SRU queue
<seb128> dholbach is leading by a small margin
<slangasek> if my wife stops making me get on planes on my SRU days, I should be able to make some progress
 * ogra-cb looks for his pompoms to cheer from the side 
<seb128> we need to stop the 6 months cycle madness and just keep the LTSes
 * seb128 got annoyed recently about the number of SRU requests for quantal, the rational behind them makes sense but it's a lot of efforts spent
<slangasek> seb128: not all SRU requests need to be accepted?
<stgraber> seb128: rationale being that they want those in quantal so they can push to precise?
<seb128> slangasek, it's hard to say not to request to fix an obvious stopper bug in a stable release
<ogra-cb> slangasek, but processed
<seb128> not->no
<ogra-cb> or at least looked at
<ScottK> seb128: Probably fewer SRUs if people follow the release schedule and land features on time so that stuff can get fixed before release.
<seb128> ScottK, well, at lot of those are from !canonical, e.g GNOME in my case
<ogra-cb> ScottK, nah, that kills all the fun of releasing with bugs
<ScottK> seb128: True, but many of them are also self inflicted.
<seb128> right, but those are mostly fine, the unity guys are doing regular bug fixe releases so it's contained on a few component (e.g mostly unity and compiz and sometime some lenses)
<seb128> slangasek, I just did a libvirt SRU today because XDG_RUNTIME_DIR broke it and it was late and we didn't notice before release :p
<seb128> well, anyway if good faith if we roll stable release we need to fix obvious bugs
<seb128> doing that on 6 months basis is high cost ... looking forward the day we can do rolling release between LTSes ;-)
<ScottK> Rolling release is an oxymoron.
<seb128> well, do it the debian way if you prefer
<seb128> e.g keep rolling on the unstable cycle for 1.5 years than take 6 month to do a solid release
<ScottK> Might as well use Debian then.
<ScottK> Having the regular releases is one of the main reasons I initially chose Ubuntu over Debian.
<seb128> like the only thing Ubuntu is doing is to snapshot Debian every 6 months?
<ogra-cb> not really
<ogra-cb> we develop features through applying different glue, the snapshotting is only a minimal part of a cycle imho
<seb128> well anyway, I didn't want to start an heated discussion
<seb128> but I've been annoyed by the numbers of SRUs I had to do to quantal recently
<seb128> I wish we only had precise and raring to care about at this point
<ogra-cb> yes, we simply shouldnt do SRUs for non LTS by policy
<xnox> seb128: lucky you with desktop lts. I was working on sponsoring server sru's into lucid the other day.....
<slangasek> seb128: IMHO that's a decision you should be empowered to make
<seb128> well, it's embarassing to have a "release" out with things broken in a so obvious way
<ogra-cb> xnox, well, that difference is gone now
<seb128> xnox, that time is over since precise
<xnox> ogra-cb: true. but it will only be evident past 2015 april.
<ogra-cb> indeed
<xnox> ogra-cb: the ticking bomb has been set off =)
<seb128> slangasek, I can't in good faith ignore those bugs in a stable release... we flagged quantal as being one so we need to deal with it
<ogra-cb> hehe
<seb128> xnox, well, lucid is still supported on the desktop as well...
<xnox> seb128: true.... but i take it doesn't have many desktop sru requests?
<seb128> xnox, likely not
<seb128> desktop people tend to like more the shiny stuff
<seb128> so they tend to update
 * xnox is sad, I upgraded to raring to get python3.3 by default..... that counts as shiny, right?!
<ogra-cb> does it wobble if you move it ?
<ogra-cb> s/does/can/
<slangasek> anyone know what happened with gst-plugins-good1.0 landing in component-mismatches?
<ogra-cb> not MIRed yet ?
<slangasek> ogra-cb: in main since forever
<ogra-cb> 1.0 ?
<slangasek> ah, looks like the armel-only binaries have been demoted to universe for some reason
<ogra-cb> note that gstreamer carries the version in the package names ... 1.0 is pretty new
<slangasek> ogra-cb: oh, so it is
<slangasek> ok
<cjwatson> slangasek: 'queuediff -s quantal-proposed appmenu-gtk' is confusing - what was going on with ubuntu1.1 there?
<jbicha> having an Ubuntu release before the GNOME .1 release is a good way to cause more SRU work
<cjwatson> it looks OK, and I think is what we agreed - just rather oddly formatted
<cjwatson> oh, I see, that version was removed
<cjwatson> never mind
<slangasek> yep
<ScottK> jbicha: The Ubuntu releases land at the KDE .1 or (usually) .2 and I've always thought that was a good thing.
<jbicha> I just think the maverick early October experiment has outlived its usefulness
<cjwatson> that wasn't even useful when it happened
<seb128> ogra-cb, slangasek: we decided that gst1 doesn't need MIRs since it's the same source that gst0.10, only a new revision ... same as gtk2 and gtk3
<seb128> but yeah it got promoted today
<slangasek> yes, agreed
<slangasek> I was just confused that 1.0 != 0.10 ;)
<cjwatson> there you go
<slangasek> ta :)
<infinity> jbicha: You're TIL on user-mode-linux, any plans to rev it to 3.7.0?
<jbicha> infinity: I only touched it becuase it was NBS, you're welcome to grab it if you like
<infinity> jbicha: Sure, I wasn't sure if you had a vested interest in it or if it was a +1 drive-by.
<infinity> I'd suggest Ubuntu needs a concept of a "QA Upload", like Debian, except that would litter about 98% of our changelogs.
<infinity> So, probably not useful. :P
<ScottK> If the same person uploads more than N times in a row to Ubuntu, ask them before you touch it ...
<infinity> ScottK: That's my general rule.  UML gets uploaded so infrequently, though, it's hard to tell if it has a primary maintainer in any meaningful way.
<infinity> (And the answer seems to be "no", which is fine)
<cjwatson> Could somebody have a look at livecd-rootfs/precise-proposed, please?  Part of the SB backport work and I'd like to get it into tomorrow's image builds.
<infinity> cjwatson: Will poke.
<infinity> cjwatson: Needs a reupload with -v to catch the previous changelog, but I'll do that on your behalf if I like the rest of it.
#ubuntu-release 2012-11-29
<infinity> cjwatson: ^
<cjwatson> infinity: That's curious; in the one I have on disk, I did use -v.
<infinity> cjwatson: Weird.  You can check your .changes in the rejected queue, it only had the top version.
<infinity> cjwatson: Anyhow, I sponsored with a new dpkg-genchanges, and accepted.
<infinity> Err.
<infinity> And now that I look in the rejected queue, I see both entries.
<infinity> Was I on crack last night?
<infinity> Poooossibly.
<cjwatson> Ah well, no harm :)
 * infinity shrugs it off.
<infinity> This distro needs more bonghits anyway.  We're clearly getting too good at what we do.
<ScottK> I managed to use my hint file to force the rest of KDE 4.9.80 into raring.  cjwatson: Thanks for the tutorial a couple of days ago.
<cjwatson> you're welcome
<infinity> Oh, and I finally got rid of that NBS linux-source-3.5.0
<ogra_> ogra@nexus7:~$ apt-cache madison ubuntu-defaults-nexus7
<ogra_> ubuntu-defaults-nexus7 |       0.35 | http://ports.ubuntu.com/ubuntu-ports/ raring/universe armhf Packages
<ogra_> ubuntu-defaults-nexus7 |       0.36 | http://ports.ubuntu.com/ubuntu-ports/ raring/universe Sources
<ogra_> hmpf
<ogra_> 0.36 was promoted 20h ago according to launchpad
<ogra_> and i see the binary on http://ports.ubuntu.com/pool/universe/u/ubuntu-defaults-nexus7/
<ogra_> did the ports.ubuntu.com publisher fail ?
<ogra_> ogra@nexus7:~/ubuntu-defaults-nexus7-0.36$ apt-cache madison curl
<ogra_>       curl | 7.28.0-2ubuntu2 | http://ports.ubuntu.com/ubuntu-ports/ raring/main armhf Packages
<ogra_>       curl | 7.28.0-3ubuntu1 | http://ports.ubuntu.com/ubuntu-ports/ raring/main Sources
<ogra_> ogra@nexus7:~/ubuntu-defaults-nexus7-0.36$
<ogra_> hmm, seems other packages are messed up too
<ogra_> https://launchpad.net/ubuntu/raring/+source/curl/7.28.0-3ubuntu1 thinks that was published 15h ago
<ogra_> cjwatson, any idea ? smells like the publisher is stuck or so
<ogra_> ot infinity (if still awake) ^^^
<ogra_> *or
<xnox> ogra_: http://ports.ubuntu.com/pool/universe/u/ubuntu-defaults-nexus7/ubuntu-defaults-nexus7_0.36_all.deb
<xnox> ogra_: and rmadison agrees.
<ogra_> not here (see above )
 * ogra_ reboots, thats freshly after install without reboot, lets see if something changes
<ogra_> aha
<ogra_> this apt-get update run takes significantly longer now
<ogra_> yeah, now it works
<ogra_> weird
<ogra_> i wonder if it has to do with the change of the hostname
<ogra_> like the other services we identified (rsyslog etc)
<xnox> ogra_: in other news. ubiquity should be fully published now & next respin should drop metacity. Apart from germinate rdepends are not updated yet =/ so not sure if it's still seeded or not.
<ogra_> we'll see
<ogra_> no hurry at all
<ogra_> hmm, why are kpartx and lvm2 hard deps of ubuntu-minimal/-standard
<ogra_> oh, they arent, dmsetup is
<ogra_> flash-kernel: installing version 3.1.10-8-nexus7
<ogra_> Flashing kernel and initramfs to /dev/mmcblk0p2... /dev/mmcblk0p2: updated is too big for the Boot Image (8472576 vs 8388608 bytes)
<ogra_> *sniff*
<ogra_> even when droping everything from the initrd, setting MODULES=list and swithcing to xz compression i cant get the initrd small enough
<ogra_> ah, shiny, weeding out more stuff manually makes it work (sadly right at the edge of teh size limit)
<cjwatson> Could somebody NEW that batch of gettext binaries?  It should make a big difference to cross-buildability.
<didrocks> cjwatson: the dep from the -dev on Depends: libgettextpo0 (= 0.18.1.1-10ubuntu1) for instance is only fullfilled if the same corresponding arch binary package is installed, right?
<didrocks> (because the corresponding libgettextpo0 is multiarch: Same as well, not foreign I guess, but just checking before acking, it's my only question, otherwise, looks good)
<cjwatson> didrocks: That's right, yes - an M-A: same package may not satisfy a dependency of a package of a different architecture
<cjwatson> (https://wiki.ubuntu.com/MultiarchSpec)
<didrocks> cjwatson: excellent, NEWed then :) (and tab opened)
<cjwatson> Great, thanks
<cjwatson> I'll be able to kick off my cross-builder in a bit and see how much further it gets ...
<cjwatson> Currently engaged in reverting all the gettext:any build-deps we used to have, which wasn't a scalable approach
<didrocks> oh right, good goal :)
<cjwatson> Hmm
<cjwatson> I think I'm going to make raring-proposed â raring propagation require powerpc again - the current arrangement causes problems with powerpc-only packages
<Laney> seems relatively caught up anyway
<cjwatson> (they get propagated almost immediately, but there are no binaries to copy so the package copier refuses to copy the source, and then the build comes along and is rejected because the publication in -proposed has been deleted and it's a build for a superseded source)
 * cjwatson audits
<ScottK> BTW, For kalgebra I had removed the armhf binary since it looked like one of it's dependencies (cantor) would be unbuildable on armhf for an extended period.    It turned out cantor got fixed by upstream very quickly and after it was built and kalgebra got retried and built, armhf migrated fine.
 * Laney adds self a hint file to hold some gstreamer back for a little while
<plars> I don't recall what the latest word was on this - we have a lot of warnings all over the place for oversized images, but does the release team want a bug for that also? Many of the precise images are oversize now in the dailies
<Laney> there's a daily email report for that so a bug wouldn't add much
<cjwatson> plars: we get mailed daily about it, so ... what Laney said
<plars> Laney, cjwatson: so we currently duplicate this check in some iso smoke tests in the lab, causing a daily job failure now.  I think I'm going to take this test out since it just duplicates the existing checks you are getting notified about, but we'll rely on you guys to handle it in that case
<cjwatson> Yeah, I don't think we need to be notified in two places
<cjwatson> And it probably obscures other things that are less easily detectable elsewhere
<plars> exactly, thanks
<bdmurray> cjwatson: since I'm not in ubuntu-archive anymore I can't remove packages from the archive - a couple of weeks ago slangasek mentioned opening a launchpad bug about granting the SRU team access to remove packages.  Does that seem best?
<bdmurray> In the meantime could somebody remove yaml-mode from lucid-proposed?
<cjwatson> The implementation would be more about granting removal permission to people with queue admin permissions on the relevant context
<cjwatson> We shouldn't be special-casing ubuntu-sru
<cjwatson> give me a removal reason string and I can remove it
<bdmurray> "Not verified within a timely fashion."
<cjwatson> bdmurray: done
<bdmurray> and samba in lucid-proposed for the same reason
<cjwatson> bdmurray: done
<bdmurray> thanks
<micahg> stgraber: is that queuebot's fault on lxc (using the backport version vs proposed) or something else?
<stgraber> micahg: yep, infinity spotted that bug before, I need to teach queuebot to look in the right pockets instead of doing a generic lookup in the whole series
<micahg> bdmurray: I would think that failed-srus would go back to triaged, not won't fix
<TheDrums> Howdy.  I'm wondering if there'd be a chance that the released ISOs would switch to XZ compression?  This would give the teams (Xubuntu for one) more room to breath.
<micahg> TheDrums: no, this has been brought up before, unless Xubuntu doesn't want its image to be rsyncable (and then it's only maybe)
<bdmurray> micahg: okay, that seems fine
<TheDrums> micahg: Ah, sorry then.
<slangasek> hmmmm, update-manager is showing me wrong changelogs for SRUs
<slangasek> server-side breakage on changelogs.u.c?
<slangasek> aha, it's because of NEWS.Debian in the packages
<slangasek> (bug #1084715)
<ubot2> Launchpad bug 1084715 in update-manager (Ubuntu) "update-manager showing wrong NEWS.Debian entries for SRUs" [Undecided,New] https://launchpad.net/bugs/1084715
<seb128> slangasek, that bug description is confusing (or did I overlook something?)
<seb128> slangasek, you wrote what it should show but you didn't describe what it's actually showing?
<slangasek> seb128: it should only be showing the changelog entry
<slangasek> none of the NEWS is actually news
<slangasek> so which flavors are in fact doing alphas this cycle?
<slangasek> the release schedule says the first of these is due to happen next week
<ScottK> Kubuntu is
<ScottK> We've actually been doing some installer testing this week and making sure we had all the KDE stuff we want landed.
<slangasek> ok, cool
<ScottK> Riddell: ^^^
<ScottK> I don't think anyone else is, but I'm not certain.
<slangasek> I was just talking to stgraber, as we noticed he has a work item about determining who "the release drivers are for each milestone", and we were trying to puzzle out what that actually means
<slangasek> seems like we should know that in time for the first milestone :P
<ScottK> Until we non-Canonical can respin images, I think who it is needs to be Canonical.
<slangasek> right, I was guessing that's what it was
<ScottK> I agree about knowing who it is.
<ScottK> We should also work on messaging this early too.
<stgraber> ok, so the work item is mostly about nagging people to put their name on https://wiki.ubuntu.com/RaringRingtail/ReleaseTaskSignup then?
<slangasek> perhaps nagging is not the best modality, but yes :)
<stgraber> I'm happy to take alpha-1, that'll let me check that the new manifest + auto-copy of build entries on the tracker works as expected
<slangasek> stgraber, cjwatson, infinity: should we draw straws wrt driving nusakan?
<slangasek> stgraber: great, I was just about to nominate you for alpha-1
<stgraber> see, you didn't even have to ;)
<stgraber> hmm, I guess I can take Check list tracking too for a1, if that's just about following the list on the wiki and making sure everything gets done
<slangasek> I'm afraid I have no idea what those different columns are for
<slangasek> except the nusakan one which is obvious
<stgraber> my interpretation is: nusakan => trigger the builds, checklist => follow the matching wikipage and make sure all entries get done, release-notes => poke people to update the wiki pages and send the announcement, qa-contact => who's looking at the bugs on the QA side
<stgraber> I'm happy to take the first three unless someone desperately wants to do the paperwork part, for QA, my guess is that it'll be balloons as it's going to be a non-Canonical flavour only run?
<slangasek> right; columns 2-4 are things that I would expect to be handled by the flavors that are particpating in the milestone
<ScottK> slangasek: 2 - 4 or 3 - 5?
<slangasek> ScottK: sorry, was only counting the signup columns
<ScottK> OK.
<stgraber> well, it was decided at UDS that it'd be the release team doing the announce for the non-Canonical milestones as was done in the past. So there's definitely going to be more involvment from the flavour leads to actually give us the content and do all the testing, but the checklist and announcement should still be done by the release tam
<stgraber> *team
<ScottK> Also, for the U-D-A Alpha announcement we need to figure out the template that we'll use to explain who is participating in the Alpha and who is not.
<ScottK> Right, but we can write the part of the content that explains Ubuntu desktop, Ubuntu server, etc are not participating due to switching to a continuous integration model.
<stgraber> yep, that definitely needs to be the first paragraph of the announcement, to avoid confusing everyone
<ScottK> I suspect there are people inside Canonical that want a chop on that boilerplate.
<slangasek> plausible ;)
<ScottK> If only the relevant Canonical manager were on IRC right now ...
<stgraber> ok, so for now I updated the wiki to be me for all first 3 columns and balloons for QA relations, I plan to heavily delegate on the participating flavours however :)
<ScottK> Excellent.
<balloons> stgraber, signed me up eh?
<stgraber> I'll send an e-mail shortly to ubuntu-release@lists.u.c to see exactly who's participating so they can be added to the alpha-1 manifest
<stgraber> balloons: totally did :) I figured you'd be the best point of contact for flavours testing for their alpha-1 next week :)
<balloons> stgraber, so what all is being asked of me?
<balloons> I can help any of the flavor leads use the tracker, etc
<stgraber> balloons: basically help them if they have some problems with their testcases and keep an eye on the bugs being reported for any critical looking ones.
<stgraber> balloons: which I assume you do pretty much everyday anyway
<balloons> fair enough.. just wanted to clarify I won't be running any of the milestones.. I want to see the flavors take ownership of them, and it seems like that's going well
<bdmurray> There are 2 versions of libgpod in the quantal -proposed queue both of which look the same based off their launchpad generated diffs.  Is that information to reject one or is there something more I should look at?
<slangasek> do they both have the same .changes file?
<slangasek> (one might be missing changelog entries it should have)
<bdmurray> no, the checksums are different
<stgraber> highvoltage, Riddell, gilir, knome: I'd appreciate it if you could read and reply to my e-mail to ubuntu-release@lists.u.c
<knome> will do. thanks for hilighting
<stgraber> and if any of you see Scott Lavender online, please forward this ping :)
<slangasek> bdmurray: hmm, which checksums?
<slangasek> the ones within the .changes?
<bdmurray> slangasek: right
<knome> stgraber, xubuntu won't be participating. do you want an email reply with that too?
<slangasek> bdmurray: looks like it doesn't matter, then
<stgraber> knome: that'd be great so those who aren't on IRC know what to expect
<knome> stgraber, ok, i'll do that! :)
<knome> stgraber, done
<stgraber> thanks
 * med_ wonders how to get some attention to a SRU candidate
<med_> bdmurray,  maybe...  https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= walinuxagent?
 * bdmurray wonders what med_ means by candidate
 * med_ should read more on the process to determine what state that really is in
<infinity> med_: I haven't looked yet, but does one of the bugs referenced in the changelog explain the rationale for this being backported to precise?
<infinity> med_: (I can probably guess that on my own from the package name, mind you, but some sort of "this is how we plan to test it on precise" would be nice)
<med_> infinity, we plan to test it heavily on precise.
<infinity> med_: A changelog telling me that it fixes a critical bug is somewhat meaningless when it disn't exist in precise before. :)
<infinity> By definition, it's more buggy than the version that was there before. :P
<med_> infinity, nod, it was included in the image put into the Microsoft Azure cloud (as we were too late to make the precise release)
<med_> but it is a required agent for the Azure cloud
<med_> (ie, Ubuntu won't work at all without it.)
<infinity> Ahh, so we're shipping a non-archive versions of this in our images?  Ick.
<med_> ick is correct.
<infinity> At least one of those bugs referenced in the SRU might want to mention that fact.
<infinity> Makes the SRU far more justifiable. :P
<med_> okay.
<infinity> Otherwise, yeah, I see no huge problems with the concept of accepting this.  I'll review it in a bit.
<bdmurray> infinity: thanks
<med_> thanks both.
<med_> infinity,  I put a comment #9 into 1079897
<cjwatson> slangasek: I'm fine with helping out for future milestones
<cjwatson> But sounds like this one is dealt with
 * slangasek nods
<cjwatson> This one may need some help from me to get britney set up to block things as needed
<cjwatson> BTW, I'm off work tomorrow - daughter's birthday
 * med_ suspects that daughter was in copehagen
<cjwatson> med_: Yeah
<stgraber> cjwatson: oh right, I meant to ping you about the per-source migration freezes in britney. I'm hoping we won't have to do any of that for alpha-1 but it's an option we said we'd give the flavours, so ...
<cjwatson> Right.  Er, somebody gets to generate a great big list and we'll plug it in, I guess.  I don't think we'll have anything more dynamic available in short order
<stgraber> yeah, for now I expect them to give me a list of source package names that they want to hold, so in theory, no auto-generated bits
<stgraber> if they all come with huge lists, then we'll probably need to figure out how to automate that stuff, but I doubt that'll be the case for alpha-1
<cjwatson> It'd be nice to be able to freeze by package set or by Priority or Task or something.
<infinity> I'm personally kinda hoping they decide they don't need this feature, but we'll see how A1 goes.
#ubuntu-release 2012-11-30
<infinity> For those who care, britney now knows about debian-installer-images and their dependencies, so kernels won't migrate and break d-i.
<stgraber> nice
<infinity> stgraber: Just don't look at the commit that made this happen, you'll vomit a little.
<infinity> stgraber: But the results are convincing:
<infinity> Trying easy from autohinter: linux-armadaxp/3.5.0-1604.6 linux-meta-armadaxp/3.5.0.1604.6
<infinity> leading: linux-armadaxp,linux-meta-armadaxp
<infinity> start: 223+0: i-106:a-47:a-30:p-40
<infinity> orig: 223+0: i-106:a-47:a-30:p-40
<infinity> easy: 224+0: i-106:a-47:a-31:p-40
<infinity>     * armhf: debian-installer-images
<infinity> FAILED
 * infinity thinks this deserves a drink.
<stgraber> aren't you supposed to drink before you touch britney's code?
<infinity> Possibly.  I just mixed a gin and tonic that's so strong it smells more like alcohol than anything drinkable, so this might retroactively make me drunk last week.
<infinity> ScottK: The NBS report would lead me to believe that your force-hinting KDE was a bit premature.
<infinity> ScottK: (And maybe that's why you needed to force it at all...)
<infinity> ScottK: Fixing up now.  But yeah, kphotoalbum and kamoso needed transitions to new libs, which was likely why you had to force things. :/
<infinity> ScottK: Oh, and both need porting, not just rebuilding.  Bah.
<infinity> ScottK: This is kinda what the whole migration thing is for, no?
<bjf> infinity, your no fun, we live to break d-i
<infinity> bjf: :)
<ScottK> cjwatson: Would it be possible to add ffmpegthumbs, kfloppy, kiten and pairs to the Kubuntu packageset in quantal (I believe they are in it for raring already).  It would make getting post-release KDE updates uploaded easier.
<micahg> ScottK: can you please score https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4022293 up to 20000
<ScottK> How about 9999999?
<micahg> I'm not that worried about stuff jumping ahead :)
<micahg> but that works, thanks
 * micahg just hopes everything finishes in time...
<ScottK> micahg: Does firefox on armel need retrying?
<ScottK> (quantal)
 * ScottK does.
<ScottK> Actually it was oneiric.
<infinity> ScottK: Ahh, nevermind my whining earlier, I caught backscroll from 4 days ago and saw this was discussed.
<infinity> ScottK: Still, naughty. :P
<seb128> powerpc  	2 	57 jobs (28 hours)
<seb128> shrug
<seb128> cjwatson, hey, did you restore the "need ppc build to migrate to raring"?
<seb128> https://launchpad.net/ubuntu/raring/+source/accountsservice/0.6.29-1ubuntu2 didn't migrate this night
<infinity> seb128: Yes, he did.  Right before we killed the buildds with a ton of security updates.
<infinity> seb128: Partial migration was causing some unintended side effects.
<seb128> infinity, is there any way around waiting that backlog to resolve itself?
<seb128> or we are just doomed at waiting monday to get stuff in raring at this point?
<infinity> seb128: If what you're worried about it in main, it'll resolve itself quite quickly.
<infinity> seb128: webkit is almost done, and firefox will be done in a few hours.
<infinity> s/it in/is in/
<seb128> infinity, I'm worried that stuff I uploaded 16 hours ago are still blocking in raring-proposed
<infinity> Well, worry less?
<seb128> and that the builder package announces a 28 hours backlog
<infinity> Having this discussion every second day won't solve anything.
<ogra-cb_> hey, think positive, it willl be there on monday :P
<seb128> infinity, well, I was trying to see if cjwatson was wanting to relax the powerpc requirements again :p
<infinity> seb128: See above, re: Partial migration was causing some unintended side effects.
<infinity> Anything after that line was pretty much not constructive.
<seb128> sorry about that
<seb128> it's frustrating to be blocked for days and have no way out
<ogra-cb_> seb128, welcome to my world
<Daviey> ScottK: Remember the thread earlier this year about irqbalance being added to ubuntu-standard?  Did it go anywhere?
<Daviey> (^ or anyone else)
<ogra-cb_> seems to be installed by default
<ogra-cb_> i see it on my nexus installs :)
<Daviey> ogra-cb_: why?
<Daviey> as in, where are you seeing it seeded, depended?
<ogra-cb_> running
<ogra-cb_> havent checked seeds
<Daviey> doesn't seem to be directly seeded.
<Daviey> People seem to remember it being installed by default on server... but i fear it was lost.
<ogra-cb_> ogra@chromebook:~$ apt-cache show irqbalance |grep Task
<Daviey> Ah, lucid added it to standard
<ogra-cb_> Task: standard, kubuntu-active
<ogra-cb_> ogra@chromebook:~$
<Laney> ubuntu-standard
<ogra-cb_> no idea why its seeded explicitly in kubuntu-active though
<Daviey> Hmm.
<cjwatson> seb128: I put it back because it turns out that relaxing it breaks powerpc-only packages.  I might relax it again if I have a chance to fix that - which won't be today because I'm on holiday.
<seb128> cjwatson, hey, ok, enjoy your holiday ;-)
<seb128> cjwatson, with some luck by monday the backlog will be cleared
<cjwatson> I expect it'll be fine - it was clear when I looked yesterday evening.
<infinity> Yeah, even without rescuing sulfur, the backlog will clear.
<infinity> Unless miach uploads another firefox security update and another, and another. :P
<infinity> But here's hoping we get sulfur sorted today anyway.
<seb128> we got unlucky, the first thing ross picked after webkit is a kde package which takes 4.5 hours to build
<seb128> unlucky or not, the score seems to have been bumped for that build so somebody wanted it ;-)
<infinity> That wasn't bad luck, that was ScottK scoring it up. :/
<infinity> Had I noticed before it got picked up, I might have undone that.
<infinity> But oh well.
<infinity> Everything needs to build eventually anyway.
<seb128> (I hope accountsservice will not have runtime issues when it hits the archive during the W.E)
<infinity> You can test it from proposed...
<seb128> I'm running it since yesterday
<seb128> but I get I will have feedback from users until it reachs raring
<infinity> I'd say that sounds like it doesn't have massive issues, then.
<seb128> no it doesn't, I just hate things landing on friday, just being paranoid ;-)
<seb128> you never know, I didn't test on all archs for example
<infinity> Well, I scored it up.  It'll be the next thing to build when firefox is done.
<seb128> thanks
<ScottK> Sorry, trying to get things in shape before the weekend for Alpha 1.
<infinity> I spent a couple of minutes on porting kphotoalbum and then got distracted.
<ScottK> infinity: There's an upstream branch we should get ~sson.
<ScottK> soon
<ScottK> Same for Kamoso
<ScottK> For Alpha 1 it's just an extra copy of the libs, so I'm not worried.
<Mirv> RAOF (or someone else on SRU team): hi! we'd need to pull out the quantal Unity 6.12.0-0ubuntu0.1. there is a regression (currently documented in bug #1067357 comments) and we need that to be fixed.
<ubot2> Launchpad bug 1067357 in Unity "Top panel shows "Tauler d&apos;inici" instead of "Taluer d'inici"" [Low,Fix committed] https://launchpad.net/bugs/1067357
<Mirv> the bug is marked verification-failed, but mostly it's no use keeping the release in -proposed if we anyway know we want to have the regression fixed
<infinity> Mirv: I can delete it from -proposed, sure.
<Mirv> infinity: thanks
<infinity> Just unity?
<Mirv> infinity: just unity, compiz SRU is going on good
<Mirv> and just quantal
<infinity> Done.
<ScottK> infinity: Am I wrong re kamoso and kphotoalbum that the only negtive effect is two copies of the relevant libs on our images until they kamsos (that's the only one that's seeded) gets ported?
<infinity> ScottK: No, you're not wrong, that's the effect, but I also don't want this to be habit forming. :P
<infinity> ScottK: Half the point of proposed is to make sure transitions happen before migration, not after.
<ScottK> Sure.  I agree about habit forming, but I'm not going to get grumpy about a few leaf packages.
<infinity> Alright, buildd chroots updated yet again, let's see how quickly the PPC queues dry out.
<ScottK> infinity: There's KDE SC 4.9.3 in queue for quantal-proposed, so "not soon".
<infinity> ScottK: Oh, right, do you plan to get all that stuff accepted over the weekend?
<ScottK> Yes.
<infinity> Shiny.
<ScottK> I reviewed the queue last night and had a few issues, so I'm waiting for more uploads, but I'd hoped to start today.
<micahg> ScottK: thanks for the Firefox retry
<ScottK> You're welcome.
<micahg> hrm, lucid failed too...
<micahg> I'm a bit reluctant to retry right now though
<infinity> Why?
<infinity> micahg: Were the sparc and ia64 failures expected?
<micahg> infinity: yes
<micahg> infinity: release is soon and I won't be around in 11 hours for it to finish, lucid armel is also EOL
<infinity> That looks rather fixable...
<micahg> infinity: sparc and ia64? probably fixable, but I doubt people are running desktops on those machines, also we haven't really had any complaints...
<infinity> micahg: Yeah, I'm not hugely concerned about lucid/armel, just curious.
<micahg> infinity: if it wasn't Fri today, I'd probably retry it FWIW
<infinity> I'm not sure a retry will get you anywhere.
<infinity> Unless this was before GCC's automagic ICE-retry magic was added.
<infinity> Cause if it was cosmic rays, it would retry, and tell you it wasn't reproducible.
<micahg> infinity: there were no code changes in that part of the source, so that leads me to believe it's cosmic rays
<infinity> Tis possible.
<infinity> FWIW, Pete just bought a big bag of heatsinks for the Pandas in the DC.  Kinda curious to see if any of our weird ray-related bugs dissipate.
<infinity> (Even if they don't, though, the Pandas will get faster...)
<infinity> The joys of CPUs that can't actually run full speed without constantly throttling to avoid overheating.
<Laney> mmm rays
<ScottK> Apparently we're still making Kubuntu dailies for alternate images.  Those can go away.
<stgraber> ok, I'll remove them from cron
<ScottK> Thanks.
<ScottK> stgraber: Can you remove the existing raring alternate daily alternates so they don't show up as there, but not updated?
<stgraber> yep
<stgraber> ScottK: all done
<ScottK> stgraber: Thanks.
<SpamapS> Hi, can somebody who understands the archive better than me take a look at the walinuxagent package in the precise upload queue? Its New, and in "universe", but walinuxagent is supposed to be in main (it has to go on the cloud images)
<ScottK> SpamapS: You have to override it to Main if that's where you want it.
<ScottK> New packages always default to Universe
<SpamapS> utlemming: ^^ I seem to recall walinuxagent getting a MIR for this explicit purpose at some point.
<utlemming> SpamapS: Yes, this went through a MIR....let me dredge that up
<utlemming> https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1014864
<ubot2> Launchpad bug 1014864 in walinuxagent (Ubuntu Quantal) "[MIR] New package - walinuxagent" [High,Fix released]
<SpamapS> utlemming: but thats quantal...
<ScottK> If it were me, I'd at least want the Security team to ack they were ok with it for an LTS release.
<SpamapS> I feel like thats already been done
<utlemming> SpamapS: this MIR covers the 12.04.1 bits too
<SpamapS> ok cool
<jamespage> SpamapS, I think its showing up in NEW for precise cause it only exists in -updates if that makes sense
<infinity> SpamapS: I was going to be sorting that.
<SpamapS> infinity: ahh thank you
<ScottK> jamespage: Yes.  It's in New because it's New for that release.  The same thing happens with backports.
<jamespage> ScottK, ack
<med_> thanks guys
<bdmurray> slangasek: xf86-input-evtouch in lucid can be removed as the verification never happened
<slangasek> bdmurray: removed
<bdmurray> slangasek: unity in oneiric
<bdmurray> slangasek: multipath-tools in lucid
<bdmurray> slangasek: libcgroup in oneiric
<slangasek> bdmurray: nux/o-p, multipath-tools/l-p, libcgroup/o-p removed
<bdmurray> slangasek: libdvdread in oneiric
<slangasek> done
<bdmurray> slangasek: distribute in oneiric
<slangasek> done
<bdmurray> slangasek: mawk in lucid
<bdmurray> slangasek: libxi in lucid
<bdmurray> slangasek: dbconfig-common in lucid
<bdmurray> slangasek: libchewing in lucid
<slangasek> bdmurray: all gone
 * ScottK tries to kill the queuebot.
<ScottK> Interesting.  It seems to have eaten my accepting kde-l10n-* for quantal-proposed entirely.
<bdmurray> slangasek: udisk in oneiric
<bdmurray> er udisks
<bdmurray> slangasek: mesa in oneiric
<bdmurray> slangasek: eggdrop in oneiric
<bdmurray> slangasek: indicator-datetime in oneiric
<slangasek> bdmurray: done
<bdmurray> slangasek: postgis in oneiric
<bdmurray> slangasek: pyfits in lucid
<bdmurray> slangasek: pam in lucid
<slangasek> oh no
<slangasek> not pam!
<slangasek> (is that mine?)
<bdmurray> bug 586462
<ubot2> Launchpad bug 586462 in pam (Ubuntu Lucid) "/sbin/pam_tally2 not included in package" [Medium,Fix committed] https://launchpad.net/bugs/586462
<slangasek> why, it sure is
<bdmurray> slangasek: seabios in lucid
<slangasek> trying to decide how I feel about the pam one.  I've never used the darn module so am not really in a position to test... so... ok, kill it
<slangasek> (done)
<bdmurray> slangasek: w-scan in lucid
<bdmurray> slangasek: gst-plugins-bad0.10 in lucid
<bdmurray> slangasek: vim-addon-manager in lucid
<bdmurray> slangasek: clutter-gst in oneiric
<bdmurray> slangasek: gdevilspie in oneiric
<bdmurray> slangasek: bamf in oneiric
<bdmurray> slangasek: initramfs-tools in lucid
<cjwatson> ScottK: I've added those four sources to the kubuntu/quantal package set.
<ScottK> cjwatson: Thanks.
<ScottK> infinity: I just put caph on manual due to multiple chroot failures.
<slangasek> bdmurray: all done
<bdmurray> slangasek: thanks!
<ScottK> Strange.
 * ScottK did not accept two marbles.
#ubuntu-release 2012-12-01
<cjwatson> slangasek: ^- above ubiquity upload is for the bug we discussed in Wednesday's team meeting; it did indeed turn out to be an issue with signed kernel handling
<ScottK> infinity: I put chort onto manual due to chroot problems.
<infinity> Ugh.
<infinity> ScottK: Thanks.
<ScottK> No problem.
<ScottK> Glad I have powerz because it's be tough to get this KDE SRU building right on all archs without it.
<infinity> ScottK: Just don't let the powerpc queue empty, or you'll end up stuck behind a chromium and a kernel.
<ScottK> Yeah.  No danger of that.
<infinity> Not that I wouldn't like to see that kernel build some day. :P
<ScottK> I think it'll get built this weekend.
<infinity> Seems likely.  The queue's not as deep as LP thinks it is.  It kinda sucks at math.
<ScottK> Timewise with KDE, I'm thinking armel might lose the race.
<infinity> I'm just afraid we'll keep bumping off Pandas all weekend.  Hopefully they won't all follow caph and chort.
<infinity> ScottK: I'm finally letting that kernel trickle through on ross, adare should finish chewing through the KDE stuff on its own, I imagine.
<ScottK> infinity: I'm sure we'll get there.
<infinity> ScottK: Yeah.
<infinity> ScottK: https://launchpad.net/ubuntu/quantal/powerpc/+builds?build_text=&build_state=pending is nearly cleared out, so we should be in good shape.
<infinity> ScottK: Oh, and kdeplasma-addons is dep-wait all over.
<ScottK> Yeah.  Fixing right now.
<ScottK> We didn't upload the packages that had no changes in them and that had a versioned b-d on one of them.
<infinity> build-dep version too high, or missed an upload of the newer libkexiv?
<infinity> Ahh, I guess you just answered that, if it had no changes.
<ScottK> It's a bit of an abuse technically, but we use versioned b-d to make sure everything builds against the same version of the KDE libs.
 * infinity nods.
<ScottK> Just uploaded it.  Would you please review/accept when it hits the queue.
<infinity> Sure.
<ScottK> Thanks.
<ScottK> Had one chroot failure on nikusui while I was sleeping.  When I retried the package it landed on nikusui again and was fine.
<ScottK> More cosmic rays I guess.
<ScottK> infinity: What to do about https://launchpad.net/ubuntu/+source/rocs/4:4.9.3-0ubuntu0.1/+build/4027053 - it finished hours ago and then, apparently, got stuck.
<ScottK> https://launchpad.net/ubuntu/+source/audiocd-kio/4:4.9.3-0ubuntu0.1/+build/4026342 is hung up as well, although rather earlier in the process.
<infinity> ScottK: I can force them to get retried, but at the expense of knocking another two Pandas out for the weekend.
 * infinity shrugs.
<infinity> May as well.
<ScottK> I think they are knocked out either way.
<ScottK> Thanks.
<infinity> Yeah, fair point.
<infinity> Hrm, curious.  buildd-manager reaped and reassigned one of them, but not the other.
<infinity> I think it may have forgotten that altais exists.
<infinity> ScottK: Is this "call an emergency number" urgent, or can I see if anyone's idling this weekend to fix it, and otherwise make it happy Monday morning?
<infinity> (Well, Sunday night when APAC gets in)
<ScottK> Not an emergency.
<ScottK> It has to sit iin -proposed for a week anyway.
<ScottK> And I won't release it to updates during the weekend, so it doesn't actually affect the timeline.
 * infinity nods.
<ScottK> The only thing it really affects is that's one more tab in my browser I could close.
<ScottK> ;-)
<infinity> Heh.  It's two tabs in my browser, and a query window or two in my IRC client.
<infinity> You can ignore it. :P
<bdmurray> slangasek: protobuf in oneiric can be removed due to lack of verification
<slangasek> infinity: hmm, so I hadn't accepted the ubiquity SRU yet because I don't see a test case for bugs 1068178 and 1024343; AIUI this is a race condition of some kind
<ubot2> Launchpad bug 1068178 in ubiquity (Ubuntu Precise) "ubi-usersetup failed with exit code 1 on preseeded - encrypted-home installations on precise" [High,Fix committed] https://launchpad.net/bugs/1068178
<ubot2> Launchpad bug 1024343 in ubiquity (Ubuntu) "Quantal desktop encrypted home unable to install due to ubi-usersetup failing with exit code 1" [Critical,Fix released] https://launchpad.net/bugs/1024343
<slangasek> bdmurray: removed
<ScottK> infinity: ^^^ there you go.
<ScottK> We might even get the powerpc swamp drained today.
<xnox> slangasek: accepted ubiquity srun into proposed or into updates?
<xnox> wait it is in proposed now.
 * xnox goes to investigate.
 * xnox commented on the bugs.
<xnox> slangasek: the test case for the both bugs is fully automated installation via preseed file attached to one of the bugs. Which is also availalbe from ubuntu-iso-testing bzr branch and is continuously run in jenkins.
<xnox> infinity: can you comment on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1068199 is it lucid only or should be applied to other releases as well?
<ubot2> Launchpad bug 1068199 in eglibc (Ubuntu Lucid) "please add support for MAP_HUGETLB in eglibc for Lucid" [High,In progress]
 * xnox should have gone to -devel.
#ubuntu-release 2012-12-02
<infinity> xnox: It doesn't need to be fixed in eglibc at all, stokachu was testing a fix I gave him for the hugetlbfs package.
<infinity> slangasek: Yeah, as xnox said, the jenkins pass/fail seemed a reasonable enough test-case, despite the lack of SRU headers in the description to that effect.
<slangasek> xnox, infinity: perfect, thanks
<infinity> slangasek: I kinda want to close #1001904 with extreme prejudice, but I'm curious why you didn't do so, rather than triaging and assigning it.
<slangasek> infinity: at this point I don't recall
<infinity> Yeah.  I totally missed the assignment happening, just noticed it when wandering through bugs that were assigned to me.
<infinity> But, it only happens if you mix-and-match precise and hardy.  And it's a by-product of apt freaking out and trying to install all the Essential packages you're missing.
<infinity> Which is a handy and useful feature.
<slangasek> infinity: I agree we don't support installation of hardy packages on later releases; and the pastebin is long gone now; grepping logs now
<infinity> But not if you're silly enough to include ancient sources.
<infinity> At least, I assume that's what's happening, cause I can't fathom anyone doing this to themselves on purpose.
 * infinity tosses hardy in a precise chroot for a second to see.
<slangasek> infinity: per the meeting logs, the reason people were doing this is because there's a sun-java package still in the hardy release pocket and they're trying to install it
<infinity> Ahh.
<infinity> Well, we could reintroduce the Replaces, but I really don't think we should carry it "forever" just for this odd use-case.
<infinity> Or reintroduce the sysvutils transitional package.
<slangasek> so if you have logs handy, there was a long discussion in #ubuntu-meeting on 2012-06-06
<infinity> And yeah, just confirmed that adding hardy to sources.list and dist-upgrading pulls in sysvutils
<slangasek> infinity: if you think wontfixing it is the thing to do, I don't have any objection; I think the bug assignment was "delegating" :)
<infinity> Yeah.  I'm reading the log, and not sure we came to a conclusion, per se.
<infinity> The other option is to reintroduce either the replaces or transitional package just for precise, since by the time 14.04 ships, hardy will be EOL, and people still doing this from old-release will be extra insane.
<infinity> But the grumpy old man in me is more on the Won't Fix side of that fence.
<xnox> infinity: ok thanks. Unsubscribed sponsors from the eglibc bug in that case. Thanks for reducing the sponsorship queue \0/
<stgraber> Riddell, ScottK: will Kubuntu do an alpha-1 release?
<phillw> stgraber: do you know who is responsible for the naming of the daily build iso's via the cron job?
<stgraber>  /win 43
<stgraber> phillw: what are you referring to?
<phillw> stgraber: I've had a bug reported... all the network iso's are called mini.iso
<stgraber> and why is that a bug?
<phillw> well, try loading two of them, then using zsync?
<phillw> i686 / AMD64...
<stgraber> just store them on your machine with a different filename?
<phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-amd64/20101020ubuntu195/images/netboot/mini.iso
<stgraber> besides, you can't zsync them as they are on archive.ubuntu.com, not on cdimage
<phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-i386/20101020ubuntu195/images/netboot/mini.iso
<stgraber> sure, that's the filename that debian-installer has always been using for the netboot images, changing that would break a lot of things for close to no benefit
<phillw> So, they are being built daily, but in a totally different naming schedule to the all the isos?
<stgraber> they're not built daily
<stgraber> they're built as part of a debian-installer package build, so they're built whenever someone uploads a new debian-installer to the archive
<phillw> okies, thanks.. i'll be able to reply to the tester for which the names are causing problems
<stgraber> and they're built through the package build process, not through the image build process, that's why they're on archive.ubuntu.com as are all binary packages and not on cdimage.ubuntu.com
<cjwatson> And it's perfectly possible to supply a different output file name when using zsync.
<cjwatson> Or rsync or whatever.
<xnox> phillw: zsync -o flag or wget -O flag.
<cjwatson> I'm responsible for those file names and I won't change them.
<phillw> I see that they only have direct (http) entry for download... sorry.. i didn't look deep enough into the issue reported by the tester.
<phillw> cjwatson: is it possible to zsync when there is no zsync link?
<xnox> phillw: yes.
<cjwatson> If it is, it will provide no meaningful benefit over just using wget.
<xnox> phillw: it will redownload the whole file =)
<phillw> okies, I'll mark it down as "won't fix" :) Thanks for clearing it up.
#ubuntu-release 2013-11-25
 * ogra_ fires off a build with "ARCHES=i386 CDIMAGE_NOPUBLISH=1 for-project ubuntu-touch cron.daily-preinstalled --live" ... please ignore any build failurme mails for this 
<ogra_> curious how far it gets :)
<cjwatson> If you use DEBUG=1 instead then it will dump everything to your console and won't send mail
<cjwatson> (For next time)
<ogra_> cjwatson, ah, i knew i had forgotten something
<ogra_> how did i know that all this diversion madness would bite us some day :P
<xnox> cjwatson: infinity: in build.opensuse.org there is a feature to branch full archive, do a rebuild, merge back all binary builds. The 300 buildds help there. And then merge back. that way one can do large binary transitions quickly and in isolation. We really don't have such capacity, to have disposable non-virt PPAs with hundreds of throw away builds. It would make sense to have binNMUs in Launchpad, which is as lightweight as one can get for bulk
<xnox> of transitions.
<xnox> (re:  CI airline)
<ogra_> xnox, well, doesnt pocket copying from PA to PPA (or to the archive) essentially give us binNMU ?
<ogra_> *from PPA
<xnox> ogra_: not really no. it does a rebuild, but it doesn't bump the version number on the binaries. One cannot have same version number, yet a new checksum on the *.deb. As packages will not be upgraded.
<xnox> in debian there is a "+b$i" suffix added.
<ogra_> ah
<xnox> the pool/ is shared after all =)
<xnox> if copy-package gained --suffix-version-number or some such, that would be sufficient.
<xnox> (or rather mangle)
<cjwatson> xnox: I don't need to be convinced about the utility of binNMUs, although I don't think I've managed to convince infinity yet.
<cjwatson> I don't think it should be overloaded onto copyPackage etc. though.
<xnox> sure, implementation can be a better one =)
<xnox> infinity: i got convinced about binNMUs by Laney. In essence even today we have archive scew and thus we don't have one-to-one relationship between src-BinaryArchBuild. (it may FTBFS on armhf in one series, but succeed in next). Or retries succeed. With binNMUs it would be nice if we could keep each build-record/build-log and thus know how many times and on which builders a package was retried already (with or without version bumps)
<xnox> we do binNMU already in a limited capacity (without version number bumps / when said version didn't manage to build on a given arch yet).
<xnox> \o/
<infinity> xnox: A build retry isn't a binNMU.  Wanting history for retries isn't the same as asking for icky version skews and the problems that come with that.
<infinity> xnox: And I don't get your claiming that we don't have a 1:1 rel between source and binary.  We absolutely do.  Fail-and-then-succeed is still only one binary.  Maybe just not in the release you wanted it. :P
<xnox> infinity: in my world binNMU creates a source record with bumped version & rebuilds across all arches. Cause otherwise it screws one over with version numbers across different arches & breaks multi-arch.
<infinity> xnox: Okay, that's not a binNMU, that's an automated sourceful rebuild, and I'd be all for THAT.
<infinity> xnox: Basically just automating what dch -R does, allowing people to edit the changelog (as Debian binNMUs do), and doing the sign/upload from a host in the DC instead of locally, so it doesn't take someone on dialup 5 days to rebuild openoffice.
<infinity> xnox: Totally cool with that concept.  Not cool with doing it per-arch, which is what a "binNMU" is to most people.
<xnox> infinity: well =) ok, it's like a 1:1 timing subject to a time component =) like integration, which adds an unknown constant value.
<cjwatson> I still prefer binNMUs; the problems with them are eminently solvable, considering that Debian's doing them
<stgraber> infinity: well, unless it's a massive native package, you don't need to re-upload the orig tarball for a rebuild, so it's usually not that big (well, a lot of people seem to forget that you don't have to bundle the orig if it's already in the archive...)
<cjwatson> And I don't think the problems are particularly bad
 * xnox s/timing/mapping/
<infinity> cjwatson: No one's solved the multiarch skew issue.  And, frankly, we're not so low on resources that I care.  The only advantage binNMUs bring is less pressure on the buildd network.
<cjwatson> Also not breaking TIL on merges
<infinity> stgraber: Yeah, I'm fine with the status quo.  But I can much more readily get behind "automated sourceful rebuilds" than "automated binary version bumps".
<cjwatson> Speaking as somebody who's TIL on a bunch of stuff I don't care about due to doing lots of rebuild-only uploads, this is an issue close to my heart
<cjwatson> And the multiarch skew issue was solved in Debian
<cjwatson> OK, worked around, if you care about the distinction
<infinity> cjwatson: Okay, yeah, there's that, I have a ton of rebuild TIL too.  But I'm not sure per-arch binNMU falls out of wanting to fix that.
<infinity> cjwatson: When was M-A skew fixed?
<infinity> cjwatson: Or do you mean just by not amending the changelog?
<xnox> infinity: cjwatson: imho, M-a skew of binnmus, should be solved on dpkg side. It should imho ignore version differences across arches (especially no-change binNMU version differences). E.g.  lib* package which only has multiarched .so files in multiarch locations, should be co-installable despite that usr/share/doc/changelog.Debian.gz is different.
<cjwatson> sbuild now puts the binNMU entry into a separate per-arch "changelog" so they don't clash, IIRC
<infinity> Erm, and does dpkg now let you install foo_1-2:arm64 and foo_1-2+b1:i386 together?
<xnox> infinity: no, it doesn't at the moment.
<cjwatson> Oh I see what you mean, no that still needs to be handled, indeed - the Debian release team just avoids doing such binNMUs
<xnox> cjwatson: do you know if version skew is at all allowed in dpkg yet?
<xnox> ack.
<infinity> xnox: Version skew is intentionally not allowed.
<cjwatson> But there are plenty of non-M-A:same packages where binNMUs are still useful
<infinity> xnox: One could make an exception for binNMU versioning but that means dpkg becoming mre Debian aware than it should.
<xnox> stgraber: well, one typically fetches the whole source package. If it was possible to just fetch .dsc & .debian.tar.gz and do a dpkg -R on it, that would be nice.
<infinity> +b1 doesn't necessarily mean "hey, identical version, new build", except in Debian.
<cjwatson> Or one could look at the Source field
<xnox> stgraber: sure, one will not reupload the orig tarball, but one typically still needs to fetch it.
<infinity> cjwatson: Right, that's probably more sane.
<xnox> yeah, source-version enforcement would be nice. but anyway, i like the idea of "server-side-generated-dch-R style binNMUs"
<cjwatson> The other advantage is that it would make new ports a bit less hair-raising
<xnox> cjwatson: wouldn't that break if one doesn't have -src lines enabled?
<cjwatson> xnox: No
<xnox> ok.
<infinity> cjwatson: Oh, you mean the option to rebuild the world?
<cjwatson> If we get some vital bit of ABI wrong, we wouldn't have to reupload everything arch-dep ...
<cjwatson> Right
<infinity> cjwatson: William and I had been discussing using copy archive for initial bootstraps.
<cjwatson> Even then we don't necessarily realise until later
<cjwatson> cf. ARMvINSANITY
<infinity> (And, to be fair, if we don't care if we have USERS of an arch, we can probably surgically remove it, dump it, and start over)
<cjwatson> Yeah, but why do horrible things when we could do nice things
<infinity> Well, if you're talking a broken ABI, there's often no nice upgrade anyway. :)
<infinity> We did dump and rebuild hppa once for that reason.
<cjwatson> The ARMv7 upgrade and the later ARMv5t downgrade in armel were examples that we really should not have had to do the way we did.
<cjwatson> And dump/rebuild wouldn't have been appropriate there.
 * xnox ponders how far up i386->i686 transition we are.
<infinity> Absolutely not.  Agreed.
<infinity> xnox: Far enough.  Also, doesn't really matter for 99.9% of the archive.
<xnox> yeah, all important binaries have been re-uploaded many times over, since.
<infinity> cjwatson: I dunno.  If we can make dpkg behave, and model it not entirely unpleasantly in LP, I might be sold.  But binNMUs as they exist today in Debian are, other than the TIL annoyance, worse by far than our sourceful rebuilds.
<infinity> (Solvable problems, I agree, but problems that exist)
<xnox> cjwatson: i didn't quite understand version skew solution: for two packages of different architecture, check that they come from the same source, and only then accept "+bN" differences between them on client/dpkg side?
<infinity> xnox: I meant that it didn't matter even before they were reuploaded. :P
<xnox> (if they are m-a:same)
<infinity> xnox: Once they come from the same source version, you don't care about the binary version at all.
<xnox> ah, ok.
<infinity> xnox: In other worse, MA:same version checks should be against source-version, not binary-version.
<cjwatson> Right, that's what I mean
<cjwatson> And better than I could think of how to put it
<infinity> Well, it would have to check source-name:source-version tuple, to be complete, as I could, for instance, upload eglibc 2.18-1 producing libc6 2.18-1 and glibc 2.18-1 producing libc6 2.18-2
<infinity> (I wouldn't, as it's crazy, but there are no tooling or archive constraints preventing me from such madness)
<cjwatson> Indeed
<xnox> i didn't know that "Source: srcname (srcver)" is encoded in the .debs them-self. =) i guess, that's because apt-cache binpackage, doesn't print (srcversion)
<infinity> xnox: It's only encoded if there's a mismatch.
<infinity> xnox: apt-cache show libgcc1, for instance.
<infinity> (I'd argue that the "only if mismatch" behaviour is wrong, and long overdue for fixing, but that's the current state)
<infinity> Would make automating various scanning tooling tons easier if Source: was always complete.
<xnox> i see, yeah, this conditional behaviour of apt-cache is rather inconvenient. Also, i guess since on ubuntu there are no binNMUs the full version is printed rarely.
<infinity> It's not apt-cache, it's dpkg-gencontrol, but yeah.
<xnox> ... or one of the wrapped commands therein =)
<infinity> xnox: I mean, it's not on the mirror side, it's in the deb itself.  dpkg-gencontrol only generates the Source field if source and binary name don't match, and only adds (version) if the versions don't match.
<infinity> So, when you lack a Source field, you assume that Package: and Version: match the source.
 * xnox ponders if there will be the "ultimate wrapper" that wrapps: all apt*, dpkg*, *debuild* tools =))))
<cjwatson> wajig was trying to be that
<cjwatson> I never really got on with it
<infinity> Maybe this made sense back in the days when people thought saving a few bytes here and there was admirable, but it's mostly just confusing.
<xnox> cjwatson: =)))))) was there a wajig-ng re-write in python as well?! =)
<cjwatson> it's been in python since 2001 ...
<xnox> ok.
<cyphermox> xnox: so, removing kmediafactory and kx11grab?
<xnox> cyphermox: yeap, removal request at https://bugs.launchpad.net/ubuntu/+source/kmediafactory/+bug/1254011 should now confirm / subscribe ubuntu-archive to it.
<ubot2> Launchpad bug 1254011 in libomxil-components (Ubuntu) "remove from ubuntu archive - never in debian, no upstream ports to libav9 / dead upstream" [Undecided,New]
<cyphermox> ack
<stgraber> infinity: can you bump this one? https://launchpad.net/ubuntu/+source/android/20131125-1710-0ubuntu1/+build/5267470
<stgraber> the builders seem slightly busy with all those kde packages ;)
<infinity> stgraber: Done.
<stgraber> thanks
#ubuntu-release 2013-11-26
<rsalveti> hey, seems ubuntu-ui-toolkit is published at launchpad but rmadison is not finding it (and it was migrated from proposed more than one hour ago)
<Mirv> the ui-toolkit does not show here in queuebot either btw
<rsalveti> seems the new version just disappeared
<Mirv> the binaries are there too http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-ui-toolkit/
<rsalveti> Mirv: seems it was finally migrated
<Mirv> rsalveti: wow, now...
<rsalveti> weird, took quite a while
<Mirv> eh, interesting
<cjwatson> rsalveti,Mirv: I don't know what was up there; it was pushed to mirrors just before 04:11 UTC (which is a reasonable/expected delay from the publication record flipping to Published state); nothing out of the ordinary that I can see in archive-reports mail
<cjwatson> (which is the bit that syncs things to snakefruit for things like rmadison)
<Mirv> ok
<Mirv> could someone kick rebuild on arm64 https://launchpad.net/ubuntu/+source/upstart-app-launch/0.3+14.04.20131126-0ubuntu1 now that dbus-test-runner is in proposed as well?
<Mirv> there's also an autopkgtest failure but it's related to autopkgtest itself and pitti will rerun the test soon enough now that the 2.5.1 was uploaded
<Laney> done, but depwaits like that will get cleared automatically
<Mirv> thanks. if it's not a heavy poll, maybe the delay could be closer to the amount of wait when waiting for eg. publisher run.
<didrocks> cjwatson, Laney: sorry for my ignorance, but I'm unsure how to read that in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<didrocks> trying: upstart-app-launch
<didrocks> accepted: upstart-app-launch
<didrocks> [â¦]
<didrocks> then, I guess it's autopkgtests result
<cjwatson> well that means it's been accepted ...
<cjwatson> I don't understand the question
<didrocks> cjwatson: oh, there is no "apparently successful"
<Laney> autopkgtest is another package which got accepted
<cjwatson> yes there is
<cjwatson> Apparently successful
<cjwatson> final: autopkgtest,upstart-app-launch
<didrocks> yeah, this is way lower
<cjwatson> yes, as usual
<didrocks> hum, never noticed it was in 2 pass
<cjwatson> AFAICS there's nothing out of the ordinary here
<didrocks> so, the "Apparently successful" is for "final: " which is following it?
<cjwatson> yes
<cjwatson> there's a branch pending review to clarify the whitespace
<didrocks> oh, learnt something today, I was obviously misreading it for month :)
<didrocks> thanks cjwatson
 * stgraber does an SRU run
#ubuntu-release 2013-11-27
<rbasak> May I have an SRU team ack for a Saucy SRU for https://launchpad.net/bugs/1245113 please, before I do the work?
<ubot2> Launchpad bug 1245113 in libapache2-mod-auth-pgsql (Ubuntu Saucy) "libapache2-mod-auth-pgsql is missing in 13.10 amd64" [Undecided,New]
<rbasak> It's a regression - the package was dropped from Debian due to falling behind on the Apache 2.4 transition, and has now been reinstated. Is an SRU for Saucy NEW acceptable here?
<rbasak> I see low SRU regression risk because it would be a new package.
<cjwatson> rbasak: seems reasonable to me
<rbasak> cjwatson: thanks!
<shadeslayer> re posting here since I was asked to
<shadeslayer> are there plans to whitelist arm64 from britney so that packages can transition to -release even if arm64 isn't built?
<cjwatson> shadeslayer: No, quite the contrary, we stopped whitelisting it.
<shadeslayer> ah I see
 * cjwatson looks through the pending failures
<shadeslayer> there seem to be odd segementation faults when unpacking things, or configuring things, at other times there are weird issues with the compiler
<cjwatson> Yes, some of the buildds are unreliable hardware
<shadeslayer> ( unpacking sgml for eg caused segmentation faults , which is just weird _
<cjwatson> But we have 2/4 reliable now
<shadeslayer> oh
<shadeslayer> okay, just annoying it is
<cjwatson> beebe and birch are the reliable ones
<cjwatson> But magic and twombly manage to build enough stuff that it's worth keeping them around until we have better
<xnox> should we cron, auto-reptry if arm64 FTBFS, and last builder is "magic, twombly"? (since presumably any new hardware will be reliable)
<cjwatson> No
<xnox> ok.
<cjwatson> Some of the failures are real
<cjwatson> But feel free to manually retry ICEs labelled as "unreproducible", bizarre segfaults, etc. that occur on magic or twombly
<cjwatson> If necessary we can force them onto beebe/birch, but usually it's worth just retrying a couple of times
<shadeslayer> okay
<infinity> shadeslayer: I've been going through "out of date on arm64" builds and retrying where appropriate, though I haven't done so in the last ~48h.
<infinity> cjwatson: Looks like you've got this round covered?
<infinity> (Though, a lot of the kde/c++ stuff you retried will almost certainly just fail again on poor magic/twombly)
<cjwatson> I did a bunch, yeah.  Figured we could down magic/twombly and try again as necessary
<shadeslayer> infinity: cjwatson can we somehow just whitelist KDE SC packages from britney + on arm64?
<shadeslayer> it's annoying that it's holding back the KDE SC packages, and we don't have the man power to take care of arm64 right now, we usually fix those towards the end of the cycle
<cjwatson> shadeslayer: No.
<shadeslayer> oh :(
<cjwatson> shadeslayer: Not prepared to do that; it makes proposed-migration willing to break other things in poor trade-offs.
<cjwatson> shadeslayer: Besides, KDE SC packages are held back for other reasons anyway
<cjwatson> (e.g. you have armhf failures)
<infinity> shadeslayer: There should be very few reasons why something would have built in the previous version but fail in the current version.  arm64 isn't that particularly weird.
<infinity> shadeslayer: Our flaky builder issue, we'll sort on our end.  Real failures should probably actually be looked at. :P
<cjwatson> Usually the KDE SC problems are that you upload everything in a giant lump and then you don't retry failures due to build-dep ordering ...
<cjwatson> IME every KDE SC upload batch involves me going round retrying stuff
<shadeslayer> build dep ordering? I thought LP took care of things if one of the Build Deps hasn't been built yet so it'll just wait
<shadeslayer> then retry periodically
<cjwatson> e.g. I just retried kalgebra/armhf kanagram/amd64 kanagram/armhf
<cjwatson> It depends on how they aren't met
<cjwatson> If they're directly unavailable, yes
<cjwatson> If one of the build-deps is uninstallable due to something further down the stack, it fails and has to be retried manually
<cjwatson> Which you folks apparently never do
<infinity> Which is a bug on our end, to be sure, but it's been like this for 8 years, you'd think people would notice.
<cjwatson> Right
<cjwatson> I'm pretty sure I mentioned it at the last KDE SC release too :-(
<shadeslayer> sigh, thanks for pointing that out, I'll keep a eye on those from now on
<cjwatson> Right, putting magic and twombly on manual
<cjwatson> Basically, anything in state "Failed to build" is never retried manually
<cjwatson> Er
<cjwatson> Is never retried automatically
<shadeslayer> it's just that I tend to upload towards the end of the day, then let it work overnight, then next morning look at everything
<cjwatson> "Dependency wait" may be retried automatically
<shadeslayer> gotcha
<cjwatson> shadeslayer: I've come along days afterward sometimes.
<shadeslayer> sorry about that
<xnox> shadeslayer: it would auto-resolve if the build-dependencies are more strict e.g. Build-depends: libkde-core (>= $the_just_uploaded_version_of_libkde) across the board, that way it would autoresolve itself overnight.
<cjwatson> Anyway, you're stuck on libav/samba
<xnox> =)
<cjwatson> xnox: No, they generally are strict
<shadeslayer> ^^
<shadeslayer> I think the issue is that the dev package itself might be un installable
<cjwatson> xnox: But if the thing they build-depend on directly is *uninstallable* when the build happens, not just unavailable, nothing auto-resolves
<xnox> right.
<xnox> cjwatson: re:samba -> about 26 packages (libfoo0 & libfoo-dev) from samba4 packages are colapsed into (samba-dev & samba-libs). What's the best way to provide transitional packages? Upload src:samba4 with all of them converted into dummy transitional packages, or to add all of them to src:samba ?
<xnox> (src:samba will need correct Replaces/Conflicts)
<shadeslayer> Riddell: poke https://launchpad.net/ubuntu/+source/calligra/1:2.7.5-0ubuntu2
<cjwatson> do we need transitional packages at all?
<cjwatson> src:samba4 is slated for removal AIUI
<shadeslayer> ah drat, you uploaded it, so someone else must approve
<xnox> cjwatson: right. we don't need them for libs, as everything transitioned to new build-deps / deps in -proposed. But we do need samba4 -> samba transitional package, no?
<xnox> cjwatson: or is it something for people to manually resolve.
<xnox> at the moment, samba4 is uninstallable, are you saying that simply src:samba4 needs to be removed from -release and that's it?
<xnox> well, I blocked it with a bug tag. I should remove the tag I guess.
<xnox> (maybe once libav9 transitions)
<cjwatson> xnox: I don't know, I'm kind of buried in urgent grub2 bugs
<xnox> ok, sorry.
<cjwatson> so hopefully somebody can work it out :)
<xnox> =))))))))))))))) i think, libav will transition once mythtv finishes building in trusty-proposed, and then samba4 can be dealt with separately.
<Laney> oh, that's why output changed
<xnox> Laney: yeah, see excuses.
<Laney> indeed
<xnox> Laney: i'm now slightly confused about samba4. i'll do upgrades in chroot from samba4 installed in trusty -> samba in trusty-proposed and check what happens.
<Laney> xnox: you think we'll need something in addition to what Debian did?
<xnox> i assert that what debian did was not enough, let me verify that.
<shadeslayer> could someone poke at https://launchpadlibrarian.net/157748907/buildlog_ubuntu-trusty-amd64.mdbtools_0.7.1-1_FAILEDTOBUILD.txt.gz < I don't understand why it's failing because it builds in pbuilder and the sbuild I created with sbuild-launchpad-chroot
<xnox> shadeslayer: it's trying to do internet access to www.oasis-open.org ?!
<shadeslayer> oh, dafuq
<xnox> shadeslayer: i think it's missing build-dependencies on local copies of those .dtd enteties.
<shadeslayer> right
<xnox> it is for sure packaged.
<shadeslayer> xnox: so, it builds fine on Debian
<xnox> Laney: so in debian, those that had samba installed get upgraded to samba 4.x series. Those that had samba4 installed on dist-upgrade from stable -> testing get samba4 removed and no samba 4.x installed.
<xnox> granted debian only shipped a beta in wheezy release, but we actually had samba4 released in raring and up.
<xnox> Laney: shouldn't samba4 auto-upgraded to samba package?
<Laney> I suppose so
<infinity> shadeslayer: Without looking at the build log, you're probably missing a build-dep on docbook-xml.
<cjwatson> Debian's builders aren't consistently firewalled from the internet
<infinity> shadeslayer: We don't allow outside internet access from our buildds.
<cjwatson> Ours are
<infinity> shadeslayer: Easiest way to test is to install build-deps in a chroot, then pull the plug on your internets and try the build. :P
<infinity> (Or intentionally break resolv.conf, or similar)
<shadeslayer> okay
<shadeslayer> checking now
<infinity> shadeslayer: But it's probably just docbook-xml you need.
<infinity> We need an sbuild hook that breaks chroot intenet after installing build-deps.
<infinity> That would be handy.
<infinity> Still, not EXACTLY what the buildds see, but a close approximation for most people.
<stgraber> infinity: yeah, I initially wanted to do something like that for sbuild-launchpad-chroot but there wasn't an easy way of getting what I wanted... I think the idea would be to have sbuild have a flag to use CLONE_NEWNET, then create a veth pair on a private subnet and do masquerading on the host side of the pair but only for the archive machines
<infinity> stgraber: Also needs to be able to resolve itself and a few limited machines (like the archive), but nothing else.
<infinity> stgraber: The draconian DNS resolution policy we have has caused some really curious build failures before.
<shadeslayer> apparently also needs rarian-compat
<infinity> stgraber: But just cutting off ALL network works for 99% of tests like this.
<shadeslayer> oh hah
<shadeslayer> debian bug #718465
<ubot2> Debian bug 718465 in mdbtools "mdbtools: Don't build-depend on rarian-compat" [Normal,Fixed] http://bugs.debian.org/718465
<xnox> libav migrated \o/
<mdeslaur> \o/
<Laney> woot
<Laney> xnox: shouldn't you unblock samba?
<xnox> Laney: yeah, will do in a sec. testing it here. it's not quite right, but i think it's good enough. also filed debian bug about it.
<xnox> Laney: once powerpc build is published, it should also all migrate.
<Laney> yes, hence asking about unblocking
<Laney> to not miss a britney cycle
<Laney> looks like src:samba4 still builds some actual packages
<xnox> correct.
<xnox> Laney: there is src:samba autopkgtest running.
<xnox> Laney: and my CI/QA vpn DNS is wrong cause i'm failing to access d-jenkins =(
<xnox> Laney: can you hint it past adt failure? since we know it does pass. and #8 was testing trusty/main instead of trusty-proposed.
<Laney> 10.98.3.6
<xnox> Laney: do you have jenkins-foo to re-trigger adt test?
<Laney> anyone does AFAIK
<Laney> will it pass?
<xnox> yeah.
<xnox> Laney: by jenkins-foo i mean "known where/how to click in jenkins UI" not necessary ACL =)
<Laney> hmm
<Laney> where's the Matrix Reloaded thing gone?
<xnox> oh, lp SSO login =)
<Laney> I've never logged into jenkins
<Laney> is that now required?
<xnox> no idea, but i cannot find a way to retrigger it either.
<xnox> Laney: ah. http://10.98.3.6:8080/job/trusty-adt-samba/build Access Denied, missing the Build permission =(
<Laney> hmm
<Laney> why did it get the trusty-release one?
<xnox> maybe because of my block-proposed bug, britney did version specific adt test of the release version, and jenkins run it.
<xnox> maybe it will request proposed version next time around, and it rerun it =/
<xnox> wait and see i guess.
<Laney> might just force it
<Laney> smells like a bug that this was requested
 * Laney finishes making dinner first
<xnox> darn. samba4-clients is still uninstallabe
<Laney> doh
<xnox> all autopackage tests passed, waiting on samba/armhf
<xnox> Laney: all in =)
#ubuntu-release 2013-11-28
<robru> stgraber, around for a quick NEW review?
<robru> infinity, you around maybe?
<infinity> robru: Sup?
<robru> infinity, oh hey, please NEW review of lp:unity-voice if you have time.
<infinity> I might have time later this afternoovening.
<robru> infinity, ok, no rush. today would be nice. https://code.launchpad.net/~ubuntu-unity/unity-voice/packaging_fixes/+merge/197115 this branch needs to land first anyway.
#ubuntu-release 2013-11-29
<robru> anybody from the release team around? i'm confused by the status of python2.7 in update_excuses. 2.7.6-2ubuntu1 fixes a big regression for us, we need that ASAP
<rsalveti> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libffi failed autopkgtest
<rsalveti> which seems to be holding python2.7
<rsalveti> there was a sync from git-annex today, which is holding everyone
<robru> rsalveti, is it something you can fix? who do we ping about this?
<rsalveti> let me first try to understand why it's failing
<robru> rsalveti, ok, brb. ping me if you need help testing anything.
<rsalveti> seems the tests are all fine, but the ret code is not 0
<xnox> rsalveti: let me look at annex failure.
<xnox> rsalveti: i've fixed it before....
<rsalveti> xnox: ok, cool
<xnox> rsalveti: i see http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-git-annex/10/ARCH=amd64,label=adt/artifact/results/dsc0t-basics-stderr/*view*/ that no tests run, since new version was uploaded.
<rsalveti> right https://jenkins.qa.ubuntu.com/job/trusty-adt-git-annex/ARCH=amd64,label=adt/10/console
<rsalveti> indeed, was opening the last successful one
<xnox> Laney: stgraber: can you mark up git-annex as bad tests? I've opened block-proposed bug #1256143 to make sure that git-annex doesn't migrate, but such that dependencies are unblock to migrate?
<ubot2> Launchpad bug 1256143 in git-annex (Ubuntu) "adt tests borked in -proposed" [High,Triaged] https://launchpad.net/bugs/1256143
<xnox> rsalveti: are you touch-release?
<xnox> rsalveti: touch-release can also mark up git-annex as badtests
<rsalveti> xnox: nops
<rsalveti> cyphermox: ?
<rsalveti> maybe even robru
<xnox> rsalveti: hm, possibly britney will request git-annex trusty-release pocket adt tests and everything will work. this is what happened, last time i requested a block-proposed bug.
<xnox> rsalveti: actually git-annex is not the only problem. libffi is out of date on powerpc
<xnox> rsalveti: and python2.7 is invalidated by dependency on libffi.
<rsalveti> yeah, ftbfs for ppc
<robru> rsalveti, xnox: i dunno anything about that...
<xnox> rsalveti: robru is not in https://launchpad.net/~ubuntu-touch-release/+members
<xnox> rsalveti: anyway, libffi/powerpc should be fixed.
<robru> cyphermox, you around? we need you ^^
<rsalveti> there's no git-annext test anymore
<xnox> robru: even if git-annex is forcedbad tests, libffi must be fixed, cause otherwise there will be huge archive skew.
<rsalveti> seems they removed the test option with latest version
<robru> xnox, any idea how to fix libffi? i've no idea
<xnox> robru: rsalveti: well ffi has missing symbols. not sure why/how.
<xnox> infinity: git-annex test-suite is pending more haskell "echo test suite currently disabled until haskell-tasty is out of NEW"
<xnox> infinity: can you please mark git-annex as badtest? git-annex itself is blocked from migrating by my block-proposed bug, such that we will get new git-annex, only once it has autopackagetest again, but such that it doesn't block the world.
<xnox> (well speficially python2.7 and libffi)
<infinity> xnox: Can do.
<xnox> infinity: thanks.
<infinity> # git-annex is blocked with a migration bug, don't block its rdeps too:
<infinity> force-badtest git-annex/5.20131127.1
<infinity> ^-- That look sane?
<xnox> coreect.
<xnox> correct that is.
<infinity> Test-building libffi out of paranaoia, but will upload shortly.
<infinity> Alright, I'm not sure who between my ISP and Canonical is screwing with me, but this is unaccetable:
<infinity> Fetched 23.0 MB in 4min 1s (95.4 kB/s)
 * stgraber read that as MB/s for a second and wondered what infinity was complaining about again
<infinity> stgraber: Yeah, no.  This is genuinely busted.
<stgraber> infinity: I'm getting somewhere between 15MB/s and 20MB/s from archive.u.c from this side of the country
<stgraber> entirely over Level3 from Montreal to the DC in London
<infinity> stgraber: Yeah.  I'm getting decent saturation on my link to random speedtest.net servers, but all of archive/ports and us.archive/us.ports are a mess for me.
<infinity> (Yes, even the US ones)
<infinity> Not sure who to blame.  I'll care deeply if it persists after I move, and start whining.
<robru> infinity, you on Shaw? Shaw I think has a vendetta against Ubuntu, they will often drop canonical's netblock right off the network (100% packet loss for days), and most of the rest of the time it's very slwo
<stgraber> infinity: interestingly enough I'm only getting 1.5MB/s from us.archive.u.c over IPv4 but I get 50MB/s from the same servers over IPv6...
<stgraber> ah, IPv4 from here to Boston goes through Level3 (same path as to London) but then jumps to Cogent in New York which gives me a final route longer than that to London and the speed that's typical for a Cogent provided link...
<stgraber> infinity: weren't you using a server in the US for the *.ubuntu.com trafic before?
<infinity> robru: I am indeed.
<robru> infinity, it's a conspiracy. Microsoft pays Shaw to give us shit service.
<infinity> stgraber: I was tunneling through San Jose for a long time, yeah.
<infinity> stgraber: (Through the machine I'm IRCing from)
<infinity> I may have to go back to doing that.
<infinity> But things had been okay for so long.
<infinity> *sigh*
 * infinity tries to decipher gv.shawcable.net and gives up.
<infinity> Greater Victoria?
<infinity> Grungy Vatican?
<stgraber> Vancouver (if so, you're not heading the right direction ;))?
<infinity> stgraber: Vancouver is vc.
<infinity> stgraber: But robru lives in Victoria, apparently, so my first guess might be close.
<robru> infinity, greater vancouver?
<robru> infinity, I used to live in Winnipeg and had problems with Shaw there, too
<infinity> robru: If you mean the island and not the city, maybe.  (As I said, Vancouver itself is ".vc." in shaw routing speak)
<infinity> Maybe granville.  The few, the proud, the drunk.
<robru> infinity, gisland vancouver ;-)
<infinity> Hrm.  Something very bad has happened to birch.
 * infinity stabs it with a fork.
<infinity> xnox: libffi fix uploaded.  Good thing I tested, I missed one spot the first time. :P
<infinity> doko_: Feel free to sync my libffi changes to Debian at any point.  Fixes the FTBFS on both powerpc and ppc64.
<infinity> final: gambas3,glib2.0,libffi,pypy,python2.7,ruby1.9.1,ruby2.0,witty/arm64
<infinity> robru: ^
<robru> infinity, sweet, thanks a ton
<cjwatson> Could somebody review grub2/precise, please?  It's pretty urgent - there's an OEM deadline of 6 Dec for it to be in updates
<xnox> cjwatson: uploaded ubiquity into precise-proposed, only changes are automatic dependency refresh, to pick up all the SRUs.
<xnox> (netcfg + partman-*)
<cjwatson> xnox: partman-* is broken right now, the discard thing
<cjwatson> So I'd been holding off until I got round to fixing that
<xnox> ah =(
<xnox> then reject that upload.
 * cjwatson goes to work on that in Debian
<xnox> cjwatson: may then instead cherrypick just partman-auto 101ubuntu2.1 for bug #1065281 ? or shall it just wait for discard fixups?
<ubot2> Launchpad bug 1065281 in OEM Priority Project quantal "Installer crashed when trying to partition 4k/4k sector hard disks" [High,In progress] https://launchpad.net/bugs/1065281
<xnox> wrong bug number.
<xnox> i meant cherry-pick for bug #1197766
<ubot2> Launchpad bug 1197766 in OEM Priority Project "Different partition layout after recovery with keep home partition" [Critical,Confirmed] https://launchpad.net/bugs/1197766
<cjwatson> Just wait, shouldn't take too long
<apw> cjwatson, idly looking at the grub change for recovery mode, i note that in the menu entry itself the 'recovery mode' string isn't internationalised (and never has been) i wonder if it makes sense to use GRUB_RECOVERY_TITLE="$(getext...)"
<cjwatson> It was internationalised before, and I did use gettext in the code that uses GRUB_RECOVERY_TITLE
<apw> oh now i see that is only for hurd, ignore me :)
<cjwatson> +             title="$(gettext_printf "%s, with Linux %s (%s)" "${os}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")" ;;
<cjwatson> etc.
<cjwatson> Yeah, that wasn't i18ned before in precise (it was in later releases) and I didn't bother to change that in the backport
<apw> yeah i am just being dumb and ignoring the filename
<apw> sensibly so, doh
<cjwatson> xnox: in progress now, I'll just wait for the d-i i18n cron jobs to pick it up
<apw> cjwatson, for what it is worth that grub2 diff looks to do what is claimed
<cjwatson> Thanks.  Hopefully somebody in ~ubuntu-sru will have a look shortly ...
<cjwatson> I dunno, fancy joining that team? :-)
<doko> giving one finger, and taking the whole hand ... ;p
<cjwatson> I prefer to call it "seeing an opportunity"
<apw> :)
<sil2100> seb128: thanks for the unity-voice review yesterday! We seemingly fixed all the issues if anything, so, once you have a quant of time... just a glance ;) Thank you and sorry for bothering!
<seb128> sil2100, ok, sure, let me have another look
<cjwatson> stgraber: queuebot seems ill
<cjwatson> I'm sure it should have noticed my partman-basicfilesystems/precise upload from 25 minutes ago by now
<apw> perhaps it is eating turkey
<doko> cjwatson, pitti, jibel: looking at why gcc-4.8 doesn't migrate ... this looks like a broken 3dpict autopkg test
<doko> same for python3.3, broken misaka autopkg test
<jibel> doko, I forced results of misaka and 3depict to pass, they failed because their testsuite is broken.
<xnox> jibel: i think i'll upload 3depict disabling it's tests. As it doesn't actually test as-installed binaries what's so ever. and if a package FTBFS we will notice it on updates / soname-transitions / archive rebuilds.
<jibel> xnox, sounds good, and the maintainer said he wouldn't have time to fix it in the coming weeks.
<xnox> jibel: adt compile tests make sense only for libfoo-dev packages, where actual as installed -dev package is test compiled.
<xnox> jibel: jenkins does notice when adt tests removed?
<jibel> xnox, no it must be removed manually
<xnox> jibel: i guess it makes sence, removed adt tests may mean a regression.
<jibel> xnox, indeed, there are more cases where adt tests have been removed by mistake than dropped on purpose.
<cjwatson> ... ah, another KDE SC upload, that's why my builds aren't happening :-)
<timchen119> hi, anyone in sru team can help me on this bug ? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1244065 I'd like this backport to precise.
<ubot2> Launchpad bug 1244065 in OEM Priority Project "Add more options to the power settings menu" [Critical,Confirmed]
<shadeslayer_> cjwatson: hehe
<shadeslayer_> it's the time of KDE SC releases \o/
 * ogra_ glares at trusty-changes ... hmmm, 169 mails in 1.5h 
<ogra_> ok, it's KDE day ...
<xnox> wow we have multi-cpu fields =) that's nice
<cjwatson> Yep, thanks to wgrant :-)
<cjwatson> The queue lengths are wildly wrong now because they don't really know about that, but he said he was going to fix that next week
<seb128> timchen119, I've sponsored that g-c-c SRU, with the template on launchpad/translations there, it should be doable as a SRU along the next langpack update
<timchen119> seb128, awesome, thanks!
<cjwatson> I would suggest not NEWing fakeroot
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730792
<ubot2> Debian bug 730792 in libfakeroot "libfakeroot: tries to overwrite libfakeroot-sysv.so, which is also in package fakeroot 1.20-1" [Serious,Fixed]
<cjwatson> The next auto-sync should bring in -3 and fix it
<cjwatson> in fact how about I just reject the binaries
<infinity> libfakeroot?  multiarchified fakeroot?
<cjwatson> Yeah
<infinity> Fancy.
<infinity> I wonder what that will end up breaking.
<robru> infinity, cjwatson: hey, can you have a look at glib2.0 in update_excuses? there's a failure listed there, but when i click through to the jenkins log, it actually looks like the failure exists with the version already in main, not the version in -proposed. we need to get the version in -proposed released because it fixes a big regression on the phone.
<sil2100> seb128: hello! I was browsing through and noticed that some of the glib2.0 autopkg tests seem to be failing - do you know anything about it ?
<robru> sil2100, lol ;-)
<sil2100> robru: ;D
<ogra_> robru, see #ubuntu-desktop, Laney is on it
<Laney> haha
<sil2100> Laney: thanks!
<sil2100> :)
<robru> Laney, also thanks ;-)
<Laney> Yeah, it doesn't really scale to ping release team guys btw
<Laney> can you retry tests?
<Laney> I think we should try it again in the hope that it gets the right version ...
<robru> Laney, I confirmed on my device that the version in -proposed fixes the regression that got into main
<Laney> I believe that part
<Laney> the autopkgtests are testing the whole thing though
<robru> Laney, i don't understand the failure though. looking here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=amd64,label=adt/ the only red one is 'trusty/main', all the 'trusty-proposed' ones are green
<Laney> it tested an old version of the tests against the new library for some reason
<infinity> robru: Hrm?  I see a red trusty-proposed/main
<infinity> (But yes, the version mismatch thing is a weird oops)
<robru> infinity, I see red trusty-proposed here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ but that's a different link
<infinity> Also the link that's linked from excuses, so probably the one that matters here. :)
<robru> infinity, yeah, but i clicked through to the red amd64 failure and that's where it says the failure is only in main
<Laney> robru: do you have permission to retry them one more time?
<robru> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=i386,label=adt/ even here the latest trusty-proposed is green
<robru> Laney, nope, I only do q-jenkins, that's d-jenkins
<cjwatson> BTW please stop saying "main" in opposition to "-proposed" - they're different categories and that's extra-confusing
<Laney> Ok, I pinged cj ohnston to retry it once more - if the same happens again then someone can force-badtest it since it has now passed on both architectures
<cjwatson> you probably mean "release"
<robru> cjwatson, yes, that one
<cjwatson> or "trusty" or "the release pocket" or something
<cjwatson> "main" is in opposition to "restricted", "universe", "multiverse"
<infinity> cjwatson: The confusion is likely because jenkins shows the component, so you see "trusty-proposed/main" and "trusty/main".
<cjwatson> this has been a public service announcement on behalf of the commission for confusing terminological schemes
<ogra_> lol
<Laney> tune your radios to http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/23/ARCH=amd64,label=adt/console
<Laney> Seems to have the right tests now
<Laney> looks like it passed that time
<Laney> if britney doesn't notice that for whatever reason then someone can force-badtest it
<Laney> got to go now, see you
<robru> Laney, thanks
#ubuntu-release 2014-11-25
<ara> infinity, :(
<infinity> ara: ?
<ara> infinity, moving 12.04.4 and 14.04.0 to old-releases
<infinity> ara: Oh, bleh.  Was on vacation for a while and forgot about getting that done.
<infinity> ara: Will forget less in the morning.
<ara> infinity, ok, thanks
<mdeslaur> can someone plese delete squid3 from the trusty and utopic upload queues?
<ScottK> mdeslaur: Done
<mdeslaur> ScottK: thanks
<utlemming> hey release team...could I get one of you to ack in the SRU upload for Bug 1367883? udev? Its been sitting now for two months
<ubot2> bug 1367883 in udev (Ubuntu Precise) "[SRU] Add Microsoft-owned MAC address to 75-persistent-net-generator.rules" [Undecided,In progress] https://launchpad.net/bugs/1367883
#ubuntu-release 2014-11-26
<cyphermox> hi, could someone please review upstart-watchdog in the NEW queue?
<xnox> cyphermox: the sheer name scares me! =)
<cyphermox> xnox: hehehe :)
<cyphermox> as it should
<ogra_> we need to have something consuming all that dogfood we invest ;)
<ogra_> hmm, could anyone let mit out of proposed so i can re-generate the meta package properly ?
<ogra_> *mir
<ogra_> since the new packages are not in the archive atm i cant get the ubuntu-touch-meta update script have them recognize yet
<xnox> ogra_: invoke editor ;-)
<cjwatson> Letting mir out of -proposed isn't a manual thing, as you well know!
<cjwatson> Regenerate the metapackage first, by hand if necessary.
<cjwatson> The update script isn't the be-all and end-all ...
<cjwatson> I'm not going to override proposed-migration just to avoid manual work regenerating the metapackage.
<ogra_> hmm, k
<ypwong> arges, I think you have reviewed bug 1329262, may I know what is blocking it to be released to -updates?
<ubot2> bug 1329262 in Ubuntu Kylin trusty "plymouth message --text doesn't work with ubuntukylin-theme" [Critical,Triaged] https://launchpad.net/bugs/1329262
<arges> ypwong: hi. let me look
<arges> ypwong: so 1.0.1 in trusty-proposed is what fixes that bug? It seems like the changelog message didn't include that bug (which is why it was missed)
<arges> ypwong: if you can confirm thats what fixed the bug I can release that into -updates.
<ypwong> arges, I can see the bug # in https://launchpad.net/ubuntu/+source/ubuntukylin-theme/1.0.1
<arges> ypwong: hmm. Ok : ) well maybe the pending SRU page didn't pick it up for some reason. I see that everything is verified, so I'll release it.
<ypwong> arges, thank you :)\
<arges> ypwong: ok done. thanks for bringing this to my attention
<ypwong> you're welcome
<mdeslaur> infinity: could you please denew xchat-gnome-indicator?
<mdeslaur> infinity: and promote it to main and demote xchat-indicator to universe?
<ogra_> *sniff*
<mdeslaur> ogra_: heh, xchat is in universe, no sense in having the indicator in main :P
<infinity> mdeslaur: Err, why should it be in main?
<infinity> If xchat is in universe...
<mdeslaur> infinity: xchat-gnome-indicator needs to be in main because xchat-gnome is in main
<mdeslaur> the xchat-indicator package used to build two binary packages: xchat-gnome-indicator and xchat-indicator
<infinity> Oh, derp.  Kay.  Do dependencies or seeds reflect this?
<mdeslaur> but I split it because one now needs to be gtk3
<ogra_> infinity, we support the castrated version now
<infinity> I'll look in a second.
<infinity> Updating my local seeds.
<mdeslaur> ogra_: what's castrated about it?
<ogra_> only half the features
<mdeslaur> such as? /me is truly curious
<infinity> xchat is an abomination anyway. :P
<infinity> People need to learn how to use terminals.
<mdeslaur> lol
<davmor2> mdeslaur: no people list on the right, some commands don't work, some plugins don't work the list goes on but I can't remember them all
<mdeslaur> oh, the people list on the right has been back for a few years
<mdeslaur> it's just off by default, you need to click the option
<mdeslaur> I wouldn't be able to use it without the people list :)
<davmor2> mdeslaur: xchat is the base for which xchat-gnome modifies why have the modification when you can have the real deal ;)
<mdeslaur> hehe
<infinity> davmor2: Because the real deal is hideous.
<infinity> (I assume xchat-gnome is slightly less ugly?)
<infinity> Otherwise, I really wouldn't see the point.
<davmor2> infinity: not really
<davmor2> infinity: it's mostly just simplified
<infinity> So, still ugly as sin and doesn't match the design/UI guildelines of any DE since the dawn of time? :/
<mdeslaur> There was a reason I switched at some point, but I honestly can't remember what it was
<infinity> One has to try really hard to make something look worse than CDE, I commend them for succeeding, at least.
 * mdeslaur wonders if having used CDE makes him privileged, or just old.
<infinity> mdeslaur: Both.
<infinity> mdeslaur: Well, or neither, I suppose, since it became freely available long after it was relevant, so some young kids saw it for funsies.
<mdeslaur> heh
<infinity> mdeslaur: But when I used it, it was cutting edge, and only shipped on hideously expensive workstations, as I assume is the case for you.
<cyphermox> on Sun workstations for me at least :/
<infinity> HP workstations for me.
<infinity> HP workstations that cost more than my parents' house.
<infinity> 120k for a tiny little grey box with the density of a star.
<mdeslaur> on Sun workstations, with the backspace key that prints ^? instead of doing anything useful
<infinity> I still don't know what alloy HP was using for those heatsinks, but I'm partially convinced it was of alien origin.
<cyphermox> infinity: if you could review upstart-watchdog next, since you're reviewing ugly stuff, I'd be very grateful ;)
<cyphermox> mdeslaur: yeah, I had forgotten about that
<cyphermox> I kept one sun keyboard from the office for nostalgia
 * infinity still has a VT220 for nostalgia.
<infinity> Every once in a while, I dust it off, go "wow, was the monitor really that tiny, it seemed so huge!" and then resolve to never plug it in again.
<infinity> upstart-watchdog - watchdog jobs to reboot when system or session jobs fail
<infinity> cyphermox: ^-- Automatic Windows administration?
<cyphermox> ahah, something like that :)
<infinity> cyphermox: The description alone doesn't make me want to review this. :P
<infinity> cyphermox: So, I have two questions.  (A) why do we need this and, (B) why do we care, if we're transitioning away from upstart?
<infinity> cyphermox: And (C) if this is a useful feature, why isn't it being proposed for upstart istself instead of a helper package?
<cyphermox> it's for the phone, if upstart jobs get into a respawn loop, most are critical and the phone just won't be useful without them running
<cyphermox> as for B)
<cyphermox> it's temporary indeed, until we can use systemd, etc.
<infinity> cyphermox: If a job is in a respawn loop, what makes us think rebooting will magically fix it?  Won't we then just end up in a reboot loop?
<cyphermox> and C) I don't know if you'd really necessarily want that on desktop, on the phone we have a bit more control and sight to make sure these respawning loops don't happen as often
<cyphermox> infinity: it's a concern, yes. but on the phone it was decided it would be just fine in that case, if you do end up in a reboot loop, to call customer support to get help
<infinity> cyphermox: In theory, yes, though it actually makes the job of support a lot harder, since diagnosing an endlessly rebooting device is Really Hard.
<cyphermox> on the phone, you can get into recovery at least
<infinity> cyphermox: "My phone app keeps crashing" is easier to debug on the fly than "my entire phone reboots every time it gets to the desktop".
<cyphermox> phone apps aren't usually upstart jobs
<infinity> Perhaps a moot point, though, since I don't see a whole lot of remote debugging being a thing on the phone.
<cyphermox> we're looking at indicators, ofono and such right now
<infinity> And phones in such a state (in a commercial context anyway) will just lead to returns or reflashes, not debugging.
<cyphermox> yes, reflashing
<cyphermox> or returns, indeed
<cyphermox> rsalveti: want to chime in ^ ?
<infinity> cyphermox: Not going to pressure anyone to provide this for a 1.0 shipping image or anything, but if we're going to go down the "we can't figure out how to recover cleanly, so just reboot" road, you probably also want to count the reboots and trap on boot "if count-in-last-hour >= 3" or something, and put up a "your phone might be buggered, please contact support or visit this web page for recovery options" dialog.
<cyphermox> infinity: the premise is that these job failures shouldn't happen in the first place, and at least trying to recover automatically by rebooting in case, say, ofono died, is more likely to lead to a phone that works again
<cyphermox> infinity: we discussed that approach
<cyphermox> decided people already were expected to call support if their phone was stuck rebooting all the time
<infinity> It's a nice theory.  People need to be hand-held a bit, I find.
<cyphermox> ie. that it was obvious enough when you keep seeing the boot animation
<cyphermox> I don't necessarily disagree
<infinity> I have a lot of non-technical friends who, when systems get in such a state, just decide that's the New World Order, until a computery friend comes along, looks at how they use their phone, laptop, etc, and goes "DUDE, WTF."
<cyphermox> I'm just following what we discussed in our sprint planning
<cyphermox> haha, yeah
<infinity> "Yes, mom, it's perfectly normal for the new Android to reboot 7 times after a phone call, you made the right decision to not return it to the store for service, CAN YOU HEAR MY SARCASM?"
 * rsalveti waves
<cyphermox> ahah
<rsalveti> infinity: yeah, we decided initially to just make it to reboot
<rsalveti> later one we need to talk with design to see if we want a different approach
<rsalveti> like getting into recovery or something
<infinity> Recovery is scary too.  But something that catches a reboot loop and offers direction would be pleasant.
<rsalveti> reboot, hope for the best, and let the user to call support if the phone is rebooting non-stop
<cyphermox> infinity: or, the fact that the phone beeps constantly, and changes the wallpaper by itself when it's charging after 5 minutes... only if you set your language to French (Canada) in Android 5.0? :D
<rsalveti> infinity: right, hard to find out the right one there, you don't want the phone to appear as working somehow for the user
<rsalveti> so that's why recovery is used by android
<cyphermox> rsalveti: nothing makes it impossible to do that though
<rsalveti> right
<infinity> cyphermox: That's a feature.
<cyphermox> rsalveti: I can just add some logic to the pacakge for a next release to get to recovery
<cyphermox> infinity: figured you would say that
<infinity> cyphermox: PS: Stop being French Canadian.
<rsalveti> cyphermox: right, better to discuss that though, as we decided to not do that initially
<cyphermox> at least now I don't need to try to say "1$s" in place of "Ok Google" :)
<cyphermox> rsalveti: yes
<rsalveti> as we need to show up something on recovery
<infinity> cyphermox: Hahahhaa.  Seriously?
<rsalveti> which then makes us talking with design, and that will take forever
<cyphermox> rsalveti: I'm just saying, we can come up with an updated way to handle this
<rsalveti> sure
<cyphermox> at least for now there is something
<cyphermox> infinity: yes, seriously. I did try it, doesn't work ;)
<infinity> cyphermox: Pronounced "one dollar ess", or perhaps "one string"?
 * mdeslaur is glad infinity is back from vacation
<cyphermox> hmm, would need more testing.
<infinity> Anyhow, the package looks like it should do what it claims it does.
<infinity> I'm pretty not okay with the approach, but I'll handwave for now and hope people come up with something less evil.
<cyphermox> handwave duly recorded
 * ogra_ notices an urge to join one of the phone teams in infinity's voice 
 * infinity panics.
<ogra_> lol
<cyphermox> rsalveti: let's move this conversation to #ubuntu-touch and think about it some more
 * mdeslaur watches upstart-watchdog restart infinity
<xnox> mdeslaur: infinity: i'm half and half. Half using x-chat, and the other half using hexchat (fork of original xchat to keep it "maintained")
<mdeslaur> xnox: why are you still using xchat? hexchat is pretty much the same, no?
<xnox> cyphermox: all phone apps are upstart jobs at the moment (user session upstart, not system one, but still ;-) )
<cyphermox> xnox: but I don't think apps in the standard sense really so much use respawn anyway
<cyphermox> indicators I agree with. some random browser app or game, not so much
<xnox> mdeslaur: there is no hexchat-indicator yet.
<xnox> mdeslaur: i'm meant to port it or find a port.
<xnox> cyphermox: indicators are running as upstart jobs.... in a user session upstart, not system one.
<mdeslaur> xnox: hrm, what if you just symlink the xchat-indicator plugin into the hexchat plugin directory?
<cyphermox> xnox: yes, I know :)
<xnox> cyphermox: so upstart-watchdog reboots from unpriviledged user? and security team let it through? it's not like mdeslaur is right here, reading this.
<xnox> mdeslaur: looking at the code they renamed s/^X/HEX/ all symbols so I daubt it, but maybe it works....
<mdeslaur> xnox: oh, darn, that sucks
 * xnox fetches to read it.
<mdeslaur> I didn't know they did that for the plugin api
<xnox> mdeslaur: i'll double check to confirm.
<mdeslaur> it's possible
<xnox> cyphermox: actually reading the whole black magic it seems ok. However do check that you don't have intentional things: emitting RESULT="failed" PROCESS="respawn" and rather be left alone instead of rebooting.
<xnox> cyphermox: e.g. for example upstart-plymouth-bridge i believe just does that - respawning until giving up, if there is no plymouth daemon running. And that's "normal".
<DalekSec> mdeslaur: https://code.launchpad.net/hexchat-indicator
<xnox> mdeslaur: may i work on merging xchat-gnome-indicator & xchat-indicator to be (a) single source code base (b) be able to build for both simultaniously (c) possibly add hexchat-indicator?
<mdeslaur> xnox: well, no, I just split it
<cyphermox> hahaha
<mdeslaur> xnox: so that gtk2 can go away to universe
<mdeslaur> (evetually)
<mdeslaur> xnox: you can add it to the xchat-indicator package though
<xnox> mdeslaur: haha. qt5 & qt4 are not ported from gtk2 to gtk3 yet.
 * xnox double checks
<mdeslaur> qt?
<mdeslaur> what, for theming?
<mdeslaur> why is qt using gtk?
<xnox> $ reverse-depends libgtk2.0-0 | grep qt
<xnox> * appmenu-qt5
<xnox> * gtk2-engines-qtcurve
<xnox> * libqt5gui5
<xnox> * libqt5gui5-gles [amd64 i386]
<xnox> funny how gles is compiled with gtk support for themeing.
<xnox> making gles not be compiled against gtk2 and not sure how appmenu is in there
<xnox> but if gles is compiled without gtk theming it could make gtk2 be dropped from phone images atleast.
<mdeslaur> well, anyway, having the same codebase for gtk2 and gtk3 in the indicator and building twice was painful
<mdeslaur> but I think adding hexchat support to the xchat-indicator package would make sense
<xnox> mdeslaur: yeah, true. i'm not sure what to base hexchat on then.
<mdeslaur> and is likely to be trivial
<xnox> it's gtk, so i'll keep it there.
<xnox> mdeslaur: reading the net-diff between xchat-gnome-indicator and xchat-indicator - i'm pretty sure the same patches are valid for gtk2...
<mdeslaur> nope, I tried
<mdeslaur> wait a sec, I'll tell you which ones
<mdeslaur> gdk_x11_window_get_xid for one
 * ScottK notes the channel and wonders if maybe we've wondered a tad off topic.
 * mdeslaur moves to #ubuntu-devel
<xnox>  mdeslaur moves... the conversation or ScottK ?! =)))))))) *giggle*
<ScottK> Pondering the imminent demise of keys < 2048 in Debian, should we do something similar?
<xnox> ScottK: we ain't even got a web of trust among all devs really... =)
<ScottK> No, we all trust in Launchpad.
<xnox> ScottK: but yeah, running a script to get all key ids and get some stats on key sizes would be useful to at least assess the situation and whether it's better or worse than debian etc.
 * xnox hopes we do not have recursive team memberships....
<stgraber> xnox: we've got 304 keys currently with upload rights
<stgraber> (that's recursive ~ubuntu-dev + the PPU people)
<stgraber> I just need to create a GPG keyring now and load them all in there, then check for < 2048rsa
<xnox> stgraber: you are faster with launchpad api than I am =) my script is still running....
<stgraber> xnox: downloading the keys from keyserver.ubuntu.com now
<stgraber> xnox: it's basically just a loop over lp.people['ubuntu-dev'].participants, for each grabbing all the keys from people.gpg_keys, then doing the same for all the people with PPU upload rights (I've got a report with the list of usernames), stuffing all that into a set
<stgraber> got a third of the keyring downloaded :)
<infinity> stgraber: You'll find people like me who still have their old key in LP.  I intend to remove it after keyring-maint finally swaps my new key into the Debian keyring.
<xnox> stgraber: ah, i've missed participants. i was doing recursive iteration over getMembersByStatus and calling oneself over if it's a team - http://paste.ubuntu.com/9256636/
<ScottK> So far, AFAIK, we don't even have a policy of retiring the older keys, so we've got to start somewhere.
<infinity> ScottK: Well, once we know the current situation, we can talk policy.
<ScottK> Sure.
<infinity> ScottK: Having the [ACCEPT] email warn about short signing keys would be a good first step.  Then we could eventually move to just REJECTing uploads signed by short keys, even if they're valid and attached to the user.
<ScottK> That'd be a start.
<infinity> Which also means people don't need to remove their old keys, we just stop trusting them.
<ScottK> Yeah
<stgraber> there you go: http://paste.ubuntu.com/9256745/
<xnox> stgraber: what about subkeys? launchpad accepts uploads singed by signing subkeys
<xnox> i think we are better than debian in terms of % of <2k keys.
<stgraber> xnox: give me a patch against http://paste.ubuntu.com/9256773/ and I'll happily run it :)
<infinity> stgraber: So, if we ignore 2048 as borderline, looks like we're about 50/50 good/bad.
<stgraber> infinity: yup
<infinity> stgraber: Except I bet that also counts both keys for people who have two?
<stgraber> it does
<stgraber> and it should
<stgraber> since both are valid for uploads to the archive
<infinity> stgraber: Well, no.  It shouldn't, from the POV of "how far do we have to go to fix it".
<infinity> stgraber: Cause if we stopped trusting 1024 today, people like Colin and I could still upload fine, even thought we have 1024 keys in your analysis.
<infinity> stgraber: So, I want to know how many *users* couldn't upload in that case, not how many *keys*.
<stgraber> yeah, I'd have to make an actual script for that rather than just type stuff in lp-shell :)
<infinity> Since we have no actual web of trust (for better or worse), we are in a position where we could move quickly if we did decide on a policy, at least.
<infinity> Cause an individual can generate and upload a key in a matter of minutes, it needs no other action.
<xnox> stgraber: can you send me the keyring itself please?
<stgraber> xnox: sure, one sec
<xnox> stgraber: tah.
<stgraber> xnox: https://dl.stgraber.org/ubuntu-keyring.asc
<xnox> stgraber: tah.
<infinity> Oh, keyring-maint *did* replace my key in Debian, I just foolishly thought I'd get an email about it when they did.
<infinity> I guess that email would have come in the form of a reject from DAK on my next upload. :P
<ScottK> No need to provide the information before you need it.
<ScottK> This way you won't forget.
<xnox> rough stats of public & subkey algos and sizes http://paste.ubuntu.com/9256897/
<infinity> wgrant: Are the ACCEPT message from soyuz a straight CC to -changes and the uploader, or are they individually crafted?
<stgraber> almost done writing a clever script
<infinity> wgrant: If we decide to start deprecating short keys, I'd like to tack a warning on the ACCEPT sent to the user, but no need to publically shame them on -changes
<xnox> this doesn't check if the subkey is encrypt only... e.g. like elg*
<stgraber> it's gonna be very slow though but very accurate (iterates through the archive privileges for all the archives)
<wgrant> infinity: I believe they're separate, but we should really just email people directly.
<wgrant> Not much point having a warning about it.
<xnox> stgraber: infinity: so we have like 11 rsa keys <2k, the rest of small keys are DSA
<infinity> wgrant: Well, an email to devel-announce obviously, with the policy.  And individual nag mails.  But I like the idea of warning "we accepted, but..."
<infinity> wgrant: Maybe there's little point.
<xnox> imho killing DSA keys should be easy / first target.
<ScottK> Kill them all.
<xnox> =)
<xnox> infinity: no need to hack soyuz.... mail announce ubuntu-devel-announce. Do another followup, rerun/check how effective that was. Mass individual email (launchpad email if present, key's emails otherwise)
<xnox> and then purge.
<infinity> ScottK: I think this should probably be a joint TB/AA decision.  Want to start a cross-posted discussion and we'll draft something to send to -announce when we all agree?
<xnox> infinity: it's not like we lock people out like debian, one can simply generate new key, login and add it.
<ScottK> Sure.
<infinity> xnox: No purging required, we can just reject if signed by a key type we don't like, even if the key is known to us.
<xnox> infinity: bigger question is - what about everyone? for PPA access/uploads?
<xnox> infinity: right, ok.
 * stgraber sshes to snakefruit so he can abuse LP much faster than from home
<xnox> infinity: yeah force removing keys from profiles sounds bad.
<infinity> And that's a fair point, TB/AA can't really make policy decisions for PPAs, but lp-dev can.
<infinity> wgrant: ^
<wgrant> "can't really" -> "can't at all" :)
<wgrant> I'd need to collect more data there.
<infinity> Pretty sure we can have different acceptance criteria in the short term, if we want to move quickly for the distro but feel it's too disruptive for PPAs.
<wgrant> And we also need to devise a solution for PPA signing keys themselves.
<wgrant> Remember that copies are a thing, though.
<infinity> The PPA signing key thing definitely needs to be solved, yes.
<xnox> wgrant: what's the algo/size for ppa singing keys? have they been rotated - ever?
<stgraber> xnox: 1024R for old PPAs
<xnox> horum.
<wgrant> There's no way to rotate them, which is the problem.
<wgrant> Ubuntu does it with a package that hacks apt's keyrings.
<xnox> yeah maybe we should practice what we are going to preach =)
<infinity> wgrant: Copies imply (however incorrectly) that you've validated the thing you're copying and you're now using your direct LP creds to do the copy to the target, the original signer is irrelevant.
<stgraber> and indeed copies are a good point, I don't suppose LP keeps a reference to the key which was used for the initial upload so we can reject the sync?
<wgrant> stgraber: It does.
<wgrant> But some things (eg. recipes) aren't signed, so it's not quite trivial.
<xnox> .... which brings us to ssh key sizes as well.
<xnox> and the ssh-blacklist =)))))
<stgraber> let's try to fix one thing at once :)
<xnox> stgraber: nah, we want to break everything at the same time.
<infinity> How do SSH keysizes matter at all?
<stgraber> turns out iterating through getAllPermissions and then grabbing all members of the team (if it's a team), not a very fast operation :)
<stgraber> infinity: commit to bzr branches which use recipes
<infinity> People doing sftp uploads are still GPG-signing their packages, so I don't actually care if their SSH login is insecure.
<infinity> stgraber: Oh, recipes.  Kay, that's back to the PPA thing, though.
<stgraber> yeah
<infinity> Let's stick with distro policy first.
<xnox> launchpad's ssl cert chain is all 2k RSA, so that's good.
<wgrant> And it should be SHA-256 all the way nowadays.
<stgraber> same for SSO, so yeah, SSL seems fine
<wgrant> I whined enough.
<stgraber> :)
<infinity> Well, this is good, though.  SSL being fine is a prereq for trusting the key replacement process. :P
<xnox> wgrant: all but the top level CA - it has sha256 fingerprint, but the selfsig is SHA1 it seems.
<infinity> I still wish we had a Debian-style WoT requirement for our signing keys, but whatever.
<infinity> That ship sailed long ago.
<xnox> wgrant: all other certs in the chain are sha256.
<stgraber> wow, that script is really incredibly slow... looks like I'll need to add some logic if I don't want it to take an hour and end up upsetting wgrant
<infinity> ScottK: Anyhow.  Thanks for bringing it up.  I thought about it earlier this year, but didn't want to bring it up while I was a hypocrite still uploading to both Debian and Ubuntu with a 1024D key from 2002.
<tumbleweed> :)
<wgrant> xnox: The root cert's self-sig doesn't matter, since it's only trusted by the fingerprint stored in the browser's CA DB.
<xnox> wgrant: i see.
<stgraber> yay, the script seems to work so far:
<stgraber> stgraber@snakefruit:~$ ./ubuntu-gpg-stats.py
<stgraber> Ubuntu has a total of 207 uploaders.
<stgraber> Ubuntu has a total of 314 GPG keys with upload privileges tied to them.
<cjwatson> xnox: The ssh blacklist is dead, along with the code to deal with it; if you want me to resurrect it and carry on maintaining it you'd better have an exceptionally compelling argument :-)
<cjwatson> Because maintaining that openssh patch sucked.
<xnox> cjwatson: i know. I like the openssl-blacklist approach where it's stand-alone set of datapoints.
<xnox> cjwatson: i've blogged - it appears a few of the openssh/openssl bad keys leaked into openpgp web of trust, thanks to monkeysphere conversion. I'm planning to find and revoke those.
<xnox> cjwatson: but i presume launchpad did database clean-up removed dupes?!
<xnox> cjwatson: well probably nothing to answer publically here.
<cjwatson> Pretty sure that was cleaned up centrally at the time, though, well, it was six years ago and memory is fuzzy.
<cjwatson> I remember us looking at a query to find duplicates though.
<wgrant> I remember something being done about that, yes.
<wgrant> Not that I was an insider at the time.
<cjwatson> Haha it looks like I ran the query indeed
<cjwatson> 18:44 <@elmo> (Do I want to know how you guys are backdooring LP? :-P)
<cjwatson> 18:44 <@cjwatson> the dump on mawson
<cjwatson> 18:44 <@cjwatson> it's not entirely up to date, but
<cjwatson> 18:45 <@cjwatson> I didn't *really* want to explain to somebody what I wanted to do on production
<xnox> LOLZ
<wgrant> Heh
<xnox> *really* yeah *really* =)
<cjwatson> Though I think my SQL at the time sucked even more than it does now and I just pulled the list of all fingerprints and postprocessed or something stupid like that.  Anyway, don't really want to go spelunking the logs of #argh at this remove :-)
<cjwatson> (Yes, that was the internal channel name)
<cjwatson> 2008-05-13.log:16:21 <@elmo> LP keys deleted
<cjwatson> Guess that covered that
<ScottK> Mail sent.
<stgraber> xnox, infinity: http://paste.ubuntu.com/9257987/ will get you one keyring per user and a global "ubuntu-archive" keyring. Shouldn't be too difficult to then look for people with multiple keys and see if one of those match the future criteria.
<xnox> stgraber: cool.
#ubuntu-release 2014-11-27
<apw> it looks like the utopic linux-signed got missed for final new processing when the last batch of SRUs were popped into -proposed, i wonder if anyone can have a look at it
<apw> (thanks)
#ubuntu-release 2014-11-28
<apw> Laney, hey ... the unity-settings-daemon upload, it seems to cause u-s-d to dump every 24s and to popup a box and crash unity that often too
<Laney> apw: yes, thanks, everyone is telling me :)
<apw> Laney, i am stuggling to see ohw something which drops a crash is getting past the auto-CI that that went through
 * cking wonders why we don't do static analysis on this code anymore, I thought we passed it through coverity scan to check for these ptr free issues
#ubuntu-release 2014-11-30
<kees> hmmm. I'm so used to doing security updates, I'm a bit rusty on doing -updates updates. :P
<kees> let's see what I get wrong! :)
<Laney> kees: you need to target <release>, not <release>-updates
<kees> Laney: with what part? I udated ubuntu-updates in the changelog and specified nothing in the dput.
<kees> er, $release-updates
<kees> but I think I need to use $release-proposed, don't I?
<Laney> release is an alias to release-proposed these days. Either would work, but people usually leave off the -proposed
<kees> ah, okay. will do.
<kees> Laney: can you discard those and I'll re-upload?
<Laney> don't think I have the power, I'm afraid
<kees> oops. heh. okay, I'll have them ready
<kees> infinity: you around? :)
<infinity> kees: Ish.
<infinity> kees: What am I discarding?
<infinity> Oh, the spamassassin uploads to the wrong pocket?
<kees> infinity: yup, thanks!
<DalekSec> LP 1360785 should be fixed by 0.3.11-0ubuntu7
<ubot2> Launchpad bug 1360785 in hexchat (Ubuntu) "HexChat does not integrate with the Ubuntu me-menu" [Medium,Confirmed] https://launchpad.net/bugs/1360785
#ubuntu-release 2015-11-23
<Mirv> cyphermox: sorry, I should have explicitly asked to be added to the newly created package set. does it need another meeting, a formal application etc or can it be handled on the mailing list?
<cyphermox> Mirv: we usually vote on these things, I think you should formally apply if you don't already have upload rights for those packages
<Mirv> cyphermox: ok, that won't help my Qt landing though anymore probably, since this addition took the 2.5 months it did and now the landing is probably near. but since the set is there it'd be useful to have someone there.
<xnox> infinity, the above two new syncs could they please go straight into main =)
<xnox> (i guess they will end up in new anyway)
<infinity> xnox: I wasn't planning on syncing those until the arch actually existed. :P
<infinity> xnox: I'm not even sure how LP behaves with a source that it can't create build records for.
<xnox> infinity, behaved fine in raring =)
<xnox> infinity, i'm just going through random things i can do now.
<infinity> xnox: Yeah, we altered build record things a bit since raring.  But it may still be happy with having buildless sources.  I don't think the bit that would break there got changed.
 * infinity goes taco hunting.
<cjwatson> xnox,infinity: It should work OK in these cases, I believe, but beware: if the source has any architecture-independent packages, such a copy will result in LP trying to do an architecture-independent-only build on amd64, which may not be what you intended and may not work.
<cjwatson> xnox,infinity: I'd probably recommend not exercising this just now. :P
<infinity> cjwatson: Yeah, those ones have no indep, just s390{,x}
<sbeattie> Hrm, I hate to ask for anything additional blocking things from promoting from proposed, but shouldn't a BuildDep version requirement that hasn't made it out of proposed block a package from leaving proposed?
<sbeattie> (The specific instance that I've just seen is graphviz migrating with a build-dep on ruby-dev > 1:2.2, which hasn't made it out of xenial-proposed)
<xnox> sbeattie, i belive britney only tests dependensies, not build dependensies.
#ubuntu-release 2015-11-24
<cjwatson> sbeattie: It might theoretically be nice, though it would be complicated to do and I wouldn't be surprised by unforeseen consequences.  The bulk of cases where it matters (though indeed not all) turn into runtime deps
<lordievader> .win20
#ubuntu-release 2015-11-25
<doko> any idea about the installation issues here in update_output? gdc-5-arm-linux-gnueabi, gdc-5-arm-linux-gnueabihf, gdc-5-multilib-arm-linux-gnueabihf, gdc-arm-linux-gnueabihf
<tjaalton> infinity: hrm, for lts-wily, newer mesa needs newer libvdpau (>= 1.1).. would it be ok to consider backporting that too (like libdrm now), seems to have the same soname at least
<tjaalton> the other option would be to revert adding HEVC support to the vdpau state tracker
#ubuntu-release 2015-11-26
<bluesabre>  please reject that xubuntu-meta wily upload
<slangasek> bluesabre: done
<bluesabre> slangasek: thank you
<xnox> can lxd autopkgtest be retriggered please?
#ubuntu-release 2015-11-27
<tjaalton> infinity: I've now got a preliminary set of lts-wily stack on ppa:canonical-x/x-staging which seems to at least install same way as lts-vivid, but I'll continue with proper tests next week
<cyphermox> could someone please rerun the network-manager autopkgtest triggered by network-manager/1.0.4-0ubuntu7 ; looks like for ppc64el the dhcp requests sometimes time out
<sil2100> Hello release team! I need to disable the system-image importer for a short while
<cyphermox> could someone please review grub2/grub2-signed in trusty, vivid and wily queues?
<tsimonq2> cyphermox: what about xenial? :D
<cyphermox> tsimonq2: it's already in xenial
<cyphermox> well
<cyphermox> I suppose it's still in NEW queue for xenial too, for i386/amd64
<tsimonq2> cyphermox: is it in -proposed yet? because I am running xenial-proposed i386
<cyphermox> yikes
<tsimonq2> cyphermox: it works fine
<cyphermox> it isn't, at least not for i386/amd64, since it's in NEW
<tsimonq2> ooh, can I go even MORE bleeding-edge then proposed? :D
<cyphermox> tsimonq2: sure, but xenial-proposed is probably not what you'd want to run day-to-day, things can and will break
<tsimonq2> heard it
<tsimonq2> never broken
<cyphermox> tsimonq2: fair enough. as long are you're aware of the risks :)
<tsimonq2> :D
<tsimonq2> cyphermox: but CAN I run something more bleeding-edge?
<cyphermox> not really. the other packages aren't available to apt-get, they're not officially in any repository, just waiting to be reviewed by an archive admin where necessary
<tsimonq2> oh :D
<cjwatson> tsimonq2: running devel-proposed is very silly, honestly - it's a waste of time to deliberately run into precisely those problems that automation would have detected
<tsimonq2> *shrug*
<tsimonq2> the new features are worth it
<cjwatson> they reach xenial as soon as they aren't broken
<cjwatson> there's no artificial delay
<cjwatson> by all means run devel, but you haven't been around long enough to see how it breaks, I think :)
<cjwatson> it -> devel-proposed
#ubuntu-release 2016-11-28
-queuebot:#ubuntu-release- New binary: ocrmypdf [amd64] (zesty-proposed/universe) [4.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-artwork [amd64] (zesty-proposed/universe) [0.6.1] (no packageset)
-queuebot:#ubuntu-release- New source: ubuntu-budgie-meta (zesty-proposed/primary) [0.0.1]
-queuebot:#ubuntu-release- New: accepted budgie-artwork [amd64] (zesty-proposed) [0.6.1]
-queuebot:#ubuntu-release- New: accepted django-hstore [amd64] (zesty-proposed) [1.5~alpha~git20161126+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-babel-runtime [amd64] (zesty-proposed) [6.18.0-1]
-queuebot:#ubuntu-release- New: accepted node-charm [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-core-js [amd64] (zesty-proposed) [2.4.1-1]
-queuebot:#ubuntu-release- New: accepted node-difflet [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-execa [amd64] (zesty-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted node-sparkles [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-wrap-ansi [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted discover-my-major [amd64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [i386] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-cliui [amd64] (zesty-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted node-duplexer2 [amd64] (zesty-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-time-stamp [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted php-net-idna2 [amd64] (zesty-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-geoip2 [amd64] (zesty-proposed) [2.4.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted smarty-gettext [amd64] (zesty-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [amd64] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [powerpc] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted django-impersonate [amd64] (zesty-proposed) [1.1~a0~hg20161126-1]
-queuebot:#ubuntu-release- New: accepted node-cpr [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted ocrmypdf [amd64] (zesty-proposed) [4.3.2-2]
-queuebot:#ubuntu-release- New: accepted ruby-unicode-display-width [amd64] (zesty-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [i386] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted node-buffer-shims [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted pybind11 [amd64] (zesty-proposed) [1.8.1-1]
-queuebot:#ubuntu-release- New: accepted node-os-locale [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted tmux-plugin-manager [amd64] (zesty-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted argonaut [amd64] (zesty-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [arm64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [powerpc] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [s390x] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [arm64] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [ppc64el] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted falcon [sync] (zesty-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [ppc64el] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [armhf] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libyami-utils [armhf] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ufo-filters [s390x] (zesty-proposed) [0.12.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted linux-firmware-raspi3 [arm64] (zesty-proposed) [1.20161123-1]
-queuebot:#ubuntu-release- Unapproved: glib2.0 (xenial-proposed/main) [2.48.1-1~ubuntu16.04.1 => 2.48.2-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: falcon [ppc64el] (zesty-proposed/universe) [1.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: falcon [amd64] (zesty-proposed/universe) [1.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: falcon [arm64] (zesty-proposed/universe) [1.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: falcon [s390x] (zesty-proposed/universe) [1.8.3-1] (no packageset)
<Laney> Anyone been prodding at the transition of doom? (glew & friends)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu2 => 20160930-0ubuntu3~16.10.0] (ubuntu-cloud)
<Odd_Bloke> Could someone reject ^?  I've just noticed that it's referencing private bugs.
<pitti> Odd_Bloke: done
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu3~16.10.0]
<Odd_Bloke> Danke.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu2 => 20160930-0ubuntu3~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: appstream (xenial-proposed/main) [0.10.1-1~ubuntu16.04.1 => 0.9.4-1ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (xenial-proposed/primary) [20160930-0ubuntu3~16.04.0]
<Odd_Bloke> Do I need to worry about the /primary there ^?
-queuebot:#ubuntu-release- Packageset: Added gce-compute-image-packages to ubuntu-cloud in trusty
-queuebot:#ubuntu-release- Packageset: Added gce-compute-image-packages to ubuntu-cloud in xenial
<LocutusOfBorg> hi, there is a lot of node-* sadness (including gitlab), that is blocked by node-spdx-expression-parse node-jison and the circular dependency
<LocutusOfBorg> maybe I can revert some change and hacky avoid the bootstrap
<LocutusOfBorg> no, node-jison needs bootstrap
<ginggs> LocutusOfBorg:
<ginggs> LocutusOfBorg: LP: #1644894
<ubot5`> Launchpad bug 1644894 in node-type-check (Ubuntu) "node-jison needs bootstrapping" [Undecided,New] https://launchpad.net/bugs/1644894
<ginggs> I spoke to doko previously and he suggested cjwatson or infinity are the ones who can cleanly fix this
<ginggs> LocutusOfBorg: you should use quassel, pitti replied about upstart in #-devel
<cjwatson> yeah, will see if I can find time today
<cjwatson> Odd_Bloke: that's normal for copies
-queuebot:#ubuntu-release- New: accepted falcon [amd64] (zesty-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted falcon [ppc64el] (zesty-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted falcon [arm64] (zesty-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted falcon [s390x] (zesty-proposed) [1.8.3-1]
<mapreri> ginggs: why is that related to quassel?
<ginggs> mapreri: if LocutusOfBorg used quassel i wouldn't have to repeat things for him :)
<mapreri> ginggs: I also offered several times space in my bouncer, but he always declined blubbering about people pinging him while not present and having to deal with backlogs :3
-queuebot:#ubuntu-release- Packageset: Removed alsamixergui from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed directfb from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed gnome-icon-theme-symbolic from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed libbinio from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed light-locker-settings from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed jack-audio-connection-kit from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed lubuntu-software-center from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed fltk1.1 from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed unico from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Added mpg123 to lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Added vte to lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed linux-wlan-ng from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Added mpv to lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Removed libdca from lubuntu in zesty
-queuebot:#ubuntu-release- Packageset: Added youtube-dl to lubuntu in zesty
-queuebot:#ubuntu-release- Unapproved: python-jujuclient (xenial-proposed/universe) [0.50.5-0ubuntu1 => 0.50.5-0ubuntu2~16.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-jujuclient (yakkety-proposed/universe) [0.50.5-0ubuntu1 => 0.50.5-0ubuntu2~16.10] (no packageset)
<Laney> could someone nuke xbmc-eventclients-j2me NBS in zesty-proposed please?
<lamont> can I get cloud-init/yakkety accepted into -proposed (from the queue)?
-queuebot:#ubuntu-release- New binary: notmuch [amd64] (zesty-proposed/main) [0.23.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (yakkety-proposed/main) [3.0~rc.4ubuntu64 => 3.0~rc.4ubuntu64.1.1] (core)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (xenial-proposed/main) [3.0~rc.4ubuntu62 => 3.0~rc.4ubuntu62.1.1] (core)
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (yakkety-proposed/multiverse) [1.20151118+b70b451-0ubuntu1 => 1.20161020-0ubuntu1~1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [s390x] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (xenial-proposed/multiverse) [1.20151118+b70b451-0ubuntu1 => 1.20161020-0ubuntu1~0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: jdupes [ppc64el] (zesty-proposed/none) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [s390x] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [s390x] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [arm64] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [arm64] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [ppc64el] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [armhf] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [ppc64el] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [armhf] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [arm64] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [powerpc] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [s390x] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [ppc64el] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [i386] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [amd64] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [ppc64el] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [armhf] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-extras [i386] (zesty-proposed/universe) [5.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [arm64] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [s390x] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [powerpc] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [armhf] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [i386] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [amd64] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [s390x] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [amd64] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jquery-typeahead.js [amd64] (zesty-proposed/universe) [2.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asl [powerpc] (zesty-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [i386] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [i386] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jdupes [powerpc] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: policycoreutils [amd64] (zesty-proposed/universe) [2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pirs [amd64] (zesty-proposed/universe) [2.0.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [amd64] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pirs [i386] (zesty-proposed/universe) [2.0.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [powerpc] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [arm64] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: casacore-data-observatories [amd64] (zesty-proposed/universe) [0+git2016.11.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eccodes [armhf] (zesty-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [s390x] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [ppc64el] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: u-boot (yakkety-proposed/main) [2016.03+dfsg1-6ubuntu1 => 2016.03+dfsg1-6ubuntu2~1.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: hdf5 [powerpc] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: u-boot (xenial-proposed/main) [2016.01+dfsg1-2ubuntu1 => 2016.01+dfsg1-2ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: hdf5 [amd64] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdmf [s390x] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdmf [ppc64el] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [i386] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [armhf] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [arm64] (zesty-proposed/universe) [1.10.0-patch1+docs-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdmf [powerpc] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [s390x] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [ppc64el] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [i386] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [amd64] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: xdmf [amd64] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [powerpc] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ppl [s390x] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [arm64] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: xdmf [i386] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppl [ppc64el] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppl [powerpc] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [armhf] (zesty-proposed/main) [8:6.9.6.2+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: xdmf [armhf] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdmf [arm64] (zesty-proposed/universe) [3.0+git20160803-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [arm64] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted xdmf [arm64] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted xdmf [i386] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted xdmf [s390x] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted xdmf [armhf] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted xdmf [ppc64el] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted casacore-data-observatories [amd64] (zesty-proposed) [0+git2016.11.02-1]
-queuebot:#ubuntu-release- New: accepted imagemagick [arm64] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [i386] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [ppc64el] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [amd64] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [powerpc] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [armhf] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [s390x] (zesty-proposed) [8:6.9.6.2+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted hdf5 [amd64] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [armhf] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [powerpc] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [s390x] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [arm64] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [ppc64el] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [i386] (zesty-proposed) [1.10.0-patch1+docs-1]
-queuebot:#ubuntu-release- New: accepted eccodes [amd64] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted eccodes [armhf] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted eccodes [powerpc] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted eccodes [s390x] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted xdmf [powerpc] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted eccodes [arm64] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted eccodes [ppc64el] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted eccodes [i386] (zesty-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted xdmf [amd64] (zesty-proposed) [3.0+git20160803-1]
-queuebot:#ubuntu-release- New: accepted asl [amd64] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [armhf] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [powerpc] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [s390x] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [arm64] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [ppc64el] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted asl [i386] (zesty-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted jdupes [amd64] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [armhf] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [powerpc] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [s390x] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [arm64] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [ppc64el] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted jdupes [i386] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted policycoreutils [amd64] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted policycoreutils [i386] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted policycoreutils [ppc64el] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted policycoreutils [armhf] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted policycoreutils [s390x] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted policycoreutils [powerpc] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted pirs [amd64] (zesty-proposed) [2.0.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted policycoreutils [arm64] (zesty-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted pirs [i386] (zesty-proposed) [2.0.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted jquery-typeahead.js [amd64] (zesty-proposed) [2.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [amd64] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [armhf] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [powerpc] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [s390x] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted notmuch [amd64] (zesty-proposed) [0.23.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [i386] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [source] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [arm64] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New: accepted opensmtpd-extras [ppc64el] (zesty-proposed) [5.7.1-3]
-queuebot:#ubuntu-release- New binary: ppl [amd64] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [ppc64el] (zesty-proposed/none) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [amd64] (zesty-proposed/none) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [powerpc] (zesty-proposed/none) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [i386] (zesty-proposed/none) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppl [armhf] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [i386] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: ppl [i386] (zesty-proposed/universe) [1:1.2-1] (no packageset)
<slashd_> Hi SRU, would it be acceptable to split up a binary package in two to include changes (already applied in Xenial) to trusty ? package in question "isc-dhcp-client" where dhclient has been included as optionnal for Dynamic DNS in Xenial with "isc-dhcp-client-ddns" optionaly. LP: #1176046
<ubot5`> Launchpad bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress] https://launchpad.net/bugs/1176046
-queuebot:#ubuntu-release- New binary: linux [powerpc] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [arm64] (zesty-proposed/universe) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-budgie-meta [armhf] (zesty-proposed/universe) [0.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [s390x] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux [armhf] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: imagemagick [powerpc] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [i386] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [ppc64el] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [amd64] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ppl [arm64] (zesty-proposed/universe) [1:1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imagemagick [armhf] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: imagemagick [arm64] (zesty-proposed/main) [8:6.9.6.6+dfsg-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux [amd64] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: paxrat [ppc64el] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paxrat [s390x] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paxrat [arm64] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paxrat [armhf] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paxrat [powerpc] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opencc [amd64] (zesty-proposed/universe) [1.0.4-2] (input-methods, kubuntu, ubuntu-desktop)
#ubuntu-release 2016-11-29
-queuebot:#ubuntu-release- New binary: paxrat [amd64] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paxrat [i386] (zesty-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libica [s390x] (zesty-proposed/universe) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: squirrelmail (yakkety-proposed/universe) [2:1.4.23~svn20120406-2ubuntu1 => 2:1.4.23~svn20120406-2ubuntu1.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: squirrelmail (xenial-proposed/universe) [2:1.4.23~svn20120406-2ubuntu1 => 2:1.4.23~svn20120406-2ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.8-3ubuntu3 => 7.0.13-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.8-0ubuntu0.16.04.3 => 7.0.13-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.2 => 0.27ubuntu1.3] (edubuntu, ubuntu-server)
<smoser> can someone NACK that ^ please ?
<smoser> i missed a changelog entry
<smoser> stgraber, ? slangasek ?
<rbasak> smoser: done
<smoser> thanks!
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.30ubuntu1 => 0.30ubuntu1.1] (edubuntu, ubuntu-server)
<smoser> :-(. and nack ^ one too ?
<smoser> stupid changelog messages again
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (yakkety-proposed) [0.30ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.2 => 0.27ubuntu1.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.30ubuntu1 => 0.30ubuntu1.1] (edubuntu, ubuntu-server)
<smoser> bah.
<smoser> this really stinks. but changelog for xenial *still* incomplete
<smoser> please nack the one currently in the queue
<slangasek> smoser: done
<smoser> thank you.
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.2 => 0.27ubuntu1.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: hexchat (yakkety-proposed/universe) [2.12.0-2ubuntu2 => 2.12.0-2ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opencc (yakkety-proposed/universe) [1.0.4-1 => 1.0.4-1ubuntu0.16.10.1] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-103.150] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-51.72] (core, kernel)
<JerryKao> rbasak, ping
<JerryKao> bdmurray, ping
<JerryKao> tjaalton, ping
<tjaalton> JerryKao: pong
<JerryKao> tjaalton, hi, https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1642662 is verified. could you help to publish?
<ubot5`> Ubuntu bug 1642662 in HWE Next "SRU request: handle EGL alternatives and use different drivers for the LTS stacks" [Critical,In progress]
<tjaalton> JerryKao: sure, after lunch
<JerryKao> tjaalton, thanks!!
<Laney> xnox: can you confim that the dist-upgrader tarballs are signed with the old archive key?
-queuebot:#ubuntu-release- New: accepted imagemagick [amd64] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [armhf] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [powerpc] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [s390x] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [arm64] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [ppc64el] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted imagemagick [i386] (zesty-proposed) [8:6.9.6.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [amd64] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [armhf] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [powerpc] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [arm64] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [ppc64el] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-budgie-meta [i386] (zesty-proposed) [0.0.1]
-queuebot:#ubuntu-release- New: accepted linux [amd64] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [powerpc] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted linux [i386] (zesty-proposed) [4.9.0-3.4]
-queuebot:#ubuntu-release- New: accepted opencc [amd64] (zesty-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- New: accepted ppl [arm64] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [i386] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [ppc64el] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [amd64] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [powerpc] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [armhf] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted ppl [s390x] (zesty-proposed) [1:1.2-1]
-queuebot:#ubuntu-release- New: accepted paxrat [amd64] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [armhf] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [powerpc] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [s390x] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [arm64] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [ppc64el] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted paxrat [i386] (zesty-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libica [s390x] (zesty-proposed) [3.0.1-1]
<Odd_Bloke> Could someone reject gce-compute-image-packages from xenial, please?
<tjaalton> Odd_Bloke: I don't see it on the queue
<Odd_Bloke> tjaalton: It's new, if that makes a difference?
<tjaalton> ah
<tjaalton> what's the reason to reject?
<Odd_Bloke> It's missing a xenial-specific change.
<Odd_Bloke> (tjaalton: ^)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
<tjaalton> Odd_Bloke: huh?
<tjaalton> you mean it's incomplete?
<Odd_Bloke> tjaalton: Yeah, it will Replace an existing package which we don't want except on upgrade to later-than-xenial.
<tjaalton> ok, done
-queuebot:#ubuntu-release- New: rejected gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu3~16.04.0]
<Odd_Bloke> tjaalton: Thanks. :)
-queuebot:#ubuntu-release- New binary: python-distro [amd64] (zesty-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [powerpc] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-distro [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: qgis [armhf] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zeromq3 (yakkety-proposed/main) [4.1.5+git20160811+2fc86bc-0ubuntu2 => 4.2.0-2ubuntu0.16.10] (kubuntu)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (zesty-proposed/universe) [2.14.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [powerpc] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (zesty-proposed) [2.14.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (zesty-proposed) [2.14.9+dfsg-1]
<xnox> Laney, they are, there is in progress branch to get them to be signed with the new key.
<xnox> let me find that.
<Laney> xnox: found it
<Laney> just noticed because it breaks ubuntu-release-upgrader tests
<Laney> and of course because apt-key can't verify it now
<xnox> Laney, once that branch lands everything will be fine again.
<xnox> and once we resign things.
<Laney> i'm sure they will
<Laney> broken right now though
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.9.0-3.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-51.72]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-103.150]
<rbasak> tjaalton: are you done with SRUs for today? I was going to look at python-django in Trusty for ScottK.
<tjaalton> rbasak: yeah, I just handled these
<tjaalton> *those, three packages
<lamont> any chance someone could let cloud-init and cloud-initramfs into {x,y}-proposed?
<lamont> cloud-init/xenial is already in, fwiw
<lamont> that will let me test them.
<Trevinho> Hey, can anyone unblock https://bileto.ubuntu.com/#/ticket/2192 from SRU waiting queue?
<slangasek> Trevinho: only bug #1635625 appears to have the SRU info in its bug description; can you please fix up the others?
<ubot5`> bug 1635625 in unity (Ubuntu) "Some indicator icons are missing after unlocking the screen" [High,Fix released] https://launchpad.net/bugs/1635625
<Trevinho> slangasek: ah, sorry... I thought they all were fixed... andyrock, can you take care of that please ^
<slangasek> Trevinho: maybe it's just the standard headers that are missing, since several of these look like they might have test case / regression potential analysis under other names; but using the standard headers would help with clarity
<andyrock> oki
<Trevinho> slangasek: yeah, that's the thing in fact... I remember we discussed that very topic.
<andyrock> slangasek Trevinho should be ok now
<Trevinho> thanks andyrock
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.17.1ubuntu1]
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (xenial-proposed/primary) [20160930-0ubuntu3~16.04.0]
<Odd_Bloke> RAOF: If you have time today, getting ^ accepted would be good. :)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-51.72~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-103.150~precise1] (kernel)
 * rbasak reviews python-django in the trusty queue
<rbasak> RAOF: ^
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.9.0-3.4]
<xnox> google-perftools appears to be stuck waiting on juju-mongodb3.2 amd64 test results, which does not appear anywhere yet is "test in progress"
<xnox> i've tried to trigger that test with: https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=juju-mongodb3.2&trigger=google-perftools%2F2.5-0ubuntu3
<xnox> but that fails with "A server error occurred.  Please contact the administrator."
<xnox> what can I do to unstuck it?
-queuebot:#ubuntu-release- Unapproved: keepalived (yakkety-proposed/main) [1:1.2.23-1 => 1:1.2.23-1ubuntu0.1] (ubuntu-server)
<nacc> can someone reject the above? i need to adjust the backported patch
<nacc> (keepalived in y-p)
<nacc> or am I able to do that myself as a core-dev?
-queuebot:#ubuntu-release- New: accepted transcode [source] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
<infinity> nacc: Yes I can, and no you can't.
<nacc> infinity: thanks :)
<infinity> xnox: The retriggering CGI WFM.
-queuebot:#ubuntu-release- Unapproved: rejected keepalived [source] (yakkety-proposed) [1:1.2.23-1ubuntu0.1]
-queuebot:#ubuntu-release- New binary: transcode [ppc64el] (yakkety-proposed/none) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
<nacc> infinity: thank you!
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.1 => 2.20.1-0ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: transcode [s390x] (yakkety-proposed/none) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- New binary: transcode [i386] (yakkety-proposed/none) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: keepalived (yakkety-proposed/main) [1:1.2.23-1 => 1:1.2.23-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: transcode [amd64] (yakkety-proposed/multiverse) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- New binary: transcode [arm64] (yakkety-proposed/multiverse) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- New binary: transcode [armhf] (yakkety-proposed/multiverse) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: keepalived (xenial-proposed/main) [1:1.2.19-1 => 1:1.2.19-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (xenial-proposed) [2.20.1-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.1 => 2.20.1-0ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: init-system-helpers (xenial-proposed/main) [1.29ubuntu3 => 1.29ubuntu4] (core)
<bdmurray> given that https://code.launchpad.net/~xnox/ubuntu-archive-publishing/migrate-dist-upgrade-to-4k/+merge/311181 was merged how can we get the dist-upgrade tarballs resigned?
<bdmurray> slangasek, infinity: ^^
<slangasek> bdmurray: I'm assuming you don't want to trigger a new one, right?
<slangasek> if not then I imagine I'll need to dig around on pepo to re-sign manually
<bdmurray> slangasek: Does trigger mean upload another version? If that's what needs to happen that's fine.
<slangasek> bdmurray: you could do it that way, yes
<slangasek> for each release
<slangasek> and I guess that would also let us validate it in -proposed before pushing it to -updates
<slangasek> which is good
<bdmurray> okay
<slangasek> andyrock, Trevinho: I am allowing this SRU through, but for the record, the "regression potential" sections are not properly filled out on several of these bugs.  "regression potential" is for describing the potential risk of regression from this SRU, not restating the impact of the bug.
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (yakkety-proposed) [7.5.0+16.10.20161112-0ubuntu1]
<nacc> i take it the perl5 and glibc updates are hammering the zesty queue?
-queuebot:#ubuntu-release- New binary: transcode [powerpc] (yakkety-proposed/multiverse) [3:1.1.7-9ubuntu0.1] (mythbuntu, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.4 => 4.3.3-5ubuntu12.5] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu15.1 => 4.3.3-5ubuntu15.2] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.5 => 0.122ubuntu8.6] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu6.1 => 0.125ubuntu6.2] (core)
<lamont> who is my favorite archive-admin on the SRU hook for the day?
-queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.4 => 0.96.20.5] (desktop-core, ubuntu-server)
<lamont> rbasak: is it you?
 * lamont needs to get the following into xenial-proposed and yakkety-proposed, so that they can be fix-verified: cloud-init cloud-initramfs-tools initramfs-tools isc-dhcp
<lamont> it would seem that cloud-init/xenial is already landed
<lamont> yep
<infinity> bdmurray, slangasek: Well, "landed" isn't landed until someone pulls on pepo (which I did).
<infinity> (just now)
<infinity> slangasek: As for verification that it's doing the right thing, given that none of this will trigger without new uploads (or fiddling), I'd suggest we might actually want to rm *.gpg on the upgrade tarballs to force resigning and verify it's working correctly *now* rather than leaving a ticking timebomb to debug when someone uploads trusty or precise in three months and it breaks.
<infinity> Oh, you suggested brian upload for *every* release, that would do it too.
<rbasak> lamont: I'm tomorrow.
<lamont> yeah.  RAOF is today, I see from the wiki that I got faceslapped with.
<bdmurray> infinity: every release includes P and T?
<lamont> rbasak: however, since I expect you'll ask/grumble at me about it, isc-dhcp... I'm thinking it'll be easier to verify the currently pending SRU by overwriting it, since I don't really have any way to verify it without the other pieces..
<infinity> bdmurray: Every release would include everything we still publish and support.  So, either you can upload all of 'em, or I can force them all the be re-signed in-place on ftpmaster, but my point is that we want them all re-signed one way or the other so we can verify we didn't break them in the process.
<infinity> bdmurray: Because in N months, when an innocent SRU is broken by this, we'll be far enough detached from it that someone will go wild-goose-hunting to figure out WTF broke.
<slangasek> infinity, bdmurray: so what about copying into -proposed directories, resigning there for testing?
<infinity> slangasek: pocket copy *-updates to *-proposed, the rm *-proposed/dist-upgrade/*gpg, and check results?
<infinity> slangasek: Seems reasonable.
-queuebot:#ubuntu-release- New binary: lxde-common [amd64] (zesty-proposed/universe) [0.99.2-2] (no packageset)
<slangasek> infinity: yah (does the pocket copy cover the dist-upgrade bits?)
<infinity> slangasek: If it didn't, we'd never have them in updates.
<slangasek> ok!
<infinity> Oh, that said, dist-upgrader-all, being custom whee, never gets *removed* from proposed.
<infinity> So, we could just re-sign proposed right now.
<infinity> And have someone verify they all look sane.
<infinity> Then re-sign updates.
<bdmurray> I'll do the verification but already uploaded zesty fwiw.
<infinity> See: http://archive.ubuntu.com/ubuntu/dists/yakkety-proposed/main/dist-upgrader-all/
<infinity> Versus: http://archive.ubuntu.com/ubuntu/dists/yakkety-updates/main/dist-upgrader-all/
<infinity> bdmurray: Sure, no big deal on zesty, but no point in a round of no change SRUs to verify just to check sigs.
<infinity> bdmurray, slangasek: http://paste.ubuntu.com/23555294/
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-103.150~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-51.72~14.04.1]
<infinity> bdmurray, slangasek: That's what I propose deleting, letting LP regenerate, someone verifying they all seem to be what we think they should be and that dist-upgrade from $previous-release doesn't hate them, then I can do the same for s/proposed/updates/ ... Seem sane?
<infinity> (Or just cp them from proposed to updates, cause having differing sigs might be weird, but *shrug*)
<bdmurray> infinity: how long will the regeneration take?
<infinity> Oh, I might do zesty too.  Since I think your upload beat my bzr pull.
<infinity> bdmurray: A publisher cycle.
<infinity> bdmurray: So, less than half an hour, more than 2 minutes.
<infinity> Actually, pretty quick if I'm quick.
<bdmurray> infinity: okay
<infinity> bdmurray: Alright, all deleted from dists.in-progress (a publisher run was under way, I'm being sneaky) should re-gen in a few minutes, push to mirrors a bit later, blah blah.
<barry> is it just me or have we not seen any debian imports for zesty in a while?
<infinity> barry: Logs at http://people.canonical.com/~ubuntu-archive/auto-sync/ disagree.
<barry> infinity: yeah okay
<infinity> Oh, well, that's confusing and annoying.
<infinity> These signature changes might never make it to mirrors anyway. :P
<infinity> We touch --reference foo.gpg to foo's timestamp, so any mirror that uses timestamp and filesize to determine the rsync list (ie: pretty much all of them) won't ever see updated files.
<infinity> bdmurray, slangasek: ^-- Based on that, it may be that the only way to reliably verify (and more importantly, push) this change is, indeed, no-change uploads.
<infinity> Because even if someone out there attempts to mirror by hash, I imagine IS blocks that server-side to prevent one bad actor from crippling our infra.
<infinity> Other option is, I guess, for me to touch those all to a different time, wait a day for tertiary mirrors to pick up the change, then touch 'em back.
<infinity> But ew.
<bdmurray> infinity: would it be worth testing your change then doing a no-change upload?
<infinity> bdmurray: Good luck testing it.
<infinity> bdmurray: Mirrors won't see the change, they'll have the old sigs.
<infinity> bdmurray: And everything that isn't ftpmaster is a mirror.  Soo....
<bdmurray> infinity: okay, I'll start with yakkety I guess
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.6]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.5]
<lamont> RAOF: please reject isc-dhcp 4.3.3-5ubuntu15.2 from yakkety-proposed queue, and I'll reupload
<RAOF> lamont: Done.
<lamont> gpg: checking the trustdb
<lamont> sigh
-queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (yakkety-proposed) [4.3.3-5ubuntu15.2]
<RAOF> Oh, wow. cloud-initramfs-tools fixes *all the bugs*
<lamont> it has a "all the shiny" exception on SRUs
-queuebot:#ubuntu-release- New: accepted transcode [amd64] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [armhf] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [powerpc] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [s390x] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [arm64] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [ppc64el] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted transcode [i386] (yakkety-proposed) [3:1.1.7-9ubuntu0.1]
<RAOF> Eh, I'm happy to accept SRUs that fix bugs :)
<lamont> uploaded
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu15.1 => 4.3.3-5ubuntu15.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.3]
<RAOF> Whelp, sorry. Same applies to yakkety initramfs-tools?
<RAOF> lamont: ^
<lamont> so it would seem.  grabbing the bits now
<lamont> fetched.  reject pls?
<RAOF> Done.
<RAOF> queuebot will notice soon :)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (yakkety-proposed) [0.125ubuntu6.2]
<lamont> and upload complete
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu6.1 => 0.125ubuntu6.2] (core)
<lamont> RAOF: sometime next week, I'll get the SRU template into the freeipmi packge in x-p.  because of sigh.
<lamont> actually, let me see if next week is today
<RAOF> Heh.
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.8 => 1:16.10.9] (core)
<bdmurray> slangasek, infinity: u-r-u in the yakkety queue
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu6.2]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (yakkety-proposed) [4.3.3-5ubuntu15.2]
<lamont> RAOF: is your plan to let the first two publish, and then add the other two?
<lamont> RAOF: and then I have a different question for you on freeipmi/xenial-proposed
<RAOF> lamont: I was not planning on doing that, unless you think that there are sufficient people running from -proposed who will be broken if they update in the window where netboot breaks.
<lamont> I'm good with not waiting
<lamont> if they all land reasonably close, then all is well.
<lamont> esp if they all land together
<lamont> https://launchpad.net/ubuntu/+source/freeipmi/1.4.11-1.1ubuntu2 <-- RAOF you'll notice from that, and the craptastic changelong in the xenial-proposed upload that the upload does not, in fact, completely address bug 1618543.  it is however, sufficient to address some operational concerns (with the fix, we can control power over ipv6 ipmi, but cannot discover the ipv6 address of the bmc, hence
<ubot5`> bug 1618543 in MAAS "freeipmi lacks IPv6 support" [Critical,Triaged] https://launchpad.net/bugs/1618543
<lamont> "not done yet")
<lamont> do you want that split into a separate bug?
<lamont> actually, 5 blades.  I'm going to just do that.  Please reject freeipmi/xenial <-- RAOF
<RAOF> lamont: If you plan to upload multiple times, it'd be nice to have a bug per upload. If you plan to wait before *all* IPv6 support lands, then.
<RAOF> Oh, I missed the xenial-unapproved upload. Ooops. :)
<RAOF> Whee! Cloud init also does all the things.
-queuebot:#ubuntu-release- Unapproved: rejected freeipmi [source] (xenial-proposed) [1.4.11-1.1ubuntu2~0.16.04]
<doko> bdmurray: fyi, accepted the transcode binary builds: ^^^
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-49-g9e904bb-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: freeipmi (xenial-proposed/main) [1.4.11-1ubuntu1 => 1.4.11-1.1ubuntu2~0.16.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (yakkety-proposed) [0.30ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: freeipmi (yakkety-proposed/main) [1.4.11-1ubuntu1 => 1.4.11-1.1ubuntu2~0.16.10] (ubuntu-desktop, ubuntu-server)
<lamont> RAOF: please accept freeipmi into x and y
<lamont> and then I think I'll be able to stop bugging you for at least the rest of the week!
<lamont> the -1 vs -1.1 was basically a non-change for binNMU happiness and seemed safe to this uploader.
<RAOF> And then I'll decamp to a cafÃ©!
<RAOF> Why isn't that spelt *imp*i? :(
<lamont> it stands for "it pleases me immensely"
<lamont> or somethign like that
<RAOF> But they missed the opportunity to have âimpâ as a substring.
#ubuntu-release 2016-11-30
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (yakkety-proposed) [1.4.11-1.1ubuntu2~0.16.10]
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (xenial-proposed) [1.4.11-1.1ubuntu2~0.16.04]
<RAOF> lamont: Today's fish is trout ala creme. Enjoy your meal.
<lamont> yum
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.9]
-queuebot:#ubuntu-release- Unapproved: pbuilder (yakkety-proposed/main) [0.226.1 => 0.226.1ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (trusty-proposed) [1.6.11-0ubuntu1]
<rbasak> pitti: you accepted ido to xenial bug 1506427 and it looks ready to release. But that would put xenial's version higher than the latest in yakkety.
<ubot5`> bug 1506427 in ido (Ubuntu Xenial) "Using calendar with keys might cause Indicator-datetime to crash unity-panel-service" [Undecided,Fix committed] https://launchpad.net/bugs/1506427
<pitti> rbasak: right, that's a blocker for releasing
<rbasak> pitti: do you normally check the version before accept or before release?
<rbasak> IOW, is it part of the normal process for it to get this far?
<rbasak> And should it be just not be released, or marked v-f?
<pitti> rbasak: usually, but seems I forgot/misread it in this cae
<pitti> no, it's not v-failed
<rbasak> OK
<pitti> as x an y have the same version, we could just forward-copy it to y as well
<pitti> or ask Trevinho to prepare an y SRU too
<pitti> i. e. forward-copy to y-proposed and ask for testing
<rbasak> If forward-copying, we'd need to verify on Yakkety too presumably?
<pitti> right
-queuebot:#ubuntu-release- Unapproved: ido (yakkety-proposed/main) [13.10.0+15.10.20151002-0ubuntu1 => 13.10.0+16.04.20161028-0ubuntu1] (ubuntu-desktop) (sync)
<rbasak> Ah, I was just preparing that command
<rbasak> For future reference, would copy-package -n -b --from-suite=xen
<rbasak> ial-proposed --to-suite=yakkety-proposed ido
<pitti> rbasak: copied and bug updated
<rbasak>  have been right?
<rbasak> pitti: thanks!
<pitti> rbasak: that's what I did (sans -b)
<pitti> err, sans -n of course
-queuebot:#ubuntu-release- Unapproved: accepted ido [sync] (yakkety-proposed) [13.10.0+16.04.20161028-0ubuntu1]
<rbasak> OK, thank you!
<pitti> thanks for pointing out!
-queuebot:#ubuntu-release- Unapproved: dbus (xenial-proposed/main) [1.10.6-1ubuntu3.1 => 1.10.6-1ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: unity-gtk-module (xenial-proposed/main) [0.0.0+15.04.20150118-0ubuntu2 => 0.0.0+15.04.20150118-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted init-system-helpers [source] (xenial-proposed) [1.29ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (xenial-proposed) [2016.01+dfsg1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (xenial-proposed) [3.0~rc.4ubuntu62.1.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (xenial-proposed) [1.20161020-0ubuntu1~0.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-virtualenv [source] (xenial-proposed) [15.0.1+ds-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted squirrelmail [source] (xenial-proposed) [2:1.4.23~svn20120406-2ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted squirrelmail [source] (yakkety-proposed) [2:1.4.23~svn20120406-2ubuntu1.16.10.1]
<Odd_Bloke> cloud-init on https://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html says "Not touching package due to block request by freeze"; what's causing that?
-queuebot:#ubuntu-release- Unapproved: simplestreams (xenial-proposed/main) [0.1.0~bzr426-0ubuntu1.1 => 0.1.0~bzr426-0ubuntu1.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (trusty-proposed/main) [1:2014.1.5-0ubuntu7 => 1:2014.1.5-0ubuntu8] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: python-libusb1 [amd64] (zesty-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytango [s390x] (zesty-proposed/universe) [9.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytango [ppc64el] (zesty-proposed/universe) [9.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted lxde-common [amd64] (zesty-proposed) [0.99.2-2]
-queuebot:#ubuntu-release- New: accepted python-libusb1 [amd64] (zesty-proposed) [1.6-1]
-queuebot:#ubuntu-release- New binary: pytango [i386] (zesty-proposed/universe) [9.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytango [powerpc] (zesty-proposed/universe) [9.2.0-2] (no packageset)
<lamont> rbasak: you around?
-queuebot:#ubuntu-release- New binary: pytango [amd64] (zesty-proposed/universe) [9.2.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.3 => 0.27ubuntu1.4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.6 => 0.122ubuntu8.7] (core)
<rbasak> lamont: o/
<lamont> rbasak: can you let c-i-t and i-t into xenial-proposed pls?
<lamont> I will have at least one for yakkety, once I finish testing it
<rbasak> lamont: has smoser reviewed these diffs?
<lamont> rbasak: he reviewed their predecessors, causing the need for the diff you see in c-i-t with his review, and finally letting me test his upload from monday, which has issuese on xenial and was not complete
<rbasak> This is a mess :-(
<lamont> iow, no he hasn't, but they're fixing things that would have been caught earlier if we had the packages, or were caused by said review
<lamont> you don't want me to get going...
 * lamont is on holiday today
<rbasak> It feels like uploaders are throwing things at the SRU team in the hope that something will stick.
<jamespage> rbasak, hey could the yakkety bit for https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1587261 be released as well please
<ubot5> Ubuntu bug 1587261 in ceph (Ubuntu Yakkety) "[SRU] Swift bucket X-Timestamp not set by Rados Gateway" [High,Fix committed]
<rbasak> Right now I have zero confidence that anything involving this bug won't cause regressions, because I can't keep track of who has uploaded what, reviewed what, accepted what into proposed and released what into updates, multiplied by three releases.
<rbasak> jamespage: I skipped Yakkety this morning because bug 1631328 hasn't yet been verified.
<ubot5> bug 1631328 in ceph (Ubuntu Yakkety) "ceph-osd stays blocked on Yakkety: "No block devices detected using current configuration"" [Undecided,Fix committed] https://launchpad.net/bugs/1631328
<jamespage> rbasak, hmm verification-done-yakkety should indicate that its done
<lamont> rbasak: the short history is that there were issues with the original uploads, so they were reverted.  After that it has been a long series of TRYING TO ACTUALLY GET STUFF TO TEST, where some people insist on only uploading them to -proposed, or making additional/different changes from what was tested in the PPA to do the upload to -proposed
<lamont> rbasak: see also /query
<rbasak> jamespage: I don't see that tag.
<jamespage> rbasak, its there :-)
<rbasak> jamespage: are we looking at the same bug?
<rbasak> https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1631328
<ubot5> Ubuntu bug 1631328 in ceph (Ubuntu Yakkety) "ceph-osd stays blocked on Yakkety: "No block devices detected using current configuration"" [Undecided,Fix committed]
<jamespage> rbasak, no
<jamespage> bug 1587261
<ubot5> bug 1587261 in ceph (Ubuntu Yakkety) "[SRU] Swift bucket X-Timestamp not set by Rados Gateway" [High,Fix committed] https://launchpad.net/bugs/1587261
<smoser> lamont, i suspect your issue is really https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1629972
<ubot5> Ubuntu bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged]
<lamont> smoser: and the way that bug is correctly fixed in xenial is to say 'manual' in the interface line
<jamespage> rbasak, I'd not spotted that one - marked verification done as well (I re-tested this all earlier in the week)
-queuebot:#ubuntu-release- New binary: double-conversion [ppc64el] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
<lamont> smoser: and please, let's not rehash the last month on this my first day of vacation, OK?
<smoser> lamont, well, your change is not needed if the fix to not take down 'lo' is applied in ifupdown
<rbasak> jamespage: OK. I'd like to wait for http://people.canonical.com/~ubuntu-archive/pending-sru.html to go green - avoids human error.
<smoser> which is why you dont see the issue in yakkety+
<lamont> smoser: I'm a big fan of not landing YET MORE CHANGES as part of this (now fully) tested mess
-queuebot:#ubuntu-release- New binary: double-conversion [arm64] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: double-conversion [armhf] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: double-conversion [amd64] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: double-conversion [i386] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: double-conversion [s390x] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
<rbasak> I am unwilling to accept a mess.
-queuebot:#ubuntu-release- New binary: double-conversion [powerpc] (zesty-proposed/main) [2.0.1-4ubuntu1] (kubuntu, ubuntu-desktop)
<rbasak> If multiple iterations are needed until everyone involved is happy with an SRU, then so be it.
<rbasak> Those iterations should ideally happen before upload.
<lamont> rbasak: you think? ;2~^*%&^*)&(
<lamont> they started life in a ppa, and were working just fine in late october.  Getting those through to actual "approved" uploads is how we got to the uploads to -proposed friday/monday/tuesday.  In that time, changes were introduced that caused them to not work, whcih are what my uploads are fixing now.
<lamont> and yes, those review changes should have gone into a ppa first.
<smoser> lamont, your latest set of changes there really are not correct.
<lamont> I'm certain that this will be a favorite conversation topic at a sprint next week.
<lamont> smoser: of course you say that
<smoser> they may solve your issue, but they change the ENI written by cloud-initramfs-dyn-netconf
<smoser> making it differ from those that are written by cloud-init
<lamont> and?
<smoser> so instead of the iscsi root boot getting the same ENI in xenial and in yakkety or zesty, you'll get a different one.
-queuebot:#ubuntu-release- New: accepted double-conversion [amd64] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted double-conversion [armhf] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted double-conversion [powerpc] (zesty-proposed) [2.0.1-4ubuntu1]
<smoser> only so that you can "fix" this issue that has a proper fix in the bug i pointed at
-queuebot:#ubuntu-release- New: accepted double-conversion [s390x] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted double-conversion [arm64] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted double-conversion [ppc64el] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted double-conversion [i386] (zesty-proposed) [2.0.1-4ubuntu1]
-queuebot:#ubuntu-release- New binary: pytango [armhf] (zesty-proposed/universe) [9.2.0-2] (no packageset)
<lamont> smoser: this would have been a good discussion to have when you merged the chagnes november 2nd, and gave me packages for testing and we discovered this.
<lamont> only no packages were created
<smoser> ? where did i merge those changes ?
<smoser> maybe i've forgotten something
<lamont> https://code.launchpad.net/~lamont/cloud-initramfs-tools/bug-1621615-device6 was what you merged into trunk
<smoser> trunk still writes what xenial-proposed writes.
<smoser> xenial-proposed is a backport of trunk from tip-1
<lamont> no comparison to the ppa where we had those changes in the xenial version of c-i-t were looked at, nor was a xenial "official" upload prepared until the 28th, which is how we are having this discusion now, instead of then
-queuebot:#ubuntu-release- New binary: pytango [arm64] (zesty-proposed/universe) [9.2.0-2] (no packageset)
<lamont> smoser: but it doesn't write what the xenial version in my ppa wrote, that was verified to be working in late october.  The backport of the MP was not available to test until Monday.  And actually testable after cyphermox got his stuff through your review yesterday.  And so I found the issue last night.
<rbasak> <smoser> they may solve your issue, but they change the ENI written by cloud-initramfs-dyn-netconf
<rbasak> smoser: does this mean that you are -1 to accept this upload?
-queuebot:#ubuntu-release- New: accepted pytango [amd64] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [armhf] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [powerpc] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [s390x] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [arm64] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [ppc64el] (zesty-proposed) [9.2.0-2]
-queuebot:#ubuntu-release- New: accepted pytango [i386] (zesty-proposed) [9.2.0-2]
<smoser> fixing bug 1629972 is the right fix. :-(
<ubot5> bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu6.2 => 0.125ubuntu6.3] (core)
<lamont> can we at least agree on the initramfs-tools uploads? (x and y)
<lamont> smoser: if you want to fix it the other way, go for it.  /me EOW
<smoser> lamont, i'll SRU the change to xenial
<smoser> the fix for ifupdown localhost
<rbasak> Am I being asked to reject the latest uploads for this bug?
 * rbasak still doesn't know what's going on.
<rbasak> If I don't, then some other SRU team member may come and accept them tomorrow.
<smoser> lamont, rbasak I can +1 the initramfs-tools upload for xenial.
<roaksoax> /w/win 8
<smoser> lamont, :-(. so if you do not rely on the debug variables form dhclient, how do you know that dhclient succeeded ? i think that is what you were using that for.
<smoser> as opposed to failed, and left that file around (because to my knowledge nothing is removing the file)
<roaksoax> smoser: lamont is on holiday now, we should syncup next week and revsolve this critically. Deliverable is December 31st and we dont have more time left
<cyphermox> smoser: the file is written to /run, it will be blasted away on reboot.
<rbasak> roaksoax: +1. Most of the SRU team will be there too I think.
<roaksoax> smoser: but cyphermox does make sense it being written in /run , that's what /run is for anyway
<cyphermox> lamont was doing this upload (Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu6.2 => 0.125ubuntu6.3] (core)) to make sure all was good, removing the one case we'd missed where the "debug" variables (not debug at all) were used
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.18 => 1:16.04.19] (core)
<cyphermox> rbasak: if you can accept that initramfs-tools, all is well.
<rbasak> I'm reluctant, because I still don't understand what's going on. And I'm supposed to review, even if you have consensus.
<cyphermox> what's missing?
<rbasak> Context around any review.
<cyphermox> yes, what is it that you don't understand?
<rbasak> We're fixing a single issue, right? For which a fix requires updates to multiple packages?
<cyphermox> yes
<smoser> cyphermox, of course its in /run. its in the initramfs
<smoser> but if dhclient failed
<smoser> then you wont recognize that
<rbasak> So while you're still debating the other pieces, there is nothing to lose by waiting until you have consensus on all of it.
<smoser> because dhclient writes the file the first time
<cyphermox> the single issue is rather big, being that there is no ipv6 support
<smoser> the first event "starting" or something
<smoser> so that file will always exist, will it not ?
<cyphermox> smoser: what are you talking about?
<rbasak> And if you can't test until something is in proposed, then please fix that.
<rbasak> IMHO, anyway. If someone else in the SRU team wants to review/accept, then fine.
<cyphermox> we've tested everything we could test before things are in proposed. as far as we know, it works
<roaksoax> yes, eveyrthing was tested even before it was in -proposed
<roaksoax> but getting things in -proposed is the ultimate validation
<cyphermox> yes
<rbasak> But you haven't agreed on everything that will land in -proposed.
<rbasak> To fix this one issue.
<cyphermox> haven't we?
<rbasak> Not from my reading of what's immediately above.
<smoser> cyphermox, your isc-dhcp debian/initramfs-tools/lib/etc/dhcp/dhclient-enter-hooks.d/config willi create that file always
<rbasak> I thought you just agreed to resolve that next week?
<smoser> even on dhclient failure
<cyphermox> smoser: what?
<rbasak> If you have agreement, then what are you going to be resolving next week?
<smoser> http://paste.ubuntu.com/23558750/
<smoser> thats the file that will write /run/net-DEVICE.conf for you
<smoser> right ?
<cyphermox> smoser: you're using an outdated diff, I already addressed that
<smoser> where ?
<cyphermox> https://launchpadlibrarian.net/295439359/isc-dhcp_4.3.3-5ubuntu12.4_4.3.3-5ubuntu12.5.diff.gz
<cyphermox> isc-dhcp is already in proposed
<smoser> oh. good. ok.
<roaksoax> rbasak: ^^ there's no blocker
<smoser> yeah, then this looks fine.
<cyphermox> ^ that dropped 'reason', so lamont's further upload fixed that bit
<smoser> ok. fyi, your 'IPVER' is no longer used at all
<rbasak> roaksoax: the blocker is that this is a mess. I have no confidence in anything anyone says because there is so much confusion. There doesn't seem to be a single place of reference for developers to review things and agree. Instead I feel like I'm getting uploads thrown at me. I don't know what has been reviewed by whom.
<cyphermox> heh
<rbasak> So I'm out. If you want me to review something, I'll only do it all at once, when everyone has agreed to what it is, from one place.
<rbasak> Otherwise, find another SRU team member please.
<rbasak> Use bzr MPs, git MPs, sha256sums of signed dscs in the bug, I don't care.
<rbasak> But there needs to be a single point of reference.
<cyphermox> there is, that's what's in proposed. the archive is always what's authoritative, so the only thing we need to all be agreeing upon is what's in the unapproved queue right now
<cyphermox> I know lamont and I agree, we just need an ack from smoser, which I thought we just got here a few minutes ago?
<rbasak> infinity1, slangasek, apw, bdmurray, RAOF, arges, pitti, stgraber, tjaalton: FYI, this is my opinion about bug 1621507 ^. But if you want to take this on, please do.
<ubot5> bug 1621507 in open-iscsi (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<roaksoax> cyphermox: so we only have : http://launchpadlibrarian.net/295554410/cloud-initramfs-tools_0.27ubuntu1.3_0.27ubuntu1.4.diff.gz and http://launchpadlibrarian.net/295554420/initramfs-tools_0.122ubuntu8.6_0.122ubuntu8.7.diff.gz
<cyphermox> roaksoax: correct.
<roaksoax> cyphermox: which is what we had agreed to initially, and which lamont had to upload to match what we had agree to ?
<cyphermox> yes.
<roaksoax> rbasak: ^^ so right there
<roaksoax> alright, so that's very clear then. We have 2 things in unapproved queue which addresses the last remaining issues that were missed in the previous upload
<cyphermox> roaksoax: I think rbasak said he'd rather someone else look into it, I respect his decision. fixing this bug *is* complicated, more eyes on it isn't bad.
-queuebot:#ubuntu-release- New binary: itango [amd64] (zesty-proposed/universe) [0.1.6-1] (no packageset)
<roaksoax> cyphermox: I'm totally fine with that, but I think he got the ipression that we weren't in sync on what the solution was and it was kind of a mess, which I disagree with :)
<smoser> cyphermox, roaksoax i just verified yakkety's bug 1629972 .
<ubot5> bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972
<smoser> i will upload an sru for that change to xenial
<cyphermox> smoser: what are you changing?
<cyphermox> (I'm just curious, yay for fixing it)
<smoser> cyphermox, https://git.launchpad.net/~usd-import-team/ubuntu/+source/ifupdown/commit/?h=ubuntu/yakkety-devel&id=8939b1cca88520666e3c72ea85f946c22695e806
<cyphermox> smoser: oh, cool.
<smoser> its really wierd, the networkign stop does not actually take down the ipv6 interface that was configured in initramfs on shutdown.
<smoser> but it took down lo.
<smoser> and that immediately breaks ipv6 networking
-queuebot:#ubuntu-release- Unapproved: ifupdown (xenial-proposed/main) [0.8.10ubuntu1.1 => 0.8.10ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (trusty-proposed/main) [1:0.220.8 => 1:0.220.9] (core)
<bdmurray> infinity: Do we really need an upload of the precise release upgrader?
<infinity> bdmurray: Yep.
<bdmurray> infinity: Where would I find the source to update from?
<infinity> bdmurray: pull-lp-source?
<infinity> pull-lp-source && dch -i && dpkg-buildpackage -uc -us -nc -S
<bdmurray> pull-lp-source: Error: Unable to retrieve package information from DDE: http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:precise/p:ubuntu-release-upgrader/?t=json (<urlopen error [Errno -2] Name or service not known>)
<bdmurray> pull-lp-source: Error: The source package 'ubuntu-release-upgrader' does not exist in the Ubuntu primary archive in precise, precise-security, precise-updates or precise-proposed
<xnox> wasn't it renamed in trusty, and split into two source packages?
<xnox> hence in precise it was under a different name
<xnox> bdmurray, it's just "update-manager" source package in precise, no?
<bdmurray> xnox: oh right, I hate that
<xnox> however i don't see the right bits in precise update-manager.... or is it there? can you remember where it actually is in precise now?
<xnox> really before my time, i joined canonical with quantal =)
<bdmurray> xnox: its in update-manager
-queuebot:#ubuntu-release- Unapproved: update-manager (precise-proposed/main) [1:0.156.14.20 => 1:0.156.14.21] (core)
<doko> infinity: do you have list of ingnored autopkg tests for your last upload?
<infinity> doko: I'm looking into the current failures, and redoing the merge with some test fixes.
<doko> infinity: just test fixes? that will throw back the autopkg tests again ...
<infinity> doko: No, as in I'm testing changes to glibc to fix the test regressions.
<bdmurray> Could somebody have a look at my ubuntu-release-upgrader uploads in the X and T queues.
<bdmurray> ?
-queuebot:#ubuntu-release- Unapproved: owncloud-client (yakkety-proposed/universe) [2.2.2+dfsg-1 => 2.2.2+dfsg-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.5 => 1.157.6] (core, kernel)
<bdmurray> I'll just review my own since there aren't really any changes
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.19]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (trusty-proposed) [1:0.220.9]
<ginggs> would someone please decruft texlive-extra? texlive-science now provides texlive-math-extra
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.0.0-0ubuntu1 => 2:9.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.0-0ubuntu1 => 1:7.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0-0ubuntu1 => 3:10.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.2.1-0ubuntu1 => 1:6.2.2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New binary: hollywood [amd64] (zesty-proposed/universe) [1.11-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (precise-proposed) [1:0.156.14.21]
#ubuntu-release 2016-12-01
<valorie> weeee, landing is awesomesauce
<valorie> oh shoot, wrong chan, sorry
-queuebot:#ubuntu-release- Unapproved: accepted python-jujuclient [source] (xenial-proposed) [0.50.5-0ubuntu2~16.04]
-queuebot:#ubuntu-release- Unapproved: accepted python-jujuclient [source] (yakkety-proposed) [0.50.5-0ubuntu2~16.10]
-queuebot:#ubuntu-release- New binary: adwaita-qt [i386] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [ppc64el] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [amd64] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [arm64] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [armhf] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quagga [ppc64el] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: quagga [i386] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: quagga [amd64] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: adwaita-qt [s390x] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [ppc64el] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [powerpc] (zesty-proposed/universe) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quagga [arm64] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: quagga [armhf] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: quagga [s390x] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: golang-github-bep-inflect [amd64] (zesty-proposed/none) [0.0~git20160408.0.b896c45-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-buffruneio [amd64] (zesty-proposed/none) [0.0~git20160124.0.df1e16f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [amd64] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yasnippet [amd64] (zesty-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [arm64] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [i386] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [armhf] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fortytw2-leaktest [amd64] (zesty-proposed/none) [0.0~git20160923.0.0db74e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: casacore-data-lines [amd64] (zesty-proposed/none) [0+git2016.11.26-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quagga [powerpc] (zesty-proposed/main) [1.1.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: casacore-data-sources [amd64] (zesty-proposed/none) [2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hydrogen [amd64] (zesty-proposed/universe) [0.9.7-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [s390x] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-docker-docker-credential-helpers [powerpc] (zesty-proposed/none) [0.3.0+git20160601.0.5128fa1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.5 => 1.3.1-1ubuntu10.6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu9 => 2.1.0-1ubuntu9.1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: purify [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [ppc64el] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [amd64] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [s390x] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [i386] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted quagga [amd64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [armhf] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [powerpc] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [s390x] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [arm64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [ppc64el] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted quagga [i386] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: suricata [arm64] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted adwaita-qt [amd64] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [armhf] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [powerpc] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [s390x] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [arm64] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [ppc64el] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [i386] (zesty-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [amd64] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [armhf] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [powerpc] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [s390x] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [arm64] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [ppc64el] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-docker-docker-credential-helpers [i386] (zesty-proposed) [0.3.0+git20160601.0.5128fa1-1]
-queuebot:#ubuntu-release- New: accepted casacore-data-lines [amd64] (zesty-proposed) [0+git2016.11.26-1]
-queuebot:#ubuntu-release- New: accepted golang-github-bep-inflect [amd64] (zesty-proposed) [0.0~git20160408.0.b896c45-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-buffruneio [amd64] (zesty-proposed) [0.0~git20160124.0.df1e16f-1]
-queuebot:#ubuntu-release- New: accepted hydrogen [amd64] (zesty-proposed) [0.9.7-1]
-queuebot:#ubuntu-release- New: accepted purify [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted casacore-data-sources [amd64] (zesty-proposed) [2-1]
-queuebot:#ubuntu-release- New: accepted hollywood [amd64] (zesty-proposed) [1.11-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yasnippet [amd64] (zesty-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-fortytw2-leaktest [amd64] (zesty-proposed) [0.0~git20160923.0.0db74e8-1]
-queuebot:#ubuntu-release- New: accepted itango [amd64] (zesty-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New binary: suricata [powerpc] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [armhf] (zesty-proposed/universe) [3.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted suricata [amd64] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [armhf] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [powerpc] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [s390x] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [arm64] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [ppc64el] (zesty-proposed) [3.1.3-3]
-queuebot:#ubuntu-release- New: accepted suricata [i386] (zesty-proposed) [3.1.3-3]
<flocculant> update yesterday killed printers in Xubuntu, this morning neither that nor Mate built - not sure how many other flavours would be involved, but cause is system-config-printer-common : Breaks: system-config-printer-gnome (< 1.5.7+20160812-0ubuntu3~) but 1.5.7+20160812-0ubuntu2 is to be installed
<Laney> flocculant: you probably want https://code.launchpad.net/~jbicha/ubuntu-seeds/xubuntu-system-config-printer/+merge/312069
<flocculant> Laney: ta - wasn't too bothered locally, not even got the printer plugged in - just thought I'd say something before it's April :D
<flocculant> ty for info though - installed sys-conf-printer and it worketh once more
<Laney> flocculant: Worth passing on to someone to upload that
<flocculant> I did about 30 seconds ago for us :)
<Laney> cool
<flocculant> don't tell me - even had gloves on today :p
<Laney> flocculant: dad jokes
<ginggs> would someone please decruft texlive-extra? texlive-science now provides texlive-math-extra
<cjwatson> "decruft" isn't a thing in Ubuntu.
<cjwatson> What exactly is happening?
<cjwatson> Oh, NBS removal in -proposed
<cjwatson> ginggs: done
<ginggs> cjwatson: thanks!
-queuebot:#ubuntu-release- New binary: freedict [amd64] (zesty-proposed/universe) [2016.10.22-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted freedict [amd64] (zesty-proposed) [2016.10.22-2]
-queuebot:#ubuntu-release- Unapproved: gcc-5-cross (xenial-proposed/main) [24ubuntu0.1 => 24ubuntu0.2] (ubuntu-desktop)
<ginggs> cjwatson: hi again, i guess you haven't had a chance to look at the node stuff yet? LP: #1644894
<ubot5> Launchpad bug 1644894 in node-type-check (Ubuntu) "node-jison needs bootstrapping" [Undecided,New] https://launchpad.net/bugs/1644894
<cjwatson> not as yet, sorry
<cjwatson> middle of project with scary deadline
<ginggs> ok, thanks
<tyhicks> hello - can someone reject my apparmor (2.10.95-0ubuntu2.5~14.04.1) and upstart (1.12.1-0ubuntu4.3) trusty uploads?
<tyhicks> (I've got a new apparmor upload and the upstart upload is no longer needed)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0-0ubuntu1.16.10.2 => 2:9.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: largetifftools [ppc64el] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [amd64] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [s390x] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [ppc64el] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qstopmotion [ppc64el] (zesty-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [amd64] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [i386] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [arm64] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (yakkety-proposed/universe) [4.2.0-1 => 4.2.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [armhf] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [s390x] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [arm64] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [powerpc] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qstopmotion [s390x] (zesty-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [armhf] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guacamole-server [i386] (zesty-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qstopmotion [amd64] (zesty-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: largetifftools [powerpc] (zesty-proposed/universe) [1.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qstopmotion [i386] (zesty-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qstopmotion [powerpc] (zesty-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: systemd [i386] (zesty-proposed/main) [232-7] (core)
-queuebot:#ubuntu-release- New binary: systemd [s390x] (zesty-proposed/main) [232-7] (core)
-queuebot:#ubuntu-release- New binary: systemd [ppc64el] (zesty-proposed/main) [232-7] (core)
-queuebot:#ubuntu-release- New: accepted largetifftools [amd64] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [armhf] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [powerpc] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [s390x] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [arm64] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [ppc64el] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted largetifftools [i386] (zesty-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [amd64] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [armhf] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [powerpc] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [s390x] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [arm64] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [ppc64el] (zesty-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted guacamole-server [i386] (zesty-proposed) [0.9.9-1]
<bdmurray> xnox: So you are saying bug 1645906 is all v-done?
<ubot5> bug 1645906 in ubuntu-release-upgrader (Ubuntu) "new dist-upgrader tarballs necessary so they are signed with 4k key" [Undecided,New] https://launchpad.net/bugs/1645906
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (yakkety-proposed/universe) [4.2.0-1 => 4.2.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: systemd [powerpc] (zesty-proposed/main) [232-7] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ironic-inspector [source] (yakkety-proposed) [4.2.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- New binary: systemd [amd64] (zesty-proposed/main) [232-7] (core)
<tyhicks> ping for someone to reject my apparmor (2.10.95-0ubuntu2.5~14.04.1) and upstart (1.12.1-0ubuntu4.3) trusty SRU uploads
<seb128> tyhicks, done
-queuebot:#ubuntu-release- Unapproved: rejected upstart [source] (trusty-proposed) [1.12.1-0ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: rejected apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.5~14.04.1]
-queuebot:#ubuntu-release- New binary: systemd [armhf] (zesty-proposed/main) [232-7] (core)
<tyhicks> thanks seb128!
<seb128> yw!
-queuebot:#ubuntu-release- Unapproved: lttng-modules (yakkety-proposed/universe) [2.8.0-1 => 2.8.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: systemd [arm64] (zesty-proposed/main) [232-7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted keepalived [source] (yakkety-proposed) [1:1.2.23-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted keepalived [source] (xenial-proposed) [1:1.2.19-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted opencc [source] (yakkety-proposed) [1.0.4-1ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted hexchat [source] (yakkety-proposed) [2.12.0-2ubuntu2.1]
-queuebot:#ubuntu-release- New: accepted systemd [arm64] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New: accepted systemd [i386] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New binary: opencc [amd64] (yakkety-proposed/universe) [1.0.4-1ubuntu0.16.10.1] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted systemd [amd64] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New: accepted systemd [powerpc] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New: accepted systemd [armhf] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- New: accepted systemd [s390x] (zesty-proposed) [232-7]
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (yakkety-proposed) [7.0.13-0ubuntu0.16.10.1]
<xnox> bdmurray, yes.
<xnox> bdmurray, do you feel like waving the 7day wait?
-queuebot:#ubuntu-release- New: accepted qstopmotion [amd64] (zesty-proposed) [2.3.2-1]
-queuebot:#ubuntu-release- New: accepted qstopmotion [powerpc] (zesty-proposed) [2.3.2-1]
-queuebot:#ubuntu-release- New: accepted qstopmotion [s390x] (zesty-proposed) [2.3.2-1]
<bdmurray> xnox: I'm fine with waiving it, but maybe Monday makes more sense for the release.
-queuebot:#ubuntu-release- New: accepted qstopmotion [i386] (zesty-proposed) [2.3.2-1]
-queuebot:#ubuntu-release- New: accepted qstopmotion [ppc64el] (zesty-proposed) [2.3.2-1]
<bdmurray> xnox: since people will be traveling etc...
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (xenial-proposed) [7.0.13-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected glib2.0 [source] (yakkety-proposed) [2.50.2-2ubuntu1]
<xnox> bdmurray, yeah.
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (yakkety-proposed) [7.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (yakkety-proposed) [1:2.6.1+dfsg-0ubuntu5.2]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu3~16.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [source] (yakkety-proposed) [2.2.2+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (yakkety-proposed) [3.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu0.16.10.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (yakkety-proposed) [3.0.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (yakkety-proposed) [3.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross [source] (xenial-proposed) [24ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu0.16.10.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [source] (yakkety-proposed) [4.2.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (yakkety-proposed) [2.8.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu6.3]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (yakkety-proposed) [2016.03+dfsg1-6ubuntu2~1.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (yakkety-proposed) [1.20161020-0ubuntu1~1.1]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (yakkety-proposed) [3.0~rc.4ubuntu64.1.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.11+16.10ubuntu1 => 0.12+16.10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apparmor (trusty-proposed/main) [2.8.95~2430-0ubuntu5.3 => 2.10.95-0ubuntu2.5~14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: dbus (trusty-proposed/main) [1.6.18-0ubuntu4.4 => 1.6.18-0ubuntu4.5] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.11+16.04ubuntu1 => 0.12+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-49-g9e904bb-0ubuntu1~16.04.1 => 0.7.8-49-g9e904bb-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (xenial-proposed) [0.1.0~bzr426-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (trusty-proposed/main) [1.127.22 => 1.127.23] (core, kernel)
<Laney> bdmurray: You rejected the newer glib2.0, which had the fixed Launchpad-Bugs-Fixed.
<bdmurray> Laney: Yeah, sorry I didn't realize that was an issue.
<Laney> np
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [0.96.20.5]
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (xenial-proposed) [0.9.4-1ubuntu2]
-queuebot:#ubuntu-release- New binary: minicoredumper [ppc64el] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [s390x] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-cloneable-readable [amd64] (zesty-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-json-stable-stringify [amd64] (zesty-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ordered-read-streams [amd64] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-jsonify [amd64] (zesty-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [i386] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [armhf] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [arm64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minicoredumper [powerpc] (zesty-proposed/universe) [2.0.0-1] (no packageset)
#ubuntu-release 2016-12-02
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-104.151~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-76.84~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-76.84] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-52.73~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-29.31] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-104.151] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-52.73] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-29.31]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-76.84]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-52.73]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-104.151]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-76.84~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-52.73~14.04.1]
-queuebot:#ubuntu-release- Unapproved: metar (xenial-proposed/universe) [20061030.1-2ubuntu2 => 20061030.1-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.0.16-0ubuntu2 => 2.1.5-0ubuntu4~14.04.0] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mesa (yakkety-proposed/main) [12.0.3-1ubuntu2 => 12.0.4-2ubuntu1~16.10.1] (core, xorg)
<ginggs> hi, any archive admins around to clean up pandas please? LP: #1643151
<ubot5> Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,New] https://launchpad.net/bugs/1643151
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (yakkety-proposed) [12.0.4-2ubuntu1~16.10.1]
<LocutusOfBorg> hi, is anybody there console-setup savvy?
<LocutusOfBorg> xnox, pitti ?
<LocutusOfBorg> wrt launchpad bug lp: #1443853
<ubot5> Launchpad bug 1443853 in kbd (Ubuntu) "Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a corrupted display" [Undecided,Confirmed] https://launchpad.net/bugs/1443853
<LocutusOfBorg> the fix might be simple
<josvaz> tjaalton: can I get you to check http://launchpadlibrarian.net/295832848/walinuxagent_2.1.5-0ubuntu4~14.04.0_source.changes getting into proposed?
<josvaz> this is the test plan: https://wiki.ubuntu.com/walinuxagentUpdates
<josvaz> Azure wants to get trusty catchup with yakkety and recently xenial on walinuxagent 2.1.5
<josvaz> Pre-SRU Test Cases
<josvaz> passed with this package
<josvaz> tjaalton: let me know if something is missing or needs fixing
<josvaz> slangasek: could you take a look to http://launchpadlibrarian.net/295832848/walinuxagent_2.1.5-0ubuntu4~14.04.0_source.changes in case can't?
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.5-0ubuntu1~ubuntu14.04.1 => 2.0.8-0ubuntu1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.8-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-49-g9e904bb-0ubuntu1~16.10.1 => 0.7.8-61-g2d2ec70-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (yakkety-proposed/main) [5.10.0-0ubuntu1 => 5.10.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (xenial-proposed/main) [4.6.1-2ubuntu1 => 4.6.1-2ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- New binary: seqan2 [i386] (zesty-proposed/universe) [2.2.0+dfsg-4ubuntu1] (no packageset)
<tjaalton> josvaz: EOD already, sorry
-queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [7.11.90.20161005-0ubuntu1 => 7.11.90.20161005-0ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.19 => 1:16.04.20] (core)
-queuebot:#ubuntu-release- Unapproved: gdb (xenial-proposed/main) [7.11.1-0ubuntu1~16.04 => 7.11.1-0ubuntu1~16.04.1] (core)
-queuebot:#ubuntu-release- New binary: seqan2 [amd64] (zesty-proposed/universe) [2.2.0+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted minicoredumper [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [armhf] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [powerpc] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [s390x] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [arm64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [ppc64el] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted minicoredumper [i386] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-cloneable-readable [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-jsonify [amd64] (zesty-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-json-stable-stringify [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-ordered-read-streams [amd64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted seqan2 [amd64] (zesty-proposed) [2.2.0+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted seqan2 [i386] (zesty-proposed) [2.2.0+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: deja-dup (xenial-proposed/main) [34.2-0ubuntu1 => 34.2-0ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lambda-align [amd64] (zesty-proposed/universe) [1.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lambda-align [i386] (zesty-proposed/universe) [1.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-toml [ppc64el] (zesty-proposed/universe) [0.3.5+git20161123.19.7cb9880-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-toml [s390x] (zesty-proposed/universe) [0.3.5+git20161123.19.7cb9880-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modelmetrics [ppc64el] (zesty-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sqlsoup [amd64] (zesty-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-weaveworks-mesh [amd64] (zesty-proposed/universe) [0+git20161024.3dd75b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-toml [i386] (zesty-proposed/universe) [0.3.5+git20161123.19.7cb9880-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-codegen [amd64] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-restic-chunker [amd64] (zesty-proposed/universe) [0.0~git20160919.0.bb2ecf9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modelmetrics [s390x] (zesty-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-toml [amd64] (zesty-proposed/universe) [0.3.5+git20161123.19.7cb9880-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-portpicker [amd64] (zesty-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sigmavirus24-urltemplate [amd64] (zesty-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-plogr [amd64] (zesty-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdata-treedumper-oo-perl [amd64] (zesty-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modelmetrics [amd64] (zesty-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pretty-yaml [amd64] (zesty-proposed/universe) [16.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-clean-test [amd64] (zesty-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-google-genproto [amd64] (zesty-proposed/universe) [0.0~git20161115.08f135d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-flask-sockets [amd64] (zesty-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-string.prototype.codepointat [amd64] (zesty-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-elithrar-simple-scrypt [amd64] (zesty-proposed/universe) [1.1+git20161119.3.2325946-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-efilter [amd64] (zesty-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-death [amd64] (zesty-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modelmetrics [i386] (zesty-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pelletier-go-toml [powerpc] (zesty-proposed/universe) [0.3.5+git20161123.19.7cb9880-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modelmetrics [powerpc] (zesty-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-elithrar-simple-scrypt [amd64] (zesty-proposed) [1.1+git20161119.3.2325946-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-toml [i386] (zesty-proposed) [0.3.5+git20161123.19.7cb9880-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-toml [ppc64el] (zesty-proposed) [0.3.5+git20161123.19.7cb9880-1]
-queuebot:#ubuntu-release- New: accepted golang-github-restic-chunker [amd64] (zesty-proposed) [0.0~git20160919.0.bb2ecf9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-toml [amd64] (zesty-proposed) [0.3.5+git20161123.19.7cb9880-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-toml [s390x] (zesty-proposed) [0.3.5+git20161123.19.7cb9880-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pelletier-go-toml [powerpc] (zesty-proposed) [0.3.5+git20161123.19.7cb9880-1]
-queuebot:#ubuntu-release- New: accepted golang-github-weaveworks-mesh [amd64] (zesty-proposed) [0+git20161024.3dd75b1-1]
-queuebot:#ubuntu-release- New: accepted lambda-align [amd64] (zesty-proposed) [1.0.0-3]
-queuebot:#ubuntu-release- New: accepted libdata-treedumper-oo-perl [amd64] (zesty-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted golang-google-genproto [amd64] (zesty-proposed) [0.0~git20161115.08f135d-1]
-queuebot:#ubuntu-release- New: accepted lambda-align [i386] (zesty-proposed) [1.0.0-3]
-queuebot:#ubuntu-release- New: accepted node-death [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-codegen [amd64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted python-flask-sockets [amd64] (zesty-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-pretty-yaml [amd64] (zesty-proposed) [16.11.4-1]
-queuebot:#ubuntu-release- New: accepted python-sqlsoup [amd64] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modelmetrics [i386] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modelmetrics [ppc64el] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-plogr [amd64] (zesty-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted node-string.prototype.codepointat [amd64] (zesty-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-portpicker [amd64] (zesty-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modelmetrics [amd64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modelmetrics [s390x] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-efilter [amd64] (zesty-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modelmetrics [powerpc] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-sigmavirus24-urltemplate [amd64] (zesty-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-clean-test [amd64] (zesty-proposed) [1.0.0-1]
#ubuntu-release 2016-12-03
<slangasek> josvaz: accepted
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.1.5-0ubuntu4~14.04.0]
-queuebot:#ubuntu-release- New binary: ruby-gli [amd64] (zesty-proposed/universe) [2.14.0-1] (no packageset)
<sergiusens> slangasek since I see your recent comment, mind allowing snapcraft into xenial-proposed and yakkety-proposed
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.22.1+16.10 => 2.23+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.22.1 => 2.23] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.5-0ubuntu1.2 => 2.0.6-0ubuntu1~ubuntu16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.5-0ubuntu1~ubuntu16.04.3 => 2.0.6-0ubuntu1~ubuntu16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.4-0ubuntu1~ubuntu16.04.1 => 2.0.5-0ubuntu1~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.4-0ubuntu1 => 2.0.5-0ubuntu1~ubuntu16.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-proposed/main) [2.0.5-0ubuntu1~ubuntu14.04.1 => 1.0.9-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (xenial-proposed/main) [0.0~git20160803.0.f8a6938-0ubuntu1~ubuntu16.04.1 => 0.0~git20161126.1.82a07a6-0ubuntu1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (yakkety-proposed/main) [0.0~git20160803.0.f8a6938-0ubuntu1 => 0.0~git20161126.1.82a07a6-0ubuntu1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-detect-indent [amd64] (zesty-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-end-of-stream [amd64] (zesty-proposed/universe) [1.1.0-1] (no packageset)
#ubuntu-release 2016-12-04
-queuebot:#ubuntu-release- New binary: pd-upp [amd64] (zesty-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toolz [amd64] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [s390x] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [ppc64el] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [amd64] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [i386] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [powerpc] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [armhf] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [arm64] (zesty-proposed/universe) [1.10.0-patch1+docs-2] (no packageset)
#ubuntu-release 2017-11-27
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [amd64] (bionic-proposed) [0.0.1.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [armhf] (bionic-proposed) [0.0.1.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [ppc64el] (bionic-proposed) [0.0.1.1-3]
-queuebot:#ubuntu-release- New: accepted pytrainer [amd64] (bionic-proposed) [1.11.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [arm64] (bionic-proposed) [0.0.1.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [s390x] (bionic-proposed) [0.0.1.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-bitarray [i386] (bionic-proposed) [0.0.1.1-3]
<slangasek> jbicha: I don't know the impact of changing the derivation of the series after it's already been opened; maybe check with infinity?
<cpaelzer> is there a way to get the output of "ip route show 0/0" on the workers that run dep8 tests on LP?
<cpaelzer> I'm tracking down multiple issues on s390x (and others)
<cpaelzer> and since now two seem to come down to that I'm teased how the output looks there
<cpaelzer> My current guess is at least a two line output, but it could be anything
<cpaelzer> there must be a better way than to pollute -proposed with something to print it for me
<cpaelzer> And assuming that there are multiple interfaces on the default routes network
<cpaelzer> which one should I let the tests touch - e.g. how do those interfaces differ?
<infinity> cpaelzer: I'm somewhat torn between "it's probably a misconfiguration if there's more than one interface on an autopkgtest VM" and "why do you care?" :P
<cpaelzer> infinity: I found a set of issues now popping up and failing on s390x
<cpaelzer> infinity: (in case you decide for why do you care)
<cpaelzer> infinity: it turned out the issue is not s390x special - instead formerly those worked on s390x (in containers) but now fail
<cpaelzer> x86 is on always fail for those
<xnox> cpaelzer, good tests, create their own interfaces/bridges and execute tests on those.
<cpaelzer> And the only way to recreate that error that I found is if the command above returns two lines
<xnox> cpaelzer, there is no specification in autopkgtest to abuse interfaces....
<cpaelzer> xnox: lets consider tests ar enot good by default
<xnox> =/
<cpaelzer> and for now I want to make a totally broken bad test a not broken bad test
<xnox> cpaelzer, do declare destroys-testbed and then abuse anything.
<xnox> (or whatever the correct term is)
<apw> cpaelzer, i believe we know it is two lines
<apw> smb, ^^
<cpaelzer> that would match the data I've seen
<apw> i believe it blew up all our testing for something
<cpaelzer> xnox: I'll remember to abuse something once I get the time to do so :-)
<smb> apw, is there a tl;dr?
<cpaelzer> Tests should not rely on network layout
<apw> s390x ADT test runners have two default routes
<apw> at least, maybe more
<cpaelzer> TL;DR is the above
<xnox> =/
<infinity> apw: Really?  Openstack does that?
<xnox> two default routes does not sound right, missconfigured openstack networking for the s390x compute? missconfigured networking profile for autopkgtest tenant on s390x?
<apw> infinity, i thought we thought it was nplan which was doing it, no idea if what it adds is correct
<xnox> it should be all virtualsed network....
<smb> apw, I think all might, which is something that was brought up as feedback to our fan testing
<smb> as part of netplan/systemd-networkd fallout
<cpaelzer> btw your laptop with wire+wireless has two defaults in the sense that matters here
<apw> right our testing units use the default route and were finding more than one, so we fix'd em
<cpaelzer> ip route show 0/0
<xnox> apw, if there is one route on xenial; yet two routes on artful/bionic -> it would smell like networkd fallout.
<cpaelzer> even back on xenial
<infinity> cpaelzer: Only if both are up and have IPs.
<xnox> apw, and yes networkd sets up two routes -> one default; and one that routes self to self.
<infinity> (and routes)
<apw> xnox, it does what now ?
<cpaelzer> yep, as they are for me without ever caring to much to configure soemthing special
<xnox> no idea why it does it; what it means; and why it is useful.
<xnox> apw, i have noticed that when diffing e.g. cloud-init provisioning tables before/after nplan switch.
<cpaelzer> xnox: btw thanks for the hint on "test on own bridges" I won't unroll my stack of fixes but will keep it in mind next work on such
<apw> xnox, a route self to self would not appear as a default route though as in ip route ls 0/0 would not show it
<infinity> So, shouldn't need to play in scalingstack for this.  Booting a generic bionic cloud image should show you what it's doing.
<xnox> apw, ack.
<infinity> The autopkgtest images are just the generic image minus some bits torn out.
<infinity> (But, at the end of the day, a test that makes assumptions about the network setup in the testbed seems a bit busted)
<cpaelzer> infinity: ack I want to make them less busted atm which brought me to the initial question
<infinity> cpaelzer: I guess my point is that the initial question seems irrelevant if you make the tests not care about the testbed's network setup. :P
<cpaelzer> even if I'm not going for the ideal target of being totally non-dependent that will make them better than they are
<apw> cpaelzer, we chose to assume the first default route was the one we wanted if that helps any
<cpaelzer> infinity: you had my buy in already
<cpaelzer> apw: I chose so as well an hour ago
<cpaelzer> thanks
<infinity> In theory, you want the one with the lowest metric.
<infinity> But if you have multiple, the assumption is that all work.
-queuebot:#ubuntu-release- Unapproved: ceph (artful-proposed/main) [12.2.0-0ubuntu1 => 12.2.1-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<infinity> cpaelzer: You also may be interested in 'ip ro get' instead of show.
<infinity> (base)adconrad@nosferatu:~$ ip ro sh 0/0
<infinity> default via 10.0.0.1 dev eth0 proto static metric 100
<infinity> default via 10.0.0.1 dev wlan0 proto static metric 600
<infinity> (base)adconrad@nosferatu:~$ ip ro ge 8.8.8.8
<infinity> 8.8.8.8 via 10.0.0.1 dev eth0 src 10.0.0.4
<infinity> (Will give you the lowest metric, or preferred route)
<apw> infinity, though that does not actually tell you the route, so if you cared about the route component you don't know the prefix informatio there
<cpaelzer> still interesting, thanks infinity
<infinity> apw: No, true, it doesn't, except that if any of our VMs have a static route to 8.8.8.8, rather than it going via 0/0, I'd be very suspicious.
<infinity> And amused.
<apw> indeed all of that, in most cases we are looking specificall for 0/0 so that would work just fine
<infinity> Anyhow, a "head -n1" should be good enough, as a machine with multiple 0/0 routes where they don't all work *is* misconfigured.
<cpaelzer> which is what I currently coded to fix the test
<cpaelzer> (head -n 1)
<slashd> o/ Hi SRU (vanguard: sil2100, infinity) Could you please approve the upload of landscape-client for A, Z, X & T ? thanks in advance
<sil2100> slashd: will take care of those after lunch
<slashd> sil2100, thanks
-queuebot:#ubuntu-release- New source: qqc2-desktop-style (bionic-proposed/primary) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-41.45~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.3 => 2.29.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.29.3~14.04 => 2.29.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.29.3+17.04 => 2.29.4+17.10] (desktop-core, ubuntu-server)
<slashd> tinoco ^
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-41.45~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (artful-proposed) [16.03-0ubuntu3.17.10.1]
<smb> Is it possible to do the same adt hinting for snapd on s390x for xenial as it seems to be done for artful (the error seems to be the same and most likely due to the same reason of being just now moved to nova testing)
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (zesty-proposed) [16.03-0ubuntu3.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (trusty-proposed) [14.12-0ubuntu6.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-defaults [source] (zesty-proposed) [2.7.13-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.3+17.10 => 2.29.4+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.29.4+17.10]
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.29.3+17.04 => 2.29.4+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.29.4+17.10]
-queuebot:#ubuntu-release- New binary: i2c-tools [ppc64el] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [ppc64el] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcleri [ppc64el] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-cron [ppc64el] (bionic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcleri [arm64] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [ppc64el] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [ppc64el] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2c-tools [s390x] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [amd64] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libcleri [armhf] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [ppc64el] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: i2c-tools [arm64] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2c-tools [i386] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [s390x] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: i2c-tools [armhf] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmix [ppc64el] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [i386] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.29.4+17.04]
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [arm64] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [arm64] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmix [amd64] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: i2c-tools [amd64] (bionic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-cron [arm64] (bionic-proposed/none) [1.0.2-1] (no packageset)
<slashd> snapd got approved tinoco ^
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.29.4]
-queuebot:#ubuntu-release- New binary: backblaze-b2 [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [amd64] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [i386] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcleri [i386] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [armhf] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: pg-cron [armhf] (bionic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: construct.legacy [amd64] (bionic-proposed/none) [2.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [s390x] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [armhf] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-fs-listener [armhf] (bionic-proposed/none) [2.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [arm64] (bionic-proposed/none) [0.1.1-1] (no packageset)
<sil2100> Oh, someone approved it
-queuebot:#ubuntu-release- New binary: libcleri [s390x] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmix [i386] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.29.4~14.04]
<sil2100> Makes sense as I didn't see the artful SRU in the queue anymore
-queuebot:#ubuntu-release- New binary: emacs-helm-ag [amd64] (bionic-proposed/none) [0.58-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [amd64] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmix [s390x] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcleri [amd64] (bionic-proposed/none) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [armhf] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-cron [s390x] (bionic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [s390x] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-cron [i386] (bionic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [i386] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-cron [amd64] (bionic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [s390x] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powercap [amd64] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-notiffany [amd64] (bionic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqxp [i386] (bionic-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-airbrussh [amd64] (bionic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmix [arm64] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libftdi1 [arm64] (bionic-proposed/universe) [1.4-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: pmix [armhf] (bionic-proposed/universe) [2.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdancer2-plugin-ajax-perl [amd64] (bionic-proposed/none) [0.300000-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-102.125~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted backblaze-b2 [amd64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted emacs-helm-ag [amd64] (bionic-proposed) [0.58-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [i386] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted construct.legacy [amd64] (bionic-proposed) [2.5.3-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [amd64] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [arm64] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [ppc64el] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [amd64] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [armhf] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [ppc64el] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted libcleri [amd64] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted libcleri [armhf] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted libcleri [ppc64el] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted libdancer2-plugin-ajax-perl [amd64] (bionic-proposed) [0.300000-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [arm64] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [armhf] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [arm64] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [s390x] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted libcleri [i386] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [amd64] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [i386] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [s390x] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted libqxp [arm64] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted libqxp [i386] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted libqxp [s390x] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-fs-listener [s390x] (bionic-proposed) [2.12.0-1]
-queuebot:#ubuntu-release- New: accepted libcleri [arm64] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [armhf] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted libqxp [amd64] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted libqxp [ppc64el] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [arm64] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [i386] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [s390x] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted i2c-tools [i386] (bionic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted libftdi1 [ppc64el] (bionic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [amd64] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [ppc64el] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcleri [s390x] (bionic-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted pg-cron [armhf] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libqxp [armhf] (bionic-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted pmix [arm64] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted pmix [i386] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted pmix [s390x] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted powercap [arm64] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted powercap [i386] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted powercap [s390x] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-notiffany [amd64] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted pmix [amd64] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted pmix [ppc64el] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted powercap [armhf] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-airbrussh [amd64] (bionic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pmix [armhf] (bionic-proposed) [2.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted powercap [ppc64el] (bionic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted powercap [amd64] (bionic-proposed) [0.1.1-1]
<LocutusOfBorg> coreycb, "Resetting proxy settings in tests is bad, and makes ubuntu infra cry" why did you reintroduce it again for python-eventlet? the -3 upload was fine, the failure was a network error, not a misconfiguration in proxy
<coreycb> LocutusOfBorg: james' delta was overwritten by a sync so i was re-enabling that. i included your delta as well but perhaps i shouldn't have?
<LocutusOfBorg> damn, I syncd by loosing the python patch
<LocutusOfBorg> the control file had the changes...
<LocutusOfBorg> mea culpa!
<LocutusOfBorg> I don't understand why enum34-compat.patch is not needed in debian then
<LocutusOfBorg> so, let me reupload without the proxy change, so the delta is reduced to only one patch, and I'll send it to debian
<coreycb> LocutusOfBorg: i'm not sure. i think jamespage submitted that back to debian but it wasn't included.
<coreycb> LocutusOfBorg: ok thanks
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881989
<ubot5> Debian bug 881989 in python-eventlet "python-eventlet: Missing dependency on enum-compat (which is a shim to enum34)" [Normal,Fixed]
<LocutusOfBorg> indeed
<coreycb> LocutusOfBorg: i wonder if they accidentally missed the patch and only updated d/control. i'll check with Ondrej.
<LocutusOfBorg> I'm reopening the bug report
<LocutusOfBorg> with an updated patch
<coreycb> LocutusOfBorg: ok that'll work. thanks.
<LocutusOfBorg> sent
<LocutusOfBorg> better have a public followup from public bug, to avoid the same discussion on next upload :P
<LocutusOfBorg> thanks!
<slangasek> infinity: so, interesting that the arm64 queue didn't seem to drop much since last night... if only we had graphs of these queues ;)  I think we have quota to try to stand up a few more runners, if that hasn't already been done
<slangasek> infinity: and currently we have 20 s390x workers running, but only 16 configured in git... not sure what awayney has in mind there, hmm, but I'll axe the last 4 which should reduce our chances of hitting quota to arm64's detriment
<slangasek> infinity: ok, bumped from 40 to 45 workers now for arm64; assuming there is hardware to back up that quota, maybe that will be enough.  Alternatively, we could disable arm64 in britney again, which would let the currently scheduled tests still run but wouldn't block things yet?
<tsimonq2> Any archive admin around who would be willing to help me with Britney?
<tsimonq2> I don't know if I messed up or Britney did...
<tsimonq2> I have some LXQt stuff synced from Experimental that just isn't migrating. All are valid candidates, and all are completely installable locally
<tsimonq2> Can someone give me a hint here? I'm stuck
<tsimonq2> infinity, slangasek: ^^^
<slangasek> tsimonq2: have you looked at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
<jbicha> slangasek: what are we going to do with s390x autopkgtests that only started failing once we got machine isolation?
<jbicha> examples are cockpit, dahdi-linux, gsequencer, gvfs
<tsimonq2> slangasek: Yes, and the uninstallable arch has seemingly fluctuated, always works on amd64, and I don't see why those are uninstallable
<jbicha> lxcfs
<slangasek> jbicha: I gladly accept MPs against lp:~ubuntu-release/britney/hints-ubuntu/ with force-badtest hints for any packages whose test history shows the failure is present in the release pocket
<jbicha> slangasek: do you want all/s390x for those ones?
<slangasek> jbicha: I prefer pinning to specific package versions and re-reviewing on new uploads
<slangasek> tsimonq2: so the uninstallable arch will fluctuate because it's an arch: all package; I don't know specifically why it's not installable; are there lxqt packages not yet ready to migrate?
<jbicha> maybe lxqt-config (source & binary) needs to be removed first? since the new lxqt packages break/replace it
<tsimonq2> You mean lxqt-common?
<tsimonq2> That might work
<tsimonq2> slangasek: And yeah, half the stack migrated and half didn't, which is the worst case scenario.
<slangasek> it shouldn't be a worst-case scenario if your package dependencies are correct
<slangasek> any problems caused by a half-migrated stack through proposed-migration are also issues for dist upgrades
<tsimonq2> That's where I need to go and talk to Debian, deps were't done right
<slangasek> so the uninstallable package is lxqt; which is from lxqt-metapackages; I don't see how lxqt-config would be related
<tsimonq2> And that's migrated already...
<tsimonq2> Er
<tsimonq2> I *thought* it did
<tsimonq2> ...I still don't see how it would be uninstallable
<tsimonq2> slangasek: either way, lxqt-common was split upstream and should be removed from Bionic.
<tsimonq2> Although I'm not sure if it will make a difference or not...
<tsimonq2> slangasek: To answer your earlier question, as far as I can see, everything should be good to migrate, I just don't get why it hasn't already
<slangasek> tsimonq2: try a test install of lxqt from -proposed; see which dependencies it pulls from -proposed; work out which of these is missing and not migrating?
<slangasek> tsimonq2: alternatively, since lxqt-metapackages makes lxqt uninstallable all by itself, you should be able to pin lxqt-metapackages source and see what it's failing to pull in as a dep
<tsimonq2> slangasek: Sure, I'll give it a try.
<slangasek> (because there are no differences to the Depends: from 19 to 20 except the versioned dep on lxqt-core, which is not uninstallable)
<slangasek> tsimonq2: ah - it is the lxqt-common thing
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [151-1 => 156-1~ubuntu17.10.1] (no packageset)
<slangasek> hmm, I think
<slangasek> triple-checking
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [156-1~ubuntu17.10.1]
<tsimonq2> slangasek: Like I said, needs to be removed anyways, so if that's not the answer, no harm done
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [151-1~ubuntu17.04.1 => 156-1~ubuntu17.04.1] (no packageset)
<slangasek> right, but if it were just that, britney would have no problem resolving it
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [151-1~ubuntu16.04.1 => 156-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [156-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [156-1~ubuntu17.04.1]
<slangasek> ok, I've chased through that dep chain and am back to having no idea
<slangasek> new lxqt-session is needed to drop the dep on lxqt-common, but that's already part of the hint
<tsimonq2> I'm tempted to no-change-rebuild the things but I doubt that will make a difference
<slangasek> it shouldn't make a difference, so please don't
<jbicha> I think it's unusual to use a versioned breaks/replaces (when the broken version doesn't even exist anywhere) so maybe that's what's needs manual hinting
<slangasek> it's unusual and in fact it's incorrect, but britney isn't supposed to care
<tsimonq2> slangasek: Right, not going to do, but it's a passing thought that was worth mentioning imo
<acheronuk> tsimonq2: ask me the others day to have a look, and I had no idea, so the above makes me feel better :P
<acheronuk> *asked me the other day
<tsimonq2> Heh
<jbicha> slangasek: it does increase the uninstallability count though, right? I'm just guessing here
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-102.125~14.04.1]
<slangasek> jbicha: yes, the uninstallable count goes up from 0 to not-0
<slangasek> and it's lxqt that becomes uninstallable, and I also can't work out why
<slangasek> are there any other binaries that are part of the hinted packages which are dropped in -proposed?
<tsimonq2> slangasek: Not that I can see
<bdmurray> slangasek: Could you review my django-tastypie Xenial SRU sometime?
<jbicha> slangasek: your lxqt hint worked :)
<tsimonq2> Oh did it?
<slangasek> tsimonq2, jbicha: yeah, I hinted in the minimal set of packages needed in order for lxqt to be installable, to see what happened; and what happened was that britney shook loose the bug :P
<slangasek> bdmurray: ok
-queuebot:#ubuntu-release- Unapproved: accepted django-tastypie [source] (xenial-proposed) [0.13.3-1~16.04.1]
<bdmurray> slangasek: Thanks
<tsimonq2> slangasek: \o/
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu3.5 => 2.20.7-0ubuntu3.6] (core)
<tsimonq2> slangasek: Yep, I can confirm, the whole LXQt stack is through, thanks!
<tsimonq2> slangasek: Do you think this is preventable in the future or was this Britney being... fun? :)
<slangasek> tsimonq2: I haven't diagnosed why britney didn't get it right on its own; it's also a fluke that I don't think I've seen before, and unlikely to be a good use of anyone's time trying to debug now
<tsimonq2> Alright
#ubuntu-release 2017-11-28
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.13 => 2.20.1-0ubuntu2.14] (core)
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.8 => 2.20.4-0ubuntu4.9] (core)
<slangasek> infinity: found a bottleneck on the bos02 autopkgtest runners; wgrant helped diagnose; I cc:ed you on the RT
-queuebot:#ubuntu-release- New sync: fonts-noto-color-emoji (bionic-proposed/primary) [0~20170913-2]
-queuebot:#ubuntu-release- Unapproved: linux-azure-edge (xenial-updates/universe) [4.13.0-1004.4 => 4.13.0-1003.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure-edge (xenial-updates/universe) [4.13.0.1004.4 => 4.13.0.1003.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure-edge [sync] (xenial-updates) [4.13.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure-edge [sync] (xenial-updates) [4.13.0.1003.3]
-queuebot:#ubuntu-release- New: rejected fonts-noto-color-emoji [source] (bionic-proposed) [0~20170913-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-noto-color-emoji [sync] (bionic-proposed) [0~20170913-2]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [source] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [ppc64el] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [arm64] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [s390x] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [armhf] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [amd64] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qqc2-desktop-style [i386] (bionic-proposed/none) [5.40.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [amd64] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [armhf] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [ppc64el] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [arm64] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [s390x] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qqc2-desktop-style [i386] (bionic-proposed) [5.40.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: fonts-noto-color-emoji [amd64] (bionic-proposed/none) [0~20170913-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [sync] (artful-proposed) [1.169.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-snapdragon [sync] (artful-proposed) [1.3-0ubuntu3~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [sync] (xenial-proposed) [1.157.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-snapdragon [sync] (xenial-proposed) [1.3-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [sync] (zesty-proposed) [1.164.2]
-queuebot:#ubuntu-release- New: accepted fonts-noto-color-emoji [amd64] (bionic-proposed) [0~20170913-2]
<xnox> slangasek, the problem is not that something has regressed in release; it's just we have machine-isolation tests that used to "skip all tests" and resulted in a "passed" rating, now that tests are not skipped it results in "failed" rating. Meaning we have an over-inflated # of passed tests. Is there a hint called "always-failed"?
<xnox> which converts failed to always-failed?
<apw> there is not
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [sync] (trusty-proposed) [1.127.24]
-queuebot:#ubuntu-release- Unapproved: iscsitarget (trusty-proposed/universe) [1.4.20.3+svn499-0ubuntu2.3 => 1.4.20.3+svn499-0ubuntu2.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (artful-proposed/main) [1:1.6.1-2 => 1:1.6.1-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1009.10] (no packageset)
<ginggs> xnox: see LP: #1688516
<ubot5> Launchpad bug 1688516 in Auto Package Testing "No way to mark a test as 'accepted regression'" [Undecided,New] https://launchpad.net/bugs/1688516
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1009.10]
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.1 => 0.32~16.04.2] (no packageset)
<cyphermox> ^ I forgot -v for that nplan upload to xenial; I will upload a new one.
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.1 => 0.32~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ppc64-diag (xenial-proposed/universe) [2.7.4-1~16.04 => 2.7.4-2~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: gnocchi [amd64] (bionic-proposed/universe) [4.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [ppc64el] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [ppc64el] (bionic-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.2]
-queuebot:#ubuntu-release- New binary: libcryptx-perl [s390x] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ppc64-diag (trusty-proposed/universe) [2.7.4-1~14.04 => 2.7.4-2~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [s390x] (bionic-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [armhf] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [arm64] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ms [amd64] (bionic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: adlibtracker2 [i386] (bionic-proposed/none) [2.4.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblocale-codes-perl [amd64] (bionic-proposed/none) [3.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [amd64] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cardo [amd64] (bionic-proposed/none) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [i386] (bionic-proposed/none) [0.054-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [amd64] (bionic-proposed/none) [0.3.2-1] (no packageset)
<wxl> infinity et al. tsimonq2 changed the lubuntu seed (https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1691) but it seems that bionic at least within the past two days fails to install the packages for UEFI booting. any idea why?
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [i386] (bionic-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (bionic-proposed/universe) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [armhf] (bionic-proposed/none) [0.3.2-1] (no packageset)
<oSoMoN> hi release team!
<oSoMoN> the i386 autopkgtest regression for libreoffice in bionic-proposed is the infamous x86 java kernel issue, it is fixed in openjdk 9 but tests currently run with 8, which is the default if I'm not mistaken
<oSoMoN> can we please ignore the test failure to allow LO to migrate to the release pocket?
<slangasek> oSoMoN: it's not infamous to me; is there a bug number for this?
<cjwatson> https://lwn.net/Articles/727703/ is an outline of it (I know that's not what you asked)
<slangasek> more relevant is the history on http://autopkgtest.ubuntu.com/packages/libr/libreoffice/bionic/i386 and the existing hint from laney; yes, I'll rev it
<slangasek> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772
<ubot5> Launchpad bug 1699772 in linux (Ubuntu) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,Confirmed]
<slangasek> and there's the bug ;)
<oSoMoN> that's the one indeed
<oSoMoN> slangasek, sorry for not providing the link in the first place
-queuebot:#ubuntu-release- Unapproved: ceilometer (artful-proposed/main) [1:9.0.1-0ubuntu1 => 1:9.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (artful-proposed/main) [1:9.0.0-0ubuntu1 => 1:9.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (artful-proposed/main) [2:11.0.0-0ubuntu2 => 2:11.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (artful-proposed/main) [3:12.0.0-0ubuntu2.2 => 3:12.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (artful-proposed/universe) [2:11.0.0-0ubuntu1 => 2:11.0.2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: nova (artful-proposed/main) [2:16.0.1-0ubuntu1 => 2:16.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.1-0ubuntu1 => 2:11.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.1-0ubuntu1 => 2:11.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: compiz (xenial-proposed/main) [1:0.9.12.2+16.04.20160823-0ubuntu1 => 1:0.9.12.3+16.04.20171116-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (xenial-proposed/main) [14.04+16.04.20161024-0ubuntu1 => 14.04+16.04.20171116-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity (xenial-proposed/main) [7.4.0+16.04.20160906-0ubuntu1 => 7.4.5+16.04.20171116] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nux (xenial-proposed/main) [4.0.8+16.04.20160705-0ubuntu1 => 4.0.8+16.04.20170816-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (xenial-proposed/main) [15.04.0+16.04.20170214-0ubuntu2 => 15.04.0+16.04.20171116-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1]
<infinity> bdmurray: That apport SRU is missing an artful upload.
<infinity> bdmurray: It looks like 0ubuntu3.2 in artful got superseded by security updates and lost in the wind?
<bdmurray> infinity: yes, that's correct.
<infinity> bdmurray: Based on missing versions in the changelog, whatever 3.3 was also got lost.
<infinity> Or maybe that was just a bad version in the security PPA or something.
<infinity> LP doesn't know about it.
<infinity> bdmurray: Anyhow, want to give me a 3.6 with 3.2 reapplied?
<infinity> http://launchpadlibrarian.net/345016954/apport_2.20.7-0ubuntu3.1_2.20.7-0ubuntu3.2.diff.gz
<bdmurray> infinity: Why? to make the diff cleaner?
<infinity> bdmurray: To make artful have the fix?
<bdmurray> infinity: Oh, okay then. ;-)
<infinity> bdmurray: Oh, I don't mean I need 3.2 to reappear in the changelog.  I mean I need the fix to reappear in a 3.6 upload. :P
<bdmurray> infinity: It show up in my local debdiff
<bdmurray> infinity: And downloading the 3.5 dsc and 3.6 dsc files I see it. The LP generated diff is from 3.2 so that's probably why it doesn't appear.
<infinity> bdmurray: Are you implying there is a 3.6 somewhere?
<infinity> OH I'M BLIND.
<bdmurray> infinity: Yes, and that the generated diff from LP is goofy
<infinity> bdmurray: I legit didn't see it in the queue.
<infinity> bdmurray: Ignore me. :P
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.14]
-queuebot:#ubuntu-release- New binary: libcryptx-perl [ppc64el] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4.9]
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [ppc64el] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (artful-proposed) [2.20.7-0ubuntu3.6]
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [amd64] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [i386] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [s390x] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [arm64] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [arm64] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [s390x] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dde-qt-dbus-factory [armhf] (bionic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [armhf] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [i386] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcryptx-perl [amd64] (bionic-proposed/universe) [0.055-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [amd64] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [armhf] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [ppc64el] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [arm64] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [s390x] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [i386] (bionic-proposed) [0.055-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [amd64] (bionic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [i386] (bionic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [s390x] (bionic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [arm64] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [i386] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [s390x] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [armhf] (bionic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [amd64] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [ppc64el] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [ppc64el] (bionic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted dde-qt-dbus-factory [armhf] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [amd64] (bionic-proposed) [0.054-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [i386] (bionic-proposed) [0.054-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [armhf] (bionic-proposed) [0.054-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [ppc64el] (bionic-proposed) [0.054-1]
#ubuntu-release 2017-11-29
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [arm64] (bionic-proposed) [0.054-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libcryptx-perl [s390x] (bionic-proposed) [0.054-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (bionic-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cardo [amd64] (bionic-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted liblocale-codes-perl [amd64] (bionic-proposed) [3.55-1]
-queuebot:#ubuntu-release- New: accepted gnocchi [amd64] (bionic-proposed) [4.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-ms [amd64] (bionic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted adlibtracker2 [i386] (bionic-proposed) [2.4.23-1]
-queuebot:#ubuntu-release- New binary: scalapack [ppc64el] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: scalapack [i386] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted scalapack [i386] (bionic-proposed) [2.0.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted scalapack [ppc64el] (bionic-proposed) [2.0.2-3ubuntu1]
-queuebot:#ubuntu-release- New binary: scalapack [amd64] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: scalapack [s390x] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted scalapack [amd64] (bionic-proposed) [2.0.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted scalapack [s390x] (bionic-proposed) [2.0.2-3ubuntu1]
<tsimonq2> slangasek: Could you please review this (this is similar to v5 stuff, which is why I ask) to make sure I did things right? https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+sourcepub/8528605/+listing-archive-extra
<tsimonq2> Can someone please kick nodejs into bionic-release? The three autopkgtests that fail are all bad, I just verified all three against themselves: https://autopkgtest.ubuntu.com/packages/node-chokidar/bionic/s390x https://autopkgtest.ubuntu.com/packages/node-platform/bionic/s390x https://autopkgtest.ubuntu.com/packages/node-yargs/bionic/armhf
-queuebot:#ubuntu-release- New binary: qhull [i386] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qhull [s390x] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qhull [ppc64el] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qhull [amd64] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qhull [armhf] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qhull [arm64] (bionic-proposed/universe) [2015.2-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: r-cran-drr [amd64] (bionic-proposed/none) [0.0.2-1] (no packageset)
<infinity> stgraber: Feel like investigating and fixing the lxcfs autopkgtest failures on s390x?  I'm going through a list of "stuff that fails now that s390x provides isolation-machine", but I don't think "just ignore it" is the right answer for lxc stuff. :P
<slangasek> tsimonq2: +1 on the opencsg revert
<slangasek> tsimonq2: (I've only looked at the archive state to confirm that a revert + provides is sane; I haven't double-checked the debian/control of the package you uploaded there)
<slangasek> infinity: good news, probably?  I think at this rate arm64 is going to catch up with the backlog tonight/tomorrow
<infinity> slangasek: Which means I can SRU glibc!
<slangasek> was that the plan?: )
<infinity> (And we can use that as a reasonable benchmark for which queues suck the least)
<infinity> slangasek: There's a pending glibc SRU, yes, but I've been holding off for the queues to empty.
<slangasek> k
<infinity> It should also double as a painful way for us to reset large chunks of the s390x baseline.
<infinity> Which we might have to do with manually editing state or something, cause I don't want to carry a bunch of "this now fails with isolate-machine, lolz" hints forever.
<slangasek> hey, there's still that proposed change to britney that would magically fix this for all regressions in release pocket
<infinity> The "testbed is now better and your test sucks" case feels like it could be handled more elegantly in a few places.
<infinity> I mean, we *have* the info to know that the test was previously skipped due to testbed restrictions, thus never actually "passed".
<infinity> But we're taking pass/fail at a lower granularity.
<slangasek> right
<infinity> But rather than rewriting everything to do test-level ganularity (which has other issues, like tests disappearing), this feels like perhaps the domain of a one-time clean-up script.
<infinity> Check old passes, record skips, check new failures, compare, if same, twiddle old passes to fail.
<infinity> Or some such.
<slangasek> infinity: which would mean twiddling the statuses in swift aiui
<infinity> slangasek: Would it?  Does britney not have its own internal idea of the current state?  It can't possibly be hitting all the history in autopkgtest every time until it walks back to a success.
<infinity> (If it is, ew?)
<slangasek> infinity: if it didn't, it would overlook new passes of the test that happened after the triggering package was uploaded; and I know in fact it doesn't, even though sometimes it would be more sensible if it did
<infinity> The britney<->debci interface probably needs a complete rewrite.  I'm not volunteering. :/
<infinity> The largest portion of britney runs is also the 8 billion http requests to debci now.
<infinity> There should surely be a way to consolidate that into one range request or something more clever.
<slangasek> perhaps britney should just pull down the sqlite database
<infinity> slangasek: Other than the part where I suspect sqlite databases are arch-specific, that's not the dumbest dumb idea I've ever heard.
<slangasek> arch-specific meaning on-disk format?
<infinity> (If they're not arch-specific, they would be missing a ton of low-hanging optimisations in their binary format, and I don't think the sqlite upstream are that silly)
<infinity> slangasek: Yeah.
<slangasek> not sure
<slangasek> I thought they were meant to be portable
<infinity> slangasek: And, sure, we happen to be amd64 in both places, but that's not a thing I'd like to rely on being true. :P
<infinity> If they're portable, I'd be shocked.
<infinity> Since portable binary formats and high speed DB access don't tend to be goals you can easily achieve in parallel.
<infinity> But ICBW.
<stgraber> infinity: out this week but I'll try to remember to take a look next week
<slangasek> doko: should /usr/share/python/dist_fallback in python be synced with /usr/share/dh-python/dist/cpython2_fallback in dh-python? or is a package like 'legit' which calls dh --with python2 doing something wrong?
<doko> slangasek: I would keep it like that. packages are supposed to b-d on dh-python in any case. is there something broken?
<doko> in bionic, ubuntu-touch.bionic still exists. Is this intended?
<doko> I mean, in the bionic seeds
<slangasek> doko: how does build-depending on dh-python change the behavior?
<slangasek> dh-python is installed; but /usr/bin/dh_python2 is owned by python
<slangasek> oh seriously
<slangasek> adding the build-dependency is enough to change the output?
<doko> dh_python2 is diverted by dh-python
<slangasek> doko: I think ubuntu-touch.bionic should be removed
<doko> slangasek: can you do that, or should I file a bug report for that?
<doko> the fallback: I'll update python-defaults, looks safe to do
-queuebot:#ubuntu-release- New: accepted r-cran-drr [amd64] (bionic-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted qhull [amd64] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New: accepted qhull [armhf] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New: accepted qhull [ppc64el] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New: accepted qhull [arm64] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New: accepted qhull [s390x] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New: accepted qhull [i386] (bionic-proposed) [2015.2-3]
-queuebot:#ubuntu-release- New binary: pyroute2 [amd64] (bionic-proposed/main) [0.4.21-0.1ubuntu2] (ubuntu-server)
<ginggs> what to do with r-cran-openssl and r-cran-future?  the tests pass locally and in debian https://ci.debian.net/packages/r/r-cran-openssl/unstable/amd64/ https://ci.debian.net/packages/r/r-cran-future/unstable/amd64/
<apw> ginggs, how do the fail in ubuntu adt ?
<ginggs> apw: r-cran-openssl 'Failed to connect to 216.58.204.83 on port 443'
<apw> so that sounds like it is trying to connect to random things ...
<ginggs> apw: r-cran-future passes on armhf and s390x only
<ginggs> apw: it's trying to download a cert from google
<apw> lhr25s13-in-f83.1e100.net. sounds like google indeed
<apw> well thats not a very sensible test why does it not include the cert
<apw> expecting to be able to connect randomly to the internet is not a reasonable thing for a test suite to do
<ginggs> apw: i thought that network connections are allowed for autopkgtests, but not for buildds
<apw> i thought you had access to squid.internal in there, but i am not sure direct connections are allowed
<apw> ginggs, yeah i am reminded we had the same problem for docker in ADT we had to use the proxy
<cjwatson> doko,slangasek: I've removed (I think) all references to ubuntu-touch.bionic and marked the branch as abandoned in LP
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-136.185] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-136.185]
<sergiusens> slangasek is there a configureable timeout for autopkgtests? I get this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/snapcraft/20171124_001006_97bdb@/log.gz (also on zesty) (search for the third match of integrationtests-plugins for a quick find)
<jbicha> infinity: here are more newly-failing s390x tests you can copy & paste: https://code.launchpad.net/~jbicha/britney/hints-skip-s390x-tests/+merge/334334
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.4 => 2.29.4.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.4+17.10 => 2.29.4.1+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.29.4+17.04 => 2.29.4.1+17.04] (desktop-core, ubuntu-server)
 * apw looks at snapd
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.29.4.1+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.29.4.1+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.29.4.1]
<slashd> tinoco ^
<slangasek> sergiusens: there is an option to configure some tests as 'long' tests.  I don't really like this as a solution, raising the timeout raises it for each test within a package's test suite which is already at 2h46m, when I think the direction we /should/ be trying to move is to have finer granularity (of timeouts and test results) within packages.  It's also potentially abusive of the
<slangasek> infrastructure (and not actually helpful to the upstream project) if it allows the tests to grow unbounded
<slangasek> sergiusens: I will add snapcraft to the 'long' test list on armhf only, if that works?
<sergiusens> slangasek yes please, only armhf
<sergiusens> slangasek we are slowly (pun) moving to making these test leaner as well
<sergiusens> it got slower because we added more tests (all the new  ROS ones)
<slangasek> sure
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (artful-proposed) [1.2+17.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (xenial-proposed) [1.2+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (zesty-proposed) [1.2+17.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12.1 => 234-2ubuntu12.2] (core)
<dannf> bdmurray: hi - would you mind cancelling qemu/zesty-proposed? (see comments #33/#35 in LP: #1710019)
<ubot5> Launchpad bug 1710019 in linux (Ubuntu Zesty) "support GICv3 ITS save/restore & migration" [Undecided,In progress] https://launchpad.net/bugs/1710019
-queuebot:#ubuntu-release- Unapproved: ipxe (zesty-proposed/main) [1.0.0+git-20150424.a25a16d-1ubuntu2.1 => 1.0.0+git-20150424.a25a16d-1ubuntu2.2] (ubuntu-desktop, ubuntu-server)
<sergiusens> thanks slangasek
-queuebot:#ubuntu-release- Unapproved: accepted ipxe [source] (zesty-proposed) [1.0.0+git-20150424.a25a16d-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.1+16.04ubuntu4 => 1.3+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (zesty-proposed/universe) [1.1+17.04ubuntu3 => 1.3+17.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (artful-proposed/main) [1.1+17.10ubuntu5 => 1.3+17.10ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New sync: drkonqi (bionic-proposed/primary) [5.11.4-0ubuntu1]
-queuebot:#ubuntu-release- New sync: plasma-vault (bionic-proposed/primary) [5.11.4-0ubuntu1]
<slangasek> infinity: in answer to the question of which archs are slowest... the answer is definitely bos02 still.  queues are growing there in response to uploads even as the other archs have zeroed out
<tsimonq2> slangasek: If you're around, any chance you could review drkonqi and plasma-vault? (or any other AA)
<tsimonq2> It shows up as a sync but it's from the CI Train
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.2]
<wxl> slangasek: tsimonq2 supposedly fixed the lubuntu bionic seed so that uefi packages would get pulled in, but it doesn't seem that's the case. any ideas?
<slangasek> wxl: what was fixed, and what packages are you expecting that aren't there currently?
<slangasek> tsimonq2: source new processing is not currently near the top of my list.  Is there a reason these packages aren't going via Debian?
<tsimonq2> slangasek: These are Kubuntu packages and needed for Plasma, so I guess the same reason why Kubuntu doesn't do more in Debian.
<tsimonq2> We don't have team members besides myself participating in the Debian side as well
<wxl> slangasek: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1691
<slangasek> I'm not clear on what that reason is ;)  we also have various KDE packages in Ubuntu that are removed from Debian as obsolete but have different Ubuntu-specific versions in Ubuntu, which makes it awkward to process removals
<wxl> tsimonq2 do you remember the missing packages for UEFI?
<tsimonq2> wxl: not offhand, see ship-live-share
<cyphermox> what do you know, that does explain the failures.
<tsimonq2> slangasek: It's a historical thing, really. We've always been a bit faster and we have different procedures.
<wxl> slangasek: i THINK it's shim-signed and grub-efi-amd64-bin that's missing
<tsimonq2> slangasek: I don't really know how to explain it otherwise except that "It's Always Been Thay Way" and there's a few blockers from us being more in-sync
<slangasek> tsimonq2: yeah, it hasn't always been that way
<slangasek> that's the thing :)
<tsimonq2> (well, not always, but for the past 3 years at least)
<slangasek> wxl: so, which image are you looking at that you see these packages missing from?
<slangasek> wxl: lubuntu/daily-live/current/bionic-desktop-amd64.list shows me grub-efi-amd64-bin and shim-signed
<tsimonq2> And that's the weird part, because those aren't in manifest
<tsimonq2> (or are they?)
<slangasek> that's not weird at all
<slangasek> you added them to a 'ship' seed
<tsimonq2> OH
<tsimonq2> Right
<tsimonq2> My bad :)
<wxl> :/
<slangasek> that puts them in the package pool, which is in .list; it doesn't install them in the livefs, which is what .manifest lists
<tsimonq2> Anyways, we've still had to install the packages on live ISOs for that stuff to work, slangasek
<cyphermox> they couldn't be in the manifest anyway, coinstalled with grub-pc...
<slangasek> you're going to have to elaborate
<slangasek> installing them in the live environment does nothing for you
<slangasek> selecting them for installation onto the target disk is explicitly part of what the installer is supposed to do
<wxl> actually i don't care about the live environment. it's the fact that the installer can't install them
<cyphermox> tsimonq2: with r1691 landed on 11-20; this should be re-tested, I think
<tsimonq2> cyphermox: Ok
<cyphermox> now, given that they were added to ship-live-share, and that wasn't the case before, I think we were looking at "efi doesn't install properly" but of a different form than it was before
<cyphermox> ie. it doesn't install correctly if you're offline, but does if you're online?
<cyphermox> that's about the only thing adding these to ship-* would change, I think
<wxl> actually it didn't install correctly while being online
<wxl> but it was originally brought to out attention with an offline install
<cyphermox> the original bug looks online
<cyphermox> but then you also had a difference in what was in the manifest, one particular package that was causing a conflict, IIRC
 * cyphermox updates his copy of lubuntu-daily-live
<wxl> i'll try again in a moment. i'm installing a zesty system now to try to troubleshoot some stupid node module problem i'm having :eyeroll:
<tsimonq2> While we're at it...
<tsimonq2> Root on XFS doesn't seem to be working either :P
<tsimonq2> (this, and LVM and UEFI not working, has sort of surprised me in that nobody tested these cases and made a big enough deal about them before release, something that we *need* to change as the Lubuntu team)
<wxl> yeah well we're kind of unique because i think everyone else just assumes EFI
<wxl> where as in general, i think we assume NOT UEFI
<wxl> so it's like we need to have special testcases just for UEFI
<wxl> which sucks, because that doubles our workload as far as QA is concerned
<cyphermox> wxl: no; nothing assumes UEFI; you just get a different bootloader depending on how you boot the image -- that's true for all our images AFAIK
<wxl> cyphermox: so no one is explicitly testing both UEFI and non-UEFI installs?
<jbicha> wxl: VirtualBox is non-UEFI by default and it is used a lot by testers
<cyphermox> everyone is testing that both UEFI and non-UEFI installs; but different individuals test different things.
<wxl> VirtualBox and KVM can both do UEFI boot
<wxl> but yeah i guess what i'm saying is we need to explicitly have testcases if we want to assume adequate coverage
<slangasek> infinity: the reason autopkgtest queues are growing is bos02 fell over again.
<wxl> this is mostly a lubuntu issue because of no-follow-recommends (:eyeroll: again) but it's not to say that SOMETHING couldn't happen to affect other flavors
<cyphermox> wxl: indeed.
<wxl> i do have it on my list to write some testcases
<wxl> but it's basically going to copy the old testcases but request a UEFI boot
<wxl> both sets of testcases will need to have more instruction about how to twiddle UEFI and non-UEFI on VM and otherwise
<wxl> maybe i should make a bug about this against ubuntu-manual-tests and we can put our heads together to resolve it
<tsimonq2> wxl: Speaking of no-follow-recommends...
 * wxl harumphs
<tsimonq2> wxl: I think we should just *try* disabling it in Lubuntu Next
<tsimonq2> Just for a little test.
<tsimonq2> See how much the ISO size increases.
<wxl> i'm game
<tsimonq2> Alright, I'll make the change after dinner.
<wxl> please report to the list
<tsimonq2> I will.
<LocutusOfBorg> sigh perl
<chrisccoulson> hi, can someone please copy the rustc binaries (1.21.0+dfsg1+llvm-0ubuntu5) from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/ to bionic-proposed so that I can get firefox built there?
<LocutusOfBorg> chrisccoulson, source+binaries, correct?
<chrisccoulson> yeah
<LocutusOfBorg> ./copy-package --from=ppa:ubuntu-mozilla-security/ubuntu/rust-updates --from-suite=bionic --to=ubuntu --to-suite=bionic-proposed --include-binaries rustc
<LocutusOfBorg> y, 50 copies requested.
<LocutusOfBorg> it will be available on next publisher run
<chrisccoulson> LocutusOfBorg, thanks
<LocutusOfBorg> you are welcome, I'm not sure why you can't do it by yourself, but you might have your good reasons :)
<chrisccoulson> oh, I didn't know that I could
<LocutusOfBorg> (copy-package is part of ubuntu-release-tools)
<LocutusOfBorg> assuming you have upload rights for the package, https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk
<LocutusOfBorg> the command is the one above ^^
<sergiusens> slangasek am I good to retrigger the armhf tests that I mentioned earlier or will you get back to me on that long/slow test marker change?
<tsimonq2> LocutusOfBorg: Why do you copy to bionic-proposed? Copying to bionic should work fine, no?
<cjwatson> No, you must copy to bionic-proposed.
<cjwatson> The copier doesn't have the same sugar that uploads do.
<cjwatson> Not least because the process of promoting from bionic-proposed to bionic uses copies, and it was very unclear what that would do if there were an automatic mapping thing in its way.
<tsimonq2> cyphermox: Oh, TIL, thank you
<wxl> just came back. any luck with that new lubuntu daily, cyphermox
-queuebot:#ubuntu-release- New binary: opencsg [s390x] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencsg [amd64] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencsg [ppc64el] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencsg [i386] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencsg [arm64] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencsg [armhf] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted opencsg [amd64] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opencsg [armhf] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opencsg [ppc64el] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opencsg [arm64] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opencsg [s390x] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted opencsg [i386] (bionic-proposed) [1.4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pyroute2 [amd64] (bionic-proposed) [0.4.21-0.1ubuntu2]
#ubuntu-release 2017-11-30
<slangasek> sergiusens: oh - I made the long_test change, you can go ahead and trigger it
-queuebot:#ubuntu-release- Unapproved: accepted corebird [source] (artful-proposed) [1.6-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected golang-petname [source] (artful-proposed) [2.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (artful-proposed) [12.2.1-0ubuntu0.17.10.1]
<cyphermox> wxl: I'm looking right now, I had to go offline for a bit to cook dinner
<cyphermox> lubuntu-next I'll blame the fact that it's Qt as to why it doesn't start to ubiquity-dm. I expect some kind of thing missing in casper
<tsimonq2> cyphermox: Where's the code that starts ubiquity-dm?
<cyphermox> tsimonq2: lp:casper
<tsimonq2> cyphermox: gracias
<doko> slangasek: you promoted vmdk-stream-converter without having a bug subscriber :-/
<doko> ahh, no, that was somebody else. reopened now
<slangasek> doko: I only promoted it in SRU; someone should've handled the bug subscriber before promoting it in devel?
<slangasek> doko: right, as you say
-queuebot:#ubuntu-release- New binary: mypy [amd64] (bionic-proposed/universe) [0.540-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted mypy [amd64] (bionic-proposed) [0.540-2]
-queuebot:#ubuntu-release- New: accepted drkonqi [sync] (bionic-proposed) [5.11.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-vault [sync] (bionic-proposed) [5.11.4-0ubuntu1]
<tsimonq2> Thanks to whoever reviewed those :)
<doko> chrisccoulson: what's up with rustc on s390x?
<cpaelzer> hi, dannf already asked about it yesterday, but it didn't happen yet so I'll ask again
<cpaelzer> could someone cancel https://launchpad.net/ubuntu/+source/qemu/1:2.8+dfsg-3ubuntu2.8 from zesty-proposed ?
<cpaelzer> discussion / reasons in bug 1710019 & 1734326
<ubot5> bug 1710019 in linux (Ubuntu Zesty) "support GICv3 ITS save/restore & migration" [Undecided,In progress] https://launchpad.net/bugs/1710019
<cpaelzer> thanks a lot in advance
<LocutusOfBorg> doko, needs bootstrap maybe?
 * LocutusOfBorg has a perl sync ready in silo :p
<cpaelzer> asking again, could somebody cancel https://launchpad.net/ubuntu/+source/qemu/1:2.8+dfsg-3ubuntu2.8 from z-p ?
<cpaelzer> reasons are outline in bugs 1710019 / 1734326
<ubot5> bug 1710019 in linux (Ubuntu Zesty) "support GICv3 ITS save/restore & migration" [Undecided,In progress] https://launchpad.net/bugs/1710019
<apw> cpaelzer, you want the zesty-proposed qemu SRU package removed, correct ?
<cpaelzer> apw: correct
<cpaelzer> kernel team found a regression
<cpaelzer> and dannf and I agreed to remove it for now
<apw> cpaelzer, gone
<cpaelzer> thank you apw
<LocutusOfBorg> silo is not triggering tests for arm64
<chrisccoulson> doko, rustc doesn't build on s390x because cargo is busted there
<sil2100> bdmurray: hey! Once you're up and doing SRU stuff, could you release livecd-rootfs for zesty as well? I have commented on the s390x failure, it seems to be 'expected' to fail
<sil2100> bdmurray: (this test case is broken on s390x)
<sil2100> bdmurray: I'll try to hint it maybe, but anyway, would like someone to release the SRU
<infinity> sil2100: Would be nice if xnox SRUed the nullglob fix to systemd back to zesty and artful, so that test was useful (and I expect the bug shows places other than just our testbeds).
<infinity> xnox_: ^
<xnox> https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?h=ubuntu-bionic&id=666a50780fe1265ecd932aa8c42f36658e121f0f yes it would be useful to fix that.
<infinity> sil2100: Hinted for now.
<sil2100> infinity: thanks
<sil2100> :)
-queuebot:#ubuntu-release- Unapproved: debian-installer-utils (xenial-proposed/main) [1.113ubuntu1 => 1.113ubuntu1.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer-utils (zesty-proposed/main) [1.113ubuntu1 => 1.113ubuntu1.17.04.1] (core)
<sergiusens> slangasek so I reran the armhf tests and the integrationtests-plugins suite didn't time out this time but the integrationtests-general one (which passed on the previous run) failed with "Temporary failure in name resolution". Did you ever have a chance to look into that?
<sergiusens> this is only really a problem with armhf
<LocutusOfBorg> firejail test fails on s390x because thunderbird is not installable/built there anymore
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/f/firejail/bionic/s390x
<LocutusOfBorg> can anybody please hint?
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.6 (artful-proposed/universe) [5.6.34-26.19-0ubuntu4 => 5.6.34-26.19-0ubuntu4.17.10.1] (no packageset)
<slangasek> sergiusens: I never made any headway on the armhf dns timeouts, no :/
<sergiusens> slangasek considering that and to not waste resources, can we consider the criteria for xenial and zesty to be good and promote to xenial and zesty-updates ?
<sergiusens> fwiw, this is my baseline to know I didn't mess up anything big with the libc6 work going on now
<sergiusens> and reverse depends adt triggers that depend on snapcraft should pass (upstream changed behavior and our tests currently fail if reran)
<sergiusens> which is unfortunate as it is a dependency we cannot pin
<slangasek> sergiusens: I don't see any reason to "save resources" and not get a clean test result
<sergiusens> slangasek ok, I'll retrigger
-queuebot:#ubuntu-release- New binary: caja-eiciel [ppc64el] (bionic-proposed/none) [1.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-eiciel [s390x] (bionic-proposed/none) [1.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-eiciel [amd64] (bionic-proposed/none) [1.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-eiciel [i386] (bionic-proposed/none) [1.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-eiciel [arm64] (bionic-proposed/none) [1.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-eiciel [armhf] (bionic-proposed/universe) [1.18.1-1] (no packageset)
<Trevinho> bdmurray: hey, could you please approve the packages in queue for this SRU https://bileto.ubuntu.com/#/ticket/2841 ?
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (artful-proposed) [2.3.0-6434-gd354690-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (artful-proposed) [1:9.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (artful-proposed) [1:9.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (artful-proposed) [2:11.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (artful-proposed) [3:12.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate-signed [source] (artful-proposed) [1.14.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (artful-proposed) [2:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (artful-proposed) [2:16.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (artful-proposed) [234-2ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.29.4~14.04 => 2.29.4.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.4.1+17.10 => 2.29.4.2+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.29.4.1+17.04 => 2.29.4.2+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.4.1 => 2.29.4.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (zesty-proposed) [2.3.0-6434-gd354690-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.3.0-6434-gd354690-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (zesty-proposed) [1.18.1-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted apt-xapian-index [source] (zesty-proposed) [0.47ubuntu13.1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer-utils [source] (zesty-proposed) [1.113ubuntu1.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (artful-proposed) [384.90-0ubuntu3.17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer-utils [source] (xenial-proposed) [1.113ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (zesty-proposed) [384.90-0ubuntu0.17.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (xenial-proposed) [384.90-0ubuntu0.16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted ppc64-diag [source] (xenial-proposed) [2.7.4-2~16.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.29.4.2+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.29.4.2+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.29.4.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.29.4.2~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted ppc64-diag [source] (trusty-proposed) [2.7.4-2~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (xenial-proposed) [2.5.4-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (xenial-proposed) [7.0.25-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted yubioath-desktop [source] (xenial-proposed) [2.3.0-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (xenial-proposed) [5.0.40-dfsg-0ubuntu1.16.04.1~16.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (zesty-proposed) [2.29-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (xenial-proposed) [4.0.8+16.04.20170816-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20171116-0ubuntu1]
<jbicha> slangasek: https://code.launchpad.net/~jbicha/britney/hints-skip-s390x-tests/+merge/334334
<jbicha> some of those have already been applied now in yours or infinity's hints
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (xenial-proposed) [7.4.5+16.04.20171116]
<bdmurray> How would I double check the Launchpad-Bugs-Fixed for unity-control-center in the xenial -proposed queue?
<apw> bdmurray, do you not get the changes file from a queue fetch ?
<bdmurray> apw: its a sync and using sru-review I see less tabs for bugs than are listed in the changelog.
<apw> Launchpad-Bugs-Fixed: 1716359
<apw> from the .changes in a queue fetch ...
<bdmurray> "in a queue fetch"?
<apw> bdmurray, queue command in ubuntu-archive-tools, queue fetch -Q unapproved -s xenial-proposed --source unity-control-center
<apw> gets you the .dsc etc, but, sync's suck utterly
-queuebot:#ubuntu-release- Unapproved: rejected unity-control-center [sync] (xenial-proposed) [15.04.0+16.04.20171116-0ubuntu1]
<wxl> hey i accidentially dput git when i meant it to go to a ppa so smack that down from me if you ssee it
<slangasek> wxl: if it was uploaded to devel it'll almost certainly hit the archive before we can intercept
 * wxl facepalms
<mwhudson> wxl: can i interest you in https://github.com/mwhudson/dput-wrap
<wxl> ooh nice thanks mwhudson
<Trevinho> bdmurray: thanks...
<Trevinho> bdmurray: as for u-c-c what's the issue?
<bdmurray> Trevinho: I had to reject that one because the Launchpad-Bugs-Fixed didn't include all the bugs in the changelog. Only the one from the last changelog entry which was fixed earlier.
<Trevinho> bdmurray: oh, let me see
<bdmurray> I think if you reordered the changelog entries it'd work out fine.
<Trevinho> bdmurray: oh, I see...
<Trevinho> weird, since the MP for it was https://code.launchpad.net/~3v1n0/unity-control-center/grouped-compiz-gsettings-support-x/+merge/326789
<Trevinho> bdmurray: should I rebuild the package and see?
<bdmurray> Trevinho: YOu should rebuild it on 15.04.0+16.04.20170214-0ubuntu2
<bdmurray> The one in -updates
<Trevinho> bdmurray: I've been using bileto so it generally does it, but let's try again
<tsimonq2> slangasek: wxl has no upload access, don't worry :P
<bdmurray> That version may have been in -proposed when you built your SRU
<slangasek> tsimonq2: oh, well in that case ;)
<Trevinho> bdmurray: mh, yeah it could be...
-queuebot:#ubuntu-release- Unapproved: accepted compiz [sync] (xenial-proposed) [1:0.9.12.3+16.04.20171116-0ubuntu1]
<Trevinho> bdmurray: ok, i'm rebuilding the packages... once published i'll ping you again, thanks.
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.2-0ubuntu1 => 2:11.0.2-0ubuntu1.1] (openstack, ubuntu-server)
<slangasek> jbicha: merged, dropping the ones that are already obsolete or already hinted elsewhere; please review that I didn't miss anything
<slangasek> sergiusens: so a pysha3 update is stuck in bionic-proposed because snapcraft depends on python3-pysha3, and the package has been renamed to python3-sha3.  Should I file a bug on snapcraft to get this fixed?
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1.1]
#ubuntu-release 2017-12-01
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (xenial-proposed/restricted) [340.102-0ubuntu0.16.04.2 => 340.104-0ubuntu0.16.04.1] (ubuntu-desktop)
<slangasek> so, arm64 in bos02 is not on par w/ ppc64el as it works through the backlog, but it is churning through faster than armhf
-queuebot:#ubuntu-release- New binary: ntfs-3g [ppc64el] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [s390x] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [arm64] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: cgal [ppc64el] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ntfs-3g [armhf] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: cgal [s390x] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [armhf] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [arm64] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted caja-eiciel [amd64] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New: accepted caja-eiciel [armhf] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New: accepted caja-eiciel [ppc64el] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New: accepted caja-eiciel [arm64] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New: accepted caja-eiciel [s390x] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New: accepted caja-eiciel [i386] (bionic-proposed) [1.18.1-1]
-queuebot:#ubuntu-release- New binary: ntfs-3g [amd64] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [i386] (bionic-proposed/main) [1:2017.3.23-2] (core)
-queuebot:#ubuntu-release- New binary: cgal [i386] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ntfs-3g [amd64] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [armhf] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [ppc64el] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [arm64] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [s390x] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [i386] (bionic-proposed) [1:2017.3.23-2]
-queuebot:#ubuntu-release- New binary: cgal [amd64] (bionic-proposed/universe) [4.11-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cgal [amd64] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New: accepted cgal [armhf] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New: accepted cgal [ppc64el] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New: accepted cgal [arm64] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New: accepted cgal [s390x] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New: accepted cgal [i386] (bionic-proposed) [4.11-2]
-queuebot:#ubuntu-release- New binary: colorclass [amd64] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted colorclass [amd64] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- Unapproved: pythonqt (xenial-proposed/universe) [3.0-1 => 3.0-1ubuntu1.16.04.2] (no packageset)
<sergiusens> slangasek oh noes; sure I can push that fix without a bug logged too
 * sergiusens missed a comma 
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (precise-proposed) [0.8ubuntu0.13]
<LocutusOfBorg> can please any AA enlight me to what happened here? https://launchpad.net/ubuntu/+source/prep-installer
<LocutusOfBorg> I can't retry the build
<LocutusOfBorg> I can't see the build
<infinity> LocutusOfBorg: There is no build because it's a powerpc-only package.
<LocutusOfBorg> so, why can't it migrate? :)
<LocutusOfBorg> indeed, xenial did build it
<LocutusOfBorg> maybe we can do some magic to stop having it in proposed?
<infinity> Yes, we can delete it.
<LocutusOfBorg> thanks!
<infinity> LocutusOfBorg: As for "why can't it migrate", we never migrate a source that has no binaries.
<infinity> LocutusOfBorg: So if a source only builds for arches we don't have, well, there you go.
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (artful-proposed/main) [0.12.7~17.10.1 => 0.12.8~17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.7~17.04.1 => 0.12.8~17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (xenial-proposed/main) [0.12.7~16.04.1 => 0.12.8~16.04.1] (no packageset)
<LocutusOfBorg> thanks infinity makes sense
-queuebot:#ubuntu-release- New binary: akonadi [ppc64el] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [s390x] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [amd64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [i386] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [armhf] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (xenial-proposed/main) [15.04.0+16.04.20170214-0ubuntu2 => 15.04.0+16.04.20171130-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New binary: akonadi [arm64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [ppc64el] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [i386] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [amd64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
<LocutusOfBorg> hello Santa, for christmas I would like to have some more space on autopkgtesters, so they don't fail with ENOSPACE anymore
<LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/linux-headers-4.13.0-17_4.13.0-17.20_all.deb (--unpack):
<LocutusOfBorg>  cannot copy extracted data for './usr/src/linux-headers-4.13.0-17/spl/config/ltmain.sh' to '/usr/src/linux-headers-4.13.0-17/spl/config/ltmain.sh.dpkg-new': failed to write (No space left on device)
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/libdata-perl-perl/bionic/armhf
<LocutusOfBorg> I have been a nice guy, never typed a wrong sudo password, so dear santa, no incidents reported to you https://xkcd.com/838/
-queuebot:#ubuntu-release- New binary: marble [s390x] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [armhf] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-41-g76243487-0ubuntu1~17.10.1 => 17.1-46-g7acc9e68-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [17.1-41-g76243487-0ubuntu1~17.04.1 => 17.1-46-g7acc9e68-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: marble [arm64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-41-g76243487-0ubuntu1~16.04.1 => 17.1-46-g7acc9e68-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> good refernce LocutusOfBorg :)
<blackboxsw> tjaalton We have queued a small SRU update for cloud-init which will replace 17.1-41 with an SRU regression fix. There should be only one additional 'bug' to add to the list for verification.
<blackboxsw> we discovered a minor bug in 17.1.41 that we don't want to publish to <series>-updates
-queuebot:#ubuntu-release- Unapproved: lime-forensics (xenial-proposed/universe) [1.7.2-1 => 1.7.2-1ubuntu1] (no packageset)
<blackboxsw> slangasek: I see you on backup for SRU's today. Sorry for the ping but I might have missed tjaalton. We have a minor update to cloud-init per our manual SRU testing
<blackboxsw> I think it's late his time :
<blackboxsw> :/
<tjaalton> i'm off this week
<LocutusOfBorg> blackboxsw, if you are interested, I maintain a python-xkcd package, that brings them with some little python code :p
<slangasek> blackboxsw: if this cloud-init SRU needs to be accepted before the current one is released (which it's not ready for yet according to the bug states), then it needs to be reuploaded built with a -v option so that all three of the bugs are listed in the .changes file
<blackboxsw> slangasek: ok, this SRU 17.1.46 includes all of 17.1.41 + a couple of additions as listed in the new changelog entry 17.1-46-g7acc9e68-0ubuntu1~16.04.1. So rebuilding with -v will include all unpublished  content?
<blackboxsw> the content from 17.1-41-g76243487-0ubuntu1~16.04.1 too?
<blackboxsw> (all 3 bugs as you said)
<smoser> slangasek: ack.
<slangasek> blackboxsw: yes, -v takes an argument, which should be the most recent version published to -updates
<blackboxsw> ok TIL. thx
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (artful-proposed) [17.1-46-g7acc9e68-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-41-g76243487-0ubuntu1~16.04.1 => 17.1-46-g7acc9e68-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [17.1-41-g76243487-0ubuntu1~17.04.1 => 17.1-46-g7acc9e68-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<smoser> re-uploaded
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-41-g76243487-0ubuntu1~17.10.1 => 17.1-46-g7acc9e68-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [17.1-46-g7acc9e68-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.1-46-g7acc9e68-0ubuntu1~16.04.1]
<tsimonq2> I'm +1ing LocutusOfBorg :P
<tsimonq2> Santa, I would also like more of the autopkgtesters so the queue can go through a bit quicker
<tsimonq2> :P
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.1-46-g7acc9e68-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [17.1-46-g7acc9e68-0ubuntu1~17.04.1]
<slangasek> jibel: could I (or maybe ubuntu-release) get bug management privs on https://bugs.launchpad.net/auto-package-testing ?
#ubuntu-release 2017-12-02
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.1-46-g7acc9e68-0ubuntu1~16.04.1]
<tsimonq2> Anyone know offhand how often Launchpad syncs its Debian archive mirror?
<acheronuk> LocutusOfBorg: +1 as well. keep seeing test fails on armhf particularly which are just the device running out of space
<slangasek> LocutusOfBorg, acheronuk: yeah, looks like, possibly during an upgrade, /var/lib/lxd stopped being pointed at the 72G disk and started being pointed at the 7.6G disk.  looking.
<slangasek> LocutusOfBorg, acheronuk: fixed for 10.43.42.186 (the host listed in the libdata-perl-perl log).  If you see more of these going forward, please let me know
<acheronuk> slangasek: thanks. quickly checking a couple of logs on the ones I saw, that seems to be the same host. but yes, I'll let you know if any more occur
<cjwatson> tsimonq2: 25 4,10,16,22 * * *
<LocutusOfBorg> thanks slangasek for being helpful once again!
<cjwatson> tsimonq2: (UTC)
<LocutusOfBorg> I'll keep you informed
<LocutusOfBorg> slangasek, on a similar issue, in the last two days I saw some s390x strange failures with "can't acquire dpkg log"
<LocutusOfBorg> an example is here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/n/node-module-deps/20171202_091629_916ef@/log.gz
<LocutusOfBorg> maybe related?
<LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#ktextwidgets search for "/unknown" and you get 5 s390x failures
<LocutusOfBorg> this happens also later in the autopkgtestsuite, so they don't fall into the "unknown state", but a general "failed" e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/libc/libconstant-generate-perl/20171202_085435_718f2@/log.gz
<acheronuk> if anyone is about, could kate4/4:4.14.3-4ubuntu2 be badtested please? that is not buildable any more and needs to be removed from bionic soon, but can only get that done once latest kde4libs that it's test fail will block gets into -release
<slangasek> LocutusOfBorg: s390x failures are certainly not related to a misconfigured filesystem on one of the armhf host nodes, no.  We've noticed the dpkg lock problem, I'm currently unsure what is causing it but we need to make sure unattended-upgrades is disabled/removed from the autopkgtest cloud images; https://git.launchpad.net/autopkgtest-cloud tools/build-adt-image-all-clouds if someone wanted to
<slangasek> dig into this
<tsimonq2> Thanks cjwatson and slangasek :)
<tsimonq2> cjwatson: Out of curiosity, what's the reasoning behind every 6 hours at those times?
<slangasek> tsimonq2: Debian itself publishes every 6h (last I checked), I believe the times are selected to try to maximize the chances of Debian's publisher having completed first before LP tries to import
<tsimonq2> slangasek: ohhh dinstall didn't even cross my mind?
<tsimonq2> s/?//
<tsimonq2> Makes sense.
<tsimonq2> slangasek: Yep, #debian-ftp topic says "dinstall starts at 0152,0752,1352,1952 UTC"
<tsimonq2> slangasek: That is quite a gap though, shouldn't dinstall not take that long?
 * tsimonq2 doesn't really know
<acheronuk> forget what I asked about kate4 for today. uploaded a possible fix
<slangasek> tsimonq2: I don't know how long it normally takes; I guess the LP team have looked at this more closely than I have and the importer cronjob is empirically informed
<tsimonq2> slangasek: Alright, interesting though :)
<cjwatson> tsimonq2: dinstall takes a while, and then it needs to propagate to the appropriate mirror
<tsimonq2> cjwatson: ah ok
<cjwatson> tsimonq2: slangasek is correct that it's empirically informed; the last change to those times was in July of this year, when we moved it 20 minutes later because it was routinely overlapping Debian mirror pushes
<tsimonq2> Gotha
<tsimonq2> *gotcha
<tsimonq2> Question about the autopkgtester test request formatting... https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format says that "all-proposed" just has to be a non-empty value, and from (albeit limited) testing it seems to only accept 1 and not a boolean
<tsimonq2> What's up with that? :)
<tsimonq2> Doesn't even accept 0 or 2, just 1
<tsimonq2> If anything I'd at *least* expect it to take a boolean, even if it's redundantly called (like if false is passed)
<slangasek> 0 and 1 are booleans, 'false' is text ;)
<tsimonq2> (I've always seen booleans in the sense of "true" or "false" when programming, albeit I've only used them in a limited sense)
<slangasek> I'd say the documentation should be updated.  I don't think it's worth changing the code to be permissive
<tsimonq2> slangasek: But it doesn't accept 0, is that because it's redundant?
<slangasek> if you're in a programming language that recognizes true and false as booleans, sure.  In url variables, anything goes
<tsimonq2> (if that's the case, the message should probably explain that instead of just "invalid format")
<tsimonq2> Ah, gotcha
<tsimonq2> TIL
<slangasek> I think it doesn't allow it because no one bothers trying to pass the extra variable when it's not explicitly needed
<tsimonq2> Hm, ok
<tsimonq2> slangasek: You plan on updating the documentation or should I?
<slangasek> tsimonq2: feel free
<tsimonq2> slangasek: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev1=87&rev2=88
<slangasek> lgtm
<tsimonq2> cool
<tsimonq2> slangasek: Do you use some sort of tool to queue tests, or do you just edit the URL?
<tsimonq2> Because I'm thinking of hacking up a tool that I'll just put in ~/bin for myself but I don't know if there's already something...
#ubuntu-release 2017-12-03
<tsimonq2> Can I please get Binary NEW queue reviews for marble and akonadi? There's a sort of large tree that's depwait because of those...
<tsimonq2> Also, if a package is demoted to -proposed, what criteria does it have to meet to get back in -release?
<tsimonq2> (Adam demoted libkf5kface to -proposed during the opencv stuff, there's a new upstream release that should fix things)
<tsimonq2> (At least I thought, but it's irrelevant to the question about criteria, which I'd like to know for future reference ;) 0
<tsimonq2> s/0/)/
<tsimonq2> Can kubrick be let through? arm* is intentionally no longer built because of this gem: https://bugs.kde.org/show_bug.cgi?id=386367
<ubot5> KDE bug 386367 in general "Support open GL ES" [Wishlist,Unconfirmed]
<tsimonq2> (by "let through" I mean "do the thing so Britney doesn't complain about missing those ;)")
-queuebot:#ubuntu-release- Unapproved: childsplay (trusty-proposed/universe) [1.6-1 => 1.6-1ubuntu0.1] (no packageset)
<slangasek> tsimonq2: most tests I queue are by clicking the 'retry' buttons on the proposed-migration / autopkgtest pages
<slangasek> tsimonq2: a package demoted to -proposed gets back into devel the same way any other package migrates from -proposed to devel
<slangasek> tsimonq2: and removing kubrick/arm64 would appear to make kdegames newly uninstallable on that architecture (arch: all package with dep on kubrick).  are you sure that's what you want here?
<tsimonq2> slangasek: demotion remigration> Does it need *all* arches to pass builds or just the arches it previously built on>
<slangasek> the latter
<tsimonq2> Ok, cool.
<slangasek> specifically, the rule is that there must not be any out of date binaries for any arch
<tsimonq2> Well how does it know if there's out-of-date binaries if it's removed from -release and all -proposed arches are FTBFS?
<slangasek> by definition if there are no binaries there are no out of date binaries
<slangasek> however, if there was an older version of the package in -proposed that did build on some archs, and those binaries are published, but the package no longer builds on those archs, those are out-of-date binaries
<tsimonq2> But then why would it be removed from -proposed in the first place?
<tsimonq2> s/proposed/release/
<slangasek> for whatever reason the AA gave when removing it
<slangasek> (which is logged in LP)
<tsimonq2> Fair. :P
<tsimonq2> slangasek: kubrick> Would something like this be correct in the Depends field of kdegames? (Debian policy doesn't seem to help on this): kubrick [!arm64] (>= ${kde:Version}),
<slangasek> not unless you change the package to be arch: any instead of arch: all.
<tsimonq2> Why is that the case?
<slangasek> [] notation is evaluated at package build time.
<tsimonq2> Oh, gotcha.
<tsimonq2> (And it seems sane in this case to change to any)
<tsimonq2> slangasek: https://launchpad.net/ubuntu/+source/meta-kde/5:92ubuntu4
<tsimonq2> So yes, I'm OK with that now.
<slangasek> ok
<slangasek> removed
<tsimonq2> Thanks.
<slangasek> why was it dropped on arm64, though? I don't know how to interpret 'KDE Bug:386367' from the changelog; and it never failed to build in Ubuntu
<tsimonq2> "Kubrick needs openGL which means it can't be built on platforms which use openGLES.  Arm platforms typically use GLES.  Ideally it should be posted to also build with GLES."
<slangasek> curious; that doesn't seem like the sort of thing that would've been a new requirement in kubrick
<tsimonq2> Well we did do a new upstream release.
<tsimonq2> (well, they did, you get the point)
<slangasek> ah, the difference is the previous version was building against qt4
<tsimonq2> Oh, right, that would explain it.
<tsimonq2> slangasek: So then out of curiosity, why did that not have to go through Binary NEW?
<slangasek> which?
<tsimonq2> (given that there were new binaries specifically for each arch instead of just one arch:all binary)
<tsimonq2> kdegames
<slangasek> hmm because the binary was already known for each arch
<tsimonq2> Oh, I thought it'd have to go through Binary NEW. TIL.
 * tsimonq2 goes to bed, thanks slangasek!
 * slangasek waves
<acheronuk> yes, we did test build kubrick and found the FTBFS doing that. thanks for the above
-queuebot:#ubuntu-release- Unapproved: slic3r (artful-proposed/universe) [1.2.9+dfsg-6.1 => 1.2.9+dfsg-6.1ubuntu1] (no packageset)
<hyperair> damnit, tagged the wrong bug
-queuebot:#ubuntu-release- Unapproved: slic3r (artful-proposed/universe) [1.2.9+dfsg-6.1 => 1.2.9+dfsg-6.1ubuntu2] (no packageset)
<hyperair> ^ please ignore 1.2.9+dfsg-6.1ubuntu1 (wrong bug in changelog)
-queuebot:#ubuntu-release- Unapproved: rejected slic3r [source] (artful-proposed) [1.2.9+dfsg-6.1ubuntu1]
<jbicha> slangasek: good morning, several recent amd64/i386 autopkgtests fail with "ERROR: testbed failure: unexpected eof from the testbed"
<tsimonq2> I can +1 that, I've seen a couple ones myself failing like that.
<jbicha> slangasek: more specific example: http://autopkgtest.ubuntu.com/packages/g/grass/bionic/amd64
<tsimonq2> It would certainly help if there weren't literally two amd64/i386 builders not stalled >_< https://launchpad.net/builders/
<tsimonq2> s/2/3/ but still
<tsimonq2> Seems like they've been like that for about 13 hours...
<slangasek> jbicha: looking at it I see some neutron errors in one of the x86 cloud regions; I'll escalate
<slangasek> meanwhile, I guess the good news is the arm64 backlog is finally less than the x86 backlog :P
<slangasek> (also, armhf is now the second fastest autopkgtest arch, how do you like that)
<tsimonq2> If anyone's around, Launchpad's down to 2 active builders for amd64 and i386.
<tsimonq2> Oh, seems to be good now. \o/
-queuebot:#ubuntu-release- New binary: mame [amd64] (bionic-proposed/universe) [0.192+dfsg.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: msxpertsuite [amd64] (bionic-proposed/universe) [3.8.1-2] (no packageset)
#ubuntu-release 2018-11-26
<tsimonq2> RAOF: yaml-cpp> Good timing, according to the Debian archive I am now a DD.
<tsimonq2> I'll look shortly.
<acheronuk> looks like the tagging commit of kitinerary 18.08.3 may fix the FTBFS of 18.03.1 against new poppler in that transition
<acheronuk> *18.08.1
-queuebot:#ubuntu-release- New: accepted cstore-fdw [arm64] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [ppc64el] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache [ppc64el] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [armhf] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [armhf] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: libzip [amd64] (disco-proposed/universe) [1.3.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libzip [armhf] (disco-proposed/universe) [1.3.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: rust-atk-sys [s390x] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cstore-fdw [armhf] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [arm64] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: libzip [i386] (disco-proposed/universe) [1.3.2-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: libzip [arm64] (disco-proposed/universe) [1.3.2-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [ppc64el] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New binary: rust-gio-sys [s390x] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [armhf] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-separator [ppc64el] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New binary: chkboot [amd64] (disco-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tryton-modules-account-dunning-email [amd64] (disco-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-pango-sys [ppc64el] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: minetestmapper [amd64] (disco-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: tryton-modules-edocument-uncefact [amd64] (disco-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [arm64] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libflate [ppc64el] (disco-proposed) [0.1.18-1]
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [ppc64el] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [armhf] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-separator [arm64] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: minetestmapper [armhf] (disco-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tryton-modules-account-fr-chorus [amd64] (disco-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-maplit [ppc64el] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [ppc64el] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [armhf] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: tryton-modules-notification-email [amd64] (disco-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [arm64] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New binary: minetestmapper [i386] (disco-proposed/universe) [20180325-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-separator [armhf] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [i386] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [armhf] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gio-sys [ppc64el] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maplit [armhf] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [amd64] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [arm64] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maplit [arm64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [i386] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [ppc64el] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [i386] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [amd64] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gio-sys [i386] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [amd64] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [ppc64el] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libflate [amd64] (disco-proposed) [0.1.18-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache [amd64] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [s390x] (disco-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [amd64] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-pango-sys [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-separator [amd64] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-pos [s390x] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atk-sys [ppc64el] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pango-sys [i386] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8parse [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [i386] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-separator [i386] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atk-sys [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [i386] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [i386] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libflate [i386] (disco-proposed) [0.1.18-1]
-queuebot:#ubuntu-release- New: accepted rust-maplit [i386] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache [s390x] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [amd64] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gio-sys [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-servo-arc [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [amd64] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maplit [amd64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atk-sys [i386] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fragile [s390x] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maplit [s390x] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-owning-ref-0.3 [s390x] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-separator [s390x] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [s390x] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-maxminddb [s390x] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libflate [s390x] (disco-proposed) [0.1.18-1]
-queuebot:#ubuntu-release- New: accepted rust-pango-sys [s390x] (disco-proposed) [0.7.0-1]
<LocutusOfBorg> hello, anybody can please promote virtualbox/bionic to updates?
-queuebot:#ubuntu-release- New binary: libmawk [amd64] (disco-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmawk [i386] (disco-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmawk [ppc64el] (disco-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmawk [arm64] (disco-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmawk [armhf] (disco-proposed/none) [1.0.0-2] (no packageset)
<LocutusOfBorg> jbicha, hello, unblock lp: #1802586 ?
<ubot5> Launchpad bug 1802586 in sane-backends (Ubuntu) "sane-backends library name issues" [High,New] https://launchpad.net/bugs/1802586
-queuebot:#ubuntu-release- New binary: dlt-daemon [amd64] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dlt-daemon [s390x] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dlt-daemon [ppc64el] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
<infinity> mwhudson: (re: netplan upload) You shouldn't be creating directories in maintainer scripts, unless you are prepared to also be removing them in maintainer scripts.  Shipping the directory as part of the deb is the better option.
<infinity> mwhudson: (Though, I'd also note that the stub interfaces file should probably be removed on removal, if the sums match what we wrote, which I bet it isn't)
-queuebot:#ubuntu-release- New binary: dlt-daemon [arm64] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dlt-daemon [armhf] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dlt-daemon [i386] (disco-proposed/universe) [2.17.0-2ubuntu1] (no packageset)
<vorlon> jbicha: revisiting LP: #1758702, there are now other packages stuck in -proposed which depend on gitlab (gitaly).  Should gitlab be un-blacklisted?
<ubot5> Launchpad bug 1758702 in gitlab (Ubuntu) "Please consider adding gitlab to sync blacklist" [Undecided,Fix released] https://launchpad.net/bugs/1758702
-queuebot:#ubuntu-release- New: accepted dlt-daemon [amd64] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dlt-daemon [armhf] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dlt-daemon [ppc64el] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzip [amd64] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted libzip [armhf] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted libzip [ppc64el] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted dlt-daemon [arm64] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dlt-daemon [s390x] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzip [i386] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted dlt-daemon [i386] (disco-proposed) [2.17.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzip [s390x] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted libzip [arm64] (disco-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [amd64] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [armhf] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [ppc64el] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [arm64] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [s390x] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted minetestmapper [i386] (disco-proposed) [20180325-1]
-queuebot:#ubuntu-release- New: accepted chkboot [amd64] (disco-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-currency [amd64] (disco-proposed) [20181109-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-account-dunning-email [amd64] (disco-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-account-fr-chorus [amd64] (disco-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-edocument-unece [amd64] (disco-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-sale-subscription [amd64] (disco-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-basic-materials [amd64] (disco-proposed) [20181109.2-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-account-es [amd64] (disco-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-notification-email [amd64] (disco-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-intllib [amd64] (disco-proposed) [20180811-1]
-queuebot:#ubuntu-release- New: accepted tryton-modules-edocument-uncefact [amd64] (disco-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted libmawk [amd64] (disco-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libmawk [armhf] (disco-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libmawk [ppc64el] (disco-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-gio-sys [s390x] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted libmawk [arm64] (disco-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-atk-sys [s390x] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted libmawk [i386] (disco-proposed) [1.0.0-2]
<doko> Laney: how do I access files saved in $AUTOPKGTEST_ARTIFACTS?
<mwhudson> infinity: please to be fixing better
<mwhudson> but you are also right, there is nothing removing the file the postinst creates either
<mwhudson> i did wonder for disco+ if we should just drop the whole idea
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (bionic-proposed) [4.18.0-1005.5~18.04.1]
<Laney> doko: should be in the artifacts tarball you get
<Laney> also should be testable locally if you pass -o
<doko> Laney: sorry, where can I find that one?
<Laney> on the results page
<LocutusOfBorg> xnox, any reason for boost ppc64el not defining BOOST_OS_LINUX when gcc uses -std=c++11?
<LocutusOfBorg> xnox doko, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914688
<LocutusOfBorg> looks like a gcc bug to me
<ubot5> Debian bug 914688 in src:gcc-8 "g++: fails to understand BOOST_OS_LINUX on ppc64el?" [Serious,Open]
<jbicha> LocutusOfBorg: we may need a transitional package for Debian bug 913346
<ubot5> Debian bug 913346 in sane-backends "libsane1: Cannot update libsane1" [Serious,Open] http://bugs.debian.org/913346
<jibel> vorlon, xnox, infinity: didrocks and I have updated the MP to build layered images https://code.launchpad.net/~jibel/livecd-rootfs/add_multi_layered_squashfses_support/+merge/358490 Could you please review it? It goes with an ubuntu-cdimage and a debian-cd MP submitted as https://code.launchpad.net/~jibel/ubuntu-cdimage/support_for_multilayer/+merge/359512 and
<jibel> https://code.launchpad.net/~jibel/debian-cd/support_for_multilayer_images/+merge/359228 Thanks
<jbicha> vorlon: I still believe gitlab is unsupportable in Ubuntu without someone dedicated to maintaining it, so I think we should either blacklist gitaly
<jbicha> or maybe we could do something like https://salsa.debian.org/live-team/live-config/commit/51fdd70c to build gitlab-common (but not gitlab itself) on Ubuntu
<jbicha> or ask the Debian maintainer to move gitlab-common somewhere else. It's just some Debian config for gitlab stuff (and not what I would normally expect from a -common pkg)
<doko> LocutusOfBorg: so you are not sure, but sure enough to file an RC issue?
<acheronuk> if anyone is looking at poppler transition, updating kitinerary would resolve a FTBFS LP: #1805110
<ubot5> Launchpad bug 1805110 in kitinerary (Ubuntu) "18.08.1 FTBFS with new poppler 0.71" [Undecided,New] https://launchpad.net/bugs/1805110
<jbicha> acheronuk: are you asking for a sponsor? ð
<acheronuk> jbicha: yes, if a developer thinks it appropriate. I got interrupted after posting the bug here
<acheronuk> but mostly it was a FYI
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3.18.10.0]
<jbicha> seb128: I guess you're running the poppler transition ^
<seb128> jbicha, I though you were, you did all those rebuilds :)
<seb128> but no, I'm not leading/owning it, at least not actively, too busy for that. I do try to help/unblock things though, we just handled libreoffice and I did popplerkit.framework
<seb128> that's probably as much as I'm going to do for today
<jbicha> acheronuk: maybe LocutusOfBorg will sponsor for you; I think he was interested in getting new poppler in
<xnox> LocutusOfBorg, is anything actually broken? in itself BOOST_OS_LINUX is not very useful.
-queuebot:#ubuntu-release- Unapproved: python-wsme (bionic-proposed/main) [0.9.2-0ubuntu2 => 0.9.2-0ubuntu2.18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-wsme (cosmic-proposed/main) [0.9.2-0ubuntu2 => 0.9.2-0ubuntu2.18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu3 => 1.5ubuntu3.18.10.0] (desktop-core, ubuntu-server)
<cascardo> sil2100: there are some dkms packages on the bionic queue we would like to get to -proposed, can you help, please?
<cascardo> sil2100: those are needed to get linux-hwe-edge into bionic
<sil2100> cascardo: ACK
<cascardo> those would be openafs, oss4, xtables-addons, nat-rtsp, sysdig, lttng-modules
<cascardo> about these last two, the bugs are being edited for the sru template as we speak
<LocutusOfBorg> doko, gcc behaving differently seems a gcc issue
<LocutusOfBorg> anyway I'm debugging it with preprocessed sources
<LocutusOfBorg> xnox, why? it is documented, should be working I would say
<doko> LocutusOfBorg: are all the involved headers the same?
<LocutusOfBorg> doko, seems so, with a little change, I can't understand
<LocutusOfBorg> https://paste.ubuntu.com/p/cX2WxRNdpv/  and https://paste.ubuntu.com/p/QcJtXVnnmd/
<LocutusOfBorg> I filed it as RC because in one case or in the other, it is a serious problem I would say, not sure if in boost or gcc
<LocutusOfBorg> I can reassign in case
<xnox> doko, i'm not even sure that system boost is used in this case, instead of the embedded one.
<xnox> LocutusOfBorg, you should file the bug against the package that ftbfs, not the toolchain, nor the build-dep.
<xnox> it's easier to trace that way, instead of, walking backwards from where you got to it.
-queuebot:#ubuntu-release- Unapproved: apache2 (trusty-proposed/main) [2.4.10-1ubuntu1.1~ubuntu14.04.2 => 2.4.7-1ubuntu4.21] (ubuntu-server)
<LocutusOfBorg> xnox, I can reproduce with a 5 lines c code, why should I file a bug against a package in particular?
<doko> that's more like 5000 lines
<LocutusOfBorg> what are you talking about?
<LocutusOfBorg> anyway, the problem is simple now
<LocutusOfBorg> "linux" macro is not defined with -std=c++14
<LocutusOfBorg> end of the story
<LocutusOfBorg> https://www.boost.org/doc/libs/master/boost/predef/os/linux.h
<LocutusOfBorg> with -std=c++14 this check fails "if defined(linux) || defined(__linux)"
<xnox> but it is with gnu++14
<xnox> doko, https://paste.ubuntu.com/p/xX7DyQ3Qsz/
<xnox> i'm not sure what's the deal with "linux 1" and "__linux 1"
<doko> #define CPP_OS_LINUX_SPEC "-D__unix__ -D__gnu_linux__ -D__linux__ \
<doko> %{!undef:                                                         \
<doko>   %{!ansi:                                                        \
<doko>     %{!std=*:-Dunix -D__unix -Dlinux -D__linux}                   \
<doko>     %{std=gnu*:-Dunix -D__unix -Dlinux -D__linux}}}               \
<doko> -Asystem=linux -Asystem=unix -Asystem=posix %{pthread:-D_REENTRANT}"
<doko> so don't use __linux
<xnox> doko, how come it works on amd64?
 * xnox updates the chroot again, just to make sure, i'm testing the right thing
<LocutusOfBorg> doko, why both "linux" and "__linux" are both undefined on ppc64el then?
<doko> that code comes from config/rs6000/sysv4.h, therefore not seen on x86_64
<xnox> fun.
<doko> legacy macros
<xnox> it's weird; differently on amd64
<LocutusOfBorg> I updated the bug doko
<xnox> (disco-amd64)root@sochi:~# g++ -std=gnu++14 -dM -E -x c++ - < /dev/null | grep linux
<xnox> #define __linux 1
<xnox> #define __linux__ 1
<xnox> #define __gnu_linux__ 1
<xnox> #define linux 1
<xnox> (disco-amd64)root@sochi:~# g++ -std=c++14 -dM -E -x c++ - < /dev/null | grep linux
<xnox> #define __linux 1
<xnox> #define __linux__ 1
<xnox> #define __gnu_linux__ 1
<xnox> i.e. __linux still leaks into c+=14; whilst gnu++14 looks the same on amd64 & ppc64el.
<xnox> LocutusOfBorg, i would recommend to worse gnu++14 instead of c++14.....
<xnox> *force
<xnox> for now.
<LocutusOfBorg> xnox, I would recommend boost doing the check against __linux__ instead of __linux? :)
<LocutusOfBorg> isn't a better fix?
<xnox> LocutusOfBorg, surely, gnu++14 is quicker to fix / unblock the package you care about, against current boosts.
<LocutusOfBorg> unfortunately boost seems to have this issue on many packages
<LocutusOfBorg> xnox, for now maybe I'll reassign the bug from gcc to boost, so it doesn't get lost
<LocutusOfBorg> and notify the package maintainer about the "fix"
<LocutusOfBorg> xnox, grep __linux . -R |grep -v "__linux__" makes it a problem on other places in the source tree
<LocutusOfBorg> (I mean boost source tree)
<xnox> depends if it's in headers, or library code =/
<xnox> predef is a start.
<xnox> doko, somehow, it feels to me, like this may cause a lot of breakage.
-queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (bionic-proposed) [1.8.0~pre5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted oss4 [source] (bionic-proposed) [4.2-build2010-5ubuntu3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [source] (bionic-proposed) [3.0-0.1ubuntu1]
<xnox> some nice gems found
<xnox> 49//  Linux systems provide the byteswap.h header, with
<xnox> 50#elif defined(__linux__)
<xnox> 51//  don't check for obsolete forms defined(linux) and defined(__linux) on the theory that
<xnox> 52//  compilers that predefine only these are so old that byteswap.h probably isn't present.
-queuebot:#ubuntu-release- Unapproved: accepted nat-rtsp [source] (bionic-proposed) [0.7+1.g2ea3cb6-1ubuntu1~18.04.1]
<LocutusOfBorg> jbicha, I agree wrt the transitional package, maybe doing it in debian is good too?
<LocutusOfBorg> acheronuk, .
<LocutusOfBorg> I also changed somewhat the changelog
-queuebot:#ubuntu-release- Unapproved: accepted sysdig [source] (bionic-proposed) [0.19.1-1ubuntu1]
<acheronuk> LocutusOfBorg: thanks :)
<LocutusOfBorg> acheronuk, please forward the issue to debian :)
<LocutusOfBorg> I don't want a tarball mismatch on next update
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.5-1ubuntu1.2]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1005.5] (kernel)
<doko> xnox, LocutusOfBorg: there is https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00916.html  ... but not yet approved, and still better to the macro which is defined at any time
<ubot5> gcc.gnu.org bug 2018 in fortran "Sqrt causes ice in emit_move_insn, at expr.c:2718" [Normal,Resolved: fixed]
<cpaelzer> juliank: you helped me with your lp-attach script and considered bringing it to ubuntu-dev-tools, I just wanted to let you know that I just learned that package lptools might be a better match for that
<juliank> might be
<juliank> But if we focus it on Ubuntu bugs, we can create a nicer syntax and then it would fit better in ubuntu-dev-tools
<xnox> doko, agree. I did submit a pull request to boostorg to start using the newer macros.
<xnox> however some places it does check for __linux && some-really-weird-acienct-compiler
<xnox> thus can't just mass sed it.
<doko> sil2100, Laney: please mark the python3.6/3.6.7-1 test as failing, triggered by pytho3-stdlib-extensions. we are removing python3.6, but only if theat package migrates
<sil2100> doko: ok, let me look at that, I want 3.6 gone as well
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [source] (xenial-proposed) [15.04.1+16.04.20160701-0ubuntu3]
<xnox> doko, LocutusOfBorg - at least predef change got merged https://github.com/boostorg/predef/pull/91/files
<gitbot> boostorg issue (Pull request) 91 in predef "os/linux: add more linux detection defines." [Closed]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.6 => 1.1ubuntu1.18.04.7] (desktop-core, ubuntu-server)
<xnox> doko, sil2100 - i'm not sure, if python3-stdlib-extensions needs to be forced in with rm python3.6
<xnox> doko, sil2100 because update_output says that migrating python3-stdlib-extensions will break idle-python3.6
<xnox> trying: python3-stdlib-extensions
<xnox> skipped: python3-stdlib-extensions (0, 33, 4)
<xnox>     got: 8+0: a-2:a-1:a-1:i-0:p-1:s-3
<xnox>     * amd64: idle-python3.6
-queuebot:#ubuntu-release- New binary: libblockdev [ppc64el] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libblockdev [s390x] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
<xnox> doko, sil2100 - or an AA should remove src:python3.6 now, as nothing depends on it.
<xnox> (the only one build-depends that remains is python3-stdlib-extensions, which will migrate if python3.6 is gone)
-queuebot:#ubuntu-release- New binary: bacula [s390x] (disco-proposed/universe) [9.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libblockdev [arm64] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libblockdev [armhf] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: feature-check [amd64] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3.18.10.0]
-queuebot:#ubuntu-release- New binary: libblockdev [amd64] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libblockdev [i386] (disco-proposed/main) [2.20-5] (desktop-core, ubuntu-server)
<jbicha> those newlibblockdev binaries need to go to universe, not main please :)
-queuebot:#ubuntu-release- New binary: bacula [ppc64el] (disco-proposed/universe) [9.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rtags [s390x] (disco-proposed/none) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastp [s390x] (disco-proposed/none) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.7]
-queuebot:#ubuntu-release- New binary: bacula [i386] (disco-proposed/universe) [9.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: x13as [s390x] (disco-proposed/none) [1.1-B39-1] (no packageset)
<doko> xnox, sil2100: removed the binary
-queuebot:#ubuntu-release- New binary: bacula [armhf] (disco-proposed/universe) [9.2.2-5] (no packageset)
<sil2100> doko: \o/
-queuebot:#ubuntu-release- New binary: bacula [amd64] (disco-proposed/universe) [9.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bacula [arm64] (disco-proposed/universe) [9.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: cohomcalg [amd64] (disco-proposed/universe) [0.32+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastp [amd64] (disco-proposed/universe) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdudaemon [amd64] (disco-proposed/universe) [0.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastp [i386] (disco-proposed/universe) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libblockdev [amd64] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted libblockdev [armhf] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted libblockdev [ppc64el] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted libblockdev [arm64] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted libblockdev [s390x] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted libblockdev [i386] (disco-proposed) [2.20-5]
-queuebot:#ubuntu-release- New: accepted bacula [amd64] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New: accepted bacula [armhf] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New: accepted bacula [ppc64el] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New binary: scala-tools-sbinary [amd64] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bacula [arm64] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New: accepted bacula [s390x] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New: accepted bacula [i386] (disco-proposed) [9.2.2-5]
-queuebot:#ubuntu-release- New: accepted cohomcalg [amd64] (disco-proposed) [0.32+ds-1]
-queuebot:#ubuntu-release- New: accepted pdudaemon [amd64] (disco-proposed) [0.0.7-1]
-queuebot:#ubuntu-release- New binary: astropy-sphinx-theme [amd64] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted feature-check [amd64] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New binary: tzdiff [amd64] (disco-proposed/universe) [0.9+git20181015.0f048c4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted scala-tools-sbinary [amd64] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New binary: umatrix [amd64] (disco-proposed/universe) [1.3.14+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtags [amd64] (disco-proposed/universe) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x13as [amd64] (disco-proposed/multiverse) [1.1-B39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtags [ppc64el] (disco-proposed/universe) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yt [s390x] (disco-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: x13as [i386] (disco-proposed/multiverse) [1.1-B39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clazy [ppc64el] (disco-proposed/universe) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtags [armhf] (disco-proposed/universe) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astropy-sphinx-theme [amd64] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tzdiff [amd64] (disco-proposed) [0.9+git20181015.0f048c4-1]
-queuebot:#ubuntu-release- New: accepted umatrix [amd64] (disco-proposed) [1.3.14+dfsg-1]
-queuebot:#ubuntu-release- New binary: fastp [ppc64el] (disco-proposed/universe) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtags [arm64] (disco-proposed/universe) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastp [armhf] (disco-proposed/universe) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastp [arm64] (disco-proposed/universe) [0.19.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fastp [amd64] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fastp [armhf] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fastp [ppc64el] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fastp [arm64] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fastp [s390x] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fastp [i386] (disco-proposed) [0.19.5+dfsg-1]
-queuebot:#ubuntu-release- New binary: rtags [i386] (disco-proposed/universe) [2.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fever [arm64] (disco-proposed/universe) [1.0.1-1] (no packageset)
<cyphermox> could someone please review netplan.io in the bionic and cosmic unapproved queues?
<infinity> cyphermox: Is the binary junk in the diff because you forgot to clean or because the previous uploader did?
-queuebot:#ubuntu-release- New binary: fever [armhf] (disco-proposed/universe) [1.0.1-1] (no packageset)
<infinity> Based on tarball size, I'd say it's you who forgot. :)
<cyphermox> that's the same person in both cases
<cyphermox> I blame git, because I always do git clean / git reset.
<infinity> cyphermox: Looks like both uploads have the same crufty sadness.
-queuebot:#ubuntu-release- New binary: x13as [arm64] (disco-proposed/multiverse) [1.1-B39-1] (no packageset)
<cyphermox> yes
<infinity> Is there not a way to run python in a "please don't create cache files" mode?  Testsuites should probably use that, so running in-place doesn't then require a followup clean.
-queuebot:#ubuntu-release- New binary: x13as [armhf] (disco-proposed/multiverse) [1.1-B39-1] (no packageset)
<cyphermox> don't know, will look later. if you want to reject I can reupload with that removed.
<infinity> Doing do.
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (bionic-proposed) [0.40.1~18.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (cosmic-proposed) [0.40.2.2]
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.40.1~18.04.2 => 0.40.1~18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.40.2.1 => 0.40.2.2] (core)
-queuebot:#ubuntu-release- New binary: yt [amd64] (disco-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yt [ppc64el] (disco-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fever [ppc64el] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x13as [ppc64el] (disco-proposed/multiverse) [1.1-B39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yt [i386] (disco-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [source] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (bionic-proposed) [2.4.95-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: python-letsencrypt (xenial-proposed/universe) [0.4.1-1ubuntu0.16.04.1 => 0.23.0-1ubuntu0.16.04.1~ppa2] (no packageset)
<NCommander> Ugh, can someone please NAK my SRU of python-letsencrypt, I accidently uploaded to the wrong pocket
<NCommander> Was supposed to go to a PPA BEFORE getting SRUed
<NCommander> ^- rbasak infinity
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.40.2.2]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.40.1~18.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected python-letsencrypt [source] (xenial-proposed) [0.23.0-1ubuntu0.16.04.1~ppa2]
<NCommander> Thanks
<NCommander> Huh, odd
<NCommander> I didn't get a reject email
<infinity> You should do.
<infinity> Mail is slow?
-queuebot:#ubuntu-release- New binary: yt [arm64] (disco-proposed/universe) [3.4.1-2] (no packageset)
<NCommander> There it goes
<NCommander> infinity, yeah, launchpad is being launchpad
<NCommander> thanks
<NCommander> infinity, little rusty, just starting to get back into Ubuntu development again
<teward> NCommander: infinity: sometimes the 'Rejected' message is very slow as well to arrive - up to 10 minutes if things're overtaxed
<teward> ... or because The Internet :P
<teward> (usually fast, but not always)
<infinity> I don't recall for sure, but I think mail from LP may be async from the actions generating it.
<infinity> (I mean, more async than SMTP already is, as in it batches it up before lobbing it at a local MTA)
<NCommander> I vaguely remember mail gets batched and goes in waves.
 * NCommander hasn't looked under Launchpad's hood in a LONG time.
<NCommander> infinity, so heads up, I'm working on a set of SRUs to update xenial's lets encrypt to 0.23 (I'm just straight backporting the bionic package). There's an open bug about it but I think this may need to go to -security
<NCommander> because the package is just going to flat out stop working come feb
<infinity> NCommander: Then you probably want to have a chat with mdeslaur.
<NCommander> infinity, we can pocket copy from updates to security, right? So if mdeslaur signs off, its straight forward?
<mdeslaur> it usually needs to be built in the security PPA so it isn't built with -updates enabled
<infinity> NCommander: Stuff headed for security should be built against security, so should go through the security team and their security-proposed PPA.
<mdeslaur> unless there are no binaries in the package
<teward> NCommander: if it's LetsEncrypt, then yes I'd feel safer it going through a sec team analysis
<mdeslaur> NCommander: once you have packages, ping me with the bug number
<NCommander> mdeslaur, that should be fine then, but there was a package split so there's one new package.
<teward> just because I know how many people use that (even at my workplace's infra) and why it'd need reviewed)
<teward> just my two cents :)
<NCommander> teward, right, I'm working with the LE team on this; normally I won't say this should go to security but ya know, LE breaking is kinda a bad thing
<teward> yep.
<NCommander> mdeslaur, I'm aiming to have an SRU upload by weeks end. We have until feb, so let the SRU land, bake, and then look at security upload mid december?
-queuebot:#ubuntu-release- New: accepted rtags [amd64] (disco-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted rtags [armhf] (disco-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted rtags [ppc64el] (disco-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted rtags [arm64] (disco-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted rtags [s390x] (disco-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted rtags [i386] (disco-proposed) [2.20-1]
<infinity> NCommander: Anyhow, I recommend keeping an open line with mdeslaur on this, keep them involved early, so they can review the plan, maybe disagree that a wholesale backport is better than a targetted cherry-pick (and you can make your argument for the inverse), so no one gives you a flat-out "no" when you're closer to your deadline and everything breaks. :P
<teward> ^ thi
<teward> s
<teward> STUPID KEYBOARD!  *throws the external keyboard into the river*
<NCommander> infinity, yeah, that's why I brought it up.
<NCommander> mdeslaur, https://bugs.launchpad.net/ubuntu/xenial/+source/python-letsencrypt/+bug/1640978 - here's the context. The bug is a bit ... ahem ... dated.
<ubot5> Ubuntu bug 1640978 in python-certbot-nginx (Ubuntu Zesty) "[SRU] Backport letsencrypt 0.14.2" [Undecided,Fix committed]
<teward> y'know I was wondering why that pinged me, then I realized I had a highlight set for 'nginx' in here :|
<teward> *chastises self*
<NCommander> teward, :)
<teward> NCommander: that's actually... a good question, this update would publish new autoconfig rules for certbot nginx yes?
<teward> which releases're you targeting with a potential SRU?
<NCommander> teward, just xenial; it's the only one affected. The version in xenial didn't support nginx. I believe there was an ACK to include that as a NEW package
<teward> becasue nginx related config headaches :P
<NCommander> but I haven't prepped an SRU for you.
<teward> NCommander: ack
<teward> nah no rush was just picking your brain at this point
-queuebot:#ubuntu-release- New binary: yt [armhf] (disco-proposed/universe) [3.4.1-2] (no packageset)
<NCommander> all the stuff are plugins
<NCommander> so we have a lot of flexibility on what gets backported
-queuebot:#ubuntu-release- New: accepted yt [amd64] (disco-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted yt [armhf] (disco-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted yt [ppc64el] (disco-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted yt [arm64] (disco-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted yt [s390x] (disco-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted yt [i386] (disco-proposed) [3.4.1-2]
<doko> r-cran-rnexml/amd64 unsatisfiable Depends: r-base-core (>= 3.5.1-2)
<doko> why is britney complaining about that? it's there
-queuebot:#ubuntu-release- New: accepted x13as [amd64] (disco-proposed) [1.1-B39-1]
-queuebot:#ubuntu-release- New: accepted x13as [armhf] (disco-proposed) [1.1-B39-1]
-queuebot:#ubuntu-release- New: accepted x13as [ppc64el] (disco-proposed) [1.1-B39-1]
-queuebot:#ubuntu-release- New: accepted x13as [arm64] (disco-proposed) [1.1-B39-1]
-queuebot:#ubuntu-release- New: accepted x13as [s390x] (disco-proposed) [1.1-B39-1]
-queuebot:#ubuntu-release- New: accepted x13as [i386] (disco-proposed) [1.1-B39-1]
<infinity> doko: Curious.  All the R stuff seems to suffer the same issue.
 * infinity investigates harder
<infinity> doko: Oh, it might have just been a publishing hiccup where r-base briefly didn't exist in either pocket because of a race between the copy and delete.
<infinity> doko: Should fix itseld.
<infinity> itself*
<doko> ahh, ok
<infinity> doko: Copies are async, deletes are sync, if britney does the promotion just on the cusp of a new publisher run, things can "go away" for a cycle. :(
<infinity> Not the most friendly bug ever.
-queuebot:#ubuntu-release- New binary: sphinx-astropy [amd64] (disco-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [s390x] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted sphinx-astropy [amd64] (disco-proposed) [1.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.10]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.9 => 2.525.10] (desktop-core)
-queuebot:#ubuntu-release- New: accepted clazy [ppc64el] (disco-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted fever [armhf] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fever [arm64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fever [ppc64el] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [ppc64el] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: python-django-debreach (disco-proposed/primary) [1.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [amd64] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
#ubuntu-release 2018-11-27
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [i386] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [arm64] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [armhf] (bionic-proposed/main) [1:7-3~ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [amd64] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [armhf] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [ppc64el] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [arm64] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [s390x] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [i386] (bionic-proposed) [1:7-3~ubuntu0.18.04.1]
<doko> mwhudson: do rust packages need regular rebuilds like ghc/ocaml? see update_output
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (cosmic-proposed/main) [5.11.1+dfsg-7ubuntu1 => 5.11.1+dfsg-7ubuntu2] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (cosmic-proposed/universe) [5.11.1-6 => 5.11.1-6build1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (cosmic-proposed/universe) [5.11.1-5 => 5.11.1-5ubuntu1] (kubuntu, qt5) (sync)
<mitya57> infinity: Hi, remember us talking about Qt documentation SRUs (bug 1799111)? I have now implemented a better fix, and as a demonstration there is qtdeclarative no-change rebuild with fixed docs.
<ubot5> bug 1799111 in qttools-opensource-src (Ubuntu Cosmic) "lots of Classes missing from docs (e.g. QFileInfo)" [Undecided,New] https://launchpad.net/bugs/1799111
<mitya57> So what is in the queue now is a sync of three packages from a CI Train PPA: qtbase has a fix and rebuilt docs, qttools has another fix, qtdeclarative has rebuilt docs only. More details are in the bug description.
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1005.5]
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.2] (ubuntu-desktop)
<oSoMoN> can someone please accept libreoffice{,-l10n} 1:6.0.7-0ubuntu0.18.04.2 in bionic-proposed, it's a trivial patch to fix a FTBFS ?
<Laney> https://paste.ubuntu.com/p/XJcD55nscm/
<Laney> disco retry league table
<doko> 18k?
<apw> Laney, are you sure about the top one, isn't that like more than exist or something
<Laney> certainly not
<Laney> there's been 45-50k runs per architecture already
<apw> Laney, but he managed to click on 18K links ... really ?
<Laney> the database don't lie
<apw> s/he/they
<Laney> you can script it to use wget ir something
<apw> heh, sometimes it does :)
<Laney> retry-autopkgtest-regressions --help even tells you how to do that
<apw> well ... is all i can say to that
<ginggs> i think he ran retry-autopkgtest-regressions after the queues were stopped earlier
<ginggs> but he does also have an itchy trigger finger :)
<xnox> Laney, in my defense, voron killed half of mine; once; and retriggered in a broken way instead.
<Laney> :>
<Laney> those results don't say anything about whether the requests were legit
<LocutusOfBorg> xnox, ping wrt boost upload? :)
<LocutusOfBorg> folks, how do you feel about an haskell transition?
<LocutusOfBorg> I can do it, we are close in debian now
<LocutusOfBorg> but I want to manually sync packages, to avoid useless rebuilds
<doko> too early, let poppler migrate, and the autopkg test queues empty
<LocutusOfBorg> ack
<LocutusOfBorg> tkamppeter, I'm uploading your cups-filters patch, ok?
<ahasenack> samba 4.8 is stuck (disco) because ldb was updated to 1.4.x, and that requires samba 4.9. I'll work on it, but will take a day probably
<ahasenack> the other issue is with ldb itself, debian's is now pulling in libmdb, which is universe in our case. I'll work on that too
-queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20180312-1 => 0.2.0+git20180917-2~ubuntu0.18.04.1] (no packageset)
<doko> ahasenack: there's also a MIR needed for http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  lmdb
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (bionic-proposed/main) [4.18.0-1006.6~18.04.1] (no packageset)
<ahasenack> yeah, that's the one I mentioned, lmdb
<ahasenack> I'm trying a build of ldb without lmdb, to check what we are missing
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1006.6] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1006.6]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (bionic-proposed) [4.18.0-1006.6~18.04.1]
<oSoMoN> sil2100, when you have a moment, would you mind accepting libreoffice 1:6.0.7-0ubuntu0.18.04.2 into bionic-proposed?
<kenvandine> sil2100: while you're at it, could you please accept fontconfig 2.12.6-0ubuntu2.2 bug 1803534 which i uploaded early last week to fix a FTBFS :-D
<ubot5> bug 1803534 in fontconfig (Ubuntu) "Backport uuid based cache file naming scheme" [Undecided,New] https://launchpad.net/bugs/1803534
<sil2100> oSoMoN, kenvandine: I'll try to get to those after lunch!
<sil2100> (aka soon)
<oSoMoN> thanks!
<oSoMoN> and enjoy your lunch
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.5 => 0.96.24.32.6] (desktop-core, ubuntu-server)
<kenvandine> sil2100: thanks!
<tkamppeter> LocutusOfBorg, OK.
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.7 => 1:18.04.11.8] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1004.5~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1004.5~18.04.1]
<LocutusOfBorg> infinity, hello what about uploading dpkg? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/9617079/+listing-archive-extra
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.41]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.10]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (cosmic-proposed/main) [1:3.30.1-1ubuntu2 => 1:3.30.2-1ubuntu0.18.10.1] (ubuntu-desktop)
<jbicha> vorlon: good morning https://code.launchpad.net/~jbicha/britney/hints-perl-udisks-trnascan/+merge/359620
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.9 => 1.1ubuntu1.18.04.7~16.04.0] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.9 => 1.1ubuntu1.18.04.7~16.04.0] (desktop-core, ubuntu-server)
<vorlon> jbicha: nack on badtesting the newer perl; the previous badtest was added due to a missing test dep + the perl transition itself, whatever the new failure is it should be sorted, not ignored
-queuebot:#ubuntu-release- Unapproved: accepted python-wsme [source] (cosmic-proposed) [0.9.2-0ubuntu2.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-wsme [source] (bionic-proposed) [0.9.2-0ubuntu2.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-memcache [source] (cosmic-proposed) [1.57-2ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-memcache [source] (bionic-proposed) [1.57-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (cosmic-proposed) [0.68.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted libgnomekbd [source] (cosmic-proposed) [3.26.0-3ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted installation-guide [source] (cosmic-proposed) [20160121ubuntu7.1]
-queuebot:#ubuntu-release- Unapproved: accepted installation-guide [source] (bionic-proposed) [20160121ubuntu4.3]
-queuebot:#ubuntu-release- New binary: black [amd64] (disco-proposed/universe) [18.9b0-1-6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.0]
-queuebot:#ubuntu-release- New binary: lepton-eda [s390x] (disco-proposed/universe) [1.9.6-1] (no packageset)
<infinity> mitya57: Yay.
<infinity> LocutusOfBorg: I'm getting to it.
<jbicha> um it looks like we lost most of the autopkgtest queue: https://autopkgtest.ubuntu.com/running
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.8]
-queuebot:#ubuntu-release- New binary: qgis [s390x] (disco-proposed/universe) [2.18.26+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lepton-eda [i386] (disco-proposed/universe) [1.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lepton-eda [i386] (disco-proposed) [1.9.6-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (disco-proposed) [2.18.26+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lepton-eda [s390x] (disco-proposed) [1.9.6-1]
-queuebot:#ubuntu-release- New: accepted black [amd64] (disco-proposed) [18.9b0-1-6]
<vorlon> jbicha: what are you expecting to see in the queue that isn't there?
<vorlon> I can confirm from graphs of the queue that there's an unnatural drop-off
<Laney> rabbitmq oomed
<vorlon> ok
<jbicha> I'm expecting to see over a 1000 arm* in the huge queues
<vorlon> Laney: are you following through on this?
<Laney> the easiest way to fix it is to wait for britney to not be running, and then delete its pending.json so that it re-requests the outstanding tests
<Laney> can do
<jbicha> thank you
<Laney> sure
<Laney> test request fest
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (cosmic-proposed) [1.54.3-1~ubuntu18.10.1]
<infinity> LocutusOfBorg: Mine ended up looking similar to yours, except you dropped a few hunks by accident, and your getenv "fix" wasn't quite sane.
<infinity> LocutusOfBorg: But gave you credit for noticing the singedness and implicit declaration warnings.
<infinity> dpkg is warning-free, tempted to turn on -Werror...
-queuebot:#ubuntu-release- New source: xorg-server-hwe-18.04 (bionic-proposed/primary) [2:1.20.1-3ubuntu2.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (cosmic-proposed) [3.30.2-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (cosmic-proposed) [3.0.3-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: wayland (cosmic-proposed/main) [1.16.0-1ubuntu1 => 1.16.0-1ubuntu1.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (cosmic-proposed) [3.0.3-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: wayland (bionic-proposed/main) [1.14.0-2 => 1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (cosmic-proposed) [1:3.30.2-1ubuntu0.18.10.1]
<stgraber> whoever is doing the SRU reviews, the exact same LXC and LXCFS is in bionic-proposed, so if you're happy with the cosmic one, you'll likely be happy with that one too :)
<mwhudson> doko: i know nothing about packaging rust packages vs rustc/cargo but i'll check
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.1-0ubuntu3 => 3:13.0.1-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.0-0ubuntu4 => 3:14.0.0-0ubuntu4.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (bionic-proposed) [0.62.0-2ubuntu2.3]
<xnox> doko, mwhudson - i see this transition in debian https://release.debian.org/transitions/html/auto-rustc.html maybe we need the same?
-queuebot:#ubuntu-release- Unapproved: accepted libgnomekbd [source] (bionic-proposed) [3.26.0-3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (bionic-proposed) [3.0.3-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (bionic-proposed) [3.0.3-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New source: zhmcclient (disco-proposed/primary) [0.21.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected subiquity [source] (xenial-proposed) [0.0.24.1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted osinfo-db [source] (bionic-proposed) [0.20180929-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fontconfig [source] (bionic-proposed) [2.12.6-0ubuntu2.2]
<LocutusOfBorg> thanks infinity ! I wasn't sure either, I had to drop a lot of that po delta stuff :/
<LocutusOfBorg> btw the previous ubuntu3 in my ppa was more "sane" and warning free
<LocutusOfBorg> lets see how you fixed it
<LocutusOfBorg> btw, I noticed the warnings mostly by change, because I was trying to understand if libzstd was really enabled :)
<LocutusOfBorg> why isn't that change upstreamed in debian?
<LocutusOfBorg> btw the getnenv change was tested locally in a simple test case and worked, not sure why btw :) (yes, because 0 and NULL are equal in my pc probably)
<LocutusOfBorg> and now devscript needs a merge
<infinity> LocutusOfBorg: Already synced.
<infinity> (after telling vorlon I was dropping his delta)
<infinity> LocutusOfBorg: The zstd stuff is "half upstreamed"... rbalint is still working on convincing guillem to love it.
<infinity> Laney, vorlon: It might be about time to ask autopkgtest to forget about vivid, yakkety, zesty, and artful...
-queuebot:#ubuntu-release- Unapproved: accepted knopflerfish-osgi [source] (bionic-proposed) [6.1.1-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: elogind [i386] (disco-proposed/universe) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1] (no packageset)
-queuebot:#ubuntu-release- New binary: elogind [s390x] (disco-proposed/universe) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected usbmuxd [source] (bionic-proposed) [1.1.0-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: elogind [amd64] (disco-proposed/universe) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1] (no packageset)
-queuebot:#ubuntu-release- New binary: elogind [ppc64el] (disco-proposed/universe) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.2]
<tsimonq2> infinity, bdmurray: Soonish (as builders allow) I'm going to copy-package mate-screensaver to the Bionic queue with binaries; this is intentional. The security team has agreed to do a bionic-proposed --(aging period)--> bionic-security hop because it's a bugfix point release and it's from a PPA which has only -security enabled.
<tsimonq2> infinity: Since you have Powers, you're welcome to copy my source from ppa:tsimonq2/security-test-builds to the security PPA if you prefer to get binaries from there.
<infinity> tsimonq2: I'd prefer it from a PPA whose configuration I can see, yes.
<tsimonq2> infinity: https://launchpad.net/~tsimonq2/+archive/ubuntu/security-test-builds/+sourcepub/9619104/+listing-archive-extra
<tsimonq2> infinity: (I would assume there's a higher build score in the security PPA too, and a lot of builders seem to be down because of "Cleaning".)
<infinity> tsimonq2: Copied to https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
<tsimonq2> infinity: Thanks.
<vorlon> infinity: forget at which level? do you want things cleaned out of swift?
<infinity> vorlon: I have no idea what level of forgetfulness was applied in the past. :P
<infinity> vorlon: But, eg, the results pages and queues don't show old releases that pitti cleaned out.
<vorlon> infinity: are you sure?  I thought vivid was the release cycle when autopkgtest was stood up
<vorlon> infinity: (and we have results for trusty because they were run retroactively)
<infinity> vorlon: If that assertion were true, we'd have wily results.
<infinity> And a wily queue.
<vorlon> hmm
<infinity> Err, the assertion that we started in vivid and never cleaned.
 * vorlon nods
<vorlon> infinity: so one problem is that the way we open the archive doesn't copy results around in swift... you may have noticed that if you try to follow the link to the log for the first result in a series you get a 404, because it tries to find a result for that series rather than the previous series that the test was actually run for
<vorlon> (well, copying the results is maybe not the only option - but it also doesn't refcount them usefully)
<infinity> That's certainly a bug.
<vorlon> yeah
<vorlon> one I think we need to fix before we start nuking past test results
<infinity> Anyhow, I tihnk I see autopkgtest mentions as far back as... raring?
<vorlon> ah?
<infinity> So, the nuking has clearly happened many times.
<vorlon> and are we ok with the historical information disappearing from http://autopkgtest.ubuntu.com/statistics ?
<mwhudson> INFO 	librust-lazy-static-dev_1.2.0-1_amd64.deb: has 1 file(s) with a time stamp too far in the past (e.g. usr/share/cargo/registry/lazy_static-1.2.0/.cargo_vcs_info.json [Thu Jan  1 00:00:00 1970]).
<infinity> Although, back then, autopkgtest was driven from jenkins.  I'm not sure when the cutover was.
<mwhudson> what
<vorlon> mwhudson: is that a recent build? I thought xnox fixed the Debian cargo toolchain recently to address that
<mwhudson> yes
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (trusty-proposed) [204-5ubuntu20.29]
<mwhudson> from 6 hours ago
<vorlon> mwhudson: (but also: hurray for an archive upload check that is supposed to be applied in both Debian and Ubuntu, but somehow doesn't fail in Debian)
<vorlon> ah; then who reverted xnox's change?
<xnox> vorlon, i think dh-make-rust thing autogenerates .cargo_vcs_info.json with a broken timestamp.
<xnox> vorlon, and people use that tool.... a lot....
<vorlon> xnox: right, but I thought you were fixing that
<mwhudson> ah yes, it's in the source package with that timestamp
<xnox> hmmmm i didn't
<vorlon> hmm ok
<infinity> vorlon: I dunno.  I mean, maybe I'm wrong about cleaning, and we should ask pitti what we did in the past.  But I *think* I remember things disappearing from results and queues (and, by extension, that stats page).
<infinity> vorlon: At the very least, the old queues should be closed.  If we want stats and logs forever, that's between you and swift.
<infinity> vorlon: From my POV, though, the granularity of trends from LTS to LTS is good enough for those stats.
#ubuntu-release 2018-11-28
<xnox> mwhudson, i think this can be fixed in dh-cargo for good
<mwhudson> xnox: debcargo? dh-cargo?
<infinity> Why would anyone intentionally create a file with a timestamp of 1?
<infinity> Or is that 0?
<xnox> i think debcargo to fix the source packages (for the future); dh-cargo to fix the .debs that are generated from broken sources made by broken debcargo
<infinity> Either way, why?
<vorlon> infinity: it looks like artful is the only one that still has queues in the worker config that need expired, fwiw... their appearance on http://autopkgtest.ubuntu.com/running is something else, and I think dropping from there involves the db surgery that loses us references
<mwhudson> neither of those packages seems to reference that file
<infinity> vorlon: Perhaps a middle ground (if you really want *some* baseline ref) is to keep a shallow copy, but generally garbage collect.
<infinity> vorlon: That is, keep the last result from each package/series/arch, or similar.
<vorlon> sure
<infinity> vorlon: Also, Debian seems to GC logs, but keep results.  That mightn't be stupid.
<mwhudson> ah wait i think it's src:cargo's fault
<infinity> vorlon: Anyhow, it was indeed the appearance on /running/ and the endlessly right-growing table on /package/<package> pages that made me think of it.
<infinity> vorlon: And I'm not positive, now that you have me questioning my own memory, but I'm *pretty* sure pitti removed some series' in the past and shrunk those things.
<infinity> (And maybe he did some surgery along the way to make that less destructive, I dunno, perhaps an email to him might let him swap in context from years ago and a past life)
<vorlon> infinity: right, it's quite possible he did and I don't remember; I just don't see an obvious way for him to have done this without it having caused us to lose results we care about (or, leaving unreferenced clutter in swift)
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (trusty-proposed) [2.4.7-1ubuntu4.21]
<mwhudson> probably new in 0.31.0
<mwhudson> vorlon: so this is invalid in debian too?
<vorlon> mwhudson: yes, but dak fails to block uploads that the code says it should
<xnox> mwhudson, uploaded dh-cargo which will touch that file on clean. this should fix the builds.
<xnox> thus once dh-cargo is out, we would need to retry the "failed" builds.
<mwhudson> xnox: ok
<mwhudson> xnox: i shall whinge in the debian bts
<xnox> but still need tracing who created that file
<vorlon> xnox: do the autobuilders call clean before build?
<xnox> mwhudson, also Jan  1  1970 Cargo.toml
<xnox> vorlon, they must.
<vorlon> must they?
<vorlon> it's supposed to be a no-op on a pristine unpacked source package
<mwhudson> xnox: it's cargo
<vorlon> (and it's often a time-wasting no-op)
<mwhudson> src/cargo/ops/cargo_package.rs
<xnox> mwhudson, i don't know how to edit that extension.... we ought to fix that..... upstream/debian/ubuntu
<infinity> vorlon: sbuild calls dpkg-buildpackage, and doesn't call it with -nc, so yes, they clean.
<vorlon> ok
<xnox> vorlon, many people apply conditional patches in clean for example.
<mwhudson> xnox: turn your head on its side and pretend it's c++
<vorlon> ...
<infinity> vorlon: Also, you might be able to hear me cackling from here about the "and it's supposed to be a no-op".  I mean, I agree with you.  And policy might too (I don't recall), but it's very much not true in many packages. :(
<xnox> mwhudson, ah! simples!
<vorlon> "many fine people"
<infinity> On both sides.
<xnox> policy is vague
<xnox> "The build target may need to run the clean target first - see below."
<xnox> so it's a may
<mwhudson> vorlon: got a policy reference for why these archives are bad?
<xnox> mwhudson, only code check in dak and launchpad.
<xnox> upon binary uploads.
<vorlon> mwhudson: none whatsoever
<mwhudson> except apparently not dak any more
<infinity> mwhudson: The range check isn't from policy, it was a dak check cargo-culted into soyuz.
<xnox> mwhudson, the code that supposed to do that reject, is still in dak.
<infinity> It's generally considered a "good" check, but not a Policy thing.
<mwhudson> oh so this is a cargo bug _and_ a dak bug
<infinity> Well, the dak bug is either that it's checking something policy doesn't forbid, or that the check is currently not working.
<infinity> Take your pick. :P
<infinity> Arguably, "crazy dates on files" is a check that belongs deeper in the stack (like sbuild, or dpkg itself), and it should never make it to a queue.
<vorlon> I took the question to #debian-ftp at cjwatson's suggestion, and no one there knew why the check was giving false negatives either
<infinity> And the reason had something to do with certain tar implementations losing their minds on large stamp skews or something.
<infinity> Cause they were written by muppets who didn't actually deal with timestamps correctly, but just did some vague windowing.
<infinity> Or something.
<infinity> *handwavy*
<infinity> I doubt any of that matters in the modern world.
<infinity> But I still don't need random files with timestamps of "0"... It looks like something broken software would produce.
<infinity> And would trip my internal "I wonder if a rootkit did this" alarm.
<vorlon> that's why my rootkits use a timestamp of 5
<infinity> Good thinking.
<infinity> You get a passwd file.
<infinity> I'll keep shadow for myself until you use a more random timestamp.
<mwhudson> https://github.com/rust-lang/cargo/issues/4712
<gitbot> rust-lang issue 4712 in cargo "crates produced by cargo have errors in them" [Closed]
<vorlon> (except for my embedded test SSL certificates, which use a timestamp in the future)
<jbicha> infinity: Debian bug 910883
<ubot5> Debian bug 910883 in src:rust-serde "rust-serde: ancient timestamp" [Normal,Open] http://bugs.debian.org/910883
<mwhudson> xnox: i hope you mutate the timestamp to DEBIAN_SOURCE_EPOCH
<xnox> mwhudson, hmmmm......
<xnox> no
<mwhudson> xnox: reproducible builds will be after you!!
<xnox> mwhudson, also the cargo issue you indicate is about the .tar file payload. not the timestamp of a file inside the tarball....
<xnox> mwhudson, or is this the same?
<mwhudson> jbicha: oh man that respose
<mwhudson> xnox: well the issue that i pasted is that it was writing the 0 timestamp incorrectly
<xnox> ah, fun.
<mwhudson> uhh https://salsa.debian.org/lintian/lintian/commit/19e46f861e1e23568812cd3437c718748c91d918
<mwhudson> well this is quite the can of worms
<xnox> mwhudson, and dak doesn't use built-in rejects anymore, and uses lintian autorejects instead, which launchpad does not have?
<xnox> vorlon, do we need launchpad lintian autorejects?
<vorlon> well clearly we don't need them, we've survived this long
<xnox> vorlon, reject uploads with missing +x comes to mind
<xnox> we didn't fix merge-o-matic, have we?!
<mwhudson> i tried
<vorlon> xnox: wasn't mwhudson hacking on that?
<mwhudson> well dak certainly still has code to reject timestamps from before 1975
<mwhudson> unless the configuration for Dinstall::PastCutoffYear is overriding it
<xnox> and it has the acient files thing as a lintian autoreject.
<mwhudson> yes but as above lintian has a special case for these files now
<infinity> I still don't grasp why cargo is intentionally setting those timestamps to 0 instead of 'now'.  How bizarre.
<xnox> mwhudson, can you check what timestamps are inside the actual debs?
<xnox> mwhudson, i wonder if debian overrides timestamps of files inside the deb, and we don't.
<mwhudson> xnox: you can read it at the end of https://buildd.debian.org/status/fetch.php?pkg=rust-lazy-static&arch=amd64&ver=1.2.0-1&stamp=1543326124&raw=0
<mwhudson> xnox: nope
<mwhudson> (search for "1970")
<infinity> Well, I see why cargo is doing it, I don't see why the people who wrote cargo wanted that.
 * xnox DDoS build queue
<xnox> well, only 75 builds to be fair.
<xnox> mwhudson, i retried all that "Failed to upload"
<mwhudson> xnox: nice
-queuebot:#ubuntu-release- New binary: rust-arc-swap [s390x] (disco-proposed/universe) [0.3.5-1] (no packageset)
 * mwhudson is still confused as to where to report the bug in debian
<xnox> hmmmm
<xnox> somehow it didn't find to retry all the things
-queuebot:#ubuntu-release- New binary: rust-arc-swap [i386] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-yaml-rust [s390x] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-uuid [s390x] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arc-swap [amd64] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [i386] (disco-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [amd64] (disco-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-yaml-rust [i386] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lock-api [i386] (disco-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-uuid [amd64] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-test [i386] (disco-proposed/universe) [1.0.80-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-yaml-rust [amd64] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-lock-api [i386] (disco-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-subtle [amd64] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-uuid [amd64] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New binary: rust-grep-matcher [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde-test [i386] (disco-proposed) [1.0.80-1]
-queuebot:#ubuntu-release- New: accepted rust-yaml-rust [amd64] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-subtle [i386] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: rust-lock-api [amd64] (disco-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted elogind [amd64] (disco-proposed) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1]
-queuebot:#ubuntu-release- New: accepted elogind [ppc64el] (disco-proposed) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1]
-queuebot:#ubuntu-release- New: accepted rust-arc-swap [amd64] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-arc-swap [s390x] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-yaml-rust [i386] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted elogind [i386] (disco-proposed) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1]
-queuebot:#ubuntu-release- New: accepted rust-arc-swap [i386] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-yaml-rust [s390x] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted elogind [s390x] (disco-proposed) [239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1]
-queuebot:#ubuntu-release- New: accepted rust-uuid [s390x] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New binary: rust-bytecount [s390x] (disco-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-uuid [i386] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [i386] (disco-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [amd64] (disco-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-bytecount [amd64] (disco-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-uuid [i386] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [i386] (disco-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [s390x] (disco-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lock-api [amd64] (disco-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-matcher [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-atlatl [amd64] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-buffer [amd64] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [amd64] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blobby [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-matcher [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-buffer [i386] (disco-proposed/universe) [0.7.0-1] (no packageset)
<xnox> mwhudson, but i guess i will have to retry all the Dependency Wait and Fail to build too.....
-queuebot:#ubuntu-release- New binary: rust-atlatl [i386] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-http [i386] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blobby [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
<xnox> cause some of FTB are actually dep-wait....
<xnox> but probably after this round of rust-* finishes building and publishing
<xnox> anyway Zzzzzzz
<mwhudson> well the depwaits will sort themselves sooner or later
-queuebot:#ubuntu-release- New binary: rust-atlatl [s390x] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-buffer [s390x] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-http [amd64] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blobby [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [i386] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [s390x] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-matcher [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-http [s390x] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [amd64] (disco-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atlatl [ppc64el] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-buffer [ppc64el] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [ppc64el] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-http [ppc64el] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blobby [armhf] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atlatl [arm64] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-blobby [arm64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atlatl [armhf] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [arm64] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-digest [armhf] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netperfmeter [amd64] (disco-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [amd64] (disco-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [i386] (disco-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [s390x] (disco-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [ppc64el] (disco-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shellia [amd64] (disco-proposed/none) [5.1] (no packageset)
-queuebot:#ubuntu-release- New binary: arm-trusted-firmware [arm64] (disco-proposed/universe) [2.0+290.98aab974-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [armhf] (disco-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-rational [arm64] (disco-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pg-rational [arm64] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted pg-rational [armhf] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted arm-trusted-firmware [arm64] (disco-proposed) [2.0+290.98aab974-2]
-queuebot:#ubuntu-release- New: accepted pg-rational [ppc64el] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted shellia [amd64] (disco-proposed) [5.1]
-queuebot:#ubuntu-release- New: accepted pg-rational [i386] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted pg-rational [s390x] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted netperfmeter [amd64] (disco-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [arm64] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-blobby [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-block-buffer [ppc64el] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [armhf] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http [ppc64el] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted pg-rational [amd64] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-blobby [armhf] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [ppc64el] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [armhf] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [arm64] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [ppc64el] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-blobby [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [amd64] (disco-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [s390x] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http [amd64] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [s390x] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [i386] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http [s390x] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-block-buffer [s390x] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-matcher [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [amd64] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-blobby [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-block-buffer [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-digest [amd64] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http [i386] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-atlatl [i386] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-block-buffer [i386] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-blobby [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-matcher [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [s390x] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [amd64] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [ppc64el] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [arm64] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [i386] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-searcher [armhf] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: usbmuxd (bionic-proposed/main) [1.1.0-2build1 => 1.1.0-2ubuntu0.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [arm64] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [i386] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [armhf] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [amd64] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [s390x] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-grep-searcher [ppc64el] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New binary: rust-rustc-version [amd64] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustc-version [s390x] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustc-version [ppc64el] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustc-version [i386] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rustc-version [amd64] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-rustc-version [ppc64el] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-rustc-version [i386] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-rustc-version [s390x] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New binary: rust-shellwords [ppc64el] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shellwords [s390x] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shellwords [i386] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shellwords [amd64] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shellwords [armhf] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-regex [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-grep-regex [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-shellwords [armhf] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shellwords [ppc64el] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: rust-grep-regex [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-regex [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-shellwords [amd64] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shellwords [s390x] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shellwords [i386] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: rust-grep-regex [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-grep-regex [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-regex [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-regex [i386] (disco-proposed) [0.1.1-1]
<LocutusOfBorg> infinity, feeling lintian syncy?
-queuebot:#ubuntu-release- New binary: rust-failure [s390x] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure [ppc64el] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure [amd64] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure [i386] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [arm64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-printer [armhf] (disco-proposed/universe) [0.1.1-1] (no packageset)
<oSoMoN> my libreoffice 1:6.0.7-0ubuntu0.18.04.2 upload to bionic-proposed was rejected because the changelog entry didn't mention a SRU bug, but that was intended to fix 1:6.0.7-0ubuntu0.18.04.1 which fails to build because of an openjdk update, and is the real SRU (and has a bug reference in its changelog)
<oSoMoN> how should I go about fixing that?
<oSoMoN> do I need to merge the two changelog entries into one?
<oSoMoN> when IÂ uploaded 1:6.0.7-0ubuntu0.18.04.1 it would build just fine, but it sat for a long time in the unapproved queue and when it got accepted the openjdk update had been published in the meantime, prompting that follow-up upload
<cjwatson> Why not just mention the bug number again?
<oSoMoN> yes I can do that for sure, but it feels like unnecessary paperwork, given that the bug number is in the changelog already, so I was wondering whether there was a way out that didn't involve yet another upload
<LocutusOfBorg> speaking of libreoffice... is anybody looking at failures in disco?
<LocutusOfBorg> I fixed gdal, so the remaining points for poppler transition are xpdf and libreoffice not building on amd64
<oSoMoN> LocutusOfBorg, I am
<oSoMoN> hoping to figure out the unit test failures today
<LocutusOfBorg> thanks!
<LocutusOfBorg> and speaking wrt okular failures, that will hold poppler transition...
<LocutusOfBorg> novaclient.exceptions.Forbidden: Quota exceeded for cores: Requested 1, but already used 50 of 50 cores (HTTP 403) (Request-ID: req-06c9d47c-0629-45fb-a19e-8808adcfe3ae)
<LocutusOfBorg> ERROR (Forbidden): Quota exceeded for cores: Requested 1, but already used 50 of 50 cores (HTTP 403) (Request-ID: req-06c9d47c-0629-45fb-a19e-8808adcfe3ae)
<LocutusOfBorg> is there anything we can do?
<LocutusOfBorg> the package is regressed in release too
<LocutusOfBorg> acheronuk, ^^ maybe you have some hint wrt that failure
<seb128> oSoMoN, did you use -v to include the previous changelog entry in the .changes?
<seb128> oSoMoN, seems not from looking at the version in the rejected queue
<oSoMoN> seb128, no, I didn't, didn't think of doing that
<seb128> oSoMoN, if you don't do that then the system only sees the most recent entry and has no bug reference matching the SRU which means the tools can't track what bug needs to be marked verified etc
-queuebot:#ubuntu-release- Unapproved: ceph (cosmic-proposed/main) [12.2.4-0ubuntu1.1build1 => 13.2.1+dfsg1-0ubuntu2.18.10.1] (desktop-core, ubuntu-server)
<seb128> or at least I think it's not smart enough to deal with it
<seb128> so yeah, either merge the entries or use -v to include the previous one
<oSoMoN> seb128, ack, thanks for the tip!
<seb128> np!
-queuebot:#ubuntu-release- New: accepted rust-failure [amd64] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-failure [ppc64el] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [armhf] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-failure [i386] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-failure [s390x] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-printer [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.5 => 4.0.0-1ubuntu8.6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (cosmic-proposed/main) [4.6.0-2ubuntu3 => 4.6.0-2ubuntu3.1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.8 => 1:2.11+dfsg-1ubuntu7.9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (cosmic-proposed/main) [1:2.12+dfsg-3ubuntu8.1 => 1:2.12+dfsg-3ubuntu8.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [s390x] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [amd64] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [ppc64el] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crates-io [s390x] (disco-proposed/universe) [0.19.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-parking-lot-core [s390x] (disco-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustfix [s390x] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-extprim [s390x] (disco-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustfix [ppc64el] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crates-io [ppc64el] (disco-proposed/universe) [0.19.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-extprim [ppc64el] (disco-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-opener [s390x] (disco-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [arm64] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-extprim [i386] (disco-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-parking-lot-core [ppc64el] (disco-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-opener [ppc64el] (disco-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [i386] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cssparser-macros [ppc64el] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cssparser-macros [amd64] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-threadpool [armhf] (disco-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crates-io [amd64] (disco-proposed/universe) [0.19.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cssparser-macros [s390x] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-codec [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crates-io [i386] (disco-proposed/universe) [0.19.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-codec [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustfix [i386] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cssparser-macros [i386] (disco-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-h2 [ppc64el] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2 [ppc64el] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-error-chain [i386] (disco-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tls-parser [i386] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rustfix [amd64] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-extprim [amd64] (disco-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hyphenation-commons [amd64] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2 [amd64] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tls-parser [amd64] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-h2 [amd64] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2 [i386] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hyphenation-commons [ppc64el] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-error-chain [amd64] (disco-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-h2 [i386] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-codec [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2-curl [ppc64el] (disco-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hyphenation-commons [i386] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2-curl [amd64] (disco-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2-curl [i386] (disco-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-codec [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-error-chain [s390x] (disco-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-h2 [s390x] (disco-proposed/universe) [0.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2 [s390x] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2-curl [s390x] (disco-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tls-parser [s390x] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hyphenation-commons [s390x] (disco-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-error-chain [amd64] (disco-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-extprim [amd64] (disco-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-git2-curl [i386] (disco-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted rust-git2-curl [s390x] (disco-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted rust-h2 [s390x] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-hyphenation-commons [s390x] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2 [s390x] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-codec [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-error-chain [s390x] (disco-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-git2-curl [ppc64el] (disco-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hyphenation-commons [i386] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tls-parser [s390x] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-git2-curl [amd64] (disco-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2 [i386] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-h2 [i386] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-codec [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crates-io [amd64] (disco-proposed) [0.19.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cssparser-macros [i386] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-error-chain [i386] (disco-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-h2 [ppc64el] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-hyphenation-commons [ppc64el] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rustfix [i386] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2 [ppc64el] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tls-parser [i386] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-codec [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crates-io [i386] (disco-proposed) [0.19.0-1]
-queuebot:#ubuntu-release- New: accepted rust-h2 [amd64] (disco-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New: accepted rust-rustfix [amd64] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-tls-parser [amd64] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [armhf] (disco-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-cssparser-macros [s390x] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2 [amd64] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hyphenation-commons [amd64] (disco-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-codec [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crates-io [ppc64el] (disco-proposed) [0.19.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cssparser-macros [amd64] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-extprim [i386] (disco-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-extprim [s390x] (disco-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-opener [s390x] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-parking-lot-core [s390x] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rustfix [s390x] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [arm64] (disco-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [ppc64el] (disco-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-crates-io [s390x] (disco-proposed) [0.19.0-1]
-queuebot:#ubuntu-release- New: accepted rust-extprim [ppc64el] (disco-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-parking-lot-core [ppc64el] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [amd64] (disco-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [s390x] (disco-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-cssparser-macros [ppc64el] (disco-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rustfix [ppc64el] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-opener [ppc64el] (disco-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-threadpool [i386] (disco-proposed) [0.1.7-1]
<LocutusOfBorg> any AA around?
<LocutusOfBorg> I see this big hint: Trying easy from autohinter: avogadro/1.2.0-4build1 bino/1.6.6-3build2 blender/2.79.b+dfsg0-4build2 bzflag/2.4.18-1build1 cegui-mk2/0.8.7-2build2 choreonoid/1.5.0+dfsg-0.1build5 colmap/3.5-1build1 colobot/0.1.11.1-5build1 darkradiant/2.6.0-3build1 ddnet/11.5-1build1 dreamchess/0.2.1-RC2-2build2 endless-sky/0.9.8-1build1 fife/0.4.1+git20180904-2build2 freeorion/0.4.8-1build1 frogatto/1.3.1+dfsg-4build3
<LocutusOfBorg> gambas3/3.11.4-6 gem/1:0.93.3-18build1 gimp-normalmap/1.2.3-0ubuntu6 glew/2.1.0-2 gource/0.49-1build1 hugin/2018.0.0+dfsg-3build1 imagevis3d/3.1.0-7build1 info-beamer/1.0~pre3+dfsg-0.1build4 k3d/0.8.0.6-8build1 kicad/5.0.1+dfsg1-3build1 limesuite/18.06.0+dfsg-1build1 logstalgia/1.1.0-2build1 mediastreamer2/1:2.16.1-4build1 megaglest/3.13.0-2build2 meshlab/1.3.2+dfsg1-4build1 mupen64plus-video-z64/2.0.0+13+g72af4f0-6build1
<LocutusOfBorg> mygui/3.2.2+dfsg-2build1 openclonk/8.1-1build1 opencsg/1.4.2-1ubuntu2 openctm/1.0.3+dfsg1-2build1 openimageio/1.7.17~dfsg0-1ubuntu6 openmsx/0.14.0-2.1build1 otb/6.6.0+dfsg-5build1 paraview/5.4.1+dfsg4-3.1build2 phlipple/0.8.5-4build1 projectm/2.1.0+dfsg-4build2 pymol/2.2.0+dfsg-1build1 qutemol/0.4.1~cvs20081111-9build1 rbdoom3bfg/1.2.0+dfsg~git20180605-1build1 renpy/7.1.1+dfsg-1build1 rlvm/0.14-3build1 rss-glx/0.9.1-6.1ubuntu
<LocutusOfBorg> 3 scorched3d/44+dfsg-3build1 slic3r-prusa/1.39.2+dfsg-1build3 slop/7.4-1build2 sludge/2.2.2-1build1 sofa-framework/1.0~beta4-12build1 solvespace/2.3+repack1-3build1 spring/104.0+dfsg-3build1 supertux/0.5.1-1build3 trigger-rally/0.6.5+dfsg-3build2 vtk7/7.1.1+dfsg1-10ubuntu1 warzone2100/3.2.1-3build2 widelands/1:19+repack-6build1
<LocutusOfBorg> is only blocked by gambas3 being entangled with poppler
<LocutusOfBorg> can we please kick gambas3 out of release for some days in the meanwhile I finish to polish up things?
<LocutusOfBorg> apw, ^^ gambas3 has been reintroduced 2 weeks ago by me :)
<LocutusOfBorg> this should disentangle things a little bit, and make me more confident about what britney is saying to me
<apw> LocutusOfBorg, so you did, so you are going to sort that out and get it back out "soon" if i do that
<LocutusOfBorg> yes, of course, it will migrate together with poppler transition
<LocutusOfBorg> it is not blocked by anything else
<apw> LocutusOfBorg, ok ... gone
<LocutusOfBorg> ta!
<LocutusOfBorg> now gdcm entangles with everything else sigh
<LocutusOfBorg> sigh2 I looked at notest, we need perl migrate to see it go
<LocutusOfBorg> at least I need somebody bumping force-badtest perl/5.28.0-3 to force-badtest perl/5.28.0-4
<apw> LocutusOfBorg, the failure in -3 differs from that in -4 to an extent i am not comfortable bumping that along the road
<apw> vorlon, ^ that perl dependency (on prove) seems to have gotten fixed, dunno if you wanna look see if the new failure is related or not
<apw> (i suspect it is not)
<LocutusOfBorg> I looked at the "command1" test of both -3 and -4 before requesting it here, and I see they looks the same, but meh, I don't understand TBH
<apw> LocutusOfBorg, the -3 says 'prove: comamnd not found' and -4 has a single test failure
-queuebot:#ubuntu-release- New binary: rust-grep-cli [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-cli [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
<LocutusOfBorg> apw, did you look at the result of 5.28.0-3	dpkg/1.19.2ubuntu1	?
-queuebot:#ubuntu-release- New binary: rust-grep-cli [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-cli [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
<LocutusOfBorg> apw, what I'm saying is that the -3 is having that test failure since a month or so
<acheronuk> LocutusOfBorg: looking at okular. my 1st test locally passed the test failing on our infra, but failed on another. so fun!
-queuebot:#ubuntu-release- Unapproved: libgweather (bionic-proposed/main) [3.28.1-1 => 3.28.2-1~ubuntu18.04.1] (ubuntu-desktop)
<apw> LocutusOfBorg, and if the symptom on -4 was the same i would hint it in a second
<apw> LocutusOfBorg, as it isn't i'd like a second oppinion from someone who likes perl (which might be noone)
<LocutusOfBorg> apw, look at:
<LocutusOfBorg> 5.28.0-3	perl/5.28.0-3	2018-11-04 07:25:07 UTC	0h 11m 20s	-	fail	log â artifacts â
<LocutusOfBorg> and .28.0-3	perl/5.28.0-3 gdbm/1.18.1-1	2018-11-06 21:04:30 UTC	0h 13m 03s	vorlon	fail	log â artifacts â â»
<LocutusOfBorg> they have the same perl version but different behavior
<LocutusOfBorg> "prove: command not found" was actually hiding the fact that with prove installed the test fails
<Laney> we could try to fix it, that'd be nice
<Laney> instead of arguing about why not to
<LocutusOfBorg> I don't get what the test does...
<LocutusOfBorg> libextutils-parsexs-perl is out of ubuntu...
<LocutusOfBorg> moreover, fixing the test will require a new ton of tests...
-queuebot:#ubuntu-release- New binary: rust-grep-cli [arm64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep-cli [armhf] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [armhf] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep-cli [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- Unapproved: fontconfig (bionic-proposed/main) [2.12.6-0ubuntu2 => 2.12.6-0ubuntu2.3] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1034.35~14.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1034.35~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1034.35] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1034.35]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1034.35~14.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1034.35~16.04.1]
<xnox> mwhudson, would you be able to look into go things stuck in disco-proposed? e.g. prometheus and friends
-queuebot:#ubuntu-release- Unapproved: tomcat8 (xenial-proposed/main) [8.0.32-1ubuntu1.8 => 8.0.32-1ubuntu1.9] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New sync: placement (disco-proposed/primary) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-grep [s390x] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [ppc64el] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [arm64] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [armhf] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [amd64] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [i386] (disco-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-grep [amd64] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [i386] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [armhf] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [arm64] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [s390x] (disco-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [ppc64el] (disco-proposed) [0.2.3-1]
<vorlon> apw, LocutusOfBorg: the new perl failure is not related; the 'prove' failure was transient while perl was in transition in -proposed
<LocutusOfBorg> vorlon, do we agree that is regressed in release?
-queuebot:#ubuntu-release- New binary: rust-encoding [s390x] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hwdata [source] (xenial-proposed) [0.267-1ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-encoding [ppc64el] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding [amd64] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding [armhf] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding [i386] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding [arm64] (disco-proposed/universe) [0.2.33-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-encoding [arm64] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding [i386] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding [amd64] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding [ppc64el] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding [armhf] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding [s390x] (disco-proposed) [0.2.33-1]
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [s390x] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (trusty-proposed) [0.80.11-0ubuntu1.14.04.4]
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [amd64] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [ppc64el] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted usbmuxd [source] (bionic-proposed) [1.1.0-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [i386] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.20]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.20]
-queuebot:#ubuntu-release- Unapproved: accepted fontconfig [source] (bionic-proposed) [2.12.6-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.20 => 2.02~beta2-36ubuntu3.20] (core)
<vorlon> LocutusOfBorg: yes, it's regressed in release, but it's not a regression that I'm willing to manually ignore
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [amd64] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [ppc64el] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [i386] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [s390x] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [armhf] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-fs [arm64] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.20 => 2.02~beta2-36ubuntu3.20] (core)
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [arm64] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-fs [armhf] (disco-proposed) [0.1.3-1]
<vorlon> if someone wanted to make launchpad's depwait analyzer understand versioned provides, that would make rust package builds a lot smoother
<cjwatson> Or Provides at all, IIRC
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/335913
<ubot5> Ubuntu bug 335913 in Launchpad itself "depwait builds do not retry even though the dep can be met via a virtual package" [High,Triaged]
<cjwatson> (if it were just the versioned aspect, that would be relatively simple)
<vorlon> cjwatson: right, wasn't sure :)
<cjwatson> I guess it might be possible without database changes with a sufficiently careful regex query on BinaryPackageRelease.provides ...
<vorlon> now why did rust-core-foundation not autosync?
<cjwatson> vorlon: because you deleted it earlier this month and it hasn't had a new version in Debian (even if it had, it would've required manual attention due to having been previously removed)
<vorlon> ah
<vorlon> :)
 * vorlon resuscitates it because despite being non-migrateable, it's good enough to satisfy other build-dependencies right now :P
<jbicha> vorlon: what do you want to do with debian-edu-artwork-legacy : blacklist it or unblacklist debian-edu-artwork?
<infinity> All the debian-edu stuff was blacklisted as "redundant with edubuntu", which is a product that no longer exists...
<infinity> Maybe we should unblacklist the lot.
-queuebot:#ubuntu-release- Unapproved: py-macaroon-bakery (bionic-proposed/main) [1.1.3-1 => 1.2.1-1~18.04.1] (ubuntu-desktop, ubuntu-server)
<roaksoax> can someone please reject  py-macaroon-bakery from bionic-proposed, i made a mistake uploading it
<infinity> roaksoax: Sure!
<teward> yay for burned version strings though? :P
<infinity> Eh.
<infinity> teward: It's not 'burned' if it's never accepted.
-queuebot:#ubuntu-release- Unapproved: rejected py-macaroon-bakery [source] (bionic-proposed) [1.2.1-1~18.04.1]
<teward> hmm good point heh
<teward> infinity: though i thought it was, i made an unapproved upload once that was not accepted but was sitting in proposed once, by accident, and was told it'd been burned
<teward> :|
<teward> so E:Miscommunication somewhere?
<infinity> teward: proposed = accepted.
<infinity> teward: queue = not accepted.
<teward> ah
<infinity> teward: If it's ever published in the primary archive, the version is burned.
<vorlon> jbicha: will blacklist debian-edu-artwork-legacy, thanks
<infinity> vorlon: See above.  Is the rationale for the blacklist maybe obsolete?
<oSoMoN> bdmurray, I uploaded libreoffice{,-l10n} 6.0.7-0ubuntu0.18.04.3 to bionic-proposed, that includes the previous changelog entries (including the SRU bug number) that were missing in the previous upload, which prompted the rejection. Would you mind taking a look and letting me know whether that's good enough?
<vorlon> infinity: ah, ok, looking deeper
<jbicha> the artwork is harmless (but unlikely to be used really)
<teward> are the armhf and s390x autopkgtest systems overtaxed or is the queue just obscenely long?  (some nginx tests are still isted as in progress but have been for well over a day)
<infinity> teward: Both?
<vorlon> infinity: in general, I think I'm ok with blacklisting of the sorts of metapackages that represent package curation in Debian that don't have input from someone in the Ubuntu community; my overall sense is that they tend to have a high failure rate (dependency skew, etc)
<xnox> teward, look at the running queue for adt?
<teward> tried i'm getting page timeouts.
<jbicha> but debian-edu-config & debian-edu-install may be too disruptive for us
<xnox> teward, =/ not good.
<teward> xnox: no, it's not
<xnox> loads for me fine.... the http://autopkgtest.ubuntu.com/running
<xnox> teward, at one point we lost a queue state; so had to re-request them; hence yes there is a backlog of s390x and armhf things, more than other arches.
<vorlon> s390x queue is exceptionally large, but it's also coming down
<infinity> vorlon: Yeah, not picky.  The stated reason for blacklisting is clearly no longer true, that's all.
<vorlon> so probably a past outage
<vorlon> (yes, possibly that outage in particular, though I don't know any reason s390x would've been more affected)
<bdmurray> oSoMoN: looking
<teward> xnox: that makes sense, it's all those perl things in the queue >.<
<vorlon> teward: looks to me like refreshing that page shows the s390x backlog dropped in half in the past hour
<jbicha> I think s390x was still fairly high (>1000) before the queue disruption
<bdmurray> oSoMoN: You could have reused the same version number i.e. a new changelog entry wasn't necessary.
<oSoMoN> bdmurray, ah, right, because it was rejectedâ¦ IÂ didn't think of that
<bdmurray> oSoMoN: Well because it never made the archive
<oSoMoN> yeah, muscle memory made me bump the version without even thinking about it
<xnox> mwhudson, vorlon - any idea why so many rust things depend on virtual things that are not provided by anybody?
<xnox> as in, did we build all of rust-* out of order now?
<vorlon> xnox: no, blame the Debian maintainers
<vorlon> some of these things have been stuck in Debian NEW due to out-of-order uploads.  Some of them are just not in evidence.  Some of them are build-dependencies on older versions than what is available in -proposed (and unstable)
<vorlon> xnox: once I've worked through rust-cargo and its revdeps, everything that can be built in Debian will also be built in disco
<xnox> vorlon, hm... it did look as if 0.31 transition was started and aborted.
<xnox> vorlon, cause i thought we need 0.31 rust to build 0.31 cargo. but maybe not.
<jbicha> I filed Debian bug 910885 earlier, but I've kinda given up on filing Debian bugs for rust uninstallable issues
<ubot5> Debian bug 910885 in src:rust-pcap "rust-pcap: Unsatisfiable dependencies" [Serious,Open] http://bugs.debian.org/910885
<roaksoax> infinity: thank you!
<jbicha> Debian bug 908364
<infinity> roaksoax: Any time.  Always glad to *not* review something. :P
<ubot5> Debian bug 908364 in librust-nodrop+nodrop-union-dev "librust-nodrop+nodrop-union-dev: unsatisfiable dependency on librust-nodrop-union-0.1+default-dev" [Grave,Open] http://bugs.debian.org/908364
<roaksoax> infinity: :)
-queuebot:#ubuntu-release- New binary: rust-cargo [amd64] (disco-proposed/universe) [0.31.0-1] (no packageset)
<xnox> i guess if you make a new language, and don't break all dependencies conventions... is it even worth trying?!
-queuebot:#ubuntu-release- New binary: rust-cargo [i386] (disco-proposed/universe) [0.31.0-1] (no packageset)
<jbicha> rust is the new nodejs
<vorlon> xnox: well, https://launchpad.net/ubuntu/+source/rust-cargo/0.31.0-1/ built on 2 archs
<xnox> i just envision a year from now, cargo being declared bad and dead, and everything moving to precompiled docker images shipped as flatpacks, with a metadata file to call it rust-freight instead
<bdmurray> oSoMoN: if its not a huge trouble it'd be nice if the changelog was cleaner / the version wasn't bumped since its an LTS
-queuebot:#ubuntu-release- New: accepted rust-cargo [amd64] (disco-proposed) [0.31.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cargo [i386] (disco-proposed) [0.31.0-1]
<oSoMoN> bdmurray, so you would reject and I would re-upload 6.0.7-0ubuntu0.18.04.2 with the changelog entries for 6.0.7-0ubuntu0.18.04.1 and 6.0.7-0ubuntu0.18.04.2 ?
<bdmurray> oSoMoN: Yeah, although the order doesn't matter.
<oSoMoN> bdmurray, ack, will do after dinner
<vorlon> xnox: so, rust-core-foundation is FTBFS on !x86, that's exciting
<vorlon> (and that's reported as Debian bug #906612)
<ubot5> Debian bug 906612 in src:rust-core-foundation "rust-core-foundation FTBFS on architecture where char is unsigned" [Important,Open] http://bugs.debian.org/906612
<sarnold> is that this? "Rust bindings to Core Foundation and other low level libraries on Mac OS X and iOS"
<vorlon> seems so
<ddstreet> bdmurray was there a reason you approved the SRU for hwdata/xenial for lp #1755490 without bionic or cosmic being fixed?
<ubot5> Launchpad bug 1755490 in unity-settings-daemon (Ubuntu Xenial) "Incorrect information about display shown in gnome/unity-control-center" [Undecided,Fix committed] https://launchpad.net/bugs/1755490
<seb128> ddstreet, bionic/cosmic Ubuntu sessions uses GNOME which migrated to use the hwdb from systemd instead of hwdata, we SRUed the change in systemd for those series
<ddstreet> seb128 nobody else will ever use hwdb in bionic/cosmic?
<seb128> I don't know
<ddstreet> seb128 also your uplaod was incomplete
<ddstreet> seb128 you don't mind if i upload to bionic/cosmic as well, and correct the xenial upload do you?
<seb128> sure, feel free
<ddstreet> thnx
<seb128> ddstreet, I was addressing a specific issue which was with the settings panel, I didn't try to fix usecases I don't know about
<ddstreet> seb128 right - but your change to xenial didn't actually change it
<seb128> but yeah, if you want to bother that's fine
<ddstreet> yep i will thnx
<seb128> that comment was about bionic/cosmic
<ddstreet> ah ok sure - IMHO since hwdata is included in b/c, it would be good to fix those as well even if we don't know specifically of someone using the info
<seb128> thx for fixing xenial, I probably overlooked something, I just backported the commit pointed on the bug. I'm going to check what extra you change :)
<seb128> ddstreet, up to you
<seb128> SRUs are resources expensive in review/testing/bandwith so I try to limit mine to fix real user visible issues
<ddstreet> the pnp.ids file is patched from the pnp.ids.patch file, but the pnp.ids file is also carried by the deb and so both the pnps.ids and .patch file need to be updated
<seb128> but I can understand if other don't see it the same way and prefer to include the fix even if it's not having a visible impact for most users
<seb128> ah ok
<seb128> ddstreet, thx :)
<ddstreet> SRU reviews are expensive, yes, but IMHO again that's an issue that is the ubuntu-sru team's own doing...they can add sru approvers at any time
<seb128> they are not the ones testing
<seb128> and when we don't have a good testcase things get non verified
<seb128> and sit in proposed for years
<seb128> and that deserves us
<seb128> anyway
<seb128> that's my position, I'm not trying to enforce it on others
<seb128> so feel free to find a testcase for bionic/cosmic and fix it there :)
<ddstreet> yep :)
-queuebot:#ubuntu-release- Unapproved: hwdata (cosmic-proposed/main) [0.290-1 => 0.290-1ubuntu0.18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: hwdata (bionic-proposed/main) [0.290-1 => 0.290-1ubuntu0.18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: hwdata (xenial-proposed/main) [0.267-1ubuntu1 => 0.267-1ubuntu2] (ubuntu-desktop)
<bdmurray> ddstreet: So are you going to test hwdata in bionic and cosmic?
-queuebot:#ubuntu-release- Unapproved: accepted hwdata [source] (xenial-proposed) [0.267-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted hvac [amd64] (bionic-backports) [0.5.0-0ubuntu1~ubuntu18.04.1]
<ddstreet> bdmurray well 1) it's a plain text file that can be pretty clearly looked at to 'verify' the fix and 2) dgadomski will test/verify, and unless i'm misunderstaning his comment 19 in the bug, hwdata is actually used for the product name even in b/c
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [18.0.5-0ubuntu0~18.04.1 => 18.2.2-0ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted hwdata [source] (bionic-proposed) [0.290-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted hwdata [source] (cosmic-proposed) [0.290-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20180917-2~ubuntu0.18.04.1]
<oSoMoN> bdmurray, can you please reject libreoffice{,-l10n} 6.0.7-0ubuntu0.18.04.3 from the bionic queue? I'll re-upload 6.0.7-0ubuntu0.18.04.2
-queuebot:#ubuntu-release- Unapproved: accepted wayland [source] (cosmic-proposed) [1.16.0-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted wayland [source] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.3]
-queuebot:#ubuntu-release- New binary: wayland [ppc64el] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: wayland [s390x] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: wayland [i386] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: wayland [amd64] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.1 => 1:6.0.7-0ubuntu0.18.04.2] (ubuntu-desktop)
<oSoMoN> bdmurray, thanks!
-queuebot:#ubuntu-release- New binary: wayland [armhf] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: wayland [arm64] (bionic-proposed/main) [1.16.0-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted wayland [amd64] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [armhf] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [ppc64el] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [arm64] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [s390x] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [i386] (bionic-proposed) [1.16.0-1ubuntu1.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [18.2.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: ruby-icalendar [amd64] (disco-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mesa [amd64] (bionic-proposed/main) [18.2.2-0ubuntu1~18.04.1] (core, xorg)
<mwhudson> xnox: well rustc and cargo are going to be kept up to date because firefox
<mwhudson> the crazy world of rust-* packages, well <raspberry noise> to all that
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New binary: mesa [armhf] (bionic-proposed/main) [18.2.2-0ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: vaultlocker [amd64] (bionic-backports/universe) [1.0.3-0ubuntu1~ubuntu18.04.1] (no packageset)
#ubuntu-release 2018-11-29
-queuebot:#ubuntu-release- New: accepted mesa [amd64] (bionic-proposed) [18.2.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted mesa [armhf] (bionic-proposed) [18.2.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: hunspell [ppc64el] (disco-proposed/main) [1.7.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: hunspell [s390x] (disco-proposed/main) [1.7.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: hunspell [amd64] (disco-proposed/main) [1.7.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: hunspell [arm64] (disco-proposed/main) [1.7.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: hunspell [armhf] (disco-proposed/main) [1.7.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: hunspell [i386] (disco-proposed/main) [1.7.0-2] (desktop-core)
<RAOF> tsimonq2: You might also enjoy the new yaml-cpp symbols file!
<xnox> vorlon, surely we shouldn't need rust-core-foundation like at all. or like not on most arches.
<rbalint> sil2100: i'm still in the process of converting ~30 fixed bugs to have sru template but could you please accept u-u to xenial-proposed? the upload is what gets into xenial sooner or later and giving it more time in -proposed gets us more feedback from users
<rbalint> sil2100: the delta to xenial is huge but to bionic it is minimal
<LocutusOfBorg> infinity, I forwarded to lintian developers your lintian fix <3 https://salsa.debian.org/lintian/lintian/merge_requests/79
<gitbot> lintian issue (Merge request) 79 in lintian "* Fix two typos introduced when parameterising test architectures in:" [Opened]
<rbasak> sil2100 isn't here?
<infinity> LocutusOfBorg: I already filed a bug with the patch.
<infinity> LocutusOfBorg: But I guess the MP works too.  We'll see which they see first. :P
<LocutusOfBorg> infinity, I'm in contact with lamby on #debian-qa, this is why I did the PR :)
<LocutusOfBorg> and I updated it with the closed bug!
<LocutusOfBorg> jrtc27 did a MR with the other ubuntu delta, this is why I opened one
-queuebot:#ubuntu-release- New binary: gdcm [s390x] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdcm [ppc64el] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New: accepted hunspell [amd64] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted hunspell [armhf] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted hunspell [ppc64el] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-icalendar [amd64] (disco-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted hunspell [arm64] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted hunspell [s390x] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted hunspell [i386] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New binary: gdcm [arm64] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdcm [armhf] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdcm [i386] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdcm [amd64] (disco-proposed/universe) [2.8.8-5] (kubuntu)
-queuebot:#ubuntu-release- New: accepted gdcm [amd64] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- New: accepted gdcm [armhf] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- New: accepted gdcm [ppc64el] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- New: accepted gdcm [arm64] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- New: accepted gdcm [s390x] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- New: accepted gdcm [i386] (disco-proposed) [2.8.8-5]
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu2.5 => 2:4.7.6+dfsg~ubuntu-0ubuntu2.6] (core)
<LocutusOfBorg> tjaalton, any reason for mesa using gcc-7?
<LocutusOfBorg> https://packages.qa.debian.org/g/gcc-8/news/20181123T092059Z.html
<LocutusOfBorg> the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 is in gcc-8 version 8.2.0-10
<ubot5> gcc.gnu.org bug 87859 in tree-optimization "store-merging miscompilation of mesa" [Normal,Resolved: fixed]
<tjaalton> LocutusOfBorg: look at the bug
<tjaalton> ha
<tjaalton> *ah
<tjaalton> yes it's fixed in gcc now
<tjaalton> 18.3 will build with gcc8 again
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (cosmic-proposed) [1:2.12+dfsg-3ubuntu8.2]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.9]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (cosmic-proposed) [4.6.0-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.6]
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.2-0ubuntu1.1 => 1:6.1.3-0ubuntu0.18.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.2-0ubuntu1 => 1:6.1.3-0ubuntu0.18.10.1] (ubuntu-desktop)
<LocutusOfBorg> thanks tjaalton :)
<acheronuk> still on cosmic http://qa.ubuntuwire.org/ftbfs/
<acheronuk> wgrant: ? ^
-queuebot:#ubuntu-release- Unapproved: rdma-core (bionic-proposed/main) [17.1-1 => 17.1-1ubuntu0.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rdma-core (cosmic-proposed/main) [19.0-1 => 19.0-1ubuntu0.1] (desktop-core, ubuntu-server)
<vorlon> xnox: well, rust-core-foundation doesn't build on !x86 currently, so we effectively have that.  But if you have opinions on whether rust-cargo shouldn't build-depend on it on !x86, you'll need to follow up with the Debian maintainers
<xnox> vorlon, re-check rust-cargo
<vorlon> k
<xnox> vorlon, i made it build without core-foundation, but it generates non-existant dependencies on a newer (?!) rust-openssl
<vorlon> xnox: btw I looked more closely at LP: #1797335, and in my test environment I'm running on a chip that doesn't have avx2.  So maybe it's the avx implementation that's pessimized?
<ubot5> Launchpad bug 1797335 in glibc (Ubuntu) "strstr() on ubuntu18.04 8 times slower than on ubuntu16" [Undecided,New] https://launchpad.net/bugs/1797335
<xnox> vorlon, retest on a c5 instance in aws?
<xnox> i think my other laptop has avx2 can't remember. and have things to do before eod.
-queuebot:#ubuntu-release- New source: fwupd-snap (disco-proposed/primary) [1.0]
<vorlon> "Hello î¿, or anyone else affected,"
 * vorlon looks askance at cpaelzer
-queuebot:#ubuntu-release- New binary: rust-debcargo [amd64] (disco-proposed/universe) [2.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [i386] (disco-proposed/universe) [2.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [armhf] (disco-proposed/universe) [2.2.9-1] (no packageset)
<doko> vorlon: please update ubuntu-release:force-badtest python-scipy/1.1.0-1ubuntu2/i386  to -2
-queuebot:#ubuntu-release- New: accepted rust-debcargo [amd64] (disco-proposed) [2.2.9-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [i386] (disco-proposed) [2.2.9-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [armhf] (disco-proposed) [2.2.9-1]
<xnox> do i want to know what mbrola is? and why does it trigger hundreds of tests for individual langauges?!
<ginggs> sounds like a deadly virus
<teward> heh
<teward> xnox: multilingual speech synthesizer according to the LP data on it
<teward> ... which explains why it's touching every language there heh
<vorlon> I wonder what its tests look like
<vorlon> is autopkgtest launching mechanical turk requests?
<ginggs> would someone please kick the scipy can along? 'force-badtest python-scipy/1.1.0-2/i386'
<ginggs> and 'force-badtest r-bioc-biocparallel/1.16.1-1/s390x r-bioc-biocparallel/1.16.1-1/armhf' too?
<vorlon> ginggs: doko asked for scipy just above; I'm looking at it now
<ginggs> vorlon: ah, missed that, thanks
<NCommander> rbasak, ping, we're getting ready to upload the SRU for certbot, it's seven packages. Four new, one update, and then compatibility shims for the existing letsencrypt package so legacy code and plugins don't break.
<rbasak> NCommander: it might be easier to review from wherever you're managing it (git?) rather than from the queue given the complexity involved.
<NCommander> rbasak, it's sitting in a PPA
<rbasak> I can review from there.
<NCommander> I had to do entirely new packaging as I had to change the packages to use python 2.7 vs. 3
<rbasak> Once reviewed I only have to check it's identical when it hits the queue.
<NCommander> rbasak, Ok, there's one mistake in the PPA regarding versioning I was going to fix (I uploaded python-acme with the wrong version number)
<NCommander> rbasak, https://launchpad.net/~certbot/+archive/ubuntu/xenial-sru/+packages
<rbasak> NCommander: actually do you have it broken down further (individual commits) so I don't have to review a big blob of diff?
<NCommander> rbasak, no, these are all new upstream versions
<NCommander> python-letsencrypt/letsencrypt-apache got replaced with compatibility shims
<vorlon> so why is this certbot SRU going to work better than the last one that sat for over a year without verification?
<NCommander> certbot-* are backports
<rbasak> vorlon: the previous one essentially failed verification.
<vorlon> ah, doesn't appear that was ever noted in the bug tags
<rbasak> I gave up as I timeboxed it twice and ran out of time twice. I felt it was too complex and a snap would be better, which is why I have a snap ready.
<vorlon> right
<rbasak> However I've always said that this doesn't block someone else working on SRUs, and NCommander volunteered.
<vorlon> so why is the next one different
<rbasak> I presume he's fixed the issues identified in my attempt.
<NCommander> vorlon, because we don't want letsencrypt to stop working in Feb
<rbasak> I didn't consider that I'd be the one ending up reviewing this anyway :-/
<NCommander> rbasak, I actually didn't see why your attempt failed in the bug.
<rbasak> NCommander: one of the uploads FTBFS
<rbasak> Because a build dep shifted by the SRU itself, IIRC.
<NCommander> If I have it building in a PPA, it should build properly, no?
 * NCommander also does some of the "official" PPA uploads so I'm pretty good at nursing this stuff at this point
<NCommander> rbasak, sorry for giving you a painful SRU but I do think it's important that we get this SRUed as not everyone installs snaps and LE breaking would be bad for the Internet
<rbasak> NCommander: thanks. I'll review, but it'll probably be next week at the earliest.
<NCommander> rbasak, that's fine, the LE team is reviewing to make sure they're compatibility shims and everything are working as expected so it's not quite ready for uploading but the packaging should be good to go.
<NCommander> rbasak, this should also simplify future backports as the SRU will handle the migration to the new name.
-queuebot:#ubuntu-release- Unapproved: ark (cosmic-proposed/universe) [4:18.04.3-0ubuntu1 => 4:18.08.3-1ubuntu1] (kubuntu)
<NCommander> mdeslaur, after we get the SRU landed, we'll look at security pocket :)
<acheronuk> please reject ark ^^^
-queuebot:#ubuntu-release- Unapproved: rejected ark [source] (cosmic-proposed) [4:18.08.3-1ubuntu1]
<apw> acheronuk, ^
<acheronuk> apw: thanks. I must pay more attention to what branch I am on!
<mdeslaur> NCommander: sounds like a good plan
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [179-1 => 183-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [178-1~ubuntu18.04.1 => 183-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [183-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [183-1~ubuntu18.04.1]
<doko> finally, java-common migrated
-queuebot:#ubuntu-release- New binary: hgsubversion [amd64] (disco-proposed/universe) [1.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [ppc64el] (disco-proposed/universe) [0.5.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [ppc64el] (disco-proposed/universe) [2.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [s390x] (disco-proposed/universe) [0.5.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [s390x] (disco-proposed/universe) [2.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [i386] (disco-proposed/universe) [0.5.11-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted hgsubversion [amd64] (disco-proposed) [1.9.3-1]
-queuebot:#ubuntu-release- New binary: baresip [amd64] (disco-proposed/universe) [0.5.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [i386] (disco-proposed/universe) [2.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted baresip [amd64] (disco-proposed) [0.5.11-2]
-queuebot:#ubuntu-release- New: accepted baresip [ppc64el] (disco-proposed) [0.5.11-2]
-queuebot:#ubuntu-release- New: accepted hypre [i386] (disco-proposed) [2.15.1-2]
-queuebot:#ubuntu-release- New: accepted hypre [s390x] (disco-proposed) [2.15.1-2]
-queuebot:#ubuntu-release- New: accepted baresip [i386] (disco-proposed) [0.5.11-2]
-queuebot:#ubuntu-release- New: accepted hypre [ppc64el] (disco-proposed) [2.15.1-2]
-queuebot:#ubuntu-release- New: accepted baresip [s390x] (disco-proposed) [0.5.11-2]
#ubuntu-release 2018-11-30
<cpaelzer> vorlon: I see this thing hates unicode :-)
<cpaelzer> I can drop my beloved ubuntu logo if it really is a problem :-/
<cpaelzer> do I have to?
<cpaelzer> Hmm - I have a leading and a trailing unicode sig, lets drop the leading one if that makes tools at least say "Christian Ehrhardt î¿"
<LocutusOfBorg> yay perl upload!
<LocutusOfBorg> xnox, ping wrt boost upload...
<Laney> cpaelzer: Not sure its your problem that the tool assumes the first 'word' is the name someone wants to be addressed by
<cpaelzer> well, I want to try to be compatible :-)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.10 => 2.525.11] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: raspi3-firmware (bionic-proposed/multiverse) [1.20171201-3 => 1.20181112-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: u-boot (bionic-proposed/main) [2016.03+dfsg1-6ubuntu2 => 2018.03+dfsg1-2ubuntu2~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: u-boot (cosmic-proposed/main) [2018.03+dfsg1-2ubuntu1 => 2018.03+dfsg1-2ubuntu2~18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: raspi3-firmware (cosmic-proposed/multiverse) [1.20180316-3 => 1.20181112-1ubuntu0.18.10.1] (no packageset)
<ginggs> Laney: hi, i'm looking at the 'Cannot allocate memory' failures in r-bioc-biovizbase and r-bioc-cummerbund. i am able to reproduce in a 64-bit VM with 2GB memory and no swap. how much memory do the standard instances have, and is there swap available?  i'm trying to avoid needing huge instances
<Laney> ginggs: 1536M, no swap
<ginggs> Laney: ta.  is enabling swap an option, or are the choices standard or huge only?
<Laney> Not without considering changing it for everyone
<Laney> biovizbase looks like the delta that was dropped in the sync?
<Laney> and the other one too
<ginggs> Laney: yes, i could replace the delta which skips the failing call to sessionInfo() - but looking for a better solution
<Laney> seems odd that this function would cause a problem like that
<Laney> what is it doing?!?
<ginggs> Laney: they made me a member of Debian R team - and I don't know any R! :D - so I could upload the fix there
<ginggs> Laney: sessionInfo just prints some system info; R version, platform and loaded modules
<Laney> right
<ginggs> but it falls over on the call to uname
<Laney> so it's weird that this would consistently cause allocations to fail
<ginggs> i seem to recall the new process inherits a copy of the environment, that would explain the behaviour
<Laney> don't retry those perl regressions
<Laney> I've put them back in the huge queue
<coreycb> tjaalton: hi, if you have a moment would you be able to take a look at the software-properties SRU to bionic? it's a small one to enable the stein cloud archive.
<tjaalton> coreycb: sure
<coreycb> tjaalton: thanks very much
<tjaalton> coreycb: shouldn't it be targeted for cosmic too?
<tjaalton> let me rephrase; cosmic should be fixed too ;)
<coreycb> tjaalton: I guess so. this is always a weird one. it's only actually applicable to bionic.
<coreycb> tjaalton: to be honest i don't know why we've historically added it to the dev release.
<tjaalton> what does it do?
<coreycb> tjaalton: it enables the stein cloud archive on bionic, and that's the only place the stein cloud archive is supported
<tjaalton> ah
<tjaalton> guess it's fine then
<coreycb> tjaalton: alright thanks for reviewing
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.6]
<doko> The following packages have unmet dependencies:
<doko>  linux-generic : Depends: linux-image-generic (= 4.19.0.7.8) but 4.18.0.11.12 is to be installed
<doko> E: Unable to correct problems, you have held broken packages.
<doko> Exit request sent.
<doko> apw: ^^^
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2.6]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [4.19.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [4.19.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New source: openjdk-12 (disco-proposed/primary) [12~22-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-12 [source] (disco-proposed) [12~22-0ubuntu1]
<apw> doko, builds stuck in queues ... sorting
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [4.19.0-7.8]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [4.19.0-7.8]
-queuebot:#ubuntu-release- Unapproved: hwdata (trusty-proposed/main) [0.249-1 => 0.249-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (trusty-proposed/main) [3.8.4-0ubuntu3.2 => 3.8.4-0ubuntu3.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-desktop-icons (disco-proposed/primary) [18.11~rc-1]
-queuebot:#ubuntu-release- New binary: libnftnl [ppc64el] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [s390x] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnftnl [s390x] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [ppc64el] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnftnl [amd64] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [s390x] (disco-proposed/universe) [0.13-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppprogress [amd64] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [ppc64el] (disco-proposed/universe) [0.13-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnftnl [i386] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [i386] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnftnl [arm64] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnftnl [armhf] (disco-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [amd64] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [i386] (disco-proposed/universe) [0.13-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [amd64] (disco-proposed/universe) [0.13-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [arm64] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rtsne [armhf] (disco-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [amd64] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [armhf] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [ppc64el] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [arm64] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [s390x] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rtsne [i386] (disco-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [amd64] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [armhf] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [ppc64el] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [arm64] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [s390x] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted libnftnl [i386] (disco-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppprogress [amd64] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [armhf] (disco-proposed/universe) [0.13-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rspectra [arm64] (disco-proposed/universe) [0.13-1-1] (no packageset)
<vorlon> cpaelzer: no unicode hate, it rendered fine for me, but note that our scripts looked at your lp name and think your first name is circle-of-friends
-queuebot:#ubuntu-release- New binary: openjdk-12 [s390x] (disco-proposed/universe) [12~22-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~rc2-7431-g7dab1f014-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~rc2-7431-g7dab1f014-0ubuntu1~18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~rc2-7433-gea48d302e-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~rc2-7433-gea48d302e-0ubuntu1~18.10.1] (ubuntu-server)
<xnox> perl the most well tested language in ubuntu
 * roaksoax again.. if someone could please reject uploads of maas to comisc/bionic
<roaksoax> i would highly appreciate it
<infinity> roaksoax: All of 'em?
<infinity> roaksoax: 7431 and 7433, or just the older ones?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1035.36~14.04.2] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.20]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.20]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1035.36~14.04.2]
<roaksoax> infinity: yes please. It was me being silly and uploading to the wrong distro
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~rc2-7431-g7dab1f014-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (cosmic-proposed) [2.5.0~rc2-7431-g7dab1f014-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~rc2-7433-gea48d302e-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (cosmic-proposed) [2.5.0~rc2-7433-gea48d302e-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- New binary: openjdk-12 [amd64] (disco-proposed/universe) [12~22-0ubuntu1] (no packageset)
<vorlon> doko: automake-1.16 looks like a genuine change in the level of testing in the new package version; the architectures where the tests pass now also take a long time. Should we not be adding automake-1.16 to the list of packages with long-running tests?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1035.36~16.04.1] (kernel)
<rbalint> vorlon, could you please consider accepting u-u for xenial-proposed in your sru-shift today?
<rbalint> bdmurray, ^
<rbalint> i keep converting the fixed bugs to have sru template, the progress is tracked in LP: #1702793
<ubot5> Launchpad bug 1702793 in unattended-upgrades (Ubuntu) "Full backport SRU for unattended-upgrades" [Wishlist,In progress] https://launchpad.net/bugs/1702793
<rbalint> vorlon, bdmurray: the change is big but most of it already got extensive testing in bionic
<rbalint> vorlon, bdmurray: ideally it would stay for -proposed for extended time to let us being sure that it is well tested by others, too, in xenial
<rbalint> bdmurray, asking vorlon since he is on duty today, but would happily accept and accept from you, too :-)
<bdmurray> rbalint: all the tabs are stil loading but are you implying that some of the bugs don't have the sru template?
<rbalint> bdmurray, yes, ~15
<rbalint> bdmurray, and decreasing :-)
<bdmurray> rbalint: briefly looking at some of these I think the sync onces can be ignored, are there others?
<bdmurray> Some of them I can guess at like bug 1680599 or write my self.
<ubot5> bug 1680599 in unattended-upgrades (Ubuntu) "unattended-upgrades crashes without writing to the log on invalid config file entries" [Medium,Fix released] https://launchpad.net/bugs/1680599
<rbalint> bdmurray, there is a list of them in LP: #1702793
<ubot5> Launchpad bug 1702793 in unattended-upgrades (Ubuntu) "Full backport SRU for unattended-upgrades" [Wishlist,In progress] https://launchpad.net/bugs/1702793
<bdmurray> rbalint: How I start by going through the bugs in there and recording which ones I'd like to see the SRU template for?
<bdmurray> and I meant How about I
<rbalint> bdmurray, ok, please make a comment to the ones not having and not needing one
<bdmurray> rbalint: some of the bugs I might know well enough to accept it w/o the SRU info but think the bug should still get it before it goes to -updates
<rbalint> bdmurray, i'm EOD-ing now, please accept the package if it is ok, i'll fill the missing needed templates next week
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1035.36] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1035.36~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1035.36]
<vorlon> rbalint: I was ignoring that until the discussion about bug references had settled.  I certainly don't expect that I will want to accept an SRU with 50 bug references in it.
<vorlon> rbalint: having more bugs referenced in the changelog + .changes file than you actually intend to do verification on is makework not just for the bug template stage
-queuebot:#ubuntu-release- New: accepted openjdk-12 [amd64] (disco-proposed) [12~22-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [amd64] (disco-proposed) [0.13-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [armhf] (disco-proposed) [0.13-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [ppc64el] (disco-proposed) [0.13-1-1]
-queuebot:#ubuntu-release- New: accepted openjdk-12 [s390x] (disco-proposed) [12~22-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [i386] (disco-proposed) [0.13-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [arm64] (disco-proposed) [0.13-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rspectra [s390x] (disco-proposed) [0.13-1-1]
#ubuntu-release 2018-12-01
<jbicha> doko: does it make sense to have openjdk-12 in the disco release archive? since its lifecycle is so short
-queuebot:#ubuntu-release- New binary: alglib [s390x] (disco-proposed/universe) [3.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alglib [ppc64el] (disco-proposed/universe) [3.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alglib [amd64] (disco-proposed/universe) [3.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alglib [arm64] (disco-proposed/universe) [3.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alglib [i386] (disco-proposed/universe) [3.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alglib [armhf] (disco-proposed/universe) [3.14.0-1] (no packageset)
<LocutusOfBorg> hello can anybody please bump symfony hint on armhf to  3.4.19+dfsg-1ubuntu1 ? upstream should receive a patch soon
<LocutusOfBorg> there is an ongoing PR
-queuebot:#ubuntu-release- New: accepted alglib [amd64] (disco-proposed) [3.14.0-1]
-queuebot:#ubuntu-release- New: accepted alglib [armhf] (disco-proposed) [3.14.0-1]
-queuebot:#ubuntu-release- New: accepted alglib [ppc64el] (disco-proposed) [3.14.0-1]
-queuebot:#ubuntu-release- New: accepted alglib [arm64] (disco-proposed) [3.14.0-1]
-queuebot:#ubuntu-release- New: accepted alglib [s390x] (disco-proposed) [3.14.0-1]
-queuebot:#ubuntu-release- New: accepted alglib [i386] (disco-proposed) [3.14.0-1]
<jbicha> https://code.launchpad.net/~jbicha/britney/libuv1_starjava-ttools_symfony/+merge/359971
-queuebot:#ubuntu-release- New binary: pushover [amd64] (disco-proposed/universe) [0.0.5+git20180909-3] (no packageset)
#ubuntu-release 2018-12-02
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (bionic-proposed/universe) [1.20.0-1 => 1.20.2-1~ubuntu18.04.1] (ubuntu-mate) (sync)
<tsimonq2> infinity: That's my (kind of belated) copy-package with binaries: ^
-queuebot:#ubuntu-release- New: accepted pushover [amd64] (disco-proposed) [0.0.5+git20180909-3]
<bluesabre> Release team, what steps need to be taken to discontinue 32-bit ISOs for Xubuntu? I've prepared a mail to the release mailing list, but not sure if that's the way to go.
<bluesabre> (related: https://lists.ubuntu.com/archives/xubuntu-devel/2018-December/011755.html)
<infinity> bluesabre: The mail is enough, we'll twiddle the right bits.
<bluesabre> infinity: great, thanks
<bluesabre> And sent.
<infinity> I think that leaves lubuntu as the only i386 image still produced (not counting base and netboot).
<infinity> tsimonq2: ^
<infinity> bluesabre: Note that "inability to upgrade" probably shouldn't have been a factor, but it certainly hints at future plans. :P
<infinity> (we disabled automagic upgrades specifically because if we *do* drop i386 before 20.04, we'd rather leave users with a 5-year-supported 18.04 than stranded on a 9m release after)
<bluesabre> Sure
<infinity> But if we do 20.04 i386, we'll enable that upgrade.
<bluesabre> It was one of several contributing factors :)
<infinity> I hope we don't do it.
<infinity> bluesabre: It's gone, and scrubbed from your daily-live dirs as well.
<bluesabre> infinity: great, thanks for the help!
<infinity> bluesabre: Thanks for making lubuntu the last oddball with an i386 image so they can stop using you as precedent. ;)
<bluesabre> ha :D
<bluesabre> sorry tsimonq2, we've made it a bit harder for you to say no
<infinity> I mean, lubuntu can keep producing i386 images right up until we flat-out refuse to build i386 debs anymore, but I'm trying to recommend against it.
<infinity> Since ISOs encourage installs and that sets future user expectations.
<infinity> So better to wean them off.
<mwhudson> they can pay for ISOs by debugging every time x87 goes weird
 * acheronuk votes to kill i386 and armhf now....
-queuebot:#ubuntu-release- New binary: pdftk [ppc64el] (disco-proposed/universe) [2.02-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pdftk [s390x] (disco-proposed/universe) [2.02-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pdftk [amd64] (disco-proposed/universe) [2.02-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pdftk [i386] (disco-proposed/universe) [2.02-5] (no packageset)
-queuebot:#ubuntu-release- New binary: movim [amd64] (disco-proposed/universe) [0.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdftk [arm64] (disco-proposed/universe) [2.02-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pdftk [armhf] (disco-proposed/universe) [2.02-5] (no packageset)
#ubuntu-release 2019-11-25
<mitya57> vorlon: as I said, some software will become available via llvmpipe, but other packages that have already adapted to GL ES will break.
<mitya57> It would be nice to make a test rebuild with that change, but I don't have time for that.
<mitya57> So far top priority for me is making qtdeclarative5-gles and moving forward with https://release.debian.org/transitions/html/libqt5gui5-gles.html. Maybe when that happens I will be able to look at switching armhf (and armel in Debian).
-queuebot:#ubuntu-release- Unapproved: thunderbird (xenial-proposed/main) [1:60.9.0+build1-0ubuntu0.16.04.2 => 1:60.9.1+build1-0ubuntu0.16.04.1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: thunderbird (disco-proposed/main) [1:60.9.0+build1-0ubuntu0.19.04.1 => 1:60.9.1+build1-0ubuntu0.19.04.1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (bionic-proposed/main) [1.7+18.04ubuntu1 => 1.8+18.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (eoan-proposed/main) [1.7+19.10ubuntu6 => 1.8+19.10ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (disco-proposed/main) [1.7+19.04ubuntu1 => 1.8+19.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/main) [1.7+16.04ubuntu1 => 1.8+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [1.1ubuntu1.18.04.7~16.04.4 => 1.1ubuntu1.18.04.7~16.04.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.12 => 1.1ubuntu1.18.04.13] (desktop-core, ubuntu-server)
<rbalint> sil2100, ^ wslu also migrated in focal, so please check out that one, too
<sil2100> rbalint: on it
<sil2100> rbalint: looking at the change, it looks good but just wanted to make about one thing:
<sil2100> rbalint: so with the change added now, you are skipping detection when pactl and xvinfo are not installed - this causes actually the `type XXX` checks to be performed twice
<sil2100> rbalint: also, previously it seemed possible to still have DISPLAY set when no pulse audio is available
<sil2100> rbalint: but I guess it's expected that pactl is always there whenever X is present?
<rbalint> sil2100, type is basically free, so it is intentional
<rbalint> sil2100, if either pactl or xvinfo is present the detection is urn
<rbalint> run
<rbalint> sil2100, if type pactl > /dev/null 2>&1 || type xvinfo > /dev/null 2>&1; then
<sil2100> Ah, duh, right, still - was wondering why this top level check was added, since all the others also do the `type` check and have && conditionals
<sil2100> So in theory, if pactl is not available, only the type check should be performed
<rbalint> sil2100, to avoid calling systemd-detect-virt when nothing can be detected
<rbalint> sil2100, calling it is more than 0.01s
<rbalint> sil2100, type is 0
<sil2100> rbalint: ah, so this is the optimization the bug mentions
<sil2100> ACK
<rbalint> sil2100, yes, i had to add calling systemd-detect-virt, but it is too slow and is worth skipping when possible
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (eoan-proposed) [2.3.2-0ubuntu2~19.10.1]
<bdmurray> rbalint: Could you have a look at the systemd patch in bug 1846787 so we can proceed with the SRU?
<ubot5> bug 1846787 in systemd (Ubuntu Xenial) "systemd-logind leaves leftover sessions and scope files" [Medium,In progress] https://launchpad.net/bugs/1846787
<bdmurray> dimitri is a bit over comitted
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (disco-proposed) [2.3.2-0ubuntu2~19.04.1]
<sil2100> bdmurray: while you have a moment, could you actually release debootstrap for x/b? Since it's there since a while now, green and ready to go
<bdmurray> sil2100: Why do you think I have a momentâ½
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (bionic-proposed) [2.3.2-0ubuntu2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (xenial-proposed) [2.3.2-0ubuntu2~16.04.1]
<sil2100> s/while/when
<sil2100> !
<sil2100> That was a genuine typo, I guess sometimes I mix up words that have common letters
<sil2100> ;)
<bdmurray> sil2100: Alright that's fair
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.13]
<sil2100> bdmurray: thank you!
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.5]
 * vorlon looks askance at Debian having removed most of the gdcm/opencv revdeps from testing without RC bugs ever being filed
<vorlon> and has there been a change to cmake to make its output useless on failure?
-queuebot:#ubuntu-release- New binary: libdvdread [i386] (focal-proposed/universe) [6.0.2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdvdread [amd64] (focal-proposed/universe) [6.0.2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdvdread [s390x] (focal-proposed/universe) [6.0.2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdvdread [ppc64el] (focal-proposed/universe) [6.0.2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdvdread [arm64] (focal-proposed/universe) [6.0.2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libdvdread [armhf] (focal-proposed/universe) [6.0.2-2] (kubuntu)
#ubuntu-release 2019-11-26
-queuebot:#ubuntu-release- New binary: gxr [s390x] (focal-proposed/none) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [amd64] (focal-proposed/multiverse) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [ppc64el] (focal-proposed/multiverse) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [arm64] (focal-proposed/multiverse) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [armhf] (focal-proposed/multiverse) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [i386] (focal-proposed/multiverse) [0.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1027.29] (core, kernel)
-queuebot:#ubuntu-release- New: accepted gxr [amd64] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted gxr [armhf] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted gxr [ppc64el] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted libdvdread [amd64] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- New: accepted libdvdread [armhf] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- New: accepted libdvdread [ppc64el] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- New: accepted gxr [arm64] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted gxr [s390x] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted libdvdread [i386] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- New: accepted gxr [i386] (focal-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted libdvdread [s390x] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- New: accepted libdvdread [arm64] (focal-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (focal-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1027.29]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1027.29~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1027.29~18.04.1]
-queuebot:#ubuntu-release- New binary: rrdtool [s390x] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [amd64] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [i386] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [ppc64el] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [arm64] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [armhf] (focal-proposed/main) [1.7.2-3] (core)
-queuebot:#ubuntu-release- New: accepted rrdtool [amd64] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- New: accepted rrdtool [armhf] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- New: accepted rrdtool [ppc64el] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- New: accepted rrdtool [arm64] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- New: accepted rrdtool [s390x] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- New: accepted rrdtool [i386] (focal-proposed) [1.7.2-3]
-queuebot:#ubuntu-release- Unapproved: cachefilesd (eoan-proposed/universe) [0.10.10-0.2 => 0.10.10-0.2ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cachefilesd (disco-proposed/universe) [0.10.10-0.1 => 0.10.10-0.1ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cachefilesd (bionic-proposed/universe) [0.10.10-0.1 => 0.10.10-0.1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.8 => 2.0.874-5ubuntu2.9] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: hwloc [s390x] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hwloc [ppc64el] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hwloc [i386] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hwloc [amd64] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hwloc [arm64] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hwloc [armhf] (focal-proposed/universe) [2.1.0+dfsg-2] (kubuntu)
<cascardo> anyone available to look at some dkms packages at bionic SRU queue?
<cascardo> lttng-modules, openafs, xtables-addons, ndiswrapper, dahdi-linux
-queuebot:#ubuntu-release- New: accepted hwloc [amd64] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hwloc [armhf] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hwloc [ppc64el] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hwloc [arm64] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hwloc [s390x] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hwloc [i386] (focal-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [19.6~ubuntu14.04.4]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.12 => 1.173.13] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.23]
-queuebot:#ubuntu-release- New binary: libchipcard [amd64] (focal-proposed/universe) [5.1.4rc1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-72.81] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-72.81] (core, kernel)
-queuebot:#ubuntu-release- Packageset: 1765 entries have been added or removed
<vorlon> infinity: please have a look at https://code.launchpad.net/~vorlon/ubuntu-archive-tools/update-i386-whitelist/+merge/376042 if you wouldn't mind
#ubuntu-release 2019-11-27
<vorlon> the i386 package whitelist for focal is now live.  in the short term, expect proposed-migration to slow down a little bit as manual binary removals from the release pocket are needed in order to let things migrate
<vorlon> I will be doing a mass binary removal on i386, but before that I will be working on landing changes to make the autopkgtest runners test i386 on an amd64 base image, to reduce the testing impact of the removals (<-- cc: Laney juliank)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-72.81]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-72.81]
-queuebot:#ubuntu-release- New: accepted libchipcard [amd64] (focal-proposed) [5.1.4rc1-3]
<cpaelzer> RAOF: thanks for updating 1836929
<cpaelzer> RAOF: I know we use block-proposed for things like an FTBFS fix where it makes sense. But on a autopkgtest failure I thought this will ahve to go to -release to be used automatically
<cpaelzer> we could keep it in proposed which would let all tests fail but people could run a custom trigger to use the new version (which is better than not having it in proposed at all)
<cpaelzer> I think this might be a new corner case to be discussed in the block-proposed context
<cpaelzer> would you mind bringing this up with the SRU Team next time you meet?
<RAOF> Don't autopkgtests run against the packages in proposed?
 * RAOF forgets
<RAOF> I will indeed bring that up.
<RAOF> cpaelzer autopkgtests are documented as running with -proposed enabled, so having it in -proposed with block-proposed set should be exactly as useful as having it in -release?
<mwhudson> vorlon: exciting times
<mwhudson> RAOF: autopkgtests in general run with only the package being tested from proposed
<RAOF> Unless people are running their autopkgtests locally *without* -proposed.
<mwhudson> RAOF: "autopkgtests are documented as running with -proposed enabled" where did you find this lie?
<mwhudson> :
<mwhudson> :)
<RAOF> mwhudson: Ah, I was indeed misreading that.
<RAOF> Or, rather, *later* in the documentation it clarifies that âwith proposed enabledâ means âwith certain packages from proposedâ ð
<RAOF> (specifically, http://packaging.ubuntu.com/html/auto-pkg-test.html says both those things)
<apw> technically it has proposed 'enabled' and pinning applied to make only a subset of packages desirable; so it is right and utterly missleading
<mwhudson> well in that sense most of my systems have proposed enabled
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-72.81~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-72.81~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-72.81~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-72.81~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [s390x] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.3.0-24.26~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.3.0-24.26~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.3.0-24.26~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [s390x] (bionic-proposed) [5.3.0-24.26~18.04.2]
-queuebot:#ubuntu-release- Unapproved: ceilometer (eoan-proposed/main) [1:13.0.0-0ubuntu1 => 1:13.0.0-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (disco-proposed/main) [1:12.0.0-0ubuntu1 => 1:12.0.0-0ubuntu1.1] (openstack, ubuntu-server)
<vorlon> huh.  all the dbus-triggered autopkgtests are failing on i386, I swear I didn't do that
<Laney> curious
<seb128> Laney, vorlon, dbus was just uploaded, looks like an arches mismatch?
<Laney> but it shouldn't have been triggered until proposed-migration saw all of the builds were there
<vorlon> furthermore, the error claims that some of the packages from the -proposed version on i386 are available but can't be installed due to dependencies
<seb128> I just tried in a focal/i386 chroot and it's installable there...
<Laney> just tried in scalingstack, still happening
<Laney> whatTTTTTTTTTTTTTTTTTTtttt
<vorlon> is it somehow refusing to upgrade packages that are part of the base image?  I'm not sure that would make sense
<Laney> it's probably somehow or other to do with the pinning
<Laney> but doesn't happen in a qemu vm locally :(
<vorlon> tseliot: nvidia-graphics-drivers-340 didn't make it into the i386 whitelist because it doesn't ship versions of any of the libraries that were identified as required for i386-compatibility.  Is there any reason to care about i386 versions of the 340 libcuda* stuff being available, or should I just drop these i386 binaries?
<tseliot> vorlon, the amd64 package already includes the i386 libraries (which should be enough for most uses), since it's not a proper multi-arch package. As for libcuda1-340, I doubt that the i386 libraries would be super useful
<Laney> vorlon: https://paste.ubuntu.com/p/SfjZ2BxhsF/
<Laney> I'm assuming we need to write pins for foreign arches too
<vorlon> tseliot: ok removing those binaries then, cheers
<vorlon> Laney: huh why is amd64 libdbus installed in that environment?
<vorlon> Laney: I mean, the conclusion sounds correct but I'm still confused how we arrived at that point
<Laney> thermald apparently
<Laney> not sure where that comes from
<vorlon> wow
<Laney> oh ok, recommends from the kernel
<vorlon> Laney: are you going to work on implementing that foreign-arch pinning? it may wind up needing some redoing shortly anyway as I'm hoping to move us from i386 images to amd64 images for focal by EOW
<vorlon> Laney: fwiw rough sketch of what I'm planning: autopkgtest itself needs to grow an interface to know what arch it's being asked to test for, which we would then invoke unconditionally; this would translate to arch-qualified installation of all packages from this source, cross-build-aware installation of @builddeps@, and default host resolution of any other test deps.  Opinions?
<Laney> not if I can help it ;-)
<vorlon> Laney: ok then my plan instead is to badtest all of the dbus revdeps that are slated for removal, skiptest the rest, and move on ;)
<vorlon> (and deal with the foreign-arch pinning as part of the migration)
<Laney> vorlon: sounds sane at first glance; might want to run it past elbrus
<Laney> what's the state of cross building random packages?
<Laney> wip/mojo-juju-2's going to want some work for this too
<Laney> i386/amd64 is treated as a special case there
<vorlon> ah?
<vorlon> Laney: elbrus> hmm he's not here, I thought he used to hang out.  Is there a recommended channel for upstream autopkgtest discussions?
<Laney> #debci
<Laney> probably OFTC?
<vorlon> ack
<Laney> special case> to handle using the same quota for both arches
<Laney> Maybe we'll just have to further special case out image building
<vorlon> well, my current approach was just to add i386 foreign-arch to the amd64 image and use that, which was a lot simpler than refactoring 3 layers of autopkgtest-cloud
<vorlon> as far as quotas... with only 1700 source packages left on i386, it may just fit in the margin ;P
<Laney> if I'm understanding correctly, autopkgtest-cloud changes are (1) don't build i386 autopkgtest cloud images any more, and (2) ask for the amd64 image when testing i386
<Laney> should be fairly trivial in both branches (but different)
 * vorlon nods
<mwhudson> vorlon: er how would you feel about deleting livecd-rootfs/i386? :)
<vorlon> mwhudson: ecstatic
<mwhudson> vorlon: i guess this will poke people who are still building i386 images in the eye fairly obviously :)
<vorlon> mwhudson: actually on that point it might be a bit awkward for me to delete it right before Thanksgiving and make the cpc team's builds all break.  Could I instead add livecd-rootfs to the package whitelist and have you upload it again to get it built?
<mwhudson> vorlon: that would be fine too
<mwhudson> (i would like it to migrate before the general mass binary removal)
<mwhudson> vorlon: let me know when its safe to upload it
<vorlon> mwhudson: should be good now
<mwhudson> vorlon: ta
<mwhudson> 4 attempts to type my gpg passphrase, not enough coffee or too much?
<valorie> never too much coffee!
 * valorie slides a glass of water to mwhudson
-queuebot:#ubuntu-release- Packageset: Added livecd-rootfs to i386-whitelist in focal
#ubuntu-release 2019-11-28
<cjwatson> You don't need to upload again to get it built.  A self-copy would do
<cjwatson> (Probably too late now, but for next time0
<cjwatson> )
<vorlon> ah good point
-queuebot:#ubuntu-release- New binary: python-m2r [amd64] (focal-proposed/none) [0.2.1-3] (no packageset)
<infinity> vorlon, mwhudson: Given it's how we generate buildd images, removing livecd-rootfs on i386 would be suboptimal. :P
<vorlon> oh that too
<mwhudson> infinity: details
-queuebot:#ubuntu-release- New binary: libbio-db-gff-perl [amd64] (focal-proposed/universe) [1.7.3-2] (no packageset)
<LocutusOfBorg> vorlon, hello, can you please add virtualbox and virtualbox-hwe to i386 list exception? I think a virtualization system guest needs to be kept, right?
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu0.18.04.3 => 12.2.12-0ubuntu0.18.04.4] (desktop-core, ubuntu-server)
<LocutusOfBorg> can I ask any AA to review some phpunit reverse-deps that might be kicked out from focal, and are already out from testing?
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu5.1 => 3.98ubuntu5.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu5.2]
<LocutusOfBorg> apw, is it possible to add virtualbox and virtualbox-hwe in the i386 exception list in your opinion?
<LocutusOfBorg> we really need guest parts to emulate the old i386 virtual machines
<apw> LocutusOfBorg, i really have no context to answer that, sorry
-queuebot:#ubuntu-release- New binary: ilmbase [s390x] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [ppc64el] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [amd64] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [i386] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [arm64] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [armhf] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.2-0ubuntu0.18.04.3 => 2.9.5-0ubuntu0.18.04.1] (ubuntu-server)
<cpaelzer> Laney: vorlon: I saw you yesterday talking about i386 autopkgtests failing
<cpaelzer> was that resolved - atm I'm wondering why a PPA no more builds i386
<cpaelzer> and I ask myself if this is part of the same overall big swicth that might be going on
<cpaelzer> i386 is enabled in the PPA, package is Architecture: linux-any - but no (neither failed nor succeeded) i386 build at the PPA
<Laney> cpaelzer: right, there's a whitelist now https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist
<cpaelzer> So I don't want/need an i386 of chrony (which I put to my PPA)
<cpaelzer> but I'd want the tests to start on it :-)
<cpaelzer> sil2100: that might be a bileto thing as that is what I used for this https://bileto.ubuntu.com/#/ticket/3847
<cpaelzer> is the drop of i386 known to need any changes there to "not wait on it"
<cpaelzer> and vice versa Laney/vorlon did "normal" britney get changes to not ahve the same "waiting on i386 build"
<Laney> it only looks for missing builds versus what is in the release
<Laney> so once someone performs a mass removal of i386, will be good
<cpaelzer> that sounds great, thanks for the info
<cpaelzer> is there any sort of ETA for that
<cpaelzer> today is thanksgiving so only about 50% will complain today :-)
<Laney> that's going to be Steve, so I can't make any promises :(
<sil2100> cpaelzer: yeah, I mean, I could drop i386 from the list of ADT arches, but I suppose once the removals happen it should be all better
<cpaelzer> sil2100: thanks
<cpaelzer> I can wait for the removal to be complete
<seb128> sil2100, hey, did you see the ping aobut jsunit/bionic yesterday?
-queuebot:#ubuntu-release- Unapproved: valgrind (eoan-proposed/main) [1:3.15.0-1ubuntu3 => 1:3.15.0-1ubuntu3.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: simplestreams (bionic-proposed/main) [0.1.0~bzr460-0ubuntu1 => 0.1.0~bzr460-0ubuntu1.1] (ubuntu-server)
<sil2100> seb128: ah, yes! On it now
<seb128> sil2100, thanks!
<sil2100> uh, ok, so I actually didn't know that someone actually released thunderbird
<sil2100> I explicitly tagged the bugs to not be released without coordination, if I knew I would have acted on the jsunit yesterday already
<sil2100> It's done now though o/
<sil2100> Sorry for the hiccup
<seb128> sil2100, np, thanks!
<seb128> oSoMoN, ^
<oSoMoN> thanks sil2100
<sil2100> yw o/
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (bionic-proposed/main) [1:3.28.2-1~ubuntu18.04.1 => 1:3.28.2-1~ubuntu18.04.2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.13 => 3.28.1-0ubuntu4.18.04.14] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.2 => 3.28.4-0ubuntu18.04.3] (desktop-extra, mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.4-0~ubuntu18.04.4 => 1:3.26.4-0~ubuntu18.04.5] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New binary: r-cran-rrcov [amd64] (focal-proposed/universe) [1.4-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rrcov [ppc64el] (focal-proposed/universe) [1.4-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rrcov [arm64] (focal-proposed/universe) [1.4-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rrcov [s390x] (focal-proposed/universe) [1.4-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rrcov [armhf] (focal-proposed/universe) [1.4-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qosmic [amd64] (focal-proposed/universe) [1.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qosmic [s390x] (focal-proposed/universe) [1.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qosmic [ppc64el] (focal-proposed/universe) [1.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qosmic [arm64] (focal-proposed/universe) [1.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qosmic [armhf] (focal-proposed/universe) [1.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ilmbase [amd64] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted ilmbase [armhf] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted ilmbase [ppc64el] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted libbio-db-gff-perl [amd64] (focal-proposed) [1.7.3-2]
-queuebot:#ubuntu-release- New: accepted qosmic [amd64] (focal-proposed) [1.6.0-2]
-queuebot:#ubuntu-release- New: accepted qosmic [armhf] (focal-proposed) [1.6.0-2]
-queuebot:#ubuntu-release- New: accepted qosmic [s390x] (focal-proposed) [1.6.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rrcov [arm64] (focal-proposed) [1.4-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rrcov [ppc64el] (focal-proposed) [1.4-9-1]
-queuebot:#ubuntu-release- New: accepted ilmbase [arm64] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted ilmbase [s390x] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted qosmic [arm64] (focal-proposed) [1.6.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rrcov [amd64] (focal-proposed) [1.4-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rrcov [s390x] (focal-proposed) [1.4-9-1]
-queuebot:#ubuntu-release- New: accepted ilmbase [i386] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted qosmic [ppc64el] (focal-proposed) [1.6.0-2]
-queuebot:#ubuntu-release- New: accepted python-m2r [amd64] (focal-proposed) [0.2.1-3]
-queuebot:#ubuntu-release- New: accepted r-cran-rrcov [armhf] (focal-proposed) [1.4-9-1]
-queuebot:#ubuntu-release- New binary: libbio-db-seqfeature-perl [amd64] (focal-proposed/universe) [1.7.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-db-ace-perl [amd64] (focal-proposed/universe) [1.7.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libbio-db-ace-perl [amd64] (focal-proposed) [1.7.3-2]
-queuebot:#ubuntu-release- New: accepted libbio-db-seqfeature-perl [amd64] (focal-proposed) [1.7.3-2]
<vorlon> 04:34 < LocutusOfBorg> we really need guest parts to emulate the old i386 virtual machines
<vorlon> he's not around so I can't answer him directly, but fwiw the answer here is a definitive no
<vorlon> there is no 32-bit kernel on focal, and no support for running a 32-bit host environment on focal, so no reason at all to have the 32-bit guest tools
<vorlon> tumbleweed: hi, qa.ubuntuwire.com down?
<vorlon> .org
<infinity> vorlon: YEah, I was waiting for him to come back to say the same thing.
<vorlon> tumbleweed: n/m I was apparently sending mistyped package names and making reverse-depends angry ;)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.23 => 2.02~beta2-36ubuntu3.24] (core)
#ubuntu-release 2019-11-29
 * tumbleweed has a look
<tumbleweed> seems alive to me
<tumbleweed> ah, right
<xnox> vorlon:  and guest tools in the say bionic guest, don't need to match the guest *stuff* on focal host, right?
<vorlon> xnox: even if they did, there would be no need for 32-bit focal bits
-queuebot:#ubuntu-release- New binary: dothost [amd64] (focal-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dothost [s390x] (focal-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dothost [armhf] (focal-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: preggy [amd64] (focal-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dothost [ppc64el] (focal-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dothost [arm64] (focal-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pattern [amd64] (focal-proposed/universe) [2.6+git20180818-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plaso [amd64] (focal-proposed/universe) [20190131-3] (no packageset)
-queuebot:#ubuntu-release- New binary: oclgrind [amd64] (focal-proposed/universe) [19.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: oclgrind [ppc64el] (focal-proposed/universe) [19.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: oclgrind [arm64] (focal-proposed/universe) [19.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: oclgrind [armhf] (focal-proposed/universe) [19.10-1] (no packageset)
<ginggs> would someone please 'force-badtest  samtools/all/i386 vcftools/all/i386 snpomatic/all/i386' ?
<vorlon> ginggs: done
-queuebot:#ubuntu-release- New: accepted oclgrind [arm64] (focal-proposed) [19.10-1]
-queuebot:#ubuntu-release- New: accepted oclgrind [armhf] (focal-proposed) [19.10-1]
-queuebot:#ubuntu-release- New: accepted dothost [amd64] (focal-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted dothost [armhf] (focal-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted dothost [s390x] (focal-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted oclgrind [ppc64el] (focal-proposed) [19.10-1]
-queuebot:#ubuntu-release- New: accepted preggy [amd64] (focal-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted dothost [arm64] (focal-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted oclgrind [amd64] (focal-proposed) [19.10-1]
-queuebot:#ubuntu-release- New: accepted python-pattern [amd64] (focal-proposed) [2.6+git20180818-1]
-queuebot:#ubuntu-release- New: accepted dothost [ppc64el] (focal-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted plaso [amd64] (focal-proposed) [20190131-3]
<ginggs> vorlon: ta!
<LocutusOfBorg> thanks vorlon and infinity !
<LocutusOfBorg> I admit, the request was not so clear in my mind, I still need to properly figure out what the support will be and how... (so I presume some libraries needed for valve&co, wine or something similar)
<LocutusOfBorg> btw, gsoap might migrate if we remove some i386 binaries...
-queuebot:#ubuntu-release- New binary: libthumbor [amd64] (focal-proposed/universe) [1.3.3-1] (no packageset)
<doko> vorlon: is there some documentation which i386 packages are still built, and which ones are not?
<ginggs> doko: there's a whitelist https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist
-queuebot:#ubuntu-release- New binary: libplist [amd64] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libplist [s390x] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libplist [ppc64el] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libplist [arm64] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libplist [i386] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
<LocutusOfBorg> do we have any AA that can do removals of i386 binaries for: cgsi-gsoap davix kopanocore srm-ifce voms?
-queuebot:#ubuntu-release- New binary: libplist [armhf] (focal-proposed/main) [2.1.0-0build1] (desktop-core, i386-whitelist)
<LocutusOfBorg> I would like to see if we need something else for migration, but Britney is not even running tests
-queuebot:#ubuntu-release- New: accepted libplist [amd64] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New: accepted libplist [armhf] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New: accepted libplist [ppc64el] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New: accepted libplist [arm64] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New: accepted libplist [s390x] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New: accepted libplist [i386] (focal-proposed) [2.1.0-0build1]
-queuebot:#ubuntu-release- New binary: libusbmuxd [amd64] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libusbmuxd [s390x] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libusbmuxd [ppc64el] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [amd64] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [s390x] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libusbmuxd [armhf] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [i386] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libusbmuxd [i386] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libusbmuxd [arm64] (focal-proposed/main) [2.0.1-1ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [ppc64el] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [armhf] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libimobiledevice [arm64] (focal-proposed/main) [1.2.1~git20190929.60823f9-1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted libimobiledevice [amd64] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libimobiledevice [armhf] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libimobiledevice [ppc64el] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libthumbor [amd64] (focal-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [arm64] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [i386] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [s390x] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libimobiledevice [arm64] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libimobiledevice [s390x] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [armhf] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libimobiledevice [i386] (focal-proposed) [1.2.1~git20190929.60823f9-1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [ppc64el] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libusbmuxd [amd64] (focal-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (eoan-proposed) [1.8+19.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (disco-proposed) [1.8+19.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.8+18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.8+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cachefilesd [source] (eoan-proposed) [0.10.10-0.2ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cachefilesd [source] (disco-proposed) [0.10.10-0.1ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cachefilesd [source] (bionic-proposed) [0.10.10-0.1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (eoan-proposed) [1:13.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (disco-proposed) [1:12.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (eoan-proposed) [1:3.15.0-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (disco-proposed) [1:60.9.1+build1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (xenial-proposed) [1:60.9.1+build1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dahdi-linux [source] (bionic-proposed) [1:2.11.1~dfsg-1ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: accepted ndiswrapper [source] (bionic-proposed) [1.60-6ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [source] (bionic-proposed) [3.0-0.1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (bionic-proposed) [1.8.0~pre5-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.8-1ubuntu2~18.04.1]
<tjaalton> xnox: hi, open-iscsi sru is still unverified after sitting in proposed for a month, and another upload is pending..
<tjaalton> xnox: oh, it's for the same bug?
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.13]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.12-0ubuntu0.18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (bionic-proposed) [2.9.5-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [sync] (bionic-proposed) [1:3.28.2-1~ubuntu18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [sync] (bionic-proposed) [3.28.1-0ubuntu4.18.04.14]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [sync] (bionic-proposed) [3.28.4-0ubuntu18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [sync] (bionic-proposed) [1:3.26.4-0~ubuntu18.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (bionic-proposed) [0.1.0~bzr460-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted limnoria [source] (bionic-proposed) [2018.01.25-1ubuntu18.04.1]
<xnox> tjaalton:  yes, previous upload was incomplete.
<tjaalton> xnox: right, accepted
-queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (xenial-proposed) [1.10.6-1ubuntu3.5]
<tjaalton> vorlon: cleared the queue again for fwupd/fwupdate ;)
<tjaalton> looks like autopkgtest.u.c needs to know i386 isn't a thing on focal anymore?
<juliank> tjaalton: but it is, cross-testing on amd64?
<tjaalton> juliank: i386 tests failing because they can't find packages
<juliank> tjaalton: yes, there could be some trouble atm, as the autopkgtest infra is probably not ready yet, but are they failing to find their own packages or test dependencies?
<juliank> I don't know any concrete plans, unfortunately
<tjaalton> both aiui, but ok, it'll get sorted eventually
<juliank> but given that we do ship some i386 libraries we certainly should not stop testing stuff
<tjaalton> but only those that get built
<juliank> yes that'd make sense
<tjaalton> not leaf pkgs that don't have debs ;)
-queuebot:#ubuntu-release- New binary: node-i18next [amd64] (focal-proposed/universe) [17.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-re2 [ppc64el] (focal-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-janus [amd64] (focal-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-re2 [amd64] (focal-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-re2 [s390x] (focal-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-re2 [armhf] (focal-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-re2 [arm64] (focal-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: visp [s390x] (focal-proposed/universe) [3.2.0-2] (no packageset)
<vorlon> doko, ginggs: you might also want to refer to the seed, which is the definition of what's included in that packageset once germinated https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/i386.seedtext
-queuebot:#ubuntu-release- New binary: visp [amd64] (focal-proposed/universe) [3.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: visp [ppc64el] (focal-proposed/universe) [3.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-i18next [amd64] (focal-proposed) [17.0.18-1]
-queuebot:#ubuntu-release- New: accepted node-re2 [arm64] (focal-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted node-re2 [ppc64el] (focal-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted visp [amd64] (focal-proposed) [3.2.0-2]
-queuebot:#ubuntu-release- New: accepted visp [s390x] (focal-proposed) [3.2.0-2]
-queuebot:#ubuntu-release- New: accepted node-re2 [amd64] (focal-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted python-janus [amd64] (focal-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted node-re2 [armhf] (focal-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted visp [ppc64el] (focal-proposed) [3.2.0-2]
-queuebot:#ubuntu-release- New: accepted node-re2 [s390x] (focal-proposed) [1.10.4-1]
<ginggs> vorlon: thanks
-queuebot:#ubuntu-release- Packageset: 111 entries have been added or removed
<vorlon> so properly seeding livecd-rootfs on i386 instead of having manually added it to the packageset as a one-off means now golang-defaults and ghc are in the packageset lol?  Guess I should make some of those deps arch-specific
<vorlon> mwhudson: side effect, it means golang-defaults is currently in the packageset so I did a self-copy so you'll get a build and it can unblock
<infinity> vorlon: livecd-rootfs pulls in... haskell?
<cjwatson> pandoc somehow?
<cjwatson> Oh, shellcheck
<infinity> Yeah, just got there.
<cjwatson> b-d of initramfs-tools
<cjwatson> Not sure how you're gonna avoid that one
<infinity> Don't run it on i386?  That's easy enough.
<infinity> You don't really need to check your shell on 6 arches.
<cjwatson> shellcheck is M-A: foreign
<cjwatson> So the germinate hack I'm halfway through reviewing should probably sort it out?
<infinity> Oh, or that.
<infinity> Wait, no.
<cjwatson> (It's in my queue.  I'm trying to decide whether the bit I'm currently on is grotty but OK, or unacceptable)
<infinity> Cause we build i386 on i386.
<infinity> With no foreign arches.
<cjwatson> Er yeah
<infinity> But just restricting the build-dep and not running it on i386 seems reasonable to cull ghc.
<cjwatson> So can't avoid the dep in livecd-rootfs, but could avoid the b-d in i-t
 * infinity fixes that now.
<doko> vorlon: sorry, can't find that in the seeds archive
<doko> so what should I do, if
<doko>  - I'd like to get gcc-7 building again on i386?
<doko>  - to add gcc-10, gcc-10-cross, gcc-10-cross-ports?
<doko>  - to add creduce
<vorlon> doko: it is its own seed pod, lp:~ubuntu-core-dev/ubuntu-seeds/+git/i386.  gcc-10-cross* should be a strong no, i386 is not a host arch and nobody should need cross-compilers for an i386 build arch on focal.  gcc-10, probably worth future-proofing just in case we continue on past focal, so it should be added - but you probably have to manually add it to the packageset for bootstrapping purposes
<vorlon> (since germinate only works on binaries that actually exist).  And why do you want creduce?
<doko> to investigate toolchain issues on i386?
<doko> ok on gcc-10-cross*
<doko> so what to do about packages not on the whitelist that don't have a build record, and that you want to add?
<vorlon> doko: 1) add it to the packageset by hand, 2) copy-package -b --force-same-destination (to cause the build record to be generated), 3) add it to the seed, 4) confirm after germinate-output regenerates that update-i386-whitelist --dry-run (from https://code.launchpad.net/~vorlon/ubuntu-archive-tools/update-i386-whitelist/+merge/376042) does what you expect
<vorlon> doko: why do you need creduce to be an i386 package, instead of an amd64 package, to debug i386 toolchain issues?  looks "cross" installable to me
#ubuntu-release 2019-11-30
-queuebot:#ubuntu-release- New binary: isl [amd64] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: isl [s390x] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: isl [i386] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: isl [ppc64el] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: isl [arm64] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: isl [armhf] (focal-proposed/main) [0.22-2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Packageset: 65 entries have been added or removed
-queuebot:#ubuntu-release- New: accepted isl [amd64] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted isl [armhf] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted isl [ppc64el] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted isl [arm64] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted isl [s390x] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted isl [i386] (focal-proposed) [0.22-2]
<infinity> vorlon: Not sure if you saw in backscroll, but I uploaded an initramfs-tools that removed ghc from i386.
<infinity> vorlon: germinate seems to agree.
<infinity> vorlon: RE: gcc-cross, we seem to have gcc-9-cross-* in there right now.  Should we investigate why and get it out?
<infinity> Hrm, might be because of gcc-defaults.
<doko> did somebody remove gcc-7/i386?
<vorlon> infinity: yeah I saw, and propagated the changes to the package set
<vorlon> doko: I did.  It wasn't in the packageset, were you needing it still for something?
<doko> no, just tried to remove it myself
<vorlon> ok
<doko> and non-x86 builders are disabled
<doko> vorlon: does the gcc-7/i386 autopkg test need overriding?
-queuebot:#ubuntu-release- New binary: node-leche [amd64] (focal-proposed/none) [2.3.0~dfsg-2] (no packageset)
<vorlon> doko: yeah, something is wrong about how/when britney decides to schedule tests, so a whole bunch of tests get scheduled for binaries that have just been removed.  Overridden now
<doko> vorlon: ta, and please could you add gcc-snapshot again to build on i386?
<vorlon> doko: added to the seed, I'll propagate it to the packageset in a bit
<vorlon> livecd-rootfs autopkgtests will need some tuning to do something relevant on i386; currently they fail because ubuntu-server is no longer bootstrappable
-queuebot:#ubuntu-release- New binary: qutip [s390x] (focal-proposed/universe) [4.4.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qutip [ppc64el] (focal-proposed/universe) [4.4.1-4] (no packageset)
#ubuntu-release 2019-12-01
-queuebot:#ubuntu-release- New binary: qutip [amd64] (focal-proposed/universe) [4.4.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qutip [arm64] (focal-proposed/universe) [4.4.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qutip [armhf] (focal-proposed/universe) [4.4.1-4] (no packageset)
<vorlon> doko: gcc-snapshot propagated now to the packageset (in the same run as getting snapd+golang out, now that livecd-rootfs has migrated)
-queuebot:#ubuntu-release- Packageset: Removed dh-golang from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed efivar from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed golang-1.12 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed golang-defaults from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed grub2 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ipxe from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ipxe-qemu-256k-compat from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed jigit from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libburn from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libisoburn from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libisofs from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed mtools from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed pyparted from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed slof from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed snapd from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ubuntu-image from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed unifont from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed voluptuous from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added gcc-snapshot to i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: rsplib [amd64] (focal-proposed/universe) [3.2.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rsplib [ppc64el] (focal-proposed/universe) [3.2.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rsplib [s390x] (focal-proposed/universe) [3.2.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rsplib [arm64] (focal-proposed/universe) [3.2.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rsplib [armhf] (focal-proposed/universe) [3.2.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openexr [amd64] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openexr [i386] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openexr [ppc64el] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openexr [arm64] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openexr [armhf] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openexr [s390x] (focal-proposed/universe) [2.3.0-6] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: boxer-data [amd64] (focal-proposed/universe) [10.8.11] (no packageset)
<vorlon> landed last round of dropping deps from livecd-rootfs on i386.  Still 14 deps pulled in, but it's largely much more reasonable stuff like dosfstools and germinate instead of qemu and xen.
-queuebot:#ubuntu-release- Packageset: Removed brltty from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed device-tree-compiler from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed dh-lisp from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libcacard from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libiscsi from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed liblouis from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed qemu from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed seabios from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed spice from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed spice-protocol from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed usbredir from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed virglrenderer from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed vte2.91 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed xen from i386-whitelist in focal
-queuebot:#ubuntu-release- New: accepted boxer-data [amd64] (focal-proposed) [10.8.11]
-queuebot:#ubuntu-release- New: accepted openexr [amd64] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted openexr [armhf] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted openexr [ppc64el] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted qutip [amd64] (focal-proposed) [4.4.1-4]
-queuebot:#ubuntu-release- New: accepted qutip [armhf] (focal-proposed) [4.4.1-4]
-queuebot:#ubuntu-release- New: accepted qutip [s390x] (focal-proposed) [4.4.1-4]
-queuebot:#ubuntu-release- New: accepted rsplib [arm64] (focal-proposed) [3.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsplib [ppc64el] (focal-proposed) [3.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-leche [amd64] (focal-proposed) [2.3.0~dfsg-2]
-queuebot:#ubuntu-release- New: accepted openexr [i386] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted qutip [arm64] (focal-proposed) [4.4.1-4]
-queuebot:#ubuntu-release- New: accepted rsplib [amd64] (focal-proposed) [3.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsplib [s390x] (focal-proposed) [3.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openexr [arm64] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted qutip [ppc64el] (focal-proposed) [4.4.1-4]
-queuebot:#ubuntu-release- New: accepted openexr [s390x] (focal-proposed) [2.3.0-6]
-queuebot:#ubuntu-release- New: accepted rsplib [armhf] (focal-proposed) [3.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: spview [amd64] (focal-proposed/universe) [2.0.0~beta2-1] (no packageset)
