#ubuntu-release 2011-01-03
<skaet> Happy new year!
<skaet> Not sure if we'll have quorum for an SRU/LTS meeting today, but there's an agenda posted https://wiki.ubuntu.com/ReleaseTeam/Meeting/StableReleaseAgenda
<skaet> will be heading over to #ubuntu-meeting in 20 minutes.
<ScottK> skaet: Just took a glance at the SRU meeting backscroll.  KDE SC 4.4.5 is pending in lucid-proposed.  The bug was just marked verification done, so it should make 1/27 with no problem.  That's the one big thing I know of that's pending for 10.04.2.
<skaet> ScottK, thanks for the update!  good to know.  :)
<doko> cjwatson: I messed something up ...
<doko> $ sync-source.py -S incoming -b doko -c main ppl0.10
<doko> Getting binaries for natty...
<doko> [Updating] ppl0.10 (None [Ubuntu] < 0.10.2-10 [Debian])
<doko>  * Trying to add ppl0.10...
<doko> 2011-01-03 21:37:42 INFO      - <ppl0.10_0.10.2.orig.tar.gz: cached>
<doko> 2011-01-03 21:37:42 INFO      - <ppl0.10_0.10.2-10.debian.tar.gz: cached>
<doko> 2011-01-03 21:37:42 INFO      - <ppl0.10_0.10.2-10.dsc: cached>
<doko> E: libppl7 is in main but its source (ppl0.10) is not.
<doko> nevermind, now uploaded manually
#ubuntu-release 2011-01-04
<ScottK> cjwatson: Could we start building http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/current/ again (which subvariant doesn't matter much as the kernel we're using for development isn't in the archive yet, but it's an omap3 variant, so linaro omap would probably be best if it's not difficult)?
<cjwatson> ScottK: it's still building - http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/current/
<cjwatson> guess I need some more redirects
<cjwatson> omap3 is failing to build for some reason I don't know
<ScottK> cjwatson: OK.  Thanks.
<cjwatson> I'll remove the old maverick daily builds there, as they correspond to released images
<ScottK> Thanks.
<ScottK> I've fixed the wiki page that pointed at the old location.
<ScottK> cjwatson: Are you supporting btrfs in the installer yet?
<cjwatson> it's been supported for a while
<cjwatson> you currently need a non-btrfs /boot
<cjwatson> this will likely change over the next week
<cjwatson> (redirects in place now)
<ScottK> Great.
<ScottK> Would it be possible to switch the kubuntu-mobile image on arm to default to btrfs once you have those changes in place?
<cjwatson> oh, the non-btrfs /boot bit is irrelevant on arm, it's a grub limitation right now
<ScottK> Ah.
<cjwatson> do you have a boot loader that can cope?
<ScottK> Let me drag someone in hear rather than play middle man.
<cjwatson> #u-installer maybe
<ScottK> OK
<ScottK> cjwatson: We've got a reasonably good chance at pulling together a fully FOSS system for n900 in this cycle.  I think all the needed bits exist now, it's mostly integration work to do.  It'll be a tech preview grade still, but should be at least somewhat useable.
<cjwatson> nifty
<cjwatson> I think I might leave mine at stock for a while yet though :)
<ScottK> I don't blame you.
<ScottK> Mine was donated to the cause so the person doing the kernel work would have hardware.
<ScottK> (my cel provider doesn't use GSM, so it was only of limited use to me)
<ScottK> cjwatson: Would you mind retrying kubuntu-mobile/omap?  http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-mobile/natty/daily-preinstalled-20110104.log looks like it was just a transient issue.
<cjwatson> it's been happening every day for weeks
<cjwatson> I don't know what the problem is - I think lamont probably needs to investigate on the livefs buildd
<ScottK> Oh.
<ScottK> OK.
<cjwatson> it's not kubuntu-mobile-specific - it's happening on all omap images.  I get a zero-byte build log
<ScottK> Clearly nevermind on the request then
<lamont> cjwatson: ew
<lamont> cjwatson: I also notice that acorn hasn't been getting used for any natty builds
<bdmurray> I'm deactivating ubuntu-10.04.1 as a milestone
<skaet> bdmurray,  thanks!   Have gone in and added it to the PointReleaseProcess to make it explicit.
#ubuntu-release 2012-01-03
<doko> please could somebody promote llvm-3.0? just the new upstream version, will only keep on llvm version for precise
<doko> needed for openjdk-6
<cjwatson> doko: done
<doko> thanks
#ubuntu-release 2012-01-04
<AlanBell> with the free CDs thing that we have been doing that has been very carefully targetted at the uk http://ubuntu-uk.org/free-cds/
<AlanBell> oops, sorry
#ubuntu-release 2012-01-05
<stgraber> good morning
<stgraber> can I get a rebuild of Edubuntu?
<stgraber> today's daily failed because of some langpacks, trying to upgrade yesterday's livefs works fine now so I'd think a rebuild should now work too
<brendand> Daviey - ping
<Daviey> brendand: hey!
<brendand> Daviey - at the release meeting a few weeks ago you asked to be kept on top of server issues in certification, yeah?
<Daviey> brendand: yes.. :)
<brendand> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/907377
<ubot4> Launchpad bug 907377 in linux (Ubuntu) (and 1 other project) "HP ProLiant DL360 G6 has debootstrap errors during install of Precise Alpha 1 (affects: 1) (heat: 10)" [High,Triaged]
<brendand> fyi
<Daviey> I trustyou have good news? :)
<brendand> i like a man who sees problems as good news :)
 * Daviey mutters.
<Daviey> brendand: thanks for letting me know, tagging it for watching :)
<stgraber> pitti, cjwatson: Can one of you trigger an Edubuntu rebuild?
<brendand> it's a bit of a strange one because it looks like a funky hard disk from the logs, but it's 100% reproducible only in Precise and not in Oneiric
<brendand> so maybe drivers
<cjwatson> stgraber: I was just going through my list of build failures
<cjwatson> brendand: not d-i, at least - I'll close that task
<Daviey> brendand: do we know when precise broke for this exactly, or just happend to notice at some point?
<pitti> today's failures mostly seemed like buildd lag due to langpacks and gtk?
<cjwatson> pitti: yes, I think so.  I'll process them
<brendand> cjwatson - no problem
<brendand> Daviey - Alpha1 was the first time we tested
 * Daviey raises his pipedream of a snapshot archive again.
 * brendand +1
<brendand> i wantz to go back in time. kthxbai
<cjwatson> with reduced LP development, you'll be lucky
<pitti> LP still has all the .debs
<pitti> so in theeeeory you could download them all and run apt-ftparchive, but that'll take quite some time
<Daviey> pitti: right, fancy writing an archive proxy.py for it? :)
<pitti> not at this time :)
<pitti> in most cases I jsut want to downgrade a package or two
<Daviey> the pool is easy, it's the indexing which is harder.
<pitti> very nice for trying a previous kernel or library
<pitti> Daviey: apt-ftparchive packages . | gzip -9 > Packages.gz is simple
<pitti> Daviey: but you need to find the right package versions at alpha-1 time
<pitti> easy for the packages which are on images (.manifest/.list)
<Daviey> pitti: it wasn't my intention to pre-download the debs.. but retrieve on demand.
<pitti> but involves parsing changelogs and comparing timestamps for others
<pitti> Daviey: on demand> like apt-get install mypackage=precise-alpha-2?
<pitti> for a single package that's rather easy
<micahg> ISTR broder having some type of mirror w/a VCS
<pitti> just grab it from LP
<Daviey> pitti: more like, echo "deb     http://snapshot.launchpad.net/archive/ubuntu/20111012T111800Z/ precise main" > /etc/apt/sources.list
<cjwatson> all images that failed last night are rebuilding now, with the exceptions of kubuntu-mobile {omap,omap4} since those seem to be longer-term problems
<Daviey> maybe make /alpha-1 an alias, and /precise-day-33
<GrueMaster> skaet, pitti: Can someone move linux-image-*-omap from universe back to main?  This is breaking my life.
<GrueMaster> Oneiric.
<GrueMaster> linux-image-3.0.0-15-omap | 3.0.0-15.25 | http://ports.ubuntu.com/ubuntu-ports/ oneiric-proposed/universe armel Packages
<skaet> SpamapS, ^ can you help?   I think you've just gone through this bit of fun recently...
<slangasek> GrueMaster: do you know the source package names offhand?
<SpamapS> skaet: no I can't do that part AFAIK, I don't have direct access. :-/
 * SpamapS will sit down with slangasek and/or pitti next week and figure out what we can do to clarify what he can/can't do
<slangasek> seems to be from the 'linux' source
<skaet> SpamapS, okie,  pull me in to the discussions if its convenient.    slangasek, can you help out right now?
<GrueMaster> slangasek: https://launchpad.net/ubuntu/oneiric/+source/linux/3.0.0-15.25
 * skaet sees slangasek helping, and says thank you.
<slangasek> GrueMaster, skaet: binaries from the linux source package on armel have been bumped to main in oneiric-proposed
<slangasek> (modulo the publisher run)
<skaet> Thanks slangasek! :)
<slangasek> GrueMaster: if this affects any other flavors, I need to know what those are
<GrueMaster> I doubt it.  omap is the only armel kernel in the main tree since Natty.
<slangasek> ok
<GrueMaster> And looking at my mirror of ports.u.c, it appears to be limited to linux-image-3.0.0-15-omap (and supported packages).  So everything from the current Oneiric proposed kernel.
<Riddell> where is the template for the release team meeting e-mail?  so I can copy and paste it instead of editing other posts
<skaet> Riddell, https://lists.ubuntu.com/archives/ubuntu-release/2011-November/000471.html
<Riddell> skaet: but I need to add wiki formatting to those headers
<Riddell> (I'm just wanting to minimise the effort in a repetative task)
<skaet> Riddell, fair enough.   Just went and created https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate.  Is that what you're looking for?
<Riddell> skaet: yes lovely
#ubuntu-release 2012-01-06
<micahg> hi doko, if I have an FTBFS fix for a new package, should I sync from Debian first, then upload the fix?
<doko> I don't mind ;)
<micahg> I'm just wondering what's better in terms of archive integrity
<micahg> doko: ok, animal-sniffer in NEW
<micahg> BTW, this fixes a depwait :)
<micahg> doko: assuming it was you, thanks
<pitti> GrueMaster, slangasek: -omap kernel> argh, I thought I caught them all when overriding; sorry
<pitti> no idea how that one weaseled out :(
<cjwatson> Why does http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html only have one entry?  That looks wrong.
<cjwatson> Laney,tumbleweed: if all autosyncs started to be done like https://launchpad.net/ubuntu/+source/autodocktools/1.5.6~rc2+cvs.20111222-1, would that work for you guys?
<cjwatson> >>> autodocktools_spphs[0].creator
<cjwatson> <person at https://api.launchpad.net/1.0/~katie>
<cjwatson> >>> autodocktools_spphs[0].package_creator
<cjwatson> <team at https://api.launchpad.net/1.0/~debian-med>
<cjwatson> contrast with https://launchpad.net/ubuntu/+source/pybik/0.4.2-1:
<cjwatson> >>> pybik_spphs[0].creator
<cjwatson> >>> pybik_spphs[0].package_creator
<cjwatson> <person at https://api.launchpad.net/1.0/~katie>
<Laney> I think we get N/A for katie ATM
<Laney> oh, wait
<Laney> In [1]: lp.people['katie'].display_name
<Laney> Out[1]: u'Ubuntu Archive Auto-Sync'
<Laney> did that always work?
<tumbleweed> it's the e-mail address that breaks, IIRC
<Laney> In [2]: lp.people['katie'].preferred_email_address.email
<Laney> Out[2]: u'archive@ubuntu.com'
<tumbleweed> hrm
<tumbleweed> something used to break badly...
<Laney> In [9]: lp.distributions['ubuntu'].getArchive(name='primary').getPublishedSources(source_name='autodocktools')[0].creator.display_name
<Laney> Out[9]: u'Ubuntu Archive Auto-Sync'
<Laney> so it should be fine â¦
<tumbleweed> http://paste.ubuntu.com/794897/ LGTM
<Laney> something must have been fixed
<cjwatson> I got the katie user unsuspended
<cjwatson> https://answers.launchpad.net/launchpad/+question/183109
<cjwatson> that was necessary before I could do this
<Laney> ah, great, good work
<cjwatson> hmm, annoyingly I get e-mail for this sort of sync though
<Laney> they're essentially syncs you are sponsoring for katie?
<cjwatson> yes, in fact that was just syncpackage -s katie
<cjwatson> though I'll write a new tool for it
<cjwatson> well - I get mail myself, and it says that precise-changes will get mail, but it doesn't actually appear to
<cjwatson> so I can probably put up with the spam until I get round to fixing it
<Laney> I suppose that will email, indeed, until copyPackage grows a quiet mode.
<cjwatson> I can probably just add more special-casing of katie
<cjwatson> after all it's a celebrity so that special-casing is possible ...
<Laney> more fun in the notification code either way
<tumbleweed> Laney: I note that the sponsor still isn't visible in the SPPH?
<Laney> yes
<tumbleweed> grumble
<Laney> there is a bug and a vague wish to look at it myself
<Laney> but as bigjools didn't JFDI right away I suspect there might be something else there
<cjwatson> so is there anything else that stops us transitioning entirely to API syncs for everything?
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-admin-shell-access
<tumbleweed> we can't do API backporting
<cjwatson> I thought the plan for that was to just switch to backportpackage
<tumbleweed> sounds fine, I guess
<cjwatson> the reason I always wanted LP doing syncs was because they have the same version number and therefore I want something to assure that they're really verbatim copies; backports don't have that problem
<cjwatson> I don't recall whether backporters can definitely always upload to -backports, but that's fixable if not
<tumbleweed> aren't there still issues with timeouts, when copying from PPAs via API?
<cjwatson> (and worst case we can have something like the current system where archive admins help them out)
<cjwatson> possibly, I don't know.  Do you have a bug#?
<Laney> we can modify backport-helper to use backportpackage indeed
<cjwatson> actually finishing all the stuff is clearly a few months' of work
<tumbleweed> search turns up bug 575450 and bug 817358
<cjwatson> *this stuff
<ubot4> Launchpad bug 575450 in launchpad "Archive:+copy-packages nearly unusable due to timeouts (affects: 13) (dups: 6) (heat: 75)" [Critical,Triaged] https://launchpad.net/bugs/575450
<ubot4> Launchpad bug 817358 in launchpad "Copying packages with lots of associated bugs can cause timeout (affects: 1) (heat: 1)" [Critical,Triaged] https://launchpad.net/bugs/817358
<Laney> it would be good to have blacklist in LP too, but not a blocker if the tools continue to look at sync-blacklist.txt
<cjwatson> the first is a UI copy which I strongly suspect is more susceptible to timeouts
<cjwatson> Laney: I was shelving that until I could do API autosyncs; now that I almost can I'll be ready to push the blacklist to LP soonish
<cjwatson> sru-release is using .syncSource and should probably be using .copyPackage
<tumbleweed> cjwatson: IIRC copyPackage can't copy from PPAs, and syncSource can but isn't synchronous
<cjwatson> .syncSource is synchronous so is bound to timeout
<tumbleweed> err is synchronous
<cjwatson> I think copyPackage has been fixed; https://launchpad.net/+apidoc/devel.html#archive shows a from_archive parameter
<cjwatson> surely that's enough to copy from PPAs
<cjwatson> Bug 902114 is kind of unfortunate, but if we kept on using bugs and just had mass-sync use a different backend, it wouldn't be a showstopper
<ubot4> Launchpad bug 902114 in launchpad "When sponsoring using copyPackage, the sponsored person is not sent email from Soyuz (affects: 1) (heat: 13)" [High,Triaged] https://launchpad.net/bugs/902114
<Laney> you can't copy /to/ PPAs, don't know about from
<cjwatson> Hm, how come?
<Laney> Response body:
<Laney> ---
<Laney> Not enabled for copying to PPAs yet.
<Laney> ---
<cjwatson> sigh, ok
<cjwatson> It's behind a feature flag
<cjwatson>             # We have no way of giving feedback about failed jobs yet,
<cjwatson>             # so this is disabled for now.
<Laney> looks like it only applies to PPA as destination though?
<Daviey> Hmm... does syncSource() not work now?
<Daviey> from archive -> PPA ?
<cjwatson> Laney: I think so
<cjwatson> Daviey: sure, but syncSource often times out
<Daviey> ahh
<cjwatson> Daviey: it's a synchronous API call
<Laney> I'll just test with something
<Daviey> bug 334858
<ubot4> Launchpad bug 334858 in launchpad "Require a way to copy [P]PPA packages into Ubuntu (dups: 1) (heat: 9)" [High,Triaged] https://launchpad.net/bugs/334858
<cjwatson> thanks for the link
<cjwatson> it might be enough for sru-release though; I'll have to give that a try
<cjwatson> pitti: re bug 891886 et al, given that oneiric and precise are in sync, is there any reason I shouldn't just sru-release --devel it?  (Please don't just do that though; I was hoping to use it as a test case for an sru-release change)
<ubot4> Launchpad bug 891886 in compiz-plugins-main (Ubuntu Precise) (and 2 other projects) "Compiz grid plugin is fired when resizing a window (affects: 4) (dups: 1) (heat: 25)" [High,In progress] https://launchpad.net/bugs/891886
<Laney> https://launchpad.net/ubuntu/+source/haskell-skein/0.1.0.3-2 worked
<Laney> (sync from PPA)
 * Laney gets briefly freaked out by "Component: main"
<cjwatson> Neat.  With include_binaries=False presumably?
<jdstrand> skaet: hey, not sure if you are aware, but http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html lost a bunch of bugs. seems I looked at it yesterday and it was full
<Laney> well, there aren't any yet, but yes
<skaet> jstrand, thanks for the head's up.  Hadn't checked it this morning.   Will look into it later.
<jdstrand> skaet: may be that only critical bugs are shown, even though the options say everything should be
<skaet> hmm...   interesting.
<skaet> ok,  after the meeting.
<jdstrand> toggling the non-critical checkboxes indeed does nothing. toggling critical does what you would expect
<pitti> cjwatson: not technically, just policy-wise (build packages against precise and all that)
<pitti> cjwatson: but we'll get a compiz release next Monday anyway, so I don't object
<pitti> cjwatson: at UDS we had a discussion about SRU policy, and skaet and me argued pretty strongly for actually uploading to precise first
<pitti> we had quite some trouble with oneiric-proposed -> precise copying in particular when there was buildd lag/powerpc failure
<cjwatson> oh, I agree in general
<cjwatson> do you know if it would be a problem in this specific case?
<cjwatson> mostly just because it's the only available test case right now :-)
<pitti> cjwatson: no, should be fine here
<pitti> cjwatson: armhf should get a new build record automatically
<pitti> (sorry, didn't see your response)
<cjwatson> hm, I hadn't thought of armhf; let's see
<cjwatson> https://launchpad.net/ubuntu/precise/+source/compiz-plugins-main/1:0.9.6-0ubuntu4.2 looks OK
<cjwatson> https://launchpad.net/ubuntu/+source/compiz-plugins-main/+publishinghistory not seeing anything for oneiric-updates though
<micahg> cjwatson: just got a -changes E-Mail for that copy
<skaet> Daviey,  "nothing to declare"... lol.   Am wondering if there is an equivalent of random search that should come into play like at customs when crossing a border.  ;)
<cjwatson> micahg: I've got one for precise, but not for oneiric
<pitti> cjwatson: but sru-release didn't crash? hm, strange; it's been a while since I used -d
<pitti> cjwatson: can you try to run it again without -d?
<cjwatson> http://paste.ubuntu.com/794968/
<cjwatson> this is with http://paste.ubuntu.com/794970/ applied
<micahg> cjwatson: right, the one for oneiric was originally 18 days ago
<pitti> cjwatson: so with syncSource (as well as copy-package.py) the copy to devel needed to happen first, then -updates; otherwise it complained about unpublished stuff in oneiric-updates when trying to copy to precise afterwards; perhaps copyPackage behaves differently now?
<cjwatson> in that case it's possible it doesn't work because copyPackage is asynchronous so when it returns the copy hasn't actually happened yet
<cjwatson> did it have to actually be published?
<cjwatson> I tried again and it still isn't working; asking on the LP ops channel if anyone can help me debug
<cjwatson> I'll probably revert to syncSource in half an hour or so if I don't hear anything
<Daviey> skaet: if there are rubber gloves, i'll be there.
<skaet> Daviey, LOL.
<cjwatson> compiz-plugins-main 1:0.9.6-0ubuntu4.2 in precise (same version already building in the destination archive for Precise)
<cjwatson> Maybe that's blocking copyPackage too
 * cjwatson cranks up the armhf build score there
<cjwatson> this is a bug though
<ev> I'll have a new wubi finally up just as soon as people.c.c rises from the dead
<cjwatson> OK.  New auto-sync script not absolutely the fastest thing ever but it seems to be at least minimally managing to scan the differences.
<cjwatson> Things I still need to do to it: (1) test that it returns the same set of results as sync-source.py -a; (2) add checks for conflicting binary versions; (3) add checks for syncs that require fakesyncs; (4) possibly check for pending Ubuntu publications as well as published ones
<cjwatson> oh and (5) make it scan the blacklist, pending shifting that into LP
<cjwatson> I might be able to make the last autosync for precise be API-based :-)
<Laney> :-)
<cjwatson> (5) done
<Laney> are you still seeing many bug based sync requests from developers?
<Laney> if so, we might want to announce syncpackage a bit
<cjwatson> a handful, very few
<cjwatson> but probably, yes
<Laney> syncpackage can do (3) â¦
<tumbleweed> and announce avoiding +localpackagediffs at the same time, so we can refer to it in future :)
<cjwatson> Laney: true, may steal / call some code
<Laney> maybe it could be extended to work on multiple packages at once
<Laney> or get / become a library indeed
<cjwatson> I do want auto-sync to be a separate thing really; it has slightly odd semantics and I don't want it to have the same kinds of options
<cjwatson> e.g. auto-sync -f would be very bad
<Laney> I was thinking you could have it hand off to syncpackage at some stage
<cjwatson> (2) is a bit awkward because sync-source.py never got that *quite* right
<Laney> not sure what that means
<cjwatson> I don't think I'd want it to actually call syncpackage, but maybe use some common code
<cjwatson> that said, the actual sync bit really isn't very much code
<cjwatson> only the fakesync detection is actually hard in any way
<tumbleweed> common checks sounds like a useful thing
<cjwatson> wrapping things up in udt objects to call syncpackage might be more trouble than it's worth
<cjwatson> given that I'm calculating the sync list from a distro_series_difference collection
<tumbleweed> agreed
<tumbleweed> I also don't understand (2)
<cjwatson> syncpackage probably ought to gain (2) actually.  That's a check that the binary versions that are produced by the source package don't accidentally override binaries from another source that have an ubuntu version number
<cjwatson> so any such syncs require -f
<tumbleweed> sounds useful, yes
<cjwatson> so if you have libfoo 1.0-1ubuntu1 -> [libfoo0 1.0-1ubuntu1, libfoo-dev 1.0-1ubuntu1] and you try to sync foo 1.0-1 -> [foo 1.0-1]  ==>  foo 1.0-2 -> [foo 1.0-2, libfoo0 1.0-2, libfoo-dev 1.0-2], that should require forcing
<cjwatson> if that notation makes sense
<cjwatson> sync-source.py checked this rather crudely and got it wrong in two ways, possibly with the same potential fix:
<cjwatson>  (1) in the above example, if foo 1.0-2 failed to build and you then tried to sync foo 1.0-3, you had to force that as well because it checked the set of binaries actually in the archive rather than the set of binaries that would be in the archive if everything had built
<cjwatson>  (2) packages that have a source with no ubuntu version substring but binaries with an ubuntu version substring have to be forcibly synced every time (yes, there is a real example of this in the archive!)
<cjwatson> (it's something that generates binaries based on binutils-source and concatenates binutils' version number with its own, or something along those lines)
<tumbleweed> hah
<tumbleweed> (1) isn't a dig problem, though
<cjwatson> I think the fix is not to check actual binaries based on Packages or getPublishedBinaries, but instead to check whether each of the binaries produced by the new source are in the Binary field of any other source package with an ubuntu version substring
<cjwatson> that would deal with both problems
<cjwatson> possibly excluding binaries that have already been superseded
<cjwatson> need to figure out how to do that quickly in the API though
<tumbleweed> sounds reasonable
<Laney> can you do that in the API?
<cjwatson> I'm not sure
<tumbleweed> it'll involve reading the .dsc too
<cjwatson> reading *every* .dsc
<cjwatson> which would suck
<Laney> yeah. not the fastest thing to do.
<cjwatson> might be quicker to just download Sources
<tumbleweed> oh, right
<cjwatson> I was hoping to avoid that, but ...
<Laney> unless an external job maintains a database
<tumbleweed> (which would be preferable fo syncpackage)
<cjwatson> I wouldn't do that, I'd extend LP if I really needed that
<tumbleweed> extending LP to know the contents of .dsc s would be handy for other bits of u-dt
<cjwatson> it already does, but this is sort of a reverse lookup
<tumbleweed> yes
<cjwatson> I mean, internally it has SPR.dsc_binaries (although it's sometimes wrong; I have a branch in progress at the moment to fix that up)
<cjwatson> but we want to search for any source that has this binary in dsc_binaries
<cjwatson> indeed a binary -> source(s) lookup would be a useful thing to have in general
<cjwatson> maybe just getPublishedSources(binary_name=...)
<cjwatson> I'll file an LP bug in a bit and see if anyone has comments; DVD time now
<Laney> I wonder what checks mass-sync would perform that we wouldn't also want syncpackage to
<Laney> seeya
#ubuntu-release 2012-01-07
<cjwatson> Laney: I don't think there are any significant ones in the long term; I'm somewhat interested in doing something expedient for now, but it wouldn't be hard to refactor later
<Laney> ack
<cjwatson> mainly because I've left it rather late to get this done and I'd like not to have to wait for April to test it ...
<Laney> well, and the first autosync of a cycle might not be the best time to test a brand new tool :-)
<Laney> anyway, getting it out the door fast is fine by me: we then have 4 monthsish to shuffle code around
<cjwatson> depends how you look at it ... but at the very least it means there's a giant pile of output and it's hard to audit
 * cjwatson decides to just not bother believing that "Blacklisted current version" knows what it's talking about, since it appears not to always do so
<Laney> we came to that conclusion for syncpackage too
<cjwatson> from what I can tell all it means is this_version > parent_version, and auto-sync can check that for itself ...
<Laney> except when it's set incorrectly or LP forgets to clear it
<cjwatson> exactly
<cjwatson> it's poor naming anyway
<Laney> https://bugs.launchpad.net/launchpad/+bug/841372
<ubot4> Launchpad bug 841372 in launchpad "Incorrect auto-blacklisting in DSD? (affects: 1) (heat: 7)" [Low,Triaged]
<cjwatson> yeah, just found that from the ref in syncpackage
<cjwatson> I think I have less rabbit-holey bugs to use my LP hacking time on though :)
<Laney> shame, as per-version blacklisting could be generally useful
<cjwatson> mm, sounds no fun to maintain though
<cjwatson> I suspect you'd often want a range of some kind
<cjwatson> "upstream 1.4 sucked, but we hear 1.5 is better"
<Laney> probably
<cjwatson> ooh, I should use copyPackages, that doesn't send mail
<cjwatson> (1) done
<Laney> goodnight. tomorrow I try to get local LP reasonably functional.
 * cjwatson posts a lengthy followup to bug 597041 on the binary->source lookup issue
<ubot4> Launchpad bug 597041 in python-launchpadlib (Ubuntu) (and 1 other project) "No way to get from binary package to source package (affects: 1) (heat: 8)" [Undecided,Invalid] https://launchpad.net/bugs/597041
<cjwatson> OK!  I think I'll be able to run an API auto-sync later today
<cjwatson> Will check in the code a bit later; have to run now
<cjwatson> The only significant thing that's not yet implemented is component checks on binaries, which isn't desperately important for the moment
#ubuntu-release 2012-01-08
<GridCube> todays xubuntu alternate images fail with "no kernel were found" errors
<cjwatson> oh, I think I forgot to bump the kernel version in the seeds, doh
<GridCube> :)
<cjwatson> yes, I'm an idiot, sorry.  thanks for the report.  I've committed a fix which will be effective from tomorrow's images (probably no point respinning now)
<GridCube> :)
<GridCube> np
<GridCube> just doing my labor :D
<cjwatson> sorry, would have caught that earlier if it'd been a weekday
<GridCube> :P and if i would have done tests earlier too
<cjwatson> I was at a party much of the day so wouldn't have made much difference
 * cjwatson does the first API-based autosync!
<cjwatson> yay yay yay, that worked
<Laney> oh, exciting!
 * cjwatson adds new package handling to auto-sync
<cjwatson> should hopefully make it a thing of the past that we get ridiculously behind on syncs of new packages
<cjwatson> I love being able to control my own tools
<tumbleweed> cjwatson: yay to not being behind on new packages!
 * Laney has done some LP hacking and spph.sponsor lives
