#ubuntu-release 2010-12-06
<stgraber> I uploaded a new ltsp yesterday to the archive. Upstream moved from implementing their own daemonizing code in python to using python-daemon, it'll need to be promoted to main. The three required MIRs (python-daemon, a build-dep and a dep) have been opened in LP so hopefully ltsp should start working again as soon as they've been approved.
<ScottK> stgraber: I'd recommend targeting the MIR bugs at Alpha 2 if you didn't.
<stgraber> ah, good point. Done
#ubuntu-release 2010-12-07
<lamont> oh btw, upgrading royal atm, you prolly don't want to build livecds for ppc
<lamont> and, in fact, the ssh to trigger will fail
<lamont> someone wanna kick off a daily livecd build on ppc ??  I want to see royal go through its paces
<cjwatson> in progress
<lamont> cjwatson: so I may have killed that when I was killing mine...
<lamont> natty and maverick fail atm, so i'm doing a lucid livecd
<lamont> cjwatson: fwiw, royal is now running lucid
<lamont> (just like adare, lets see how stable it is...)
#ubuntu-release 2010-12-08
<doko> Riddell: please could you wait a few hours with the kde uploads?
<doko> especially not uploading a new kdebindings before the armel build is in the archive
<Riddell> doko: why?
<doko> did you read my email about making python 2.7 the default today?
<Riddell> don't think I did
<GrueMaster> Can someone publish linux-image-2.6.35-24-omap?  It is pending publication, and I need to get it tested from -proposed before it can be released.
<GrueMaster> Still waiting for a kernel to get published.
<cjwatson> GrueMaster: processed; should be visible in ~1.5 hours
<GrueMaster> Thanks.  I've been asked to test it for two days now.
<cjwatson> it only appeared in the NEW queue six or seven hours ago.
<GrueMaster> I know.  But the kernel team released it yesterday.
<GrueMaster> And it was published for everything BUT armel.
<cjwatson> I can't make armel builds go faster :-)  I imagine somebody looked at the queue when armel hadn't finished building yet, that's all.
<GrueMaster> So it is a manual process.  Good to know.
<cjwatson> Any time package names change it requires manual intervention.
<cjwatson> Thus, any kernel ABI change requires manual intervention.
<sconklin> How can I solve this problem? - A source package containing an incorrect .orig.tar.gz (which had the correct file name) was uploaded to a ppa, and now I need to make that orig.tar.gz go away, or replace it with the correct one.
<cjwatson> sconklin: you'll have to ask #launchpad if there's a way - the Ubuntu archive admins have no control over PPAs
<sconklin> cjwatson: thanks
<cjwatson> (for Ubuntu the answer would be "the only way is to bump the upstream version")
<sbeattie> that's also pretty much true for ppas, as well.
<sconklin> that's a bit of a problem for the kernel ;-)
<sbeattie> sconklin: I don't disagree, and I also think it should be relaxed for PPAs versus the ubuntu archive, but that's what people in #soyuz tell me.
<cjwatson> there are some good reasons for it in corner cases around making corresponding source available, even for PPAs
<sbeattie> sconklin: it's *possible* for it to go away eventually from the ppa, if you delete it and wait on the order of a couple of weeks.
<sconklin> yeah. It's a case of totally understanding the rules and why they exist, but trying to unwind a mistake
<sconklin> ok, I tried deleting it and waiting an hour
<cjwatson> anyway, #launchpad may be able to advise on adminy options that are available
<sconklin> I'm asking there
<ScottK> sconklin: Make a different PPA and upload it there.  consistency among PPAs is not enforced.
<sconklin> ScottK:  this is our non-virtualized kernel build PPA
<ScottK> Yeah, well that makes it a bit tough.
<ScottK> You might arange for a hot spare in case it's needed.
<cjwatson> (corner cases: imagine that your new version fails to build on one architecture.  now ppa.launchpad.net is distributing source for the new version but can't distribute source for the old version due to a filename clash.  imagine you never bother to fix this.  is ppa.launchpad.net now violating the GPL?)
<sconklin> cjwatson: totally understood. And it's possible that someone (anyone) grabbed a copy of the built package
<ScottK> cjwatson: That wouldn't necessarily be an issue for a private PPA.  Perhaps the rules could be relaxed for those (I've got a use case for that).
<cjwatson> I expect actually that it's just too annoying to figure out the publication rules :-)
#ubuntu-release 2010-12-10
<bdmurray> skaet_: I'm going to make ubuntu-10.10 inactive as a milestone
<skaet_> bdmurray,  thanks!
<bdmurray> natty-alpha-1 should be deactivated too
<bdmurray> is this not on some checklist?
<ScottK> Seems to me if the milestone is passed it should be automatic.
<bdmurray> feel free to write that launchpad patch ;-)
<cjwatson> LP doesn't know right now whether the milestone is actually *done* rather than just slipped
<cjwatson> and telling it that it's done is basically deactivating the milestone ...
<cjwatson> (deactivated)
<cjwatson> I'll clear up bugs set to it later
<skaet_> cjwatson,   I started moving them over yesterday, but haven't finished.  :P
<skaet_> bdmurray, yeah you're right it should be on checklist.   if cjwatson hasn't added it already, I'll go add it.
<cjwatson> skaet_: please do
<skaet_> ack.
<skaet_> cjwatson,  will do after going to get some lunch :)
<skaet_> cjwatson, bdmurray - have moved over natty-alpha-1 milestoned bugs without fixes to natty-alpha-2.
<skaet_> https://launchpad.net/ubuntu/+milestone/natty-alpha-1 - looks pretty clean now.
#ubuntu-release 2011-12-05
<rickspencer3> pitti, around at all?
<pitti> hey rickspencer3
<rickspencer3> hey pitti, I have a silly question for you
<rickspencer3> basically, I wake up each morning and check https://jenkins.qa.ubuntu.com/view/Precise/ first thing
<rickspencer3> however, the daily builds are quite ready and so the smoke tests aren't run yet
<rickspencer3> this is going to sound crazy, but ...
<rickspencer3> is there anyway to start the dailies about 2 hours earlier so the results are there first thing in the morning here?
<rickspencer3> oops
<rickspencer3> the dailies *aren't* quite ready
<pitti> in theory that's possible, of course; in practice, we'd probalby need to adjust a lot of other images as well, as we shouldn't run them in parallel
<rickspencer3> hmmm
<pitti> unfortunately they failed over the weekend due to buildd lag
<pitti> we had a massive number of uploads on Friday due to armhf; not much we can do there, I'm afraid
<rickspencer3> indeed
<rickspencer3> pitti, this is far from an emergency situation, it would just be nice to be able to follow up on any significant problems first thing, rather than waiting
<pitti> actually, yesterday's desktops did build (and today's)
<pitti> rickspencer3: actually, I quite like them at the current time; it gives me about two hours to fix problems before we build images
<pitti> so at 6:30 my time I can look at http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html, and fix uninstallability in time for the image builds
 * rickspencer3 looks
<pitti> if we do them earlier, we'll need to re-spin a lot more often
<rickspencer3> pitti, that totally makes sense
<pitti> but yeah, I see how it would be nicer for you to have them earlier :)
<cjwatson> I think the reason I didn't originally want them too much earlier is that it reduces the chance of end-of-the-day Pacific time uploads being incorporated
<rickspencer3> so you look for problems in the archive before you try to spin an ISO
<pitti> so, we can have them earlier at the expense of lessening the probability of them succeeding
<rickspencer3> pitti, no that makes sense
<rickspencer3> I see that for you, daily quality starts *before* the builds and smoke testing
<rickspencer3> I think it's smarter to optimize for that
<rickspencer3> so ...
<rickspencer3> carry on :)
<pitti> rickspencer3: yes, our archive reports usually catch failures before we attempt the image build
<pitti> we get an hourly feedback loop with them
<rickspencer3> pitti, for your uninstallable packages report, can you tell which ones will cause the ISOs not to build?
<pitti> rickspencer3: yes
<pitti> rickspencer3: whenever ubuntu-desktop is uninstallable
<rickspencer3> does ubuntu-server have a similar metapackage?
<pitti> rickspencer3: it's not 100% correct (as we ship a few additional packages in live-ship), but usually good enough
<pitti> of ubiquity is uninstallable, that's bad as well, of coruse
<pitti> rickspencer3: no, I don't think so; but in general we just try to keep above list at zero
<pitti> so that all images will build
<rickspencer3> ok
 * rickspencer3 stops trying to gild the lily
<rickspencer3> thanks pitti
<rickspencer3> as usual, you are a true scholar and gentleman ;)
<pitti> rickspencer3: thanks to you, too; it's always good to check the justification of how we have things set up :)
<rickspencer3> jibel, pitti, can I assume that https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_encryptedhome/ fail because of bug #894768
<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: 23) (dups: 23) (heat: 353)" [High,In progress] https://launchpad.net/bugs/894768
<rickspencer3> ?
<cjwatson> rickspencer3: yeah, looks like the same bug
<rickspencer3> thanks cjwatson
 * rickspencer3 shakes fist at 894768
<rickspencer3> cjwatson, I know it's being worked on :)
<pitti> rickspencer3: correct, it's in the d-i syslog
<pitti> but nice that these builds now actually appear, thanks jibel for fixing that
<pitti> last week they just didn't appear at all
<pitti> rickspencer3: these days, when amd64 succeeds and i386 fails, it's most likely that bug
<jibel> rickspencer3, yes it is. line 2902 of d-i-syslog Dec  5 08:50:18 ubuntu install.py: IOError: [Errno 22] Invalid argument
<rickspencer3> ok
<rickspencer3> thanks guys
<cjwatson> uh, who just flushed my syncs?
<cjwatson> or removed, I can't tell
<infinity> cjwatson: Flushed, I'd guess, based on the build queues all shooting up.
<infinity> (And no idea who)
<doko_> cjwatson, I'm guilty ...
<stgraber> infinity: just saw your upload of livecd-rootfs, should that package get added to the list in https://wiki.ubuntu.com/NewReleaseCycleProcess?
<stgraber> good morning skaet
<skaet> goodmorning stgraber. :)
<infinity> stgraber: Nah.  The default suite in BuildLiveCD is a convenience to people hacking on it (to avoid passing "-d precise"), it makes no real difference.
<infinity> stgraber: The buildds all pass the suite explicitely anyway.
<infinity> (And I usually do when testing too, which is why I never notice the default)
<stgraber> ok
<cjwatson> Subject: LiveFS --f-omap4/ubuntu/armel+omap4 failed to build on 20111205
<cjwatson> uh
<slangasek> heh
 * cjwatson fails to puzzle that out
<infinity> cjwatson: Someone screwed up a manual build, I assume.
<infinity> cjwatson: ogra and I were puzzling over the same thing.
<infinity> cjwatson: The only way I could fathom that subject line is with --f on the buildlive command line.
<infinity> (Which is weird, in and of itself)
<infinity> cjwatson: Oli's suggesting we tag Log mails with SUDO_USER to call people out. ;)
<ogra_> well, we wouldnt need to log the name
<stgraber> jibel, skaet: http://91.189.93.73/qatracker/milestones/204/builds/7471/testcases/115/results/
<ogra_> but put "manual build" in the mail subject if SUDO_USER isnt empty
<ogra_> so we can at leats see its manual fiddling that caused it
<stgraber> jibel, skaet: So support for multiple results for the same user is there. There are still a few bugs around the feature though, will fix a bit later (need to get some food, then DMB meeting)
<infinity> ogra_: Pfft.  If you're going to go partway, just finish the job and make the subject line: "Nelson: Ha, ha, ${SUDO_USER} sucks!"
<ogra_> LOL
<skaet> infinity, ogra_ some of my manual tests didn't end until after midnight it appears,  so I could be the culprit.   All of them suceeded (they were no publish though).
 * skaet was doing timings on arm builds yesterday
<infinity> skaet: I assume the conclusion was "slow"?
<ogra_> well, i got that failure mail 90min ago ...
<skaet> infinity,  glacial
<ogra_> livefs builds should take 90min each
<skaet> infinity,  I'll bounce you the numbers...   arms the highwater mark now on full respins.
<ogra_> plus about 30-40 for the post live-build stuff cdimage/debian-cd do
<infinity> skaet: It always was.
<ogra_> so all in all 2.5h for one image
<skaet> ogra_ yeah,  that's about what I was seeing.
<ogra_> we used to have 4h builds, dont complain !
<ogra_> :)
<skaet> :)  yeah, but we have more images to build now,  so.... ;)
<ogra_> indeed
<infinity> I'll have it all parallelised by February, at least.
<ogra_> well, spice seeds would help with that
<infinity> ogra_: livefs-in-soyuz will help more.
 * skaet looking forward to the parallelization.  :)
<ogra_> 90min for buildlive once and then 15min per subarch to mangle it ;)
<infinity> ogra_: Don't sell something we're not (currently) working on. ;)
<infinity> ogra_: But livefs-in-soyuz, I've promised for this cycle.
<ogra_> infinity, well, i always wanted to just have a three layered casper filesystem setup ... one for rootfs, one for kernel/modules and a cow
<skaet> stgraber,  excellent.   :D
<ogra_> that would have solved it earlier
<skaet> cow?
<ogra_> copy on write :)
<skaet> lol
<ogra_> else i would have written pony ... i'm not *that* much into cows :)
 * skaet was definitely wondering about those cows.  ;)
<ogra_> infinity, when i was about to start on that we came up with preinstalled so i never implemented it
<infinity> Anyhow.  Once lamont and I get the armhf builder to admit that it's actually meant to build things, I might spin ubuntu/armhf+omap for the lolz.
<infinity> Shame we don't have a more useful kernel yet.
<ogra_> omap4 would really be nice
<infinity> Well, I could probably make ti-omap4 build without any serious effort.
<infinity> I just don't want to step on toes, and ppisati said he was on it.
<ogra_> you could just cp it on ports :)
<infinity> Uhm, no.
<infinity> I'd have to repack it, at the very least.
<infinity> But no.
<infinity> And many other times no.
<ogra_> heh
 * cjwatson checks that ogra doesn't have a cocoplum account :-P
<ogra_> lol
<ogra_> infinity, btw, looking at buildlive, SUDO_USER would always be set ...
<infinity> Eh?
<ogra_> (if root runs it it forcefully sudos to "cdimage")
<ogra_> if [ "$(id -u -n)" != "cdimage" ]; then
<ogra_>         exec sudo -H -u cdimage $0 "$@"
<ogra_> fi
<ogra_> (or cron or whoever)
<infinity> No, that's if a user runs it.
<infinity> It's legacy code.
<ogra_> though, cron runs it as cdimage
<infinity> cron executes it as cdimage.
<ogra_> snap
<ogra_> k
<charlie-tca> I broke the daily testing tracker
<charlie-tca> it won't let me update an in-progress test
<charlie-tca> http://91.189.93.73/qatracker/milestones/204/builds/7503/testcases/131/results
<stgraber> charlie-tca: that's likely my fault :)
 * stgraber looks
<charlie-tca> Okay, I will agree ")
<stgraber> charlie-tca: ah, could it be you didn't see the UI change?
<stgraber> charlie-tca: you can now post multiple results
<charlie-tca> huh?
<stgraber> charlie-tca: so you need to click on the edit icon to change an existing one
<charlie-tca> but I can not update the test that says in-prgress. It errors
<stgraber> ah, ok, that part is probably my fault then :)
<charlie-tca> Should I post the error to pastebin?
<stgraber> nope, got it in the log
<charlie-tca> Okay
<stgraber> resultid does not exist
<stgraber> fixing
<charlie-tca> Anyway, I did the test and it worked today
<stgraber> charlie-tca: should be fixed now
<charlie-tca> stgraber: Thank you
<stgraber> I'd expect removal of results to still be broken though, that's pretty high on my to-fix list (post DMB meeting)
<charlie-tca> Worked now. That is great!
<stgraber> cool
<jibel> stgraber, nice, there will some ui work though, because it is not really intuitive.
<jibel> and I confirm that removal of results is a bit broken ATM
<stgraber> jibel: yep, wokring on the removing results part. I agree the UI is not terribly intuitive, especially after 4 years of a similar UI that could only add/update the results :)
<jibel> stgraber, no problem, step by step
<stgraber> jibel: oh, actually, removed results are only a problem for admins because we're supposed to see them and that part of the code fails :)
<stgraber> jibel: fixed. So now admins should be able to see any removed result (you can restore by updating them without any change) and users can only see their own removed results (and restore them too)
<stgraber> hehe, I guess http://91.189.93.73/qatracker/milestones/204/builds/7471/testcases/115/results is a good example of what an admin can expect to see on release week :)
<stgraber> maybe with a few less removed results though :)
<stgraber> which reminds me I need to make the LP integration script a bit more clever to avoid tagging bugs linked to a removed result
<jibel> stgraber, and blacklist bug 1 please :)
<ubot4> Launchpad bug 1 in tilix (and 28 other projects) "Microsoft has a majority market share (affects: 1119) (dups: 2) (heat: 5202)" [High,New] https://launchpad.net/bugs/1
<jibel> sorry
<stgraber> jibel: yeah, I guess a bugnumber blacklist could be useful :) I did a mass remove of that one last week but I'm sure we have many more like it
<stgraber> I see we have 0, 2 and 5 on the list of bugs that have never been updated from LP
<stgraber> I'll cleanup these that are clearly invalid, that should make the cronjob a bit faster
<stgraber> jibel: qatracker=> DELETE FROM qatracker_bug WHERE bugnumber IN (0,2,5,91919191,3737384,5577744);
#ubuntu-release 2011-12-06
<rickspencer3> hey pitti, jibel
<rickspencer3> https://jenkins.qa.ubuntu.com/view/Precise/ :,(
<jibel> rickspencer3, there is a problem with jenkins
<pitti> eek
<jibel> i.e not with the images. the slaves didn't restart this morning
<jibel> pitti, rickspencer3 jenkins is back.
<rickspencer3> yeah
<jibel> I'll trigger all the jobs
<rickspencer3> thanks jibel
<rickspencer3> did you find the problem?
<pitti> jibel: merci beaucoup
<tumbleweed> can someone plesae process archive-admin sync requests?
<cjwatson> I did yesterday, but there were a few I shelved until I could think about them properly; is there something you care about particularly?
<tumbleweed> ah, I thought they'd been piling up, because I hadn't seen one I approved go through
<cjwatson> iftop?
<cjwatson> processing that one now
<tumbleweed> sorry, should have said, yes, thanks
<mvo> fwiw, I uploaded release-upgrader-{apt,python-apt} to lucid-proposed now, the libs/release-upgrader-python-apt packages are co-installable with the apt/python-apt on lucid and it will not affect the regular system in any way. a updated update-manager is ready too and can land once this is availalbe in -proposed. I tested the upgrade with my PPA (that has the packages too) and its working there
<infinity> mvo: Shiny.
<skaet> mvo,  :)
#ubuntu-release 2011-12-07
<pgraner> slangasek, you about?
<slangasek> pgraner: ish
<slangasek> pgraner: what's up?
<pgraner> slangasek, hey weired apt-get install validation error on davidm's machine
<slangasek> ah?
<pgraner> slangasek, davidm is going to give you the pastebin
<davidm> slangasek, sent
<slangasek> davidm, pgraner: behind a proxy, by any chance?
<pgraner> slangasek, taipei office
<pgraner> slangasek, not sure if there is one here
 * doko_ curses the renamed ruby sources and starts removing ...
<cjwatson> pgraner: I mailed davidm a likely local solution
<pitti_> doko: oh, some of them appear to have been renamed in Debian; just removed libfeedtools-ruby
<pitti_> doko: (I'm currently running process-removals)
<doko> pitti_, ahh, ok, please do the remaining ones too
<pitti_> doko: do you want to handle them and I ignore them? or should I just leave it to process-removals?
<pitti_> doko: ah, roger; doing that then
<doko> pitti_, just saw these on http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html
<pitti_> there's still a ton of them indeed
<pitti_> doko: will that page automatically remove entries for removed packages?
<doko> pitti_, I assume you won't see the sources there once the source is removed
 * ogra_ runs a manual armhf image build, dont be surprised if you get build failure mails :)
<ogra_> bah, live-build doesnt know about hf
<ogra_> (well, it does, but FLAVOUR doesnt seem to get set for the kernel)
 * ogra_ tries with explicitly set subarch
<ogra_> hmm, intresting, it doesnt seem to fail
 * ogra_ wonders why it doesnt work with just setting the toplevel arch
<ogra_> wohoo
<ogra_> first armhf image built !
<pitti_> ogra_: wow, enough of main built now?
<pitti_> ogra_: does it actually boot? :_0
<pitti_> :-) even
<ogra_> pitti_, yesterday already
<ogra_> i didnt try yet
<ogra_> the netinst ones booted yesterday when tobin tested
<ogra_> so i would expect the preinstalled ones to boot too
<ogra_> but first of all i will try to build each of them manually before i do further tests
<ogra_> we're weeks ahead of teh plan anyway so i can take my time :)
<skaet> ogra_ great!!
<ogra_> yeah, isnt it :)
<skaet> :)
<ogra_> doko, and infinity seriously deserve a fat (and i mean *F*A*T*) bonus this cycle :)
<skaet> :)
 * skaet makes sure to add armhf into the image set for alpha2  
<ogra_> yeah
<ogra_> i personally would love to drop armel asap if we dont find massive issues with hf
<skaet> yup,  now on to getting it well tested and dealing with the issues (hopefully not massive).  ;0
<skaet> :) even.
<ogra_> well, i woudlnt expect many ... but we'll see
<ogra_> my task for today is to have them all handbuilt once (modulo mx5)
<ogra_> and if they all build, have them autobuilt from tomorrow on
<ogra_> ha ! forst feedback for the ac100 image from the community ...
<ogra_> it boots !
<ogra_> *firsst
<skaet> :)
#ubuntu-release 2011-12-08
<ogra_> hmpf, why does my manual omap4 armhf build fail with oem-config being out of sync
<ogra_> bah, ftbfs on hf
<ogra_> install: cannot create regular file `debian/ubiquity/usr/lib/ubiquity/flash-kernel/flash-kernel-installer': No such file or directory
<ogra_> GRMBL !
<ogra_> weird, f-k-i udeb should be there
<ogra_> cjwatson, could it be that we miss an update of the integrated udeb stuff in ubiquity ?
<ogra_> (to pick up armhf bits)
<ogra_> hmm, no, should have happened
 * ogra_ scratches head ... the udeb is on ports.u.c, the last ubiquity upload claims to have it picked up but still it doesnt seem to be in the source
<cjwatson> ogra_: that's fixed in bzr
<ogra_> cjwatson, yes
<cjwatson> I'll do a quick upload now
<ogra_> dont clash with infinity !
<ogra_> :)
<cjwatson> oh, if he's doing it, fine
<cjwatson> yeah, I notice he fixed my broken symlinks :)
<ogra_> well, he sounded like :)
<ogra_> hmm, seems infinity didnt upload
<mvo> hi, I wonder if someone could review the release-upgrader-{apt,python-apt} in lucid-proposed, it would be nice to get it in there so that we can start with the lucid->precise auto-upgrade-testing properly (i.e. testing the multiarch transition on amd64)
<pitti> mvo: sure, doing an SRU run now
<mvo> \o/
<pitti> mvo: hm, I don't see it in https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
 * mvo looks
<mvo> subject: [ubuntu/lucid-proposed] release-upgrader-python-apt
<mvo>         0.8.0ubuntu9+upgrader1 (New)
<mvo> subject: [ubuntu/lucid-proposed] release-upgrader-apt
<mvo>         0.8.16~exp5ubuntu13+upgrader1 (New)
<pitti> oh, new
<mvo> its both source and binary new
<mvo> as it needs to be co-installable
<pitti> mvo: my  main nitpick is that the version number is higher than the original one
<pitti> 0.8.16~exp5ubuntu13+upgrader1
<pitti> it would be safer to do 0.8.16~exp5ubuntu13~upgrader1
<pitti> for lucid->precise that won't be a problem
<pitti> but for lucid->maverick or lucid->oneiric it will
<pitti> mvo: for libapt-pkg4.11 and the other common package names
<pitti> mvo: will we get a conflicts:/replaces: in precise for the new release-upgrader-libapt-pkg-dev etc. packages to clean them up?
<mvo> pitti: indeed, I'm happy to fix the version number, good point
<mvo> pitti: the release-uprader-libapt-pkg-dev will never be installed directly its just used for building release-upgrader-python-apt so I have not actually considered adding a C/R there
<pitti> mvo: ok
<pitti> mvo: but we need one for release-upgrader-python-apt, I suppose
<ogra_> sigh, finally ubiquity published
 * ogra_ tries another omap4 armhf build
<pitti> mvo: ok, I'll reject the two uploads; I'm happy with + -> ~, will accept those
<mvo> pitti: release-upgrader-python-apt> indeed, good point. I was actually planning to just use the normal release-upgrader cleanup handle this, but doing it at the packaging level is pretty nice
<pitti> mvo: ah, in cleanup sounds fine
<pitti> mvo: it's only r-u which will pull it in in the first place
<pitti> so whatever is easier
<mvo> yeah
<mvo> thanks a bunch for the review, I will fix the mentioned issues and re-upload
<pitti> mvo: issues? it's just the version number, right?
<mvo> yes
<mvo> maybe issues is a bit strong of a word for that :)
<ogra_> disasters ?
<ogra_> :)
<mvo> lol
<elmo>   workrave |    1.9.3-2 | natty/universe | source, amd64, armel, i386, powerpc
<elmo>   workrave | 1.9.4-2~oneiric1 | oneiric-backports/universe | source, amd64, armel, i386, powerpc
<elmo>   workrave |    1.9.4-3 | precise/universe | source, amd64, armel, i386, powerpc
<elmo> how is that possible?
<elmo> as in, why would it not be in oneiric at all?
<pitti> elmo: in oneiric it was uninstallable/unbuildable
<pitti> so it got removed
<pitti> it was ported to the gnome-panel-3 stuff too late for oneiric
<elmo> blink
<elmo> ok
<elmo> do we not enable -backports by default yet?
<elmo> s/not //
<pitti> I thought we do now, but with pinning so that you need to opt-in still
<pitti> mvo: ^ right?
<cjwatson> right
<cjwatson> apt-setup (1:0.49ubuntu5) oneiric; urgency=low
<cjwatson>   * Enable backports by default now that we have NotAutomatic enabled and
<cjwatson>     working.
<elmo> hmm
<cjwatson>  -- Iain Lane <laney@ubuntu.com>  Thu, 12 May 2011 08:39:39 +0100
<cjwatson> dunno about upgraded systems
<mvo> yeah, I don't think the release-upgrader adds them, that sounds like a bug
<Laney> hmm?
<Laney> ah, yes, I would expect it to be added on upgrades too
<elmo> is there some way to "reset" my sources.list to what it would be on a default install?
<elmo> (short of finding a fresh install somewhere and copying it across)
<slangasek> none that I can think of
<stgraber> infinity: looks like I need to upload a new edubuntu-meta adding armhf? (just got a build failure)
<infinity> stgraber: Almost certainly.  But check your germinate-created package lists and see if it's even near complete.  If not, not much point yet.
<infinity> stgraber: (If there are any blockers, let me know, we're still unsnagging a lot of universe)
#ubuntu-release 2011-12-09
<stgraber> infinity: are you still around for another 30min or so? I may need you to change ~/.isotracker.conf on nusakan
<stgraber> infinity: http://iso.qa.ubuntu.com is almost good to go, so will need to switch the target once I kill http://91.189.93.73 (so we avoid daily builds showing up on the wrong one)
<stgraber> slangasek: ^
<stgraber> we're ready for the switch now
<stgraber> just replace http://91.189.93.73 to http://iso.qa.ubuntu.com in ~/.isotracker.conf (cdimage user I believe)
<stgraber> morning pitti
<stgraber> pitti: can you update ~/.isotracker.conf (see above)?
<pitti> good morning
<pitti> stgraber: done
<pitti> stgraber: but it says "still under maintenance", is that expected?
<stgraber> pitti: yes, I was waiting for someone to switch the target of the dailies before I switch it to production mode and disable the temporary one
<pitti> ah :)
<stgraber> ok, opened the new one and closed 91.189.93.73. We now have an all new and shiny tracker at http://iso.qa.ubuntu.com
<stgraber> Seems like everything is working, so calling it a day, back in 8 hours or so :)
<pitti> stgraber: still says "under maintenance"
<pitti> stgraber: thanks, sleep well!
<stgraber> pitti: argh, that's annoying... let me hit the cache harder
<stgraber> pitti: any better now?
<pitti> ah, yes!
<stgraber> Drupal's aggressive caching is really, well, aggressive :)
<Laney> Somebody points out in #-motu that DebianImportFreeze mentions unstable, and that the release schedule links there instead of LTSDebianImportFreeze. Which fix should we do?
<infinity> Laney: Documenting DIF twice seems odd.  Combining the two pages into one that explains why it's sometimes unstable and sometimes testing might make more sense.
<Laney> I thought it would be easiest to just remove 'unstable'
<infinity> Laney: (But for now, linking the PreciseReleaseSchedule to LTSDIF works, I guess)
<Laney> it's not as if that document is the canonical reference for the dafault sync source
<infinity> Well, both pages seem subtly different too.
<Laney> LTS... says "(and tested)" and does not mention autosyncs of NEW packages.
<Laney> I do not think it's true that new packages aren't autosynced from testing.
<infinity> It's not true, no.  We still autosync.
<Laney> so AFAICS the differences aren't meaningful
<infinity> I wouldn't say so, no.
<Laney> we can check with skaet later I guess
<infinity> I think instead of saying "from Debian <release>", another line that explains that sometimes we sync from unstable and sometimes from testing, and this is determined at the beginning of each cycle by the release team...
<infinity> (While we more or less have followed the non-LTS->unstable, LTS->testing trend, I see no reason to state that as a future fact)
<Laney> indeed, it should be a per-release decision
<Laney> there should be a place to document it
<infinity> Well, LP knows the parent series.
<infinity> At least, it does now. :P
<Laney> ah, yes, lp/ubuntu/release
<infinity> I think documenting these things in too many places is just asking for them to be out of sync.
<infinity> And LP is authoritative on the matter, now that syncing is a native affair.
<Laney> There should be one place that things point to. That's what I was after. Even better if it's used by tools too.
<ogra_> doe that look ok for adding a "manual build" notification to the failure mails ? http://paste.ubuntu.com/764832/
<ogra_> *does
<ogra_> (in cdimage that is)
 * ogra_ would like a typo check before committing ... i cant see any issue but that doesnt mean much :P
<infinity> ogra_: I'd probably write it as MANUALTEXT="(built by ${SUDOUSER}) "
<ogra_> k, no prob
<infinity> ogra_: And smoosh it right against $PROJECT (otherwise, you get an extra space when it's not set)
<ogra_> yeah, well, whats an extra space :P
<infinity> s/SUDOUSER/SUDO_USER/
<infinity> Extra spaces are the devil's work!
<ogra_> heh
<infinity> ogra_: Need a trailing space.
<infinity> MANUTEXT="(built by ${SUDO_USER}) "
<ogra_> === modified file 'bin/buildlive'
<ogra_> --- bin/buildlive	2011-12-02 06:14:28 +0000
<ogra_> +++ bin/buildlive	2011-12-09 12:04:52 +0000
<ogra_> @@ -20,6 +20,11 @@
<ogra_>  	DIST="$3"
<ogra_>  fi
<ogra_>  
<ogra_> +MANUTEXT=
<ogra_> +if [ -n "${SUDO_USER}" ]; then
<ogra_> +	MANUTEXT="(built by ${SUDO_USER})"
<ogra_> +fi
<ogra_> +
<ogra_>  datestamp="$(date +%Y%m%d)"
<ogra_>  
<infinity> pasting here might not have been clever. :P
<ogra_>  RES=""
<ogra_> @@ -118,7 +123,7 @@
<ogra_>  	 	ADDRESSES="$(get_notify_addresses "${PROJECT%-dvd}")"
<ogra_>  	 	if [ "$ADDRESSES" ]; then
<ogra_>  			wget -q -O - "http://$machine/~buildd/LiveCD/$DIST/$PROJECT${SUBPROJECT:+-$SUBPROJECT}${subarch:+-$subarch}${UBUNTU_DEFAULTS_LOCALE:+-$UBUNTU_DEFAULTS_LOCALE}/latest/livecd-${datestamp}-${arch}.out" | \
<ogra_> -	 		mail -s "LiveFS $PROJECT${SUBPROJECT:+-$SUBPROJECT}${subarch:+-$subarch}${UBUNTU_DEFAULTS_LOCALE:+-$UBUNTU_DEFAULTS_LOCALE}/$DIST/$arch failed to build on $datestamp" \
<ogra_> +	 		mail -s "LiveFS $MANUTEXT$PROJECT${SUBPROJECT:+-$SUBPROJECT}${subarch:+-$subarch}${UBUNTU_DEFAULTS_LOCALE:+-$UBUNTU_DEFAULTS_LOCALE}/$DIST/$arch failed to build on $datestamp" \
<ogra_>  	 			-a 'X-Generated-By: buildlive' \
<ogra_>  	 			$ADDRESSES
<ogra_>  	 	fi
<ogra_> argh !
<ogra_> sorry
 * ogra_ czrses to not have middle click ... 
<ogra_> http://paste.ubuntu.com/764840/ was what i meant to paste
<infinity> ogra_: Also, I'm reviewing on nusakan, no need to paste at all. :P
<ogra_> haha
<ogra_> k
<ogra_> well, i'll merge if you dont scream now
<infinity> ogra_: s/${SUDO_USER})"/${SUDO_USER}) "/
<ogra_> fixed
<infinity> Lovely.
<infinity> The name of the variable is a bit odd.
<ogra_> eek
<ogra_> ogra@nusakan:/srv/cdimage.ubuntu.com$ bzr pull
<ogra_> Using saved parent location: /srv/cdimage.ubuntu.com/bzr/private/cdimage
<ogra_>  M  bin/buildlive
<ogra_> Text conflict in bin/buildlive
<ogra_> 1 conflicts encountered.
<ogra_> hmpf
<ogra_> i'm sure my tree in ~ is up to date
<ogra_> hmm, someone seems to commit directly to the production tree
<ogra_> grmbl
<infinity> Or not commit.
<infinity> It was uncommitted changes you ran into.
<ogra_> oh
<infinity> And wrong ones, at that...
<ogra_> oh my
<infinity> Is that Michael doing weird things to make jani's live build go? :/
<ogra_> he shouldnt have to change anything
<ogra_> NCommander, ^^^^ ????
<ogra_> he only needs to set a var to not make it publish when running the build
<infinity> Yeah, but that s/arch/cpuarch/ thing looks pretty suspect.
<infinity> Oh, wait, that's just log fetching?
<infinity> Whatever.
<infinity> Just manually merge your bits.
<infinity> Or I will.
<ogra_> feel free
<infinity> There.  Merged.
 * ogra_ looks at default-arches now to enable hf for desktop and server 
<infinity> And whoever's uncommited crap that is better claim it.
<ogra_> i'll run into the same issue with the next commit them i guess
<ogra_> *then
<infinity> Only if you commit to buildlive again...
<infinity> In those same lines. :P
<ogra_> no, to etc/default-arches only
<infinity> Yeah, default-arches has no uncommitted changes.
<infinity> You're fine.
<ogra_> i see far more issues than buildlive here
<ogra_> etc/purge-days
<ogra_> etc/config
<infinity> Yeah, I know.  There are lots of bits uncommitted.
<infinity> But not the file you're about to edit.
<ogra_> bin/publish-release
<infinity> (No need to paste this all)
<ogra_> k, i trust you :)
<ogra_> infinity, can you take a look ? i'm not sure about the server bit ...
<infinity> ogra_: Eh?
<ogra_> the change to default arches
<infinity> ogra_: Yeah, that was wrong. :)
<infinity> I'll fix.
<ogra_> heh
<ogra_> i'll never understand that thing
<ogra_> sigh
<infinity> Oh, actually.  It might have been accidentally right.
<infinity> ubuntu-server/preinstalled matches twice.
<ogra_> only for maverick builds, no ?
<ogra_> oh, its maverick-
<ogra_> ignore me :P
<infinity> Ahh, no.  I was right.
<ogra_> the bottom thing needs to go and the maverick- line needs hf, right ?
<infinity> Yeah.
<ogra_> s/to go/reverting/
<ogra_> k, then i understand it right
<infinity> Already fixing.
<ogra_> (until i want to touch it again and forgot all tis next time :P )
<infinity> Meh.  I really should move all this armhf stuff to precise- lines.
<infinity> Incoming mess.
<ogra_> that would at least make it easier to understand
<ogra_> i really struggel with all these wildcards ... especially if i havent touched it fro a few months
<infinity> Trust me, I didn't just make it easier to read. :P
<ogra_> (and i need typing training)
<infinity> adconrad@nusakan:~/cdimage$ CDIMAGE_ROOT=. ALL_DISTS="lucid maverick natty oneiric precise" bin/default-arches ubuntu-server daily-preinstalled oneiric
<infinity> armel+omap armel+omap4
<infinity> adconrad@nusakan:~/cdimage$ CDIMAGE_ROOT=. ALL_DISTS="lucid maverick natty oneiric precise" bin/default-arches ubuntu-server daily-preinstalled precise
<infinity> armel+omap armel+omap4 armhf+omap armhf+omap4
<infinity> Better.
<ogra_> as elegant it is, i must admit i found the cluttered crontab better
 * infinity commits.
<infinity> ogra_: Fixed in production now.
<ogra_> yep, just pulled
<infinity> ogra_: Calling default-arches helps to figure out what you've done.
<ogra_> ah, cool, i didnt even know there was a binary
<ogra_> (i could indeed have looked ... but i have a slighly distracted day today)
<infinity> It's not the most intuitive thing to call, mind you.
<infinity> But at least you can do it from your branch.
<ogra_> yeah, seeing that above
<infinity> (See above for calling convention)
<infinity> I'm going to catch a nap before morning meetings and work.
<ogra_> can you do the release meeting ?
<ogra_> since michael doesnt seem able to
<infinity> I have a conflicting linaro meeting. :/
<ogra_> ah, k, i'll try to get tobin to do it then
<infinity> I can fix that, but not for the one in a few hours.
<ogra_> yeah
<ogra_> its only for today anyway ...
<stgraber> pitti: didn't we get Ubuntu dailies today?
<pitti> stgraber: we did
<pitti> http://cdimage.ubuntu.com/daily-live/20111209.1/
<pitti> http://cdimage.ubuntu.com/daily/20111209/
<stgraber> hmm, ok, they aren't on the tracker...
<pitti> $ cat .isotracker.conf
<pitti> [general]
<pitti> url=http://iso.qa.ubuntu.com/xmlrpc.php
<pitti> username=ubuntu-cdimage
<pitti> password=<secret>
<pitti> default_milestone=Precise Daily
<pitti> stgraber: looks ok?
<stgraber> yep, that looks good
<stgraber> checking the build logs now, maybe we'll get a nice python trace in there :)
<stgraber> ok, I see a "Failed to add build to the tracker"
<stgraber> now to figure out why exactly
<stgraber> ok, got the same from here at least
<ogra_> i might be late to the release meeting ...
 * ogra_ needs to pick up his car from the other side of the city and the shop closes right after the meeting
<ogra_> (please someone forward that to kate if i dont manage)
<stgraber> pitti: digging a bit more, the API seems to work, though not the admin API for some reason. While I do that, do you have a way to get a list of everything that build since "Ubuntu Server i386" (20111209)?
<pitti> stgraber: we didn't do any manual builds today, so we should have exactly one build for each flavour
<pitti> i. e. just the cronjobs
<pitti> server starts at 06:29
<pitti> so that would be: ubuntu desktop/alternate
<ogra_> note that we autobuild armhf images from today on ...
<pitti> kubuntu desktop/alternate
 * ogra_ hopes that doesnt confuse anything on the tracker 
<pitti> edubuntu dvd
<pitti> kubuntu dvd
<pitti> sorry, scratch edubuntu, that goes earlier
<pitti> studio, mythbuntu, lubutun
<pitti> that's it
<pitti> everything else builds before server
<pitti> stgraber: ^
<stgraber> pitti: ok, thanks. I found the problem (squid server in front of the tracker blocks http auth), so only the public API works. I'm talking to IS to have that fixed, then I'll just push all of these again
<stgraber> ogra_: I don't think we have armhf on the tracker and probably not in our mapping table so it shouldn't be a problem, though we'll need to add it
<stgraber> pitti: I think I fixed them all by hand, in the process I noticed a few don't seem to get posted automatically, likely because of a wrong or missing mapping in the script. That's: Kubuntu Mobile armel+omap3, Kubuntu Mobile i386, Wubi i386 and Wubi amd64
<stgraber> (these all had daily builds today but never had a daily registered on the tracker)
<stgraber> skaet: good morning
<stgraber> skaet: and look at our shiny new http://iso.qa.ubuntu.com :)
<stgraber> (still talking to IS about the authenticated API currently not working)
<skaet> stgraber,  *\o/*
<pitti> skaet: good morning
<pitti> skaet: FYI, kenvandine will join the release meeting today instead of me, as I need to leave a little earlier
<skaet> pitti, good afternoon.  :)
<skaet> pitti,  ok.
<skaet> thanks for letting me know.
<skaet> stgraber,  delighted to see the new tracker - awesome way to start the day.
<gilir> hi, all lubuntu desktop daily isos are currently not published, I think there is a little problem in the publisher script : http://paste.ubuntu.com/765014/
<stgraber> pitti: add lubuntu to the list I gave you before (of things building with a wrong/missing mapping) :)
<Laney> skaet: earlier we were talking about merging LTSDebianImportFreeze with DebianImportFreeze â noticed because the latter is linked from the release schedule and still says that we are syncing from unstable
<Laney> what do you think?
<stgraber> gilir: is that actually making the build fail or just not publish them on the tracker?
<stgraber> gilir: because when I added them all manually this morning (problem with the API...) I didn't see a 20111209 build of lubuntu
<gilir> stgraber, I think only the publishing, I didn't see any failure in the log about the build
<stgraber> gilir: ah right, just saw the timestamp, that was yesterday's. So the tracker is up to date
<skaet> Laney,  oversite,  and yes will fix.
<skaet> :)
<skaet> thanks for flagging.
<Laney> AFAICS we should remove the word "unstable" from DebianImportFreeze and add a sentence saying to look at launchpad.net/ubuntu/<release> to see where we are syncing from
 * ogra_ is back ... just in time it seems :)
<skaet> Laney that's a better solution,  agreed.
<Laney> :-)
 * NCommander waves (sorry for being a bit tardy)
<ogra_> NCommander, i'm here, no need to cover ...
<ogra_> i just made it in time
<Laney> looks like current ben is still compatible with the old input format
<Laney> and it also now contains code to generate an index
<Laney> win and win
<scott-work> skaet: sorry i missed the meeting, work was inescapable this morning
<skaet> scott-work,  no worries.
<skaet> scott-work,  I'll be posting links to all the other teams, and the IRC minutes in the agenda today.
<skaet> Laney, https://wiki.ubuntu.com/DebianImportFreeze
#ubuntu-release 2011-12-10
<skaet> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-12-09 - has updates from today's meeting in it now.
<skaet> one item to highlight,  that didn't get discussed at the meeting.   gcc 4.6 is being updated to 4.6.2-6ubuntu1.  doko sent out email before the meeting but it got blocked by mail-list.  unblocked now, and reference added.
<skaet> details are in the minutes and on the ubuntu-release mail list
<slangasek> ah, is that why it seemed to come late
<slangasek> skaet: has someone whitelisted him now?
<skaet> slangasek,  I should have when it went through but forgot,   next time will do,  or he could subscribe ;)
<slangasek> yes, he could :)
 * skaet --> weekend.  :)
<mdeslaur> pitti: oneiric's linux-meta needs to go from -proposed to -security, ABI doesn't currently match
<infinity> Wait, there's a mailing list? :P
<infinity> mdeslaur: I can look at that.
<infinity> mdeslaur: You mean from proposed to updates?  linux and linux-meta in security seem to match (both 13).
<infinity> mdeslaur: But updates has a mismatch (14 and 13)
<infinity> mdeslaur: (proposed to updates copy done)
<mdeslaur> infinity: thanks!
<hggdh> just marked bug 849745 critical. I think this should be considered for Alpha2, certainly for SRU, given the number of affected users.
<ubot4> Launchpad bug 849745 in software-center (Ubuntu) "software-center crashed with DBusException in call_blocking(): org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (affects: 67) (dups: 56) (heat: 478)" [Critical,Triaged] https://launchpad.net/bugs
#ubuntu-release 2012-12-03
<ScottK> stgraber: Yes.
<stgraber>  ScottK ok. Can you say so in the ubuntu-release@lists.u.c thread?
<ScottK> stgraber: Riddell already did.
<stgraber> ScottK: ah? https://lists.ubuntu.com/archives/ubuntu-release/2012-November/ and https://lists.ubuntu.com/archives/ubuntu-release/2012-December/ don't seem to agree
<stgraber> and there's nothing in the moderation queue
<cjohnston> stgraber: do you know where the code is for http://reqorts.qa.ubuntu.com/reports/boot-speed/ by chance?
<ScottK> OK.  Done.
<stgraber> cjohnston: nope
<stgraber> ScottK: thanks
<ScottK> Seems I mis-remembered.
<ScottK> No problem.
<cjohnston> thanks stgraber
<infinity> ScottK: APAC woke up, rocs is building belatedly on armhf/quantal-proposed now.
<ScottK> infinity: Thanks.
<infinity> ScottK: When you get a moment, can you review and let the above hugetlbfs into lucid-backports?
<ScottK> Is it tested?
<infinity> Yeahp.  stokachu had it tested.
<infinity> (So says the bug log)
<infinity> Do backports uploads auto-close bugs, or do I need to do it manually?
 * infinity goes to look.
<ScottK> No.  They don't, but I already did it.
<infinity> Ahh, thanks.
<ScottK> It wasn't actually even filed against backports.  Fixed that too.
<infinity> Oh, yeah.  The backport bug tracking is a bit odd to me.  The lack of per-pocket bugs targeting makes it sketchy, I guess.
<ScottK> Each release is a separate project in LP.
<Riddell> hmm I'm sure I e-mailed ubuntu-release
 * ScottK thought so too, but didn't see it.
 * ScottK did a backup mail and covered it though.
<Riddell> my sent-mail says I sent it to stgraber directly, silly me
<Riddell> doesn't explain why he hasn't seen it but
<infinity> I dunno about him, but I spam filter all mail with Scottish accents.
<stgraber> Riddell: well, I've had e-mail problems on Friday and likely lost an hour or so of e-mails. I re-checked all my mailing-lists manually for anything I'd missed, but there's not much I could do for private e-mails
<Riddell> jings and crivvens
<infinity> Great, now I need to start filtering IRC.
<infinity> Also, http://en.wiktionary.org/wiki/crivvens is brilliant: "See also: cripes and crikey".
<cjwatson> Grr, getting live-build to install linux-generic-lts-quantal correctly is unexpectedly difficult
 * ogra-cb wonders if the chinese images are built using a different build system ... bug 1085918 shows the same timestamp i use for nexus7 images but thats set only based on the subarch 
<ubot2> Launchpad bug 1085918 in ubiquity (Ubuntu) "Chinese raring desktop images have different format of media-info to that of standard desktop images" [Undecided,New] https://launchpad.net/bugs/1085918
<xnox> ogra-cb: i'd like to know where the chinese images are...
<ogra-cb> the bug points to them
<ogra-cb> http://china-images.ubuntu.com/raring/daily-live/current/
<ogra-cb> its likely only a conicidence that they use the same timestamp format. but its irritating
<cjwatson> The Chinese images use ubuntu-defaults-builder.
<cjwatson> Which is based on live-build / livecd-rootfs, but another layer.
<ogra-cb> xnox, i would also see a bug in utah here ... it should eb able to handle such stamps too
<ogra-cb> (specifically because all arm images and images will have it)
<ogra-cb> (well, all preinstallled ones at least)
<xnox> ogra-cb: sure, but ideally we standartise on some kind of parsable format.
<ogra-cb> yes, for preinstalled where the stamp is created on the live builder we cant know if it is yyyymmdd.n or just yyyymmdd
<ogra-cb> so there must be another format that still makes it possible ot have more than a build per day
<ogra-cb> if the stamp is added during post processing you code can check whats in the www dir alreday, cant do that from a live builder easily
<ogra-cb> *your
<xnox> ogra-cb: or the stamp can be yyyymmdd.HHMM
<ogra-cb> oh, sure
<xnox> and that has ~ same machine parsability.
<ogra-cb> but that will require code changes all over the place if you want consistency
<ogra-cb> i.e. to make the download dirs use that
<ogra-cb> and i'm not sure we would want that (breaks likely lots of download scripts out there)
<ogra-cb> i think we should rather determine the version string at the very beginning of the build and export it to the live builder
<ogra-cb> (and to all other scripts indeed, but these are on teh same machine anyway)
<psivaa> xnox: i am seeing bug 1085961 when i do side by side installations
<ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [Undecided,New] https://launchpad.net/bugs/1085961
<xnox> ogra-cb: I am not talking about urls, I am only talking about the format/regexp of the image/iso diskid.
<xnox> ogra-cb: which we can use in ubiquity & utah etc.
<ogra-cb> xnox, usually that corresponds to the url
<xnox> ogra-cb: no. all urls use current/ symlink.
<xnox> ogra-cb: and that's the canonical url, the rest may or may not exist as we rotate them a lot & images may not be build today.
<ogra-cb> i.e. an iso from  cdimage.u.c/daily/20121201.1 will have exactly that timestamp insiuude too
<ogra-cb> and i think thats wanted
<ogra-cb> current is just a link to the latest of these timestamped dirs
<xnox> ogra-cb: apart from that url -> file mapping is not always true (e.g. as we see in preinstalled & chinese images), while current->latest symlink is correct across all of them.
<ogra-cb> preinstalled just got that added two weeks ago ... and simply because i couldnt come up with anything better
<xnox> ogra-cb: that gives me confidence that url != file is ok, but file having a different format within image is / can be a problem.
<ogra-cb> chinese looks more like a bug
<xnox> ack.
<ogra-cb> url != file is not ok, it is there because i introduced it lacking a better implementation
<ogra-cb> the proper implementation would be as i said above, figure out the stamp at the very beginning and hand them to the respective scripts ... currently the stamp is only used in post processing
<ogra-cb> which we dont do for preinstalled
<xnox> ogra-cb: ack.
<xnox> ogra-cb: and ubuntu-defaults builder should be fixed to generate more similarish timestamps.
<ogra-cb> i simply didnt want to hack up the whole code of cdimage ... introducing yyymmdd-hhmm was just the way of least resistance for an unsupported image
<ogra-cb> i dont mind replacing the dash with a dot for now ... but effectively it wont fix the bug
<ogra-cb> that can only be done by a bit of redesign
<ogra-cb> i might even drop the whole thing again if we decide to switch to xz for nexus7 which means we would re-pack the tarball on nusakan anyway
<ScottK> It would be nice if someone in SRU (I uploaded it, so I can't) would review ^^^ so we don't end up hold all of KDE 4.9.3 up for it.
<cjwatson> infinity,slangasek: ^- livecd-rootfs 2.65.4 - YA in the secure boot saga
<cjwatson> This time I've actually tested the image build (which is currently failing in precise :-/)
<ScottK> stgraber: Now that I created the Alpha 1 milestone in the tracker, is everything going to get added automatically?
<ScottK> It'd be nice to only have the Kubuntu stuff in there so people don't get confused.
<stgraber> ScottK: yeah, I still need to setup some scripts to avoid that ^
<stgraber> was planning on doing that this afternoon :)
<ScottK> Excellent.
<ScottK> IIRC, that's not far off.
<cjwatson> Has anyone decided on whether a partial britney freeze is needed, and if so of what package(set)s?
<stgraber> ScottK: alright, I removed everything from the alpha-1 milestone. I'll add the Kubuntu desktop products to the manifest so that they'll auto-publish when we start building at 21:00 UTC today
<stgraber> cjwatson: I didn't get any request so far, so I'm hoping not
<ScottK> stgraber: Can we have the current images in there manually?
<ScottK> (for Kubuntu)
<ScottK> I added them manually when I set up the milestone.
<stgraber> ScottK: ok, added.
<ScottK> Thanks.
<stgraber> ScottK: you added them with an invalid version number (.0), so that's why I removed them earlier
<ScottK> Yes.  I messed that bit up.  I wasn't sure what to put in.  Thanks for fixing.
<stgraber> btw, we may end up having an Edubuntu alpha-1 after all. Seems like highvoltage will have enough time to take care of it all by himself.
<stgraber> we'll have the final decision by 21:00 UTC
<ScottK> Cool.
<stgraber> highvoltage: edubuntu added to the alpha-1 manifest, first builds will show up a bit after 21:00 UTC
<slangasek> cjwatson: livecd-rootfs accepted
<xnox> stgraber: yeah, so ubiquity-gtk frontend will be exercised ;-)
<cjwatson> slangasek: thanks
<infinity> cjwatson: Oh, FWIW, verified over the weekend that the britney hack for d-i/udeb block/pass works fine.  So, that takes some pressure off d-i upload timing.
<slangasek> block/pass/pick/fumble/touchdown
<infinity> I don't understand, that's not hockey.
<cjwatson> Good good, thanks.  (Not that I was feeling the pressure anyway, I must say; the worst case was NBS.  The difficult sync is between d-i and seeds ...)
<infinity> cjwatson: Yeah, seeds are a bit sketchy still.  I've been trying to time my seed updates to when d-i hits disk on ftpmaster, which isn't an ideal thing for normal mortals to try to do. :P
<infinity> cjwatson: Maybe that could do with some rethinking.  I was going to use the word "automation", but I don't really want automated commits to seed branches.
<cjwatson> infinity: Quite.
<cjwatson> infinity,slangasek: I've fixed britney to require at least one up-to-date binary on at least one architecture before promotion, regardless of any exceptions for slow architectures.
<infinity> cjwatson: That should do.  Thanks.
<slangasek> sounds good
<ScottK> heka had a chroot problem failure, but it must have been gremlins/cosmic rays because the retry hit heka again and worked fine.
<infinity> When we finally get decent ARM buildds, I intend to send a Panda from the DC to every member of ~launchpad-buildd-admins and ~ubuntu-release to mutilate as they please.
<micahg> infinity: can I get on the list for one please :)
<infinity> Heh.
<infinity> micahg: I see your firefox finally built. :P
<micahg> infinity: yeah, last time it muttered about a \37....
 * micahg didn't ask it to fnid Amelia Earhart, just to build firefox...
<slangasek> infinity: mutilating machines that contain no spinning parts is way less fun
 * ScottK looks around for some spare dynamite.
<ScottK> Depends on how you do it.
<sbeattie> slangasek: the point is to make the parts that are not spinning spin.
<sbeattie> or at least, that's what I go for.
<sbeattie> YMMV and all that.
<ogra-cb> its pandaboards, you can just make them spin completely with pretty low effort
<ScottK> This proposed thing is handy when a package update gets uploaded to the archive instead of a PPA by mistake ...
<slangasek> heh
<ScottK> Which package owns the first startup screen in the installer (the one that Ubuntu doesn't show by default, where you, for example, set up an OEM install)?
<infinity> Sounds like ubiquity.
<infinity> Do you have a string from said screen?
<ScottK> "Boot from first hard disk"
<ScottK> That one is particularly relevant because it's trying to boot from my USB stick again.
<infinity> Oh, pre-boot?
<ScottK> Yes.
<ScottK> The one that you have to hold shift down in Ubuntu to see.
<infinity> That would be syslinuxish, though the actual menus don't come from syslinux.
<ScottK> So in the case of picking the wrong thing to boot from, what package do I blame?
<infinity> I'm trying to sort that out...
<ScottK> Thanks.
<slangasek> your bios? :)
<infinity> debian-cd writes the menus.
<infinity> label hd
<infinity>   menu label ^Boot from first hard disk
<infinity>   localboot 0x80
<slangasek> "Boot from first hard disk" is done via BIOS calls; if the "first hard disk" it's booting isn't the one you want, that's a BIOS issue
<infinity> And yeah, that's just booting 0x80, so if your BIOS is remapping your stick, that's correct.
<infinity> And it's arguably correct for your BIOS to remap your stick when you select it as the boot device.
<ScottK> Hmmm.
<infinity> (Though this behavious varies wildly between machines)
<slangasek> solution: upgrade your firmware to UEFI
<infinity> behaviour, too.
<slangasek> then you can't run syslinux at all, problem solved
<infinity> Hahaha.
<infinity> "solved".
<ScottK> So does this option actually do any good?
<infinity> ScottK: It made a lot more sense on CDs, which were never remapped.
<ScottK> Right.
<infinity> ScottK: And it makes sense for people who burn our images to DVDs (same argument).
<slangasek> right, if the issue is that you're booted *from* the USB stick, it should probably detect that and translate it to 0x81 instead
<infinity> That's probably still more common than USB sticks, except for serial reinstallers.
<ScottK> slangasek: That sounds sensible.
<infinity> slangasek: That's a fair chunk of extra magic to ask of syslinux.
<slangasek> IIRC the same el-torito boot image is used for both CD and hybrid USB booting, so this magic would have to be in syslinux
<slangasek> infinity: it doesn't hurt to ask
<ScottK> Also it doesn't have to detect it's a USB, it would have to detect that the device it's about to try to boot from is the same one it's already booted from.
<infinity> But yeah, one could do an "if current device = 0x80, shift all menu lookups by 1" or something.  I guess.
<infinity> I'm not sure if it can even reliably know this.
<ScottK> From the discussion, it seems like that would do it.
<infinity> Not without more code than it has room to run.
<infinity> Still, yeah, a mildly annoying buglet.
<ScottK> I'll file it and then it will be what it will be.
<ScottK> Turns out there is an existing bug.
<infinity> Hrm.
<infinity> Looks like "localboot -1" triggers int 18h, which should force your BIOS to try the next boot device.
<infinity> Of course, that's likely wildly buggy from machine to machine as well.
<infinity>                 cmp ax,-1
<infinity>                 je .int18
<infinity> .int18:
<infinity>                 int 18h                         ; Hope this does the right thing...
<infinity>                 jmp kaboom                      ; If we returned, oh boy...
<infinity> Such faith in his own code there...
<ScottK> Heh.
<ScottK> Bug #1066387 in case you want some place to document findings.
<ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
<ScottK> BTW, the continuous quality push seems to be showing.  I got through all the Kubuntu test cases for i386 with  no failures.
<infinity> \o/
<ScottK> The syslinux thing was the 2nd most annoying bug I found.
<infinity> That bug's been around forever, so hardly counts.  What was the first most annoying bug?
<ScottK> http://launchpad.net/bugs/1086047
<ubot2> Launchpad bug 1086047 in qapt (Ubuntu) "Firefox installer fails in raring" [High,Fix released]
<ScottK> The Kubuntu package install mechanism was broken.
<ScottK> (for adding specific packages)
<infinity> Ahh.
<ScottK> qapt-batch
 * infinity nods.
<persia> re: bug 1066387 : what problem is the "boot from first HD" option attempting to solve
<ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
<slangasek> persia: to let you boot from the hard drive if you've accidentally left the CD in the drive
<slangasek> without having to reboot and/or fiddle
<persia> Given that it won't work with any machines that have a preinstall of Windows 8 or OS X > 10.6, how much longer should this remain relevant?
<persia> (plus we did tell the user to remove the CD in order to perform the reboot, although some hardware lets one ignore this)
<slangasek> persia: any machines that have a preinstall of Windows 8 won't see syslinux at all
<slangasek> I don't know that this bug is anything we're going to invest time in fixing
<slangasek> but I think it's true that it's a bug
<persia> Makes sense: rather than trim syslinux to just not show this for the dwindling use case, leave it as a known issue, and let it expire as BIOS becomes irrelevant.
 * ScottK doesn't have a strong opinion about fixing/removing, but thinks one of them should happen.
<cjwatson> Ultimately the boot menu needs to move to GRUB for all architectures, but it's a non-trivial chunk of work to migrate the menu interface over.
<cjwatson> Something I've tried to push up the hill before.  It may get higher-priority as UEFI becomes more common.
<cjwatson> If we do it for UEFI then we can ditch syslinux across the board and rejoice.
<cjwatson> Longish-term plan though.
<persia> What produces txt.cfg?  I don't see it in the syslinux source.
<slangasek> I believe that's in the debian-cd branch
<cjwatson> Either that or debian-installer.
<stgraber> ScottK: so I'm assuming you don't want your 21:00 UTC respin?
<ScottK> stgraber: We do.  I want the newer qapt in.
<ScottK> The qapt-batch bug didn't cause the test case to fail, but it's still a significant bug.
<stgraber> ScottK: ok, so should I kick a respin now?
 * ScottK is lost in TZ math.
<stgraber> it's 21:48 UTC :)
<stgraber> or :50 even
<ScottK> Right.
<ScottK> So if the 2100 respin is out of date for qapt, yes.  Please.
<persia> It is in debian-cd, although in the branch, and not the package.  From infinity's suggestions, I get the impression that the bug should be retargeted, but I'm not sure of the semantics of that, as it's not in the debian-cd ubuntu package, nor in the debian-cd trunk branch on LP.  Can we do specific branch-targeting of bugs?
<persia> (unless someone believes it to actually be a bug in syslinux code)
<slangasek> it's a limitation of syslinux code
<slangasek> well, or there's that -1 option, isn't there
<slangasek> so I'm actually not sure how that works when you've got a mapped eltorito image
<persia> What's the limitation in syslinux?  If it's being told to boot 0x80, and it does, why is this wrong?
<slangasek> because 0x80 is the disk you just booted from
<slangasek> so boot 0x80 is a loop
<slangasek> I'm not sure you can properly solve this is a hybrid-friendly manner in bios
<persia> Sure.  I agree it's a bug.  I'm just not convinced it's a syslinux bug, but rather a debian-cd bug.
<persia> I'm not sure why syslinux shouldn't boot from BIOS-mapped first hard drive when instructed to "localboot 0x80"
<slangasek> persia: er, show me how you can tell syslinux to dtrt
<slangasek> it's a debian-cd bug iff there's already a way to express this to syslinux
<slangasek> anyway, the place to target would be the ubuntu-cdimage project
<persia> Ah, OK.  Not having hardware that does such BIOS mapping, I'll leave that alone then (as I can't test the -1 option).
<infinity> I think the word "bug" is a bit harsh in this case.  Misfeature, perhaps. :P
<infinity> The (potential) problem with switching to -1 is that some BIOSes, upon remap, may remove your HDD entirely from the boot list, so 18h would trigger floppy, then fail.
<infinity> But that's theoretical, since I have no idea what any one person's weird BIOS will do. :/
<ScottK> But that's at least no worse off.
<infinity> Barring that potential strange behaviour, though, 18h is probably what one actually expects to happen, since it's just the generic "this boot device sucks, fall through to the next" call.
<infinity> 18h being what, for instance, PXE firmware will do when it fails to get a BOOTP server, etc.
<cjwatson> persia: bugs on our debian-cd branch go on the ubuntu-cdimage project
<cjwatson> oh, slangasek said that
<persia> But you also saying it changes my mind to actually do the retarget, as opposed to wait longer for someone to test the -1 thing with appropriate hardware before retargeting.  It can always come back, if it turns out to really be a syslinux thing.
<infinity> cjwatson: We could switch to -1, call it "Attempt to boot from next device..." and call it good. :P
<cjwatson> We could.  I'm not much interested, TBH :-)
<cjwatson> I suspect that'll attract a different set of bugs.
<infinity> Yeah, I don't really care deeply either way.  The obvious solution to "it doesn't work" is "remove the USB stick, doofus".
<infinity> cjwatson: In the known-working case (CDs), -1/18h should work just as well.
<cjwatson> Assuming sane BIOS ...
<infinity> cjwatson: In the USB case, it'll likely just break in a different set of weird BIOS cases.
 * infinity doesn't care terribly if it just stays kinda broken anyway, given that "I left the disk in the drive, oops" is a time-honored "I own a PC, and did a stilly thing" deal.
<persia> Added an ubuntu-cdimage task: someone should set it to wontfix or switch to -1, and set it to fixreleased (and be willing to argue with folk about which is the right thing for follow-on reports).
<infinity> Note that this isn't remotely a "new" bug.  Well, as new as the ability to boot USB thumb drives.
<infinity> I don't see that dealing with it suddenly became urgent. :P
<slangasek> that doesn't seem to be stopping anybody from talking it to death though :P
<ScottK> slangasek: We could talk about systemd instead, if you'd prefer.
<ScottK> ;-)
<slangasek> doesn't bother me none
<ScottK> It seems to be the recent driver for most extensive flogging of a dead horse I've seen lately.
#ubuntu-release 2012-12-04
<phillw> jbicha: ping
<jbicha> phillw: hi
<infinity> cjwatson: WTF at that yate patch.
<infinity> cjwatson: (Notably, why on earth didn't it fail everywhere?)
<cjwatson> infinity: Indeed, I can't figure that out
<cjwatson> infinity: My best guess is that the optimiser did a better job of noticing that it was unused on every other architecture; but I have no idea why
<infinity> Bizarre.
<cjwatson> Also can't really see why it worked in quantal.
<cjwatson> (And I don't buy my own optimiser theory; building that file with -O0 on i386 still works.)
<infinity> I'd like to blame binutils, cause that's always a sensible thing to do.
<infinity> (And it's the only thing that changed drastically since quantal)
<cjwatson> I don't think it's the linker.  If I build just that .o on i386 and armhf, armhf has the FaxHandler::received undefined reference while i386 doesn't.
<cjwatson> If you want to blame binutils it has to be the assembler, I think, which seems far-fetched.
<infinity> Oh, seriously?  Hrm.
<cjwatson> (I haven't compared .S)
<infinity> That's just weird.
<cjwatson> I got bored of tracking it down through the toolchain once I realised the code was Just Wrong anyway.
<phillw> a very quick Q. which you will tell me off for... Is there some sort of time scale for bug 1040037 getting into quantal?
<ubot2> Launchpad bug 1040037 in cups-filters (Ubuntu Quantal) "Libreoffice will no longer print landscape page" [High,In progress] https://launchpad.net/bugs/1040037
<infinity> I wonder if the php-horde mess has been fixed in unstable yet.
<infinity> Looks like no.  Bah.
<ScottK> phillw: You should ask tkamppeter_
<phillw> Scottk when and where does he appear?
<ScottK> phillw: #ubuntu-devel
<phillw> thanks :)
<jbicha> he's Europe-based
<infinity> A fix for that is in the queue, asking Till won't help.
<infinity> phillw: It'll get reviewed and (potentially) accepted when it does.
<phillw> infinity: it is working... ubuntu-uk have confirmed as it affects news letters etc. I was just curious if it needed any more 'yeah it works' stuff, but as it has come from 'above' I'm really out of my depth.
<infinity> phillw: Hard to confirm it works before it's been built. :P
<phillw> infinity: the 'R' works.. rule #1 of SRU :P
<phillw> infinity: soz, it was #ubuntu-advertising
<phillw> infinity: http://pastebin.com/EBrTie21
<phillw> and then you can tell me off, again.
 * infinity points phillw 2 minutes back in backscroll.
<infinity> Or 3.
<phillw> infinity: phillw: Hard to confirm it works before it's been built.
<phillw> as it has been built.. I'm really missing something on how these things happen :(
<infinity> phillw: It was only just accepted to quantal 7 minutes ago.
<infinity> phillw: Though, before you kept giving me supporting evidence as to why I should accept it, apparently.
<phillw> infinity: I apologise, I thought I was being gentle as the email was quite a few hours earlier. I did tell them to be patient this evening but it is now 02:12 UTC here and I was asking for an update. Thank you ever so much, the guys will wake up to good news :)
<ScottK> This reminds me ...
<ScottK> It might be time to recruit some more new bodies for the SRU team.  I don't get the impression we're keeping up and I have this suspicion that next week SpamapS will have less time rather than more for SRU work.
<infinity> No, we're not keeping up particularly well right now, but that upload was only a few days old.
<phillw> is the backlog testing proposed SRU's ?
<infinity> No.
<infinity> Well, I'm sure there's a backlog there too, and I wouldn't turn down people doing verification.
<infinity> But in this case, no.  The backlog is review.
<infinity> Though, when bdmurray is done rewriting sru-accept, I might find more joy in the process. :P
<phillw> I cannot help on review, but may be able to help on verification
<slangasek> infinity: corresponding precise version of mountall on its way to the queue now, btw
<infinity> slangasek: Oh, did you already SRU all this mess back to precise, thinking it was shiny and good?
 * infinity missed when that happened.
<slangasek> infinity: it's in precise-proposed now, I v-failed it
 * infinity dies a little inside, reading ns3's debian/rules.
<slangasek> queuebot is on vacation?
<infinity> Why do people think "convert to dh(1)" means "keep your old rules file, but add dh $@ to it"?
<infinity> slangasek: queuebot was speaking up just a while ago.
<slangasek> ah, right, it's around but has just scrolled off my screen already ;)
<slangasek> infinity: because it's the naive way to incrementally improve your rules?
<infinity> You and I have varying definitions of "improve".
<infinity> It becomes seemingly nondeterministic when you do that.  (Not actually nondeterministic, but confusing enough for a human to sort out).
<slangasek> it's possible I've misunderstood your description of the changes, then; but that's probably ok, I don't really need to know
<infinity> Heh.
<micahg> well, if I ever find some time again, I might consider trying to join -sru
<infinity> micahg: We only ask for about 75% of your week, no big deal.
<micahg> infinity: heh, if that was work time, that's fine :P
<infinity> There's non-work time?
<micahg> I'm trying to rediscover what that is :)
<stgraber> infinity: between christmas and new year
<stgraber> (apparently)
<infinity> stgraber: *rimshot*
<cjwatson> infinity: Indeed, if you leave targets such as 'build' in place, it can get very confusing.
<infinity> cjwatson: Yep.
<cjwatson> Oh boy, my flood of Multi-Arch: foreign patches to Debian to support cross-build is producing a moderately steady counter-flood of confused maintainers trying to work out what multiarch is
<infinity> Hahaha.  Score.
<infinity> I love how out of touch DDs seem to be about things like this.
<cjwatson> Though I actually can't blame them for being confused about how it interacts with cross-building
<infinity> (I'm in that boat too, obviously not WRT multitouch, but sometimes I don't get the memo about some large/obvious change for years)
<infinity> The joys of working on a very large system.
<infinity> s/touch/arch/... Stupid SRUs have me with touchpads on the brain.
<infinity> ... and trying to sort out how a bug about a misbehaving Thinkpad touchpad ended up with a patch to asus-touchpad.sh
<cjwatson> ScottK: Do you know if there's a plan to multiarchify boost?
<ScottK> cjwatson: I do not know.
<Mirv> unity-2d 5.14.0-0ubuntu1 has been in the precise SRU queue for >1 month, and bursting with enthusiasm to get to users! also, unity-lens-applications
<psivaa> xnox: Reported bug 1086339 on manual partitioning, not sure if its related to bug 1085961.
<ubot2> Launchpad bug 1086339 in ubiquity (Ubuntu) "Can not install raring desktop with manual partitioning" [Undecided,New] https://launchpad.net/bugs/1086339
<ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [Undecided,New] https://launchpad.net/bugs/1085961
<xnox> psivaa: ack, thanks.
<psivaa> xnox: yw
<cjwatson> stgraber: Could you test the current precise Ubuntu desktop image on SB-enabled hardware?  It *should* work now, I think
<cjwatson> Took me a while to get the image building pieces in place
<stgraber> cjwatson: ok, I'll do a test later today
<cjwatson> Thanks!
<stgraber> alright, let's have some fun with SecureBoot, back in 30min, hopefully...
<stgraber> cjwatson: first try doesn't look too good. This time around I get to grub but after selecting an entry all I'm getting is a black screen.
<stgraber> I'm rewriting the image to my phone (which for some reason stops exporting the USB device after a reboot...) and will try again with set debug=all
<cjwatson> Hmph.
<stgraber> cjwatson: hmm, is vmlinuz signed?
<stgraber> root@castiana:/boot# sbverify vmlinuz
<stgraber> No signature table present
<cjwatson> Huh, I thought it was
<stgraber> apparently not, so my machine won't be able to boot it because of the shim bug
<cjwatson> But you're right, blast
<cjwatson> I'll try yet again
<cjwatson> (Getting Quite Bored of SB)
<stgraber> cjwatson: well, at least we have a pretty comprehensive list of things that can go wrong with SB images ;) I'm almost tempted to write a testing script checking that the partition table is correct, that the fs structure is fine for EFI, that shim and grub exist and are signed, that grub.cfg looks right and that vmlinuz is signed. If all of those match, it's pretty sure it'll at least boot (install is a whole other problem).
<cjwatson> stgraber: the cause of this is a 403
<cjwatson> Which is aggravating
<cjwatson> I wonder how many goes this livecd-rootfs SRU is going to take
<infinity> A 403?
<cjwatson> Just uploaded YA livecd-rootfs/precise-proposed to fix it
 * infinity looks.
<infinity> cjwatson: Oh, *facepalm*
<infinity> cjwatson: Accepted.
<ScottK> stgraber: Would you please stop cron from building the Kubuntu Alpha 1 images?
<ScottK> At UDS we talked about a ~2 day transition freeze during the scheduled milestones for just the relevant packages.  Did anyone look into how to do that yet?
<stgraber> ScottK: cron should have been stopped yesterday, did you actually get dailies today?
<ScottK> stgraber: No.
<ScottK> I guess we didn't.
<stgraber> good, so working as expected then :)
<ScottK> Yes.
<ScottK> How about the other question?
<stgraber> ScottK: for package freezes, cjwatson said he probably could figure some way to freeze a package set or a list of sources if needed, though the code doesn't exist yet, so if you need it for alpha-1 it may be a bit tricky
<ScottK> I don't know that we NEED it.
<ScottK> It's probably more of a concern for Edubuntu since you've got to worry about what the desktop team may choose to upload.
<tumbleweed> freezing a list of packages should be doable with britney hints
<ScottK> Yes.  The trick is getting the right list.
<cjwatson> Right, the mechanics of freezing aren't hard (s/^/block /), but I don't think I can usefully contribute to coming up with a list if that's what you want
<ScottK> I think I have a list.
<ScottK> At least for Kubuntu.
#ubuntu-release 2012-12-05
<ScottK> http://paste.debian.net/214431/
<ScottK> stgraber: ^^^
<ScottK> Riddell: I was thinking that we ought to freeze transitions for everything on the images tomorrow AM (when stgraber is awake) do one final respin to get current and then test that until we're ~ready on Thursday).
<ScottK> How does that sound?
<ScottK> I think it's up to Edubuntu separately if they want to put a block in place or not.
<stgraber> I don't think Edubuntu is planning to respin, but I haven't explicitly asked highvoltage about it
<ScottK> The test results didn't look good on the ISO tracker.
<ScottK> Not sure if you care for an Alpha 1.
<ScottK> "block" works on source packages as well as binaries, right?
<cjwatson> ScottK: It only works on source packages.
<ScottK> OK.  Then my list should be right.
<cjwatson> I've obviously not checked the details but I'm OK with such a block going in for a couple of days
<ScottK> OK.
<ScottK> I got the list by looking at the seed structure and cat'ing the relevant .sources files together and then de-duplicating.
<ScottK> It wasn't pretty, but I think it's ~right.
<cjwatson> You might want to compare against actual images, just in case.
<cjwatson> Assuming you can come up with a reasonably efficient binary-to-source function
<cjwatson> (I usually can but it's a bit late for me)
<ScottK> Well, it seems I manage to have no KDE at all in there, so clearly I missed something.
<highvoltage> ScottK, stgraber: I wasn't planning on requesting a re-spin. We could potentially fix some issues, but it's an alpha so I don't particularly care about the issues as long as they're listed as known issues
<ScottK> OK
<Riddell> ScottK: yes that sounds like a good plan
<ScottK> OK.
<ScottK> stgraber: As the U-R dude for this milestone, would you please write a mail to u-d-a letting people know?
<cjwatson> stgraber: I've built a new precise daily that actually has the signed kernel on (though I haven't tested the installer with this yet)
<doko> cjwatson, gcc-4.7-armhf-cross doesn't migrate from proposed, because it thinks that armhf and powerpc builds are needed
<infinity> doko: That's not why at all.
<infinity> doko: It's not migrating because hrw broke some dependencies, we've already discussed it.
<doko> ahh, ok
<doko> or not ok, bad hrw
<infinity> doko: Basically, he stopped building biarch packages because he ran into a build failure he couldn't figure out, and that broke the gcc-4.6-cross stuff that depended on those packages.  So, our options are either fix his biarch builds or un-bi-arch the 4.6 stuff (or drop the 4.6 stuff entirely).
<infinity> doko: He promised he'd look into the first option, before we look at the other two.
<infinity> I might look into it in the next week or two if he doesn't get to it.
<doko> cjwatson, infinity: the gettext b-d issue was s/gettext:any/gettext/, yes?
<infinity> doko: Yes.  It not a critical issue to revert it (nothing's broken, per se), but the gettext:any stuff is unnecessary now, that's all.
<psivaa> cjwatson: Precise desktop images seem to have some problem, i386 is not available, amd64 images do not have casper/vmlinuz
<infinity> psivaa: Look again.
<psivaa> infinity: thanks, they appear now
<cjwatson> doko: yes
<cjwatson> infinity: disagree, :any breaks
<cjwatson> it's not allowed with M-A: foreign and some tools (inc. apt IIRC) enforce that
<cjwatson> psivaa: precise amd64 images have /casper/vmlinuz.efi
<cjwatson> (which is bootable as non-UEFI too, but the rename was necessary for installer reasons)
<infinity> cjwatson: Ahh, fair enough.  doko uploaded the revert/fix anyway.
<infinity> Also, WTF:
<infinity>   if test "$cross_compiling" = yes; then :
<infinity>   ap_cv_void_ptr_lt_long=yes
<infinity> if test "$ap_cv_void_ptr_lt_long" = "yes"; then
<infinity>     as_fn_error "Size of \"void *\" is less than size of \"long\"" "$LINENO" 5
<infinity> fi
<infinity> Brilliant.
<cjwatson> infinity: I discovered the glory that is AC_CHECK_SIZEOF last night
<infinity> "If cross-compiling, just fail hard for no good reason" is how I read that.
<cjwatson> Look at its implementation - it's worth it
<infinity> Hahaha.  Googling for this brings up an upstream commit fixing it (yay), but also the following mailing list post detailing someone's "workaround" to crossing apache:
<infinity> ./configure  --host=arm-linux-uclibc  LIBS=-lpthread apr_cv_process_shared_works=set ap_cv_void_ptr_lt_long=no ac_cv_sizeof_struct_iovec=8 apr_cv_tcp_nodelay_with_cork=yes ac_cv_func_setpgrp_void=no  ac_cv_file__dev_zero=yes --prefix=/usb/sda1/apache
<infinity> "Let's just preseed every potentially broken test and carry on."
<cjwatson> The principle of dpkg-cross ...
<infinity> Yeah, but we live in a brave new post-dpkg-cross world.
<infinity> (Where I'm honestly impressed that most of this "just works" at this point)
<gema_> hi release team, someone on call?
<gema_> I'd like to know status (in the queue) of bug 1085961 and bug 1060327
<ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [High,Confirmed] https://launchpad.net/bugs/1085961
<ubot2> Launchpad bug 1060327 in compiz (Ubuntu) "compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327
<gema_> .. which are impacting a lot our testing
<gema_> and the ability to install Raring
<gema_> EOM
<cjwatson> I'll have a look at the first one
<gema_> cjwatson: thanks
<cjwatson> Might be best to ask the desktop/unity teams directly about the second
<gema_> cjwatson: ack, will do
<didrocks> gema_: is this crash on top of errors.ubuntu.com
<didrocks> ?
<gema_> didrocks: I don't its ranking, but I know this crash is making people unable to test on vbox
<gema_> didrocks: which is really bad
<didrocks> gema_: can we have the question asked just on one channel? it's currently split up on 2 :p
<didrocks> so just pick one please ;)
<xnox> didrocks: it's blocking the installation (since ubiquity now uses compiz). One "workaround" is to seed metacity back on to the ubuntu desktop cds, such that users can complete installation while this bug is being fixed.
<xnox> & respin.
<didrocks> ok, it's the first time I'm pinged with that one, so status is "unknown" and not on the priority list right now
<gema_> didrocks: sorry, I was trying to make people aware of the issue
<gema_> :)
<xnox> didrocks: ack.
<didrocks> I'll put that on the priority list when I have the meeting with the 13.04 maintenance team
<didrocks> (next week)
<didrocks> sounds good to you?
<xnox> gema_: i maybe over-reacting here.
<gema_> didrocks: not really, since it is blocking testing
<didrocks> is that happening on every virtualbox run, starting the raring iso?
<gema_> didrocks: manual testing
<xnox> gema_: does this bug only happens post-install in try-ubuntu session, or can this be triggered during install-ubuntu?
<gema_> xnox: let me find you some (I believe) duplicates
<gema_> xnox: bug 1085171
<ubot2> Launchpad bug 1085171 in ubiquity (Ubuntu) "installer doesn't appear Ubuntu AMD 64 in Vbox" [Undecided,Confirmed] https://launchpad.net/bugs/1085171
<didrocks> 11:31:46 didrocks | is that happening on every virtualbox run, starting the raring iso?
 * didrocks would like an answer
<gema_> didrocks: I will get you one, need to talk to nick about it, he has been following the progress of it
<didrocks> is it on "try ubuntu" or the ubiquity session?
 * xnox does not like virtualbox at all, there are many problems with virtualbox which we can or might not be able to fix.
<didrocks> would be good to have data about how critical this is so that I can weigh in before pinging about it with OMG it's urgent :p
 * xnox wishes we can just not support virtualbox.
<gema_> didrocks: understood, there's also bug 1080437
<ubot2> Launchpad bug 1080437 in ubiquity (Ubuntu) "no background during the 13.04 daily install" [Undecided,New] https://launchpad.net/bugs/1080437
<didrocks> gema_: so no live session it seems, but reliably on the install one?
<xnox> gema_: no background is known & unrelated as it is present regardless of virtualisation / bare metal.
<gema_> didrocks: judging from the iso tracker, I'd say it is quite widespread, but I will get balloons input and get some input from my team as well
 * didrocks stop bother about this until we get data and what is impacted first :)
<gema_> didrocks, xnox thanks for the pointers
<didrocks> so waiting for ballons :)
<gema_> yep
<didrocks> thanks gema_, xnox!
<didrocks> keep me posted
<gema_> will do
<xnox> gema_: if people report VirtualBox issue, they should also report virtual box version numbers (proprietary vs opensource edition) (from ubuntu archive vs from oracle)
<xnox> and also if it is reproducible in KVM or not.
<gema_> xnox: ok, we'll need to train them to do that
<psivaa> didrocks: i tried with virt manager and it happens in every live session, bug 1086036
<ubot2> Launchpad bug 1060327 in compiz (Ubuntu) "duplicate for #1086036 compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327
<xnox> gema_: it is better for them to stop using VirtualBox and instead use virt-manager - a graphical interface for kvm which is similar if not better than virtualbox.
<gema_> xnox: Virtualbox is not going to go away
<didrocks> psivaa: ok, that's more interesting, and it's raring only? not quantal?
<gema_> xnox: until we decide to stop supporting it
<psivaa> didrocks: only raring
<didrocks> interesting, as unity raring is (until today) the exact same than unity quantal
<didrocks> so maybe a rdepends is triggering this
<didrocks> psivaa: do you have the setup ready?
<didrocks> psivaa: like, can you update from a ppa and start again the vm?
<psivaa> didrocks: this is during the live session, so i could try that
<didrocks> psivaa: excellent, please install ~ubuntu-unity/daily-build ppa, which is going to land in raring later on (first real unity version in raring)
<didrocks> psivaa: at least, we'll know if the issue still exists, as compiz changed quite a lot
<didrocks> popey: Mirv: the ppa is updated with what should land soon, if you want to test itâ¦ :)
<popey> roger roger
<cjwatson> xnox: regressions are regressions, virtualbox or not
<cjwatson> I'd be very wary of saying "oh, it's virtualbox, screw it" without very careful evidence to demonstrate that it isn't something that affects real hardware too
<xnox> cjwatson: ok.
<popey> xnox, also worth noting virtualbox supports hardware 3d passthrough, so users can actually use Unity without going via LLVM. I don't believe kvm does this?
<xnox> popey: ok. I shall try to set that up on my machine. Will it work with intel graphics? I guess I will find out =)
<popey> yes
<popey> I am using ubuntu 12.04, 12.10 and raring in virtualbox
<popey> (on i7, HD2000 GPU)
<cjwatson> FWIW last I checked 3D passthrough was only in the proprietary edition
<cjwatson> Certainly a good reason somebody might use it though
<doko> infinity, bad boy
<infinity> doko: ?
<doko> infinity, no, it's hrw
<infinity> Oh.  Yeah.
<doko> infinity, so it looks like the armhf-armel packages are always empty. did something change how stubs-hard and stubs-soft are generated? currently I can only see stubs-hard.h
<infinity> doko: stubs-hard is in libc6-dev:armhf and stubs-soft is in libc6-dev-armel:armhf
<infinity> doko: They didn't used to be split out at all, pre-2.16
<infinity> (As in, there used to just be one stubs.h that had code for both)
<doko> bah, http://packages.ubuntu.com/ can't search armhf
<infinity> Nope, I've complained to Rhonda recently about that.
<infinity> It may change.
 * infinity wonders idly if this cross-built apache2 of his will actually run.
<psivaa> didrocks: i could not verify the ppa in the live session, tried with persistence but rebooting the VM in KVM does not go back to the live session, even though the boot order is correct and the dvd with the iso is the first one on the list. tried to 'sudo restart lightdm' after the ppa installation but that command just hangs and i do not see anything happening
<Mirv> nothing weirds noticed with the new PPA versions either
<rtg> infinity, tsk, tsk. linux-meta-nexus7 has a git repo
<infinity> rtg: Tsk, tsk, I can't commit to it. :P
<rtg> infinity, you're not supposed to. How about sending me a patch ?
<infinity> rtg: Thanks in advance for merging without complaining about my not committing somewhere that I can't commit.
<infinity> rtg: http://launchpadlibrarian.net/124931118/linux-meta-nexus7_3.1.10.8.12_3.1.10.8.13.diff.gz
<infinity> rtg: Enjoy. :)
<ogra-cb> rtg, i have a config patch for the image package
<diwic> Hi, I could use some advice on how to get a SRU through. The SRU fixes bugs that currently block hardware certification for some devices.
<xnox> psivaa: usually: stop lightdm; stop ubiquity; pkill -9 X; start lightdm; all as root should be able to "restart" the graphical session for you after installing / changing packages.
<diwic> I uploaded Pulseaudio almost a month ago and nothing happened; however, during this month more bugs have shown up so I should do another upload before it's accepted
<diwic> However, if I do that, I'm afraid I'll get last in queue again and have to wait another month.
<seb128> slangasek, infinity, ScottK, bdmurray, SpamapS, RAOF: ^
<seb128> diwic, if you have a new upload to replace the currently waiting just get it in, it will not "reset the counter"
<infinity> diwic: Upload a new one, use -vold_old_version to generate a sane changelog that included both, and ping me.
<seb128> but what infinity said, merge both entries or use -v
<diwic> infinity, should the new upload have the same version as the old one?
<infinity> diwic: Oh, either option is fine.  Re-use, or -v to catch both.  Don't care.
<diwic> ok
<diwic> I'll go and prepare another upload
<diwic> thanks
<psivaa> xnox: thanks, pkill -9 X alone brings up the live session properly even without installing the unity daily ppa
<xnox> psivaa: ;-)
<cjwatson> gema_: phew, that was an obscure bug
<gema_> cjwatson: did you fix it already!?
<gema_> cjwatson: thanks a lot!
<cjwatson> Just preparing an upload now
<cjwatson> It may take a little while to reach images as ubiquity is one of the packages frozen for the community image milestone
<ScottK> Speaking of which ...
<gema_> cjwatson: ack, no problems, thanks a lot for this :D
<ScottK> cjwatson: Now that it's not incredibly late, did you have in mind a way to get a list of packages to freeze?
<cjwatson> ScottK: Oh, huh.  I thought you'd frozen already.  Isn't it a bit late now?
<cjwatson> I mean, not for me, but for it to be useful
<ScottK> No, we were going to block transitions today and respin.
<ScottK> Since it's just Kubuntu images it's not that big of a deal to retest.
<ScottK> Ideally we'd have done it earlier, but this is the first time and all ...
<ScottK> I was playing with germinate last night, but didn't get anywhere since I couldn't figure out how to use -c to get it to use both main and universe at the same time.
<cjwatson> -c main,universe - but I think it'd be better to use the .manifest and .list files from the images
<ScottK> Ah.  That's one option I didn't try.
 * xnox thought edubuntu & kubuntu are releasing and hence the set of frozen packages is larger.
<xnox> well "to be frozen"
<ScottK> It's up to Edubuntu if they want a freeze or not.
<ScottK> IIRC, stgraber said they weren't going to respin, so there was no need for a freeze for their stuff.
<cjwatson> join -j1 -o2.2 <(sort -u list-of-binary-packages) <(grep-aptavail -nsPackage,Source:Package '' | perl -ple '$_ .= " " . <>; chomp; <>' | sort -u)
<cjwatson> Should be close enough
<cjwatson> .oO( SQL in shell )
<cjwatson> Might miss packages that don't exist on the architecture you're running on
 * xnox is impressed. But questions perl's ability to do sort -u?
<cjwatson> It could but then you can't use -p which is handy
<xnox> ah
<highvoltage> xnox, ScottK: yep, edubuntu has some release-critical bugs for alpha-1 but it doesn't seem necessary to block an alpha release because of them. people who want something more feature complete and without sever bugs can wait for the beta :)
<diwic> infinity, okay, a new upload is now in the queue
<infinity> highvoltage: I think you just summed up everything I dislike about actually releasing alphas there.
<stgraber> ScottK: so I caught up on the highlights but not on the rest of the log. Did you push your britney hints to the branch already?
<ScottK> stgraber: No.
<ScottK> I'm sorting out the list now.
<stgraber> ok
<infinity> ScottK: I guess this would be a bad time for me to push a new d-i and kernels? ;)
<ScottK> stgraber: Pushed.
<ScottK> I'd appreciate it if someone would check it please.
<ScottK> infinity: It's probably OK.  I think my block hits faster than the buildds get that ready to transition.
<cjwatson> Hints are updated at the start of every britney run
<ScottK> stgraber: Once we've confirmed that works, would you please respin the Kubuntu images.
<cjwatson> It looks plausible at a very cursory glance
<didrocks> cjwatson: hey, you maybe have seen we just had our first automated daily process (but with manual testing, autopilot not being ready yet) unity stack release.
<didrocks> cjwatson: we had some new (renaming) source packge which went through NEW
<didrocks> like unity-scope-gdrive
<didrocks> but nux bumped its soname and is now nux4
<didrocks> the binary package didn't seem to go in the NEW queue
<didrocks> (fortunately, I asked a beforehand review from the ppa itself to seb128)
<didrocks> any idea if I either use a wrong copy argument or if there is indeed a bug?
<ScottK> cjwatson: For Alpha 1, I'll settle for plausible.
<ScottK> stgraber: Since my block is in place, would you please respin Kubuntu.
<infinity> didrocks: copies don't hit binary NEW, this is true.  And mildly problematic in this case, perhaps.
<didrocks> infinity: ah, well, when we have packaging changes, the publisher is stopped for a manual review
<cjwatson> I think I remember vacillating about that when implementing --auto-approve
<didrocks> infinity: so at least, we won't copy without noticying
<didrocks> but then, you can just count on people having the credential following the process
<stgraber> ScottK: sure
<stgraber> ScottK: running
<cjwatson> I believe I settled for auto-approve bypassing NEW because that way it was convenient for Debian auto-syncs
<didrocks> (which I think, I did proove more than once ;) but I would prefer it to be enforced)
<ScottK> Thanks.
<didrocks> yeah, I understand
<didrocks> should I just note that on the doc and we rely on people pushing the manual trigger when there is a packaging change?
<didrocks> in*
<infinity> cjwatson: Yeah, the problem isn't necessarily bypassing NEW (although, if this sort of automated copying happens more, I'm a bit irked by it bypassing ftpmaster checks), but that the overrides will be wrong by default.
<cjwatson> And I think that's an independent bug
<ScottK> stgraber: Do you think the block is worth a mail to u-d-a?
<cjwatson> I think it is.
<cjwatson> If only because it's new information that we can do this without affecting people's ability to upload.
<ScottK> OK.
 * ScottK writes
<stgraber> ScottK: I'm actually 90% done writing an e-mail to u-d-a :)
 * ScottK stops writing.
<ScottK> Thanks.
<stgraber> ScottK: did I miss something? http://paste.ubuntu.com/1412595/
<ScottK> I think it's fine.
<ScottK> stgraber: ^^^
<stgraber> alright, sent
<stgraber> cjwatson: can you accept it in u-d-a's moderation queue?
<cjwatson> stgraber: done
<didrocks> cjwatson: about those auto-accepted binaries, they are landing in main or universe?
<stgraber> cjwatson: thanks
<cjwatson> didrocks: As infinity says, there's a bug in default overrides, so we'll probably need to fix that
<infinity> Yeah, it's filed.
<didrocks> ok, I'll do a manual promote then
<cjwatson> I'm doing it
<didrocks> I thought about override as "bypassing"
<didrocks> ok, thanks cjwatson :)
<cjwatson> done
<cjwatson> hopefully it won't go wrong again on copy to release
<infinity> https://bugs.launchpad.net/launchpad/+bug/1079577
<ubot2> Launchpad bug 1079577 in Launchpad itself "Copies with binaries don't correctly override NEW binaries" [High,Triaged]
<infinity> Which may or may not be more than one bug.
<didrocks> thanks
<stgraber> cjwatson: you'll be happy to hear that today's precise image boots on SB :)
<infinity> stgraber: \o/
<stgraber> I'm now testing that it installs and boots, hoping to be done before the team meeting :)
<cjwatson> stgraber: HOORAY
<cjwatson> "happy" doesn't really cover it, that's a huge relief
 * stgraber really needs to fix queuebot to better deal with disabled products :)
<stgraber> cjwatson: so, I can boot the media, install but not quite boot post-install... sorry :(
<stgraber> checking what's wrong now
<stgraber> ok, so the reason why I can boot is because the efibootmgr entry doesn't point to the shim...
<stgraber> Boot0018* ubuntu	HD(1,800,2f000,fe060401-4d67-4ea8-8f0d-0f5910471a15)File(\EFI\ubuntu\grubx64.efi)
<stgraber> cjwatson: installer syslog: http://paste.ubuntu.com/1412670/
<cjwatson> stgraber: is shim in \EFI\ubuntu\ at all?
<stgraber> cjwatson: yep
<cjwatson> Hm, curious
<stgraber> looking at the log, the signed grub and shim are clearly installed but for some reason the wrong efibootmgr entry is written, then ubiquity removes linux-signed-generic-lts-quantal
<stgraber> one thing that may have confused the scripts is that it's on my laptop where I already have a working secureboot raring installation on the internal disk. The precise installation was done from a USB stick to another USB stick but sharing the efi partition on my internal disk with the raring install
<didrocks> cjwatson: did you handle also the unity-scope-gdrive migration to main? (it's the unity-scope-gdocs code, just a source package rename)
<cjwatson> didrocks: No, I didn't touch it
<didrocks> should I? just don't want to conflict when it will migrate to main :)
<cjwatson> Be my guest
<didrocks> ok, doing :)
<didrocks> cjwatson: last question before I stop bothering you, I'm looking at the proposed migration and it seems it's failing in some way for the unity stack, but I'm quite unsure about how to read the log :)
<cjwatson> didrocks: looking (modulo meeting)
<ogra_> didrocks, left to right, top to bottom :P
<didrocks> ogra_: ah, that explains whyâ¦ oh wait! :-)
<cjwatson> didrocks: Why does bamf-dbg depend on both libbamf0 and libbamf3-0?
<ogra_> :)
<cjwatson> didrocks: Also, ginn needs to be rebuilt against (or ported to) libbamf3-0
<ScottK> Also, should I expect the block to show up on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
<cjwatson> ScottK: excuses
<ScottK> Thanks
<cjwatson> And I do see it there
<didrocks> cjwatson: waow, indeed, not sure as those libbamf0 renaming came from debian, maybe a wrong merge, I can fix it directly
<cjwatson> didrocks: those are the two problems blocking migration AFAICS
<didrocks> ok, let me see for ginn
<didrocks> thanks for the hint cjwatson :)
<ScottK> OK.  I can see the block is working.
<stgraber> cjwatson: do you have enough information to debug that efi weirdness or do I need to extract something else before I fix my laptop to work again with SB?
<ScottK> It turns out the block is incomplete, but I'm not going to worry about it for Alpha 1.
<cjwatson> stgraber: I'm currently baffled but I can probably make some progress given that plus more coffee, so go ahead and restore
<slangasek> hmm, what's the efi weirdness now?
<stgraber> slangasek: even though I install under secureboot, the grub scripts somehow decide to use grubx64.efi instead of the shim
<stgraber> so I end up with a system where shim-signed and grub2-signed are installed but the efibootmgr entry points to grub directly
<slangasek> mmk
<cjwatson> grub-install bug - ${source_dir} isn't set
<cjwatson> i.e. misbackport
<cjwatson> doesn't explain why linux-signed-generic-lts-quantal gets removed
<xnox> stgraber: I remember you were requesting "static efi secure boot image validation". Currently that is run in jenkins and fails because of s/vmlinuz/vmlinuz.efi/
<xnox> stgraber: was there a irc log of all the things you were asking to be checked for? cause we can feed it to the smoke testing jenkins job.
<stgraber> 16:12 < stgraber> cjwatson: well, at least we have a pretty comprehensive list of things that can go wrong with SB images ;) I'm almost tempted to write a testing script checking that the partition table is correct, that the fs structure is fine for EFI, that shim and grub exist and are signed, that grub.cfg looks right and that vmlinuz is signed. If all of those match, it's pretty sure it'll at least boot (install is a whole other proble
<stgraber> xnox: ^
<cjwatson> If somebody wants to review that grub2, that should be half of stgraber's problem
<cjwatson> Only touches grub-install so shouldn't need a new grub2-signed
<cjwatson> The removal of linux-signed-generic-lts-quantal is perplexing, and we need to fix it, but I don't think it should break booting because it's just the metapackage
<cjwatson> (It'll break future upgrades instead)
<xnox> stgraber: thanks, I'll try to work on those bits.
<infinity> cjwatson: At which point is the metapackage being removed?
<infinity> By the "I guess you don't need a signed kernel" logic?
<cjwatson> infinity: It's actually more that it isn't being specifically kept (because it's in the live part of the squashfs manifest)
<cjwatson> infinity: I think check-kernels is getting confused by the -lts-quantal suffix.  Tedious rather than complex as such.
<infinity> Ahh.
<cjwatson> infinity: Go work with pinky on sulfur, sounds like he's making progress :)
<infinity> He is?
<cjwatson> #is
<cjwatson> I've apparently forgotten most of what I know about rescuing powerpc boot failures, but at least it gets somewhere interesting now
<infinity> Dangit, if he'd just waited longer on the udev spam, it would have eventually let him in.
<phillw> Hi, a bit of a n00b Q, I know! When  I cannot get a crash report to send the details, which files do I manually upload to the manually opened bug report on lp? (A link to wiki with list is fine).
<infinity> phillw: You could just file it with apport-bug /path/to/.crash
<infinity> phillw: Or if you've already filed a bug, "apport-collect 12345" (for the bug number)
<phillw> infinity: it's a KVM instance. and is dying with ubiquity. I can use guestfs to pull files from it, but not much more.
<infinity> syslog is a good start.
<phillw> shall i pull /var onto my local machine?
<xnox> phillw: /var/log
<phillw> xnox: thanks, I'm just installing guestfs onto my machine
<SpamapS> Is there a reason php5 hasn't moved out of raring-proposed ?
<SpamapS> Its compiled on all arches.. and I don't see any installability issues.
<xnox> SpamapS: trying: php5
<xnox> skipped: php5 (57 <- 25)
<xnox>     got: 107+0: i-107
<xnox>     * i386: php5-suhosin
<xnox> SpamapS: so php5-suhosin becomes uninstallable if php5 is upgraded.
<xnox> SpamapS: http://people.canonical.com/~ubuntu-archive/proposed-migration/
<ScottK> Self service at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<SpamapS> ahh .. http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html .. is that not up to date?
<xnox> SpamapS: that looks at raring-release, not raring-proposed nor the mix of the two yet.
<micahg> http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html
<SpamapS> AHH
<xnox> SpamapS: so britney telss you when/why it's not migrating a package and that's more canonical way to check why something is not migrating.
 * ScottK wonders if xnox was punning.
<xnox> micahg: Ooohhh we have that now =)
<SpamapS> ok, looks like php5-suhosin will need another rebuild
<ScottK> Right, but it doesn't actually answer SpamapS' question.
<micahg> excuses page said it's a valid candidate...
<infinity> micahg: excuses saying "valid candidate" means "and thus, I shall try and see if it fits!"
<infinity> micahg: Basically, it means is passed the "is it build" and "are there any blocks" tests, etc.
<infinity> Then it actually tries the complex upgrade bits.
<infinity> And that's _output.
<cjwatson> xnox: We've had it since roughly when raring opened
<micahg> infinity: right, I'm one step behind since I haven't dug into this yet :)
<infinity> micahg: excuses and output aren't actually two views of the same thing, rather, excuses is the first stage, and output the second.
<micahg> (this being britney mimgrations)
<ScottK> Yes
<cjwatson> Excuses is package-local, output is global.
<infinity> cjwatson: Right, but if something isn't a valid candidate, according to excuses, it'll never hit the global try/pass/fail in output.
<infinity> (Which was what I was trying to get across with the "two stages" bit)
<cjwatson> Indeed.
<ScottK> Right and the stages are: 1 local 2 global
<infinity> Heh.
<infinity> Ed Zachary.
<infinity> So, is breakfast still breakfast when you've been up since 6pm the previous evening?
 * infinity decides to go cook some and find out.
<micahg> infinity: if you've not been eating since then, certainly :)
<plars> xnox: I'm looking at https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1086036 and would like to improve the title so that it's clear that we're not talking about the 2 month old compiz bug that it was duped to earlier. do you happen to know what the thing is called that comes up to ask if you want to go into live session or the installer? is that part of ubiquity?
<ubot2> Launchpad bug 1086036 in compiz (Ubuntu) "Compiz crashes when booting to raring live session" [Undecided,New]
<plars> I'm currently thinking that the compiz crash may or may not even be related to the real problem described here
<xnox> plars: so ubuntu desktop CD's boot into "ubiquity-dm" session which presents ubiquity in the greeter mode aka "Try or Install Ubuntu" screen.
<xnox> plars: so something like "compiz driven ubiquity-dm crashes in raring daily" is a reasonable title or something else you can think off.
<xnox> ... but did not under metacity.
<plars> xnox: because one of the other things we've noticed is that if you hit a key at the boot screen and choose boot to live session, it goes into the live session fine, but if you choose install ubuntu, it seems to give us something similar to what we see here (top bar only, no installer)
<plars> xnox: ah, so there was a change from metacity to compiz here recently?
<xnox> plars: correct. So "install only" mode is also running under a "ubuntu-dm" session.
<xnox> plars: yes, there was. See the email to ubuntu-devel announcing this.
<SpamapS> [6~[6~[6~[6~[6~/win 99
<SpamapS> curse you lag
<xnox> plars: I have tested it across all hardware I had available and the idea is that live-cd should gracefully use 3D accelaration or fallback to LLVM Pipe rendering.
<plars> xnox: ok, that's about the same timeframe for that change and when I'm seeing it that it quit working
<xnox> plars: if this experiment doesn't work out well, we can seed metacity back on to the desktop CDs, but keep using compiz on nexus7 images (e.g. controlled environment / hard ware where we know it works correctly)
<plars> xnox: that's sheds some light on this for me, thanks
<xnox> plars: So it can be easily tested: stop lightdm; stop ubiquity; pkill -9 X; apt-get install metacity; start ubiquity
<xnox> if that works you know it's compiz fault.
<xnox> Ideally I want compiz to work out of the box for the installer on all hardware, because this is requirement to run the installed system after all.
<plars> xnox: well, it *does* seem to run once we get it installed, just not for the ubuntu-dm session
<SpamapS> so, I think php-suhosin probably needs to be removed
<xnox> plars: interesting. Somebody with compiz skills should debug this then. Does it work on the installed system, due to installing & activating extra graphics drivers?
<xnox> plars: didrocks was pinged about it earlier.
<plars> xnox: also, I think psivaa already did some of this testing this morning, but even just killing X and restarting lightdm worked on it's own
<plars> without installing metacity
<xnox> 8) sounds racy.
<plars> indeed
<xnox> plars: coincidently ogra_ was reporting race condition between compiz & onboard with subsequent boot working out better for onboard.
<xnox> (that's on nexus7)
<xnox> interesting.
<stgraber> pgraner, slangasek, ScottK, highvoltage: Initial draft of the announcement: http://pad.ubuntu.com/raring-alpha1-announcement
<ScottK> Riddell: ^^^
<highvoltage> stgraber: I'm going to make some slight yet liberal changes to that
<ScottK> stgraber: It's a bit difficult to get this just right since Ubuntu is a: a free software project, b: a Linux distribution, c: a desktop OS that you get when install "Ubuntu", d: all of the above.
<highvoltage> ah I see you changed the URL so long, thanks
<highvoltage> ScottK: yeah hence my small change there too :)
<highvoltage> stgraber: I just realised that we don't actually link to any iso image from the release announcement, should I just link to the daily build we used or is there special logic somehow that preserves that iso somewhere?
<ScottK> That's one thing he has to do as it still requires Canonical powerz.
<ScottK> infinity: http://pad.ubuntu.com/raring-alpha1-announcement <-- I added a paragraph about not reporting old bugs for you.
<ScottK> stgraber: What do you think about the pargraph I added?
<stgraber> highvoltage: use the same link I put on the pad (the /alpha-1/ thing)
<stgraber> ScottK: looking
<ScottK> Thanks.
<infinity> ScottK: You seem to be having problems Englishing. :)
<ScottK> Did I?
<infinity> should identified in the Alpha 1 installer should be
<ScottK> Ah.
<infinity> But thanks for that.
<ScottK> Anyway, trying to address your golden image concerns at least a bit.
<infinity> Sadly, we'll see people keep using Alpha1 images to install from for a long while.
<ScottK> Sure.
<infinity> Hopefully they're not full of annoying installer bugs that keep dominating errors.u.c. :P
<ScottK> Not so far, althought I may have just found one.
<infinity> (Which is what we saw last cycle... Tons of ancient ubiquity bugs drowning the signal in noise)
<stgraber> infinity: well, people like using obsolete stuff, I'm still regularly getting e-mails from people who want to install Feisty (not sure why but Feisty seems rather popular for Edubuntu...) and wonder where to find packages for it...
<infinity> Which is one of the reasons why I've argued that, even if people want to do the alpha-style freeze/test week, maybe publishing the final images isn't actually a net positive.
<infinity> stgraber: Feisty?  Wow.  Impressive.
<highvoltage> infinity: sounds like something that needs to be fixed with the error reporting mechanism
<infinity> highvoltage: It does reasonable version tracking.  But we *want* the stats on old versions that are in use, it's just annoying when they're the top crashers because no one uses the newer versions.
<stgraber> infinity: I think someone made some kind of Edubuntu based appliance using Feisty, then never updated their stuff and the company disappeared a few years back, so apparently entire school districts now run Feisty + a ton of custom packages and have no upgrade path :)
<ScottK> Feisty was a good release.
<infinity> stgraber: Oh fun. :/
<stgraber> ScottK: looks good. I spotted the same problem as infinity and dropped a couple of words from your paragraph to make it more parsable
<ScottK> Thanks.
<infinity> stgraber: If we could actually identify this particular appliance and userbase, there may be some money in this for a consulting company (or Canonical) to help provide them a solid and safe upgrade path.
<highvoltage> My mother ran Feisty for around 4.5 years and it just kept going
<infinity> highvoltage: Heh.  I ran woody for around 8 years before I decided that was a really stupid idea.
<tumbleweed> it was the stable release for aronud that long, though :P
<slangasek> lies :P
<highvoltage>   sheesh, and woody was already kind of old when it was released
<infinity> Give or take five years.
<stgraber> I've been running woody for a long time too as for some reason I never quite liked sarge so didn't want to update anything to it, probably not 8 years though
<highvoltage> it was the first debian release I tried on my laptop and gnome 1.2 just hurt my eyes too much
<highvoltage> (now gnome 3.6 hurts my eyes, I guess I've gone full circle)
<pgraner> stgraber, I made a few small edits but it looks great.
<seb128> hey
<seb128> I'm looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule ... is DesktopInfrastructureFreeze the point where things need to be uploaded or be approved?
<seb128> wondering if the SRU team backlog is going to be an issue there...
<infinity> seb128: We'll clear it out by then, but if not, ping about specific things that need to make the freeze.  Not every SRU does.  Some clearly do (enablement stack stuff).
<infinity> seb128: I'm hoping the curious combination of "most people will be on holidays for a few weeks and not uploading" and "lots of the SRU team members are silly workaholics who work on their holidays anyway" will help catch us right up. :P
<seb128> infinity, so you are saying that the SRU team commit in having everything which is currently in the team approved (or at least not reject because the SRU team didn't get to do reviews on time)?
<seb128> doh
<seb128> which is currently in the *queue*
<seb128> infinity, I'm starting to worry that the month backlog is going to create issues
<infinity> seb128: That sentence didn't English very well, but I'm not saying we're committing to clearing the queue entirely, but that we'll clear what's deemed necessary.  And if we miss something on that list, let us know. :P
<infinity> seb128: While, ideally, we'll clear the queue (and I'd like to), not all SRUs *need* to be on the .2 disc.  Some of them obviously HAVE to be.
<seb128> infinity, sorry about my french, it's 9pm and it has been a long day :p
<seb128> infinity, should I start lobbying today for things I want to get reviewed?
<infinity> seb128: I'm going to throw my shoulder at the queue a few times over the next week to see how far down I can get it, FWIW.
<seb128> infinity, or should I give you guys some slack and start complaining about things still not reviewed after holidays?
<infinity> seb128: Complain early January, if things still suck.  And pick your battles carefully, cause if you just complain about "everything in the queue", we'll have to have some cultural misunderstandings. ;)
<infinity> seb128: In the week before that freeze, we should be able to push through anything that's urgent and got missed.
<seb128> infinity, thanks
<SpamapS> FYI, https://bugs.launchpad.net/ubuntu/+source/php-suhosin/+bug/1086984 ... probably time to drop php-suhosin
<ubot2> Launchpad bug 1086984 in php-suhosin (Ubuntu) "Should Drop php-suhosin from Ubuntu" [Critical,New]
<ScottK> Yeah.
<ScottK> SpamapS: Gone
<slangasek> cjwatson: do you have any idea why this command would only be copying the i386 binary, not the amd64 binary?: copy-package -j -b -s precise --to-suite quantal gstreamer0.10-fluendo-plugins-partner
<slangasek> oh, n/m
<slangasek> cjwatson: it's because there are separate source packages for the upstream binary drops, ignore me :)
<phillw> If there is a potential fix to an issue in debian/unstable for a bug (i.e. a newer release), is there a way for me to pull it in & test it? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/2
<ubot2> Launchpad bug 1086974 in libguestfs (Ubuntu) "libguestfs: error: cannot find any suitable libguestfs supermin" [Undecided,New]
<slangasek> speaking of gstreamer, is it planned to drop gst0.10 from the images for raring in favor of gst1.0?
<slangasek> phillw: you can grab the source with pull-debian-source and build it yourself; or you can copy it to a ppa; but this is off topic for #ubuntu-release, perhaps #ubuntu-devel is better
<seb128> slangasek, yes it is, we should be close from that
<slangasek> seb128: ok, cool
<seb128> slangasek, I just respinned discussion about partner/fluendo codecs as well since we are on the topic
<seb128> just as a piece of information
<slangasek> ugh, python-support on component-mismatches /again/?
<slangasek> seb128: respinned discussion?
<seb128> slangasek, there has been discussion between Canonical/fluendo before quantal since we were not sure if we going to follow GNOME (which went with gst1 in 3.6) or not
<slangasek> seb128: ok
<seb128> slangasek, those discussions sort of stopped when we decided to hold on the update for quantal
<infinity> slangasek: Yeah, looks like someone's idea of "all deps are in main" didn't take build-deps into account.
<seb128> so it's time to get that resolved ;-)
<slangasek> infinity: hmph.  Is that because we're not providing people the right tools?
<infinity> slangasek: I've already commented on the MIR bug.
<slangasek> (to give them the correct answers)
<slangasek> ok
<infinity> slangasek: No, our tools are fine.  That doesn't mean people use them.
<slangasek> seb128: right, that's why the question comes up :)
<slangasek> infinity: which tool?
<slangasek> I can't tell you what tool I'd even use for this
<slangasek> so I'm not surprised if $random_mir_submitter doesn't use it
<infinity> Oh, actually, hrm.  There may not be a simple tool to check maininess of rdeps.
<infinity> slangasek: I'm not surprised when mir_submitters miss this, I'm a bit more miffed when mir_reviewer does. :P
<slangasek> also, promoting before uploading the thing that depends on it
<infinity> Oh, is it not actually being used in main yet?  In that case, demote away.
<SpamapS> ScottK: thanks!
<infinity> Indeed, its only reverse-dep is rlvm.
<infinity> slangasek: I'm going to demote it and reopen the MIR bug, unless you've beat me to it.
<slangasek> infinity: beating you now
<infinity> Alright.
<infinity> And ow.
<micahg> infinity: there's check-mir in ubuntu-dev-tools
<infinity> So there is.
<infinity> And it even works for google-mock.
<slangasek> perhaps someone should point this tool out to the MIR team? :)
<slangasek> "unar" - wtfbbq
<infinity> ?
<slangasek> c-m again
<slangasek> file-roller has a new recommends on some tool that needs gnustep
<infinity> There's... Something called unar?
<cjwatson> it's like thunar but when you've been to the dentist
<slangasek> that's what it's *called*
<infinity> Oh, I see, a one-size-fits-all.
<seb128> bdrung, ^
 * cjwatson sees nux binaries fell into universe again - fixed
<cjwatson> anyone know why farstream-0.2 was moved to main without its dependencies?  looks like it was deliberate but I can't find an MIR
<infinity> Might have just started out in main because it was a new upstream of an already-main package.
<infinity> (As in, I may have NEWed it that way, assuming it would be a build-dep ASAP, or fall out if not)
<cjwatson> +publishinghistory said it was NEWed into universe and then moved to main.
<infinity> Oh.  In that case, no idea.  It sounded like the sort of thing I'd do. :P
<cjwatson> I think.  Unless it was a copy bug.
<cjwatson> I'll move it back.
<seb128> cjwatson, what infinity said
<seb128> it's a new version of a package in main
<seb128> it's part of the gst1
<cjwatson> It's uninstallable in main.
<seb128> transition
<seb128> kubuntu is mixed in the farstream transition afaik
<cjwatson> You can put it back if you fix that; after this publishing cycle though (to avoid triggering that long-standing LP bug).
<seb128> Laney sent an email Ccing the kubuntu team about that
<seb128> but he's on holidays this week
<seb128> cjwatson, I think it has been kept off the transition because of kubuntu so it's fine to demote
<seb128> but it will come back soon
<cjwatson> I don't mind if it's promoted again as long as it's not showing up on uninstallability reports :-)
<infinity> Sure, it's not kubuntu that was making it uninstallable, mind you, it was gst1.0
<cjwatson> gstreamer1.0-nice, indeed
<seb128> cjwatson, ok, fair enough ;-)
<seb128> cjwatson, infinity: Laney wrote
<seb128> "  * Kubuntu-ers again: There's a mini telepathy-farstream transition
<seb128>     required (syncing the new version from experimental which has a new
<seb128>     SONAME) for the gst 1.0 port. This is needed for Ubuntu for empathy,
<seb128>     but you have kde-telepathy-call-ui libtelepathy-qt4-farstream2
<seb128>     depending on it. ktp-call-ui explicitly depends on gstreamer0.10
<cjwatson> I'd have promoted gstreamer1.0-nice if farstream-0.2 had been seeded anywhere
<seb128>     stuff and FTBFS with the new telepathy-farstream (see attachment)."
<cjwatson> As it is, I'd rather not cause component-mismatches to get any bigger with stuff we don't know why it's there or whether it can be moved to univere
<cjwatson> +s
<cjwatson> Investigating those is time-consuming
<seb128> cjwatson, thanks, I will investigate that tomorrow but there is no hurry (as long as we are fine still having gst0.10 in mainÃ )
<cjwatson> I don't care either way :-)  What I want is continuous consistency
<seb128> right, all good then ;-)
<infinity> cjwatson: Speaking of c-m.  Do you happen to remember the cause of the misfeature that wants to drag all the universe kernels in for their udebs?  I swore we had this in previous cycles and cleared it up somehow...
<cjwatson> infinity: It might be a missing Provides in the primary kernel's kernel-image udeb on that arch
<cjwatson> Our esteemed kernel team is sometimes lazy about those (probably because they don't realise they're actually useful)
<infinity> Ahh, so probably a bug on all the primary kernels, but since ARM is the only arch with other kernels...
<cjwatson> Well, it depends on config too
<cjwatson> The general notion is that if a feature that's sometimes provided by *-modules udebs is instead built into the kernel, kernel-image ought to have "Provides: ext2-modules" or similar
<bdrung> infinity: it's for extract RARv3 archives
<cjwatson> It'll be either ext2-modules or fat-modules, I expect
<bdrung> extracting RARv3 archives is a common use case
<seb128> bdrung, file-roller is doint install-on-demand so that's not an issue
<seb128> doing
<seb128> bdrung, e.g it will prompt you to install utilities if those are needed
<bdrung> seb128: it does not prompt you to install unar (it suggests unrar or rar instead)
<seb128> oh, ok
<infinity> unrar would work too, mind you.
<infinity> (Except for the part where it's nonfree)
<bdrung> infinity: unrar is non-free, but unar is free
<ScottK> seb128: I think if you start an uncoordinated transition, that's not our fault that we didn't work it out at the same time.
<seb128> ScottK, I don't think it's fair to say the transition was uncoordinated, it was discussed at UDS, prepared in a ppa and Laney sent emails Ccing the kubuntu list
<seb128> ScottK, and there is no blaming, the transition is still ongoing, nobody is late or blocking anyone
<seb128> ScottK, we just got some bits demoted because we didn't get to them yet which is fine
<slangasek> bdrung: free but requires a crazy ObjC stack that we don't want in main
<bdrung> hm
<bdrung> i think it makes sense to have a rar extracter installed by default, but preferable without pulling ObjC in
<seb128> bdrung, there is unrar-free...
<bdrung> seb128: it does not support v3 files (which is what nearly all rar files use)
<bdrung> v3 is 11 years old
<seb128> hum, k
<seb128> that's not something we got lot of complain about so far afaik
<ScottK> seb128: Even better.  Ask questions.  Don't get responses and then upload anyway.
<seb128> so I'm not sure how many people out there are using rar v3 and if install-on-demand is working for that usecase or not
<ScottK> Kamoso is currently unbuildable, so there's no way this can go forward right now.
<ScottK> (at least not without removals)
<seb128> ScottK, even better, ask question, don't quest responses, get stucked for ever to not be able to move forward
<infinity> Because the largest consumers of RAR are people splitting and distributing copyrighted material and they (a) don't like to file bugs about not being able to do that, and (b) have switched to torrents that don't need splitting.
<seb128> quest->get
<ScottK> The message is less than a week old.
<seb128> right and as said there is no issue, the transition is ongoing
<ScottK> We've been kind of busy getting KDE 4.10 beta 1/2 packaged and doing an Alpha
<seb128> so the uploads didn't hurt
<seb128> both versions are co-installable
<seb128> it just means we have both on our iso
<ScottK> OK, then don't complain about Kubuntu'ers and it's not done yet then.
<seb128> which is fine
<seb128> ScottK, sorry, I was more pointing at where we are than complaining
<seb128> the current situation is not an issue
<seb128> but reality is that we need kubuntu to move forward to finish the transition
<ScottK> Sure.
<seb128> no hurry though
<ScottK> OK.  No worries then.
<bdrung> infinity: RAR files are used for legal stuff, too (some friends use it and need to extract these files from time to time), but you probably describe the normal use case
<seb128> cool, sorry for the confusion if there was any
<infinity> bdrung: I did say the "largest consumers", not all of them.  I also realise in looking at my wording there that I may have implies that warez kiddies are overweight.
<infinity> s/implies/implied/
 * ScottK wonders if clamav can use unar.
<bdrung> i would love to see someone port the algorithm from unar to libarchive
<infinity> I've generally been happy with the assumption than an .rar attached to an email was a virus without opening it to look.
<infinity> That assumption's not been wrong yet. :P
<bdrung> infinity: a .rar attachment from an unknown person. a .rar attachment from an known person could be no spam.
<infinity> bdrung: Sure, could be.  But no one I know has ever emailed me a rar, hence the assumption works for me, that's all.
 * bdrung nods.
<Riddell> stgraber: the announcement has no ringtail themed quote!
<Riddell> that's essential for alpha 1
<stgraber> Riddell: add one :)
<Riddell> how about this one? PG Woodhouse: "Sir, that stolen lemur bit one of your prostitutes right in the face and she says she can't go to hospital because she's, quote, "tripping balls.""
<Riddell> oh it's not pg woodhouse, that's no good then
<Riddell> The Philosopher's Apprentice "I know the God hypothesis has its partisans, but, oh, what a boring idea. Where did the universe come from? He did it. How do we account for rivers and rocks and ring-tailed lemurs? He made them. Ho-hum. "  I like that one
<slangasek> infinity: statistically speaking, warez kiddies don't exercise much
<Riddell> "Krusty The Clown: Book that animal that always chomps on my groin. Secratary: Susan Anton? Krusty The Clown: No, the lemur."
<phillw> Riddell: "The lifespan of the ring-tailed lemur is 20 years", slightly less than 13.04 :P
<Riddell> I'm going with  "I am a ring-tailed roarer. I can draw faster, shoot straighter, ride  harder, and drink longer than any
<Riddell> man alive. I'm the rip-snortinest cowboy that ever rode North, South, East or West of the Rio Grande."
<Riddell>  - Pecos Bill, Tall Tale 1995
<phillw> Riddell: I like that one... and look forward to the further quotations as we progress :)
 * ScottK removes some passive voice from the draft announcement.
#ubuntu-release 2012-12-06
<psivaa> Is there anything wrong with precise desktop image publishing? cd-build-log says 'Build successfully added to the tracker', and the iso tracker is pointing to a cdimage link for 20121206 which is '404 Not Found'
<psivaa> Happened yesterday as well
<cjwatson> not clear; I've poked it ...
<cjwatson> mirroring is kind of out of our hands except for poking the trigger
<cjwatson> Looks OK now
<psivaa> cjwatson: thanks
<apw> can i assume that the britney block is for the alpha1 ?
<cjwatson> Yes
<apw> thanks
<diwic> infinity, ping
<infinity> diwic: Sup?
<diwic> infinity, you told me to ping you once I've uploaded a new pulseaudio for SRU into 12.04
<infinity> diwic: Mmkay.
<diwic> infinity, hopefully I've managed to write nice little "Sru justifications" in every bug it fixes, but let me know if you have any questions.
<Riddell> I think kubuntu is ready for alpha 1
<Riddell> oh hmm the cdimage page says OVERSIZED, I our 1GB limit isn't marked for raring in some part of it
<xnox> Riddell: the text != the actual size being checked for.
<xnox> Riddell: but I thought non ubuntu-desktop images where still at 700
<Riddell> we set it to a round 1GB for kubuntu in quantal but I guess that needs to be added for raring too
<Riddell> hmm I don't see the limit being for quantal only in ubuntu-cdimage bin/publish-daily
<Riddell> yofel: another crash fix for 4.9.4?
<Riddell> yofel: able to handle it or need help?
 * Riddell updates http://starsky.19inch.net/~jr/tmp/kubuntu-ppa-build-status.html
<Riddell> oh wrong channel :)
<cjwatson> Riddell: AFAICS you never made that quantal-specific
<cjwatson> lp:ubuntu-cdimage r897.1.1
<cjwatson> But it's in lib/cdimage/tree.py / lib/cdimage/tests/test_tree.py now anyway
<Riddell> stgraber: kubuntu is good to go for alpha 1 on i386 and amd64 modulo working out how to remove the oversized warnings on http://cdimage.ubuntu.com/kubuntu/daily-live/20121205/
<Riddell> aah it is over the limit, that explains it 1000341504 bytes > SIZELIMIT=1000000000
<Riddell> I think I'll bump that up to the binary 1GiB
<Riddell> cjwatson: could you merge in lp:~jr/ubuntu-cdimage/kubuntu-limit for that bumped limit?
<psivaa> xnox: cjwatson: any ETA for the fix for bug 1086339
<ubot2> Launchpad bug 1086339 in ubiquity (Ubuntu) "Can not install raring desktop with manual partitioning" [Undecided,Confirmed] https://launchpad.net/bugs/1086339
<cjwatson> psivaa: I uploaded the fix yesterday, but, as I told gema, it's waiting for the Alpha 1 freeze to lift before it lands in images
<cjwatson> Riddell: um, no - you're working off ancient source before the Python rewrite
<Riddell> oh I'm behind the times
<cjwatson> Oh, hmm, is the public mirror out of date I wonder
<Riddell> I just did bzr co lp:ubuntu-cdimage
<cjwatson> Hmm, LP is getting 403
<cjwatson> Grab it directly from http://people.canonical.com/~cjwatson/bzr/cdimage/mainline/ for now
<cjwatson> Ah, there we go, never mind
<cjwatson> lp:ubuntu-cdimage should be up to date no
<cjwatson> w
<psivaa> cjwatson: ack thanks
<Riddell> cjwatson: lp:~jr/ubuntu-cdimage/kubuntu-limit2 for the merging
<cjwatson> Riddell: ./run-tests
<Riddell> cjwatson: good point, updated
<cjwatson> Riddell: Righto, thanks - merged, deployed, and I've removed the *.OVERSIZED files
<Riddell> yay thanks
<Riddell> stgraber: kubuntu good to go
 * ogra_ wonders if he just never noticed or if ppa-purge pulling in all of aptitude is a new thing
<diwic> ogra_, my guess is that we don't pull in aptitude anymore by some other random package, that's causing you to now notice that ppa-purge does it
<ogra_> hmm, might be, yeah
<Riddell> ScottK, stgraber: no amd64+mac for kubuntu, no install tests on it
<cjwatson> grr.  sorry about all the precise Ubuntu desktop amd64 rebuilds, I'm trying to make a debian-cd tweak for secure boot and having a bit of trouble
<ScottK> stgraber: How close are you to pulling the release trigger?  I'm wondering when I should drop my block.
<stgraber> good morning
<stgraber> ScottK: can you mark both images as ready on the tracker?
<stgraber> highvoltage: same ^
<ScottK> stgraber: Done.
<stgraber> ScottK: so I'm planning to release within the next two hours as there's no pre-publishing or anything like that to do and the only thing left is moving the images, archiving quantal beta2 and sending the e-mail
<ScottK> OK.
<ScottK> How often does britney run?
<infinity> ScottK: Every time the publisher does.
<ScottK> infinity: Thanks.
<infinity> (So, every 30m, except when not)
<stgraber> ScottK: so I'll do the old milestone archiving now and wait for highvoltage to show up
<ScottK> OK.
<stgraber> pgraner: if you want one last look at the announcement before we release, it's pretty much ready now. http://pad.ubuntu.com/raring-alpha1-announcement
<plars> Our ssh issues from NM bug before are resolved, but we are blocked in automated testing on another bug it seems now: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1061242
<ubot2> Launchpad bug 1061242 in ubiquity (Ubuntu) "apt-install fails during success-command because target environment cannot resolve DNS" [High,Confirmed]
<plars> anyone have a moment to take a look?
<plars> xnox maybe? ^
<xnox> plars: well I did notice the highlight (for ubiquity), I was somehow under impression this was fixed in quantal at one point by cjwatson to support adding ppas.
<xnox> but needs checking.
<cjwatson> I don't recall that but I'm an old man with a patchy memory :)
<cjwatson> Oh, there was a resolvconf bug
<cjwatson> Or related to that anyway
<cjwatson> It wasn't anything to do with PPAs as I recall
<pgraner> stgraber, cool, works for me
<cjwatson> xnox: You may be thinking of ubiquity r5671?
<xnox> cjwatson: yes, that is the commit that I was thinking of.
<cjwatson> plars: Please, whenever your team submits this kind of bug, could you include the preseed file?
<plars> cjwatson: yes, I'm getting one for you now
<cjwatson> It's not much fun trying to guess whether it's a bug in the installer or in the preseeding commands
<cjwatson> Thanks
<xnox> cjwatson: http://jenkins.qalab:8080/view/Raring/view/Smoke%20Testing/job/raring-desktop-amd64-smoke-default/20/artifact/syslog/*view*/
<plars> cjwatson: it used to attach it to the job as an artifact, but not at the moment, so give me just a bit
<cjwatson> xnox: I don't have DNS for that
<xnox> yes.
<cjwatson> And am not particularly keen on spending half an hour setting it up :)
<cjwatson> This should be in the bug
<stgraber> good, so announcement is ready, beta-2 has been archived and all alpha-1 bugs have been moved to the next milestone (month-2) and past milestones have been disabled
<plars> cjwatson: http://jenkins.qa.ubuntu.com/ would be the full name
<xnox> plars: Looking at the raring-desktop-amd64-smoke it looks like it fails to find us.archive.ubuntu.com. But I remember somebody ( jibel ?) saying in the qalab only archive.ubuntu.com was accessible.
<xnox> wait, I am wrong cause it access it just fine earlier in the run.
<cjwatson> I'm pretty certain that's a similar kind of resolver misconfiguration.
<cjwatson> Actually, it just looks like nothing especially cares about ensuring correct bind-mounts there.
<cjwatson> And never really has.
<cjwatson> You could just bracket your success command with 'mount --bind /run /target/run; ...; umount /target/run' for now.
<xnox> cjwatson: should that simply be added to in-target wrapper & advertise everyone to use that?
<cjwatson> Well, no, it's not that
<cjwatson> in-target already does it
<cjwatson> But there's a TODO in compat/apt-install saying that it should use in-target and currently does
<cjwatson> n't
<cjwatson> It must have been hard for some reason ...
<cjwatson> (Well, saying that it should use chroot-setup, but that's the active ingredient in question)
<xnox> Well this is what currently is run:
<xnox> Dec  6 13:08:55 ubuntu ubiquity[3078]: log-output -t ubiquity sh -c sh utah-latecommand ; chroot /target sh -c 'apt-get install -y --force-yes openssh-server >>/var/log/utah-install 2>&1; apt-get install -y --force-yes gdebi >>/var/log/utah-install 2>&1; sed -i -e "/^exit 0$/iapt-get install -y --force-yes openssh-server >>/var/log/utah-install 2>&1; apt-get install -y --force-yes gdebi >>/var/log/utah-install 2>&1;" /etc/rc.local;'; chroot /target
<xnox>  sh -c 'chmod g+w /var/lib/utah/testsuites; apt-get install -y --force-yes imagemagick'; [ "$?" -eq "0" ]
<cjwatson> Oh, yeah, that's nonsense
<cjwatson> OK, that's totally the preseed file's fault
<xnox> let me find the branch for this.... =)
<cjwatson> So the claim in the bug that it was using apt-install was untrue
<cjwatson> How misleading
<xnox> that the current log of the fail in the jenkins desktop smoke test.
<cjwatson> plars: Replace 'chroot /target' with 'in-target' throughout, including wherever it might be used within utah-latecommand
<xnox> cjwatson: well it's lp:utah I am looking through it now.
<xnox> cjwatson: cause the late command is generated from config values.
<xnox> plars: what i see in jenkins does not match lp:utah code. And in lp:utah there is now "cp /etc/resolv.conf /target/etc/resolv.conf" which is also not what is wanted.
<infinity> ScottK: Are you ready to drop your britney block?
<ScottK> Sure.  Give me a minute.
<cjwatson> cp /etc/resolv.conf /target/etc/resolv.conf> wow, that *really* won't work
 * infinity finds it oddly creepy that his and cjwatson's hints files are both 119 bytes.
<cjwatson> At least they aren't bricktext
<xnox> cjwatson: you said there was a bug report? or just a discussion here?
<highvoltage> hello stgraber
<cjwatson> bug 1061242
<ubot2> Launchpad bug 1061242 in ubiquity (Ubuntu) "apt-install fails during success-command because target environment cannot resolve DNS" [High,Confirmed] https://launchpad.net/bugs/1061242
 * highvoltage gets to it
<infinity> cjwatson: Was that a comment on my changelog habits? :P
<cjwatson> Heh, do you do that?  I hadn't noticed
<infinity> I don't consciously do it, so it's not always perfectly justified, but I seem to subconciously do it more often than seems sane.
 * cjwatson is reminded again of debconf 0.9.10 / 0.9.11
<stgraber> highvoltage: so if you're ready for release, just mark the images as ready on the tracker and take another look at the announcement. Everything else is good to go on my side, so I'll start publishing once you're done.
<highvoltage> stgraber: edubuntu images marked as ready
<xnox> cjwatson: commenting. thanks.
<infinity> cjwatson: hahahaha.
<cjwatson> I think that's the best changelog ever
<ScottK> infinity: Done and before the publisher run ...
<infinity> ScottK: Danke.
<infinity> ScottK: (It runs when the publisher's done, so you may have had a few more minutes to spare)
<infinity> Though, when the publisher is only doing non-release pockets, it's dangerously close to instant.
 * infinity commemorates the thaw by doing a d-i upload to let all the kernels in.
<highvoltage> heh
<highvoltage> open the gates!
<ScottK> They are open.
<ScottK> stgraber: AFAIK, Kubuntu is ready in all respects.  Our flavour specific release announcement is done.
<stgraber> alright, let's start publishing that thing
<ScottK> \o/
<smartboyhw> \o/
<Riddell> excellent, thanks much stgraber and ScottK
 * ScottK marked up the ISO tracker a bit.
<stgraber> rsync appears to be pretty slow today... it's been copying stuff to cdimage for almost 10 minutes now
<stgraber> ScottK, highvoltage: so I guess we should have everything ready by 11am EST. Torrents tend to take a little while to start working but half an hour should be enough for the seeder to import the new isos and start seeding.
<highvoltage> ok
<ScottK> OK.
<ScottK> I have the correct tab open in my browser to put the annoucement on kubuntu.org
<stgraber> ScottK, highvoltage: publishing done, can you confirm that cdimage looks good for your respective products?
 * stgraber tests the torrents
<ScottK> stgraber: I see them on http://cdimage.ubuntu.com/kubuntu/releases/raring/release, not on http://cdimage.ubuntu.com/kubuntu/releases/raring/alpha-1.
<stgraber> ScottK: hmm, indeed... wondering how I missed that. Fixing
<stgraber> that's really weird, only kubuntu got published as "release", edubuntu got published fine as alpha-1...
<highvoltage> I knew the Kubuntu team is really efficient but not /that/ efficient.
<stgraber> ;)
<stgraber> oh and because of that, the html header is wrong too... /me fixes
<stgraber> ScottK: alright, that should be better now
<ScottK> Agreed.
<ScottK> stgraber: Looks good to me.
<stgraber> ok, so as usual bittorrent is the only problem, the seeder doesn't appear to work. I just poked IS to have them take a look
<infinity> stgraber: I'm sure it works fine, but magellanic is crap.
<infinity> stgraber: Note that it's still mirroring from nusakan.
<stgraber> infinity: yeah, but with 4 iso images I had hope it'd catch up a bit faster than usual :)
<infinity> stgraber: It'll catch up.  IS can't make it faster.
<infinity> adconrad@nusakan:~$ netstat -n | grep :873
<infinity> tcp        0      0 91.189.89.127:873       91.189.90.143:38677     TIME_WAIT
<infinity> When it stop suckling, it'll slowly catch up.
<stgraber> infinity: it appears to be done rsyncing now
<infinity> stgraber: Yeahp, just finished, so now it'll take $some_time to do its tracker thing.
<stgraber> I guess it was just rsyncing the kubuntu images again after I moved them to the right directory, the edubuntu images have been announced on the tracker for a while now but without any seed, so maybe the seeding part of magellanic is stuck again :)
 * ScottK notes the time and votes "GO".
<highvoltage> Seconded.
<stgraber> bittorrent isn't there yet, but fine, I'll send the e-mail :)
<psivaa> cjwatson: Do you think the fix that has just been released for bug 1085961 will also fix bug 1080701?
<ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [High,Fix released] https://launchpad.net/bugs/1085961
<ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs with 'ubuntu partman: No matching physical volumes found'" [High,Confirmed] https://launchpad.net/bugs/1080701
<stgraber> cjwatson: can you let the alpha-1 announcement through to u-d-a?
<cjwatson> psivaa: I'm not sure, sorry.  It only affects situations where you were at some point presented with a pop-up question dialog
<cjwatson> stgraber: done
<smartboyhw> Um so can I now say that Alpha 1 has been released? I want to make a thread in ubuntu Forums..
<highvoltage> smartboyhw: go ahead
<stgraber> cjwatson: thanks
<highvoltage> thanks release team
<stgraber> np
<TheLordOfTime> alpha 1 released?
<ScottK> Yes
<TheLordOfTime> ETA on torrents?
<ScottK> stgraber: Thanks.
<cjwatson> psivaa: PS "partman: no matching physical volumes found" is not an error
 * TheLordOfTime was reading the scrollbacks.
<cjwatson> I've deleted it from the bug title to avoid confusion
<stgraber> TheLordOfTime: whenever the seeder feels like it ;) it's an old terribly slow machine that really needs to be replaced...
<TheLordOfTime> heh
<cjwatson> I advise against trying to guess which bits of the syslog are relevant in bug descriptions
<TheLordOfTime> okay, i'll assume the ETA is 67 years then :P
<TheLordOfTime> </joke>
<smartboyhw> Sadly Ubuntu Forums can't do two prefixes at once, if not I could have [edubuntu] and [kubuntu] all together
<stgraber> at least the tracker appears to work, so if one of the flavour really needs torrents now, they can probably start seeding by manually grabbing the .iso and the .torrent
<TheLordOfTime> smartboyhw, do all variants?
<smartboyhw> TheLordOfTime, yes I did
<psivaa> cjwatson: ok, thank you. i remember that advise,  this bug was reported before that :)
<cjwatson> psivaa: asked for more information
<psivaa> cjwatson: ok ill try to add that information
<TheLordOfTime> well, i'll check for the torrent(s) later then.  in the mean time, if anyone on SRU team can spare me a few minutes, i'd like to borrow you to look at something for SRU eligibility checks.  (assuming you're not as busy as you were approaching alpha1 release)
<smartboyhw> TheLordOfTime, well it is released anyway:P
<stgraber> cjwatson, infinity, slangasek: any of you has credentials for Release Notes
<stgraber> doh, bad copy/paste :) meant, https://release-blog.ubuntu.com/wp-login.php
<cjwatson> I think I do
<cjwatson> Looks like it.  Send me content
<stgraber> sure, one sec
<stgraber> cjwatson: based on the previous posts: http://paste.ubuntu.com/1415124/
<infinity> stgraber: Is it a bit sad that I never even knew that blog existed?
<infinity> (and it seems rather pointlessly redundant, unless its whole point is to be syndicated)
<stgraber> infinity: well, I don't think it's really mentioned anywhere, that doesn't help :)
<ogra_> it is aggregated in planet though
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<cjwatson> infinity: syndicated> that
<infinity> ogra_: Yeah, that's what I meant by "its whole point is to be syndicated".
<ogra_> right, i think thats the point
<cjwatson> infinity,slangasek: ^- could you review that one?  it should be the second half of the fix for the 12.04 SB installation problems stgraber reported
<slangasek> looking
<slangasek> ok, queuediff -b with ubiquity uploads overloads firefox
<slangasek> noted
<slangasek> heh, and there's no new bug ref anyway
<cjwatson> Yeah, indeed
<bjf> on raring it seems that 'quilt' is no longer part of the default install. how do i determine if that is true or just a personal problem ?
<infinity> bjf: Was it ever?
<infinity> I can't imagine why it would have been.
<TheLordOfTime> i don't think quilt's been included in any release ever by default...
<TheLordOfTime> (based on observations for quantal, precise, and oneiric)
<bjf> infinity, well, i'm assuming so because i'm having to explicitly install it now for some testing and didn't before
<infinity> It wasn't in any default seeds in precise either.
<bjf> infinity, huh, maybe it was a dependency of something else i was installing and now no longer is
<infinity> bjf: The only thing on my system that depends on it is bzr-builddeb.  Maybe you had that installed before?
<slangasek> cjwatson: what are the conceivable values of altmeta here?  I see it being appended to the name 'linux-signed-generic', but there are no packages from linux-meta that fit that pattern
<slangasek> cjwatson: ah, "-lts-quantal" I guess
<slangasek> cjwatson: ok, accepted.  Do we need to reset the verification status of all the SRU bugs?
<cjwatson> slangasek: -lts-quantal, indeed
<cjwatson> slangasek: I think we just need to complete the SB verification, TBH
<slangasek> ok
<cjwatson> It should already be exhaustive enough
 * slangasek nods
<slangasek> only three of the bugs seem to have been verified yet so it probably wouldn't be a huge difference either way; I'll leave it as-is
<stgraber> cjwatson: so I guess I'll have a new image to test in an hour or so? :)
<cjwatson> If you want to spin one, as I'll probably have EODed by then
<cjwatson> Otherwise tomorrow morning
<slangasek> hmm, the efifb stride bug is still in limbo, isn't it
 * slangasek ponders how to get that tested, since he can only reproduce it with d-i
<bjf> infinity, i'm trying to 'copy-proposed-kernel precise linux-lts-quantal' and i'm getting an error saying the signer of this package doesn't have upload rights
<stgraber> bjf: who's the signer?
<bjf> stgraber, henrix
<infinity> bjf: Got impatient waiting on me?
<bjf> stgraber, he pumps out all the SRU kernels
<bjf> infinity, i like to try my hand from time to time
<stgraber> stgraber@castiana:~/data/code/ubuntu-archive-tools$ ./edit-acl query -P kernel -S precise | grep quantalstgraber@castiana:~/data/code/ubuntu-archive-tools$
<infinity> bjf: Yeah, but I'll just end up rejecting yours and copying my own. :P
<stgraber> well, that copy/paste didn't work as well as I'd have liked ;)
<stgraber> but anyway, that source isn't in the kernel package set
<stgraber> let me fix that for you, then you can retry
<stgraber> bjf: try now
<bjf> infinity, are you serious or not?
<bjf> stgraber, that worked
<bjf> stgraber, thanks
<stgraber> np
<infinity> bjf: Partially serious, in that if I copy, they get auto-accepted, and I can keep track of my workflow better.
<infinity> bjf: And since I need to do other work on copy too (it's not just accepting them), that's why I take that task.
<stgraber> bjf: do you have any other -quantal source I should add? (meta package maybe?)
<infinity> bjf: (And why shankbot probably should assign that task to SRU, not to Kernel)
<infinity> bjf: Well, more realistically, to archive admins, not SRU.
<bjf> infinity, so, we used to bug an AA to do this, then we got perms to do it ourselves so we didn't have to bug an AA and now you are saying that we should always bug an AA?
<infinity> bjf: You kinda have to have an AA touch them anyway, at least on ABI bumps.
<infinity> bjf: And if you've noticed over the last few months, it was always me who closed out those tasks. :P
<bjf> infinity, i'm assuming that at some point you might be on vacation when i need this done
<stgraber> haha, infinity on vacation, good one ;)
<infinity> bjf: Sure, but you guys still can't accept or process them through NEW, so you still need someone else involved.
<bjf> stgraber, ok, maybe he gets hit by a bus
<infinity> bjf: It's doesn't have to be *me* (though it usually is), but it needs AA intervention, yes.
<infinity> bjf: Getting the ability to copy didn't change that, it just changed things from me running "copy-proposed-kernel" to me running "queue accept".
<infinity> And than all the same faff afterward with overrides.
<bjf> infinity, ok, the proper interface is for us to nag, so nag we shall
<stgraber> infinity: though anyone in the SRU team has queue admin rights on -proposed, so is that a case where we could allow them to do the Newing themselves. Or do you actually want to do a full binNEW review on those packages?
<infinity> stgraber: The NEWing there is occasionally complex enough that I'd prefer having an actual AA do it.
<stgraber> k
<bjf> infinity, consider youself nagged :-)
<infinity> bjf: I tend to get to it within a day or less anyway.  Today seems to be a minor exception to that rule.
<bjf> infinity, there's quite a pile waiting to go
<infinity> bjf: Yeah, I'm looking at workflow right now.
<bjf> infinity, i'll get shank-bot changed to assign the correct group if you can tell me the LP group you want assigned
<infinity> bjf: It should be ~ubuntu-sru, though the people actually doing the work should also be AAs, I'm not sure the distinction matters much for the tracking.
<infinity> And I think I may have upset LP with all these copies.
<infinity> I only have about 1/4 of my accept emails so far.
<infinity> Oo, there they are.
<slangasek> stgraber: oh, I thought cjwatson and I were going to flip a coin for alpha2 vs. beta1
<slangasek> (for nusakan)
<infinity> slangasek: You may still slip as many coins as you like.
<infinity> Or flip them, if you prefer.
<stgraber> slangasek: there's still alpha-2 and 12.04.2 to flip coins for :)
<infinity> I suspect Colin will take precise.2 just out of paranoia over SB not exploding.
<slangasek> I was perhaps assuming unduly that 12.04.2 counted separately
* You're now known as ubuntulog
<infinity> slangasek: dpkg-shlibdeps didn't pick up that skype->libssl dep on its own?  Is it dlopen()ed or something crazy?
<slangasek> infinity: I didn't even find evidence of dlopen() in the strings
<slangasek> but yeah, it's not a shlibdep
<cjwatson> skype's well-known for being deliberately obfuscated
<slangasek> cjwatson: even to the point that their own in-house packagers didn't know about this dep ;)
<infinity> Maybe it's doing it through some QT interface that does something fancy at runtime.
<slangasek> could be
<ScottK> IIRC the potentially relevant Qt bits depend on openssl though.
<slangasek> 'apt-cache rdepends libssl1.0.0| grep -i qt' shows nothing relevant
<infinity> (base)adconrad@cthulhu:~$ strings /usr/lib/i386-linux-gnu/libQtNetwork.so.4 | grep libssl
<infinity> libssl.*
<infinity> Not sure what that's all about, but that's the only libssl I find in all the rdeps.
<infinity> And libqt4-network definitely doesn't depend on libssl.
<ScottK> OK.  Then I remember wrong.
<slangasek> oh, you know what
<slangasek> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1056494
<ubot2> Launchpad bug 1056494 in qt4-x11 (Ubuntu Precise) "libqt4-network should have libssl in its depends list" [Medium,Triaged]
<slangasek> I knew about this bug and then forgot :P
<infinity> Hey, lookie there.
<slangasek> hey look, I've even commented on it
<slangasek> <cough> with a veiled reference to skype
<infinity> slangasek: So.  Want to SRU QT instead of updating skype (or, I guess, we can do both, all belt-and-bracers like)
<ScottK> libqca2 ?
<slangasek> oh gah, debfx is claiming a license reason not to link against libssl
<infinity> Surely, a dlopen() on a glob doesn't actually circumvent the GPL's intent there. :P
<slangasek> yes, exactly
<slangasek> so either we should just make it a dep, or we already have a problem
<slangasek> debfx: can you clarify what license issue you see in bug #1056494?  Qt itself is LGPL so has no issue with libssl; and making it optional in the code doesn't help any when in practice we're shipping qt together with libssl in all cases
<ubot2> Launchpad bug 1056494 in qt4-x11 (Ubuntu Precise) "libqt4-network should have libssl in its depends list" [Medium,Triaged] https://launchpad.net/bugs/1056494
<infinity> slangasek: It's only been LGPL for ~3 years, maybe he's just living in the past slightly. :)
<slangasek> it could be a concern about GPL revdeps of Qt
<infinity> I've always been a bit fuzzy about indirect linking being considered a derivative work if you don't actually use any of the offending functions.
<infinity> Though, I suppose with an abstraction layer like qt-network, it's hard to avoid using bits if they're there.
<slangasek> it's not a question of derivative works
<slangasek> it's a condition of the GPL
<infinity> Oh, er, right, I was thinking in the other direction.
<infinity> Brain's not in debian-legal mode this afternoon.
<infinity> Which is likely a good thing.
<slangasek> that reminds me, there's a mailing list somewhere where I need to go set the record straight about MongoDB :-P
<stgraber> slangasek: sounds like canonical-tech (mostly because 90% of the posts are about mongodb) ;)
<slangasek> ?
<slangasek> whose sync is that?
<infinity> That was me.
<infinity> Did you not want it out of proposed after all?
<slangasek> infinity: preempting the question of whether we should fix this in Qt instead?
<infinity> slangasek: I think we should also fix it in QT, but it doesn't hurt to fix it in skype for now.
<ScottK> JFTR, Qt.  QT is the thing Apple makes.
<slangasek> well, it's divergence from upstream and we don't really want to have to be responsible for that, but yeah
<infinity> ScottK: Picky, picky.
<infinity> slangasek: Well, I may have already copied it to raring a little bit.
<slangasek> infinity: shrug, you might as well follow through then
<ScottK> FWIW, libqca2-plugin-ossl is the Qt/SSL thing I was thinking of.
#ubuntu-release 2012-12-07
<cjwatson> stgraber: I did an updated precise build for you, in case you're still around
<stgraber> cjwatson: ah cool, I'll give it a try
<stgraber> now that I'm done banging my head against the wall trying to figure out how nih-dbus-tool does its magic :)
<slangasek> stgraber: do you have a bug # handy for the "can't boot unsigned kernels" bug on your system?  I'd like to start digging into that with you too before .2
<stgraber> hmm, I can't remember whether I filed a bit for that one or not, let me look at my recently filed bug list :)
<stgraber> can't find one... I'll file a new one against shim so we can track that issue
<stgraber> slangasek: bug 1087501
<ubot2> Launchpad bug 1087501 in shim (Ubuntu) "Unable to boot unsigned kernel, boot freezes in shim call" [Undecided,New] https://launchpad.net/bugs/1087501
<slangasek> ok
<stgraber> slangasek: once I'm done testing the new precise image for Colin, I'll do another run of grub with debug=all and attach a picture to the bug. I doubt it's going to really help though as all that we'll see is that it's calling a function that the shim exports.
<slangasek> yep
<slangasek> so as a first step, I'd like to do a build of the new upstream version of shim, where mjg59 has entirely dropped the fallback code for calling the UEFI protocol
<slangasek> (the same UEFI protocol that was popping up dialogs on signature failure)
<stgraber> I've been playing with EFI a bit lately and I think I have a working .efi binary that when called will load my local PKI's certificate into the firmware, allowing me to sign my own binaries. That should help quite a bit.
<stgraber> I know that in theory I can also just write new entries from Ubuntu while in setup mode but I haven't found a good tool for that yet (that just takes a standard SSL cert and loads it)
<cjwatson> stgraber: debug=all> we already tried that at UDS and showed it just calling said function, indeed - I don't think it was useful for debugging this
<slangasek> stgraber: yes, for debugging you definitely want to be using self-signed binaries :)
<slangasek> (at least self-signed shim)
<stgraber> slangasek: btw, is there any reason why /sys/firmware/efi/efivars is world readable but /sys/firmware/efi/vars is only root readable?
<stgraber> found it a bit weird considering they export the exact same information just with different paths :)
<slangasek> stgraber: ummm because the former is a mountpoint and I didn't think to change the defaults? :)
<slangasek> it shouldn't be a security issue in practice, but maybe we do want to lock it down to be root-only by default
<slangasek> can you file a bug report on mountall for this?
<stgraber> will do once I'm back to my standard desktop (currently in the middle of the precise install)
<stgraber> cjwatson: well, the good news is that grub is booting
<stgraber> cjwatson: the bad news is that it has no menu and can't seem to find anything
<stgraber> so I'm stuck in grub minimal
<stgraber> and back to a working laptop, now let's see what was broken this time around :)
<stgraber> cjwatson: so at first glance, my bet would be on the missing grub directory under /boot/efi/
<stgraber> cjwatson: at the end of this install the EFI partition only contains two directories, EFI and LOST.DIR, no grub
<stgraber> cjwatson: installer log: http://paste.ubuntu.com/1416091/
<stgraber> cjwatson: btw, to make things simpler this time around I unplugged my internal ssd before the installation
<stgraber> cjwatson: that may explain why my previous test had the grub directory present as the EFI boot partition was shared with the one from my raring system and therefore already had a grub directory.
<stgraber> slangasek: efivars bug 1087546
<ubot2> Launchpad bug 1087546 in mountall (Ubuntu) "efivars filesystem gives more access than the exists vars directory" [Undecided,New] https://launchpad.net/bugs/1087546
<slangasek> stgraber: /boot/efi> secureboot doesn't get a grub directory, you get a monolithic grub .efi because it's not allowed to load unsigned code?
<stgraber> slangasek: ah, ok, so I must have it on my laptop because grub-install has been running a few times without secureboot. So it's something else that's broken in the secureboot grub that's on the precise image
<stgraber> so trying to boot the same disk in a VM (so I can slow it done and see what's going on), I'm seeing a bunch of "error: efidisk read error.", then drop in a minimal grub shell and that's all I get
<stgraber> *down
<slangasek> strange
<slangasek> "efidisk read error" isn't anything I'm familiar with, I guess it could be a grub-specific error message when it tries to use the efi disk protocols
<stgraber> yeah, and that VM isn't running with secureboot enabled, so it's not the firmware blocking access or anything like that
<stgraber> and just to be 100% sure, I checked that the md5sum of /boot/efi/EFI/ubuntu/grubx64.efi matches that of /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed, so it's not some kind of random vfat corruption that happened at install time
<stgraber> anyway, enough uefi fun for the evening, will wait for cjwatson to show up
<ScottK> Looking at the SRUs in -proposed, I see that walinuxagent is fixing a private bug (bug  	#1077147).  It seems to me that any bug being dealt with in the SRU process ought to be public (if needed, support people could make a sanitized version of the bug for public consumption.)
<slangasek> yes, I agree; this has been communicated in the past, but it needs to be repeated from time to time
 * ScottK wonders if removing the upload from proposed would be an adequate form of 'communication'?
<cjohnston> lol
 * ScottK is not kidding.
<slangasek> preferably telling the uploader why at the same time?
<ScottK> Yes.  That too.
<slangasek> then yeah
<slangasek> it clearly can't be accepted as-is
<ScottK> Additionally, it doesn't appear it was accepted into quantal by a member of ubuntu-sru
<slangasek> sigh
<slangasek> hmm, no, infinity accepted it
<slangasek> (per the comment on the private bug)
<ScottK> For precise
<slangasek> oh
<ScottK> https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1079897/comments/11 indicates Dave Walker for quantal
<ubot2> Launchpad bug 1079897 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent mangles server identity and access on upgrade" [Critical,Fix committed]
<ScottK> Since infinity accepted it for one release, maybe he'll take responsiblity for getting the bug unprivate ....
<slangasek> man, I really don't feel like I'm accomplishing anything with these precise new queue approvals without queuebot to cheer me on
<ScottK> OK, so removed walinuxagent and pinged the bug/uploaders.
<ScottK> (to complete the record here for backscroll readers)
<infinity> ScottK: Gah.  I could have sworn walinuxwhatever used to reference a public bug.
<infinity> Err, it does.
<infinity> ScottK: Oh, that was just a "new upstream" bug from a previous changelog entry.  I'm not sure that was worth removing for. :/
<infinity> ScottK: I don't agree that asking people to revise their changelog to sanitize out dupe bugs is sane at all.
<infinity> ScottK: It clearly was a dupe of an identical public bug, from the changelog.
<xnox> ScottK: walinuxagent is a valid bug. And references public bugs. Also that SRU causes dataloss and rendering sertain machines unreachable.
<xnox> ScottK: infinity: can we please revert removal?
<infinity> xnox: You can't "revert" removal.
<infinity> xnox: It'll need a new upload with a bumped version.
<infinity> Oh, actually.  That might not be true.
<xnox> infinity: it is scheduled "in 3h time or something?!"
<infinity> We can copy from proposed to proposed to make it magically reappear.
<xnox> =)))))
 * infinity tries that.
<xnox> ScottK: infinity: while the SRU procedure was not followed, it is best to speak with individual in question publically on u-d, instead of blindly removing packages from -updates.
<infinity> xnox: The procedure was followed.
<xnox> righ.
<xnox> So why is ScottK removed both of them?
<infinity> (It's just that the changelog references one private (dupe) bug).
 * xnox thinks about grammar.
<infinity> And I'm not editing the changelog and reuploading, when it's obvious that's the case.
<infinity> xnox: That said, the procedure absolutely was NOT followed for Quantal. :P
<infinity> xnox: I'm only restoring the one I accepted into precise.
<xnox> infinity: the bug causes dataloss & renders machines unreachable. I'd want to see both packages restored asap.
<infinity> xnox: That's no excuse for non-SRU members accepting SRUs.
<xnox> Daviey: jamespage: ^^^^^^^ walinuxagent - Daviey, you shouldn't accept SRUs. (you can via AA rights, but you shouldn't due to not being SRU team member). And now walinuxagent is being removed from the updates pocket.
<xnox> win \o/
<xnox> infinity: what do you want to happen for quantal SRU to be re-published?
<infinity> xnox: I want to wait until I discuss this with ScottK and slangasek tomorrow to grasp why it was such a monumentally big deal to have a changelog reference a private bug (when it was clearly a dupe, I know exactly why it's bad when it's not).
<Daviey> xnox: This is something that has only been clarified recently.
<infinity> Daviey: Uhm.  If "recently" means "before you were an archive admin", I agree.
<Daviey> No.
<infinity> ScottK / slangasek: I absolutely agree that SRUs shouldn't ref private bugs, but I also think that people reviewing these things should have the ability to read changelogs instead of blindly clicking on a list in a UI.
<Daviey> infinity: erm, that isn't quite what happened.. And i'd appreciate a less sarky attitude please.
<infinity> Daviey: What isn't what happened?
<Daviey> infinity: you are shooting off comments, without facts.  It is inappropriate.
<infinity> Daviey: Which comment lacks facts?
<Daviey> infinity: Firstly, i was informed from an ~ubuntu-sru member that it was agreed at UDS before last that AA's could handle SRU's. Secondly, i checked with another member that it wouldn't cause upset.. and thirdly, "blindly clicking on a list in a UI." is just flippant.
<Daviey> That is not what i did.
<infinity> Daviey: That last comment had nothing to do with you, it had to do with people clicking bugs and noticing they're private and knee-jerking, rather than reading the changelog to see the ref.
<Daviey> Oh, ok.  Apologies.
<infinity> Anyhow, the first part is a twisting of the part where we had a conversation suggesting AA/SRU/Release should perhaps be merged (and then opted not), second, whoever you checked with was, well, wrong?  Third, this is all documented. :/
<Daviey> infinity: I wasn't in the session i don't think.. But when a ~ubuntu-sru member tells you something like that, it seems reasonable.
<Riddell> how do I put a block on migrating from proposed (for KDE SC)?
<infinity> (base)adconrad@cthulhu:~/britney/hints-ubuntu$ cat kitterman
<infinity> # Keep KDE SC 4.9.90 from migrating before we are ready
<infinity> block kde4libs
<infinity> Riddell: ^-- Like that one?
<infinity> Riddell: (ScottK appears to be on the case)
<Riddell> lovely
<infinity> ScottK: So there's public record of this in the channel, Daviey and I have talked privately, and I'll be giving him some formal training, but there won't be any more SRU accepting by him until after that happens.
<cjwatson> stgraber: For your VM test, make sure you have enough RAM.  I wasted a couple of hours a few weeks ago because I was running kvm with its default of 128MB, but UEFI/OVMF/whatever is too memory-hungry for that to work
<cjwatson> Daviey: If you mean with me, since the conversation was in person I don't have a word-for-word record; but I believe I said that I thought it was acceptable for AAs to step in occasionally outside their usual line of work if other avenues had been exhausted
<cjwatson> I don't think it should be a routine thing
<Daviey> cjwatson: Actually, that wasn't you.. you were the followup.  The outcome of our conversation IIRC was that it was 'OK', but should really look to get in officially.. Which is what i did.
<cjwatson> stgraber: What's in /boot/efi/EFI/ ?
<cjwatson> (a.k.a. /EFI/ on the EFI System Partition)
<jdstrand> infinity: hey, fyi, you mentioned a CC in the team status reminder, but there was no CC. I'll forward it along to my guy
<infinity> jdstrand: SRSLY?
<infinity> Cc: brendan.donegan@canonical.com, didrocks@ubuntu.com, marc.deslauriers@canonical.com,
<infinity>         leann.ogasawara@canonical.com, antonio.rosales@canonical.com, fathi.boudra@linaro.org,
<infinity>         para.siva@canonical.com, jriddell@ubuntu.com, ogra@ubuntu.com, alan.pope@canonical.com
<infinity> jdstrand: It was CCed, the header just got stripped off the lists copy.
<jdstrand> oh, interesting
<jdstrand> I didn't know the list would do that
<jdstrand> infinity: ok, sorry for the noise :)
<psivaa> cjwatson: i have attached ubiquity debug logs as asked in bug 1080701
<ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701
<cjwatson> psivaa: Thanks
<cjwatson> xnox: ^- Do you think you could have a look at that, please?  I think you've touched this code most recently
<xnox> cjwatson: ok. I will look into it later today.
<psivaa> xnox: cjwatson: thanks
<cjwatson> xnox: Thanks
<stgraber> cjwatson: a single ubuntu directory containing shimx64.efi and grubx64.efi
<stgraber> cjwatson: the VM had 2GB of RAM, so shouldn't be the problem and I get the same on baremetal with 16GB
<slangasek> infinity: in the changelog I looked at, it was note a dupe: Backport new upstream version (LP: #1078074) from current development release including fix for critical issue during upgrade (LP: #1079897).
<ubot2> Launchpad bug 1078074 in walinuxagent (Ubuntu Quantal) "[SRU] Update walinuxagent to version 1.1" [High,Triaged] https://launchpad.net/bugs/1078074
<ubot2> Launchpad bug 1079897 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent mangles server identity and access on upgrade" [Critical,Triaged] https://launchpad.net/bugs/1079897
<slangasek> infinity: in this case I mentioned to ScottK I didn't mind if it was published with that particular bug reference present since the bug itself was nothing more than "New upstream release"
<infinity> slangasek: That's not the private bug.
<infinity> * New upstream version (LP: #1078074, #1077147).
<ubot2> Launchpad bug 1078074 in walinuxagent (Ubuntu Quantal) "[SRU] Update walinuxagent to version 1.1" [High,Triaged] https://launchpad.net/bugs/1078074
<infinity> ^-- The second one there is the private.
<slangasek> infinity: ah, then apparently I got my wires completely crossed while looking at changelogs
<infinity> https://launchpad.net/ubuntu/+source/walinuxagent/1.1-0ubuntu2~12.04.1
<infinity> Had the top-referenced bug been private, I would have had the same grump.
<slangasek> infinity: so I don't object to this SRU being resuscitated as-is
<infinity> Check.
<infinity> I'll review the Q one and copy it back in (I already did so for precise)
<infinity> And I'm going to give Daviey some training $soon.
<cjwatson> stgraber: I think the answer is going to be that I have to pair-debug this with you at a time when it's mutually convenient
<cjwatson> stgraber: But today my head is full of cold and I don't think I'm in a useful state to do much about it
<cjwatson> stgraber: So maybe Monday?  What kind of time do you start then?
<cjwatson> the efidisk read error might be a consequence of a wrong bootstrap config file in the embedded memdisk
<cjwatson> at any rate that's my best guess at the moment - but I'd have to stare at it
<stgraber> cjwatson: Monday morning is pretty bad for me because of a bunch of meetings. I start at 14:00 UTC but have meetings between 15:00 and 16:00 and between 17:00 and 17:30
<cjwatson> stgraber: ok, I think I'm actually free 16 to 17 - but maybe Tuesday then?
<stgraber> cjwatson: I have nothing on Tuesday so that'd work a lot better :)
<infinity> cjwatson: Oh, pursuant to an old conversation, here's a prime example of my subconscious need to (almost) fully-justify things without really thinking about it:
<infinity> https://launchpadlibrarian.net/125129559/qemu_1.2.0.dfsg-4_source.changes
<infinity> cjwatson: Extra sad, since that was just a test package I did for hallyn.
<utlemming> infinity: on walinuxagent, I've cleared the private bug -- its now public
<utlemming> infinity: all confidential information has been hidden.
<infinity> utlemming: We decided that wasn't necessary in the end, but thanks anyway. :)
<infinity> utlemming: I've recopied both SRUs to proposed (binaries and all, so if you'd previously done verification on them, that verification is still valid)
<utlemming> inifinity: okay great...do we know when it will land?
<infinity> Was all the verification done and ready to go?
<infinity> If so, I can quickly run through the paperwork and do some releasy magic.
<utlemming> infinity: yup. That was private tracking bug that we used for talking to MS. It really shouldn't have been referenced. But, yes, verification is done
<slangasek> infinity: hmmm my copy of your mail to u-release includes 0 CC:s
<infinity> slangasek: mailman strips the CC header.
<infinity> slangasek: I assure you that people got the mail.
<slangasek> wat
<infinity> slangasek: (Or, so I've been told by $people)
<slangasek> mailman has never, ever stripped cc:s for me before
<slangasek> but ok, as long as you're sure people got the memo
<infinity> slangasek: It did this time.  Perhaps because it tripped the "too many recpients" thing?  (which it did, I had to moderate it)
<slangasek> right, that could be a special case
<slangasek> stgraber: on iso.qa, I see that desktop and preinstalled are both "active" products for armhf+omap*.  Is this because the list is used for both the current release and the LTS point releases?
<stgraber> slangasek: yep
<slangasek> ok
<stgraber> hmm, not that we do point release for armhf, do we?
<stgraber> if we don't we can probably just disable preinstalled
<slangasek> it doesn't appear that we did 12.04.1 for armhf
<slangasek> except for ubuntu core
<infinity> Yeah, we don't do point releases on those images.
<ogra_> slangasek, hmm, i thought respinning armhf was undesired
<infinity> ogra_: It is.  This is just the tracker that needs to learn that, the rest of us know. :)
<ogra_> oh. ok
<cjwatson> stgraber: though it occurs to me that I could build myself a grub image that thinks it's SB and refuses to load modules, even though it really isn't
<cjwatson> I might have a go at that on Monday.  Not sure why I haven't tried that before
<stgraber> cjwatson: oh, I may have forgotten to mention that SB or non-SB gives me the same thing, so if you have an EFI system, booting the signed binary should trigger the bug
<slangasek> stgraber: so IIRC, the theory was that we would ditch the wiki manifest in favor of something that lives in the iso tracker; I cannot currently find any page in the ISO tracker that accurately shows me what we're expecting to release for raring.  Halp?
<stgraber> slangasek: right, so we have a way of storing the manifest on the tracker, by going to a manifest page under the series tab in the admin. However the implementation has discussed at UDS had a flaw ;) we said we wouldn't need that list to be overridable per-milestone but we clearly do.
<cjwatson> stgraber: no, I test-installed in OVMF before I gave it to you, so it's not that simple
<med_> infinity, as I understand scrollback, walinuxagent is about to go "live" in precise-updates and quantal-updates?  Is there a timetable for that (ie, within 24 hours?)
<cjwatson> it might be the memory allocation bug that Dell want me to fix, I guess ...
<slangasek> stgraber: ehm, so, I was expecting this to be the manifest for the release
<stgraber> cjwatson: I can send you a compressed disk image of my drive if you want? "sudo qemu-system-x86_64 -L . -hda /dev/sdc -m 2048" clearly gives me the same bug here as on metal
<infinity> med_: Less, probably, I just need to stop multitasking and poke it.
<cjwatson> stgraber: couldn't hurt ...
<slangasek> stgraber: is the problem here that it's being used by nusakan to control the actual milestone publishing, and therefore needs to keep track of the differences?
<med_> infinity, nod, thanks.
<stgraber> slangasek: so the way it works currently is that you can set a milestone to be based on the manifest, in that case, whenever a daily that's pushed by nusakan is present in the manifest, it'll be automatically added to the milestone.
<stgraber> slangasek: so if we had listed everything in the manifest for alpha-1, then all the products would have showed up in the alpha-1 milestone on the tracker
<stgraber> slangasek: my current thought of a quick fix for this limitation is to add a disabled flag to those manifest entries, so that we can choose which are currently active and should be used when posting images
<stgraber> that way we can add all the products and their contacts for the release and before a milestone, disable them all and only enable those that are participating
<slangasek> stgraber: what about not automatically posting the images to the milestone?
<slangasek> wouldn't require code changes, could be implemented immediately
<stgraber> slangasek: well, I surely intend to lend the active/inactive flag way before the next milestone
<stgraber> slangasek: so there's no problem populating the manifest already
<stgraber> *land
<infinity> *sigh*... Has anyone yelled at seb128 about breaking ubuntu-desktop?
<slangasek> infinity: er?
<infinity> http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html
<infinity> slangasek: Due to the im-switch -> im-config change without an MIR (or two).
<slangasek> stgraber: ok, so... do we have the data somewhere, that can be used to repopulate this?
<slangasek> infinity: britney allowed this?
<stgraber> slangasek: nope because I don't think we actually asked th product leads what they're planning on releasing for raring. We can base it on quantal though and then ask everyone to check that it's correct
<infinity> slangasek: Britney doesn't deal in components currently.
<slangasek> stgraber: I think that's a good place to start then.  Can you do that easily?
<stgraber> slangasek: yep
<slangasek> stgraber: ok, then please do :)
<slangasek> infinity: so, are you reverting language-selector?
<infinity> slangasek: I suppose that's the way forward for the weekend.
<infinity> slangasek: And the seeds, and ubuntu-meta.
<infinity> Oh, maybe not meta.
<infinity> Nope, meta hasn't been refreshed yet.
<slangasek> yes, and we have a wiki page somewhere for tracking reverts, right?
<infinity> But I'll revert the seed change.
<infinity> We do.  Somewhere.
<slangasek> https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog, editing
<slangasek> infinity: were there any bug reports for this?
<infinity> slangasek: It just landed in the archive a few hours ago and Andy whined that upgrade was taking out ubuntu-desktop.
<infinity> Let me go see if there's a bug report.
<slangasek> infinity: well, if you're doing the reverting upload, please do that first :)
<slangasek> we can find and fix bug reports after
<infinity> Already done.
<slangasek> ah, thanks
<infinity> Might even build before the publisher.
<infinity> Nothing new on language-selector, but heaven knows what other random packages it could have been filed on.
<infinity> And my build beat the publisher.
<infinity> Yay.
<slangasek> no obvious bug reports that I can see
<stgraber> slangasek: http://iso.qa.ubuntu.com/qatracker/series/32/manifest
<infinity> Why do I keep ending up ad server amd64+mac?
<infinity> I swear I fixed that in the wiki before.
<stgraber> based on quantal's manifest and dropped armel products. I don't think I missed anything but that's a long list
<stgraber> infinity: well, you didn't fix https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest apparently ;)
<infinity> (And I'm positive it's cause someone saw "mac" and saw I was on the hook for PPC, and extrapolated)
<slangasek> heh
<stgraber> I'm not even sure why we build a +mac server image to start with :)
<infinity> We probably shouldn't.
<infinity> Well, ideally, we shouldn't have to build any +mac images.
<stgraber> yeah, would be nice to finally get the full hybrid images working and getting rid of +mac
<stgraber> not sure how far cjwatson got on that though
<infinity> Did he ever manage to kidnap a Mac from the kernel team?
<slangasek> infinity: thanks for volunteering to hack the ISOs in your spare time!  Hardware is on its way
<slangasek> ;)
<infinity> AFAIK, he was blocking on having real hardware to debug with.
<slangasek> no, actually the hardware is kidnapped in my direction
<infinity> Ahh.
<infinity> Plz fix.
 * infinity emails the responsible parties.
<infinity> Weird.  mailman is definitely munging CCs.
<infinity> In my =Sent folder, I have "Cc: gunnarhj@ubuntu.com, seb128@ubuntu.com"
<infinity> The mail from the list only has Gunnar.
<slangasek> infinity: oh; correction, the macs are not kidnapped in my direction, they are sitting on my doorstep
 * slangasek fixes this
<xnox> slangasek: so you are joining the apple crowd =) I am sure ev & barry would give you a hug. (and doko & myself to some extend)
<slangasek> xnox: I'm only here to kill off an ISO
<slangasek> after that the hardware goes away again ;)
 * ScottK cheers killing off an ISO.
 * xnox can image slangasek using a separate tagged vlan for macs in a quarantine room, just in case they pollute the rest of machines.
<stgraber> you don't need network access to test iso images
<infinity> Nor a room.
<slangasek> hahaha
<infinity> In fact, I recommend testing ISOs on Macs in the middle of corn fields.
<ScottK> Not unless there will be excessive public displays of affection otherwise (re the room)
<infinity> ev: Say, how many iProducts do I need to send you to make the wubi-e2fsprogs-doesn't-support-ext4 thing go away?
<infinity> xnox: Or, since you seem to have some perverse obsession with cross-building Win32 stuff, maybe I should be asking you. :P
<xnox> infinity: yes, you should be asking me. Let's see if I can double this up together with fix 5-cross-compiles.
<slangasek> you cannot
<slangasek> :P
<infinity> Wow, e2fsprogs still uses dh_movefiles.
<slangasek> that's a work item for cross-compiling to /real/ platforms :)
<infinity> slangasek: He may well be able to, e2fsprogs is broken in http://people.canonical.com/~cjwatson/cross/armhf/raring/
<slangasek> hah
<slangasek> ok fine
<infinity> slangasek: If he fixes it for the armhf cross case, it might Just Work for a mingw32 target.
<infinity> (might)
<slangasek> the converse seems more likely
<infinity> True.
<xnox> hah =)
<barry> you'll pry my mbp out of my hands when i get a 1440x900 ultrabook :)
<infinity> barry: Will 1600x900 do?
<slangasek> infinity: ok, this cc: issue is clearly something on your end, you said "hi guys" but have only one Cc :)
<infinity> barry: The Carbon is definitely ultrabooky.  And pretty sexy.
<barry> infinity: it just might
<infinity> slangasek: I mentioned this half an hour ago.
<barry> infinity: i basically want a macbook air that's not a mac :)
<infinity> barry: The ThinkPad X1 Carbon is pretty much exactly that.
<infinity> barry: With the bonus of being a less crap keyboard, and a sexier cover.
<slangasek> infinity: ah yes, missed that
<infinity> Also, a nipple.
<xnox> there is also a new asus ultrabook which I didn't compare to thinkpad yet.
<barry> infinity: i'll have to try to play with on.  my last thinkpad's keyboard killed my hands :/
<slangasek> infinity: anyway, I have a hard time believing it's mailman
<infinity> barry: Was that the classic ThinkPad keyboard they've shipped for the last decade, or the new chicklet ones?
<xnox> barry: surprisingly X1's keyboard is similarish to the spread out mb keyboards.
<barry> infinity: pre-chicklet
<infinity> barry: Well, if you're using chicklet Macs, my personal opinion is that the Lenovo chiklets are much more pleasant.
<infinity> barry: But YMMV.
<barry> infinity: definitely something to investigate.  thanks.  (i'm up for refresh next month)
<infinity> I'd probably buy a Carbon tomorrow if they shipped with more RAM.
<infinity> 8G.  Bah.
<barry> yeah.  air max is 8g but 512 ssd i think
<infinity> That Carbon's SSD appears to top out at 256 on the web form.
<infinity> Then again, I don't know why I need more local storage than that (I don't).
<barry> multitrack audio!
 * xnox is reminded of the "WE LOVE BARRRRRY" chants during NoNameYet band debut gig.
<barry> oh gawd
<barry> chanting the bass players name has killed universes
<xnox> barry: was it recoreded?
<barry> good question for pgraner
<slangasek> xnox: the gig, or the death of universes?
<barry> slangasek: you wouldn't be able to hear the latter.  it's at 1 x 10 ^ (-graham's number) hz
<xnox> slangasek: former in flac, later in 3D video (I expect something no less exiting to hitchhickers guide to the galaxy style launching space ships into stars)
#ubuntu-release 2012-12-08
<pgraner> barry, I don't think anyone recorded it, I haven't even seen video
<stgraber> cjwatson: image of my external disk is at: http://www.stgraber.org/download/uefi-sb-precise.tar.xz (1.6GB compressed, 32GB uncompressed)
<cjwatson> stgraber: thanks
<slangasek> cjwatson: ok, singularly unhelpful; I hold down 'alt' on this MacBook Air, it gives me an EFI boot menu, I choose the USB stick (which is just a dd of the raring image), and I get the GRUB menu with no problems
<slangasek> cjwatson: any idea how I should be doing this to reproduce the *not* working cases? :)
<ScottK> The answer might be "get an older Mac"
<slangasek> yeah, maybe
<slangasek> this one is a 4,something
<slangasek> (4,2?  I don't have dmidecode output pulled up anymore)
<slangasek> 12.04.1 gives me the syslinux menu instead, which at least confirms that something was fixed Mac-wise in the image booting during the SB work
<slangasek> (12.10 also gives the grub-efi menu)
<ScottK> shadeslayer: What version is your Macbook?
<slangasek> correction, 4,1
<shadeslayer> 4,2
<shadeslayer> erm
<shadeslayer> 8,2
<shadeslayer> getting Ubuntu to EFI boot on a mac is ... interesting
<shadeslayer> kms drivers conflict, you have to boot with radeon.modeset=0 ... and then use the fbdev driver for X
<slangasek> shadeslayer: right; the radeon driver is something sforshee is working with upstream on AIUI, at the moment I'm mostly concerned about making sure we have the image layout correct so that it boots everywhere
<shadeslayer> ah
<shadeslayer> slangasek: I actually have to make grub-efi loopmount the ISO and then boot it
<shadeslayer> that's the only way to get EFI booting on my mac
<slangasek> and is that the case with 12.10 / raring as well?
<shadeslayer> but I'll be happy to test out stuff
<shadeslayer> yes
<slangasek> ok
<slangasek> hmm, but wait
<anoteng> Hello, bug #1087999 can be easily fixed by copying the newer upstream version from raring. I believe I know which upstream commit fixed the bug, but since the upstream changelog is small and transgui is neither widely used nor has any reverse dependencies I believe it would be ok to sync from raring. Do you guys concur, or do I have to prepare a patched version of the version already in quantal?
<ubot2> Launchpad bug 1087999 in transgui (Ubuntu) "UI event focus stuck in some pane, impossible to reach the rest of the UI" [Medium,Confirmed] https://launchpad.net/bugs/1087999
<slangasek> where is the copy of grub-efi that's being booted?
<shadeslayer> it's a combination of doing this : http://wiki.sabayon.org/index.php?title=UEFI_Boot#preparing_the_USB_stick : and untarring this : http://people.ubuntu.com/~rohangarg/efi.tar.xz : in the root dir of the USB
<slangasek> anoteng: not really the right place for the question; try asking on #ubuntu-devel?
<ScottK> anoteng: It's better to grab the single commit and prepare an SRU based on that.
<ScottK> But that too.
<shadeslayer> slangasek: it's on the root dir of the USB stick
<shadeslayer> but the USB stick itself needs to be prepared in a special way as described on that wiki page
<slangasek> shadeslayer: so, er, have you tried just dd'ing a hybrid image to the USB stick?
<shadeslayer> yes, didn't work the last time I tried it in quantal
<shadeslayer> but haven't tried in raring
<slangasek> shadeslayer: was that with the quantal release, or was it before release?
<shadeslayer> it was with the release iirc
<slangasek> because there were changes in the image mastering during 12.10 development
<shadeslayer> I see
<slangasek> related to secure boot, but may have also benefited macs
<shadeslayer> ok, I'll try with the Kubuntu alpha release
<shadeslayer> ( raring alpha that is )
<slangasek> shadeslayer: cool, looking forward to hearing the results
<shadeslayer> slangasek: is there some way I can track the status of the radeon issue?
<shadeslayer> having to use fbdev sucks :(
<slangasek> shadeslayer: well, there's an upstream discussion for it, https://lkml.org/lkml/2012/10/25/442; I don't know whether there's a bug in LP, you might check with sforshee
<shadeslayer> cool
<shadeslayer> slangasek: thx for the link
<shadeslayer> wohoo
<shadeslayer> slangasek: it works!
<shadeslayer> now the only problem is the radeon stuff ....
<slangasek> shadeslayer: hah, ok :)
<slangasek> shadeslayer: and the radeon problem shows up only when doing EFI boot, correct?
<shadeslayer> if someone fixes the radeon stuff in raring I'll have to stop considering buying a new laptop \o/
<shadeslayer> slangasek: right
<shadeslayer> in BIOS mode the intel card doesn't get picked up
<shadeslayer> and the HDD is accessed via IDE
<slangasek> that's odd; installing raring onto the mac mini, it now reboots straight into grub even if I hold down lwin
<slangasek> have to grab a grub shell and type 'exit' to get back to refit
<slangasek> (grub gives an OSX boot option which seems to not quite work)
<phillw> slangasek: oh for PPC to actually boot into grub :)
<slangasek> heh, that's an entirely different question
#ubuntu-release 2012-12-09
<slangasek> aha, finally found something that doesn't work the same on the amd64 and amd64+mac images: USB BIOS boot on the Mac Mini
<ScottK> infinity: If you'd accept php-horde-crypt-blowfish from binary New (It's my upload, so I can't), the whole horde thing might be unscrewed.
<infinity> ScottK: For serious?  I'm all for unscrewing that mess.
<ScottK> Something happened about 6 hours ago and suddenly all but that one built.
<ScottK> So no promises about migration, but at least they'll all have binaries.
<infinity> Well, the britney output on Debian suddenly got better too.  So, I assume someone uploaded a missing package.
<infinity> I've been looking every couple of days.
<infinity> stgraber: queuebot seems to have failed to track raring/new.
<ScottK> Oddly, I think the one I fixed was the only one that migrated (or I'm looking at Britney output wrong)
<infinity> Looks like the rest already migrated in a previous run.
<infinity> I see none in excuses.
<infinity> I assume someone uploaded php-horde-stream, or whatever the missing one was.
<ScottK> I must have hit refresh too soon.
<ScottK> I guess that's one thing done.
<cjwatson> infinity,ScottK: I happened to notice auto-sync grabbing a huge pile of new php-horde-* packages
<doko> cjwatson, could you have a look how to accept gcc-defaults-armhf-cross (NEW)?
<cjwatson> doko: http://paste.ubuntu.com/1421054/ suggests that you need to bump the version somewhere
<cjwatson> those file names are indeed already in the archive
<cjwatson> so rejecting those since it doesn't look possible to accept them
<shadeslayer> slangasek: would you have an idea on the suspend/resume status of Ubuntu on the Macbook Pro? ( 2011 models )
<shadeslayer> or should I poke sforshee
<ScottK> shadeslayer: AIUI, he was just working on installer stuff.
<shadeslayer> oh
<shadeslayer> okay
<slangasek> shadeslayer: definitely a question for sforshee
#ubuntu-release 2013-12-02
<ogra_> cjwatson, hmm trying to merge rsalveti's goldfish support into cdimage ./run-tests produces http://paste.ubuntu.com/6508783/ even before i merge his code ...
<ogra_> cjwatson, this is on precise (in case it matters) ...
<ogra_> hmm, happens even if i remove the last few commits from the tree
 * ogra_ does a cresh bzr checkout
<ogra_> *fresh too
<ogra_> hmm, no, doesnt change a thing
<ogra_> aha, works fine in a trusty chroot
<jamespage> could someone flush git through the NEW queue for trusty - its blocking openstack package builds in one of the server CI labs right now
<jamespage> please (sorry - forgot my manners for a moment then)
<rsalveti> ogra_: hey
<ogra_> hey
<ogra_> wrangling with your merge currently
<rsalveti> ogra_: seems the test failures are not related with the code I changed
<ogra_> no, they show on older commits too
<ogra_> and dont show in a trusty cheroot
<rsalveti> ogra_: right
<ogra_> i'm on my xps now ... that hasa trusty setup ... if it works there i'll commit and push
<ogra_> (and start a test image)
<rsalveti> ogra_: cool, thanks
<zul> can someone have a look at git please, it has some pending binaries https://launchpad.net/ubuntu/+source/git/1:1.8.5-1 thats blocking the openstack-ci lab
<rsalveti> stgraber: hey, so we finally have the goldfish files in cdimage, can you enable it in system-image?
<shadeslayer_> Could someone review kscreen in the unapproved queue plz ? bug 1254125
<ubot2> Launchpad bug 1254125 in kscreen (Ubuntu Saucy) "Please update kscreen to 1.0.2.1" [Undecided,New] https://launchpad.net/bugs/1254125
<stgraber> rsalveti: added
<stgraber> rsalveti: note that I got some weird output when generating the device tarball, something about the system.img not being in the right format
<rsalveti> stgraber: oh, right, I don't think they are the same format indeed
<rsalveti> might need some other changes then
<stgraber> rsalveti: right, the resulting device.tar.xz contains a 0 byte system.img, so you'll need to fix the format to match :)
<rsalveti> stgraber: right, have a link to the branch that actually does this logic?
<rsalveti> but I guess I need to change the android side of it
<stgraber> yeah, it'd be easy to hack in system-image to have it not call simg2img but I'd rather not special case goldfish in there
<rsalveti> sure
<stgraber> so it'd probably be best if you could do a img2simg on the .img as part of the build
<rsalveti> stgraber: so you basically just convert to the proper img format and use that instead, right?
<stgraber> right, what I do is simg2img and resize2fs to shrink it down to the minimum non-sparsed size
<rsalveti> right, cool
<stgraber> I guess if there was an easy way to detect simg vs standard img, I could have the code skip that part of the code
<rsalveti> right
<xnox> stgraber: rsalveti: i can turn off sparse images for all of our builds of system.img in the android package.
<xnox> (it's a board make variable)
<rsalveti> xnox: sure, just not sure yet if this is kind of what we want
<rsalveti> as we still want the fastboot-compatible images to be at cdimage
<stgraber> xnox: that'd make 2GB large raw images by default, not sure we want that :)
<stgraber> and indeed, be problematic for those using them with fastboot
<xnox> rsalveti: i think we do. Both are fastboot compatible, and we want to be able to mount the system image. If it for some reason increases in size, we just need to make sure we don't "overspecify" large system.img.
<xnox> but we actually don't use 2GB of it, hm. horum.
<rsalveti> we would need to drop to a common size
<rsalveti> which might also give us problems
<xnox> rsalveti: alternative is to enable sparse system.img for goldfish, which will make current scripts not work (basically a call to sim2img would be needed)
<rsalveti> never flashed a raw image with fastboot either
<rsalveti> xnox: yup, that's what I'm currently checking
<xnox> to be honest, i think i did disable sparse images for goldfish cause "it's all local, i'm porting it and want to mount it"
 * xnox is on the laptop, testing installer on my server machine so can't look it up easily at the moment.
<rsalveti> not so sure, I don't think aosp creates sparse image by default for it
<ogra_> wasnt the final target to have an mmc like image with partition table etc
<ogra_> for the emulator
<rsalveti> but anyway, I'm checking if creating a sparse image for it is desirable
<rsalveti> ogra_: later on, maybe
<ogra_> so that it behaves identical to a real install
<xnox> ogra_: i posted patches to boot of GPT partitioned mmc card =) but i'm yet to see responses to that.
<xnox> ogra_: initramfs-ubuntu-touch patch is fairly generic, and other patch, is just tweaks to the build-emulator-sdcard.sh script to format it gpt.
<ogra_> well, i think it should be our final target to get as close as possible to real HW
<ogra_> especially for testing OTA upgrades etc
<rsalveti> ogra_: right, I think we just need to discuss what would be our partitioning scheme
<xnox> well, it still doesn't boot off the sdcard (but rather kernel/initramfs from command line)
<ogra_> xnox, thats the next step then :)
<rsalveti> but that's mostly because we don't have a bootloader
<xnox> but i'm not keen on diving into qemu code to find/fix where/how it loads kernel off command line, instead of raw offset from the sdcard.
<ogra_> right
<xnox> yeah, no bootloader, so we could hack/hardcode qemu to read the raw kernels/initramfs from sdcard offset...... potentially.
<xnox> i guess i should create the 3*8MB big bootloader partition as the first one. the rest can be flexible.
#ubuntu-release 2013-12-03
<shadeslayer> hi, I was wondering, libkdcraw, marble and kdegraphics-thumbnailers are all valid candidates for moving, yet they haven't migrated over the last 3 days from -proposed
<shadeslayer> any clue why?
<cjwatson> "valid candidate" is only the first stage.  you have to look at update_output for the second
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<shadeslayer> ah
<cjwatson> in this case: libkdcraw/kdegraphics-thumbnailers leaves calligra, digikam, digikam-dbg, kipi-plugins, kphotoalbum, krita, kubuntu-full, showfoto uninstallable
<cjwatson> marble/kdeplasma-addons leaves calligra-reports-map-element, digikam, digikam-dbg, kexi-map-form-widget, libkgeomap-dev, libkgeomap1, showfoto uninstallable
<cjwatson> unhandled soname changes?
<cjwatson> libkdcraw22 -> libkdcraw23 and libmarblewidget16 -> libmarblewidget17, so looks like it
<cjwatson> calligra's still building
<cjwatson> at least digikam definitely needs a rebuild
<cjwatson> and kphotoalbum
<shadeslayer> I see
<shadeslayer> makes sense
 * shadeslayer can finally sort of understand update_output.txt \o/
<shadeslayer> cjwatson: question , what does 85 and 125 mean in : skipped: libkdcraw (85 <- 125)
<cjwatson> they're done/remaining counters in the list of packages currently being iterated over
<shadeslayer> ah okay
<cjwatson> but anyway, you don't want that bit - for packages involved in a transition, look for the first match following the "SUCCESS" line (which indicates the end of attempts to migrate sources one at a time, and the start of attempts to migrate groups)
<seb128> I wonder if there are extra infos that could be put inline in that file to make easier to read/understand it
<cjwatson> I'd rather put a frontend on it the way packages.qa.debian.org does
<shadeslayer> ^^
<cjwatson> http://release.debian.org/migration/testing.pl etc.
 * seb128 basically does "look at the bottom of the page, for the source you are interested in, and try to install the packages listed on the arch lists"
<cjwatson> and if we avoid mucking about with the format of the raw file, it will make it easier to put that kind of frontend on top
<cjwatson> which is why I'm reluctant to touch it much
<seb128> yeah, I'm not sure what makes it difficult to read/what would improve though :/
<shadeslayer> seb128: well, it's just that you need to know how to read it :)
<shadeslayer> if you look at it without knowing how to read it, then it doesn't make much sense
<seb128> well, I sort of know how to find the info I want/need usually, but sometime I still manage to get it wrong
<seb128> e.g when we had several transitions involved recently (e-d-s samba openchange) I managed to get really confused until Laney helped me
<xnox> yeah, when there are multiple transitions, it seems to try all possible intersections of those, which means one needs to read the "middle one" where all transitions are tried together.
<cjwatson> xnox: IME the most complete one is usually at the top
<cjwatson> well, below the initial block ending in "SUCCESS"
<shadeslayer> cjwatson: does valgrind need fixing wrt arm64?
<shadeslayer> doesn't seem to be built for arm64
<cjwatson> Don't know, you'll need to give me some context
<shadeslayer> https://launchpad.net/ubuntu/+source/valgrind/1:3.8.1-5ubuntu1
<cjwatson> Oh, presumably it needs to be ported
<shadeslayer> ^^ no arm64 causes https://launchpad.net/ubuntu/+source/digikam/4:3.5.0-0ubuntu3/+build/5296982
<cjwatson> digikam should only try to use valgrind on arches where it's available
<shadeslayer> ack
<cjwatson> it's never been "works on every architecture" kind of software
<cjwatson> compare https://bugs.launchpad.net/linaro-aarch64/+bug/1236748
<ubot2> Launchpad bug 1236748 in Linaro AArch64 cross-distro work "valgrind needs Aarch64 port" [Undecided,Triaged]
<cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=926688 suggests "several months of work"
<ubot2> bugzilla.redhat.com bug 926688 in valgrind "valgrind: Does not support aarch64 in f19 and rawhide" [Unspecified,Closed: cantfix]
<shadeslayer> yeah, 95K lines of ARM specific code
 * shadeslayer adds !arm64 to Build-Depends
<cjwatson> Probably the wrong answer
<shadeslayer> hm?
<cjwatson> valgrind has "Architecture: amd64 armel armhf i386 mips mipsel powerpc ppc64 s390x x32" - better to match that than to invent an inaccurate negative version
<cjwatson> that'd just need to be updated for the next port
<shadeslayer> *nod*
<cjwatson> could somebody in ~ubuntu-sru please review partman-basicfilesystems/precise?  apw eyeballed it a few days ago
<stgraber> cjwatson: doing so now
<ara> hello! could anyone in ~ubuntu-sru review https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=gnome-control-center, please?
<shadeslayer> likewise for kscreen as well ^^ , it has a MRE
<cjwatson> thanks.  I'd nag about grub2/precise as well but I'm currently waiting for upstream to reappear on IRC so I can jump on him about whether the latest iteration of the hotkey patch is ok
<cjwatson> I'll take gnome-control-center
<ara> cjwatson, thanks
<cjwatson> shadeslayer: saucy, presumably - libkscreen too?
<cjwatson> ara: done
<shadeslayer> cjwatson: yep
<ara> cjwatson, thanks!
<cjwatson> stgraber: thanks
<shadeslayer> cjwatson: thx
<cjwatson> xnox: could you do another ubiquity/precise upload with the new partman-basicfilesystems in precise-proposed?
<cjwatson> should be less busted now
<xnox> cjwatson: ack.
#ubuntu-release 2013-12-04
<tseliot> hi, can an admin tell me if nvidia-prime in precise and in saucy is really in main, please? Launchpad says so but I thought it was only in main in Trusty: https://launchpad.net/ubuntu/+source/nvidia-prime
<Laney> it's true
<tseliot> Laney: is there a way to find out how/when/why that happened?
<tseliot> cjwatson, pitti ^
<cjwatson> look at the publishing history
<cjwatson> that tells you when, not why
<cjwatson> we have no auditing that records why
<cjwatson> try IRC logs around 2013-08-12, by the looks of things
<tseliot> cjwatson: ok, so I filed the MIR for Saucy (not Trusty, my bad) but this still doesn't explain what happened in Precise
<tseliot> cjwatson: not that I'm complaining, I only need to know whether to put bbswitch in main or universe in precise, since the next nvidia-prime will depend on it
<cjwatson> I dunno, I expect it was to do with a point release around that time
<cjwatson> You surely don't need to worry about which component it goes in, given that that's an archive admin decision anyway
<tseliot> cjwatson: ok, thanks
<bdmurray_> cjwatson, stgraber: could one of you have a look at my phased-updater merge proposal?  https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/skip-not-phasing-packages/+merge/197626
<cjwatson> looking
<cjwatson> lgtm, merged, thanks
<stgraber> ah, cjwatson was faster, I just posted an approve to that MP
<bdmurray_> heh, thanks!
<melodie> hi
<cjwatson> my sincere apologies to whomever has to review grub2/precise, but it's all urgent customer stuff :-/
<infinity> cjwatson: Why the two version bumps?
<infinity> Allergic to moving tags, I guess? :)
<xnox> infinity: easier interdiff for SRU team, cause they can fetch both 11->12 & 11->13.
<infinity> I could have just fetched the two versions of 12 and diffed them, but sure. :P
<xnox> =))))))))
 * xnox gets crosseyed when i see bzr conflict for same version debian changelog stanza.
<infinity> cjwatson: What level of testing has gone into this?
<xnox> (it's like top line matches, then "\n" context everything conflicting (or only some entries), "\n" context, and conflicting trailer line. Wost diff ever, it should totally make the whole entry conflict =)
<cjwatson> infinity: just felt clearer in my head
<cjwatson> infinity: I tested the timeout/hotkey stuff in a precise VM and caught the bug mentioned in the second changelog *-entry there :-)
<cjwatson> infinity: I confirmed that various hidden vs. not timeout cases worked, and that the hotkey-immediate-boot feature now works
<infinity> cjwatson: Excellent.  All of this sounds like you probably booted some computers a few times too.
<cjwatson> haven't done EFI testing or tested the GRUB_RECOVERY_TITLE stuff
<cjwatson> yeah, I've done some BIOS boots
<infinity> cjwatson: And fresh deb->deb upgrades with built packages, not custom hackery of local builds and mangles conffiles to simulate the final package? :P
<infinity> s/mangles/mangled/
<cjwatson> I might have deleted one line from /etc/grub.d/10_linux rather than rebuilding the whole thing for the aforementioned bug
<cjwatson> but other than that ...
<cjwatson> *cough*
<infinity> I'll poke the code for obvious scariness jumping out, but this sort of change needs more "yeah, I did a bunch of pre-upload testing" more than it needs code review, hence my pedantry.
<cjwatson> that was http://paste.ubuntu.com/6520979/
<cjwatson> the timeout_style stuff has run the gauntlet fairly extensively upstream, although the backport and interaction with other patches was distinctly non-trivial
<cjwatson> infinity: any further comments from the grub2 review?
<infinity> cjwatson: I got distracted with other work, but it's on my TODO for this afternoovening.
<infinity> Well, other work and lunch.
<infinity> Mmm, lunch.
#ubuntu-release 2013-12-05
<seb128> I'm removing harfbuzz from trusty-proposed, just as fyi
<seb128> we got an autosync from Debian today which changes the soname, but we are not ready for that migration
<seb128> (it's a small one but includes libreoffice which doesn't build on trusty atm)
<cjwatson> mkay
<seb128> cjwatson, I was commenting there in case somebody has a strong objection
<seb128> basically libreoffice 4.2rc1 is scheduled for mid-decembre and that's we want to upload to trusty (the alpha versions are being tested in a ppa and build)
<seb128> we don't want to start debugging 4.1 build issues before that because that would be a waste of efforts
<seb128> we could let stuff in proposed during that time, but that includes a new webkitgtk building on arm64 and we want that in trusty
<seb128> cjwatson, ^ seems reasonable to you?
<cjwatson> sure
<seb128> thanks
<cjwatson> slangasek,infinity: I believe those are really finally honestly now the grub2/grub-installer versions I'd like to go into 12.04.4
#ubuntu-release 2013-12-06
<tjaalton> hey, nvidia-graphics-drivers-legacy-304xx should be removed from trusty
<tjaalton> since we have our own nvidia packaging, and installing this could break things
<tjaalton> hmm I'll just file a bug
<infinity> tjaalton: Bug number?
<tjaalton> infinity: lp1258394
<infinity> tjaalton: Ahh, found it.
<tjaalton> cool
<infinity> (didn't realise that was literally the source package name, I thought you meant 304*)
<tjaalton> yeah, probably why it got in trusty
<infinity> Well, it's new.
<infinity> And we don't blacklist with a wildcard.
<infinity> Not sure if auto-sync is smart enough to deal with wildcards. :P
<infinity> Anyhow, I'll add it to the blacklist.
<infinity> Once I remember where it lives.
<tjaalton> great, thanks
<infinity> lp:~ubuntu-archive/+junk/sync-blacklist looks plausibly canonical, despite the hilarious path.
<infinity> Oh, and I already have that checked out.  A good sign.
<tjaalton> sweet
<infinity> Waaait.  That had an ubuntu version on it?
<infinity> It was synced and then reuploaded for an ftbfs or something? :P
<infinity> Oh well.
<infinity> All removed now.
<tjaalton> yeah
<tjaalton> that's how I noticed it, by reading trusty-changes
<infinity> Heh.
<cjwatson_> infinity: It wouldn't be that hard to add wildcard support to auto-sync if you wanted, though you'd probably have to add it to syncpackage too.
<cjwatson> infinity: Any further thoughts on grub2/precise?
<infinity> cjwatson: Doesn't really matter for Ubuntu of course, but why doesn't 10_hurd.in use gettext like the others?
<cjwatson> infinity: It does in 2.00, but was apparently omitted in 1.99
<cjwatson> I assume somebody was careless
<cjwatson> But didn't bother to import more general fixups for code we don't care about :-)
<cjwatson> (Completism, except when it's annoying)
<infinity> cjwatson: Ahh, kay.  So, the only other thing I'd question is if you caught all the possible error paths for the udevadm madness.
<cjwatson> Go on ...
<infinity> cjwatson: Will this properly not do something stupid if udev isn't running, if udevadm doesn't exist, etc.
<infinity> It looks like you catch some things, I just have no idea if it's all the things. :)
<cjwatson> Well, I'm assuming that udevadm will only write a line to stdout if it actually worked
<cjwatson> If it doesn't do that, then sysfs_partition_path is going to return NULL one way or another
<cjwatson> (Worst case I think it produces some junk on stderr, which I'm happy to ignore)
<infinity> cjwatson: It certainly seems to DTRT if the dev doesn't exist.  Let me stop udevd and see if my laptop explodes...
<cjwatson> And sysfs_partition_path NULL -> sysfs_partition_start 0 -> fallback to HDIO_GETGEO
<cjwatson> You might be better off with a container there :-)
<infinity> Nah, I live on the wild side.
<infinity> That seems to do what you expect too.  Good enough for me.
<infinity> cjwatson: Want to follow that up with a -signed with a strict build-dep, so we don't forget and do it two weeks later? :P
<cjwatson> infinity: ayup
<cjwatson> infinity: Mind if it doesn't come with bug closures?
<infinity> cjwatson: I think at least one of these bugs has a grub2-signed task.
<cjwatson> Ah, let me check then
<infinity> But I don't much care, if you prefer to ignore and invalidate the tasks and have the rebuild upload not have a bug.
<cjwatson> Yeah, OK, I'll add them
<infinity> linux-signed certainly never references bugs.
<cjwatson> just the mega bug 1065281 by the looks of things
<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
<cjwatson> infinity: ok, uploaded.  maybe ara won't hunt me down now ...
<infinity> cjwatson: Personally, I don't see much point in -signed and -meta and other such packages having bug refs unless the bug is actually a bug in THAT package, rather than the one that it depends/builds on/with.
<infinity> But, YMMV.
<cjwatson> me neither, but I don't want to edit that bug's metadata more than I have to :-)
<infinity> Heh.
<cjwatson> I'd actually like to teach sru-report about the linkage or something ...
<infinity> cjwatson: Teaching sru-report about connections seems wrong.  Surely, the right answer is britneyfying stables.
<infinity> cjwatson: Then we enforce what we need to with blocking bugs and/or strict deps.
<infinity> And sru-review is lying scum...
<infinity> (base)adconrad@cthulhu:~$ PAGER=view sru-review -s precise grub2-signed
<infinity> ERROR: queue does not have a debdiff
<infinity> I'M STARING AT IT IN THE WEB UI.
<cjwatson> infinity: mm, could do ...
<cjwatson> infinity: sru-review> caching by any chance?
<infinity> Ahh, possibly.  It finally caught up with reality anyway.
<infinity> cjwatson: Does grub2-signed still do that wonky thing where, despite a build-dep on a binary package, it then just takes the latest efi blob from ftpmaster without version checking?
<cjwatson> infinity: Yes - but that will always be new enough, right?
<cjwatson> (It should arguably pick the version out of the apt cache, yes.)
<infinity> cjwatson: If you never build grub in a PPA (or, rather, never binary copy it), I think it probably still gets what you want.
<infinity> I like linux-signed approach to versioning and version-checking a bit better.
<infinity> (The binary copy thing is great, cause you'll get the .deb published, but the EFI bits in unapproved until someone notices, so your build-dep would be satisfied, but you'll get the old EFI bits)
<infinity> Just one more way copies are hilariously goofy.
<cjwatson> I think linux-signed was originally derived from my code, but it looks like they've spruced it up a fair bit.
<cjwatson> And yeah, it's grabbing a specific version rather than using current, which is what I was vaguely suggesting above.
<cjwatson> Might fix that in the next grub2-signed/trusty upload if I remember.
<infinity> Which reminds me, there's a bug in linux-signed where it can't work in private PPAs.
<infinity> Which is a moot point unless we also allow the security PPA to build with the archive signing key (which we won't), but it's still annoying for staging/testing.
<infinity> I kept meaning to fix that after the last fiasco involving such.
<barry> hi.  can this migration be easily retried? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-system-image/
<cjwatson> fwiw it's not the migration that needs to be retried, it's the autopkgtest (terminology)
<cjwatson> barry: is there a reason to suppose the autopkgtest will succeed this time?  it has never passed on trusty
<barry> cjwatson: these are not real test failures or as previous, incorrect autopkgtest deps.  these are just the intermittent test suite timeouts rearing their ugly head again.  yes, we need to try to figure that out (and it's a top priority for the sprint, since i think its udm related), but a retry locally often "fixes" the problem.  tl;dr we might get lucky on a retry
<cjwatson> barry: well.  I'm a little bit sceptical that you might be losing races that many times and succeed on a retry - but I've asked it to rebuild, we'll see how it does
<xnox> barry: do note, the tests are running inside a VM and therefore a monolithic_raw clock is not available, and some syscalls "round up" to precision values which in this case is infinity (max allowed size of the variable type used)
<xnox> barry: therefore e.g. for autopkgtest in upstart some timing tests are skipped.
<xnox> barry: buildds have proper hardware clock, so those timing tests are executed then. So i'd suggest disabling / or marking those tests may fail if monolithic clock is not available.
<barry> cjwatson, xnox: so, basically what is happening here is that si is telling udm to download a bunch of files (over localhost), and then waits for the appropriate dbus signals.  yes, there's a timeout, but it's cranked up to 20 minutes during the test suite.  however, for reasons none of us have ever been able to figure out, sometimes udm just stops sending its signals, so the dbus reactor will eventually timeout saying it never saw a
<barry> 'finished' signal.  it happens occasionally locally but is very difficult to reproduce or debug.  a retry seems to fix it (oh, and it will almost never timeout when running in-tree tox, but it can when sbuilding in a chroot).  thing is, the *exact* same test suite is run in the build and the dep8 tests so, yeah
<barry> one of the things i hope to address at the sprint is debugging and integration tests to figure out why udm just stops responding
<ogra_> stgraber, so we had an ubuntu-touch build ... and there will be one later tonight, do you need to watch it live when it happens for the isotracker stuff ? (i can ping you when starting the build)
<stgraber> ogra_: no, everything I need will either be right on the tracker or if it fails, in the logs
<ogra_> ok
<stgraber> ogra_: looks like 20131206 posted fine on the tracker
<ogra_> ah, yeah, i see something there
<stgraber> ogra_: can you login on http://iso.qa.ubuntu.com (if already logged in, logout and login again)?
<stgraber> ogra_: you should see ubuntu-touch-release on the SSO page and then have access to the touch products
<stgraber> ogra_: if that works, you should then be able to go to http://iso.qa.ubuntu.com/qatracker/milestones/308/builds, tick the touch product and then access the rebuild controls at the bottom of the page
<ogra_> yeah, i see a "Request a rebuild" pulldown
<stgraber> ogra_: would be nice if you could trigger the next build that way so we can check that the tracker -> nusakan link works for touch
<ogra_> will do
<ogra_> is everyone from the CI team in ubuntu-touch-release ?
<ogra_> (if not, can we add them)
<stgraber> I believe you need to be a coredev to be on ubuntu-touch-release
<cjwatson> right, because it also controls access to the britney hints branch
<cjwatson> but I think it makes sense for it to be the same team
<ogra_> hmm, we need to have the CI guys able to trigger builds
<stgraber> ogra_: nusakan checks for rebuild requests every 5 minutes, so it can take a little while until the build actually starts
<ogra_> could we use another team for this perhaps ?
<cjwatson> every single one?  does it really matter that much?
<stgraber> ogra_: I can easily grant the same tracker access to another team
<cjwatson> it's only been you so far and while it hasn't been ideal it hasn't been *that* huge a problem
<ogra_> cjwatson, well, two in each TZ i'd say
<cjwatson> I don't get why it's suddenly a critical requirement
<ogra_> not each of them
<ogra_> cjwatson, because i'm not allowed to switch on cron for european and US daytimes and they need to be able to have ad-hoc builds then
<cjwatson> it'll have to be a different team then
<ogra_> (i'll have to burn vacation days from monday on)
<ogra_> didrocks, ^^^ whats the team we need to have access to trigger builds
<ogra_> (i dont need to be in it, i can do it from cmdline on the main server)
<cjwatson> better if you are in it though
<ogra_> k
<didrocks> ogra_: hum, not sure to follow what you are asking it as it seems to be image build, not cu2d?
<cjwatson> didrocks: image build, yes
<ogra_> didrocks, right
<cjwatson> didrocks: (please see the last screen or two of scrollback)
 * didrocks reads
<didrocks> ubuntu-touch-release would make sense to me
<ogra_> didrocks, but not all CI people are core-dev
<ogra_> i thought the person doing the final landing before an image shoujld also be able to trigger the build
<didrocks> ogra_: in theory yeah, but for now, I would say we don't need everyone to be able to kick a build, we have enough coverage with the current ones on all timezones
<ogra_> so i woulld think it makes sense to have the complete CI team allowed
<didrocks> otherwise, it's ~ubuntu-unity
<cjwatson> note that ~ubuntu-release can always do it too - I seriously doubt you'll have timezone coverage problems in reality
<didrocks> agreed
<ogra_> k
<ogra_> so lets keep ubuntu-touch-release for now then
<stgraber> ogra_: the command the tracker will trigger is "ARCHES=armhf DIST=trusty for-project ubuntu-touch cron.daily-preinstalled --live" (just did a dry-run rebuild to check), comparing to the crontab, that looks right
<ogra_> stgraber, yeah ... ARCHES shouldnt be needed though, but wont hurt
<stgraber> ogra_: yeah, the tracker always sets ARCHES based on the arches, that was easier than having to parse the default arches list :)
<ogra_> well, we will add x86 tarball builds in the not so far future, then it will need to be extended
<cjwatson> ogra_: that would be an extra image type which you'd also select on the tracker, then - no big deal
<ogra_> ah, k
<cjwatson> or rather same image type, another architecture.  another row on the tracker anyway
<ogra_> yup, i see
<stgraber> ogra_: oh, one last thing, we have a rate limit in place for all tracker requested builds set at 2 builds per user per day. That limit however doesn't apply to members of ~ubuntu-release. If that actually becomes a problem for ubuntu-touch, we can probably raise it to 3 or 4 (as so far we haven't seen anyone abusing their powers).
<ogra_> heh, they will rather do to less than to many
 * ogra_ is the one pushing for more ... they would likely be fine with two/day in total
<Laney> birch went to disabled
<Laney> could somebody please do the needful?
<bdmurray> slangasek: if you get a chance https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/jsondecodeerror/+merge/198120
<doko> infinity, cjwatson, jibel: I need python3-defaults in trusty. could somebody please unblock that? the autopkg tests hardly rely on this, maybe only when we change the default version to 3.4
<infinity> doko: Have you looked into why those tests fail?
<infinity> The dh-python one looks to be legitimately failing, though maybe the test itself is wrong...
<doko> did never pass
<infinity> Indeed, and neither have the other two.  I can wave it through.  We should still fix those tests, though.
<doko> python-csb did never pass
<doko> jibel, ^^^
<infinity> doko: Tests for those source/version tuples skipped.
<barry> i'm seriously considering disabling the autopkgtests for system-image.  it just seems the jenkins runs are too flaky to be of any use beyond blocking proposed migration.  note that it's the exactly same test suite that i run locally in tree via tox *and* in the package build d/rules.  it only seems to be inside adt that we get lots of timeout errors, connections reset by peers, etc.  something about that environment is causing
<barry> unreliable dbus/socket problems it seems.
<slangasek> bdmurray: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/jsondecodeerror/+merge/198120> why is the json decoding failing?  Should this actually be handled via the http status, the way we already handle 502?
<bdmurray> slangasek: I don't know as I don't have the data returned from errors
<slangasek> ah; is this happening when called on errors itself?
<bdmurray> slangasek: I found some cronjob email from snakefruit today with the traceback in the mp
<bdmurray> I'll run the phased-updater some here and see if I can recreate the crash
<slangasek> bdmurray: I would say we should check for any rate_file.getcode() >= 400, and then see if the jsondecode change is still needed at all
<bdmurray> slangasek: ah, that makes sense
<bdmurray> slangasek: updated
<slangasek> bdmurray: merged, thanks
#ubuntu-release 2013-12-07
<doko_> infinity, cjwatson, jibel: please help python2.7 into trusty. the failing ntdb package is new, and the test wrong :-/
<jibel> doko_, results forced.
<doko_> thanks, filed an issue in debian
<knome> anybody who can approve blueprints for trusty around? i don't want to flood the channel with details (again), so please ping me
<xnox> knome: send an email to ubuntu-release mailing list, and appropriate people with powers will do that.
<knome> xnox, cheers, will do that
<xnox> infinity: please demote udisks src+bins to universe
<knome> xnox, mail sent. :)
#ubuntu-release 2013-12-08
<infinity> xnox: iz done.
<xnox> infinity: thanks.
<xnox> where is the tech-board when one needs it.
<xnox> i guess that's not that easy to achieve =)
#ubuntu-release 2014-12-01
<GunnarHj> Can somebody in the SRU team please approve ubuntu-docs in https://launchpad.net/ubuntu/utopic/+queue?queue_state=1 ? An update of the Utopic language packs will take place in a few days, and the package must have been built before then.
<GunnarHj> infinity: Hi Adam! ^ ?
<bzoltan> chrisccoulson: ping
<bzoltan> wrong channel
<mlankhorst> could wine-development be removed from the archive? seems to be synced from debian
<ogra_> infinity, apw, is anyone on top of the linux-signed uninstallability during image builds ?
<ogra_> seems iso builds fail since a while due to that
<ogra_> The following packages have unmet dependencies:
<ogra_>  linux-signed-generic : Depends: linux-signed-image-generic (= 3.13.0.41.48) but it is not going to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> P: Begin unmounting filesystems...
<apw> ogra_, not heard anything about that, got a pointer to something which shows it ?
<apw> ogra_, this is in trusty i assume?  with or without -proposed ?
<ogra_> oh, yeah, trusty
<ogra_> started failing on friday
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu
<ogra_> also only amd64 as it seems
<apw> ogra_, linux-signed was stuck in new around that time, but .. it seems to be MIA right now
<ogra_> lol
<apw> ok if i am reading this right, there is no builds for it any more
<ogra_> was it the US edition ? it perhaps simply didnt return from eating turkey yet
<apw> heh ... seems it failed to build, because the bits it relies on didn't make it to dists, which aiui should be impossible
<apw> ogra_, i'll ask it to try that again ... lets see if it is sticky
<apw> ogra_, ok it is now .... ^^ ... stuck in new
<apw> ogra_, somehow the dists had not mirrored out to ftpmaster.internal when the job ran, which i find supprising
<ogra_> yeah, a bit weird
<rbasak> Can someone from the SRU team please review bug 1396210?
<ubot2> bug 1396210 in mysql-5.6 (Ubuntu) "Backporting the mysql_no_login plugin to 5.6" [Undecided,New] https://launchpad.net/bugs/1396210
<rbasak> infinity: it's your day today I think?
<infinity> rbasak: It is, but I'm heading back to sick and febrile land.
<skellat> infinity: But you've seen The Face! :-)
<rbasak> infinity: what, and miss my DMB meeting? :-)
<rbasak> infinity: anyway, no worries.
<ScottK> infinity: Isn't sick and febrile perfect for SRU reviews?
 * knome notes that down for the next time ScottK is sick and febrile :)
 * ScottK rejects even more then, so it may not help.
 * ScottK can rationalize hallucinating reject reasons.
<knome> hey, at least it clears the queue!
<GunnarHj> infinity: ping?
<ScottK> GunnarHj: infinity is not well today.
<GunnarHj> ScottK: Aha, thanks for letting me know. Are you possibly in the SRU team?
<ScottK> I am, but lacking time to deal with it ATM.
<GunnarHj> ScottK: Ok. Anybody else? It's about a pure translation update in the utopic-proposed queue.
<ScottK> Not sure.
<GunnarHj> ScottK: Ok, I'll try tomorrow then - if not somebody sees this and offers a helping hand. ;)
#ubuntu-release 2014-12-02
<GunnarHj> arges, RAOF: I would need help by somebody in the SRU team to approve ubuntu-docs in https://launchpad.net/ubuntu/utopic/+queue?queue_state=1
<GunnarHj> It's a pure translation update. An update of the Utopic language packs will take place in a few days, and the package must have been built before then.
<arges> GunnarHj: i'll take a look
<GunnarHj> arges: Thanks. :)
<tumbleweed> ^ previous SRU (#1368418) FTBFS on ppc in -proposed. This fixes it.
<infinity> tumbleweed: So, basically, that's -fPIC on everything but i386?
<infinity> tumbleweed: Can you reupload with a -v including the previous version?
<tumbleweed> infinity: can do
<tumbleweed> infinity: https://bitbucket.org/pypy/pypy/src/8471ffc38d46b9fa1da64943e9d077631502d9bc/rpython/translator/platform/__init__.py?at=default#cl-252 - that's the current logic
<infinity> tumbleweed: I got that from the diff context, yeah.
<infinity> tumbleweed: And (at least in Ubuntu), the only arch that doesn't match that is i386.
<infinity> tumbleweed: Which could also build with -fPIC.
<tumbleweed> right
<infinity> tumbleweed: So, the whole thing is a bit curious. :)
<tumbleweed> the pypy people love to squeeze every bit of performance they can, out
<infinity> tumbleweed: Anyhow, food for thought, not something to change in an SRU if you're sure the current method works.
<tumbleweed> yeah, it works
<infinity> tumbleweed: Ahh, they're intentionally doing it because they know i386 addressing is gimpy enough to get away with it?
<tumbleweed> yes
<infinity> tumbleweed: Fair enough.
#ubuntu-release 2014-12-03
<wgrant> Publisher disabled for surgery, hopefully have it back up within an hour.
 * ScottK wonders how the surgery went.
<infinity> ScottK: The patient survived.
<infinity> cjwatson: Can you review the d-i in the trusty queue (well, maybe "review", the changeset is a bit large to audit line-by-line) for me?  I've test-built it in my PPA on all arches, and test-installed vanilla and lts-utopic flavours on amd64, powerpc64, and ppc64el
<cjwatson> infinity: Looks pretty plausible to me.  No armhf/keystone?
<infinity> cjwatson: There's no utopic keystone kernel.
<cjwatson> Good a reason as any.
<infinity> Ta.
#ubuntu-release 2014-12-04
<Riddell> what would it take to make a kubuntu phone image using the same base as ubuntu touch but different UI? is it just like another flavour of ubuntu or is there anything more?
<cjwatson> Probably better ask on #ubuntu-touch
<cjwatson> Riddell: When you removed kde-workspace, you made cantata uninstallable in vivid (since it Depends: kde-style-oxygen).  Please could you fix it up?
<cjwatson> Riddell: And I suspect possibly some other packages too; might be worth a quick grep
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/vivid_uninst.txt has some suspicious-looking entries
<Riddell> cjwatson: I'm working on kde applications which replaces kde sc and should fix up all that http://qa.kubuntu.co.uk/ninjas-status/build_status_14.11.97_vivid.html
<cjwatson> OK
#ubuntu-release 2014-12-06
<xnox> Please reject^ https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=partclone it was meant for vivid
<cjwatson> xnox: done
<cjwatson> xnox: your adns sync regresses ppc64el
<cjwatson> though not for the obvious reason
<xnox> cjwatson: yeah, not obvious and it builds correctly on debian's ppc64el. So apart from uploading -O2 build there is not much that I can do.
<xnox> debian's pcc64el porter boxes do not usually have ubuntu chroots...
<xnox> it also appears that sftp uploads are not getting processed and/or taking longer. I seem to be re-uploading things via ftp and that gets accepted instantly.
#ubuntu-release 2015-11-30
<rbasak> Can an AA please review monitoring-plugins languishing in Xenial NEW? It's a merge of a Debian source package rename.
<xnox> lxd 0.23-0ubuntu2 fails to start on i386 in the adt test. Can that be investigated at all? e.g. get the systemd journal out of there?
<xnox> (similar transient failure was in the previous upload too)
<infinity> xnox: Did you mean xenial? ^
<xnox> yes
<Laney> xnox: the instances are transient - you could make the test save artifacts in $ADT_ARTIFACTS
<xnox> Laney, it fails on adt deps installation..... before the test even run
<Trevinho> SRU team, can we please get a quick review of https://requests.ci-train.ubuntu.com/#/ticket/685 ? It's waiting for long time, and it's blocking other changes...
<yofel> what's a good way to find out why a souce is not part of a packageset even though it's listed in the supported seed?
<yofel> *source
<yofel> (polkit-kde-agent-1 and kwayland-integration from kubuntu xenial in this case)
<yofel> hm, kwayland-integration is edubuntu and motu, polkit-kde-agent-1 is motu-only o.O
<stgraber> so I have a few friends poking me because of a busted kernel that just hit the security pocket:
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1514785
<stgraber> basically anyone who uses policy based routing or vaguely advanced routing in their firewall script now seem to be stuck in an infinite loop when calling iproute
<stgraber> seems rather bad
<stgraber> apw, ogasawara: ^
<ogasawara> bjf: ^^
<stgraber> an earlier report was dupped which I suspect confused the bots and made it disappear from reports...
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516052
<wxl> bots aren't here
<bjf> ogasawara, stgraber looking
<bjf> stgraber, if someone can test kernels we'll get it bisected and a fix out asap
<stgraber> bjf: sdeziel can help there, I can have him join #ubuntu-kernel if that helps
<bjf> stgraber, thanks
#ubuntu-release 2015-12-01
<xnox> please remove qtsvg-opensource-src 5.5.1-2 from xenial-proposed, as all of 5.5 landing is being prepared by Mirv in a silo, and this 5.5 qtsvg component that got auto-synced is in the way for bootstrap =)
<xnox> "got auto-synced _and_ is in the"
<Mirv> xnox: no need really
<Mirv> xnox: I've all of them built as 'build1' already
<Mirv> and there are 10+ autosynced modules
<darkxst> can someone unleash bug 1237904 from wily-proposed?
<darkxst> it was verification-done about 3 weeks ago
<darkxst> infinity, RAOF ^
<RAOF> darkxst: You are in luck! I now have a laptop with actual access to ubuntu-archive-tools!
<darkxst> RAOF, great! :)
<RAOF> C'mon, deja-dup. You can do it! Find the backup!
<Laney> yofel: I fixed it, in future please debug starting from lp:~developer-membership-board/+junk/packageset
<xnox> Mirv, ok, when will it land? or could you please share the silo ppa URL? /me is having test suite failures in qtbase
<Mirv> xnox: today at current pace. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages
<Mirv> I'm just fixing some KDE arm64 rebuilds
<xnox> cool
<Mirv> xnox: note that qtbase unit tests are some of the most difficult ones to run on our builders (compared to Qt upstream's own test machinery), and we currently run the much modified set of unit tests only on amd64+armhf+i386. I can add s390x to the skipped architectures or you can try to get them working, but please don't upload a new qtbase today.
<Mirv> and obviously upstream doesn't run them at all on many of our archs
<cjwatson> Mirv: have you considered making it a positive list of architectures where they're run rather than a list of skipped architectures?
<cjwatson> the latter approach is usually only suitable when it's particular known properties of the skipped architectures at issue
<Mirv> cjwatson: yes, I thought I had already done that but I just noticed I didn't
<Mirv> it was probably some other package
<Mirv> I'll do that to the next upload
<yofel> Laney: thanks a lot! (for both the fix an the repo :) )
<Mirv> sorry I've invaded the arm64 builders by kicking builds of a lot of KDE packages to get them through to release pocket
<Mirv> Qt 5.5.1 has been published to xenial-proposed. After a few hours there might be something migration related popping up, feel free to fix or I'll look at them tomorrow.
<rtg> Can I get the Xenial 4.3 kernel released from the NEW queue ?
<rbasak> Can an AA please review monitoring-plugins languishing in Xenial NEW? It's a merge of a Debian source package rename.
<xnox> Mirv, interesting, for me it was mostly passing and i was trying to narrow it down to #if !defined(Q_T_S390X) here and there.
<xnox> Mirv, or like chaning things to XFAIL etc.
<xnox> Mirv, most things do pass. I wonder which things are skipped, i assumed we had a 100% pass rate on amd64, I shall compare with other arches now.
<Mirv> xnox: the enable-tests.patch is what maintains the exception. it'd be doable for all archs, but quite a lot of test cases change between Qt versions. that's why it's easier to handle those for the archs I have direct access to.
<xnox> Mirv, cool. i'll check if that's the same things on s390x or not =)
 * Mirv -> sleep
#ubuntu-release 2015-12-02
<rbasak> Can an AA please review monitoring-plugins languishing in Xenial NEW? It's a merge of a Debian source package rename.
<doko> arges, gccgo-go isn't in the archive anymore for wily and xenial
<arges> doko: which bug are you refering to?
<doko> arges, https://bugs.launchpad.net/bugs/1361946
<arges> doko: ah yes! ok I'll mark as invalid
<arges> doko: thanks!
<arges> invalid for gccgo-go/xenial
<cjwatson> publishers and various other bits of Soyuz will be stopped for a bit while we create s390x
<Logan> cjwatson: whaaaaaaat
<Logan> did I miss something?
<cjwatson> perhaps.  it's been mentioned in a few places
<cjwatson> https://www-03.ibm.com/press/us/en/pressrelease/47474.wss
<Pici> bug 100000
<ubot5> bug 100000 in Launchpad itself "There are still too many bug reports" [Undecided,Invalid] https://launchpad.net/bugs/100000
<Pici> okay, good.
<cyphermox> Logan: it's going to be amazing. I'm waiting to receive my own to heat my house... at the cost of blocking off the basement because too much noise.
<arges> cjwatson: do you know when publishing will resume?
<cjwatson> arges: shortly
#ubuntu-release 2015-12-03
<Logan> cyphermox: hah, now I want one
<Logan> so are we building every package on s390x now?
<Logan> well, every "any" package
<xnox> Logan, at the moment nothing is built, as none exist =) but in the future yes. Think of this like ppc64el, arm64 ports, which were brought up in recent times. but really not the good time or place to talk about it, as the shoe strings are being put together to get things going.
<cjwatson> Logan: unless specifically excluded in their Architecture, indeed
<cjwatson> Logan: though as usual, packages that never built won't count against proposed migration
<Logan> nice, sounds awesome
<cjwatson> infinity: might want to teach p-m about s390x
<Logan> looking forward to another cycle of blind porting :P
<slangasek> gonna be pretty boring; this is a mature architecture in Debian
<infinity> Logan: This one won't need much love like the last two, it's an old port.
<Logan> hmm, okay
<cjwatson> no endless autoreconfery for us this time
<cjwatson> also it'll have 28 builders once we get things going, at least for the short term, so shouldn't get in people's way nearly as much :)
<apw> cjwatson, britney is (now) reporting xenial linux-meta and linux as lacking builds on s390x and not starting testing, do i presume that they are stuck there until those builds appear ?  s390x is not a lagging arch?
<apw> cjwatson, and actually, launchpad is not reporting builds as existing for s390x in the web interface, is that correct
<cjwatson> apw: Yeah, I was trying to get somebody to do the britney work last night since I can't
<cjwatson> apw: Launchpad> example URL please?
<cjwatson> 'cos it sure is in some places
<cjwatson> apw: Oh, the kernel, that'll be because your Architecture lines don't include s390x, so that's expected.  Don't worry about the "missing build on s390x" in your case - that's actually just because arch all binaries are out of date, so it'll clear as soon as we process amd64 through NEW
<apw> cjwatson, well our architecture lines do contain s390x for the one in -proposed, but https://launchpad.net/ubuntu/+source/linux/4.3.0-1.10 does not have a missing build for it
<cjwatson> apw: Oh, infinity didn't run add-missing-builds for -proposed, we were going to wait until release was a bit more fleshed out
<cjwatson> infinity: Maybe I was wrong and that isn't worth the confusion
<infinity> cjwatson: Nah, I think you were right. :P
<infinity> cjwatson: I was going to do proposed once main's more or less done.
<apw> cjwatson, ahh then that makes sense then
<cjwatson> Copies into release will still generate builds, so we won't end up in a half state
<infinity> Even if something did get stuck in a half state, I was going to re-run add-missing for all pockets at the end anyway, out of paranoia.
<rbasak> Can an AA please review monitoring-plugins languishing in Xenial NEW? It's a merge of a Debian source package rename.
 * apw notes that britney is reporting wily as in freeze, is that just leftovers from the release ?
 * apw also notes that the title says wily release coordination still
<cjwatson> apw: what URL is that?
* cjwatson changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Wily 15.10 | Archive: open | Xenial Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<apw> http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html
<apw> cjwatson, ^ that one
<cjwatson> apw: note the URL ...
<cjwatson> s,wily/,,
<cjwatson> or s/wily/xenial/
<cjwatson> oh, wait, you actually are intentionally looking at the stable run
<apw> cjwatson, right, looking at the stable runs for adt info etc, presumably not making a differnce, just odd
<cjwatson> apw: sorry, I understand now, I have hit it with a suitable hammer so it should clear in a bit
<apw> cjwatson, ack thanks
<cjwatson> (removed the old hints branch - it'll rebranch on the next run)
<apw> could someone review the linux-signed in new, so we can see if testing kicks off ok with s390x in the mix
<apw> (in xenial-proposed)
<cjwatson> looks like it was just accepted
<cjwatson> oh that
<apw> ta
<bdmurray> slangasek: Could you review my python-apt SRUs for T and W?
<slangasek> bdmurray: sure, looking
<bdmurray> slangasek: There's a wily one too.
<slangasek> bdmurray: yep, got interrupted - doing it now :)
<bdmurray> slangasek: okay
<slangasek> done
<cjwatson> right, we have a slightly more respectable number of s390x builders now, though still only about a third of the end total
<tkamppeter> Hi, why is cups-filters 1.2.0-1 stuck in xenial-proposed for 2 days now? It has successfully built on all plat forms.
<xnox> it built \o/ slangasek ^ can you please de-new it =)
<slangasek> xnox: someone may have beat me to it?
<xnox> newing libc6-s390 looks good, not sure about the .ddebs... i thought they don't go into launchpad.
<xnox> slangasek, https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text=glibc
<xnox> it's in release pocket.
<slangasek> ah yes
<xnox> because funny arches =)
 * xnox goes back to evening tea and waiting for firefox to build
<xnox> slangasek, is it normal for -*dbgsym*.ddebs to be listed as NEW packages ? (me has no idea, cause well, i'm not an AA)
<slangasek> xnox: yes, it apparently is normal :)
<slangasek> accepted now
<tkamppeter> slangasek, xnox, why is cups-filters 1.2.0-1 stuck in xenial-proposed for 2 days now? It has successfully built on all plat forms.
<xnox> tkamppeter, it's in poppler transition, which is not complete. https://wiki.ubuntu.com/ProposedMigration
<tkamppeter> xnox, thanks.
<cjwatson> xnox: ddebs go into Launchpad as of April
<cjwatson> http://blog.launchpad.net/general/launchpad-news-april-june-2015
<xnox> cjwatson, i read that.... well just the "git" portion =))))) and then was over-exited and went to play with all of that.
<xnox> libdbusmenu is hung, as usual, killing the build.
<xnox> known bug #1429291
<ubot5> bug 1429291 in libdbusmenu (Ubuntu) "FTBFS on Ubuntu Vivid due to hang in test-json-instruction" [Critical,Triaged] https://launchpad.net/bugs/1429291
#ubuntu-release 2015-12-04
<Laney> hmm
<Laney> Is it expected that things being built against the s390x bootstrap archive are getting held in proposed?
<Laney> For example texlive-binaries got a dependency on libpoppler56 which it got from the bootstrap archive, and now britney is (correctly) saying it is uninstallable
<Laney> ...It would actually want a rebuild for the poppler transition on s390x, but poppler isn't built yet
<cjwatson> Mirv: Looks like qtbase-opensource-src build-depends on publicsuffix, which is in universe.  Could you sort out an MIR?
<cjwatson> That's needed for Laney's request, via a couple of layers
<Laney> I just asked him in #ubuntu-desktop
<Laney> but thanks
<Laney> Think it should be a trivial MIR
<Mirv> cjwatson: darn, yes, I'll file a MIR
<infinity> I could toss a bootstrap build of qtbase-opensource-src from the release pocket into a bootstrap repo.  Maybe.
<Laney> You could pre-promote publicsuffix based on its triviality ;)
<xnox> Mirv, cause without that, i can't build qtbase-opensource-src in proposed on s390x, and then i can't build new poppler, and the world is sad, and -proposed will pile up =)
<infinity> Laney: Looking now.
<Laney> Ta
<infinity> Yeah.
<infinity> I'm not on the team anymore, but happy to pre-promote.
<infinity> It's a single data file. :P
<cjwatson> And sigh, if I'd realised ghc and haskell-* were going to be uploaded overnight I'd have sync-blacklisted them.
<cjwatson> Now I get to rebuild everything.
<xnox> infinity, NB! _and_ a symlink =)
<Laney> Hopefully qtbase builds
<infinity> It had a single test failure in the previous version.
<infinity> Maybe this one's happier.
<infinity> Fingers crossed.
<xnox> yeah, there were weird QtFile test suite failures, with long 240+ characters file names, on a debian kernel...
<xnox> and different toolchain...
<xnox> and i see more qtbase being built in landing-032 again ?!
<Laney> Silos might need s390x turned on, if that's an explicit knob
<xnox> wgrant, ^
<xnox> Laney, i think it is a knob
<Mirv> Laney: xnox: cjwatson: https://bugs.launchpad.net/ubuntu/+source/publicsuffix/+bug/1522811
<ubot5> Ubuntu bug 1522811 in publicsuffix (Ubuntu) "[MIR] publicsuffix" [Undecided,New]
 * Laney adds s390x to transition-tracker
<Laney> Mirv: ta
<cjwatson> Laney: It is, but we want to let the bootstrap finish first
<cjwatson> There's always going to be a slightly ambiguous period
<cjwatson> But let's not confuse people with a bazillion dep-waits
<Laney> As you wish
<infinity> I was probably going to turn on s390x in silos early next week.
<infinity> Once we've made sure most of our stack kinda builds.
<xnox> building qtbase-opensource-src in a nonvirt ppa, with universe enabled, s390x build to see if it will build. (thus not waiting publicsuffix mir)
<infinity> xnox: it's already building in the primary archive.
<Laney>  Totals: 55 passed, 1 failed, 0 skipped, 0 blacklisted
<Laney> ********* Finished testing of tst_LargeFile *********
<Laney> Makefile:573: recipe for target 'check' failed
<xnox> as usual.
<xnox> oh but qfile did pass.
<infinity> #if defined(__x86_64__)
<infinity>         QEXPECT_FAIL("", "fails on 64-bit Linux (QTBUG-21175)", Abort);
<infinity> #endif
<infinity> WORST IFDEF EVER.
<infinity> Fails on 64-bit Linux, so we'll exclude only one 64-bit arch.
<infinity> And before anyone asks "but, how does it work on arm64 and ppc64el then?"
<infinity> # Skip tests on the archs they are known to be flaky  with current configuration
<infinity> testskip_architectures := arm64 powerpc ppc64el
<infinity> Brilliant in so many ways.
<infinity> Anyhow, someone fix either the ifdef in the test (preferred) or the excluded test arches (ick), and you're golden.
<infinity> Mirv, xnox: ^
<xnox> infinity, i have chroot up with qtbase, i was working on excluding individual tests, and marking htem expect fail
<xnox> infinity, cause most tests do pass.
<infinity> xnox: There's only one failing test.
<infinity> xnox: And there's already an ifdef there to exclude it on amd64.  That's what I was pointing out. :P
<xnox> infinity, thanks. i was fixing broken schroot on debian, that doesn't support too-new kernel with too new overlayfs expected options =)
<infinity> xnox: Use aufs?
<xnox> infinity, and there might be more tests after it, as the build is done without -k
<xnox> infinity, phhhh, i'm hipster.
<Mirv> infinity: xnox: my next upload will make the archs to run tests on opt-in instead of opt-out, so xnox can then later eg add s390x when it passes
<xnox> Mirv, please no, i want to run tests on s390x.
<xnox> or keep it enabled, i'll upload direct to archive, rather than silo to get it building and migrating.
<xnox> most of them pass on s390x, it's not a new platform, but a solid one.
<cjwatson> Well, opt-in is still good, you can just add s390x to the list.
<Mirv> xnox: well it's better to specify which architectures to run on, but I'll gladly add s390x there if you have the changes by that time
<xnox> Mirv, yeap.
<infinity> Mirv: The line I pointed out above is obviously wrong anyway.
<infinity> Mirv: When the comment says "doesn't work on 64-bit" and then it only excludes on 64-bit arch. :P
<infinity> Mirv: Especially since Qt pretty much has to have some is_64bit macro or something that's used in, like, the entire codebase...
<infinity> s/excludes on/excludes one/
<Mirv> infinity: sure it's wrong. upstream CI is x86+armhf only so they probably do things like that in tests at times unfortunately
<cjwatson> right, I'm going to cancel all the haskell builds that are still "needs building", partly to get queues under control a bit more and partly because they're mostly going to need rebuilds anyway
<xnox> proposed-migrations says that zipl-installer is not installable, yet i don't see how or why =(
<cjwatson> xnox: with all the virtual dependencies in use in the installer, it's probably fallout from something earlier on, maybe partman-base not being installable
<cjwatson> xnox: a lot of things should get less ridiculously difficult to unpick once a new kernel lands
<xnox> ack.
<xnox> well i added -proposed and -release, debian-installer bits and e.g. zipl-installer is installable, so it's okish. i guess it just doesn't migrate on it's own then.
<cjwatson> xnox: It transitively depends on kernel udebs, so until they're migratable, migrating zipl-installer would increase the installability count by one
<cjwatson> Even though it's basically for an existing reason
<apw> cjwatson, fyi i just released the 4.3 kernel
<cjwatson> apw: oh good, thanks
<xnox> where is autopackage test page?
<xnox> ...
<xnox> why did i cause new binaries for procps.... /me looks
<xnox> abi bump, sigh.
<xnox> E: Invalid Release signature (key id 40976EAF437D05B5) -> i hate the world
<xnox> tst_QImage 1 failed, tst_QtJson 1 failed, tst_QLogging 11 failed,
<xnox> =(
#ubuntu-release 2016-12-05
-queuebot:#ubuntu-release- Unapproved: opencc (yakkety-proposed/universe) [1.0.4-1ubuntu0.16.10.1 => 1.0.4-1ubuntu0.16.10.2] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.4]
<Laney> NEWing hdf5 would be appreciated if someone has a second
 * Laney grumbles at this transition
-queuebot:#ubuntu-release- Unapproved: snap (xenial-proposed/universe) [2013-11-29-1ubuntu2 => 2013-11-29-1ubuntu2ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snap (yakkety-proposed/universe) [2013-11-29-1ubuntu2 => 2013-11-29-1ubuntu2ubuntu0.16.10.1] (no packageset)
<ginggs> Laney: re hdf5: ruby-hdfeos5 has a pending fix in debian, armhf and i386 binaries scan be removed from in trilinos
<Laney> ginggs: yep
<ginggs> and libsis-jhdf5-java may as well be removed, it is rc in debian
<Laney> I have a tomboy note with these items in already
<Laney> wasn't close enough to want to do removals
<Laney> with insanetoolkit4 being broken
<sergiusens> infinity apw are you around to accept some packages (snapcraft into xenial-proposed and yakkety-proposed)
<infinity> sergiusens: Maaaybe.
<sergiusens> infinity then mayyybe thanks ;-)
<sergiusens> but thanks for breaking radio silence at least :-)
-queuebot:#ubuntu-release- Unapproved: rejected snap [source] (xenial-proposed) [2013-11-29-1ubuntu2ubuntu0.16.04.1]
<infinity>    * New upstream release 2.22.1 (LP: #1646993)
<ubot5> Launchpad bug 1646993 in snapcraft (Ubuntu Yakkety) "[SRU] New stable micro release 2.23" [Undecided,New] https://launchpad.net/bugs/1646993
<infinity> sergiusens: ^-- rly?
<sergiusens> omg
<sergiusens> infinity NOT
-queuebot:#ubuntu-release- New binary: unbound [ppc64el] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
<sergiusens> infinity if you reject that can I push with the same version?
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.6.2-0ubuntu1~ubuntu16.04.1 => 2.0.8-0ubuntu1~ubuntu16.04.2] (edubuntu, ubuntu-server)
<infinity> sergiusens: Yeah, though I wasn't going to reject just because of the changelog being derpy.
<sergiusens> infinity aside from the version, what other problem is there?
<infinity> sergiusens: Well, nothing else yet.  That was my point.
<infinity> sergiusens: As in, I won't reject if that's the only issue.
<infinity> stgraber: DUDE.
-queuebot:#ubuntu-release- New binary: unbound [s390x] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
<stgraber> infinity: I know, rejecting
<sergiusens> infinity oh, "wasn't", misread; ok, will wait on your further feedback then
<infinity> stgraber: I realise the previous version also had a derpy version, but do we need to continue with it? :)
-queuebot:#ubuntu-release- New binary: unbound [amd64] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: unbound [i386] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
<stgraber> infinity: oh, actually, it's just queuebot being confused above, the upload looks good
<infinity> stgraber: (2.0.8-0ubuntu1~16.04.1 perhaps?)
<infinity> Oh.  But there was already a 2.0.8-0ubuntu1~ubuntu16.04.1
<infinity> Gross.
-queuebot:#ubuntu-release- New: accepted hdf5 [arm64] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [armhf] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [amd64] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [powerpc] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [s390x] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted node-end-of-stream [amd64] (zesty-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-gli [amd64] (zesty-proposed) [2.14.0-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [i386] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted node-detect-indent [amd64] (zesty-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted toolz [amd64] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [ppc64el] (zesty-proposed) [1.10.0-patch1+docs-2]
-queuebot:#ubuntu-release- New: accepted pd-upp [amd64] (zesty-proposed) [0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.8-0ubuntu1~ubuntu16.04.2]
<infinity> stgraber: Same with lxc and lxcfs.  Why the hideous versions with "ubuntu" repeated?
<stgraber> infinity: just found where that pattern comes from, that's the format which backport-package uses, so we presumably started using that everywhere since our PPAs are auto-generated by backport-package and we want people to be able to turn them on/off so have the same pattern
<infinity> stgraber: Emulating the icky versions from lp-buildd/buildrecipe?
<infinity> Perhaps I should fix lp-buildd and backport-package to not duplicate ubuntu.
-queuebot:#ubuntu-release- New binary: unbound [arm64] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: unbound [powerpc] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
<stgraber> infinity: so yeah, we could stop that duplication but I'd first have to change the pattern in our scripts so the PPA stop using that for new builds, then we can do the same in the archive
<infinity> stgraber: Yeah, not urgent, just icky. :P
<infinity> Maybe I should fix the other occurences first.
-queuebot:#ubuntu-release- New binary: unbound [armhf] (zesty-proposed/main) [1.5.10-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snap [source] (yakkety-proposed) [2013-11-29-1ubuntu2ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.23]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.23+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.6]
<sergiusens> thanks!
<slashd> For SRU, could you please set LP: #1579609 affecting "Xenial" for pkg os-prober ? AND LP: #1176046 affecting "Trusty" ? thanks in advance !
<ubot5> Launchpad bug 1579609 in os-prober (Ubuntu) "os-prober bug resulting in possible FS corruption" [Critical,In progress] https://launchpad.net/bugs/1579609
<ubot5> Launchpad bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [High,In progress] https://launchpad.net/bugs/1176046
<rtg> slangasek, infinity - I think I'm having an overrides problem with zesty linux-4.9.0-6.7. linux-signed is failing to build because it cannot find the linux-image-4.9.0-6-generic deb. Please have a look at https://launchpadlibrarian.net/296550638/buildlog_ubuntu-zesty-amd64.linux-signed_4.9.0-6.7_BUILDING.txt.gz
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10 => 2.17.1+16.10ubuntu1] (desktop-core, ubuntu-server)
<slangasek> rtg: that's not an override problem, it's a release-uefi-signed-binaries-from-queue problem; releasing now
<rtg> slahuh, well I was in the ballpark
<rtg> slangasek, ^^
<slangasek> released
<rtg> slangasek, thanks. sforshee ^^
<rbasak> slashd: done, but note the usual place to ask is #ubuntu-bugs. I'd like to think that you get a wider able audience there. It's low traffic and people who can do bug actions lurk exactly to do them.
<slashd> rbasak, sure will use #ubuntu-bugs, TBH, I was following what is written here : https://wiki.ubuntu.com/StableReleaseUpdates ... Vanguards from the SRU team can be found in #ubuntu-release on the following schedule: ...
<slashd> rbasak, tks for doing my request ;)
<slashd> rbasak, sorry I found the right thing : Ask the Ubuntu bug control team to nominate the bug for the appropriate Ubuntu release(s)/series (e. g. the current LTS and latest stable release). You can ask on IRC (Freenode) in #ubuntu-bugs, or by emailing them at the address found on the linked page.
<slashd> my bad
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.9.0-6.7] (core, kernel)
<rbasak> slashd: right - the set of people who can nominate bugs for SRUs is much greater than the SRU team :)
<slashd> rbasak, yep thanks ;)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.8-0ubuntu1~ubuntu14.04.1 => 2.0.8-0ubuntu1~ubuntu14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.8-0ubuntu1~ubuntu14.04.2]
-queuebot:#ubuntu-release- New binary: hexchat [ppc64el] (zesty-proposed/universe) [2.12.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hexchat [arm64] (zesty-proposed/universe) [2.12.3-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gdb [source] (yakkety-proposed) [7.11.90.20161005-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected gdb [source] (xenial-proposed) [7.11.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: autopkgtest (trusty-backports/main) [4.2~ubuntu14.04.1 => 4.2.2~ubuntu14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (yakkety-backports/main) [4.1 => 4.2.2~ubuntu16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (xenial-backports/main) [4.2~ubuntu16.04.1 => 4.2.2~ubuntu16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (xenial-backports) [4.2.2~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (yakkety-backports) [4.2.2~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (trusty-backports) [4.2.2~ubuntu14.04.1]
-queuebot:#ubuntu-release- New binary: hexchat [amd64] (zesty-proposed/universe) [2.12.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vim [ppc64el] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [amd64] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [i386] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [s390x] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [armhf] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [powerpc] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: vim [arm64] (zesty-proposed/main) [2:8.0.0095-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.6.2-0ubuntu1~ubuntu16.04.1 => 2.6.2-0ubuntu3~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.6.2-0ubuntu1~ubuntu16.04.1 => 2.6.2-0ubuntu3~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ca-certificates [amd64] (zesty-proposed/main) [20161130] (core)
-queuebot:#ubuntu-release- New binary: libhdhomerun [ppc64el] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: forensics-extra [amd64] (zesty-proposed/universe) [1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: libhdhomerun [amd64] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: libhdhomerun [i386] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: libhdhomerun [arm64] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: jsxgraph [amd64] (zesty-proposed/universe) [0.99.5+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [amd64] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhdhomerun [armhf] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: wolfssl [i386] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [amd64] (zesty-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [ppc64el] (zesty-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [i386] (zesty-proposed/none) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: d3-format [amd64] (zesty-proposed/none) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-fancy-log [amd64] (zesty-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-has-gulplog [amd64] (zesty-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-rechoir [amd64] (zesty-proposed/none) [0.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [i386] (zesty-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [ppc64el] (zesty-proposed/none) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-flagged-respawn [amd64] (zesty-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [ppc64el] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [amd64] (zesty-proposed/none) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-interpret [amd64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdate-holidays-de-perl [amd64] (zesty-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhdhomerun [s390x] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: node-glogg [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-path-root-regex [amd64] (zesty-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stream-consume [amd64] (zesty-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nbsphinx [amd64] (zesty-proposed/none) [0.2.9+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sequencify [amd64] (zesty-proposed/none) [0.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-multipipe [amd64] (zesty-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-withr [amd64] (zesty-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [amd64] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [i386] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: dnssecjava [amd64] (zesty-proposed/none) [1.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhdhomerun [powerpc] (zesty-proposed/universe) [20161117-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: wolfssl [arm64] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [s390x] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [s390x] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [s390x] (zesty-proposed/universe) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [armhf] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [armhf] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [arm64] (zesty-proposed/universe) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [arm64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [powerpc] (zesty-proposed/universe) [3.9.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chasquid [armhf] (zesty-proposed/universe) [0.01+git20161124.6479138-2] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [armhf] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-indicator-applet [powerpc] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [arm64] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [powerpc] (zesty-proposed/multiverse) [0.8.5-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (trusty-proposed/main) [2:2.99.910-0ubuntu1.6 => 2:2.99.910-0ubuntu1.7] (desktop-core, xorg)
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [amd64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [armhf] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [powerpc] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [s390x] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted chasquid [amd64] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted chasquid [armhf] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted chasquid [ppc64el] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted d3-format [amd64] (zesty-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted forensics-extra [amd64] (zesty-proposed) [1.2]
-queuebot:#ubuntu-release- New: accepted hexchat [arm64] (zesty-proposed) [2.12.3-2]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [arm64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [ppc64el] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted chasquid [arm64] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted chasquid [s390x] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted hexchat [amd64] (zesty-proposed) [2.12.3-2]
-queuebot:#ubuntu-release- New: accepted budgie-indicator-applet [i386] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted chasquid [i386] (zesty-proposed) [0.01+git20161124.6479138-2]
-queuebot:#ubuntu-release- New: accepted hexchat [ppc64el] (zesty-proposed) [2.12.3-2]
-queuebot:#ubuntu-release- New: accepted ca-certificates [amd64] (zesty-proposed) [20161130]
-queuebot:#ubuntu-release- New: accepted dnssecjava [amd64] (zesty-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- New: accepted jsxgraph [amd64] (zesty-proposed) [0.99.5+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libdate-holidays-de-perl [amd64] (zesty-proposed) [1.9-1]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [arm64] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [i386] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [ppc64el] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted nbsphinx [amd64] (zesty-proposed) [0.2.9+ds-2]
-queuebot:#ubuntu-release- New: accepted node-flagged-respawn [amd64] (zesty-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted node-has-gulplog [amd64] (zesty-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-multipipe [amd64] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-rechoir [amd64] (zesty-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted node-stream-consume [amd64] (zesty-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [amd64] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [powerpc] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted node-fancy-log [amd64] (zesty-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted node-interpret [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-sequencify [amd64] (zesty-proposed) [0.0.7-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [arm64] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [armhf] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted node-glogg [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-withr [amd64] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [s390x] (zesty-proposed) [20161117-2]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [powerpc] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted node-path-root-regex [amd64] (zesty-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [amd64] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [i386] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [s390x] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted wolfssl [arm64] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [i386] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [ppc64el] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [armhf] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted wolfssl [amd64] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [powerpc] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [ppc64el] (zesty-proposed) [0.8.5-5]
-queuebot:#ubuntu-release- New: accepted wolfssl [s390x] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [armhf] (zesty-proposed) [3.9.10+dfsg-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-53.74] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (xenial-backports) [2.6.2-0ubuntu3~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.6.2-0ubuntu3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-105.152] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-105.152]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-30.32]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-53.74]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-77.85] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-77.85]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-105.152~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-77.85~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-53.74~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.8.0-30.32~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-77.85~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.8.0-30.32~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-53.74~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-104.151~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-105.152~precise1]
-queuebot:#ubuntu-release- New binary: r-cran-dbitest [amd64] (zesty-proposed/universe) [1.4-1] (no packageset)
<clivejo> can someone help in getting new packages added to the Kubuntu package list?
<cjwatson> You want a DMB member for that probably
<clivejo> unfortunately they don't seem to want to reply to my email
-queuebot:#ubuntu-release- New: accepted r-cran-dbitest [amd64] (zesty-proposed) [1.4-1]
<cjwatson> they're nevertheless the right team
<cjwatson> s'not really a release thing
<clivejo> ok
<clivejo> can you suggest any other way to get something uploaded?
 * clivejo watches tumbleweed blow by and wanders off to play tik tak toe with a chicken
 * tumbleweed assures you he didn't blow by :P
<clivejo> oupps, didn't mean to ping you!
<tumbleweed> that happens with this nick
<cjwatson> In your position I'd probably poke DMB members individually on IRC until somebody replies :)
<cjwatson> Assuming it's been a respectable interval since your mail
<clivejo> but it does make sense to where my mind got tumbleweed from
<clivejo> not something you seen much of in Ireland to be fair
<clivejo> cjwatson: don't like having to poke people, Ill just go make maps on OSM :)
-queuebot:#ubuntu-release- New binary: jupyter-sphinx-theme [amd64] (zesty-proposed/none) [0.0.6+ds1-2] (no packageset)
#ubuntu-release 2016-12-06
-queuebot:#ubuntu-release- New binary: sonnet [ppc64el] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [ppc64el] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [amd64] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [i386] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [arm64] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [amd64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [i386] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [s390x] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [powerpc] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [armhf] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [s390x] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwayland [armhf] (zesty-proposed/universe) [4:5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sonnet [powerpc] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted unbound [amd64] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [armhf] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [powerpc] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [s390x] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [arm64] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [i386] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [ppc64el] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [arm64] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [ppc64el] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [armhf] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [s390x] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted unbound [i386] (zesty-proposed) [1.5.10-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [powerpc] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted vim [amd64] (zesty-proposed) [2:8.0.0095-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [amd64] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [armhf] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [powerpc] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [s390x] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [arm64] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [ppc64el] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland [i386] (zesty-proposed) [4:5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jupyter-sphinx-theme [amd64] (zesty-proposed) [0.0.6+ds1-2]
-queuebot:#ubuntu-release- New: accepted sonnet [arm64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [i386] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [ppc64el] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [amd64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [powerpc] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [armhf] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sonnet [s390x] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdoctools [amd64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [ppc64el] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [i386] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ipywidgets [amd64] (zesty-proposed/universe) [5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdoctools [s390x] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [armhf] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [powerpc] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (yakkety-proposed/main) [1.2-0ubuntu1.1 => 1.4-0ubuntu1~yakkety] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.2-0ubuntu1.1~xenial => 1.4-0ubuntu1~xenial] (no packageset)
-queuebot:#ubuntu-release- New binary: jupyter-notebook [amd64] (zesty-proposed/universe) [4.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raspi3-firmware [arm64] (zesty-proposed/multiverse) [1.20161123-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [i386] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [ppc64el] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [amd64] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [armhf] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [arm64] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [s390x] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dune-uggrid [powerpc] (zesty-proposed/universe) [2.5.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dune-uggrid [amd64] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [armhf] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [powerpc] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [s390x] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted kdoctools [arm64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [i386] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [ppc64el] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [arm64] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [ppc64el] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted kdoctools [armhf] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [s390x] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dune-uggrid [i386] (zesty-proposed) [2.5.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted kdoctools [powerpc] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [amd64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipywidgets [amd64] (zesty-proposed) [5.2.2-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.9.0-6.7]
-queuebot:#ubuntu-release- New: accepted jupyter-notebook [amd64] (zesty-proposed) [4.2.3-1]
-queuebot:#ubuntu-release- New: accepted raspi3-firmware [arm64] (zesty-proposed) [1.20161123-2]
-queuebot:#ubuntu-release- Unapproved: snap (xenial-proposed/universe) [2013-11-29-1ubuntu2 => 2013-11-29-1ubuntu2.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [ppc64el] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [arm64] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [i386] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [armhf] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [amd64] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [s390x] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kronometer [powerpc] (zesty-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sagenb-export [amd64] (zesty-proposed/universe) [2.0-1] (no packageset)
<Elleo> pitti: ping?
<seb128> Elleo, he's at a sprint this week and not watch IRC much, you probably should state what you want
<seb128> watching
<seb128> so he can act from backlog or maybe somebody else can help you
<Elleo> pitti, seb128: https://bileto.ubuntu.com/#/ticket/2260 <-- this silo is stuck as showing autopkg tests as "running", it thinks one of the vivid tests is still running from friday, but it isn't
<seb128> Laney knows a bit about autopkgtest infra and might be able to help
<seb128> Laney, do you know what should be done in such cases? retry?
<Elleo> seb128, Laney: not sure how to retry, since the excuses page doesn't show the retry option due to it thinking its running rather than failed
<Laney> seb128: yes, but it looks like the API that retry-autopkgtest-regressions uses to generate the request URLs is gone now
<Laney> 404
<Laney> :|
<seb128> :-(
<Laney> ok, done
<seb128> Laney, how did you do it? is that something the uploader can do (for next time)?
<seb128> Laney, oh, and thanks ;-)
<seb128> Elleo, ^
<Laney> making a merge proposal, and then yes
<Elleo> Laney, seb128: thanks very much
<seb128> cool
<Laney> Elleo: I did "retry-autopkgtest-regressions --bileto 2260 --series vivid --state RUNNING"
<Laney> then you get a URL to use
<Elleo> Laney: cool, thanks, didn't know about that tool
<Laney> tell all your friends :)
<Elleo> heh, will do ;)
<ginggs_> morning! vim-gtk3 needs to be promoted to main (vim-gnome is now a transitional package that depends on vim-gtk3) - what do i need to do?
<infinity> ginggs_: Nothing.
<infinity> ginggs_: I see somoene got impatient waiting for me to merge. :P
 * infinity wonders if he should review that...
<ginggs_> infinity: if you would that would be great
<infinity> Bah, someone used merge-o-matic for this. :/
<infinity> Pointless changelog format changes.
<infinity> Bleh, and dropped my supported series changes.
<infinity> ginggs_: Bad sponsor. :P
<ginggs_> infinity: sorry :(
<Laney> Can someone clear up the qgis NBS in z-proposed please?
<Laney> and ... remove gyoto from z-proposed so that I can rebuild the old version (or copy it back if that'll work), remove/demote libsis-jhdf5-java from zesty, remove trilinos binaries from zesty armhf/i386 (that is also on ginggs_ to fix properly :P)
<Laney> then perhaps we'll get somewhat close to this hell being a candidate (modulo tests)
<xnox> pitti, did we colide uploading metas? =)
<pitti> xnox: for ubuntustudio?
<pitti> xnox: it seems I won, anyway :) https://launchpad.net/ubuntu/+source/ubuntustudio-meta/0.163
<pitti> xnox: I was waiting for the seed branch to get merged as core-dev can't commit to the studio seeds
<xnox> heh, that sounds wrong
<Laney> maybe a bug for the above would be helpful?
-queuebot:#ubuntu-release- New: accepted kronometer [amd64] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [armhf] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [powerpc] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [s390x] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [arm64] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [ppc64el] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted kronometer [i386] (zesty-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted sagenb-export [amd64] (zesty-proposed) [2.0-1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.24-0ubuntu1.16.04.1 => 5.0.24-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: kio [amd64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kio [ppc64el] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kio [i386] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (yakkety-proposed/universe) [5.1.6-2 => 5.1.6-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.7 => 20101020ubuntu451.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.8]
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu483 => 20101020ubuntu483.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu483.1]
-queuebot:#ubuntu-release- New binary: kio [s390x] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kio [powerpc] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kio [armhf] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kio [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
 * Laney prods
-queuebot:#ubuntu-release- New binary: snapper [ppc64el] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [i386] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [amd64] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [armhf] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [s390x] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [powerpc] (zesty-proposed/universe) [0.3.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper [arm64] (zesty-proposed/universe) [0.3.3-4] (no packageset)
<clivejo> Regarding ^^ New binary: kio [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu) would someone mind reviewing that?
-queuebot:#ubuntu-release- New binary: python-acora [ppc64el] (zesty-proposed/none) [2.0-2] (no packageset)
<clivejo> it is basically a rename of the package to indicate the version kio-dev => libkf5kio-dev
-queuebot:#ubuntu-release- New binary: android-platform-libcore [amd64] (zesty-proposed/universe) [7.0.0+r3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpgobject-type-bytestring-perl [amd64] (zesty-proposed/none) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-is-negated-glob [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-lazystream [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [i386] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dynlm [amd64] (zesty-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-from2 [amd64] (zesty-proposed/none) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [amd64] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-lazy-debug-legacy [amd64] (zesty-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-intervaltree [amd64] (zesty-proposed/none) [2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stream-shift [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [s390x] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-streamtest [amd64] (zesty-proposed/none) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-unc-path-regex [amd64] (zesty-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-zc.customdoctests [amd64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [armhf] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [powerpc] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-acora [arm64] (zesty-proposed/none) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted android-platform-libcore [amd64] (zesty-proposed) [7.0.0+r3-1]
-queuebot:#ubuntu-release- New: accepted node-from2 [amd64] (zesty-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-lazy-debug-legacy [amd64] (zesty-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-stream-shift [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-unc-path-regex [amd64] (zesty-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted python-acora [arm64] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted python-acora [i386] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted python-acora [ppc64el] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted python-intervaltree [amd64] (zesty-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-dynlm [amd64] (zesty-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted libpgobject-type-bytestring-perl [amd64] (zesty-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-lazystream [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-acora [amd64] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted python-acora [powerpc] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted python-zc.customdoctests [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted snapper [arm64] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted snapper [i386] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted snapper [s390x] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted node-is-negated-glob [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-acora [armhf] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted snapper [amd64] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted snapper [powerpc] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted node-streamtest [amd64] (zesty-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted snapper [armhf] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New: accepted python-acora [s390x] (zesty-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted snapper [ppc64el] (zesty-proposed) [0.3.3-4]
-queuebot:#ubuntu-release- New binary: node-first-chunk-stream [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-merge-stream [amd64] (zesty-proposed/universe) [1.0.1-1] (no packageset)
<acheronuk> ditto what clivejo said on New binary: kio [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
<acheronuk> and the other archs
-queuebot:#ubuntu-release- Unapproved: linux-firmware (yakkety-proposed/main) [1.161 => 1.161.1] (core, kernel)
#ubuntu-release 2016-12-07
-queuebot:#ubuntu-release- New source: pysha3 (zesty-proposed/primary) [1.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New sync: android-platform-system-tools-aidl (zesty-proposed/primary) [1:7.0.0+r1-1]
<tsimonq2> !info apt zenial
<ubot5> 'zenial' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed, yakkety, yakkety-backports, yakkety-proposed, zesty, zesty-backports, 
<tsimonq2> !info apt xenial
<ubot5> apt (source: apt): commandline package manager. In component main, is important. Version 1.2.15 (xenial), package size 1034 kB, installed size 3305 kB
<tsimonq2> Hmmm, fun: https://github.com/Debian/apt/issues/27
-queuebot:#ubuntu-release- New sync: p4est (zesty-proposed/primary) [1.1-4]
<acheronuk> kio new binary dev-package rename commit https://anonscm.debian.org/cgit/pkg-kde/frameworks/kio.git/commit/?id=5b57f9997123bb577ae9033be9339aa8a26e08e4
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.12+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.12+16.10ubuntu1]
<acheronuk> pitti et al: if you are around and can spare a sec, could you perhaps take a look at the new binary for kio? sorry to be a pain, but it's blocking the rest of our frameworks stack from building now. TY :)
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.8 => 20101020ubuntu451.9] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.9]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.4 => 0.103ubuntu4.5] (core)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.17.1+16.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.18+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.18+16.10]
<clivejo> hi doko_ are you on the release team?
-queuebot:#ubuntu-release- Unapproved: tzdata (precise-proposed/main) [2016h-0ubuntu0.12.04 => 2016j-0ubuntu0.12.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2016h-0ubuntu0.16.04 => 2016j-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2016h-0ubuntu0.14.04 => 2016j-0ubuntu0.14.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (yakkety-proposed/main) [2016h-0ubuntu0.16.10 => 2016j-0ubuntu0.16.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (precise-proposed) [2016j-0ubuntu0.12.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2016j-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (trusty-proposed) [1.6.18-0ubuntu4.5]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2016j-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (yakkety-proposed) [2016j-0ubuntu0.16.10]
<ginggs> would someone please process p4est in new? and there have been a few requests for kio as well
-queuebot:#ubuntu-release- New: accepted android-platform-system-tools-aidl [sync] (zesty-proposed) [1:7.0.0+r1-1]
-queuebot:#ubuntu-release- New: accepted p4est [sync] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted node-first-chunk-stream [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-merge-stream [amd64] (zesty-proposed) [1.0.1-1]
<ginggs> thanks
-queuebot:#ubuntu-release- New binary: p4est [i386] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: p4est [ppc64el] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted kio [amd64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [armhf] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [powerpc] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [s390x] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [arm64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [ppc64el] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio [i386] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: p4est [amd64] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: p4est [arm64] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: p4est [s390x] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: p4est [armhf] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: p4est [powerpc] (zesty-proposed/none) [1.1-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted p4est [amd64] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [armhf] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [powerpc] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [s390x] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [arm64] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [ppc64el] (zesty-proposed) [1.1-4]
-queuebot:#ubuntu-release- New: accepted p4est [i386] (zesty-proposed) [1.1-4]
<acheronuk> thank you to whoever accepted kio :)
<infinity> acheronuk: NP.
<sforshee> is there someone around that could approve a couple of my linux-firmware uploads?
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (xenial-proposed) [34.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted metar [source] (xenial-proposed) [20061030.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected opencc [source] (yakkety-proposed) [1.0.4-1ubuntu0.16.10.2]
<infinity> sforshee: Which series'?
<sforshee> infinity: trusty and xenial
<infinity> sforshee: By which, you mean trusty and yakkety?
<sforshee> infinity: yes, that's what I meant
<infinity> :)
<sforshee> still early for me :-P
<infinity> Pretty sure I accepted the xenial one a while ago
<infinity> I'll grab the other two today.
<sforshee> yeah, I just forgot which one I uploaded yesterday
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.5]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (trusty-proposed) [1.127.23]
<infinity> sforshee: Done and done.
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (yakkety-proposed) [1.161.1]
<sforshee> infinity: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (yakkety-proposed) [3.175.1]
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (xenial-proposed) [3.168.3]
<lamont> rbasak: updated 1621507
<rbasak> Thanks!
-queuebot:#ubuntu-release- New binary: plasma-framework [ppc64el] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [amd64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [s390x] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [i386] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [arm64] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [armhf] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-framework [powerpc] (zesty-proposed/universe) [5.28.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted plasma-framework [amd64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [armhf] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [powerpc] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [s390x] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [arm64] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [ppc64el] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-framework [i386] (zesty-proposed) [5.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New sync: libjs-handlebars (zesty-proposed/primary) [3:4.0.5-4]
-queuebot:#ubuntu-release- New binary: kwallet-pam [amd64] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New sync: libmath-gsl-perl (zesty-proposed/primary) [0.39-1]
<LocutusOfBorg> doko, ping about dpkg/hardening everywhere
<LocutusOfBorg> stuff like libpng1.6 gdcm and more started failing
 * LocutusOfBorg sends a mail
-queuebot:#ubuntu-release- Unapproved: resolvconf (yakkety-proposed/main) [1.79ubuntu1 => 1.79ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu2 => 1.78ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: node-strip-bom-stream [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bcmwl (yakkety-proposed/restricted) [6.30.223.248+bdcom-0ubuntu11 => 6.30.223.271+bdcom-0ubuntu1~2.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deal.ii [ppc64el] (zesty-proposed/universe) [8.4.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bcmwl (xenial-proposed/restricted) [6.30.223.248+bdcom-0ubuntu8 => 6.30.223.271+bdcom-0ubuntu1~1.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deal.ii [s390x] (zesty-proposed/universe) [8.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [amd64] (zesty-proposed/universe) [8.4.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bcmwl (trusty-proposed/restricted) [6.30.223.248+bdcom-0ubuntu0.2 => 6.30.223.271+bdcom-0ubuntu1~0.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: kwin [ppc64el] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [s390x] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [i386] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [powerpc] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libspectre (trusty-proposed/main) [0.2.7-2ubuntu1.1 => 0.2.7-2ubuntu1.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: kwin [arm64] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [armhf] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [amd64] (zesty-proposed/universe) [4:5.8.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: virt-manager (yakkety-proposed/universe) [1:1.3.2-3ubuntu3 => 1:1.3.2-3ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virt-manager (xenial-proposed/universe) [1:1.3.2-3ubuntu1.16.04.2 => 1:1.3.2-3ubuntu1.16.04.3] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [arm64] (zesty-proposed/universe) [8.4.2-2] (no packageset)
#ubuntu-release 2016-12-08
<wxl> ok who wants to help get some more packages in the kubuntu packageset?
<wxl> come on you know you want to
<wxl> it's super fun
<wxl> and you brag to all your friends!
<valorie> I thought it was the DMB who did that, wxl?
<wxl> or do i have to wait for someone from DMB?
<valorie> the suggestion was to ping those people
<valorie> clivejo emailed them already, and asfaik has not gotten a reply
<wxl> valorie: well infinity, bdmurray, cyphermox, micahg, rbasak are all DMB *AND* they're here
<valorie> possibly because each of them thinks someone else will do it
<valorie> cool
 * valorie hushes up then
<wxl> you know this is where all the cool kids are
<clivejo> I did what now?
<valorie> you said you wrote to teh DMB
<wxl> clivejo: you've been kindly cajoling the developer board to get our packageset updated
<clivejo> I did, and cyphermox replied, spoke with us earlier in #kubuntu-devel
<wxl> clivejo: we were led to believe in #kubuntu-devel that not all of these have been resolved
<clivejo> see -devel backlog approx 17:21 UTC
<clivejo> none are "resolved"
<clivejo> they need adding to our packageset
<wxl> they ALL still do? rik said there were only 6 left.
<clivejo> Im confused at what that means
<wxl> yeah i guess i am too
 * wxl sighs
<wxl> i guess we'll just need to wait until cyphermox shows up again
<clivejo> all the packages on that trello card are ones we need added to Kubuntu package set
<wxl> let's move this over to kubuntu-devel until we get out facts straight XD
<clivejo> some are really holding us back "roadblockers" and some are wishlist
<acheronuk> @release team - whoops. sorry for the noise. slight miscommunication
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.1 => 1:8.0-0ubuntu3.2] (core)
-queuebot:#ubuntu-release- New binary: python-keepalive [amd64] (zesty-proposed/none) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sagenb [amd64] (zesty-proposed/none) [0.13+ds1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xorg-server-lts-xenial (trusty-proposed/main) [2:1.18.3-1ubuntu2.2~trusty3 => 2:1.18.4-0ubuntu0.2~trusty1] (no packageset)
<rbasak> bdmurray: FYI, I'm continuing to look at initramfs-tools and ifupdown from the xenial queue today.
<bdmurray> rbasak: ack, thanks
<rbasak> bdmurray: also cloud-init
-queuebot:#ubuntu-release- New: accepted kwin [amd64] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [armhf] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [powerpc] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [s390x] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [arm64] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [ppc64el] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [i386] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwallet-pam [amd64] (zesty-proposed) [4:5.8.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [sync] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted python-keepalive [amd64] (zesty-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted libjs-handlebars [sync] (zesty-proposed) [3:4.0.5-4]
-queuebot:#ubuntu-release- New: accepted sagenb [amd64] (zesty-proposed) [0.13+ds1-1]
-queuebot:#ubuntu-release- New: accepted node-strip-bom-stream [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libspectre [source] (trusty-proposed) [0.2.7-2ubuntu1.2]
-queuebot:#ubuntu-release- New binary: libjs-handlebars [amd64] (zesty-proposed/none) [3:4.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [amd64] (zesty-proposed/none) [0.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [ppc64el] (zesty-proposed/none) [0.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [i386] (zesty-proposed/none) [0.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [s390x] (zesty-proposed/none) [0.39-1] (no packageset)
<acheronuk> ^^^ thank you to whoever just accepted kwin there :)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [powerpc] (zesty-proposed/none) [0.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [arm64] (zesty-proposed/none) [0.39-1] (no packageset)
<acheronuk> I only mention as I was sitting here with a request typed out wondering whether to be cheeky and hit send.....
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [armhf] (zesty-proposed/none) [0.39-1] (no packageset)
<acheronuk> but thanks would be due anyway..... not saying otherwise
 * acheronuk stops digging holes
-queuebot:#ubuntu-release- Unapproved: rejected resolvconf [source] (xenial-proposed) [1.78ubuntu3]
-queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu2 => 1.78ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected resolvconf [source] (yakkety-proposed) [1.79ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: resolvconf (yakkety-proposed/main) [1.79ubuntu1 => 1.79ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: mesa (yakkety-proposed/main) [12.0.3-1ubuntu2 => 12.0.5-0ubuntu0.16.10.1] (core, xorg)
-queuebot:#ubuntu-release- New sync: storage-provider-webdav (zesty-proposed/primary) [0.1+17.04.20161128-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted deal.ii [amd64] (zesty-proposed) [8.4.2-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [ppc64el] (zesty-proposed) [8.4.2-2]
-queuebot:#ubuntu-release- New: accepted libjs-handlebars [amd64] (zesty-proposed) [3:4.0.5-4]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [arm64] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [i386] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [s390x] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [arm64] (zesty-proposed) [8.4.2-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [amd64] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [powerpc] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [s390x] (zesty-proposed) [8.4.2-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [armhf] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [ppc64el] (zesty-proposed) [0.39-1]
-queuebot:#ubuntu-release- New binary: weston [ppc64el] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: wordpress [amd64] (zesty-proposed/universe) [4.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: weston [amd64] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [i386] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [s390x] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [arm64] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [powerpc] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [armhf] (zesty-proposed/universe) [1.12.0-1] (xorg)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.17.1+16.10ubuntu1]
-queuebot:#ubuntu-release- New: accepted weston [amd64] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [armhf] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [powerpc] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [s390x] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [arm64] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [ppc64el] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted weston [i386] (zesty-proposed) [1.12.0-1]
-queuebot:#ubuntu-release- New: accepted wordpress [amd64] (zesty-proposed) [4.7+dfsg-1]
<rtg> can I get some approval love for bcmwl in trusty, xenial, and yakkety ?
-queuebot:#ubuntu-release- Unapproved: deja-dup (yakkety-proposed/main) [34.2-0ubuntu3 => 34.2-0ubuntu3.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: deja-dup (trusty-proposed/main) [30.0-0ubuntu4 => 30.0-0ubuntu4.1] (ubuntu-desktop)
<santa_> hi
<infinity> rtg: Lemme have a look.
<santa_> pitti, slangasek: I would like to tell you about a couple of things
<santa_> 1. now we have something to check the autopkgtests status in kubuntu before uploading the packages
<infinity> rtg: This is just a straight backport of the zesty package?
<santa_> 2. I'm expecting the autopkgtests of kdelibs4support and probably baloo for non-amd64 (and perhaps kde-cli-tools)
<rtg> infinity, yup, with only the versions changed.
<infinity> rtg: Have you tested that it builds against all the target kernels (3.13->4.4 for trusty, 4.4->4.8 for X/Y)?
<rtg> infinity, I tested each package in a VM to make sure it installed and compiled.
<infinity> Well, builds and inserts, ideally. :)
<santa_> it would be nice if we could have some mercy on those given that we are dealing with our first upload for zesty
<infinity> rtg: Kay.  3.13 and 4.4?
<infinity> rtg: I'm not going to review too deeply if you've done your due diligence there.
<rtg> infinity, trusty, xenial, and yakkety
<rtg> I did not attempt against HWE kernels
<santa_> oh, and also we will need to get gpgme1.0 fixed in -proposed
<infinity> rtg: Well, the only HWE kernel we still support in T is 4.4
<infinity> rtg: So, if it works with 3.13 and 4.4, we're good.
<rtg> which is why I wasn't too worried
<santa_> http://gpul.grupos.udc.es/sponsor/gpgme1.0/
<santa_> if someone can upload this fixed package it would be really nice because that would be needed for kwallet-kf5
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [source] (trusty-proposed) [6.30.223.271+bdcom-0ubuntu1~0.1]
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [source] (xenial-proposed) [6.30.223.271+bdcom-0ubuntu1~1.1]
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [source] (yakkety-proposed) [6.30.223.271+bdcom-0ubuntu1~2.1]
<infinity> rtg: Done, done, and done.
<rtg> infinity, thanks much
<acheronuk> santa_: I assume you saw the bug on gpgme1.0?
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1647204
<ubot5> Ubuntu bug 1647204 in gpgme1.0 (Ubuntu) "1.8.0-2 FTBFS in zesty 17.04" [Undecided,New]
<acheronuk> I had tried half your fix, but hardening options is not a things I am hugely up on
<santa_> acheronuk: nope, building in a ppa now...
-queuebot:#ubuntu-release- Unapproved: crash (trusty-proposed/main) [7.0.3-3ubuntu4.4 => 7.0.3-3ubuntu4.5] (core)
<acheronuk> santa_: I wonder if you will see the indefinite hang on gpg-agent starting and stopping that I did in a ppa
<santa_> https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-good/+build/11538897
 * acheronuk sits and watches build
<acheronuk> I wanted that for KCI as well, but gave up and pinched Neon's version in the end
<acheronuk> I did -pie but not +pic
<acheronuk> santa_: I fear your build may be stuck at the point mine did :/
<acheronuk> site there doing not much until the builder kills it due to inactivity
<acheronuk> santa_: tick tock.... LP killed my test builds after 150 mins
-queuebot:#ubuntu-release- New binary: dcm2niix [ppc64el] (zesty-proposed/none) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [ppc64el] (zesty-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bcal [amd64] (zesty-proposed/universe) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [amd64] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: casacore-data [amd64] (zesty-proposed/universe) [1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [i386] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [amd64] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-config [amd64] (zesty-proposed/universe) [0.0~git20160626.0.e64b424-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdmi2usb-fx2-firmware [amd64] (zesty-proposed/universe) [0.0.0~git20151018-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-rpc [amd64] (zesty-proposed/universe) [0.0~git20161021.0.e6e3853-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [i386] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: itamae [amd64] (zesty-proposed/universe) [1.9.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-mergeomics [amd64] (zesty-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [s390x] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [powerpc] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ixo-usb-jtag [amd64] (zesty-proposed/universe) [0.0.0+git20160908-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [s390x] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: willow [amd64] (zesty-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [powerpc] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [ppc64el] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [s390x] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [amd64] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [powerpc] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [i386] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New source: zendframework (zesty-proposed/primary) [1.12.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: icingaweb2 [amd64] (zesty-proposed/universe) [2.3.4+fix-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [arm64] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocplib-simplex [armhf] (zesty-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [arm64] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcm2niix [armhf] (zesty-proposed/universe) [1.0.20161101-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [armhf] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtltools [arm64] (zesty-proposed/universe) [1.0+dfsg-1] (no packageset)
<elopio> slangasek: can you help us releasing snapcraft? https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1646993
<ubot5> Ubuntu bug 1646993 in snapcraft (Ubuntu Yakkety) "[SRU] New stable micro release 2.23" [Undecided,Fix committed]
<elopio> it's ready.
-queuebot:#ubuntu-release- New binary: scram [ppc64el] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [s390x] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dehydrated [amd64] (zesty-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-is-unc-path [amd64] (zesty-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-pkg-up [amd64] (zesty-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-resolve-pkg [amd64] (zesty-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-load-grunt-tasks [amd64] (zesty-proposed/universe) [3.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-vinyl [amd64] (zesty-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-resolve-from [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [amd64] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [powerpc] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [i386] (zesty-proposed/universe) [0.11.4-1] (no packageset)
#ubuntu-release 2016-12-09
-queuebot:#ubuntu-release- New binary: scram [armhf] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [arm64] (zesty-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-106.153~precise1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-106.153~precise1]
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (trusty-proposed) [7.0.3-3ubuntu4.5]
<xnox> pitti, can upstart be migrated ignoring tests? the only change is use upstart in less sessions.
<xnox> and i hope to remove it completely
<xnox> it is racy. i had to rebuild armhf/arm64 twice to succeed the build on buildds.
<pitti> xnox: yes, we've been bumping the force-badtest for a long time anyway
<xnox> excellent! thanks.
<pitti> (done)
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.2 => 3.168.3] (ubuntu-desktop, ubuntu-server)
<rbasak> tjaalton, slangasek: FYI, still working on reviewing MAAS IPv6 SRU pieces in Xenial - cloud-init, ifupdown, initramfs-tools, isc-dhcp, open-iscsi.
<rbasak> Almost there now.
-queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.175 => 3.175.1] (ubuntu-desktop, ubuntu-server)
<xnox> pitti, please RM google-mock gtest
<xnox> as they are superseed by the https://launchpad.net/ubuntu/+source/googletest which builds all the binaries the previous two did
<xnox> as the two projects merged upstream.
<xnox> pitti, ^
<pitti> xnox: *flush* done
<xnox> tah
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.6 => 0.122ubuntu8.7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (yakkety-proposed) [34.2-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (trusty-proposed) [30.0-0ubuntu4.1]
-queuebot:#ubuntu-release- New binary: cloud-initramfs-tools [amd64] (zesty-proposed/main) [0.33ubuntu1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted cloud-initramfs-tools [amd64] (zesty-proposed) [0.33ubuntu1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [armhf] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted dehydrated [amd64] (zesty-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted node-is-unc-path [amd64] (zesty-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-pkg-up [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-resolve-pkg [amd64] (zesty-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [arm64] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted qtltools [amd64] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qtltools [armhf] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qtltools [powerpc] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [arm64] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted icingaweb2 [amd64] (zesty-proposed) [2.3.4+fix-1]
-queuebot:#ubuntu-release- New: accepted node-resolve-from [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [armhf] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted qtltools [i386] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qtltools [s390x] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scram [arm64] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted scram [i386] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted scram [ppc64el] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted willow [amd64] (zesty-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [powerpc] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted node-vinyl [amd64] (zesty-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted qtltools [ppc64el] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scram [armhf] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted scram [s390x] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted node-load-grunt-tasks [amd64] (zesty-proposed) [3.5.2-1]
-queuebot:#ubuntu-release- New: accepted scram [amd64] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted qtltools [arm64] (zesty-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scram [powerpc] (zesty-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted bcal [amd64] (zesty-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [amd64] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [ppc64el] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted hdmi2usb-fx2-firmware [amd64] (zesty-proposed) [0.0.0~git20151018-1]
-queuebot:#ubuntu-release- New: accepted ixo-usb-jtag [amd64] (zesty-proposed) [0.0.0+git20160908-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [i386] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [ppc64el] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-mergeomics [amd64] (zesty-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted casacore-data [amd64] (zesty-proposed) [1.0]
-queuebot:#ubuntu-release- New: accepted dcm2niix [s390x] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [amd64] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [s390x] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted dcm2niix [i386] (zesty-proposed) [1.0.20161101-1]
-queuebot:#ubuntu-release- New: accepted ocplib-simplex [powerpc] (zesty-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted itamae [amd64] (zesty-proposed) [1.9.10-1]
-queuebot:#ubuntu-release- New: accepted tendermint-go-rpc [amd64] (zesty-proposed) [0.0~git20161021.0.e6e3853-1]
-queuebot:#ubuntu-release- New: accepted tendermint-go-config [amd64] (zesty-proposed) [0.0~git20160626.0.e64b424-1]
-queuebot:#ubuntu-release- New: accepted zendframework [source] (zesty-proposed) [1.12.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.175.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.3]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [source] (trusty-proposed) [2:2.99.910-0ubuntu1.7]
-queuebot:#ubuntu-release- New binary: zendframework [amd64] (zesty-proposed/none) [1.12.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.5~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (trusty-proposed) [1:2014.1.5-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.2 => 2.0.873+git0.3b4b4500-14ubuntu3.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu8.1 => 2.0.873+git0.3b4b4500-14ubuntu8.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-106.153] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-78.86~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-78.86~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-106.153]
<slangasek> tjaalton: what was your standard of review for the apparmor SRU that I see has been accepted?
<slangasek> infinity, bdmurray, stgraber: fyi ^^
<stgraber> slangasek: not sure if infinity forwarded that comment to you, but shortly after you left yesterday, we figured that this actually needs to be tested with 3.2, 3.13 and 4.4 as precise is technically still supported, so someone may well be upgrading from 12.04 to 14.04 (possibly on the way to 14.04) and so will wind up running the new apparmor userspace with a 3.2 kernel, albeit briefly
<stgraber> so need to ensure that we won't be getting LTS upgrade failures as a result of that
-queuebot:#ubuntu-release- New binary: apache2 [ppc64el] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
<tjaalton> slangasek: it was the newer upload, and didn't see anyone disapproving the backport itself
<slangasek> tjaalton: ok, I'm asking what your standard of review was; because there was some discussion here at sprint about some of the potential problems with this SRU, so I want to understand what review you've already done and what if anything we should catch up on
-queuebot:#ubuntu-release- New binary: apache2 [i386] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: apache2 [amd64] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: apache2 [s390x] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: apache2 [armhf] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: apache2 [powerpc] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
<tjaalton> slangasek: the discussion should've been added to the bug, and/or package dropped from the queue again until a clear concensus was reached. the package diff itself wasn't reviewable as it was a backport. I'll remember not to touch core package backports anymore ;)
<tjaalton> also, why do some diffs have also changes from the security uploads in them?
<tjaalton> again makes reviewing changes harder than it should be
<rbasak> Launchpad doesn't know what to diff against, AFAIK.
<rbasak> We have some plans to make reviews from the unapproved queue much easier using the git importer. I just need to implement.
<tjaalton> ok
<rbasak> Then you can view a diff against anything
<slangasek> tjaalton: I am asking you what your standard review has been *so that I know what we need to do to take it from here*.  It was a realtime discussion at the sprint and we did not get a chance to record anything in the bug
<slangasek> so I'm asking now what you've done, so I don't need to duplicate effort
<slangasek> I'm not saying you did anything wrong by reviewing it to your satisfaction, I'm saying we have additional context and want to get up to speed
-queuebot:#ubuntu-release- New binary: apache2 [arm64] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
<tjaalton> hang on
<tjaalton> having network issues
<tjaalton> browser froze :/
<tjaalton> slangasek: looked at the bug, noticed it mentioned #1628285 and that the older upload was dropped because of changes for that bug, and a new one uploaded once it was decided those were not good for 1404
-queuebot:#ubuntu-release- New: accepted apache2 [amd64] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [armhf] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [powerpc] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [s390x] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [arm64] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [ppc64el] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted apache2 [i386] (zesty-proposed) [2.4.23-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted zendframework [amd64] (zesty-proposed) [1.12.20+dfsg-1ubuntu1]
<slangasek> tjaalton: ok, thanks
<tjaalton> slangasek: I'll double-check the diff now
<xnox> Laney, i believe there was a dual intent in those s390x removals. it was not just about uninstalability, and not just about upstart, but to exclude/prevent ubuntu-desktop & ubuntu-touch because we do not support, nor want to build that, on s390x.
<xnox> slangasek hopefully can clarify that on https://code.launchpad.net/~xnox/unity-greeter/no-s390x/+merge/312912
<xnox> slangasek unless you want unity-greeter:s390x ?!
<slangasek> xnox: do not want
<slangasek> xnox: is that the answer you needed?
<slangasek> xnox: however - do not want but would not block
<xnox> Laney, ^
<Laney> ubuntu-desktop is already not built
<Laney> I don't think you want to go down the road of doing this at the individual package level
<Laney> (or if you do, don't pick on one package at a time)
<xnox> Laney, it's not in zesty, i do not want unity-greeter be stuck on bin new.
<xnox> i'm not creating the change to remove s390x; i'm maintaining the status quo compared with yakkety.
<xnox> (trying to)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-31.33] (core, kernel)
-queuebot:#ubuntu-release- New source: sgt-launcher (zesty-proposed/primary) [0.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.10.0-0ubuntu1 => 2.10.0-0ubuntu1.1] (openstack, ubuntu-server)
<infinity> xnox: There's some disagreement on the correctness of the status quo. :P
-queuebot:#ubuntu-release- Packageset: 568 entries have been added or removed
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.9.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: swift (xenial-proposed/main) [2.7.0-0ubuntu2 => 2.7.0-0ubuntu2.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.6 => 0.122ubuntu8.7] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.5 => 4.3.3-5ubuntu12.6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ifupdown [source] (xenial-proposed) [0.8.10ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.8-49-g9e904bb-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.6]
<rbasak> roaksoax, lamont, smoser, cyphermox: FYI ^
<lamont> rbasak: WOOT!
<lamont> thanks
-queuebot:#ubuntu-release- New sync: libphp-jpgraph (zesty-proposed/primary) [1.5.2-13]
-queuebot:#ubuntu-release- New sync: lnav (zesty-proposed/primary) [0.8.1-2]
<elopio> slangasek: bdmurray: I'm sorry but Sergio is telling me from his holidays to ping you about the snapcraft SRU. It's ready, can you give us a hand releasing it?
<elopio> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1646993
<ubot5> Ubuntu bug 1646993 in snapcraft (Ubuntu Yakkety) "[SRU] New stable micro release 2.23" [Undecided,Fix committed]
-queuebot:#ubuntu-release- New sync: opensips (zesty-proposed/primary) [2.2.2-2]
-queuebot:#ubuntu-release- New sync: ciphersaber (zesty-proposed/primary) [1.01-2]
-queuebot:#ubuntu-release- New sync: acorn (zesty-proposed/primary) [4.0.3-1]
<slangasek> elopio: sorry, we don't release SRUs on Friday to avoid getting into the situation of having a regression that no one is around to sort out; and on this particular Friday I'm flying back from a sprint in the morning so it would be an especially bad idea
<flocculant> xnox: xubuntu lost indicator-plugin since your change today, bug 1648889
<ubot5> bug 1648889 in xfce4-indicator-plugin (Ubuntu) "Removal of upstart patch breaks indicator-plugin" [Undecided,New] https://launchpad.net/bugs/1648889
#ubuntu-release 2016-12-10
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.9.0-10.11]
-queuebot:#ubuntu-release- Unapproved: tracker (yakkety-proposed/main) [1.10.0-1ubuntu1 => 1.10.2-0ubuntu0.1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- New binary: protobuf [s390x] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [ppc64el] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [amd64] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [powerpc] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [armhf] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [arm64] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [i386] (zesty-proposed/main) [3.0.0-9ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: dascrubber [amd64] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [ppc64el] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [arm64] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [i386] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [s390x] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [armhf] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dascrubber [powerpc] (zesty-proposed/universe) [0~20160601-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcs (yakkety-proposed/universe) [0.9.153-2 => 0.9.153-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcs (xenial-proposed/universe) [0.9.149-1 => 0.9.149-1ubuntu1] (no packageset)
<mapreri> pitti (or anybody relevant): could you please ignore the diffoscope/armhf regression?  One of our devs said it looks like a tiny change in readelf output breaking the tests, but nothing too interesting (also, somebody already ignored the ppc64el test?)
-queuebot:#ubuntu-release- New binary: lua-systemd [ppc64el] (zesty-proposed/universe) [0~git20160517-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-systemd [amd64] (zesty-proposed/universe) [0~git20160517-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-watson-developer-cloud [amd64] (zesty-proposed/universe) [0.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-zeep [amd64] (zesty-proposed/universe) [0.23.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-systemd [arm64] (zesty-proposed/universe) [0~git20160517-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-orchestrator [amd64] (zesty-proposed/universe) [0.3.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-to-absolute-glob [amd64] (zesty-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-duplexify [amd64] (zesty-proposed/universe) [3.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-through2-filter [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lua-systemd [amd64] (zesty-proposed) [0~git20160517-1]
-queuebot:#ubuntu-release- New: accepted lua-systemd [ppc64el] (zesty-proposed) [0~git20160517-1]
-queuebot:#ubuntu-release- New: accepted node-orchestrator [amd64] (zesty-proposed) [0.3.8-1]
-queuebot:#ubuntu-release- New: accepted node-to-absolute-glob [amd64] (zesty-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-zeep [amd64] (zesty-proposed) [0.23.0-1]
-queuebot:#ubuntu-release- New: accepted lua-systemd [arm64] (zesty-proposed) [0~git20160517-1]
-queuebot:#ubuntu-release- New: accepted node-through2-filter [amd64] (zesty-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-duplexify [amd64] (zesty-proposed) [3.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-watson-developer-cloud [amd64] (zesty-proposed) [0.22.0-1]
#ubuntu-release 2016-12-11
-queuebot:#ubuntu-release- New binary: bmusb [ppc64el] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [s390x] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [ppc64el] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [s390x] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [ppc64el] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [ppc64el] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-defaults [amd64] (zesty-proposed/main) [1:2.3.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: bmusb [i386] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [s390x] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [s390x] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [amd64] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [armhf] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [arm64] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [ppc64el] (zesty-proposed/universe) [6.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [powerpc] (zesty-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [amd64] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [armhf] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [s390x] (zesty-proposed/universe) [6.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [i386] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [arm64] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [arm64] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [amd64] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [powerpc] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [i386] (zesty-proposed/universe) [6.0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [armhf] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [armhf] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ndpi [powerpc] (zesty-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [amd64] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-after [amd64] (zesty-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [arm64] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-shelljs [amd64] (zesty-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vtgamma [amd64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hook-std [amd64] (zesty-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [amd64] (zesty-proposed/universe) [6.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [powerpc] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [arm64] (zesty-proposed/universe) [6.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: svxlink [amd64] (zesty-proposed/universe) [15.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: khard [i386] (zesty-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [armhf] (zesty-proposed/universe) [6.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cylc [powerpc] (zesty-proposed/universe) [6.11.2-1] (no packageset)
<bdmurray> elopio: He pinged, on Friday and we don't release SRUs to -updates b/c of the weekend.  We can do it on Monday.
-queuebot:#ubuntu-release- New binary: kicad [amd64] (zesty-proposed/universe) [4.0.4+dfsg2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bmusb [amd64] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [armhf] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [powerpc] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [s390x] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted cylc [arm64] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted cylc [powerpc] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted cylc [s390x] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted khard [arm64] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted khard [i386] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted khard [ppc64el] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [arm64] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [ppc64el] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted cylc [armhf] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted khard [amd64] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted khard [powerpc] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [i386] (zesty-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted cylc [ppc64el] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted khard [s390x] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted cylc [amd64] (zesty-proposed) [6.11.2-1]
-queuebot:#ubuntu-release- New: accepted khard [armhf] (zesty-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted kicad [amd64] (zesty-proposed) [4.0.4+dfsg2-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [arm64] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [i386] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [ppc64el] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted ndpi [amd64] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted ndpi [armhf] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted ndpi [powerpc] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted ndpi [s390x] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [amd64] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [powerpc] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted ndpi [arm64] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted ndpi [ppc64el] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [armhf] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted ndpi [i386] (zesty-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [s390x] (zesty-proposed) [6.0.10.0-1]
-queuebot:#ubuntu-release- New: accepted node-after [amd64] (zesty-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted node-hook-std [amd64] (zesty-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-defaults [amd64] (zesty-proposed) [1:2.3.3]
-queuebot:#ubuntu-release- New: accepted vtgamma [amd64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted node-shelljs [amd64] (zesty-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted svxlink [amd64] (zesty-proposed) [15.11-2]
-queuebot:#ubuntu-release- New binary: node-debug-fabulous [amd64] (zesty-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-unique-stream [amd64] (zesty-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [ppc64el] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [ppc64el] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [ppc64el] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [ppc64el] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [ppc64el] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: d3-tip.js [amd64] (zesty-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [i386] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-disconnect-wifi [amd64] (zesty-proposed/none) [3.22.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-system-monitor [amd64] (zesty-proposed/none) [31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-anzu [amd64] (zesty-proposed/none) [0.62-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-multi-monitors [amd64] (zesty-proposed/none) [0.00~git20160725.1.7390a66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-better-volume [amd64] (zesty-proposed/none) [0.0-git20161106.ff67408-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jqueryui [amd64] (zesty-proposed/universe) [1.12.1+dfsg-3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: dhcpcanon [amd64] (zesty-proposed/none) [0.1.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [i386] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [amd64] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: python-xattr [i386] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [amd64] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [arm64] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: node-package [amd64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [amd64] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [s390x] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [arm64] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [s390x] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [s390x] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [armhf] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: android-platform-tools-apksig [amd64] (zesty-proposed/none) [0.3+git154~gfdc6e98-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [armhf] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-whois-ip-perl [amd64] (zesty-proposed/none) [1.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [arm64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [s390x] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [armhf] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-ed25519 [amd64] (zesty-proposed/none) [0.0~git20160723.0.1f52c6f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-process [amd64] (zesty-proposed/none) [0.0~git20161130.0.226eb65-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [arm64] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-pom-view-restructured-perl [amd64] (zesty-proposed/none) [0.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [arm64] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-event-meter [amd64] (zesty-proposed/none) [0.0~git20160420.0.c9240a5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-ldap-sid-perl [amd64] (zesty-proposed/none) [0.001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-neovim [amd64] (zesty-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [armhf] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zfs-auto-snapshot [amd64] (zesty-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [armhf] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [s390x] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: rng-tools5 [i386] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [amd64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [amd64] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxlinuxprint [powerpc] (zesty-proposed/none) [1.1.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xattr [powerpc] (zesty-proposed/main) [0.9.1-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nixstatsagent [i386] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rambo-k [amd64] (zesty-proposed/none) [1.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-tools-analytics-library [amd64] (zesty-proposed/none) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nixstatsagent [powerpc] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jid [powerpc] (zesty-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rng-tools5 [powerpc] (zesty-proposed/none) [5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-intervaltree-bio [amd64] (zesty-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted android-platform-tools-analytics-library [amd64] (zesty-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted d3-tip.js [amd64] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted emacs-anzu [amd64] (zesty-proposed) [0.62-1]
-queuebot:#ubuntu-release- New: accepted android-platform-tools-apksig [amd64] (zesty-proposed) [0.3+git154~gfdc6e98-1]
-queuebot:#ubuntu-release- New: accepted dhcpcanon [amd64] (zesty-proposed) [0.1.8.2-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [amd64] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [armhf] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [powerpc] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [s390x] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-disconnect-wifi [amd64] (zesty-proposed) [3.22.14-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-system-monitor [amd64] (zesty-proposed) [31-1]
-queuebot:#ubuntu-release- New: accepted jid [arm64] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted jid [i386] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted jid [ppc64el] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted jqueryui [amd64] (zesty-proposed) [1.12.1+dfsg-3]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [arm64] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [ppc64el] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-multi-monitors [amd64] (zesty-proposed) [0.00~git20160725.1.7390a66-1]
-queuebot:#ubuntu-release- New: accepted jid [armhf] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted jid [s390x] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted libnet-whois-ip-perl [amd64] (zesty-proposed) [1.19-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [armhf] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [powerpc] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [s390x] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fxlinuxprint [i386] (zesty-proposed) [1.1.0+ds-1]
-queuebot:#ubuntu-release- New: accepted jid [amd64] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted libnet-ldap-sid-perl [amd64] (zesty-proposed) [0.001-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [arm64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [ppc64el] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-better-volume [amd64] (zesty-proposed) [0.0-git20161106.ff67408-1]
-queuebot:#ubuntu-release- New: accepted libpod-pom-view-restructured-perl [amd64] (zesty-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted jid [powerpc] (zesty-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted nixstatsagent [i386] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-debug-fabulous [amd64] (zesty-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New: accepted node-unique-stream [amd64] (zesty-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [amd64] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [armhf] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [powerpc] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [s390x] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [amd64] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [armhf] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [powerpc] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [s390x] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted node-package [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [arm64] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [ppc64el] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [arm64] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [ppc64el] (zesty-proposed) [5-1]
-queuebot:#ubuntu-release- New: accepted tendermint-ed25519 [amd64] (zesty-proposed) [0.0~git20160723.0.1f52c6f-1]
-queuebot:#ubuntu-release- New: accepted tendermint-go-process [amd64] (zesty-proposed) [0.0~git20161130.0.226eb65-1]
-queuebot:#ubuntu-release- New: accepted python-intervaltree-bio [amd64] (zesty-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rambo-k [amd64] (zesty-proposed) [1.21+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-neovim [amd64] (zesty-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted zfs-auto-snapshot [amd64] (zesty-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-xattr [i386] (zesty-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted tendermint-go-event-meter [amd64] (zesty-proposed) [0.0~git20160420.0.c9240a5-1]
-queuebot:#ubuntu-release- New: accepted rng-tools5 [i386] (zesty-proposed) [5-1]
#ubuntu-release 2017-12-04
-queuebot:#ubuntu-release- New binary: confuse [amd64] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: confuse [ppc64el] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: confuse [i386] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: confuse [s390x] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: confuse [arm64] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: confuse [armhf] (bionic-proposed/universe) [3.2.1+dfsg-2] (ubuntu-mate)
-queuebot:#ubuntu-release- New: accepted confuse [amd64] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted confuse [armhf] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted confuse [ppc64el] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted mame [amd64] (bionic-proposed) [0.192+dfsg.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted confuse [arm64] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted confuse [s390x] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted confuse [i386] (bionic-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted msxpertsuite [amd64] (bionic-proposed) [3.8.1-2]
-queuebot:#ubuntu-release- New: accepted marble [amd64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [armhf] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [ppc64el] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [arm64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [s390x] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [i386] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [amd64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [armhf] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [ppc64el] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [arm64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [s390x] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [i386] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kmailtransport [ppc64el] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [amd64] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [s390x] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-contacts [amd64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [i386] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [armhf] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-contacts [arm64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-contacts [i386] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-contacts [armhf] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted akonadi-contacts [amd64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-contacts [armhf] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-contacts [arm64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-contacts [i386] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kmailtransport [arm64] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kmailtransport [amd64] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [armhf] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [ppc64el] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [arm64] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [s390x] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [i386] (bionic-proposed) [17.08.3-0ubuntu1]
<acheronuk> ah, b*lls. I may have wanted that rejected :/
<acheronuk> ^^^ kmailtransport
<apw> acheronuk, not that i accepted it, you missed your window for that
<acheronuk> apw: I know. I was just looking at it as it was accepted. as we have another applications release before bionic is done, and a merge with debian in that, I guess I will now be resolving the issue then
<apw> if ti has no reverse-depends that are built against it it could likely be removed still if it is that broken
<acheronuk> apw: http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/17.08.3_bionic_retry_builds.pdf
<acheronuk> looks ok to do that
<acheronuk> reverse depends have not built against that version yet
<apw> acheronuk, so you are sure you want this gone, the version number will be dead
<acheronuk> ubuntu2 would not be a problem?
<apw> no problem with ubuntu2, ubuntu1 is consumed removed or not
<acheronuk> theres a delta to debian in terms of new package names (plugins) etc that someone added (not me) I would prefer gone
<apw> ok then i think we can justify ripping it till you can fix it properly
<acheronuk> thanks. makes less work for later
-queuebot:#ubuntu-release- New binary: rrdtool [s390x] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [amd64] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [ppc64el] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [i386] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [arm64] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: rrdtool [armhf] (bionic-proposed/main) [1.7.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted rrdtool [amd64] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rrdtool [armhf] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rrdtool [ppc64el] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rrdtool [arm64] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rrdtool [s390x] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rrdtool [i386] (bionic-proposed) [1.7.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.104-0ubuntu0.16.04.1]
<apw> ^ duplicate in the queue, rejected as per uploader
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.104-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: uvp-monitor (artful-proposed/universe) [2.2.0.315-0ubuntu1 => 2.2.0.316-0ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New source: uvp-monitor (xenial-proposed/primary) [2.2.0.316-0ubuntu1~16.04.1]
<mdeslaur> can someone please manually migrate openssl from bionic-proposed? the remaining ruby test failure is unrelated
 * apw looks
<apw> mdeslaur, concur that that is not in the bit of ruby that uses openssl and not in a test which is testing anything related to it
<mdeslaur> thanks
-queuebot:#ubuntu-release- New binary: kmailtransport [ppc64el] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [i386] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [s390x] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [amd64] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [armhf] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
<acheronuk> apw: that one is OK I hope (was in a ppa) ^^^
-queuebot:#ubuntu-release- New binary: kmailtransport [arm64] (bionic-proposed/universe) [17.08.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rtl8812au (xenial-proposed/universe) [4.3.8.12175.20140902+dfsg-0ubuntu2 => 4.3.8.12175.20140902+dfsg-0ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (artful-proposed) [0.12.8~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.8~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (xenial-proposed) [0.12.8~16.04.1]
-queuebot:#ubuntu-release- Unapproved: python2.7 (xenial-proposed/main) [2.7.12-1ubuntu0~16.04.2 => 2.7.12-1ubuntu0~16.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: python2.7 (zesty-proposed/main) [2.7.13-2ubuntu0.1 => 2.7.13-2ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.3-0ubuntu3.1 => 3:11.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Packageset: Added linux-azure-edge to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure-edge to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-oem to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-oem to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-signed-oem to kernel in xenial
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (artful-proposed) [0.32~17.10.1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [amd64] (bionic-proposed) [17.08.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [armhf] (bionic-proposed) [17.08.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [ppc64el] (bionic-proposed) [17.08.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [arm64] (bionic-proposed) [17.08.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [s390x] (bionic-proposed) [17.08.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [i386] (bionic-proposed) [17.08.3-0ubuntu2]
-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- Unapproved: unity (xenial-proposed/main) [7.4.5+16.04.20171116 => 7.4.5+16.04.20171201.3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (zesty-proposed) [2.7.13-2ubuntu0.2]
<Laney> the two unity-control-center in xenial/unapproved are the same, feel free to reject one
<Laney> biletoooo
-queuebot:#ubuntu-release- Unapproved: rejected unity-control-center [sync] (xenial-proposed) [15.04.0+16.04.20171130-0ubuntu1]
<apw> Laney, ^
<Laney> â¥
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.7-0ubuntu1 => 2:15.0.8-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (zesty-proposed/main) [1:8.1.1-0ubuntu1 => 1:8.1.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (zesty-proposed/main) [1:8.0.4-0ubuntu1 => 1:8.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New source: uvp-monitor (trusty-proposed/primary) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.2 => 0.32~16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (xenial-proposed) [2.7.12-1ubuntu0~16.04.3]
-queuebot:#ubuntu-release- Unapproved: iproute2 (artful-proposed/main) [4.9.0-1ubuntu2 => 4.9.0-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: iproute2 (xenial-proposed/main) [4.3.0-1ubuntu3.16.04.2 => 4.3.0-1ubuntu3.16.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: iproute2 (trusty-proposed/main) [3.12.0-2ubuntu1.1 => 3.12.0-2ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: iproute2 (zesty-proposed/main) [4.9.0-1ubuntu1 => 4.9.0-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.3-0ubuntu1 => 2:10.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [i386] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
<slangasek> Laney: welcome back
<Laney> hey slangasek
<Laney> cheers
<slangasek> Laney: so wrt LP: #1735860: a) cron mail is not actually going out, the newly deployed juju node gets rejected for relaying; b) there absolutely are nova instances that are stuck in an 'error' state that I'm able to clean from the commandline without admin intervention, but that the maintenance job does not clean up
<ubot5> Launchpad bug 1735860 in Auto Package Testing "autopkgtest-cloud should detect nova instances in ERROR state, attempt to clear them, and notify the admins" [Undecided,New] https://launchpad.net/bugs/1735860
<Laney> I get the cron mail ...
<slangasek> oh?
<Laney> give it 4 minutes and I'll give you a message ID
<slangasek> I haven't been receiving it, and /var/log/mail.log on autopkgtest-cloud-worker/3 is full of Relay access denied
<Laney> oh no wait I didn't delete the 1200 one
<Laney> Subject: Cron <ubuntu@juju-prod-ues-proposed-migration-machine-11> autopkgtest-cloud/tools/cloud-worker-maintenance
<Laney> WARNING:root:instance adt-bionic-i386-libfennec-lite-perl-20171203-025501 is in error state (message: {'code': 500, 'message': 'Unable to establish connection to
<Laney> +http://10.222.128.8:9696/v2.0/ports/ad3736bf-ee88-4753-92b3-9cd7f11960a4.json', 'created': '2017-12-03T03:15:35Z'}), deleting
<Laney> Message-ID: <cmu-lmtpd-3899624-1512390024-3@sloti24t05>
<slangasek> interesting
<slangasek> that looks suspiciously like one of the instances that I manually deleted last night
<Laney> I've never seen something able to be deleted on the n>1th attempt
<Laney> it always works on the first try or requires admin intervention IME
<Laney> so if we're seeing it again, would be good to have a look at it
<slangasek> yep.  are we sure there isn't a bug that's preventing the maintenance job from deleting /any/ of them? it says 'deleting' but maybe it isn't?
<Laney> not sure, but that would mean that https://git.launchpad.net/autopkgtest-cloud/tree/tools/cleanup-instances#n28 isn't working
<slangasek> fwiw, "give it 4 minutes" - I also cowboyed the cronjob to run at 20 */6,3 instead of at 0 */6 because of LP: #1735878
<ubot5> Launchpad bug 1735878 in Auto Package Testing "worker auto restarting should be handled by systemd unit, not by cronjob" [Undecided,New] https://launchpad.net/bugs/1735878
<slangasek> so we have another 20 minutes still
<Laney> fair enough
<slangasek> and now I'm trying to figure out why all the x86 runner units are ded when nova looks fine
<Laney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1730717 in lcy01 at least
<ubot5> Launchpad bug 1730717 in linux (Ubuntu Bionic) "Some VMs fail to reboot with "watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]"" [High,In progress]
<Laney> s_forshee got assigned to that today, poor him
<slangasek> random check shows autopkgtest@lgw01-25.service with normal-ish output until 2.5h ago, then nothing
<slangasek> ah, that's the soft lockup bug
<slangasek> frustrating that nothing useful goes to the journal in this case
<Laney> huh
<Laney> -25 *is* the soft lockup bug
<Laney> hadn't seen that in lgw01 before
<slangasek> and I see there are blind retries of failed autopkgtests this morning (crmsh s390x/ppc64el)
<Laney> for some reason journalctl -u <> -e stops before the end
<slangasek> hopefully no one's blindly retrying on x86 :P
<Laney> if you use that to get the timestamp and then journalctl -S that you can see further
<Laney> Dec 04 15:30:57 juju-prod-ues-proposed-migration-machine-11 sh[9637]: [[0;32m  OK  [0m] Reached target Shutdown.
<Laney> Dec 04 15:30:57 juju-prod-ues-proposed-migration-machine-11 sh[9637]: [  136.028454] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]
<slangasek> ah? how wonderful
-queuebot:#ubuntu-release- New binary: kf5-messagelib [arm64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
<Laney> -e --some-random-place-in-the-middle
<Laney> yeah we really need to get this bug solved
<apw> always fun to debug sometihng that late in day ...
<Laney> for now I'd put the maint job back to hourly
<Laney> got to run off, feel free to do that if anyone concurs
<Laney> see you
<slangasek> Laney: later
<slangasek> Laney: so I looked and can't find that this message-id ever hit mail.c.c for me
-queuebot:#ubuntu-release- Unapproved: accepted slic3r [source] (artful-proposed) [1.2.9+dfsg-6.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (zesty-proposed) [3:11.0.4-0ubuntu1]
<sil2100> coreycb: hey, I'm looking at the nova SRU you prepared for zesty and the diff is strange, it's quite big because it seems that in this release all '_' signs in the upstream source ChangeLog file got replaced with '\_', is that intentional?
<sil2100> coreycb: same for heat
<sil2100> coreycb: horizon and ceilometer were good so far
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (zesty-proposed) [1:8.1.2-0ubuntu1]
<coreycb> sil2100: i can check on that. they are that way in the upstream tar ball.
<coreycb> sil2100: i'll let you know what I hear
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.4-0ubuntu1]
<sil2100> coreycb: ok, I can accept those as those are just in the ChangeLogs, especially if you say that it's how it's in the official tarballs
<coreycb> sil2100: ok i think that is reasonable
<coreycb> sil2100: thanks
<sil2100> Wanted to know if it's just not something that got busted during repacking the tarballs or something
<Trevinho> sil2100: you still here?
<sil2100> Trevinho: yes, hello!
<Trevinho> sil2100: hey )
<Trevinho> :)
<Trevinho> sil2100: could you please sync unity, unity-control-center from the sru queue?
<Trevinho> sil2100: they were already put on proposed, but there was an issue with ucc changelog and I had to remove a commit from unity
<sil2100> Trevinho: which series?
<sil2100> xenial?
<Trevinho> sil2100: yes, xenial
<sil2100> Trevinho: ok, I can get to that once I'm done with nova and heat
<Trevinho> sil2100: they come from https://bileto.ubuntu.com/#/ticket/2841
<Trevinho> sil2100: thanks
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (zesty-proposed) [1:8.0.5-0ubuntu1]
<sil2100> Trevinho: hmmm, any plans on getting this fixed for zesty as well?
<sil2100> I guess it would be nice to have that for people that might be upgrading, on the other hand zesty will be EOL really soon so yeah
<sil2100> Trevinho: hmmm, for the unity sync
<sil2100> Trevinho: I see you're skipping tests for powerpc and there's no mention of it in the changelog
<slangasek> infinity: arm64 backlog cleared and x86 backlog clearing, if you want to claim a position in queue for glibc
<Trevinho> sil2100: oh, that was a change I had to do because suddently they stopped working, I thought it wasn't needed to mention..
<Trevinho> sil2100: should I readd it?
<Trevinho> :-(
<sil2100> ehhh, let's screw that ;)
<sil2100> It should and normally I'd reject, but since I have the context and Bileto re-uploads are quite bothersome, let's leave this
<sil2100> Trevinho: but for next time remember to mention such things, any change that's not a no-op should be mentioned in the changelog, as at one point one might start wondering why some tests were disabled
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (xenial-proposed) [7.4.5+16.04.20171201.3]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (xenial-proposed) [15.04.0+16.04.20171130-0ubuntu1]
<Trevinho> sil2100: thanks...
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.0-0ubuntu1 => 8.0.5.5-0ubuntu1] (no packageset)
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/verify-details/+merge/334709
<acheronuk> hi, would someone be kind enough to accpet the kf5-messagelib new binaries please? they are holding up one level of the KDE PIM build chain. thanks
-queuebot:#ubuntu-release- New binary: nq [ppc64el] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [ppc64el] (bionic-proposed/none) [0.9-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [ppc64el] (bionic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nq [s390x] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lbdb [amd64] (bionic-proposed/main) [0.45.3] (core)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [s390x] (bionic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [s390x] (bionic-proposed/none) [0.9-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nq [arm64] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nq [armhf] (bionic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [arm64] (bionic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [armhf] (bionic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [arm64] (bionic-proposed/none) [0.9-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [armhf] (bionic-proposed/universe) [0.9-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nq [amd64] (bionic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psst [amd64] (bionic-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nq [i386] (bionic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [i386] (bionic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dimred [amd64] (bionic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psst [i386] (bionic-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webmockr [amd64] (bionic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [i386] (bionic-proposed/universe) [0.9-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: terminaltables [amd64] (bionic-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ipred [amd64] (bionic-proposed/universe) [0.9-6-1] (no packageset)
#ubuntu-release 2017-12-05
<slangasek> LocutusOfBorg: it doesn't look like you've done much analysis of these rails autopkgtest failures before retrying them; the previous failures clearly show they require rack-test 0.7.0 but nothing is enforcing a versioned dep.  Is there an upload somewhere which I'm not seeing that will cause the retries to have the correct dep pulled in?
<slangasek> LocutusOfBorg: your coquelicot test trigger is also definitely wrong, and somehow my correct one got lost...
<slangasek> LocutusOfBorg: well, apparently I failed to ever queue it on i386, so that explains that
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [i386] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [amd64] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [s390x] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [ppc64el] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [armhf] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-sqlclient [arm64] (bionic-proposed/universe) [1.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [amd64] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [armhf] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [ppc64el] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [arm64] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [s390x] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted gnustep-sqlclient [i386] (bionic-proposed) [1.8.1-3]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [amd64] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [armhf] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [ppc64el] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [arm64] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [s390x] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ipred [i386] (bionic-proposed) [0.9-6-1]
-queuebot:#ubuntu-release- New: accepted nq [amd64] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted nq [armhf] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted nq [ppc64el] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted nq [arm64] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted nq [s390x] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted nq [i386] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [amd64] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [armhf] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [ppc64el] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [arm64] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [s390x] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dimred [i386] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted lbdb [amd64] (bionic-proposed) [0.45.3]
-queuebot:#ubuntu-release- New: accepted terminaltables [amd64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-webmockr [amd64] (bionic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [arm64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [i386] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted psst [amd64] (bionic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted psst [i386] (bionic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [amd64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [i386] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [armhf] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [arm64] (bionic-proposed/universe) [4:17.08.3-0ubuntu1] (kubuntu)
<oSoMoN> sil2100, good morning! re bug #1728072, the libreoffice SRU should be good to go
<ubot5> bug 1728072 in libreoffice-l10n (Ubuntu Artful) "[SRU] libreoffice 5.4.2 for artful" [Undecided,Fix committed] https://launchpad.net/bugs/1728072
<sil2100> oSoMoN: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.3]
<LocutusOfBorg> go perl go!
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [amd64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [armhf] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [arm64] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [i386] (bionic-proposed) [4:17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: akonadi-import-wizard [amd64] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-import-wizard [i386] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-import-wizard [arm64] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-import-wizard [armhf] (bionic-proposed/universe) [17.08.3-0ubuntu1] (kubuntu)
<sergiusens> slangasek I have reran the armhf tests 8 times and they keep failing on that DNS timeout issue; I am sort of getting tired of it tbh
-queuebot:#ubuntu-release- New source: opengcs (bionic-proposed/primary) [0.3.4+dfsg1-0ubuntu1]
<cpaelzer> hi, I miss something on dovecot not migrating in bionic-proposed it is a valid candidate in update_excuses for half a day now
<cpaelzer> would I see in update excuses if I missed a new component mismatch on the merge?
<cpaelzer> other ideas why it might just "hand around" for now?
<cpaelzer> arr I think I know
<cpaelzer> yep, http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_output.txt
<cpaelzer> the abi  bump in the api to dovecot antispam
<cpaelzer> sorry for the noise, working on it
-queuebot:#ubuntu-release- New: accepted akonadi-import-wizard [amd64] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-import-wizard [armhf] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-import-wizard [arm64] (bionic-proposed) [17.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-import-wizard [i386] (bionic-proposed) [17.08.3-0ubuntu1]
<slashd> Hi SRU, Could you please release "landscape-client" into -updates for Trusty, Xenial, Zesty and Artful ? I just changed one of the bugs (LP: #1208393) to verification-$RELEASE-done a minute ago. If you look in pending SRU page, it may not be updated yet, but all the verification-done tag are set.
<ubot5> Launchpad bug 1208393 in landscape-client (Ubuntu Artful) "add autoremove to Landscape" [Wishlist,Fix committed] https://launchpad.net/bugs/1208393
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20171025+dfsg1-0ubuntu1~17.10.0 => 20171129+dfsg1-0ubuntu1~17.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20171025+dfsg1-0ubuntu1~16.04.0 => 20171129+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20171025+dfsg1-0ubuntu1~14.04.0 => 20171129+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20171025+dfsg1-0ubuntu1~17.04.0 => 20171129+dfsg1-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New sync: haskell-hspec-smallcheck (bionic-proposed/primary) [0.4.2-1]
-queuebot:#ubuntu-release- New sync: haskell-smtp-mail (bionic-proposed/primary) [0.1.4.6-1]
-queuebot:#ubuntu-release- New sync: haskell-hspec-smallcheck (bionic-proposed/primary) [0.4.2-1]
-queuebot:#ubuntu-release- New sync: haskell-shell-conduit (bionic-proposed/primary) [4.6.1-1]
-queuebot:#ubuntu-release- New sync: haskell-hspec-smallcheck (bionic-proposed/primary) [0.4.2-1]
-queuebot:#ubuntu-release- New sync: haskell-smtp-mail (bionic-proposed/primary) [0.1.4.6-1]
-queuebot:#ubuntu-release- New sync: haskell-shell-conduit (bionic-proposed/primary) [4.6.1-1]
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [amd64] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [ppc64el] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [i386] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [s390x] (bionic-proposed/universe) [0.3.0-1] (no packageset)
<LocutusOfBorg> ok, with them the haskell stuff should be complete ^^
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [arm64] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yesod-auth-oauth2 [armhf] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [amd64] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [armhf] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [ppc64el] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [arm64] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [s390x] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yesod-auth-oauth2 [i386] (bionic-proposed) [0.3.0-1]
<LocutusOfBorg> the new packages are syncs due to haskell being blacklisted, so they should have been auto accepted
<sil2100> slashd: on it
<slashd> sil2100, thanks man
<cjwatson> LocutusOfBorg: not how auto-accept works
<cjwatson> auto-sync specifically arranges to accept new packages using its privileges; but when you do it yourself that doesn't happen
-queuebot:#ubuntu-release- New: rejected haskell-hspec-smallcheck [sync] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: rejected haskell-shell-conduit [sync] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: rejected haskell-hspec-smallcheck [sync] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: rejected haskell-smtp-mail [sync] (bionic-proposed) [0.1.4.6-1]
<cjwatson> accepted now anyway
<sil2100> slashd: regarding https://bugs.launchpad.net/landscape/+bug/1208393 <- the tester mentions using packaging from landscape/lds-trunk for testing, does he mean he tested the packages from that PPA? I would suppose we need it tested using the packages in -proposed, no?
<ubot5> Launchpad bug 1208393 in landscape-client (Ubuntu Artful) "add autoremove to Landscape" [Wishlist,Fix committed]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [sync] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [sync] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [sync] (bionic-proposed) [4.6.1-1]
<sil2100> slashd: I don't remember the landscape-client releases to be binary copies from a PPA
<sil2100> slashd: how does that PPA work? Is it somehow special?
<sil2100> slashd: (e.g. does landscape use this PPA or something like that?)
<slashd> sil2100, hmmm I havent look at the details for this one, as andreas did the upload ... let me check if I can find the information
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [i386] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [s390x] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [amd64] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [ppc64el] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [ppc64el] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [i386] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [ppc64el] (bionic-proposed/none) [4.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [s390x] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
<sil2100> slashd: thanks! Poking you as you switched the bug to verification-done
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [amd64] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [armhf] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hspec-smallcheck [arm64] (bionic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [i386] (bionic-proposed/none) [4.6.1-1] (no packageset)
<slashd> sil2100, yeah I just did the paperwork on this one to help my colleagues
<slashd> sil2100, will see if I can find the detail for you
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [amd64] (bionic-proposed/none) [4.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [arm64] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [s390x] (bionic-proposed/none) [4.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-smtp-mail [armhf] (bionic-proposed/none) [0.1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [amd64] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [armhf] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [ppc64el] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [amd64] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [armhf] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [ppc64el] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [arm64] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [s390x] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [i386] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-hspec-smallcheck [i386] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [s390x] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-smtp-mail [arm64] (bionic-proposed) [0.1.4.6-1]
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [armhf] (bionic-proposed/universe) [4.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-shell-conduit [arm64] (bionic-proposed/universe) [4.6.1-1] (no packageset)
<cjwatson> LocutusOfBorg: remember to let us know when we can unblacklist ghc and haskell-* ...
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [amd64] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [armhf] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [ppc64el] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [arm64] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [s390x] (bionic-proposed) [4.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-shell-conduit [i386] (bionic-proposed) [4.6.1-1]
<slashd> sil2100, ppa:landscape/lds-trunk is the daily ci build for landscape
<sil2100> slashd: I would prefer if we're testing the actual packages that are going to be released to -updates
<sil2100> slashd: since there can always be things like unsatisfied deps in the PPA, virtualized builders etc.
<sil2100> slashd: when testing an SRU the packages under test should be the packages that are in -proposed, not 'source equivalents' from somewhere else
<slashd> sil2100, AFAIK the verif has been done using the package found in the archive and not the PPA, the PPA was pre-sru.
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.5-0ubuntu1.1 => 2.0.5-0ubuntu1.2] (ubuntu-server)
<cjwatson> coreycb: would you like to sanity-check my upload above, fixing bug 1736454 (debdiff in bug)?
<ubot5> bug 1736454 in python-pylxd (Ubuntu Xenial) "pylxd cannot start containers with LXD 2.0.11" [Critical,In progress] https://launchpad.net/bugs/1736454
<cjwatson> stgraber: ^- FYI
<sil2100> slashd: could you double-confirm that? The comment says otherwise
<slashd> sil2100, yep I just ask the support guy who did the verification for most bugs
<slashd> sil2100, he didn't know the existence of the ppa
<slashd> davecore, can you confirm for sil2100 that you the archive for the lds-client testing ?
<slashd> you use ^
<sil2100> slashd: the testing person was Simon for this bug
<coreycb> jamespage: you may want to review cjwatson's pylxd patch. you're more familiar with that code.
<sil2100> slashd: Simon Poirier
<slashd> sil2100, oh ok for lp: #1208393
<ubot5> Launchpad bug 1208393 in landscape-client (Ubuntu Artful) "add autoremove to Landscape" [Wishlist,Fix committed] https://launchpad.net/bugs/1208393
<slashd> sil2100, too many ppl involve in this SRU, give me a few minutes to reach out Simon
<slashd> sil2100, he used the archive for the client, the ppa for the server.
<sil2100> Ok, the comment was misleading then
<slashd> sil2100, sorry I didn't release you were talking about a specific bug, since there is 4 of them in this SRU
<sil2100> slashd: I pasted the bug link in my original question above ;)
<slashd> sil2100, yeah my bad, I didn't see it
<sil2100> Anyway, all good, it's all clear now
<slashd> sil2100, great thanks
<jamespage> coreycb, cjwatson: that looks fine to me - its a backport of some improvements made in later releases after all
<coreycb> jamespage: cool thanks
<ahasenack> slashd: sil2100 are you ok wrt to that lds-trunk ppa thing? Did you understand what was going on?
<slashd> ahasenack, you basically did a binary copy or something ? instead of uploading the sources.change as we normally do
<ahasenack> no
<slashd> ahasenack, then I didn't get it lol
<ahasenack> slashd: from what I understood, sil2100 was concerned that the client package that was used for testing #1208393 came from lds-trunk ppa, and not proposed
<slashd> ahasenack, yeah got that, but I think I also saw him taking about a ppa copy
<ahasenack> slashd: that's something you have to ask the tester about. Exactly what he did. But given the bug, I *think* he meant that he used the *server* from lds-trunk ppa, because there is no released server yet that has that feature the bug addresses
<slashd> ahasenack, ok got it now
<ahasenack> slashd: but that lds-trunk ppa also has client packages
<ahasenack> so a mistake could have been made by the tester and it should be checked
<ahasenack> the lds-trunk client packages have a higher version than the ones in proposed
<cjwatson> jamespage: thanks
<slashd> ahasenack, make total sense thanks I didn't see it that way at first.
<cjwatson> sil2100: would you mind looking at python-pylxd/xenial?  it'd be nice to get moving on unblocking LP buildd images
<sil2100> slashd, ahasenack: from slashd's last comment regarding this bug it seemed as if he confirmed with Simon that he only used the server packages from the PPA and the client from the archive, which is what I wanted to know
<ahasenack> ok then
<sil2100> ahasenack: as his testing comment was misleading and I originally understood it as if he used only the PPA
<sil2100> (Simon's testing comment)
<ahasenack> sil2100: understood
<sil2100> But all is good and published now
<slashd> sil2100, yep I think I misread and misunderstood your original point.
<slashd> sil2100, ahasenack thanks
 * slashd need coffee
<ahasenack> fwiw, I did that test pre-upload
<ahasenack> that's how I wrote it
<sil2100> cjwatson: sure
<sil2100> cjwatson: on it now
<cjwatson> ta
<sil2100> cjwatson: I like smooth SRUs like this!
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (xenial-proposed) [2.0.5-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [156-1~ubuntu17.10.1 => 157-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [156-1~ubuntu17.04.1 => 157-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [156-1~ubuntu16.04.1 => 157-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (artful-proposed) [20171129+dfsg1-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20171129+dfsg1-0ubuntu1~17.04.0]
<cjwatson> sil2100: \o/, thanks
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20171129+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20171129+dfsg1-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New binary: muchsync [ppc64el] (bionic-proposed/none) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [ppc64el] (bionic-proposed/none) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [arm64] (bionic-proposed/none) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [s390x] (bionic-proposed/none) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [s390x] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: muchsync [armhf] (bionic-proposed/none) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [armhf] (bionic-proposed/none) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: muchsync [arm64] (bionic-proposed/none) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [ppc64el] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: muchsync [s390x] (bionic-proposed/none) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [arm64] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [armhf] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu1 => 2.02-2ubuntu2] (core)
<stgraber> cjwatson: crap
<stgraber> cjwatson: I'm really annoyed by pylxd freaking out every time a new optional field shows up... though I'm also confused as to how new fields were introduced in 2.0.11
<stgraber> cjwatson: oh, great, you backported the change to no longer freak out on new fields, at least that won't bite us again then :)
<cjwatson> right, should hopefully help
<stgraber> grabbing some food, then will re-read the change very closely and then let the SRU out without the normal wait period as that's a very much needed fix
<cjwatson> stgraber: I'm waiting for it to publish so I can test it
-queuebot:#ubuntu-release- New binary: condor [s390x] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: condor [ppc64el] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
<cjwatson> stgraber: bug is v-done-xenial now
<stgraber> thanks!
<cjwatson> stgraber: (there are still some UserWarnings, but they're ignorable IMO)
<stgraber> cjwatson: released to -updates
-queuebot:#ubuntu-release- New binary: condor [armhf] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: condor [arm64] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
<sil2100> stgraber: thanks!
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.9 => 0.122ubuntu8.10] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.9 => 0.103ubuntu4.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [157-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [157-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [157-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.14 => 2.02~beta2-36ubuntu3.15] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.6 => 3.20.5-0ubuntu0.16.04.7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3.17.04.7 => 3.22.7-0ubuntu3.17.04.8] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [amd64] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [i386] (bionic-proposed/main) [1.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted libcdio [amd64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [armhf] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [ppc64el] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [arm64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [s390x] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [i386] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: muchsync [amd64] (bionic-proposed/universe) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [i386] (bionic-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-shortcut-viewer [amd64] (bionic-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: muchsync [i386] (bionic-proposed/universe) [4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [amd64] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [armhf] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [ppc64el] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [arm64] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [s390x] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted deepin-shortcut-viewer [i386] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted muchsync [amd64] (bionic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted muchsync [armhf] (bionic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted muchsync [ppc64el] (bionic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted muchsync [arm64] (bionic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted muchsync [s390x] (bionic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted muchsync [i386] (bionic-proposed) [4-1]
<slangasek> acheronuk: you working on unblocking akonadi-contacts (kdepim autopkgtest regressions)?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-19.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-42.46] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-103.126] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-137.186] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-42.46~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.13.0-19.22~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-103.126~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.14.0-11.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: mailman-suite [amd64] (bionic-proposed/universe) [0+20170523-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rebulk [amd64] (bionic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog-any-adapter-tap-perl [amd64] (bionic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: condor [amd64] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mailman-hyperkitty [amd64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
<tsimonq2> slangasek: We're tag teaming as he's in the UK and I'm in the US (we both stay up late :P)
<slangasek> tsimonq2: ok, so in any event someone's on it
<tsimonq2> slangasek: right
-queuebot:#ubuntu-release- New: accepted liblog-any-adapter-tap-perl [amd64] (bionic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted mailman-suite [amd64] (bionic-proposed) [0+20170523-1]
-queuebot:#ubuntu-release- New: accepted mailman-hyperkitty [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-rebulk [amd64] (bionic-proposed) [0.9.0-1]
 * tsimonq2 loves when I can just cherrypick things like this https://github.com/KDE/kdepim-addons/commit/1e9fa3c3173f61075ec4d5edc1ef2087910b5c39#diff-612699dd483e72931abd60ff31e8d943 :D
-queuebot:#ubuntu-release- Unapproved: fwupdate (xenial-proposed/main) [0.5-2ubuntu5 => 0.5-2ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate-signed (xenial-proposed/main) [1.11.1 => 1.11.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu2 => 2.02-2ubuntu2] (core)
<RAOF> What has been happening with pulseaudio in xenial-proposed?!
<acheronuk> slangasek: yes, I only got around to retrying most earlier, as so many of them need large parts of the rest of that version of the stack to test against
<acheronuk> can now start solving remaining issues
-queuebot:#ubuntu-release- New binary: condor [i386] (bionic-proposed/universe) [8.6.8~dfsg.1-1] (no packageset)
<tsimonq2> slangasek: Hey so with kdepim-addons the problems are with the tests itself, not the code, as shown in https://github.com/KDE/kdepim-addons/commit/379da and https://github.com/KDE/kdepim-addons/commit/1e9fa and https://github.com/KDE/kdepim-addons/commit/e4849 -- I could certainly include these patches but these are applied by default in the next upstream release. Want a new upload or can you
<tsimonq2> override?
<tsimonq2> (those failures should directly correspond to the unit tests being fixed in all three of those commits)
<tsimonq2> Now, I'm still looking at kdepim-runtime... but that's a start I guess ;)
-queuebot:#ubuntu-release- New: accepted condor [amd64] (bionic-proposed) [8.6.8~dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted condor [i386] (bionic-proposed) [8.6.8~dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted condor [arm64] (bionic-proposed) [8.6.8~dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted condor [ppc64el] (bionic-proposed) [8.6.8~dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted condor [armhf] (bionic-proposed) [8.6.8~dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted condor [s390x] (bionic-proposed) [8.6.8~dfsg.1-1]
<tsimonq2> slangasek: Same case with kdepim-runtime, except they decided to fix all the autotests we're seeing failures for in one commit: https://github.com/KDE/kdepim-runtime/commit/8b7e7
<tsimonq2> slangasek: (that should allow a couple things to get unstuck as those are blocking tests on several packages)
<tsimonq2> slangasek: In fact, I stand corrected, *everything* that's blocked in proposed related to the KDE PIM stack should migrate
<acheronuk> slangasek: I would also note that on akonadi-calendar/4:17.08.3-0ubuntu1, britney again initially triggered tests on ppc64el/s390x, despite no binaries being produced on that
<acheronuk> same with libkf5eventviews/4:17.08.3-0ubuntu1
<acheronuk> onlt on tests against themselves, so I still don't know why britney gets confused on that
<tsimonq2> acheronuk: That's because those two arches are still built, but they don't produce binaries and are depwait
<tsimonq2> Might be worth it to tell it to stop that :P
<acheronuk> but as before, if those could be ignored on those archs, then thanks, as certainly have no way of fixing those
<tsimonq2> Right
<acheronuk> tsimonq2: no, as quite a few of PIM are the same, and don't do that :P
<acheronuk> tsimonq2: have discussed this before with release team, and there is something odd with britney going on
<tsimonq2> acheronuk: Got an example?
#ubuntu-release 2017-12-06
<acheronuk> tsimonq2: looks like maybe now britney has wrongly tried against most over a few releases, and there are none left running and not ignored. however, this was discussed we me and slangasek and I think Laney on here before, who both said britney should be triggering
<tsimonq2> ok
<acheronuk> tsimonq2: I'm too tired to grep logs, but the discussions are somewhere in those for this channel
<acheronuk> *both said britney should NOT be triggering
<acheronuk> tsimonq2: 2017-07-01:[20:01] <slangasek> acheronuk: hint added; however, it is unclear to me why this kdepim-addons/s390x test was triggered, given that kdepim-addons produces no binaries on s390x, so that's probably a bug.  (I did have a hint for kdepim-addons/s390x in place already, and then I dropped it once things migrated
<acheronuk> tsimonq2: shoudl not have looked so hard. kdepim-addons is an example. LOL
<tsimonq2> acheronuk: hah
<acheronuk> tsimonq2: spuriously triggers on those on itsekf: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdepim-addons
<acheronuk> but NOT on most other packages it triggers against
<acheronuk> as said, some britney oddness
 * acheronuk is tired as his typing is going haywire
<acheronuk> more haywire than usual, anyway
<slangasek> tsimonq2: upload to cherry-pick those test fixes is definitely preferred, please
<tsimonq2> slangasek: Alright.
<slangasek> if you told me that having to fix it was going to set back the migration by days and risk entangling with other transitions, I might make an exception; but all other things being equal it's always better to keep a green baseline
<acheronuk> tsimonq2: go for it then
<tsimonq2> Ok
<acheronuk> tsimonq2 is going for kubuntu-dev, so needs the practice :P
 * acheronuk hides
<RAOF> bdmurray: Are you doing a late shift? :)
<tsimonq2> RAOF: Hey! Around at all to talk about the Lubuntu SRUs?
<RAOF> tsimonq2: Yes!
<tsimonq2> RAOF: So what happened here is that I thought that the latest lubuntu-meta was accepted adding a dep on pavucontrol *before* everything was published
<tsimonq2> RAOF: Turns out it wasn't
<tsimonq2> RAOF: I thought I hadn't made the upload at all, so I made another upload
<tsimonq2> RAOF: But the upload with the new bug number got rejected in favor for this one that was never accepted
<tsimonq2> RAOF: tl;dr some way or another we need a new lubuntu-meta in -updates adding pulseaudio because at this point it's regression-update tagged
<tsimonq2> s/pulseaudio/pavucontrol/
<RAOF> It would have been clearer to file a second bug for the update regression. :)
<RAOF> But, now that we're hereâ¦
<tsimonq2> There *was* one
<tsimonq2> That upload got rejected in favor of this one
<tsimonq2> https://bugs.launchpad.net/ubuntu/xenial/+source/lubuntu-meta/+bug/1685598
<ubot5> Launchpad bug 1685598 in lubuntu-meta (Ubuntu Xenial) "Clicking 'Sound Settings' in Lubuntu is a no-op " [Critical,In progress]
<RAOF> Urgh.
<tsimonq2> My thought exactly.
<RAOF> (With a side order of: why didn't the acceptance of 0.65.3 get noted on the bug?)
<tsimonq2> This has been a bug caused by Firefox completely removing ALSA support that's been a thing since *August*. Please oh please can we just get this over with already? :)
<RAOF> Ok, so: has 0.65.3 been tested? It's been accepted into -proposed.
<tsimonq2> Yes.
<tsimonq2> It's been tested.
<tsimonq2> I tested it on a fresh install as soon as it was accepted.
<RAOF> Sold! To the man in the silly hat.
<tsimonq2> Thanks a bunch!
<RAOF> In general, feel free to ping me on my SRU day ð¸
<tsimonq2> Alright, thanks.
<tsimonq2> RAOF: Could I get that childsplay SRU processed please?
<tsimonq2> (I plan on using as future reference for new packagers, that's why this 3 year old bug finally gets a patch :P)
 * RAOF looks
<wxl> something's funky with d-i it seems? https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1736309
<ubot5> Launchpad bug 1736309 in debootstrap (Ubuntu) "installer failed missing dpkg_1.19.0.4ubuntu1_amd64.deb" [Undecided,New]
<RAOF> An SRU to trusty ?!
<tsimonq2> RAOF: Yes. :P
-queuebot:#ubuntu-release- Unapproved: accepted childsplay [source] (trusty-proposed) [1.6-1ubuntu0.1]
<tsimonq2> RAOF: Thanks.
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (bionic-proposed/universe) [1.22.1+dfsg1+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (bionic-proposed/universe) [1.22.1+dfsg1+llvm-0ubuntu2] (no packageset)
 * tsimonq2 gets a bit retry-happy now that kdepim-addons is uploaded
<tsimonq2> All done pressing the retry button. :P
<tsimonq2> Hopefully things migrate now.
<slangasek> doko: so, libcdio; API-breaking, about half of the revdeps ftbfs?
<doko> slangasek: looking at that today ...
<slangasek> doko: ok. I've just uploaded vcdimager, which may also fix xine-lib-1.2 and vlc
<acheronuk> tsimonq2: did you have a chance to try those PIM test fixes?
<acheronuk> slangasek: can kdepim-addons (add ppc64el to existing hint), akonadi-calendar, and libkf5eventviews be ignored on ppc64el/s390x as mentioned earlier in the miidle of me and tsimonq2 talking?
<acheronuk> or apw if you are about this early ^^^
<slangasek> acheronuk: I don't see an existing hint for kdepim-addons, and kdepim-addons/ppc64el is "always-failed" so doesn't need a hint.  Did you mean kdepim-addons/s390x, or something else?
<acheronuk> slangasek: yes, I meant add s390x. sorry. got it the wrong way around
<slangasek> acheronuk: added
<acheronuk> appreciated. thanks
<acheronuk> slangasek: damn kdepim-runtime/4:17.08.3-0ubuntu1 is the same and needs one as well. sorry. did you or anyone ever work out why these are being triggered initially when there are no binaries?
<acheronuk> or just kdepim-runtime generally for ppc64el/s390, as looks like tsimonq2 has not uploaded the fix for the other architectures yet :/
<acheronuk> I really wish KDE would stop coding stuff to require QtWebEngine. Grr.
 * doko discards his vcdimager changes ...
-queuebot:#ubuntu-release- New binary: dipy [s390x] (bionic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dipy [ppc64el] (bionic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dipy [amd64] (bionic-proposed/universe) [0.13.0-2] (no packageset)
<doko> did something change with openGL on arm64 recently?
-queuebot:#ubuntu-release- New binary: rustc [armhf] (bionic-proposed/universe) [1.22.1+dfsg1+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dipy [i386] (bionic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dipy [arm64] (bionic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (bionic-proposed/universe) [1.22.1+dfsg1+llvm-0ubuntu2] (no packageset)
<doko> chrisccoulson: not accepting rustc, ftbfs on i386
-queuebot:#ubuntu-release- New binary: dipy [armhf] (bionic-proposed/universe) [0.13.0-2] (no packageset)
<LocutusOfBorg> doko, yes, e.g. qtbase and gl stuff changed IIRC
<LocutusOfBorg> tsimonq2, ^^^
<LocutusOfBorg> but I don't remember how :)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.13.0-19.22~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-103.126]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-42.46~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-19.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-137.186]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-103.126~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-42.46]
-queuebot:#ubuntu-release- New: accepted dipy [amd64] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted dipy [armhf] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted dipy [ppc64el] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted dipy [arm64] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted dipy [s390x] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted dipy [i386] (bionic-proposed) [0.13.0-2]
<cpaelzer> LocutusOfBorg: you were on the last merge of curl - I think I'd poke on the next one as I need it for some work on nghttp2 anyway
<cpaelzer> LocutusOfBorg: I added myself in mom, is it ok if I grab that one?
<cpaelzer> LocutusOfBorg: also any known-hurdles from your last merge?
<LocutusOfBorg> cpaelzer, please steal, but please make it migrate before merging
<LocutusOfBorg> because of $security updates
<LocutusOfBorg> this is why I didn't merge it yet
<cpaelzer> hmm - checking where it doesn't migrate ...
<cpaelzer> hmm - I love earning extra tasks :-)
<cpaelzer> will take a look - thanks for the info LocutusOfBorg
<cpaelzer> I can concurrently test the new thing from ppas
<cpaelzer> LocutusOfBorg: would you be willing to review the merge once done - should be a trivial one as it looks right now ?
<cpaelzer> mdeslaur: if you have further info why this might fail to migrate let us know
<cpaelzer> mdeslaur: all CVEs would be included in the latest merge
 * cjwatson fixes ubuntu.bionic/STRUCTURE in response to several overnight image build failures
<chrisccoulson> doko, a rebuild will probably "fix" that. There's an issue where rustc crashes randomly on the builders but not locally
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.24 => 2.408.25] (desktop-core)
<cpaelzer> LocutusOfBorg: I got to look at curl since I'm about to pull nghttp2 into main
<cpaelzer> LocutusOfBorg: but I saw that the new merge would bump libcurl-gnutls 4.4 -> 4.5 - I'd not want to fuse that with the nghttp2 enablement
<cpaelzer> LocutusOfBorg: so I will try to get the current one to migrate and then for now just do the enablement
<cpaelzer> leaving the actual merge open for now
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [s390x] (bionic-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [ppc64el] (bionic-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [amd64] (bionic-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [i386] (bionic-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [armhf] (bionic-proposed/universe) [3.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1010.11] (kernel)
-queuebot:#ubuntu-release- New binary: cairo-dock-plug-ins [arm64] (bionic-proposed/universe) [3.4.1-2] (no packageset)
<mdeslaur> cpaelzer, LocutusOfBorg: looks like an unrelated test failure in casync
<mdeslaur> cpaelzer, LocutusOfBorg: it can get manually promoted I guess
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [amd64] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [armhf] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [ppc64el] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [arm64] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [s390x] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted cairo-dock-plug-ins [i386] (bionic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1010.11]
<cpaelzer> mdeslaur: I came to the same conclusion
<cpaelzer> mdeslaur: test history also looks that way failing/not-failing for no apparent reason
<cpaelzer> I wanted to run on a s390x system manually to be sure before asking to promote thou
<cpaelzer> which is WIP atm
<mdeslaur> cpaelzer: I didn't ask to get it migrated because last time I looked there were still running tests
<cpaelzer> mdeslaur: I fixed the last remaining regression
<cpaelzer> mdeslaur: just hours ago
<mdeslaur> cool
<cpaelzer> now only casync is left
<cpaelzer> once I'm confident engouh (by manual test) I'll ask for the promotion
<cpaelzer> the other one was a flaky network-manager test
<mdeslaur> can someone migrate samba too? the remaining test is unrelated also.
<cpaelzer> so no big magic involved in fixing that
<cpaelzer> mdeslaur: the remaining samba fail looks like no ipv4 was available
<cpaelzer> mdeslaur: do our testbeds have (sometimes) only ipv6 recently?
<mdeslaur> I don't know, I don't think so
<cpaelzer> but I agree - the history of it looks like the issue you face was thre before the samba change http://autopkgtest.ubuntu.com/packages/gvfs/bionic/ppc64el
-queuebot:#ubuntu-release- Unapproved: accepted pythonqt [source] (xenial-proposed) [3.0-1ubuntu1.16.04.2]
<cpaelzer> ok casync really works well outside the testbed on LP - http://paste.ubuntu.com/26124829/
<cpaelzer> Therby I'd ask the release team to promote curl curl/7.55.1-1ubuntu3 in bionic-proposed
<cpaelzer> I also see history on this test is on most arches already ignored failure
<cpaelzer> I'd almost assume this got a blocker now that s390x uses VMs
<cpaelzer> ok it really is marked as that, just not on s390x yet
-queuebot:#ubuntu-release- Unapproved: accepted lime-forensics [source] (xenial-proposed) [1.7.2-1ubuntu1]
<cpaelzer> so might I ask to add s390x to the list that is currently masked at http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/vorlon#L89
<cpaelzer> slangasek: infinity: apw: ^^ ?
<apw> cpaelzer, what is the reasoning behind that
<LocutusOfBorg> apw, I retried against the release version, regressed in release
<LocutusOfBorg> probably due to the lxc changes in s390x containers
<cpaelzer> exactly
<cpaelzer> slangasek: already masked it for those reasons on all other arches that woudl run it before
<cpaelzer> that is the link above to hints
<cpaelzer> and I ran it on s390x in a container, it runs just fine outside of the LP-autotest infrastructure
<cpaelzer> so it is a) false positive and b) no real regression
<cpaelzer> and c) masked for the same reasons on other arches
<cpaelzer> at least that is how read the breadcrumbs I found - there is the chance that slangasek might remember more from his changes like http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2473
<cpaelzer> http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2570
<cpaelzer> ...
<cpaelzer> it works in a loop on my s390x box
<cpaelzer> but test history says arch isn't even important as it fails the same way everywhere
<cpaelzer> running in autopkgtest on x86 now in case I could find something to fix, but I don't see anything actionable yet
<LocutusOfBorg> slangasek, cdio->vlc is "fixed" I think
<LocutusOfBorg> I see upstream removed that plugin because deprecated, so I removed it and reuploaded
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.14.0-11.13]
<doko> LocutusOfBorg: still ftbfs
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.10]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.10]
<cpaelzer> apw: LocutusOfBorg: actually I think I have a real fix for this casync test issue
<cpaelzer> apw: you didn't override it yet did you?
<apw> cpaelzer, not yet indeed
<cpaelzer> ok, then I'll try to solve it the right way
<LocutusOfBorg> doko, I know, working on it, the first failure is fixed, the upnp one is tricky
-queuebot:#ubuntu-release- New binary: rustc [i386] (bionic-proposed/universe) [1.22.1+dfsg1+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (bionic-proposed) [1.22.1+dfsg1+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (bionic-proposed) [1.22.1+dfsg1+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (bionic-proposed) [1.22.1+dfsg1+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (bionic-proposed) [1.22.1+dfsg1+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (bionic-proposed) [1.22.1+dfsg1+llvm-0ubuntu2]
<chrisccoulson> doko, heh, a rebuild of rust fixed it: https://launchpad.net/ubuntu/+source/rustc/1.22.1+dfsg1+llvm-0ubuntu2/+build/13820599
<chrisccoulson> not sure what to do about this - it's a regular issue and one that I can't reproduce locally. It can take multiple attempts to get a successful build
<cyphermox> could someone please review grub2 amd64 in the bionic NEW queue? it needs manual review for EFI signing.
<apw> cyphermox, another one so soon ... and it is in the Unapproved queue
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu2]
<cyphermox> sorry, indeed unapproved queue
<cyphermox> what do you mean another one so soon?
<cyphermox> apw: ^
<cyphermox> also, thanks :)
<apw> cyphermox, there was one on there this mornign
<apw> i thought
<cyphermox> ah
<slangasek> LocutusOfBorg: hmm, there was no need to diverge from Debian to disable the vcdimager plugin when I had just fixed vcdimager
<LocutusOfBorg> mmm thanks, not sure how I missed that
<LocutusOfBorg> reverting that part
<LocutusOfBorg> slangasek, can I force sync it?
<slangasek> cpaelzer: casync/s390x hint added
<slangasek> cpaelzer: but a real fix is welcome and not exclusive
<LocutusOfBorg> I mean, can I force sync vcdimager?
<LocutusOfBorg> doko, uploaded it (with a previous wrong changelog entry, but nevermind :) )
<slangasek> LocutusOfBorg: you don't need my permission to
<slangasek> you just need to be correct ;)
<LocutusOfBorg> lovely :) thanks
<cpaelzer> slangasek: actually the real fix is in b-proposed
<cpaelzer> slangasek: if it tests fine can I ping you to remove the hints then?
<LocutusOfBorg> anyhow, that plugin will go away in the next vlc release, so my "removal" wasn't entirely wrong... :) but yeah, fixing vcdimager is really better
<slangasek> cpaelzer: you shouldn't spend your time to ping me to remove the hints
<cpaelzer> but just remove them?
<slangasek> cpaelzer: since the hints are tied to package version, they are no-ops for all new tests once the new casync is in bionic
<cpaelzer> oh well the hint is evrsioned isn't it - it might work as is
<cpaelzer> ack, we mean the same
<cpaelzer> ok, great, thanks slangasek
<slangasek> cpaelzer: furthermore, unless you re-trigger all the failed casync tests currently showing on update_excuses, the hint remains relevant until those packages migrate
<cpaelzer> ok
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [amd64] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [arm64] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [i386] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [armhf] (bionic-proposed/universe) [3.12.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wolfssl [amd64] (bionic-proposed) [3.12.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [armhf] (bionic-proposed) [3.12.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [ppc64el] (bionic-proposed) [3.12.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [arm64] (bionic-proposed) [3.12.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [s390x] (bionic-proposed) [3.12.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [i386] (bionic-proposed) [3.12.2+dfsg-1]
<acheronuk> has anyone an idea why this may occur on arm?
<acheronuk> The following packages have unmet dependencies:
<acheronuk>  libkf5notifications5 : Depends: phonon4qt5 but it is not going to be installed
<acheronuk> but "apt-get install apt-get install libkf5notifications5 phonon4qt5" works
<acheronuk> - one 'apt-get install' there :/
<apw> acheronuk, got a log please ?
<acheronuk> apw: I was investigating this: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-plasma/+build/13824579
<acheronuk> which didn't tell me much, so fired up an armhf chroot to try to see why
<apw> what happens if you try and install phonon4qt4 on its own
<apw> s/qt4/qt5/
<cjwatson> you can just use chdist for that kind of thing - you don't need a full chroot
<apw> some kind of unexperessed need to upgrade both together perhaps
<acheronuk> apw: apt seems happy to do that
<cjwatson> and it's usually a good idea to try "apt-get build-dep <source package name>", otherwise you won't detect the case of something else in the build-deps declaring Breaks on something in phonon4qt5's deps
<cjwatson> (for example)
<cjwatson> i.e. "apt-get install libkf5notifications5 phonon4qt5" is definitely not a sufficient test in all cases
<cjwatson> it could also be something that's been resolved by a newer publisher run, of course
<apw> acheronuk, on armhfyes ?
<acheronuk> apw: armhf and arm64, but not on any other architectures
 * acheronuk wonders what will happen just building against release?
<acheronuk> i.e. not with proposed
<acheronuk> apw: seems to be installing build deps ok in a ppa where proposed has been turned off. hmmmmm....
<acheronuk> I wonder if there is some new Qt changes messing with arm*
<infinity> Curious.
<infinity> Asking for just libkf5notifications5 fails with the above error, asking for both works.
<infinity> Thanks, apt.
<infinity> And it's because of vlc-plugin-base, I think.
<infinity> So, should clear up when that's published for arm*
<infinity> Maybe.
<infinity> acheronuk: ^
<acheronuk> infinity: thanks for that detective work. I'll wait until that is done then :)
<LocutusOfBorg> cpaelzer, please make nghttp2 in main and then I can followup with the two uploads if you want
<LocutusOfBorg> I already did the merge in a ppa
<LocutusOfBorg> (I agree about an upload with just http2 enabled and then a new one with the merge)
<slangasek> tjaalton: do you have any insights into what the latest dogtag-pki autopkgtest failures mean? I'm not really buying that adduser broke this.  http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/bionic/amd64
-queuebot:#ubuntu-release- Unapproved: dpkg (trusty-proposed/main) [1.17.5ubuntu5.7 => 1.17.5ubuntu5.8] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (artful-proposed/main) [3.26.1-0ubuntu1 => 3.26.2.1-0ubuntu0.1] (personal-gunnarhj, ubuntu-desktop)
<sergiusens> slangasek hello there; question, do you think you would allow me to SRU a new version of patchelf into 16.04?
<tjaalton> slangasek: i'll look into it on friday, I'm off until then
<tjaalton> thanks for the notice
<slangasek> sergiusens: my standard answer to an SRU question at that level of detail is "maybe"
<slangasek> tjaalton: cheers
<sergiusens> slangasek fair enough
-queuebot:#ubuntu-release- New binary: go-dep [amd64] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: go-dep [ppc64el] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: go-dep [armhf] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: go-dep [s390x] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: go-dep [arm64] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: willow [amd64] (bionic-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: go-dep [i386] (bionic-proposed/none) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (trusty-proposed) [3.12.0-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (zesty-proposed) [4.9.0-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (artful-proposed) [4.9.0-1ubuntu2.1]
#ubuntu-release 2017-12-07
-queuebot:#ubuntu-release- New binary: x265 [s390x] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: writerperfect [amd64] (bionic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: writerperfect [s390x] (bionic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: writerperfect [ppc64el] (bionic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: x265 [i386] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: writerperfect [i386] (bionic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: x265 [arm64] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [ppc64el] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [armhf] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [amd64] (bionic-proposed/universe) [2.6-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: writerperfect [arm64] (bionic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: writerperfect [armhf] (bionic-proposed/universe) [0.9.5-2] (no packageset)
<wxl> slangasek: tsimonq2 had me cherry pick a patch from upstream in the bionic kdepim-runtime in order to fix autopkgtests, apparently by your suggestion. looks like it fixed 1 of 2 failing tests, but do you have any suggestions regarding the second?
<wxl> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/k/kdepim-runtime/20171207_053307_20e20@/log.gz
<slangasek> wxl: not specifically, but I would wonder about that test being racy since it's a client-server test, and retry it
<wxl> slangasek: alright, i'll see if tsimonq2 has any ideas.
-queuebot:#ubuntu-release- New: accepted go-dep [amd64] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted go-dep [armhf] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted go-dep [ppc64el] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted go-dep [arm64] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted go-dep [s390x] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted go-dep [i386] (bionic-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [amd64] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [armhf] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [ppc64el] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [arm64] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [s390x] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted writerperfect [i386] (bionic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted willow [amd64] (bionic-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [arm64] (bionic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted x265 [i386] (bionic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted x265 [s390x] (bionic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted x265 [amd64] (bionic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted x265 [ppc64el] (bionic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted x265 [armhf] (bionic-proposed) [2.6-2]
<cpaelzer> slangasek: http://autopkgtest.ubuntu.com/packages/casync all green on bionic now :-)
<acheronuk> slangasek: that kdepim-runtime akonadi_sqlite_pop3test is failing for some time now on KDE's own CI tests, with no fix yet I can see
<LocutusOfBorg> cpaelzer, ping for the MIR?
<cpaelzer> hi LocutusOfBorg
<cpaelzer> still a block on systemd autopkgtest
<cpaelzer> I'm testing the MIR from a ppa and the actual change looks good
<cpaelzer> it is more to get former curl out of the way
<cpaelzer> a rerun is in the queue - the issue certainly isn't due to curl
<cpaelzer> we can ask for an override here as well, but I usually prefer to get it green if a rerun does it
<cpaelzer> LocutusOfBorg: I see your trigger of the same even is in the queue above me
<cpaelzer> It seems the tests atm take quite long and the queue is full of retriggers for it
<cpaelzer> I also see slangasek for adduser&lsb just as you a bit down the queue as well
<cpaelzer> as a glimpse of hope at least casync tests fine now :-)
<LocutusOfBorg> yep, I want it migrate too
<LocutusOfBorg> but I don't want to enable nghttp2 before it gets promoted
<LocutusOfBorg> this is why I'm asking: can you please promote so I can push once it goes in release?
<LocutusOfBorg> btw the new release is just about bugfixes, so maybe we can upload it only once?
<LocutusOfBorg> I have a merge ready in my ppa btw
<cpaelzer> for curl you mean?
<LocutusOfBorg> yep
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8550553/+listing-archive-extra
<cpaelzer> I thought it bumped libcurl-gnutls from 4.4 to 4.5 and was unsure if that means a huge rebuild excercise
<LocutusOfBorg> with a libssh2 MIR we can sync
<cpaelzer> I can't provide that
<LocutusOfBorg> https://launchpadlibrarian.net/348311136/curl_7.55.1-1ubuntu2.1_7.57.0-1ubuntu1.diff.gz
<LocutusOfBorg> there is no bump, at least to my diff
<cpaelzer> I have tested enabling http2 in curl (and apache) and it works for curl fine in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3070/+packages
<cpaelzer> I had the merge in my ppa and it changed the version
<cpaelzer> but I deletde and stepped back to just enabling http2 so I have no logs anymore since LP cleans them
<cpaelzer> the mir for http2 is https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1687454
<ubot5> Launchpad bug 1687454 in curl (Ubuntu) "[MIR] nghttp2" [Undecided,Triaged]
<LocutusOfBorg> yep I know the mir
<cpaelzer> feel free to combine the enabling with your merge
<cpaelzer> I agree that one upload is better than two
<LocutusOfBorg> I already did it :)
<cpaelzer> thanks
<cpaelzer> yet for any of that we would want the former one to promote
<LocutusOfBorg> I mean, it was "removing some delta from debian" rather than enabling stuff
<cpaelzer> and I have no powers to do so
<LocutusOfBorg> oh ok
<LocutusOfBorg> BTW the curl currently in bionic seems just wrong
<LocutusOfBorg>  # do not add patches below and then CVE-2017-1000254.patch
<LocutusOfBorg> cpaelzer, can you please test the curl in my ppa?
<cpaelzer> on the merge you drop 1000254 anyway
<cpaelzer> sure, I can use your ppa for my tests with enabling apache2
<LocutusOfBorg> oh actually the Ubuntu3 is fine http://launchpadlibrarian.net/347530733/curl_7.55.1-1ubuntu2.1_7.55.1-1ubuntu3.diff.gz
<cpaelzer> I have seen the reshuffle
<cpaelzer> LocutusOfBorg: I know - I really had a merge ready https://git.launchpad.net/~paelzer/ubuntu/+source/curl?h=lp1687454-bionic-merge
<cpaelzer> LocutusOfBorg: until I saw the so bump, let me check your ppa for that one
<LocutusOfBorg> I can see new symbols, yes
<LocutusOfBorg> but no old symbols changed, and no soname bump
 * LocutusOfBorg has always the feeling to get the ABI changes wrong, so he is surely wrong here
<cpaelzer> oh well, I didn't go into that detail
<cpaelzer> but that is good to be confirmed
<LocutusOfBorg> I looked at debian/control and no bump, and libcurl3-gnutls.symbols shows a lot of "+" but no "-" :)
<LocutusOfBorg> if you confirm, I upload once britney lets this one go
<cpaelzer> well dh_makeshlibs doesn't punch you in your build and it would otherwise
<cpaelzer> so ok
<cpaelzer> LocutusOfBorg: do you know - can we overrride systemd just for curl?
<cpaelzer> or would that unblock all of the others as well - of wich some might want to sort something out?
<LocutusOfBorg> xnox, ^^^
<LocutusOfBorg> maybe we can wait for the current tests to finish and see what happened
<cjwatson> jamespage: I imagine these were just boilerplate messages on bug 1736454, but FWIW I am not likely to have time to test this for the cloud archive
<ubot5> bug 1736454 in Ubuntu Cloud Archive ocata "pylxd cannot start containers with LXD 2.0.11" [Critical,Fix committed] https://launchpad.net/bugs/1736454
<jamespage> cjwatson: yep - I've got those covered
<cjwatson> cool
<cpaelzer> LocutusOfBorg: the last two systemd tests (those re-triggered by slangasek) failed due to bug 1730717
<ubot5> bug 1730717 in linux (Ubuntu Bionic) "Some VMs fail to reboot with "watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]"" [High,In progress] https://launchpad.net/bugs/1730717
<cpaelzer> I hade hoped if those go well they give us confidence to epxect a pass once your trigger of it for curl hits the top of the queue
<cpaelzer> Laney: you recycled workers for this right ? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20171206_035945_add64@/log.gz
<cpaelzer> any need to poke somebody to do so?
<cpaelzer> or is that done on a regular base anyway?
<Laney> not me, Steve did I think, and no it's not done automatically
<Laney> no good way to tell that from a real failure
<Laney> join us in praying for that bug to be fixed soon
<Laney> well I guess we could add some code to find that string in the log and reject the result
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.4-0ubuntu1 => 2:10.0.4-0ubuntu2] (openstack, ubuntu-server)
<ahasenack> hi guys, systemd has a failing dep8 test on s390 which was fixed in bionic: https://git.launchpad.net/~usd-import-team/ubuntu/+source/systemd/commit/?id=bc28ba569ef1ecdbc028512dd24b32907212e5cc
<ahasenack> but not in artful
<ahasenack> I have an iproute2 SRU migration failing in artful because of this (and other packages, but I'm debugging this one now)
<ahasenack> here is the systemd autopkg test history on artful/s390: http://autopkgtest.ubuntu.com/packages/s/systemd/artful/s390x
<ahasenack> it started to fail when the s390 tests started to run in a vm, which liberated that particular systemd-fsck test to finally run instead of being skipped
<ahasenack> what's usually done in such a case? mark it as always-fail? sru the dep8 fix?
<ahasenack> I filed a bug about this particular case, tasking artful: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1736955
 * ahasenack -> lunch
<smb> Is someone working on adt queue/workers for artful/arm64? There are two tests which claim to be running (without runtime changing) and right now the queue appears to be no longer there. Which is not that bad as alot of it was me hitting retry
<Laney> The images have disappeared, and I reported a ticket to IS to get it fixed
<smb> oh dear.... thanks
-queuebot:#ubuntu-release- Packageset: Added linux-azure-edge to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-euclid to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure-edge to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-meta-euclid to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-meta-oem to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-oem to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-signed-oem to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-euclid to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-euclid to kernel in xenial
<Laney> om nom kernels
<slangasek> acheronuk: if akonadi_sqlite_pop3test is a broken test, how about disabling the test?
<acheronuk> slangasek: we are thinking of doing that. just doing some due diligence, as it actually looks a bit more broken in our runs than the upstream results.
-queuebot:#ubuntu-release- New binary: brotli [ppc64el] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [s390x] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-locate-path [amd64] (bionic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [i386] (bionic-proposed/universe) [1.0.2-2] (no packageset)
<ahasenack> hi, can someone please "force-badtest" (I think that's the term) the s390x systemd artful and zesty dep8 test, it has been failing since the s390x tests moved to a vm due to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1736955
<ubot5> Launchpad bug 1736955 in systemd (Ubuntu Artful) "dep8 test systemd-fsckd fails on s390" [Medium,Triaged]
<ahasenack> it's fixed in bionic
<ahasenack> s390x artful systemd tests: http://autopkgtest.ubuntu.com/packages/s/systemd/artful/s390x
<ahasenack> zesty: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/s390x
-queuebot:#ubuntu-release- New binary: brotli [amd64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [arm64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [armhf] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maas (trusty-proposed/main) [1.9.5+bzr4599-0ubuntu1~14.04.2 => 1.9.5+bzr4599-0ubuntu1~14.04.3] (ubuntu-server)
<dpb1> rbasak: can you do what ahasenack is asking? ^
-queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (artful-proposed) [1.8.4-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (artful-proposed) [1.3+17.10ubuntu1]
-queuebot:#ubuntu-release- New: accepted brotli [amd64] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted brotli [armhf] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted brotli [ppc64el] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted brotli [arm64] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted brotli [s390x] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted brotli [i386] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted node-locate-path [amd64] (bionic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted percona-xtradb-cluster-5.6 [source] (artful-proposed) [5.6.34-26.19-0ubuntu4.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted uvp-monitor [source] (artful-proposed) [2.2.0.316-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.20-0ubuntu4~16.04.1 => 2.0.11-0ubuntu1~16.04.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (artful-proposed) [3.26.2.1-0ubuntu0.1]
<stgraber> any sru person around (other than myself)?
-queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.20-0ubuntu4~16.04.1 => 2.0.11-0ubuntu1~16.04.3] (edubuntu, ubuntu-server)
<stgraber> we have a bit of an annoying regression in LXD 2.0.11 which we need fixed ASAP. The upload is about to hit the queue and I'm intending on releasing to -updates immediately after manual testing is done. ^
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (zesty-proposed) [1.3+17.04ubuntu1]
<stgraber> infinity, bdmurray, slangasek: any of you around who could do a quick review of that upload? (diff is small)
<bdmurray> stgraber: just for xenial?
<stgraber> bdmurray: yep, that's the only place where we have LXD 2.0.11
<bdmurray> stgraber: I'll do it
<stgraber> bdmurray: thanks!
<stgraber> I'll test it on a clean system as soon as it's published
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.8]
<bdmurray> Can somebody fix perms on sru-review in the ubuntu-archive-tools tree?
<stgraber> done
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.25]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.3+16.04ubuntu1]
<tsimonq2> infinity: Your kdepim-runtime armhf hint can be safely dropped. There are now no real differences in failures from other arches.
<mwhudson> is there a good way to do upgrade testing in autopkgtest?
<stgraber> bdmurray: looks like we'll have a follow-up fix, noticed another problem with lxd init while doing more testing... sorry
<stgraber> bdmurray: running the upstream testsuite against that fix now, will push upstream and cherry-pick next
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.20-0ubuntu4~16.04.1 => 2.0.11-0ubuntu1~16.04.4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (trusty-proposed) [1.4.20.3+svn499-0ubuntu2.4]
<stgraber> bdmurray: ready for review in the queue (queuebot seems a bit slow today)
-queuebot:#ubuntu-release- Unapproved: networking-l2gw (artful-proposed/universe) [1:10.1.0~a2~git20170831.a8ae0e3-0ubuntu1 => 1:11.0.0-0ubuntu1] (no packageset)
<ahasenack> autopkg test failures do not block migrations for srus?
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.4]
<ahasenack> initramfs-tools has more reds than greens in http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html, but it's in trusty-proposed
<ahasenack> my iproute2 upload to trusty also has reds, but it's also in proposed already
<cjwatson> well, firstly, -proposed is the source for migrations, not the target; tests don't generally happen at all until they're in -proposed
<cjwatson> secondly, at the moment autopkgtest results are only informative to SRU team members deciding whether to promote SRUs to -updates, and don't block; although we've talked about changing that at various times in the past
<rbasak> I was just about to look at force-badtest for ahasenack
<rbasak> Though we can ignore the results
<rbasak> Let's see if that works.
 * rbasak hasn't done this before
#ubuntu-release 2017-12-08
<cpaelzer> hi, the current bionic apache2 upload https://launchpad.net/ubuntu/+source/apache2/2.4.29-1ubuntu2 is blocked in proposed for a component mismatch to libnghttp2-14 - the MIR for that is complete in bug 1687454
<ubot5> bug 1687454 in curl (Ubuntu) "[MIR] nghttp2" [Undecided,Triaged] https://launchpad.net/bugs/1687454
<cpaelzer> OTOH I do not see it in https://people.canonical.com/~ubuntu-archive/component-mismatches.txt , so maybe I fail to see something else missing in this case
<cpaelzer> So I either need an AA to promote that through the mismatch or some guidance on what I overlook in this case
<cpaelzer> I'd have expected the autopkgtests to run and then be a component mismatch, but the tests block on "unsatisfiable Depends: libnghttp2-14"
<cpaelzer> But other than being in universe it is there as far as I can see
<infinity> cpaelzer: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt is what you're after.  Fixing.
<cpaelzer> infinity: thanks for the link but I'm puzzled
<infinity> cpaelzer: By?
<cpaelzer> is that telling me something else than the expected component mismatch?
<infinity> cpaelzer: It's telling you what you thought you wanted to see on the other page.
<cpaelzer> lol
<infinity> cpaelzer: The other page, of course, won't list the mismatch because it doesn't include -proposed, and thus nothing is pulling nghttp2 into main there.
<infinity> cpaelzer: Anyhow, it's promoted now.
<cpaelzer> thank you
<cpaelzer> I had the link from https://wiki.ubuntu.com/MainInclusionProcess
<cpaelzer> would it be reasonable if I added the one you gave me there as well?
<infinity> cpaelzer: Sure.  Maybe s/show up in the component-mismatches list/show up in the component-mismatches list, or if the dependency is only in proposed, the component-mismatches-proposed list/
<cpaelzer> done
<cpaelzer> checking the autopkgtests in a few hours then ...
<cpaelzer> Can someone cancel https://launchpad.net/ubuntu/+source/iproute2/4.14.1-0ubuntu1 from bionic-proposed
<cpaelzer> other than tests before upload suggested this needs a bigger cleanup for ubuntu-fan
<cpaelzer> I want to prepare a proper ..ubuntu2 for that, but that needs some time
<cpaelzer> so cancelling the current one would be kind to interfer less with others
<infinity> cpaelzer: Is it interfering in some way?
<infinity> It builds no libraries, so the only way it could be causing issues if it it's actually broken somehow.
<cpaelzer> infinity: it works in general but not with ubuntu fan
<infinity> Mmkay.  I can delete it.
<cpaelzer> thank you
<infinity> cpaelzer: Gone.
<doko> $ fgrep gvfs *
<doko> vorlon:force-badtest gvfs/1.34.1-1ubuntu3/s390x
<doko> please add ppc64el, tired about giving that back for every package multiple times ...
<doko> or better disable the flaky tests, but that should be a task for the package owners ...
<Laney> doko: done
<acheronuk> Could someone please 'force-badtest kdepim-runtime/all/ppc64el kdepim-runtime/all/s390x' ?
<acheronuk> that is another that seems to want to run tests on those architectures against itself, despite no binaries building
<doko> infinity, slangasek, apw, Laney: please don't work on python-gobject-dev in NBS, using that as an example package mentoring Lucasz
<apw> doko, ack
<LocutusOfBorg> apw, hinting systemd/amd64 badtest will make a lot of stuff migrate, e.g. curl with security fixes inside...
<apw> LocutusOfBorg, that on the face of it is a terrifying idea ... letting a systemd which is not passing its tests out
<LocutusOfBorg> I'm running systemd against itself right now
<LocutusOfBorg> apw, I know, but we are stuck with curl because of that, I pinged xnox above, I don't really know what to do
<apw> LocutusOfBorg, oh but that looks like the reboot issue ... bah
<LocutusOfBorg> we discussed this above already yesterday with cpaelzer and somebody else
<LocutusOfBorg> I would like to upload the curl merge with new release and http2 support :)
<LocutusOfBorg> somebody mentioned a race condition on the bug, but retrying the test is not helping too much
<Laney> yet there are 4 more retries running right now
<apw> Laney, did you make things smarter that we now see the dmesg bits in the logs ?
<Laney> if it errors
<apw> Laney, ahhh only if it is _your_ reboot which triggers it i assume
<Laney> doesn't appear to be happening there
<Laney> the test carries on, if that bug happens the machine dies forever
<apw> oh yeah, so that specific instance isn't it, though the one on lsb _is_
<apw> Laney, ^5 for adding that info, that is awsome
<Laney> lsb is the same bug, right
<Laney> but the others aren't AFAICS
<LocutusOfBorg> I did run it against itself, lets see what happens
<LocutusOfBorg> cpaelzer, libvirt merge ping? :)
<Laney> right, but the 4 other retries aren't very helpful I don't think
<coreycb> bdmurray: we have a few stable uploads that could use a review. nova for xenial and neutron for zesty. would you or someone else on the team be able to take a look?
<LocutusOfBorg> can we have systemd forced bad then? curl is still waiting his cve fixes :(
<bdmurray> coreycb: Its slangasek's day but if he can't I will.
<jbicha> please consider badtesting pinentry/s390x, it's always-failed on most architectures (holding up gtk+2.0 and others today)
<coreycb> bdmurray: thanks, much appreciated
<LocutusOfBorg> apw, you ignored linux block, but I think there is a little NBS in proposed cleanup needed
<LocutusOfBorg> old binaries left on arm64: linux-headers-4.4.0-1080-snapdragon, linux-image-4.4.0-1080-snapdragon, linux-snapdragon-headers-4.4.0-1080, linux-snapdragon-tools-4.4.0-1080, linux-tools-4.4.0-1080-snapdragon (from 4.4.0-1080.85)
<apw> LocutusOfBorg, indeed, they would have appeared in the last hour or so, i'll sort them out
<LocutusOfBorg> also raspi2 needs it :)
<LocutusOfBorg> btw the new mainline vboxvideo seems to work great
-queuebot:#ubuntu-release- Unapproved: sysstat (artful-proposed/main) [11.5.7-1ubuntu1 => 11.5.7-1ubuntu2] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sysstat (zesty-proposed/main) [11.4.3-1 => 11.4.3-1ubuntu1] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sysstat (xenial-proposed/main) [11.2.0-1ubuntu0.1 => 11.2.0-1ubuntu0.2] (kubuntu, ubuntu-server)
<slashd> dgadomski, ^
<LocutusOfBorg> cpaelzer, uploading curl, the current one won't easily migrate soon
<cpaelzer> really
<cpaelzer> ok LocutusOfBorg
<cpaelzer> I decoupled apache anyway so it is not dpeending on each other
<cpaelzer> the tests no more need the enabled curl
<cpaelzer> and the MIR is done, so you won't hit the component mismatch
<LocutusOfBorg> I see apache is good yes
<cpaelzer> LocutusOfBorg: and btw fro libvirt - target is 3.11 wihch released mid Jan
<cpaelzer> I'll play with 3.10 which released like a few days ago, but just to work with qemu 2.11 which releases next week
<cpaelzer> this is all intertwined and none works well without the other
<cpaelzer> but TL;DR it is under control :-)
-queuebot:#ubuntu-release- New binary: libical3 [ppc64el] (bionic-proposed/none) [3.0.1-1] (no packageset)
<LocutusOfBorg> thanks, the python binding is dep-waiting on it, this is why I care
<LocutusOfBorg> btw, speaking on qemu, let me ask a question
-queuebot:#ubuntu-release- New binary: libical3 [amd64] (bionic-proposed/none) [3.0.1-1] (no packageset)
<LocutusOfBorg> long short story: pbuilder-dist bionic arm64 create fails since artful or so
<LocutusOfBorg> somewhat it can't install bash, and fails there
<LocutusOfBorg> same command, works with sid
<LocutusOfBorg> cpaelzer, did you ever experienced that?
-queuebot:#ubuntu-release- New binary: libical3 [i386] (bionic-proposed/none) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libical3 [s390x] (bionic-proposed/none) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libical3 [arm64] (bionic-proposed/none) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libical3 [armhf] (bionic-proposed/none) [3.0.1-1] (no packageset)
<LocutusOfBorg> W: Failure while unpacking required packages.  This will be attempted up to five times.
<LocutusOfBorg> W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/bash_4.4-5ubuntu1_arm64.deb is at fault)
<LocutusOfBorg> this is a paste http://paste.ubuntu.com/26140607/ of the file
-queuebot:#ubuntu-release- New: accepted libical3 [amd64] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted libical3 [armhf] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted libical3 [ppc64el] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted libical3 [arm64] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted libical3 [s390x] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted libical3 [i386] (bionic-proposed) [3.0.1-1]
<doko> please could somebody override the falcon/s390x autopkg test? it's always-failed on the other archs, not sure why it succeeded on s390x. or maybe better mark it as always-failed for s390x
<jbicha> similar for pinentry/s390x
<doko> now disabled the test in falcon, was disabled in the package build as well
<slangasek> jbicha: the pinentry/s390x test regression does not appear to have happened as part of the move from lxd to kvm; I don't think this looks appropriate to override
<jbicha> it's not appropriate for it to block gtk2 either, right?
<slangasek> jbicha: you can trigger a baseline re-test of pinentry against the release pocket to show that it's not a regression in -proposed
<jbicha> it feels odd for a test that doesn't pass on amd64 to block migrationâ¦
<slangasek> ah
<slangasek> pinentry fails on all kvm archs and only passes on lxd archs?
<slangasek> ok, I overlooked that specialness
<jbicha> oh, that's a neat trick :|
<slangasek> spectacularly lame that a tty-related test would work in a container and fail on a host
<slangasek> ok, overriding
<jbicha> thanks
-queuebot:#ubuntu-release- Unapproved: resolvconf (zesty-proposed/main) [1.79ubuntu4 => 1.79ubuntu4.1] (core)
<acheronuk> slangasek:  Could you please 'force-badtest kdepim-runtime/all/ppc64el kdepim-runtime/all/s390x' ?
<acheronuk> another that wants to run tests on those architectures against itself despite no binaries building
<acheronuk> ^^^^ that should make the last of PIM migrate
<slangasek> acheronuk: done
<slangasek> coreycb: this neutron SRU is missing paperwork on LP: #1731595; test case, regression potential
<ubot5> Launchpad bug 1731595 in neutron (Ubuntu Zesty) "L3 HA: multiple agents are active at the same time" [High,Triaged] https://launchpad.net/bugs/1731595
<slangasek> bdmurray: ^^ though I see you accepted it into artful-proposed without?
<coreycb> slangasek: filling that in now
<bdmurray> Oh, I thought I'd added a comment about accepting it but needing that info
<coreycb> slangasek: bdmurray: updated with SRU details. thanks.
<slangasek> bdmurray: "never read the comments" ;-)
<slangasek> coreycb: nova is uploaded with the wrong -v option, -0ubuntu4.2 is not accepted into the archive but -0ubuntu4.3 doesn't include the link to LP: #1692397 in its .changes file; rejecting, this will need a reupload
<ubot5> Launchpad bug 1692397 in nova (Ubuntu Xenial) "hypervisor statistics could be incorrect" [Low,Triaged] https://launchpad.net/bugs/1692397
<slangasek> coreycb: also, it's unclear why this wasn't simply uploaded as 4.2, there is no 4.2 anywhere in LP's history
<coreycb> slangasek: yeah that was a mistake. the old version was in the queue for a while and forgotten.
<coreycb> slangasek: i'll fix that up
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.1 => 2:13.1.4-0ubuntu4.2] (openstack, ubuntu-server)
<coreycb> slangasek: i've uploaded a new nova to xenial
<slangasek> thanks, will re-review shortly
<coreycb> slangasek: thanks much
<acheronuk> slangasek: thank you
<slangasek> coreycb: ah; and what about LP: #1736149? seems there is already an openstack in zesty-proposed, awaiting verification
<ubot5> Launchpad bug 1736149 in nova (Ubuntu Zesty) "[SRU] ocata stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1736149
<coreycb> slangasek: i'm on a roll here :/
<slangasek> coreycb: sorry, I blindly paged through that warning message when I reviewed it earlier, I should've flagged it to you the first time around
<coreycb> slangasek: could we replace the version in proposed with the new one?
<coreycb> slangasek: probably not, they'd need to have the bugs referenced in the same version of the changelog
<slangasek> coreycb: you could upload /nova/ with -v, and then do the SRU verification of 1736149 and the new bug at the same time
<slangasek> coreycb: but that only makes us happy if the SRU verification actually takes place
<coreycb> slangasek: i think i'll just verify the one that is in proposed and that will be 7 days in proposed on monday at which point we could promote it to updates and accept the new one
<slangasek> ok
-queuebot:#ubuntu-release- New binary: polyml [i386] (bionic-proposed/universe) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [s390x] (bionic-proposed/universe) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [ppc64el] (bionic-proposed/universe) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [amd64] (bionic-proposed/universe) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [arm64] (bionic-proposed/universe) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [armhf] (bionic-proposed/universe) [5.7.1-1] (no packageset)
#ubuntu-release 2017-12-09
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.2]
<slangasek> Laney: er, do you know why we have only 20 arm64 worker threads?
<slangasek> Laney: ah... looks like the higher count didn't get saved to the branch, because I said we needed to wait for the backlog to clear to see how many we need... clearly the answer is "more than 20" ;)
<slangasek> Laney: oh, but it looks like this wasn't accidentally triggered by juju either, because s390x was @ 20 even though the branch said only 16?
<slangasek> Laney: so the actual problem was that we only had bionic images back, which means a bunch of SRU tests in artful+zesty were systematically murdering the runners :)
<tjaalton> slangasek: had a brief look at the dogtag failure, seems some java libs got updated that might've caused this, most likely libjaxrs-api-java. I'm prepping a new version for upload, hope it works with the new libs
<slangasek> tjaalton: ok, cool
<cpaelzer> LocutusOfBorg: haven#t seen that, but then I don't pbuild at all and due to that even less pbuild cross
<cpaelzer> LocutusOfBorg: file me a bug and I'll try to take a look
<cpaelzer> LocutusOfBorg: give me a command that worked and the revision when and since when it fails
<LocutusOfBorg> cpaelzer, ack, btw the new curl is (modulo arm64 in progress) stuck on the very same systemd failure, so we are ok now
<LocutusOfBorg> as we were yesterday
-queuebot:#ubuntu-release- New: accepted polyml [amd64] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted polyml [armhf] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted polyml [ppc64el] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted polyml [arm64] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted polyml [s390x] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted polyml [i386] (bionic-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New binary: libical [s390x] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libical [amd64] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libical [ppc64el] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libical [i386] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libical [arm64] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libical [armhf] (bionic-proposed/main) [2.0.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted libical [amd64] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libical [armhf] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libical [ppc64el] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libical [arm64] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libical [s390x] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libical [i386] (bionic-proposed) [2.0.0-2]
<LocutusOfBorg> cpaelzer, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1737312 :)
<ubot5> Launchpad bug 1737312 in qemu (Ubuntu) "Qemu crashes with signal 6 on arm64 chroot creation on amd64 (installing bash)" [Undecided,New]
-queuebot:#ubuntu-release- New binary: range-v3 [amd64] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-debug [amd64] (bionic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiff [ppc64el] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New binary: tiff [amd64] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New binary: tiff [s390x] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New binary: tiff [i386] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New binary: tiff [arm64] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New binary: tiff [armhf] (bionic-proposed/main) [4.0.9-1] (core)
-queuebot:#ubuntu-release- New: accepted tiff [amd64] (bionic-proposed) [4.0.9-1]
-queuebot:#ubuntu-release- New: accepted tiff [armhf] (bionic-proposed) [4.0.9-1]
-queuebot:#ubuntu-release- New: accepted tiff [ppc64el] (bionic-proposed) [4.0.9-1]
-queuebot:#ubuntu-release- New: accepted tiff [arm64] (bionic-proposed) [4.0.9-1]
-queuebot:#ubuntu-release- New: accepted tiff [s390x] (bionic-proposed) [4.0.9-1]
-queuebot:#ubuntu-release- New: accepted tiff [i386] (bionic-proposed) [4.0.9-1]
#ubuntu-release 2017-12-10
-queuebot:#ubuntu-release- New binary: ayatana-ido [ppc64el] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphite2 [ppc64el] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New binary: pikopixel.app [ppc64el] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudpickle [amd64] (bionic-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikopixel.app [amd64] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [amd64] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [s390x] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphite2 [s390x] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New binary: ayatana-ido [i386] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphite2 [i386] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New binary: ayatana-ido [arm64] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikopixel.app [s390x] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikopixel.app [armhf] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikopixel.app [arm64] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikopixel.app [i386] (bionic-proposed/none) [1.0-b8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [armhf] (bionic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphite2 [arm64] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New binary: graphite2 [armhf] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New binary: graphite2 [amd64] (bionic-proposed/main) [1.3.10-8] (core)
-queuebot:#ubuntu-release- New: accepted graphite2 [amd64] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted graphite2 [armhf] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted graphite2 [ppc64el] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted graphite2 [arm64] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted graphite2 [s390x] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted graphite2 [i386] (bionic-proposed) [1.3.10-8]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [amd64] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [armhf] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [ppc64el] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [arm64] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [s390x] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted pikopixel.app [i386] (bionic-proposed) [1.0-b8-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [amd64] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [armhf] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [ppc64el] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted cloudpickle [amd64] (bionic-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted range-v3 [amd64] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [arm64] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [s390x] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [i386] (bionic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted node-debug [amd64] (bionic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New sync: icu-le-hb (bionic-proposed/primary) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [sync] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New binary: icu-le-hb [s390x] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New binary: icu-le-hb [amd64] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New binary: icu-le-hb [ppc64el] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New binary: icu-le-hb [i386] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New binary: icu-le-hb [arm64] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New binary: icu-le-hb [armhf] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted icu-le-hb [amd64] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [armhf] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [ppc64el] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [arm64] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [s390x] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New: accepted icu-le-hb [i386] (bionic-proposed) [1.0.3+git161113-4]
-queuebot:#ubuntu-release- New binary: golang-github-mwitkow-go-conntrack [amd64] (bionic-proposed/universe) [0.0~git20161129.cc309e4-1] (no packageset)
<doko> Laney, slangasek: looks like the arm64 can't keep up, the backlog isn't cleared during the weekend
<doko> s/amr64/arm64 autopkg test machines/
-queuebot:#ubuntu-release- New binary: postorius [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-mwitkow-go-conntrack [amd64] (bionic-proposed) [0.0~git20161129.cc309e4-1]
-queuebot:#ubuntu-release- New: accepted postorius [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
#ubuntu-release 2018-12-03
<xnox> mwhudson++
-queuebot:#ubuntu-release- New: accepted movim [amd64] (disco-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted pdftk [arm64] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New: accepted pdftk [i386] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New: accepted pdftk [s390x] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New: accepted pdftk [amd64] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New: accepted pdftk [ppc64el] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New: accepted pdftk [armhf] (disco-proposed) [2.02-5]
-queuebot:#ubuntu-release- New binary: simple-revision-control [amd64] (disco-proposed/universe) [1.21-2] (no packageset)
-queuebot:#ubuntu-release- New binary: simple-revision-control [s390x] (disco-proposed/universe) [1.21-2] (no packageset)
<tsimonq2> infinity: It's time, axe Lubuntu i386 too.
-queuebot:#ubuntu-release- New binary: simple-revision-control [armhf] (disco-proposed/universe) [1.21-2] (no packageset)
-queuebot:#ubuntu-release- New binary: simple-revision-control [ppc64el] (disco-proposed/universe) [1.21-2] (no packageset)
-queuebot:#ubuntu-release- New binary: simple-revision-control [i386] (disco-proposed/universe) [1.21-2] (no packageset)
-queuebot:#ubuntu-release- New binary: simple-revision-control [arm64] (disco-proposed/universe) [1.21-2] (no packageset)
<infinity> tsimonq2: I can haz email to ubuntu-release@lists to that effect?
<tsimonq2> infinity: Sure, next time I'm at a computer.
<ginggs> any ideas why gudhi/arm64 is not installable?  blocking tbb, pytest
<vorlon> ginggs: well, rmadison shows no binaries on arm64
<vorlon> https://launchpad.net/ubuntu/disco/arm64/gudhui/2.2.0+dfsg-2ubuntu2 status: deleted
<ginggs> vorlon: thanks, now why would that be?
<vorlon> that part I'm not sure about, if there's a place in the web ui to see why a binary was removed I can never remember where to find it
<ginggs> vorlon: ah thanks, here it is
<ginggs> https://launchpad.net/ubuntu/disco/arm64/gudhui
<ginggs> Deleted on 2018-11-21 by Matthias Klose
<ginggs> remove gudhi arm64 binaries, libcgal-qt5-dev not built anymore
<vorlon> ok
<vorlon> haha wow, 'abandoned upstream (and upstream host serves malware);'
<vorlon> (unrelated to gudhi)
<ginggs> so i guess we need a 'force-badtest gudhi/all/arm64' please?
<vorlon> ginggs: done
<acheronuk> FYI since cmake is in main LP: #1806276
<ubot5> Launchpad bug 1806276 in cmake (Ubuntu) "regression: kio FTBFS on i386 and armhf with cmake >= 3.13" [Undecided,New] https://launchpad.net/bugs/1806276
<acheronuk> I've put block-proposed on that bug for now
<acheronuk> and reported upstream: https://gitlab.kitware.com/cmake/cmake/issues/18669
<ginggs> vorlon: thanks
<vorlon> acheronuk: what's the purpose of a block-proposed, given that everything is built against -proposed?
<acheronuk> vorlon: just in case last night. in the unlikely event it needs to be yanked, it makes it easier if not gone to release, does it not?
<acheronuk> I hope a fix will be quick
<acheronuk> I can remove it if you like
<vorlon> acheronuk: yes, it does make it a bit easier if it hasn't gone to release; but also, if the package is not releasable, perhaps I should just remove it now
-queuebot:#ubuntu-release- New source: eglexternalplatform (disco-proposed/primary) [1.0+git20181101-0ubuntu1]
<acheronuk> vorlon: can the same version be brought back if you do that?
<acheronuk> KDE consider it an upstream issue with cmake again, but.....
<vorlon> acheronuk: it can be, yes, if you ask an archive admin to
<acheronuk> vorlon: ok. can we do that for now then? at the moment it is blocking us doing staging builds of new frameworks properly against proposed at the very least
<vorlon> acheronuk: done
<acheronuk> vorlon: thanks. I've reached out to people involved in fixing previously @ cmake last time, so fingers crossed for a quick patch I can forward on to debian
<apw> doko, i don't know if you have heard anything about this, but we have reports of any kernel built with gcc-8 8.2.0-9 cause data corruption; apparently due to a retirement optimisation eating writes
<apw> doko, i see we have -10 now, do we have any way to know what if anything archive side might have been compiled with it ?
<apw> doko, for clarity as far as i know no official kernels have been affected
-queuebot:#ubuntu-release- New source: egl-wayland (disco-proposed/primary) [1.1.0-0ubuntu1]
<rbalint> vorlon, i intend to verify all the referenced bugs (i also accept help from others if they step up to verify some of them)
<rbalint> vorlon, please clarify if _you don't want to accept_ the u-u sru as it is or _you oppose anyone accepting it in the sru team_
<rbalint> vorlon, i agree that it would be more reasonable to pick a subset of the bugs but my discussion with the sru team did not settle on a subset of bugs as one member was fine referencing only the sru bug, other insisted on referencing all of them in the changelog and i figured if i spend a week verifying extra 30 bugs rather than discussing which 30 bugs can be skipped is better use of everyone's time
<rbalint> and also u-u gets more testing
-queuebot:#ubuntu-release- New: accepted simple-revision-control [amd64] (disco-proposed) [1.21-2]
-queuebot:#ubuntu-release- New: accepted simple-revision-control [armhf] (disco-proposed) [1.21-2]
-queuebot:#ubuntu-release- New: accepted simple-revision-control [ppc64el] (disco-proposed) [1.21-2]
-queuebot:#ubuntu-release- New: accepted simple-revision-control [arm64] (disco-proposed) [1.21-2]
-queuebot:#ubuntu-release- New: accepted simple-revision-control [s390x] (disco-proposed) [1.21-2]
-queuebot:#ubuntu-release- New: accepted simple-revision-control [i386] (disco-proposed) [1.21-2]
<rbalint> vorlon, the time i spent adding sru templates was not wasted, i found old bugs (which could surface in different ways) while preparing the test cases
<vorlon> rbalint: I don't oppose anyone in the SRU team accepting it
<rbalint> vorlon, ok, thanks, then i can add a few more templates and it will be ready
<xnox> vorlon, Laney - is it possible for us to somehow trigger all the things that depend on python; whenever python2.7 is uploaded; without like uploading python-defaults?
<xnox> vorlon, Laney - ditto trigger tests whenever python3.7 is uploaded, but not python3-defaults. Cause things that are arch:all and depend only on the meta-package python/python3 do not get triggered when the implementation moves.
<xnox> is there some kind of a manual way for me to trigger this? cause in the context of OpenSSL bionic SRU this can be quite severe.
<vorlon> xnox: 'quite severe' how? are you saying there are regressions that have been overlooked because the tests were not triggered at the right level?
<vorlon> xnox: anyway, there's some prior art in britney2/policies/autopkgtest.py for overriding the list of tests to trigger
<xnox> vorlon, the amount of tests triggered is inadequate for my liking, yes.
<xnox> ok, i'll try to look into that.
<Laney> Sounds like something britney could learn about in the short term, yeah. (Please add tests)
<Laney> Ideally this would be decentralised somehow, like having python3.7 itself express that relationship somehow - but that would be something to discuss with upstream debci people probably
<Laney> can someone accept my gnome-shell-extension-desktop-icons sync from experimental in the disco new queue please? /me just tried to file a bug on it and got an oops because it's not published :-)
<vorlon> Laney: done
<Laney> thanks ð
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-desktop-icons [sync] (disco-proposed) [18.11~rc-1]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-desktop-icons [amd64] (disco-proposed/none) [18.11~rc-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted vaultlocker [amd64] (bionic-backports) [1.0.3-0ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (xenial-proposed/universe) [4.18.0-1006.6~16.04.2+signed1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (xenial-proposed) [4.18.0-1006.6~16.04.2+signed1]
<dgadomski> hi sil2100, could you please approve gnome-desktop3 and hwdata for trusty?
<doko> ubuntu-release:force-badtest symfony/3.4.17+dfsg-1ubuntu1/armhf symfony/3.4.18+dfsg-0ubuntu1/armhf
<doko> this hint needs an update to symfony/3.4.19+dfsg-1ubuntu1
<jbicha> doko: https://code.launchpad.net/~jbicha/britney/libuv1_starjava-ttools_symfony/+merge/359971
<fidencio> infinity: cjwatson: Hey! I may need your help :-) I'm one of the libosinfo maintainers and libosinfo is basically a database of OSes where we store info about minimum/recommended amount of resources, supported devices and what not. We're used mainly by GNOME Boxes and virt-manager and one of the things we do is matching OS ISOs/installation trees in order to let those apps decide the best way of installing those OSes (right now I'm working ...
<fidencio> ... on unattended-installation support for virt-install)
<fidencio> infinity: cjwatson: with this background ... I'd like to ask whether would be possible to have some file under the installers for Ubuntu (as http://archive.ubuntu.com/ubuntu/dists/disco/main/installer-i386) that would actually tell what's the ubuntu release we're dealing with
<fidencio> infinity: cjwatson: other distros as fedora/opensuse are using treeinfo (which is not the case for debian/ubuntu, and that's more than fine :-)) ... the only issue is that we don't have a proper way to recognize the system being installed
<cjwatson> fidencio: please untag me as I don't do installer work any more
<fidencio> cjwatson: right, sorry for the noise.
<sil2100> dgadomski: hey! Will try! No promises though since I'm sprinting this week!
<dgadomski> sil2100: ack, thanks
<doko> Laney: could you add monero to the list of long running tests?
-queuebot:#ubuntu-release- Unapproved: barbican (bionic-proposed/main) [1:6.0.0-0ubuntu1 => 1:6.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.3-0ubuntu1 => 2:12.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (bionic-proposed/main) [2:13.0.1-0ubuntu1 => 2:13.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (bionic-proposed/main) [1:12.0.0-0ubuntu1 => 1:12.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.6-0ubuntu2 => 2:17.0.7-0ubuntu1] (openstack, ubuntu-server)
<tseliot> apw, doko: hey, do you know why I am getting an invalid changelog.Debian.gz on amd64 for nvidia in disco, whereas the one on i386 is fine? Note: the exact same source is fine in Bionic
<Laney> doko: maybe - did you run it locally and find out that it works?
<apw> tseliot, does not make any sense to me, so you'd have to try it in a chroot
<tseliot> apw: I would, if creating a disco chroot didn't crash and complain about libnet-ssleay-perl
<tseliot> apw: like this http://paste.ubuntu.com/p/kwvZMxQKZ4/
<rbalint> bdmurray, i finished updating all bugs related to the u-u sru, please take a look at them when your time permits
<bdmurray> rbalint: Thanks will do!
<coreycb> hello, can an archive admin please look into accepting python-django-debreach and placement from the disco NEW queue? this will help unblock openstack horizon and allow us to start testing openstack placement for stein.
-queuebot:#ubuntu-release- Unapproved: gnocchi (bionic-proposed/universe) [4.2.4-0ubuntu1.1 => 4.2.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: foma [ppc64el] (disco-proposed/universe) [1:0.9.18+r243-3] (no packageset)
-queuebot:#ubuntu-release- New binary: foma [s390x] (disco-proposed/universe) [1:0.9.18+r243-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [s390x] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-rpc [amd64] (disco-proposed/universe) [0.0~git20160927.22c016f-2] (no packageset)
-queuebot:#ubuntu-release- New binary: astrometry.net [ppc64el] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: foma [i386] (disco-proposed/universe) [1:0.9.18+r243-3] (no packageset)
-queuebot:#ubuntu-release- New binary: astrometry.net [s390x] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (disco-proposed/universe) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kickpass [s390x] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [i386] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [amd64] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [s390x] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aggdraw [s390x] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: authheaders [amd64] (disco-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [s390x] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-lsp-haskell [amd64] (disco-proposed/universe) [1.0.20181023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-lsp-ui [amd64] (disco-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [s390x] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-stringify-hash [amd64] (disco-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kickpass [i386] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [armhf] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aggdraw [amd64] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kickpass [amd64] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-typing-extensions [amd64] (disco-proposed/universe) [3.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [s390x] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [arm64] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [arm64] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aggdraw [i386] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-in-parallel [amd64] (disco-proposed/universe) [0.1.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [amd64] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: perl6-readline [amd64] (disco-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-parking-lot [s390x] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aggdraw [armhf] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lsp-mode [amd64] (disco-proposed/universe) [5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-data-migrate [amd64] (disco-proposed/universe) [3.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [amd64] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [armhf] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astrometry.net [i386] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: ruby-pry-byebug [amd64] (disco-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [i386] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (disco-proposed/universe) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [i386] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astrometry.net [amd64] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kickpass [arm64] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [s390x] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-open-uri-redirections [amd64] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [arm64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [s390x] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [s390x] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [s390x] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [s390x] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [amd64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsh-autosuggestions [amd64] (disco-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (disco-proposed/universe) [18.3.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [s390x] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aggdraw [arm64] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-gmmlib [i386] (disco-proposed/universe) [18.3.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: keyman-config [amd64] (disco-proposed/universe) [10.99.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [i386] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [ppc64el] (disco-proposed/universe) [4.1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [ppc64el] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kickpass [armhf] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [armhf] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [i386] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblingua-en-sentence-perl [amd64] (disco-proposed/universe) [0.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [i386] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [ppc64el] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [amd64] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srslte [ppc64el] (disco-proposed/universe) [18.06.1-7] (no packageset)
<bdmurray> I'm reviewing this unattended-upgrades xenial SRU so nobody steal it from me because its HUGE.
-queuebot:#ubuntu-release- New binary: aggdraw [ppc64el] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [amd64] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-plac [amd64] (disco-proposed/universe) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [arm64] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [amd64] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [i386] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (disco-proposed/universe) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [amd64] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [amd64] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [armhf] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [amd64] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [amd64] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [i386] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [i386] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jaxws [amd64] (disco-proposed/universe) [2.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [i386] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kickpass [ppc64el] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (disco-proposed/universe) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: foma [arm64] (disco-proposed/universe) [1:0.9.18+r243-3] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [amd64] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ascii [ppc64el] (disco-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [i386] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: foma [armhf] (disco-proposed/universe) [1:0.9.18+r243-3] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [arm64] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [ppc64el] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-parking-lot [ppc64el] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [armhf] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [ppc64el] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2godesktopsharing [ppc64el] (disco-proposed/universe) [3.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [arm64] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [armhf] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [arm64] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [armhf] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [ppc64el] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [ppc64el] (disco-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [arm64] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpdas [armhf] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [ppc64el] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [ppc64el] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stdweb [arm64] (disco-proposed/universe) [0.4.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [arm64] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [armhf] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [armhf] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [arm64] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-murmurhash [ppc64el] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [i386] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astrometry.net [armhf] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: astrometry.net [arm64] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: grpc [armhf] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [arm64] (disco-proposed/universe) [1.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-art [arm64] (disco-proposed/universe) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-art [amd64] (disco-proposed/universe) [8.1.0+r23-1] (no packageset)
<bdmurray> rbalint: Working through this SRU I see there are quite a few bugs that are in Launchpad-Bugs-Fixed but shouldn't be. I realize this has been a long process but how do you feel about cleaning those up?
<rbalint> bdmurray, could you please tell an example?
<rbalint> bdmurray, do you mean they are not fixed?
<bdmurray> rbalint: I mean like the merge requests and ones like "LP: #1632361 the bug is referenced mistakenly"
<ubot5> Launchpad bug 1632361 in mysql-5.5 (Ubuntu) "unattended-update installArchives" [Undecided,New] https://launchpad.net/bugs/1632361
<rbalint> bdmurray, there are only a very few of this kind, but if you mark them in the sru but i'm dropping them
<rbalint> in a new upload
<bdmurray> rbalint: well there is also the "already fixed" ones and bug 1357093 which is a dupe
<ubot5> bug 1675079 in unattended-upgrades (Ubuntu Xenial) "duplicate for #1357093 16.04 LTS Partition /boot fills up with Kernel images, gets underwear in a twist" [Undecided,Confirmed] https://launchpad.net/bugs/1675079
<bdmurray> and bug 1737441
<ubot5> bug 1737441 in unattended-upgrades (Ubuntu Bionic) "python-apt crashes if objects of one cache are passed to depcache belonging to another cache" [Undecided,Fix released] https://launchpad.net/bugs/1737441
<rbalint> bdmurray, there is an u-u fix for that but it is untestable practially
<rbalint> bdmurray, the test needs a broken python-apt
<bdmurray> Okay, then I'm saying lets not include it in LP-bugs-Fixed.
<rbalint> bdmurray, i can drop the duplicates, too
<bdmurray> rbalint: That'd be great as it cleanup the rest of the process, no tag flipping or task closing needlessly
<bdmurray> rbalint: Otherwise it all looks good to me.
<jbicha> please remove and blacklist chromium (we already blacklist chromium-browser)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (cosmic-proposed/main) [1:13.0.0-0ubuntu1 => 1:13.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (cosmic-proposed/main) [2:13.0.0-0ubuntu1 => 2:13.0.1-0ubuntu1] (openstack, ubuntu-server)
<rbalint> bdmurray, i uploaded the fixed changes
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.9 => 1.1ubuntu1.18.04.7~16.04.0] (desktop-core, ubuntu-server)
<bdmurray> rbalint: okay, I'll reject the previous one
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.0]
-queuebot:#ubuntu-release- New binary: srslte [arm64] (disco-proposed/universe) [18.06.1-7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.0-0ubuntu4 => 3:14.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.0-0ubuntu2 => 2:14.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnocchi (cosmic-proposed/universe) [4.3.1-0ubuntu4 => 4.3.2-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.0.1-0ubuntu1.1 => 2:18.0.3-0ubuntu1] (openstack, ubuntu-server)
<bdmurray> rbalint: a couple of merges still got through
<bdmurray> 1714019, 1718419, 1722426, 1764797
<infinity> fidencio: You're probably better off having that discussion in Debian (where you'll no doubt find all sorts of engaging opinions on the matter) and then circle back and point us at a cherry-pick when something is decided on and committed to.
-queuebot:#ubuntu-release- New binary: tomcat9 [amd64] (disco-proposed/universe) [9.0.13-1] (no packageset)
<bdmurray> rbalint: I'll just remove them and upload it.
-queuebot:#ubuntu-release- New binary: tifffile [ppc64el] (disco-proposed/universe) [20181128-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [s390x] (disco-proposed/universe) [20181128-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [arm64] (disco-proposed/universe) [20181128-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [armhf] (disco-proposed/universe) [20181128-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [i386] (disco-proposed/universe) [20181128-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [amd64] (disco-proposed/universe) [20181128-1] (no packageset)
-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: rejected unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.0]
<bdmurray> rbalint: Hmm I missed bug 1654600 which seems like it was already fixed in Ubuntu 16.04. You may want to set that back to Fix Released.
<ubot5> bug 1654600 in unattended-upgrades (Ubuntu Xenial) "unattended-upgrade-shutdown hangs when /var is a separate filesystem" [High,Fix committed] https://launchpad.net/bugs/1654600
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.1-0ubuntu1 => 2:13.0.2-0ubuntu1] (openstack, ubuntu-server)
<coreycb> bdmurray: by any chance can I get your opinion on this in terms of how to fix it via an SRU? https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/1806474
<ubot5> Ubuntu bug 1806474 in python-pysnmp4 (Ubuntu) "missing oneliner" [Undecided,New]
<jbicha> yay, another perl upload is on its way
<bdmurray> coreycb: looking
<teward> jbicha: oh dear, so another round of chaos then >.<
<bdmurray> coreycb: I think you need to just SRU the whole thing back to cosmic
<coreycb> bdmurray: ok. do you know if I can do that via a sync?
<bdmurray> coreycb: I don't think so but an AA like infinity would know better
<coreycb> bdmurray: alright. thanks for your input.
<coreycb> vorlon: do you know if a sync can be done for an SRU?
-queuebot:#ubuntu-release- New: accepted android-platform-art [amd64] (disco-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted astrometry.net [ppc64el] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rust-ascii [amd64] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ascii [armhf] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ascii [ppc64el] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-parking-lot [ppc64el] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-stdweb [amd64] (disco-proposed) [0.4.10-1]
-queuebot:#ubuntu-release- New: accepted rust-stdweb [armhf] (disco-proposed) [0.4.10-1]
-queuebot:#ubuntu-release- New: accepted rust-stdweb [ppc64el] (disco-proposed) [0.4.10-1]
-queuebot:#ubuntu-release- New: accepted tifffile [arm64] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New: accepted android-platform-art [arm64] (disco-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted rust-ascii [arm64] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ascii [s390x] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-stdweb [arm64] (disco-proposed) [0.4.10-1]
-queuebot:#ubuntu-release- New: accepted tifffile [amd64] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New: accepted tifffile [i386] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New: accepted tifffile [s390x] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New binary: astrometry.net [amd64] (disco-proposed/universe) [0.76+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: intel-gmmlib [amd64] (disco-proposed/universe) [18.3.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: junixsocket [arm64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astrometry.net [s390x] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rust-parking-lot [s390x] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted tifffile [armhf] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New: accepted tomcat9 [amd64] (disco-proposed) [9.0.13-1]
-queuebot:#ubuntu-release- New binary: junixsocket [amd64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cymem [s390x] (disco-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ascii [i386] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted tifffile [ppc64el] (disco-proposed) [20181128-1]
-queuebot:#ubuntu-release- New binary: kickpass [arm64] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-stdweb [i386] (disco-proposed) [0.4.10-1]
-queuebot:#ubuntu-release- New binary: python-murmurhash [s390x] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [s390x] (disco-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astrometry.net [amd64] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New: accepted astrometry.net [armhf] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New: accepted jaxws [amd64] (disco-proposed) [2.3.0.2-1]
-queuebot:#ubuntu-release- New binary: lsp-mode [amd64] (disco-proposed/universe) [5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [arm64] (disco-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astrometry.net [arm64] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New binary: aggdraw [i386] (disco-proposed/universe) [1.3.7+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astrometry.net [i386] (disco-proposed) [0.76+dfsg-2]
-queuebot:#ubuntu-release- New binary: python-typing-extensions [amd64] (disco-proposed/universe) [3.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted balboa [arm64] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted foma [arm64] (disco-proposed) [1:0.9.18+r243-3]
-queuebot:#ubuntu-release- New: accepted grpc [amd64] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted grpc [armhf] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted junixsocket [ppc64el] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [armhf] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mpdas [arm64] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted mpdas [ppc64el] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [armhf] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [arm64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted balboa [ppc64el] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted grpc [arm64] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [arm64] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mpdas [armhf] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [ppc64el] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [i386] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (disco-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [arm64] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [i386] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted foma [armhf] (disco-proposed) [1:0.9.18+r243-3]
-queuebot:#ubuntu-release- New: accepted libt3widget [ppc64el] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [armhf] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted srslte [arm64] (disco-proposed) [18.06.1-7]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [ppc64el] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted grpc [i386] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [ppc64el] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [arm64] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [armhf] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [arm64] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted balboa [amd64] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted balboa [s390x] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted intel-gmmlib [amd64] (disco-proposed) [18.3.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted junixsocket [armhf] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted keyman-config [amd64] (disco-proposed) [10.99.33-1]
-queuebot:#ubuntu-release- New: accepted kickpass [ppc64el] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [amd64] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mpdas [amd64] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [amd64] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [ppc64el] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted grpc [ppc64el] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted junixsocket [i386] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted liblingua-en-sentence-perl [amd64] (disco-proposed) [0.31-1]
-queuebot:#ubuntu-release- New: accepted mpdas [i386] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [amd64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (disco-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [ppc64el] (disco-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [ppc64el] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New sync: placement (disco-proposed/primary) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted balboa [i386] (disco-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted kickpass [armhf] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [i386] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted srslte [ppc64el] (disco-proposed) [18.06.1-7]
-queuebot:#ubuntu-release- New: accepted zsh-autosuggestions [amd64] (disco-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New source: zhmcclient (disco-proposed/primary) [0.21.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intel-gmmlib [i386] (disco-proposed) [18.3.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted python-plac [amd64] (disco-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New source: python-django-debreach (disco-proposed/primary) [1.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libt3widget [i386] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [amd64] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [amd64] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [i386] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted authheaders [amd64] (disco-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted emacs-lsp-ui [amd64] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted foma [ppc64el] (disco-proposed) [1:0.9.18+r243-3]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-desktop-icons [amd64] (disco-proposed) [18.11~rc-1]
-queuebot:#ubuntu-release- New: accepted grpc [s390x] (disco-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- New: accepted junixsocket [arm64] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted kickpass [amd64] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted kickpass [i386] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [armhf] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted emacs-lsp-haskell [amd64] (disco-proposed) [1.0.20181023-1]
-queuebot:#ubuntu-release- New: accepted foma [s390x] (disco-proposed) [1:0.9.18+r243-3]
-queuebot:#ubuntu-release- New: accepted junixsocket [amd64] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted kickpass [arm64] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [s390x] (disco-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mpdas [s390x] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-cymem [s390x] (disco-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted python-typing-extensions [amd64] (disco-proposed) [3.6.6-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (disco-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted aggdraw [s390x] (disco-proposed) [1.3.7+ds-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gorilla-rpc [amd64] (disco-proposed) [0.0~git20160927.22c016f-2]
-queuebot:#ubuntu-release- New: accepted kickpass [s390x] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted perl6-readline [amd64] (disco-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (disco-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-in-parallel [amd64] (disco-proposed) [0.1.17-1]
-queuebot:#ubuntu-release- New: accepted ruby-pry-byebug [amd64] (disco-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [amd64] (disco-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [armhf] (disco-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted x2godesktopsharing [s390x] (disco-proposed) [3.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted foma [i386] (disco-proposed) [1:0.9.18+r243-3]
-queuebot:#ubuntu-release- New: accepted lsp-mode [amd64] (disco-proposed) [5.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-data-migrate [amd64] (disco-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-stringify-hash [amd64] (disco-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [i386] (disco-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [arm64] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New: accepted x2goserver [i386] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New: accepted junixsocket [s390x] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-open-uri-redirections [amd64] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [amd64] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New: accepted x2goserver [s390x] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New: accepted python-murmurhash [s390x] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [armhf] (disco-proposed) [4.1.0.3-2]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [arm64] (disco-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: cinder (cosmic-proposed/main) [2:13.0.0-0ubuntu4 => 2:13.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: python-preshed [ppc64el] (disco-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-preshed [s390x] (disco-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-preshed [arm64] (disco-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-preshed [armhf] (disco-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-preshed [amd64] (disco-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-beaker-hostgenerator [amd64] (disco-proposed/universe) [1.1.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-preshed [i386] (disco-proposed/universe) [2.0.1-1] (no packageset)
<vorlon> coreycb: a sync /can/ be done for an SRU, but a) you can't sync any version of a package in SRU that was already synced in the devel series, b) doing a sync makes the queue review more awkward and slows down the process a bit
<coreycb> vorlon: ok that won't work then. maybe a fakesync will work.
-queuebot:#ubuntu-release- New binary: intel-media-driver [amd64] (disco-proposed/universe) [18.3.0+dfsg1-1] (no packageset)
<vorlon> coreycb: typically in such situations we'd point to the Security Team's versioning guide, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<coreycb> vorlon: ok, thanks
-queuebot:#ubuntu-release- Unapproved: python-pysnmp4 (cosmic-proposed/main) [4.4.6-1 => 4.4.6+repack1-0ubuntu0.18.10.1] (ubuntu-server)
<fidencio> infinity: right, works for me :-) thanks for the answer!
<bdmurray> jamespage: Are there any plans to update ceph in cosmic? Bug 1796645 will create a version in B > C.
<ubot5> bug 1796645 in Ubuntu Cloud Archive pike "[SRU] ceph 12.2.8" [Medium,Triaged] https://launchpad.net/bugs/1796645
#ubuntu-release 2018-12-04
-queuebot:#ubuntu-release- New binary: php-react-http [amd64] (disco-proposed/none) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ratchetphp [amd64] (disco-proposed/none) [0.4.1-2] (no packageset)
<jamespage> bdmurray: yes - I have an SRU raised to re-introduce 13.2.1 back into cosmic - it sat in proposed all of the release cycle due to a pending MIR which is now completed (including in cosmic)
<jamespage> its in the queue for SRU team review
<jamespage> bdmurray: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1805355
<ubot5> Ubuntu bug 1805355 in ceph (Ubuntu Cosmic) "[SRU] ceph 13.2.1" [High,Triaged]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.11]
-queuebot:#ubuntu-release- New: accepted intel-media-driver [amd64] (disco-proposed) [18.3.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted python-preshed [amd64] (disco-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-preshed [armhf] (disco-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-preshed [ppc64el] (disco-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted ratchetphp [amd64] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted php-react-http [amd64] (disco-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted python-preshed [i386] (disco-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-beaker-hostgenerator [amd64] (disco-proposed) [1.1.22-1]
-queuebot:#ubuntu-release- New: accepted python-preshed [arm64] (disco-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-preshed [s390x] (disco-proposed) [2.0.1-1]
<doko> oSoMoN: are you aware of the lo ftbfs?
<oSoMoN> doko, yes, and I'm looking at it again (IÂ was afk Friday and Monday)
<doko> ta
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1029.34] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1029.34]
<vorlon> dear ruby-kaminari maintainer, no, having a self-build-dependency to make dh_auto_test pass at build time is not sane.
-queuebot:#ubuntu-release- New binary: ruby-kaminari [amd64] (disco-proposed/universe) [1.0.1-4~build2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-kaminari [amd64] (disco-proposed) [1.0.1-4~build2]
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.4 => 239-7ubuntu10.5] (core)
-queuebot:#ubuntu-release- New binary: rust-language-tags [s390x] (disco-proposed/none) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [ppc64el] (disco-proposed/universe) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [amd64] (disco-proposed/universe) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [i386] (disco-proposed/universe) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [arm64] (disco-proposed/universe) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [armhf] (disco-proposed/universe) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-language-tags [amd64] (disco-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [armhf] (disco-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [ppc64el] (disco-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [arm64] (disco-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [s390x] (disco-proposed) [0.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [i386] (disco-proposed) [0.2.2-2]
<vorlon> tsimonq2: do you want qtpim-opensource-src removed? not in Debian, not in cosmic or disco, ftfs for 139 days
<tsimonq2> vorlon: Please do.
<vorlon> tsimonq2: do you want to file a bug before I do?
<vorlon> (not necessarily required)
<tsimonq2> vorlon: I'm currently away from a computer, so up to you, but ack on removing.
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (cosmic-proposed) [3:14.0.0-0ubuntu4.1]
<bdmurray> coreycb: Could you add some SRU information to bug 1806474?
<ubot5> bug 1806474 in python-pysnmp4 (Ubuntu Cosmic) "[SRU] python-pysnmp4 pkg inconsistent in cosmic" [High,Triaged] https://launchpad.net/bugs/1806474
<rbasak> I expect to be starting PHP and MySQL transitions soon.
<rbasak> Who should I coordinate with?
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (cosmic-proposed) [1:13.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (cosmic-proposed) [2:13.0.1-0ubuntu1]
<bdmurray> coreycb: The hozion upload only contains the most LP: # in the changelog in Launchpad-Bugs-Fixed so if you want the other tracked, which I think should be, then you need to reupload with 1802226 in the Launchpad-Bugs-Fixed
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (cosmic-proposed) [2:14.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (cosmic-proposed) [4.3.2-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (cosmic-proposed) [2:13.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.5]
<jbicha> rbasak: what's your solution for pcre2 https://lists.ubuntu.com/archives/ubuntu-devel/2018-November/040542.html ?
<rbasak> jbicha: it looks like a swap of build dep against pcre3 works for PHP.
<rbasak> kstenerud is working on adding a dep8 test for pcre to make sure it doesn't break things.
<rbasak> But assuming it works, the plan is to use pcre3 for now, but we'll be ready to transition to pcre2 trivially at any time.
<rbasak> How does that sound?
<jbicha> it sounds like good news and bad news at the same time to me :)
<rbasak> :)
<rbasak> I wonder how much pain it will be to switch from 3->2 in PHP later. But it's just work and we'll be able to do it, and the only reason not to do it is if a pcre2 transition in main is imminent, which AFAICT it is not.
-queuebot:#ubuntu-release- New binary: progressivemauve [s390x] (disco-proposed/universe) [1.2.0+4713+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bloscpack [ppc64el] (disco-proposed/universe) [0.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: progressivemauve [ppc64el] (disco-proposed/universe) [1.2.0+4713+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-pkix [ppc64el] (disco-proposed/universe) [0.2018.11.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lagan [ppc64el] (disco-proposed/universe) [2.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [ppc64el] (disco-proposed/universe) [0.9~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcb-imdkit [ppc64el] (disco-proposed/universe) [0~20171205+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bloscpack [s390x] (disco-proposed/universe) [0.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lagan [s390x] (disco-proposed/universe) [2.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-pkix [s390x] (disco-proposed/universe) [0.2018.11.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcb-imdkit [s390x] (disco-proposed/universe) [0~20171205+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [s390x] (disco-proposed/universe) [0.9~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-platform-ui [amd64] (disco-proposed/universe) [4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bloscpack [amd64] (disco-proposed/universe) [0.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: progressivemauve [i386] (disco-proposed/universe) [1.2.0+4713+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-beaker [amd64] (disco-proposed/universe) [4.1.0-1] (no packageset)
<smoser> hi. i'd like an sru team member to take a look at open-iscsi in bionic.
-queuebot:#ubuntu-release- New binary: erlang-p1-pkix [i386] (disco-proposed/universe) [0.2018.11.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lagan [i386] (disco-proposed/universe) [2.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lagan [amd64] (disco-proposed/universe) [2.0-3] (no packageset)
<smoser> currently blocked due to resource-agents on arm64
<smoser>  https://autopkgtest.ubuntu.com/packages/resource-agents/bionic/armhf
<smoser> errr s/arm64/armhf/
<rbasak> jbicha: FWIW, I'm intending to reply to your post on ubuntu-devel@ as soon as we have confirmation that the pcre3 switch will work. Thank you for posting that mail.
<smoser> it seems that particular test is finicky at best and the accepted practice is 'push rerun a couple times and then ignore'
<smoser> i pushed rerun, but it seems like the odds are not in my favor of it passing.
<smoser> bdmurray: its your 'sru day" today. are you able to look at that?
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [amd64] (disco-proposed) [4.9-1]
-queuebot:#ubuntu-release- New binary: erlang-p1-pkix [amd64] (disco-proposed/universe) [0.2018.11.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcb-imdkit [i386] (disco-proposed/universe) [0~20171205+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted puppet-beaker [amd64] (disco-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New binary: gr-limesdr [i386] (disco-proposed/universe) [0.9~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [amd64] (disco-proposed/universe) [0.9~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: manuskript [amd64] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: system-packages-el [amd64] (disco-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: magic-wormhole-mailbox-server [amd64] (disco-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcb-imdkit [amd64] (disco-proposed/universe) [0~20171205+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: progressivemauve [amd64] (disco-proposed/universe) [1.2.0+4713+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted magic-wormhole-mailbox-server [amd64] (disco-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted xcb-imdkit [amd64] (disco-proposed) [0~20171205+ds1-1]
-queuebot:#ubuntu-release- New: accepted manuskript [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted bloscpack [amd64] (disco-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-pkix [i386] (disco-proposed) [0.2018.11.12-1]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [i386] (disco-proposed) [0.9~beta-1]
-queuebot:#ubuntu-release- New: accepted lagan [i386] (disco-proposed) [2.0-3]
-queuebot:#ubuntu-release- New: accepted system-packages-el [amd64] (disco-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-pkix [amd64] (disco-proposed) [0.2018.11.12-1]
-queuebot:#ubuntu-release- New: accepted lagan [amd64] (disco-proposed) [2.0-3]
-queuebot:#ubuntu-release- New: accepted xcb-imdkit [i386] (disco-proposed) [0~20171205+ds1-1]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [amd64] (disco-proposed) [0.9~beta-1]
-queuebot:#ubuntu-release- New: accepted progressivemauve [amd64] (disco-proposed) [1.2.0+4713+dfsg-4]
-queuebot:#ubuntu-release- New: accepted bloscpack [s390x] (disco-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [ppc64el] (disco-proposed) [0.9~beta-1]
-queuebot:#ubuntu-release- New: accepted lagan [ppc64el] (disco-proposed) [2.0-3]
-queuebot:#ubuntu-release- New: accepted progressivemauve [i386] (disco-proposed) [1.2.0+4713+dfsg-4]
-queuebot:#ubuntu-release- New: accepted xcb-imdkit [s390x] (disco-proposed) [0~20171205+ds1-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-pkix [s390x] (disco-proposed) [0.2018.11.12-1]
-queuebot:#ubuntu-release- New: accepted lagan [s390x] (disco-proposed) [2.0-3]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [s390x] (disco-proposed) [0.9~beta-1]
-queuebot:#ubuntu-release- New: accepted xcb-imdkit [ppc64el] (disco-proposed) [0~20171205+ds1-1]
-queuebot:#ubuntu-release- New: accepted bloscpack [ppc64el] (disco-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted progressivemauve [ppc64el] (disco-proposed) [1.2.0+4713+dfsg-4]
-queuebot:#ubuntu-release- New: accepted erlang-p1-pkix [ppc64el] (disco-proposed) [0.2018.11.12-1]
-queuebot:#ubuntu-release- New: accepted progressivemauve [s390x] (disco-proposed) [1.2.0+4713+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (bionic-proposed) [3.28.2-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (bionic-proposed) [1:6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (bionic-proposed) [1:12.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (bionic-proposed) [4.2.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected rustc [source] (bionic-proposed) [1.29.2+dfsg1+llvm-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (trusty-proposed) [3.8.4-0ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted hwdata [source] (trusty-proposed) [0.249-1ubuntu1]
<bdmurray> smoser: can you add some comment about the tests to the open-iscsi bug report?
-queuebot:#ubuntu-release- Unapproved: landscape-client (cosmic-proposed/main) [18.01-0ubuntu4 => 18.01-0ubuntu4.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3.1 => 18.01-0ubuntu3.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2.16.04.4 => 16.03-0ubuntu2.16.04.5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu6.14.04.3 => 14.12-0ubuntu6.14.04.4] (ubuntu-desktop, ubuntu-server)
<smoser> bdmurray: ok.
<smoser> bdmurray: done.
<bdmurray> cyphermox: so vorlon's comments in bug 1770082 apply to every previously verified netplan bug e.g. https://bugs.launchpad.net/netplan/+bug/1771704/comments/14?
<ubot5> Ubuntu bug 1771704 in netplan.io (Ubuntu Bionic) "support for ipv4 link-local addressing" [Undecided,Fix committed]
<ubot5> bug 1770082 in systemd (Ubuntu) "systemd-networkd not renaming devices on boot" [Undecided,Confirmed] https://launchpad.net/bugs/1770082
<cyphermox> bdmurray: that was our understanding.
<cyphermox> vorlon: ?  ^^
-queuebot:#ubuntu-release- New binary: resteasy [amd64] (disco-proposed/universe) [3.6.2-1] (no packageset)
#ubuntu-release 2018-12-05
<vorlon> cyphermox, bdmurray: yes
-queuebot:#ubuntu-release- New binary: node-modern-syslog [ppc64el] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-snapdragon-node [amd64] (disco-proposed/none) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-snapdragon-util [amd64] (disco-proposed/none) [5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-modern-syslog [s390x] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-snapdragon-token [amd64] (disco-proposed/none) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-modern-syslog [i386] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-modern-syslog [amd64] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-modern-syslog [arm64] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-modern-syslog [armhf] (disco-proposed/none) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [amd64] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [armhf] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [ppc64el] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-snapdragon-node [amd64] (disco-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted node-snapdragon-util [amd64] (disco-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [arm64] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [s390x] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted resteasy [amd64] (disco-proposed) [3.6.2-1]
-queuebot:#ubuntu-release- New: accepted node-modern-syslog [i386] (disco-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-snapdragon-token [amd64] (disco-proposed) [4.0.0-1]
<vorlon> rbalint: it's pointed out on LP: #1686470 that this bug is already fixed in xenial via SRU so maybe shouldn't be in the changelog as a change for the new SRU
<ubot5> Launchpad bug 1686470 in unattended-upgrades (Ubuntu Xenial) "Apt updates that are uniformly spread across all timezones, with predictable application windows" [High,Fix committed] https://launchpad.net/bugs/1686470
<LocutusOfBorg> hello anybody looking at xpdf?
<LocutusOfBorg> I have a mostly complete patch, but I failed in one simple thing :/
<Laney> syes
<Laney> -s
<Laney> sye?
<rbalint> vorlon, indeed, if i have to reupload the update i'm fixing that
<coreycb> bdmurray: sorry, I was out yesterday. I've added SRU details to bug 1806474
<ubot5> bug 1806474 in python-pysnmp4 (Ubuntu Cosmic) "[SRU] python-pysnmp4 pkg inconsistent in cosmic" [High,Triaged] https://launchpad.net/bugs/1806474
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.3-0ubuntu0.18.04.3 => 3.28.3-0ubuntu0.18.04.4] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (cosmic-proposed/main) [3.30.1-2ubuntu1.18.10.1 => 3.30.1-2ubuntu1.18.10.2] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.0-0ubuntu4 => 3:14.0.1-0ubuntu1] (openstack, ubuntu-server)
<coreycb> bdmurray: i've uploaded a new version of horizon to the cosmic unapproved queue with the changelog fixed up to include both bugs. thanks for the reviews!
<coreycb> hello archive admins, can someone take a look into accepting python-django-debreach and placement from the disco NEW queue? this will help unblock openstack horizon and allow us to start testing openstack placement for stein.
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20181120.1-0ubuntu0.18.04.1 => 1:20181205.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20181120.1-0ubuntu0.14.04.1 => 1:20181205.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20181120.1-0ubuntu0.18.10.1 => 1:20181205.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20181120.1-0ubuntu0.16.04.1 => 1:20181205.1-0ubuntu0.16.04.1] (no packageset)
<doko> vorlon: please ignore the libreoffice/1:6.1.3-0ubuntu6 failure triggered by gcc-7, now that the trigger is removed
<vorlon> doko: done
<vorlon> coreycb: do you have any reason to care about python-happybase?  There's a newer upstream version in Ubuntu that you uploaded, but in Debian it's been removed as obsolete.  There are no revdeps.
<coreycb> vorlon: it doesn't look like we need it anymore, feel free to drop it
<coreycb> vorlon: by any chance could you help push along my python-django-debreach and placement request above?
<vorlon> let's see
<vorlon> coreycb: stale standards version in a new package? I: python-django-debreach source: out-of-date-standards-version 4.1.1 (released 2017-09-27) (current is 4.2.1)
<vorlon> coreycb: debian/copyright claims you hold the copyright; should this not be Canonical?
<coreycb> vorlon: let me fix those up
<vorlon> coreycb: fwiw I expect you shouldn't need to pass -O--buildsystem=python_distutils to dh_clean, that it would pick it up from the environment since you've already passed it to dh
-queuebot:#ubuntu-release- New source: python-django-debreach (disco-proposed/primary) [1.5.2-0ubuntu1]
<coreycb> vorlon: possibly so. i'll test to see. i did just upload a new version. if needed i'll fix the dh_clean rule for our next upload.
-queuebot:#ubuntu-release- New: rejected python-django-debreach [source] (disco-proposed) [1.5.2-0ubuntu1]
<jbicha> vorlon: could you remove mudlet & mysql-workbench for libzip transition? & plume-creator for hunspell? All 3 were removed from Debian Testing
-queuebot:#ubuntu-release- New: accepted python-django-debreach [source] (disco-proposed) [1.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-django-debreach [amd64] (disco-proposed/none) [1.5.2-0ubuntu1] (no packageset)
<vorlon> I: placement source: duplicate-short-description placement-api placement-common
<vorlon> W: placement source: package-has-a-duplicate-build-relation python3-pbr (>= 2.0.0), python3-pbr (>= 2.0.0)
<vorlon> I: placement source: out-of-date-standards-version 4.1.4 (released 2018-04-05) (current is 4.2.1)
<vorlon> W: placement source: unnecessary-testsuite-autopkgtest-field
<vorlon> coreycb: ^^
<vorlon> jbicha: will look
<coreycb> vorlon: looking
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20181205.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20181205.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20181205.1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20181205.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted python-django-debreach [amd64] (disco-proposed) [1.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New source: placement (disco-proposed/primary) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
<coreycb> vorlon: i've fixed those in a new upload of placement
<doko> jbicha: did you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/i386/r/ruby-rmagick/20181205_140537_fe274@/log.gz ?
-queuebot:#ubuntu-release- New: rejected placement [sync] (disco-proposed) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
<roaksoax> exit/win 5
<vorlon> coreycb: debian/copyright in placement also
<coreycb> vorlon: ok will fix that up shortly
<vorlon> https://launchpad.net/ubuntu/+source/libedlib/1.2.3-3 is crazy... debian/edlib-alignment exists, at a point before anything should've created it
<vorlon> and if I manually step through dh build-arch --no-act it doesn't happen :P
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (cosmic-proposed) [3:14.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pysnmp4 [source] (cosmic-proposed) [4.4.6+repack1-0ubuntu0.18.10.1]
<coreycb> vorlon: alright that's fixed, sorry for the delay
-queuebot:#ubuntu-release- New source: placement (disco-proposed/primary) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
<jbicha> doko: I don't know ruby so I don't think I can help much there with that crash
<doko> vorlon: please subscribe the fonts team to fonts-yrsa-rasa, so we can promote it
-queuebot:#ubuntu-release- New: rejected placement [source] (disco-proposed) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted placement [source] (disco-proposed) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
-queuebot:#ubuntu-release- New binary: placement [amd64] (disco-proposed/universe) [0.0.1~git2018112616.3ccbacfc-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ceilometer (cosmic-proposed/main) [1:11.0.0-0ubuntu2 => 1:11.0.1-0ubuntu1] (openstack, ubuntu-server)
<coreycb> bdmurray: i just uploaded ceilometer for bug 1806049. if you have a moment, ceilometer and nova are the only ones remaining in the queue for that SRU. also keystone and nova are in the queue for bug 1806043.
<ubot5> bug 1806049 in nova (Ubuntu Cosmic) "[SRU] rocky stable releases" [High,Triaged] https://launchpad.net/bugs/1806049
<ubot5> bug 1806043 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1806043
<cyphermox> bdmurray: since you have the context on netplan.io; could I convince you to look at it for bionic SRU currently in -proposed?
<bdmurray> coreycb, cyphermox: noted
<bdmurray> coreycb: there is an existing SRU for nova in cosmic, should the existing upload supersede it?
<cyphermox> ta
<coreycb> bdmurray: ah ok let me batch those together and re-upload
<bdmurray> coreycb: I mean there is one in -proposed that hasn't been verified yet
<coreycb> bdmurray: right, i think what i'll do is upload a new version with that included and it will just have to be in proposed another 7 days
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (cosmic-proposed) [1:11.0.1-0ubuntu1]
<coreycb> bdmurray: if that is ok, that is. i don't want to hold off the stable release much longer.
<bdmurray> coreycb: its fine with you me, you are a better judge of how imporant bug 1744079 is
<ubot5> bug 1744079 in OpenStack Compute (nova) rocky "[SRU] disk over-commit still not correctly calculated during live migration" [Low,In progress] https://launchpad.net/bugs/1744079
<coreycb> bdmurray: ok
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (bionic-proposed) [2:13.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.0.1-0ubuntu1.1 => 2:18.0.3-0ubuntu1] (openstack, ubuntu-server)
<coreycb> bdmurray: alright i've uploaded a new nova
<jbicha> vorlon: could you jump-start the autopkgtest queue? it looks like perl & nodejs teamed up to take it down again
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (cosmic-proposed) [2:18.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.0.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: bmusb [ppc64el] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [s390x] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [i386] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen-lvs [ppc64el] (disco-proposed/none) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orocos-bfl [ppc64el] (disco-proposed/universe) [0.8.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [amd64] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [ppc64el] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [ppc64el] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geos [s390x] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [ppc64el] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: pyjavaproperties [amd64] (disco-proposed/universe) [0.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen-lvs [s390x] (disco-proposed/universe) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orocos-bfl [s390x] (disco-proposed/universe) [0.8.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [s390x] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [s390x] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen-lvs [i386] (disco-proposed/universe) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [amd64] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-oci [amd64] (disco-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen-lvs [amd64] (disco-proposed/universe) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-graphlibrary [amd64] (disco-proposed/universe) [2.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orocos-bfl [i386] (disco-proposed/universe) [0.8.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-pol [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orocos-bfl [amd64] (disco-proposed/universe) [0.8.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: node-chart.js [amd64] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-szl [amd64] (disco-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-columnify [amd64] (disco-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [i386] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sdp-jingle-json [amd64] (disco-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vagrant-hostmanager [amd64] (disco-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-rollup-plugin-typescript [amd64] (disco-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [i386] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [amd64] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted apertium-oci [amd64] (disco-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted apertium-szl [amd64] (disco-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-graphlibrary [amd64] (disco-proposed) [2.2.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: node-chrome-trace-event [amd64] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-shiny-server-client [amd64] (disco-proposed/universe) [1.0.0+git20180820.eba5e90+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-xmldom [amd64] (disco-proposed/universe) [0.1.27+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted apertium-pol [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted placement [amd64] (disco-proposed) [0.0.1~git2018112616.3ccbacfc-0ubuntu1]
-queuebot:#ubuntu-release- New binary: node-worker-loader [amd64] (disco-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-chart.js [amd64] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New binary: node-html5shiv [amd64] (disco-proposed/universe) [3.7.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-chrome-trace-event [amd64] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-html5shiv [amd64] (disco-proposed) [3.7.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-sdp-jingle-json [amd64] (disco-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted node-worker-loader [amd64] (disco-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted vagrant-hostmanager [amd64] (disco-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted node-columnify [amd64] (disco-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted node-shiny-server-client [amd64] (disco-proposed) [1.0.0+git20180820.eba5e90+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-typescript [amd64] (disco-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted node-xmldom [amd64] (disco-proposed) [0.1.27+ds-1]
-queuebot:#ubuntu-release- New binary: bmusb [arm64] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-wildemitter [amd64] (disco-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyjavaproperties [amd64] (disco-proposed) [0.6-3]
-queuebot:#ubuntu-release- New binary: twitter-bootstrap4 [amd64] (disco-proposed/universe) [4.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-timeago.js [amd64] (disco-proposed/universe) [3.0.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [armhf] (disco-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-timeago.js [amd64] (disco-proposed) [3.0.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted twitter-bootstrap4 [amd64] (disco-proposed) [4.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-wildemitter [amd64] (disco-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted bmusb [amd64] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [armhf] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [ppc64el] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New binary: yaml-cpp [s390x] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted bmusb [arm64] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [s390x] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted bmusb [i386] (disco-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New binary: yaml-cpp [ppc64el] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [amd64] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: yaml-cpp [amd64] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [i386] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: yaml-cpp [i386] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [arm64] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [armhf] (disco-proposed/universe) [3.7.1-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted geos [amd64] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New: accepted geos [armhf] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New: accepted geos [ppc64el] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New: accepted geos [arm64] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New: accepted geos [s390x] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New: accepted geos [i386] (disco-proposed) [3.7.1-1]
-queuebot:#ubuntu-release- New binary: netgen-lvs [arm64] (disco-proposed/universe) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen-lvs [armhf] (disco-proposed/universe) [1.5.107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orocos-bfl [arm64] (disco-proposed/universe) [0.8.0-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted netgen-lvs [amd64] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New: accepted netgen-lvs [armhf] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New: accepted netgen-lvs [ppc64el] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New binary: pg-fact-loader [arm64] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted netgen-lvs [arm64] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New: accepted netgen-lvs [s390x] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New: accepted netgen-lvs [i386] (disco-proposed) [1.5.107-1]
-queuebot:#ubuntu-release- New binary: orocos-bfl [armhf] (disco-proposed/universe) [0.8.0-5] (no packageset)
#ubuntu-release 2018-12-06
-queuebot:#ubuntu-release- New binary: pglogical-ticker [arm64] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libyang [armhf] (disco-proposed/universe) [0.16.52-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [armhf] (disco-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [armhf] (disco-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [amd64] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [armhf] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [ppc64el] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [arm64] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [s390x] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [i386] (disco-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [amd64] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [armhf] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [ppc64el] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [arm64] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [s390x] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [i386] (disco-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [amd64] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [armhf] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [ppc64el] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [arm64] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [s390x] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New: accepted orocos-bfl [i386] (disco-proposed) [0.8.0-5]
-queuebot:#ubuntu-release- New binary: yaml-cpp [arm64] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: yaml-cpp [armhf] (disco-proposed/universe) [0.6.2-1ubuntu1] (kubuntu)
<vorlon> doko: desktop team subscribed to fonts-yrsa-rasa (there is no fonts team on http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html)
<vorlon> jbicha: did whatever the issue was w/ autopkgtest queues get sorted, or do I still need to look at something?
<jbicha> vorlon: it's not been sorted, I did some retries to get something in the queue but maybe you'd be able to reset it more effectively
<vorlon> jbicha: by 'reset' you mean requeue all lost test requests?
<vorlon> apparently Laney knows a way to do that efficiently server-side, but I think I might just use retry-failed-autopkgtests
<vorlon> all bugs about fonts-yrsa-rasa
<vorlon> retry-autopkgtest-regressions rather
-queuebot:#ubuntu-release- New binary: cheesecutter [amd64] (disco-proposed/universe) [2.9+git20181112-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cheesecutter [i386] (disco-proposed/universe) [2.9+git20181112-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cheesecutter [armhf] (disco-proposed/universe) [2.9+git20181112-1] (no packageset)
<vorlon> coreycb: I see that vmware-nsx-common has been removed from Debian as per Debian bug #897331.  It has no revdeps, but you've been updating it; do you still want it?
<ubot5> Debian bug 897331 in ftp.debian.org "RM: vmware-nsx -- ROM; Not needed, FTBFS, closed source solution" [Normal,Open] http://bugs.debian.org/897331
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-13.14] (core, kernel)
<Laney> vorlon: delete pending.json when britney isn't running
<Laney> would you like to look into whatever is happening with rabbit?
<vorlon> Laney: no, I would like to delegate it to someone else on Foundations :)
<Laney> sounds good to me
<Laney> I thought that last time this came up we modified stuff so the requests would get written out to disk, which meant that a restart of rabbitmq wouldn't lose jobs
<Laney> apparently that didn't work either...
<vorlon> I don't know, I don't think I was part of that
-queuebot:#ubuntu-release- New sync: opensaml (disco-proposed/primary) [3.0.0-2]
<Laney> https://git.launchpad.net/autopkgtest-cloud/commit/?id=b896ef84ff70dfd6cd66cc9fd59df98453284652
<Laney> but https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/autopkgtest.py#n614
<Laney> probably needs that treatment too
-queuebot:#ubuntu-release- New sync: shibboleth-sp (disco-proposed/primary) [3.0.2+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted opensaml [sync] (disco-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [sync] (disco-proposed) [3.0.2+dfsg1-2]
<Laney> if we upgrade to bionic then https://www.rabbitmq.com/lazy-queues.html becomes available
-queuebot:#ubuntu-release- New binary: opensaml [s390x] (disco-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cheesecutter [amd64] (disco-proposed) [2.9+git20181112-1]
-queuebot:#ubuntu-release- New: accepted cheesecutter [i386] (disco-proposed) [2.9+git20181112-1]
-queuebot:#ubuntu-release- New: accepted opensaml [s390x] (disco-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted cheesecutter [armhf] (disco-proposed) [2.9+git20181112-1]
-queuebot:#ubuntu-release- New: accepted libyang [armhf] (disco-proposed) [0.16.52-1]
-queuebot:#ubuntu-release- New binary: opensaml [i386] (disco-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [amd64] (disco-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted opensaml [amd64] (disco-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted opensaml [i386] (disco-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1005.6] (kernel)
<Laney> k, britney is pushed too now
-queuebot:#ubuntu-release- New binary: shibboleth-sp [s390x] (disco-proposed/universe) [3.0.2+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [ppc64el] (disco-proposed/universe) [3.0.2+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [i386] (disco-proposed/universe) [3.0.2+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [i386] (disco-proposed) [3.0.2+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [s390x] (disco-proposed) [3.0.2+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [ppc64el] (disco-proposed) [3.0.2+dfsg1-2]
-queuebot:#ubuntu-release- New binary: shibboleth-sp [amd64] (disco-proposed/universe) [3.0.2+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [amd64] (disco-proposed) [3.0.2+dfsg1-2]
<Laney> vorlon: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#re-queueing_all_outstanding_test_requests
<vorlon> Laney: woot
-queuebot:#ubuntu-release- New: accepted yaml-cpp [amd64] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted yaml-cpp [armhf] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted yaml-cpp [ppc64el] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted yaml-cpp [arm64] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted yaml-cpp [s390x] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted yaml-cpp [i386] (disco-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mountall (trusty-proposed/main) [2.53 => 2.53ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1005.6]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-13.14]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-164.214] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-164.214]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-141.167] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-141.167]
<coreycb> vorlon: yes we'll continue to support vmware-nsx
<vorlon> coreycb: ok
<coreycb> sil2100: hi, if you have a moment today could you take a look at accepting nova for bug 1806043 ?
<ubot5> bug 1806043 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1806043
<sil2100> coreycb: I will do my SRU round today when I back to the hotel (if we have internet)
<coreycb> sil2100: ok thanks :)
<jbicha> Laney: it looks to me like britney stopped running when you did the rabbit stuff earlier https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<vorlon> jamespage: is LP: #1755061 something you're planning on verifying for 14.04?
<ubot5> Launchpad bug 1755061 in haproxy (Ubuntu Trusty) "HAProxyContext on Ubuntu 14.04 generates config that fails to start on boot" [High,Fix committed] https://launchpad.net/bugs/1755061
<jamespage> vorlon: I should - so will - now on my todo list for this week
<vorlon> jamespage: ta
<Laney> jbicha: I know, I pushed a fix for that a few minutes ago, next run should get it
<vorlon> tsimonq2: LP: #1786337 either needs a better test case or someone to run it who has an actual API key
<ubot5> Launchpad bug 1786337 in python-phabricator (Debian) "diffusion.querycommits deprecated in favor of diffusion.commit.search which support hasn't been merged for yet" [Unknown,New] https://launchpad.net/bugs/1786337
<tsimonq2> vorlon: I have an API key
<tsimonq2> It's on my list, sorry.
<vorlon> ok
<tsimonq2> vorlon: Near the top of my list (because it has a bounty) is that mate-screensaver SRU in the Bionic queue though.
<tsimonq2> Processing of that would be much appreciated.
-queuebot:#ubuntu-release- Unapproved: cups (cosmic-proposed/main) [2.2.8-5ubuntu1 => 2.2.8-5ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu2.1 => 2.2.7-1ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.5 => 2.1.3-4ubuntu0.6] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [4.19.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [4.19.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: o2 [s390x] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librtr [ppc64el] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [ppc64el] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [ppc64el] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: o2 [ppc64el] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [s390x] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [s390x] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [ppc64el] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [s390x] (disco-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-dpkt [amd64] (disco-proposed/universe) [1.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [s390x] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [s390x] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: darknet [ppc64el] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [ppc64el] (disco-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: darknet [s390x] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [ppc64el] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librtr [amd64] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [amd64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: o2 [i386] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [i386] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: o2 [amd64] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [amd64] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librtr [i386] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-strings [amd64] (disco-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-symfony-contracts [amd64] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-zlibbioc [amd64] (disco-proposed/universe) [1.28.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsgiproxy2 [amd64] (disco-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vland [amd64] (disco-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [i386] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ratchet-pawl [amd64] (disco-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-generics [amd64] (disco-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [i386] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [amd64] (disco-proposed/universe) [2] (no packageset)
<LocutusOfBorg> release team, PLEASE KICK OUT LLVM-TOOLCHAIN-7 out from disco-proposed, thx
-queuebot:#ubuntu-release- New binary: python-msgpack-numpy [amd64] (disco-proposed/universe) [0.4.4-1] (no packageset)
<LocutusOfBorg> on i386, the clang binary is missing the "+x" bit
<LocutusOfBorg> I don't know why, we are debugging and debian has no issue :/
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/hedgewars/0.9.25-2 this is the failure I got with cmake detection
<LocutusOfBorg> please kick it out!
-queuebot:#ubuntu-release- New binary: darknet [i386] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-vcr [amd64] (disco-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: darknet [amd64] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [i386] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [i386] (disco-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [amd64] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [amd64] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librtr [arm64] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: o2 [arm64] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librtr [armhf] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: o2 [armhf] (disco-proposed/universe) [1.0~repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [armhf] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ptmap [arm64] (disco-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [arm64] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pd-csound [armhf] (disco-proposed/universe) [2:1.01.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [armhf] (disco-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [armhf] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntex-errors [arm64] (disco-proposed/universe) [0.59.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dsmidiwifi [arm64] (disco-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: darknet [arm64] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [arm64] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: darknet [armhf] (disco-proposed/universe) [0.0.0+git20180914.61c9d02e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cytoolz [armhf] (disco-proposed/universe) [0.9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-cytoolz [amd64] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-cytoolz [armhf] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-cytoolz [ppc64el] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-dpkt [amd64] (disco-proposed) [1.9.1-1]
-queuebot:#ubuntu-release- New: accepted wsgiproxy2 [amd64] (disco-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted python-cytoolz [arm64] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-cytoolz [s390x] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-cytoolz [i386] (disco-proposed) [0.9.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-msgpack-numpy [amd64] (disco-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [amd64] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [armhf] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [ppc64el] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [arm64] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [s390x] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted rust-syntex-errors [i386] (disco-proposed) [0.59.1-1]
-queuebot:#ubuntu-release- New: accepted darknet [amd64] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted darknet [armhf] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted darknet [ppc64el] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted o2 [amd64] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted o2 [armhf] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted o2 [ppc64el] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted darknet [arm64] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted darknet [s390x] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted o2 [i386] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted darknet [i386] (disco-proposed) [0.0.0+git20180914.61c9d02e-1]
-queuebot:#ubuntu-release- New: accepted o2 [s390x] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted o2 [arm64] (disco-proposed) [1.0~repack-1]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [amd64] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [armhf] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [ppc64el] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [arm64] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [s390x] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted dsmidiwifi [i386] (disco-proposed) [2]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [amd64] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [armhf] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [ppc64el] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [amd64] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [armhf] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [ppc64el] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [arm64] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [s390x] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [i386] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ptmap [i386] (disco-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [s390x] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted pd-csound [arm64] (disco-proposed) [2:1.01.0-1]
-queuebot:#ubuntu-release- New: accepted librtr [amd64] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted librtr [armhf] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted librtr [ppc64el] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted librtr [arm64] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted librtr [i386] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted php-symfony-contracts [amd64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-zlibbioc [amd64] (disco-proposed) [1.28.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ratchet-pawl [amd64] (disco-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted vland [amd64] (disco-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted puppet-strings [amd64] (disco-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-vcr [amd64] (disco-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-generics [amd64] (disco-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New binary: python-thinc [s390x] (disco-proposed/universe) [6.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thinc [ppc64el] (disco-proposed/universe) [6.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thinc [armhf] (disco-proposed/universe) [6.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thinc [amd64] (disco-proposed/universe) [6.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thinc [i386] (disco-proposed/universe) [6.12.1-1] (no packageset)
<tsimonq2> infinity, vorlon: Can I please get a review of mate-screensaver in the Bionic queue?
-queuebot:#ubuntu-release- New: accepted python-thinc [amd64] (disco-proposed) [6.12.1-1]
-queuebot:#ubuntu-release- New: accepted python-thinc [i386] (disco-proposed) [6.12.1-1]
-queuebot:#ubuntu-release- New: accepted python-thinc [s390x] (disco-proposed) [6.12.1-1]
-queuebot:#ubuntu-release- New: accepted python-thinc [armhf] (disco-proposed) [6.12.1-1]
-queuebot:#ubuntu-release- New: accepted python-thinc [ppc64el] (disco-proposed) [6.12.1-1]
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [ppc64el] (disco-proposed/none) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [s390x] (disco-proposed/none) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piexif [amd64] (disco-proposed/universe) [1.0.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [amd64] (disco-proposed/universe) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [i386] (disco-proposed/universe) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [arm64] (disco-proposed/universe) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rcppannoy [armhf] (disco-proposed/universe) [0.0.11-1] (no packageset)
#ubuntu-release 2018-12-07
-queuebot:#ubuntu-release- New binary: freedict-wikdict [amd64] (disco-proposed/universe) [2018.11.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [s390x] (disco-proposed/none) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [amd64] (disco-proposed/none) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [ppc64el] (disco-proposed/none) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lemonldap-ng [amd64] (disco-proposed/universe) [2.0.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [i386] (disco-proposed/none) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [arm64] (disco-proposed/universe) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fnn [armhf] (disco-proposed/universe) [1.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (bionic-proposed/main) [4.18.0-1007.7~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1007.7] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (bionic-proposed) [4.18.0-1007.7~18.04.1]
<sil2100> coreycb: hey! I'm looking at nova now (apologies, yesterday was a busy day) - I see that your SRU overwrites the already present in -proposed LP: #1744079
<ubot5> Launchpad bug 1744079 in OpenStack Compute (nova) rocky "[SRU] disk over-commit still not correctly calculated during live migration" [Low,In progress] https://launchpad.net/bugs/1744079
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1007.7]
<cpaelzer> someone around that could promote libtspi1 from src.trousers based on  bug 247590?
<ubot5> bug 247590 in trousers (Ubuntu) "main inclusion request: trousers" [Undecided,Fix released] https://launchpad.net/bugs/247590
<cpaelzer> the dependency pulling it in main was very old, lost for B&C, but now back again
<cpaelzer> so I thnik all (old) paper work is done
<cpaelzer> just needs an AA to do that
<cpaelzer> maybe I should add a Disco task to the old MIR and set the AA's to the bug?
-queuebot:#ubuntu-release- New: accepted lemonldap-ng [amd64] (disco-proposed) [2.0.0+ds-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [arm64] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [i386] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [s390x] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [amd64] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [ppc64el] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fnn [armhf] (disco-proposed) [1.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted freedict-wikdict [amd64] (disco-proposed) [2018.11.02-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [amd64] (disco-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [armhf] (disco-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [ppc64el] (disco-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New: accepted piexif [amd64] (disco-proposed) [1.0.13-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [i386] (disco-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [arm64] (disco-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rcppannoy [s390x] (disco-proposed) [0.0.11-1]
<acheronuk> vorlon, infinity etc. could ypou assist into getting this change merged and uploaded? https://code.launchpad.net/~rikmills/ubiquity/+git/ubiquity/+merge/359785
<acheronuk> Kubuntu has not had a working daily iso for over a week now
<vorlon> looking
<acheronuk> I built the change in my ppa and tested
<vorlon> acheronuk: uploaded
<acheronuk> vorlon: great. thank you
<acheronuk> vorlon: um. failed to build. needs the d-i update stuff run when making source?
<vorlon> tsimonq2: this mate-screensaver upload is a binary sync from https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa and I don't know the properties of this ppa to see that it's appropriate for binary copy to the main archive (since I'm not a member of the team).  Either get me a non-binary upload to the queue, or get someone from the security team to sign off that this is an ok source
<vorlon> for copying?
<vorlon> acheronuk: hngh haaaate. ok.
 * acheronuk agrees with vorlon on that ^^^
 * vorlon pines for the good old days of bzr-builddeb hooks
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1005.6~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1005.6~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (cosmic-proposed) [18.01-0ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (bionic-proposed) [18.01-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.5]
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (trusty-proposed) [14.12-0ubuntu6.14.04.4]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [4.19.0-8.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [4.19.0-8.9]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1036.38] (kernel)
-queuebot:#ubuntu-release- New source: egl-wayland (disco-proposed/primary) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1036.38~14.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1036.38]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1026.27] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1036.38~14.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1026.27]
-queuebot:#ubuntu-release- Unapproved: e2fsprogs (cosmic-proposed/main) [1.44.4-2 => 1.44.4-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-43.46] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-43.46] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-43.46]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-43.46]
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.9 => 3.168.10] (ubuntu-desktop, ubuntu-server)
<rbalint> tjaalton, vorlon: ^ people started hitting this one with unattended-upgrades sru in xenial-proposed, it would be nice it we could fix this one before u-u gets to -updates
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1036.38~16.04.1] (kernel)
<Laney> (disco-amd64)root@bionic:/# DEB_HOST_ARCH=ppc64el dpkg-buildflags --get CFLAGS
<Laney> -g -O3 -g -O2 -fdebug-prefix-map=/=. -fstack-protector-strong -Wformat -Werror=format-security
<Laney> vorlon: infinity: doko: looks like new dpkg broke ppc64el's CFLAGS
<Laney> https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=d5374bc618310917557daa9c9ac2f4930515a0b2
<Laney> probably caused by that one
<acheronuk> Laney: that for Libreoffice? I got to the patch with dpkg-buildflags --get CFLAGS in it, but couldn't see what change in dpkg may have been at fault
<Laney> that's where I noticed it
 * acheronuk nods
<Laney> that one I linked :-)
<acheronuk> Laney: ah, had not seen your comments in #ubuntu-desktop :)
<Laney> linked it here too :P
<Laney> but yeh
<acheronuk> yeah, I saw in here, but didn't have the libreoffice context. hence men asking
<acheronuk> *me asking
<Laney> Aaaanyway.
<acheronuk> sorry. I just idly looked at it earlier, and was pleased to see I got most of the way there
 * acheronuk shuts up
<Laney> I guess it's most correct for the Ubuntu hook to run the parent one first and then *append* its changes?
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.10]
<tjaalton> rbalint: done
<rbalint> tjaalton, thanks!
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.6-0ubuntu2 => 2:17.0.7-0ubuntu1] (openstack, ubuntu-server)
<slashd> o/ archive admin, I sponsored d-i for mfo/ddstreet to support HTTPS using ca-certificates-udeb, but it FTBFS because it cannot locate ca-certificates-udeb (even after an attempt to rebuild w/ no change in disco) and then we figured out the udeb were missingin in main (http://archive.ubuntu.com/ubuntu/pool/main/c/ca-certificates/) but were found in universe instead (http://archive.ubuntu.com/ubuntu/pool/universe/c/ca-certificates/) and I
<slashd> suspect to be the reason why d-i fails as it cannot get the universe udeb I guess ? thoughts ? what can be done to address this ?
<mfo> related note:  if we rebuild ca-certificates in a PPA, the udeb goes to main/,  but on the normal LP builders, it's going to universe/
<slashd> Just a friendly ping on archive admin that I know and aware of : sil2100 stgraber vorlon infinity ^
<slashd> mfo ddstreet ^
<coreycb> tjaalton: hi, I uploaded a new version of nova to the bionic queue per sil2100's comments on it yesterday. if you happen to have a chance to review it's ready.
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1036.38~16.04.1]
<slashd> sil2100 stgraber volon infinity (and other archive admin) : I left you a more official comment on the public bug : https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1807023/comments/23
<ubot5> Ubuntu bug 1807023 in debian-installer (Ubuntu Disco) "installer stock images fail to validate any HTTPS certificates (ca-certificates missing)" [Medium,In progress]
<slashd> mfo ddstreet ^
<mfo> slashd, ack. :)
<tsimonq2> vorlon: ack
<doko> Laney: syntactically correct. why can't LO handle that? but yes, -O2 is not correct
<Laney> a bug in libreoffice, but that's not the point - that is why in here I didn't mention Libreoffice
<Laney> before acheronu_k did anyway
<Laney> anyway I submitted a potential patch
<doko> where?
<Laney> BTS
<doko> man, bug#?
<Laney> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915881 there ya go
<ubot5> Debian bug 915881 in libdpkg-perl "Ubuntu's custom build flags are overridden by Debian's" [Normal,Open]
<doko> \o/
<tsimonq2> vorlon: Er, re-reading your earlier message, Adam might be able to attest to it.
<tsimonq2> infinity: ^
<tsimonq2> mdeslaur maybe as well.
<tsimonq2> (mate-screensaver upload in Bionic queue is a copy from the security team PPA from binaries, he's asking if it's appropriate for a copy)
-queuebot:#ubuntu-release- New binary: tl-parser [s390x] (disco-proposed/universe) [0.0.0+git20180215.f49077de-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tl-parser [ppc64el] (disco-proposed/universe) [0.0.0+git20180215.f49077de-1] (no packageset)
<infinity> Laney: Grr, thanks for that catch.
<Laney> No bother
-queuebot:#ubuntu-release- New binary: tl-parser [amd64] (disco-proposed/universe) [0.0.0+git20180215.f49077de-1] (no packageset)
<infinity> Laney: Fix uploaded.
<infinity> Laney: http://paste.ubuntu.com/p/vRVjxHwfpM/ if you're curious.
<Laney> Cheers duck.
<Laney> Might want to post that to the bug, if you're intending it to supersede the patch I posted there
 * Laney went for "append and override"
<infinity> Laney: Bug number?
<Laney> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915881
<ubot5> Debian bug 915881 in libdpkg-perl "Ubuntu's custom build flags are overridden by Debian's" [Normal,Open]
<Laney> Linked it to d_oko just above
<Laney> and X-Debbugs-Cced you :P
<infinity> Laney: Ahh, haven't checked my mail today. :P
<infinity> Laney: But also, append is icky there IMO.
<infinity> Laney: I prefer the amd64 and ppc64el lines to actually be comparable, not one to be a mess of deciding which option came first.
 * Laney shrugs
<Laney> As I say, go ahead and post your better version if you like
<infinity> Doing.
<Laney> You could say it's icky having to go and update two places if the upstream default ever changes.
<Laney> but I was going to let some reviewer decide
<Laney> Quittin' time
<Laney> updating a copyright file has removed my will to be at the computer
<infinity> Laney: Yeah, in theory, that's super icky (and I agree).  In practice, the Debian default of '-g -O2' hasn't changed in decades, so I'm not sure it's a deep concern.
<infinity> Laney: But I'd also prefer the icky be under the hood than something that users have to deal with every day.
-queuebot:#ubuntu-release- New binary: tl-parser [arm64] (disco-proposed/universe) [0.0.0+git20180215.f49077de-1] (no packageset)
<infinity> slashd: Promoted. I'll retry the builds when the publisher's done moving it around.
<jbicha> infinity: speaking of build flags, I was reading https://lwn.net/Articles/192624/ at the end of 1.0 there is a claim that all of Ubuntu builds with -Wl,-O1
<jbicha> but that's not true, is it?
<slashd> infinity, thanks a lot
<slashd> ddstreet, mfo ^ fyi
<infinity> jbicha: If it's true, it's being baked into the compiler or linker, but I don't *think* it is...
<slashd> infinity, does the promotion done for each release we support atm also or just devel release ?
<jbicha> doko: can you confirm the answer to my -Wl,-O1 question?
<infinity> slashd: Just disco.  For other releases, it'll require some fiddling.
<slashd> infinity, ack tks
<slashd> ddstreet, mfo again fyi ^
<infinity> slashd: For bionic and cosmic, I'll have to copy ca-certificates to -updates, then do the promotion.  For earlier releases, you need to SRU something that actually produces the package. ;)
<infinity> slashd: Did you have SRUs in flight for b/c at least?
<slashd> infinity, mfo has all the debdiff ready for sponsoring yes
<slashd> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1807023
<ubot5> Ubuntu bug 1807023 in debian-installer (Ubuntu Disco) "installer stock images fail to validate any HTTPS certificates (ca-certificates missing)" [Medium,In progress]
<infinity> slashd: Also, WTF: https://launchpad.net/ubuntu/+source/ca-certificates/20180409ubuntu0.19.04.1
<infinity> slashd: I see three names involved in that upload.  That means three people thought things magically move between components on upload? :/
<infinity> slashd: Can we fix that? :)
<slashd> infinity, I know thats my bad, I miss the ball on that one
<slashd> infinity, how would you like me to fix this ?
<infinity> slashd: I meant "can we fix the knowlege gap?" ... One person being confused is fair enough, three people sharing confusion is the sort of thing that turns into folklore.
<slashd> infinity, yeah I guess we all learn from that don't worry that won't happen again
<infinity> And that's how you get people who think -pipe makes compiled code faster.
<infinity> slashd: Anyhow, I deleted that upload, we can all just pretend it didn't happen. :)
<slashd> infinity, I appreciate it ;)
<infinity> slashd: For future reference, as you've discovered, things move between components "because we say so", and we tend to do it based on reports telling us that it's needed (ie: because something in main now depends/build-depends on it)
<infinity> slashd: In this case, step 1 wasn't going to happen because step 2 wasn't going to happen because d-i's udebs are held in main by a package that d-i itself produces, which is a bit chicken-and-eggy, so the poke was required. :)
<infinity> slashd: For all things other than d-i, it happens as described, though.  In that if something hits proposed that needs new build-deps, you don't need to bug us to promote, we have reports.  But you might have to participate in MIR stuff, if it's a new source in main.
<slashd> infinity, yeah that confirm I wasn't totally wrong ;p I pinged you cause I was expecting it didn't need an MIR due to the fact that the package was already in main (otherwise I would have done the necessary inside an LP), the ca-certificate  rebuild was indeed a bad decision, I admit it, but again I learn a lesson out of it.
<slashd> infinity, thanks again
<ddstreet> infinity much thnx - for me the confusion was around ca-certificates being in main, while ca-certificates-udebs being in universe...didn't know that was possible
<ddstreet> i thought the component referrend to the src pkg, not binary
<slashd> ddstreet, everything is cleaned up now, and we all learn something so all good ;)
<ddstreet> yep excellent stuff
<ddstreet> infinity i'll wait to sru until bionic and cosmic have ca-certificates-udebs moved to main, and we do have patches to generate -udebs for t/x ready
<infinity> ddstreet: Go ahead and do the d-i uploads to bionic and cosmic now, I'll clean up the mess when I review/accept them.
<ddstreet> infinity ok will do, thnx
<infinity> ddstreet: I need to do some bits on my end to import those changes to bzr as well, so may as well while it's fresh in my mind.
<ddstreet> infinity i uploaded d-i to cosmic, but for bionic there's a pending d-i sru from lp #1789227
<ubot5> Launchpad bug 1789227 in debian-installer (Ubuntu Bionic) "nvme devices namespace assigned to the wrong controller" [Undecided,Fix committed] https://launchpad.net/bugs/1789227
<ddstreet> which isn't verified yet
<ddstreet> you want me to upload to bionic anyway and see if we can verify the pending sru before approving the new upload?
<infinity> dannf: *poke*
<dannf> infinity: yo
<infinity> dannf: You have a month-old d-i SRU to bionic that's gumming up the works.
<infinity> dannf: pls to be verifying.
-queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu557 => 20101020ubuntu557.1] (core)
<dannf> infinity: oh man, i hate gum
<infinity> dannf: It's the worst.
<dannf> infinity: i don't see it in -proposed
<infinity> dannf: https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu543.3
<dannf> infinity: oh, sorry - the Unapproved message below yours confused me
<infinity> ddstreet: Go ahead and upload to bionic too.
<ddstreet> will do thnx
<ddstreet> cpaelzer you're looking at the autopkgtest failures for nova, right?  re: "... NoSuchTableError: migration_tmp"
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.3 => 20101020ubuntu543.4] (core)
<ddstreet> oh coreycb is now fixing it?
<coreycb> ddstreet: yes, i'll upload something in a bit
<ddstreet> awesome thnx!
<coreycb> ddstreet: np bug 1807262 for reference
<ubot5> bug 1807262 in migrate (Ubuntu) "stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp" [High,Triaged] https://launchpad.net/bugs/1807262
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu557.1]
<infinity> dannf: Actually, I'm just going to accept ddstreet's upload on top of yours, since yours was just an ABI bump.  If you can verify your fix with his version instead of yours, that'd be nice.
<dannf> infinity: sorry, got interrupted w/ credit card company crap. i have definitely tested that installer version, so i'll mark it as verified. however, i can't say that it fixed the original issue associiated with the kernel. that's still waiting for the user to clarify
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.4]
<infinity> dannf: Fair.  So we know d-i didn't regress, we don't know if the kernel fixed the bug, but that's not d-i's concern.
<dannf> right
 * infinity nods.
<infinity> ddstreet: Okay, cosmic and bionic both accepted and bzr branches fixed up to import those changes.
<infinity> ddstreet: I'll need quick turnaround on bionic so it doesn't block d-i uploads needed for the point release.  Less picky about other releases.
<ddstreet> infinity no problem, should be able to verify today
<infinity> Ta.
<ddstreet> i'll upload for t/x monday, and ping you then about ca-certificates-udeb component for those
<ddstreet> (we do have a patch to actually build -udeb for it for t/x)
<infinity> ddstreet: ca-certificates-udeb will default to main for those two releases anyway, since it's a new package, and new binaries get the component of their source by default.
<ddstreet> great, that makes it easier :)
<ddstreet> thnx
<ddstreet> mfo do you want to verify d-i for bionic (and c/d) or should i? ^
<mfo> ddstreet, i can verify them :)
<ddstreet> thnx mfo!
<infinity> (It's still building on amd64, but should be done within the hour)
<mfo> alright.
 * infinity writes an angry black metal song called "An Ode to Ell One Tee Eff and Why I'm Going to Burn Everything Down".
<cpaelzer> ddstreet: yes I looked at the bug
<cpaelzer> ddstreet: as libvirt is blocked by it
<cpaelzer> I see coreycb has handed you the bug reference
<cpaelzer> so you will know by know what was going on
<ddstreet> cpaelzer yep one of my uploads too - sorry for highlighting you before i checked the recent updates in the bug
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1026.27~16.04.1] (kernel)
<tsimonq2> infinity: Since vorlon doesn't have access to verify the validity of that mate-screensaver binary + source sync to Bionic, could yyou review?
<infinity> Doesn't have access?
<infinity> Oh, doesn't have access to the PPA's properties.
<infinity> vorlon: For reference, ubuntu-security-proposed is the security team's "build here, then copy to proposed" PPA for security updates that need more love, aren't embargoed, etc.  It's a valid binary copy source.
<infinity> tsimonq2: vorlon did leave a comment on the bug, though, which should be addressed.
<teward> tsimonq2: E:NoTestCases, E:NeedsMoreExploratoryTesting
<teward> (to summarize)
<infinity> I think the test case complaint was his confusion about where "see also" was pointing.
<infinity> But the other is valid.
<teward> infinity: to be fair for SRUs I"d still ilke to see at least *one* documented test case in the bug, but I'm picky :P
<teward> (my opinion in the matter is also irrelevant but still)
<infinity> teward: There is one.
<teward> infinity: missed it because the steps looked repeated with the wall of text detailed test case oopsies :|
<teward> *needs more coffee*
<vorlon> infinity: I was not confused about where "see also" was pointing, I simply consider it wrong to have such "see also"s in an SRU template because they introduce opportunity for error or ambiguity
<infinity> vorlon: Maybe I misread your intent, then.  I often do similar things (see ten lines below in the original report) to avoid a mess of copy and paste.
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-13.14~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-13.14~18.04.1] (kernel)
#ubuntu-release 2018-12-08
-queuebot:#ubuntu-release- New binary: tldjs [amd64] (disco-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: twms [amd64] (disco-proposed/universe) [0.06y-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-rpc [amd64] (disco-proposed/universe) [0.0~git20160927.22c016f-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-gorilla-rpc [amd64] (disco-proposed) [0.0~git20160927.22c016f-3]
-queuebot:#ubuntu-release- New: accepted tl-parser [arm64] (disco-proposed) [0.0.0+git20180215.f49077de-1]
-queuebot:#ubuntu-release- New: accepted tl-parser [s390x] (disco-proposed) [0.0.0+git20180215.f49077de-1]
-queuebot:#ubuntu-release- New: accepted twms [amd64] (disco-proposed) [0.06y-2]
-queuebot:#ubuntu-release- New: accepted tl-parser [amd64] (disco-proposed) [0.0.0+git20180215.f49077de-1]
-queuebot:#ubuntu-release- New: accepted tldjs [amd64] (disco-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted tl-parser [ppc64el] (disco-proposed) [0.0.0+git20180215.f49077de-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-13.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-13.14~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1030.35] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-43.46~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-43.46~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: gau2grid [s390x] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gau2grid [ppc64el] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1030.35]
-queuebot:#ubuntu-release- New binary: gau2grid [i386] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gau2grid [amd64] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gau2grid [arm64] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gau2grid [armhf] (disco-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: neutron-vpnaas-dashboard [amd64] (disco-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [ppc64el] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [i386] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1026.27~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-43.46~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-43.46~16.04.1]
-queuebot:#ubuntu-release- New binary: libedlib [amd64] (disco-proposed/universe) [1.2.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libedlib [i386] (disco-proposed/universe) [1.2.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [amd64] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [s390x] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [armhf] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modsecurity [arm64] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted modsecurity [amd64] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted modsecurity [armhf] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted modsecurity [ppc64el] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted modsecurity [arm64] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted modsecurity [s390x] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted modsecurity [i386] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted gau2grid [amd64] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted gau2grid [armhf] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted gau2grid [ppc64el] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted libedlib [amd64] (disco-proposed) [1.2.3-3]
-queuebot:#ubuntu-release- New: accepted neutron-vpnaas-dashboard [amd64] (disco-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted gau2grid [arm64] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted gau2grid [s390x] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted gau2grid [i386] (disco-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted libedlib [i386] (disco-proposed) [1.2.3-3]
-queuebot:#ubuntu-release- New binary: racon [amd64] (disco-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted racon [amd64] (disco-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New binary: kamcli [amd64] (disco-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcc [amd64] (disco-proposed/universe) [1.2.0~DEVEL+20181202-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcc [i386] (disco-proposed/universe) [1.2.0~DEVEL+20181202-1] (no packageset)
#ubuntu-release 2018-12-09
-queuebot:#ubuntu-release- Unapproved: libtorrent-rasterbar (cosmic-proposed/universe) [1.1.9-1 => 1.1.9-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fusiondirectory [amd64] (disco-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pytango (xenial-proposed/universe) [8.1.8-1 => 8.1.8-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [ppc64el] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [s390x] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [arm64] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [armhf] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [amd64] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybluez [i386] (disco-proposed/universe) [0.22+really0.22-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fusiondirectory [amd64] (disco-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted pcc [amd64] (disco-proposed) [1.2.0~DEVEL+20181202-1]
-queuebot:#ubuntu-release- New: accepted pybluez [amd64] (disco-proposed) [0.22+really0.22-1]
-queuebot:#ubuntu-release- New: accepted pybluez [armhf] (disco-proposed) [0.22+really0.22-1]
-queuebot:#ubuntu-release- New: accepted pybluez [ppc64el] (disco-proposed) [0.22+really0.22-1]
-queuebot:#ubuntu-release- New: accepted kamcli [amd64] (disco-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted pybluez [arm64] (disco-proposed) [0.22+really0.22-1]
-queuebot:#ubuntu-release- New: accepted pybluez [s390x] (disco-proposed) [0.22+really0.22-1]
-queuebot:#ubuntu-release- New: accepted pcc [i386] (disco-proposed) [1.2.0~DEVEL+20181202-1]
-queuebot:#ubuntu-release- New: accepted pybluez [i386] (disco-proposed) [0.22+really0.22-1]
<doko> tsimonq2: your patch for doit doesn't seem to fix the autopkg test failures, or are these new ones?
<ginggs> doko: new failures with new pytest, i think
-queuebot:#ubuntu-release- Unapproved: libvirt (cosmic-proposed/main) [4.6.0-2ubuntu3.1 => 4.6.0-2ubuntu3.2] (ubuntu-server, virt)
<cpaelzer> libvirt_4.6.0-2ubuntu3.2 is a fixup to the one in current C-proposed (found on SRU verification, and should now be complete)
<cpaelzer> I'd ask to accept that into C-propsoed to release it once (and not twice) to save the world some downloads of .debs
<cpaelzer> rbasak: that is the one line on top of the current SRU that I mentioned
<cpaelzer> literally a one line change http://paste.ubuntu.com/p/hBkRpkBq7W/
<cpaelzer> let me know if we need there anything else to continue on that
<doko> Logan: guhdi ftbfs. why do you sync without looking at the merges?
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [amd64] (disco-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [ppc64el] (disco-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [i386] (disco-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [s390x] (disco-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [arm64] (disco-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils-0.5 [armhf] (disco-proposed/universe) [0.5.0-2] (no packageset)
<Logan> doko: hey there
<Logan> the Ubuntu delta was applied in Debian
<Logan> the build failure is a new one - and I already filed a ticket in their BTS about it
<Logan> I'd prefer it if you didn't make baseless accusations - thanks :)
-queuebot:#ubuntu-release- New binary: borgmatic [amd64] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [amd64] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: borgmatic [i386] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [i386] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: borgmatic [ppc64el] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [ppc64el] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk-pixbuf-sys [i386] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [i386] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk-pixbuf-sys [amd64] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [amd64] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-docopt [i386] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk-pixbuf-sys [ppc64el] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [ppc64el] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-no-panic [amd64] (disco-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-docopt [ppc64el] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: borgmatic [s390x] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tabwriter [i386] (disco-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [amd64] (disco-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcre2-sys [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-docopt [amd64] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-no-panic [ppc64el] (disco-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [ppc64el] (disco-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcre2-sys [amd64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [i386] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [s390x] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [i386] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tabwriter [amd64] (disco-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [s390x] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcre2-sys [ppc64el] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-docopt [s390x] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [ppc64el] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk-pixbuf-sys [s390x] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tabwriter [ppc64el] (disco-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [s390x] (disco-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-no-panic [i386] (disco-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [amd64] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-no-panic [s390x] (disco-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [s390x] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tabwriter [s390x] (disco-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcre2-sys [s390x] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mudlet [s390x] (disco-proposed/universe) [1:3.7.1-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [i386] (disco-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mudlet [ppc64el] (disco-proposed/universe) [1:3.7.1-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mudlet [i386] (disco-proposed/universe) [1:3.7.1-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: borgmatic [arm64] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: borgmatic [armhf] (disco-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [armhf] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [armhf] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytesize [arm64] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crc32fast [arm64] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-docopt [arm64] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-bytesize [arm64] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytesize [s390x] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [s390x] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-docopt [s390x] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [i386] (disco-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [s390x] (disco-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-no-panic [ppc64el] (disco-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [amd64] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytesize [armhf] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-docopt [amd64] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [ppc64el] (disco-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-no-panic [s390x] (disco-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [ppc64el] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pcre2-sys [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pcre2-sys [ppc64el] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tabwriter [amd64] (disco-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tabwriter [ppc64el] (disco-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [armhf] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [amd64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [i386] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pcre2-sys [i386] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tabwriter [i386] (disco-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk-pixbuf-sys [s390x] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [s390x] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-tabwriter [s390x] (disco-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-no-panic [i386] (disco-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-pcre2-sys [s390x] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-bytesize [amd64] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytesize [ppc64el] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [arm64] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [ppc64el] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [arm64] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [i386] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [s390x] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-docopt [i386] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk-pixbuf-sys [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk-pixbuf-sys [ppc64el] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytesize [i386] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [i386] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [armhf] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-docopt [arm64] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk-pixbuf-sys [i386] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-no-panic [amd64] (disco-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-crc32fast [amd64] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [ppc64el] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-gio [amd64] (disco-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils-0.5 [amd64] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New binary: mudlet [amd64] (disco-proposed/universe) [1:3.7.1-1.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-docopt [ppc64el] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted borgmatic [amd64] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted borgmatic [armhf] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted borgmatic [ppc64el] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted mudlet [amd64] (disco-proposed) [1:3.7.1-1.1]
-queuebot:#ubuntu-release- New: accepted mudlet [ppc64el] (disco-proposed) [1:3.7.1-1.1]
-queuebot:#ubuntu-release- New: accepted borgmatic [arm64] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted borgmatic [s390x] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted mudlet [s390x] (disco-proposed) [1:3.7.1-1.1]
-queuebot:#ubuntu-release- New: accepted borgmatic [i386] (disco-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted mudlet [i386] (disco-proposed) [1:3.7.1-1.1]
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [arm64] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libnghttp2-sys [armhf] (disco-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [arm64] (disco-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libnghttp2-sys [armhf] (disco-proposed) [0.1.1-1]
#ubuntu-release 2019-12-02
<RikMills> vorlon or other AA, could someone sort the chaplin 1386 binaries? I think that is th only thing blocking the libdvdread transition
<vorlon> RikMills: done
<RikMills> thanks!
<RikMills> could an AA remove k3d from the release pocket please? It needs porting upstream to python3, and can't build now that boost in proposed dropped python2
<RikMills> I have mentioned this in upstream issue, and that they need to port if they want it in 20.04
<oSoMoN> vorlon (or another AA), could you please remove the firefox i386 binaries from focal?
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu5.2 => 3.98ubuntu5.3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (eoan-proposed) [3.98ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (disco-proposed) [2.02+dfsg1-12ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (disco-proposed) [2.02+dfsg1-12ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (eoan-proposed) [1.2.10-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (eoan-proposed) [1.2.10-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (eoan-proposed) [1.2.10-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (eoan-proposed) [1.2.10-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.4 => 1:0.5.2.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu5.3 => 3.98ubuntu5.3] (core)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (eoan-proposed/main) [3.98ubuntu5.3 => 3.98ubuntu5.3] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (eoan-proposed/main) [1:0.7.6 => 1:0.7.6.0.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected flash-kernel [source] (eoan-proposed) [3.98ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: rejected flash-kernel [source] (eoan-proposed) [3.98ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (disco-proposed/main) [1:14.0.0-0ubuntu1.1 => 1:14.0.0-0ubuntu1.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.11 => 0.96.24.32.12] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.10 => 1.10.1] (core)
<vorlon> oSoMoN: done; sorry, I had removed the binaries from the release pocket already and overlooked that there were also older ones in -proposed
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.10 => 1.10.1] (core)
<vorlon> RikMills: what is k3d blocking by not being rebuilt?  It doesn't currently show on update-output.  And do you have a link to a bug report about this?
-queuebot:#ubuntu-release- Unapproved: rejected fwupd-signed [source] (eoan-proposed) [1.10.1]
<RikMills> vorlon: latest rebuild was for libopenexr23 -> libopenexr24
<RikMills> vorlon: https://github.com/K-3D/k3d/issues/38
<gitbot> K-3D issue 38 in k3d "Python2 to be EOL-ed" [Open]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (eoan-proposed) [1.10.1]
-queuebot:#ubuntu-release- New binary: vistrails [amd64] (focal-proposed/universe) [3.0~git+9dc22bd-2] (no packageset)
<oSoMoN> vorlon, thanks
-queuebot:#ubuntu-release- Unapproved: unicode-data (xenial-proposed/universe) [8.0-3 => 8.0-3ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted spview [amd64] (focal-proposed) [2.0.0~beta2-1]
-queuebot:#ubuntu-release- New binary: jimtcl [amd64] (focal-proposed/universe) [0.79+dfsg0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-asynctest [amd64] (focal-proposed/universe) [0.13.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [s390x] (focal-proposed/universe) [0.79+dfsg0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-atlassian-jwt [amd64] (focal-proposed/none) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [ppc64el] (focal-proposed/universe) [0.79+dfsg0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [arm64] (focal-proposed/universe) [0.79+dfsg0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [armhf] (focal-proposed/universe) [0.79+dfsg0-2] (no packageset)
#ubuntu-release 2019-12-03
-queuebot:#ubuntu-release- New binary: libinsane [amd64] (focal-proposed/universe) [1.0.2-1] (no packageset)
<cpaelzer> rbasak: is there more to do for https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1844834/comments/19 right now than adding block-proposed ?
<ubot5> Ubuntu bug 1844834 in open-vm-tools (Ubuntu Disco) "open-vm-tools 11.0.0 released" [Undecided,Fix committed]
<cpaelzer> to "hold it back more" :-)
<rbasak> cpaelzer: you can ask for a phasing stop for Eoan
<cpaelzer> rbasak: I did in the bug update
<cpaelzer> rbasak: usually bdmurray is dealing with phasing and I sent him a mail pointing to my added comment already
<mwhudson> if an aa is bored and wants to remove focal/i386 binary for containerd i wouldn't complain
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.12 => 18.04.14.13] (core)
<sforshee> LocutusOfBorg: did you see my last comment on bug #1848594 ? virtualbox-guest-dkms is still failing to build with 5.4
<ubot5> bug 1848594 in virtualbox (Ubuntu) "virtualbox 6.0.12-dfsg-1 ADT test failure with linux 5.4.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1848594
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-73.82] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-38.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-73.82] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-38.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-38.41] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-73.82]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-38.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-38.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-73.82]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-38.41]
-queuebot:#ubuntu-release- Unapproved: cargo (xenial-proposed/universe) [0.37.0-3ubuntu1~16.04.1 => 0.37.0-3ubuntu1~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cargo (disco-proposed/universe) [0.37.0-3ubuntu1~19.04.1 => 0.37.0-3ubuntu1~19.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted jimtcl [amd64] (focal-proposed) [0.79+dfsg0-2]
-queuebot:#ubuntu-release- New: accepted jimtcl [armhf] (focal-proposed) [0.79+dfsg0-2]
-queuebot:#ubuntu-release- New: accepted jimtcl [s390x] (focal-proposed) [0.79+dfsg0-2]
-queuebot:#ubuntu-release- New: accepted jimtcl [arm64] (focal-proposed) [0.79+dfsg0-2]
-queuebot:#ubuntu-release- New: accepted python-asynctest [amd64] (focal-proposed) [0.13.0-4]
-queuebot:#ubuntu-release- New: accepted jimtcl [ppc64el] (focal-proposed) [0.79+dfsg0-2]
<doko> vorlon: please add gcc-10, gcc-10-cross and gcc-10-cross-ports to the i386 white list, gcc-defaults-ports too. They don't even build in ppa's now
-queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.57-0ubuntu3 => 0.09.57-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stress-ng (eoan-proposed/universe) [0.10.07-1ubuntu1 => 0.10.07-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu4 => 0.09.25-1ubuntu5] (no packageset)
<LocutusOfBorg> sforshee, unless you convince an AA to let gsoap go in release, the fix won't migrate
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/virtualbox/6.0.14-dfsg-3
<LocutusOfBorg> we need an i386 removal, and an hint of something regressed in release
<LocutusOfBorg> voms/i386 removed, and hint for kopanocore/all and apparmor/i386, both regressed in release
<LocutusOfBorg> vorlon, ^^
<kanashiro> seb128, re rrdtool: I am talking to cpaelzer about this MR excluding python3-rrdtool-dbg: https://code.launchpad.net/~lucaskanashiro/ubuntu-seeds/+git/ubuntu/+merge/376068
<kanashiro> I'd like your feedback if it is still needed to avoid the same problem in the future
<kanashiro> cpaelzer, was explaining that it can be auto-promoted because the source is in main
<seb128> kanashiro, yes it's needed, currently the dbg shows as to be promoted on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<seb128> yes, we could promote the python binding as well if you prefer that
<kanashiro> seb128, IMO promoting the python3 binding is preferable, what do you think cpaelzer ?
<sil2100> RAOF, rbasak, infinity, bdmurray, apw: hey! Since we are working currently on some eoan image respins, could you, for now, not release any updates from eoan-proposed to eoan-updates? Accepting into -proposed is fine, but I'd like us to keep having a stable updates pocket for a bit
<sil2100> Thanks!
<bdmurray> sil2100: I won't do anything!
<cpaelzer> seb128: kanashiro: I'd prefer to ack and merge  the MP
<cpaelzer> seb128: kanashiro: which lets the -dbg stay in universe
<cpaelzer> and not trigger the component mismatch that we see (whcih we know will trigger the next one)
<rbasak> sil2100: ack
<cpaelzer> kanashiro: seb128: we are not keen (have no reason atm) to provide support for the python-binding
<cpaelzer> if we would, then clearly promoting both would be the most straight forward call to make
<seb128> right, makes sense to me to no promote/support things if we don't need to
<cpaelzer> ok, then it seems we agree - let me merge that seed change ...
<kanashiro> ok then, you're more experienced than me on this :)
<seb128> what 19.10  images are being respinned and why?
<RikMills> ^ was wondering as well
<seb128> sil2100, ^
-queuebot:#ubuntu-release- New binary: python-aioresponses [amd64] (focal-proposed/universe) [0.6.1-2] (no packageset)
<sil2100> seb128, RikMills: just the raspi preinstalled images we're respinning, no worries - those had a few issues for certain pi versions
<seb128> k, cool thx
<sil2100> Nothing worrying, just well, subpar experience, bootability issues
<sil2100> So we're making it much better
<seb128> nice, I just wanted ot make sure it was not the desktop iso :)
<seb128> or that we know about it if it its
<RikMills> ditto. thanks
<seb128> can someone hint the dbus in focal-proposed to migrate? openjdk-lts/armhf just worked once and keep failing otherwise (should probably be flagged as badtest?) and systemd/i386 which seems a fallout if i386 being decomissioned
<seb128> sil2100, ^ since you are around is that something you can do or who should be pinged rather? :)
<sil2100> seb128: I guess I can!
<sil2100> Let me do that
<seb128> I guess we want to badtest openjdk-lts/armhf maybe?
<seb128> it blocks other things as well
<seb128> want a mp for that?
<tdaitx> seb128: sil2100: it's timming out, weirdly it is set as a flaky test, I wonder why it is blocking anything
<tdaitx> so yeah, badtest it for now
<sil2100> seb128: yeah, if that's not big enough of a problem, an MP could be conveninent ;)
 * sil2100 is jumping between stuff
<seb128> sil2100, https://code.launchpad.net/~seb128/britney/openjdk-lts-armhf/+merge/376286
<seb128> sil2100, sorry, editing, I put it in a i386 block
<seb128> sil2100, k, pushed again
<sil2100> Ok! Looking, thanks!
<sil2100> seb128: did you bzr push for sure?
<seb128> thx
<seb128> sil2100, sorry, it remembered a previous location as default, done to the right place now
<rbalint> RAOF, bdmurray: could you please release LP: #1853343 in your sru cycles?
<ubot5> Launchpad bug 1853343 in wslu (Ubuntu Eoan) "[SRU] Please detect sound and X server in WSL2, too" [Undecided,Fix committed] https://launchpad.net/bugs/1853343
<sil2100> seb128: all done o/
<seb128> great, thank you!
<vorlon> doko: they don't even build in ppas now> right, that's as I mentioned in my email to ubuntu-devel, but why do you need the -cross ones built at all for an i386 host?  That seems like a waste of launchpad resources to me ;-)
<vorlon> LocutusOfBorg: removing voms requires removing an annoying stack of lcmaps revdeps which is why I didn't dig into it.  Is there an urgency here that justifies me doing that by hand, vs waiting for the i386 mass-removals?
<doko> vorlon: you may see it as "waste", however I'd like to make sure these build on 32bit platforms. Plus it's not uncommon that I backport those
<doko> there's a lot more "waste" going on with daily and nightly package builds ...
<vorlon> doko: so why not build them in the ppa for the target release instead of in focal?
<vorlon> doko: yes, I would've thought you'd be sympathetic to the waste argument on that basis
<doko> do I really have to argue with you abou that?
<infinity> Not if you don't want to argue.
<sforshee> vorlon: LocutusOfBorg is saying this is a blocker for getting a vbox version which supports 5.4, which is a blocks getting a 5.4 kernel into focal
<vorlon> sforshee: ok, I'll work through the tree
<doko> no, I'm doing this work on trunk, not on any release. so please add those
<vorlon> doko: you do have commit rights
<doko> ok
<vorlon> I still don't think any of the cross packages belong on the whitelist, but it's not really worth arguing about
<vorlon> jdstrand: so the apparmor/i386 autopkgtests now fail because they have test deps on binary packages that have been removed.  Is there a subset of tests that test the library functionality and that we should care about continuing to have good results from, or should we just ignore apparmor test failures on i386 going forward?
<vorlon> jdstrand: (to the extent that we are running tests on i386, they're all going to be with the amd64 generic kernel, and most of the test deps are going to be satisfied via the amd64 versions)
<jdstrand> vorlon: let me look at the tests
<vorlon> jdstrand: cheers
<jdstrand> vorlon: unrelated, I'm planning an apparmor merge soonish to resolve the py2 stuff
<vorlon> \o/
<jdstrand> (and super unrelated, also ufw)
<jdstrand> well, that is an upload to unstable then merge, but anyway
<jdstrand> vorlon: ok, the bad test is 'compile-policy' and it needs to be reworked to avoid i386, both in its Depends and since there won't be an apparmor_parser i386 binary
<vorlon> jdstrand: there will be an apparmor_parser i386 binary, despite it not normally being the one that's installed
<vorlon> jdstrand: I can help with the refactoring of the test declarations to be cross-friendly, my question is whether once I've done that there will be any tests left worth running
<jdstrand> vorlon: so, apparmor and apparmor-utils aren't in the list of i386 binaries we will keep, correct?
<vorlon> jdstrand: they are. whitelisting is by source package, not binary package
<jdstrand> vorlon: did something pull in libapparmor?
<vorlon> so since libapparmor1 is pulled in, apparmor + apparmor-utils are also there
 * jdstrand wonders what pulled that in
<vorlon> actually, let's see
<bdmurray> cpaelzer: open-vm-tools has already been released to -updates so block-proposed won't do anything. An AA needs to manually set the phased-update percentage to 0 for it.
<vorlon> jdstrand: dh-apparmor is a cups build-dependency and libapparmor-dev is a dbus build-dependency, that's what pulls it in
<vorlon> (plus dbus runtime dep on libapparmor1)
<vorlon> jdstrand: since libapparmor1 is a dep of the dbus binary package, which users won't install, rather than libdbus-1-3, it may be reasonable to just say we don't care about testing apparmor on i386 and the packages are just there as a side-effect
<jdstrand> vorlon: the fact that the binaries are there at all suggests the tests are worth keeping, but the fact that no one will use apparmor_parser, aa-enabled or aa-exec from the i386 binary packages means the tests don't mean anything
<vorlon> jdstrand: that's enough for me; I'll badtest them and move on with life
<jdstrand> vorlon: yes, that is my conclusion
<vorlon> jdstrand: ta
-queuebot:#ubuntu-release- New binary: oops-datedir-repo [amd64] (focal-proposed/universe) [0.0.24-0ubuntu2] (no packageset)
<jdstrand> vorlon: when I do the merge, I'm thinking I should try to adjust the tests so they don't run at all?
<vorlon> jdstrand: doesn't matter, they'll run and fail, it's cheap and not worth you spending time on :)
<LocutusOfBorg> sforshee, actually, you can upload 5.4 in focal-proposed pocket
<LocutusOfBorg> tests will be green if you run them with the proposed vbox trigger
<sforshee> LocutusOfBorg: oh, the version in -proposed has the fix? Based on the changelog entry I didn't think that it did, let me try it
-queuebot:#ubuntu-release- New binary: python-mne [amd64] (focal-proposed/universe) [0.19.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-libgit2-git2go.v28 [amd64] (focal-proposed/universe) [0.28+git20190813.37e5b53-3] (no packageset)
<jdstrand> vorlon: ack. is that badtesting them in a git commit somewhere that we discussed it and why it is ok to badtest them?
<jdstrand> vorlon: (just in case someone else from the team is asked about it)
<LocutusOfBorg> sforshee,   * Drop 81649 and take the archlinux version, that contains also rev 81586 and
<LocutusOfBorg>     81587 (LP: #1848594)
<ubot5> Launchpad bug 1848594 in virtualbox (Ubuntu) "virtualbox 6.0.12-dfsg-1 ADT test failure with linux 5.4.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1848594
<LocutusOfBorg> this is from virtualbox 6.0.14-dfsg-3 changelog
<LocutusOfBorg> (with a gsoap fix added)
-queuebot:#ubuntu-release- Unapproved: accepted cargo [source] (disco-proposed) [0.37.0-3ubuntu1~19.04.2]
-queuebot:#ubuntu-release- Unapproved: thunderbird (eoan-proposed/main) [1:68.2.1+build1-0ubuntu0.19.10.1 => 1:68.2.2+build1-0ubuntu0.19.10.1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cargo [source] (xenial-proposed) [0.37.0-3ubuntu1~16.04.2]
<sforshee> LocutusOfBorg: 6.0.14-dfsg-3 still fails with the same errors as in my last comment on bug 1848594
<ubot5> bug 1848594 in virtualbox (Ubuntu) "virtualbox 6.0.12-dfsg-1 ADT test failure with linux 5.4.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1848594
<vorlon> jdstrand: https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu
<vorlon> sforshee: fwiw I can't find evidence in the autopkgtest history for LocutusOfBorg's statement that kopanocore has regressed in release, I only see failures on the version in -proposed; so that needs unpicking still
<sbeattie> apw, vorlon: heya, linux-oem 4.15.0.1065.69 got forward copied from bionic-security to disco-security and eoan-security respectively but linux-signed-oem was only forward-copied to disco-updates and not disco-security, leading to an abi mismatch. (linux-signed-oem did get copied to eoan-security correctly)
<sbeattie> (that's linux-signed-oem 4.15.0-1065.75 )
<vorlon> sbeattie: looking
<vorlon> sbeattie: copied
<sbeattie> vorlon: thanks!
<apw> sbeattie: likely I have yet another launchpad oops in my inbox
<vorlon> hmmm cups is not seeded but libcups is; and cups depends on cups-filters which is not whitelisted; what to do
<LocutusOfBorg> sforshee, fixed.
<sforshee> thanks LocutusOfBorg
-queuebot:#ubuntu-release- New: accepted golang-gopkg-libgit2-git2go.v28 [amd64] (focal-proposed) [0.28+git20190813.37e5b53-3]
-queuebot:#ubuntu-release- New: accepted oops-datedir-repo [amd64] (focal-proposed) [0.0.24-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-mne [amd64] (focal-proposed) [0.19.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libinsane [amd64] (focal-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-atlassian-jwt [amd64] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted python-aioresponses [amd64] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-bmatcuk-doublestar [amd64] (focal-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted vistrails [amd64] (focal-proposed) [3.0~git+9dc22bd-2]
-queuebot:#ubuntu-release- New: accepted golang-github-pearkes-cloudflare [amd64] (focal-proposed) [0.0~git20160103.765ac18-1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.2-36-g059d049c-0ubuntu2~16.04.1 => 19.3-41-gc4735dd3-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.2-36-g059d049c-0ubuntu2~18.04.1 => 19.3-41-gc4735dd3-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [19.2-36-g059d049c-0ubuntu2~19.04.1 => 19.3-41-gc4735dd3-0ubuntu1~19.04.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: hypopg [amd64] (focal-proposed/universe) [1.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [s390x] (focal-proposed/universe) [1.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [ppc64el] (focal-proposed/universe) [1.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [armhf] (focal-proposed/universe) [1.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [arm64] (focal-proposed/universe) [1.1.3-1] (no packageset)
<blackboxsw> hi RAOF or bdmurray (as I think RAOF is EOD) we've queued an SRU for cloud-init that we'd like to check into -proposed to start validation for a couple of ec2/azure related fixes. The cloud-init SRU is queued against Xenial, Bionic, Disco and Eoan
<blackboxsw> If there is time, we'd love to get that reviewed. If not, we can pick it up tomorrow with Robie
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.2-36-g059d049c-0ubuntu3 => 19.3-41-gc4735dd3-0ubuntu1~19.10.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1031.35] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1031.35]
#ubuntu-release 2019-12-04
<RAOF> blackboxsw:Me is actually mid-morning. Let's get some cloud-init happening!
<blackboxsw> schweet RAOF
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.40-0ubuntu1 => 8.0.6.0-0ubuntu1] (no packageset)
 * RAOF grins at `safeyaml`
<RAOF> blackboxsw: It would be nice to explicitly mention that the Debian patch dropped was dropped because it's in the new upstream release, rather than me trawling through the long upstream changelog ;)
<blackboxsw> Ahh excellent, yes, will amend that in the descr, and of future SRUs
<blackboxsw> RAOF: should that be the debian/changelog text that says that
<blackboxsw> ?
<blackboxsw> we can fixup our tooling to emit that
<RAOF> Yeah, ideally.
<blackboxsw> ok will do
<blackboxsw> will ammend that for all subsequent SRUs
<RAOF> Changelogs for SRUs are kinda annoying, in that they have two distinct audiences.
<RAOF> Developers working on the package, and users working out whether to upgrade the package :)
<blackboxsw> RAOF: which debian/changelog entry text are we talking about changing?
<blackboxsw> I'm trying to find an unclear one that doesn't already say dropped due to upstream inclusion
<RAOF> Oh! Xenial's.
<blackboxsw> ok moving to xenial to check
<blackboxsw> there I see   * refresh patches:
<blackboxsw>    + debian/patches/ec2-classic-dont-reapply-networking.patch
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.3-41-gc4735dd3-0ubuntu1~16.04.1]
<blackboxsw> and previous SRUs had   * drop the following cherry-picks now included:
<blackboxsw>     + cpick-1d5e9aef-azure-Add-apply_network_config-option-to-disable
<blackboxsw> ohhhh      - drop cherry picks included in upstream/master commit 7d5d34f3
<RAOF> Hm.
<blackboxsw> I see, sorry about that. I think this was a one off case RAOF, I'll make sure we adhere to our typical cherry pick dropping (we have tooling that does that and write the appropriate debian/changelog and I think that wasn't used on xenial
<RAOF> It also appears to be missing from bionic.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.3-41-gc4735dd3-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.3-41-gc4735dd3-0ubuntu1~19.04.1]
<blackboxsw> RAOF: that patch wasn't needed bionic I believe. and this SRU should sync both xenial and bionic to be equivalent
<RAOF> Hm. It's actually been dropped from all series, and not mentioned explicitly.
<blackboxsw> hrm, ok I need to figure out why that's happened
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [19.3-41-gc4735dd3-0ubuntu1~19.10.1]
<blackboxsw> thanks for this
<RAOF> You might want to see if there's something about that patch which your current tooling fails to pick up.
<blackboxsw> yep I think in all cases it was a git cherry-pick manually run instead of our tooling 'cherry-pick'
<blackboxsw> which would have added the appropriate debian/changelog entry
<blackboxsw> ok I'll talk to our team tomorrow to make sure that's not repeated
<blackboxsw> #newguys ;)
<RAOF> :)(
<blackboxsw> not so new, just newer to our team :)
<blackboxsw> and had different tooling on their team.\
-queuebot:#ubuntu-release- New: accepted hypopg [amd64] (focal-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- New: accepted hypopg [armhf] (focal-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- New: accepted hypopg [s390x] (focal-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- New: accepted hypopg [arm64] (focal-proposed) [1.1.3-1]
-queuebot:#ubuntu-release- New: accepted hypopg [ppc64el] (focal-proposed) [1.1.3-1]
<cpaelzer> bdmurray: open-vm-tools  has only went to -updates for Eoan
<cpaelzer> bdmurray: the block-proposed that I added was for Bionic and Disco
<cpaelzer> I thought that should work for those two, or is the tag non-functional as soon as it was released for one series?
<cpaelzer> apw: vorlon: seb128: is one of you around to set the phasing of open-vm-tools 2:11.0.1-2ubuntu0.19.10.1 in Eoan back to 0%
<cpaelzer> currently at 70%
<cpaelzer> reasons https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1844834/comments/19  https://github.com/vmware/open-vm-tools/issues/390
<gitbot> vmware issue 390 in open-vm-tools "Crash in HostinfoLsbRemoveQuotes" [Open]
<ubot5> Ubuntu bug 1844834 in open-vm-tools (Ubuntu Disco) "open-vm-tools 11.0.0 released" [Undecided,Fix committed]
<apw> cpaelzer, the tools say it is at 0%
<cpaelzer> apw: hmm, yeah it says it now
<cpaelzer> was saying 70% this morning
<cpaelzer> Ah here, I got a mail about 2h ago
<cpaelzer> maybe some AA already responded but didn't ping
<apw> perhaps, not sure who is awake but ok
<rbalint> hi, rbasak please take a look at wslu in your sru cycle
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan 19.10.1] has been updated (20191203)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan 19.10.1] has been updated (20191203)
<LocutusOfBorg> sforshee, of course testing is appreciated :)
<LocutusOfBorg> mdeslaur, can clamav go in sync now?
<LocutusOfBorg> I mean, the patch is in stable releases, it is not needed anymore, right?
<LocutusOfBorg> any AA, please move golang-1.12-race-detector-runtime to universe and golang-1.13-race-detector-runtime to main, thanks
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1027.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-171.200] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1027.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-171.200]
<sforshee> LocutusOfBorg: virtualbox-guest-dkms 6.0.14-dfsg-4 builds fine with 5.4, thanks!
<ahasenack> hello, could an archive admin please take a look at the haproxy i386 failure in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy ?
<ahasenack> is this a case where the i386 package has to be removed, as per vorlon's email to ubuntu-devel a few days ago?
<jdstrand> vorlon: thanks!
<ahasenack> for my case, neutron-metadata-agent exists for i386, but it wants haproxy, which wasn't built for i386
<cpaelzer> apw: seb128: doko: pinging AAs for a removal as described in bug 1853003
<ubot5> bug 1853003 in ibmasm-utils (Ubuntu) "[20.04] Please remove ibmasm-utils package from the Archive" [Undecided,New] https://launchpad.net/bugs/1853003
<seb128> cpaelzer, apw, doko, done now
<cpaelzer> thank you
<seb128> cpaelzer, can you get it removed from https://people.canonical.com/~ubuntu-archive/seeds/platform.focal/supported-misc-servers , I overlooked that before removing it :-/
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1051.54] (kernel)
<cpaelzer> yes I'll open an MP for that, just a sec
<seb128> thx
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1009.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1009.14]
<cpaelzer> seb128: https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/376334
<cpaelzer> arr merge target might mismatch
<seb128> cpaelzer, wrong... right
<cpaelzer> looks much saner https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/376335
<vorlon> ahasenack: the haproxy i386 binaries were removed; the triggering of the test for the non-existent haproxy binaries is the annoying britney behavior.  I've added a round of badtest hints
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (bionic-proposed/main) [2.7.16-2~18.04 => 2.7.17-1~18.04] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15-4ubuntu4~18.04.2 => 2.7.17-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: swift (eoan-proposed/main) [2.23.0-0ubuntu1 => 2.23.1-0ubuntu0.19.10.1] (openstack)
<ahasenack> vorlon: thanks
<RikMills> imagemagick needs a no change rebuild against libopenexr24 to get nearer to completing that transition. could any core-dev lurking be kind enough to oblige?
<ahasenack> vorlon: neutron also needs a badtest for i386? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy
<ahasenack>  neutron-metadata-agent : Depends: haproxy but it is not installable
<ahasenack> or should neutron stop being built for i386
-queuebot:#ubuntu-release- New binary: ldb [amd64] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: ldb [s390x] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: ldb [ppc64el] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
<ahasenack> hi archive admins, the new binary above is a soname change: libldb1 -> libldb2
<ahasenack> could someone let it through please?
-queuebot:#ubuntu-release- New binary: ldb [i386] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
<ahasenack> although it's still building for arm
-queuebot:#ubuntu-release- New binary: ldb [armhf] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: ldb [arm64] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
<ahasenack> ok, all built now
<cjwatson> This sort of new-on-import-from-Debian is semi-automatic, but done anyway
-queuebot:#ubuntu-release- New: accepted ldb [amd64] (focal-proposed) [2:2.0.7-4]
-queuebot:#ubuntu-release- New: accepted ldb [armhf] (focal-proposed) [2:2.0.7-4]
-queuebot:#ubuntu-release- New: accepted ldb [ppc64el] (focal-proposed) [2:2.0.7-4]
-queuebot:#ubuntu-release- New: accepted ldb [arm64] (focal-proposed) [2:2.0.7-4]
-queuebot:#ubuntu-release- New: accepted ldb [s390x] (focal-proposed) [2:2.0.7-4]
-queuebot:#ubuntu-release- New: accepted ldb [i386] (focal-proposed) [2:2.0.7-4]
<ahasenack> thanks!
<ahasenack> I have two other uploads that need this ldb version, so this speeds that up
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-73.82~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-73.82~16.04.1] (kernel)
<kanashiro> smartmontools is not a candidate to migrate from proposed because of a missing build on i386, could someone please help me with that?
<vorlon> kanashiro: I was just working my way through the proposed-migration list down to that one; the i386 binaries will be removed shortly
<kanashiro> thanks vorlon
<vorlon> kanashiro: mm.  the revdep tree of this package is deep (I just hit qemu), this may wind up waiting until I do the mass i386 binary removals
<kanashiro> vorlon, ok
<vorlon> actually the qemu revdeps weren't so bad, almost done pruning
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.2 => 4.1~rc1-3~ubuntu18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (eoan-proposed/main) [4.1-2ubuntu3 => 4.1-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (disco-proposed/main) [4.1-1ubuntu1 => 4.1-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1051.54]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-73.82~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-73.82~16.04.1]
#ubuntu-release 2019-12-05
<vorlon> autopkgtest [05:42:11]: host juju-prod-ues-proposed-migration-machine-11; command line: /home/ubuntu/autopkgtest/runner/autopkgtest --output-dir /tmp/autopkgtest-work.d7k492al/out --timeout-copy=6000 -a i386 --setup-commands /home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh --setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed
<vorlon> --apt-pocket=proposed=src:liblouis --apt-upgrade liblouis --env=ADT_TEST_TRIGGERS=liblouis/3.11.0-3 -- ssh -s /home/ubuntu/autopkgtest/ssh-setup/nova -- --flavor autopkgtest --security-groups autopkgtest@lgw01-23.secgroup --name adt-focal-i386-liblouis-20191205-054210 --image adt/ubuntu-focal-amd64-server --keyname testbed-juju-prod-ues-proposed-migration-machine-11
<vorlon> --net-id=net_ues_proposed_migration -e ''"'"'http_proxy=http://squid.internal:3128'"'"'' -e ''"'"'https_proxy=http://squid.internal:3128'"'"'' -e ''"'"'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net'"'"'' --mirror=http://ftpmaster.internal/ubuntu
 * vorlon waits
<vorlon> (for the test failure, since the i386 binaries have been removed ;P)
<vorlon> well hey, the pass rate for cross-tests of the remaining packages on i386 is > 0%: http://autopkgtest.ubuntu.com/packages/a/adduser/focal/i386
<vorlon> (of course, this is an arch: all package anyway so it tells us nothing about quality)
-queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [207-1~ubuntu19.10.1 => 208-1~ubuntu19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [207-1~ubuntu19.04.1 => 208-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [207-1~ubuntu18.04.1 => 208-1~ubuntu18.04.1] (no packageset)
<LocutusOfBorg> hello cyphermox, nodejs merge please? a lots of nodejs packages are stuck...
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
<LocutusOfBorg> nvm, syncing it
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [208-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [208-1~ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [208-1~ubuntu18.04.1]
<seb128> can someone ignore the silx failure to let python-fabio and xorg-server migrate?  something changed which makes opencl fail, looks like toolchain or kernel but it's not due to those updates
<seb128> http://autopkgtest.ubuntu.com/packages/s/silx/focal/amd64
<apw> seb128, that looks a lot like a dependant package for silx is broken with it or in and of itself
<apw> seb128, if i am reading the trace back right ?
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1027.28~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1028.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1010.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1027.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1028.30]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1010.11]
<seb128> apw, which log are you looking at?
<seb128> apw, if you are refering to the h5py errors, look at the python-fabio/0.9.0+dfsg-4 h5py/2.10.0-2 one rather. It's one of the reasons I want python-fabio to be marked as candidate, it's needed for the fixed h5py to migrate
<seb128> h5py is buggy in the release pocket and it's impacting on a number of other tests, would be nice to see that resolved
<apw> seb128, so would just requesting a test of sixl and h5py not cause those to look happy ?
<seb128> apw, that's the second entry on http://autopkgtest.ubuntu.com/packages/s/silx/focal/amd64
<seb128> apw, that makes h5py happy but opencl fails with
<seb128> pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident module'.
<seb128> apw, I'm stating that it doesn't look like a python-fabio problem so if the failing results could be ignored to make python-fabio a candidate
<seb128> which would allow us to have the fixed h5py migrating
<seb128> which would make other tests happier (and not having people like me chasing retries to add &trigger=h5py/2.10.0-2)
<seb128> the opencl/silx problem still needs to be sorted out
<seb128> but meanwhile it would make things easier to unblock the other ones
<seb128> if that makes any sense?
<apw> some indeed
<apw> seb128, ok so the logical hint is to hint python-fabio good as that does not randomly unblock other things which have not been eye-balled
<apw> seb128, but you also have self-test failures for s390x
<seb128> apw, ah, right :(
<seb128> apw, thx for pointing that out, I'll have a look to that
<apw> seb128, ack thanks
<RikMills> could someone with permissions do an imagemagick no change rebuild against libopenexr24? that should be one of the last things holding the ilmbase/openexr transition
-queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)
<rbalint> sil2100, please drop pam ^
<sil2100> Ok
-queuebot:#ubuntu-release- Unapproved: rejected pam [source] (eoan-proposed) [1.3.1-5ubuntu1.19.10.0]
<seb128> RikMills, k, doing now
<RikMills> seb128: thanks!
<seb128> np!
<seb128> RikMills, freeimage has failing i386 tests (forge & freeimage) that should probably be marked badtest to make it candidate
<RikMills> seb128: yeah. was going to ask vorlon this morning before his eod in the USA, but forgot
<seb128> RikMills, you can probably get any r-t member to merge a such mp if you send one
<seb128> RikMills, just need to be added to the i386 section from https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release I guess
 * RikMills shudders at doing a mp with bzr
<seb128> RikMills, I can do it if you want?
<RikMills> seb128: that would be great. I don't have much time until later
<seb128> RikMills, k, I do it, I've some other ones to add in that section anyway
<RikMills> ty
<seb128> https://code.launchpad.net/~seb128/britney/extra-i386-badtests/+merge/376400
<seb128> if someone wants to review/merge that
-queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)
<slashd> o/ sil2100, could you please review the upload of 'stress-ng' in E/D/B when you have a moment ? Thanks in advance !
<slashd> mfo, ^
<sil2100> slashd: hey o/ Sure
<sil2100> Just need to finish the publishing to -updates
<mfo> slashd, sil2100  thanks guys!  this upload is not high priority, so i haven't checked about them yet; i planned to follow up next week just in case, but if it can be worked on sooner, that's great :)  thanks again. o/
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1010.11~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1027.28~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1009.14~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1010.11~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1009.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1027.28~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1032.36] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1032.36]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (eoan-proposed) [0.10.07-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (disco-proposed) [0.09.57-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python2.7 (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu2 => 8.3.0-26ubuntu1~19.10] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04.1 => 8.3.0-26ubuntu1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu2 => 7.5.0-3ubuntu1~19.10] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04.1 => 7.5.0-3ubuntu1~18.04] (core)
<cpaelzer> ddstreet: xnox: rbalint: Upstrem systemd CI runs on http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream seem odd to me. They hang after "dpkg-buildpackage: info: binary-only upload (no source included)" and then from upstream POV vanish after a timeout
<cpaelzer> is that a known issue of any kind and/or is there something that we can do about it?
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1031.34] (kernel)
<cpaelzer> Laney: cjwatson: ^^ FYI for your general great knowledge about the inner workings of autopkgtest.u.c
<ddstreet> cpaelzer what do you mean 'vanish'?
<ddstreet> the result links are added on the PRs upstream, for the latest test run
<cpaelzer> E.g. 49219b5c is an upstream PR of mine https://github.com/systemd/systemd/pull/14167 - currently those tests are there as "pending - autopkgtest running"
<gitbot> systemd issue (Pull request) 14167 in systemd "Fix memory_deny_write_execute on x86 and s390 with libseccomp 2.4.2" [Good-To-Merge/Waiting-For-Ci ð, Seccomp, Tests, Open]
<cpaelzer> last time they just went away, no more mentioned
<cpaelzer> not failed and not succeeded
<cpaelzer> just gone fromt he overview
<cpaelzer> I thought I ask while the tests are still "active"
<cpaelzer> as afterwards there might be not much to look after
<cpaelzer> Here Lennard seems to mention that this "happens sometimes" https://github.com/systemd/systemd/pull/14167#issuecomment-562043653
<gitbot> systemd issue (Pull request) 14167 in systemd "Fix memory_deny_write_execute on x86 and s390 with libseccomp 2.4.2" [Good-To-Merge/Waiting-For-Ci ð, Seccomp, Tests, Open]
<cpaelzer> the question is can/should we do someting about it
<ddstreet> all the old tests are still available, you just have to go thru pain to manually find them
<ddstreet> there was general infrastructure problems on dec 2, so i think a lot of Ubuntu ci jobs got dropped then
<ddstreet> that does happen sometimes
<cpaelzer> ok, I can wait until thesw work or timeout or disappear
<ddstreet> but normally all the ci jobs should complete and update github with the results and log.gz link
<cpaelzer> just wanted to be proactive while still debuggable
<ddstreet> have you tried gathering the resutls with the autopkgtest-manager script?  that makes autopkgtest.u.c less painful to gather results from
<cpaelzer> ddstreet: I haven't looked for the systemd CI results via that
<ddstreet> https://git.launchpad.net/ubuntu-support-tools/tree/autopkgtest-manager/autopkgtest-manager
<cpaelzer> the current ones are still running, I'd look for them afterwards
<ddstreet> might be helpful
<cpaelzer> but I can try to find the old ones
-queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu7 => 11ubuntu7.19.10.0] (core)
<ddstreet> i set in my .bash_aliases export AUTOPKGTEST_MANAGER_CACHE_DIR="~/autopkgtest-manager"
<ddstreet> and then i create /home/ddstreet/autopkgtest-manager-systemd-upstream -> autopkgtest-manager/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/pr
<ddstreet> makes it a bit easier to review various systemd-upstream PR results
<seb128> apw, can you mark the silx tests to skip for python-fabio as well as python-fabio/s390x itself? the python-fabio/s390x failure is just stupid, from a scucess log (the most recent)
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/p/python-fabio/20191130_022051_d9d4c@/log.gz
<seb128> FAILED (failures=5, errors=43, skipped=17)
<seb128> Test suite failed
<seb128> autopkgtest [02:20:39]: test python3-dbg: -----------------------]
<seb128> autopkgtest [02:20:40]: test python3-dbg:  - - - - - - - - - - results - - - - - - - - - -
<seb128> python3-dbg          PASS
<seb128> apw, so basically it always failed, just the packaging was buggy before and not returning the error properly
<apw> seb128, so it is random what it says, but it is always failed
<seb128> so it's not a regression
<apw> ok
<seb128> right
<seb128> they fixed it to properly error out
<seb128> do we have a way to do an history reset of a test? like declare it always failed?
<apw> we have literally no way to do that, and it is the most annoying of things
<seb128> seems annoying indeed :-/
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1.2 => 3:15.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.2-0ubuntu1 => 2:14.0.3-0ubuntu1] (openstack, ubuntu-server)
<cjwatson> cpaelzer: I have no knowledge whatsoever about the internal workings of autopkgtest
<apw> seb128, and so hinted
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (disco-proposed/universe) [2:14.0.0-0ubuntu1 => 2:14.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan 19.10.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan 19.10.1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: octavia (disco-proposed/universe) [4.0.0-0ubuntu1.2 => 4.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1031.34]
<seb128> apw, thanks
<apw> seb128, np, thanks for doing the legwork on the s390x regression marker
-queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3.18.04.1 => 2.02.176-4.1ubuntu3.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: lvm2 (disco-proposed/main) [2.02.176-4.1ubuntu4.1 => 2.02.176-4.1ubuntu4.2] (core)
-queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3.18.04.1 => 2.02.176-4.1ubuntu3.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: vaultlocker (disco-proposed/universe) [1.0.3-0ubuntu2 => 1.0.4-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vaultlocker (eoan-proposed/universe) [1.0.3-0ubuntu2 => 1.0.4-0ubuntu0.19.10.1] (no packageset)
<vorlon> happy i386 day https://paste.ubuntu.com/p/HvbrGHNYx3/
<vorlon> infinity: re-ping on https://code.launchpad.net/~vorlon/ubuntu-archive-tools/update-i386-whitelist/+merge/376042
<vorlon> seb128: ^^ fyi, over the course of today the number of 'missing build on i386' problems should drop to zero (it'll take some time to remove all the binaries, so far I'm down to 'ac' :P), but the number of autopkgtest regressions will probably increase
<vorlon> the good news is we should reach steady state fairly quickly, we'll just need to badtest the arch: all packages with tests
<infinity> vorlon: It has comments.  Do as you will with them.  I'm sick and wishy-washy today.
<vorlon> ta
<vorlon> infinity: do you have a link handy to the LP bug?
<infinity> https://bugs.launchpad.net/launchpad/+bug/1855069
<ubot5> Ubuntu bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New]
<infinity> vorlon: Oh, and given that there's no real input validation here (and, honestly, I'm not sure how one would do any), I assume there's no intent to ever run this automated without dry-run?
<infinity> vorlon: Actually, the lack of input sanity checking means the dry-run could tell you plausibly good things, then the next run to commit could blow up in your face.  Maybe this needs a confirmation between printing and acting.
<vorlon> infinity: in practice I download the file locally, do a --dry-run, and then commit :)
<vorlon> but also if it does blow up in your face, it will still tell you it has blown up in your face so read the output etc
<vorlon> but yeah I don't think this is sane to ever run without human oversight
<infinity> vorlon: Fair enough, but I don't think the tool itself implies that's how it should/could be used, so I still think a y/n after the dry-run check makes sense.
<vorlon> since one wrong package removal means germinate will shrink the packageset to 0
<infinity> A y/n with no --yes override, so it's clear it must be interactive. :P
<vorlon> infinity: well you were wishy-washy and I've already merged it now without that... :)
<infinity> Hah.  Well, if you have "spare time".
 * vorlon nods :)
<infinity> It literally doesn't matter until someone other than you runs it, I suspect, but it's a public tool now, so you know someone will eventually.
<vorlon> infinity: done
<RikMills> could someone run the tests to see if cmake/3.13.4-1build1 is regressed in release please?
<RikMills> I have seen the finding of harfbuzz fail due to new pango in release, so the imagemagick cmake test fails look to be the same cause
-queuebot:#ubuntu-release- Packageset: Added gcc-10 to i386-whitelist in focal
<vorlon> 8166 badtest hints added for i386
<vorlon> this is fine
<vorlon> RikMills: awkward to construct that command, and anyway there was a pass of cmake on 21Nov, what do you think would have changed since then that would regress cmake's own tests?
<RikMills> vorlon: https://gitlab.kitware.com/cmake/cmake/issues/19531
<RikMills> due to new pango 1.44 in -release
<vorlon> RikMills: tests triggered
<RikMills> vorlon: pango1.0 1.44.7-1 published to -release on 21Nov, so may have been just after that successful test
<RikMills> vorlon: thanks!
<RikMills> I could be misreading it, but would be good to know :)
<RikMills> yeah, pango pubished 12+ hrs later
<RikMills> vorlon: may I ask what the rationale for triggering the cmake tests against 'gcc-defaults/1.185.1ubuntu1' is?
<vorlon> RikMills: baseline retests against the release pocket require specifying a trigger which is a package with no version in -proposed
<vorlon> I generally pick glibc, but there's currently a version in proposed
<RikMills> vorlon: so it would not work with the cmake version in release as a trigger?
<vorlon> RikMills: no, because the autopkgtest code gets confused and winds up pinning against the version of cmake from -proposed anyway and testing that
<RikMills> vorlon: thanks. that is actually REALLY useful to know :)
<RikMills> refreshing https://autopkgtest.ubuntu.com/running#pkg-cmake I just saw ppc64el win the race to a test fail in the way I expected
<RikMills> just wait for the rest I guess, and results
<RikMills> + s390x
<RikMills> I'll shut up now....
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1031.34~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1031.34~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (disco-proposed) [2.02.176-4.1ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: rejected lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (eoan-proposed) [2.7.17-1~19.10]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (eoan-proposed) [2.7.17-1~19.10]
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (bionic-proposed) [2.7.17-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (bionic-proposed) [2.7.17-1~18.04]
<vorlon> xnox: I happened to notice that nodejs is in the i386 whitelist as a build-dep-indep of ffmpeg, which is not critical but annoying.  did you have anything that would help with this?
<xnox> vorlon:  i had thoughts and no prayers
<xnox> vorlon:  does nodejs still ftbfs on i386 or is it ok?
<vorlon> xnox: no idea
<vorlon> xnox: it seems to be bfs, there's a version in -proposed synced today which has tests running
<xnox> vorlon:  wait
<xnox> we don't care about -Indep
<xnox> we only need -Indep on arch:amd64
<vorlon> xnox: we don't /in principle/ care about indep but they're still being traversed currently
<xnox> because we build _all.deb packages on amd64
<xnox> .... i guess we transverse them, because we do not have strictly knowledge that things build from source as arch builds without Indep installed?
<xnox> does launchpad install Indeps for arch builds today?
<vorlon> it does not
<vorlon> (I just checked the log to confirm)
<xnox> so either selectively blacklist the whitelist
<vorlon> xnox: so in principle it seems like this might be something that the no-follow-build-depends-all feature should handle
<xnox> not "-all" but like "-indep"
<vorlon> since the packages listed in Build-Depends-Indep are the build-depends of an arch-all package
<vorlon> no, I think it fits under the existing flag definition
<xnox> ah, existing flag is "no-follow-build-depends"
<xnox> if i recall correctly
<vorlon> no-follow-build-depends-all is the new flag I added (which cjwatson kindly merged)
<xnox> ah, i see what you mean
<xnox> oh
<xnox> ok
<xnox> well, there are corner cases
<vorlon> and which we use to not pull all of rust etc into the i386 set :)
<xnox> as context of other packages in the same source package matter
<xnox> i.e. arch: i386 arch:all  => is only built on i386 and needs Indep
<xnox> which is a bad example
<vorlon> I believe we still build the arch: all package on amd64 in that case also
<vorlon> and while there were designs for being able to specify build arch affinity for arch: all packages, there are zero such packages in practice (and I wouldn't expect there to ever be any specifying i386)
<xnox> Ack
<xnox> So, you want to skip B-D-Indep on i386, correct?
<vorlon> yeah
<infinity> I vaguely recall mentioning you'd need this. :P
<vorlon> but I mean, I can hack on this, I was just wondering if this would happen to fall out of the other germinate MP you already having
<infinity> It's probably a 1-2-liner (and test), if you find the place where it merges BD and BDI and conditionalise it on the no-blah-all flag being set.
<vorlon> yep
<xnox> vorlon:  definately not.
<xnox> vorlon:  my MP is for entirely different thing unfortunately.
<xnox> it has no good way to transverse past arch:all, non-multiarched apps.
<infinity> xnox: Oh, so I noticed your foreign arch MP follows foreign arch deps, but what I didn't see (or maybe I'm blind) is a way to explicitly seed " * foo [amd64:i386]" or " * foo:i386 [amd64]" (not sure which syntax I like better, might need a bikeshed with Colin), but I suspect that might come in handy.  It's entirely a fluke that the nvidia issue is "solved" by transitive deps.
<infinity> (And, actually, is it? ... The deps will only pull in one, surely not all)
<xnox> infinity:  we seed multiple amd64 versions, which have cross-arch recommends on the i386 versions
<xnox> infinity:  it was intentional for me to _only_ introduce cross-arch resolution without any new seed syntax.
<infinity> xnox: Oh, the recommends are from the nvidia packages?  Oh, right.  The release sprint is slowly coming back to me. :P
<xnox> infinity:  because we definately do not want "nvidia-drivers [amd64:i386]" as that would then pull in the whole of i386 graphics stack
<infinity> xnox: So, fair enough to land them as two different things indeed.  Just noting that the explicit seeding thing might be needed too at some point.
<xnox> infinity:  we only want the libnvidiafooXYZ:amd64|i386
<xnox> explicit seeding makes sence for truly i386 app, like wine
<xnox> which is M-A: nothing & arch:i386 and my current code cannot cope with that, past
<infinity> We might not need it now, but it feels like it would make the multi-arch handling more complete for future use.
<xnox> arch:all => arch:any deps boundary
<infinity> Anyhow, not urgent, just something to ponder.
<infinity> The nvidia thing is definitely the current pain point.
<xnox> indeed
<infinity> And I can't wait to kill the static file hack in debian-cd.
<xnox> the next pain point of mine, is to load all arches in one go
<xnox> such that s390-tools [s390x] opal-foo [ppc64le] util-linux => show up in the parsed ubuntu-server seed forexample from a single run on people.u.c/~ubuntu-archive/..../germinate.output/
<infinity> Ahh yeah, the part where we only run for one arch there is confusing to people trying to examine why something is included.
<infinity> I'll admit that it annoys me enough that I tend to use ftpmaster's copies instead, which are for all arches.
<infinity> Not exactly an option for most people.
 * vorlon nods
<infinity> We have a copy of ftpmaster's germinate run on snakefruit that we mirror literally every minute.  We could publish that in public_html if that would be helpful.
<infinity> It's only for the devel series, but that's what most people care about.
-queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => 3.192.26.1] (ubuntu-desktop, ubuntu-server)
<seb128> RikMills, cmake needs that fix it looks like? https://gitlab.kitware.com/cmake/cmake/merge_requests/3877
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1065.70] (kernel)
#ubuntu-release 2019-12-06
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.17 => 2.208.18] (desktop-core)
<RikMills> seb128: cmake devs say on the main reporting issue that they don't plan to backport that fix to earlier than 3.16. I am trying to clarify why.
<seb128> RikMills, good morning, ok, weird since it looks an easy enough change to me?
<RikMills> seb128: I agree. perhaps it is just as simple as being no more planned releases on those earlier branches
<seb128> RikMills, right, that would make sense if they don't consider it important enough to do another release on a serie which they don't consider active
<seb128> can someone skip the imagemagick/i386 autopkgtest result to make it candidate?
<rbalint> tjaalton, could you please accept base-files and update-notifier in your sru cycle? pam will also be ready in focal and i'm aiming at sruing update-motd and ubuntu-release-upgrader today with small fixes
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1065.70]
<tjaalton> rbalint: I'm officially off today, but we'll see
<rbalint> is there any sru team member who could look into them and also merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/376455 to let pam migrate?
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1009.10~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1009.10~18.04.1]
-queuebot:#ubuntu-release- New sync: libg15render (focal-proposed/primary) [1.3.0~svn316-2.4]
<seb128> can someone skipt dynare/i386 test for that package to be candidate? the i386 binary has been removed so I'm not even sure why the test result still are there/matter...
-queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.4-2ubuntu2 => 1.20.4-2ubuntu2.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: network-manager (disco-proposed/main) [1.16.0-0ubuntu2 => 1.16.0-0ubuntu2.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.2 => 1.10.6-2ubuntu1.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: network-manager (xenial-proposed/main) [1.2.6-0ubuntu0.16.04.3 => 1.2.6-0ubuntu0.16.04.4] (kubuntu, ubuntu-desktop)
<seb128> could also someone make http://autopkgtest.ubuntu.com/packages/l/lazr.restfulclient/focal/i386 being skipped for six?
<seb128> pg-checksums/i386 can we skip that as well?
-queuebot:#ubuntu-release- New binary: pympler [amd64] (focal-proposed/universe) [0.7+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- New: rejected libg15render [sync] (focal-proposed) [1.3.0~svn316-2.4]
-queuebot:#ubuntu-release- New: accepted pympler [amd64] (focal-proposed) [0.7+dfsg1-1build1]
<RikMills> vorlon: could you take a look at the imagemagick i386 test to see if that is hintable? I'm not 100% sure
-queuebot:#ubuntu-release- New source: libg15render (focal-proposed/primary) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New: accepted libg15render [source] (focal-proposed) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New binary: libg15render [amd64] (focal-proposed/universe) [1.3.0~svn316-2.4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libg15render [armhf] (focal-proposed/universe) [1.3.0~svn316-2.4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libg15render [s390x] (focal-proposed/universe) [1.3.0~svn316-2.4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libg15render [arm64] (focal-proposed/universe) [1.3.0~svn316-2.4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libg15render [ppc64el] (focal-proposed/universe) [1.3.0~svn316-2.4build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libg15render [amd64] (focal-proposed) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New: accepted libg15render [armhf] (focal-proposed) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New: accepted libg15render [s390x] (focal-proposed) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New: accepted libg15render [arm64] (focal-proposed) [1.3.0~svn316-2.4build1]
-queuebot:#ubuntu-release- New: accepted libg15render [ppc64el] (focal-proposed) [1.3.0~svn316-2.4build1]
<rbalint> bdmurray, i have uploaded the migrated repo to https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/+git/ubuntu-release-upgrader and made the last upload to focal from it
<rbalint> bdmurray, it looks ok
<rbalint> bdmurray, i suggest switching over to git now since I accidentally already left the Vcs-Git field in the last upload :-)
<ahasenack> vorlon: hi, another i386 migration issue for when you have a moment: talloc and samba/i386 https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#talloc
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1009.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: g15daemon [amd64] (focal-proposed/universe) [1.9.5.3-11] (no packageset)
<rbalint> vorlon, could you please accept base-files and update-notifier to eoan? pam will also be ready in focal and i'm aiming at sruing update-motd and ubuntu-release-upgrader today
-queuebot:#ubuntu-release- New binary: update-motd [amd64] (focal-proposed/main) [3.6-0ubuntu2] (core)
-queuebot:#ubuntu-release- Packageset: Added simplestreams to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added simplestreams to ubuntu-cloud in disco
-queuebot:#ubuntu-release- Packageset: Added simplestreams to ubuntu-cloud in eoan
-queuebot:#ubuntu-release- Packageset: Added simplestreams to ubuntu-cloud in focal
-queuebot:#ubuntu-release- Packageset: Added simplestreams to ubuntu-cloud in xenial
-queuebot:#ubuntu-release- New binary: update-motd [amd64] (focal-proposed/main) [3.6-0ubuntu3] (core)
<rbalint> vorlon, doko could you please accept the new binary package of update-motd?
<seb128> vorlon, can you mark http://autopkgtest.ubuntu.com/packages/p/postgresql-12/focal/i386 to ignore?
<doko> rbalint: done
-queuebot:#ubuntu-release- New: accepted g15daemon [amd64] (focal-proposed) [1.9.5.3-11]
-queuebot:#ubuntu-release- New: accepted update-motd [amd64] (focal-proposed) [3.6-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted update-motd [amd64] (focal-proposed) [3.6-0ubuntu2]
<LocutusOfBorg> apw, can you please kick out mocha from focal-proposed? that sync from experimental is making almost all nodejs related testsuites fail, such as node-sinon node-file-entry-cache node-aws4 node-tmp node-mongodb node-socket.io-parser node-superagent node-log-driver node-coveralls jsbundle-web-interfaces and probably more
<LocutusOfBorg> I hope RikMills can explain the rationale for the sync ^^
<LocutusOfBorg> I forgot ~10 other nodejs packages, and if you look at mocha autopkgtestsuite you find some more
<LocutusOfBorg> vorlon, ^^
<LocutusOfBorg> (using all nodejs packages from debian experimental works, but I don't want to sync all node* stuff from there)
<RikMills> LocutusOfBorg: hmmm. nearly a month ago... there was a reason, but honestly I don't recall right now
<LocutusOfBorg> I propose to drop it
<RikMills> I would think getting rid of it would be ok
<LocutusOfBorg> in any case it will autosync once it goes in sid
<RikMills> LocutusOfBorg: I can't disagree right now
<LocutusOfBorg> oh yes, rationale was oxygen-icons5
<LocutusOfBorg> meh, the reason for that test failure was probably elsewhere in nodejs (e.g. nodejs version)
<LocutusOfBorg> kicking mocha out should auto-heal it
<LocutusOfBorg> as soon as an AA does it, I can rekick nodejs stuff
-queuebot:#ubuntu-release- New binary: cupp [amd64] (focal-proposed/universe) [0.0+20190501.git986658-4] (no packageset)
-queuebot:#ubuntu-release- New binary: fabric [amd64] (focal-proposed/universe) [2.5.0-0.1] (no packageset)
<RikMills> LocutusOfBorg: if it was, oxygen-icons5 doesn't matter anyway (that version)
-queuebot:#ubuntu-release- New binary: libsearpc [amd64] (focal-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pypubsub [amd64] (focal-proposed/universe) [4.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pcre2 [amd64] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: python-watson-developer-cloud [amd64] (focal-proposed/universe) [4.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jpylyzer [amd64] (focal-proposed/universe) [1.18.0-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [amd64] (focal-proposed/multiverse) [1.8.19~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyvcf [amd64] (focal-proposed/universe) [0.6.8+git20170215.476169c-3] (no packageset)
-queuebot:#ubuntu-release- New binary: music [amd64] (focal-proposed/universe) [1.1.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-whiteboard [amd64] (focal-proposed/universe) [1.0+git20170915-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pcre2 [i386] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxcrypt [amd64] (focal-proposed/universe) [1:4.4.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: stimfit [amd64] (focal-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cupp [amd64] (focal-proposed) [0.0+20190501.git986658-4]
-queuebot:#ubuntu-release- New: accepted jpylyzer [amd64] (focal-proposed) [1.18.0-3.1]
-queuebot:#ubuntu-release- New: accepted python-watson-developer-cloud [amd64] (focal-proposed) [4.1.0-2]
-queuebot:#ubuntu-release- New: accepted fabric [amd64] (focal-proposed) [2.5.0-0.1]
-queuebot:#ubuntu-release- New: accepted python-whiteboard [amd64] (focal-proposed) [1.0+git20170915-3]
-queuebot:#ubuntu-release- New: accepted python-pypubsub [amd64] (focal-proposed) [4.0.3-3]
-queuebot:#ubuntu-release- New binary: meep-openmpi [amd64] (focal-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-mpi-default [amd64] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [amd64] (focal-proposed/universe) [5.15.0+dfsg-8] (no packageset)
<rbalint> vorlon, thanks for the review, i've updated the hints mr
-queuebot:#ubuntu-release- New binary: pcre2 [arm64] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pcre2 [armhf] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pcre2 [s390x] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxcrypt [arm64] (focal-proposed/universe) [1:4.4.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [armhf] (focal-proposed/universe) [1:4.4.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pcre2 [ppc64el] (focal-proposed/main) [10.34-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxcrypt [ppc64el] (focal-proposed/universe) [1:4.4.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [s390x] (focal-proposed/universe) [1:4.4.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyvcf [s390x] (focal-proposed/universe) [0.6.8+git20170215.476169c-3] (no packageset)
-queuebot:#ubuntu-release- New binary: music [arm64] (focal-proposed/universe) [1.1.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyvcf [arm64] (focal-proposed/universe) [0.6.8+git20170215.476169c-3] (no packageset)
-queuebot:#ubuntu-release- New binary: music [s390x] (focal-proposed/universe) [1.1.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: music [armhf] (focal-proposed/universe) [1.1.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [arm64] (focal-proposed/multiverse) [1.8.19~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyvcf [armhf] (focal-proposed/universe) [0.6.8+git20170215.476169c-3] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [armhf] (focal-proposed/multiverse) [1.8.19~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [s390x] (focal-proposed/multiverse) [1.8.19~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyvcf [ppc64el] (focal-proposed/universe) [0.6.8+git20170215.476169c-3] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [ppc64el] (focal-proposed/multiverse) [1.8.19~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: music [ppc64el] (focal-proposed/universe) [1.1.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stimfit [s390x] (focal-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stimfit [ppc64el] (focal-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-mpi-default [s390x] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-openmpi [s390x] (focal-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-mpi-default [ppc64el] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stimfit [arm64] (focal-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stimfit [armhf] (focal-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-openmpi [ppc64el] (focal-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-mpi-default [arm64] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-openmpi [arm64] (focal-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-mpi-default [armhf] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meep-openmpi [armhf] (focal-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted meep-openmpi [arm64] (focal-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted meep-openmpi [ppc64el] (focal-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted pcre2 [armhf] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted stimfit [arm64] (focal-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted stimfit [ppc64el] (focal-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted meep-openmpi [armhf] (focal-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted pcre2 [ppc64el] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted stimfit [s390x] (focal-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted meep-openmpi [s390x] (focal-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted stimfit [armhf] (focal-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted pcre2 [amd64] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted pcre2 [i386] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted stimfit [amd64] (focal-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted pcre2 [arm64] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted pcre2 [s390x] (focal-proposed) [10.34-5]
-queuebot:#ubuntu-release- New: accepted libsearpc [amd64] (focal-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-pyvcf [amd64] (focal-proposed) [0.6.8+git20170215.476169c-3]
-queuebot:#ubuntu-release- New: accepted python-pyvcf [ppc64el] (focal-proposed) [0.6.8+git20170215.476169c-3]
-queuebot:#ubuntu-release- New: accepted meep-openmpi [amd64] (focal-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted python-pyvcf [s390x] (focal-proposed) [0.6.8+git20170215.476169c-3]
-queuebot:#ubuntu-release- New: accepted python-pyvcf [armhf] (focal-proposed) [0.6.8+git20170215.476169c-3]
-queuebot:#ubuntu-release- New: accepted openvr [amd64] (focal-proposed) [1.8.19~ds1-2]
-queuebot:#ubuntu-release- New: accepted openvr [armhf] (focal-proposed) [1.8.19~ds1-2]
-queuebot:#ubuntu-release- New: accepted openvr [s390x] (focal-proposed) [1.8.19~ds1-2]
-queuebot:#ubuntu-release- New: accepted openvr [arm64] (focal-proposed) [1.8.19~ds1-2]
-queuebot:#ubuntu-release- New: accepted python-pyvcf [arm64] (focal-proposed) [0.6.8+git20170215.476169c-3]
-queuebot:#ubuntu-release- New: accepted openvr [ppc64el] (focal-proposed) [1.8.19~ds1-2]
-queuebot:#ubuntu-release- New: accepted libxcrypt [amd64] (focal-proposed) [1:4.4.10-5]
-queuebot:#ubuntu-release- New: accepted libxcrypt [armhf] (focal-proposed) [1:4.4.10-5]
-queuebot:#ubuntu-release- New: accepted libxcrypt [s390x] (focal-proposed) [1:4.4.10-5]
-queuebot:#ubuntu-release- New: accepted music [arm64] (focal-proposed) [1.1.16-1]
-queuebot:#ubuntu-release- New: accepted music [ppc64el] (focal-proposed) [1.1.16-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [arm64] (focal-proposed) [1:4.4.10-5]
-queuebot:#ubuntu-release- New: accepted music [amd64] (focal-proposed) [1.1.16-1]
-queuebot:#ubuntu-release- New: accepted music [s390x] (focal-proposed) [1.1.16-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [ppc64el] (focal-proposed) [1:4.4.10-5]
-queuebot:#ubuntu-release- New: accepted music [armhf] (focal-proposed) [1.1.16-1]
-queuebot:#ubuntu-release- New: accepted meep-mpi-default [amd64] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted meep-mpi-default [armhf] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted meep-mpi-default [s390x] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted meep-mpi-default [arm64] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted plplot [amd64] (focal-proposed) [5.15.0+dfsg-8]
-queuebot:#ubuntu-release- New: accepted meep-mpi-default [ppc64el] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1066.76] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1028.30~18.04.1] (kernel)
<LocutusOfBorg> AA ping for mocha removal
<LocutusOfBorg> (src:node-mocha)
<LocutusOfBorg> any AA, please: python3-pyside2.qttexttospeech/i386 unsatisfiable Depends: libqt5texttospeech5 (>= 5.8.0~alpha)
<LocutusOfBorg> vorlon, ^^ needs a removal?
<LocutusOfBorg> (searching on update_excuses for "/i386 unsatisfiable Depends" returns a lot of stuff
<seb128> vorlon, can you badtest golang-github-tdewolff-minify/i386 (blocking golang-github-tdewolff-parse) and postgresql-12/i386 (blocking elogind)
<seb128> also probably dynare/i386 blocing itself
<vorlon> RikMills: imagemagick/i386 hinted, thanks
<seb128> vorlon, it's a bit unclear to me how we trigger a 'reload for such cases, dynary has no i386 left in focal/focal-proposed
<seb128> why is britney caring about old i386 results?
<seb128> and what's the right way to tell it to reconsider the situation?
<vorlon> ahasenack: samba/i386 hinted
<RikMills> thank you!
<seb128> RikMills, did you figure out what to do about cmake/pango?
<vorlon> rbalint: typo in your changelog for base-files/eoan; I'll fix && reupload
<vorlon> rbalint: btw why did you make this conditional on id == 0 instead of just ignoring EPERM on write?
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (eoan-proposed) [11ubuntu7.19.10.0]
-queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu7 => 11ubuntu7.19.10.0] (core)
<RikMills> seb128: not exactly. I had no response yet. It does look a quite benign change to backport though. In theory sounds as if it would fix things like the navit FTBFS in the libgps transition
<RikMills> likewise, if all goes pear shaped, should be simple to revert
<vorlon> rbalint: erm.  also, the version number for base-files looks entirely wrong, why is this not 10.2ubuntu7.1?
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (eoan-proposed) [1.20.4-2ubuntu2.1]
<vorlon> seb128: postgresql-12 has been hinted (via rbalint)
<seb128> vorlon, great
<seb128> RikMills, at the same time the pango issue is due to pango not the cmake update so it might make more sense to force migrate the current version than to reset the tests matrix?
<seb128> then we can do another around with the patch...
<seb128> around->round (upload)
<vorlon> LocutusOfBorg, RikMills: node-mocha removed from focal-proposed
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (eoan-proposed) [1.3.1-5ubuntu1.19.10.0]
<RikMills> seb128: if the few regressions against cmake 3.15.4-1 are not serious or easily fixable, yes that would make sense I suppose
<vorlon> LocutusOfBorg: I'm not taking requests right now for individual removals of i386 binaries that are on the chopping block; I'm churning through the whole archive as fast as remove-package will go.  I'm currently still in the haskell packages
<LocutusOfBorg> thanks!
<RikMills> haskell on its will probably take ages :P
<LocutusOfBorg> kill it with fire!
<RikMills> *its own
<LocutusOfBorg> all haskell!
<vorlon> seb128: and golang-github-tdewolff-minify/i386 and dynare/i386 also now hinted.  FWIW I don't know why britney behaves the way it does, triggering tests for binaries on architectures that have been removed, but the pattern I've seen is that the /next/ time after removal, britney will manage to trigger tests only for the right architectures. needs debugging.
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (eoan-proposed) [4.1-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (disco-proposed) [4.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (bionic-proposed) [4.1~rc1-3~ubuntu18.04.3]
<LocutusOfBorg> nodejs is healing!
<ahasenack> vorlon: thanks (samba/i386 hint)
-queuebot:#ubuntu-release- New binary: node-eslint-visitor-keys [amd64] (focal-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-file-entry-cache [amd64] (focal-proposed/universe) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-node-sass [amd64] (focal-proposed/universe) [4.12.0-2] (no packageset)
<LocutusOfBorg> btw vorlon do you have any idea wrt an ocaml sync?
<LocutusOfBorg> or can you please do it? we have a lot of ocaml sadness on the proposed pocket...
<vorlon> LocutusOfBorg: I don't speak ocaml.  it looks like you were the last uploader?
-queuebot:#ubuntu-release- New binary: node-dottie [amd64] (focal-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-chai-as-promised [amd64] (focal-proposed/universe) [7.1.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu7 => 10.2ubuntu7.19.10.0] (core)
<LocutusOfBorg> vorlon, I think I remember you reintroducing the fpic hash patch... not sure why
<vorlon> LocutusOfBorg: I remember nothing of this, the changelog is your best guide :)
-queuebot:#ubuntu-release- New binary: psl.js [amd64] (focal-proposed/universe) [1.5.0+ds-1] (no packageset)
<LocutusOfBorg> doko, ^^ you introduced the two patches, and now with the new release they don't apply anymore, cleanly or not cleanly
<LocutusOfBorg> would you mind having a look?
<LocutusOfBorg> Pass --hash-style=both --no-copy-dt-needed-entries --as-needed to the linker.
<LocutusOfBorg> back in 2011
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1028.30~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1066.76]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1009.10]
-queuebot:#ubuntu-release- New binary: rust-nettle [s390x] (focal-proposed/universe) [5.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nettle [ppc64el] (focal-proposed/universe) [5.0.3-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (eoan-proposed) [11ubuntu7.19.10.0]
-queuebot:#ubuntu-release- New binary: rust-gstreamer [amd64] (focal-proposed/universe) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nettle [amd64] (focal-proposed/universe) [5.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gstreamer [s390x] (focal-proposed/universe) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gstreamer [ppc64el] (focal-proposed/universe) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (eoan-proposed) [10.2ubuntu7.19.10.0]
-queuebot:#ubuntu-release- New binary: rust-nettle [arm64] (focal-proposed/universe) [5.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt [s390x] (focal-proposed/universe) [0.3.1-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-structopt [amd64] (focal-proposed/universe) [0.3.1-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-nettle [armhf] (focal-proposed/universe) [5.0.3-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (disco-proposed) [1.16.0-0ubuntu2.1]
-queuebot:#ubuntu-release- New binary: rust-gstreamer [arm64] (focal-proposed/universe) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gstreamer [armhf] (focal-proposed/universe) [0.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt [armhf] (focal-proposed/universe) [0.3.1-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-structopt [ppc64el] (focal-proposed/universe) [0.3.1-1] (i386-excludes)
-queuebot:#ubuntu-release- New binary: rust-structopt [arm64] (focal-proposed/universe) [0.3.1-1] (i386-excludes)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (bionic-proposed) [1.10.6-2ubuntu1.3]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer [arm64] (focal-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer [ppc64el] (focal-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted rust-nettle [armhf] (focal-proposed) [5.0.3-2]
-queuebot:#ubuntu-release- New: accepted rust-structopt [arm64] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [ppc64el] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer [armhf] (focal-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [amd64] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [s390x] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-nettle [arm64] (focal-proposed) [5.0.3-2]
-queuebot:#ubuntu-release- New: accepted rust-structopt [armhf] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted node-chai-as-promised [amd64] (focal-proposed) [7.1.1-2]
-queuebot:#ubuntu-release- New: accepted node-node-sass [amd64] (focal-proposed) [4.12.0-2]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer [amd64] (focal-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted rust-nettle [amd64] (focal-proposed) [5.0.3-2]
-queuebot:#ubuntu-release- New: accepted rust-nettle [s390x] (focal-proposed) [5.0.3-2]
-queuebot:#ubuntu-release- New: accepted node-dottie [amd64] (focal-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer [s390x] (focal-proposed) [0.14.5-1]
-queuebot:#ubuntu-release- New: accepted psl.js [amd64] (focal-proposed) [1.5.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-nettle [ppc64el] (focal-proposed) [5.0.3-2]
-queuebot:#ubuntu-release- New: accepted node-eslint-visitor-keys [amd64] (focal-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted node-file-entry-cache [amd64] (focal-proposed) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-4]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.4]
-queuebot:#ubuntu-release- Packageset: 106 entries have been added or removed
<vorlon> infinity, xnox: ^^ fyi a one-off run of germinate with build-depends-indep pruned (and an MP raised)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (eoan-proposed) [1:0.7.6.0.1]
<LocutusOfBorg> handsome_feng, I'm syncing kylin-burner because I don't think the delta is still worth the effort... basically we were adding libunity-dev build-dependency
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.5]
<LocutusOfBorg> well, I'm merging it once again, please let me know if we can sync on next release
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (eoan-proposed) [1.0.4-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (disco-proposed) [1.0.4-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.12]
<rbalint> bdmurray, could you please check my follow-up mp for unbreaking u-r-u motd saving? https://code.launchpad.net/~rbalint/ubuntu-release-upgrader/+git/ubuntu-release-upgrader/+merge/376480
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.13]
<rbalint> bdmurray, sorry, i added one more thing to the mp
<RikMills> ilmbase/openexr transition looks to be migrating :) thanks for the various 'nudges'
<bdmurray> rbalint: When will pre-build.sh run?
<rbalint> bdmurray, before gbp buildpackage starts the build
<rbalint> bdmurray, i believe this matches bzr-builddeb's behaviour
<rbalint> bdmurray, i think since running pre-build.sh and the source build on bionic yielded different result on bionic and focal both should exit with error when running on an older release than the target, what do you think?
-queuebot:#ubuntu-release- New binary: rust-gstreamer-base [s390x] (focal-proposed/universe) [0.14.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gstreamer-base [ppc64el] (focal-proposed/universe) [0.14.4-1] (no packageset)
<bdmurray> rbalint: that seems reasonable
-queuebot:#ubuntu-release- New binary: rust-gstreamer-base [amd64] (focal-proposed/universe) [0.14.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [amd64] (focal-proposed/universe) [0.12.0-1] (no packageset)
<rbalint> bdmurray, i did not notice the script not running in the previous upload because i also passed the hook via the cmd line
-queuebot:#ubuntu-release- New binary: rust-gstreamer-base [armhf] (focal-proposed/universe) [0.14.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gstreamer-base [arm64] (focal-proposed/universe) [0.14.4-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:19.10.15.3 => 1:19.10.15.4] (core)
<rbalint> bdmurray, this matches the mp agains ubuntu/eoan ^
<rbalint> bdmurray, could you please drop the older upload of update-notifier for eoan? i'm regenerating the source upload honoring the pre-build
-queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => 3.192.26.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (eoan-proposed) [3.192.26.1]
<LocutusOfBorg> please accept rust in new queue?
-queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => 3.192.26.1] (ubuntu-desktop, ubuntu-server)
<rbalint> bdmurray, i noticed typos in the LP bug numbers, this should be ok ^
<rbalint> bdmurray, could you please accept the last one if it is ok?
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (eoan-proposed) [3.192.26.1]
-queuebot:#ubuntu-release- New binary: fwupd [amd64] (focal-proposed/main) [1.3.5-1] (core)
-queuebot:#ubuntu-release- New binary: fwupd [s390x] (focal-proposed/main) [1.3.5-1] (core)
-queuebot:#ubuntu-release- New binary: fwupd [ppc64el] (focal-proposed/main) [1.3.5-1] (core)
-queuebot:#ubuntu-release- New binary: opencolorio [amd64] (focal-proposed/universe) [1.1.1~dfsg0-4] (kubuntu)
<vorlon> sure, why shouldn't libsoup2.4 build-depend on php
#ubuntu-release 2019-12-07
-queuebot:#ubuntu-release- New binary: fwupd [arm64] (focal-proposed/main) [1.3.5-1] (core)
-queuebot:#ubuntu-release- New binary: meep [amd64] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gatb-core [amd64] (focal-proposed/universe) [1.4.1+git20191130.664696c+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gatb-core [ppc64el] (focal-proposed/universe) [1.4.1+git20191130.664696c+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meep [ppc64el] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gatb-core [s390x] (focal-proposed/universe) [1.4.1+git20191130.664696c+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meep [s390x] (focal-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted fwupd [amd64] (focal-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- New: accepted fwupd [ppc64el] (focal-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- New: accepted opencolorio [amd64] (focal-proposed) [1.1.1~dfsg0-4]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer-base [arm64] (focal-proposed) [0.14.4-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer-base [ppc64el] (focal-proposed) [0.14.4-1]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [amd64] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted fwupd [arm64] (focal-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer-base [amd64] (focal-proposed) [0.14.4-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer-base [s390x] (focal-proposed) [0.14.4-1]
-queuebot:#ubuntu-release- New: accepted fwupd [s390x] (focal-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-gstreamer-base [armhf] (focal-proposed) [0.14.4-1]
-queuebot:#ubuntu-release- New: accepted gatb-core [amd64] (focal-proposed) [1.4.1+git20191130.664696c+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gatb-core [s390x] (focal-proposed) [1.4.1+git20191130.664696c+dfsg-1]
-queuebot:#ubuntu-release- New: accepted meep [ppc64el] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted gatb-core [ppc64el] (focal-proposed) [1.4.1+git20191130.664696c+dfsg-1]
-queuebot:#ubuntu-release- New: accepted meep [s390x] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted meep [amd64] (focal-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.5-1 => 1.3.5-1] (core)
-queuebot:#ubuntu-release- New binary: liblouis [amd64] (focal-proposed/main) [3.12.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted liblouis [amd64] (focal-proposed) [3.12.0-2]
<vorlon> doko: do you happen to remember if there's a reason dh_python3 generates dependencies on python3:any, but python3.7 without the :any?
-queuebot:#ubuntu-release- Unapproved: update-motd (eoan-proposed/main) [3.6-0ubuntu1 => 3.6-0ubuntu1.19.10.0] (core)
<vorlon> infinity: we're left with a number of binary packages that are built from whitelisted source packages, and uninstallable on i386 because those binaries weren't seeded and they have deps on things not in the whitelist (e.g., audispd-plugins, bluez-cups, ...) do you have opinions on what to do with these?
<infinity> vorlon: I find it odd that we're not seeding sources for the exercise, rather than binaries.
<vorlon> does germinate have an option to seed by source?
<infinity> vorlon: %source is a source entry in a seed (see supported-kernel-common, for instance)
<vorlon> also I don't think it's to anyone's benefit to keep a bunch of extra source packages building on i386 just to make these packages "installable"
<infinity> I think a bunch of uninstallable packages will lead to a distinct "lack of quality" feel to the whole thing.   I don't care so much about the solution (source deltas to not build those binaries, P-a-s to not publish them, or making them actually installable), but I don't think "a bunch of stuff in the archive we can't install" is great.
<infinity> And yes, I know there are any number of arch:all packages that fit that description too (on many arches, but now a whole bunch on i386), and that's a stickier problem.
<vorlon> infinity: right, I'm fine with us making the binaries go away, and yeah I was just going to make the same point re: arch:all
<vorlon> although the difference with arch:all packages is that, if i386 is a foreign arch (the expected end-user use case), apt+dpkg alway treat that as a native-arch package
<vorlon> so it will be installable
<infinity> Making the binaries go away needs to be done "properly" (either by telling LP not to publish them in a P-a-s style feature that it doesn't have, or by altering the source), both of which are a bit icky.
<vorlon> so, I'd definitely prefer introducing deltas to remove the binary packages rather than making them installable
<vorlon> I'm not sure there's a way to do that in a way that's upstreamable to Debian... maybe some dh -p magic in debian/rules
<infinity> Anyhow, having them uninstallable is something we can live with in the very short term, but it'll lead to stalled britney migrations without hinting, and then hinting will lead to unintended side-effects when britney decides that trading 3 uninst on s390x for 4 uninst on i386 is a good deal, or whatever.
<infinity> (That said, my hatred of britney's uninst-trading feature is much lower these days now that we attempt to keep the uninst count close enough to zero that we can actually see what's happening)
<infinity> vorlon: I am genuinely curious how much bigger the set would get if it was a full closure of all binaries generated from the sources we seed, though.  If it's only 5% or 10%, that seems worth the hassle to not have to think too hard, if it's 50%, maybe not.
<vorlon> I didn't think britney traded uninstallables across architectures?  and also none of these should magically become installable
<infinity> Fair point.
<infinity> Still curious about how much the set would grow.
<vorlon> infinity: tbh I'm still inclined to go the other direction and find more things to cut, for example gst-plugins-bad1.0 is explicitly seeded and that build depends on opencv which pulls in vtk and I want that to die
<infinity> I suspect somehting like 'Extra-Include: *' would do the trick.
<infinity> vorlon: I only have gst-x, gst-base, abd gst-good installed here on i386.  All of which I didn't do on purpose, so I assume those are "needed", and others maybe less so.
<vorlon> infinity: wine in some cases goes looking for gst-plugins-bad
<infinity> But, OTOH, if those are needed for something, then so is -bad as soon as that thing wants to play an MP3. :P
<infinity> Or whateevr is in bad these days.
<infinity> It occurs to me that the i386 Packages file could be much smaller if it wasn't for all the useless arch:all too.  I wonder if the whitelist feature could be extended to also not publish arch-all for non-whitelisted packages (and then we'd have to whitelist all the arch:all stuff we want, but that seems feasible)
 * infinity wanders off again.
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [amd64] (focal-proposed/universe) [4.13.2-dfsg1-4ubuntu1] (no packageset)
<vorlon> in practice the arch: all stuff we want is already included in the whitelist
<vorlon>   samba (2:4.11.1+dfsg-3ubuntu1): libnss-winbind libpam-winbind python3-samba samba samba-common-bin samba-testsuite winbind
<vorlon> wonder if we should've included nss modules in the whitelist explicitly
<vorlon> why did ia32-libs depend on gvfs, that seems pointless
<vorlon> hmm I guess that package provides the gio plugin that lets apps talk to gvfs.  So not actually pointless
<vorlon> just another annoying dep tree that it pulls in as a result (leading to pacemaker ;)
<vorlon> doko: britney thinks a large number of *-cross packages are NBS, but cron.NBS does not, and they're uninstallable.  Do you know what's needed there? https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt
<infinity> vorlon: cron.NBS fails miserably at finding stuff that's NBS on a subset of arches.
<vorlon> infinity: so I should just manually nuke them?
<infinity> Perhaps, yes.  Check outdate.
<vorlon> "outdate"?
<infinity> https://people.canonical.com/~ubuntu-archive/testing/focal_outdate.txt
<infinity> Which doesn't seem to think anything's NBS...
<infinity> I'm not seeing britney thinking things are NBS.  Am I blind?
<vorlon> infinity: at the end of update_output it has a long list of foo-cross packages that it says it wants to remove...
<infinity> Wow, now I'm confused.  uninst shows those are from 32ubuntu2, but the only version in the archive is 32ubuntu1...
<infinity> Oh, 31ubuntu2.
<infinity> Lysdexia.
<infinity> So yeah, looks like all the dgb packages were dropped.  Why the outdate britney run isn't seeing that, I don't know.
<vorlon> the trivialness of the fixes to make all of these packages cross-testable is really quite satisfying
#ubuntu-release 2019-12-08
<RikMills> vorlon: kconfig on the whitelist?
<vorlon> RikMills: it is; but it seems something went wrong with said whitelist, because some of its transitive build-deps got removed
 * vorlon works on figuring that out
<vorlon> ah
<vorlon> did kconfig's build-depends change after we started removals?
<vorlon> hmm no
<vorlon> did pkg-kde-tools's dependencies change?
<vorlon> not that either
<vorlon> guess I need to dig into germinate
<RikMills> yes, I am curious why kconfig is on the list anyway
<vorlon> RikMills: build dependency of something; germinate-output shows
<vorlon> oh and there's the problem, lintian in -proposed grew a number of new deps
<RikMills> got that. just puzzled as to the culprit
<RikMills> ahhhhh
<RikMills> some not in main IIRC
<vorlon> so if lintian had migrated, this would've been visible to germinate
-queuebot:#ubuntu-release- Packageset: Added libclass-xsaccessor-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libdigest-sha-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added python-etcd to i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: python-pyface [amd64] (focal-proposed/universe) [6.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: povray [amd64] (focal-proposed/universe) [1:3.7.0.8-3] (no packageset)
<RikMills> kconfig built!
<RikMills> looks like changes to seeds is not getting copied to https://people.canonical.com/~ubuntu-archive/seeds/
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [amd64] (focal-proposed) [4.13.2-dfsg1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-pyface [amd64] (focal-proposed) [6.1.2-1]
-queuebot:#ubuntu-release- New: accepted povray [amd64] (focal-proposed) [1:3.7.0.8-3]
<RikMills> the libgdk-pixbuf2.0-common 2.40.0+dfsg-1ubuntu1 binaries say they have been deleted, while the rest of that ubuntu1 in proposed still exists?
<RikMills> which makes ultimately libgtk-3-dev and friends uninstallable in proposed
<RikMills> friends = all gtk3 stuff
<RikMills> Deleted 7 hours ago by Steve Langasek
<RikMills> Hack around gdk-pixbuf circular build-dep
<RikMills> something else in play then :)
<doko> vorlon: not directly, http://autopkgtest.ubuntu.com/packages/b/binutils/focal/i386 might be related, so lsb-release isn't installable
<vorlon> RikMills: because gdk-pixbuf has a circular build-dependency, and the fact that the arm builds were behind and missed building during the same publishing window made them ftbfs, and then the arm builders were badly backlogged. :P
<vorlon> I've done the self-copy back to focal-proposed now
<RikMills> ah, good. I didn't doubt there was a good reason. it just looked very strange at 1st!
<vorlon> doko: the uninstallables I was asking about were all on amd64
<vorlon> doko: could you omit the gccbrig-* packages on i386?  they build but are uninstallable because they require libhsail-rt-9-dev which we have no reason to provide
<vorlon> RikMills: gdk-pixbuf is republished, so if there's anything you have in -proposed that ftbfs because of the uninstallability you can retry it now
<RikMills> vorlon: thanks!
-queuebot:#ubuntu-release- New binary: pmemkv [amd64] (focal-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.440 => 1.440.1] (core)
-queuebot:#ubuntu-release- New binary: python-pbcore [amd64] (focal-proposed/universe) [1.7.1+git20191121.7947eb7+dfsg-2ubuntu1] (no packageset)
