#ubuntu-release 2010-06-14
<ScottL> is this the right channel to talk about the -preempt kernel building uninstallable binaries and it possibly prevent a proper release candidate from being posted at the ISO tracker?
<slangasek> ScottL: you should discuss that with the kernel team (#ubuntu-kernel)
<ScottL> thanks slangasek, i've posted there as well an hour ago or so but hadn't received an answer :(
<ScottL> but at least i know that's the right channel then :)   thanks again
<ScottL> by the way, persia told me i should introduce myself as ubuntu studio project lead
<slangasek> ScottL: does that mean luisbg is no longer the point of contact for Ubuntu Studio release matters?
<ScottL> hi, i'm scott and i'm the new ubuntu studio project lead   (there, presia would be proud :P)
<ScottL> yes, that is correct slangasek
<slangasek> :-)
<slangasek> hi Scott :)
<ScottL> and i'm sorry for any future confusion between me and ScottK
<ScottK> ScottL: I generally cover Universe related issues at release team meetings, so if there are issues you need to get in front of the release team, please let me know.
<ScottL> slangasek, would an email to the -release mailing list introducing myself be required?
<ScottL> thank you very kindly ScottK
<slangasek> ScottL: not required, but you're welcome to do so
#ubuntu-release 2010-06-15
<Riddell> I've never run new-source before but I'm doing so now, is there anything I should look out for?
<Riddell> if I feed it into sync-source.py it seems to run for a few packages before running into errors, it'll take quite a few runs (removing packages already done/errored) to complete
<ajmitch> Riddell: oh, about sync-source.py - I've got a local change to LP that I wanted to run past some archive admins, which is special-casing -XfakesyncY revisions where the upstream versions in ubuntu & debian are the same
 * ajmitch isn't sure how useful it'll be for archive admins, but if it is, I'll submit it to LP
<Riddell> ajmitch: you mean packages that have "fakesync" in their version numbers?
<ajmitch> yes
<ajmitch> a few have been uploaded recently
<ajmitch> it'd just be for convenience, bailing out with a decent error message insted of choking on the orig.tar.gz
<ajmitch> this came up because we were checking whether packages with 'build' in the version number were a special case, or just those with 'ubuntu'
<Riddell> ajmitch: seems interesting
<ajmitch> perhaps, I'll pass it by one of the others before I put a merge proposal in :)
<cjwatson> Riddell: new-source> could you stop pleasE?
<cjwatson> Riddell: you need to first filter it for things that have been removed from Ubuntu but not blacklisted
<cjwatson> Riddell: those all need to be checked by hand
<cjwatson> ajmitch: as I said on ubuntu-devel, why not just use 'ubuntu' there?
<cjwatson> well, I suppose it does have definitely distinct semantics, but in any case, it'd be nice if people who disagree followed up to my mail
<cjwatson> Riddell: if you've already flushed a pile of stuff through, then please go back and check the list to see which ones shouldn't have been reintroduced
<Riddell> cjwatson: I have, they're in New queue now
<Riddell> how do I check to see which ones shouldn't have been reintroduced?
<ajmitch> cjwatson: it's a fairly minor difference wrt ubuntu vs fakesync, it'd let those package be automatically synced without having to be checked through when a new upstream version hits
 * ajmitch had missed which mail you were referring to, though
<cjwatson> Riddell: you have to trawl through publication histories in LP, and then look through the reasons why they were removed
<cjwatson> this takes a while and it's why I'd only done part of them; most of the ones that remain are either relatively new, or difficult
<Riddell> cjwatson: and the file new-source-formerly-in-ubuntu is part of that?
<cjwatson> ajmitch: if you're making sure the autosync only happens when the upstream versions are different and that otherwise we silently skip those packages without breaking the autosync run, then it sounds like a worthwhile improvement
<ajmitch> cjwatson: that was the intent
<cjwatson> Riddell: that was my list of packages from new-source that had a prior publication history as of whenever that file is dated, yes
<cjwatson> Riddell: of course it won't take account of any packages that might have been reintroduced to Debian having previously been in Ubuntu before that
<ajmitch> I don't know how silent you need it, it'll currently print a line about not updating
<cjwatson> ... since then
<cjwatson> doesn't need to be silent, just needs to not fall over
<ajmitch> either way, it's only 10 lines of diff
 * ajmitch will follow up with it tomorrow, it's not a part of LP that has tests at the moment
<wgrant> ajmitch: You know to ignore the SyncSource tests which don't actually test the current implementation?
<ajmitch> wgrant: afaik there aren't tests for scripts/ftpmaster-tools, which is where the change was made
<ajmitch> though I'm not surprised that there are tests to be ignored
<wgrant> ajmitch: Right. But there's another SyncSource implementation lurking around somewhere from years ago. it was mostly written and tested, but never completed.
<ajmitch> wonderful
<Riddell> cjwatson: so if the publication history is empty e.g. https://edge.launchpad.net/ubuntu/+source/beid/+publishinghistory that means it should be safe to let into the archive?
<cjwatson> yes
#ubuntu-release 2010-06-16
<Daviey> Hmm.. Is something up with cd image creation?  Not seeing a daily for maverick server?
<Daviey> infact, not seeing any flavours :/
<Daviey> sorry, am seeing some flavours
<cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ show anything interesting?
<cjwatson> Missing debootstrap-required gnupg-curl
<cjwatson> CD1 missing some packages needed by debootstrap
<cjwatson> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu-server/daily/tmp/maverick-amd64/packages-stamp] Error 1
<cjwatson> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<cjwatson> OK, so this is an archive problem, will fix
<cjwatson> (this happens when packages are dropped out of the ubuntu-minimal set)
<cjwatson> and I managed to drop a whole slew of packages out of ubuntu-minimal recently by a change to gnupg
<cjwatson> fixed for next publisher run, next build after that should work
<cjwatson> thanks
<Riddell> when I do backports with mass-sync I get a big ********** FAILED SYNCS ********** back, can someone else try?
<Riddell> backport 594608 qtgain
<ScottL> should I be concerned that daily ISOs for ubuntu studio have not been built in two days?
<cjwatson> ScottL: have you checked the build logs?
<cjwatson> ScottL: it's probably the same breakage as other alternate/server CDs, though, and as such should be fixed for the next build
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/maverick/daily-20100616.log, search for "ERROR WHILE" - yes, it's the same problem
<cjwatson> but certainly worth reporting in general if you can't figure it out from the build logs
<ScottL> cjwatson, thank you for the links, i shall look into the logs when i get to work :)
<ScottL> i shall have to add those to my growing ubuntu studio related bookmarks ;)
<Daviey> cjwatson: Sorry for the delayed reply.. thanks for looking into that
#ubuntu-release 2010-06-20
 * slangasek moves libpoppler6 where it belongs
<ScottK> slangasek: Thanks.
#ubuntu-release 2011-06-13
<charlie-tca> Can someone kick the server? No images since the 10th of June for Ubuntu/Xubuntu/Server
<cjwatson> have you checked build logs?
<charlie-tca> There aren't any since the 10th
<cjwatson> thanks, it saves time if you say that
<charlie-tca> Sorry. I forgot.
<charlie-tca> but, I did remember to look today.
<cjwatson> hmm, it's certainly *trying*
<ScottK> charlie-tca: None for Kubuntu neither.
<ScottK> The daily status reports over the weekend only reported dvd related errors.
<cjwatson> oh, ENOSPC
<cjwatson> damnit, where's that disk upgrade
<cjwatson> cleaning up a few bits and bobs, but mostly we've hit a wall and I need IS assistance
<cjwatson> (asking there)
<cjwatson> it may manage to limp along for a bit now
<cjwatson> not kicking new images right now though, as the plan is to switch to live-build today
<micahg> could I ask an archive admin to pocket copy chromium from -proposed to -security/-updates for maverick and natty, testing confirmation in bug 794197
<ubot4> Launchpad bug 794197 in chromium-browser (Ubuntu Oneiric) (and 4 other projects) "11.0.696.77 -> 12.0.742.91 (affects: 1) (heat: 258)" [High,Fix released] https://launchpad.net/bugs/794197
<maco> skaet: is there a way to fix the chart on http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kubuntu.html to go with the new set of blueprints?
<skaet> maco,  we just need to link the new set into the topic-oneiric-kubuntu blueprint.
<maco> skaet: i mean the diagonal line
<maco> its really really low because it starts before the blueprints were linked in
<skaet> ahh... yeah its on the list to be cleaned up.
<maco> ok
<maco> thanks
<skaet> where do you want it starting?  110?
<maco> skaet: sure thatd make sense
<micahg> slangasek: can you please pocket copy chromium ^^
<slangasek> micahg: copying
<cjwatson> apologies for live filesystem build noise for those receiving it; just ignore it for now
 * lamont puts the world on manual for a minute or 3
<micahg> slangasek: just checking if you're still copying chromium
<slangasek> micahg: hum, sorry, missed the 'natty' part due to word wrap; copying now
<micahg> slangasek: thanks, I saw maverick hit the bug, but not the archive though
<slangasek> ah, no idea there
<slangasek> should've made it to the archive by now
<micahg> ah, seems to have hit, something's just slow in updating
<slangasek> ok
<micahg> slangasek: thanks!
<slangasek> sure thing
 * slangasek raises his eyebrow at the squid-deb-proxy udeb in NEW
<slangasek> ah, I see, it's avahi integration
<lamont> buildds all back to normal
<cjwatson> live-build migration: done
<cjwatson> world hopefully not too exploded
 * skaet crosses fingers
#ubuntu-release 2011-06-14
<ogra_> cjwatson, wold slightly exploded ... i got "E: There is no default kernel flavour defined for your architecture." for the headless images
<ogra_> *world even
<ogra_> oh, i see the upload, ignore me :)
<cjwatson> yeah, I know, fixed
<cjwatson> two uploads actually, it needed a live-build change too
<cjwatson> oops, forgot to add cdimage support for manifest-remove.  done now
<cjwatson> today's images will be a bit broken, at least for installation
<lool> cjwatson: Cleaned up some armel+imx51 scripts from debian-cd in maverick, natty, oneiric (never used in these releases)
<lool> cjwatson: Also got confirmation from ogra that imx51 support can be stripped of debian-installer trunk
<cjwatson> feel free to do that
 * ogra_ smells the fresh citronized air of a code cleanup :)
<ScottK> So there's going to be no mx51 support?
<ScottK> I had planned (again) to work on this for oneiric.
<ScottK> ogra_, lool, cjwatson: Why are we stripping support for stuff that's (at least for now) on the release manifest for oneiric?
<lool> ScottK: So what I stripped where scripts which were redboot specific "post boot" processing hooks; I think you wouldn't have reused them anyway, but I'm happy to resurrect these if you like
<lool> ScottK: it was basically wget-ing the redboot .deb from the archive, then using tools from redboot-tools to generate a redboot specific config and image format
<ScottK> lool: OK.  I read that as removed mx 51 support entirely.
<lool> ScottK: well, I effectively removed all mentions of mx51 by doing that  :-)
<lool> ScottK: what I think you'd want here is to use the u-boot bits from *omap* to re-implement up-to-date support for your mx51 platform
<ScottK> So you think we'd do it enough differently now that it's irrelevant.
<ScottK> I think that's fine.
<lool> ScottK: albeit if you're thinking of efika*sb* and not the smarttop, then I should mention that u-boot support isn't upstream yet
<ScottK> Thanks for clarifying.
<lool> np
<lool> ScottK: let me know if you are stuck on mx51 related bits; I've been too familiar with them, at least I'd be happy if it servers someone  ;-)
<lool> *serves
<ScottK> Thanks.
#ubuntu-release 2011-06-15
<ogra_> cjwatson, something goes wrong with the headless image build ... i have a mail from last night where it chokes on unmet deps for plasma-widget-networkmanagement and mono, something i wouldnt expect to be in ubuntu-standard (which is what headless used to install by default)
<cjwatson> ogra_: OK, I'll have a look, thanks
<ogra_> seems actually none of the arm images are built since sat
<ogra_> for desktop there is archive skew, so thats expected ...
<ogra_> aha
<ogra_> the headless ext3 filesystem is 1.5G
<ogra_> seems a bit big :)
<ogra_> hmm, no
<ogra_> the one from the 10th is also 1.5G uncompressed
<ogra_> seems /srv has only 21G free
<ogra_> (and the last logs have an out of space error)
<cjwatson> ogra_: OK, I think livecd-rootfs 2.4 should sort out that weirdness
<cjwatson> there were some stale bits lying around from the previous livefs build
<ogra_> great, thanks !
<cjwatson> I think, anyway
<ogra_> well, we'll see
<cjwatson> I'm not entirely certain, so if it still goes wrong, I guess I'll need to look again
<ogra_> whats strange is that there are no debian-cd logs
<ogra_> i see there are livefs'es on the live builder though
<cjwatson> hmm, kubuntu-mobile-omap* is creating squashfses rather than ext3
<cjwatson> oh, I see
<cjwatson> lamont: could you deploy BuildLiveCD r450, please?
<cjwatson> ogra_: ^- should deal with that
<ogra_> ok
<ogra_> i would have expected the issue in cdimage rather than BuildLiveCD
<ogra_> given that the dirs in cdimage scratch/ are all from the 11th
<ogra_> (and the logs too)
<cjwatson> so wait, which image are you looking at now?
<cjwatson> if you mean headless, the cdimage parts don't run at all if BuildLiveCD exits failure
<ogra_> both, headless and ubuntu
<ogra_> (daily-preinstalled)
<ogra_> oh, ok
<ogra_> that explains it then
<lamont> cjwatson: remind me of a branch where I'll find that rev>
<cjwatson> lamont: lp:~ubuntu-core-dev/livecd-rootfs/trunk
<lamont> ta
<lamont> cjwatson: should be live around :45
<cjwatson> great, thanks
 * cjwatson tries a fresh build
<jibel> cjwatson, is bug 797364 what you meant when you said "today's images will be a bit broken" yesterday ?
<ubot4> Launchpad bug 797364 in ubiquity (Ubuntu) (and 1 other project) "build 20110614, strange popup during time zone selection, not closeable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/797364
<ogra_> hmm
 * ogra_ wonders if ALL in the mail recipients list of cdimage actually means "mail for all builds" or just mail for all x86 builds, the summary looks like x86/amd64 only
<ogra_> hmm, no, there is ppc in it
<ogra_> but no armel
<cjwatson> jibel: no
<cjwatson> jibel: but I know about it anyway
<cjwatson> it's a dup of bug 796865
<ubot4> Launchpad bug 796865 in ubuntu "alt installer asks ??? ??? <go back> <continue> (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/796865
<jibel> cjwatson, ok, thanks.
<cjwatson> (and who is using the partman-auto upstream project there?)
<ogra_> hmm, looks like ALL only covers all iso images
<cjwatson> that's not the itent
<cjwatson> intent
<ogra_> well, i just got the Cd health check
<ogra_> (email)
<cjwatson> we don't check .img files at all right now, but that's got nothing particular to do with ALL
<ogra_> well, so i should get buld failure mails for daily-preinstalled images ...
<cjwatson> uh, missing the pooint
<cjwatson> aside from the mail configuration, those mails are independent of the CD health check
<ogra_> aha
<cjwatson> there aren't really any useful checks we can do on preinstalled images anyway, aside from oversizedness
<ogra_> i thought thats one function
<cjwatson> I don't see any reason why you shouldn't get mail about daily-preinstalled image failures
<cjwatson> well, only if they're ubuntu-netbook or ubuntu-headless
<ogra_> well, i thought you fired off a headless testbuild
<cjwatson> it's by project, not by image type
<cjwatson> I did, and it succeedd
<cjwatson> no reason to mail you!
<ogra_> hmm, where did it end up ?
<cjwatson> I didn't do the CD part of it though
<cjwatson> that's running now
<ogra_> ah !
<ogra_> k
<ogra_> sorry, i should have expressed myself better from the beginning
<charlie-tca> cjwatson: apparently something has gone wrong building the Xubuntu desktop images. There are only gnome and unity sessions available for the live desktop.
<charlie-tca> according to the manifest files, there are no xf* package available
<cjwatson> yes, mr_pouit just mentioned the same thing on #ubuntu-devel
<charlie-tca> Thanks
<cjwatson> ogra_: hmm, still seems to have failed
<cjwatson> damnit, it still built a squashfs
<cjwatson> oh, poo, I forgot --chroot-filesystem
<cjwatson> fixed in livecd-rootfs 2.5; will need to build/publish first
<ogra_> k
 * ogra_ crosses fingers
<ogra_> btw, oversized measuring as we use it on isos wouldnt help on preinstalled ... we would need the unpacked size of the rootfs
<cjwatson> jibel: heh, fantastic, it's a Linux 3.0 thing
<jibel> cjwatson, nice, and that's just the beginning of the discoveries.
<cjwatson> nope, we've already discovered and fixed a couple of others :-)
#ubuntu-release 2011-06-16
<ogra_> cjwatson, hmm, so my arm desktop images all end up around 1G ... and there seem to be no manifest files generated for them
<ogra_> i thought it was a copying issue, but even sycamore doesnt have them
<cjwatson> OK, I'll have a look, thanks
<cjwatson> ogra_: won't the size largely be due to switching from netbook to desktop?
<ogra_> well, all other arches are around 700M
<ogra_> surely we grew by switching to desktop
<ogra_> the size isnt my issue, the missing manifests are :)
<cjwatson> fixed your manifest output
<cjwatson> (livecd-rootfs 2.6)
<ogra_> so i can find out what we have extra on arm
<ogra_> thx !
<doko> cjwatson: the list of sources with no binaries in the archive: http://paste.ubuntu.com/627926/
<doko> not yet right/complete.
<cjwatson> ah, you missed udebs in your binary list
<doko> ahh, good point
<doko> s390-* and sparc-* packages can be sorted out
<doko> looking at things like: https://launchpad.net/ubuntu/+source/ubuntu-calendar-march/+publishinghistory  the sources are there, but not more the binaries. any idea why?
<doko> I don't understand the *-ruby packages yet
<cjwatson> I can't remember how to get at BPPH records in the UI
 * cjwatson pokes about in the API
<doko> are the apt.sources lines for downloading the debian-installer packages files?
<cjwatson> binaries were removed with 'unmaintained upstream since hoary; if this is ever revived and somebody steps up to do the packaging work, it can be reintroduced'
<cjwatson> no obvious reason why the source package wasn't removed; I guess that was an accident
<cjwatson> ubuntu.main_archive.getPublishedBinaries(binary_name='ubuntu-calendar-march') # and then poke about through the resulting collection of binary_package_publishing_history objects
<cjwatson> doko: just use main/debian-installer restricted/debian-installer etc. as components
<cjwatson> heh, and I removed the ubuntu-calendar-* binaries back in intrepid apparently, so my bad for missing the sources
<cjwatson> I've removed all six remaining ubuntu-calendar-* source packages now
<cjwatson> oh, and ubuntu-calendar too
<doko> pitti:
<doko> language-pack-gnome-zh
<doko> language-pack-gnome-zh-base
<doko> language-pack-kde-zh
<doko> language-pack-kde-zh-base
<doko> language-pack-zh
<doko> language-pack-zh-base
<doko> source exists, but no binaries
<doko> the ruby packages are a lot of source renames
<doko> cjwatson: filed https://bugs.launchpad.net/ubuntu/+bug/798195  will do the ftbfs checks later
<ubot4> Launchpad bug 798195 in ubuntu "source packages in oneiric without binaries (affects: 1) (heat: 8)" [Undecided,New]
<pitti> doko: oh, these source pkgs should be removed; doing now
<doko> pitti: could you update the bug report above?
<pitti> yep, will do
<ScottK> Aren't some of those the ones we removed binaries for during Lucid so we wouldn't have unsupportable binaries in an LTS?
<ScottK> Why the push to remove the source now?  My recollection was that we decided keeping the source was harmless.
<nigelb> skaet: And, here's the list I've promised :)
<nigelb> http://paste.ubuntu.com/628055/
<skaet> nigelb,  Thanks!  do you have the bug numbers associated with them?
<nigelb> skaet: Not yet. tumbleweed is figuring that out :)
<skaet> nigelb,  sounds good.  :)
<tumbleweed> skaet: without being able to programattically link bugs to blueprints, I don't think this is going to be very workable
<skaet> tumbleweed, it feels like it should be scriptable,  just going to be a matter of figuring out the right launchpad API's to let us find and hook them up.
<tumbleweed> there are API methods for linking branches, but not bugs (that I can see). Bugs appear to be read only
<skaet> hmm... which version are you looking at?
<tumbleweed> devel, 1.0 has almost nothing for blueprints
<nigelb> What are we trying to do, file bugs and then link them to the BP?
<skaet> nigelb,  yup
<tumbleweed> find the bugs already filed
<nigelb> tumbleweed: finding should be easy.
<tumbleweed> and then link them :)
<nigelb> worst case
<skaet> tumbleweed,   searching on the tag ftbfs under the oneiric bugs gives you the first pass.   Then for each of the bugs,  need to determine if the project is against universe
<nigelb> we can have it print out the bugs and we can link manually
<nigelb> tumbleweed: oooh
<nigelb> tumbleweed: talk to brian please? he has a selinium test thingy account
<nigelb> tumbleweed: That can do this linking from the web ui.
<nigelb> tumbleweed: iamfuzz on irc
<skaet> If its about 80,  I'll take a share.    If its going to be 780,  then yeah we need to do it programatically.
 * skaet heads out to lunch,  biab
<tumbleweed> nigelb's list was ~80, which is manageable, yes. If it were more than that I'd say there are easier ways to get progress graphs (the FTBFS page on qa.ubuntuwire has CSV output that would be trivial to store and graph)
<nigelb> tumbleweed: I wwas actually hoping to use harvest, bug in harvest prevented that.
<nigelb> (I should file that bug)
<micahg> nigelb: what's that list for?
 * micahg notices chromium
<nigelb> micahg: ftbfs, that's because of linking changes
<micahg> ah, ok
<nigelb> micahg: is the chromium failure correct in that way?
<micahg> nigelb: yes, but I think it's fixed now
<nigelb> we scraped the list 2 days back
<micahg> oh, wait, arm is still broke I think
<ogra_> yes, hrm is working on an arm fix atm
<ogra_> in a very heroic attempt :)
<ogra_> err
<ogra_> s/hgrm/hrw/
<ogra_> heh
<micahg> nigelb: I think gcc-4.6 + chromium on i386 is fixed in trunk ATM, will check
<nigelb> ogra_: heh, interesting spell-error ;)
#ubuntu-release 2011-06-17
<ScottK> cjwatson: It was just pointed out to me that the Kubuntu amd64 images seem to have vanished: http://cdimages.ubuntu.com/kubuntu/daily-live/current/ - any idea what's up with that?
<cjwatson> have you checked the logs?
<cjwatson> xorriso : FAILURE : Cannot determine attributes of source file '/srv/cdimage.ubuntu.com/scratch/kubuntu/daily-live/tmp/oneiric-amd64/-efi-boot' : No such file or directory
<cjwatson> by the looks of things
<ScottK> I thought I was supposed to be getting mailed all the failure logs.
<ScottK> I don't recall that one.
<ScottK> I notice the amd64 image isn't listed on the Kubuntu CD daily health check anymore either.
<cjwatson> maybe it didn't fail sufficiently hard
<cjwatson> anyway, I think that option needs to be --efi-boot with xorriso
<ScottK> Where does that need to be fixed?
<ScottK> AFAIK no one in Kubuntu messed with anything that would affect CD building.
<cjwatson> it's fallout from my hybrid CD/USB changes
<cjwatson> fixed in debian-cd now - thanks for the report
<ScottK> Great.  Thanks.
 * cjwatson tries rebuilding that image
<cjwatson> (though it'll have broken all amd64 images, not just Kubuntu)
<cjwatson> for the record, I think that a failure of any individual live filesystem gets mailed out, but if a subset of architectures fail at the CD build stage then that doesn't get mailed, unfortunately
<cjwatson> it'll only trigger a mail if all arches fail, I think
<cjwatson> I found it from http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/oneiric/daily-live-20110617.log
<ScottK> Thanks.  I have to run to catch a flight, but I let the reporter know you were on it.
<cjwatson> is there a bug#?
<cjwatson> have a good flight
<ScottK> No.  It was an IRC report.
<cjwatson> ok
<ScottK> How about the image not appearing anymore on the daily health check mail?
<cjwatson> same reason
<cjwatson> it's probably just been failing for enough days unnoticed that it eventually got purged
<ScottK> I guess I need to read them closely enough to notice that all the wanted images are actually listed.
<ScottK> Thanks.  Gotta run....
<Laney> what's the purpose of (^| ) and \s*(,|$) in the dh-python2 is_affected regexp?
<cjwatson> I was trying to stop it matching libfoo-python
<Laney> ah
<Laney> I blindly cribbed it for mono.ben and it nobbled the match a bit
<cjwatson> it's possible I got it wrong :)
<Laney> dunno, don't want to think about it :-)
<Laney> it's enough to know that we don't need it ;)
<tumbleweed> it sounds like ben should be taught to split and normalise dependancy lists
<cjwatson> it's possible it already does know and I wasn't aware of it ;-)
<Laney> speak to mehdi
 * Laney returns to modelling STM
<ScottK> cjwatson: I got a failure mail for the retry with no log in it.  I also don't see anything likely in http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/oneiric/ - where should I be looking?
<cjwatson> I ran the wrong command by mistake, and then got distracted by looking into the reason every single livefs build is failing right now
<cjwatson> which seems to be some regression related to dpkg triggers, although I haven't yet worked out where
<ScottK> OK.
<ScottK> It's not critical.
<ScottK> As long as whatever needs doing is somewhere on the TODO, no rush.  Certainly sounds lower priority than that.
<ScottK> Also the airport wifi has gone very laggy, so don't be surprised if I'm not terribly responsive.
<jdstrand> I have not been able to get a natty mini.iso (amd64) to boot after install in kvm. I'm told that it is broken. https://help.ubuntu.com/community/Installation/MinimalCD has links and checksums. is this known and if so, are we planning to fix it?
<jdstrand> well, 'boot to a prompt'
<jdstrand> it seems to get past grub but then all I get is a blinking cursor
<jdstrand> meh
<jdstrand> out of range pointer 0x8022000
<jdstrand> Aborted. Press any key to exit.
<jdstrand> (maverick amd64 mini.iso)
<jdstrand> (I used virtio driver)
<ScottK> skaet: Sorry I forgot to warn you I'd miss today's meeting.
#ubuntu-release 2012-06-11
<Daviey> infinity: yes
<Riddell> cjwatson, infinity: fancy eyeing over these for merge? https://code.launchpad.net/~jr/ubuntu-cdimage/kubuntu-quantal/+merge/109612 https://code.launchpad.net/~jr/livecd-rootfs/kubuntu-quantal/+merge/109611
<Riddell> that etc/crontab file in ubuntu-cdimage seems suspicious incomplete to me
<Riddell> cjwatson: also kubuntu bits can be moved to universe any time you like
<cjwatson> Yeah, it's incomplete at the moment
<cjwatson> Riddell: So I meant to talk with you about that - there seemed to be some disagreement on kubuntu-devel about whether that was desirable.  Have you resolved that or are you just taking a leadership decision? :-)
<Riddell> cjwatson: making a decision, but maybe ScottK wants to wait and debate it
<cjwatson> Riddell: merged your branches plus a little bit more
<Riddell> thanks
<ScottK> Riddell: I was clearly in the minority, so no problem.
<ScottK> Riddell: Once the move is in place, it probably merits a mail to ubuntu-devel-announce.
<Riddell> cjwatson: ^^
<zul> can someone promote python-jsonschema its been acked by the MIR team (bug #1003729)
<ubot2> Launchpad bug 1003729 in python-jsonschema "[MIR] python-jsonschema" [High,Fix committed] https://launchpad.net/bugs/1003729
<cjwatson> zul: It's not in component-mismatches.  Are you about to upload something that depends on it?
<zul> cjwatson: doh...i need to upload glance first, ill nag you guys on friday
<zul> sorry about that
<cjwatson> No, that's OK, I can promote it as long as you're about to do the upload
<cjwatson> I just want to make sure that's happening since as soon as I move it to main it'll show up on our report for moving back to universe
<zul> cjwatson: it will happen this week
<cjwatson> zul: I've gone ahead and moved it to main, then
<zul> cjwatson: merci buckets
<henrix> hi! we have a bunch of kernels waiting to be moved into -updates. any chance of having someone taking a look at those?
<henrix> i never know exactly who shall i ask to do this :)
<xnox> http://packages.qa.debian.org/libc/libconfig.html package has started uncordinated library transition from libconfig8 -> 9
<xnox> currently sitplus fails to build from source in ubuntu
<xnox> because it expects libconfig9
<xnox> in ubuntu we carry a delta which simply adds shlib symbols files
<xnox> is it save to initiate a transition in ubuntu? should I file a bug first?
<xnox> 11 packages are affected by the transition
 * xnox -> eod
 * xnox wrong channel =)
<infinity> xnox: If it's just 11 packages without wildly irriating chained dependencies, we can JFDI.
<infinity> xnox: Especially if there's no API break.
<xnox> infinity: ok, after I do the merge and generate new symbols...... I wonder if libconfig is api compatible as well and the soname bump was worthless
<infinity> You mean ABI?
<infinity> If there's no ABI break, that's a bit of an oops.
<infinity> Anyhow, if you do the merge, I can hammer out all the rebuilds.  No point giving me a ton of empty MPs.
<xnox> infinity: =))))) hmmm I like empty MPs =))))) they generated multiple bugs against sponsorship page: including gems such as "group by a certain contributors" and "exclude those merge proposals that can only be reviewed by selected members of foundations team"
<xnox> infinity: to be fair you only got half of the rebuilds ;-) I have been doing self-service NMU+sync to rebuild some of them ;-)
<infinity> xnox: Heh.
<Daviey> xnox: no-change debian NMU then sync to Ubuntu to support a Ubuntu transition ?!
<xnox> Daviey: no, no senior, le reale patches NMU por RC ants =)
 * xnox spanish/french sucks
<slangasek> I'm going to have so much fun with you in Nicaragua
<infinity> "RC ants"?
 * infinity giggles.
<slangasek> infinity: les fourmis CR
<seb128> xnox, hey
<Daviey> xnox: oh good.. i was kinda wtf'ing :)
<infinity> slangasek: Thanks for the translation. :P
<xnox> seb128: hallo =)
<seb128> xnox, if you diff the libconfig.h between those versions you have a bunch of type changes in functions types
<seb128>  extern LIBCONFIG_API int config_lookup_int(const config_t *config,
<seb128> -                                           const char *path, long *value);
<seb128> +                                           const char *path, int *value);
<seb128> xnox, like that one
<slangasek> infinity: avec prazer
<seb128> xnox, so that count as ABI changes
<xnox> seb128: and that's the reason why sitplus is FTBFS currently =) why they did, I do not understand.
<slangasek> seb128: that's not a C ABI change
<slangasek> but it is an API change
<infinity> ^
<seb128> slangasek, well, the lib has a cpp variant
 * xnox better to do this earlier than later
<cjwatson> slangasek: Is that true on all architectures?
<slangasek> seb128: but that doesn't look like a C++ api call
<slangasek> cjwatson: I'm fairly certain it is, yes; sizeof(long *) == sizeof(int *), so even on archs with weird calling conventions (like alpha), it should have no impact on the ABI
<cjwatson> Surely if it's big-endian that could end up writing an int into the top half of a long, if the caller was expecting the old abi
<slangasek> oh
<slangasek> well right
<slangasek> I apparently was being too strict in my definition of "ABI" and should drink more coffee
<seb128> they changed some structs as well (dropping members of the struct)
<seb128> seems like a valid soname change case
<seb128> xnox, slangasek, cjwatson: well anyway that was just to add a piece of datas ;-)
<slangasek> agreed
<slangasek> agreed that it seems a valid change
<slangasek> seb128: thanks :)
<xnox> for symbols do I generate all symbols with the latest version of libconfig9
<xnox> or shall i reuse the 'introduced' version of the libconfig8
<xnox> new library, new symbols, start afread?!
<slangasek> xnox: not sure I'm understanding the question
<slangasek> are you asking what version number to use in the .symbols file for libconfig9?
<slangasek> short answer is "it doesn't matter" since there's an ABI break
<seb128> slangasek, I think he's asking "if a symbol is there for age, do we keep the version where it was added for the .symbols or do we reset all symbols to the new soname version"
<slangasek> i.e., as long as the version you use is <= the minimum version of libconfig9 found in Ubuntu, it will never be an issue
 * slangasek nods
<xnox> ok.
<xnox> not that the old one was ever used, yet was required for 'main' inclusion...
<infinity> Wasn't used in what sense?
<infinity> dpkg-shlibdeps prefers .symbols over .shlibs, if it exists.
 * slangasek nods
<slangasek> it's possible the .symbols never gave a different answer for dependencies than the .shlibs did, but it was certainly used :)
<slangasek> (but I don't think it's sane to make this a requirement for main inclusion fwiw)
<infinity> No, a sane .shlibs is perfectly reasonable in many/most cases.
<xnox> infinity: as in, there was never a newer release of libconfig in ubuntu and debian didn't accept symbols file
<seb128> xnox, did they reject it or just ignored it?
<xnox> ignore.
<seb128> unresponsive maintainer I guess
<xnox> and the next upstream version bump upload in debian, was abi bump.
<seb128> though that package has a cpp lib, which are not .symbols friendly ;-)
<xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618735
<ubot2> Debian bug 618735 in libconfig "libconfig: Add symbols to library packages." [Wishlist,Open]
<xnox> Date: Fri, 18 Mar 2011 11:36:06 +1100
<xnox> slangasek: do you imply that we should drop our 'symbols' file and sync?
<slangasek> xnox: that would be my preference... who requested/required the .symbols file in the first place, do you know?
<slangasek> (is this in the MIR history?)
<seb128> that's one of the things the MIR team like to require ;-)
<xnox> slangasek: https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760/comments/2
<ubot2> Launchpad bug 730760 in libconfig "[MIR] b-d for libffado" [High,Fix released]
<slangasek> seb128: hunh
<infinity> xnox: I'm with vorlon on this; I see no reason to carry a delta just for a symbols file, assuming the shlibs are correct.
<seb128> slangasek, well, I just know that mterry consistently require to have a .symbols and the testsuit to be run if there is one
<infinity> (Yes, it's also nice to use the symbols file to make sure the ABI doesn't break accidentally, but with something we're syncing with Debian, we can hope it'll get caught there if that happens)
<slangasek> seb128: I agree with the latter, and not at all with the former... so I'm going to talk to him about this, since it seems to not be in the MIR wiki page at all
<infinity> seb128: The second requirement there, I heartily agree with.
<slangasek> xnox: stay tuned for further developments on #ubuntu-devel :)
<xnox> the idea was that debian picks it up & we sync. Debian didn't pick it up....
<seb128> ;-)
 * xnox grabs pop-corn and 'Go vorlon' flags
<seb128> right, I think mterry just try to encourage us having one, I don't think that's a strict requirement
<slangasek> yep - clarification requested
<slangasek> in that case specifically, though, he said "rejected" due to lack of symbols files
<xnox> I will commit a transition tracker, and wait for resolution on this issue.
<infinity> xnox: A transition tracker for 11 packages seems like overkill (it was only 11, yes?)
<infinity> xnox: I can just blat them all at the archive after your library builds. :P
<seb128> slangasek, well he has been consistently asking for one so I'm not surprised ;-) not sure we ever argued on "we wrote on, sent it to debian, they didn't take it and it's our only diff with them on this source"
<xnox> infinity: i like watching green ticks before going to bed ;-)
<xnox> in debian there are transition trackers for like 3 packages
<xnox> infinity: i am expecting boost1.49 and/or gcc4.7 failures =)
<xnox> http://people.canonical.com/~ubuntu-archive/transitions/libconfig9.html
<stgraber> can someone reject lxc from proposed? there's an extra fix that we'd like to bundle
<RAOF> Done.
<stgraber> thanks
#ubuntu-release 2012-06-12
<jibel> there is no desktop image for the last 3 days. can anyone have a look ?
<Daviey> the cronjob suggests it's currently building
<jibel> Daviey, could it be a problem with ppc ? I don't have a view on the builder but from the date of the livefs build logs, the 8th ppc was built 14h after x86, 8h on the 9th, and there is no log for PPC yesterday and today. and there is no cd build log at all for all arch since the 10th
<Daviey> jibel: I see build logs for 09,10,11,12 ?
<cjwatson> There's certainly some kind of backlog, judging from nusakan's process list
<Daviey> jibel: cd images dated today http://cdimage.ubuntu.com/daily/current/ ?
<Daviey> there are indeed a bunch of powerpc blocking
<cjwatson> Daviey: not live CDs, so not relevant
<jibel> Daviey, but no desktop http://cdimage.ubuntu.com/daily-live/
<Daviey> cjwatson: That was an intentional oversight, and i was wondering who would spot it.
<Daviey> Perhaps related, the machine was rebooted 3 days ago.
<Daviey> 4 now
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/lubuntu/latest/livecd-20120609-powerpc.out - stuck in update-initramfs maybe?
<cjwatson> (that was the oldest, I killed it)
<cjwatson> OK, so I've killed a bunch of the backlog.  The three currently trying to build are livecd-base/quantal, ubuntu/daily-live/precise, and ubuntu/daily-live/quantal
<cjwatson> So we'll see whether those repeat the problem
<jibel> thanks
<cjwatson> Failing that, it'll probably need somebody like infinity to investigate
 * Daviey leaves it then.
<Riddell> no daily CDs since the 9th?
<cjwatson> see scrollback
<cjwatson> At this point I can't see what's going on on royal, and am waiting for infinity to wake up to assist
<xnox> infinity: thanks for the libconfig rebuild/transition =)
<infinity> xnox: NP.
<pgraner> infinity, ppc hw info pls </friendly reminder>
<xnox> yeah ppc is slow =) my boost1.49 transition is lagging due to ppc =((((((
<pgraner> xnox, poke infinity then :-)
<Laney> why is ross disabled?
<xnox> Laney: see notes on the builder
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005699 RT#51115
<ubot2> Launchpad bug 1005699 in linux "tg3: reports "eth0: DMA Status error. Resetting chip.", fails to work" [High,Confirmed]
<infinity> Because it was upgraded to precise and ran into a kernel bug.
<Laney> builders have notes?
<infinity> ^
<infinity> Laney: They do when I add them. :P
<xnox> Laney: just below the status on this page https://launchpad.net/builders/ross
<Laney> I didn't even know that was a thing
<Laney> ta
<cjwatson> infinity: Speaking of powerpc, can you tell what's happening on royal?
<infinity> cjwatson: No, but webops can.
<infinity> cjwatson: I haven't had direct access to buildds since I came back.
<cjwatson> infinity: Ah, my bad, I thought you did.
<infinity> Wish I still did.  Would make my life easier. :P
<seb128> skaet, slangasek: should bug #987220 we tracked for the lts maybe? it seems a quite frequent complain
<ubot2> Launchpad bug 987220 in upstart "no complete shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/987220
<seb128> not sure who,what team would be the best placed to look at that
<slangasek> seb128: is it reproducible, tractable?
<slangasek> seb128: there are probably separate issues here - the users saying "halt doesn't work" have an incorrect expectation of the behavior of 'halt', and that's probably most of the interest in the bug
<slangasek> so I guess the question is... is GNOME incorrectly calling 'halt' as well :)
<slangasek> GNOME and/or indicator-session
<seb128> slangasek, well, let's say I hit an issue at least once a week where shutdown does trigger a shutdown (i.e session closing, init going to the corresponding level, services being stopped, but the machine actually never power off), I was wondering if that's the same issue
<seb128> slangasek, I've seen quite some people complaining about that "never power off"
<slangasek> seb128: it may be... do you know what command indicator-session is calling to shut down?
<seb128> slangasek, hints on how to debug would be welcome
<slangasek> code inspection
<slangasek> if it's related, then it's because something is calling 'halt' based on the same wrong assumption of the meaning of this command
<seb128> slangasek, I need to check but I think indicator-session justs uses the gnome-session interface, which might call consolekit or the login manager
<seb128> slangasek, well, I doubt indicator-session call different commands according to the day so it's not as simple as "it's calling a buggy command" I guess
<slangasek> well, we should probably be sure anyway.  Do you know what package that code lives in?
<seb128> slangasek, so indicator-session does a call to gnome-session's RequestShutdown dbus interface ... checking what that does
<slangasek> seb128: does it?  When I looked at indicator-session I saw it pointing at consolekit
<slangasek> and consolekit calls the correct interface
<seb128> slangasek, you looked to consolekit_fallback()?
<seb128> 	} else if (action == LOGOUT_DIALOG_TYPE_SHUTDOWN) {
<seb128> 		g_debug("Asking Session manager to 'RequestShutdown'");
<seb128> 		res = dbus_g_proxy_call_with_timeout (sm_proxy, "RequestShutdown", INT_MAX, &error,
<seb128> 											  G_TYPE_INVALID, G_TYPE_INVALID);
<seb128>  
<seb128> slangasek, that seems the normal action in gtk-logout-helper.c
<seb128> ck seems the be the fallback
<seb128> slangasek, but gnome-session uses ck as well
<seb128>         res = dbus_g_proxy_call_with_timeout (manager->priv->ck_proxy,
<seb128>                                               "Stop",
<slangasek> seb128: I was looking in src/gtk-logout-helper.c
<seb128> slangasek, right, you looked at consolekit_fallback() which is a the top of this file
<seb128> slangasek, down the file there is the code I copied, anyway they both call ck Stop
<slangasek> ah
<slangasek> ok
<slangasek> seb128: have you reproduced this bug yourself?
<seb128> slangasek, as said it happens to me once a week
<slangasek> hmm
<seb128> my laptop goes all the way down like it was stopping but never actually power off when that happens
<seb128> I'm not 100% sure that's what all those users have but it seems similar
<slangasek> many of the users are seeing user error
<slangasek> and I never shut down my laptop, I reboot it or suspend it... so I can't say if your experience is typical
<slangasek> what % of the time do you hit the issue?
<seb128> ok
<seb128> random guess; 5%
<slangasek> crazy
<seb128> well "rought estimation"
<slangasek> and the GUI shuts down, leaving you at a kernel console, and fails to power off?
<seb128> I usually power off my laptop once a day
<seb128> the guy shut off, I see the typical vt "stopping ..." lines
<seb128> then at the point it would normally power off it "sits" there
<seb128> I need to press the power button 5 seconds to power it off at this point
<slangasek> I guess I would like to see a screen capture of the hung state
<seb128> guy->gui
<slangasek> to rule out it being a userspace issue... but it's probably a kernel issue
<seb128> ok, I will take one next time it happens
<slangasek> cheers
<seb128> can I get any other useful info when the system is in this state?
<seb128> or after reboot?
<slangasek> maybe, but I don't want to have you do a bunch of extra debugging that's speculative... want to know what's on the screen and see where we should go from there
<seb128> slangasek, ok, I will ping you back with those infos when I get them ;-)
<slangasek> seb128: sounds good, thanks :)
<seb128> slangasek, thank *you* for helping ;-)
<SpamapS> can somebody queue-jump this build: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.25-0ubuntu2/+build/3570349 .. the archive is already skewed badly for mysql and i386 landing well before amd64 will just skew it worse.
<infinity> SpamapS: I already did.
<SpamapS> oh
<infinity> Oh, I can jump it harder. ;)
<SpamapS> did you mean to push it back behind the others?
<infinity> No.
<SpamapS> As I was typing that I thought 'huh.. 999999 looks odd'
<infinity> Higher = better.
<infinity> But let me give it a disabled buildd. :P
<SpamapS> ok
<infinity> There.
<infinity> Jumped with prejudice.
<infinity> Here's hoping the MySQL testsuite doesn't rely heavily on perl.
<SpamapS> Well I think it should be ok.. the uninstallability is coming from >='s not =='s
<SpamapS> so actually i386 landing early should be fine
<SpamapS> infinity: no they rewrote it in scala
<SpamapS> with an erlang backend and node-js for stats
<infinity> Tell me that's a joke.
<SpamapS> mysql is web scale ;)
<micahg> lol
<infinity> Please.
<SpamapS> perl, its all perl
<infinity> Right, well, we'll see if it explodes.
 * SpamapS will bring marshmallows
<infinity> hardy kernels and quantal's perl have disagreements.
<infinity> And I think I confused allspice.
 * infinity tries another.
<SpamapS> thats the problem with calling an LTS "hardy" .. sysadmins just don't want to replace their hardy old friend with some lucid hippie or a precise git.
<infinity> No, the real problem was that we dropped Xen support in the interim LTS. :/
<infinity> Thankfully, it's back.
<SpamapS> we're just kvm haters? ;)
<SpamapS> rpl.rpl_ssl1 'mix' [ pass ] 3613
<SpamapS> hooray
<infinity> We had pretty valid reasons for going with Xen back in the day.
<SpamapS> Xen was better than kvm for a long time
<infinity> Most of those reasons aren't particularly important anymore, but changing one's infrastructure for the flavour of the month is silly.
<micahg> infinity: I guess you don't want mysql built before tomorrow :P
<infinity> micahg: ?
<micahg> yellow is soooooo slow
<infinity> Oh, bah.  It's not THAT bad.
<infinity> It builds in 3.3h on a Panda, yellow's not slower than that. :P
<micahg> I guess as long as no = are breaking badly, it doesn't matter much anyways
<micahg> ah, fine, I thought it was much worse than that
<micahg> could I get the apparmor security updates above approved?
<micahg> infinity: are you still around?
<infinity> micahg: Nope.
<micahg> infinity: can you approve my apparmor -security syncs?
<infinity> micahg: To which releases?
<micahg> lucid, natty, oneiric, precise (I used copyPackage from the security PPA)
 * infinity is so grumpy that those have no diffs.
<infinity> micahg: What are you fixing in apparmor in the Mozilla PPA? :P
<micahg> infinity: abstractions, diffs are in that PPA if you want
<infinity> micahg: Kay, in the middle of a meeting right now, but I'll poke it shortly.
<micahg> infinity: thanks
<infinity> skaet: Can you mail out the raw notes/minutes to everyone who was in that meeting just now?  I don't want to have to remember some URL to a Google doc. ;)
<skaet> infinity,  will do.
<Daviey> skaet: can you send it to a wider audience please? :)
<skaet> Daviey,  ack.   Needs to be made prettier though first.
#ubuntu-release 2012-06-13
<mvo> if someone from the SRU team could look at the aptdaemon upload, that would be awsome, this should reduce the amount of crashes on errors.ubuntu.com quite a bit and also one issue around ubuntu software-center when downloading psychonauts
<cjwatson> mute queue new ubuntu-release
<cjwatson> mute queue new quantal-release
<cjwatson> too slow
<cjwatson> ummute queue new ubuntu-release
<xnox>  ^^    cjwatson, still a typo
<xnox> coffee?
<Laney> can anyone execute those commands?
<Laney> unmute queue new ubuntu-release
<Laney> hoho
<xnox> what about unmuting quatnal-release?
<cjwatson> xnox: no that was deliberate
<cjwatson> correcting my earlier typo
<Laney> "ummute"
<cjwatson> I'll unmute quantal-release in a few minutes once it's cleared
<cjwatson> oh doh
<cjwatson> unmute queue new quantal-release
<jibel> there's no daily Ubuntu desktop build.
<jibel> 12th finally built late afternoon yesterday
<jibel> can anyone look why there is no desktop image today ?
<cjwatson> jibel: Same as yesterday; blocked on powerpc livefs builds.  I talked with webops about that yesterday and they found that royal needs a replacement disk and took it down.  I'd hoped that that would mean that the trigger would just quickly fail, but evidently not.
<cjwatson> jibel: I've disabled those builds with a bigger stick now.
<jibel> cjwatson, thank you
<cjwatson> And I've killed the blocked processes, so I think you should get builds fairly soon.
<skaet> infinity,  is there a bug number or some specific reason we haven't gotten Ubuntu armhf+omap4 builds sinc 6/10?
<cjwatson> Which product (preferably URL)?
<cjwatson> Ah, you said Ubuntu, never mind
<knome> ah, i thought she meant red hat...
<knome> :)=
<cjwatson> skaet: I can't see exactly why.  The ssh trigger to celbalrai.buildd for the livefs build fails after one second, but it doesn't seem to produce any output
<infinity> Special.
<cjwatson> Nothing useful in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-omap4/
 * skaet nods
<infinity> Looks like all triggers to celbalrai are dying, it's not just ubuntu-omap4.
<infinity> Which is slightly less puzzling, actually.
<infinity> Path of least resistance is probably just to bounce the machine.  I'll talk to IS.
<skaet> k
<infinity> Although, it's very much alive.
<infinity> Weird.
<infinity> I'll look into it in a sec.  Multitasking all over and haven't had coffee.
 * infinity notes that the "kernel PPA copying" section of sru-report doesn't actually point out which arches are built/building/failed, which makes it pretty dangerous, if someone just copies blindly without checking.
<ogra_> infinity, hmm, did you talk to jani before changing linux-ac100-meta ? i had the impression he didnt want the 3.1 one as default yet
<infinity> ogra_: Nope, but we've already spoken about it.  I may have been overzealous because I was trying to clean out NBS...
<ogra_> ah
<infinity> ogra_: (On the other hand, I'm not sure why one would upload a kernel if they thought it might not work...)
<ogra_> well, afaik the current 3.1 has console issues
<ogra_> not sure they are solved already
<ogra_> the new binary driver requires 3.1
<stgraber> no need to look at the new newt binary, another upload is coming with a proper version number
 * slangasek rejects it to be complete
<slangasek> ETA on the next one? :)
<stgraber> they're built, just need to wait for LP to notice ;)
<slangasek> cool
<stgraber> slangasek: ^
<slangasek> those are still ~ppa1 ;)
<stgraber> and I just uploaded the non ~ppa1 version, now that my test build in the archive succeeded :)
<slangasek> right, that's what I meant by "next one"
<slangasek> rejectzored
 * micahg hugs stgraber
<stgraber> slangasek: that's all of them ^
#ubuntu-release 2012-06-14
<cjwatson> Please to be NEWing update-manager awesomeness.
<slangasek> reviewinating
<slangasek> accepted
<stgraber> infinity: thanks
<cjwatson> jdstrand: Are you OK with the permissions change proposed in https://lists.ubuntu.com/archives/technical-board/2012-June/001312.html ?
<jdstrand> cjwatson: so iiuc, anyone in these teams can upload to their respective pocket, but they still need to be approved via LP? the situation now is what, an upload to -security is outright rejected?
<cjwatson> -security is actually somewhat special beyond this, because there's a special hardcoded thing that stops you uploading directly to -security at all rather than going via a staging PPA.
<cjwatson> But an attempt to copy a package in main to -security is I believe outright rejected right now if you aren't in -core-dev, yes.
<cjwatson> I'm sort of pretending your specialised unembargoing tools don't exist for now because ultimately I want to be able to support it all through Archive.copyPackage.
<cjwatson> This is one step.
<cjwatson> For -backports, which doesn't have any of this extra complexity - yes, right now a backporter has to be able to upload the package in general or else they get outright rejected
<jdstrand> ok, let's pretend (just for a moment, I know it's hard ;) that I don't know exactly what is changing in your commit, or all the special LP stuff. your change allows someone in these groups to upload to their pocket without being rejected from the start. your change allows that initial step to pass for later checks to be performed. is that accurate?
<cjwatson> That's correct.
<jdstrand> ok, I think the permissions changes are fine then at least for -security. I can't really comment on -backports because I wasn't part of that conversation, but based on your recap, they sound fine too
<jdstrand> cjwatson: do you need me to comment in the bug?
<cjwatson> No, that's fine, I just wanted to double-check with you before messing about with -security
<cjwatson> The LP change is being rolled out either way, since it's harmless by itself
<jdstrand> thanks. it doesn't open it up anymore afaics, so it looks good to me
<jdstrand> s/anymore/any more/
<cjwatson> It would make things a bit easier for micahg, potentially.
<cjwatson> Oh, except that he's -core-dev now.
 * cjwatson <- paying attention honest
<cjwatson> But, you know, future security team members who aren't yet -core-dev.
<jdstrand> we still have two
<jdstrand> actually 3
<cjwatson> Tyler and John?
<cjwatson> Oh wow, I didn't know Steve wasn't -core-dev yet.
<jdstrand> cjwatson: so with this change, we can use copyPackage to unembargo, then go to the LP unapproved queue to accept them?
<cjwatson> Well.
<jdstrand> cjwatson: sbeattie too, but we are desperately trying to fix that
 * jdstrand pokes sbeattie 
<jdstrand> :)
<cjwatson> In principle I'd like to say yes, but there's funny stuff around making sure stuff gets copied from the restricted librarian to the public one and I don't know if copyPackage handles that yet.
<jdstrand> I see
<jdstrand> well, it is a step any way, and I appreciate that :)
<jdstrand> we added a --copy argument to our unemgardo tool to use copyPackage, so it should be easy enough to test
<jdstrand> cjwatson: I've subscribed the team to the bug. when the change is committed, we'll have someone do a copyPackage and see how it goes
<jdstrand> err
<jdstrand> change is live
<cjwatson> Hm, I think I'd kind of like to try it out in the LP test suite (or satisfy myself that it's already there) before trying it on real data :-)
<cjwatson> I could add a permission on staging or something and you could try it there, though
<cjwatson> That'd be better than production for this
<Laney> I'm having a hard time reconciling queue admin and copying permission
<cjwatson> Do expand
<Laney> I'm not sure entirely, but it feels like the wrong model. Perhaps it's because copying to me is tied to uploading.
<cjwatson> It is a bit of a conflation.  The reason I think it makes sense is that copying stuff around within Ubuntu is a bit more of an administrative operation.
<cjwatson> Copying stuff from outside Ubuntu, I agree.
<cjwatson> (Anyway, I wasn't suggesting making uploaders be unable to copy.)
<Laney> I know, but you were suggesting making queue admins always able to copy
<cjwatson> Copying stuff from -proposed to -updates and then having to separately go to approve it just seems kind of mad.
<cjwatson> Well, that's the other bug, I guess.
<Laney> yes, so I'd like bug #1006871 fixed for that
<ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Low,Triaged] https://launchpad.net/bugs/1006871
<Laney> and then the SRU team given permissions to manage their queues
<Laney> and also to upload to them, which is what I was suggesting
<cjwatson> Most of my motivation for queue admins always being able to copy is for automating auto-syncs.
<Laney> I guess I don't see the need for this conflation
<Laney> the auto-sync account could just be made a core-dev
<cjwatson> It could.  It makes me jittery for some reason.
<Laney> perhaps that is too much permission though
<cjwatson> I know that the package-import account is a core-dev.
<Laney> wait.
<cjwatson> Slightly less permission would be to give it a separate blanket upload ArchivePermission.
<Laney> yes, that
<cjwatson> That way it at least wouldn't be able to write to core-dev branches, say.
<Laney> to the release pocket in the dev release
<Laney> can we express that?
<cjwatson> But it's still a root-everything account :-)
<cjwatson> Can't do pocket & other stuff, but it can be series-specific, yes.
<cjwatson> Would be a bit of a hassle to have to roll it over every series, but nothing too horrible.
<cjwatson> Oh, wait.  Better check my assumptionss.
<cjwatson> Bah.  Packageset permissions are per-series, but component permissions aren't.
<Laney> hmm
<cjwatson> Another way I think about it is:
<cjwatson>  * you can fairly easily upload stuff to a component you aren't supposed to have access to by accident
<cjwatson>  * working around it by uploading to a PPA and then copying, to me, implies more chance of malice
<cjwatson> So they're sort of technically equivalent in security terms but the safety-catch nature is different
<cjwatson> It's not a massively high priority for me though: fully automating auto-syncs would be nice, but we've got along for eight years without, so meh.
<Laney> I see the potential for abuse, but if we're just talking about the one bot account for auto-syncing then I'm not really very concerned. It would be easy enough to keep it fairly locked down.
<Laney> Also, I thought that one of the benefits of moving to this new API is that we /wouldn't/ need a bot account for auto-syncing?
<Laney> Archive admins just run the script on their own machine.
<cjwatson> Well, yes and no
<cjwatson> It means we *can* run it on our own machines, it means we don't have to run it as a user with direct Launchpad database access, it means we don't have to have a crazy scheme involving downloading source packages and pushing them through a special back door designed just for it, and it means it's a lot easier for us to improve our own tools
<Laney> I see you might want to cron it, in which case this would be required
<cjwatson> But it'd still be nice to be able to cron it.  I don't think that should depend on any particular archive admin, and I don't want to grant access to my Launchpad account to a cron job.
<cjwatson> Maybe just going with blanket upload AP entries would indeed be the right answer.  I'll meditate some more, I guess.
<Laney> So I'd a) Make a new ubuntu-autosync-bot user, b) Give it upload permissions to release (soon to be proposed), c) Give it queue admin to NEW, d) Add API to allow certain copying operations to bypass queues
<cjwatson> a) is done, ubuntu-archive-robot
<Laney> NEW/devel series, depending on how that goes
<cjwatson> Actually, for c), I'd prefer NEW not to be automatic
<cjwatson> We do wave through new auto-syncs fairly liberally, but I catch things that I don't want to auto-sync (and blacklist them or whatever) moderately frequently
<cjwatson> If we had auto-sync --batch cronned, I'd want to be able to catch stupidity at the NEW queue admin level
<cjwatson> Not full review or anything, just an "oh boy that package name looks kind of familiar" sort of thing
<Laney> so you wouldn't even need it to be able to queue admin â that's even simpler, surely?
<cjwatson> Perhaps I should remove it from ~ubuntu-archive.
<cjwatson> I'm not sure it'll never want queue admin for something else in future.
<cjwatson> Not for auto-syncs, but there's other stuff I want to cron.
<cjwatson> copy-report is the most obvious one.
<cjwatson> (Copy stuff from -security to -updates, without going through unapproved.)
<cjwatson> But I suppose it could have queue admin AP on -updates.
<Laney> maybe you'd want multiple users then, for protection
<cjwatson> Possibly.
<cjwatson> I don't think any changes set anything much in stone.
<hggdh> skaet: shouldn't bug 949641 be re-milestoned?
<ubot2> Launchpad bug 949641 in fglrx-installer "Installing both fglrx and fglrx-updates results in: error exit status 1 -"/etc/init.d/atieventsd exists during rc.d purge"" [Critical,Triaged] https://launchpad.net/bugs/949641
<skaet> hggdh,  yes,  done now.
 * skaet will dig into how that one got overlooked later today.
<hggdh> skaet: I could have done it, but I would rather ask
<Laney> ScottK: I think you were referring to bug #648611 (as was discussed elsewhere in the thread, and in here)
<ubot2> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
<ScottK> Laney: That's the one.
<Laney> But the description is weird, and it doesn't talk about distroseries granularity which you requested
<cjwatson> I don't understand why that description wants per-upload-status granularity.  Personally I'd like to avoid that.
<cjwatson> Per-series is a bit nasty but I can understand it and it's not that far out of line with packagesets.
<cjwatson> Although I suspect it would require a DB constraint change :-(
<ScottK> cjwatson: I think it's reasonable to say that only ~ubuntu-archive can process New.
<cjwatson> Is the converse also reasonable, though?
<Laney> you probably want backporters to be able to do NEW backports
<ScottK> True.
<ScottK> cjwatson: I think it is.  Since I'm not (yet) in ubuntu-sru, I've go no business accepting stuff to precise-proposed except to work around the current issues where I may do it on behalf of an ~ubuntu-sru member that can't.
<cjwatson> Hm, maybe I was unclear
<cjwatson> I mean, I agree that it's reasonable to say that only ~ubuntu-archive can process New; but would it also be reasonable to say that anyone with queue admin privileges to some intersection of pocket/series/whatever can process New as well as Unapproved?
<cjwatson> I care because the latter is, I think, rather easier to implement.
<cjwatson> I could probably do the former if I must.
<cjwatson> Anyhow, this is all about future work on queue admin privileges, not about the upload changes that just landed, so let me go and add the latter permissions now
<Laney> Personally I think pocket & series would be fine.
<cjwatson> Looks like I was wrong that pocket & series would require a DB constraint change.
<cjwatson> ALTER TABLE ArchivePermission ADD CONSTRAINT one_target CHECK ((null_count(ARRAY[packageset, component, sourcepackagename, pocket]) = 3));
<cjwatson> (Bizarre way of writing "you get only one of these".)
<cjwatson>     parser.add_option("-p", "--person", dest="person", action="append")
<cjwatson>     parser.add_option("-P", "--packageset", dest="packageset", action="append")
 * cjwatson gives up on a short option for --pocket
<xnox> cjwatson: - pÌ
<xnox> we have unicode ;-)
<Laney> Ï
<ScottK> cjwatson: I don't think I understand what you mean by "some intersection of pocket/series/whatever".  Can you give an example (no rush - as you say, this is about future work)
<xnox> Laney: p-hat is visually different from -p -P
<Laney> so's rho!
<cjwatson> ScottK: Pocket plus zero or more intersected constraints.  Let's say, as an example, if we gave ~ubuntu-sru queue admin on -proposed, would it be reasonable to say that they could process NEW there (e.g. kernel ABI changes)?
<ScottK> cjwatson: Yes.  I think it is.
<cjwatson> You said the contrapositive, that it would be reasonable to say that only ~ubuntu-archive can process NEW, but you didn't say you thought the opposite was unreasonable; so I'm trying to explore that.
<ScottK> I didn't think about that case.
<cjwatson> If you see what I mean.
<ScottK> Yes.
<ScottK> Equally, I think new backports should be OK for backporters.
<cjwatson> 'cos that way I don't have to invent some way of embedding the upload status into an archive permission.
<cjwatson> Excellent.  I think we are in agreement on that part at least, then. :-)
<ScottK> Ideally though in the case of backporters it would only be new for that release, not new to the archive as they aren't supposed to do that.
<ScottK> That probably pushes things back into hard though.
<cjwatson> I see what you mean.  Hmm.
<Laney> We'd get that if it were pocket & series, though?
<cjwatson> No.
<cjwatson> There isn't sufficient distinction between new to precise-backports because it was backported from quantal and not previously in precise(-backports), and new to precise-backports because it wasn't previously in Ubuntu at all.
<cjwatson> Which I think is what ScottK means.
<Laney> I don't think NEW captures that at all.
<cjwatson> It doesn't.
<Laney> That's part of the trust that you grant when you delegate queue admin
<Laney> Maybe NEW would also be interesting if we manage to get backports pre-release off the ground
<ScottK> Sure, but I'd like to make the technical capability and the policy constrains match as closely as possible.
<ScottK> Laney: Even in that case, it would still need an archive admin review.
<ScottK> While I'm dreaming, I'd like a secondary LP login that would be the only one that has queue access.
<ScottK> Then I could log into that only when actually processing the queue.
<Laney> How so (if permissions are just pocket/series)?
<cjwatson> $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check
<cjwatson> Iain Lane (laney) cannot upload coreutils to Precise/Backports
<cjwatson> $ ./edit_acl.py -p ubuntu-backporters --pocket backports add
<cjwatson> Added:
<cjwatson> Archive Upload Rights for ubuntu-backporters: archive 'primary', pocket 'Backports'
<cjwatson> $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check
<cjwatson> Iain Lane (laney) can upload coreutils to Precise/Backports
<bdmurray> SpamapS: how far through the precise queue did you get?
 * Laney gets to it
<cjwatson> You were a handy example from sorted(set(p.name for p in lp.people['ubuntu-backporters'].members) - set(p.name for p in lp.people['ubuntu-core-dev'].members)) :-)
<cjwatson> $ ./edit_acl.py -p ubuntu-security --pocket security add
<cjwatson> Added:
<cjwatson> Archive Upload Rights for ubuntu-security: archive 'primary', pocket 'Security'
<Laney> ah, there's a handy main backport ready
<cjwatson> I've committed the corresponding edit_acl.py changes now.
<xnox> cjwatson: Laney is up with a core-dev application though =)))))
<cjwatson> There are two other examples ;-)
 * ScottK wonders if Laney's core-dev application should be rejected on the grounds of it being very late.
<cjwatson> DENIED: slacker
<Laney> I didn't want to deny core-devs the warm internal glow that sponsorship provides :-)
<Laney> cjwatson: ^ it works!
<ScottK> Where does the sync blacklist live these days?
<cjwatson> ScottK: lp:~ubuntu-archive/+junk/sync-blacklist
<cjwatson> Laney: yay
<ScottK> Thanks.
<cjwatson> (Now where's that review-backport tool?)
<Laney> /part
<cjwatson> haha
<ScottK> cjwatson: If an entry is obsolete, can I just remove it  and push (blacklist)?
<cjwatson> Sure
<ScottK> Thanks.
<Riddell> cjwatson: are you planning on moving kubuntu bits to universe any time soon?
<cjwatson> Oh, er, yeah could do, let me get a BIG coffee
<phillw> hi good people, has http://pad.ubuntu.com/ubuntu-release been retired? I see respins, but no reasons for them, thanks.
<Riddell> phillw: there's no current release candidates going on
<Riddell> cjwatson: if you happen to be in a channel with sabdfl can you remind him there's a kubuntu meeting in #kubuntu-devel in 5 mins?
<cjwatson> You're seeing routine daily builds, not manual respins
<phillw> Riddell: thanks, is there any 'pulling together' what is in each respin being logged?
<cjwatson> Riddell: He's not on e.g. #canonical
<phillw> thanks, cjwatson et all :)
<Riddell> ah well
<cjwatson> phillw: These are totally automatic builds.
<phillw> thanks :)
<cjwatson> phillw: So no.  You can use things like the quantal-changes mailing list to see all changes in the archive.
<phillw> I don't think I have the skills to decode that :)
<cjwatson> Nor does the cron job running the daily builds. ;-)
<phillw> lol
<phillw> tochee :D
<cjwatson> Riddell: Do either of us need to follow up to https://lists.ubuntu.com/archives/kubuntu-devel/2012-June/006135.html
<cjwatson> ?
<Riddell> cjwatson: I've not thought it much but my feeling is if someone want to upload a package they should check their changes get into the relevent packaging branch
<Riddell> and anyone who doesn't isn't doing the task properly
<Riddell> ~kubuntu-
<Riddell> packagers
<Riddell> is easy to add people to
<Riddell> no approvals needed
<cjwatson> So you're happy with a sort of post-merge review on any changes that turn up in Kubuntu
<cjwatson> TBH the problem probably existed occasionally in main too
<Riddell> cjwatson: happy enough
<Riddell> generally I'd prefer they discuss it with the kubuntu developers if practical
<cjwatson> Right, I mean as a recovery-from-error process rather than advertised process IYSWIM
<cjwatson> I just want to make sure that I'm not going to do this and then have some set of people shout at me that I need to move gigabytes of data *back* :-)
<Riddell> cjwatson: yeah it's fine
<cjwatson> ('cos mirrors are probably going to notice this ...)
 * infinity notes it's yet another "branches out of sync with archive" complaint, and wishes people would stop pretending branches are authoritative.
<cjwatson> Mind you I suppose it won't be anywhere near, say, a release
<SpamapS> bdmurray: I got to June 9
<Laney> Why don't you just add motu to the team with the branches?
<infinity> Laney: I'm sure they could, that doesn't mean the branches will be up to date. :P
<Laney> It makes it slightly more likely
 * infinity goes to push his change to the calligra branch, so it doesn't get dropped...
<skaet> phillw,  have gone in and cleaned it up.  ;)  thanks for flagging
<Laney> and quite a lot less irritating for someone who tries to do things the right way
<infinity> Laney: I disagree that the "right way" is to create more busy work for someone doing a drive-by fix, but hey. ;)
<SpamapS> bdmurray: its probably worth re-checking the ones we've nagged for testcase/regression potential quite regularly. I'm wondering if we should start rejecting things quicker.. like.. 1 week after the nag
<Laney> One team's right way â¦ :P
<infinity> As long as source packages are authoritative (and they currently are), it will continue to irk me when people don't check the current state of the archive before uploading.
<bdmurray> SpamapS: I found myself looking at ones you'd just commented on yesterday though
<micahg> infinity: even with authoritative source packages we seem to get collisions (see ubuntu-meta earlier this morning)
<SpamapS> bdmurray: shouldn't be too hard to just move to the next... but yeah
<SpamapS> bdmurray: need some way to communicate "skip these"
<bdmurray> SpamapS: well its the 20 tabs open that need to get closed which takes some time
<infinity> micahg: That's the same error, really.  Not checking a debdiff against the previous version before uploading.
<infinity> micahg: Though, in the meta case, just hilarious, not damaging.
<micahg> heh
<infinity> micahg: The problem with people (mistakenly) considering branches authoritative is that they think "bzr diff" is enough to see what changes they've introduced.
<micahg> Riddell: IMHO, it's worth a mail when the switch happens to remind people to check the Vcs-* fields when uploading
<infinity> micahg: Which isn't even true if they're not reverting something someone else did. :P
<cjwatson> bdmurray: I think your recent sru-accept.py change is a much better fix to my "Advertise pending-sru.html in sru-accept comment?" work item than the work item itself proposes.  Can I reassign that WI to you and mark it done?
<micahg> infinity: heh, yeah, I've given up on trusting bzr diff on random branches
<SpamapS> bdmurray: I isolate my SRU work in a single browser window for that reason. :-P
<bdmurray> cjwatson: sure, didn't know about that
<cjwatson> (https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process)
<cjwatson> all yours
<cjwatson> thanks :)
<infinity> micahg: I sort of treat them as two entirely different entities.  bzr diff, of course, has its place when I'm actually working in bzr (as I do for some codebases), but I *always* debdiff my final upload against the previous version to cruft-and-reversion-check.
<bdmurray> cjwatson: do you have any plans for that last work item?
<cjwatson> bdmurray: sorry, which one?
<bdmurray> [tb] patch sru-accept to link to .debs for -proposed in comment or the page of the binary package build in launchpad which has all the deb links from the librarian (as the security team does): TODO
<cjwatson> oh, the one we hopefully assigned to tb
<cjwatson> he suggested it so we voluntold him
<cjwatson> I somehow doubt he'll have time to do it
<cjwatson> no plans myself though it doesn't sound horribly difficult
<bdmurray> right, I might just do it then
<infinity> FWIW, I much prefer linking to the build(s) rather than the .debs.
<cjwatson> agreed
<cjwatson> possibly marginally easier anyway
<micahg> I think that was the outcome of the session anyways
<cjwatson> though you'll need one per arch of course
<infinity> micahg: Yeah, the work item proposes both options.
<cjwatson> bdmurray: be my guest
<infinity> micahg: So, I thought I'd voice an opinion. ;)
<micahg> infinity: just affirming support for you based on historical precedent :)
<infinity> I assume the security team has cargo-cultable code here.
<bdmurray> infinity: sssh, don't give away how I will do it
<infinity> ;)
<infinity> bdmurray: When you're done with that, would you like some of my work items too?
<cjwatson> I've got more.
<bdmurray> infinity: I'll get back to you on that ;-)
<infinity> cjwatson: Oh, if you're resurrecting dsync-flist use in the publisher, remind me to resurrect my local project to actually make the code build on a modern OS and get it into the archive.
<infinity> cjwatson: Cause, one of these days, elmo's hand-built binary from 1987 will explode. :P
<cjwatson> It's not hopelessly slow if it's being run, like, ever.
<cjwatson> It took two and a half hours to run generate on a year's worth of changes.
<cjwatson> But a no-op run takes 9s.
<infinity> Yeah, it's pretty quick when it's being run.
<cjwatson> Do you think we could make it emit ls-lR somehow?
<infinity> That said, it SHOULD be rolled into apt-ftparchive, IMO, and it could be really fast.
<cjwatson> Seems like it should have most of the data.
<cjwatson> I'd be totally happy to keep that if it were blindingly fast.
<cjwatson> I mean, it can lie about some of the fields or something.
<infinity> Hrm, yeah.  If we could make ls-lR not suck, we could keep it.
 * xnox adam and colin are discussing archive's black magic again
<cjwatson> It can't be that much harder than md5sums.
<cjwatson> That's what we do.
<infinity> And drink.
<cjwatson> And drink.
<infinity> But it's a bit early for that.
<cjwatson> Sun's well over the yard-arm here.
<infinity> cjwatson: Let me dig up the actual dsync source.  It's on some laptop somewhere here.
<cjwatson> I've got it if you don't.
<cjwatson> -rw-r--r--   1 cjwatson cjwatson 131189 Oct 26  2006 dsync_0.0-0.1.tar.gz
<cjwatson> fresh
<elmo> infinity: it's not hand built; I have sources!
<elmo> there, see
<cjwatson> (I suspect that's the time I downloaded it, though
<cjwatson> )
<infinity> elmo: Sources that don't build anymore. ;)
<cjwatson> drwxr-xr-x   9 cjwatson cjwatson   4096 May 16  2005 dsync-0.0
<elmo> these filthy accusations shall not stand
<infinity> elmo: Hahaha.
<cjwatson> dsync (0.0-0.1) experimental; urgency=low
<cjwatson>   * Make it build using g++-3.3.
<cjwatson>  -- Kurt Roeckx <kurt@roeckx.be>  Mon, 16 May 2005 16:04:58 +0200
<cjwatson> That must be good enough, right?
<elmo> WFM
<infinity> Close enough.
 * xnox adores cjwatson idioms http://en.wikipedia.org/wiki/Yard_(sailing)#.22Sun_over_the_yardarm.22
 * micahg thought we added gcc 3.3 back to the archive
<cjwatson> Oh, that's all right then. :-P
<cjwatson> It's only libstdc++5, not the compilers.
<cjwatson> Anyone want to comment on anything in http://paste.ubuntu.com/1041070/ ?
<cjwatson> That's what moving Kubuntu to universe would change.
 * micahg wonders if the libjpeg stuff is worth seeding or not
 * micahg also wonders why a bunch of -dbg packages are now showing up
<cjwatson> -progs?  Dunno.  That's only a binary movement so easy enough to revert.
<cjwatson> Probably because of different Extra-{Ex,In}cludes between the Ubuntu and Kubuntu supported seeds.
<cjwatson> Some of those are probably a mite spurious.
 * micahg guesses xscreensaver isn't worth keeping in main either
<cjwatson> bzr-doc is odd, what's up there
<ScottK> Kubuntu has a development seed that is 'overbroad'.
<ScottK> Some of that stuff comes from there.
<cjwatson> Right, but bzr should be seeded in Ubuntu and its Extra-Includes should grab bzr-doc.
<micahg> libzip is another one that looks like it might be worth keeping
<xnox> cjwatson: speech-dispatcher-festival is interesting cause I thought orca works better with that
<cjwatson> Mostly I'd rather people investigate what's going on and fix seeds rather than telling me :-)
 * micahg isn't sure if these things are actually worthwhile or would do the commits
<cjwatson> Ah, some of this is seed madness
<cjwatson> supported fails to inherit from server-ship
 * cjwatson goes to try to rectify
<xnox> myspell going away, we still have something else in main, right? like hunspell?
 * xnox doesn't now
<xnox> since emacs is in main please keep auctex
 * xnox the world will be a better place with more emacs stuff
<cjwatson> It doesn't vanish because it's in universe
<micahg> xnox: yes, although I thought some dictionaries didn't have hunspeel equivalents, maybe we don't have those languages?
<cjwatson> I don't think we can necessarily sanely keep every add-on for everything
<cjwatson> Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different
<xnox> micahg: still seems strange, why so *little* of them moved. I'm suspicious.
<cjwatson> Should be possible to investigate this by comparing germinate output on people.c.c
<micahg> xnox: right, most likely, we'll need to seed those I think (myspell-he is one example)
 * micahg fixes
<micahg> hrm, not sure where though
<micahg> cjwatson: for any languages we don't ship on the live image, should I add the dictionary to the supported seed?
<cjwatson> Are they regexable?  You could put them next to the /^hunspell-[^-]*$/ regex entry.
<cjwatson> Which is in supported, yes.
<micahg> cjwatson: well, I think we just want the myspell ones when we don't have hunspell equivalents, right (or they are the hunspell equivalents)
<cjwatson> micahg: Well, feel free to seed them individually there
<micahg> cjwatson: thanks
<cjwatson> infinity: dsync-flist md5sums takes 19s or thereabouts
<cjwatson> Very tempting to just shove this back into ubuntu-archive-publishing by fiat.
<infinity> cjwatson: Kay.  I do wonder if this could be even faster if it could be taught to re-use apt-ftparchive's cache.
<infinity> cjwatson: (Given that dsync is a mess of cargo-culted code from apt anyway...)
<cjwatson> Except I have enough to do today.  But something like http://paste.ubuntu.com/1041084/
<cjwatson> (Which roughly corresponds to the last version of that code before it was removed from Launchpad.)
<infinity> I also wonder how that can be so fast, when ls-lR is doing less, and takes much longer...
<cjwatson> It uses Packages and Sources, right?
<cjwatson> Hmm.  No.
<infinity> Neither one does.
<cjwatson> I guess it can use getdents and doesn't have to stat everything individually if it's in its cache.
<infinity> dsync just walks the tree you give it.  How that's faster than a recursive ls is a mystery. :P
 * cjwatson straces
<cjwatson> ls -lR has to stat everything.
<infinity> Fair point.
<infinity> Makes a good argument for figuring out how to make dsync generate a fake ls-lR, if we want to keep it.
<infinity> It should have all the appropriate info (except permissions, but who cares?) in its cache.
<cjwatson> It actually does seem to do lots of lstats.
<cjwatson> Not sure how it's so fast.  Maybe I got lucky with caching and it wouldn't be fast if run after a publisher run?
<infinity> Possibly.
<cjwatson> It's bloody slow under strace. :-)
<infinity> gdb the strace process, that'll speed it right up.
<infinity> And then valgrind the gdb.
 * cjwatson wonders if dsync is ctrl-c safe, and isn't sure he wants to experiment
<xnox> cjwatson: heartbeat move to universe is a bad idea. Expect to break a lot of servers. Ideally this should be under server's team control.
<xnox> as many servers use only main.
<cjwatson> xnox: Then it should be in a server seed somewhere.
<xnox> and it's the only way to do high-availability.
<xnox> hmmm how do I request / do that?
<cjwatson> The point of the seed system is that I don't have to work it all out myself. :-)
 * xnox is off to wiki about archive development
<cjwatson> MP into lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal
<cjwatson> heartbeat isn't explicitly seeded anywhere right now
<xnox> hmmm so how come it ended up in main?
<xnox> just because of kubuntu?
<cjwatson> build-dep of pacemaker
<xnox> yeah, is pacemaker moving as well?!
<cjwatson> Which is in Ubuntu, so actually I'm pretty sure this is due to the problem I fixed above
<cjwatson> So no need for an MP
<cjwatson> You probably might as well stop investigating until I refresh the list
<cjwatson> It's wrong
<cjwatson> 17:47 <cjwatson> Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different
<xnox> ok.
 * xnox can't find neither pacemaker nor heartbeat in the seeds
<cjwatson> Build-dep of ocfs2-tools.
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/heartbeat
<cjwatson> (Which unfortunately doesn't say why ocfs2-tools is there; minor germinate bug I guess - but it's in the server-ship seed.)
<cjwatson> But, you know, if it's that vital, maybe it ought to be explicit.
<xnox> well I wonder why ocfs2-tools got added, cause pacemaker by itself should be explicit just in case IMHO.
<xnox> pacemaker/hearbeat stuff has more usage than ocfs2-tools thingy
<xnox> hmm seems ok
<xnox> it looks like the server seed is explicit under cluster sections of everything you ever need to run any time of cluster stuff
 * xnox doing merge proposal just in case
 * xnox done
<cjwatson> I'm sure that dsync-flist could be very much faster by assuming that files in the pool never change contents once created.
<cjwatson> Which it doesn't seem to, so I've no idea how it was so fast earlier.
<cjwatson> In fact it seems to predate package pools.
<infinity> Well, it's format-agnostic.
<cjwatson> Yeah, but what do I care.
<infinity> I use it on random collections of mp3s and movies. :P
<cjwatson> Freak
<cjwatson> So maybe it would be faster to shove it in apt-ftparchive.  It'd have to be run later rather than as part of the main a-f run though.
<cjwatson> And that would kind of suck if the LP team ever finished getting rid of a-f.
<infinity> I'm unconvinced that NMAF will actually work on large archives, personally.
<cjwatson> And it would have to deal with the random files on the mirror.
<infinity> It drops the local cache in favour of assuming the DB is insanely fast.
<cjwatson> The general NMAF approach absolutely blew on dogfood, but then dogfood is horrible
<cjwatson> And it's possible my queries were awful too
<infinity> The a-f cache is a godsend on any sufficiently large archive.
<cjwatson> (I'd been hoping to do germinate-from-db, but it seemed to be impractical)
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/germinate-from-db
<cjwatson> I don't think I knew about bulk loading then, so that would make a fairly enormous difference.
<micahg> ok, dictionaries fixed
<micahg> s/fixed/added to supported/
<skaet> infinity,  ogra_ - any clue yet why we still don't have arm desktop dailies?
<infinity> skaet: Oh, I pinged IS about doing some remote-hands debugging of celbalrai, and I think I must have cause webops on a shift change or something.
<infinity> skaet: And then got busy with something else. :P
<infinity> skaet: I'll poke harder.
<skaet> thanks infinity
<ScottK> infinity: You caused a shift change?
<infinity> ScottK: caught.  My fingers and brain aren't agreeing.
<infinity> The classic case of typing "cau" and having your fingers go "HOLY CRAP, I KNOW THAT WORD" and filling in the rest with nonsense.
<ScottK> Right, but it was funnier my way.
<cjwatson> http://paste.ubuntu.com/1041164/ - better list of movements to universe due to Kubuntu
<ScottK> Some of the binary only demotions seem odd, but it's definitely better.
<cjwatson> supported-network-client (at least) still isn't inherited by supported.
<cjwatson> Which causes e.g. irssi-dev.
 * infinity wonders why lbdb was seeded in Kubuntu...
<infinity> Or was that also due to the above?
<ScottK> No, it's on the DVD.
<cjwatson> I wonder why supported-common fell out.  That was what it was for.
<ScottK> Probably the ambitious Kubuntu development seed.
<ScottK> No, it's directly seeded in the Kubuntu DVD seed.  No idea why.
<cjwatson> Maybe dates from the original Ubuntu supported seed.
<ScottK> That or the fact that Riddell is known to use Mutt.
<xnox> This move to universe boggles me:
<xnox> + o exim4-daemon-heavy-dbg exim4-daemon-light-dbg exim4-dbg exim4-dev eximon4{exim4}
<cjwatson> Same cause, missing supported-common in supported's inheritance list.
<cjwatson> Will be fixed in the next list.
<cjwatson> ScottK: r89 in breezy, so probably just got blindly merged.
<xnox> Moving this to universe is strange:
<xnox> + o nagios3-dbg                                                       {nagios3}
<cjwatson> xnox: Same cause.
<xnox> not sure about:
<xnox> + o libreiser4-dev                                               {reiser4progs}
<infinity> xnox: Might be worth giving up on reviewing the list until there's a new one. :P
<bdmurray> our criteria regarding test case for SRU says 'These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.
<cjwatson> xnox: Same cause.
<bdmurray> with the possibility of uploader verification is that still the case?
 * ScottK would think so.
<micahg> bdmurray: as I recall from the session, yes, as it helps crystalize the issue in the mind of the person doing the SRU
<xnox> Also concerned about all the speech-dispatcher and festival stuff, it basically will make ubuntu mute
<infinity> bdmurray: I think that's a fair statement still for test cases, with an addition that "sometimes, this is very difficult or, indeed, next to impossible to satisfy, so a test-case that can be understood by the uploader or another person familiar with the package is acceptable if the verification will also be done by same".
<ScottK> If you can't write it down, then you haven't thought it through.
<infinity> ScottK: There are some test cases that I can perfectly reasonably write down, but someone "unfamiliar with the package" will not realistically be able to reproduce.
<bdmurray> here's an example https://bugs.launchpad.net/nova/+bug/968843/comments/6
<ubot2> Ubuntu bug 968843 in nova "[SRU] connection leak in rpc connection pool" [Undecided,In progress]
<infinity> (Or, not without hours/days of learning and setup time)
 * xnox prepares e2fsprogs testcase: take a block device larger than 16TB and run fsck against it..... then do this.....
<bdmurray> I've no idea where to set small pool size
<ScottK> infinity: True.
<bdmurray> nor how to cause an rpc response timeout
<bdmurray> So I'd consider that insufficient
<cjwatson> xnox: Er, that clearly can't be true since that's stuff that isn't in main right now.
<cjwatson> xnox: Can we please tone down the hyperbole about how awful everything is going to be? :-)
<infinity> bdmurray: That would one could, indeed, be better, but I'd be just as happy with that test case and a commitment that it will be tested by someone who understands it.
<infinity> bdmurray: What I don't want is crappy (or no) testcases and an assumption that "Someone Else" will verify it.
<xnox> cjwatson: your diff starts with no heading. What's the first heading/diff lines correspond to?
<cjwatson> festival is genuinely unseeded in Ubuntu right now (as opposed to Kubuntu, where it was recently depended on by something), and not in main.
<bdmurray> infinity: so stuff like "Test Case â¦ None" would concern you?
<cjwatson> xnox: it's against http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<xnox> cjwatson: ok.
<infinity> bdmurray: s/That would one could/Than one could/ ... No idea what's with my brain->finger interconnect today.
<cjwatson> The first is "Source and binary movements to main"
<xnox> cjwatson: makes sence =)
 * xnox stay calm and carry on
<cjwatson> I can't regenerate a diff awfully quickly because this relies on the archive's germinate run.
<infinity> bdmurray: No test case at all concerns me unless the "test case" is itself the bug (ie: "bug: package fails to ship copyright file, fix: patch that ships copyright file", in that case, "testcase: look at your filesystem" is pointless)
<cjwatson> Which I can't really do while the publisher's running.
<infinity> bdmurray: But quality of testcases is entirely dependant on who the tester(s) will be.  I just want to know that testcase and test audience seem to be a matched set. :P
<infinity> bdmurray: (I certainly have some glibc SRUs coming up where writing "idiot-proof" testcases will be a phenomenal waste of time)
 * micahg wasn't under the impression they needed to be idiot proof, just clear enough that someone not intricately involved could decipher
<infinity> micahg: The problem is how one draws lines around what defines "not familiar with the package".
<infinity> micahg: And a testcase that boils down to having someone just examine output of some commands doesn't mean they're testing that you've fixed the bug, they're testing that you've written the testcase to match the output. ;)
<infinity> micahg: (As in, I'd argue that there are bugs where the tester has to understand the problem, period)
<ScottK> Fundamentally, the SRU rules are the standard case.  They aren't a suicide pact.  I think the SRU team can use some judgment about what's appropriate on a case by case basis.
<infinity> ScottK: Ed Zachary.
<ScottK> ?
<infinity> ScottK: Sorry.  More formally, "I agree".
 * infinity does enjoy that when he uses "Ed Zachary" in online conversation and people don't get it, the first hit on Google is less than flattering.
<ScottK> Yes.  Yes it is (first hit on IxQuick anyway)
<cjwatson> ooh ooh ooh
 * cjwatson consigns type-handling to the flames^W^Wuniverse
<cjwatson> Now that gdb's been fixed
<cjwatson> Is reverse-depends giving 403 for anyone else?
<cjwatson> Oh sod it, it's quitting time.  /me -> pub
<hggdh> I just tried a 'do-release-upgrade -d' to quantal -- it fails on 404s from extras.ubuntu.com. Is this expected?
<stgraber> no
<stgraber> I thought I fixed that one...
<stgraber> oh, and I did :) though it looks like the mirroring script IS is running doesn't sync quantal...
<stgraber> hggdh: fixed
<hggdh> stgraber: you are my hero :-)
<micahg> did someone do a giveback of FTBFS in stable releases again?
 * micahg is just wondering why chromium in oneiric is building
<infinity> micahg: Hrm?
<infinity> micahg: Are you sure it wasn't something that failed in one pocket, then got copied?  Or similar?
<micahg> infinity: hrm, idk, I thought it was already in -updates and -security
<infinity> Dunno.  I never give back things in non-development releases except explicitly.
<infinity> And if anyone else does, I'm not aware of it.  And I wish they'd stop. :P
 * micahg had some stuff rebuilt last night when he copied some packages to another PPA as a backup
<micahg> but that only used 1hr of useful build time
<herton> hi, can some AA copy linux-ti-omap4: 3.0.0-1211.23 to -updates (bug 1005455)?
<ubot2> Launchpad bug 1005455 in linux-ti-omap4 "linux-ti-omap4: 3.0.0-1211.23 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1005455
#ubuntu-release 2012-06-15
 * infinity takes the ti-omap4/oneiric SRU.
<micahg> infinity: can you take care of these? ^^
<infinity> Maaaaybe.
<infinity> Do I want to know how we managed a security hole in unity-2d?
<micahg> infinity: not a security hole
 * infinity points at the pocket.
<micahg> bug 1010466
<ubot2> Launchpad bug 1010466 in unity-2d "dropdown boxes on sites stop working" [Medium,In progress] https://launchpad.net/bugs/1010466
<micahg> infinity: basically unity-2d sets the window timestamp to seconds from epoch
<micahg> causing a noticeable bad behaviour with the new version of firefox
<infinity> That's a pretty questionable use of the security pocket, but meh.
<micahg> infinity: well, for everything except precise, I think it was a regression exposed by a security update
<micahg> precise might have had the issue at release (which technically means it should be SRU'd), which I can do if you really want
<infinity> Nah.
 * micahg will publish a USN for it
<infinity> I'm going to close my eyes and scream "la la la", after I review the bug and the code.
<micahg> infinity: and I've got the LP command to copy to quantal as soon as it's accepted as well (or do I have to wait for it to be published)
<infinity> Please don't copy to quantal.
<micahg> infinity: it FTBFS and I'm not fixing it, they've got a new version coming soon (and quantal currently has this version)
<infinity> It's FTBFS?
<infinity> gcc-4.7?
<micahg> well, if I would upload it would be :)
<infinity> Meh.  Whatever.  Fine, copy it. :P
<ScottK> skaet: You'll want to have Bug #1013171 on your radar I believe.
<ubot2> Launchpad bug 1013171 in xdiagnose "Many package hooks not ported to python3" [Critical,Confirmed] https://launchpad.net/bugs/1013171
<micahg> infinity: yeah, gcc-4.7, they've got all of it fixed in trunk I thnk
<ScottK> Many is 10 that we know of.
<micahg> ah, I do have to wait for them to be published before copying to quantal
<infinity> ScottK: Oh, fun.  I don't think this even occurred to us during the sprint.
<micahg> was brought up in -devel a few hours ago
<ScottK> It's currently blocking upgrades.
<infinity> ScottK: Shouldn't be hard to scrub the Contents file for hooks by location, and then 2to3 them.
<ScottK> Yep.
<ScottK> Someone should do that.  I'm about to go to sleep.
<infinity> Yeah, I'm heading out the door to pretend to have a "life" for a couple of hours before I sleep.
<infinity> But Europe will be awake soon enough.  And Europe love python.
<infinity> s/love/loves/
<ScottK> infinity: pitti's already confessed to being awake on another channel.
<ScottK> Good night.
<slangasek> what package hooks are these?  all apport hooks?
<slangasek> would rolling apport back to python2 fix this?
<slangasek> hmm, I think it would
<micahg> didrocks: are you planning a unity-2d upload to quantal soon, or should I copy the precise version over?
<didrocks> micahg: copy the precise version over for now
<didrocks> micahg: normally we will release a new version next week, but we never know :)
<micahg> didrocks: ok
<didrocks> thanks micahg
 * micahg is still waiting for the binaries to publish
 * micahg wonders why LP is saying the precise binaries aren't published when they're on security.ubuntu.com
<micahg> ah, the -updates copy :)
<micahg> finally, copied
<cjwatson> http://paste.ubuntu.com/1042093/ - looking a bit more sensible now
<cjwatson> still a fair number of binary-only movements to universe, but I'm not necessarily going to do those all anyway - more concerned about the source movements
 * xnox can't spot anything
<cjwatson> phew :-)
<cjwatson> (I do appreciate the checks ...)
<debfx> cjwatson: demoting qca2-plugin-ossl while keeping qca2 in main seems wrong to me (libqca2 is mostly useless without a backend)
<cjwatson> libqca2 is only there as a build-dep.
<cjwatson> But I can probably Extra-Include it or something, so that it's kept in main if and only if libqca2 is in main.
<cjwatson> Oh, that won't work, it's a separate source.
<cjwatson> libqca2 is clearly useful for the use it's being put to in main (being a build-dep).
<cjwatson> Otherwise whatever build-deps on it would build-dep on libqca2-plugin-ossl too.
<cjwatson> So I'm not sure I agree with your premise :-)
<debfx> libplasma3 depends on libqca2 and seems to stay in main
<cjwatson> apport Build-Depends: python3-pykde4 -> kde-runtime -> libkactivities6 -> libkactivities-bin -> libplasma3
<cjwatson> It's all build-dep chain stuff
<debfx> ok
<cjwatson> Riddell: Sorry for the delays in sorting out Kubuntu -> universe.  I made a number of seed changes this morning to get some things that aren't really Kubuntu-related off the list, but unfortunately I've run into a glitch in Launchpad deployment that's meant I'm not getting up-to-date germinate output.  That's being fixed.
<Riddell> thanks for that cjwatson
<tseliot> hi, can anybody reject my upload of cedarview-drm-drivers, please?
<tseliot> automatically rejected. Great!
<cjwatson> http://paste.ubuntu.com/1042480/ - latest version.  I'm going to start in on this soon.  I seeded libenchant-voikko and tmispell-voikko, since they shouldn't be on that list.
 * cjwatson moves python3-germinate to main so that stuff like livecd-rootfs is installable again, whoops
<cjwatson> And icedtea shouldn't be in that list.
<cjwatson> http://paste.ubuntu.com/1042500/ - last call
<cjwatson> (Sorry, not wrapped)
<cjwatson> I'll wait until after the next publisher run starts (7 mins) to maximise the chances of this completing within a single publisher run.
<cjwatson> Here we go.
<cjwatson> Riddell: Done.  That ran more quickly than I expected.
<Riddell> whee
<Riddell> cjwatson: could you e-mail a list of packages demoted to kubuntu-devel@  then we'll be able to work out what is still in main
<Riddell> ?
<cjwatson> OK
<Daviey> cjwatson / skaet_ : bug 1002248 assigned
<ubot2> Launchpad bug 1002248 in mythbuntu-meta "[quantal] xfce4-utils is deprecated in 4.10" [Undecided,New] https://launchpad.net/bugs/1002248
<cjwatson> Thanks
<skaet_> thanks
<scott-work> bug 1002250
<ubot2> Launchpad bug 1002250 in ubuntustudio-meta "[quantal] xfce4-utils is deprecated in 4.10" [Undecided,Confirmed] https://launchpad.net/bugs/1002250
<scott-work> Daviey: cjwatson : mr prouit has some nice instructions for resolving the xfce4-utils deprecation ^^^
<infinity> cjwatson: Ahh, I see the kubuntu->!main thing is underway.  Did you plan to do all the overrides too, or still going through it with a fine-toothed comb?
<Daviey> scott-work: yeah, most helpful.. I spoke to Thomas before assigning it to him, he seems happy to drive it.
<skaet_> have gone ahead and dropped ubuntu DVD from the daily crontab based on seb128's +1 in the meeting.
<skaet_> Riddell,  I didn't spot Kubuntu's DVD there,  so someone must have dropped it already.
<skaet_> stgraber,  I've gone in and removed Ubuntu DVD and Kubuntu DVD from the iso tracker daily images.
<stgraber> skaet_: ok, the products should probably be completely disabled too, unless they're included in the point releases
<skaet_> stgraber,  they *may* be in the point releases,  wasn't clear.   Riddell and seb128 have actions on what to do about them for 12.04.1 ;)
<Riddell> still pondering that but I'm currently not wanting to do dvds in 12.04.1
<skaet_> Riddell,  let us know the final decision on ubuntu-release mail list.   If you don't want to do them for 12.04.1 - will they be needed at any time,  or can they be dropped from LTS supported manifest?
<bjf> infinity, i have a few kernel packages in various upload queues ... just saying :-)
<infinity> bjf: That was delightfully vague. ;)
<infinity> bjf: But yeah, I see all the stuff queuebot spewed up there.
<bjf> infinity: could you New them please?
<infinity> bjf: I'll poke shortly.
<bjf> infinity: thanks!
<cjwatson> infinity: I actually did them all around the time c-m first listed them.  It just took the publisher and c-m some time to catch up with the giant pile of publication records.
<cjwatson> ('cos I worked out the list in advance of the production c-m run)
<cjwatson> Hm, there are some left apparently.  Possibly there were some uploads around the same time as my massive change-override run.
<cjwatson> But I'm travelling now, so feel free to resolve those without me.
<cjwatson> I mailed the full list of intended override changes to kubuntu-devel, so you can xref against that.
<infinity> cjwatson: Alrighty.
<skaet_> Riddell,  https://blueprints.launchpad.net/ubuntu/+spec/kubuntu-q-images  is this approved now?   and can I consider that 1GB will be the limit you'll be using for Desktop?
<Riddell> skaet_: yes that's approved, marking approved and tidying up work items is on my todo
<skaet_> thanks Riddell   :)
<Laney> que, queuebot?
<infinity> stgraber: queuebot go byebye?
<stgraber> infinity: respawned. It only notices its offline when it tries to post something, which it didn't have to in a while apparently
<infinity> stgraber: That's odd that it had nothing to post, since it missed a bunch of my kernel accepts.
<infinity> Which reminds me that I need to follow those up for override fixing.
<infinity> bjf: For the ones that required override fixes, I've done so and updated the tracking bugs.
<infinity> bjf: For the ones that didn't, the tracking bugs are all yours to update. :P
<bjf> infinity: ack
#ubuntu-release 2012-06-16
<Daviey> ev: Have you renamed whoopsie-daisy to whoopsie?
<quadrispro> ehya guys
<ev> Daviey: yes
<ev> well, it was always whoops, but the source package was whoopsie-daisy
<ev> whoopsie*
<ev> as the source package used to contain the backend code
<ev> which now lives in separate branches
<ev> (lp:whoopsie, lp:daisy, lp:errors)
<ev> hm, I should probably make that Replaces: whoopsie-daisy
<ev> oops
<ev> err nevermind, source packages and all that jazz
<Daviey> ev: hey, yeah - that is why i was asking.. I saw it in the new queue.. Was kinda confused.
<ev> do feel free to let it through :)
<Daviey> ev: you are sure breaks and/or replaces aren't needed?
<ev> Daviey: pretty sure. It's a source package replacing a source package with the same binary packages.
<Daviey> ah, ok. I didn't dig into it.. reading split, i wondered if the files were now divided into two separate binary packages aswell.
<ev> yay, cheers
<phillw> ooh, do we have an update for crash reporter?
#ubuntu-release 2012-06-17
<stgraber> and now that queuebot supports IPv6, that's one less container with IPv4 connectivity!
<stgraber> wow, that was surprisingly easier than I expected, I now have a multi-threaded queuebot! will let the test bot run in a parallel for a few hours to check that it's not missing anything, but it's much much faster than the single threaded one :)
<cjwatson> stgraber: does it not use lplib?  I thought lplib was unsafe to use multithreaded
<cjwatson> some problem with its cachedir management
<tumbleweed> unfortunately, lplib's cache isn't particularly useful, either
<ScottK> Anything that's getting build on ain is hitting chrootwait.
<ScottK> cjwatson: ^^^ you can down buildd's, right?
<ScottK> infinity: ^^^ (re ain)
<ScottK> lamont: ^^^
<ScottK> I've retried as many as I could, but with ain still online, any more just land there and chrootwait again.
<stgraber> cjwatson: yeah, it's using lplib but I don't share the lp instance between threads. So far it seems to be working fine but I'll see in a couple of days if it still posts the same thing as the non-threaded queuebot
<infinity> ScottK: Offlined, thanks for the heads-up.
<ScottK> infinity: Thanks.
#ubuntu-release 2013-06-10
<AnAnt> Hello, few days I uploaded xpra 0.9.5+dfsg-1ubuntu1 to raring by mistake, it was supposed to be for saucy (which I've already done today).
<cjwatson> AnAnt: rejected, thanks
<didrocks> kenvandine: does it need to be in main? ^
<didrocks> or it's touch* only for now?
<kenvandine> not yet
<kenvandine> touch only for now
<jbicha> gssdp and gupnp should build now if someone wants to retry them (they needed vala-0.20)
<ScottK> PM me the links and I"ll retry them.
<infinity> jbicha: Done.
<ScottK> The dkimpy SRU uploads fix what may be a mail losing bug for people, so it'd be nice if someone from -sru could have a look.
 * ScottK waves innocently to infinity.
<infinity> ScottK: What is it with you and bugs that make people lose mail?
<ScottK> FWIW, not my code this time.
<ScottK> Neither the bug, nor the fix.  I'm just the messenger.
<ScottK> But that is why I tend to bother with the SRUs.
 * infinity waits on diff for P and Q.
<infinity> s/diff/diffs/
<ScottK> They have ubuntu in the revision.
<ScottK> IIRC you'll be equally unhappy about the maintainer.
<ScottK> Fixed version for raring uploaded.
<infinity> ScottK: Oh, since the maintainer is you anyway, I'm less fussed about that.  Just the version thing.
<ScottK> Personally, I pretty much never bother to change the maintainer if the maintainer is Debian is also me.
<ScottK> Fix for that is uploaded.
<infinity> ScottK: precise drops some changelog history, but I suppose that's not world-ending.
<ScottK> Crap.
<ScottK> I only looked back to make sure the previous entry from the last SRU was consistent.
<ScottK> I can fix it if you want.
<infinity> ScottK: Meh, no big deal.  It's meaningless history, since the new upstream folded all that in anyway, AFAICT.
<ScottK> It did.
 * infinity wonders what Brian's new sru-review tool does when LP hasn't diffed.
<infinity> Oh.
<infinity> (base)adconrad@cthulhu:~$ sru-review -s raring dkimpy
<infinity> ERROR: queue does not have a debdiff
<infinity> FRIENDLY.
<infinity> bdmurray: ^-- That might be suboptimal if anyone ever SRUs udev. ;)
<infinity> bdmurray: Maybe an "I've reviewd the diff externally, please let me use the tool anyway, kthx" option.
<ScottK> infinity: Thanks.
#ubuntu-release 2013-06-11
<darkxst> gnome-shell never got copied to quantal-updates from Bug 1128804\
<ubot2`> Launchpad bug 1128804 in gnome-shell (Ubuntu Quantal) "Update mutter/gnome-shell to 3.6.3" [Medium,Fix committed] https://launchpad.net/bugs/1128804
<ScottK> darkxst: That's because Bug #1132308 is still not verified.
<ubot2`> Launchpad bug 1132308 in gnome-shell (Ubuntu Quantal) "~50px pointer barrier in gnome shell at bottom of primary monitor" [Low,Fix committed] https://launchpad.net/bugs/1132308
<darkxst> ScottK, right, well if the reporter hasnt verified it by now, I suppose they never will. I can't actually test it since barriers don't work in VM's
<ScottK> darkxst: OK.
<ScottK> Oh, hey, it's been released.  I wonder how that happend.
<ScottK> ;-)
<darkxst> ScottK, thanks ;)
<FourDollars> 
 * cjwatson hides in a cave and tries to implement autopkgtest/proposed-migration
<cjwatson> I wonder how doomed http://paste.ubuntu.com/5754933/ will be
<infinity> I fear for our Velocity(tm) when this spins up.
<infinity> But I guess we'll see.
<cjwatson> Note that this is subject to force hints
<Laney> Would it be hard to add a force-tests hint type?
<Laney> so we don't have to toss all of britney out
<cjwatson> I'll look
<cjwatson> http://paste.ubuntu.com/5754976/ then
<cjwatson> ("force-autopkgtest")
<Laney> great
<cjwatson> Now if only I can figure out how to test this non-invasively ...
<infinity> Run britney on dogfood?
<infinity> Though, it probably can't talk to the adt machines.
<infinity> Maybe run a second britney instance on lillypilly *against* dogfood?
<cjwatson> I don't think dogfood will be helpful.
<cjwatson> Argh!  Unity!  Stop segfaulting!
<infinity> Have you upgraded lately?
<infinity> Mine stopped segfaulting recently.
<cjwatson> Yes, I have
<infinity> 7.0.0daily13.06.07-0ubuntu1 seemed to have fixed it for me.
<cjwatson> That's what I have
<infinity> Might also have been the libnux around the same time.
<seb128> infinity, cjwatson: there is still a bamf issue that Trevinho is working on, that might be your issue ... do you have a backtrace of the segfault?
<Trevinho> seb128: FYI i've identified the issue, so it's just matter of cleaning up my code and submit the change
<seb128> Trevinho, if that's the same one ... which is hard to say without a backtrace ;-)
<seb128> Trevinho, good job in any case ;-)
<Trevinho> seb128: it's likely that it is the problem...
<Trevinho> :)
<seb128> Trevinho, let's see
 * infinity is still amazed that no one took issue to us naming a project "bamf".
<Trevinho> :)
<Trevinho> infinity: it's offically just BAMF, Application Matching Framework :)
<infinity> I can only assume that none of the people who would normally care actually know what the acronym means. :P
<Trevinho> infinity: that it is... ehm... officially :)
<rtg_> infinity, did a library drop out of main ? '/usr/bin/ld: cannot find -liberty'
<cjwatson> That should be in binutils-dev
<rtg_> so, simply a new build dep. I'll give it a go.
<infinity> New?  Didn't the kernel always build-dep on binutils-dev?
<infinity> Sure does here.
<rtg_> and indeed still does. wtf ?
<rtg_> infinity, so this is perf that is failing to build because of demangle. I'm thinking I'll just disable demangle and see how it goes.
<rtg_> infinity, buf it y'all think liberty _should_ still exists, then I'm a bit concerned.
<infinity> Oh, hrm.  Newer binutils-dev seems to only have libiberty_pic.
<rtg_> I wonder why my test build worked
<infinity> I can't imagine that this is a recent change, mind you.
<rtg_> infinity, 2 updates since the last kernel upload
<infinity> doko: Was dropping libiberty.a from binutils-dev intentional?
<tumbleweed> win 12
<tumbleweed> err
<infinity> Oh, I didn't notice there was a shiny new shapshot in -proposed.
<infinity> rtg_: So, the one in the release pocket would work fine, the one in proposed, not so much.  Which would be likely why your testbuild went fine, if you don't build against proposed.
<infinity> rtg_: Or if you started your build more than an hour ago. :P
<infinity> rtg_: (So, yes, this is a very recent change)
<rtg_> infinity, yeah, so I'm just gonna disable HAVE_CPLUS_DEMANGLE for now.
<infinity> rtg_: Or you could use the _pic version.
<rtg_> infinity, well, I'm trying to remember why we wanted demangling in the first place. there is no C++ in the kernel
<infinity> I blame the raisins.
<rtg_> It kind of looks like the perf Makefile has improved to the point that it figures out why libraries exist if you _don't_ force HAVE_CPLUS_DEMANGLE, so maybe that _is_ the right thing to do.
<rtg_> s/why/which/
<doko> infinity, hmm, I see. it's not installed by default anymore. will fix it
<jbicha> oops, that EDS was meant for a PPA because of the removed symbol
<infinity> jbicha: "That EDS"?
<Laney> evolution-data-server
<Laney> will block
<infinity> I know what EDS is, I meant "which one?"
<stgraber> [ubuntu/saucy-proposed] evolution-data-server 3.8.3-0ubuntu1~build1 (Accepted)
<Laney> the one he just uploaded
<jbicha> Laney: it's also blocked because it has new packages
 * infinity gives up.
<infinity> Laney: There are 5 distro series in active development, with multiple pockets, I assume "just uploaded", that didn't tell me anything.
<infinity> If it's binary NEW, that'll be easy enough.
<infinity> Though, you still get to upload something to revert that now.
<Laney> Didn't mean to be facetious; I usually look at "latest upload".
<jbicha> infinity: well I think we do want it, I just want to check that e-d-s's rdepends still build first
<infinity> Laney: Which means nothing if it was aimed at a stable queue.
<Laney> now it's my turn to give up
<infinity> :P
<infinity> jbicha: Well, if it's binary NEW, I'll just reject the binaries, and you can reupload with a more pleasant version number when you're sure it's what we want.
<jbicha> ok that will work, thanks
#ubuntu-release 2013-06-12
<seb128> infinity, cjwatson, wgrant: hey, do you know what are the disk space limitations on ppa builders? is there any way we could have libreoffice somewhat build on machines that have > 40G for free disk space?
<wgrant> seb128: no, there's no way to do that. how can it possibly need suxh a ridiculous volune?
<seb128> it's libreoffice, don't ask...
<seb128> c++ objects are not small
<seb128> webkit for example with a 5Mb source uses some 15GB of disk space to build
<wgrant> sure, but it still seems implausible
<wgrant> regardless, not something we can support. you would probably have to talk to IS
<infinity> IS can't do much about it either, other than upgrade the world.
<infinity> This isn't exactly new.
<seb128> well, hardware improve, you could think that 50G of disk space is not a lot by today's standards
<seb128> there is no way we will make libreoffice smaller with our one maintainer
<wgrant> seb128: we have multiple guests on a single host, and lots of old hardware that we are stuck with
<infinity> seb128: It's not, but it's a matter of them either swapping hard drives in a bunch of old computers (which they don't want to do), or wait for the cloudified builder.
<seb128> Sweetshark suggested turning off tests on the buildders to workaround the space issue :/
<infinity> seb128: Turning off tests for PPA builds is fine, as long as he doesn't do it for archive uploads. :P
<seb128> so archive builders don't have that space issue
<infinity> I thought he was already mangling his PPA builds anyway.
<seb128> I guess the ppa wouldn't either if it was devirtualized, right?
<infinity> No, archive buildds are fine in this regard.
<seb128> he is mangling them
<seb128> but that's becoming ridiculous
<seb128> and that makes ppa builds different from archive builds
<seb128> so not as good as a testbed for archive uploads as they could be
<seb128> we had bugs in the mangled part before which meant archive builds failed
<infinity> I remember, I fixed that once. :/
 * infinity wonders why britney hasn't britnized in 5 hours...
<ogra_> "britnized" ?
<ogra_> oh my
<infinity> ogra_: Britnified?
<ogra_> i dont know, i kind of get a picture of a bold and suddenly chubby girl on drugs in my head if you say that
<infinity> cjwatson: Has the autopkgtest integration caused britney to asplode, or...?
<cjwatson> Unlikely, since it's not committed yet.
<infinity> So process 15176 doesn't relate?
<cjwatson> That's me trying to pdb things into existence - it shouldn't interact
<infinity> Anyhoo, britney hasn't output anything useful in ~5h, I was just quickly finger-pointing without cause. :)
<cjwatson> I started that process more like 20 hours ago
<cjwatson> Well, 19
<cjwatson> infinity: proposed-migration/log/2013-06-12/10:03:43.log shows a crash
<cjwatson> I'll need considerably more coffee if you want me to debug that :)
 * infinity shoves a coffee packet in the CD slot, and clicks 'brew'.
<wgrant> seb128: Do we know how much space libreoffice actually needs nowadays?
<seb128> wgrant, I need confirmation from Sweetshark, the number he gave first were putting the build around 30GB ... but that's the disk space used at the end of the build, it seems to spike over that during the build (some objects are copied and then replaced by symlinks)
<seb128> I asked him to join the channel when he reads my ping
<Sweetshark> seb128: joined, but I have to go to lunch, I have an appointment. Ill read the backlog though.
<seb128> Sweetshark, ok, wgrant was asking for an estimate for the space you need for the build
<seb128> Sweetshark, your number seems to be in range from 30GB to 100GB ... the second one seems a bit high, Laney managed to build in memory recently using 32GB iirc
<wgrant> 100GB!?
<Sweetshark> seb128: so, I would estimate the peak of the work directory to be in the 30-35GB range. The 100GB figure was the whole pbuilder-root (to take into account the big set of deps that LO has).
 * wgrant wanders off to sob quietly
<Sweetshark> 110GB that is.
<czajkowski> God lord 110GB!
<seb128> wgrant, I think 30GB is a better estimate, 100GB was a du on a full pbuilder with the libreoffice build-depends installed (which seems to be like half of the archive)
<Laney> the one I managed to do in RAM was an arch-dep build only
<seb128> wgrant, make it 40GB to be safe
<infinity> seb128: 100ish sounds more accurate, then.
<Laney> arch+indep ran out of space
<doko> cjwatson, http://people.canonical.com/~ubuntu-archive/proposed-migration/ seems to be outdated
<infinity> seb128: The PPAs don't magically install build-deps on another disk, after all.
<infinity> doko: Yeah, it's crashing.
<doko> ouch
<seb128> infinity, yeah, I guess if you count system + builddir
<infinity> If libreoffice and its build-deps keep growing, the archive buildds won't be able to build it soon. :/
<infinity> They're easier to justify upgrading but, still, that's insane.
<seb128> well, we are not creating the situation
<seb128> but yeah, it sucks
<infinity> We're not helpless pawns, either.
<seb128> not sure what else to do though :/
<infinity> I suspect things could be done, patches could be submitted.
<seb128> right
<wgrant> What takes up all the space?
<wgrant> I actually cannot comprehend it.
<wgrant> It's insane.
<seb128> Sweetshark, ^
<doko> Sweetshark, split build!
<Sweetshark> infinity: https://bugs.freedesktop.org/show_bug.cgi?id=60924 and followups might make split builds easier in the long run, but that still takes time ...
<ubot2`> Freedesktop bug 60924 in Libreoffice "move libraries to autoinstallation in scp2" [Normal,New]
<infinity> Probably the most obvious (but painfully time-intensive) win would be splitting the upstream source.  A lot.
<infinity> wgrant: The fundamental problem is that it's a bunch of libraries with a bunch of build-deps and a bunch of binaries with a buch more build-deps, all in the same build tree.
<infinity> wgrant: Imagine if all of KDE built in one go, instead of the hundreds of packages it currently is.
<wgrant> what, like 4 years ago? :)
<infinity> A bit longer than that. :P
<infinity> 4 years ago, it was in nice little related bundles, I guess.
<infinity> kdegames, etc.
<infinity> But libreoffice is kinda like kdelibs + kderuntime + koffice + kitchensink
<Sweetshark> doko: also note the irony of the thing causing us to run out of space is running the subsequenttests. and with a split build, that would need to be reconsidered anyway: subsequenttests can detect an error in any of the split packages, but can only run with all of them build.
<Sweetshark> doko: so that would need reevaluation than anyway.
<infinity> Sweetshark: Turn them into runtime tests instead of build-time tests, and they can be tested agaisnt the binary packages.
<infinity> Sweetshark: (For debian/ubuntu, that would be autopkgtest, but others have similar post-install test frameworks)
<Sweetshark> infinity: I already did this cycle: http://skyfromme.wordpress.com/2013/03/19/autopkgtests-for-adults/
<infinity> Is it safe to click that link?
 * infinity is suspicious.
<Sweetshark> infinity: here is the catch: they were also too big for the default autopkgtest images ;>
<Sweetshark> infinity: its sfw
 * Sweetshark gotta run
<xnox> Sweetshark: talk to unity/dx people, I think it should be fine to run on top of utah and or otto. With later being quite fast and caching/keeping dependencies pre-installed.
<xnox> Sweetshark: looking at lp:auto-package-testing it does support resizing the disk image and thus you can have bigger disk for autopkgtest in jenkins.
<cjwatson> Sorry for the delay in proposed-migration coming back; I'm still attacking it with gdb
<cjwatson> Er, pdb
<ogra_> cjwatson, i assume it will still take a while ? (if so i'll disable the touch cronjob since i need the two last uploads in the next build)
<cjwatson> When would it fire?
<ogra_> 6 min according to my clock
<cjwatson> Oh, there's no way you'll get new packages by then anyway - the publisher still has to run
<cjwatson> Even if I fixed it right now
<ogra_> i'm fine doing a manual build later ... i just dont want it to run automatically and block for 90min
<ogra_> ok
<ogra_> no prob :)
<cjwatson> It's something complicated in the undo logic for rolling back failed hints, I think
<ogra_> yeah, no worries
<cjwatson> Ah, I think I might see the problem ...
<cjwatson> I bet undoing changes in reverse order would improve things
<Sweetshark> xnox: well, yeah. I already resized the autopkgtest image locally -- it works. Otherwise I wouldnt have blogged "it works" ;).
<xnox> Sweetshark: yeah there is a -S size option in prepare-testbed in that branch. Maybe talk to qa or pitti about bumping the size for libreoffice or bumping the size in general.
<cjwatson> argh argh argh.  reverse the undo list and I get a different crash
<jibel> Sweetshark, xnox  I increased the size to 12GB. Will it be enough for LO?
<xnox> jibel: doesn't it need something like 40GB?
<jibel> xnox, if the test builds the package, probably.
<jibel> xnox, currently it crashes because it downloads 2GB of dependencies which uses 5G of disk space after installation, let see how far it goes with the bump.
<chrisccoulson> can someone please approve that flash upload? ^^
<cjwatson> Phew, I think I've fixed proposed-migration
<cjwatson> Running now
<ogra_> \o/
<cjwatson> There we go.  Next publisher run should do it
<infinity> jbicha_: ^-- Do you really mean it this time?
<jbicha_> infinity: yes :)
<infinity> chrisccoulson: You might want to kick the -0precise1 habit in favor of -0.12.04.1 before we wrap around the alphabet. ;)
<chrisccoulson> infinity, won't support for flash have ended by the time we roll around? ;)
<chrisccoulson> i can't remember when they announced the 5 years of security updates for the current version
<infinity> chrisccoulson: One can hope so.  It's more about breaking the habit in general. :)
<bdmurray> cjwatson: with the phased-updates work how would you imagine sru-release working since it should set the phased update percentage to something low?
<cjwatson> yes, I was expecting it would crank the PUP on the copy in -updates down to something low
<cjwatson> however I wonder if that's possible without waiting for the copy to actually take place ...
<infinity> Not if it's an override.
<infinity> The copy job needs to happen, then you can override in the queue before it actually publishes.
<infinity> Well, not in the "queue", per se, since it has a pending publishing record at that point, but you know what I mean.
<bdmurray> so perform the copy then use changeoverride to set the PUP low?
<cjwatson> right, the problem is copies are async and you have to wait; right now an expected wait of a little over 30 seconds +/- 30 seconds
<cjwatson> I was wondering if copyPackage(phased_update_percentage=blah) would be sane
<infinity> Overrides are inherited on copy, why don't we just set it in proposed, then copy?
<cjwatson> I guess that would work too
<cjwatson> Does it copy pending override changes?
<infinity> Oh, probably not.
<infinity> I meant set it earlier.
<cjwatson> Try it on dogfood I guess
<infinity> But I guess that's undesirable.
<cjwatson> It might, I just don't believe any particular property about copies until I've seen it
<infinity> We want it 100% in proposed, but something < 1 in updates, I guess?
<bdmurray> Right
<cjwatson> Yeah, that's the thing, dropping the PUP in -proposed might inhibit the testing we get
<infinity> How long are these phase cycles meant to be in general, anyway?
<infinity> I get antsy when the cool kids get a google app a day or two before me, a week would be lame. :P
<bdmurray> Also regarding "trying it" - I don't have the proper permissions to use changeoverride iirc
<cjwatson> You could on dogfood
<cjwatson> It has independent team membership
<bdmurray> Is dogfood staging?
<cjwatson> No
<infinity> No, it's dogfood.
<cjwatson> However, if sru-release is going to need to change overrides, you'd need those permissions on prod
<cjwatson> So let's see if you have them already
<bdmurray> When we were testing checkbox last week I didn't.
<infinity> Yay, more permissions and more potential for subtle archive breakage. :/
<cjwatson> Looks like you need launchpad.Append on the archive, and it's not per-series.
<cjwatson> Seems to me that ought to be tied into the per-series permissions for other things.
<infinity> Perhaps, except that as long as only ubuntu-archive had the permission, no one cared.
<cjwatson> Anyway, by way of testing, you're in ~ubuntu-archive on dogfood now.
<infinity> Honestly, expanding that one scares me a bit in general.  Bad override mangling can cause very hard-to-debug behaviours.
<cjwatson> Well, let me put it a different way.  If ~ubuntu-sru stop being able to use sru-release, that would be bad.
<cjwatson> I agree override mangling can be a problem, but it's a problem even today, realistically ...
<infinity> Can we not just have a default PUP, and ask AAs to twiddle if your package is a unique snowflake?
<cjwatson> Default just for copies into -updates?
<cjwatson> It's all a bit magic.
<infinity> It's absolutely a problem today, I agree, I just fixed a bunch of overrides in post-release pockets this morning.
<infinity> I'd just prefer to limit the number of fingers in that pie.
<cjwatson> copyPackage(phased_update_percentage=) would allow sru-release to control this without opening overrides in general.
<infinity> Would it?  Wouldn't that still require them to have the permission?
<cjwatson> Don't see why.
<infinity> Well, the copy already does.  I suppose the other bit could skip a permission check, sure.
<infinity> That might be the path of least scary, then.
<cjwatson> The permission check is on the BPPH.changeOverride interface, but the copier has to create a new BPPH anyway and it could just set it up in the desired state to start with.
<infinity> That's a fair point.
<infinity> I like that proposed solution, then.
<infinity> It means ubuntu-sru can't alter the PUP post-release, but that's probably not a big deal.
<cjwatson> That was all going to be done by a cron job anyway, IIRC
<cjwatson> I guess we'll see whether the LP guys think it's too magic ...
<cjwatson> Or too specialised
<infinity> Sure, I meant if someone felt they messed it up or needed to force a new value.
<infinity> But asking an AA to intervene there seems fine.
<bdmurray> if that means incrementing and setting to 0 for a cronjob, then yes I'm working on that
<ScottK> At least if it was 0 in proposed we'd get fewer complaints about regression in proposed.
<bdmurray> infinity / cjwatson: so uing change-override with -l dogfood should be okay then?
<infinity> bdmurray: Should do.  Given that you don't have access to mess up the primary archive anyway. ;)
<bdmurray> I'm getting a httplib2.CertificateHostnameMismatch: Server presented certificate that does not match host api.dogfood.launchpad.net: error
<stgraber> haha, yeah, classic problem, the certificate is for *.launchpad.net which doesn't cover *.*.launchpad.net and so covers dogfood.launchpad.net but not api.dogfood.launchpad.net
<bdmurray> great
<stgraber> so maybe there's an environment variable or option you can pass to bypass the SSL cert check, otherwise I'm affraid you may have to patch your local copy of lazr to skip the check...
<bdmurray> did I say great already? ;-)
<stgraber> infinity: can you add me to ~ubuntu-archive on dogfood looks like the DB import is a bit old
<stgraber> (and the TB doesn't own that one for some reason)
<infinity> stgraber: Done.
<stgraber> bdmurray: LP_DISABLE_SSL_CERTIFICATE_VALIDATION=True change-override ...
<stgraber> infinity: thanks
<stgraber> bdmurray: obviously, that's usually a very bad idea to set that env variable so make sure that it's not persistent :)
<bdmurray> stgraber: right of course.  thanks!
<bdmurray> Hrm, now I'm getting a "Cannot change overrides in suite 'quantal'" error
<infinity> bdmurray: Because you can't, it's stable.
<infinity> bdmurray: Did you mean quantal-updates, perhaps?
<bdmurray> infinity: ah yeah, I'd used -s quantal no -s quantal-updates
<wgrant> cjwatson: Copies don't preserve PUP, do they?
<wgrant> I'm pretty sure there's a comment in copyBinaries saying that there's no point
<cjwatson> You may be right
#ubuntu-release 2013-06-13
<cjwatson> But if so that was because it didn't make sense to copy, not necessarily that it didn't make sense to set it at all
<wgrant> cjwatson: Sure, just saying it wouldn't work in the current code.
<zequence> Any way to learn about ISO download statistics?
<zequence> I'd be interested in comparing Ubuntu Studio with others
<ScottK> zequence: Since the ISOs are all available via torrents, there's really no knowing.
<zequence> ScottK: The direct downloads would still give you an idea of proportions
<zequence> I realize actual amounts don't say much
<ScottK> Only if the direct download versus torrent ratios are the same.
<zequence> It would still tell me something, I think
<ScottK> If you want some publicly available information to get an idea of ratios, look up the popcon data for the various metapackages.
<zequence> any other methods for comparing flavor popularity?
<zequence> popcon?
<ScottK> Other than popcon (which has it's own limitations) no.
<ScottK> Short for "populairity contest".
<zequence> ah http://popcon.ubuntu.com/
<zequence> ScottK: Thanks
<ScottK> For people that opt-in, it send information about what packages they have installed.
<ScottK> You're welcome.
<infinity> ScottK: popcon is self-selecting for the nerdier/ricer crowd, much like distrowatch stats.
<ScottK> infinity: That's true.  It's gone tons of problems, but I don't know of better, public data.
<infinity> ScottK: But, I suppose, given that the "nerd/ricer" crowd is probably fairly well distributed among all the flavours that are "anything but Ubuntu itself", it might even out.
<ScottK> Although Kubuntu has some substantial organizational deployments that I don't think the other non-Canonical flavors have.  I'm sure they don't have popcon on.
<infinity> Yeah.  I was going to say the same for edubuntu.
<infinity> Anyhow, we can occasionally dig out fun stats from cdimage and archive logs, but even those are Not A Metric(tm), which is why we try to avoid telling the world about them.
<infinity> Cause, who needs the sort of silly bickering that distrowatch causes in our own little family of flavours? :P
<ScottK> infinity: You aren't releasing any SRUs just now are you?  (I am and I don't want to do double)
<ScottK> Done
<infinity> ScottK: I wasn't, no.
<ScottK> OK.  I'm all done now.
<ScottK> I figured if I waited until the next publisher run, it'd be safe.
<skaet> bdmurray,   was starting through the checklist for MilestoneProcess,  and "DevelReleaseAnnouncement" link on the wiki is null page.    More details?
<cjwatson> It's a file name, not a wiki page name.  I've unlinkified it
<apw> i am unable to figure out why linux-grouper is sitting in -proposed, britney has done two runs (at least) over it and still seems to think it is out of date, when from what i can see it is not in the archive
<apw> keen to figure out if i am missing something or if britney is unhappy
<skaet> cjwatson, thanks.
<cjwatson> apw: looking
<ogra_> cjwatson, so there was just a discussion on #phablet ... do we already have any idea how we will integrate the installation of click packages into cdimage builds ?
<ogra_> seems thats a july target ...
<cjwatson> ogra_: not yet, on my list somewhere
<cjwatson> it clearly has to happen
<ogra_> heh, yeah, but it doesnt even seem to be clear where click packages will eventually live
<cjwatson> ogra_: beuno is managing the server side
<ogra_> i was guessing a blessed archive like partner
<cjwatson> apw: so I think the reason this is unusual is that there's -3.5 in release, and then a -3.7 in proposed that didn't migrate before -4.x landed
<cjwatson> ogra_: custom server, not LP
<ogra_> since we cant ship preinstalled PPAs
<ogra_> ah, k
<ogra_> so the PPA discussion is out of question, good
<rtg_> cjwatson, yeah, the grouper upload series have been stalled by britney for a couple of valid reasons along the way. I _think_ it should be correct now.
<cjwatson> apw,rtg_: I've NBS-removed those stale binaries from -proposed now; should migrate in the proposed-migration after the next publisher run
<rtg_> cjwatson, cool, thanks. apw ^^
<ogra_> cjwatson, oh, and if you have a spare minute at some point, there are still the machine accounts for rsalveti and sergiusens pending on nusakan i think
 * ogra_ always forgets about that 
<sergiusens> \o/
<sergiusens> cjwatson: hey last night I tried to build the deb and with python3 I get error: error in setup.cfg: command 'build' has no such option 'pod2man' ... worked fine with 2... so was wondering what dep I'm missing (which perhaps seems to be missing in Build-Depends)
<sergiusens> cjwatson: missed the important piece lp:click-packages was what I tried to bzr bd
<apw> cjwatson, ahh so until someone cleans up NBS britney will always hold a kernel
<cjwatson> rsalveti,sergiusens: added you both to ~ubuntu-cdimage in LP, and filed an RT to get you machine access.  Please see https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<rsalveti> cjwatson: great, thanks
<cjwatson> sergiusens: WFM - can I have the full log?
<cjwatson> sergiusens: shouldn't need any particular B-D, apart from python3-setuptools which is already there
<cjwatson> apw: It's only in the case where there was a previous unmigrated upload in -proposed with a different ABI
<sergiusens> cjwatson: thanks, and  here's the log: http://pastebin.ubuntu.com/5761390/
<apw> cjwatson, ahh subtle thanks for the explanation
<cjwatson> sergiusens: huh, yeah, I see it in sbuild ...
<phillw> cjwatson: is there a link to view what is the seed file for the saucy lubuntu iso's ?
<cjwatson> phillw: bzr co lp:~lubuntu-dev/seeds/lubuntu.saucy
<cjwatson> sorry
<cjwatson> bzr co lp:~lubuntu-dev/ubuntu-seeds/lubuntu.saucy
<phillw> thanks!
<cjwatson> sergiusens: *mutter* stupid incomprehensible setuptools bugs
<cjwatson> working on it ...
<sergiusens> ack
<cjwatson> sergiusens: Ah, got it.  r80
<sergiusens> great, built fine
<cjwatson> But talk about an obscure way to present that error.
<infinity> barry: The lsb in the precise queue wasn't good enough for you? :P
<Laney> LSB_ME_HARDER
<barry> infinity: crap, i even thought i searched the queue and didn't see it
<infinity> barry: I'll eenie meenie miney and reject one of them in a bit.
<barry> +1
<phillw> on 7th June, https://code.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.saucy shows that chromium was replaced by firefox, but my install today is now installing chormium. Any ideas?
<infinity> phillw: Which version of lubuntu-desktop is installed?
<infinity> phillw: gilir only uploaded the new meta 15h ago.
<phillw> infinity: ahh, okies. I thought the seed was read from there. I'll await today's cron build. Thanks!
<cjwatson> rsalveti,sergiusens: you should have ssh access to nusakan and 'sudo -u cdimage -i' now
<cjwatson> (RT#62315)
<jbicha_> is there a plan for Alpha1 next week?
<rsalveti> cjwatson: thanks!
<sergiusens> cjwatson: thanks
<ogra_> yay
<jbicha_> phillw: see also http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.saucy/desktop which runs multiple times daily
<phillw> thanks
<phillw> jbicha_: lubuntu will be running Alpha1
<jbicha_> you mean you guys are in charge of the release? or just participating? :)
<infinity> jbicha_: There's a plan for me to send an email about Alpha being a week later, as we agreed at UDS and I forgot to change the schedule. :/
<infinity> jbicha_: I'll get that out today, I'm just context switching between a few things.
<jbicha_> ah ok I didn't realize the wiki wasn't updated
<jbicha_> how much work will it be for flavors if they choose to participate in an Alpha?
<infinity> jbicha_: Testing, helping with release notes, the usual.
<jbicha_> it would be cool if releasing an alpha would help us get testing as opposed to having to do it all ourselves before the release
<infinity> jbicha_: It's less about how much work it'll be for the flavours, and more about how much work it shouldn't be for the people not participating. :)
<phillw> infinity: yeah, if you can get the email out! I've already scheduled meetings for just before each of the milestones :)
<stgraber> infinity: ah good, that's one more week for me to finally land the self-rebuild feature on nusakan then (kind of forgot about alpha1 so didn't prioritize accordingly) ;)
<infinity> stgraber: Oh shiny, if that lands in time, we can put it through its paces.
<infinity> stgraber: That might mean you should sign up for the engineering task on A1 if you haven't already. :P
<infinity> Oh look, you did.
<stgraber> infinity: that's precisely why I signed up for the engineering side of things for A1 :)
<infinity> Riddell: I notice you signed up for the release notes task for A3 which is, conveniently, the Alpha I'm about to drop from the schedule.  How would you feel about doing that for A1 or A2 instead?
<phillw> infinity: A3 is going? lubuntu were planning not to do A2 as it is too close to the A3 ?!!
<infinity> phillw: That's why A3 is going away.  We're spreading them out a bit to match the previous release.
<stgraber> phillw: yeah, A3 made it to the schedule by mistake, A1 and A2 will be moved slightly to have more spaces between them (similar to what we had for raring)
<phillw> stgraber: that's fine. the lubuntu testers asked for approx one milestone each month, which is why A2 was not going to be tested.
<cjwatson> phillw: What happened here was that the saucy schedule was erroneously based on something a bit more like quantal's - the changes made in raring were mistakenly not applied to it
<cjwatson> (IOW, creating schedules in advance has turned out to be a bad idea)
<Riddell> infinity: :)
<Riddell> infinity: why are you dropping A3?
<phillw> that's fine! if it can be updated today, I can let our testers know and re-do the time table for the general meetings.
<cjwatson> Riddell: It wasn't meant to be there.  Compare https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
<Riddell> yep, just read
<Riddell> got a new date for alpha 2?
<Riddell> infinity: anyway yes you can move me to alpha 2
<bdmurray> using sru-release "sru-release -n -s precise nagios-nrpe" indicates it would copy the package to precise-security.  I suspect this is fine as one bug being fixed has a CVE but I just wanted to confirm.
<infinity> bdmurray: Err, it will because of the '-s'
<infinity> bdmurray: But if was built in proposed, no, it can't be released to security.
<bdmurray> hrm, I find the meaning of the -s switch in the ubuntu-archive-tools to be confusing
<bdmurray> It just seems to be inconsistently used
<cjwatson> It's sometimes suite and sometimes series.  In most of the ones I wrote it's suite ...
<cjwatson> But there are cases where suite isn't really all that appropriate
<infinity> Except that in sru-release, it's neither suite or series, which leads to this problem.
<infinity> It should probably be replaced with --security or sometihng, so people don't eff it up.
<cjwatson> infinity: Oh, yes, that's pretty scary
<cjwatson> Indeed, we could just ditch the short option
<cjwatson> ... done
<bdmurray> thanks!
 * infinity will now need to retrain his fingers, but probably a small price to pay.
<bdmurray> cjwatson: speaking of long options shouldn't -y for change-override be --confirm-none not --confirm-all?
<infinity> bdmurray: Hrm?  comfirm-all meaning "say yes to all questions".
<infinity> --yes-me-harder
<bdmurray> okay
<cjwatson> Depends which way you read it, I guess
<infinity> cjwatson: Yeah, I read it bdmurray's way after he asked.  Curious thing, this English.
<infinity> (I've always read it the "right" way before
<infinity> )
<infinity> bdmurray: I just saw your film debut.  I don't think you get to criticize ubuntu-archive-tools for a few days.
<bdmurray> infinity: heh. that's not actually my debut, I've done some previous work!
<infinity> bdmurray: ;)
<infinity> bdmurray: After you delivered your first line, I was all "that dude in the suit sounds just like Brian".
<slangasek> infinity: <snort>
<xnox> hm? i think I haven't seen that yet
<phillw> infinity: sorry to nag, but how soon do you expect to have https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule updated (I've got to re-schedule meetings and xubuntu have just had a meeting deciding to to partake in A1, A2 & A3 !) :)
<infinity> phillw: It'll be done this afternoon/evening.
<phillw> thanks
<slangasek> xnox: you need to be following kees on g+ :)
<xnox> slangasek: i think i have circled him recently.
<slangasek> xnox: oh... then you need to convince kees to share with you ;)
<Laney> an all star cast and crew
<kenvandine> indeed
<xnox> ahhh... please reshare it to me =)
<Sarvatt> xnox: http://vimeo.com/68009319
<xnox> =))))))) nice
<xnox> is it #ingress inspired?
<kees> xnox: nah, it's based on a tiny piece of a web comic. I needed something ultra short.
<infinity> kees: Did you name-drop with Jeph when you asked him for permission?
<infinity> kees: (Which I suppose would only work if you knew that he and I have known each other for well over a decade, hrm...)
<infinity> Dearest Launchpad: Either accept or reject my copy, but don't just eat it and email me "nom nom nom" messages.  Thanks.
<kees> infinity: nope, I didn't ask for permission. :)
<kees> infinity: I had no idea you knew him!
<kees> infinity: I posted it to the QC forum, though, so maybe he'll see it.
<infinity> kees: Long and sordid past.  We met in NYC over a decade ago (back when he was still a music student, not a cartoonist), later ended up dating the same girl (at different times), etc.
<kees> infinity: hah, funny :)
<bdmurray> infinity: https://dogfood.launchpad.net/ubuntu/quantal/amd64/libxen-dev is the increasing number of publications expected because it is dogfood?
<infinity> bdmurray: If you keep overriding it without the publisher ever running, yeah.
<infinity> bdmurray: And dogfood's publisher isn't cronned.
<bdmurray> infinity: okay, just wanted to make sure there wasn't something else wrong.
<cjwatson> infinity: You know Jeph?  *fanboy*
<infinity> cjwatson: I suspect my opinion of him is slightly lower than yours. ;)
<infinity> cjwatson: But yes.
<cjwatson> Familiarity breeds contempt, I'm sure :-)
<bdmurray> cjwatson: were you going to talk to Launchpad devs about copyPackage and phased_update_percentage?
<cjwatson> I wasn't sure whether wgrant talking here qualified as him having registered the discussion :)
<cjwatson> I should probably file a bug, when I'm not two pints of beer + one cider the worse for wear
<bdmurray> Oh, I missed him saying something
<ScottK> infinity: So what are the planned dates (or where did this vUDS discussion get documented)?  Moving Alpha 1 a week slaps it right on top of KDE 4.11 Beta 2, which is why we put it where it is on the wiki after pgraner's call for inputs back in March: https://lists.ubuntu.com/archives/ubuntu-release/2013-April/002361.html
<ScottK> infinity: Could we please find a way not to recreate the problem with KDE 4.11 beta 2 that we already fixed once with KDE 4.11 beta 1.
<wgrant> cjwatson, bdmurray: I've registered the discussion, but I'm not going to really do anything yet since AFAICT nobody knows what wants to be done. When someone has some idea, I'm all ears :)
<infinity> ScottK: KDE 4.11 B2 is on the 26th, a day before the proposed A1 would release.  Is that really a problem?  You get to spin alphas and stabilise on 4.11b1 while people upload 4.11b2 to proposed and have it all land and break the world after A1 releases...
<cjwatson> I think our consensus was that we wanted to be able to copy packages and set an initial phased_update_percentage for them in one go
<ScottK> Except it's the same people doing both.
<infinity> ScottK: Well, sure, but it's within a day.  They could upload a day later too, no?
<ScottK> Sure.  Next time don't ask for inputs, just do whatever.  We'll manage.
<infinity> ScottK: I'm trying to discuss this, not be a jerk about it.  But it seems that, either way, you'd be releasing A1 with 4.11b1 and then landing b2 afterward, all this does is slip b2 hitting the release pocket for a day.
<ScottK> I mean it's pretty frustrating to be asked for inputs, go to trouble to coordinate them, get everyone to agree, and then be told that a month later there was a meeting that everyone forgot to mention the results of for a month.
<infinity> ScottK: I guess I'm just trying to understand why that's problematic.
<ScottK> For the week in question, I think we can either package KDE 4.11 beta 2 or do the Alpha.
<ScottK> I doubt we'll get both done.
<ScottK> We can just land the beta later, but it's all very frustrating.
<ScottK> I don't understand why inputs were even requested.
<cjwatson> I think we had some slack in alpha scheduling otherwise, didn't we?  I don't recall the vUDS discussion being very constrained on those.
<infinity> ScottK: We can alternately drop A3 (as planned), but not move A1 and A2.  The big motivation for moving A1 and A2 by a week was also to have them align a bit better with end-of-month milestones, since having two competing sets of milestones would be a frustrating thing.
<cjwatson> The end-of-month thing was a minor benefit, I thought.
<cjwatson> Rather than the sole motivation.
<ScottK> End of the month is irrelevant for those of us who don't care about it.
<infinity> Well, everyone had different motivations.
<ScottK> I'll let Riddell decide.
<infinity> ScottK: I think it's fairly relevant to allow flavours to align, for when their packaging changes cause crossover issues, but maybe that's just me.
<ScottK> I'm sufficiently frustrated from a process perspective I don't trust my judgment on is it a problem at the moment.
<ScottK> Right, which is what I thought we got sorted back in march/april.
<cjwatson> I must admit I had entirely missed the thread you point to
<cjwatson> Don't know about others
<infinity> For the record, these were the meeting notes I had completely forgotten to implement and mail out until today:
<infinity> - Drop an alpha
<infinity> - Move alpha1/2 to wk9/13
<infinity> - Move FeatureFreeze to Beta1Freeze
<infinity> - Move DocStringFreeze to FinalBetaFreeze
<infinity> It was pretty... Sparse.
<cjwatson> It was basically "let's not forget to apply changes from raring".
<ScottK> I don't understand why this wasn't discussed when we were discussing the schedule.
<cjwatson> I think we hadn't noticed that the draft schedule was weirdly more like quantal than raring.
<ScottK> I need to go.  Please discuss the schedule with Riddell.
<ScottK> OK.
<cjwatson> It was a screwup.
<ScottK> TTYL.
<cjwatson> infinity: I think possibly the reasoning you're missing is that Kubuntu feels it important to be as early out the door as possible with new KDE releases
<infinity> That's fair.  And we can keep A1 and A2 as they are.  I'm not hugely fussed about them.
<cjwatson> So an alpha in the same week basically forces them a week later than they'd otherwise have been which means other distros get to get the jump on them
<infinity> I'd argue that, to make the gaps a bit less weird, we might then want to move B1 a week earlier instead.
<cjwatson> Where does that put it?
<infinity> Which would also work out alright as far as lulls in the KDE schedule.
<cjwatson> Or when, I suppose
<infinity> That would pur freeze at Aug22 and release at Aug29.
<infinity> KDE 4.11 releases on Aug14, and 4.11.1 releases on Sept3.
<infinity> So nicely not competing.
<phillw> A2 to A3 is too close, what date are you suggesting for the new A2 (replacing A3) ?
<infinity> phillw: A3 is going away.
<phillw> infinity: so A2 becomes A3 on that date?
<cjwatson> So that puts feature freeze back where it originally was, I guess
<infinity> phillw: No.
<cjwatson> You might want to give folks warning of that :-)  But I don't think I have a problem with that
<infinity> cjwatson: Well, FF and B1F should be the same freeze date.  It's just a question of moving one to meet the other, in one direction or the other.
<cjwatson> Right, I realise
<infinity> cjwatson: Given that we never moved FF after our discussion, I doubt anyone is/was counting on the later date.
<cjwatson> True
<stgraber> infinity: I've got to go now, not sure if I'll be back on IRC later tonight. If we do end up having A1 next week (after you're all done discussing this), can you make sure to send something to that regard to ubuntu-release@lists.u.c or at least PM me on IRC? Because if we're doing A1 next week I need to change my schedule for tomorrow from system-image stuff to cdimage self-respin stuff.
<infinity> stgraber: Yeah, whatever we hash out, I'll mail out.
<infinity> ScottK: *pokity poke*... I know you're gumpy, but come back. :)
<infinity> ScottK: If we leave A1 and A2 alone, drop A3, and make B1 a week earlier, would that all work out for you?  It seems to align well with gaps in the KDE release schedule I'm looking at.
<phillw> infinity: that'd be fine by lubuntu... one milestone / month :)
<skellat> infinity: I just got back from the arts charity meeting where I'm attached as their PR flack.  Could you please send an e-mail about these milestone changes to those of us in Xubuntu land since we just had a meeting earlier today discussing opt-in/opt-out options?  Most of the scrollback above seems to make a good chunk of our meeting earlier today kinda moot and not longer valid.
<skellat> infinity: My unofficial copy of the meeting notes are here if you want to view them on your own: https://wiki.ubuntu.com/skellat/XubuntuMeeting--2013-06-13
#ubuntu-release 2013-06-14
<infinity> skellat: Read through it all.  I suspect all the above would do is s/a3// from your discussion.
<infinity> skellat: I assume those of you who are about release issues are subscribed to ubuntu-release@lists, so I don't have to hunt you down? :)
<skellat> infinity: Bingo.  I just happen to be in Eastern Standard Time and saw this.
<infinity> s/who are/who care/ might make my sentence make more sense. ;)
<skellat> From our discussion we were pretty much focused on Alpha 2 as target.
<infinity> skellat: Check, so dropping A3 shouldn't be a big deal.
<infinity> (And dropping A3 isn't really up for discussion, IMO, it was a mistake that it was there in the first place, which is fairly obvious from the tiny 2-week gap)
<skellat> Shouldn't be on our end.  I can't speak officially for the release team of knome and elfy but our discussion today was pretty focused on getting ready for A2.
<skellat> We still haven't heard from upstream Xfce as to when 4.12 will drop so we were still gearing up for when the toolchain changes hit.
<infinity> skellat: No official 4.12 release schedule yet? :/
<skellat> infinity: That's what we're investigating
<infinity> Hrm, yeah, a lot of strikethrough on http://wiki.xfce.org/releng/4.12/roadmap
<skellat> infinity: Yeah, the wiki says one thing but the commits to the various pieces say something else.  It's been a work in progress since vUDS to find out what's happening.  It has only been a little while so we still have some time to figure things out before it gets to be a messy issue.
<skellat> And we've got another meeting in 2 weeks anyhow
<skellat> infinity: Thank you for taking the time to chat.  I gotta go spend some more time with family again.
<infinity> skellat: Happy familying. :)
<phillw> infinity: can we, at least, get a firm date for A1?
<jbicha> were any flavors even at that vUDS discussion?
<jbicha> anyway since currently we're tracking stable gnome instead of unstable gnome I don't think the specific dates matter too much this time for the gnome guys
<jbicha> except I still think late October is better than mid October for final release
<infinity> jbicha: Several were, yes. :/
<infinity> jbicha: Though some seem to have forgotten since.
<jbicha> that way we can get the 3.10.1 version of the few 3.10 things we cherrypick
<jbicha> for reference, 3.10.1 is October 16
<jbicha> although I'm guessing final release isn't still up for discussion at this point?
<phillw> jbicha: I was not aware of such a discussion, nor would I have flagged it. Certainly from lubuntu, we go with what -release team suggest and can then decide to take part, or not. (The hint is opt-in). lubuntu were not going to do A2 as our testers asked for one per month....
<jbicha> I thought Kubuntu & Ubuntu GNOME didn't participate in May's vUDS
<jbicha> I think dropping a 3rd alpha is pretty uncontroversial
<phillw> infinity: I am on the ubuntu-release mailing list, but may I humbly suggest that you also email the ubuntu-quality list, as these are the people who actually spawn the testers :)
<phillw> infinity: does https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule/phillw make any sense?
<infinity> phillw: Not in light of the discussion with ScottK, no.  I've got this, don't worry about it.
<phillw> infinity: okies. the flavours are all out of sync, I wish you well, but at the end of the day, we need at least a date for A1 setting :)
<infinity> phillw: I don't think A1 will be moving.
<phillw> yet earlier it was? A decision would be handy :)
<phillw> s/handy/useful
<infinity> phillw: I'm waiting for Scott to get back to me, but I think we've reached a decision.
<phillw> infinity: well, as the earlier idea was for https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule to be fully updated today, I'm some what puzzled.... But, Meh... these things happen. lubuntu and xubuntu were set with the schedule, and now it gets changed with no input from us? Alpha's are <<opt in >> and the two flavours have done so to the schedule.
<infinity> phillw: Dude.  Relax.  Please.
<infinity> phillw: A3 is being dropped, as was discussed at vUDS.  Other things we decided to move might not move as it would mess with Kubuntu a bit too much, and they weren't at the meeting to discuss it before.  Life will go on.  This is probably not a crisis.
<infinity> phillw: Also, I don't live in the UK, there's a lot more "today" for me still. :P
<StevenK> infinity: Don't forget "tomorrow"
<StevenK> If I keep this up, infinity is going to move the RelEng meeting to Saturday just to spite me.
<infinity> wgrant: ^-- That was an accept... What happened?
<infinity> wgrant: I was about to assume the packages timed out of the PPA, but they seem to still be there.
 * infinity tries recopying.
<infinity> Ahh, and when I copy it myself, I get a reject message.
<infinity> compiz 1:0.9.9~daily13.05.31~13.04-0ubuntu1 in raring (source contains expired files)
<infinity> Grr.
<wgrant> infinity: They're not copying from a staging PPA?
<infinity> No.  I asked them to, but they've not yet done so.  I think a second round of failed SRU attempts might convince them. :/
<infinity> This is getting tiresome.
<infinity> Bad enough that I have to jump through so many hoops to review a copy in the first place, then to have it rejected because it's not actually there anymore.  Argh.
<StevenK> We can't just un-expire SPF/BPRF when we copy them?
<wgrant> StevenK: We can't undelete files, no
<infinity> StevenK: I was assuming the above message meant things were gone from the librarian, not just disk.
<infinity> Which is a bit hard to reverse.
<infinity> wgrant: Hrm, actually, a staging PPA would get me useful diffs for review too, wouldn't it?
<infinity> wgrant: Cause copying would trigger a diff against the archive version?  Maybe?  Or is that me being overly optimistic? :)
<wgrant> infinity: I don't remember if copies into a PPA do that atm
<wgrant> I suspect not, but don't quote me on that.
<infinity> Actually, why doesn't their PPA have useful diffs anyway?
<infinity> The kernel PPA always gives me a pair of diffs, one against the archive, and one against the most recent version in the PPA (if that differs).
<wgrant> Because bug #259422
<ubot2`> Launchpad bug 259422 in Launchpad itself "display PPA diffs against Ubuntu" [Low,Triaged] https://launchpad.net/bugs/259422
 * infinity scratches his head at how the kernel PPA seems to DTRT.
<infinity> wgrant: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
<infinity> wgrant: See the pair of diffs for linux/raring.
<infinity> wgrant: That would seem to suggest that bug is fixed... For some people. :P
<wgrant> infinity: that's not because it's been copied into the primary archive?
<infinity> wgrant: I was fairly sure those diffs showed up before I copy to proposed.  Maybe I'm mistaken.
<infinity> Hard to tell right now, since everything there is in proposed. :/
<wgrant> linux_3.8.0-23.34_3.8.0-25.37.diff.gz is substantially newer
<wgrant> Look at the LFA IDs
<wgrant> 141820015 vs 142361264
<infinity> Hrm.  Kay.  Maybe I'm mistaken, then.  Oh well.  Would be a great feature to have. :P
<infinity> I'm now going to go be grumpy and frustrated that I wasted an hour reviewing packages I couldn't accept.
<infinity> Maybe gin will help.
<StevenK> infinity: Gin always helps?
<wgrant> Heh
<infinity> StevenK: Generally.
<infinity> Ginerally?
<infinity> Maybe if I mix gin, a shiraz, a belgian blonde, and some cheesecake, I can have all of my favourite things in one place.
<infinity> It'll be awesome.
<infinity> Or I'll die.
<infinity> Taking bets now.
<StevenK> infinity: ... Mixing how? One night, or a blender?
<StevenK> infinity: And is Australian lamb missing from that list?
<ScottK> cjwatson and infinity: Thanks for offering to be flexible.  I've been really busy with $work this week, so I think Riddell is a better judge of where we are on packaging 4.11 Beta 1 and which week is better for Kubuntu for having Alpha 1.
<seb128> infinity, hey, I read the backlog after wondering why the unity SRU vanished from the queue ... is that ok if we just republish a round without a staging ppa?
<seb128> infinity, we have graphical corruption on a range of video cards that is waiting for a fix for over a month, I would like to get those fix in without having to block on infra changes from didrocks' side
<seb128> infinity, it's getting a bit ridiculous that we have our default desktop known to be broken on some machines with a fix available and it's taking us over a month to land the SRU :/
<Mirv> like I messaged infinity, the files actually don't seem like expired this time around, yet, look at for example https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3234004/+listing-archive-extra
<Mirv> it does say 'removed' at the top (only 5 days after the build), but the files are still there at the bottom and downloadable, unlike for the week older packages
<Mirv> so it should be looked for the next time how those files can be retrieved, but since these syncs were rejected and we can't re-establish the sync request, we need to do manual reuploads of the 13.05.31 packages anyhow
<wgrant> Mirv: Sort of, the files don't actually get removed immediately, but they're half way through the removal queue so it still won't let you publish them in new places
<wgrant> Because once they're condemned for deletion it's not possible to unqueue them.
<wgrant> I'd really recommend you copy them from a staging PPA
<Mirv> wgrant: right, even though they stay there for over two weeks after being marked for removal.
<wgrant> Copying a package that doesn't actually exist any more sounds like a recipe for trouble :)
<Mirv> 5 days is too little, SRU Team cannot be expected to do review in that time, so yes it needs to be changed
<wgrant> Mirv: They become candidates for total deletion a week after they're not published anywhere any more
<wgrant> Then it can take a few days for them to progress through to actually being removed from the librarian
<Mirv> I've actually the 13.05.31 release at https://launchpad.net/~unity-team/+archive/sru/+packages?field.name_filter=&field.status_filter=published&field.series_filter=raring , so we'll probably get to reupload those
<wgrant> This is not something that will change in Launchpad; what you're doing is unsupported, and you'll need to use a staging PPA.
<wgrant> Plus a staging PPA will make it easier to review :)
<Mirv> ok, I'll let people know. I'm all for staging PPA, it just needs to be automated somehow to make those "blessed by us" snapshots from the daily-build PPA
<wgrant> Well
<wgrant> Does it need to be automated any more than the copies into the primary archive do?
<wgrant> Just turns "copy from daily PPA to primary archive" into "copy from daily PPA to staging PPA, copy from staging PPA to primary archive"
<seb128> yet another ppa (tm)
<seb128> but I guess that's easy enough
<seb128> that system has soon 5 layers on ppa though
<Mirv> yeah, well blessing current day's releases is just a matter of LP copy, true. so maybe nothing to do, except if wanting for some reason to bless an earlier, superseded release (LP doesn't allow copying those, even though it allows initiating the copy)
<seb128> non-verificated->verified->published->copied-for-archive->archive
<wgrant> You can copy a superseded one
<wgrant> You just can't copy one that's been superseded for more than a week
<Mirv> wgrant: no, it gives an error at the targe PPA
<Mirv> wgrant: ah, right..
<wgrant> I wrote the code, I know the rules :)
<Mirv> that explains it :)
<StevenK> seb128: Sure, but you keep superseding old releases by uploading new ones
<wgrant> Things are copyable as long as they've never not been published anywhere for more than a week at at time
<seb128> StevenK, yeah, I guess I wish that ppa copies were actual copies
<seb128> not symlinks to targets that might go away
<wgrant> seb128: PPA copies are, unreviewed queue copies aren't
<wgrant> Not ideal, but not easy to fix without significant model reworks, and easy to work around.
<seb128> right, that seems fair enough, some easy having for didrocks next week I guess
<skaet> infinity, if date for A1 is changing why wasn't there a mail-out discussion on the ubuntu-release mail list.
<skaet> ??
<skaet> ScottK,  from discussions I had with Riddell yesterday,  Kubuntu is going to be participating.
<rtg_> infinity, after looking at Britney update_excuses.html I still don't get why linux-mako/linux-manta are stuck in -proposed.
<cjwatson> You must read update_excuses.html and update_output.txt together - they're two phases of checks
<cjwatson> Though, OK, not an issue here
<cjwatson> That looks like it's the same NBS-in-proposed problem as yesterday.  I'll confirm and sort it out
<rtg_> cjwatson, ok. in this case update_output.txt didn't have anything in it that made sense (which is why I asked I guess)
<cjwatson> Yeah, sorry, that was a knee-jerk :)
<cjwatson> linux-{mako,manta} binaries are still in NEW, if nothing else
 * cjwatson processes
<rtg_> thanks
<cjwatson> That ought to be enough, I believe
<rtg_> cool
<skaet> stgraber,  from discussions with highvoltage,  Edubuntu is not participating.
 * skaet was working through some of the day-7 tasks yesterday,  and planed a mail out to ubuntu-release later today,  to figure out opt-in.       
<skaet> Will hold off on email until I understand a bit more on the date churn I've seen from discussion between ScottK, infinity in the backscroll
<ScottK> I think we need to decide if this is day -7 or not first.
 * ScottK is waiting for Riddell to appear and voice an opinion.
<Riddell> hello
<Riddell> I think we should do it
<ScottK> Riddell: When?
<ScottK> Are we OK with moving it a week later?
<Riddell> yeah that's fine
<ScottK> infinity: ^^^ There's your answer.
<ScottK> skaet: ^^^ I guess we're at -14, not -7.
<Riddell> since we're not yet done with beta 1 and upstream doesn't seem to give us any packaging time now we can do our alpha then get back to upstream's beta
<skaet> ScottK, Riddell, infinity - ack.   I'll go in and change the schedule then later.
<infinity> Riddell, ScottK: Lovely, I'll push that change out in a second, then.
<balloons> we think we're done editing the schedule now :-p
<balloons> ?
<infinity> balloons: Yep.  My bad for not getting full concensus and editing it earlier.  Should be all finalized now.
<balloons> no worries infinity I was just thinking I was crazy and had imagined the conversation at vUDs
<infinity> balloons: You might still be crazy, but you didn't imagine the meeting. :)
<balloons> :-)
<jbicha> uh in the past there have been problems having UI Freeze the same day as Docs Freeze; how can the Docs Team document things that haven't landed
<infinity> jbicha: Hrm.  I suspect there may be overload as to what constitutes a "docstring".
<jbicha> maybe the Unity (and related projects) won't land significant UI changes the night of UI freeze (or a week or two later) any more :)
<infinity> A man can dream.  Anyhow, freezes are always a bit flexible if one can show things like "this documentation is clearly out of whack with reality".
<infinity> And, I've always taken doc string freeze to be an internal string freeze for software docs, and shipped things like the slideshow.  External docs should be living, breathing things, and the idea of freezing them at all is probably silly.
<infinity> In that sense, it makes sense for a UI and string freeze to be bundled in one, since strings in UIs are the very things we don't want changing before translators get their hands on them.  But I can see the inverse interpretation too, that it's only about docs for software, not docs from software.
<infinity> jbicha: Anyhow, of all the changes we made, that one's likely the most flexible, and I don't think anyone's keen on arbitrarily hamstringing documentation one way or the other.  And that's something we can discuss right up to release, nearly.
<ScottK> "how can the Docs Team document things that haven't landed" <-- The same way the always do when stuff lands late.   ;-)
<infinity> ScottK: Clairvoyance?
<ScottK> Dunno, I'm not on the docs team.
<infinity> Probably the most important skill to list on a tech writer job req, yet I never see it listed.
<ScottK> I am loving all the back slapping from the Unity team on how complete and stable the 100 scopes stuff is in Saucy when the only reason it didn't go into Raring (and be late/immature/the usual stuff) is we told them no.
<infinity> ScottK: Aww, let them have their fifteen minutes.  Everyone likes to brag about doing something right, even if it's done right because someone made them. ;)
<cjwatson> Yeah, this is a much better result than them seething with resentment
<infinity> Damn my eyes.  I read that as "teething with resentment" on the first pass.
<ScottK> That's why I'm venting a bit here instead of on planet.ubuntu.com.
<ScottK> I'm pretty sure children actually do that.
<cjwatson> Oh yes they do
<cjwatson> Also fire and the sword
 * ScottK defers to cjwatson's more recent experience.
<bdmurray> infinity: I was thinking about turning on apport's crash reporting to Launchpad now, additionally I think it could happen earlier in the cycle than in the past due to quality improvements.
<infinity> bdmurray: I have almost zero opinion on the topic, I'd recommend running it past pitti.
#ubuntu-release 2013-06-15
<Laney> I ran out of time chasing this down, but I think that gcj-4.8 being in universe is making db5.3 FTBFS
<Laney> will dig more later if required
<infinity> Laney: ?
<infinity> Laney: If it has a build-dep on it, that would show up in c-m.
<infinity> Laney: Oh, wait, some stuff wants to be promoted again.  Fun.
 * infinity fixes.
<infinity> Laney: Thanks for the heads-up.  Will be fixed in an hour or so.
<phillw> just in case there is a release team person about, Lubuntu is now opt-in for all the alpha's and beta's.
#ubuntu-release 2013-06-16
<ogra_> hmm, cadejo seems stuck ... there is a bunch (5) of piled up BuildLiveCD processes hanging around on nusakan
<ogra_> ARGH ...
<ogra_> 2013-06-15 17:14:17] lb_clean noauto --all
<ogra_> P: Cleaning chroot
<ogra_> Segmentation fault
<ogra_> [2013-06-15 17:14:21] lb_config
#ubuntu-release 2014-06-09
<pete-woods> hi there release folks! can anyone spare some time to look at my HUD upoad in trusty?
<xnox> How to force-sync libusbmuxd from sid into utopic-proposed? src:usbmuxd got split into two src packages in debian and we want to sync both across.
<sil2100> infinity: hi! Are you around by any chance? Our standard core-dev responsible for CI Train packaging ACKs is off and we would need someone to +1/-1 a change before publication :)
<sil2100> infinity: would you have a moment for that?
<sil2100> Oh, and actually I need some archive admin as well
<cjwatson> what's the change?
<sil2100> cjwatson: it's a big diff, I already browsed through it and it looked safe: https://ci-train.ubuntu.com/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.23+14.10.20140609-0ubuntu1.diff
<sil2100> cjwatson: there is a new binary package there as well
<cjwatson> sil2100: Is libqt5sql5-sqlite some kind of plugin that can't be detected with shlibdeps?
<sil2100> cjwatson: oh, I actually mis-read that for QML bindings, but I see now that it's actually a normal lib, hm
<sil2100> cjwatson: let me check that up
<cjwatson> sil2100: qtdeclarative5-ubuntu-web-plugin being Multi-Arch: same looks very fishy; it's not structured like a usual M-A: same package
<cjwatson> sil2100: wait, belay that, I'm reading the wrong bit of the file listing
<cjwatson> sil2100: ack (both ~ubuntu-core-dev and ~ubuntu-archive) - I think this is fine
<cjwatson> just double-check that there isn't a better way to do the libqt5sql5-sqlite dep
<sil2100> cjwatson: I can poke the upstream developer about that libqt5sql5-sqlite dep, but since I don't see it in any CMake files, I think it might not be easily detectable
<cjwatson> oh, -sqlite is in fact a plugin
<sil2100> I can't remember how Qt DB support works, but it might be plugin-based
<cjwatson> cjwatson@pepo:~$ dpkg -c ubuntu/pool/main/q/qtbase-opensource-src/libqt5sql5-sqlite_5.2.1+dfsg-1ubuntu17_i386.deb | fgrep .so
<cjwatson> -rw-r--r-- root/root     51196 2014-05-13 05:43 ./usr/lib/i386-linux-gnu/qt5/plugins/sqldrivers/libqsqlite.so
<cjwatson> that's fairly clear :)
<sil2100> cjwatson: thanks for the review :)
<sil2100> o/
<cjwatson> and no shlibs control file in the .deb, so there won't be a better option for this
<cjwatson> glad to see the new-binary-package check in citrain there
<sil2100> Yeah, I added that since it was really easy to forget about archive-admin-poke whenever a new binary package pops up
<cjwatson> Hopefully I'll figure out the remaining issues with my copies-respect-new branch this week
<cjwatson> If I can remember what my plan for fixing the ancestry calculation was
<Trevinho> slangasek: I've checked the errors you pointed out last week, that seems to be related to the latest unity SRU, but really nothing changed on our code might cause them... :/
<Trevinho> was the security uploaded package already tracked for these errors, right?
<slangasek> Trevinho: I believe the security pocket also gets error reports against it, yes; in any case, that security update had also been copied to -updates and was there for a month, so definitely would have had crash reports against in
<slangasek> s/in$/it/
<slangasek> Trevinho: could this have been caused by code changes nearby that changed the stack signature of an existing crash?
<Trevinho> slangasek: mh, I'd say no as nothing seems related to these calls... but I'd wait for better stack trace since the ones we have are partially incomplete
<Trevinho> and anyway while one crash can be avoided (as it's triggered by gdk on X errors), the other one is really happening when setting up the the unity super short-cuts which are there since years
<slangasek> Trevinho: what trace is partially incomplete?  You're not going to have a better stack trace coming
<Trevinho> slangasek: https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95
<Trevinho> slangasek: there are no nuch infos about the unity code
<slangasek> Trevinho: right, but there's not going to be a better backtrace coming either.  I don't know why it's giving "no symbol table info available" for the unity calls...
<slangasek> bdmurray: ^^ do you know if this is related to ddeb availability?
<slangasek> I would have thought that, without ddebs, it would refuse to retrace at all
<Trevinho> slangasek: there is a similar issue also in other errors (such as https://errors.ubuntu.com/problem/1e4a09ec7376628035e64b1600bef4e3c5b36d93 )
<Trevinho> that's still from 13.10
<bdmurray> slangasek: not off the top of my head, but the stacktrace on a bucket page is the first one that did retrace
<bdmurray> slangasek: I think bjoern mentioned something about the line numbers being off in his email to ubuntu-devel - that's the same issue
<slangasek> well, in this case the crash has only ever been seen in a single versino
<slangasek> version
<slangasek> the fact that the backtrace includes a function name for the unity components implies that it's getting at least some debugging information
<bdmurray> slangasek: I'm bit involved in the cassandra migration at the moment. Maybe its some non standard compiz plugin?
<slangasek> bdmurray: the missing symbols relate to the unity .so itself
<slangasek> but maybe they're not actually "missing", I'm not sure
<bdmurray> slangasek: this is the problem yes? https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95
<slangasek> bdmurray: yeah
<bdmurray> and lines 26,27,31,32 are the concerns?
<bdmurray> or something else?
<slangasek> bdmurray: those addresses are clearly outside of any DSO; the bit I was looking at was frame 9, "No symbol table info available"
<slangasek> but maybe Trevinho was talking about 26,27,31,32
<slangasek> Trevinho: ?
<Trevinho> slangasek: mostly 9
<slangasek> ok
<Trevinho> slangasek: as basically all the reports we get about unity don't include local variables or line numbers
<bdmurray> it'd be interesting to know if that is true in Launchpad too
<Trevinho> bdmurray: generally stacktraces in lp are more informative
<bdmurray> Trevinho: an example would be helpful
<bdmurray> Okay, I found one
<Trevinho> bdmurray: ok, nice as the lp timeouts were blocking my searches here :/
<bdmurray> bug 1328180
<slangasek> Trevinho: yet another new crash: https://errors.ubuntu.com/problem/f5a955d67c42bb688386e1fa695af37cfe9ee20a
<slangasek> same issue with symbol table info
<slangasek> I wonder if this is something about the way unity is built
<Trevinho> slangasek: I've no idea... these stacks also seems to be unrelated...
<Trevinho> I mean, I get the computeGlowQuads call and then the Launcher::EmitEneedsRedraw but there's really no connection or call path between them
<Trevinho> nor with the final destructor... It looks like there's something messed up with the stack
<Trevinho> and still there are a lot of missing intermediate frames...
<Trevinho> also I don't think we changed the way we build unity..
<Trevinho> bregma: any idea?
<bregma> we definitely didn;t change anything in the way we build things
<bregma> other than using ci-train instead of a distro builder
<bregma> I suppose that could make some sort of difference, but is beyond my kenning
<Trevinho> yeah, the same I knew... But these errors are quite weird... Nothing seems related to anything changed. And also inside the errors themselves there are unknown code paths
<slangasek> well, I don't know that it's a matter of the unity build having /changed/.  Were you previously getting better backtraces from errors.u.c?
<slangasek> this latest one shows a code path that goes via __GI___pthread_mutex_lock, that certainly looks dodgy
<bdmurray> The bug I reported (1328180) has something and examples in it
<slangasek> bdmurray: when you say "done against (13.10|14.04)", is that about the versions of the packages being retraced, or the version of gdb, or both?
<bdmurray> the former for sure, the latter I'm not certain
#ubuntu-release 2014-06-10
<zequence> Would someone who knows seeds mind to take a look at the Ubuntu Studio seeds? I've been comparing them with others, and some things don't seem to make sense.
<zequence> The bzr repo is at lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.utopic
<zequence> Particularly the ship and dvd seeds, and how they are don in STRUCTURE
<zequence> How is ship put on the ISO? Is it put on the ISO at all?
<zequence> I'm guessing it wouldn't need "di-requirements"
<darkxst> anyone around that can bump libmutter0d through new?
<cjwatson> cdimage puts everything in ship on the ISO
<cjwatson> see lib/cdimage/germinate.py in lp:ubuntu-cdimage
<cjwatson> that's the *point* of ship :)
<zequence> cjwatson: Ok, thanks. So, some seeds are special - which I've read about, but haven't understood exactly how
<cjwatson> (however if it's a live image then ship-live is used instead)
<zequence> cjwatson: Ok, so in our case, we have a live DVD. How does that work?
<cjwatson> don't quite have time right now, could you read through the code reference I gave to start with?
<cjwatson> the cd-live seed looks like a misplaced guess at least
<zequence> cjwatson: It's for a new CD we want
<cjwatson> should be ship-live
<zequence> I've looked around in ubuntu-cdimage, and I guess I could continue with that. But, really, all I want is for our seeds to make sense and that we get a new CD built further on
<cjwatson> I don't recall how the dvd-live seed gets used, but I added it originally so it must have made sense :)
<cjwatson> some of the seeds get turned into metapackages or tasks and used from there
<cjwatson> for live-type seeds it's usually tasks
<zequence> Yes, I know about that. And, I've prepared one new meta, which isn't updated in the meta source yet
<cjwatson> but ship-live-type things are different - those are "the live image needs these additional .debs in a pool on the ISO, outside the squashfs"
<cjwatson> dvd-live looks like it's more like live than ship-live
<cjwatson> and I withdraw my earlier comment about cd-live - it's not ship-live, should probably just be "live"
<cjwatson> (if it's not clear, the reason you need different seeds for the CD and DVD cases there is because even though they have the same top-level contents they may have different dependency expansions depending on what they inherit from)
<zequence> The problem is in STRUCTURE though. if live inherits from all our multimedia seeds, and both a CD and a DVD inherits from live, won't all the multimedia packages get installed on both ISOs?
<cjwatson> you clearly need different live seeds for CD vs. DVD
<cjwatson> since they will usually have different inheritance
<zequence> Good. So, so far, I've been doing it somehow right then :)
<cjwatson> but I'd prefer the naming to be regular across flavours wherever possible, please
<cjwatson> so rename cd-live to live
<cjwatson> makes my life easier
<zequence> ok, and dvd-live?
<cjwatson> leave that as it is
<zequence> ok, and if we wanted a new CD built right now - do I need to do anything else?
<cjwatson> is the new metapackage you're talking about "ubuntustudio-live"?
<zequence> no, ubuntustudio-audio-core
<cjwatson> ah, ubuntustudio-live is a real package, confusing but ok
<zequence> I also added desktop-minimal, but I'm not intending to make that an installable package
<cjwatson> (which is fine, there shouldn't normally be a metapackage equivalent of live-type seeds)
<cjwatson> zequence: rightly so
<cjwatson> zequence: adding image builds will take some work from me, but I think the seeds are mostly in shape now (with that renaming) to make that workable
<zequence> I copied ubuntustudio-live from edubuntu pretty much. I could change the name to -live-settings
<cjwatson> *shrug*
<zequence> cjwatson: Ok, so should I post a mail, or something to ask for a new ISO build?
<cjwatson> yeah, mail me please or add a work item for me on a blueprint or something
<zequence> cjwatson: Alright. Thanks a million!
<cjwatson> I don't have a problem with doing it as long as you guys have QA capacity for it around releases
<zequence> Won't be a problem :)
<cjwatson> darkxst: done
<darkxst> cjwatson, thanks!
<zul> can someone reject testresources please?
<Trevinho> bdmurray: hey, could you please check https://bugs.launchpad.net/ubuntu/+source/vdpau-video/+bug/1222790 again? the build failure should be fixed by https://bugs.launchpad.net/+branch/~3v1n0/ubuntu/trusty/vdpau-video/remove-va-constants/+merge/219436
<bdmurray> Trevinho: by check do you mean you'd like me to merge and sponsor it or something else?
<Trevinho> bdmurray: merge and sponsor :)
<bdmurray> Trevinho: I'll try and get to it
<Trevinho> bdmurray: thank you
<rtg> I uploaded tboot-1.8.1 90 minutes ago and have yet to receive an email, nor can I see it in the Utopic queues. Any thoughts ?
<rtg> Successfully uploaded tboot_1.8.1-0ubuntu1.dsc to upload.ubuntu.com for ubuntu.
<rtg> Successfully uploaded tboot_1.8.1.orig.tar.gz to upload.ubuntu.com for ubuntu.
<rtg> Successfully uploaded tboot_1.8.1-0ubuntu1.debian.tar.xz to upload.ubuntu.com for ubuntu.
<rtg> Successfully uploaded tboot_1.8.1-0ubuntu1_source.changes to upload.ubuntu.com for ubuntu.
<stgraber> there was some disk space problems with the ftpmaster around that time, might be related
<stgraber> cjwatson: ^
<rtg> stgraber, shall I just fire it up again ?
<cjwatson> er, possibly, sorry
<cjwatson> one sec
<cjwatson> I'll just check the logs
<cjwatson> 2014-06-10 13:28:10 DEBUG   dpkg-source failed for tboot_1.8.1-0ubuntu1.dsc [return: 29]
<cjwatson> 2014-06-10 13:28:10 DEBUG   [dpkg-source output:   dpkg-source: info: extracting tboot in tboot-1.8.1
<cjwatson> 2014-06-10 13:28:10 DEBUG     dpkg-source: info: unpacking tboot_1.8.1.orig.tar.gz]
<cjwatson> yeah, sorry about that, just reupload
<rtg> can do. thanks.
<cjwatson> looks like the only affected upload
<cjwatson> (I accidentally filled up /)
<rtg> sucks to be me :)
<arges> if something is in utopic-proposed (not sure how that happened), what process shoudl be used to get it into -updates? (looking at audacity fwiw)
<cjwatson> nothing should go into utopic-updates
<cjwatson> utopic-proposed is managed automatically by proposed-migration; you shouldn't touch it as an SRU admin
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#audacity
<cjwatson> It's part of the big libav transition which needs to go in as a unit
<cjwatson> https://wiki.ubuntu.com/ProposedMigration to understand how this works
<arges> cjwatson: thanks
<cjwatson> ... since you're an archive admin, you shouldn't generally touch it manually as that either :)
<cjwatson> it does sometimes need hints but those are usually handled by the release team
<arges> cjwatson: well i was just going through the review queue and saw audacity sru for trusty, but it wasn't fixed for utopic and rmadison showed the utopic-proposed version.
<cjwatson> right
<cjwatson> but it would be actively harmful to copy it into utopic right now, as it'll be uninstallable until the whole of libav can land
<arges> gotcha; i won't touch it : ) that's why I asked here
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libav10.html  still some way to go by the looks of things :-/
<Laney> arges: https://launchpadlibrarian.net/177112196/webkitgtk_2.4.3-1ubuntu2_source.changes has a bug reference already because I uploaded with -v
<Laney> arges: Maybe we need to un-SRUify it?
<Laney> (See Launchpad-Bugs-Fixed there)
<arges> Laney: ahh sorry I just looked at the changelog
<Laney> it's possible that the tool will think it's already in proposed
<balloons> cjwatson, infinity perhaps someone else.. Do we archive the ubuntu-touch images in the same way as our desktop images? I need the manifests of some older builds that what is on cdimage atm
<cjwatson> I don't archive the desktop images; I don't know who does
<cjwatson> If all else fails, you can scrape the same data out of http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ with a bit of work
<cjwatson> And .../cd-build-logs/
<Laney> arges: can you accept that from rejected or shall I reupload?
<balloons> ty cjwatson
<arges> cjwatson: can I accept an SRU from rejected (that I rejected)? or will that cause mass chaos
<cjwatson> Should be fine
<arges> Laney: re: 1326359, is it fixed for utopic or not?
<Laney> arges: I see what you want me to do. :)
<Laney> there we go
<arges> Laney: cool. : ) just being careful on my end
<arges> Laney: ok updated for trusty. sorry about all the confusion
<Laney> no worries, thanks for looking again
<Laney> denial of servicing a buildd network near you in 3, 2, 1
<arges> hmm so webkitgtk was moved into Done; but I don't see it in rmadison yet and queuebot hasn't said anything yet
<arges> anyway, listening to talk
#ubuntu-release 2014-06-11
<kees> is anyone around to hit this one?
<kees> 21:09 -queuebot:#ubuntu-release- Unapproved: duo-unix (precise-proposed/universe) [1.7-3 => 1.9.11-1~ubuntu0.12.04.1] (no packageset)
<infinity> kees: Hit it in what sense?
<infinity> kees: The bug doesn't seem to justify the backport?
<infinity> kees: How does "changing certificates" lead to "need to backport all the new code"?
<kees> infinity: because their server is dropping connections based on versions. since the code changes are well tested and relatively small, it seems best to just catch up precise instead of doing a hacky cert-and-fake-version bump on the protocol.
<kees> infinity: and "hit" in the sense of no one appears to have looked at it from approve or reject
<infinity> stgraber, slangasek, cjwatson, RAOF, ScottK, any of you around?
<slangasek> infinity: yabbado
<cjwatson> Slightly but mostly trying to do QA on the PPA publisher before going back to bed
<infinity> slangasek: So.  docker versus docker.io... There's an ongoing thread about docker.io taking over docker(1) and docker moving to wmdocker(1)
<slangasek> oh, is this still ongoing?
<infinity> slangasek: paultag just uploaded a docker 1.5-1 that does the wmdocker(1) move, and I'm considering just syncing that to trusty.
<infinity> slangasek: Any objections?
<cjwatson> I would object in some such cases, but in this one it seems relatively unlikely that people will be invoking it by name?
<infinity> slangasek: (The second half being a longer discussion about docker 1.0 in trusty, but I think that'll turn out to look like a Good Idea from a supportability standpoint)
<slangasek> syncing it to /trusty/?
<infinity> slangasek: To trusty, yes.
<cjwatson> I'd prefer a cherry-pick to a sync though
<cjwatson> If possible
<infinity> slangasek: Argument being that 1.5-1 has nearly zero changes relative to 1.4-5, except for the inclusion of the Ubuntu patch, the inclusion upstream of a Debian patch, and the binary move.
<slangasek> nearly zero is like nearly infinite
<infinity> cjwatson: And the reason for the sync instead of the cherrypick would be to keep the Breaks/Replaces in sync with Debian as well.
<cjwatson> Oh
<cjwatson> I can see the argument there
<cjwatson> We might want to build1 it in utopic in that case, dunno
<infinity> cjwatson: We might.  I'm not sure it matters much.  The current version hasn't rebuilt since natty, it's not like this one gets a lot of attention.
<kees> bdmurray: precise and saucy micro updates for duo-unix have landed now. Waaaay easier delta to review. :) (debdiffs added to the LP bug)
<infinity> cjwatson / slangasek: I can cherry-pick just the binary/manpage move, if you prefer, but I think in this weird case of a leaf package that likely almost no one uses with Ubuntu anyway (and in light of keeping b/r in sync), we're better off just taking the Debian package wholesale.  YOMV.
<slangasek> infinity: I'm more intersted in knowing what else was is in the delta that we might consider risky
<infinity> slangasek: http://paste.ubuntu.com/7631006/ <-- The entire diff between trusty and sid.
<slangasek> what the heck is debian/Dockerfile ?
<infinity> slangasek: A joke, AFAICT.  Allows one to build docker in docker.
<infinity> slangasek: Harmless cruft, from the POV of the Debian packaging, mind. :P
<slangasek> very funny
<slangasek> infinity: no upstream changelog, bah; but the changes do seem fairly innocuous, either the thing works with these changes or it doesn't
<slangasek> I assume someone will test that it does actually work, before we publish to -updates :)
<infinity> Yeah.
<infinity> I'll make sure Paul's tested it before I sync, and then test on Ubuntu before releasing.
<infinity> I miss WindowMaker.  It'll be fun revisiting the past.
#ubuntu-release 2014-06-12
<infinity> slangasek: Alright, Paul tells me he tested the Debian upload, and it built fine on all arches, so a +1 on syncing to trusty, and then I'll find a time machine and do some testing on Ubuntu too?
<infinity> Well, once LP learns about it, so it can do the copy...
<tseliot> hi, can an admin reject ubuntu-drivers-common from trusty-proposed, please? (I'd like to add one more small fix)
<tseliot> infinity: ^
<RAOF> tseliot: Sure.
<tseliot> RAOF: thanks!
<Riddell> what would it take to make a kubuntu-plasma5 flavour which was built with a PPA?
<Riddell> Laney: how's the unity 8 flavour doing?
<Riddell> (I would like to point out we were planning on a plasma5 flavour before you announced that one :)
<Laney> Riddell: there's no PPA involved there
<Riddell> Laney: ah, it's all in the archive?
<Laney> yep
<Laney> I think cjwatson's new stuff might help you in this regard somewhat
<Laney> Riddell: btw, are you aware that kubuntu-active images are failing to build?
<Laney> Riddell: because kmail-mobile and kdepim-mobileui-data have a file conflict
<Riddell> gosh are they still trying to build?  I should probably stop them, it's not usable
<Laney> Still seems like a bug. :)
<Riddell> cjwatson: what's the magic new stuff to make images buildable with PPAs?
<seb128> Riddell, https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038267.html
<Riddell> thanks seb128
<seb128> yw!
<Riddell> Laney: this is your unity8 flavour? http://cdimages.ubuntu.com/ubuntu-desktop-next/daily-live/current/
<Laney> Riddell: yup
<Laney> Riddell: It doesn't work atm
<Riddell> Laney: how did you build it? just editing cdimage scripts or is there a newer more fancy way?
<Laney> wrong type of snow on the ci train line etc
<Laney> cdimage, launchpad (to generate Task:) and livecd-rootfs
<Laney> and I think cjwatson did some bits to debian-cd behind the scenes too
<Laney> and adding the product to the ISO tracker
<shadeslayer> Laney: cjwatson I thought that unity8 was going to be delivered via PPA;s
<shadeslayer> or atleast that's what I recall from the ML discussion
<Laney> Not for this flavour at any rate
<Laney> There might be some ideas floating around about how to get it running on 14.04 that involve PPAs, not sure about that
<seb128> see https://lists.launchpad.net/ubuntu-phone/msg08410.html
<seb128> the ppa option got flagged as "shelved" in there
<shadeslayer> ok, I keep messing up derived distribution and ppa >.>
<cjwatson> Riddell: it's not in place yet, please ask later
<shadeslayer> anyway, IIRC cjwatson had some tooling done to make ISO's from PPA's I think, will wait for him to get back
<shadeslayer> oh ^^
<cjwatson> Riddell: it'll require https://code.launchpad.net/~cjwatson/launchpad-buildd/livefs-extra-ppas/+merge/220109 and then we can set EXTRA_PPAS in the environment when running a livefs build
<cjwatson> from cdimage
<cjwatson> will probably refine that later
<cjwatson> only works as long as the PPA's only needed for the livefs though; if it's needed on the pool on the ISO then that will take some more work
<Riddell> cjwatson: ooh interesting, thanks
<cjwatson> Riddell: more importantly it requires https://code.launchpad.net/~cjwatson/launchpad/db-livefs/+merge/217206 https://code.launchpad.net/~cjwatson/launchpad/livefs/+merge/217261 https://code.launchpad.net/~cjwatson/launchpad/livefs-garbo/+merge/217784 https://code.launchpad.net/~cjwatson/launchpad/livefs-browser/+merge/219505 :-)
<robru> cjwatson, can you check on platform-api in proposed? excuses says valid candidate but it's been sitting for a while.
<seb128> robru, see #ubuntu-ci-eng
<seb128> that's being discussed there
<seb128> robru, you should know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt by now no?
<robru> seb128, yeah I just forget
<robru> seb128, also no idea how to interpret it
<cjwatson> robru: https://wiki.ubuntu.com/ProposedMigration has some interp advice fwiw
<robru> cjwatson, thanks
#ubuntu-release 2014-06-13
<sil2100> seb128: hey! Do you think you would have a moment today to NEW net-cpp for utopic? :)
<seb128> sil2100, hey, I can have a look, was it preNEW reviewed by somebody before upload?
<sil2100> seb128: not really, didrocks mentioned that preNEWing is not required anymore for new source packages as they anyway need to be NEWed as normal packages - but I had a look at the packaging some time before and things looked really ok
<sil2100> seb128: thanks!
<seb128> sil2100, well, preNEWed is useful to minimize silo locking
<bdmurray> slangasek: can you run the following? change-override -s trusty-updates -S -z 50 qemu (the phased-updater would do it eventually but it might be nice to give it a head start)
<slangasek> bdmurray: done
<bdmurray> slangasek: and kde-workspace to 10% again
<slangasek> bdmurray: ok, done
<stgraber> oops, wrong series, let me reject that.
<bdmurray> slangasek: could you fully phase nautilus? I've looked at all the errors and they aren't regressions and the package version is the second SRU in trusty-updates so we are unlikely to receive bug reports about the previous version since its not installable. The bug seems some important and I'd likely just have to override most of the regressions.
<infinity> bdmurray: It's at 0% now?
<infinity> bdmurray: Oh, was that because you were investigating?
<infinity> bdmurray: Bumped to 100%
<bdmurray> infinity: Thanks. The phased-updater had stopped it mostly because of the database switch.
#ubuntu-release 2014-06-15
<stgraber> that's the first LXC 1.0 SRU to trusty, let me know if you have any question. The goal is that once accepted, tested in -proposed and landed in -updates, this will then get backported (in place of the current LXC alpha we've got in -backports there) to all >= 12.04 supported releases
<michagogo> !info lxc precise
<michagogo> !info lxc
 * michagogo tries to poke ubottu, only to discover that nick completion fails
<ScottK> michagogo: Probably because a major Canonical data center is down.
<michagogo> ScottK: ah, that's not good
<michagogo> How come?
<ScottK> Dunno.  The people who do are all probably busy trying to fix it.
<michagogo> Fair enough.
<michagogo> If any of you are in here: good luck!
<stgraber> michagogo: as for your query, we've got LXC 0.7.5 by default in precise with 1.0.0~alpha1 currently in precise-backports. I intend to replace the latter by LXC 1.0.4 once it's first been pushed to trusty.
<stgraber> michagogo: LXC 1.0.4 for precise can already be obtained from ppa:ubuntu-lxc/stable (should be identical to what will land in trusty and precise-backports), though you may have a hard time adding that ppa at the moment since apt-add-repository depends on the Launchpad API which is down due to the DC network outage
<michagogo> stgraber: I thought it was add-apt-...?
<DalekSec> ScottK, michagogo: Most ubot* bots are hosted on a donated Rackspace server.  The one that was in here, ubot2, was on another host that disappeared a few months ago.
<DalekSec> /usr/bin/apt-add-repository -> add-apt-repository it's a link, either works.
#ubuntu-release 2015-06-08
<utlemming> Would someone be willing to promote the cloud-init SRU's from -proposed? They've sat now for 9 days.
<micahg> can I please get SRU team input on this question: https://bugs.launchpad.net/ubuntu/utopic/+source/lua-json/+bug/1443288/comments/8
<ubot93> Launchpad bug 1443288 in lua-json (Ubuntu Utopic) "Unusable in Trusty; upgrade to 1.3.2" [Undecided,Fix committed]
<micahg> is the proposed migration working?
<micahg> seems like the proposed-migration and excuses haven't been updated for about 6 hours
#ubuntu-release 2015-06-09
<infinity> micahg: Last run was 7m ago, so I guess it cleared up?
<micahg> so it seems :), thanks
<GunnarHj> Anybody who can accept the ubuntu-docs package in the vivid upload queue? Needs to be built this week.
<cjwatson> wait what
<cjwatson> bah
<jamespage> ^^ those two new python-oslo.XX packages are source package renames from Debian
<jamespage> I'll raise a bug to get the old ones removed in wily
<micahg> arges: would you have a moment to look at this please? (SRU question) https://bugs.launchpad.net/ubuntu/utopic/+source/lua-json/+bug/1443288/comments/8
<ubot93> Launchpad bug 1443288 in lua-json (Ubuntu Utopic) "Unusable in Trusty; upgrade to 1.3.2" [Undecided,Fix committed]
<arges> micahg: looking
<arges> micahg: so the fix for lua 5.2 can't just be added to 1.3-1ubuntu0.1 as a patch easily?
<micahg> I'm not sure if there's a smaller patch or not, but it seems the whole 1.3.1 release was for lua5.2 compatibility
<arges> micahg: yea looks like it
<micahg> so, it would seem that's important for the LTS
<arges> micahg: so seems reasonable as the update is a bugfix-only update.
<micahg> ok, so I'm ok to backport the utopic SRU then, it's 1.3.1 + the fix for the bug in question
<arges> seems reasonable to me
<micahg> ok, thanks
<micahg> re ^^ give me one second to double check that fixes the issue
<micahg> yep, it's good
#ubuntu-release 2015-06-10
<doko> slangasek, infinity: verfication now done for https://launchpad.net/bugs/1311866
<ubot93> Launchpad bug 1311866 in gcc-4.8 (Ubuntu Trusty) "update binutils and GCC for trusty" [Wishlist,Fix committed]
<hallyn> hi - qemu wily package needs approval of some new binary pkgs
<Laney> stgraber: how do I configure release managers in the iso tracker?
<Laney> oh, bah, are you off today? :)
<hallyn> Laney: is approving the new wily qemu packages something you can do?
<infinity> hallyn: I can look.
<hallyn> thanks!
<infinity> hallyn: libacard (and related) and qemu-block-extra?
<infinity> hallyn: I assume/hope these changes are in sync with Debian, not us going out on a limb?
<infinity> hallyn: Okay, answered that one myself from the Debian changelog.
<infinity> hallyn: Looks like you probably want to merge -5 for the security fixes, though. :P
<hallyn> infinity: yeah...  actually i'm assuming mdeslaur wanted to push patches for those, which is why i wnated to get this cleared
<hallyn> but i can just merge the next version right now from debian too
<infinity> hallyn: Kay, just doing a quick binNEW review here.
<infinity> hallyn: Accepted.
<hallyn> thanks
<hallyn> hm, -5 is not in debian's git
<infinity> hallyn: Manual merge and resolve it later? :P
<infinity> (Or yell at mjt to push his branch)
<hallyn> starting with 2 and then doing 1 :)
<hallyn> infinity: pushing the new merge now
<infinity> hallyn: Shiny.
<infinity> hallyn: Ahh, I see you got mjt to push git. :)
<hallyn> yup :)  was a refreshingly simple merge.  (jinx)
<mdeslaur> grr...dist-upgrading a freshly installed trusty fails
 * mdeslaur will research and file a bug tomorrow
<infinity> mdeslaur: There's already a bug.
<infinity> mdeslaur: Assuming this is what you're seeing: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1452238
<ubot93> Launchpad bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Undecided,Confirmed]
<mdeslaur> infinity: ah, yes, that's the issue, thanks
<mdeslaur> infinity: I think that's the issue people with brand new Dell XPS 13s are hitting too
<mdeslaur> infinity: it's a pretty bad issue...is anyone actively working on it?
<infinity> mdeslaur: Other than commenting on the bug, I haven't looked too deeply, but I'm guessing it can be worked around per my last comment.  Would be nice if someone found the time to experiment.
<mdeslaur> infinity: ack. adding to my to-do list
<mdeslaur> infinity: right after the glibc tzdata regression
<infinity> mdeslaur: Oh man, I completely forgot about the tzdata thing.  I'd really like to understand that one.
<mdeslaur> infinity: did you see the bug with the reproducer?
<mdeslaur> infinity: I have a test build in a ppa with the commit reverted, I need to upload tzdata to it and test further
<infinity> mdeslaur: I wonder if it's something as simple as building on a 64-bit system produces unportable results, but 32-bit is fine (given that vivid was when we switched from i386 to amd64 for arch:all)
<infinity> mdeslaur: Bug number?
<mdeslaur> infinity: nah, I thought about that, but the tzdata where it worked was built on amd64
<mdeslaur> infinity: bug 1462052
<ubot93> bug 1462052 in glibc (Ubuntu) "timezone handling regression in glibc 2.21" [Undecided,New] https://launchpad.net/bugs/1462052
 * mdeslaur uploads tzdata to ppa
<infinity> mdeslaur: Oh, I think I pointed you at that commit.  That's not exactly an isolation of the problem. :P
<mdeslaur> infinity: I only reverted the zic part of the commit...just for confirmation
<mdeslaur> I can't build glibc locally for some reason, the test suite fails, which is why I put it in a ppa
<infinity> mdeslaur: Are you building on an overlayfs schroot?
<infinity> mdeslaur: There's a test that fails on overlayfs.
<mdeslaur> infinity: oh, yeah, I am
<mdeslaur> infinity: I'm doing this in between the zillion security updates I work on as my day job, so it's taking a while :P
<infinity> mdeslaur: Right.  Well, if reverting that "fixes" it, that's a start, but it's not a reasonable fix.  So, more digging required.
<mdeslaur> no, not a reasonable fix at all
<mdeslaur> my next step was to see if updating to the latest tzcode fixes it
<mdeslaur> there's a lot of fishy things in that commit
<infinity> mdeslaur: There are definitely a lot of places where wordsize looks like it could come into play.
<mdeslaur> I'm just trying to confirm that commit so I know I'm looking in the right place
<infinity> mdeslaur: But it's still weird that it's producing data files that then get misinterpreted on load.
<mdeslaur> yeah, quite weird
<infinity> mdeslaur: Dumping a working and non working zone and comparing them might be interesting.
<mdeslaur> I tried that
<mdeslaur> but it's like 100% different :(
<mdeslaur> well, actually, I haven't tried dumping the same version of tzdata
<mdeslaur> but the one I just uploaded to the ppa will allow me to do just that
<mdeslaur> I tried comparing utopic with vivid
<mdeslaur> and that was too different
<mdeslaur> anyway, more tests tomorrow
 * mdeslaur -> away
#ubuntu-release 2015-06-11
<infinity> tjaalton: Around?
<tjaalton> infinity: off this week. xorg metapkg isn't uploaded yet btw..
<infinity> tjaalton: xorg-lts-vivid, you mean (which is in the queue), or something else?
<infinity> tjaalton: Also, I rejected one of your uploads, would be nice if you could look at that, despite the VAC.
<tjaalton> infinity: oh i uploaded it? ok.. i'll check the other one
<tjaalton> infinity: looks like -qxl doesn't follow the same packaging as rest, so there's some tarball diff
<tjaalton> or such
<infinity> tjaalton: That crufty weirdness didn't happen between utopic and lts-utopic, FWIW.
<infinity> tjaalton: And nothing in the utopic->vivid diff would have caused that.
<infinity> tjaalton: So, I assume it was just a dirty tree when building lts-vivid.
<tjaalton> weird
<tjaalton> i use the source from apt get
<infinity> tjaalton: Err, wait.  WAT?
<tjaalton> pulled the source package from vivid
<tjaalton> renamed
<infinity> tjaalton: qxl is native in utopic/lts-utopic, and vivid.  Where did that orig magically come from for lts-vivid?
<tjaalton> debuild
<tjaalton> oh
<tjaalton> grr
<infinity> tjaalton: That orig is likely the culprit. :P
<tjaalton> shitfuck
<tjaalton> ok i'll delete the orig then
<infinity> Where did it even come from? :)
<infinity> Given that there's no orig in vivid... So confused.
<infinity> But yeah, I'd assume unpacking vivid, running rename mojo on it, and building source withut the orig should give you a nice, small diff.
<infinity> tjaalton: And assuming xorg-lts-vivid is the last piece of the puzzle, then you can rest without me bugging you.
<infinity> tjaalton: And I might have functional dailies for you to test when you get back.
<tjaalton> and now the debdiff makes sense
<tjaalton> the rename script was buggy for a reason then!
<tjaalton> it would happily build the source for you without a proper tarball
<tjaalton> qxl uploaded again
<tjaalton> infinity: yeah apparently i uploaded the metapkg at some point, so it should be all good then
<infinity> tjaalton: Alright, lemme quickly re-review this.
<infinity> tjaalton: That looks much saner, thanks.
<tjaalton> cool
<tjaalton> time for bf ->
<sil2100> Hello everyone! I would need to disable the importer on nusakan again for a while
 * Laney looks at stgraber 
<Laney> iso tracker halp? :)
<stgraber> Laney: hey
<stgraber> Laney: what's up?
<stgraber> (sorry, been taking some days off this past week so may have missed some pings)
<Laney> no worries
<Laney> how can I add a new 'owner' team?
<stgraber> Laney: is that for a new product?
<Laney> no, I want to set one for desktop-next
<stgraber> ok, it's not exactly the easiest thing in the world :)
<stgraber> first you have to go create a new role, that's in the admin interface under user IIRC
<Laney> I see a list here: http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/363/edit
<stgraber> once done, go to the permissions tab and make sure that the permissions for the new role matches that of a similar product owner team
<Laney> ah, that'll get it in there I suppose
<stgraber> once that's done, go to the LP team module configuration and setup a new mapping between the LP team and the role you created
<stgraber> once you've done that, you can go and edit the product to assign it the role
<Laney> I don't have user in there
<stgraber> oh, you're probably not admin enough :)
<Laney> oh man, there are higher levels of power?
<stgraber> and stupid 3G here has busted routes to SSO
<stgraber> let me proxy through a server somewhere so I can actually login
<stgraber> ok, I'm logged in
<stgraber> Laney: what's the LP team?
<Laney> ~ubuntu-desktop-next-release
<stgraber> Laney: role should be setup now
<stgraber> Laney: I'm EODing now and about to leave till Monday, do you need anything else from me?
<Laney> stgraber: not if it works
<Laney> happy holidays!
<Laney> and thanks
<Laney> ah wait, it's not posting to the tracker it seems
<stgraber> Laney: btw, those with admin access for that kind of stuff are ~ubuntu-qa-website-devel
<Laney> ah, maybe it doesn't have to be
<stgraber> No iso.qa.ubuntu.com product found for ubuntu-desktop-next/daily-preinstalled/wily-preinstalled-desktop-next-i386; skipping.
<stgraber> No iso.qa.ubuntu.com product found for ubuntu-desktop-next/daily-preinstalled/wily-preinstalled-desktop-next-armhf; skipping.
<Laney> etc/qa-products?
<stgraber> yep
<Laney> k, will fix
<Laney> will that break triggering the rebuild?
<stgraber> qa-products is used both by the build script and process-rebuilds so yeah, you need to fix this
<Laney> ok then
<Laney> I'll hassle you on monday if it doesn't work by then
<stgraber> ok :)
<stgraber> rebuild-requests can be run in dry-run and verbose mode to see if the change works
<stgraber> as for publishing, look at the end of the build log: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-desktop-next/wily/daily-preinstalled-20150611.log
 * Laney tries a test build
 * stgraber -> out
<sil2100> I'll have to disable the importer again...
<sil2100> ...or maybe not
<coreycb> hello, can we have python3-tempest-lib and python3-paramiko promoted to main please?
<infinity> coreycb: I don't see anything on my reports indicating that they're being pulled in.
<coreycb> infinity, do I need an MIR for them?  the python 2 binary packages are in main.
<infinity> coreycb: No, you don't need an MIR.  But you need something uploaded that depends on them, or to have them explicitly seeded with a rationale.
<infinity> coreycb: If your intent was the former, please upload, and we'll clean it up.
<coreycb> infinity, ok I still need to get the package in that depends on python3-tempest-lib, but there's already a dep on python3-paramiko:  https://launchpad.net/ubuntu/+source/python-tempest-lib/0.5.0-1/+build/7528029
<infinity> coreycb: You do, however, need an MIR for python-ddt.
<coreycb> infinity, we have one somewhere, lemme find it
<infinity> And I'm very confused about why none of this is showing up on my mismatches reports.  Hrm.
<coreycb> infinity, bug 1459151
<ubot93> bug 1459151 in python-ddt (Ubuntu) "[MIR] python-ddt" [High,Fix committed] https://launchpad.net/bugs/1459151
<infinity> coreycb: Ta.
<infinity> coreycb: Should all be promoted.
<coreycb> infinity, great, thanks!
<infinity> coreycb: Or, will be once a publisher cycle happens.
<infinity> coreycb: By "all", I mean the two packages in that MIR, and paramiko.
<infinity> coreycb: tempest will want love after you upload something else that needs it.
<coreycb> infinity, yep, got it
<infinity> coreycb: tempest still has an issue.
<infinity> coreycb: It build-depends on python3-oslo.log and python-oslo.log, but those don't actually exist.  They're -log, not .log
<infinity> coreycb: Oh, nevermind, the new .log just hasn't built yet.
<infinity> La la la.
<infinity> This namespace renaming is such a mess.
<coreycb> infinity, yeah jamespage worked through a bunch of those to rename them back to .log recently.  anything needed from us?
<infinity> coreycb: Not yet.  I'll keep babysitting and see where it ends up.
<coreycb> infinity, ok thanks
<infinity> coreycb: Oh, filling in all the MIR info for LP: #1464158 would help.  That seems to be the next snag.
<ubot93> Launchpad bug 1464158 in python-wrapt (Ubuntu) "[MIR] python-debtcollector, python-wrapt" [High,New] https://launchpad.net/bugs/1464158
<coreycb> infinity, ok I'll do that
<coreycb> infinity, I've updated that MIR bug for  python-debtcollector and python-wrapt
<infinity> coreycb: Thanks.
#ubuntu-release 2015-06-12
<jamespage> infinity, thanks for working on the oslo stuff - hopefully once we re-align with Debian this will be alot less hassle going forward
<jamespage> infinity, suffice to say there was miscommunication between ubuntu/debian last cycle on the need to transition the package names for the upstream namespace changes
<sil2100> Hello everyone! It seems that the latest gnutls28 upload that's in wily-proposed is breaking cmake bits on i386 (most probably)
<sil2100> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1464569
<ubot93> Launchpad bug 1464569 in gnutls28 (Ubuntu) "3.3.15-5ubuntu1 breaks CMake on i386" [Undecided,New]
<sil2100> Mirv filled in a bug for that, we think it's critical to at least double-confirm it and maybe even drop the upload from -proposed
<cjwatson> Dropping it would break other things - it's a transition in progress
<cjwatson> (Other things that your consumers care about, even)
<sil2100> ACK
<cjwatson> Can you see whether 'ldd cmake' in a wily-proposed chroot shows multiple versions of libnettle?  (I'd check myself but I just switched laptops and haven't set up schroots again yet)
<sil2100> Damn, didn't setup a wily chroot yet, Mirv do you have one handy by any chance?
<sil2100> I'll make one now anyway as it'll be useful
<Mirv> sil2100: well I have wily amd64, would it need to be i386 with proposed enabled?
<Mirv> sil2100: cjwatson: wily-proposed i386 ldd cmake http://paste.ubuntu.com/11701395/ yes to multiple libnettle:s
<teward> when an ubuntu delta exists in a package, is autosync disabled?
<Laney> Yeah, someone has to look at the diff and decide what to do with it
<Laney> Port it forward or get rid of it
<cjwatson> Indeed.  See auto-sync in lp:ubuntu-archive-tools for the full logic
<teward> good, because if that logic didn't exist I'd be asking for a temporary sync blacklist on nginx, but since the delta exists the system won't help :P
<teward> s/help/break anything/
<teward> (those who care, keep an eye on the server mailing list, i'll drop a summary of why this is the case shortly)
<cjwatson> Sync blacklists aren't often needed these days, and never were in the case of Ubuntu deltas.
<teward> cjwatson: wasn't sure, hence my asking :P
<cjwatson> Sure
#ubuntu-release 2016-06-13
<Logan> this is weird
<Logan> I can't mark a bug as affecting Precise - it just says "Nominated for Precise by..."
<Logan> I was able to just add releases to bugs in the past o_O
<apw> Logan, sometimes that happens when you are using the "wrong" package where a bug has tasks for more than one
<Logan> apw: weird. it's Bug 659742, which only has Ubuntu and Debian tasks
<ubot5> bug 659742 in zephyr (Ubuntu) "initscript zhm, action "restart" failed" [Medium,Fix released] https://launchpad.net/bugs/659742
<jbicha> maybe it's because zephyr was in main for precise, according to rmadison
<infinity> Logan: Approved the nomination.  The internet here is too crap for me to figure out why it didn't work for you.
<Logan> jbicha: you're totally right! that makes sense
<Logan> infinity: thanks, as always :)
<flexiondotorg> infinity, I'm not able to request rebuilds on iso.qa.
<flexiondotorg> Or rather, I can request them, but nothing happens.
<flexiondotorg> At least from from I have access to, nothing is started. No logs.
<flexiondotorg> Daily builds are obviously working though.
<ogra_> do you perhaps still have a build queued that failed ?
<flexiondotorg> ogra_, Not that I can see.
<ogra_> iirc there used to be an issue wheer you had to cancel a build first before you could request a new one ... (but that was a while ago)
<ogra_> not sure thats still the case though
<flexiondotorg> ogra_, I'll have a tinker.
<flexiondotorg> I'm trying to get Ubuntu MATE mostly following recommends and it will be helpful to rebuild on demand rather than wait a day :-)
<infinity> flexiondotorg: Looking.
<flexiondotorg> infinity, Cheers.
<infinity> flexiondotorg: THere are no pending requests.
<flexiondotorg> infinity, I have requested any today.
<flexiondotorg> I tried a few times over the weekend.
<flexiondotorg> Shall I request one now?
<infinity> flexiondotorg: Sure.
<flexiondotorg> infinity, Yakkety daily rebuild requested.
<flexiondotorg> All archs.
<infinity> flexiondotorg: Huh.  Definitely seems to be not doing a thing.
<flexiondotorg> OK
<infinity> *raise brow*
<infinity> That's really wonderfully broken.
<infinity> flexiondotorg: I might need some stgraber to figure out WTF.
<infinity> stgraber: What timezone are you in?
<flexiondotorg> infinity, OK, thanks for looking. Thought it was odd which is why I raised it.
<Laney> Looks like s/Mate/MATE/ in etc/qa-products
<Laney> I guess the thingies got renamed at some point, and this file needs to keep up
<infinity> Hrm, why would things have been renamed?
<infinity> Laney: I don't see how it's different from xenial...
<Laney> Presumably the renaming affects all series then
 * Laney tests
<infinity> Laney: Although, you switched the name last year.  r1500.
<Laney> http://iso.qa.ubuntu.com/qatracker/milestones/347/builds/105083/testcases
<Laney> totes
<infinity> Laney: Right, okay, so you're implying someone did s/Mate/MATE/ in the tracker recently.  That would indeed explain this.
<Laney> #ubuntu-release.log-20160422.gz:21/04 12:07:13 -queuebot:#ubuntu-release- Builds: Ubuntu Mate Desktop amd64 [Xenial Final] has been marked as ready
<infinity> Derp.
<infinity> Laney: You fixing cdimage already, then?
<Laney> Can do
<infinity> Laney: I can, I'm there already.
<infinity> Just didn't want to stop on toes.
<Laney> oh
<Laney> Well I just pushed it
<Laney> You go pull that then
<infinity> Heh.
<infinity> Doing.
<Laney> Committed revision 1600.
<Laney> spooky
<infinity> Hah.
<infinity> So we get to rename it again for 1700.
<infinity> Make a note.
<infinity> That looks better.
<infinity> flexiondotorg: Should build in 20s.
<flexiondotorg> infinity, Laney Thank you!
<flexiondotorg> Laney, the Ubuntu MATE rebuild earlier failed to a package mis match.
<flexiondotorg> I can't Cancel the rebuild.
<flexiondotorg> In order to try again.
<infinity> flexiondotorg: Cancelled.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, cyphermox If you could be so kind - https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/mate-compatbility/+merge/297219
<attente> hi, what's the process for sru'ing a package that's fixed in debian? do i need to file an sru that points to the appropriate debian bugs? do i attach a debdiff with the debian changes?
<teward> attente: https://wiki.ubuntu.com/StableReleaseUpdates
<sergiusens> slangasek bdmurray mind accepting snapcraft 2.11 into xenial if you have a moment?
<bdmurray> sergiusens: could you be specific about your request? into -proposed or -updates?
<sergiusens> bdmurray into updates
<sergiusens> bdmurray specifically ( :-) ), snapcraft-2.11 that is in xenial-proposed to xenial-updates; everything has been marked verification-done
<bdmurray> sergiusens: I'll have a look shortly
<sergiusens> bdmurray thank you
<bdmurray> sergiusens: oh, this is the one from last week to be released in a shorter time frame?
<sergiusens> bdmurray yes
<sergiusens> bdmurray in any case, we have been staying in -proposed for 2 days at most with all snapcraft releases
<bdmurray> sergiusens: okay, its publication is now pending
<sergiusens> thanks
#ubuntu-release 2016-06-14
<chih> ping infinity
<flexiondotorg> infinity, Laney Ubuntu MATE daily didn't build at all last night and issuing rebuild requests doesn't work :-(
<flexiondotorg> stgraber, Not sure if you can help with the above? ^^
<infinity> flexiondotorg: I don't see any pending requests.
<flocculant> flexiondotorg: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-mate
<flexiondotorg> flocculant, Yep, I've seen that too.
<flexiondotorg> infinity, There are two issues here.
<flexiondotorg> The libgpod4 package conflict is one. I can work around that.
<flexiondotorg> The other is, if I request a rebuild nothing happens.
<ogra_> infinity, hmm, so i pushed yoour yakkety livecd-rootfs to the snappy ppa, now all of a sudden xenial-proposed is enabled everywhere
<ogra_> infinity, weird, seems to be enabled all the time, not related to your change, but makes images explode
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/65242 suddenly has "Proposed: True"
 * ogra_ wonders if anything globally changed in cdimage or some such 
<flexiondotorg> infinity, I can issue rebuild requests now :-)
<flexiondotorg> Thanks.
#ubuntu-release 2016-06-15
<tkamppeter> cups 2.1.3-6 does not make it from proposed to release in Yakkety for several days now. What is the problem.
<seb128> tkamppeter, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<seb128> "Depends: cups krb5 (not considered) "
<seb128> https://launchpad.net/ubuntu/+source/krb5/1.14.2+dfsg-1 build issue
<tkamppeter> seb128, this means that CUPS does not update because krb5 does FTBFS on ppc64el? What can be done here?
<seb128> tkamppeter, somebody needs to fix the krb5 build issue
<tkamppeter> seb128,  it seems that krb5 is not maintained by us, simply auto-syncing from Debian.
<seb128> don't change that statement
<seb128> somebody needs to debug/fix the build issue
<seb128> that fix can be sent back to debian
<seb128> or an ubuntu1 revision can be uploaded
<cjwatson> I suspect it's due to -O3
<cjwatson> Looks like the sort of thing where the compiler does a bit more uninitialised-variable tracking at higher optimisation levels
<cjwatson> Would probably go away at -O2, or somebody could adjust the offending function to pacify the compiler; either way
<tkamppeter> ppc64el seems to be some more exotic architecture, so if I would try to change anything this would be pure guesswork, and some core-dev also needs to upload it. Can someone of you perhaps fix it?
<tkamppeter> cjwatson, seb128 ^^
<cjwatson> I'm not going to
<seb128> neither am I, my todolist overflow already without that
<LocutusOfBorg> Hi, I still hope somebody can help me in removing a couple of binaries (already removed in Debian)
<rbasak> LocutusOfBorg: I can't help (not an AA) but I would just ask if I were you.
<LocutusOfBorg> vmtk/powerpc <-- we want the insighttoolkit to be removed from Ubuntu too, and removing vmtk/powerpc allows us to
<tkamppeter> cjwatson, seb128: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1592841
<ubot5> Launchpad bug 1592841 in krb5 (Ubuntu) "FTBFS on ppc64el, blocks updates of all packages depending on krb5, for example CUPS" [Critical,New]
<LocutusOfBorg> this means also removing src:insighttoolkit
<cjwatson> tkamppeter: please untag me
<LocutusOfBorg> also vtk, needs some removals too, but it should go (fslview seems the last blocker, and its broken in debian too, so maybe demoting is the way?)
<LocutusOfBorg> src:libpng seems blocked only by liquidsoap migration
<LocutusOfBorg> but I need help here
<LocutusOfBorg> rbasak, I wrote the above a lot of time, I hope somebody will pick them up
<tkamppeter> cjwatson, I did not tag you, and if the system has tagged you automatically, where do I see it and how do I remove it?
<LocutusOfBorg> tkamppeter, I think he means from irc, highlight
<tkamppeter> cjwatson, sorry.
<cjwatson> tkamppeter: Yes, I mean please don't highlight me further regarding this bug, because I'm not going to work on it; I was helping you in passing but I have too many other things to do
<LocutusOfBorg> tkamppeter, what about providing a patch and subscribing sponsors?
<LocutusOfBorg> if you look at e.g. cowdancer, you should have a really similar issue, and similar patch
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/cowdancer/0.80ubuntu1
<LocutusOfBorg> you can test a patch, upload in a ppa, and ask for a sponsor
<tkamppeter> LocutusOfBorg, I will not be able to test it in a PPA as PPAs only support amd64 and i386 AFAIK, but I can do the same change as was done on cowdancer attach the debdiff to the bug and subscribe sponsors. Will this work?
<LocutusOfBorg> tkamppeter, you can test ppa
<LocutusOfBorg> just go in options and enable ppc64el
#ubuntu-release 2016-06-16
<mardy> hi! the autotests failed because of some bluez installation issue, completely unrelated; can we force the landing here? http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-system-settings-online-accounts
<LocutusOfBorg> cjwatson, sorry for bothering, do you plan to have a look at haskell? I think you are the best one here :)
<LocutusOfBorg> propellor is FTBFS because of it
<cjwatson> oh yeah probably
<LocutusOfBorg> thanks! is it blacklisted right now?
<cjwatson> let me just unleash auto-sync on it at this point
<LocutusOfBorg> well, it didn't migrate completely in Debian
<cjwatson> I got far enough through the transition that stuff should generally fail rather than building with the old ABI
<cjwatson> which was the reason I blacklisted it, to avoid too many unnecessary rebuilds
<LocutusOfBorg> yes indeed, this is why I'm saying that the transition is not completely finished
<cjwatson> yes I'm aware of that
<LocutusOfBorg> thanks :)
<LocutusOfBorg> nice to see you keeping up haskell!
<cjwatson> auto-sync should deal with some of it in an hour or so and then I'll see what's left after that
<LocutusOfBorg> as usual, since I don't like to ask stuff, I propose myself to do some work
<cjwatson> I'm happy to deal with the boring "rebuild/retry stuff in layers" bit
<cjwatson> it's only interesting once there's actually stuff to debug
<LocutusOfBorg> I already did some ocaml rebuilds, but seems that I didn't make it migrate :(
<LocutusOfBorg> well, I'm happy to see you doing it, but I like also to learn sometimes ;)
<LocutusOfBorg> anyway, I really appreciate your work as usual!
<mardy> cjwatson: hi! Do you have time to unlock http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-system-settings-online-accounts ? the autotest failure is due to some error on installing bluez, which is not related at all
<jamespage> please can the ceph 10.2.1 for xenial be rejected from the unapproved queue; going to re-upload with 10.2.2
<cjwatson> mardy: sorry, no, hopefully somebody else does
<LocutusOfBorg> can anybody kick botch? it is preventing dose3 and liquidoap from migration
<cjwatson> LocutusOfBorg: explain "kick"
<LocutusOfBorg> cjwatson, broken in Debian, if demoting is good enough... demote
<LocutusOfBorg> I guess it will be removed from Debian soon, but demoting should do the trick I think
<cjwatson> I'd really prefer to wait for the Debian removal unless there's some specific urgency
<LocutusOfBorg> liquidsoap migration would be appreciated
<LocutusOfBorg> I think it is the latest one blocking libpng12 removal
<cjwatson> that's a better reason
<LocutusOfBorg> I really want only one libpng implementation in yakkety
<LocutusOfBorg> :)
<cjwatson> LocutusOfBorg: removed from yakkety, left the FTBFSing source in yakkety-proposed
<LocutusOfBorg> thanks! do you think the autopkgtestsuite will stop from running now?
<cjwatson> dunno
<cjwatson> wait a bit and find out :)
<LocutusOfBorg> yeah! ;)
<jbicha> bdmurray: could you accept abiword/wily too so that those sru's can be tested simultaneously?
<bdmurray> jbicha: yeah, sorry that slipped my mind
<jbicha> np, there aren't many wily sru's now
#ubuntu-release 2016-06-17
<ginggs> hi slangasek, can we demote elkcode to proposed please? it needs a rebuild for libxc transition, but it will FTBFS (see RC debian bug #825934)
<ubot5> Debian bug 825934 in src:elkcode "elkcode: FTBFS: undefined reference to xc_f90_version_" [Serious,Open] http://bugs.debian.org/825934
<slangasek> ginggs: not demote; I'll remove it
<ginggs> slangasek: thanks
<slangasek> ginggs: (done)
<ginggs> would someone take at why supercollider won't migrate please? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#supercollider 'old binaries left on armhf: supercollider-supernova (from 1:3.7.0~repack-1)'
<ginggs> and also please remove the old armhf build of singular, armhf is now dep-wait on python-polybori
#ubuntu-release 2017-06-12
-queuebot:#ubuntu-release- New: accepted mbox-importer [source] (artful-proposed) [16.12.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: mbox-importer [amd64] (artful-proposed/universe) [16.12.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbox-importer [i386] (artful-proposed/universe) [16.12.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbox-importer [armhf] (artful-proposed/universe) [16.12.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mbox-importer [amd64] (artful-proposed) [16.12.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mbox-importer [i386] (artful-proposed) [16.12.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mbox-importer [armhf] (artful-proposed) [16.12.3-0ubuntu1]
<ginggs> would someone please update 'force-badtest r-bioc-annotationhub/2.8.1-1'? older versions are in adconrad hints
-queuebot:#ubuntu-release- New: accepted octave [amd64] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [armhf] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [ppc64el] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [arm64] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [s390x] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [i386] (artful-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [amd64] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (artful-proposed) [0.36.3-1~git1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-120.167] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-120.167]
-queuebot:#ubuntu-release- New binary: golang-github-andybalholm-cascadia [amd64] (artful-proposed/universe) [0.0~git20161224.0.349dd02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faceup [amd64] (artful-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplack-builder-conditionals-perl [amd64] (artful-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-bdd [amd64] (artful-proposed/universe) [2.18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [ppc64el] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [ppc64el] (artful-proposed/universe) [1.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [amd64] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [i386] (artful-proposed/universe) [1.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [amd64] (artful-proposed/universe) [1.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-xterm [amd64] (artful-proposed/universe) [2.7.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [i386] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [s390x] (artful-proposed/universe) [1.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [arm64] (artful-proposed/universe) [1.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [s390x] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [armhf] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-miniutter [arm64] (artful-proposed/universe) [0.4.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: network-manager-l2tp [armhf] (artful-proposed/universe) [1.2.6-2] (no packageset)
<slashd> o/ Good monday sil2100, could you please have a look a these 2 requests for me when you have some times ? #1 - Promote "ebtables" from -proposed to -update for releases : T/X/Y/Z  | #2 - Promote "vlan" from -proposed to -update for releases : X/Y/Z (Not Trusty as it doesn't have the minimum aging yet)
<slashd> ddstreet, ^
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-80.101] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-6.11] (core, kernel)
<estan> anyone think they have time to publish qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.5 today (it's in the xenial SRU queue)? (infinity? sil2100?)
<sil2100> estan: I could take a look
<sil2100> In some moments
<sil2100> Need to take care of kernels first
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-80.101]
<estan> sil2100: excellent. many thanks.
<cyphermox> slangasek: indeed, it should be ~desktop-packages. it already has ~desktop-bugs though
<cyphermox> (hopefully that wasn't changed between when you and I looked)
<jbicha> caribou already had ~desktop-bugs subscribed before last night, I guess slangasek was looking at something different?
<jbicha> caribou: oops, hi :)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-23.25] (core, kernel)
-queuebot:#ubuntu-release- New: accepted faceup [amd64] (artful-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [amd64] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [armhf] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [ppc64el] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted libplack-builder-conditionals-perl [amd64] (artful-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [arm64] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [i386] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [s390x] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-andybalholm-cascadia [amd64] (artful-proposed) [0.0~git20161224.0.349dd02-1]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [i386] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [amd64] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [ppc64el] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [arm64] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted network-manager-l2tp [armhf] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted haskell-miniutter [s390x] (artful-proposed) [0.4.6.0-1]
-queuebot:#ubuntu-release- New: accepted node-xterm [amd64] (artful-proposed) [2.7.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted pytest-bdd [amd64] (artful-proposed) [2.18.2-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-23.25]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-6.11]
<ginggs> would someone from release team please 'force-badtest r-bioc-annotationhub/2.8.1-1' ? older versions are in adconrad hints
<apw> ginggs, what is the nature of the failure?  that looks to be a fairly large delta without any fixes to the tests
<ginggs> apw, the new version fails in the same way in ubuntu as the previous versions
<ginggs> it does not fail locally or on Debian's CI infra
<infinity> I thought the old failure was due to their upstream site moving files around?
<infinity> Or was that another one?
<infinity> Oh, no.  Different failure.
<infinity> This was one where a regression slipped in to -release, so I let it slide in -proposed.
<infinity> Would still be good to root cause and fix it...
<infinity> ginggs: Bumped for now.
<ginggs> infinity: yeah we fixed the upstream ftp moving stuff around issue, that was actually in r-bioc-genomeinfodb
<ginggs> infinity: thanks, that's gonna unblock a month's worth of R stuff now!
<slangasek> jbicha: the list of recognized subscribers for main packages is http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html.  I've subscribed desktop-packages now, thanks
<jbicha> slangasek: see also #ubuntu-devel I believe the Ubuntu Desktop Team wants to use desktop-bugs instead
<slangasek> jbicha: yeah, I see that now
<slangasek> I'll leave it to seb128 and bdmurray to reconcile
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-23.25~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-80.101~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-23.25~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-80.101~14.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-tweak-tool (zesty-proposed/universe) [3.24.0-0ubuntu2 => 3.24.1-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
<sil2100> estan: ...aand it's released \o/ Sorry it took so long, those kernel SRUs were much more time consuming than I expected
-queuebot:#ubuntu-release- Unapproved: curtin (zesty-proposed/main) [0.1.0~bzr482-0ubuntu1 => 0.1.0~bzr505-0ubuntu1~17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr470-0ubuntu1~16.10.1 => 0.1.0~bzr505-0ubuntu1~16.10.1] (ubuntu-server)
<smoser> bah
<smoser> can someone NACK the curtin uploads to xenial, yakkety and zesty ?
<smoser> i need an SRU bug there.
<smoser> :-(
<smoser> sorry for noise
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [0.1.0~bzr470-0ubuntu1~16.04.1 => 0.1.0~bzr505-0ubuntu1~16.04.1] (ubuntu-server)
<smoser> infinity, ^ ? i know you like NACKing my things.
<smoser> just pretend i didnt ask.
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (zesty-proposed) [0.1.0~bzr505-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (xenial-proposed) [0.1.0~bzr505-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: curtin (zesty-proposed/main) [0.1.0~bzr482-0ubuntu1 => 0.1.0~bzr505-0ubuntu1~17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (yakkety-proposed) [0.1.0~bzr505-0ubuntu1~16.10.1]
<apw> smoser, ^
-queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr470-0ubuntu1~16.10.1 => 0.1.0~bzr505-0ubuntu1~16.10.1] (ubuntu-server)
<smoser> apw, gracias
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [0.1.0~bzr470-0ubuntu1~16.04.1 => 0.1.0~bzr505-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu4]
<infinity> smoser: Aww, man, I missed out on the chance to reject THREE of your uploads?  This is a sad day.
<jbicha> infinity: you can reject libgweather 3.24.0/zesty but it would be nice if you would accept 3.24.1 in its place :)
<infinity> jbicha: I'm not actually here.
<infinity> jbicha: Which won't stop me from rejecting, but might stall the other bit.
<jbicha> I just need to find an SRU Team member running GNOME Shell/zesty who wants it to not crash so much :)
-queuebot:#ubuntu-release- Unapproved: rejected libgweather [source] (zesty-proposed) [3.24.0-0ubuntu2.1]
<infinity> jbicha: Merry Christmas.
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (zesty-proposed) [3.24.1-0ubuntu0.1]
<jbicha> you can go back to not being here now :)
-queuebot:#ubuntu-release- New binary: sphinx-celery [amd64] (artful-proposed/universe) [1.3.1-1ubuntu1] (no packageset)
#ubuntu-release 2017-06-13
<jbicha> RAOF: hi, if you have time for SRUs today, it might be nice to push chrome-gnome-shell/xenial and yakkety into updates since FF54 will be released this week
<RAOF> jbicha: My SRU day is tomorrow morning, unless I've somehow missed Tuesday :)
<RAOF> That said, let me look... A)
<jbicha> (chrome-gnome-shell seems to basically work with Firefox 54 though)
<RAOF> :)
<jbicha> RAOF: I thought it was Tuesday where you were?
<jbicha> I'm following https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<RAOF> jbicha: It is Tuesday, but that Wiki page is in Pacific time :)
<jbicha> seriously?
<jbicha> that sounds convenientâ¦ :)
<RAOF> That was simple enough. Enjoy your shiny new chrome-gnome-shell/xenial,yakkety
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.13-0ubuntu3~ubuntu16.04.1 => 2.14-0ubuntu3~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-backports/main) [2.13-0ubuntu3~ubuntu16.10.1 => 2.14-0ubuntu3~16.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.13-0ubuntu3~ubuntu17.04.1 => 2.14-0ubuntu3~17.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.14-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-backports) [2.14-0ubuntu3~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.14-0ubuntu3~17.04.1]
<LocutusOfBorg> fossfreedom, budgie-desktop syncd in ubuntu
<LocutusOfBorg> fossfreedom, it fails to build, patch appreciated
<didrocks> cjwatson: hey, would you know why I can't access to https://launchpad.net/ubuntu/artful/+upload/15602063/+files/pim-sieve-editor_16.12.3-0ubuntu1_amd64.deb ? (I tried multiple pim-sieve-editor binary packages in NEW)
<cjwatson> didrocks: Hmm, probably my mistake - I think when I changed the queue page to proxy those files through the webapp rather than linking straight to the librarian, I forgot that PackageUpload:+files doesn't yet handle binary packages
<cjwatson> didrocks: Can you file a bug?
<didrocks> cjwatson: sure, bug #1697680. Is there any way I can access them to check before binNEW them?
<ubot5> bug 1697680 in Launchpad itself "Can't access binaries in NEW queue (source packages assets are fine though)" [Undecided,New] https://launchpad.net/bugs/1697680
<cjwatson> didrocks: "queue fetch 15602063" works fine
<cjwatson> (or any other queue fetch mode)
<didrocks> cjwatson: perfect, thanks!
<cjwatson> It's probably about as complicated as http://paste.ubuntu.com/24848569/ plus tests, so hopefully don't take too long
<cjwatson> *won't take
<didrocks> cjwatson: ah indeed, no hurry anyway, preferred to ping just in case this changed over time and I didn't notice :)
<cjwatson> Yeah, it's a recent-ish regression
<jamespage> please could horizon 10.0.4-0ubuntu1 be rejected from the yakkety UNAPPROVED queue - there is a problem with the orig-static.tar.gz bundle
<apw> jamespage, rejected .... though where is queubot ...
<jamespage> taking a break I guess :)
<jamespage> apw: ta
 * apw wonders who is responsible for stroking queuebot ...
<sil2100> infinity: btw. you want to take care of all the HWE stack packages or should I take the rest? I see things like libwacom in the queue now
<smoser> infinity, i'm sure you'll get another chance sometime. thanks.
<apw> bdmurray, do you know who runs queuebot ?
<cyphermox> hi, could someone please review nplan from the queue for all releases: nplan 0.23~$release; and netcfg
<bdmurray> apw: Maybe stgraber
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (xenial-proposed) [1:6.1.2-0ubuntu1]
<slashd> good day sil2100 ;) hope you are doing well. I know it's not your SRU day today, but I sent you a message yesterday on #ubuntu-release and I had some internet issue a few minutes after so if you answered me I never got it. It was about moving from -proposed to -updates 2 packages "vlan" (for all affected releases but Trusty) and "ebtables" for all affected releases.
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu1]
<sil2100> slashd: hey! You're in luck, I'm wearing my SRU hat today since yesterday I was busy with kernel SRUing
<sil2100> slashd: I either didn't get that message or missed it completely, so I can take a look at it in a moment
 * slashd going to buy a lottery ticket
<slashd> sil2100, thanks I appreciate it.
<slashd> ddstreet^^^^
-queuebot:#ubuntu-release- New binary: evolution [ppc64el] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [s390x] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
<sil2100> slashd: all done, looking good - I'll try to keep an eye out for vlan on trusty once it gets enough time in -proposed
-queuebot:#ubuntu-release- New binary: evolution [amd64] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [i386] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [armhf] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [arm64] (artful-proposed/universe) [3.24.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: klibc (trusty-proposed/main) [2.0.3-0ubuntu1.14.04.2 => 2.0.3-0ubuntu1.14.04.3] (core)
<slashd> sil2100, ok thanks much appreciated !
<slashd> ddstreet, ^^^^^^^
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (zesty-proposed) [0.23~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (trusty-proposed) [2.0.3-0ubuntu1.14.04.3]
<bdmurray> cyphermox: Is bug 1630285 fixed in Artful?
<ubot5> bug 1630285 in linux (Ubuntu) "mwifiex_pcie crashes after several bind/unbind" [Medium,Triaged] https://launchpad.net/bugs/1630285
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170509.1-0ubuntu0.14.04.1 => 1:20170613.2-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20170509.1-0ubuntu0.16.10.1 => 1:20170613.2-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170509.1-0ubuntu0.16.04.1 => 1:20170613.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170509.1-0ubuntu0.17.04.1 => 1:20170613.2-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170613.2-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20170613.2-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170613.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170613.2-0ubuntu0.17.04.1]
<slashd> sil2100, another quick question for you, about the percona-xtradb-cluster-5.5, what if I need to SRU a fix for a "real" Trusty only issue with this block package in trusty-proposed ?
<slashd> Mmike^
<slashd> sil2100, re: LP: #1657256 ^^
<ubot5> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<slangasek> are i386 autopkgtest runners stalled out?
<Laney> they are the same as the amd64 ones
<slangasek> Laney: any idea why the i386 queue is so much longer, then?
<sil2100> slashd: hm hm, normally we'd just drop the package that's in -proposed and release the new, trusty-only fix as is, but maybe it would be good to discuss with the wider SRU team if maybe we could include it on top of the -proposed changes
<Laney> the workers pick jobs from the queues in the order they connected to them
<sil2100> slashd: how far is the artful fix for 5.6 from being ready?
<Laney> that order is supposed to be randomised
<Laney> but maybe that isn't working, or maybe most of them randomly picked amd64
<infinity> sil2100: I'll attack more hwe stuff today.
<Laney> they will be processed sooner or later anyway
<slangasek> Laney: right, if we're confident they'll eventually processed, that's fine, but if there's an RNG bug that means i386 isn't being tried while there's anything in the amd64 queue, that's going to slow down transitions a fair amount
<slangasek> Laney: also there are a good number of items on http://autopkgtest.ubuntu.com/running showing a suspicious lack of output on amd64
<slangasek> e.g. kitemviews amd64 artful
<Laney> slangasek: The cloud VMs fail from time to time - they time out and get retried
<Laney> I see the normal queue is being processed in parallel to the huge one, and is much smaller - wouldn't expect it to be a particular problem for transitions
<Laney> maybe we misunderstood and the queues are consumed in some kind of sorted order or something
<Laney> the random.shuffle(queues) thing looks right to me
<Laney> https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/tree/worker/worker#n575
<slashd> sil2100, as of how far is the fix to 5.6, I'll need to discuss with Mmike tomorrow, he is eod now but I think it's still far from it, since no upstream fix is done yet
<slashd> sil2100, I'll resync with Mmike and will keep you posted.
<slangasek> Laney: what's the timeout on the cloud VMs, and what's the failure rate in your experience?
<tsimonq2> What's the process for requesting that a package be demoted to Universe from Main? I'm not finding docs on it...
<Laney> I get mail every 6 hours and there's usually a few in there
<Laney> Another thing that happens when the capacity is completely used is that we exceed our quota and back off
<slangasek> Laney: ah; who else do these mails go to besides you?
<nacc> tsimonq2: it's not being held by anything?
<Laney> nobody
<Laney> do you want them?
<slangasek> Laney: certainly seems like something more than one person should have eyes on.  Sure, you can include me
<slashd> sil2100, Mmike is here, just talk to him on another channel
<slangasek> tsimonq2: you don't request demotions; you unseed the package or remove its reverse-deps, and the rest takes care of itself
<slashd> Mmike, how far is the artful fix for 5.6 from being ready?
<nacc> slangasek: can you accept sphinx-celery from the queue for artful?
<tsimonq2> nacc: I'm wondering how complicated it would be to ask for the Qt packages to be demoted to Universe as Unity 8 is no longer a thing and the Qt people working for Canonical are no longer working there.
<tsimonq2> slangasek: ^
<apw> Laney, cirtianly my ppa bits got round robined with the huge ones
<nacc> tsimonq2: it should fallout naturally by removing seeds and revdeps
<nacc> tsimonq2: heh, exactly as slangasek just said, sorry!
<Laney> slangasek: ok, enjoy!
<slangasek> nacc: new python2 binary package, not present in Debian; it's not a slam dunk to accept this, no
<tsimonq2> nacc, slangasek: Is there an easy way to find rdeps for a package that are only in Main?
<slangasek> nacc: can you elaborate why it's needed?
<slangasek> tsimonq2: reverse-depends -c main; seeded-in-ubuntu
<tsimonq2> slangasek: Can that work with source packages or only binary ones?
<slangasek> tsimonq2: try and see, the commands have documentation :)
<tsimonq2> slangasek: ack, sorry
<cyphermox> bdmurray: yes, it is, since 0.13
<bdmurray> cyphermox: can you update the bug then?
<Laney> apw: yeah, but it looks like it is preferring amd64 within queues to me
<Mmike> slashd, sil2100, hey
<bdmurray> smoser: Can you add some regression potential information to bug 1692093?
<ubot5> bug 1692093 in cloud-init (Ubuntu Zesty) "Cloud init is re-executing fs and disk setup during reboot" [Medium,Confirmed] https://launchpad.net/bugs/1692093
<smoser> bdmurray, ack.
<Mmike> slashd: so, percona-5.6 fix is not close - the trusty-proposed one can go away and I'll propose the SRU for bug 1366997
<ubot5> bug 1366997 in percona-xtradb-cluster-5.5 (Ubuntu Trusty) "Duplicate entry error for primary key following cluster size change" [Undecided,In progress] https://launchpad.net/bugs/1366997
<slashd> sil2100, ^^
<nacc> slangasek: sure, sorry -- jamespage requested some help with openstack pike bits stuck in a-p. Specifically kombu in a-p (synced from experimental) needs a newer celery (LP: #1690688). Newer celery b-d on python{,3}-sphinx-celery in order to build it's documentation. But as I write this, I'm realizing that perhaps I can just use the python3 version. So nevermind! Sorry to waste your time. I'll ping
<ubot5> Launchpad bug 1690688 in sphinx-celery (Ubuntu) "kombu in artful-proposed incompatible with celery in artful" [Undecided,In progress] https://launchpad.net/bugs/1690688
<nacc> again later if this build fails :)
<smoser> bdmurray, done
<bdmurray> smoser: And bug 1692087 needs regression potential. Bug 1687712 needs all SRU info.
<ubot5> bug 1692087 in cloud-init (Ubuntu Zesty) "check_partition_layout has false positives when partitioned with gpt" [Medium,Confirmed] https://launchpad.net/bugs/1692087
<ubot5> bug 1687712 in cloud-init "cc_disk_setup: fs_setup with cmd doesn't work" [Medium,Confirmed] https://launchpad.net/bugs/1687712
<bdmurray> smoser: bug 1636345 is also missing SRU template
<ubot5> bug 1636345 in cloud-init "[Hyper-V][Azure] cloud-init on FreeBSD for Azure does not work" [Medium,Confirmed] https://launchpad.net/bugs/1636345
<sil2100> Oh
<sil2100> slashd, Mmike: ACK
<cyphermox> bdmurray: done
<Mmike> sil2100: thnx
<slashd> sil2100, thanks for you precious help
<bdmurray> Oh, that's not helpful that last bug has an "SRU information" attachment.
<slangasek> nacc: ok; will you reupload to drop this binary again and I can reject out?
<smoser> bdmurray, i will add one. i intended to not include that in the changelog
<smoser> as it is not related to ubuntu... its freebsd (other than regresion potential)
<smoser> i will add a template though
<nacc> slangasek: yeah, i've not yet uploaded the celery change, so you can reject please
<slangasek> nacc: ok
<nacc> slangasek: thanks for ... listening? :) you helped, regardless
<slangasek> :)
<bdmurray> smoser: okay, let me know when everything is set.
-queuebot:#ubuntu-release- New: rejected sphinx-celery [amd64] (artful-proposed) [1.3.1-1ubuntu1]
<smoser> bdmurray, done
<bdmurray> smoser: bug 1692087 was missed
<ubot5> bug 1692087 in cloud-init (Ubuntu Zesty) "check_partition_layout has false positives when partitioned with gpt" [Medium,Confirmed] https://launchpad.net/bugs/1692087
<smoser> missed ?
<bdmurray> I mentioned it was missing a regression potential and I don't see one yet.
<smoser> oh. i didnt see you had. sorry. only saw the first. added.h
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-153-g16a7302f-0ubuntu1~17.04.1]
<tjaalton> sil2100: hi, I managed to miss your ack of mesa for zesty, so maybe you could check the new bugfix version on the queue when you have time, and I'll get that one properly tested
<tjaalton> it's also the final version of 17.0.x series
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (yakkety-proposed) [0.23~16.10.1]
<bdmurray> cyphermox: and nplan 0.23 for xenial is meant to supersede the existing SRU?
<cyphermox> yup
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.23~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: evolution [ppc64el] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [s390x] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [amd64] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [i386] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [arm64] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [armhf] (artful-proposed/universe) [3.24.2-0ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: click (xenial-proposed/main) [0.4.43+16.04.20160203-0ubuntu2 => 0.4.43+16.04.20170613-0ubuntu1] (ubuntu-desktop) (sync)
<slangasek> jbicha: what's the rationale for adding a binary 'tests' package for evolution?
<jbicha> slangasek: it's for installed tests https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
<jbicha> you can see other examples by doing something like
<jbicha> apt-file search /usr/share/installed-tests/
<infinity> jbicha: I assume these are (or will be) run from autopkgtests?
<infinity> Since that's pretty much a perfect fit.
<jbicha> infinity: yes, I just hadn't finished testing them yet
<infinity> jbicha: Excellent.  Happy to see an upstream initiative that dovetails so nicely into downstream CI.
<jbicha> for instance, the new e-d-s installed-tests didn't completely pass reliably yet so I didn't want e-d-s's autopkgtests to start failing because of that
<infinity> Reminds me that we put a bunch of work into making the glibc tests runnable out-of-tree against the installed libc, but never quite hit the finish line.  I should revisit that.
<jbicha> infinity: are you interested in doing unity8-related removals or is xnox handling that?
<infinity> jbicha: I'm standing by for people to give me lists of packages and sign-offs and promises that party B won't yell at me five minutes after party A asks me to remove stuff.
<infinity> jbicha: But I also think slangasek and Laney were on the case as AAs (and, as you say, xnox as a core-dev working on lists).  So may be enough cooks in that kitchen.
<infinity> Err, Laney as release and slangasek as AA, I guess.
<jbicha> I probably should have waited until e-d-s 3.24 was in artful before dropping Ubuntu Online Accounts because address-book-service will need to be rebuilt or dropped to complete the transition
<slangasek> jbicha: I fail to see why this design requires the 'installed' tests to be part of a package; this could work just as well as build in tree, install just the tests to a local target, run against the packaged bits, and impose no overhead on the archive
<jbicha> I'm just doing the packaging; if you have concerns about installed tests, maybe you can ask the people who packaged the other tests before me?
<jbicha> but you don't have to build the source package to run these tests: that's kind of the point
#ubuntu-release 2017-06-14
<slangasek> those people didn't upload to a NEW queue that I help oversee
<jbicha> it sounds like you're trading burden on the archive mirrors (the package is very small) for burden on the autopkgtest builders
<slangasek> it's burden on every single system that downloads apt Packages files, not just the archive mirrors
<jbicha> *cough* nodejs *cough*
<slangasek> yes, that is the tradeoff - and I come down in favor of putting the burden on the autopkgtest runners
<slangasek> if you want to backdoor a binary package into the Ubuntu archive without having to justify it to an Ubuntu AA, you should upload it to Debian and sync it ;)
<jbicha> that's a major change in position and you should probably discuss that more widely
<slangasek> what is?
<jbicha> saying that you don't think installed-tests should be packaged
<slangasek> it's certainly not a change in position by me
<slangasek> infinity: ^^ since you seemed to not have the same concern I do?
<jbicha> I help maintain the evolution-data-server packaging in Debian and now that we're dropping UOA we're very close to being in sync (probably after 18.04 LTS for transitional pkgs)
<slangasek> Debian also allowed dumb -dbg packages into the archive for a very long time; that is also something I would not have allowed into the archive via an Ubuntu upload
<slangasek> cyphermox: SRU-release'ing klibc/yakkety before you can change your mind
<jbicha> I'm waiting for pkg-gnome to sponsor e-d-s 3.24 with the installed-tests for me, I've also begun the DD application process so I don't have to wait as much in the future :)
<Ukikie> slangasek: But really, the Debug archive doesn't have a trusted key in Ubuntu, nor commented out in /etc/apt/sources.list either, so that's really not ideal..
<slangasek> Ukikie: both of those are, at best, fixable bugs that don't warrant a design that requires every mirror to carry debug symbols and every user to download indices for them
<Ukikie> slangasek: I do agree, but as of yet they still aren't.
<slangasek> jbicha: I see Laney's name in the changelogs of some of the apt-file found packages, so I'll name drop him here in case he wants to defend the practice
<slangasek> Ukikie: yes, because they're a low priority due to the vanishingly small number of users affected... which just reinforces that they don't belong on the mirrors ;)
<jbicha> considering we have 50k+ packages for amd64 and 50k+ packages for i386, it doesn't seem worth trying to stop a couple more packages
<slangasek> "the archive is big so we should let it grow without bounds"
<jbicha> let's spend more time worrying about a .002% difference :)
<slangasek> well, I'm not spending any more time worrying about it; but I'm also not accepting that package from binary NEW
<slangasek> another AA can if they think it's ok
<infinity> Well, to be fair, if packaging out-of-tree testsuites was considered best practice, and all packages had tests, you'd be adding 15k packages to the archive or something.
<infinity> But that's probably a straw man as much as only looking at one specific addition is.
<infinity> slangasek: As for opinions on the matter, I'd agree that in a perfect world, we should have a tests archive that these -tests debs get shunted off to, that can be in the sources.list for autopkgtest runners.  I'm less convinced that the absence of that should lead to tests always being rebuilt.
<slangasek> infinity: the tradeoff I'm looking at here is that every Ubuntu machine downloads sources.list every day, and autopkgtests put load on a couple of machines a few times a cycle
<infinity> Machine time aside, given that autopkgtest is meant to be package-level regression tests, a prebuilt binary is better than effectively "testing" the toolchain with every re-run of your tests.
<jbicha> yes, a tests archive similar to the dbg archive is reasonable too
<slangasek> sure
<infinity> We could also slap them in another component, which I'm sure Colin would be thrilled to discuss.
<infinity> Mirror space here is really not a massive concern, IMO, the growth of Packages.gz *might* be, but I'm obviously less fussed about it than you are.
<infinity> (Plus, as you note, it'll flow in from Debian soon enough anyway, so if you really hate it, we should either discuss it in Debian, or we have an ugly road ahead of carrying deltas or automagic filtering to drop those packages in only Ubuntu)
-queuebot:#ubuntu-release- Unapproved: sudo (xenial-proposed/main) [1.8.16-0ubuntu1.4 => 1.8.16-0ubuntu1.5] (core)
-queuebot:#ubuntu-release- Unapproved: sudo (yakkety-proposed/main) [1.8.16-0ubuntu3.2 => 1.8.16-0ubuntu3.3] (core)
-queuebot:#ubuntu-release- Unapproved: sudo (zesty-proposed/main) [1.8.19p1-1ubuntu1.1 => 1.8.19p1-1ubuntu1.2] (core)
<tsimonq2> Wonderful, mass rebuilds in a Foundations PPA that has the same build priority as everything else so it clogs up the build queue when I want to build something :/
 * tsimonq2 shrugs and waits
<mwhudson> tsimonq2: sorry, the priority has been reduced now
<tsimonq2> mwhudson: Thanks
<mwhudson> tsimonq2: pity my team mates who are getting all the failure mails :)
<tsimonq2> mwhudson: lol
 * tsimonq2 mumbles something or other about Adam's large inbox
<tsimonq2> mwhudson: Well I'm building Qt right now, so apologies for clogging up the queue... :P
<mwhudson> hehe
<mwhudson> i'm about to be afk for a few hours anyway so...
<tsimonq2> lol
<cpaelzer> Hi AA's the text in bug 1694159 is rather crowded as it affects different packages in very different way
<ubot5> bug 1694159 in kimchi (Ubuntu) "Complete libvirt migration to Debian style packaging (dependencies, conffiles)" [High,Triaged] https://launchpad.net/bugs/1694159
<cpaelzer> But if there would be one around that could help me removing things from Artful that would be very kind
<cpaelzer> because unintentionally "hidden" in that bug is the request and reasoning to remove kimchi & ginger
<cpaelzer> I subscribed ubuntu-archive a while ago, but I see that you'll have to read a lot through the other content to see what is the todo for an AA there
<cpaelzer> therefore asking here
<infinity> cpaelzer: Done.  Want me to go ahead and remove nova and libvirt too? :P
<infinity> Pretty sure no one uses those.
<cpaelzer> infinity: thanks
<cpaelzer> infinity: if you do so for a short while I could take a break so why not :-P
<cpaelzer> I'll come back with more removes in ~1 week, but even then noether libvirt nor nova
<cpaelzer> :-)
<cpaelzer> or rather "neither" than noether
<infinity> I assumed that was an alternate spelling known only to your inner circle.
<cpaelzer> yeah my personal inner circle - I'm fat enough to have several
<infinity> Though, I'd expect it to be nÅther.
<cpaelzer> working from home is not good for your shape
<infinity> Dude, tell me about it.
<cpaelzer> I know we share that part
<infinity> I used to be thin as a rail when I started this gig.  I'm approaching beach ball shape.
<infinity> Which just makes it more efficient to roll from the office to the fridge.
<infinity> Which exacerbates the problem.
<cpaelzer> if I continue at the canonical rate I have so far I'll crack 200kg in 2025
<cpaelzer> ok next bug, ... thanks for the smiles you caused infinity
-queuebot:#ubuntu-release- Unapproved: rejected click [sync] (xenial-proposed) [0.4.43+16.04.20170613-0ubuntu1]
<apw> that thing is cursed
<Laney> slangasek: It makes sense. A good autopkgtest tests a non-moving target, which the -tests packages are.
<Laney> So yes. I defend it.
-queuebot:#ubuntu-release- Unapproved: click (xenial-proposed/main) [0.4.43+16.04.20160203-0ubuntu2 => 0.4.43+16.04.20170613-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted click [source] (zesty-proposed) [0.4.46+17.04.20170607.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted click [sync] (xenial-proposed) [0.4.43+16.04.20170613-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted click [source] (yakkety-proposed) [0.4.46+16.10.20170607.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: freeipa (zesty-proposed/universe) [4.4.3-3ubuntu2 => 4.4.3-3ubuntu2.1] (no packageset)
<beisner_> hi all - can i have an archive admin help move some new openstack pike packages along for us in the artful new queue?:
<beisner_> pypowervm, python-ovsdbapp, python-zunclient, python-deprecation, python-os-traits
<mapreri> so, today I wanted to pull off the opencv 3.1 transition, except that there is a buggy package (src:mldemos) that FTBFS, etc.  Can it be dropped out of release, and kept in proposed only?  Shall it be done before or after the opencv upload triggering the transition?
<mapreri> Also, is it a good time at all or there is something big going on, etc?
<mapreri> (test builds done at: https://launchpad.net/~mapreri/+archive/ubuntu/opencv-3.1.0-sync-test/+packages)
<apw> mapreri: I don't know of anything other than KDE clogging the ADT queues. You can start without the removal, it will just sit in -proposed until that is resolved one way or another.
<mapreri> apw: nice, ack.  So, I'll start (once I'm in a better situation, which might mean tomorrow, fwiw) :)
-queuebot:#ubuntu-release- New: accepted python-deprecation [source] (artful-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [amd64] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [armhf] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [ppc64el] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [amd64] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted evolution [armhf] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted evolution [ppc64el] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted evolution [arm64] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [s390x] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [i386] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted evolution [i386] (artful-proposed) [3.24.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [s390x] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted evolution [arm64] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New binary: python-deprecation [amd64] (artful-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-deprecation [amd64] (artful-proposed) [1.0.1-0ubuntu1]
<clivejo> apw: regarding the epochs.  We missed the 16.08 release which included those packages in kdepim, then in 16.12 they got split out of src:kdepim and into brand new packages
<clivejo> https://community.kde.org/Applications/16.12_Release_Notes
<clivejo> kdepim (split into akonadi-calendar-tools, akonadiconsole, akonadi-import-wizard, akregator, blogilo, grantlee-editor, kaddressbook, kalarm, kmail, kmail-account-wizard, knotes, kontact, korganizer, mbox-importer, pim-data-exporter, pim-sieve-editor, pim-storage-service-manager)
-queuebot:#ubuntu-release- Unapproved: btrfs-tools (xenial-proposed/main) [4.4-1 => 4.4-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.11 => 2.02~beta2-36ubuntu3.12] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.11 => 1.66.12] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (yakkety-proposed/main) [1.74.3 => 1.74.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.3 => 2.02~beta2-36ubuntu11.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2.1 => 2.02~beta3-4ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (zesty-proposed/main) [1.80.1 => 1.80.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.31+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.31+16.10]
-queuebot:#ubuntu-release- Unapproved: munge (xenial-proposed/universe) [0.5.11-3 => 0.5.11-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: munge (trusty-proposed/universe) [0.5.11-1ubuntu1 => 0.5.11-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.31]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.8-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.8-0ubuntu1~16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (zesty-proposed) [2.0.8-0ubuntu1~17.04.2]
-queuebot:#ubuntu-release- Unapproved: hw-detect (xenial-proposed/main) [1.117ubuntu2.1 => 1.117ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: hw-detect (yakkety-proposed/main) [1.117ubuntu3 => 1.117ubuntu3.1] (core)
<ahoneybun> anyway to get https://babe.kde.org/ into the archive?
<ahoneybun> we have debs on our KCI
-queuebot:#ubuntu-release- Unapproved: accepted munge [source] (xenial-proposed) [0.5.11-3ubuntu0.1]
<jbicha> ahoneybun: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<jbicha> please file a bug and subscribe ~ubuntu-sponsors
-queuebot:#ubuntu-release- Unapproved: accepted munge [source] (trusty-proposed) [0.5.11-1ubuntu1.1]
<ahoneybun> looking at that list makes me think I don't have a chance tbh jbicha
<ahoneybun> almost 2000
<jbicha> 2000 what?
<ahoneybun> requested packages
<jbicha> Debian has 3000+ but new packages get in Debian all the time
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.3]
<jbicha> once you have the packaging done and subscribe ubuntu-sponsors, this is the list that will matter first: http://reqorts.qa.ubuntu.com/reports/sponsoring/
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (yakkety-proposed) [2.28.2-1ubuntu1.2]
<jbicha> although it looks a bit bad, stuff does get sponsored from there regularly
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (zesty-proposed) [2.29-1ubuntu2.1]
<ahoneybun> mm we'll see
<ahoneybun> https://bugs.launchpad.net/ubuntu/+bug/1698009
<ubot5> Ubuntu bug 1698009 in Ubuntu "[needs-packaging] Babe-Qt" [Undecided,New]
<jbicha> please mention on the bug where the packaging can be found
<ahoneybun> our packaging our the upstream code?
<acheronuk> ahoneybun: is babe getting a release?
<ahoneybun> well it's beta right now
<ahoneybun> 0.5 Beta
<acheronuk> ahoneybun: beta release tarballs?
<acheronuk> don't see anything @ https://download.kde.org/unstable/
<clivejo> there been no releases
<ahoneybun> yea I know
#ubuntu-release 2017-06-15
<slangasek> why would subsequent invocations of xvfb-run fail on container-based autopkgtest runners, but not the first invocation?  http://autopkgtest.ubuntu.com/packages/p/pytest-qt/artful/s390x http://autopkgtest.ubuntu.com/packages/p/pytest-qt/artful/armhf
<xnox> interesting, i wonder if we can get more logs out of the host as to when this happens - e.g. things closed and cleaned and not allowed to be reopened. but that looks really weird. it does not look like multiple xvfb-run are run in parallel as it should exit first.
<xnox> it uses the same TMP directory, maybe something needs to be cleaned up and isn't for the subsequent runs?
<xnox> this needs a task opened, adding to trello.
-queuebot:#ubuntu-release- New binary: network-manager [amd64] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: network-manager [s390x] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: network-manager [ppc64el] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: network-manager [i386] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: network-manager [arm64] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: network-manager [armhf] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted network-manager [amd64] (artful-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted network-manager [armhf] (artful-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted network-manager [ppc64el] (artful-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted network-manager [arm64] (artful-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted network-manager [s390x] (artful-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted network-manager [i386] (artful-proposed) [1.8.0-3ubuntu1]
<Saviq> hi release team :) can someone please have a look at the mir SRUs into xenial, yakkety, zesty - they've been aging for 8 days in -proposed now - thanks!
 * apw looks
<apw> Saviq, done
<Saviq> apw, fantastic, thank you!
-queuebot:#ubuntu-release- New binary: haskell-code-page [ppc64el] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-raw-loader [amd64] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pysodium [amd64] (artful-proposed/universe) [0.6.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-useragent [amd64] (artful-proposed/universe) [0.16.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-say [ppc64el] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-email-reply-trimmer [amd64] (artful-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: printer-driver-oki [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-spa-ita [amd64] (artful-proposed/universe) [0.2.0~r78826-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-code-page [i386] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-typed-process [ppc64el] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-enhanced-resolve [amd64] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-puerkitobio-goquery [amd64] (artful-proposed/universe) [1.1.0+git20170324.3.ed7d758-1] (no packageset)
-queuebot:#ubuntu-release- New binary: humanfriendly [amd64] (artful-proposed/universe) [3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-code-page [s390x] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: parsley-clojure [amd64] (artful-proposed/universe) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-say [i386] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-code-page [amd64] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-typed-process [i386] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-typed-process [amd64] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ajv-keywords [amd64] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-code-page [arm64] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-code-page [armhf] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-say [armhf] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-say [amd64] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-typed-process [armhf] (artful-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted apertium-spa-ita [amd64] (artful-proposed) [0.2.0~r78826-1]
-queuebot:#ubuntu-release- New: accepted golang-github-puerkitobio-goquery [amd64] (artful-proposed) [1.1.0+git20170324.3.ed7d758-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [arm64] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [i386] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [s390x] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [amd64] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [ppc64el] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-code-page [armhf] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted humanfriendly [amd64] (artful-proposed) [3.2-1]
-queuebot:#ubuntu-release- New: accepted node-enhanced-resolve [amd64] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted parsley-clojure [amd64] (artful-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New: accepted pysodium [amd64] (artful-proposed) [0.6.11-1]
-queuebot:#ubuntu-release- New: accepted ruby-useragent [amd64] (artful-proposed) [0.16.8-1]
-queuebot:#ubuntu-release- New: accepted node-ajv-keywords [amd64] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted printer-driver-oki [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-raw-loader [amd64] (artful-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-email-reply-trimmer [amd64] (artful-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New binary: haskell-lambdahack [amd64] (artful-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdahack [ppc64el] (artful-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdahack [i386] (artful-proposed/universe) [0.5.0.0-1] (no packageset)
<tsimonq2> I'm curious why only one of the s390x builders are running right now when the rest are marked as "Idle"...
<tsimonq2> s/running/building a package/
<tsimonq2> And there's other packages in the queue.
<tsimonq2> And now plasma-workspace is stuck where it is.
<tsimonq2> cjwatson, wgrant: ^^^
<acheronuk> seems a lot of builds have just froze
<acheronuk> or appear to have done at least viewing their status, even if they really have not
 * acheronuk wonders if tsimonq2 broke launchpad
 * tsimonq2 wonders if acheronuk broke Launchpad
<tsimonq2> :P
 * acheronuk examines the relative probability there
<acheronuk> nah, my bet's still on you :P
<santa_> hi
<tsimonq2> acheronuk: Your CI uploads thousands of packages in a given week, I'll upload maybe 50 on a good week if I'm lucky :P
 * tsimonq2 thinks acheronuk has been throwing things at Launchpad!
<acheronuk> not many recently. not midnight yet
<tsimonq2> lol
<santa_> apw, slangasek: thank you very much for looking into our kubuntu's packages. would be possible to ignore the akonadi test failure, so we can see if the rest of kdepim gets out of -proposed? http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.3_artful_proposed_migration.pdf
<santa_> we would upload kde applications 17.04.x but I think it would be nice if we get the current 16.12.3 out of proposed before doing that
<acheronuk> santa_: it would, but I fear it may need a lot of deleting of old binaries on architectures where PIM now depwaits due to no qtwebengine
<acheronuk> or at least I discussed that with apw, and came to that conclusion
<Laney> you DoSed the test queues with a version you knew would be obsolete very shortly? :/
<slangasek> santa_: my stock answer for "could we ignore autopkgtest failure for <foo>" is "no".  Who is fixing the akonadi tests?
<santa_> Laney: the tests were already completed a while ago. in fact the thing was already uploaded a while ago, but some packages were new and they weren't accepted for a while
<Laney> santa_: ok, so not the tests that are still draining out now
<acheronuk> tsimonq2: gonna give up for tonight I think. LP builds look stuffed
<tsimonq2> acheronuk: Ah ok
<santa_> slangasek: right now I can't reproduce the akonadi test failures locally, and I think if there's anything to fix, it would be better to fix it in >= 17.04
<slangasek> santa_: are we not talking about 17.04 here?
<acheronuk> tsimonq2: as soon as I wander off and do something else, it'll probably all fix itself :P
<tsimonq2> acheronuk: lol
<slangasek> >= 17.04, I mean (17.10)
<tsimonq2> acheronuk: I'll ping on Telegram if it gets unclogged
<acheronuk> slangasek: that is KDE applications version 17.04. they use a similar versioning scheme to ubuntu for their apps
<tsimonq2> Speaking of that, any archive admin know what's up?
<slangasek> eh
<acheronuk> slangasek: https://www.kde.org/announcements/announce-applications-17.04.0.php
<santa_> slangasek: right now we have kde apps 16.12.3 in the archive, I mean if we are going to touch something wrt akonadi it would be better to work on *akonadi* >= 17.04.x
<santa_> because this way we would be able to get help from fellow kde developers
<slangasek> santa_, acheronuk: no test is better than a useless and constantly failing test.  uploaders have the means to resolve autopkgtest failures without involving the release team, so for me it's a low priority to investigate and override a failure to let things migrate sooner
<santa_> slangasek: we could upload a new package version disabling the test in question as a temporary solution then
<santa_> acheronuk: â
<acheronuk> santa_: perhaps, as long as we are testing somewhere outside ubuntu infra in a sane/valid way to confirm they pass in that
<acheronuk> past stuff I tested passed locally, or in lxc adt test envs, but oddly failed on ubuntu infra.
<acheronuk> ideally would fix everywhere, but don't have infinite time to spend on this
<cjwatson> tsimonq2,acheronuk: forked discussion, only replying on #launchpad
<tsimonq2> cjwatson: gracias
-queuebot:#ubuntu-release- New binary: haskell-lambdahack [armhf] (artful-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20170523-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20170523-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20170523-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20170523-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (zesty-proposed) [1.138ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (yakkety-proposed) [1.138ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.4]
-queuebot:#ubuntu-release- Unapproved: accepted libepoxy [source] (zesty-proposed) [1.3.1-1ubuntu1.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-fastimport [source] (zesty-proposed) [0.9.6-2ubuntu17.04.1]
-queuebot:#ubuntu-release- New binary: iptables [ppc64el] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: iptables [amd64] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: iptables [s390x] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: iptables [i386] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: iptables [arm64] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: iptables [armhf] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted btrfs-tools [source] (xenial-proposed) [4.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20170524.0.ea2fe2b0-0ubuntu0.16.04.1]
#ubuntu-release 2017-06-16
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20170524.0.ea2fe2b0-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.4]
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3.17.04.2 => 3.22.7-0ubuntu3.17.04.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted python-ovsdbapp [source] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted exabgp [amd64] (artful-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdahack [armhf] (artful-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdahack [i386] (artful-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdahack [amd64] (artful-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-say [amd64] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-say [i386] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-typed-process [amd64] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-typed-process [i386] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdahack [ppc64el] (artful-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-say [ppc64el] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-typed-process [ppc64el] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-say [armhf] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-typed-process [armhf] (artful-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted iptables [amd64] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted iptables [armhf] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted iptables [ppc64el] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted iptables [arm64] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted iptables [s390x] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted iptables [i386] (artful-proposed) [1.6.0+snapshot20161117-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-pypowervm [source] (artful-proposed) [1.1.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-zunclient [source] (artful-proposed) [0.2.0-0ubuntu1]
<slangasek> infinity: I see that didrocks has uploaded livecd-rootfs to revert to using tasks instead of metapackages for ubuntu-desktop; as I recall we wanted to switch this so that there was minimal code delta between HWE point release builds and other builds; does this need discussed?
-queuebot:#ubuntu-release- New binary: dms [amd64] (artful-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poppass-cgi [amd64] (artful-proposed/universe) [3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: west-chamber [s390x] (artful-proposed/universe) [20100405+svn20111107.r124-7] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [i386] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: node-string-decoder [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [ppc64el] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: west-chamber [ppc64el] (artful-proposed/universe) [20100405+svn20111107.r124-7] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [ppc64el] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: west-chamber [i386] (artful-proposed/universe) [20100405+svn20111107.r124-7] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [arm64] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [arm64] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: win-iconv [amd64] (artful-proposed/universe) [0.0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [s390x] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [s390x] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: west-chamber [amd64] (artful-proposed/universe) [20100405+svn20111107.r124-7] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [armhf] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [amd64] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [amd64] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-mouse [armhf] (artful-proposed/universe) [1:1.9.2-1] (xorg)
-queuebot:#ubuntu-release- New binary: xserver-xorg-input-keyboard [i386] (artful-proposed/universe) [1:1.9.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: python-pypowervm [amd64] (artful-proposed/universe) [1.1.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dms [amd64] (artful-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted poppass-cgi [amd64] (artful-proposed) [3-6]
-queuebot:#ubuntu-release- New: accepted west-chamber [i386] (artful-proposed) [20100405+svn20111107.r124-7]
-queuebot:#ubuntu-release- New: accepted west-chamber [s390x] (artful-proposed) [20100405+svn20111107.r124-7]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [amd64] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [armhf] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [ppc64el] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [amd64] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [armhf] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [ppc64el] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted node-string-decoder [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted west-chamber [ppc64el] (artful-proposed) [20100405+svn20111107.r124-7]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [arm64] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [s390x] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [i386] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted west-chamber [amd64] (artful-proposed) [20100405+svn20111107.r124-7]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-keyboard [i386] (artful-proposed) [1:1.9.0-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [s390x] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted win-iconv [amd64] (artful-proposed) [0.0.8-2]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-input-mouse [arm64] (artful-proposed) [1:1.9.2-1]
-queuebot:#ubuntu-release- New: accepted python-pypowervm [amd64] (artful-proposed) [1.1.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-zunclient [amd64] (artful-proposed/universe) [0.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [amd64] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [armhf] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [ppc64el] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [arm64] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [s390x] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xview [i386] (artful-proposed/universe) [3.2p1.4-28.2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-readable-stream [amd64] (artful-proposed/universe) [2.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ovsdbapp [amd64] (artful-proposed/universe) [0.4.0-0ubuntu2] (no packageset)
<jamespage> any SRU team members around who could look at the various openstack related SRU's across xenial, yakkety and zesty that need review/acceptance into -proposed?
<apw> jamespage, man that is a lot of packages
<jamespage> apw: yup
<jamespage> apw: thankfully that's the last set of xenial stable point releases as the release is EOL upstream
<jamespage> apw: but we're typically looking at N projects x 3 releases for stable points at the start of each month
<jamespage> hence the volume; I generally spend a day on SRU prep across all three upstream supported releases near the start of the month
<infinity> slangasek: livecd-rootfs in xenial is also using tasks now.  I found a more clever/evil way to do the HWE bits.
<infinity> slangasek: I should have sorted the devel series at the same time, but apparently forgot to look into it.
<infinity> slangasek: (or maybe thought it had already been done)
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (zesty-proposed) [2:10.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (zesty-proposed) [1:8.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-readable-stream [amd64] (artful-proposed) [2.2.11-1]
-queuebot:#ubuntu-release- New: accepted xview [arm64] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- New: accepted xview [i386] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- New: accepted xview [s390x] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- New: accepted xview [amd64] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- New: accepted xview [ppc64el] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- New: accepted xview [armhf] (artful-proposed) [3.2p1.4-28.2]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (zesty-proposed) [2:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (zesty-proposed) [15.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (zesty-proposed) [2:15.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.2-0ubuntu1 => 2:15.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected swift [source] (zesty-proposed) [2.13.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (zesty-proposed) [3:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (zesty-proposed/main) [2.13.0-0ubuntu1 => 2.13.1-0ubuntu0.17.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: node-stream-browserify [amd64] (artful-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stream-http [amd64] (artful-proposed/universe) [2.7.1+dfsg-1] (no packageset)
<jamespage> any archive admins around who could accept the NEW binaries for python-zunclient  and python-ovsdbapp into artful please?
<apw> want want want, where's the bribes ?
-queuebot:#ubuntu-release- New: accepted node-stream-browserify [amd64] (artful-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-stream-http [amd64] (artful-proposed) [2.7.1+dfsg-1]
 * acheronuk offers apw a chocolate hobnob
<apw> better
-queuebot:#ubuntu-release- New: accepted python-ovsdbapp [amd64] (artful-proposed) [0.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-zunclient [amd64] (artful-proposed) [0.2.0-0ubuntu1]
<apw> jamespage, ^
<jamespage> apw: thankyou!
<jamespage> apw: perpetual gratitude and beer next time we meet
<apw> heheh
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170613.2-0ubuntu0.14.04.1 => 1:20170616.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20170613.2-0ubuntu0.16.10.1 => 1:20170616.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170613.2-0ubuntu0.16.04.1 => 1:20170616.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170613.2-0ubuntu0.17.04.1 => 1:20170616.1-0ubuntu0.17.04.1] (no packageset)
<doko> apw: I've now uploaded again binutils, being stuck because of failing linux autopkg tests ...
<apw> doko: blame apparmor ... sigh
<apw> doko: will have a look in a little
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20170616.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170616.1-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170616.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170616.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: capnproto (xenial-updates/universe) [0.5.3-2ubuntu1 => 0.5.3-2ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted capnproto [sync] (xenial-updates) [0.5.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (zesty-proposed) [2.13.1-0ubuntu0.17.04.1]
<Ukikie> Seems both firefox and adobe-flashplugin were missed from artful.
<infinity> Ukikie: Missed how?
<infinity> https://launchpad.net/ubuntu/+source/adobe-flashplugin/1:20170616.1-0ubuntu1
<Ukikie> infinity: Yep, my bad.  Just firefox 54.
<apw> yep it does not appear to have been copied forward, not that we are meant to be copying forward any more
<infinity> Not that it would migrate anyway, due to armhf being FTBFS.
<infinity> And ppc64el.
<infinity> *sigh*
<infinity> Maybe I'll copy it to artful-security.
<Ukikie> Sure, but since it always fails on those arches, if you enable proposed you'll get updates.
<infinity> If you enable proposed in a devel series, you're asking for a broken machine.
<Ukikie> Yep, that's why I use http://paste.openstack.org/show/612878
<jbicha> infinity: should we just delete the binaries on those arches for Firefox given that we've effectively been ignoring the build failures for several months now?
<Ukikie> s/months/releases/
<infinity> jbicha: Or fix the failures.
<infinity> Ukikie: Not several releases.
<Ukikie> Eh, I'm likely overgeneralizing FTBFS issues on those arches, you're right.
<Ukikie> infinity: Anyway, thanks for looking into it.
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.1 => 2.20.4-0ubuntu4.2] (core)
<slangasek> infinity: so... strace now ftbfs on ppc64el with "invalid system call 'kexec_file_load'", where it succeeded before. any idea what that's about?  I'm not sure if it's a runtime kernel issue or a linux-libc-dev issue
#ubuntu-release 2017-06-17
-queuebot:#ubuntu-release- New binary: yazpp [amd64] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yazpp [ppc64el] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yazpp [i386] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yazpp [s390x] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yazpp [arm64] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yazpp [armhf] (artful-proposed/universe) [1.6.5-0ubuntu1] (no packageset)
<infinity> slangasek: That's almost sure to be linux-libc-dev.
<infinity> slangasek: Possibly a missing CONFIG_KEXEC_FILE
<infinity> Though, that seems to be enabled.
<infinity> slangasek: Oh, no.  Other way around.  4.11 wired up that syscall, so linux-libc-dev exposes it, but the testsuite assumes the running kernel should also have it.
<infinity> slangasek: I think.
-queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.3-0ubuntu0.1 => 1.48.4-0ubuntu0.1] (desktop-extra, mozilla, ubuntugnome)
<infinity> slangasek: Fix uploaded.
<infinity> slangasek: And forwarded.
<slangasek> infinity: cheers!
<slangasek> looks like someone's been retrying neutron/s390x autopkgtest a fair bit; any reason to believe this is eventually going to pass?  (also, why is the test against the -proposed version of neutron?)
<slangasek> the autopkgtest could certainly do with more useful output than 'see journalctl -xe for details'
<slangasek> right, passed now with the artful neutron (by hinting to install iptables from -proposed)
#ubuntu-release 2018-06-11
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.32.9 => 2.33] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.32.9+17.10 => 2.33+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32.9+18.04 => 2.33+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.32.9~14.04 => 2.33~14.04] (no packageset)
 * apw is handling snapd ^
<sil2100> apw: thanks!
<caribou> Hello everyone, his this the appropriate place to get in touch with the SRU team or #ubuntu-devel is better ?
<apw> caribou, you should find the SRU team here i recon
<caribou> apw: morning, I'll repost my question here then :
<caribou> There is a dependency issue b/w  kdump-tools (in -updates) and kexec-tools (-proposed) which makes the installation of the linux-crashdump meta-package to fail (Xenial)=
<caribou> kdump-tools is depending on the version of kexec-tools which is still in -proposed
<apw> that is bad
<LocutusOfBorg> guys, does ubuntu 18.10 use merged usr?  https://salsa.debian.org/installer-team/debootstrap/merge_requests/5
<gitlab-bot> Debian Installer bug (Merge request) 5 in debootstrap "Re-enable merged-usr by default (after stretch release)" (comments: 5) [Opened]
<apw> sil2100, ^ i think you might have been playing along with those
<caribou> apw: at least this is my two minute analysis of the situation; when I add -proposed to the sources.list, it installs correctly
<LocutusOfBorg> lets not break debootstrap :)
<LocutusOfBorg> maybe slangasek has an opinion on merged usr? https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge
<LocutusOfBorg> I would say to enable it, unless anybody speaks otherwise, it seems to have been done in quantal according to wiki, maybe just not enabled
<sil2100> ugh
<sil2100> apw, caribou: let me take a look
<caribou> apw: thanks!
<sil2100> Ah ah, this is unexpected
<sil2100> apw: could you by any chance be able to verify LP: #1743529 ?
<ubot5> Launchpad bug 1743529 in The Ubuntu-power-systems project "Merge kexec-tools 2.0.16-1 from Debian: System hung with Kernel panic -not syncing: Out of memory message when crash is triggered." [High,In progress] https://launchpad.net/bugs/1743529
<sil2100> Since today I released makedumpfile which causes the issue, which got built in -proposed so against the new kexec-tools
<sil2100> And we'd need to release that
<sil2100> I guess we need to set phasing of makedumpfile to 0
 * sil2100 looks into how to do that
<sil2100> apw: ok, I guess I can use change-override to set the phased percentage - but do you know how to re-enable phasing afterwards?
<sil2100> apw: ok, I have overriden the phased percentage of makedumpfile to 0 so that users don't encounter more upgrade problems
<sil2100> caribou: ^
<sil2100> Now we need someone to verify the kexec-tools package so we can release it
<caribou> sil2100: ok, I'll check
<sil2100> caribou: if you got the package then I guess this won't change a thing for you, but new users won't encounter the bug
<sil2100> The real fix is getting kexec-tools verified and released ASAP
<apw> sil2100, concur
<caribou> @sil2100 I don't know if there is some kind of delay, but purging  cleaning, apt update & apt install does the same thing
<sil2100> caribou: as said, if you got the update already, you probably will just have it
<sil2100> But yeah, I don't know much about the phased upgrades mechanisms myself
<caribou> sil2100: not sure that it is all the problem, I'm still looking at it
<caribou> sil2100: yes, there is more to it :
<caribou> apt install kdump-tools :
<caribou> kdump-tools : Depends: kexec-tools (>= 1:2.0.10-2) but it is not going to be installed
<caribou> if you apt install kdump-tools kexec-tools, there is even more details :
<caribou> kdump-tools : Depends: kexec-tools (>= 1:2.0.10-2) but 1:2.0.10-1ubuntu2.5 is to be installed*
<caribou> The SRU will release 1:2.0.16-1ubuntu1~16.04.1 which will still fail
<caribou> oh, wait it .16 not .10
<sil2100> Should work
<caribou> @sil2100 so the answer is to override the phased percentage of kdump-tools as well (built from makedumpfile) which is the one that fails
<caribou> yes it will, my mistake
<sil2100> caribou: ah! And I did a mistake as well, I thought I have overriden all binaries of the source but I didn't
<sil2100> Now it's good
<sil2100> cascardo: hey! Maybe you could help out with getting LP: #1743529 verified?
<ubot5> Launchpad bug 1743529 in The Ubuntu-power-systems project "Merge kexec-tools 2.0.16-1 from Debian: System hung with Kernel panic -not syncing: Out of memory message when crash is triggered." [High,In progress] https://launchpad.net/bugs/1743529
<cascardo> sil2100: so, the makedumpfile and kexec-tools updates are "interlocked"
<cascardo> IIRC, makedumpfile in -proposed has a Breaks on kexec-tools on GA/-updates, so you have to release both of them from -proposed
<cascardo> but I see, you want a verify of the kexec-tools bug so you can release it
<apw> cascardo, one has already escaped ...
<cascardo> apw: yah, I noticed that, not sure how one could have verified one without verifying the other, but will do the verification needed myself
<apw> cascardo, indeed
<sil2100> cascardo: if both had the same bug number and multiple tasks, I'd know not to release one without the other
<sil2100> cascardo: but here they seemed disconnected, at least from the bug perspective - which is what I'm looking at mostly before releasing an update
<sil2100> Maybe I should have drilled deeper
<cascardo> sil2100: I could have warned about it first, as well
<cascardo> booting xenial here so I can verify it, will do artful next
<cascardo> sil2100: done on xenial
<sil2100> cascardo: thanks!
<sil2100> Now, I need to figure out how to remove the phased percentage override
<sil2100> cjwatson: hey, maybe you'll know: I have overriden a package's phase percentage to 0 through change-override - are overrides of such things handled specially, e.g. do I need to somehow 'disable' the override for things to start phasing again?
<sil2100> cjwatson: or does doing .changeOverride() only simply modify the value?
<rbasak> There's a bzr branch for overriding phase stops IIRC
<rbasak> One moment
<rbasak> https://code.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides
<rbasak> sil2100: is that what you're after?
<rbasak> Actually I think it isn't, sorry
<cascardo> sil2100: now, also verified on artful
<cjwatson> sil2100: .changeOverride() only sets the current value; actual phasing processes are handled outside Launchpad
<cjwatson> I don't recall exactly where
<sil2100> cjwatson: ah, ok then!
<sil2100> rbasak: oh, didn't know about it, I already used change-override for this
<sil2100> I guess my change only stopped it for one moment then
<sil2100> ANyway, let me release makedumpfile, switch phasing of the other packages to 10 (as per default) and see how this goes
<rbasak> sil2100: I think that has the inverse sense though. It's for override of automatic phasing stops
<sil2100> s/makedumpfile/kexec-tools
<sil2100> Ah, or that
<apw> i thought setting phasing to 0 was the right thing to do to stop it letting anyone having it 'later'
<apw> and that once it was 0 it didn't increment automatically any more
-queuebot:#ubuntu-release- Unapproved: lastpass-cli (bionic-proposed/universe) [1.0.0-1.2ubuntu1 => 1.0.0-1.2ubuntu2] (no packageset)
<apw> not that that stops anyone not using update-manager
<rbasak> I wonder how that interacts with automatic phasing though
<sil2100> apw: hm, would be good if we had that documented
<rbasak> Does the automatic phaser "call" change-override?
<sil2100> rbasak: the phaser I guess uses .changeOverride() directly
<rbasak> bdmurray will know: ^
<sil2100> Which is what change-override does
<rbasak> That suggests to me that the phaser needs a second override "blacklist"
<sil2100> Anyway, I'd really like these things to be documented, I saw nothing about stopping phasing on the SRU page
<rbasak> Unless it automatically detects a phase of 0 means "don't touch"
<sil2100> rbasak: from what apw is writing it might be doing just that
<sil2100> But bdmurray will know more
<apw> the code is in ubuntu-archive-tools
<apw> and 0 does look to be special
<rbasak> FWIW, we've had a similar problem with grub2-signed before. I think we should adjust sru-release to have a known list of sets that should go together and require a specific force to do anything but release them together
<sil2100> britney would have caught this
<apw> well we should be checking the britney output
<apw> which is running and (as sil2000 says) should have been telling us to release them together
<apw> i wonder if there is any way we could get that information surfaced in the penidng-sru report
<apw> uggg, i sound like a manager
<Laney> The end goal is presumably to *use* proposed-migration to release SRUs?
<apw> yes, though we have been talking about that definatly happening for new releases for at least 2
<sil2100> caribou: hopefully your problems should be over soon ;)
<apw> i think it was deemed too gnarly to retrofit to releases we have simply sru-released a bunch of stuff to
<Laney> I mean if people are going to work on SRU tooling, maybe those blockers would be a good use of effort
<Laney> not that I'm (a) in the team (b) knowledgable of what the problems are
<Laney> :P
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (artful-proposed/partner) [1:20180508.1-0ubuntu0.17.10.1 => 1:20180607.1-0ubuntu0.17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180508.1-0ubuntu0.14.04.1 => 1:20180607.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180508.1-0ubuntu1 => 1:20180607.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180508.1-0ubuntu0.16.04.1 => 1:20180607.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20180607.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180607.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180607.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20180607.1-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: apache2 (bionic-proposed/main) [2.4.29-1ubuntu4.1 => 2.4.29-1ubuntu4.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: apache2 (artful-proposed/main) [2.4.27-2ubuntu4.1 => 2.4.27-2ubuntu4.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (bionic-proposed/main) [3.28.0-0ubuntu2 => 3.28.0-0ubuntu2.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: apache2 (xenial-proposed/main) [2.4.18-2ubuntu3.8 => 2.4.18-2ubuntu3.9] (ubuntu-server)
<slangasek> LocutusOfBorg: merged usr was a topic of conversation at the Foundations engineering sprint this past week.  I believe the conclusion is that there's no value to our users in doing this by default in advance of Debian doing it.
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.1 => 18.04.14.2] (core)
<LocutusOfBorg> slangasek, isn't this the default now in Debian?
<LocutusOfBorg> slangasek, isn't this the default now in Debian?
<LocutusOfBorg> (see the pull request)
<slangasek> what pull request?
<slangasek> infinity, xnox: ^^ redirecting to you anyway, since this was primarily the two of you having that discussion
<LocutusOfBorg> https://salsa.debian.org/installer-team/debootstrap/merge_requests/5
<LocutusOfBorg> this one
<gitlab-bot> Debian Installer bug (Merge request) 5 in debootstrap "Re-enable merged-usr by default (after stretch release)" (comments: 6) [Opened]
<slangasek> LocutusOfBorg: "according to @vorlon this has been implemented in Ubuntu quantal" - uhm what?
<slangasek> LocutusOfBorg: the header on that wiki page says "draft"
<slangasek> LocutusOfBorg: also, if you look at the page history, I didn't write any of this. :P
-queuebot:#ubuntu-release- New: accepted ndctl [source] (cosmic-proposed) [60.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ndctl [amd64] (cosmic-proposed/none) [60.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-json-iterator-go [amd64] (cosmic-proposed/none) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [ppc64el] (cosmic-proposed/none) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-modern-go-concurrent [amd64] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [amd64] (cosmic-proposed/universe) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [i386] (cosmic-proposed/universe) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [arm64] (cosmic-proposed/universe) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [armhf] (cosmic-proposed/universe) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zypper [s390x] (cosmic-proposed/universe) [1.14.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3 => 0.130ubuntu3.1] (core)
<LocutusOfBorg> slangasek, lol, your name was written on that page :)
<LocutusOfBorg> I updated the ticket, please ack the change :)
<slangasek> LocutusOfBorg: yes, xnox likes to blame me for a lot of things
<LocutusOfBorg> :)
<LocutusOfBorg> you should be proud of so many pokes! :)
<xnox> slangasek, what the quantal?! LocutusOfBorg - your comment does not make sense at all.
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.9 => 1.34.9.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.1]
-queuebot:#ubuntu-release- New binary: myspell-lv [amd64] (cosmic-proposed/none) [0.9.6-8] (personal-gunnarhj, ubuntu-desktop)
#ubuntu-release 2018-06-12
-queuebot:#ubuntu-release- New binary: ell [amd64] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [ppc64el] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [i386] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [s390x] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cctools [amd64] (cosmic-proposed/universe) [6.2.9-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [armhf] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cctools [s390x] (cosmic-proposed/universe) [6.2.9-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [arm64] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted bolt-lmm [amd64] (cosmic-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ell [arm64] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [i386] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [s390x] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [arm64] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted ell [i386] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted ell [s390x] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted ell [amd64] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [ppc64el] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [armhf] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted ell [armhf] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted ell [ppc64el] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted ell [amd64] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted genometester [amd64] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted genometester [armhf] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted genometester [ppc64el] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-dnephin-cobra [amd64] (cosmic-proposed) [1.5.1+git20170113.0.0e9ca70-3]
-queuebot:#ubuntu-release- New: accepted golang-github-modern-go-concurrent [amd64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted pyaxmlparser [amd64] (cosmic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted uhd [amd64] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [armhf] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [ppc64el] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted watson [amd64] (cosmic-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted genometester [arm64] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted genometester [s390x] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted myspell-lv [amd64] (cosmic-proposed) [0.9.6-8]
-queuebot:#ubuntu-release- New: accepted uhd [arm64] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [s390x] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted genometester [i386] (cosmic-proposed) [4.0-1]
-queuebot:#ubuntu-release- New: accepted python-cartopy [amd64] (cosmic-proposed) [0.16.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-json-iterator-go [amd64] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted uhd [i386] (cosmic-proposed) [3.12.0.0-2]
-queuebot:#ubuntu-release- New: accepted zc.lockfile [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted zypper [arm64] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New: accepted zypper [i386] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New: accepted zypper [s390x] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New: accepted zypper [amd64] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New: accepted zypper [ppc64el] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New: accepted zypper [armhf] (cosmic-proposed) [1.14.6-1]
-queuebot:#ubuntu-release- New binary: golang-github-modern-go-reflect2 [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [s390x] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [ppc64el] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [amd64] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [i386] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [armhf] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [arm64] (cosmic-proposed/universe) [3.7.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnuradio [amd64] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [armhf] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [ppc64el] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [arm64] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [s390x] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [i386] (cosmic-proposed) [3.7.13.2-2]
-queuebot:#ubuntu-release- New: accepted golang-github-modern-go-reflect2 [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.1.0]
<LocutusOfBorg> wgrant, hello what is happening on ppc64el farming? network glitch?
<LocutusOfBorg> e.g. bos02-ppc64el-009
<wgrant> LocutusOfBorg: Instances fail occasionally and we have to reset them.
<wgrant> But we usually don't bother if it's only a couple, like this.
<wgrant> (and if the build farm is idle)
<LocutusOfBorg> I don't know, I retried all taffybar and xmonad-extras  4/5 time already, everywhere
<LocutusOfBorg> seems to affect arm64 s390x armhf ppc64el
<wgrant> LocutusOfBorg: Oh, build failures? Do you have a link?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/xmonad-extras/0.13.3-1/+build/14992916
<LocutusOfBorg> this one
<LocutusOfBorg> as said, just look at taffybar and xmonad-extras on cosmic
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/xmonad-extras/0.13.3-1
<LocutusOfBorg> they seems to be eating builds
<apw> wgrant, build failures without logs, fun
<LocutusOfBorg> since at least one hour
<wgrant> LocutusOfBorg: Yeah, looking
<wgrant> Thanks
<LocutusOfBorg> you are welcome, thanks for looking!
<wgrant> But please do be more specific when reporting issues in future -- there was nothing obvious without a build link.
<LocutusOfBorg> yep, true
<wgrant> Testing a fix
<wgrant> LocutusOfBorg: Right, fixed. One bit wrong in a subnet mask :(
<LocutusOfBorg> lol thanks!
<bdmurray> sil2100: When you override a regression the phased-updater will resume the phasing at whatever percentage it was last at on its next run. So if it stopped at 20% it will bump it to 30% the run after the override.
-queuebot:#ubuntu-release- Unapproved: fwts (bionic-proposed/universe) [18.03.00-0ubuntu1 => 18.03.00-0ubuntu2] (no packageset)
<sil2100> bdmurray: ok, thanks!
<sil2100> bdmurray: is phasing 0 treated specially in that case? I didn't check the code, I think Andy checked but better double-checking with you
<sil2100> bdmurray: could we maybe get those parts documented somewhere?
<bdmurray> sil2100: I'm not sure I understand the question but anything that is stopped has a phased-update-percentage of 0.
<bdmurray> sil2100: What do you think about releasing the fix for bug 1766137 early?
<ubot5> bug 1766137 in gdm3 (Ubuntu Bionic) "[regression] Password accepted but login fails (blank purple screen and mouse pointer only)" [High,Fix committed] https://launchpad.net/bugs/1766137
<sil2100> bdmurray: what I meant is what will be happening if someone manually sets a package phasing to 0 - does the phaser know then not to increment percentages for such packages?
<sil2100> bdmurray: as for gdm3 - I think we could make an exception for it indeed, but I'd like us to first explain all the whining people on the bug that there are reasons why we let updates age in -proposed
<bdmurray> sil2100: I understand the question now and will have a look.
<sil2100> bdmurray: you want to take care of gdm3?
<bdmurray> sil2100: Yeah, I'll handle it.
<sil2100> bdmurray: thanks o/
-queuebot:#ubuntu-release- New binary: x265 [s390x] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [ppc64el] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [arm64] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [i386] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [armhf] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [amd64] (cosmic-proposed/universe) [2.8-3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lsvpd (bionic-proposed/main) [1.7.8-2ubuntu1 => 1.7.8-2ubuntu1.1] (core)
-queuebot:#ubuntu-release- New: accepted x265 [amd64] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- New: accepted x265 [armhf] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- New: accepted x265 [ppc64el] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- New: accepted x265 [arm64] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- New: accepted x265 [s390x] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- New: accepted x265 [i386] (cosmic-proposed) [2.8-3]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-46.51] (core, kernel)
-queuebot:#ubuntu-release- New binary: cctools [s390x] (cosmic-proposed/universe) [6.2.9-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cctools [amd64] (cosmic-proposed/universe) [6.2.9-4] (no packageset)
#ubuntu-release 2018-06-13
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-default-settings (bionic-proposed/universe) [1.4.4 => 1.4.4.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1 => 1.1ubuntu1.18.04.1] (desktop-core, ubuntu-server)
<tsimonq2> slangasek, apw: Can I please get some ANAIS cleanup for gammaray? qtwebengine isn't available on ppc64el or s390x.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-46.51]
-queuebot:#ubuntu-release- New: accepted cctools [amd64] (cosmic-proposed) [6.2.9-2]
-queuebot:#ubuntu-release- New: accepted cctools [amd64] (cosmic-proposed) [6.2.9-3]
-queuebot:#ubuntu-release- New: accepted cctools [amd64] (cosmic-proposed) [6.2.9-4]
-queuebot:#ubuntu-release- New: accepted cctools [s390x] (cosmic-proposed) [6.2.9-2]
-queuebot:#ubuntu-release- New: accepted cctools [s390x] (cosmic-proposed) [6.2.9-4]
-queuebot:#ubuntu-release- New: accepted cctools [s390x] (cosmic-proposed) [6.2.9-3]
-queuebot:#ubuntu-release- New: accepted tarantool [amd64] (cosmic-proposed) [1.9.1.26.g63eb81e3c-1]
-queuebot:#ubuntu-release- New: accepted tarantool [armhf] (cosmic-proposed) [1.9.1.26.g63eb81e3c-1]
-queuebot:#ubuntu-release- New: accepted tarantool [arm64] (cosmic-proposed) [1.9.1.26.g63eb81e3c-1]
-queuebot:#ubuntu-release- New: accepted tarantool [i386] (cosmic-proposed) [1.9.1.26.g63eb81e3c-1]
-queuebot:#ubuntu-release- New: accepted manila [amd64] (cosmic-proposed) [1:6.0.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted murano [amd64] (cosmic-proposed) [1:5.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mistral [amd64] (cosmic-proposed) [6.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted ndctl [amd64] (cosmic-proposed) [60.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gemma [amd64] (cosmic-proposed) [0.97+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gudhi [amd64] (cosmic-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gudhi [ppc64el] (cosmic-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gemma [i386] (cosmic-proposed) [0.97+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gudhi [s390x] (cosmic-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gudhi [arm64] (cosmic-proposed) [2.1.0+dfsg-2]
-queuebot:#ubuntu-release- New source: python-3parclient (cosmic-proposed/primary) [4.2.7-0ubuntu1]
<jamespage> ^^ that's a package rename that should have happened 2 years ago...
<jamespage> python-hp3parclient is the old name
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-129.155] (core, kernel)
<LocutusOfBorg> jamespage, why diverging from debian?
<jamespage> LocutusOfBorg: debian needs to catchup as well - I'll talk with zigo
<LocutusOfBorg> https://pypi.debian.net/3parclient returns nothing
<LocutusOfBorg> this one works https://pypi.debian.net/hp3parclient
<jamespage> try https://pypi.debian.net/python-3parclient
<LocutusOfBorg> yeah got it
<LocutusOfBorg> nice way to rename a package!
<LocutusOfBorg> :/
<LocutusOfBorg> (I mean, why upstream is prepending "python-" to the name... meh)
<LocutusOfBorg> can't you just commit to pkg-openstack the change for Debian too?
<LocutusOfBorg> onovy is probably the best person to talk with
<jamespage> I wish I felt I could (there is quite a bit of history here)
<jamespage> but yes maybe onovy is a better person to talk to
<jamespage> I already pinged him about something else so I'll raise this as well
<LocutusOfBorg> I requested access to pkg-openstack salsa team, why can't you join?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-129.155]
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.2 => 4.0.0-1ubuntu8.3] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.3 => 1:2.11+dfsg-1ubuntu7.4] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libclc (xenial-proposed/universe) [0.2.0+git20170330-3~16.04.1 => 0.2.0+git20180312-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.3]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [s390x] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [amd64] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [armhf] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [powerpc] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [s390x] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [arm64] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [ppc64el] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [i386] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.2-0ubuntu1.2 => 3.28.2-0ubuntu1.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected lastpass-cli [source] (bionic-proposed) [1.0.0-1.2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: lastpass-cli (bionic-proposed/universe) [1.0.0-1.2ubuntu1 => 1.0.0-1.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nux (artful-proposed/universe) [4.0.8+17.10.20170922-0ubuntu1 => 4.0.8+17.10.20180613.3-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: nux (xenial-proposed/main) [4.0.8+16.04.20170816-0ubuntu1 => 4.0.8+16.04.20180613.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nux (bionic-proposed/universe) [4.0.8+17.10.20170922-0ubuntu1 => 4.0.8+18.04.20180613.5-0ubuntu1] (no packageset) (sync)
<Laney> heh, those packagesets show an interesting change in the importance of nux
<didrocks> I'm still set as the maintainer for it, we should SRU that :p
<didrocks> (getting spam ;))
<LocutusOfBorg> xnox, if you don't want debootstrap merged please speak *now* :)
<Trevinho> rbasak: hey have you some time for approve the SRU for branches mentioned in https://bileto.ubuntu.com/#/active?search=1768610
<Trevinho> As for bug https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1768610 making it SRU compliant now
<ubot5`> Ubuntu bug 1768610 in nux (Ubuntu Bionic) "leftover conffile forces GNOME is software rendering" [Undecided,In progress]
<xnox> LocutusOfBorg, why would you ask me, if i'm not the one who has touched-it-last.
<xnox> LocutusOfBorg, and it is inapproriate for you to touch or change that package, without coordination
<xnox> LocutusOfBorg, serious, debootstrap is by far not the only piece that we will need to change, and it is not your call to change it
<xnox> nor mine
<xnox> either
<LocutusOfBorg> nvm, it would be autosyncd
<LocutusOfBorg> xnox, it has no delta now
<xnox> correct, and with usr-merge off for ubuntu's scripts
<LocutusOfBorg> nope
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (bionic-proposed) [2.4.29-1ubuntu4.2]
<LocutusOfBorg> https://salsa.debian.org/installer-team/debootstrap/commit/b77d34572cd2c0c42e33e78803d661423c0bd60c
<xnox> that is not an invintation for you to upload a change to that.
<LocutusOfBorg> oh yeah, cosmic is out
<LocutusOfBorg> ok, sooooo a problem for cosmic+1
<LocutusOfBorg> :)
<LocutusOfBorg> nice, no action is good then
<LocutusOfBorg> (I was wondering cosmic being with merged usr)
<xnox> specifically, no actions from you are requested wrt. to changing this
<LocutusOfBorg> I'm really not the one who introduces deltas in Ubuntu :)
<rbasak> Trevinho: any reason for urgency? The queues are rather long at the moment and I try to process them FIFO otherwise.
<LocutusOfBorg> xnox, I didn't discover your comment on the merge, nice seems we have the same idea :)
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (artful-proposed) [2.4.27-2ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: accepted lastpass-cli [source] (bionic-proposed) [1.0.0-1.2ubuntu2]
<Trevinho> rbasak: we need that for .1 for sure, it's breaking the desktop usage for anyone upgrading
<Trevinho> .1 is far, but soon is better than later
<Trevinho> also because people could upgrade in any moment
<Trevinho> by breaking = always running in 2d mode, thus with slowness and high cpu usage
-queuebot:#ubuntu-release- Unapproved: rejected appstream-glib [source] (xenial-proposed) [0.5.13-1ubuntu6]
<slangasek> tsimonq2: did the gammary cleanup get done?  I see it only in cosmic now
<slangasek> tsimonq2: (not in -proposed)
<tsimonq2> slangasek: Looks like it just migrated.
<tsimonq2> Thanks anyway.
<slangasek> k
-queuebot:#ubuntu-release- Unapproved: rejected iperf [source] (xenial-proposed) [2.0.5+dfsg1-2ubuntu0.1]
 * rbasak is looking at nux now
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (artful-proposed) [4.0.8+17.10.20180613.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (bionic-proposed) [4.0.8+18.04.20180613.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (xenial-proposed) [4.0.8+16.04.20180613.1-0ubuntu1]
<rbalint> rbasak, could you please approve gce-compute-image-packages for trusty?
<rbalint> rbasak, tracking bug: LP: #1770650
<ubot5`> Launchpad bug 1770650 in gce-compute-image-packages (Ubuntu Trusty) "Update google compute-image-packages to 20180510" [Undecided,Fix committed] https://launchpad.net/bugs/1770650
<rbasak> rbalint: I don't see it in the queue
<rbasak> Oh. You mean release?
<rbalint> rbasak, yes, s/approve/release/
<rbasak> Ah
<rbasak> rbalint: it's not reached the minimum aging period
<rbalint> rbasak, yes, it has the exception, it is detailed in the bug
 * rbasak reads
<Trevinho> rbasak: thanks
<rbasak> rbalint: I don't see anything about an exception to the minimum aging period
<rbalint> rbasak, well, https://wiki.ubuntu.com/gce-compute-image-packages-Updates does not explicitly mention aging but overrides the SRU process, so there is ambiguity indeed
<rbalint> rbasak, in practice we did not require aging i think, sil2100, what is your take on this?
<rbalint> rbasak, sil2100 i'm updating the wiki to be clear about this
<rbasak> I don't think it's at all ambiguous. If the aging period is to be skipped, I'd expect that to be documented separately. We normally follow aging for all other existing SRU exceptions, AFAIK.
<rbasak> rbalint: what's the justification for skipping it? Any changes will need reapproval from the SRU team BTW. Please don't just change the wiki.
<rbasak> (tzdata etc. don't have aging but they are documented exceptional exceptions)
<rbalint> rbasak, sil2100: i'm asking for clarification here if we are supposed to speed up aging just forgot adding it to the wiki
<rbalint> rbasak, sil2100: imo in this package's case that would be warranted since no one tests the packages from -proposed apart CPC and GCE and they are part of the verification
<rbasak> Our SRU verification model allows for any interested user to do testing and provide feedback in advance of an SRU release. Even as a one-off.
<rbasak> I'm not sure we want to lose that without justification.
<rbasak> rbalint: what's the downside to keeping the aging period?
<rbasak> (an example: user has obscure use case, but runs CI. User detects problem with -proposed package and reports verification failure)
-queuebot:#ubuntu-release- Unapproved: iperf (xenial-proposed/universe) [2.0.5+dfsg1-2 => 2.0.5+dfsg1-2ubuntu0.1] (edubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-129.155~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-129.155~14.04.1]
<rbalint> rbasak, this package is used only in Google's cloud, only Google performs verification outside of Canonical and Google tells us when the package is ready to be released
<rbalint> rbasak, waiting one week adds no extra QA but slows down the release to Google's infrastructure
<tsimonq2> slangasek: Out of curiosity, when a package is removed from Debian, is there some sort of process for following through in Cosmic or is it (semi-)automatic?
<tsimonq2> slangasek: I'm specifically looking at src:jovie, Debian bug 900922 has removal details, and removal would fix bug 1757665.
<ubot5`> Debian bug 900922 in ftp.debian.org "RM: jovie -- ROM; obsolete, not used anymore" [Normal,Open] http://bugs.debian.org/900922
<ubot5`> bug 1757665 in jovie (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757665
<slangasek> tsimonq2: semiautomatic.  We have a 'process-removals' script that AAs run from time to time.
<tsimonq2> slangasek: Ah, OK.
<slangasek> coreycb: ^^ on the question of removals, it seems Debian has removed vmware-nsx as "not needed" (Debian bug #897331) but you have been updating it in Ubuntu.  Should we remove or keep?
<ubot5`> Debian bug 897331 in ftp.debian.org "RM: vmware-nsx -- ROM; Not needed, FTBFS, closed source solution" [Normal,Open] http://bugs.debian.org/897331
<coreycb> slangasek: let's keep it for now. it's still actively being developed but sounds like zigo doesn't want to support it. jamespage, thoughts on that?
<slangasek> tsimonq2: kttsd is seeded as 'supported' in kubuntu; do you want to take care of cleaning up the seed?
<slangasek> tsimonq2: (kttsd from jovie source)
<tsimonq2> slangasek: ENOACCESS to I defer to acheronuk unless you want to JFDI.
<tsimonq2> s/to/so/
-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- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.1 => 0.130ubuntu3.2] (core)
 * rbalint EODs
<acheronuk> tsimonq2 slangasek: will look in the morning on kttsd
 * acheronuk goes zzzzzzzz
-queuebot:#ubuntu-release- New binary: python-orderedmultidict [amd64] (cosmic-proposed/none) [1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [ppc64el] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [amd64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bx [ppc64el] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bx [amd64] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [i386] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [arm64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [armhf] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopencsd [s390x] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bx [i386] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bx [s390x] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libopencsd [amd64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted libopencsd [armhf] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted libopencsd [ppc64el] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted python-3parclient [source] (cosmic-proposed) [4.2.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopencsd [arm64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted libopencsd [s390x] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted libopencsd [i386] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted python-bx [amd64] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted python-bx [ppc64el] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted python-orderedmultidict [amd64] (cosmic-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted python-bx [i386] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted python-bx [s390x] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New binary: python-3parclient [amd64] (cosmic-proposed/universe) [4.2.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bx [arm64] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-3parclient [amd64] (cosmic-proposed) [4.2.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-bx [arm64] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New binary: libcdio [amd64] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [s390x] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [ppc64el] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [arm64] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [armhf] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [i386] (cosmic-proposed/main) [2.0.0-1] (kubuntu, ubuntu-desktop)
#ubuntu-release 2018-06-14
-queuebot:#ubuntu-release- New: accepted libcdio [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [ppc64el] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [arm64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [s390x] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (artful-proposed) [4.33-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (xenial-proposed) [4.33-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.33-0ubuntu1~14.04.1]
<xnox> infinity, recall during sprint i said debootstrap/rsyslog is busted.
<xnox> infinity, well, i believe it really is... in -proposed, hence debootstrap was failing to migrate as the default-bootstraps as called by livecd-rootfs autopkgtests is busted there.
<xnox> infinity, would you be able to dig into that? or should I be spending time to investigate that?
<xnox> looks like a regression since 1.0.95
<cpaelzer> sil2100: I get the feeling that https://bileto.ubuntu.com/#/ticket/3293 is not running tests
<cpaelzer> sil2100: anything we can do to investigate?
<sil2100> cpaelzer: let me take a look
<sil2100> ARGH
<sil2100> Yeah, the usual unauthorized thing, let me take care of it
<sil2100> cpaelzer: I poked webops to restart it, as that's the easiest way to get it fixed
<sil2100> Need to investigate why it started turning into such a big problem recently, I don't remember it happening before
<sil2100> cpaelzer: ok, let's see if the next run will be better
<cpaelzer> sil2100: do I need to toggle the lander signoff
<cpaelzer> off/on to retrigger?
<sil2100> cpaelzer: no, it shouldn't be necessary
<cpaelzer> sil2100: ok giving it an hour to recheck then
<cpaelzer> queues on http://autopkgtest.ubuntu.com/running are empty
<cpaelzer> would I see it there sil2100?
<cpaelzer> under the ppa category
<sil2100> Yes, but only after britney is done triggering the tests
<cpaelzer> ok
<sil2100> And the queues in the webview aren't updated automatically, there's always a delay
<cpaelzer> good to know
<sil2100> cpaelzer: done, tests actually already ran and passed
<sil2100> cpaelzer: since the issue that bileto had was actually uploading the results to swift to display them
<cpaelzer> oh I see
<cpaelzer> so the perm issue is on the swift upload
<cpaelzer> thank you sil2100!
<sil2100> cpaelzer: yw! If I have some free time I'll try to think of a way of making sure the tokens don't get desync so often
<sil2100> We don't do any work on Bileto now so it might get delayed
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (bionic-proposed) [3.0.1-0ubuntu1~18.04.1]
<cpaelzer> sil2100: low investement high gain, just bluntly restart it all 6 hours or sometihng like that
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-24.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-24.26] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-24.26]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-24.26]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (bionic-proposed) [3.0.1-0ubuntu1~18.04.1]
<tjaalton> how to trigger tests on the latest version of the package, instead of the version that had failed?
<tjaalton> like this http://autopkgtest.ubuntu.com/packages/v/vtk7/cosmic/amd64
<tjaalton> re-running tests for libglvnd runs it on the old vtk7
<xnox> tjaalton, and one more package to triggered by with a newer version number, from e.g. proposed.
<xnox> tjaalton, hack the retry url
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (bionic-proposed) [3.0.1-0ubuntu1~18.04.1]
<xnox> note there are two vtk7 at the moment, one in proposed, another one in release pocket.
<xnox> what you are saying is that libglvnd is broken against vtk7 in release pocket, but work against new one?
<xnox> maybe libglvnd needs Depends: libvtk7 (>= new version) ? no?
<xnox> tjaalton, cause you don't want libglvnd to migrate without libvtk7 into release pocket, and then regress in the release pocket, no?
-queuebot:#ubuntu-release- Unapproved: rejected python-pylxd [source] (bionic-proposed) [2.2.6-0ubuntu1.1]
<tjaalton> xnox: no, it's just vtk7 which is buggy
<xnox> ah
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (bionic-proposed) [2.2.6-0ubuntu1.1]
<xnox> tjaalton, hack the url to include &package=vtk7/correctversion for the retry url of the libglvnd
<tjaalton> looks like it needs some hand-holding to get through, depends on other packages
<tjaalton> right, how to add '+' there?
<xnox> urlencode
-queuebot:#ubuntu-release- Unapproved: rejected swauth [source] (bionic-proposed) [1.3.0-1ubuntu1]
<tjaalton> https://autopkgtest.ubuntu.com/request.cgi/?release=cosmic&arch=amd64&package=vtk7%2F7.1.1%2Bdfsg1-4build2&trigger=libglvnd%2F1.0.0%2Bgit20180308-3ubuntu1
<tjaalton> doesn't seem to work
<tjaalton> or I'm missing something
<xnox> hu
<xnox> tjaalton, package=thing to test & trigger=who & trigger=other
<xnox> tjaalton, i think you want to run the test of libglvnd? no? then you should have package=libglvnd/version&trigger=libglvnd/version&trigger=vtk7/version
<tjaalton> no
<tjaalton> libglvnd doesn't have any tests
<xnox> such that you run libglvnd, but triggered by two things - new libglvnd and new vtk7
<xnox> oh
<xnox> package vtk7/newversion & trigger=vtrk7/newversion & trigger=libglvnd/newversion ?
<xnox> run vtk7 tests, whilst new vtk7 is installed and a new libglvnd installed
<tjaalton> ok
<tjaalton> nope, still the same
<xnox> so what you pasted is good, but needs a second trigger for the right vtk7 as well as the package= stanza, so repeat that bit
<xnox> package is without version number
-queuebot:#ubuntu-release- Unapproved: accepted swauth [source] (bionic-proposed) [1.3.0-1ubuntu1]
<tjaalton> it works without, not with
<tjaalton> oh well, see how it goes
<xnox> looks ok
<xnox> http://autopkgtest.ubuntu.com/running#pkg-vtk7
<xnox> Release:	cosmic
<xnox> Architecture:	amd64
<xnox> Triggers:	['vtk7/7.1.1+dfsg1-4build2', 'libglvnd/1.0.0+git20180308-3ubuntu1']
<xnox> Requester:	tjaalton
<xnox> Running for:	0h 0m 30s
<tjaalton> alright, hope it passes this time
<tjaalton> thanks
-queuebot:#ubuntu-release- New binary: swauth [amd64] (bionic-proposed/universe) [1.3.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fonts-guru-extra [source] (bionic-proposed) [2.0-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted swauth [source] (artful-proposed) [1.2.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-pylxd [source] (artful-proposed) [2.2.6-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- New binary: swauth [amd64] (artful-proposed/universe) [1.2.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: libocxl (bionic-proposed/primary) [1.0.0-1~ubuntu18.04.0]
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-16.04 (xenial-proposed/main) [1:7.10.0-1~16.04.1 => 1:18.0.1-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-16.04 (xenial-proposed/main) [1.4.0-1~16.04.1 => 18.0.1-1~16.04.1] (no packageset)
<tjaalton> sil2100: ^ some uploads for 16.04.5, and there's also libclc on the queue
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel-hwe-16.04 (xenial-proposed/main) [2:2.99.917+git20170309-0ubuntu1~16.04.1 => 2:2.99.917+git20171229-1~16.04.1] (no packageset)
<sil2100> tjaalton: thanks! On it
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (xenial-proposed) [0.2.0+git20180312-1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-16.04 [source] (xenial-proposed) [1:18.0.1-1~16.04.1]
<sil2100> tjaalton: love those version leaps 1.4.0 -> 18.0.1
<tjaalton> sil2100: they went for year.N
<tjaalton> like mesa
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-16.04 [source] (xenial-proposed) [18.0.1-1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: openipmi (bionic-proposed/main) [2.0.22-1.1ubuntu2 => 2.0.22-1.1ubuntu2.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openipmi (artful-proposed/main) [2.0.22-1.1ubuntu1 => 2.0.22-1.1ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openipmi (xenial-proposed/main) [2.0.18-0ubuntu11.1 => 2.0.18-0ubuntu11.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [169-1~ubuntu16.04.1 => 170-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [170-1~ubuntu16.04.1]
<ahasenack> hi all, I added dep8 tests to autofs package in my 5.1.2-3ubuntu2 upload
<ahasenack> there were none before
<ahasenack> they are all marked as "always failed" in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, is that just a safe default for when tests are added?
<ginggs> ahasenack: yes
<ahasenack> can that please be changed to not ignore failures?
<ahasenack> http://autopkgtest.ubuntu.com/packages/autofs
<ginggs> ahasenack: after the tests have passed the first time, they have to keep passing
<ahasenack> ginggs: ah, good, thanks
<sil2100> tjaalton: I see the xserver-xorg-video-intel-hwe-16.04 package has dropped dri3info after the sync to Debian - won't that cause any problems, since it was an existing Ubuntu delta?
<sil2100> s/sync to/sync from/
<tjaalton> sil2100: I doubt it, it just says if dri3 is enabled
<tjaalton> which should be, by default
<sil2100> tjaalton: if that's the case then I guess I'll approve, but please have your eyes open for people whining for it being gone
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel-hwe-16.04 [source] (xenial-proposed) [2:2.99.917+git20171229-1~16.04.1]
<tjaalton> sure
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.19.5-0ubuntu2~16.04.1 => 2:1.19.6-1ubuntu4~16.04.1] (no packageset)
<tjaalton> sil2100: the server, tested on nvidia by tseliot so that it doesn't regress, had to revert some things from it but it's fine
<tjaalton> sil2100: ^
<tjaalton> it's only mesa missing now
<bdmurray> sil2100: How go the SRU reviews?
-queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [17.2.8-0ubuntu0~16.04.1 => 18.0.5-0ubuntu0~16.04.1] (core, xorg)
<tjaalton> sil2100: aand there's mesa
<sil2100> bdmurray: I'm done for today, I'll just take care of the HWE things in xenial, e.g. mesa and xorg-server
<sil2100> bdmurray: but all the others are yours o/
<sil2100> tjaalton: thanks! On it, just need to grab a quick bite
<bdmurray> sil2100: ack
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.6-1ubuntu4~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (xenial-proposed) [18.0.5-0ubuntu0~16.04.1]
<tjaalton> sil2100: \o/
-queuebot:#ubuntu-release- New source: python-qinlingclient (cosmic-proposed/primary) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-vitrageclient [amd64] (cosmic-proposed/universe) [2.1.0-0ubuntu1] (no packageset)
<bdmurray> sil2100: Could you review my upload of lsvpd for bionic?
<sil2100> bdmurray: sure
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (bionic-proposed) [1.7.8-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (bionic-proposed) [3.28.0-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.2]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (bionic-proposed) [0.34-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.6]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu23]
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (bionic-proposed) [4.2.4-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (bionic-proposed) [1:10.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (artful-proposed) [1:9.0.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (xenial-proposed) [1:6.1.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (artful-proposed) [10.7.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (bionic-proposed) [11.1.6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (xenial-proposed) [9.20160115ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (bionic-proposed) [2.0.10+dfsg1-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (artful-proposed) [2.0.10+dfsg1-1ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted iperf [source] (xenial-proposed) [2.0.5+dfsg1-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.9.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (bionic-proposed) [18.03.00-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (bionic-proposed) [2.0.10.4-3.5ubuntu2.18.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (artful-proposed) [2.0.10.4-3.5ubuntu2.17.10.2]
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.14.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (xenial-proposed) [2.0.10.4-3.4ubuntu2.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-default-settings [source] (bionic-proposed) [1.4.4.1]
<rbasak> bdmurray: +1 on the queue rejects.
<rbasak> I was leaving them there but really that just means every pass takes longer. And I'd seen them multiple times already.
<bdmurray> rbasak: Yeah and it wasn't a good use of my time.
-queuebot:#ubuntu-release- Unapproved: accepted skytools3 [source] (artful-proposed) [3.2.6-5ubuntu0.1]
<rbasak> I was getting more reject happy nearer the end of my shift yesterday, but had already gone past those ones. Too much stuff languishing/blocked in the queues at the moment :-/
-queuebot:#ubuntu-release- Unapproved: accepted skytools3 [source] (xenial-proposed) [3.2.6-4ubuntu0.1]
#ubuntu-release 2018-06-15
<bdmurray> Not to mention all that stuff needing verifying.
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.1 => 0.130ubuntu3.2] (core)
<acheronuk> ./retry-autopkgtest-regressions
<acheronuk> Traceback (most recent call last):
<acheronuk>   File "./retry-autopkgtest-regressions", line 183, in <module>
<acheronuk>     args.no_proposed)
<acheronuk>   File "./retry-autopkgtest-regressions", line 148, in get_regressions
<acheronuk>     trigger = excuse['source'] + '/' + excuse['new-version']
<acheronuk> KeyError: 'source'
<acheronuk> :(
<LocutusOfBorg> acheronuk, WFM
<acheronuk> LocutusOfBorg: weird. worked last night
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-153.203] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-153.203]
<LocutusOfBorg> acheronuk, maybe it works now?
<acheronuk> LocutusOfBorg: it does. It also did when I switched to a VPS or another local user, when it's would not work under my main account. but seems ok on all now
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-130.156] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-130.156]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-130.156~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-130.156~14.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1014.14~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1014.14~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1014.14] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1014.14]
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-6 => 5.2.10-dfsg-6ubuntu18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: boinc (bionic-proposed/universe) [7.9.3+dfsg-5ubuntu1 => 7.9.3+dfsg-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nbd (bionic-proposed/main) [1:3.16.2-1 => 1:3.16.2-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: changeme [amd64] (cosmic-proposed/none) [1.1.1-1] (no packageset)
#ubuntu-release 2018-06-16
-queuebot:#ubuntu-release- Unapproved: python-acme (bionic-proposed/universe) [0.22.2-1 => 0.22.2-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted changeme [amd64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-vitrageclient [amd64] (cosmic-proposed) [2.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-beng-extra [source] (bionic-proposed) [1.0-6ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-deva-extra [source] (bionic-proposed) [3.0-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-gujr-extra [source] (bionic-proposed) [1.0-6ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-orya-extra [source] (bionic-proposed) [2.0-5ubuntu0.1]
<acheronuk> apw or any other AA. can krita 1:4.0.4+dfsg-1ubuntu1 be removed from -proposed and be replaced by a direct sync? I misread the changelog slightly, and we can drop the delta
<acheronuk> if too late for that, no probs
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (bionic-proposed) [0.22.2-1ubuntu0.1]
<rbasak> acheronuk: I'm not an AA, but I'm pretty sure you can't do that since the version number would have to go backwards (1:4.0.4+dfsg-1ubuntu1 is "published" even though it's in cosmic-proposed). You could drop the delta in a 1:4.0.4+dfsg-1ubuntu2 upload perhaps, ready to sync in a future 1:4.0.4+dfsg-2 (or higher) in Debian.
<rbasak> Or just leave it if it won't matter to users.
<tsimonq2> I would even go 1:4.0.4+dfsg-1+build1 fakesyncing then let the autosyncer take care of it from there.
<tsimonq2> Unless... hmm... is build1 higher or lower than ubuntu1?
<tsimonq2> ubuntu1 is probably higher
<acheronuk> rbasak: thanks. it is going no-where, so can wait for a bit
<acheronuk> tsimonq2: ubuntu1 is higher
<tsimonq2> Right, that would make sense.
<slangasek> acheronuk, rbasak: LP does allow for rolling back version numbers in -proposed, as long as they are version numbers that haven't previously been used in the archive; but this isn't something I want us to be doing, especially for packages currently tied up in transitions in -proposed - it can just be made a sync next time around.
<acheronuk> slangasek: great. not a problem :)
-queuebot:#ubuntu-release- Unapproved: lxcfs (bionic-proposed/main) [3.0.1-0ubuntu1~18.04.1 => 3.0.1-0ubuntu2~18.04.1] (edubuntu, ubuntu-server)
<stgraber> ^ that should unstick the lxcfs SRU (bionic) and should be pretty easy to review
#ubuntu-release 2018-06-17
<LocutusOfBorg> hello cyphermox, ping wrt LP: #1770146 (I'm thinking I might have missed something!)
<ubot5> Launchpad bug 1770146 in libayatana-appindicator (Ubuntu) "[MIR] libayatana-appindicator" [Low,New] https://launchpad.net/bugs/1770146
#ubuntu-release 2019-06-10
-queuebot:#ubuntu-release- New: accepted node-d3-contour [amd64] (eoan-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted node-dagre-layout [amd64] (eoan-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted node-request-promise-core [amd64] (eoan-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-d3-fetch [amd64] (eoan-proposed) [1.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-define-properties [amd64] (eoan-proposed) [1.1.2-1]
<acheronuk> xnox: might need slightly more thought it seems
<acheronuk> ftbs
<acheronuk> bdmurray: hi, apport seems to have regressed on its i386 test since last upload LP: #1832120
<ubot5> Launchpad bug 1832120 in apport (Ubuntu) "i386 - Test fails 'test_get_file_package_uninstalled_multiarch'" [Undecided,New] https://launchpad.net/bugs/1832120
-queuebot:#ubuntu-release- New binary: papi [amd64] (eoan-proposed/universe) [5.7.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [ppc64el] (eoan-proposed/universe) [5.7.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [i386] (eoan-proposed/universe) [5.7.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [arm64] (eoan-proposed/universe) [5.7.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [armhf] (eoan-proposed/universe) [5.7.0+dfsg-1] (no packageset)
<koza> Hey everybody. I am using bionic and I have added arm64 architecture via sudo dpkg --add-architecture arm64 however now the apt update renders lots of 404 errors (like: 404  Not Found [IP: 153.19.251.225 80]) Is it normal? What is the way to add another architecture?
<cjwatson> arm64 lives on ports.ubuntu.com rather than archive.ubuntu.com, which requires some sources.list finagling
<cjwatson> Something like adding [arch=amd64] just after the "deb " on each archive.ubuntu.com line in sources.list, and then adding "deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic main restricted universe multiverse" (and similarly for bionic-updates)
<cjwatson> Likewise for security.ubuntu.com
<cjwatson> You can read "man sources.list" for more details
<cjwatson> Oh, also, this is not a release management question, please use #ubuntu for this kind of thing next time
<koza> cjwatson: thanks
<LocutusOfBorg> hello, can we please have diaspora-installer/0.7.6.1+debian1/armhf hinted? it is regressed in release (it is just a downloader), and I have reported it upstream https://github.com/codahale/bcrypt-ruby/issues/201
<LocutusOfBorg> but not something we can easily fix in Ubuntu side, since gems are handled on rubygems.org website, not internally
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1041.46] (kernel)
-queuebot:#ubuntu-release- Unapproved: python-glance-store (cosmic-proposed/main) [0.26.1-0ubuntu2.1 => 0.26.1-0ubuntu2.2] (openstack, ubuntu-server)
<acheronuk> vorlon: could I perhaps get a skiptest for konsole in proposed please? the i386 apport test fail is not the fault of konsole. LP: #1832120
<ubot5> Launchpad bug 1832120 in apport (Ubuntu) "i386 - Test fails 'test_get_file_package_uninstalled_multiarch'" [Undecided,New] https://launchpad.net/bugs/1832120
<vorlon> acheronuk: badtested apport instead
<acheronuk> vorlon: thanks! that is fair enough
<teward> vorlon: i'm seeing a lot of openssl-related things, including a note that openssl has been released, yet it still only shows in proposed for me, i take it that's normal in this case?
<teward> even though that SRU is marked as "Fix Released"
<vorlon> teward: the emails arrive before the archive publishing is visible on the mirror
<teward> ah, okay.  so EVENTUALLY it'll be fully published.
<teward> as soon as things sync up.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.26 => 2.525.27] (desktop-core)
<ddstreet> is the xenial sru queue still getting reviewed?
-queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (bionic-proposed) [4.5.3-1ubuntu0.1]
<vorlon> ddstreet: yes, though speaking only for myself I tend to look at queues in reverse chronological order, and I never made it to xenial on Friday because d/c/b kept me busy
<Eickmeyer> Looks like both budgie and studio failed to build today, but can't see that it's for the same reasons. In Studio's case it appears to be a conflict with the nvidia drivers? I was in the process of adding them to the seed, but hadn't finished processing the meta yet.
<Eickmeyer> https://launchpadlibrarian.net/427666228/buildlog_ubuntu_eoan_amd64_ubuntustudio_BUILDING.txt.gz
<rbasak> ddstreet, vorlon: FWIW, usually I review the queues in forward chronological order of release, but I tend to skip big and/or complicated SRUs on my first pass, and rarely get to a second.
 * cjwatson removes gcc-defaults-ports/cosmic-proposed because it's causing the publisher to OOPS; commented on bug 1828171 with an explanation
<ubot5> bug 1828171 in binutils (Ubuntu) "New toolchain updates need to be rebuilt against -security only" [High,New] https://launchpad.net/bugs/1828171
#ubuntu-release 2019-06-11
<acheronuk> xnox: daily isos fail with 'cpio: premature end of archive' again after the 'fix' in initramfs-tools 0.133ubuntu8
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (cosmic-proposed/universe) [1.178ubuntu1.1 => 1.178ubuntu1.18.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (cosmic-proposed) [1.178ubuntu1.18.10.1]
<sil2100> cjwatson: hey! Thanks for pointing out and dealing with the gcc-defaults-ports binary issues, I just pushed a new version that hopefully shouldn't conflict anymore
<cjwatson> thanks
<doko> cjwatson, sil2100: I think your upload won't help
<doko> I'm trying to understand why this only shows up with gcc-defaults-ports, and not with the other cross packages
<cjwatson> That upload does help
<cjwatson> I mean, maybe not permanently, but its binary versioning scheme is such that it won't collide
<doko> how? it
<doko> hmm
<cjwatson> Because it has .18.10.1 on the end
<sil2100> I don't understand the build process, but I did try to make sure the ubuntu part of the version is non-collidable with bionic
<doko> ahh, ok, such a version bump would not help for gcc-N-cross and gcc-N-cross-ports
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1041.46]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.39.2+19.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.39.2+18.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.39.2+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.39.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.39.2]
<LocutusOfBorg> what is preventing src:papi from being accepted? it is not built on s390x, but neither the previous version is...
<cjwatson> nothing?
<ginggs> @LocutusOfBorg new binaries
-queuebot:#ubuntu-release- New: accepted papi [amd64] (eoan-proposed) [5.7.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [armhf] (eoan-proposed) [5.7.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [ppc64el] (eoan-proposed) [5.7.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [arm64] (eoan-proposed) [5.7.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [i386] (eoan-proposed) [5.7.0+dfsg-1]
<ginggs> cjwatson: thanks :)
<LocutusOfBorg> cjwatson, the question is: does the "auto accept tool" check if all archs are built, and becomes manual if some of them are missing, or does check if previous version were missing too?
<cjwatson> auto-accept is not a thing for NEW
<LocutusOfBorg> thanks for accepting :D
<LocutusOfBorg> oh, I remember you talking about some half made auto accept script, but I admit I lost the context probably
<cjwatson> there is new-binary-debian-universe, but that's a helper that archive admins can run by hand
<cjwatson> just saves a bit of time when processing the obvious bulk stuff in NEW
<apw> the other auto accept bot is for unapproved late in the cycle
<cjwatson> and it has no particular architecture checks
<LocutusOfBorg> yeah probably that one, but does it work if some arch is not built yet?
<cjwatson> it works fine, I just ran it
<LocutusOfBorg> how does it work if some of the stuff in new is built on some arch and is not yet built on others?
<cjwatson> it cares not
<cjwatson> proposed-migration will sort that sort of thing out
<LocutusOfBorg> sure thing :D thanks!
<cjwatson> also, it prompts - if there's some kind of complicated layered rebuild in process then an archive admin can choose to wait
<cjwatson> but it's up to the human in the loop
<LocutusOfBorg> ack thanks
-queuebot:#ubuntu-release- Unapproved: kazam (disco-proposed/universe) [1.4.5-2.1 => 1.4.5-2.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: u-boot (disco-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2 => 2018.07~rc3+dfsg1-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: u-boot (cosmic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2~18.10.1 => 2018.07~rc3+dfsg1-0ubuntu3~18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: u-boot (bionic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2~18.04.1 => 2018.07~rc3+dfsg1-0ubuntu3~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: u-boot (xenial-proposed/main) [2016.01+dfsg1-2ubuntu3 => 2016.01+dfsg1-2ubuntu4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (disco-proposed) [2018.07~rc3+dfsg1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (cosmic-proposed) [2018.07~rc3+dfsg1-0ubuntu3~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (bionic-proposed) [2018.07~rc3+dfsg1-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (xenial-proposed) [2016.01+dfsg1-2ubuntu4]
<ahasenack> hi release team, diaspora-installer cannot be installed in the machines used for autopkgtests because its postinst actually downloads diaspora at install time: https://pastebin.ubuntu.com/p/N9MqVKvN4Q/
<ahasenack> hm, but why did it fail only on armhf, and not the other arches...
 * ahasenack puzzled now
<ahasenack> huh
<ahasenack> armhf is on lxd, others are vms?
 * ahasenack switches to #ubuntu-devel
<LocutusOfBorg> ahasenack, hey!
<LocutusOfBorg> I reported it already!
<LocutusOfBorg> [16:32:41] <LocutusOfBorg> hello, can we please have diaspora-installer/0.7.6.1+debian1/armhf hinted? it is regressed in release (it is just a downloader), and I have reported it upstream https://github.com/codahale/bcrypt-ruby/issues/201
<LocutusOfBorg> [16:33:05] <LocutusOfBorg> but not something we can easily fix in Ubuntu side, since gems are handled on rubygems.org website, not internally
<ahasenack> LocutusOfBorg: oh, thx
<ahasenack> LocutusOfBorg: but it worked in the other arches,
<ahasenack> LocutusOfBorg: it looks like our armhf lxd just can't resolve squid.internal
<ahasenack> the other arches can
<ahasenack> https://pastebin.ubuntu.com/p/RVQFSwXS8F/ for a good run, same version
<ahasenack> oh, you reported a build failure
<ahasenack> something different
<ahasenack> LocutusOfBorg: MP for the diaspora-installer armhf hint: https://code.launchpad.net/~ahasenack/britney/diaspora-installer-armhf-hint/+merge/368655
<ahasenack> oh, hm, dns was just a temporary issue
<xnox> acheronuk:  of course they are! because the fix needs to be on the nusakan.
<acheronuk> xnox: makes sense. I'm not really too familiar with what gets pulled in on the fly in each build on that, and what needs to be already there
<xnox> acheronuk:  it is a bit of a mess
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190514.1-0ubuntu0.18.04.1 => 1:20190611.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190514.1-0ubuntu0.19.04.1 => 1:20190611.1-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190514.1-0ubuntu0.18.10.1 => 1:20190611.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190514.1-0ubuntu0.16.04.1 => 1:20190611.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu570 => 20101020ubuntu570.1] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (disco-proposed/main) [0.131ubuntu19 => 0.131ubuntu19.1] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15.2 => 0.131ubuntu15.3] (core)
<xnox> acheronuk:  we upgraded nusakan, so tomorrow's build should be fine.
<xnox> acheronuk:  thank you for paying attention.
<xnox> and thank you sil2100 for fixing everything.
<acheronuk> xnox & sil2100: thank you!
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.7 => 20101020ubuntu543.8] (core)
<blackboxsw> bdmurray: or RAOF  if there is availability today, there is a curtin SRU queued in unapproved for xenial, bionic, cosmic and disco https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1831772
<ubot5> Launchpad bug 1831772 in curtin (Ubuntu Disco) "sru curtin 2019-06-05 - 19.1-7-g37a7a0f4-0ubuntu1" [Undecided,New]
<blackboxsw> if either of you get a chance to peek at it. that'd be excellent
-queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu3 => 2:14.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu557.1 => 20101020ubuntu557.2] (core)
-queuebot:#ubuntu-release- Unapproved: bash (bionic-proposed/main) [4.4.18-2ubuntu1.1 => 4.4.18-2ubuntu1.2~bionic1] (core)
-queuebot:#ubuntu-release- Unapproved: bash (cosmic-proposed/main) [4.4.18-2ubuntu3 => 4.4.18-2ubuntu3.1~cosmic1] (core)
<coreycb> hello, can an archive admin please remove python-oslo.log 3.44.0-0ubuntu2 from eoan-proposed? we have some circulary dependency issues and this is the easiest resolution.
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.22 => 237-3ubuntu10.23] (core)
<vorlon> coreycb: done
<coreycb> vorlon: thanks
<xnox> vorlon:  https://code.launchpad.net/~ahasenack/britney/diaspora-installer-armhf-hint/+merge/368655
#ubuntu-release 2019-06-12
<RAOF> blackboxsw: The curtin update appears to add a new dependency on probert?
<RAOF> blackboxsw: ...which is in Universe, so you'll need to get that into Main before we could release the SRU?
-queuebot:#ubuntu-release- Unapproved: u-boot (xenial-proposed/main) [2016.01+dfsg1-2ubuntu4 => 2016.01+dfsg1-2ubuntu5] (desktop-core, ubuntu-server)
<apw> ^ intended as a fix for the u-boot in xenial-proposed
-queuebot:#ubuntu-release- Unapproved: glib-networking (disco-proposed/main) [2.60.1-1 => 2.60.3-1~ubuntu19.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: glib2.0 (disco-proposed/main) [2.60.0-1ubuntu0.1 => 2.60.4-0ubuntu0.19.04.1] (core)
<rbasak> apw: by fixed in later versions, do you mean that you've confirmed that "return ret" is present in the newer series including the development release?
<rbasak> apw: if so, then +1 for your u-boot one line quilt patch upload - do you want me to accept?
<apw> rbasak, exactly that, i traced it to making that change, then confirmed that the next series version was fixed in that way already
<apw> rbasak, yes please
<rbasak> done
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (xenial-proposed) [2016.01+dfsg1-2ubuntu5]
<apw> rbasak, thanks
-queuebot:#ubuntu-release- Unapproved: vaultlocker (bionic-backports/universe) [1.0.3-0ubuntu1~ubuntu18.04.1 => 1.0.3-0ubuntu1.18.10.1~ubuntu18.04.1] (no packageset)
<jibel> cking, Hi, do you plan to fix the failing tests of zfs-linux 0.7.12-1ubuntu6 / spl-linux 0.7.12-1ubuntu4. It seems that they must depend on each other to build.
<cking> jibel, yep, i keep on getting distracted by other issues, I will get around to it today
<jibel> cking, thanks
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.11-0ubuntu0.18.04.2 => 12.2.12-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
<cking> https://appletonwildlifediary.wordpress.com/
<cking> oops, that was not meant to be pasted there
<jamespage> vorlon: hey - did you have any feedback on the binary packaging changes for https://launchpad.net/ubuntu/+source/ceph/14.2.1-0ubuntu1 ?
<jamespage> the one that cast doubt in my mind was the libradospp-dev package - trying to get to the bottom of why upstream ceph thought that was needed
<jamespage> cking: nice post all the same - love a bee orchid :-)
<cking> ah, serendipity
<coreycb> hello, can an archive admin please remove the binary package for python-oslo.log 3.44.0-0ubuntu2 from eoan-proposed? this was partially done yesterday i think but it seems the binary is still there.
<coreycb> python3-oslo.log is the binary
<cjwatson> It is not still there
<cjwatson> Where are you seeing it?
<cjwatson> "rmadison -s eoan,eoan-proposed -S python-oslo.log" does not show it, and https://launchpad.net/ubuntu/eoan/amd64/python3-oslo.log shows that binary as deleted
<jamespage> coreycb: I guess you hit rebuild again :)
<cjwatson> I hit retry on https://launchpad.net/ubuntu/+source/python-oslo.log/3.44.0-0ubuntu3/+build/16934603 to make sure I'm looking at something current
<jamespage> ah right-oh
<cjwatson> That built
<cjwatson> I didn't make a careful note of the time before retrying, but buildd-manager logs say nobody had retried it since the removal
<xnox> rbasak:  do you have capacity to process an openssl sru for bionic to fix up the 1.1.1 landing.
<rbasak> xnox: I suspect that's non-trivial? If so, sorry, I don't this week (and probably not next week).
<rbasak> I'm a bit behind on things I'd like to have finished two weeks ago, and am blocking people :-/
<xnox> rbasak:  it actually is a trivial diff.
<coreycb> jamespage: nope
<rbasak> xnox: but does that make it a trivial review? :)
<coreycb> jamespage: ah you got a response
<coreycb> jamespage: well that was easy :)
<xnox> rbasak:  https://paste.ubuntu.com/p/56WzxXCSnt/ the bit that are slightly more time sensitive is the postinst ;-)
<xnox> rbasak:  there is more comments then code changes? =)
<xnox> rbasak:  basically we forgot to restart services upon upgrade from 1.1.0 to 1.1.1 and we must do that....
<rbasak> xnox: for me that's a non-trivial review, sorry. It'll take me time to understand the context.
<coreycb> cjwatson: thanks and sorry for the noise. i assumed the new python-oslo.log was uploaded this morning.
<xnox> rbasak:  ack
-queuebot:#ubuntu-release- Unapproved: fetchmail (bionic-proposed/main) [6.3.26-3build1 => 6.3.26-3ubuntu0.1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted fetchmail [source] (bionic-proposed) [6.3.26-3ubuntu0.1~18.04.1]
<vorlon> jamespage: sorry, infinity had asked about the ceph binaries and I said I hadn't gone far enough to be holding a lock on the review, I thought he was going to take a look
<xnox> vorlon:  can you please review this openssl bionic SRU hotfix? https://paste.ubuntu.com/p/FxNnWp2d4F/    it has a regression fix, a low CVE, and an upgrade maintainer script to actually trigger restarting services......
<xnox> (the last bit makes many things not-worky until restarted, or the machine reboots)
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.1 => 1.1.1-1ubuntu2.1~18.04.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2.1 => 1.1.1b-1ubuntu2.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu2.2 => 1.1.1-1ubuntu2.3] (core) (sync)
<xnox> vorlon:  the srus for other releases do not have maintainer script thing, as well, not needed / too late.
<xnox> vorlon:  and they are syncs, because built in security pocket, to be copyable into -security as requested by the security team.
<vorlon> xnox: I don't love seeing adjustments to the behavior of the service-checking code in an SRU hotfix...
<xnox> vorlon:  i can get away with just changing the version numbers in those hunks.
<vorlon> xnox: that would reduce friction
<xnox> vorlon:  meaning only services that still have matching initd scripts will be restarted by invoke-rc.d => which should be true for most/all the ones listed.
<xnox> vorlon:  what about the other two patches cherrypicked from upstream. Are those ok, or not?
 * xnox prepares reupload.
<vorlon> xnox: ah, because we do a literal check for /etc/init.d/foo there... hmm
<vorlon> so rbalint was right ;)
 * vorlon checks to see if this is still buggy in libpam
<xnox> vorlon:  and invoke-rc.d internally redirects to systemctl. Thus the right thing to check is with systemctl is-active => cause only those will be restartable.....
<xnox> i can quickly pull all of the packages mentioned, to double check that they still ship init.d/ scripts or not.
<vorlon> xnox: yeah considering we've never agreed to drop init scripts and it's still required by Debian policy, I think we should just go with the version-check-only change for now
<xnox> vorlon:  uploading
<xnox> vorlon:  please reject the current sync then.
<vorlon> ack
<xnox> (the bionic one only)
<vorlon> done
-queuebot:#ubuntu-release- Unapproved: rejected openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.1 => 1.1.1-1ubuntu2.1~18.04.2] (core) (sync)
<xnox> vorlon:  updated sru ^
<vorlon> xnox: test case on LP: #1828215 appears to depend on files not included in the test case, where should they be sourced?  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1828215/comments/6 ?
<ubot5> Launchpad bug 1828215 in openssl (Ubuntu Disco) "openssl ca -spkac output regressed" [High,Confirmed]
<xnox> vorlon:  in the comments of the bug.
<vorlon> xnox: can you please extract that into a recipe in the description that can be followed without reference to the comments
<xnox> vorlon:  i.e. it is just /etc/ssl/openssl.cnf with more stanzas added to them.
<vorlon> and without "assumes you've already generated a CA key" which most SRU testers aren't going to have just lying around
-queuebot:#ubuntu-release- Unapproved: erlang (bionic-proposed/main) [1:20.2.2+dfsg-1ubuntu2 => 1:20.2.2+dfsg-1ubuntu2.1] (ubuntu-desktop, ubuntu-server)
<xnox> vorlon:  updated will all step by step instructions from scratch. creates CA, creates CA key, creates cert request, spkac request, and signs it
<xnox> could be made more non-interactive, and quicker, but this is all step by step and works. just redid it from scratch in a chroot.
<vorlon> xnox: thank you
<vorlon> xnox: unrelated, any idea why the apache2 autopkgtests broke again? they were broken for a while by libfoo-ssl-perl, now they're broken differently
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.2]
<xnox> vorlon:  in which releases? they are a bit fragile and i was monitoring it.... it's only arm64 at the moment, no?
<xnox> (in eoan, unless you mean some other release)
<vorlon> xnox: arm64/eoan yes
<vorlon> infinity: I notice that the Debian release team has announced a buster target release date of July 6; and eoan DIF is set to August 22.  Should we consider moving up DIF to match buster release, so we don't import the first month's worth of crazy from unstable?
<cjwatson> Better get it in eoan than in F, IMO
<cjwatson> I'm sure there'll be some new upstreams and such that we want to have in 20.04 and where it'd be better for them to have a cycle to shake out
<cjwatson> ICBW
<xnox> vorlon:  both openssl bugs verified; i guess wait for autopkgtests results and release?
<xnox> (autopkgtests to confirm it's not a complete toast)
<vorlon> cjwatson: fair point, if we're going to get a logjam it may be better to have it sooner
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (cosmic-proposed) [1.1.1-1ubuntu2.3]
<vorlon> xnox: to be clear, this SRU is slated to be released to -security and that's why there's a CVE ref with no bug #, right?
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (disco-proposed) [1.1.1b-1ubuntu2.2]
<juliank> vorlon: I think we should probably look at experimental now and start merging from there if possible to reduce a jam
<juliank> Also, is anything crazy going on that would interfere with an apt ABI+API break?
<juliank> I guess I'll do rebuilds in PPA first
<juliank> but still
<juliank> I don't think I see anything
<vorlon> juliank: I consider merging from experimental something to only be done if the merger is making a committment to field bugs in lieu of the Debian maintainer if that version doesn't make it to unstable before the next Ubuntu release
<juliank> Well, I guess if you know that they're planning to upload to unstable
-queuebot:#ubuntu-release- Unapproved: scilab (disco-updates/universe) [6.0.2-0ubuntu1 => 6.0.2-0ubuntu2~19.04] (no packageset) (sync)
<juliank> Oh I guess I'll just add an apt transition tracker for planned transitions to make sure I get a good overview?
<juliank> like bad is libapt-pkg5.0|libapt-inst2.0, good is libapt-pkg5.90
<juliank> but with proper quoting
<juliank> or rather escaping
-queuebot:#ubuntu-release- Unapproved: scilab (cosmic-updates/universe) [6.0.1-7ubuntu1~18.10 => 6.0.1-7ubuntu1~18.10.1] (no packageset) (sync)
<juliank> This seems about right: https://paste.ubuntu.com/p/3mqHtv7Nc5/
<juliank> Note that we're dropping libapt-inst, as it's folded into libapt-pkg
<juliank> (and the combined library is smaller than an older libapt-pkg thanks to removal of deprecated code :D)
<vorlon> in which case the last regexp can be shortened to /libapt-pkg5\.0|libapt-inst/
<juliank> true
<vorlon> and don't forget your \b around words
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-updates/universe) [6.0.1-7ubuntu1~18.04 => 6.0.1-7ubuntu1~18.04.1] (no packageset) (sync)
<vorlon> (maybe not necessary in this case, but we have a history of overbroad regexps in the tracker)
<juliank> it's fine here
<vorlon> yes but it sets a bad example for others who cargo-cult you later ;)
<juliank> vorlon: Is .depends ~ /\b(libapt-pkg5\.90)\b/ equivalent to .depends ~ "libapt-pkg5.90"?
<vorlon> does the tracker support a non-regexp form?  I'm not familiar with that
<juliank> there are some examples in there that use it
<juliank> but I'm not sure if it's whole words
<juliank> with \b and shortened a bit, I have https://paste.ubuntu.com/p/nKGGS4Yyz8/
<juliank> hmm, why do I have () in is_good, not necessary there
-queuebot:#ubuntu-release- Unapproved: scilab (disco-proposed/universe) [6.0.2-0ubuntu1 => 6.0.2-0ubuntu2~19.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-proposed/universe) [6.0.1-7ubuntu1~18.04 => 6.0.1-7ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scilab (cosmic-proposed/universe) [6.0.1-7ubuntu1~18.10 => 6.0.1-7ubuntu1~18.10.1] (no packageset) (sync)
<cjwatson> AFAICS, ben implements ~ "..." by splitting the string on |, regex-quoting each piece, joining with | again, and then matching using /\b(%s)\b/
<cjwatson> Also damnit you made me try to read ocaml
<juliank> cjwatson: heh
<juliank> I quite like ocaml
<juliank> Not that I've ever used it
<cjwatson> You can work out any remaining fine details then :)
<juliank> but I did provide like two patches or so
<juliank> for edos something I think
<juliank> but really never had the chance to actually invest more like a few mins in it, or compile any ocaml program
 * juliank committed the regex version fwiw, with the  \b added in the useful places
<juliank> But I'm going to sleep, so I hope I did not break it
<cjwatson> I'm pretty sure the answer to your equivalence question is yes BTW, in case that wasn't clear from what I wrote
<juliank> it was perfectly clear
<cjwatson> Good
<bdmurray> tjaalton: Could address https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894/comments/42 since you changed the tag from failed to done?
<ubot5> Launchpad bug 1740894 in xkeyboard-config (Ubuntu Bionic) "KEY_RFKILL is not passed to userspace" [Low,Fix committed]
<tdaitx> I mistankenly uploaded scilab to bionic/cosmic/disco -updates (should have been -proposed, which I did shortly after), could someone please take care of rejecting the ones for -updates?
<tdaitx> s/uploaded/copied/
-queuebot:#ubuntu-release- New binary: utf8.h [amd64] (eoan-proposed/none) [0~git20190120.2a7c5bf-1] (no packageset)
#ubuntu-release 2019-06-13
<xnox> vorlon:  it's a low, but yes. should release to -updates first; as push to -security is an avalanche of all the packages.
<xnox> vorlon:  ie. we want to coordinate release to -security slightly later.
<vorlon> xnox: does this mean the security team should sign off on it being ready to release to updates, since there are changes with no bug and no test case?
<xnox> vorlon:  i have no idea what the process is. Or i can open a launchpad bug report with the CVE identifier and a test case.
<xnox> "specs say this is max; use max; don't use anything higher than max; try to use more than max; fail"
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-430 (eoan-proposed/primary) [430.26-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1042.47] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1042.47]
-queuebot:#ubuntu-release- Unapproved: rejected scilab [sync] (bionic-updates) [6.0.1-7ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected scilab [sync] (disco-updates) [6.0.2-0ubuntu2~19.04]
-queuebot:#ubuntu-release- Unapproved: rejected scilab [sync] (cosmic-updates) [6.0.1-7ubuntu1~18.10.1]
<apw> ^ all direct to -updates
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1009.10] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1009.10]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (disco-proposed) [20101020ubuntu570.1]
<LocutusOfBorg> please update: force-badtest libgd2/2.2.5-5/amd64 libgd2/2.2.5-5.1/amd64 to
<LocutusOfBorg> force-badtest libgd2/2.2.5-5/amd64 libgd2/2.2.5-5.1/amd64 libgd2/2.2.5-5.2/amd64
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.23]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu557.2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.8]
<LocutusOfBorg> apw, ^^ can you please bump the hint?
<apw> LocutusOfBorg, yu have confirmed it is the same ?
<apw> LocutusOfBorg, anyhow done
<LocutusOfBorg> sorry!
<LocutusOfBorg> I can't reach anymore any website *ubuntu*
<apw> LocutusOfBorg, got a specific one?  ubuntu.com works for me
<LocutusOfBorg> looks like vodafone is screwing up with dns
-queuebot:#ubuntu-release- Unapproved: netbeans (bionic-proposed/universe) [10.0-3~18.04.1ubuntu1 => 10.0-3ubuntu2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: netbeans (cosmic-proposed/universe) [10.0-3~18.04.1ubuntu1 => 10.0-3ubuntu2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: netbeans (disco-proposed/universe) [10.0-3 => 10.0-3ubuntu2~18.04.1] (no packageset) (sync)
<LocutusOfBorg> apw, anyway, yes! it is the same as before
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.39-1ubuntu1~18.04.1 => 8.5.39-1ubuntu1~18.04.2] (kubuntu) (sync)
<Laney> http://[2001:ba8:1f1:d03:216:3eff:fef0:f2f0]/
<Laney> getting there with the new charms
<rharper> sil2100: I was wondering if you could remove the curtin upload into the unapproved queues (xenial, bionic, cosmic, disco)?  I need to upload a replacment with a change to debian/control (not a new version)
<rharper> s/into/in
<sil2100> rharper: sure, on it
<rharper> sil2100: thanks!
<apw> rharper: you don't need to wait for them to be rejected to replace them
<rharper> apw: even with the same version?
<rharper> dput with --force or something ?
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (cosmic-proposed) [19.1-7-g37a7a0f4-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (disco-proposed) [19.1-7-g37a7a0f4-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (bionic-proposed) [19.1-7-g37a7a0f4-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (xenial-proposed) [19.1-7-g37a7a0f4-0ubuntu1~16.04.1]
<apw> rharper: right, they really don't exist in archive terms in the queue
<rharper> apw: nice! thanks for that
<apw> 2 of the same version will cause confusion for the reviewers, which you resolve by telling us here what you are doing
<rharper> apw: right
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (disco-proposed) [2.2.40-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (cosmic-proposed) [2.2.40-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (bionic-proposed) [2.2.40-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.40-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~16.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.10.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-22-g08bf6ff7-0ubuntu1 => 19.1-7-g37a7a0f4-0ubuntu1~19.04.1] (ubuntu-desktop, ubuntu-server)
<rharper> sil2100: thanks for the help, if you have time, could you look at the curtin SRU to approve into the -proposed pocket, https://bugs.launchpad.net/curtin/+bug/1831772
<ubot5> Launchpad bug 1831772 in curtin (Ubuntu Disco) "sru curtin 2019-06-05 - 19.1-7-g37a7a0f4-0ubuntu1" [Undecided,Incomplete]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.40]
<sil2100> rharper: let me try getting to that today
<rharper> thanks!  appreciate your help
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [source] (eoan-proposed) [430.26-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-430 [i386] (eoan-proposed/restricted) [430.26-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted netbeans [sync] (disco-proposed) [10.0-3ubuntu2~18.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-430 [amd64] (eoan-proposed/restricted) [430.26-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [i386] (eoan-proposed) [430.26-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [amd64] (eoan-proposed) [430.26-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (disco-proposed) [6.0.2-0ubuntu2~19.04]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (cosmic-proposed) [6.0.1-7ubuntu1~18.10.1]
<Eickmeyer> Not sure what's going on and why ubuntustudio-controls is stuck in eoan-proposed, but, it's stuck. https://launchpad.net/ubuntu/+source/ubuntustudio-controls/1.8.1
-queuebot:#ubuntu-release- Unapproved: rejected netbeans [sync] (cosmic-proposed) [10.0-3ubuntu2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected netbeans [sync] (bionic-proposed) [10.0-3ubuntu2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (bionic-proposed) [6.0.1-7ubuntu1~18.04.1]
<ginggs> Eickmeyer: from https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<ginggs> trying: ubuntustudio-controls
<Eickmeyer> ginggs: Thanks, I couldn't remember the spot.
<ginggs>     got: 4+0: a-0:a-0:a-2:i-0:p-0:s-2
<ginggs>     * armhf: ubuntustudio-desktop, ubuntustudio-desktop-core
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.39-1ubuntu1~18.04.2]
<Eickmeyer> ginggs: I'm not 100% sure what's broken there. Got any clues?
<acheronuk> it means migrating  ubuntustudio-controls would result in armhf: ubuntustudio-desktop, ubuntustudio-desktop-core being uninstallable
<acheronuk> working out why that should be is the trick....
<Eickmeyer> acheronuk: That's strange. I just checked the seed (generates the metapackages) and can't find any clues there.
 * Eickmeyer fixed the version number, probably the problem
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [sync] (bionic-proposed) [1.14.4-1ubuntu1.1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [sync] (bionic-proposed) [1.14.4-1ubuntu1~ubuntu18.04.1]
<Eickmeyer> acheronuk: Thanks. Looks like it was depending on a package that doesn't build in certain architectures. Demoted that to recommends, so that should fix it.
<acheronuk> Eickmeyer: sounds plausible. welcome to proposed migration "why the hell doesn't that migrate" fun ;)
<Eickmeyer> hahaha
<acheronuk> sometimes it is obivious
<acheronuk> sometimes it is WTF
<Eickmeyer> This was a bit more WTF than obvious, but once I figured out what was wrong (what changed? It just now depends on.... oh, great. >.<), i reuploaded.
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [sync] (bionic-proposed) [1.14.4-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (bionic-proposed) [1.14.4-0ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [19.1-7-g37a7a0f4-0ubuntu1~18.04.1]
<sil2100> rharper: hey, the disco curtin upload has a lot of bugs in the .changes file
<rharper> sil2100: urg; sorry, lemme fix l; thank you for the review
<sil2100> rharper: I would expect only the tracking bug and the dependency-removal bugs to be present like in the other series
<sil2100> Thanks! Let me reject it then ;)
<rharper> correct; my mistake;  Thanks again for catching my mistakes
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (cosmic-proposed) [19.1-7-g37a7a0f4-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (disco-proposed) [19.1-7-g37a7a0f4-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [19.1-7-g37a7a0f4-0ubuntu1~16.04.1]
<sil2100> rharper: yw, small mistakes like that happen! Anyway, I will be going EOD now, but please upload it whenever you have a moment
<sil2100> I'll upload it when I see it in the queue
<sil2100> o/
<rharper> sil2100: thanks!
<sil2100> s/upload/review
-queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-22-g08bf6ff7-0ubuntu1 => 19.1-7-g37a7a0f4-0ubuntu1~19.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.27]
<chrisccoulson> could somebody please copy the adobe-flashplugin partner packages that are sat in proposed for xenial -> disco? (and copy them to release in a bit)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.27 => 2.525.28] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.28]
-queuebot:#ubuntu-release- New source: s390-tools-signed (eoan-proposed/primary) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu2 => 2.9.0-0ubuntu2] (core)
#ubuntu-release 2019-06-14
<apw> ^ /me will look at those once we have the launchpad support in place
<cjwatson> apw: which is already, right?
<cjwatson> apw: I deployed your SIPL code yesterday
<apw> cjwatson, i was under the impression the key was not yet in place; perhaps i missed that
<cjwatson> apw: I installed that the day before yesterday :)
<apw> cjwatson, ahh i stand corrected, will look at it next :)
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (disco-proposed) [19.1-7-g37a7a0f4-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20190611.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190611.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190611.1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190611.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected s390-tools-signed [source] (eoan-proposed) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New source: s390-tools-signed (eoan-proposed/primary) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected s390-tools-signed [source] (eoan-proposed) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New source: s390-tools-signed (eoan-proposed/primary) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted s390-tools-signed [source] (eoan-proposed) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: s390-tools-signed [s390x] (eoan-proposed/none) [2.9.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted s390-tools-signed [s390x] (eoan-proposed) [2.9.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2.2 => 1.1.1b-1ubuntu2.3] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu2.3 => 1.1.1-1ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.2 => 1.1.1-1ubuntu2.1~18.04.3] (core)
<xnox> apw:  can you please reject all three of openssl above ^ ? they shouldn't be direct uploads, but should be built in -security only silo, and copied in.
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (cosmic-proposed) [1.1.1-1ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.3]
<xnox> tah
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.2 => 1.1.1-1ubuntu2.1~18.04.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu2.3 => 1.1.1-1ubuntu2.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2.2 => 1.1.1b-1ubuntu2.3] (core) (sync)
<tjaalton> bdmurray: i'll discuss the KEY_RFKILL bug with seb next week,when he's back
<xnox> vorlon:  fresh set of openssl sru syncs for you to review =) please =)
<vorlon> xnox: for disco it seems only the fixes for the restart handling are included, not the other fixes; are those still in progress?
<xnox> vorlon:  what other fixes?
<vorlon> xnox: the other openssl 1.1.1-induced regressions that were being discussed yesterday and whose bug numbers I would have to hunt down
<xnox> regression in 1.1.1 and 1.1.1a; fixed upstream in 1.1.1b and up
<vorlon> ok
<xnox> bug #1832659
<ubot5> bug 1832659 in openssl (Ubuntu Cosmic) "openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350" [Undecided,New] https://launchpad.net/bugs/1832659
<vorlon> and LP: #1832370 is still incomplete
<ubot5> Launchpad bug 1832370 in openssl (Ubuntu Eoan) "Unable to configure or disable TLS 1.3 via openssl.cnf" [High,Incomplete] https://launchpad.net/bugs/1832370
<vorlon> (w/ follow-up from submitter suggesting it should be closed invalid)
<xnox> vorlon:  re-inability to cap to tlsv1.2 and/or reorder ciphersuites is incomplete/invalid. I managed to tweak my openssl.cnf to both cap, or reorder ciphersuites.
<vorlon> ack
<xnox> ah
<xnox> vorlon:  closed as invalid
<vorlon> xnox: why does the disco SRU bump the minimum version for restarting to 1.1.1-1ubuntu2.1~18.04.2, which is ultimately an arbitrary point in the bionic SRU history?
<vorlon> is it because that's the first version that triggers the service restart correctly on bionic?
<xnox> vorlon:  we need to restart anybody who is coming from 1.1.0 or the 1.1.1 version that didn't restart people.
<xnox> vorlon:  yes.
 * xnox needs to not forget to bump that, when going to v3.0.0 somehow
<vorlon> 1.1.1-1ubuntu2.1 in cosmic is a higher version number.  did that have the restart correct?
<xnox> no, bu cosmic shipped with 1.1.1 to begin with in release pocket.
<xnox> this is for upgrades from bionic-release => any of these releases really.
<xnox> and/or lts -> lts
<vorlon> ok
<xnox> i.e. for people who installed cosmic/bionic/eoan this is a no-op, and will not fire.
<xnox> cosmetic.
<xnox> but also all postinsts are the same now =)
<vorlon> hmm, alright
<vorlon> I'll accept the consistency argument
<vorlon> otherwise I would've been inclined to say that the minimum version should've been set at 1.1.1 instead of 1.1.1-1ubuntu2.1~18.04.2,
<xnox> debian didn't bump it, cause they are going from libssl1.0.2 => libssl1.1 where 1.1 is 1.1.1
<xnox> but probably should report it there too....
<vorlon> because "I installed bionic and upgraded to an old 1.1.1 and my services were broken but I never restarted them and I didn't apply any later updates but I dist-upgraded to disco" <-- uh ok
 * xnox would find it weird how come version check is different on bionic vs other releases, and how to calculate it right.... and for all practical reasons 1.1.1-1ubuntu2.1~18.04.2 is equivalent to 1.1.1, on post-bionic releases.
<vorlon> well, I find having that particular version string in the postinst confusing to read / reason about, see also the preceding discussion, and a 1.1.1 would I think be clearer to people later
<vorlon> but as I said, I'm ok with the consistency argument
<xnox> ack
<vorlon> xnox: LP: #1832421> this observation is not for SRU, but I think given systemd we should be doing much better than this in the future as it is now possible to not only get a complete list of processes on the system that have an out-of-date library loaded in memory, but also to map them to systemd units and figure out which require what kind of notification to the user
<ubot5> Launchpad bug 1832421 in openssl (Ubuntu Disco) "openssl reboot needed message using incorrect path to X server" [Undecided,New] https://launchpad.net/bugs/1832421
<xnox> interesting
<xnox> vorlon:  but e.g. Xorg is just a usersession process in the user scope, not a unit by itself.
<xnox> checking libary loaded mappings and mapping it to unit names will be fun.
<vorlon> xnox: yes, but my point is that before we set any flags at all saying "reboot required", we should actually inspect what units have the old library loaded, which currently we do not
<vorlon> currently we unconditionally set that flag on servers on upgrade
<xnox> we need a card for this
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (disco-proposed) [1.1.1b-1ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (cosmic-proposed) [1.1.1-1ubuntu2.4]
<vorlon> xnox: hmm openssl 1.1.1-1ubuntu2.1~18.04.3 wrongly lists LP: #1832522 a second time
<ubot5> Launchpad bug 1832522 in openssl (Ubuntu Disco) "openssl maintainer scripts do not trigger services restart" [Undecided,Fix committed] https://launchpad.net/bugs/1832522
<vorlon> xnox: can you fix that quickly, please?  I don't want wrong user-visible changelogs in an SRU, or for this bug to be entangled in the SRU tracking
<xnox> looking
<xnox> yeah that's buggy
<xnox> vorlon:  reject it please
-queuebot:#ubuntu-release- Unapproved: rejected openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.3]
<vorlon> eoan/armhf autopkgtest queue cut by a third by --all-proposed'ing the kde autopkgtests
<xnox> ah, maybe we should always do that, when all of that goo lands
<vorlon> xnox: automation welcome
<vorlon> currently it looks like for queue in debci-huge-eoan-armhf debci-eoan-armhf; do ./autopkgtest-cloud/tools/filter-amqp $amqp_url $queue
<vorlon> '\b(ktextwidgets|kio|kxmlgui|kcompletion|kconfigwidgets|kiconthemes|kcrash|kservice|kwidgetsaddons|ki18n|kwindowsystem|kcoreaddons|kirigami2|kpeople|kwallet-kf5|kbookmarks|knotifyconfig|kinit|knewstuff|baloo-kf5|kdeclarative|kparts|kactivities-kf5|kross|kded|kdewebkit|kcmutils|khtml|frameworkintegration|kmediaplayer|ktexteditor|kactivities-stats|kdelibs4support|plasma-framework|krunner)\b'; done;
<vorlon> retry-autopkgtest-regressions --state RUNNING --all-proposed | grep -E '[...]'
<vorlon> anyway, total queue size down now by closer to 50%, and the reshuffle actually means the kde tests are at the back of the queue again, so we ought to see chings making progress
<xnox> vorlon:  re deleted maps.... we really ought to do that at the end of every upgrade really.
<xnox> at least least things, offer to restart them, and/or raise reboot flags. Or at least like login/logout notifications.
<xnox> i think i need to reboot my laptop now, so many deleted maps.....
<vorlon> xnox: there's a spectrum here.  Some libs we know break after major upgrades because of plugin libraries and warrant prompting about affected services (libc, pam, openssl); security updates should be in your face (and that should probably be handled by debian/rules glue to notice CVEs in changelogs and bail about maintainer scripts not being updated, or by actually auto-generating the min versions
<vorlon> based on changelog); some updates are just inconvenient overhead on the fs if you don't restart
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.2 => 1.1.1-1ubuntu2.1~18.04.3] (core) (sync)
<xnox> vorlon:  updated ^
<vorlon> xnox: accepted, thanks
<xnox> yeah
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.3]
<vorlon> who's triggering langpack updates these days?  language-pack-gnome-fi-base seems to have gotten missed for upload
<vorlon> coreycb: hi, have you seen the regressed autopkgtests on python-oslo.*?
<coreycb> vorlon: I'm off today but that might be fixed with the latest upload
<vorlon> coreycb: hmm latest upload of what?
<vorlon> librust-curl+force-system-lib-on-osx-dev | 0.4.22-1      | new        | amd64
<vorlon> sure, that's a perfectly reasonable justification for having a rust-cargo uploaded with its build-dependencies unsatisfiable in the Debian archive
-queuebot:#ubuntu-release- Unapproved: rejected gnupg [source] (xenial-proposed) [1.4.20-1ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (xenial-proposed) [1:3.18.2-1ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.2-0ubuntu0.18.04.5]
#ubuntu-release 2019-06-16
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [i386] (eoan-proposed/universe) [3ubuntu6] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [amd64] (eoan-proposed/universe) [3ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [195-1~ubuntu19.04.1 => 196-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [195-1~ubuntu18.10.1 => 196-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [196-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [196-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [195-1~ubuntu18.04.1 => 196-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [196-1~ubuntu18.04.1]
#ubuntu-release 2020-06-08
-queuebot:#ubuntu-release- New source: artyfx (groovy-proposed/primary) [1.3+git20200508-0ubuntu1]
-queuebot:#ubuntu-release- Packageset: 233 entries have been added or removed
-queuebot:#ubuntu-release- New source: redkite (groovy-proposed/primary) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openssh (focal-proposed/main) [1:8.2p1-4 => 1:8.2p1-4ubuntu0.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: syndication [amd64] (groovy-proposed/universe) [1:5.70.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chiark-tcl-applet [amd64] (groovy-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cmath [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-libnotify [amd64] (groovy-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted syndication [amd64] (groovy-proposed) [1:5.70.0-1]
-queuebot:#ubuntu-release- New: accepted chiark-tcl-applet [amd64] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-rack-livereload [amd64] (groovy-proposed) [0.3.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-polyglot [amd64] (groovy-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New: accepted sugar-etoys-activity [amd64] (groovy-proposed) [116-8]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (groovy-proposed) [10.1.243-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (groovy-proposed) [10.1.243-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted subversion [riscv64] (groovy-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted hera [amd64] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [armhf] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [riscv64] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [amd64] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hera [armhf] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hera [riscv64] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted php-horde [amd64] (groovy-proposed) [5.2.21+debian1-1]
-queuebot:#ubuntu-release- New: accepted wiki2beamer [amd64] (groovy-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted hera [arm64] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [s390x] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [ppc64el] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wiki2beamer [amd64] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted hera [ppc64el] (groovy-proposed) [0~git20200602+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hera [s390x] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hera [arm64] (groovy-proposed) [0~git20200602+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [amd64] (groovy-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [armhf] (groovy-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [riscv64] (groovy-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [arm64] (groovy-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [s390x] (groovy-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-cool.io [ppc64el] (groovy-proposed) [1.6.0-1]
<cpaelzer> hi, there was another perl upload https://launchpad.net/ubuntu/+source/perl/5.30.3-4
<cpaelzer> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html lists the tests as running, but the following is empty
<cpaelzer> wget -q http://autopkgtest.ubuntu.com/queues.json -O - | sed -e 's/\\"/"/' | grep -e '\\n{"triggers": \["perl/5.30.3"\]'
<cpaelzer> Laney: I actually wanted to ask to cancel the 5.30.3-2 tests, but it seems something/someone already cancelled too much
<cpaelzer> Laney: do you have a better way to check the queue?
<Laney> cpaelzer: no, but I can see in the history that someone filtered 5.30.3-4 already
<Laney> don't know why
<cpaelzer> that was a bit overzealous I think
<cpaelzer> unless it is known that there will be another anotherone in a few hours
<cpaelzer> Laney: does it track who issued that?
<Laney> no, it's a shell command
<Laney> under a shared user
<Laney> but I could have a good guess that the person's nickname starts with a 'v' ;-)
<cpaelzer> hehe
<xnox> Laney:  i think that was a mistake
<xnox> Laney:  the intention was to clear the old -2/-1 tests from 5th of june
<Laney> evidence?
<xnox> which were still scheduled to run
 * xnox asked him, he "did it", yet old ones were still there, he "did again"
<xnox> Laney: I did seemed to me that too many tests were dropped.
<Laney> again, would be better if such conversations happen in here
<cpaelzer> agreed
<xnox> Laney:  i wonder if somebody should rescheduled the running ones =)
<xnox> because yeah, the queues got dropped by too much
<cpaelzer> well, we can reschedule if we are sure that this was what removed them
<Laney> doing
<Laney> not the running (always failed) ones, just running
<cpaelzer> Laney: IIRC the "always failed" also need to complete somehow to let britney consider the results - is there a way to fully-abort them in the state-machine?
<Laney> pretty sure they don't
<cpaelzer> ok we will see then
<cpaelzer> I already see the queue refill - thanks Laney
<Laney> cpaelzer: np!
<cjwatson> cpaelzer: your queues.json grep didn't work because (a) it should have been 5.30.3-4 rather than 5.30.3 (b) it looks as though a bunch of things were triggered by other things as well as perl
<cjwatson> Oh and because even more escaping I think
<cpaelzer> cjwatson: oh that was fixed already
<cpaelzer> cjwatson: it was really empty 5 minuts back in time
<cjwatson> OK
<xnox> cjwatson:  which sort of people can/know-how to remove stray signed things from the archive? https://bugs.launchpad.net/bugs/+bugs?field.tag=rm-signed
<xnox> cjwatson:  i've asked a couple of AAs and they said they don't know or don't want to do that alone.
<xnox> cjwatson:  i assume infinity vorlon wgrant and you know how to do that? Is it manual ssh to master rm, or is there an API?
<apw> xnox, i likely can arrange for it to happen; can you pm me the list
<apw> xnox, or bug which ever it was
<xnox> oooh
<xnox> apw:  https://bugs.launchpad.net/bugs/+bugs?field.tag=rm-signed is the lot of them!
<cjwatson> Some of those come back to a Launchpad bug I think
<cjwatson> Removing them will probably only be effective for this cycle
<cjwatson> The problem is that the custom upload model is a very crude bag hung on the side of Soyuz, and LP doesn't really know quite as well as it should what's actually supposed to be published
<apw> cjwatson, cycle == publisher cycle?
<cjwatson> release cycle
<apw> ahh
<cjwatson> So I mean you can nuke them manually off pepo if you like with rm, but they'll probably come back in H
<cjwatson> And fixing that is a fairly deep job
<apw> ahh, thanks for the warnin
<xnox> oh
<xnox> =(
<xnox> cjwatson:  is there something we can do to the newreleasecycle process to like double check if source is published, before copying up those things?
<cjwatson> xnox: No
<cjwatson> It needs data remodelling in Soyuz
<cjwatson> You can't fix it
<cjwatson> You *could* have NRCP say to manually remove stuff after the initial publication
<cjwatson> I don't think it's a great plan, but you could
<cjwatson> (Because we're better off not encouraging people to mess about in the live master archive with rm)
<cjwatson> efilinux was IIRC literally the first thing to be signed in Launchpad and it was removed in wily, so this is not at all a new problem
<xnox> cjwatson:  if we ever remove precise/trusty, sources might start disappearing.
<xnox> cjwatson:  is d-i the same, and even if i remove it, it will still keep coming back?
<cjwatson> d-i is the same
<cjwatson> It's a bug, but it's a bug in Launchpad rather than one that should be handled by whack-a-mole rm
<cjwatson> Ah that's right, the copy is done in the first publisher run by PublishFTPMaster.prepareFreshSeries
<xnox> is there a bug number we can track for this?
<LocutusOfBorg> hello, can any AA please have a look at LP: #1882106 and LP: #1882217 ?
<ubot5> Launchpad bug 1882106 in virtualbox-hwe (Ubuntu Focal) "[SRU] virtualbox 6.1.*" [Undecided,In progress] https://launchpad.net/bugs/1882106
<ubot5> Launchpad bug 1882217 in virtualbox-hwe (Ubuntu Bionic) "[SRU] virtualbox 5.2.*" [Undecided,In progress] https://launchpad.net/bugs/1882217
<LocutusOfBorg> thanks!
<cjwatson> xnox: No, somebody should file one (but I think apw might be doing so)
<apw> yes i am going to make sure
<apw> one even
 * doko restores the groovy package, accidentally removed last week because of a typo in the removal command ...
-queuebot:#ubuntu-release- New sync: groovy (groovy-release/primary) [2.4.17-4ubuntu1]
<doko> don't name a series like a package ;p
-queuebot:#ubuntu-release- New: accepted groovy [sync] (groovy-release) [2.4.17-4ubuntu1]
<didrocks> this is puzzling indeed :)
<LocutusOfBorg> doko, LOL.
<LocutusOfBorg> indeed, this command was returning nothing: reverse-depends -r groovy -b groovy
-queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.2-0ubuntu1.1 => 2:15.0.2-0ubuntu1.2] (openstack, ubuntu-server)
<vorlon> doko: the groovy package> haha
<blackboxsw> sil2100 or SRU vanguard for Monday, we have some cloud-init unapproved uploads queued for X, B, E, and F releases for this SRU bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,New]
<blackboxsw> if someone has a chance to peek at that today, it would be great
<blackboxsw> tjaalton: sorry I missed you friday
-queuebot:#ubuntu-release- Unapproved: lttng-modules (bionic-proposed/universe) [2.10.8-1ubuntu2~18.04.1 => 2.10.8-1ubuntu2~18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.7 => 2.8.0-1ubuntu1~16.04.8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lttng-modules (eoan-proposed/universe) [2.10.8-1ubuntu2 => 2.10.8-1ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.11.2-1 => 2.11.2-1ubuntu0.1] (no packageset)
<Eickmeyer> ubuntu-archive: I'm going to be bringing-in a number of new packages this cycle, mostly audio plugins. Right now, I have two in the NEW source queue: redkite and artyfx. If I could get some attention on these, that would be wonderful. :)
-queuebot:#ubuntu-release- New source: add64 (groovy-proposed/primary) [3.9.3-0ubuntu1]
<Eickmeyer> ubuntu-archive: add64 can be added to that list. ^
<apw> oh what a lovely package name , that doesn't look like 2 architecture name or anything
<Eickmeyer> apw: It's additive synthesizer 64-bit. I also maintain the same package in Fedora.
<Eickmeyer> (where it has been for years)
<Eickmeyer> I was actually surprised we didn't already have it.
-queuebot:#ubuntu-release- New binary: mirage [amd64] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-builder [amd64] (groovy-proposed/universe) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirage [ppc64el] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirage [s390x] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirage [riscv64] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirage [arm64] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mirage [armhf] (groovy-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mirage [arm64] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted mirage [ppc64el] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted mirage [s390x] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted mirage [armhf] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted mirage [riscv64] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted mirage [amd64] (groovy-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted pyqt-builder [amd64] (groovy-proposed) [1.4.0+dfsg-1]
<tsimonq2> Laney: Hey, so I finally circled back around to https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/363643
<tsimonq2> Laney: Who let me touch code when my Python was that bad... :P
<tsimonq2> Laney: Can I get a current copy of running.json? I'd like to write some tests.
-queuebot:#ubuntu-release- Packageset: 2126 entries have been added or removed
<Eickmeyer> ubuntu-archive: I'm going to be bringing-in a number of new packages this cycle, mostly audio plugins. Right now, I have three in the NEW source queue: redkite, artyfx, and add64. If I could get some attention on these, that would be wonderful. :)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [81.0.4044.129-0ubuntu0.20.04.1 => 83.0.4103.97-0ubuntu0.20.04.1] (ubuntu-desktop)
#ubuntu-release 2020-06-09
<Eickmeyer> ubuntu-archive: I'm going to be bringing-in a number of new packages this cycle, mostly audio plugins. Right now, I have three in the NEW source queue: redkite, artyfx, and add64. If I could get some attention on these, that would be wonderful. :)
<ginggs> ubuntu-archive: would someone please remove gnome-chemistry-utils ?  it build-depends on gnome-doc-utils which was already removed, see debian #947529
<ubot5> Debian bug 947529 in src:gnome-chemistry-utils "gnome-chemistry-utils: build-depends on deprecated gnome-doc-utils" [Serious,Open] http://bugs.debian.org/947529
<mwhudson> ginggs: hey https://bugs.launchpad.net/ubuntu/+source/rgtk2/+bug/1719937 looks familiar
<ubot5> Ubuntu bug 1719937 in rgtk2 (Ubuntu) "Please remove r-cran-rgtk2 and r-cran-rggobi s390x binaries" [Undecided,Fix released]
<mwhudson> (i'm about to file exactly the same bug... i wonder when the binaries got removed)
<mwhudson> s/got removed/reappeared/
<ginggs> mwhudson: looks like https://launchpad.net/ubuntu/+source/rgtk2/2.20.34-1build1
<mwhudson> ginggs: huh
<mwhudson> ginggs: i guess if someone retried the currently failing build a million times, it would probably pass eventually
<Trevinho> SRU team: please you can get rid of some duplicated uploads of gnome-shell and mutter, as new dot releases / fixes come up after the initial upload, so feel free to remove the oldest ones.
<Trevinho> (in focal)
-queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.5 => 0.4.6] (no packageset)
-queuebot:#ubuntu-release- New source: oem-sutton.newell-ace-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-somerville-melisa-meta (focal-proposed/primary) [20.04~ubuntu3]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200512.1-0ubuntu0.18.04.1 => 1:20200609.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20200512.1-0ubuntu0.20.04.1 => 1:20200609.1-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200512.1-0ubuntu0.19.10.1 => 1:20200609.1-0ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200512.1-0ubuntu0.16.04.1 => 1:20200609.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (focal-proposed/main) [1:1.6.7-1ubuntu2 => 1:1.6.7-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.5-1ubuntu1~18.04.4 => 1:1.6.5-1ubuntu1~18.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.6.3-2~16.04.2 => 1:1.6.3-2~16.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (eoan-proposed/main) [1:1.6.6-2ubuntu2 => 1:1.6.6-2ubuntu2.1] (core)
<seb128> bdmurray, could you consider moving the pulseaudio/focal SRU from proposed to update despite the missing risvc64 build? That arch is also missing from the current version if focal-updates (security upload) so that isn't a regression
<blackboxsw> RAOF: or bdmurray we have some cloud-init unapproved uploads queued for X, B, E, and F releases for this SRU bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,New]
<blackboxsw> if there is time today, it'd be great to get those into -proposed so we can perform verification
<bdmurray> seb128: I'll have a look
<bdmurray> blackboxsw: okay, noted
<seb128> bdmurray, thanks
<blackboxsw> thx bdmurray
-queuebot:#ubuntu-release- Packageset: Removed binfmt-support from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed mapbox-geometry from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed mapbox-variant from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed mapbox-wagyu from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libconfig-tiny-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libemail-address-xs-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added liblist-utilsby-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added sphinxcontrib-qthelp to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added sphinxcontrib-serializinghtml to i386-whitelist in groovy
-queuebot:#ubuntu-release- New binary: gasic [amd64] (groovy-proposed/universe) [0.0.r19-6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20200609.1-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: python-libusb1 [amd64] (groovy-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200609.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20200609.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200609.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted alsa-ucm-conf [source] (focal-proposed) [1.2.2-1ubuntu0.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1028.29] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-59.53] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-37.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-59.53] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-37.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1015.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1026.28~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1016.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-37.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-59.53] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1015.15] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1026.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-59.53]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-59.53]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1028.29]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-59.53]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1016.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1015.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-37.41]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1026.28] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1015.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-37.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-37.41]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1024.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-37.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-59.53] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1089.99] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-106.107] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1028.29~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-106.107] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1077.87] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-106.107]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-106.107]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1089.99]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1077.87]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-59.53]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1028.29~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1026.28]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1024.26]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-37.41]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.2-45-g5f7825e2-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [20.2-45-g5f7825e2-0ubuntu1~19.10.1]
<Eickmeyer> ubuntu-archive: I'm going to be bringing-in a number of new packages this cycle, mostly audio plugins. Right now, I have three in the NEW source queue: redkite, artyfx, and add64. If I could get some attention on these, that would be wonderful. :)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [20.2-45-g5f7825e2-0ubuntu1~18.04.1]
<Eickmeyer> Also, Ubuntu Studio Focal's live CDs have been FTBFS for over a month now, and I don't know what's causing it. Moreso, it seems to be in the build system. This needs to be fixed ASAP.
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [20.2-38-g8377897b-0ubuntu1~16.04.1]
<Eickmeyer> The dailies, that is.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [20.2-45-g5f7825e2-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-37.41~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1024.26~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1087.97] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1026.28~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1045.49] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-106.107~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-184.214] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/main) [5.4.0-37.41~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1045.49~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1089.99~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1026.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-37.41~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1045.49]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-37.41~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1087.97]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1024.26~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-184.214]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1089.99~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-106.107~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-106.107~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1045.49~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-106.107~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-37.41~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1077.87~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1059.64] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1063.66] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-59.53~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-59.53~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1042.43] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-59.53~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1063.66]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1042.43]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-59.53~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-59.53~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-37.41~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-37.41~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1059.64]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-59.53~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1077.87~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-37.41~18.04.1]
-queuebot:#ubuntu-release- New binary: avahi [i386] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: avahi [ppc64el] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: avahi [amd64] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: avahi [s390x] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: avahi [arm64] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: avahi [armhf] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
<vorlon> Laney, seb128: would you have any idea whether the aa-get-connection-apparmor-security-context.patch patch can be dropped now from dbus?  It was a non-upstreamed method and the comments say it should be dropped once Ubuntu consumers have moved to using the generic GetConnectionCredentials
<seb128> vorlon, it should probably, Laney did add a card to our board previous cycle for it, https://trello.com/c/mnooP2Xd/85-remove-getconnectionapparmorsecuritycontext-from-dbus ... sounds like now would be a good time to do that, best if someone can do an archive grep before so we fix potential users
<vorlon> seb128: archive grep> I was hoping to avoid that :)
<seb128> would be nice if we had a codesearch.ubuntu.com :/
<vorlon> indeed
<seb128> some people in the security team are set it to do an archive grep iirc
<seb128> but sorry, I didn't check so I think it would be best if we could do the archive grepping
<vorlon> yeah but I hate making this the security team's problem either
<vorlon> otoh it was a security team patch in this case, so... :)
<seb128> right, sorry but I don't have a better answer
<vorlon> no worries
<seb128> vorlon, if you are doing merges and feel like doing the avahi one again, Debian moved to python3 now :)
<vorlon> seb128: I just did avahi... :)
<seb128> ah, nice, thanks!
-queuebot:#ubuntu-release- New binary: avahi [riscv64] (groovy-proposed/main) [0.8-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: gasic [amd64] (groovy-proposed/universe) [0.0.r19-7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (focal-proposed) [3.0~a57-1ubuntu38.20.04.2]
#ubuntu-release 2020-06-10
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.10-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.10-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.10-1] (core)
-queuebot:#ubuntu-release- New binary: xevil [amd64] (groovy-proposed/none) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xevil [arm64] (groovy-proposed/none) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xevil [armhf] (groovy-proposed/none) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xevil [riscv64] (groovy-proposed/universe) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xevil [ppc64el] (groovy-proposed/universe) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xevil [s390x] (groovy-proposed/universe) [2.02r2-10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20190827-1ubuntu0.18.04.2 => 0.2.0+git20190827-1ubuntu0.18.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (focal-proposed) [6.1.8-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (focal-proposed) [6.1.8-dfsg-2~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-guest-additions-iso [source] (focal-proposed) [6.1.8-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (focal-proposed) [6.1.8-dfsg-2~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (focal-proposed) [3.36.3-1ubuntu1~20.04.1]
<tjaalton> need an AA to drop bbswitch-dkms from archs which have no nvidia driver
<tjaalton> so that bbswitch can migrate
-queuebot:#ubuntu-release- Unapproved: rejected bbswitch [source] (focal-proposed) [0.8-8.0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: bbswitch (focal-proposed/universe) [0.8-8 => 0.8-8ubuntu0.20.04.1] (no packageset)
<LocutusOfBorg> tjaalton, care to accept virtualbox with the mesa fixes? :)
<tjaalton> later
<LocutusOfBorg> <3
<tjaalton> checking some other first
<LocutusOfBorg> sure, please if you can do the 5.x and 6.x both (bionic/focal)
-queuebot:#ubuntu-release- Unapproved: accepted bbswitch [source] (focal-proposed) [0.8-8ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (focal-proposed) [3.36.2-1ubuntu1~20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [source] (focal-proposed) [2.1.7+ds-2~ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (focal-proposed) [1:1.3.4-2.5ubuntu3.1]
-queuebot:#ubuntu-release- New binary: kcalcore [amd64] (groovy-proposed/universe) [5:5.70.0-1] (kubuntu)
<Laney> anyone know offhand where our britney fork actually performs the copy?
<Laney> want to make sure that I properly disable it when deploying the new one in test mode...
<Laney> ah lp_import() in b1 calls promote-to-release
<Laney> thank you, rubber ducks all
-queuebot:#ubuntu-release- Unapproved: rejected evince [source] (focal-proposed) [3.36.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected wpa [source] (focal-proposed) [2:2.9-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openblas [source] (focal-proposed) [0.3.8+ds-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (focal-proposed) [1:3.36.3-0ubuntu1]
<seb128> rbasak, vorlon, bug #1879087 , would it be accepted if the 'the roaming events should not be too frequent' line was deleted to the description?
<ubot5> bug 1879087 in wpa (Ubuntu Focal) "dbus errors, frequent roaming and unstable connectivity" [High,Incomplete] https://launchpad.net/bugs/1879087
 * rbasak defers to vorlon
<rbasak> (as he made the original request for clarification)
-queuebot:#ubuntu-release- Unapproved: shotwell (focal-proposed/main) [0.30.8-0ubuntu2 => 0.30.10-0ubuntu0.1] (ubuntu-desktop)
<seb128> rbasak, k, np
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (focal-proposed) [3.24.20-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected clamav [source] (bionic-proposed) [0.102.3+dfsg-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-107.108] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-60.54] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-38.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-60.54] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-38.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-38.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-185.215] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-38.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-60.54] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-107.108] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-60.54] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-38.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-38.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-38.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-38.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-107.108]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-60.54]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-60.54]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-107.108]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-60.54]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-60.54]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (eoan-proposed) [2.4.7-1ubuntu2.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (focal-proposed) [2.4.7-1ubuntu2.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (bionic-proposed) [2.4.4-2ubuntu1.4]
-queuebot:#ubuntu-release- New binary: tifffile [s390x] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [ppc64el] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [s390x] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tifffile [armhf] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [s390x] (groovy-proposed/universe) [3.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [arm64] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [ppc64el] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: srt [amd64] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tifffile [amd64] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [ppc64el] (groovy-proposed/universe) [3.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lava [amd64] (groovy-proposed/universe) [2020.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [armhf] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: srt [arm64] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: gmp [i386] (groovy-proposed/main) [2:6.2.0+dfsg-5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: syslog-ng [arm64] (groovy-proposed/universe) [3.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [i386] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: syslog-ng [amd64] (groovy-proposed/universe) [3.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [armhf] (groovy-proposed/universe) [3.27.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tifffile [riscv64] (groovy-proposed/universe) [20200511-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [riscv64] (groovy-proposed/universe) [1.4.1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: syslog-ng [riscv64] (groovy-proposed/universe) [3.27.1-1] (no packageset)
<mwhudson> vorlon: did you see https://code.launchpad.net/~mwhudson/britney/hints-ubuntu/+merge/385327 ?
<vorlon> mwhudson: yeah just hadn't had time to do anything with it yet
<vorlon> mwhudson: also wrt the R transition, did you look into autopkgtest regressions at all?  since I think that's the larger issue than the s390x binaries (which are now removed)
<mwhudson> vorlon: i did not
<vorlon> k
<vorlon> mwhudson: also there are other packages in -proposed that nss-wrapper depends on and have run only the tests for the current release version of nss-wrapper, we should add the -proposed version instead of replacing
<vorlon> also also, this is in the section of the hints file labelled "requires more investigation" :)
<mwhudson> vorlon: add vs replace, i wasn't sure about that
-queuebot:#ubuntu-release- Unapproved: vte2.91 (focal-proposed/main) [0.60.1-1ubuntu1 => 0.60.2-1ubuntu1~20.04] (ubuntu-desktop)
<vorlon> mwhudson: also, alternate solution: https://paste.ubuntu.com/p/FcVJjbC9qw/
<mwhudson> vorlon: actually thinking about the problem??
<vorlon> :)
#ubuntu-release 2020-06-11
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (focal-proposed/main) [3.36.1.1-1ubuntu1 => 3.36.2-1ubuntu1~20.04] (desktop-core)
-queuebot:#ubuntu-release- New binary: coinor-csdp [amd64] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinor-csdp [s390x] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinor-csdp [ppc64el] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [s390x] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: srt [ppc64el] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: php-symfony-polyfill [amd64] (groovy-proposed/universe) [1.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: coinor-csdp [arm64] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [i386] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: coinor-csdp [armhf] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [amd64] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: srt [armhf] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: srt [arm64] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: coinor-csdp [riscv64] (groovy-proposed/universe) [6.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: srt [riscv64] (groovy-proposed/universe) [1.4.1-3] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-185.215]
-queuebot:#ubuntu-release- New: accepted srt [amd64] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [armhf] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [ppc64el] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [s390x] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [arm64] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [i386] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [riscv64] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [arm64] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [riscv64] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [armhf] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [s390x] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [i386] (groovy-proposed) [1.4.1-2]
-queuebot:#ubuntu-release- New: accepted srt [ppc64el] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted srt [amd64] (groovy-proposed) [1.4.1-3]
-queuebot:#ubuntu-release- New: accepted gmp [i386] (groovy-proposed) [2:6.2.0+dfsg-5]
-queuebot:#ubuntu-release- New: accepted php-symfony-polyfill [amd64] (groovy-proposed) [1.17.0-1]
-queuebot:#ubuntu-release- New: accepted gasic [amd64] (groovy-proposed) [0.0.r19-7]
-queuebot:#ubuntu-release- New: accepted lava [amd64] (groovy-proposed) [2020.05-1]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [amd64] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [armhf] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [riscv64] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [arm64] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [s390x] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted coinor-csdp [ppc64el] (groovy-proposed) [6.2.0-2]
-queuebot:#ubuntu-release- New: accepted kcalcore [amd64] (groovy-proposed) [5:5.70.0-1]
-queuebot:#ubuntu-release- New: accepted avahi [amd64] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [armhf] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [ppc64el] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [s390x] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [arm64] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [riscv64] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [i386] (groovy-proposed) [0.8-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [amd64] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [armhf] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [riscv64] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted tifffile [amd64] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted tifffile [armhf] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted tifffile [riscv64] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [arm64] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [s390x] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted tifffile [ppc64el] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [ppc64el] (groovy-proposed) [3.27.1-1]
-queuebot:#ubuntu-release- New: accepted tifffile [s390x] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted tifffile [arm64] (groovy-proposed) [20200511-1]
-queuebot:#ubuntu-release- New: accepted gasic [amd64] (groovy-proposed) [0.0.r19-6]
-queuebot:#ubuntu-release- New: accepted xevil [amd64] (groovy-proposed) [2.02r2-10.1]
-queuebot:#ubuntu-release- New: accepted xevil [armhf] (groovy-proposed) [2.02r2-10.1]
-queuebot:#ubuntu-release- New: accepted xevil [riscv64] (groovy-proposed) [2.02r2-10.1]
-queuebot:#ubuntu-release- New: accepted python-libusb1 [amd64] (groovy-proposed) [1.8-1]
-queuebot:#ubuntu-release- New: accepted xevil [ppc64el] (groovy-proposed) [2.02r2-10.1]
-queuebot:#ubuntu-release- New: accepted xevil [arm64] (groovy-proposed) [2.02r2-10.1]
-queuebot:#ubuntu-release- New: accepted xevil [s390x] (groovy-proposed) [2.02r2-10.1]
<Laney> first rebased britney test run is ongoing now, will see what happens later today
<Laney> https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/log/groovy/2020-06-11/ for the logs
 * apw hands Laney some luck tokens he has been holding on to
<Laney> you can follow my various fails if you look at the old ones :>
<Laney> thanks apw, /me goes down the bookies
<Laney> i'm sure that's what you intended them to be used for
<apw> Laney, makes a lot of sense to me :)b
<rbalint> ubuntu-archive, could someone please remove the lambda-align2 binaries? LP: #18828321
<ubot5> Error: Launchpad bug 18828321 could not be found
<rbalint> LP: #1882832
<ubot5> Launchpad bug 1882832 in lambda-align2 (Ubuntu) "Please remove !amd64 binaries of 2.0.0-2build1 from groovy" [Undecided,New] https://launchpad.net/bugs/1882832
-queuebot:#ubuntu-release- New binary: libwebsockets [s390x] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libwebsockets [ppc64el] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libwebsockets [amd64] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libwebsockets [arm64] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libwebsockets [armhf] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gdal [s390x] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libwebsockets [riscv64] (groovy-proposed/universe) [4.0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gdal [ppc64el] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdal [amd64] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdal [arm64] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdal [armhf] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu4 => 2:2.9-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: evince (focal-proposed/main) [3.36.0-2 => 3.36.5-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gdal [riscv64] (groovy-proposed/universe) [3.1.0+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1025.27] (core, kernel)
-queuebot:#ubuntu-release- New: accepted gdal [amd64] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gdal [armhf] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gdal [riscv64] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libwebsockets [amd64] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New: accepted libwebsockets [armhf] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New: accepted libwebsockets [riscv64] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New: accepted gdal [arm64] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gdal [s390x] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libwebsockets [ppc64el] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New: accepted gdal [ppc64el] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libwebsockets [s390x] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New: accepted libwebsockets [arm64] (groovy-proposed) [4.0.15-2]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1064.67] (no packageset)
<Laney> why are there like 2000 new tests per arch every time I look at /running ð³
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1025.27]
<LocutusOfBorg> Laney, did we already get our daily perl sync? :)
<Laney> heh
<Laney> glibc this time
-queuebot:#ubuntu-release- New binary: openms [s390x] (groovy-proposed/universe) [2.5.0+cleaned1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [i386] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: md4c [i386] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: hfst-ospell [s390x] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: presto [amd64] (groovy-proposed/universe) [0.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-bioccheck [amd64] (groovy-proposed/universe) [1.22.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-tempest [amd64] (groovy-proposed/universe) [16.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fastd [amd64] (groovy-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [amd64] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dexseq [amd64] (groovy-proposed/universe) [1.32.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-goplot [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [amd64] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ipynb [amd64] (groovy-proposed/universe) [0.1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-coarsedatatools [amd64] (groovy-proposed/universe) [0.6-5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: md4c [armhf] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: r-cran-rstatix [amd64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cgreen [arm64] (groovy-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [amd64] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [armhf] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: humanfriendly [amd64] (groovy-proposed/universe) [8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: md4c [s390x] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: cgreen [s390x] (groovy-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [ppc64el] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: hfst-ospell [arm64] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: md4c [arm64] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: md4c [ppc64el] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: md4c [amd64] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [s390x] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [amd64] (groovy-proposed/universe) [2.5.0+cleaned1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cgreen [amd64] (groovy-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [amd64] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [s390x] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [s390x] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-aweek [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [amd64] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [s390x] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [ppc64el] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [arm64] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ipynb [ppc64el] (groovy-proposed/universe) [0.1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [ppc64el] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [armhf] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [armhf] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [arm64] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [ppc64el] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [ppc64el] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [arm64] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: md4c [riscv64] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [armhf] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [armhf] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ipynb [arm64] (groovy-proposed/universe) [0.1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [arm64] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [riscv64] (groovy-proposed/main) [0.5.2-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [riscv64] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cgreen [riscv64] (groovy-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [ppc64el] (groovy-proposed/universe) [2.5.0+cleaned1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-equality [riscv64] (groovy-proposed/universe) [1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vte2.91 (focal-proposed/main) [0.60.1-1ubuntu1 => 0.60.3-0ubuntu1~20.04] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [riscv64] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
<kenvandine> can someone please reject my vte2.91=0.60.2-1ubuntu1~20.04 upload to focal?  I have uploaded a 0.60.3 that supersedes it
-queuebot:#ubuntu-release- New binary: haskell-ipynb [riscv64] (groovy-proposed/universe) [0.1.0.1-1] (no packageset)
<LocutusOfBorg>  libemail-address-xs-perl | 1.04-1build2 | groovy          | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
<LocutusOfBorg>  libemail-address-xs-perl | 1.04-1build2 | groovy-proposed | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
<LocutusOfBorg> does anybody know if this is an issue or not?
<LocutusOfBorg> oh Laney :) I found the irc conversation
-queuebot:#ubuntu-release- Unapproved: ceres-solver (focal-proposed/universe) [1.14.0-4ubuntu1 => 1.14.0-4ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (focal-proposed/universe) [3.36.1-1 => 3.36.2-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: rejected vte2.91 [source] (focal-proposed) [0.60.2-1ubuntu1~20.04]
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (focal-proposed/main) [3.36.2-0ubuntu1 => 3.36.3-0ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: openms [arm64] (groovy-proposed/universe) [2.5.0+cleaned1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: adaptive-wrap [amd64] (groovy-proposed/none) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: droidlysis [amd64] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [amd64] (groovy-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pos-tip [amd64] (groovy-proposed/none) [0.4.6+git20191227-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bashtop [amd64] (groovy-proposed/none) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-client-sessions [amd64] (groovy-proposed/none) [0.8.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-haskell-tab-indent [amd64] (groovy-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aiohttp-proxy [amd64] (groovy-proposed/none) [0.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [amd64] (groovy-proposed/none) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [s390x] (groovy-proposed/none) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libatomicbitvector [amd64] (groovy-proposed/none) [0.0+git20200519.e295358-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [s390x] (groovy-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [amd64] (groovy-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aioinflux [amd64] (groovy-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinx-tabs [amd64] (groovy-proposed/none) [1.1.13+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [arm64] (groovy-proposed/none) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [armhf] (groovy-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [s390x] (groovy-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sublime-music [amd64] (groovy-proposed/none) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cif2cell [amd64] (groovy-proposed/none) [2.0.0a1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pauvre [amd64] (groovy-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ncbi-acc-download [amd64] (groovy-proposed/none) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [armhf] (groovy-proposed/none) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: escapevelocity-java [amd64] (groovy-proposed/none) [0.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [arm64] (groovy-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [armhf] (groovy-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [ppc64el] (groovy-proposed/none) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [arm64] (groovy-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [s390x] (groovy-proposed/none) [0.41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ara [amd64] (groovy-proposed/none) [1.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [ppc64el] (groovy-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New source: cd-boot-images-ppc64el (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New source: cd-boot-images-arm64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [amd64] (groovy-proposed/universe) [0.41-1] (no packageset)
<xnox> ubuntu-archive sorry for the duplicate cd-boot-images-amd64 upload, one of them can be rejected.
-queuebot:#ubuntu-release- Unapproved: hydrogen (focal-proposed/universe) [1.0.0~beta2-0ubuntu1 => 1.0.0~rc1-0ubuntu0.20.04.1] (ubuntustudio)
<xnox> mwhudson:  doko: ^ i've split cd-boot-images into per-arch packages, because that way one can pick which architecture the arch:all package is built on, and thus make them arch:all packages.
<xnox> doko:  when reviewed/accepted, cd-boot-images will be possible to remove.
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [ppc64el] (groovy-proposed/universe) [0.41-1] (no packageset)
<Eickmeyer> tjaalton, vorlon: If either of you have time for a quick SRU on bug 1883151 for hydrogen, that would be wonderful.
<ubot5> bug 1883151 in hydrogen (Ubuntu Focal) "[SRU] Hydrogen Bugfix - Update to 1.0.0-rc1" [Undecided,In progress] https://launchpad.net/bugs/1883151
-queuebot:#ubuntu-release- New binary: libmmap-allocator [riscv64] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [riscv64] (groovy-proposed/universe) [1.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [armhf] (groovy-proposed/universe) [0.41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensmtpd-filter-rspamd [riscv64] (groovy-proposed/universe) [0.1.6-1] (no packageset)
<mwhudson> xnox: ah thanks
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [arm64] (groovy-proposed/universe) [0.41-1] (no packageset)
<xnox> mwhudson:  https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/cd-boot-images/+git/cd-boot-images made a branch too, with recipes setup to build them all into a PPA
<mwhudson> xnox: yeah just found that
<xnox> useful for testing & experimenting, as it's not quite possible to build that source package on arm64/ppc64el
<xnox> anyway, will look into making subiuqity inject scripts to use that later
<xnox> after this debian-cd stuff works
<mwhudson> xnox: we should add pxelinux / grub configs for netbooting?
<mwhudson> (can you use grub for legacy pxe boot?)
#ubuntu-release 2020-06-12
<mwhudson> xnox: heh the branch is now attached to a source package that will soon be deleted
<xnox> mwhudson: it will move, one new ones are up.
<xnox> mwhudson: yeah, I thought to have net-pxe, net-uefi dirs next to it.
<xnox> mwhudson: however net-uefi is mostly about generating micro.iso rather than anything else.
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [riscv64] (groovy-proposed/universe) [0.41-1] (no packageset)
<mwhudson> xnox: yeah, i wrote up docs for uefi-pxe but maybe uefi-http is the better choice
-queuebot:#ubuntu-release- New binary: assembly-stats [amd64] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [ppc64el] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [s390x] (groovy-proposed/universe) [0.4.0+git20200122.adbfbe1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [s390x] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [arm64] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pauvre [amd64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: assembly-stats [armhf] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libatomicbitvector [amd64] (groovy-proposed/universe) [0.0+git20200519.e295358-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [arm64] (groovy-proposed/universe) [0.4.0+git20200122.adbfbe1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ncbi-acc-download [amd64] (groovy-proposed/universe) [0.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-aweek [amd64] (groovy-proposed/universe) [1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [amd64] (groovy-proposed/universe) [0.4.0+git20200122.adbfbe1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: presto [amd64] (groovy-proposed/universe) [0.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [armhf] (groovy-proposed/universe) [0.4.0+git20200122.adbfbe1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-coarsedatatools [amd64] (groovy-proposed/universe) [0.6-5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dexseq [amd64] (groovy-proposed/universe) [1.34.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-base [s390x] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnustep-base [ppc64el] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: assembly-stats [riscv64] (groovy-proposed/universe) [1.0.1+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmmap-allocator [riscv64] (groovy-proposed/universe) [0.4.0+git20200122.adbfbe1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-base [amd64] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnustep-base [armhf] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnustep-base [arm64] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libclc (focal-proposed/universe) [0.2.0+git20190827-4 => 0.2.0+git20190827-4ubuntu0.1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [20.0.4-2ubuntu1 => 20.0.8-0ubuntu1~20.04.1] (core, i386-whitelist, xorg)
-queuebot:#ubuntu-release- Unapproved: evolution (focal-proposed/universe) [3.36.2-0ubuntu1 => 3.36.3-0ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [amd64] (groovy-proposed) [0.4.0+git20200122.adbfbe1-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [armhf] (groovy-proposed) [0.4.0+git20200122.adbfbe1-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [s390x] (groovy-proposed) [0.4.0+git20200122.adbfbe1-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [armhf] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [s390x] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [arm64] (groovy-proposed) [0.4.0+git20200122.adbfbe1-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [amd64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [riscv64] (groovy-proposed) [0.4.0+git20200122.adbfbe1-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [riscv64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libatomicbitvector [amd64] (groovy-proposed) [0.0+git20200519.e295358-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [amd64] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [armhf] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [riscv64] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New: accepted libmmap-allocator [arm64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libatomicbitvector [amd64] (groovy-proposed) [0.0+git20200519.e295358-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [ppc64el] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New binary: haskell-show-combinators [ppc64el] (groovy-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [arm64] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [s390x] (groovy-proposed) [0.41-1]
-queuebot:#ubuntu-release- New: accepted escapevelocity-java [amd64] (groovy-proposed) [0.9.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [amd64] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [armhf] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [riscv64] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [arm64] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [s390x] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-show-combinators [ppc64el] (groovy-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [amd64] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [armhf] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [riscv64] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [arm64] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [ppc64el] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [arm64] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [s390x] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [s390x] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-equality [ppc64el] (groovy-proposed) [1-2]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [i386] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [amd64] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [riscv64] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted presto [amd64] (groovy-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted r-cran-aweek [amd64] (groovy-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New binary: humanfriendly [amd64] (groovy-proposed/universe) [8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: md4c [s390x] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New: accepted hfst-ospell [armhf] (groovy-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dexseq [amd64] (groovy-proposed) [1.34.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: md4c [armhf] (groovy-proposed/universe) [0.4.4-1] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New: accepted ncbi-acc-download [amd64] (groovy-proposed) [0.2.6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-coarsedatatools [amd64] (groovy-proposed) [0.6-5-2]
-queuebot:#ubuntu-release- New: accepted assembly-stats [amd64] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [armhf] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [riscv64] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [amd64] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New: accepted assembly-stats [armhf] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New: accepted assembly-stats [riscv64] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New: accepted python-ara [amd64] (groovy-proposed) [1.3.2-1]
-queuebot:#ubuntu-release- New binary: haskell-ipynb [amd64] (groovy-proposed/universe) [0.1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted assembly-stats [arm64] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [s390x] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [ppc64el] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New: accepted python-pauvre [amd64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [ppc64el] (groovy-proposed) [1.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted assembly-stats [s390x] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New: accepted assembly-stats [arm64] (groovy-proposed) [1.0.1+ds-2]
-queuebot:#ubuntu-release- New binary: r-cran-tmvnsim [amd64] (groovy-proposed/universe) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted adaptive-wrap [amd64] (groovy-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted cif2cell [amd64] (groovy-proposed) [2.0.0a1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted emacs-haskell-tab-indent [amd64] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted pos-tip [amd64] (groovy-proposed) [0.4.6+git20191227-1]
-queuebot:#ubuntu-release- New: accepted python-pauvre [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted bashtop [amd64] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted node-client-sessions [amd64] (groovy-proposed) [0.8.0-2]
-queuebot:#ubuntu-release- New: accepted sphinx-tabs [amd64] (groovy-proposed) [1.1.13+ds-1]
-queuebot:#ubuntu-release- New: accepted droidlysis [amd64] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New binary: rustc [s390x] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted python-aiohttp-proxy [amd64] (groovy-proposed) [0.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ncbi-acc-download [amd64] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted sublime-music [amd64] (groovy-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-aioinflux [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-bioccheck [amd64] (groovy-proposed) [1.22.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-aweek [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-goplot [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [amd64] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [armhf] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [riscv64] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dexseq [amd64] (groovy-proposed) [1.32.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rstatix [amd64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [ppc64el] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-coarsedatatools [amd64] (groovy-proposed) [0.6-5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [s390x] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvnsim [arm64] (groovy-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted fastd [amd64] (groovy-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted presto [amd64] (groovy-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted humanfriendly [amd64] (groovy-proposed) [8.2-2]
-queuebot:#ubuntu-release- New: accepted puppet-module-tempest [amd64] (groovy-proposed) [16.3.0-2]
-queuebot:#ubuntu-release- New: accepted md4c [amd64] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [armhf] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [ppc64el] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [s390x] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [arm64] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [riscv64] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted md4c [i386] (groovy-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted cgreen [amd64] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted cgreen [riscv64] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted cgreen [arm64] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted cgreen [s390x] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [amd64] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [armhf] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [riscv64] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [arm64] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [s390x] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted opensmtpd-filter-rspamd [ppc64el] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New binary: r-cran-incidence [amd64] (groovy-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1064.67]
-queuebot:#ubuntu-release- Unapproved: postfix (focal-proposed/main) [3.4.10-1ubuntu1 => 3.4.11-0ubuntu1] (core)
<ackk> ubuntu-archive: hi, could someone please take a look at this RM: https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1882949 ? should hopefully be trivial
<ubot5> Ubuntu bug 1882949 in django-piston3 (Ubuntu) "RM: remove django-piston3 / python3-django-piston3 from archive" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: evolution-ews (focal-proposed/universe) [3.36.2-0ubuntu1 => 3.36.3-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1016.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1078.88] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1046.50] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1027.29] (core, kernel)
<LocutusOfBorg> hello, is any archive-admin caring about https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1883260 ?
<ubot5> Ubuntu bug 1883260 in mongodb (Ubuntu) "remove mongodb from groovy" [Undecided,New]
<apw> LocutusOfBorg, it looks to be having its reverse-depends fixed on the linked duplcate
-queuebot:#ubuntu-release- New binary: openms [riscv64] (groovy-proposed/universe) [2.5.0+cleaned1-2] (no packageset)
<ackk> apw, hi I also have an RM request at https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1882949. can that be processed?
<ubot5> Ubuntu bug 1882949 in django-piston3 (Ubuntu) "RM: remove django-piston3 / python3-django-piston3 from archive" [Undecided,New]
-queuebot:#ubuntu-release- Packageset: Added jackd2 to ubuntustudio in bionic
-queuebot:#ubuntu-release- Packageset: Added jackd2 to ubuntustudio in eoan
-queuebot:#ubuntu-release- Packageset: Added jackd2 to ubuntustudio in focal
-queuebot:#ubuntu-release- Packageset: Added jackd2 to ubuntustudio in xenial
-queuebot:#ubuntu-release- Packageset: Added jackd2 to ubuntustudio in groovy
<kyrofa> Hey tjaalton, we're a bit blocked on this SRU, any chance you could take a look today? https://bugs.launchpad.net/ubuntu/+source/ceres-solver/+bug/1882626
<ubot5> Ubuntu bug 1882626 in ceres-solver (Ubuntu Focal) "libceres-dev Focal arm64 build failing with failed test" [High,In progress]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1025.27~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ceres-solver [source] (focal-proposed) [1.14.0-4ubuntu1.1]
-queuebot:#ubuntu-release- New binary: gztool [s390x] (groovy-proposed/none) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [s390x] (groovy-proposed/none) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [s390x] (groovy-proposed/none) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [s390x] (groovy-proposed/none) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [s390x] (groovy-proposed/none) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-kusto-python [amd64] (groovy-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [amd64] (groovy-proposed/none) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ggtags [amd64] (groovy-proposed/none) [0.8.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: atomic-chrome-el [amd64] (groovy-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [s390x] (groovy-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libips4o [amd64] (groovy-proposed/none) [0.0+git20190618.2206938-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmetrics-any-perl [amd64] (groovy-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmu-tiny-perl [amd64] (groovy-proposed/universe) [0.000002-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [arm64] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [amd64] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-arthurhoaro-web-thumbnailer [amd64] (groovy-proposed/universe) [2.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [amd64] (groovy-proposed/universe) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-core [amd64] (groovy-proposed/universe) [2.31.10+debian0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [amd64] (groovy-proposed/universe) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-cephes-perl [amd64] (groovy-proposed/universe) [0.5305-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [arm64] (groovy-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-nanomath [amd64] (groovy-proposed/universe) [0.23.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [armhf] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [armhf] (groovy-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [amd64] (groovy-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsort-maker-perl [amd64] (groovy-proposed/universe) [0.06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [ppc64el] (groovy-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [ppc64el] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-parser-perl [amd64] (groovy-proposed/universe) [1.63-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [riscv64] (groovy-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtest-json-schema-acceptance-perl [amd64] (groovy-proposed/universe) [0.990+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-matrixreal-perl [amd64] (groovy-proposed/universe) [2.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [armhf] (groovy-proposed/universe) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [ppc64el] (groovy-proposed/universe) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [riscv64] (groovy-proposed/universe) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [armhf] (groovy-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [riscv64] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [riscv64] (groovy-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pprintpp [amd64] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [armhf] (groovy-proposed/universe) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtest-sharedobject-perl [amd64] (groovy-proposed/universe) [0.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [arm64] (groovy-proposed/universe) [2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [riscv64] (groovy-proposed/universe) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [amd64] (groovy-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [arm64] (groovy-proposed/universe) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-cephes-perl [riscv64] (groovy-proposed/universe) [0.5305-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-cephes-perl [arm64] (groovy-proposed/universe) [0.5305-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [arm64] (groovy-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [ppc64el] (groovy-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [amd64] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [ppc64el] (groovy-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-mat-dumper-perl [ppc64el] (groovy-proposed/universe) [0.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-cephes-perl [armhf] (groovy-proposed/universe) [0.5305-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-cephes-perl [ppc64el] (groovy-proposed/universe) [0.5305-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [s390x] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [arm64] (groovy-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [armhf] (groovy-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [ppc64el] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [armhf] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [arm64] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: qiskit-terra [riscv64] (groovy-proposed/universe) [0.12.0-1] (no packageset)
<Eickmeyer> tjaalton, vorlon: I have two SRUs if either of you can spare a couple cycles:
<Eickmeyer> bug 1883151
<ubot5> bug 1883151 in hydrogen (Ubuntu Focal) "[SRU] Hydrogen Bugfix - Update to 1.0.0-rc1" [High,In progress] https://launchpad.net/bugs/1883151
<Eickmeyer> 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
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1016.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1027.29]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1078.88]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1046.50]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1025.27~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (focal-proposed) [440.82-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1016.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: libtorrent-rasterbar [riscv64] (groovy-proposed/universe) [1.2.5-1.1] (no packageset)
<LocutusOfBorg> archive admins, please
<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> vorlon, ^^ :)
<LocutusOfBorg> NBS-proposed cleanup
-queuebot:#ubuntu-release- Unapproved: ccls (focal-proposed/universe) [0.20190823.5-1 => 0.20190823.6-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [amd64] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [ppc64el] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [s390x] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [arm64] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [armhf] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-base [riscv64] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected hydrogen [source] (focal-proposed) [1.0.0~rc1-0ubuntu0.20.04.1]
<tjaalton> Eickmeyer: your hydrogen upload didn't mention the sru bug
<Eickmeyer> tjaalton: It didn't? I could've sworn it did. Oh well, feel free to reject, I'll try again.
<tjaalton> rejected already
<Eickmeyer> Hehe, just saw that. :)
-queuebot:#ubuntu-release- Unapproved: hydrogen (focal-proposed/universe) [1.0.0~beta2-0ubuntu1 => 1.0.0~rc1-0ubuntu0.20.04.1] (ubuntustudio)
<Eickmeyer> tjaalton: Take two? ^
-queuebot:#ubuntu-release- New binary: haskell-edit-distance-vector [riscv64] (groovy-proposed/universe) [1.0.0.4-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hydrogen [source] (focal-proposed) [1.0.0~rc1-0ubuntu0.20.04.1]
<tjaalton> Eickmeyer: accepted, had to add the verification-needed tag manually..
<tjaalton> and I don't see r-p-d on the queue
<tjaalton> anyway, I'm about to crash
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (focal-proposed) [1.64.3-1~ubuntu20.04.1]
<vorlon> Laney: do you know anything about the 'testinfo.json not found' emails coming through from autopkgtest? I'm not familiar with that area of the code
-queuebot:#ubuntu-release- New binary: haskell-generic-lens [riscv64] (groovy-proposed/universe) [1.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted memcached [source] (focal-proposed) [1.5.22-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: gztool [amd64] (groovy-proposed/universe) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [armhf] (groovy-proposed/universe) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [amd64] (groovy-proposed/universe) [0.006-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-nanomath [amd64] (groovy-proposed/universe) [0.23.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [arm64] (groovy-proposed/universe) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libips4o [amd64] (groovy-proposed/universe) [0.0+git20190618.2206938-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [s390x] (groovy-proposed/universe) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [amd64] (groovy-proposed/universe) [2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: google-auto-common-java [amd64] (groovy-proposed/none) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [s390x] (groovy-proposed/universe) [0.006-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [arm64] (groovy-proposed/universe) [0.006-2] (no packageset)
-queuebot:#ubuntu-release- New binary: google-http-client-java [amd64] (groovy-proposed/universe) [1.27.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [s390x] (groovy-proposed/universe) [2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wiipdf [arm64] (groovy-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: wiipdf [s390x] (groovy-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [armhf] (groovy-proposed/universe) [0.006-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wiipdf [armhf] (groovy-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: wiipdf [amd64] (groovy-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.14 [source] (focal-proposed) [1.14.3-2ubuntu2~20.04.1]
-queuebot:#ubuntu-release- New binary: quicktree [arm64] (groovy-proposed/universe) [2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [armhf] (groovy-proposed/universe) [2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wiipdf [riscv64] (groovy-proposed/universe) [1.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: quicktree [riscv64] (groovy-proposed/universe) [2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gztool [riscv64] (groovy-proposed/universe) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libarray-base-perl [riscv64] (groovy-proposed/universe) [0.006-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gztool [riscv64] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted quicktree [riscv64] (groovy-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [riscv64] (groovy-proposed) [0.006-2]
-queuebot:#ubuntu-release- New: accepted google-auto-common-java [amd64] (groovy-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gztool [amd64] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted gztool [armhf] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [armhf] (groovy-proposed) [0.006-2]
-queuebot:#ubuntu-release- New: accepted python-nanomath [amd64] (groovy-proposed) [0.23.2-1]
-queuebot:#ubuntu-release- New: accepted quicktree [arm64] (groovy-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted quicktree [s390x] (groovy-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted wiipdf [arm64] (groovy-proposed) [1.4-3]
-queuebot:#ubuntu-release- New: accepted wiipdf [riscv64] (groovy-proposed) [1.4-3]
-queuebot:#ubuntu-release- New binary: atomic-chrome-el [amd64] (groovy-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted google-http-client-java [amd64] (groovy-proposed) [1.27.0-1]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [arm64] (groovy-proposed) [0.006-2]
-queuebot:#ubuntu-release- New: accepted quicktree [amd64] (groovy-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted wiipdf [amd64] (groovy-proposed) [1.4-3]
-queuebot:#ubuntu-release- New: accepted wiipdf [s390x] (groovy-proposed) [1.4-3]
-queuebot:#ubuntu-release- New binary: libmetrics-any-perl [amd64] (groovy-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [amd64] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-arthurhoaro-web-thumbnailer [amd64] (groovy-proposed/universe) [2.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gztool [arm64] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted quicktree [armhf] (groovy-proposed) [2.5-2]
-queuebot:#ubuntu-release- New binary: libips4o [amd64] (groovy-proposed/universe) [0.0+git20190618.2206938-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-encode-xs-perl [arm64] (groovy-proposed/universe) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [s390x] (groovy-proposed) [0.006-2]
-queuebot:#ubuntu-release- New binary: libmu-tiny-perl [amd64] (groovy-proposed/universe) [0.000002-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wiipdf [armhf] (groovy-proposed) [1.4-3]
-queuebot:#ubuntu-release- New binary: qiskit-terra [s390x] (groovy-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnustep-base [riscv64] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [riscv64] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [arm64] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [ppc64el] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [s390x] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [ppc64el] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [ppc64el] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted libmath-cephes-perl [armhf] (groovy-proposed) [0.5305-1]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [amd64] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [armhf] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New: accepted gztool [s390x] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [armhf] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [arm64] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libips4o [amd64] (groovy-proposed) [0.0+git20190618.2206938-2]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [arm64] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [riscv64] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New: accepted qiskit-terra [arm64] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted qiskit-terra [riscv64] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New source: cd-boot-images-ppc64el (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [amd64] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [amd64] (groovy-proposed) [0.006-2]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [ppc64el] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New: accepted qiskit-terra [armhf] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New source: cd-boot-images-arm64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New binary: gnustep-base [arm64] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnustep-base [ppc64el] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens [riscv64] (groovy-proposed) [1.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libtorrent-rasterbar [s390x] (groovy-proposed) [1.2.5-1.1]
-queuebot:#ubuntu-release- New binary: gnustep-base [amd64] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnustep-base [s390x] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libmath-cephes-perl [ppc64el] (groovy-proposed) [0.5305-1]
-queuebot:#ubuntu-release- New binary: gnustep-base [armhf] (groovy-proposed/universe) [1.27.0-3] (kubuntu)
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [3]
-queuebot:#ubuntu-release- New: accepted gztool [riscv64] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [riscv64] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [armhf] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted libmath-cephes-perl [arm64] (groovy-proposed) [0.5305-1]
-queuebot:#ubuntu-release- New: accepted libmath-matrixreal-perl [amd64] (groovy-proposed) [2.13-1]
-queuebot:#ubuntu-release- New: accepted libtest-json-schema-acceptance-perl [amd64] (groovy-proposed) [0.990+ds-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [ppc64el] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted pprintpp [amd64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted qiskit-terra [ppc64el] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted quicktree [armhf] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [armhf] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [riscv64] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted libsort-maker-perl [amd64] (groovy-proposed) [0.06-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [riscv64] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted quicktree [arm64] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New: accepted quicktree [riscv64] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New binary: rustc [arm64] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [i386] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [arm64] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted libtest-sharedobject-perl [amd64] (groovy-proposed) [0.01-1]
-queuebot:#ubuntu-release- New: accepted quicktree [ppc64el] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New binary: rustc [armhf] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted libmath-cephes-perl [riscv64] (groovy-proposed) [0.5305-1]
-queuebot:#ubuntu-release- New binary: rustc [amd64] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted qiskit-terra [amd64] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted gztool [arm64] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted gztool [ppc64el] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libmath-cephes-perl [amd64] (groovy-proposed) [0.5305-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [armhf] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted gztool [armhf] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libpod-parser-perl [amd64] (groovy-proposed) [1.63-1]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [amd64] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted python-nanomath [amd64] (groovy-proposed) [0.23.1-1]
-queuebot:#ubuntu-release- New binary: gztool [ppc64el] (groovy-proposed/universe) [0.11.2-2] (no packageset)
#ubuntu-release 2020-06-13
-queuebot:#ubuntu-release- New binary: openms [amd64] (groovy-proposed/universe) [2.5.0+cleaned1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [s390x] (groovy-proposed/universe) [2.5.0+cleaned1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: google-auto-service-java [amd64] (groovy-proposed/universe) [1.0~rc7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libautobox-transform-perl [amd64] (groovy-proposed/universe) [1.034-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libanyevent-forkmanager-perl [amd64] (groovy-proposed/universe) [0.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-nanoget [amd64] (groovy-proposed/universe) [1.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [amd64] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [s390x] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [ppc64el] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [arm64] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [armhf] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-diff [riscv64] (groovy-proposed/universe) [1.1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-data [riscv64] (groovy-proposed/universe) [0.7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [ppc64el] (groovy-proposed/universe) [2.5.0+cleaned1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ggtags [amd64] (groovy-proposed/universe) [0.8.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: google-auth-java [amd64] (groovy-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmetrics-any-perl [amd64] (groovy-proposed/universe) [0.05-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libautobox-transform-perl [amd64] (groovy-proposed/universe) [1.034-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmu-tiny-perl [amd64] (groovy-proposed/universe) [0.000002-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [arm64] (groovy-proposed/universe) [2.5.0+cleaned1-3] (no packageset)
<Laney> vorlon: I stopped those happening by manually deleting that submission from swift, but I think we should be failing if testinfo.json doesn't exist, at least for upstream git requests where the web side needs this file to match up requests with results
<Laney> failing -> retrying
-queuebot:#ubuntu-release- New binary: libanyevent-forkmanager-perl [amd64] (groovy-proposed/universe) [0.07-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1016.16]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1078.88~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1046.50~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-107.108~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1078.88~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1046.50~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-107.108~16.04.1]
-queuebot:#ubuntu-release- New binary: mumps [amd64] (groovy-proposed/universe) [5.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [s390x] (groovy-proposed/universe) [5.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [ppc64el] (groovy-proposed/universe) [5.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1060.65] (no packageset)
-queuebot:#ubuntu-release- New: accepted libanyevent-forkmanager-perl [amd64] (groovy-proposed) [0.07-2]
-queuebot:#ubuntu-release- New: accepted mumps [ppc64el] (groovy-proposed) [5.3.1-3]
-queuebot:#ubuntu-release- New: accepted mumps [amd64] (groovy-proposed) [5.3.1-3]
-queuebot:#ubuntu-release- New: accepted mumps [s390x] (groovy-proposed) [5.3.1-3]
-queuebot:#ubuntu-release- New: accepted ggtags [amd64] (groovy-proposed) [0.8.13-2]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-diff [riscv64] (groovy-proposed) [1.1.0.8-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [arm64] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [riscv64] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted libmetrics-any-perl [amd64] (groovy-proposed) [0.05-2]
-queuebot:#ubuntu-release- New: accepted openms [arm64] (groovy-proposed) [2.5.0+cleaned1-3]
-queuebot:#ubuntu-release- New: accepted google-auth-java [amd64] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [armhf] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted libmu-tiny-perl [amd64] (groovy-proposed) [0.000002-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [amd64] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted openms [ppc64el] (groovy-proposed) [2.5.0+cleaned1-3]
-queuebot:#ubuntu-release- New: accepted libautobox-transform-perl [amd64] (groovy-proposed) [1.034-2]
-queuebot:#ubuntu-release- New: accepted google-auto-service-java [amd64] (groovy-proposed) [1.0~rc7-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [ppc64el] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted libanyevent-forkmanager-perl [amd64] (groovy-proposed) [0.07-1]
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [amd64] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted openms [s390x] (groovy-proposed) [2.5.0+cleaned1-3]
-queuebot:#ubuntu-release- New: accepted gztool [ppc64el] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted libautobox-transform-perl [amd64] (groovy-proposed) [1.034-1]
-queuebot:#ubuntu-release- New: accepted python-nanoget [amd64] (groovy-proposed) [1.12.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-data [s390x] (groovy-proposed) [0.7.0.0-2]
-queuebot:#ubuntu-release- New: accepted openms [amd64] (groovy-proposed) [2.5.0+cleaned1-3]
-queuebot:#ubuntu-release- New: accepted atomic-chrome-el [amd64] (groovy-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libmetrics-any-perl [amd64] (groovy-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [amd64] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted php-arthurhoaro-web-thumbnailer [amd64] (groovy-proposed) [2.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted quicktree [amd64] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New: accepted libips4o [amd64] (groovy-proposed) [0.0+git20190618.2206938-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [arm64] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted libmu-tiny-perl [amd64] (groovy-proposed) [0.000002-1]
-queuebot:#ubuntu-release- New: accepted php-horde-core [amd64] (groovy-proposed) [2.31.10+debian0-4]
-queuebot:#ubuntu-release- New: accepted azure-kusto-python [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted gztool [amd64] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libarray-base-perl [s390x] (groovy-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted liburl-encode-xs-perl [s390x] (groovy-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted quicktree [s390x] (groovy-proposed) [2.5-1]
-queuebot:#ubuntu-release- New: accepted ggtags [amd64] (groovy-proposed) [0.8.13-1]
-queuebot:#ubuntu-release- New: accepted libdevel-mat-dumper-perl [s390x] (groovy-proposed) [0.42-1]
-queuebot:#ubuntu-release- New: accepted gztool [s390x] (groovy-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted qiskit-terra [s390x] (groovy-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted gnustep-base [amd64] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted gnustep-base [armhf] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted gnustep-base [s390x] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted openms [arm64] (groovy-proposed) [2.5.0+cleaned1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-incidence [amd64] (groovy-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted gnustep-base [arm64] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-ipynb [riscv64] (groovy-proposed) [0.1.0.1-1]
-queuebot:#ubuntu-release- New: accepted gnustep-base [ppc64el] (groovy-proposed) [1.27.0-3]
-queuebot:#ubuntu-release- New: accepted openms [riscv64] (groovy-proposed) [2.5.0+cleaned1-2]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [amd64] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [armhf] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [s390x] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-ipynb [arm64] (groovy-proposed) [0.1.0.1-1]
-queuebot:#ubuntu-release- New: accepted openms [amd64] (groovy-proposed) [2.5.0+cleaned1-2]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [arm64] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-ipynb [amd64] (groovy-proposed) [0.1.0.1-1]
-queuebot:#ubuntu-release- New: accepted openms [ppc64el] (groovy-proposed) [2.5.0+cleaned1-2]
-queuebot:#ubuntu-release- New: accepted haskell-edit-distance-vector [ppc64el] (groovy-proposed) [1.0.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-ipynb [ppc64el] (groovy-proposed) [0.1.0.1-1]
-queuebot:#ubuntu-release- New: accepted openms [s390x] (groovy-proposed) [2.5.0+cleaned1-2]
-queuebot:#ubuntu-release- New binary: libtest-metrics-any-perl [amd64] (groovy-proposed/universe) [0.01-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-gui [s390x] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: r-cran-epiestim [amd64] (groovy-proposed/universe) [2.2-3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtest-dbic-expectedqueries-perl [amd64] (groovy-proposed/universe) [2.002-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-gui [amd64] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: google-auto-value-java [amd64] (groovy-proposed/universe) [1.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-gui [ppc64el] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: haskell-aeson-diff [amd64] (groovy-proposed/universe) [1.1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnustep-gui [arm64] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gnustep-gui [armhf] (groovy-proposed/universe) [0.28.0-2] (ubuntustudio)
#ubuntu-release 2020-06-14
-queuebot:#ubuntu-release- Packageset: Added libfprint to ubuntu-desktop in bionic
-queuebot:#ubuntu-release- Packageset: Added libfprint to ubuntu-desktop in eoan
-queuebot:#ubuntu-release- Packageset: Added libfprint to ubuntu-desktop in focal
-queuebot:#ubuntu-release- Packageset: Added libfprint to ubuntu-desktop in groovy
-queuebot:#ubuntu-release- New binary: gnome-pass-search-provider [amd64] (groovy-proposed/universe) [0.0~20191115+da2db41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-suapapa-go-eddystone [amd64] (groovy-proposed/universe) [0.0~git20190827.8d8c1bb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-joyent-gosdc [amd64] (groovy-proposed/universe) [0.0~git20161202.ec8b350-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [amd64] (groovy-proposed/universe) [1:3.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [s390x] (groovy-proposed/universe) [1:3.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [ppc64el] (groovy-proposed/universe) [1:3.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [arm64] (groovy-proposed/universe) [1:3.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [armhf] (groovy-proposed/universe) [1:3.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mailutils [riscv64] (groovy-proposed/universe) [1:3.9-2] (no packageset)
<ginggs> hi, 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
<LocutusOfBorg> hello vorlon I'm trying to figure out why php7.4 and perl are not installable on i386, but I failed so far... php-symfony-polyfill and libemail-address-xs-perl are failing on i386 but I don't see any solution to the problem
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1060.65]
-queuebot:#ubuntu-release- New binary: mp3check [s390x] (groovy-proposed/none) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mp3check [amd64] (groovy-proposed/none) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mp3check [ppc64el] (groovy-proposed/none) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mp3check [arm64] (groovy-proposed/universe) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mp3check [armhf] (groovy-proposed/universe) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mp3check [riscv64] (groovy-proposed/universe) [0.8.7-3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (focal-backports/universe) [218-1~ubuntu20.04.1 => 221-1~ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (focal-backports) [221-1~ubuntu20.04.1]
<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
-queuebot:#ubuntu-release- New binary: dlpack [amd64] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dlpack [s390x] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dlpack [arm64] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dlpack [armhf] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dlpack [ppc64el] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dlpack [riscv64] (groovy-proposed/universe) [0.0~git20200217.3ec0443-2] (no packageset)