<tumbleweed> we'll need to special case katie in lp-udd.py
<Laney> why?
<tumbleweed> I was going to say because tehy aren't real sponsorships, but yeah, don't see any particular need
<Laney> maybe though, otherwise all consumers will have to
<Laney> is this going to give cjwatson lots of karma? :-)
<tumbleweed> probably :)
<tumbleweed> it's ok, he deserves it
<tumbleweed> Laney: in general, I think other services have to be careful with katie uploads. This is just another variant of those...
<Laney> dunno, I'll think about it
#ubuntu-release 2013-01-01
<joshuahoover> Happy New Year!
<Noskcaj> joshuahoover, that was 15 hours ago
#ubuntu-release 2013-01-03
<tjaalton> there's no d-i upload using the backport stack for 12.04.2 yet?
<cjwatson> should be in -proposed ...
<tjaalton> oh
<tjaalton> yeah there it is.. didn't think to check -proposed
<tjaalton> I think there is a newer kernel available now (-35), so maybe a rebuild is in order?
<tjaalton> uh
<tjaalton> -21
<cjwatson> I'd like to finish landing the SB stack first please
<tjaalton> sure, just thinking out loud :)
<cjwatson> stgraber: Did you ever manage to test precise images on non-SB systems of any kind?
<cjwatson> (Or anyone else?)
<tjaalton> cjwatson: you mean like the -proposed netboot image? I can give it a go
<cjwatson> I meant CD images
<tjaalton> I've installed it on a haswell system, no secure boot
<tjaalton> before the holidays
<cjwatson> BIOS or UEFI?
<tjaalton> good question.. I'll check. could be bios
<tjaalton> cjwatson: bios..
<cjwatson> OK, thanks
<cjwatson> Anyone done a non-SB UEFI test with current precise imageS?
<cjwatson> *images
<tjaalton> i'll try that next
<cjwatson> Brilliant, thanks
<tjaalton> hmm, maybe I should try some other image than this oem one...
<tjaalton> and not on the beta hw :)
<tjaalton> has issues with booting uefi it seems
<tjaalton> cjwatson: is it the precise/dvd/current image on cdimages.u.c?
<tjaalton> it says 12.04.2
<cjwatson> Yeah
<tjaalton> ok, takes a while to download
<tjaalton> cjwatson: I get "error: couldn't read file; error: you need to load the kernel first" after the grub menu
<cjwatson> Any difference with the desktop image?
<cjwatson> precise/daily-live/current/
<cjwatson> and this is amd64 I presume
<tjaalton> downloading, and yes
<tjaalton> the oem image had the same problem
<tjaalton> from mid-december with the new stuff on it
<cjwatson> I'm not going to debug the OEM image since some of this stuff can depend on fine details of image construction
<tjaalton> right, but it could be something related to the haswell firmware too. I'll ask around just to be sure
<cjwatson> It's possible, although an outside chance
<cjwatson> Also possibly worth comparing with 12.04.1 to see whether this is a regression
<tjaalton> hm, the amd64+mac image I had doesn't even seem to load grub
<cjwatson> Why are you using amd64+mac?
<cjwatson> Its purpose is not to have UEFI support.
<tjaalton> it's the only cd-sized image there was
<cjwatson> It's not a valid test for this.
<tjaalton> and I had that already
<tjaalton> this was .1
<tjaalton> .2 just finished downloading
<cjwatson> http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image
<cjwatson> ^- explains that amd64+mac does not have UEFI support
<cjwatson> Does this brand-spanking-new system really have a CD-only drive?
<tjaalton> no :)
<tjaalton> s/cd-sized/reasonably sized/
<tjaalton> booting off a usb stick didn't work the last time I tried
<cjwatson> eh, the amd64 image is very similar in size to the amd64+mac image
<cjwatson> to within noise, basically
<tjaalton> http://cdimages.ubuntu.com/releases/12.04.1/release/
<cjwatson> http://releases.ubuntu.com/12.04/
<tjaalton> besides, it was just what I had on the system readily available, I'll try .2 now while .1 dvd is downloading
<tjaalton> bah
<tjaalton> confusing :)
<cjwatson> (and see the link at the top of that page ...)
<tjaalton> hah
<tjaalton> bad/old habit of using cdimages.u.c..
<cjwatson> current precise-desktop-amd64 works fine in kvm/uefi for me
<cjwatson> well, gets to grub and boots the kernel
<cjwatson> I'll do a full test install in kvm
<cjwatson> working in kvm seems to eliminate this being an image construction bug, so I think a firmware problem has become more likely
<tjaalton> yeah
<tjaalton> or firmware setting bug
<cjwatson> admittedly I've not tried the DVD yet; it'll take a couple of hours to download
<cjwatson> the fact that grub got as far as it did for you indicates that efidisk is at least somewhat working, since it read its configuration file
<cjwatson> check that the problem's repeatable, too
<tjaalton> same thing with the desktop image.. trying with the usb stick now
<tjaalton> could be a brazero issue on quantal
<cjwatson> I use growisofs for burning DVD images
<tjaalton> cjwatson: ha, booted fine off the usb stick, installing now
<cjwatson> OK, good; I'd still like to know that it isn't a regression, but that's helpful
<stgraber> cjwatson: I did one before the holidays by accident (forgot to enable SB) and it worked fine
<tjaalton> I'll try with the growisofs-burned image next
<cjwatson> infinity: Do you remember anything else we wanted to check before dropping in the whole lot?
<cjwatson> I still have two other grub2 patches I want to squeeze in for .2 (one customer-requested), and am running out of time ...
<tjaalton> cjwatson: not a regression, getting the same with .1
<tjaalton> something wrong with the machine
<tjaalton> but usb worked, installed and boots afterwards
<cjwatson> phew (from my pov)
<tjaalton> :)
<tjaalton> the .2 image doesn't seem to use the xorg backport stack yet?
<cjwatson> no, just the kernel backports
<cjwatson> not worked out what we need to do for xorg yet
<tjaalton> a new meta package for ubuntu-desktop, and the desktop task that installs it?
<tjaalton> mlankhorst should know, I'll ask..
<cjwatson> task changes are troublesome
<cjwatson> I think we're actually going to have to switch to the metapackage; but if we change the metapackage then that upgrades existing users ...
<cjwatson> the kernel was easier since that's already handled specially
<tjaalton> so there's xserver-xorg-lts-quantal, but the current archive version would remove ubuntu-desktop
<tjaalton> and there's a new version that fixes that, but not accepted yet
<cjwatson> let's see about that
<tjaalton> on the proposed queue I'm told..
<cjwatson> no bug ref, makes it hard to coordinate validation?
<tjaalton> hmm
<cjwatson> there are occasional very routine things we do without that, but not sure this counts as routine
<mlankhorst> hey
<tjaalton> mlankhorst: 17:00 < cjwatson> no bug ref, makes it hard to coordinate validation?
<tjaalton> for the xorg upload
<mlankhorst> hm would have to check
<mlankhorst> don't know if it had a bug or not
<cjwatson> if not, could you create an artificial one, please?
<cjwatson> I just want some way of ensuring that this all works together nicely
<cjwatson> and somebody is going to have to recommend a set of installer/metapackage/whatever changes, bearing in mind upgrade effects
<mlankhorst> so far most communication goes through me
<mlankhorst> so felt like having a bug was confusing
<cjwatson> for SRUs it needs to be in bugs
<cjwatson> please
<cjwatson> it will make things better since there'll be clear status right there on the SRU report
<cjwatson> can't do much about the existing xorg updates; right now they're all sitting there with no way to indicate whether they're good for promotion to -updates :-/
<cjwatson> so, the spec says that upgraders won't be pulled into the new enablement stack
<tjaalton> right
<mlankhorst> yeah the xorg package just allows the lts-quantal version to be coinstalled
<cjwatson> this means we somehow need to get the images changed without touching metapackages
<tjaalton> but the .2 image needs to have some way to pull xorg-lts-quantal
<tjaalton> which then provides 'xorg' for ubuntu-desktop
<cjwatson> this is kind of horribly out of spec for the image building tools - but there may be some ways to achieve it
<mlankhorst> erm
<mlankhorst> xorg can install just fine
<mlankhorst> it's just the xserver-xorg that will conflict with xserver-xorg-lts-quantal
<cjwatson> I can't really do anything until the SB stack lands, at risk of entangling the two
<cjwatson> sure, but that doesn't address the image building problem
<cjwatson> it makes it possible to do something without breaking upgraders, yes
<cjwatson> but I think we're going to need to SRU at least livecd-rootfs and possibly pkgsel to manually arrange to install -lts-quantal
<cjwatson> actually I'd rather leave pkgsel alone and only support installing the enablement stack from desktop images ...
<cjwatson> (and DVD)
<cjwatson> and there's the question of things like the Chinese edition
<cjwatson> kind of unfortunate nobody arranged for anyone cdimagey to have a work item for this ...
<tjaalton> :)
<cjwatson> so, if I can have an xorg reupload with a bug ref, I'll accept that, and then we can get going on the image building changes after the SB changes are in -updates
<mlankhorst> ok
<mlankhorst> could you look at the video blobs in the meantime?
<cjwatson> specific package names?
<mlankhorst> nvidia-* and fglrx whatever, that are still in the proposed queue
<cjwatson> mkay
<mlankhorst> do you want a bug specific about xorg, or just generic 'xorg quantal in precise' bug
<cjwatson> the latter's fine
<cjwatson> sigh, at least one of these fglrx uploads is busted
<cjwatson> is tseliot on IRC anywhere?
<mlankhorst> should be
<mlankhorst> but not online atm
<tjaalton> probably on holiday
<cjwatson> in that case perhaps one of you could upload new fglrx-installer-experimental-9 and fglrx-installer-updates packages in line with comments #31 and #32 in bug 1080588 (i.e. drop the xserver-xorg-core deps and upload with appropriate -v)?
<ubot2> Launchpad bug 1080588 in jockey (Ubuntu Precise) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588
<mlankhorst> cjwatson: hm should I bump version of xorg as well or can you delete the current one from -proposed?
<cjwatson> mlankhorst: I've rejected it
<mlankhorst> ah k
<tjaalton> cjwatson: so can I reuse 2:9.010-0ubuntu0.2 and squash both changes there?
<cjwatson> In this case, since there's an additional change, I'd rather you used a new version number
<cjwatson> (actual source change rather than just changelog)
<tjaalton> so 0.4?
<cjwatson> Yeah
<tjaalton> ok I'll deal with those
<mlankhorst> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1095686 good enough?
<ubot2> Launchpad bug 1095686 in xorg (Ubuntu) "xorg needs to be updated to allow quantal xserver stack to be installed" [Critical,In progress]
<tjaalton> jeez, fglrx is huge..
<cjwatson> mlankhorst: yes, thanks, now that I've targeted it to precise :)
<mlankhorst> ah right
<mlankhorst> uploading
<mlankhorst> oops
<cjwatson> oops?
<mlankhorst> raced with your bug changes :)
<cjwatson> not a problem ...
<mlankhorst> but it's there now, I'm uncertain about the fglrx changes, tjaalton are you working on it?
<cjwatson> yeah, I'll review it once the queue gets a debdiff
<tjaalton> mlankhorst: yeah, trying to figure out what to actually change :)
<mlankhorst> how are those maintained btw?
<tjaalton> in git somewhere I think, but pulled them from the rejected queue
<tjaalton> https://launchpad.net/ubuntu/precise/+queue?queue_state=4&queue_text=
<mlankhorst> yeah I was just curious if we had a central repo or something, similar to other xorg things
<tjaalton> nothing we can touch
<tjaalton> it's on github or such
<mlankhorst> ah
<tjaalton> fglrx-installer-experimental uploaded
<tjaalton> -updates after dinner
<tjaalton> cjwatson: the nvidia-96 upload you accepted failed to upload (after build) on amd64, should I just kick a rebuild?
<cjwatson> sure, if it looks transient
<tjaalton> yup, built fine
<mlankhorst> ok now xorg should work? :)
<tjaalton> hmm, so fglrx-updates in precise doesn't even support the new backport stack, is there any point in updating that version for that bug?
<mlankhorst> nah
<tjaalton> ok, so it may wait for the other sru to pass
<tjaalton> although, it has the same bug as the experimental one
<mlankhorst> yay
<brendand> anyone know why in 12.04.2 the kernel versions vary between the amd64 and i386 builds?
<brendand> http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-i386.manifest
<brendand> linux-image-generic-pae	3.2.0.35.40
<brendand> http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-amd64.manifest
<brendand> linux-image-generic-lts-quantal	3.5.0.21.28
<apw> oh ... are the boot kernels on i386 non-pae i wonder
<apw> hmm no, that is a pae kernel on there, so not that
<cjwatson> brendand: ara already asked about that on #ubuntu-devel
<cjwatson> and yes it probably is something to do with pae
<cjwatson> it's on my list
<brendand> cjwatson, ok. a fix isn't an emergency from our perspective. mainly we just needed to know whether it was in fact a bug
<brendand> cjwatson, we wanted to make sure that 3.5 was the kernel that was supposed to be included
<cjwatson> it is a bug and is something I need to fix for .2
<tjaalton> cjwatson: both fglrx packages uploaded, but the other sru's still block them
<infinity> cjwatson: I'm sure we have a lot more misfeatures to shake out on images, but I can't think of anything else SB-specific that needed testing.  I've been mostly not getting in the way of you, slangasek, and stgraber testing, mind you. :P
<cjwatson> infinity: OK.  Do you have any objection if I just promote the lot now, then?
<infinity> cjwatson: Nope.
 * cjwatson copies all the things
