#ubuntu-release 2010-06-21
<lamont> ScottK: postfix 2.7.1-1 uploaded to debian, btw
<ScottK> lamont: Thanks.
<slangasek> lamont: are clementine and acorn still the right machines for armel livefs builds?  I'm noticing a lot of failed livefs build attempts with no corresponding logs at all
<lamont> clementine iz dead.  or should be.
<lamont> acorn is your happiness, or should be.
<lamont> though with acorn, try again...
<slangasek> erm, so we're down to one again?
<slangasek> lamont: why did clementine go away?
<lamont> pegatron bad.
<lamont> must kill all pegatron
<slangasek> is it being *replaced* with something?
<lamont> slangasek: did you want a second one?
<slangasek> yes!
<lamont> slangasek: and do you have the ability to put a buildd on manual?
<slangasek> no
<lamont> that is a sadness
<lamont> so basically, if you want a second one, I need to (a) steal a buildd, or (b) we dual-load it sometimes
<lamont> what's your pleasure?
<lamont> slangasek: oh and hey, bind9 1:9.7.1.dfsg-1 wants to come over from debian once it gets out of incoming, kthx
<slangasek> well, I don't understand why clementine was killed in the first place; I was thoroughly expecting acorn to be supplementing clementine, not replacing it
<lamont> all of the pegatron machines were temporary until we got in usable boards.  you really don't want the full details behind the pain that they were
<slangasek> bind9> can do
<slangasek> hmm
<lamont> so once all the current hardware was online, we shot the pegatroids in the head
<slangasek> I don't have stats on arm buildd capacity to say that a buildd should be stolen to be a livefs builder, but being back down to one livefs buildd will be painful
<lamont> it's been doing well with 8.  though atm, 2 of them have faceplanted and will be down until someone goes to powercycle them
<lamont> 7 did pretty OK when we had that many... so stealing a second one to be dedicated livecd cruncher shouldn't be too bad, I expect
<slangasek> what about when it comes time to do a rebuild of all of main again on armel next month? :)
<lamont> that, we could use $MOAR machines for
 * slangasek nods
<lamont> and we could always temporarily drop you to 1 or 0 livefs builders for that. :-p
<slangasek> heh
<lamont> once it's back online, I'll make sycamore your other livecd builder
<slangasek> cheers :)
<lamont> slangasek: my test build to confirm things is running on sycamore now
<lamont> (and will give you a lucid ubuntu armel livecd fs if that's of any use to you
<slangasek> don't think I need one at the moment, thanks :)
#ubuntu-release 2010-06-22
<slangasek> lamont: do you know why there are no kernels at http://acorn.buildd/~buildd/LiveCD/maverick/ubuntu-netbook-imx51/ ?
<slangasek> lamont: n/m, it's because there are no kernels installed :/
<ogra_> slangasek, there shouldnt even be any buiuld attempts
<ogra_> slangasek, we dont build any non OMAP images in maverick (and OMAP is still being worked on)
<slangasek> ogra: er, no one updated the crontab to say that
<ogra> huh ?
<ogra> imx51 was disabled months ago
<ogra> *SIGH*
<ogra> you are indeed right
<slangasek> :-)
<slangasek> ok, so the crontab change was committed but not made live :)
<ogra> though no imx51 but there are omap buiolds
<ogra> there shouldnt be any armel builds atm
<ogra> i was about to enable them tomorrow
<ogra> omap images will be broken anyway, all other armel arches are unsupported atm
<ogra> so i didnt want to build them to prevent us from having to clean up
<slangasek> well, the flipside is that having no arm images building for months means no one will be working on cleaning up the problems for months :)
<ogra> we're completely redesigning the armel images
<ogra> i didnt want to have anything that interferes with the new stuff
<ogra> debian-cd and livecd-rootfs already have their changes, cdimage publishing code is still pending but i plan to land that before end of my day
<slangasek> yes, but general archive installability problems will also tend to accumulate if not tended
<ogra> we largely wiped the old scripts for omap
<ogra> we watch the ftbfs table closely
<ogra> and from A2 on we'll have dailies again
<slangasek> ok
<ogra> (i hope)
<ogra> looks like nothing buiolt anyway ... at least cdimage doesnt show any images
<slangasek> ogra: correct - but it sends mail /about/ the images not building :)
<tsimpson> cjwatson: ping
<cjwatson> tsimpson: hi
<cjwatson> only sort of here
<tsimpson> cjwatson: ok, we need to set up and entry message for all logged channels, and you're the only one who can do that here
<tsimpson> cjwatson: mind if I /msg you the details?
<cjwatson> ok
<cjwatson> set an entry message, and given some rights to UbuntuIRCCouncil
<cjwatson> (+votisA)
<tsimpson> yay, it works :)
#ubuntu-release 2010-06-23
<slangasek> ogra: publish-daily is broken by the latest merge
<ogra> eek
<ogra> what broke ?
<ogra> i know NCommander tested it with a local setup and didnt see any obvious code breakage
<ogra> and *i* didnt see ...
<ogra> slangasek, whats the error ?
<slangasek> there's a missing esac
<ogra> sigh, thats definately my fault then
 * ogra sees it 
<ogra> slangasek, sorry for that, fixing
<ogra> slangasek, fixed and committed
<slangasek> ogra: thanks!
<ScottK> slangasek: I'd appreciate it if you would give dovecot in binary New a look.  I think I got all the package renaming magic right, but a good second set of eyes would be appreciated.
<slangasek> ScottK: looking
<ScottK> Thanks.
<slangasek> ScottK: E: mail-stack-delivery: maintainer-shell-script-fails-syntax-check preinst
<slangasek> a missing esac
<slangasek> (seems to be a lot of that going around today :)
<ScottK> Argh.
<slangasek> on the bright side, it's the preinst, so it won't break anyone's system ;)
<slangasek> prep_mv_conffile mail-stack-delivery "/etc/dovecot/conf.d/01-dovecot-postfix.conf"
<slangasek> that won't work
<slangasek> the first arg needs to be the name of the package that owns the existing conffile
<slangasek> mv -f "/etc/dovecot/dovecot-postfix.conf"  "/etc/dovecot/mail-stack-delivery.conf"
<slangasek> surely that's not a conffile, so there's no reason to move it?
<ScottK> It's not, OTOH, it seemed reasonable.
<slangasek> ScottK: looks to me like it leaves it behind as an orphaned file on package removal
<ScottK> OK.  Obviously I need to go do the testing that I would have thought someone would have done before they uploaded it (and why I didn't upload it myself)
<ScottK> Thanks for looking at it.
<slangasek> sure
#ubuntu-release 2010-06-24
<ogra> slangasek, did you re-enable the omap netbook builds ?
 * ogra wonders where http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100624/maverick-netbook-armel+omap.img comes from, it shouldnt exist
<slangasek> ogra: I haven't touched the crontab at all
<ogra> weird
<ogra> i wonder where that image comes from :)
<slangasek> ogra: from what I see, *you* haven't touched the crontab either
<slangasek> at least, those jobs are all still enabled
<ogra> pitti disabled the omap builds ages ago
<ogra> at least he said so
<ScottK> ogra: I've been getting 3 armel build failure mails a day for kubuntu-netbook.
<ScottK> Did sync source and sync source new get done today?
<ogra> ScottK, well, there shouldnt be any builds for kubuntu on omap either
<ogra> since we're completely changing armel builds
 * ScottK wonders why he gets the mails then?
<ogra> because apparently something still builds them
<ogra> hrm
<ogra> indeed omap is still in the crontab
<ogra> but the kubuntu entry is odd
<cjwatson> hmm, it's import freeze isn't it
<cjwatson> I suppose I had better do a sync run
#ubuntu-release 2010-06-25
<slangasek> lamont: it appears livecd.sh requires ltsp-build-client for edubuntu, but this isn't installed on cardamom
<Riddell> $ copy-package.py -j -s lucid --to-suite=mavierck gstreamer0.10-fluendo-plugins-partner
<Riddell> 2010-06-25 11:55:16 ERROR   Cross-PARTNER copies are not allowed.
<Riddell> is there any way I can copy packages from lucid partner to maverick partner?
<Riddell> brian requested it
<cjwatson> does spelling maverick correctly help?
<cjwatson> otherwise I don't know, you'd have to check with #soyuz
#ubuntu-release 2011-06-24
<lamont> there will be a brief disturbance in the ppa universe for maintenence
<hggdh> folks, the Oneiric server ISO has changed -- there is a Packages.gz that is a link to another Packages.gz: dists/oneiric/restricted/debian-installer/binary-amd64/Packages.gz link to dists/oneiric/restricted/binary-amd64/Packages.gz
<hggdh> is this correct? It breaks bsdtar when expanding the ISO
<slangasek> hggdh: provided that the packages file contains both the .debs and the .udebs, I'd say it's correct
<hggdh> slangasek: seems empty, 20 bytes in lenght. But bsdtar fails on it (trying to write to a read-only, already-extracted, file)
<slangasek> hggdh: so, the empty Packages.gz for restricted doesn't seem out of the question to me.  I don't know what would have changed to make these files links to each other, but I guess that's a bsdtar bug
<hggdh> not really a bug, but a known restriction -- bsdtar expands an ISO as read-only. And this link is new, until A1 we did not do it (and had no breaks :-)
<slangasek> no, it's a bug that bsdtar doesn't correctly handle the hardlink
<cjwatson> hggdh: we hardlink identical files on the CD together because it saves something like 5MB of space on the server CD
<cjwatson> hggdh: not that small file in particular, of course, but there are two copies of the kernel in different places and it makes a big difference there
<cjwatson> hggdh: I'm surprised that there's no way to get bsdtar to handle that, and if there isn't then it seems like a bsdtar bug to me
<cjwatson> hggdh: I made this change when switching to hybrid images (see ubuntu-devel a week or two back)
<hggdh> cjwatson: I can agree it is a bsdtar bug, but we do not have many options to extract an ISO
<hggdh> I cannot mount the ISO because I do not have admin access on tamarind (otherwise it would be mount && cp -r)
<sbeattie> hggdh: what version of bsdtar/os release? I don't recreate the error locally.
#ubuntu-release 2011-06-25
<hggdh> sbeattie: hardy... on tamarind :-(
<sbeattie> ooh, hardy. I went back to lucid and still couldn't reproduce it.
<hggdh> I am hacking a lucid one there, will just install the binary & libs
#ubuntu-release 2011-06-26
<Laney> please be aware that the mono transition needs help, cf <1308878833.2523.21.camel@desire>
<Laney> not asking you to do anything, just to be aware that it is ongoing and proceeding slower than we'd like
#ubuntu-release 2012-06-18
<brendand> does anyone know the milestone at which the images go from being hosted on cdimage to being hosted on releases?
<brendand> i see alpha1 is on cdimage. will alpha2 be?
<cjwatson> brendand: we normally put betas on releases.u.c, not alphas
<brendand> cjwatson, thanks. that would make the most sense. is there any sort of enforcement around that? will betas always be on releases?
<cjwatson> Why are you asking?
<cjwatson> It's currently implemented in lp:ubuntu-archive-tools publish-image-set.pyp
<cjwatson> .py
<cjwatson>     if 'alpha' in milestone:
<cjwatson>         official = 'no'
<cjwatson>     else:
<cjwatson>         official = 'named'
<brendand> good enough for me
<brendand> it's for a script that needs to assemble url's to iso's as part of it's operation
<cjwatson> OK
<brendand> cjwatson, are there a fixed number of possible milestones?
<cjwatson> brendand: No
<Laney> I would appreciate it if people could comment on my proposal on list so that it can be rolled out before A2 freezes start if indeed we want it.
<Laney> it would involve a DB change to LP, so the lead time is kind of long
<tumbleweed> Laney: is this a safe change to make, before we can get -backports to build against packages in -backports?
<Laney> I think the intended fix there is to have the buildds ignore it
<Laney> and I believe infinity was going to do that, so maybe it is a simple matter of pokage
<jamespage> please could someone reject 'simple-http' from the quantal NEW queue - uploaded with a crufty orig.tar.bz2
<seb128> jamespage, done
<jamespage> thanks seb128!
<seb128> yw
<stgraber> mute tracker
<stgraber> mute
<stgraber> unmute tracker
<stgraber> ^ upgraded to the multi-threaded version, should be lower latency for queue monitoring and when controling the mute entries
<xnox> stgraber: =))))
<highvoltage> stgraber: I guess LP bug 1013172 is a security bug?
<stgraber> highvoltage: no, just private
<highvoltage> ah right I guess since it might contain passwords
<stgraber> highvoltage: and it's public now as it doesn't contain anything private that I could see
<highvoltage> stgraber: I think it might contain passwords entered in ubiquity
<stgraber> highvoltage: no, ubiquity wasn't running in debug mode, so the debconf transactions aren't logged and IIRC even when it's in debug mode, the passwords are stripped
<highvoltage> stgraber: ok great
<stgraber> highvoltage: oh, I see the problem. cjwatson ported ubiquity-bluetooth-agent to python3 but didn't add a dependency on python3-gobject
<stgraber> highvoltage: I'll quickly test that it's indeed the only missing bit and will add the dependency if that's the case
<highvoltage> stgraber: k
<cjwatson> stgraber: no such thing as python3-gobject
<cjwatson> stgraber: needs to be ported to gi
<stgraber> cjwatson: yeah, I just noticed. Moving it to Gobject from gi.repository
<cjwatson> (which looks like it should be easy)
<cjwatson> but yeah, my bad for not noticing that
<cjwatson> stgraber: "IIRC even when it's in debug mode, the passwords are stripped" sadly not
<cjwatson> (well, unless I've forgotten something)
<stgraber> cjwatson: that's too bad, though at least it's easy to check in the logs whether they're running in debug mode or not and carefuly check then...
<stgraber> cjwatson: "from gi.repository import GObject as gobject" did the trick, same API
<cjwatson> Good, but no need to use 'as gobject', you can just change the single place where it's used
<cjwatson> Sorry, two places
<stgraber> indeed :)
<stgraber> could someone review my -proposed upload of nagios-plugins in hardy-proposed, it's been waiting in the queue for 10 days now?
<xnox> stgraber: review or SRU verify?
<stgraber> xnox: just review and let through to -proposed. Verification is easy, I have 15 machines hitting the bug every day :)
<xnox> stgraber: ok =))))
<stgraber> so I just need to upgrade them to that package and check that I don't get angry e-mail from Nagiosafter that
 * xnox has stopped reading automatic email from my server.... maybe I should make them less verbose
<stgraber> yeah, I have adopted a policy of fixing the source of the e-mail rather than ignoring them, monitoring is pointless if you don't read the notifications :)
<henrix> infinity: hi. could you take a look at the hardy kernel, to copy it into -proposed?
<henrix> infinity: bug #1012143
<ubot2> Launchpad bug 1012143 in linux "linux: 2.6.24-31.102 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1012143
<infinity> henrix: I thought you guys were doing the proposed copies yourselves these days (except where we need to clean up overrides after the fact)
<infinity> henrix: But this one shouldn't need override tidying, as there's no ABI bump.
<henrix> infinity: well, i know we execute the copy-proposed-kernel.py script, but that alone doesn't do the job, does it?
<henrix> infinity: i believe brad executed that script on this kernel already anyway
<henrix> infinity: (i don't actually have upload rights, so i can't run the script. but i can bug other guys on the stable team to do... something...?)
<infinity> henrix: copy-proposed-kernel.py is all that should be required in this case.
<henrix> infinity: hmm, ok. so maybe brad forgot to run it on this kernel.
<henrix> infinity: so, i'll ping him again to run it.
<henrix> infinity: thanks
<infinity> henrix: I can just do it right now.
<infinity> henrix: Was just pointing out that you guys can, and have been. :)
<henrix> infinity: yeah, i knew we were able to run that script but i though something else had to be done by an AA
<infinity> henrix: AAs need to intervene post-script-run if there's an ABI bump (because the new packages land in universe)
<henrix> infinity: but it looks like this is only needed for kernels that require the overrides
<infinity> henrix: For non-ABI-changing uploads (like this one), we don't need to get involved.
<henrix> infinity: ok, got it. thanks for the clarification.
<infinity> henrix: Oh, hah.
<infinity> henrix: It could be that the script has been run a few times and no one has accepted it from UNAPPROVED.
<infinity> :P
<infinity> La la la.
<infinity> Done.
<henrix> infinity: heh :)
<henrix> infinity: cool, thanks! :)
<infinity> Sorry, this is a rather Mondayish Monday.
<henrix> infinity: yeah, similar problem here!
 * slangasek blinks
<slangasek> 2012-06-18 18:50:40 ERROR   Cross-PARTNER copies are not allowed.
<slangasek> what's that about?
<slangasek> hmm, apparently requires --to-partner with it, ok
#ubuntu-release 2012-06-19
<RAOF> What the hell's happening with software-center in precise-proposed?
<RAOF> Ah, that's what.
<ScottK> RAOF: I have a bit of time for SRU training, if that should happen to fit with your schedule?
<RAOF> ScottK: Yeah, why not. I'm currently processing the queue anyway.
<ScottK> OK.  How should we do this?
<RAOF> Let's start with our status pages, and pick off some representative tasks.
<ScottK> OK.  PM or here (not sure if we need to bore everyone with this - I'm good either way thoug)?
<RAOF> You're already familiar with the archive tools, so those bits won't be very interesting; it'll mostly be the process that you need learning?
<cjwatson> If it's here it's logged, which might be useful later.
<ScottK> Oh.  We already moved, but I don't think it's that useful.
<stgraber> looks like the new queuebot isn't nearly as reliable, reverting, will test it some more
<RAOF> cjwatson: I've run ScottK through the various SRU processes; given he's already an AA you could probably add him to ~ubuntu-sru now.
<cjwatson> RAOF,ScottK: Fine by me - done
<cjwatson> Thanks :-)
<ScottK> Thanks.
<ScottK> Inaugural SRU accept done ^^^.
 * micahg hugs ScottK
<micahg> RAOF: re the chromium SRU, I have not done any further testing, but as it seems to have fixed a top crasher, I'm tempted to say, let's just push it out
 * micahg likes the first seen/last seen on errors.u.c
<micahg> RAOF: at least for precise that is, let me get back to you tomorrow on that
<bradm> anyone about who could help with cleaning up cdimage machines?
<cjwatson> bradm: Yes
<cjwatson> bradm: Do you mean nusakan or cdimage.u.c?
<bradm> cjwatson: ultimately cdimage.u.c
<bradm> cjwatson: those servers are getting close to running out of space
<cjwatson> ah, I see the problem, purging wasn't running for the precise daily builds
<bradm> cjwatson: I see there's some 150G of kubuntu precise daily images
<RAOF> micahg: Thanks. Given that it fixes a number of security flaws it's probably worth pushing out, even if it has some new crashers.
<RAOF> Stupid browsers. Why can't they just work :)
<cjwatson> bradm: as I say, the auto-purging was broken - no need to single out Kubuntu
<bradm> cjwatson: ah, right
<bradm> cjwatson: so do you need anything done from our side?
<cjwatson> Nope
<cjwatson> Should have it fixed in a few minutes
<bradm> excellent, thanks
<cjwatson> bradm: syncing out now; -> bed
<ScottK> All the way up to 21.0 kB/s.  Ain't hotel wifi wonderful.
<bradm> cjwatson: thanks heaps
<tkamppeter__> cjwatson, hi
<NCommander> infinity: you awake? part of the highbank kernel landed in universe by accident
<NCommander> (linux-highbank is the binary). The rest went into main, I think this was just an oversight
<NCommander> I can write a MIR if required though
<NCommander> ^- (or any awake archive admin)
<infinity> NCommander: In which release?
<infinity> NCommander: Oh, security, updates, and proposed.  Slick.
<infinity> NCommander: Will fix.
<NCommander> infinity: thanks
<NCommander> brbr, need to reboot
<NCommander> back
<infinity> NCommander: Should be all fixed in ~60m or so.
<NCommander> great
<infinity> It might be bedtime.  I just (intentionally) did a clean-room reimplementation of dpkg-maintscript-helper.  I feel kinda dirty.
<NCommander> infinity: ow
<NCommander> infinity: why did you reimplement it though?
<infinity> NCommander: Because I needed to mangle the files halfway through the rename/remove process, so I couldn't use rm_conffile, for fear that if the implementation changed, it would break my mid-helper fiddling.
<xnox> NCommander: i think he was merging dpkg all night or something of that sort
<NCommander> infinity: ow. I think you broke my brain
<cjwatson> tkamppeter: Hello
<tkamppeter> cjwatson, I have uploaded a SRU for foomatic-filters, bug 1002699. Can you approve the package? Thanks.
<ubot2> Launchpad bug 1002699 in foomatic-filters "cups not respecting printing options" [High,Fix committed] https://launchpad.net/bugs/1002699
<cjwatson> tkamppeter: I normally leave new SRUs to the other members of the SRU team - they're better practised at it than I am
<cjwatson> They should see it in the queue
<NCommander> win 26
#ubuntu-release 2012-06-20
<tkamppeter> ScottK, hi
<tkamppeter> ScottK, bug 932882 updated.
<ubot2> Launchpad bug 932882 in gutenprint "Update of a printer driver package does not update the PPD files of the existing queues for this driver" [High,Fix committed] https://launchpad.net/bugs/932882
<tkamppeter> ScottK, bug 1002699 updated.
<ubot2> Launchpad bug 1002699 in foomatic-filters "cups not respecting printing options" [High,Fix committed] https://launchpad.net/bugs/1002699
<xnox> there is a 'stamp' http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-amd64.OVERSIZED
<xnox> was that adjusted for the 800M(something) size?
<Laney> doesn't look like it
<Laney> quantal-desktop-amd64.iso           19-Jun-2012 07:53  722M
<xnox> Laney: I wasn't sure if 722 is over 800 using the M-unit of the day
<xnox> three apport popups in quantal daily =) and I didn't even start testing the thing I was meant to test! =)
<micahg> seb128: can you please release the firefox updates from the lucid, natty, oneiric, and precise queues?
<seb128> micahg, how do I do that? I don't do security copies usual so I'm a bit unsure ;-)
<micahg> seb128: it's AA approval in queue
<micahg> they're in unapproved
<seb128> ok
<seb128> micahg, done
<micahg> seb128: thanks, here's to hoping I caught the publisher :)
<cjwatson> Can somebody who isn't an archive admin give me a quick hand with a bit of Launchpad QA?
<cjwatson> I just want to make sure that the new API method is correctly restricted
<cjwatson> It'll take about two minutes
<micahg> cjwatson: I suppose I have a few minutes if it's doesn't require me to be too awake :)
<cjwatson> micahg: Thanks.  Grab http://paste.ubuntu.com/1050621/, run it as './change-override -l qastaging -p extra -y fonts-droid' - it should fail, and I'd like to see the output
<cjwatson> (Saves me having to set up an appropriately unprivileged account on qastaging ...)
<cjwatson> It'll want LP auth
<cjwatson> (But on qas not prod)
<micahg> cjwatson: it seems to be letting me do it
<micahg> cjwatson: do you want a pastebin of the output?
<cjwatson> micahg: Yes please
<micahg> cjwatson: http://paste.ubuntu.com/1050632/
<cjwatson> micahg: Damnit.  Glad I asked.  Thanks.
<micahg> np
 * cjwatson goes over the permissions again
<cjwatson> Oh, wait, you're in ubuntu-security
<cjwatson> That explains it
<tumbleweed> you want someone who isn't?
<cjwatson> Magic launchpad.Append on IArchive strikes again
<cjwatson> Yeah, please
<cjwatson> (So this slightly broadens ubuntu-security's abilities, but only temporarily since that hack will be going away soonish)
<micahg> ubuntu-security can override archive permissions?
<cjwatson> It's a consequence of your crazy syncSource hack
<micahg> ah, ok
 * micahg stopped using that anyways :)
<cjwatson> Well, you don't have a replacement that works
<cjwatson> Yet
<cjwatson> So, heh, this means that technically you guys can currently remove packages as well
<cjwatson> Best not to rely on that though
<cjwatson> tumbleweed: './change-override -l qastaging -p extra -y ttf-droid' please?
<cjwatson> micahg: So, uh, what *are* you using to unembargo from private PPAs right now then?
<tumbleweed> cjwatson: http://paste.ubuntu.com/1050639/
<micahg> cjwatson: oh, I don't use the private PPA :)
<cjwatson> Ah
<cjwatson> tumbleweed: Great, that's as expected - thanks
<tumbleweed> np
<ogasawara> could I get the linux-3.5.0-1.1 and linux-meta-3.5.0.1.1 packages accepted and copied from quantal-proposed to the release pocket?
<ogasawara> infinity: when you have a moment, could I get the linux-3.5.0-1.1 and linux-meta-3.5.0.1.1 packages accepted and copied from quantal-proposed to the release pocket?
<infinity> ogasawara: Will get to it in a bit, yeah.
<balloons> are we going to get a daily build on the iso's today?
<stgraber> balloons: we did but I believe the all failed. Let me have a quick look at the reason and I can trigger a rebuild of at least Ubuntu if that's fixed
<stgraber> apparently only a subset of the live images are affected
 * stgraber tries a rebuild of ubuntu desktop
<infinity> stgraber: I assume it was evolution* fallout?
<stgraber> infinity: yeah
<stgraber> balloons: so apparently ubuntu desktop (all architectures) and edubuntu failed to build. I'm rebuilding ubuntu desktop now, will then rebuild wubi and edubuntu. Do you also need the arm images (these are pretty long to build but I can start them in the background and forget about them ;))?
<balloons> hehe.. i don' t have plans for arm, but sure
<stgraber> balloons: apparently evolution is still broken, so I'll wait before triggering any more rebuild
<balloons> ouch
<stgraber> infinity: "evolution-data-server : Breaks: libebook-1.2-12 (< 3.4) but 3.2.3-0ubuntu7 is to be installed" <-- working on this one?
<infinity> jbicha_: ^
<balloons> stgraber, probably should use notice board for such things?
<infinity> stgraber: I'll look in a sec.
<jbicha_> micahg: were you going to work on thunderbird today? bug 1015723
<ubot2> Launchpad bug 1015723 in thunderbird "thunderbird-gnome-support is uninstallable (depends on NBS evolution library)" [Undecided,New] https://launchpad.net/bugs/1015723
<balloons> saying daily's are being delayed
<stgraber> balloons: I suppose we could, though the fact that the dailies weren't posted is usually a good indication of that. They're usually triggered by cron, so if they aren't there, something failed.
<balloons> do you get any messages about when they fail, etc?
<balloons> stgraber, yes but folks have been asking me about when they would appear, etc
<balloons> seeing as I've asked them to test this week...
<stgraber> balloons: I do for Edubuntu but I don't for the others, I guess I should just add myself to the e-mail notifications for all the builds...
<balloons> you can add me also if you wish
<balloons> so I don't have to ping you constantly
 * highvoltage was actually going to test edubuntu today, so whenever there's a build feel free to poke me
<stgraber> highvoltage: I also added you to the notifications of edubuntu
<stgraber> *for
<highvoltage> ok thanks
<balloons> so stgraber I mean, it seems like a good idea to mention on the notice board when builds fail to build
<balloons> is that something the cron job could do automagically?
<stgraber> balloons: not without quite a bit of work as nusakan doesn't have a single place containing the state of all images and we don't have an API to update the notice board
<balloons> I figured as much
<stgraber> balloons: so we'd need some magic that'd write the state for every product we build (livefs and cd build) then something that publishes that to the notice board
<stgraber> that's doable but I don't quite have the time to put in that at this point
<balloons> yes, sure... I mean for now just knowing something is broken.. It can be manual
<balloons> I'll post something on the board
<xnox> stgraber: can't the success/fail emails be emailed to jenkins as a passive notification pass/fail/no-info
<xnox> passive test-result, if there is such capability
<xnox> stgraber: forwarding all of those to an automated / public mailing list would be great
<xnox> email notifications that is
 * stgraber stores his answer for when xnox is back...
<jbicha_> balloons: where is the notice board you were talking about?
<balloons> http://iso.qa.ubuntu.com/
<balloons> top of the page
<infinity> chrisccoulson: Is there a new thunderbird upload happening today?
<chrisccoulson> infinity, yes, quite possibly
<infinity> chrisccoulson: The thunderbird/evolution skew is causing a sad.
<stgraber> chrisccoulson: new thunderbird! thanks
<infinity> chrisccoulson: Doing thunderbird-couchdb as well?
<infinity> chrisccoulson: (It has a libedataserver-1.2-15 dep hardcoded in debian/control)
<chrisccoulson> infinity, jbicha_ already did that. although, it needs more than the dependency in debian/control changing
<chrisccoulson> we should just remove that from the archive ;)
<infinity> Oh, I have an out-of-date source here.
<infinity> chrisccoulson: Removing it from the archive doesn't seem ideal.  It looks like it actually does something useful...
 * stgraber waits for thunderbird to publish then start some rebuilds and an Edubuntu armhf test build
<highvoltage> yay
<stgraber> it's very very unlikely to succeed but trying it is the easiest way to check what's missing ;)
<infinity> stgraber: You might need to wait for it to build first. :P
<highvoltage> surely building is implied with publishing?
<highvoltage> (well, completion of it :p)
<infinity> You'd think. ;)
<stgraber> infinity: I assumed you'd already done the build score bumping if it was needed ;)
<infinity> stgraber: Also, wait, edubuntu armhf?
<stgraber> infinity: yeah, we are planning on releasing 12.10 for the zapad (similar to kubuntu), though we kind of lack hardware and a kernel at the moment, so I'm planning a one off daily-preinstalled omap4 build so we can see how much of it explodes
<infinity> stgraber: Oh dear.  Kay.  That'll be interesting, since we're dropping preinstalled images from Ubuntu.  You may be the only remaining consumer of that codepath when we do.
<stgraber> infinity: no, we don't want to go with preinstalled for release, I'm just going to build a preinstalled image today as it's the easiest thing to build until ogra_ lands the live image change
<infinity> stgraber: Well, I'm not sure how you'd install a tablet with a live image.
<infinity> stgraber: Unless it has internal storage and a way to use external boot media, I guess.
<highvoltage> the zatab has that, at least
<highvoltage> (reportedly :p)
<stgraber> infinity: well, it's a tablet with 16gb of internal storage and it's not locked or anything (made by zareason with their developer present on IRC)
<infinity> I guess we'll see how it all turns out.
<stgraber> kind of waiting on hardware to know how much of an headache that'll be :)
<highvoltage> infinity: indeed, time will tell, but it seems like a good first device to try to get edubuntu on as a tablet: http://zareason.com/shop/zatab.html
<tumbleweed> ajmtch has one...
<highvoltage> yeah but he still runs android :)
<stgraber> tumbleweed: we have 5 of them somewhere between zareason and sherbrooke at the moment, so shouldn't be long before we can see how much work will be needed to get something releasable
<highvoltage> (at least he's willing to test kubuntu/edubuntu images when they exist)
<tumbleweed> stgraber: ah, nice. I tried to get my hands on one before leaving SF but it didn't happen
<stgraber> chrisccoulson: looks like at least powerpc will remain broken for a while...
<herton> hi, can someone accept for precise-proposed linux-meta-ti-omap4 - 3.2.0.1415.15 and linux-ti-omap4 - 3.2.0-1415.20 in precise queue?
<infinity> herton: Can do.
<herton> infinity, thanks
<stgraber> balloons: looks like you won't be getting a daily today, thunderbird just failed to build on i386
<stgraber> chrisccoulson: ^ (but I guess you noticed already)
<slangasek> stgraber: a daily being a daily quantal image?
<stgraber> slangasek: right, today's dailies failed because of evolution requiring a bunch of rebuilds, including thunderbird (last one that needs building I believe)
<Laney> it looks like he already uploaded again actually
<slangasek> so it sounds like this is a transition that should have happened in quantal-proposed, no?
<stgraber> slangasek: yeah, not sure why it didn't
<slangasek> probably because whoever started it is not accustomed to thinking in terms of -proposed for library transitions yet :)  what upload tripped it off?  maybe it's worth a friendly reminder to the uploader
<stgraber> Laney: oh, wasn't there when I last checked ;) so we might have the archive fixed in ~2hours then (for amd64 + i386 at least)
<stgraber> slangasek: it was a sync of evolution-data-server, looking at who requested it now
<stgraber> slangasek: that'd be jbicha
<slangasek> stgraber: ah, and he's conveniently disconnected from irc ;)
<slangasek> gema: hi, can you tell me about this work item I seem to have picked up on https://blueprints.launchpad.net/ubuntu/+spec/qa-q-add-test-coverage ?  I know I wasn't in that session at UDS :)
<jbicha> hi, sorry about the excitement today
<jbicha> I believe eds would have autosynced today anyway
#ubuntu-release 2012-06-21
<ScottK> We're doing all library transitions in -proposed now?
<infinity> ScottK: The archive certainly doesn't seem to be aware of this.
<infinity> ScottK: But yeah, especially for seeded packages, transitioning in proposed sure ends up a nicer experience for users and testers.
<infinity> ScottK: I'm looking into britney automagic migration stuff this week and next.  With any luck, we can just switch to proposed for all uploads and be done with it.
<ScottK> Just call it unstable.
<ScottK> Then alias the release pocket to testing.
 * xnox doesn't want people to accidently upload to wrong distro though if pockets match names in debian & ubuntu
<infinity> ScottK: Yeah, not gonna happen. :P
<infinity> ScottK: Also, it's instant migration, so not quite the same deal.
<ScottK> The window is narrower, but you can still have interlocked transitions due to archive skew.
<infinity> Well, yes.
<infinity> But given that we also don't have a strict concept of package ownership, the answer to that problem is "fix it, then".
<ScottK> I will be surprised though if eventually someone doesn't say, "You know, we really ought to test these packages before they migrate".
<infinity> Much as it currently is when our release pocket sucks.
<infinity> When autopkgtest stuff gets more coverage, I wouldn't be at all unhappy with slowing the migration down a bit to force testing.
<infinity> But we'll see.
<ScottK> True, but 'instant' can suddenly get a lot longer when your little library transition has to wait for a Qt build to finish on armel.
<infinity> That will be an entirely different debate on velocity versus quality, etc.
<infinity> ScottK: Yes, but we want things in sync on arches.
<ScottK> Yes we do.
<infinity> ScottK: (And much like Debian, we may blacklist non-supported arches)
<infinity> ScottK: Though, I don't intend to do that except as a last resort (like the current armel/mono breakage)
<ScottK> Speaking of non-supported  architectures ...
<ScottK> Would you have a moment to look at clamav in lucid-backports.
<ScottK> It FTBFS from a test failure I've seen once on other archs, but is 100% after about 5 tries on ppc.
<ScottK> (on lucid - fine on other releases)
<infinity> I was going to suggest trying a different kernel, but that was on a precise kernel even.
<infinity> And I assume previous failures weren't all on ross?
<ScottK> I didn't think to check.
<ScottK> infinity: Can you retry it again and make sure it hits !ross?
<infinity> ScottK: Done.
<ScottK> Thanks.  I guess we wait now.
<infinity> ScottK: Not sure if it relates, but while it's compiling testsuites, there's a char->uint conversion warning thrown by the compiler.
<infinity> Actually, there are a fair few of those...
<infinity> Though, I can't see how that would make it fail on only one release.
<RAOF> infinity: I'll let robert_ancell ask what needs AA attention.
<infinity> robert_ancell: Answer fast, I have a midnight date with a patio and a cold beer.
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html - new change-override tool
<gema> slangasek: you volunteered, I don't think it is so much for you to do it, but for you to help us find who should be doing it, or pointing us to the test cases, or get started somehow
<xnox> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html is in Pub Time mode =)
<cjwatson> And so it should be! :-)
 * cjwatson fires his LP branch to remove change-override.py off to EC2
 * xnox 'cjwatson and LP Archive Admin days with your favourite Core Dev characters available now in the software centre as part of the Humble Indie Bundle in the Ubuntu Software centre"
 * xnox 'cjwatson and the LP Archive Admin days with your favourite Core Dev characters available now as a part of the Humble Indie Bundle in the Ubuntu Software Centre"
<cjwatson> odd chap
 * xnox tries to be funny and fails at spelling and grammar
<cjwatson> Now, I wonder what to do with security-kernel-overrides.  It's kind of broken anyway due to something funky with indices, but maybe I should fix that anyway ...
<cjwatson> Or maybe it's time to fix LP so that binaries default to the same component as their source
<micahg> cjwatson: +1, that would solve my remaining override issues :)
<cjwatson> (Bug 192076)
<ubot2> Launchpad bug 192076 in launchpad "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/192076
<infinity> cjwatson: That's a wonderfully old bug.
<infinity> cjwatson: Would love it fixed.
<infinity> cjwatson: Though, security-kernel-overrides still had a place for hardy kernels, where some bits are in universe.
<infinity> (Not that I ever use the script, I don't trust it, I just eyeball madison output and make it match)
<infinity> cjwatson: Of course, if it was fixed to actually look at listed components and DTRT, I think the hardy kernel would probably Just Work.
<infinity> (And if not, we could fit it to do so)
<cjwatson> security-kernel-overrides just plain didn't work last I checked, because the written-out overrides in indices were horribly incomplete.
<cjwatson> I probably ought to investigate that
<jibel> can you respin ubuntu desktop ? ubiquity on the image is 2.11.5 but 2.11.6 in the squashfs
<jibel> it breaks oem-config
<cjwatson> That's freaky.  .list should always be >= .manifest, if anything.
<cjwatson> Oh, it was built in parallel with something else apparently so it didn't sync the mirror.
<cjwatson> I wonder what.
<cjwatson> jibel: I'm investigating this rather than blindly respinning.
<jibel> cjwatson, ok, thank you
<cjwatson> There was a semaphore set that should have been clear.
<cjwatson> So it always thought it was doing a parallel build even though it wasn't.
<cjwatson> Apparently this situation has persisted since an Ubuntu daily-live build was killed on 20120606.
<cjwatson> It must have been killed extremely unceremoniously; normally build-image-set cleans up the semaphore on exit.
<cjwatson> I've cleaned this up and kicked off another build.  However this time it actually *was* in parallel with a server build, which suffered from the same problem, so I'll wait for that to finish and then try yet again.
<cjwatson> I'm surprised that nobody noticed that all the server packages date from 2012-06-06.
<infinity> cjwatson: More evidence that no one tests between milestones? :P
<infinity> cjwatson: (Since the Alpha-1 server build was pretty much on that date)
<infinity> cjwatson: Regarding the new change-override.  Remember how the LP script gave a visual clue what it was overriding?  That was actually kinda helpful.
<cjwatson> infinity: Example?
<infinity> cjwatson: Yours says "universe/utils/optional -> main", I'd expect "UNIVERSE/utils/optional -> MAIN"
<infinity> It upper-cased the chunk of the override stanza that was being overridden.
<cjwatson> No it didn't.
<infinity> Did too.
<cjwatson> It upper-cased the priority.
<cjwatson> Unconditionally.
<cjwatson> 2012-06-14 18:22:46 INFO    Override Component to: 'universe'
<cjwatson> 2012-06-14 18:22:46 INFO    'libboost-graph1.46-dev-1.46.1-7ubuntu3/main/libdevel/OPTIONAL' binary overridden in quantal/amd64
<cjwatson> And I have history to prove it.
<infinity> Huh.  I swear I've seen it do the other thing.
 * infinity scratches his head.
<cjwatson> And that was just a side-effect of priorities being DB enumerated types.
<cjwatson> I lower-cased it because that always annoyed me. :-)
<cjwatson> If you want to upper-case as a hint, that sounds cool, it's just not because change-override.py always did it. :-)
<infinity> Maybe I only noticed it when I was doing priorities...
<cjwatson> But maybe only upper-case on the LHS.
<infinity> I do now wonder how my brain saw that differently all these years.
<infinity> Maybe I need a new one.
<knome> can i have the old one?
<infinity> I thought I might keep in a jar and figure out how to talk to myself.
<knome> bah. still no brain-eating :(
<knome> oops
<knome> :)
<cjwatson> jibel: Should be happier now.
<ScottK> infinity: Thanks.
<ogra_> stgraber, looking yt your edubuntu omap buildlog you need some tweaks to tell livecd-rootfs to use universe i think
<ogra_> *at
<stgraber> ogra_: ah? the build failure I got looked fine, epoptes depends on a package that never built on armhf...
<ogra_> stgraber, oh, i thought it was a package in universe :)
<ogra_> yeah, if it didnt build thats an "okayish" error indeed
<stgraber> well, it also happens to be in universe but so was epoptes, so that part seems to work :)
<stgraber> I thought alkis fixed that issue by making epoptes conditionally depend on ssvnc which is also supported and built on armhf but apparently not
<ogra_> trivial fix then
<ogra_> unless you can convince him to fix xvnc4viewer on arm ;)
<stgraber> hehe, I actually tried that then when I saw the packaging of that thing I gave up and started writting my own vnc client ;)
<stgraber> xvnc4viewer's source is basically an old version of the vnc source + a copy of an old version of the X server + a bunch of patches
<ogra_> yeah, i know ... iirc doko was the last person looking at it for arm and gave up ... but that was like 2-3years ago :)
<stgraber> well, I guess nothing changed, it still looked like a terrible mess when I looked at it a couple of months ago ;)
<ogra_> yeah
<stgraber> IIRC the actual source of the FTBFS is in the X code, not in the vnc code, so we'd need to find the fix in the upstream X code and backport it to whatever old version is bundled in vnc4...
<ogra_> well ... could ... yes ... indeed ...
<stgraber> but for now I'm mostly of the opinion of just letting that package die ;) and trying to get as far away of it as possible for Edubuntu.
<ogra_> hehe, yeah, thats surely the better move ...
<slangasek> gema: ok - I'm going to point you at stgraber then
<stgraber> slangasek: context? :)
<slangasek> stgraber: work item to provide test cases for ipv6
<stgraber> slangasek: ok
<Laney> I should fix my procmail rules to do deduplication... this thread being cross-posted to -devel and -release is getting annoying
<stgraber> Laney: deduplication? you're actually getting duplicates? in my case it looks like mailman is being clever and doesn't send me duplicates, but I end up having 50% of the thread on one list and 50% on the other :)
<Laney> yeah I get allo f them on both
<cjwatson> stgraber: Exactly why I hate deduplication
<Laney> that could get annoying, yeah. Would have to be made deterministic somehow.
<stgraber> it'd be fine if the To field would always be in the same order as the first match will move the e-mail, but apparently it's quite random, making them get into both folders...
<stgraber> I guess I could write a script that sorts the To field, then uses that for filtering :)
<ogra_> cdimage@nusakan:~$ ARCHES=armel+omap4 buildlive ubuntu daily-live &&  ARCHES=armel+omap4 for-project ubuntu cron.daily-live
<ogra_> ubuntu-armel-omap4 on annonaceae.buildd starting at 2012-06-21 15:28:58
<ogra_> ssh: connect to host annonaceae.buildd port 22: No route to host
<ogra_> heh
<ogra_> nice way to tell me: "screw you we dont build armel images anymore, fix y<our finger memory, damned !!!"
<stgraber> ogra_: shouldn't that be celbalrai.buildd ?
<ogra_> stgraber, well, for arm*el* it should be nothing :)
<stgraber> ogra_: heh, right :)
<ogra_> my fingers just didnt leanr that yet
<ogra_> *learn
<stgraber> ogra_: I'll be ready to kick another edubuntu test build after the publisher finishes its job, will check that you aren't already running a build before triggering it :)
<ogra_> oh, i can run armhf+omap instaed
<ogra_> no problem
<stgraber> ogra_: that'd be great, hopefully my default-arches config works now and it'll indeed only build for omap4 :)
<ogra_> running armhf+omap --- but i'm not sure infinity is done with switching his load balancing stuff back on again
<ogra_> so i might or might not block you atm, seems my build also starts on celbalrai
<stgraber> well, I'd usually have both omap and omap4 running on celbalrai at the same time, so I assumed it's fine as long as it's not the exact same "arch" building twice
<ogra_> the buildds block while they build for one arch
<ogra_> and a build usually takes 90min
<stgraber> ok, that explains why it looks like they're both starting building at the same time, but the second one takes double the time
<stgraber> ogra_: looks like your build just finished (well, failed), so I'm starting an Edubuntu build now
<ogra_> yep, i got what i want (logs)
<ogra_> my live build finished properly though :)
<ogra_> gah, where did we hardcode ext4 ... i thought we had bound that to preinstalled
<ogra_> hmm, obviously not in buildlive
<ogra_> stgraber, looks like you are done ?
<ogra_> stgraber, i'm firing off another attempt and will leave for the evening afterwards
<ogra_> (so celbalrai is free for you afterwards if you want to do more testbuilds)
<stgraber> ogra_: yep, my build worked (only did livefs)
<Laney> NCommander: moar snipping please :-)
<NCommander> Laney: I think we have a proposal that works all
<Laney> well, if you reply again I'd rather not have to page down for 15 minutes :P
<stgraber> NCommander: your proposal basically means that freezes will work as they do currently :)
<stgraber> NCommander: as Edubuntu won't be able to move to the new milestone-less stuff and edubuntu is a superset of Ubuntu (and we're introducing a server version this cycle)
<NCommander> stgraber: whch is what Kubuntu wants. Ubuntu doesn't wish to be part of those freezes so we can simply remove them
<stgraber> so that'd mean that all packages in Ubuntu would still have to be frozen as Edubuntu will still need the freeze
<NCommander> stgraber: please respond to Robbie's email then
<Laney> I'm not sure I've seen much support from the RT for the idea of dropping freezes anyway
<stgraber> yeah, I mentioned it very early in the thread but my point of view is that we're already doing signifcant improvements to the way the archive works this cycle and that I'd really prefer we don't mess with our release process on top of that :)
<stgraber> we can always discuss doing that kind of change at next UDS after we've had a cycle (or part of anyway) of using -proposed and extended automated testing
<stgraber> NCommander: I'll respond to Robbie with Edubuntu's view once I confirmed that my view matches that of the rest of the Edubuntu release team (that being highvoltage)
<NCommander> stgraber: excellent
<Laney> I think that for this cycle we should just have the community team do their additional milestones when we're not doing official ones.
<Laney> Then we'll have some data at UDS as to how it goes, without having to potentially mess stuff up.
<stgraber> yep, I certainly have no problem whatsoever with more people testing the dailies and that'd let us easily review things at next UDS
<Laney> like "was the archive working enough to let this happen?" "were the results useful?"
<NCommander> Laney: I recommend you post in the thread
<Laney> it seems too big to be productive already
<Laney> I'd rather discuss it at the meeting and see if we can come to a position as the release team
<stgraber> +1
<Laney> skaet: can/should we put it on the agenda?
<seb128> NCommander, btw next time can you refrain to create issues for anyone and crosspost when not needed?
<highvoltage> stgraber: I'm kind of annoyed at Jono's post and I'm tempted to reply
<highvoltage> stgraber: but I don't want to delute any official message you'll be sending on the topic
<stgraber> highvoltage: I think the beginning of my message may also apply to your concern.
<highvoltage> stgraber: just started to read your message, your first paragraph is almost exactly what I was already typing :)
<stgraber> highvoltage: hehe, I remember we discussed it with skaet at UDS and said we need to fix our documentation and "people" to stop saying derivatives when they mean flavours
<highvoltage> stgraber: just finished reading it. perfect. not sure I would've been so nice so I'm glad you sent it.
<stgraber> :)
 * skaet has a workitem to talk to the webops about cleaning up derivatives...
<skaet> Laney,  if you want to bring it up as a topic for discussion tomorrow, fine.   Maybe start a new thread on ubuntu-release first,  so folks who haven't been following the ubuntu-devel thread in all its glory can understand the issue?
<Laney> Really? :(
<highvoltage> stgraber: I still want to reply to jono's mail
<Laney> I don't want to risk starting another discussion / fragmenting the existing one
<infinity> Laney: Does it need discussing as an actionable item, really?  While I (unlike many) am on the "hey, we should probably drop milestones" side of the fence, I don't think we should JFDI and see what explodes.
<highvoltage> I think I'll send it to him as a private mail.
 * ScottK looks up.
<infinity> Laney: The only sane way forward is to increase testing, change the culture, and make milestones irrelevant.  And if that works, then drop them.
<infinity> Laney: I suspect it'll take two sentences and about 30 seconds to get concensus that we can't even consider B without first doing A.
<Laney> I'm just asking for a conversation within the release team.
<Laney> then we can give our position to those pushing for whatever change is being considered now.
<ScottK> infinity: Depends on how many managers are in the room.
<Laney> if it's 30 seconds, all the better.
<infinity> ScottK: I'm happy to phone a few up and get them to agree to the above position statement too. :P
<infinity> Laney: This means I need to actually attend the release meeting, doesn't it?  Since I'm one of the few RMs that seems to hold a strong opposing view here.
<infinity> Laney: (Well, an opposing view with a cautious approach, though)
<skaet> Laney,  I'm fine with it just being a conversation then.   Was just worried that some weren't following ubuntu-devel thread
<Laney> It would certainly be nice if all interested were there
<Laney> maybe we could just draft some thing on the pad though
<skaet> Laney,  lets see who's there tomorrow,  and if its quorum talk about it.   If not,  I'll set up something else next week for us to get together with the release team and talk about it.
<stgraber> infinity: FWIW I'm not saying we should keep milestones forever, but I'm clearly of the opinion that doing a change of this magnitued in the middle of a release cycle is a bad idea and that any change shuld be done incrementally, in the right order and evaluated after each step.
<Laney> skaet: ok then
<highvoltage> +1 to that
<stgraber> infinity: but the current proposal sounded a lot like JFDI to me and I'm clearly opposed to that
<infinity> stgraber: The original proposal didn't even talk about dropping milestones, just relaxing/dropping freezes (which we kinda already did for A1)
<infinity> stgraber: It morphed into dropping milestones (which, yes, there's been a lot of discussion about), but no one thinks we can JFDI without making sure it's sane.
<infinity> stgraber: Anyhow.   I'll show to the meeting tomorrow and give my 2c.
<ScottK> infinity: I think the conclusion was that you can't really drop freezes and keep the milestones.
<ScottK> So you have to pick one.
<infinity> ScottK: That depends on how you define milestones.
<infinity> ScottK: If it's just a rallying point where people decide to test harder, target features, etc, you don't need a freeze.
<infinity> ScottK: If it's to produce a release-quality image, you do need a freeze, but if that's the point, we always fail anyway.
<ScottK> Even for Alpha 1 (where there was no attempt to produce release quality images) we still freeze and need it.
<infinity> ScottK: Hence why I included the anonymous "well, all the bugs we know about are kinda crap, but they'll be fixed in tomorrow's daily anyway" quote in the thread.
<infinity> ScottK: We don't even pretend milestones are release-quality, so why put all the effort into trying to make them so?
<ScottK> I think a graduated set of goals would make sense.
<ScottK> Informally we generally consider Alpha 1 a win if you can install something and it boots.
<ScottK> We could lay out the release criteria for each milestone so that we aren't over-engineering early on.
<ScottK> For Beta 2, I think we should be aiming for release quality images (at least for all the installer components).
<ScottK> That would shorten the needed freezes without switching entirely away from our existing system.
<infinity> We certainly want to achieve higher quality as we go, yes.
<infinity> Though, one of the goals of PlusOne is to keep quality as high as we can.
<infinity> Which was why I suggested a cultural shift to PlusOneQA to go with PlusOneMaint.  ie: stop pretending only milestones matter, essentially.
<ScottK> Yes, but I think it's be useful to have a defined point to say "It's good enough, move on" for the early ones.
<infinity> It does make the whole machine operate much more smoothly if "everything sucks for 3 weeks and then we freeze to test and fix it" isn't the status quo.
<ScottK> Agreed.
<ScottK> I think a general shift towards the idea that things should generally not be crap is very good.
<infinity> Aaanyhow.  I haz to work.  But I'll come to the release meeting tomorrow and be the voice of insanity to balance against everyone's reason. ;)
<skaet> ScottK,  agreed,  we've been informally turning up the quality as we go along,  gettting the expectations for what happens at alphas/betas written down, was something I was thinking was overdue
<NCommander> seb128: (sorry, was on the phone). would you please ellibrate to what issues? (as for cross-posting, given the topic involved release tasks, it was just as revelant on u-release as it is on u-devel)
<seb128> NCommander, I would assume that the release team members care enough about Ubuntu to be subscribed to -devel and I saw at least 5 people today complain about your crossposting making it hard to follow the discussion
<seb128> NCommander, like you didn't add any value by crossposting but you make job harder for list admin, people commenting and people following
<seb128> NCommander, several people replied on one of the two list only as well splitting the discussion thanks to you
<NCommander> seb128: ah, I shall stop
<NCommander> I apologize for the headache I caused
<seb128> nw, but crossposting just sucks
<NCommander> nw?
<seb128> no worry
<seb128> sorry ;-)
<NCommander> seb128: guess I'm used to mutt handling it sanely
<seb128> what's sanely?
 * NCommander crawls under the bed in fear of the listadmins
<NCommander> If the message id matches, it shows it once, with two From: lines
<seb128> the people who commented there today said they have half of the discussion landing on their -devel folder and the other half on -release
<NCommander> (though that might have been some procmail/muttrc magic I did)
<ScottK> I have them going to the same folder, so it was just hitting the delete key.
 * NCommander decides to don a fake beard, get a Mexican Passport, and flees before the listadmins come to rm me out of existance
<Laney> hey, LP's Debian import really /did/ get faster :-)
<Laney> Date: Thu, 21 Jun 2012 13:52:05 +0000 Subject: zeitgeist-sharp_0.8.0.0-3_amd64.changes ACCEPTED into unstable
<Laney> syncpackage: Source zeitgeist-sharp -> quantal/Release: current version 0.8.0.0-2, new version 0.8.0.0-3
<infinity> Oh?  Does this mean I can sync my uploads?
 * infinity looks.
<infinity> Evidently not.
<infinity> Laney: Thanks for the false hope.
#ubuntu-release 2012-06-22
<micahg> infinity: when you can a chance, can you release thunderbird, lightning-extension, and enigmail?
<cjwatson> stgraber et al: I've changed the precise daily image builds to use -proposed, to make it possible to verify installer/cdimage-type changes
<cjwatson> been meaning to do that for a while
<quadrispro> bdmurray,
<quadrispro> libmtp's been reuploaded to precise-proposed
<ogra_> nice, the arm live images work astonishingly well
<xnox> ogra_: did manage to boot, while you were having lunch? =))))))
<ogra_> heh, kind of, it boots into the installer and does the install ... though the copying process takes ages ... i'm massively spoiled by preinstalled images
 * ogra_ is curious if the bootloader bit will work
<xnox> I was planning migrating my laptop to UEFI boot, but I'm not sure weather to reinstall or migrate the installation from the backup
<ogra_> hmm, the partitioner isnt able to read the MBR of my USB disk, weird
<ogra_> bah, and indeed it chrashed at the bootloader install stage
<tumbleweed> infinity: I (and my IRC logs) can't remember. Did we increase the build timeouts for pypy? 1.9 has been building very happily in Ubuntu but timing out everywhere in Debian (and in quite a few of my PPA builds on Ubuntu)
<stgraber> cjwatson: thanks, that'll be quite useful
<stgraber> ogra_: yep, thanks for that work! I built an Edubuntu omap4 live image yesterday afternoon and it worked great (haven't tried installing though, just been checking the live environment)
<infinity> tumbleweed: I don't think we did any sbuild timeout magic.  And even if we had, PPAs use the same configs.
 * tumbleweed wonders why on earth it isn't timing out, then
<tumbleweed> compare https://buildd.debian.org/status/package.php?p=pypy&suite=experimental with https://launchpad.net/ubuntu/+source/pypy/1.9+dfsg-1
<infinity> tumbleweed: Our timeouts might be slightly less agressive, I don't recall off the top of my head.
<infinity> tumbleweed: Our systems might also suck less.
<tumbleweed> heh
<tumbleweed> infinity: if you wouldn't mind increasing the timeouts for the benefit of PPA builds, I'd appreciate it. And it looks like I need to request this in Debian too
<Laney> skaet: So are we going to send a "response from the release team" to this discussion?
<ogra_> infinity, would you mind doing the changes to /etc/default-arches ? i know i will break it again if i touch it ...
<Laney> That's what I was after from it :P
<infinity> ogra_: You do seem to be good at breaking it.
<ogra_> infinity, omap, omap4 and mx5 desktop need to be added to the normal live ... ac100 needs to stay preinstalled from quantal on
<ogra_> no crontab changes needed i think
<infinity> ogra_: Can do.  This is going to annoy the heck out of people doing live builds. ;)
<ogra_> oh, indeed, they now take longer
<infinity> Oh, how I can't wait for more ARM hardware.
<infinity> ogra_: A lot longer.  Times 3.
<ogra_> we should probaly move back to ARCHES in crontab for that
<ogra_> to keep this build separate
<infinity> crontab isn't the issue, it's manual builds.
<skaet> Laney,  rather than add to the mess that that thread is,  I'll start off a new one on the goals, and see if we can get some planning structure in place to pull in the input from all the stakeholders in an effective manner.
<ogra_> and not make the change in default-arches
<infinity> No one cares (or, they shouldn't) how long the cron entry takes.
<ogra_> it will also be the manual build you run on nusakan
<ogra_> (during milestones when doing rebuilds)
<Laney> skaet: OK. I think it's important to emphasis that the RT doesn't want to change anything for Q but that we are cautiously supportive of the goals.
<skaet> Laney,  agreed.
 * Laney looks at the wind/rain and thinks twice about cycling home
<stgraber> ogra_: we should probably also check that the cronjob timing will still be good after that change.
 * skaet looks at the outside thermometer and wishes for wind and rain....   summer is now in Austin.
<ogra_> stgraber, thats why i think using ARCHES for this might be better
<infinity> stgraber: It won't be.
<cjwatson> I hate to say this, but I'll revert changes that put ARCHES in crontab
<infinity> Really, I need the army of new Pandas I was promised to materialise.
<cjwatson> I put a lot of work into getting rid of that
<ogra_> cjwatson, hmm, but do you really want a live build to take hours ?
<cjwatson> I don't especially care
<cjwatson> At least not for cronned builds
<infinity> ogra_: Like I said, I don't care for cron jobs.  And no one should.
<ogra_> no, but for manual ones
<cjwatson> Those don't follow the crontab anyway
<infinity> ogra_: It's by-hand stuff that's more annoying to people.  And that has nothing to do with crontab.
<ogra_> cjwatson, they follow default-arches
<infinity> ogra_: THey don't have to. :P
<cjwatson> Not mandatorily
<ogra_> and are only as fast as the slowest build
<infinity> ogra_: And they haven't always.
<ogra_> yes, i know they havent always
<cjwatson> The pad-based "big sequence of stuff to build" often has manual ARCHES overrides.
<ogra_> ok
<cjwatson> That much is fine.  It's just not OK in the crontab.
<ogra_> if the pad is enough to handle it thats fine
<cjwatson> (Well, not fine, but tolerable.)
<infinity> Well, the pad is meant to turn into something better.
<cjwatson> Yes.
<infinity> It's on my list of stuff and things.
<ogra_> i just dont want the wrath of all team on me just because the build suddenly goes 4h longer since i added arm to the build
<ogra_> *teams
<cjwatson> The correct answer (at least based on the current world order) is to have enough extra builders to have the new cron builds parallelised.
<infinity> cjwatson: Yes, and I was promised a MandaBox in the DC to solve this issue.
<infinity> cjwatson: I need to chase that up.  I bet it's there and collecting dust.
<ogra_> a month ago, wasnt it ?
 * skaet --> lunch
 * ogra_ packs his bags and wanders off to watch greece kick germanys butt ;)
<infinity> ogra_: That's some real national pride you have there.
<ogra_> heh
<infinity> ogra_: But, really, Greece is pretty much just a German province at this point.
<ogra_> well i do my duty at least ... going to the beergarden to watch the game that is :)
<infinity> ogra_: Or, they soon will be.
<infinity> ogra_: So, you're essentially kicking your own butts!
<ogra_> yeah, i'm already watching out for an island :)
<xnox> infinity: it's always fun to watch minions play
 * cjwatson has his ninth (or so) go at fixing LP copying of custom uploads
<infinity> cjwatson: Ninth time's the charm.  That's what they always say when trying to off cats.
<infinity> * Note: I do not condone the offing of cats.
<skaet> ogra_, have fun.  :)
<cjwatson> I think the nearest approximation to a right answer is that, when you copy a package containing a custom upload, LP should synthesise uploads to the target series/pocket containing only the custom files
<cjwatson> That's how it works for copying custom uploads across to new series; it's a bit weird but it works, and absent some equivalent of BinaryPackagePublishingHistory that's useful for custom files, it's about the best we can do
<infinity> cjwatson: Will that also buy us auto-rotation/expiry of custom published bits, or do we still need to mangle that by hand?
<cjwatson> Should do, because it'll go through the normal custom upload publication code at that popint.
<cjwatson> *point
<infinity> \o/
<infinity> That'll be a massive win for the one AA task that no one ever remembers to perform until someone points out it's been broken for six months.
<cjwatson> Yeah.  (Though sru-release started nagging about it, which I think has helped.)
<cjwatson> But I've been trying on and off for months to make this work, so maybe best not hold your breath :-)
<cjwatson> As usual writing the tests is the incredibly difficult bit
<ScottK> infinity: Isn't that true for most of Europe now?
<infinity> ScottK: Perhaps.  It turns out that being rich was a far better strategy than wearing grey outfits and killing everyone.
<ScottK> Yes.  Absolutely.
<ScottK> From a US policy POV this is a case of be careful what you ask for, you may get it.
<infinity> cjwatson: Also, vaguely related, after watching the publisher grind for 28m last night on a single libreoffice.translation.tar.gz, I'm wondering why ftpmaster is doing that job at all.  I assume we don't hard-crash the publisher is a translation tarball import fails (I hope?), so can't we just fire and forget that at some appserver somewhere, and take it from 28m to a second or two?
<infinity> s/is a/if a/
<cjwatson> I'm not sure how that stuff works
<infinity> Me neither.  It's a black box to me.
<infinity> I think it is to almost everyone, which could explain why it's never been optimised.
<cjwatson> Let me have a look at the logs and see if I can hazard a guess
<cjwatson> 2012-06-22 01:03:16 DEBUG   Publishing custom libreoffice, libreoffice_3.5.4-0ubuntu1_amd64_translations.tar.gz to ubuntu/precise
<cjwatson> 2012-06-22 01:29:02 DEBUG   Successfully processed queue item 4298271
<cjwatson> That bit, I take it
<infinity> cjwatson: That bit, yeah.
<infinity> cjwatson: THe 28m is a bit unfair, as it was fighting for I/O with bug 1013583, but even if that weren't the case, it would be maybe 14m, which seems crazy.
<ubot2> Launchpad bug 1013583 in apt "contents-generation could be 2x faster by not regenerating Packages/Sources" [Medium,New] https://launchpad.net/bugs/1013583
<infinity> cjwatson: And a minute or two for smaller translation tarballs.
<cjwatson> Hm, right
<cjwatson> So this is PackageUploadCustom.publishRosettaTranslations
<cjwatson> Which calls SPR.attachTranslationFiles
<cjwatson> Which indeed is dealing with inserting files into the translation queue
<cjwatson> I think in the modern world it should be creating a job for that
<infinity> Seems out of scope for the publisher to do, yeah.
<infinity> Hence the fire-and-forget suggestion.
<infinity> You know, when you finally admit you're a Launchpad developer and so this stuff full time.
 * infinity ducks.
<cjwatson> That's a fairly standard mechanism for pushing off long-running things to script servers
<cjwatson> Never happening :-P
<infinity> s/so/do/
 * cjwatson is not StevenK
<infinity> No, you don't bring Vegemite to conferences.
<infinity> For which I'm grateful.
<cjwatson> If you want an example of stuff causing jobs to be created, look at Archive.copyPackage -> PackageCopyJob
<cjwatson> I'm a little surprised there isn't a job class for this already, actually.
<infinity> cjwatson: Oh, would you say from the lack of response on mirrors (other than the one dude who seemed to argue that they were useless but he wanted something else), that we can probably remove ls-lR.gz.  Unless you really wanted to talk to iwj about him being the only use-case. :P
<cjwatson> I dunno, I'm uncomfortable with it because I do actually know more than one user of that mirroring software :)
<infinity> You're not one of them, are you?  *suspicious look*
<cjwatson> I'd kind of prefer to pursue the "blat it out of the ftparchive cache" approach
<cjwatson> No, I use debmirror
<stgraber> ls-lR.gz is usually the file I'm using to test download speed from mirrors ;)
<infinity> Yeah, and I just use rsync.  (well, Debian's fancy rsync wrapper mirror script)
<infinity> All our "real mirrors" would never use ls-lR.gz for anything, so it's all about small home users using Ian's tool.  Surely, it can be rejiggered to not require it.
<infinity> Or just make it a debmirror wrapper. :P
<cjwatson> I dunno.  I guess I can ask.  I don't like dropping features if it's avoidable though.
<cjwatson>  lp.soyuz.scripts.tests.test_copypackage.TestDoDirectCopy.test_copy_custom_upload_files
<cjwatson>   Ran 1 tests with 0 failures and 0 errors in 4.522 seconds.
<cjwatson> Ooh
<infinity> Yay?
<infinity> And sure, if we can make a-f do it with a significant performance increase over the current coreutils implementation, that seems reasonable.
<cjwatson> I think there may be a degree of cautious yay
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/copy-custom-uploads/+merge/111653 *pant*
<cjwatson> We won't be entirely able to get rid of the manual copy process until I also fix bug 827941, but that's a really easy follow-up branch at this point.
<ubot2> Launchpad bug 827941 in launchpad "Copy ddtp-translations uploads to new distroseries" [High,Triaged] https://launchpad.net/bugs/827941
<cjwatson> (In fact, it can be done independently.)
<cjwatson> There we go, branch pushed for that too.  I'll file an MP for it later.
<xnox> I would love someone to accept autofs, this is a package rename autofs5 -> autofs, following merge from debian
<xnox> thank you!
<infinity> Did someone remove autofs5 and its binaries before that landed or something?
<infinity> Cause most of the binaries the queue thinks are NEW shouldn't be. :/
<xnox> infinity: autofs ships transitional packages with old names
<xnox> of autofs5
<xnox> which are arch all
<infinity> xnox: No, I'm looking at the queue, and almost everything it's marking as NEW isn't.
<infinity> xnox: Hence the "did someone remove the old binaries?" bit.
 * infinity shrugs and will sort it out.
<xnox> but it just got accepted!
<infinity> ...
<infinity> Binaries.
<xnox> infinity: I'm off to read about ArchiveAdministration as I don't understand launchpad's new queue administration. Nor debian's for that matter.
<xnox> Deleted 8 minutes ago by Jamie Strandboge
<xnox> renamed to autofs
<xnox> Published on 2012-04-26
<xnox> Copied from ubuntu precise in Primary Archive for Ubuntu
<xnox> infinity: ask jdstrand  =))))
<infinity> jdstrand: You made life more difficult by removing the autofs5 package.
<infinity> jdstrand: You should have waited for autofs to take over all the binaries.
<jdstrand> infinity: hrm. I was unaware of that. why?
<xnox> and wait for autofs5 to end up in the NBS....
<infinity> jdstrand: Because now all the binaries are NEW again.  So, I have to go carefully re-ovveride them all.
<infinity> jdstrand: (When, in fact, none of these binaries were new at all)
<jdstrand> infinity: well, you could leave that to me-- it is my archive day after all :)
<xnox> jdstrand: and we have no autfs in the archive now =)
<infinity> jdstrand: Okay, so you'd better carefully re-override them all to match.  Either way. :P
<jdstrand> xnox: I used -S
<jdstrand> the binaries are still there
<xnox> jdstrand: oh, ok.
<infinity> jdstrand: Not in a way that the queue knows about, evidently. :P
<jdstrand> infinity: I was responding to 'no autofs in the archive now'
<infinity> jdstrand: Heh, yeah.
<infinity> jdstrand: Anyhow.  I'll leave the overriding to you.  It's just irksome with main/universe split packages to have to re-do it when you didn't have to. :)
<jdstrand> well, I'll remember for next time
 * jdstrand has to do it the hard way
 * xnox jdstrand see sign ^^^^^^ "be prepared to apologise to the release team | we accept payment in cash, check or birdseed"
<xnox> =)
<jdstrand> I figure my apology is doing the work :)
 * xnox likes birdseeds =)
<infinity> jdstrand: Well, it was a chastisement when I was going to do the work.  With you doing the work, it's more pointing out that you could have been more efficient. ;)
<jdstrand> heh
 * cjwatson <- obviously glutton for punishment.  I'm trying to track down all the various places where LP fails to honour P-a-s ...
<jdstrand> I'll do the remaining source NEWs over the weekend
<infinity> cjwatson: The saner thing would be just phasing out P-a-s, probably.
<infinity> cjwatson: I thought I heard rumors that Debian was wanting to do away with it, now that Arch lines are significantly more expressive.
<cjwatson> They're only doing so really gradually, AFAICS.
<infinity> Fair point.
<xnox> what's P-a-s ?
<cjwatson> I'm pretty sure I can fix all three known classes of failures to handle P-a-s, and one unreported one, in about 10/20 lines, maybe plus a bit more for tests.
<infinity> xnox: Packages-arch-specific.
<cjwatson> Packages-arch-specific - a central override file allowing us to prevent some packages being attempted for build on some architectures
<xnox> ah, ok.
<infinity> It has more uses in Debian, like that wanna-build used to REALLY suck at sorting out source:binary relationships on arches that didn't build every binary a source has in debian/control, so P-a-s was used to denote arch-specific binaries.
<infinity> This allowed wanna-build to be more accurate about if a source was out-of-date and needed building.
<infinity> We don't use any of that functionality, we just use the source->arch blacklisting.
<cjwatson> Anyway, it was one of the two things I could see that would break when killing off delayed copies.
<cjwatson> (Which is a consequence/benefit of making Archive.copyPackage work for copying things out of private archives, i.e. for the security team.)
#ubuntu-release 2012-06-23
<ogra_> "For ARM hardware for which we do not ship preinstalled images, see ARM/Server/Install for detailed installation information. " ....
 * ogra_ wonders who has hacked that into the html header of *all* cdimage download pages
<ogra_> oh, bzr blame say that was skaet
<ogra_> *says
<cjwatson> Ugh, yeah, that should be more careful
<ogra_> well, its at least limited to the ubuntu project, not sure how we determine if there are any arm images in that dir so that we could make it conditional
<cjwatson> could always just keep a note in a variable somewhere
<ogra_> though i thionk flipping it from "ubuntu" to "ubuntu-server" would already suffice
 * infinity does his morning spam cleaning of the ubuntu-archive moderation queue.
#ubuntu-release 2013-06-17
<didrocks> bdmurray: daily releases are appropriate for SRUs
<didrocks> bdmurray: and that one was a manual upload btw with a fixed changelog :/
<didrocks> bdmurray: having everything stalled on the SRU side for more than 2 months now and a reject with no reason, can you please explain a little bit more than:
<didrocks> "Rejected by Brian Murray: Daily releases are not appropriate for an SRU."
<didrocks> also, it seems the files are again deprecated (we can't expect to have the files around for 2 months :/)
<didrocks> infinity: should I reupload the bamf manual upload so that it can be reviewed before being rejected based on version number?
<wgrant> didrocks: Hmm, why does sru-staging need to be nonvirt? Can't you just copy the binaries?
<didrocks> wgrant: would that work, that won't skip powerpc/armhf for instance?
<didrocks> as we'll have:
<didrocks> daily-build -> binary copy to -> sru-staging -> binary copy to -> distro
<wgrant> Right, that would work fine. Non-virt-ness only affects build creation, not copies.
<didrocks> ah, so fine without one I guess
<didrocks> wgrant: I'll implement that today then, just need to think about the best strategy to only use that ppa for SRUs
<xnox> didrocks: wgrant: everything that ends up in ubuntu archive should be compiled on non-virt. If one compiles on virt ppa, copy sources to the distro such that it's rebuild on the distro builders again.
<didrocks> xnox: who is telling it's going to be compiled on non-virt?
<xnox> didrocks: hm, I guess I miss read the backlog.
<didrocks> xnox: we are talking about binary packages copy
<didrocks> I just wanted to ensure that if the ppa is non virt and we do a binary package to it, it won't skip the archs that aren't in non virt ppas
<xnox> didrocks: I see now. no compilation will happen in sru-staging, just storing the binaries. Nice =))))
<didrocks> yep :)
 * xnox like & +1
 * didrocks points to "already implemented for an hour" :p
<didrocks> (only SRUs will follow that extra copy)
<cjwatson> wgrant,didrocks: I'm not totally sure I'm comfortable with binaries from virt builds being copied into the archive, what with them being built in a somewhat different environment and all ...
<cjwatson> Oh
<cjwatson> Sorry, read the whole backlog now :)
<didrocks> :)
<cjwatson> Yeah, copies through virt are fine
<didrocks> I'll just do that for SRU btw for now
<didrocks> see how it goes, and if we should do that unconditionnaly
<didrocks> I hope we can finally have a raring SRU for unity at some point :p
<cjwatson> jibel: I'm considering deploying the autopkgtest/proposed-migration integration today
<cjwatson> jibel: I think I have it working, but of course it's a bit hard to tell in dry-run mode because a full test relies on going back and forward to Jenkins
<cjwatson> jibel: Would you be available to watch activity on the Jenkins side and let me know if jobs are arriving correctly?
<jibel> cjwatson, Yes, I'm available. I'll watch it.
<cjwatson> OK.  I'm just doing a few last tests ...
<jibel> cjwatson, I disabled the cron entry on lillypilly, you can submit real jobs if you want.
<cjwatson> I guess if we aren't doing fully-recursive dependency expansion we still want the occasional cronned run?
<jibel> cjwatson, won't it confuse britney to receive results for tests it didn't request?
<cjwatson> Shouldn't
<cjwatson> As long as any causes from britney-initiated runs don't get lost
<jibel> cjwatson, okay, I'll keep it disable for the moment, this way I know that all the requests received by jenkins come from britney. I'll reenable it if needed once we made sure everything is running as expected with britney.
<cjwatson> jibel: You should have just got / be about to get a request for evolution-data-server 3.8.3-0ubuntu2
<jibel> cjwatson, confirmed: Found publication: evolution-data-server Proposed 3.8.3-0ubuntu2 jr jriddell@ubuntu.com
<cjwatson> Hm, but nothing in excuses
<cjwatson> I might just not have cleared out enough state
<cjwatson> Hopefully the next job will do better
<cjwatson> jibel: I'm only waiting for amd64 results at the moment.  Handling the multi-architecture case confused me.
<cjwatson> OK, well that much seemed to work
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#evolution-data-server
<cjwatson> autopkgtest for evolution-data-server 3.8.3-0ubuntu2: PASS
<cjwatson> jibel: If I do a request, submit, and collect in quick succession, is the collect guaranteed to give me back the request I just made (even if it's just as "NEW")?
<cjwatson> jibel: And for that matter can you remind me whether collect also returns old results?
<jibel> cjwatson, once a result as been collected, it is archived and won't be collected a second time.
<cjwatson> Ah, so it's synchronous on the collection.  That should be fine
<cjwatson> I have a feeling the answer to my first question may be no, though
<jibel> cjwatson, if you request/submit/collect in quick succession, I have a doubt, there should be no result at all on the collection
<jibel> I'm checking
<jibel> cjwatson, answer to your first question is no. for a given package collect won't return any result until the tests have run on all archs.
<jibel> cjwatson, but there is the information that a test is running, so I could return it if you need it.
<cjwatson> jibel: That would be helpful, but if you think it's the wrong thing to do I can work around it
<jibel> cjwatson, not at all, the collect command is not used by anything else than britney. I can do any changes that you find helpful.
 * infinity gets a giggle out of backscroll and people continually misreading the SRU PPA virt/non-virt thing. :P
<bregma> hey guise who knows what the plans are for a Unity SRU in 13.04?
<cjwatson> jibel: It might be an idea to check reverse-build-deps too
<cjwatson> Or maybe not, I don't know
<cjwatson> Since we care more about whether it breaks users
<cjwatson> Yeah, never mind that :)
<infinity> didrocks: Please do reupload that, yeah.  I'm inclined to agree with Brian that we don't want "daily builds" as SRUs, the part he missed is that these are tested and "blessed" builds that happen to be yanked from the daily stream.
<infinity> didrocks: My objection would just be ugly version numbers and end-user confidence in such, but I suspect I'd lose that argument.
<didrocks> infinity: we never had any better test trigger and repetitively ensuring we don't regress than with dailies TBH :)
<didrocks> infinity: we are repreparing another SRU daily round, using a sru-staging ppa this time
<infinity> didrocks: Awesome.  Thanks for that.  I will try to get it reviewed ASAP anyway, thanks to the shell shock from previous delays.
<infinity> didrocks: But I still hate relying on things that *might* disappear, so yay.
<didrocks> infinity: yeah, this time it won't happen I hope, with this ppa (so 2 stage copy process) :)
<infinity> didrocks: (I actually did review and attempt to accept things last week, which was what led me to throw my hands in the air and say "dude, just do the staging PPA" as I saw LP reject all my hard work)
<didrocks> infinity: well, I've been busy lately and I understood from Mirv that you were going to do the review the same day than we uploaded the 2nd batch, hence the "on my too long TODO list"
<didrocks> at least, we'll know soon if it's working :)
<bdmurray> infinity: If I am remembering correctly, one other issue I had with the changelog for bamf  was that there were two entries in it and there LP bugs in both entries and only the first ones would be auto closed by the janitor.
<cjwatson> That's actually not true provided that the package has been in the relevant -proposed suite before
<cjwatson> (I think)
<cjwatson> Anyhow that's only a signed dpkg-genchanges away :)
<infinity> bdmurray: Oh, was the .changes wrong?  I hadn't gotten to looking at it yet.
<infinity> bdmurray: Still, that's not what your reject message said. :)
<bdmurray> It seems I should have kept better notes to be able to refer to today
<infinity> bdmurray: I'm not too concerned.  They're going to blat a whole new set of SRU candidates at us soon enough, and I'll get those reviewed.
<infinity> bdmurray: It's just been a comedy of errors trying to get this autolanding stack in.
<bdmurray> cjwatson: were you going to submit a Launchpad bug about copy package and phased update percentage?
<bdmurray> infinity: okay, I'll still keep better notes next time / save the diff
<Trevinho> infinity: any news on unity sru for raring?
<infinity> Trevinho: There isn't one in the queue right now, I'm waiting on didrocks to fix up his staging PPA workflow, and we'll have another batch
<Trevinho> infinity: ah... I was told days ago that it was in queue...
<infinity> Trevinho: And that all got rejected due to the lack of staging PPA, and the files timing out.  So, we're working on making it more foolproof.
<Trevinho> infinity: ah, I see
<Trevinho> infinity: thanks for the update
<cyphermox> can someone please reject libdbusmenu_0.6.1-0ubuntu3.1 from the precise proposed queue, it's wrong...
<stgraber> cyphermox: done
<phillw> hi, on todays builds for lubuntu we seem to have 'lost' ZRam. Has there been an updated seed file from Julien, or is the builder just having an 'off-day'?
<jbicha> phillw: it's listed in the lubuntu manifests
<phillw> jbicha: zram-config ... got removed from 13.10 daily build of 17-Jun
<phillw> I'll grab the ISO to my server (faster) and check it is still there.
<jbicha> you can check the manifests at http://cdimage.ubuntu.com/lubuntu/daily-live/current/
<jbicha> or the build logs at http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/ if something was added or removed, it would be listed there
<stgraber> phillw: it's listed in the manifest of all of today's daily, daily-live and daily-preinstalled
<phillw> jbicha: stgraber thanks, I've asked the OP to zsync & am also pulling in zsync http://cdimage.ubuntu.com/lubuntu/daily-live/20130617/saucy-desktop-i386.iso.zsync
<phillw>  to my server
<phillw> is there a way to do a diff between the build on http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/daily-live-20130610.log and http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/daily-live-20130617.log to just check if it has fallen off? The OP is adamant that it is not in today's image.
<jbicha> phillw: if you look at the 0613 log you can see that zram-config was added that day and xscreensaver was dropped; if something else changed it would show up like that in the log
<stgraber> phillw: I think it'll benefit everyone here if you confirm issues before bringing them to this channel
<stgraber> phillw: anyway, in this specific case, as both jbicha and I have been telling you, zram-config is in your image: http://paste.ubuntu.com/5775623/
<phillw> jbicha: this is really wierd, the iso from those days was running ZRam happily, but I'm told it is not there on todays image. The zsync confirms the md5 is correct. Where in the ISO (I've got it mounted in /mnt/loop) would I see it.
<phillw> stgraber: ^^
<stgraber> phillw: see the link I gave you 30s ago
<phillw> stgraber: no, actually in the ISO, please?
<stgraber> phillw: please read that paste again
<stgraber> carefully
<phillw> stgraber: there is no /etc in the ISO
<stgraber> phillw: indeed, and if you actually read what I paste, you'll see why and where the listing actually comes from
<phillw> stgraber: I'm sorry for being a n00b at this, I've done  mount -t iso9660 -o loop ./saucy-desktop-i386.iso /mnt/loop0
<phillw> which has mounted it and 'ls -l /mt/loop0' shows stuff in the directory, but 'find /mnt/loop0 | grep zram' reports nothing
<stgraber> phillw: right, and if you had read my paste, you'd have noticed I'm doing a second loop mount to actually see what's in the live file system
<phillw> *ls -l /mnt/loop0*
<stgraber> http://paste.ubuntu.com/5775623/ <= line 20 and line 23
#ubuntu-release 2013-06-18
<phillw> stgraber: thanks, it works with your instructions. I've never live mounted an ISO before (except with grub). But, as it is there, I'm as much confused as before as to why it has stopped working.
<phillw> I'm out of ideas, but now I'm getting shouted at.... ZRam is NOT in the daily build regardless of what the logs say.
<phillw> WHy is zRAM removed from the daily build? Is it a mistake, was the idea
<phillw> to test zRAM only a few days, or did someone find something really bad
<phillw> with it?
<infinity> No one removed anything.
<phillw> I'l leave that with you good people... https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1192005
<ubot2> Ubuntu bug 1192005 in lubuntu-meta (Ubuntu) "zram-config is not enabled by default on saucy-desktop-i386 17-Jun daily build" [Undecided,Confirmed]
<phillw> infinity: I've now had it from two testers.... that is enough for me to 'see' something has gone wrong? What else is needed :'(
<infinity> phillw: This isn't an ubuntu-release thing, please talk to your own engineers to see what's going on.
<phillw> infinity: when was the last meta package for lubuntu updated? If it is a fault by Julien, I'll go nag him!
<infinity> https://launchpad.net/ubuntu/+source/lubuntu-meta
<phillw> Evidently, what is on the daily launchpad list is not the same as what gets fed into the seed.
<stgraber> please go and talk to someone who's in charge of the technical side of lubuntu, as quite a few people have been telling you now, it's not an #ubuntu-release issue
<phillw> you guys know when lubuntu changes the seed list, it is on a seperate area
<infinity> phillw: That version of lubuntu-desktop is on the CDs, and so is zram-config.
<stgraber> and it very likely has absolutely nothing to do with seeds as the package and files quite clearly are on your images, why zram-config doesn't work is a whole other question which is best answered by one of your technical guys
<phillw> stgraber: I'm just trying to learn... I'm sorry if that is annoying for you.
<infinity> phillw: The bug reporter, however, has "Package: lubuntu-desktop 0.48" installed.
<infinity> phillw: So, it's an out-of-date image.
<stgraber> phillw: I'm fine with people learning, but using a release communication channel full of people who don't necessarily have a whole lot of interest in Lubuntu isn't quite the right place for this
<infinity> stgraber: It's not zram-config not working, it's a tester using an old image.
<infinity> phillw: ^
<infinity> phillw: This is not a learning channel.  We have channels for that.
<stgraber> infinity: ah yeah, that'd explain it too ;) phillw has repeatedly been saying that this was on today's image, I was (apparently wrongly) assuming that he at least made sure this was the case
<infinity> LiveMediaBuild: Lubuntu 13.10 "Saucy Salamander" - Alpha i386 (20130607)
<infinity> phillw: So, all the info you needed was right there in the bug report.
<infinity> phillw: Including the build date of the ISO, and the old version of the meta package.
<phillw> infinity: Hmm, well, that's one person I instructed to zsync http://cdimage.ubuntu.com/lubuntu/daily-live/20130617/saucy-desktop-i386.iso.zsync and one more who has stumbled upon it. I'm really sorry for this. I'll go back and check what the heck is going on. They both know how to pull in the latest ISO's (as is evident with them reporting a glitch with the most recent one).
<phillw> infinity: just by the way, which learning channel should I be using? I had wrongly assumed that I "had my head round" how the dailies are built and mistakeingly thought this was the channel to learn about them on. May I once again humbly apologise.
<infinity> phillw: Well, for starters, this had nothing to do with how the ISOs are built, just with reading a bug report.
<infinity> phillw: But #ubuntu, possibly #ubuntu-bugs or #ubuntu-motu.  I'm not sure where best to ask these questions.  But the temptation to ask all your questions here because this is where the cool kids hang out doesn't help us get actual work done.
<TheDrums> -motu isn't really right either.
<infinity> No, probably not.  It's mostly packaging oriented.
<phillw> infinity: with the greatest of respect... http://pastebin.com/jH62bLJF
<infinity> -bugs, perhaps, but I don't hang out there, I'm not sure what they do.
<infinity> phillw: yes, and?  That's clearly not the ISO the person installed and reported the bug from.
<phillw> it is
<infinity> phillw: It's not.  We could argue this all day, or you can tell him to rewrite his CD or USB key and try harder.
<infinity> phillw: I can pretty clearly see the contents of today's daily, and that it contains newer packages than what the bug is filed against.  He didn't install something that magically downgraded his packages.
<infinity> phillw: So, as much fun as it is to argue incessantly, please don't.
<stgraber> phillw: https://www.stgraber.org/download/lubuntu-zram.png
<phillw> infinity: thanks! At least I know where the problem is... And, very sadly, it is only on here I can get deffinate answers. I do try to avoid 'bugging' you good people, as I know you have better things to do. I'll try to leave you all in peace:)
<stgraber> that's a screenshot of the exact image you linked earlier, showing a VM running with zram started and 1GB of swap configured as a result
<stgraber> can we now please stop that argument and get back to doing productive things
<phillw> stgraber: several people (testers) are going to get 'barked' at :)
<infinity> phillw: You don't need to come here for answers, you could have read the bug report.
<infinity> phillw: Please, we're not your personal resource for these sorts of things.  Pretty please.  With sugar on top.
<TheDrums> You're actually doing more to hurt Lubuntu, as people will remember events like this and not be nearly as willing to help...
<phillw> infinity: I was dealing with the OP to get him to file a bug report, it did not enter my head after my telling him to zsync up that he would be using an old image.... In all honesty, would you have expected that?  I will double check next ime.
<phillw> *next time*
<infinity> I suspect I would have expected it, or I wouldn't have gone looking.
<infinity> Well, I started by checking the manifest to see what version of lubuntu-desktop and zram-config were on the ISO.
<infinity> Then I noted that the bug report had an older desktop.
<infinity> And checked the other bits.
<infinity> But it's all there.
<infinity> And didn't need an "expert" to diagnose.
<infinity> Just someone who can compare integers.
<infinity> Which, it turns out, is nearly everyone over five.
<phillw> Yeah, maybe better if I do not ask questions on here.. Sorry for taking your time up.
<infinity> stgraber: queuebot is wedged again.
<didrocks> infinity: hey, what would it take to have the daily-build ppa building including -proposed?
<didrocks> (not talking about upstream CI, it's their own willingness to not take it for now)
<infinity> didrocks: Just tick the box on the PPA dependencies page?
<infinity> didrocks: +edit-dependencies
<didrocks> infinity: waow, that was easy! Thanks :)
<infinity> didrocks: No problem.  I feel like I've been useful today now. :P
<didrocks> infinity: roh, happy to help you having this feeling then :-)
<sil2100> Hi
<sil2100> infinity: ping!
<stgraber> infinity: restarted, will have to look into the actual cause at some point... it's been rock solid for months last cycle but not so much this one...
<infinity> sil2100: Pong?
<sil2100> infinity: unping!
<bdmurray> infinity / cjwatson: dogfood is timing out for me regularly perhaps due to pending publications like https://dogfood.launchpad.net/ubuntu/quantal/amd64/libxen-dev.  Is there a way via the API I can delete them?
<bdmurray> Does requestDeletion work with pending publications?
<cjwatson> Keep trying - dogfood's db is very slow
<bdmurray> I've been trying although not in really quick succession
<bdmurray> and in quick succession it is still timing out
<cjwatson> There may not be much we can do about it on dogfood
<cjwatson> requestDeletion should work
<bdmurray> okay, I'll try deleting some of the pending publications then
<bdmurray> thanks!
<bdmurray> oh, cjwatson were you going to submit a bug about copy package and phased update percentage or should I do that?
<cjwatson> oh, er, I keep meaning to but I have to go for dinner now; if you wouldn't mind that'd be great
<bdmurray> cjwatson: okay, I'll subscribe you in case I butcher it
<cjwatson> ta :)
<rtg_> infinity, please NEW the tools binaries for linux-manta
 * Noskcaj is away: school
#ubuntu-release 2013-06-19
<wgrant> bdmurray: dogfood's running the entire Launchpad application and DB on a 4GiB machine from 2004, so it's unfortunately rather slow. Retrying a few dozen times sometimes works.
<mlankhorst> cjwatson: it still says new source for the lts-quantal one?
<cjwatson> mlankhorst: Yeah, buggy ancestry handling in LP, but it doesn't make much difference
<Daviey> Hey, the web team have expressed an interested in updating some of the look and feel of http://cloud-images.ubuntu.com/ , i explained that it shares a common base with the cdimage site.  Would a refresh be well received in that aswell?
<Daviey> (& old-releases)
<tjaalton> any archive admin around to approve libdrm/x-x-v-intel ^ for bug 1175533?
<ubot2> Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,New] https://launchpad.net/bugs/1175533
<tjaalton> oh libdrm was approved already
<tjaalton> -intel then :)
<mlankhorst> and the lts-raring lts-quantal in precise, I'm still fixing up mesa atm
<mlankhorst> can someone move mesa to main in raring?
<mlankhorst> it's in -proposed atm
<cjwatson> Daviey: If it shares a common base, I think it's something your team must maintain semi-manually?  cloud-images isn't on nusakan AFAIK so not automatically kept up to date
<cjwatson> Daviey: I don't mind a refresh in principle, but in the past what I've got tends to be a dump of what the output HTML should look like that's very time-consuming to integrate.  It would be helpful to explain that the HTML is heavily generated by lp:ubuntu-cdimage
<Daviey> cjwatson: Right, i mean - it's a fork of the one on nusakan (and so is old-releases).. Rather than the webteam just refreshing the cloud one, i wondered if it made sense to do it generically
<Daviey> And yes, agreed, ugly html/css will be a blocker.
<cjwatson> I don't have any time to integrate HTML dumps, at least not this cycle.  If there's any refresh it will have to come as patches to the Python code.
<Daviey> ok
<ogra_> cjwatson, did you see all the failed image builds today ? i wonder hos signon-ui got past britney in that state
<cjwatson> If it comes that way I'd be happy to review it.
<ogra_> *how
<cjwatson> ogra_: I did and talked about it on #ubuntu-devel
<ogra_> ah, k
<cjwatson> ogra_: proposed-migration doesn't check components
<cjwatson> This is well-known (to me anyway) but not worth the gigantic amount of effort it would take to fix
<cjwatson> At least in my assessment
<ogra_> k
 * ogra_ just looked in -desktop's backlog
<bdmurray> cjwatson: copy package and phased update percentage is bug 1192286
<ubot2> Launchpad bug 1192286 in Launchpad itself "Allow phased update percentage to be set when copying a package" [Undecided,New] https://launchpad.net/bugs/1192286
<cjwatson> ta
#ubuntu-release 2013-06-20
<ogra_> wow, britney has a fast day (or my timing was very lucky)
<xnox> ogra_: you probably do not have autopkgtests! =( otherwise it now takes longer ;-)
<cjwatson> slangasek,bdmurray: working on the copy/phased-updates thing now.  I'm a bit rusty ...
<psivaa> cjwatson: just curious if there will be saucy desktop images arriving later today
<ogra_> depends when libqt5webkit5 enters main
<cjwatson> psivaa: blocked on bug 1192567, I believe currently taken by doko
<ubot2> Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] https://launchpad.net/bugs/1192567
<doko> yes, will look at this today
<psivaa> cjwatson: doko: ack, thanks
<slangasek> per discussion on #ubuntu-devel, cleaning up daily-preinstalled/* on nusakan... as it only contains stale nexus7 desktop images
<ogra_> yeah
<stgraber> cjwatson: hey, do you happen to know what I'd need to do to hook into live-build's compression code? Basically I want to have it spit out both the current .tar.gz and a new .tar.xz (with everything shifted into a system/ directory in there) at the end of an ubuntu-touch build
<cjwatson> stgraber: One or the other is easy, but to do both, I think it'd be simplest to just recompress it in livecd-rootfs/live-build/auto/build
<stgraber> cjwatson: ok
<stgraber> cjwatson: ok, got it working here, though looking at how slow it's on my laptop, I'm not sure we want that to run on armhf. I think I'll instead just write a python tool that does the unpack, move stuff to a sub-dir, repack on nusakan.
<cjwatson> ok
<stgraber> once we get rid of the existing .tar.gz rootfs, we could even grab an uncompressed copy from the livefs builder which I suspect would cut build time by a few minutes (looking at how slow compression is on pandas...)
<stgraber> (or we'll just have the shiny new builders and won't have to care about this anymore... not sure how fast those calxeda nodes are at doing gzip/xz)
<cjwatson> infinity: So I just commented out auto-sync for Debian import freeze, and was going to send mail about it, but I just noticed that raring's schedule had DIF in week 17 and saucy's schedule has it in week 8.  This seems a weirdly enormous discrepancy.  I thought I mentioned this in the UDS discussion - didn't we agree to move it?
<infinity> cjwatson: Hrm, I didn't have moving it in my notes.
<ScottK> IIRC it was supposed to be close to FF.
<ScottK> (not from UDS, but generally from the raring discussion)
<infinity> So, Raring had it at alpha2.  I'm not wildly picky about exactly when and where it lands, so long as it's not after FF. :P
<infinity> And, honestly, we have people who like to play the role of the autosync bot after DIF anyway (a practice I'd love to stamp out)...
<cjwatson> I know day-of is a crappy time to be asking about it, but it does seem incredibly weirdly early to me this time round.
<cjwatson> Two weeks earlier than quantal, even.
<infinity> cjwatson: I don't think anyone will mind if it slips later.  Maybe we can hit some mild concensus among people in the channel right now.
<cjwatson> I agree it clearly ought to be before FF.
<cjwatson> Raring had it coincident with Alpha 2.  That seemed OK to me.
<infinity> cjwatson: I's be comfy with either A2freeze or FF.
<doko> now you build everything, and everything is fine, and then somebody uploads a new texinfo :-/
<ScottK> cjwatson: Sounds good to me.
<ScottK> KDE 4.10.4 is all accepted for raring now, so the wall of accepts should be over.
#ubuntu-release 2013-06-21
<didrocks> infinity: hey, do you have any idea when the SRU will be review for the unity stack in raring?
<didrocks> infinity: I hope we can finally get those netbook for who unity is not working fixed, as the fix was ready for a month and half
<Laney> I thought we had a chat about DIF at the vUDS session
<cjwatson> Guess I could go and review the video
<Laney> already loading it up
<cjwatson> Be my guest :)
<Laney> if I can bear to see myself on video, that is
<Laney> oh no, that's the one I missed :-)
<Laney> cjwatson: https://www.youtube.com/watch?v=Re9HfnTifaY&feature=player_embedded - the two of you discussing decided-ish on week 12 but pending an ubuntu-release discussion
<Laney> guess that is this
<xnox> Laney: can you give that link with minute/second offset ?
<Laney> 10:30
<cjwatson> k, I shall refrain from enduring listening to myself since you have kindly summarised
<Laney> the discussion starts at 06:30
<Laney> xnox: I don't know how
<xnox> Laney: click share tab, tick start at: http://youtu.be/Re9HfnTifaY?t=6m30s
<cjwatson> (mental self-image of voice does not have the same accent or pitch as actual voice)
<xnox> there you go, even using youtu.be short url.
<Laney> my hero
<xnox> cjwatson: the actual voice sounds better than mental self-image of voice?! right?!
<cjwatson> god no
<Laney> never does
 * Laney has a sexy radio 4 continuity announcer style voice
<Laney> right guys?
 * xnox must sound hideous then, since i don't like the mental projection of mine much.....
<xnox> Laney: you don't speak much anyways =))))))
<Laney> righto :P
 * xnox wants the voice of danny o'donoghue
<Laney> anyway
<Laney> 12 or 13 would be fine by me
<sil2100> Hi!
<sil2100> Is there anyone from the SRU team around?
<seb128> sil2100, you better state your question than wait for an answer to that ;-)
<sil2100> So, Brandon prepared some unity+nux fixes for those bugs for raring: LP: #983254, LP: #1043627, LP: #1112044
<ubot2> Launchpad bug 983254 in Unity 5.0 "Support input methods beside ibus" [High,In progress] https://launchpad.net/bugs/983254
<ubot2> Launchpad bug 1043627 in Nux 2.0 "Add XIM Support to Nux" [High,In progress] https://launchpad.net/bugs/1043627
<ubot2> Launchpad bug 1112044 in Nux 2.0 "Fcitx can't input word group more than 6 Chinese characters in Dash. Causes a crash if entering to many characters." [High,In progress] https://launchpad.net/bugs/1112044
<sil2100> It's hard to say if those are bugs or features, so I wanted to get a confirmation if those are SRUable - the priority for those is rather high, as it affects many asian-language countries
<sil2100> The fixes are ready, reviewed and waiting to get merged
<sil2100> cjwatson: hi! Maybe you would have a moment to give a quick look and comment? ;) ^
<cjwatson> I think it'd be better to be somebody with more desktop clue than I do
<stgraber> cjwatson: [cjwatson] suggest moving DIF to week 12 (18 July) on -release
<cjwatson> Either week 12 or 13 is fine by me, don't feel strongly
<cjwatson> But thanks for the reminder :)
<xnox> cjwatson: week 13 sounds better, as it will be Alpha2 again, just like in raring. That's like two releases in a row ;-)
<xnox> (as if that's any kind of an argument for week 13 vs week 12)
<TheDrums> https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule has a header of "Do not edit", but it seems you've moved DIF, mind updating there or if I do?
<stgraber> TheDrums: I was assuming cjwatson would do it once his "complain now or I'll move it" deadline is passed (Tuesday IIRC)
<TheDrums> Cool, I'll shutup. :)
<infinity> TheDrums: That's sort if why it has the "do not edit" header, so people don't randomly change things without concensus, or mistake a discussion for a decision. :)
<TheDrums> (I wouldn't have edited it anyway, just an excuse to ask about it in here.)
<Trevinho> Laney: still here?
<infinity> autopkgtest for eglibc 2.17-0ubuntu5: RUNNING
<infinity> autopkgtest for linux 3.9.0.7.8: RUNNING
<infinity> ^-- Why do I have a feeling that's going to take a Very Long Time?
<cjwatson> Spare a thought for glib2.0
<cjwatson> autopkgtest for firefox 22.0~b6+build1-0ubuntu1: RUNNING
<cjwatson> autopkgtest for libreoffice 1:4.0.2-0ubuntu5: RUNNING
<cjwatson> autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING
<cjwatson> autopkgtest for ubiquity 2.15.7: RUNNING
<infinity> cjwatson: So, out of curiosity, do we even have remotely enough resources to run all these tests before tomorrow? :)
 * infinity wonders how beefy jibel's infrastructure is.
<ScottK> Sounds like rather a personal question.
<infinity> ScottK: There's a reason I avoided the word "equipment".
<cjwatson> I guess we'll find out
<cjwatson> Given how many times management has asked me about this work I expect I might have some leverage if it turns out to be prohibitively expensive
<infinity> cjwatson: Yeah.  It just stands to reason that, as test coverage increases (or for awful rdep cases like glibc and glib), the autopkgtest QA will take orders of magnitude longer than the actual builds do.
<infinity> cjwatson: So, if that can be parallelised out very, very well, yay, but it could take a whole lot of machines.
<infinity> (Or, we have to pare down some of the scarier rdep trees)
<cjwatson> Well, as I've said, there are always force-autopkgtest hints in special cases if need be.
<cjwatson> But, yes, I expect the rdep analysis may need to get a bit subtler.
<infinity> Yeah, but I want to avoid using those as a general rule.
<cjwatson> I had the impression there were quite a few Jenkins slaves, but I don't know the details.
<infinity> Well, hopefully we're keeping some stats (or just a decent request/response logfile) so we can do some analysis later.
<cjwatson> Not in a very pleasant form, but it's mostly logged.  I was going to clean that up a bit soon.
 * infinity wonders if he should brave the outside world for food, or if it's better to avoid being dragged away in a flood, and just find something in his house.
<cjwatson> Right now I'm in one-more-upload-then-bed mode though ...
<infinity> cjwatson: Pleasntness is less important than in/out timestamps. :)
<infinity> cjwatson: Computers are awfully good at reading files I can't make sense of.
<cjwatson> I'm not totally sure the results are properly logged other than in excuses.  I'll check next time I'm in there.
<infinity> With the exception of the Canterbury Tales.
<cjwatson> Did I ever tell you about my stepson's experience with the Canterbury Tales when he was little?
<cjwatson> He had recently learned how to read and was doing fairly well
<cjwatson> Then he came in one evening holding a book, quite upset, saying "mummy, I've forgotten how to read"
<cjwatson> ... it was Chaucer
<infinity> Hah.
<infinity> Well, time to teach him some Middle English.
<infinity> Mine is pretty piss-poor these days.
<infinity> I used to be passably alright.
<cjwatson> Given some of the Tales it's probably best for them to be encoded in a child-safe form. :-)
<infinity> Meh, they're not THAT raunchy, really.
<infinity> And at least they're well-written.
 * cjwatson reads about the floods.  Yikes.  Bring stilts?
<infinity> God forbid children stumble on literary abortions like 50 Shades.
<infinity> Not because of the content, but because it would teach them some terrible style and grammar.
<infinity> I highly recommend "Mark Reads 50 Shades" (youtube search it, I'm not going to link it), for work background noise.
<cjwatson> I've so far avoided the source material.
<infinity> Well done.  But Mark Reads is a whole different story.
<infinity> In fact, nearly any of his segments are good, but the 50 Shades one is great just to get a feel for how awful the source material really is.
<infinity> Like, the author ending narrative sentences in ", or something."
<cjwatson> I've read a few fairly blistering written criticisms/satires of it.
<cjwatson> But, yeah, fanfic goes straight to publication without the benefit of a whole lot of editing in between, I gather
<infinity> My ex made the mistake of reading it and spent several DAYS complaining to me about how awful it was.
<Laney> Does proposed-migration/autopkgtest require the test to succeed or to not go from successfulâfailure?
 * Laney is concerned about the LO autopkgtest ...
#ubuntu-release 2013-06-22
<cjwatson> Laney: To succeed
<Laney> grarg
<Laney> Maybe jenkins is having a sad time anyway; can't see that those jobs are being run or get to the internal instance
<cjwatson> We may have to force that one if nobody can be bothered to fix it - but the list of autopkgtests is sufficiently short that I think it's worth additional incentives to get the failures to zero routinely
<cjwatson> Also possible that proposed-migration is wrong that they're running
<Laney> I do see pango in https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/portlet/dashboard_portlet_29/
<cjwatson> There's probably something wrong at my end.  May look at it when I'm more awake ...
<Laney> No need to spend weekend time on it really if it'll block on Libreoffice anyway
<Laney> I'll just hit Sweetshark with it on Monday
 * Laney goes to catch a train to Huntingdon
<Laney> ttfn
<cjwatson> Huntingdon> I'm so sorry
<Laney> points failure has me stuck at Grantham
<Laney> not sure if that's better or worse ...
 * Noskcaj is away: I'm either at school or soccer. or i just don't like you.
<Noskcaj> stupid xchat
 * apw notes that the autopkgtest for linux is marked as running in proposed-migrations (autopkgtest for linux 3.9.0.7.8: RUNNING
<apw> ) any idea where i might find the said run to see when it started, how long it takes normally etc
<cjwatson> I think it's probably a bug that it's listed as still running.
<cjwatson> I was going to look at it at some point over the weekend.
<cjwatson> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
 * apw idly oneders if cjwatson is every offline :)
<apw> ever
<apw> there is definatly something wrong with this keyboard, sigh
<cjwatson> Hm, that doesn't show a recent run.
<cjwatson> Has your autopkgtest ever passed?  Doesn't really look like it.
<apw> assuming it is saucy-adt-run, there was one 17 hours ago, that would be about the right time
<cjwatson> Oh, back in Feb for raring apparently
 * apw thought that their autopackage run was 'empty' and just triggered a kernel build
<cjwatson> apw: saucy-adt-linux.  That run looks too early
 * apw checks the config is even in the tree
<cjwatson> There's something wrong here but I think it needs jibel.  How about I force it for now
<apw> no great shakes either way i suspect
<cjwatson> Do see if you can fix it though.  Try running 'adt-run linux_blah.dsc --- adt-virt-schroot saucy-amd64' on a machine with a saucy-amd64 chroot
<cjwatson> schroot that is
<apw> cjwatson, yeah wil have a poke see what we added.  i seem to remember it being empty
<apw> cjwatson, though this saucy run looks about right.  source published 21 hours ago, run was 17 hours ago
<apw> (right time wise)
<cjwatson> Maybe I can't do timezone maths
<cjwatson> Or maybe I trusted the changelog date rather than the upload date :)
<apw> oh, hmm, good point, maybe i am not taking them into account at all ;)
<apw> though reading the jenkinsjob it does indeed seem it did nothing at all instead of testing right
<Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-linux/39/ARCH=i386,label=adt/console
<Laney> Does look like the right version
<Laney> badpkg: Test Depends field contains an invalid dependency `' adt-run: erroneous package: Test Depends field contains an invalid dependency `'
 * apw goes look at what we had in raring and what we carried forward, perhaps it got broken then
<apw> Laney, we do have an empty Depends: that was something pitti said we needed
<apw> now what it might mean, erm, not sure
<Laney> Well, see if you can reproduce and fix locally I guess.
<Laney> Maybe the apec has something to say about it
<apw> cjwatson, Laney, yep seems reasonable i'll take this away and poke it
<Laney> Oho, looks like we are arriving in the promised land of Peterborough. See you.
<Laney> (apec/spec)
<apw> Laney, heh good luck with _that_
<jibel> apw, empty Depends field makes adt-run fail. The spec doesn't mention how it should behave in that case.
<jibel> Strictly speaking, the meaning of an empty Depends field would be "do not install any package for the test" which is different from no Depends field which means "install package(s) generated by the source package"
<jibel> but I never received an answer from upstream on this point.
<jibel> apw, for linux adt test, if it is a rebuild test, you should probably have Depends: build-essential
<jibel> instead of nothing
<apw> jibel, ahh really, i can do that...
<apw> jibel, do we do autopkgtest on anything other than development do you know ?
<jibel> apw, we do autopkgtest on dev and latest stable. Precise and Quantal are kept only to run MaaS package tests. But going forward, with the increasing number of packages autopkgtest-able, I think it's helpful for SRUs to keep them running on all supported releases.
#ubuntu-release 2013-06-23
<jbicha> hey, could you temporarily sync-blanklist the packagekit stack which is landing in unstable now?
<jbicha> apper, gnome-packagekit, listaller, packagekit, packagekit-qt
#ubuntu-release 2014-06-16
<soren> 12.10 and 13.04 are still not on old-releases.ubuntu.com in spite of EOL announcements having been sent out. Is that intentional?
<sil2100> cjwatson: hey! Do you have a moment for a packaging ACK? There is a new binary package in a pending release in CITrain
<sil2100> cjwatson: the changes themselves seem to be ok, but I'm not entirely sure about those as well: https://ci-train.ubuntu.com/job/landing-017-2-publish/lastSuccessfulBuild/artifact/packaging_changes_signon-ui_0.17+14.10.20140612-0ubuntu1.diff <- here's the new binary pkg added
<sil2100> cjwatson: and here's the related change in u-s-s-o-a: https://ci-train.ubuntu.com/job/landing-017-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings-online-accounts_0.4+14.10.20140612-0ubuntu1.diff
<cjwatson> sil2100: Mostly looks OK, but I have two questions
 * cjwatson checks before speaking
<cjwatson> one question :)
<sil2100> ;)
<cjwatson> sil2100: This seems to lose several files that are currently in signon-ui - or do those vanish as part of the move to oxide?
<cjwatson> /usr/lib/$(DEB_HOST_MULTIARCH)/signon-ui/browser-process, /usr/bin/tst_inactivity_timer, /usr/share/applications/signon-ui-browser-process.desktop
<sil2100> hmmm
<sil2100> Right, I suppose those are removed on purpose with the switch, as if it was not planned the packages wouldn't build
<cjwatson> They might build but not work
<cjwatson> Are those binaries still built/present-in-source?
<sil2100> cjwatson: well, we have --fail-missing so if they were originally 'built' from the source and not included, they would break package build
<sil2100> So if they're not generated, I guess it's intentional, hm
<sil2100> cjwatson: I can talk with the upstream guys if needed
<sil2100> To make sure
 * cjwatson goes to look at the silo
<cjwatson> browser-process was intentionally removed
<cjwatson> and not installing a unit test probably isn't a problem
<cjwatson> ah, probably
<cjwatson> -include($${TOP_SRC_DIR}/common-installs-config.pri)
<cjwatson> sil2100: ~ubuntu-core-dev / ~ubuntu-archive ack
<sil2100> Thanks! :) Yeah, I supposed it's intentional, that's usually why --fail-missing is our 'safe-keeper' here, as we make sure the upstream developers know what they want to ship
<sil2100> But it's still best to double check anyway
<cjwatson> right, --fail-missing is normally the right thing
<sil2100> seb128: did you have a moment to do a NEW review of net-cpp by any chance? :)
<seb128> sil2100, let me add that to my todolist, I can try having a look today
<sil2100> Thanks!
<rtg> infinity, could you approve Trusty linux-firmware 1.127.3 ? I've got some server guys waiting on it, and just discovered https://bugs.launchpad.net/bugs/1327908 as well.
<rtg> nm about bug 1327908, thats bogus.
#ubuntu-release 2014-06-17
<arges> hi. looking at libgphoto2 in trusty queue which fixes the broken -proposed version (2.5.3.1-1ubuntu2.1). Should the diff be against ubuntu2 or ubuntu2.1 with what I see in the queue? Anything I should watch out for there?
<cjwatson> If the diff in the queue is wrong (possible) then just download the source and debdiff by hand against the versions in trusty/trusty-proposed
<arges> cjwatson: sure, what I'm asking is should the debdiff i see with 'sru-review' show the diff against the -updates version or -proposed?
<cjwatson> arges: And what I'm saying is that I don't remember but that if it doesn't it isn't fatal and you should just do the diff by hand
<cjwatson> I mean if it doesn't do whichever of those you might want - I can imagine either being useful
<arges> cjwatson: ok Ill do that, overall I just want to make sure if I accept it in the queue, i'm doing the right thing; esp since this is a case where the old -proposed is verficiation-failed
<cjwatson> I would normally diff by hand in that situation anyway just to make sure
<arges> cool, doing that now
<zul> do i have to write a MIR for python3-tornado even though python-tornado is in main already?
<cjwatson> No, it's from the same source package
<cjwatson> zul: python3-sure also seems to be missing for python-httpretty though
<zul> cjwatson: yeah im trying to trackdown python-htpretty in proposed
<cjwatson> zul: could you write an MIR for python-rednose?
<cjwatson> I think that's what's needed
<zul> cjwatson: yeah im on it
<cjwatson> Also python-termstyle
<cjwatson> python3-tornado can be promoted without paperwork, but I'd rather hold off on it until the other things are done because otherwise it'll transiently show up for movement back to universe in c-m and somebody might do that
<arges> zul: can keystone/ceilometer 1:2014.2~b1-0ubuntu1 be rejected from the queue since I see newer versions?
<arges> (from the trusty queue that is)
<zul> arges:  yes
 * arges starts reviewing the rest of the openstack uploads.
<jamespage> arges, can you hold on those for the moment
<jamespage> arges, just waiting for nova to catchup
<arges> jamespage: ok,. got neutron accepted. but will holdon the rest
<arges> jamespage: sorry about that.
<jamespage> arges, hey - no problem
<jamespage> arges, I guess it does not hurt from them to enter proposed a little staggerred
<Laney> is germinate-output from previous days stored anywhere?
<cjwatson> Laney: sorry no
<Laney> oh well
<Laney> was wondering why removing no-follow-recommends from touch/desktop changed little
<rbasak> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.utopic/all lists chkrootkit as coming from "Ubuntu.Utopic supported-sysadmin-common seed" and it's in component mismatches.
<rbasak> This is from https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/1324111 I guess.
<rbasak> I'm confused though, as I see no mention of chkrootkit anywhere inside lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.utopic
<rbasak> And the email to ubuntu-release said "[Reverse-Depends: Ubuntu.Utopic supported-misc-servers seed]"
<cjwatson> ubuntu.utopic inherits from platform.utopic and the supported-sysadmin-common seed is in the latter.
<rbasak> Ah
<rbasak> I did not know about inheritance or about platform.*. That's what I was missing. Thanks.
<cjwatson> The inheritance is defined in STRUCTURE.
<cjwatson> It might be nice if germinate used the real seed collection name in its reasons rather than the starting collection though.
<cjwatson> Bug report would be welcome.
<rbasak> I'll happily file one for you, but I'm barely starting to understand this area. I can do some copy and pasting from here though :)
<cjwatson> Copy and paste will be fine :)
<rbasak> Done: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1331072
<rbasak> Ugh the copy and paste came out horrible. Sorry.
 * rbasak fixes
<rbasak> jdstrand: ^^ - so could you drop chkrootkit from platform.utopic/support-sysadmin-common also, please, for bug 1324111? I don't have commit rights.
<jdstrand> rbasak: done
<rbasak> jdstrand: thanks!
#ubuntu-release 2014-06-18
<RAOF> Ok. That'll do for the morning.
<bluesabre> :)
<mlankhorst> hm xserver-xorg-input-synaptics has a breaks on kde-config-touchpad (<< 0.8.1-2~) because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722058
<infinity> mlankhorst: So, looks like the saucy version of synaptics probably needs to be backported to precise, and then the Breaks relaxed to match the right version.
<mlankhorst> yeah I already did that
<infinity> mlankhorst: Which part of "that"?
<mlankhorst> I asked rtg to sponsor :)
<rtg> infinity, arges and I are looking at it
<infinity> rtg: Ta.
<arges> yup
<arges> mlankhorst: bug 1328266 ... is this just valid for precise?
<mlankhorst> think so, it's because trusty was merged against debian's branch again
<mlankhorst> and picked up the breaks from there
<arges> mlankhorst: also can you update the bug with the SRU template please?
<arges> mlankhorst: did this patch get refreshed: synaptiks-0.8.1/debian/patches/kubuntu_fix_udev_property_access.patch ?
<mlankhorst> I grabbed the saucy package, i think it only removed the crashing parts
<mlankhorst> oh the timestamp is different, but seems to be the same patch afaict
<mlankhorst> copied the sru template from the other bug :P
<arges> mlankhorst: so are these two things needing sponsoring related?
<arges> or independet
<mlankhorst> related
<mlankhorst> because otherwise you can't install even the fixed synaptiks
<arges> mlankhorst: can you explain a bit more? or if its in the bug let me know where I can read that
<mlankhorst> erm xserver-xorg-input-synaptics had a breaks on << -2, but the upload is for -1ubuntu1.3
<mlankhorst> so even fixing the synaptiks bugs left it uninstallable
<mlankhorst> which is why a second upload was needed
<arges> mlankhorst: ok i'll have to review this a bit later. can you just post the proper debdiffs to the bug to make it easier?
<arges> in case infinity wants to take a look at those
<arges> : )
<mlankhorst> they get autogenerated after upload :P
<arges> mlankhorst: still around?
<jdstrand> fyi, the cinder update is just what was in proposed with the patch for http://www.ubuntu.com/usn/usn-2248-1/
<jdstrand> fyi, uploaded a neutron update to trusty-proposed that has the corresponding fix for neutron that was in the earlier cinder update
<jdstrand> that's the one ^
<jdstrand> ok, I rejected the previous neutron and uploaded a new one
#ubuntu-release 2014-06-19
<mlankhorst> ok back :p
<bdmurray> infinity: could you review libtar for me?
<shadeslayer> could someone reject kde-workspace from trusty unapproved?
<bdmurray> shadeslayer: doing so
<shadeslayer> bdmurray: thx
<shadeslayer> uploaded the fixed package
<shadeslayer> oh
<shadeslayer> ScottK: ^^ kde-workspace uploaded
<cjwatson> shadeslayer: since you've been asking - the livefs stuff is landed on Launchpad trunk now and is looking pretty good, so I'm optimistic that we'll have an initial production rollout next week
<cjwatson> doing it on Friday would probably be a bit cavalier
<shadeslayer> I noticed :)
<shadeslayer> hehe
<shadeslayer> cjwatson: btw from what I've understood, using the LP derivative distro will make a entire archive fork ?
<cjwatson> I ended up using the PPA code for testing (because I needed a hacked live-build), so maybe I can get some ops time to debug that
<cjwatson> shadeslayer: partial
<cjwatson> s/debug/deploy/
<cjwatson> buildd deployments are rather more fragile and time-consuming for ops at the moment sadly
<shadeslayer> cjwatson: so, we specify which packages to fork then?
<cjwatson> but we'll see
<shadeslayer> *nod*
<cjwatson> shadeslayer: something like that.  I don't think it will be ready for casual use for quite a while ...
<shadeslayer> cjwatson: I mostly need it for Kubuntu Next ISO's
<cjwatson> yeah, don't hold your breath
<cjwatson> I would expect a PPA to be better for your use case anyway?
<shadeslayer> I see, then we'll have to figure out how to do those with PPA's
<shadeslayer> yep, however, I was more interested in the ISO side of those
<cjwatson> I dunno, maybe it will be possible with derived distros, but the target is to get them working for a single target for August and that target doesn't require anything complicated on the cdimage side
<cjwatson> whereas Kubuntu likely would
<cjwatson> so would need to discuss the exact requirements in a bit more detail I think
<shadeslayer> mhm, should I email Ubuntu devel with our requirements next week then? because plasma 5 is going to be out in a few weeks, and it would be awesome to have a ISO to go along with it
<cjwatson> I'm also kind of wary of derived distros being used for more than stabilisation branches, as it would be very easy to end up with fragmentation
<shadeslayer> I could hack around things and use ubuntu-defaults-builder and what not, but I don't know how to setup the UEFI side of things
<cjwatson> right, you absolutely will not have derived distros in a few weeks
<cjwatson> so sure, details please :)
<shadeslayer> ok, will send details to ubuntu-devel next week :)
<shadeslayer> if that's the right place to discuss this
<cjwatson> will probably need some work on the cdimage side to mirror additional PPAs
<cjwatson> maybe ubuntu-release, but whichever
<shadeslayer> well, it'll be just the one
<cjwatson> yeah but I'm not writing special-case code for this, if I write it it'll be generic so I don't have to rewrite it later :)
<shadeslayer> fair enough :)
<cjwatson> trying to make sure that new classes of configuration I add to cdimage are table-driven
<cjwatson> one thing that's important to know is the scope of the PPA
<cjwatson> in particular it would be helpful to have a guarantee that it will not touch things in the debootstrap set
<cjwatson> ('cos debootstrap isn't much good at multi-archive bootstrapping)
<cjwatson> if it's just the UI layer, and you're happy to deal with the utopic archive moving along under you, then a PPA should work
<shadeslayer> I highly doubt it'll touch things in the debootstrap layer
<shadeslayer> **maybe** some library like poppler, or stuff, but I highly doubt we'll touch things in debootstrap
<stgraber> cjwatson: the only problem is if the PPA contains extra packages (not in archive) which they need in the debootstrap set, correct? anything else, we debootstrap from the release pocket + dist-upgrade the chroot with all the right sources afterwards which should take care of any version bump for packages in the debootstrap set.
<stgraber> or am I missing something?
<cjwatson> or removals.  but possibly, yeah
<cjwatson> still, I'd be more comfortable if that were excluded
<cjwatson> it's complex enough as it is :)
<stgraber> yeah, I just assumed we already had that kind of logic since it's not uncommon for us to push debootstrap-set packages into -updates post-release and then build point release isos including that (where we debootstrap from release pocket, setup sources.list and dist-upgrade afterwards).
<cjwatson> we might do, I'd just like for it not to be a requirement because it seems like a plausible source of difficulty
<cjwatson> and this is several thousand lines of brand new infrastructure code as it is
<cjwatson> https://dogfood.paddev.net/builders/  heh, LP is nice sometimes, I didn't explicitly put the [<archive>] bit there but it's absolutely right
<cjwatson> ah yes, of course PackageBuildFormatterAPI does that
<DalekSec> Howdy!  With the latest upload of darkice, we have eliminated the rest of the Ubuntu delta, can you sync it (or do I need to make a formal sync request?)
<cjwatson> that's self-service by uploaders, we don't do that centrally any more
<cjwatson> if you have upload access, use syncpackage, otherwise, use requestsync
<cjwatson> assuming you have an Ubuntu system to run it from?
<cjwatson> actually, never mind, it's pretty clear, I'll switch to my uploader hat and do it
<cjwatson> done
<DalekSec> Sweet, thanks.  And no, I have no upload rights.
<DalekSec> (It was a simple one, yeah.)
<bdmurray> cjwatson: could you review libtar in trusty-proposed?
<cjwatson> looking
<cjwatson> bdmurray: do you want to fix the grievous misspelling of the patch author's name in the changelog? :)
<cjwatson> Magnus != Marcus, Holmgren != Holmgen
<cjwatson> rest of it looks ok ...
<bdmurray> cjwatson: wow, that'd be great or I can do it
<cjwatson> can I reject and have you fix the changelog?  I like to have people's names spelled right
<cjwatson> but I'll be around for a little bit longer to accept the second try
<bdmurray> cjwatson: sure, sounds good
<bdmurray> cjwatson: reuploaded
<cjwatson> bdmurray: thanks
<bdmurray> cjwatson: thank you for pointing it out
#ubuntu-release 2014-06-20
<infinity> ScottK / Riddell : Is someone on top of the trusty KDE SRUs that are making the queue unreadable? :)
<ScottK> infinity: Yes.  On my list for tomorrow.
<ScottK> (just off to sleep now)
<infinity> ScottK: \o/
<infinity> ScottK: Sleep well.
<ScottK> Thanks.
<cjwatson> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-core
<tseliot> hi, can an admin reject ubuntu-drivers-common from trusty-proposed, please? One of the bug reports that I listed in the changelog is wrong
<Laney> cjwatson: great
<Laney> is cdimage adjusted already?
<cjwatson> Laney: In progress
<Laney> if I click "Live filesystems" I get to a 404 :-)
<cjwatson> Laney: Or rather, the code is all done (that build was kicked off from cdimage), needs configuration
<cjwatson> Laney: hah.  bug please
<Laney> cjwatson: there you go, bug #1332479
<Laney> oh, botless
<tseliot> bdmurray: I've just reuploaded
<bdmurray> tseliot: ack, thanks
<tseliot> thanks to you
<tseliot> bdmurray: BTW nvidia-prime in precise-proposed ended up in NEW
<bdmurray> tseliot: okay
<zul> can someone accept python3-sure please
<slangasek> cjwatson, wgrant, infinity: hi!  So I see livefs-in-launchpad is marked as fix released \o/  Does that mean we're ready to turn on daily builds of trusty?
<slangasek> (or put differently: what remains to get this wired up from nusakan?)
<cjwatson> slangasek: I've wired it up for ubuntu-core already
<cjwatson> slangasek: For the rest, waiting for one more LP deployment on Monday to give me the ability to set the relevant livefs objects to devirt (since I don't really want to ask webops to manually configure 42 objects for me)
<cjwatson> slangasek: Also I'd rather be around to supervise it, and I'm leaving in 15 minutes :)
<slangasek> ack :)
<cjwatson> slangasek: ubuntu-touch is going to need ogra to fix a monitoring script of his, which he said he'd do in the next couple of days
<cjwatson> slangasek: Other than that I think we're basically all set
<ogra_> well, dont wait for me, i dont want to be a blocker
<cjwatson> slangasek: Oh, for stable builds it'll need one more launchpad-buildd deployment so that we can build from -proposed
<ogra_> i can also change it after the fact ... the imgbot is not overly important
<cjwatson> ogra_: We can easily configure everything except touch to build this way, but yeah, whatever
<cjwatson> I have the necessary config file staged locally
<cjwatson> slangasek: So yeah, it's all pretty good, happy day
<cjwatson> slangasek: I'll try to organise the launchpad-buildd deployment on Monday so that we can do trusty builds this way
<cjwatson> slangasek: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-core FWIW
<smoser> hi. could someone kill my trusty-proposed upload
<smoser> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=cloud-init
<smoser> i'd like to fix one other issue
<smoser> stgraber, or slangasek ^ ?
<stgraber> smoser: done
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/modify-email-creation/+merge/223977 could you merge that when you get a chance?
<bdmurray> stgraber: could you have a look at merging this? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/modify-email-creation/+merge/223977
<stgraber> bdmurray: done
<bdmurray> stgraber: thanks
<slangasek> bdmurray: whoops - sorry, I got sidetracked here :)
<bdmurray> slangasek: no problem, I remembered stgraber switched tzs for the day
#ubuntu-release 2014-06-21
<bluesabre> 3
<xnox> hm, interesting.
<xnox> slangasek: without a matching boost-mpi-source1.54 above will result in uninstallables in universe.
 * xnox goes to prepare it
<slangasek> xnox: ok, thanks
 * xnox mumble mumble archive reorg mumble =)
<xnox> thanks!
<slangasek> no rpob
<ScottK> xnox: That's not archive reorg's fault. Before we split the package, we just didn't provide the mpi packages at all.
<xnox> ScottK: I mean if archive reorg plans would be in place, we would not need to split source packages at all.
<ScottK> How so?
<xnox> https://wiki.ubuntu.com/ArchiveReorganisation/Components
<infinity> ScottK: One of the theories behind archive reorg (ie: flattening the components to free/non-free instead of {un,}supported-{non-}free is that we could let supported build-dep on unsupported and just mark binaries supported.
<infinity> ScottK: I'm less convinced this is actually a sensible way to declare things, since we probably want to support things we use to build things, but in a handwavy way, I get the intent.
<slangasek> we don't really want to support them; feel free to peruse http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html for some of the crazier stuff that doesn't actually matter to us except transitively and we shouldn't actually provide security support for
<infinity> slangasek: Well, we don't want to support everything, but we want to support a lot of things.  Means a lot more explicit seeding, I guess, for toolchains and things we actually really should support?
<infinity> But I can see, for instance, why we don't care about supporting things like aalib, except to make sure they're buildable.
<slangasek> build-essential is already seeded, and done ;)
<infinity> Which was what I meant by "handwavy"... We need to support a lot of things that are currently only transitively supported, but not necessarily all of it.
<infinity> slangasek: There's a lot more than build-essential that matters. :P
<infinity> slangasek: We don't seed most of X, for instance, cause it's all transitive.
<infinity> In fact, that's true of most libraries.
<infinity> And some we might not care about, but others, we really do.
<slangasek> we would seed the binary deps, not the source deps
<infinity> Err, right.  Sorry, X and libs are poor examples.
<infinity> But there are other toolchain bits that aren't build-essential.
<infinity> Anyhow, I get the theory.  Some day, it might be less of a theory.
<xnox> argh, why is lintian hanging in doing select, when executed under sbuild?!
<xnox> annoying.
<infinity> xnox: Probably trying to write to the controlling terminal, which sbuild doesn't provide.
<xnox> hm, but lintian hasn't changed recently, nor e.g. sbuild. i wonder if it's something else like a hook or some such.
#ubuntu-release 2014-06-22
<darkxst> so seb says we need RT approval for https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1330037
<darkxst> should I subscribe release team to that bug?
#ubuntu-release 2015-06-15
<micahg> for the libproj transition can we ignore mapnik, push the rest through to the release pocket and copy https://launchpad.net/ubuntu/+source/mapnik/2.2.0+ds1-7build3 with binaries to the release pocket?
<infinity> micahg: What have you got against the new mapnik?
<micahg> infinity: the twp reverse dependencies seem like not easy fixes, seems mapnik changed a lot
<micahg> oh, wait, I forgot, I had one more dep to fix for proj
<micahg> zygrib still needs to be fixed, I'll have to try another day though
<infinity> micahg: So, I can remove 3.x from proposed and copy build3 back in.  And then copy 3.0 back in later.
<infinity> micahg: But no point until you're sure the rest is ready to transition.
<micahg> infinity: ooh, that would work, ok, I'll ping you when I get the other piece sorted, will probably be later in the week I hope
<jamespage> ^^ that new source superceeds oslo.messaging; equiv in the NEW queue in Debian - but need to unblock into Ubuntu
<sbeattie> Not sure who's on SRU duty today, but I'd like to ask if the apparmor in trusty-proposed could be pushed to trusty-updates; everything verified okay except one bug (LP: #1296667) which doesn't introduce regressions, but was just not fixed properly.
<ubot93> Launchpad bug 1296667 in AppArmor "dovecot/apparmor: profile not found" [Undecided,New] https://launchpad.net/bugs/1296667
<sbeattie> The rest of the fixes address enough issues to warrent being accepted IMO. And I've posted a debdiff for the dovecot/apparmor bug that didn't get fixed and will work to push it through following the current package.
<infinity> sbeattie: Seems reasonable to me.
<sbeattie> infinity: thanks
<infinity> sbeattie: Erm, did that want to go to -security too, or just -updates?
<sbeattie> infinity: no, just updates.
<infinity> sbeattie: I noticed it was built in a security PPA after I released it to updates.
<infinity> sbeattie: Okay, cool.  Just updates it is, then.
<jdstrand> \o/
<sbeattie> no, it was just a place to build it before going into -proposed.
<sbeattie> infinity: thanks again!
<jdstrand> sbeattie: yay, yay!
<jdstrand> this is going to be great for trusty users
<infinity> sbeattie: Re-targeted that one bug to trusty, if you'd like to followup ASAP with the fix before you forget.
<sbeattie> infinity: thanks, yeah.
<infinity> jdstrand: While you're cheering this morning, I fixed LP: #1452238 that you escalated to my manager last week.
<ubot93> Launchpad bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Medium,Confirmed] https://launchpad.net/bugs/1452238
<jdstrand> infinity: woohoo!
 * jdstrand hugs infinity :)
 * jdstrand reads
<mdeslaur> infinity: heh, subtle :)
<infinity> mdeslaur: Yeah.  I mean, fundamentally, it's an apt bug, but dependency loops end up being an O(insane) problem for resolvers, so breaking them is much simpler than diving into the resolver.
<infinity> mdeslaur: And, in this case, both deps were entirely unnecessary cruft anyway.
<mdeslaur> infinity: I was referring to your comment, not to the bug :)
<mdeslaur> infinity: but yeah, that bug sucks
<infinity> mdeslaur: Oh.  See, it was a subtle bug, so your comment could go either way. :P
<mdeslaur> hehe
<robru> is anybody looking into http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src ? I heard something along the lines that all the regressions are false positives and this should be waved through, but I'm not clear on the details.
<ScottK> robru: Mirv was discussing it with Riddell earlier today.
<infinity> robru: I'm retrying a bunch of tests, but it would be nice to get KDE people to weigh in on the current state of their autopkgtesting.
<robru> ScottK: yeah, Mirv asked me to poke you guys later today since he had to EoD. any word on some progress there?
<infinity> ScottK: Oh, hi KDE person.
<robru> nice ;-)
<ScottK> Not on a (K)ubuntu box ATM.
#ubuntu-release 2015-06-16
<Mirv> infinity: Riddell seemed ok to override the packages and I gave him the list, but then neither him or Scott had time to do that http://irclogs.ubuntu.com/2015/06/15/%23kubuntu-devel.html#t18:45 - so that's the current status
<Mirv> I'm running Qt + KF5 + Plasma 5 from wily-proposed without issues
<infinity> Mirv: Which packages are you trying to get to migrate?
<infinity> Mirv: I won't override the KDE tests themselves, as that would cause the KDE packages to migrate, but I can force a pass on your packages if those tests are the only failing ones.
<Mirv> infinity: Qt, since that affects non-Kubuntu too. full list is http://pastebin.ubuntu.com/11723237/
<Mirv> infinity: plasma-framework and frameworkintegration are part of the Qt transition since they use private Qt symbols. they are no-change rebuilds.
<infinity> Mirv: Okay, some of those are waiting on broken boottests too.
<Mirv> infinity: doh, fginther tried to fix qtmir-gles/qtubuntu-gles, they shouldn't be doing what they are doing (trying to install x86 packages on arm)
<Mirv> he unblocked the previous uploads of those yesterday
<infinity> *raise brow*
<infinity> They're trying to do what now? :P
<infinity> Mirv: Do you have a pointer to any public debugging of this oddity?
<infinity> Mirv: Oh, lolz.  I see.  Those packages  don't even EXIST on ARM, so the phone boottest is totally irrelevant.  Check.
<infinity> Mirv: Okay, let me try to unwind the rest of this and see what I can do.
<Mirv> ok
<Mirv> and yes, they are hard to install on the phone :)
<infinity> Mirv: Yeah, I thought you meant it was trying to install the wrong arch's binaries, which would be super special, not that it was running tests for binaries that don't exist (which makes more sense).
<infinity> Mirv: So, when I parse the mess to start looking, this is what I get.  Care to verify the sanity of the list while I go looking at results for each to make sure this is reasonable?
<infinity> Mirv: http://paste.ubuntu.com/11723303/
<infinity> Mirv: Hrm, on second thought, you're going to get stuck in the KDE transition anyway, due to frameworkintegration.  If it needs to migrate.  We'll see.
<Mirv> infinity: the list looks sane. and yes, it seems even though plasma-framework is already in release pocket (the one before this rebuild), frameworkintegration in release pocket is the previous version. the old frameworkintegration depends on qtbase-abi-5-4-1 which would be going away with this Qt in favor of qtbase-abi-5-4-2
<Mirv> so frameworkintegration 5.10.0-0ubuntu2 is needed too
<infinity> Mirv: Alright, that could get messy.  We'll see.
<infinity> Mirv: Maybe letting KDE migrate despite their broken tests will actually be easier, except it might be caught in the nettle transition.  Not sure how much I feel like playing at midnight, but I'll look some.
<Mirv> it might be that letting just frameworkintegration 5.10.0 through (and the plasma-framework 5.10.0 rebuild) would be enough. to me it'd look like packages depending on src:frameworkintegration would be fine with newer version too
<Mirv> and frameworkintegration itself apparently is ok with older versions of kconfigwidgets and kiconthemes that are considered dependencies at update excuses
<infinity> Mirv: If britney considers them deps, it's because of versioned deps...
<infinity> Mirv: Or versioned build-deps.
<infinity> Looks like it's the latter.
<Mirv> ah.. it seems the dependency chain stops at kconfigwidgets and kiconthemes but then you'd be already in KDE territory
<infinity> I'm okay with letthing those two pass and then letting the KDE folks sort the rest later.
<infinity> But no guarantees that nettle wasn't in there somewhere too.  I guess we'll find out.
<Mirv> oh the same that was with CMake? uh..
<infinity> Mirv: Yeah, the nettle transition is still two fixes short of being done, and I was busy all day with kernel security madness. :/
<infinity> Mirv: Looks like you win, your packages migrated.
<infinity> Mirv: But britney made an uninstallability trade to make it happen.
<infinity> Newly uninstallable packages in testing:
<infinity>     * amd64: kwin, kwin-addons, kwin-dbg, kwin-dev, oem-config-kde, ubiquity-frontend-kde
<infinity> Mirv: Any chance you could double-check that once the mirrors have caught up and see why?
<infinity> Mirv: Ahh, looks like kwin depends on qtbase-abi-5-4-1
<infinity> Mirv: You missed it in your transition, I guess?
<infinity> Mirv: Ahh, it got superseded, so your rebuilt one never made it.
<infinity> Mirv: A fresh -0ubuntu3 build would be appreciated.  I can do that.
<infinity> Mirv: Done.
<infinity> cjwatson: Really unconvinced about britney's uninst trades being a good thing.
<Mirv> infinity: !! hugely thanks, and I'm almost surprised it was even possible
<Mirv> infinity: but regarding kwin, it seems there was a never git snapshot that then was deleted, so what could be done since I already uploaded ubuntu2?
<Mirv> infinity: oh...
<Mirv> infinity: there was also deleted ubuntu2...
<Mirv> infinity: ok, thanks for the ubuntu3, I "uploaded" ubuntu2 yesterday via train and somehow the train didn't complain because the archive ubuntu2 was deleted...
<infinity> Mirv: It would have been rejected.  The train might fail miserably at rejects, since the emails go to la-la-land. :/
<infinity> Mirv: Okay.  kwin sorted.  Which, I think, fixed a bunch of autopkgtests too.  Including the ones you wanted to skip. :P
<infinity> Mirv: So, there's a lesson not to ignore tests...
<cjwatson> infinity: If you ever figure out how to make it not do that in a way that doesn't entirely kill performance, be my guest
<infinity> cjwatson: Oh, I thought it might just be a toggle, and it would magically stop.  No such luck, I guess? :P
<infinity> cjwatson: Of course, I guess the ideal way to toggle it off is to get to 0 uninst, so it has nothing to swap.
<cjwatson> infinity: britney keeps a count of uninstallables at various stages, and just compares the number.  It'd have to keep track of much more involved data structures in order to avoid swaps.
<cjwatson> infinity: Right, that's more or less been my conclusion when looking at this in the past. :-/
<infinity> cjwatson: Ahh, so it's an O(shit) problem.
<Mirv> infinity: yes it seems the kdeplasma-addons was because of kwin and not like the other kf5 failures that had actual unit test failures
<infinity> Mirv: rocs started passing too.
<infinity> Mirv: Anyhow, whatever.  Live and learn.  Be more careful next time, blah blah.  It's all happy now, looks like.
<Mirv> infinity: correct, rocs was also like that, started failing on i386 only now while it used to pass before. interestingly I don't see the passing run in jenkins.
<infinity> Mirv: Oh, huh.  I don't either.  That might be a weird bug. :P
<flexiondotorg> Laney, infinity I've seen this https://lists.ubuntu.com/archives/ubuntu-release/2015-June/003285.html
<flexiondotorg> Laney, infinity And had a chat with the Xubuntu team.
<flexiondotorg> Laney, infinity I have no idea what some of those tasks actually entail. Can give me a brief idea of what assistance is required?
<flexiondotorg> I've agreed to work with the Xubuntu team but if I can muster the help I would be interested in making an Alpha 1 and Alpha 2 release.
<flexiondotorg> I just need to understand if I can actually commit the time.
<Laney> Find out who wants to participate. Make sure they do their testing in time and update the ISO tracker. Send a release announcement.
<Laney> (If it's me doing the other side then I'll want to be released by 18:00 UK time on the Thursday)
<flexiondotorg> Laney, I can commit to doing the testing and updating the iso tracker in the time required.
<flexiondotorg> Laney, Is that all is required from a flavour? Is there anything else that needs to be done?
<Laney> flexiondotorg: You don't have to do it all yourself, just make sure that everyone is marked ready at the appropriate time.
<Laney> I think that's all.
<flexiondotorg> Laney, well I have a few people who help with the testing and know how the ISO tracker works.
<flexiondotorg> Laney, So if Ubuntu MATE would like a 15.10 Alpha 1 do I just need to enter myself as QA Contact?
<flexiondotorg> Laney, Basically, given that Ubuntu MATE is still fresh into Ubuntu and I am introducing MATE 1.10 this cycle I really need some test releases to feel confident I've not busted everything horribly.
<Laney> What we need is someone to do the things I outlined, which are for *all* flavours participating in the milestone.
<Laney> Flavours always do their own QA
<flexiondotorg> Laney, right understood.
<flexiondotorg> So this is an all or nothing situation?
<Laney> I don't think it is much work
<Laney> Mail ubuntu-release the week before to see who wants in, then on the Wednesday and Thursday morning see who is left to mark as ready and find out how far off they are. Then after the engineer pushes out the images you can send a release announcement to ubuntu-devel-announce.
<Laney> But yes, we need someone to volunteer. Last cycle wxl gave a hand - he could probably brief/reassure you.
<Laney> (Also note that stgraber has already volunteered for Alpha 1 so that is covered.)
<tedg> I can't figure out which seed results in this manifest: http://cdimage.ubuntu.com/ubuntu-core/releases/15.04/release/ubuntu-core-15.04-core-amd64.manifest
<tedg> It seems like it should be obvious, but I am yet confused.
<tedg> Can someone give me a couple pointers there?
<davmor2> tedg: ââ are those any use?
 * tedg tries dereferencing them
<slangasek> tedg: it's the ubuntu.vivid 'system-image' seed.  The mapping of image names to seeds lies in the arcana of livecd-rootfs.
<tedg> Ah, okay. So what is "core-libs" and "core-libs-devel" ?
<ogra_> slangasek, there doesnt seem to be a metapackage for this though
<slangasek> tedg: "SDK", basically
<ogra_> (which makes changing anything in the PPA a bit tricky ... as we would usually do that manually in -meta in case we change something for a released release)
<tedg> How can it be an SDK if those libs aren't included in the system image itself?
<slangasek> tedg: I'm not sure that the core-libs* aren't completely obsolete
<tedg> Okay, that would perhaps explain how I can't find relationships with them to other stuff :-)
<tedg> (and a lot of my confusion)
<tedg> So system image requires "boot" but not "required" or "minimal"
<tedg> That's confusing.
<arges> can another SRU memeber accept qemu in trusty?
<bzoltan> tedg:  is there any desktop application on the system image what would use the UITK? I remember about two years ago it was an issue that the whole Qt stack did not fit to the image... but by then the KUbuntu used 4.8 and we used 5.0. Now we are in sync.
<tedg> bzoltan, Not on system image, there is now GUI stuff there.
<tedg> bzoltan, Do you mean the touch image?
<tedg> But, really, long term. I wouldn't expect that the UITK to be on any image, it should be included by the apps that use it.
<bzoltan> tedg: yeps, i agree
<wxl> Laney: flexiondotorg: happy to help. not sure i can dedicate my own time, unfortunately, as i'll be travelling.
#ubuntu-release 2015-06-17
<flexiondotorg> stgraber, I would like to have an 15.10 Alpha 1 for Ubuntu MATE. I am not clear what I need to do in order to make that happen.
<flexiondotorg> stgraber, I have people ready to do test and update the ISO Tracker for Ubuntu MATE. But I an unclear if all flavours need to participate in Alpha 1 or if Ubuntu MATE can go it alone?
<infinity> flexiondotorg: It's up to each flavour if they want to participate.  Responding to his mail on ubuntu-release@lists would be nice.
<cjwatson> y
<cjwatson> sigh
<stgraber> turning off rebuild-requests to look into Laney's problem
<stgraber> Laney: so it's currently running:
<stgraber> ARCHES=amd64 i386 armhf DIST=wily for-project ubuntu-desktop-next cron.daily-preinstalled --live
<stgraber> so the problem is the sub-project
<stgraber> SUB_PROJECT=system-image ARCHES=amd64 i386 armhf DIST=wily for-project ubuntu-desktop-next/system-image cron.daily-preinstalled --live
<stgraber> Laney: that should do the trick ^ cron re-enabled
<Laney> stgraber: did you test it?
<Laney> cron runs: SUBPROJECT=system-image for-project ubuntu-desktop-next cron.daily-preinstalled --live
<ogra_> Laney, how do you make your changes to cdimage usually ?
<ogra_> ah, other channel
<Laney> commit, push, bzr up/pull
<stgraber> Laney: oh yeah, looks like I messed up, kinda odd I didn't get a failure mail
<stgraber> Laney: fixing
<Laney> thanks!
<stgraber> that looks better. Build running now
<Laney> great
#ubuntu-release 2015-06-18
<sil2100> Hello! I'll disable the nusakan s-i importer for a short while, should be back in a few minutes
<sil2100> And it's re-enabled again
<jdstrand> arges: hey, so I copied over apparmor 2.8.95~2430-0ubuntu5.3 to trusty-proposed for sbeattie for bug #1296667 and it was autoaccepted. I didn't mean to step on the sru team's toes. sorry
<ubot93> bug 1296667 in apparmor (Ubuntu Trusty) "dovecot/apparmor: profile not found" [High,In progress] https://launchpad.net/bugs/1296667
<arges> jdstrand: this bug is a bit confusing... so 5.3 was verfication failed, but comment #8 says the package was moved to -updates... but hten you just put 5.3 into -proposed : )
<jdstrand> I will let sbeattie comment
<sbeattie> arges: no, 5.2 failed verification. 5.3 is what should address it.
<arges> sbeattie: ok launchpad munged the tag change to the comment containing the 5.3 patch, which is why I was confused
<arges> sbeattie: the patch seems reasonable fwiw, so probably all that's needed is a reminder saying 'please verify this'
<sbeattie> arges: thanks!
<bdmurray> infinity: I ran across this report the other day http://people.canonical.com/~ubuntu-archive/testing/vivid_probs.html and noticed there isn't one for wily at all.
<infinity> bdmurray: That seems like it might be a bug.
<bdmurray> infinity: a bug in what though?
<infinity> bdmurray: The magic on snakefruit.
<infinity> Huh.  It's totally running, but the results are never making it to public_html.
<infinity> bdmurray: Bah.  And now I know why.  outdate-report is crashing.
 * infinity comments it out for now, and will investigate later.
#ubuntu-release 2015-06-19
<mdeslaur> infinity: can you push gnutls28 out of -proposed? the ffmpeg failure looks unrelated
<infinity> mdeslaur: No.
<mdeslaur> infinity: but mom promised!
<mdeslaur> infinity: seriously, what's missing?
<infinity> mdeslaur: It's part of the nettle transition, which is waiting on gst-plugins-bad1.0 and lsh-utils being happy.
<infinity> mdeslaur: slangasek's got an MP to fix the former, if you feel like bending your brain at the latter, it won't hurt my feelings.
<Laney> It's blocked on platform-api being broken
<Laney> (gst)
<mdeslaur> infinity: ah, I see, thanks
<infinity> Laney: I know.
<Laney> Great!
<wxl> stgraber: do you really intend to do everything for alpha1 or do you need help? i'm pretty slammed and i don't want to overbook myself, but if you need itâ¦
<stgraber> so what I'm planning to do is just dealing with setting things up on Monday, starting an announcement pad and be around on IRC if something goes wrong
<wxl> ok
<wxl> holler if you're desperate i guess :)
<wxl> ahoneybun has expressed interest in helping. he doesn't have the experience, but i'd be happy to help assist him.
<infinity> Self-accepting that no-change rebuild d-i.
#ubuntu-release 2015-06-20
<Logan> hmm, I wonder why that went into the queue
#ubuntu-release 2015-06-21
 * Logan pokes infinity with a long stick
<infinity> Logan: Ow.
<infinity> Logan: Why the stick-poking?
<Logan> infinity: any idea why my netbeans sync went into the queue?
<infinity> Logan: Because it was new?
<infinity> Logan: Looks like slangasek violently removed it from vivid.  So, yes, it's NEW in wily.
<Logan> oh oops, I didn't realize it was removed
<Logan> could you please approve the sync? :)
<infinity> Logan: No, but I'll accept that one ^
<Logan> :)
<shadeslayer> mmmm ... Debian sync :3
#ubuntu-release 2016-06-20
<LocutusOfBorg> please remove pepperflashplugin-nonfree[i386] following the same removal in debian, following the removal from google (upstream) of the deb
<mapreri> how can I confirm that scribus' SRU is fully phased out and will be in the next point releasE?
<mapreri> (i received an email back then that it was blocked because of a new crash appeared in errors.u.c, but I'm not sure if it's already unblocked or what
<mapreri> )
<LocutusOfBorg> link please
<mapreri> to what?
<LocutusOfBorg> errors page
<mapreri> https://errors.ubuntu.com/problem/296f63e4d068bd1e0cbcfbedef5e74e9ecfc524d
<LocutusOfBorg> sending the content privately
<mapreri> erm, I can't actually
<mapreri> ah,
<LocutusOfBorg> I am sending you the content of the page
<mapreri> well, I *can* read the error :)
<mapreri> i don't know if that thing has been ignored and the phased continued, or what
<LocutusOfBorg> ohh, ok
<Laney> http://people.canonical.com/~ubuntu-archive/phased-updates.html
<Laney> AFAIK if it's not there and is in -updates then it's fully phased
<mapreri> Laney: ok.  I was a bit perplexed because even right after I received the email it was not on that list, and neither it was the day afterâ¦
<mapreri> (mail from June 8th
<mapreri> Laney: Thanks!
<infinity> xnox: ^-- For you.
<ginggs> hi infinity: would you have a look at the cacti SRU please?  also we are thinking of a bof/sprint for some fpc stuff http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/Week-of-Mon-20160613/001284.html
<mwhudson> my kingdom for someone to look at the yakkety NEW queue
<slangasek> mwhudson: tell me more about this kingdom
<slangasek> mwhudson: why does lintian report dev-pkg-without-shlib-symlink for libgolang-1.6-std1?
<mwhudson> slangasek: ah, because i forgot to update overrides i bet
<mwhudson> yes
<slangasek> but why does lintian say it's a dev package, at all?
<mwhudson> oh
<mwhudson> that is a good question
<slangasek> mwhudson: as this is precisely the new binary package in the queue, I think we need to get to the bottom of that before I'll accept this into the archive
<mwhudson> is it just lintian being strange and reporting it against the lib package rather than the -dev package?
<slangasek> don't know
<slangasek> if I run lintian against the individual .debs, the warning isn't reported for either
 * mwhudson reads some perl
<slangasek> if I run it against the amd64.changes, it tags it on libstd1
<mwhudson> lintian is definitely looking at the pair of packages together
<mwhudson> and in a sense, the warning is perfectly valid
<mwhudson> there is no symlink
<mwhudson> or at least, not where lintian expects it
<mwhudson> but that's because the go linker does not look for files in the same places as the system linker
<slangasek> ok
<slangasek> yeah if I pass those two packages to lintian together on the commandline the warning comes back
<mwhudson> so once all this stuff is bedded down, i should make some lintian changes around go shared libraries
<mwhudson> i actually have a trello card about this already :-)
<slangasek> mwhudson: packages accepted; does your kingdom have a swimming pool?
<mwhudson> slangasek: thanks
<tsimonq2> the Lubuntu images aren't being generated
<mwhudson> slangasek: only wellington harbour and it's a bit cold at this time of year
<tsimonq2> the directory is being created for the daily images, just not being populated
<tsimonq2> could somebody look into this?
<mwhudson> slangasek: there is going to be a steady drip of golang shared lib NEW queue things i guess
<mwhudson> slangasek: also aren't you on leave today? :)
<slangasek> mwhudson: I am, which means you won't have me to hand for the next bit of NEW processing ;)
<mwhudson> well there are 10 or so packages that i can do this for and as i should actually read the debdiffs properly and write proper descriptions for the archive, i'll probably be ok for a while :)
<infinity> tsimonq2: Fixing.
<infinity> tsimonq2: Should be fixed for the next daily.
<tsimonq2> thank you infinity
<mwhudson> infinity: could you look at the xenial containerd/docker.io/runc srus pls? we'd like to get them done before dockercon which is soon
#ubuntu-release 2016-06-21
<RAOF> bdmurray: How does one override phased-update percentages when an SRU has been stopped by errors.ubuntu.com crashes?
<slangasek> RAOF: change-override -z
<RAOF> slangasek: That would not continue the gradual ramp up to 100%, correct?
<RAOF> For clarity: the crash that's stopped the phased-update appears to unrelated to the update, and is just a fairly rare crash that happened to be first seen (again) with the update.
<RAOF> (file-roller, crash is https://errors.ubuntu.com/problem/a595b32f105a3f7cb708c518855658d3e48eea2c )
<slangasek> RAOF: i don't recall if that causes the phasing to be picked up again or not; I think it does?
<RAOF> So, âchange-override -s xenial -z 100 file-rollerâ would appear to be the correct invocation.
<slangasek> to override and fully phase, yes
<RAOF> It hadn't got to fully-phased before being killed; phased-updates.html says it got to 30%. So perhaps a more correct invocation would be âchange-override -s xenial -z 30 file-rollerâ and then it will be picked back up and gradually phased to 100%?
<RAOF> Oooh. Or, in fact, not. Need -s xenial-updates rather than -s xenial!
<LocutusOfBorg> can anybody please remove mame on ppc64el? it has been removed in Debian, and should make it migrate
<mwhudson> can someone delete https://launchpad.net/ubuntu/+source/golang-defaults/2:1.6.1+1ubuntu2~ppa1 ?
<mwhudson> i've already uploaded a package with a non bogus version
<mwhudson> (the former mentioned package is in NEW)
<apw> mwhudson, ~ppa rejected
<apw> mwhudson, the source should be reaped in nbs once your new one is accepted
<bdmurray> RAOF: https://code.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides
<cyphermox> I'm curious, what do autopkgtests have access to? can they only reach the archive or could we also ship, say, a preseed file on people.c.c or people.u.c to script the install of a VM to do integration tests that require a BIOS implementation to be run?
<cyphermox> I'm thinking of an autopkgtest that could boot, install a VM, and drop some file in a specific location that could then be read from outside the VM to make sure it has booted with Secure Boot; for instance.
<cyphermox> well, really, boot and install a new VM, then reboot with the install (which would have to have installed the package to test), and then drop a file, or otherwise have some way of checking results
<cyphermox> AFAIK we can run VMs in an autopkgtest, the issue is whether a preseed might be reachable so that the install can be scripted.
<rbasak> AIUI that would work, but I don't think it's wise to add external dependencies like that unless there's really no other way. And even then I'm not convinced. In this case, can you serve the preseed from the host of the VM?
<cyphermox> rbasak: I suppose that could be done yes, it just increases the complexity of the test
<cyphermox> rbasak: I'm asking because I already do ship a bunch of preseeds that I use elsewhere, on p.c.c
<rbasak> cyphermox: it feels like they should be part of the test though, and not external. At the very least, store a copy of the preseeds inside the test and verify that the hosted ones are available and are identical. That might help someone avoid tearing hair out in future.
<rbasak> Verify before running the actual test, that is.
<rbasak> Also I'd get an ack from pitti or jibel or someone like that before proceeding.
<cyphermox> that was the point by asking here.
<rbasak> (I don't see pitti here)
<rbasak> Sure - I'm just pointing out that I don't consider myself a pitti or a jibel, if that isn't obvious :-)
<cyphermox> rbasak: well, your idea is not bad. making the preseed available from the test would be the best way to do it and it's not very complicated either as long as the networking for the VM happens correctly
<cyphermox> rbasak: http://paste.ubuntu.com/17649438/
<rbasak> cyphermox: that's just a bit evil :)
<rbasak> cyphermox: how about test-depending on apache2 and then just sticking the file into /var/www/html/? I think that should work.
<cyphermox> rbasak: I was kind of opting to make it as lean as possible
<cyphermox> but it looks like that will be necessary anyway, as I can't be bothered to otherwise clean up after that script
<rbasak> Why? I'd swing more towards minimal code + less chance of false positives.
<rbasak> If I upload an apache2 that breaks /var/www/html from working, that'll be my problem ;)
<cyphermox> rbasak: what do you mean by minimal code?
<cyphermox> you mean depending on apache2?
<rbasak> cyphermox: I just meant that I wouldn't write many lines of code to achieve correctness either. Not that either of us are suggesting it, just explaining my principle here.
<rbasak> But both of the options are minimal, so I favour the more correct one, at the cost of lean-ness in terms of test execution time.
<cyphermox> rbasak: right, I agree
<cyphermox> at least I can rely on service x start/service x stop to DTRT and not have to care about it.
<rbasak> Yeah. Also things like concurrent hits to the server.
<rbasak> Or a race while it loops round again.
<cyphermox> bah, it's not like this is really expecting to get many hits
<cyphermox> really, probably just once in the lifetime of a test.
<rbasak> I can't think of a real world failure case either, and if you look into the details you might be able to demonstrate that there isn't one.
<cyphermox> I don't care enough to bother ;)
<rbasak> But one day d-i will start doing a HEAD before the GET or something, and you'll hit the race. Not worth looking :)
<cyphermox> I was just thinking about whether it would be feasible to fully preseed a VM to DTRT here to test shim-signed or some other EFI blobs.
<rbasak> (and when that day comes, someone will spend time figuring out why and then will want to hit you with something. Worth avoiding :-)
<cyphermox> depends, it would likely be me wanting to hit myself over the head with something
<bdmurray> Trevinho: you'd asked about compiz entering -updates these two errors still seem like they are new issues with the new version of compiz.  https://errors.ubuntu.com/problem/a18b45b1acd6f9f0efe1c7533b04c92a5d830334 and https://errors.ubuntu.com/problem/7f28efb5fc498dcae25332fbdfdd56af6a47eb80
<Trevinho> bdmurray: hoestly I think these issues aren't unrelated to what the SRU changed
<bdmurray> Trevinho: you mean aren't related right?
<Trevinho> yeah, sorry bdmurray
<seb128> bdmurray, the file-roller issue should be cleared off as well
<bdmurray> slangasek, infinity: could you fully phase compiz for xenial?
<bdmurray> seb128: ack
<seb128> thanks
<bdmurray> seb128: should we create an LP bug for it though?
<seb128> bdmurray, you can, looks like that bug was already there in trusty and got some reports there, it might be worth trying to fix at some point
<bdmurray> seb128: okay, it doesn't seem as prevalent now though
<seb128> right, I think it's a pretty uncommon issue and not that important
<slangasek> bdmurray: compiz phasing done
<bdmurray> slangasek: thanks
<cyphermox> I validated a SRU earlier today by downloading a package manually from LP; it looks as though things aren't being published for precise-proposed --- I still haven't seen mokutil pop up there, and it should have become available in proposed a few hours ago already
<cyphermox> ie. timestamp for /ubuntu/dists/precise-proposed/main/binary-amd64/Packages.{bz2,gz} still has 2016-06-16 as a timestamp; I'm wondering if it's situation normal and it takes many hours for things to publish in the archive after they're cleared from Accepted; or if something is wrong, or if I'm looking at the wrong place
<bdmurray> cyphermox: I'm confused you said validated an SRU but also said precise-proposed.  I think validation would mean moving from -proposed to -updates.
<infinity> cyphermox: Hrm?  The mokutil in precise-proposed was published 5 hours ago.  In theory.
 * infinity looks.
<infinity> cyphermox: Oh.  But that landed in universe.  Should fix that.
<infinity> cyphermox: Moved to main for precise/trusty/wily.
<mwhudson> apw: thanks
<cyphermox> bdmurray: verifying; then, except I had to retrieve it straight from the launchpad build
<cyphermox> infinity: I was looking at both universe and main, neither seemed to list it
<bdmurray> cyphermox: Ah, I get it. To perform the validation you had get the package from Launchpad.
<cyphermox> yes
<cyphermox> and what I mean is that for instance, the timestamp on http://archive.ubuntu.com/ubuntu/dists/precise-proposed/InRelease looks off.
<infinity> cyphermox: Should be sorted as of the next mirror pulse (ie: it looks good on ftpmaster now)
 * infinity goes hunting for hamburgers.
<cyphermox> infinity: coolio, thanks
#ubuntu-release 2016-06-22
<mwhudson> slangasek: those multiarch-- packages in docker have all gone upstream
<slangasek> mwhudson: ah excellent
<mwhudson> slangasek: also i think it is "multiarch" as in "multiple architecture support" not the debian thing :-)
<mwhudson> slangasek: runc & containerd too?
<mwhudson> slangasek: also the golang-defaults in yakkety NEW would be great...
<Laney> Bah
<apw> that good huh?
<Laney> Please queue -Q unapproved -s xenial-proposed reject gst-plugins-bad1.0 gst-plugins-ugly1.0
 * Laney closed the wrong bug
<Laney> Probably need to include a message there, which can be "Laney sucks at closing bugs"
<apw> Laney, what about the other two?
<Laney> they seem to have the right bug
<Laney> it should be 1594407 not 1575152
<Laney> I guess that I copied and pasted the last merge changelog and didn't update the bug ref
<apw> ok cool
<Laney> whoopsie
<Laney> :)
<Laney> thanks apw!
<apw> Laney, double ugly ?
<Laney> i've heard that one before
<Laney> they seem to be identical
 * apw will bounce the second one then
<mwhudson> slangasek: can i get some more queued stuff released? runc from xenial UNAPPROVED, containerd from xenial NEW, golang-defaults from yakkety NEW
<flexiondotorg> infinity, Is there a plan for who is driving 16.10 Alpha1?
<flexiondotorg> infinity, Asking around Lubuntu and Ubuntu MATE are in. Kubuntu are out. Waiting on final confirmation from Xubuntu. Not heard from Ubuntu GNOME yet.
<flexiondotorg> infinity, Xubuntu are out.
<slangasek> mwhudson: remind me, was there an email thread somewhere documenting what we've signed off for an SRU plan for runc+containerd?
<mwhudson> slangasek: there was a thread about that (which i misunderstood at first), who is it who gets to "sign off"?
<slangasek> mwhudson: any member of the SRU team; I thought infinity had given sign-off but I want to double-check what he blessed to make sure I'm reviewing with the right glasses on
<mwhudson> slangasek: yeah, just found an email from infinity about this, let me read it more carefully :)
<mwhudson> slangasek: subject:"runc & containerd packaging (wrt new docker.io)"
<slangasek> thx, hunting
<mwhudson> slangasek: 28 may
<slangasek> yep, got it
<slangasek> "but with the same loose SRU policy for upstream version bumps" - ok, that's sufficiently clear :)
<slangasek> -libcontainer/criurpc/criurpc.pb.go
<slangasek> +#libcontainer/criurpc/criurpc.pb.go
<slangasek> the irony of this being in a diff to a file named "clean"
<mwhudson> heh yes
<slangasek> mwhudson: do I read this correctly that the new version of runc is regressing vs. the current xenial version wrt bundling of dependencies?
<mwhudson> slangasek: yes
<mwhudson> the current xenial version came from debian, we didn't touch it at all
<slangasek> ok, and this is actually consistent with the policy for docker.io also
<mwhudson> there is a crazy situation where docker vendors bits of containerd and containerd vendors bits of docker, etc
<mwhudson> slangasek: afk for a few
<slangasek> mwhudson: runc has rev builddeps in xenial: golang-github-fsouza-go-dockerclient, gosu.  Can you please include these in the test case on bug #1574904?
<ubot5> bug 1574904 in docker.io (Ubuntu Xenial) "Old clients cannot talk to Docker in 16.04" [High,Fix committed] https://launchpad.net/bugs/1574904
<mwhudson> slangasek: done
<mwhudson> slangasek: containerd?
<slangasek> mwhudson: accepted
<mwhudson> slangasek: thanks
<mwhudson> slangasek: can you accept the binaries too?
<slangasek> mwhudson: yes, getting there just now :)
<mwhudson> slangasek: thanks :)
<mwhudson> slangasek: and then golang-defaults in yakkety and i'll leave you alone for at least a day :)
<slangasek> dear lintian, please stop telling me that 'writeN' is a misspelling of 'written'
<nacc> heh
<mwhudson> slangasek: lintian definitely has a sense of humour
<slangasek> I: lintian: spelling-error-in-binary writeN rotten
<mwhudson> slangasek: thanks
#ubuntu-release 2016-06-23
<jbicha> could openssl be copied from xenial-security to yakkety please?
<rbasak> mdeslaur: see jbicha's request above. Should Xenial's openssl be copied forward to Yakkety?
<apw> i thought in general we were no longer meant to do that, because yakkety has a wildly diferent compiler
<apw> (not that this might not be a "yes but its important" moment)
<LocutusOfBorg> hi folks, since I have a *lot* of binarie to ask for removal, I thought about creating a bug report, and list them here with some rationale
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libpng/+bug/1595485
<ubot5> Launchpad bug 1595485 in libpng (Ubuntu) "packages to remove from yakkety" [Undecided,New]
<LocutusOfBorg> is it correctly filed? e.g. I subscribed ubuntu-archive, not sure if correct
<LocutusOfBorg> can anybody please ack/nack it?
<Ukikie> LocutusOfBorg: FWIW, re pepperflashplugin-nonfree: adobe-flashplugin contains pepper i386/amd64, so technically the package is not nearly as useful in Ubuntu.
<mdeslaur> jbicha, rbasak: I'll upload openssl to yakkety when I get back on monday
#ubuntu-release 2016-06-24
<flexiondotorg> infinity, Laney There were no new iso images built, for any flavour last night.
<flexiondotorg> I'd also requested an Ubuntu MATE rebuild yesterday which, from what I have access too, built a livefs but no iso materialised and the rebuild request is stuck in a rebuild state in the UI.
<flexiondotorg> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-mate
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/yakkety/daily-live-20160623.1.log
<infinity> flexiondotorg: We had a massive datacenter outage yesterday.
<infinity> Err... And cdimage is busted.
<infinity> flexiondotorg: Might be happier now.
<flexiondotorg> infinity, Thanks.
<apw> doko, did you intend that version to be ubuntu2.1 rather than 1.1 ?
<doko> apw, ahh, I can change that
<apw> doko, not looked at the diff just noticed the anomoly in queuebot output
<apw> doko, looking at the diff it looks more like a backport of yakkety's version, but whatever you normally do, do indeed
<doko> apw, yeah, the no-pie is a no-op for xenial, anyway, fixing the version ...
<doko> apw, fixed
<flexiondotorg> An Ubuntu MATE rebuild request is stuck in that state.
<flexiondotorg> Seems to be caused by a failed sync lock request.
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/yakkety/daily-live-20160624.log
<cjwatson> bdmurray: can you have a look at the dpkg/trusty crash rate increase?  I don't *think* it can possibly be related to my SRU, but I can't see the crash reports (errors.ubuntu.com says "Sorry, you are not a member of a group that is allowed to see the data from error reports" which has got to be nonsense)
<apw> ^ clashing upload of dkms
<jbicha> hi, nacc and I would like to upgrade the drupal7 xenial proposed sru to that one ^
<cjwatson> bdmurray: thanks for giving me access.  So I think this must be https://errors.ubuntu.com/oops/2d0a3dda-39a8-11e6-ba18-fa163eec78fa, but I don't think that can be related to the update as if it were I'd have seen it when upgrading the package to do QA; it's probably just somebody with a slightly broken perl installation for some reason.  Could you override this?
<slangasek> hmm so apparently nusakan's archive sync lock doesn't do well in the face of a system reboot?
<infinity> slangasek: Oh, did that asplode?
<slangasek> seems so
<slangasek> lock cleared now
<infinity> slangasek: PS: I'm home.
<yofel> could someone please review kinit in xenial-proposed? It's a CVE fix
<yofel> * in unapproved
<infinity> yofel: If it's a security fix, it should go through the security team, not the SRU queue.
<infinity> mdeslaur: ^
<yofel> even for universe components?
<infinity> yofel: Yes.  We still want security updates to be in the security pocket.
<yofel> ok
<infinity> yofel: The Canonical security team is happy to usher community security updates through their process.
<infinity> sbeattie: Around still? ^
<sbeattie> infinity, yofel: I am
<sbeattie> yofel: is there a bug report? Happy to sponser a security update.
<infinity> LP: #1595507
<ubot5> Launchpad bug 1595507 in kinit (Ubuntu Xenial) "World readable X11 Cookie key logger" [High,In progress] https://launchpad.net/bugs/1595507
<infinity> sbeattie: There's a rejected upload in https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text= if you can read that.
<sbeattie> infinity: I can, thanks
#ubuntu-release 2016-06-25
<flexiondotorg> infinity, Ubuntu, Kubuntu and Ubuntu MATE haven't published a new daily iso for several days.
<flexiondotorg> livefs is successfully building.
<flexiondotorg> But the following error is being thrown - File "/srv/cdimage.ubuntu.com/ubuntu-archive-tools/qatracker.py", line 427, in __init__
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/yakkety/daily-live-20160625.log
<flocculant> flexiondotorg: could be worse - tracker might be up and you want people to test AND report ;)
<flexiondotorg> Or this error.
<flexiondotorg> CalledProcessError: Command '['lockfile', '-r', '4', '/srv/cdimage.ubuntu.com/etc/.lock-archive-sync']' returned non-zero exit status 73
<flexiondotorg> flocculant, That was going to be my next thing :-)
<flocculant> fwiw - we didn't build yesterday - but did today :)
<flexiondotorg> I want to get some testing done.
<flexiondotorg> flocculant, Yes, odd that Xubuntu automatically built.
<flocculant> flocculant: I've mentioned trackers in sysadmin channel - nothing in the topic there though about downs
<flexiondotorg> But none others did.
<flocculant> we're special :D
<flexiondotorg> Can you sprinkle some special dust in my direction please? ;-)
<flocculant> :)
<flocculant> I guess you're A1'ing next week
<infinity> flexiondotorg: I'll look after I finish waking up and breakfasting and whatever else people do on Saturday morning.
<infinity> Disabling cdimage crontab entirely to let nusakan quiet down before I go cleaning up and making it happy again.
<slangase`> infinity: what is it that's unhappy? I haven't managed to interpret the emails
<slangasek> 'connection reset by peer' doesn't look like a local problem
<ogra_> looks like some connection issue
<ogra_> (with the iso tracker apparently)
<infinity> slangasek: iso.qa was busted.
<infinity> slangasek: But now that that's fixed, I want to make sure cdimage is in general not pooping itself.  Then I'll reinstate the crontab.
<slangasek> ok
<infinity> Alright, cdimage crontab back in place, world back on full auto.
#ubuntu-release 2017-06-19
-queuebot:#ubuntu-release- New binary: python-raven [amd64] (artful-proposed/universe) [6.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [ppc64el] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [amd64] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [i386] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [arm64] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [armhf] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpcd-ui [s390x] (artful-proposed/universe) [0.7.5-0ubuntu2] (no packageset)
<LocutusOfBorg> hello, autoimport broken?
<LocutusOfBorg> or disabled?
<tsimonq2> I was sort of wondering about that in the back of my head too.
<tsimonq2> LocutusOfBorg: I wouldn't be surprised if it was disabled, to be honest.
<LocutusOfBorg> why? because of debian? well, it has to start again, we are not in freeze yet
<LocutusOfBorg> not even alpha1
<LocutusOfBorg> tsimonq2, even syncpackage manually is not working, so I really suspect LP didn't survive to the Stretch-release joy
<LocutusOfBorg> or Buster birth, FWIW
<tsimonq2> LocutusOfBorg: Yeah, that's why I'm thinking something broke or someone was expecting something to break so they turned it off.
<tsimonq2> LocutusOfBorg: Because Stretch is released and Buster is a thing now <3
<cjwatson> tsimonq2: so you seem to be reporting general problems here but no specifics.  do you have an example of a package that should have been imported but isn't?
<tsimonq2> cjwatson: That's a question for LocutusOfBorg. I don't have anything specific in mind, I'm just thinking that with something as major as a Debian release, something might happen.
<tsimonq2> LocutusOfBorg> tsimonq2, even syncpackage manually is not working, so I really suspect LP didn't survive to the Stretch-release joy
<cjwatson> Yeah but LocutusOfBorg never stays on IRC :P
<cjwatson> tsimonq2: Ah, right, it's because the stretch signing key was rotated.  I filed a ticket to upgrade our debian-archive-keyring package over the weekend but it hasn't been processed yet.
<tsimonq2> cjwatson: Murphy's Law. :P
 * tsimonq2 heads -> bed
 * cjwatson nags sysadmins
<LocutusOfBorg> sorry cjwatson :)
<LocutusOfBorg> "Yeah but LocutusOfBorg never stays on IRC :P" you are right, I have to switch network
<LocutusOfBorg> I can say: gdcm, libpng1.6
<LocutusOfBorg> websocketpp
<LocutusOfBorg> hedgewars borgbackup poedit  udiskie unittest++ papyrus
<LocutusOfBorg> but I'm quite sure there are more
<LocutusOfBorg> oh I see you already answered, bad slow monday
<LocutusOfBorg> thanks!!!
<cjwatson> it will hopefully be sorted out in an hour or two when the cron job next runs.
<LocutusOfBorg> no problem, releasing on saturday is really a bad timing indeed :)
<cjwatson> I actually had a todo card from some time ago to update the keyring package, but when I created the card for myself it wasn't yet in unstable and I didn't check back until just before release.
 * LocutusOfBorg leaves, waiting for the big import
<LocutusOfBorg> ta
<LocutusOfBorg> still nothing, meh :)
<LocutusOfBorg> I'll move to some debian work then :D
<cjwatson> LocutusOfBorg: The import worked fine
<LocutusOfBorg> mmm I can't see packages updated...
<LocutusOfBorg> syncpackage gdcm
<LocutusOfBorg> syncpackage: Error: Debian version 2.6.8-1 has not been picked up by LP yet. Please try again later.
<LocutusOfBorg> e.g. https://launchpad.net/debian/+source/gdcm still shows the old one
<cjwatson> hm yes maybe there is still something wrong
<LocutusOfBorg> as long as you are aware with it, I'm fine :)
<LocutusOfBorg> BTW, what about adding a link to the debian PTS? sometimes I reach LP by following Debian link, but the other way would be awesome too
<LocutusOfBorg> is it worth a bug?
<cjwatson> oh, right, it's just that the mirror run took longer than usual so it finished after gina (the actual import bit) started
<cjwatson> so it should catch up with the next run in ~5 hours
<cjwatson> in general LP doesn't do very good linking to external sources at the moment.  you can file a bug but it's unlikely to be done any time soon
<LocutusOfBorg> I don't like filing bugs if nobody plans to look at them :) thanks!
<rbasak> IMHO, it's nevertheless useful to document defects and missing features so they get prioritised over time - for example with the count of the number of users affected if nothing else.
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (zesty-proposed) [0.1.0~bzr505-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (yakkety-proposed) [0.1.0~bzr505-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.20 => 1.2.24] (core)
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3.5 => 1.3.9] (core)
-queuebot:#ubuntu-release- Unapproved: apt (zesty-proposed/main) [1.4 => 1.4.6~17.04.1] (core)
-queuebot:#ubuntu-release- New binary: hunspell [ppc64el] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hunspell [s390x] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hunspell [amd64] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hunspell [i386] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hunspell [arm64] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hunspell [armhf] (artful-proposed/main) [1.6.1-1] (kubuntu, ubuntu-desktop)
<slashd> sil2100, good day, as per our last week conversation with Mmike, could you please make "percona-xtradb-cluster-5.5" go away from -proposed since the fix isn't ready for 5.6. This will unblock Mmike for another percona-xtradb-cluster-5.5 SRU only affect affecting Trusty.
<sil2100> slashd: sure thing
<slashd> sil2100, thanks
<slashd> Mmike, ^^
<Mmike> ack!
<Mmike> thnx slashd, sil2100
<sil2100> Ok, looking at that now
<slashd> sil2100, once removed, do you want us to update the case saying the package has been intentionally drop for now, until we fix 5.6 in later Ubuntu release ?
<sil2100> slashd: I'll leave a message on the bug I guess, since I'll be doing the package removal from -proposed
<slashd> sil2100, ok thanks again
<sil2100> slashd, Mmike: this should now be done, thanks and sorry for the bump-back on the fix! It's a bit frustrating sometimes, but I guess these rules make sense and save trouble in the future
<sil2100> You're good to go with further fixes for trusty
<Mmike> sil2100: thank you!
<sil2100> slashd, Mmike: that being said remember that the 14.04.3 version number is now 'burned' and you'd need to use .4 in your next upload
<Mmike> sil2100: whops, thnx for the heads up :D
<slashd> sil2100, ack
<acheronuk> why is vivid still supported?
<acheronuk> e.g. https://launchpad.net/ubuntu/+source/kubuntu-meta
<sil2100> acheronuk: there's still one Ubuntu-based 'commercial' product that needs to be supported out there
<acheronuk> sil2100: ok, thanks for that info. makes sense
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.5 (trusty-proposed/universe) [5.5.37-25.10+dfsg-0ubuntu0.14.04.2 => 5.5.37-25.10+dfsg-0ubuntu0.14.04.4] (no packageset)
<slashd> sil2100, I just uploaded it ^, can you take a look since you already know about the version bump, etc ...
<slashd> Mmike, ^^
<sil2100> slashd: o/ on it in a minute!
<slashd> sil2100, thanks
<slangasek> infinity: could I get a quick NEW review of yazpp?
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:0.4.17.2 => 1:0.4.17.3] (desktop-core, ubuntu-server)
<sil2100> slashd: accepted o/
-queuebot:#ubuntu-release- Unapproved: accepted percona-xtradb-cluster-5.5 [source] (trusty-proposed) [5.5.37-25.10+dfsg-0ubuntu0.14.04.4]
<slashd> sil2100, thanks much appreciated
<slashd> Mmike, ^^^
<sil2100> np!
<Mmike> sil2100++ <3 :* :D
<sil2100> ;p
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (trusty-proposed) [3.0~a57-1ubuntu11.4]
<infinity> slangasek: You can get a review; I make no promises on quickness.
-queuebot:#ubuntu-release- New: accepted hunspell [amd64] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted hunspell [armhf] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted hunspell [ppc64el] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-raven [amd64] (artful-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted hunspell [arm64] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted hunspell [s390x] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted hunspell [i386] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-81.104] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-56.61] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-81.104~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-56.61~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-24.28~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-56.61]
-queuebot:#ubuntu-release- New: accepted yazpp [amd64] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yazpp [armhf] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yazpp [ppc64el] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yazpp [arm64] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yazpp [s390x] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted yazpp [i386] (artful-proposed) [1.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-81.104~14.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-24.28] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-24.28~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-81.104]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-56.61~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-24.28]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-121.170] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-121.170]
-queuebot:#ubuntu-release- New binary: bear [ppc64el] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [ppc64el] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [amd64] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [s390x] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bear [armhf] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [i386] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bear [s390x] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [arm64] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bear [amd64] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bear [i386] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [armhf] (artful-proposed/universe) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [ppc64el] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bear [arm64] (artful-proposed/universe) [2.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [s390x] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [i386] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [amd64] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dash-el [amd64] (artful-proposed/universe) [2.13.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [arm64] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bareos [armhf] (artful-proposed/universe) [16.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: firejail [amd64] (artful-proposed/universe) [0.9.48-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debootstrap (zesty-proposed/main) [1.0.81ubuntu3.1 => 1.0.81ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (yakkety-proposed/main) [1.0.81ubuntu2.2 => 1.0.81ubuntu2.3] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.3 => 1.0.78+nmu1ubuntu1.4] (core)
<LocutusOfBorg> infinity, your hammer failed again for the old-known bug :)
<LocutusOfBorg> src: freedroidrpg
<LocutusOfBorg> has been kicked out from release and from proposed, and the old version copied instead
 * LocutusOfBorg please correct me if the analysis is wrong
-queuebot:#ubuntu-release- New binary: libvmime [ppc64el] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-prctl [ppc64el] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [ppc64el] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted python-os-traits [source] (artful-proposed) [0.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debootstrap (zesty-proposed/main) [1.0.81ubuntu3.1 => 1.0.81ubuntu3.2] (core)
-queuebot:#ubuntu-release- New binary: libvmime [s390x] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [s390x] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: osgearth [ppc64el] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-prctl [s390x] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [ppc64el] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [amd64] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libvmime [amd64] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [i386] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvmime [i386] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-87.95] (core, kernel)
-queuebot:#ubuntu-release- New binary: osgearth [s390x] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pydocstyle [amd64] (artful-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-prctl [i386] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-prctl [amd64] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: s-el [amd64] (artful-proposed/universe) [1.11.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [s390x] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [ppc64el] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-os-traits [amd64] (artful-proposed/none) [0.3.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [s390x] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
-queuebot:#ubuntu-release- New binary: osgearth [amd64] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: osgearth [i386] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [i386] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-87.95]
 * mapreri wonders how opencv came to be in the kubuntu packagesetâ¦
-queuebot:#ubuntu-release- New binary: opencv [amd64] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
<tsimonq2> mapreri: There are so many things in the Kubuntu packageset that probably don't need to be there.
<tsimonq2> For example, a lot of Unity 7 seemed to be in there :P
<valorie> what?
<tsimonq2> valorie: Yep
<valorie> show me
<tsimonq2> valorie: When I said "Unity 7" I meant what ships on that Unity 7 ISO: http://people.canonical.com/~ubuntu-archive/packagesets/artful/kubuntu
-queuebot:#ubuntu-release- New binary: qgis [i386] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
<valorie> can we discuss this in #kubuntu-devel please?
<tsimonq2> Sure, although I certainly didn't think this was anything new...
-queuebot:#ubuntu-release- New binary: opencv [i386] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted bareos [amd64] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bareos [armhf] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bareos [ppc64el] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bear [amd64] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bear [armhf] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bear [s390x] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bareos [arm64] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bareos [s390x] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bear [i386] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bareos [i386] (artful-proposed) [16.2.5-2]
-queuebot:#ubuntu-release- New: accepted bear [arm64] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bear [ppc64el] (artful-proposed) [2.3.5-2]
-queuebot:#ubuntu-release- New: accepted bmusb [arm64] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted bmusb [i386] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted bmusb [s390x] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted firejail [amd64] (artful-proposed) [0.9.48-2]
-queuebot:#ubuntu-release- New: accepted libvmime [i386] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted libvmime [s390x] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted bmusb [amd64] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted bmusb [ppc64el] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted libvmime [amd64] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted bmusb [armhf] (artful-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted libvmime [ppc64el] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dash-el [amd64] (artful-proposed) [2.13.0+dfsg-2]
-queuebot:#ubuntu-release- New binary: libvmime [armhf] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvmime [arm64] (artful-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [arm64] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-prctl [arm64] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: movit [armhf] (artful-proposed/universe) [1.5.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-prctl [armhf] (artful-proposed/universe) [1.6.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (zesty-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu1~17.04] (core)
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (yakkety-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu1~16.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected powerpc-utils [source] (yakkety-proposed) [1.3.2-1ubuntu1~16.10]
-queuebot:#ubuntu-release- Unapproved: rejected powerpc-utils [source] (zesty-proposed) [1.3.2-1ubuntu1~17.04]
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (zesty-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu2~17.10] (core)
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (yakkety-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu2~16.10] (core)
-queuebot:#ubuntu-release- New binary: sfcgal [armhf] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: osgearth [arm64] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: osgearth [armhf] (artful-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [arm64] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (artful-proposed/universe) [2.14.15+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected powerpc-utils [source] (yakkety-proposed) [1.3.2-1ubuntu2~16.10]
-queuebot:#ubuntu-release- Unapproved: rejected powerpc-utils [source] (zesty-proposed) [1.3.2-1ubuntu2~17.10]
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (yakkety-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu2~16.10] (core)
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (zesty-proposed/main) [1.3.2-1 => 1.3.2-1ubuntu2~17.04] (core)
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (xenial-proposed/main) [1.3.1-2ubuntu0.2 => 1.3.1-2ubuntu0.3] (core)
-queuebot:#ubuntu-release- New binary: opencv [armhf] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
-queuebot:#ubuntu-release- New binary: dash-functional-el [amd64] (artful-proposed/universe) [1.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyosmium [amd64] (artful-proposed/universe) [2.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [arm64] (artful-proposed/universe) [3.1.0+dfsg1-1~exp1] (kubuntu)
#ubuntu-release 2017-06-20
-queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.3 => 2.20.3-0ubuntu8.4] (core)
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.6 => 2.20.1-0ubuntu2.7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted powerpc-utils [source] (yakkety-proposed) [1.3.2-1ubuntu2~16.10]
-queuebot:#ubuntu-release- Unapproved: accepted powerpc-utils [source] (xenial-proposed) [1.3.1-2ubuntu0.3]
-queuebot:#ubuntu-release- New source: snapd-glib (trusty-proposed/primary) [1.12-0ubuntu1~14.04]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.2-0ubuntu1.1~xenial => 1.13-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (zesty-proposed/main) [1.9-0ubuntu1 => 1.13-0ubuntu0.17.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted movit [amd64] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted movit [armhf] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted movit [ppc64el] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted movit [arm64] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted movit [s390x] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted movit [i386] (artful-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted osgearth [amd64] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted osgearth [armhf] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted osgearth [ppc64el] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted osgearth [arm64] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted osgearth [s390x] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted osgearth [i386] (artful-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (artful-proposed) [2.14.15+dfsg-1]
-queuebot:#ubuntu-release- New: accepted opencv [amd64] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted opencv [armhf] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted opencv [ppc64el] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted opencv [arm64] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted opencv [s390x] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted opencv [i386] (artful-proposed) [3.1.0+dfsg1-1~exp1]
-queuebot:#ubuntu-release- New: accepted libvmime [arm64] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted libvmime [armhf] (artful-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted pydocstyle [amd64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-prctl [amd64] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted python-prctl [armhf] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted python-prctl [ppc64el] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted pyosmium [amd64] (artful-proposed) [2.12.3-1]
-queuebot:#ubuntu-release- New: accepted python-prctl [i386] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted python-prctl [arm64] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted python-prctl [s390x] (artful-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- New: accepted dash-functional-el [amd64] (artful-proposed) [1.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted s-el [amd64] (artful-proposed) [1.11.0-3]
-queuebot:#ubuntu-release- New binary: cvxopt [ppc64el] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvxopt [i386] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvxopt [s390x] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvxopt [amd64] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [s390x] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [ppc64el] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: open-coarrays [s390x] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cvxopt [armhf] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-coarrays [ppc64el] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cvxopt [arm64] (artful-proposed/universe) [1.1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [i386] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [amd64] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: open-coarrays [amd64] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [amd64] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cvxopt [amd64] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cvxopt [armhf] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cvxopt [ppc64el] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [amd64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [armhf] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [ppc64el] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted cvxopt [arm64] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cvxopt [s390x] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [i386] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted cvxopt [i386] (artful-proposed) [1.1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [s390x] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted sfcgal [arm64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New binary: open-coarrays [i386] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [s390x] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [ppc64el] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [amd64] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [arm64] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [i386] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [arm64] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcsfml [armhf] (artful-proposed/universe) [2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: open-coarrays [arm64] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [armhf] (artful-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: open-coarrays [armhf] (artful-proposed/universe) [1.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xtaci-kcp [amd64] (artful-proposed/universe) [3.15+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ublock-origin [amd64] (artful-proposed/universe) [1.12.4+dfsg-1] (no packageset)
<Ukikie> infinity: â Firefox addon.
-queuebot:#ubuntu-release- New binary: gnome-session [amd64] (artful-proposed/main) [3.24.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: texlive-extra [amd64] (artful-proposed/main) [2017.20170619-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted getdns [armhf] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [armhf] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New: accepted ublock-origin [amd64] (artful-proposed) [1.12.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xtaci-kcp [amd64] (artful-proposed) [3.15+ds-1]
-queuebot:#ubuntu-release- New: accepted texlive-extra [amd64] (artful-proposed) [2017.20170619-2]
-queuebot:#ubuntu-release- New: accepted getdns [amd64] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted getdns [i386] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted getdns [s390x] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [arm64] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [i386] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [s390x] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [arm64] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [ppc64el] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New: accepted getdns [arm64] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [amd64] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [ppc64el] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [i386] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New: accepted getdns [ppc64el] (artful-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [amd64] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New: accepted libcsfml [armhf] (artful-proposed) [2.4-2]
-queuebot:#ubuntu-release- New: accepted open-coarrays [s390x] (artful-proposed) [1.9.0-2]
-queuebot:#ubuntu-release- New binary: otb [amd64] (artful-proposed/universe) [6.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [i386] (artful-proposed/universe) [6.0.0+dfsg-1] (no packageset)
<RAOF> Hm.
<RAOF> How do I override an autopkgtest failure for glbinding?
<RAOF> It fails on the new mesa, but that appears to be because gcc has added a new warning. (In code unrelated to the new mesa)
<apw> RAOF, so you are saying some other package than mesa is failing its tests because if gcc and mesa is getting blamed ?
<RAOF> apw: Correct.
<RAOF> Although with âofâ instead of âifâ :P
<apw> that does sound vaguely familiar.  i think in the past we have skiptest'd the equiv of mesa when all its other tests have passed
<RAOF> apw: Specifically, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/g/glbinding/20170620_030409_32ab3@/log.gz has lots of compile warnings of the form ânote: parameter passing for argument of type â__gnu_cxx::__normal_iterator<const double*, std::vector<double> >â will change in GCC 7.1â, apparently all in gtest code.
<apw> that sounds doubly familiar, there was even talk of fixing the warning i think
 * RAOF goes to collect ZoÃ«
<RAOF> Well, that would be lovely.
<RAOF> I don't much care how it's fixed; I'd just like the Mir EGL platform to work again, and the new mesa actually builds that code...
<RAOF> ð
<cpaelzer> hi, if things are stuck in unapproved is there any place other than asking here to check what might be the reason?
<cpaelzer> I expect people are just busy which is fine, yet I want to ensure it is not blocked on me and I miss it
<cpaelzer> qemu since (almost) a month now for bug 1692530
<cpaelzer> uh it is in fix committed
-queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu5.1 => 2.5.0-3ubuntu5.2] (ubuntu-server, virt) (sync)
<cpaelzer> I remember there was something that this is considered as through approved
<cpaelzer> fixing status
<RAOF> cpaelzer (IRC): you could ping me in ~16 hours and I can look at it on my SRU rotation.
<RAOF> If no one gets to it first.
<cpaelzer> I really think I messed it up by setting "fix committed" early, I assume that makes it no more showing up in your tooling
<cpaelzer> status is "correct" at in progress following the "official" SRU process - I hope that this will make it being picked up
<cpaelzer> but I set myself a reminder for tomorrow and ping you in case - thanks for the offer RAOF
-queuebot:#ubuntu-release- New: accepted gnome-session [amd64] (artful-proposed) [3.24.1-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted otb [amd64] (artful-proposed) [6.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted otb [i386] (artful-proposed) [6.0.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (zesty-proposed) [1:2.8+dfsg-3ubuntu2.3]
<apw> cpaelzer, ^
<cpaelzer> saw it , thanks apw
<ginggs_> ariba {"all-proposed": "1", "requester": "costamagnagianfranco", "triggers": ["fermi-lite/0.1-4"]} - bad LocutusOfBorg
<LocutusOfBorg> webpage should have a better way to add triggers, rather than going to make mistakes on custom uri
<LocutusOfBorg> btw the fix was to keep one single package from proposed, and I'm sure it was the correct fix
<LocutusOfBorg> so... at the end the result is the same
<Laney> I don't really want to encourage people to hack around bad dependencies by messing with the requests.
<LocutusOfBorg> encouraging them to use all-proposed might be worse :p (joking)
-queuebot:#ubuntu-release- Unapproved: libmbim (xenial-proposed/main) [1.12.2-2ubuntu1 => 1.12.2-2ubuntu1.1] (kubuntu, ubuntu-desktop)
<sil2100> slangasek, infinity, apw: hey! In case a package is removed from Debian and doesn't really have any reverse-dependencies in Ubuntu, do I have to fill in an explicit removal bug for it or just poke you guys?
<sil2100> slangasek, infinity, apw: since as per ginggs_'s mention on another channel, mrtrix can be removed as it's gone from Debian + doesn't really build on Ubuntu anymore
<apw> sil2100, i am not sure of the proceedure, there is little harm in captureing that information in a bug, so someone can find out from the removal record why it was junk
<apw> sil2100, so i would vote for a bug
<sil2100> Ok, will fill in a quick one then I guess
<apw> doens't have to be an epic that is for sure
<sil2100> The wiki mentions 'Packages which are removed from Debian are semi-automatically removed from Ubuntu universe on a regular basis by the administrators', but I'd doesn't say how frequent ;) A bug won't hurt I suppose
<apw> sil2100, there is some kind of bulk-processing, but where there is some history and thought and discussion behind it it seems useful to record it in a bug
<jbicha> sil2100: if the package has Ubuntu modifications (maybe even rebuilds?), it won't be "semi-automatically removed"
<sil2100> Good to know!
<cjwatson> Well it depends
<cjwatson> process-removals always asks for the archive admin running it to decide
<cjwatson> Generally things that aren't modified in Ubuntu are an easier sell than things that are
<sil2100> LP: #1699102 for anyone potentially interested - thank you!
<cjwatson> But when I've run it in the past I've (a) not considered rebuilds to be modifications for this purpose (b) even if a package is modified then I'll skim the changelog and if it's clearly just somebody trying to make the thing keep building or similar then I won't consider that as blocking removal either
<cjwatson> Clearly this sort of thing depends on the admin though
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.4 => 1:4.2.8p4+dfsg-3ubuntu5.5] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ntp (zesty-proposed/main) [1:4.2.8p9+dfsg-2ubuntu1 => 1:4.2.8p9+dfsg-2ubuntu1.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ntp (yakkety-proposed/main) [1:4.2.8p8+dfsg-1ubuntu2 => 1:4.2.8p8+dfsg-1ubuntu2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.15 => 0.4.9-3ubuntu7.16] (core)
<slangasek> sil2100: a package that has no Ubuntu delta and has been removed from Debian will be removed when we run process-removals.  However, mrtrix is not removed from Debian, it's only removed from Debian testing; therefore a bug is needed
<ginggs> slangasek: you got bug LP: #1699102
<ubot5`> Launchpad bug 1699102 in Ubuntu "Please remove mrtrix from Ubuntu artful" [Undecided,New] https://launchpad.net/bugs/1699102
 * slangasek nods
<bdmurray> slangasek: Could you look at apport in the SRU queue for xyz?
<teward> do non-merge autosyncs from Debian skip proposed migration or no?  Just curious.
<jbicha> teward: no
<teward> jbicha: thanks
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (zesty-proposed) [1.4.4~17.04.1]
<bdmurray> slangasek: Do you feel like all your concerns in comment #7 of bug 1686470 have been addressed?
<ubot5`> bug 1686470 in apt (Ubuntu Zesty) "Apt updates that are uniformly spread across all timezones, with predictable application windows" [High,In progress] https://launchpad.net/bugs/1686470
-queuebot:#ubuntu-release- New binary: openvas-libraries [ppc64el] (artful-proposed/universe) [9.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-libraries [s390x] (artful-proposed/universe) [9.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-libraries [amd64] (artful-proposed/universe) [9.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas [amd64] (artful-proposed/universe) [9.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-libraries [i386] (artful-proposed/universe) [9.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-libraries [arm64] (artful-proposed/universe) [9.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-libraries [armhf] (artful-proposed/universe) [9.0.1-2] (no packageset)
<slangasek> bdmurray: apport> looking
<bdmurray> slangasek: thanks
<cyphermox> could someone please review grub2, grub2-signed in xenial, yakkety, and zesty queues?
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4.2]
<slangasek> cyphermox: RAOF is on today if I'm not mistaken
<cyphermox> yes, I just checked
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.4]
<cyphermox> I don't think he's on just now though, and grub has been waiting for a few days
<cyphermox> just doing what I can to poke this a bit in the right direction :)
<slangasek> right, I think highlighting RAOF is moving it a bit further in that direction
<cyphermox> yep
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.7]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [amd64] (artful-proposed) [9.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [armhf] (artful-proposed) [9.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [ppc64el] (artful-proposed) [9.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas [amd64] (artful-proposed) [9.0.0]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [arm64] (artful-proposed) [9.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [s390x] (artful-proposed) [9.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-libraries [i386] (artful-proposed) [9.0.1-2]
<slangasek> bdmurray: apt> did the latest implementation get fixed to not run twice a day anymore?
<slangasek> bdmurray: I know xnox replied to my question, but I don't agree with him :)
<bdmurray> slangasek: I'll have to look closely. Also I don't see any mention of a wiki page which is something you suggested. I feel like some (just one) SRU team member just needs to own this apt SRU and help get it done.
 * bdmurray realizes he's likely volunteering for that
<slangasek> bdmurray: I may have already agreed with gaughen that I would own it
<bdmurray> slangasek: Well you are a bit more opinionated in this matter. ;-)
<ginggs> would someone please remove pixfrogger's 64-bit binaries so it can migrate from -proposed?
<bdmurray> slangasek: so you'll take ownership of the apt SRU?
<slangasek> bdmurray: yes
-queuebot:#ubuntu-release- New binary: openvas-cli [i386] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-cli [s390x] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-cli [ppc64el] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-cli [amd64] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-cli [armhf] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-cli [arm64] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [ppc64el] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [ppc64el] (artful-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [s390x] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [s390x] (artful-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [i386] (artful-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [amd64] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [i386] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [arm64] (artful-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [armhf] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-manager [amd64] (artful-proposed/universe) [7.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [amd64] (artful-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: greenbone-security-assistant [arm64] (artful-proposed/universe) [7.0.2+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-scanner [armhf] (artful-proposed/universe) [5.1.1-2] (no packageset)
<RAOF> Wow. That's a big-arse patchset to grub2
<RAOF> cyphermox: I presume there's a good rationale for the grub2 changes?
<RAOF> cyphermox: The tracking bug doesn't actually mention anything that's broken, just that there are âlots of commits upstreamâ.
<RAOF> Which would not normally be grounds for an SRU, but you're no neophyte so I'm sure you've got a reason :)
#ubuntu-release 2017-06-21
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [sync] (zesty-proposed) [2.5.0-3ubuntu5.2]
<slangasek> RAOF: the rationale may be "the secureboot implementation has bugs, and cherry picking pieces of a secureboot implementation is higher risk"
<RAOF> slangasek: I assume it's something like that, yes. I'd like to not assume what the rationale is, though :)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.7-0ubuntu0.17.04.1]
<cyphermox> RAOF: indeed, that's the rationale, I'll update the bug.
<slangasek> RAOF: sorry, I was using cutesy verbs.  I knew for a fact that's what the SRU was about
<RAOF> And now that it's recorded in the bug the next person who touches it won't have the same question!
<RAOF> :P
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.12]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.12 => 2.02~beta2-36ubuntu3.12] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (zesty-proposed) [2.02~beta3-4ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (zesty-proposed) [1.80.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (yakkety-proposed) [1.74.4]
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.4 => 2.02~beta2-36ubuntu11.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2.2 => 2.02~beta3-4ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.12]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.12 => 2.02~beta2-36ubuntu3.12] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.4 => 2.02~beta2-36ubuntu11.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2.2 => 2.02~beta3-4ubuntu2.2] (core)
<slangasek> anyone driving this latest ghc transition?
-queuebot:#ubuntu-release- New binary: openvas-manager [s390x] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-manager [ppc64el] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-audriusbutkevicius-pfilter [amd64] (artful-proposed/universe) [0.0~git20170209.0.09b3cfd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-coreos-semver [amd64] (artful-proposed/universe) [0.0~git20150304-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-manager [armhf] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-chmduquesne-rollinghash [amd64] (artful-proposed/universe) [2.0.2+git20170321.9.043b8fd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gedex-inflector [amd64] (artful-proposed/universe) [0.0~git20170307.0.16278e9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fatih-structs [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-spaolacci-murmur3 [amd64] (artful-proposed/universe) [0.0~git20150829.0.0d12bf8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-guregu-null.v3 [amd64] (artful-proposed/universe) [3.1+git20160228.0.41961ce-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-serenize-snaker [amd64] (artful-proposed/universe) [0.0~git20170425.0.1c7f653-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-manager [i386] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-guregu-null.v2 [amd64] (artful-proposed/universe) [2.2+git20150913.0.4ac4f00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ccding-go-stun [amd64] (artful-proposed/universe) [0.0~git20170323.0.04a4eed-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvas-manager [amd64] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-viki-org-dnscache [amd64] (artful-proposed/universe) [0.0~git20130720.0.c70c1f2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-audriusbutkevicius-pfilter [amd64] (artful-proposed) [0.0~git20170209.0.09b3cfd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-coreos-semver [amd64] (artful-proposed) [0.0~git20150304-2]
-queuebot:#ubuntu-release- New: accepted golang-github-gedex-inflector [amd64] (artful-proposed) [0.0~git20170307.0.16278e9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-spaolacci-murmur3 [amd64] (artful-proposed) [0.0~git20150829.0.0d12bf8-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-guregu-null.v3 [amd64] (artful-proposed) [3.1+git20160228.0.41961ce-1]
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [armhf] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-manager [i386] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted openvas-manager [s390x] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [arm64] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-chmduquesne-rollinghash [amd64] (artful-proposed) [2.0.2+git20170321.9.043b8fd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-serenize-snaker [amd64] (artful-proposed) [0.0~git20170425.0.1c7f653-1]
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [arm64] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-manager [ppc64el] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [armhf] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-fatih-structs [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted openvas-manager [armhf] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-guregu-null.v2 [amd64] (artful-proposed) [2.2+git20150913.0.4ac4f00-1]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [amd64] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [amd64] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [ppc64el] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-cli [amd64] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted openvas-cli [armhf] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted openvas-cli [ppc64el] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted openvas-manager [amd64] (artful-proposed) [7.0.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [ppc64el] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New binary: openvas-manager [arm64] (artful-proposed/universe) [7.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [i386] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-cli [arm64] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted openvas-cli [s390x] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [s390x] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted greenbone-security-assistant [s390x] (artful-proposed) [7.0.2+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-scanner [i386] (artful-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted openvas-cli [i386] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New binary: ruby-autoparse [amd64] (artful-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-pseudorandombytes [amd64] (artful-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-domain-browser [amd64] (artful-proposed/universe) [1.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [ppc64el] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [s390x] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.3]
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [amd64] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [i386] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [ppc64el] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [s390x] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [amd64] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [i386] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [arm64] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
<LocutusOfBorg> slangasek, can you please leave ghc transition to me?
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1509 [armhf] (artful-proposed/universe) [15.09a-2ubuntu1] (no packageset)
<LocutusOfBorg> lots of packages needs uploads in Debian, I'm already scheduling/doing them
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [armhf] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: alljoyn-thin-client-1604 [arm64] (artful-proposed/universe) [16.04-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-8.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-8.13]
<rbasak> bdmurray: opinion on bug 1562308 please? It seems to me that comment 17 is referring to some other bug, with no steps to reproduce provided. OTOH cosmos-door has a reproducer and confirmed it broken without and fixed with proposed, so I think this is OK to release. Do you agree?
<ubot5`> bug 1562308 in less (Ubuntu Yakkety) "missing or duplicate lines caused by a wrapped line with wide characters" [Medium,Fix committed] https://launchpad.net/bugs/1562308
<rbasak> mapreri: see https://bugs.launchpad.net/ubuntu/+source/python-werkzeug/+bug/1694261/comments/5 - I'm around doing SRUs today if you'd like to discuss.
<ubot5`> Ubuntu bug 1694261 in python-werkzeug (Ubuntu Xenial) "Crashes with UnicodeDecodeError when trying to handle paths with non-ascii chars" [Medium,In progress]
<mapreri> rbasak: I'm around, yes.
<mapreri> (even if I planned to go afk soonâ¢)
<mapreri> rbasak: besides that I can't see why anybody would want to limit its filesystem to ASCII-only (which, btw, would be a purely artificial limitation I can't even think where to set), reading it as UTF-8 would Just Work.
<mapreri> Besides, I'm not convinced that I should be setting LANG=C.UTF-8 anywhere to just open a file that happens to have a non-ASCII filename.
<mapreri> and yes, setting LANG=C.UTF-8 would workaround the bug, but it's very much not the fix here.
<mapreri> (i.e. it worked before, it works after with the new upstream, it just doesn't work in-betweenâ¦)
-queuebot:#ubuntu-release- New binary: gnome-session [amd64] (artful-proposed/main) [3.24.1-0ubuntu4] (ubuntu-desktop)
 * mapreri afk as planned, please keep the questions coming if you want.
-queuebot:#ubuntu-release- Unapproved: fwupdate (xenial-proposed/main) [0.5-2ubuntu4 => 0.5-2ubuntu5] (core)
<alan_g> apw: (I gather you were looking this yesterday.) RAOF tells me the mesa glbindings is a false positive, can we get that overridden?
-queuebot:#ubuntu-release- New: accepted gnome-session [amd64] (artful-proposed) [3.24.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (xenial-proposed) [1:0.4.17.3]
-queuebot:#ubuntu-release- New binary: dcmtk [s390x] (artful-proposed/universe) [3.6.1~20170228-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcmtk [ppc64el] (artful-proposed/universe) [3.6.1~20170228-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcmtk [amd64] (artful-proposed/universe) [3.6.1~20170228-1] (no packageset)
-queuebot:#ubuntu-release- New source: gir-to-d (zesty-backports/primary) [0.10.0-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New source: gir-to-d (xenial-backports/primary) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [source] (xenial-backports) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [source] (zesty-backports) [0.10.0-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New binary: gir-to-d [amd64] (xenial-backports/none) [0.10.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [ppc64el] (xenial-backports/none) [0.10.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [i386] (xenial-backports/none) [0.10.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [i386] (zesty-backports/none) [0.10.0-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [amd64] (zesty-backports/none) [0.10.0-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [armhf] (xenial-backports/none) [0.10.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [armhf] (zesty-backports/none) [0.10.0-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: dcmtk [arm64] (artful-proposed/universe) [3.6.1~20170228-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gir-to-d [amd64] (xenial-backports) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [i386] (xenial-backports) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [amd64] (zesty-backports) [0.10.0-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [i386] (zesty-backports) [0.10.0-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [armhf] (xenial-backports) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [armhf] (zesty-backports) [0.10.0-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [ppc64el] (xenial-backports) [0.10.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: dcmtk [armhf] (artful-proposed/universe) [3.6.1~20170228-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20170523-0ubuntu1~17.04.0 => 20170609-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20170523-0ubuntu1~14.04.0 => 20170609-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20170523-0ubuntu1~16.10.0 => 20170609-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20170523-0ubuntu1~16.04.0 => 20170609-0ubuntu1~16.04.0] (ubuntu-cloud)
<rbasak> mapreri: would setting LANG correctly be a bug workaround, or would it be fixing the root cause? Do you know how it is that your system came to have LANG be unset?
<rbasak> mapreri: I'm concerned because the patch introduces a behaviour change, and some users may have problems with that in a way I can't necessarily predict.
<rbasak> mapreri: on the other hand, if you're impacted (I think by having a misconfigured server in the first place), then you can fix the behaviour on your own server without having something forcibly pushed out to everyone else.
<rbasak> mapreri: if you're concerned about doing it globally, you could arrange to set LANG just for that process even.
<alan_g> Can anyone help? RAOF tells me the mesa glbindings is a false positive, can we get that overridden?
-queuebot:#ubuntu-release- New: accepted dcmtk [amd64] (artful-proposed) [3.6.1~20170228-1]
-queuebot:#ubuntu-release- New: accepted dcmtk [armhf] (artful-proposed) [3.6.1~20170228-1]
-queuebot:#ubuntu-release- New: accepted dcmtk [s390x] (artful-proposed) [3.6.1~20170228-1]
-queuebot:#ubuntu-release- New: accepted golang-github-viki-org-dnscache [amd64] (artful-proposed) [0.0~git20130720.0.c70c1f2-1]
-queuebot:#ubuntu-release- New: accepted node-pseudorandombytes [amd64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted openvas-manager [arm64] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted dcmtk [arm64] (artful-proposed) [3.6.1~20170228-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ccding-go-stun [amd64] (artful-proposed) [0.0~git20170323.0.04a4eed-1]
-queuebot:#ubuntu-release- New: accepted openvas-manager [amd64] (artful-proposed) [7.0.1-3]
-queuebot:#ubuntu-release- New: accepted dcmtk [ppc64el] (artful-proposed) [3.6.1~20170228-1]
-queuebot:#ubuntu-release- New: accepted node-domain-browser [amd64] (artful-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted ruby-autoparse [amd64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-82.105] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-25.29] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-25.29~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: autofs (xenial-proposed/main) [5.1.1-1ubuntu3 => 5.1.1-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: autofs (yakkety-proposed/main) [5.1.1-1ubuntu3 => 5.1.1-1ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: android-tools [amd64] (artful-proposed/main) [5.1.1.r38-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: android-tools [i386] (artful-proposed/main) [5.1.1.r38-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: android-tools [arm64] (artful-proposed/main) [5.1.1.r38-1] (desktop-core)
<LocutusOfBorg> any AA, please kick haskell-cabal out of -release (move to proposed)
<LocutusOfBorg> rationale: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865399#10
<ubot5`> Debian bug 865399 in libghc-cabal-dev "libghc-cabal-dev and ghc: error when trying to install together" [Serious,Open]
<LocutusOfBorg> there are 4 reverse-deps
-queuebot:#ubuntu-release- New binary: android-tools [armhf] (artful-proposed/main) [5.1.1.r38-1] (desktop-core)
<ahasenack> hi, can someone please accept the zesty nomination for https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1644428 ?
<ubot5`> Ubuntu bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released]
<rbasak> ahasenack: done
<ahasenack> rbasak: thx
<alan_g> tjaalton: Can you help? A mesa fix into artful is blocked in "excuses". RAOF (whose fix it is) tells me the mesa glbindings is a false positive, can we get that overridden?
<tjaalton> alan_g: I can't override that
<alan_g> I tried asking apw, but got no response. Who can?
<tjaalton> any AA, but it's a scarce resource :)
<cjwatson> release team, not AA
-queuebot:#ubuntu-release- New: accepted android-tools [amd64] (artful-proposed) [5.1.1.r38-1]
-queuebot:#ubuntu-release- New: accepted android-tools [armhf] (artful-proposed) [5.1.1.r38-1]
-queuebot:#ubuntu-release- New: accepted android-tools [arm64] (artful-proposed) [5.1.1.r38-1]
-queuebot:#ubuntu-release- New: accepted android-tools [i386] (artful-proposed) [5.1.1.r38-1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [amd64] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [armhf] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [ppc64el] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [amd64] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [armhf] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [ppc64el] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [amd64] (artful-proposed) [0.7.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [armhf] (artful-proposed) [0.7.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [ppc64el] (artful-proposed) [0.7.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-os-traits [amd64] (artful-proposed) [0.3.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [arm64] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [s390x] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [i386] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [arm64] (artful-proposed) [0.7.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [s390x] (artful-proposed) [0.7.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1509 [i386] (artful-proposed) [15.09a-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [s390x] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted alljoyn-thin-client-1604 [arm64] (artful-proposed) [16.04-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dhcpcd-ui [i386] (artful-proposed) [0.7.5-0ubuntu2]
<flexiondotorg> Afternoon.
<flexiondotorg> I've got a couple of new packages I'd like see uploaded to the 17.10 archive in time for Alpha 1.
<flexiondotorg> Anyone here who could take a look please?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+bug/1699333
<ubot5`> Ubuntu bug 1699333 in Ubuntu "[needs-packaging] vala-panel" [Wishlist,Confirmed]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+bug/1699334
<ubot5`> Ubuntu bug 1699334 in Ubuntu "[needs-packaging] vala-panel-appmenu" [Wishlist,Confirmed]
<flexiondotorg> These packages are of interest to Ubuntu MATE and Ubuntu Budgie.
<flexiondotorg> Tagging didrocks and fossfreedom_
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-25.29]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-25.29~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-82.105]
<bdmurray> rbasak: looking
<bdmurray> rbasak: I looked for other bugs related to the commenter and found some recent activity from them so maybe they made a mistake? Also I'm looking at other less bugs to see if there is anything like their issue.
<bdmurray> rbasak: I don't see anything similar to comment #17 so I think its fine.
<doko> please could somebody override the linux autopkg tests in binutils, gcc-6 and gcc-7?
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (trusty-proposed) [0.22-1ubuntu1.1]
<tjaalton> cjwatson: oh
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:0.4.17.2 => 1:0.4.17.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (xenial-proposed) [1:0.4.17.3]
<slangasek> LocutusOfBorg: haskell-platform, propellor, haskell-cabal-install are the only revdeps I found of haskell-cabal that would need demoted; you said there were 4, what did I miss?
<LocutusOfBorg> slangasek, checking
<LocutusOfBorg> Reverse-Build-Depends
<LocutusOfBorg> =====================
<LocutusOfBorg> * curry-frontend
<LocutusOfBorg> * ganeti
<LocutusOfBorg> * git-annex
<LocutusOfBorg> * haskell-cabal-install
<LocutusOfBorg> * haskell-hackage-security
<LocutusOfBorg> "reverse-depends -r artful -b libghc-cabal-dev"
<slangasek> LocutusOfBorg: also I believe we should demote these revdeps and remove haskell-cabal since it needs sourceful changes before it's usable again
<slangasek> LocutusOfBorg: right, I wouldn't (need to) demote the reverse-build-deps
<slangasek> only the binary deps
<LocutusOfBorg> so, if you can do it, wonderful
<LocutusOfBorg> in the meanwhile we will fix it debian-side
<LocutusOfBorg> or get them out from testing, that is the same :)
<doko> please could somebody override the linux autopkg tests in binutils, gcc-6 and gcc-7?
<slangasek> doko: it'll be a bit before I can get to it; meanwhile, do you want to scold the kernel team for their unreliable autopkgtests? :)
<doko> slangasek: I did, but it didn't help in the past. there should be even a bug report ... which I cannot find now
<nacc> heh
<slangasek> LocutusOfBorg: any idea on the haskell-protobuf/armhf build failure?
<slangasek> LocutusOfBorg: btw I'm hands-off on the transition now, as you asked.  Would it be possible to have plans around transitions communicated to ubuntu-devel?  Otherwise, it's not obvious when looking at update_excuses that a transition is being managed, vs. being just a big pile of things that need fixing :)
<apw> doko, slangasek, the current failure (for ppc64el) is fallout from the crd cve which has not been reflected in the tests by the looks of it
<apw> ie a really new one
<bdmurray> Has something changed with the autopkgtest infrastructure the apport failures are surprising and unrelated to my SRU. http://autopkgtest.ubuntu.com/packages/a/apport/xenial/amd64
<bdmurray> slangasek, Laney: Has something changed with the autopkgtest infrastructure the apport failures are surprising and unrelated to my SRU. http://autopkgtest.ubuntu.com/packages/a/apport/xenial/amd64
<slangasek> bdmurray: test_core_dump_packaged , test_core_dump_unpackaged ?
<slangasek> I'm not aware of any changes, but is the test suite's behavior dependent on whether the kernel has a crash handler registered?
<bdmurray> Well I think it is testing itself as the crash handler.
<infinity> bdmurray: Not seeing how "the infrastructure" would be at fault there.  Have you tried blaming systemd? :)
<infinity> Or the kernel.
<slangasek> right
-queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.3-0ubuntu0.1 => 1.48.5-0ubuntu0.1] (desktop-extra, mozilla, ubuntugnome)
<jbicha> please reject gjs 1.48.4/zesty
<infinity> jbicha: One commit per upstream version, that's quite the release workflow.
-queuebot:#ubuntu-release- Unapproved: rejected gjs [source] (zesty-proposed) [1.48.4-0ubuntu0.1]
<jbicha> infinity: they apparently found a regression in that one fix :(
<infinity> jbicha: Yeah, I read the changelog. :)
<infinity> jbicha: Based on recent history, I'm going to say that particular software isn't exactly the Best Thing Ever, and we can probably expect more of the same.
<jbicha> it's a moving target, it was ported from mozjs24 to 31 to 38 for 3.24 and this cycle it's being ported through 45 to 52 in time for next year porting to 59 :|
<infinity> jbicha: I wonder what it is about JS that leads to all implementations being awful.
<infinity> Maybe the people who know how to write decent compilers and VMs didn't feel the need for another, so JS engines are written by, like, the half-wit cousin of the ex-wife's hairdresser's plumber, seven times removed from a compiler designer.
<infinity> Aaaand, sometimes I forget just how much madness autoconf tests for.
<infinity>  END
<infinity>      AC_MSG_ERROR([Your 'rm' program is bad, sorry.])
<infinity>    fi
<infinity> Not sure what the test was, as that's just a bit of diff context, but hah.
<nacc> infinity: awesome
<infinity> Maybe when everyone has finally decided to move to autotools replacements because newer is clearly always better, we can just rename autoconf "quirky UNIX testsuite".
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (zesty-proposed) [2.02~beta3-4ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (zesty-proposed) [2.02~beta3-4ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (yakkety-proposed) [2.02~beta2-36ubuntu11.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (yakkety-proposed) [2.02~beta2-36ubuntu11.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.12]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.12]
-queuebot:#ubuntu-release- New binary: libgetdata [ppc64el] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgetdata [i386] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgetdata [s390x] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgetdata [amd64] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgetdata [arm64] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgetdata [armhf] (artful-proposed/universe) [0.10.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: webcamoid [s390x] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webcamoid [ppc64el] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webcamoid [amd64] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webcamoid [i386] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webcamoid [arm64] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
#ubuntu-release 2017-06-22
-queuebot:#ubuntu-release- New binary: webcamoid [armhf] (artful-proposed/universe) [8.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [ppc64el] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [amd64] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [s390x] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-kaptan [amd64] (artful-proposed/none) [0.5.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [i386] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [armhf] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-core [arm64] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-57.62] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-57.62~16.04.1] (kernel)
<jamespage> if there is a sru person around, I have uploads for neutron and keystone in xenial-proposed I'd like to regression test alongside the rest of the mitaka point releases already accepted - those are for specific bug fixes
<jamespage> and similar in yakkety in that I have a number of point releases in the unappproved queue - I'd like to clear testing this week if possible please :)
<sil2100> jamespage: hey, I *might* have a look at those once I'm done with my kernel round, so in ~1 hour
<jamespage> sil2100: thankyou :-)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-57.62]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-57.62~16.04.1]
<sil2100> jamespage: I checked neutron xenial, looks fine-ish - I don't like the version number though but I'll just re-upload and then approve
<sil2100> So don't worry about that one, there will be a reject followed by an approval
<jamespage> sil2100: ok I'll make a not to re-import your updated version to the git repo then
<jamespage> note rather
<sil2100> jamespage: it's just that it doesn't make sense to do a 2:8.4.0-0ubuntu2.1 since there's no version conflict possible, we should just go to ubuntu3 as is
<sil2100> But those are nitpicks, which is why I'll fix that ;)
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu2.1]
<apw> doesn't that help maintain consistency though ?
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu2 => 2:8.4.0-0ubuntu3] (openstack, ubuntu-server)
<sil2100> apw: well, it's not consistent anyway since we already have one update in xenial that bumped from ubuntu1 to ubuntu2, so to stay consistent we need to bump to ubuntu3, not suddenly decide on switching to the .1 notation ;)
<sil2100> IMO
<sil2100> Which is what I'm doing nwo
<apw> sil2100, ok
<sil2100> apw: ah, while we're at it, do you want to tackle keystone? I already started looking at it but I see you handled the zesty version already, so maybe you'd like the rest too?
<apw> sil2100, i can.  it would not be instand
<apw> t
<xnox> Laney, can src:systemd be peppered over to migrate in artful? =)
<xnox> or is it too much to say that i don't care about armhf.
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu3]
<sil2100> apw: ok then, I'll leave that one for you then
<sil2100> apw: thanks! I'll proceed with neutron and others in yakkety
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-122.171] (core, kernel)
-queuebot:#ubuntu-release- New binary: libpodofo [ppc64el] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- New binary: libpodofo [s390x] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libpodofo [amd64] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- New binary: libpodofo [i386] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (yakkety-proposed) [2.10.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libpodofo [arm64] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- New binary: libpodofo [armhf] (artful-proposed/universe) [0.9.5-5] (edubuntu)
-queuebot:#ubuntu-release- New: accepted libbpp-core [amd64] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-core [armhf] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-core [ppc64el] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libgetdata [amd64] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted libgetdata [armhf] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted libgetdata [ppc64el] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted libpodofo [amd64] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted libpodofo [armhf] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted libpodofo [ppc64el] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted python-kaptan [amd64] (artful-proposed) [0.5.8-3]
-queuebot:#ubuntu-release- New: accepted libbpp-core [arm64] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-core [s390x] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libgetdata [i386] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted libpodofo [arm64] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted libpodofo [s390x] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted webcamoid [arm64] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted webcamoid [i386] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted webcamoid [s390x] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libbpp-core [i386] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libgetdata [s390x] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted webcamoid [amd64] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted webcamoid [ppc64el] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libgetdata [arm64] (artful-proposed) [0.10.0-3]
-queuebot:#ubuntu-release- New: accepted webcamoid [armhf] (artful-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libpodofo [i386] (artful-proposed) [0.9.5-5]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-122.171]
<ypwong> sil2100, it's bug 1684034 again, about fwupdate. We avoided doing a full upgrade and just picked 4 commits this time.
<ubot5`> bug 1684034 in fwupdate-signed (Ubuntu Yakkety) "Some Dell and Lenovo systems do not work after BIOS Capsule Update" [High,In progress] https://launchpad.net/bugs/1684034
<ypwong> sil2100, could you give it a look?
<rbasak> sil2100, bdmurray: during SRUs today? I had a couple I'd mostly looked at so was just going to finish those two off - less and cloud-init.
<rbasak> (releasing less, and accepting cloud-init from Trusty unapproved)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (trusty-proposed) [0.7.5-0ubuntu1.22]
<slashd> bdmurray, sil2100:  Good day, could you please have a look at these uploads waiting for approval : #1) - autofs for X/Y (LP: #1686679) -- #2) - multipath-tools for Trusty : (LP: #1695789) & (LP: #1687004). Thanks.
<ubot5`> Launchpad bug 1686679 in autofs5 (Ubuntu Yakkety) "[SRU] Ubuntu16.04 : autofs is extremely long with large number of direct maps" [Medium,In progress] https://launchpad.net/bugs/1686679
<ubot5`> Launchpad bug 1695789 in multipath-tools (Ubuntu Trusty) "multipath random crashes on use-after-free" [Medium,In progress] https://launchpad.net/bugs/1695789
<ubot5`> Launchpad bug 1687004 in multipath-tools (Ubuntu Trusty) "multipath crash generating core dump" [Medium,In progress] https://launchpad.net/bugs/1687004
<slashd> tinoco^
<sil2100> slashd: hey! Just got back from lunch, can take a look in a moment
<sil2100> rbasak: hey, I'm doing some SRU work today yes
<sil2100> ypwong: I can try having a look at that in some moments, thanks!
<rbasak> sil2100: hello! I'm done with SRU work for today - I handled just those two I mentioned.
<sil2100> rbasak: ok, thanks o/
<xnox> ypwong, the bug title sounds bad
<slashd> sil2100, thanks
<xnox> slangasek, please remove linux 4.11.0-8.13 from artful-proposed due to failing adt tests.
<xnox> slangasek, my understanding is that adt tests should be run against linux kernel ppa built before copying into artful-proposed (aka silo style)
<apw> xnox, indeed the normally are, and tests change because that is the nature of tests
<apw> xnox, so they can trivially pass get copied out and stop passing
<xnox> (after more talk on -kernel)
<xnox> Laney, slangasek: why are src:systemd triggered tests of src:linux are running against proposed version of src:linux?
<xnox> using proposed src:linux is almost never the right answer.
<Laney> https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/tree/worker/worker#n350
<Laney> it's always worked like that
<xnox> Laney, sorry does that code means always use src:linux from release, instead of proposed?
<xnox> Laney, then why my systemd tests are currently using linux 4.11 instead of 4.10?
<xnox> (4.11 is in proposed, and 4.10 is what is in release)
<xnox> or does that on the contrary says always use src:linux from proposed?
<Laney> the opposite of what you said
<xnox> o_O
<xnox> i've said both things =)
<Laney> the behaviour you are observing is the one that the code says should happen
<xnox> where does src:linux always come from?
<xnox> *sigh*
<Laney> linux is not subject to the pinning
<xnox> apw, ^^^^^
<xnox> src:linux and src:linux-meta is so special that broken src:linux in proposed affects everybody, always, unlike all the other packages.
<xnox> slangasek, ^
<apw> hmmm, that is unexpected i think
<xnox> ideally we would fix src:linux pinning and test against release linux; or remove src:linux from -proposed if its tests are broken.
<xnox> fix ADT pinning of src:linux src:linux-meta src:linux-hwe-meta
<xnox> that is.
<Laney> you'll have to ask pitti what the precise problem was
<xnox> apw, or e.g. change the process to copy from PPA into silo; wait for adt results of src:linux -> adt test of src:linux, and copy from silo to devel-proposed, iff the adt test for src:linux of the new src:linux passed.
<xnox> (not _all_ the triggered tests, but just src:linux trigger linux)
<xnox> apw, does that make sense for the linux package release process?
<apw> xnox, making the process have yet another copy step is not going to make anyone happy
<apw> we are running tests against it before it moves in the normal case
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (yakkety-proposed) [5.1.1-1ubuntu4]
<xnox> apw, ok, where are the results visible? e.g. did 4.11-8.13, 4.11.0-7.12, 4.11.0-6.11, 4.11.0-5.10 ever pass on amd64?
<xnox> because all of those kernels never passed adt on amd64 in the archive yet.
<xnox> (linux, passing itself tests, with various triggers, with probably some packages coming from -proposed)
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (xenial-proposed) [5.1.1-1ubuntu3.1]
<Laney> it's been forced up to now
 * apw has to step away
-queuebot:#ubuntu-release- New binary: libbpp-seq [s390x] (artful-proposed/universe) [2.3.1-1] (no packageset)
<apw> it seems we have an apparmor issue which has been triggering the test, a failure in the tests to keep up with the kernel, hmmm
<xnox> FAIL: test_061_guard_page (__main__.KernelSecurityTest) is the one that seems to be failing from the ubuntu-regression-suite
<xnox> in adt, in artful-proposed, and said test case should have run in ADT prior to copy to artful-proposed, no?
<apw> xnox, right this a new issue with the CRD fixes
-queuebot:#ubuntu-release- New binary: libbpp-seq [ppc64el] (artful-proposed/universe) [2.3.1-1] (no packageset)
<xnox> right that's on the recentish kernels. the older I go, it has different errors from a different part of the suite.
<apw> xnox, although it is annoying, this is so normal, like we've been hinting systemd failures for literally months where the kernel is cross affected
<xnox> on armhf/s390x -> yes, and i have fixed those.
<xnox> or do you mean on amd64 as well?
<apw> doesn't matter what arch it is
 * apw really has to step out now
<xnox> apw, http://autopkgtest.ubuntu.com/packages/linux/artful/amd64 vs http://autopkgtest.ubuntu.com/packages/systemd/artful/amd64
<sforshee> xnox: there are failures in apparmor test cases that the security team has known about for a while now which are responsible for the past failures
<sforshee> xnox: I should note that those apparmor failures don't represent any serious problem, just that the tests haven't been updated for a change in kernel behavior
-queuebot:#ubuntu-release- New binary: libbpp-seq [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
<xnox> sforshee, sure. and that is fine. my concern is that src:linux->linux adt test is run; known to be broken; yet the package is thrown over the wall anyway, which then flags up many false regressions across many core packages; requiring manual intervention on each depdant package to migrate.
<xnox> and i'm being told that adt test of src:linux against new src:linux is run before upload.
<sforshee> xnox: normally they are, I rushed this one because it was a cve fix then it turned out upstream had flubbed it. The tests wouldn't have passed anyway though, and we can't wait indefinitely for others to fix broken tests.
-queuebot:#ubuntu-release- New binary: libbpp-seq [arm64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq [armhf] (artful-proposed/universe) [2.3.1-1] (no packageset)
<xnox> sforshee, ok, but the end result is that src:linux 4.11 is not in release pocket; but clogging up many package migrations in devel-proposed; and nobody running artful has the CVE fix, and thus is still vulnerable.
<xnox> (not that it matters, cause we do not guarantee security support in devel series)
<xnox> sforshee, but e.g. what was the rationale for pushing these packages to devel-proposed, what did you hope to achieve? that people running devel-proposed are secured?
<sforshee> xnox: I had a 4.11 in -proposed last week that I hoped to get promoted. When the cve came up I thought it better to wait and let 4.10 with the fix get copied forward then try to push out a 4.11 with the fix.
<sforshee> xnox: that other stack guard test failing isn't as bad as it looks, the guard page is still there but there's a difference in behavior.
<sforshee> or guard region rather, more than a single page now
<sforshee> xnox: in hindsight is was a bad idea to rush it though, and there wasn't a real reason other than trying to get 4.11 into -release
<xnox> right. a series of unfortunate events.
<xnox> .... our test-suite was expoiting the guard page cve all this time?! O_o =)
<xnox> good test suite
 * xnox giggles
<slashd> sil2100, no rush, just wanted to know if you will have time today for my 2 requests :  #2) - multipath-tools for Trusty : (LP: #1695789) & (LP: #1687004)
<ubot5`> Launchpad bug 1695789 in multipath-tools (Ubuntu Trusty) "multipath random crashes on use-after-free" [Medium,In progress] https://launchpad.net/bugs/1695789
<ubot5`> Launchpad bug 1687004 in multipath-tools (Ubuntu Trusty) "multipath crash generating core dump" [Medium,In progress] https://launchpad.net/bugs/1687004
<sil2100> slashd: I'll try! Need to finish up something else first + weekly meeting
<sil2100> If not Brian might during his shift later today or I'll pick it up first thing in the morning
<slashd> sil2100, bdmurray ok thanks
<sil2100> High chance is I'll just be able to make it today
<xnox> slangasek, please release systemd (src:linux is broken, and known, impossible to run src:linux release tests as src:linux is pinned to always run from proposed)
<xnox> it's otherwise green
<slashd> tinoco, ^^^
-queuebot:#ubuntu-release- New: accepted libbpp-seq [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq [armhf] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq [s390x] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq [arm64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq [ppc64el] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New binary: libbpp-popgen [ppc64el] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [arm64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [s390x] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [s390x] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [s390x] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [ppc64el] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [ppc64el] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [arm64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [armhf] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [armhf] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [arm64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [armhf] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [armhf] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [s390x] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [arm64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [ppc64el] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [armhf] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [arm64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [s390x] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [ppc64el] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [arm64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [armhf] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [ppc64el] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [s390x] (artful-proposed) [2.3.1-1]
<sil2100> slashd: I guess from the bug description that there's no reliable way of reproducing LP: #1687004 for testing purposes?
<ubot5`> Launchpad bug 1687004 in multipath-tools (Ubuntu Trusty) "multipath crash generating core dump" [Medium,In progress] https://launchpad.net/bugs/1687004
-queuebot:#ubuntu-release- New binary: libbpp-phyl [s390x] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (trusty-proposed) [0.4.9-3ubuntu7.16]
<slashd> tinoco, ^ see sil2100 comment
<tinoco> sil2100: unfortunately not. single crash dump.
<tinoco> sil2100: approach (fix) from upstream changes from heap to stack.
<tinoco> i thought it was safe enough to consider this as a fix for the crash (customer verified)
<tinoco> among several servers, statistically we could consider this fixed (as no crash files were created)
<slashd> sil2100, tinoco thanks guys
<tinoco> tku both!
-queuebot:#ubuntu-release- New binary: libbpp-phyl [ppc64el] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [s390x] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [ppc64el] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [amd64] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [s390x] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [ppc64el] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [ppc64el] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [s390x] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [amd64] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- Unapproved: kexec-tools (zesty-proposed/main) [1:2.0.14-1ubuntu3 => 1:2.0.14-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: php-defaults (xenial-proposed/main) [35ubuntu6 => 35ubuntu6.1] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [ppc64el] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [s390x] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [amd64] (artful-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bppsuite [amd64] (artful-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-libtmux [amd64] (artful-proposed/universe) [0.6.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dj-static [amd64] (artful-proposed/universe) [0.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-decouple [amd64] (artful-proposed/universe) [3.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vulkan [source] (xenial-proposed) [1.0.42.0+dfsg1-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (xenial-proposed) [2.4.76-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libwacom [source] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: libdrm [armhf] (xenial-proposed/main) [2.4.76-1~ubuntu16.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted xfonts-utils [source] (xenial-proposed) [1:7.7+3ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: libwacom [s390x] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [ppc64el] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [amd64] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [armhf] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [powerpc] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [arm64] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libwacom [i386] (xenial-proposed/main) [0.22-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (xenial-proposed) [0.2.0+git20170213-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [amd64] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [armhf] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [powerpc] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [s390x] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [arm64] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [ppc64el] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libwacom [i386] (xenial-proposed) [0.22-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [armhf] (xenial-proposed) [2.4.76-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted bppsuite [amd64] (artful-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [amd64] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [s390x] (artful-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted python-libtmux [amd64] (artful-proposed) [0.6.3-4]
-queuebot:#ubuntu-release- New: accepted dj-static [amd64] (artful-proposed) [0.0.6-2]
-queuebot:#ubuntu-release- New: accepted python-decouple [amd64] (artful-proposed) [3.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [ppc64el] (artful-proposed) [2.3.1-2]
#ubuntu-release 2017-06-23
<RAOF> Hey, fancy release team members!
<RAOF> I'd quite like to get mesa out of artful-proposed!
<RAOF> It's blocked by glbindings hitting new and exciting gcc warnings on armhf, thouh.
<RAOF> Those warnings aren't in mesa-adjacent code, though. glbindings is just broken.
<slangasek> RAOF: stderr output from the compiler due to C++, yeah, that's a pretty sure bet that it's not mesa's fault :)  overriding
<RAOF> Ta muchly!
<jbicha> slangasek: want to help android-tools migrate out of -proposed? LP: #1699928
<ubot5`> Launchpad bug 1699928 in goget-ubuntu-touch (Ubuntu) "Please delete obsolete android binaries" [Undecided,New] https://launchpad.net/bugs/1699928
<slangasek> jbicha: ubuntu-device-do / ubuntu-device-flash are not listed on update_excuses and they don't appear to be NBS; removing the binaries is not a correct solution here unless you also show that they won't come back on the next upload
<jbicha> ok
<jbicha> it doesn't build; maybe we should just remove it for all architectures :(
<jbicha> slangasek: are you interested in removing phablet-tools and goget-ubuntu-touch because it won't build? (no other rdeps)
<jbicha> goget builds on zesty but not yakkety
<slangasek> jbicha: those being client tools rather than part of the touch platform, I'd like a clearer statement from the project owners that they should be dropped
<jbicha> heh, "owners"
<jbicha> I got that backwards, it builds on yakkety but not zesty
-queuebot:#ubuntu-release- New binary: gflags [arm64] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gflags [ppc64el] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gflags [amd64] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gflags [i386] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gflags [s390x] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ntfs-3g [ppc64el] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [i386] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New binary: gflags [armhf] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ntfs-3g [s390x] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [arm64] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [armhf] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New binary: ntfs-3g [amd64] (artful-proposed/main) [1:2016.2.22AR.2-2] (core)
-queuebot:#ubuntu-release- New: accepted gflags [amd64] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted gflags [armhf] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted gflags [ppc64el] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [amd64] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New: accepted gflags [arm64] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted gflags [s390x] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted gflags [i386] (artful-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [armhf] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [arm64] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [ppc64el] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [i386] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New: accepted ntfs-3g [s390x] (artful-proposed) [1:2016.2.22AR.2-2]
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [s390x] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud)
<sil2100> Hey! Anyone here could force ignore octave-io's failing armhf test? Checking the logs it's been failing for longer and from the logs (and one re-run) I see that random tests seem to be failing, not the same ones everytime
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#octave-io
<Laney> sil2100: I bumped the existing hint
<sil2100> Laney: thank you!
<sil2100> Also, is there any AA on duty right now to take a look at the binNEW's for gce-compute-image-packages?
<ginggs> would someone please 'force-badtest sunpy/all/armhf' ? existing hint in a.p.w's file
<Laney> .
<ginggs> Laney: thanks!
<flexiondotorg> Any archive admins here who could take a look at LP: #1699333 and LP: #1699334 please?
<ubot5`> Launchpad bug 1699333 in Ubuntu "[needs-packaging] vala-panel" [Wishlist,Confirmed] https://launchpad.net/bugs/1699333
<ubot5`> Launchpad bug 1699334 in Ubuntu "[needs-packaging] vala-panel-appmenu" [Wishlist,Confirmed] https://launchpad.net/bugs/1699334
<flexiondotorg> Laney? infinity? ^
<flexiondotorg> I'd really like to land those for 17.10 Alpha 1.
<Laney> I can't, sorry
<apw> flexiondotorg, what are you looking for on those, they arn't uploaded as far as i can see
<apw> are you looking for an aa or a sponsor ?
<flexiondotorg> apw Yes, looking for an aa to upload them.
<apw> typically ones doesn't need an aa, for an upload one is looking for a coredev or motu sponsor
<flexiondotorg> Then I can updated the Ubuntu MATE seeds. Then email the DMB so I can maintain them in the archive long term.
<apw> to look at accepting them you need a release-team memeber in artful
<apw> (being picky on terms as there are more of the other types than pure-aa's)
<flexiondotorg> I'll ask in #ubuntu-motu
<jbicha> flexiondotorg: ask in #ubuntu-devel, the MOTU channel isn't as popular
<Laney> apw: Accepting from the NEW queue is ~ubuntu-archive
<Laney> although ~ubuntu-release can technically do that for the devel series ...
<Laney> It's not really allowed :)
<apw> Laney, i thought that you could review them, and recommend, but likely so, i was more trying to get a wider view on sponsorship
<mapreri> slangasek: so can you proceed with #1700080 ? :)
<mapreri> we're getting near itâ¦
<mapreri> probably
<mapreri> maybe
<mapreri> hopefully
<acheronuk> also https://bugs.launchpad.net/ubuntu/+source/libkface/+bug/1699727
<ubot5`> Ubuntu bug 1699727 in libkface (Ubuntu) "Please remove libkface from artful - required for OpenCV 3.1 transition" [Undecided,New]
 * acheronuk heads to find cold beer.....
<sil2100> Any archive admin around to take a look at the gce-compute-image-packages binNEWs?
<apw> sil2100, there are some worrying lintian warnings on those, particularly about the library naming
<slangasek> mapreri: done
<mapreri> ta
<mapreri> so, we are probably left with only one failing packages once the new opencv upload I just did builds and mrpt/armhf is retried.
<mapreri> slangasek: #1699727 too?
<slangasek> mapreri: also done
<mapreri> taÂ²
<sil2100> apw: it's some GCE internal thing so yeah, not perfect - what are the lintian warnings?
<slangasek> acheronuk, valorie: any plans on untangling the akonadi-contacts -> qtwebengine-opensource-src -> libv8-dev dependency chain?  You can't rely on v8 being present across all Ubuntu archs, it's highly non-portable, so someone needs to decide what happens to this part of the Kubuntu stack where it's not available
<acheronuk> slangasek: QtWebEngine and what now hard coded depends on it is just not going to be buildable outside amd64/i386 + armhf for now. So we are going to have to ask for some some deletions on architecture that although we did not officially support in kubuntu, did happne to build until now :(s
<slangasek> acheronuk: should I start deleting those now?
<acheronuk> slangasek: can you wait so talk to santa? (https://launchpad.net/~panfaust) I doubt it would matter as most is pretty self obvious, but he has been leading on the Apps update (inc this PIM stuff)
<slangasek> acheronuk: do you expect him to be around on IRC, or do you suggest taking this to email/bug?
<acheronuk> slangasek: I have just pinged him on telegram. Hopefully he will get on here soon. not quite sure why he does not have a IRC BNC, his internet in his home was very bad, but he will usually respond  in shortish time (famous last words)
<slangasek> ok
<acheronuk> slangasek: if you feel any urgency, then please post to kubuntu-devel mailing list as well
<slangasek> "urgency" and "email" are inversely correlated ;)
<acheronuk> lol. I know, but at least it's just there when people care to check
<acheronuk> evening santa :)
<acheronuk> santa_: FYI http://paste.ubuntu.com/24933682/
<slangasek> santa_: hi there.  Should I start picking at the tree of binaries on {arm64,ppc64el,s390x} that are out-of-date because of lack of V8 and removing them?
<slangasek> actually, v8 is available on ppc64el but there was a build failure... so nevermind that part, I'll have a closer look first
<santa_> hi
<slangasek> QtWebEngine can only be built for x86, x86-64, ARM, Aarch64, MIPSel, and MIPS64 architectures.
<slangasek> there we go, sounds like fair game to remove that right now also due to lack of upstream support
<acheronuk> slangasek: QtWebEngine explicitly states it will not build for ppc64el
<slangasek> (but upstream may want to revisit that)
<acheronuk> or it did last time I looked a a log
<acheronuk> they may, but seem in no hurry
<santa_> slangasek: indeed we have several things which are not going to build for some architectures because of libv8 and QtWebengine. so go ahead with the removals please
<slangasek> ok
<slangasek> it'll take a while to hunt them all, but I'll make a start and see if we can't clean up update_excuses
-queuebot:#ubuntu-release- New binary: htslib [s390x] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
<santa_> we also have the akonadi autopkgtest failure
<slangasek> I overrode it (but wasn't happy about it)
-queuebot:#ubuntu-release- New binary: htslib [i386] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: htslib [armhf] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: htslib [ppc64el] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: htslib [amd64] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: htslib [arm64] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset)
<santa_> slangasek: thank you, please just keep in mind that autotests for kde are extremely tricky to set up, even if there's asbsolutely no upstream issues in the code tested. also note that we have been working very, very, very, very hard to try to keep them in shape
<santa_> in fact, today I have spent all night trying to use the qemu backend instead of schroot for the stuff I have to check the autopkgtests in advance
<santa_> also note that in all the time I have been fixing autopkgtest (and I fixed dozens and dozens of them) I still didn't find find any actual upstream code issue
<slangasek> I understand.  I'm not saying these things are easy to manage, but I do think it's better to disable tests in source, or wrap them to pass even if there are errors, than to have constantly-failing tests
<santa_> yeah, that's what I'm working on
<santa_> one problem I have with akonadi is that it fails in different ways in schroot, lxc and the ubuntu official infra
<santa_> so I'm working right now on trying to swtich my invention from schroot to qemu
<santa_> * switch
 * slangasek nods
-queuebot:#ubuntu-release- Unapproved: kexec-tools (yakkety-proposed/main) [1:2.0.10-2ubuntu1.2 => 1:2.0.10-2ubuntu1.3] (core)
<slangasek> good news, everyone!  a bunch more kde packages can now have their autopkgtests run
<jbicha> slangasek: we added some comments to LP: #1699928 for you
<ubot5`> Launchpad bug 1699928 in phablet-tools (Ubuntu) "Please delete obsolete android binaries" [Undecided,New] https://launchpad.net/bugs/1699928
-queuebot:#ubuntu-release- Unapproved: shim-signed (zesty-proposed/main) [1.28 => 1.30~17.04.1] (core)
<cyphermox> slangasek: I think you mistyped your nick; sfarnsworth ;)
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.28~16.10.1 => 1.30~16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.28~16.04.1 => 1.30~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.19~14.04.1 => 1.30~14.04.1] (core)
<xnox> slangasek, https://launchpad.net/ubuntu/+source/ocaml/4.02.3-9ubuntu3 looks futile effort to me, due to patch that passes -fPIC to the build and thus it results in just being PIC, rather than PIE, no?!
<xnox> https://launchpadlibrarian.net/322273615/buildlog_ubuntu-artful-amd64.ocaml_4.02.3-9ubuntu3_BUILDING.txt.gz Ctrl+f PIC
<xnox> (thanks to the ubuntu-only patch from doko)
<xnox> should ocaml be PIE, or PIC?
<xnox> (on all arches)
<slangasek> xnox: AFAIK, PIE and PIC are only materially different when you're linking an executable; which bit do you see that's problematic?
<xnox> slangasek, the bit i see problematic is that the patch lacks description (either inside, or in the name) and the debian changelog entry are useless.
<xnox> instead of stating why something is changed, it simply states what has been changed.
<xnox> And it is not obvious why.
<xnox> -Wl,--no-relax linker flag added, and -fPIC enabled, but on amd64 only.
<slangasek> xnox: ah.  well, I believe that was on rbalint's list of packages to rebuild
<xnox> rebuilding stock debian experimental release on ubuntu, succeeds the build on all arches and at least the build time test suite passes.
<slangasek> which means he tested that rebuilding it made a difference
<xnox> slangasek, i'm not questioning your rebuild alone; i'm questioning why we have the delta at all.
<slangasek> but the -fPIC patch is perhaps superfluous now that the compiler default has changed
<xnox> that's what i'm thinking, but i'm not sure.
<xnox> also no idea what -Wl,--no-relax does
<xnox> and why that is _removed_
<xnox> i'll email doko
<rbalint> xnox,slangasek: yes, ocaml was on the PIE rebuild list because as far as i remember lwt failed to build on arm64 artful without PIE-d ocaml
<rbalint> like it did fail to build on Debian as well when i tested the PIE rebuild #837669
<rbalint> i don't have the failing log because i have an the email saying that build failed but the linked log seems to be replaced with a successful run
<rbalint> by launchpad
<xnox> rbalint, yes there is only one build-log per upload per arch.
<rbalint> xnox: when i tested ocaml build it picked static libs from _system's_ ocaml #837359, thus converting to PIE looks like 1. enable PIC, 2. rebuild with PIE, 3. (optional) drop PIC
<rbalint> xnox: so regarding your question of PIE/PIC ocaml IMO PIC can be dropped now again
<xnox> i think we are at step 2, everywhere now, but i'm not sure. Will double check. E.g. see https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages?field.name_filter=ocaml&field.status_filter=published&field.series_filter=artful
-queuebot:#ubuntu-release- Unapproved: libepoxy (zesty-proposed/main) [1.3.1-1ubuntu1.17.04.1 => 1.3.1-1ubuntu1.17.04.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: libepoxy (xenial-proposed/main) [1.3.1-1ubuntu0.16.04.1 => 1.3.1-1ubuntu0.16.04.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.2 => 1:2.0.10-1ubuntu2.3] (core)
<slangasek> Laney: do you happen to know if there's a limit on the number of triggers that can be specified?  Because I keep trying to run 'run-autopkgtest -s artful -a i386 --trigger kf5-messagelib/4:16.12.3-0ubuntu1 --trigger kf5-kdepim-apps-libs/4:16.12.3-0ubuntu1 --trigger libkf5gravatar/4:16.12.3-0ubuntu1 --trigger libkf5pimcommon/4:16.12.3-0ubuntu1 --trigger sonnet/5.35.0-0ubuntu2 --trigger
<slangasek> akonadi-contacts/4:16.12.3-0ubuntu1 --trigger akonadi-mime/4:16.12.3-0ubuntu1 --trigger akonadi-notes/4:16.12.3-0ubuntu1 --trigger akonadi/4:16.12.3-0ubuntu1 --trigger akonadi-search/4:16.12.3-0ubuntu1 --trigger kmailtransport/16.12.3-0ubuntu1 --trigger libkf5grantleetheme/16.12.3-0ubuntu1 --trigger libkf5libkleo/4:16.12.3-0ubuntu1 --trigger libkf5pimcommon/4:16.12.3-0ubuntu1 kf5-messagelib' and
<slangasek> I see it land in the queue, then disappear again
<slangasek> Laney: btw I don't seem to be receiving any of the nuisance emails you said you set up for me
<mapreri> o.O at some point you should probably give up and use all-proposed :)
<slangasek> except I'm not sure that registers as a result for the packages in question
<mapreri> oh, in that command there is no actual package to test?  they are all --trigger
<slangasek> kf5-messagelib
<mapreri> ok, newline
<slangasek> if I split the list in half, it goes :P
<mapreri> in my (short) experience I saw stuff scheduled with all-proposed being correctly recognized as a result for the tested package, and have that test make britney happy about the triggers
<slangasek> it's not about it being a result for the /tested/ package
<slangasek> it's about having it be a result for all the other packages listed in triggers
<nacc> yeah, you'd need a separate run for each of them, then?
<nacc> as you're doing, i mean
<slangasek> it's not meant to be a run for each of them. I want a single run, with all these packages from -proposed, that's credited to all the packages in the list
<nacc> slangasek: actually, no matter what, wouldn't it only show up in the tested package's results?
<slangasek> because this is a KDE transition and I don't actually need the test suite to run 14 times
<nacc> slangasek: right, i get that
<slangasek> nacc: it shows up in the results of each of the packages listed as --trigger
<nacc> slangasek: oh interesting, I guess I didn't realize that, but it makes sense
<slangasek> but if I don't list the triggers, I don't think autopkgtest is smart enough to credit the passing result for every package that happened to be pulled from -proposed with --all-proposed
<nacc> slangasek: yeah, I don't think it does either
<nacc> slangasek: and i (honestly) thought it didn't in general until you just TIL'd me
<mapreri> (same)
<slangasek> ok, I can confirm now that I have the tests running that I want, having split the trigger lists.  What I don't know is why they didn't go before
<slangasek> or if I'll actually get results back :P
<nacc> slangasek: heh
<slangasek> http://autopkgtest.ubuntu.com/running#pkg-kf5-messagelib
<slangasek> fun
<slangasek> completely blank output from the runners?
#ubuntu-release 2017-06-24
-queuebot:#ubuntu-release- New binary: node-os-browserify [amd64] (artful-proposed/none) [0.2.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (trusty-proposed) [1.27~14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (xenial-proposed) [1.30~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (zesty-proposed) [1.30~17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (trusty-proposed) [1.30~14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (yakkety-proposed) [1.30~16.10.1]
<slangasek> LocutusOfBorg: hi, so is this you blindly retrying the armhf haskell builds?
<LocutusOfBorg> slangasek, no, I did retry some builds in the 19-20-21 tonight
<LocutusOfBorg> and the side effect was that I retried also them
<LocutusOfBorg> sorry if you got a lot of emails
<slangasek> LocutusOfBorg: hmm, ok.  well, somebody (or multiple somebodies) are leaning on the retry button ;)
<LocutusOfBorg> it was some automatic tool :)
<LocutusOfBorg> not me, not anymore
<LocutusOfBorg> since I woke up
<acheronuk> slangasek: did a rebuild of KDE zanshin which depends on KDE PIM https://launchpad.net/ubuntu/+source/zanshin ; so that needs the same removal of binaries due to non building architectures now I think
<slangasek> LocutusOfBorg: I fixed haskell-cryptonite this evening, and have scheduled rebuilds of the rest of the stack above it
<LocutusOfBorg> I see
<LocutusOfBorg> :)
<LocutusOfBorg> I'm fixing right now *yesod*
<slangasek> acheronuk: already removed
<LocutusOfBorg> oops, I mean *prelude*
<acheronuk> slangasek: :) thank you
<LocutusOfBorg> the main showstoppers now are ada and xmlhtml
<mapreri> I also noticed somebody retrying a failed build of opencv/s390x at least 4 times in not even 2 hours yesterday night.  when the issue was an installability problem fixed later (and then I successfully retried the build).
<mapreri> i.e. that guy didn't care of watching the build logâ¦
<LocutusOfBorg> prelude should be ready for upload
<LocutusOfBorg> mapreri, why can't they be 4 different people?
<mapreri> LocutusOfBorg: what are you doing with prelude?
<LocutusOfBorg> haskell-prelude
<mapreri> they can, but I don't think they are.  call it a hunch :)
<LocutusOfBorg> mapreri, I retried it once, but only one single time
<mapreri> ah, ok, carry on with haskell *shrugs*
<LocutusOfBorg> because I also retried git and something else, then I looked at vtk6 and everything was in place
<LocutusOfBorg> so, I stopped caring about opencv
<LocutusOfBorg> it was probably python, right?
<mapreri> no, it was opempio
<mapreri> openmpi*
<LocutusOfBorg> oh yeah yes
<LocutusOfBorg> I remember now
<LocutusOfBorg> yeah the nice transition
<mapreri> fixed with -6
<LocutusOfBorg> what could possibly go wrong
<mapreri> it wasn't a transition, was it?
<LocutusOfBorg> you will know when reverse-dependencies will start breaking
<mapreri> :(
<LocutusOfBorg> openmpi can be sooo funny
<acheronuk> mapreri: I retried just once. Then looked at the build log and realised :/
<acheronuk> dunno who did the other 3
<mapreri> that's already 2 people
<mapreri> don't tell me LocutusOfBorg was right
<slangasek> :D
<slangasek> it wasn't me
<LocutusOfBorg> mapreri :)
<LocutusOfBorg> prelude* is in dep-wait and building
<LocutusOfBorg> slangasek, what is next step? remove that bunch of armhf stuff? I looked a lot, and I don't really know how to solve
<LocutusOfBorg> agda and xmlhtml
<slangasek> could be
<slangasek> xmlhtml also failed on i386, so it may be a 32-bit problem?  Did this fail in Debian?
<mapreri> could you please remind me how often ubuntu's britney runs?
<LocutusOfBorg> xmlhtml I opened an issue upstream
<LocutusOfBorg> confirm, I think this is a general 32 bit issue
<slangasek> mapreri: it runs 5 minutes after the previous one finishes
<LocutusOfBorg> I can't know debian because slowlyness of builders
<mapreri> that's Very Oftenâ¢
<LocutusOfBorg> no, i386 has failed
<LocutusOfBorg> armhf is slow, but meh
<LocutusOfBorg> also kfreebsd-i386 is sad, I think I reported that upstream
<LocutusOfBorg> lets see how bad I was tonight at fixing/reporting stuff
<LocutusOfBorg> https://github.com/snapframework/xmlhtml/issues/30
<LocutusOfBorg> the funny thing IIRC this is a new test, so it has been probably broken since forever :)
<LocutusOfBorg> something is telling me "ehi disable testsuite", but I won't listen to it
<LocutusOfBorg> hgettext testsuite depends on cabal-install sigh
<LocutusOfBorg> so, probably it needs to go away or be silented
<acheronuk> E: [Sat Jun 24 18:00:50 2017] - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/c/carton/20170623_115845_812ba@/result.tar is damaged, ignoring: "filename 'testpkg-version' not found"
<acheronuk> quite a few errors like that in the full migration output logs
<acheronuk> which seems to be associated with tests thate are "running" forever in excuses, but not in the running tests @ http://autopkgtest.ubuntu.com/running
<slangasek> acheronuk: where are you looking that you see that error?
<acheronuk> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-06-24/18:47:36.log
<acheronuk> raw logs which I sometimes look at if I'm impatient
<acheronuk> search down for alien-hunter a few times, and that will come eventually
<acheronuk> which seems associated with the forever "running" test reported here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libcommons-cli-java
<slangasek> acheronuk: thanks, I'll dig a bit and see what I can find
<acheronuk> I noticed the same think on some KDE tests this morning, but worked around those with the 'retry' script with '--state RUNNING' and some very specific picking of the output urls
<acheronuk> and re-running those seemed to break them out of that situation
<acheronuk> ok. thanks
<slangasek> acheronuk: btw is something supposed to be providing the 'kdepim' binary package going forward? I see that this, plus the stale ktnef binaries on arm64/ppc64el/s390x, are the only bits still in artful right now
<slangasek> so maybe that source package is ready for removal?
<slangasek> (which would clean up NBS)
<acheronuk> slangasek: AFAIK, yes. They can go. kdepim meta package was not really appropriate to be included anything produced from the kdepim split. I guess if ever decided we need to bring back a meta, it would made somewhere else
<acheronuk> slangasek: seen the bug for the removal, and that it's done. thank you
-queuebot:#ubuntu-release- New binary: haskell-raaz [ppc64el] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [amd64] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [i386] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [s390x] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [arm64] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [armhf] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-raaz [amd64] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [armhf] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [ppc64el] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted node-os-browserify [amd64] (artful-proposed) [0.2.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [arm64] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [s390x] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [i386] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [amd64] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [ppc64el] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [i386] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [s390x] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [arm64] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hackage-security [armhf] (artful-proposed/universe) [0.5.2.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [amd64] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [ppc64el] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [s390x] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [i386] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [arm64] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaqbanking [armhf] (artful-proposed/universe) [5.7.6beta-2] (no packageset)
#ubuntu-release 2017-06-25
-queuebot:#ubuntu-release- New: accepted libaqbanking [arm64] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted libaqbanking [i386] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted libaqbanking [s390x] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted libaqbanking [armhf] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted libaqbanking [ppc64el] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted libaqbanking [amd64] (artful-proposed) [5.7.6beta-2]
-queuebot:#ubuntu-release- New: accepted htslib [amd64] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted htslib [armhf] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted htslib [ppc64el] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted htslib [arm64] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted htslib [s390x] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted htslib [i386] (artful-proposed) [1.4.1-2ubuntu1]
 * acheronuk notes that simon in artful -release is gone
<acheronuk> thanks. that should sort that transition, but leave things open for a fix :)
<mapreri> slangasek, acheronuk: thank you for your help; opencv 3.1 now successfully migrated :)
<acheronuk> np. along with new Digikam :)
-queuebot:#ubuntu-release- New binary: libseqlib [amd64] (artful-proposed/universe) [1.1.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pymodbus [amd64] (artful-proposed/universe) [1.3.1-1] (no packageset)
<jbicha> infinity: can you check what happened to mercurial 4.0-1? it looks like it was accidentally deleted according to publishing history
<slangasek> jbicha: that's the known bug where copies from zesty-proposed -> artful-proposed -> artful don't work right; I'm fixing it now (<-- infinity)
-queuebot:#ubuntu-release- Unapproved: gnome-session (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted libseqlib [amd64] (artful-proposed) [1.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pymodbus [amd64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New binary: mia [s390x] (artful-proposed/universe) [2.4.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [ppc64el] (artful-proposed/universe) [2.4.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [i386] (artful-proposed/universe) [2.4.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [amd64] (artful-proposed/universe) [2.4.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [armhf] (artful-proposed/universe) [2.4.4-2ubuntu1] (no packageset)
<infinity> slangasek: Ta.
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [amd64] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [armhf] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [ppc64el] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [amd64] (artful-proposed) [2.4.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [i386] (artful-proposed) [2.4.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [s390x] (artful-proposed) [2.4.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [arm64] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [s390x] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [ppc64el] (artful-proposed) [2.4.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hackage-security [i386] (artful-proposed) [0.5.2.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [armhf] (artful-proposed) [2.4.4-2ubuntu1]
<infinity> slangasek: Speaking of AA stuff, when you did the opencryptoki removal ( https://launchpad.net/ubuntu/artful/armhf/libopencryptoki-dev ), you missed that tpm-tools became unbuildable/uninstallable on armhf (fixing now).
<slangasek> infinity: I have some recollection of removing the tpm-tools binaries too, so not sure what happened there
<slangasek> but yeah, I noticed the uninstallability and was going to chase that down once I had p-m squashed down a bit more
<infinity> slangasek: https://launchpad.net/ubuntu/artful/armhf/tpm-tools disagrees, but meh, I remember doing all sorts of things that never happened. ;)
<infinity> (The human brain sucks, apparently)
<slangasek> sure; maybe I ran the command and then closed the Internet or something
<infinity> THE WHOLE INTERNET.
<infinity> Right, that's all but 1 of http://people.canonical.com/~ubuntu-archive/proposed-migration/artful_uninst.txt sorted.  Now, what's with the top one.
<slangasek> also, the tryton-all is my doing, I was sick of watching 100 tryton modules in the p-m output
<slangasek> so I forced it, knowing that the last bit is stuck in Debian NEW
<infinity> Oh.  Yeah, it depends on a bunch of stuff that doesn't exist in the archive at all.
<infinity> Fun.
<slangasek> only a few, and AFAIK it's all in the NEW queue
<infinity> E: Package 'tryton-modules-calendar' has no installation candidate
<infinity> E: Package 'tryton-modules-calendar-classification' has no installation candidate
<infinity> E: Package 'tryton-modules-calendar-scheduling' has no installation candidate
<infinity> E: Package 'tryton-modules-calendar-todo' has no installation candidate
<infinity> E: Package 'tryton-modules-party-vcarddav' has no installation candidate
<infinity> E: Package 'tryton-modules-webdav' has no installation candidate
<infinity> We'll let the jury decide if six is a few or a bunch. :)
<infinity> But if it'll clear itself up magically, meh.
 * infinity goes back to weekending.
<slangasek> those are the deps of the old tryton-meta
<slangasek> the new one in -proposed is better
<slangasek> only tryton-modules-stock-shipment-measurements missing
<infinity> Ahh, so perhaps it just needed deleting from the release pocket to ease your transition.
<infinity> Since it has no rdeps.
<infinity> But 1 uninstallable for now probably won't cause britney to completely break the archive any time soon. :P
<slangasek> thanks hunspell, for deprecating an API but only documenting the deprecated API in your headers, not its replacement
<Laney> slangasek: limit> no I don't know; see the journal output on autopkgtest-cloud-worker/0 and work from there
<Laney> slangasek: email> To: laney@ubuntu.com, steve.langasek@ubuntu.com
<slangasek> Laney: ok; what do the emails look like?  maybe they're hiding from me
<slangasek> fwiw there were 800+ autopkgtests stuck in 'running' state, that I had to requeue several times to resolve
<slangasek> ISTR this was a pitti daily task, did he hand that over to you, Laney?
-queuebot:#ubuntu-release- New binary: libgig [ppc64el] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgig [s390x] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgig [amd64] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-compress-perl [amd64] (artful-proposed/none) [2.074-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgig [i386] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgig [arm64] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgig [armhf] (artful-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal-install [amd64] (artful-proposed/none) [1.24.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal-install [ppc64el] (artful-proposed/none) [1.24.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal-install [i386] (artful-proposed/none) [1.24.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-cabal-install [amd64] (artful-proposed) [1.24.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-cabal-install [ppc64el] (artful-proposed) [1.24.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-cabal-install [i386] (artful-proposed) [1.24.0.2-2]
-queuebot:#ubuntu-release- New: accepted libgig [armhf] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libgig [amd64] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libgig [i386] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libgig [s390x] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libgig [arm64] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libio-compress-perl [amd64] (artful-proposed) [2.074-1]
-queuebot:#ubuntu-release- New: accepted libgig [ppc64el] (artful-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New binary: haskell-cabal-install [s390x] (artful-proposed/none) [1.24.0.2-2] (no packageset)
#ubuntu-release 2018-06-18
<sil2100> Laney: hey! Did you look why some of the gstreamer cosmic packages are still stuck in -proposed?
<sil2100> I'd prefer not to release the bionic ones before the cosmic ones are in the release pocket
<sil2100> Laney: could you make sure those migrate?
<Laney> sil2100: I replied to you before, they are entangled with everything else in proposed
<sil2100> Laney: thanks! (sorry for asking twice then, probably forgot/missed it when I asked the first time during the review)
<Laney> np!
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-24.26~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-24.26~16.04.1]
<ginggs> would someone please 'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It looks like it passed once accidentally on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
-queuebot:#ubuntu-release- New binary: dgit [amd64] (cosmic-proposed/universe) [5.0] (no packageset)
-queuebot:#ubuntu-release- New binary: node-capture-stream [amd64] (cosmic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: primesieve [s390x] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [s390x] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-matcher [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lttoolbox [amd64] (cosmic-proposed/universe) [3.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-gencpp [amd64] (cosmic-proposed/universe) [0.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xmedcon [amd64] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-resolve-cwd [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmedcon [i386] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-genlisp [amd64] (cosmic-proposed/universe) [0.4.16-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [i386] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-term-size [amd64] (cosmic-proposed/none) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: primesieve [arm64] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-quick-lru [amd64] (cosmic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-uniqs [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [arm64] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: primesieve [armhf] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: more-itertools [amd64] (cosmic-proposed/universe) [4.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [amd64] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [armhf] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openhpi [s390x] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: primesieve [i386] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmedcon [arm64] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmedcon [armhf] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: primesieve [amd64] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xmedcon [s390x] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openhpi [amd64] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: openhpi [ppc64el] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [i386] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New binary: primesieve [ppc64el] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New binary: genius [ppc64el] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openhpi [arm64] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: xmedcon [ppc64el] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dgit [amd64] (cosmic-proposed) [5.0]
-queuebot:#ubuntu-release- New binary: openhpi [armhf] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lttoolbox [amd64] (cosmic-proposed) [3.4.2-1]
-queuebot:#ubuntu-release- New binary: openhpi [i386] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted more-itertools [amd64] (cosmic-proposed) [4.2.0-1]
-queuebot:#ubuntu-release- New: accepted node-matcher [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-resolve-cwd [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-uniqs [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted ros-genlisp [amd64] (cosmic-proposed) [0.4.16-3]
-queuebot:#ubuntu-release- New: accepted node-capture-stream [amd64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-term-size [amd64] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-quick-lru [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ros-gencpp [amd64] (cosmic-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted genius [amd64] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted genius [armhf] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted genius [ppc64el] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New binary: uwsgi [armhf] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New: accepted genius [arm64] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted genius [s390x] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted genius [i386] (cosmic-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New binary: uwsgi [arm64] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
-queuebot:#ubuntu-release- New: accepted openhpi [amd64] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted openhpi [armhf] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted openhpi [ppc64el] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted primesieve [amd64] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted primesieve [armhf] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted primesieve [ppc64el] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted openhpi [arm64] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted openhpi [s390x] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted primesieve [i386] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted openhpi [i386] (cosmic-proposed) [3.8.0-1]
-queuebot:#ubuntu-release- New: accepted primesieve [s390x] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted primesieve [arm64] (cosmic-proposed) [7.0+ds-3]
-queuebot:#ubuntu-release- New: accepted xmedcon [amd64] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xmedcon [armhf] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xmedcon [ppc64el] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xmedcon [arm64] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xmedcon [s390x] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xmedcon [i386] (cosmic-proposed) [0.15.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New: accepted uwsgi [i386] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (cosmic-proposed) [2.0.15-12]
-queuebot:#ubuntu-release- New binary: datalad [amd64] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
<doko> apw: please could you have a look at the linux autopkg test failures triggered by gcc?  or tell me who could do that
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.1-0ubuntu1.18.04.1 => 1:3.28.1-0ubuntu1.18.04.2] (ubuntu-desktop)
<apw> doko, yep, will figure out someone
<stgraber> could someone look at lxcfs in bionic-proposed? it's a minor fix (debian/rules) on top of the current SRU to fix an upgrade regression
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1 => 3.192.1.1] (ubuntu-desktop, ubuntu-server)
<juliank> LocutusOfBorg: please don't break versioning for update-notifier next time. you incremented the third level (3.192.1 to 3.192.2 in cosmic) where you should have gone to 3.193
 * juliank now named the bionic SRU 3.192.1.1
<juliank> Probably should bump cosmic to 3.193
<juliank> But I saw no point in doing that for 3.192.{4,5} given that the versioning was broken anyway
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0~beta2-6865-gec43e47e6-0ubuntu1 => 2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-notifier (artful-proposed/main) [3.186.2 => 3.186.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.8 => 3.168.9] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
<LocutusOfBorg> sorry juliank !
<LocutusOfBorg> can anybody please check rfkill?
<rbasak> I just commented.
<LocutusOfBorg> lovely thanks
<rbasak> I'm not sure it's necessary to add a dependency, but feel free to tell me why I'm wrong.
<LocutusOfBorg> I answered...
<LocutusOfBorg> I honestly have no strong point
<LocutusOfBorg> we added new aircrack-ng to backbox ppa and discovered this issue
<LocutusOfBorg> since the patch you think might be trivial, can you please share it?
<LocutusOfBorg> I would like to avoid conditionalizing the call, but you might have a smarter approach in mind I'm not aware of...
<LocutusOfBorg> like dpkg -l ?
 * LocutusOfBorg goes catching a train
<rbasak> LocutusOfBorg: the common pattern is to use test -x or similar.
<rbasak> It does involve hardcoding the expected location of udevadm
<rbasak> Or you do it via command -v etc.
<rbasak> command -v udevadm >/dev/null && udevadm ...
<rbasak> LocutusOfBorg: || true is fine also I think
<rbasak> LocutusOfBorg: all of those options are better than adding the dependency I think
<rbasak> For fixing this particular use case at least.
-queuebot:#ubuntu-release- New binary: ruby-encryptor [amd64] (cosmic-proposed/none) [3.0.0-2] (no packageset)
<stgraber> infinity: can you let that follow-up lxcfs upload in (bionic-proposed, fixes regression in SRU currently in -proposed)?
-queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
<LocutusOfBorg> rbasak, I fixed up
<LocutusOfBorg> ^^
<LocutusOfBorg> (probably removing this postinst file is even a better fix, since this was a leftover until xenial release
<LocutusOfBorg> but meh, somebody might still be upgrading from trusty
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.2ubuntu1~18.04.0]
<stgraber> slangasek, bdmurray: either of you around to look at that lxcfs upload? (nagging because anyone upgrading to the current one in -proposed will have all their containers crash)
<bdmurray> stgraber: I am
<stgraber> bdmurray: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (bionic-proposed) [3.0.1-0ubuntu2~18.04.1]
-queuebot:#ubuntu-release- New binary: watcher [amd64] (cosmic-proposed/universe) [1:1.8.0-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: neutron [amd64] (cosmic-proposed/main) [2:13.0.0~b2-0ubuntu2] (openstack, ubuntu-server)
<tsimonq2> I was thinking of doing a Qt transition at the end of this week but by the looks of -proposed that would probably be bad.
<tsimonq2> Are there any overarching transitions I can help with? I see a lot of R stuff and a lot of Haskell stuff.
#ubuntu-release 2018-06-19
<tsimonq2> This that
<tsimonq2> whoops
<tsimonq2> (TIL Ctrl + M sends messages O_o)
<sarnold> ^M == \r  :)
<sarnold> next up try ^J and see what that does
<sarnold> ^J == \n
<tsimonq2> hm, test
<tsimonq2> OH
<tsimonq2> hah
<tsimonq2> :)
<doko> tsimonq2: there are haskell ftbfs on armhf and later on on s390x.
<doko> tsimonq2: I think ginggs would welcome looking at r-* autopkg test issues
<doko> tsimonq2: openmpi on armhf as well
<tsimonq2> doko: ack
<tsimonq2> doko: Was it ever decided to disable the autosyncer temporarily? I saw something in the Foundations standup AOB...
<tsimonq2> doko: Might be a good idea, just in case someone else decides to firehose some stuff into Debian...
<doko> tsimonq2: I can only propose it ... but it doesn't help either, if nobody is committing to work on issues
<tsimonq2> doko: True. I can personally only help so much; this is the first time I've poked around in R and Haskell packages, so there's going to be a learning curve...
<ginggs> doko, tsimonq2: morning! med-fichier built on armhf in debian yesterday (openmpi) - I asked pochu to gb the other openmpi/armhf failures to see what happens
<ginggs> https://buildd.debian.org/status/logs.php?pkg=med-fichier&arch=armhf - still ftbfs in ubuntu though
<ginggs> R is pretty much done, I think - just need someone from ~ubuntu-release to kick some hints along
<ginggs> but R cannot migrate on its own, it's entangled with openmpi
<tsimonq2> Yay, empty queues... I'll kick some autopkgtests.
<doko> ginggs: is it known why it fails? I don't see any FAILs or ERRORs in the log
<doko> tsimonq2: please retry the openmpi ones too (using all-proposed)
<ginggs> doko: why what fails?
<tsimonq2> doko: Yep, that's what I was looking at.
<doko> ginggs: med-fichier
<doko> python-numpy looks sad as well, but it non-blocking
<doko> ahh, no it's blocking too
<ginggs> doko: anything that runs an mpi test during build, or autopkgtest, locks up on armhf and eventually times out
<tsimonq2> doko: Retried a fair amount of openmpi test failures with all-proposed.
<doko> fair amount, or all?
<tsimonq2> `retry-autopkgtest-regressions --all-proposed --blocks openmpi` so all the regressed ones. I agree that the armhf ones are timing out, and running with all-proposed enabled will certainly turn a few other ones green.
<tsimonq2> Once those are done, let's see what's left.
<tsimonq2> I have a feeling some of these can be hinted...
 * tsimonq2 goes to sleep - I'll have a poke at things later and see if I can progress things.
<ginggs> tsimonq2: gnight!
<tsimonq2> o/
<doko> ginggs: disabled mpi on armhf for now in med-fichier. same as on arm64
<ginggs> doko: ok, i don't follow how this helps though
<ginggs> looking at https://people.canonical.com/~ubuntu-archive/transitions/html/openmpi3.html
<ginggs> I think you can RM molds and nwchem, they are not in debian testing either
<doko> tsimonq2: https://launchpad.net/ubuntu/+source/amarok/2:2.9.0-0ubuntu3 just a no-change rebuild ...
<ginggs> doko: and if you RM nwchem, then you can RM blacs-mpi too LP: #1771087
<ubot5> Launchpad bug 1771087 in blacs-mpi (Debian) "Please remove src:blacs-mpi" [Unknown,Incomplete] https://launchpad.net/bugs/1771087
<doko> ginggs: it fixes the ftbfs
<doko> ginggs: both removed
<acheronuk> doko: fixed amarok uploaded
<doko> ginggs: removed molds too
<apw> doko, that linux regresion is an test suite problem and is now hinted
<doko> ginggs: what about building elpa on armhf without mpi?
<doko> apw: ta
<doko> ginggs: no, I mean p4est
<doko> ... and I removed the blocking dune* binaries
<ginggs> doko: "it fixed the ftbfs" yes, but it seems that mpi is broken on armhf, so is there a point?
<ginggs> doko: for p4est rather just remove the old armhf binary
<ginggs> doko: p4est's only rdep is deal.ii, which only builds on 64-bit
<doko> ginggs: ok, doing that
<ginggs> doko: thanks
-queuebot:#ubuntu-release- New: accepted datalad [amd64] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-encryptor [amd64] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted neutron [amd64] (cosmic-proposed) [2:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted watcher [amd64] (cosmic-proposed) [1:1.8.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (bionic-proposed/main) [1.7-0ubuntu3 => 1.7-0ubuntu3.2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-attr-encrypted [amd64] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
<ginggs> would someone please 'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It passed once by accident on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
-queuebot:#ubuntu-release- New binary: neutron-fwaas [amd64] (cosmic-proposed/main) [1:13.0.0~b2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (cosmic-proposed/universe) [2:13.0.0~b2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: neutron-vpnaas [amd64] (cosmic-proposed/main) [2:13.0.0~b2-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- New binary: neutron-lbaas [amd64] (cosmic-proposed/universe) [2:13.0.0~b2-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [amd64] (cosmic-proposed) [2:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted neutron-lbaas [amd64] (cosmic-proposed) [2:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-qinlingclient [source] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted neutron-fwaas [amd64] (cosmic-proposed) [1:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ruby-attr-encrypted [amd64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted neutron-vpnaas [amd64] (cosmic-proposed) [2:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New binary: python-qinlingclient [amd64] (cosmic-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-qinlingclient [amd64] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: atheme-services [ppc64el] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [ppc64el] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-atomicwrites [amd64] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: atheme-services [amd64] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: atheme-services [i386] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: atheme-services [arm64] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [amd64] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: atheme-services [armhf] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [i386] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: atheme-services [s390x] (cosmic-proposed/universe) [7.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [arm64] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [armhf] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [ppc64el] (cosmic-proposed/universe) [2.1.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [i386] (cosmic-proposed/universe) [2.1.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [s390x] (cosmic-proposed/universe) [2.1.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [amd64] (cosmic-proposed/universe) [2.1.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: vitrage [amd64] (cosmic-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [arm64] (cosmic-proposed/universe) [2.1.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry [s390x] (cosmic-proposed/universe) [1.12.0-2] (no packageset)
<ginggs> doko: openmpi definitely seems to be fixed in debian now: https://buildd.debian.org/status/logs.php?pkg=p4est&arch=armhf
-queuebot:#ubuntu-release- New: accepted atheme-services [amd64] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted atheme-services [armhf] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted atheme-services [ppc64el] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted python-atomicwrites [amd64] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted atheme-services [arm64] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted atheme-services [s390x] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted atheme-services [i386] (cosmic-proposed) [7.2.9-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry [amd64] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry [armhf] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry [ppc64el] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted vitrage [amd64] (cosmic-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted ros-geometry [arm64] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry [s390x] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry [i386] (cosmic-proposed) [1.12.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.33+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.33~14.04]
<LocutusOfBorg> can we drop now the "v5" package renaming and go back in sync with debian?
-queuebot:#ubuntu-release- New: accepted gudhi [amd64] (cosmic-proposed) [2.1.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gudhi [i386] (cosmic-proposed) [2.1.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gudhi [s390x] (cosmic-proposed) [2.1.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gudhi [arm64] (cosmic-proposed) [2.1.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gudhi [ppc64el] (cosmic-proposed) [2.1.0+dfsg-3]
-queuebot:#ubuntu-release- New binary: zaqar [amd64] (cosmic-proposed/universe) [7.0.0~b1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: flatpak (bionic-proposed/universe) [0.11.7-0ubuntu0.1 => 0.11.8.3-0ubuntu0.1] (ubuntugnome)
<ginggs> LocutusOfBorg: I think you'll need appropriate Breaks/Replaces until the next LTS release
<doko> ginggs, LocutusOfBorg: no these were introduced before 14.04 LTS
-queuebot:#ubuntu-release- New: accepted swauth [amd64] (artful-proposed) [1.2.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.14 => 1:17.10.15] (core)
-queuebot:#ubuntu-release- New: accepted swauth [amd64] (bionic-proposed) [1.3.0-1ubuntu1]
<LocutusOfBorg> doko, "no" means "ok drop them now?"
<doko> yes
<LocutusOfBorg> wonderful
<LocutusOfBorg> maybe from the next debian upload then
<LocutusOfBorg> and meh, they will require a transition and a trip in new queue :/
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.1 => 0.130ubuntu3.2] (core)
<doko> please ignore the liggghts/3.7.0+repack1-1build1 failure on armhf. I removed the binary packages on armhf
<doko> ginggs: openmpi itself is now migratable
<doko> however python-numpy and r-base are blocking
<ginggs> doko: we need someone from ubuntu-release to update some hints
<ginggs> doko: some of python-numpy's rdeps need updates or removal though - i think they are genuinely broken with the new numpy
<Odd_Bloke> doko: So hg-git upstream have some fixes for new hg/new dulwich, but their test suite still fails due to emitted deprecation warnings (https://bitbucket.org/durin42/hg-git/issues/246/devel-warn-compatibility-issues-in-tests); do you think a patch to modify their tests to expect the warnings is reasonable to get them passing?
<tsimonq2> Morning.
<tsimonq2> slangasek: bug 1757858 fixed by removing robojournal, Debian bug 901447. Could I please get a removal?
<ubot5> bug 1757858 in robojournal (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757858
<ubot5> Debian bug 901447 in ftp.debian.org "RM: robojournal -- ROM; dead upstream" [Normal,Open] http://bugs.debian.org/901447
<doko> Odd_Bloke: this, or not not running some tests
<ginggs> doko: btw, i believe r-cran-rmarkdown's autopkgtest failures are due to missing pandoc
<ginggs> err r-cran-rmarkdown
<ginggs> oh, got it first time :)
<Odd_Bloke> doko: Ack; I have meetings now, but should have time to prepare a new upload soon.
<sil2100> smoser: hey! I'm looking at the netinfo_to_netplan changes in initramfs-tools for bionic SRU right now
<sil2100> eh, not here, derp
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.11 => 0.122ubuntu8.12] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (artful-proposed/main) [0.125ubuntu12.1 => 0.125ubuntu12.2] (core)
-queuebot:#ubuntu-release- New binary: openstack-trove [amd64] (cosmic-proposed/universe) [1:10.0.0~b1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kubectx [amd64] (cosmic-proposed/none) [0.5.0-1] (no packageset)
<tsimonq2> slangasek: bug 1757663, ike, Debian bug 900380
<ubot5> bug 1757663 in ike (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757663
<ubot5> Debian bug 900380 in ftp.debian.org "RM: ike -- RoQA; dead upstream, orphaned, RC-buggy" [Normal,Open] http://bugs.debian.org/900380
-queuebot:#ubuntu-release- New binary: golang-github-atotto-clipboard [amd64] (cosmic-proposed/none) [0.0~git20180322.5e2c7bd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcode-tidyall-plugin-yaml-perl [amd64] (cosmic-proposed/none) [0.000001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cyphar-filepath-securejoin [amd64] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-gorethink-gorethink.v3 [amd64] (cosmic-proposed/none) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ibmquantumexperience [amd64] (cosmic-proposed/none) [1.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libversion-compare-perl [amd64] (cosmic-proposed/none) [0.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-googleapis-gnostic [amd64] (cosmic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplack-request-withencoding-perl [amd64] (cosmic-proposed/none) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset [ppc64el] (cosmic-proposed/none) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libweasel-widgets-dojo-perl [amd64] (cosmic-proposed/none) [0.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [ppc64el] (cosmic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset [amd64] (cosmic-proposed/none) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [amd64] (cosmic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset [i386] (cosmic-proposed/none) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset [arm64] (cosmic-proposed/none) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset [armhf] (cosmic-proposed/none) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [arm64] (cosmic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [i386] (cosmic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [armhf] (cosmic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (artful-proposed) [0.125ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.12]
<Odd_Bloke> doko: http://paste.ubuntu.com/p/BQzbJZnwtM/
-queuebot:#ubuntu-release- New binary: haskell-enummapset [s390x] (cosmic-proposed/universe) [0.5.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2-ttf [s390x] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.1 => 0.130ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (artful-proposed) [0.125ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.12]
-queuebot:#ubuntu-release- New binary: sahara [amd64] (cosmic-proposed/universe) [1:9.0.0~b2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.11 => 0.122ubuntu8.12] (core)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1 => 1.1ubuntu1.18.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (artful-proposed/main) [0.125ubuntu12.1 => 0.125ubuntu12.2] (core)
-queuebot:#ubuntu-release- New: accepted golang-github-atotto-clipboard [amd64] (cosmic-proposed) [0.0~git20180322.5e2c7bd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-googleapis-gnostic [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [amd64] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [armhf] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [ppc64el] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cyphar-filepath-securejoin [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [arm64] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [s390x] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-gorethink-gorethink.v3 [amd64] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset [i386] (cosmic-proposed) [0.5.2.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [amd64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [armhf] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [ppc64el] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ibmquantumexperience [amd64] (cosmic-proposed) [1.9.2-1]
-queuebot:#ubuntu-release- New: accepted libcode-tidyall-plugin-yaml-perl [amd64] (cosmic-proposed) [0.000001-1]
-queuebot:#ubuntu-release- New: accepted libversion-compare-perl [amd64] (cosmic-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [arm64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [s390x] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted libplack-request-withencoding-perl [amd64] (cosmic-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2-ttf [i386] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted libweasel-widgets-dojo-perl [amd64] (cosmic-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted kubectx [amd64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected rfkill [source] (xenial-proposed) [0.5-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected rfkill [source] (xenial-proposed) [0.5-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected rfkill [source] (xenial-proposed) [0.5-1ubuntu3.1]
#ubuntu-release 2018-06-20
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.39-0ubuntu1 => 1.40-0ubuntu0.18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.39-0ubuntu1 => 1.41-0ubuntu0.18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<ginggs> would someone please 'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It passed once by accident on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
<RAOF> Bah! Why is gst-plugins-bad1.0 not migrating to cosmic?
<RAOF> It, and all of it's dependencies, appear to be valid candidates in update_excuses.
<apw> RAOF, your answer will be in update_output.txt
<RAOF> And update_output is rather inscrutable.
<RAOF> Is the skippedâ¦. s390x:  <big long list of packages> the list of packages that an update would make uninstallable?
<apw> RAOF, yeah so migrating all the valid things would make that mess (only one arch is reported iirc and not always the same one)
<apw> RAOF, pming you some bits
<Laney> It ends up being entangled in other transitions
-queuebot:#ubuntu-release- Unapproved: dovecot (bionic-proposed/main) [1:2.2.33.2-1ubuntu4 => 1:2.2.33.2-1ubuntu4.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
<LocutusOfBorg> bdmurray, ^^ thanks for the reject :)
-queuebot:#ubuntu-release- Unapproved: accepted openipmi [source] (bionic-proposed) [2.0.22-1.1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted openipmi [source] (artful-proposed) [2.0.22-1.1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted openipmi [source] (xenial-proposed) [2.0.18-0ubuntu11.2]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (artful-proposed) [3.186.3]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.9]
<doko> RAOF: it usually helps if you can fix blocking issues
-queuebot:#ubuntu-release- Unapproved: accepted rfkill [source] (xenial-proposed) [0.5-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (artful-proposed) [1:17.10.15]
-queuebot:#ubuntu-release- Unapproved: accepted boinc [source] (bionic-proposed) [7.9.3+dfsg-5ubuntu2]
<sil2100> rbasak: would you mind if I review initramfs-tools for xenial/artful now?
<sil2100> rbasak: I was supposed to review it yesterday but it had some issues that only got fixed after my EOD
-queuebot:#ubuntu-release- New: accepted openstack-trove [amd64] (cosmic-proposed) [1:10.0.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted zaqar [amd64] (cosmic-proposed) [7.0.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sahara [amd64] (cosmic-proposed) [1:9.0.0~b2-0ubuntu1]
<rbasak> sil2100: sure - I'm done processing SRUs for today.
-queuebot:#ubuntu-release- New binary: networking-sfc [amd64] (cosmic-proposed/universe) [7.0.0~b2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: networking-ovn [amd64] (cosmic-proposed/universe) [5.0.0~b2-0ubuntu2] (no packageset)
<juliank> Laney, sil2100 https://trello.com/c/RAnrwNw1/17-make-the-retry-button-reuse-the-same-triggers-as-the-last-run
<juliank> does this make sense, smarter retry button for autopkgtest?
<sil2100> juliank: I would say yes, since I actually would expect it to work like that
<Laney> what makes the last set of triggers the right set and not someone randomly playing around (e.g. adding all-proposed)?
<Laney> Like, if you added a trigger and there's a retry button still, sounds like that means the run failed and the trigger wasn't right/enough anyway
<doko> Laney: how would you determine the minimal set of triggers? e.g. for vtk7, triggered by openmpi?
<Laney> doko: not sure what that has to do with what the retry button does?
<Laney> (Note that you can retry with a previous run's set of triggers from autopkgtest.u.c already)
<doko> I'm not aware of that. how would I do that?
<Laney> http://autopkgtest.ubuntu.com/packages/python-pydap/cosmic/armhf
<Laney> See the links there for example
<doko> hmm, so how did ginggs find out about these triggers?
<Laney> I don't know, some domain specific knowledge?
<Laney> This seems orthogonal to the original question to me
<doko> right, domain specific knowledge for any random package
<Laney> It would have been better for the maintainer to have specified that a newer numpy was required there.
 * ginggs searched for update_excuses for python-pydap looking for other packages that it needed to be tested against
<doko> Laney: the original thing is that with every new openmpi upload, the tests triggered by openmpi are failing again. and how best to fix that
<Laney> The original thing to me was a question about uthe retry button.
<doko> yes, because I usually retrigger the openmpi tests with all-proposed=1
<Laney> If new openmpi uploads break previously built things, it sounds like that should be expxressed in the package somehow.
<doko> so add a delta just for the autopkg tests and hope that nobody discards that with the next sync?
<Laney> I said 0 of the things you just asserted.
<doko> "should be expxressed in the package somehow"
<doko> but maybe I'm not reading between the lines
<Laney> It almost certainly should *not* be a delta, for one.
<Laney> And it's not clear that this would be "just" for the tests.
<Laney> If it's possible to install a broken set of packages, that'd probably apply to non-test usecases too.
<doko> so you mean to express this by a hint?
<Laney> No, more like a versioned package relationship.
<ginggs> a new upload of openmpi upload doesn't break things, britney runs the tests against the versions of the packages in testing instead of in proposed - all of the tests need to triggered again
<Laney> ginggs: What is wrong about the versions in testing that they fail?
<ginggs> Laney: they are compiled against openmpi2 not openmpi3
<ginggs> this discussion should probably go to #debci
<ginggs> britney needs to learn there's a transition going on and trigger the right group of packages together
<Laney> Sorry, we went on an extreme tangent from a simple question about the generated retry button and I don't really have time to get into this in depth.
<ginggs> regarding the retry button, I think it would be really useful if successful tests also had a retry button, so I could copy the link and make a minor change
<ginggs> ...on this page http://autopkgtest.ubuntu.com/packages/python-pydap/cosmic/armhf not update_excuses
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (artful-proposed) [0.125ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.12]
-queuebot:#ubuntu-release- New: accepted networking-ovn [amd64] (cosmic-proposed) [5.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted networking-sfc [amd64] (cosmic-proposed) [7.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New binary: senlin [amd64] (cosmic-proposed/universe) [6.0.0~b2-0ubuntu1] (no packageset)
<mitya57> Can someone please mark three autopkgtests that block sphinx migration as ignored failures? pyfai/amd64, python-asdf/armhf and xonsh (all archs)
<mitya57> I have verified that they have nothing to do with sphinx, and not trivial to fix
-queuebot:#ubuntu-release- New binary: puppet-module-arioch-redis [amd64] (cosmic-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: c-sig [amd64] (cosmic-proposed/universe) [3.8-22] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-turbolinks-source [amd64] (cosmic-proposed/none) [5.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-ovn [amd64] (cosmic-proposed/none) [13.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-websocket [amd64] (cosmic-proposed/none) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-ccs-perl [amd64] (cosmic-proposed/none) [1.23.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-congress [amd64] (cosmic-proposed/none) [13.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcite [amd64] (cosmic-proposed/universe) [1.60-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-ccs-perl [i386] (cosmic-proposed/none) [1.23.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-gnocchi [amd64] (cosmic-proposed/none) [13.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ironic-inspector [amd64] (cosmic-proposed/universe) [7.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted puppet-module-arioch-redis [amd64] (cosmic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-gnocchi [amd64] (cosmic-proposed) [13.1.0-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-congress [amd64] (cosmic-proposed) [13.1.0-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-ovn [amd64] (cosmic-proposed) [13.1.0-1]
-queuebot:#ubuntu-release- New: accepted c-sig [amd64] (cosmic-proposed) [3.8-22]
-queuebot:#ubuntu-release- New: accepted ruby-turbolinks-source [amd64] (cosmic-proposed) [5.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted senlin [amd64] (cosmic-proposed) [6.0.0~b2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ironic-inspector [amd64] (cosmic-proposed) [7.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xcite [amd64] (cosmic-proposed) [1.60-4]
-queuebot:#ubuntu-release- New: accepted ruby-websocket [amd64] (cosmic-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted libpdl-ccs-perl [amd64] (cosmic-proposed) [1.23.8-1]
-queuebot:#ubuntu-release- New: accepted libpdl-ccs-perl [i386] (cosmic-proposed) [1.23.8-1]
<doko> ginggs: r-base:  r-cran-rmarkdown/armhf and /s390x, r-cran-yaml/i386 r-cran-memoise/armhf  still failing. did you look at any of those?
<doko> no debian reports yet
<doko> r-cran-rmarkdown is a leaf package
-queuebot:#ubuntu-release- New binary: monero [amd64] (cosmic-proposed/universe) [0.12.2.0~dfsg-1] (no packageset)
<LocutusOfBorg> hello chrisccoulson, are you aware of the dh-cargo/amd64 unsatisfiable Depends: cargo (>= 0.27.0-2)  issue?
<ginggs> doko:  r-cran-rmarkdown/armhf and /s390x is due to missing haskell/pandoc
<ginggs> doko:  r-cran-yaml/i386 is a regression due to new r-cran-yaml, r-cran-memoise is a alignment regression due to new r-cran-memoise - none are caused by the new r-base
-queuebot:#ubuntu-release- New: accepted monero [amd64] (cosmic-proposed) [0.12.2.0~dfsg-1]
<ginggs> would someone please 'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It passed once by accident on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
 * enyc sneezes....
-queuebot:#ubuntu-release- New source: qemu-ovmf-secureboot (cosmic-proposed/primary) [1.1.2-0ubuntu1]
#ubuntu-release 2018-06-21
<ginggs> would someone please RM old htseq binaries on armhf, i386 and s390x? it B-D on python-pysam which is not avaiable on those
<doko> ginggs: hmm, they are not available?
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.1.0 => 1.2.0~bionic] (no packageset)
<ginggs> doko: so what blocks htseq then? according to update_excuses it is missing build on armhf, i386 and s390x
<doko> ginggs: update_excuses only tells you about a missing build, not about the status of earlier uploads
<doko> ahh, the -doc package ...
-queuebot:#ubuntu-release- New: rejected qemu-ovmf-secureboot [source] (cosmic-proposed) [1.1.2-0ubuntu1]
<doko> done
<ginggs> doko:  thanks!
<cpaelzer> where was that from?
<cpaelzer> dannf was that you ^^?
<doko> LocutusOfBorg: could you have a look at the python-mechanicalsoup autopkg tests? failing both in Debian and Ubuntu
<LocutusOfBorg> doko, will try
<LocutusOfBorg> can any AA please move linuxbrew-wrapper to multiverse?
<LocutusOfBorg> aaand why didn't it end up in new queue like it did to Debian?
<LocutusOfBorg> apw, "Move to contrib section. (Closes: #888957)"
<LocutusOfBorg> cjwatson, aren't move to contrib important for us? I'm worried about how many undetected move we missed...
<doko> LocutusOfBorg: might be as simple as mechanicalsoup.LinkNotFoundError -> mechanicalsoup.utils.LinkNotFoundError
<LocutusOfBorg> doko, thanks! I'm already setting up the cosmic VM
<ginggs> doko: btw, liggghts still shows up as a regression on armhf here https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liggghts even though i think you removed the armhf binary, i'm not sure how to clear that
<doko> ginggs: will it ftbfs when we rebuild? there is no other way to get rid off this record
<doko> well, you could hint it
<sil2100> Let me hint it in
<ginggs> sil2100: thanks, and please  'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It passed once by accident on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
<sil2100> ginggs: ACK
<doko> ginggs: but this will show up again with the next version
<ginggs> sil2100: I have some R hints that need their versions bumped too
<doko> cpaelzer: could you (or server team) have a look at the failing autopkg tests triggered by postgresql-10 ?
<sil2100> ginggs, doko: liggghts and pyfai have been badtested
<sil2100> ginggs: which packages you need bumped?
<ginggs> sil2100: looking...
<doko> <ginggs> doko:  r-cran-rmarkdown/armhf and /s390x is due to missing haskell/pandoc
<doko> <ginggs> doko:  r-cran-yaml/i386 is a regression due to new r-cran-yaml, r-cran-memoise is a alignment regression due to new r-cran-memoise - none are caused by the new r-base
<ginggs> sil200: in hints-ubuntu - force-badtest r-bioc-annotationhub/2.10.1-1 r-bioc-annotationhub/2.12.0-2 r-bioc-annotationhub/2.12.0+dfsg-1
<ginggs> sil2100: force-badtest r-bioc-biocparallel/1.14.1-1build1/s390x r-bioc-biocparallel/1.14.1-1build1/armhf
<cpaelzer> doko: I was looking at PG-10 related tests already
<cpaelzer> doko: one bug fixed, one block resolved by retries (flaky perl soemthing package) and two need a update for new versions in force-badtest
<cpaelzer> the latter is in the review queue to infinity
<ginggs> sil2100: i meant the above in hints-ubuntu/adconrad
<cpaelzer> as his britney files had the old pglogical
<doko> removed all old binaries in proposed, two weeks old ...
<cpaelzer> doko: only libpqtypes is new to me, that was not there 3 days ago
<cpaelzer> taking a look at that
<doko> ginggs: htseq migrated
<cpaelzer> doko: if you want to ack & push the britney hints please feel free https://code.launchpad.net/~paelzer/britney/hints-ubuntu-postgres-related-cosmic/+merge/348197 - otherwise I have to wait for infinity to get to it
<ginggs> sil2100: and in hints-ubuntu/stefanor - force-badtest python-xarray/0.10.2-1/i386 python-xarray/0.10.7-1/i386
<cpaelzer> will look at the new libpqtypes fail later today
<ginggs> sil2100: and - force-badtest python-xarray/0.10.2-1/arm64 python-xarray/0.10.7-1/arm64
<ginggs> sil2100: thanks in advance!
<ginggs> doko: \o/ at least something could migrate!
<sil2100> ginggs: I'll poke those in a moment
<sil2100> yw!
<doko> ginggs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/s/sfepy/20180621_072525_11bac@/log.gz where does the gomp dependency come from? can't find it in mayavi2
<doko> vtk6?
<apw> LocutusOfBorg, linuxbrew-wrapper> looking
<ginggs> doko: ENOCLUE- i wonder if building sfepy wth -O2 on ppc64el will help
<sil2100> ginggs: ok, bumped
<doko> sil2100: please could you update vorlon:force-badtest python-asdf/1.3.3-1/s390x to 2.0.1-1
<cpaelzer> doko: the linpqtypes issues are resolved now
<cpaelzer> doko: leaving only the mentioned MP to infinity open for pglogical to finally unblock it
<cpaelzer> if you are allowed to do so, please ack and merge it
<ginggs> sil2100: thanks, there's a typo in stefanor: force-badtest python-xarray/0.10.2-1/i386 python-xarray/0.10.2-1/i386  - the 2nd version should be  0.10.7-1
<cjwatson> LocutusOfBorg: I'm sure we should have something to track that, yes.  The NEW queue is probably the wrong tool - it ends up there basically for circumstantial reasons in Debian (there's no way to do a component move AIUI, you have to remove and reupload)
<LocutusOfBorg> yes cjwatson, it would be nice to do an archive sanity check for such mismatches
<LocutusOfBorg> I remember having to bother for virtualbox-ext-pack, I limit the bothering to packages I moved, I don't check what other people do...
<LocutusOfBorg> IANAL and I hate such things
<doko> LocutusOfBorg: hmm, the mechanicalsoup fix was wrong
<LocutusOfBorg> doko, yes, I'm debugging it right now
<LocutusOfBorg> upstream has a commit too
<sil2100> ginggs: whoops!
<sil2100> doko: done
<LocutusOfBorg> thanks apw
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.2-0ubuntu1.3]
<ginggs> sil2100: did you see the r-cran-rmarkdown etc, hints doko quoted me on above?
<ginggs> sil2100: force-badtest r-cran-rmarkdown/1.10+dfsg-1/armhf  r-cran-rmarkdown/1.10+dfsg-1/s390x
<ginggs> sil2100: force-badtest r-cran-yaml/2.1.19-1ubuntu1/i386
<ginggs> sil2100: force-badtest r-cran-memoise/1.1.0-2/armhf
<ginggs> and I think r-base will be ready to migrate after that!
<sil2100> I think I missed those, but I just took a look at those and will be pushing hints
<sil2100> Since they seem to be valid badtests
<sil2100> ginggs: should be done
<ginggs> sil2100: thanks again!
<sil2100> yw!
 * sil2100 goes back to his SRUs
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (bionic-proposed) [5.2.10-dfsg-6ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (bionic-proposed) [1.40-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted zlib [source] (trusty-proposed) [1:1.2.8.dfsg-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nbd [source] (bionic-proposed) [1:3.16.2-1ubuntu0.1]
<doko> ginggs: it's entangled with python-numpy
<doko> and  r-bioc-delayedarray/0.6.0+dfsg-1: armhf
<ginggs> doko: r-bioc-delayedarray/0.6.1+dfsg-1 passes
<ginggs> doko: but yeah, numpy :( sandro should have uploaded to experimental and given rdeps a chance to catch up
<doko> ginggs: we could "resolve" this dependency by removing r-cran-fastcluster and r-bioc-cummerbund from the release pocket
<ginggs> doko: no objections
<doko> did you give back the r-bioc-delayedarray tests?
-queuebot:#ubuntu-release- New binary: ros-class-loader [amd64] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
<ginggs> doko: locutus did retry-autopkgtest-regressions a little while ago, looks all green to me
-queuebot:#ubuntu-release- New binary: ros-class-loader [i386] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
<doko> ahh, didn't reload
-queuebot:#ubuntu-release- New binary: ros-class-loader [ppc64el] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-class-loader [s390x] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-class-loader [arm64] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-class-loader [armhf] (cosmic-proposed/universe) [0.4.1-2] (no packageset)
<apw> ginggs, looks like there are still two laggers for r-base to migrate
<doko> apw: which ones?
<apw> r-cran-metamix, r-cran-rmpi
<apw> though the first of those is new, so i don't see how that is uninstallable
<doko> rmpi is entabled with openmpi :-/
<apw> bugger
<doko> and openmpi with python-numpy
<doko> ok, removing rmpi as well from the release pocket. leaf package as well
<apw> doko, something's testing regressed for r-base (r-other-mott-happy) pulling it back from Valid candiate
<doko> ginggs: ^^^
<apw> ginggs, if i am reading this log right, this packages doesn't depend on R but uses it
<doko> and more autopkg test regressions
<ginggs> looks like r-other-mott-happy passed its tests for the first time ever, so makes previous 'always failed' results invalid
<apw> ginggs, and yet, from the log that looks to be completely impossible
-queuebot:#ubuntu-release- Unapproved: linux (xenial-updates/main) [4.4.0-130.156 => 4.4.0-130.156] (core, kernel) (sync)
<ginggs> apw: it seems it was 'always-failed' because it didn't have any tests, now Testsuite: autopkgtest-pkg-r in debian/control has kicked in
<ginggs> https://ci.debian.net/packages/r/r-other-mott-happy/unstable/amd64/
<apw> trying to work out how it ever passed
<ginggs> apw it didn't http://autopkgtest.ubuntu.com/packages/r-other-mott-happy/bionic/amd64
<apw> http://autopkgtest.ubuntu.com/packages/r-other-mott-happy/cosmic/amd64
<apw> ginggs, ^ yes it idid
<ginggs> it did now - but didn't ever work in the past
-queuebot:#ubuntu-release- Unapproved: rejected linux [sync] (xenial-updates) [4.4.0-130.156]
<apw> ginggs, they do look to be a noop of a test though
<apw> ginggs, though does that not also say that LocutusOfBorg got it to run since
<apw> so that is confusing ...
<ginggs> apw: 2.4-2 always fails - 2.4-3 passes - look carefully in the logs of the 11:47, 11:51 and 11:52 tests
<ginggs> Get:1 http://ftpmaster.internal/ubuntu cosmic/universe amd64 r-other-mott-happy.hbrem amd64 2.4-2 [137 kB]
<ginggs> whereas the passing test has Get:44 http://ftpmaster.internal/ubuntu cosmic-proposed/universe amd64 r-other-mott-happy.hbrem amd64 2.4-3 [214 kB]
-queuebot:#ubuntu-release- Unapproved: broadcom-sta (xenial-proposed/multiverse) [6.30.223.271-3~16.04.2 => 6.30.223.271-3~16.04.3] (no packageset)
<ginggs> it often happens that the test suite runs against a different version of the package
<apw> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/r/r-other-mott-happy/20180621_114749_38f60@/log.gz
<apw> doesn't that log say -3 though, and is a fial ?
<ginggs> Get:1 http://ftpmaster.internal/ubuntu cosmic-proposed/universe r-other-mott-happy 2.4-3 (dsc) [2161 B]
<ginggs> Get:1 http://ftpmaster.internal/ubuntu cosmic/universe amd64 r-other-mott-happy.hbrem amd64 2.4-2 [137 kB]
<apw> oh that is utterly useless
<apw> ginggs, so for that one we might well want to test it against itself again, then it will test -3 right ?
<apw> ginggs, and r-base at the same time, ugg
<ginggs> apw the trigger is r-other-mott-happy/2.4-3 it should pull in r-base/3.5.0-5 because R packages at least have a dependency on it
<ginggs> ^ if the trigger is...
-queuebot:#ubuntu-release- Unapproved: dm-writeboost (xenial-proposed/universe) [2.2.6-1~16.04.2 => 2.2.6-1~16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bcmwl (xenial-proposed/restricted) [6.30.223.271+bdcom-0ubuntu1~1.2 => 6.30.223.271+bdcom-0ubuntu1~1.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.33 => 2.33.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.33+17.10 => 2.33.1+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.33+18.04 => 2.33.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.33~14.04 => 2.33.1~14.04] (no packageset)
<dannf> cpaelzer:  qemu-ovmf-secureboot ? no idea what that is
<ginggs>     * amd64: r-cran-metamix, r-cran-rmpi - why are these still a problem?
<kenvandine> can someone please reject flatpak from the bionic-proposed queue?
<apw> kenvandine, can do, why so
<kenvandine> we are going to skip straight to 1.0
<kenvandine> they are preparing a 1.0 release now
<apw> ack
<kenvandine> apw, thx!
-queuebot:#ubuntu-release- Unapproved: rejected flatpak [source] (bionic-proposed) [0.11.8.3-0ubuntu0.1]
<apw> kenvandine, ^
<kenvandine> apw, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33.1+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.33.1+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.33.1~14.04]
<LocutusOfBorg>     * amd64: r-cran-metamix, r-cran-rmpi
<LocutusOfBorg>     * arm64: r-cran-metamix, r-cran-rmpi
<LocutusOfBorg> why are them still blocking britney and r-base to migrate?
<LocutusOfBorg> doko, apw ^^^ pleeeeeeeease
<LocutusOfBorg> new run is ongoing...
<LocutusOfBorg> (I mean auto-sync run)
<LocutusOfBorg> they are moved in proposed
<LocutusOfBorg> maybe a no.change rebuild might fix?
<teward> they don't depend on perl at all do they?  i only ask since the perl migration is holding up several of the things I've pushed into the repos too :P
<doko> LocutusOfBorg: they should not block. removed from the release pocket
<teward> just to check in, what is the current status of the perl migration?  is it still 'in progress'?  (the system keeps yelling about nginx being stuck in proposed for > 30 days to me, and I'm curious what the progress is, if any)
<doko> teward: if nobody is working on it, I would hardly call it as "in progress"
<teward> doko: well I can't tell is the thing
<teward> for all intents and purposes it *should* have migrated if autopkgtests are the only thing holding it back
<teward> but since update excuses still shows it as 'valid candidate' for perl and nginx, and nginx is held because Perl hasn't migrated yet, it tends to make me head-scratch as to "What the heck is going on"
<teward> and the latest Perl has been in the proposed for 11 days, and still says "Valid Candidate"
<teward> so, again, I ask if there's some ongoing migration that's not listed somewhere that's preventing it from automatically migrating.  last time about a month ago there was, but i haven't heard anything since
<teward> except for the archive system complaining about nginx being stuck in proposed for 30+ days
-queuebot:#ubuntu-release- New: accepted ros-class-loader [amd64] (cosmic-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ros-class-loader [armhf] (cosmic-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ros-class-loader [ppc64el] (cosmic-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ros-class-loader [arm64] (cosmic-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ros-class-loader [s390x] (cosmic-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ros-class-loader [i386] (cosmic-proposed) [0.4.1-2]
<doko> it has been there for much longer
<teward> yes, it has.  at least a month or more, because NGINX is blocked by it
<teward> which brings me back to my original question: "What's up with Perl?"
<teward> if the answer is "Nobody Knows" then my next question is "Who should I be prodding next to ask?"
<cjwatson> I just added a gdal 2.3.0 transition tracker, since that seems at least implicated.  Should show up in a bit
<cpaelzer> dannf: I found who did it, it was cyphermox
<cyphermox> dannf: I'm trying to set something up so that we can ship firmware with preloaded Microsoft certs for people to use Secure Boot from the start
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1031.35] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1031.35]
<apw> cjwatson, and i think that gdal transition tracker says that the last thing is broken because pandoc is broken
<LocutusOfBorg> doko, I know what britney says but britney says also otherwise     * arm64: r-cran-metamix, r-cran-pbivnorm, r-cran-rmpi
-queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (bionic-proposed) [1:2.2.33.2-1ubuntu4.1]
<doko> cjwatson: this is just osmcoastline, which is blocked on pandoc
<apw> which is blocked because haskell is deeply unhappy for armhf
<apw> haskell-cryptonite seems to have test-suite failures
<LocutusOfBorg> I might think wrt disabling testsuite on armhf for aes, and see how much it progresses
<LocutusOfBorg> this is a problem in Debian too BTW
<LocutusOfBorg> other things are mostly clear
<LocutusOfBorg> (pandoc is still a big problem btw)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.41-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.1]
<doko> the s390x issue is a different one, a big-endian problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897001
<ubot5> Debian bug 897001 in libghc-cmark-gfm-dev "libghc-cmark-gfm-dev: not big-endian-safe" [Serious,Open]
<bdmurray> apw: Could you look at bug 1777646 for me? I'm confused as the description mentions 4.13 but the debdiff is for 4.14.
<ubot5> bug 1777646 in bcmwl (Ubuntu Xenial) "bcmwl 6.30.223.271+bdcom-0ubuntu1~1.2 ADT test failure with linux-hwe-edge 4.15.0-23.25~16.04.1" [Undecided,Fix committed] https://launchpad.net/bugs/1777646
<apw> bdmurray, ok so the fix is to make bcwml support v4.14 and v4.15 kernels; the testing is against 4.4, 4.13, and 4.15 whihc are the various kernels that were avilable at the time, and all of which it must work with
<apw> bdmurray, this is part of preparing for linux-hwe to move to v4.15 for the point release
<bdmurray> apw: but there is not fix for 4.13 afaict
<bdmurray> s/not/no/
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (artful-proposed) [1.2ubuntu1~17.10.0]
<apw> bdmurray, right, it should already work for v4.13, just testing there to confirm it is not regressed
<doko> LocutusOfBorg: looking at update_output, I don't see this line anymore. but the list of uninstallable packages includes a lot of openmpi related things.
<LocutusOfBorg> doko, there is an hint with just
<LocutusOfBorg>     * amd64: r-cran-metamix, r-cran-rmpi
<LocutusOfBorg> left
<ginggs> doko, LocutusOfBorg: i think r-base migrated
<slangasek> tada
<ginggs> what was blocking it?
<slangasek> ginggs: the autohinter was being too greedy and including some packages that were instantly uninstallable
<ginggs> slangasek: ah ok, thanks! so did you have to manually hint it?
<slangasek> ginggs: yep
-queuebot:#ubuntu-release- Unapproved: python3-defaults (bionic-proposed/main) [3.6.5-3 => 3.6.5-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python3-defaults (artful-proposed/main) [3.6.3-0ubuntu2 => 3.6.3-0ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: sfcgal [s390x] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [ppc64el] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [i386] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
#ubuntu-release 2018-06-22
-queuebot:#ubuntu-release- New binary: sfcgal [armhf] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [arm64] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sfcgal [amd64] (cosmic-proposed/universe) [1.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted sfcgal [amd64] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted sfcgal [armhf] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted sfcgal [ppc64el] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted sfcgal [arm64] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted sfcgal [s390x] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted sfcgal [i386] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New binary: libantlr3c [i386] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libantlr3c [s390x] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [s390x] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libantlr3c [ppc64el] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [ppc64el] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libantlr3c [amd64] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [i386] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [amd64] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libantlr3c [arm64] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [arm64] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libantlr3c [armhf] (cosmic-proposed/universe) [3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [armhf] (cosmic-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libantlr3c [amd64] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libantlr3c [armhf] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libantlr3c [ppc64el] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [amd64] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [armhf] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [ppc64el] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted libantlr3c [arm64] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libantlr3c [s390x] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [i386] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted libantlr3c [i386] (cosmic-proposed) [3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [s390x] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [arm64] (cosmic-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.33.1+18.04 => 2.33.1+18.04ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.33.1+17.10 => 2.33.1+17.10ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.33.1 => 2.33.1ubuntu1] (desktop-core, ubuntu-server)
<doko> ginggs: fyi, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902102  this is blocking sundials and python-numpy
<ubot5> Debian bug 902102 in src:hypre "hypre has underlinked libraries, causing build failures with ld --as-needed" [Normal,Open]
<ginggs> doko: https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/9191674/+listing-archive-extra if you want it
<doko> ginggs: yeah, but the real issue is in hypre
<doko> please update the mercurial hint: mercurial/4.6.1-1ubuntu1/arm64. the amd64 one can be dropped
<doko> or extend: force-badtest mercurial/all/armhf to cover arm64
<sil2100> Looking in a moment
<doko> and please add python-asdf/2.0.1-1/armhf (already have it for s390x). blocking sphinx, and it's not the documentation which is failing
<sil2100> Should be done
-queuebot:#ubuntu-release- New binary: sundials [amd64] (cosmic-proposed/universe) [3.1.1+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [ppc64el] (cosmic-proposed/universe) [3.1.1+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [i386] (cosmic-proposed/universe) [3.1.1+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [arm64] (cosmic-proposed/universe) [3.1.1+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [s390x] (cosmic-proposed/universe) [3.1.1+dfsg-1ubuntu1] (no packageset)
<jibel> Yesterday's and todays cosmic desktop iso failed to build https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/cosmic/daily-live-20180622.log Could someone have a look?
-queuebot:#ubuntu-release- New: accepted sundials [amd64] (cosmic-proposed) [3.1.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted sundials [i386] (cosmic-proposed) [3.1.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted sundials [s390x] (cosmic-proposed) [3.1.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted sundials [arm64] (cosmic-proposed) [3.1.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted sundials [ppc64el] (cosmic-proposed) [3.1.1+dfsg-1ubuntu1]
<LocutusOfBorg> Laney, https://bugs.launchpad.net/ubuntu/+source/libayatana-appindicator/+bug/1770146
<ubot5> Ubuntu bug 1770146 in libayatana-appindicator (Ubuntu) "[MIR] libayatana-appindicator" [High,Incomplete]
<LocutusOfBorg> please subscribe it to the team? :)
<LocutusOfBorg> doko, after two days, I can say that mechanicalsoup has no regressed
<LocutusOfBorg> just httpbin might have changed his code
<LocutusOfBorg> https://ci.debian.net/packages/p/python-mechanicalsoup/unstable/amd64/
<LocutusOfBorg> look at the first failure, and the last good
<LocutusOfBorg> the testbed is mostly identical
<acheronuk> jibel: mate, budgie & xubuntu isos also failing in the same way :/
<LocutusOfBorg> doko, https://github.com/MechanicalSoup/MechanicalSoup/issues/213
<gitlab-bot> MechanicalSoup bug 213 in MechanicalSoup "testsuite failure (LinkNotFoundError)" (comments: 0) [Open]
<ubot5> bug 213 in Launchpad itself "The form to upload .po files is not working" [Medium,Fix released] https://launchpad.net/bugs/213
<acheronuk> Kubuntu's CI image builds (not on ubuntu infra) also failing in a similar way, but our cosmic isos on cdimage.ubuntu.com are ok. weird
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1009.12] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1009.12]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.1 => 237-3ubuntu10.2] (core)
<xnox> infinity, it has nvidia-prime drm vs logind fix; and the maintainscript fix for tmpfiles
<xnox> infinity, here is the diff of the postinst http://paste.ubuntu.com/p/DNt3gFWp8r/
<LocutusOfBorg> mdeslaur, mysql5.7 merge from debian please? :)
<rbasak> LocutusOfBorg: not really needed. I've planned one for later this cycle.
<Laney> LocutusOfBorg: have you discussed that with the team?
<LocutusOfBorg> Laney, I don't know how to discuss it, I subscribed the team, and nobody answered
<LocutusOfBorg> I don't know how to contact them :/
<LocutusOfBorg> you are my best bet
<Laney> LocutusOfBorg: you know about #ubuntu-desktop
<LocutusOfBorg> lets move there
<Laney> yes, might be a bit late right now though
<mdeslaur> LocutusOfBorg, rbasak: thanks
-queuebot:#ubuntu-release- New source: qemu-ovmf-secureboot (cosmic-proposed/primary) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.2-4-g05926e48-0ubuntu1~16.04.2 => 18.3-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [18.2-4-g05926e48-0ubuntu1~17.10.2 => 18.3-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-27-g6ef92c98-0ubuntu1~18.04.1 => 18.3-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<LocutusOfBorg> doko, mechanicalsoup fixed.
<blackboxsw> tjaalton: or slangasek if  possible today we would like to get the following cloud-init 18.3 releases queued into -proposed for xenial, artful and bionic so we can start the SRU verification timer
<blackboxsw> All are tied to the bug https://bugs.launchpad.net/bugs/1777912
<ubot5> Ubuntu bug 1777912 in cloud-init (Ubuntu) "sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-0ubuntu1)" [Undecided,New]
-queuebot:#ubuntu-release- New: accepted libocxl [source] (bionic-proposed) [1.0.0-1~ubuntu18.04.0]
-queuebot:#ubuntu-release- New binary: libocxl [ppc64el] (bionic-proposed/none) [1.0.0-1~ubuntu18.04.0] (no packageset)
<LocutusOfBorg> cyphermox, slangasek  thanks for haskell fixes all in debian now :)
<LocutusOfBorg> I'm not happy wrt armhf, but meh, at least it makes things better :D
<tjaalton> blackboxsw: sorry, public holiday here today
<slangasek> blackboxsw: I'll see what I can do
-queuebot:#ubuntu-release- New source: qemu-ovmf-secureboot (cosmic-proposed/primary) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.11-0ubuntu1 => 8.0.5.16-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [amd64] (cosmic-proposed/none) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [i386] (cosmic-proposed/none) [2.0.0-3] (no packageset)
#ubuntu-release 2018-06-23
-queuebot:#ubuntu-release- New binary: kore [ppc64el] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [arm64] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [armhf] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [s390x] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [ppc64el] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [amd64] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [i386] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [s390x] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [arm64] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kore [armhf] (cosmic-proposed/universe) [2.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cnvkit [amd64] (cosmic-proposed/universe) [0.9.3-2] (no packageset)
#ubuntu-release 2018-06-24
-queuebot:#ubuntu-release- Unapproved: libjsyntaxpane-java (bionic-proposed/universe) [0.9.6~r156-6 => 0.9.6~r156-6ubuntu0.18.04.1] (no packageset)
#ubuntu-release 2019-06-17
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [amd64] (eoan-proposed) [3ubuntu6]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [i386] (eoan-proposed) [3ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.11]
-queuebot:#ubuntu-release- Unapproved: erlang-p1-tls (bionic-proposed/universe) [1.0.20-1build1 => 1.0.20-1ubuntu0.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.02+dfsg1-12ubuntu3 => 2.02+dfsg1-12ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: apt [s390x] (eoan-proposed/main) [1.9.0] (core)
-queuebot:#ubuntu-release- New binary: apt [amd64] (eoan-proposed/main) [1.9.0] (core)
-queuebot:#ubuntu-release- New binary: apt [ppc64el] (eoan-proposed/main) [1.9.0] (core)
-queuebot:#ubuntu-release- New binary: apt [i386] (eoan-proposed/main) [1.9.0] (core)
<xnox> sil2100:  erlang-p1-tls is in bionic-proposed, a sync.... i'm sure you love those
-queuebot:#ubuntu-release- New binary: apt [armhf] (eoan-proposed/main) [1.9.0] (core)
<sil2100> xnox: on it in a moment - I love them with all my heart
<sil2100> ;)
 * xnox poders logically "meaning, if one has no heart, it means.... OMG"
<xnox> hahahahhahhaa
-queuebot:#ubuntu-release- New binary: apt [arm64] (eoan-proposed/main) [1.9.0] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.02+dfsg1-12ubuntu3 => 2.02+dfsg1-12ubuntu3] (core)
<sil2100> ;p
-queuebot:#ubuntu-release- Unapproved: accepted erlang-p1-tls [sync] (bionic-proposed) [1.0.20-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted apt [amd64] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- New: accepted apt [armhf] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- New: accepted apt [ppc64el] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- New: accepted apt [arm64] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- New: accepted apt [s390x] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- New: accepted apt [i386] (eoan-proposed) [1.9.0]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.1-0ubuntu1]
<sil2100> coreycb: hey! So I wanted to also review the nova upload for the new upstream release (disco) but I still see the previous SRU doesn't have one bug verified
<sil2100> coreycb: I see someone tested the PPA packages, but not the -proposed ones
<coreycb> sil2100: ok thanks we'll push on getting the other one verified for nova
<coreycb> sil2100: just to be clear were you referring to this one? https://bugs.launchpad.net/nova/+bug/1808951
<ubot5> Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged]
<coreycb> sil2100: we also have a high priority fix for python-glance-store in the cosmic unapproved queue if you have a moment to take a look at that. it's a small fix.
 * didrocks is a little bit puzzled why grub2 binary packages on amd64 and arm64 are in eoan unapproved queue
<didrocks> there is no new binary package or whatsoever
<apw_> didrocks, they carry an efi signing component; which is always manually reviewed
<vorlon> oSoMoN: have you seen handsome_feng's latest comments on LP: #1832656?  Will you support preseeding of chromium on flavor images (which means, opening and closing a stable/ubuntu-19.10 channel for the snap)?
<ubot5> Launchpad bug 1832656 in livecd-rootfs (Ubuntu Eoan) "chromium-browser deb->snap transition breaks ubuntukylin image builds" [High,Triaged] https://launchpad.net/bugs/1832656
<oSoMoN> vorlon, yes, I'll do that
<oSoMoN> still working on the week-end backlog, will do that neext
<vorlon> oSoMoN: cheers :)
<didrocks> apw: ah, makes sense, indeed
-queuebot:#ubuntu-release- New binary: libept [s390x] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [amd64] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [i386] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [ppc64el] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [arm64] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [armhf] (eoan-proposed/universe) [1.1+nmu3ubuntu1] (no packageset)
<juliank> ^ archive admins (CC sil2100, doko, infinity) can someone accept the libept ones please? they follow the apt abi bump and are needed for the next round
<juliank> Maybe I should add libept1.5.0 as bad to the tracker
<juliank> I plan to fix the apt test failure tomorrow, in case anyone was wonderign about that
<vorlon> W: libept1.5.90: package-name-doesnt-match-sonames libept1.aptpkg5.90
<vorlon> juliank: ^^ is this package name / soname agreed upstream in Debian?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-52.56~16.04.1] (kernel)
<vorlon> juliank: or are you handwaving because this is transitional on the way to 2.0 and you don't intend this to be in any stable releases?
-queuebot:#ubuntu-release- New binary: node-uri-js [amd64] (eoan-proposed/none) [4.2.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1047.51] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-151.178] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1015.17~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: mplayer-blue [amd64] (eoan-proposed/none) [1.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-52.56~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1034.36~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted mplayer-blue [amd64] (eoan-proposed) [1.11-2]
-queuebot:#ubuntu-release- New: accepted utf8.h [amd64] (eoan-proposed) [0~git20190120.2a7c5bf-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-151.178]
-queuebot:#ubuntu-release- New: accepted node-uri-js [amd64] (eoan-proposed) [4.2.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1047.51]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1034.36~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-52.56~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-52.56~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1015.17~16.04.1]
<juliank> vorlon: it's auto-generated like this based on apt soname
<juliank> Probably should add an override at some point, don't know
<juliank> I'm doing defacto maintenance in Debian
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1020.20~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1034.36] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-52.56] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1013.14~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-52.56] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1034.36] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1043.48] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-17.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-22.23] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1020.20] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-52.56]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-22.23~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-52.56]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1010.11] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1020.20~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-22.23~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1013.14~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1015.17] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1034.36]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-17.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-22.23~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1008.8] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1034.36]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1013.14] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-22.23~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1010.11]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.0.0-17.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1043.48]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1015.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-22.23]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1020.20]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-17.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1013.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1008.8]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-22.23] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-17.18]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1008.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-17.18] (core, kernel)
<vorlon> juliank: ack
-queuebot:#ubuntu-release- New: accepted libept [amd64] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [armhf] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [ppc64el] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [arm64] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [s390x] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [i386] (eoan-proposed) [1.1+nmu3ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-17.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-17.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-22.23]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.6-0ubuntu1 => 2:12.0.6-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu3.3 => 2:13.0.3-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.9-0ubuntu3 => 2:17.0.10-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.1.0-0ubuntu3 => 2:18.2.0-0ubuntu2] (openstack, ubuntu-server)
<wxl> why on earth does every flavor depend on spice-vdagent?????
<teward> s/every flavor/every desktop flavor/
<teward> wxl: ^
-queuebot:#ubuntu-release- Unapproved: iperf (disco-proposed/universe) [2.0.12+dfsg1-2 => 2.0.12+dfsg1-2ubuntu0.1] (edubuntu)
<infinity> wxl: 9d2b6e2f2e1c13d240b2e00c5b6c150d9ea2a428 in the platform seed.
<infinity> Author: Jeremy Bicha <jbicha@ubuntu.com>
<infinity> Date:   Tue Feb 20 08:02:27 2018 -0500
<infinity>     desktop-common: Add spice-vdagent to work better in VMs (LP: #1200296)
<ubot5> Launchpad bug 1200296 in ubuntu-meta (Ubuntu) "[MIR] spice-vdagent" [Wishlist,Fix released] https://launchpad.net/bugs/1200296
<wxl> yiiiikes
<infinity> Lemme guess, the complaint it that it pulls in gtk3?  Cause its deps seem otherwise pretty harmless.
<wxl> "will have no impact on other use cases" << presumptuous
<wxl> oh well, we'll blacklist it
<infinity> If it's gtk-3-only, it should be moved from desktop-common to gtk-3 flavours, IMO.
<infinity> Not hacked around via blacklists.
<wxl> we haven
<wxl> 't completely divorced ourselves from gtk so that's not entirely fair, though that's the goal
<wxl> but limiting unnecessary services is certainly one
<infinity> Oh, is it actively running things that are causing issues?  It's not just the toolkit bloat?
<vorlon> it's socket activated
<vorlon> so not running by default
<wxl> weird. it autostarts but it doesn't.
<infinity> Was there actually a discussion about this before it landed in desktop-common?  The bug only references ubuntu-meta.
<vorlon> it's certainly still subject to moving to a different seed if there's not consensus across the flavors, but why is this on your radar at all?
<wxl> either way, i'd like to limit the gtk depends
-queuebot:#ubuntu-release- Unapproved: iperf (cosmic-proposed/universe) [2.0.10+dfsg1-1ubuntu1 => 2.0.10+dfsg1-1ubuntu1.1] (edubuntu)
<vorlon> limit, or eliminate?
<wxl> goal being eliminate and limit in the interim
<infinity> To be fair, firefox is still the browser of choice for most flavours, and it's gtk-3, so...
<infinity> spice-thingee is pulling in nothing extra.
<vorlon> it doesn't make sense to me to remove a package from the seed that has no runtime memory cost and improves the usability of the flavor in some environments (VMs) until you're ready to drop gtk entirely
<wxl> ok, blacklist it is :)
<vorlon> if you really think that's the right thing to do, you can, but as infinity says, it should be done by moving it out of desktop-common into the per-flavor seeds, not by blacklisting
<vorlon> no, absolutely not by blacklisting
<infinity> And the only credible replacement for firefox is chromium, which is also gtk-3.
<infinity> So, unless you hate your users enough to force them to use a crappy web browser (which is 95% of most people's computer usage these days), you might be stuck shipping GTK. :P
<vorlon> infinity: chromium is a snap now in eoan ;P
<infinity> vorlon: I mean, that doesn't remove the GTK, just gives you more copies of it.
<infinity> Also, ick.
<vorlon> wxl: https://wiki.ubuntu.com/SeedManagement/AddingPackagesToDesktopCommon
<infinity> wxl: Anyhow, blacklisting is the wrong answer philosophically, but it's also the wrong answer technically.  seed blacklists are used to help influence alternate dependency choices, they don't actually outright blacklist things.
<wxl> okie dokie
<infinity> vorlon: Adding it definitely did not follow that policy. :)
<infinity> vorlon: OOI, is it referenced from the seed?
-queuebot:#ubuntu-release- Unapproved: iperf (bionic-proposed/universe) [2.0.10+dfsg1-1ubuntu0.18.04.1 => 2.0.10+dfsg1-1ubuntu0.18.04.2] (edubuntu)
<vorlon> infinity: policy was created after that add happened.  policy is referenced from the seed now, and that was the last change made to desktop-common ;)
<infinity> vorlon: Oh, I had an off-by-one here.  I thought it was added Feb 2019, not 2018.
<infinity> Impressive that it took this long for anyone to pretend to care.
<wxl> in other news, oh seed masters, can anyone tell me why we have geoclue? i'm been pouring over the rdepends and can't quite figure it out.
<infinity> wxl: Honestly, given that it pulls in exactly zero new deps (assuming you ship ffox), isn't running by default, and has, supposedly, a positive impact, I'd just leave it be.  If you can disprove the last point or two...
<infinity> wxl: geoclue isn't in eoan anymore...
-queuebot:#ubuntu-release- Unapproved: rejected iperf [source] (disco-proposed) [2.0.12+dfsg1-2ubuntu0.1]
<wxl> geoclue-2.0 :/
-queuebot:#ubuntu-release- Unapproved: iperf (disco-proposed/universe) [2.0.12+dfsg1-2 => 2.0.12+dfsg1-2ubuntu0.1] (edubuntu)
<infinity> libqt5positioning5
<infinity> wxl: ^
<infinity> wxl: Which is depended on by libqt5webkit5
<infinity> wxl: So, QtWebkit -> QtPositioning -> geoclue.
<infinity> And now you know.
<infinity> And knowing is 37% of the battle.
<wxl> huh. well that's silly. it autostarts some demo agent
<infinity> Talk to the Qt packagers.  Maybe it really only wants libgeclue instead of geoclue, and they oopsed.
<wxl> how did you get that, btw?
<infinity> Drilling backward through reverse-depends -l and some shell loops and typing quickly.
<wxl> oh hm, i always used apt-rdepends
<vorlon> "it autostarts" well there's nothing running here, perhaps because /etc/xdg/autostart/geoclue-demo-agent.desktop hilariously declares 'NotShowIn=GNOME'?
<infinity> Hah.
<infinity> Way to hide the bugs from us.
<infinity> wxl: Solution, run GNOME.
<infinity> (not actually the solution)
<wxl> oh darn, because i was just about to...
 * wxl slaps infinity with a wet fish
<wxl> ..that
<infinity> Is it 1999?
<infinity> Are you running mIRC?
<infinity> Blink twice if you need help.
<wxl> i thought it was 94
<wxl> and dude, i'm running EPiC like everyone else
<wxl> *mom get off the phone i'm on the computer!*
<vorlon> xnox: s390-tools Depends: s390-tools-signed (= ${DEB_VERSION}) interesting
<xnox> hahahhahahhahhaha
<xnox> oh boi
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.02+dfsg1-12ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.02+dfsg1-12ubuntu3]
#ubuntu-release 2019-06-18
-queuebot:#ubuntu-release- Unapproved: snapd-glib (disco-proposed/main) [1.47-0ubuntu2 => 1.48-0ubuntu0.19.04.0] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0 => 1.48-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.47-0ubuntu0.18.04.0 => 1.48-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.47-0ubuntu0.16.04.0 => 1.48-0ubuntu0.16.04.0] (no packageset)
<doko> apw: linux-azure seems to need some clean up to be able to migrate
<apw> doko, nbs by the looks .. sorting
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [source] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [amd64] (eoan-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [s390x] (eoan-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [i386] (eoan-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [armhf] (eoan-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [arm64] (eoan-proposed/universe) [0.2] (no packageset)
<jamespage> infinity: hey - heard you might be reviewing the ceph in eoan NEW - any feedback? I'd like to get this clear and into -updates so I can push an updated to support a SRU for PY3
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: grubzfs-testsuite [ppc64el] (eoan-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-23.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-23.24] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-23.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-23.24]
-queuebot:#ubuntu-release- Unapproved: coinor-ipopt (disco-proposed/universe) [3.11.9-2.1build4 => 3.11.9-2.1ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-53.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-152.179] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-53.57] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: coinor-ipopt (cosmic-proposed/universe) [3.11.9-2.1build4 => 3.11.9-2.1ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: coinor-ipopt (bionic-proposed/universe) [3.11.9-2.1build3 => 3.11.9-2.1ubuntu0.18.04.1] (no packageset)
<juliank> archive admin madness: I'd like to get 3 packages removed.
<juliank> #1833213
<juliank> bug 1833213
<ubot5> bug 1833213 in goplay (Ubuntu) "Remove goplay" [Undecided,New] https://launchpad.net/bugs/1833213
<juliank> bug 1833218
<ubot5> bug 1833218 in debian-xcontrol (Ubuntu) "Please remove debian-xcontrol" [Undecided,New] https://launchpad.net/bugs/1833218
<juliank> bug 1833219
<ubot5> bug 1833219 in aptsh (Ubuntu) "Remove aptsh from archive" [Undecided,New] https://launchpad.net/bugs/1833219
<juliank> These are terrible unmaintained packages disturbing the apt transition, and I'm working on getting them removed in Debian too
 * juliank should add bug links to Debian bugs
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.6 => 1.173.7] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175.4 => 1.175.5] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-53.57]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-152.179]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-53.57]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [amd64] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [armhf] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [ppc64el] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [arm64] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [s390x] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted grubzfs-testsuite [i386] (eoan-proposed) [0.2]
-queuebot:#ubuntu-release- Packageset: Added folder-color to ubuntu-mate in eoan
-queuebot:#ubuntu-release- Packageset: Added indicator-notifications to ubuntu-mate in eoan
<bdmurray> jamespage: Should the nova in the unapproved queue for disco supersede the existing nova in disco-proposed?
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (disco-proposed) [1.1.1+bzr982-0ubuntu21.1]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (cosmic-proposed) [1.1.1+bzr982-0ubuntu20.1]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (bionic-proposed) [1.1.1+bzr982-0ubuntu19.1]
-queuebot:#ubuntu-release- Unapproved: accepted kazam [source] (disco-proposed) [1.4.5-2.1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (disco-proposed) [0.131ubuntu19.1]
-queuebot:#ubuntu-release- Unapproved: accepted glib-networking [source] (disco-proposed) [2.60.3-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (disco-proposed) [2.0.12+dfsg1-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (cosmic-proposed) [2.0.10+dfsg1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (bionic-proposed) [2.0.10+dfsg1-1ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (disco-proposed) [1.48-0ubuntu0.19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted coinor-ipopt [source] (disco-proposed) [3.11.9-2.1ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted coinor-ipopt [source] (cosmic-proposed) [3.11.9-2.1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted coinor-ipopt [source] (bionic-proposed) [3.11.9-2.1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-18.19~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-23.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.0.0-18.19~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-23.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-18.19~18.04.2] (kernel)
<bdmurray> connor_k: How is bug 1828187 fixed in Eoan and Disco?
<ubot5> bug 1828187 in kexec-tools (Ubuntu Cosmic) "ibm,dynamic-memory property not found while loading kexec kernel (4.18.0-18-generic)" [High,In progress] https://launchpad.net/bugs/1828187
<connor_k> bdmurray, the versions of kexec-tools for disco and eoan already have the changes in their code bases
<bdmurray> connor_k: Is there something you can point me to?
<connor_k> bdmurray, I can try to find something. I arrived at that conclusion when I went to go apply the patches to D/E and saw that they were already there when I pulled them up side-by-side when quilt rejected the code chunks
<connor_k> bdmurray, i assumed they made their way in there when we synced with upstream, but I'm looking for a way to confirm that
<bdmurray> https://launchpadlibrarian.net/409220955/kexec-tools_1%3A2.0.16-1ubuntu3_1%3A2.0.18-1ubuntu1.diff.gz
<bdmurray> connor_k: ^
<bdmurray> Found by expanding disco here https://launchpad.net/ubuntu/+source/kexec-tools then looking at the diff
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (cosmic-proposed) [1:2.0.16-1ubuntu3.1]
<connor_k> bdmurray, thanks for showing me :) I'll be keeping that workflow in mind for next time
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (bionic-proposed) [1:2.0.16-1ubuntu1.1]
<bdmurray> connor_k: Anyway, in the future it would help to know, if its not obvious, how the bug was fixed in the development release.
<connor_k> bdmurray, agreed, I'll be sure to include that information next time
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (cosmic-proposed) [2:13.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (cosmic-proposed) [1:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.13.2-9ubuntu6 => 2.13.2-9ubuntu6.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (cosmic-proposed) [2:18.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-glance-store [source] (cosmic-proposed) [0.26.1-0ubuntu2.2]
<coreycb> bdmurray: hi, if you have a chance we have a high priority fix for python-glance-store in the cosmic unapproved queue. it's a small one.
<coreycb> bdmurray: oh i see that was just accepted!
<bdmurray> coreycb: other than the one I just approved? ;-)
<coreycb> bdmurray: lol good timing, thanks :)
<bdmurray> rbasak: SRU team meeting?
<rbasak> Oh
<rbasak> Sorry!
<bdmurray> rbasak: blame it on google calendar
<rbasak> Yep that must be it
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (cosmic-proposed) [2:14.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.2.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (cosmic-proposed) [2:13.0.3-0ubuntu1]
<bdmurray> coreycb: What original issue is no longer being fixed with the change in bug 1722584?
<ubot5> bug 1722584 in neutron (Ubuntu Disco) "[SRU] Return traffic from metadata service may get dropped by hypervisor due to wrong checksum" [High,Triaged] https://launchpad.net/bugs/1722584
-queuebot:#ubuntu-release- Unapproved: rejected bash [source] (bionic-proposed) [4.4.18-2ubuntu1.2~bionic1]
-queuebot:#ubuntu-release- Unapproved: rejected bash [source] (cosmic-proposed) [4.4.18-2ubuntu3.1~cosmic1]
<acheronuk> libappstream4/amd64 unsatisfiable Depends: liblmdb0 (>= 0.9.7)
<acheronuk> I can't quite see why that should be?
<vorlon> acheronuk: because liblmdb0 is in universe and libappstream4 is in main
<vorlon> so an MIR is needed for lmdb, or appstream needs to carry a delta to drop this runtime dep
<acheronuk> oh. fun!
#ubuntu-release 2019-06-19
-queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]
<teward> release team: reject ubuntustudio-menu-add please, that was sponsored but on cursory review from sarnold due to some hatred of subprocess calls and unsafe wraps which I fully agree with.  (I did a cursory code review, and I've done these 'hacks' before but... I'm in full agreement it needs work after going more in-depth into the code)
<teward> s/release team/archive admins/
<teward> vorlon: ^ if you can
-queuebot:#ubuntu-release- Unapproved: bash (cosmic-proposed/main) [4.4.18-2ubuntu3 => 4.4.18-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: bash (bionic-proposed/main) [4.4.18-2ubuntu1.1 => 4.4.18-2ubuntu1.2] (core)
<vorlon> teward: done
-queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-18.19~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-18.19~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-23.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-18.19~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-23.24~18.04.1]
<jamespage> bdmurray: sorry missed your ping - let me look
<jamespage> bdmurray: yes that's fine to superceed the one already in proposed - the patches for 2.3 are included in the new point release
<jamespage> sahid: ^^
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-53.57~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-53.57~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-53.57~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-53.57~16.04.1]
 * rbasak is (virtually) sprinting today and generally unavailable for SRU work - sorry
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1035.37] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1009.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1014.15] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1014.15]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1009.9]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1035.37]
<acheronuk> vorlon: regards lmdb being required for appstream and possible MIR: https://github.com/ximion/appstream/commit/358e9394631b87797f56dcb7e09e459b4044e631#commitcomment-33995178
<Laney> acheronuk: it's going to need it, feel free to get that filed if you want
<Laney> desktop team's going to sign on for that one
 * Laney attempts to deploy an autopkgtest-lxd-worker
<coreycb> bdmurray: dosaboy is going to update the regression potential on 1722584
<xnox> vorlon:  "xnox: s390-tools Depends: s390-tools-signed (= ${DEB_VERSION}) interesting" i thought you spotted unescaped string. But i checked, it's all doing correct stuff. I guess you did "interesting" comment similar to how apw said that "omg this is so much easier, i should steal that" although it is a bit of cheat =)
<teward> vorlon: thanks for the reject, I'll make sure they get to fixing it.
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu3 => 2.9.0-0ubuntu3] (core)
<vorlon> xnox: yes, and it's interesting because it also implies s390-tools-signed can't have packaging-only updates
<xnox> vorlon:  i'm happy to decouple the two, if we do reproducible builds. Cause in practice it is very rare when stage3.bin actually changes. Thus imho I'd just make s390-tools download signed blob and ship it if it matches. And have s390-tools-signed contain sources, that are rebuilt reproducibly and publish signed blob with a version mangled to include the stage3 binary checksum. or something like that.
<xnox> vorlon:  somehow i think a build should be able to generate a signing tarball, be suspended, and resume with launchpad having published signed bits somewhere. Ie. i'd love to move away from this dual-source package / two build-records.
<vorlon> xnox: well you can talk to apw about lp signing services
<cjwatson> That sort of rearrangement is serious work and a bit outside what apw has been doing
<cjwatson> I don't object to the theory but it's Hard (tm)
<cjwatson> (Well, I wouldn't do it quite like that but anyway)
<apw> vorlon, what we are doing with other signed packages is letting them have wider versions
<vorlon> apw: well, on grub and shim what we are doing is the -signed package depends on the unsigned one, so there are strict dependencies but the other way around and not assuming lockstep binary package versioning across source packages
<apw> vorlon, yeah i recon mine are mostly that way too, and then use a >= instead for forward ones
<apw> xnox, can you not just have the forward dep be more like Depends: >= $(DEB_VERSION) <= $(DEB_VERSION).99
<apw> then the signing package can gain a .1 .2 if it needs to be revved without
<cyphermox> vorlon: if I may, also we're quite close to having fully reproducible binaries for shim, modulo the signature.
<cyphermox> the only issue at this point is the ephemeral key we use (which we could get rid of)
<xnox> cjwatson:  yeah =) i can dream. But e.g. Intel had a rest-api signing service like that. And OBS does something like that similarly. I.e. i'd be happy for launchpad to take the build-dep, and mangle it for me to attach sigs / replace files, before .deb is published. for example. but yeah, quite a lot of rearrangements.
<xnox> for just like what - 4-5 signy things
<cjwatson> xnox: Yes, such a project is in the LP backlog
<cjwatson> And has sort of half a design
<cjwatson> Won't be this cycle though
<vorlon> apw: do you have any idea why all the bionic daily builds are reporting linux-generic-hwe-18.04 uninstallable in bionic-proposed?  I thought maybe it was build skew, but things appear to have been published 20+ hours ago and the last build failure email I have is from 7 hours ago; and I can't seem to reproduce the uninstallability locally
<apw> vorlon: sitting in new for signed overnight
-queuebot:#ubuntu-release- Unapproved: accepted bash [source] (cosmic-proposed) [4.4.18-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted bash [source] (bionic-proposed) [4.4.18-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (disco-proposed) [2.60.4-0ubuntu0.19.04.1]
<ddstreet> bdmurray for lp #1831933 would you prefer if i attach debdiffs (or open MPs) or just upload to the sru queues myself?
<ubot5> Launchpad bug 1831933 in ubuntu-release-upgrader (Ubuntu Disco) "do-release-upgrade tries to install snaps even if it knows it can't reach the snapstore" [Undecided,New] https://launchpad.net/bugs/1831933
<bdmurray> ddstreet: uploading to the queues themselves is fine with me but you'll also want to run pre-build.sh so mirrors.cfg, DistUpgradeVersion.py, and the demotions files get updated. Its not necessary to document those changes in the changelog though.
<ddstreet> ack, thanks will do
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.5 => 1:19.04.16.6] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.11.8 => 1:18.10.11.9] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.33 => 1:18.04.34] (core)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu3]
<xnox> vorlon:  is https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html stuck?
<xnox> i expect pass for all the openssl, and results are visible on a.u.c but not in excuses =/ i am confused.
<Laney> xnox: you can view the logs under https://people.canonical.com/~ubuntu-archive/proposed-migration/log/
<Laney> the answer is yes
<Laney> same reason as was being discussed in #ubuntu-devel
<Laney> should I try to fix fauxpkg.py to ignore FauxPackages if it'd clobber a real pkg?
<Laney> I can't really explain why this suddenly broke for gnome-shell though - my only theory is that the production copy of FauxPackages wasn't being used properly (something to do with the observed conflict)
<xnox> ah
<vorlon> or should fauxpkg.py be changed to output the entry with Architecture: foo instead of Architecture: all?
<Laney> it's not only the Architecture section that breaks it - any mismatch causes errors
<vorlon> ok
<Laney> well if we're going to remove it then I'll pass on any fixes to the script for now
<Laney> we can reconsider if it comes up again
<Laney> (sorry for anyone following - this was split between #ubuntu-release and #ubuntu-devel)
<infinity> Laney: Ignore-if-clobber would work too, yeah.  If you can see a way to trivially slap that in somewhere, I don't think it would be wrong.
<Laney> infinity: Something like https://bazaar.launchpad.net/~laney/britney/fauxpkg-no-clobber/revision/318
<Laney> Packages_arch aren't already parsed, unfortunately (but it seems to be reasonably speedy)
 * Laney is off - feel free to do whatever with that
<infinity> Laney: Yeah, that seems vaguely reasonable, except maybe for the section.get('Source'.. bit that I don't understand cause I don't speak python-apt. :)
#ubuntu-release 2019-06-20
<wxl> mdeslaur: i noticed you uploaded 0.3.6 of usb-creator. i've a fix i want to upload but i can't find any repo anywhere that has anything beyond 0.3.5. maybe i'm blind. could you offer assistance, at least in matters outside of optometry?
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (cosmic-proposed) [1.175.5]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.15]
<Laney> infinity: That's like grep-dctrl's Source:Package thing
<Laney> fauxpkg.py uses that construct elsewhere too
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.1-0ubuntu1] (ubuntu-desktop)
<Laney> I've pushed that, so if it starts acting up in weird ways you know where to look
<marcustomlinson> please could someone review my libreoffice bionic sru. It's a relatively important crash fix
<mdeslaur> wxl: I don't think there's a current repo anywhere
<mdeslaur> wxl: what's your fix?
-queuebot:#ubuntu-release- Unapproved: systemtap (xenial-proposed/universe) [2.9-2ubuntu2 => 2.9-2ubuntu2.1] (no packageset)
<wxl[m]> mdeslaur: no repo? That's weird. Was hoping to SRU https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1629715/comments/6 so that the Qt version works *at all*
<ubot5> Launchpad bug 1629715 in usb-creator (Ubuntu Disco) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged]
<mdeslaur> wxl[m]: ok, wait before you do because I have some updates pending in the security team PPA here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
<mdeslaur> wxl[m]: I'll release them in the next few days, then you can base your SRUs on them
<xnox> vorlon:  35 files changed, 1482 insertions(+), 251 deletions(-)
<vorlon> xnox: deletions?!
<vorlon> xnox: sounds like you need to do msgmerge instead of copying the files
<vorlon> to not clobber translations of the existing templates
<xnox> vorlon:  somehow || RET="false" sounds easier.
<xnox> vorlon:  oh, you thought .po files were uptodate in openssl, huh?!=)
<xnox> -#: ../libssl1.0.0.templates:1001
<xnox> +#: ../libssl1.1.templates:1001
<vorlon> heh
<xnox> as produced by debconf-updatepo
<vorlon> xnox: I don't mind reviewing obviously correct changes to templates
<xnox> https://paste.ubuntu.com/p/CPKcndMbtQ/ is how i generated the thing
<xnox> i hate gettext =)
<vorlon> whereas I just get hatetext
<vorlon> xnox: could the debconf-updatepo step be skipped?  since it should only munge comments
<xnox> true
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2.3 => 1.1.1b-1ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu2.4 => 1.1.1-1ubuntu2.5] (core)
<xnox> vorlon:  openssl is green on bionic, no adt regressions, but only 5 days. Could you release that to updates early? (sil is away today)
<xnox> vorlon:  then review templates thing that will land into bionic-proposed unapproved shortly and published that into -proposed.
<xnox> vorlon:  fixes on other releases are not verified yet, so can't release pending cosmic/disco SRUs (and still waiting for adt retries) but those releases are also not urgent at the moment to fix up
<xnox> (not as urgent)
<wxl> mdeslaur: cool thx
<tsimonq2> vorlon (last merger), xnox (TIL): In Lubuntu, we found a regression in initramfs-tools which only exists in Eoan. A workaround has been applied to our Calamares configuration, but from what I can tell, initramfs-tools still needs fixing. Full details including the precise problem are in bug 1829805; I don't want to step on toes and JFD the bugfix, so I wanted to ping and get your input.
<ubot5> bug 1829805 in initramfs-tools (Ubuntu) "Lubuntu Eoan Daily Image fails to boot after install on KVM" [High,Triaged] https://launchpad.net/bugs/1829805
<tsimonq2> (Of course, if you *want* me to JFD a bugfix, I will do so. ;) )
<xnox> tsimonq2:  i've read the whole bug and it's not clear to me
<xnox> tsimonq2:  what the bug in initramfs-tools is.
<tsimonq2> xnox: The bug description should be revised to include TJ-'s findings: https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/1829805/comments/13
<xnox> tsimonq2:  ie. under this conditions, running this does not build an initrd.
<ubot5> Launchpad bug 1829805 in initramfs-tools (Ubuntu) "Lubuntu Eoan Daily Image fails to boot after install on KVM" [High,Triaged]
<xnox> tsimonq2:  because as it stands now, it's impossible for me to understand what you want changed in initramfs-tools and/or how it has regressed.
<xnox> tsimonq2:  still do not understand.
<xnox> tsimonq2:  what's the steps to reproduce it without any calamares stuff in the way?
<xnox> tsimonq2:  ie. remove these files; ask to create new initrd using this options; it doesn't do that
<tsimonq2> xnox: Again, see TJ-'s comment. Run "update-initramfs -k all -c -t" prior to the initramfs generation in a fresh-installed system.
<xnox> tsimonq2:  something like that.
<xnox> tsimonq2:  what fresh-installed system.....
<tsimonq2> xnox: Fresh-installed-before-system-is-finalized. I can write clear, reproducable instructions if you wish.
<tsimonq2> xnox: i.e. generation of an initramfs before one actually exists.
<xnox> tsimonq2:  what is "-t" for ? that arg does not exist?
<xnox> tsimonq2:  i did "sudo rm /boot/initrd.img*; sudo update-initramfs -c -k all" and that didn't produce any initrds. Which is ok.
<xnox> tsimonq2:  normally the first initrd is produced by kernel getting installed.
<xnox> tsimonq2:  how did the kernel get installed? and has kernel's postinst executed?
<tsimonq2> xnox: Have you verified that immediately after copying the squashfs, the initrd exists?
<xnox> tsimonq2:  i'm not running calamares installer.... nor squashfs.
<tsimonq2> xnox: I'm unsure that a clean squashfs for an Ubuntu image contains a kernel whose postinst has been executed.
<xnox> tsimonq2:  if this is a bug in `-k all` handing of update-initramfs, it should be reproducible on a running system too.
<tsimonq2> xnox: which is ok> I disagree with that.
<tsimonq2> xnox: You found the bug, but you're making false assumptions.
<xnox> tsimonq2:  please don't get into how installer work. we just need to identify regression in initramfs-tools and report upstream to debian.
<tsimonq2> xnox: The context for why this bug exists is in the installer.
<xnox> tsimonq2:  and they will not be interested in squashfs, calamares, ubiquity, curtin or anything.
<tsimonq2> xnox: You're misunderstanding my point.
<tsimonq2> xnox: You're making the assumption that at all times, if a kernel is installed, the initrd is present. I'm unsure that is the case with the root squashfs of an ISO.
<tsimonq2> xnox: I'm simply asking you to verify that assumption.
<tsimonq2> xnox: You don't need to care about the installer, at all.
<tsimonq2> xnox: Just "does initrd exist on a fresh squashfs"?
<tsimonq2> xnox: I can grab one now to see for myself if that helps?
<xnox> curtin / subiquity / ubiquity, install base systems without kernels.
<xnox> and without prebuild initrds.
<xnox> and create the first initrd for target, in-target.
<xnox> tsimonq2:  and no, the question i asked, has not been answered. i commented on the bug.
<tsimonq2> How does it create the initrd, just by running the kernel postinst?
<xnox> tsimonq2:  it doesn't matter how, if you say there is a regression in the initramfs.
<xnox> tsimonq2:  and it should be possible to get to that state.
<xnox> tsimonq2:  it seems like calamares is trying to create an initrd, without any kernels installed..... for which no initrd can be created. Unless one expects it to have no kernel modules, but then it cannot be called "all"
<xnox> tsimonq2:  but that is just a guess.
<xnox> tsimonq2:  hence the question how to reproduce the problem at hand.
<tsimonq2> xnox: Okay, you can reproduce this by copying the squashfs somewhere where you can read/write, mount the appropriate directories, chroot into the system, and run the above update-initramfs command.
<xnox> without any installers in the way, just initramfs-tools by itself.
<tsimonq2> xnox: The kernels *are* installed.
<xnox> one really should not need squashfs to reproduce anything.
<tsimonq2> xnox: The initrd just isn't there.
<tsimonq2> ...
<tsimonq2> It's all about context, xnox.
<tsimonq2> This isn't a usual, glaring bug.
<tsimonq2> You just told me that the installer does the work of generating the initrd, but you're also telling me that if a kernel is present, the initrd is also present.
<tsimonq2> Those are incompatible in a squashfs that has a kernel but no initrd.
<xnox> i never told you that initrd is also present if a kernel is present.
<tsimonq2> 01:56:53 PM < xnox> tsimonq2:  i did "sudo rm /boot/initrd.img*; sudo update-initramfs -c -k all" and that didn't produce any initrds. Which is ok.
<tsimonq2> This is the bug.
<xnox> most of our systems boot without initrd these days.
<tsimonq2> xnox: Ok, so that's what update-initramfs is assuming then.
<tsimonq2> If a kernel is present, so is the initrd.
<tsimonq2> That's the case *most* of the time.
<xnox> tsimonq2:  then report it upstream using those steps to debian, and double check it is failing in debian.
<tsimonq2> Yep, I plan on it. :)_
<xnox> then we can cherrypick upstream fixes for this issue.
<xnox> tsimonq2:  as per man-page
<xnox>               The  use  of  "all" for the version string specifies update-initramfs to execute the
<xnox>               chosen action for all kernel versions, that are already known to update-initramfs.
<tsimonq2> xnox: I just don't want to get scolded for stealing TIL once we have the bugfix (although that seems to be a standard applied for some packages and not others...)
<tsimonq2> xnox: The version detection is done by reading which initrds are there.
<tsimonq2> xnox: Not via uname or related tools.
<tsimonq2> xnox: The logic needs to be improved.
<xnox> that's as per documentation....
<tsimonq2> Yes, and that's a bug.
<xnox> report it to debian
<tsimonq2> I will.
<xnox> as per man-page to make a kernel version known to update-initramfs, is to call it with -c and explicit version number
<xnox> which is what kernel maintainer scripts do
<xnox> hence post laying the disc, e.g. ubiquity reruns dpkg-reconfigure on the kernel packages
<xnox> cause kernel maintainer scripts know their correct version, and know how to call update-initramfs with -c -k correctly
<tsimonq2> ack, I'll talk to the Debian maintainers, though.
<xnox> indeed.
<tsimonq2> I think the discussion is done here. :)
-queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]
<vorlon> tsimonq2: this may or may not be a regression in initramfs-tools, that's fine; but *why* do you have a squashfs containing a kernel but not an initrd?
<vorlon> (if the answer is "that's what we get out of livecd-rootfs", then ok; I think that's also a bug and we should own it)
<infinity> It shouldn't have either, ideally, *but* that's not really relevant.
<infinity> The linux-image package is "installed", then we build an initrd, move kernel and initrd out (so we don't ship two copies), and let the installer move vmlinuz back and create a proper initrd.
<infinity> Evidently, however ubiquity does the last bit works fine, however calamares does doesn't.
 * vorlon nods
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.3 => 1.1.1-1ubuntu2.1~18.04.4] (core) (sync)
<xnox> infinity:  well ubiquity iterates and call /var/lib/dpkg/info/$pkg.postinst configure on "linux-*" stuff.
<tsimonq2> vorlon: Yeah, it comes from livecd-rootfs.
<infinity> Which works, but is overkill for "regenerate all my initrds please" since initramfs-tools saves state and is meant to know which ones it has.
<infinity> $ ls -l /var/lib/initramfs-tools/
<infinity> total 8
<infinity> -rw-r--r-- 1 root root 79 Jun 17 13:48 5.0.0-16-lowlatency
<infinity> -rw-r--r-- 1 root root 79 Jun 20 00:31 5.0.0-17-lowlatency
<vorlon> infinity: yeh except that state saving is itself terrible and we've had bugs in the past where initramfses grow back in /boot long after the kernel package they map to has been removed :P
<infinity> It's meant to read those stamp files to decide what "-k all" means.
<infinity> vorlon: Those cases were people manually deleting stuff from /boot instead of actually uninstalling kernel packages, weren't they?
<xnox> vorlon:  openssl sync for you  to verify. I have figured a reproducer. I downgrade lxd container back to bionic-security, and then can upgrade to reproduce the issue => after purging the debconf database for libc6/pam packages. And yeah, upgrade to bionic-updates fails, but to the CI train ppa passes.
<vorlon> infinity: not in my case, no
<xnox> vorlon:  and it is, just like you said, "just add more templates"
<vorlon> infinity: (I experienced this myself)
<vorlon> xnox: ack
 * xnox promises to never touch openssl again
<tsimonq2> infinity: I don't quite understand if you're implying this is a Calamares issue or an initramfs-tools issue. Shouldn't initramfs-tools be smart enough to read currently-installed kernels and think "oh, gee, I think I should generate an initrd for that"?
<infinity> tsimonq2: It's more complex than "currently installed kernels", it's "currently installed kernels that I've been asked to create an initrd for in the past".
<xnox> tsimonq2:  i think the question is "did calamares always do the same thing" and "did the same thing was actually the same" and "did something change in initramfs / livecd-rootfs / etc" to change what is happening.
<infinity> But yes, I'm arguing that if this has stopped working, it's an initramfs-tools bug, but that doesn't preclude calamares also being more explicit about what it asks for.
<xnox> tsimonq2:  cause i'm interested to know if it's just new code, or we have a real regression somewhere in the stack between livebuild -> postinstall boot.
<xnox> which is a lot of moving pieces.
<tsimonq2> infinity: That's fair. I'll file Debian and upstream Calamares bugs.
<tsimonq2> xnox: The update-initramfs call in Calamares hasn't changed.
<tsimonq2> xnox: As the comment I keep pointing you to states, it's a specific commit in initramfs-tools we can point to.
<xnox> tsimonq2:  did the state on disk prior the call, now different between prior releases and eoan?
<wxl> the last time it effectively changed in calamares was 2017 https://github.com/calamares/calamares/commit/086a019d19cc32c28731c7f65a55ffdad94f4ec3
<tsimonq2> xnox: I don't quite understand your question.
<xnox> tsimonq2:  or is it just update-initramfs?
<tsimonq2> Oh, no, state on disk didn't change.
<tsimonq2> As far as I can tell, only update-initramfs changed.
<infinity> So, testing locally, initramfs-tools feels regressed to me.
<xnox> tsimonq2:  ie. disco, at the point when that call is made used to look different to how eoan now looks.
<xnox> tsimonq2:  ack.
<xnox> infinity:  which does match documentation.
<xnox> infinity:  so i'm not sure if it regressed and docs were always wrong.
<infinity> xnox: Erm, wat?
<xnox>               The  use  of  "all" for the version string specifies update-initramfs to execute the
<xnox>               chosen action for all kernel versions, that are already known to update-initramfs.
<xnox> whatever "known to update-initramfs" means
<infinity> xnox: "known to update-initramfs" is "listed in /var/lib/initramfs-tools"
<infinity> Or, was.
<infinity> And now it's not.
<infinity> So yes, this is regressed, and no longer matches docs.
<infinity> If I delete my initrd, it doesn't come back with -k all.
<xnox> ooooh
<xnox> infinity:  indeed, i see things in var/lib/initramfs-tools.
<tsimonq2> infinity: Right, and that's precisely the bug here.
 * xnox learned about /var/lib/initramfs-tools today
 * tsimonq2 goes afk to do collegy stuff.
<xnox> tsimonq2:  i presume the ondisk has relevant kernels mentioned in /var/lib/initramfs-tools too
<xnox> (when calamares calls things)
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.4]
<infinity>  get_sorted_versions()
<infinity>  {
<infinity> -       version_list="$(ls -1 "${STATEDIR}" | linux-version sort --reverse)"
<infinity> -
<infinity> +       version_list="$(
<infinity> +               linux-version list |
<infinity> +               while read -r version; do
<infinity> +                     test -e "${BOOTDIR}/initrd.img-$version" && echo "$version"
<infinity> +               done |
<infinity> +               linux-version sort --reverse
<infinity> +               )"
<infinity>         verbose "Available versions: ${version_list}"
<infinity>  }
<infinity> That appears to completely ignore STATEDIR now.
<infinity> And 'linux-version list' doesn't list -17 on my system.  Which seems suspect.
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (cosmic-proposed) [1.1.1-1ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.4]
<infinity> Wait.  Now I'm confused. :)
<infinity> Oh.  I deleted a kernel while debugging.  I'm SMRT.
<infinity> Anyhow, the behaviour change above is that it switched from checking STATEDIR to stating the initrd.
<infinity> So, instead of "statedir knows what we've done in the past", we have "in you have no initrd, you can't have a new one either".
<infinity> s/in you/if you/
<infinity> https://salsa.debian.org/kernel-team/initramfs-tools/commit/f39625afd6ba6c1aa2027286dc3ef1c933da14e0
<infinity> vorlon: That would be the offending commit.  I think the obvious way to get both old and new behaviour combined would just be to add the statedir bit to the list (and sort -u the mess).
<vorlon> infinity: no opinion :)
-queuebot:#ubuntu-release- Unapproved: accepted newlib [source] (bionic-proposed) [2.4.0.20160527-3ubuntu0.1]
#ubuntu-release 2019-06-21
-queuebot:#ubuntu-release- New: accepted ceph [amd64] (eoan-proposed) [14.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [s390x] (eoan-proposed) [14.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [i386] (eoan-proposed) [14.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [arm64] (eoan-proposed) [14.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [ppc64el] (eoan-proposed) [14.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [armhf] (eoan-proposed) [14.2.1-0ubuntu1]
<tsimonq2> infinity: Right, so our workaround for that is literally just running "touch /boot/initrd.img-$(uname -r)" to trick initramfs-tools. :P
<tsimonq2> infinity, vorlon, xnox: Upstream Calamares bug I just filed, in case anyone wants to add anything: https://github.com/calamares/calamares/issues/1180
<gitbot> calamares issue 1180 in calamares "update-initramfs should be more specific" [Open]
<tsimonq2> I don't have access to my GPG key at the moment, so I'll hold off on submitting the bug to Debian.
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1044.49] (kernel)
-queuebot:#ubuntu-release- Unapproved: ceph (disco-proposed/main) [13.2.4+dfsg1-0ubuntu2 => 13.2.6-0ubuntu0.19.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceph (cosmic-proposed/main) [13.2.4+dfsg1-0ubuntu0.18.10.1 => 13.2.6-0ubuntu0.18.10.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1044.49]
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.17-0ubuntu0.16.04.1 => 9.5.18-0ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (bionic-backports) [1.0.3-0ubuntu1.18.10.1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: brasero [i386] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: brasero [s390x] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: brasero [amd64] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: brasero [ppc64el] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: brasero [arm64] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: brasero [armhf] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted brasero [amd64] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted brasero [armhf] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted brasero [ppc64el] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted brasero [arm64] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted brasero [s390x] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted brasero [i386] (eoan-proposed) [3.12.2-5ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1014.15~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1035.37] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1014.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1035.37]
<acheronuk> vorlon: would it perhaps be ok to not have the new appstream in proposed until the lmdb MIR is done? it will block important parts of new Plasma versions until then if it stays
<seb128> acheronuk, why not filing that MIR request now if that's important to you guys? maybe the MIR team can help to get it reviewed, always best to move toward the goal rather than stepping back when we can
<teward> archive admin, at the request of the ubuntu studio devs please reject ubuntustudio-menu-add in Eoan NEW queue, they discovered a bug after they said it was ready to upload.  (I think i'mma sit on them for a few days this time before they get another consideration for it getting a sponsor...)
 * teward preps the drive-by fixes for other things and another NGINX upload in the interim
<seb128> teward, done
<teward> seb128: thanks
<seb128> np
-queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
<teward> seb128: hate having to keep asking it to be NACK'd but the first was security/code concern, this time they discovered a bug >.>
<teward> maybe I should sit on their project leader for a while, lol...
<seb128> teward, well, depending of the bug it's not the end of the world to let it in the review queue and do another upload later to fix the bug
<seb128> depends if it's ok to let it in with that bug or not
<seb128> while it's in the queue it has more chances to be NEW reviewed :)
<teward> seb128: AIUI the bug is it doesn't work as is with their attempt to move to array-based subprocess calls in the python
<teward> which they only discovered AFTER asking for the second sponsoring.
<teward> at least the shell=True subprocess calls for cp and rm are gone... *shivers*
<teward> thanks sarnold for pointing those out :P
<seb128> ok, probably makes sense to postpone then in that case
<teward> seb128: yep.
<teward> seb128: i also have inside knowledge that they're doing this in Python for compat but they use a lot of other language 'approaches' to things, and are a tad new to the Python.  (if you look at the changelogs I've added a few things with Eickmeyer's approval to fix some of the major concerns)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1016.18] (kernel)
<teward> right now though NGINX needs my attention :p
<teward> distropatch for a PIDfile race condition problem
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1016.18]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1009.9] (core, kernel)
<teward> seb128: wow confusion is chaos, but it seems they wer ebugging me on A DIFFERENT package >>>
<teward> i think context is key in things :|
 * teward once again uploads this to NEW for them.
 * teward then returns to watching update_excuses and update_output with regards to NGINX
<seb128> teward, ah :)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1009.9]
<teward> seb128: BUT at least now i can focus on nginx for the next... *checks averate timespan* ... 8 hours.
<seb128> that's a long day!
-queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]
<teward> seb128: nah that's just how long things're going to take xD
<teward> because i still have my full time job as well :)
<teward> seb128: unrelated, I don't think there's anything that'd block ubuntustudio-menu-add so if you or another AA have some spare cycles to look at that, I'm sure Eickmeyer would be appreciative
<teward> :P
<Eickmeyer> ^he speaks the truth
<teward> note i don't care either way
<teward> Eickmeyer is the one who cares :P
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1048.52] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1016.18~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1035.37~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1011.12] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1011.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1048.52]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1016.18~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1035.37~16.04.1]
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.1 => 5.9.5+dfsg-0ubuntu2.3] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: node-d3-scale-chromatic [amd64] (eoan-proposed/none) [1.3.3-1] (no packageset)
<vorlon> acheronuk: as seb128 says, it would be better to move appstream forward rather than removing it from -proposed.  also, merely removing appstream doesn't unblock plasma, you'd also need to reupload and rebuild... someone should at least start the MIR
<acheronuk> vorlon: LP: #1833745
<ubot5> Launchpad bug 1833745 in lmdb (Ubuntu) "[MIR] required new dependency of appstream" [Undecided,New] https://launchpad.net/bugs/1833745
<acheronuk> plasma will be rebuilt on Tuesday anyway, as there is a new bugfix release then
<wxl> @tsimonq2: looks like adam and i both hit that one up
<vorlon> acheronuk: do you plan to fill it out with the template as described on https://wiki.ubuntu.com/MainInclusionProcess and subscribe ubuntu-mir team?
<acheronuk> vorlon: most of those headings I really am not confident about filling in, so as Laney said the "<Laney> desktop team's going to sign on for that one" then its probably best for someone who can get it right at the start to do so
<acheronuk> I would of course follow to try to learn...
<vorlon> acheronuk: well, they get filled in as described on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<tsimonq2> infinity, wxl: cala issue> Much appreciated.
 * acheronuk nudges tsimonq2 towards that MIR
<seb128> acheronuk, one random MIR example if you need one, https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598
<ubot5> Launchpad bug 1746598 in libnfs (Ubuntu) "[MIR] libnfs" [Undecided,Fix released]
<acheronuk> vorlon seb128: ok. let me look over the weekend. no promises. this is a bit out of my comfort zone
<seb128> acheronuk, the sections are pretty straightforward and it should be fine if you follow the wiki/example but feel free to ping/email me if you have question/need help (I'm not on IRC during the w.e email might work better)
<acheronuk> seb128: ok. thanks. not going to tackle it tonight at least, as beer o'clock is here
<seb128> right, same here
<seb128> enjoy beer o'clock & w.e :)
<acheronuk> you too :)
<seb128> thx
<Eickmeyer> I have a relatively urgent SRU I'd like to get pushed through. Fairly trivial, it just, uh... is there a nicer term for idiot-proofing? (bug 1833740)
<ubot5> bug 1833740 in ubuntustudio-installer (Ubuntu) "[SRU] Option in ubuntustudio-installer pulling-in gdm3" [Undecided,Confirmed] https://launchpad.net/bugs/1833740
<Eickmeyer> Debdiff is attached.
<teward> Eickmeyer: why do you need to revert the debhelper compat for Eoan?
<teward> just curious (looking at the packaging)
<Eickmeyer> teward: Because bionic backports ppa.
 * teward headscratches
<teward> your changelog entries are wrong then
<teward> debdiff MACL
<teward> NACK'd for Sponsoring because it's not targeting Bionic, etc.
<Eickmeyer> teward: The sponsoring in this case only needs to go to disco.
<teward> then the changelog needs updated :P
<teward> but i'll leave that for SRU, etc. to handle.
 * teward goes back to kicking some python packages into submission
<seb128> teward, Eickmeyer, looking to ubuntustudio-menu-add there is no COPYING file nor mention of copyright holder or license outside of the debian dir, that seems suboptimal
<seb128> k, and on that side comment calling it a week, bye :-)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-installer (disco-proposed/universe) [0.02 => 0.04~19.04.1] (ubuntustudio)
<Eickmeyer> vorlon, infinity: Please reject ubuntustudio-menu-add per seb128's request. Those items have now been added.
<Eickmeyer> teward: wrt ^ changes now in git.
#ubuntu-release 2019-06-22
<wxl> infinity: bdmurray: rbasak: calling you out as SRU folks. i'm trying to do my first SRU and i'm a little bit hesitant as it has been suggested to me to pull in some changes that aren't directly related to the bug at hand but i believe should have small likelihood for regression. i've tried to explains this. thoughts? suggestions? https://bugs.launchpad.net/ubuntu/+source/libfm-qt/+bug/1825587
<ubot5> Launchpad bug 1825587 in libfm-qt (Ubuntu Disco) "non-existent temporary desktop file appears on desktop" [High,Triaged]
-queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New source: openjdk-11 (eoan-proposed/primary) [11.0.4+8-1]
-queuebot:#ubuntu-release- New: rejected openjdk-11 [source] (eoan-proposed) [11.0.4+8-1]
-queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]
<teward> hmm
#ubuntu-release 2019-06-23
<acheronuk> could qtbase in proposed be hinted please? the pinentry amd64 test is regressed against itself, and not qtbase fault http://autopkgtest.ubuntu.com/packages/p/pinentry/eoan/amd64
<teward> can someone badtest kopano-webapp for amd64, arm64, armhf, and i386?  The test logs in amd64, arm64, and i386 indicate that the web driver in use by Selenium is just crashing in the tests (via snaps) and armhf show shows a Snap / Chromium related crash issue.
<teward> (it's blocking NGINX)
<mitya57> By the way, I can confirm that pinentry test failure is not related to Qt. Looks like a race condition that started happening on amd64, but it was happening on !amd64 previously too, and on amd64 in ealier releases.
#ubuntu-release 2020-06-15
<smb> Is this channel the right one to ask about an additional hint to britney badtest(s)?
<LocutusOfBorg> yep
<smb> So I have added a comment to the bug report here https://bugs.launchpad.net/ubuntu/+source/dahdi-linux/+bug/1878214. Basically the upload is stuck due to s390x failing which looks to be a known thing
<ubot5> Ubuntu bug 1878214 in dahdi-linux (Ubuntu Xenial) "[Xenial] dahdi-dkms fails to build after kernel version 4.4.218" [Medium,Fix committed]
<smb> https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#dahdi-linux
<LocutusOfBorg> apw, ^^ yes, we fixed dkms to stop throwing errors in bionic or so
<LocutusOfBorg> can we please get an hint?
<smb> apw, sorry, did not know it would fire back at you :)
<LocutusOfBorg> he should be the one who hinted it at the begin, that backlight driver doesn't exist on s390x, we did a lot of work to exclude dkms building when the arch was not supported
<LocutusOfBorg> but that work didn't reach xenial, and I don't think it should be backported there
<smb> No, certainly one (and if only minimally) hopes to stop caring that much about xenial soon
<LocutusOfBorg> and thanks to you, I updated dkms to debian sid and groovy :)
<smb> heh :)
<Laney> https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.html
<Laney> first run from over the weekend
<Laney> couple of bugs there heh
-queuebot:#ubuntu-release- New source: plasma-wayland-protocols (groovy-proposed/primary) [1.0-0ubuntu1]
 * Laney runs again
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1027.29~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: deja-dup (focal-proposed/main) [40.6-1ubuntu2 => 40.7-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: u-boot [amd64] (groovy-proposed/main) [2020.04+dfsg-2ubuntu1] (core)
<Laney> We managed to recover some more arm64/ppc64el capacity
<Laney> so those queues should start going down faster now
<Laney> hopefully
<coreycb> sil2100: hello, if you happen to have cycles today we have neutron packages in the eoan and xenial unapproved queue
-queuebot:#ubuntu-release- New binary: u-boot [riscv64] (groovy-proposed/main) [2020.04+dfsg-2ubuntu1] (core)
<sil2100> coreycb: o/
<coreycb> sil2100: o/
-queuebot:#ubuntu-release- Unapproved: rejected evince [source] (focal-proposed) [3.36.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: evince (focal-proposed/main) [3.36.0-2 => 3.36.5-0ubuntu1] (ubuntu-desktop)
<vorlon> LocutusOfBorg: because perl-base is essential, and apt won't remove perl-base:amd64 in favor of perl-base:i386 in the cross-test environment.  These just need to be hinted away.
-queuebot:#ubuntu-release- Unapproved: gnutls28 (focal-proposed/main) [3.6.13-2ubuntu1.1 => 3.6.13-2ubuntu1.2] (core, i386-whitelist)
<vorlon> LocutusOfBorg: hinted now
<seb128> sil2100, hey, any chance you could review that gnutls SRU ^ it's a small diff and should fix connection to yahoo and other servers failing
-queuebot:#ubuntu-release- Unapproved: parted (bionic-proposed/main) [3.2-20ubuntu0.2 => 3.2-20ubuntu0.3] (core)
-queuebot:#ubuntu-release- New: accepted dlpack [amd64] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted dlpack [armhf] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted dlpack [riscv64] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted mp3check [amd64] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted mp3check [armhf] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted dlpack [arm64] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted dlpack [s390x] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted mp3check [riscv64] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted dlpack [ppc64el] (groovy-proposed) [0.0~git20200217.3ec0443-2]
-queuebot:#ubuntu-release- New: accepted mp3check [arm64] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted golang-github-joyent-gosdc [amd64] (groovy-proposed) [0.0~git20161202.ec8b350-1]
-queuebot:#ubuntu-release- New: accepted mailutils [arm64] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mailutils [ppc64el] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mailutils [s390x] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mp3check [s390x] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted mailutils [amd64] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mailutils [riscv64] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mailutils [armhf] (groovy-proposed) [1:3.9-2]
-queuebot:#ubuntu-release- New: accepted mp3check [ppc64el] (groovy-proposed) [0.8.7-3.1]
-queuebot:#ubuntu-release- New: accepted gnome-pass-search-provider [amd64] (groovy-proposed) [0.0~20191115+da2db41-1]
-queuebot:#ubuntu-release- New: accepted gnustep-gui [arm64] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-gui [ppc64el] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-suapapa-go-eddystone [amd64] (groovy-proposed) [0.0~git20190827.8d8c1bb-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-diff [amd64] (groovy-proposed) [1.1.0.8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-epiestim [amd64] (groovy-proposed) [2.2-3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gnustep-gui [amd64] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-gui [s390x] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted libtest-dbic-expectedqueries-perl [amd64] (groovy-proposed) [2.002-2]
-queuebot:#ubuntu-release- New: accepted gnustep-gui [armhf] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted google-auto-value-java [amd64] (groovy-proposed) [1.7.2-1]
-queuebot:#ubuntu-release- New: accepted libtest-metrics-any-perl [amd64] (groovy-proposed) [0.01-2]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (groovy-proposed) [1.43.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images-ppc64el [source] (groovy-proposed) [3]
-queuebot:#ubuntu-release- New binary: cd-boot-images-ppc64el [ppc64el] (groovy-proposed/universe) [3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [20.0.4-2ubuntu1~18.04.2 => 20.0.8-0ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6.1 => 0.136ubuntu6.2] (core, i386-whitelist)
<LocutusOfBorg> vorlon, thanks!
<LocutusOfBorg> btw please NBS cleanup libplacebo7? this makes vlc migrate and the transition end, hopefully
-queuebot:#ubuntu-release- Unapproved: libvpd (focal-proposed/main) [2.2.6-1build1 => 2.2.6-1ubuntu1~20.04.1] (core)
<LocutusOfBorg> some archive admin might have decrufted it before the build was over, it still exists on riscv64 and s390x
<sil2100> seb128: hey! Sure, I'll try, but I have my +1 maintenance shift today and tomorrow so I'm only doing minimal SRU work - will get to it on Thursday for sure if not
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (focal-proposed) [1:1.6.7-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (eoan-proposed) [1:1.6.6-2ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (bionic-proposed) [1:1.6.5-1ubuntu1~18.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (xenial-proposed) [1:1.6.3-2~16.04.3]
-queuebot:#ubuntu-release- Unapproved: libxau (bionic-proposed/main) [1:1.0.8-1 => 1:1.0.8-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: bamkit [amd64] (groovy-proposed/none) [0.0.1+git20170413.ccd079d-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bbhash [s390x] (groovy-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [s390x] (groovy-proposed/none) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [s390x] (groovy-proposed/none) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [amd64] (groovy-proposed/none) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bbhash [amd64] (groovy-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: magnum-tempest-plugin [amd64] (groovy-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [s390x] (groovy-proposed/none) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudkitty-tempest-plugin [amd64] (groovy-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: senlin-tempest-plugin [amd64] (groovy-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heat-tempest-plugin [amd64] (groovy-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libstatistics-pca-perl [amd64] (groovy-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mmtf-python [amd64] (groovy-proposed/none) [1.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [amd64] (groovy-proposed/none) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [amd64] (groovy-proposed/none) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-import-export [amd64] (groovy-proposed/none) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [amd64] (groovy-proposed/none) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [s390x] (groovy-proposed/none) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abacas [amd64] (groovy-proposed/universe) [1.3.1-8] (no packageset)
-queuebot:#ubuntu-release- New binary: jsmn [amd64] (groovy-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tomcat-jakartaee-migration [amd64] (groovy-proposed/none) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-cache-machine [amd64] (groovy-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bbhash [ppc64el] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-ical [amd64] (groovy-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lsvpd (focal-proposed/main) [1.7.10-1build1 => 1.7.10-1ubuntu0.1] (core)
-queuebot:#ubuntu-release- New binary: bbhash [riscv64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [ppc64el] (groovy-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [ppc64el] (groovy-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [ppc64el] (groovy-proposed/universe) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [ppc64el] (groovy-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [riscv64] (groovy-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [riscv64] (groovy-proposed/universe) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bbhash [arm64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [riscv64] (groovy-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [arm64] (groovy-proposed/universe) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [armhf] (groovy-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [armhf] (groovy-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbaseencode [armhf] (groovy-proposed/universe) [1.0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ylva [arm64] (groovy-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [armhf] (groovy-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [arm64] (groovy-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: meliae [arm64] (groovy-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wys [riscv64] (groovy-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (bionic-proposed/main) [1.10~ubuntu18.04.3 => 1.10~ubuntu18.04.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27 => 1.27ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.10.2 => 1.10.2ubuntu0.1] (core)
<vorlon> xnox: "shim is broken, just use grub" - false?
<vorlon> xnox: (cd-boot-images-arm64)
<xnox> vorlon: i think i forgot which one is broken (shim or grub), but i thought currently in groovy we have broken shim (the reverted one, without arm64 signature) and broken grub (needs rebase) to work in secureboot on arm64.
<xnox> vorlon:  thus shim->grub does not work in groovy at the moment, until we rebase grub & get new shim.
<xnox> vorlon:  but booting grub directly works.
<xnox> vorlon:  what's wrong in the above?
-queuebot:#ubuntu-release- New: accepted cd-boot-images-arm64 [source] (groovy-proposed) [3]
<vorlon> xnox: it doesn't work if secureboot is turned on.  But I don't think we have any problems booting shim->grub with sb disabled.
<xnox> vorlon:  oh really. In that case i should upload better cd-boot-images-arm64!
<vorlon> xnox: I was pretty sure we had the working shim in focal and groovy
<xnox> ack
<xnox> will test in kvm as well
<sbeattie> Hi, can we get the fwupd uefi images in the unappoved queue for focal, eoan, and bionic published. We have fwupd-signed source pacakges in the unapproved queues to build when the uefi bits are available.
-queuebot:#ubuntu-release- New binary: cd-boot-images-arm64 [arm64] (groovy-proposed/none) [3] (no packageset)
<sbeattie> ubuntu-achive: Hi, can the security team get the fwupd uefi images in the unappoved queue for focal, eoan, and bionic published. We have fwupd-signed source pacakges in the unapproved queues to build when the uefi bits are available.
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (focal-proposed) [1.27ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4ubuntu0.1 => 1.3.10-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (eoan-proposed) [1.10.2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: gnustep-back [s390x] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gnustep-back [ppc64el] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gnustep-back [amd64] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gnustep-back [arm64] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gnustep-back [armhf] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd-signed [source] (bionic-proposed) [1.10~ubuntu18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (bionic-proposed) [1.10~ubuntu18.04.4]
<vorlon> sbeattie: I think this is all done now
<sbeattie> vorlon: ugh, looks like for focal we need a different version? https://launchpad.net/ubuntu/+source/fwupd-signed/1.27ubuntu0.1
<vorlon> sbeattie: yep, appears so
<vorlon> sbeattie: in particular, it seems that 1.27ubuntu0.1 sorts earlier than 1.27+, so the fwupd part of the version string needs to be bumped somehow
<vorlon> whether through reupload of fwupd or by more aggressive mangling in fwupd-signed's debian/rules
<sbeattie> vorlon: why did this not get rejected in eoan?
<sbeattie> is it only checking the version in the release pocket and not eoan-updates?
<vorlon> sbeattie: uh possibly
<Bashing-om> vorlon: 2) 18.04 upgrade: "The following packages have been kept back: fwupd ".
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.10.2ubuntu0.1 => 1.10.3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27ubuntu0.1 => 1.27.1ubuntu1] (core)
<sbeattie> vorlon: okay, updated fwupd-signed sources with bumped versions that should superced existing versions in the eoan and focal unapproved queues ^
<sbeattie> (adjusting fwupd-signed versions seemed less error prone than trying to adjust debian/rules for this update.)
<sbeattie> also, as a heads up, superm1 uploaded a followup sru for fwupd to the focal proposed queue.
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (focal-proposed) [1.27.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (eoan-proposed) [1.10.3ubuntu1]
<sbeattie> woot, thanks!
-queuebot:#ubuntu-release- New: accepted gnustep-back [amd64] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-back [armhf] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-back [s390x] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-back [arm64] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted gnustep-back [ppc64el] (groovy-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted bbhash [arm64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbaseencode [armhf] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted meliae [armhf] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted wys [arm64] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted wys [riscv64] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted ylva [armhf] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted libbaseencode [arm64] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted meliae [riscv64] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted ylva [arm64] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted meliae [arm64] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted wys [armhf] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted bbhash [ppc64el] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted jsmn [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libbaseencode [riscv64] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted python-django-cache-machine [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted wys [ppc64el] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted ylva [riscv64] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted bbhash [riscv64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted meliae [ppc64el] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted ylva [ppc64el] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted libbaseencode [ppc64el] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted python-django-ical [amd64] (groovy-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted abacas [amd64] (groovy-proposed) [1.3.1-8]
-queuebot:#ubuntu-release- New: accepted libbaseencode [amd64] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted meliae [amd64] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted python-django-import-export [amd64] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted wys [amd64] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted ylva [s390x] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted heat-tempest-plugin [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted mmtf-python [amd64] (groovy-proposed) [1.1.2-2]
-queuebot:#ubuntu-release- New: accepted ylva [amd64] (groovy-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted libstatistics-pca-perl [amd64] (groovy-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted tomcat-jakartaee-migration [amd64] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted bamkit [amd64] (groovy-proposed) [0.0.1+git20170413.ccd079d-2]
-queuebot:#ubuntu-release- New: accepted bbhash [s390x] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbaseencode [s390x] (groovy-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- New: accepted meliae [s390x] (groovy-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted wys [s390x] (groovy-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted bbhash [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted magnum-tempest-plugin [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted cloudkitty-tempest-plugin [amd64] (groovy-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted senlin-tempest-plugin [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: python-nest-asyncio [amd64] (groovy-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: error-prone-java [amd64] (groovy-proposed/universe) [2.3.2+ds-1] (no packageset)
#ubuntu-release 2020-06-16
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27.1ubuntu1 => 1.27.1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: cockpit (focal-backports/universe) [221-1~ubuntu20.04.1 => 221.1-1~ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (focal-backports) [221.1-1~ubuntu20.04.1]
<LocutusOfBorg> hello, can any ubuntu-archive admin please promote libsane1 again?
<RAOF> LocutusOfBorg: I don't see that in component mismatches? What's pulled it in now?
<LocutusOfBorg> renaming from libsane to libsane1
 * RAOF is confused by the rmadison output.
<RAOF> libsane has always been providing a libsane1 that's been in universe, and now it's changing name?
<RAOF> Oh, it looks like libsane has been Provide: ing libsane1. So the transitional libsane1 package is going to now be the real package?
<LocutusOfBorg> yes, sadly, yes
<LocutusOfBorg> I might satisfy the old libsane1 with just a versioned Provides, but I'm not sure if it is enough for apt to do the upgrade smootly
<LocutusOfBorg> in any case, if you are interested: https://bugs.debian.org/962936
<ubot5> Debian bug 962936 in src:sane-backends "sane-backends: please still keep libsane transitional package around" [Serious,Open]
<RAOF> Ah, but regardless, the correct thing to do will be to promote libsane1.
<RAOF> And then libsane should be able to be demoted at some point.
<RAOF> Or disappear
 * RAOF is temporarily EoD now, but will get onto that after the evening meeting of someone else doesn't get to it first.
<ackk> ubuntu-archive: hi, could someone please take a look at https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1882949 ?
<ubot5> Ubuntu bug 1882949 in django-piston3 (Ubuntu) "RM: remove django-piston3 / python3-django-piston3 from archive" [Undecided,New]
<ackk> thanks sil2100
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1027.29~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1027.29~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-38.42~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-38.42~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/main) [5.4.0-38.42~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-38.42~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1027.29~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-38.42~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-38.42~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-38.42~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-38.42~18.04.1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images-arm64 [arm64] (groovy-proposed) [3]
-queuebot:#ubuntu-release- New: accepted error-prone-java [amd64] (groovy-proposed) [2.3.2+ds-1]
-queuebot:#ubuntu-release- New: accepted u-boot [amd64] (groovy-proposed) [2020.04+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images-ppc64el [ppc64el] (groovy-proposed) [3]
-queuebot:#ubuntu-release- New: accepted u-boot [riscv64] (groovy-proposed) [2020.04+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-nest-asyncio [amd64] (groovy-proposed) [1.3.3-1]
<RAOF> LocutusOfBorg: Hm, actually, I'm not sure whether the libsane1 in groovy-proposed, or the one in groovy, or both need to be promoted. ubuntu-archive, what happens here? Will promoting the version in groovy-proposed copy over when britney accepts it?
<RAOF> Will britney not accept it as a valid candidate if the binary in groovy isn't promoted? Or will britney just get confused if the components differ between proposed and release?
<seb128> RAOF, I'm not sure, I keep being confused by that but I think it will not migrate unless you promote it in the main archive
<RAOF> Ok. Given that I'm about to go to sleep, and so won't be around to handle any cleanup if we're wrong, would you like to promote it seb128?
<RAOF> :)
<seb128> RAOF, I can do that yes
<seb128> RAOF, enjoy your evening (night?)
<RAOF> Yup, 10pm!
<RAOF> Thanks!
<doko> RAOF: it shouldn't be necessary to promote the version in the release pocket, and afik, it won't work, because -release is frozen
<doko> ahh, groovy release, not frozen, but not necessary
<RAOF> doko: groovy release isn't frozen :P
<RAOF> So britney will DTRT. Good to know!
 * RAOF really goes to sleep now.
-queuebot:#ubuntu-release- Unapproved: glib2.0 (focal-proposed/main) [2.64.2-1~fakesync1 => 2.64.3-1~ubuntu20.04.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1043.44] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1017.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1029.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1012.12] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-ibmq-provider [amd64] (groovy-proposed/universe) [0.4.6-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libgphoto2 (focal-proposed/main) [2.5.24-1 => 2.5.25-0ubuntu0.1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.4 [amd64] (bionic-proposed/main) [5.4.0-1017.17~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.4 [amd64] (bionic-proposed/main) [5.4.0-1016.16~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.4 [amd64] (bionic-proposed/universe) [5.4.0-1016.16~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.4 [amd64] (bionic-proposed) [5.4.0-1017.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1043.44]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.4 [amd64] (bionic-proposed) [5.4.0-1016.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1016.16~18.04.1]
-queuebot:#ubuntu-release- New binary: angelscript [s390x] (groovy-proposed/none) [2.34.0+ds-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-gitgutter [amd64] (groovy-proposed/none) [0~20200414-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruamel.yaml.clib [s390x] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [amd64] (groovy-proposed/none) [2.34.0+ds-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: lastz [amd64] (groovy-proposed/none) [1.04.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [s390x] (groovy-proposed/none) [2.11.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [ppc64el] (groovy-proposed/none) [2.34.0+ds-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanosv [amd64] (groovy-proposed/none) [1.2.4+git20190409.c1ae30c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-vader [amd64] (groovy-proposed/none) [0.3.0+git20200213.6fff477-1] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [arm64] (groovy-proposed/none) [2.34.0+ds-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [amd64] (groovy-proposed/none) [2.11.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruamel.yaml.clib [ppc64el] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruamel.yaml.clib [arm64] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [ppc64el] (groovy-proposed/none) [2.11.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruamel.yaml.clib [armhf] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: batalert [amd64] (groovy-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [arm64] (groovy-proposed/none) [2.11.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruamel.yaml.clib [amd64] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wifi-qr [amd64] (groovy-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openjson [amd64] (groovy-proposed/none) [1.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [armhf] (groovy-proposed/none) [2.11.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tiddit [riscv64] (groovy-proposed/universe) [2.11.0+dfsg-1] (no packageset)
<tjaalton> update_excuses shows that seqtools for armhf is the only missing test for xorg-server and that it's currently running, but isn't
-queuebot:#ubuntu-release- New binary: angelscript [riscv64] (groovy-proposed/universe) [2.34.0+ds-1.1] (no packageset)
<tjaalton> looks like the arm* test queues are hopelessly long?
<tjaalton> or what's the 'huge' queue?
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (focal-proposed) [1.7.10-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvpd [source] (focal-proposed) [2.2.6-1ubuntu1~20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1088.98] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (focal-proposed) [40.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (focal-proposed) [0.60.3-0ubuntu1~20.04]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (focal-proposed) [3.36.2-1ubuntu1~20.04]
<vorlon> tjaalton: the 'huge' queue is the separate queue tests are put into for packages that trigger a lot of revdeps at a time.  It's a coarse prioritization method, that in general lets packages with few revdeps clear proposed-migration first
<vorlon> and according to the cowboyed state, apparently arm64 is not working correctly in bos01 right now
<vorlon> so we're down from 12 workers to 3
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu4 => 2:2.9-1ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected wpa [source] (focal-proposed) [2:2.9-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted wpa [source] (focal-proposed) [2:2.9-1ubuntu4.1]
-queuebot:#ubuntu-release- New: accepted angelscript [riscv64] (groovy-proposed) [2.34.0+ds-1.1]
-queuebot:#ubuntu-release- New: accepted openjson [amd64] (groovy-proposed) [1.0.12-1]
-queuebot:#ubuntu-release- New: accepted ruamel.yaml.clib [arm64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted tiddit [arm64] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tiddit [ppc64el] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wifi-qr [amd64] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted batalert [amd64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruamel.yaml.clib [armhf] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted tiddit [riscv64] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruamel.yaml.clib [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted tiddit [armhf] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted angelscript [amd64] (groovy-proposed) [2.34.0+ds-1.1]
-queuebot:#ubuntu-release- New: accepted angelscript [ppc64el] (groovy-proposed) [2.34.0+ds-1.1]
-queuebot:#ubuntu-release- New: accepted nanosv [amd64] (groovy-proposed) [1.2.4+git20190409.c1ae30c-1]
-queuebot:#ubuntu-release- New: accepted tiddit [amd64] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted vim-gitgutter [amd64] (groovy-proposed) [0~20200414-1]
-queuebot:#ubuntu-release- New: accepted angelscript [arm64] (groovy-proposed) [2.34.0+ds-1.1]
-queuebot:#ubuntu-release- New: accepted ruamel.yaml.clib [ppc64el] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted vim-vader [amd64] (groovy-proposed) [0.3.0+git20200213.6fff477-1]
-queuebot:#ubuntu-release- New: accepted lastz [amd64] (groovy-proposed) [1.04.03-1]
-queuebot:#ubuntu-release- New: accepted tiddit [s390x] (groovy-proposed) [2.11.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted angelscript [s390x] (groovy-proposed) [2.34.0+ds-1.1]
-queuebot:#ubuntu-release- New: accepted ruamel.yaml.clib [s390x] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted qiskit-ibmq-provider [amd64] (groovy-proposed) [0.4.6-2]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (focal-proposed) [2.11.2-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (eoan-proposed) [2.10.8-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.8-1ubuntu2~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted openssh [source] (focal-proposed) [1:8.2p1-4ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1029.30]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1012.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1017.17]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1088.98]
-queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (focal-proposed/universe) [5.4.0-1017.17] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1029.30~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (focal-proposed) [5.4.0-1017.17]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1029.30~18.04.1]
-queuebot:#ubuntu-release- New: rejected cd-boot-images-amd64 [source] (groovy-proposed) [3]
-queuebot:#ubuntu-release- New: rejected cd-boot-images-amd64 [source] (groovy-proposed) [3]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1090.100] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1090.100~16.04.1] (kernel)
#ubuntu-release 2020-06-17
-queuebot:#ubuntu-release- Unapproved: python-botocore (bionic-proposed/universe) [1.8.48+repack-1 => 1.16.19+repack-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (focal-proposed/universe) [1.15.46+repack-1ubuntu0.20.04.1 => 1.16.19+repack-1ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (eoan-proposed/universe) [1.12.208+repack-1 => 1.16.19+repack-1ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (xenial-proposed/universe) [1.4.70-1~16.04.0 => 1.16.19+repack-1ubuntu0.16.04.1] (no packageset)
<RAOF> Hey, tjaalton - there's no reason not to release the non-mesa packages for #1876882, is there? And there's no reason to release llvm-10 until either mesa or libclc are candidates?
-queuebot:#ubuntu-release- Unapproved: gnome-software (focal-proposed/main) [3.36.0-0ubuntu3 => 3.36.1-0ubuntu0.20.04.0] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: simple-scan (focal-proposed/main) [3.36.0-0ubuntu1 => 3.36.3-0ubuntu0.18.04.0] (ubuntu-desktop)
<tjaalton> RAOF: right, and for llvm-10 it should be harmless to move to updates. libclc/mesa updates are on the queue too
<tjaalton> vorlon: ok, got it
-queuebot:#ubuntu-release- New: rejected artyfx [source] (groovy-proposed) [1.3+git20200508-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.1-0ubuntu2 => 15.2.3-0ubuntu0.20.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libmoox-typetiny-perl [amd64] (groovy-proposed/none) [0.002003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: picopore [amd64] (groovy-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [amd64] (groovy-proposed/none) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-optimalcutpoints [amd64] (groovy-proposed/none) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxsmm [amd64] (groovy-proposed/universe) [1.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [arm64] (groovy-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [armhf] (groovy-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [s390x] (groovy-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [ppc64el] (groovy-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-grohmm [riscv64] (groovy-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apache2 (xenial-proposed/main) [2.4.18-2ubuntu3.14 => 2.4.18-2ubuntu3.15] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (focal-proposed) [0.2.0+git20190827-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1ubuntu0.18.04.3]
-queuebot:#ubuntu-release- Unapproved: python-botocore (bionic-proposed/universe) [1.8.48+repack-1 => 1.16.19+repack-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (xenial-proposed/universe) [1.4.70-1~16.04.0 => 1.16.19+repack-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (eoan-proposed/universe) [1.12.208+repack-1 => 1.16.19+repack-1ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (bionic-proposed) [1.16.19+repack-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (eoan-proposed) [1.16.19+repack-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (xenial-proposed) [1.16.19+repack-1ubuntu0.16.04.1]
<Laney> ubuntu-archive cc xnox: could someone please revert r112 in lp:ubuntu-archive-publishing to drop dual-signing of groovy?
<Laney> We just got the necessary archive hosts upgraded to the new ubuntu-keyring
-queuebot:#ubuntu-release- Unapproved: awscli (bionic-proposed/universe) [1.14.44-1ubuntu1 => 1.18.69-1ubuntu0.18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: awscli (focal-proposed/universe) [1.17.14-1 => 1.18.69-1ubuntu0.20.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: awscli (eoan-proposed/universe) [1.16.218-1 => 1.18.69-1ubuntu0.19.10.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: awscli (xenial-proposed/universe) [1.11.13-1ubuntu1~16.04.0 => 1.18.69-1ubuntu0.16.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: python-s3transfer (xenial-proposed/universe) [0.1.9-1~16.04.0 => 0.3.3-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-s3transfer (bionic-proposed/universe) [0.1.13-1 => 0.3.3-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-s3transfer (eoan-proposed/universe) [0.2.1-1 => 0.3.3-1ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: alsa-lib (focal-proposed/main) [1.2.2-2.1 => 1.2.2-2.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [20.0.8-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: gnutls28 (bionic-proposed/main) [3.5.18-1ubuntu1.3 => 3.5.18-1ubuntu1.4] (core)
 * Laney looks all sad and pathetic
<seb128> Laney, don't be sad, r112 reverted now :-)
<Laney> seb128: thanks, I was trying the "hungry puppy" trick on the archive admins
<seb128> it worked :)
 * Laney notes down for future requests :>
<seb128> lol
<seb128> Laney, https://i.pinimg.com/236x/c8/90/31/c890310187fde1997deae11afe44358c--shrek-so-cute.jpg
<Laney> seb128: stop spying on my webcam
<xnox> ubuntu-keyring uploaded that drops 2012 archive snippet from trusted.gpg.d
<xnox> (but keeps it in the ubuntu-archive-keyring.gpg, because i still want `mk-sbuild xenial` to work)
 * xnox ponders if ubuntu-archive-publishing changes just take effect, or if some kind of a deployment needs to happen
<Laney> dunno, was just going to wait and see
<cjwatson> they need to be pulled manually onto pepo (/srv/launchpad.net/publisher-parts/ubuntu IIRC), but I'm on leave
<cjwatson> normally I do it but you could probably ask IS.  it's a bzr pull as lp_archive@pepo
<cjwatson> please notify #launchpad-ops@irc.c.c when it's done so that they know about it in case there's some odd consequence
<Laney> ah ok, that'll save time waiting, thanks
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [20.0.8-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.18 => 1.173.19] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187 => 1.187.1] (core, kernel)
<rbalint> Laney, could you please check https://code.launchpad.net/~rbalint/ubuntu-archive-tools/retry-intermittent/+merge/384468 again?
-queuebot:#ubuntu-release- Unapproved: linux-firmware (eoan-proposed/main) [1.183.5 => 1.183.6] (core, kernel)
<rbalint> Laney, and https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/384609
<Laney> rbalint: yeah, will do, saw the mail about one of thoes
<rbalint> Laney, thanks in advance and thanks for working on the proposed-migration rebasing!
<Laney> xnox: https://paste.ubuntu.com/p/3BTC6WTV3m/ ð¯
<xnox> whoop whoop
<xnox> Laney:  and i guess archive reports are still working, right?
<Laney> probably give them a little while longer
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (focal-proposed) [1.16.19+repack-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted awscli [source] (focal-proposed) [1.18.69-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1090.100]
<didrocks> vorlon: hey, are you looking at cryptsetup FTBFS? (It failed on all arch but risc). Only need to decide if the conf file should be shipped or not.
<vorlon> didrocks: no, it's deep in my backlog
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (eoan-proposed) [1.16.19+repack-1ubuntu0.19.10.1]
<didrocks> vorlon: I have something to push there before my holidays, Iâll take care of it so that at least things are in proposed (hoping the autopkgtests wonât fail with the new version)
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: accepted python-s3transfer [source] (eoan-proposed) [0.3.3-1ubuntu0.19.10.1]
<Laney> I'm starting more arm64 workers back up, got a positive sign from IS
<Laney> will keep an eye
-queuebot:#ubuntu-release- Unapproved: accepted python-s3transfer [source] (bionic-proposed) [0.3.3-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (bionic-proposed) [1.16.19+repack-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted awscli [source] (bionic-proposed) [1.18.69-1ubuntu0.18.04.1]
<vorlon> Laney: \o/
<Laney> seems OK
-queuebot:#ubuntu-release- New binary: fonts-anonymous-pro [amd64] (groovy-proposed/universe) [1.003-2] (personal-gunnarhj)
-queuebot:#ubuntu-release- New binary: libmoox-typetiny-perl [amd64] (groovy-proposed/universe) [0.002003-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mcl [s390x] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-apparentlymart-go-versions [amd64] (groovy-proposed/universe) [0.0.1+git20180815.64b99f7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcl [ppc64el] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-abeconnelly-autoio [amd64] (groovy-proposed/universe) [0.0~git20150803.989b7b0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-henrydcase-nobs [amd64] (groovy-proposed/universe) [0.1+git20200305.7d891c7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-refraction-networking-utls [amd64] (groovy-proposed/universe) [0.0~git20190909.43c36d3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [s390x] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-h12-socks [amd64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcl [amd64] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (xenial-proposed) [1.16.19+repack-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: kazocsaba-imageviewer [amd64] (groovy-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [amd64] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [s390x] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: molmodel [s390x] (groovy-proposed/universe) [3.0~svn842-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-http-2 [amd64] (groovy-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [amd64] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-console [amd64] (groovy-proposed/universe) [1.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: samclip [amd64] (groovy-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rspec-files [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [s390x] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-s3transfer [source] (xenial-proposed) [0.3.3-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: haskell-assoc [s390x] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: molmodel [amd64] (groovy-proposed/universe) [3.0~svn842-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rspec-memory [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [amd64] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-broadcast-chan [s390x] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seirsplus [amd64] (groovy-proposed/universe) [0.1.4+git20200528.5c04080+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-protocol-http [amd64] (groovy-proposed/universe) [0.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-byte-order [amd64] (groovy-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-protocol-hpack [amd64] (groovy-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-data-fix [s390x] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vitrage-tempest-plugin [amd64] (groovy-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assoc [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-random [s390x] (groovy-proposed/universe) [1.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [ppc64el] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-random [amd64] (groovy-proposed/universe) [1.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-timeit [amd64] (groovy-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-broadcast-chan [amd64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inline-c [amd64] (groovy-proposed/universe) [0.9.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-some [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-timeit [s390x] (groovy-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-constraints-extras [amd64] (groovy-proposed/universe) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-some [s390x] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-bsd [s390x] (groovy-proposed/universe) [2.8.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [ppc64el] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.15 [s390x] (groovy-proposed/universe) [1.15~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-primitive-unaligned [amd64] (groovy-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-bsd [amd64] (groovy-proposed/universe) [2.8.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [ppc64el] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-data-fix [amd64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [riscv64] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: molmodel [ppc64el] (groovy-proposed/universe) [3.0~svn842-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assoc [ppc64el] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-broadcast-chan [ppc64el] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.15 [amd64] (groovy-proposed/universe) [1.15~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-data-fix [ppc64el] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-byte-order [ppc64el] (groovy-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-constraints-extras [ppc64el] (groovy-proposed/universe) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-random [ppc64el] (groovy-proposed/universe) [1.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted awscli [source] (xenial-proposed) [1.18.69-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: haskell-network-bsd [ppc64el] (groovy-proposed/universe) [2.8.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-some [ppc64el] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-primitive-unaligned [ppc64el] (groovy-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [riscv64] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.15 [ppc64el] (groovy-proposed/universe) [1.15~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inline-c [ppc64el] (groovy-proposed/universe) [0.9.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-timeit [ppc64el] (groovy-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [riscv64] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcl [riscv64] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- New: accepted mcl [riscv64] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [riscv64] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted golang-1.15 [amd64] (groovy-proposed) [1.15~beta1-1]
-queuebot:#ubuntu-release- New: accepted haskell-constraints-extras [ppc64el] (groovy-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-random [ppc64el] (groovy-proposed) [1.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-bsd [ppc64el] (groovy-proposed) [2.8.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-some [ppc64el] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [riscv64] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New binary: libmoox-typetiny-perl [amd64] (groovy-proposed/universe) [0.002003-1] (no packageset)
-queuebot:#ubuntu-release- New source: redkite (groovy-proposed/primary) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.15 [ppc64el] (groovy-proposed) [1.15~beta1-1]
-queuebot:#ubuntu-release- New: accepted haskell-inline-c [ppc64el] (groovy-proposed) [0.9.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-timeit [ppc64el] (groovy-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New source: plasma-wayland-protocols (groovy-proposed/primary) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-data-fix [ppc64el] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New source: add64 (groovy-proposed/primary) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-primitive-unaligned [ppc64el] (groovy-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-1.15 [s390x] (groovy-proposed) [1.15~beta1-1]
-queuebot:#ubuntu-release- New: accepted haskell-broadcast-chan [ppc64el] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-data-fix [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-primitive-unaligned [amd64] (groovy-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-timeit [s390x] (groovy-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [ppc64el] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted haskell-assoc [ppc64el] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-bsd [amd64] (groovy-proposed) [2.8.1.0-1]
-queuebot:#ubuntu-release- New: accepted molmodel [ppc64el] (groovy-proposed) [3.0~svn842-1]
-queuebot:#ubuntu-release- New: accepted haskell-byte-order [ppc64el] (groovy-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted shovill [riscv64] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-some [s390x] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-assoc [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-constraints-extras [amd64] (groovy-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-inline-c [amd64] (groovy-proposed) [0.9.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-some [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted shovill [ppc64el] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-broadcast-chan [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-bsd [s390x] (groovy-proposed) [2.8.1.0-1]
-queuebot:#ubuntu-release- New binary: haskell-data-fix [riscv64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-generic-random [amd64] (groovy-proposed) [1.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-timeit [amd64] (groovy-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-broadcast-chan [s390x] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-data-fix [s390x] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted molmodel [amd64] (groovy-proposed) [3.0~svn842-1]
-queuebot:#ubuntu-release- New: accepted ruby-protocol-hpack [amd64] (groovy-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted vitrage-tempest-plugin [amd64] (groovy-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-byte-order [amd64] (groovy-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [ppc64el] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-random [s390x] (groovy-proposed) [1.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted seirsplus [amd64] (groovy-proposed) [0.1.4+git20200528.5c04080+ds-2]
-queuebot:#ubuntu-release- New: accepted haskell-assoc [s390x] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-console [amd64] (groovy-proposed) [1.8.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-rspec-files [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted samclip [amd64] (groovy-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted shovill [s390x] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New binary: haskell-generic-random [riscv64] (groovy-proposed/universe) [1.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted molmodel [s390x] (groovy-proposed) [3.0~svn842-1]
-queuebot:#ubuntu-release- New: accepted ruby-rspec-memory [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New binary: haskell-assoc [riscv64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-protocol-http [amd64] (groovy-proposed) [0.20.0-1]
-queuebot:#ubuntu-release- New: accepted shovill [amd64] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-henrydcase-nobs [amd64] (groovy-proposed) [0.1+git20200305.7d891c7-1]
-queuebot:#ubuntu-release- New: accepted kazocsaba-imageviewer [amd64] (groovy-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [amd64] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [amd64] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted ruby-http-2 [amd64] (groovy-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted golang-refraction-networking-utls [amd64] (groovy-proposed) [0.0~git20190909.43c36d3-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [s390x] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted mcl [amd64] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [s390x] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted fonts-anonymous-pro [amd64] (groovy-proposed) [1.003-2]
-queuebot:#ubuntu-release- New: accepted golang-github-apparentlymart-go-versions [amd64] (groovy-proposed) [0.0.1+git20180815.64b99f7-1]
-queuebot:#ubuntu-release- New: accepted libmoox-typetiny-perl [amd64] (groovy-proposed) [0.002003-2]
-queuebot:#ubuntu-release- New: accepted mcl [s390x] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [riscv64] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-abeconnelly-autoio [amd64] (groovy-proposed) [0.0~git20150803.989b7b0-1]
-queuebot:#ubuntu-release- New: accepted mcl [ppc64el] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [s390x] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted golang-h12-socks [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [ppc64el] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [arm64] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [armhf] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New binary: mcl [arm64] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-broadcast-chan [riscv64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-some [riscv64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-bsd [riscv64] (groovy-proposed/universe) [2.8.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcl [armhf] (groovy-proposed/universe) [1:14-137+ds-6] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [arm64] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: molmodel [riscv64] (groovy-proposed/universe) [3.0~svn842-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-beachmat [armhf] (groovy-proposed/universe) [2.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [arm64] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [armhf] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shovill [arm64] (groovy-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmp [armhf] (groovy-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- Packageset: Removed python-stdlib-extensions from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added what-is-python to i386-whitelist in groovy
<LocutusOfBorg> please anybody
<LocutusOfBorg> old binaries left on riscv64: libplacebo7 (from 1.7.0-2build1)
<LocutusOfBorg> old binaries left on s390x: libplacebo7 (from 1.7.0-2build1)
<LocutusOfBorg> please please!
-queuebot:#ubuntu-release- New binary: ruby-protocol-http1 [amd64] (groovy-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-protocol-http2 [amd64] (groovy-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-sidh [amd64] (groovy-proposed/universe) [1.0+git20190228.d2f0f90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-async [amd64] (groovy-proposed/universe) [1.26.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [amd64] (groovy-proposed) [1.3.9-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (groovy-proposed) [1.3.9-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [arm64] (groovy-proposed) [1.3.9-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (groovy-proposed) [1.3.10-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (groovy-proposed) [1.3.10-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (groovy-proposed) [1.3.10-1]
-queuebot:#ubuntu-release- Unapproved: gnutls28 (xenial-proposed/main) [3.4.10-4ubuntu1.7 => 3.4.10-4ubuntu1.8] (core)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-sidh [amd64] (groovy-proposed/universe) [1.0+git20190228.d2f0f90-2] (no packageset)
<bdmurray> I don't know if people highlight on ubuntu-mir but if they do please note libobject-id-perl and gcc-10-cross had no bug subscriber.
#ubuntu-release 2020-06-18
-queuebot:#ubuntu-release- Unapproved: installation-guide (focal-proposed/main) [20160121ubuntu9 => 20160121ubuntu9.1] (core)
<didrocks> rbasak: FYI, just uploaded the improved SRU of docker for ZFS on focal (19.03.8-0ubuntu2), based on the new version on groovy and removing the migration part, pointing to the wiki page. Tested on direct installation and upgrade path (followed then by the wiki instructions) on ZFS on root, ext4 and ext4 + other zfs path type of installations.
<didrocks> rbasak: sorry, the version is actually 19.03.8-0ubuntu1.20.04 (based on groovy 19.03.11-0ubuntu2)
-queuebot:#ubuntu-release- Unapproved: docker.io (focal-proposed/universe) [19.03.8-0ubuntu1 => 19.03.8-0ubuntu1.20.04] (no packageset)
<seb128> Laney, https://code.launchpad.net/~seb128/ubuntu-archive-scripts/verdict-not-package/+merge/386000 is enough to have the report not fail, I'm going to have a go at the bug reference problem after that one
<Laney> seb128: nice, should be the same thing hopefully
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (focal-proposed/universe) [1.0.20200506-1~20.04.1 => 1.0.20200611-1ubuntu1~20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (eoan-proposed/universe) [1.0.20200506-1~19.10.2 => 1.0.20200611-1ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- New source: wireguard-linux-compat (bionic-proposed/primary) [1.0.20200611-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New source: wireguard (bionic-proposed/primary) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New binary: r-cran-optimalcutpoints [amd64] (groovy-proposed/universe) [1.1-4-2] (no packageset)
<LocutusOfBorg> apw, can you please NBS-proposed cleanup libplacebo? it would make vlc and ffmpeg migrate...
-queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu9.7 => 1:4.0+dfsg-0ubuntu9.8] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu6.2 => 1:4.2-3ubuntu6.3] (ubuntu-server, virt)
<rbalint> seb128, could you please process LP: #1884061 ?
<ubot5> Launchpad bug 1884061 in python-tornado (Ubuntu) "Please remove mitmproxy 4.x from groovy" [Undecided,New] https://launchpad.net/bugs/1884061
<xnox> ubuntu-archive may i start icu transition?
<doko> why should u-a decide that?
<xnox> doko:  i don't know the current status of how many things are entagled, and it will be a doom of autopkgtests again.
<xnox> cause it's boost rebuild too
<LocutusOfBorg> finishing haskell and r-base might be good before doing another one...
<LocutusOfBorg> doko, can you please fix libplacebo?
<rbalint> is there anyone working on r-base?
<LocutusOfBorg> yes rbalint :)
<LocutusOfBorg> and me on haskell
<rbalint> LocutusOfBorg, ok, i take the R ones, btw i'm finishing off the websockets transition
<LocutusOfBorg> rbalint, please coordinate with ginggs :)
<LocutusOfBorg> he is driving it
<ginggs> LocutusOfBorg: i am???
<rbalint> ginggs, LocutusOfBorg  then i'm not the only one who missed that :-D
<ginggs> i do have a list of things that can be hinted
<ginggs> is there any way to revert r-cran-stanheaders to 2.21.0-1-1build1 and r-cran-dplyr to 0.8.5-1build1 ?  the new versions are breaking other autopkgtests
<ginggs> these regressed in release
<ginggs> force-reset-test r-bioc-tcgabiolinks/2.14.1+dfsg-2/s390x
<ginggs> force-reset-test r-cran-rdflib/0.2.3+dfsg-1
<ginggs> force-reset-test r-bioc-cummerbund/2.28.0-1/ppc64el
<ginggs> would someone please 'force-reset-test r-cran-gwidgetsrgtk2/0.0-86.1-1build1/s390x' it depends on r-cran-rgtk2 which is no longer available on s390x
<ginggs> r-cran-openmx/2.17.3-1build1: armhf is a new failure, not regressed in release
<rbalint> ginggs, ok, i'm collecting those in an MP
<LocutusOfBorg> I remember you asking for hints, so in some ways you are the best person to ask for information :)
<ginggs> and i think r-bioc-variantannotation needs to be added to big_packages
<ginggs> rbalint: thanks
<LocutusOfBorg> doko, why is cmake-format trying to use --buildsystem=cmake when the dh call is explictly doing --buildsystem=pybuild?
<LocutusOfBorg> looks a dh-python issue that is ubuntu-only?
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (focal-proposed) [1.0.20200611-1ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (eoan-proposed) [1.0.20200611-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New: accepted wireguard [source] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New binary: wireguard [amd64] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [i386] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wireguard-linux-compat [source] (bionic-proposed) [1.0.20200611-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: wireguard [arm64] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [ppc64el] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [armhf] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [s390x] (bionic-proposed/universe) [1.0.20200513-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard-linux-compat [amd64] (bionic-proposed/universe) [1.0.20200611-1ubuntu1~18.04.1] (no packageset)
<vorlon> xnox: the script I had posted to ubuntu-devel as part of my +1 maintenance report might be useful to you in --dry-run mode, to see how much is currently in -proposed that would entangle new libicu
<xnox> ooooh
<vorlon> xnox: specifically, misc-transition-script libicu66 libicu67 --dry-run | grep Package.*already.present -- shows it would entangle haskell and r-base
<vorlon> xnox: so help us get the R transition into the release pocket :)
<xnox> hm
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.42.1 => 2.45.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.42.1+18.04 => 2.45.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.44.3+20.04 => 2.45.1+20.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (eoan-proposed/main) [2.42.1+19.10 => 2.45.1+19.10] (core)
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-ace-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.newell-ace-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-somerville-melisa-meta [source] (focal-proposed) [20.04~ubuntu3]
-queuebot:#ubuntu-release- New binary: oem-somerville-melisa-meta [amd64] (focal-proposed/none) [20.04~ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-ace-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-somerville-melisa-meta [amd64] (focal-proposed) [20.04~ubuntu3]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4ubuntu0.1 => 1.3.11-1~focal1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27.1ubuntu1 => 1.27.1ubuntu2] (core)
<Trevinho> SRU team, could you please unqueue the shell 3.36.3 stack in focal?
-queuebot:#ubuntu-release- New source: kwayland-server (groovy-proposed/primary) [5.19.1-0ubuntu1]
<seb128> sil2100, if you are not done with your day yet could you review the gnome-shell stack SRU to focal? It's waiting for 10 days+ now and is an important update
<seb128> it's difficult to get those updates reviewed for some reason, unsure if there anything we could do to help things landing with less delay
<seb128> tjaalton, vorlon, other SRU members, ^ if one of you would like to do that in their shift tomorrow
<Trevinho> and... Since you're there there's a mozjs68 update that will be quite nice to handle if you'd just use / merge https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 :)
<RikMills> vorlon: would you perhaps be able to look at plasma-wayland-protocal and kwayland-server in NEW?
<RikMills> LP: #1883501
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<RikMills> LP: #1884120
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<RikMills> or any AA that happens to be feeling kind...
<rbalint> ginggs, agreed, varianannotation is big ubuntu-release please merge https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/386049
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1090.100~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd-signed [source] (focal-proposed) [1.27.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (focal-proposed) [1.3.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected installation-guide [source] (focal-proposed) [20160121ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: installation-guide (focal-proposed/main) [20160121ubuntu9 => 20160121ubuntu9.1] (core)
-queuebot:#ubuntu-release- New binary: bdebstrap [amd64] (groovy-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.10-1 => 1.3.11-1] (core)
-queuebot:#ubuntu-release- New binary: google-common-protos-java [amd64] (groovy-proposed/universe) [1.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-oauth-client-java [amd64] (groovy-proposed/universe) [1.27.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.11-1 => 1.3.11-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.11-1 => 1.3.11-1] (core)
#ubuntu-release 2020-06-19
-queuebot:#ubuntu-release- New binary: golang-starlark [amd64] (groovy-proposed/none) [0.0~git20190717.fc7a7f4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [s390x] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [amd64] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [ppc64el] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-benbjohnson-immutable [amd64] (groovy-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [arm64] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [armhf] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.3-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: ipe [riscv64] (groovy-proposed/universe) [7.2.15-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.3-1ubuntu1~20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (eoan-proposed) [1.183.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.19]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.4+git20200505-0ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (bionic-proposed) [440.82-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libxau [source] (bionic-proposed) [1:1.0.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted installation-guide [source] (focal-proposed) [20160121ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu6.2]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.44.3+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (eoan-proposed) [2.44.3+19.10]
-queuebot:#ubuntu-release- Unapproved: rejected simple-scan [source] (focal-proposed) [3.36.3-0ubuntu0.18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (focal-proposed) [0.30.10-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.6]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (focal-proposed) [1:6.4.4-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.44.3]
-queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (focal-proposed) [1.2.2-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (focal-proposed) [3.36.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (focal-proposed) [3.36.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (focal-proposed) [3.36.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (focal-proposed) [3.36.3-0ubuntu1]
<RikMills> apw, seb128, sil2100 or any AA : would you perhaps be able to look at plasma-wayland-protocal and kwayland-server in NEW?
<RikMills> LP: #1883501
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<RikMills> LP: #1884120
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<RikMills> without those, Kubuntu and studio will get no new plasma for 20.10
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.8 => 1:11.1-1ubuntu7.9] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted wireguard-linux-compat [amd64] (bionic-proposed) [1.0.20200611-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [arm64] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [i386] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [s390x] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [amd64] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [ppc64el] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [armhf] (bionic-proposed) [1.0.20200513-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: libvoikko (focal-proposed/main) [4.3-1build1 => 4.3-1build2] (i386-whitelist, ubuntu-desktop)
<oSoMoN> urgh, please reject that upload ^, it was meant for groovy
-queuebot:#ubuntu-release- Unapproved: rejected libvoikko [source] (focal-proposed) [4.3-1build2]
<apw> oSoMoN, ^
<oSoMoN> thanks
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [4]
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15 => 20.04.15.1] (core)
<juliank> So retry-autopkgtests combines triggers together which lets packages migrate to release pocket which then cause other tests to fail, because they like needed two triggers to work
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (groovy-proposed) [1.3.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (groovy-proposed) [1.3.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (groovy-proposed) [1.3.11-1]
<juliank> e.g. make-dfsg is blocked by dpkg, and if I retry with dpkg as an additional trigger (or something pulling that in), make-dfsg would pass and "break" the dpkg in release pocket.
<juliank> oh ffs autopkgtest
<Laney> Extra triggers in 'bad idea' shocker (same for all-proposed)
<juliank> yeah
<Laney> Maybe we should restrict that to the release team only
<juliank> Laney: and people were suggesting combining triggers in the queue automatically
<Laney> They should be combined where there are package relationships that make them required
<juliank> e.g. if X is trigger by A and B in two entries, delete them and make it triggered by A,B
<Laney> new proposed-migration does that!
<Laney> but otherwise, no nope no
<Laney> Unless we could feed the information back and add extra faux-depends
<juliank> but does it then also add a dependency so that all triggers need to migrate together?
<Laney> it generates the triggers *from* the dependencies
<juliank> ah
<juliank> right, I was thinking if you merge unrelated triggers
<Laney> no, and it's questionable that retry-autopkgtest-regressions does that imho
<juliank> then the entire trigger list should probably only migrate together
<Laney> but we don't have any feedback in that direction atm
<Laney> it probably could be done if we read the triggers on the p-m side ...
<Laney> which would not work for all-proposed :(
<Laney> anyway, why am I talking to you, I'm on a day off and could be outside getting wet :)
<Laney> o/
-queuebot:#ubuntu-release- Unapproved: libfprint (focal-proposed/main) [1:1.90.1+tod1-0ubuntu4 => 1:1.90.2+tod1-0ubuntu1~20.04.1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: harp [s390x] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opendkim [amd64] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mpg123 [ppc64el] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libbytesize [amd64] (groovy-proposed/universe) [2.3-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: mpg123 [amd64] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: harp [amd64] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpg123 [i386] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ibus-table-others [amd64] (groovy-proposed/universe) [1.3.11-2] (input-methods)
-queuebot:#ubuntu-release- New binary: qhull [amd64] (groovy-proposed/universe) [2020.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: open-vm-tools [amd64] (groovy-proposed/main) [2:11.1.0-2] (ubuntu-cloud, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: harp [ppc64el] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpg123 [armhf] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: mpg123 [arm64] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qhull [s390x] (groovy-proposed/universe) [2020.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opendkim [s390x] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opendkim [ppc64el] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qhull [ppc64el] (groovy-proposed/universe) [2020.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: harp [arm64] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: harp [armhf] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppad [s390x] (groovy-proposed/universe) [2020.00.00.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qhull [riscv64] (groovy-proposed/universe) [2020.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opendkim [riscv64] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mpg123 [riscv64] (groovy-proposed/main) [1.26.0-1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: opendkim [armhf] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opendkim [arm64] (groovy-proposed/universe) [2.11.0~beta2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qhull [arm64] (groovy-proposed/universe) [2020.1-2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libfprint (focal-proposed/main) [1:1.90.1+tod1-0ubuntu4 => 1:1.90.2+tod1-0ubuntu1~20.04.1] (desktop-core, ubuntu-desktop)
<Trevinho> please remove the first version of libfprint i uploaded to focal-proposed as it had a bad bug reference number :-/
-queuebot:#ubuntu-release- New binary: cppad [amd64] (groovy-proposed/universe) [2020.00.00.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qhull [armhf] (groovy-proposed/universe) [2020.1-2] (kubuntu)
<seb128> Trevinho, rejected
<Trevinho> seb128: thanks
<seb128> yw!
-queuebot:#ubuntu-release- Unapproved: rejected libfprint [source] (focal-proposed) [1:1.90.2+tod1-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.9-1ubuntu2.1 => 3.9.1-1ubuntu0.20.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: harp [riscv64] (groovy-proposed/universe) [1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppad [armhf] (groovy-proposed/universe) [2020.00.00.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppad [arm64] (groovy-proposed/universe) [2020.00.00.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.22-0ubuntu1 => 0.9.24-0ubuntu0.20.04.1] (ubuntustudio)
<Eickmeyer> ubuntu-archive: Please reject ^ rapid-photo-downloader, it won't build due to debhelper-compat being too high. I'll reduce and reupload.
-queuebot:#ubuntu-release- Unapproved: rejected rapid-photo-downloader [source] (focal-proposed) [0.9.24-0ubuntu0.20.04.1]
<Eickmeyer> ta
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.22-0ubuntu1 => 0.9.24-0ubuntu0.20.04.1] (ubuntustudio)
<Eickmeyer> tjaalton, vorlon: ^ SRU bug 1873944
<ubot5> bug 1873944 in rapid-photo-downloader (Ubuntu Focal) "[SRU] Upgrade rapid-photo-downloader to version 0.9.24" [High,In progress] https://launchpad.net/bugs/1873944
<tjaalton> I'm EOw
-queuebot:#ubuntu-release- New binary: cppad [riscv64] (groovy-proposed/universe) [2020.00.00.3-1] (no packageset)
<vorlon> Eickmeyer: it's a queue; there are a few packages ahead of this one
<Eickmeyer[m]> vorlon: Ok
-queuebot:#ubuntu-release- New: accepted cppad [amd64] (groovy-proposed) [2020.00.00.3-1]
-queuebot:#ubuntu-release- New: accepted cppad [armhf] (groovy-proposed) [2020.00.00.3-1]
-queuebot:#ubuntu-release- New: accepted harp [riscv64] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted opendkim [armhf] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted qhull [armhf] (groovy-proposed) [2020.1-2]
<Eickmeyer[m]> vorlon: It's just that, in the past, my packages and uploads get skipped in the queue a LOT, so you can understand my tepidness.
-queuebot:#ubuntu-release- New: accepted cppad [arm64] (groovy-proposed) [2020.00.00.3-1]
-queuebot:#ubuntu-release- New: accepted mpg123 [riscv64] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted cppad [riscv64] (groovy-proposed) [2020.00.00.3-1]
-queuebot:#ubuntu-release- New: accepted qhull [arm64] (groovy-proposed) [2020.1-2]
-queuebot:#ubuntu-release- New: accepted cppad [s390x] (groovy-proposed) [2020.00.00.3-1]
-queuebot:#ubuntu-release- New: accepted harp [armhf] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted opendkim [ppc64el] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted qhull [ppc64el] (groovy-proposed) [2020.1-2]
-queuebot:#ubuntu-release- New: accepted qhull [s390x] (groovy-proposed) [2020.1-2]
-queuebot:#ubuntu-release- New: accepted harp [arm64] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted opendkim [riscv64] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted opendkim [arm64] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted qhull [riscv64] (groovy-proposed) [2020.1-2]
-queuebot:#ubuntu-release- New: accepted harp [amd64] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted ibus-table-others [amd64] (groovy-proposed) [1.3.11-2]
-queuebot:#ubuntu-release- New: accepted mpg123 [armhf] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted open-vm-tools [amd64] (groovy-proposed) [2:11.1.0-2]
-queuebot:#ubuntu-release- New: accepted qhull [amd64] (groovy-proposed) [2020.1-2]
-queuebot:#ubuntu-release- New: accepted harp [ppc64el] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted mpg123 [i386] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted mpg123 [arm64] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted opendkim [s390x] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted golang-github-benbjohnson-immutable [amd64] (groovy-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted ipe [arm64] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted ipe [riscv64] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted mpg123 [amd64] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted opendkim [amd64] (groovy-proposed) [2.11.0~beta2-3]
-queuebot:#ubuntu-release- New: accepted harp [s390x] (groovy-proposed) [1.11-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [amd64] (groovy-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted ipe [armhf] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted mpg123 [ppc64el] (groovy-proposed) [1.26.0-1]
-queuebot:#ubuntu-release- New: accepted bdebstrap [amd64] (groovy-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted golang-starlark [amd64] (groovy-proposed) [0.0~git20190717.fc7a7f4-1]
-queuebot:#ubuntu-release- New: accepted google-oauth-client-java [amd64] (groovy-proposed) [1.27.0-1]
-queuebot:#ubuntu-release- New: accepted ipe [ppc64el] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-optimalcutpoints [amd64] (groovy-proposed) [1.1-4-2]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-sidh [amd64] (groovy-proposed) [1.0+git20190228.d2f0f90-2]
-queuebot:#ubuntu-release- New: accepted ipe [amd64] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted google-common-protos-java [amd64] (groovy-proposed) [1.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted ipe [s390x] (groovy-proposed) [7.2.15-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-sidh [amd64] (groovy-proposed) [1.0+git20190228.d2f0f90-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [arm64] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted ruby-async [amd64] (groovy-proposed) [1.26.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-protocol-http2 [amd64] (groovy-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted shovill [armhf] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [armhf] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted ruby-protocol-http1 [amd64] (groovy-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gmp [armhf] (groovy-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted shovill [arm64] (groovy-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-assoc [riscv64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-random [riscv64] (groovy-proposed) [1.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-some [riscv64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted mcl [armhf] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted r-bioc-beachmat [arm64] (groovy-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-broadcast-chan [riscv64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted mcl [arm64] (groovy-proposed) [1:14-137+ds-6]
-queuebot:#ubuntu-release- New: accepted haskell-network-bsd [riscv64] (groovy-proposed) [2.8.1.0-1]
-queuebot:#ubuntu-release- New: accepted molmodel [riscv64] (groovy-proposed) [3.0~svn842-1]
-queuebot:#ubuntu-release- New: accepted haskell-data-fix [riscv64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libxsmm [amd64] (groovy-proposed) [1.9-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-grohmm [amd64] (groovy-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted libmoox-typetiny-perl [amd64] (groovy-proposed) [0.002003-1]
-queuebot:#ubuntu-release- New: accepted r-cran-optimalcutpoints [amd64] (groovy-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted picopore [amd64] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New binary: ruby-async-io [amd64] (groovy-proposed/universe) [1.30.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-async-pool [amd64] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-api-client-java [amd64] (groovy-proposed/universe) [1.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [s390x] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [amd64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [arm64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [armhf] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [ppc64el] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [riscv64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
#ubuntu-release 2020-06-20
-queuebot:#ubuntu-release- Unapproved: rejected mozjs68 [sync] (focal-proposed) [68.9.0-1~ubuntu20.04.1]
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [s390x] (groovy-proposed/none) [4.23.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [amd64] (groovy-proposed/universe) [4.23.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [arm64] (groovy-proposed/universe) [4.23.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [armhf] (groovy-proposed/universe) [4.23.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [ppc64el] (groovy-proposed/universe) [4.23.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [amd64] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [s390x] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [ppc64el] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [arm64] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [armhf] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: xmms2 [riscv64] (groovy-proposed/universe) [0.8+dfsg-20] (no packageset)
-queuebot:#ubuntu-release- New binary: bsdmainutils [amd64] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [ppc64el] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [i386] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [s390x] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [arm64] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [armhf] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [riscv64] (groovy-proposed/main) [12.1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: flint [s390x] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [amd64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [ppc64el] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bsdmainutils [amd64] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [s390x] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [arm64] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [i386] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [armhf] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bsdmainutils [ppc64el] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: flint [arm64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bsdmainutils [riscv64] (groovy-proposed/main) [12.1.1ubuntu1] (core, i386-whitelist)
<RikMills> vorlon: can these binaries be clear up? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libplacebo
<RikMills> cleared
-queuebot:#ubuntu-release- New binary: flint [riscv64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [s390x] (groovy-proposed/universe) [4.23.1+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [amd64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [ppc64el] (groovy-proposed/universe) [4.23.1+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [s390x] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [amd64] (groovy-proposed/universe) [4.23.1+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [ppc64el] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [arm64] (groovy-proposed/universe) [4.23.1+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-v2ray-core [armhf] (groovy-proposed/universe) [4.23.1+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [riscv64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [armhf] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: squashfs-tools-ng [arm64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [arm64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [armhf] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted flint [riscv64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [arm64] (groovy-proposed) [4.23.1+ds-3]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [ppc64el] (groovy-proposed) [4.23.1+ds-3]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [riscv64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [amd64] (groovy-proposed) [4.23.1+ds-3]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [s390x] (groovy-proposed) [4.23.1+ds-3]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [s390x] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [armhf] (groovy-proposed) [4.23.1+ds-3]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [ppc64el] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [arm64] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [riscv64] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted flint [arm64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted flint [s390x] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [armhf] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted flint [ppc64el] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted flint [amd64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [amd64] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [ppc64el] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted xmms2 [arm64] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted xmms2 [riscv64] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [i386] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted xmms2 [armhf] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [s390x] (groovy-proposed) [12.1.1]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [arm64] (groovy-proposed) [4.23.1+ds-2]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [ppc64el] (groovy-proposed) [4.23.1+ds-2]
-queuebot:#ubuntu-release- New: accepted xmms2 [ppc64el] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [armhf] (groovy-proposed) [4.23.1+ds-2]
-queuebot:#ubuntu-release- New: accepted xmms2 [s390x] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted xmms2 [amd64] (groovy-proposed) [0.8+dfsg-20]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [amd64] (groovy-proposed) [4.23.1+ds-2]
-queuebot:#ubuntu-release- New: accepted google-api-client-java [amd64] (groovy-proposed) [1.27.1-1]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [armhf] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [riscv64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-v2ray-core [s390x] (groovy-proposed) [4.23.1+ds-2]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [arm64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [s390x] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-async-pool [amd64] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted squashfs-tools-ng [ppc64el] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-async-io [amd64] (groovy-proposed) [1.30.0-1]
-queuebot:#ubuntu-release- New binary: ruby-async-http [amd64] (groovy-proposed/universe) [0.52.4-1] (no packageset)
#ubuntu-release 2020-06-21
-queuebot:#ubuntu-release- Unapproved: gnome-applets (focal-proposed/universe) [3.36.2-1 => 3.36.4-0ubuntu1] (desktop-extra, edubuntu)
<ginggs> rbalint: i think we also need gff2aplot reverted to 2.0-11, it's causing gffread's auopkgtests to fail, which blocks a couple of r-bioc packages
<ginggs> perl had a couple of autopkgtests stuck 'Test in progress' - I've retried those
-queuebot:#ubuntu-release- New binary: libmbim [amd64] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [s390x] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [i386] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [arm64] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [armhf] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [ppc64el] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libmbim [riscv64] (groovy-proposed/main) [1.24.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.9-1ubuntu0.19.10.3 => 3.9.1-1ubuntu0.19.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.9-1ubuntu0.18.04.3 => 3.9.1-1ubuntu0.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: jackd2 (focal-proposed/main) [1.9.12~dfsg-2ubuntu2 => 1.9.14-0ubuntu0.20.04.1] (desktop-core, i386-whitelist, ubuntu-server, ubuntustudio)
<Eickmeyer[m]> ubuntu-archive: Hydrogen was approved for SRU (bug 1883151) on June 12 but has been sitting in updates-proposed since. I can't find anything in update-excuses about it, so why is it stuck?
<ubot5> bug 1883151 in hydrogen (Ubuntu Focal) "[SRU] Hydrogen Bugfix - Update to 1.0.0-rc1" [High,Fix committed] https://launchpad.net/bugs/1883151
<vorlon> Eickmeyer[m]: SRUs are not published to -updates until they have aged in -proposed for 7 days, unless an exception has been requested; and SRUs are only released to -updates Monday through Thursday to ensure someone is available to deal with any regressions
<Eickmeyer[m]> vorlon: It's been in -updates for more than 7 days now afaict.
<Eickmeyer[m]> s/updates/proposed
<vorlon> it was accepted into proposed on the 12. 12+7==19, which was a Friday.
<Eickmeyer[m]> So, it's obviously a Mon-Thurs issue.
-queuebot:#ubuntu-release- New binary: ipe [amd64] (groovy-proposed/universe) [7.2.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmi [i386] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libqmi [amd64] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