<infinity> cjwatson: The patch to debian/* in grub doesn't match the behaviour you patched into grub itself.
<infinity> cjwatson: (That is, the debian bits will ignore grub.d if /etc/default/grub doesn't exist, while grub will still use grub.d even if default/grub isn't there)
<infinity> cjwatson: Not sure which behaviour is most desirable, but they should probably be consistent.
<cjwatson> fair point; I'll fix that later (and in experimental/raring too)
<cjwatson> feel free to reject/hold/whatever
<infinity> cjwatson: I'd probably lean toward the way you did grub, so one could break out default/grub to .d snippets and delete the file entirely, but your call.  I'll reject for now.
<infinity> cjwatson: Something like http://paste.ubuntu.com/1492918/ perhaps.
<infinity> (And a similar munging of postinst)
<infinity> cjwatson: Tested the above locally, seems to work as I'd expect.
<bdmurray> Can the release of Precise SRUs proceed as usual?  If so until when?
<infinity> bdmurray: Yes, until the 17th, ish.
<xnox> ah. just a week left.
<bdmurray> infinity: thanks!
<infinity> xnox: Your weeks are 14 days long?
<bdmurray> that'd make for less weekends :-(
<infinity> cjwatson: Oh, hey, I have commit access to grub in Debian, don't I?  Maybe I'll just commit this directly, unless you'd rather I didn't?
<xnox> infinity: 1 week to upload & accepted in -proposed + 1 week of baking , to be release on time.
<infinity> xnox: Final freeze for 12.04.2 is the 24th, I was giving the 17th as the last possible day to accept things (barring emergencies).
<xnox> oh, ok.
<infinity> Not that I have problems with people thinking the deadline is a week earlier.  Last minute panic sucks.
<bdmurray> I just verified bug 1008225 if somebody wants to release it - its been in -proposed for some time.
<ubot2> Launchpad bug 1008225 in vm-builder (Ubuntu Precise) "vmbuilder fails using tmpfs due to upstart restarting cron in the tmpfs" [High,Fix committed] https://launchpad.net/bugs/1008225
<infinity> bdmurray: Done.
<bdmurray> I've made an ubuntu-archive-tools merge proposal - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/comment-date/+merge/141818 - nothing too exciting though
<infinity> bdmurray: I object.  The diff has more green than red, and I hate green.
<cjwatson> infinity: that's fine to commit directly, but isn't it needed in postinst.in too?
<cjwatson> infinity: (definitely to experimental though, not to the unstable/wheezy branch)
#ubuntu-release 2013-01-04
<infinity> cjwatson: Yeah, I mentioned postinst in my above rambling.
<infinity> 12:54 < infinity> cjwatson: Something like http://paste.ubuntu.com/1492918/ perhaps.
<infinity> 12:55 < infinity> (And a similar munging of postinst)
<infinity> cjwatson: Just without a nick hilight, I guess.
<cjwatson> ok
<tjaalton> infinity: yo, about the sssd rejection.. I forgot to add a pointer to bug 1086304 in the changelog, would that have made a difference?
<ubot2> Launchpad bug 1086304 in sssd (Ubuntu Precise) "new upstream bugfix release from the LTM branch" [High,In progress] https://launchpad.net/bugs/1086304
<infinity> tjaalton: Unless we have a bug for every single fix in that new upstream release, it's going to need an MRE, or at least some serious review.
<infinity> tjaalton: (And I'm guessing you don't have bugs with testcases for every change)
<tjaalton> infinity: no I don't
<tjaalton> hmm, technical-board@ is not listed on lists.u.c
<tjaalton> infinity: sent the MRE :)
<psivaa> would anyone know why precise desktop i386 images are not yet published to cdimage despite 'Build successfully added to the tracker' in the logs
<tjaalton> cjwatson: so, would something like this work for livecd-rootfs? http://pastebin.com/b3gzhpnf
 * ogra_ wuld rather put it into a flavour based case function instead of making it arch based
<ogra_> (if you actually mean what you say in the changelog ;) )
<cjwatson> tjaalton: on leave today
<cjwatson> ogra_: well it should probably go alongside the kernel -lts-quantal handling
<ogra_> cjwatson, yes but then the changelog describes it wrongly
<ogra_> since it says it is for ubuntu/edubuntu only
<ogra_> so just adjust the changelog to say i368/amd64 instead of mentioning the flavours
<cjwatson> it's per-flavour too
<cjwatson> so definitely not "instead of"
<ogra_> k
<tjaalton> yeah the diff just doesn't show the context fully :)
<ogra_> right, and i didnt look at the actual code only at the diff ... sorry, technically it looks fine
<gema> ogra_: any idea who's on duty for the release team today?
<gema> ogra_: we are missing precise desktop i386 images and unsure who to ask for them :)
<ogra_> gema, no idea, i just got back from vac. yesterday
<gema> ogra_: oh, welcome back!
<brendand> gema, there was a problem with yesterdays image and the kernels included
 * ogra_ will look for logs though, i havent got any failure mails for broken builds 
<gema> ogra_: thanks !
<brendand> gema, which might explain why i386 is not there since the issue only affected that
<gema> brendand: precise?
<gema> brendand: ok, that may be it then
<gema> thanks
<brendand> gema, yes the 12.04.2 dailies
<gema> brendand: is there a bug for that?
<ogra_> ah, yeah there were some kernel related uploads
<ogra_> and i dont get failure mails for 12.04 builds i think
<psivaa> brendand: gema: ogra_: but the images were built successfully
<gema> psivaa: yesterday?
<psivaa> gema: today as well
<gema> psivaa: so the only thing that failed is the publishing?
<brendand> gema, cjwatson was looking at it, not sure if there is a bug number
<gema> brendand: ack
<Laney> mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily-live/tmp/precise-i386/CD1/casper/filesystem.kernel-generic-pae': No such file or directory
<Laney> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily-live/tmp/precise-i386/bootable-stamp] Error 1
<Laney> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<gema> oh, so there is a problem :D
<Laney> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/daily-live-20130104.log
<psivaa> gema: as far as i understood, yes it was a publishing issue, http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/daily-20130104.log
<gema> ok, thanks
<ogra_> yeah
<Laney> that's the alternate
<Laney> which is on there
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/daily-live-20130104.log
<ogra_> has the same error
<cjwatson> I know about the precise thing and will fix it on Monday when I'm back
<cjwatson> no bug
<ogra_> gema, ^^^
<cjwatson> hm, mind you maybe I can make a really quick stab at it now
<ogra_> tsk
<gema> ogra_, cjwatson ack, monday is fine, as long as you guys are on the case, I am happy
<cjwatson> I've had a shot at fixing it; may or may not work
<cjwatson> if it doesn't work it'll have to wait 'til Monday or somebody else will have to figure it out
<cjwatson> If somebody wants to spend a bit of time tracking down an image build bug, I'd really appreciate somebody working out why the Chinese edition build is failing
<cjwatson> (precise)
<cjwatson> It seems to be producing a full log but no actual output, or exiting non-zero, or something
<lamont> should I be at all concerned that raring seems to not debootstrap atm?
<xnox> lamont: do you have a log? (with/without -proposed/universe)?
<lamont> xnox: I suppose I could cause one to exist.  let me do that
<lamont> dpkg-deb: file `.//var/cache/apt/archives/libglib2.0-0_2.34.3-1_amd64.deb' contains ununderstood data member data.tar.xz     , giving up
<lamont> that's debootstrapping raring on a lucid box
<lamont> and sounds like a dpkg-deb bug in lucid, albeit a feature request
<lamont> and a bug against dpkg to s/ununderstood/nonunderstood/
<lamont> :D
<lamont> I suspect that we don't want to call debootstrapping raring on precise "unsupported", so something gets a bug
 * xnox thought all /relevant/ lucid boxes had dpkg backported with xz patch.
<xnox> lamont: precise should be fine, as it does have .xz support in dpkg.
<lamont> ii  dpkg                            1.15.5.6ubuntu4.6               Debian package management system
<lamont> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<lamont> it's fully currnet
<lamont> lucid, lucid-updates, lucid-security
<xnox> lamont: yeah, we didn't upload xz support into lucid backport. Only into prod-ppa or something like that.
<lamont> so, iow, we didn't actually fix it for lucid. :(
<stgraber> lamont: looking around, you want >= 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04
<lamont> stgraber: that is not available to our customers
<lamont> which package do I file the bug against that joe user cannot debootstrap raring on a lucid machine?
<xnox> lamont: can lucid bootstrap precise? & then bootstrap raring from that =))))
 * xnox hides
<lamont> xnox: IOW, lucid is no longer supported?
<lamont> also, HARDY is still supported, no?
<xnox> lamont: it is, on the server & what not. https://wiki.ubuntu.com/Releases
<stgraber> xnox: lucid should be able to bootstrap precise, yes.
<xnox> lamont: lucid until April 2015 (Server), hardy until April 2013 (Server).
<stgraber> lamont: the right package to file a bug against would be dpkg
<xnox> lamont: but you are asking for new features, not "support".
<stgraber> lamont: does lucid's debootstrap even know what raring is?
<lamont> true enough
<lamont> I'll file the bug against dpkg and we'll see where it goes
<lamont> ...
<stgraber> ls: cannot access /usr/share/debootstrap/scripts/raring: No such file or directory
<lamont> welll...
<stgraber> the most recent release in lucid's debootstrap is precise
<stgraber> which is the last one that's guaranteed to work
<lamont> everyone knows that's just a matter of ln -s gutsy /usr/share/debootstrap/scripts/raring
<lamont> I'll include that little tidbit in the bug for purposes of full disclosure
<stgraber> sure, just wanted to confirm that we're not shipping something that's broken (an SRUed debootstrap with the raring symlink) :)
<lamont> I have 1.0.39~0.IS.10.04
 * lamont shames
<xnox> stgraber: /me ponders if 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04 can be rebased on top of 4.6 and published somewhere (ppa or backports)
<stgraber> xnox: well, it should probably be rebased on 4.6, yes, as it seems to be currently held to the 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04 by puppet to avoid loosing the required features
<stgraber> pushing to a PPA should be fine, not sure it matches the backports policy as it's not an actual full backport
<xnox> ScottK: can we "cherry-pick" a feature into lucid-backport? (dpkg xz support in lucid, without bringing a full new dpkg)
<lamont> generally speaking, in the case of dpkg, if we backported a higher rev of it, it was because either (1) we had to, or (2) it was invasive enough that the gods of distro promised us that they were pretty sure it wouldn't regress anything (though I belive that said promise is specifically not intended to be sufficient for the purposes of this channel)
<ScottK> Generically, a cherry pick is fine.
<lamont> [do you like all that handwaving non-promise in (2)?]
<ScottK> Specifically, any dpkg backport would have to have significant testing.
<xnox> lamont: are you after "make it work" (with ppa/backports/whatever) or are you after "it should be SRUed into lucid" (which will not happen as far as I can see)
<ScottK> xnox: Also, I don't remember if lucid backports is NotAutomatic or not.  If it is, then that makes this less concerning.
<lamont> xnox: the current state is that before the porterbox gets any new chroots, it'll have to upgrade to precise
<xnox> ScottK: the xz cherry pick in question is extensively tested by a few production machines.
<Laney> notautomatic is natty
<xnox> lamont: why can you not pin ISPATCHED.10.04 version?
<lamont> xnox: hence it's actually me wearing my coredev hat going "da&*^*(it this should work"
<xnox> =))))
<lamont> xnox: well, I could trivially add the suite so that we get the ISPATCHED version
<lamont> OTOH, ISTR that machine should get scheduled for a precise upgrade anywya
<xnox> precise is the way to go....
<lamont> there's a schedule, and then there are the "this doesn't work on lucid, works on precise, ok" escalations to the head of the schedule
<lamont> so s/get/be/ in my prior statement
<xnox> lamont: yeah.... if it can linger another year there will be a new LTS =)))))
 * xnox remembers upgrading potato machine all the way to squeeze without reboots =) that was fun.
<xnox> only had to fetch a couple of packages from snapshots to do lockstep upgrade but overall it was fine.
<lamont> I'm not entirely sure that "without reboots" is an option these days
<xnox> lamont: heck I didn't even fully dist-upgraded to the intermittent release =)
<lamont> that would be an interesting test for someone: does the hardy -> lucid -> precise -> quantal (and maybe -> raring) path require reboots at any point in the path?
<lamont> I remember crosgrading sarge(?) to warty.  that was a wonderfully crazy time
 * xnox is pondering about crosgrading to x32, when we get it ;-)
<lamont> x32?
<xnox> https://lwn.net/Articles/456731/
<xnox> the crazy 64bit machine with 32bit long pointers.
<cjwatson> mm, IMO we should backport the dpkg xz patch to lucid-proposed; I'm pretty confident in standing behind it by now
<cjwatson> but not going to do so today
 * ScottK likes that plan.
<xnox> infinity: https://launchpad.net/ubuntu/+source/cunit/2.1-0.dfsg-10ubuntu1 can you make it build faster? =)
<infinity> xnox: Your debian/rules changes don't seem to be accounted for in the changelog...
<xnox> infinity: and?! =) it's not an SRU and the preferred way to do autoreconf.
<xnox> s/the/my/
<infinity> xnox: Sure, but you're submitting this to Debian, right?  (That was the other condition of the MIR)
<xnox> *sigh* /me missed that bit.
<infinity> Pretty sure we don't want to end up maintaining this when we haven't been so far.
<infinity> Which was the point. :)
<xnox> infinity: well I can do a more minimal fix. drop the "-ansi" flag and not add checks for c99, but imho I'm not sure what's best to do here. Minimal wise.
<xnox> just ignore the "implicit declaration of snprintf" warning from the compiler and get on with things?
<infinity> Ignoring implicit declarations is generally never the right thing to do.
<infinity> So, no, I'm okay with more intrusive and correct fixes, but they should go to Debian and get a second set of eyes.
<xnox> (snprintf is not in ansi (C90) only in C99, yet upstream currently builds with -ansi & uses snprintf)
<xnox> ack.
 * xnox has a stack of patches to push to debian from recent FTBFS fixes.....
<infinity> Yeah, upstream's clearly wrong about their target C.
<infinity> (Though, with no switches/defines, you'll end up with C11, not C99, so your changelog is still a lie)
<infinity> Not that C11 is a bad idea. :P
<infinity> (I love that we stuck with two digit dates for that, and 11 << 99... NOT CONFUSING AT ALL)
<xnox> infinity: I added AC_PROG_CC_C99 which defines C99 for a given compiler, if it supports it.
<infinity> Ahh, right, missed that bit.
 * xnox liked C0x
<xnox> infinity: but that macro is not available in autoconf2.59 ...... hence autoreconf to a brave new world.
<infinity> xnox: Just dropping -ansi would likely be fine too.
<infinity> xnox: Your fix is more complete for upsteam, mind you, if they care deeply.
<infinity> (Personally, I think people who insist on targetting a specific C standard instead of just keeping current are Doing It Wrong, but whatever)
 * xnox tries to recall last upstream commit - was it in this century?
<xnox> infinity: well it's a unit-test framework for C, any C, hence the original goal to target lowest one..... a bit of a fail with a single call to snprintf.
<infinity> Oh, fair point.  The other solution could be to not call snprintf. :P
<xnox> yeah, could do that. but sprintf is "less safe".
<infinity> Sure is.
<infinity> But our fancy overflow detection should catch that anyway, I would think?
<infinity> Of course, if they're doing tricky things with snprintf's return, that would need rethinking.
<xnox> no, they don't. Where can I learn about overflow detection?
<infinity> Actually, I'm only assuming that sprintf gets covered by FORTIFY_SOURCE, but I suspect it does.
<infinity> Yeah, it does.
<infinity> Not that snprintf isn't still saner, but if they really want to be targetting C89, it makes some sense to fudge it...
<infinity> And fudging it by calling a function that may not be defined isn't the right answer. :P
#ubuntu-release 2013-01-05
 * slangasek targets C89 with ordnance
<xnox> =)))))
<infinity> xnox: You really need to get those extra chins looked at.
<infinity> slangasek: So, if the current quantal SRU is proven to fix the samsung bricking issue, should we respin ubuntu/quantal/amd64 with no updates except the kernel?
<infinity> slangasek: Normally not something I'd suggest, but I think cutting down on killing machines might be nice.
<infinity> slangasek: (If Samsung needs images to test, I can spin one over the weekend)
<slangasek> infinity: mmm, by the time we know the samsung fix is solid, we'll be close to the release date for 13.04; and "no updates except the kernel" is awkward to do, isn't it?
<infinity> slangasek: It's not particularly difficult to do with a few tweaks, I imagine.  I just don't want people continuing to download 12.10 media and bricking their machines. :/
<ScottK> We respun every single ISO, not just the LTS ones for 10.04.1 due to the openssl thing, so there's certainly precedent for bad enough for a post-release respin.
 * infinity hunts down the annoying "component-mismatches wants linux-{ac100,nexus7} in main" bug and fixes.
#ubuntu-release 2013-01-06
<micahg> in the new world of proposed, when fixing something broken in $devel-proposed, should -v be used for the version in the release pocket?
<cjwatson> micahg: I don't believe that's necessary
<micahg> ok, thanks
#ubuntu-release 2013-12-30
<ogra_> hmm, s2tc seems to break all of i386 (image builds)
<ogra_> (feels like haskellbuntu in here today :P )
<jpds> ogra_: Let me throw in some ipsec. ;-)
<ogra_> :)
<xnox> can php5/amd64 auto-package-test be retried? it seems to have failed to connect to the instance to run the tests
<cjwatson> xnox: retried (hopefully)
<cjwatson> xnox: also haskell-* appears to be out of your way now - I suspect I removed some things too early and gave p-m the opportunity to trade them off
<xnox> cjwatson: yeah, noticed accept emails, hence investigating where did icu go. Thanks a lot.
<xnox> yeah, all good.
<xnox> now hopefully britney will notice it =)
<xnox> still stuck on git-annex, haskell-dav & well http-client stack.
<jpds> Anyone know who I should poke for https://launchpadlibrarian.net/160694863/buildlog_ubuntu-trusty-ppc64el.unbound_1.4.21-1_FAILEDTOBUILD.txt.gz ?
<xnox> jpds: what do you mean? the package needs to use dh_autoreconf to update config.guess/.sub and libtool (if it's using that)
<xnox> jpds: same as thousands of other packages on that port.
<xnox> http://qa.ubuntuwire.com/ftbfs/ppc64el.html
<cjwatson> xnox: I fixed haskell-http-client in Debian earlier today - will be autosynced
<jpds> xnox: Ah, I didn't know that. So I add a build-dep on dh-autoconf ?
<cjwatson> It can be a bit more complex than that.
<cjwatson> That's a start ...
#ubuntu-release 2013-12-31
<nikogh> hello all, the current filezilla 5.3.5 in ubuntu 12.04 LTS precise has a bug with explicit FTP over TLS, limiting the maximum upload file size. The only workaround is to use unencrypted connections :(, but this is a security issue. The bug is already fixed in newer versions of filezilla since 3.6.0.2. The filezilla bug report ist here: http://trac.filezilla-project.org/ticket/7287. There are already some ppa's for newer versions (htt
<nikogh> p://ubuntuhandbook.org/index.php/2013/08/install-upgrade-filezilla-3-7-in-ubuntu-13-04-12-04-12-10/), but isn't it somehow possible to  bring the new filezilla client 3.7.3 to Precise?
<nikogh> via the official repositories of course ;)
<rbasak> nikogh: see https://wiki.ubuntu.com/StableReleaseUpdates. Short answer: a minimal patch that fixes the issue can go out in an update. For backports, see https://wiki.ubuntu.com/UbuntuBackports.
<nikogh> I've already read Backports and STU webpages, but I was not sure, whats the right way. :confused: What is a small patch? I guess a new version jump from 3.5 to 3.6 or above is too much right? So, I'll try now to request a official backport of filezilla. Any concerns?
<cjwatson> small patches are ones that fix only the issue at hand, not a load of other extraneous stuff
<cjwatson> version numbering is not the determining factor, but normally a full new upstream version will change lots of other stuff as well as the critical problem that actually needs to be fixed
#ubuntu-release 2014-01-01
<JackYu> happy new year, every one!
#ubuntu-release 2014-01-02
<cjwatson> xnox: I fixed a syntax error in python3.4_all_dev.ben that was breaking the transition tracker (unmatched parenthesis).  Just removing the unmatched paren produced something nonsensical, so I guessed a bit at what it actually was supposed to be from the most recent commit; please review
<xnox> cjwatson: looking. but it is actually doko__ who is growing number of underscores in his nick, and requesting that tracker.
<cjwatson> xnox: fine, but you were the committer :-)
<xnox> =))) touch-it-last strikes again...
<cjwatson> if you're doing it on behalf of somebody else then you can always mention their name in the commit message, or use --author, or whatever
<mlankhorst> poke, can someone accept all lts packages in NEW?
<xnox> doko__: excellent =) now who is going to port unity & nux to glew 1.10? =)
<mlankhorst> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<doko> xnox, sorry, didn't know the reason why it was kept back :-/
<xnox> doko: nevermind, i did the first round upload & nux/unity turned out to be trivial to fix =)
<xnox> doko: as soon as arm64 catches up.... i'll look into finishing it off.
<xnox> glew (42%) done as per transition tracker.
<infinity> rtg: ^-- Guessing we want that for 12.04.4?
<rtg> infinity, nah, its for v3.10+ kernels, e.g., the Trusty backport
<apw> rtg, saucy is 3.11
<infinity> rtg: Last I checked, saucy was 3.10+
<rtg> oh, dyslexia reigns supreme this morning
<rtg> infinity, lemme make really sure. I'll get back to you in  a bit.
 * infinity goes to find some back to work breakfast.
<infinity> rtg: Sure.  If we want it for 3.11, get someone to smoketest that the new files appear kinda sane and work with lts-saucy somehow, and we'll jam it through.
<rtg> infinity, ok, I've determined that the iwlwifi 7K and 3K firmware updates will definitely affect the Saucy LTS kernel. The Brocade bits should have no impact on v3.11
<zul> how does syncs get processed btw?
<infinity> zul: That question needs more context to know what you're actually asking.
<zul> infinity:  sorry i was talking about libvirt-python from debian
<xnox> zul: like so ^ =)
<zul> xnox:  yeah thanks
<infinity> zul: To be fair, it all would have happened automatically, if you waited for an autosync.  But yeah, if you sync something NEW explicitly, we need to process it like any other NEW package, except that we don't bother reviewing it if it's obviously a straight Debian sync.
<zul> infinity:  coolio
<utlemming> has the 13.04 EOL been announced yet?
<utlemming> All I've seen is that it is sometime in January, but no date.
<infinity> utlemming: D'oh.  I should have sent out an announce during the break, probably.  I'll get to that later today.
<mlankhorst> infinity: hey can you accept mesa binaries?
<mlankhorst> mesa-lts-saucy in precise
<infinity> mlankhorst: I'll look at all the LTS userspace stuff this afternoon if no one beats me to it.  Just dealing with kernels right now.
<mlankhorst> infinity: just accept the binaries, after that xorg-server can build and you can tell everything that's left to build :-)
<infinity> mlankhorst: Fiiiine.  Just had to make sure it was all destined for main first, etc.
#ubuntu-release 2014-01-03
<mlankhorst> can any archive admin drop xorg-server-lts-saucy? it needs to be re-uploaded, debian/patches/series is bugged
<mlankhorst> and xserver-xorg-video-ati/intel-lts-saucy
<cjwatson> done
<cjwatson> those were binaries that got rejected for xorg-server-lts-saucy - I hope that's what you meant
<mlankhorst> yeah I'll re-upload the borked stuff, debian/patches/series was emptied
<tjaalton> minor details
#ubuntu-release 2014-12-30
<darkxst> can someone give the gnome-photos autopkgtest a kick, I just ran it locally and it passed.
<cjwatson> darkxst: done
<darkxst> cjwatson, thanks
 * cjwatson does a mass retry of failed builds, since builders are quiet
#ubuntu-release 2014-12-31
<cjwatson> infinity: Were you planning to appoint another administrator of ~ubuntu-release?  I mentioned that suggestion in https://lists.ubuntu.com/archives/ubuntu-release/2014-November/003135.html
<infinity> cjwatson: Yeah, just haven't gotten around to it yet.
#ubuntu-release 2016-01-04
<infinity> teward: The release schedule it always anchored on Thursdays, which is why the last column points out if an event is non-Thursday.
<teward> ok
<wxl> infinity: do you have any sense as to when we'll be releasing on monday?
<infinity> wxl: Sometime fairly early in my work day, I assume, since testing seems to be going well.
<infinity> wxl: (My workday starts around 1600 UTC)
<wxl> yikes ok i'll be up all night infinity :)
<wxl> infinity: looks like we have release notes from everyone. most of our testing is done, though i know both flexiondotorg and i would like to do some more with ppc
<wxl> infinity: i should be up and about by 1500 or so
<flexiondotorg> wxl, I've marked Ubuntu MATE ready.
<flexiondotorg> All set with Release Notes here.
<flexiondotorg> wxl, These are my noteworthy bugs for Ubuntu MATE.
<flexiondotorg> I think they affect Lubuntu too.
<flexiondotorg>   * The cryptsetup password prompt is not shown.
<flexiondotorg>     * [LP: #1359689](https://bugs.launchpad.net/bugs/1359689)
<flexiondotorg>     * [LP: #1530548](https://bugs.launchpad.net/bugs/1530548)
<flexiondotorg>   * Shutdown/Restart of the live session does not work in Virtualbox, VMWave and KVM guests.
<flexiondotorg>     * [LP: #1447038](https://bugs.launchpad.net/bugs/1447038)
<flexiondotorg>   * The input box for editing a Wired connection static IP address doesn't appear correctly.
<ubot5`> Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
<flexiondotorg>     * [LP: #1530323](https://bugs.launchpad.net/bugs/1530323)
<ubot5`> Launchpad bug 1530548 in plymouth (Ubuntu) "passphrase input-box for encrypted disk is not shown" [Undecided,Confirmed]
<ubot5`> Launchpad bug 1447038 in casper (Ubuntu) "Shutdown/Restart of live session guest does not work in Virtualbox or VMWare" [High,Triaged]
<ubot5`> Launchpad bug 1530323 in network-manager-applet (Ubuntu) "The input box for editing a Wired connection static IP address doesn't appear correctly" [Undecided,New]
<xnox> seb128, could you please decruft mariadb-10.0, on s390x, in xenial-proposed? there are old binaries left from a supperseeded build.
<xnox> seb128, purge s390x mariadb-10.0 10.0.22-4 from xenial-proposed =)
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.0
<cjwatson> xnox,seb128: done
<rbasak> Thank you!
<xnox> hm.
<xnox> NBS report doesn't resolve alternative build-deps does it?
<xnox> e.g. i believe golang-blackfriday-dev is safe to remove.
<cjwatson> xnox: no, it's not totally clear what it would mean (it would have to be careful to avoid listing all alternatives as removable, for instance).  I agree golang-blackfriday-dev is OK, and done now
<xnox> tah. ok.
<infinity> wxl: Good morning.
<flexiondotorg> infinity, Morning
<flexiondotorg> wxl, o/
<infinity> flexiondotorg: Hey.  I'm going to start releasing soon, once I have an idea from you and wxl on the state of ppc images and if you want them released or not.
<flexiondotorg> infinity, I do want the PPC images released for Ubuntu MATE.
<flexiondotorg> I also tested the Lubuntu PPC mages for the Lubuntu guys and all looks good to me.
<flexiondotorg> Guess we need wxl to confirm that.
<flexiondotorg> Let me chase...
<infinity> flexiondotorg: Out of curiosity, what hardware are you testing on?
<flexiondotorg> iBook G4
<flexiondotorg> Which take f-o-r-e-v-e-r
<infinity> flexiondotorg: I want to do a change from yaboot to grub2 this cycle, but I need a smattering of 32-bit G4s and 64-bit G5s to test on.
<flexiondotorg> I can test on the G4.
<infinity> (And I own no Macs)
<flexiondotorg> I've seen the G5 are cheap on ebay.
<infinity> Well, not entirely true, I own a G3, but it can't use either bootloader. :P
 * Ukikie hides his G3.
<flexiondotorg> For example - http://www.ebay.co.uk/itm/Apple-I-Mac-G5-2GHz-PowerPC-5-1GB-RAM-160GB-HDD-A1058-17-2518-/252237748581?hash=item3aba8a9965:g:KTgAAOSwHaBWipNx
<infinity> flexiondotorg: Yeah, not likely to buy more computers just to test on. ;)
<flexiondotorg> I have 11 ;-)
<infinity> flexiondotorg: But if I can find enough community people with kit to be guinea pigs, that'll work.
<flexiondotorg> infinity, There is quite a PPC group on Ubuntu MATE.
<flexiondotorg> That are mostly on the Amiga X1000
<flexiondotorg> Which is modern.
<infinity> flexiondotorg: Oh, curious.  Is the X1000 openfirmare based as well?
<flexiondotorg> But I think they build their own kernel and initrd.
<flexiondotorg> infinity, I'd have to ask.
<flexiondotorg> infinity, Lubuntu team say yes to the PPC images.
<infinity> flexiondotorg: Alright.  I'll start the release dance, and wxl can send out the announcement when he pops in.
 * infinity clears the britney block.
<flexiondotorg> infinity, "Custom Open Firmware compliant firmware was used on the Pegasos2 made by Genesi."
<flexiondotorg> But
<flexiondotorg> "CFE used on the AmigaOne X1000 built by A-EON Technology."
<flexiondotorg> And
<flexiondotorg> "Das U-Boot used on the Sam440, Sam460 and AmigaOne 500 products from ACube Systems. U-Boot was also used by Eyetech for their AmigaOne-XE and MicroA1-C products and various developer boards."
<infinity> flexiondotorg: uboot?  Problematic indeed.  Some day, it might be nice to make those work out of the box, today's probably not that day.
<flexiondotorg> The guys running modern PowerPC workstations either have the AimgaOne X1000 or something based on the Sam440, Sam460 or AmigaOne 500 products.
<flexiondotorg> Is grub for Power8?
<infinity> flexiondotorg: grub *should* work for any OF-using system with OF >= 3.0
<infinity> flexiondotorg: So, G4 and up.
<infinity> flexiondotorg: But needs testing to confirm.
<flexiondotorg> OK, well I can test the G4 no problem.
<flexiondotorg> Just ping me.
<flexiondotorg> I guess my seeds will be changing to includ grub on PPC and exlcude yaboot etc/
<flexiondotorg> ?
<infinity> flexiondotorg: All I have is an IBM PPC970MP and an IBM POWER7 (and a POWER5, if I dig up sulfur), but nothing Apple, so yeah, will bug you for testing.
<flexiondotorg> No probs.
<infinity> flexiondotorg: Yeah, I'll do all the seed and installer changes after we've tested a bit.
<flexiondotorg> infinity, OK.
<flexiondotorg> Thats will be great.
<infinity> flexiondotorg: The early G4s are my biggest concern, since I think most of the grub2 OF work was originally done on a G5 (and then continued on IBM servers), so testing your G4 will help.
<flexiondotorg> Sure.
 * flexiondotorg is looking a G5 Power Macs now...
<infinity> flexiondotorg: Don't bother unless you really really want another space heater.
<flexiondotorg> Hah
<infinity> flexiondotorg: They were the fastest computers in the world (by a fair margin) when they came out, but time's not been kind to them. :P
<flexiondotorg> You're right of course.
<flexiondotorg> Everything is better with an SSD though.
<flexiondotorg> infinity, Well Ubuntu MATE is all set. And I "believe" Lubuntu is too.
<infinity> flexiondotorg: Yeahp, doing imagey things now.
<flexiondotorg> I've certainly been given the go ahead for Lubuntu PPC.
<flexiondotorg> Cool.
<wxl> sorry crazy weather this morning
<wxl> everything is covered in ice
<wxl> sounds like we went ahead so that's good
<infinity> wxl: I did the imagey bits, you still need to sort out the release announcement and send it out to -devel-announce/-release
 * infinity goes to find coffee/breakfast really quickly.
<infinity> wxl: No huge rush on that, but should happen in the next few hours probably. :P
<wxl> infinity: sounds doable thx
<flexiondotorg> infinity, Can you explain what sits behind the torrents are what it is that eventually makes them "go"?
<infinity> flexiondotorg: The tracker mirrors from the main cdimage mirror, then has to index the images before listing them.
<flexiondotorg> OK
<flexiondotorg> So there is one seeder initially?
<infinity> flexiondotorg: Yeah.  Though, I'd expect it to have picked them up by now.
<infinity> flexiondotorg: Oh, it seems to have.
<infinity> wxl: Easiest way is to go back 6mo in the -devel-release archives and copy-pasta the previous alpha 1 announcement, adjusting where needed. :P
<wxl> infinity: thx i was just going to ask about that
<infinity> wxl: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-June/001139.html
<wxl> even better XD
<infinity> wxl: handily, that even includes the three flavours participating this time, so you just need to remove the ones that aren't, change versions a bit, thwack my sarcastic quote at the top, and you're done. :P
<wxl> heh
<flexiondotorg> wxl https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-July/001144.html
<wxl> i'll include *my own* sarcastic quote, thank you very much :)
<flexiondotorg> infinity, So are the images sync in all the right places?
<flexiondotorg> s/sync/synced/
<infinity> flexiondotorg: Yep, all looks good to me.
<infinity> flexiondotorg: I always did love the irony of that Tesla quote.
<flexiondotorg> Yep.
<infinity> flexiondotorg: "No thrill can go through the human heart like [blah blah blah, touchy feeling inventor stuff]... OH AND 240 VOLTS."
<infinity> Okay, Alpha 1 marked as released in the tracker and dailies re-enabled for the participating flavours.
<infinity> wxl: Let me know when the announce goes out, so I can moderate it for you.
<flexiondotorg> infinity, Thanks  of rhelping us out.
<flexiondotorg> infinity, Any chance you can move caja-dropbox along in the NEW queue?
<wxl> infinity: worked on it on the bus ride, put out the first fires to appear at work, so should be on it in just a bit
<infinity> wxl: Alrighty.
<wxl> infinity: mod away
<infinity> wxl: You missed some s/wily/xenial/ edits.
<wxl> infinity: gosh darnit, i looked at it twice.
 * wxl needs gmail-vim
<wxl> will redo
<wxl> uh
<wxl> i did?
<wxl> vim does not seem to think so
<infinity> wxl: Editing in plain text might help...
<infinity> wxl: This is how it came out in the mod queue: http://paste.ubuntu.com/14402775/
 * wxl is
<infinity> wxl: Note all the 'wily' and 'Wily Werewolf' in there.
<wxl> oh the encoded links jeez
<infinity> Well, those shouldn't be there anyway.
<infinity> I'm guessing whatever you used to copy mine copied the links as links, which is broken.
<infinity> Should just copy/paste mine as plain text.
<infinity> And let mail clients linkify.
<infinity> ie: it should look identical to https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-June/001139.html in your editor (minus blue underlines)
<wxl> better now?
<infinity> wxl: That looks a bit less sketchy, other than the fact that it's text/html, but I can forgive that.
<infinity> I blame gmail. :P
<wxl> infinity: blame gmail.
<wxl> :)
<infinity> wxl: Accepted.
<wxl> infinity: thank you! sending out notices to lubuntu
<wxl> flexiondotorg: we're released officially
<flexiondotorg> wxl Thanks :-)
<wxl> i'm not sure how to get a hold of the kylin folks, actually. hope they're subscribed to devel-announce
<flexiondotorg> infinity, I see a number of MATE 1.12 packages are held in proposed.
<flexiondotorg> infinity, Is there a problem holding them up?
<flexiondotorg> Because all the important stuff like session manage and settings daemon are still 1.10 in the repos.
<flexiondotorg> Updating create a very busted system.
<infinity> flexiondotorg: I imagine it's mostly waiting on mate-settings-daemon?
<infinity> Ish.
<flexiondotorg> https://launchpad.net/ubuntu/+source/mate-settings-daemon
<flexiondotorg> Seems to be still build on arm?
<infinity> it's working on it.
<flexiondotorg> https://launchpad.net/ubuntu/+source/mate-settings-daemon/1.12.1-1/+build/8797712
<flexiondotorg> OK, only started a while ago.
<flexiondotorg> Cool.
<flexiondotorg> So everything will catch up.
<mapreri> umh, html in u-d-a@  (multipart, ok, at least)
<wxl> infinity: do you tweet perchance?
<infinity> mapreri: Yeah, blame gmail. :P
<infinity> wxl: Nope, I'm a cranky old man who doesn't believe in microblogging.
<infinity> wxl: Sadly, you'll never know what I had for dinner or when I go to the bathroom.
<wxl> darn
<wxl> i was just going to mention you, as i was getting ready to go to the bathroom XD
<xnox> wxl, awwww nice quote =)
<wxl> xnox: thx :)
<flexiondotorg> infinity, I remember that apport "disabled" somehow in 15.10 for a while. Is that the case with 16.04 at the moment?
<flexiondotorg> infinity, Also I see Xenial is syncing with unstable, will that remain so until FF?
<infinity> flexiondotorg: Not sure on the apport question, pitti's a better person to ask.  And syncing from unstable will continue until DIF/FF, yes.
<flexiondotorg> Thanks.
#ubuntu-release 2016-01-05
<tjaalton> infinity: so, libdrm is waiting in trusty upload queue since ~1mo, the rest has been staged in ppa:canonical-x/x-staging and could go in after libdrm
#ubuntu-release 2016-01-06
<lotuspsychje> !latest
<ubot5> Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so "latest" may not be a good idea. Post-release updates are only considered if they are fixes for security vulnerabilities, high impact bug fixes, or unintrusive bug fixes with substantial benefit. See also !backports, !sru, and !ppa.
<lotuspsychje> any triggers for latest packages here?
<LocutusOfBorg1> lotuspsychje, which package?
<lotuspsychje> LocutusOfBorg1: we were looking for libsdl 2.0.4 before
<LocutusOfBorg1> oh, what a coincidence
<LocutusOfBorg1> http://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-January/002272.html
<LocutusOfBorg1> it should be fixed in debian before
<lotuspsychje> mcphail: ^
<LocutusOfBorg1> actually I did the work http://anonscm.debian.org/cgit/pkg-sdl/packages/libsdl2.git
<LocutusOfBorg1> there is still two points to address, I hope my fellow Debian Maintainers will address them
<mcphail> LocutusOfBorg1: lotuspsychje: does this mean 2.0.4 is likely to come to xenial? 2.0.2 doesn't work with Mir properly
<LocutusOfBorg1> you can ping the other sdl maintainers on the mail I sent
<LocutusOfBorg1> maybe this can speed up things
<LocutusOfBorg1> I, for sure, won't upload it because just I have permissions, it needs a transition probably
<LocutusOfBorg1> and changes are quite large
<mcphail> LocutusOfBorg1: thanks. I'll keep poking. need to find out if all bschaefer's mir fixes have made it into upstream anyway
<mcphail> Would be a shame if a functional SDL missed LTS release
<LocutusOfBorg1> mcphail, the transition is quite large, so it needs to start ASAP
<LocutusOfBorg1> mcphail, it isn't Debian or Ubuntu fault if upstream took 2 years to release 2.0.4 :)
<lotuspsychje> LocutusOfBorg1: isnt there like a request url for packages?
<LocutusOfBorg1> lotuspsychje, what does it mean?
<mcphail> LocutusOfBorg1: ha!
<LocutusOfBorg1> no, there is a mail list, just ping it
<lotuspsychje> LocutusOfBorg1: well like mcphail here suggest sdl to be added
<LocutusOfBorg1> I imported on git as soon as it has been released (a few hours later)
<LocutusOfBorg1> now I need to have someone on pkg-sdl team to upload
 * LocutusOfBorg1 can upload it, but it needs coordination from -release team
<lotuspsychje> LocutusOfBorg1: so if someone wants a package added==mailinglist mail?.
<LocutusOfBorg1> there is already a debian open bug
<LocutusOfBorg1> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788688
<ubot5> Debian bug 788688 in libsdl2 "Please update to 2.0.3" [Wishlist,Open]
<cjwatson> LocutusOfBorg1: please don't start an SDL transition until perl 5.22 is out of the way
<cjwatson> oh autopkgtest, y u take forever
<LocutusOfBorg1> cjwatson, it won't start for at least a week, and according to what you said on -devel the perl should be done in a few hours :)
<cjwatson> LocutusOfBorg1: I'm certainly hoping so
<LocutusOfBorg1> I hope with you :)
<LocutusOfBorg1> BTW how can I help in vpx transition? it should be already started, and preventing virtualbox from migrate
<LocutusOfBorg1> do you have any single command for issuing rebuilds? I would like to avoid dget dch dpkg-buildpackage dput
<cjwatson> it'll be a lot less impossible to see what's going on with libvpx (and mostly everything else) once perl lands
<LocutusOfBorg1> yes, of course
<LocutusOfBorg1> I'm finding difficult to understand the log too
<cjwatson> http://irclogs.ubuntu.com/2015/12/22/%23ubuntu-release.html#t14:10
<LocutusOfBorg1> btw can somebody please accept hedgewars/*-backports?
<cjwatson> rebuild stuff
<LocutusOfBorg1> yes, I remember that log, but I don't keep logs on my pc, thanks
<cjwatson> you might have noticed that at the time but you were busy nitpicking about binNMUs ;-)
<LocutusOfBorg1> the problem is that I don't know an easy way to keep logs and find them ;)
<cjwatson> dunno how to do it in hexchat.  I configured irssi autolog years ago ...
<cjwatson> I also have http://paste.ubuntu.com/14421429/ as ~/bin/grep-ubuntu-irclogs, which is slow but functional in cases where it's for a channel I'm not routinely in
<cjwatson> (also makes quite a lot of requests ...)
<LocutusOfBorg1> lol wonderful!
<LocutusOfBorg1> cjwatson, http://paste.ubuntu.com/14422449/
<LocutusOfBorg1> what do you think about?
<LocutusOfBorg1> it should avoid the "codename release" issue, and avoid to hardcode the reason for the rebuild
<LocutusOfBorg1> I think I'll use this one
<xnox> cjwatson, well done =)
<xnox> i see perl migrating.
<mapreri> LocutusOfBorg1:         dch -R 'Rebuild for new '$2'.'
<mapreri>         sed s/UNRELEASED/$RELEASE/ -i debian/changelog
<mapreri> use `dch -D` instead of the sedding?
<slangasek> arges: hi, so I wonder about the self-accept etc. on bug #1513227, given that bug #1511347 was filed first :)
<ubot5> bug 1513227 in systemtap (Ubuntu Trusty) "systemtap ppc64el needs to build for trusty" [Medium,Fix committed] https://launchpad.net/bugs/1513227
<ubot5> bug 1511347 in systemtap (Ubuntu Trusty) "Feature request to enable systemtap on ubuntu 14.04.04." [Medium,Triaged] https://launchpad.net/bugs/1511347
<slangasek> arges: also seems to include changes (multi-arch) with no SRU bug or justification...
<slangasek> ah, I guess that piece goes hand-in-hand with the Architecture change
<LocutusOfBorg1> mapreri, seems legit
<arges> slangasek: the multi-arch change should have been explained better in the previous bug. So will including the patches from ibm fix it for ppc64el?
<slangasek> arges: that's my understanding, yes
<slangasek> arges: I'd assigned the bug to me, I'm happy to follow through with a 1.3 upload; or do you want to do it?
<arges> slangasek: I won't get to it today, so if you have time go ahead. otherwise i can put on my list for later this week
<slangasek> arges: ok I'll probably do it this afternoon then
<LocutusOfBorg1> mapreri, http://paste.ubuntu.com/14424960/
<LocutusOfBorg1> :)
<cjwatson> LocutusOfBorg1: I'm not taking patches to my ad-hoc stuff; if you want to run something a bit different then be my guest
<cjwatson> LocutusOfBorg1: but you don't need to tell me about it, nor do I really want to know :)
#ubuntu-release 2016-01-07
<cjwatson> LocutusOfBorg1: I'm uploading a stack of rebuilds for the libxpv transition now
<cjwatson> FYI since you were asking about it
<michi> Is anyone around how can help with publishing a silo?
<michi> cjwatson: ^ are you around?
<michi> I need someone to delete binary package for s390x for this: https://launchpad.net/ubuntu/+source/thumbnailer/2.3+16.04.20151102.2-0ubuntu1
<michi> It never should have been built in the first place.
<michi> We canât support this arch because gstreamer codecs donât work there.
<michi> Now the existence of this package is preventing publication of silo 26, and Iâm blocked on that for something else.
<infinity> michi: But it passed the testsuite in the previous build?
<michi> No, not really.
<michi> That was a lie.
<infinity> A lie?
<michi> Bascally, gstreamer codes for mp3 and mp4 do not exist on 390x
<infinity> 100% tests passed, 0 tests failed out of 21
<michi> At one point, I modified the tests to lie and just skip the mp3 and mp4 testing on s390x
<michi> Thatâs why they passed that one time.
<michi> Then jamesh, robru, and me discussed this.
<infinity> So, now it has rdeps.
<michi> We decided that we do not want to support 390 because, once the package is published, we canât regress, but we have no way to really make it work on that arch.
<michi> There are no 390 packages in the official archives, I believe.
<michi> We have not published since.
<infinity> Err, what?
<infinity> 21:14 < michi> There are no 390 packages in the official archives, I believe.
<michi> So we are not going to break anyoneâs dependencies by deleting this now.
<infinity> ?
<infinity> The official archive is what you're asking me to remove packages from. :P
<michi> Has this been actually published?
<michi> It shouldnât have been.
<michi> On a mainframe, no-one needs a thumbnailer.
<michi> The UI doesnât exist, there is no desktop, etc.
<infinity> You don't grasp how X works, I take it? :P
<michi> The whole 390 thing was simply a mistake on my part.
<infinity> People run X clients on mainframes.
<michi> And they listen to music collections on mainframes?
<infinity> Who knows what people do.
<michi> Look, we never meant to publish this.
<michi> It happened by mistake.
<infinity> Anyhow, "we don't think people will use it on this platform" is never an excuse.
<michi> we cannot support the thumbaniler on s390x.
<michi> If we publish for that, then we will publish packages that donât work when people try to use them.
<infinity> And they can't be fixed, why?
<michi> Because gstreamer does not work on s390x, no-one maintains codecs for that.
<infinity> Anyhow, it's been published since December.
<robru> michi: the build in the archive is not from your silo, it's from November 2
<michi> Steve Langasek made it clear that ubuntu touch packages do not need to pass on 390
<michi> Yes, robru, remember the discussion with james back then?
<michi> This was simply a mistake on my part and should never have happened.
<infinity> Touch packages are becoming desktop-next, and desktop should work on s390x eventually.
<robru> michi: yeah i do remember that unfortunately it's not up to me to remove it
<michi> The s390x builds were added to the silos without anyone telling us.
<infinity> I'm not arguing against removing it *for now*, I'm arguing against the "we can't possibly fix it" POV.
<michi> Then, before we got more tight on our tests, the thing slipped out.
<michi> The tests originally didnât detect that failure at all
<michi> Then I made the test pass at one point by lying to the testing harness.
<infinity>   * Ignored failing tests on PPC due to gstreamer problems.
<michi> infinity: Well, no-one here at Canonical can fix the codecs.
<infinity> Is that for the same issue?
<michi> infinity: yes.
<infinity> If so, it sounds like it's a big-endian issue.
<infinity> Nothing to do with mainframes.
<infinity> Just bad math somewhere.
<michi> Similar problems, because the gstreamer codecs fall over on PPC
<michi> We have no interest in publishing the thumbnailer for things that are not on the phone.
<infinity> Anyhow, if you're ignoring it on one arch, why not on both?
<michi> It has exactly one customer, which is the software on the phone.
<michi> infinity: I can do that.
<infinity> Think to the future.  Right now, it's the phone.  Eventually, it'll be the desktop.
<michi> Except that weâll be obliged then to keep publishing for s390x.
<michi> I know.
<michi> And it wonât be on the desktop unless someone fixes the codes where they are broken.
<michi> Which isnât our job.
<infinity> And if we had that attitude, we'd never be ready for arm64 phones either (oh, wait...)
<michi> infinity: Well thatâs an entirely different kettle of fish.
<infinity> Same fish.
<infinity> Same attitude.
<michi> We have had repeated arm64 test failures too, due to bugs in components we have no  control over.
<infinity> "No one cares about !armhf, cause that's the phone".
<michi> No, I actually care a lot.
<michi> But I canât make software work on a machine that I have no access to.
<michi> We have no arm64 hardware to work on.
<infinity> Anyhow, if you're ignoring some tests on PPC for now, I recommend ignoring them on s390x too, make a big note that it's almost certainly an endian issue, and file a gstreamer bug to investigate further.
<michi> The porter boxes cannot be used because they are not available with the overlay
<infinity> No one's forcing you to investigate, but a bug would be nice for reference.
<michi> I would be much happier if we could just delete the archive.
<michi> It was never meant to be published for 390.
<michi> This only happened by mistake.
<infinity> Like I said, it has rdeps, I'd really rather just let it be.
<michi> So, you are recommending that I make the tests lie for 390 too?
<infinity> michi: I recommend you make s390x and powerpc both skip the same test for now and file a gstreamer bug, yes.
<michi> OK. So, what is the correct procedure then?
<michi> silo 26 has been approved by QA.
<michi> Now I need to make change.
<michi> How do I do that?
<infinity> Endian bugs are often bad math that comes back to bite you anyway, so worth looking at at some point.
<michi> Trust me, I have plenty of experience with endian bugs, and they donât happen in my code...
<infinity> michi: No idea what the silo procedure is.  I'd just fix it in the archive if it were me. :P
<michi> So, whatâs the right process to follow now?
<michi> We cannot get things into the archive without going through a silo because this is for touch.
<michi> And we are about to miss ota 9
<infinity> michi: But I assume you want to reupload to the silo, and skip QA if there are no code changes, only packaging/testsuite tweaks.
<infinity> robru: ^?
<michi> And round and round we go.
<michi> Ah, that seems feasible.
<infinity> michi: Sorry, not trying to be a dick here, and get your POV today.  But, on the other hand, while a thumbnailer on s390x might not be something someone wants this year, gstreamer being busted is a big problem for a server, potentially.
<infinity> (server side re-encoding, etc)
<michi> Sure, I take your point.
<infinity> So, best to make sure the bug is known and someone's looking at it than to just say "anything using gstreamer can't work on s390x".
<michi> I also agree with you, in the sense that we shouldnât just let shoddy software go.
<infinity> michi: Anyhow, if you file the bug (after you sort out your silo -- priorities), I can make sure it gets some eyes.
<michi> Itâs just that this is not our software and that, for components that run only on touch, we were told explicitly by slangasek that we do not need to pass on 390
<infinity> michi: And if we fix it, you can stop skipping tests, and everyone wins.
<michi> Not holding my breath.
<robru> infinity: not sure what you're asking me. Yes silos are fit touch landings and they build s390x if applicable
<michi> The gstreamer codecs are a complete train wreck in many cases.
<infinity> michi: Sure, he's not wrong.  You're not expected to have all your existing software start working.  But you're expected to not have regressions.  I get that this regression is a weird corner case, but.  Meh.
<infinity> robru: No, I was asking you if he can fasttrack and skip QA if he does a quick reupload with no code changes, just the testsuite tweak.
<michi> yeah, well, except for the accidental publication, itâs not a regression.
<infinity> michi: There was on accidental publication, it was built in the archive.
<michi> robru: if I could do that, it would make a huge difference.
<infinity> s/on/no/
<robru> infinity: sorry i didn't read all the backlog. Did you guys decide to go back to skipping tests or something?
<michi> Disabling the tests for 390 is trivial.
<michi> Yes
<infinity> robru: He already skips tests on PPC for the same issue.  Makes no sense to be inconsistent there.
<robru> Ooh OK
<infinity> michi: Would be better if you only skipped the one failing test instead of the testsuite, but not going to be picky when you're on a deadline.
<robru> Yeah if it's a trivial change i guess it's fine to skip qa but you do have to smoke test it to make sure nothing blows up
<michi> Itâs thoroughly smoke tested.
<michi> Will test again, no problem.
<robru> michi: i mean a new build will need a new smoke test
<robru> K
<michi> So, should I add this change to the existing MR, or add a separate MR?
<michi> And once Iâve done that, how do I get the silo published?
<infinity> michi: Thanks for putting up with my pedantry.  And please do file the gst bug and point it at me after you've re-landed.
<michi> Wonât the QA approval revert?
<infinity> michi: I can land it with force if no one's around to do it properly. :P
<michi> infinity: Will do. Thanks for your help!
<robru> michi: the qa field doesn't change unless somebody changes it
<infinity> michi: (ie: I can copy to the archive and let robru pick up the pieces)
<michi> Any recommendation as to a separate MR or just commit to the existing branch?
<robru> infinity: the train detects that case and acts accordingly, nothing to pick up on my end
<infinity> robru: ^-- Your machinery, what does he have to do?
<robru> michi: either is fine, whatever you want
<infinity> robru: Oh, nice, if I do the copy out of band, it'll record the silo as landed and free it?
<michi> robru: Cool, thanks!
<robru> infinity: yup
<infinity> robru: Shiny.
<robru> michi: you're welcome
<robru> infinity: it's slowly beginning to not suck so much ;-)
<infinity> robru: Sadly, lack of suck almost always goes hand in hand with increased complexity.  I bet I don't want to know HOW it doesn't suck, do I? :)
<michi> robru, infinity: silo is rebuilding now.
<michi> The train is bloody awesome.
<michi> Itâs really easy to drive. I like it.
<robru> infinity: it pings the archive every 15 minutes on every silo to check if anything has changed and if it detects the version in archive has same hash then it merges ;-)
<infinity> robru: Oh, sure, I meant the overall lack of suck.  Each individual feature always looks elegant in isolation (or should), but when it's all put together, strong men weep and children run screaming.
<infinity> At least, this is what I've learned over the decades of system architecture.
<robru> infinity: i didn't even make this feature on purpose, i wrote a status poller to make sure that new archive uploads didn't invalidate our builds, then i was like "wait, it's now trivial to also detect manual copies"
<robru> Yeah
<michi> infinity: Looking through the build log...
<michi> _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root.
<michi> s390x is misconfigured in the silo, by the looks of things.
<infinity> That shouldn't even be in the chroots.  Lemme look if I oopsed.
<michi> We are running a test that uses xvfb to test that thumbnails have the right contents.
<michi> Weâve seen this before on some of the arm builders.
<infinity> Oh.  If you've seen it before on some builders sometimes, then it's not the builder's fault. :P
<infinity> Since they all use the same chroots.
<infinity> And indeed, that file isn't in the s390x chroot.
<infinity> So it's a race in the process somewhere.
<michi> Well, itâs not anything we can fix.
<michi> thatâs totally out of our control.
<michi> We just run xvfb
<infinity> I suspect that's always in the log file.
<infinity> And a red herring.
<michi> So, the dir is missing completely?
<michi> No.
<infinity> But you only see it on failures.
<infinity> 9: FAIL!  : Thumbnailer::Photo::test_rotation_scaled() Unexpected pixel value at (0, 0)
<michi> Donât think so.
<infinity> 9: actual:   #000000
<infinity> 9: expected: #FE0000
<michi> Right.
<infinity> That sort of thing being the real failure, I'd assume.
<michi> The thumbnailer painted black.
<michi> No, this is not a real failure.
<michi> It fails because xvfb canât display the image.
<michi> On the previous failures, we got this problem because the ownership of that dir was wrong.
<michi> Does the dir exist for 390?
<infinity> The directory doesn't exist at all in the chroots.
<infinity> I just checked.
<infinity> So it comes about at runtime.
<michi> It needs to be there, I believe.
<michi> Owned by root.
<michi> If itâs not owned by root, xvfb fails.
<michi> Doesnât paint anything, and we read a zero pixel value.
<infinity> It's not there in the x86 chroots either.
<michi> Aha.
<michi> So it should be created on the fly then.
<infinity> Yes.
<michi> I have no idea why thatâs not happening.
<infinity> Anyhow, we can look at the why later.
<michi> Cool, thanks!
<infinity> For now, get your quick fix through.
<michi> Itâs building as we speak.
<infinity> Ahh, so it is.
<infinity> Oh, curious that ppc64el is in that list too..
<michi> H 264 codec broken.
<infinity> 100% tests passed, 0 tests failed out of 24
<michi> From memory.
<infinity> Or it doesn't need to be in the list anymore.
<michi> Yes, because we lie, as I said.
<infinity> Heh.
<michi> See debian/rules
<infinity> Yeah.  Should definitely revisit all of this shortly.
<michi> BAsically, we still build and run the tests, but ignore the failures.
<infinity> No, I'm saying that ppc64el no longer has failures.
<infinity> ppc and s390x have 1 failure that you ignore.
<michi> Ah, itâs working suddenly?
<infinity> ppc64el has 0, but you still ignore. ;)
<michi> Thatâs the problem with ignoring stuff.
<infinity> But also, don't fix that right now.  Deadlines and all.
<michi> you donât notice when it breaks and starts working again :(
<infinity> And I agree.  Ignoring sucks.
<infinity> Happy to help hunt and fix when it's not 10pm.
<michi> What a mess.
<michi> the problem with PPC is the same old one:
<michi> None of us has access to the hardware, so we canât debug anything.
<infinity> That's not true.
<michi> How are we supposed to make things work without hardware to do it with?
<michi> How so?
<infinity> We have PPC porters.
<michi> They donât work, I tried that.
<michi> None of them is available with vivid + overlay
<infinity> But you're also building for xenial.
<michi> Yes, so?
<infinity> So you could fix the bug on xenial...
<michi> Just because it works on xenial doesnât mean that itâll work on vivid.
<michi> At least in theory.
<michi> Well, I certainly canât fix the bug myself.
<infinity> But overlay literally only matters for armhf.
<michi> Donât have the expertise to fix gstreamer codecs.
<michi> We discussed all this at great length with slangasek.
<michi> The whole gstreamer story is a disaster.
<michi> We have a kernel bug on arm that causes gstreamer processes to spin at 100% CPU.
<michi> They spin in the kernel, and a kill -9 wonât kill them.
<michi> I opened a bug for this months ago.
<infinity> Huh.  Fun.
<michi> tvoss pushed reallly hard to get it fixed.
<michi> No-one is interested.
<infinity> On all kernels, or just some of the icky Android kernels?
<michi> Android.
<michi> The problem is somewhere with the low-level Android media stack.
<infinity> Yeah.  We can't support most of the Android stuff.  Which is a whole extra mess. :/
<michi> And, presumably, some driver is spinning at uninteruptible priority somehwere.
<michi> We had months of serious grief working around all the problems.
<infinity> michi: Your PPA is all built for !armhf, if you intended to smoketest on x86 or something.
<infinity> (armhf is catching up)
<slangasek> michi: so anything that we discussed, I would have been very clear in expressing that the packages should be fixed in a way (i.e. by dropping architectures from the source packages, and by handling removals of any reverse-dependencies that thereby become uninstallable) that does not require ongoing manual intervention from archive admins
<michi> On arm, we have disabled concurrency for gstreamer pipelines because, as soon as there is more than one running at a time (in different processes, mind you!), things go belly-up.
<michi> slangasek: The whole 390 publication thing was a huge mistake and basically happened by accident.
<slangasek> because the tests gave a false positive and were later fixed
<michi> Way back, we had a test suite that wasnât anywhere near as thorough, and didnât test mp3 and mp4 at all.
<infinity> You keep saying that, but you didn't publish on s390x at all, we did.
<slangasek> so yes, always-failing tests can be ignored
<michi> Well, the problem is that the s390x thing slipped through completely behind our backs.
<michi> Because s-jenkins doesnât build on s390x.
<michi> So, nothing in our process alerted us to the new architecture.
<michi> the silo just built and things worked because they werenât tested.
<michi> then I tightened the test suite.
<slangasek> right
<michi> Found out about the build failure only when the stuff hit the silo.
<michi> then made the tests lie for s390x
<michi> After discussion with robru and jamesh, I backed that out again
<michi> Because of your comment in the email you sent that we canât regress.
<infinity> Anyhow, the current hack works for now.  I'm happy to throw someone as investigating the "why" because while no one cares about thumbnailers, we should care about gst.
<michi> But, by then, the thing was published already.
<michi> Thatâs my best recollection of the sequence of events.
<infinity> michi: It was built in the archive, no one accidentally published anything.
<michi> We have a *huge* problem with the s-jenkins and silo story.
<michi> Because the silos build on arches that s-jenkins doesnât build on.
<michi> That means we find out about problems only at 5 minutes to midnight.
<michi> Or even not at all.
<michi> infinity: I donât really know what that even means.
<michi> We build in the silo. The silo pushes to trunk, then the archive publication machinery picks it up from there.
<infinity> michi: it means that two months after it was published, it built on s390x in the archive because we added a new arch and *all* packages were tried.
<michi> In that case, it most likely built in the silo for 390 without anyone of us even noticing.
<michi> And passed the tests only because the failing parts were not tested.
<infinity> Sure.
<infinity> As Steve points out, though, adding a new test that fails isn't a "regression" in general QA terms.
<michi> I see.
<michi> Hmmm...
<infinity> Fixing it would be nice, but ignoring it is also valid while the fix is hard.
<michi> But I still have to lie, donât I? Because, otherwise, Iâll never get the silo published.
<infinity> (GCC and glibc run into this all the time, we create tests for things we *want* to fix, then get around to fixing them :P)
<michi> Wow :)
<infinity> michi: Right, you have to lie to the testsuite (or invent an XFAIL), and then we sort things.
<michi> Well, I guess Iâm lying thoroughly now. Because no matter what breaks on s390x, itâll claim it worked.
<michi> I will go back and make that more selective
<slangasek> infinity: when I spoke of regressing, I was referring to the archive being unhappy with dropping an architecture once built and test-passed, without manual intervention
<infinity> slangasek: Right, that more or less matches my definition, just in project terms instead of archive terms.
<michi> silo has âsuccessfully buildâ s390x now :)
<michi> *built*
<infinity> slangasek: But, basically, if a new test fails and it would have failed on the previous successful build, it's not a regression.
<slangasek> sure
<michi> infinity: Good point. Otherwise, it gets rather hard to improve the tests.
<slangasek> but autopkgtest expects the test *suite* to pass
<slangasek> adding a test to the testsuite that fails, and uploading that to the archive, doesn't help us
<infinity> michi: I don't subscribe to the new world concept of TDD much, but for glibc, it's worked wonders to do things like "we want to clean up POSIX compliance in all our headers, we'll write a testsuite that checks how awful we are and then iterate".  Cause on projects that large, something like that can be a 2-year process.
<slangasek> unless you XFAIL it, as mentioned
<infinity> michi: So, yeah, we had to learn to XFAIL quite extensively to make the results usable. :P
<michi> Seems like everyone is lying ;)
<michi> Itâs all an illusion anyway...
<infinity> And, in the toolchain world, you always have things like "well, the kernel just plain can't do this yet on $arch, and someday we'll hook up the syscall" sorts of XFAILs too.
<infinity> testing is messy.
<michi> Itâs also saved my arse more often than I can count.
<michi> I think Iâll marry my test suite, actually.
<michi> It has saved me more often than my wife has by now ;)
<infinity> She might not be cool with this plan.
<michi> I like my test suite better anyway ;)
<infinity> Ouch.
<michi> just kidding...
<michi> Iâve been married for 32 years. Iâm allowed to say such things.
<infinity> Well, you're in QLD, hard to tell.
<michi> Ouch. :)
<infinity> You haz armhf binaries now too.
<infinity> robru: If you're still around, you going to push michi's buttons for him after he smoketests, so he can stop panicking?
<infinity> robru: If I get no reply, I'll stick around and do the manual copy for him instead.
<michi> I just tried publishing and was refused.
<michi> I donât have privileges.
<robru> infinity: yeah I'm off today so if you could copy that's be great
<michi> robru: My pretty all blue silo page has just gone all red again, because I tried to publish and wasnât allowed to...
<michi> Do I need to kick off yet another build?
<michi> I need this to merge into trunk.
<robru> michi: why would you need to build again? Did you push a new commit?
<michi> No. Itâs just all red now, complaining about the missing publish permission.
<robru> michi: that'll go away on its own
<michi> Sweet.
<infinity> michi: Just let me know when you've checked for magic smoke, and I'll take care of the rest.
<michi> Iâve already tested locally with this change.
<michi> And seeing that I canât test s390x binaries on a Nexus 4, I think we are good to go.
<infinity> michi: I think robru was implying it's the binaries in the PPA that need smoketesting.
<infinity> michi: Obviously not the s390x ones. :)
<michi> They are tested already to death, as in 30 minutes ago.
<robru> Yeah since they were rebuilt we just want to confirm that nothing broke due to build flakiness or something
<michi> And the previous few hours.
<michi> Ah.
<michi> Give me five please...
<infinity> Sure.
<infinity> Just poke me when you're done, I'll be around.
<michi> Make that a bit more, 20-30.
<michi> Oh Christ...
<michi> I flashed the phone with the latest rc-proposed, and now it doesnât boot anymore.
<michi> infinity: How much longer will you be around?
<infinity> michi: Couple of hours.
<michi> Iâll try an reflash from the boot loader.
<infinity> michi: I'm in no rush, just trying to be helpful since I made you go through this effort. :P
<infinity> michi: I'll be kicking around doing !work things and checking in here and there.
<michi> I do appreciate that!
<michi> Itâs sometimes kind of lonely, given the timezone Iâm in.
<infinity> michi: Yeah, I found that when I lived in Melbourne.  I fixed it by being awake 23h/d.
<michi> Itâll take half an hour to download the latest image.
<michi> How nice...
<michi> infinity: Mirv helped me out and has just pressed the publish button.
<michi> Heâs done the smoke testing.
<infinity> michi: Shiny.
<michi> I just got my phone back to life after bricking it.
<michi> Doing more testing now too, just in case.
<michi> Thanks again for stepping in to help!
<LocutusOfBorg1> thanks cjwatson :)
<tjaalton> infinity: so, should I just start uploading lts-w though libdrm is still in the queue?
<infinity> tjaalton: Does it all have a versioned build-dep on the new libdrm?
<infinity> (either declared or undeclared...)
<tjaalton> infinity: just the ones that need it
<infinity> tjaalton: Hold on.  Lemme try to review this a bit.
<infinity> tjaalton: The changelog and the package don't agree...
<infinity> http://paste.ubuntu.com/14429036/
<infinity> tjaalton: Changelog claims you dropped the revert patch, but it's clearly still there.
<tjaalton> huh, so it seems
<infinity> tjaalton: That said, if that .symbols change goes with it, I would say you need that patch.
<infinity> tjaalton: And I question how we let upstream get away with this in later versions. :P
<infinity> libdrm2 is not libdrm2 anymore if it dropped a symbol.
<infinity> tjaalton: Anyhow, please either fix the changelog to match reality or reality to match the changelog, and explain why you chose the option you did. :P
<apw> infinity, is that the entire diff, if so there is nothing left if you drop that patch too ?
<tjaalton> infinity: I'll figure it out
<tjaalton> been 1,5mo since that :)
<infinity> apw: Well, yes, but it's a backport, so what would be left is the changelog.
<apw> infinity, right, but the changelog also says there is a change to control
<infinity> apw: In the previous backport, not this one.
<apw> point
<tjaalton> infinity: apparently they were only used internally
<tjaalton> within libdrm
<infinity> tjaalton: Then why revert the commit in the past?
<tjaalton> can't remember
<infinity> tjaalton: Possible, perhaps, that an older version of X or some X driver abused that symbol?
<tjaalton> I'll grep through the driver trees
<infinity> tjaalton: And we need it to run trusty X/drivers with the backported librm?
<infinity> libdrm, even.
<infinity> tjaalton: Anyhow, seems safest to me to maintain that status quo, even if you can't find the original reason.
<infinity> tjaalton: Though, no need to have the rest of that commit reverted, it's really just the visibility of the symbol that you're worried about.
<tjaalton> right
<rbasak> Could someone remove the php-fpm binary from xenial-proposed please? It's blocking the proposed migration of php-defaults 21 I think, which no longer builds that binary. I'm not sure we want to commit to php-7.0 in Xenial yet, but I think it would be easier see that other things aren't blocking proposed migration if/when we attempt to move across, and presumably we can always delete it from the rele
<rbasak> ase pocket later?
<cjwatson> rbasak: removed
<LocutusOfBorg1> can anybody please make arrayfire migrate?
<LocutusOfBorg1> discarding the armhf pkgtest failure?
<rbasak> cjwatson: thank you!
<stgraber> micahg, Laney: so LXD 0.25 didn't make it to trusty-backports before 0.26 was tagged. I've now rejected 0.25 from the queue and uploaded a 0.26 backport. Would be great to have this accepted soon-ish as trusty is quite a bit behind!
<Laney> stgraber: sorry, I forgot if you pinged me about it
<Laney> If micahg doesn't get to do it then feel free to self accept IMO
 * Laney wants to move towards more self service backports anyway
<stgraber> yeah, being allowed to self-accept backport updates, so long as the delta remains identical would be nice
<stgraber> makes a lot of sense to have the backports team review new packages and new packaging delta when needed, but it quickly becomes a lot of work if reviewing every other package update
<Laney> We're not a very efficient bottleneck right now
<Laney> micahg does do more uploads than me to be fair
<barry> infinity or slangasek: could you promote lazy-object-proxy? LP: #1531033?
<ubot5> Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-proxy is new dep for main package pylint" [Undecided,Fix committed] https://launchpad.net/bugs/1531033
<slangasek> barry: done
<barry> slangasek: thanks!
<infinity> tjaalton: Still around?
<infinity> tjaalton: If I was being picky, I'd suggest that you should also keep the s/void/char/ bugfix in that "revert".
<infinity> tjaalton: ie: the only thing the patch should do is 's/^static //'
<tjaalton> infinity: ok, reject and i'll upload a new one tomorrow
<tjaalton> although, that was never in a header so not part of public api
<tjaalton> dunno why i kept it
<tjaalton> last time
<infinity> tjaalton: Not in a header doesn't prevent someone from using the symbol.  Just makes it harder.
#ubuntu-release 2016-01-08
<micahg> stgraber: sorry, I'll take a look either later tonight or over the weekend
<stgraber> micahg: thanks!
<michi> infinity: Trying to do my duty and put together a gstreamer bug.
<michi> Building in silo 7 at the moment.
<michi> Interesting failures again.
<michi> Itâs no longer the gstreamer codecs, it seems.
<michi> powerpc also failed with the /tmp/.X11-unix dir not being owned by root
<michi> Also, the gstreamer error only happens on Vivid.
<michi> It looks like the codec was fixed some time after Vivid.
#ubuntu-release 2016-01-10
<infinity> tjaalton: Your new libdrm is in, BTW, if you want to flood the queue with other bits ASAP.
#ubuntu-release 2017-01-02
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.20.1 => 2.20.1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.20.1+16.10 => 2.20.1+16.10ubuntu1] (desktop-core, ubuntu-server)
#ubuntu-release 2017-01-03
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu0.14.04 => 14.12-0ubuntu1.14.04] (ubuntu-desktop, ubuntu-server)
<bladernr> Hey gang... Happy New Year!
<bladernr> Question... who is responsible for moving release images from releases.ubuntu.com to old-releases.ubuntu.com?
<cjwatson> bladernr: https://wiki.ubuntu.com/EndOfLifeProcess
<cjwatson> I think infinity normally does that these days
<bladernr> cjwatson, ahhh, thanks.  I'll ping infinity then.  I see where it's supposed to occur in the link, thanks for that!
-queuebot:#ubuntu-release- New sync: akonadi4 (zesty-proposed/primary) [1.13.0-11]
<mvo> can someone review/approve the snapd uploads to yakkety-propsed/xenial-proposed? trivial diff, should fix the autopkgtest failures we are seeing right now
<mvo> (someone from the SRU team)
<mvo> please :)
-queuebot:#ubuntu-release- New: accepted akonadi4 [sync] (zesty-proposed) [1.13.0-11]
<apw> mvo, looking
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.20.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.20.1+16.10ubuntu1]
<mvo> apw: \o/
<mvo> apw: thank you!
<mvo> apw: and happy new year :)
-queuebot:#ubuntu-release- New binary: cmor [ppc64el] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [amd64] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [i386] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [arm64] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [s390x] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [armhf] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cmor [powerpc] (zesty-proposed/universe) [3.2.1-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted cmor [amd64] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [armhf] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [powerpc] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [s390x] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [arm64] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [i386] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [ppc64el] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [arm64] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [ppc64el] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [armhf] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [s390x] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [i386] (zesty-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- New: accepted cmor [powerpc] (zesty-proposed) [3.2.1-4]
-queuebot:#ubuntu-release- New: accepted cmor [amd64] (zesty-proposed) [3.2.1-4]
<lamont> RAOF: holler when you're around, re: bug 1519836
<ubot5`> bug 1519836 in grub2-signed (Ubuntu Xenial) "MaaS fails to boot Hyper-V Generation 2 virtual machines" [High,Fix committed] https://launchpad.net/bugs/1519836
<lamont> RAOF: only haha it won't be tuesday for you, will it?
<slangasek> lamont: I think the SRU schedule is written such that he's covering "Tuesday", not Tuesday ;)
<slangasek> (i.e. I believe that on Wednesday he covers our Tuesday)
<lamont> oh, awesome
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.20.1+16.10ubuntu1 => 2.20.1+16.10ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New sync: aufs (zesty-proposed/primary) [4.8+20161219-2]
<valorie> question: I see queuebot to #ubuntu-release- New: accepted akonadi4 [sync] (zesty-proposed) [1.13.0-11] -- why?
<valorie> why sync a "KDE4" package, when we (kubuntu) have packaged and uploaded the current version for Zesty?
<valorie> slangasek: ^^^
<nacc> valorie: sorry, i only see the one version of akonadi4 in the publishing history?
<nacc> https://launchpad.net/ubuntu/+source/akonadi4/+publishinghistory
<valorie> we don't want or need akonadi4
<valorie> does someone else need it?
<slangasek> valorie: because it showed up in the auto-sync log as something that couldn't be handled automatically, and a review of the packaging showed they were equivalent
<valorie> hmmm
<slangasek> valorie: is there a reason to want the diverged version of it?
<valorie> ok, there will be a few old versions that show up like that I guess
<valorie> "diverged"?
<valorie> old=kdelibs, new=frameworks5
<slangasek> the only real difference between the akonadi1 source package that was already in the archive, and the akonadi4 source package from Debian that was building the same binaries, was the source package name
<valorie> for libraries
<slangasek> so I synced akonadi4 and dropped akonadi1
<valorie> which is why we uploaded the *new* version
<valorie> and have been waiting for our uploads to be accepted
<valorie> meanwhile old stuff gets synced instead
<valorie> which is very frustrating to us
<slangasek> valorie: er, there is nothing waiting in the NEW queue
<valorie> um
<slangasek> so I don't know what you mean by "waiting for our uploads to be accepted"
<valorie> kubuntu packagers please speak up!
-queuebot:#ubuntu-release- New: accepted aufs [sync] (zesty-proposed) [4.8+20161219-2]
 * tsimonq2 strolls in
<valorie> slangasek: I've been running zesty for 6 weeks or so, and eagerly waiting for all the stuff I've tested to show up
<tsimonq2> um
<valorie> afai recall, it was uploaded weeks ago
<tsimonq2> Hold on here...
<acheronuk> valorie: we have not uploaded new apps (including akonadi) for zesty yet
<valorie> oh
<valorie> sorry for the noise then
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: wxwidgets3.0 (xenial-proposed/universe) [3.0.2+dfsg-1.3 => 3.0.2+dfsg-1.3ubuntu0.1] (kubuntu)
<slangasek> meanwhile, all I was working on there was driving down http://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<acheronuk> frameworks, yes. plasma, yes. apps, no. though they are being staged to be ready
<slangasek> for the purpose of changing the behavior of autosyncing wrt previously-published packages
<tsimonq2> ]  * Rename source to akonadi1 from akonadi
<tsimonq2>     + This is now a transitional source to allow kde4pimlibs applications to
<tsimonq2>       install
<valorie> bah, last thing I wanted to do was discourage hard-working release team members
<valorie> sorry, slangasek
<slangasek> :)
<slangasek> no worries
<tsimonq2> slangasek: You said akonadi1 = akonadi4 then?
<slangasek> tsimonq2: yes
<tsimonq2> O_o
<slangasek> just a different source package name in Debian vs. Ubuntu, now reconciled
<tsimonq2> So akonadi1=1.13.0-8ubuntu1 is the same as akonadi4=1.13.0-11 then?
<tsimonq2> Interesting...'
<tsimonq2> slangasek: And yes, what valorie said, thanks. :)
<tsimonq2> slangasek: While you're here, who's the best person to poke about systemd-resolved doing a belly flop and breaking things?
<tsimonq2> (seeing that pitti is gone)
<slangasek> tsimonq2: you can use me as a starting point for that
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.20.1+16.10ubuntu2]
<tsimonq2> Grr, I can't find this thing...
<tsimonq2> slangasek: bug 1647031
<ubot5`> bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
<wxl> any hope of getting our ubiquity problems fixed while we're fixing things? :(
<lamont> could someone process the grub2-signed and grub2 xenial SRUs from -proposed to -updates?
<lamont> pretty please?
<slangasek> lamont: done
<slangasek> wxl: is there a bug number for that?
<lamont> slangasek: tg
<lamont> ta even
<wxl> slangasek: bug 1650767
<ubot5`> bug 1650767 in ubiquity (Ubuntu) "kubuntu zesty 17.0.4.1 installation fails (2016-12-16 image)" [Critical,Triaged] https://launchpad.net/bugs/1650767
<wxl> slangasek: cyphermox said he would upload a fix and then disappeared, so.. i'm not even sure he knew what the solution was to be frank.
<wxl> slangasek: we may wish to participate in alpha2, so if we could get it fixed this month, that would be nice :)
<slangasek> wxl: ok; I believe cyphermox may be out this week still, so perhaps he'll have a chance to look at it next week
<wxl> slangasek: does anyone KNOW when he'll be back?
<slangasek> wxl: fwiw "kubuntu can't install" ought to be considered a showstopper; I would love to see this tested via autopkgtest before whatever broke it broke it in zesty, instead of alpha2 being the driver
<slangasek> (since if we do that right, we can also stop worrying about alphas altogether)
<valorie> to be fair, our driver is that our daily ISOs can't be installed right now
<slangasek> yes
<slangasek> so having that as a CI check via proposed-migration would be welcome
<wxl> slangasek: huh. i'm surprised there's no testing already. is the rest of ubiquity tested, sans our kubuntu-specific bits?
<slangasek> wxl: we don't currently have any image testing wired up as a gate for CI; there is something like that in development for this cycle, though at the moment it's focused on the cloud side - but I would certainly love to see collaboration there on how flavor install testing could also be automated and wired up
<tsimonq2> slangasek: What are you guys currently using?
<wxl> slangasek: as RM for lubuntu and general-lackey for kubuntu, i'd be more than happy to help out with that.
<tsimonq2> Same, although in < 1 week I have to go away for a half a month for semester exams... :/
<slangasek> tsimonq2: not sure what you're asking
<tsimonq2> slangasek: Re: systemd-resolved?
<tsimonq2> Ohj
<tsimonq2> hah
<tsimonq2> slangasek: For CI
<slangasek> tsimonq2: proposed-migration + autopkgtest
<slangasek> that provides the distro-level CI
<tsimonq2> Hmm ok
<cyphermox> wxl: I haven't forgotten, I'll be back next week. I thought it was that something got broken in console-setup, but it hasn't changed... it needs more thorough investigation to figure out exactly why it's broken now and was fine in Yakkety.
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.4 => 2.20.1-0ubuntu2.5] (core)
<cyphermox> slangasek: fwiw, I think there are autopkgtests, but the qt tests are suspiciously absent (or my vgrep fails me)
<slangasek> cyphermox: there aren't "Does this image install" autopkgtests
<cyphermox> actually, there are non-autopkgtests tests
<cyphermox> but not specifically for kubuntu I think.
<tsimonq2> o/ cyphermox
<RAOF> lamont: Yo!
<cyphermox> tsimonq2: hello
<RAOF> lamont: Disrupted morning, with people wandering around in my roof. What can I do you for?
<lamont> RAOF: you were beaten by a fellow SRU king.
<lamont> no worries mate
<RAOF> Superb.
<lamont> also, happy new year!
<RAOF> Happy new year!
#ubuntu-release 2017-01-04
<wxl> cyphermox: good to hear from you. there were some interesting tracebacks as recent comments on the bug report.
<slangasek> tsimonq2: so how and why is bug #1647031 affecting you, given that libnss-resolve is in ubuntu-standard and masks the issue?
<ubot5`> bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
<tsimonq2> slangasek: I still get the issue when that is installed afair
<slangasek> tsimonq2: "AFAIR"> would be good to have confirmation, since that conflicts the information on the bug
<tsimonq2> slangasek: OK, I'll let you know on Thursday when I have access to that install again
<slangasek> ok
<Mirv> please remove these (unbuildable, related to the upstart removals) s390x binaries from zesty: libqt5purchasing5 qml-module-qtpurchasing qtpurchasing5-dbg qtpurchasing5-dev-dbgsym libqt5purchasing5-dbgsym qml-module-qtpurchasing-dbgsym qtpurchasing5-dev
<Mirv> filed bug #1653906 about it
<ubot5`> bug 1653906 in qtpurchasing-opensource-src (Ubuntu) "RM: s390x binaries of qtpurchasing-opensource-src" [Undecided,New] https://launchpad.net/bugs/1653906
<ginggs> morning! would someone please 'force-badtest ocrmypdf/4.2.5-1/s390x' ?  debian bug #849094
<ubot5`> Debian bug 849094 in liblept5 "liblept5: Broken on s390x (+ other big endian archs)" [Normal,Open] http://bugs.debian.org/849094
<ginggs> tumbleweed, if you're in a compatible timezone ^
<apw> ginggs, why would we want to break that on s390x by letting it migrate?  it worked before
<ginggs> apw, my understanding is it was always broken on big-endian, the new tests are exposing the problem
<apw> ahh ok
<apw> ginggs, and done
<ginggs> apw: thanks!
<cjwatson> Can somebody remove the force-badtest openssh from the britney hints branch?  It passes everywhere now.
<cjwatson> (It's in pitti's hints file, but I don't think he has commit access any more?)
 * apw has a look
<apw> cjwatson, and done
<cjwatson> Cheers
<cjwatson> Took about a week of on and off arm's-length debugging ...
<apw> that sounds like a lot of a nightmare
<cjwatson> A bit.  Should be suitably nailed to the wall now anyway :)
-queuebot:#ubuntu-release- Unapproved: libica (yakkety-proposed/universe) [2.6.1-3 => 2.6.1-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libica (xenial-proposed/universe) [2.6.1-1ubuntu2 => 2.6.1-1ubuntu2.1] (no packageset)
<flocculant> release team peoples - are you aware the daily boots direct to the desktop? bug 1651716
<ubot5`> bug 1651716 in ubiquity (Ubuntu) "17.04 boots direct to live desktop, no option to Try or Install" [Undecided,Confirmed] https://launchpad.net/bugs/1651716
<mdeslaur> could someone please remove bubblewrap from the yakkety upload queue, I need to rebuild it in the security pocket instead
<apw> mdeslaur, bubblewrap (source)
<apw> 0.1.5-1~ubuntu16.10.0
<apw> that one ?
<mdeslaur> apw: yep
<apw> mdeslaur, and gone
<mdeslaur> thanks apw
-queuebot:#ubuntu-release- Unapproved: rejected bubblewrap [source] (yakkety-proposed) [0.1.5-1~ubuntu16.10.0]
<ginggs> apw: do we need 'force-badtest ocrmypdf/4.3.4-2/s390x' as well for the new version?
<apw> ginggs, looks to be ignored for example for leptonlib, what are you waiting on
<apw> ginggs, oh ocrmypdf is actually waiting to migrate, derp
<ginggs> apw: sorry i didn't realize you needed to do that per version, i thought it was worked like >= 4.2.5-1
<apw> ginggs, some of them do, some not.
<tumbleweed> ginggs: you can do all versions, but then it's easily forgotten
<Mirv> could an archive admin bug handle bug #1653906 so that my ticket rebuild qtpurchasing (https://bileto.ubuntu.com/#/ticket/1985) wouldn't show a missing build? (since it's not really missing, as the s390x binaries could not be built in zesty if a rebuild was done anymore, regardless of the landing)
<ubot5`> bug 1653906 in qtpurchasing-opensource-src (Ubuntu) "RM: s390x binaries of qtpurchasing-opensource-src" [Undecided,New] https://launchpad.net/bugs/1653906
<infinity> Mirv: Err, why are we still doing upstart-related removals?  Didn't xnox put in a bunch of work to make things stop depending on upstart?
<Mirv> infinity: probably because the upstart problems need to be fixed all at once. right now libpay2 is unavailable on s390x due to manual stop gap dependency in it, so qtpurchasing can't rebuild on s390x. I think xnox will eventually need to have a single huge silo that removes all upstart dependencies, both actual and the made up ones that were inserted in various points to keep touch stack landable for
<Mirv> the last four months.
<Mirv> since doing it partially probably would introduce a chain reaction
<infinity> *sigh*
<infinity> And this removal here was probably one that was missed when people did this crap in yakkety.
<infinity> (And yes, "crap" sums up how I feel about the upstart/s390x "solution")
<infinity> Alright, I'll poke at this bug.
<Mirv> yes, it's pretty crap crap
<infinity> Mirv: Done.
<Mirv> thank you
<tsimonq2> bubblewrap, heh
<tsimonq2> Are there docs somewhere showing what exactly is done when a new development release is being formulated? On the release schedule it says "Toolchain Uploaded" and the appropriate wiki page just talks about the various parts of the toolchain, but not actually what it means to have "Toolchain Uploaded"
<tsimonq2> I'm just curious, as I'm not finding it documented anywhere.
<tsimonq2> Like, inspecting zesty-changes shows some things like setting Zesty as the release etc. but not actually what happens when new releases are a thing.
<cjwatson> tsimonq2: https://wiki.ubuntu.com/NewReleaseCycleProcess
<tsimonq2> cjwatson: Ooh, fancy, thanks.
<tsimonq2> One other thing, why does Lintian *still* not recognize zesty as a release? Should I file a bug, or is that something someone forgot about that I can just submit a debdiff for?
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-proposed/main) [2.0.6-0ubuntu1~ubuntu14.04.1 => 1.0.9-0ubuntu2] (ubuntu-server)
<cjwatson> how about I just use my upstream commit bit to fix that in Debian
<tsimonq2> cjwatson: Yes please. :)
<cjwatson> https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=0170df01277e46b618c269de0a0622389c573a39 - it's probably OK to just let that be synced later, but feel free to cherry-pick if you're in a rush
<tsimonq2> ...maybe if I had upload access I would have that option :P
<tsimonq2> cjwatson: But thanks :)
<tsimonq2> !info lintian zesty
<ubot5`> lintian (source: lintian): Debian package checker. In component main, is optional. Version 2.5.50 (zesty), package size 792 kB, installed size 3831 kB
<tsimonq2> !info lintian unstable
<ubot5`> lintian (source: lintian): Debian package checker. In component main, is optional. Version 2.5.50 (unstable), package size 1019 kB, installed size 3831 kB
<tsimonq2> Ah ok.
<tsimonq2> ...why would the package size in unstable be larger than in Ubuntu?
<stgraber> infinity: can you let that lxc upload into trusty-proposed pretty please? that should fix the autopkgtest failure we've had so far by having our test detect busted kernels properly
<tsimonq2> s/Ubuntu/zesty/
<cjwatson> tsimonq2: stripped upstream changelog
<cjwatson> $ diff -u <(zcat unstable/usr/share/doc/lintian/changelog.gz) <(zcat zesty/usr/share/doc/lintian/changelog.gz) | diffstat
<infinity> stgraber: Hahaha.  I was just looking at that.
<cjwatson>  62 |17741 ---------------------------------------------------------------------
<cjwatson>  1 file changed, 1 insertion(+), 17740 deletions(-)
<infinity> stgraber: (The failure, not your upload)
<infinity> stgraber: Oh.  Different (maybe?) failure.
<infinity> stgraber: Care to have a glance at https://bugs.launchpad.net/auto-package-testing/+bug/1654025 and see if you can make sense of it?
<ubot5`> Ubuntu bug 1654025 in Auto Package Testing "trusty/armhf dkms tests are killing workers" [Undecided,New]
<infinity> stgraber: As for this lxc upload... Skipping a test doesn't seem to resolve the bug?
<infinity> stgraber: Unless the feature being tested also will refuse to be used on old kernels.
<stgraber> infinity: LXC does fail when it runs into that particular kernel issue, it's said LXC failure which was then causing autopkgtest to fail. So we now detect it ahead of time and skip the test rather than failing when we get the error.
<stgraber> infinity: it's not ideal in that there's still a kernel bug, but it's limited to the 3.13 kernel and hasn't seen much traction in getting fixed
<infinity> stgraber: And this bug/interaction has always existed in trusty lxc-versus-3.13?
<infinity> stgraber: As in, no new regression here, just a test that exposed it?
<stgraber> infinity: LXC used to go ahead with the busted-ness which was enough to make the test happy and then break people randomly. LXC 1.0.9 detects the kernel being busted and refuses to have anything to do with it.
<infinity> stgraber: Okay, that sounds like progress, even.  (not ideal progress, but progress nonetheless)
<infinity> stgraber: So, accepting that.
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507463 is the underlying issue I believe
<ubot5`> Ubuntu bug 1507463 in linux (Ubuntu) "OverlayFS: Wrong mnt_id and path reported in /proc in linux-3.13" [Medium,Confirmed]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-proposed) [1.0.9-0ubuntu2]
<infinity> stgraber: Can you look at the bug above (specifically, Laney's strace vomit) and tell me if that rings any bells?
<infinity> stgraber: It looks suspiciously container/namespace related, and I can't reproduce in a plain old chroot.
<stgraber> infinity: so it's apt-get source dkms on trusty blowing up somehow?
<infinity> "apt-get source -q --only-source nvidia-graphics-drivers-340=340.98-0ubuntu0.14.04.1" is the call, and yeah, in a chroot, it just does a thing, downloads some source, prints to stdout, life is good.
<infinity> stgraber: In a container, it appears to not do a useful thing. :P
<infinity> (Though still exits 0, thanks apt)
<Laney> Bit weirder
<Laney> It exits 0 but the rest of the script doesn't run
<infinity> Laney: That's the script's fault, surely.
<infinity> Laney: But the apt failure it the curious bit right now.
<Laney> I think the whole script is being killed
<Laney> But yeah, surely fixing that will fix whatever it is
<infinity> Laney: The script being "killed" is by design, surely.
<infinity> Laney: It's logging an error, and even gives us the error.
<infinity> (The error being that apt exited without printing anything to stdout, and we're pretty uncool with that)
<Laney> No
<Laney> The script is meant to catch the bad exit code, look at the output and then exit with it
<Laney> We should see that happening, given set -x
<stgraber> Laney: any chance you can get a dmesg output post failure?
<Laney> Hmm
<stgraber> the first thing that comes to mind with such behavior (command just stopping halfway through whatever it's doing) would be the kernel oom killer
<stgraber> though that usually causes a non-zero exit :)
<infinity> OOM kills return a 9, not 0.
<Laney> 'fraid I've got to get out of here for a bit
<stgraber> I'll try to reproduce this on my m400 (xenial arm64 host), should be as close as I can get
<Laney> I'm just running it on my desktop (zesty, amd64)
<stgraber> infinity: we've seen the kernel do weird shit when the oom is cgroup triggered :)
<Laney> We just get it on armhf for autopkgtest because that's the only place we use lxd
<stgraber> Laney: oh, fun
<infinity> We use it on s390x too.
<infinity> But it might not be triggering the same tests.
<stgraber> not on trusty though
<infinity> Oh, and trusty.  Yeah.
<stgraber> running "apt-get source --only-source nvidia-graphics-drivers-340" in a trusty container here doesn't reproduce the issue though
<stgraber> Laney: do you have a reproducer that doesn't involve running all of autopkgtest with the lxd backend?
<Laney> Nope, sorry
<infinity> Odds are it's just that one command.
<infinity> But I don't lxd well enough to tell you that. :P
<Laney> I think I tried earlier in a normally started container (but still an autopkgtest one) and it worked
<Laney> The desktop is off now because of the aforementioned leaving
<Laney> ttyl
<stgraber> Laney: does autopkgtest with the lxd backend exec stuff through "lxc exec" or through ssh?
<stgraber> I just tried a simple shell script which runs the apt-get source command and then prints something in both of "lxc exec"'s modes and both worked fine
<infinity> Define working fine.  Does it download the source?
<stgraber> yup
<stgraber> downloads and unpacks
<infinity> Well, that's irksome.
<infinity> ssh certainly could be involved, if it's mimicking the xen and kvm workflows.
<tsimonq2> cjwatson: Hmmmm ok thanks
-queuebot:#ubuntu-release- New binary: gyoto [s390x] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [ppc64el] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [amd64] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [powerpc] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [i386] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [arm64] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gyoto [armhf] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
 * tsimonq2 throws bug 1647031 at barry 
<ubot5`> bug 1647031 in systemd (Ubuntu) "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
<tsimonq2> May be relevant... :)
<tsimonq2> (can't respond to the email atm)
-queuebot:#ubuntu-release- Unapproved: rejected owncloud-client [source] (yakkety-proposed) [2.2.2+dfsg-1ubuntu0.2]
<Laney> stgraber: I think https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/autopkgtest/tree/virt/autopkgtest-virt-lxd#n149 that beauty is prefixed to commands to run
-queuebot:#ubuntu-release- Unapproved: owncloud-client (yakkety-proposed/universe) [2.2.2+dfsg-1ubuntu0.1 => 2.2.2+dfsg-1ubuntu0.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [source] (yakkety-proposed) [2.2.2+dfsg-1ubuntu0.2]
<stgraber> Laney: running with that command still works fine here
<stgraber> Laney: http://paste.ubuntu.com/23741392/
<Laney> Something somewhere is making it break in this specific way :P
<Laney> I'll have to look more tomorrow unless one of you gets to it tonight
<Laney> Food now
<stgraber> Laney: what version of LXD are you using on your machine?
<stgraber> we did some tweak to exec handling in recent versions (2.6/2.7), wondering if maybe I can't reproduce it because my version isn't affected somehow
<barry> tsimonq2: ha, yes probably related :)  thanks
<Laney> stgraber: Right this second I'm on yakkety - seems to be 2.4.1
<Laney> can't remember offhand what the autopkgtest infrastructure is on, probably x
<Laney> bet it's something in trusty
<stgraber> yeah, I'd expect autopkgtest to be on xenial so 2.0.x
<stgraber> the exec fixes were in LXD 2.6 or 2.7 so only in zesty so far
<stgraber> let me try that against a xenial host
<Laney> this means I've seen the same on x, y and z
<Laney> does the spew in the strace log tell you anything?
<Laney> probably should have compressed that
<stgraber> not really, sure looks like it's in a loop but there's no sign of it ever getting out of it
<stgraber> which is odd as you should at least see strace exit at some point
 * Laney shrugs
<Laney> I guess tomorrow, if nobody beats me to it, I'll have to step through everything autopkgtest is doing until it breaks
<stgraber> no luck with my minimal reproducer on yakkety
<barry> Laney, stgraber what's going on with autopkgtest?  i don't have any relevant scrollback
<infinity> barry: https://bugs.launchpad.net/auto-package-testing/+bug/1654025
<ubot5`> Ubuntu bug 1654025 in Auto Package Testing "trusty/armhf dkms tests are killing workers" [Undecided,New]
<infinity> barry: Insights welcome.
<barry> infinity: looking
<tsimonq2> barry: np, it's Really Really Annoying so Please Try And Get It Fixed Pretty Please ;)
<barry> tsimonq2: oh trust me, i'm hitting it all the time ;)
<tsimonq2> barry: Relevant systemd bug: https://github.com/systemd/systemd/issues/3826
<tsimonq2> :)
<barry> tsimonq2: thanks.  i guess i'll subscribe to that ;)
<infinity> Looks like another case of "systemd thought they knew better", given the implementation is intentionally doing the filtering.
<barry> please please please give me systemd-emacs
<tsimonq2> systemd-editord?
<tsimonq2> OH I KNOW! systemd-snapd :P
 * tsimonq2 runs
<tsimonq2> barry: Thanks, slangasek didn't bite when I linked him yesterday, really glad I'm not the only one being tormented ;)
<barry> tsimonq2: yet another fallout of the pitti defection.  we each inherited 1/10th of a pitti, kind of like a horcrux or something
<tsimonq2> barry: :P I wish I had the time and expertise to help...
<tsimonq2> barry: OOH! https://lists.ubuntu.com/archives/ubuntu-devel/2016-December/039564.html
<barry> tsimonq2: i'm not sure i have either either but i've gotten pretty good at annoyance transfer
<barry> tsimonq2: yep.  slangasek did suggestion elsewhere a possible revert option until this is fixed
<tsimonq2> In the worst case, these are the two commits to revert to undo this: https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/commit/?id=98974a88 https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/commit/?id=47c16e59
<tsimonq2> barry: imho that would be good, even though my vote probably doesn't count, +3 :P
<barry> tsimonq2: i think i'll at least test that revert tomorrow
<barry> then we can decide after some additional data
<tsimonq2> barry: And I'd also like to point out that Lubuntu has a bug where ubuntu-standard and ubuntu-minimal (tasks) aren't installed by default, and I Absolutely Hate GUI networking solutions, so there's that...
<tsimonq2> barry: Heck, I can package the revert now in a PPA of mine and test it quick here :)
<tsimonq2> As I face it on Real Hardware...
<barry> tsimonq2: that would be very helpful.  if you do gather useful information, can you please update the LP bug?  i'm very nearly eod and can't run too late tonight.
<tsimonq2> barry: Sure, although if it's OK with you, I'd like to link the PPA here once I have a solution and at lt have someone else test it ;)
<barry> tsimonq2: +1
<tsimonq2> s/lt/least/
<tsimonq2> barry: OK, cool! I'll let you know! Have a nice night! :)
<barry> tsimonq2: thanks, you too!
-queuebot:#ubuntu-release- New binary: qbs [ppc64el] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [s390x] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [amd64] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [i386] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [powerpc] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [arm64] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [armhf] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
#ubuntu-release 2017-01-05
<slangasek> xnox: I feel like you might be the person to ask about stray dirmngr processes left hanging around in an image chroot after apt has been run
<xnox> slangasek, yeah....
<slangasek> xnox: how can I fix this?
<xnox> pkill ?
<slangasek> mmhmm :)
<xnox> on a more serious note, things should not be hitting the network, or trying to retrieve gpg keys.
<slangasek> "things"?
<xnox> soemthing somewhere calls gnupg and doesn't clean up. You don't mean that a simple "apt update" results in stray dirmngr?
<slangasek> xnox: probably the apt-key call
<xnox> yes, apt-key would do it. one should not call apt-key.... and just ship key snippets (like ubuntu-keyring does)
<xnox> or are you adding/enabling PPAs with apt-key?
<slangasek> ppa
<xnox> ... and not using add-apt-repository?
<slangasek> this script *also* uses add-apt-repository
<slangasek> let me see if the apt-key stuff is superfluous
<xnox> if add-apt-repository results in stray dirmngr, i should fix that.
-queuebot:#ubuntu-release- New: accepted qbs [amd64] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [armhf] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [powerpc] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [s390x] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [arm64] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [ppc64el] (zesty-proposed) [1.7.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted qbs [i386] (zesty-proposed) [1.7.0+dfsg-3]
<slangasek> however, there's also a cleanup phase here of 'sudo apt-key del ${ppa_key}'
<slangasek> is that going to provoke dirmngr?
<xnox> that should be safe.
<xnox> apt-key adv is not.
<slangasek> ok
<slangasek> that does seem like a bug in apt-key, anyway
<xnox> that it doesn't clean up dirmngr (or any other spawned agents) post-adv command? (which are actually passthrough to gpg command, which now started to spawn garbage)
<slangasek> yes
<slangasek> apt-key appears to run with a temporary GNUPGHOME dir
<slangasek> and anything spawned that references that dir is lost
<slangasek> and add-apt-repository adds the ppa, but packages from that ppa are listed as unauthenticated
<slangasek> unpleasant
<xnox> slangasek, $ gpgconf --list-components | sed 's/:.*//' | xargs -L1 gpgconf --kill
<xnox> probably slightly better (e.g. don't try to kill gpg "component") is needed.
<xnox> add-apt-repository should have been fetching a key =/ iff it can access things (do you need proxy to access ubuntu keyserver?!)
<slangasek> xnox: but doesn't that require the matching GNUPGHOME, so gpgconf can see which of the running processes is its?
<xnox> sure it does, hence it should be in the apt-key cleanup.
<xnox> (as in apt-key itself should be doing that)
<xnox> which btw is just a fancy pkill
<slangasek> right
<slangasek> so we agree it's an apt-key bug
<xnox> but i thought that add-apt-repository did the right thing (tm)
<xnox> so possibly two bugs.
 * slangasek nods
<slangasek> oh
<slangasek> hmm
<slangasek> xnox: add-apt-repository doesn't know to fetch ppa keys for a private ppa :P
<xnox> oh, you want that
<slangasek> well, all things considered, I really do not
<slangasek> ;)
<slangasek> but I currently have
<xnox> slangasek, use curl to fetch private ppa key off keyserver and pipe it into a file.
<slangasek> alternatively, I can batch-copy things out of the private to a public one because thbt
<xnox> slangasek, or you can specify [trusted=yes] on the ppa entry you are using.
<xnox> given you delete the key afterwards anyway... and building in secure environment anyway....
<xnox> and forget about keys.
<slangasek> xnox: same problem with add-apt-repository
<xnox> marvelous.
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.6-0ubuntu1~ubuntu16.04.1 => 2.0.6-0ubuntu1~ubuntu16.04.2] (ubuntu-server)
<xnox> killall dirmngr sounds appropriate size of ikea hammer.
<slangasek> Executing: /tmp/tmp.DaevBURr1s/gpg.1.sh --keyserver keyserver.ubuntu.com --recv
<slangasek> gpg: keybox '/tmp/tmp0_lqr33e/pubring.gpg' created
<slangasek> root      2600  0.0  0.0 175736  4088 ?        Ssl  16:51   0:00  \_ dirmngr --daemon --homedir /tmp/tmp0_lqr33e
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.6-0ubuntu1~ubuntu16.10.1 => 2.0.6-0ubuntu1~ubuntu16.10.2] (ubuntu-server)
<slangasek> yeah
<xnox> also, i'm confused why gpg doesn't just kill dirmngr at the end of execution....
<slangasek>                      root       4891 .rce. gpg-agent
<slangasek> wat
<xnox> yeah that too
<xnox> apperantly gpg-agent is needed to store keys....
<stgraber> why did they make such a mess with gpg2...
 * xnox was not kidding when i said pipe curl from keyserver into /etc/apt/trusted.gpg.d/foo.gpg file
<xnox> gpg2.1, i think gpg2.0 was still sane.
<stgraber> it's really tempting to distro patch gpg to record what it auto-spawns and kill them all on exit, basically re-introducing good old gpg1 behavior (except it used to do everything in-process)
<xnox> racy
<stgraber> not if you have them listen on a per-process temp path :)
<xnox> one can spawn to /usr/bin/gpg which are waiting on results from e.g. the same dirmgr
<xnox> hahaha
<xnox> i think upstream rejected systemd socket activation =)
-queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.20 => 204-5ubuntu20.21] (core)
<LocutusOfBorg> novaclient.exceptions.OverLimit: Quota exceeded for ram: Requested 8192, but already used 48640 of 51200 ram (HTTP 413) (Request-ID: req-ecaa7c79-5e1f-4106-8b3f-7664a086b1cf)
<LocutusOfBorg> ERROR (OverLimit): Quota exceeded for ram: Requested 8192, but already used 48640 of 51200 ram (HTTP 413) (Request-ID: req-ecaa7c79-5e1f-4106-8b3f-7664a086b1cf)
<LocutusOfBorg> Laney, ^^ seems that retrying poppler autopkgtestsuite against libreoffice fails on i386
<LocutusOfBorg> I would like to finish that poppler stuff :/
 * LocutusOfBorg leaves
<LocutusOfBorg> rmadison -u ubuntu cups-ipp-utils
<LocutusOfBorg> universe ^^
<LocutusOfBorg> doko, promote to main and unblock cups?
<Laney> It'll retry itself
<LocutusOfBorg> cups-filters-core-drivers/* unsatisfiable Depends: cups-ipp-utils
<Laney> libreoffice wants a large instance
<LocutusOfBorg> thanks Laney :)
<LocutusOfBorg> I'm already trying the reverse-dependencies
<LocutusOfBorg> if the laptop battery resists, I'll also set up a ben file
<LocutusOfBorg> cups needs a move to main of cups-ipp-utils anyway I guess
<LocutusOfBorg> poppler is already on ben
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.6-0ubuntu1~ubuntu16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.6-0ubuntu1~ubuntu16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild-launchpad-chroot [source] (yakkety-proposed) [0.13.1ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [sync] (yakkety-proposed) [2.28.2-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [sync] (xenial-proposed) [2.27.1-6ubuntu3.2]
<ginggs> would an ubuntu-archive admin remove python-sunpy and python3-sunpy 0.7.3-1 on armhf and arm64 from -proposed please? LP: #1643151
<ubot5`> Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,New] https://launchpad.net/bugs/1643151
-queuebot:#ubuntu-release- New source: bubblewrap (xenial-proposed/primary) [0.1.5-1~ubuntu16.04.1]
<barry> tsimonq2: how did your revert test go?
<apw> ginggs, looking
<apw> ginggs, done
<mvo> can someone please release snapd 2.20.1ubuntu1 for xenial and 2.20.1+16.10ubuntu2 for yakkety? verification is done. there is an autopkgtest failure on ppc64el but despite what the tracker says this is not a real regression because there was a hickup in a previous upload and that was responsible for this "passed on ppc64el" result
-queuebot:#ubuntu-release- New binary: yaz [ppc64el] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaz [s390x] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaz [amd64] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaz [powerpc] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaz [arm64] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaz [armhf] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.5]
-queuebot:#ubuntu-release- New binary: yaz [i386] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.21]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (xenial-proposed/universe) [0.58.1 => 0.58.2] (ubuntugnome)
<dmj_s76> When are we expecting kernel 4.8 to land in the daily iso for 16.04.2?
<jbicha> bdmurray: if you can, please look at accepting ubuntu-gnome-meta 0.58.2 in to xenial-proposed so it's ready in time for 16.04.2
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (xenial-proposed) [0.58.2]
<jbicha> thank you!
<slangasek> infinity: ^^ 4.8 in xenial dailies? done?
<tkamppeter> Hi, I have synced cups-filters 1.13.2 from Debian to Zesty some days ago, why did it not make it from -proposed to the release?
<nacc> tkamppeter: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says unsatisfiable depends cups-ipp-utils
<tkamppeter> nacc, why unsatisfiable depends on cups-ipp-utils? cups-ipp-utils is part of the cups source package which is in main.
<slangasek> which means the binary needs promoting to main
<slangasek> (done now)
<nacc> tkamppeter: yeah it was a mismatch http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<tkamppeter> slangasek, thanks.
<tkamppeter> nacc, also thanks.
<nacc> tkamppeter: np
-queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (xenial-proposed) [2.38.0-12ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (yakkety-proposed) [2.38.0-15ubuntu1.1]
<juliank> I feel like we should let apt 1.2.18 enter xenial-updates now. While nobody verified 1592817 as fixed, there seem to be no new reports in it for -proposed (bdmurray). There's a ton of other bugs verified fixed, and it's really important to get this done now, as it apparently breaks upgrades to yakkety for some people. Most of this has been waiting since November's 1.2.16 upload, so it really is a bit older than overviews make you think :)
<juliank> There were some autopkgtest failures, but those are not regressions caused by apt since the last apt upload
-queuebot:#ubuntu-release- Unapproved: accepted overlay-scrollbar [source] (xenial-proposed) [0.2.17.1+16.04.20151117-0ubuntu1.16.04.1]
<bdmurray> How are the autopkgtest failures not regressions?
-queuebot:#ubuntu-release- Unapproved: accepted overlay-scrollbar [source] (yakkety-proposed) [0.2.17.1+16.04.20151117-0ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx [source] (xenial-proposed) [1:4.2.9.1-1ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx [source] (yakkety-proposed) [1:4.2.9.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libseccomp (trusty-proposed/main) [2.2.3-2ubuntu1~ubuntu14.04.1 => 2.1.1-1ubuntu1~trusty3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.1.3+bzr5573-0ubuntu1~16.04.1]
<juliank> bdmurray: They happen in apport, autopkgtest, and sbuild; and if you look at the logs, already earlier (even with 1.2.15). I think all of them started as soon as yakkety opened.
<juliank> It would be a wise thing to fix them at some point, but I have not gotten around to that, and apparently nobody else either :/
<juliank> apport actually started failing in August, at that point, the wily ddeb archive started showing signature errors in apt - without a change in apt.
<juliank> These tests will stop working even more once wily is dropped from the archive.
<juliank> or well, that was the issue
<juliank> the ddebs were dropped at that time
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.8]
<jdstrand> bdmurray: happy new year! I could you take a look at libseccomp on trusty in the unapproved queue?
<jdstrand> s/I could/could/
<jdstrand> bdmurray: this is to address bug 1653487
<ubot5`> bug 1653487 in libseccomp (Ubuntu) "seccomp argument filtering not working on trusty" [High,In progress] https://launchpad.net/bugs/1653487
<bdmurray> jdstrand: I was on a call, looking now
<bdmurray> jdstrand: its meant to supersede the existing upload?
<jdstrand> bdmurray: yes. it includes everything that was in it
<bdmurray> jdstrand: I guess I meant you don't care if the other doesn't get released first?
<jdstrand> bdmurray: do not release the other first (there is no point since this SRU is for snappy and the previous upload doesn't work with snappy amd64)
<jdstrand> bdmurray: basically, this fixes the verification-failed of Tyler's upload
<bdmurray> jdstrand: got it
<jdstrand> bdmurray: so reject Tyler's, and accept this one (which is Tyler's plus patches to fix the failure)
<jdstrand> cool
<bdmurray> fyi bug 1653487 has no trusty task
<ubot5`> bug 1653487 in libseccomp (Ubuntu) "seccomp argument filtering not working on trusty amd64" [High,In progress] https://launchpad.net/bugs/1653487
<jdstrand> bdmurray: fixed
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [source] (trusty-proposed) [2.1.1-1ubuntu1~trusty3]
<jdstrand> bdmurray: thanks!
<bdmurray> jdstrand: I think there's something wrong with your "Send" button
<jdstrand> mm?
-queuebot:#ubuntu-release- Unapproved: accepted os-prober [source] (xenial-proposed) [1.70ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu14]
#ubuntu-release 2017-01-06
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (xenial-proposed) [13.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-gtk-module [source] (xenial-proposed) [0.0.0+15.04.20150118-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted hdhomerun-config-gui [source] (xenial-proposed) [20150826-0ubuntu1.16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted hdhomerun-config-gui [source] (yakkety-proposed) [20150826-0ubuntu1.16.10.0]
<tsimonq2> barry: aaaargh /o\ I totally forgot
<tsimonq2> And unfortunately I have no energy left for today...
<barry> tsimonq2: no worries.  i have a version in my ppa: https://launchpad.net/~barry/+archive/ubuntu/experimental/+packages
<barry> tsimonq2: i did just a little testing before i had to go, but will test more tomorrow
<ginggs> thanks apw (re:sunpy removal)!  Can I get a  'force-badtest sunpy/0.7.4-2/armhf' as well for the autopkgtest that is no longer installable please?
-queuebot:#ubuntu-release- New source: olefile (zesty-proposed/primary) [0.43-1~ubuntu1]
<apw> ginggs, done
<ginggs> apw: ta!
<jamespage> please could the ceph sru's in xenial and yakkety proposed be rejected; I want to recut with a few other fixes
<rbasak> Done
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (xenial-proposed) [10.2.5-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (yakkety-proposed) [10.2.5-0ubuntu0.16.10.1]
<jamespage> rbasak, ta
-queuebot:#ubuntu-release- New binary: calligra [s390x] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [ppc64el] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [powerpc] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [amd64] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [i386] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [arm64] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: calligra [armhf] (zesty-proposed/universe) [1:2.9.11+dfsg-4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted s390-zfcp [source] (xenial-proposed) [1.0.2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (xenial-proposed) [2.48.2-0ubuntu1]
<tyhicks> hello! I'm curious if anyone on the SRU team could give me an update on the status of the apparmor 14.04 SRU?
<xnox> tyhicks, they are flying to cape town?! =) is that good enough update /me giggles
<xnox> slangasek, ^^^
<tyhicks> xnox: good, I'll be able to ask them in person :)
<tyhicks> I've been off this week but I was surprised that I didn't see it move to trusty-updates
<tyhicks> I can ask around more in Cape Town
<tkamppeter> slangasek, hi
<tkamppeter> Yesterday I have asked because of cups-filters 1.13.2 not making it from zesty-proposed to zesty release and slangasek told me that the binary package cups-ipp-utils needs to get proposed to main and he told he would do it immediately. Was this actually done?
<xnox> that's easy to check with rmadison.
<xnox> it is in main
<xnox> $ rmadison -S cups-ipp-utils -> says it's in "zesty" implying main.
<xnox> universe would have been "zesty/universe" like it is in xenial, xenial-proposed, yakkety.
<xnox> cups-filters is a valid candidate
<Laney> it's the poppler transition
<xnox> which needs "just" there to finish I think: calligra, karbon, libreoffice-pdfimport, pdf2htmlex
<xnox> or is there a transition tracker?
<Laney> dunno, looks like it's being handled so not getting involved
 * xnox likes it.
<xnox> http://people.canonical.com/~ubuntu-archive/transitions/html/poppler.html
<tkamppeter> xnox, Laney, thank you very much for the update.
<dmj_s76> xnox: Do you know when the iso will get the new kernel for testing 16.04.2?
<xnox> dmj_s76, no, i saw things in some channel that it's in progress and/or done, or some such.
<xnox> but maybe not yet.
<mapreri> pdf2htmlex should build now that I fixed a dep of it
<mapreri> if you could accept calligra from NEW would help ;)
-queuebot:#ubuntu-release- New: accepted calligra [amd64] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [armhf] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [powerpc] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [s390x] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [arm64] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [ppc64el] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New: accepted calligra [i386] (zesty-proposed) [1:2.9.11+dfsg-4]
-queuebot:#ubuntu-release- New binary: cpio [amd64] (zesty-proposed/main) [2.11+dfsg-6] (core)
<apw> mapreri, ^
<jbicha> mapreri: I'm doing another fixup upload of calligra now but I expect calligra will get stuck because of the ongoing kde transition anyway
<clivejo> jbicha: is there anyone you know could help us get KDE frameworks moved on and out of proposed
<jbicha> clivejo: is the blocker just autopkgtests?
<clivejo> yes
<clivejo> and I dont have the skill/knowledge to fix them :(
<jbicha> ok you're in the right channel since there's people here who can set those to be ignored
<clivejo> can't find anyone else willing to take the time and teach us either
<clivejo> we also have a new Qt landing soon which Mirv has been working on
<clivejo> jbicha: is there anyone in particular to ping regarding this?
<jbicha> by the way, I noticed that kdevplatform's autopkgtest exists on Ubuntu but not Debian
<jbicha> you could try emailing ubuntu-devel if you want to see if anyone can help with troubleshooting autopkgtests
<jbicha> for ignoring autopkgtests, you could try pinging one of https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files
<clivejo> that doesnt appear to be current
<clivejo> Jon Riddell and Scott Kitterman are no longer working on the project
<jbicha> sure, but 3 people made changes in 2017 already
<clivejo> bar Colin I dont know anyone else who is active on that list
<clivejo> jbicha: BTW are you aware that calligra is at 3.0.0.1 now? ( http://download.kde.org/stable/calligra-latest/ )
<clivejo> and that 2.9.11 is KDE4?
<robru> any core devs around who can assign me some bite-size archive maintenance tasks? (and then sponsor uploads later?) thanks
-queuebot:#ubuntu-release- New: accepted cpio [amd64] (zesty-proposed) [2.11+dfsg-6]
<cjwatson> clivejo: have you at least tried setting up autopkgtest sufficiently locally so that you can run the tests and iterate on fixes?
<cjwatson> there's no point to autopkgtests if people are just going to reflexively ignore failures - and I hope people nowadays agree that tests are worthwhile
<jbicha> robru: archive maintenance? maybe https://bugs.launchpad.net/~ubuntu-archive/ is some of what you're looking for
<clivejo> cjwatson: honestly, no.  I have no idea how to do that locally and I don't have the equipment or internet to even try it locally.  I was looking into trying to get a public instance so that we would do tests and fix them before even uploading, but that hit a brick wall
<cjwatson> I refreshed my setup recently for debugging openssh - it's a bit fiddly but not too bad.  if you're on xenial then the easiest way is probably to follow the procedure in adt-build-lxd(1)
<cjwatson> and I have utterly rubbish internet
<robru> jbicha: I was thinking more like http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html but not clear to me who's working on what (or what would be bite-sized) so hoping for some guidance picking something
<cjwatson> in many cases it doesn't need any particular equipment beyond what you need for ordinary development
<clivejo> we had one guy santa_ who setup his own equipment to do the tests, but I haven't seen him about in a few months now
<cjwatson> I think honestly nowadays it's something that everyone who uploads stuff would be well-served taking an hour or two to learn how to do
<clivejo> cjwatson: you are quite right, I have tried to learn it, but haven't found any online docs to help with that and everyone I've asked has basically been too busy doing other things
<cjwatson> ok, well, adt-build-lxd(1) is my pointer from recent experience, and the directions in adt-virt-lxd(1) seem to work fine
<cjwatson> (the former setup for building the base image, the latter for running individual tests)
<jbicha> robru: ok, there's also http://qa.ubuntuwire.org/ftbfs/
<mapreri> apw: thanks :)
<mapreri> jbicha: :(
<LocutusOfBorg> thanks jbicha wrt calligra :) I fixed the breaks+replaces typo and uploaded
<LocutusOfBorg> release team please demote mensis to proposed, this will make poppler / fontforge transitions finish
<LocutusOfBorg> mensis is out of Debian Stretch, rc buggy, rebuilding is useless
<clivejo> how are you guys dealing with the package split in calligra?
<LocutusOfBorg> breaks+replaces and sync with Debian
<LocutusOfBorg> but I didn't do the work, so I can't answer :)
<clivejo> ok
<clivejo> so are you guys taking over maintenance of calligra now?
<LocutusOfBorg> the maintainer is ubuntu developers
<LocutusOfBorg> I'm not really sure about what you mean... you can still upload/maintain it, just the delta should be reduced now
<LocutusOfBorg> and the package is 30MB instead of ~150
<LocutusOfBorg> :)
<LocutusOfBorg> if you want to maintain it in Debian, and sync I think it would be awesome, I don't see much gain in having two different packaging in Debian and Ubuntu
 * LocutusOfBorg didn't do the work, and is just trying to make poppler migrate
<clivejo> just don't understand why we are updating old versions
<clivejo> calligra (KDE4) is now split into calligra + krita + kexi all KF5
<LocutusOfBorg> https://packages.qa.debian.org/c/calligra.html
<LocutusOfBorg> seems split yes
<LocutusOfBorg> not sure what is the question, nor I understand what calligra does
<jbicha> clivejo: no I don't intend to maintain KDE stuff, I just helped reduce the diff with Debian and get the package to build
<acheronuk> LocutusOfBorg: calligra now has a 3.0.0.1 Qt5/KF5 version with krita and kexi removed, whereas the legacy 2.9 branch is Qt4. hopefully that can be packaged for zesty in time
<LocutusOfBorg> nice :)
<clivejo> not really
<clivejo> as we can't upload them
<LocutusOfBorg> why?
<jbicha> clivejo: please file a bug and subscribe ubuntu-sponsors
<clivejo> they become NEW and get queued
<clivejo> and we don't have a MOTU on our team any more
<LocutusOfBorg> jbicha, uploading once again
<clivejo> jbicha: we have 36 NEW packages on our list, no-one will take it on
<LocutusOfBorg> clivejo, why not apply for PPU?
<LocutusOfBorg> or MOTU
<clivejo> I don't know enough
<clivejo> only got my Kubuntu Devel permissions few months ago
<acheronuk> they need adding to our packageset, but that is not happening very fast at the moment
<acheronuk> hence a bit frustrating
<jbicha> if you just open a bug, attach the .debdiff or point to the git branch or whatever, and subscribe ubuntu-sponsors, it will show up on http://reqorts.qa.ubuntu.com/reports/sponsoring/
<jbicha> and there are several people who regularly look for stuff on there to sponsor
<clivejo> jbicha: you mentioned trojita a while back
<clivejo> would you be prepared to sponsor it?
<clivejo> http://trojita.flaska.net
<jbicha> someone probably will, just leave an explanation for why Debian never got around to uploading it
<clivejo> they short on packagers, same as us!
<mapreri> clivejo: also in Debian there are people regularly sponsoring packages, and the Qt/KDE team is quite active with several active DDs, if you want to do the work there :P
<clivejo> mapreri: maybe a few years down the line when I learn some more :)
 * clivejo is currently very content and happy in his little Kubuntu CI bubble
<clivejo> well until acheronuk broke it by adding Qt5.7.1
<mapreri> clivejo: anyhow, if the Kubuntu team lacks proper MOTUs, just open bugs and subscribe ubuntu-sponsors, somebody will look at it at some point :)
<acheronuk> clivejo: sorry :P trying to fix
<acheronuk> or I will if QtWeEngine builds in less than 4hrs tonight
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (xenial-proposed) [1.157.7]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.6 => 1.157.8] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: cups-filters (xenial-proposed/main) [1.8.3-2ubuntu3.2 => 1.8.3-2ubuntu3.3] (desktop-core, ubuntu-server)
#ubuntu-release 2017-01-07
<Mirv> it would be nice if the KF 5.28 was force-allowed in before Qt lands but not strictly necessary as same KDE related forces will be needed for Qt too as long as the KDE autopkgtetss remain enabled but not maintained
<valorie> that would help Kubuntu a lot as we try to get the latest Plasma bugfix in as well as applications
<acheronuk> Mirv: there will also be at least another whole frameworks upload before any freeze, so FW 5.29 failures are not exactly an irrelevance, but neither are they indicative of what should be shipped
<acheronuk> plus there should be new KDE applications landing as well, so where test failures related to the old apps shipped with yakkety, much the same applies
<Mirv> yeah the only real problem is overloading autopkgtest infrastructure and letting stuff stay in proposed for months
<Mirv> proposed time should be minimized, either by fixing autopkgtests or disabling them if they are not used
<acheronuk> Mirv: well, santa is the only person currently on the team who really knows how to fix them, and he has fallen off the planet for the last month and is not responding to emails etc, so the prospect of "fixing" them is fairly slim
<acheronuk> is that case continues, then disabling at least the irksome ones may be the way, for FW 5.29, 5.30 etc
<acheronuk> not ideal, nut many things are not
<acheronuk> *but
<Mirv> acheronuk: yes. that's unfortunate but maybe the way that needs to be taken at least for this cycle.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (trusty-proposed) [204-5ubuntu20.21]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-59.80~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-59.80] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-59.80~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-59.80]
-queuebot:#ubuntu-release- New binary: python-irc [amd64] (zesty-proposed/universe) [8.5.3+dfsg-3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: lua-sql [amd64] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [ppc64el] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [i386] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [s390x] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [armhf] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [powerpc] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-sql [arm64] (zesty-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lua-sql [arm64] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [powerpc] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [armhf] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [s390x] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [amd64] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [ppc64el] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted lua-sql [i386] (zesty-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted python-irc [amd64] (zesty-proposed) [8.5.3+dfsg-3]
#ubuntu-release 2017-01-08
<tsimonq2> cjwatson: Reading the conversation from a few days ago, would just adding a hook onto sbuild to do autopkgtests work? https://wiki.debian.org/sbuild#Using_autopkgtest
<tsimonq2> cjwatson: I mean, I guess it would help, right?
<cjwatson> tsimonq2: Rather beside the point if you haven't got them running at all yet :-) but sure, if you like
<cjwatson> tsimonq2: I'd find that rather annoying for quick test builds personally
<LocutusOfBorg> doko, cjwatson please move mensis to proposed, and let fontforge/poppler migrate, thanks
<cjwatson> no
<cjwatson> I mean, please don't ask me
<cjwatson> you might find me more likely to have time if it's during the week
<LocutusOfBorg> I used to ping pitti, I don't know who has the power(TM) to do that :(
<slangasek> LocutusOfBorg: ITYM remove mensis from zesty, since it's already in -proposed; removal done
<slangasek> and who has power == ~ubuntu-archive
<LocutusOfBorg> slangasek, why a package in proposed blocks the migration? (thanks BTW)
<slangasek> LocutusOfBorg: it's not the package /in/ proposed that blocks the migration, it's the package in zesty that blocks migration
<LocutusOfBorg> indeed, you were quicker then me, when I reopened the page the package was already out
<LocutusOfBorg> I was mostly sure lp was updating that page when dinstall or publish run
<LocutusOfBorg> so, lets see poppler go in thanks
<LocutusOfBorg> mapreri, ^^ jbicha ^^
-queuebot:#ubuntu-release- Unapproved: pyqt5 (trusty-proposed/main) [5.2.1+dfsg-1ubuntu1 => 5.2.1+dfsg-1ubuntu2] (no packageset)
<LocutusOfBorg> please ppc64el go go go :)
<jbicha> could sepolgen/zesty be hinted in: its binary was changed from python to python3 and its rdepends were fixed for the change
#ubuntu-release 2018-01-01
-queuebot:#ubuntu-release- New source: ubuntu-unity-meta (bionic-proposed/primary) [0.1]
<wxl> the weekly upgrade testing build seems to have expired and now results cannot be submitted again. can we fix that? i have Google Code-In students that would like to work on this
<flocculant> wxl: I can see result pages
<wxl> yeah but you can't report new results
<flocculant> http://iso.qa.ubuntu.com/qatracker/milestones/384/builds/163834/testcases/1310/results
<wxl> ah wrong build
<flocculant> aah - yea build numbers change
-queuebot:#ubuntu-release- New binary: mbpfan [s390x] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [s390x] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: klystrack [s390x] (bionic-proposed/none) [0.20171212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [s390x] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [s390x] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [s390x] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [s390x] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [s390x] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: debian-dad [amd64] (bionic-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [s390x] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [amd64] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [ppc64el] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [amd64] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbpfan [amd64] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [s390x] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [i386] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [i386] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [amd64] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbpfan [i386] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: klystrack [amd64] (bionic-proposed/none) [0.20171212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [ppc64el] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: klystrack [i386] (bionic-proposed/none) [0.20171212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [i386] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [i386] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [amd64] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: klystrack [ppc64el] (bionic-proposed/none) [0.20171212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-static3 [amd64] (bionic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [ppc64el] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [amd64] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mbpfan [ppc64el] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [amd64] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [ppc64el] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [i386] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [ppc64el] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [i386] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [amd64] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [ppc64el] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [ppc64el] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [ppc64el] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [amd64] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [i386] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [arm64] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ignition-cmake [armhf] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [i386] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: planetblupi [amd64] (bionic-proposed/universe) [1.12.1-22-g13a7e27-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [armhf] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmseed [arm64] (bionic-proposed/none) [2.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [arm64] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbpfan [arm64] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [armhf] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: imx-usb-loader [armhf] (bionic-proposed/none) [0~git20171026.138c0b25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbpfan [armhf] (bionic-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [armhf] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [arm64] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: klystrack [arm64] (bionic-proposed/none) [0.20171212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [armhf] (bionic-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [arm64] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-rope [armhf] (bionic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: i2pd [arm64] (bionic-proposed/none) [2.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [armhf] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: todoman [arm64] (bionic-proposed/none) [3.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-image-viewer [arm64] (bionic-proposed/none) [1.2.16.7-1] (no packageset)
#ubuntu-release 2018-01-02
-queuebot:#ubuntu-release- New binary: libt3window [s390x] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [ppc64el] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [amd64] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [i386] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [armhf] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3window [arm64] (bionic-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [amd64] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [armhf] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [ppc64el] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted libt3window [arm64] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted libt3window [i386] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted libt3window [s390x] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [arm64] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted libt3window [amd64] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted libt3window [ppc64el] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [i386] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted libt3window [armhf] (bionic-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted libt3window [ppc64el] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted libt3window [amd64] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted libt3window [armhf] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted libt3window [s390x] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted libt3window [arm64] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted pyasn1 [amd64] (bionic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted libt3window [i386] (bionic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted i2pd [amd64] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted i2pd [armhf] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted i2pd [ppc64el] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted i2pd [arm64] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted i2pd [i386] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted klystrack [amd64] (bionic-proposed) [0.20171212-1]
-queuebot:#ubuntu-release- New: accepted klystrack [i386] (bionic-proposed) [0.20171212-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [amd64] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [armhf] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [ppc64el] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted klystrack [arm64] (bionic-proposed) [0.20171212-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [arm64] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted klystrack [ppc64el] (bionic-proposed) [0.20171212-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [i386] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-rope [s390x] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted todoman [arm64] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New: accepted todoman [i386] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New: accepted todoman [amd64] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New: accepted todoman [ppc64el] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New: accepted todoman [armhf] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New: accepted deepin-image-viewer [s390x] (bionic-proposed) [1.2.16.7-1]
-queuebot:#ubuntu-release- New: accepted python-static3 [amd64] (bionic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted i2pd [s390x] (bionic-proposed) [2.17.0-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [source] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [amd64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [armhf] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [s390x] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [armhf] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [ppc64el] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [arm64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [arm64] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [s390x] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [ppc64el] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [i386] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted imx-usb-loader [amd64] (bionic-proposed) [0~git20171026.138c0b25-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [arm64] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [i386] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [s390x] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [amd64] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [ppc64el] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mbpfan [armhf] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted debian-dad [amd64] (bionic-proposed) [1]
-queuebot:#ubuntu-release- New: accepted libmseed [amd64] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted libmseed [armhf] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted libmseed [ppc64el] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted planetblupi [amd64] (bionic-proposed) [1.12.1-22-g13a7e27-2]
-queuebot:#ubuntu-release- New: accepted ignition-cmake [i386] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmseed [i386] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted libmseed [arm64] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted libmseed [s390x] (bionic-proposed) [2.19.5-1]
-queuebot:#ubuntu-release- New: accepted klystrack [s390x] (bionic-proposed) [0.20171212-1]
-queuebot:#ubuntu-release- New: accepted todoman [s390x] (bionic-proposed) [3.2.4-3]
-queuebot:#ubuntu-release- New binary: ubuntu-unity-meta [ppc64el] (bionic-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-unity-meta [amd64] (bionic-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-unity-meta [i386] (bionic-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-unity-meta [arm64] (bionic-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-unity-meta [armhf] (bionic-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [amd64] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [armhf] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [ppc64el] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [arm64] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-unity-meta [i386] (bionic-proposed) [0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (xenial-proposed) [0.5-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (xenial-proposed) [0.5-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (xenial-proposed) [0.5-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (xenial-proposed) [0.5-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: rejected powerline [source] (artful-proposed) [2.5-1.1ubuntu0]
<LocutusOfBorg> hello, can we please have gsequencer hinted? (regressed in release)
<LocutusOfBorg> on s390x I mean
<doko> is there currently an upgrade freeze in place?
<doko> alpha1 ...
<tsimonq2> doko: Next week
<tsimonq2> doko: Nobody objected to pushing it back, it was in my email...
<tsimonq2> (several weeks ago at that)
<doko> hmm, but the freeze is still in place ...
<tsimonq2> Oh, is it?
<tsimonq2> O_o
<tsimonq2> Someone should lift that
<tsimonq2> (and also edit the release schedule, heh)
<tsimonq2> doko: Do you know who put that in place?
<doko> <no
<tsimonq2> Alright.
<xnox> ... isn't it this week
 * xnox dropped all context
<tsimonq2> xnox: Let me edit that release schedule...
<xnox> tsimonq2, i assume i missed a memo w.r.t. change of dates =)
<tsimonq2> xnox: I said it in my email to ubuntu-release ;)l
<xnox> ah
<tsimonq2> (I blame myself, should have edited the schedule)
<tsimonq2> There.
<LocutusOfBorg> hello, can we please have gsequencer hinted? (regressed in release) (s390x)
<LocutusOfBorg> this will make libxml2 migrate with its security fix
<xnox> LocutusOfBorg, make a merge proposal to the hints branch?
<tsimonq2> I know people might still be catching up on stuff but the sooner this is reviewed the better, as it should fix the Lubuntu dailies ;)  https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/+merge/335604
<tsimonq2> (in hindsight I should have probably waited, but hindsight's 20/20, heh)
<LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/335626
<LocutusOfBorg> xnox, I think I did it
<LocutusOfBorg> please delete your one :) and thanks!
<xnox> tsimonq2, i was pondering to move everybody to git for seeds too a while back.
<xnox> tsimonq2, and have one repository; with branches for all releases; and use something like ~TEAM/ubuntu-seeds repository name (ie. just the default repo for a team in said project)
<xnox> tsimonq2, what layout did you go for?
<tsimonq2> xnox: By default, Germinate has Git support for each flavor having a repo with a branch for every release
<tsimonq2> So I did that
<tsimonq2> xnox: So yeah, very sinilar to what you describe
<tsimonq2> xnox: Take a look: https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu
<tsimonq2> xnox: So I did the tooling changes I could see, but I know there's a script in ubuntu-archive-tools that needs an MP too
<xnox> right
<tsimonq2> (bad reception, meh)
<tsimonq2> xnox: Do you have the permissions to merge that?
<xnox> tsimonq2, nope, that one is owned by archive admins
<xnox> (i am guessing you meant lp:ubuntu-archive-tools, or was it something else?)
<tsimonq2> xnox: Alright. Either way, a review would be appreciated, there might be a better Bashism to use than what I did ;)
<tsimonq2> Yeah, that, or my MP
<tsimonq2> (archive tools doesn't have an MP yet)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.27]
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (bionic-proposed/main) [17.11-3] (kubuntu, ubuntu-desktop, ubuntu-server)
<cpaelzer> due to the sync for bionic ^^ - please let me know if anthing is needed
-queuebot:#ubuntu-release- New binary: libt3highlight [s390x] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3key [s390x] (bionic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3highlight [ppc64el] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3key [ppc64el] (bionic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (bionic-proposed/main) [17.11-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libt3key [arm64] (bionic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3highlight [arm64] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3highlight [armhf] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3key [armhf] (bionic-proposed/universe) [0.2.7-1] (no packageset)
<tsimonq2> /or/kr
<tsimonq2> grr
<acheronuk> ?
<tsimonq2> acheronuk: mobile + irssi aliases = errors
 * acheronuk shoves tsimonq2 @ matrix :P
<tsimonq2> Noooo
<tsimonq2> Irssi ftw <3
<acheronuk> haha
-queuebot:#ubuntu-release- New binary: libmail-message-perl [amd64] (bionic-proposed/universe) [3.005-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3highlight [i386] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3highlight [amd64] (bionic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3key [i386] (bionic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3key [amd64] (bionic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [i386] (bionic-proposed/main) [17.11-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (bionic-proposed/main) [17.11-3] (kubuntu, ubuntu-desktop, ubuntu-server)
<tsimonq2> cjwatson: Would you be available to review my merge proposal to lp:ubuntu-cdimage? https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/+merge/335604
#ubuntu-release 2018-01-03
-queuebot:#ubuntu-release- New binary: avahi [s390x] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: avahi [ppc64el] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: avahi [amd64] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: avahi [i386] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: avahi [arm64] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: avahi [armhf] (bionic-proposed/main) [0.7-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: mstch [s390x] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtree-r-perl [amd64] (bionic-proposed/universe) [0.072-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mstch [ppc64el] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mstch [amd64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mstch [arm64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mstch [i386] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mstch [armhf] (bionic-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: flask-security [amd64] (bionic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [s390x] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [ppc64el] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [i386] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [amd64] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [arm64] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qscintilla2 [armhf] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vulkan (xenial-proposed/universe) [1.0.42.0+dfsg1-1ubuntu1~16.04.1 => 1.0.61.1+dfsg1-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qscintilla2 [amd64] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted qscintilla2 [armhf] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted qscintilla2 [ppc64el] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted qscintilla2 [arm64] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted qscintilla2 [s390x] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted qscintilla2 [i386] (bionic-proposed) [2.10.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted avahi [amd64] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [armhf] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [ppc64el] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted mstch [amd64] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mstch [armhf] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted mstch [ppc64el] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted avahi [arm64] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted avahi [s390x] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted mstch [i386] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted avahi [i386] (bionic-proposed) [0.7-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted mstch [arm64] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (bionic-proposed) [17.11-3]
-queuebot:#ubuntu-release- New: accepted dpdk [i386] (bionic-proposed) [17.11-3]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (bionic-proposed) [17.11-3]
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (bionic-proposed) [17.11-3]
-queuebot:#ubuntu-release- New: accepted flask-security [amd64] (bionic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted mstch [s390x] (bionic-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted libtree-r-perl [amd64] (bionic-proposed) [0.072-1]
-queuebot:#ubuntu-release- New: accepted libt3key [amd64] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libt3key [armhf] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libt3key [ppc64el] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libt3key [arm64] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libt3key [s390x] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libt3key [i386] (bionic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted libmail-message-perl [amd64] (bionic-proposed) [3.005-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [arm64] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [i386] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [s390x] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [amd64] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [ppc64el] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted libt3highlight [armhf] (bionic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New binary: libt3widget [s390x] (bionic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [ppc64el] (bionic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [amd64] (bionic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [i386] (bionic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [arm64] (bionic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libt3widget [armhf] (bionic-proposed/universe) [0.5.4-1] (no packageset)
<tseliot> sil2100: hi, is it ok if I reupload ubuntu-drivers-common for LP: #1728547 dropping the code for the other SRU for now? (we need the nvidia fix to get in quickly)
<ubot5> Launchpad bug 1728547 in OEM Priority Project "SRU: Add support for keeping the dGPU on in power saving mode" [Medium,Triaged] https://launchpad.net/bugs/1728547
-queuebot:#ubuntu-release- New: accepted libt3widget [amd64] (bionic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [armhf] (bionic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [ppc64el] (bionic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [arm64] (bionic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [s390x] (bionic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libt3widget [i386] (bionic-proposed) [0.5.4-1]
<sil2100> tseliot: hm hm, that might be a bit problematic as I'm not sure it would be wise to skip the 7-day aging period for it
<sil2100> tseliot: so after the new version is uploaded and accepted into -proposed, it'd still have to wait there for at least 7 days I guess
<sil2100> tseliot: but if you think that the bugfix might not work (as I see in the other bug comment, Alex seemed to have some issues verifying the fix) I guess re-uploading might be a solution
<tseliot> sil2100: yes, the thing is I'm not sure when we would be able to verify the amdgpu code. That can wait. The fix for nvidia is more urgent, and we need the new fix that Alex proposed too
-queuebot:#ubuntu-release- Unapproved: rejected dpkg [source] (trusty-proposed) [1.17.5ubuntu5.8]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:0.4.17.4 => 1:0.4.17.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: tilde [s390x] (bionic-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilde [amd64] (bionic-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilde [arm64] (bionic-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilde [i386] (bionic-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilde [armhf] (bionic-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilde [ppc64el] (bionic-proposed/universe) [0.3.9-1] (no packageset)
<sil2100> tseliot: ok, re-upload in that case (with a newer version number of course)
<sil2100> tseliot: I'll pick it up from the queue
<tseliot> sil2100: you should be able to see my upload a few lines above ^^
<sil2100> Ahah ;)
<sil2100> Ok!
<LocutusOfBorg> jbicha, please double check my sane-backends merge
<jbicha> LocutusOfBorg: where?
-queuebot:#ubuntu-release- Unapproved: accepted vulkan [source] (xenial-proposed) [1.0.61.1+dfsg1-1ubuntu1~16.04.1]
<LocutusOfBorg> jbicha, bionic
<tseliot> sil2100: thanks for your help ;)
<sil2100> tseliot: yw! hm, I guess we don't need a re-upload for zesty, considering that it'll be EOL this month
<tseliot> sil2100: yes, right, let's just leave zesty alone
<jbicha> LocutusOfBorg: seems fine enough, a bit mysterious why that diff wasn't included in the Debian upload since it was properly forwarded as comment 50 at Debian bug 870078
<ubot5> Debian bug 870078 in libsane1 "libsane1 breaks all 3rd party scanner drivers" [Important,Open] http://bugs.debian.org/870078
<jbicha> but I have trouble communicating with jff :(
<sil2100> tseliot: I see the new xenial upload includes a minor change on top, right? Like, the skip bbswitch?
<sil2100> tseliot: remember to re-test it before re-marking as verified
<sil2100> tseliot: oh, and hm, I guess you'll have to re-upload (if possible) and remove the link to bug LP: #1731873
<ubot5> Launchpad bug 1731873 in OEM Priority Project "Backport amdgpu-pro support" [High,New] https://launchpad.net/bugs/1731873
<sil2100> tseliot: or, maybe not remove it but just do the source package build without -v, so that the .changes file only includes 1:0.4.17.5 - whichever you prefer
<sil2100> tseliot: since otherwise the SRU machinery will need the other bug verified as well, even though the fix has been reverted
<tseliot> sil2100: alextu tested that change. I can certainly re-upload the package without -v, if you reject it
<sil2100> tseliot: sure, upload and I'll reject
<tseliot> sil2100: done
<sil2100> tseliot: done, will re-review your new upload once the diff is generated
<sil2100> Thanks!
<tseliot> sil2100: thanks to you!
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (xenial-proposed) [1:0.4.17.5]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:0.4.17.4 => 1:0.4.17.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (xenial-proposed) [1:0.4.17.5]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.25 => 2.408.27] (desktop-core)
<jbicha> slangasek: could you drop the mango-lassi pkg from bionic to allow avahi to migrate? (already removed in Debian Testing)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [176.0.0-0ubuntu1 => 183.0.0-0ubuntu1~17.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [176.0.0-0ubuntu1~16.04.0 => 183.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [176.0.0-0ubuntu1~14.04.0 => 183.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.27]
<slangasek> jbicha: done
<jbicha> slangasek: avahi-sharp (and gshare) need to be removed too. Do you need a LP bug filed?
<slangasek> jbicha: are there serious bugs filed in Debian that I can point to for those?
<jbicha> avahi-sharp is Debian bug 877038 , gsharp was removed from testing because it needs avahi-sharp
<ubot5> Debian bug 877038 in libavahi-ui0.0-cil "libavahi-ui0.0-cil depends on obsolete package libavahi-ui0" [Serious,Open] http://bugs.debian.org/877038
<slangasek> ok
<slangasek> one
<slangasek> done
<jbicha> "one and done" :)
<slangasek> cpaelzer: wrong merge target for https://code.launchpad.net/~paelzer/britney/hints-ubuntu-bump-openvswitch/+merge/335670, I think
-queuebot:#ubuntu-release- New binary: libmoosex-traitfor-meta-class-betteranonclassnames-perl [amd64] (bionic-proposed/universe) [0.002003-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu3 => 2:9.1.2-0ubuntu4] (openstack, ubuntu-server)
<slangasek> tsimonq2: "because it fixes Lubuntu daily builds" - har; why did your seeds disappear from bzr before this had been done?
<tsimonq2> slangasek: Because I thought it would be alright... probably should have asked where it would break first, to be honest...
<tsimonq2> Probably shouldn't have used it as an argument :P
<tsimonq2> Â¯\_(ã)_/Â¯
<slangasek> tsimonq2: as we're adding support for git here, I would prefer that the pattern for legacy bzr usage to also be explicitly tagged 'bzr'.  Would you care to do an s/pattern/bzrpattern/ throughout, or should I fix it up as part of the merge?
<tsimonq2> slangasek: I'll be home in ~ 45 mins and can do it then, unless you feel inclined to merge this now
<slangasek> tsimonq2: I can wait for you, thanks
<tsimonq2> slangasek: Cool, I'll ping when it's done
<tsimonq2> slangasek: But I'm also curious to see what you think about the other branch I linked in the MP
<slangasek> haven't looked yet - will try to do so soon
<tsimonq2> Alright.
<tsimonq2> slangasek: afaict the last place that needs to be fixed is ubuntu-archive-tools, does that sound right?
<slangasek> Â¯\_(ã)_/Â¯
<tsimonq2> Heh alright, I guess we'll have to see then. :P
<tsimonq2> Thanks slangasek
<tsimonq2> slangasek: What's the version of germinate deployed on Nusakan?
<slangasek> tsimonq2: I don't actually know where https://code.launchpad.net/~tsimonq2/+junk/ubuntu-archive-scripts is supposed to be merged to
<slangasek> tsimonq2: checking
<slangasek> germinate @VERSION@
<slangasek> ;)
<slangasek> d6b2f1ad5687ad07b85f3589d5e6a2236566bb31
<slangasek> which is approximately 2.25
<tsimonq2> slangasek: This: https://code.launchpad.net/~ubuntu-archive/+junk/scripts
<cjwatson> somebody should feel free to make that a proper project if it's going to get MPs
<cjwatson> sorry I haven't had time to review
<slangasek> tsimonq2: right, thanks
<slangasek> (I have a checkout of that branch, but its name eluded me)
<cjwatson> you might also want to think about what to do about branch-seeds in lp:ubuntu-archive-tools
<tsimonq2> cjwatson: Right, that was my next step.
<slangasek> tsimonq2: https://code.launchpad.net/~tsimonq2/+junk/ubuntu-archive-scripts merged, and cjwatson's suggestion to make it a proper project added to my round-tuit pile
<slangasek> tsimonq2: wrt germinate versions, 2.26 help output matches - so if you've tested or looked at code or something to tell you that --vcs == --vcs=auto, that's fine, it's just not obvious to me from the --help
<tsimonq2> slangasek: Cool cool, looking at addressing your comments on my MP now
<tsimonq2> slangasek: Sure, if you look at lubuntu-meta from bionic, that's what I did in the update script, and it seemed to work (with the platform seeds being in Bionic and the Lubuntu seed being in Git, it had no problems)
<tsimonq2> (just specifying --vcs)
<slangasek> ok
<tsimonq2> slangasek: bzrpattern change pushed, but I'm unsure about this bit (there's confusingly similar language in the germinate source), is {prefer,use}_bzr specific to cdimage, or is it taken from the germinate Python module?
<tsimonq2> (s/language/variables/ I guess...)
<slangasek> tsimonq2: in this context it's specific to cdimage
<tsimonq2> slangasek: Alright, thanks.
<tsimonq2> slangasek: Should be good now, could you take a look?
<slangasek> tsimonq2: merged
<tsimonq2> slangasek: thanks, looking at lp:ubuntu-archive-tools now then
<slangasek> tsimonq2: ah, you didn't run run-tests and neither did I
<tsimonq2> slangasek: TIL ...
-queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.4-1 => 3.5-1~ubuntu17.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.4-1~ubuntu16.04.1 => 3.5-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.4-1~ubuntu14.04.1 => 3.5-1~ubuntu14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.4-1~ubuntu17.04.1 => 3.5-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
<tsimonq2> slangasek: Do you want to fix things or should I?
<slangasek> tsimonq2: inprogress here
<tsimonq2> ack
-queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.4-1~ubuntu14.04.1 => 3.5-1~ubuntu14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.4-1~ubuntu16.04.1 => 3.5-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.4-1~ubuntu17.04.1 => 3.5-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
<tsimonq2> ubuntu-archive-tools> As they say, there's more than one way to skin a cat... I'm leaning towards trying to programatically detect if it's a git or bzr repo and then adding a --vcs argument if the user wants to override, would that be alright?
-queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.4-1 => 3.5-1~ubuntu17.10.1] (ubuntu-desktop, ubuntu-server)
<slashd> Happy new year sil2100 ! As we previously discussed could you please have a look at the uploads of sosreport for AZXT to start building in -proposed tomrrow during you SRU day ? I'm sorry I had to re-upload it after realizing I haven't put the LP: #XXX in d/changelog, you can reject the less recent upload and proceed with the most recent ones.
-queuebot:#ubuntu-release- New: accepted libmoosex-traitfor-meta-class-betteranonclassnames-perl [amd64] (bionic-proposed) [0.002003-1]
-queuebot:#ubuntu-release- New: accepted tilde [arm64] (bionic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted tilde [i386] (bionic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted tilde [s390x] (bionic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted tilde [amd64] (bionic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted tilde [ppc64el] (bionic-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted tilde [armhf] (bionic-proposed) [0.3.9-1]
<cjwatson> germinate: error: --vcs option requires an argument
<cjwatson> I think your --vcs == --vcs=auto theory may not hold water
<tsimonq2> Yeah.
<tsimonq2> MP is a min away :)
<tsimonq2> cjwatson: I made a false assumption that germinate argument syntax was the same as germinate-update-metapackage in that if only --vcs was specified, it would fall back to auto.
<tsimonq2> (I wonder why there's that inconsistency, but regardless, fixing.)
<cjwatson> mm, I don't quite recall
<cjwatson> germinate-update-metapackage --vcs doesn't take an arg
<tsimonq2> Ohh.
<tsimonq2> cjwatson: Commit pushed to lp:~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate and there might still be that MP attached.
<tsimonq2> (Still, the inconsistency is a bit peculiar...)
<cjwatson> I think there was some reason to do with g-u-m having extra information from the thing it's updating, or somehting
<cjwatson> it was a while ago
<tsimonq2> cjwatson: (Apologies if you're already doing it but) could I please get http://bazaar.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/revision/1697 pulled to lp:ubuntu-cdimage? It seems https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/+merge/335604 doesn't update...
<cjwatson> I'm not and won't have time
<tsimonq2> Sure.
<cjwatson> sorry
<tsimonq2> slangasek? :)
<acheronuk> "Build farm disabled for maintenance; no ETA yet "
<acheronuk> from #launchpad ^^^
<tsimonq2> Might be worth updating the topic in here and #ubuntu-devel.
* cjwatson changed the topic of #ubuntu-release to: LP build farm disabled for maintenance; no ETA yet | Released: Xenial 16.04.3, Artful 17.10 | Archive: open | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
#ubuntu-release 2018-01-04
<slangasek> tsimonq2: done and rolled out
<tsimonq2> slangasek: Thanks.
<tsimonq2> slangasek: So the build logs for Lubuntu daily-live timestamped 20180104 show that the *implementation* is correct but the repositories aren't.
<tsimonq2> slangasek: I certainly wouldn't have expected this...
<slangasek> mm?
<tsimonq2> slangasek: It errors out with this: fatal: could not read Username for 'https://git.launchpad.net': No such device or address
<slangasek> ok then
<tsimonq2> So it just needs git+ssh?
<tsimonq2> (Do the builders have the capability to do that? Stupid question but I think it's worth asking...)
<slangasek> well, git+ssh *definitely* requires a username...
<tsimonq2> Right, but apparently so does https
<tsimonq2> https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/bionic/daily-20180104.log - there it is
<slangasek> tsimonq2: yes, if I browse to https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/platform.bionic  I get an Ubuntu SSO prompt
<tsimonq2> That's not what I'm referring to.
<slangasek> and then I log in, and then I get Repository '~lubuntu-dev/ubuntu-seeds/+git/platform.bionic' not found.
<tsimonq2> Besides, that doesn't exist (thus the SSO prompt)
<tsimonq2> Ohhh
<tsimonq2> I'm misreading this
<tsimonq2> (or am I? dunno)
<slangasek> what I see is that https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/ clones fine, then it fails to get platform.bionic
<tsimonq2> In fact, line 59 of that log I just linked is probably the culprit
<tsimonq2> RIght
<tsimonq2> s/59/60/
<slangasek> * Checking out https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/
<slangasek> bzr: ERROR: Not a branch: "https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/".
<tsimonq2> Right
<tsimonq2> I can now repro locally
<slangasek> fwiw your bzrpattern edit changed http to https
<slangasek> and I can branch from http
<slangasek> -        elif self.prefer_bzr:
<slangasek> -            pattern = "http://bazaar.launchpad.net/~%s/ubuntu-seeds/"
<slangasek> you assumed https was correct? :)
<tsimonq2> Right, and I thought that was harmless, because I assumed when everything in Canonical's sites switched over to https, so did bazaar.launchpad.net
<tsimonq2> (there was an announcement and everything)
<slangasek> ok.  I'm switching it back
<tsimonq2> Also change it back in the tests (when you fixed them I saw you changed to https as well)
<slangasek> tsimonq2: done. by all rights I should've demanded you change this already when reviewing because you were making an unrelated change, but I was being lenient ;)
<tsimonq2> slangasek: Right, and to be completely fair, I thought HTTPS Bazaar was a thing.
<tsimonq2> slangasek: Also, you apparently believed me, you did it in your commits fixing the tests ;P
<tsimonq2> slangasek: ubuntu-archive-tools> To get this part fixed, I could do this in multiple ways... I'm leaning towards trying to programatically detect if it's a git or bzr repo and then adding a --vcs argument if the user wants to override, would that be alright?
<slangasek> tsimonq2: sorry, I don't actually know the context of what needs to be fixed on that branch, and my attention is elswhere right now
<tsimonq2> slangasek: Alright. When you do have a minute though, branch-seeds in lp:ubuntu-archive-tools is what I'm referring to.
<tsimonq2> (Just needs "Gitifying")
<slangasek> tsimonq2: ok, I don't know that I've ever used this command, but I see that it's referenced in https://wiki.ubuntu.com/NewReleaseCycleProcess.  I don't see a use case for a --vcs option to override - it seems to me that if a flavor is migrating their seeds, they should do so for historical releases all at the same time
<slangasek> tsimonq2: I'm fine with programmatically detecting bzr vs git (which should be as straightforward as a string match on the URI)
<tsimonq2> slangasek: Adam does this at the beginning of every release cycle. ;)
<tsimonq2> slangasek: http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.bionic/revision/390 for example
<tsimonq2> (well, not *absolutely* sure, but it does look like this is the script he uses)
<tsimonq2> (I'd ask Adam himself but it seems like he's still on vac)
<tsimonq2> vcs> makes sense
<tsimonq2> slangasek: There, I think this should do it: https://code.launchpad.net/~tsimonq2/ubuntu-archive-tools/add-git-support-to-branch-seeds/+merge/335687
<cpaelzer> slangasek: bzr merging always i bizzare to me (so it lives to its abbreviation) - but yeah now that the Delta is generated it obviously is the wrong target
<cpaelzer> slangasek: thanks for the hint
<cpaelzer> what I had set was the default LP gave me
<cpaelzer> I think I fixed the target, but will double check once the diff is up this time
<cpaelzer> hmm now it shows no diff, did you already merge and your pingwas only FYI?
<cpaelzer> oh you did, thank you slangasek
<LocutusOfBorg> hello apw, please merge? https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/335626
* Laney changed the topic of #ubuntu-release to: LP build farm and autopkgtest request.cgi disabled for maintenance; no ETA yet | Released: Xenial 16.04.3, Artful 17.10 | Archive: open | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<Laney> :'(
<sil2100> Oh shit
<xnox> holiday, celebrate!
<tsimonq2> Right, unexpected holiday ...
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (zesty-proposed) [3.5-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.1]
<dpb1> sil2100: hey
<dpb1> are you working on #1737640?
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (zesty-proposed) [3.5-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (artful-proposed) [2.8.1-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted openscad [source] (artful-proposed) [2015.03-2+dfsg-2ubuntu1.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (artful-proposed) [0.39ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (zesty-proposed) [0.35ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: rejected evolution-data-server [source] (artful-proposed) [3.26.3-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected evolution [source] (artful-proposed) [3.26.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.5]
<tsimonq2> ...are the Launchpad builders still down, even for Ubuntu builds?
<tsimonq2> Oh, hm, seems things might be back?
<tsimonq2> Oh, reading #lp, nvm
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu4]
<rbasak> tsimonq2: also the topic here :)
<tsimonq2> rbasak: I know, but I see builds going, so I wondered...
<teward> rbasak: this brings up an obvious question, but does this require alteration to the release schedule to adjust freeze dates, etc. because of the downtime?
<teward> since we can't build things anymore :P
<cjwatson> tsimonq2: Only test rebuilds, which have built on Launchpad already and so are negligible risk
<cjwatson> (well, mostly only test rebuilds)
<rbasak> teward: I'm not on the release team. But I think it probably doesn't make sense to adjust schedules twice, so we might as well defer any discussion until we know when the downtime will be over.
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu3 => 2:9.1.2-0ubuntu4] (openstack, ubuntu-server)
<tsimonq2> cjwatson: Alright, thanks
<slangasek> jbicha: hrm, do you know the history of the gvfs delta that runs the autopkgtests through 'sudo', without taking any steps to ensure that the user running the tests has passwordless sudo access?
<slangasek> jbicha: (yours is the oldest Ubuntu upload before the merge changelog gets truncated, so you get to field the question ;)
<slangasek> apparently this dates back to gvfs 1.20.1-1ubuntu3 by pitti
-queuebot:#ubuntu-release- New source: opengcs (bionic-proposed/primary) [0.3.4+dfsg2-0ubuntu1]
<jbicha> I suggest skipping a January alpha (there's still a 17.10 respin that needs to be done too) and most flavors weren't participating in the January alpha
<acheronuk> unless miraculous updates appear in the VERY near future, I would agree with that ^^^
<jbicha> a year ago, we didn't have an "Alpha 1" and things were fine, so I don't think it's very useful
<flocculant> 'we've' not had an alpha for some cycles and things are fine :)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [183.0.0-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [183.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [183.0.0-0ubuntu1~14.04.0]
<tsimonq2> jbicha: Right, that was the plan.
<tsimonq2> jbicha: (I've had my eye on this, everything *could* magically work out but it's unlikely)
<tsimonq2> flocculant: Let's not get started on that debate again ;)
<tsimonq2> I totally see the use in it
<tsimonq2> (So, I'll continue pushing to do it.)
<tsimonq2> If a flavor doesn't want to do it, it's simple, they opt out.
<tsimonq2> Â¯\_(ã)_/Â¯
<slangasek> I think you could get the same benefit without the milestone overhead
<tsimonq2> I disagree, it's a nice occasion for testing, and we've found (and squashed) bugs because of A1 testing before.
<slangasek> you can schedule testing without imposing an archive freeze and publishing milestone images
<tsimonq2> Sure you can, but milestones seem to get the most traction, because there's a sense of urgency attached to releasing images as a milestone.
<slangasek> if you wanted to do an "alpha" that was just coordinating testing, instead of imposing a milestone freeze on the archive that causes drag for other teams due to the buggy way per-flavor freezes are implemented, then I would have no objections
<tsimonq2> What would it take to fix the buggy implementation of the per-flavor freezes so that other teams wouldn't be dragged down by it?
<tsimonq2> (I ask because rather than avoiding milestones only because the per-flavor freeze implementation is buggy could be fixed by correctly implementing the per-flavor freeze... I'd rather do that than go without milestones.)
<tsimonq2> ((That sentence didn't make gramatical sense but you probably got the point anyways...))
-queuebot:#ubuntu-release- Unapproved: rejected libzstd [source] (zesty-proposed) [1.3.1+dfsg-1~ubuntu0.17.04.1]
#ubuntu-release 2018-01-05
-queuebot:#ubuntu-release- Unapproved: debian-installer (artful-proposed/main) [20101020ubuntu523 => 20101020ubuntu523.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (artful-proposed) [20101020ubuntu523.1]
<slangasek> tsimonq2: the issue is that generate-freeze-block (from lp:ubuntu-archive-tools) will freeze all packages included in an image for a flavor that's participating in a milestone, including base packages that are shared between flavors.  If generate-freeze-block were patched to not block packages which aren't flavor-specific, opt-in milestones would be much less of a problem for those who have
<slangasek> opted out
<Laney> slangasek: generate-freeze-block -u
<Laney> tsimonq2: ^-
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.29.4.2~14.04 => 2.30~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.4.2+17.10 => 2.30+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.4.2 => 2.30] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (artful-proposed/main) [0.125ubuntu12 => 0.125ubuntu12.1] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (zesty-proposed/main) [0.125ubuntu9 => 0.125ubuntu9.1] (core)
<teward> Release Team: regarding 17.04, is there a firm EOL date for it?  I didn't see an announcement yet, but I thought I'd ask.  Since relevant to a major thing right now over on Ask Ubuntu
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (artful-proposed) [0.125ubuntu12.1]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.11]
<slangasek> Laney: oh? that option has been there the whole time?
<Laney> slangasek: I don't think it was there right at the start, but for quite sime time, yes
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.6 => 0.28ubuntu0.7] (core)
<tsimonq2> slangasek: So we're good now? :)
<slangasek> tsimonq2: provided that option DTRT and we're all agreed that this is the right way to manage opt-in milestones, yes
<slangasek> (I still think the actual milestone mechanics are just overhead, but individual flavors can still make that call)
<tsimonq2> slangasek: You're more than welcome to test it on Lubuntu if you wish :)
<tsimonq2> I'll be more than happy to provide patches if it doesn't.
<Laney> You'll probably find that not as many packages are 'unique' as you might want
<tsimonq2> How so?
<Laney> Try the command and see
<tsimonq2> slangasek: Speaking of patches... I'll fix some stuff on that MP a bit later, but where you left the comment of "Why?" I'd like to point to new line 46, which is what I think it is.
<tsimonq2> I'm not a Bazaar user unless needed for simple stuff, so thanks for correcting me on those parts :)
<tsimonq2> Laney: Alright. Is this in ubuntu-archive-tools?
<Laney> Ya
<tsimonq2> ack
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (xenial-proposed) [0.28ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.6 => 0.28ubuntu0.7] (core)
<tsimonq2> O_o
<tsimonq2> You're right Laney
<tsimonq2> This doesn't even have lubuntu-meta...
<tsimonq2> I'll play with it later and propose an MP when I'm done :)
<Laney> tsimonq2: Right, try seeded-in-ubuntu on a missing pkg and you'll see it's seeded somewhere else
<Laney> in this case lubuntu-next
<tsimonq2> I wonder if I can figure out logic to override it if the shared seed comes from the same place..
<Laney> just pretend lubuntu-next is participating and add that to the commandline imo
<tsimonq2> I just look at it from the perspective of extendability should any other flavor decide to do the same thing as us in the future.
<tsimonq2> (i.e. Kubuntu once Plasma 6 is a reality)
<tsimonq2> (extendability might not be the right word, but meh)
<tsimonq2> Thanks for the info Laney
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.7]
<LocutusOfBorg> hello infinity time to merge glibc from debian? :)
<teward> is infinity even around?  RUmor is he's not here right now :p
<LocutusOfBorg> infinity, ^^ (I remember now that you highlight only with first word mentioning you)
<LocutusOfBorg> in case you are not around, have fun! :) (I don't even know if a merge is useful or not)
-queuebot:#ubuntu-release- Unapproved: gnome-applets (artful-proposed/universe) [3.26.0-1 => 3.26.0-1ubuntu0.1] (desktop-extra, edubuntu)
<slangasek> for the non-bios-mangling respin of 17.10: http://iso.qa.ubuntu.com/qatracker/milestones/385/builds
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Dot One] (20180105.1) has been added
<flocculant> slangasek: I assume flavours will show up on there at some point in the future?
<tsimonq2> ^
<slangasek> yes
<flocculant> slangasek: cheers
<tsimonq2> Niiice, many thanks to all who helped in that :)
<slangasek> there is some misconfiguration I don't understand that's preventing them from auto-posting ("TypeError: Only active milestones are accepted"), but I'll manually post them
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Dot One] (20180105.2) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Dot One] (20180105.2) has been added
<slangasek> ok, found the configuration issue, future builds hopefully post automatically
<flocculant> ok - thanks
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Dot One] (20180105) has been added
<acheronuk> do we have a proposed release date for these?
<slangasek> acheronuk: I was going to propose next Thursday; opinion?
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Dot One] (20180105.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Dot One] (20180105.1) has been added
<jbicha> will you be respinning artful after the initial spectre fixes are published?
<slangasek> no
<flocculant> slangasek: I'm assuming that all we're needing to do is check install works for this - and if someone can do so with affected machines all the better?
<slangasek> the objective of the respin is to fix the media so it stops breaking people's BIOS on boot; we don't respin media for security bugs generally, even one as nasty as meltdown/spectre
<slangasek> flocculant: we should be looking for the usual set of release image test cases.  No need to test on affected machines, we're 99.783% sure that not compiling in the spi driver into the kernel at all will prevent that driver from breaking your bios
<jbicha> ok, I was only asking because of the schedule question :)
<slangasek> jbicha: so, the archive freeze due to spectre actually makes it more convenient to do the image builds now because I don't have to worry about cross-image skew in -updates; it would also be nice to have 17.10 images available again since 17.04 is due to EOL shortly
<cjwatson> security update publication to -updates is still possible FWIW
<slangasek> cjwatson: yes, but less likely, which still works out in my favor
<slangasek> anyway, noted, thanks :)
<tsimonq2> slangasek, cjwatson: Someone should disable the daily Bionic and Xenial ISO builds while the build farm is down so that we don't have to deal with the emails about it failing...
<tsimonq2> Well, the live builds, Lubuntu Alternates *seem* to be succeeding for Bionic
<flocculant> tsimonq2: I grabbed that yesterday to check a testcase mp - was current date at least
<tsimonq2> flocculant: That's interesting, because iso.qa.ubuntu.com doesn't seem to be up-to-date for Lubuntu and I keep getting the failure emails...
<slangasek> tsimonq2: if I disable them, someone then has to enable them again by hand in order for them to restart.  I was just going to leave them failing so that's one less manual thing to do when we're back on our feet
<flocculant> tsimonq2: alternate I'm talking about
<tsimonq2> slangasek: Oh, that's fair, got it.
<cjwatson> I share slangasek's take
<acheronuk> slangasek: Thursday seems reasonable to me
<tsimonq2> flocculant: Ohh, was gonna say...
<tsimonq2> :)
<flocculant> you *seemed* unsure ;)
<tsimonq2> Because I was ;)
<tsimonq2> Anyways...
<tsimonq2> Has the archive been frozen in that part of it, or do things just get stuck waiting to build forever?
<flocculant> :)
<tsimonq2> :)
<cjwatson> tsimonq2: the latter
<tsimonq2> cjwatson: Alright, thanks.
<tsimonq2> So to get this right, the Artful Dot One images disable the driver, or can they heal broken systems?
<slangasek> disable the driver
<tsimonq2> ack
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Unapproved: fwupd (artful-proposed/main) [0.9.7-2 => 0.9.7-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (artful-proposed/main) [0.9.7-2 => 0.9.7-2ubuntu1] (desktop-core)
<slangasek> Username for 'https://git.launchpad.net':
<slangasek> ...why
<slangasek> did I not deploy the ubuntu-cdimage fixes?
<nacc> slangasek: what prompted that?
<slangasek> nacc: germinate lubuntu.artful
<slangasek> no, I have
<slangasek> tsimonq2: ^^ running cron.daily interactively gives me these prompts, on nusakan
<slangasek> for lubuntu, specifically
<nacc> slangasek: ah, fyi, if a repo doesn't exist, you get prompted for auth
<slangasek> mmm
<tsimonq2> slangasek: ...
<nacc> slangasek: i wonder if that is happening to you? (i was looking in my logs as I hit something similar)
<tsimonq2> slangasek: What script are you running?
<nacc> slangasek: as lp can't expose the diff. between a private repo and a non-existent repo
<slangasek> tsimonq2: DIST=artful for-project lubuntu cron.daily
<tsimonq2> slangasek: ack
<slangasek> * Cloning branch artful of https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+
<nacc> slangasek: if that does end up being the root, we have set GIT_TERMINAL_PROMPT=0 to make it noninteractive in `git ubuntu`
<slangasek> git/platform/
<slangasek> Cloning into '/tmp/germinate-rUfVvx/platform.artful'...
<slangasek> remote: Authorisation required.
<slangasek> fatal: Authentication failed for 'https://git.launchpad.net/~lubuntu-dev/ubuntu-
<slangasek> seeds/+git/platform/'
<tsimonq2> slangasek: Right, and if that doesn't work, germinate should fall back to Bazaar...
<slangasek> tsimonq2: except that git *prompts* when it doesn't work; needs fixing to not prompt
<nacc> slangasek: yeah that repo doesn't exist
<nacc> slangasek: so the above hack will 'fix' your client tool
<slangasek> (or, needs fixing to not try the non-existent repo)
<tsimonq2> slangasek: Want code from me?
<slangasek> tsimonq2: yes please ;)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Dot One] (20180105) has been added
<tsimonq2> slangasek: Sure, no problem, on it :)
#ubuntu-release 2018-01-06
<tsimonq2> slangasek: Just cron.daily or cron.daily-live too?
<slangasek> don't know yet
<slangasek> :)
<slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/artful/lubuntu/
<tsimonq2> ack
<tsimonq2> slangasek: So why does it show as successful then? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-20180105.log
<tsimonq2> This is on Nusakan itself, not an LP builder, correct?
<wxl> if i read slangasek's email correctly, we will be re-releasing 17.10 to fix the SPI bug, but the Meltdown/Spectre fixes will come in kernel updates, right?
<tsimonq2> Correct.
<slangasek> tsimonq2: it's successful because I manually hit enter at the prompt.  But it should not prompt interactively just because I ran the command with a controlling tty
<tsimonq2> slangasek: ohhh, ic now...
<slangasek> and yes, it also affects lubuntu live ;)
<nacc> wxl: yeah
<wxl> thx release team for your hard work on this! (and to the kernel team as well)
<tsimonq2> ^^^^
<valorie> amen to that
<valorie> thank you thank you thank you
<valorie> my emails asking for testing have gone out
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Dot One] (20180105) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Dot One] (20180105) has been added
<tsimonq2> slangasek: So I've figured out what needs to happen. Would something like this be acceptable? https://paste.ubuntu.com/26329048/
<tsimonq2> slangasek: As long as that env var is set, it won't prompt for anything, but I'm unsure if setting an env var in that way will ensure it gets passed to git from germinate...
<tsimonq2> slangasek: (er, I can test this locally, my point is, what way would you prefer I set the env var?)
<slangasek> tsimonq2: rather, you should pass an env argument to proxy_check_call (which is a wrapper around subprocess.check_call).
<slangasek> tsimonq2: cheatsheet: https://stackoverflow.com/questions/2231227/python-subprocess-popen-with-a-modified-environment
<tsimonq2> slangasek: thanks
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Dot One] (20180106) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Dot One] (20180106) has been added
<tsimonq2> slangasek: incoming: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/make-git-noninteractive/+merge/335789
<tsimonq2> slangasek: Also, Lubuntu Next shouldn't get 17.10.1 builds ;)
<slangasek> tsimonq2: ack, I forgot that directory was empty; how about I delete the directory
<tsimonq2> slangasek: sure np
<slangasek> tsimonq2: did you run 'run-tests'?
<tsimonq2> slangasek: er, good point... let me fix these...
<tsimonq2> slangasek: (nothing's broken except the tests fwiw)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Dot One] (20180106) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Dot One] (20180106) has been added
<smoser> hey. just want to make sure this is expected..
<smoser> ah. never mind.
<smoser> no builds yet. was wondering why a package let in yesterday wasnt in archive.
<smoser> thanks for listening :)
<slangasek> :)
<tsimonq2> slangasek: I'm probably really overthinking this but I keep getting an error code of 256 and I'm having trouble figuring out how to fix it
<tsimonq2> I'll keep trying things but any pointers would really be appreciated
<slangasek> tsimonq2: after modifying the germinate_command() function to include the same env logic?
<tsimonq2> slangasek: Yes.
<tsimonq2> slangasek: I tried this:
<tsimonq2> -                    ], cwd=os.path.join(germinate_output, arch))
<tsimonq2> +                    ], cwd=os.path.join(germinate_output, arch),
<tsimonq2> +                       env=dict(os.environ, GIT_TERMINAL_PROMPT="false"))
<tsimonq2> Because that's the same logic, no?
<slangasek> yes
<tsimonq2> Specifically: AssertionError: Calls not found. -- that's the error
<slangasek> when I apply that and run it here, I see the same failure; if I compare the calls, I see the 'actual' list includes an additional lockfile call?
<tsimonq2> Hmm.
<slangasek> don't know anything beyond that and am afk for now, sorry
<tsimonq2> Alright, thanks anyways
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Dot One] (20180106) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Dot One] (20180106) has been added
<tsimonq2> slangasek: So it ended up being a *one* *line* *fix* - but what you said did help. But I did learn something about Python unit testing in the progress...
<nacc_> tsimonq2: fyi, the documented value is 0
<nacc_> tsimonq2: not "false" (see `man git`)
<nacc_> tsimonq2: I mentioned that value (0) earlier
<tsimonq2> nacc_: Oh, thanks
<tsimonq2> Gah, where'd he go? :)
<nacc> tsimonq2: np :) (and now i'm afk for real too :)
<tsimonq2> o/
<flocculant> slangasek: I don't appear to be able to get iso's from Artful Dot One ... both 32 and 64 bit give me a 404
<flocculant> checked a couple of other flavours and ubuntu - all 404
<flocculant> they 'can' be grabbed ok from cdimage.ubuntu.com/xubuntu/artful/daily-live/current/  at least - but I suspect everyone else points their testers to the tracker, I know I did ;)
<acheronuk> flocculant: same for kubuntu. the qa tracker url points to /kubuntu/daily-live/20180105.2/ folder, whereas the actua images are in /kubuntu/artful/daily-live/20180105.2/
<acheronuk> *actual
<flocculant> acheronuk: yea - you were one of the other flavours I looked at :p
<acheronuk> not done any announcing yet, so good catch
<acheronuk> tsimonq2: lubuntu is also 404, so guess they all are (which is logical)
<flocculant> acheronuk: that was the other flavour :D
<wxl> flocculant: can't we just go on the tracker and change the URLs?
<flocculant> wxl - no idea, never seen that anywhere
<flocculant> wxl - just point people at the cd.image url for the time being
<wxl> well it looks like it should just work http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/497/downloads
<flocculant> never seen that
<wxl> with great power comes great curiousity XD
<flocculant> :)
<wxl> well anyways i can't figure it out if it is possible so oh well
<flocculant> probably is - on the other hand it could go horribly wrong
<flocculant> for you - cos I would wait ;)
<wxl> hm are bionic dailies halted?
<wxl> everyone's stuck at 20180103 it seems.. except for Lubuntu alternates which are ahead and the rest of the Lubuntu images which are behind but rebuilding
<jbicha> wxl: I assume that's because LP isn't building anything now (see the /topic )
<wxl> yeah i guess that's true, jbicha, except for the fact that it's clear that's not true XD
<wxl> again, lubuntu has a fresh release
<wxl> not to mention artful dot one
<jbicha> bionic hasn't changed in a few days anyway
<wxl> it has for lubuntu
<jbicha> I'm guessing it's all related to Meltdown/Spectre; there's no need for bionic dailies right now, but we do need a 17.10 release since 17.04 is nearly EOL
<slangasek> flocculant: sorry, fixes for the code on the tracker are welcome, but in the meantime people will just have to find the correct URLs manually
<flocculant> slangasek: no problem - have a good weekend :)
<wxl> ouch that sucks
#ubuntu-release 2018-01-07
<tsimonq2> wxl, flocculant: There *has* to be a better way to fix this, but I figured out how to manually fix the ISO QA tracker is you're a product administrator. Administration -> Products -> Downloads for a product (under Actions)
<tsimonq2> wxl, flocculant: I'll put in the time to do this manually for Lubuntu unless I can find a script in the QA tracker source
<tsimonq2> If I can brush up on my PHP I'll write a function in that screen to automatically do it unless someone can point me to a script :)
<tsimonq2> (Lubuntu's all fixed now.)
<flocculant> tsimonq2: yea - we saw that - I didn't want to muck about there and break it for other xubuntu releases
<flocculant> I assume you added Artful?
<acheronuk> I looked at Kubuntu, and decided not to mess with it ;)
<tsimonq2> flocculant: yeah
<tsimonq2> flocculant, acheronuk: All you have to do is add duplicate entries that have the exact same values as Xenial
<flocculant> tsimonq2: ty - I didn't remember seeing that on lubuntu there before - glad at least I have a 1 day memory still ;)
<tsimonq2> :)
<acheronuk> tsimonq2: "all you have to do is change the vcs urls in the flavour's meta".....
 * acheronuk hides
<tsimonq2> acheronuk: Oh shush XD
<tsimonq2> That should be fixed now btw
<acheronuk> Kool
<wxl> slangasek: lubuntu alternate is failing to install https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1741713
<ubot5> Launchpad bug 1741713 in debootstrap (Ubuntu) "Lubuntu testcases 'Alternate Install': Debootstrap fails due to dependency problems" [Undecided,Confirmed]
<wxl> slangasek: ubuntu server is also failing to install though not with the same dependencies https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1741782
<ubot5> Launchpad bug 1741782 in debootstrap (Ubuntu) "Artful Dot One Server fails to install due to dependency issues" [Undecided,New]
#ubuntu-release 2018-12-31
<tomreyn> so what's up with "8 years of support"? - https://wiki.ubuntu.com/Releases still states the old state.
<tomreyn> s/8/10/
<tomreyn> https://askubuntu.com/questions/1093582/what-are-the-specifics-of-18-04s-ten-year-support/1093600
<tomreyn> does this refer to ESM then?
<jbicha> tomreyn: yes, the wiki page shows an EOL date for 18.04 ESM
<tomreyn> jbicha, so that's what shuttleworths' 10 y statement referred to?
<jbicha> yes
<tomreyn> thanks for confirming.
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [ppc64el] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [s390x] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [i386] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [armhf] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [arm64] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [arm64] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [amd64] (disco-proposed) [0.0.10-2]
-queuebot:#ubuntu-release- New: accepted openscad [amd64] (disco-proposed) [2015.03-2+dfsg-2.2]
-queuebot:#ubuntu-release- New: accepted python-hgapi [amd64] (disco-proposed) [1.7.3+git20170127.dd8fb7b-1]
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [armhf] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [ppc64el] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [i386] (disco-proposed) [0.0.10-2]
-queuebot:#ubuntu-release- New: accepted python-project-generator-definitions [amd64] (disco-proposed) [0.2.38-1]
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [s390x] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted pyspectral [amd64] (disco-proposed) [0.8.6+ds-1]
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [i386] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [amd64] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [armhf] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [ppc64el] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted openscad [i386] (disco-proposed) [2015.03-2+dfsg-2.2]
-queuebot:#ubuntu-release- New: accepted openscad [s390x] (disco-proposed) [2015.03-2+dfsg-2.2]
-queuebot:#ubuntu-release- New: accepted python-pywebview [amd64] (disco-proposed) [2.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [arm64] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [s390x] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted python-markdown2 [amd64] (disco-proposed) [2.3.7-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [i386] (disco-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted openscad [ppc64el] (disco-proposed) [2015.03-2+dfsg-2.2]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [armhf] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [armhf] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [s390x] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [armhf] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted openscad [i386] (disco-proposed) [2015.03-2+dfsg-2.1]
-queuebot:#ubuntu-release- New: accepted openscad [s390x] (disco-proposed) [2015.03-2+dfsg-2.1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [arm64] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [arm64] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted openscad [ppc64el] (disco-proposed) [2015.03-2+dfsg-2.1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [ppc64el] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted openscad [amd64] (disco-proposed) [2015.03-2+dfsg-2.1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [arm64] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [ppc64el] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [arm64] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [amd64] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [ppc64el] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [i386] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [armhf] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [s390x] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [s390x] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gio [i386] (disco-proposed) [2.0.18-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-atk [amd64] (disco-proposed) [2.0.15-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [i386] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [s390x] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [i386] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [amd64] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [amd64] (disco-proposed) [1.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenu [ppc64el] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [amd64] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-project-generator [amd64] (disco-proposed/universe) [0.9.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [i386] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [s390x] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [ppc64el] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [arm64] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [armhf] (disco-proposed/universe) [2.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [armhf] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [amd64] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [i386] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [s390x] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [arm64] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New: accepted python-project-generator [amd64] (disco-proposed) [0.9.13-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [ppc64el] (disco-proposed) [2.0.16-1]
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [amd64] (disco-proposed/universe) [3.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [ppc64el] (disco-proposed/universe) [3.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [i386] (disco-proposed/universe) [3.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [s390x] (disco-proposed/universe) [3.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [arm64] (disco-proposed/universe) [3.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [armhf] (disco-proposed/universe) [3.0.16-1] (no packageset)
#ubuntu-release 2019-01-01
-queuebot:#ubuntu-release- Unapproved: rejected ukui-menu [source] (cosmic-proposed) [1.1.8-1~2018.1229.1050.1810]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [amd64] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [armhf] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [ppc64el] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [arm64] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [s390x] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [i386] (disco-proposed) [3.0.16-1]
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2018g-0ubuntu0.18.04 => 2018i-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2018g-0ubuntu0.14.04 => 2018i-0ubuntu0.14.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (cosmic-proposed/main) [2018g-0ubuntu0.18.10 => 2018i-0ubuntu0.18.10] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2018g-0ubuntu0.16.04 => 2018i-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2018i-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2018i-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2018i-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (cosmic-proposed) [2018i-0ubuntu0.18.10]
<tsimonq2> Happy New Years.
<tsimonq2> (Well, in ten minutes, but...)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [amd64] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [s390x] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [ppc64el] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [i386] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [armhf] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [arm64] (disco-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [ppc64el] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [i386] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [s390x] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [amd64] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [arm64] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [armhf] (disco-proposed/universe) [3.0.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdatavis3d-everywhere-src [amd64] (disco-proposed/universe) [5.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfarranger [amd64] (disco-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [s390x] (disco-proposed/none) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [s390x] (disco-proposed/none) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [ppc64el] (disco-proposed/none) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [amd64] (disco-proposed/none) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [s390x] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [ppc64el] (disco-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-chai [amd64] (disco-proposed/universe) [4.2.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [i386] (disco-proposed/universe) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [amd64] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [i386] (disco-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [amd64] (disco-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [i386] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [ppc64el] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [arm64] (disco-proposed/universe) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [armhf] (disco-proposed/universe) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [arm64] (disco-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pikepdf [armhf] (disco-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [armhf] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqmatrixclient [arm64] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [i386] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [ppc64el] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [s390x] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [amd64] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [arm64] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [armhf] (disco-proposed/universe) [0.12.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfarranger [amd64] (disco-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: use-package [amd64] (disco-proposed/universe) [2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slirp4netns [amd64] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyninjotiff [amd64] (disco-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slirp4netns [i386] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aioxmpp [amd64] (disco-proposed/universe) [0.10.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: beancount [i386] (disco-proposed/none) [2.1.3+hg20181225-2] (no packageset)
-queuebot:#ubuntu-release- New binary: beancount [s390x] (disco-proposed/none) [2.1.3+hg20181225-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slirp4netns [s390x] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: beancount [amd64] (disco-proposed/none) [2.1.3+hg20181225-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slirp4netns [ppc64el] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-noto [amd64] (disco-proposed/main) [20181227-1] (desktop-core, personal-gunnarhj, ubuntu-server)
-queuebot:#ubuntu-release- New binary: slirp4netns [arm64] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slirp4netns [armhf] (disco-proposed/none) [0.1~git20181119.5e4789b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [amd64] (disco-proposed/universe) [0.6.1~dfsg-3] (no packageset)
#ubuntu-release 2019-01-02
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [ppc64el] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [s390x] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-chai [amd64] (disco-proposed/universe) [4.2.0+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [i386] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [amd64] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [arm64] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-0.5 [armhf] (disco-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [s390x] (disco-proposed/universe) [0.6.1~dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [ppc64el] (disco-proposed/universe) [0.6.1~dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [i386] (disco-proposed/universe) [0.6.1~dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [amd64] (disco-proposed/universe) [0.6.1~dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: valentina [arm64] (disco-proposed/universe) [0.6.1~dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [amd64] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [armhf] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [ppc64el] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted valentina [amd64] (disco-proposed) [0.6.1~dfsg-3]
-queuebot:#ubuntu-release- New: accepted valentina [arm64] (disco-proposed) [0.6.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted valentina [ppc64el] (disco-proposed) [0.6.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [arm64] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [s390x] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted valentina [i386] (disco-proposed) [0.6.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [i386] (disco-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted valentina [s390x] (disco-proposed) [0.6.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted valentina [amd64] (disco-proposed) [0.6.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted fonts-noto [amd64] (disco-proposed) [20181227-1]
-queuebot:#ubuntu-release- New: accepted gitit [arm64] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [i386] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [s390x] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [amd64] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [ppc64el] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [armhf] (disco-proposed) [0.12.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-chai [amd64] (disco-proposed) [4.2.0+ds-3]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [amd64] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [armhf] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [ppc64el] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [arm64] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [s390x] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-0.5 [i386] (disco-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted pikepdf [amd64] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted pikepdf [armhf] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted pikepdf [ppc64el] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted slirp4netns [amd64] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted slirp4netns [armhf] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted slirp4netns [ppc64el] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted pikepdf [arm64] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted pikepdf [s390x] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted slirp4netns [i386] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted pikepdf [i386] (disco-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted slirp4netns [s390x] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted slirp4netns [arm64] (disco-proposed) [0.1~git20181119.5e4789b-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [amd64] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [armhf] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [ppc64el] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [amd64] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [armhf] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [ppc64el] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [arm64] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [s390x] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [i386] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [i386] (disco-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [s390x] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [arm64] (disco-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nats-io-gnatsd [amd64] (disco-proposed) [1.3.0+git20181112.3c52dc8-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pdfarranger [amd64] (disco-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted pyninjotiff [amd64] (disco-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted qtdatavis3d-everywhere-src [amd64] (disco-proposed) [5.11.3-1]
-queuebot:#ubuntu-release- New: accepted node-chai [amd64] (disco-proposed) [4.2.0+ds-2]
-queuebot:#ubuntu-release- New: accepted python-aioxmpp [amd64] (disco-proposed) [0.10.2-1]
-queuebot:#ubuntu-release- New: accepted pdfarranger [amd64] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted use-package [amd64] (disco-proposed) [2.4-1]
-queuebot:#ubuntu-release- New: accepted beancount [amd64] (disco-proposed) [2.1.3+hg20181225-2]
-queuebot:#ubuntu-release- New: accepted beancount [s390x] (disco-proposed) [2.1.3+hg20181225-2]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [arm64] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [i386] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [s390x] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted beancount [i386] (disco-proposed) [2.1.3+hg20181225-2]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [armhf] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [amd64] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libqmatrixclient [ppc64el] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: fava [amd64] (disco-proposed/universe) [1.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [s390x] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [i386] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [amd64] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [s390x] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [i386] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [s390x] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [i386] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [amd64] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [amd64] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [i386] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [ppc64el] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [s390x] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [ppc64el] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [ppc64el] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [ppc64el] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [amd64] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [arm64] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [armhf] (disco-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [arm64] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [armhf] (disco-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [armhf] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [arm64] (disco-proposed/universe) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [arm64] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [armhf] (disco-proposed/universe) [2.91.19-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fava [amd64] (disco-proposed) [1.9-2]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [arm64] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [i386] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [s390x] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [arm64] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [i386] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [s390x] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [arm64] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [i386] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [s390x] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [amd64] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [ppc64el] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [armhf] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [amd64] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [ppc64el] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [arm64] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [i386] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [s390x] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [armhf] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [ppc64el] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [amd64] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [ppc64el] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [amd64] (disco-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [armhf] (disco-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [armhf] (disco-proposed) [2.91.19-1]
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [s390x] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [amd64] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [i386] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [ppc64el] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-termonad [amd64] (disco-proposed/universe) [0.2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [arm64] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [armhf] (disco-proposed/universe) [0.1.5.0-1] (no packageset)
<LocutusOfBorg> plese accept them ^^ termonad builds only on amd64 for now, nd gtk-sni-tray is built everywhere :D
-queuebot:#ubuntu-release- New binary: pymol [s390x] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pymol [ppc64el] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pymol [i386] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [s390x] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [i386] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [ppc64el] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [amd64] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [armhf] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [arm64] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: pymol [armhf] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pymol [amd64] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pymol [arm64] (disco-proposed/universe) [2.2.0+dfsg-4] (no packageset)
<LocutusOfBorg> and pymol is good too!
-queuebot:#ubuntu-release- New: accepted pymol [amd64] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pymol [armhf] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pymol [arm64] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [arm64] (disco-proposed) [0.1.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [ppc64el] (disco-proposed) [0.1.5.0-1]
-queuebot:#ubuntu-release- New: accepted pymol [i386] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pymol [s390x] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [armhf] (disco-proposed) [0.1.5.0-1]
-queuebot:#ubuntu-release- New: accepted pymol [ppc64el] (disco-proposed) [2.2.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted haskell-termonad [amd64] (disco-proposed) [0.2.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [amd64] (disco-proposed) [0.1.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [s390x] (disco-proposed) [0.1.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [i386] (disco-proposed) [0.1.5.0-1]
<LocutusOfBorg> can anybody infra-savvy tell me which socket changes on infrastructure made this test fail? http://autopkgtest.ubuntu.com/packages/b/backuppc/disco/armhf
<LocutusOfBorg> cmdSystemOrEval: finished: got output ping: socket: Operation not permitted
<LocutusOfBorg> cmdSystemOrEval: about to system /bin/ping6 -c 1 localhost
<LocutusOfBorg> this  is what fails I think
<infinity> LocutusOfBorg: I'd assume it's lxc denying the operation.
<LocutusOfBorg> probably, but what is your suggested fix?
<LocutusOfBorg> is an infra bug or should the package stop trying to ping?
<LocutusOfBorg> I would say ping is a safe operation
<Laney> The latest iputils upload is very suspicious, would suggest investigating from there
<Laney> (not here, so can't help you)
<LocutusOfBorg> Laney, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/b/backuppc/20181213_231334_ba7c3@/log.gz
<LocutusOfBorg> this one has the latest iputils and is a good result...
<LocutusOfBorg> timing is interesting anyway
<Laney> Don't bother pinging me back, I can't help you.
<infinity> Ahh, yeah, it's the latest iputils.
<infinity> LocutusOfBorg: The difference between those logs is that the successful one has iputils upgrading, attempting to setcap, failing that, then setting ping suid.
<infinity> LocutusOfBorg: While the failing ones have ping (presumably setcapped) in the rootfs.
<infinity> vorlon: ^-- Thoughts?
<infinity> vorlon: Your upload mentions "... now that we can rely on fscap support everywhere including in lxd" which may be true, but does it mean we need a new lxc/lxd profile on armhf autopkgtest hosts to accomodate?
<infinity> Oh course, iputils-ping isn't in minimal, and this bug would go away if the autopktest roots weren't fat to start with...
<infinity> Er, it's minimal, but not essential.  That.
<vorlon> infinity: hmm my understanding was that no special profile was required but that we needed the latest SRUed version of lxd to land in -updates first.  And that was on lxd 3.0.x so possibly this doesn't work so hot on 16.04-based lxd runners.
<vorlon> infinity: actually the runners seem to have lxd from xenial-backports, but a stale one; so maybe we just need to upgrade
<vorlon> Laney: ^^ thoughts on this?  Should we JFDI?
<vorlon> (I'll take silence for consent, since you're not here)
<jbicha> vorlon: could you handle LP: #1703630 ?
<ubot5> Launchpad bug 1703630 in phoronix-test-suite (Ubuntu) "Please remove phoronix-text-suite from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1703630
<vorlon> infinity, Laney: lxd updated on all the arm64 runners (and fixed the pssh wrapper in the process)
<vorlon> jbicha: done
<vorlon> LocutusOfBorg, infinity: am retrying the failed backuppc test now; I'm not sure if I also need to re-import the lxd images to get it to work, ISTR there was some question about that when I was talking to stgraber about the fscaps thing, so we'll see if this works or if I have more to do
<stgraber> depends on the storage backend used
<stgraber> if using dir, the image is unpacked every time so doesn't matter, if using something else, the unpack would have happened earlier so you should delete the image to force a re-import with a fscaps enabled version of the code
<Laney> ...I probably would have tested that upgrade first...
<Laney> but if it works, good
<Laney> Looks to me like that broke armhf
<Laney> still not here, though, sorry
<Laney> ok, here now, I'll fix that
<Laney> there we go
-queuebot:#ubuntu-release- New binary: kross-interpreters [s390x] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kross-interpreters [amd64] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kross-interpreters [ppc64el] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kross-interpreters [i386] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kross-interpreters [arm64] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kross-interpreters [armhf] (disco-proposed/universe) [4:18.08.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: lix [amd64] (disco-proposed/universe) [0.9.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lix [i386] (disco-proposed/universe) [0.9.23-1] (no packageset)
<Laney> vorlon: Looks like that test still failed.
<Laney> Also, does this mean that iputils doesn't have an autopkgtest? It'd be good to have one that would have caught this.
-queuebot:#ubuntu-release- New binary: lix [armhf] (disco-proposed/universe) [0.9.23-1] (no packageset)
#ubuntu-release 2019-01-03
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [amd64] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [armhf] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [ppc64el] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [amd64] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [armhf] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [ppc64el] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lix [amd64] (disco-proposed) [0.9.23-1]
-queuebot:#ubuntu-release- New: accepted lix [i386] (disco-proposed) [0.9.23-1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [arm64] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [s390x] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [i386] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lix [armhf] (disco-proposed) [0.9.23-1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [i386] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [s390x] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kross-interpreters [arm64] (disco-proposed) [4:18.08.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: med-fichier [ppc64el] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
-queuebot:#ubuntu-release- New binary: med-fichier [amd64] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
-queuebot:#ubuntu-release- New binary: med-fichier [arm64] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted med-fichier [amd64] (disco-proposed) [4.0.0+repack-5]
-queuebot:#ubuntu-release- New: accepted med-fichier [ppc64el] (disco-proposed) [4.0.0+repack-5]
-queuebot:#ubuntu-release- New: accepted med-fichier [arm64] (disco-proposed) [4.0.0+repack-5]
<infinity> Laney: An iputils test wouldn't have caught it, since it works on upgrade.
<infinity> Laney: (on upgrade, it attempts to setcap, fails, and falls back to setuid instead, but if it's already fscapped in the filesystem, sucks to be you)
<LocutusOfBorg> hello all, so still broken...
<LocutusOfBorg> thanks for working on it!
<LocutusOfBorg> btw, can any AA around help hdf5 transition move a little bit forward?
<LocutusOfBorg> we have a lot of NBS in proposed of old libraries that are preventing britney from showing up some result
<LocutusOfBorg> e.g. petsc, hdf5, slepc
<LocutusOfBorg> and some "kick out from release" packages that are FTBFS and out from testing
<LocutusOfBorg> also various meep* packages needs cleanup
<infinity> LocutusOfBorg: petsc, hdf5, slepc, and meep* NBS tidied.
<vorlon> stgraber: btrfs on /var/lib/lxd/storage-pools/default and fscaps apparently don't work?
<vorlon> ah, no, I was cut'n'pasting a buggy command from a maintainer script
<vorlon> ok so the storage backend supports them fine (if I manually set on the filesystem) but if I launch ubuntu-daily:disco it comes in without the fscap
<LocutusOfBorg> infinity, <3
-queuebot:#ubuntu-release- New binary: python3.6 [s390x] (disco-proposed/main) [3.6.8-1] (core)
-queuebot:#ubuntu-release- New binary: python3.6 [amd64] (disco-proposed/main) [3.6.8-1] (core)
-queuebot:#ubuntu-release- New binary: python3.6 [i386] (disco-proposed/main) [3.6.8-1] (core)
-queuebot:#ubuntu-release- New binary: python3.6 [ppc64el] (disco-proposed/main) [3.6.8-1] (core)
-queuebot:#ubuntu-release- New binary: python3.6 [arm64] (disco-proposed/main) [3.6.8-1] (core)
-queuebot:#ubuntu-release- New binary: python3.6 [armhf] (disco-proposed/main) [3.6.8-1] (core)
<infinity> doko: ^-- python3.6?  That was removed less than a month ago, have you decided we need it back for some reason?
<infinity> Oh, that wasn't doko, that was autosync...
 * infinity removes again.
-queuebot:#ubuntu-release- New: rejected python3.6 [amd64] (disco-proposed) [3.6.8-1]
-queuebot:#ubuntu-release- New: rejected python3.6 [armhf] (disco-proposed) [3.6.8-1]
-queuebot:#ubuntu-release- New: rejected python3.6 [ppc64el] (disco-proposed) [3.6.8-1]
-queuebot:#ubuntu-release- New: rejected python3.6 [arm64] (disco-proposed) [3.6.8-1]
-queuebot:#ubuntu-release- New: rejected python3.6 [s390x] (disco-proposed) [3.6.8-1]
-queuebot:#ubuntu-release- New: rejected python3.6 [i386] (disco-proposed) [3.6.8-1]
<stgraber> vorlon: did you try wiping the images that show up in "lxc image list"? so you get a clean download + unpack of the image on the newer LXD?
<tsimonq2> infinity, vorlon, xnox: Could I please get eyes on bug 1810123 from someone when y'all are off EOY break? :)
<ubot5> bug 1810123 in debootstrap (Ubuntu) "Merge debootstrap 1.0.112 from Debian Sid" [Medium,Fix committed] https://launchpad.net/bugs/1810123
<acheronuk> has anyone looked at emacs FTBFS on ppc64el? I ask as that is causing emacs24 (a test dep in the qt transition) to be uninstallable
#ubuntu-release 2019-01-04
-queuebot:#ubuntu-release- New binary: libpillowfight [s390x] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpillowfight [amd64] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpillowfight [ppc64el] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpillowfight [i386] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpillowfight [arm64] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpillowfight [armhf] (disco-proposed/universe) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: refcard [amd64] (disco-proposed/universe) [10.2] (no packageset)
<vorlon> stgraber: yes, I had wiped the image from lxc image list
-queuebot:#ubuntu-release- New: accepted libpillowfight [amd64] (disco-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted libpillowfight [armhf] (disco-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted libpillowfight [ppc64el] (disco-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted refcard [amd64] (disco-proposed) [10.2]
-queuebot:#ubuntu-release- New: accepted libpillowfight [arm64] (disco-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted libpillowfight [s390x] (disco-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted libpillowfight [i386] (disco-proposed) [0.2.4-2]
<acheronuk> reported the emacs fail fyi: LP #1810496
<ubot5> Launchpad bug 1810496 in emacs (Ubuntu) "1:26.1+1-3 FTBFS in disco on ppc64el (test fail)" [Undecided,New] https://launchpad.net/bugs/1810496
<LocutusOfBorg> infinity, we have python3.5 in sync blacklist, and python3.6 has been already autosyncd twice IIRC... what about blacklisting it?
<acheronuk> vorlon infinity or anyone else: could we please skiptest qtbase to make it a candidate? The one remaining failing test on uim ppc64el is due to emacs FTBFS, and not in any way due to qtbase
<acheronuk> ah, same uim ppc64el fail is affecting qtx11extras-opensource-src as well. that would need skiptest as well if we can do that
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (disco-proposed/universe) [1.7.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: dtfabric [amd64] (disco-proposed/universe) [20180808-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (disco-proposed/universe) [1.7.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblouis [s390x] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: apriltag [amd64] (disco-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (disco-proposed/universe) [1.7.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (disco-proposed/universe) [1.7.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblouis [ppc64el] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: orage [amd64] (disco-proposed/universe) [4.12.1-6] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New binary: python-pywebview [amd64] (disco-proposed/universe) [2.2.1+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [s390x] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [s390x] (disco-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouis [i386] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [amd64] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [i386] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [amd64] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepdiff [amd64] (disco-proposed/universe) [3.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-mini-mime [amd64] (disco-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plinth [amd64] (disco-proposed/universe) [0.46.0] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [i386] (disco-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsjtx [amd64] (disco-proposed/universe) [2.0.0+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [ppc64el] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouis [arm64] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [armhf] (disco-proposed/main) [3.8.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (disco-proposed/universe) [1.7.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (disco-proposed/universe) [1.7.0-2] (kubuntu)
#ubuntu-release 2019-01-05
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [arm64] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.2 [armhf] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postgres [amd64] (disco-proposed/universe) [7.7.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [ppc64el] (disco-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: silkaj [amd64] (disco-proposed/none) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted silkaj [amd64] (disco-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (disco-proposed) [1.7.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [amd64] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [armhf] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [ppc64el] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [arm64] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [s390x] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [i386] (disco-proposed) [3.8.0-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [amd64] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [armhf] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [ppc64el] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [arm64] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [s390x] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.2 [i386] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted apriltag [amd64] (disco-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted apriltag [ppc64el] (disco-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted deepdiff [amd64] (disco-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-postgres [amd64] (disco-proposed) [7.7.1-3]
-queuebot:#ubuntu-release- New: accepted plinth [amd64] (disco-proposed) [0.46.0]
-queuebot:#ubuntu-release- New: accepted ruby-mini-mime [amd64] (disco-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted apriltag [i386] (disco-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted dtfabric [amd64] (disco-proposed) [20180808-1.1]
-queuebot:#ubuntu-release- New: accepted python-pywebview [amd64] (disco-proposed) [2.2.1+dfsg-4]
-queuebot:#ubuntu-release- New: accepted apriltag [s390x] (disco-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted wsjtx [amd64] (disco-proposed) [2.0.0+repack-1]
-queuebot:#ubuntu-release- New: accepted orage [amd64] (disco-proposed) [4.12.1-6]
<LocutusOfBorg> hello
<LocutusOfBorg> reverse-depends src:llvm-toolchain-4.0 -r disco <-- GREEN NOW
<LocutusOfBorg> kill it with fire please? apw doko
<LocutusOfBorg> (it has 3 false positive)
-queuebot:#ubuntu-release- New binary: pyphen [amd64] (disco-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-general-soundfont-small [amd64] (disco-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-general-soundfont [amd64] (disco-proposed/universe) [0.1.3-2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: morse-simulator [i386] (disco-proposed/universe) [1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: morse-simulator [amd64] (disco-proposed/universe) [1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: morse-simulator [s390x] (disco-proposed/universe) [1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: morse-simulator [ppc64el] (disco-proposed/universe) [1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: morse-simulator [arm64] (disco-proposed/universe) [1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: morse-simulator [armhf] (disco-proposed/universe) [1.4-4] (no packageset)
#ubuntu-release 2019-01-06
-queuebot:#ubuntu-release- New: accepted morse-simulator [arm64] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New: accepted morse-simulator [armhf] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New: accepted morse-simulator [amd64] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New: accepted morse-simulator [ppc64el] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New: accepted musescore-general-soundfont-small [amd64] (disco-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted pyphen [amd64] (disco-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted morse-simulator [i386] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New: accepted musescore-general-soundfont [amd64] (disco-proposed) [0.1.3-2]
-queuebot:#ubuntu-release- New: accepted morse-simulator [s390x] (disco-proposed) [1.4-4]
-queuebot:#ubuntu-release- New binary: kamailio [s390x] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [amd64] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [i386] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [arm64] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [armhf] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [ppc64el] (disco-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted kamailio [amd64] (disco-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [armhf] (disco-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [ppc64el] (disco-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [arm64] (disco-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [i386] (disco-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [s390x] (disco-proposed) [5.2.0-2]
<vorlon> LocutusOfBorg: reverse-depends src:llvm-toolchain-4.0 -b shows firefox and thunderbird also have build-dependencies on this version, and those are not false positives
<vorlon> acheronuk: it appears that all of your retries of the uim/ppc64el test were done with all-proposed=1, which seems sure to run into the problem with uim-el uninstallability within -proposed, but it's unclear to me that they should have been.  I'm retrying the test with only qt from -proposed, which is better than skiptest
<acheronuk> vorlon: I tried uim normally as well, but IIRC the test decided test decided....
<acheronuk> "autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from disco-proposed"
<acheronuk> like your try did
<acheronuk> this is why I asked for skiptest
<LocutusOfBorg> chrisccoulson, can I switch from llvm-4.0-dev to llvm-dev for firefox and thunderbird? I can switch and upload
<LocutusOfBorg> vorlon, ^^ I see debian is using llvm-dev not the 4.0 version, so it should be safe to swtich
<jbicha> LocutusOfBorg: I think osomon is the current Firefox maintainer for Ubuntu
<acheronuk> vorlon: if you are willing I would quite like to skiptest konsole as well, as that is just blocaked by apport test regression which is entirely valgrind brokeness. However, I will be uploading a new bugfix release of konsole end of next week, so if you do not skiptest the current one it's not the end of the world
<acheronuk> mostly the pink test fail here offends my 'fix it' instinct :D  http://people.ubuntu.com/~rikmills/ka-iron-hand_reports/applications_archive/18.12.0_disco_proposed_migration.pdf
-queuebot:#ubuntu-release- New binary: pdfminer [amd64] (disco-proposed/universe) [20181108+dfsg-1] (no packageset)
<vorlon> acheronuk: ack, now that I can see this I'll follow through on a skiptest.  Why is uim-qt5-immodule uninstallable, though?  it didn't look like this should've been a library transition
<vorlon> LocutusOfBorg: "should be safe" - but hasn't been done yet; until it is, not a candidate for removal
<acheronuk> vorlon: depends emacs24, which  s built for all arches on amd64, but depends on emacs-gtk, which depends on the arch dependant builds of emacs-bin-common = source version. hence in proposed emacs24 -> emacs-gtk requires 1:26.1+1-3 emacs-bin-common on all arches, which doesn't exist on ppc64el due to the FTBFS
<acheronuk> vorlon: thank you
<vorlon> acheronuk: my question is why is the version in the release pocket not installable
<acheronuk> oh. well for Qt at least, uim in release depends qtbase-abi-5-11-2 so will be uninstallable in any test against Qt 5.11.3
#ubuntu-release 2019-12-30
-queuebot:#ubuntu-release- New binary: exactimage [amd64] (focal-proposed/universe) [1.0.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: exactimage [s390x] (focal-proposed/universe) [1.0.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: exactimage [ppc64el] (focal-proposed/universe) [1.0.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: exactimage [armhf] (focal-proposed/universe) [1.0.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: exactimage [arm64] (focal-proposed/universe) [1.0.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis3-survex-import [amd64] (focal-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [amd64] (focal-proposed/none) [1.92.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [amd64] (focal-proposed/universe) [1.92.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [s390x] (focal-proposed/universe) [1.92.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [ppc64el] (focal-proposed/universe) [1.92.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [armhf] (focal-proposed/universe) [1.92.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: avogadrolibs [arm64] (focal-proposed/universe) [1.92.1-3] (no packageset)
#ubuntu-release 2019-12-31
-queuebot:#ubuntu-release- New: accepted avogadrolibs [amd64] (focal-proposed) [1.92.1-2]
-queuebot:#ubuntu-release- New: accepted avogadrolibs [arm64] (focal-proposed) [1.92.1-3]
-queuebot:#ubuntu-release- New: accepted avogadrolibs [ppc64el] (focal-proposed) [1.92.1-3]
-queuebot:#ubuntu-release- New: accepted qgis3-survex-import [amd64] (focal-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted avogadrolibs [amd64] (focal-proposed) [1.92.1-3]
-queuebot:#ubuntu-release- New: accepted avogadrolibs [s390x] (focal-proposed) [1.92.1-3]
-queuebot:#ubuntu-release- New: accepted avogadrolibs [armhf] (focal-proposed) [1.92.1-3]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.5-1 => 1.3.6-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.5-1 => 1.3.6-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.5-1 => 1.3.6-1] (core)
<LocutusOfBorg> vorlon, missing build on i386: python-libbtbb-pcapdump (from 2018.08.R1-2) please?
<LocutusOfBorg> missing build on i386: x11vnc-data (from 0.9.13-6)
<LocutusOfBorg> missing build on i386: python-bx-tools, python3-bx-tools (from 0.8.2-1)
<LocutusOfBorg> also inkscape
<LocutusOfBorg> libsemanage
<LocutusOfBorg> python-ktoblzcheck r-cran-gmm, r-cran-seurat
<LocutusOfBorg> thanks :) and happy new year
-queuebot:#ubuntu-release- New binary: liblivemedia [amd64] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [i386] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [ppc64el] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [s390x] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [arm64] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [armhf] (focal-proposed/universe) [2019.10.11-2] (i386-whitelist, kubuntu)
#ubuntu-release 2020-01-01
-queuebot:#ubuntu-release- New: accepted liblivemedia [armhf] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [amd64] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [i386] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [s390x] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [arm64] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [ppc64el] (focal-proposed) [2019.10.11-2]
-queuebot:#ubuntu-release- Packageset: Added secilc to i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: yade [s390x] (focal-proposed/universe) [2019.12~git~0~e74819ea-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yade [amd64] (focal-proposed/universe) [2019.12~git~0~e74819ea-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yade [ppc64el] (focal-proposed/universe) [2019.12~git~0~e74819ea-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: yade [arm64] (focal-proposed/universe) [2019.12~git~0~e74819ea-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mayavi2 [amd64] (focal-proposed/universe) [4.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mayavi2 [s390x] (focal-proposed/universe) [4.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mayavi2 [armhf] (focal-proposed/universe) [4.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mayavi2 [arm64] (focal-proposed/universe) [4.7.1-1] (no packageset)
<vorlon> LocutusOfBorg: what can we do with llvm-toolchain-9 on i386? you previously dropped z3 as a build-dependency on Ubuntu, but now it's back and we definitely don't want it on i386
<vorlon> its dependencies are horrible
<vorlon> LocutusOfBorg: also, took care of all the other missing-build-oni386 that you pointed out; some of them were /not/ appropriate for binary removal, they were e.g. dep-waits (libsemanage has a new build-dep on secilc) or were whitelisted but got caught without binaries and needed rebuilt (inkscape)
-queuebot:#ubuntu-release- New binary: psi4 [s390x] (focal-proposed/universe) [1:1.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: psi4 [amd64] (focal-proposed/universe) [1:1.3.2-2] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added libwnck3 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libxfce4ui to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libxfce4util to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libxpresent to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libxres to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added rxtx to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added startup-notification to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added xfconf to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added xfwm4 to i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: psi4 [ppc64el] (focal-proposed/universe) [1:1.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: psi4 [arm64] (focal-proposed/universe) [1:1.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: psi4 [armhf] (focal-proposed/universe) [1:1.3.2-2] (no packageset)
<LocutusOfBorg> thanks vorlon I knew something were dep-wait, but I wasn't aware of the "solution" :)
<LocutusOfBorg> wrt llvm-toolchain-9 I don't see it "back", can you please elaborate?
<LocutusOfBorg> now some of the stuff you removed on i386 before, has failing autopkgtests...
-queuebot:#ubuntu-release- New: accepted mayavi2 [arm64] (focal-proposed) [4.7.1-1]
-queuebot:#ubuntu-release- New: accepted mayavi2 [s390x] (focal-proposed) [4.7.1-1]
-queuebot:#ubuntu-release- New: accepted psi4 [arm64] (focal-proposed) [1:1.3.2-2]
-queuebot:#ubuntu-release- New: accepted psi4 [ppc64el] (focal-proposed) [1:1.3.2-2]
-queuebot:#ubuntu-release- New: accepted mayavi2 [armhf] (focal-proposed) [4.7.1-1]
-queuebot:#ubuntu-release- New: accepted psi4 [armhf] (focal-proposed) [1:1.3.2-2]
-queuebot:#ubuntu-release- New: accepted psi4 [amd64] (focal-proposed) [1:1.3.2-2]
-queuebot:#ubuntu-release- New: accepted psi4 [s390x] (focal-proposed) [1:1.3.2-2]
-queuebot:#ubuntu-release- New: accepted mayavi2 [amd64] (focal-proposed) [4.7.1-1]
-queuebot:#ubuntu-release- New binary: ruby-jekyll-compose [amd64] (focal-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-unidecode [amd64] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ausweisapp2 [s390x] (focal-proposed/universe) [1.18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ausweisapp2 [ppc64el] (focal-proposed/universe) [1.18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ausweisapp2 [amd64] (focal-proposed/universe) [1.18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ausweisapp2 [armhf] (focal-proposed/universe) [1.18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ausweisapp2 [arm64] (focal-proposed/universe) [1.18.2-1] (no packageset)
#ubuntu-release 2020-01-02
-queuebot:#ubuntu-release- New: accepted ausweisapp2 [amd64] (focal-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted ausweisapp2 [armhf] (focal-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted ausweisapp2 [s390x] (focal-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted ausweisapp2 [arm64] (focal-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted ausweisapp2 [ppc64el] (focal-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-compose [amd64] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-unidecode [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: cppunit [i386] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [amd64] (focal-proposed/universe) [0.9.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppunit [ppc64el] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: dleyna-core [amd64] (focal-proposed/universe) [0.6.0-3] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: dleyna-core [s390x] (focal-proposed/universe) [0.6.0-3] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: cppunit [s390x] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: golang-github-oklog-run [amd64] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dleyna-core [ppc64el] (focal-proposed/universe) [0.6.0-3] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: cppunit [amd64] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [ppc64el] (focal-proposed/universe) [0.9.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dleyna-core [arm64] (focal-proposed/universe) [0.6.0-3] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [armhf] (focal-proposed/universe) [0.9.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dleyna-core [armhf] (focal-proposed/universe) [0.6.0-3] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [s390x] (focal-proposed/universe) [0.9.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppunit [arm64] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [arm64] (focal-proposed/universe) [0.9.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cppunit [armhf] (focal-proposed/universe) [1.15.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: cqrlog [amd64] (focal-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: galera-4 [amd64] (focal-proposed/universe) [26.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: galera-4 [ppc64el] (focal-proposed/universe) [26.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: galera-4 [s390x] (focal-proposed/universe) [26.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: galera-4 [arm64] (focal-proposed/universe) [26.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: galera-4 [armhf] (focal-proposed/universe) [26.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [s390x] (focal-proposed/main) [1:9.0.1-3] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: x2goclient (bionic-proposed/universe) [4.1.1.1-2 => 4.1.1.1-2ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: x2goclient (xenial-proposed/universe) [4.0.5.1-1 => 4.0.5.1-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: x2goclient (eoan-proposed/universe) [4.1.2.1-2 => 4.1.2.1-2ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [ppc64el] (focal-proposed/main) [1:9.0.1-3] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [s390x] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [ppc64el] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (focal-proposed/universe) [0.49~exp2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gsequencer [s390x] (focal-proposed/universe) [3.0.0~alpha3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [amd64] (focal-proposed/universe) [3.0.0~alpha3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [ppc64el] (focal-proposed/universe) [3.0.0~alpha3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [i386] (focal-proposed/main) [1:9.0.1-3] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: golang-github-oklog-run [amd64] (focal-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [armhf] (focal-proposed/universe) [3.0.0~alpha3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.4 [amd64] (focal-proposed/universe) [5.4.0-1001.2] (no packageset)
<LocutusOfBorg> is it possible to have some binary new queue reviewed?
<LocutusOfBorg> e.g. yade
-queuebot:#ubuntu-release- New binary: gsequencer [arm64] (focal-proposed/universe) [3.0.0~alpha3-1~build1] (no packageset)
<tumbleweed> are we doing removals for python2-only stuff that got dropped from testing in Debian?
<tumbleweed> (or should I do uploads re-adding python2 support)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [amd64] (focal-proposed/main) [1:9.0.1-3] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted cppunit [amd64] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted cppunit [armhf] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted cppunit [s390x] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted cppunit [arm64] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted cppunit [ppc64el] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted cppunit [i386] (focal-proposed) [1.15.1-2]
-queuebot:#ubuntu-release- New: accepted dleyna-core [amd64] (focal-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted dleyna-core [armhf] (focal-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted dleyna-core [s390x] (focal-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted galera-4 [arm64] (focal-proposed) [26.4.3-2]
-queuebot:#ubuntu-release- New: accepted galera-4 [ppc64el] (focal-proposed) [26.4.3-2]
-queuebot:#ubuntu-release- New: accepted golang-github-oklog-run [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted cqrlog [amd64] (focal-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted dleyna-core [ppc64el] (focal-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted galera-4 [armhf] (focal-proposed) [26.4.3-2]
-queuebot:#ubuntu-release- New: accepted golang-github-oklog-run [amd64] (focal-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted dleyna-core [arm64] (focal-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted galera-4 [s390x] (focal-proposed) [26.4.3-2]
-queuebot:#ubuntu-release- New: accepted galera-4 [amd64] (focal-proposed) [26.4.3-2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [s390x] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [arm64] (focal-proposed) [0.9.32-1]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [ppc64el] (focal-proposed) [0.9.32-1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [amd64] (focal-proposed) [0.9.32-1]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [s390x] (focal-proposed) [0.9.32-1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [ppc64el] (focal-proposed) [0.49~exp2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [armhf] (focal-proposed) [0.9.32-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [amd64] (focal-proposed) [1:9.0.1-3]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [ppc64el] (focal-proposed) [1:9.0.1-3]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [i386] (focal-proposed) [1:9.0.1-3]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [s390x] (focal-proposed) [1:9.0.1-3]
<LocutusOfBorg> please accept yade thanks
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src [amd64] (focal-proposed/universe) [5.12.5-5] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src [amd64] (focal-proposed) [5.12.5-5]
-queuebot:#ubuntu-release- New: accepted net-snmp [amd64] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted net-snmp [armhf] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted net-snmp [ppc64el] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted net-snmp [arm64] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted net-snmp [s390x] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted net-snmp [i386] (focal-proposed) [5.8+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-panel [amd64] (focal-proposed) [1:3.35.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-panel [armhf] (focal-proposed) [1:3.35.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-panel [s390x] (focal-proposed) [1:3.35.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-panel [arm64] (focal-proposed) [1:3.35.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-panel [ppc64el] (focal-proposed) [1:3.35.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted exactimage [amd64] (focal-proposed) [1.0.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted exactimage [armhf] (focal-proposed) [1.0.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted exactimage [s390x] (focal-proposed) [1.0.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted exactimage [arm64] (focal-proposed) [1.0.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted exactimage [ppc64el] (focal-proposed) [1.0.2-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted yade [amd64] (focal-proposed) [2019.12~git~0~e74819ea-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted yade [ppc64el] (focal-proposed) [2019.12~git~0~e74819ea-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted yade [arm64] (focal-proposed) [2019.12~git~0~e74819ea-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted yade [s390x] (focal-proposed) [2019.12~git~0~e74819ea-6ubuntu1]
-queuebot:#ubuntu-release- New binary: dpkg-source-gitarchive [amd64] (focal-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath [s390x] (focal-proposed/none) [0.180-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-db-embl-perl [amd64] (focal-proposed/none) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paperwork [amd64] (focal-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ttf-parser [amd64] (focal-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xcb-proto [amd64] (focal-proposed/universe) [1.13-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rust-ttf-parser [s390x] (focal-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-openshift-api [amd64] (focal-proposed/universe) [4.0+git20190508.81d064c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath [amd64] (focal-proposed/universe) [0.180-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-sil-shimenkan [amd64] (focal-proposed/universe) [1.000-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath [arm64] (focal-proposed/universe) [0.180-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath [ppc64el] (focal-proposed/universe) [0.180-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ttf-parser [armhf] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath [armhf] (focal-proposed/universe) [0.180-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ttf-parser [ppc64el] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ttf-parser [arm64] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dpkg-source-gitarchive [amd64] (focal-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted fonts-sil-shimenkan [amd64] (focal-proposed) [1.000-1]
-queuebot:#ubuntu-release- New: accepted libbio-db-embl-perl [amd64] (focal-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New: accepted metamath [arm64] (focal-proposed) [0.180-1]
-queuebot:#ubuntu-release- New: accepted metamath [ppc64el] (focal-proposed) [0.180-1]
-queuebot:#ubuntu-release- New: accepted paperwork [amd64] (focal-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ttf-parser [arm64] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ttf-parser [ppc64el] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted xcb-proto [amd64] (focal-proposed) [1.13-2]
-queuebot:#ubuntu-release- New: accepted golang-github-openshift-api [amd64] (focal-proposed) [4.0+git20190508.81d064c-1]
-queuebot:#ubuntu-release- New: accepted metamath [armhf] (focal-proposed) [0.180-1]
-queuebot:#ubuntu-release- New: accepted rust-ttf-parser [amd64] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ttf-parser [s390x] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted metamath [amd64] (focal-proposed) [0.180-1]
-queuebot:#ubuntu-release- New: accepted rust-ttf-parser [armhf] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted metamath [s390x] (focal-proposed) [0.180-1]
#ubuntu-release 2020-01-03
<LocutusOfBorg> pcscd/i386 unsatisfiable Depends: libccid (>= 1.4.1~) | pcsc-ifd-handler
<LocutusOfBorg> vorlon, ^^
<LocutusOfBorg> not sure what is missing
-queuebot:#ubuntu-release- New binary: rust-log-reroute [amd64] (focal-proposed/none) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-code.cloudfoundry-bytefmt [amd64] (focal-proposed/none) [0.0~git20190818.854d396-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-daemonize [amd64] (focal-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-listenfd [amd64] (focal-proposed/none) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsharp [amd64] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topline [amd64] (focal-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-json [amd64] (focal-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyml [amd64] (focal-proposed/none) [20190626-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wofi [amd64] (focal-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyml [s390x] (focal-proposed/none) [20190626-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyml [ppc64el] (focal-proposed/none) [20190626-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (focal-proposed/universe) [3.9.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-daemonize [s390x] (focal-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (focal-proposed/universe) [3.9.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (focal-proposed/universe) [3.9.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-json [s390x] (focal-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-listenfd [s390x] (focal-proposed/none) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyml [arm64] (focal-proposed/universe) [20190626-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-daemonize [ppc64el] (focal-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyml [armhf] (focal-proposed/universe) [20190626-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-daemonize [armhf] (focal-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-log-reroute [s390x] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-daemonize [arm64] (focal-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topline [s390x] (focal-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-json [ppc64el] (focal-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsharp [s390x] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-listenfd [arm64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-listenfd [ppc64el] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-log-reroute [armhf] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topline [arm64] (focal-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topline [ppc64el] (focal-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vala [s390x] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: wofi [s390x] (focal-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-json [armhf] (focal-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-log-reroute [arm64] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topline [armhf] (focal-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wofi [armhf] (focal-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-listenfd [armhf] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vala [amd64] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rust-log-reroute [ppc64el] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsharp [arm64] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-json [arm64] (focal-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wofi [arm64] (focal-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsharp [armhf] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wofi [ppc64el] (focal-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vala [i386] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libsharp [ppc64el] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (focal-proposed/universe) [3.9.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (focal-proposed/universe) [3.9.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (focal-proposed/universe) [0.46.5-1.2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted golang-code.cloudfoundry-bytefmt [amd64] (focal-proposed) [0.0~git20190818.854d396-1]
-queuebot:#ubuntu-release- New: accepted libsharp [armhf] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libsharp [s390x] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libsharp [arm64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libsharp [ppc64el] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libsharp [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted pyml [arm64] (focal-proposed) [20190626-1]
-queuebot:#ubuntu-release- New: accepted pyml [ppc64el] (focal-proposed) [20190626-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (focal-proposed) [3.9.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (focal-proposed) [3.9.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (focal-proposed) [3.9.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pyml [amd64] (focal-proposed) [20190626-1]
-queuebot:#ubuntu-release- New: accepted pyml [s390x] (focal-proposed) [20190626-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (focal-proposed) [3.9.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pyml [armhf] (focal-proposed) [20190626-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (focal-proposed) [3.9.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-daemonize [amd64] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-daemonize [armhf] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-daemonize [s390x] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-daemonize [arm64] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-daemonize [ppc64el] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-json [arm64] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-json [ppc64el] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-json [armhf] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-json [s390x] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-json [amd64] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-listenfd [arm64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-listenfd [ppc64el] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-listenfd [amd64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-listenfd [s390x] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-listenfd [armhf] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-log-reroute [amd64] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-log-reroute [armhf] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-log-reroute [s390x] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted topline [arm64] (focal-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted topline [ppc64el] (focal-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted vala [amd64] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New: accepted wofi [amd64] (focal-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted wofi [armhf] (focal-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-log-reroute [arm64] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted topline [amd64] (focal-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted topline [s390x] (focal-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New: accepted wofi [arm64] (focal-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted wofi [s390x] (focal-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-log-reroute [ppc64el] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New: accepted wofi [ppc64el] (focal-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted topline [armhf] (focal-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (focal-proposed) [0.46.5-1.2]
-queuebot:#ubuntu-release- New binary: xgridfit [amd64] (focal-proposed/none) [2.3-4] (no packageset)
<vorlon> LocutusOfBorg: pcscd is a non-whitelisted binary built from whitelisted source, and its binary dependencies are not guaranteed to be whitelisted as a result of pcsc-lite's build-dependencies.  So pcsc-lite needs adjusted to not build pcscd on Ubuntu/i386
<vorlon> this is on the uninstallable list already for focal: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt
<LocutusOfBorg> vorlon, autopkgtest for esys-particle/2.3.5+dfsg1-4~build1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Regression â» , ppc64el: Pass, s390x: Pass
<LocutusOfBorg>  please?
<LocutusOfBorg> it should make boost look less sad and migrate something
 * LocutusOfBorg leaves
-queuebot:#ubuntu-release- New binary: golang-github-sylabs-sif [amd64] (focal-proposed/none) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block [s390x] (focal-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-modes [amd64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block [amd64] (focal-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-modes [s390x] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block [ppc64el] (focal-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-modes [ppc64el] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cstr-argument [ppc64el] (focal-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dbus-0.2 [s390x] (focal-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cstr-argument [amd64] (focal-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cstr-argument [s390x] (focal-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block [arm64] (focal-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dbus-0.2 [ppc64el] (focal-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block [armhf] (focal-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-modes [arm64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-block-modes [armhf] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cstr-argument [arm64] (focal-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex-literal-impl [s390x] (focal-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex-literal-impl [ppc64el] (focal-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hkdf [s390x] (focal-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-db-ncbihelper-perl [amd64] (focal-proposed/universe) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dbus-0.2 [arm64] (focal-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hkdf [amd64] (focal-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-malloc-buf [amd64] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-malloc-buf [s390x] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unindent [s390x] (focal-proposed/none) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cstr-argument [armhf] (focal-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hkdf [ppc64el] (focal-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unindent [ppc64el] (focal-proposed/none) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dbus-0.2 [armhf] (focal-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unix-socket [s390x] (focal-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-malloc-buf [ppc64el] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unix-socket [ppc64el] (focal-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unwrap [s390x] (focal-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unwrap [amd64] (focal-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hkdf [arm64] (focal-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unix-socket [amd64] (focal-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hkdf [armhf] (focal-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unwrap [ppc64el] (focal-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-malloc-buf [arm64] (focal-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unindent [amd64] (focal-proposed/none) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex-literal-impl [arm64] (focal-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stacer [s390x] (focal-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex-literal-impl [armhf] (focal-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dbus-0.2 [amd64] (focal-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unindent [arm64] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stacer [amd64] (focal-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex-literal-impl [amd64] (focal-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stacer [ppc64el] (focal-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unwrap [arm64] (focal-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-malloc-buf [armhf] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unix-socket [arm64] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unwrap [armhf] (focal-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unindent [armhf] (focal-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unix-socket [armhf] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stacer [arm64] (focal-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stacer [armhf] (focal-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-unindent [armhf] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted stacer [armhf] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted stacer [arm64] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dbus-0.2 [amd64] (focal-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-unix-socket [arm64] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unwrap [arm64] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted stacer [amd64] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-malloc-buf [armhf] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unwrap [armhf] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unix-socket [armhf] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hex-literal-impl [amd64] (focal-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hex-literal-impl [armhf] (focal-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unindent [arm64] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted stacer [s390x] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hex-literal-impl [arm64] (focal-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted stacer [ppc64el] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unindent [amd64] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-hkdf [arm64] (focal-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-malloc-buf [arm64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unwrap [amd64] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unwrap [s390x] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hkdf [armhf] (focal-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unwrap [ppc64el] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unix-socket [amd64] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted libbio-db-ncbihelper-perl [amd64] (focal-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New: accepted rust-dbus-0.2 [arm64] (focal-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-malloc-buf [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unindent [ppc64el] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-unix-socket [ppc64el] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cstr-argument [armhf] (focal-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-malloc-buf [ppc64el] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unix-socket [s390x] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dbus-0.2 [armhf] (focal-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-unindent [s390x] (focal-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-block-modes [arm64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-hex-literal-impl [ppc64el] (focal-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hkdf [amd64] (focal-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hkdf [s390x] (focal-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cstr-argument [arm64] (focal-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hkdf [ppc64el] (focal-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hex-literal-impl [s390x] (focal-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-malloc-buf [s390x] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-block-modes [amd64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-block-modes [ppc64el] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-block [armhf] (focal-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-cstr-argument [ppc64el] (focal-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dbus-0.2 [ppc64el] (focal-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-block-modes [armhf] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cstr-argument [amd64] (focal-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dbus-0.2 [s390x] (focal-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-block [arm64] (focal-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-cstr-argument [s390x] (focal-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sylabs-sif [amd64] (focal-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted rust-block [amd64] (focal-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-block [s390x] (focal-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-block-modes [s390x] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted xgridfit [amd64] (focal-proposed) [2.3-4]
-queuebot:#ubuntu-release- New: accepted rust-block [ppc64el] (focal-proposed) [0.1.6-1]
#ubuntu-release 2020-01-04
-queuebot:#ubuntu-release- New binary: libbio-procedural-perl [amd64] (focal-proposed/universe) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-variation-perl [amd64] (focal-proposed/universe) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-cristifalcas-etcd [amd64] (focal-proposed/universe) [1.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [amd64] (focal-proposed/universe) [3.0.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [s390x] (focal-proposed/universe) [3.0.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [ppc64el] (focal-proposed/universe) [3.0.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [arm64] (focal-proposed/universe) [3.0.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsequencer [armhf] (focal-proposed/universe) [3.0.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gsequencer [amd64] (focal-proposed) [3.0.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted gsequencer [armhf] (focal-proposed) [3.0.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted gsequencer [s390x] (focal-proposed) [3.0.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted gsequencer [arm64] (focal-proposed) [3.0.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted gsequencer [ppc64el] (focal-proposed) [3.0.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted libbio-procedural-perl [amd64] (focal-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-cristifalcas-etcd [amd64] (focal-proposed) [1.12.3-1]
-queuebot:#ubuntu-release- New: accepted libbio-variation-perl [amd64] (focal-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New binary: r-cran-robust [amd64] (focal-proposed/universe) [0.4-18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-robust [ppc64el] (focal-proposed/universe) [0.4-18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-robust [s390x] (focal-proposed/universe) [0.4-18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-robust [arm64] (focal-proposed/universe) [0.4-18.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-robust [armhf] (focal-proposed/universe) [0.4-18.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-robust [amd64] (focal-proposed) [0.4-18.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-robust [armhf] (focal-proposed) [0.4-18.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-robust [s390x] (focal-proposed) [0.4-18.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-robust [arm64] (focal-proposed) [0.4-18.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-robust [ppc64el] (focal-proposed) [0.4-18.2-1]
-queuebot:#ubuntu-release- New binary: r-cran-wgcna [s390x] (focal-proposed/universe) [1.68-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-wgcna [s390x] (focal-proposed) [1.68-2]
-queuebot:#ubuntu-release- New binary: exec-path-from-shell-el [amd64] (focal-proposed/none) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-msoffcrypto-tool [amd64] (focal-proposed/none) [4.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gpsoauth [amd64] (focal-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docker-systemctl-replacement [amd64] (focal-proposed/none) [1.4.3424-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modeldata [amd64] (focal-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-heapy [amd64] (focal-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-itertools [amd64] (focal-proposed/none) [0.1-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (focal-proposed/universe) [4.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zarr [amd64] (focal-proposed/none) [2.3.2+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (focal-proposed/universe) [4.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (focal-proposed/universe) [4.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (focal-proposed/universe) [4.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (focal-proposed/universe) [4.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pysph [amd64] (focal-proposed/universe) [1.0~b0~20191115.gite3d5e10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src-gles [s390x] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src-gles [amd64] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src-gles [ppc64el] (focal-proposed/universe) [5.12.5-2] (no packageset)
#ubuntu-release 2020-01-05
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src-gles [arm64] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-opensource-src-gles [armhf] (focal-proposed/universe) [5.12.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ez-vcard [amd64] (focal-proposed/none) [0.10.5+ds+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pysurfer [amd64] (focal-proposed/none) [0.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: docker-systemctl-replacement [amd64] (focal-proposed/universe) [1.4.3424-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-modeldata [amd64] (focal-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: zarr [amd64] (focal-proposed/universe) [2.3.2+ds-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted docker-systemctl-replacement [amd64] (focal-proposed) [1.4.3424-1]
-queuebot:#ubuntu-release- New: accepted exec-path-from-shell-el [amd64] (focal-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted docker-systemctl-replacement [amd64] (focal-proposed) [1.4.3424-2]
-queuebot:#ubuntu-release- New: accepted ez-vcard [amd64] (focal-proposed) [0.10.5+ds+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted pysurfer [amd64] (focal-proposed) [0.9.0-3]
-queuebot:#ubuntu-release- New: accepted python-msoffcrypto-tool [amd64] (focal-proposed) [4.10.1-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src-gles [arm64] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src-gles [ppc64el] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted r-cran-itertools [amd64] (focal-proposed) [0.1-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modeldata [amd64] (focal-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (focal-proposed) [4.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (focal-proposed) [4.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pysph [amd64] (focal-proposed) [1.0~b0~20191115.gite3d5e10-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src-gles [amd64] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src-gles [s390x] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (focal-proposed) [4.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (focal-proposed) [4.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-gpsoauth [amd64] (focal-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-modeldata [amd64] (focal-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-opensource-src-gles [armhf] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (focal-proposed) [4.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-heapy [amd64] (focal-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted zarr [amd64] (focal-proposed) [2.3.2+ds-2]
-queuebot:#ubuntu-release- New: accepted zarr [amd64] (focal-proposed) [2.3.2+ds-1]
-queuebot:#ubuntu-release- New binary: python-gmusicapi [amd64] (focal-proposed/universe) [12.1.1-1] (no packageset)
