#ubuntu-release 2010-10-25
<ScottK> Done.
#ubuntu-release 2010-10-26
 * lamont thinks maybe we're past maverick release coordination
* cjwatson changed the topic of #ubuntu-release to: Natty Narwhal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or car insurance ads | melior malum quod cognoscis
<cjwatson> lamont: a fair point
<cjwatson> hmm
<lamont> cjwatson: and while you're here...  is it still trivial to do a ubuntu-standard install from an alternate CD?
* cjwatson changed the topic of #ubuntu-release to: Natty Narwhal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or whale food | melior malum quod cognoscis
 * lamont hands cjwatson a ton of plankton
<cjwatson> lamont: boot with priority=medium and then you'll get to choose
<lamont> ah, cool
<cjwatson> or did you want that entirely preseeded?
<lamont> really don't care
<cjwatson> that's a bit trickier 'cos any command-line preseeding of tasksel/first will be overridden by the CD's preseed file
<cjwatson> ok
<lamont> just don't want to download a server cd
<lamont> [ ] # <-- wtf language is that?
<lamont> locale, ethat is
<cjwatson> it's bug 465120 - will be fixed when we next merge localechooser
<ubot4`> Launchpad bug 465120 in localechooser (Ubuntu) ""Choose language" dialog to select additional locales has two "#" locales (affects: 1) (heat: 12)" [Low,Confirmed] https://launchpad.net/bugs/465120
<cjwatson> (IIRC)
<lamont> precisely that. ta
<lamont> ISTR we used to have an alternate preseed file on the cd
<cjwatson> lamont: don't remember one
<cjwatson> I guess there might have been a server seed at one point
<lamont> meh. something tells me that I should have removed the preseed=
<cjwatson> lamont: ought to work with the preseed=
<cjwatson> there's a special thing in there to DTRT if priority=medium (or low)
<lamont> cjwatson: it defaulted to installing desktop without asking about package selection
<cjwatson> at priority=medium?  that is a bug
<cjwatson> not sure where though :-)
#ubuntu-release 2010-10-28
<lamont> yes, they're all on manual.
#ubuntu-release 2011-10-24
<Laney> ping about backports awaiting processing
<cjwatson> Laney: fair point
<cjwatson> Laney: does bug 877842 supersede bug 871811?
<ubot4> Launchpad bug 877842 in oneiric-backports (and 1 other project) "Please backport memcached 1.4.9-0ubuntu1 from precise to natty and oneiric (affects: 1) (heat: 8)" [Wishlist,In progress] https://launchpad.net/bugs/877842
<ubot4> Launchpad bug 871811 in natty-backports "Please backport memcached 1.4.7-0.1ubuntu1 from oneiric to natty (affects: 1) (heat: 8)" [Wishlist,In progress] https://launchpad.net/bugs/871811
<Laney> erm, don't know what scott intended there
<Laney> but I guess so
<Laney> the former was before 1.4.9 was uploaded
<cjwatson> I'll mark 871811 as a dup then
<Laney> won't fixed.
<cjwatson> Laney: can't process bug 802044, newer version in oneiric
<ubot4> Launchpad bug 802044 in natty-backports "Please backport nspluginwrapper 1.4.2-0ubuntu2 (affects: 2) (heat: 6)" [Undecided,In progress] https://launchpad.net/bugs/802044
<Laney> bdrung: ^
<cjwatson> (I realise that's my fault for not having processed the backport in the relevant time window in July ...)
<Laney> :-)
<Laney> good to know that you can only do the newest version, hadn't considered that
<cjwatson> well, at least not without hackery, and I think it's better to backport things that are current *somewhere*
<Laney> aye
<cjwatson> non-current versions probably ought to be manual uploads
<Laney> Means that, especially early on in the cycle, it's important to keep track of versions.
<cjwatson> queue flushed now aside from nspluginwrapper
<Laney> ty
<Laney> you can unsubscribe the archive from that bug
<cjwatson> done
<cjwatson> (should it still be In Progress?)
<Laney> oh, I could have done it, didn't know
<Laney> no, fixing and pinging
<cjwatson> thanks
 * cjwatson moves the transition tracker cron job 14 minutes earlier (to 41)
<Laney> publisher avoidance?
<cjwatson> no, I made it use a different mirroring system which lets it run earlier
<cjwatson> and running earlier is good because it gives you a better chance of uploading earlier
<cjwatson> (it now hooks off the special ubuntu-archive rsync module that lets us mirror dists directly from cocoplum, rather than having to wait for archive and ports to sync)
<Laney> ah, nice
<stgraber> skaet, jibel: I can now add sites, products and testcases without requiring DB access to the tracker!
<skaet> stgraber,  great!!!  :)
<stgraber> skaet: I should have the admin UI done today, then will try to implement as much of the user UI as I can before UDS
<skaet> stgraber,  very cool.  :)   Let me know if you need help testing at any point.
<stgraber> I'll probably update my canonistack instance with the tracker code once the admin UI is done so you can start playing with it :)
<skaet> :)
<stgraber> http://91.189.93.73 is the canonistack instance. At least SSO login and the rest of Drupal should be working. Will be refreshed tonight hopefully.
<slangasek> tumbleweed: ubuntu-dev-tools was copied to -updates, so I guess the way is clear for an upload of 880051
<tumbleweed> slangasek: uploaded this morning
<slangasek> oh
<slangasek> right, that's kind a sorta what you said this morning already :P
<slangasek> let me process it then :)
<tumbleweed> heh, thanks
#ubuntu-release 2011-10-25
<stgraber> skaet: http://91.189.93.73/admin/config/services/qatracker is the new ISO tracker admin UI
<stgraber> skaet: you need to be part of ~ubuntu-release to have access to that (SSO should send that info to the new tracker)
<stgraber> infinity: did the SSO integration work for you?
<infinity> stgraber: It forwarded me somewhere bizarre, but it worked.
<infinity> stgraber: Though, it didn't check my group membership by default, I had to tick the box.  Maybe there's something you have to feed it to have it ticked?  I dunno.
<infinity> (Minor nitpick, though)
<jamespage> doko_, around? - could do with a second opinion on way forward for maven-repo-helper/markdown MIR
<doko_> jamespage, sure
<jamespage> doko: great - so the latest and greatest of maven-repo-helper includes documentation!!!
<jamespage> w00t
<jamespage> but it uses markdown to generate the HTML docs that get published in the .deb's
<jamespage> we don't appear to have a markdown equivalent in main already; the markdown package is up-to-date with upstream
<jamespage> but is very old
<jamespage> so 1) I could proposed moving to rst format for the source documentation in Debian and use python-docutils
<jamespage> or 2) we could just MIR markdown as its part of the build-chain only
<jamespage> doko: any preference - I'll do the work either way - but 2) will probably be quicker as I would want to get agreement with the Debian maintainers first
<jamespage> for 1)
<doko> jamespage, I remember that I disabled the docs for a similiar case (can't remember which one), so disabling it now, then moving to rst would be my preference
<doko> bug 2) would be fine too
<ubot4> doko: Error: Bug #2 not found.
<doko> but even
<doko> but it does have bug 829377 and bug 853962
<ubot4> Launchpad bug 829377 in markdown (Ubuntu) "package markdown (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/markdown', which is also in package python-markdown 0:2.0.3-1 (affects: 1) (heat: 4)" [Undecided,New] https://launchpad.net/bugs/829377
<ubot4> Launchpad bug 853962 in markdown (Ubuntu) "package markdown 1.0.1-7 failed to install/upgrade: trying to overwrite '/usr/bin/markdown', which is also in package python-markdown 0:2.0.3-1 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/853962
<jamespage> doko: OK - lemme take a look at those
<jamespage> I will raise the move to rst in Debian
<jamespage> but we should be able to fixup Ubuntu in the short term one way or another :-)
<Laney> those bugs can be closed
<Laney> python-markdown -2 doesn't ship that binary any more
<doko> jamespage, hmm, looking at markdown, I really don't care if we promote it
<jamespage> doko: ack - lemme raise the MIR then
<jamespage> doko: on second thoughts I just checked in Debian - I don't think we should MIR it
<jamespage> I'm going to disable the documentation for the time being and push for rst migration in Debian
<doko> ok
#ubuntu-release 2011-10-26
<slangasek> hrm.  why is syncpackage telling me that freetype is blacklisted, when precise has 2.4.7-1?
 * slangasek forgets where the webpage is that shows the LP blacklist
<Laney> https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=freetype&field.package_type=all&field.package_type-empty-marker=1
<slangasek> ta
<Laney> as for "why", no idea
<Laney> but archive admins can turn it off there
<tumbleweed> there's a bug in the auto blacklisting
<Laney> probably because it ahead of wheezy
<slangasek> tumbleweed: is there a bug #?
<tumbleweed> bug 841372
<ubot4> Launchpad bug 841372 in launchpad "Incorrect auto-blacklisting in DSD? (affects: 1) (heat: 27)" [Low,Triaged] https://launchpad.net/bugs/841372
<slangasek> Laney: I didn't get this previously for packages I synced from unstable
<tumbleweed> yeah it happens randomly with some packages
<Laney> ok, maybe that bug then
<tumbleweed> well presumably not randomly :)
<tumbleweed> if this goes on for too long, we should make syncpackage spit out that bug number
<Laney> why do we care about blacklisted_current in ubuntu?
<tumbleweed> yeah, maybe we shouldn't. We certainly aren't using it yet
<tumbleweed> I could see it being handy for saying "nothing interesting here"...
<Laney> given that only archive admins can set it ...
 * tumbleweed notices that syncs aren't greyed out on oneiric's +localpackagediffs page. I hope that doesn't mean pressing sync will do anything
<Laney> it'll get rejected if it goes through
<Laney> ime
<slangasek> Laney: "given that only archive admins can set it" - er, but that's exactly how blacklisting of packages has always happened?
<Laney> slangasek: we were talking about the "these versions" bit
<slangasek> but then I don't know what "blacklisted_current" means either
<Laney> which is what blocked your sync
<slangasek> ok
<Laney> and whether it has any meaning for ubuntu
<slangasek> right, I can't figure out what that would mean
<slangasek> (conceptually within Ubuntu)
<tumbleweed> this version is bad, don't sync it
<Laney> yeah
<tumbleweed> IIRC it goes away as soon as either side changes
<cjwatson> which in itself suggests that it's useless for the stated use case
<cjwatson> somebody uploads something unrelated, you lose your note
<Laney> it seems like we should just ignore it for ubuntu as long as it has no use for us
 * slangasek concurs
 * tumbleweed makes that happen
<Laney> we could make syncpackage print out the comments if there are any
<Laney> i can't remember if they are tied to version pairs?
<tumbleweed> Laney: it currently prints the comments when there's a blacklist, but noth otherwise
<tumbleweed> no, comments are just a list. There's no knowing what comment applies to which decade :/
<Laney> display the date so that at least people can see how stale it is?
<Laney> and ask LP to please let us delete or hide old comments
<tumbleweed> looks like dssi & nautilus-image-converter don't need to be blacklisted any more. No more mismatch
<stgraber> skaet, cjwatson, Daviey: So looking at Drupal's xmlrpc support, authentication is something the module would have to implement itself which I'd rather avoid doing at the moment. Would we be fine restricting write access to the API by IP?
<stgraber> I guess the biggest use would be to push new builds and to push new results, I'm pretty sure IP based restriction is fine for the former, not sure for the later.
<skaet> stgraber, case that's worrying me is community testers logging test results.  Is this just for the admin interface or user too?
<stgraber> skaet: that's for the scripting API. Adding a build is definitely an admin task, pushing results could be used by a regular user though I don't think it'd be that useful.
<stgraber> I think the "add build" API is really for pushing new builds from antimony and the "add result" API is for jenkins/automated testing posting results automatically
<skaet> stgraber,  if that's the case, then I can't think of a reason why we can't live with that for now.
<skaet> jibel, ^^  can you see any issues?
<stgraber> I think it's a reasonable limitation for now and if we get pressure from the community to have access to the API, I can then spend the time to implement proper authentication in there
 * skaet nods
<stgraber> >>> import xmlrpclib
<stgraber> >>> rpc_srv = xmlrpclib.ServerProxy("http://192.168.122.172/xmlrpc.php")
<stgraber> >>> rpc_srv.qatracker.builds.add(3, '12345', False)
<stgraber> True
<stgraber> cjwatson: ^ that's what the new API looks like from python
<stgraber> with the parameters being: product_id, version, email_notify
<jdstrand> skaet: hey. so I just added a bunch of tags to things, and wouldn't you know it, they showed up on everyone elses list
<jdstrand> skaet: the kernel is fine, but it seems http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html is not aware that my team will handle apparmor
<skaet> jdstrand,  hmm,   tool probably needs to pull a refresh from the spreadsheet again.
<skaet> will look into it.
<jdstrand> skaet: thanks
<jdstrand> otherwise Daviey will come knocking on my door
<skaet> chuckle,  and we can't have that.  ;)
<jdstrand> nooo!
<skaet> lol
<tumbleweed> grumble, we have a missed (tiny) transition in oneiric, bug 882265. Uploaded botan1.8, should I wait for it to be NEWed before uploading the 3 rebuilds?
<ubot4> Launchpad bug 882265 in botan1.8 (Debian) (and 8 other projects) "libbotan-1.8.2.so not found (affects: 9) (dups: 4) (heat: 44)" [Unknown,Unknown] https://launchpad.net/bugs/882265
<micahg> tumbleweed: it was Debian's fault for not bumping soname I think
<tumbleweed> the debian maintainer screwed up royally, then spent 2 uploads fixing it :P
 * micahg is glad someone else took care of it :)
<tumbleweed> I only saw it because it was filed against mercurial by accident, and I get python team e-mail...
#ubuntu-release 2011-10-27
<jdstrand> skaet: fyi, something is not quite right with http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html. bug 344878 has assignments in the bug, but the report is not picking it up
<ubot4> Launchpad bug 344878 in linux (Ubuntu Precise) (and 8 other projects) "file name too long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) (affects: 75) (dups: 7) (heat: 448)" [High,In progress] https://launchpad.net/bugs/344878
<jamespage> morning all
<jamespage> how would I go about getting jruby moved from multiverse to universe?
<jamespage> the latest Debian version has moved into main (it no longer bundles its deps)
<Laney> file bug, subscribe ubuntu-archive
<jamespage> Laney: thanks
<Laney> :-)
<Laney> someone might Just Do It for you if they read the request on IRC, but bugs work.
<jamespage> well you neven know - I'll belt and braces it
<jamespage> if any archive admins do pick this up its a little complicated due to deps currently FTBFS  - see bug 576980 for more information
<ubot4> Launchpad bug 576980 in jruby (Debian) (and 1 other project) "jruby ships prebuilt jar files in the orig tarball (affects: 1) (heat: 8)" [Unknown,Fix released] https://launchpad.net/bugs/576980
<cjwatson> stgraber: hm, well, it's unfortunate since we often do things like posting AMI sets from off antimony
<cjwatson> stgraber: but I suppose it's tolerable in the shortish term
<stgraber> cjwatson: off antimony but still from a limited set of machines that we could whitelist or from random IPs (home internet for example)?
<stgraber> an alternative I thought about yesterday evening is to require an API key (send as a standard HTTP password), that should be just as easy to implement as the IP whitelisting (no need to have that hooked up with SSO + team membership, it'd just be linked to a QA tracker instance)
<stgraber> cjwatson: thinking about it for an extra 10 minutes, I'll store a list of valid qatracker userids + api key in a per-instance configuration key. So for any account where we want to give API access, we'll just need to generate a password (different from SSO) and add it to the list in the admin UI.
<stgraber> this should be easy for me to implement as the usernames are stored by Drupal, the password for the API will be store by the tracker and I don't need to go through the whole list of ACLs to figure out if the user is an admin or not as he'll be explicitly added by an admin
<stgraber> the only potential problem I see here is that for example an account used for Jenkins to post results will have just as much right as the account used to post new builds, so we'll need to be careful about who gets added to that list
<cjwatson> stgraber: in my case it's home internet, although admittedly my IP doesn't change often
<cjwatson> (if we had IPv6 then you could whitelist my tunnel range ;-) )
<cjwatson> API key> I suppose that's not too bad ...
<stgraber> I'll poke at the Drupal ACL api during my 5 hours ride through Maine, see if there's some easy way to check the ACLs from an xmlrpc module, if there's, then I'll just add the API key as a regular profile field for everyone and apply the same ACLs on xmlrpc as we have from the web interface
<lamont> heads up: recipe builds et al is causing a rolling blackout while I upgrade the buildds for them.  that is all.
<skaet> jdstrand,   weirdness with the report and bug 344878 was sorted out.   All should be ok now.
<ubot4> Launchpad bug 344878 in linux (Ubuntu Precise) (and 8 other projects) "file name too long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) (affects: 76) (dups: 7) (heat: 454)" [High,In progress] https://launchpad.net/bugs/344878
<jdstrand> cool
#ubuntu-release 2011-10-28
<Laney> cjwatson: I wouldn't bother doing GHC rebuilds just now; we're likely to get 7.0.4 in short order.
<cjwatson> Laney: how short?
<Laney> days
<cjwatson> well, ok; but I'd almost got to the point of being able to clear the haskell-hledger* build failures
<cjwatson> it's easier for me to see real failures when I can clear out the ones that are just due to uninstallables
<Laney> it doesn't hurt, of course
<cjwatson> [5~/wg 61
<cjwatson> gah
<jbicha> I'm curious why totem 3.0.1-0ubuntu7.2 was rejected, not important enough for a SRU?
 * ogra_ hand skaet a friendly  reminder about the EOL announcement for lucid :)
<skaet> ogra_ you want to review the draft I'm working on this afternon?
<skaet> :)
<ogra_> ah, no, just wanted to make sure it gets out
<ogra_> :)
<skaet> lol,  yeah I know how it is.  :)
<skaet> ogra_,  just to confirm, upgrade path for the ARM ones is to go to maverick?
<ogra_> yup
<skaet> :)
<skaet> thanks
<ogra_> at least for the next 6 months ;)
 * micahg is curious about this eol for lucid
<ogra_> micahg, armel wasnt lts
<micahg> ogra_: orly?  what's the supported life?
<ogra_> 18 months
<ogra_> it was a normal release
<micahg> good to know, I won't worry excessively about armel after that then (will try to get chromium working on armel before eol though :))
<ogra_> lol, dont waste your time on that
<ogra_> eol is today :)
<ogra_> micahg, rather make sure it works in precise and probably oneiric
<micahg> ah, right, we just hit 18 months :)
<micahg> ogra_: yeah, will try to decode gyp after UDS
<ogra_> the existing chromium oneiric package is fine btw i use it all day
<skaet> ogra_, the deed is done.   Announce is out.
<ogra_> \o/
<skaet> (or at least its sent, and waiting to clear the permission queues :P )
 * ogra_ hugs skaet and makes a mental note to pay her a sunday night drink 
<skaet> :)
 * skaet looks forward to seeing ogra_ on sunday.  :)
<micahg> ogra_: oneiric failed to build on armel (as did precise) for M15, I'll look into it as time permits
<ogra_> micahg, yeah, that would be good, i know the upstream build with webgl and friedns works, many people in #ac100 use it
<micahg> ogra_: I welcome help if you know someone who knows gyp
<ogra_> skaet, same goes for me, i'm already on the continent since yesterday and enjoy the silence of maine atm :)
<ogra_> micahg, i sadly dont, i just know that many ac100 users just use the google build on oneiric
<ogra_> so there apparently is a way to build it that works
#ubuntu-release 2012-10-22
<ScottK> doko_: ^^^ has bug fixes we should have in at the open.
<obounaim> Good morning everybody
<Daviey> cjwatson / ScottK: Please could you accept the maas SRU?
<cjwatson> ... I can't say I would have accepted those before general opening, personally
<cjwatson> They aren't important for building other packages
<infinity> cjwatson: I find the lack of syntax hilighting while preparing other uploads wildly annoying, but YMMV.
<infinity> cjwatson: Working on eglibc and base-files right now, which are, admittedly, a bit more crucial.
<cjwatson> I'm happy to edit that locally temporarily.
<cjwatson> Since usually I continue running stable for a while (although this release may be different).
<infinity> I'm looking forward to britney making this the first release I'm not scared poopless about running from day 1 on my laptop.
 * infinity crosses his fingers.
<cjwatson> Yeah.  I'm starting in on the LP changes now.
<infinity> Hrm.  If you apply the rewrite magic universally to all releases, I wonder if I should make the emacs-el bits match Debian (which only allows/hilights $release and $release-security, due to their auto-rewriting for -proposed-updates)
<cjwatson> I was going to make it a per-DS flag.
<infinity> Would make sense to just do it universally anyway, but will take some time to socialise it.
<cjwatson> Dunno, maybe it should be on Distribution.
<infinity> And I assume it won't attempt to rewrite -proposed, to people using the old method will still get the desired results.
<infinity> s/to people/so people/
<cjwatson> Indeed.
<infinity> My fingers need tea.
<cjwatson> I guess Distribution already has a substantial assortment of random columns.
<infinity> I can't see any reason why this would be a per-series flag.
<infinity> Just confused to have it DTRT for some series and not all.
<infinity> s/confused/confusing/ # see above, WRT tea for fingers... BRB.
<cjwatson> I was sort of thinking of the old state of Ubuntu, where we might have liked to have it auto-rewrite for everything but the dev series.
<cjwatson> But whatever.
<cjwatson> wgrant: ^- any opinions?
<infinity> Oh, there's that possibility, yes.  Could still be a Distribution thing, but have a toggle for "don't do this for non-stable series".
<infinity> Then it won't need to be twiddled as we release/open old/new series.
<infinity> But rather, just be a question of setting a policy that DTRT.
<cjwatson> It's certainly a reasonable point that we don't want to add more steps to NewReleaseCycleProcess.
<wgrant> Mmm
<wgrant> My opinion is that the whole thing is terrible :P
<wgrant> But
<infinity> cjwatson: I think it makes more sense as a policy thing than a per-series thing.  If we want stable/supported rewritten, but not devel, we don't want that to always be true, not just when we remember to set it. :)
<infinity> cjwatson: (Not that I think we want that, but I see that we may in the future decide to go back that direction, or that some other mystical LP-using distro may want it that way)
<infinity> It's certainly what Debian would want if they used Soyuz.
<wgrant> If any other distro wanted to use LP we'd have to rework the whole suite system anyway
<infinity> Yeah, I guess so.  Certainly in the Debian case, where there are technically two suites in development at all times.
 * infinity wonders idly why we unsplit the glibc docs, rather than just pulling in the non-free package and having a dependency, and goes about reducing that massive delta.
<wgrant> Do we really want to rewrite post-release release to proposed?
<wgrant> I guess it's OK since it'll end up in Unapproved anyway
<infinity> wgrant: I'm failing to see why we wouldn't?
<wgrant> Well
<infinity> wgrant: It how I do all my uploads anyway (precise in the changelog, precise-proposed in the .changes)
<wgrant> LP has always done what you told it to in this respect
<infinity> s/It/It's/
<cjwatson> Where one of the options is "fail and make you reupload" and the other is "do what you meant"
<wgrant> Right, and it's not so bad since it always requires approval, I suppose
<cjwatson> Indeed.  There've been basically no complaints about Debian auto-rewriting stable to proposed-updates, which has been the case for years
<cjwatson> Hm, I'd been going with .forbid_release, but now that I come to write help strings and such I think it should be .redirect_release_uploads
<wgrant> Yeah, forbid_release is a bit wrong
<wgrant> Also, depending on where you do the rewrite you might need to think about how it impacts binary uploads
<wgrant> And what about copies?
<cjwatson> Definitely must not redirect copies, because that's how we're going to do promotion from -proposed.
<cjwatson> Might at some point consider allowing copies only to queue admin.
<wgrant> Right, but this sort of inconsistency has the potential to bite people
<cjwatson> Well, syncpackage, true.
<wgrant> "oh I want to upload to raring... but let me go via a ppa... oh whoops copies don't redirect"
<wgrant> dak doesn't really have this problem since the only way mortals interact with it is via dput
<cjwatson> I think a possibility I suggested in passing last week was to have copies redirect unless you're a queue admin and use auto_approved=True (thereby signalling that you're acting as a queue admin)
<wgrant> That seems even more magic
<cjwatson> So I agree a lot of this is a fair bit of magic; I'm open to suggestions that don't involve having to re-educate every Ubuntu uploader
<infinity> Well, I think most of this, if done as written above, only requires educating archive admins.  Since the average uploader will just have the Right Thing happen, no?
<wgrant> infinity: Not for copies
<cjwatson> Where "as written above" includes my more-magic suggestion, I think
<infinity> wgrant: I was including Colin's... Yeah.
<wgrant> The auto_approved=True thing is far too magic
<cjwatson> Alternative proposal which probably isn't too hard: redirect=False (or similar)
<wgrant> It *might* be acceptable for it to reject if auto_approved=False, but not redirect
<wgrant> Right
<cjwatson> Not redirecting for normal uploaders means we have all the hassle of changing syncpackage in stable series
<wgrant> But all the sanity of having one less opaque boobytrap in Launchpad.
<wgrant> Which is then encoded in tools for years/forever
<wgrant> And impossible to change without disastrous consequences
<cjwatson> So you'd actually prefer copies to behave differently from uploads?
<cjwatson> That's kind of a boobytrap too, just a different one
<wgrant> It's not a boobytrap if the copy API tells you to go away when you try :)
<cjwatson> I suppose copies are more explicit about a bunch of things
<cjwatson> True
<wgrant> Right, that too
<infinity> Copies rejecting and suggesting you might have wanted -proposed would be an alright compromise, but as stated, we'd need to SRU all the old releases to sync to proposed.
 * infinity glares at pidgin-libnotify landing after Q released.
<cjwatson> I guess people can use -r raring-proposed in the meantime.
<cjwatson> Assuming that works.
<cjwatson> Yeah, it does.
<infinity> Oh, wait, that notification bubbles, not indicator integration.
<wgrant> The fact that you have to SRU any API change is an excellent argument for making the API not be full of boobytraps.
<Laney> yeah
<wgrant> Because if they prove to be a problem then we can't change them later
<Laney> someone is working on a patch for the indicator stuff
<infinity> Laney: Good.  I'm wildly miffed that when I upgraded my main machine to Q, I lost the only two consumers of the messaging menu that I care about (pidgin and gm-notify)
<cjwatson> wgrant: Mm.  True.
<wgrant> The reasons given for wanting the upload redirect are a) retraining developers, and b) ugly changelogs
<wgrant> I hardly think a) is particularly valid at all :)
<wgrant> And b) doesn't apply to copies
<infinity> Well, we could fix (b) with end-user tools doing the rewrite, though I don't really want that hack in dpkg-genchanges. :P
<infinity> Mostly, I just felt the redirect was the right DWIM thing, but that's years of Debian redirects that have trained me to expect that.
<wgrant> Sure, it is the right DWIM thing.
<infinity> And, if the counter-proposal is just to hard reject all uploads to $series, don't we still need to consider how that affects copies, and when?
<wgrant> But there's a tradeoff there
<infinity> The rewriting seems orthogonal to the "no uploads to $series except for copies from $series-proposed in a devel release" thing.
<wgrant> infinity: Indeed, that would probably need to be made explicit (or it could be folded into auto_approve; I don't have a problem with auto_approve approving extra stuff, it just must not affect a redirect)
<infinity> wgrant: Well, a redirect=False on copies would work then, right?  Allowing us to attempt a copy to $series, and check if we have the right perms to do so, etc?
<cjwatson> I'm inclined to suggest that build uploads should never be redirected.
<wgrant> Build uploads must never be directed, indeed
<wgrant> That would destroy ~everything
<wgrant> It's possible that you can just hack the insecure policy to do it
<wgrant> I'm not sure if that's reasonable
<cjwatson> Probably better than doing it in the upload processor + nascentupload (which mysteriously both construct policies independently).
<wgrant> Hee hee
<wgrant> Yeah
<wgrant> That code has some terrible demons lurking
<wgrant> With not insignificant chunks ripped straight from dak...
<infinity> Build uploads wouldn't need to bypass the redirect.
<infinity> They always upload to the right series.
<cjwatson> (And why does soyuz_process_upload live under lp/soyuz anyway?)
<infinity> Oh, except if it's a retry after it's been promoted, then it would build in $series, but a redirection would try to rewrite that.
<infinity> Otherwise, though, buildds don't get the upload series from the changelog, but from sbuild (which gets it from buildd-master), so it should be correct.
<wgrant> infinity: Hmm?
<infinity> wgrant: Was just talking myself through why buildds need an exception here. :P
<wgrant> uploadprocessor doesn't get it from the changelog either
<wgrant> It's normally from the Distribution field in the .changes
<infinity> wgrant: uploadprocessor gets it from the changes, I assme?  Or is that different for binary uploads for some reason?
<infinity> wgrant: Yes, exactly.
<wgrant> But depending on the layer that cjwatson rewrites at...
<wgrant> We hopefully ignore the .changes Distribution for buildd uploads
<wgrant> Given that we know the build it's coming into
<infinity> And by "ignore", you mean "don't rewrite".
<wgrant> There's a sanity check that various .changes metadata matches the build, but I forget if that's part of it
<infinity> Cause binary .changes is always what we want it to be.
<wgrant> It should always match, indeed
<wgrant> But Launchpad already knows where the build is meant to go
<wgrant> It doesn't need to read the .changes
<wgrant> This isn't Debian :)
<infinity> True, given that the .changes contains exactly what LP told us.
<infinity> Though, that's true in Debian as well. :P
<cjwatson> The insecure policy seems like an OK place to do this, which makes the question moot.
<wgrant> So we *probably* ignore the .changes Distribution, but depending on where cjwatson overrides it could impact the build-derived target suite too
<wgrant> But if you do it in insecure, it's fine as you say
<infinity> Actually, wait.
<wgrant> infinity: Is that really true in Debian now?
<infinity> We absolutely ignore .changes
<wgrant> infinity: I thought Debian buildds still just uploaded signed binaries into whatever suite and dak believed them
<wgrant> infinity: Why do we absolutely ignore .changes?
<infinity> wgrant: Well, yes, but the buildds are getting the suite from wanna-build.  So, not much different from buildd-master telling us what to build for.
<wgrant> Sure, but the thing in question here is how the upload processor chooses the target suite
<wgrant> In dak it will respect what the buildd tells it
<wgrant> In LP it probably won't
<cjwatson> Do we want a log message telling the uploader about the redirect (as Debian does)?
<infinity> wgrant: Oh, nevermind.  I was thinking something relating to Daniel's stellar design decision to pass -dautobuild to sbuild, but I fixed that years ago.  Some part of my brain is living in the past.
<wgrant> infinity: Heh
<wgrant> cjwatson: Please
<wgrant> cjwatson: Even better if that ends up in a convenient place in the Accepted mail somewhere
<cjwatson> That's what I was thinking
<wgrant> Although I forget if the new format has a logical place for that
<cjwatson> Not that upload policies currently have a logger, but ...
<infinity> It should end up in the Accept/Hold mail anyway.
<infinity> Since an upload to $foo should end up saying "Accepted in $foo-proposed"
<wgrant> cjwatson: there's probably a well-known logger name, like there is in buildd-manager
<cjwatson> It can go somewhere near "Announcing to ..."
<wgrant> Subjects say something like [ubuntu/raring-proposed] already, don't they?
<wgrant> But I'd prefer an explicit log line
<wgrant> As the subject is easy to miss
<infinity> Yeah, both are fine.
<cjwatson> wgrant: Did I just catch you assuming logic from LP?
<cjwatson> (AFAICT archiveuploader just passes through an explicit logger everywhere.)
<wgrant> Heh
<wgrant> Well
<wgrant> It's an open question which of those is more logical
<cjwatson> Oh, bah, the notification mails are just constructed from a great big static template
<wgrant> PPA acceptance emails have something fairly free-form at the top
<wgrant> I can't remember how dissimilar the PPA template is
<cjwatson> I could shove %(SUMMARY)s into the distro one, I suppose
<cjwatson> But I think it fits better down below in the new format
<wgrant> Yeah
<cjwatson> Since IIRC the intention was for the top bit to still be vaguely parseable, in principle
<wgrant> Indeed, although that matters more for announcement than acceptance
<cjwatson> Announcements don't really need to be terribly explicit about redirects.
<wgrant> Exactly
<wgrant> It's not important for the announcement at all
<wgrant> And it's the announcement that was intended to be parseable
<wgrant> I suppose I should actually look at an acceptance mail to see just how parseable they are today
<wgrant> Ah
<cjwatson> Would it be OK for this to go in an "Upload Warnings:" section?  archiveuploader constructs once of those, although it doesn't currently go in distro acceptance messages.
<wgrant> They are more similar than I remembered.
<wgrant> Yeah, that sounds reasonable
<wgrant> Upload warnings don't spam us
<wgrant> I forget the full set of current warnings, though
<wgrant> All I can remember is the one about the lack of debian/copyright
<wgrant> I think that may, in fact, be the only one
<wgrant> Ah, PPA quota too
<wgrant> So yeah, seems like a reasonable place
<cjwatson> Also urgency overrides
<wgrant> Hmm
<wgrant> But we get cronspam about those
<wgrant> Oh
<wgrant> priority overrides cronspam, urgency overrides end up in Upload Warnings
<wgrant> Right
<wgrant> Makes sense :/
<henrix> infinity: it looks like we have a small prob with the lts-quantal
<henrix> infinity: we're not able to create the tracking bug because the package has never been uploaded
<henrix> any chances of getting it back? :)
<henrix> herton: bjf: ^^
<rtg> which was _why_ I uploaded last Friday.
<bjf> i agree and why i said an 18 would be coming soon
<rtg> all stable activity is predicated on the existence of the source code package
<bjf> henrix, if necessary, just upload an 18 without a tracking bug
<henrix> rtg: right, and makes sense. i didn't realised that we wouldn't get a tracking bug.
<bjf> henrix, the other thing you can do is just create a bug by hand which will become the tracking bug for the package you upload
<bjf> henrix, once it hits -proposed you can then just fix it up by hand
<rtg> create it using 'linux' as the source package name, then just change it later.
<henrix> bjf: hmm, ok. i guess that could be done. thanks
<bjf> ack
<infinity> henrix: Ahh, yeah, can't file bugs against something that doesn't exist.  Not world-ending.
<infinity> (Not worth QAing a -17- upload just to be able to file bugs against it, mind you, which was why I rejected it if -18- was happening today)
<infinity> I could accept -17- to proposed just to make your life easier, I suppose.
<bjf> infinity, it isn't going to be QA'd if we mark the tasks invalid, we just need something in the archive
<infinity> bjf: Well, "need" being a bit strong.  The copy will still work if the target doesn't exist.
<infinity> bjf: But if you'd prefer it this way to make the bot less grumpy, it's not like burning buildd time right now will hurt.
<infinity> bjf: I can accept Tim's uploads right now.
<bjf> infinity, just accept rtg's upload please
<henrix> bjf: infinity: ok, so i'll wait for -17 to get accepted
<infinity> Sure, just give me a moment to do the NEW review.
<henrix> infinity: sorry for the mess.  i should have thought about that before ;)
<infinity> henrix: Well, just having it in the PPA without the tracking bug (until after I copy) would have worked just fine too.
<infinity> But I need to review this at one point or another anyway.
<infinity> So.  May as well do it now.
<infinity> henrix: BTW, for my peace of mind, do you intend to generate lts-quantal using an exact copy of the .orig.tar.gz from quantal?
<infinity> henrix: (Cause Tim's was built natively, which makes it a fair chunk different from Q)
<henrix> infinity: we use a script debian.quantal/etc/update-from-quantal-master, which rebases the lts branch against the release repo
<infinity> henrix: Branch rebasing isn't building the debian source package.  I mean when you build the source package, have a linux-lts-quantal_3.5.0.orig.tar.gz in .. that is an exact copy of linux_3.5.0.orig.tar.gz from quantal.
<infinity> henrix: Saves space for mirrors that use hardlinks, and also makes the two source packages much easier to audit as being related to each other.
<henrix> infinity: ah, ok. we do that for the linux packages, but not for the lts
<infinity> henrix: Might be nice if you started. ;)
<infinity> henrix: Given that, other than some bits in Debian, they're pretty much identical and all.
<henrix> infinity: ack
<infinity> henrix: Just make sure the orig is an exact copy, or it'll kinda defeat the purpose.  Cause if it's identical, you just saved ~100MB (per source package) for every mirror that isn't silly.  And a lot more, once you factor in version bumps.
<rtg> infinity, is the orig tarball name a function of the source package name ? in which case we're gonna end up with a 2nd tarball anyways, but we can still save a shitload of space for subsequent uploads.
<rtg> s/is/isn't/
<cjwatson> rtg: Yes.
<cjwatson> (Although a few mirrors know how to hardlink identical files.)
<infinity> rtg: Yes, I specifically mentioned the hardlinking above for that reasons.
<infinity> s/reasons/reason/
<infinity> rtg: Either way, as you note, it saves space in subsequent uploads, even for less bright mirrors.
<rtg> ah, missed that
<infinity> henrix: Oh, and if I missed mentioning it, I accepted Tim's uploads, so shankbot should be happy about creating bugs.
<henrix> infinity: ack, thanks
<cjwatson> abcde is a test case I'm running for -proposed migration
<xnox> the name of the package is too generic, testme-please-ignore1 would be better.... oh wait it's a real package called "abcde" and it has nothing to do with teaching alphabet.... *sigh* abcde: A Better CD Encoder
 * highvoltage always liked the name of that program
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/ - most boring possible output :-)
<highvoltage> you can do a lot worse, like there's an educational flashcard program called "iGNUit!" (urgh)
<cjwatson> all I needed was something that wasn't compiled and so wasn't involved in any toolchain work; abcde happened to be first in the list from auto-sync output
<xnox> I am suspecting ben the transition tracker is still pointing to quantal instead of raring http://people.canonical.com/~ubuntu-archive/transitions/
<xnox> http://people.canonical.com/~ubuntu-archive/transitions/python3.3.html has lxml at 2.3.5-1 yet it is 3.0.1-1 in raring
<cjwatson> xnox: fixed for next run
<cjwatson> though you could have done that yourself I think - it's ubuntu/download/archive{,_ports}.ben
<Laney> yeah
<Laney> I don't think it's encoded in the script that runs it
<cjwatson> it's not
<cjwatson> http://paste.ubuntu.com/1297805/
<Laney> we need to be making this learn about proposed
<cjwatson> Laney: do you have access to the chroot this runs in nowadays?
<Laney> no
<cjwatson> we should get you into ~ubuntu-archive so that you do
<cjwatson> then you can sort out the new tracker code so I don't have to :-)
<Laney> I wouldn't complain
<cjwatson> since I'm obviously failing to
<Laney> there's already an RT to get ben installed on that box
<Laney> I suspect it won't happen until someone pushes at it though
<cjwatson> https://launchpad.net/ubuntu/+source/abcde/+publishinghistory - looks moderately sane
<cjwatson> ubuntu-archive-robot will end up being blamed for a lot of stuff :)
<Laney> heh
<xnox> cjwatson: thanks... doh =) should have done myself.
<Laney> will there be a hinting mechanism for our britney?
<cjwatson> It shouldn't affect anything processing *-changes lists
 * xnox wants new tracker =))))
<cjwatson> But if there are things that try to assign blame by processing the publishing history, they'll probably need to be adjusted
<cjwatson> Laney: the code's there, and I expect we'll need it occasionally, but I was going to cross that bridge when we came to it
<xnox> Laney: well manual copies are still possible to bypass britney =)
<Laney> mmm
 * Laney is aware of what we do to Debian's RT with Haskell.
<cjwatson> xnox: that's not a given
<xnox> cjwatson: ?! /me doesn't get it.
<cjwatson> xnox: manual copies to bypass britney will probably not remain possible
 * xnox :`(
<xnox> oh well. Better be good with my uploads then.
<cjwatson> otherwise everyone using syncpackage would bypass it
<cjwatson> (until we modify it, but even then ...)
<xnox> hmm... mk-sbuild should add -proposed to sources by default. And quantal ppa's as well?!
<cjwatson> No!
<cjwatson> Absolutely not!
<cjwatson> *Don't* encourage actual users to use -proposed
<cjwatson> A lot of people use sbuild chroots for non-buildy things ...
<xnox> but buildd will build against -proposed, while locally it will build against release.
<cjwatson> (Sorry, maybe my exclamations were a bit OTT)
<xnox> well, you have a point =)
<cjwatson> Why talk about quantal PPAs then?
<cjwatson> buildds won't build against those ...
<xnox> s/quantal/raring/
<cjwatson> buildds won't build against raring PPAs either
<xnox> yeah, agree. Forget I ever mentioned PPAs.
<xnox> but pbuilder-dist & mk-sbuild - should or shouldn't add -proposed?
<cjwatson> OK, maybe that confused me
<cjwatson> Arguably
<xnox> for raring, while it's development release.
<xnox> well always.... as it becomes SRU staging archive.
<cjwatson> I guess at least with an option
<cjwatson> (like --skip-updates)
<xnox> opt-in then.
<cjwatson> I could see it either way; it kind of depends on the target audience
<cjwatson> Builds in raring PPAs probably won't use -proposed by default
<cjwatson> Builds aimed at the primary archive might well want to be tested against -proposed
<Laney> Then you get into the situation where people end up enabling -proposed on their machines to satisfy dependencies
<xnox> ack. And if a developer is caught in a transition, they should know & learn about it.
<cjwatson> We're still going to have to put effort into keeping transitions as brutally short as possible
<cjwatson> So, yeah, disregard my "No!" above - I was out of line
<cjwatson> I'm being a bit hair-trigger on the risk that people might start widely using -proposed
<cjwatson> Because if they do it kind of makes a lot of this work pointless
<xnox> server & X where building against -proposed this cycle. Did we have any "support" issues with enabling -proposed for those devs...? (I am guessing kernel & X developers are fairly sophisticated and do not require the #ubuntu-motu style hand-holding)
<cjwatson> Not really, but there was so little in -proposed at any one time that it hardly mattered; they mostly had the pocket to themselves
<cjwatson> The support issue was keeping track of when things were ready to be promoted
<cjwatson> And being aware that we were going to start doing auto-promotion was why we were repeatedly discouraging people from doing manual testing there
<xnox> which mostly funnelled down to all of them pinging infinity =)
<xnox> is Raring Ringtail a proper name, and hence capitalised. Or is it a common noun and hence should be lower-cased.
<xnox> ?
<cjwatson> When written in full like that, it should be in title-case as you have it
<cjwatson> For just the adjective, opinions evidently vary.  I tend to capitalise it when I'm using it as an abbreviation for Raring Ringtail / Ubuntu 13.04 / whatever, and lower-case when I'm referring to the technical identifier (the Launchpad series, upload targets, whatever)
<cjwatson> But that's probably just me.
<slangasek> I think I agree
<slangasek> even though my usage tends not to be so consistent :)
<cjwatson> I'm sure mine isn't unless I'm thinking about it.
<xnox> I am debating weather /etc/lsb-release DISTRIB_CODENAME is human readable or machine parsable. Since I am afraid things may break if the codename is suddently capitalised.
<infinity> Does someone want to give a quick review to that base-files in the queue?  It's a reasonably beefy merge, so wouldn't mind a second set of eyes rather than self-accepting.
<infinity> xnox: It's meant for computers, not people, IMO.  If you're referring to the bug I just closed.
<xnox> by the loooks of things openSUSE capitalize their codenames in lsb-release, debian doesn't. Checking fedora now.
<xnox> infinity: yeah. it is about the bug you closed.
<xnox> I like os-release it has a pretty and machine names.
<xnox> let's see what you crafted for raring =)
<infinity> xnox: raring is the same as every release previous.
<slangasek> there certainly may be software that assumes the codename field is directly usable for apt and the like
<cjwatson> Oh, goodness, yes, don't change the capitalisation in DISTRIB_CODENAME.
<cjwatson> No excuse or reason for doing that.
<infinity> Hrm, wait.  This can't be about CODENAME anyway.
<cjwatson> That sort of thing doesn't need to obey the normal rules of English grammar.
<infinity> xnox: Which string is this?
<slangasek> ah, oh right, it's about DISTRIB_DESCRIPTION
<slangasek> which lowercases the codename prior to release
<infinity> With an added s/\(.*// ?
<slangasek> and /that/ it would be reasonable to uppercase
<infinity> Cause I wouldn't be against.. Yeah.
<xnox> well the os-prober fetches it, and then ubiquity parses it further and we end up in Ubiquity with a string:"You have Ubuntu quantal installed on this computer. What would you like to do?"
<cjwatson> Agreed, that doesn't matter.
<xnox> during development.
<infinity> xnox: Right, I'm just trying to nail down precisely (raringly?) where that comes from.
<infinity> xnox: If it's lsb_release -d | sed 's/\(.*//' (or so), then yeah, we could uppercase that one.
<cjwatson> /usr/lib/os-probes/mounted/40lsb
<cjwatson> Basically DISTRIB_DESCRIPTION
<infinity> cjwatson: Minus the " (development branch)" bit, I assume.
<cjwatson> I guess.  I haven't followed the twisty maze.
<xnox> well ubiquity strips (development branch)
<xnox> but it is there.
<xnox> http://paste.ubuntu.com/1297966/
<infinity> Ahh.
<infinity> Check.
<xnox> this is paste of raw os-prober results against some of my chroots.
<infinity> If ubiquity's already post-processing it, you could tr the first character of the name too. :P
 * xnox wants to remove all of the logic out of ubiquity
<xnox> so I rather Base-Files to be Capitalised =)
<infinity> But I think I can see a valid argument for the bits in DISTRIB_DESCRIPTION, PRETTY_NAME, and /etc/issue* to have an uppercase R.
<slangasek> xnox: ITYM BasE-FIleS
<infinity> I shall reject my upload and do that now, if there are no objections.
<xnox> "Weâll make somethingâ¦ wonderful, and call it the Raring Ringtail." and "However, for the sake of sanity, itâs not a raring ringtail raccoon, just a raring ringtail." As per http://www.markshuttleworth.com/archives/1195
<xnox> slangasek: I am not from east london.
<infinity> RFC: http://paste.ubuntu.com/1297969/
<cjwatson> I have a "that looks wrong" reaction which I think is just unfamiliarity.
<cjwatson> I think it would be fine.
<infinity> Yeah, I think it looks wrong to Capitalize It Without The Ringtail.
<xnox> I wonder how many things will break, and why is it "Ubuntu Raring" and not "Ubuntu Raring Ringtail" everywhere.
<infinity> Maybe we should add the animal too.
<infinity> And totally break with tradition.
<xnox> =))))))
<cjwatson> I'd be a bit worried about increasing the length causing some strings to wrap and ...
<infinity> xnox: Nothing should break, since those fields all change regularly anyway.
<xnox> we are really raring this time around =)
<cjwatson> But I suppose it's reasonable to try it now
<infinity> cjwatson: Yeah, I was thinking about wrapping issues too.  Especially in installers.
<cjwatson> As long as we don't attempt to SRU it
<infinity> What the heck, let's get all animally.
<cjwatson> I'm pretty sure that at one point "Ubuntu quantal" etc. was displayed in some contexts that didn't have a lot of horizontal space.
<cjwatson> Like the horizontal partition display we had at one point.
<infinity> Actually, yeah.  I'll change it in issue/issue.net, I won't change it in lsb/os-release.
<infinity> Well.  Wait.  People using those already cut out the (devel release) garbage.
<xnox> but then ubiquity will say: "You have Ubuntu Raring installed. What do you want to do?"
<infinity> They can cut the animal too if it's really an issue.
<cjwatson> I do, FWIW, think it's perfectly fine to talk about raring or Raring; it's not like it's *wrong* without Ringtail.  We've been abbreviating it ever since warty.
<infinity> Bah.
<infinity> Screw it.  I'm done having opinions.
<infinity> Everyone gets ringtails.  It's a new world oder.
<infinity> Also, an order.
<xnox> =)))))
<infinity> And I just typed "Raring Ringtails"...
<infinity> Stupid brain.
<infinity> http://paste.ubuntu.com/1297985/
<infinity> And uploading.
<cjwatson> (As in, I have a mail from 2004-04-09 talking about all of "warty", "Warty", and "Warty Warthog" essentially interchangeably.)
<infinity> Yeah.  Well, this feels more correct for /etc/issue* anyway.
<infinity> We'll see if the world explodes due to lsb-release.
<infinity> And it bloody better not be an issue for os-release, which has no consumers yet. :P
 * xnox ponders what would happen if we include some UTF-8 characters as well =)
<infinity> But, I figure all lsb_release -d consumers who cared about screen space were already chopping off the last bit, so they can just chop harder.
<infinity> (Or, more correctly, just keep the first two fields, which may be what some already do)
<xnox> infinity: about chopping     https://www.youtube.com/watch?feature=player_detailpage&v=h8FomrtvCIY#t=17s
<infinity> Alright.  If someone wants to give THAT base-files upload a quick once-over and accept it, that would be lovely.
 * infinity wanders off to find a bit of liquid food.
<ScottK> doko: ^^^
<slangasek> bdmurray, jibel, gema: does anyone know where http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html has disappeared to?
<micahg> slangasek: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html (same thing happened to the sponsorship page)
<slangasek> "reqorts"?
<slangasek> what in the world
<micahg> slangasek: machine move :)
<slangasek> micahg: is that going to be fixed to a more sensible name in the future?
<micahg> slangasek: no idea, I just found out myself due to backscroll in one the channels
<slangasek> ok, thanks
 * skaet *blinks*
<skaet> yeah,  an email about the location changes would have been nice.
<bdmurray> slangasek: no, I don't what we should be using to get to them now
<slangasek> bdmurray: see micahg's comment above, apparently there's "reqorts" now
<bdmurray> slangasek: oh, I missed the q
<bdmurray> wtf
<skaet> I'm asking if there could be an email explaining the change/transition in locations.
<Laney> slangasek: huh, I talked with IS about that earlier
<Laney> ChrisS was supposed to have set up a redirect
<Laney> uh, it's gone away, the sponsoring report worked earlier
<Laney> speak to the vanguard ...
<slangasek> Laney: a redirect from where?
<Laney> from reports to reqorts
<slangasek> for which subtrees?
<Laney> /reports/
<slangasek> ok
<Laney> anyway, it seems to have gone away
<ScottK> Any objections to an Ubuntu specific debootstrap upload to make it aware of raring?
* ChanServ changed the topic of #ubuntu-release to: Ubuntu 12.10 (Quantal Quetzal)  released! | Archive: Frozen | http://pad.ubuntu.com/ubuntu-release | Raring Ringtail Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<cjwatson> ScottK: not really, although I was going to do it in Debian soonish.  If you could upload one to raring-proposed it'd be another handy test of britney.
<ScottK> OK.
<cjwatson> (as long as people can restrain themselves from copying it to raring manually)
<cjwatson> I don't have britney fully automated yet - will run it by hand tomorrow morning
<ScottK> cjwatson: Uploaded.
<cjwatson> ta
<cjwatson> mostly I want to check that announcement mails come out sane
<ScottK> I already added the symlink by hand locally, so I'm not rushed.
<cjwatson> you might get an extra mail when it's copied - haven't worked out how/whether to suppress that yet
<cjwatson> I figure people can always filter so it's not a *huge* deal
<xnox> I like receiving emails upon accepts in the queue & upon copies (SRUs from lp, or sftp Debian uploads) Plus it will give a clear idea of how long the delay is or whether there are problems (Oh, there was no second email, why is it not transitioning).
<cjwatson> xnox: Yes, I expect some people will feel that way and others will complain about the duplication :-)
<cjwatson> Something like grep-excuses in a cron job is a better way of keeping track of transition delays in Debian
<xnox> whoever complaints should start getting katie's email =)
<cjwatson> But it may not work well for Ubuntu unless we make it show maintainers a bit differently
<xnox> well *I* care about _my_ package transitioning, not the rest of the world ;-)
<cjwatson> I expect I will have to start filtering ubuntu-archive-robot's mail shortly
<xnox> heh.... =)
<cjwatson> (katie itself doesn't tend to get mail)
<cjwatson> (not that I'd see it if it did)
<xnox> lucky her =)
<cjwatson> ScottK: That was apparently to raring (release).  Would you mind reuploading to raring-proposed.
<cjwatson> ?
<ScottK> cjwatson: Not at all (it was)
<ScottK> Done
<cjwatson> Ta
<phillw> hi guys, any idea why I'm getting bug 986967 in quantal on alternate install?
<ubot2> Launchpad bug 986967 in unity-greeter (Ubuntu Precise) "unable to log in - hangs on 'logging in' msg" [High,Fix released] https://launchpad.net/bugs/986967
<xnox> phillw: there is no alternate install for quantal.... so what are you doing? did you mean precise?
<phillw> well that sort of issue?
<phillw> xnox, there is alternate for both server installs and lubuntu.
<xnox> ack.
<phillw> along with netboot, of course.
<phillw> I do have a full set of logs, as it is on my other hard drive. So, if you guys let me know what ones you want, I'd be more than happy to furnish them.
<xnox> phillw: comment on the bug or open a new one. I don't it's something #-release can solve easily.
<xnox> I don't "think" (missing from above)
<phillw> As it is Q bug, I guess I should open a new one. It's obviously NOT unity greeter!
<phillw> the repeated error is unable to open pam_gnome_keyring.so  Does that help in what I should bug it against?
<phillw> in fact the line all have pam / PAM in, but I'm not knowledgeable enough to understand them :/
<xnox> duplicate pam module configured by any chance?!
<phillw> xnox: give me a couple of mins and I'll paste up the auth.log - hopefully you can tell me what to bug report it against.
#ubuntu-release 2012-10-23
<cjwatson> Could you take this to #ubuntu-bugs or similar, please?
<phillw> pastebin.com/iNEUgVES
<phillw> cjwatson: certainly, I just asked here in case one of you could give me what to bug report it against. My apologies. :(
<phillw> cjwatson: xnox - my apologies.. old /home + new install = reset ~/.Xauthority, in my feeble defence, been 18 months since I was last bitten by that little critter.
<ScottK> doko_: ^^^ That'll work with 3.2/3.3, so it should get in.
<psivaa> The md5sum for the latest quantal-desktop-amd64 (20121017.5 i think) does not match that is listed in cdimage.u.c. Would someone be able to have a look please?
<cjwatson> psivaa: It matches on cdimage.
<Laney> can someone reject the old seahorse from quantal-proposed/unapproved please?
<Laney> just in case
<cjwatson> Laney: done
<Laney> merci buckets
<psivaa> cjwatson: it does indeed, not sure why our tests report they dont match. i'll have a look thanks
 * cjwatson finishes his first pass at a "redirect-release-uploads" LP branch
<cjwatson> (though also waiting for the DB branch to be reviewed and deployed)
<infinity> Hrm.  Methinks we missed the "create raring in the partner archive" step.
<infinity> Or, so apt tells me.
<cjwatson> infinity: So, well
<infinity> "Verify that the partner repository has been created on archive.canonical.com as a result of this process; if not, notify the Soyuz developers to fix it and check that this happens."
<cjwatson> infinity: That got screwed by setting raring to frozen early
<infinity> Ahh, that was one of the fallout issues from my oops?
<cjwatson> infinity: I tried running publish-distro -A manually, and it republished a load of old series
<cjwatson> infinity: so I screamed and reverted to a backup
<cjwatson> infinity: I think the easiest way to fix this is likely to publish something irrelevant to raring/partner and then delete it
<infinity> Or something relevant.
<cjwatson> infinity: Just to force the publisher to do something (you might need to hold off on the deletion until after a publisher run)
<infinity> I could just push vmware-view-client with a raring version.
<cjwatson> infinity: If you have something, sure :)
<infinity> Yeah, I'll just do that.
<infinity> Hrm.  The painful decision between "working from the hotel to avoid distraction" and "going into the office to have bandwidth" really becomes apparent when I download massive sources.
 * infinity turns the hand crank.
<infinity> Ahh, but welcome to the bizzaro world of hotel networks, where my upstream is 10 times better than my downstream.
 * infinity blinks at the /etc/os-release conffile prompt.
<infinity> We *just* added that file in Q, how could we have messed it up already? :P
<infinity> Oh, feh.  It wasn't a conffile in doko's upload.
<infinity> So this needs migration magic.
<Laney> 6
<Laney> Yes. Six.
<doko> infinity, https://launchpadlibrarian.net/120762889/buildlog_ubuntu-raring-armhf.python-pylibacl_0.5.1-1.1build1_CHROOTWAIT.txt.gz ?
<infinity> doko: What machine was that on?
<infinity> Erm.  Where did these new buildds come from?
<doko> infinity, bukavac, alfirk, diphda
<infinity> Yeah, those all use to be "virtual".
<infinity> And they're misconfigured.
<infinity> Hunting down.
<infinity> cjwatson: partner fixed.
<cjwatson> So it is.  Great, thanks.
<cjwatson> Though raring seems to have fewer pockets than quantal does on archive.c.c.  Probably correctly, though ...
<cjwatson> Series initialisation is confusing.
<cjwatson> infinity: Any objections if I nuke r-series* from there?
<infinity> cjwatson: Nope, I was just noticing that hilarity myself.
<infinity> cjwatson: And the pocket thing is weird, since partner shouldn't have pockets AT ALL.
<cjwatson> Done.
<cjwatson> Yeah, I know.
<infinity> cjwatson: Which means either someone fixed it, or it's accidentally doing it correctly now, and that's worrisome. :P
<cjwatson> The accident is probably because only raring/partner was dirty.
<infinity> cjwatson: But the others never should be.
<cjwatson> If not for your oops, I'm pretty sure we'd have the unnecessarily full set.
<infinity> cjwatson: So, maybe they're just cruft from IFP, and haven't been touched since...
<cjwatson> Yeah, but series init doesn't rely on dirtiness
<infinity> (And should all go away)
<cjwatson> I doubt it's as simple as IFP; I suspect the fresh-series logic in the publisher is wrong.
<infinity> Possibly that too.
<infinity> I'm still all for nuking the other pockets.
<infinity> After a quick verification that all the Packages files are empty, which they'd effin' better be.
<cjwatson> Pockets are so hardcoded that I suspect IFP has nothing to do with them.
<infinity> Any objections to such a tidy?
<cjwatson> I don't object, but best talk to LP folks first, and it would probably be a good idea to fix the publisher so that they don't come back next time.
<infinity> Well, let's see if they're all empty first.
<infinity> Right, so, tons of 0-length files, as I'd assumed.  And all with timestamps of Apr 26, 16:15.  Was that the last IFP?
<infinity> And going all the way back to breezy, which seems somewhat excessive.
<cjwatson> First publisher run after the IFP of quantal, but yes.
<infinity> Yeah, that's what I meant, but I'm a lazy typist. :P
<cjwatson> Might have been the first time we relied on the new fresh-series logic.
<infinity> Could be, since I don't remember partner being this... populous.
 * cjwatson goes to remedy critical lack-of-coffee error.
<infinity> Though, if it's taken 6 months to notice, I'm obviously not that observant.
<infinity> feceti/win 47
<infinity> Err.
<infinity> My IRC client is revolting.
<doko> is the publisher currently running?
<infinity> doko: As in, right this second, or in general?
<infinity> doko: It just finished running 4 minutes ago, and will run again in 3.
<doko> in general, don't see updates, like the python3-tz promotion to main
<doko> ok, did use the de archive mirror at release time, now switched back
<xnox> doko: apparmor ^^^ =)
 * cjwatson resolves conflicts in the transition tracker config; whoops
<Laney> the horror
<Laney> lsdiff !$
<Laney> oops
 * cjwatson unbreaks promote-to-release and tells britney to copy debootstrap for real
<xnox> cjwatson: the second email is "funny" and "confusing" =)))) it's addressed to me and my "sponsor" (cjwatson+ubuntu-archive-robot@...) and attached changes file has "Sorry, changesfile not available."
<xnox> and there is no indication where to the package moved.
<cjwatson> Yeah, I know
<cjwatson> bug 1069862 for the first part
<ubot2> Launchpad bug 1069862 in Launchpad itself "Need some way to copy without the copier ending up in From:" [Low,Triaged] https://launchpad.net/bugs/1069862
<cjwatson> Feel free to file a bug about the second part
<cjwatson> At the moment I'm just trying to make the whole thing work at all; prettiness is for the next iteration
<cjwatson> Hmm, neither debootstrap nor apparmor appeared on raring-changes
<cjwatson> Wonder why
<xnox> cjwatson: hmm... if it's a copy, then it's a known issue that there are no changes files available.
<xnox> same as for syncs, there are no changes files.
<cjwatson> Sure, but it could synthesise the changes
<cjwatson> They're in the database somewhere, after all
<cjwatson> No reason LP has to expose *every* detail of its internal DB layout :-)
<Laney> I asked for this when we first started doing API copies (for ubuntu-upload-history)
<Laney> someone, I forget who, argued that it was a bad idea
<cjwatson> Meh.  Dig that up and I'll pay attention to it if the argument is reasonable, otherwise I'll ignore it :)
<cjwatson> (But, if nothing else, why include an attachment at all if it's only going to say "nee-ner you can't have it"?)
<doko> python-apt failed to build on armel for the third time, given back now. (with different errors)
<Laney> failed to find it
 * Laney moves on with life
<mvo> doko: with a error that makes sense?
<doko> mvo, unreproducible GCC ICE
<mvo> doko: ok
<doko> the other one was a hang in the test suite
<xnox> mod-wsgi is not public module - but plugins, but still fixed to build in raring.
<xnox> dpkcd ~/
 * xnox clearly didn't have focus where I thought it was
<shadeslayer> hi, I was wondering if there's some sort of mirror redirector link that automatically redirects the user to his/her nearest iso mirror
<shadeslayer> like how ubuntu does
<shadeslayer> but I want it for Kubuntu
<stgraber> ubuntu.com uses the list of mirrors from Launchpad, though flavours aren't on releases.ubuntu.com so there's no such list for cdimage mirrors (and not that many mirrors I believe)
<doko> pyzmq/i386 ftbfs on the buildd, succeeds locally
<stgraber> For 13.04 I'll be re-organizing the Edubuntu DVD image a tiny bit by moving all our squashfs files under casper/ (we'll ship three of them in 13.04). To achieve that, I need to move our current ltsp squashfs to the new location without breaking 12.04 as we're doing LTS releases.
<stgraber> I came up with http://paste.ubuntu.com/1300855/ which should do the trick, but I'm happy to hear about less hackish solutions
<cjwatson> stgraber: looks fine, though my personal tendency is to leave such guards in place permanently by way of a kind of documentation
<stgraber> cjwatson: ok. I'll drop the FIXME and just make it a standard comment saying that as of 13.04 we're moving all the squashfses into casper/
<shadeslayer> stgraber: re mirrors, drat
<shadeslayer> IIRC there was a redirector sometime ago, but maybe that expired
<stgraber> well, kubuntu used to be on releases.ubuntu.com but that changed fairly recently
<shadeslayer> ah, I guess that makes sense then ...
<shadeslayer> ( move was most likely due to us moving to a community maintained flavor )
<stgraber> yeah, that and pretty limited disk space on the releases mirrors
<shadeslayer> righto, its just that someone mirroring Kubuntu ISO's wanted to know why Kubuntu did not do mirror redirects
<xnox> Please accept psycopg2 and python-cups into raring-proposed
<xnox> doko ^ =))))
<infinity> xnox: Hahaha.  <3 for the bash-completion fix.  Did you forward that to Debian?
<xnox> infinity: =))))) Yeah I got pissed at hitting tab and diverted my anger into upload......
<xnox> infinity: yeah I could. I need to forward a few patches from todays uploads.
<infinity> Oh, indeed.
<infinity> +Forwarded: not yet
<infinity> I'm not sure "not yet" is one of the documented states for that field, but I like it.
<infinity> "Forwarded: I'll get to it, stop nagging."
<knome> that's the documented state?
<infinity> The documented states are "no", "yes", and "not needed", I believe. :P
<infinity> But I like "not yet".
<infinity> I'd also accept "maybe, depends on your temporal view".
<xnox> I submitted a branch into lp:session-indicator it got "approved" but jenkins ci rejected it because merge proposal did not have commit message set in lp.net metadata..... wtf =)
<knome> what about "workforce welcome"
<xnox> knome: no, worforce is not welcome in this case =)
<knome> :)
<doko> cjwatson, am I allowed to copy xnox's python related uploads from raring-proposed to raring?
<xnox> doko: in part, I am being a tester for cjwatson's britney runs =)
<xnox> he did a few today.
<doko> xnox, ohh, nice, so please test =)
<bdmurray> infinity: I've done the verification of bug 1070542 depending on how you feel about waiving the aging period
<ubot2> Launchpad bug 1070542 in apport-symptoms (Ubuntu Precise) "not possible to use ubuntu-bug ubuntu-release-upgrader-core on precise" [High,Fix committed] https://launchpad.net/bugs/1070542
<xnox> doko: join in on the spam^W fun and upload to -proposed =)
<infinity> bdmurray: Yeah, done.  It's not like upgrader things get "tested" in any meaningful way by aging in proposed anyway.
#ubuntu-release 2012-10-24
<RAOF> Gah! The Unity SRU appears to _pointlessly_ replace a large batch of boost::* with std::*
<RAOF> Mmm. if (progress == 1.0f). What could possibly go wrong!
<stgraber> hmm, why am I getting "Raring-changes subscription notification" e-mails? Looking at mailman skaet is supposed to be the list owner so I'm not sure how I ended up on raring-changes-owner
<cjwatson> doko: Please don't manually copy from raring-proposed to raring, no.  (I'll run britney once I'm properly awake and at a real computer.)
<cjwatson> It'll be cronned once I trust it.
<doko> I didn't, therefore my question
<psivaa> cjwatson: We are hitting bug 1068178 every now and then on our daily precise encrypted-home preseeded installation tests. Would be helpful if you could have a look
<ubot2> Launchpad bug 1068178 in ubiquity (Ubuntu) "ubuntu ubiquity: cannot stat `/target/etc/fstab' error on preseeded - encrypted-home installations on precise" [Undecided,New] https://launchpad.net/bugs/1068178
<cjwatson> psivaa: Needs to be somebody else this week
<cjwatson> xnox: ^- can you look at that?
 * xnox looking
<psivaa> cjwatson: xnox: ok thank you
<cjwatson> though rings a faint bell - xnox, you might find that was fixed somewhere post-precise
<xnox> cjwatson: thanks.
<doko> xnox, do you have a list of outstanding "python (<< 3.3)" packages?
<xnox> doko: yeah. but all of them either "pretend" to build for all, yet really want to build against default only or FTBFS
<xnox> (as in with py2.7 & 3.2 & 3.3 and known)
<xnox> I have one more to upload and then I'll start rebuilding with with 3.3 set to default in a ppa.
<xnox> doko: let me push you the list.
<doko> xnox, could you file bug reports with the python3.3 keyword in debian for the pretending ones?
<xnox> doko: ack.
<xnox> doko: http://people.canonical.com/~xnox/py3.2/python3.2.html
<xnox> filter on bad only.
<xnox> I can upload pyopencl. shiboken ftbfs with reverse-dep pyside.
<stgraber> can someone kick the older lxc from precise-proposed? it contains missing "fi" statements for the devtmpfs handling causing a parse error
<stgraber> hallyn uploaded a fixed version (that new queuebot listed a couple of minutes ago)
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<skaet> stgraber,   Sorry about the communication glitch.  I went in and added you, infinity, cjwatson to the moderator set for the raring-changes list yesterday.
<cjwatson> FWIW the list of moderators in the mailman admin UI is basically just informational
<cjwatson> The true set of moderators is just people who have the moderator password
<infinity> Well, the list of mods or admins are the people who get nag mails.
<infinity> But yes, the two passwords are the bit that matters.
<Laney> not that -changes should require any moderation
<cjwatson> No, well, in this case it did until today
<cjwatson> But that's fixed now
<Laney> it /did/ but it /should not/ have :-)
<infinity> Laney: Absolutely, it shouldn't have.  But it did, regardless.
<stgraber> yay, IPv6 is back online, restarting queuebot :)
<ev> would someone kindly let whoopsie 0.2.6 and apport 2.6.1-0ubuntu6 through?
<smartboyhw> skaet, just a reconfirm: When is the blueprint deadline for R cycle?
<skaet> smartboyhw,  blueprints should be registered and accepted prior to the start of UDS if they need to be discussed there.   Otherwise, blueprints are accepted until planning freeze.
<skaet> oops... s/planning freeze/feature definition freeze/
<smartboyhw> thx skaet
<skaet> yw
<knome> skaet, btw, where can i see a list of the track leads?
<knome> skaet, and is desktop now the track where flavors should go? (i saw some lubuntu sessions on community)
<skaet> knome,  http://summit.ubuntu.com/uds-r/tracks <-- has the track leads
<knome> skaet, sweet. i don't recall seeing that page before
<skaet> and I recommend using the "community" track for the flavor work in general,  although depending on the topic, other tracks may be applicable in order to make sure the right audience knows to attend.
<knome> skaet, ok, thanks :)
<skaet> :)
<knome> bbl
<gema> xnox: ping
<xnox> gema: yes?!
<gema> xnox: the btrfs bp, I think you should own it
<gema> :D
<xnox> gema: ack.
<gema> xnox: I created it because bjf suggested we need to do something about that
<gema> and we do
<xnox> gema: not sure how much time I will have for it. But sure =)
<gema> but I think QA should be a participant, not the driver
 * xnox nods
<gema> xnox: if not you, someone in your team
<gema> I don't mean to burden you with it x)
<gema> xnox: we'll run the tests, sure, but we'll need advice and help on how to set up , etc
<gema> that only you guys can provide
<gema> xnox: so who is your approver?
<xnox> gema: slangasek will need to double check for it =)
<gema> ok, let me know
<gema> I won't change it until you let me know
<slangasek> gema: what blueprint is this?
<slangasek> (full title?)
<gema> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/qa-r-btrfs-automated-testing
<gema> slangasek: Adding automated test cases for btrfs
<slangasek> btrfs is not a priority for us in 13.04
<slangasek> so if that's really only about the btrfs filesystem... not gonna happen
<gema> slangasek: ack, then I will have that BP removed and we will touch on the subject in one of our ones for adding coverage
<xnox> ack.
<gema> slangasek: because we likely won't have the time either, but I don't want to forget about it
<xnox> gema: decline from uds-r, but keep it for reference and keep it as new/unapproved or something like that.
<gema> xnox: ok, let me see if I can do that
<xnox> gema: yeah =) keep as reference if someone else wants to do it =)
<slangasek> declined for uds-r
<gema> ok, thanks slangasek and xnox !
<ScottK> doko, cjwatson, etc: I need that sip4 upload to build before I can upload python-qt4 (and I think I have that about fixed).
<ScottK> (please accept)
<doko> ScottK, done
<ScottK> Thanks.
<knome> is there a specified uds twitter hashtag?
<cjwatson> https://uds.ubuntu.com/community/remote-participation/ just says #ubuntu
<cjwatson> (not really an #ubuntu-release thing though ...)
<knome> hmph. i was thinking whether one should use #uds or #uds-r
<knome> but maybe #uds... #ubuntu seems a bit too generic, don't you think?
<cjwatson> Not the kind of thing I care much about, and not a release management thing, as I said :-)
<knome> hehe, sure
<knome> just asking around O:)
<knome> cheers
<stgraber> can someone please reject the lxc in precise-proposed? we just noticed that the devtmpfs magic is a very bad idea. hallyn will be pushing an SRU to quantal to revert it there too
<infinity> stgraber: Sure.
<infinity> stgraber: How very bad an idea was it?
<stgraber> well, devtmpfs doesn't have "instances", so let's say it'd be very bad for someone to rm /dev/* in a container...
<stgraber> (crashing the whole host and all other containers, working around all of the apparmor magic, kind of bad)
<infinity> stgraber: Oh, indeed.
<infinity> stgraber: A static dev should always be fine anyway, given that you know in advance what nodes you'll need, surely?
<stgraber> yeah, that's what we had but for some reason that was breaking grub upgrades in containers (yeah, some people are weird and have grub installed in a container even though it'll never actually be able to run...)
<infinity> stgraber: Maybe grub just needs some container-guessing voodoo.
<stgraber> so for now we're going with broken grub upgrades but safe /dev and will figure out another way to fix the grub upgrade
<stgraber> yeah, I think some of the scripts already use running-in-container to check for that case, I guess we'll need some more of that
<cjwatson> hallyn and I went over that and I'd been hoping to avoid it :-(
<cjwatson> Bah, world sucks
<stgraber> yeah... once we have the device namespace in the kernel we won't need those hacks, but getting that stuff implemented and accepted upstream takes a lot of time... :(
<bdmurray> infinity: v-done for bug 1066445
<ubot2> Launchpad bug 1066445 in apt (Debian) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Unknown,New] https://launchpad.net/bugs/1066445
<infinity> bdmurray: Is that some sort of subtle hint? ;)
<bdmurray> infinity: if my verification makes sense yes it is!
<infinity> bdmurray: Yeah, good enough for me.  Released.
<stgraber> would appreciate if lxc could be reviewed quickly in quantal-proposed considering the impact. Clean diff can be found at http://paste.ubuntu.com/1303355/
<stgraber> (impact is that any container created with current lxc in quantal will be able to wipe the host's /dev)
<stgraber> (oh, and that any lucid container created with it won't boot)
<stgraber> the lxc in the queue is a revert of the change causing that (removing the patch from debian/patches) and another trivial bugfix
<stgraber> looks like the bug paperwork hasn't been done... /me gets that fixed
 * skaet looks at schedule for reviews, and sees if SpamapS  is around?
<infinity> stgraber: I'll give it a poke.
<infinity> stgraber: Both sensible fixes, accepting.
<stgraber> infinity: thanks
<skaet> thanks infinty
<infinity> stgraber: (The tar fix is almost as awful, TBH)
<infinity> stgraber: You might want to talk to the security team about a USN and letting me copy this to -security when you're done validating.
<bdmurray> It'd be good if the ubuntu-release-upgrader in quantal-proposed could move to -updates early
<infinity> bdmurray: Yeah, that was on my radar.  Thanks for verifying it.
#ubuntu-release 2012-10-25
<slangasek> ScottK, doko_: python-qt4 uploaded
<SpamapS> skaet: sorry I wasn't responsive earlier.. I'm in CEST (UTC+2) right now
<TheLordOfTime> SpamapS, explains why i have to reach you at strange hours in my time :p
<TheLordOfTime> oops sorry, that was targetted for privmsg :P
 * TheLordOfTime hates using irssi, it ignores basic commands.
<ScottK> slangasek: Thanks.
<stgraber> infinity: I'm doing a quick test of the lxc in quantal-proposed. If it's all looking good, are you fine with ignoring the 7 days limit and releasing to -updates today?
 * stgraber builds a test container of lucid, oneiric, precise, quantal and raring on i386, amd64, armel and armhf. That should spot any remaining bug or regression in the lxc-ubuntu template
<infinity> stgraber: I could be pursuaded.
<cjwatson> I've arranged (if I didn't get it wrong) for pending-sru to stop listing migrations in the development series.  People should not now be doing any of that by han.
<cjwatson> *hand
<cjwatson> It'll still list any cleanups that were missed by the automation.
<stgraber> infinity: tests passed fine on lxc, only current breakage is running the precise cloud image on quantal but according to the bug that'll be fixed next time utlemming spins an ubuntu cloud image
<stgraber> utlemming: if you're around, do you know when the new precise cloud image will land? The bug description says "That will be fixed by utlemming by Oct 25."
<cjwatson> proposed-migration is now running automatically every time the archive updates
<cjwatson> Output from most recent run (automatically updated): http://people.canonical.com/~ubuntu-archive/proposed-migration/
<cjwatson> Historical logs: lillypilly:~ubuntu-archive/proposed-migration/log/
<Laney> oh gosh, /this/ output
<stgraber> ;)
<Laney> the RT in Debian sometimes mails pkg-haskell dumps of britney output
<Laney> smile and nod
<cjwatson> Heh
<cjwatson> You get used to it
<cjwatson> When slangasek and I joined as ajt's lieutenants, the boot-camp training involved interpreting britney output and doing whatever was necessary to make it work
<cjwatson> Without actually being allowed to change the script
<cjwatson> So eventually I think it just got embedded in our brains
<cjwatson> It'll be more interesting once auto-sync starts
<xnox> The output is boring at the moment =)
<cjwatson> Hmm, glibc will take 5h+ to build on everything
<cjwatson> So in theory, if jodh and infinity get everything uploaded in the next couple of hours, I can start auto-syncs just before my end of week
<infinity> Maaaaybe.  I have a few more iterations to go through here, probably.
<cjwatson> Yeah.
<infinity> (After yesterday's meeting, I'd been targetting tomorrow, not today, but I'll see where I go)
<cjwatson> The LP database patch is being deployed at the moment, and I'm running some of the LP tests locally in parallel.
<infinity> Also got a bit of a late start today that nearly turned into a sick day.
 * infinity is feeling a bit rough.
<cjwatson> The alternative is that I find out whether the Legoland hotel has good internet access while being climbed over by kids :-)
<infinity> Ooo, Legoland!
<cjwatson> (Which, to be fair, I was probably going to end up doing anyway ...)
<jodh> cjwatson: I hear their internet access may be.... blocked... sorry, lame lego joke :)
<cjwatson> sigh :)
<iulian> Speaking of auto-syncs, is there a way to auto-sync haskell-* from experimental?
<iulian> cjwatson, Laney: ^
<cjwatson> Not automatically (at the moment anyway)
<cjwatson> Though in principle it's possible
<cjwatson> Perhaps you could file a bug on ubuntu-archive-tools for that kind of thing?
<iulian> Certainly, will do that.
<cjwatson> Laney: Is that something you'd like to happen too?
<Laney> Errrrrrrrrrrrrrrrr
<Laney> I have heebie-jeebies
<Laney> it's not unknown to upload a version of the compiler there for testing - would be quite terrible to auto-sync that
<iulian> So, how will we get all the haskell goodies?
<cjwatson> I'd be vaguely interested in having some scheme where we can auto-sync a nominated package list from experimental
<cjwatson> Which perhaps ought to affect MoM as well
<cjwatson> (It already looks at the sync-blacklist, so this isn't completely out of left field)
<Laney> I'm not sure if you can know that a given package will always be safe to sync from experimental without being the sole maintainer
<cjwatson> Of course it would be possible to track and manually sync them, too
<Laney> for the haskell case, I'd say write a client script yourself
<cjwatson> Which would allow a degree of sanity-checking
<infinity> Yeah, I like the idea of being able to do this, I'm not sure it's sane for haskell.
 * iulian nods.
<infinity> jodh: Oh, too late now, but for the record, there's no point in having a "raring" task on bugs you're working on, as an upload to raring would have closed the generic distro task.
<jodh> infinity: ah - right. wot no undo? :)
<infinity> jodh: No need to undo it.  You'll note the generic task just essentially goes away when you add one for the current devel release.
<infinity> jodh: Which is a curiously odd way for it all to work out, but meh.  Just pointing out you could have skipped that step (so you don't waste your time next time)
<infinity> stgraber: So, I don't really want to release that lxc if it's going to break something else.  Want to give me a solid nudge when you're sure that's no longer the case?
 * infinity wonders how we haven't opened yet and already have an uninstallable.
<infinity> Or, at least, an un-upgradeable.
<infinity> (python-sip)
<cjwatson> Uninstallable.
<cjwatson> But it's in python-qt4.
<cjwatson> According to raring_probs anyway
<infinity> Oh, the new python-sip provides sip-api-9.0, while python-qt4 wants an older version.
<infinity> Shiny.
<infinity> ^-- Does that fix it? :P
<infinity> Changelog implies that it will.
 * infinity goes for lunch while Yet Another Test Build runs.
<jodh> infinity/cjwatson: just pushed libnih_1.0.3-4ubuntu12 to raring.
<cjwatson> jodh: thanks, reviewing
<infinity> Let me throw that through a test build before you accept it.
<cjwatson> Right.  It looks OK.
<infinity> jodh: Shouldn't need the sed hackery in debian/rules anymore.  And there's also some oddity with dpkg-gensymbols.  Otherwise, looks like it's doing what we want.
 * infinity accepts.
<infinity> cjwatson: I thought you fixed -changes mails needing to be moderated?
<infinity> (somehow)
 * stgraber was just about to mention it
<infinity> Not that doing it manually bugs me terribly, but...
 * infinity eats his lunch instead of carin.
<cjwatson> infinity: IS said they had fixed it
<infinity> I'm so tempted to put "rarin'" in all my changelogs, and locally hack dpkg-genchanges to s/rarin'/raring/ for the .changes file.
<infinity> Hahaha.
<infinity> parsechangelog/debian: warning:     debian/changelog(l328): found eof where expected first heading
<infinity> parsechangelog/debian: error: fatal error occurred while parsing input
<infinity> Maybe not. ;)
<cjwatson> doko: do we need this gcc-4.7 to open?
<doko> cjwatson, what do you mean? no, we don't have to wait for the build to finish
<cjwatson> That's what I mean
<infinity> cjwatson: Would suck if we did need it, since it doesn't build. ;)
<infinity> cjwatson: Oh, that was the previous version.
<stgraber> wow, I think it's the first time ever that I'll have all my merges done before the archive even opens ;)
 * knome knocks the wood for stgraber 
<smartboyhw> touchwood
<infinity> stgraber: Good, then you can do mine too. ;)
<doko> but it wouldn't help with eglibc :-/
<stgraber> infinity: you don't actually have that many but no, I don't want to end up touched-it-last on things like plymouth ;)
<stgraber> but I'll probably start stealing some once I'm done test building all of mine, not much else to do until UDS anyway
<doko> stgraber, https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+builds?build_text=&build_state=failed (although talk with xnox which ones are already fixed in -proposed)
<xnox> stgraber: to be honest most of them are done now =)
<xnox> doko: stgraber: https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+packages is a better view.
<xnox> If it's not building and has a red cross, it needs fixing =)
<xnox> mathjax, objgraph, shiboken are non-py3.3 specific build failures
<stgraber> good. I'll take a look at any remaining one once I'm done starting test builds of all my merges and fixing any failure resulting from the test build
<xnox> I am unbreaking blender & morse-simulator as they hard-coded themself to 3.2
<cjwatson> Uh.  Why the manual syncs of stuff that'll be auto-synced soon enough anyway?
<cjwatson> Manual uploads, even!
<cjwatson> Huh.  Not in Debian yet.
<Laney> I suspect he uploads to both simultaneously
<Laney> but #-devel
<cjwatson> But in incoming.
<Laney> Exactamundo
<cjwatson> ScottK: Hmm, ditto opendkim.  Can't we sync that instead?
<ScottK> cjwatson: Could now.
<cjwatson> Wouldn't be an autosync because it's in experimental, but still.
<cjwatson> (And probably has less risk of knock-on uninstallability than gst*)
<ScottK> It's dealing with a security issue, so I wanted to get it in the hopper.
<ev> would someone please let whoopsie into proposed? This is a continuation of the changes from yesterday - I just forgot to include the InstallationMedia field.
<ev> It's a one-liner
<infinity> ev: Tsk.
<ev> I know, I was so excited when I saw you let the updates in
<ev> and there was already data to play with in the database
<ev> then I noticed that particular field was missing
<ev> smashed my head on the desk a few times, appropriately
<infinity> ev: Friends off.  Never speaking to you again, etc.
<ev> yes, yes, absolutely
<ev> I'll avoid eye contact
<cjwatson> infinity: looks like libnih is all built now
<infinity> cjwatson: Yeah.  I'm still back-and-forth with aurel and wookey on glibc, but I think the light at the end of the tunnel is growing.
 * infinity has already cancelled his dinner plans tonight, in anticipation of this taking a while.
<cjwatson> redirect-release-uploads now QAed and landed.  I just need to find somebody to arrange a deployment ...
<Laney> are we still looking at copies having to be re-done?
<Laney> copies to -release
<cjwatson> Laney: How do you mean?
<Laney> cjwatson: You suggested before that people hold off on syncing as the redirection might not apply there
<cjwatson> Copies to release will be forbidden (unless you're an archive admin or in ubuntu-release, but please don't); until we get round to updating syncpackage people will need to use -r raring-proposed
<cjwatson> Let me see, I can perhaps do that at least in bzr now
<cjwatson> I suspect it isn't worth rejecting and redoing the syncs already in the queue
<infinity> Depends on if any of them look like the sort that could create inconsistencies.
<infinity> I'd really like britney to be starting from a known-alrightish position.
<cjwatson> I've committed a change to ubuntu-dev-tools bzr to have syncpackage default to -proposed.
<cjwatson> infinity: Yeah - well, that was why I rejected gst* earlier
<Laney> I'll do the same for glib2.0 and pcre3
<cjwatson> maas and fonts-baekmuk are probably fine
<cjwatson> pidgin-libnotify too
<stgraber> maas is coped from the ubuntu archive (quantal => raring I guess). Any copy including binaries should be fine (not that it's easy to spot in the UI)
<stgraber> *copied
<cjwatson> Ah, indeed
<stgraber> what's the plan for the other uploads currently targeting raring? do you have a way of redirecting them to -proposed post-upload or should they also be rejected and re-uploaded to -proposed?
<infinity> Does the /ubuntu/raring poppy trick work for the main archive too, or just PPAs?
<infinity> If so, we could wholesale yank them from the queue and reupload them without even having to mangle .changes and re-sign.
<cjwatson> stgraber: I don't have a way to do that
<infinity> Err, I guess /ubuntu/raring-proposed :P
<cjwatson> Oh, well, yes, infinity's approach would I think technically work
<cjwatson> Shouldn't be limited to PPAs
<infinity> Well, or they could be yanked and reuploaded after your stuff is rolled out.
<infinity> Then they'll redirect.
<infinity> Also, a good test of the redirection in production. :P
<cjwatson> Yes, very true
<cjwatson> Excited.  It's nearly all there!
<stgraber> though we don't have the signed .changes so we'll need to sign them again before uploading, making LP think whoever does that is the uploader (not that we really care I guess)
<cjwatson> stgraber: It's not ideal.
<cjwatson> We could go through them and see which ones might be problems.
<infinity> Oh, we so have the signed changes.
<cjwatson> Where?
<cjwatson> Oh, there's that bug, isn't there ...
<cjwatson> actually, no, I thought that replay attack got fixed
<infinity> Oh, no.  We only have the .changes if poppy has a sad about it.
<infinity> Or I could just be looking at the wrong poppy.
<stgraber> anyway, from a quick look, the scary ones gdk-pixbuf, alsa-lib and gvfs are the ones I'd suspect may break things
<stgraber> (based from a very quick apt-cache showsrc on the queue entries)
<infinity> So, yeah, we'd need to re-sign either way, so editing .changes or not doesn't make a difference.
<infinity> But testing the redirection would be fancy.
<cjwatson> We'll test it quick enough :)
<cjwatson> I'm sure I can come up with a merge
<infinity> I have a kmod upload to do.
<stgraber> I have a bunch ready for upload FWIW :)
<infinity> Which is, ironically, being yanked from the quantal rejected queue. :P
 * stgraber -> dinner
<stgraber> ldb, sssd, tevent and ding-libs in ubuntu-desktop?? that seems a bit weird considering I just added them to the edubuntu seeds. Wondering if the script somehow got confused
 * stgraber starts a raring container to check
<slangasek> doko: did you put foundations-r-buildds-usage on the list for re-discussion at UDS-R?
<doko> slangasek, yes, I did propose it
<slangasek> doko: it doesn't look like the whiteboard has changed; what needs to be rediscussed?
<doko> well, priorities for non-distro builds in times when the buildds are needed for distro
<doko> and resources ... I think armhf buildds, but that might not be necessary when armel gets dropped for raring
<doko> ohh, and temporary resources for test rebuilds for the whole archive
<doko> slangasek, ^^^
<bdmurray> ScottK: from what I can tell bug 1066892 should be fix committed for precise but can released to -updates for quantal.  Does that sound right to you?
<ubot2> Launchpad bug 1066892 in kde-workspace (Ubuntu Precise) "initial power profiles do not use suspend support" [Critical,In progress] https://launchpad.net/bugs/1066892
<slangasek> doko: ok, can you please update the whiteboard with the current set of topics and make sure the right people are subscribed to be able to talk about this?
<DGMurdockIII> what do you guys use to host you torrents of ubuntu
<slangasek> doko: I'm not sure if the right people are at UDS to let us make any forward progress on questions like non-distro builds
<doko> slangasek, ok, however I'm not sure who would be responsible for qt5-edgers
<doko> I'm fine if this sees some follow-ups in phone calls
<slangasek> doko: where is that one?  I don't see that team name
<infinity> doko: We keep getting more ARM buildds, it may not be an issue even without dropping armel.
<slangasek> infinity: we keep getting more ARM buildds that don't work :P
<doko> was it canonical-qt5-edgers?
<infinity> slangasek: Only one of the recent ones doesn't work (and it should after a reinstall).
<slangasek> doko: tag Zoltan for that, please
<doko> ok
<slangasek> infinity: buildd capacity / contention has certainly been an ongoing issue regardless, so if we can realistically do some capacity planning I think it's worth having that conversation; I just don't want to have the conversation during UDS if we don't have the right people for it
<infinity> slangasek: Oh, I'm not arguing that it's not worth better coordination.  But yeah, we did this at UDS once, and it didn't seem to be all that useful, for the reason you state.
<doko> well, at least the resource planning with IS was done
<ScottK> bdmurray: Yes.
<cjwatson> doko: we do now have an explicit document from Francis Lacoste saying that Ubuntu has priority for the distro build farm.  I used this during release prep to drop the priority of the golang-tip builds.  From my POV that part of it is a solved problem.
<doko> cjwatson, but you do have to do this per build?
<doko> besides dropping the builds or an entire architecture
<cjwatson> doko: no, per PPA
<doko> slangasek, cjwatson: I don't insist on having a discussion at uds
<cjwatson> now, that doesn't address the PPA build farm - we (explicitly?) don't have an automatic right to priority there
<slangasek> cjwatson: so to hear PES tell it, flacoste has also given them an SLA, resulting in a rather high overcommit ratio ;)
<doko> ok, so am I allowed to request a downgrade for times of a test rebuild?
<cjwatson> slangasek: that's not what his document says
<slangasek> so we should make sure to invite PES to that session if we have it, too, in lieu of the phone call that didn't happen last week
<cjwatson> realistically, commitments to all parties can probably only be met by more builders, anyway ...
<cjwatson> doko: for the distro build farm, afaik yes
<slangasek> cjwatson: right, it may not be in *that* document, but PES believes they were given one ;)
<slangasek> so we ought to make an effort to sort this out, and UDS is probably as good a time as any to do so
<cjwatson> ok, agreed
<cjwatson> Francis will be there, won't he?
<doko> slangasek, so who to add for PES?
<slangasek> doko: Tim Chavez and smagoun please
<bdmurray> when I release kde-workspace to quantal should I also use the -d switch as the raring version is less than the one that will go into quantal-updates?
<slangasek> bdmurray: yes
<bdmurray> slangasek: thanks
<bdmurray> could somebody merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/unsubscription-fix/+merge/131473?
<infinity> bdmurray: Looking.
<infinity> bdmurray: iz done.
<doko> interesting ...
<doko> Unpacking python3-nose (from .../python3-nose_1.1.2-3ubuntu1_all.deb) ...
<doko> dpkg: error processing /var/cache/apt/archives/python3-nose_1.1.2-3ubuntu1_all.deb (--unpack):
<doko>  trying to overwrite '/usr/bin/nosetests-python3.3', which is also in package python-nose 1.1.2-3ubuntu1
<doko> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<doko> Errors were encountered while processing:
<doko>  /var/cache/apt/archives/python3-nose_1.1.2-3ubuntu1_all.deb
<doko> E: Sub-process /usr/bin/dpkg returned an error code (1)
<doko> apt-get failed.
<xnox> doko: hmm... doesn't look good.
#ubuntu-release 2012-10-26
<cjwatson> ^- first test of new upload scheme
<cjwatson> (I was in a bit too much of a rush the first time and beat the rollout to pepo, hence the reject)
<xnox> g
<xnox> please accept: libguestfs    x-kit    for python3.3 fixes
<cjwatson> x-kit's fine
<cjwatson> libguestfs (a) has a typo ("CPPCFLAGS") and (b) ignores test failures without explanation
<cjwatson> So rejected - I've mailed doko with an explanation
<cjwatson> xnox: ^-
<cjwatson> (Plus, next upload will magically go to -proposed)
<cjwatson> I've modified the queue client to look in -proposed by default, seeing as most things will be there now
<xnox> cjwatson: ack. thanks for the review.
<ScottK> ^^^ would be nice to get in before the general opening because there is a small chance packages might misbuild if it's not.
<infinity> ScottK: Sure.
<ScottK> Thanks.
<infinity> I should probably nap.  I think eglibc's done, but it might help to look it over when my eyes aren't close to being glued shut.
<ScottK> That means my local hack to avoid including the entire package changelog in the sync request worked ...
<cjwatson> ScottK: oh, yeah, perhaps I ought to have mentioned that in my -devel-announce post - the "entire changelog" bug is one tumbleweed fixed in ubuntu-dev-tools bzr
<doko> cjwatson: how long does it usually take for a package to migrate from -proposed to -release
<RAOF> doko: That depends on a number of things; the SRU default policy is 7-days, plus all bugs marked as tested.
<doko> RAOF, ahh, no, for raring
<RAOF> Hah!
<RAOF> ECONTEXT
<cjwatson> doko: there is no migration delay; it should be in the next publisher cycle after it's built everywhere, typically
<cjwatson> doko: see http://people.canonical.com/~ubuntu-archive/proposed-migration/
<doko> thanks
<doko> ohh, so we are blocking on the slowest arch
<cjwatson> Yes
<cjwatson> I *may* decide to weaken some of the constraints at some point, but I want to see how we do with these first
<cjwatson> I'd prefer to start accurate rather than assuming failure
<cjwatson> You can also look at it as "ensuring that multiarch systems combining fast and slow architectures don't fail"
<cjwatson> Since they often require that versions are in sync
<cjwatson> doko: BTW, packages in -proposed still build against -proposed, so this doesn't need to block build chains or anything
<doko> right
<xnox> doko: and the py3.3 rebuild ppa builds against raring-proposed as well ;-)
<doko> hmm, the onboard ftbfs looks interesting
<xnox> cjwatson: at the current moment nose is already deleted from -proposed, but not yet published in -release
<xnox> ah it's pending in release
<doko> bah, the setup.py overwriting locale.getpreferredencoding
<cjwatson> xnox: that ordering can happen because it does Archive.copyPackage (creates async job processed maybe a minute or so later) then SPPH.requestDeletion (immediate)
<cjwatson> But there's no risk of it actually getting lost AFAIK - worst case you get really unlucky and it vanishes for one publisher cycle
<cjwatson> I think timings are such as to render that implausible at the moment, though
<xnox> cjwatson: ok, i'm not sure if it ever managed to be published/available from -proposed or I have missed it with rmadison.
<xnox> obviously it was published enough for britney to find it....
<cjwatson> xnox: britney works off published Packages/Sources files, so it must have been fully published and available
<xnox> ok.
<cjwatson> prodded proposed-migration a bit - the conditions for running it weren't quite right
<cjwatson> should sort itself out next publisher cycle
<cjwatson> (specifically, it wasn't running when raring-proposed changed, only when raring changed)
<Laney> can we see the scripts and the britney modifications?
 * Laney finds promote-to-release
<stgraber> ^ isn't that supposed to be blocked to start with? or is that how it's being handled (lands in queue then something rejects automatically)?
<jdstrand> stgraber: let me try that again
<jdstrand> that exim4 update is a security update
<stgraber> sure, but you shouldn't be able to copy to raring, only to raring-proposed
<stgraber> I'm just surprised it even showed up in the queue, I thought it'd be rejected at copy time, not when hitting the queue
<jdstrand> stgraber: even as an AA?
<micahg> stgraber: AAs should be able to copy to the release pocket still AIUI
<stgraber> only if using the auto-accept flag
<jdstrand> I'll happily put it in -proposed
<infinity> stgraber: AAs can copy directly, with autoapprove=True or whatever it is.
<infinity> Ahh, you beat me there.
<jdstrand> ok, I was unaware of --auto-approve
<jdstrand> actually, I was not, I just haven't used it in a while
<jdstrand> that ^ will be rejected
<jdstrand> then the next one was with --auto-approve
 * jdstrand wonders if --auto-approve shows up here
<stgraber> it shouldn't as it won't hit the queue
<jdstrand> ah, makes sense
<stgraber> jdstrand: is it just LP being a bit slow or did you get an error with the --auto-approve copy? I'm not seeing 1.1 on the publishing page for exim4 in raring
<jdstrand> stgraber: I did not get an error. I assume it is slow
<jdstrand> I never can remember how long it takes. 5 minutes, 10 minutes, 30 minutes...
<jdstrand> not 5 it seems :)
<jdstrand> I did unembargo 8 openjdks
<jdstrand> so maybe that has something to do with it
<ScottK> doko: Can I get pykde4 building with 3.3 before we switch the default?
<doko> ScottK, is this on the images?
<ScottK> Yes.
 * ScottK double checks.
<doko> see -devel, we wanted to make it the default now
<doko> how difficult is this? like qscintilla2?
<ScottK> It requires CMake to know about the alternate include directory.
<ScottK> I have a test build of a dirty hack in progress.
 * xnox already did 3-4 CMake's
<xnox> blender morse-simulator hivex by memory
<ScottK> Does PYTHON_INCLUDE_DIRS include both?
<ScottK> It may just be then that I need to use that instead of PYTHON_INCLUDE_PATH
<xnox> ScottK: no, it doesn't. But you need to add both into it and make sure all cmakelists use PYTHON_INCLUDE_DIRS
<ScottK> pykde4 still uses the older PYTHON_INCLUDE_PATH, but that's an easy enough change.
<xnox> here I cheated: used pkg_config to populate PYTHON_INCLUDE_DIRS http://launchpadlibrarian.net/121099621/morse-simulator_0.6~alpha-1~exp1_0.6~alpha-1~exp1ubuntu1.diff.gz
<xnox> hivex is actually autoconf.
<doko> ScottK, sip: /scratch/packages/tmp/pykde4-4.9.2/sip/kdecore/typedefs.sip:955: Mapped type has already been defined in another module
<doko> make[5]: *** [sip/kterminal/sipkterminalpart0.cpp] Error 1
<doko> make[5]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7'
<doko> make[4]: *** [CMakeFiles/python_module_PyKDE4_kterminal.dir/all] Error 2
<doko> make[4]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7'
<doko> make[3]: *** [all] Error 2
<doko> fails already in 2.7 :-/ or is this known?
<ScottK> That's known.
<ScottK> There's an upstream patch for that.
<ScottK> doko: https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/fd30259903ad693b86476b6e8c280b93d0102223
<doko> just wanted to check for the so name renaming. ScottK: pointer?
<ScottK> There you go.
<doko> make[5]: *** No rule to make target `/usr/lib/libpython3.3mu.so', needed by `lib/pykde/akonadi.so'.  Stop.
<ScottK> My horrible hack attempt is just about to get to that point.
<cjwatson> Laney: lp:~ubuntu-archive/britney/britney{1,2}-ubuntu
<cjwatson> stgraber,jdstrand: while people with queue admin privileges on the release pocket *can* copy directly to it (and it'll land in the queue if we're frozen and you don't use auto_approve), please do not do so.  This is intended only for the sake of the automatic scripts themselves
<ScottK> doko: I'm stuck on "/usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory"
<doko> ScottK, I have a fix. but how do a re-run a configure step just for 3.3?
<ScottK> I don't know.  I just failed at that myself.
<doko> ScottK, didn't xnox's hint help?
<cjwatson> We should probably talk at UDS about exceptions, since there'll no doubt be some, but I don't really want AAs/release-team-members copying into release just because we can ...
<ScottK> That one is still building.
<ScottK> It's 1/4 of the way through python3.2
<xnox> ScottK: well I look at the cmakes output's first to see if they make sence and have the paths, before launching the build ;-)
<ScottK> That would have been one way to do it.
<stgraber> if an SRU team member has a minute, the bridge-utils I just uploaded to precise-proposed fixes a boot time hang that quite a few people have been nagging me about on IRC over the past few days. It's a 3 lines change to a script so should be trivial to review and matches what we've had in quantal for months, so pretty safe.
<doko>             -DPYTHON_LIBRARY=/usr/lib/libpython${v}$(shell python$(i) -c "import sys; print(sys.abiflags)").so \
<doko> ScottK, ^^^
<ScottK> doko: Thanks.
<doko> and I see it prefers python2 as the default python version. maybe change that for raring (not now)?
<ScottK> It has to.
<ScottK> The one part of the build that that affects hasn't been ported yet.
<doko> hrm, that's not enough ...
<ScottK> It would be a more general solution, I think, to change FindPythonLibs.cmake in CMake itself so that PYTHON_INCLUDE_DIRS has both directories in it.
<doko> I hate debhelper sequencer ...
<ScottK> If we do that, it's a one line change (I think) in pykde4 to use PYTHON_INCLUDE_DIRS instead of PYTHON_INCLUDE_PATH
<bdrung> slangasek: there are a bunch of patches for -proposed waits to get accepted (vlc, culmus, fonts-nanum-coding)
<doko> ScottK, please do if it's quick. I have a patch for the rest of the renaming
<ScottK> doko: Go ahead and do PYTHON_INCLUDE_DIRS in your pykde4 as that'll work regardless.  Let me look at CMake again.
<infinity> ^-- Shouldn't natty be EOLish?
<doko> ScottK, xnox: pkg_check_modules(PYTHON3 python3) how would that be patched to look for the python version used for the build (and not python3)?
<bdmurray> I setup a blueprint for the SRU team at https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-sru-queue-velocity
<ScottK> doko: I think python${_CURRENT_VERSION}
<ScottK> That's what FinePythonLibs uses
<jdstrand> cjwatson: so, exim4 never made it to raring. should I use raring-proposed?
<ScottK> that may be internal to it though.
<ScottK> Yes, it is.
<ScottK> debfx: ^^^ Do you know the answer to doko's question?
<skaet> infinity,  scheduled for 10/28 - will send out the email then.
<slangasek> bdrung: I'm aware of the SRU queue and will be plowing through them today.  Please make sure that all SRU bugs have the required SRU information before I get there, otherwise they'll go to the back of the queue again ;)
<stgraber> infinity: thanks. I poked a couple of the reporters on IRC so bridge-utils should be all tested before it reaches the 7 days mark.
<infinity> stgraber: Alrighty.
<infinity> stgraber: (Wait, how did you know it was me?)
<stgraber> infinity: sru-accept comments in the bug ;)
<infinity> stgraber: Oh, duh.  Right.
<infinity> stgraber: I thought someone had finally implemented queue auditing when I wasn't looking.
<stgraber> (no, we still don't have queue audit...)
<stgraber> right :)
<ScottK> doko: I'm lost in a maze of twisty turny cmake passage, all look alike.
<doko> ScottK, I think I have something ...
<ScottK> Great.
<bdrung> slangasek: done. please note that vlc has a preliminary MRE
<ScottK> It did, however, lead me to find a mistake I'd made in my hack to deal with multiple pyqtconfig.py files in the same directory for python3 in PyQt (thus the upload)
<ScottK> So getting lost wasn't time wasted.
<doko> cjwatson, ^^^ hmm, copies from ppa's including binaries don't seem to work
<cjwatson> jdstrand: Please do, although I would like to investigate what happened to your previous copy when I'm not in an airport.
<cjwatson> doko: see above comment :)
<doko> yeah, seen python3-defaults too
<jdstrand> cjwatson: ack
<jdstrand> (and done)
<ScottK> doko: Thanks.
<ScottK> doko: Would you mind accepting the python-qt4 one as well?
<doko> ScottK, is it really needed? arm builders are busy ...
<ScottK> Without it pyqtconfig isn't going to work in python3.  Not sure how important that is.
<ScottK> I got an accept from somebody.  Thanks.
<jdstrand> meh
<jdstrand> mdeslaur: seems that copies from ppas including binaries doesn't work atm, so the exim4 update was rejected (both to release and -proposed). the same thing happened to openjdk-6 and openjdk-7. cjwatson is aware, but will look at it late
<jdstrand> later*
<mdeslaur> jdstrand: ok, thanks
<doko> ScottK, any idea about https://launchpadlibrarian.net/121171710/buildlog_ubuntu-raring-amd64.pykde4_4%3A4.9.2-0ubuntu3_FAILEDTOBUILD.txt.gz ?
<doko> did build here locally
<ScottK> doko: No idea why it'd work locally and not on the buildd, but "sip: Unable to find file "QtCore/QtCoremod.sip"" gives me some thought that a retry after the PyQt upload build is done might work.
<xnox> doko this is some ^^^^
<xnox> there will be more vvvvv
<xnox> doko ^^^^
<doko> xnox, why python-numpy again?
<xnox> doko: not sure. reject for now and I'll double check my set.
<doko> xnox, because I know this has the extensions for both 3.x versions
<xnox> doko: ok, it was in my set because it has hard dependency on python3.2 via /usr/bin/f2py3.2
<xnox> which will be dropped, when we drop py3.2 support.
<xnox> so reject is correct.
<xnox> doko: cjwatson: barry: shiboken is shibroken & hence I cannot rebuild pyside and therefore britney is holding back python3-defaults
 * xnox decides to fix all of this.
<slangasek> do we not have support for overriding britney here?
<slangasek> because we shouldn't block on shiborken
<barry> xnox: slangasek is correct.  if you *must* fix shiboken, my suggestion is to essentially no-op the tests that crash the interpreter.
<barry> xnox: sucks because it hides a real bug (imho, in shiboken) but there you have it
<slangasek> if britney is set up right, I could probably force it by manually copying python3-defaults over :P
<slangasek> (and then let britney clean everything up afterwards)
<slangasek> but, er, I haven't gotten a briefing yet on where the britney instance is doing its thing
<slangasek> infinity: ^^ can you give me a pointer?
<slangasek> (preferably a non-null one)
<xnox> slangasek: I'm going to do the right way, and do "anything possible without touching britney" to migrate packages.
<doko> yeah on https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-5ubuntu3/+build/3928872/+files/buildlog_ubuntu-raring-armel.gcc-4.7_4.7.2-5ubuntu3_FAILEDTOBUILD.txt.gz
<slangasek> xnox: I don't think disabling a test suite to make a known-broken package build is "the right way" :)
<xnox> slangasek: it's bug 1070772
<ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [Undecided,Confirmed] https://launchpad.net/bugs/1070772
<doko> I think ignoring the test failure is ok provided you keep a bug report open and come to it back later
<slangasek> xnox: and any more-correct fix for sheboygan is going to take much longer to implement, and really shouldn't be allowed to block here
<xnox> and I don't know if it's bug in shiboken, the unit test, or our pythons.
<barry> slangasek: i don't either :)  just sayin' if there's no other way, that's how i'd work around it
<barry> xnox: i strongly suspect shiboken or some other related extension module
<barry> xnox: i tried to report it upstream, but the qt bug tracker hates me
<xnox> slangasek: shiboken is known fail to build from source in quantal. So can britney wave those?
<xnox> slangasek: should shiboken binaries & pyside binaries be removed from the archive then?
<xnox> is that a right fix?
<slangasek> doko: ^^ would you agree with removing the binaries?
<slangasek> they'd be uninstallable anyway, right?
<doko> generally yes, if there are no r-deps
<doko> afk now
<xnox> slangasek: we are talking about removing pyside - python qt4 LGPL bindings here. (pyqt4 is gpl)
<slangasek> the rdep chain is shiboken->pyside/pyside-tools->ipython3-qtconsole
<barry> ScottK might have some input here, if he's around
<slangasek> xnox: actually, I was only planning to remove shiboken; pyside could be left as-is until shiboken itself is fixed
<slangasek> but "as-is" would be "uninstallable"
<xnox> slangasek: python3-defaults will not migrate. britney is holding on pyside not shiboken.
<slangasek> anyway, the set of revdeps on pyside is small, which is why I think this is reasonable
<slangasek> oh
<slangasek> xnox: where are you seeing the britney output?
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
 * xnox *grins*
<slangasek> perfect, thanks
 * xnox also has no clue what britney is trying to tell me
 * xnox is troubleshooting pycrypto in the mean time
<slangasek> xnox: it tells you that updating python3-defaults results in those packages becoming newly-uninstallable
<slangasek> pyside isn't the only package in the list though
<slangasek> morse-simulator, python3-crypto-dbg?  what do we know about this?
<slangasek> xnox: pulling the shiboken binary will definitely unblock britney
<slangasek> because then pyside is *already* uninstallable in raring, so britney ignores it
<slangasek> sorry, I mean it'll unblock britney wrt pyside
<xnox> slangasek: morse-simulator is building, python3-crypto-dbg <--- working on it.
<xnox> slangasek: also having python3-defaults generate uninstallable defaults packages doesn't help either.
 * xnox goes to fix python3-defaults first.
<slangasek> where do you see this?
<xnox> slangasek: when trying to rebuild python-crypto in raring-proposed chroot.
<slangasek> hmm
<slangasek> but britney doesn't notice?
<xnox> $ rmadison -S -s raring python3.3
<xnox> $ rmadison -S -s raring-proposed python3-defaults
<slangasek> I don't follow
<xnox> defaults are at 3.3.0-0ubuntu1, while real one is at 3.3.0-2
<slangasek> why is that a problem?
<slangasek> they're different sources, there shouldn't be any lockstep versioned dependency
<xnox> hmmm....
<xnox> https://launchpad.net/ubuntu/raring/i386/python3-minimal/3.3.0-0ubuntu1
<slangasek> shiboken binaries shibounced
<xnox> slangasek: thanks.
<slangasek> fwiw if someone (ScottK?) considers not having pyside installable a problem and feels that it's better to have shiboken skipping the test suite and building with a known bug, I don't object
<slangasek> I just don't think we should do that as non-users of the package
<barry> slangasek: you won't mind if i subscribe ScottK to the bug and paste your comment there?
<barry> there == bug 1070772
<ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
<slangasek> no, that's between you and him ;)
<barry> :)
<barry> slangasek: he and i are on the same flight to cph so maybe we'll chat about it
<xnox> slangasek: ok. I had a dirty chroot.
 * xnox continues to debug python-crypto
<xnox> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt now looks very interesting
<xnox> are there any hints and trying to understand that output?
<slangasek> xnox: it's more interesting now because there were more candidates; my binary removals hadn't taken effect yet, it's nothing different due to that
<xnox> why python3-defaults is "tried" twice
<xnox> ah.... if other candidates migrate (all: changes) will the skipped packages migrate together or not.
<xnox> hmm.... clever but hard to read =)
<slangasek> xnox: so each block beginning with "trying:" is a single source package that's a candidate for copying; 'ori' is the count of uninstallable packages, per architecture, at the beginning of the britney run; pre: is at the current point in the run before adding this candidate; now: is the result after trying to add the candidate
<slangasek> xnox: correct
<xnox> and the got bit?
<xnox> got: 180+0: i-180
<slangasek> xnox: that says something about the increase in uninstallability... I forget exactly what, sorry
<slangasek> I believe it's "there are now 180 packages uninstallable on i386, which is an increase" (from 164)
<xnox> I can see how circular dependencies may  confuse britney.
<slangasek> they don't really confuse britney, they just make it slower due to NP-completeness :)
<slangasek> actually, I would expect us to be using auto-hinting for -proposed and it doesn't look like we are
<xnox> slangasek: can it please also do demotions/removals? it would be nice to ask britney to try to demote python3.2 and it tell me which packages I should fix =)
<xnox> although we have transition trackers for that, britney is more robust.
<slangasek> xnox: checkrdepends is probably better for that
<xnox> ok.
<slangasek> ah, seems the auto-hinting doesn't generate output anymore
<slangasek> that does mean you can't use the output to track the progress of a related set of packages that are not-quite-ready
<xnox> ^ above rebuilds makes python3-crypto-dbg to be Depends: python3 (>= 3.2.0) instead of Depends: python3 (>= 3.2.0), python3 (<< 3.3)
<xnox> and then we will just have to wait for powerpc builds to finish =(
<ScottK> barry/slangasek: pyside isn't on my list of things I care about.
<barry> ScottK: cool
<xnox> infinity: eglibc breaks boost
 * xnox wishes I uploaded boost-mpi-source1.49 before your eglibc upload.
<xnox> infinity: time.h now defines TIME_UTC, which boost used to be using.
<xnox> in boost 1.50 they renamed it to TIME_UTC_
<ScottK> Then boost needs to stop.
<xnox> well there is patch https://svn.boost.org/trac/boost/changeset/78802
<ScottK> Sounds like you know what patch you need to apply then ...
<xnox> but will that break abi/api/compat if I do it in boost1.49
<xnox> https://svn.boost.org/trac/boost/changeset/78802/trunk/boost/thread/xtime.hpp
<xnox> it's part of enum xtime_clock_types
 * xnox so does not want to have boost transition :`(
<infinity> xnox: I'm inclined to say that boost is broken, not glibc.
<infinity> xnox: But I'm happy to help with a boost transition during UDS.
<infinity> xnox: Is 1.50 GA, or still in devel?
<infinity> xnox: If it's GA, we should just switch, IMO.
<xnox> infinity: released August 20th, 2012 23:00 GMT
<xnox> infinity: well, that macro is part of C11 standard
<infinity> xnox: Yeah, we should just transition and be done with it, then.
<xnox> Unfortunately, on Linux, this is a problem in any C++ code. g++ implicitly defines _GNU_SOURCE, which in turn causes _ISOC11_SOURCE to be defined, regardless of what C++ standard is actually used. But regardless of this gcc feature, the boost interfaces are broken if I want to use C11 interfaces from C++ code.
<xnox> quote from https://svn.boost.org/trac/boost/ticket/6940
<xnox> I'm not sure *who* is defining _ISOC11_SOURCE
<infinity> Anyhow, I'm pretty deep in the gin right now, so if that's the only major fallout of glibc 2.16 so far, we're doing well.
<xnox> infinity: I think I will apply patch to boost1.49 and if rdeps break then we will move to boost1.50
<xnox> infinity: no, we need to move to boost1.50 then because there is stuff that uses boost::TIME_UTC which is now invalid
<infinity> xnox: If we're breaking ABI, we may as well just bump it correctly instead of fudging it.
<xnox> infinity: yes. So for the currently stuck package in britney I can just port that one to boost1.50 (this should then allow python3-defaults to migrate)
<xnox> and then we can do the boost transition
<slangasek> xnox: why is it not sufficient to #undef TIME_UTC in the boost headers?
<slangasek> (as a non-ABI-changing workaround)
<xnox> slangasek: it should be. Why did fedora not do this when they hit it?
<xnox> They first applied: http://pkgs.fedoraproject.org/cgit/boost.git/commit/?h=f18&id=f68c4dd92574829a34324290c15e360d0fedf643
<xnox> drop enclosed enum and "embrace" TIME_UTC macro
<xnox> and now transitioning to boost 1.50....
<ScottK> xnox: Probably safer to apply just the patch to 1.49 and do some rebuilds.
<xnox> ScottK: patch which does (i) undef TIME_UTC or (ii) s/boost::TIME_UTC/boost::TIME_UTC_/
<ScottK> The latter.
<xnox> I am doing a test build of slangasek 's simple solution, as I can't think of any reason why it wouldn't work.
<xnox> eglibc 2.16 is new and nothing should be relying on TIME_UTC.
<xnox> If something does conditionally rely on it & boost xtime.hpp at the same time it would only do so with boost1.50 which we have available.
<xnox> I really don't want to have boost1.49.ubuntu1 abi =)
<ScottK> OK.
<xnox> slangasek: autohinter did the magic to transition python3-defaults \0/
<slangasek> perfect
<xnox> and your boost fix works as well http://paste.ubuntu.com/1308399/
<ScottK> Boost insanity is curable for once.
<infinity> xnox: Good to hear.
#ubuntu-release 2012-10-27
<xnox> please accept boost1.49.0 after that's build and published I will upload boost-mpi-source1.49 (probably tomorrow)
<xnox> and once glibc & that propagates into release we can open =/
<xnox> thanks
<doko> done
<xnox> was not expecting you doko =))))
<doko> ScottK, pykde4 now buillds
<ScottK> doko: Excellent.  Then I suspect the difference between local and remote was you had ubuntu1 which was missing the pyqtconfig breakage I introduced in ubuntu2 (and fixed in ubuntu3).
<xnox> good night everyone
<slangasek> xnox: 'night!
<slangasek> see you Sunday
<xnox> slangasek: sure =) Sunday +1 hour ;-)
<slangasek> bdmurray: bugbot++ (bug #1071951)
<ubot2> Launchpad bug 1071951 in plymouth (Ubuntu) "package plymouth 0.8.2-2ubuntu2.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Invalid] https://launchpad.net/bugs/1071951
<infinity> xnox / slangasek: Thanks for the quick boost fix.
<bdrung> added wxwidgets and light-themes to the -proposed queue. now five packages wait for being accepted.
<infinity> Grr, who overzealously demoted glibc-doc-reference to universe?
 * infinity fixes.
<infinity> Maybe we need to make component-mismatches start to understand proposed, since transitiony things will be happening there.
<infinity> ^-- Updating the three packages that have strict libc6 deps due to naughtily using internal symbols.
<infinity> s/internal/private/
<infinity> I should probably sleep sometime this weekend.
<slangasek> infinity: so where are you right now, anyway?  London, or Copenhagen?
<infinity> slangasek: London.  I fly out Sunday morning.
<infinity> slangasek: More specifically, in Andy's living room.
<slangasek> ah, so you have one more night to enjoy the expensive beer before flying out to join us for expensive beer
<infinity> Something like that, yes. :P
<infinity> Though, tonight I had free gin.
<slangasek> woohoo
<infinity> Hrm, werid.  Shouldn't update_excuses tell me why eglibc can't promote (as update_output does) instead of just smiling and saying "oh no, it's totally a valid candidate, la la la"?
<infinity> Anyhow, all fixed now, and yay for it forcing a transition to happen properly instead of leaving it broken.
<infinity> cjwatson: Huzzah ^
<slangasek> infinity: what exactly do you want to see on _excuses?
<slangasek> _excuses tells you whether it passes the preliminary, package-local checks to be considered a candidate for the second pass
<infinity> slangasek: I dunno.  I thought it was meant to say "updating this will make the following uninstallable: dante-client, libdsocksd0, libnss-db, libsocksd0, libsocksd0-dev, unscd"?
<slangasek> nope, because that information only becomes available to it in the second pass
<infinity> slangasek: Or is that the fancy grep-excuses output that slaps _excuses and _output together?
<slangasek> and only packages that are self-consistent are included in the second pass
<slangasek> grep-excuses may do some fancypants combining, yes
<infinity> Yeah, I'm probably so used to interacting with update_* via the pretty display on the PTS that I've forgotten what the raw files look like, that's all.
<infinity> Any objections to letting glib2.0 and pcre3 in now that eglibc's published all over?
<slangasek> I don't have any objections, but I'm not sure I'm sufficiently well-informed for my opinion to count here
<infinity> (And then, soon, the world, but those two feel sufficiently low-level enough to get a pass on being next in line)
<infinity> slangasek: Well, we're close enough to autosyncing at this point that it likely doesn't matter anyway.  But I also have an ulterior motive of wanting to see glib2.0 pass its testsuite on all 5 arches, since it has a rather violent one.
<slangasek> infinity: right; I was interpreting the question from the POV of "are we close enough to opening that we can slip these in"
<slangasek> and I think you know better than I do whether that's the case ;0
<slangasek> ;)
<infinity> slangasek: Oh.  Yeah.  We are.  Was more a question of if anyone had seen any "oh god, no" mentions earlier that I missed.
<infinity> I'll probably just flush the queue once glib looks good.
<infinity> Well, flush the proposed bits.
<infinity> Might fetch and reupload all that release stuff.
 * infinity wonders why the pcre version grew an epoch.
<slangasek> wow, really?
<slangasek> pcre3 (8.30..-2) unstable; urgency=low
<infinity> http://packages.debian.org/changelogs/pool/main/p/pcre3/current/changelog
<infinity> Yeah.
<infinity> That was a curious attempt to... Do... Something.
<slangasek> to bump the version number following a .really-$prevver NMU
<slangasek> and then failing at dpkg --compare-versions, it seems :)
<infinity> Silly.
<slangasek> infinity: hmm, rejects?
<slangasek> is that expected as part of auto-redirecting to -proposed?
<infinity> slangasek: No, this is expected as part of me forcefully "redirecting" stuff that was uploaded before the redirect code landed. :P
<slangasek> ok
<infinity> I figure it's a small enough set that the few early mergers will come ask.
<infinity> You being one of them.
<slangasek> ;)
<slangasek> the early merger gets the confusing email
<infinity> kirkland: Ignore the rejects, they got reuploaded to -proposed.
<infinity> slangasek: Hrm.  What do you know of the autohinter?
<infinity> slangasek: Is it dumb as rocks?
<slangasek> infinity: whispers and tales; it post-dates my involvement with the britney code.  what's up?
<infinity> slangasek: Just trying to sort out if eglibc is going to need a manual shove.  It seems to be failing to get any love.
<slangasek> looking
<slangasek> the one thing about it, as discussed with xnox earlier, is that the autohinter gives no feedback whatsoever about sets of packages that are almost-but-not-quite ready
<infinity> In this case, eglibc (+rdeps) should have been ready in the last two passes.
<infinity> Unless I missed something.
<slangasek> infinity: the autohinter tried it, see bottom of update_output
<slangasek> it failed due to powerpc-specific problems
<slangasek> (which had not been shown earlier because britney doesn't bother showing you problems for other archs while i386 is still broken)
<infinity> Oh, that line relates to the above?  That wasn't entirely obvious.
<slangasek> yep
 * infinity goes to look at gcl/ppc and see how it relates to glibc..
<slangasek> let's all blame aj for the idiosyncratic output :)
<infinity> Ahh, indeed, gcl on PPC appears to have the same private linking issue.  Curious.
<infinity> And same with python-pypsignifit
 * infinity fixes.
<infinity> We need to get Apple to hire AJ as a UI designer.
<slangasek> Laney: webkit 1.10.1 doesn't appear to have an MRE; how does this fit the SRU guidelines?
<slangasek> Laney: the only linked bug report is about an arm-specific change to debian/rules
<ScottK> Any objection to me accepting the opendkim sync since it's a ~security related issue and I want to get the SRU/backports started.
<slangasek> ScottK: a sync to quantal, not to raring?
<ScottK> slangasek: sync to raring is in queue.
<ScottK> (has been since yesterday)
<slangasek> ah - if it's the raring one you mean, no objections
<ScottK> I just want to make sure the sync'ed tarball hits the archive first.
<ScottK> Yes.  Thanks.
<slangasek> Laney: bug #1044322 isn't covered by the GNOME MRE (it's a patch added in the package), and there's no SRU test case etc; please fix when you have a chance-
<ubot2> Launchpad bug 1044322 in glib2.0 (Ubuntu Quantal) "indicator-messages-service crashed with assert in g_menu_exporter_name_vanished()" [Medium,In progress] https://launchpad.net/bugs/1044322
 * infinity fixes the seeds to germinate stops trying to put libc-bin in universe...
<infinity> s/to/so/
<infinity> cjwatson: I assume you're LEGOLanding right now, but if not, we should be good to start autosyncs, methinks.
<infinity> doko: Any outstanding issues you've seen, or do you want to press send on your opening announce you've had queued up for days? :P
<doko> infinity, x32, fixing eglibc and preparing packages
<infinity> doko: We can bootstrap x32 any time.  Elaborate on "fix eglibc".
<doko> when I'm ready
<doko> infinity, you did remove the Vcs headers for Ubuntu in the merge
<infinity> doko: That implies they were there in the previous version (they weren't).
<infinity> doko: Anyhow, I'm in the process of moving the whole mess (for both us and Debian) to git.  Just working on the source package for now is fine.  But, I'll ask again, what needs "fixing" in eglibc?
<doko> which is strange, hmm
<infinity> doko: Did you just mean enabling x32 and bootstrapping it?
<doko> no, I'm currently testing
<xnox> infinity: slangasek: well when auto-hinting was required it _did_ appear in the britney output file. But I didn't quite understand but it was like "trying with autohints" combinations.
<xnox> infinity: slangasek: there should be past logs available on that host that you can read for you pleasure =)
<xnox> s/you/your/
<infinity> Autohinting doesn't imply any action being required, hence the auto.
<infinity> But yeah, the output's less than intuitive.
<xnox> infinity: autohinting is always shown in the logs on that host.
<xnox> infinity: it's just if no autohints were generated, none are shown on the public web-pages.
<xnox> infinity: see proposed-migration/logs/
<infinity> xnox: I know. ;)
<xnox> ah =)
<xnox> it was news to me. I guess I'm green and not acquainted with britney yet.
<infinity> I'm not a britney expert, by any means, but I used to stare at its output in Debian long ago, and it's coming back to me.
<doko> infinity, did you try building gcc with the new eglibc packages?
<doko> ftbfs
<infinity> doko: I didn't test-build gcc with the final upload, no.  What's the FTBFS?
<doko> http://paste.ubuntu.com/1309478/
<infinity> Looks a whole lot like a missing include.
<doko> no, features now emits an explicit preprocessor warning
<doko> which let's the configure mis-detect things
<doko> configure:3817: gcc -E  conftest.c
<doko> In file included from /usr/include/limits.h:26:0,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:169,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/syslimits.h:7,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:34,
<doko>                  from conftest.c:10:
<doko> /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
<infinity> Ahh, yes.  That warning.
<infinity> That's actually breaking unclever configure scripts?  They shouldn't be looking at warnings...
<doko> it's the standard AC_CHECK_HEADER check
<doko> so I assume this will happen for most packages
<infinity> Is it using -Werror during configure or something?
<infinity> But yeah, we could patch out that warning.
<doko> configure:4967: checking for limits.h
<doko> configure:4967: gcc -E  conftest.c
<doko> In file included from /usr/include/limits.h:26:0,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:169,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/syslimits.h:7,
<doko>                  from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:34,
<doko>                  from conftest.c:10:
<doko> /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
<doko> configure:4967: $? = 0
<doko> configure: failed program was:
<doko> | /* confdefs.h */
<doko> | #define PACKAGE_NAME ""
<doko> | #define PACKAGE_TARNAME ""
<doko> | #define PACKAGE_VERSION ""
<doko> | #define PACKAGE_STRING ""
<doko> | #define PACKAGE_BUGREPORT ""
<doko> | #define PACKAGE_URL ""
<doko> | #define STDC_HEADERS 1
<doko> | /* end confdefs.h.  */
<doko> | #include <limits.h>
<doko> configure:4967: result: no
<doko> I don't think we want to "fix" autoconf at this point
<infinity> http://sourceware.org/bugzilla/show_bug.cgi?id=13979 <-- Was the upstream bug that led to the commit.
<ubot2> sourceware.org bug 13979 in libc "A warning should be issued if FORTIFY_SOURCE is requested but not enabled" [Normal,Resolved: fixed]
<infinity> But yeah, revert that commit and see how it goes.
<infinity> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=05c2c9618f583ea4acd69b3fe5ae2a2922dd2ddc
<doko> so, yes commenting out this line fixes it
<infinity> Alright.
<infinity> Well, did you want to do the x32 bootstrap right now too?  Uploading an eglibc/gcc pair with a bootstrap seeded would do the trick.
<infinity> I'll commit the revert of that commit to Debian and Ubuntu, if you're satisfied that it DTRT for you.
<doko> or ... adjust the gcc-default patch to only add it when optimizing
<infinity> That would probably be more correct, but some people might be defining it themselves.
<infinity> Well, I suppose if they are, that's what the warning is for, to be fair.
<infinity> *shrug*  I'm open to fixing it in both places, though the eglibc warning is clearly correct, I can see the argument that it's correctness that could cause a lot of annoyance.
<ScottK> I just noticed a nice side effect of uploading to -proposed is that now bugs get closed when I package is built, not when it's uploaded which to me seems more logical.
<infinity> doko: So, are you going to fix gcc to DTRT here?  I'm less concerned about the x32 bootstrap as (a) it's not a priority, and (b) we don't actually have kernel support for it right now, but we can certainly do the x32 bootstrap soon.
<doko> infinity, it's not that important that it needs to go in within the next hour. yes, I'm testing a fix
<infinity> doko: Excellent.
<doko> infinity, gcc-4.7/eglibc now building on armel/armhf/powerpc. amd64 and i386 need one manual bootstrap. binaries for these builds can be found at
<doko> deb http://people.canonical.com/~doko/tmp/install-{amd64,i386} ./
<doko> the gcc-4.7 build failures on armel, armhf, powerpc will be fixed once eglibc is built on these archs
<infinity> doko: Hrm.  I thought we weren't doing the bootstrap this weekend.
<infinity> doko: (I also didn't think we were reverting that commit, in favour of just fixing gcc instead, but meh)
<doko> there will break too much without it, and no gcc will bootstrap without it
<doko> next time, just make sure that gcc still builds with an updated glibc ;-P
<infinity> doko: And you didn't document the ln changes in sysdeps/ ... Was the s/-s/-sf/ actually necessary?  (I didn't see any header breakage)
<doko> re-run the binary target
<infinity> doko: Ahh.
<doko> and yes, there are other ln -sf calls
<infinity> Alright, well, I guess we get to bootstrap right now. :P
<doko> the x32_RUN_TESTSUITE thing doesn't work as intended, but there's another consistency check before running the testsuite
<infinity> The testsuite will fail miserably on the buildds, so here's hoping it doesn't run.
<doko> I did check it here
<doko> up to you if you disable the tests with nocheck for the bootstrap
<doko> infinity, is the missing -xmx32 in debian too?
<doko> -mx32
<infinity> Oh, whoops.  Yep.  I'll commit your changes to Debian in a sec.
<infinity> Or you can, I suppose.
<doko> ok, I'll notice daniel about it
<doko> no
<infinity> No?  Kay, I'll do it. :P
<doko> afk now
<doko> infinity, once this is built, maybe we should rebuild everything which did get built against eglibc 2.16 (except gcc-4.7)
<doko> all libreoffice builds were started with 2.15, so that doesn't need an update
<infinity> doko: If we can find evidence in build logs of features being turned off, maybe.
<doko> cheaper to just rebuild
<doko> basically I wouldn't trust any autoconf built package
<infinity> doko: http://paste.ubuntu.com/1311032/
<infinity> Err, I should move that patch addition down to the doko block in the changelog.
<infinity> doko: Otherwise, look good to you?
<doko> +#x32_RUN_TESTSUITE = no
<doko> this doesn't seem to work as intended
<infinity> Oh.  As in, not at all? :P
<doko> +  * Fix building x32 miultilib libraries, by correctly passing -mx32.
<doko> typo
<infinity> I was trying to be authentic!
<infinity>         elif [ $(call xx,RUN_TESTSUITE) != "yes" ]; then \
<infinity>           echo "Testsuite disabled for $(curpass), skipping tests."; \
<infinity>           echo "Tests have been disabled." > $(log_results) ; \
<infinity>         else \
<doko> then you would have used your version of the revert-bz13979.diff ;-P
<infinity> You'd think that would work...
<doko> it didn't
<doko> according to the build log
<infinity> Special.
<doko> I didn't care, because it did work anyway
#ubuntu-release 2012-10-28
<infinity> doko_: Ahh.  foo_RUN_TESTSUITE would work fine, but the ld.so test just above it fails, that's all.
<infinity> (Because our kernels don't have the x32 syscalls at all, I assume)
<doko__> infinity, leaving now for the airport. if you can find a reliable armel buildd to buld gcc-4.7, that would be nice... fails for random reasons ...
<micahg> does copy-package not show what it's copying to in dry-run mode or am I doing it wrong?
<infinity> micahg: Example command-line?
<micahg> ./copy-package -s quantal-updates --to-suite=raring-proposed -b firefox -n
<infinity> Actually, I'm not convinced it shows the pocket it's copying to in non-dry-run.
<infinity> If that's what you mean.
<micahg> ok, well, it should hit the queue anyways, so..
<infinity> It'll also not work.
<infinity> Unless Colin fixed that.
<micahg> hrm?
<micahg> to -proposed?
<infinity> Something broke with copies-with-binaries to the devel release, if I recall.
<micahg> ugh, ok, I'll wait then
<infinity> Once it's sorted, I'm sure we'll do a quick quantal-updates->raring sync run anyway.
<micahg> ok
<infinity> (Ran into this with exim4 earlier)
 * micahg was wondering why Firefox wasn't copied, that explains it
<infinity> cjwatson: Any idea what went wrong with copies-with-binaries to devel?
<infinity> cjwatson: (Or are you still LEGOing with family?)
<infinity> slangasek: So, I don't know if you ever got around to reviewing kmod for quantal before we rejected it due to timing, but the above is identical, except for s/quantal/raring/ in the changelog.
<slangasek> infinity: I did review it and rejected it only because we didn't need it at the time.  Given that you're asserting that it's the same, how's about you go ahead and self-accept so's I don't have to go to the trouble of proving this
<infinity> slangasek: Works for me.
<cjwatson> jdstrand: so, I did the exim4 copy and it worked; the logs indicate that you forgot to use the -b option ...
<cjwatson> jdstrand: if you could try that with openjdk-6 and openjdk-7, that'd be good
<cjwatson> jdstrand: include_binaries=True if you're using some tool other than copy-package
<cjwatson> Adam's set raring to active development
<cjwatson> and is clearing the queue
<cjwatson> I'm doing an initial test auto-sync now
<cjwatson> with four packages
* infinity changed the topic of #ubuntu-release to: Ubuntu 12.10 released | Archive: Open | Raring Ringtail Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<cjwatson> which would be easier if I hadn't apparently subtly broken auto-sync somewhere along the way
 * cjwatson debugs
<cjwatson> ah, copying into Ubuntu would probably work better than copying into Debian, on the whole
<slangasek> balloons: ping
#ubuntu-release 2013-10-21
<slangasek> hmm, surprised to see that pam was accepted; I'm just taking care of TIL merges, why was this cherry-picked into trusty-proposed while other packages aren't?
<cjwatson> doko_: IIRC you said you had an opening mail ready to send?
<doko_> cjwatson, yes, let me finish this
<doko_> xnox, do you want to upload / sync the bits for boost1.54?
<xnox> doko_: boost1.54 and boost-defaults are uploaded into trusty. I'd rather complete transition, once auto-sync is running / archive is open.
<cjwatson> doko_: send away :)
* cjwatson changed the topic of #ubuntu-release to: Released: 13.10, and 12.04.3 | Archive: open | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<Laney> wee
<doko_> bye bye catching up on arm64 ...
<xnox> doko_: =)
<xnox> doko_: i was pondering if it make sense to upscore arm64/trusty-release builds.
<doko_> xnox maybe, but then only some at a time, and selected ones.
<cjwatson> doko_: arm64'll be fine, it's doing well enough
<cjwatson> I don't think we need to worry about it
<cjwatson> autosyncs starting
<cjwatson> I expect a bunch of stuff will fail due to mid-perl-transition, but it'll clear out in time
<cjwatson> sigh, the perl transition doesn't half make p-m take forever
<cjwatson> I think I'll just block perl until the transition is a bit further along
<doko> still not defaulting to openmpi1.6, there's an open debian report about the transition, left alone ...
<cjwatson> aha, I see the auto-sync is building now
<psivaa> cjwatson: ( i know there is a lot going on there :)) but autorun.inf and wubi.exe are missing from the desktop images of trusty.. are they still being refined?
<xnox> cjwatson: i guess i should add it to the checklist, that symlinks need updating.
<cjwatson> psivaa: I ran the cron job with no attention whatsoever :)
<cjwatson> xnox: yes please
<cjwatson> psivaa: so when xnox sorts out the symlinks, they should return
<psivaa> cjwatson: ack, thanks :)
<cjwatson> psivaa: is that what's keeping the images in pending?
<xnox> cjwatson: well... i don't have access to update them =) i was going to bump wubi + add the steps to the NewReleaseCycleProcess.
<cjwatson> xnox: oh, are they in ubuntu-archive or something?
<psivaa> cjwatson: yes at least the desktop ones
<cjwatson> xnox: can I just symlink saucy/stable to trusty/stable for now?
<xnox> cjwatson: yes, please.
<cjwatson> xnox: done
<cjwatson> psivaa: doing another run now then
<xnox> cjwatson: added a step about wubi symlinks before the cdimage cron step, on the NewReleaseCycleProcess.
<cjohnston> lool: I've created a config for status.ubuntu.com for ubuntu-t.. I figured leave ubuntu-s running for a little while still?
<cjwatson> xnox: thanks
<doko> promoting ruby2.0 ...
<doko> cjwatson, should we promote all lib*-perl modules needed for 5.18?
<cjwatson> doko: I'm going to check that over after the dust has settled
<cjwatson> doko: Right now I expect there could be noise and don't really want to spend time sorting it out manually :)
<cjwatson> doko: that said, as long as you're aware that c-m-proposed might be lying if there are alternative dependencies involved and check it manually, be my guest
<cjwatson> I suspect we should try to avoid that dep on libperl4-corelibs-perl (not for 5.18 as such)
<cjwatson> Riddell: Can I sync citadel-client/citadel?  The only diff in citadel is https://launchpadlibrarian.net/142321516/citadel_8.16-1_8.16-1ubuntu1.diff.gz, but any build in >=saucy will build against libical 1.0 anyway, so I think that's probably not worth merging?
<cjwatson> this is from auto-sync:
<cjwatson> [New] citadel-client_8.20-1
<cjwatson> No previous publications in Ubuntu
<cjwatson> OK (Y/n)?  y
<cjwatson>  * Trying to add citadel-client ...
<cjwatson> citadel-client_8.20-1 is trying to override modified binary citadel-client_8.16-1ubuntu1.  OK (y/N)?  n
<Riddell> cjwatson: yeah go for it
 * Riddell at linuxcon this week, not very responsive
<cjwatson> Riddell: responsive enough, thanks :)
<cjwatson> enjoy linuxcon
<infinity> xnox: Scoring up arm64/trusty-release builds would choke out proposed builds and cause unnecessary arch skew.  It's a feature that proposed builds first in this case.
<cjwatson> Laney: you might want to merge your ttf-wqy-zenhei delta into the new fonts-wqy-zenhei package in Debian; it looks like perhaps your fix was never forwarded and Debian applied a less-optimal fix?
<cjwatson> at least insofar as I can make it out
<bdmurray> cjwatson: could you merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/reversed-releases/+merge/191997
<cjwatson> bdmurray: done
<bdmurray> thanks
<cjwatson> bdmurray: yikes.  is there override damage in the archive to clean up?
<Laney> cjwatson: Don't remember, will check it out
<Laney> it's on my merge list
<cjwatson> ok
<cjwatson> thought it might not have been due to the source package name change
<bdmurray> cjwatson: I don't believe so but will check the log files.
<cjwatson> bdmurray: good stuff
<bdmurray> cjwatson: did you add trusty to meta-release?  if not I have a change to make for saucy and can do that too
<cjwatson> bdmurray: I didn't, go for it
<Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687156
<ubot2> Debian bug 687156 in ttf-wqy-zenhei "fontconfig disjunction syntax incorrect" [Normal,Open]
<Laney> With amusing response
<cjwatson> now that's a set of build queues and a half
<cjwatson> glad we got those extra two x86 builders
<stgraber> otherwise it'd have given a pretty funny result with armhf first, then powerpc, then x86 ;)
<bdmurray> cjwatson: no phased update percentage changes were made in error, however some packages were in raring weren't incremented when they should have been.
<ScottK> slangasek: Bug 1240673 seems to be piling up a fair number of "Me too" responses and seems to be all recentish Dell laptops, so I thought it might be worth mentioning given the Canonical/Dell partnership.
<ubot2> Launchpad bug 1240673 in upower (Ubuntu) "Reports 0% charged for fully charged batteries" [High,Confirmed] https://launchpad.net/bugs/1240673
<cjwatson> bdmurray: ok, that's presumably not horrible
<stgraber> could someone please binNEW lxc? (added lxc-tests)
<cjwatson> stgraber: looking
<cjwatson> stgraber: "test binaries" - for use by whom?  automatic?
<stgraber> cjwatson: I think hallyn's plan was to make use of those in autopkgtest and also help when debugging someone's system (those are test binaries for the liblxc library, basically one small binary per API call)
<cjwatson> ah, I see
<cjwatson> stgraber: do you plan to seed / depend on it somewhere in main, or should I drop it in universe?
<stgraber> I'll add it to one of the supported seeds (though it'd probably be just fine in universe)
<cjwatson> ok, accepting then thanks
<stgraber> thanks
<Laney> Are we SRUing things to teach them about trusty?
<arges> Laney: I can help, looking at debootstrap unless soembody else is looking at it
<Laney> I guess only if things actually fail
<Laney> Just noticed dput-ng (fixed upstream to not hardcode)
<arges> Laney: well on my precise box, i'd like to have a trusty sbuilder
<Laney> Yes, debootstrap would fall into that class
<doko> cjwatson, I see that libparams-validate-perl and libdatetime-perl do need updates. can I upload, or are other moduls first?
<infinity> doko: I assume he's going in dependency level order, according to http://people.canonical.com/~ubuntu-archive/transitions/perl5.18.html
 * infinity bumps a couple of builds to get level 1 done.
<arges> Laney: i'm tracking this with bug 1242747 fyi
<ubot2> Launchpad bug 1242747 in debootstrap (Ubuntu Saucy) "Add trusty as known Ubuntu release" [Undecided,New] https://launchpad.net/bugs/1242747
<Laney> okay
<cjwatson> doko: Yes, I'm going in dependency order as infinity says
<bdmurray> could somebody release the SRU fixing bug 1241123?
<ubot2> Launchpad bug 1241123 in ubuntu-release-upgrader (Ubuntu) "lubuntu-desktop PostUpgradeRemove rule is unnecessary and problematic" [High,Triaged] https://launchpad.net/bugs/1241123
<infinity> bdmurray: Looking.
<infinity> bdmurray: Done.
<bdmurray> infinity: thanks
<infinity> ScottK: debootstrap in precise-backports probably needs more love (shame it was ever backported...)
<ScottK> Sigh.  OK.
<infinity> I wonder if maybe we should just make the SRU version supersede it.
<infinity> And then remove it.
<ScottK> I think that's quite reasonable.
<ScottK> +1 from me.
<arges> ScottK: infinity : fyi, i'm looking at debootstrap now on bug 1242747, just uploaded precise. was planning on doing it for Q/R/S as necessary, let me know if that will be a problem
<ubot2> Launchpad bug 1242747 in debootstrap (Ubuntu Precise) "Add trusty as known Ubuntu release" [Medium,In progress] https://launchpad.net/bugs/1242747
<infinity> arges: Go ahead with Q/R/S, I'll reject the precise upload and reupload with a different version number.
<arges> infinity: ok
<lool> cjohnston: Ok; thanks -- we will probably use T starting with next vUDS
<infinity> arges: precise (well, and lucid, but no one seems to care about that one) was the only release where someone backported debootstrap to -backports and sort of messed up the world.
<cjwatson> I used to dump debootstrap into -backports quite frequently because it was less paperwork
<infinity> cjwatson: Yeah, went sideways when people started SRUing it religiously, since people with -backports enabled have a stale version, unless it keeps getting backported.
<infinity> People use dput-ng?  Man, I only just switched to dput from dupload.
<infinity> ScottK: If you want to do the honors on my debootstrap/precise upload, that should be sufficient for us to just delete (or ignore) the backports one going forward.
<ScottK> OK.
 * ScottK looks
<xnox> infinity: dput-ng is suppose to support the fancy new "grand a DM upload rights" but it fails to work for me =(
<arges> can somebody unapprove the raring deboostrap upload? I forgot to add the bug # to the changelog.
<infinity> arges: Sure.
<arges> thanks
<ScottK> arges: Too late.
<ScottK> infinity: ^^^
<infinity> Hrm?  Not too late.
<infinity> I just rejected it...
<ScottK> OK.
<ScottK> infinity wins.
<infinity> And, since the publisher wasn't working hard enough already, it's kernel SRU release day.  Whee.
<rtg> infinity, saucy LTS ?
<infinity> rtg: I'll check out lts-saucy after I've released the rest of the world here.
<ScottK> arges: Accepted the fixed  one.
<arges> ScottK: ok cool, I just dput saucy, and that should be it.
<seb128> could somebody review the gnome-control-center SRU there ^
<seb128> it's part of a round of improvements to a bug about keybinding-to-change-keymaps not working with annoys lots of user
<seb128> (we get like 30 comments a day on this bug since release)
<doko> infinity, is https://launchpad.net/ubuntu/+source/esys-particle/2.2.u2-2/+build/5137627 going to suceed?
<infinity> doko: Yes.
<infinity> doko: At least, the previous versions did, I don't see why it wouldn't.
<arges> ScottK: Verified debootstrap for P/Q/R, but I can't find the saucy-proposed package to verify.
<ScottK> arges: Not sure where it went.  Upload it again.
<arges> ScottK: ok
<arges> ScottK: actually I see this in my inbox:
<arges> File debootstrap_1.0.53ubuntu1.tar.gz already exists
<arges> Which is the trusty version
<infinity> You want 0.1
<arges> Ok, fixing.
<ScottK> arges: Did that one too.
<slangasek> bdmurray: so there's a new error reported for procps, but I don't seem to be able to get enough info out of the error tracker to confirm whether it's ignorable. https://errors.ubuntu.com/problem/24165ca0a985e6022d9da9a8e438b3e09f163c61
<slangasek> I suspect this is a corner case only affecting those users who already had tried to install the previous busted version of procps
<bdmurray> slangasek: package install failures for stable releases should still go to Launchpad but I don't see any for procps
<bdmurray> slangasek: also one of the problems indicates it is a fresh install - https://errors.ubuntu.com/oops/03a6150c-38c7-11e3-a8a4-e4115b0f8a4a
<slangasek> bdmurray: which wouldn't change the behavior of applying the SRU, I think?
<bdmurray> ah right, sorry
<slangasek> it's still unlikely to be a bug in procps itself, the error is because apt is telling dpkg the wrong thing
<slangasek> so I think we should just override
<bdmurray> agreed
<slangasek> remind me where to do that?
<slangasek> I'm sure I have a bzr checkout here somewhere, but don't remember its name
<bdmurray>  bzr+ssh://bazaar.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides/
<slangasek> thanks
<seb128> ^ that gnome-settings-daemon upload is supposed to improve the keyboard layout switching issue I was mentioned earlier for gnome-control-center, would be nice to get in as well
<doko> trying to find out why https://launchpad.net/ubuntu/+source/libperl-critic-perl/1.119-1/+build/5139895 fails. works for me in a local chroot
<slangasek> doko: the latest failure is listed as a dep-wait on libmodule-pluggable-perl, is that wrong?
<slangasek> hmm, looks like it's in the archive now
<infinity> "Module::Plaggable Provides a simple ..."
<infinity> PLAGGABLE.
<stgraber> doko: a local sbuild build gives me the same thing as LP (when building with -proposed and only main+restricted)
<infinity> Oh, that probably needs a promotion.
<stgraber> right, just checked and the b-d is in universe
<stgraber> so that'd explain it
<infinity> Yeah, that got split out from perl-modules.  I'll promote.
<infinity> (Please, no one else do so, it'll disappear)
<infinity> component-mismatches-proposed is an entertaining mess...
<stgraber> ;) so speaking of which, has any process been made on fixing the double-override bug?
<infinity> stgraber: No, we've had bigger fish to fry.
<stgraber> ^ procps is a mini-transition I'll take care of it
<stgraber> (as in, it's my upload so need someone to binNEW for me, but I'll take care of the transition after that)
<infinity> stgraber: I'll poke the binaries when they all roll in.
<stgraber> seems like we have a bit of a java mess going on in -proposed? (looking at c-m)
<infinity> stgraber: Yeah, looks like.  Will worry about it after the dust has settled a bit.
<infinity> {standard input}:1: Error: junk at end of line, first unrecognized character valued 0x10
<infinity> {standard input}:1: Error: unknown mnemonic `â¬' -- `â¬'
<infinity> {standard input}:1: Error: unknown mnemonic `ËÂ¼s3' -- `ËÂ¼s3'
<infinity> Hrm, I wonder if that might be memory corruption.
<infinity> Or the world's best assembler...
<doko> stgraber, just one package
<infinity> stgraber: Accepted.
<stgraber> ifnthanks
<stgraber> infinity: thanks
<stgraber> (works better when I actually press tab apparently)
<seb128> infinity, stgraber, slangasek, bdmurray: could one of you review the gnome-control-center/gnome-settings-daemon saucy SRUs today? the "can't switch layout" seems it's sort of really annoying russian and chinese users from the number of angry comments we get
<infinity> seb128: saucy?
<seb128> infinity, yes
<infinity> seb128: Looking.
<seb128> infinity, thanks
<slangasek> eep, yes, being able to change your keyboard layout is a bit important when your native language and English require mutually exclusive things :P
<seb128> slangasek, well, you can change it, but not without a keybinding ... which is sort of inefficient ;-)
<seb128> (e.g the indicator works, but it requires going to click there every time)
<seb128> infinity, thanks!
<infinity> This gsd patch is quite... Extensive.
<infinity> seb128: Do you know if this is going or has gone upstream?
<seb128> infinity, not going upstream, we are adding code they dropped basically
<infinity> :/
<infinity> Kay.
<infinity> I can follow what it's meant to do, and it seems sane, but hard to audit a patch this large by eyeballing it.
<seb128> infinity, they moved the feature to gnome-shell (which makes sense), ideally we would do the same with unity, but unity7 is not having enough manpower for that
<seb128> infinity, those patches have been tested in a ppa and got feedback from quite some users for a week
<seb128> I'm running it as well
<infinity> seb128: Good to hear.
<seb128> infinity, thanks
<doko> infinity, https://launchpad.net/ubuntu/+source/ruby-rspec-core/2.14.5-1/+build/5142443 probably needs manual intervention. ruby-rspec was already built for the new version
<infinity> doko: Erk, annoying.  I'll sort that in the bootstrap repo or something clever.
<doko> thanks
<stgraber> infinity: someone just filed a bug about that pt_chown change against LXC when running some other distro. So I've spent the time to add all the needed tasks, SRU paperwork, ... bug 1242913 if you want to keep that on a list somewhere for when you do the eglibc security update
<ubot2> Launchpad bug 1242913 in lxc (Ubuntu Saucy) "/dev/pts being created with mode=600 by Lxc" [High,Triaged] https://launchpad.net/bugs/1242913
<infinity> stgraber: Well, at least I gave you warning. :)
<stgraber> infinity: yeah, most of the !ubuntu templates are kind of broken anyway so it's not extremely urgent for us to SRU the upstream fix just yet. It'll get done with our next round of SRU unless the eglibc update hits first (in which case we need it done right before or at the same time to avoid global breakage)
<infinity> stgraber: I intend to put a lot more thought into it before doing the glibc switch, but it will be in the next couple of months, I'm sure.
<infinity> doko: FWIW, that's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677955
<ubot2> Debian bug 677955 in ruby-rspec-mocks,ruby-rspec-expectations,ruby-rspec-core "Circular build dependency ruby-rspec-mocks <-> ruby-rspec-expectations <-> ruby-rspec-core" [Normal,Open]
<infinity> doko: I'll do the manual bootstrap here for now, but I sure hope I don't have to do this over and over again.
<infinity> Who accepted that walinuxwagent/precise?
<infinity> stgraber: When you're doing NEW processing, doing the correct overrides in the queue is nice too...
 * infinity fixes.
<stgraber> infinity: doh, thanks for fixing. I accepted using the API while doing other SRU reviews so didn't think of the overrides... (those SRUs for packages introduced post-release showing up in New are annoying...
<stgraber> )
<infinity> stgraber: Yeah, that's a bug, to be sure, but one we need to be aware of for now. :P
<infinity> doko: ruby bootstrap loop sorted.
<doko> afk now, fixed / did give back about 30 ftbfs today
#ubuntu-release 2013-10-22
<doko_> cjwatson, auctex b-d's on emacs23 | emacs24, and component-mismatches-proposed complains about it. does this really need a change?
<cjwatson> Maybe
<cjwatson> Where's auctex seeded?
<shadeslayer> could someone point me to the procedure on how to ask for a 13.10.1 for Kubuntu? There's a Critical bug in the UEFI boot that we would like to get fixed : 1242417
<shadeslayer> bug 1242417
<ubot2> Launchpad bug 1242417 in grub2 (Ubuntu) "UEFI install broken when GRUB_DISTRIBUTOR!=Ubuntu (e.g. Kubuntu/UbuntuStudio)" [High,In progress] https://launchpad.net/bugs/1242417
<cjwatson> shadeslayer: I'm not sure we have such a procedure
<cjwatson> shadeslayer: Also, I think the installer will fetch grub2 from the network if it can and if it's newer ...
<cjwatson> *think*
<shadeslayer> :D
<shadeslayer> my main concern is for machines without a network
<doko_> supported-development-desktop
<cjwatson> Send mail to ubuntu-release and I guess we'll see if we can figure something out
<shadeslayer> okay
<cjwatson> doko_: Which is odd because emacs24 is there explicitly, and that should be sufficient
<cjwatson> doko_: Let me look at the underlying germinate output ...
<shadeslayer> for machines with a network, most users will probably check "Apply updates when installing", so they should get the fix
<cjwatson> shadeslayer: That checkbox actually isn't relevant here
<cjwatson> It only applies to stuff in the livefs, which grub isn't
<shadeslayer> oh, didn't know that ....
<cjwatson> doko_: So, I think this is actually because auctex winds up in the expansion of the development seed
<cjwatson> Rather than the explicit seed entry in supported-development-desktop
<cjwatson> doko_: Choices are to seed emacs24 explicitly in ubuntu.trusty/development, or to modify auctex
<shadeslayer> cjwatson: btw, any news on the dev symlink that was talked about last UDS? :D
<cjwatson> doko_: Or to get to the point where we can remove emacs23, I suppose
<cjwatson> shadeslayer: It's in the archive, there are some bugs though
<shadeslayer> oh, like?
<cjwatson> (a) its target seems unreliable (it was pointing to quantal at one point yesterday, although it points to trusty now), (b) in the past it hasn't reliably existed for all pockets, (c) apt issues warnings when you try to use it, (d) I don't think the UI is in place yet
<cjwatson> I won't announce it until we've tidied at least some of that up
<cjwatson> It is *possible* to use it though, and you can upload to devel
<shadeslayer> sounds quite cool, can I make a chroot using devel?
<cjwatson> shadeslayer: don't see why not
<cjwatson> shadeslayer: it's just a symlink ... although debootstrap won't know about it
<cjwatson> shadeslayer: so you'd still need to arrange to call debootstrap with trusty
<shadeslayer> cjwatson: yup, created a devel symlink to gutsy
<ScottK> shadeslayer: I released the SRU for the updated debootstrap for p/q/r/s yesterday, you shouldn't need to make your own.
<shadeslayer> ScottK: we were talking about the devel release
<shadeslayer> not trusty
<ogra_> there is a difference ?
<Laney> 'devel'
<shadeslayer> ^^
<ogra_> and devel isnt trusty currently ?
<shadeslayer> it is, debootstrap just didn't have a script for it
<xnox> shadeslayer: "devel" is current alias for "trusty"
<cjwatson> He knows
<ogra_> oh, for debootstrapping a devel with the actual rolling name !
<xnox> bah.
 * ogra_ gets it now
 * xnox ditto
<cjwatson> I'm reluctant to change debootstrap for this because I like to keep it in sync with Debian, and "devel" is awfully generic for that
<cjwatson> (and debootstrap doesn't have an interface to select the distribution - it's all one big namespace)
<ogra_> linkspace rather :)
<cjwatson> I suspect adding a distribution option is the best long-term answer to this
<doko_> cjwatson, looking at giflib, Depends: libperl4-corelibs-perl | perl (<< 5.12.3-7), however we didn't complain before about the mismatch
<cjwatson> doko: Looking
<shadeslayer> cjwatson: I was looking at http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/trusty/grub2/trusty/revision/2359 and it seems like util/grub-install.in has the change applied directly as well?
<cjwatson> shadeslayer: yes
<shadeslayer> intended?
<cjwatson> shadeslayer: yes
<shadeslayer> uh okay
<cjwatson> shadeslayer: that branch is patches-applied
<shadeslayer> I see
<cjwatson> shadeslayer: so that for example I can "bzr blame" across both upstream and patches at once
<doko> o libapache2-mod-auth-pgsql: libapache2-mod-auth-pgsql
<doko>    [Reverse-Depends: Ubuntu.Trusty server-ship seed]
<cjwatson> shadeslayer: this is useful to me
<doko> this probably should just be removed from the seed
<shadeslayer> ack
<cjwatson> doko: it was in main in raring; removed for apache 2.4 transition, now fixed in Debian and reintroduced
<cjwatson> doko: I'd be inclined to keep it and re-promote since it was there before
<doko> libperl4-corelibs-perl?
<cjwatson> doko: libapache2-mod-auth-pgsql
<cjwatson> doko: I'm still investigating what happened with libperl4-corelibs-perl
<cjwatson> (I'm about to go out for a bit, it may have to wait)
<shadeslayer> cjwatson: if I upload grub2 with your fix to saucy, would you approve it once you get back?
<doko> cjwatson, see https://bugs.launchpad.net/ubuntu/+source/emacs23-non-dfsg/+bug/1243207 for the emacs23 removal
<ubot2> Launchpad bug 1243207 in emacs23-non-dfsg (Ubuntu Trusty) "remove emacs23 during the trusty cycle" [Undecided,New]
<cjwatson> shadeslayer: Given it's my code, you should get somebody else to do it
<cjwatson> doko: thanks
<shadeslayer> okay
<cjwatson> I mean, I think it's SRU-suitable, certainly, but there should be a different reviewer
<doko> cjwatson, what is the bitsize tag?
<cjwatson> bitesize, you mean?
<doko> yes!
<cjwatson> It usually means that it should be an easy and small thing for a new contributor to tackle
<doko> sure, fixing dependencies and b-d's?
<cjwatson> I guess
<cjwatson> Probably ought to involve checking that the packages actually work with emacs24 too?
<cjwatson> doko: libperl4-corelibs-perl is because perl-modules provided libperl4-corelibs-perl in saucy, but it no longer does as of perl 5.16
<doko> cjwatson, ahh, so we can promote it because the code was already in main
<cjwatson> doko: Yep
<doko> cjwatson, are you ok with https://bugs.launchpad.net/ubuntu/+source/libtest-most-perl/+bug/1243176 and https://bugs.launchpad.net/ubuntu/+source/libcapture-tiny-perl/+bug/1243172 ?
<ubot2> Launchpad bug 1243176 in libtest-most-perl (Ubuntu) "[MIR] libtest-most-perl (b-d of libconvert-binhex-perl)" [Undecided,New]
<ubot2> Launchpad bug 1243172 in libparse-recdescent-perl (Ubuntu) "[MIR] b-d's for libtest-fatal-perl" [Undecided,New]
<cjwatson> doko: those sound harmless
<doko> and the last perlish one is https://bugs.launchpad.net/ubuntu/+source/libunicode-linebreak-perl/+bug/1243178
<ubot2> Launchpad bug 1243178 in sombok (Ubuntu) "[MIR] b-d's for po4a (to run the tests)" [Undecided,New]
<cjwatson> I expect the lib*-perl ones are pretty harmless; sombok might want a look
<cjwatson> (it's probably fine though)
<Laney> cjwatson: ^ is the one you pinged me about yesterday
<Laney> should be able to remove the old source once that's in
<doko> Laney, I don't mind if you do want to coordinate that with Debian
<Laney> Well, you're already putting the effort in ;-)
<doko> cjwatson, last one for the perl recommends is: https://bugs.launchpad.net/ubuntu/+source/libtext-soundex-perl/+bug/1243180
<ubot2> Launchpad bug 1243180 in libtext-soundex-perl (Ubuntu) "[MIR] new recommends for perl 5.18" [Undecided,New]
<cjwatson> doko: fine by me
<cjwatson> (not that I have any say)
<doko> INFO Upload was rejected:
<doko> INFO 	libguava-java_15.0-2_all.deb: has 2 file(s) with a time stamp too far in the past (e.g. usr/share/doc/libguava-java/README [Sun Dec 30 23:00:00 1979]).
<doko> INFO 	libguava-java-doc_15.0-2_all.deb: has 2 file(s) with a time stamp too far in the past (e.g. usr/share/doc/libguava-java-doc/AUTHORS [Sun Dec 30 23:00:00 1979]).
<doko> re-upload?
<cjwatson> doko: Will probably need a debian/rules change to fix the timestamps
<cjwatson> I expect it worked in Debian because it's arch all and the maintainer had newer timestamps locally
<cjwatson> but those aren't recorded in the source ... IMO this is at least an important bug in the Debian package
<doko> Laney, mono, "please take" ?
<Laney> what?
<doko> the comment on mom ...
<Laney> oh, let me see
<Laney> was that me?
<Laney> changed :-)
<doko> Laney, but planned for trusty?
<Laney> should be, but directhex will take care of it ideally
<Laney> still stabilising it
<doko> cjwatson, infinity: esys-particle now builds for 18h, the last version did need 6h on x86 ...
<infinity> doko: Took 17h on amd64 this time, so I assume i386 will finish up soon.
<infinity> doko: Clearly need to move all that junk to an arch_all package.  And maybe pre-optimise the PNGs in the source and turn off PNG mangling at build time.
<infinity> But not deeply concerned about doing that today.  I scored it down to -1 on powerpc and arm64, so it won't be harming the queues there for now.
<xnox> Hm, there is no xubuntu trusty daily yet.
<xnox> Has it not been cronned back on yet, or failing?
<infinity> None of them have been cronned back on yet.
<infinity> stgraber: Does any magic need to happen to the tracker before we uncron trusty dailies and watch the world burn?
<stgraber> yeah, I need to create the series and copy all the test cases, I'll do that after lunch
<infinity> alternates and server will be broken until your d-i build filters through anyway.  So, I'll uncron a bit later.
<cjwatson> And until d-i is updated to trusty
<stgraber> cjwatson: that's what my upload was about
<cjwatson> stgraber: I was still working on choose-mirror, at least
<cjwatson> stgraber: And cdrom-detect and iso-scan haven't been done either - those are on my list
<stgraber> oh yeah, I just did d-i itself...
<stgraber> so yeah we need a bit more than just d-i indeed
<cjwatson> I'll get them done today or tomorrow
<doko> please give back libunicode-linebreak-perl once the fixed sombok is published (afk now)
<infinity> cjwatson: I'm thinking we might want to remove arm64 from slow_arches soon.  We'll hit a point where it's doing more harm than good to let it skew.
<cjwatson> Yeah, I was thinking of doing that towards the end of the week
<infinity> Andy's doing up some HOWTO instructions and polishing off a script to make ubuntu-core plus the 3.12 kernel from their PPA into bootable images for the Foundation Model, so we may even have a plausible thing to point people to to investigate their arm64 issues.
<cjwatson> Oh excellent
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/already-installed/+merge/192225
<slangasek> bdmurray: would it be better to fix that at the source, and have errors not bucket them against packages in the first place?
<slangasek> also, the logging changes look unrelated to me
<bdmurray> slangasek: it'd be best to fix the apt bug that is causing the install failures and I'm looking into that.  I'd say this is a temporary measure.  The logging changes are unrelated but I thought they'd help.
<slangasek> ok; fwiw this kind of problem has been present in apt in one form or another for quite a while, so I'm not confident that we'll manage to quickly fix all the occurrences
<slangasek> I thought fixing the bucketing might be a good intermediate fix instead
<bdmurray> okay, I'll think about how these are bucketed then too.
#ubuntu-release 2013-10-23
<sil2100> Hi everyone! Still need someone from the SRU team to take a look at a fix that we'd like to SRU for raring: https://bugs.launchpad.net/unity/+bug/1043627
<ubot2> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
<sil2100> It seems to be somewhat important
<xnox> Can I ask for PowerPC builds be rescored of packages listed in Levels 1-3, excluding (boost-mpi-source1.53, ogre, ogre-1.8) for the boost1.54 transition http://people.canonical.com/~ubuntu-archive/transitions/boost1.54.html ?
<cjwatson> xnox: doing
<xnox> thanks.
<cjwatson> xnox: frogatto librcsb-core-wrapper mkvtoolnix pentobi rdkit btag enblend-enfuse gringo lightspark mira source-highlight vera++ laserboy -> 4000
<xnox> cjwatson: thanks, all good.
<psivaa> cjwatson: infinity: could i know when trusty server images will start appearing in cdimages?
<cjwatson> was planning to poke at that tomorrow; so tomorrow or Friday
<cjwatson> I uploaded the d-i components today that need to be touched for the new release name
<psivaa> cjwatson: ack, thanks
<mitya57> Hi, I continue getting pinged about bug 943195 â can somebody accept the SRU please?
<ubot2> Launchpad bug 943195 in xpdf (Ubuntu Raring) "xpdf.real crashed with SIGSEGV in GooHash::hash()" [High,Triaged] https://launchpad.net/bugs/943195
<mitya57> (It's a bug affecting 116 people with ugly but working fix)
<jdstrand> cjwatson: hey-- you asked me to upload apparmor for perl 5.18, so I did, but it seems to be blocked by perl now
<cjwatson> jdstrand: Yes, that's expected
<cjwatson> jdstrand: Should be done with that transition in a day or two
<jdstrand> cjwatson: ok, cool, thanks
<cjwatson> If you desperately need to upload something you can stack it on top as long as you're sure it isn't going to fail to build somewhere, or you can wait
<jdstrand> cjwatson: no, we aren't blocked-- I just noticed it and thought I;d ask
<cjwatson> jdstrand: If you want to speed it along you could help figure out any of the libdr-tarantool, gdal, or libmongodb-perl build failures :)
<roaksoax> howdy! i uploaded maas to saucy-proposed a few days ago (beforr trusty was open). can someone please accept it into -propsed for sru verification and copy it into trusty?
<infinity> roaksoax: I'll look at it after I get the last of this perl transition licked.
<roaksoax> infinity: perfect! thank you!
<infinity> cjwatson: FWIW, I'm fixing the gdal FTBFS, if you were planning on that.
<infinity> cjwatson: I think stgraber is looking at libdr-tarantool-perl, though possibly with some confusion.
<seb128> is anyone planning to let some of the saucy SRUs in this week?
<infinity> cjwatson: So, that leaves ibmongodb-perl
<seb128> or should I consider direct pings to get mines in? ;-)
<infinity> l*
<cjwatson> infinity: Oh, good, I'd got part-way into the gdal FTBFS but was interrupted by dinner.  Be m yguest.
<infinity> seb128: I'm going to look at the SRU queues once this perl transition looks to be under control.  Don't want to keep trusty-proposed in this state too long.
<stgraber> infinity: I'm fighting with airlines at the moment but will get back to figuring out why the test segfaults after that
<seb128> infinity, bdmurray: do you plan do SRUs this week or next ? ;-)
<infinity> seb128: Red 8 minutes back in backscroll.
<seb128> infinity: sorry, missed that ... thanks ;-)
 * seb128 blames that web client (behind a connection blocking IRC ports atm)
<infinity> seb128: Ew.
<slangasek> infinity: how much longer do you think it's going to take to get perl through?  The maas SRU is AIUI a time-sensitive one, so maybe I should look at it
<infinity> slangasek: Oh, if it's time-sensitive (the maas one?), I can look.  I already had a bit of context.
<stgraber> slangasek: down to 3 packages
<infinity> My gdal FTBFS fix worked, and then failed on the next g++ call, so I clearly have a bit of work to do there. :P
<brainwash> bdmurray: hey, any news on bug 1232363 ?
<ubot2> Launchpad bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Medium,Triaged] https://launchpad.net/bugs/1232363
<slangasek> infinity: oh, actually, maas was not mentioned as one of the packages affected by what I'm thinking of
<slangasek> infinity: so don't let it disrupt your flow
<slangasek> I was thinking of walinuxagent+cloud-init, which I think was just precise and already done
<infinity> Ahh.
<stgraber> yeah, I dealt with the cloud-init + walinuxagent uploads (so far precise + raring I believe)
<slangasek> smoser: is there still a quantal SRU coming of cloud-init + walinuxagent?
<bdmurray> brainwash: I'm working on it
<brainwash> bdmurray: thanks, still curious if my patch works, well it's no magic anyway, copy and paste mostly :)
<cjwatson> Wonder if I can figure out libmongodb-perl
<cjwatson> Not my field, to put it mildly, but
<cjwatson> Ha.  https://github.com/mongodb/mongo-perl-driver/commit/dc4db9bf3807627828859bb630ff4e852d8d261b
<slangasek> destroy all software... or at least its tests
<cjwatson> IOW "the javascript engine reports errors in too many random ways so let's give up for the moment"
<cjwatson> works for me for now ...
<infinity> cjwatson: Oh dear.
<infinity> TMTOWTDI, I guess.
<infinity> Though, that seems the wrong way. :P
<cjwatson> It does, but I'll go with upstream terribleness over home-grown terribleness for software I don't know
 * infinity nods.
<infinity> gdal seems licked, just waiting for it's enormously slow test build to finish.
<infinity> its...
<infinity> Damn you, internet.
<infinity> Phew.  gdal fixed.
<infinity> So, that just leaves us whatever-tarantool-thingee.
<infinity> And any arch lag...
<infinity> I think I caught all the lagging PPC perl builds, but I'll do another sweep.
<cjwatson> Also poking proposed-migration/autopkgtest until it stops being confused about a few things
<cjwatson> infinity: Anything that was lagging and that mattered would show up in the transition tracker, I expect
<infinity> cjwatson: There were plenty of PPC builds showing as blanks in the tracker, I think I got them all.
<cjwatson> Blanks don't matter for migration
<infinity> They should, since you can't migrate with half-built sources.
<cjwatson> If it's a blank then it probably wasn't built before ...
<cjwatson> If it was built before I'd expect an x, since it would've been against perlapi-5.14.blah
<infinity> Oh, I guess outdate doesn't matter for new sources?
 * infinity shrugs.
<cjwatson> It's not outdate if it hasn't been built :)
<infinity> Anyhow, I picked them all off anyway.
<infinity> I think.
<cjwatson> I have about three different views of this.  Going round and checking them all.
<infinity> I'll stop fixing arm64 perl FTBFSes for a few cycles, so we can let the dust settle without me revving source versions again.
<infinity> ... and score that gdal through the roof so it happens this century.
<cjwatson> I already scored it high enough
<infinity> Oh, it's already building.  Yay.
<infinity> Heh.
 * cjwatson reruns the sbuild autopkgtest now that schroot is in sync
<infinity> It disturbs me that I knew more about GCC floating point options in April than I do in November.
<cjwatson> samba4 similarly
<infinity> My fixes to teem seem entirely like voodoo to me now.
<infinity> s/November/October/
<stgraber> cjwatson: ah, I just finished running the samba4 one locally and pushed an hint to ignore the failure, but a re-run works too :)
<cjwatson> I prefer making them pass than overriding them
<infinity> stgraber: Any hope on the tarantool segv thing?
<stgraber> cjwatson: how can I trigger a re-run?
<cjwatson> stgraber: you need an account on the private jenkins, then there's a "build now" operation at the top level of a test
<stgraber> infinity: poking at this slowly (while on hold, still fighting with airlines...)
<cjwatson> There we go, samba4 and sbuild autopkgtests back to green.  I wonder if p-m will notice
<stgraber> cjwatson: who do I poke to get one of those accounts?
<cjwatson> stgraber: I think I poked jibel
<stgraber> ok
<smoser> slangasek, quantal is difficult...
 * cjwatson sighs and goes to kick auto-package-testing inna head
<smoser> and not terribly high priority to anyone
<smoser> other than to the upgrade path from p -> q
<stgraber> infinity: I'm done being a travel agency and back to poking at that tarantool thing
<cjwatson> hm, it's running, maybe I'll leave it
<cjwatson> ah, looks like it picked up the rerun, good
<cjwatson> grr, and of course the perl transition gets britney into one of its unhappy "I'm going to take ages because when I try individual packages the world becomes uninstallable" moods
<cjwatson> (which was why I blocked it when it was hopelessly incomplete)
<cjwatson> "AIEEE: counter overflow"  yes yes I know
<infinity> Heh.
<slangasek> smoser: ok; no skin off my nose if q isn't a priority for you
<smoser> slangasek, ok. thank you. the backport is harder there.
 * slangasek puts some paper towels down on the counter
<roaksoax> q/win 13
<stgraber> cjwatson: infinity suggested you may be faster at solving the libdr-tarantool-perl failure than us ;)
<stgraber> cjwatson: http://paste.ubuntu.com/6291627/ is the stacktrace
<stgraber> cjwatson: the function that's failing didn't change between saucy and trusty but the rest of the code changed quite a bit
<infinity> I'm fine with demoting or reverting that, if it ends up being our only blocker, but fixed would be nicer if the bug jumps out at anyone.
<stgraber> cjwatson: and the fun being that this only fails on i386, amd64 works fine
<cjwatson> I used to be an XS expert but it's been a while
<stgraber> infinity: I'm testing a rebuild of saucy's version on trusty now to confirm that's an option
<cjwatson> Let me grab some coffee and take a look
<stgraber> infinity: not an option, segfaults too
<infinity> Oh, lawlz.
<infinity> So maybe it's in something it links to?
<cjwatson> Looks to me like a changed packet format or something
<cjwatson> But I'll see if I can just debug it directly ...
<infinity> Though, no.  Not link, per se.
<stgraber> (saucy-i386-sbuild)root@castiana:~/libdr-tarantool-perl-0.42# ldd ./blib/arch/auto/DR/Tarantool/Tarantool.so
<stgraber> 	linux-gate.so.1 =>  (0xf7788000)
<stgraber> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000)
<stgraber> 	/lib/ld-linux.so.2 (0xf7789000)
<infinity> stgraber: Yeah, more likely sometihng it's calling out to (ie: tarantool)
<infinity> Not that tarantool is segfaulting but, as Colin says, maybe some format has changed.
 * cjwatson also eyes an earlier fix https://github.com/dr-co/dr-tarantool/commit/dc33e60713dfd996dcef936b26e6ce5acc67c855 to nearby code
<stgraber> FWIW I confirmed the crash on saucy happens on the exact same line of the tp_next function
<cjwatson> Also FWIW the counts seem random
<stgraber> build works when downgrading tarantool to saucy's version
<cjwatson> https://launchpadlibrarian.net/154728856/buildlog_ubuntu-trusty-i386.libdr-tarantool-perl_0.42-1_FAILEDTOBUILD.txt.gz got through two rounds of the loop before failing; my local build got through 14
<cjwatson> 1, 13, 16 ... definitely racy
<stgraber> hmm, looks like I was lucky, even with saucy's version I can get it to segfault
<cjwatson> So something like an adapted version of that earlier commit seems like a decent potential candidate
<infinity> Oh, if this is racy, I can give it back 37 times. :P
<cjwatson> And indeed it does sometimes succeed
<cjwatson> Nah, would rather attempt a fix
<infinity> Yeah, that was sarcasm.
 * infinity goes back to seeing if birch is salvageable.
<cjwatson> my $body = join '', map { chr int rand 256 } 1 .. (300 + int rand 300);
<cjwatson> wonder if it depends on the length of that
<cjwatson> ... not obviously
<infinity> cjwatson: When we thing the perl transition is ready, we might want to pause the publisher, so that massive block of copies and deletes from britney happens atomically.
<infinity> s/thing/think/
<cjwatson> I was thinking that too
<cjwatson> There's still a fair amount of stuff in output
<cjwatson> It might be over-autohinting, or more likely it's stuff that doesn't show up in the tracker :-/
<cjwatson> Or could be under-autohinting.  gammaray's installable in trusty-proposed-amd64.
<cjwatson> Ah, graphviz mini-transition too
 * cjwatson crafts another tracker
<cjwatson> Also libbuffy-bindings FTBFS; not sure why that didn't show up on the tracker, since it was there at one point
<cjwatson> Sigh, this is going to be painful - we should've done the new graphviz after the perl transition was done
<cjwatson> I didn't realise it was going to involve sourceful changes to dependent packages of its own
<cjwatson> Though at least not all of them ...
<cjwatson> This mess absolutely vindicates the decision to defer the new graphviz from saucy to trusty, though
<stgraber> 2/9 worked with a rebuild, we've seen better, thankfully there aren't that many of those
<infinity> poppler can be much worse, when it happens.
<infinity> Thankfully, though they break ABI every eight days, they seem to only violently break API once a year or so. :P
<doko> cjwatson, sorry, forgot about the graphviz one
<cjwatson> Hmm.  Maybe this is just me not understanding something, but the reply from tarantool in the segfaulting case looks like total nonsense
<cjwatson> Sensible-ish header but then the tuple lengths are off in la-la land
<stgraber> cjwatson: there'll apparently be a new Debian upload of tarantool real soon (changelog entry was pushed to git 14 hours ago), I wonder if this may help
<cjwatson> Oh, actually it's not tarantool at all
<cjwatson> The packet I'm looking at is entirely generated by the test code
<cjwatson> So it is utterly dumb luck whether it happens to cause it to overflow into space
<cjwatson> Not too sure why it ever worked, though it clearly does sometimes and I can't be bothered to sort out why.
<stgraber> so are you close to figuring it out how to fix the test or should we just turn that one off (or click rebuild a couple of times and see it magically pass)?
<cjwatson> I'm close
<cjwatson> But there's no rush now since we have at least graphviz to do before perl can land
<infinity> The number of times I've run into people actually attempting to update config.{sub,guess} but landing it in the wrong directory is quite funny.
<wgrant> Also lots of people use autoreconf to do it
<wgrant> But then their setup is sufficiently strange, or they just don't use automake, so it doesn't actually work.
<infinity> I'm pretty much madly in love with dh_autotools_dev's spray of bullets approach to the problem.
<infinity> Seems to DTRT every time, so far.
<wgrant> Yep
<infinity> Finished 1 minute ago (took 13 minutes, 47.2 seconds)
<infinity> Finished 1 minute ago (took 13 minutes, 46.6 seconds)
<infinity> birch and sulfur fight to the death at the finish line...
<infinity> I obviously need some breakfast if I'm sitting here comparing build times.
<xnox> Can I ask for PowerPC builds be rescored to 4000 of packages listed in Levels 6 which did succeed on "adm64 i386 armhf" at http://people.canonical.com/~ubuntu-archive/transitions/boost1.54.html ?
#ubuntu-release 2013-10-24
<xnox> to speed up boost transition, i know it says on launchpad that all powerpc queue will be drained in 26h, but I somehow doubt that a little =)
<xnox> infinity: cjwatson: ^
<xnox> if not, please upscore just this one build to 4001 on powerpc https://launchpad.net/ubuntu/+source/kdepim/4:4.11.2-0ubuntu2/+build/5152973 it should result in boost-default migrating into release pocket, i think.
<infinity> xnox: I can do kdepim right now.
<infinity> xnox: The 26h probably isn't a lie, I'm not sure why you'd think so.
<xnox> infinity: given new uploads today/tomorrow daytime to main/unity-landing-ppa/kernel-ppa/etc, will result in those mostly universe packages not be build in 26h window.
<xnox> infinity: but i guess we'll see that on friday 2:00am UTC ;-)
<infinity> xnox: Kernels are all done for this SRU cycle.
<xnox> ah, cool =)
<infinity> (Well, for powerpc anyway)
<infinity> Not counting the two I need to rebase and upload, but I'm in control of that. :P
<cjwatson> stgraber: http://paste.ubuntu.com/6292147/ survives more than 1000 test runs; I think it's good.  But I'll upload that in the morning after a more-awake re-review.
<cjwatson> Right now I need to go to bed before any of that nonsense accidentally seeps into long-term memory.
<infinity> Whiskey.
<infinity> You need whiskey.
<cjwatson> Often true but I think not right now :-)
<infinity> xnox: I'll nudge a few more of your builds along here and there tonight.
<xnox> infinity: ta, and I'm off to sleep.
<xnox> cjwatson: infinity: i was thinking about whiskey too, would go down best neat for my  swollen leg agony, crutches, and x-rays of "nothing broken"......
<infinity> xnox: Amputation could work too.
<xnox> infinity: i don't think upscoring pain higher up the body fixes the problem of having pain =)))))))
<infinity> xnox: I dunno, you'd forget all about the leg if you didn't have it, right?
<apw> the pain is being perceived by the head, i recon there is a clear solution
<StevenK> apw: IE, 'amputation' again?
<stgraber> right, infinity never said what body part ;)
<apw> ahh point indeed
<doko> cjwatson, infinity: do you know what's happening with the acl2 builds on i386 and amd64?
<cjwatson> acl2 normally takes forever, doesn't it?
<cjwatson> ah, though that might be buildd-manager again
<cjwatson> I'll check the logs in a minute
<cjwatson> doko: Doesn't seem to be buildd-manager.  I'll investigate when a webops vanguard is around; shouldn't be desperately urgent given current queues
<doko> sure
<xnox> Maybe kdepim needs a hint to go in together with boost-defaults? together they are installable.
<Laney> Maybe so, adding
<xnox> cheers.
<xnox> worked! \o/
<Laney> w00t
<xnox> muaha =) i'll be setting priority=high on my transition rebuilds =) just enough to nudge universe uploads above DebianImport universe.
<cjwatson> Not a terrible idea
<seb128> infinity, hey, I guess you didn't get to the saucy SRUs yesterday but that's still on your todolist for this week? ;-)
<arges> Can somebody reject the SRUs for iproute in PQR? i've marked the bug verification-failed, just wanted to make sure they don't go any further
<doko> cjwatson, stgraber: https://bugs.launchpad.net/ubuntu/+source/massif-visualizer/+bug/1244261
<ubot2> Launchpad bug 1244261 in massif-visualizer (Ubuntu) "kgraphviewer needs porting from libgraph to libcgraph (remove binaries for now)" [Undecided,New]
<doko> https://bugs.launchpad.net/ubuntu/+source/rggobi/+bug/1244263
<ubot2> Launchpad bug 1244263 in rggobi (Ubuntu) "ggobi needs porting from libgraph to libcgraph (remove binaries for now)" [Undecided,New]
<cjwatson> doko: I think I'll demote kgraphviewer/massif-visualizer too
<cjwatson> Doesn't look like an obvious port
<doko> ScottK, ^^^ you did touch it last, package is not in Debian
<roaksoax> 4/win 17
<Laney> oops
<Laney> I'll fix that c-m explosion
<xnox> Laney: hm?
<infinity> doko: Oh, there's a 'tail -f' that's left stale/hanging at the end of acl2's build.
<doko>        while sleep 1800; do echo Tick; done & k=$$! ; tail -f debian/test.log & l=$! ; \
<doko>         wait $$j ; kill $$k $$l
<doko>         [ -f $@ ] && ! fgrep '**' $@ || echo FULL TEST FAILS
<doko>         for i in $$(find books -name "*.out"); do \
<doko>                 if ! [ -e $${i%out}cert ] ; then \
<doko>                         echo $$i ; \
<doko>                         cat $$i ; \
<doko>                 fi ; \
<doko>         done
<doko> infinity, dpkg or something else should get some support to follow log files which don't print on stdout/stderr ...
<doko> cjwatson, perl migrating?
<cjwatson> nearly; need to get massif-visualizer built in -proposed, remove it from release, demote kgraphviewer
<cjwatson> oh look, maybe it worked anyway
<cjwatson> maybe it traded something off
<cjwatson> Well, so much for the plan of stopping the publisher first
<cjwatson> Maybe I still can
<xnox> cjwatson: hm, as long as it doesn't go across mirror-pulses.....
<cjwatson> start: 176+0: i-68:a-3:a-2:p-6:a-97
<cjwatson> orig: 176+0: i-68:a-3:a-2:p-6:a-97
<cjwatson> easy: 127+0: i-19:a-3:a-2:p-6:a-97
<cjwatson>     * i386: claws-mail-extra-plugins, claws-mail-perl-filter, libgv-perl
<cjwatson>     * amd64: claws-mail-perl-filter, libgv-perl
<cjwatson>     * armhf: claws-mail-perl-filter, libgv-perl
<cjwatson>     * powerpc: claws-mail-perl-filter, libgv-perl
<cjwatson>     * arm64: libgv-perl
<cjwatson> xnox: I think I got the publisher in time
<xnox>  \o/
<cjwatson> I don't know why that thought there were 68 uninstallables in release
<xnox> cjwatson: i think claws was uninstallable even from before you started.
<cjwatson> by definition the ones listed above are new packages
<cjwatson> I mean, new uninstallables
<xnox> ok =/
<cjwatson> however don't worry too much about claws, because there are special cases for it in britney because of claws-mail-extra-plugins being merged into claws-mail
<cjwatson> I might just have got the special cases a bit wrong
<cjwatson> I really don't know what those 68 uninst on i386 were, though.  I guess we'll find out shortly
 * infinity notes that http://people.canonical.com/~ubuntu-archive/testing/trusty_probs.html doesn't exist yet...
<cjwatson> That wouldn't really tell you in this case, though trusty_uninst will after this run finishes
<cjwatson> Though, yes, I should set that up
<infinity> The important thing is that I finally get a new vim.
<cjwatson> We might all get exciting upgrade failures if we're unlucky
<infinity> :/
 * cjwatson preemptively removes libscalar-list-utils-perl
<xnox> stgraber: did you say you were going to open http://iso.qa.ubuntu.com/ for trusty ?
<xnox> or are you waiting for images to be uncronned?
<xnox> un-uncronned that is.
<cjwatson> oh, blast, I caused the early migration by removing libmath-bigint-perl, I think
<cjwatson> a bunch of stuff was that (>= version) | perl (>= 5.15.x) or similar
<cjwatson> oh well, it's done now and pretty close
<cjwatson> publisher re-enabled
<stgraber> xnox: I did say that but haven't got to it yet, will do it after lunch
<cjwatson> It's just possible that this publisher run might take a while
<infinity> Yeah, the publisher doesn't cope well with having a ton of files to put to disk (or to check for content).
<infinity> I note this every time I do kernel SRUs.
<infinity> Uhm...
<infinity> All my stuff is getting copied to trusty *again*?
<infinity> cjwatson: Is britney running in the middle of this publisher run and being very confused?
<cjwatson> Possibly.  It should have no effect
<cjwatson> But I've killed it anyway
<infinity> I wish I had your optimism. :)
<cjwatson> It probably ran again because the previous proposed-migration run coincided with a publisher run
<cjwatson> So the archive was modified and it re-ran
<cjwatson> Oh, I did .../testing/ for you BTW
<cjwatson> And the ports version has arm64
<stgraber> xnox: trusty added to the tracker with a copy of the testsuites and manifest from saucy
<xnox> stgraber: thanks a lot =)
<infinity> I guess I can uncron soon, then.  A bit scared of all the images failing, but no time like the present to find that out...
<infinity> cjwatson: Gah.  trusty_uninst looks bad. :/
<infinity> Do we know what went wrong there?
<ogra_> stgraber, is there anything wrong with import-images ? the touch build i did finished at :23 and i still seee no trace of a system-image
 * ogra_ wonders if he is to impatient ... but it rarely takes more than 5min usually 
<stgraber> ogra_: it's running
<ogra_> ah, great
<ogra_> so its just me :P
<seb128> Daviey: isn't "including the change of an inflight sru" the way to supersed the said SRU?
<Daviey> seb128: Is that the intent?  The current one has been in nearly a week, and i can't see that it has failed verification ?
<seb128> Daviey: well, I wanted to add more fixed, and I didn't notice there was a SRU inflight because bdmurray didn't commit that to the vcs
<seb128> Daviey: that's ok, I can fix the vcs, rebase, redo an upload
<seb128> fixed->fixes
<infinity> I'm okay with accepting it as-is, if you want to re-verify those bits quickly.
<Daviey> seb128: Can resurrect it, but I noticed it whilst reviewing and seemed safer to reject ut incase it was accepted by mistake
<seb128> infinity: Daviey: don't worry, I'm going to redo another upload on top of the current one, easier
 * infinity shrugs.
<xnox> cjwatson: infinity: is britney/publisher back running normally? or is
<slangasek> I think I saw him say he was restoring it.  What's stuck for you?
<xnox> something wrong with initramfs-tools-ubuntu-touch package.... it's in trusty-proposed for an hour now, and in none of britney's reports. Unless i'm being impatient.
<xnox> slangasek: lxc-android-config as well.
<slangasek> ok, let's have a look
<stgraber> last britney run was 3 hours ago apparently
<slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html generated: 15:19
<slangasek> did perl get in?
 * stgraber sshes into snakefruit
<slangasek> already there
<xnox> slangasek: perl did go in, upgrading my machine from uk mirror to the new perl already.
<slangasek> ok, so I suspect we've just forgotten to turn something back on
<stgraber> looks like it to me, not seeing anything actively running on snakefruit
<slangasek> p-m runs from archive-reports, right?
<stgraber> it does, yes
<stgraber> fixed
<stgraber> ubuntu-archive@snakefruit:~$ rm proposed-migration/STOP
<stgraber> ubuntu-archive@snakefruit:~$
<stgraber> next archive-reports run should trigger proposed-migration again
<xnox> cool, thanks.
<stgraber> slangasek: ^ (in case you're still digging)
 * xnox off to find dinner & tea, and then i'll upload the rest of the stuff later once everything is published.
<slangasek> stgraber: ok, cheers :)
<cjwatson> infinity: Yeah, what went wrong was that I removed libmath-bigint-perl too early
<cjwatson> stgraber,slangasek: thanks for re-enabling that - sorry, I should have left a note here to explain what I'd done
<infinity> cjwatson: Yeah, I saw that mention, I'm just wondering how that led to a ton of uninsts...
<cjwatson> there were a respectable number of rdeps
<cjwatson> the ones I checked manually all traced back to that
<infinity> Ahh, oops.
 * infinity uploads a fixed libept.
<infinity> Or, will, once incoming learns about it...
<slangasek> hmm, why is lp:ubuntu/initramfs-tools unbranchable?
<slangasek> bzr: ERROR: Revision {package-import@ubuntu.com-20121122094309-0ovxt4hcu1alzkpm} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<infinity> slangasek: probably because it's a package maintained by me.
<infinity> slangasek: And, thus, I've never noticed or cared. :)
<infinity> slangasek: (I'm going to be doing a bi-directional ubuntu<->debian merge in the next week or less, was there something specific you wanted mangled?)
<slangasek> infinity: maintained by you> lies; there've been 6 other Ubuntu uploads since your last one
<infinity> slangasek: Well, I use the term "maintained" loosely there, but the bit about the planned merge stands. :)
<infinity> It'll be more maintained once I fix up our delta.
<slangasek> infinity: I'm fixing bug #229732 and bug #1238194; dunno if these are fixed in Debian, but it'll be a small delta and you should have no trouble figuring it out from there
<ubot2> Launchpad bug 229732 in initramfs-tools (Ubuntu) "USB Keyboard drivers not loaded in initramfs" [Low,Triaged] https://launchpad.net/bugs/229732
<ubot2> Launchpad bug 229732 in initramfs-tools (Ubuntu) "duplicate for #1238194 USB Keyboard drivers not loaded in initramfs" [Low,Triaged] https://launchpad.net/bugs/229732
<infinity> slangasek: Oh, more missing drivers in newer kernels?
<slangasek> yeah, so far just one AFAIK (ohci-pci)
<infinity> slangasek: Kay, cool.  If you fix that, care to SRU it to precise?  Keeping that module list in sync for lts-backport kernels sucks.
<brainwash> just curious, are about this initramfs bug report, are all the saucy reports really duplicates of this ancient report from 2008?
<slangasek> infinity: yeah, I can probably manage that
<slangasek> brainwash: no, there are at least two separate issues here
<brainwash> really made we wonder, why someone marked the new saucy reports as duplicate of this old one
<infinity> The two issues I usually run into are (a) a driver legitimately missing from the list, or (b) people using modules=dep instead of modules=most, and dep ain't too smart about sorting out what you (might) need for your keyboard to work.
<slangasek> brainwash: overaggressive bug duping on someone's part
<brainwash> slangasek: thanks for clarifying :)
<infinity> roaksoax: Can you re-do that with '-v1.4+bzr1693+dfsg-0ubuntu2'?
<roaksoax> infinity: sure!
<roaksoax> infinity: re-uploaded it! thanks!
<bdmurray> I don't like how Launchpad says OK after you reject something
<infinity> bdmurray: Always makes you wonder if you pressed the wrong button, doesn't it?
<bdmurray> infinity: yep
<xnox> infinity: libept \o/ yeah
<infinity> xnox: Had to do some tag-teaming with enrico to make it happy, but got there in the end.
<slangasek> infinity: so you accepted gnome-settings-daemon into saucy-proposed over the version that was already verified there?
<xnox> ... as per seb128 request in #ubuntu-devel
<slangasek> ah, ko
<slangasek> ok
<xnox> slangasek: you were in that conversation, unless somebody is spoofing your nick =))))
<slangasek> was not
<slangasek> I was in the one about software-properties :)
<xnox> slangasek: ah, i see now =)
<xnox> my bad, sorry.
<infinity> slangasek: What he said.
<xnox> slangasek: infinity: can you please hint boost1.54 past mongodb auto-package-test, since it looks to me like it has actually PASSED.
<xnox> also can libreoffice be hinted past it's own adt failure? it doesn't seem like it has ever passed.
<cjwatson> xnox: mongodb shouldn't be hinted, I should poke things to notice the pass
<cjwatson> xnox: I'll update my libreoffice hint
<xnox> cjwatson: ta for both.
<cjwatson> hopefully will notice now
<slangasek> cjwatson: so, what did you poke for mongodb and should I know how to do that?
<infinity> We all should know how to do it, but it requires VPN and a jenkins account.
<infinity> Which is suboptimal.
<cjwatson> Not true in this case
<infinity> No?
<infinity> Oh, this was noticing a new pass, not retrying a job.
<cjwatson> This wasn't a jenkins-side problem, it was adt-britney getting lost
<infinity> Right.
<xnox> slangasek: New binary: android [i386] \o/
<infinity> What do we do about adt-britney getting lost, I'm curious about that too.
<cjwatson> I don't think it's about a new pass either - the problem AFAIK is when amd64 and i386 results arrive out of sync, sometimes adt-britney gets confused
<slangasek> xnox: woohoo :)
<cjwatson> Until jibel figures out WTF is wrong and fixes this properly, what I do is edit the individual job file plus results.history in ~/proposed-migration/autopkgtest/data/adt/trusty-proposed/amd64/work/, being careful to ensure that p-m isn't running at the time
<xnox> slangasek: i like the copyrights files package as well, will get that seeded on touch images such that we actually ship copyrights for the android portion of the image.
<cjwatson> It's not pretty ...
<xnox> slangasek: made it before UTC EOD ;-)
<slangasek> xnox: haha, nicely done
<xnox> slangasek: which to be honest only because of my anckle.... can't leave home so do this instead =)
<slangasek> heh
<slangasek> clearly we should injure you more often
<infinity> And more extensively?
<infinity> Does the quality of the work increase inverse to the gimpiness?
<cjwatson> Compassionate management
<xnox> infinity: it follows Ballmer Perk, but with painkillers http://xkcd.com/323/
<infinity> Peak...
<slangasek> lol
<xnox> s/Perk/Peak/ but same thing i guess
<doko> cancelled the ruby-lapack arm64 build again
#ubuntu-release 2013-10-25
<xnox> Please demote boost1.53 src+binaries into universe =)
<infinity> xnox: Done.
<xnox> \o/
<doko_> xnox, so gccxml should go too
<infinity> Byebye, libperl5.14.
<xnox> doko_: libboost-python1.54-dev still "Recommends" gccxml. Is main done by build-depeds, depends & recommends?
<xnox> doko_: or why is gccxml not in components-missmatches. I agree though gccxml should be in universe.
<infinity> xnox: Recommends will keep it in main.
<xnox> doko_: unless i package https://github.com/alexleach/gccxml_plugin which removes all gcc4.2 code.
<infinity> I suppose it's too late to suggest we just drop boost entirely from Debian and Ubuntu?
<xnox> infinity: to be honest, majority of packages should switch to C++11 & STL. Half of things only uses crap like unique_pointer & command-line-arg-parser from boost.
<wgrant> xnox, doko_: That's why I initially demoted gccxml to Suggests, but someone disagreed.
<doko__> xnox, wgrant: the objections for the suggests were for saucy. please do it for trusty
<doko__> xnox, nice plugin, however should stay in universe
<xnox> doko__: ok i'll do it for trusty, sometime with next / subsequent uploads.
<xnox> no rush to do it right now.
<ScottK> doko__: I'll see if I can find someone with interest, otherwise we can remove it.
<tseliot> any admins around?
<tseliot> didrocks: ^
<didrocks> tseliot: in meetings
<tseliot> didrocks: ok, never mind, thanks
<didrocks> sorry ;)
<tseliot> Riddell: are you around?
<Riddell> hi tseliot
<tseliot> Riddell: hi, we filed a MIR in bug 1204820 but we didn't specify that we needed that for both saucy and precise
<ubot2> Launchpad bug 1204820 in nvidia-prime (Ubuntu) "[MIR] nvidia-prime & fglrx-pxpress" [Undecided,Fix released] https://launchpad.net/bugs/1204820
<cjwatson> Riddell: can I sync webcit and drop https://launchpadlibrarian.net/142321538/webcit_8.16-dfsg-1_8.16-dfsg-1ubuntu1.diff.gz ?  Same reason as citadel or citadel-client or whichever it was the other day
<tseliot> Riddell: so now the two packages are in main only in Saucy. Would it be ok if I added the two packages to the seeds for precise and we moved them to main?
<xnox> tseliot: not really, why you need that?
<Riddell> cjwatson: yeah go for it
<cjwatson> ta, done
<Riddell> tseliot: mm didn't we release precise last year?
<xnox> tseliot: sometimes security team picks up support for previous releases, if same package gets into main into latter release.
<tseliot> xnox: because packages in main cannot depend on packages in universe
<tseliot> Riddell: well, there are point releases
<xnox> tseliot: ok, but we don't change components post-release without a good reason. and if done the change would only be visible in -security and/or -updates only.
<tseliot> and the two packages were included in 12.04.3
<xnox> tseliot: what are the packages in question?
<tseliot> xnox: nvidia-prime and fglrx-pxpress
<xnox> tseliot: neither of which have reverse dependencies in precise/main, or do you plan to introduce one?
<Riddell> xnox: he wanted to add to seed
<Riddell> I suppose it makes sense but I've not done it before so it makes me a little nervous I'm missing something
<xnox> tseliot: i'm not sure. Where did you want to seed them into? "supported" or on to desktop-cd?
<tseliot> xnox: for now it's just that if I upload the package, it ends up in NEW
<tseliot> as it happened to nvidia-prime
<tseliot> xnox: supported, I guess
<tseliot> or whatever else can prevent my packages from ending up in NEW
<xnox> tseliot: yeah, that's unfortunate bug in launchpad, but pretty much only affects you so far and poor AA who needs to de-new it constantly.
<Riddell> tseliot: it needs a SRU request
<Riddell> if you want new versions in precise
<tseliot> Riddell: yes, I've done that
<xnox> tseliot: and i don't think seeding in main will help at all, cause i think launchpad still says "oh look precise-release didn't have it" => NEW, and it should learn to look at -updates pocket.
<Riddell> it won't end up in new there's already packages in precise
<Riddell> tseliot: bug no?
<cjwatson> Riddell: yeah it will
<xnox> Riddell: i think those two packages fall under "hardware enablement stacks" with respect to kernel & graphics packages.
<xnox> cjwatson: ^ wouldn't it?
<cjwatson> Riddell: there's an LP bug relating to post-release pockets and ancestry
<cjwatson> but it's not a huge problem
<tseliot> Riddell: bug 1224098 and bug 1219650
<ubot2> Launchpad bug 1224098 in nvidia-prime (Ubuntu Saucy) "xserver wont start after nvidia-prime installation" [High,In progress] https://launchpad.net/bugs/1224098
<ubot2> Launchpad bug 1219650 in nvidia-prime (Ubuntu Saucy) "Failed to install on 12.04.3 , /var/lib/dpkg/info/nvidia-prime.postinst: 36: printf: 08: not completely converted" [High,In progress] https://launchpad.net/bugs/1219650
<xnox> ouch.
<tseliot> oh, so it's a bug
<Riddell> tseliot: just get SRU team to approve it from New then
<cjwatson> no seed change will affect NEW handling
<tseliot> cjwatson: ok, thanks
<tseliot> Riddell: the SRU team is subscribed to the bugs
<Riddell> tseliot: ok so upload package, add to seed, get SRU to approve it, if an archive admin needs to move to main that's the last step I think
<tseliot> Riddell: but really it should be at least removed from NEW so that it ends up in the "pending approval" state
<cjwatson> tseliot: dude it makes no difference
<cjwatson> don't obsess about the new vs. unapproved thing
<cjwatson> it requires manual action either way
<cjwatson> and we *can't* move it from new to unapproved anyway
<cjwatson> not without fixing the lp bug
<tseliot> cjwatson: can any member of the SRU team move it from NEW without being an admin?
<cjwatson> any member of the SRU team should be able to accept it if they think the changes are appropriate, yes
<cjwatson> we don't have per-queue permissions
<tseliot> ok, good
<cjwatson> ubuntu-sru has queue admin permissions for <all stable releases>-{proposed,updates}
<tseliot> it's a rather serious issue, so I didn't want it to get stuck for any reason
<tseliot> good
<xnox> I've uploaded sflphone rebuild against boost1.54, it's build-deps are not installable in trusty-proposed, but they are in trusty. Can that source package be somehow build with just "trusty" pocket enabled (a non-virt ppa?), binaries copied to trusted-proposed & migrated to trusty?
<xnox> ( i guess that can be last resort, if the build-deps uninstallability is not solved)
<cjwatson> a non-virt PPA is possible, but fairly cumbersome; last resort as you say
<xnox> ok.
<cjwatson> sflphone is part of the ucommon transition IIRC
<xnox> yeap, correct.
<xnox> i've bumped it to boost1.54, and it does build correctly in -release, so it shouldn't cause any additional entanglement in the ucommon transition.
<cjwatson> I don't especially object but I wonder if it would be better to just slap that transition through ASAP
<xnox> well, i'm juggling slepc mini-transition and ogre-1.9 mini-transitions, to finally get off boost1.49.... having 3 boosts in the archive is too much.
<cjwatson> I can start on the obvious bits of it at least
<xnox> ack. and I think boost1.54 will eventually be stuck on libav9 transition, unless e.g. old blender is rebuilt in trusty-release, bypassing new upstream release.
<jpds> Anyone from the SRU team know when https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/995719 will go into -updates ?
<ubot2> Launchpad bug 995719 in puppet (Ubuntu Precise) "process_name.rb removed in 2.7.11 but still provided by puppet-common" [High,Fix committed]
<xnox> jpds: from http://people.canonical.com/~ubuntu-archive/pending-sru.html it looks like it's good to go, but SRUs are not usually released on Fridays.
<xnox> (due to many developers missing typically over the weekend to handle a regression)
<cjwatson> We don't normally.  That one looks harmless enough though?
<xnox> i think it is harmless enough.
<jpds> "Mostly harmless."
<cjwatson> Yeah, just removing a file
<cjwatson> jpds: released
<jpds> cjwatson: Thank you!
<cjwatson> oh, I could've just retried libccaudio2, bah
<cjwatson> hm, the libucommon-dev -> libgnutls28-dev dep is going to be troublesome, and the ucommon changelog says it fails to build against libgnutls-dev
<xnox> I don't understand britney's excuse for not considering gnuradio. Can somebody help me, please? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> that's probably NBS in -proposed, give me a minute
<cjwatson> (proposed-migration needs some manual care in the case where one of the intermediate unmigrated versions has NBS binaries)
<xnox> ok.
<cjwatson> xnox: removed, should work after the next publisher run
<cjwatson> right, let's see if the server image will build
<cjwatson> if this works I think I'll call it a week
 * cjwatson quickly fixes up ~cdimage/.isotracker.conf
<infinity> cjwatson: FWIW, I concur that we should probably pull arm64 out of slow_arches nowish.  New uploads should take precedence, so the only reason it would lag is build failures, which we'll have to deal with one way or another.
<cjwatson> Yeah, I was considering doing it before I finish for the day.
<infinity> I'd certainly be more comfortable if our builders were more reliable, but I'm not holding my breath on that happening soon.
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty_uninst_full.txt  if anyone fancies a project :-)
<cjwatson> that's with considering arch: all on all architectures rather than just i386
<infinity> That's more depressing than the regular uninst.
<infinity> (But actually, not all that bad)
<cjwatson> It isn't quite as terrible as I'd expected.
<infinity> ppc and armhf are a bit worse than I suspected.  Lots of "do we actually care?" versus "arch:all packages that depend on :any should probably not be :all" decisions to take there.
<infinity> Or, arguably, a Soyuz bug/misfeature to fix in some cases.
<cjwatson> I tried to persuade the nodejs people of the error of their ways a couple of weeks ago.  Not sure I've got the message across yet.
<cjwatson> (I think all their packages should be Architecture: any Build-Depends: nodejs
<cjwatson> )
<infinity> As in, if there's no build for a source in a DAS, perhaps we shouldn't publish the arch:all packages on that arch.
<infinity> Not counting things that are all-only.
<infinity> So, it gets a bit messy to get the heuristic right.
<infinity> But I still suspect that's a correct heuristic to apply.
<cjwatson> I think most of these are all-only with arch-specific deps.
<infinity> Yeah, that's a harder problem that should be addressed at the package level.
<cjwatson> You may have a point in some cases, yeah
<infinity> I'm thinking of sources that are "i386 amd64 all", where the all seems to have a legit right to exist, but just shouldn't exist on !x86.
<cjwatson> Though I'd kinda like to persuade Debian of it first
<infinity> And I'm not sure, but I think DAK might get that case right.
<cjwatson> Just in case there are weird exceptions ...
<cjwatson> Never heard of it does so.
<cjwatson> *doing
<infinity> I know they pull some tricks to not publish arch:all stuff when the :any build on an arch is lagging.
<cjwatson> I thought they just kept publishing the old one.
<infinity> Yes, but not the new one.
<cjwatson> Oh, right, yeah
<cjwatson> I guess that might imply this
<infinity> Which works around the apt bug/misfeature we run into with our "publish them all" approach.
 * cjwatson checks
<cjwatson> infinity: Nope - 7kaa is Architecture: amd64 i386 all, but 7kaa-data is published in unstable/powerpc
<infinity> Ahh, kay, so much for the hope that someone else got that more right than us. ;)
<infinity> I guess it's hard to know for sure that you got it right.  One could construct a package that produces "foo-i386, foo-amd64, foo-sparc, foo-python-portable" and you'd actually want the last one on all arches.
<infinity> Or whatever.
<cjwatson> infinity: I think there really are such cases with Java.
<cjwatson> Build foo-java on all architectures, foo-jni on some.
<infinity> cjwatson: Right, so perhaps not worth trying to be clever at the archive level there.
<stgraber> ogra_, lool: I've turned off import-images for system-image as the last touch build is breaking the delta generation tool, I need to look into the specific problem
<ogra_> stgraber, ok
#ubuntu-release 2013-10-27
<ogra_> stgraber, did you eventually find the issue for the broken diff generation of system-image ?
<ogra_> (would be really nice to be able promote image #6 on monday)
<cjwatson> I've removed arm64 from OUTOFSYNC_ARCHES in proposed-migration.
<cjwatson> So it'll now require arm64 builds to be up-to-date if the previous version was built.
<cjwatson> It's caught up enough now that this should be safe.
<apw> cjwatson, cool
<cjwatson> apw: Are we getting an arm64 kernel package soon? :)
<stgraber> ogra_: I didn't have time to investigate on Friday, will try to fix this today
<apw> cjwatson, sure are ... waiting on some testing but yeah
<ogra_> stgraber, well, i meant "on monday" ... i didnt mean "please work on the weekend" ;)
<micahg> infinity: any chance of fixing the other arm64 buildds? 3 are on manual
<apw> micahg, as likely as anything with the queue so short 'not birch' are disabled for performance, that one is much more reliable
<micahg> apw: was unaware that they weren't all the same, makes sense
<apw> micahg, birch is definatly superior
<cjwatson> micahg: I believe we're deliberately sending failures to birch to see if it does better
<cjwatson> (So much as apw says)
<micahg> well, my build was fine the second time around
<cjwatson> Yep, that's not too surprising
<cjwatson> I expect we'll unmanual before EOD
<cjwatson> i.e. before the next flood
<micahg> ok, I've been seeing some failures on arm64 for previous uploads, I guess the only sane thing to do at the moment is fix if it's an autotools thing and leave it for someone else who has hardware otherwise?
<micahg> or are the qemu instructions somewhere?
<cjwatson> We don't have full-system qemu yet AFAIK
<cjwatson> And I don't think the user-mode qemu is packaged
<cjwatson> So indeed, fix if obvious, leave if not
<cjwatson> It shouldn't be a blocker for anyone - arm64 failures will only block migration if it built before
<micahg> that was the case I had :)
<micahg> was some weird failure in dpkg-genchanges
<cjwatson> Just retry that
<micahg> yeah ,already did and it built fien
<cjwatson> That's the non-birch hw being randomly segfaulty
<cjwatson> We have a special version of launchpad-buildd installed on those builders that checks dmesg for the faults and considers them failures
<cjwatson> At least I think that's still true
 * cjwatson fails to understand why haskell-{sdl,cairo} and the stacks above them are showing up in http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<cjwatson> They look installable to me and they aren't showing up in p-m output
<cjwatson> I wonder if it's an :any dependency somewhere, doom
<cjwatson> Oh well, nap time first
#ubuntu-release 2014-10-20
<mlankhorst> can someone approve xxv-intel? ^
<smb> Sorry if that is repeating a known fact which is going away with the final release. Just noting that right now with the daily iso the "release notes" link is pointing to the ubuntu.com main page.
<LocutusOfBorg1> can anybody please give a feedback to me about bug 1382848?
<ubot2> bug 1382848 in ettercap (Ubuntu) "[FFe] Sync ettercap 1:0.8.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1382848
<LocutusOfBorg1> I really would like to see it in the upcoming utopic, the current kernel spot a race condition in one of the core parts of ettercap
<apw> smb, i _think_ that the link doesn't actually point there, i think it points to something "dynamic" which webops have to sort ... but best to let someone else confirm
<smb> apw, Yeah, I just wanted to bring it up in the case this needs something done in the installer, too. maybe I could copy the link to find out what exactly it is. Its not obvious by hovering over it or when firefox comes up
<cjwatson> smb,apw: I can confirm this is not a problem with the installer; web team (not webops) needs to fix it
<smb> cjwatson, Ok, thanks.
<M-Saunders> Hi everyone. Was the 14.10 RC released on the 16th? I can't find a trace of it
<stgraber> M-Saunders: we don't do RCs
<infinity> Or, rather, we don't "release" them.
<M-Saunders> Ah, thanks. I was going on this: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
<infinity> It's logically nonsensical to release a release candidate.
<M-Saunders> I'm making a coverdisc for a magazine (Linux Voice), and my deadline is Friday
<infinity> M-Saunders: Click the ReleaseCandidate link there, it explains it.
<infinity> M-Saunders: The real release is Thursday, that's the ISO you'll want to be using.
<M-Saunders> infinity: Yeah. For testing in the meantime, would you recommend using the nightlies?
<infinity> M-Saunders: Yep.
<M-Saunders> Great, thanks
<M-Saunders> And as far as you know, should the release happen on Thursday? I haven't seen any talk of slippage
<infinity> M-Saunders: It's been years since we slipped, I don't anticipate it.
<M-Saunders> Yep, you guys have been reliable in recent years indeed. Ta!
<Riddell> #
<knome> Riddell, the number you have dialed cannot be reached.
<Riddell> it's the ultimate twitter hashtag
<Laney> Where are we with accepting stuff / britney blocks / respins?
<infinity> Laney: britney block should happen.  Happy to have you do that, if you'd like.
<infinity> Laney: There's a guaranteed respin tomorrow for a kernel issue, so we can squeeze some other bits in in the meantime if they seem sane.
<Laney> Kewl
<Laney> I'll do a mega block and we can block-all source later on
 * Laney stabs this latency
<mdeslaur> can someone please accept xchat-gnome so I can start sruing it, thanks
<infinity> mdeslaur: Looking.
<Laney> the world is blocked
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.1, Utopic Beta 2 | Archive: Final Freeze, packages on images blocked | Utopic Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<mdeslaur> infinity: sooooo many packages in the archive force sslv3... /me cries
<infinity> mdeslaur: Sadness and loss.
 * Laney collides with stgraber 
<mdeslaur> infinity: same fix, but for xchat ^
<infinity> mdeslaur: Having fun with this one yet? :P
<mdeslaur> infinity: I don't think we have the same definition of "fun" :)
<infinity> mdeslaur: Do you have a list of still-affected packages?
<infinity> mdeslaur: And can you prioritise stuff that's on images (as seen by seeded-in-ubuntu(1)), so they get into respins?
<mdeslaur> infinity: I don't have a list yet...I started, but then got depressed and switched to looking for beer.
<mdeslaur> infinity: I'll try and see after lunch
 * cjwatson updates ubiquity-slideshow-ubuntu translations
<cjwatson> <joeyh> debconf-updatepo... also known as "I'm feeling unproductive today.
<cjwatson>         Please give me a huge diff to check in"
<jibel> infinity, bug 1381766 and bug 1378735
<ubot2> bug 1378735 in syslinux (Ubuntu) "Unable to use PXE boot with 14.10 (Utopic Unicorn) Daily Build: "Failed to load ldlinux.c32"" [Undecided,New] https://launchpad.net/bugs/1378735
<cjwatson> possibly same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586
<ubot2> Debian bug 750586 in debian-installer "syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug" [Important,Open]
<cjwatson> http://paste.ubuntu.com/8604733/
<cjwatson> pretty sure CPing that will do the job
<cjwatson> jibel: fix committed
<pitti> hello all
<jibel> cjwatson, thanks
<pitti> bdmurray pointed me to bug 1372665, which is because we currently run *both* /etc/init.d/apport (unintentinoally) and /etc/init/apport.conf (intentionally) during boot
<ubot2> bug 1372665 in apport (Ubuntu) "apport reports suspend/resume failure twice on boot (apportcheckresume)" [High,Fix committed] https://launchpad.net/bugs/1372665
<pitti> I just committed a trivial fix for that to trunk, is that something which we still want in the release, or as SRU at this point?
<mdeslaur> infinity: ok, my search only found spamassassin in the seeded list: bug 1383415
<ubot2> bug 1383415 in spamassassin (Ubuntu) "Incorrect use of SSL options" [Undecided,New] https://launchpad.net/bugs/1383415
<mdeslaur> infinity: all the others aren't seeded
<mdeslaur> (that's just searching for the same type of issue as xchat-gnome had...)
<mdeslaur> infinity: and it's not important enough for a quick fix
<pitti> cjwatson, all: we have an idea what changed last Friday -- the old distro-info said that utopic was released at that day; this can't be a coincidence, there's surely something in the autopkgtest machinery that still uses that
<pitti> until that, test runs are stalled, I'll request those manually while we investigate
<kenvandine> pitti, thx
<jibel> pitti, actually the problem is not what I thought but an SSL issue http://paste.ubuntu.com/8605136/
<pitti> jibel: FTR, manually running tests doesn't help -- they are available in jenkins with the right version, but britney doesn't pick those up; consistent with the SSL prob?
<jibel> pitti, yes the error comes from the job that consumes the queue
<jibel> pitti, it should be unblocked. The SSL errors happens when it fetches changes from LP to find latest uploader. I disabled notification of the uploader for the moment.
<cjwatson> jibel,pitti: I bet this coincides with SSLv3 being turned off on Launchpad frontends
<cjwatson> due to the recent catastrophic vulnerability in it
<cjwatson> what is trying to use SSLv3?
<cjwatson> jenkins/adtnotify.py
<cjwatson> Probably ought to be ssl.PROTOCOL_TLSv1_2 nowadays
<cjwatson> http://paste.ubuntu.com/8605356/ maybe (untested)
<cjwatson> hmm
<cjwatson> I wonder if we should retain the fallback in case in future LP upgrades to TLSv1.3
<mdeslaur> please use ssl.PROTOCOL_SSLv23 for everything
<mdeslaur> that will negotiate the best
<cjwatson> Not clear that ssl.PROTOCOL_TLSv1_2 would interop with that, but ssl.PROTOCOL_SSLv23 tries everything
<mdeslaur> cjwatson: ^
<cjwatson> mdeslaur: right except it's failing here
<cjwatson> the log is really misleading but when it says "Trying SSLv3" it's actually falling back to trying ssl_version=ssl.PROTOCOL_SSLv23
<pitti> cjwatson, mdeslaur: but SSLv23 is the one that is failing, no?
<cjwatson> so maybe it's just that the fallback doesn't work
<cjwatson> I bet it needs to reopen the socket from scratch
<mdeslaur> perhaps you can't try a different wrap_socket
<mdeslaur> cjwatson: yeah
<cjwatson> since it's probably already done some negotiation
<pitti> oh, right http://paste.ubuntu.com/8605136/ doesn't actually show an SSLError
<cjwatson> so yeah, just use ssl_version=ssl.PROTOCOL_SSLv23 across the board and drop the override; that's what httplib does itself anyway, so you can just drop this whole misguided thing
<pitti> so PROTOCOL_SSLv3 succeeded, but then fails later on
<cjwatson> no, the SSLError was swallowed by the except
<cjwatson> and then the fallback attempt failed because it was in the wrong place in the protocol to restart ssl.wrap_socket
<pitti> can we apply that locally on snakefruit to test it before we commit it to lp:britney2?
<cjwatson> I am reasonably sure that you can just do http://paste.ubuntu.com/8605402/
<cjwatson> python2.7's httplib uses the ssl_version we want
<cjwatson> pitti: this isn't on snakefruit
<cjwatson> it's somewhere that has /var/lib/jenkins/QA/
<cjwatson> tachash?
<cjwatson> and it's not in britney2, it's in lp:auto-package-testing
<pitti> ah, I don't have access to that
<jibel> on tachash
<pitti> oh
<pitti> cjwatson: cheers
<mdeslaur> cjwatson: I think you still need that to specify the certs, or it defaults to no cert checking
<cjwatson> really?  I didn't see that when comparing the code
 * cjwatson looks again
<cjwatson> no, that's passed to the constructor and the default implementation passes it through
<cjwatson>             self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
<cjwatson> from the default impl
<pitti> yay, I'm getting jenkins-failed mails again, so I suppose it's working again
<pitti> (with the degraded notifications)
<cjwatson> mdeslaur,jibel: so I don't think I see a reason to keep that; but should clean up a bit more, http://paste.ubuntu.com/8605441/
<cjwatson> urllib2 certainly works against LP without any of that stuff, although I don't have an easy way to confirm what TLS version it's using
<cjwatson> mdeslaur: (if you could confirm at some point that would be good ...)
<mdeslaur> cjwatson: yeah, sorry, that the client cert...I don't think urllib2 does any sort of server cert verification at all, actually
<cjwatson> it doesn't look like it.  but the code in adtnotify doesn't appear to help with that
<mdeslaur> cjwatson: is this python2 or python3?
<cjwatson> mdeslaur: python2
<cjwatson> mdeslaur: actually, ssl.py in python2.7 appears to default to CERT_REQUIRED when in client mode
<mdeslaur> cjwatson: ok, so no cert verification in there
<cjwatson> see create_default_context
<cjwatson> or do you need ca_certs= to make that work?
<cjwatson> pitti: apport> looks fine, accepted, thanks
<mdeslaur> cjwatson: where can I get the whole adtnotify.py file?
<pitti> mdeslaur: http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/jenkins/adtnotify.py
<mdeslaur> pitti: thanks
<mdeslaur> pitti, cjwatson: right, so no server cert verification in there, and the removed code had no impact on that
<Laney> arges: I'd appreciate it if you could consider the e-d-s I just uploaded so we can get both versions in at once
<arges> Laney: ok i'll take a look
<Laney> thanks
<Laney> sorry for forgetting that one initially
<Laney> but the bug sucks a bit
<wxl> um, are there supposed to be new images in daily? i see everything's old again.
<infinity> wxl: Shouldn't be anything new, no.
<wxl> infinity: ok, cool. thanks :)
<arges> Laney: ok just to confirm, that e-d-s upload overrides 3.10.4-0ubuntu1.4 and is a superset of fixes?
<Laney> arges: It's another patch on top, yeah
<arges> Laney: ok yea looked like it, just wanted to make sure i wasn't missing anything
<Laney> sure, no worries
<Laney> w00t
#ubuntu-release 2014-10-21
<slangasek> stgraber, infinity, xnox: fyi I posted some more information about my own plymouth findings to bug #1362333
<ubot2> bug 1362333 in ubiquity (Ubuntu) "After reboot of Ubuntu installation, password for LVM encryption is not accepted" [Undecided,Confirmed] https://launchpad.net/bugs/1362333
<apw> slangasek, i think i have proved that that is a plymouth issue, not sure what the issue is mind ... info in the bug
<LocutusOfBorg1> ginggs, thanks for testing
<LocutusOfBorg1> I hope I'll get the Ffe
<ginggs> LocutusOfBorg1: You are welcome.  I was just to about to ask here if someone could take a look :)
<LocutusOfBorg1> BTW I'm debian maintainer for both of them, if it matters, and also upstream developer of ettercap :)
<LocutusOfBorg1> and yes, I build them on ubuntu, so thanks for rebuilding, but I usually test them on trusty/utopic :)
<LocutusOfBorg1> virtualbox actually fixes two RC on debian, due to the xorg 1.16 switch
<LocutusOfBorg1> and ettercap fixes a really serious bug that makes it (almost) useless on some conditions
<LocutusOfBorg1> I tried my best to release ASAP, but I failed because of the debian freeze :(
<ginggs> Hi release team, I'm looking for FFes for LP: #1382034, LP: #1382848 and LP: #1382922 please.
<ubot2> Launchpad bug 1382034 in modem-manager-gui (Ubuntu) "FFe: Sync modem-manager-gui 0.0.17.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1382034
<ubot2> Launchpad bug 1382848 in ettercap (Ubuntu) "[FFe] Sync ettercap 1:0.8.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1382848
<ubot2> Launchpad bug 1382922 in virtualbox-guest-additions-iso (Ubuntu) "[FFe] Sync virtualbox and guest additions 4.3.18-dfsg-1 (multiverse) from Debian unstable (contrib)" [Wishlist,New] https://launchpad.net/bugs/1382922
<pitti> cjwatson, Laney: distro-info problem? https://jenkins.qa.ubuntu.com/job/utopic-adt-pbuilder/20/ARCH=i386,label=adt/console
<pitti> ubuntu-distro-info: Invalid date `2016-01-30' in file `/usr/share/distro-info/ubuntu.csv' at line 23 in column `eol'.
<pitti> not sure what's invalid in that date, though
<Laney> Hm
<infinity> That doesn't make a lot of sense.
<rbasak> Missing EOL at end of the line?
<cjwatson> Not in what I committed ...
<infinity> Looks fine to me.
<rbasak> Sorry. Just a random guess as to why a CSV might appear right but parse wrong.
<cjwatson> but it does fail locally for me
<Laney>            date->month == 1 ? 29 : days_in_month[date->month-1]);
<Laney> It's probably that
<Laney> s/30/29/ fixes it
<infinity> *blink*
<cjwatson> Err
<infinity> 29 days in January, eh?
<cjwatson> date->month == 2 surely
<Laney> Yes
<cjwatson> distro-info-util.c:           date->month == 2 ? 29 : days_in_month[date->month-1]);
<cjwatson> in git
<cjwatson> http://bugs.debian.org/766142 I think
<ubot2> Debian bug 766142 in distro-info "distro-info: Invalid date in ubuntu.csv" [Important,Fixed]
<cjwatson> so I guess we just sync distro-info once that's available?
<cjwatson> and remember that we need to update that in stables before distro-info-data
<infinity> Yeahp.
<infinity> Fun bug.
<Laney> Might want to upload it if it's breaking autopkgtests
<cjwatson> oh it breaks other tests too?
<cjwatson> ah yeah, bah
<infinity> Anything that uses distro-info, I suppose.
<cjwatson> somebody wanna do that?  in meeting
<infinity> Yeah, I'll do it.
<Laney> Can review
<infinity> Laney: ^
<Laney> Soz, was eating a bagel, looking
<Laney> â
<infinity> There are bagels?
<infinity> WHY DID NO ONE TELL ME THERE WERE BAGELS.
<mdeslaur> infinity: dude! bagels!
<kenvandine> bagels?
<Laney> You wanted a bunker, you got a bunker
<kenvandine> :-D
 * Laney collects dead rats
<infinity> No, seriously, where are these bagels?
<infinity> This has suddenly become very important.
<Laney> In the coffee area upstairs
<infinity> Oh, there's good stuff if I leave the dungeon?  Check.
 * knome lols
<knome> infinity, get some food :D
 * Laney gnaws on knome 
<knome> oh mi gosh!
<knome> i'm not a bagel
<elfy> possibly a worse choice than bagel
 * knome offers some meatloaf for Laney 
<Riddell> emergency SRU needed to fix release upgrade notification in kubuntu, bug 1383767
<ubot2> bug 1383767 in muon (Ubuntu Utopic) "muon does not find releasechecker" [Undecided,New] https://launchpad.net/bugs/1383767
<shadeslayer> Riddell: probably worth pinging on ubuntu-release ML as well?
<pitti> infinity: FTR, uploading fresh langpacks now; there were a few gotchas this morning
<Laney> LocutusOfBorg1: Would you please include the upstream changes in your ffes?
<LocutusOfBorg1> lamont, yes, THANKS!!!!
<Laney> umm
<LocutusOfBorg1> going to add changelogs
<LocutusOfBorg1> lamont, changelogs added for virtualbox :)
<LocutusOfBorg1> the guest-additions changelog I guess isn't needed, right?
<lamont> LocutusOfBorg1: I am not related to this, correct?
<LocutusOfBorg1> sorry s/lamont/laney
<LocutusOfBorg1> :( damn tab
<cjwatson> apw: do the signed char conversions work out right in your plymouth upload?  I think I'd be more comfortable if you were using uint8_t *
<cjwatson> like ply_write_uint32
<cjwatson> it's not actually treated as characters anywhere
<apw> cjwatson, i can do that
<infinity> apw: I can haz new patch, so we can test here?
<apw> infinity, yep when i've gotten it building again ...
<shibata> Hi all. Can someone check LP: #1382132 ? And could you tell me where channel should I contact?
<ubot2> Launchpad bug 1382132 in ubiquity-slideshow-ubuntu (Ubuntu) "Unicorn first slideshow haven't changed from Tahr" [Undecided,New] https://launchpad.net/bugs/1382132
<Riddell> 16:27 < Riddell> emergency SRU needed to fix release upgrade notification in kubuntu, bug 1383767
<ubot2> bug 1383767 in muon (Ubuntu Utopic) "muon does not find releasechecker" [Undecided,New] https://launchpad.net/bugs/1383767
<slangasek> Riddell: have you seen that muon ftbfs on all archs in utopic-proposed?
<slangasek> /build/buildd/muon-2.2.0/installer/ResourceView/ResourceDelegate.cpp:37:34: fatal error: Nepomuk/KRatingPainter: No such file or directory
<slangasek>  #include <Nepomuk/KRatingPainter>
<slangasek>                                   ^
<slangasek> compilation terminated.
<slangasek> Riddell: your SRU upload also misses the bug reference in the changelog (and ought to be numbered -0ubuntu3.2 rather than -0ubuntu3.1.1).  Will you upload a fix or do you need me to?
<apw> infinity, ok the patch at: http://people.canonical.com/~apw/misc/plymouth-split-writes.debdiff should be up to date
<apw> ^ infinity, kernel update as requested ...
<infinity> Laney: Man, that aisleriot commit/comment is pretty hostile.
<infinity> Laney: Can't we all just get along?
<Laney> Yeah, no joke
<slangasek> pitti: hi, do you see anything in this build log that would account for missing ddebs? https://launchpadlibrarian.net/179654105/buildlog_ubuntu-utopic-i386.bzip2_1.0.6-5ubuntu4_UPLOADING.txt.gz
<Laney> We had one like that in gnome-terminal a few months ago
<Laney> So when I noticed there weren't proper menus in aisleriot, and remembered who the maintainer was, ...
<slangasek> pitti: (this was after I specifically fixed bzip2's build system to generate ddebs properly; but they're missing for i386 and amd64, maybe it's an already-fixed bug somewhere and we just need to no-change rebuild?)
<Laney> GNOME decided that wasn't cool so we just pushed the commit straight upstream
<pitti> slangasek: not really, that looks good to me
<slangasek> ok
<slangasek> infinity: ^^ can I shove in a no-change rebuild of bzip2 to try to get debugsyms?
<cjwatson> infinity: hey, could you make https://launchpad.net/ubuntu/+series look consistent between utopic and vivid?  apparently the mismatching display name triggers a sorting bug on the bug nominate-for-series form
<infinity> cjwatson: Oh, I got the wrong bits in the wrong fields, I guess.  Can fix.
<infinity> slangasek: Go nuts.
<slangasek> infinity: AHAAHAhahahaHAHAHAaha
<slangasek> </nuts>
<cjwatson> infinity: we should clear priority-mismatches
<infinity> cjwatson: vivid fixed.
<slangasek> vixed?
<cjwatson> vhanks
<infinity> cjwatson: Nothing in p-m looks terribly scary, except that I knee-jerked at acl, thinking it was acl2.
<infinity> And I'm all for perl in required.  You go, perl.
<slangasek> knee-jerking an acl is a good way to get injured
<infinity> cjwatson: Were you going to attack those, or did you want me to?  (don't want to race).
<cjwatson> infinity: I can do it but it'll be half an hour or so
<infinity> slangasek: So, are you sure ddeb-retriever is actually going to pick these up correctly this time?
<infinity> cjwatson: Right, I can do it.
<cjwatson> infinity: thanks
<infinity> Architecture-independent packages missing from some architectures:
<infinity> ------------------------------------------------------------------
<infinity> infernal-doc [arm64 armhf i386 powerpc ppc64el]
 * infinity blinks.
 * ogra_ guesses they are infernal for a reason
<infinity> That looks sort of NBS.
<infinity> wgrant: Come to the release lair when you have a chance.  I have something for you to scratch your head over.
<slangasek> infinity: no I have no confidence in ddeb-retriever in spite of the run of fixes done to it, so this remains best-effort until wgrant gives us swiftbrarian
<infinity> slangasek: s/wgrant/IS/
<slangasek> bdmurray: infinity wants to make sure you know that if you're doing boost1.55, boost-mpi-source1.55 has to be uploaded with it with a matching source version number
<slangasek> bdmurray: also, boost1.55 is on all the images so if you were to do that one, it should be uploaded soonish - otherwise we should skip it
<jibel_> infinity, bug 1383851
<ubot2> bug 1383851 in plymouth (Ubuntu) "Cannot enter LVM encryption password in qemu with -vga std" [Undecided,New] https://launchpad.net/bugs/1383851
<bdmurray> slangasek: I've contacted pitti about watching for the ddebs
<slangasek> ok
<slangasek> so virt-manager does -device VGA,id=video0,bus=pci.0,addr=0x2 instead of -std vga; how do these compare?
<slangasek> sorry, -vga std
<infinity> doko: You need to upload all the gcc-4.8 cross packages to drop the binaries that the 4.9 packages produce.
<doko> infinity, do you still care about 4.8?
<infinity> doko: No, I care that the archive doesn't have a broken mess of binaries.
<infinity>  lib64atomic1-powerpc-cross | 4.8.2-16ubuntu3cross0.11 | utopic/universe | all
<infinity>  lib64atomic1-powerpc-cross | 4.9.1-16ubuntu6cross0.4  | utopic          | all
<doko> ok, let's remove them
<infinity> doko: ^-- For instance.
<infinity> doko: If anyone were to try to upload 4.8, it would be rejected.
<infinity> doko: Err, I don't want to remove the compilers at this point in the release, someone might be using them, and I'm not going to do a poll. :P
<wxl> release notes are /release-full-name/ReleaseNotes/optional-flavor correct?
<infinity> doko: So, please remove the unshipped binaries?
<slangasek> the arm ones in particular still might be used somewhere for android bits
<infinity> wxl: http://paste.ubuntu.com/8618664/
<doko> infinity, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8-powerpc-cross/+bug/1383864
<ubot2> Launchpad bug 1383864 in gcc-4.8-powerpc-cross (Ubuntu) "please remove the gcc-4.8-*-cross packages, superseded by gcc-4.9" [Undecided,New]
<infinity> wxl: That's a handy list of the redirects, which should show were we expect release notes.
<infinity> doko: Like I said... I don't want to remove them two days before release when I don't know if people might be using them.
<infinity> doko: And it's way too late to conduct a poll and find out.
<slangasek> infinity: I would argue the only people we need to poll about this are the phonedations team with regards to android builds
<infinity> wxl: Mentally change 14.04 to 14.10 and TrustyTahr to UtopicUnicorn, of course. :)
<infinity> slangasek: Perhaps, yes.
<slangasek> as they're the only extra-archive consumers of non-default cross-compilers that I'm aware of
<infinity> slangasek: Care to poll?
<slangasek> rsalveti: ^^ are you guys still using gcc-4.8-armhf-cross anywhere?
<wxl> thx infinity
<slangasek> doko: discussion here notes that some of these cross-compilers are still relevant for cross-building of arm kernels
<rsalveti> slangasek: kernel I guess
<slangasek> ok
<slangasek> are the android bits all built from the source package now?
<rsalveti> slangasek: not for krillin, as unfortunately the pes guys still need to get that in a package
<rsalveti> at least the kernel side of it
 * slangasek nods
<slangasek> do you know which compiler that uses?
<rsalveti> slangasek: still the proprietary ones that are not provided by our archive
<slangasek> aha
<mapreri> might I know if a two-last-day sync like this http://www.mapreri.org/debian/debdiffs/scribus/1.4.4+dfsg1-1_1.4.4+dfsg1-2.debdiff is acceptable (is a only 100 rows debdiff, but really simple). it fixes a nasty bug I introduced, and has really no potential regressions (it can't make the situation worst)
<infinity> doko: Right, so it seems the conclusion is that you need to remove your duplicate binaries, not the sources.
<cjwatson> (that is, upload so the sources don't build those any more, not just remove-package)
<Riddell> slangasek: muon 2.2.0-0ubuntu3.2 uploaded to trusty-proposed awaiting approval by ~ubuntu-sru
<doko> jdstrand, infinity: openjdk-7 uploaded
<slangasek> Riddell: accepted
<infinity> doko: Can that be done in a PPA instead and queued up for an SRU?
<infinity> doko: That's a bit too large for release week.
<doko> mehh, it's the security update ...
<Riddell> thanks slangasek
<mapreri> infinity: â ? (I'd like an ack for http://www.mapreri.org/debian/debdiffs/scribus/1.4.4+dfsg1-1_1.4.4+dfsg1-2.debdiff to utopic (a sync))
<slangasek> doko: which means there's a perfectly good -security pocket that this can go to
<infinity> doko: What he said.
<doko> jdstrand, can you pick it from unapproved or rejected?
<bdmurray> infinity: how long do I have for these no change rebuild uploads?
<infinity> bdmurray: Many hours.
<Laney> Is there still a $world respin happening?
<cjwatson> Laney: yeah but will need a new slideshow first
<cjwatson> Laney: any help finding somebody who can crop out an appropriately stylised unicorn logo would be appreciated
<Laney> Umm, d...design?
<cjwatson> apparently marketing used to do it
<cjwatson> and design are all doing phone stuff ... but we may have to go back to them
<cjwatson> should just require gimp though, there's one of the wallpapers from the design contest that's almost right, my gimp skills just aren't up to cramming it into the right shape
<cjwatson> bdmurray: could you reupload gmp and libpciaccess as rebuilds rather than ubuntu versions, please?  dch -R
<cjwatson> no point inhibiting future autosyncs here
<cjwatson> think I may have missed that for expat
<infinity> Riddell: That muon SRU is FTBFS on all arches.
<Laney> please review that, per mapreri
<bdmurray> cjwatson: will do
<wxl> what's the difference between disabling and removing an image? i don't want ppc or amd64+mac to have a release
<stgraber> then you need to remove them and remove them from the manifest so they don't show up at all
<Riddell> infinity: the trusty SRU isn't, the utopic upload is but that's because of different reasons
<wxl> stgraber: do i remove them from the manifest even though i want the dailies to build?
<stgraber> the manifest isn't relevant to the dailies
<wxl> stgraber: k thanks :)
<stgraber> so yeah just disable them on the manifest
<infinity> wxl: We're going to drop amd64+mac on the floor anyway, I think.
<wxl> infinity: oh THANK GOD!!!!
<infinity> Riddell: Oh, I missed it.
<wxl> infinity: i've been trying to make a case to drop it or at least rename it. i'm quite sure that macs don't need it anymore. i haven't come across an intel mac that could not boot regular amd64. i know there are non-apple machines that still use old efi, but that's a lot of work for such a small number of machines.
<cjwatson> The prevailing theory here is that all such machines have firmware updates that fix the original bug
<wxl> cjwatson: i think that's a fair assumption. i'm 100% behind removing it.
<stgraber> +mac is now gone
<Laney> RIP
<wxl> YAY
<wxl> is this documented anywhere besides this conversation so i can spread the (official) good news? :)
<stgraber> we'll have to mention it in the release notes I expect and posssibly on www.ubuntu.com too
<infinity> cjwatson: s/all/most/ but for the really old ones, I think "use the i386 image" is an acceptable workaround.
<wxl> stgraber: if it does get published somewhere, let me know.
<infinity> cjwatson: Since i386 will be much more pleasantly speedy on an old Core2 anyway.
<cjwatson> stgraber: did you stop building it in cdimage too?
<cjwatson> I think etc/default-arches needs adjusting
<infinity> cjwatson: I'll pull it out of etc/
 * infinity nods.
<cjwatson> should we take care to keep building it for trusty point updates just in case?
<infinity> cjwatson: While I'm doing this, I'm seeing entries for anciently EOL releases, mind if I clean those up?
<cjwatson> separate commit if you do, please
<cjwatson> I preserved them as basically historical documentation but I guess I don't mind
<wxl> i'm going to remove any mention of amd64+mac in our release notes and leave it to ubuntu to handle it in theirs :)
<wxl> you guys can add fix released to this one :) https://bugs.launchpad.net/ubuntu-cdimage/+bug/1298894
<ubot2> Launchpad bug 1298894 in Ubuntu CD Images "amd64+mac images no longer necessary" [Undecided,New]
<Laney> ta
<Riddell> bug 1383767 SRU verification-done by me, not sure if it's maybe good practice to wait for someone else to verify it, but I'd really like this in tomorrow
<ubot2> bug 1383767 in muon (Ubuntu Utopic) "muon does not find releasechecker" [Undecided,New] https://launchpad.net/bugs/1383767
<infinity> Riddell: I can release it right now.
<Riddell> infinity: would be lovely
<infinity> Riddell: Done.
<Riddell> awooga
 * Laney unblocks the rebuilds
#ubuntu-release 2014-10-22
<jdstrand> doko (and slangasek): I can and did pick openjdk-7 from rejected. it is building in the security-proposed ppa (along with trusty and precise)
<infinity> jdstrand: Ta.
<infinity> Mass rebuild in progress for a new kernel, and other bits.
<bluesabre> SRU team, please release xfce4-weather-plugin into trusty-updates, https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1377612
<ubot2> Launchpad bug 1377612 in Xfce4 weather plugin "[SRU] Plugin needs updated for locationforecast-1.2" [Medium,Confirmed]
<smb> cjwatson, with the utopic server iso and installing over an existing install (standard using LVM) I run into the situation of first partition (which contains /boot) of the disk still mounted to /media. The installer acts correctly and asks to unmount and from there all is normal. So nothing fatal but just odd. Should I file a bug about it or do you already have one?
<rcj> ^ cloud images marked ready
<cjwatson> smb: I have no idea whether we have a bug about that.  I'll give it a try a bit later.
<cjwatson> infinity: In case you notice the build failure when you get up, I manually respun server from nusakan; it looks like rebuild-requests is confused about whether it needs to do a live filesystem build in the server case or not
<cjwatson> infinity: ubuntustudio/i386 failure still needs investigating, possibly from a better network
<smb> cjwatson, Ok, I am using the dailies from the 18th (which seem to be the most current). A cobbler netboot install with pre-seeding was ok. Hm, the mini iso there dates from the 17th. Manual update got them to todays date.
<smb> Will re-run the netboot install
<cjwatson> smb: Yeah, see above comment to infinity for why the server dailies are old
<smb> cjwatson, Doh. Ok I read the message but it sounded Japanese to me. Meaning I did not get its meaning. :)
<cjwatson> OK, it was intended to be meaningful mainly to Adam, but "previous rebuild didn't work, I did it differently" :-)
<smb> heh. ok. so with more recent image, netinstall still seems ok. good
<cjwatson> smb: ah, so I don't need to investigate this now?
<smb> cjwatson, Well it was the full iso install that showed the issue. But let me repeat that with the newer isos when they show up. As long as only manual cd install has it there is someone to press yes for unmount.
<smb> there already. just need to sync now
<smb> cjwatson, I would still see the unmount dialog with latest iso. But since the netbook variant seems unaffected it does not seem to warrant that you look at it urgently. You likely have enough other things to do and are caught in the wrong timezone.
<smb> I meant netboot
<cjwatson> ok, well let me queue it up for if/when I get a moment, thanks
<LocutusOfBorg1> cjwatson, may I ask you a trivial sync?
<cjwatson> please ask don't ask to ask
<LocutusOfBorg1> kbuild... one single line
<LocutusOfBorg1> one fatal error changed to error, because otherwise virtualbox won't build with newer kernels, fixing also a debian RC
<LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/kbuild.git/commit/?id=0437af2183faedf5b9b065bc0910242afba1e53e
<LocutusOfBorg1> this is the bit
<cjwatson> LocutusOfBorg1: done
<LocutusOfBorg1> thanks!
<cjwatson> modulo queue and such
<cjwatson> LocutusOfBorg1: well I would have closed it, I was just waiting for the auto-accept
<LocutusOfBorg1> ops I though you didn't noticed the bug ;)
<cjwatson> I did although it would have been nicer if you had directed me to it
<LocutusOfBorg1> indeed, sorry for that, I wrote it today on #devel IIRC
<cjwatson> fairly little brainspace right now
<cjwatson> #-devel was the right place to ask really, just bear in mind that a lot of us are on US/Eastern time right now
<LocutusOfBorg1> ack ;) I asked on 9AM CEST lol
<LocutusOfBorg1> anyway thanks, I hope one day I'll be able to do the sync by myself, at least for packages I maintain :)
<infinity> cjwatson: The studio failure looks like an apt loop-breaking bug, but this is a rather inconvenient time for it to pop up.
<cjwatson> infinity: I couldn't reproduce it locally, so I've tried just mashing retry and hoping
<cjwatson> (It does, yes)
<cjwatson> infinity: I have unicorn SVGs.  Shall I mail you them (or indeed come up to the room and we can mess about with gimp)?
<infinity> cjwatson: Sure.
<infinity> cjwatson: Either of those things, or both.
<infinity> jibel: Did you file a bug for your qemu -vga std'
<infinity> jibel: ... issue?
<jibel> infinity, bug 1383851
<ubot2> bug 1383851 in linux (Ubuntu) "Cannot enter LVM encryption password in qemu with -vga std" [Medium,Confirmed] https://launchpad.net/bugs/1383851
<jibel> infinity, this one?
<apw> jibel, when you boot it in that mode, what do you see?  black screen?
<infinity> jibel: Yep.
<infinity> apw: You get the proper screen, it just seems "frozen".
<apw> jibel, actually come into my parlour
<infinity> apw: No amount of hammering the keyboard does anything.
<jibel> apw, you see the lvm encryption password prompt but cannot type anything
<jibel> apw, like it doesn't receive kb input at all
<infinity> jibel: Did you narrow it down at all between -17 and -22?
<jibel> infinity, not yet, I'm verifying latest images
<bdmurray> slangasek: https://bugs.launchpad.net/ubuntu-website/+bug/1384291
<ubot2> Launchpad bug 1384291 in Ubuntu Website "Ubuntu download thank you page links to documenation team information" [Undecided,New]
<pitti> infinity, cjwatson: what is the rough chance between "go away" and "yeah, fine" of uploading two fixes to autopkgtest which fixes running autopilot tests on phones?
<pitti> (not seeded anywhere)
<slangasek> pitti: since not seeded, the chance is somewhere in the middle
<pitti> slangasek: thanks, I'm taking that :)
<pitti> it's not really that important, in CI we'll need to run a backport anyway; but it's making things more convenient for touch devs on utopic
<Riddell> so if you folks are in washington, what's the ETA for release tomorrow?
<infinity> Riddell: No specific time set, but aiming for more or less our usual timeline adjusted for local timezone.
<infinity> Riddell: (ie: we shoot for noonish, with acceptable slippage into the afternoon and early evening, and see how we do)
<infinity> Riddell: There's always the hope (dream) that everything's ready on Wednesday and Thursday is just mindless button pushing, but... ;)
<Riddell> infinity: noonish on +5?
<infinity> Riddell: No earlier than noon on +5, I'd say, but definitely could be quite a bit later if the world doesn't go our way.
<infinity> Err, +5?  Wrong direction. :P
<infinity> We're in -0400 right now.
<infinity> And you're +1, so -5 total for your math.
<Riddell> infinity: gotcha, thanks :)
<knome> people should just use UTC...
<cjwatson> pitti: stuff not on images has a while yet, yeah
<pitti> knome: apply biiiig hammer to earth â no time zones any more
<knome> pitti, lol, worksforme
<elfy> I'm easy with timezones - would rather not see enormous hammer :p
<cjwatson> balloons: hey, so would there be a problem with a mass respin soon?  we have a new linux-firmware and a new ubiquity-slideshow-ubuntu, so would be good to get that lot through; there are some test results on the tracker
<balloons> cjwatson, I would rather see a respin sooner rather than later on this. I haven't checked the critical bug list yet this morning, so I'm not sure what's outstanding (in other words if another respin would happen or not)
<cjwatson> sooner> yeah so would we
<cjwatson> respin cycles are much faster now, an hour or two
<cjwatson> I see a few red bugs but (from a quick skim) I suspect they're mostly fairly long-standing installer issues, not something likely to be fixed in a respin at this point
<cjwatson> but second opinions welcome
 * balloons loos
<elfy> I'd look instead balloons
<balloons> elfy, :-)
<balloons> cjwatson, ack, I agree. Good, if that works out we're in good shape
<rcj> cjwatson, if you respin is needs to be very very soon.  cloud images will take > 14 hours
<cjwatson> yeah, I'm just going to get linux-firmware in
<cjwatson> you can start right after that I guess?
<cjwatson> oh we need d-i
<utlemming> rcj, cjwatson: actually if it only linux-firmware, it does not require a respin
<utlemming> rcj, cjwatson: cloud images don't ahve linux-firmware
<cjwatson> do they have debian-installer?
<utlemming> cjwatson: negative. However, it looks like the arm builds have it
<utlemming> cjwatson: for linux-firmware
<rcj> cjwatson, utlemming: I see a new linux-virtual in proposed, is that coming in too?
<rcj> cjwatson, utlemming: nevermind, wrong release.
<cjwatson> utlemming: ok, so do you need to respin just the arm ones?
<utlemming> cjwatson: we would have to respin everything, otherwise the serials are off
<cjwatson> ok, you should be good to go quite soon, linux-firmware is migrating as I type
<cjwatson> we're just waiting for argh why have I never QAed the faster apt-ftparchive
<cjwatson> (answer: because 19000 things to do)
<cjwatson> smb: your bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745717, which includes a workaround
<ubot2> Debian bug 745717 in di-utils "di-utils: fetch-url runs mountmedia without cleaning up; blocks partitioner preseeding" [Important,Open]
<smb> cjwatson, Ah yes.
<rcj> cjwatson, anything else or can I let the cloud publication begin?
<cjwatson> rcj: go go go
<rcj> cjwatson, thanks
<mdeslaur> infinity: can we get the owncloud package removed from utopic?
<mdeslaur> (and blacklisted so it doesn't get synced)
<cjwatson> robertk_: soooo close
<cjwatson> this will be tight but nearby
<infinity> mdeslaur: Do you have a bug for that?
<cjwatson> damnit amd64 hit a raid-card-less builder
<cjwatson> no wonder it took ages :-(
<mdeslaur> infinity: one sec, I'll open one
<mdeslaur> infinity: bug 1384355
<ubot2> bug 1384355 in owncloud (Ubuntu) "ownCloud should be removed from Utopic" [Undecided,New] https://launchpad.net/bugs/1384355
<infinity> mdeslaur: removed and blacklisted.
<mdeslaur> thanks infinity
<infinity> mdeslaur: A solution for trusty and precise would be nice, though.
<infinity> mdeslaur: Note that precise-updates has a (now old) backport, so someone was originally going the "just toss in the latest version" route.
<mdeslaur> infinity: yes, having someone update to the latest versions regularly would be ideal...perhaps someone on the list will step up
<robertk_> cjwatson: nice!
<cjwatson> yep it's there now
<cjwatson> depending on which cdimage mirror you hit, but will be there by the time IBM look
<cjwatson> robertk_: http://cdimage.ubuntu.com/ubuntu-server/daily/20141022.2/
<robertk_> thank you!
<Riddell> new images?
<cjwatson> updated linux-firmware, debian-installer, ubiquity-slideshow-ubuntu; was hard to get that lot in without respinning everything
<wxl> cjwatson: but we have had two respins today?
<cjwatson> though pretty minor changes so from your point of view should just need very quick smoke-tests if you already tested earlier iterations
<cjwatson> this is the second yeah
<cjwatson> AFAIK we should be done from here
<wxl> missed something in the first/
<cjwatson> yes
<cjwatson> I mean that goes without saying right? :)
<wxl> well yeah but i thought we had it done
<wxl> i don't remember balloons mentioning ubiquity-slideshow-ubuntu, though
<cjwatson> we did tell him today
<cjwatson> like I say should just require very quick smoke testing
<cjwatson> also nobody ever promised that the last respin was done, or if they did they were wildly optimistic
<wxl> hahahah okie dokie
<cjwatson> if you've already tested the previous version, just make sure that this one passes a quick install test or similar and call it good
<wxl> cool thanks cjwatson
<cjwatson> *already tested the previous version more thoroughly
<wxl> if only lubuntu desktop would hurry up already
 * wxl scowls
<cjwatson> shouldn't be long, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu/+build/9493 and https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu/+build/9498
<cjwatson> the estimates should be fairly plausible by this point
<cjwatson> then just the quick bit on nusakan
<wxl> oooh nice
<wxl> i didn't even know about that
<wxl> you are a plethora of wonderful info cjwatson :)
<cjwatson> most recent ones are linked from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu
<cjwatson> unfortunately panlong is one of the builders without a raid card (in progress, I filed the ticket four months ago but it's been stalled on hardware acquisition) so it's a bit slower
<cjwatson> but still should be quick enough, respins aren't an eight-hour proposition any more
<wxl> yes but having that estimated time is awesome
<wxl> even if it is slower XD
<Riddell> mdeslaur: security problems in owncloud?
<stgraber> Riddell: upstream asked for it to be removed due to security issues, yeah
<mdeslaur> Riddell: upstream wants us to remove the packages
<cjwatson> it's the median of the last nine successful builds, as an approximation
<wxl> not the mean, eh?
<cjwatson> I tend to prefer median for this kind of thing to reduce the effect of outliers
<cjwatson> though not a statistician
<Riddell> shame but fair enough
<wxl> cjwatson: is there a general non-release-specific link i can use to see build status or get to it?
<cjwatson> wxl: afraid not
<cjwatson> I didn't quite finish a proper livefs index in LP, maybe at some point
<wxl> cjwatson: same general layout, though?
<cjwatson> Yeah
<wxl> e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/codename/flavor
<cjwatson> Yeah
<wxl> cool thanks :)
<mvo> cjwatson: I can reproduce the bug now, thanks for your help with the buildlivefs
<cjwatson> mvo: oh fantastic
<cjwatson> wonder what the relevant different was
<cjwatson> *difference
<mvo> cjwatson: next thing is to get it into a state so that I can debug it, I am trying this now
<cjwatson> oh yeah buildlivefs possibly nukes it
<cjwatson> actually it shouldn't if you run it on its own
<cjwatson> only if run from the full launchpad-buildd state machine
<mvo> cjwatson: the chroot is still here, but I want the dpkg  status and /var/lib/apt/lists/* status before the apt-get operation starts
<cjwatson> right
<cjwatson> hack it to use a stunt live-build that has a big sleep in there maybe
<mvo> cjwatson: yeah, good idea
<wxl> cjwatson: the track is not updating despite the fact that amd64 is uploaded
<cjwatson> wxl: it'll get there, there's a final assembly stage
<wxl> cjwatson: ah ok
<cjwatson> logs of that are at http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/utopic/ but it's only updated periodically rather than cronned
<cjwatson> so unfortunately you can't see that live
<cjwatson> wxl: also, it's waiting for the i386 one to finish before it does the assembly
<wxl> cjwatson: that's interesting
<cjwatson> yeah I might have done this differently if I were writing the code from scratch but it's quite hard to disentangle now
<cjwatson> anyway will be less of an issue in this case once the buildd hardware is normalised
<mvo> cjwatson: "Dpkg::MaxArgs" defaults to 8k and "Dpkg::MaxArgBytes" to 32k - we can increase this for the failing build, I will also investigate now how to drive dpkg in a different way to avoid this limit entirely
<cjwatson> mvo: thanks!  infinity ^=
<infinity> mvo: Ta.
<mvo> infinity: it should be fine to multiply the current values by 4 - _SC_ARG_MAX is big enough (and the code is stupid *sigh*)
<infinity> mvo: Sure, just need to find a clever place to hack that in temporarily.
 * mvo nods
<elfy> cjwatson: I assume that if I'm happy with the testing we've done already - the newest respin just needs a check to make sure it doesn't do anything bad
<infinity> elfy: Yeah, pretty much.  Very few things changed.
<elfy> infinity: thought as much - just wanted to make sure I could get to bed tonight :D
<infinity> elfy: Check that we didn't accidentally break your slideshow (we didn't, but check), and that linux-firmware seems sane to you, and the usual boot/install/reboot smoketest.
<knome> infinity, i'm sure you put in pink unicorns in it :(
<cjwatson> elfy: right, smoke-test
<infinity> knome: I was going to, but didn't have time.
<knome> infinity, damn.
<knome> then it must've been somebody else
<infinity> mvo: configure-index.gz claims the defaults are much lower.  Is that out of sync with reality?
<elfy> pretty sure it's the same as it was - just the vbox issue and black try/install background we know about
<knome> elfy, and the pink unicorns!
<wxl> http://sixgun.org/files/utopic-unicorn.jpg
<elfy> that was last night knome
<wxl> i'm sure you've all seen that already
<wxl> but if not you're in for a TREAT
<cjwatson> wxl: wow
<infinity> wxl: I have... No words.
<wxl> hgahahahahah
<elfy> good lord
<knome> gosh
<wxl> seriously though i can't wait for unicorn shirts
 * knome was referring to http://temp.knome.fi/xubuntu/.pink-unicorns/slideshow.png though
<wxl> pretty cute
<knome> infinity, ^ that must've been you, eh? :P
<mvo> infinity: its out of sync, yeah
<mvo> infinity: thanks for letting me know
<infinity> mvo: Couldn't that be autogenerated somehow?
<infinity> mvo: And why doesn't "apt-config dump | grep DPkg" show those options at all? :/
<mvo> infinity: the configure-index.gz? maybe, yes.
<mvo>    unsigned int const MaxArgs = _config->FindI("Dpkg::MaxArgs",8*1024);
<mvo>    unsigned int const MaxArgBytes = _config->FindI("Dpkg::MaxArgBytes",32*1024);
<infinity> mvo: Alright, the code probably isn't lying. ;)
<mvo> infinity: the configure-index is not lying in git anymore now too
<stgraber> infinity, cjwatson: so core built fine this time but didn't publish because the build needs to be triggered using daily-live but the resulting artifact is daily-preinstalled and triggering and publishing from/to the tracker uses a single file
<stgraber> so the fix would be to make cdimage consistent then we should be good :)
<stgraber> until then we've got the choice between ability to trigger from the tracker or having the images publish there
<cjwatson> err that's weird
<cjwatson> it's daily not daily-preinstalled
<cjwatson> http://cdimage.ubuntu.com/ubuntu-core/daily/pending/
<cjwatson> daily-preinstalled is your stuff :)
<stgraber> oh right
<cjwatson> so uh yeah, that's going to be not quite trivial (maybe not hard, but not release day - 1 stuff) to disentangle, suggest just building by hand for now
<stgraber> still, same problem, triggered with daily-live, then we get:
<stgraber> No iso.qa.ubuntu.com product found for ubuntu-core/daily/utopic-core-powerpc; skipping.
<infinity> By hand works for me.
<stgraber> yeah, my plan once I'm done with my current meeting is to revert my change and just hardcode daily-live in rebuilt-triggers
<stgraber> which is ugly but will do the trick
<cjwatson> ok
<infinity> stgraber: As long as I have all my core builds in time to test them in the morning, that's good enough for me. :P
<infinity> It's not like they take more than a few seconds to validate.
#ubuntu-release 2014-10-23
<bluesabre> queuebot gets lazy too
<rcj> queuebot is processing all of the cloud images, you certainly don't want to see them listed :)
<rcj> cloud images are ready.  I'll be back before the sun comes up (10am UTC, 5am CDT)
<stgraber> infinity: have fun ^
<infinity> stgraber: Can't make me.
<Riddell> rebuilding kubuntu plasma5 for a fault in the login manager
<Riddell> kubuntu plasma5 working nice now
<cjwatson> Riddell: thanks for sorting that out and letting us know
<cjwatson> any other fires evident that you can see?
<Riddell> nope, kubuntu looking good
<cjwatson> great.  it's a bit early here but we'll be getting going in a couple of hours
<Riddell> groovy
<Riddell> I have 6 hours until need to go and play canoe polo, that's your target :)
<cjwatson> haha
<cjwatson> not totally sure about that.  do you have a delegate?
<apw> zequence, hey ... your "release notes" link is broken on your images ... the wiki page is missing
<zequence> apw: Thanks. Will check that out.
<apw> zequence, the good thing is it isn't an issue with the image :)
<stgraber> good, nothing scary appeared on the tracker overnight
<pitti> cjwatson: http://launchpadlibrarian.net/187964694/language-pack-af_1%3A14.10%2B20141020_1%3A14.10%2B20141020.1.diff.gz
<pitti> cjwatson: it's in the queue now; sorry about that
<cjwatson> pitti: what about the Replaces?
<pitti> ok, now it starts being really embarassing..
<pitti> ok, now grep doesn't have any -an stuff any more
<pitti> btw, queuebot AWOL?
<davmor2> pitti: no he is on holiday
<pitti> http://launchpadlibrarian.net/187965216/language-pack-af_1%3A14.10%2B20141020_1%3A14.10%2B20141020.1.diff.gz
<cjwatson> pitti: thanks
<cjwatson> (accepted)
<knome> fwiw, moved the xubuntu release announcement to http://xubuntu.org/news/14-10-release/
<knome> do i need to worry about changing this url somewhere except the release notes wiki pages?
<cjwatson> mlankhorst: is this mesa upload really for utopic final?  it seems ... rather late for a new upstream merge
<mlankhorst> cjwatson: just let it slide into -proposed, not final :P
<cjwatson> then it can wait until after release
<cjwatson> but that means it will require SRU paperwork
<cjwatson> it has no bug reference now
<mlankhorst> oh indeed, just reject it.
<mlankhorst> meant to link https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1384289
<ubot2> Launchpad bug 1384289 in mesa (Ubuntu) "mesa 10.3.1 required for mir" [High,Confirmed]
<cjwatson> ok, done
<apw> knome, i think infinity will need that for the announce email
<cjwatson> thanks
<knome> infinity, PING! i moved the xubuntu release announcement to http://xubuntu.org/news/14-10-release/ (to follow our usual format)
<Riddell> going out for lunch, sms or facebook message or whatsapp message if you need me
<cjwatson> Riddell: my understanding is that the agreement is that we won't be publishing Plasma on our side because of the extra PPA thing, but that you're welcome to do so on your side and make sure source is available etc.
<cjwatson> this seems like a good time to confirm that
<cjwatson> starting publishing shortly (obviously will take some time and will be a while after that until we actually release)
<jdstrand> is it ok to push something to utopic-security, or should I be patient for official release?
<jack_> infinity, hi, the release announcement of Ubuntu Kylin is here: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes/Kylin
<stgraber> jack_: are you guys testing i386 now?
<stgraber> nevermind, seeing results now
<jack_> stgraber, yes :)
<jack_> stgraber, everything is OK. Have a nice day and weekend. lol...
<stgraber> darkxst: are your images ready for release (not signed off yet)?
 * cjwatson taps fingers waiting for checksumming
<infinity> jdstrand: Wait until we are 100% positive no one's respinning an image, if it's seeded.
<infinity> jdstrand: If it's not seeded, you can still get it in the release pocket.
<infinity> jdstrand: Which package?
<infinity> jdstrand: Hrm, I don't see anything built for utopic in either of your PPAs.
<jdstrand> infinity: ah sorry
<jdstrand> infinity: openjdk-7
<jdstrand> oh, did I delete it? I might have accidentally last night. that would've been silly
 * jdstrand checks
<jdstrand> heh, yes I did
<jdstrand> infinity: ok, fixed. openjdk-7 in ubuntu-security-proposed
<jdstrand> infinity: I'm fine with waiting. I was planning on it, but I can never seem to remember if the images pull in -security when being built
<infinity> jdstrand: They pull in updates.
<infinity> jdstrand: Which ends up being the same thing, after the automagic copying.
<jdstrand> yes, true
<jdstrand> sounds like I should wait, which is fine
<infinity> jdstrand: Yeah, you won't be waiting long.
 * jdstrand nods
<cjwatson> utlemming: can you do your "Update the Cloud images" publishing bit from https://wiki.ubuntu.com/ReleaseProcess please, if that's appropriate?  I've done most of the cdimage side
<Odd_Bloke> rcj: ^
<cjwatson> if the contact has changed then please update the above wiki page :)
<rcj> cjwatson, it's utlemming and myself.  I'll update the page.  The cloud images are staged and ready to be made public.  Shall I start to make them public now?
<cjwatson> rcj: yes that should be fine at this point
<rcj> cjwatson, excellent.  we'll get it going.
<utlemming> cjwatson: our publication is going to take a bit longer than usual due to the new ec2 region that just launched.
<utlemming> cjwatson: as in launched 1hr ago
<cjwatson> utlemming: what kind of time do you think?
<cjwatson> rcj: thanks
<utlemming> cjwatson: actually I think it will be done shortly. I mistakenly assumed that it would push the new region. I'll add the new region post release.
<cjwatson> Riddell: (apparently I mean "statement of policy from us" rather than "agreement"; FWIW this also applies to the Ubuntu Core system-image thing)
<Riddell> cjwatson: ho hum, ok
<rcj> cjwatson, cloud images are public.
<cjwatson> thanks
<jibel> infinity, I finished screen reader tests on desktop. No critical bug found. I didn't test VMWare installation.
<Riddell> cjwatson: where are the source ISOs?
<cjwatson> Riddell: http://cdimage.ubuntu.com/releases/utopic/release/source/
<cjwatson> when that finishes syncing, apparently
<Riddell> cjwatson: but of kubuntu-plasma5 ?
<cjwatson> Riddell: we're not doing source images of your PPA
<cjwatson> that's your responsibility
<cjwatson> (your plural)
<cjwatson> was this not made clear?
<cjwatson> probably doesn't need to be an iso, you can just snapshot the PPA and then additionally refer to our source images
<Riddell> cjwatson: ok I understand now, will do
<apw> jamespage, let me know when you are done editing ... i have an xorg update to apply
<jamespage> apw, please go ahead
<cjwatson> Riddell: thanks
<apw> jamespage, done and thanks
<Riddell> darkxst: really? http://ubuntugnome.org/ubuntu-gnome-14-10-is-released/
<jibel> stgraber, shall we remove all the references to edubuntu from the release notes?
<stgraber> jibel: yes, we are LTS only now
<Riddell> um, internet died in washington DC?
<cjwatson> seems fine here but it's lunchtime
<cjwatson> they probably just closed their laptops
<cjwatson> (weirdos not using irc in screen ...)
<Riddell> :)
<skellat> That would do it
<Riddell> I'm going to walk home, back online shortly, sms me if problems http://jriddell.org/contact.html
<knome> Riddell, https://wiki.ubuntu.com/ReleaseProcess ?
<stgraber> knome: ?
<knome> stgraber, re: a #ubuntu-release-party question :)
<stgraber> ah, I had a feeling I was missing some context there
<Riddell> knome: maybe a bit too technical for what he wants :)
<knome> yeah, sorry for not bringing up the context
<knome> Riddell, i guess, but hey, at least it's what he's asking ;)
<knome> though yeah, i agree that it would be a nice to have a blog post about that written by a release team member :)
<infinity> jdstrand: Go ahead and do your security releases if you want, we're not changing anything else at this point.  Just make sure you're copying to the security pocket. ;)
 * cjwatson taps fingers for publisher
<jdstrand> infinity: thanks!
<Riddell> are we nearly there yet?
<cjwatson> tÃ¡
<wxl> did we not do any release notes about dropping amd64+mac?
<ogra_> Riddell, go to #ubuntu-release-party with that :P
<Riddell> it's pretty tame in #ubuntu-release-party this time
<ogra_> yeah
<knome> very tame..
 * cjwatson wonders if Scottish Gaelic is close enough to the above
<cjwatson> looks like it
<cjwatson> anyway, web content is pushing
<Riddell> Scottish Gaelic doesn't really have a word for Yes or No, one reason it's a bit nuts as languages go
<cjwatson> yes Irish is the same
<cjwatson> tÃ¡ = tha I think
<wxl> if we're not going to have anything in the release notes about amd64+mac dropping, i guess i need to put it in the lubuntu release notes
<wxl> anyone? bueller?
<cjwatson> wxl: it should be in the main ones.  stgraber is writing something now I think
<wxl> cjwatson: cool thx
<stgraber> added
<wxl> https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes ?
<cjwatson> t
<cjwatson> anyway release notes don't have to be done before announcement
<stgraber> oh, I probably should put it somewhere else than in the known issues
<wxl> i don't see it?
<wxl> i see a mention about ati/amd video
<stgraber> actually, can't think of a better spot :)
* cjwatson changed the topic of #ubuntu-release to: Released: Trusty 14.04.1, Utopic 14.10 | Archive: closed | Utopic Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<cjwatson> thanks all!  (proxying for infinity)
<wxl> stgraber: that's where i have put similar comments for lubuntu
<cjwatson> somebody who cares wanna go do #ubuntu-release-{announce,party}?
<wxl> they already noticed cjwatson :)
<Riddell> awooga!
<wxl> stgraber: i still don't see your comment on amd64+mac
<Riddell> thanks cjwatson, infinity
<stgraber> wxl: yeah, the wiki is acting weird... I see the text in edit mode but not when accessing the page
<cjwatson> wxl: they usually notice hours in advance, but still good to have an official thing if not already
<cjwatson> the archive isn't technically actually closed yet
<cjwatson> final publisher is still running with some override changes
<stgraber> and the wiki is mostly unresponsive for me now....
<cyphermox> everybody hitting the release notes...
<cjwatson> proposed-migration is stopped
<wxl> hey at least people read it :)
<cyphermox> I'm just guessing
<stgraber> wxl: try now?
<wxl> stgraber: done and well worded thank you!!
<stgraber> good
<ogra_> \o/
 * knome bows and thanks the release team once again
<elfy> thanks all
 * elfy is often late
<knome> tweeted
<knome> hmm, wrong channel..
<elfy> lol
<Laney> good to know
<knome> isn't it?! :)
<ogra_> its a unicorn !
<knome> ogra_, you're very correct sir
<ogra_> :)
<Symmetria> hrm, no update on www.ubuntu.com for the utopic downloads yet?
<rww> there is for me
<elfy> and me
<Symmetria> aahh there it is, hrm, just trying to figure out why the mrirors arent seeing any increase in traffic yet (and almost zero utopic hits)
<Symmetria> aahhh there we go :) it just kicked in on the mirrors, hard :)
<mdeslaur> congrats, release team!
<darkxst> stgraber, yes they were ready
#ubuntu-release 2014-10-24
<Logan_> lol, Vivid is already open?
<Logan_> that's a quick turnaround
<tumbleweed> not open yet, in freeze
<slangasek> stgraber: wat. https://wiki.ubuntu.com/UbuntuDevelopers?action=diff&rev2=94&rev1=93 :)
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.1, Utopic 14.10 | Archive: open | Utopic Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.1, Utopic 14.10 | Archive: open | Vivid Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<Riddell> our torrrent files are really the iso files
<Riddell> http://cdimage.ubuntu.com/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.torrent
<Riddell> anyone know anything about those files?
<Riddell> or maybe a task for sysadmins?
<cjwatson> I think possibly sysadmin screwed up cloudfront redirects?  They're fine on the master system
<cjwatson> cdimage@nusakan:~/cdimage/www$ file full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso*
<cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso:         # ISO 9660 CD-ROM filesystem data 'Kubuntu 14.10 i386              ' (bootable)
<cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.torrent: BitTorrent file
<cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.zsync:   data
<cjwatson> Can you wait a couple of hours until I'm in work properly and can track this down?
<Mirv> unity 7.2.3+14.04.20140826-0ubuntu1 for trusty has had the last verifications done a few days ago. all in all 30 days in -proposed.
<Riddell> cjwatson: I worked out that if you swap utopic for 14.10 in that torrent url it works so updated the website for that
<wxlS5> We don't have any products in the daily manifest. Is that something you guys take care of or is that a flavor job?
<teward> anyone on the SRU team I can poke/bother/annoy/question regarding a specific bug and whether or not it's even remotely SRUable?
<rbasak> teward: don't ask to ask, etc.
<teward> rbasak: true.  :P
<teward> bah i have to find the bug again
<teward> anyways, the default nginx configuration file has the SSL section commented out, but has SSLv3 in its ssl_protocols line for the example config.  While a lot of new users just uncomment those sections and use them as is, they usually don't change much there.  To that end, they open themselves up to the POODLE vuln.
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1383379 was the bug I filed for this
<ubot2> Launchpad bug 1383379 in nginx (Ubuntu Trusty) "nginx default config has SSLv3 enabled, makes sites using default config options vulnerable to POODLE" [Undecided,New]
<teward> sec team said to check with SRU team for Trusty and Precise as to whether it gets included or even addressed
<teward> (mdeslaur uploaded nginx to utopic that makes the change in the default configs, though, last minute, which was accepted)
<teward> looking for guidance on whether SRU team would accept or not.
<rbasak> One catch is that this will cause a conffile prompt when users pick up this update.
<rbasak> (if they commented the section out, then that constitutes a change that dpkg won't want to overwrite)
<teward> rbasak: +1
<teward> that is a consideration point
<rbasak> If a user doesn't already have SSL enabled (no conffile change), then I think the user is less likely to enable it in the future.
<teward> to that end, if the decision is to NOT support the upload, and make the bug "won't fix" or something, that's fine, I blogged about the issue
<teward> (and that's already aggregated on planet.u.c, and available to the world for recommendation of disabling SSLv3)
<rbasak> If the user _has_ enabled SSL (conffile change), then the user will get a prompt. Which may be a reasonable thing to do, except that the user won't have any hint of _why_ he has the conffile prompt.
<rbasak> (and the prompt will appear as just a change in a comment)
#ubuntu-release 2014-10-25
<ogra_> could someone re-score https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/9639 so that it wont sit for 7h
<slangasek> wgrant: ^^ could you help with ogra's request?
<wgrant> if i can find my laptop
<wgrant> ogra_: Done.
 * wgrant out
<ogra_> thanks !
<ogra_> can some archive admin please bump the score for https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/9645 and https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/9646 ...
<ogra_> stgraber, i think you will be the first one to land ... in case you see this ^^^ please bump them, this is an emergency rollback
<cjwatson> I'm here, one sec
<cjwatson> done
<cjwatson> (my flight doesn't leave until tomorrow)
<wxl-phone> When are we going to have daily builds?
<cjwatson> wxl-phone: I'll probably try to set them up before I leave for home tomorrow.
<wxl-phone> cjwatson: thank you sir!
<cjwatson> Daily builds should be on now for vivid, hopefully.
<cjwatson> (Untested; I'll let cron do the testing.)
<elfy> cjwatson: awesome and thanks :)
#ubuntu-release 2014-10-26
<cjwatson> Ah, I forgot to copy the livefs objects in LP
<cjwatson> Maybe I should script that since that's new process
<cjwatson> Scripted, run, and documented for next time
#ubuntu-release 2015-10-19
 * pitti NBSes the old linux-raspi binaries
<pitti> ^ disables apport for the final release and fixes the failing test case
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Beta 2 | Archive: final freeze, britney block in place | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<infinity> darkxst: If you upload, I'll be happy to review.
<davmor2> infinity: can you add the netboot tests for rc please
<infinity> jibel: ^-- You know how to add all those "fake" tests?
 * xnox lols at "fake"
<davmor2> infinity: jibel is travelling to get to bluefin,  I'll run the tests now and add the results after
<infinity> davmor2: Ahh, he's coming here today?  I couldn't remember.
<davmor2> infinity: yeah travelling to the airport now
<davmor2> infinity: that's why I asked you :P
<infinity> flexiondotorg: I'm not sure I understand your ubuntu-mate-meta "fix".  If there's a file conflict, fix the packages in question, rather than unseeding them, surely?
<darkxst> infinity, uploaded
<infinity> darkxst: No matching clutter for that mutter?
<infinity> darkxst: Oh, I guess they're not really tied together. I'm not braining well today.
<darkxst> infinity, no, this does not involve clutter
<darkxst> can do a 0day update for clutter though
<darkxst> insert ^sru
<infinity> jamespage: Around?
<jamespage> infinity, yes
<infinity> jamespage: Any ideas about the nova autopkgtest regression on ppc64el?
<infinity> adt-run [09:09:12]: test nova-compute-daemons: [-----------------------
<infinity> OK
<infinity> ERROR: NOVA-COMPUTE IS NOT RUNNING
<infinity> adt-run [09:09:45]: test nova-compute-daemons: -----------------------]
<infinity> adt-run [09:09:45]: test nova-compute-daemons:  - - - - - - - - - - results - - - - - - - - - -
<infinity> nova-compute-daemons FAIL non-zero exit status 1
<jamespage> oh joy
<infinity> jamespage: Seems pretty consistent over many re-runs.
<jamespage> lemme look in a bit
<jamespage> I would suspect a racey test that might pass everywhere else by accident
<jamespage> infinity, I'll get coreycb to take a look; I have a few things to sweep up before I have capacity today
<infinity> jamespage: It's holding back cinder and nova, would be nice if you get your Top Men to give it some analysis.
<jamespage> infinity, ack
<jamespage> infinity, is there a nice place to debug that failure? looks like its related to nova-compute-lxc on ppc64el
<infinity> jamespage: kelsey01, perhaps?
<infinity> jamespage: Depends on if you need root.
<infinity> jamespage: If you need root, I might be able to spin you a VM somewhere.
<jamespage> infinity, I need root really - vm would be good
<infinity> jamespage: Which ssh key?
<infinity> jamespage: ssh -p 6222 jamespage@10.245.64.15
<infinity> jamespage: *poke, poke* :P
<flexiondotorg> infinity, Morning.
<flexiondotorg> infinity, I am happy to fix the Compiz packages but I simply don't have the time this week.
<jamespage> infinity, sorry - electrician in today as well :-)
<flexiondotorg> infinity, So I'd like to unseed Compiz for armhf, since it is not essential (in fact useless for the Pi 2) at this point.
<jamespage> infinity, can I get root on that as well?
<flexiondotorg> infinity, Can you please update ubuntu-mate-meta for me?
<flexiondotorg> infinity, I can then build the Raspberry Pi 2 image so it is ready for 22nd Oct release day.
<flexiondotorg> infinity, And I'll submit fixes for Compiz after 15.10 is out.
<infinity> jamespage: You have root, check ~/sudo_password
<jamespage> infinity, gotit - ta
<jamespage> infinity, pitti: do the autopkg tests for ppc64el run inside a kvm? or is it container based?
<infinity> jamespage: It's lxc in kvm, I believe.
<jamespage> infinity, this might be the limitation - tests are working fine under just kvm
<infinity> jamespage: Except that armhf is also lxc, afaik, so that doesn't add up.
<jamespage> infinity, yeah - I was just looking for a correlation there
<flexiondotorg> infinity, Please can you let me know if you will be able to update/upload ubuntu-mate-meta?
<infinity> flexiondotorg: I can, yes.  I was just questioning the reasoning for it.  But it also doesn't matter if you want to drop compiz from armhf, so uploading.
<flexiondotorg> infinity, Many thanks!
<infinity> flexiondotorg: http://paste.ubuntu.com/12859967/ <-- Look right to you?
<flexiondotorg> infinity, Perfect!
<pitti> jamespage: the tests are running in lxc, yes; the  host is kvm
 * jamespage scratches his head
<pitti> jamespage: given the history on http://autopkgtest.ubuntu.com/packages/n/nova/wily/ppc64el/ the test is obviously racy, but I wondered if 7 failures in a row with the new version is just bad luck or a systematic problem
<jamespage> pitti, test is OK without LXC
<jamespage> pitti, I suspect that armhf might have the same problem - but fails slower that ppc64el
<pitti> http://autopkgtest.ubuntu.com/packages/n/nova/wily/armhf/ is much more green (although still a bit racy indeed)
<jamespage> pitti, I have a feeling that set of tests is going to behave like that under lxc
 * pitti runs it manually with shell'ing in
<flexiondotorg> infinity, Many thanks!
<pitti>    apt-get install -y nova-compute $daemon 2>&1 > /dev/null
<pitti>     if pidof -x nova-compute > /dev/null; then
<pitti> jamespage: ^ i. e. the postinst doesn't wait until it's actually started?
<jamespage> pitti, hmm - that might be it
<pitti> or it fails to start; not that easy to tell due to the >/dev/null
<pitti> jamespage: nova-compute-lxc might just fail under lxc sometimes?
<jamespage> it might
<jamespage> pitti, I think I'll drop the install re-direction that might give a clue
<pitti> jamespage: on the last 6 logs nova-compute-kvm is consistently working and -lxc is concistently failing
<jamespage> pitti, yeah - that might be race again
<jamespage> nova-compute-kvm will actually get installed via tests/control
<jamespage> so has longer to be present in the process listing
<pitti> jamespage: ah, due to it being the preferred alternative
<jamespage> yeah
<pitti> so if nothing fundamentally changed in teh last version, should we hint this so that it can land in the next rebuild?
<pitti> I guess this is a bit urgent
<jamespage> pitti, nova/cinder not on any images
<pitti> ah, good
<rtg> ssh gloin.kernel
<rtg> -EWRONGWINDOW
<coreycb> jamespage, hey, need anything?
<pitti> jamespage: yeah, seems to be a race indeed
<pitti> jamespage: after the test fails, nova-compute is running
<pitti> (for -lxc)
<pitti> # service nova-compute start; echo "STARTED"; pidof -x nova-compute
<pitti> STARTED
<pitti> (no pid)
<pitti> jamespage: ^
<infinity> tjaalton: Why has there been no attention to LP: #1507255 ?
<ubot2> Launchpad bug 1507255 in xserver-xorg-video-intel "Garbled graphics in Wily with Intel GMA4500 chip" [Undecided,New] https://launchpad.net/bugs/1507255
<ubot93> Launchpad bug 1507255 in xserver-xorg-video-intel (Ubuntu) "Garbled graphics in Wily with Intel GMA4500 chip" [Undecided,New] https://launchpad.net/bugs/1507255
<infinity> tjaalton: Looks pretty vile.
<tjaalton> infinity: the bug is one day old, first time I hear about it too
<infinity> tjaalton: Oh, fair point.  His mention that it's been happening for a while made me not check the date.
<pitti> jamespage: so my first gut feeling is that the start job is done when python runs, but that still needs to parse/read/run nova-compute and change its argv etc.
<pitti> jamespage: so maybe add a retry loop for 5 s or so?
<jamespage> coreycb, nah on this
<pitti> jamespage: testing a fix now
<jamespage> coreycb, hey - could you work the changes/uploads for the horizon upgrade issue we discussed on friday
<jamespage> coreycb, that will need an SRU as well - lets see if we can get that in before zul's stable kilo release work
<coreycb> jamespage, sure will do
<jamespage> pitti, a retry?
<pitti> jamespage: testing http://paste.ubuntu.com/12860302/
<jamespage> pitti, awesome ta
<flocculant> infinity: re bug 1507333 - the guy who reported that was also talking about corrupt icons - I'll ask him to grab the iso again - ftr I just installed with the same iso and was ok here
<ubot2> bug 1507333 in systemd "kernel panic during installation" [Medium,Incomplete] https://launchpad.net/bugs/1507333
<ubot93> bug 1507333 in systemd (Ubuntu) "kernel panic during installation" [Medium,Incomplete] https://launchpad.net/bugs/1507333
<infinity> flocculant: Corrupt icons too, could point to just dodgy hardware.  Which would explain a systemd segv that no one else sees.
<flocculant> infinity: yep - the guy is in our QA team, so if he'd seen that before I would know
<flocculant> unless it's broken recently ofc ;)
<flocculant> anyway - soon as I see him I'll ask him
<flexiondotorg> infinity, Do I need to request an unblock for ubuntu-mate-meta?
<infinity> flexiondotorg: Nah, I'll unblock it.
<flexiondotorg> Cheers.
<flexiondotorg> infinity, You in England?
<cyphermox> could someone please review console-setup and localechooser, once that is done we can rebuild d-i and ubiquity to ship the fixes on images
<infinity> pitti: Wasn't your last apport upload meant to fix the tests? :P
<infinity> flexiondotorg: Yep.
<flexiondotorg> :-)
<pitti> infinity: yeah, and now they fail for something completey different and unexpected; need to investigate
<infinity> pitti: \o/
<pitti> infinity: it did fix the test that was failing previously at least
<pitti> jamespage, infinity ^ should fix the ppc64el failure; it succeeded twice in a row  on wolfe (i. e. on the production platform)
<pitti> and also in local (amd64) LXC
<jamespage> pitti, thankyou
<pitti> well, I forgot to take out the extra "echo waiting..", but not a biggie
<pitti> if you care, I'll reupload
<pitti> it was meant to show me how many 0.1 s iterations it needs and that the loop is working
 * pitti self-rejects and reuploads
<pitti> infinity: btw, I uploaded and self-accepted postfix yesterday as that was holding up dpkg; I hope I didn't disrupt any freeze/image building with it
<pitti> but I figured we'd want that dpkg everywhere
<infinity> pitti: Nope, all good.
<infinity> pitti: Thanks for that.
<infinity> jamespage: Where does "manage.py" in openstack-dashboard-ubuntu-theme.postrm come from?
<infinity> jamespage: Pretty sure you can't rely on it being there during purge, only remove, if it's a package that one depends on.
<infinity> jamespage: And it's redundant to do it in both cases anyway.
<pitti> nova-compute-daemons PASS
<pitti> jamespage: ^ http://autopkgtest.ubuntu.com/running.html for nova/ppc64el \o/
<infinity> pitti: Huzzah.  Thanks.
<pitti> so I guess you might want to lift the freeze for nova and cinder?
<pitti> to not ship wily with the release candidates?
<infinity> pitti: Already done/doing.
<pitti> infinity: ah nevermind, Laney did it already
<apw> infinity, ^^ to fix the virtualbox provide snarfu ...
<infinity> pitti: Now if you can either fix apport or tell me I can ignore its broken tests, that would be lovely. :P
<pitti> infinity: I hinted it this morning already
<infinity> pitti: Oh, so you did.
<pitti> infinity: but I'll look at the tests ASAP of course (not today any more though, need to run to French class in 10 mins)
<davmor2> pitti: why take a french class, just hang around in here and get insulted by jibel, seb128 and cyphermox, you'll be fluent in no time ;)
<pitti> tout est cassÃ© ! merde !
<seb128> ;-)
<cyphermox> pitti: I tend to use a different wording, and not so much write that, just say it loud :)
<davmor2> hahaha
 * pitti n'apprend pas encore Ã  jurer
<cyphermox> (because I'm polite and stuff)
<davmor2> cyphermox: but I make you swear all the time :P
<cyphermox> davmor2: sure, but I don't swear when other peoples might hear it, because I don't want to subject people to it and sound like I'm always mad :)
<davmor2> cyphermox: I'm sorry you have another mode????
<cyphermox> you all seem to forget that next release d-i and ubiquity will default to fr_CA ;)
<cyphermox> ... or fr_QC, depending on how elections end today? ;P
<davmor2> cyphermox: is that like EN_US ie not quite French :P
<flocculant> ha ha
<cyphermox> seb128: thanks, your fix for ubiquity works -- I'll just use 50 instead so it's not too large for people with small screens.
<seb128> cyphermox, yeah, sorry I couldn't easily test so I picked a number ... thanks for testing/including ;-)
<cyphermox> np. we've been wanting to fix/rework this for a bit, make the detials more useful
<cyphermox> right now it's too small to be very readable, and if we make it larger it's as useless for large screens.
<cyphermox> s/large/small/
<seb128> right
<davmor2> infinity: weren't we dropping wubi.exe?
<infinity> jamespage: Should I worry about this vmware-nsx in the NEW queue that no one has ever bugged me about?
<jamespage> infinity, I suspect its been there so long its now bitrotted and will FTBFS
<jamespage> defer it until +1 opens...
<jamespage> I can always request a backport like I did early last cycle for a few other similar bits and pieces
<infinity> jamespage: Happy to reject it if there's no urgency.
<jamespage> infinity, fine with me
<flexiondotorg> infinity, Are you planning on respinning all the flavours again?
<infinity> flexiondotorg: Yeah, we've changed both installers, so $world will respin later tonight to pick all of that up.
<seb128> unsure if that's confirmed or just a problem for some users and how much of an issue it is but bug #1507245 and bug #1506502 looks like they are worth investigating a bit
<ubot2> bug 1507245 in ubiquity "Not all language support files are installed even 'if install updates' is selected during installation" [Undecided,New] https://launchpad.net/bugs/1507245
<ubot2> bug 1506502 in ubiquity "fcitx-mozc is not installed by default on Ubuntu 15.10" [Undecided,Confirmed] https://launchpad.net/bugs/1506502
<ubot93> bug 1507245 in ubiquity (Ubuntu) "Not all language support files are installed even 'if install updates' is selected during installation" [Undecided,New] https://launchpad.net/bugs/1507245
<ubot93> bug 1506502 in ubiquity (Ubuntu) "fcitx-mozc is not installed by default on Ubuntu 15.10" [Undecided,Confirmed] https://launchpad.net/bugs/1506502
<seb128> (trying a japanese install in a vm to see if I can confirm the issue)
<Laney> poor ubot93
<flexiondotorg> infinity, Thanks.
<seb128> bug #1506502 is confirmed
<ubot2> bug 1506502 in ubiquity "fcitx-mozc is not installed by default on Ubuntu 15.10" [Undecided,Confirmed] https://launchpad.net/bugs/1506502
<seb128> could be because  fcitx-mozc is in universe, does the language-selector code grab things from there?
<seb128> if not bug #1486772, the package needs to be seeded
<ubot2> bug 1486772 in gyp "[MIR] mozc" [Undecided,Incomplete] https://launchpad.net/bugs/1486772
<seb128> (the MIR is fix commited for mozc, the status reflect another component)
<infinity> seb128: It probably shouldn't.  But lemme look at the MIR.
<infinity> seb128: It should be seeded in live (and should be moved to main once it is).
<flexiondotorg> infinity, I've just noticed something weird.
<flexiondotorg> infinity, mate-sensors-applet is still in wily/proposed.
<flexiondotorg> infinity, This was synced weeks ago.
<flexiondotorg> infinity, Can you let me know why it is stuck there and how to move it on?
<cyphermox> flexiondotorg: isn't it on excuses?
<cyphermox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
 * flexiondotorg is looking now
<cyphermox> ^ fails to build on some architectures
<flexiondotorg> cyphermox, Which ones?
<flexiondotorg> cyphermox, It build in debian unstable/sid
<flexiondotorg> cyphermox, Can you request a rebuild?
<ogra_> Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
<ogra_> bad timing ;)
<flexiondotorg> https://packages.debian.org/sid/mate-sensors-applet
<ogra_> (that was likely the beta freeze that was in effect when you synced it)
<flexiondotorg> cyphermox, Can you unblock mate-sensors-applet please
<flexiondotorg> ogra_, Thanks.
<cyphermox> flexiondotorg: sorry, I can't unblock things, no permissions for that :)
<cyphermox> arf, but it's failing to build anyway
<flexiondotorg> infinity, Please can you unblock mate-sensors-applet
<flexiondotorg> OK, can you request a rebuild?
<infinity> flexiondotorg: Unblocking won't help.
<flexiondotorg> I have previously built it in a PPA to test it and it builds in Debian sid.
<infinity> flexiondotorg: It has build-deps that can't be satisfied.
<flexiondotorg> Where can I see this please?
<infinity> flexiondotorg: In the build log.
<infinity>  sbuild-build-depends-mate-sensors-applet-dummy : Depends: libxnvctrl-dev but it is not installable or
<infinity>                                                            nvidia-settings but it is not installable
<flexiondotorg> infinity, Yep, so I see.
<flexiondotorg> infinity, Thanks.
<infinity> flexiondotorg: In Debian, libxnvctrl-dev seems to exist on all arches, it's only on some in Ubuntu.
<flexiondotorg> infinity, So I see :-(
<infinity> flexiondotorg: So you probably want to arch-restict that build-dep, if it's optional.
<flexiondotorg> infinity, Incantation to that?
<infinity> [amd64 armhf i386]
<infinity> But that implies that dropping the build-dep doesn't break the package somehow.
<infinity> Which you might want to verify. :P
<flexiondotorg> infinity, It won't.
<flexiondotorg> infinity, configure will simply disable nvidia support if the build dep is missing.
<infinity> I feel like it might break the new mate-sensors-applet-nvidia package. :P
<flexiondotorg> infinity, Should I provide a debdiff?
<infinity> Or make it so useless that you should also arch-restrict that.
<flexiondotorg> infinity, Yep, arch restrict that -nvidia package too.
<infinity> And the nvidia-dbg package, obviously.
<flexiondotorg> Ordinarily I'd fix this in Debian and synv to Ubuntu, but no time for that.
<rsalveti> infinity: apw: uploaded a new dfsg rtl8812au, removing those files
<infinity> flexiondotorg: So, yeah, gimme a debdiff, I guess.
<jderose> infinity: i noticed that the 20151017.1 ISO didn't pass the automated testing... are you expecting to respin the ISO this week, or do you expect 20151017 to be the final?
<infinity> jderose: I'm respinning tonight after some bits of the archive settle.
<infinity> jderose: Which automated testing didn't pass?
<flexiondotorg> infinity, Sorry for the delay. Been reading bed time stories to my daughter.
<flexiondotorg> infinity, How does this look? - http://paste.ubuntu.com/12864333/
<infinity> flexiondotorg: Looks like it might work.  Did you test by fudging the arches and doing a local build?
<infinity> flexiondotorg: I can try that.
<infinity> flexiondotorg: (Also, your changelog indentation is wrong, but I'll fix that)
<flexiondotorg> Haven't done a local build, just wanted to make sure the ubuntu1 suffix was the right way to do things?
<infinity> flexiondotorg: Yup.
<flexiondotorg> infinity, OK. Do you want me to raise a bug?
<infinity> flexiondotorg: No.
<flexiondotorg> infinity, Thanks!
<infinity> flexiondotorg: I'm going to test this a bit here and then sponsor it if it seems sane.
 * flexiondotorg goes off to test PowerPC build for Ubuntu MATE and Lubuntu...
<infinity> flexiondotorg: Also missed running update-maintainer(1) (fixed).
<flexiondotorg> infinity, Thanks.
<infinity> flexiondotorg: Testing right now with s/amd64/powerpc/ so my amd64 build will omit those bits. :P
<infinity> flexiondotorg: Will upload if this DTRT.
<flexiondotorg> infinity, Thanks for your help. Let me know if you need me to do anything else.
<jderose> infinity: not sure what failed, i just noticed that the migration from pending to current didn't happen, and it was my understand that usually means the automated iso testing failed
<infinity> jderose: Fair point.  jibel's looking at it.
<jderose> infinity: jibel: thanks! :)
<flexiondotorg> infinity, Thanks ^^^^^^^^^^^^^
<jhodapp> I have a change to qtubuntu-media that will be published for wily shortly and I want to make sure it gets accepted into the wily release. It's a very minor package dependency change on a specific version of mediascanner (old version now) that mediascanner needs in order to not be blocked in proposed.
<jhodapp> Anyone with thoughts on the qtubuntu-media landing?
<jhodapp> the diff is here: https://code.launchpad.net/~phablet-team/qtubuntu-media/mediascanner-dependency-removal/+merge/274914
<flexiondotorg> infinity, Turns out that mate-sensors-applet is busted in Debian too.
<flexiondotorg> infinity, So I will fix it there too and it can synced for the 1604 cycle :-)
<infinity> jhodapp: Laney already fixed it hours ago.
<flexiondotorg> cyphermox, What options can I pass oem-config to get some debug/logging?
<cyphermox> flexiondotorg: debug-oem-config, I think. lemme look
<cyphermox> yeah, if you pass debug-oem-config on the kernel command-line it will start in debug mode; which is the same as starting it from the console with --debug
<cyphermox> what kind of information are you looking for?
<jhodapp> infinity, yeah he forgot to mention that :)
<jhodapp> infinity, but it's only a partial fix
<DalekSec> So has anyone asked sabdfl for the XX name yet, considering last release? :P
<jderose> flexiondotorg: so have you hit some issue with oem-config? please share, inquiring minds at system76 would love to know :)
<flexiondotorg> jderose, Nothing for you to worry about.
<flexiondotorg> jderose, I'm working on the Raspberry Pi 2 build.
<jderose> flexiondotorg: hey, that's always what i *want* to hear :P
<jderose> gotcha
<flexiondotorg> jderose, Which is a bit unusual because of the kernel.
<flexiondotorg> Got debug now.
<flexiondotorg> cyphermox, I'm trying to get oem-config working with my Raspberry Pi 2 build.
<flexiondotorg> I think the issue is related to that usual kernel I'm using.
<flexiondotorg> *unusual
<infinity> jhodapp: How is it only a partial fix?
 * infinity respins the world.
<ianorlin> althuogh oem-config on lubuntu uses the the unity slideshow but that is probably that there is not a lubuntu oem slideshow package
<cyphermox> ianorlin: no, I think there's just one slideshow for any oem-config.
<ianorlin> There actually is one for ubuntu mate for oem config but apt-cache search slideshow should show them if the package has a reasonable name
<flexiondotorg> cyphermox, ianorlin There is just one slideshow for owm-config.
<flexiondotorg> Something I'd like to change for 16.04.
<flexiondotorg> Or rather, oem-config support only one slideshow.
<flexiondotorg> ianorlin, Has spotted I tried to create one for Ubuntu MATE in the past.
<flexiondotorg> cyphermox, I've monkey patched oem-config to work with the Raspberry Pi Foundation kernel.
<flexiondotorg> cyphermox, No pretty, very specific. I doubt you want a real patch?
<cyphermox> well shoot what you have I can haz a look
<cyphermox> I'm not sleeping just yet.
#ubuntu-release 2015-10-20
<flexiondotorg> cyphermox, I really don't think this is going to be acceptable.
<flexiondotorg> cyphermox, It is a hack specific to the "kernel" from the Raspberry Pi Foundation.
<flexiondotorg> cyphermox, I'm trying to reduce it to just minimum changes required.
<flexiondotorg> It is not conditional right now. I'd prefer it to enumerate the system, determine it is a Pi kernel and then behave accordingly.
<flexiondotorg> I've also been forcibly modifying it to use oem-slideshow-ubuntu-mate.
<flexiondotorg> Which I'd like to make a general purpose modification so flavours can ship their own oem-config slideshow.
<davmor2> infinity, jibel: I'm not sure I got a reply yesterday but weren't we dropping wubi from the image?
<infinity> davmor2: We were literally JUST talking about that.
<davmor2> infinity: talk louder I can't hear you
<infinity> davmor2: WE WERE LITERALLY JUST TALKING ABOUT THAT.
<davmor2> infinity: I didn't say shout ;)
<Laney> wE wErE lItErAlLy JuSt TaLkInG aBoUt ThAt
<didrocks> no coffee at the office makes Laney writing in a weird capitalization :p
<infinity> There's a backup coffee machine.
<didrocks> ah, this week only one is broken, not the 2 of them?
<Laney> think so, but I haven't been that far
<Laney> the tea machine works :)
<didrocks> heh
<didrocks> 50% better than last week thus
<jibel> infinity, davmor2 is verifying of fix for bug 1507676 , do we want it in the release or 0-day SRU?
<ubot2> bug 1507676 in xserver-xorg-video-intel "Nvidia-Prime not switching from intel to nvidia leading to a black screen" [Critical,In progress] https://launchpad.net/bugs/1507676
<jibel> s/of/a/
<infinity> jibel: I have to respin to remove wubi anyway, so if it can be solidly verified, sure.
<jibel> davmor2, how much time do you need to verify tseliot's fix?
<tseliot> yes, either you get a black screen or you don't ;)
<davmor2> jibel: having issues with it just double checking now, seems to be locked to intel
<davmor2> tseliot: is there a way to double check it is using nvidia
<tseliot> davmor2: yes, dmesg, and /var/log/gpu-manager.log
<davmor2> tseliot: I open nvidia settings I select nvidia I log out, log back in, and nvidia prime option is still on intel
<tseliot> davmor2: yes, that's why I need the log. I need to see what's going on
<davmor2> let me try again and this time I'll reboot
<tseliot> maybe nouveau is loaded, and it won't let the system use nvidia
<tseliot> davmor2: if that doesn't work, try removing and reinstalling the nvidia driver, and finally rebooting
<davmor2> tseliot, jibel: so reboot and I now see the nvidia sections in nvidia-settings so I am on nvidia now, tseliot that means that it lies when it says log out to apply settings you need to reboot,  I assume that means that lightdm keeps x alive so the x session isn't restarted right?
<davmor2> tseliot: is that text something we can get changed?  I assume it is part of the nvidia binary so probably not right?
<tseliot> davmor2: a log out should be enough. I don't know what happened in your specific case (I needed that log). Lightdm does restart X. Can you try again now (switching and logging out), please?
<davmor2> tseliot: sure
<tseliot> BTW nvidia doesn't offer any such feature. That's something I created.
<davmor2> tseliot: and now it is working maybe just a glitch
<tseliot> davmor2: yes, it works fine here too
<davmor2> tseliot: oh I wonder if it needed to reboot for the fixed package and that was the issue,  I flipped between intel and back to nvidia with log outs and it is fine now
<tseliot> davmor2: oh, good point, that's it. It did need a reboot. I forgot to tell you
<davmor2> tseliot: mystery solved
<davmor2> jibel: I declare this fixored
<jibel> davmor2, good
<jibel> tseliot, can you upload to wily and we'll get it into the image, there'll be a respin soon
<tseliot> jibel: sure
<davmor2> tseliot: thanks dude \o/
<tseliot> davmor2: thanks for your help
<davmor2> tseliot: np's it's what I'm here for :)
<tseliot> jibel: uploaded
<jibel> tseliot, thanks
<davmor2> jibel: when is the new image spinning up then?
 * davmor2 it thinking I might just test memtest and stuff if new images are spinning
<jibel> davmor2, soon
<Laney> infinity: libnet-dbus-perl libx11-protocol-perl libxml-twig-perl libunicode-map8-perl libxml-sax-machines-perl libxml-handler-yawriter-perl libxml-xpathengine-perl libunicode-string-perl
<bluesabre> ^ small fixes that correct a startup crash and a runtime crash, confirmed by xubuntu qa team
<cyphermox> oh, cool, thanks
<cyphermox> bluesabre: is that the sudoers thing?
<bluesabre> cyphermox: yes
 * Laney looks
<bluesabre> thanks Laney :)
<Laney> tseliot: ^ unclean source package, could you re-upload please?
<Laney> You can use the same version number
<pitti> bluez: trivial and tested fix, but should not be important for images
<pitti> oh, nice anyway :)
<infinity> pitti: We have a respin anyway, so whatever.
<flexiondotorg> cyphermox, Regarding wubi. Take a look at this bug reported and the merge proposal linked within it.
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1471344
<ubot2> Launchpad bug 1471344 in wubi "The wubi.exe provided on the 15.04 and 15.10 install ISOs" [Undecided,New]
<cyphermox> flexiondotorg: I believe it's late for that, we just removed wubi.
<flexiondotorg> cyphermox, OK.
<flexiondotorg> Can you close that bug accordingly please/
<pitti> infinity: is someone already on the demotions on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<pitti> and more importantly, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has two cases which we must fix for the release, AFAICS
<infinity> pitti: Yes.
<cyphermox> flexiondotorg: I'll look in a bit, but currently focusing on maybe fixing a bug before respin
<infinity> pitti: The maas ones and the libgd-perl one?
<pitti> we could probalby ignore the recommends, but bug 1471476 and cmake-extras sound release-critical?
<ubot2> bug 1471476 in libimage-exiftool-perl "[MIR] libimage-exiftool-perl" [High,New] https://launchpad.net/bugs/1471476
<flexiondotorg> cyphermox, OK.
<flexiondotorg> Is the descision to remove wubi final and forever?
<pitti> infinity: i. e. someone alredy looks at the demotions, or yes these two MIRs are RC?
<flexiondotorg> If so, I can be the messenger.
<infinity> pitti: I just did all the demotions.
<infinity> pitti: The MIRs are RC, IMO, we need to hound people.
<infinity> pitti: The maas one is the only one that affects images.
<pitti> erk, that too indeed
<pitti> infinity: MIR requirements in bug 1415164 got ignored by the server team for half a year :(
<ubot2> bug 1415164 in slimit "[MIR] slimit" [Undecided,New] https://launchpad.net/bugs/1415164
<infinity> lamont: Lamaaaaaaaaaant.
<infinity> We really need to make britney component-aware, to push back on maintainers.
<infinity> Cause this should fail installability checks and not migrate.
<pitti> infinity: or the train, for that matter (libqtdbustest would be FTBFS in ubuntu)
<infinity> pitti: The tain should be enforcing components, I think people keep turning that flag off on the silos when I turn it on >:(
<pitti> infinity: anyway, I'm playing monkey and file a MIR for cmake-extras, and give the package some review
<infinity> pitti: Yeah, I think cmake-extras will probably be a no-brainer "does it have a subscribers?  kay, whatever, promote".
<infinity> pitti: The maas deps are far more concerning, IMO.
<infinity> pitti: libimage-thingajob-perl I'm not super concerned about either, but I'll get security to sign off when the US wakes up.
<pitti> infinity: right, there was concern about parsing images themselves rather than just wrapping a standard lib
<pitti> bug 1508000
<ubot2> bug 1508000 in cmake-extras "[MIR] cmake-extras" [Undecided,New] https://launchpad.net/bugs/1508000
<flocculant> tseliot: not sure if bug 1501041 is dupe of davmor2's one - but it appears to be close
<ubot2> bug 1501041 in nvidia-graphics-drivers "No visible display in ubuntu session when using nvidia drivers via nvidia-prime until screen goes to sleep, then waked up" [Critical,Triaged] https://launchpad.net/bugs/1501041
<infinity> pitti: Alright, have the security team alerted to angular and libwhosit-perl.
<infinity> pitti: c-m should clear out a fair bit after the next archive-reports run.
<ogra_> infinity, hmm, did you disable daily builds for snappy ?
 * ogra_ just noticed there were no wily images since the 17th
<infinity> ogra_: Might have.
 * ogra_ turns them back on 
<ogra_> done :)
<seb128> ogra_, speaking about snappy, is anyone going to fix the 1.6 ftbfs? we still have 1.5 in wily and a non building 1.6 in wily-proposed
<ogra_> seb128, Chipaca and mvo were looking into it yesterday i think
<ogra_> not sure aboout the outcome or if there is more needed
<chrisccoulson> can we use wily-security yet?
<davmor2> infinity, jibel: is the new image built yet?
<infinity> davmor2: No, still waiting on some installer fixes.
 * davmor2 looks at cyphermox and drums his fingers on the desk loudly
<jibel> tseliot, Laney rejected your upload, can you fix it an reupload?
<tseliot> jibel: sure
<tseliot> flocculant: it could be the same issue
<tseliot> Laney: weird, I don't see any pyc files here
<Laney> tseliot: see https://launchpadlibrarian.net/221757417/ubuntu-drivers-common_1%3A0.4.10_1%3A0.4.11.diff.gz
<cyphermox> davmor2: what did I do again?
<tseliot> Laney: so that means that those files are available in the original tarball too
<cyphermox> davmor2: I'm fixing the bugs you don't find! :)
<tseliot> but they differ
<davmor2> cyphermox: fixing is the issue they should be fixed already damn it ;)
<cyphermox> davmor2: I'll let you play with powerpc-ibm-utils next time :)
<Laney> tseliot: nah, diff's just not showing us the contents because binary
<davmor2> cyphermox: I'm not sure there is enough power in our house for one of those :D
<Laney> tseliot: compare http://launchpadlibrarian.net/221756239/ubuntu-drivers-common_0.4.11.tar.gz with 0.4.10
<cyphermox> davmor2: not sure I want one in my living room either. it must be loud.
<cyphermox> vvv grub-install? ta-daaa!?
<cyphermox> *grub-installer.
<lamont> infinity: wat!?
<lamont> oh.  maas.
<lamont> infinity: details and I'll sic someone on it
<infinity> lamont: Yeah.  Need traction on your ignored MIRs.
<infinity> lamont: I have the security team looking at angular.js, but angular's build-dep also needs a response from you guys, AFAICT.
<lamont> url?
<infinity> lamont: https://bugs.launchpad.net/ubuntu/+source/slimit/+bug/1415164
<ubot2> Launchpad bug 1415164 in slimit "[MIR] slimit" [Undecided,New]
<tseliot> Laney: .gitignore (which I didn't set), contains "*.pyc". Mystery solved...
<tseliot> Laney: re-uploaded. No trace of pyc files now
<Laney> ty
<lamont> infinity: anything more than the slimit one? (which I guess is blocking angular.js?)
<infinity> lamont: Just that, afaict.
<lamont> cool. just trying to start with a full scope. :/
<cyphermox> davmor2: find me a quick ubiquity bug I can fix to go with the rebuild for grub-installer?
<lamont> full understanding of scope, that is
<davmor2> cyphermox: the cursor changes to the grab icon before you can grab it in the slider for resize partition, how's that?
<cyphermox> yuck
<cyphermox> that's very yuck, probably not one I can done in a five minutes.
<davmor2> cyphermox: hahahaha
<davmor2> cyphermox: man you ask, I give and now you don't want it ;)
<cyphermox> yep, I'm picky.
<davmor2> cyphermox: how about this one then, If I run live desktop, install the binaries for wifi and intel, in ubiquity select install 3rd party drivers, the wifi and intel blobs are not installed?  Probably because ubuntu drivers doesn't detect there are drivers missing?
<davmor2> cyphermox: you're not going to want that one either are you
 * davmor2 pencils them in for 16.04
<cyphermox> davmor2: it's not the easy quick fix type I was looking for
<cyphermox> I'll just do the rebuild
<davmor2> cyphermox: I'm looking for some others but to be honest I only noticed the first because jibel couldn't move the slider so am playing around with it now, and the second because I just did it try on my xps 13 and got nailed by no network :)
<davmor2> cyphermox: see this is what happens when you have time on your hands because there is no point testing something that is being respun :P
<davmor2> jibel: ^ this is possibly the issue you hit, it's not that the slider doesn't move it is that the cursor changed to the slider one before you can actually click to slide
<infinity> davmor2: There's lots of point in testing images that are being respun.
<infinity> davmor2: The more bugs we fix in one iteration, the better.
<davmor2> infinity: and I found 2 just :P
<davmor2> cyphermox, infinity: are there any logs that would be useful for the last one.  I'm assuming it is because I installed the binary drivers in the live session so ubuntu devices isn't picking them up
<infinity> davmor2: So the driver one is that desktop->ubuntu-drivers->install, then ubiquity->3rd-party doesn't give you a sane result but, I assume, just boot-to-ubiquity, or desktop->ubiquity both work fine if you didn't to the drivers bit first?
<infinity> davmor2: Yeah, it would be exactly that.  ubuntu-drivers won't list them as needed if they're already installed.
<infinity> Actually, it does in some modes.  Hrm.
<davmor2> infinity: This is on the xps and I wanted to install the drivers in live desktop, so it went, try ubuntu, install drivers, connect to web, click on install, run ubiquity in the live session, select install 3rd party drivers, finish the install, new system has no wifi
<jibel> cyphermox, bug 1508060
<ubot2> bug 1508060 in ubiquity "Partioning fails if user reverts LVM partition created with the manual partitioner" [Undecided,New] https://launchpad.net/bugs/1508060
<infinity> davmor2: Yeahp.  It's the manual install bit that would have broken it.  Cause we get the install list from "ubuntu-drivers autoinstall" which then tells us which packages it installed.  Which will be none if you already installed them.
<infinity> davmor2: Fixable, but I don't think I want to touch that bit two days before release, it's potentially brittle.
<davmor2> infinity: hence pencilling it for 16.04
<infinity> davmor2: Worth a permanent spot on the release notes as a "don't do that, then" note until we fix it.
<infinity> davmor2: (ie: please add, with bug link, thanks)
<davmor2> infinity: yeap I'm just reproducing it now, and will add a bug after, are there any useful logs I can add to it to confirm the assumption though?
<infinity> davmor2: Nope, I just tested locally, it's quite obvious why it breaks.
<infinity> davmor2: Just less obvious how to fix it nicely.
<davmor2> infinity: oh sound okay I'll just write up a bug then
<cjwatson> mana/wg 51
<cjwatson> argh
<cjwatson> manamana
<ogra_> badipidipi
<cjwatson> Laney: urls of the form https://bugs.launchpad.net/bugs/bugtrackers/ubuntu-bugzilla/NNNNN
<Laney> https://bugs.launchpad.net/ubuntu/+bug/10727
<ubot2> Launchpad bug 10727 in ubuntu "Chosing Norwegian Installation" [Low,Fix released]
<davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1508063
<ubot2> Launchpad bug 1508063 in ubuntu-drivers-common "In a live session installing binary drivers, stops them from installing on the system" [Undecided,New]
<infinity> davmor2: Ta.
<infinity> jamespage: Did you not read the rejection message on the last horizon upload?
<davmor2> and cyphermox for you I present you with https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508086
<ubot2> Launchpad bug 1508086 in ubiquity "Cursor changes to slider mode before you are on the actual slider" [Undecided,New]
<cyphermox> weeee
<davmor2> cyphermox: sorry for the blurry pictures only I was holding a mouse still while taking them :)  poor excuse I know but it is as good as you are getting :)
<hallyn_> rbasak: pushed the cherrypick of netcf FTBFS fix to wily, fwiw
<rbasak> hallyn_: thanks!
<cyphermox> davmor2: reproduced it here
<cyphermox> but yeah, I blame gtk
<davmor2> cyphermox: also should you be able to move the cursor off the grab bar once you have it clicked?
<cyphermox> yesish
<cyphermox> it works if I kill ubiquity to start over, and go really slowly to catch the right pixels
<davmor2> so not to the far left and right of the screen then?
<cyphermox> at the far left or right of the screen?
<davmor2> cyphermox: grab the bar, and move it as far left as it will go and keep moving the mouse
<davmor2> to the left
<davmor2> cyphermox: it leave the bar and keeps going
<cyphermox> how cute.
<cyphermox> that's just gtk being gtk though
<davmor2> cyphermox: nice I still blame you though :P
<jdstrand> fyi, I did all the overrides for the juju component mismatches
<infinity> jdstrand: Was everything MIRed and happy?
<jdstrand> yes, I verified the remaining bits, commented in the bug, etc, etc
<infinity> jdstrand: There were some reds on the chart.
<infinity> jdstrand: Ahh, kay, cool.
<jdstrand> right, but that was just the timing of the report
<infinity> jdstrand: Looking forward to that node of c-m clearing up then, thanks.  Wasn't sure that would make it for release.
<jdstrand> sure, np
<jdstrand> yes, that node took some work, and I don't mean just this mroning :)
<jdstrand> morning*
<infinity> jdstrand: I suspect golang-race-detector-runtime might still want attention there.  It had no MIR (recommended from golang).
<infinity> jdstrand: But willing to ignore it if no one has the time too.
<jdstrand> let me look at it real quick
<Riddell> I get bug 1508075 in unity and kubuntu, means I can't install
<ubot2> bug 1508075 in ubiquity "crash during network setup in ubiquity wily" [Undecided,New] https://launchpad.net/bugs/1508075
<jdstrand> infinity: it looks fine to me
<jdstrand> infinity: I'll add a task and move it, etc
<infinity> Riddell: That log looks like it's from a unity session?  Not kubuntu?  I'm confused.
<infinity> Riddell: Oh, you get it in both.  I can't read.  Check.
<Riddell> infinity: right, I tested both and reported from unity
<infinity> Riddell: I like that your first terminal search was for 'konsole'. ;)
<Riddell> muscle memory :)
<infinity> Riddell: Do you still have the session?
<Riddell> infinity: no, although I can boot up a kubuntu one easily enough
<cyphermox> Riddell: was that in Try or in Install?
<infinity> Riddell: Did you happen to dist-upgrade the live system?
<Riddell> cyphermox: Try, using Install works fine (runs as root)
<Riddell> infinity: nope
<cyphermox> Riddell: ok, I couldn't parse that sentence on the bug.
<jdstrand> infinity: the component-mismatches looks funny now for juju. is that due to the report generation and the publisher run?
<infinity> jdstrand: It's cause you closed all the bugs but nothing's been published yet.
<jamespage> infinity, nope I got it second hand via coreycb
<infinity> jdstrand: Should clear up on the nest run.
<jamespage> so evidently I misheard
<jamespage> apologies
<jdstrand> ok. that is what I was trying to ask
<infinity> jamespage: I rejected it because calling binaries from your deps is wrong on purge, as you don't know if they're installed anymore when in a removed-with-conffiles state.
<infinity> jamespage: Furthermore, it's redundant to perform the same steps for both remove and purge anyway.
<infinity> jamespage: As purge implies remove first.
<infinity> jamespage: So you'll just be doing the same thing twice, and the second time isn't guaranteed to work.
<jamespage> infinity, so the action needs to happen in remove only
<infinity> jamespage: Yeahp.
<infinity> jamespage: Or, if there's conffile removal somewhere, it should happen in purge only.
<infinity> jamespage: But I think all your stuff was more remove-worthy, as things would be broken if you removed your binaries and didn't perform those cleanup steps.
<jamespage> infinity, ack
<flocculant> tseliot: I wondered so thought I would point it out :)
<tseliot> flocculant: the package has been accepted into wily, so you might want to give it a try when it lands
<flocculant> tseliot: it doesn't actually affect me so can't test that - I just saw it on the forum, then saw davmor and your discussion re the other one
<tseliot> flocculant: oh, ok
<utlemming> stgraber: can you populate "Wily Final" on clouds.qa.ubuntu.com?
<slangasek> infinity, cjwatson: wubi removed from 15.10, does this impact the autorun support on Windows?
<infinity> slangasek: By all accounts, the autorun didn't do much on >= 7 (or >= vista?) anyway, because of the new "what do you want to do?" dialog getting in the way.
<cjwatson> Possibly, but consensus seemed to be that the cure was worse than the disease
<infinity> slangasek: But yes, this removes autorun.inf, which ran wubi.exe.
<cjwatson> Er, cure == having wubi
<slangasek> ok
<flocculant> infinity: sorry to bother - did I read ^^ a rebuild coming due to d-i and ubiquity?
<infinity> flocculant: Yeah.
<flocculant> infinity: ok - thanks - we were expecting to do one for us - but I think what was expected has turned up so will make it in the global one :)
<infinity> flocculant: What package were you waiting on?
<flocculant> catfish
<infinity> Riddell: We can't reproduce that ubiquity/wireless/NM thing here. :/
<flocculant> but looks like 1.3.3-0ubuntu2 on http://changelogs.ubuntu.com/changelogs/pool/universe/c/catfish/catfish_1.3.3-0ubuntu2/changelog
<Riddell> infinity: I see other testers are ok too, so it may just be me
<Riddell> thanks for trying
<coreycb> infinity, is this ok? https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/horizon/tree/debian/openstack-dashboard-ubuntu-theme.postrm
<cyphermox> Riddell: still going to try kubuntu now, for kicks
<cyphermox> I couldn't reproduce it on Ubuntu
<jibel> cyphermox, bug 1508121
<ubot2> bug 1508121 in ubiquity "fcitx-mozc has missing files" [Undecided,New] https://launchpad.net/bugs/1508121
<jibel> Laney, ^
<infinity> jamespage: Looks less sketchy, yeah.
<jamespage> coreycb, ^^
<coreycb> infinity, thx
<infinity> Riddell: cyphermox made it crash.  Somehow.  He's looking harder.
<flexiondotorg> cyphermox, I don't know when this started working. But if I installed oem-config-slideshow-ubuntu-mate before preparing an OEM install. The Ubuntu MATE Slideshow work correctly during the oem-config-first :-)
<flexiondotorg> cyphermox, So, the question is.
<flexiondotorg> Can it be included in the live seed?
<infinity> flexiondotorg: ... really?  I didn't think there was any code to handle that.
<infinity> flexiondotorg: Oh, was it changed to just install files to the same paths?
<flexiondotorg> infinity, No idea on the first. I looked at the code and thought it should work.
<flexiondotorg> infinity, Don't think the oem-config path was ever changed.
<flexiondotorg> Anyway, I have a patched oem-config working on the Pi 2 build with slidshow :-)
<flexiondotorg> Also tested the slideshow on PC too.
<flexiondotorg> Only drawback is that package is not autoremoved.
<flexiondotorg> I have patched my Pi 2 version so it does remove it.
<flexiondotorg> Anyway, maybe for 16.04 now.
<flexiondotorg> But a simple heuristic to detect the DE and then appropriate oem slideshow can be installed/removed.
<jibel> davmor2, what is the bug # for the missing binary drivers after install again?
<davmor2> https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1508063
<ubot2> Launchpad bug 1508063 in ubuntu-drivers-common "In a live session installing binary drivers, stops them from installing on the system" [Undecided,New]
<davmor2> jibel: ^
<jibel> thanks
<infinity> flexiondotorg: The autoremoval should be trivial to fix in ubiquity.
<flexiondotorg> infinity, Indeed.
<infinity> flexiondotorg: Oh.  But not completely trivial.
<infinity> flexiondotorg: So, yeah, let's do it for 16.04 Alpha 2.
<flexiondotorg> infinity, Yep.
<infinity> flexiondotorg: Not terribly comfy with the three places this looks to need abuse.
<flexiondotorg> Just need a method to determine the DE and store that as an attribute.
<flexiondotorg> Then add a few conditional statements about the place.
<cyphermox> pitti: you still around?
<cyphermox> pitti: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1508075 may be up your alley; looks like some weirdness in how polkitd gets started for ubiquity, but I can only reproduce it once every second try or so; I put details on the bug.
<ubot2> Launchpad bug 1508075 in policykit-1 "crash during network setup in ubiquity wily" [Critical,Confirmed]
<tsimonq2> hey, when are the rebuilds going to happen
<wxl> i hear talk of a world rebuild?
<tsimonq2> yeah, that is what I am asking about
<tsimonq2> Does anybody have an answer to the question of when the *World* *Rebuild* will be?
<infinity> Respinning the world, FYI.
<wxl> aw why for infinity ?
<infinity> wxl: Installers all got rebuilt.
<wxl> just ubiquity i'
<wxl> m assuming, infinity ?
<infinity> wxl: And d-i.
<wxl> aw fooey.
<tsimonq2> infinity: When will the new ISOs be released?
<wxl> tsimonq2: watch the tracker
<tsimonq2> wxl: the QA tracker?
<tsimonq2> ?
<wxl> tsimonq2: yep. they're not rebuilding yet, but they will be and you'll see (rebuilding)
<infinity> tsimonq2: They'll start building shortly, and will pop up over the next couple of hours.
<tsimonq2> infinity: How do I know what is building?
<wxl> tsimonq2: "(rebuilding)"
<wxl> tsimonq2: for lubuntu we'll have version 20152020
<tsimonq2> wxl: umm where are you seeing this?
<wxl> you will see it on the iso tracker when it happens, tsimonq2. as always with you, learn patience
<infinity> Rebuilds in progress now.
<wxl> you going to make an announcement by email infinity ?
<infinity> wxl: Nope, I'll probably sleep.
<wxl> infinity: good night sweet prince XD
<jderose> not sure if it just takes a while for them to be regenerated, but the zsync files in http://cdimages.ubuntu.com/daily-live/pending/ are stale... they're still the zsync files from yesterday's builds
<tsimonq2> ping infinity, wxl ^
<jderose> tsimonq2: thanks :)
#ubuntu-release 2015-10-21
<pitti> cyphermox: hm, do you have an actual .crash file report with a backtrace?
<Logan> sorry about all the last-minute uploads/syncs, trying to fix a lot of those rebuild FTBFSes :P
<pitti> Laney: rejecting one of your duplicate stsci.distutils syncs, don't get confused
<pitti> Laney: sorry, not you
<pitti> Logan: rejecting one of your duplicate stsci.distutils syncs, don't get confused
<Logan> oh yeah, my bad for requesting twice
<Logan> I thought it didn't go through the first time
<Logan> (Launchpad email notifications still leave something to be desired)
<pitti> cyphermox, infinity: in case you pung about bug 1508075, I just followed up
<ubot2> bug 1508075 in policykit-1 "crash during network setup in ubiquity wily" [Critical,Confirmed] https://launchpad.net/bugs/1508075
<pitti> infinity: can you test core arm64 and powerpc? I tested the others, but I don't have root access to these arches
 * pitti goes to test ubuntu desktop i386
<pitti> hm, can someone confirm that ubuntu i386 desktop live session is stuck? I see the background pic and nothing else
<pitti> both with default qemu vga driver and -vga vmware
<pitti> everything is okay on amd64
<smb> pitti, in a VM?
<pitti> yes
<smb> pitti, use kvm64 cpu type
<pitti> that has never been necessary -- is that some kind of mesa regression or so?
<pitti> smb: "64" for 32 bit ubuntu?
<smb> default is qemu64 which is an odd enough type to break llvm-pipe
<pitti> ah
<smb> pitti, and yes theat is "known" to people since dunno Trusty?
<smb> pitti, at least when you ask them
 * pitti searches for an existing bug
<smb> pitti, give me a sec and I could tell you
<pitti> smb: thanks
<smb> pitti, one at least is bug 1448985
<ubot2> bug 1448985 in qemu "llvmpipe i386 crashes when running on qemu64 cpu" [Medium,Confirmed] https://launchpad.net/bugs/1448985
<pitti> smb: cheers, I'll add that to the tracker
 * pitti links that in the tracker result, so that it appears in the future
<smb> pitti, np. Spent hours to understand that one and then Adam came and told me "oh yeah we know that" :-P
<pitti> smb: I remember that I had to change -cpu in autopkgtest to get around that
<flexiondotorg> cyphermox, We've found the the Deja Dup plugin for Caja has a namespace collision, so doesn't work anymore.
<flexiondotorg> cyphermox, I've spoken with the developer (who is on the Ubuntu MATE team).
<flexiondotorg> He is not available until much later today.
<flexiondotorg> But is happy for me to provide and updated debdiff and tarball.
<smb> pitti, ah right. Yeah either core2duo or kvm64 is ok. Only qemu64 is modeling some weird athlon with virt-extensions that never existed as real hw. And my guess is llvm-pipe assumes some things either from cpuid or id name which does not hold true when running the assembly code for it. Unfortunately the llvm-pipe error message is rather useless. At least to me
<flexiondotorg> cyphermox, Does that sound like a good way to proceed?
<pitti> smb: right, that rings a bell; I just used -cpu host for now
<smb> pitti, yup, that should work as well.
<smb> pitti, ok, fwiw I also did a quick install on an old netbook, so i386 desktop iso via life session and then install. Not sure the final reboot really got stuck with a black screen there as well or I am just getting too impatient in my old days. three finger salute did finish things...
<cyphermox> flexiondotorg: sorry, what does that mean? you'd need a respin?
<cyphermox> flexiondotorg:  I think it probably should be a SRU at this point
<cyphermox> flexiondotorg: I'll go back to my "I'm not in the release team so my opinion doesn't matter much, you could argue with them" cop out, but I think it's better to SRU the fix at this point, especially when it's "just" for dejadup.
<pitti> ^ FWIW, sounds sensible
<pitti> aside from that, it sounds we need a respin for Kubuntu for the kwallet-kf5 thing, right?
<flexiondotorg> cyphermox, No respin required.
<flexiondotorg> cyphermox, Just an upload.
<flexiondotorg> cyphermox, OK, SRU it is.
<pitti> flexiondotorg: oh, it's a package which isn't on teh images? which package is that?
<flexiondotorg> infinity, Are the images getting spun again?
<seb128> bug #1502821
<ubot2> bug 1502821 in usb-creator "usb-creator-* fails with message cannot install bootloader" [Undecided,New] https://launchpad.net/bugs/1502821
<pitti> flexiondotorg: likely, yes
<flexiondotorg> pitti, It is seeded, in Ubuntu mATE only.
<seb128> states
<seb128> "it looks for files into directory /usr/lib/syslinux/ but (in ubuntu Wily) the correct path is
<seb128> /usr/lib/SYSLINUX/"
<pitti> flexiondotorg: then it needs a respin
<seb128> ^ that might be something to fix for release?
<flexiondotorg> seb128, OK, I'll prepare a debdiff.
<pitti> we'll need a respin for bug 1508075 and for  the "ubiquity decorations are wrong" thing that seb128 was looking into
<ubot2> bug 1508075 in udisks2 "ubiquity and others time out on polkit (killed by udisks2-inhibit)" [Critical,Incomplete] https://launchpad.net/bugs/1508075
<seb128> flexiondotorg, for usb-creator?
<pitti> smb: I get the shutdown screen with "remove install media and press enter" all the time, hmm
<pitti> smb: we fought with that during the vivid release sprint
<seb128> Laney, ^ you said you would be interested to fix usb-creator issues? ;-)
 * pitti claims the "first mandatory green 9/9" flag for desktop i386
<infinity> flexiondotorg: As pitti says, we have a couple of bugs we'll probably respin for, assuming fixes happen.
<infinity> The only one I consider RC is the polkit thing.
<infinity> pitti: If there's any help you can lend on the polkit bug, more brains are better.  Even German ones.
<flexiondotorg> infinity, Thanks. I'll not burn another PowerPC DVD just yet then ;-)
<pitti> infinity: was just talking to cyphermox; I asked him to test an idea which has a pretty good chance to succeed
<infinity> pitti: \o/
<pitti> infinity: but I can't reproduce the hang on any of my three platforms, so I need some testing help
<seb128> anyone who knows about syslinux and want to comment on the usb-creator issue just mentioned?
<seb128> like did the path change and on purpose?
<infinity> seb128: If you can hunt down mdeslaur, he touched usb-creator in funny ways this cycle.
<infinity> seb128: As for paths changing, check the Debian maintainer field. :P
<seb128> infinity, he's probably still sleeping
<pitti> infinity: I'd like to sync https://tracker.debian.org/news/720214 once it's imported into LP, to mop up some small fixes (most importantly, fix backportability to trusty)
<infinity> pitti: It's not seeded, I'm fine with that.
<pitti> infinity: and fixing the "prepare VM" scripts to give a working minimal VM again (lxc/lxd was added very late)
<pitti> infinity: ok, what I thought
 * pitti sighs at cloud images carrying more and more unnecessary stuff
<cyphermox> it's ever so slightly less worse, but still tends to be racy
<infinity> seb128: /usr/lib/syslinux is in syslinux-common, BTW, not syslinux.
<pitti> cyphermox: still getting timeouts?
<cyphermox> yes
<cyphermox> seb128:  usb-creator was correct, and working fine this cycle unless something changed recently
<cyphermox> aside from issues if there's an architecture mismatch
<seb128> cyphermox, it fails to create the bootloader for me and I found that but with the details I just copied
<seb128> testing if changing syslinux to SYSLINUX fixes it
<cyphermox> well, it might if you have that path, but I think it would be good to know why it didn't find the other path
<seb128> which one?
<pitti> cyphermox: ok, thanks for testing; it was worth a try, although I still don't quite understand this
<flexiondotorg> infinity, I need a respin. Allegedly.
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1505505
<ubot2> Launchpad bug 1505505 in ubuntu-mate "ubuntu-mate-desktop does depend on vlc-plugin-pulse but that got removed" [Undecided,New]
<flexiondotorg> infinity, I'll update the seeds in a sec.
<cyphermox> seb128: syslinux-common
<seb128> cyphermox, infinity, Laney, in fact the path seems correct on disk, maybe that user has a local problem. My bug was because I picked an amd64 iso on a 32 bits machine I think, sorry about the noise :-/
<infinity> seb128: It's just a missing dep.  We'll fix it here.
<infinity> seb128: Just needs to depend on syslinux-common.
<seb128> infinity, thanks
<flexiondotorg> infinity, Can you update ubuntu-mate-meta please?
<flexiondotorg> Can someone please sponsor this update please? https://bugs.launchpad.net/ubuntu-mate/+bug/1508353
<ubot2> Launchpad bug 1508353 in deja-dup-caja "deja-dup-caja plugin has a namespace collision in Ubuntu MATE 15.10 [debdiff]" [Undecided,In progress]
<pitti> cyphermox, infinity: ok, give me some time for this; at this point we need an unintrusive and small fix, teaching polkitd about SIGHUP doesn't sound like that. I'll try some other things first
<cyphermox> no, it's not unobtrusive enough
<cyphermox> but I think your systemctl try-restart is the best we have right now
<pitti> cyphermox: I thought that still leads to timeouts, and thus is useless?
<cyphermox> I'm going to try it some more, see if it's good enough to get us something that looks good
<cyphermox> it does sometimes lead to timeouts, but it's better than it was
<cyphermox> and my testing method isn't exactly what people usually do - starting and stopping and restarting ubiquity repeatedly
<pitti> unfortunately polkit doesn't support /run/polkit-1/localauthority/
<pitti> on the live system we don't actually need the bind mount though, but I would be surprised if inotify worked on aufs
<pitti> anwyay, that's part of "I'll try some things"
<infinity> Riddell: You around?
<infinity> Riddell: If so, can you try pitti's workaround for this bug, since you reproduce it better than anyone?
<pitti> not that important really, as it'll just a bit less bad, but still not "good"
<pitti> I have about three ideas which I'm currently testing
<infinity> pitti: If "less bad" is the best we can do, it's still better. :/
<infinity> pitti: But, yeah.  Goodest would be more gooder.
<infinity> pitti: The live system is overlay, not aufs, and inotify definitely doesn't work. :P
<pitti> infinity: I'm currently testing that, but that's what I was afraid of
<infinity> pitti: In fact, it's actively broken, which is even worse than not working (as in, the FS claims to support it, then does nothing useful when you hook into it).
<pitti> I have a solution which works on my installed sytesm
<pitti> hm, it actually does trigger, curious
<pitti> sudo G_MESSAGES_DEBUG=all /usr/lib/policykit-1/polkitd -r
<pitti> sudo touch /var/lib/polkit-1/localauthority/90-mandatory.d/foo.pkla
<pitti> -> polkit reacts (that's on a live system)
<pitti> not expected (but would be nice indeed)
<pitti> pkcheck -a org.freedesktop.udisks2.filesystem-mount -p $$; echo $?
<pitti> that should be 0 for normal mode, and 1 for inhibited mode
<pitti> anyway, I still have another idea, let me test/prod more
<pitti> cyphermox: can you reproduce that with ubiqutiy under the live system? i. e. where it's non-agonizing to downlaod/update a file?
<pitti> Riddell: ^
<infinity> pitti: Is that path an overlay, or a tmpfs?
<cyphermox> pitti: of course
<pitti> infinity: it's on teh normal overlayfs
<infinity> pitti: Huh.  Then something's polling manually, cause inotify definitely doesn't work on overlay. :P
<pitti> cyphermox: ack, I should have a new udisks2-inhibit for testing then
<cyphermox> pitti: what what?
<cyphermox> pkcheck I didn't try
<pitti> cyphermox: I mean, in 5 mins, sorry
<cyphermox> I just rebooted
<cyphermox> your systemctl try-restart fix looks sufficient
<cyphermox> it helps if one changes both kills, for sure.
<pitti> infinity: it does use inotify,confirmed in strace
<cyphermox> now, to run all this in a vm so I can actually complete the install and make sure things work correctly
<pitti> cyphermox: the second kill is only when ubiquity finishes, though
<cyphermox> sure
<cyphermox> but that's *why* I said it wasn't quite there
<pitti> cyphermox: oh, you only got hangs on the second restart?
<pitti> ah
<cyphermox> if it gets killed, it hangs on second starts or NM might not have a polkit ready
<pitti> right, *if* the restart helps, then it needs to go to both places
<cyphermox> looks good so far
<infinity> pitti: Then I question that it's on overlay, unless someone fixed that in the last 6 months, but... Kay.
<infinity> pitti: (I could have sworn I saw a weird polkit related mount in my last live session)
<pitti> infinity: yes, you did
<pitti> infinity: it *currently* doesn't rely on inotify, but it seems it actually works now
<pitti> infinity: perhaps since the new version that landed in the upstream kernel (remember we had to change casper and everything for the new syntax)
<infinity> pitti: Oh, actually.  It might be that it works for new files, but not changed files or something.
<apw> overlayfs and inotify, i'd be epically supprised if it works reliably
<pitti> infinity: right, but that'd be sufficient
<infinity> pitti: Yeah.
<pitti> new file and rm seem to work
<pitti> (repeatedly)
<pitti> i. e. it seems to work for dirs, but not files
<pitti> (changing files does *not* work, I tested)
<infinity> New files are new inodes, changed files don't change the inode with the watch on, but instead give you a new inode and the world explodes.
<apw> pitti, right because directories are a thing at the overlayfs level, files arn't, they exist in the real filesystems but your watches are not in the right world
<infinity> apw: I still think the fix for that is just to copy-up when a watch is added, and attach the watch to the copy.
<infinity> apw: Bit of a waste of space, but would be reliable.
<pitti> new udisks2-inhibit works locally; /me tests it on live system
<apw> infinity, except it is more complex in that there are are three places and you are in the thrid one, i have patches which
<apw> make overlayfs a consumer of inotify on the files it uses from the lower layers, and propogate them to the real upper watches
<pitti> \o/ works fine
<infinity> apw: Three?  Doesn't the inode on the combined filesystem either match the underlay (before a copy-up) or the overlay (after a copy-up), so there's really only two options?
<cyphermox> pitti: how new is it?
<pitti> cyphermox: sorry, how new is what?
<infinity> apw: Oh.  I guess I'm nothing thinking of multiple layer cases.
 * cyphermox has been testing systemctl try-restart in an install now
<apw> but they are invasive, and they don't fix the issue that there is no way to represent copy up itself
<cyphermox> how new is your udisks2-inhibit?
<apw> infinity, the third place is the overlayfs inode, which doesn't exist per-see but does from a notify point of view
<flexiondotorg> infinity, Can you update ubuntu-mate-meta please?
<cyphermox> flexiondotorg: do you have your caja fix too?
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu-mate/+bug/1508353
<ubot2> Launchpad bug 1508353 in deja-dup-caja "deja-dup-caja plugin has a namespace collision in Ubuntu MATE 15.10 [debdiff]" [Undecided,In progress]
<pitti> infinity, cyphermox: attached the kill-less inotify scrip to the bug
<infinity> flexiondotorg: I can do your meta update.
<flexiondotorg> infinity, Thank you!
<infinity> flexiondotorg: I wouldn't recommend a rebuild until we sort this ubiquity thing, since I have to rebuild everyone for that anyway.
<flexiondotorg> infinity, Understood.
<pitti> cyphermox, infinity, Riddell: I attached both variants to the bug now
<infinity> flexiondotorg: Is there a bug number for this meta update?
<infinity> flexiondotorg: Ahh, found it.
<pitti> it's a "pick your poison" decision: the inotify one relies on overlayfs and might leave dangling symlinks behind if you actually use that in a real system, and the restart one might break pending calls to polkit (but not existing connections any more, which is the bug here)
<pitti> I actually have a better solution in mind using temporary udev rules (which have neither problem), but that's more intrusive
<pitti> if the restart one works, then my recommendation is to use that for wily as that's the least intrusive
<pitti> if it doesn't work, then let's use the inotify one
<infinity> Or both!
<infinity> Two hammers are better than one hammer.
<infinity> That's what my hammer salesman told me.
<pitti> infinity: sorry, it's just one shaft with a hammer head on either end
<infinity> pitti: It's PHP?
<infinity> Oh, that was two claws.
<infinity> https://www.flickr.com/photos/raindrift/sets/72157629492908038/
<pitti> there; I was going to work on the udev rule one and now I need to chuckle
<pitti> as long as it's not like this: http://vignette4.wikia.nocookie.net/starwars/images/1/1a/Darth_Maul_lightsaber_reveal.png/revision/latest?cb=20140421143551
<pitti> infinity, cyphermox: remind me, why do we have this inhibit thing in the first place? for installations to USB drives, right? (as internal drives aren't being automounted anyway)
<pitti> or, I guess it was for preventing the user from clicking on the internal drive icons and thus manually mounting them
<cjwatson> automounting hasn't always been inhibited consistently on internal drives, and yes, external ones matter too
<cjwatson> ubiquity needs complete control muahahahaha etc.
<pitti> just tested on current live system, manual mounting is all too easy too
<cjwatson> cf. http://www.chiark.greenend.org.uk/~cjwatson/blog/desktop-automount-pain.html :-)
<pitti> so just setting UDISKS_AUTO=0 won't suffice
<pitti> cjwatson: heh, right; but most of them won't prevent manual mounts, which AFAICS is the bigger problem?
<cjwatson> the original motivation was things randomly capturing temporary mount points
<pitti> that was the  idea behind temporarily changing the polkit policy -- then you both disable auto- and manual mounts, and it works for all desktsop
<cjwatson> but suppressing manual mounts would be good too
<flexiondotorg> infinity, Thanks.
<cyphermox> pitti: upload whichever one you prefer, both your fixes seem to work correctly here.
<cyphermox> unless Riddell says otherwise
<pitti> cyphermox: cool, thanks for testing
<cyphermox> I can only test it so much, it's hard to reproduce
<pitti> cyphermox: I'll flip a coin :) but indeed I'm leaning towards the restart thingy as that's the least intrusive
<cyphermox> ok
<cyphermox> well, the inhibit one seemed to be quite nice
<cyphermox> not restarting means it's even less intrusive to other things on the session
<pitti> I'm testing the temp udev rules one right now, which is kind of "best of both worlds"
<pitti> but I wouldn't do that a day before release
<cyphermox> right
<cyphermox> but after release I'd just teach polkit to do USR1 or HUP.
<cyphermox> seems like a fairly useful trick
 * cyphermox takes a backup to be able to run at least one install test on real hardware
<pitti> yay, we have an X-series bug target in LP now
<pitti> cyphermox: oh, don't you guys have infinity's craptop as a victim in the office?
<infinity> I didn't bring my spare laptop this time, no.  Didn't want the weight when I'm on the road for three weeks.
<cyphermox> I considered bringing craptops, but didn't want to take more shit out at airport securities
<pitti> I'd have thought in the office there sohuld be a spare or three
<infinity> There might be.
<pitti> ^ kthxbye lunch o'clock
<cyphermox> pitti: thanks
<pitti> infinity: if you review/accept it seems a a perfect lunch time for you as well, for LP/britney to do their things :)
<seb128> ^ u-s-d, that's for bug #1508327
<ubot2> bug 1436861 in unity-settings-daemon "duplicate for #1508327 unity-settings-daemon crashed with SIGSEGV in engine_update_composite_device()" [High,In progress] https://launchpad.net/bugs/1436861
<seb128> would be nice to get in as well
<seb128> both didrocks and I got it while testing ubiquity install-mode
<pitti> https://launchpadlibrarian.net/221863227/unity-settings-daemon_15.04.1%2B15.10.20151012-0ubuntu1_15.04.1%2B15.10.20151021-0ubuntu1.diff.gz
<seb128> it leads to having wm decorations on the right and probably some other issues
<pitti> ^ debdiff for that, as it's non trivial to find
<flexiondotorg> This bug is confirmed not present in Ubuntu MATE but still present in Unity - https://bugs.launchpad.net/ubuntu-mate/+bug/1437764
<ubot2> Launchpad bug 1437764 in msttcorefonts "ttf-mscorefonts-installer doesn't work from Ubuntu Software Center because of EULA, breaks APT" [Undecided,Confirmed]
<flexiondotorg> I didn't do anything to fix it.
<seb128> could be a missing frontend?
<pitti> seb128: is the "devices = " just for not having to write manager->priv->devices_array several times in the loop, or is there some funky refcounting thing going on?
<pitti> seb128: i. e. the gist of the change is to disconnect signal handlers before freeing, right?
<seb128> pitti, it's just to improve readability
<seb128> yes
<pitti> seb128: I thought one would use g_ptr_array_new_with_free_func() for such things, and disconnect handlers there
<seb128> pitti, same reasoning than https://bugzilla.gnome.org/show_bug.cgi?id=673007#c17
<pitti> but anyway, LGTM
<ubot2> Gnome bug 673007 in general "[power]: gnome-settings-daemon crashed with SIGSEGV in engine_update_composite_device()" [Normal,Resolved: fixed]
<infinity> pitti: Are you reviewing u-s-d?
<seb128> pitti, feel free to comment on #ubuntu-desktop for larsu about that
<seb128> we can improve that with another commit after wily
<pitti> infinity: I was reviewing, seems Laney is currently pushing the button for it
<pitti> seb128: yeah, nevermind
<seb128> thanks for the review!
<Laney> pitti: I didn't
<seb128> lunch now, I'm starving
<seb128> bbiab
<Laney> I saw you were reviewing :)
<Laney> just saying that we will take this change
<pitti> ack; accepting then
<pitti> "The Unapproved queue is empty."
<pitti> and so is my stomach
 * pitti bbl
<Laney> thanks
<pitti> ^ oooh!
<pitti> we have an adjective?
<cjwatson> shh
<Laney> sssshhhhhh
<cjwatson> (also, if we're fired, I blame infinity)
<doko> promoted the slimit binary, only the source was promoted
<infinity> Huh, I thought I got that in the queue yesterday.  Thanks.
<smb> pitti, really it might be just me being too quick... I am not used to a puny netbook with an old Atom CPU.
<pitti> Laney: vim/amd64 WTH?
<Laney> pitti: ?
<Laney> did it fail?
<pitti> Laney: yes, in a really weird way; I retried it
<pitti> Laney: https://launchpadlibrarian.net/221870097/buildlog_ubuntu-wily-amd64.vim_2%3A7.4.712-2ubuntu4_BUILDING.txt.gz
 * Laney blinks
<pitti> Laney: seems the new build is past that point already
<Laney> worrying
<Laney> but thanks for retrying :)
<didrocks> the new build was just a better build, that's it :p (hemâ¦ ;))
<infinity> pitti: Can you hunt down why the kio/i386 autopkgtest isn't autopkgtesting?
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/k/kio/20151021_095959@/log.gz
<pitti> argh that again
 * pitti radiates hate towards lcy01
<pitti> infinity: yep, on it
<pitti> http://autopkgtest.ubuntu.com/status/alerts/ - eww
<infinity> pitti: I retried it.  But I'm not convinced it's retrying.
<pitti> infinity: next britney run will re-trigger them
 * pitti disabled lcy01 again, next runs will use lgw01 and clean up the mess
<pitti> infinity: http://autopkgtest.ubuntu.com/running.html -> kio/i386 is actually running
<infinity> pitti: I always forget the URL to that page.
<pitti> infinity: "Running" in the menu on a.u.c.
<infinity> ... which is linked from the top level.
<pitti> infinity: http://autopkgtest.ubuntu.com/status/alerts/ shows all the tmpfails, FYI; i. e. problems with the testbeds
<doko> are uploads for wily-proposed already accepted?
<flexiondotorg> cyphermox, Will you have time for the Deja Dup extension fix for Caja?
<cyphermox> can you point me to the bug again? I was on something else
<flexiondotorg> cyphermox, Sure.
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu-mate/+bug/1508353
<ubot2> Launchpad bug 1508353 in deja-dup-caja "deja-dup-caja plugin has a namespace collision in Ubuntu MATE 15.10 [debdiff]" [Undecided,In progress]
<cyphermox> flexiondotorg: are you sure this is good? the commented out part in setup.py?
<Riddell> pitti: infinity: still need testng?
<flexiondotorg> flexiondotorg, Yep.
<flexiondotorg> cyphermox, Thanks.
<flexiondotorg> Did you change debian/install to executable?
<infinity> Riddell: I'm going to respin you shortly, you can just test the ISO instead. :)
<Riddell> lovely
<pitti> Riddell: if you want, you can replace udisks2-inhibit with what's attached to the bug, to get it early
<pitti> also, the fixed udisks2 is just being published
<cyphermox> ^ lolz
<cyphermox> flexiondotorg: deja-dup-caja is atrocious
<flexiondotorg> cyphermox, In what sense?
<cyphermox> in the sense that the packaging was broken, and that your patch means the upstream tarball should get fixed
<cyphermox> (and we rejected twice before getting it right)
<flexiondotorg> cyphermox, I'm working with the upstream author to fix the tarball either tonight or tomorrow.
<cyphermox> ok
<flexiondotorg> Is there anything else you want me to improve.
<flexiondotorg> Because I'v not ben involved with the development or packaging until tody.
<flexiondotorg> cyphermox, ^^^^^^^^^^^^^^^^^^^^^^
<cyphermox> flexiondotorg: nothing critical now; if you can just make sure that the upstream developer fixes the filename in their tarball, then we'll be pretty good
<cyphermox> oh, and the README too; there's a small diff
<cyphermox> basically, what's in deja-dup-caja.patch
<cyphermox> once that is done, there's nothing special to do but to drop the patch with the upload, the rest is not an issue
<apw> infinity, i've done a quick spin through the release notes, dropped the bugs which appear fixed etc.  we are missing updated release notes for most of the flavours at the moment (many are /beta2 still)
<apw> infinity, we are also missing server
<flocculant> apw - ours are done - just not changed that page yet
<apw> flocculant, cool thanks
<flocculant> apw - though if I'd have waited I could have said I'd done the main page ...
<flocculant> must be install testing fever
<infinity> flexiondotorg: Will rebuild MATE once that deja-dup thing publishes in the next 30m.
<infinity> **** WARNING: REBUILDING THE WORLD ****
 * ogra_ searches for cover
<davmor2> infinity: \o/ imagesssss the precccciiiouussssss
<flexiondotorg> infinity, Thanks.
<flexiondotorg> I'll get my DVD burner at the ready for PowerPC ;-)
<flexiondotorg> cyphermox, Noted regarding the tarball.
<cyphermox> flexiondotorg: oh, that's right. getting a ppc machine next week means I'll really need to do my netboot setup.
<flexiondotorg> cyphermox, What PPC machine you getting?
<cyphermox> flexiondotorg: some random G5 I might be able to aquire.
<cyphermox> flexiondotorg: I've been meaning to setup a proper netboot environment regardless.
<infinity> pitti: How long after something disappears from running.html until is shows up in the test results?
<infinity> s/is/it/
<infinity> pitti: The juju-core tests went away from running.html minutes ago, but I don't see results.  Weird.
<infinity> pitti: Bah.  And now they both show up.  Finally.  As failures.
<flexiondotorg> cyphermox, Look on ebay, they G5 powermacs are really cheap now.
<cyphermox> yeah
<cyphermox> it shouldn't be too hard to find, I just need to email someone actually
<cyphermox> I just postponed until next week since I'm not in Canada
<flexiondotorg> cyphermox, There is also the Amiga ONE X500 and X1000 too.
<flexiondotorg> Which are new.
<cyphermox> flexiondotorg: which are probably quite expensive then
<pitti> infinity: up to 5 minutes
<pitti> infinity: I retried them, in case it helps; but if it's urgent, feel free to hint away
<infinity> pitti: You're way behind.
<infinity> pitti: I already hinted them, and the bug has been diagnosed and is being fixed.
<pitti> panic: osVersion reported an error: Could not determine series ?
<pitti> behind> heh, indeed I am, just returned quickly to laptop before basketball
<pitti> infinity: is that the old "no current development series in Launchpad" thing agaain?
<pitti> ah, autopkgtest finally imported; /me pushes sync button
<infinity> pitti: No, it's a bug in the test.
 * pitti will be back in some 3 hours after basketball; anything I should be looking out for then?
<pitti> (I assume/hope you'll be out by then)
<pitti> 19:11:25    rbasak | Juju fix uploaded.
<pitti> \o/
<infinity> pitti: Just ISO testing.  This spin should be "final" unless something horrible happens.
<pitti> infinity: ack; I guess I'll give them an initial spin tonight then, and do the finer-grained install cases tomorrow
<pitti> already went through all of them today after all, and we didn't change that much
<pitti> (famous last words, I know)
<flocculant> infinity: assuming that nothing particularly horrid has been seen - these new images just need a quick check?
<pitti> infinity: this spin> the ones that just landed 45 mins ago, or is another one going on?
<pitti> i. e. 20151021 or an upcoming 20151021.1?
<jibel> pitti, final build should be 20151021
<infinity> flocculant: Pretty much, yeah.
<infinity> pitti: What jibel said.
<pitti> hmm, and still bug 1471476 and bug 1508000
<ubot2> bug 1471476 in libimage-exiftool-perl "[MIR] libimage-exiftool-perl" [High,New] https://launchpad.net/bugs/1471476
<ubot2> bug 1508000 in cmake-extras "[MIR] cmake-extras" [Undecided,New] https://launchpad.net/bugs/1508000
<infinity> pitti: Yeah, neither of those affect images, so we just need them sorted by tomorrow afternoon.
<pitti> the latter could be promoted now, after doko's review and latest comments
<flocculant> infinity: thanks - that was exactly what I needed to read :p
<infinity> pitti: Would perhaps be nice if those mythical bugfixes were actually in wily instead of a PPA, but meh.
<jderose> infinity: will there be 20151021 server ISOs, or did only the desktop need a respin?
<infinity> jderose: Server's building right now.
<jderose> infinity: gotcha, thanks!
<wxl> infinity: so what are we trying to fix with today's global respin, sigh?
<wxl> â¦bug numbers might be helpful
<jibel> wxl, bug 1436861 and bug 1508075
<ubot2> bug 1436861 in unity-settings-daemon "unity-settings-daemon crashed with SIGSEGV in engine_update_composite_device()" [High,Fix released] https://launchpad.net/bugs/1436861
<ubot2> bug 1508075 in udisks2 "ubiquity and others time out on polkit (killed by udisks2-inhibit)" [Medium,Fix committed] https://launchpad.net/bugs/1508075
<wxl> jibel: 1436861 required a global respin?
<infinity> wxl: No, the other bug did.
<wxl> okie dokie
<jibel> wxl, 1508075 did
<jibel> what infinity said
<infinity> wxl: And no sighing, we almost always have a respin the day before release. :P
<infinity> I can't remember the last time we just sat around twiddling our thumbs on a Wednesday.
<jibel> maybe because there was no last time?
<infinity> OR MAYBE BECAUSE WE HAVE NO THUMBS.
<jderose> pitti: small inconsistency i noticed: when installing from the desktop ISO, /var/lib/dbus/machine-id is a symlink to /etc/machine-id, but from the server ISO  /var/lib/dbus/machine-id is a file (with the same UUID value copied from /etc/machine-id)
<utlemming> infinity: can you add wily final to cloud.qa.ubuntu.com?
<wxl> infinity: upgrades haven't been updated. don't the unity ones need to be?
<wxl> s/updated/respun/
<utlemming> slangasek, infinity, stgraber: cloud image test results can't be populated because the product is not on cloud.qa.ubuntu.com yet, and switching to iso.qa.ubuntu.com is erroring out.
<slangasek> utlemming: "erroring out" how?
<slangasek> the webpage loads for me
<utlemming> slangasek: when I try to populate the products it returns a failure
<utlemming> slangasek: http://paste.ubuntu.com/12887531/
<utlemming> slangasek: we moved over to cloud.qa.u.c, for the last release so that the cloud images didn't take over the dashboard. So the real fix is for someone to create the milestone of "Wily Final"  there
<slangasek> ok; I don't know anything about cloud.qa.u.c, would I have admin access on it?
<slangasek> doesn't look like it
<utlemming> slangasek: actually, I think I can do it...I was looking at the wrong place...standby
<utlemming> slangasek: okay, I found that I can do it
<slangasek> \o/
<utlemming> General FYI -- cloud image test results are going to http://cloud.qa.ubuntu.com
<davmor2> infinity, jibel: boot from first drive is failing
<davmor2> not sure how critical it is
<davmor2> it does cause the system to reboot so I guess that will get you to the first hard-drive ish
<infinity> davmor2: Longstanding issue with some BIOSes.  It's hard to fix without breaking other people instead.
<infinity> davmor2: Unless your contention is that this works on the same machine with an older image.
<davmor2> infinity: I'll grab an older image but I think it used to, but this bios has been updated so now might not, it might also be dvd vs pendrive so I'll try that too
<infinity> davmor2: It's less likely to work with USB drives than with optical drives.
<infinity> davmor2: As some BIOSes boot USB sticks by remapping them to the logical location of the first hard drive.
<davmor2> infinity: indeed that's why I say I'll double check that too once this install finishes
<cyphermox> go davmor2, break stuff!
<davmor2> cyphermox: shhh that's what I'm trying not to do
<davmor2> infinity: same issue on dvd let me get a 14.04 image burned
<davmor2> infinity: 14.04 daily image dvd boots from first hard drive
<davmor2> jibel: ^
<davmor2> I'll write up a bug and blame cyphermox
<davmor2> now where does that menu live I guess casper maybe?  cyphermox
<davmor2> infinity, jibel: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1508589
<ubot2> Launchpad bug 1508589 in casper "15.10: On the Ubuntu menu on a non uefi install Boot from first disk fails" [Undecided,New]
<davmor2> jibel: there is no test for that option on the tracker so shall I attach it anywhere or do you just want to tag it for info
<flocculant> davmor2: I noticed that a while back - then promptly forgot about it
<davmor2> flocculant: feel free to confirm the bug then :)
<flocculant> davmor2: do you think I wouldn't have ;)
<flocculant> davmor2: or do you mean actually write something instead of just me tooing?
<davmor2> flocculant: no that's fine I didn't look at the bug too busy looking at the other machine for the next install
<flocculant> ok - then all done :)
<pitti> jderose: interesting, can you please file a bug about it? a symlink sounds better
<cyphermox> davmor2: it's in debian-cd actually, I'll reassign
<pitti> jderose: might be that this is because server doesn't install dbus by default?
<davmor2> cyphermox: thanks dude
<jderose> pitti: yeah, i'll file a bug about it later today or tomorrow. er, i thought dbus (system-wide anyway) was installed by default on the server?
<pitti> jderose: ah, maybe it is now
<jderose> pitti: just double checked... yup, installed by default on the server
<davmor2> okay that is odd, screen reader not working on i386 dvd but is from i386 thumbdrive meh
 * Laney peeks in
<davmor2> Laney: mad fool it's all your fault now
<Laney> /quit
<flexiondotorg> cyphermox, Should there be a network applet in oem-config?
<jderose> pitti: filed a  bug - https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697
<ubot2> Launchpad bug 1508697 in dbus "Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server" [Undecided,New]
#ubuntu-release 2015-10-22
<Laney> pitti: I just released u-r-u to updates BTW
<Laney> thanks!
<pitti> Laney: good morning; ah, nice!
<Laney> hey
<Laney> did you get your 8 hours? :P
<pitti> Laney: so now we need to adjust the -meta branch and roll this out
<Laney> pitti: indeed, have this committed here, will do
<Laney> or will get someone to do
<pitti> Laney: indeed I did! I slept until 9, it's been a loooong time since I've been able to do that
<pitti> Laney: ah, you did already? good; I wanted to wait until you guys are up to get some more pair of eyes on the changes
 * pitti does iso testing in the meantime, although davmor2 already was on fire :)
<pitti> Laney: you didn't push yet?
<davmor2> pitti: sleep is for the weak ;)
<pitti> davmor2: but I hope the iso tracker's time zone is just off or so
<pitti> I saw results from you from yesterday 14:00
<pitti> which was several hours before they actually got released
<pitti> or there's a bug with showing old results
<davmor2> pitti: that was the tests for netboot though :P
<pitti> davmor2: no, e. g. http://iso.qa.ubuntu.com/qatracker/milestones/347/builds/105070/testcases/1300/results
<pitti> 2015-10-21 14:37
<davmor2> pitti: and you ran a test at 03:55
<pitti> so I guess it's behind ~ 6 hours
<davmor2> pitti: stgraber set it up so I assume it is canada time
<pitti> right, makes sense
<pitti> ok, amd64 is as good as it ever gets, doing i386 and the ubuntu core ones now
<davmor2> pitti: so it would of been 20:37
<pitti> Laney: odd, that didn't close the bug task
<pitti> Laney: seems you didn't actually release, https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+publishinghistory
<pitti> Laney: what did you run?
<Laney> did the copy work?
<pitti> "sru-release wily ubuntu-release-upgrader"?
<Laney> sru-release -z 100 wily ubuntu-release-upgrader
<Laney> "Copied to wily-updates"
<pitti> hm, +publishinghistory disagrees
 * Laney plays the x-files theme
<pitti> does htis thing need spethial magic for the extra tarball?
<pitti> nothing on https://wiki.ubuntu.com/StableReleaseUpdates
<pitti> we used to have special instructions many years ago, but I thought this got fixed in LP a long time ago
 * pitti runs the command
<cyphermox> flexiondotorg: I don't know, are you asking because it is missing or because you see it there?
<pitti> Laney: hm, worked for me; really odd
<Laney> pitti: wait
<Laney> it's in the queue
<Laney> ah
<pitti> Laney: urgh -- why does it land in the queue for you but not for me? ~ubuntu-sru membership or so?
<Laney> I guess
 * pitti deletes the queue item then
<Laney> I had these powers before
<Laney> someone's put some kryptonite somewhere around here
<davmor2> jibel: infinity: morning guys so the boot to first hard drive issue didn't happen on 14.04's daily live image so only on 15.10, so a bug for xenial.  Also I hit an issue with the screen reader on dvd that I am going to revisit today and see if I can reproduce, works as expected from usb pendrive, on dvd the installer has no commentary but the installed desktop does
<pitti> Laney: ok; want me to eyeball your ~ubuntu-core-dev/meta-release/ubuntu change and push?
<jibel> davmor2, thanks. I'll try to confirm the screen reader thing
<Laney> pitti: I pushed it there (it's manually pulled to changelogs.u.c) if you want to have a look
<Laney> the URLs aren't live yet so I couldn't check them that way
 * pitti promotes the remaining two MIRs
<pitti> Laney: ah, looks straightforward
<pitti> Laney: this will just be copied to meta-release later on, right?
<pitti> we should probably update meta-release-proposed too, but I guess that's part of the "do the release" dance
<Laney> yeah
<pitti> Laney: Adam can push this to ch.u.c.
<Laney> will wait for the publisher before poking
<flexiondotorg> cyphermox, Because it is missing.
<cyphermox> flexiondotorg: I suppose it probably should be there
<flexiondotorg> I *think* I remember it being there is the past.
<flexiondotorg> If I invoke oem-config-first boot with sudo, I get NetworkManager stuff.
<cyphermox> if you invoke oem-config-first it will remove NM configs; since you might need some for setting up the oem environment
<flexiondotorg> To be clear, there is no network applet in when oem-config runs after is has been prepared.
<flexiondotorg> So no option to join a wifi network.
<flexiondotorg> No indication that you are connected via a wire.
<Riddell> are we nearly there yet?
<infinity> Riddell: Not yet. :P
<davmor2> jibel: so I'm definitely not getting a screen reader on dvd on hardware let me see if it is the same in kvm
<flexiondotorg> infinity, Does this mean the images will be respun again?
<infinity> flexiondotorg: No.
<flexiondotorg> Yes!
<infinity> NO!
<flexiondotorg> infinity, I understand :-)
<flexiondotorg> My Yes! was pleasure to seeing your No.
<flexiondotorg> Was up until 02:30 testing.
<pitti> infinity: good morning
<davmor2> jibel: so working in kvm with --soundhw ac97  and on pendrive so no idea why it isn't working from dvd
<davmor2> jibel: I'll try enabling it in live desktop and see if functions there
<jibel> davmor2, can you file a bug it's something for xenial now
<davmor2> jibel: sure
<cyphermox> flexiondotorg: ah, I thought you meant in oem-config-wrapper; the thing that runs after you've set up the session to copy things for the end user.
<flexiondotorg> cyphermox, No. I mean after the system has been prepared.
<cyphermox> so, in the end user session?
<cyphermox> or in the oem user session?
<flexiondotorg> When you get to choose you language and locale etc.
<cyphermox> right
<jibel> davmor2, I'm on the remaining tests for i386
<cyphermox> that's oem-config-wrapper
<cyphermox> I suppose it might be normal
<flexiondotorg> cyphermox, OK, that's good then :-)
<davmor2> flexiondotorg, cyphermox: I had no issues with OEM installs on Ubuntu desktop this time
<cyphermox> flexiondotorg: it's probably like that since vivid; but maybe it's an issue
<flexiondotorg> It's not a problem. Because it all works and there is no need for a network connection.
<cyphermox> I just don't know if you'd need to download things in that environment
<cyphermox> ah
<cyphermox> ok then
<flexiondotorg> At least, I don't think there is a need.
<cyphermox> let's just make sure you do get an indicator or nm-applet once in the user's session
<flexiondotorg> I do.
<cyphermox> langpacks maybe, if you pick something not already available?
<flexiondotorg> Yes, that is the only thing I can think of that might require network connectivity.
 * cyphermox spins up yet another vm
 * Laney is trying the server-i386 test which is left
<jderose> flexiondotorg: you're right, i didn't even notice that the user config after "prepare for shipping to end user" is no longer prompting you for a wifi password when your not on ethernet, doesn't seem to have networking setup
<jderose> flexiondotorg: i'm almost positive it was in vivid
<flexiondotorg> jderose, Thanks for the confirmation.
<jderose> cyphermox: lack of network config here does mean it can't guess your timezone
<flexiondotorg> jderose, It was late and I wasn't sure what the previous behaviour was.
<flexiondotorg> jderose, Ah, yes. No timezone detection.
<jderose> wonder how recently this changed... i'm pretty sure networking was still enabled here not too long ago in wily
<Laney> could test a beta image
<jderose> crap, can't believe i missed this. nice catch, flexiondotorg!
 * flexiondotorg fears I have thrown a spanner in work :-/
<jderose> hehe
<flexiondotorg> jderose, So System76 offer non-LTS options then?
<jderose> flexiondotorg: yeah. and for skylake, we absolutely had to move to wily
<flexiondotorg> Ah, of course.
<infinity> Riddell: I'm assuming your images are ready, though you didn't mark them as such?
<jderose> historically System76 only offered the latest release, offering the LTS (when we can) is a recent development. but it's proven popular with corporate and scientific customers
<flexiondotorg> jderose, Yeah, makes sense.
<Riddell> infinity: right, just me wanting to keep getting people from testing them but they're good as far as I'm concerned
<infinity> Riddell: Ta.
<Riddell> ..keep getting people to test them
<pitti> Laney: http://changelogs.ubuntu.com/meta-release-development LGTM, thanks! /me does another upgrade test with the "real" do-r-u now
<jderose> flexiondotorg: funny thing is, ubi-timezone generally can't guess my timezone from my home IP, so when i've been testing the first run user config this week while ethernet was plugged it, i thought it was the usual behavior, didn't realize networking wasn't enabled :P
<davmor2> jibel, popey: https://bugs.launchpad.net/orca/+bug/1508844
<ubot2> Launchpad bug 1508844 in orca "Screen reader is not triggered during live cd and installer when on DVD on hardware" [Undecided,New]
<pitti> Laney: *meep*
<pitti> $ sudo do-release-upgrade -d
<pitti> Err Upgrade tool signature
<pitti>   404  Not Found            WARNING:root:file 'wily.tar.gz.gpg' missing
<Laney> full URL?
<pitti> which is odd as it's *right there* on http://archive.ubuntu.com/ubuntu/dists/wily-updates/main/dist-upgrader-all/current/
<Laney> sure looks there to me
<Laney> sure is working in schroot for me too
<Laney> http://de.archive.ubuntu.com/ubuntu/dists/wily-updates/main/dist-upgrader-all/current/ ?
<Laney> does it use mirrors?
<pitti> hm, possibly
<pitti> my apt sources use archive.u.c. though
<Laney> "System upgrade is complete."
<infinity> Could just be that not all the archive frontends are up to date yet?
<pitti> so if at all, it's using some geolocation magic
<pitti> argh, *phew* apt proxy FTL
<Laney> proxies and u-r-u... feel like we've heard this before
<infinity> Hah.  That's the second time in two days that apt-cacher broke someone.
<pitti> I temporarily disabled it for downloading the tarball, and it seems to work now; sorry for the noise
<Laney> Maybe it's using the apt proxy for too many things
<davmor2> jibel: trying on mac too to rule out hardware, but it's odd that 14.04 daily worked but 15.10 didn't, I might try another dvd too just incase that one is slower than the 14.04 one
<Laney> Assuming you have it configured in apt only
<pitti> Laney: yes, /etc/apt/apt.conf.d/95cloud-init-proxy
<infinity> pitti: Yeah, apt-cacher doesn't do well with arbitrary files (squid-deb-proxy would be fine in this case).
<infinity> pitti: But likely a bug in u-r-u that it uses your apt proxy config to find metadata.  Or maybe it should try once with and once without.
<pitti> I tried s-d-p, and found it much worse; not entirely sure why any more, but I think one reason was that you can't use it offline
<infinity> zequence: What's the status of studio testing/images?
<davmor2> jibel, popey, beginning to suspect the dvd, so will confirm with a new disc
<zequence> infinity: We're in middle of testing
<jderose> flexiondotorg: just tested with 14.04.3... it doesn't show the NM applet when you're on ethernet, but if not on ethernet it will prompt you to join a WiFi network, does show the NM applet in this case
<flexiondotorg> jderose, OK, thanks.
<infinity> zequence: Kay.  I'm publishing anyway, but you have a couple of hours to tell me it's all broken and I should delete them. :P
<davmor2> jibel, popey: meh same behaviour on another dvd, checking the integrity now, seems to be fine so far :(
<cyphermox> flexiondotorg: jderose: did you file a bug about the missing network indicator in the oem-config-wrapper?
<zequence> infinity: Why so early this time?
<infinity> zequence: Not really that early.  Aiming for an early afternoon (London time) release, as usual.
<infinity> zequence: But we always push earlier to let the world settle a bit,
<infinity> zequence: I don't always tell people, mind you. :P
<zequence> Alright. Yeah, things seem to work for us. Only one test left, I think.
<jderose> cyphermox: i haven't yet. flexiondotorg?
<flexiondotorg> infinity, Release at 15:10 ;-)
<flexiondotorg> cyphermox, No. But can do.
<flexiondotorg> cyphermox, Just fire fighting something else...
<cyphermox> ok
<infinity> flexiondotorg: No. :)
<flexiondotorg> infinity, Spoil sport.
<infinity> flexiondotorg: If we did that, when would I release Ubuntu 24.04?
<infinity> THINK, MAN, THINK.
<jderose> hehe
<Laney> As if the world is going to still exist by then
<cyphermox> infinity: on may 24th?
<cyphermox> err, april
<Laney> 02:40:40
<davmor2> jibel, popey: oh that's interesting I tried enabling it in the ubiquity session rather than via the menu and the screen reader worked, so now I'm retrying the menu way again, if that is broken then it might just be calling the system wrong maybe
<davmor2> but then it's odd that it works on pendrive when run the same way
<pitti> so http://people.canonical.com/~ubuntu-archive/component-mismatches.svg is now as good as it's going to be
<flexiondotorg> jderose, Can you raise the oem-config-wrapper bug and link it here please?
<flexiondotorg> The rest of my helpers are sleeping and I'm a little busy.
<infinity> pitti: I noticed, thanks.
<jderose> flexiondotorg: yeah, on it. then i need to get back to bed, as in theory i'm supposed to be sleeping right now :P
<flexiondotorg> jderose, Thank you!
<jderose> flexiondotorg: cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865
<ubot2> Launchpad bug 1508865 in ubiquity "oem-config: networking not enabled during user config" [Undecided,New]
<flexiondotorg> jderose, Thanks for that :-)
<jderose> np :)
<cyphermox> ta
<Trevinho> bdmurray: hey, so... Since you told me that the compiz from https://requests.ci-train.ubuntu.com/#/ticket/402 is already in proposed and thus in ddebs, can we cleanup that silo?
<seb128> Trevinho, bdmurray, can we just get that one migrated to updates? what's blocking it?
<Trevinho> seb128: the bug wasn't added to the changelog (blame the train), but I think the got it
<davmor2> jibel: popey: so after several retries, I can confirm it looks like it is all cyphermox and infinity fault :)  infinity is there a way to see the kernel line for screen reader enabled to ensure the option is actually being enabled?  I guess I can enable another mode like free software only and then enable screen reader right?
<jibel> davmor2, press space on boot to display the boot menu then F6
<davmor2> jibel: thanks
<jibel> willcooke, seb128 you're happy with the desktop section of the release notes?
<jibel> https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes#Ubuntu_Desktop
<willcooke> jibel, +1
<davmor2> jibel: so I see nothing change when I enable screen reader, let me see what happens on usb stick
<seb128> jibel, works for me
<jibel> jamespage, gaughen anything you'd like to add for server https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes ? there is nothing currently
<jamespage> jibel, I'll add some openstack bits - jgrimm, smoser and rharper can do general server
<jibel> thanks
<cyphermox> davmor2: what is this about?
<davmor2> cyphermox: https://bugs.launchpad.net/orca/+bug/1508844
<ubot2> Launchpad bug 1508844 in orca "Screen reader is not triggered during live cd and installer when on DVD on hardware" [Undecided,New]
<cyphermox> in non-efi you might not actually see the command-line changes in various cases, it's not a bug
 * cyphermox tries
<davmor2> cyphermox: works fine on 14.04 daily live, works fine from pendrive, works fine on virtual dvd on kvm with --soundhw ac97, just doesn't work from real dvd on real hardware hardware
<cyphermox> davmor2: sounds very very suspect.
<davmor2> cyphermox: try a secondary dvd, both dvd's pass the integrity test, both have the same behaviour, but as I say 14.04 daily on dvd in the same system works with no issues
<davmor2> s/try/I tried
<cyphermox> dvd> what image?
<jibel> pitti, is bug 1508744 the same bug you fixed in wily?
<ubot2> bug 1508744 in lxc "Upgrade to Ubuntu 15.10 Broken" [Undecided,New] https://launchpad.net/bugs/1508744
<pitti> jibel: looking, but very likely
<davmor2> cyphermox: http://cdimages.ubuntu.com/daily-live/current/
<nhaines> I found a typo in the release notes.  "Blueman 2.0 is now include and used by several flavours along with BlueZ 5.35." should be "Blueman 2.0 is now included and used by several flavours along with BlueZ 5.35."
<pitti> jibel: inconclusive, let me respond there
<davmor2> cyphermox: I find it really odd that the same image on pendrive works with no issues, and the same image on kvm has no issues
<cjwatson> nhaines: fixed, thanks, though it's a wiki so feel free to edit directly if you notice typos and such
<nhaines> cjwatson: this was my first impulse, but it's an immutable page.  :)
<davmor2> cyphermox: I managed to trigger the screen reader if I let it boot straight to ubiquity session but not if I trigger it from the f5 menu, just really weird
<cjwatson> oh, maybe it's locked to ... something
<pitti> jibel: no, looks different, replied
<cjwatson> you sure you're logged in?
<nhaines> cjwatson: yup!  But after a refresh, it's no longer locked.
<nhaines> No wait, it's locked again.
<nhaines> \o/
<cjwatson> wibble
 * nhaines shrugs.
<nhaines> Looks like it's a wiki.ubuntu.com problem, not an issue withh the page actually being locked.
<cjwatson> that seems likely
<nhaines> Someone else fixed the thing I noticed, so I fixed something else that was more trivial. \o/
<cyphermox> davmor2: I get no sound, but I think it's because the kvm sound is broken, orca is running, and all the settings set in casper-a11y-enable are set.
<davmor2> cyphermox: yes it works for me in kvm I did say that, it's only really dvd on real hardware where it doesn't,
<cyphermox> davmor2: ah, I understood it the other way around
<cyphermox> are you sure that hardware can do sound?
<cyphermox> and that the volume is up?
<davmor2> cyphermox: yeap I hear the drums, and on pendrive on the same system it works, and if I let ubiquity session start and the drums go I can then trigger screen reader and I hear it, just not from the f5 menu
<davmor2> cyphermox: the really weird think is though that the screenreader is on, on the installed system so it is only the ubiquity session that is not having the screenreader work
<jamespage> rbasak, hey - if you are around, I've done what I can with https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes for server, but there are a few general server things I'm not sure on  (all in comments on the page)
<davmor2> cyphermox: or the live cd session for that matter
<davmor2> cyphermox: the kvm command I used is as follows kvm -m 2048 -vga vmware -cpu host --soundhw ac97 -cdrom wily-desktop-amd64.iso -hda kvm-images/ubuntu20hda.qcow2 -boot d  that gives me audio then
<rbasak> jamespage: looking
<jamespage> rbasak, ta
<rbasak> jamespage: so Juju has a 1.24.7 now: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1506652
<ubot2> Launchpad bug 1506652 in juju-core "[needs-packaging] Juju 1.24.7 is not in Ubuntu" [Undecided,Triaged]
<jamespage> rbasak, is that actually uploaded yet?
<rbasak> No
<jamespage> or released from proposed
<jamespage> (in juju stream terms)
<jibel> cyphermox, is usb-creator completely busted in wily?
<rbasak> Oh it might still be in proposed
<rbasak> So then 1.24.6 is the latest stable from upstream so the note is correct. Sorry.
<rbasak> jamespage: the notes look fine to me, thanks.
<rbasak> teward: did you have anything to add for nginx?
<jamespage> rbasak, erm missing MAAS LXD LXC (still commented)
<rbasak> Oh, commented as in the source? I get it :)
<jamespage> yah
<rbasak> MySQL hasn't changed (at all)
<rbasak> LXC and MAAS, I don't know. Will have to defer to stgraber and roaxsoax.
<cyphermox> jibel: just writing amd64 images from i386, because we run the syslinux from the image you're trying to write, so that it writes an image that is bootable.
<jibel> cyphermox, do you know if bug 1467989 is still an issue, it is commented in the release notes.
<ubot2> bug 1467989 in multipath-tools "Boot issues running multipath with a large number of paths" [Undecided,Confirmed] https://launchpad.net/bugs/1467989
<jibel> ?
<Riddell> hello
<Laney> hi
<davmor2> Riddell: hello
<cyphermox> jibel: it's probably a little better but I'm not certain
<cyphermox> I don't typically have very many paths when testing :/
<jamespage> infinity, hey - do I have time for a sync of a fix for bug 1508463 from Debian? its an unseeded universe package?
<ubot2> bug 1508463 in aodh "alembic.ini is missing from the aodh install source" [Medium,Confirmed] https://launchpad.net/bugs/1508463
<infinity> jamespage: Yes, be fast.
<infinity> Or, I'll do it.
<jamespage> infinity, I need -6 but lp has not noticed yet
<jamespage> greee
<jamespage> at
<infinity> jamespage: Oh.
<infinity> jamespage: Then I'll fakesync -6 for you. :P
<jamespage> infinity, thankyou very much :-)
<infinity> jamespage: ^
<jamespage> infinity, ta
<infinity> jamespage: Will make sure that migrates before I close wily. :P
<jamespage> thankyou
<utlemming> Cloud images are ready to go, and marked as such on our tracker: http://cloud.qa.ubuntu.com/qatracker/milestones/349/builds
<lotuspsychje> ogra_: nice1
<flexiondotorg> infinity, Release ETA?
<ogra_> flexiondotorg, stop being pushy :P
<flexiondotorg> Not at all.
<flexiondotorg> Just trying to figure out if I can pick up my daughter from school :-)
<ogra_> if we delay she will have to learn til evening ?
<ogra_> poor girl :)
<Riddell> omg pre-announcing as usual...
<ogra_> yeah, sigh
<ogra_> they never learn
<flexiondotorg> Riddell, And Softpedia.
<ogra_> yup
<ogra_> pretty quiet in #ubuntu-release-party today
<rsalveti> ogra_: is it out yet? :P
<nhaines> Yeah, I'm trying to keep the links off /r/Ubuntu.
 * ogra_ hugs rsalveti 
 * rsalveti hugs ogra_ back
<infinity> flexiondotorg: Around 2pm London time, I think.  Just eating some lunch while things settle down.
<flexiondotorg> infinity, Cheers.
<teward|web> is Wily releasing today, per the release date listed on the wiki?
<Laney> Sure is
<ogra_> if nothing goes wrong it will be
<davmor2> jibel: did the screen reader bug get listed?
<teward|web> Laney: so, it's on the radar, but not yet "complete"/announced?
<rbasak> teward|web: did you see my message about release notes and nginx?
<ogra_> teward|web, exactly
<teward|web> rbasak: which message?  a PM to 'teward'?
<rbasak> No, in here.
<rbasak> teward|web: please edit https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes if you have any relevant notes.
<teward|web> rbasak: negative - no ZNC
<rbasak> There's a section for Ubuntu Server.
<teward|web> ack
<infinity> utlemming: Yo.
<utlemming> infinity: here
<infinity> utlemming: You can push your button any time, we'll be announcing in the next 15m.  Just want to verify your links work. ;)
<utlemming> infinity: pushing ow
<utlemming> er, now
<utlemming> ETA is roughly 5 minutes
<teward|web> rbasak: To my knowledge, there's nothing Wily-related with NGINX that needs a release notes.  Xenial is the one that really needs attention.  If I put anything there, it'll be a note that Wily has 1.9.4, which may have features which have bugs in the functionality, and that it does not have HTTP/2 support.  But the big one's going to be for Xenial.  (I know it's Xenial because the release notes bug I made for X-series had that phrase repla
<cjwatson> teward|web: you can know it's that because http://markshuttleworth.com/archives/1479
<rbasak> teward|web: the end of that got cut off I think. But yeah - if there's no need to say anything then don't botther.
<teward|web> cjwatson: didn't see that yet :0
<teward|web> as i said, no ZNC, no nice feeds form my laptop ;)
<teward|web> rbasak: i hate webchat with a passion - stupid char trim.
<teward|web> rbasak: there's nothing important for Wily with regards to nginx, no.  For Xenial, yes.
<teward|web> cjwatson: thanks
 * teward|web should probably follow Mark's pages :P
<rbasak> teward|web: OK, thanks.
<teward|web> rbasak: quick PM though, semi-important
<utlemming> infinity: AWS API's are being slow, but things are moving along, the links are good though (when the process completes).
<infinity> utlemming: Is http://cloud-images.ubuntu.com/releases/15.10/release correct?
<utlemming> infinity: yes, I just changed that a few minutes ago
<infinity> Kay.
<jibel> pitti, I couldn't reproduce the lxc upgrade issue so far, did you?
<pitti> jibel: no, I couldn't either; I upgraded it several times for that other bugs
<pitti> bug
<flocculant> infinity: far off now?
<infinity> flocculant: It's all in the hands of our IS people setting up some cloud redirection magic.  I'm hoping "soon".
<flocculant> okey doke - thanks :)
<mgedmin> "Due to changes in syslinux, it is not currently possible to use usb-creator from 14.04 and earlier releases to write USB images for 15.04"
<mgedmin> was this meant to say "15.10"?
<mgedmin> https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes#Boot.2C_installation_and_post-install
<apw> or "15.04 and later"
<nhaines> No, but should probably say--what apw said.  :)
<pitti> should the LibO section be trimmed a bit? Enumerating 10 "foo improvements" isn't very informative
<pitti> either we describe the improvements, or summarize this with "Improvements in foo, bar, bla" or skip this compleltely?
<jibel> seb128, ^
<bdmurray> seb128: there is nothing blocking it I was thinking we didn't really need to put it in -updates and make everyone download it since they don't need the ddebs and we already have them.
<willcooke> pitti, yeah, I think that makes sense.  There is a link to the main LO notes anyway, so we can just go with that
<willcooke> pitti, shall I change it?
<pitti> willcooke: please
<willcooke> on it...
<seb128> bdmurray, ok, ok, wfm
<seb128> jibel, pitti, willcooke, wfm
<willcooke> pitti, done.  Sorry, had to remember how to disable wikinames :)
<pitti> willcooke: yay, thank you
<Riddell> facebook says it's out?
<Laney> So it does
<teward|web> has it been released, though?  I don't see any announcement email yet.
<apw> teward|web, the email defines when it is released ... so ... :)
<teward|web> indeed :0
<teward|web> :) *
<teward|web> god i hate not having my computer with my keyboard >.>
<teward|web> this irritates me
<cjwatson> Riddell: still waiting for cloudfront redirect so that the release doesn't melt the DC - just escalated
<nhaines> The insights.ubuntu.com article just showed up.  That probably means it's actually out.  ;)
<infinity> nhaines: Or not. :P
<nhaines> infinity: must be.  I read it on the Internet!
<willcooke> le sigh
<Laney> It says "will be" or similar
<Laney> :)
<willcooke> The G+ post headline is "We've launched!"
<willcooke> :/
<cjwatson> yeah I think we need to get comms to jump the gun a bit less
<nhaines> Hmm, the insights article seems to imply a *much* more advanced Unity 8 session experience than I've ever managed to work.
<cjwatson> oh well
<Riddell> they probably just copy omg :)
<popey> jderose: heh
<popey> er, oops :)
<infinity> willcooke: We've launched!*  (11 years ago).
<willcooke> :D::D
<Laney> launched a south african into space
<willcooke> :)
<nhaines> I'm starting to doubt the wisdom of staying up to make sure the right threads got pinned in /r/Ubuntu.
<teward|web> There's the email.  Now Wily is released!
<teward|web> (topic change needed?)
<lordievader> Whoop, whoop. Congratulations!
<infinity> teward|web: Erk, ignore the email to ubuntu-release. :P
<infinity> teward|web: It's not moderated to ubuntu-announce yet.
<teward|web> ack
<infinity> Intentionally...
<infinity> *sigh*
<teward|web> my bad then :0
<teward|web> :) *
<lordievader> Aww :(
<infinity> A bit of a mess here, sorry.
<teward|web> infinity: no problem
<davmor2> infinity: take a deep breath, count to 10 and exhale
<teward|web> infinity: IMO, though, if it's being held off from the announce list, should it have actually been sent out?
<teward|web> (there are those who watch both lists, miscommunications like this will happen if people are watching both lists)
<infinity> teward|web: I shouldn't have sent it, apparently, but was only told that 30 seconds after I pressed send. ;)
<teward|web> ah OK :0
<infinity> teward|web: Life's like that.
<teward|web> :)  *
<cjwatson> teward|web: second-guessing isn't very helpful right now, please don't
 * teward|web kicks his keyboard out the window
<teward|web> cjwatson: ack
<nhaines> infinity: that sounds like the timimg's about right.  :)
<flexiondotorg> infinity, I'm getting an AccessDenied from cdimage.u.c. Is that intentional?
<infinity> flexiondotorg: Possibly.
<pietroalbini> flexiondotorg, it's working for me
<infinity> flexiondotorg: That would be the CloudFront redirect, which is perhaps still a work in progress.
<infinity> pietroalbini: Not the ISOs.
<flexiondotorg> Just the isos are Access Denied.
<infinity> flexiondotorg: Right, cause just the ISOs get redirected to AWS.
<pietroalbini> infinity, I can download xubuntu-15.10-desktop-amd64.iso without problems
<infinity> And that's the thing we've been sorting out for the last hour. :/
<flocculant> infinity and team - thanks :)
<nhaines> infinity: I'm tired, but I'm grateful it's not me.  :)
<flexiondotorg> infinity, OK.
<flexiondotorg> infinity, Lubuntu and Ubuntu MATE isos are Access Denied. The others appear to be working.
<cjwatson> flexiondotorg: try again?
<flexiondotorg> cjwatson, Thanks!
<cjwatson> (wasn't me, just passing it on :-) )
<flexiondotorg> Confirm Lubuntu and Ubuntu MATE iso downloads are working.
<flexiondotorg> cjwatson, Pass on my thanks :-)
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Wily 15.10 | Archive: opening freeze, britney block in place | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Wily 15.10 | Archive: closed, britney block in place | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<Pici> thanks for all the hard work everyone!
<cjwatson> changelogs.ubuntu.com meta-release stuff is live, so upgraders should start arriving
<chrisccoulson> can I push stuff to wily-security now?
<infinity> chrisccoulson: Yes.
<Laney> go nuts
 * Riddell sheds a tear, that'll be my last release as release manager
<popey> nice work people!
<teward|web> great job, Release Team!
<willcooke> thanks release team!
<nhaines> Congrats, everyone!  :D
<ogra_> yay
<cyphermox> yeah, thanks all
<cjwatson> and we have a couple of hours left in the day to start opening xenial!
<Laney> Riddell: oh no
<cjwatson> that's the fun bit ...
<didrocks> thanks release team ;)
<Laney> thanks iso tester slash developer slash cheese eater
<flexiondotorg> infinity, cyphermox, Laney, popey, cjwatson, seb128, didrocks, ogra_, sil2100, mhall119, pitti, bregma - Thanks for your help with Ubuntu MATE 15.10!
 * mhall119 isn't sure what he did to help, but you're welcome :)
<flexiondotorg> You're all mention in out release notes - https://ubuntu-mate.org/blog/ubuntu-mate-wily-final-release/
<flexiondotorg> mhall119, The community catch up thing :-)
<sil2100> flexiondotorg: more like thank you for all your hard work! :)
 * ogra_ hugs flexiondotorg 
<sil2100> Congrats everyone
<flexiondotorg> So tired. many typos.
<mhall119> ah, happy to do that, let's do it again in the 16.04 cycle
<didrocks> flexiondotorg: thanks for your work on it! :)
<Laney> flexiondotorg: aim for upload access for +6 months?
<Laney> :)
<flexiondotorg> Laney, yeah. I've burneden you all enough ;-)
<flexiondotorg> And for those of you that don't know about it - https://ubuntu-mate.org/raspberry-pi/
<teward|web> flexiondotorg: i assume there'll be a Wily image?
<teward|web> :P
<flexiondotorg> teward|web, Already released :-)
<teward|web> flexiondotorg: nice.  Got a question for you but I'll go to the IRC chan for MATE
<flexiondotorg> Did it alongside all the hard work you fella were doing this week.
<slangasek> cjwatson, infinity: sil2100 has reminded me that we have packages in the wily phone stable overlay ppa that want binary copying forward into xenial; any reason I shouldn't do that immediately?
<cjwatson> slangasek: we literally only just initialised, give it a bit longer
<cjwatson> like a minute ago
<slangasek> ok :)
<slangasek> pitti: why is there a python-dbusmock package currently building in the stable-phone-overlay ppa?
<slangasek> sil2100: ^^ fyi
<pitti> slangasek: ... because pete-woods asked me to?
<pitti> like "I need this fix, please land in vivid and wily"
<pitti> bad timing?
<slangasek> pitti: pete-woods doesn't manage those ppas, the landing team does ;)  landings are supposed to be built in the silos, then binary copied to the overlay ppa
<slangasek> (after testing)
<pitti> slangasek: I discussed that with sil2100 a while ago (when we started doing that), and he was okay with that
<slangasek> ok
<pitti> i. e. essentially backporting from the devel series
<pitti> (which in this case is sid, but same difference)
<slangasek> it looked odd to me, and I'm currently queuing up packages for binary-copy to xenial, so it was noteworthy
<flexiondotorg> I was going to go to sleep, but I see Xenial is open for busy :-D
<flexiondotorg> *business
<flexiondotorg> OK, typo rate is high. Perhaps sleep now.
<slangasek> and there are three packages in the wily overlay that are older than the version in wily.... oxide-qt, ubuntu-touch-meta, unity-scope-mediascanner
<slangasek> chrisccoulson: hi, what's the difference between oxide-qt 1.9.5-0ubuntu1~overlay1 and 1.9.5-0ubuntu1?  Why was an ~overlay1 package needed?
<chrisccoulson> slangasek, I've no idea. The person who requested that could probably answer though
<slangasek> chrisccoulson: sorry, who would that have been? the package changelog points to you
<chrisccoulson> slangasek, it wasn't me :(
<slangasek> ok
<slangasek> ah, uploader field is sil2100
<slangasek> sil2100: ^^
<sil2100> Hey
<sil2100> No difference in source, it's just rebuilt in the overlay-ppa
<slangasek> sil2100: ok, why was that needed for wily?
<sil2100> Since dbarth wanted to make sure it's rebuilt against the proper media-hub that's on the phone
<sil2100> That was probably when we started landing wily to the overlay
<chrisccoulson> I know we need that for vivid, but why is that needed for wily? Shouldn't the proper media-hub have ended up in the archive?
<slangasek> "shouldn't" - maybe, but it didn't. archive has media-hub 4.0.0, wily overlay has 4.1.0
<slangasek> so that explains, at least
<slangasek> sil2100: fwiw in this case a version number > wily instead of < wily would have helped; I can't copy this oxide-qt package forward to xenial
<sil2100> Yeah, not sure if we want to copy the oxide-qt from the overlay, it anyway has lower version than what's in wily
<sil2100> Oh
<slangasek> sil2100: so we'll need another oxide-qt upload against the new media-hub, in xenial
<sil2100> slangasek: there's a new oxide-qt in flight now
<slangasek> ok
<sil2100> So this should get fixed this week probably
<chrisccoulson> note, 1.9.5 is obsolete now ;)
<slangasek> the other two packages with lower versions in the ppa are ubuntu-touch-meta (Mirv) and unity-scope-mediascanner (james-henstridge). -mediascanner seems to be straight up obsoleted by a -0ubuntu2 version in the archive
<slangasek> but due to pinning, the wily images are using the stale one from the overlay ppa
<slangasek> chrisccoulson: not so obsolete that it's not the latest version in the wily release... :)
<chrisccoulson> slangasek, it was until a minute or so ago https://launchpad.net/ubuntu/+source/oxide-qt/1.10.3-0ubuntu0.15.10.1 :)
<slangasek> heh
<slangasek> chrisccoulson: ok, will you be taking care to copy that into xenial?
<chrisccoulson> slangasek, I can't, but jdstrand probably could
<Mirv> slangasek: yes, https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_qt5-image-formats-plugins/+merge/274882 just needs retargeting to xenial
<Mirv> and done at https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_qt5-image-formats-plugins/+merge/275386
<infinity> pitti: autopkgtest for xenial, please.
<infinity> pitti: And ddebs.
<infinity> pitti: And retracers. ;)
<seb128> he called it a day 15 minutes ago or so, I guess that's going to be for tomorrow
<Laney> it says seb128 can do retracers
<Laney> ;-)
<seb128> lol
<infinity> seb128: Good thing you spoke up. ;)
<Laney> busted
<slangasek> cjwatson: overlay ppa copy> how about now? ;)  (In principle I think these packages should be treated as part of archive initialization, just from a different source, so shouldn't wait for e.g. toolchain to land)
<cjwatson> slangasek: just trying to fix the publisher
<cjwatson> which will be kind of useful in the cause of getting anything to build, so is higher priority
<cjwatson> and I would prefer to make sure it works before publishing more stuff
<slangasek> ack
<cjwatson> but shouldn't be too much longer - certainly hope not because it is pub o'clock
<slangasek> :)
<tsimonq2> so what now? Wily is released, do we still have tasks to do for Wily, or are we moving on to Xenial?
<cjwatson> wily's handed over to stable maintenance, we're working on opening xenial
<tsimonq2> cjwatson: so is Xenail opened right after the release of WIly, or does it take a bit?
<tsimonq2> *xenial
<cjwatson> like I say, we're working on it
<tsimonq2> ok :)
<cjwatson> it's not instant but we like it not to take too long
<apw> t'is normally opened as soon as soon as we have a name :)
<tsimonq2> (first time being around on this side for a release, just out of curiosity, no pressure intended)
<tsimonq2> apw: but we have a name
<cjwatson> and we are opening it
<cjwatson> so stop asking :)
<cjwatson> https://wiki.ubuntu.com/NewReleaseCycleProcess shows you how much we have to do
<cjwatson> we're about half-way through, in terms of step count, may not translate to half-way in terms of elapsed time
<tsimonq2> so what step are you guys on?
<cjwatson> 20
<tsimonq2> ok :)
<tsimonq2> any way that I can follow along, or do I just need to ask?
<cjwatson> we generally witter about it here as we go
<tsimonq2> ok :)
<cjwatson> slangasek: ok, feel free to do those copies assuming that you're checking manually for conflicts (and perhaps appropriateness) and that you're copying to xenial-proposed and not xenial :)
<slangasek> cjwatson: check and check
<cjwatson> (I assume it's possible that a package might have diverged in both directions between wily release and the overlay)
<slangasek> ah
<slangasek> if it diverged in both and the overlay ppa version is newer, then my method fails to detect this
<cjwatson> could probably work it out by a quick changelog grep
<slangasek> let me quickly check for any !-0ubuntu1 packages
<cjwatson> (cf. the thing that auto-promotes -security to -updates)
<cjwatson> copy-report, that's the one
<tsimonq2> typo here: https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
<tsimonq2> it says 15.04 in the title
<ogra_> the release shedule is only a template at this time of the release (usually at least)
<cjwatson> tsimonq2: I assume you're fixing since you have an edit lock
<ogra_> the actual schedule gets worked out at vUDS normally
<ogra_> but yeah, just fix it :)
<cjwatson> you might as well fix the "back to" link while you're there
<tsimonq2> ok, it just says please do not edit, so I wanted to check first
<tsimonq2> cjwatson: WHat do you mean?
<cjwatson> at the top, it says back to VividVervet
<cjwatson> rather than back to XenialXerus
<tsimonq2> oh hahahah
<tsimonq2> got it
<cjwatson> please do not edit> the point there is to stop people crowd-editing the schedule and introducing confusion, not so much for fixing typos and such, which is fine (and thanks)
<tsimonq2> ok :)
<slangasek> ok yes, these all check out
<slangasek> copying now
<cjwatson> slangasek: I assume you're taking care of getting the landing team to redirect their stuff to vivid-overlay + xenial, too?
<slangasek> cjwatson: yes
<cjwatson> cool
<tsimonq2> so as some people know, I am a teenager, so for Social Studies, I get to do a current events presentation on the release of Ubuntu 15.10!
<tsimonq2> I am happy!
<cjwatson> :-)
<tsimonq2> irrelevant?
<tsimonq2> oh hahahahahaha
<tsimonq2> should I create the XenialXerus page and just copy everything from WilyWerewolf, or should I let someone else do that?
<cjwatson> It's a pretty simple page, I think feel free to copy it, maybe with the not-yet-existent milestones commented out or something.  Have a look at the history of WilyWerewolf and see how it started
<tsimonq2> ok :)
<tsimonq2> I have to go, end of Study Hall, here it is: https://wiki.ubuntu.com/XenialXerus
<cjwatson> thanks!
<tsimonq2> and it only shoes children to that page
<tsimonq2> *shows
<tsimonq2> so yeah
<tsimonq2> bye
<cjwatson> ah yes
<slangasek> y
<slangasek> cjwatson, sil2100: wily overlay-ppa -> xenial-proposed copy done
<sil2100> slangasek: \o/ thank you!
<cjwatson> gcc-5 will need to be retried once binutils has built and published everywhere
<cjwatson> (that one perhaps could be a dep-wait, I think it's in the category of things the LP webapp isn't quite smart enough to process so buildd doesn't emit dep-waits for those)
<davmor2> cyphermox: did you have any joy with that screen reader issue?
<robru> oooOOOOoooooh, xenial
<slangasek> I keep wanting to pronounce that 'genial' as in Spanish, but that is etymologically incorrect :(
<cyphermox> davmor2: sorry, I did not dig in more into it; there are other bugs higher in priority this week :)
#ubuntu-release 2015-10-23
<tsimonq2> so do we have a progress update since I was last on? or is it pretty obvious?
<pitti> infinity: ddebs should set themselves up, retracers and autopkgtests coming now
<pitti> http://ddebs.ubuntu.com/dists/xenial/ -- yup
<pitti> infinity: there's no britney for xenial yet either
<pitti> infinity: xenial autopkgtest queues ready for business; but I stopped the ppc64el workers, see #u-devel
<pitti> infinity: are you going to switch $DEFAULT_SERIES in britney1-ubuntu and set up britney, or want me to walk through it?
<flocculant> slangasek: hi - could you look at the xubuntu core MP again, there are changes following your disapprove, we really want to get this in as soon as possible so we get as much cycle as poss to test it https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<flocculant> thanks :)
<Riddell> adios chicos, it's been a pleasure working with you, I don't expect I'll be going too far https://kubuntu.org/news/jonathan-riddell-stands-down-as-release-manager-of-kubuntu/
<pitti> infinity, Laney: do you have a magic script to move over wily's proposed packages (except the new ones which got accepted today) over to xenial?
 * pitti bbl
<infinity> pitti: I don't have a magic script, I do it by hand, ish.
<cjwatson> Riddell: Good luck
<doko> just filed the ticket (#38) to create new chroots on the developer boxes
<Riddell> thanks cjwatson :)
<pitti> grep: /home/ubuntu-archive/public_html/proposed-migration/xenial/update_excuses.html: No
<pitti> +such file or directory
<pitti> cjwatson, infinity: ^ should I just go ahead and create that dir, or is there something more to it?
<pitti> (cron mail on snakefruit)
 * pitti mkdirs, what could possibly go wrong :)
<Laney> will need to update the symlinks too
<pitti> ah, is that manual? ok
<Laney> AFAIK
<pitti> but I'll wait with that until we actually have a report
<pitti> Laney: I had assumed DEFAULT_SERIES=wily â DEFAULT_SERIES=xenial would do that
 * pitti commits that
<pitti> hah, infinity just beat me to it
<infinity> pitti: Did your pkg-create-dbgsym upload break me? :P
<infinity> https://launchpadlibrarian.net/222260532/buildlog_ubuntu-xenial-armhf.vim_2%3A7.4.826-1ubuntu1_BUILDING.txt.gz
<pitti> infinity: wut?
<infinity> ^-- That seems weird.
<cjwatson> mkdir was unnecessary, p-m would've done that once it started running for the right series.
<pitti> cjwatson: ah, ok
<pitti> infinity: apparently so, meh; let me upload a revert, then I'll investigate
<infinity> pitti: I removed 0.70 as well to hurry the process along.
<pitti> infinity: ah, even better; then I don't even need to upload a revert, right?
<pitti> ood, there's no python* package involved at all, which was the only case that this changed
<infinity> pitti: That vim build concerns me, given that it succeeded on most arches, but not all, seems likely there's some sensitivity to parallelism or other raciness going on.
<pitti> it smells more like this bug has been there for quite some time, and we've just been lucky (or retried the builds without much investigation)
<infinity> pitti: Possibly.
<infinity> pitti: Are we almost ready to move to the debhelper-based implementation and scrap ours?
<pitti> infinity: I didn't look at that yet
<pitti> infinity: but the debhelper one spits out *.debs, not *.ddebs, so I figure before we do that we need some rework in LP and ddeb-retriever
<pitti> (which won't be a "ddeb"-retriever any more then)
<infinity> pitti: Err, really?  I thought there was some back and forth on that and then it ended up being ddebs?
<pitti> infinity: hm, then I didn't get that; I saw the discussion and had the impression they sticked to *.deb
<infinity> pitti: I'm somewhat opposed to a non-policy-compliant deb-like thing being .deb
<pitti> me too, but I think the argument was something like "similar to -dbg.deb" or so
<infinity> pitti: Anyhow, if you're sure this bug can't possibly relate to 0.70, I can just copy it back in place.
<infinity> I'm retrying that build with 0.70 right now.
<pitti> infinity: it's very unlikely; the effective diff was
<pitti> if [ "$pkgname" != "${pkgname#python}" ]; then
<pitti>    <ignore>
<pitti> but there is no python* binary in that vim build
<pitti> infinity: indeed it looks like dh_strip and dh_gencontrol run in parallel for the same packages
<infinity> pitti: Well, it should succeed/fail in ~7m.
<pitti> indeed pkg-c-d is currently assuming that dh_strip runs before dh_gencontrol
<infinity> pitti: Could be a parallelisation error in dh or vim, but I've never seen this before, so weird.
<pitti> hm, debian/rules looks okay
<infinity> Yeah, it looks pretty serial.
<infinity> It exports MAKEFLAGS=-j, but that shouldn't suddenly mangle recipes within a target. :P
<pitti> infinity: submitted bug 1509299 and attached the build log to it, as they tend to disappear on retries
<ubot2> bug 1509299 in pkg-create-dbgsym "parallel build race condition between dh_gencontrol and dh_strip" [Undecided,New] https://launchpad.net/bugs/1509299
<infinity> pitti: Ta.  The weird thing is that this wasn't isolated, that build failed on armhf *and* powerpc (succeeded on ppc on retry, armhf is still building).
<infinity> pitti: Which seems weirdly frequent for a rare race we've never noticed before.
<infinity> pitti: But maybe I'm just having an unlucky Friday.
<pitti> ok, treating that as medium for now; /me looks at broken ddebs.u.c. indexes then
<doko> infinity, pitti: it's a rules error
<doko> the indep and arch targets are run in parallel
<doko> I don't know if it's a make issue, or a rules issue, the export of the different DH_OPTIONS goes wrong. yeah for -j as the default in dpkg :-/
<pitti> ah, that's why all the lines appear twice
<infinity> Probably not dpkg's fault, he's setting MAKEFLAGS.
<infinity> I can turn that into a PARALLELFLAGS and pass it explicitly just to the build target makes.
<doko> yep, "because it should work", done without testing
<pitti> ah, it never sets DH_OPTIONS=-a or -s
<pitti> just -i
<doko> anybody working on a dpkg merge?
<infinity> I will, yes.
<infinity> s/will/am/
<doko> ta
<infinity> pitti: Copying your package back in.
<pitti> infinity: cheers
<pitti> infinity: OOI, where do you copy it from?
<infinity> copy-package -s xenial-proposed --to-suite=xenial-proposed --force-same-destination --silent --auto-approve -e 0.70 -b pkg-create-dbgsym
<pitti> wow
<pitti> you can copy deleted packages?
<infinity> Yup.
<cjwatson> sure can
<pitti> neat
<pitti> hm, britney still doesn't run, wth
<pitti> I got another mail about the missing /home/ubuntu-archive/public_html/proposed-migration/xenial/update_excuses.html, so archive-reports clearly ran
<pitti> but proposed-migration/code/b1/ wasn't pulled yet
 * pitti pulls it manually and sees if that helps somehow
<Laney> run-proposed-migration is supposed to do that
<pitti> yeah, that's what I thought too
 * Laney can see it right there
 * pitti tries DISTRIBUTION=ubuntu SERIES=xenial run-proposed-migration
<pitti> and sure enough that immediately exits
<Laney> the STOP file
<pitti> ah! proposed-migration/STOP  exists
<Laney> :)
<pitti> I guess leftover from yesterday?
<infinity> Yep.
<pitti> tail -f proposed-migration/log/xenial/2015-10-23/11\:08\:46.log
<pitti> muuuc better
 * pitti tosses in a 'h'
<Laney> betterh
<pitti> Laney: no; "better, haha!"
<cjwatson> Right, I touched STOP yesterday to stop it doing stuff with wily
<pitti> yay, 238 xenial test requests on all three arches
<pitti> that'll keep stuff busy over the weekend :)
<cjwatson> Hopefully it'll migrate base-files soon so that people stop complaining about launchpad-buildd recipes producing wrong versions
<pitti> Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
<pitti> (also, outstanding tests, but this needs unblocking too I figure)
<infinity> Yeah, we might want to keep the block there for now, but unblocking base-files is sane.
 * infinity does that.
<cjwatson> Removing block-all source is on NRCP
 * infinity does that after checking the diff.
<cjwatson> infinity: looks like you did branch-livefses?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and *.yaml etc. is still wily, I'll adjust the symlinks
<infinity> I did yesterday, yes.
<infinity> doko: Your base-files merge dropped os-release from conffiles.
<doko> infinity, intended
<infinity> doko: ?
<doko> moved to /usr/lib
<doko> or is there a mistake?
<pitti> oh, and /etc/os-release becomes a symlink?
<cjwatson> http://bugs.debian.org/753658
<ubot2> Debian bug 753658 in base-files "/etc/os-release has moved" [Normal,Fixed]
<pitti> shoudln't it move to /lib then, as long as we still have separate /usr ?
<infinity> Probably.
<cjwatson> Eh, whatever; we have separate /usr but it's always mounted
<cjwatson> AIUI
<doko>   * Moved /etc/os-release to /usr/lib/os-release. Put a symlink pointing to
<doko>     the new place. Thanks to Marco d'Itri for the report. Closes: #753658.
<pitti> I got debian bug reports from people with separate /usr who didn't have an initramfs; not that I think that this is even remotely sane/supported, but just saying
<pitti> yay for not being a conffile any more, though
<infinity> doko: Also dropped a newline from /etc/issue accidentally.
<doko> ouch
<doko> pitti, so should that be move to /lib/os-release? is there a spec / documentation referencing /usr/lib/os-release?
<pitti> doko: I read the debian bug now, should be fine
<pitti> doko: indeed we mount /usr in the initramfs, so that's fine
<pitti> doko: man os-release
<infinity> Hrm.  Not convinced that symlink should be shipped in the package.
<infinity> Seems like it should be written once in postinst.
<infinity> So users can replace it with a file.
<doko> why do you want it to be replacable?
<infinity> Because /etc/os-release is for user overrides of /usr/lib/os-release
<infinity> There's no point in having both locations if they're always identical.
<infinity>        The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should
<infinity>        check for the former, and exclusively use its data if it exists, and only fall back to
<infinity>        /usr/lib/os-release if it is missing.
<doko> "/etc/os-release should be a relative symlink to /usr/lib/os-release, to provide
<doko>        compatibility with applications only looking at /etc."
<infinity> Yeah, I read that as "it should default to being a symlink", but I agree the doc is ambiguous between my paste and yours. :P
<infinity> There's not much point in defining precedence, if they're always the same.
<rbasak> They don't seem to have provided any rationale for having it available in the tree in both places.
<infinity> rbasak: Except for the usual systemd/coreos rationale of
<infinity> "/usr is immutable default configs, /etc is overrides"
<infinity> Likely the only reason for os-release to also ship the symlink is because it used to live in /etc, so it needs backward compat with software that only looks there.
<infinity> Unlike systemd units, etc, which we've expected in /lib from day one.
<rbasak> It was supposed to be yet-another-standard-to-rule-them-all, and now we have two of them?
 * rbasak is feeling grumpy
<cjwatson> Never believe such claims.
<cjwatson> Then you can be grumpy all the time rather than having your hopes inevitably dashed.
<rbasak> Well, I never particularly believed it in the first place. But it would have been nice if they had thought of this before changing it and making everyone leave cruft everywhere.
<rbasak> Given that moving it to /usr/lib won't benefit Debian, why move it at all?
<rbasak> Might as well just keep it in /etc.
<rbasak> (not that it matters as it's moved now)
<rbasak> Then we could just skip straight to their fifth iteration when they decide on it.
 * rbasak will stop ranting now.
<xnox> rbasak: in clearlinux, we don't have /etc/os-release and have been fixing everything to start checking both locations. E.g. last discovery was docker, and the merge proposal to fix it is not yet upstream nor released.
<xnox> infinity: systemd accepts units from /usr/lib, even on /lib enabled systems.... it's kind of freaky.
<xnox> rbasak: i don't think os-release was for debian benefit...
<rbasak> xnox: it's to have one standard everywhere. But now we have two standards everywhere. If /etc/os-release is the one required and more universally available, then I don't see any need to do anything different now.
<xnox> rbasak: the os-release spec says: use /etc/os-release if present, otherwise check /usr/lib/os-release as well.
<xnox> (well the updated spec, original only had /etc)
<rbasak> xnox: deciding it should be somewhere else now doesn't necessarily mean that the spec has to be changed like it has been done.
<xnox> rbasak: the change enables "thin" derivatives. With mostly identicaly /usr (read-only / atomic), yet enough custom stuff in /etc & e.g. /opt to warrant a change in os-release.
<rbasak> xnox: the change goes beyond that. It only needed to be changed to say that /etc/os-release may be a symlink.
<xnox> there is no requirement for it to be a symlink.... and in practice it shouldn't be a symlink. it should either be a different thing, or not exist at all.
<xnox> and not everything supports symlinks....
<rbasak> xnox: I didn't say that there was a requirement for it to be a symlink. Read what I said.
<xnox> rbasak: sorry, then i don't understand. both old and new standard say nothing about whether or not it's a real file, or symlink somewhere else.
<xnox> rbasak: and the change was not about symlinks, or moving locations. but splitting immutable & configurable parts. Previously it wasn't like that and rpm doesn't have sensible config file handling ;-)
<rbasak> xnox: "both old and new standard say nothing". No, that's wrong. It says "/etc/os-release should be a relative symlink to /usr/lib/os-release..."
<rbasak> xnox: I'm saying that this "should" is unnecessary. The spec only needed to be amended to say that /etc/os-release may be a symlink, and no changes in "shoulds" for OS implementors or changes in "shoulds" in how apps should read the file would have been necessary.
<xnox> rbasak: the goal is to drop file from /etc. and make it muitable. what you are proposing whould not achieve that, especially on rpm systems which have broken config handling.
<xnox> rbasak: as in on upgrade /etc/os-release.rpmNEW was written out without updating /etc/os-release -> not good =)
<xnox> rbasak: at the moment we are in a transition period.
<xnox> rbasak: this is /etc -> /lib mistake, as have been seen e.g. with udev.d rules. one would think, that history would be learned.
<tsimonq2> xnox: how so?
<xnox> tsimonq2: how so, what? udev past mistake? initially udev rules were only loaded from /etc cause it needs to be customizable and at early boot. Later, people did modify these, upstreams/upgrades rename things resulting in an utter mess. Hence udev rules got moved to [/usr]/lib location and /etc became just an overlay, for admin customizations. Segregating system defaults from admin customizations. If one doesn't segregate system & admin defaults,
<xnox> there is no easy upgrade path.
<xnox> tsimonq2: http://blog.surgut.co.uk/2015/03/boiling-frog-or-when-did-we-loose-it.html
<tsimonq2> xnox: no, 07:44:47 AM < xnox> rbasak: at the moment we are in a transition period.
<tsimonq2> xnox: first time seeing this end of things, so I am curious.
<xnox> tsimonq2: once one no longer wants to support old tooling parsing /etc/os-release, one can and will drop such symlink.
<xnox> tsimonq2: read the os-release man page. it does state said symlink is for backwards compat only.
<tsimonq2> xnox: I didn't want to know about that issue at all :)
<xnox> =)
<tsimonq2> xnox: I just wanted to know where we are at
<tsimonq2> xnox: what step are you guys on? https://wiki.ubuntu.com/NewReleaseCycleProcess
<xnox> tsimonq2: i'm not doing it. wait for "open for development" email to ubuntu-devel-announce.
<xnox> like last one, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-May/001134.html
<tsimonq2> oh
<tsimonq2> xnox: so is that step 28? Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output.
<xnox> tsimonq2: no.
<xnox> tsimonq2: i said, i do not know. hence assuming it is not open. it will be open for development, once the email is out. so wait for that.
<tsimonq2> ok :)
<cjwatson> tsimonq2: Waiting to make sure that autopkgtests have their lives sorted out sufficiently to be able to let stuff migrate to xenial, I think.
<cjwatson> infinity: I guess once we see base-files migrate successfully, we can unblock the world and open?
<tsimonq2> cjwatson: I know I am (maybe) gonna irk you, but what step is that?
<cjwatson> tsimonq2: I don't remember.
<cjwatson> It's not completely linear.
<cjwatson> A lot of it is "make sure not to forget this stuff", not "must be done in exactly this order".
<tsimonq2> ok :)
<tsimonq2> cjwatson: so after xenial is unblocked, is that when it is marked as Development in Launchpad?
<cjwatson> Yes
<tsimonq2> cjwatson: and when the announcement is sent out?
<cjwatson> I would assume so.
 * tsimonq2 whispers to himself, "step 28"
<tsimonq2> â â£ â
<pitti> infinity: AFAICS everything on http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.yaml should be moved to xenial; want me to do that?
<pitti> (I thought I saw some "real" wily SRUs being accepted, but openjdk-9 is the most recent one and not an SRU)
 * pitti moves wily-proposed cruft to xenial-proposed, to clear up the way for SRUs
<infinity> pitti: I'm doing it now.
<cjwatson> ^- log4cxx should help base-files migrate
<infinity> cjwatson: Also, I'm reminded every 6 months that I really want a copy-package --with-or-without-binaries-yknow-whatever option. :P
<pitti> infinity: already copied to xenial
<infinity> pitti: Oh.
<pitti> infinity: I'm removing them from wily-proposed now
<pitti> infinity: xenial-proposed of course, sorry
<infinity> pitti: Did you watch carefully to make sure they all succeeded?
<infinity> pitti: In that ones with binaries need -b and ones without will fail with -b.
<pitti> I ran with -b, and got "1 package successfully copied." on the FTBFS ones
 * infinity raises brow.
<pitti> but Laney says there are some rejections, checking
<infinity> Did someone fix that since wily opening?
<pitti> Copy candidates:
<pitti>  node-srs 0.4.8+dfsg-2 in wily
<infinity> pitti: Oh.  copy-package told you that.
<pitti> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
<pitti> 1 package successfully copied.
<pitti> e. g. that
<infinity> pitti: copy-package lied.
<pitti> yeah, it might be lying
<infinity> pitti: You probably have a ton of mail.
<infinity> pitti: Also, you might want to use --silent, no need to spam the world with this. :P
<infinity> pitti: But I'll let you sort the mess now that you started.
<infinity> (Welcome to "things that look simple when someone else does them")
<pitti> yep
<pitti> heh :)
<pitti> yeah, will use --silent next time, sorry
<cjwatson> I've made copy-package's output a little less misleading.
<cjwatson> (It'll say "1 copy requested." now)
<pitti> thanks
<pitti> so I'll re-copy the rejected ones with --silent and without -b
<cjwatson> And yeah, I should fix the copier at some point ...
<cjwatson> pitti: I'm sure http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#base-files should be showing log4cxx/amd64 has "Always failed" by now - it's been at least a few cycles
<cjwatson> Oh, though I guess it could have been requested again
<cjwatson> pitti: Do you have any way to push dict-foldoc and log4cxx up the queue?  I believe we're only waiting for those to get base-files migrated.
<cjwatson> And then hopefully we can unblock and open.
<pitti> cjwatson: no, didn't run yet (click on the individual packages, you won't see a result from yesterday or today), e. g. http://autopkgtest.ubuntu.com/packages/d/dict-foldoc/xenial/amd64/
<pitti> the older ones are the latest successful ones I copied from wily
<pitti> to be able to continue to track "regression" vs. "always failed"
<pitti> queues are 181 on amd64, 194 on i386
<pitti> and lcy01 is still only running with max 5 instances, as with anything more it keeps falling over :(
<pitti> ok, copied the FTBFS ones
<pitti> e. g. https://launchpad.net/ubuntu/+source/mpdris2/+publishinghistory
<infinity> pitti: Kay.  I have a script here to check both match.  So, after a publisher run, I can verify that, then we can go on a deleting spree.
<infinity> pitti: Unless you trust yourself enough that you've started deleting already. :P
<pitti> infinity: err, sorry, I already did
<infinity> Heh.
<pitti> I spot-checked some 5 packages, and they looked ok
<pitti> we'll get almost all of them back during autosyncs too, but there are a few -ubuntuN ones, so I mostly checked those
<pitti> but also e. g. https://launchpad.net/ubuntu/+source/bup/+publishinghistory
<infinity> pitti: I'll double-check for paranoia in a bit.
<pitti> infinity: http://paste.ubuntu.com/12903087/ is the package list of everything that was in wily-proposed
<cjwatson> pitti: log4cxx ran today, but a bit earlier perhaps.
<cjwatson> So maybe your copies.
<infinity> pitti: Yup, I have the same list.
<pitti> cjwatson: no, I only copied the latest successful result, no failed ones (as they don't serve any purpose)
<pitti> cjwatson: the point is just that if we get a failure as the first "real" xenial run we need to tell apart regression vs "always failed", so I "seeded" xenial with the latest "pass"
<pitti> infinity: let's see for how much longer we'll drag cairo-5c along :)
<cjwatson> I'm failing to wrap my head around that today, but I guess I don't in fact need to know :)
<pitti> cjwatson: ok, sorry; indeed http://autopkgtest.ubuntu.com/packages/l/log4cxx/xenial/i386/ is a valid run and britney should consider it
<infinity> pitti: I feel like it's the real champion here.
 * pitti checks
<infinity> Oh.  Did someone bring forward the britney history?
<pitti> infinity: how do you mean?
<infinity> Erk.
<pitti> infinity: we didn't copy the wily autopkgtest results if you mean that, which is probably the reason for a good chunk of the ~ 300 test requests that we got after opening
<pitti> infinity: but at least python3-defaults, debhelper etc. are genuine new requests
<cjwatson> Oh, Dates ...
<infinity> cjwatson: Fixed.
<cjwatson> infinity: you fixed Dates, or something else?
<infinity> Dates.
<cjwatson> That was quick.
<infinity> I have a way with shells?
<pitti> oh, for keeping the 523 days or whatnot of cairo-5c? :-)
<pitti> can't lose that record!
<cjwatson> Well, I assumed it couldn't just be a copy, because we've had uploads since opening.
<infinity> Hopefully, the run in progress doesn't undo my handiwork.
<infinity> cjwatson: I concatenated and sorted wily and xenial into a new xenial.
<cjwatson> Cool.
<pitti> oh, wth
<infinity> Oh, hrm.  That has some dupes, though.  Might need to be more clever.
<pitti> cjwatson: ah, that's it -- teh result is for base-files/9.4ubuntu1 (and that's already in britney's cache)
<pitti> cjwatson: but there was another upload ubuntu2 to fix the missing newline
<infinity> If britney doesn't rewrite it to fix it.
<pitti> and that's still in the queue
<pitti> cjwatson: so, I have a really awful way of expediting this, if desired
<pitti> I could flush the entire queue, stuff these 4 tests back in, and then let britney re-create the other test results
<pitti> can't directly reorder an AMQP queue, sorry
<pitti> while I'm at screwing up things, let's do that :)
<cjwatson> infinity: britney should fix it, I think
<infinity> cjwatson: S'ok, I just learned a new shell trick.
<cjwatson> (haven't checked, I'm knee-deep in twisted code)
<infinity> sort -u -k1,1 Dates > Dates.new
<infinity> (To sort on only the first field)
<pitti> ok, base-files tests are now at the front of the queue
<pitti> all four running on http://autopkgtest.ubuntu.com/running.html now
<pitti> infinity: turns out I didn't actually remove yet as it stumbled over openjdk-9 which you already removed
<pitti> infinity: I have the Remove [y|N] prompt now; do you still want to run your script first?
<pitti> (it takes ages to even get to that point)
<infinity> pitti: I'll check right now, yeah.
<infinity> Looks like my Dates hacking worked.
<infinity> pitti: I see some still missing, so either snakefruit's mirror is behind, or you missed a few.
<infinity> pitti: Waiting and trying again/
<pitti> infinity: ah, you're checking on archive.u.c., not LP publishing
<infinity> pitti: Well, snakefruit, but yes.
<infinity> (ie: rmadison)
<pitti> ok; /me cancels this and stashes the remove-package command for later
<cyphermox> slangasek: ^ fwupdate.
<infinity> pitti: No, you really did miss some.  Spot-checking my list against publishing records, there are some xenial records missing.
<infinity> pitti: http://paste.ubuntu.com/12903342/
<cjwatson> pitti: thanks
<pitti> infinity: fun; thanks for the pastebin, copying those again then
<infinity> pitti: Most of those have binaries, I think, so need -b, but I didn't check them all.  It might be a mix.
<pitti> infinity: hm, so maybe it stops at the first error or so
 * pitti might need to re-do the loop to call copy-package individually on each one, instead of a big batch
<pitti> ok, plastimatch, ruby-gsl, and statsmodels worked now
<infinity> pitti: When you think you've cleaned it all up, lemme know and I'll double-check again. :P
<pitti> meh, --silent also disables rjection mails
 * pitti throws hands in the air, mumble ridiculously complicated mumble
<infinity> pitti: Sometimes, it's best not to look behind the curtain.
<infinity> But, y'know, welcome back here.  We have tea and cakes.
<Laney> And snakes
<pitti> infinity, cjwatson: https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu2 promoted
<cjwatson> pitti: I think --silent disabling rejection mails could be argued to be a bug - the main purpose was to have a way to not spam with success mails in some cases
<cjwatson> pitti: base-files> excellent, thanks
<cjwatson> infinity: anything more before we open?
<pitti> infinity: I did the next round of copies (both with binaries and without -b for the FTBFS ones)
<pitti> but due to the complete lack of error messages I guess that again some packages might just silently have failed; so I guess it's waiting for pulisher now and rmadison again
<infinity> pitti: Yeah, we'll see shortly, yes.  You could check pending publishing records for all of them, but I'd rather see the archive consistent anyway.
<pitti> infinity: yeah, doing that would need a script; too much effort/error prone in firefox
 * pitti -> dinner, will check again after that
<infinity> cjwatson: Whoever's writing the email, and maybe confirming pitti's copies are sane.
<infinity> cjwatson: But we're pretty much thereish.
<pitti> infinity: can you re-run your script? I checked with rmadison again, and it seems to be ok now
<pitti> rmadison -s xenial-proposed $(cat remove-from-wily-proposed) > /tmp/out
<pitti> for p in $(cat remove-from-wily-proposed); do grep -q $p /tmp/out || echo $p; done
<pitti> where remove-from-wily-proposed is the above pastebin (i. e. packages from http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html)
<pitti> wow, e. g. https://launchpad.net/ubuntu/+source/jruby/1.7.22-1ubuntu1 actually built in xenial, but not in wily
<infinity> pitti: Confirmed, LGTM.
<doko> indeed a surprise
<infinity> pitti: Delete away.
 * pitti pushes the delete button and calls it a day/week
<pitti> infinity: safe travels back home!
<pitti> infinity: and congrats for the release
<infinity> pitti: Not going home for another two weeks, but I'll see you in Austin.
<pitti> infinity: oh, ok; you stay in London?
<infinity> pitti: Detour on the way home for a week, plus VAC.
<infinity> s/home/to Austin/
<Laney> bye pitti!
<pitti> Laney: bye, enjoy the weekend!
 * Laney is coming to .de ;-)
<pitti> ^ BTW, none of these syncs are urgent in any way, just stashing them after reviewing my merges
<Laney> ah yes, they made polkit support the old syntax
<Laney> or backported new stuff, or something
<pitti> Laney: no, new polkit is just a lot of backported bug fixes, and getting back in sync
<pitti> same for our ppolkit-qt-1 vs. polkit-qt5-1 split
<pitti> they are both in Debian's ppolkit-qt-1 package now, and we can remove polkit-qt5-1 source once built
<Laney> pitti: indeed, I remember that we (and debian) were blocked because of the JS stuff
<pitti> Laney: yeah, and I don't see that change anytime soon
<Laney> but smcv or someone backported a load of good stuff
<Laney> which is nice
<Laney> nanyway
<Laney> get going :)
<pitti> these poor test machines now won't have any free time on the weekend :)
<pitti> debci-xenial-amd64  465
<pitti> debci-xenial-armhf  321
<pitti> debci-xenial-i386   458
<Laney> did you get some more capacity?
<Laney> or still on 5?
<pitti> Laney: no, lcy01 is still brittle, only 5 on that; 8 on lgw01
<pitti> and of course 16 armhf LXC ones as usual
<Laney> mmm
<pitti> Laney: I had to disable ppc64el, as that's power7, and xenial is power8 now
<Laney> yeah I heard
<pitti> hope we can get scalingstack bos soon
<tsimonq2> I have a spare machine and I was wondering if I could use that to help somehow, maybe automated build machine, or somethibg of that nature...any ideas?
 * pitti waves, have a nice weekend everyone!
<tsimonq2> bai
<tsimonq2> spam much? XD
<sil2100> infinity, seb128, slangasek: hey! If anyone of you guys has a minute, we have a silo that introduces a new binary package to the qtmir source - qtmir-tests
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/46/
<cjwatson> infinity: I imagine I could copy and paste an email if you like.
<infinity> cjwatson: I expected doko might want to do one, but if he's not...
<infinity> doko: Did you have a "welcome to Xenial" mail drafted?
<cjwatson> I think we could unfreeze, since all this stuff going through the queue isn't exactly toolchain.
<infinity> Yep.
<infinity> We can thaw both the queue and britney, I think.
<infinity> Lemme do the former.
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Wily 15.10 | Archive: open | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<doko> infinity, cjwatson: yep, wanted to wait until the queues cleared up, and send it tomorrow. afk now
<cjwatson> All right, how about I turn on auto-sync?
<doko> then the queues will be busy with main, but anyway, they can do something over the weekend
<infinity> cjwatson: auto-sync on sounds fine by me.
<infinity> And I think I'll clear the britney block, if no one has any objections?
<cjwatson> doko: They may as well, no point in them being idle
<infinity> britney block clearing in 3...
<infinity> 2...
<cjwatson> auto-sync enabled
<infinity> 1...
<doko> infinity, yes please
<Laney> boom
<cjwatson> Conveniently, will run in three minutes
<infinity> Let's see how my PPC VMs hold up with 3.19 kernels instead of 3.13
<infinity> Hoping for a miracle, since I'll probably only check in daily while on VAC.
<cjwatson> Everything except arm64 should be pretty quick to clear now.
<infinity> Those poor Mustangs.
<infinity> If only they had I/O.
<infinity> And friends.
<cjwatson> And weren't trying to finish a test rebuild as well
<cyphermox> careful, soon they'll form a union.
<olli_> happy day after release day!
<olli_> does anyone know if slangasek is around today?
<infinity> slangasek might know if he's around.
<olli_> infinity, hanging out in the channel and replying are two slightly different but important things ;)
<infinity> olli_: Indeed.
<davmor2> olli_: assume he isn't till he says he is :)
<slangasek> olli_, infinity: I am around, but don't tell anyone
<slangasek> infinity, cjwatson: have either of you been filled in on the lxd breakage on the cloud images?
<slangasek> or are you all safely at the pub now? :)
<cyphermox> slangasek: no pub tonight on account of travelling tomorrow, it seems
<cyphermox> (at least, for me it's a good enough reason)
<slangasek> heh ok
<cyphermox> tacos ended the week quite well though.
<cjwatson> slangasek: didn't hear anything about it
<slangasek> cjwatson: ok.  is being addressed in a way that doesn't involve nasty archive surgery, so carry on ;)
<cjwatson> ok :)
<cjwatson> good grief auto-sync is still going
<bdmurray> slangasek: still about? I'm not certain how to proceed with bug 1509305.
<ubot2> bug 1509305 in ubuntu-release-upgrader "Kernel not upgraded during upgrade from Vivid to Wily" [High,Triaged] https://launchpad.net/bugs/1509305
<slangasek> hmm
<bdmurray> its a result of bug 1506169
<ubot2> bug 1506169 in software-properties "if linux metapackage is installed software properties will uninstall it" [High,In progress] https://launchpad.net/bugs/1506169
<slangasek> ah, ick
<slangasek> bdmurray: probably wants an upgrader quirk in u-r-u/u-m to unconditionally install linux-generic if there's no linux metapackage installed
 * doko looses hopes to quickly get a python3-defaults into the release pocket :-/
#ubuntu-release 2015-10-24
<infinity> slangasek: I heard about it last night, but I'm running off to get on a plane.
<Logan> oh dear
#ubuntu-release 2016-10-24
<tsimonq2> Two things actually.
<tsimonq2> cmst and libqtxdg
<tsimonq2> !info cmst unstable
<ubot5`> cmst (source: cmst): QT GUI for Connman with system tray icon. In component main, is optional. Version 2016.10.03-1 (unstable), package size 2159 kB, installed size 3026 kB (Only available for linux-any)
<tsimonq2> !info cmst zesty
<ubot5`> cmst (source: cmst): QT GUI for Connman with system tray icon. In component universe, is optional. Version 2016.04.03-2 (zesty), package size 2162 kB, installed size 2962 kB (Only available for linux-any)
<tsimonq2> !info libqtxdg unstable
<ubot5`> Package libqtxdg does not exist in unstable
<tsimonq2> !info libqtxdg zesty
<ubot5`> Package libqtxdg does not exist in zesty
<tsimonq2> Argh, :/
<tsimonq2> I wish ubottu could recognize source packages.
<tsimonq2> !info libqt5xdg-dev unstable
<ubot5`> libqt5xdg-dev (source: libqtxdg): Development files for libqtxdg. In component main, is optional. Version 2.0.0-4 (unstable), package size 20 kB, installed size 90 kB
<tsimonq2> !info libqt5xdg-dev zesty
<ubot5`> libqt5xdg-dev (source: libqtxdg): Development files for libqtxdg. In component universe, is optional. Version 1.3.0-4 (zesty), package size 14 kB, installed size 90 kB
<tsimonq2> slangasek: There. Those are two specific packages I would like synced but haven't been.
<slangasek> ok, will investigate a bit later
<tsimonq2> Thank you slangasek.
<Logan> slangasek: I also manually synced eclipse-mylyn-tasks-github because it apparently wasn't done automatically
<slangasek> ah, so auto-sync is currently set up with --dry-run
<slangasek> so I'm not sure if that's supposed to be dropped, since there's no reference crontab in VCS
<slangasek> infinity, cjwatson: is snakefruit cron for auto-sync supposed to have the --dry-run dropped?
<infinity> slangasek: I think we wanted to wait until the Perl transition was at least happy enough to make sure we didn't make all the packaging toolchain stuff explode.
<slangasek> ok
<infinity> slangasek: If that's now the case (I've been blissfully unaware of work all weekend), then yes, we can autosync.
<slangasek> infinity: the perl transition has been started; it hasn't progressed very far
<tsimonq2> Out of curiosity, Debian's or Ubuntu's? I assume Ubuntu's?
<infinity> Kay.  Something for me to tackle violently tomorrow morning then.
<infinity> tsimonq2: Yes, ours.
<tsimonq2> Ok, cool.
<infinity> tsimonq2: As in, if things sync out of order, debhelper and other things become uninstallable, and we get a sea of read from the autosyncs. :P
 * tsimonq2 hunts the tracker down and looks for simple things
<infinity> s/read/red/
<tsimonq2> infinity: Fun. :P
<slangasek> infinity: anyway, my question was more about the mechanics of how autosync is /supposed/ to happen, since --dry-run isn't mentioned on the NewReleaseProcess
<infinity> slangasek: Ahh, yes.  That's how it happens.  I think the bullet point still just says "talk to Colin", it can be changed to mention the specific tweak required instead.
<slangasek> infinity: yeah, it doesn't say 'talk to Colin', so :)
<infinity> Oh.
<infinity> Point 30.  I see.  Just out of date.
<infinity> Didn't used to have the dry-run option. :P
<tsimonq2> I assume y'all are talking about http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.24.html ?
<infinity> tsimonq2: That'd be the one.
 * infinity goes back to ignoring IRC until tomorrow morning.
<tsimonq2> o/ infinity
<tsimonq2> Not going to chase this around *too* much, but it seems "armhf build of gdal 2.1.1+dfsg-5 in ubuntu zesty PROPOSED" is caused by default-libmysqlclient-dev being uninstallable. Weird. I'd be curious to see what the problem is when it's found out.
<tsimonq2> Hmm, libfile-rsyncp-perl is mysteriously shown as FTBFS.
<tsimonq2> I have to do homework then sleep, so I'm not going to try to poke around with this any more tonight. I'll look into how you guys fixed this stuff tomorrow. o/
<slangasek> doko: reproducible ld.gold internal error on arm64, impacting the ghc transition: https://launchpad.net/ubuntu/+source/gitit/0.12.1.1+dfsg-2build5/+build/11062557
<slangasek> doko: oops, sorry, correction - not impacting the ghc transition because this is a pre-existing build failure
<pitti> stgraber: yay, thanks! s390x images are there now
<cjwatson> slangasek,infinity: The technical details of the switch indeed consist of removing --dry-run
<cjwatson> (Used to comment it out, but it was useful to have the log handy of what it would do)
-queuebot:#ubuntu-release- New: accepted owfs [arm64] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [powerpc] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [armhf] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [s390x] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [amd64] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [ppc64el] (zesty-proposed) [3.1p4-1]
-queuebot:#ubuntu-release- New: accepted owfs [i386] (zesty-proposed) [3.1p4-1]
<ginggs> Laney: hi, should I sync texinfo, or is it better to wait?
<Laney> ginggs: Don't have context - perl related I guess?
<Laney> ah yes, it's on the list
<Laney> ginggs: If it builds, go for it
<Laney> I'm doing dependency level 2 ATM so it'll get uploaded in a little bit anyway
<ginggs> Laney: it builds, so I'll sync it
<Laney> k
 * apw_ notes the NBS report is still running against yakkety
<Laney> apw: I think that particular one lives in ubuntu-archive-tools
<apw> Laney, no issues switching it over if i find it ?
<Laney> Not that I know of
<Laney> Would do it, but, y'know. :P
<apw> right hopefully that is changed over
<pitti> wgrant, cjwatson: \o/ we got zesty ddebs over the weekend
<pitti> wgrant: and that kernel ddeb was the only "failed to retriever" instance, so it seems it's all good
<apw> pitti, hrm, did we find the .ddeb for that ?
<pitti> apw: we did, it was just a temporary download glitch
<apw> phew
<cjwatson> pitti: good stuff
<cjwatson> and yeah, there was no backend corruption there
-queuebot:#ubuntu-release- New binary: lirc [ppc64el] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [amd64] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [i386] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [arm64] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [s390x] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [powerpc] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [armhf] (zesty-proposed/main) [0.9.4c-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (yakkety-proposed/main) [3.20.2-1ubuntu1 => 3.22.1-1ubuntu1] (ubuntu-desktop)
<jbicha> please reject gnome-desktop3/yakkety :(
<jbicha> I've become too dependent on 'dch -r'
<LocutusOfBorg> jbicha, FYI, lirc is fixed ^^
<LocutusOfBorg> it might even migrate if accepted (probably)
<jbicha> thanks
<apw> jbicha, done
-queuebot:#ubuntu-release- Unapproved: rejected gnome-desktop3 [source] (yakkety-proposed) [3.22.1-1ubuntu1]
<LocutusOfBorg> dch -R -D `distro-info --devel` "message"
<LocutusOfBorg> jbicha, ^^ this works as alias for the latest development release
 * LocutusOfBorg credits/copyrights go to cjwatson for his rebuild script :)
-queuebot:#ubuntu-release- Unapproved: libnl3 (trusty-proposed/main) [3.2.21-1ubuntu3 => 3.2.21-1ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: jellyfish [amd64] (zesty-proposed/universe) [2.2.6-1] (no packageset)
<sakrecoer> hi everyone! any news on the calligra/krita issue in ubuntustudio, what did you guys decide in the end? Maybe i get things wrong, but it seems if we do it the SRU way, since we have no uplaoder atm, we are going to have to poke arround once we have the deb diff...
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20161007-0ubuntu1 => 16.10+16.10.20161024-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu4.1]
<LocutusOfBorg> slangasek, please do the haskell-memoize kick out too=
<LocutusOfBorg> ?
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (xenial-proposed) [1:1.5.9-5ubuntu0.2]
-queuebot:#ubuntu-release- New: accepted jellyfish [amd64] (zesty-proposed) [2.2.6-1]
-queuebot:#ubuntu-release- New: accepted lirc [arm64] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [i386] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [ppc64el] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [amd64] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [powerpc] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [armhf] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- New: accepted lirc [s390x] (zesty-proposed) [0.9.4c-1]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (trusty-proposed) [1.5.5-2ubuntu1.6]
<slangasek> LocutusOfBorg: can you elaborate what needs kicked with haskell-memoize and why?
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.2-0ubuntu1]
<apw> ^ rejecting an old upload which has been subsumed by a later one in the queue
<LocutusOfBorg> slangasek, because it was wrongly syncd
<LocutusOfBorg> it requires ghc8
 * LocutusOfBorg leaves
<ginggs> [11:54:26] <ginggs> slangasek: do we still need a separate fftw3-mpi since archive re-org?
-queuebot:#ubuntu-release- New binary: ffmpeg [ppc64el] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libnl3 [source] (trusty-proposed) [3.2.21-1ubuntu4]
-queuebot:#ubuntu-release- New binary: ffmpeg [i386] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ffmpeg [amd64] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: fwts (xenial-proposed/universe) [16.03.00-0ubuntu1 => 16.03.00-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpeg [s390x] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: fwknop [ppc64el] (zesty-proposed/universe) [2.6.9-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-go.crypto (xenial-proposed/main) [1:0.0~git20151201.0.7b85b09-2 => 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: fwknop [arm64] (zesty-proposed/universe) [2.6.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwknop [armhf] (zesty-proposed/universe) [2.6.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwknop [amd64] (zesty-proposed/universe) [2.6.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwknop [i386] (zesty-proposed/universe) [2.6.9-1] (no packageset)
<slangasek> ginggs: we don't want fftw3-mpi in main; and we'll need to adjust the seed to keep it out
-queuebot:#ubuntu-release- New binary: fwknop [s390x] (zesty-proposed/universe) [2.6.9-1] (no packageset)
<ginggs> slangasek: so our separate fftw3-mpi package can be removed now?
<slangasek> I imagine so
-queuebot:#ubuntu-release- New binary: fwknop [powerpc] (zesty-proposed/universe) [2.6.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpeg [arm64] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ffmpeg [powerpc] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ffmpeg [armhf] (zesty-proposed/universe) [7:3.1.5-1] (kubuntu)
<ginggs> slangasek: ok thanks, should i file a bug for that?
<slangasek> ginggs: was this source package in Debian?  if not, yes please for bug
<ginggs> slangasek: no it wasn't in debian - will file bug
-queuebot:#ubuntu-release- Unapproved: fwts (trusty-proposed/universe) [14.03.01-0ubuntu3 => 14.03.01-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-proposed/universe) [4.4.0.1032.24 => 4.4.0.1033.25] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-snapdragon (yakkety-proposed/universe) [4.4.0-1032.36 => 4.4.0-1033.37] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-proposed) [4.4.0.1033.25]
-queuebot:#ubuntu-release- Unapproved: accepted linux-snapdragon [sync] (yakkety-proposed) [4.4.0-1033.37]
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (zesty-proposed/universe) [3.22.1-2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (zesty-proposed/universe) [3.22.1-2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [s390x] (zesty-proposed/universe) [3.22.1-2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [i386] (zesty-proposed/universe) [3.22.1-2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (zesty-proposed/universe) [3.22.1-2] (desktop-extra, edubuntu, ubuntugnome)
<slangasek> $ cat dist-ghc/test/cryptonite-0.15-test-cryptonite.log
<slangasek> Test suite test-cryptonite: RUNNING...
<slangasek> Test suite test-cryptonite: FAIL
<slangasek> Test suite logged to: dist-ghc/test/cryptonite-0.15-test-cryptonite.log
<slangasek> $
<slangasek> hnngh
-queuebot:#ubuntu-release- New binary: vala [i386] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [s390x] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu4.16.10.1 => 2.0.0-0ubuntu0.16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: vala [arm64] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [powerpc] (zesty-proposed/universe) [0.34.1-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libirman [ppc64el] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [arm64] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [s390x] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [armhf] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [amd64] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [powerpc] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libirman [i386] (zesty-proposed/universe) [0.5.2-0.2~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ffmpeg [arm64] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted ffmpeg [powerpc] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted fwknop [powerpc] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (zesty-proposed) [3.22.1-2]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (zesty-proposed) [3.22.1-2]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (zesty-proposed) [3.22.1-2]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted vala [i386] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted ffmpeg [armhf] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted fwknop [s390x] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (zesty-proposed) [3.22.1-2]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted fwknop [i386] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted vala [amd64] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (zesty-proposed) [3.22.1-2]
-queuebot:#ubuntu-release- New: accepted vala [powerpc] (zesty-proposed) [0.34.1-2]
-queuebot:#ubuntu-release- New: accepted ffmpeg [amd64] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted ffmpeg [ppc64el] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted fwknop [amd64] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted fwknop [armhf] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted ffmpeg [i386] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted fwknop [arm64] (zesty-proposed) [2.6.9-1]
-queuebot:#ubuntu-release- New: accepted ffmpeg [s390x] (zesty-proposed) [7:3.1.5-1]
-queuebot:#ubuntu-release- New: accepted fwknop [ppc64el] (zesty-proposed) [2.6.9-1]
<LocutusOfBorg> slangasek, sponsor please? http://paste.ubuntu.com/23376220/ (notmuch fix in armhf)
<slangasek> LocutusOfBorg: please don't make me fish patches out of a pastebin :)
<LocutusOfBorg> will appear here soon https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa
<LocutusOfBorg> accepted
-queuebot:#ubuntu-release- Unapproved: edk2 (yakkety-proposed/universe) [0~20160813.de74668f-1 => 0~20160813.de74668f-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New sync: firebird3.0 (zesty-proposed/primary) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New sync: emacs25 (zesty-proposed/primary) [25.1+1-1]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [sync] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New binary: firebird3.0 [s390x] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [ppc64el] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [amd64] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [powerpc] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [i386] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [armhf] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- New binary: firebird3.0 [arm64] (zesty-proposed/none) [3.0.1.32609.ds4-8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected golang-go.crypto [source] (xenial-proposed) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-go.crypto [source] (yakkety-proposed) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.10.1]
#ubuntu-release 2016-10-25
-queuebot:#ubuntu-release- New binary: nageru [ppc64el] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-go.crypto (xenial-proposed/main) [1:0.0~git20151201.0.7b85b09-2 => 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: nageru [amd64] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nageru [armhf] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nageru [arm64] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nageru [i386] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nageru [s390x] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nageru [powerpc] (zesty-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [ppc64el] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [s390x] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [i386] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [powerpc] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [amd64] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [armhf] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrumstick [arm64] (zesty-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libdrumstick [amd64] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [armhf] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [powerpc] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [s390x] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [arm64] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [ppc64el] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrumstick [i386] (zesty-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted nageru [amd64] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [armhf] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [powerpc] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [s390x] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [arm64] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [ppc64el] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted nageru [i386] (zesty-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [arm64] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [i386] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [armhf] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [powerpc] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [amd64] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [s390x] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New: accepted firebird3.0 [ppc64el] (zesty-proposed) [3.0.1.32609.ds4-8]
-queuebot:#ubuntu-release- New binary: pcp [amd64] (zesty-proposed/universe) [3.11.5] (no packageset)
<pitti> FTR: britney isn't being updated because swift keeps running into "proxy errors" or timeouts
<pitti> Laney: ^
<pitti> I'll watch it and notify IS if this persists
<Laney> pitti: I think I saw robr_u asking about swift problems yesterday also
<pitti> Laney: yeah, for "the" bileto ticket
<Laney> failing to upload files
<Laney> so already persisted for some time if it's the same problem
<pitti> it's the download direction for me
<pitti> nice, the next run seems to have finished, and so did my local (~pitti) run to test the new branch
<Laney> impressive queue size
<pitti> Laney: and that's only the s390x mass-retries for perl..
<pitti> (I didn't yet do it for the other arches as they are still catching up)
<Laney> pitti: Yeah, quite a lot of red on there
 * Laney is going through local failures now
<Laney> might fire them at a PPA though so others can see (and maybe some will randomly work on launchpad)
<davmor2> Laney, pitti: out of interest how long before there are daily iso's for z I assume not too long right?
<pitti> davmor2: there's nothing fundamental that would block those; not sure what it takes to switch them on
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (xenial-proposed/main) [14.04+16.04.20160804-0ubuntu1 => 14.04+16.04.20161024-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<pitti> Laney: wrt. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl, it seems there are two metric tons of packages which need no-change rebuilds or syncs; is anyone working on that?
<Laney> pitti: Have you been watching zesty-changes? :-)
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.24.html is getting more green
<pitti> Laney: no, I haven't; just looked at some random samples of uninstallability
<pitti> Laney: but if you are on it, great, I just wanted to know whether anyone is :)
<pitti> transition tracker> nice, so much easier
<Laney> soon it will be just the really broken things left
<pitti> I'll kill my retries then, not much point in those
<apw> Laney, wow, thats improved hugely
<Laney> apw: yeh, getting there
<Laney> levels 1 and 2 are basically now things that are actual problems
<Laney> I think the ones that are all red are removals that Debian did too
<apw> and mysql must be about half the rest :/
<Laney> (we should probably follow those)
<pitti> Laney: want me to go through process-removals?
<Laney> pitti: Not sure that tracks testing removals?
 * pitti ran it a week before release, I suppose most of the recent stuff since then is legit
<pitti> ah no, it's not
<Laney> If you find perl things in there though then go for it
<Laney> I'll file a bug later or tomorrow
<xnox> pitti, Laney: imho we should follow testing removals, with demotions to proposed.
<xnox> and an auto-bug filed "block-proposed" for those, to prevent migration straight back.
<pitti> Laney: through with process-removals; no perl stuff there
<Laney> yeah, not surprised
<Laney> thanks for doing a pass anyway
-queuebot:#ubuntu-release- New: accepted emacs25 [sync] (zesty-proposed) [25.1+1-1]
-queuebot:#ubuntu-release- New binary: fonts-tiresias [amd64] (zesty-proposed/none) [0.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted fonts-tiresias [amd64] (zesty-proposed) [0.1-3]
-queuebot:#ubuntu-release- New binary: emacs25 [s390x] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs25 [ppc64el] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs25 [powerpc] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs25 [i386] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs25 [amd64] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs25 [armhf] (zesty-proposed/universe) [25.1+1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (xenial-proposed) [16.03.00-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected fwts [source] (trusty-proposed) [14.03.01-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted emacs25 [amd64] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted emacs25 [i386] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted emacs25 [ppc64el] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted libirman [amd64] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted libirman [armhf] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted libirman [powerpc] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted libirman [s390x] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted emacs25 [armhf] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted emacs25 [s390x] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted libirman [i386] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted pcp [amd64] (zesty-proposed) [3.11.5]
-queuebot:#ubuntu-release- New: accepted emacs25 [powerpc] (zesty-proposed) [25.1+1-2]
-queuebot:#ubuntu-release- New: accepted libirman [ppc64el] (zesty-proposed) [0.5.2-0.2~build1]
-queuebot:#ubuntu-release- New: accepted libirman [arm64] (zesty-proposed) [0.5.2-0.2~build1]
<xnox> bagel/s390x builds "fine" locally. however it runs and ignores test-suite results.
<xnox> which appear to get stuck on launchpad. hitting retry, if that gets stuck as well, I shall disable running the test-suite on s390x.
<infinity> xnox: Lemme go watch the build in progress.
-queuebot:#ubuntu-release- Unapproved: fwts (trusty-proposed/universe) [14.03.01-0ubuntu3 => 14.03.01-0ubuntu4] (no packageset)
<infinity> xnox: Looks like bagel went fine on the retry.
<xnox> hmmm.... bagels
<ogra_> bah
 * ogra_ looks for food 
<clivejo> is there anyone I could talk to about accepting new KDE packages for upload?
<jbicha> clivejo: if they are brand new packages, it's really better to get them accepted into Debian first
<jbicha> otherwise you're asking the Ubuntu archive team members to duplicate the "new package review" that is already being done by the Debian ftp masters team
<clivejo> but we'll like to work on them in the time it takes Debian to publish them
<clivejo> sgclark: how did you get new packages into Ubuntu in the past?
<jbicha> you could try pinging one of the Debian ftp mastersâ¦
<infinity> (hint: ScottK can do Debian NEW review, and also cares about KDE)
<clivejo> Im trying to get kirigami into zesty
<clivejo> and will have lot of PIM related packages when we get that far
<cyphermox> could someone please reject golang-go.crypto in xenial queue, it's wrong
<infinity> Anyhow, it's not impossible to get a NEW package into Ubuntu, you just need someone to sponsor the upload.
<infinity> cyphermox: Done.
<cyphermox> ta
-queuebot:#ubuntu-release- Unapproved: rejected golang-go.crypto [source] (xenial-proposed) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1]
<clivejo> who can I get to sponsor it?
<sgclark> clivejo: I didn't. Had to beg. Try shadeslayer or ScottK
<clivejo> its the begging I dont like!
<sgclark> well then study up for MOTD :)
<sgclark> well then study up for MOTU rather
<clivejo> LOL, you first!
<sgclark> I probably should. So much to do, so little time.
<clivejo> then I can beg you :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.9+16.04ubuntu1 => 0.10+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.9+16.10ubuntu1 => 0.10+16.10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.3-0ubuntu1~ubuntu14.04.1 => 2.0.4-0ubuntu1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-backports/main) [2.0.4-0ubuntu1~ubuntu14.04.1 => 2.0.5-0ubuntu1~ubuntu14.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.4-0ubuntu1~ubuntu14.04.1 => 2.0.5-0ubuntu1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-backports) [2.0.5-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.5-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.4-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.0.5-0ubuntu1~ubuntu16.04.1 => 2.4.1-0ubuntu1~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.4.1-0ubuntu1~ubuntu16.04.1]
<slangasek> who could speak to debconf prompting being broken on Ubuntu-GNOME?  jbicha ?  LP: #1605376, LP: #1636597
<ubot5`> Launchpad bug 1605376 in shim-signed (Ubuntu) "(Ubuntu-GNOME, debconf passthrough) package shim-signed 1.17~15.10.1+0.8-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [High,New] https://launchpad.net/bugs/1605376
<ubot5`> Launchpad bug 1636597 in shim-signed (Ubuntu) "(Ubuntu-GNOME, debconf passthrough) package shim-signed 1.18~16.04.1+0.8-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1636597
<jbicha> slangasek: Ubuntu GNOME shouldn't be doing anything with debconf different than Ubuntu (Unity)
-queuebot:#ubuntu-release- Unapproved: lightdm (yakkety-proposed/main) [1.19.5-0ubuntu1 => 1.20.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.7 => 1:16.10.8] (core)
<slangasek> jbicha: well, that's definitely not the case, because Ubuntu-GNOME users get this error and nobody else does
<slangasek> jbicha: aptdaemon? packagekit?
-queuebot:#ubuntu-release- Unapproved: rejected lightdm [source] (yakkety-proposed) [1.20.0-0ubuntu2]
<jbicha> but Ubuntu GNOME 16.04 uses the exact same update tools as Ubuntu (Unity)
<infinity> I was fairly sure libgtk2-perl was required to make debconf popups DTRT, but I note it's not in ubuntu-desktop either...
<slangasek> it may be the same tools, but they're clearly wired up differently
<infinity> Or does update-manager do its own magic?
<slangasek> Ubuntu GNOME users get this error, Ubuntu Desktop users do not
<slangasek> infinity: no, update-manager passes through to debconf
<infinity> slangasek: Which would then imply that without libgtk2-perl, people are getting text prompts in the little terminal window...
<infinity> I think.
<slangasek> hmm I have libgtk2-perl installed here, maybe that's why /my/ debconf is broken ;P
<jbicha> it feels like a stretch to me to say based on 2 bug reports that there's a major problem with Ubuntu GNOME's debconfâ¦
<slangasek> it's not 2 bugs, those are the two I happened to have the numbers to hand for
<jbicha> oh ok, well I don't know anything about debconf :(
<infinity> I'm having a hard time seeing how this would differ between Ubuntu and Ubuntu GNOME, other than dumb luck.
<infinity> And "dumb luck" is never a good engineering strategy.
<slangasek> #1605376 #1605977 #1636597; so three bugs ;)
<slangasek> (which is 3 out of 16 open bugs)
<slangasek> there are also bugs with similar symptoms for Ubuntu Desktop, but only on trusty
<infinity> slangasek: Conclusion, all our users reinstalled with GNOME after trusty.
<jbicha> lol
<jbicha> all 3 of them!
<infinity> (Probably not)
<infinity> Unrelated: daily ISOs are cronned again and should start hitting the tracker over the next 24h.
<infinity> (base is there already, as it was the testcase)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.17 => 1:16.04.18] (core)
<santa_> pitti: it's a bit offtopic here but I have the impression I found a bug in autopktest, if you have a minute we could have a brief chat about it
<teward> infinity: if there's an nginx in zesty-proposed (held thanks to Perl migration), is there a problem with me putting another package into proposed that has a higher version that includes a fix for a CVE that was fixed by the Security team?  Ahead of the planned merge I'm working on from Debian, that is.  Or should I wait for my 'merge' to be ready for review (after the Perl migration, probably)
<slangasek> teward: the perl transition is going to take a while to finish up; if the new nginx merge doesn't bring other dependency issues, that should be ok
<slangasek> teward: I mean that merging the new one should be ok
<teward> slangasek: the merge is weeks away - the headache of switching from the static-binary builds to dynamic modules *and* a static binary is... treacherous
<slangasek> teward: oh, you mean an upload that just adds the security fix. yeah, there's absolutely no reason for you to not do that here
<teward> the upload that'd be done now is basically borrowing the changes done by mdeslaur to the Yakkety package and apply that to the Zesty package, until such time it's in debian and get absorbed into the merge.
<teward> yeah
<teward> slangasek: wanted to make sure it wouldn't torpedo anything
<teward> i want that security fix in, not the merge, at this point.
<teward> assuming the Security team has no objection.  cc: mdeslaur
-queuebot:#ubuntu-release- Unapproved: golang-go.crypto (yakkety-proposed/main) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.10.1 => 1:0.0~git20161012.0.5f31782-1ubuntu0.16.10.2] (kubuntu, ubuntu-desktop)
<xnox> slangasek, can you force boost1.60 & boost1.61 to become valid candidates; such that openmpi doom migrates; and i start boost1.62 transition, please =)
<xnox> slangasek, also mongodb 3.2 does not build on armhf, could you please remove mongodb/armhf from zesty-release pocket?
<xnox> missing build on armhf: mongodb, mongodb-clients, mongodb-server (from 1:2.6.11-1ubuntu1)
<slangasek> xnox: boost1.6x are not the cause of openmpi not being a candidate; but let's look at them anyway.  can you give me details about why the autopkgtest regressions should be overridden?
#ubuntu-release 2016-10-26
<tsimonq2> dpkg: error processing archive /tmp/apt-dpkg-install-SPDwR3/42-liblirc-client0_0.9.4c-1_amd64.deb (--unpack):
<tsimonq2>  trying to overwrite '/usr/lib/x86_64-linux-gnu/liblirc_client.so.0', which is also in package liblircclient0:amd64 0.9.0-0ubuntu6
<tsimonq2> Errors were encountered while processing:
<tsimonq2>  /tmp/apt-dpkg-install-SPDwR3/42-liblirc-client0_0.9.4c-1_amd64.deb
<tsimonq2> E: Sub-process /usr/bin/dpkg returned an error code (1)
<tsimonq2> Fun...
<tsimonq2> Am I stupid or did someone do something Very Very Badâ¢ ?
<tsimonq2> It may just be the former.
<tsimonq2> And I may have put this in the wrong channel...
-queuebot:#ubuntu-release- Unapproved: golang-go.crypto (xenial-proposed/main) [1:0.0~git20151201.0.7b85b09-2 => 1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: anjuta-extras (yakkety-proposed/universe) [3.10.0-4 => 3.10.0-4build0.1] (no packageset)
<slangasek> pitti: where did you see that the "latest s390x test is ok" for gerris?  what I see is an openmpi-related regression. http://autopkgtest.ubuntu.com/packages/g/gerris/zesty/s390x
<slangasek> pitti: and I see tests marked 'in progress' on ppc64el whose requests seem to have gotten lost (e.g.: libtest-xslate-perl, trigger: libdata-messagepack-perl/0.49-1build2).  I don't think retry-autopkgtest-regressions covers this case, does it?
<slangasek> ah, there's a --state option (though no documentation about the list of available states?)
<LocutusOfBorg> tsimonq2, I did a mistake in uploading lirc, a typo prevented smooth upgrade paths, because ubuntu was already multiarch, and debian wasn't. jbicha uploaded a fix 12 hours ago  0.9.4c-2ubuntu1
<pitti> slangasek: ah, I got asked to ignore gerris for now to unblock the transition, but indeed that looks like an actual bug; sorry, unhinting
<pitti> xnox: ^ FYI
<pitti> slangasek: retry-autopkgtest-regressions --state=RUNNING covers this
<ginggs> slangasek, pitti: that s390x gerris failure looks like the error when you try to run MPI programs in a chroot, do you want me to work around that?
<slangasek> ginggs: AFAIK the test is run in a container but not in a chroot; but why is this the only openmpi revdep tripping over the problem, since they all use the same testbed?
<slangasek> ginggs: anyway, I'm not sure what "work around" means here; it's a regression in the behavior of the tests, it's not clear to me if this is because of a regression in openmpi or because the test itself is buggy, but either way it should be fixed, rather than ignoring the test result with skiptest
<ginggs> slangasek: the debian maintainer recently removed the bits that allowed the tests to run in a chroot
<ginggs> https://anonscm.debian.org/cgit/debian-science/packages/gerris.git/commit/?h=master&id=b87f1f28b1661754178c504ac35119aaf895d267
<ginggs> I can try put that back and see if that does the trick, i asked yesterday if it would be better to hint this through so that openmpi can migrate
<slangasek> ginggs: at a glance, it looks like the run of the previous gerris's tests against the new openmpi failed with the same error
<ginggs> previous gerris was missing openmpi-bin
<ginggs> i can't think of a way to test this without uploading, shall i go ahead?
<slangasek> The value of the MCA parameter "plm_rsh_agent" was set to a path
<slangasek> that could not be found:
<slangasek>   plm_rsh_agent: ssh : rsh
<slangasek> how about fixing the tests to actually depend on ssh, if they require ssh?
<slangasek> it's not "doesn't work in a chroot", it's "doesn't work if ssh isn't installed"
<slangasek> (which is why it also applies to containers, and generally doesn't apply to VM testbeds)
<ginggs> we use the export OMPI_MCA_plm_rsh_agent=/bin/false trick a lot when MPI programs are run during the build
<slangasek> ok, then why was it dropped for this one?
<slangasek> regardless
<ginggs> I don't believe ssh is actually required unless you have the same MPI job running across multiple hosts
<slangasek> the general answer to "should we override the tests to let the transition in" is "no"
<slangasek> and I would think xnox in particular would care about not increasing the test failure rate on s390x :)
<ginggs> ok, so shall i put back export OMPI_MCA_plm_rsh_agent=/bin/false and upload?
<slangasek> if that's considered a correct fix for this
<pitti> ginggs: so I figure this should also be exposed when you run this in a local amd64 lxc?
<pitti> ginggs: i. e. it's not s390x specific?
<ginggs> pitti: yeah, i think it's better to have the export back (provided it doesn't break the other arches) but i don't know to test without uploading
<pitti> ginggs: I can walk you through testing with LXC
<ginggs> BTW, there is a bug for this #841885
<pitti> ginggs: autopkgtest-build-lxc(1) describes how to build them
<pitti> hmm, https://ci.debian.net/packages/g/gerris/unstable/amd64/ started to fail much earlier (that's also lxc)
<ginggs> pitti: yeah, they are missing openmpi-bin there
<ginggs> pitti: does setting up autopkgtest-build-lxc need download a lot of stuff? i don't have good interwebs at the moment
<pitti> ginggs: yes, it does debootstrap essentially
<ginggs> ok, well i can confirm that putting back the export does not break the tests run locally on amd64
<ginggs> shall i upload to the archive?
<LocutusOfBorg> slangasek, why you did sync vtk6 :/
<LocutusOfBorg> I intentionally left it to sync, to avoid entangling openmpi transition with mysql one
<pitti> ginggs: if you are reasonably sure that this fixes it, sure
<ginggs> pitti: ok
<pitti> slangasek: did you already retry the ppc64el ones? I don't see any running ones
-queuebot:#ubuntu-release- New source: mysql-defaults (yakkety-proposed/primary) [1.0.0ubuntu1]
<apw> ^ was that intended for yakkety ?
<apw> rbasak, ^
<rbasak> Ah
<rbasak> No
<rbasak> Sorry! I need to remember the name of the current release!
 * Laney always wants to type zenial
<LocutusOfBorg> rbasak, use "distro-info -d" :)
<ginggs> zakkety
 * rbasak tries again
<rbasak> Could someone reject mysql-defaults from the yakkety new queue please?
<apw> rbasak, gone
-queuebot:#ubuntu-release- New: rejected mysql-defaults [source] (yakkety-proposed) [1.0.0ubuntu1]
<rbasak> Thank you!
<xnox> LocutusOfBorg, it's entangled regardless =(
-queuebot:#ubuntu-release- New binary: botch [amd64] (zesty-proposed/universe) [0.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: botch [i386] (zesty-proposed/universe) [0.19-2] (no packageset)
 * Laney makes a list of perlish removals
-queuebot:#ubuntu-release- New binary: botch [powerpc] (zesty-proposed/universe) [0.19-2] (no packageset)
<xnox> pitti, your systemd SRU to xenial uses strage numbers =)
<xnox> i was expected 229-4ubuntu4.7 by now, not 229-4ubuntu11 =)
<pitti> xnox: hm; can use an SRUish one the next time, but switching teh pattern now would seem strange too
<xnox> pitti, yeah, it's fine. best to keep going as you did forever. I'm currently rebasing my patches on top of xenial, so for my ppa i use 229-4ubuntu12~ppa1 -> to be higher than current, but lower than next.
 * xnox doesn't care if my overlay features are trumped in my ppa
<ginggs> pitti: looks like gerris s390x autopkgtests passed now \o/ can you make openmpi run its tests against the correct versions of gerris and esys-particle please?
<pitti> ginggs: great, thanks! will do that
<pitti> ginggs: I actually queued a retry of esys-particle, it's just patiently waiting in the queue
<pitti> ginggs: retried gerris for openmpi: http://autopkgtest.ubuntu.com/running#pkg-gerris
-queuebot:#ubuntu-release- New binary: botch [arm64] (zesty-proposed/universe) [0.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: botch [armhf] (zesty-proposed/universe) [0.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: botch [s390x] (zesty-proposed/universe) [0.19-2] (no packageset)
-queuebot:#ubuntu-release- New sync: golang-github-hlandau-goutils (zesty-proposed/primary) [0.0~git20160722.0.0cdb66a-1]
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9git1 => 231-9ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu11 => 229-4ubuntu12] (core)
<Laney> apw or pitti: https://bugs.launchpad.net/ubuntu/+source/kvirc/+bug/1636804 I think is the required removals
<ubot5`> Ubuntu bug 1636804 in uwsgi (Ubuntu) "perl 5.24 demotions" [Undecided,New]
-queuebot:#ubuntu-release- New binary: botch [ppc64el] (zesty-proposed/universe) [0.19-2] (no packageset)
<apw> Laney, we'll sort that out ta
<pitti> Laney: you didn't tag this block-proposed -- did you block it in britney?
<pitti> Laney: i. e. we need to somehow make sure it doesn't immediately propagate back
<apw> pitti, ok i can see a block for the list in hints-ubuntu
<pitti> apw: ah, I see Laney's "block" hints
<pitti> apw: so, want to do the demote-to-proposed exercise?
<apw> pitti, sounds good, shall i demote the lot and then we can remove things from there if they need that
<pitti> sure
<pitti> apw: or they'll just come back when/if they get fixed in debian, through autosyncs
<Laney> I'll drop the hint once perl migrates
<Laney> thanks!
<apw> Laney, ok should be done
<pitti> w00t, armhf tests have almost caught up
<Laney> apw: â¥
<Laney> mysql-defaults is published too, will retry things
<apw> Laney, oh nice ... i assume that is going to fix a heap of stuff
<Laney> if the gods are feeling kind
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu12]
<apw> Laney, your block list doesn't include libbio-scf-perl is that intended
<Laney> it should do, I added it in a later commit
 * Laney stabs this connection
<apw> Laney, ahh so it does, i managed to suck it down in the gap
<Laney> DNS seems to have given up for lunch
<Laney> it's a hint for me to do the same
<Laney> o/
-queuebot:#ubuntu-release- Unapproved: accepted anjuta-extras [source] (yakkety-proposed) [3.10.0-4build0.1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-go.crypto [source] (yakkety-proposed) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.8]
-queuebot:#ubuntu-release- Unapproved: accepted edk2 [source] (yakkety-proposed) [0~20160813.de74668f-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (yakkety-proposed) [1.2-0ubuntu1.1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop-environment [source] (yakkety-proposed) [0.4.17]
-queuebot:#ubuntu-release- New: rejected minuet [source] (yakkety-proposed) [16.04.3-0ubuntu1]
<apw> ^ submitted to yakkety prior to release ... requested they be resubmitted if still needed ^
<xnox> openmpi is now valid candidate all by it self.
<xnox> well vtk6 is ignored vailure.
 * xnox is confused what does it not like.
<xnox> ah it wants vtk6
<xnox> which fails to build on armhf
<xnox> mysql-5.7 failing to upload on amd64 is also not nice
<LocutusOfBorg> rbasak, is on mysql
<LocutusOfBorg> vtk6 was good until the last sync  "6.3.0+dfsg1-1build3" <-- if you can delete the -2 that one can migrate
<xnox> i guess default mysql was slow to publish, hence vtk6 build failed to install build-deps, it's building now on the retry.
<LocutusOfBorg> no
<LocutusOfBorg> default-sql was pointing to mariadb
<LocutusOfBorg> and martiadb ftbfs on armhf
<LocutusOfBorg> so now vtk6 has both in different architectures, a mess
 * LocutusOfBorg retries gambas4
 * LocutusOfBorg retries gambas3
<apw> that is a mess
<LocutusOfBorg> having different sql backends on different architectures is painful, maybe rbasak you want to rebuild them?
<LocutusOfBorg> libdbd-mysql-perl lcgdm gdal cacti-spine gambas3 vtk6
<LocutusOfBorg> ^^
<xnox> it's building vtk6 against _a_ backend now on armhf, no idea about other arches =)
 * xnox wishes that there is a libperl-vtk-mysql-boost package
<LocutusOfBorg> xnox, the others are using mariadb
<LocutusOfBorg> and no, I prefer to rebuild them *now*
<LocutusOfBorg> instead of landign with such stuff
 * LocutusOfBorg will rebuild in 10 minutes if nobody complains
<rbasak> LocutusOfBorg: sure. No objection. I was going to look at the rdeps at some point, but sounds like you'll get to it first.
<LocutusOfBorg> rbasak, just because I don't want them to land
<LocutusOfBorg> done
<xnox> rbasak, any idea where the mysql-common 5.8+1.0.0ubuntu1 zesty all came from?
<rbasak> xnox: src:mysql-defaults
<xnox> that's preventing mysql-5.7 build on amd64 to upload.
<rbasak> Yes. I need to merge mysql-5.7.
<rbasak> In sid, mysql-common has moved to src:mysql-defaults from src:mysql-5.7.
<xnox> right, but we don't have mysql-5.8 at all
<xnox> shouldn't mysql-defaults build mysql-common 5.7?
<rbasak> There's hack with the binary version number.
<xnox> or are we expecting 5.8 shortly?
<rbasak> There is no 5.8.
<rbasak> src:mysql-defaults 1.0 (or whatever) builds mysql-common 5.8+...
 * xnox pretends all above is sane, and takes it as given.
<rbasak> I would've started src:mysql-defaults at 5.8 or something personally, but someone else in Debian did that part.
<rbasak> I didn't think it really mattered.
 * LocutusOfBorg is scared about that *sql* stuff, but hopes it is fine
<sewaddle> hi.. Peter from the Canonical web team... we got this but - https://github.com/ubuntudesign/www.ubuntu.com/issues/1041
<sewaddle> but=bug
<LocutusOfBorg> cjwatson, ^^^ :)
<xnox> sewaddle, mostly harmless and i think that has always been like that.
<xnox> sewaddle, it will look right if and when .4 images are rotated off to old-releases host.
<xnox> or maybe infinity can twiddle things
<xnox> LocutusOfBorg, colin doesn't do any of releasy stuff any more.
<sewaddle> ok xnox I can pass that back to the person
<LocutusOfBorg> oh, ok
<sewaddle> they also pinged us on #ubuntu-website as well
<LocutusOfBorg> I still consider him the man who does everything :p
<LocutusOfBorg> anyway, expecting openmpi to migrate in 3 hours from now?
<xnox> sewaddle, it's merely an apache autoindex pattern, maybe it can be tweaked to be better, and ahead of time doing the right things for all point releases. but meh.
<xnox> https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html
<sewaddle> xnox: I invited the person here; however they just posted '<alevipri> realname sewaddle since the Wily HWE stack is in EOL, 14.04.4 should have be moved to old-releases'
<xnox> sewaddle, honestly, this is not a support channel for people.
<sewaddle> xnox: nor is mine
<xnox> sewaddle, we archive things / garbagge collect things whenever we need to / want to, usually we keep as many things on the release server as our disk-space space allows.
<xnox> sewaddle, yeah.... not sure how to deal with such requests.... politely =)
-queuebot:#ubuntu-release- New source: adobe-flashplugin (zesty-proposed/partner) [1:20161026.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debootstrap (precise-proposed/main) [1.0.40~ubuntu0.10 => 1.0.40~ubuntu0.11] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.1 => 1.0.78+nmu1ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (trusty-proposed/main) [1.0.59ubuntu0.5 => 1.0.59ubuntu0.6] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (yakkety-proposed/main) [1.0.81ubuntu2 => 1.0.81ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.0~beta15-0ubuntu2.16.04.1 => 2.0.0-0ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [i386] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [armhf] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [i386] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-safe-exceptions [armhf] (zesty-proposed/universe) [0.1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [amd64] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [amd64] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [amd64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [amd64] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [armhf] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-safe-exceptions [amd64] (zesty-proposed/universe) [0.1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [arm64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [armhf] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [i386] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [arm64] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-safe-exceptions [i386] (zesty-proposed/universe) [0.1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [i386] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [i386] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [i386] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [amd64] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [amd64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [armhf] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [arm64] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [arm64] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [powerpc] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-safe-exceptions [powerpc] (zesty-proposed/universe) [0.1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [powerpc] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [powerpc] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [s390x] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client [s390x] (zesty-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [s390x] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [powerpc] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [armhf] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [arm64] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [s390x] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-finite-field [powerpc] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-scanner [s390x] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [armhf] (zesty-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [arm64] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [powerpc] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [s390x] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
<slangasek> LocutusOfBorg: because the result of not syncing vtk6 was an inability to get useful autopkgtest results for all of openmpi's revdeps
<slangasek> pitti: no, I didn't retry the ppc64el ones
<pitti> slangasek: hm, so they arrived after all, I suppose
<LocutusOfBorg> thanks slangasek, I don't know why my rebuild didn't work, but doesn't matter, thanks :)
<LocutusOfBorg> BTW I'm retrying some haskell leaf packages, so expect flooding (~38 new packages)
 * slangasek nods
-queuebot:#ubuntu-release- New: accepted botch [amd64] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [armhf] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [powerpc] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [s390x] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [arm64] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [ppc64el] (zesty-proposed) [0.19-2]
-queuebot:#ubuntu-release- New: accepted botch [i386] (zesty-proposed) [0.19-2]
<Laney> Second set of eyes on pdl/armhf and libtext-bibtex-perl/s390x appreciated
<LocutusOfBorg> https://launchpad.net/~abbat/+archive/ubuntu/tox/+build/11081274
<LocutusOfBorg> what did happen^^^
<slangasek> Laney: heads up that the livecd-rootfs branch appears to be out of date vs the archive; also, am confused by the text of your MP change because I thought we did fix this for ubuntu-core already; did that only get fixed in SRU?
<slangasek> (or in the snappy ppa)
<balloons> so I noticed we have 32-bit builds of juju-core in zesty -- why is this? Can we get them removed?
<Laney> slangasek: You mean that I should be more explicit that it was already turned off for some flavours?
<slangasek> Laney: seems that yes, it was only committed in the snappy-dev ppa on xenial; so your fix looks reasonable
<slangasek> Laney: no, I was just asking why ubuntu-core was not there alongside ubuntu-cpc|ubuntu-server in the exclusion list
<slangasek> balloons: where do you see this?
<Laney> OK
<Laney> Well that's one bit of delta they can drop then :)
<balloons> slangasek, well, let me be clear actually. I'm seeing autopkgtest runs for 32-bit on zesty (and perhaps yakkety too, we'll see on the next upload if they kick again)
<balloons> I spoke with pitti about this at one point, and I think he was a little confused why they still kicked off
<slangasek> balloons: ok.  there are no 32-bit /builds/ of juju-core in zesty; and I would not be less confused than pitti about why the autopkgtest is trying to trigger tests for them.  We should certainly override those into oblivion in the meantime
<slangasek> balloons: though the current tests are failing on all archs, so...
<balloons> slangasek, yes, current-manual-provider zesty test will fail due to lack of published agent for it
<slangasek> balloons: comment from pitti's hint file:
<slangasek> # does not build on 32 bit arches any more, but Arch: all metapackages still exist (fixed in git)
<balloons> ahh, yes I recall that being the reason
<Laney> sil2100: If you have a branch for your livecd-rootfs 2.435 upload, could you push it please?
-queuebot:#ubuntu-release- New binary: haskell-servant-client [ppc64el] (zesty-proposed/universe) [0.7.1-1] (no packageset)
<sil2100> Laney: hey! Oh, it's not in bzr?
<sil2100> Maybe I forgot bzr push or something
<Laney> push it real good
-queuebot:#ubuntu-release- New binary: haskell-finite-field [ppc64el] (zesty-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raaz [ppc64el] (zesty-proposed/universe) [0.0.2-1] (no packageset)
<sil2100> eh, can't find the branch, need to re-create, pushing in a min
<pitti> slangasek: yes, britney still sees 32 bit packages from juju-core due to the arch: all
<pitti> (or "saw" -- they should be NBS after the next upload)
<slangasek> pitti: ok cool
<sil2100> Laney: pushed
<Laney> sil2100: dziÄkujÄ
-queuebot:#ubuntu-release- New binary: haskell-scanner [ppc64el] (zesty-proposed/universe) [0.2-1] (no packageset)
<sil2100> Laney: proszÄ bardzo! And sorry for not pushing, I have no idea how this happened
<Laney> it's easy to forget
<alevipri> hello everyone, hope this is the correct channel where to ask
<alevipri> this page ( http://releases.ubuntu.com/14.04/ ) lists both 14.04.4 and 14.04.5
<alevipri> and describes ubuntu 14.04.4 as "Ubuntu 14.04.5 LTS (Trusty Tahr)"
<alevipri> I think this has to be fixed (move 14.04.4 to old-releases.ubuntu.com and correct 14.04.4 description)
<alevipri> or am I missing something?
-queuebot:#ubuntu-release- New binary: haskell-deriving-compat [ppc64el] (zesty-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-parsers [ppc64el] (zesty-proposed/universe) [0.2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted adobe-flashplugin [source] (zesty-proposed) [1:20161026.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: adobe-flashplugin [amd64] (zesty-proposed/none) [1:20161026.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adobe-flashplugin [i386] (zesty-proposed/none) [1:20161026.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20161011.1-0ubuntu0.12.04.1 => 1:20161026.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20161011.1-0ubuntu0.16.04.1 => 1:20161026.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20161011.1-0ubuntu0.14.04.1 => 1:20161026.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20161011.1-0ubuntu1 => 1:20161026.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20161026.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20161026.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20161026.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20161026.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- New: accepted adobe-flashplugin [amd64] (zesty-proposed) [1:20161026.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted adobe-flashplugin [i386] (zesty-proposed) [1:20161026.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-image [amd64] (xenial-proposed) [0.9+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.4.1-0ubuntu1~ubuntu16.04.1 => 2.5-0ubuntu1~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.5-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (yakkety-proposed) [1.0.81ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.4.1-0ubuntu1~ubuntu16.04.1 => 2.5-0ubuntu1~ubuntu16.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.5-0ubuntu1~ubuntu16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (trusty-proposed) [1.0.59ubuntu0.6]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (precise-proposed) [1.0.40~ubuntu0.11]
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (trusty-proposed) [14.03.01-0ubuntu4]
-queuebot:#ubuntu-release- New binary: slepc [i386] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [amd64] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [s390x] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [armhf] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [powerpc] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [arm64] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
<xnox> so everything is a valid candidate, including vtk6 & openmpi (et.al) yet it still does not migrate.
<xnox> i guess it needs perl too?
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has a lot in "trying: openmpi", some package there which still needs migratino?
<pitti> I don't see anything perl-ish there
<xnox> well search for "Apparently successful"
<xnox> then SUCCESS (119/106)
<xnox> then the doom of transition where openmpi is tried together with vtk6 and a gazzillion of other packages.
<xnox> there is perl there.
<xnox> Ctrl-F SUCCESS (119/106)
<xnox> Trying easy from autohinter.
<xnox> as if there is some kind of other transition needed.
-queuebot:#ubuntu-release- New binary: slepc [ppc64el] (zesty-proposed/universe) [3.7.3+dfsg1-2] (no packageset)
<slangasek> xnox: I don't see anything in the output of the openmpi 'easy' hint pointing to perl, do you see a specific package?  I do see gdal becoming uninstallable, which has a lot of revdeps (and libgdal-perl is tied to the perl transition); we might break libgdal-perl to let openmpi in, then let it catch back up with perl
<slangasek> sorry, the first part of that message was rendered false by the time I wrote the second part ;)
<slangasek> so, it's armadillo + perl that entangles here via gdal
<slangasek> force added for gdal, to clear the brush
<LocutusOfBorg> armadillo should be good now
<LocutusOfBorg> mea culpa, I was waiting for openmpi to start it
<LocutusOfBorg> didn't see gdal coming
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.10+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.10+16.10ubuntu1]
<LocutusOfBorg> please accept slepc from new queue
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-goutils [sync] (zesty-proposed) [0.0~git20160722.0.0cdb66a-1]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [arm64] (zesty-proposed) [0.8.0-1]
<LocutusOfBorg> or maybe just wait for openmpi to land, I parsed from britney some "dolfin uninstallable issue" and slepc might be the reason
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [i386] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [amd64] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [armhf] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [powerpc] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [amd64] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [s390x] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [i386] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [armhf] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [arm64] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [powerpc] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [ppc64el] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted slepc [amd64] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted slepc [armhf] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted slepc [powerpc] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted slepc [s390x] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-finite-field [ppc64el] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted slepc [arm64] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted slepc [ppc64el] (zesty-proposed) [3.7.3+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client [s390x] (zesty-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted slepc [i386] (zesty-proposed) [3.7.3+dfsg1-2]
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- New binary: golang-github-hlandau-goutils [amd64] (zesty-proposed/none) [0.0~git20160722.0.0cdb66a-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-scanner [armhf] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-safe-exceptions [amd64] (zesty-proposed) [0.1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-safe-exceptions [i386] (zesty-proposed) [0.1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [amd64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [i386] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [ppc64el] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-safe-exceptions [armhf] (zesty-proposed) [0.1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [arm64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [s390x] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-safe-exceptions [powerpc] (zesty-proposed) [0.1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-scanner [powerpc] (zesty-proposed) [0.2-1]
<LocutusOfBorg> golang should make acmetool buildable
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [amd64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [armhf] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [powerpc] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [s390x] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [arm64] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [i386] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [ppc64el] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [arm64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [ppc64el] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [armhf] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [s390x] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-deriving-compat [i386] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [powerpc] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-raaz [amd64] (zesty-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [amd64] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [armhf] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [powerpc] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [s390x] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [arm64] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [ppc64el] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-parsers [i386] (zesty-proposed) [0.2.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-goutils [amd64] (zesty-proposed) [0.0~git20160722.0.0cdb66a-1]
-queuebot:#ubuntu-release- New sync: golang-github-hlandau-buildinfo (zesty-proposed/primary) [0.0~git20160722.0.b25d4b0-1]
-queuebot:#ubuntu-release- New sync: golang-github-hlandau-dexlogconfig (zesty-proposed/primary) [0.0~git20160722.0.055e2e3-1]
<LocutusOfBorg> that golang stuff is still for acmetool  ^^
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-buildinfo [sync] (zesty-proposed) [0.0~git20160722.0.b25d4b0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-dexlogconfig [sync] (zesty-proposed) [0.0~git20160722.0.055e2e3-1]
-queuebot:#ubuntu-release- New binary: gnome-twitch [amd64] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-twitch [i386] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-twitch [arm64] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-twitch [armhf] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-twitch [s390x] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-twitch [amd64] (zesty-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted gnome-twitch [armhf] (zesty-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted gnome-twitch [s390x] (zesty-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted gnome-twitch [arm64] (zesty-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted gnome-twitch [i386] (zesty-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New binary: gnome-twitch [ppc64el] (zesty-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tcsh (yakkety-proposed/universe) [6.18.01-5 => 6.18.01-5ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libnss-ldap (trusty-proposed/main) [264-2.2ubuntu4.14.04.1 => 264-2.2ubuntu4.14.04.2] (ubuntu-server)
#ubuntu-release 2016-10-27
-queuebot:#ubuntu-release- New: accepted gnome-twitch [ppc64el] (zesty-proposed) [0.3.0-2]
<slangasek> pitti: nplan SRU still verification-needed?
-queuebot:#ubuntu-release- New source: subiquity (xenial-proposed/primary) [0.0.22~16.04.1]
-queuebot:#ubuntu-release- Unapproved: procps (xenial-proposed/main) [2:3.3.10-4ubuntu2 => 2:3.3.10-4ubuntu2.1] (core)
-queuebot:#ubuntu-release- New source: budgie-desktop-environment (zesty-proposed/primary) [0.5.0]
<slangasek> LocutusOfBorg: hmm, so why did you sync slepc before the openmpi transition was done, anyway?
-queuebot:#ubuntu-release- New binary: golang-github-hlandau-buildinfo [amd64] (zesty-proposed/universe) [0.0~git20160722.0.b25d4b0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [i386] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [ppc64el] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [amd64] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [armhf] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [arm64] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [powerpc] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [s390x] (zesty-proposed/universe) [1.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozc [amd64] (zesty-proposed/main) [2.18.2595.102+dfsg-1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mozc [i386] (zesty-proposed/main) [2.18.2595.102+dfsg-1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mozc [armhf] (zesty-proposed/main) [2.18.2595.102+dfsg-1] (input-methods, ubuntu-desktop)
<jbicha> hi, could uim-mozc be accepted into universe? (the rest of mozc is in main)
<jbicha> this was discussed a bit at bug 1624369
<ubot5`> bug 1624369 in mozc (Ubuntu) "Please sync mozc 2.18.2595.102+dfsg-1 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1624369
<LocutusOfBorg> slangasek, there is a binNMU request against slepc, so the britney output told me that it might be needed in Ubuntu too
<LocutusOfBorg> I don't really understand their packages https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842135
<ubot5`> Debian bug 842135 in release.debian.org "nmu: slepc4py_3.7.0-2+b3" [Normal,Open]
<LocutusOfBorg> and since openmpi didn't migrate, the output was mentioning slepc and dolfin... I syncd it
<LocutusOfBorg> why is still not syncd?
<LocutusOfBorg> s/syncd/migrated
<slangasek> ... it's not migrated because the slepc sync triggered a new transition... :)
<slangasek> pitti: "A server error occurred. Please contact the administrator." http://autopkgtest.ubuntu.com/packages/s/sumo/zesty/armhf
<ginggs> openmpi \o/
<pitti> slangasek: I'll verify bug 1635256 today, but I'd like the console-conf guys decide whether bug 1626617 is fixed now
<ubot5`> bug 1635256 in systemd (Ubuntu Xenial) "[xenial] search domains in networkd do not get propagated to resolvconf" [Medium,Fix committed] https://launchpad.net/bugs/1635256
<ubot5`> bug 1626617 in subiquity (Ubuntu Xenial) "console-conf does not allow to set up dns for static ip" [Undecided,New] https://launchpad.net/bugs/1626617
<pitti> slangasek: zumo server error> "sqlite3.OperationalError: database is locked"
<pitti> slangasek: oops -- I guess that's during the minute or two when reads the Packages.gz and pokes that into the DB -- that runs at 06:02 every day, i. e. exactly at that time
<pitti> slangasek: I'll check if sqlite can handle this better
<LocutusOfBorg> lovely migration
<pitti> Oh, openmpi is landing, nice!
<LocutusOfBorg> one hour ago :)
<LocutusOfBorg> pitti, I'm going to have a look at perl now, do you have a list of things to fix?
<LocutusOfBorg> oh well, accepting stuff in new will make also haskell migrate and also acmetool
<pitti> http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.24.html
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl
<LocutusOfBorg> you syncd acmetool without syncing the golang dependencies :)
<LocutusOfBorg> yep pitti I plan to look at that page once openmpi disappears from it
<LocutusOfBorg> :)
<pitti> the latter is still a sea of red, but I suppose with the recent rebuilds we should do a mass-retry of that
<pitti> LocutusOfBorg: oh, meh -- these are such a mess :(
<LocutusOfBorg> just accepting it from new queue should make everything go
<LocutusOfBorg> I also sponsored them to jessie backports a few minutes ago :)
<pitti> LocutusOfBorg: ah, I remember why -- some golang libs got renamed, and Debian removed the old names
<pitti> and we want to follow suit of course
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-buildinfo [amd64] (zesty-proposed) [0.0~git20160722.0.b25d4b0-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [amd64] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [armhf] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [powerpc] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [arm64] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [s390x] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [i386] (zesty-proposed) [1.0.0.3-1]
<LocutusOfBorg> apw, you probably need a bigger hammer for perl
<LocutusOfBorg> kvirc -> Demoted to zesty-proposed for perl 5.24 transition (LP: #1636804)
<ubot5`> Launchpad bug 1636804 in uwsgi (Ubuntu) "perl 5.24 demotions" [Undecided,Fix released] https://launchpad.net/bugs/1636804
<LocutusOfBorg> and it landed
<apw> say what ...
<pitti> apw: meh, the linux tests still seem to loop :( mind if I zap them from the queue for now?
<LocutusOfBorg> the demotions landed on updates, so perl is again stuck
<LocutusOfBorg> why did the block fail?
<pitti> apw: we seem to have fixed the first two or three issues, but there's another one; I just have some high-urgency stuff to do today, I'm afraid
<pitti> LocutusOfBorg: please coordinate with Laney on perl (he just said good morning
<Laney> hi
<Laney> What?
<LocutusOfBorg> hi Laney good morning!
<Laney> What does "the demotions landed on updates" mean?
<LocutusOfBorg> I mean bug 1636804
<ubot5`> bug 1636804 in uwsgi (Ubuntu) "perl 5.24 demotions" [Undecided,Fix released] https://launchpad.net/bugs/1636804
<apw> pitti, pleas zap anything you are worried about linux side ... please
<pitti> e. g. kvirc is still in -proposed
<LocutusOfBorg> shouldn't them stay in proposed until perl goes in?
<Laney> They are in proposed
<LocutusOfBorg> mmm bad cache
<pitti> apw: curiously amd64 now works (http://autopkgtest.ubuntu.com/packages/l/linux/zesty/amd64), but i386 still loops
<pitti> apw: so at least 50% better now :)
<LocutusOfBorg> sorry nvm
<apw> pitti, bugger :)
<apw> LocutusOfBorg, they look to be in the right place to me ?
<Laney> LocutusOfBorg: Only hard stuff left, but you are welcome to try
<Laney> pdl/armhf and the two that are red on s390x only
<pitti> Laney: so I suppose a lot of the red on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl was due to second-level uninstallability, and the intermediate ones got rebuilt now; I. e. time for a mass-retry?
<Laney> pitti: I clicked on about 10 reds and they were all due to uninstallability
<LocutusOfBorg> Laney, libterm-readline-gnu-perl should be removed on s390x, already removed in debian
<LocutusOfBorg> oh not removed, but the same failure
<pitti> Laney: right, me too -- but that doesn't really agree with the transition tracker any more, hence my hope that retries should work; I'll try one or two for now, and if that works better, retry the whole lot to see where we stand?
<Laney> pitti: Sure
-queuebot:#ubuntu-release- New sync: haskell-hcwiid (zesty-proposed/primary) [0.0.5-4]
-queuebot:#ubuntu-release- New sync: haskell-persistable-record (zesty-proposed/primary) [0.4.0.3-1]
 * pitti kills the 20 gazillion content-hub test requests from silo 1994.1 -- WTF?
-queuebot:#ubuntu-release- Unapproved: accepted procps [source] (xenial-proposed) [2:3.3.10-4ubuntu2.1]
<LocutusOfBorg> do you foresee issues with a xapian transition?
<LocutusOfBorg> I see them: cyrus-imapd libsearch-xapian-perl needs to land
<pitti> Laney: looks  hopeful, doing mass-retry
<LocutusOfBorg> sigh I forgot to sync some haskell new libraries
<oSoMoN> pitti, the SRU for webbrowser-app thatâs sitting in the unapproved queue should now be ready to be reviewed, as the corresponding fixes landed in zesty yesterday
<pitti> Laney: ok, http://autopkgtest.ubuntu.com/running is now another mouthful :)
<Laney> pitti: eek!
<pitti> and someone said perls are rare
<LocutusOfBorg> lol
<LocutusOfBorg> btw just to add some fun today: ghc 8 is expected to land in Stretch, so it will start to transition probably in a week or two
<LocutusOfBorg> and openssl 1.1 bugs are now RC
<LocutusOfBorg> so.... zesty migth have it? :)
<xnox> Laney, are we going to have perl5 -> perl6 transition?
<Laney> xnox: Don't ask me questions about perl. :P
<Laney> But I seriously doubt it, since they are basically separate languages
<xnox> Laney, are you still planning the perl5 -> haskell transition? =)))))) rewrite everything =)
<Laney> Now you're talking
<LocutusOfBorg> that would be funny
<LocutusOfBorg> haskell works, zero bugs, easy transitions
<LocutusOfBorg> nobody can understand the code and complain
<xnox> https://xkcd.com/1312/
<LocutusOfBorg> https://xkcd.com/353/
<pitti> I like the popup
<LocutusOfBorg> yes, the funniest part is that
<LocutusOfBorg> and I never found a way to see it on smartphone
<Laney> m.xkcd.com
<pitti> honestly, it's great for algorithmic stuff, but most programs are not like that, they do I/O and graphical stuff, where functional languages are inherently unwieldy at
<pitti> OCaml was an interesting approach to that
<LocutusOfBorg> Laney, WOW
 * LocutusOfBorg reminds everybody that somebody is maintaining a python-xkcd binding https://packages.qa.debian.org/p/python-xkcd.html
-queuebot:#ubuntu-release- New sync: golang-github-googleapis-proto-client-go (zesty-proposed/primary) [0.0~git20160726.0.e5790fe-1]
<LocutusOfBorg> pitti, ^^ forgot one :)
<pitti> LocutusOfBorg: done
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- New: accepted golang-github-googleapis-proto-client-go [sync] (zesty-proposed) [0.0~git20160726.0.e5790fe-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [sync] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [sync] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [ppc64el] (zesty-proposed) [1.0.0.3-1]
-queuebot:#ubuntu-release- New binary: golang-github-hlandau-dexlogconfig [amd64] (zesty-proposed/universe) [0.0~git20160722.0.055e2e3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [ppc64el] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [ppc64el] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [amd64] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [i386] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [armhf] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [amd64] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [i386] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [arm64] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [armhf] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [arm64] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New sync: gobgp (zesty-proposed/primary) [1.12-1]
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [powerpc] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [powerpc] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hcwiid [s390x] (zesty-proposed/none) [0.0.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-persistable-record [s390x] (zesty-proposed/none) [0.4.0.3-1] (no packageset)
<LocutusOfBorg> doko, did protobuf compiler stop working? https://launchpad.net/ubuntu/+source/golang-google-grpc/1.0.0-1/+build/11038838
<LocutusOfBorg> I can reproduce locally but not in Debian
<LocutusOfBorg> cpu 100% and stuck
-queuebot:#ubuntu-release- New binary: papi [ppc64el] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [amd64] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [i386] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [arm64] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nautilus (yakkety-proposed/main) [1:3.20.3-1ubuntu3 => 1:3.20.3-1ubuntu3.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: papi [armhf] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [ppc64el] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [amd64] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [i386] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: papi [powerpc] (zesty-proposed/universe) [5.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [arm64] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [armhf] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu-contrib [amd64] (zesty-proposed/multiverse) [1.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [s390x] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [powerpc] (zesty-proposed/universe) [1.2.0+dfsg-1] (no packageset)
<pitti> Laney: /me likes all the green on the http://autopkgtest.ubuntu.com/  history :)
<pitti> looks like we need to buy another Binford 6100 scalingstack for MOAR POWER
-queuebot:#ubuntu-release- New binary: starpu-contrib [ppc64el] (zesty-proposed/multiverse) [1.2.0+dfsg-2] (no packageset)
<Laney> pitti: \o/
<Laney> nice reference too
<ogra_> hah
 * Laney tries pdl from git out of desperation
<apw> Laney, that is about half your red too ...
<Laney> apw: pdl?
<apw> Laney, yeah ...
<Laney> mmm
-queuebot:#ubuntu-release- New: accepted papi [amd64] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted papi [armhf] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted papi [powerpc] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted starpu-contrib [amd64] (zesty-proposed) [1.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted starpu [amd64] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted starpu [armhf] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted starpu [powerpc] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted starpu [s390x] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [arm64] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted papi [ppc64el] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted starpu [arm64] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted starpu [ppc64el] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted papi [i386] (zesty-proposed) [5.5.0-3]
-queuebot:#ubuntu-release- New: accepted starpu [i386] (zesty-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted starpu-contrib [ppc64el] (zesty-proposed) [1.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [amd64] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [armhf] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [powerpc] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [s390x] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [arm64] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [ppc64el] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-persistable-record [i386] (zesty-proposed) [0.4.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [amd64] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [armhf] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [powerpc] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [s390x] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [arm64] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [ppc64el] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted haskell-hcwiid [i386] (zesty-proposed) [0.0.5-4]
-queuebot:#ubuntu-release- New: accepted gobgp [sync] (zesty-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted mozc [amd64] (zesty-proposed) [2.18.2595.102+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mozc [i386] (zesty-proposed) [2.18.2595.102+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hlandau-dexlogconfig [amd64] (zesty-proposed) [0.0~git20160722.0.055e2e3-1]
-queuebot:#ubuntu-release- New: accepted mozc [armhf] (zesty-proposed) [2.18.2595.102+dfsg-1]
<Laney> yeah still fails from git
<apw> bah
<rcj> infinity, Who should I ping with a zesty powerpc builder question?  Getting "There is already a live filesystem with the same name, owner, and distroseries." and not sure if we're provisioned correctly for powerpc.
<rcj> wgrant, cjwatson ^
<jbicha> did whoever approved mozc see my comment about the uim-mozc binary pkg needing to be in universe?
-queuebot:#ubuntu-release- New sync: es-module-loader-0.17.js (zesty-proposed/primary) [0.17.11+dfsg-1]
-queuebot:#ubuntu-release- New sync: webcomponentsjs-custom-element-v0.js (zesty-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: carettah [amd64] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [i386] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [i386] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [armhf] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [arm64] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [amd64] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [powerpc] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [s390x] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [powerpc] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [ppc64el] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: carettah [s390x] (zesty-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [armhf] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query [arm64] (zesty-proposed/universe) [0.8.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted carettah [amd64] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted carettah [armhf] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted carettah [powerpc] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted carettah [s390x] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [arm64] (zesty-proposed) [0.8.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [i386] (zesty-proposed) [0.8.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [s390x] (zesty-proposed) [0.8.3.1-1]
-queuebot:#ubuntu-release- New: accepted carettah [arm64] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted carettah [ppc64el] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [armhf] (zesty-proposed) [0.8.3.1-1]
-queuebot:#ubuntu-release- New: accepted carettah [i386] (zesty-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [powerpc] (zesty-proposed) [0.8.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-query [amd64] (zesty-proposed) [0.8.3.1-1]
<sil2100> I guess the publisher is really busy today
-queuebot:#ubuntu-release- Unapproved: accepted python-rfc3986 [source] (yakkety-proposed) [0.2.2-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-rfc3986 [source] (xenial-proposed) [0.2.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected fcitx [source] (yakkety-proposed) [1:4.2.9.1-4ubuntu1.16.10.1]
<apw> sil2100, i am not sure the publisher is particularly busy, britney is probabally crying in a corner in zesty though
<apw> sil2100, and cirtainly the ADT queues are a bit mental for perl
<sil2100> Yeah, britney for sure, but I also saw that there was a long delay between a package copy and it actually appearing on launchpad  in -proposed
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/zesty/2016-10-27/
<pitti> britney runs every 20 minutes or more often
<pitti> but that's fairly normal with this queue length
<apw> publishing take something like 45m a cycle, so if you are unlucky it can be as much as double that
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20161024-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20161024-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected tcsh [source] (yakkety-proposed) [6.18.01-5ubuntu0.1]
<tyhicks> bdmurray: hey - if you're around doing SRU work today, xenial apparmor has received all the proper bug fix verifications and is only hung up on an unrelated mysql autopkgtest failure
<tyhicks> bdmurray: that mysql failure was introduced, upstream, by a security update a couple months ago
<bdmurray> rbasak: ^^
 * rbasak looks
<tyhicks> rbasak: you're not at fault (test results at http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/xenial/amd64)
<rbasak> I've asked upstream to take a look.
<bdmurray> tyhicks: He's doing SRU training with me right now.
<tyhicks> aha
<tyhicks> I mistakenly made the mysql <-> rbasak connection
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (yakkety-proposed) [1:3.20.3-1ubuntu3.1]
<cyphermox> could someone please review golang-go.crypto and juju-core in xenial, yakkety proposed queues?
<cyphermox> balloons: ^
<oSoMoN> could someone please have a look at webbrowser-app thatâs sitting in the yakkety proposed queue?
<rbasak> oSoMoN: see my ping above.
<rbasak> oSoMoN: there seems to be an extra patch but no bug reference.
<rbasak> oSoMoN: sorry, it was in #ubuntu-devel, not this channel.
<rbasak> About three hours ago.
<oSoMoN> rbasak, oh, sorry, I missed that one, just seeing it now
<sergiusens> bdmurray hello, mind allowing snapcraft into xenial-proposed?
<bdmurray> sergiusens: I'll have a look
-queuebot:#ubuntu-release- New source: zfcpdump-kernel (xenial-proposed/primary) [4.4-0ubuntu1~16.04.1]
<apw> ^ xnox -- your zfcpdump-kernel pulled-back to xenial ...
<xnox> \o/
<bdmurray> sergiusens: you said xenial proposed? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<xnox> absolutely fabulous =)
<sergiusens> bdmurray yes
<sergiusens> I didn't get a confirmation email which worries me a bit, I uploaded almost an hour ago
<apw> sergiusens, if the thing is not signed it just gets lost
<bdmurray> sergiusens: I'd be worried as I don't see it in the queue.
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [amd64] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
<xnox> sergiusens, was that a dput or copy? i have seen copies fail.
<sergiusens> apw http://pastebin.ubuntu.com/23388955/ looks like it is ok
<sergiusens> xnox no no copy, I uploaded the almost same thing to zesty last night
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [i386] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [amd64] (zesty-proposed/main) [0.7.4-2] (desktop-core)
<xnox> sergiusens, same version number?
<xnox> weird
<apw> sergiusens, i have dumped something in the upload queue and seen it pop thorugh to xenial new so it is working
<apw> sergiusens, throw it in again and see what happens
<xnox> sergiusens, pastebin your .changes file?
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [powerpc] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [s390x] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
<sergiusens> xnox http://paste.ubuntu.com/23388970/
<apw> strange indeed perhaps launchpad oops'd
<apw> really shove it at the upload queue again, and see if it works better this time
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [armhf] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
<sergiusens> apw I'll dput again
-queuebot:#ubuntu-release- New binary: haskell-relational-schemas [arm64] (zesty-proposed/universe) [0.1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.19 => 2.20] (no packageset)
<sergiusens> apw ok, good now [ubuntu/xenial-proposed] snapcraft 2.20 (Waiting for approval)
<bdmurray> Okay, I'll review that now.
<apw> sergiusens, clearly sunspots ....
-queuebot:#ubuntu-release- Unapproved: accepted webbrowser-app [sync] (yakkety-proposed) [0.23+16.10.20161018-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.20]
<apw> sergiusens, did the same sunspots hit the yakkety-proposed upload ?
<sergiusens> apw should I consider yakkety?
<sergiusens> apw let me ask this differently, is it required to cater for yakkety?
<apw> sergiusens, well if anyone upgrades from xenial to yakkety they will have a regression
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.19+16.10 => 2.20+16.10] (no packageset)
<sergiusens> apw [ubuntu/yakkety-proposed] snapcraft 2.20+16.10 (Waiting for approval)
<apw> bdmurray, are you still on a queue scan ?
<apw> sergiusens, thanks queuebot just noticed it too
<slangasek> sergiusens: yes, it's required; and particularly as this is a developer-oriented tool I think you care about getting the non-LTS releases
<sergiusens> slangasek right, but our only 'core' is xenial based, we can discuss more next week. I will follow the rules for now.
<slangasek> sergiusens: snapcraft isn't being released to the distro by way of the core
<apw> sergiusens, right but where people make their snaps isn't necessarily an UC system
<sergiusens> right, it is not a UC system but they run with core as the base so there may be library incompatibilities (they are all solveable I guess, like needing to manually add your stdc++ lib)
<sergiusens> anywyas, it is making its way so no worries!
 * sergiusens gets back to his day off :-)
<sergiusens> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.20+16.10]
<balloons> bdmurray, can you review juju and golang-go.crypto in the xenial and yakkety queues? It's the 2.0.0 upload, and the golang-go.crypto update is needed to build
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 8-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 8-3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11 => 2.02~beta2-36ubuntu11.1] (core)
<bdmurray> balloons: Is the 2.0.0 upload one which slangasek had concerns about?
<cyphermox> bdmurray: should no longer be the case, I'd hope, unless he expressed these concerns today?
-queuebot:#ubuntu-release- Unapproved: grub2-signed (yakkety-proposed/main) [1.74 => 1.74.1] (core)
<bdmurray> cyphermox: I thought there were some the week before last or so
<cyphermox> yeah, should have been addressed already, I would think. I've been iterating on this with balloons for a bit
<cyphermox> it certainly doesn't include an epoch bump now ;)
<bdmurray> Okay, I don't know what they were - just trying to get some context.
<slangasek> I don't know what they were either, I may have spoken them aloud in the channel :)
<cyphermox> I'm not sure, except for the epoch.
-queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905.is.0.8-0ubuntu3 => 0.9+1474479173.6c180c6-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-go.crypto [source] (xenial-proposed) [1:0.0~git20161012.0.5f31782-1ubuntu0.16.04.1]
<slangasek> cyphermox: I remember there was an Arch: all/any thing which I hope is now resolved
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.3 => 1.21.4] (core)
<cyphermox> yes
<cyphermox> and there, all the pieces are in the queue for the shim SRU, except none have bug tags :'(
<cyphermox> I fial
<cyphermox> fail, too.
<slangasek> apw: could you delete these packages from zesty instead of demoting them to -proposed, please?  If we've already decided they're not important enough for us to fix for the transition and we're letting Debian do it, we don't need to leave the never-again-installable version hanging around in -proposed
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (yakkety-proposed) [1.21.4]
<cyphermox> slangasek: if you're rejecting shim-signed, please also reject grub and grub-signed, I'll reupload them all with the right bug tags
<cyphermox> I was just creating a proper bug to use for this
<cyphermox> obviously, shim itself can't be changed.
<slangasek> cyphermox: done, thanks
<slangasek> cyphermox: shim itself will have bug refs already, maybe reuse LP: #1624096 ?
<ubot5`> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,Fix released] https://launchpad.net/bugs/1624096
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (yakkety-proposed) [1.74.1]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.1]
<slangasek> or maybe LP: #1581299 is better
<ubot5`> Launchpad bug 1581299 in shim-signed (Ubuntu) "shim: set second stage not work" [High,Fix released] https://launchpad.net/bugs/1581299
<cyphermox> slangasek: I'll close 1581299 too, but I rather have something new where it will be more obvious if things regress again
<cyphermox> (and tracking for each release, and test cases, etc.)
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1637290
<ubot5`> Ubuntu bug 1637290 in shim-signed (Ubuntu Yakkety) "Update to the signed 0.9+1474479173.6c180c6-0ubuntu1 shim binary from Microsoft" [Undecided,New]
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.3 => 1.21.4] (core)
<bdmurray> balloons, cyphermox: were pitti's concerns in bug 1631038 addressed?
<ubot5`> bug 1631038 in juju-core (Ubuntu Yakkety) "Need /etc/sysctl.d/10-juju.conf" [Undecided,In progress] https://launchpad.net/bugs/1631038
<cyphermox> go me, network failure.
<balloons> bdmurray, we would like to ship these files as a workaround for now. You can see my explanation in the SRU details on the bug itself. The values set will affect the entire machine, however, they have been deemed reasonable and safe to do so. We did implement them in the place suggested by pitti -- I sought his feedback on the bug itself before agreeing to ship anything
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11 => 2.02~beta2-36ubuntu11.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (yakkety-proposed/main) [1.74 => 1.74.1] (core)
<balloons> The real fix is happening upstream and stgraber can comment more on that. LXD hadn't planned to ship any changes itself; rather to fix the upstream kernel
<cyphermox> slangasek: they're back in the queue.
<stgraber> right, inotify namespacing in the kernel should be merged in a few weeks, we can then try to get the kernel team to backport those bits in our stable kernels
<bdmurray> what would happen with these changes then?
<bdmurray> I mean if the kernel changes were backported
<balloons> We will drop the changes once the real fixes land
<stgraber> in most cases, they just wouldn't be necessary anymore. The knobs will still be there but will just become the default value for each of the namespaces.
<stgraber> as for pitti's comment, the problem is that we can't do that in LXD as bumping those values impact kernel memory use. It's fine for juju to bump them as it knows it's running on pretty beefy instances and knows that the containers it will be running will need those inotify watches.
<stgraber> it's however not fine to have LXD do so everywhere as that'd mean bumping those sysctls on small ARM boards that'd effectively OOM immediately
<stgraber> similarly, you won't hit that kind of issue if you're running android, alpine or even Ubuntu 14.04 containers, the use of inotify watches very much depends on your workload
<stgraber> currently for LXD, we have those knobs documented upstream in our production-setup documentation, along with a few other knobs that people may need to tweak based on their particular environment but we haven't found anything that we feel can be safely applied to every Ubuntu system
<balloons> right, see https://github.com/lxc/lxd/blob/master/doc/production-setup.md
<bdmurray> Okay, thanks for the info
<balloons> Note, our set value for  fs.inotify.max_user_watches is half what is shown in the table. The fs.inotify.max_user_instances is much more conservative at just double the default value
<balloons> These values will revert to default if the package is removed of course
<pitti> balloons: you're shipping that in /usr now?
<pitti> not /etc?
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.4-0ubuntu0.16.04 => 9.5.5-0ubuntu0.16.04] (core)
<balloons> pitti, yes, we install to /usr/lib/sysctl.d/10-juju.conf
<balloons> sorry, /usr/lib/sysctl.d/juju-2.0.conf
<bdmurray> balloons: juju-core 2.0.0 is still in zesty proposed due a test failure.  will we see a similar issue with y and x?
<balloons> bdmurray, no. There are two issues to note with zesty. The first is that autopkgtests are running 32-bit arches, which is invalid. The second is a true failure, current-manual-provider. This test is failing because there is not yet a published zesty agent.
<bdmurray> balloons: okay, cool
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0.0-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (xenial-proposed) [2.0.0-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (yakkety-proposed/main) [9.5.4-1 => 9.5.5-0ubuntu0.16.10] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.3 (trusty-proposed/main) [9.3.14-0ubuntu0.14.04 => 9.3.15-0ubuntu0.14.04] (no packageset)
<pitti> bdmurray: are you still doing SRUs? would be great if you could review bug 1637236 (just the usual formality)
<ubot5`> bug 1637236 in postgresql-9.5 (Ubuntu Yakkety) "New upstream microreleases 9.1.24, 9.3.15, 9.5.5" [Undecided,In progress] https://launchpad.net/bugs/1637236
-queuebot:#ubuntu-release- Unapproved: postgresql-9.1 (precise-proposed/main) [9.1.23-0ubuntu0.12.04 => 9.1.24-0ubuntu0.12.04] (core)
<pitti> . o O { looking at the test queues: can we run x86/ppc64el QEMU emulators on s390x? âº  }
-queuebot:#ubuntu-release- Unapproved: postgresql-9.1 (trusty-proposed/universe) [9.1.23-0ubuntu0.14.04 => 9.1.24-0ubuntu0.14.04] (core)
<bdmurray> pitti: I'll have a look shortly
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (yakkety-proposed) [9.5.5-0ubuntu0.16.10]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.5-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.3 [source] (trusty-proposed) [9.3.15-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.1 [source] (trusty-proposed) [9.1.24-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.1 [source] (precise-proposed) [9.1.24-0ubuntu0.12.04]
-queuebot:#ubuntu-release- Unapproved: accepted php-smbclient [source] (xenial-proposed) [0.8.0~rc1-2build1]
<pitti> bdmurray: cheers!
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (xenial-proposed) [2.0.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvme-cli [source] (xenial-proposed) [0.5-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: tcsh (yakkety-proposed/universe) [6.18.01-5 => 6.18.01-5ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: greybird-gtk-theme (yakkety-proposed/universe) [3.20.1-1 => 3.20.1-1ubuntu0.1] (no packageset)
<infinity> rcj: That's from, what?  An LP API call?
#ubuntu-release 2016-10-28
<stgraber> hmm, so what happened to snapcraft in Xenial? looks like it just went back to 2.8.4 and that's making all the lxd builds fail
<stgraber> LP says there should be 2.20 in xenial-proposed, 2.8.4 in xenial and 2.19 in xenial-updates
<stgraber> rmadison only shows 2.8.4 in xenial, not the other too
<stgraber> and publishing history confirms that 2.19 was never removed or superseded, so something weird's going on
<stgraber> infinity: ^
<stgraber> the timeline I've got is that it was fine 5 hours ago and bad an hour ago, so something happened at some point in between
<stgraber> slangasek: ^ if you're around.
<mwhudson> stgraber: huh
<mwhudson> stgraber: the publisher has gone a bit weird, that may be related
<stgraber> mwhudson: ah, what's going on with the publisher?
<mwhudson> stgraber: are you getting different answers from ftpmaster.internal vs archive.ubuntu.com ?
<stgraber> nevermind, reading scrollback of the internal channel now
<mwhudson> stgraber: dunno, see #webobs internal
<stgraber> mwhudson: yeah, they may be different answers, rmadison queries ftpmaster and that's also what LP uses
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.10+16.04ubuntu1 => 0.10+16.04ubuntu2] (no packageset)
<stgraber> so the reason is ftpmaster running out of memory and the publisher ending up doing a partial publish (not so great error handling...)
<stgraber> IS is now trying to get a succesful publisher run again to get things back to normal
-queuebot:#ubuntu-release- Unapproved: gspell (yakkety-proposed/main) [1.0.3-1ubuntu3 => 1.0.3-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New source: subiquity (xenial-proposed/primary) [0.0.23~16.04.1]
-queuebot:#ubuntu-release- New binary: gspell [armhf] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [ppc64el] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [amd64] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [arm64] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [i386] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [s390x] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gspell [powerpc] (zesty-proposed/main) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseaudio [i386] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [amd64] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [ppc64el] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [s390x] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [powerpc] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [armhf] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: pulseaudio [arm64] (zesty-proposed/main) [1:9.0-4ubuntu1] (core)
<LocutusOfBorg> *please* blacklist ghc and haskell-*
<LocutusOfBorg> somebody started the ghc-8 transition in Debian
<LocutusOfBorg> pitti, slangasek ^^ I don't want a ghc 8 transition right now
<pitti> hm, autosync isn't on yet, is it? ^ for the ghc thing
<apw> it is not as far as i know, waiting on perl was the last i heard
<oSoMoN> hi everyone. Could someone help me understand why https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=webbrowser-app ended up in the rejected queue?
<pitti> oSoMoN: you should have gotten a REJECTed email, but I guess it's because https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-051-deletedppa has been deleted
<pitti> oSoMoN: although I think this is not the same webbrowser-app upload that you were doing recently
<pitti> (this was from August already)
<oSoMoN> pitti, indeed that was a different SRU (the upload I did recently was targetting yakkety, this is for xenial)
<oSoMoN> pitti, I donât think IÂ got that rejected e-mail, Iâll check again. according to biletoâs logs (https://bileto.ubuntu.com/#/ticket/1650#audit_log) the silo was abandoned because the upload had been rejected, not the other way around
<oSoMoN> pitti, should IÂ request a new silo?
<pitti> oSoMoN: I don't know why it was rejected, or what happened to the silo, I'm afraid
<oSoMoN> no worries, Iâll request a new one then, IÂ shouldnât have let it drag on for so long
<rbasak> Does bileto not pass rejected emails along?
<apw> i have taken to dropping a note next to the reject notification from queuebot in here, but i don't think i did that one
<rbasak> Sounds like someone should file a bug against bileto
<apw> i assume the bugs go to the owner of the copying key
<apw> s/bugs/emails
<xnox> Laney, is it wise to start boost transition, when there are 5,500 hits for "perl" on the excuses page?
<xnox> pitti, oSoMoN, unfortunately the reject emails go to the bileto bot email address; effectively /dev/null
<oSoMoN> xnox, is robru aware of it? it would be useful to have that information stored and accessible somewhere
<robru> oSoMoN: there was some talk of getting those mails sent to landers, but it requires changes in launchpad, ask cjwatson if that is in production yet
<robru> oSoMoN: pitti: i think you guys are confused. The upload to the ppa wasn't rejected, the package was in the ppa and then published, but sru team rejected the upload to xenial archive
<oSoMoN> robru, yes, thatâs what I said, and some time later the silo was abandonned because of the rejection
<rbasak> bdmurray: ^
<robru> oSoMoN: yeah, I'm not aware of emails being sent for sru rejections, emails get sent if the ppa rejects an upload, so the plan to get emails sent in case of uploads rejection doesn't apply here as far as i know
<robru> robru: anyway sorry for deleting your ppa, i was being aggressive in removing landing-nnn PPAs, it looked really neglected
<robru> oSoMoN: the rejection reason should be on your bug, really: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1600176 shame it's not
<ubot5`> Ubuntu bug 1600176 in webbrowser-app (Ubuntu) "[SRU] webbrowser-app bug fixes" [High,New]
<robru> oSoMoN: not sure if you started a new ticket yet, no harm in reusing the same ticket, just click build and it'll bring the ticket back to life
<oSoMoN> robru, I started another one, and donât feel bad about deleting the other one, it was being neglected indeed, IÂ didnât do a good job of following up on it
<rbasak> robru: what if an SRU upload refers to two bugs, and the rejection reason is that a patch appears to be a third bug that doesn't appear to apply to either of them? I don't think there's a clear place for a rejection reason to go.
<rbasak> robru: or (not sure if this applies to bileto) sometimes there's an upload that needs to be rejected because it has no bug reference.
<robru> rbasak: oh jeez i dunno. The mp has a few bugs listed but that one is the only one that isn't "fix released"
<rbasak> I think there was some confusion on this upload, but it started off with me saying "why is there a patch not connected to either of the bugs listed?"
<rbasak> oSoMoN cleared that up yesterday, but it was confusing.
<robru> rbasak: http://bazaar.launchpad.net/~ci-train-bot/webbrowser-app/webbrowser-app-ubuntu-xenial-landing-051/revision/1419#debian/changelog it seems like this upload was drowning in bug references
<rbasak> Hmm. That's not the changelog I reviewed yesterday.
<robru> rbasak: no, this upload was rejected over a month ago
<rbasak> Then I'm missing your point.
<robru> rbasak: nobody seems to know why this sru was rejected, you said maybe it lacked a bug reference, i dug up the changelog to confirm it had bug references
<rbasak> No, that's not what I mean. What I'm saying is that rejection reasons aren't necessarily tied to bugs, so in the general case the right place for a rejection reason is against the upload, not against a particular bug.
<robru> Ah
<robru> Ok anyways, 3am here, goodnight, and good luck oSoMoN !
<LocutusOfBorg> infinity, my eternal gratitude for a powerpc fpc bootstrap <3
<oSoMoN> rbasak, yeah that was confusing, there were two SRUs, one targetting yakkety (that you reviewed yesterday) and one targetting xenial (that had been bitrotting for a while, and I was trying to understand why it had been rejected in the first place)
<rbasak> Ah. I had thought that the one I reviewed yesterday was the one rejected. Sorry.
<oSoMoN> no worries :)
<LocutusOfBorg> pitti, your opinion about ghc8?
<LocutusOfBorg> or slangasek
<pitti> LocutusOfBorg: no idea about haskell; I'd defer to Laney for that
<pitti> LocutusOfBorg: but, so far we don't even have autosyncs on, we first want to finish perl
<pitti> LocutusOfBorg: I don't mind blacklisting it for a bit
<LocutusOfBorg> no, but a specific blacklist would be awesome
<LocutusOfBorg> I can ask to re-enable it when things are more clear, right now we have many reverse-dependencies broken in unstable
<LocutusOfBorg> so, blocking it might be nice
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu4 => 0.6.5.8-0ubuntu4.1] (no packageset)
<LocutusOfBorg> also, two haskell libraries in new queue, and webcomponentsjs-custom-element-v0.js es-module-loader-0.17.js
<LocutusOfBorg> still for the golang stuff
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu14 => 0.6.5.6-0ubuntu15] (no packageset)
<pitti> LocutusOfBorg: ghc8 isn't in Ubuntu so it won't even be autosynced; I don't think we need a blacklist for that
<pitti> LocutusOfBorg: is there a ghc-defaults or so which needs blacklisting then?
<LocutusOfBorg> no, ghc8 is src:ghc
<LocutusOfBorg> only one is possible
<LocutusOfBorg> https://packages.qa.debian.org/g/ghc.html
<pitti> LocutusOfBorg: http://paste.ubuntu.com/23392659/ ?
<LocutusOfBorg> are you sure you don't need an additional "haskell-*" hscolour happy djinn drift and so on?
<LocutusOfBorg> I remember cjwatson putting such blacklisting a while ago, can't you recover it?
<pitti> no, I don't know at all what I'm doing :)
<LocutusOfBorg> maybe colin knows better
<LocutusOfBorg> you don't track versioning for it
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
-queuebot:#ubuntu-release- New binary: postgresql-common [amd64] (zesty-proposed/main) [177git1] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [amd64] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [armhf] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [powerpc] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [arm64] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [s390x] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-schemas [i386] (zesty-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted gspell [amd64] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [armhf] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [powerpc] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [s390x] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [arm64] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [ppc64el] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted gspell [i386] (zesty-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted postgresql-common [amd64] (zesty-proposed) [177git1]
-queuebot:#ubuntu-release- Unapproved: procps (xenial-proposed/main) [2:3.3.10-4ubuntu2.1 => 2:3.3.10-4ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [i386] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [armhf] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [amd64] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [arm64] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [s390x] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-query-hdbc [powerpc] (zesty-proposed/universe) [0.6.0.2-1] (no packageset)
<xnox> pitti, openscad does not support qt gles, since qt switched to gles on arm64 openscad can no longer build on arm64. Could you please remove arm64 openscad binaries from zesty release?
<xnox> specifically openscad 2015.03-1+dfsg-3build1 arm64
<xnox> from zesty release
<pitti> xnox: *zap*, done
<xnox> pitti, thank you!
<xnox> i'm just a couple of steps away from completing boost1.61 transition and requesting removal of boost1.60. Such that I can start boost1.62 transition without having 3 boosts in the archive.
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl looks much more reasonable now, but still a bit of work to do
 * pitti goes to do some less glorious house cleaning, have a nice evening/weekend everyone!
<ginggs> yay xnox!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.10+16.04ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (trusty-proposed) [2.0.0+dfsg-2ubuntu1.29]
<bdmurray> slangasek: I think rbasak is good to join the SRU team now.
#ubuntu-release 2016-10-29
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (zesty-proposed) [8-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (zesty-proposed) [8-3]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu15]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.1 => 2.02~beta2-36ubuntu11.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.1 => 2.02~beta2-36ubuntu11.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (yakkety-proposed) [1.74.1]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1474479173.6c180c6-0ubuntu1]
<slangasek> rbasak: welcome to the SRU team :)  (bdmurray, thanks for getting him up to speed!)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (xenial-proposed/universe) [3.18.5-0ubuntu0.1 => 3.18.5-0ubuntu0.2] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (yakkety-proposed/universe) [3.20.4-0ubuntu1 => 3.20.4-0ubuntu2] (desktop-extra, edubuntu, mozilla, ubuntugnome)
#ubuntu-release 2016-10-30
-queuebot:#ubuntu-release- Unapproved: ansible (xenial-backports/universe) [2.0.0.2-2ubuntu1 => 2.1.1.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ansible [source] (xenial-backports) [2.1.1.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accountsservice (xenial-proposed/main) [0.6.40-2ubuntu11.2 => 0.6.40-2ubuntu11.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: software-center (trusty-proposed/main) [13.10-0ubuntu4.1 => 13.10-0ubuntu4.2] (ubuntu-desktop)
#ubuntu-release 2017-10-23
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-appindicator (artful-proposed/main) [17.10.1 => 17.10.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-135.184] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-135.184]
<oSoMoN> good morning release team
<oSoMoN> can gdm3 3.26.1-3ubuntu3 migrate from -proposed to -updates?
<oSoMoN> the SRU has been verified and marked as such
<apw> oSoMoN, is that safe to release on its own ?
<apw> oSoMoN, and as it has not yet hit its SRU minimum age, do we ahve a justification for expediting it
 * apw notes that he believe that gdm3 and gnome-session must move together
<didrocks> oSoMoN: apw: FYI, I just saw the first report of people upgrading and getting fallback to gnome classic (can impact some users on upgrade, which is what the gdm/gnome-session fixes are for)
<oSoMoN> apw, sorry I somehow missed your questions earlierâ¦ gdm3 and gnome-session should move together indeed
<sil2100> Yeah, I'm about to publish those two now
<oSoMoN> apw, and as pointed out by Didier, this SRU addresses an upgrade path, so the sooner the better
<oSoMoN> sil2100, excellent, thanks!
<sil2100> apw: I'll handle it, I more-or-less approve of the skip-aging exception and I know the context
<apw> sil2100, ack thanks
<andreas> rbasak: hi,where is your merges report for the server team again? Somewhere in reports.qa.ubuntu.com, but I lost the link
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.14]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.14]
<xnox> sil2100, can you release systemd from xenial-proposed into xenial-updates?
<sil2100> xnox: I'm in the middle of reviewing the bugs just now
<sil2100> ;)
<xnox> ah, thanks.
<xnox> sil2100, although some bugs affect nplan too, systemd & nplan srus can land independent of each other.
<sil2100> Ok, good to know, since I see 2 still unverified for the nplan one
<rbasak> andreas: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html
<andreas> yep, thx
<sil2100> xnox: could you take a look at the autopkgtests related to systemd on zesty?
<sil2100> xnox: I didn't look at them yet but I see there's quite some, wonder if any are related
<xnox> sil2100, yes, but not now. it took me a while to resolve all of tests on xenial.
<sil2100> ACK
<xnox> sil2100, none are related as far as i can tell, but needs hints / overrides / bugs filed. which is what i did for xenial.
<xnox> but not yet on zesty.
-queuebot:#ubuntu-release- Unapproved: apturl (artful-proposed/main) [0.5.2ubuntu12 => 0.5.2ubuntu13] (ubuntu-desktop)
<slashd> sil2100, good day, are you guys accepting patch in Artful, even if 'Bb' not totally publicly define yet ?
<clivejo> when does the Busty Booby archive open?
<jbicha> clivejo: it can't open without a name, and then usually it takes a few days to update the toolchain (compiler, dpkg, etc.)
<clivejo> someone not poke Mark with a big stick?
<LocutusOfBorg> mark stopped giving names a few releases ago IIRC
<jbicha> I believe he still picked artful, he just didn't blog about it
<clivejo> who picks now?
<clivejo> he hasn't blogged in over a year
<clivejo> is he still alive?
<jbicha> he still picks name and he is very much still alive, he posted on twitter last week https://twitter.com/sabdfl
<acheronuk> he was on BBC News 24 the other week
<acheronuk> clivejo: https://youtu.be/eGj7eagbUNg
<clivejo> could be a robot impersonating him :/
<sil2100> slashd: that's a hard question! I'm a bit too much of a freshman in the SRU/release teams to say what's the rule here, but I'd say it's possible if the fix is important
<slashd> sil2100, ack tks ;)
<ogra_> clivejo, yeah, it is actualy an IoT robot running UbuntuCore, if we dont put the sabdfl costume on it, it looks like http://media.pennlive.com/food/photo/robot-1ca28a1d05691962.jpeg
<sil2100> slashd: anyway, I'd say yes if it matches the SRU standards ;)
<slashd> sil2100, anyway 'Bb' will be copied over artful right ?
<slashd> so 'Bb' will have the SRU'd patch anyway if my understanding is good
<cjwatson> ogra_: I'm pretty sure that if I walked into a store and saw that, I'd turn around and walk right out again and look for a pub instead
<cjwatson> in order to forget
<sil2100> Yeah, but best if you also ask someone from SRU+release with more experience
<ogra_> lol
<sil2100> I mean, it will have it then but I'm not sure if it's all formally acceptable
<slashd> sil2100, sure I'll wait then, it's not critical ;)
<slashd> thanks sil2100
<apw> slashd, artful is open for SRUs, when BB opens it will start from whatever is in A
<slashd> apw, sil2100 ^ thanks
<slashd> ddstreet, ^
<ddstreet> great!
<LocutusOfBorg> apw, also -proposed pocket?
<LocutusOfBorg> what happens if it gets rejected?
<apw> -propsoed gets copied to bb-proposed too yes
<apw> if somethign getrs rejected it might have gotten into bb, and you get to fix that too
<apw> much as you would now if bb was open, you'd upload it there, upload a backport to aa, that would fail, you would fix bb and re-upload aa
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu4 => 1:3.26.1-0ubuntu5] (ubuntu-desktop)
<LocutusOfBorg> ack thanks
<bdmurray> slangasek: Could you review my cracklib2 SRU?
-queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu4 => 1.78ubuntu5] (core)
<slangasek> bdmurray: yep, looking
-queuebot:#ubuntu-release- Unapproved: accepted cracklib2 [source] (zesty-proposed) [2.9.2-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cracklib2 [source] (xenial-proposed) [2.9.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lshw (artful-proposed/main) [02.18-0.1ubuntu3 => 02.18-0.1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: lshw (zesty-proposed/main) [02.18-0.1ubuntu3 => 02.18-0.1ubuntu3.1] (core)
<bdmurray> slangasek: I'm seeing some upgrade failures due to unity being blacklisted - that seems like a no brainer right?
<slangasek> bdmurray: blacklisted?
<bdmurray> slangasek: blacklisted for removal
<slangasek> ah
<slangasek> unity, not unity8?
<bdmurray> https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/removal_blacklist.cfg
<bdmurray> slangasek: yes, just unity
<slangasek> I agree that it should no longer be in the blacklist; I am surprised that having it blacklisted is causing upgrade problems
<bdmurray> Yeah it was fine in my testing
<slangasek> example failure?
<bdmurray> But is it worth digging into?
<slangasek> it's probably worth a small amount of digging
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1726255
<ubot5> Ubuntu bug 1726255 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade failed to upgrade from 17.04 to 17.10" [Undecided,New]
<slangasek> bdmurray: looks like ubuntu-session Breaks: on old hud/unity packages is what's causing the unexpected removal; I'd suggest logging a bug against ubuntu-session for the desktop team to look at, and get their sign-off on dropping the blacklist
<bdmurray> slangasek: bug 1681231 is v-done for zesty if you want to fast track it
<ubot5> bug 1681231 in apt (Ubuntu) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Undecided,Confirmed] https://launchpad.net/bugs/1681231
<slangasek> bdmurray: agreed, releasing, thanks
<smoser> hey. so if i was going to upload cloud-init to x, z, a i could/should do that ?
<smoser> and then just deal with anything about 'b' later on ?
<nacc> smoser: in theory, if it gets into aa before bb opens, it'll get copied forward
<slangasek> yes
<smoser> k.
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-18-gd4f70470-0ubuntu1 => 17.1-25-g17a15f9e-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> here we go for real
<blackboxsw> :)
<nacc> heh
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [17.1-18-gd4f70470-0ubuntu1~17.04.2 => 17.1-25-g17a15f9e-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-18-gd4f70470-0ubuntu1~16.04.2 => 17.1-25-g17a15f9e-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<bdmurray> slangasek: durh, the unity blacklist issue is due to not having universe enabled.
<slangasek> bdmurray: oh, wellthen
<slangasek> bdmurray: sounds like a valid user setup and that unity should be removed in that case, no?
<bdmurray> slangasek: Yes.
<jbicha> personally, I think we *should* have marked unity for autoremoval, but we'll need the rest of the Desktop Team to weigh in on that
<bdmurray> slangasek: I'm going test and upgrade w/ universe enabled and unity not blacklisted just to be safe before thinking about an SRU.
#ubuntu-release 2017-10-24
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (artful-proposed/main) [1:17.10.7 => 1:17.10.8] (core)
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu3 => 2.20.7-0ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: postfix (xenial-proposed/main) [3.1.0-3ubuntu0.1 => 3.1.0-3ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: golang-1.7 (zesty-proposed/main) [1.7.4-2ubuntu1 => 1.7.4-2ubuntu1.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.5.9-5ubuntu0.5 => 1:1.5.9-5ubuntu0.6] (core)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [169.0.0-0ubuntu1 => 176.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [169.0.0-0ubuntu1~17.04.0 => 176.0.0-0ubuntu1~17.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [169.0.0-0ubuntu1~16.04.0 => 176.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [169.0.0-0ubuntu1~14.04.0 => 176.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: valgrind (artful-proposed/main) [1:3.13.0-1ubuntu2 => 1:3.13.0-1ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1007.8] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1007.8]
<cpaelzer> Hi - can I still upload Artful SRU fixes today incrementing ubuntu1, ubuntu2, ubuntu3 - or is BB close enough (or ongoing in background) already that it has to be ubuntu1.1 ?
<apw> cpaelzer, i don't think it is uber immenent, i am sure there will be a warning, and things blocked for the copy up
<cpaelzer> ok, gogin on as usual for now then
<rbasak> I know uploading to the release pocket for an SRU automatically redirects to the proposed pocket. Is this true also for -updates? Asking for sponsorship - OK to accept and upload a debdiff targetting -updates?
<Laney> No, they'll go to -updates straight away if accepted (AFAIK)
<rbasak> OK I'll modify before uploading, thanks.
<xnox> rbasak, imho everyone should just target "release" without any suffixes, as that goes into the right queue, always, both during devel-time and SRU-time
-queuebot:#ubuntu-release- Unapproved: freeplane (artful-proposed/universe) [1.6.6-1build1 => 1.6.6-1ubuntu1] (no packageset)
<rbasak> I agree
<acheronuk> bionic beaver! O_O
 * clivejo giggles
<clivejo> so rude
<rbasak> But I want to be a little more liberal in what I accept, particularly for new contributors, because in the past a much wider range of things was acceptable in general. But I would like all sponsors to be consistent in what they recommend in order to make life easier for newcomers.
<acheronuk> sounds like a sex toy
<apw> you owuld never upload to -updates ... that is always a -proposed first scenario, as is -release in devel
<rbasak> ^ I sponsored freeplane so cannot accept the SRU. If someone else is around, it's trivial.
<apw> i concur with xnox that just uploading to "artful" is the right thing
<apw> and works in a PPA too
<rbasak> My idea is that the git ubuntu lint tool will always recommend one thing only.
<rbasak> And I'd like to get contributors to use it locally as well as have a CI bot for MPs.
<rbasak> But we're not quite there yet :)
<apw> well it should be either foo, or foo-proposed at all times, i prefer the former
<rbasak> I prefer the former also.
<rbasak> Otherwise it's "wrong" as soon as it lands.
<apw> its not wrong per-see, it is where it was uploaded to
<rbasak> I know; hence the quotes :)
<cpaelzer> acheronuk: from now on it will all be beavers until we hit https://en.wikipedia.org/wiki/Zombeavers
<clivejo> rbasak: are the plans for that git thingie fixed, or can we ask for features?
<nacc> clivejo: you can ask :)
<nacc> clivejo: what kind of features are you looking for?
<rbasak> He wants dput wrapping :)
<nacc> oh ok
<nacc> i need a spec on the changes file implementation you and cjwatson want and then we can do that :)
<nacc> well, sort of can
<rbasak> clivejo: I'm quite interested in making sure that our design accomodates stuff that we could add in the future. IOW, that we don't rule out the implementation of particular desired features in the future.
<rbasak> I won't want to add anything more to our plans for a 1.0 though.
<rbasak> But you can try and convince us :)
<clivejo> also wondering if there is flexiblity on source code hosted elsewhere, ie KDE
<rbasak> I think that may conflict with our goals depending on exactly what you mean.
<rbasak> I think it's important that drive-by contributors (or newcomers to any Ubuntu development team) get a consistent view.
<nacc> rbasak: depending on where we land with upload tags, we can probably ship a wrapper script in the snap for 1.0
<rbasak> Hosting elsewhere and with a different scheme for branches and tags and the working tree layout (eg. debian/ only) would contradict that goal I think.
<rbasak> However we absolutely don't preclude a team from maintaining a primary git tree elsewhere with a different layout.
<rbasak> A drive-by contributor wouldn't be forced to use that repo; that's all.
<clivejo> we want/need drive-bys
<rbasak> Then you don't want to be forcing them to use a git layout that's different from other packages.
<clivejo> is there no way to rope them, or deploy a stinger?
<rbasak> IHO
<rbasak> IMHO
<rbasak> I'm not saying the answer is simple.
<rbasak> There are teams that use debian/ only for good reason.
<rbasak> But it does mean that it makes sense to consider these cases out of scope for now.
<clivejo> well that is why I wanted to talk to you about it
<clivejo> it has some nice pro's and some con's
<nacc> our scope is very specific, IMO: if you want to find the current source for any package in ubuntu, you can, and you can get the full publishinng history, as presented by LP, for it
<nacc> it does not reflect development methodologies, necessarily, external sources of information, necessarily, etc.
<bdmurray> sil2100: Could you review my artful SRUs? apport and ubuntu-release-upgrader
<sil2100> bdmurray: sure
<nacc> clivejo: probably the easiest thing to do is file a bug, so we can track similar requests
<clivejo> Kubuntu is a large packageset, and like a oil tanker to maneuver, so we have to plan in advance.  But the prospect of a dput wrapper is very appealing.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (artful-proposed) [1:17.10.8]
<sil2100> bdmurray: hm, something's fishy with the apport one, I think you were missing a -v when building the package
<sil2100> bdmurray: since the changes file only includes 2.20.7-0ubuntu3.2 while there's .1 as well
<sil2100> bdmurray: could you change that? I'll reject the current one
<sil2100> Will re-review it once we're back from the dentist visit
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (artful-proposed) [2.20.7-0ubuntu3.2]
<bdmurray> sil2100: Ah, my bad the 3.1 upload was rejected. Thanks for catching that.
<nacc> clivejo: good to know, I suppose what would be best is what all you'd want in a dput wrapper for Kubuntu development https://bugs.launchpad.net/usd-importer/+filebug
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu3 => 2.20.7-0ubuntu3.1] (core)
<smoser> RAOF: if you're still around, and could look at an sru upload in queue for cloud-init i'd appreciate it.
<smoser> or if bdmurray wanted to do that... not significant changes since the one that is in -proposed.
<smoser> only 2 bug fixes and test related chagnes.
-queuebot:#ubuntu-release- Unapproved: rejected gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu4 => 1:3.26.1-0ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: sane-backends (artful-proposed/main) [1.0.27-1~experimental2ubuntu2 => 1.0.27-1~experimental2ubuntu3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libvirt (artful-proposed/main) [3.6.0-1ubuntu5 => 3.6.0-1ubuntu6] (ubuntu-server, virt)
<bdmurray> infinity: Could I get queue permissions for artful?
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu3 => 2.20.7-0ubuntu3.1] (core)
 * rbasak has just been asked for a review of libvirt (^) so will want queue permissions too
<apw> rbasak, in the short term feel free to use my fingers
<rbasak> Thanks. I'll report shortly following review.
 * rbasak is called away for dinner; will finish review later.
<tsimonq2> cjwatson: Bionic Beaver, can has graph update? ;)
<cjwatson> tsimonq2: done
<tsimonq2> cjwatson: Thanks!
<blackboxsw> bdmurray: I saw your comments on the bug https://bugs.launchpad.net/apport/+bug/1722564. I just posted a comment and updated branch that I'm going to test now
<ubot5> Ubuntu bug 1722564 in apport (Ubuntu Artful) "apport question will not accept multi-character responses" [Medium,In progress]
<blackboxsw> thanks
<rbasak> apw: +1 for libvirt in artful unapproved; please accept.
<rbasak> cpaelzer: ^.
<rbasak> cpaelzer: and thank you for comprehensively documenting everything; that made it easy to review even though it was three bugs.
<rbasak> cpaelzer: (~ubuntu-sru haven't been handed the ACL bits for artful yet it seems)
 * tumbleweed will do distro-info-data for bionic. I see a Release Schedule targetting the 26th. I guess that's plausible? https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
<bdmurray> blackboxsw: Okay, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [176.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (zesty-proposed) [176.0.0-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [176.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [176.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (artful-proposed) [3.6.0-1ubuntu6]
<bdmurray> slangasek: Could you review artful-proposed's apport upload? I made a goof.
<slangasek> bdmurray: queue shows two uploads; review newer, reject older?
<bdmurray> slangasek: Yeah, I would have rejected the older but I can't yet.
<slangasek> k, done
<slangasek> infinity: ^^ I guess you're driving the archive opening; want any help?
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (artful-proposed) [2.20.7-0ubuntu3.1]
<slangasek> (no idea where we are in the checklist currently)
<bdmurray> Actually, the apport change is on the ReleaseProcess checklist. I wonder if Martin was pinged. ;-)
<slangasek> sil2100: ^^ ?
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (artful-proposed) [2.20.7-0ubuntu3.1]
<bdmurray> slangasek: the apport SRU has been verified if you want to release it quickly
-queuebot:#ubuntu-release- Unapproved: distro-info-data (artful-proposed/main) [0.36 => 0.36ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (zesty-proposed/main) [0.33ubuntu0.1 => 0.33ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.7 => 0.18ubuntu0.8] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.3 => 0.28ubuntu0.4] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (precise-proposed/main) [0.8ubuntu0.12 => 0.8ubuntu0.13] (ubuntu-server)
<blackboxsw> RAOF: I may have missed the response, there is an SRU upload in queue for cloud-init if there is a chance to look at that today it'd be awesome
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.2.4-0ubuntu0.16.04.1 => 2.2.4-0ubuntu0.16.04.2] (ubuntu-server)
<blackboxsw> we added 3  fixes referenced here https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1721847/comments/25, one of those fixes a potential regression in our previous SRU attempt
<ubot5> Ubuntu bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1)" [Medium,Fix committed]
<LocutusOfBorg> please accept distro-info-data!
-queuebot:#ubuntu-release- Unapproved: juju-core (zesty-proposed/main) [2.2.4-0ubuntu0.17.04.1 => 2.2.4-0ubuntu0.17.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (artful-proposed/main) [1.404 => 1.405] (core)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (artful-proposed) [0.36ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (zesty-proposed) [0.33ubuntu0.2]
-queuebot:#ubuntu-release- New sync: ocaml (bionic-proposed/primary) [4.05.0-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.8]
-queuebot:#ubuntu-release- Packageset: 6673 entries have been added or removed
<sil2100>  /quit
<sil2100> eh
<RAOF> blackboxsw: The cloud-init upload is meant to supercede an upload already in -proposed, I take it?
<RAOF> blackboxsw: It needs to include the previous changelog entry in the .changes file in that case.
<jbicha> RAOF: do I need to re-upload sane-backends then?
<slangasek> Laney: https://wiki.ubuntu.com/NewReleaseCycleProcess line 46, seed-new-release expects autopkgtest.db to be on the host; this command was previously run on wendigo, but autopkgtest.db no longer exists there.  And the unit that does have autopkgtest.db doesn't have the module deps
<slangasek> Laney: I think I'm safe to copy autopkgtest.db back to wendigo and just run it there, in line with the documentation; but I wonder if you want to do something different for next cycle
<RAOF> jbicha: If it supercedes an upload that never made it out of -proposed, yes.
<RAOF> The changes file should list *all* changes since the package in -updates (or release, if there are no previous updates).
-queuebot:#ubuntu-release- Unapproved: sane-backends (artful-proposed/main) [1.0.27-1~experimental2ubuntu2 => 1.0.27-1~experimental2ubuntu3] (desktop-core, ubuntu-server)
<infinity> jbicha: Would versioning the Provides not work just as well?
#ubuntu-release 2017-10-25
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.1-25-g17a15f9e-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [17.1-25-g17a15f9e-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.1-25-g17a15f9e-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected sane-backends [source] (artful-proposed) [1.0.27-1~experimental2ubuntu3]
<RAOF> jbicha: Yeah, versioning the Provides should work (now that versioned Provides *do* work âº) and would save a trip through NEW.
<jbicha> versioning the provides how?
<infinity> jbicha: Provides: libsane (= version)
<jbicha> but how do we know which version to use?
<infinity> jbicha: Either binary:Version or a static version less than the current would be fine.
<infinity> jbicha: binary:Version would result in the same thing you got with your metapackage, but without the cruft.
<jbicha> ok, I'll give that a try
<infinity> jbicha: You also would want to replace the Breaks/Replaces with Conflicts/Replaces.  Breaks/Provides/Replaces doesn't have any higher level meaning, while P/C/R does.
<infinity> (C/R will hint for frontends to remove the old one in favour of the new one, while the versioned Provides should continue to satisfy deps)
<infinity> And C/R should be unversioned in that case (though it probably makes little difference in this specific scenario)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu5]
<jbicha> I've been told that Conflicts (instead of Breaks) is usually overkill
<infinity> They each have their place.
<infinity> C/R is what you want when you want to force a package off.
<infinity> A versioned Breaks is what you want when you want to force a package to be upgraded.
<infinity> Versioned B/R is for overwriting files that moved between versions.
<infinity> Conflicts alone is when the two packages will always conflict but neither is preferred.
<jbicha> do you really want me to switch breaks with conflicts in this sru?
<infinity> P/C/R is for when two packages provide the same interface (like this), but also if the C/R only exists in one direction, that one will take precedence and force the other off (again, like this).
<infinity> I want the relationships correct, yes.
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-18-gd4f70470-0ubuntu1~16.04.2 => 17.1-25-g17a15f9e-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<smoser> RAOF: just re-uploaded cloud-init with correct changes (sorry for the noise)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [17.1-18-gd4f70470-0ubuntu1~17.04.2 => 17.1-25-g17a15f9e-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> smoser: thanks, just saw this go up. Did I need to re-upload a new MP (for next time)? I've also added the related bugs to the SRU processbug per per comment  here https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1721847/comments/25,
<ubot5> Ubuntu bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1)" [Medium,Fix committed]
<blackboxsw> I'll add that recent changelogs to the top of that bug description too  I suppose
<smoser> blackboxsw: i uploaded just now
 * blackboxsw just got back from dinner
<smoser> blackboxsw: just for your notes... what i did was
<smoser> git checkout ubuntu/xenial
<smoser> build-package -- -S -d -v0.7.9-233-ge586fe35-0ubuntu1~16.04.2
<smoser> where that version is the version that is in -updates currently.
<smoser> they want the .changes to have the delta versus what is in -updates
<smoser> no changes, just had to build-package with the '-v'
 * smoser is out now.
<blackboxsw> night
<smoser> manana
<smoser> and i pinged in ubuntu-release for raof, but might have missed him
<smoser> :-(
<RAOF> Hey!
<RAOF> No, haven't missed me :)
<smoser> oh. sorry fo the double ping.
<smoser> i thought i was in a different channel :)
<RAOF> :)
 * smoser really shoudl go sleep now. thanks for your help.
-queuebot:#ubuntu-release- Unapproved: sane-backends (artful-proposed/main) [1.0.27-1~experimental2ubuntu2 => 1.0.27-1~experimental2ubuntu2.1] (desktop-core, ubuntu-server)
<jbicha> thanks for the help, this is only the 2nd time I've dealt with versioned provides
<jbicha> I didn't understand it the previous time either!
<valorie> jbicha: when I do something technical like that, i blog it
<valorie> so next time I can look for my blog
<jbicha> I've done that once
<valorie> if I hadn't done it many times, I would be lost!
<valorie> <--- slow learner
<jbicha> people like to hear about bugs getting fixed so maybe I will blog about it
<valorie> eh, I blog for me; if other's appreciate it, fine
<slangasek> Laney: I think I've mostly gotten the autopkgtest bits done for bionic, except for the armhf lxd containers; I can't find a straightforward way to modify the scripts to bootstrap from the existing artful images, maybe you have a trick there
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [17.1-25-g17a15f9e-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.1-25-g17a15f9e-0ubuntu1~16.04.1]
<blackboxsw> woot will test THX!
<tjaalton> infinity: I need the first wave of packages for artful hwe backport in xenial-proposed, because 16.04osp1 final base image will be built on friday, apparently..
<infinity> tjaalton: What is 16.04osp1?
<infinity> tjaalton: And why does it need stuff that's usually meant for the point release in 3 months?
<tjaalton> oem service pack 1
<tjaalton> base image for next wave of oem systems
<tjaalton> yes the schedule doesn't match
<tjaalton> because of intel gemini lake, coffee lake etc
<tjaalton> amd raven ridge
<tjaalton> the queue has had libdrm, wayland-protocols, llvm-5 for mesa, libclc will be uploaded once llvm-5 is built
<infinity> tjaalton: Well, the idea that we'll fasttrack this all through in 3 days seems a bit unreasonable.
<tjaalton> just to proposed
<tjaalton> no need to push it to updates
<tjaalton> they already use ppa's for the image, which is kinda bad
<tjaalton> they can stay on proposed until the whole stack is ready
<infinity> "kinda bad"?
<infinity> Very bad.
<infinity> Especially if those PPAs are enabled on customer systems.
<infinity> Yay undue post-release maintenance burden.
<infinity> But okay, I can try to find some review cycles after the archive opening is done.
<tjaalton> great, thanks
<tjaalton> noone else seems to touch these uploads ;)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.36 => 0.37] (core) (sync)
<tjaalton> oh and the ppa's are only used when building the image, but still..
<cpaelzer> thanks rbasak and apw, looking into build status, verification and more safety regression checks now
<cpaelzer> apw: so the race I was afraid of happened with libvirt 3.6.0-1ubuntu6 in a-p and  3.6.0-1ubuntu5 now.
<cpaelzer> should I make an  3.6.0-1ubuntu6 to bionic now instead and prep an identical  3.6.0-1ubuntu5.1?
<cpaelzer> or can on the acceptance of  3.6.0-1ubuntu6 that be copyied to Bionic as well?
<infinity> cpaelzer: Anything accepted in artful before bionic is completely open will be copied forward by me.
<infinity> cpaelzer: After that, it's a bit more of a crapshoot, but you can always copy yourself if you have upload rights to the series.
 * infinity goes to find some food to fuel the home stretch on the opening.
<cpaelzer> infinity: ok, to be sure please define "accepted" in that regard - being in proposed (waiting for it's SRU proposed days to pass) - will that be copied over by you when it completely opens?
<cpaelzer> want to avoid the crapshooting :-)
<cpaelzer> but enjoy your meal first
<acheronuk> if I want to revert to an older source to fix an issue that is going to take some time upstream to adapt to on new sources, is versioning like that acceptable for a SRU?
<acheronuk> i.e. versioning a source laterversion+really.olderversion
<apw> cpaelzer, yes the contents of -proposed gets copied forward, if it has binaries then those too
<apw> acheronuk, it is something like .is.oldversion
<acheronuk> apw: well, looking at archive packages, I see several variation on a theme, of haow people do it
<apw> acheronuk, yeah am trying to find if there is a definative source and recommendation for names
<acheronuk> question was really if that reversion to a quite a bit earlier source is ok for a SRU
<acheronuk> or whether just patch out the commits since the last good commit in the current source is better
<acheronuk> both are mildly evil
<apw> a major version bump in any direction is not lightly taken as a SRU
<apw> but the primary issue is the size and scope of the delta regardless of versioning
<acheronuk> well, in this case, only KDE uses the package now (signon-ui), and it is utterly broken in artful
<apw> i am glad to see we tested artful before release </sarcasm>
<acheronuk> well, it's a feature that has limited scope for use by an end user by default in artful, so went under the radar a bit
<apw> well if it is utterly broken, and noone uses it, the scope for regression is low so you would have more lattitude in fixing it
<acheronuk> but will be wanting to fix for 18.04, and backports, as the new Google drive integration in our file manager that we want to include requires it
<acheronuk> apw: yes, just wanted to check what was acceptable, and what might be a preferred way to jump
<apw> acheronuk, it doesn't sounds like either of those will be a different delta, and it is the delta we care about from a regression perspective
<acheronuk> personally would would re-upload the old source, as then it's quite clear what has been done in it's version string
<acheronuk> * I would
<apw> acheronuk, to get to a working place, it makes more sense you would do it the way is most sensible to you as you have to maintain it going forward i guess
<apw> just expect lots of gagging from teh reviewrs when you upload either way
<acheronuk> indeed. well, it would not be super critical if it got rejected for artful. going to include it in our updates ppa anyway. just an archive fix is better
<acheronuk> apw: ok. thanks for all that :) I will ponder it
<apw> np
<infinity> Laney: Poke me when you're up.
<Laney> infinity: STAB
<infinity> Laney: Ow.
<infinity> Laney: If you could double-check Steve's work on autopkgtest stuff and figure out how to make armhf love bionic, that would be lovely.
<Laney> ok
<Laney> do we have an archive now?
<infinity> Laney: Yep.
<Laney> sehr gut
<sil2100> infinity: when is the mass copy of artful to bionic planned?
<infinity> sil2100: Yes.
<infinity> sil2100: Sometime after Laney assures me that autopkgtests are going to work, so we don't miss any triggers.
<infinity> (Or, I guess, if he assures me that the queue is ready to accept triggers, even if the runners won't be firing yet)
<infinity> Laney: ^
<sil2100> Oh, meaning quite soon I suppose
<Laney> Gimme a bit
<infinity> Yeah, soonish.
<infinity> Certainly during today's London work day.
<infinity> I'm not in a huge rush to do it RIGHT NOW, but definitely today.
<sil2100> Was asking since I want to push stuff into the artful queue, was wondering if I should aim for making it before the copy or not
<infinity> sil2100: *shrug*
<infinity> sil2100: If you don't make it, you can copy things later.  It's not rocket surgery.
<infinity> Anyone with upload rights can copy forward.
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (artful-proposed/main) [0.7 => 0.7.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20171006+dfsg1-0ubuntu1 => 20171019+dfsg1-0ubuntu1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20171006+dfsg1-0ubuntu1~17.04.0 => 20171019+dfsg1-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20171006+dfsg1-0ubuntu1~14.04.0 => 20171019+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20171006+dfsg1-0ubuntu1~16.04.0 => 20171019+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: pacemaker (xenial-proposed/main) [1.1.14-2ubuntu1.2 => 1.1.14-2ubuntu1.3] (ubuntu-server)
<jamespage> any sru team members around? ^^ pacemaker update stops the packaging shooting pacemaker in the head and then not restarting on upgrade which we've seen due to the recent security update
<jamespage> if that could be processes asap and if possible pushed to -updates and -security once verified we might save users some pain
<jamespage> not sure if we can push it to -security
<apw> jamespage, needs to be built in the security-ppa if it is going to -security
<apw> (well against -security only, but you get the idea)
<jamespage> apw: hmm ok - who's around who I can talk to about that?
<apw> if you want to shove it out to -security you might want to ask them about sponsoring it
<apw> arround is an interesting question ... /me thinks
<jamespage> apw: yeah that was my worry - unattended security updates are gradually killing bits of HA openstack clouds atm
<jamespage> I have gnuoy running around restarting pacemaker atm
<jamespage> but he can't do that for the rest-of-the-world
<cjwatson> (this was what killed lgw01 this morning, FWIW)
<apw> i guess i could build it in the kernel security PPA
<rbasak> Seems to me it should go to -security. Otherwise users who get -security and not -updates will still be broken, and the bug is being triggered by something new being published into -security.
<apw> indeed
<sil2100> Yeah
<jamespage> rbasak: yeah its specifically  security auto-updates (which default to on) causing the pain here
<jamespage> so I want to superceed the one in -security ASAP
<sil2100> We don't have any security people around in our timezone?
<rbasak> ratliff is in the #ubuntu-hardened topic. Or infinity?
<jamespage> pinged ratliff
<jamespage> I suspect she's not up yet
 * apw will try and build it in the kernel security PPA in parallel
<jamespage> apw: can you pull from unapproved?
<apw> i can ...
<infinity> I'm here.
<infinity> Lemme slam it through the proper channels.
<jamespage> infinity: ta
<jamespage> I'm aware that I've done my own testing via the PPA as well as having prepared the update
<jamespage> I can do testing once in proposed but a second pair of eyes on the test case would be good
<infinity> jamespage: How did this regress in the security update?
<infinity> Or was it just the act of updating that breaks it.
<jamespage> infinity: its not a regression - its just the first update to pacemaker since xenial release-ish
<jamespage> and its just the act that breaks things
<infinity> Right, so updating "regressed" it, just by virtue of updating sucking.
 * infinity nods.
<infinity> I'm good enough with calling that a security regression.
<jamespage> awesome
-queuebot:#ubuntu-release- Unapproved: rejected pacemaker [source] (xenial-proposed) [1.1.14-2ubuntu1.3]
<infinity> apw: source upload rejected, binary copy in queue, deal with it as you see fit.
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (artful-proposed) [20171019+dfsg1-0ubuntu1]
<infinity> apw: Permission granted in advance to "sru-release --security" when you and jamespage agree it's good.
-queuebot:#ubuntu-release- Unapproved: pacemaker (xenial-proposed/main) [1.1.14-2ubuntu1.2 => 1.1.14-2ubuntu1.3] (ubuntu-server) (sync)
<infinity> apw: The team can sort out the regression USN in the US morning.
<apw> infinity, ack thanks ...
<jamespage> apw, infinity: I've tested from the security-proposed PPA and updated https://bugs.launchpad.net/ubuntu/zesty/+source/pacemaker/+bug/1727063
<ubot5> Ubuntu bug 1727063 in pacemaker (Ubuntu Xenial) "Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage" [Critical,Triaged]
<jamespage> I'd like a co-pilot on the testing if possible - its pretty easy to reproduce
<jamespage> (and you can do so in a LXD container btw)
 * infinity goes back to bionic and lets you two deal with this.
-queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.29.1-4ubuntu1 => 2.29.1-6ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: icu (bionic-proposed/main) [57.1-6 => 59.1-3] (core) (sync)
<LocutusOfBorg> mmm people uploading to bionic...
<sil2100> Toolchain
<apw> LocutusOfBorg, just the beginings of the toolchain i hope
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [sync] (xenial-proposed) [1.1.14-2ubuntu1.3]
<apw> jamespage, ok i've accpeted the security sync, so that should appeare in -proposed shortly ^^
<jamespage> apw: ok documented my testing on bug 1727063
<ubot5> bug 1727063 in pacemaker (Ubuntu Xenial) "Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage" [Critical,Triaged] https://launchpad.net/bugs/1727063
-queuebot:#ubuntu-release- Unapproved: golang-1.7 (artful-proposed/universe) [1.7.4-2ubuntu1 => 1.7.4-2ubuntu1.1] (kubuntu, ubuntu-desktop)
<jamespage> apw: dosaboy is also upgrading some of his cloud which broke am this morning with the proposed update
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.2.0-8ubuntu3 => 7.2.0-12ubuntu1] (core)
<Laney> infinity: should be good to go
<Laney> britney needs updating before I can try with run-autopkgtest though
 * Laney does the needful
-queuebot:#ubuntu-release- Unapproved: gcc-5 (bionic-proposed/main) [5.5.0-1ubuntu1 => 5.5.0-2ubuntu1] (core)
<doko> accepted binutils, will end up in NEW anyway
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (bionic-proposed) [0.37]
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (bionic-proposed) [2.29.1-6ubuntu1]
<infinity> Laney: britney should be updated.
<infinity> Unless I failed to commit.
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [9.6ubuntu102 => 10ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10ubuntu1]
 * infinity wonders who accepted base-files.
<infinity> doko: If that's you, please stop accepting stuff until Laney and I are sure britney's working.
-queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [source] (bionic-proposed) [7.2.0-12ubuntu1]
<doko> infinity: ok
-queuebot:#ubuntu-release- New binary: binutils [s390x] (bionic-proposed/main) [2.29.1-6ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.2.0-8ubuntu3 => 7.2.0-12ubuntu1] (core)
<Laney> infinity: Argh, no, I forgot s390x is a special snowflake
 * Laney eyes 106122
<infinity> Laney: Yeeees, 106122...
<infinity> Laney: Also, did I actually miss something with britney, or did you just end up checking my work? :P
<apw> jamespage, touch testing of that pacemaker update is good here ...
<apw> jamespage, did dosaboy succeeed ...
<jamespage> apw: he did and commented in the bug
<jamespage> apw: lets get this releases
<apw> jamespage, yep just waiting on the publisher, will get it out shortly
<jamespage> apw: awesome
<Laney> infinity: Umm, dunno, I made the .bionic configuration files myself - can't remember how they're created right now
<Laney> I didn't update the excuses/output symlinks yet
<infinity> Laney: Oh, right, the config files.  Derp.
<Laney> run-autopkgtest grubs around in those to find the stuff it needs
-queuebot:#ubuntu-release- New binary: binutils [ppc64el] (bionic-proposed/main) [2.29.1-6ubuntu1] (core)
<Laney> so
<infinity> la
<Laney> Temporary failure resolving âsquid.internalâ
<apw> Laney, we _so_ love those
<Laney> I guess something nplannish needs to happen ...
<infinity> Oh, this is in your shiny new guests?
<apw> jamespage, ok buttons pushed, will be out "soon"
<infinity> Didn't just copy and hack up artful ones?
<Laney> maybe I can do that
<Laney> I was just trying to make new lxc container
<Laney> s
<jamespage> apw: +1 ta
<Laney> ok, that works
<sil2100> apw: thanks for dealing with that!
<Laney> seems good to me now
-queuebot:#ubuntu-release- New binary: binutils [armhf] (bionic-proposed/main) [2.29.1-6ubuntu1] (core)
<mdeslaur> infinity: thanks for pacemaker
<infinity> Laney: Seems good as in, we should enable archive-reports and watch the world burn?
<Laney> infinity: If they're otherwise ready, goferit
<Laney> bit of a queue backlog on x86 due to snapd, but that should clear out soon enough
<infinity> Laney: I mean, I always forget/miss something, but I think they're ready. :P
<infinity> So, let's see what happens.
<infinity> Whee.
 * apw looks out the window to see if he can see smoke yet ...
<cjwatson> FWIW we'll be stopping buildd-manager for a bit in the process of initialising translations, so builds will queue for a bit longer than usual
<infinity> cjwatson: Mmkay.
<cjwatson> and also build logs not update etc.  but it'll all catch up.
<infinity> wget -q --mirror -nH --cut-dirs=3 -np -R *index.html* -P /home/ubuntu-archive/mirror/phone-overlay -X /*/*/*/*/*/*/i18n http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/dists/
<infinity> Yeah, that needs to go away from archive-reports.
<infinity> Ick.
<sil2100> Oh god
<sil2100> Was that still around?
<cjwatson> my excuse is I couldn't think of a better way
<cjwatson> but yes
<cjwatson> though I don't think that can all have been me - I'd have quoted better
<infinity> There's a bunch of phone overlay and RTM and other cruft on snakefruit that needs careful removal.
<infinity> Today's not the day I'm doing that.
<infinity> cjwatson: That was from ps(1), it may well be quoted pretty in the original script.
 * apw hands infinity a very large and sharp machette
<Laney> britney runneth
<infinity> Yea verily.
<infinity> Hrm, I should have copied forward before the first run.  Now I'll have to mangle the copied-forward britney state again, I think.
<infinity> Maybe.
<cjwatson> buildd-manager is back up.
<infinity> Oh, no, looks like I didn't lose any state.  Yay.
<infinity> Laney: So, I guess let's see how these tests triggered from base-files and distr-info-data do, and call it good.
<Laney> Kool Beanz
<Laney> some of them seem to be in already, and look OK to me
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (artful-proposed) [1:3.13.0-1ubuntu3]
-queuebot:#ubuntu-release- New binary: binutils [arm64] (bionic-proposed/main) [2.29.1-6ubuntu1] (core)
<apw> infinity, ^^ something just got accpeted in artful ...
<infinity> apw: I noticed.  Not terribly concerned.
<cpaelzer> infinity: on our discussion this morning - I have a bunch of FTBFS fixes in Artful for a while - they are still in unapproved
<cpaelzer> infinity: now that bionic is close do we have to reroll those, or would you think you let them in and copy them over as well as part of opening binoic?
<infinity> cpaelzer: I'm sure we can manage the latter.
<cpaelzer> infinity: ok, in case this does not work out - just update the associated bugs or ping me or whatever you find appropriate
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (xenial-proposed) [3.1.0-3ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (xenial-proposed) [1.18.4ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (trusty-proposed) [3.12.0-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: sphinx (bionic-proposed/main) [1.5.6-2 => 1.6.5-1] (edubuntu, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ocaml (bionic-proposed/universe) [4.04.0-2ubuntu4 => 4.05.0-10ubuntu1] (kubuntu) (sync)
<xnox> doko, can you please reject both of ocaml syncs from bionic queues? one is in bionic unapproved, the other one is in bionic new -> both syncs are bad, as they include binaries.
<xnox> or maybe apw ?
<xnox> https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=ocaml & https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text=ocaml
<infinity> xnox: Done.
<xnox> infinity, tah
-queuebot:#ubuntu-release- New: rejected ocaml [sync] (bionic-proposed) [4.05.0-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ocaml [sync] (bionic-proposed) [4.05.0-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ocaml (bionic-proposed/universe) [4.04.0-2ubuntu4 => 4.05.0-10ubuntu1] (kubuntu)
<doko> infinity: I see the first packages did migrate. so can we go on with accepting packages?
-queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [source] (bionic-proposed) [7.2.0-12ubuntu1]
<infinity> doko: I rejected gcc-7 due to rules.conf not mentioning bionic.
<infinity> (Well, you can read the reject message)
<infinity> doko: But yes, you should be good in general to start building toolchain things, and prep early transitions and such.
<doko> infinity: ok
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (bionic-proposed) [5.5.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml [source] (bionic-proposed) [4.05.0-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted icu [sync] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [sync] (bionic-proposed) [1.6.5-1]
-queuebot:#ubuntu-release- New binary: icu [s390x] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- New binary: icu [amd64] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (artful-proposed/partner) [1:20171016.1-0ubuntu1 => 1:20171025.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: icu [i386] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (artful-proposed/main) [3.22.24-0ubuntu2 => 3.22.24-0ubuntu2.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: icu [arm64] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- New binary: icu [armhf] (bionic-proposed/main) [59.1-3] (core)
-queuebot:#ubuntu-release- New: accepted icu [amd64] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- New: accepted icu [ppc64el] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- New: accepted icu [i386] (bionic-proposed) [59.1-3]
-queuebot:#ubuntu-release- Unapproved: automake-1.15 (bionic-proposed/main) [1:1.15-6ubuntu1 => 1:1.15.1-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted automake-1.15 [source] (bionic-proposed) [1:1.15.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: valgrind (bionic-proposed/main) [1:3.13.0-1ubuntu2 => 1:3.13.0-1ubuntu3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [sync] (bionic-proposed) [1:3.13.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gcc-5 (bionic-proposed/main) [5.5.0-1ubuntu1 => 5.5.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (bionic-proposed) [5.5.0-2ubuntu2]
<infinity> doko: Due to a circular dep/breaks issue with debhelper/dpkg, they'll need a bit of care, so I'll do both after I've slept.
<infinity> doko: If someone uploads one or the other, reject them if you don't want the archive to break. :P
-queuebot:#ubuntu-release- Unapproved: lxcfs (artful-proposed/main) [2.0.7-0ubuntu5 => 2.0.8-0ubuntu1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: binutils [amd64] (bionic-proposed/main) [2.29.1-6ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-5 (bionic-proposed/main) [5.5.0-2ubuntu2 => 5.5.0-2ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted binutils [amd64] (bionic-proposed) [2.29.1-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [armhf] (bionic-proposed) [2.29.1-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [s390x] (bionic-proposed) [2.29.1-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [arm64] (bionic-proposed) [2.29.1-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [ppc64el] (bionic-proposed) [2.29.1-6ubuntu1]
<slangasek> Laney: I was seeing that 'failure to resolve squid.internal' on the s390x containers, and it did *not* seem to be a netplan problem... the containers had a resolv.conf pointing at the upstream gateway... did you figure out what was goin on there?
<LocutusOfBorg> [16:03:28] <BTS> Opened #879762 (serious) in src:debhelper 10.10 by James Cowgill (jcowgill) Â«debhelper: fails to parse debian/control files with leading blank linesÂ». https://bugs.debian.org/879762
<ubot5> Debian bug 879762 in src:debhelper "debhelper: fails to parse debian/control files with leading blank lines" [Serious,Open]
<acheronuk> infinity: tsimonq2 via telegram asks if he can 'steal your debhelper merge later'?
<Laney> slangasek: nope - I copied the artful contianers and dist-upgraded those instead
<Laney> if you feel like digging in, be my guest
<acheronuk> whatever the hell means. don't shoot the messenger
<slangasek> Laney: yeah, probably not; I'm hopeful that the RT will be resolved and we don't have to do this again for cacophonic
 * Laney had the same thoughts :-)
<slangasek> acheronuk: the answer is no, infinity needs to bootstrap dpkg+debhelper due to breaks, needs an AA to do that
<acheronuk> slangasek: understood. I will pass that to tsimonq2
<LocutusOfBorg> slangasek, please  have a look at https://bugs.debian.org/879762
<ubot5> Debian bug 879762 in src:debhelper "debhelper: fails to parse debian/control files with leading blank lines" [Serious,Open]
<LocutusOfBorg> infinity, ^^^
<LocutusOfBorg> don't break the archive :)
-queuebot:#ubuntu-release- Unapproved: dcmtk (bionic-proposed/universe) [3.6.2-2 => 3.6.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ledger (bionic-proposed/universe) [3.1.2~pre1+g3a00e1c+dfsg1-5 => 3.1.2~pre1+g3a00e1c+dfsg1-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ncmpcpp (bionic-proposed/universe) [0.7.4-1build3 => 0.7.4-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (bionic-proposed/universe) [3.26.1-1ubuntu1 => 3.26.1-1ubuntu2] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: libvmime (bionic-proposed/universe) [0.9.2-3 => 0.9.2-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjfx (bionic-proposed/universe) [8u141-b14-3 => 8u141-b14-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-mapnik (bionic-proposed/universe) [1:0.0~20170120-8139e5c-1~exp1build1 => 1:0.0~20170120-8139e5c-1~exp1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dcmtk [source] (bionic-proposed) [3.6.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (bionic-proposed) [5.5.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libvmime [source] (bionic-proposed) [0.9.2-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [source] (bionic-proposed) [8u141-b14-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (bionic-proposed) [3.26.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ncmpcpp [source] (bionic-proposed) [0.7.4-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted ledger [source] (bionic-proposed) [3.1.2~pre1+g3a00e1c+dfsg1-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-mapnik [source] (bionic-proposed) [1:0.0~20170120-8139e5c-1~exp1build2]
-queuebot:#ubuntu-release- Unapproved: widelands (bionic-proposed/universe) [1:19+repack-4 => 1:19+repack-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted widelands [source] (bionic-proposed) [1:19+repack-4build1]
<xnox> slangasek, apt remove --purge libnss-resolve ?
<slangasek> xnox: interesting, why would that have been installed in a freshly bootstrapped bionic container?  anyway, I'm not going back to check it out :)
<xnox> slangasek, freshly installed should be fine, but i see above mentions of upgraded one too.
<xnox> slangasek, also failure to resolve squid.internal -> is the container booted and running? e.g. there is nothing fishy done, like chrooting to it with starting systemd-resolved and expecting things to work?
-queuebot:#ubuntu-release- Unapproved: python-mapnik (bionic-proposed/universe) [1:0.0~20170120-8139e5c-1~exp1build1 => 1:0.0~20170621-0cd7493f2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-mapnik [sync] (bionic-proposed) [1:0.0~20170621-0cd7493f2-1]
-queuebot:#ubuntu-release- New source: boost1.65.1 (bionic-proposed/primary) [1.65.1+dfsg-0ubuntu1]
<slangasek> xnox: my test was fresh creation of a container; /etc/resolv.conf was not pointing at resolved but at the upstream resolver.
<slangasek> xnox: but again, I'm not going to chase this further, Laney JFDI and we should just get this moved into scalingstack
<xnox> slangasek, oh, but you must be using obsolete lxc-templates.
<xnox> slangasek, artful lxc1 can make artful lxc1 containers using fixed up templates.
<xnox> slangasek, lxd just works, as we control the LXD image overrides hence they just work on any lxd version.
<slangasek> Â¯\(ã·)/Â¯
<xnox> so xenial's lxc1 cannot create artful+ containers at the moment.
<xnox> using the old e.g. download-ubuntu or debootstrap variants.
<xnox> i think it will be resolved with the next backport / point rleease, or some such.
<bdmurray> slangasek: Could we release apport to artful early?
<slangasek> bdmurray: y
<slangasek> bdmurray, apw, rbasak: distro-info-data has caused a regression in juju; I'd like to get a second set of SRU eyes on my proposed plan in https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1727355/comments/4
<ubot5> Ubuntu bug 1727355 in distro-info-data (Ubuntu) "no matching agent binaries available with 2.2.5" [High,Triaged]
<xnox> ... or simply revert the last update?
<slangasek> xnox: that will break users of all the dev tools that need distro-info-data to match LP
<slangasek> (e.g. pull-lp-source; dch)
<slangasek> balloons: btw, it's obviously wrong for juju to bootstrap to bionic by default while bionic is not released, but the other part that exposed this bug is the lack of agent binaries for bionic... when will that piece be fixed?
<balloons> slangasek, yea, there hadn't been a release yet, so we didn't have agents of course
<balloons> because the client and agent are tied together, 2.2.5 for instance will never run on bionic as it was released before it
<slangasek> oh?
<slangasek> why would you not copy the agents forward?
<balloons> in order to support bionic on 2.2.5, we'd have to build an agent for it, then add it to streams. Not impossible to do, but we would have to do it for every old version
<balloons> juju lives on the upgrade treadmill; this is an example
<slangasek> I think that's categorically broken
<xnox> slangasek, well, it would be more hallarious if people started to successfully deploy bionic instances instead of xenial in production.
<slangasek> the agent should copy forward by default, just like everything in the Ubuntu archive does
<balloons> if the agent / client was separated or the client always bootstrapped the latest (as 1.25 did) things would be different
<slangasek> xnox: absolutely
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.4 => 0.33ubuntu0.3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (xenial-proposed) [0.33ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.4 => 0.28ubuntu0.5] (core)
<balloons> slangasek, you probably can won't fix for trusty
<balloons> slangasek, though hmmm
<slangasek> balloons: is that because you don't intend to fix the client in trusty?
<slangasek> or because the client isn't broken in trusty?
-queuebot:#ubuntu-release- Unapproved: distro-info-data (zesty-proposed/main) [0.33ubuntu0.2 => 0.33ubuntu0.3] (core)
<balloons> slangasek, there isn't a juju-2 client in trusty, so indeed. That said, juju-1 client on trusty probably is broken too. I should check
<xnox> is trusty juju1 or juju-core?
<slangasek> balloons: please do :)
<balloons> juju-core
<xnox> ack
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.8 => 0.18ubuntu0.9] (core)
<slangasek> apw, bdmurray, rbasak: so, I don't want to just self-accept the above given its irregularity, but I'm dealing with a sick kiddo and will be afk from ~now for most of the day.  It would be great if one of you could review and potentially accept + fast-track the above today
<balloons> slangasek, trusty is fine with 0.18ubuntu0.8
<slangasek> balloons: ok, thanks
<balloons> slangasek, juju-2 on it will be broken though, but that's not in the archive
-queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (trusty-proposed) [0.18ubuntu0.9]
<balloons> looks good, ty
<slangasek> balloons: can you update the bug with a test case (what command to run, expected output vs. failure output)?
<balloons> slangasek, yep
<bdmurray> slangasek: I can have look see
<slangasek> bdmurray: ta!
<bdmurray> slangasek: How will the work to add LTS back be tracked?
<slangasek> bdmurray: I'm intending to upload the revert SRU to the queue as soon as this version is accepted
<bdmurray> slangasek: And how will it not be accepted accidentally?
<slangasek> bdmurray: if you prefer I can wait until this version is in -updates so it doesn't accidentally get accepted over it
<slangasek> bdmurray: and then I would pre-emptively mark the bug v-failed
<bdmurray> slangasek: Oh, so the reall distro-info-data will live in -proposed until juju ends up in -updates?
<slangasek> bdmurray: that's the idea yes
<slangasek> bdmurray: I would also add a Breaks: against the un-fixed juju-core versions
<slangasek> really afk now, sorry
<bdmurray> balloons: slangasek's comment about juju 2.2.4 already being in the SRU stream lead me to believe it was already in -proposed which it isn't. Why can't the one waiting in the -proposed queue be fixed?
<balloons> bdmurray, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1718213
<ubot5> Ubuntu bug 1718213 in juju-core (Ubuntu Zesty) "[SRU] Juju 2.2.4" [Undecided,In progress]
<balloons> bdmurray, ohh you mean, why isn't the fix in the proposed stream? or why we would want to push 2.2.6 as the fix?
<bdmurray> balloons: Yeah, why not just fix 2.2.4?
<bdmurray> Its not anywhere real yet.
<balloons> bdmurray, we would have to distro patch it into 2.2.4. It would be ok in this case though as the change is purely client side, so the existing agents are fine to be fair
<balloons> imho makes more sense to just rev the source so we don't have to carry patches
<balloons> since it's not released
<bdmurray> "carry patches" where are you carrying it if 2.2.6 is coming out?
<bdmurray> I guess it really doesn't matter as we'd still need the distro-info-data SRU for the existing version of juju and we can fast track that SRU more quickly than juju. The argument about not fixing 2.2.4 is still odd to me though.
<balloons> bdmurray, I'm not following you, I'm sorry. I'm working to rev a 2.2.6 version of juju. We'll want to include the change in the SRU version of juju. Since 2.2.4 is already in proposed, i thought it made sense to just rev that to the new version, since we didn't release it. Since 2.2.X was in the SRU pipeline already, it doesn't make sense to push a
<balloons>  specific SRU for this to the 2.0.2 package in xenial currently
<balloons> The end result is juju 2.2.6 and distro-info-data sitting in proposed tonight/tomorrow happily working together. Then we can land them both
<balloons> or my thoughts anyway
<doko> infinity: is the migration block still intended to be in place?
<bdmurray> balloons: 2.2.4 is not already in -proposed though
<balloons> bdmurray, am I missing something? https://launchpad.net/ubuntu/+source/juju-core/. I tested it from proposed
<balloons> it's been in there for a bit
<bdmurray> balloons: Ah, I also saw 2.2.4-0ubuntu0.17.04.2 in the queue
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (zesty-proposed) [0.33ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.5]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20171025.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20171016.1-0ubuntu0.14.04.1 => 1:20171025.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20171016.1-0ubuntu0.17.04.1 => 1:20171025.1-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20171016.1-0ubuntu0.16.04.1 => 1:20171025.1-0ubuntu0.16.04.1] (no packageset)
<LocutusOfBorg> I have prepared dpkg and debhelper
<LocutusOfBorg> tsimonq2, ^^
<LocutusOfBorg> I'm testing some rebuilds in my ppa https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13619303
<LocutusOfBorg> so far so good
-queuebot:#ubuntu-release- Unapproved: debhelper (bionic-proposed/main) [10.7.2ubuntu2 => 10.10.4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (bionic-proposed/main) [1.18.24ubuntu1 => 1.19.0.4ubuntu1] (core)
<LocutusOfBorg> I still need to do some more testing, but so far the merge is correct
<LocutusOfBorg> I need to check for ddeb creation
<LocutusOfBorg> actually kbuild is good and it produced ddebs correctluu
<LocutusOfBorg> so, if any AA wants to accept them together...
<LocutusOfBorg> binutils is good, and it provides old -dbg packages
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20171025.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20171025.1-0ubuntu0.17.04.1]
<tsimonq2> LocutusOfBorg: ack, although I thought infinity wanted to do those...
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20171025.1-0ubuntu0.14.04.1]
<LocutusOfBorg> infinity, whants somebody to accept them together
<LocutusOfBorg> for obvious reasons
<LocutusOfBorg> (bootstrap)
<LocutusOfBorg> they need to be published in the same cycle
<tsimonq2> cyphermox: Were the slideshow updates for Lubuntu not merged or was the MP not updated?
<tsimonq2> (for Artful)
<cyphermox> tsimonq2: maybe I missed pushing
<tsimonq2> cyphermox: ok, please let me know
<cyphermox> tsimonq2: lp:ubiquity-slideshow-ubuntu corresponds to what was uploaded in 133
<tsimonq2> cyphermox: And it has the Lubuntu slideshow updates right?
<tsimonq2> (if so could you please update the MP?)
<cyphermox> tsimonq2: I don't know, only guess so
-queuebot:#ubuntu-release- Unapproved: 0ad (bionic-proposed/universe) [0.0.21-2 => 0.0.21-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: 389-adminutil (bionic-proposed/universe) [1.1.23-1build1 => 1.1.23-1build2] (no packageset)
<cyphermox> I have no idea where that MP is, it looks to me like there are no open to-review MP except Gunnar's
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (bionic-proposed/universe) [1.3.7.5-1 => 1.3.7.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: aegisub (bionic-proposed/universe) [3.2.2+dfsg-3build6 => 3.2.2+dfsg-3build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: 389-dsgw (bionic-proposed/universe) [1.1.11-2build3 => 1.1.11-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: an (bionic-proposed/universe) [1.2-1build2 => 1.2-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: boost1.62 (bionic-proposed/main) [1.62.0+dfsg-4build3 => 1.62.0+dfsg-4build4] (core)
-queuebot:#ubuntu-release- Unapproved: boost1.63 (bionic-proposed/universe) [1.63.0+dfsg-1ubuntu3 => 1.63.0+dfsg-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: calibre (bionic-proposed/universe) [3.7.0+dfsg-2 => 3.7.0+dfsg-2build1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: cg3 (bionic-proposed/universe) [1.0.0~r12254-1ubuntu1 => 1.0.0~r12254-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dee (bionic-proposed/main) [1.2.7+17.10.20170616-0ubuntu1 => 1.2.7+17.10.20170616-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: brltty (bionic-proposed/main) [5.4-7ubuntu4 => 5.4-7ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: couchdb (bionic-proposed/universe) [1.6.0-0ubuntu8 => 1.6.0-0ubuntu9] (no packageset)
<tsimonq2> cyphermox: ok thanks
-queuebot:#ubuntu-release- Unapproved: dwdiff (bionic-proposed/universe) [2.1.1-1 => 2.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: firebird3.0 (bionic-proposed/universe) [3.0.2.32703.ds4-9 => 3.0.2.32703.ds4-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnustep-base (bionic-proposed/universe) [1.24.9-3ubuntu1 => 1.24.9-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grcompiler (bionic-proposed/universe) [4.2-6build1 => 4.2-6build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-text-icu (bionic-proposed/universe) [0.7.0.1-6build2 => 0.7.0.1-6build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (bionic-proposed/main) [3.26.1-1ubuntu1 => 3.26.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnustep-gui (bionic-proposed/universe) [0.25.0-4build1 => 0.25.0-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hfst-ospell (bionic-proposed/main) [0.4.5~r343-2.1 => 0.4.5~r343-2.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: frog (bionic-proposed/universe) [0.13.7-1 => 0.13.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: harfbuzz (bionic-proposed/main) [1.4.2-1 => 1.4.2-1build1] (core)
<cyphermox> tsimonq2: sorry :)
<cyphermox> tsimonq2: that said, I just pushed lp:ubiquity-slideshow-ubuntu/artful to capture the current state of artful, and created a bionic series (though we'll still work on trunk for now)
-queuebot:#ubuntu-release- Unapproved: hhvm (bionic-proposed/universe) [3.21.0+dfsg-2 => 3.21.0+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kdb (bionic-proposed/universe) [3.0.2-1 => 3.0.2-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ibus-qt (bionic-proposed/universe) [1.3.3-1 => 1.3.3-1build1] (input-methods, kubuntu)
-queuebot:#ubuntu-release- Unapproved: kopanocore (bionic-proposed/universe) [8.1.0-3ubuntu5 => 8.1.0-3ubuntu6] (no packageset)
<cyphermox> and now I'm thinking if we shouldn't move that to git.
-queuebot:#ubuntu-release- Unapproved: libcdr (bionic-proposed/main) [0.1.3-3 => 0.1.3-3build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libe-book (bionic-proposed/main) [0.1.2-4 => 0.1.2-4build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libical (bionic-proposed/main) [2.0.0-0.5 => 2.0.0-0.5build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libphonenumber (bionic-proposed/main) [7.1.0-5ubuntu2 => 7.1.0-5ubuntu3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libcolumbus (bionic-proposed/universe) [1.1.0+15.10.20150806-0ubuntu8 => 1.1.0+15.10.20150806-0ubuntu9] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libmspub (bionic-proposed/main) [0.1.2-4 => 0.1.2-4build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libfolia (bionic-proposed/universe) [1.6-2 => 1.6-2build1] (no packageset)
<tsimonq2> cyphermox: np, thanks :)
<tsimonq2> And yes Git :D
-queuebot:#ubuntu-release- Unapproved: accepted 0ad [source] (bionic-proposed) [0.0.21-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [source] (bionic-proposed) [1.3.7.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted aegisub [source] (bionic-proposed) [3.2.2+dfsg-3build7]
-queuebot:#ubuntu-release- Unapproved: accepted boost1.62 [source] (bionic-proposed) [1.62.0+dfsg-4build4]
-queuebot:#ubuntu-release- Unapproved: accepted 389-adminutil [source] (bionic-proposed) [1.1.23-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted an [source] (bionic-proposed) [1.2-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted 389-dsgw [source] (bionic-proposed) [1.1.11-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted boost1.63 [source] (bionic-proposed) [1.63.0+dfsg-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted brltty [source] (bionic-proposed) [5.4-7ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted cg3 [source] (bionic-proposed) [1.0.0~r12254-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted dee [source] (bionic-proposed) [1.2.7+17.10.20170616-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (bionic-proposed) [3.26.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted frog [source] (bionic-proposed) [0.13.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnustep-gui [source] (bionic-proposed) [0.25.0-4build2]
<powersj> is this stream of messages around the unapproved queue? and do they mean pulling stuff into bionic?
-queuebot:#ubuntu-release- Unapproved: accepted harfbuzz [source] (bionic-proposed) [1.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted hfst-ospell [source] (bionic-proposed) [0.4.5~r343-2.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted calibre [source] (bionic-proposed) [3.7.0+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted dwdiff [source] (bionic-proposed) [2.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnustep-base [source] (bionic-proposed) [1.24.9-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-text-icu [source] (bionic-proposed) [0.7.0.1-6build3]
-queuebot:#ubuntu-release- Unapproved: accepted couchdb [source] (bionic-proposed) [1.6.0-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted grcompiler [source] (bionic-proposed) [4.2-6build2]
-queuebot:#ubuntu-release- Unapproved: accepted firebird3.0 [source] (bionic-proposed) [3.0.2.32703.ds4-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted hhvm [source] (bionic-proposed) [3.21.0+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted kdb [source] (bionic-proposed) [3.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libcdr [source] (bionic-proposed) [0.1.3-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted libe-book [source] (bionic-proposed) [0.1.2-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted libical [source] (bionic-proposed) [2.0.0-0.5build1]
-queuebot:#ubuntu-release- Unapproved: accepted libphonenumber [source] (bionic-proposed) [7.1.0-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: libvisio (bionic-proposed/main) [0.1.5-4 => 0.1.5-4build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ibus-qt [source] (bionic-proposed) [1.3.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libcolumbus [source] (bionic-proposed) [1.1.0+15.10.20150806-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted libmspub [source] (bionic-proposed) [0.1.2-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted kopanocore [source] (bionic-proposed) [8.1.0-3ubuntu6]
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:5.4.1-0ubuntu1 => 1:5.4.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libfolia [source] (bionic-proposed) [1.6-2build1]
-queuebot:#ubuntu-release- Unapproved: libxml2 (bionic-proposed/main) [2.9.4+dfsg1-4ubuntu1 => 2.9.4+dfsg1-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: mapnik (bionic-proposed/universe) [3.0.15+ds-1 => 3.0.15+ds-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mpd (bionic-proposed/universe) [0.20.9-2 => 0.20.9-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-stringprep (bionic-proposed/universe) [0.8.0-3build1 => 0.8.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libzmf (bionic-proposed/universe) [0.0.2-1 => 0.0.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: msort (bionic-proposed/universe) [8.53-2.1 => 8.53-2.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mozjs38 (bionic-proposed/universe) [38.8.0~repack1-0ubuntu1 => 38.8.0~repack1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nodejs (bionic-proposed/universe) [6.11.4~dfsg-1ubuntu1 => 6.11.4~dfsg-1ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: odil (bionic-proposed/universe) [0.8.0-3ubuntu1 => 0.8.0-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.1.10-3 => 2:10.1.10-3build1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openttd (bionic-proposed/universe) [1.7.0-1 => 1.7.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php-pecl-http (bionic-proposed/universe) [3.1.0+2.6.0-4build2 => 3.1.0+2.6.0-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: poedit (bionic-proposed/universe) [2.0.4-1 => 2.0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: prelude-lml (bionic-proposed/universe) [1.0.0-5.3ubuntu4 => 1.0.0-5.3ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php7.1 (bionic-proposed/main) [7.1.8-1ubuntu1 => 7.1.8-1ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pyicu (bionic-proposed/main) [1.9.5-1build2 => 1.9.5-1build3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: postfix (bionic-proposed/main) [3.2.3-1 => 3.2.3-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.1+dfsg-10ubuntu1 => 5.9.1+dfsg-10ubuntu2] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (bionic-proposed/universe) [5.9.1+dfsg-4 => 5.9.1+dfsg-4build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (bionic-proposed/universe) [5.9.1+dfsg-5ubuntu1 => 5.9.1+dfsg-5ubuntu2] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ruby-charlock-holmes (bionic-proposed/universe) [0.7.3+dfsg-2build3 => 0.7.3+dfsg-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: subtitlecomposer (bionic-proposed/universe) [0.6.4-2 => 0.6.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: taglib (bionic-proposed/main) [1.11.1+dfsg.1-0.2 => 1.11.1+dfsg.1-0.2build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: texlive-bin (bionic-proposed/main) [2017.20170613.44572-5build1 => 2017.20170613.44572-5build2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: r-cran-stringi (bionic-proposed/universe) [1.1.2-1build1 => 1.1.2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sword (bionic-proposed/universe) [1.7.3+dfsg-9.1 => 1.7.3+dfsg-9.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tin (bionic-proposed/universe) [1:2.4.1-1 => 1:2.4.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: slop (bionic-proposed/universe) [7.3.49-1 => 7.3.49-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tesseract (bionic-proposed/universe) [3.04.01-6 => 3.04.01-6build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ucto (bionic-proposed/universe) [0.9.6-1 => 0.9.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (bionic-proposed/main) [2.18.0-2 => 2.18.0-2build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xerces-c (bionic-proposed/universe) [3.1.4+debian-2 => 3.1.4+debian-2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: zimlib (bionic-proposed/universe) [2.0.0-2 => 2.0.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zope.ucol (bionic-proposed/universe) [1.0.2-2ubuntu9 => 1.0.2-2ubuntu10] (zope)
-queuebot:#ubuntu-release- Unapproved: unar (bionic-proposed/universe) [1.10.1-2 => 1.10.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: yaz (bionic-proposed/universe) [5.19.2-0ubuntu1 => 5.19.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: webkitgtk (bionic-proposed/universe) [2.4.11-3 => 2.4.11-3build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: znc (bionic-proposed/universe) [1.6.5-2build2 => 1.6.5-2build3] (no packageset)
<tsimonq2> powersj: No, looks like d o k o is no-change rebuilding things
<powersj> tsimonq2: ah ok
-queuebot:#ubuntu-release- Unapproved: accepted odil [source] (bionic-proposed) [0.8.0-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openttd [source] (bionic-proposed) [1.7.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted php7.1 [source] (bionic-proposed) [7.1.8-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (bionic-proposed) [3.2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyicu [source] (bionic-proposed) [1.9.5-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.1.10-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted poedit [source] (bionic-proposed) [2.0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted php-pecl-http [source] (bionic-proposed) [3.1.0+2.6.0-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted prelude-lml [source] (bionic-proposed) [1.0.0-5.3ubuntu5]
<tsimonq2> powersj: (toolchain updates but you likely know that :) )
-queuebot:#ubuntu-release- Unapproved: accepted libvisio [source] (bionic-proposed) [0.1.5-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted libzmf [source] (bionic-proposed) [0.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mozjs38 [source] (bionic-proposed) [38.8.0~repack1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [source] (bionic-proposed) [2.9.4+dfsg1-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mpd [source] (bionic-proposed) [0.20.9-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [source] (bionic-proposed) [3.0.15+ds-1build1]
<powersj> tsimonq2: I actually didn't :) so I appreciate it
-queuebot:#ubuntu-release- Unapproved: accepted msort [source] (bionic-proposed) [8.53-2.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted nodejs [source] (bionic-proposed) [6.11.4~dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [source] (bionic-proposed) [5.9.1+dfsg-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted node-stringprep [source] (bionic-proposed) [0.8.0-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (bionic-proposed) [5.9.1+dfsg-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (bionic-proposed) [5.9.1+dfsg-10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-stringi [source] (bionic-proposed) [1.1.2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted slop [source] (bionic-proposed) [7.3.49-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted sword [source] (bionic-proposed) [1.7.3+dfsg-9.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted tesseract [source] (bionic-proposed) [3.04.01-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted tin [source] (bionic-proposed) [1:2.4.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted unar [source] (bionic-proposed) [1.10.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted webkitgtk [source] (bionic-proposed) [2.4.11-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-charlock-holmes [source] (bionic-proposed) [0.7.3+dfsg-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted taglib [source] (bionic-proposed) [1.11.1+dfsg.1-0.2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ucto [source] (bionic-proposed) [0.9.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted subtitlecomposer [source] (bionic-proposed) [0.6.4-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (bionic-proposed) [2.18.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted texlive-bin [source] (bionic-proposed) [2017.20170613.44572-5build2]
<tsimonq2> powersj: ;)
-queuebot:#ubuntu-release- Unapproved: accepted xerces-c [source] (bionic-proposed) [3.1.4+debian-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted zimlib [source] (bionic-proposed) [2.0.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted zope.ucol [source] (bionic-proposed) [1.0.2-2ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted yaz [source] (bionic-proposed) [5.19.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted znc [source] (bionic-proposed) [1.6.5-2build3]
<tsimonq2> powersj: bionic-changes at lists.u.c is a thing if you're curious why ;)
<tsimonq2> I subscribed to it already
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:5.4.1-0ubuntu2]
<powersj> tsimonq2: ah look at that! that would have answered my question
<tsimonq2> powersj: Yeah it's pretty convenient :D
<LocutusOfBorg> is transition page needing some hint for bionic? http://people.canonical.com/~ubuntu-archive/transitions/html/icu.html still shows everythign as bad
<LocutusOfBorg> Laney, ^^
<LocutusOfBorg> btw let me know if you need something for debhelper+dpkg
<LocutusOfBorg> so far so good
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.4.11-0ubuntu1 => 8.0.5.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (zesty-proposed/main) [0.33ubuntu0.3 => 0.33ubuntu0.4] (core)
<slangasek> bdmurray, balloons: ^^ the revert of distro-info-data, back in the queue and awaiting the juju-core side to land
<balloons> slangasek, ty
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.5 => 0.28ubuntu0.6] (core)
<valorie> slangasek: hope your kiddo is feeling better
<slangasek> valorie: it's nap time ;)
<balloons> slangasek, ahh glorious! rest for kiddo and you
<valorie> :-)
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.4.0~beta3build2 => 1.4.0~beta3ubuntu1] (core)
<gaughen> rbasak, arges  (re-asking on the right channel) With your SRU vanguard hat on (you two are listed as vanguards for today), would one of you please have a look at this https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760 (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=resolvconf) pretty please?
<ubot5> Ubuntu bug 1711760 in resolvconf (Ubuntu Xenial) "[2.3] resolv.conf is not set (during commissioning or testing)" [Medium,Confirmed]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.23-0ubuntu1 => 1.24-0ubuntu1] (ubuntu-desktop)
#ubuntu-release 2017-10-26
-queuebot:#ubuntu-release- Unapproved: rejected dpkg [source] (bionic-proposed) [1.19.0.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dpkg (bionic-proposed/main) [1.18.24ubuntu1 => 1.19.0.4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected debhelper [source] (bionic-proposed) [10.10.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debhelper (bionic-proposed/main) [10.7.2ubuntu2 => 10.10.4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (bionic-proposed) [10.10.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (bionic-proposed) [1.19.0.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: devscripts (bionic-proposed/main) [2.17.9build1 => 2.17.10] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [sync] (bionic-proposed) [2.17.10]
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.91ubuntu1 => 1.0.91ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.91ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.4.0~beta3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: memcached (bionic-proposed/main) [1.4.33-1ubuntu3 => 1.5.0-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: devscripts (bionic-proposed/main) [2.17.10 => 2.17.10ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (bionic-proposed) [2.17.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: conntrack-tools (bionic-proposed/main) [1:1.4.4+snapshot20161117-5ubuntu3 => 1:1.4.4+snapshot20161117-6] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: dh-make-perl (bionic-proposed/universe) [0.95 => 0.96] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: dgit (bionic-proposed/universe) [3.12 => 3.13] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dgit [sync] (bionic-proposed) [3.13]
-queuebot:#ubuntu-release- Unapproved: accepted dh-make-perl [sync] (bionic-proposed) [0.96]
-queuebot:#ubuntu-release- Unapproved: lintian (bionic-proposed/main) [2.5.55 => 2.5.55ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lintian [source] (bionic-proposed) [2.5.55ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-django (bionic-proposed/main) [1:1.11.4-1ubuntu1 => 1:1.11.6-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mousetweaks (bionic-proposed/main) [3.12.0-1ubuntu3 => 3.12.0-2ubuntu1] (ubuntu-desktop)
<doko> Laney, infinity: the transition trackers don't seem to get updated: http://people.canonical.com/~ubuntu-archive/transitions/html/icu.html
<infinity> doko: Fixing.
<infinity> And maybe fixed.
<infinity> Something bad happened while generating ./html/icu.html!
<infinity> That's the most useless error message I've ever seen.
<doko> hmm, and gcc-7 on arm64 was restarted an hour ago :-/
<infinity> doko: Yeah, it timed out in the testsuite.
<infinity> doko: Ugh, the removal of icu-config in the experimental ICU wasn't quite ready for prime-time, looks like.
<doko> infinity: yes, I'm re-adding that
-queuebot:#ubuntu-release- Unapproved: libxml2 (bionic-proposed/main) [2.9.4+dfsg1-4ubuntu2 => 2.9.4+dfsg1-5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [source] (bionic-proposed) [2.9.4+dfsg1-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: icu (bionic-proposed/main) [59.1-3 => 59.1-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted icu [source] (bionic-proposed) [59.1-3ubuntu1]
<infinity> Bah, missed one spot.
<infinity> doko: Okay, I think the tracker will be less broken on the next run.
<infinity> One file isn't in revision control. :/
<infinity> Because of course it isn't.
<doko> infinity: now documented on the opening procedure?
<infinity> No, going to put that file in revision control. :P
<doko> or that
<infinity> (so the existing docs of "fix the transition tracker repo" are correct)
<Laney> we should get that thing updated this cycle...
<infinity> Laney: Be my guest.
<Laney> can we just run it on the host?
<infinity> Probably.  That schroot is used for something else too for some reason.
<infinity> Need to see what that's all about.
<Laney> the trusty-transitions one?
<infinity> Yeah.
<Laney> Erm
<infinity> # Both update-transitions and run-britney need this.
-queuebot:#ubuntu-release- New: accepted boost1.65.1 [source] (bionic-proposed) [1.65.1+dfsg-0ubuntu1]
<infinity>     debcheck = subprocess.Popen(
<infinity>         ['schroot', '-c', 'trusty-transitions', '--',
<infinity>          'dose-debcheck', '--explain', '--failures'] + packages_paths,
<infinity>         stdout=subprocess.PIPE, cwd='/')
<infinity> I imagine that could be installed and run on the host too at this point.
<infinity> Yeah, that's using dose-distcheck from trusty-updates, we could probably update it to use xenial's installed on the host.
<Laney> Aye, that chroot was to go forward in time but now we're past that point
<infinity> Laney: Are the s390x autopkgtest lxc containers for bionic identical to artful's?
<infinity> http://autopkgtest.ubuntu.com/packages/d/debootstrap/bionic/s390x
<Laney> in what way?
<Laney> I used lxc-copy
<infinity> Laney: That's a bit suspect.  Like /dev/pts isn't mounted or something.
<infinity> Laney: Passed consistently in artful, and not enough has changed for me to blame anything but the testbed.
<Laney> 'k, do you want access to have a look?
<infinity> I can try to poke around.  My lxc knowledge is approximately nil.
<infinity> Kinda hoping we get bos02 kvm instances Really Soon and it becomes moot.
<infinity> (And for the case of the debootstrap test, my carefactor is 0, since the debootstrap tests are universally crap on all arches, but it just looks like it could point to a regression that'll pop up elsewhere too)
<infinity> Wow, our pkg-kde-tools delta is huge and disgusting.
-queuebot:#ubuntu-release- Unapproved: busybox (bionic-proposed/main) [1:1.22.0-19ubuntu2 => 1:1.27.2-1ubuntu1] (core)
<infinity> doko: Oh hey, your transition has green things on it now. \o/
-queuebot:#ubuntu-release- Unapproved: pkg-kde-tools (bionic-proposed/universe) [0.15.25ubuntu1 => 0.15.28ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: boost1.65.1 [ppc64el] (bionic-proposed/universe) [1.65.1+dfsg-0ubuntu1] (no packageset)
<doko> infinity: not many, but it's a start ;p
<infinity> doko: It's better than all the red lies it used to have!
<infinity> doko: Also, I'm getting to a point where I don't need the britney block anymore.  If you're happy to let things migrate willy-nilly, I'll remove that.
<doko> infinity: can you remove the auto-block for migrations?
<doko> ahh, ok
<infinity> doko: (And let me know when you're done with the queue freeze)
-queuebot:#ubuntu-release- New binary: boost1.65.1 [amd64] (bionic-proposed/universe) [1.65.1+dfsg-0ubuntu1] (no packageset)
<doko> boost-defaults first when xnox wakes up, or finishes his breakfast
 * infinity nods.
<infinity> There's lots to untangle here with the new packaging toolchain, but none of that needs a freeze, so whenever you're happy with whatever you need to finish before the flood.
<infinity> If only guillem would stop improving dpkg and breaking every little helper utility in the process.
<infinity> (Not actually complaining, 1.19 looks pretty shiny, but ugh, the cascading breakage from people expecting behaviour they shouldn't...)
-queuebot:#ubuntu-release- Unapproved: accepted pkg-kde-tools [source] (bionic-proposed) [0.15.28ubuntu1]
<infinity> Laney: Oh, where's the autopkgtest request.cgi live?
<infinity> Laney: It needs to learn about bionic.
<infinity> "You submitted an invalid request: Unknown release bionic"
<Laney> hmm, sec
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/d/debootstrap/20171005_134535_3a8a7@/log.gz
<Laney> 25/26 failed before but it didn't make the test fail
<infinity> Okay, so 25/26 are a red herring.
<infinity> But something's newly changed still.
 * infinity needs to diff, I guess.
-queuebot:#ubuntu-release- New binary: boost1.65.1 [i386] (bionic-proposed/universe) [1.65.1+dfsg-0ubuntu1] (no packageset)
<Laney> so these FAILED (TODO) things seem to make it fail now wrongly?
<Laney> I'm guessing that's supposed to be a SKIP
<infinity> Oh that diffs really poorly.  autopkgtest needs a log filter like sbuild that replaces random-build-dir-1234 with a static string.
 * infinity does it by hand.
-queuebot:#ubuntu-release- New: accepted boost1.65.1 [amd64] (bionic-proposed) [1.65.1+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.65.1 [ppc64el] (bionic-proposed) [1.65.1+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.65.1 [i386] (bionic-proposed) [1.65.1+dfsg-0ubuntu1]
<infinity> Laney: Okay, it's not 25/26, it's 19/20 that are new.
<Laney> ahh
<infinity> +# mountinfo: 715 861 0:52 /ptmx /dev/ptmx rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
<Laney> okay, try the screen on ubuntu@10.100.0.12
<infinity> And that's new in the bionic container.
<Laney> I tried on artful too
<Laney> and it fails there
<infinity> Well, "in the log".
<Laney> I think lxc got upgraded in the dist-upgrade what I did yesterday
<infinity> Possibly indeed.
<infinity> So, what do I do with this thing?
<infinity> Pretend I know nothing about lxc, and you'll be close.
<Laney> are you at the shell with the failure?
<infinity> But my hunch is that the ptmx change from being a symlink into /dev/pts/ptmx into a bindmounted file to god-knows-where is the confusion here.
<infinity> Oh, connecting to screen would help.
<Laney> two windows in there, a and b
<infinity> lxc (2.0.8-0ubuntu1~16.04.1) xenial; urgency=medium
<infinity>     - conf: use bind-mount for /dev/ptmx
<infinity> I mean, not positive that's the issue, but it's suspicious, given the failure.
 * Laney has almost 0 idea what that is about
<infinity> Laney: How do I re-run the test?
<Laney> When a process opens /dev/ptmx, it gets a file descriptor for a pseudoterminal master (PTM), and a pseudoterminal slave (PTS) device is created in the /dev/pts directory. Each file descriptor obtained by opening /dev/ptmx is an independent PTM with its own associated PTS, whose path can be found by passing the descriptor to ptsname(3).
<Laney> Good... for... you...
<infinity> Or, just literally debian/tests/foo ?
<Laney> infinity: If you quit that shell it should clean up the container, and then you can re-run the previous command
<infinity> If this is a break with all the deps installed.
<Laney> you can do that
<infinity> Yeah, I don't want to clean it up.
<infinity> I want to fiddle.
<Laney> depends if you want to start from clean or not
<infinity> I assume I won't break anything if I just abuse one of these?
<Laney> Probably running the script is good enough
<Laney> nah
<infinity> "Hey Adam, did you redirect that to a log?"  "Sure didn't, cause I'm an idiot."
<infinity> Here's hoping this screen buffer isn't tiny.
<apw> bound to be N-2 of whatever you need it to be
<infinity> apw: There's that cheerful optimism I've been missing in my life.
<apw> what indeed would you do without me :)
<Laney> Lennart got that algorithm just right for the journal
<Laney> Ooh, there's the interesting part
<Laney> RATE LIMITED
<apw> :))
<apw> that string should just be "You didn't want to do it like that"
<infinity> Laney: Erm, I quit and it quit quite convincingly.  How do I recreate that environment?
<Laney> should be the previous command in the buffer
<Laney> otherwise, I just copied it from the top of a failed log
<Laney> and removed --output-dir /blah
<infinity> Without output-dir, it'll dump me to a shell?
-queuebot:#ubuntu-release- New binary: boost1.65.1 [arm64] (bionic-proposed/universe) [1.65.1+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted boost1.65.1 [arm64] (bionic-proposed) [1.65.1+dfsg-0ubuntu1]
<infinity> Hrm no, no it doesn't.
<apw> i think it will run the test, and fail, and you can then connect to it, right ?
<infinity> I hope that question mark isn't for me.
<apw> the ? is for Laney really
<Laney> --shell-fail
<Laney> le fail
<Laney> that's pure muscle memory for me now
 * infinity tries again.
<infinity> Of course, if it is the ptmx thing, stgraber helpfully hardcoded all of this in C, it's not a config option.
<infinity> So, downgrading lxc and filing a bug would be the only option.
<apw> infinity, lovely
 * infinity sideeyes the ptmx node sitting in the root of AUTOPKGTEST_TMP
<infinity> Wat.
-queuebot:#ubuntu-release- Unapproved: gcc-6 (bionic-proposed/main) [6.4.0-8ubuntu1 => 6.4.0-9ubuntu1] (core)
<infinity> Laney: Okay, I'm satisfied that this is debootstrap being braindead in the face of slightly changed lxc behaviour, and not an actual lxc bug.
<infinity> So, badtesting and carrying on with life.
<infinity> Might fix it when I care more, but the debootstrap autopkgtest is relatively new anyway, and fails on almost all arches for different reasons.
<Laney> infinity: Mmkay, probably not so bad as it's testsuite only
<infinity> Laney: Oh, yes, it's the testsuite itself that's written to fail like this, not debootstrap.
<infinity> Laney: The right answer for us is probably to only run the variant of the testsuite that we know will work, depending on which testbed we detect.  I might work that up later and commit to Debian when I feel the urge to be hacky.
<infinity> As it stands, s390x would have started failing for other reasons when we switched to bos02 kvm, I think.
<infinity> So, a bit meh.
-queuebot:#ubuntu-release- Unapproved: boost1.65.1 (bionic-proposed/universe) [1.65.1+dfsg-0ubuntu1 => 1.65.1+dfsg-0ubuntu2] (no packageset)
<xnox> infinity, ftbfs fix for s390x.... out of all the arches.... uploads from me..... lolz ^
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (bionic-proposed) [6.4.0-9ubuntu1]
<infinity> xnox: So coroutine2 no longer depends on context, or never did and that was a lie? :)
<xnox> infinity, things changed, and somehow it now only needs c++11, instead of c++14 and it used to build a library that depends on coroutine1 but doesn't anymore and it's like a header only thing.
<xnox> and coroutine1 is now deprecated
<xnox> and bjam became more strict into validating bogus --without-* flags
<xnox> (build a library, but never install a library)
<infinity> Have I ever mentioned how I feel about boost?
<apw> it is your very favourite thing ever ?
-queuebot:#ubuntu-release- Unapproved: accepted boost1.65.1 [source] (bionic-proposed) [1.65.1+dfsg-0ubuntu2]
<xnox> infinity, let's just say i never go to any hipster smoothie juice bars. I start crying when they try to offer me a boost with my shake.
<infinity> apw: Yeah, that, but the other thing.
<infinity> xnox: I mean, maybe you're avoiding mentions of "boost", but I suspect you're just dodging Evan.
<xnox> libboost-container-dev -> i hope stgraber uses it in something like golang-go-boost-container
-queuebot:#ubuntu-release- Unapproved: mapnik (bionic-proposed/universe) [3.0.15+ds-1build1 => 3.0.15+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [sync] (bionic-proposed) [3.0.15+ds-2]
-queuebot:#ubuntu-release- Unapproved: kbuild (bionic-proposed/universe) [1:0.1.9998svn2814+dfsg-2 => 1:0.1.9998svn3110+dfsg-1] (no packageset) (sync)
<infinity> That x86 autopkgtest queue is fun.
 * infinity wonders if we lost a region again.
<LocutusOfBorg> boost1.65.1 <-- isn't this a funny name?
<LocutusOfBorg> why not boost1.65?
<infinity> The binaries always end up with the full version (I assume due to compat breaks between minor revisions?), so makes sense for the source to match for once.
<LocutusOfBorg> libboost-atomic1.65-dev: No summary available for libboost-atomic1.65-dev in ubuntu bionic.
<LocutusOfBorg> libboost-atomic1.65.1: No summary available for libboost-atomic1.65.1 in ubuntu bionic.
<LocutusOfBorg> so, the source matches the binaries, while the development packages match nothing?
 * infinity shrugs.
<infinity> Also, does it matter?
<infinity> Let the boost maintainer care about the name of his icky source package.
<LocutusOfBorg> I'm worried about reverse-dependencies how much the detection code will break
<LocutusOfBorg> but we will know with this transition I guess :)
<infinity> Uhh, wat?
<infinity> If any package in the archive thinks that mapping binaries to sources based on a guessed pattern is sane, they'd be very wrong.
<infinity> And also, I can't see why anyone would want to do that anyway.
<LocutusOfBorg> "dpkg -s boost-foo | grep -o installed"
<LocutusOfBorg> because some features are available only on some architectures
<LocutusOfBorg> people might do that in rules files to detect and pass configuration flags accordingly
<infinity> That didn't really address my point.
<LocutusOfBorg> yep I know
<infinity> Why would anyone try to guess the source package *name* based on binary packages installed?
<LocutusOfBorg> nobody I hope
 * LocutusOfBorg shrugs
<LocutusOfBorg> I started the question after a look at the source name, but the binaries situation is probably worth a look
 * LocutusOfBorg upgrades zesty to artful, goodbye
<infinity> You're a release behind.
<LocutusOfBorg> yep :P
<LocutusOfBorg> my work is not $ubuntu, so I can't break my pc :)
<LocutusOfBorg> and I pay for my connection, so less updates, less useless traffic
<LocutusOfBorg> good luck with the archive opening
-queuebot:#ubuntu-release- Unapproved: golang-1.9 (bionic-proposed/universe) [1.9.1-2ubuntu1 => 1.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyicu (bionic-proposed/main) [1.9.5-1build3 => 1.9.7-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (bionic-proposed) [1:1.27.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kbuild [sync] (bionic-proposed) [1:0.1.9998svn3110+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.9 [source] (bionic-proposed) [1.9.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pyicu [source] (bionic-proposed) [1.9.7-0ubuntu1]
<ginggs> do we have arm64 autopkgtesters now?
<infinity> ginggs: We will once they're done grinding through backlog to produce a baseline.
<ginggs> infinity: yay, thanks
<LocutusOfBorg> nice!
-queuebot:#ubuntu-release- Unapproved: luajit (bionic-proposed/universe) [2.0.4+dfsg-1 => 2.1.0~beta3+dfsg-5] (no packageset) (sync)
<xnox> infinity, "If any package in the archive thinks that mapping binaries to sources based on a guessed pattern is sane, they'd be very wrong." hahahahahahah have you seen ax_boost.m4, cmake, et.al? when i started boost packaging I was like "dear upstream, how about you ship pkg-config files" it only took them a few years to ship those......
<xnox> infinity, cause they were like "everybody on windows & mac, just embeds all of boost, even if they just use one header only thing"
<xnox> LocutusOfBorg, the name is correct
<xnox> but we simply did not package/ship 1.65.0 series
-queuebot:#ubuntu-release- Unapproved: boost-defaults (bionic-proposed/main) [1.62.0.1 => 1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
<infinity> xnox: I assume accepting defaults before boost itself is built and published wouldn't be smart.
<xnox> infinity, no, that would not be smart. but it's mostly ok, as it was built and published on amd64 already.
<infinity> I'll wait.
<juliank> JFTR: apt's autopkgtests fail as they are not compatible with dpkg 1.19 - 1.6~alpha{1,2} are, but the new seccomp sandboxing has problems with fakeroot on ppc64el (and mips on Debian; missing ipc syscall). It should go back to normal later today with 1.6~alpha3, though.
<infinity> juliank: Could just do a 1.5+fixes for the dpkg compat?
<infinity> Although, hilariously, dpkg doesn't trigger apt tests.
<infinity> Might want to fix that.
<juliank> Indeed, it just needs that commit: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=404dececf913d3c09368a73ca00aa8172dbf6865
<infinity> juliank: To be clear, it's only the tests that fail with the new dpkg, no actual runtime compat issues?
<juliank> infinity: lol
<juliank> infinity: yeah
<infinity> juliank: Good job on the pointless whitespace changes in that commit.
<juliank> infinity: git-clang-format auto formats changed hunks these days so we get consistent coding style eventually :)
<infinity> Gross.
<infinity> I can't stand people comitting whitespace and code fixes in the same commit on projects I work on. :/
<juliank> Sometimes I override it
<juliank> But it's mostly stuff like comment moves or f(a,b,c) becoming f(a, b, c) I don't mind that
<infinity> juliank: Oh, I don't mind the fixes, I just hate them landing with code.  It makes cherrypicks more painful, diffs longer to review, etc.
<juliank> Well, the point with it only changing changed parts is that it makes cherry-picking not really more complicated, because the code changed anyway.
<juliank> But in general that's right. It just makes it much easier to write new code if you don't have to worry about formatting
<infinity> juliank: But that's not true in this commit. :)
<infinity> juliank: It moved comments around, and added trailing commas to end members.  None of those had code changes.
<juliank> infinity: Yeah, I wonder how the first hunk happened. The trailing commas - I added those manually, otherwise it would move the closing brace directly after the 0...
<infinity> Unless you mean "only touches files we touched", or "code hunks we touched", but that sort of makes cherrypicks harder, not easier.
<infinity> juliank: Anyhow, your project, your commit rules.  I'll just hate it irrationally from a distance. :)
<infinity> juliank: But yes, a cherrypick of the dpkg compat stuff would be nice.  Makes more sense than shoving in a 1.6 alpha you're not sure of yet.
 * juliank has an entirely different coding style than apt, so it's really a lot of help :)
<infinity> juliank: If the dpkg compat stuff is backward-compatible, jam it in an artful SRU and copy forward? :)
<juliank> That sounds ugly.
<infinity> Well, not ugly if you intend to maintain a 1.5 branch.
<infinity> Since versioning gets wonky if you also do 1.5 stuff in bionic.
<infinity> I guess you could do 1.5.91 for the 1.5+bionic_fixes stuff, with the assumption that you'll move to 1.6 in a week or three.
<juliank> I think we had wonky versioning every single release :D
<infinity> Fair enough.
<juliank> But yeah, I can issue a 1.5.1 for artful with 2 updated translations + the dpkg 1.19 test suite compat fixes
<juliank> + change to dockerfile to build in artful :D
<juliank> (on CI)
-queuebot:#ubuntu-release- Unapproved: vim (bionic-proposed/main) [2:8.0.0197-4ubuntu5 => 2:8.0.1144-1ubuntu1] (core)
<juliank> (by default CI runs on Debian testing)
-queuebot:#ubuntu-release- Unapproved: accepted vim [source] (bionic-proposed) [2:8.0.1144-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcdio (bionic-proposed/main) [0.83-4.3 => 0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
<juliank> infinity: Should be picking the fix for ignoring (well, warning) about invalid keyring files as well, so people don't get obscure no key found errors anymore: https://github.com/Debian/apt/commit/f29f7ce33d6570fca5a6d0160cac215da184de89
<infinity> juliank: FWIW, if you add "dpkg" to your test depends (despite it being Essential, so obviously not necessary as a dep), then autopkgtest will map that backwards and trigger apt tests when dpkg changes.
-queuebot:#ubuntu-release- Unapproved: accepted libcdio [source] (bionic-proposed) [0.94-0ubuntu1]
<juliank> that makes sense
<slashd> sil2100, good day, last week I have uploaded lshw for artful and zesty (before 'Bb' has a name as we discussed A will be copied to 'Bb') now that bionic exist, it's too late and I'll have to get the patch sponsored in Bionic first ? as usual or you can approve the upload anyway ?
<infinity> juliank: Seems like that's a relationship we probably want. :)
-queuebot:#ubuntu-release- Unapproved: accepted boost-defaults [source] (bionic-proposed) [1.65.1.0ubuntu1]
<infinity> doko: I was waiting for boost to finish building on arm* before accepting that.
<infinity> But I guess as long as nothing that build-deps on boost is accepted, meh.
<juliank> infinity: added a test dep in master
<infinity> juliank: \o/
-queuebot:#ubuntu-release- New binary: boost-defaults [ppc64el] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
<doko> infinity: it was already built, wasn't it?
-queuebot:#ubuntu-release- New binary: libcdio [ppc64el] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [i386] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [s390x] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
<doko> it's in NEW anyway
-queuebot:#ubuntu-release- New binary: boost-defaults [amd64] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: boost-defaults [i386] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [amd64] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
<slashd> sil2100, anyway the versionning doesn't make sense anymore since that 'Bb' lshw exist and == A version. I'll have to modify Z and A version. Can you reject the upload and I'll do it again including 'Bb' maybe the upload was to premature (re : lshw upload)
-queuebot:#ubuntu-release- New binary: libcdio [armhf] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
<infinity> doko: Nope.  armhf never made it to the archive before the new version was uploaded.
-queuebot:#ubuntu-release- New binary: boost-defaults [arm64] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [arm64] (bionic-proposed/main) [0.94-0ubuntu1] (kubuntu, ubuntu-desktop)
<infinity> doko: But being stuck in NEW indeed solves the concern. :)
<sil2100> slashd: what I guess we can still do is review the Aa one, approve and then forward binary-copy to B
<infinity> ^
<slashd> sil2100, ok if you can still do that, that would be great
<slashd> sil2100, I'm also fine re-doing it if needed, really up to you guys.
<sil2100> slashd: leave it as is, I'll check up on the SRU stuff in a moment - if I manage to review/approve it as is I'll then just do the forward copy
<sil2100> (since Bb is still closed for regular uploads)
<slashd> sil2100, ack thanks for looking at it
-queuebot:#ubuntu-release- New: accepted libcdio [amd64] (bionic-proposed) [0.94-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio [armhf] (bionic-proposed) [0.94-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio [ppc64el] (bionic-proposed) [0.94-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio [arm64] (bionic-proposed) [0.94-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio [s390x] (bionic-proposed) [0.94-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio [i386] (bionic-proposed) [0.94-0ubuntu1]
<juliank> infinity: So I just upload https://github.com/Debian/apt/compare/1.5.y...julian-klode:1.5.y?expand=1 / https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1727694 to artful, and someone accepts and copies it to bionic?
<ubot5> Ubuntu bug 1727694 in apt (Ubuntu) "[SRU] apt/artful 1.5.1 microrelease" [Undecided,New]
<juliank> never done it this way before :)
<infinity> juliank: Yup.  Bonus points if you cherry-pick that top master commit to all your stable branches too.
<juliank> Oh, yeah, that makes sense
<infinity> Not that I anticipate dpkg SRUs breaking apt, but I'd also like that to be tested.
<juliank> +1
-queuebot:#ubuntu-release- Unapproved: accepted memcached [source] (bionic-proposed) [1.5.0-1ubuntu1]
<infinity> juliank: And to be 100% paranoid before you upload, I'll ask again (cause I think it got lost in the noise of me whining about whitespace), the dpkg compat fixes are definitely 100% backward compatible, right?  This won't accidentally break apt with dpkg 1.18 while fixing it with 1.19? :)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.24-0ubuntu1]
<juliank> infinity: Well, CI would catch this
<infinity> That sounds like a firm "maybe".
<juliank> infinity: travis for 1.5.y runs on artful; and shippable for 1.4.y, 1.5.y, and master runs on stretch.
<juliank> And no, I'm sure that it won't break.
<infinity> ;)
<infinity> juliank: So yeah, roll it up, put it through whatever local/remote testing you do, and gimme.  A small delta like that should be both easy to review and easy to verify as an SRU.
<juliank> infinity: I added that now, build & tagged it locally, and am waiting for CI to (hopefully) succeed :)
<infinity> juliank: (And, of course, once it's built in artful-proposed, I'll copy it forward to bionic, doesn't need to wait on SRU verification for that)
<juliank> yeah
<juliank> I mean, there's nothing to verify really, all changes are tested by autopkgtests :D
<juliank> (and tiny)
<infinity> juliank: Just watch as the unnecessary whitespace changes trigger a compiler bug.
<infinity> juliank: (And be grateful that you're young enough to believe that's a joke rather than the horrible reality we all lived in 20 years ago)
<juliank> infinity: I guess I could have picked https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=7ea3c67f96e3bc82f86afe72d6c61308c92de515 too, but there's always a later time
<juliank> I do wonder why people have empty build dependency fields
<infinity> juliank: People sprinkle empty crap all over debian/control because dpkg-gencontrol filters it out for them.
<doko> Laney: I see you had some couchdb uploads. do you care about it?
<juliank> Gah, now I received two reports that the store method (which recompresses files) needs socket(2), and that the http method needs sysinfo(2).
<juliank> seccomp sandboxing sucks
<infinity> juliank: Certainly worth fixing, but not a regression either, since I assume it only affect the "new" debian/control build-dep fetching feature.
<infinity> Which isn't that new anymore, but whatever.  I assume it's always been "broken".
<juliank> yeah
<infinity> juliank: When you got that bug, did you also check that other invalid-but-valid control syntax works?
<juliank> I don't think so, but David did it, so I don't know what he checked
<infinity> juliank: The obvious one that comes to mind is "Field: thing, , , thing," cause dpkg-gencontrol collapses out the empty values.
<infinity> juliank: I'd almost suggest that if you're going to parse debian/control directly, you just call out to libdpkg-perl, so you don't have to duplicate the sanitizer logic.
<juliank> heh
<infinity> debian/control is, ironically, not meant to be a valid control file, pretty much by design.
<juliank> But yes, ,, does not work
-queuebot:#ubuntu-release- Unapproved: mapnik (bionic-proposed/universe) [3.0.15+ds-2 => 3.0.15+ds-2ubuntu1] (no packageset)
<juliank> dpkg does far too much sanitizing IMO
<juliank> not only here, but also when installing packages with invalid names or versions
<cjwatson> The ,, stuff is very handy for empty substvars
<juliank> dpkg modifies names to be lowercase, for example - apt has to duplicate that all
<juliank> cjwatson: That makes sense, but we only parse build-deps :D
<infinity> Well, it has to sanitize stuff like that so you can do things like "Foo: bar, baz, ${substvar}, quux" and have substvar empty.  Though, build-depends can't have substvars in them, as they're parsed directly, so one could make an argument that packages with invalid Build-depends syntax are just buggy.
<infinity> cjwatson: Jinx.
<cjwatson> juliank: fair
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [source] (bionic-proposed) [3.0.15+ds-2ubuntu1]
<xnox> infinity, is it me, or the xenial tests are now qued after bionic because alphabet
<xnox> in autopkgtest.ubuntu.com
<xnox> i thought before xenial was drained before zesty was.
-queuebot:#ubuntu-release- Unapproved: audacious-plugins (bionic-proposed/universe) [3.9-1 => 3.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: audiotools (bionic-proposed/universe) [3.1.1-1build3 => 3.1.1-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: clementine (bionic-proposed/universe) [1.3.1+git276-g3485bbe43+dfsg-1 => 1.3.1+git276-g3485bbe43+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: daisy-player (bionic-proposed/universe) [10.6.4.2-1 => 10.6.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gmerlin-avdecoder (bionic-proposed/universe) [1.2.0~dfsg-9 => 1.2.0~dfsg-9build1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (bionic-proposed/universe) [1.12.3-1 => 1.12.3-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cdw (bionic-proposed/universe) [0.8.1-1 => 0.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-iso9660 (bionic-proposed/universe) [0.3-1.1 => 0.3-1.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.34.1-1ubuntu1 => 1.34.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cmus (bionic-proposed/universe) [2.7.1+git20160225-1build1 => 2.7.1+git20160225-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gmerlin (bionic-proposed/universe) [1.2.0~dfsg+1-6 => 1.2.0~dfsg+1-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kodi (bionic-proposed/universe) [2:17.3+dfsg1-3 => 2:17.3+dfsg1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libdevice-cdio-perl (bionic-proposed/universe) [0.3.0-6build1 => 0.3.0-6build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mpv (bionic-proposed/universe) [0.26.0-3ubuntu1 => 0.26.0-3ubuntu2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ripoff (bionic-proposed/universe) [0.8.3-0ubuntu7 => 0.8.3-0ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vcdimager (bionic-proposed/universe) [0.7.24+dfsg-0.2 => 0.7.24+dfsg-0.2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: xine-lib-1.2 (bionic-proposed/universe) [1.2.6-1.3build2 => 1.2.6-1.3build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kover (bionic-proposed/universe) [1:4-11 => 1:4-11build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qmmp (bionic-proposed/universe) [1.1.6-1.1ubuntu1 => 1.1.6-1.1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [2.2.6-6 => 2.2.6-6build1] (kubuntu, mozilla)
-queuebot:#ubuntu-release- Unapproved: mplayer (bionic-proposed/universe) [2:1.3.0-6build3 => 2:1.3.0-6build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: xmms2 (bionic-proposed/universe) [0.8+dfsg-18build1 => 0.8+dfsg-18build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: simpleburn (bionic-proposed/universe) [1.8.0-1 => 1.8.0-1build1] (no packageset)
<infinity> xnox: I dunno.  I see no xenial tests queued.
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (bionic-proposed) [1.34.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kover [source] (bionic-proposed) [1:4-11build1]
-queuebot:#ubuntu-release- Unapproved: accepted mplayer [source] (bionic-proposed) [2:1.3.0-6build4]
<infinity> xnox: But I have no idea what order the queues drain in, ask Laney.
-queuebot:#ubuntu-release- Unapproved: accepted qmmp [source] (bionic-proposed) [1.1.6-1.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted simpleburn [source] (bionic-proposed) [1.8.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (bionic-proposed) [2.2.6-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted kodi [source] (bionic-proposed) [2:17.3+dfsg1-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted mpv [source] (bionic-proposed) [0.26.0-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vcdimager [source] (bionic-proposed) [0.7.24+dfsg-0.2build1]
-queuebot:#ubuntu-release- Unapproved: accepted libdevice-cdio-perl [source] (bionic-proposed) [0.3.0-6build2]
-queuebot:#ubuntu-release- Unapproved: accepted ripoff [source] (bionic-proposed) [0.8.3-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted audacious-plugins [source] (bionic-proposed) [3.9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted cdw [source] (bionic-proposed) [0.8.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted cmus [source] (bionic-proposed) [2.7.1+git20160225-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-iso9660 [source] (bionic-proposed) [0.3-1.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gmerlin [source] (bionic-proposed) [1.2.0~dfsg+1-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted xine-lib-1.2 [source] (bionic-proposed) [1.2.6-1.3build3]
-queuebot:#ubuntu-release- Unapproved: accepted audiotools [source] (bionic-proposed) [3.1.1-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted daisy-player [source] (bionic-proposed) [10.6.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [source] (bionic-proposed) [1.12.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted clementine [source] (bionic-proposed) [1.3.1+git276-g3485bbe43+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xmms2 [source] (bionic-proposed) [0.8+dfsg-18build2]
-queuebot:#ubuntu-release- Unapproved: accepted gmerlin-avdecoder [source] (bionic-proposed) [1.2.0~dfsg-9build1]
<juliank> infinity: 1 out of 3 runs passed :/ - temporary failure in one, and lots of profiling noise in the other. I wonder if artful has a particularly chatty gcov.
<juliank> neither of which should affect autopkgtests, though
<xnox> only 27 packages in main have boost depends.
<xnox> well 20, excluding boost itself.
<xnox> 5 ceph, 5 mir and a couple more
<xnox> i wonder how doable is to get rid of boost from main.
-queuebot:#ubuntu-release- New binary: boost-defaults [s390x] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
<slashd> sil2100, I almost forgot, additionnaly, could you please look at releasing openvswitch (LP: #1723480) for Zesty & Xenial ?
<ubot5> Launchpad bug 1723480 in Ubuntu Cloud Archive newton "openvswitch-switch package postinst modifies existing configuration" [High,Triaged] https://launchpad.net/bugs/1723480
-queuebot:#ubuntu-release- New binary: boost-defaults [armhf] (bionic-proposed/main) [1.65.1.0ubuntu1] (kubuntu, ubuntu-desktop)
<xnox> infinity, all of boost-defaults are now done \o/ =)
<xnox> just need new processig and transition all the things
-queuebot:#ubuntu-release- Unapproved: libcdio (bionic-proposed/main) [0.94-0ubuntu1 => 0.94-0.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted boost-defaults [amd64] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost-defaults [armhf] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost-defaults [ppc64el] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost-defaults [arm64] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost-defaults [s390x] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost-defaults [i386] (bionic-proposed) [1.65.1.0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libcdio [source] (bionic-proposed) [0.94-0.2]
-queuebot:#ubuntu-release- Unapproved: accepted conntrack-tools [sync] (bionic-proposed) [1:1.4.4+snapshot20161117-6]
-queuebot:#ubuntu-release- Unapproved: accepted luajit [sync] (bionic-proposed) [2.1.0~beta3+dfsg-5]
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (bionic-proposed) [1:1.11.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.26.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mousetweaks [source] (bionic-proposed) [3.12.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apt (artful-proposed/main) [1.5 => 1.5.1] (core)
<juliank> infinity: ^
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (artful-proposed) [1.5.1]
<Laney> doko: when were they?
<Laney> it was a thing for some project years ago
<Laney> so... no
<Laney> xnox: in theory they're randomised, but I don't know if that works
<infinity> juliank: What ancient release do you build your source packages on?
-queuebot:#ubuntu-release- Unapproved: debootstrap (zesty-proposed/main) [1.0.81ubuntu3.2 => 1.0.81ubuntu3.3] (core)
<infinity> juliank: (FWIW, that "add dpkg to debian/tests/control" trick only works if your source is built with dpkg-dev >= 1.18.8)
<xnox> Laney, eventually it will get there....
-queuebot:#ubuntu-release- Unapproved: rejected debootstrap [source] (zesty-proposed) [1.0.81ubuntu3.3]
<juliank> infinity: why?!
<Laney> sure will
<infinity> juliank: Because dpkg 1.18.8 parses/expands debian/tests/control:Depends and turns it into Testsuite-Triggers in your .dsc
<juliank> ah
<infinity> juliank: Which is what debci looks for to do the reverse mapping.
<juliank> grr
<infinity> juliank: No big deal.  I only noticed after I accepted. :P
<infinity> juliank: It'll self resolve some day when you run a current dpkg.
<juliank> I need to build more current chroots with gbp-buildpackage in them.
<juliank> Currently, I do the source tarballs on xenial
<infinity> juliank: I know some people swear by building their source in sbuild in the target release for their uploads.  I think that's a level of bizarre paranoia I can't get on board with.  I just always run the latest.
<infinity> juliank: But my job sort of makes "run the latest" sound saner than it does for most people.
<infinity> (ie: I 'upgraded' to bionic literally before anyone else)
<infinity> apw: Are you rejecting your own debootstraps?
<apw> infinity, i rejected that one because i forgot the bug in it ... so yes
<apw> infinity, will be back in a sec
<infinity> Ahh.
<juliank> infinity: Well, my host is debian, the ubuntu's live in tons of chroots and VM / dual boot (one partition, two uses :D). I should just build a devel chroot, though, and keep that up-to-date, would save resources.
<juliank> I do need the xenial for 1.2.y, though, otherwise you get insanely weird po file diffs I think
<infinity> juliank: Or stop running oldstable?
<infinity> juliank: Debian stable has a much shinier dpkg.
<xnox> bdmurray, sil2100 - could you please publish systemd from zesty?
<juliank> infinity: I run unstable, but Debian dpkg does not generate Launchpad-Bugs-Fixed in changes
<infinity> juliank: Oh, ISWYM.  You probably do run stable, but built the source in a xenial chroot for... Yeah.
<xnox> all the adt regressions have been retried and passed and/or hinted over correctly in the ~ubuntu-sru branch
<juliank> I think unstable is a slightly smoother ride than devel, but I never tried running devel really :D
<xnox> juliank, i always build source packages outside the chroot, if the outside is newer.
<infinity> xnox: Yes, but see above, you can't build Ubuntu sources on Debian if you want LP bug closures.
<juliank> I'd have to be able to override the dpkg vendor
<xnox> infinity, you can with DEB_VENDOR=Ubuntu i thought
<juliank> for that command
 * xnox should check that
<juliank> let me try!
-queuebot:#ubuntu-release- Unapproved: debootstrap (artful-proposed/main) [1.0.91ubuntu1 => 1.0.91ubuntu1.1] (core)
<infinity> Oh, maybe?
<infinity> Except Debian dpkg doesn't ship the ubuntu vendor file, so not sure how that works in practice.
<infinity> juliank: I wouldn't agree with unstable being smoother than Ubuntu devel.  My experience is the opposite.
<infinity> juliank: testing is smoother than devel, but also much, much slower.
<infinity> juliank: unstable is the wild west.
<xnox> juliank, unstable does not gate adt regressions
<infinity> unstable doesn't gate anything.
<juliank> Yeah, I think the autopkgtests really improved day-to-day devel use
<infinity> By design.
<infinity> testing at least gates on installability.
<xnox> making ubuntu source packages buildable on debian would be nice.
<infinity> But yes, I'll be much happier when it also gates on tests.
-queuebot:#ubuntu-release- Unapproved: debootstrap (zesty-proposed/main) [1.0.81ubuntu3.2 => 1.0.81ubuntu3.3] (core)
<doko> xnox: boost1.65 promoted
<xnox> cause how does it work then? when debian changelogs mention LP: # numbers, they do get closed on sync and migrate =/
<juliank> xnox: On sync, a new changes is generated, basically
<xnox> ah
<infinity> Yeah, syncs don't sync the .changes file, we create one on the fly.
<infinity> (There's no where to sync it from, without grubbing around the DONE queue on ftpmaster)
<sil2100> xnox: I'll be starting my SRU shift in a moment
<cjwatson> Copies don't even use a .changes
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.4 => 1.0.78+nmu1ubuntu1.5] (core)
<infinity> cjwatson: Well, yes, it was more "in spirit".
<xnox> infinity, hm.... so changes can be signed by a different key from .dsd?
<xnox> infinity, hm.... so changes can be signed by a different key from .dsc?
<infinity> xnox: Of course, I do so all the time.
<infinity> xnox: Which is how I do manual syncs.
<infinity> xnox: Grab debian source, genchanges, change target Dist, sign.
<infinity> (And keep the DDs sign on the .dsc)
<infinity> s/sign/sig/
<xnox> infinity, does dak enforce for .dsc to have a DD signature?
<juliank> infinity: I patched syncpackage to keep the dsc signature with a --no-lp
<xnox> or only .changes needs a DD signature?
<juliank> infinity: locally, that is. Should send a patch eventually.
<infinity> xnox: Historically, only .changes.  No idea if that policy has changed.
<cjwatson> In the copy case, basically, LP works out the aggregate changelog since the previous version and scans it for bug closures all by itself.
<infinity> cjwatson: We could reuse that code path for regular uploads, and get rid of Launchpad-Bugs-Fixed entirely.
 * juliank uses the patched syncpackage --no-lp for zesty's 1.4.y syncing
<cjwatson> infinity,xnox: Currently both.  I thought it was always that way, but not digging back through history to check.
<cjwatson> (dak)
<apw> cjwatson, does it do that only when there isn't a .changes?
<cjwatson> apw: yes
<infinity> If it was figured out in the queue and exposed as a property of the queue item, the SRU tools could pick up the list there.
<apw> infinity, oh you want the world :)
<cjwatson> infinity: It's not as much reuse as you think it would be.
<cjwatson> infinity: Reaggregating the changelog is a lot easier when the SPRs already exist somewhere.
<infinity> cjwatson: I'm almost sure it didn't always enforce .dsc sigs being in the keyring.  I even have some fuzzy memory of unsigned .dsc being allowed.  But maybe that was pre-katie.
<apw> given the changes has the sum of the .dsc it is not clear why you need both signed
<infinity> apw: Because .changes is thrown away, and you're taking the archive owner's word about chain of custody.
<apw> ahh point
<infinity> apw: In the Ubuntu case, we've decided that's fine (and it's really the only sane thing we can do, given we import half our sources from a third party).
<infinity> apw: In the debian case, being able to dget a .dsc and verify it's signed by a DD is somewhat comforting.
<infinity> Well, comforting or horrifying, depending on exactly who signed it.
<infinity> But at least you know.
-queuebot:#ubuntu-release- Unapproved: debootstrap (trusty-proposed/main) [1.0.59ubuntu0.8 => 1.0.59ubuntu0.9] (core)
<cjwatson> note that .changes has to be either thrown away or at least have its signature stripped, because it's an upload instruction and so replayable etc.
<apw> cjwatson, hmmm a good point indeed
<sil2100> xnox: ok, looking at the systemd for zesty now
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.5 => 1.5.1] (core) (sync)
<infinity> doko: *poke*
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (bionic-proposed) [1.5.1]
<infinity> doko: I'm about to handle the boost component mismatches, unless you already have (don't want to hit the double override bug).
<infinity> doko: Oh, hah, and it looks like you did already indeed. :)
 * infinity keeps his hands off.
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20171019+dfsg1-0ubuntu1~17.04.0]
<infinity> juliank: https://launchpad.net/ubuntu/+source/apt/1.5.1/+publishinghistory
<infinity> juliank: There you go.
<juliank> infinity: thx
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20171019+dfsg1-0ubuntu1~16.04.0]
<infinity> juliank: Speaking of apt SRUs, you seem to have a few in flight that are all very unverified.
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20171019+dfsg1-0ubuntu1~14.04.0]
<juliank> infinity: Um, yeah, I have not gotten around to verifying yet. Really should do that.
<juliank> infinity: I hoped that some of the reporters would do it, but they don't seem to be particularly interested in verifying.
<infinity> juliank: It's my experience that sru-verifying reporters come in three flavours: People who are SO EXCITED THAT THEY TEST SECONDS AFTER THE BINARY IS PUBLISHED, people who need to be nudged repeatedly over the course of a month before they grudgingly take part in your "stupid process", and people who just disappear off the earth second after they report their bug.
<infinity> juliank: If you don't have the first type, you may as well just do it yourself.
<infinity> s/second/seconds/
<juliank> Yeah, I'm like supposed to have my msc thesis code done in a week or so, so I have not spend that much daytime on apt as I'd normally have. and it's nothing interesting that lets me stay up all night :)
<infinity> juliank: Well, no pressure either.  They can sit longer.  Was just something I noticed in passing. :P
<infinity> (And if someone is itching for the updates, they can verify your uploads)
<sil2100> xnox: looking at the bugs verification for the systemd for zesty
<sil2100> xnox: so in LP: #1709135 people noticed a regression with the noarp being now set, they filled in that second bug for that - is it only for xenial, or will this also appear in the zesty upload?
<ubot5> Launchpad bug 1709135 in nplan (Ubuntu Zesty) "add bond primary parameter" [High,Fix committed] https://launchpad.net/bugs/1709135
<jbicha> the first time is rare and always surprises me when I see them :(
<infinity> jbicha: I get the first type when the upload is a direct result of a real-time "oh, let me fix that right now" conversation.  Becomes more rare the more async the communication is, I think.
<xnox> sil2100, zesty is not affected. as networkd in zesty has a fixed ARP support.
<xnox> sil2100, cherrypicks into xenial were in complete.
<sil2100> xnox: ACK, that's what I wanted to confirm
<sil2100> Thanks
<sil2100> xnox: done
-queuebot:#ubuntu-release- New source: libcdio-paranoia (bionic-proposed/primary) [10.2+0.94+2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [source] (bionic-proposed) [10.2+0.94+2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcdio-paranoia (bionic-proposed/none) [none => 10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libcdio-paranoia [source] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [amd64] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [ppc64el] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [i386] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [s390x] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [armhf] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [arm64] (bionic-proposed/none) [10.2+0.94+2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [amd64] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [armhf] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [ppc64el] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [arm64] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [s390x] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [i386] (bionic-proposed) [10.2+0.94+2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: busybox (bionic-proposed/main) [1:1.27.2-1ubuntu1 => 1:1.27.2-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (bionic-proposed) [1:1.27.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.4~17.04.1 => 0.12.6~17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (xenial-proposed/main) [0.9.2 => 0.12.6~16.04.1] (no packageset)
<slangasek> Laney: 22 of 56 x86 autopkgtest runners are currently offline, across both cloud regions.  I have yet to understand why this happens, the logs are not informative; I know there's a cron to restart them but it may only run daily.  Do you understand what that's about and can you explain it to me to where I can understand if there's something there we should be fixing?
<Laney> slangasek: It runs 6 hourly; check the journal output for the units in question
<Laney> The first few I tried are back-offs because we hit the quota
<slangasek> Laney: I have looked at journal output before and not been able to make heads or tails
<Laney> not sure about autopkgtest@lgw01-5.service
<Laney> e.g. autopkgtest@lcy01-1.service says "novaclient.exceptions.OverLimit: Quota exceeded for cores,ram: Requested 4, but already used 27 of 30 cores (HTTP 413) (Request-ID: req-47bcd4c0-bfc8-4be7-9e0c-8046835d7aec)"
<Laney> and then it goes away until the maintenance script runs at */6
<slangasek> ah
<Laney> it can happen if you have m1.large instances
<infinity> AKA Your Mom instances?
<Laney> i.e. big_packages or whatever it's called
<Laney> your mom's so big she exceeded our lcy01 quota
<Laney> sick burn
<juliank> infinity: sbuild on artful fails with E: No such script: /usr/share/debootstrap/scripts/bionic
<juliank> INFO: Creating sbuild chroot 'bionic-ppc64el-sbuild' for release 'bionic' in directory '/tmp/autopkgtest.mGtTXc/autopkgtest_tmp/schroot-bionic' from url 'http://ports.ubuntu.com/ubuntu-ports'
<xnox> juliank, add a symlink?
<juliank> Why does it test that in autopkgtests?
<juliank> seems weird
<infinity> juliank: It'll self-solve shortly.
<juliank> OK
<juliank> the rest is looking good :)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (artful-proposed) [1.0.91ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: kover (bionic-proposed/universe) [1:4-11build1 => 1:4-11ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gmerlin (bionic-proposed/universe) [1.2.0~dfsg+1-6build1 => 1.2.0~dfsg+1-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: daisy-player (bionic-proposed/universe) [10.6.4.2-1build1 => 11.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted daisy-player [sync] (bionic-proposed) [11.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted kover [source] (bionic-proposed) [1:4-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gmerlin [source] (bionic-proposed) [1.2.0~dfsg+1-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: daisy-player (bionic-proposed/universe) [10.6.4.2-1build1 => 11.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted daisy-player [source] (bionic-proposed) [11.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bcmwl (xenial-proposed/restricted) [6.30.223.271+bdcom-0ubuntu1~1.1 => 6.30.223.271+bdcom-0ubuntu1~1.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: haskell-pandoc-citeproc (bionic-proposed/universe) [0.10.4.1-2build3 => 0.10.4.1-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-stringprep (bionic-proposed/universe) [1.0.0-7build2 => 1.0.0-7build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-yi-rope (bionic-proposed/universe) [0.8-1 => 0.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-pandoc-citeproc [source] (bionic-proposed) [0.10.4.1-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-yi-rope [source] (bionic-proposed) [0.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-stringprep [source] (bionic-proposed) [1.0.0-7build3]
-queuebot:#ubuntu-release- Unapproved: autodock-vina (bionic-proposed/universe) [1.1.2-3build5 => 1.1.2-3build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: choreonoid (bionic-proposed/universe) [1.5.0+dfsg-0.1build2 => 1.5.0+dfsg-0.1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: flightcrew (bionic-proposed/universe) [0.7.2+dfsg-9 => 0.7.2+dfsg-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: btfs (bionic-proposed/universe) [2.15-1 => 2.15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ckon (bionic-proposed/universe) [0.7.1-3build4 => 0.7.1-3build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freeorion (bionic-proposed/universe) [0.4.7-2 => 0.4.7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gpsshogi (bionic-proposed/universe) [0.7.0-2build2 => 0.7.0-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mygui (bionic-proposed/universe) [3.2.2-5build1 => 3.2.2-5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: funguloids (bionic-proposed/universe) [1.06-13 => 1.06-13build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: orthanc (bionic-proposed/universe) [1.3.0+dfsg-1build1 => 1.3.0+dfsg-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-iio (bionic-proposed/universe) [0.1.67-1 => 0.1.67-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: orthanc-dicomweb (bionic-proposed/universe) [0.4+dfsg-1 => 0.4+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: orthanc-webviewer (bionic-proposed/universe) [2.3-1 => 2.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pdns-recursor (bionic-proposed/universe) [4.0.6-1 => 4.0.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qpid-cpp (bionic-proposed/universe) [0.16-9ubuntu9 => 0.16-9ubuntu10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: scram (bionic-proposed/universe) [0.15.0-1 => 0.15.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: slic3r-prusa (bionic-proposed/universe) [1.37.0+dfsg-1.1 => 1.37.0+dfsg-1.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: springlobby (bionic-proposed/universe) [0.256+dfsg-2 => 0.256+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ui-gxmlcpp (bionic-proposed/universe) [1.4.4-1build1 => 1.4.4-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: orthanc-postgresql (bionic-proposed/universe) [2.0-3 => 2.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: performous (bionic-proposed/universe) [1.1-2build1 => 1.1-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sfcgal (bionic-proposed/universe) [1.3.1-2 => 1.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: synfig (bionic-proposed/universe) [1.0.2-1build5 => 1.0.2-1build6] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: orthanc-wsi (bionic-proposed/universe) [0.4+dfsg-3 => 0.4+dfsg-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: spring (bionic-proposed/universe) [103.0+dfsg2-1 => 103.0+dfsg2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-interactive-markers (bionic-proposed/universe) [1.11.3-1build1 => 1.11.3-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ui-utilcpp (bionic-proposed/universe) [1.8.5-1build2 => 1.8.5-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: visp (bionic-proposed/universe) [3.0.1-2ubuntu2 => 3.0.1-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted autodock-vina [source] (bionic-proposed) [1.1.2-3build6]
-queuebot:#ubuntu-release- Unapproved: accepted choreonoid [source] (bionic-proposed) [1.5.0+dfsg-0.1build3]
-queuebot:#ubuntu-release- Unapproved: accepted flightcrew [source] (bionic-proposed) [0.7.2+dfsg-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted funguloids [source] (bionic-proposed) [1.06-13build1]
-queuebot:#ubuntu-release- Unapproved: accepted btfs [source] (bionic-proposed) [2.15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted freeorion [source] (bionic-proposed) [0.4.7-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ckon [source] (bionic-proposed) [0.7.1-3build5]
-queuebot:#ubuntu-release- Unapproved: accepted gpsshogi [source] (bionic-proposed) [0.7.0-2build3]
-queuebot:#ubuntu-release- Unapproved: accepted mygui [source] (bionic-proposed) [3.2.2-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-postgresql [source] (bionic-proposed) [2.0-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-wsi [source] (bionic-proposed) [0.4+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted pdns-recursor [source] (bionic-proposed) [4.0.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gr-iio [source] (bionic-proposed) [0.1.67-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-webviewer [source] (bionic-proposed) [2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-dicomweb [source] (bionic-proposed) [0.4+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc [source] (bionic-proposed) [1.3.0+dfsg-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted performous [source] (bionic-proposed) [1.1-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted ros-interactive-markers [source] (bionic-proposed) [1.11.3-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted sfcgal [source] (bionic-proposed) [1.3.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted spring [source] (bionic-proposed) [103.0+dfsg2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted qpid-cpp [source] (bionic-proposed) [0.16-9ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted slic3r-prusa [source] (bionic-proposed) [1.37.0+dfsg-1.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted scram [source] (bionic-proposed) [0.15.0-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (zesty-proposed) [3:11.0.3-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted springlobby [source] (bionic-proposed) [0.256+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ui-gxmlcpp [source] (bionic-proposed) [1.4.4-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted visp [source] (bionic-proposed) [3.0.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted synfig [source] (bionic-proposed) [1.0.2-1build6]
-queuebot:#ubuntu-release- Unapproved: accepted ui-utilcpp [source] (bionic-proposed) [1.8.5-1build3]
<bdmurray> slangasek: I sort of feel like there should be a separate distro-info-data bug regarding bionic not being listed as LTS and that your upload should fix that. If we don't file the bug in LP somebody else will.
<slangasek> bdmurray: I'm not convinced that's worth twiddling bugs and reuploading, but if you insist I will
<bdmurray> slangasek: Okay, how about we just look for duplicates before accepting?
<slangasek> bdmurray: sounds good to me
-queuebot:#ubuntu-release- Unapproved: busybox (bionic-proposed/main) [1:1.27.2-1ubuntu2 => 1:1.27.2-1ubuntu3] (core)
<doko> oops, wrong changelog entry for the last batch of no-change uploads :-/
-queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (bionic-proposed) [1:1.27.2-1ubuntu3]
<cascardo> sil2100: I have a new makedumpfile waiting to get into xenial-proposed, could you take a look at it?
<cascardo> bdmurray: or could you?
<bdmurray> cascardo: Is bug 1658733 fixed anywhere else e.g. artful / bionic?
<ubot5> bug 1658733 in makedumpfile (Ubuntu Artful) "Ubuntu 16.04.2KVM:kdump fails to mount root file system when noirqdistrib is missing as dump kernel parameter" [Undecided,In progress] https://launchpad.net/bugs/1658733
<bdmurray> tsimonq2: Can add more details than "it works" when verifying SRUs?
<bdmurray> We expect more details like https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1305232/comments/16
<ubot5> Ubuntu bug 1305232 in postfix (Ubuntu Xenial) "Postfix fails to start, "failure to copy certificates"" [Medium,Fix committed]
<cascardo> bdmurray: not yet, working on further testing upstream, so I expect it to land in devel and artful soon
<cascardo> bdmurray: but tested that it works on xenial, fixing a reproducible problem
<bdmurray> cascardo: The SRU process talk about having the bug fixed in the development release first.
<cascardo> bdmurray: at this stage of the release, should I push it to artful-proposed, then?
<bdmurray> cascardo: That'd be fine since bionic isn't open yet
<tsimonq2> bdmurray: sure
-queuebot:#ubuntu-release- Unapproved: accepted apturl [source] (artful-proposed) [0.5.2ubuntu13]
-queuebot:#ubuntu-release- Unapproved: accepted tgt [source] (artful-proposed) [1:1.0.71-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (artful-proposed) [36.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libmemcached [source] (artful-proposed) [1.0.18-4.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:12.0.0-0ubuntu2.1 => 3:12.0.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (artful-proposed) [02.18-0.1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (zesty-proposed) [02.18-0.1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: horizon (artful-proposed/main) [3:12.0.0-0ubuntu2.1 => 3:12.0.0-0ubuntu2.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.3-0ubuntu3 => 3:11.0.3-0ubuntu3.1] (openstack, ubuntu-server)
<balloons> slangasek, so juju-2.2.6 should be ready, just need a sponsor
<balloons> mwhudson should be able to do it when he awakes I trust :-)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-appindicator [source] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (artful-proposed) [0.7.1]
-queuebot:#ubuntu-release- Unapproved: postgresql-common (bionic-proposed/main) [184ubuntu1 => 187] (kubuntu, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: lsvpd (bionic-proposed/main) [1.7.8-0ubuntu2 => 1.7.8-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: amule (bionic-proposed/universe) [1:2.3.2-1build2 => 1:2.3.2-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: anytun (bionic-proposed/universe) [0.3.6-1 => 0.3.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: antpm (bionic-proposed/universe) [1.19-4 => 1.19-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: aoflagger (bionic-proposed/universe) [2.9.0-1 => 2.9.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: aqsis (bionic-proposed/universe) [1.8.2-8 => 1.8.2-8build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: asl (bionic-proposed/universe) [0.1.7-2 => 0.1.7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: aptitude (bionic-proposed/main) [0.8.3-1ubuntu4 => 0.8.3-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: asc (bionic-proposed/universe) [2.6.1.0-2 => 2.6.1.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: augustus (bionic-proposed/universe) [3.3+dfsg-2 => 3.3+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bagel (bionic-proposed/universe) [0.0~git20170109-1 => 0.0~git20170109-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: avogadro (bionic-proposed/universe) [1.2.0-2 => 1.2.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ball (bionic-proposed/universe) [1.4.3~beta1-3build1 => 1.4.3~beta1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bastet (bionic-proposed/universe) [0.43-4build4 => 0.43-4build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bio-eagle (bionic-proposed/universe) [2.3.5-1 => 2.3.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: barada-pam (bionic-proposed/universe) [0.5-3.1build7 => 0.5-3.1build8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: biometryd (bionic-proposed/universe) [0.0.1+16.10.20160922.3-0ubuntu2 => 0.0.1+16.10.20160922.3-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: berkeley-express (bionic-proposed/universe) [1.5.1-3build1 => 1.5.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: blender (bionic-proposed/universe) [2.78.c+dfsg0-2build1 => 2.78.c+dfsg0-2build2] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: bombono-dvd (bionic-proposed/universe) [1.2.2-0ubuntu12 => 1.2.2-0ubuntu13] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (bionic-proposed/multiverse) [1.0.0-3build1 => 1.0.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: casablanca (bionic-proposed/universe) [2.9.1-1 => 2.9.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: blockattack (bionic-proposed/universe) [2.1.2-1 => 2.1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caffe (bionic-proposed/universe) [1.0.0-3build1 => 1.0.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: btag (bionic-proposed/universe) [1.1.3-1build7 => 1.1.3-1build8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: casacore (bionic-proposed/universe) [2.3.0-4 => 2.3.0-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cclive (bionic-proposed/universe) [0.9.3-0.1build2 => 0.9.3-0.1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cassiopee (bionic-proposed/universe) [1.0.5-2 => 1.0.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cegui-mk2 (bionic-proposed/universe) [0.8.7-1.3build2 => 0.8.7-1.3build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.0-0ubuntu1 => 12.2.0-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: clblas (bionic-proposed/universe) [2.12-1 => 2.12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: collada-dom (bionic-proposed/universe) [2.4.4+ds1-2build2 => 2.4.4+ds1-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ciftilib (bionic-proposed/universe) [1.5.1-1 => 1.5.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: clfft (bionic-proposed/universe) [2.12.2-1build1 => 2.12.2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: colobot (bionic-proposed/universe) [0.1.10-2 => 0.1.10-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cufflinks (bionic-proposed/multiverse) [2.2.1-3build1 => 2.2.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: darkradiant (bionic-proposed/universe) [2.3.0-1 => 2.3.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dc-qt (bionic-proposed/universe) [0.2.0.alpha-4.3 => 0.2.0.alpha-4.3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dindel (bionic-proposed/universe) [1.01+dfsg-4build1 => 1.01+dfsg-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: comedilib (bionic-proposed/universe) [0.10.2-4build6 => 0.10.2-4build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dbus-cpp (bionic-proposed/universe) [5.0.0+16.10.20160809-0ubuntu2 => 5.0.0+16.10.20160809-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dnaclust (bionic-proposed/universe) [3-4build2 => 3-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cupt (bionic-proposed/universe) [2.9.10 => 2.9.10build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: diet (bionic-proposed/universe) [2.8.0-1ubuntu5 => 2.8.0-1ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted aoflagger [source] (bionic-proposed) [2.9.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted aqsis [source] (bionic-proposed) [1.8.2-8build1]
-queuebot:#ubuntu-release- Unapproved: accepted asl [source] (bionic-proposed) [0.1.7-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted avogadro [source] (bionic-proposed) [1.2.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ball [source] (bionic-proposed) [1.4.3~beta1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted bio-eagle [source] (bionic-proposed) [2.3.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted blender [source] (bionic-proposed) [2.78.c+dfsg0-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted bombono-dvd [source] (bionic-proposed) [1.2.2-0ubuntu13]
-queuebot:#ubuntu-release- Unapproved: accepted caffe-contrib [source] (bionic-proposed) [1.0.0-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted casablanca [source] (bionic-proposed) [2.9.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted aptitude [source] (bionic-proposed) [0.8.3-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted augustus [source] (bionic-proposed) [3.3+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted berkeley-express [source] (bionic-proposed) [1.5.1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted blockattack [source] (bionic-proposed) [2.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted caffe [source] (bionic-proposed) [1.0.0-3build2]
-queuebot:#ubuntu-release- Unapproved: dspdfviewer (bionic-proposed/universe) [1.15.1-1 => 1.15.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: easystroke (bionic-proposed/universe) [0.6.0-0ubuntu9 => 0.6.0-0ubuntu10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ekiga (bionic-proposed/universe) [4.0.1-7 => 4.0.1-7build1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: evolvotron (bionic-proposed/universe) [0.6.3-5build1 => 0.6.3-5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fastqtl (bionic-proposed/universe) [2.184+dfsg-5build3 => 2.184+dfsg-5build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted asc [source] (bionic-proposed) [2.6.1.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted biometryd [source] (bionic-proposed) [0.0.1+16.10.20160922.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: dolfin (bionic-proposed/universe) [2016.2.0-5build3 => 2016.2.0-5build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: eiskaltdcpp (bionic-proposed/universe) [2.2.9-4.1 => 2.2.9-4.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fastnetmon (bionic-proposed/universe) [1.1.3+dfsg-3 => 1.1.3+dfsg-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bagel [source] (bionic-proposed) [0.0~git20170109-1build1]
-queuebot:#ubuntu-release- Unapproved: dssp (bionic-proposed/universe) [2.2.1-3ubuntu1 => 2.2.1-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: field3d (bionic-proposed/universe) [1.7.2-1build1 => 1.7.2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted btag [source] (bionic-proposed) [1.1.3-1build8]
-queuebot:#ubuntu-release- Unapproved: ember (bionic-proposed/universe) [0.7.2+dfsg-1build1 => 0.7.2+dfsg-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted barada-pam [source] (bionic-proposed) [0.5-3.1build8]
-queuebot:#ubuntu-release- Unapproved: accepted casacore [source] (bionic-proposed) [2.3.0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted cclive [source] (bionic-proposed) [0.9.3-0.1build3]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted clblas [source] (bionic-proposed) [2.12-1build1]
-queuebot:#ubuntu-release- Unapproved: fife (bionic-proposed/universe) [0.4.1-2 => 0.4.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fracplanet (bionic-proposed/universe) [0.4.0-5 => 0.4.0-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freecontact (bionic-proposed/universe) [1.0.21-6 => 1.0.21-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: frogatto (bionic-proposed/multiverse) [1.3.1+dfsg-4 => 1.3.1+dfsg-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bastet [source] (bionic-proposed) [0.43-4build5]
-queuebot:#ubuntu-release- Unapproved: accepted cegui-mk2 [source] (bionic-proposed) [0.8.7-1.3build3]
-queuebot:#ubuntu-release- Unapproved: accepted clfft [source] (bionic-proposed) [2.12.2-1build2]
-queuebot:#ubuntu-release- Unapproved: freecad (bionic-proposed/universe) [0.16+dfsg2-3 => 0.16+dfsg2-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: galera-3 (bionic-proposed/universe) [25.3.20-1 => 25.3.20-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cassiopee [source] (bionic-proposed) [1.0.5-2build1]
-queuebot:#ubuntu-release- Unapproved: flamerobin (bionic-proposed/universe) [0.9.3~+20150308.6c0559c-2 => 0.9.3~+20150308.6c0559c-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ciftilib [source] (bionic-proposed) [1.5.1-1build1]
-queuebot:#ubuntu-release- Unapproved: freelan (bionic-proposed/universe) [2.0-5ubuntu2 => 2.0-5ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted amule [source] (bionic-proposed) [1:2.3.2-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted anytun [source] (bionic-proposed) [0.3.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted colobot [source] (bionic-proposed) [0.1.10-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted cufflinks [source] (bionic-proposed) [2.2.1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted darkradiant [source] (bionic-proposed) [2.3.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted dc-qt [source] (bionic-proposed) [0.2.0.alpha-4.3build1]
-queuebot:#ubuntu-release- Unapproved: accepted dindel [source] (bionic-proposed) [1.01+dfsg-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted dolfin [source] (bionic-proposed) [2016.2.0-5build4]
-queuebot:#ubuntu-release- Unapproved: accepted dssp [source] (bionic-proposed) [2.2.1-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted eiskaltdcpp [source] (bionic-proposed) [2.2.9-4.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted antpm [source] (bionic-proposed) [1.19-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted comedilib [source] (bionic-proposed) [0.10.2-4build7]
-queuebot:#ubuntu-release- Unapproved: accepted dbus-cpp [source] (bionic-proposed) [5.0.0+16.10.20160809-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted dnaclust [source] (bionic-proposed) [3-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted easystroke [source] (bionic-proposed) [0.6.0-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: gazebo (bionic-proposed/universe) [7.5.0+dfsg-1build3 => 7.5.0+dfsg-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: glob2 (bionic-proposed/universe) [0.9.4.4-2.5build1 => 0.9.4.4-2.5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: glom (bionic-proposed/universe) [1.30.4-0ubuntu9 => 1.30.4-0ubuntu10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnuradio (bionic-proposed/universe) [3.7.10.1-2ubuntu2 => 3.7.10.1-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gpick (bionic-proposed/universe) [0.2.5+git20161221-1 => 0.2.5+git20161221-1build1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted collada-dom [source] (bionic-proposed) [2.4.4+ds1-2build3]
-queuebot:#ubuntu-release- Unapproved: accepted diet [source] (bionic-proposed) [2.8.0-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted ekiga [source] (bionic-proposed) [4.0.1-7build1]
-queuebot:#ubuntu-release- Unapproved: glogg (bionic-proposed/universe) [1.1.0-1build3 => 1.1.0-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gource (bionic-proposed/universe) [0.44-1build3 => 0.44-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-hpsdr (bionic-proposed/universe) [0.0.0.bb77f3c-2build4 => 0.0.0.bb77f3c-2build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-radar (bionic-proposed/universe) [0.0.0.20160615-3build1 => 0.0.0.20160615-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cupt [source] (bionic-proposed) [2.9.10build1]
-queuebot:#ubuntu-release- Unapproved: gearmand (bionic-proposed/universe) [1.0.6-9build1 => 1.0.6-9build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-fosphor (bionic-proposed/universe) [3.7.0.2.7b6b996-1build2 => 3.7.0.2.7b6b996-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dspdfviewer [source] (bionic-proposed) [1.15.1-1build1]
-queuebot:#ubuntu-release- Unapproved: gr-iqbal (bionic-proposed/universe) [0.37.2-7build2 => 0.37.2-7build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnash (bionic-proposed/universe) [0.8.11~git20160608-1.3 => 0.8.11~git20160608-1.3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-rds (bionic-proposed/universe) [3.7.0.2.a542331-1build2 => 3.7.0.2.a542331-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gyoto (bionic-proposed/universe) [1.2.0-3 => 1.2.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-blogliterately (bionic-proposed/universe) [0.8.4.3-1build2 => 0.8.4.3-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-idna (bionic-proposed/universe) [0.3.0-6build2 => 0.3.0-6build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: guitarix (bionic-proposed/universe) [0.35.6-1 => 0.35.6-1build1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: haskell-hakyll (bionic-proposed/universe) [4.9.7.0-3build1 => 4.9.7.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hadori (bionic-proposed/universe) [1.0-1 => 1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: heaptrack (bionic-proposed/universe) [1.0.1~20170503.git4da8c45-3 => 1.0.1~20170503.git4da8c45-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ember [source] (bionic-proposed) [0.7.2+dfsg-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted fastnetmon [source] (bionic-proposed) [1.1.3+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted field3d [source] (bionic-proposed) [1.7.2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted flamerobin [source] (bionic-proposed) [0.9.3~+20150308.6c0559c-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted freecad [source] (bionic-proposed) [0.16+dfsg2-3build1]
-queuebot:#ubuntu-release- Unapproved: hugin (bionic-proposed/universe) [2017.0.0~rc2+dfsg-2 => 2017.0.0~rc2+dfsg-2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: imagevis3d (bionic-proposed/universe) [3.1.0-5 => 3.1.0-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted evolvotron [source] (bionic-proposed) [0.6.3-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted fife [source] (bionic-proposed) [0.4.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted freecontact [source] (bionic-proposed) [1.0.21-6build1]
-queuebot:#ubuntu-release- Unapproved: innoextract (bionic-proposed/universe) [1.6-1build2 => 1.6-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fastqtl [source] (bionic-proposed) [2.184+dfsg-5build4]
-queuebot:#ubuntu-release- Unapproved: icinga2 (bionic-proposed/universe) [2.7.0-1 => 2.7.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fracplanet [source] (bionic-proposed) [0.4.0-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted freelan [source] (bionic-proposed) [2.0-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted galera-3 [source] (bionic-proposed) [25.3.20-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gearmand [source] (bionic-proposed) [1.0.6-9build2]
-queuebot:#ubuntu-release- Unapproved: accepted glogg [source] (bionic-proposed) [1.1.0-1build4]
-queuebot:#ubuntu-release- Unapproved: isc-kea (bionic-proposed/universe) [1.1.0-1 => 1.1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: juju-mongodb3.2 (bionic-proposed/universe) [3.2.15-0ubuntu1 => 3.2.15-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kakoune (bionic-proposed/universe) [0~2016.12.20.1.3a6167ae-1 => 0~2016.12.20.1.3a6167ae-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kido (bionic-proposed/universe) [0.1.0+dfsg-2build6 => 0.1.0+dfsg-2build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted frogatto [source] (bionic-proposed) [1.3.1+dfsg-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted glob2 [source] (bionic-proposed) [0.9.4.4-2.5build2]
-queuebot:#ubuntu-release- Unapproved: ismrmrd (bionic-proposed/universe) [1.3.3-1build1 => 1.3.3-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kcollectd (bionic-proposed/universe) [0.9-4 => 0.9-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gazebo [source] (bionic-proposed) [7.5.0+dfsg-1build4]
-queuebot:#ubuntu-release- Unapproved: k3d (bionic-proposed/universe) [0.8.0.6-4 => 0.8.0.6-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted glom [source] (bionic-proposed) [1.30.4-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: kig (bionic-proposed/universe) [4:17.04.3-0ubuntu1 => 4:17.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnash [source] (bionic-proposed) [0.8.11~git20160608-1.3build1]
-queuebot:#ubuntu-release- Unapproved: accepted gource [source] (bionic-proposed) [0.44-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted gr-fosphor [source] (bionic-proposed) [3.7.0.2.7b6b996-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted gr-iqbal [source] (bionic-proposed) [0.37.2-7build3]
-queuebot:#ubuntu-release- Unapproved: accepted gr-rds [source] (bionic-proposed) [3.7.0.2.a542331-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted gyoto [source] (bionic-proposed) [1.2.0-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-blogliterately [source] (bionic-proposed) [0.8.4.3-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-idna [source] (bionic-proposed) [0.3.0-6build3]
-queuebot:#ubuntu-release- Unapproved: accepted hugin [source] (bionic-proposed) [2017.0.0~rc2+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted imagevis3d [source] (bionic-proposed) [3.1.0-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted gnuradio [source] (bionic-proposed) [3.7.10.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gr-hpsdr [source] (bionic-proposed) [0.0.0.bb77f3c-2build5]
-queuebot:#ubuntu-release- Unapproved: accepted guitarix [source] (bionic-proposed) [0.35.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-hakyll [source] (bionic-proposed) [4.9.7.0-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted icinga2 [source] (bionic-proposed) [2.7.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gpick [source] (bionic-proposed) [0.2.5+git20161221-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted hadori [source] (bionic-proposed) [1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted innoextract [source] (bionic-proposed) [1.6-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted gr-radar [source] (bionic-proposed) [0.0.0.20160615-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted heaptrack [source] (bionic-proposed) [1.0.1~20170503.git4da8c45-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted isc-kea [source] (bionic-proposed) [1.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (bionic-proposed) [3.2.15-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kakoune [source] (bionic-proposed) [0~2016.12.20.1.3a6167ae-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted kido [source] (bionic-proposed) [0.1.0+dfsg-2build7]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (zesty-proposed) [1:2.8+dfsg-3ubuntu2.7]
-queuebot:#ubuntu-release- Unapproved: accepted ismrmrd [source] (bionic-proposed) [1.3.3-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted kcollectd [source] (bionic-proposed) [0.9-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted k3d [source] (bionic-proposed) [0.8.0.6-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted kig [source] (bionic-proposed) [4:17.04.3-0ubuntu2]
<doko> slangasek: do you want to do the postgresql transition now?
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:12.0.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: laserboy (bionic-proposed/universe) [2016.03.15-1.1build1 => 2016.03.15-1.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lgogdownloader (bionic-proposed/universe) [3.2-1build1 => 3.2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libbitcoin (bionic-proposed/universe) [2.11.0-1ubuntu2 => 2.11.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: krita (bionic-proposed/universe) [1:3.2.1+dfsg-1 => 1:3.2.1+dfsg-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libavg (bionic-proposed/universe) [1.8.1-3build1 => 1.8.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ledger (bionic-proposed/universe) [3.1.2~pre1+g3a00e1c+dfsg1-5build1 => 3.1.2~pre1+g3a00e1c+dfsg1-5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libcmis (bionic-proposed/main) [0.5.1+git20160603-3build1 => 0.5.1+git20160603-3build2] (kubuntu, ubuntu-desktop)
<slangasek> doko: I don't care, I'm just going through my merges :)
-queuebot:#ubuntu-release- Unapproved: libcutl (bionic-proposed/universe) [1.10.0+ds1-2 => 1.10.0+ds1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libkolabxml (bionic-proposed/universe) [1.1.4-1build3 => 1.1.4-1build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libmems (bionic-proposed/universe) [1.6.0+4725-4 => 1.6.0+4725-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: liborcus (bionic-proposed/main) [0.12.1-3build1 => 0.12.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libpwiz (bionic-proposed/universe) [3.0.10827-3 => 3.0.10827-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: librime (bionic-proposed/universe) [1.2.9+dfsg1-1build1 => 1.2.9+dfsg1-1build2] (input-methods)
-queuebot:#ubuntu-release- Unapproved: libgdf (bionic-proposed/universe) [0.1.2-2.0build7 => 0.1.2-2.0build8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libmpikmeans (bionic-proposed/universe) [1.5+dfsg-5build2 => 1.5+dfsg-5build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: librcsb-core-wrapper (bionic-proposed/universe) [1.005-4build4 => 1.005-4build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: liblas (bionic-proposed/universe) [1.8.1-4build1 => 1.8.1-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: liborigin2 (bionic-proposed/universe) [2:20110117-1.2build1 => 2:20110117-1.2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted krita [source] (bionic-proposed) [1:3.2.1+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ledger [source] (bionic-proposed) [3.1.2~pre1+g3a00e1c+dfsg1-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted libavg [source] (bionic-proposed) [1.8.1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted libcmis [source] (bionic-proposed) [0.5.1+git20160603-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted libgdf [source] (bionic-proposed) [0.1.2-2.0build8]
-queuebot:#ubuntu-release- Unapproved: libvigraimpex (bionic-proposed/universe) [1.10.0+git20160211.167be93+dfsg-2ubuntu2 => 1.10.0+git20160211.167be93+dfsg-2ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lierolibre (bionic-proposed/universe) [0.5-2build3 => 0.5-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: limereg (bionic-proposed/universe) [1.4.1-3build1 => 1.4.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lucene++ (bionic-proposed/universe) [3.0.7-8build3 => 3.0.7-8build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lvtk (bionic-proposed/universe) [1.2.0~dfsg0-2ubuntu1 => 1.2.0~dfsg0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted laserboy [source] (bionic-proposed) [2016.03.15-1.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted libbitcoin [source] (bionic-proposed) [2.11.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: libtorrent-rasterbar (bionic-proposed/universe) [1.1.1-1build2 => 1.1.1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lightspark (bionic-proposed/universe) [0.7.2+git20150512-2.1ubuntu8 => 0.7.2+git20150512-2.1ubuntu9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lv2-c++-tools (bionic-proposed/universe) [1.0.5-3build1 => 1.0.5-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lgogdownloader [source] (bionic-proposed) [3.2-1build2]
-queuebot:#ubuntu-release- Unapproved: libzeep (bionic-proposed/universe) [3.0.2-4build2 => 3.0.2-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lyx (bionic-proposed/universe) [2.2.3-1 => 2.2.3-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libcutl [source] (bionic-proposed) [1.10.0+ds1-2build1]
-queuebot:#ubuntu-release- Unapproved: linssid (bionic-proposed/universe) [2.9-3 => 2.9-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libkolabxml [source] (bionic-proposed) [1.1.4-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted libmems [source] (bionic-proposed) [1.6.0+4725-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted liborcus [source] (bionic-proposed) [0.12.1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted libpwiz [source] (bionic-proposed) [3.0.10827-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted librime [source] (bionic-proposed) [1.2.9+dfsg1-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted libvigraimpex [source] (bionic-proposed) [1.10.0+git20160211.167be93+dfsg-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: mapnik (bionic-proposed/universe) [3.0.15+ds-2ubuntu1 => 3.0.15+ds-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: messaging-framework (bionic-proposed/universe) [0.2+17.04.20161208-0ubuntu1 => 0.2+17.04.20161208-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mididings (bionic-proposed/universe) [0~20120419~ds0-5build3 => 0~20120419~ds0-5build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mir (bionic-proposed/main) [0.28.0+17.10.20171011.1-0ubuntu1 => 0.28.0+17.10.20171011.1-0ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted liblas [source] (bionic-proposed) [1.8.1-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted liborigin2 [source] (bionic-proposed) [2:20110117-1.2build2]
-queuebot:#ubuntu-release- Unapproved: accepted libtorrent-rasterbar [source] (bionic-proposed) [1.1.1-1build3]
-queuebot:#ubuntu-release- Unapproved: media-hub (bionic-proposed/universe) [4.6.0+17.04.20170323-0ubuntu1 => 4.6.0+17.04.20170323-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: minieigen (bionic-proposed/universe) [0.50.3+dfsg1-5build4 => 0.50.3+dfsg1-5build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libmpikmeans [source] (bionic-proposed) [1.5+dfsg-5build3]
-queuebot:#ubuntu-release- Unapproved: maffilter (bionic-proposed/universe) [1.2.1+dfsg-1 => 1.2.1+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted librcsb-core-wrapper [source] (bionic-proposed) [1.005-4build5]
-queuebot:#ubuntu-release- Unapproved: mia (bionic-proposed/universe) [2.4.4-2ubuntu3 => 2.4.4-2ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libzeep [source] (bionic-proposed) [3.0.2-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted lightspark [source] (bionic-proposed) [0.7.2+git20150512-2.1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted linssid [source] (bionic-proposed) [2.9-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted lucene++ [source] (bionic-proposed) [3.0.7-8build4]
-queuebot:#ubuntu-release- Unapproved: accepted lvtk [source] (bionic-proposed) [1.2.0~dfsg0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted maffilter [source] (bionic-proposed) [1.2.1+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted media-hub [source] (bionic-proposed) [4.6.0+17.04.20170323-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mia [source] (bionic-proposed) [2.4.4-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted minieigen [source] (bionic-proposed) [0.50.3+dfsg1-5build5]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [sync] (bionic-proposed) [187]
-queuebot:#ubuntu-release- Unapproved: accepted lierolibre [source] (bionic-proposed) [0.5-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [sync] (bionic-proposed) [1.7.8-2]
-queuebot:#ubuntu-release- Unapproved: accepted lyx [source] (bionic-proposed) [2.2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted messaging-framework [source] (bionic-proposed) [0.2+17.04.20161208-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mir [source] (bionic-proposed) [0.28.0+17.10.20171011.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted limereg [source] (bionic-proposed) [1.4.1-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [source] (bionic-proposed) [3.0.15+ds-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lv2-c++-tools [source] (bionic-proposed) [1.0.5-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted mididings [source] (bionic-proposed) [0~20120419~ds0-5build4]
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.7-1 => 1:3.4.7-1build1] (mozilla)
-queuebot:#ubuntu-release- Unapproved: mothur (bionic-proposed/universe) [1.39.5-2 => 1.39.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mrs (bionic-proposed/universe) [6.0.5+dfsg-2build3 => 6.0.5+dfsg-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: morris (bionic-proposed/universe) [0.2-3 => 0.2-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mupen64plus-video-glide64mk2 (bionic-proposed/universe) [2.5-4build3 => 2.5-4build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mp3diags (bionic-proposed/universe) [1.2.03-1build1 => 1.2.03-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: murasaki (bionic-proposed/universe) [1.68.6-6build4 => 1.68.6-6build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ogre-1.9 (bionic-proposed/universe) [1.9.0+dfsg1-9 => 1.9.0+dfsg1-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opengm (bionic-proposed/universe) [2.3.6+20160905-1build2 => 2.3.6+20160905-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openmw (bionic-proposed/multiverse) [0.41.0-1ubuntu2 => 0.41.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ncmpcpp (bionic-proposed/universe) [0.7.4-1build4 => 0.7.4-1build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openimageio (bionic-proposed/universe) [1.6.17~dfsg0-1ubuntu5 => 1.6.17~dfsg0-1ubuntu6] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: ompl (bionic-proposed/universe) [1.2.1+ds1-1 => 1.2.1+ds1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openscad (bionic-proposed/universe) [2015.03-2+dfsg-2ubuntu1 => 2015.03-2+dfsg-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvdb (bionic-proposed/universe) [3.2.0-2.1 => 3.2.0-2.1build1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: osmium-tool (bionic-proposed/universe) [1.7.0-2 => 1.7.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcb2gcode (bionic-proposed/universe) [1.1.4-git20120902-1.1build1 => 1.1.4-git20120902-1.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opensurgsim (bionic-proposed/universe) [0.7.0-5 => 0.7.0-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: otb (bionic-proposed/universe) [6.0.0+dfsg-4build1 => 6.0.0+dfsg-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: osm2pgrouting (bionic-proposed/universe) [2.2.0-1 => 2.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcl (bionic-proposed/universe) [1.8.1+dfsg1-2ubuntu1 => 1.8.1+dfsg1-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pdns (bionic-proposed/universe) [4.0.4-2 => 4.0.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pingus (bionic-proposed/universe) [0.7.6-4 => 0.7.6-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pdfcube (bionic-proposed/universe) [0.0.5-2build5 => 0.0.5-2build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pion (bionic-proposed/universe) [5.0.7+dfsg-4 => 5.0.7+dfsg-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: percona-galera-3 (bionic-proposed/universe) [3.19-0ubuntu1 => 3.19-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: plee-the-bear (bionic-proposed/universe) [0.6.0-4 => 0.6.0-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pokerth (bionic-proposed/universe) [1.1.1-7 => 1.1.1-7build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: povray (bionic-proposed/universe) [1:3.7.0.0-9build2 => 1:3.7.0.0-9build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: prime-phylo (bionic-proposed/universe) [1.0.11-4build2 => 1.0.11-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pulseview (bionic-proposed/universe) [0.2.0-1.2 => 0.2.0-1.2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pp-popularity-contest (bionic-proposed/universe) [1.0.6-2build4 => 1.0.6-2build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pycuda (bionic-proposed/multiverse) [2016.1.2+git20161024-1build2 => 2016.1.2+git20161024-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: process-cpp (bionic-proposed/universe) [3.0.1-0ubuntu5 => 3.0.1-0ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyexiv2 (bionic-proposed/universe) [0.3.2-5ubuntu4build5 => 0.3.2-5ubuntu4build6] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: pytango (bionic-proposed/universe) [9.2.1-1 => 9.2.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-escript (bionic-proposed/universe) [5.0-4ubuntu1 => 5.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-mapnik (bionic-proposed/universe) [1:0.0~20170621-0cd7493f2-1 => 1:0.0~20170621-0cd7493f2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyosmium (bionic-proposed/universe) [2.12.4-1 => 2.12.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-freecontact (bionic-proposed/universe) [1.1-2build3 => 1.1-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-demgengeo (bionic-proposed/universe) [1.2-1build4 => 1.2-1build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pythonmagick (bionic-proposed/universe) [0.9.17-1 => 0.9.17-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ogre-1.9 [source] (bionic-proposed) [1.9.0+dfsg1-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted opengm [source] (bionic-proposed) [2.3.6+20160905-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted openmw [source] (bionic-proposed) [0.41.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted opensurgsim [source] (bionic-proposed) [0.7.0-5build1]
-queuebot:#ubuntu-release- Unapproved: python-visual (bionic-proposed/universe) [1:5.12-1.6build8 => 1:5.12-1.6build9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qtltools (bionic-proposed/universe) [1.1+dfsg-2 => 1.1+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rdkit (bionic-proposed/universe) [201603.5-2 => 201603.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: regina-normal (bionic-proposed/universe) [5.1-2 => 5.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ompl [source] (bionic-proposed) [1.2.1+ds1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted openscad [source] (bionic-proposed) [2015.03-2+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: qbittorrent (bionic-proposed/universe) [3.3.7-3 => 3.3.7-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: referencer (bionic-proposed/universe) [1.2.2-2 => 1.2.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openimageio [source] (bionic-proposed) [1.6.17~dfsg0-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: quantlib (bionic-proposed/universe) [1.10-1 => 1.10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-pgmagick (bionic-proposed/universe) [0.6.5-1build1 => 0.6.5-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (bionic-proposed) [1.8.1+dfsg1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pdns [source] (bionic-proposed) [4.0.4-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted pingus [source] (bionic-proposed) [0.7.6-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted plee-the-bear [source] (bionic-proposed) [0.6.0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted povray [source] (bionic-proposed) [1:3.7.0.0-9build3]
-queuebot:#ubuntu-release- Unapproved: rheolef (bionic-proposed/universe) [6.7-3 => 6.7-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rlvm (bionic-proposed/universe) [0.14-2.1build2 => 0.14-2.1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-bond-core (bionic-proposed/universe) [1.7.18-2 => 1.7.18-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-dynamic-reconfigure (bionic-proposed/universe) [1.5.46-1 => 1.5.46-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-laser-geometry (bionic-proposed/universe) [1.6.4-2build5 => 1.6.4-2build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pdfcube [source] (bionic-proposed) [0.0.5-2build6]
-queuebot:#ubuntu-release- Unapproved: accepted pion [source] (bionic-proposed) [5.0.7+dfsg-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted pp-popularity-contest [source] (bionic-proposed) [1.0.6-2build5]
-queuebot:#ubuntu-release- Unapproved: ros-actionlib (bionic-proposed/universe) [1.11.7-1 => 1.11.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-geometry-experimental (bionic-proposed/universe) [0.5.13-5 => 0.5.13-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-random-numbers (bionic-proposed/universe) [0.3.1-1build2 => 0.3.1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-ros (bionic-proposed/universe) [1.14.1-1 => 1.14.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-rospack (bionic-proposed/universe) [2.4.2-1 => 2.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rsbackup (bionic-proposed/universe) [3.1-3 => 3.1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: schroot (bionic-proposed/main) [1.6.10-4 => 1.6.10-4build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted percona-galera-3 [source] (bionic-proposed) [3.19-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ring (bionic-proposed/universe) [20170803.2.5fcfe3f~dfsg1-1 => 20170803.2.5fcfe3f~dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-pluginlib (bionic-proposed/universe) [1.10.4-2build2 => 1.10.4-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-roscpp-core (bionic-proposed/universe) [0.6.5-1 => 0.6.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: salmon (bionic-proposed/universe) [0.7.2+ds1-2 => 0.7.2+ds1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sdformat (bionic-proposed/universe) [4.2.0-3 => 4.2.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pokerth [source] (bionic-proposed) [1.1.1-7build1]
-queuebot:#ubuntu-release- Unapproved: ros-ros-comm (bionic-proposed/universe) [1.12.6-2 => 1.12.6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: scummvm-tools (bionic-proposed/universe) [1.9.0-2 => 1.9.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-class-loader (bionic-proposed/universe) [0.3.6-1build2 => 0.3.6-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-vision-opencv (bionic-proposed/universe) [1.12.3+ds-1build1 => 1.12.3+ds-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pycuda [source] (bionic-proposed) [2016.1.2+git20161024-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted pyosmium [source] (bionic-proposed) [2.12.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-demgengeo [source] (bionic-proposed) [1.2-1build5]
-queuebot:#ubuntu-release- Unapproved: accepted python-freecontact [source] (bionic-proposed) [1.1-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted python-pgmagick [source] (bionic-proposed) [0.6.5-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted rdkit [source] (bionic-proposed) [201603.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted regina-normal [source] (bionic-proposed) [5.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ring [source] (bionic-proposed) [20170803.2.5fcfe3f~dfsg1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-actionlib [source] (bionic-proposed) [1.11.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-class-loader [source] (bionic-proposed) [0.3.6-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted pyexiv2 [source] (bionic-proposed) [0.3.2-5ubuntu4build6]
-queuebot:#ubuntu-release- Unapproved: accepted python-escript [source] (bionic-proposed) [5.0-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pythonmagick [source] (bionic-proposed) [0.9.17-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rheolef [source] (bionic-proposed) [6.7-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-bond-core [source] (bionic-proposed) [1.7.18-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.6~17.04.1]
-queuebot:#ubuntu-release- Unapproved: seer (bionic-proposed/universe) [1.1.2-3 => 1.1.2-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sfftobmp (bionic-proposed/universe) [3.1.3-5build4 => 3.1.3-5build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sinfo (bionic-proposed/universe) [0.0.48-1build2 => 0.0.48-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapper (bionic-proposed/universe) [0.5.0-2 => 0.5.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pytango [source] (bionic-proposed) [9.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted referencer [source] (bionic-proposed) [1.2.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-dynamic-reconfigure [source] (bionic-proposed) [1.5.46-1build1]
-queuebot:#ubuntu-release- Unapproved: setop (bionic-proposed/universe) [0.1-1build2 => 0.1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sitplus (bionic-proposed/universe) [1.0.3-5.1build2 => 1.0.3-5.1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: soapyuhd (bionic-proposed/universe) [0.3.3-1 => 0.3.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: soundscaperenderer (bionic-proposed/universe) [0.4.2~dfsg-6build2 => 0.4.2~dfsg-6build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sqlsmith (bionic-proposed/universe) [1.0-1build3 => 1.0-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sslsniff (bionic-proposed/universe) [0.8-6ubuntu1 => 0.8-6ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: supertux (bionic-proposed/universe) [0.5.1-1 => 0.5.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-mapnik [source] (bionic-proposed) [1:0.0~20170621-0cd7493f2-1build1]
-queuebot:#ubuntu-release- Unapproved: sdpb (bionic-proposed/universe) [1.0-3build1 => 1.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: soapyosmo (bionic-proposed/universe) [0.2.5-1 => 0.2.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: source-highlight (bionic-proposed/universe) [3.1.8-1.1build3 => 3.1.8-1.1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: supercollider (bionic-proposed/universe) [1:3.7.0~repack-5 => 1:3.7.0~repack-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tagpy (bionic-proposed/universe) [2013.1-6build1 => 2013.1-6build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ticcutils (bionic-proposed/universe) [0.14-1 => 0.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tophat (bionic-proposed/universe) [2.1.1+dfsg-3 => 2.1.1+dfsg-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rlvm [source] (bionic-proposed) [0.14-2.1build3]
-queuebot:#ubuntu-release- Unapproved: solarpowerlog (bionic-proposed/universe) [0.24-7 => 0.24-7build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: swift-im (bionic-proposed/universe) [3.0.4-1 => 3.0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tmfs (bionic-proposed/universe) [3-2build7 => 3-2build8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shark (bionic-proposed/universe) [3.1.3+ds1-2ubuntu5 => 3.1.3+ds1-2ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: thumbnailer (bionic-proposed/universe) [2.4+17.04.20161114.1-0ubuntu1 => 2.4+17.04.20161114.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ssh-agent-filter (bionic-proposed/universe) [0.4.2-1 => 0.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted quantlib [source] (bionic-proposed) [1.10-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-laser-geometry [source] (bionic-proposed) [1.6.4-2build6]
-queuebot:#ubuntu-release- Unapproved: accepted ros-random-numbers [source] (bionic-proposed) [0.3.1-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted ros-ros [source] (bionic-proposed) [1.14.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-rospack [source] (bionic-proposed) [2.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rsbackup [source] (bionic-proposed) [3.1-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted schroot [source] (bionic-proposed) [1.6.10-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted sdformat [source] (bionic-proposed) [4.2.0-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted seer [source] (bionic-proposed) [1.1.2-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted sfftobmp [source] (bionic-proposed) [3.1.3-5build5]
-queuebot:#ubuntu-release- Unapproved: accepted ros-geometry-experimental [source] (bionic-proposed) [0.5.13-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-ros-comm [source] (bionic-proposed) [1.12.6-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-vision-opencv [source] (bionic-proposed) [1.12.3+ds-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted scummvm-tools [source] (bionic-proposed) [1.9.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted setop [source] (bionic-proposed) [0.1-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted sinfo [source] (bionic-proposed) [0.0.48-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted soapyosmo [source] (bionic-proposed) [0.2.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted solarpowerlog [source] (bionic-proposed) [0.24-7build1]
-queuebot:#ubuntu-release- Unapproved: accepted source-highlight [source] (bionic-proposed) [3.1.8-1.1build4]
-queuebot:#ubuntu-release- Unapproved: accepted ssh-agent-filter [source] (bionic-proposed) [0.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-pluginlib [source] (bionic-proposed) [1.10.4-2build3]
-queuebot:#ubuntu-release- Unapproved: accepted salmon [source] (bionic-proposed) [0.7.2+ds1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted shark [source] (bionic-proposed) [3.1.3+ds1-2ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted soapyuhd [source] (bionic-proposed) [0.3.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted sqlsmith [source] (bionic-proposed) [1.0-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted supercollider [source] (bionic-proposed) [1:3.7.0~repack-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted swift-im [source] (bionic-proposed) [3.0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted thumbnailer [source] (bionic-proposed) [2.4+17.04.20161114.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: uhd (bionic-proposed/universe) [3.9.5-2 => 3.9.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unity-scopes-api (bionic-proposed/universe) [1.0.8+17.04.20170116-0ubuntu1 => 1.0.8+17.04.20170116-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ros-roscpp-core [source] (bionic-proposed) [0.6.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted sitplus [source] (bionic-proposed) [1.0.3-5.1build3]
-queuebot:#ubuntu-release- Unapproved: accepted sslsniff [source] (bionic-proposed) [0.8-6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted tagpy [source] (bionic-proposed) [2013.1-6build2]
-queuebot:#ubuntu-release- Unapproved: undertaker (bionic-proposed/universe) [1.6.1-4.1build1 => 1.6.1-4.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: uwsgi (bionic-proposed/universe) [2.0.15-2.1ubuntu2 => 2.0.15-2.1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vdr-plugin-fritzbox (bionic-proposed/universe) [1.5.3-6 => 1.5.3-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: volk (bionic-proposed/universe) [1.3-1build2 => 1.3-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: votca-tools (bionic-proposed/universe) [1.3.0-2build3 => 1.3.0-2build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: voxbo (bionic-proposed/universe) [1.8.5~svn1246-2ubuntu1 => 1.8.5~svn1246-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sdpb [source] (bionic-proposed) [1.0-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted supertux [source] (bionic-proposed) [0.5.1-1build1]
-queuebot:#ubuntu-release- Unapproved: utopia-documents (bionic-proposed/universe) [3.0.2-1.1 => 3.0.2-1.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vera++ (bionic-proposed/universe) [1.2.1-2build5 => 1.2.1-2build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vowpal-wabbit (bionic-proposed/universe) [8.1.1-1build3 => 8.1.1-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted soundscaperenderer [source] (bionic-proposed) [0.4.2~dfsg-6build3]
-queuebot:#ubuntu-release- Unapproved: vcmi (bionic-proposed/multiverse) [0.99+dfsg-2 => 0.99+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ncmpcpp [source] (bionic-proposed) [0.7.4-1build5]
-queuebot:#ubuntu-release- Unapproved: accepted osm2pgrouting [source] (bionic-proposed) [2.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted otb [source] (bionic-proposed) [6.0.0+dfsg-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted prime-phylo [source] (bionic-proposed) [1.0.11-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted pulseview [source] (bionic-proposed) [0.2.0-1.2build1]
-queuebot:#ubuntu-release- Unapproved: accepted qbittorrent [source] (bionic-proposed) [3.3.7-3build1]
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.1-2ubuntu2 => 3.26.1-2ubuntu2.1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: wesnoth-1.12 (bionic-proposed/universe) [1:1.12.6-1build2 => 1:1.12.6-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: trust-store (bionic-proposed/universe) [2.0.0+16.04.20160119-0ubuntu6 => 2.0.0+16.04.20160119-0ubuntu7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openvdb [source] (bionic-proposed) [3.2.0-2.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pcb2gcode [source] (bionic-proposed) [1.1.4-git20120902-1.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted python-visual [source] (bionic-proposed) [1:5.12-1.6build9]
-queuebot:#ubuntu-release- Unapproved: 0ad (bionic-proposed/universe) [0.0.21-2build1 => 0.0.21-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ycmd (bionic-proposed/universe) [0+20161219+git486b809-2.1 => 0+20161219+git486b809-2.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: votca-csg (bionic-proposed/universe) [1.3.0-3build1 => 1.3.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted process-cpp [source] (bionic-proposed) [3.0.1-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: wsclean (bionic-proposed/universe) [2.4-1build1 => 2.4-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted osmium-tool [source] (bionic-proposed) [1.7.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted qtltools [source] (bionic-proposed) [1.1+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (bionic-proposed) [1:3.4.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mothur [source] (bionic-proposed) [1.39.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted mrs [source] (bionic-proposed) [6.0.5+dfsg-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted murasaki [source] (bionic-proposed) [1.68.6-6build5]
-queuebot:#ubuntu-release- Unapproved: accepted ticcutils [source] (bionic-proposed) [0.14-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted tophat [source] (bionic-proposed) [2.1.1+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted uhd [source] (bionic-proposed) [3.9.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-scopes-api [source] (bionic-proposed) [1.0.8+17.04.20170116-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [source] (bionic-proposed) [2.0.15-2.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted vdr-plugin-fritzbox [source] (bionic-proposed) [1.5.3-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted morris [source] (bionic-proposed) [0.2-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted mupen64plus-video-glide64mk2 [source] (bionic-proposed) [2.5-4build4]
-queuebot:#ubuntu-release- Unapproved: accepted tmfs [source] (bionic-proposed) [3-2build8]
-queuebot:#ubuntu-release- Unapproved: accepted undertaker [source] (bionic-proposed) [1.6.1-4.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted vcmi [source] (bionic-proposed) [0.99+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted mp3diags [source] (bionic-proposed) [1.2.03-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted trust-store [source] (bionic-proposed) [2.0.0+16.04.20160119-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted vera++ [source] (bionic-proposed) [1.2.1-2build6]
-queuebot:#ubuntu-release- Unapproved: accepted snapper [source] (bionic-proposed) [0.5.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted utopia-documents [source] (bionic-proposed) [3.0.2-1.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted 0ad [source] (bionic-proposed) [0.0.21-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted votca-csg [source] (bionic-proposed) [1.3.0-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted vowpal-wabbit [source] (bionic-proposed) [8.1.1-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted wesnoth-1.12 [source] (bionic-proposed) [1:1.12.6-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted ycmd [source] (bionic-proposed) [0+20161219+git486b809-2.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted volk [source] (bionic-proposed) [1.3-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted voxbo [source] (bionic-proposed) [1.8.5~svn1246-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted votca-tools [source] (bionic-proposed) [1.3.0-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted wsclean [source] (bionic-proposed) [2.4-1build2]
-queuebot:#ubuntu-release- Unapproved: totem-pl-parser (bionic-proposed/main) [3.10.8-3ubuntu1 => 3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libcolumbus (bionic-proposed/universe) [1.1.0+15.10.20150806-0ubuntu9 => 1.1.0+15.10.20150806-0ubuntu10] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libphonenumber (bionic-proposed/main) [7.1.0-5ubuntu3 => 7.1.0-5ubuntu4] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: widelands (bionic-proposed/universe) [1:19+repack-4build1 => 1:19+repack-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: odil (bionic-proposed/universe) [0.8.0-3ubuntu2 => 0.8.0-3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libcolumbus [source] (bionic-proposed) [1.1.0+15.10.20150806-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted odil [source] (bionic-proposed) [0.8.0-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted widelands [source] (bionic-proposed) [1:19+repack-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted libphonenumber [source] (bionic-proposed) [7.1.0-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (zesty-proposed) [1.0.81ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted totem-pl-parser [source] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (trusty-proposed) [1.0.59ubuntu0.9]
-queuebot:#ubuntu-release- New binary: totem-pl-parser [s390x] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: totem-pl-parser [amd64] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: totem-pl-parser [ppc64el] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: totem-pl-parser [i386] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.7 [source] (zesty-proposed) [1.7.4-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: gnome-music (bionic-proposed/universe) [3.26.1-1 => 3.26.1-2] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- New binary: totem-pl-parser [armhf] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: totem-pl-parser [arm64] (bionic-proposed/main) [3.26.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libservicelog (bionic-proposed/main) [1.1.18-0ubuntu2 => 1.1.18-1] (core) (sync)
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [amd64] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [armhf] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [ppc64el] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [arm64] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [s390x] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted totem-pl-parser [i386] (bionic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (bionic-proposed) [3.26.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted libservicelog [sync] (bionic-proposed) [1.1.18-1]
-queuebot:#ubuntu-release- Unapproved: kamailio (bionic-proposed/universe) [4.4.2-3ubuntu5 => 5.0.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.1.30-dfsg-1 => 5.2.0-dfsg-1] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.1.30-2 => 5.2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.1.30-1 => 5.2.1-118452-1] (no packageset) (sync)
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/apport/lp-retracer-artful-updates-part-deux/+merge/332816
<acheronuk> autotests for kde4libs triigered on pkg-kde-tools have been running for over 10hrs and 7 hrs on armhf and amd64 respectively
<acheronuk> no recent change, so wonder if those are stuck?
-queuebot:#ubuntu-release- Unapproved: accepted kamailio [source] (bionic-proposed) [5.0.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (bionic-proposed) [5.2.1-118452-1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (bionic-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.0-dfsg-1]
-queuebot:#ubuntu-release- Unapproved: tome (bionic-proposed/multiverse) [2.4~0.git.2015.12.29-1.2 => 2.4~0.git.2015.12.29-1.2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [ppc64el] (bionic-proposed/universe) [5.0.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tome [source] (bionic-proposed) [2.4~0.git.2015.12.29-1.2build1]
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-proposed/universe) [5.5.2-4ubuntu2 => 5.5.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: kamailio [i386] (bionic-proposed/universe) [5.0.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.26.1-0ubuntu3 => 3.26.1-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: kamailio [amd64] (bionic-proposed/universe) [5.0.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kamailio [amd64] (bionic-proposed) [5.0.4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kamailio [ppc64el] (bionic-proposed) [5.0.4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kamailio [i386] (bionic-proposed) [5.0.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adacgi (bionic-proposed/universe) [1.6-19.1ubuntu1 => 1.6-20] (no packageset) (sync)
<xnox> infinity, did you not open up the queue?
-queuebot:#ubuntu-release- Unapproved: camlidl (bionic-proposed/universe) [1.05-15 => 1.05-15build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: camlzip (bionic-proposed/universe) [1.06-2build1 => 1.06-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: facile (bionic-proposed/universe) [1.1.1-1build1 => 1.1.1-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hlins (bionic-proposed/universe) [0.39-22build1 => 0.39-22build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: camlp5 (bionic-proposed/universe) [7.01-1 => 7.01-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: findlib (bionic-proposed/universe) [1.7.1-2 => 1.7.1-2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cothreads (bionic-proposed/universe) [0.10-4 => 0.10-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mlgmp (bionic-proposed/universe) [20021123-19 => 20021123-19build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocaml-tools (bionic-proposed/universe) [20120103-4build2 => 20120103-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocamlbuild (bionic-proposed/universe) [0.10.1-1 => 0.10.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocamlwc (bionic-proposed/universe) [0.3-13build1 => 0.3-13build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: perl4caml (bionic-proposed/universe) [0.9.5-5build1 => 0.9.5-5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pycaml (bionic-proposed/universe) [0.82-15 => 0.82-15build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: z3 (bionic-proposed/universe) [4.4.1-0.3build3 => 4.4.1-0.3build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocamlagrep (bionic-proposed/universe) [1.0-12 => 1.0-12build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocamlweb (bionic-proposed/universe) [1.39-5build1 => 1.39-5build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xml-light (bionic-proposed/universe) [2.4-1 => 2.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocamlpam (bionic-proposed/universe) [1.1-5 => 1.1-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: polygen (bionic-proposed/universe) [1.0.6.ds2-16 => 1.0.6.ds2-16build1] (no packageset)
<xnox> bah
<wxl> why isn't bionic on packages.u.c yet?
<xnox> wxl, because bionic is not open yet, and maybe packages.u.c requires a manual config change and redeploy
<wxl> ah not open yet ok!
-queuebot:#ubuntu-release- Unapproved: bitmeter (bionic-proposed/universe) [1.2-3.1ubuntu2 => 1.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qmmp (bionic-proposed/universe) [1.1.6-1.1ubuntu2 => 1.1.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-mapnik (bionic-proposed/universe) [3.6.2+dfsg-1 => 3.6.2+dfsg-1build1] (no packageset)
<xnox> infinity, Laney - can we have autoaccept running for things that are without packageset at least?
-queuebot:#ubuntu-release- Unapproved: oce (bionic-proposed/universe) [0.17.2-2ubuntu2 => 0.18.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [2 => 10~ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (zesty-proposed/main) [2 => 10~ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [2 => 10~ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: totem (bionic-proposed/main) [3.26.0-0ubuntu1 => 3.26.0-0ubuntu2] (ubuntu-desktop)
<jbicha> ooh, webkitgtk doesn't build any more, maybe we should just remove it now ;)
-queuebot:#ubuntu-release- Unapproved: juju-core (zesty-proposed/main) [2.2.4-0ubuntu0.17.04.1 => 2.2.6-0ubuntu0.17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: glewlwyd (bionic-proposed/universe) [1.1-2ubuntu1 => 1.2.2-1] (no packageset) (sync)
#ubuntu-release 2017-10-27
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.2.4-0ubuntu0.16.04.1 => 2.2.6-0ubuntu0.16.04.1] (ubuntu-server)
<tsimonq2> xnox, wxl: Yep, I'll ping Rhonda to ask about getting that updated...
<balloons> juju-core 2.26 is in the queue now, juju-core 2.24 upload can be rejected
<tsimonq2> Oh hey balloons :)
<balloons> hey tsimonq2
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2017b-2 => 2017c-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: apertium (bionic-proposed/universe) [3.4.2~r68466-1ubuntu1 => 3.4.2~r68466-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libalog (bionic-proposed/universe) [0.5.2-2ubuntu4 => 0.5.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: postgresql-multicorn (bionic-proposed/universe) [1.3.3-2ubuntu2 => 1.3.3-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: perf-tools-unstable (bionic-proposed/universe) [0.0.1~20160212+git0c13e83-2ubuntu2 => 1.0+git7ffb3fd-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: seqan2 (bionic-proposed/universe) [2.3.1+dfsg-5ubuntu2 => 2.3.2+dfsg2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php-doctrine-cache-bundle (bionic-proposed/universe) [1.3.0-4ubuntu1 => 1.3.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ruby-pathname2 (bionic-proposed/universe) [1.8.0-1ubuntu1 => 1.8.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pcs (bionic-proposed/universe) [0.9.159-3ubuntu2 => 0.9.160-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openscenegraph-3.4 (bionic-proposed/universe) [3.4.0+dfsg1-4ubuntu1 => 3.4.1+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: stenographer (bionic-proposed/universe) [0.0~git20161206.0.66a8e7e-5ubuntu1 => 0.0~git20161206.0.66a8e7e-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: grok (bionic-proposed/universe) [1.20110708.1-4.2ubuntu1 => 1.20110708.1-4.3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apache-log4j1.2 (bionic-proposed/universe) [1.2.17-7ubuntu2 => 1.2.17-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-mapnik [source] (bionic-proposed) [3.6.2+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ocamlagrep [source] (bionic-proposed) [1.0-12build1]
-queuebot:#ubuntu-release- Unapproved: accepted ocamlpam [source] (bionic-proposed) [1.1-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted ocamlweb [source] (bionic-proposed) [1.39-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted polygen [source] (bionic-proposed) [1.0.6.ds2-16build1]
-queuebot:#ubuntu-release- Unapproved: accepted xml-light [source] (bionic-proposed) [2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml-tools [source] (bionic-proposed) [20120103-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted ocamlwc [source] (bionic-proposed) [0.3-13build2]
-queuebot:#ubuntu-release- Unapproved: accepted pycaml [source] (bionic-proposed) [0.82-15build1]
-queuebot:#ubuntu-release- Unapproved: accepted ocamlbuild [source] (bionic-proposed) [0.10.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted z3 [source] (bionic-proposed) [4.4.1-0.3build4]
-queuebot:#ubuntu-release- Unapproved: accepted perl4caml [source] (bionic-proposed) [0.9.5-5build2]
-queuebot:#ubuntu-release- Unapproved: accepted camlidl [source] (bionic-proposed) [1.05-15build1]
-queuebot:#ubuntu-release- Unapproved: accepted camlzip [source] (bionic-proposed) [1.06-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted facile [source] (bionic-proposed) [1.1.1-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.26.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted mlgmp [source] (bionic-proposed) [20021123-19build1]
-queuebot:#ubuntu-release- Unapproved: accepted camlp5 [source] (bionic-proposed) [7.01-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted findlib [source] (bionic-proposed) [1.7.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (bionic-proposed) [2017c-1]
-queuebot:#ubuntu-release- Unapproved: accepted cothreads [source] (bionic-proposed) [0.10-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted hlins [source] (bionic-proposed) [0.39-22build2]
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.6 (zesty-proposed/universe) [5.6.34-26.19-0ubuntu1 => 5.6.34-26.19-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.5 (trusty-proposed/universe) [5.5.37-25.10+dfsg-0ubuntu0.14.04.4 => 5.5.37-25.10+dfsg-0ubuntu0.14.04.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.6 (xenial-proposed/universe) [5.6.34-26.19-0ubuntu0.16.04.1 => 5.6.34-26.19-0ubuntu0.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: clementine (bionic-proposed/universe) [1.3.1+git276-g3485bbe43+dfsg-1build1 => 1.3.1+git276-g3485bbe43+dfsg-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clementine [sync] (bionic-proposed) [1.3.1+git276-g3485bbe43+dfsg-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted adacgi [sync] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- Unapproved: accepted bitmeter [sync] (bionic-proposed) [1.2-4]
-queuebot:#ubuntu-release- Unapproved: accepted libalog [sync] (bionic-proposed) [0.5.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted qmmp [source] (bionic-proposed) [1.1.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted totem [source] (bionic-proposed) [3.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted apertium [sync] (bionic-proposed) [3.4.2~r68466-2]
-queuebot:#ubuntu-release- Unapproved: accepted oce [sync] (bionic-proposed) [0.18.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted glewlwyd [sync] (bionic-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (bionic-proposed) [5.5.2-6]
-queuebot:#ubuntu-release- Unapproved: accepted apache-log4j1.2 [sync] (bionic-proposed) [1.2.17-8]
-queuebot:#ubuntu-release- Unapproved: accepted openscenegraph-3.4 [sync] (bionic-proposed) [3.4.1+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted perf-tools-unstable [source] (bionic-proposed) [1.0+git7ffb3fd-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-multicorn [source] (bionic-proposed) [1.3.3-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted seqan2 [source] (bionic-proposed) [2.3.2+dfsg2-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grok [source] (bionic-proposed) [1.20110708.1-4.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted php-doctrine-cache-bundle [source] (bionic-proposed) [1.3.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted stenographer [sync] (bionic-proposed) [0.0~git20161206.0.66a8e7e-6]
-queuebot:#ubuntu-release- Unapproved: accepted pcs [sync] (bionic-proposed) [0.9.160-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-pathname2 [sync] (bionic-proposed) [1.8.0-2]
<LocutusOfBorg> hello, g morning, infinity can you please have a look at debhelper again? I'm pushing it right now
-queuebot:#ubuntu-release- Unapproved: debhelper (bionic-proposed/main) [10.10.4ubuntu1 => 10.10.5ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: adacgi [i386] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [ppc64el] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [amd64] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- Unapproved: keyutils (bionic-proposed/main) [1.5.9-9ubuntu1 => 1.5.9-9.1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: adacgi [s390x] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjdk-9 (bionic-proposed/universe) [9~b181-4 => 9.0.1+11-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: netcdf (bionic-proposed/universe) [1:4.4.1.1-2ubuntu1 => 1:4.5.0-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: asterisk (bionic-proposed/universe) [1:13.17.2~dfsg-1ubuntu1 => 1:13.17.2~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [arm64] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (bionic-proposed) [10.10.5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.9 (bionic-proposed/main) [1:3.9.1-17ubuntu1 => 1:3.9.1-18ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted keyutils [source] (bionic-proposed) [1.5.9-9.1ubuntu1]
-queuebot:#ubuntu-release- New binary: adacgi [armhf] (bionic-proposed/universe) [1.6-20] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted asterisk [source] (bionic-proposed) [1:13.17.2~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [source] (bionic-proposed) [9.0.1+11-1]
-queuebot:#ubuntu-release- Unapproved: accepted netcdf [sync] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- Unapproved: odil (bionic-proposed/universe) [0.8.0-3ubuntu3 => 0.8.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libsdl2 (bionic-proposed/universe) [2.0.6+dfsg1-3ubuntu1 => 2.0.6+dfsg1-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: netcdf [ppc64el] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
<cpaelzer> bdmurray: FYI on the SRU with the LP timeout yesterday I added the verification-needed tags
<cpaelzer> pending-sru overview seems happy, once HWE Team verified I'll check if it also recognizes the -done to be green then
-queuebot:#ubuntu-release- New binary: netcdf [amd64] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: netcdf [s390x] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: netcdf [i386] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-pkg-tools (bionic-proposed/universe) [0.19.11ubuntu1 => 0.19.12ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (bionic-proposed/universe) [1.12.3-1ubuntu1 => 1.12.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wine (bionic-proposed/universe) [2.0.2-2ubuntu1 => 2.0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mia (bionic-proposed/universe) [2.4.4-2ubuntu4 => 2.4.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: netcdf [arm64] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [ppc64el] (bionic-proposed/universe) [3.4.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netcdf [armhf] (bionic-proposed/universe) [1:4.5.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [s390x] (bionic-proposed/universe) [3.4.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: oce [s390x] (bionic-proposed/universe) [0.18.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted adacgi [amd64] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New: accepted adacgi [armhf] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New: accepted adacgi [s390x] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New: accepted netcdf [arm64] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted netcdf [i386] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted netcdf [s390x] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [ppc64el] (bionic-proposed) [3.4.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted adacgi [arm64] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New: accepted netcdf [amd64] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted netcdf [ppc64el] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [s390x] (bionic-proposed) [3.4.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted adacgi [i386] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New: accepted oce [s390x] (bionic-proposed) [0.18.2-2]
-queuebot:#ubuntu-release- New: accepted netcdf [armhf] (bionic-proposed) [1:4.5.0-1]
-queuebot:#ubuntu-release- New: accepted adacgi [ppc64el] (bionic-proposed) [1.6-20]
-queuebot:#ubuntu-release- New binary: oce [ppc64el] (bionic-proposed/universe) [0.18.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected sane-backends [source] (artful-proposed) [1.0.27-1~experimental2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gjs (bionic-proposed/main) [1.50.1-1 => 1.50.1-2] (desktop-extra, mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (artful-proposed) [1.0.27-1~experimental2ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: libguestfs (bionic-proposed/universe) [1:1.34.6-7ubuntu1 => 1:1.36.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [amd64] (bionic-proposed/universe) [3.4.1+dfsg1-1] (no packageset)
<LocutusOfBorg> jbicha, please mozjs52 sync? (fakesync sigh)
-queuebot:#ubuntu-release- Unapproved: ldc (bionic-proposed/universe) [1:1.4.0-3 => 1:1.4.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tilix (artful-proposed/universe) [1.6.4-2ubuntu1 => 1.6.4-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gtk-d (artful-proposed/universe) [3.6.6-1ubuntu1 => 3.6.6-1ubuntu2] (no packageset)
<LocutusOfBorg> please accept ldc and let it publish before tilix and gtk-d
-queuebot:#ubuntu-release- Unapproved: erlang (bionic-proposed/main) [1:20.0.4+dfsg-1ubuntu1 => 1:20.1.2+dfsg-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: openjdk-9 [ppc64el] (bionic-proposed/universe) [9.0.1+11-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adios (bionic-proposed/universe) [1.11.0-2build2 => 1.11.0-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cmor (bionic-proposed/universe) [3.2.5-2 => 3.2.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dx (bionic-proposed/universe) [1:4.4.4-10 => 1:4.4.4-10build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: eccodes (bionic-proposed/universe) [2.4.1-1 => 2.4.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: exodusii (bionic-proposed/universe) [6.02.dfsg.1-7 => 6.02.dfsg.1-7build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ffmpeg (bionic-proposed/universe) [7:3.3.4-2 => 7:3.3.4-2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: grace (bionic-proposed/universe) [1:5.1.25-5 => 1:5.1.25-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gdal (bionic-proposed/universe) [2.2.1+dfsg-2build3 => 2.2.1+dfsg-2build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: grads (bionic-proposed/universe) [3:2.1.1.b0-1 => 3:2.1.1.b0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gri (bionic-proposed/universe) [2.12.26-1 => 2.12.26-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grib-api (bionic-proposed/universe) [1.23.1-1 => 1.23.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: labplot (bionic-proposed/universe) [2.4.0-1ubuntu3 => 2.4.0-1ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libminc (bionic-proposed/universe) [2.3.00-3.1build1 => 2.3.00-3.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libpdl-netcdf-perl (bionic-proposed/universe) [4.20-5build2 => 4.20-5build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nco (bionic-proposed/universe) [4.6.8-1 => 4.6.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ncview (bionic-proposed/universe) [2.1.8+ds-1 => 2.1.8+ds-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: netcdf-cxx-legacy (bionic-proposed/universe) [4.2-7 => 4.2-7build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: netcdf-fortran (bionic-proposed/universe) [4.4.4+ds-2build1 => 4.4.4+ds-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: netcdf-cxx (bionic-proposed/universe) [4.3.0+ds-4 => 4.3.0+ds-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: netcdf4-python (bionic-proposed/universe) [1.2.9-1build2 => 1.2.9-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: octave-netcdf (bionic-proposed/universe) [1.0.11-1build1 => 1.0.11-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ruby-netcdf (bionic-proposed/universe) [0.7.2-1 => 0.7.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-ncdf4 (bionic-proposed/universe) [1.15-1build2 => 1.15-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rnetcdf (bionic-proposed/universe) [1.8-2-1build1 => 1.8-2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: v-sim (bionic-proposed/universe) [3.7.2-2 => 3.7.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: openjdk-9 [amd64] (bionic-proposed/universe) [9.0.1+11-1] (no packageset)
<LocutusOfBorg> jbicha, uploading fakesynced mozjs52 to ubuntu, will end up in unapproved
-queuebot:#ubuntu-release- Unapproved: mozjs52 (bionic-proposed/main) [52.3.1-0ubuntu3 => 52.3.1-7fakesync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-publicsuffixlist (bionic-proposed/universe) [0.1-9build6 => 0.1-9build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: esys-particle (bionic-proposed/universe) [2.3.5+dfsg1-2 => 2.3.5+dfsg1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haskell-publicsuffixlist (bionic-proposed/universe) [0.1-9build6 => 0.1-9build7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gr-fcdproplus (bionic-proposed/universe) [3.7.25.4b6464b-2build2 => 3.7.25.4b6464b-2build3] (no packageset)
-queuebot:#ubuntu-release- New: accepted openjdk-9 [ppc64el] (bionic-proposed) [9.0.1+11-1]
-queuebot:#ubuntu-release- New: accepted openjdk-9 [amd64] (bionic-proposed) [9.0.1+11-1]
-queuebot:#ubuntu-release- Unapproved: kicad (bionic-proposed/universe) [4.0.6+dfsg1-1 => 4.0.6+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-casacore (bionic-proposed/universe) [2.1.2-4build1 => 2.1.2-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-image-common (bionic-proposed/universe) [1.11.11-2 => 1.11.11-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-opencv-apps (bionic-proposed/universe) [1.11.14-1build1 => 1.11.14-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: progressivemauve (bionic-proposed/universe) [1.2.0+4713-3 => 1.2.0+4713-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-nodelet-core (bionic-proposed/universe) [1.9.8-1 => 1.9.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-geometry (bionic-proposed/universe) [1.11.8-4 => 1.11.8-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-robot-model (bionic-proposed/universe) [1.12.6-1 => 1.12.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted esys-particle [source] (bionic-proposed) [2.3.5+dfsg1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-publicsuffixlist [source] (bionic-proposed) [0.1-9build7]
-queuebot:#ubuntu-release- Unapproved: witty (bionic-proposed/universe) [3.3.6+dfsg-1.1build1 => 3.3.6+dfsg-1.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: yade (bionic-proposed/universe) [2017.01a-9 => 2017.01a-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gr-fcdproplus [source] (bionic-proposed) [3.7.25.4b6464b-2build3]
-queuebot:#ubuntu-release- Unapproved: woo (bionic-proposed/universe) [1.0+dfsg1-1ubuntu7 => 1.0+dfsg1-1ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-rviz (bionic-proposed/universe) [1.12.4+dfsg-2 => 1.12.4+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kicad [source] (bionic-proposed) [4.0.6+dfsg1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted progressivemauve [source] (bionic-proposed) [1.2.0+4713-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rnetcdf [source] (bionic-proposed) [1.8-2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted ros-image-common [source] (bionic-proposed) [1.11.11-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-opencv-apps [source] (bionic-proposed) [1.11.14-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted ros-rviz [source] (bionic-proposed) [1.12.4+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted witty [source] (bionic-proposed) [3.3.6+dfsg-1.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted yade [source] (bionic-proposed) [2017.01a-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted mozjs52 [source] (bionic-proposed) [52.3.1-7fakesync1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-geometry [source] (bionic-proposed) [1.11.8-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-robot-model [source] (bionic-proposed) [1.12.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted woo [source] (bionic-proposed) [1.0+dfsg1-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted python-casacore [source] (bionic-proposed) [2.1.2-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted v-sim [source] (bionic-proposed) [3.7.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ros-nodelet-core [source] (bionic-proposed) [1.9.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (bionic-proposed) [1.50.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (bionic-proposed) [1:1.36.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [source] (bionic-proposed) [1.12.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mia [sync] (bionic-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-pkg-tools [source] (bionic-proposed) [0.19.12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (bionic-proposed) [2.0.6+dfsg1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (bionic-proposed) [2.0.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ldc [source] (bionic-proposed) [1:1.4.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted odil [sync] (bionic-proposed) [0.8.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted adios [source] (bionic-proposed) [1.11.0-2build3]
-queuebot:#ubuntu-release- Unapproved: accepted dx [source] (bionic-proposed) [1:4.4.4-10build1]
-queuebot:#ubuntu-release- Unapproved: accepted erlang [source] (bionic-proposed) [1:20.1.2+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ffmpeg [source] (bionic-proposed) [7:3.3.4-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted grace [source] (bionic-proposed) [1:5.1.25-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted gri [source] (bionic-proposed) [2.12.26-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted labplot [source] (bionic-proposed) [2.4.0-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted libpdl-netcdf-perl [source] (bionic-proposed) [4.20-5build3]
-queuebot:#ubuntu-release- Unapproved: mia (bionic-proposed/universe) [2.4.4-2ubuntu4 => 2.4.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cmor [source] (bionic-proposed) [3.2.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted exodusii [source] (bionic-proposed) [6.02.dfsg.1-7build1]
-queuebot:#ubuntu-release- Unapproved: accepted grads [source] (bionic-proposed) [3:2.1.1.b0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libminc [source] (bionic-proposed) [2.3.00-3.1build2]
-queuebot:#ubuntu-release- Unapproved: accepted eccodes [source] (bionic-proposed) [2.4.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted grib-api [source] (bionic-proposed) [1.23.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gdal [source] (bionic-proposed) [2.2.1+dfsg-2build4]
-queuebot:#ubuntu-release- Unapproved: accepted nco [source] (bionic-proposed) [4.6.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ncview [source] (bionic-proposed) [2.1.8+ds-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted netcdf-cxx [source] (bionic-proposed) [4.3.0+ds-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted netcdf4-python [source] (bionic-proposed) [1.2.9-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ncdf4 [source] (bionic-proposed) [1.15-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted netcdf-cxx-legacy [source] (bionic-proposed) [4.2-7build1]
-queuebot:#ubuntu-release- Unapproved: accepted octave-netcdf [source] (bionic-proposed) [1.0.11-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted netcdf-fortran [source] (bionic-proposed) [4.4.4+ds-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-netcdf [source] (bionic-proposed) [0.7.2-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected haskell-publicsuffixlist [source] (bionic-proposed) [0.1-9build7]
-queuebot:#ubuntu-release- Unapproved: accepted mia [source] (bionic-proposed) [2.4.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.9 [source] (bionic-proposed) [1:3.9.1-18ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [amd64] (bionic-proposed) [3.4.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted oce [ppc64el] (bionic-proposed) [0.18.2-2]
-queuebot:#ubuntu-release- Unapproved: libguestfs (bionic-proposed/universe) [1:1.34.6-7ubuntu1 => 1:1.36.10-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pjproject (bionic-proposed/universe) [2.6~dfsg-2 => 2.7~dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: openjdk-9 [i386] (bionic-proposed/universe) [9.0.1+11-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcre-ocaml (bionic-proposed/universe) [7.2.3-2 => 7.2.3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ocaml-gettext (bionic-proposed/universe) [0.3.7-1 => 0.3.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: blends (bionic-proposed/universe) [0.6.100ubuntu1 => 0.6.100ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted openjdk-9 [i386] (bionic-proposed) [9.0.1+11-1]
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu20 => 229-4ubuntu21] (core)
<xnox> tjaalton, slangasek - due to regression-updates, i want ^ to be published all the way into -updates today
<xnox> !regression-updates
<ubot5> xnox: I am only a bot, please don't think I'm intelligent :)
<xnox> !regression
<xnox> !updates-regression
<ubot5> xnox: I am only a bot, please don't think I'm intelligent :)
 * xnox thought there was a command for that at one point
<apw> xnox, i can review that systemd if that helps
<xnox> apw, yes please.
<xnox> apw, it's two lines =)
<apw> of course it still takes launchpad a week to make a diff :)
<doko> infinity: slangasek: I think we can turn off manual approval now, most of the icu and boost stuff is built (at least tried to build)
<xnox> https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch
<xnox> https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch
<xnox> apw ^
<doko> and maybe turn on auto syncs, so that we can make use of the weekend time
<xnox> \o/
<Ukikie> !search regression
<ubot5> Found: pamerror, intel*, regression-alert*
<xnox> ah
<xnox> Ukikie, thank you =)
<xnox> !regression-alert
<ubot5> xnox: I am only a bot, please don't think I'm intelligent :)
<xnox> sigh
<Ukikie> xnox: '*' means deleted.
-queuebot:#ubuntu-release- Unapproved: accepted blends [source] (bionic-proposed) [0.6.100ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ocaml-gettext [source] (bionic-proposed) [0.3.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pjproject [sync] (bionic-proposed) [2.7~dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (bionic-proposed) [1:1.36.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pcre-ocaml [source] (bionic-proposed) [7.2.3-2build1]
<xnox> Ukikie, oooooo, right. because we stopped doing that. I think last time i used that command, it tried to ping people who no longer are on the sru team =)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21]
<apw> xnox, ^
<xnox> apw, whoop whoop, thank you =)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (bionic-proposed/universe) [5.9.1+dfsg-5ubuntu2 => 5.212.0~alpha2-3] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [sync] (bionic-proposed) [5.212.0~alpha2-3]
<apw> slangasek, this distro-info-data update in xenial seems to depend on a version of juju-core we are unlikley to have in xenial, isn't that version only a snap ?
<apw> s/depend on/breaks against/
<apw> ditto for zesty
<apw> oh in zesty we do now at least have a 2.26 coming ... ok then i'll ignore it for a bit
<cascardo> xnox: can you tell me the bug number that update fixes?
<sil2100> cjwatson: hey, could you switch off bionic's 'pre-release freeze'? I guess this requires a higher power ;)
<xnox> cascardo, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301
<ubot5> Ubuntu bug 1727301 in systemd (Ubuntu Xenial) "229-4ubuntu20 added ARP option breaks existing bonding interfaces" [Critical,Fix committed]
<cjwatson> sil2100: should be able to - are relevant folks agreed that the toolchain setup is done?
<Ukikie> I just got a mail from doko that the archive was open, so guess so. :3
<cjwatson> doko: what was the queue item you were unable to accept?
<cjwatson> doko: Oh, I guess you worked around it by accepting one at a time.  I was hoping you'd leave them in the queue so that I could see what difference my latest patch makes.
<sil2100> cjwatson: doko mentioned it's good to go, infinity we last saw him was basically only waiting on doko IIRC
<cjwatson> sil2100: OK, done
<sil2100> Thanks, hopefully I didn't cause the world to explode!
<sil2100> infinity: ^
<apw> seems we have a pkgstripfiles wedge in https://launchpad.net/ubuntu/+source/gnome-software/3.26.1-0ubuntu4/+build/13630494 who owns that thing now
<doko> cjwatson, sil2100: ta
<LocutusOfBorg> sorry, did I read "archive open"?
<sil2100> LocutusOfBorg: well...
 * LocutusOfBorg looks at topic
<apw> it also says artful ...
<LocutusOfBorg> indeed, the artful archive is indeed closed :p
* sil2100 changed the topic of #ubuntu-release to: 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
<sil2100> ...I guess that's correctish now?
-queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.2 => 2.8.0-1ubuntu1~16.04.3] (no packageset)
<Ukikie> LocutusOfBorg: https://lists.ubuntu.com/archives/kubuntu-devel/2017-October/011480.html yeeep.
<sil2100> doko: thanks for sending out the announce!
<LocutusOfBorg> thanks for fixing!
<LocutusOfBorg> please drop gtk-d and tilix from artful unapproved queue
<LocutusOfBorg> we discussed, and ended up that artful is not worth fixing
-queuebot:#ubuntu-release- Unapproved: dnsmasq (xenial-proposed/main) [2.75-1ubuntu0.16.04.3 => 2.75-1ubuntu0.16.04.4] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dnsmasq (zesty-proposed/main) [2.76-5ubuntu0.1 => 2.76-5ubuntu0.2] (ubuntu-desktop, ubuntu-server)
<jbicha> doko: did you send the announcement to ubuntu-devel too?
<LocutusOfBorg> WTF? qtwebkit-opensource-src -> 	5.212.0~alpha2-3
<LocutusOfBorg> mitya57, ^^ did you use a wrong versioning?
-queuebot:#ubuntu-release- New binary: duktape [amd64] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [s390x] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [ppc64el] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [i386] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-evdev [amd64] (bionic-proposed/universe) [0.7.0+dfsg-2] (no packageset)
<apw> LocutusOfBorg, that is the version in debian, well -4 ... dunno if that helps
<doko> jbicha: -devel-discuss
-queuebot:#ubuntu-release- Unapproved: rejected gtk-d [source] (artful-proposed) [3.6.6-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected tilix [source] (artful-proposed) [1.6.4-2ubuntu2]
<apw> LocutusOfBorg, ^
-queuebot:#ubuntu-release- New: accepted duktape [amd64] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted duktape [ppc64el] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted python-evdev [amd64] (bionic-proposed) [0.7.0+dfsg-2]
-queuebot:#ubuntu-release- New binary: libgit2 [ppc64el] (bionic-proposed/universe) [0.26.0+dfsg.1-1.1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted duktape [i386] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New binary: libgit2 [amd64] (bionic-proposed/universe) [0.26.0+dfsg.1-1.1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted duktape [s390x] (bionic-proposed) [2.2.0-2]
<xnox> slangasek, if you will be comfortable releasing this https://bugs.launchpad.net/systemd/+bug/1727301 without aging today, i would appreciate it. It is regression-updates, the fix is 2 one-liners.
<ubot5> Ubuntu bug 1727301 in systemd (Ubuntu Xenial) "229-4ubuntu20 added ARP option breaks existing bonding interfaces" [Critical,Fix committed]
-queuebot:#ubuntu-release- New binary: libgit2 [i386] (bionic-proposed/universe) [0.26.0+dfsg.1-1.1] (kubuntu)
<jbicha> doko: all I see is the kubuntu-devel list
<apw> slangasek, that fix looks very tight and contained and obviously broken, it should be relativly low risk
<rbasak> It's also Friday  :-/
<apw> so it is, when did that happen
 * rbasak fixes the tag to the well-defined 'regression-update'
 * apw is sure it is still wednesday
-queuebot:#ubuntu-release- New binary: duktape [armhf] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [arm64] (bionic-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webpy [amd64] (bionic-proposed/universe) [1:0.38+20170615-1] (no packageset)
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu5]
-queuebot:#ubuntu-release- New binary: libgit2 [armhf] (bionic-proposed/universe) [0.26.0+dfsg.1-1.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [arm64] (bionic-proposed/universe) [0.26.0+dfsg.1-1.1] (kubuntu)
<acheronuk> LocutusOfBorg: qtwebkit-opensource-src is versioned like that, as it's a revival of the old source from here I think? https://gitlab.com/paretje/qtwebkit/tags
<LocutusOfBorg> so 5.12 will have a lower version wrt the current one
-queuebot:#ubuntu-release- New binary: sambamba [i386] (bionic-proposed/universe) [0.6.6-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: sambamba [amd64] (bionic-proposed/universe) [0.6.6-1build1] (no packageset)
-queuebot:#ubuntu-release- New sync: pspp (bionic-proposed/primary) [1.0.1-1]
<rbasak> I just happened to notice that wget probably wants copying forward to bionic. Is there any effort planned to catch all such occurances?
-queuebot:#ubuntu-release- New binary: liblouis [amd64] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [s390x] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [ppc64el] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [i386] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (trusty-proposed) [10~ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (zesty-proposed) [10~ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (xenial-proposed) [10~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: liblouis [arm64] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
<infinity> doko: Want to bounce your opening announcement to ubuntu-devel-announce, where it belongs? :)
<infinity> rbasak: We can do an archive diff to catch them one time, but the real answer is that SRUs shouldn't be accepted without bionic uploads superseding them *or* a commitment from someone involved to copy forward.
<infinity> rbasak: We're long past the "oh, whatever, Adam might copy it" stage.
<infinity> Ahh, but that was a security update
<infinity> Which means mdeslaur should be on the hook.
<infinity> rbasak: As for "< rbasak> It's also Friday", the whole reason we don't release on Fridays is so we don't have to deal with regressions over the weekend.  Seems obtuse to extend that rule to an update that is explicitly fixing a regression, no?
-queuebot:#ubuntu-release- New: accepted libgit2 [amd64] (bionic-proposed) [0.26.0+dfsg.1-1.1]
-queuebot:#ubuntu-release- New: accepted libgit2 [armhf] (bionic-proposed) [0.26.0+dfsg.1-1.1]
-queuebot:#ubuntu-release- New: accepted libgit2 [ppc64el] (bionic-proposed) [0.26.0+dfsg.1-1.1]
-queuebot:#ubuntu-release- New: accepted libgit2 [arm64] (bionic-proposed) [0.26.0+dfsg.1-1.1]
-queuebot:#ubuntu-release- New: accepted libgit2 [i386] (bionic-proposed) [0.26.0+dfsg.1-1.1]
-queuebot:#ubuntu-release- New: accepted pspp [sync] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted sambamba [i386] (bionic-proposed) [0.6.6-1build1]
-queuebot:#ubuntu-release- New: accepted sambamba [amd64] (bionic-proposed) [0.6.6-1build1]
-queuebot:#ubuntu-release- New binary: liblouis [armhf] (bionic-proposed/main) [3.3.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted liblouis [amd64] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted liblouis [armhf] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted liblouis [ppc64el] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted liblouis [arm64] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted liblouis [s390x] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted liblouis [i386] (bionic-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted webpy [amd64] (bionic-proposed) [1:0.38+20170615-1]
-queuebot:#ubuntu-release- New: accepted duktape [arm64] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted duktape [armhf] (bionic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New binary: libgit2-glib [s390x] (bionic-proposed/universe) [0.26.0-3] (no packageset)
<jbicha> infinity: how do we forward-copy from artful to bionic? since bionic only opened recently there are several artful SRUs that aren't in bionic yet
<infinity> jbicha: copy-package --from-suite=artful-updates --to-suite=bionic-proposed -b $package
<infinity> s/updates/proposed/ as necessary.
<jbicha> that works, the -b wasn't obvious to me
<infinity> Thankfully, without the -b, it'll just be rejected.
<infinity> So, no harm learning. :P
<rbasak> infinity: to be clear, I didn't intend that to be a -1. Just an unfortunate day for this to happen.
<infinity> xnox: Good job submitting an MP with merg conflict markers in it. :)
<rbasak> I'm told LP does that intentionally. If the proposed branch doesn't merge, the conflicts are intentionally shown.
<LocutusOfBorg> a lot of stuff failed for ENOSPACE on autopkgtests
<LocutusOfBorg> retrying it
<jbicha> please reject ubuntu-meta 1.405/artful, re-uploading with a SRU version number
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (artful-proposed/main) [1.404 => 1.404.1] (core)
<infinity> jbicha: Done.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (artful-proposed) [1.405]
<slangasek> apw: right, wrt distro-info-data there's an SRU in the queue already for juju-core 2.2.6 (and 2.2.4 is what's currently in -proposed)
-queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (xenial-proposed) [2.2.4-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- New binary: fwupd [ppc64el] (bionic-proposed/main) [1.0.0-4] (desktop-core)
-queuebot:#ubuntu-release- New binary: libgit2-glib [ppc64el] (bionic-proposed/universe) [0.26.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgit2-glib [i386] (bionic-proposed/universe) [0.26.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [ppc64el] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: fwupd [s390x] (bionic-proposed/main) [1.0.0-4] (desktop-core)
-queuebot:#ubuntu-release- New binary: libgit2-glib [amd64] (bionic-proposed/universe) [0.26.0-3] (no packageset)
<apw> slangasek, yeah there is in zesty, but i didn't see it (then at least) in xenial
-queuebot:#ubuntu-release- New binary: fwupd [amd64] (bionic-proposed/main) [1.0.0-4] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [i386] (bionic-proposed/main) [1.0.0-4] (desktop-core)
<slangasek> infinity: the friday rule means we only release on friday if someone is willing to be on the hook for handling regressions over the weekend; and it's not like we've never had a regression in an upload that fixed a regression ;)  in this case I'm happy to release and be on the hook for regressions once I've reviewed the delta myself, or else someone else can release it
<infinity> slangasek: Well, yes.  Not telling me anything I don't know, given I instituted the rule. :)
-queuebot:#ubuntu-release- New binary: libgit2-glib [arm64] (bionic-proposed/universe) [0.26.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [armhf] (bionic-proposed/main) [1.0.0-4] (desktop-core)
-queuebot:#ubuntu-release- New binary: opencv [s390x] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2-glib [armhf] (bionic-proposed/universe) [0.26.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [arm64] (bionic-proposed/main) [1.0.0-4] (desktop-core)
<infinity> LocutusOfBorg: Thanks for undoing all the autopkgtest progress I'd made on debhelper. :P
-queuebot:#ubuntu-release- New sync: flatpak-builder (bionic-proposed/primary) [0.10.1-1]
<tsimonq2> \o/ open
<infinity> LocutusOfBorg: Also, I notice in backscroll that you mentioned it when I was indeed awake and around, but you highlighted me mid-line, so I didn't see it.
<infinity> LocutusOfBorg: I only highlight first-word mentions because, well, common English word nick.
<slangasek> xnox: ohhh but you misspelled 'unconditionally' in the changelog, not sure I can release that on a Friday
<ogra_> lol
<infinity> slangasek: Did he spell it with a Russian accent?
-queuebot:#ubuntu-release- New binary: opencv [i386] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
<slangasek> infinity: unkyondyitsyonally?
<infinity> Da.
-queuebot:#ubuntu-release- New binary: opencv [amd64] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- Packageset: Added budgie-desktop to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- New binary: casablanca [i386] (bionic-proposed/universe) [2.10.0-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: language-selector (artful-proposed/main) [0.180 => 0.180.1] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- Packageset: Added arc-theme to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-artwork to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-desktop to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-desktop-environment to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-indicator-applet to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-wallpapers to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-welcome to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added faba-icon-theme to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added moka-icon-theme to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added rhythmbox-plugin-alternative-toolbar to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added slick-greeter to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added ubuntu-budgie-meta to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added arc-theme to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added budgie-artwork to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added budgie-desktop-environment to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added budgie-indicator-applet to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added budgie-wallpapers to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added budgie-welcome to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added faba-icon-theme to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added moka-icon-theme to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added rhythmbox-plugin-alternative-toolbar to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added slick-greeter to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- Packageset: Added ubuntu-budgie-meta to personal-fossfreedom in bionic
-queuebot:#ubuntu-release- New binary: casablanca [amd64] (bionic-proposed/universe) [2.10.0-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [armhf] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: fontforge [amd64] (bionic-proposed/universe) [1:20170731~dfsg-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: casablanca [armhf] (bionic-proposed/universe) [2.10.0-1~build1] (no packageset)
<xnox> slangasek, infinity - so the new movie out uses D instead of A in the title, and it pisses me off.
<slangasek> the... new... movie?
<xnox> slangasek, https://cdn.flickeringmyth.com/wp-content/uploads/2017/08/death-of-stalin-poster-featured-600x385.jpg
<slangasek> oh, haha
<xnox> slangasek, also are you serious about not releasing systemd? because you don't think it's that bad... or because friday?
<slangasek> xnox: I didn't say I wouldn't release it, I was simply challenging the claim that we shouldn't follow the friday rule when in fact we should follow the friday rule to completion
-queuebot:#ubuntu-release- New binary: opencv [arm64] (bionic-proposed/universe) [3.2.0+dfsg-3] (kubuntu)
<doko> infinity: it waits for moderator approval ...
<infinity> doko: Oh, I read above where you said you sent to -discuss, so didn't even look.
<infinity> doko: Looks like someone moderated it.
<infinity> (Probably Steve)
<slangasek> notme
<infinity> Well, someone. :P
<infinity> Cause there it is.
 * infinity goes back to the ICU transition.
 * infinity looks at the java vomit in the openjfx log and dies a little inside.
<infinity> Ahh, maybe the java vomit is a red herring, and it's the C++ vomit I want.  I can deal with that.
<jbicha> infinity: can we remove webkitgtk?
<infinity> jbicha: I want to say yes just because webkit.  How is the rdep situation?
<infinity> Still gnucash.
<infinity> So still no, I think.
<infinity> slangasek: Any idea if there's been movement on porting gnucash to something less ancient? (I was told you're one of the users)
<slangasek> there is a new upstream version of gnucash that fixes this; I may have thrown some packaging patches into the Debian BTS about it
<jbicha> are you feeling lucky? because there's an alpha of gnucash now https://github.com/Gnucash/gnucash/releases
<slangasek> I was originally looking at it to fix a ftbfs though, so when I found the new upstream version *didn't* fix the ftbfs, I stashed that work until post-artful
<infinity> slangasek: Want to take said patches and roll a -0ubuntu1 release?  It might help us over some humps.
<infinity> Oh, less helpful if it'll just FTBFS.
<slangasek> nah, I fixed the ftbfs
<slangasek> I just had hoped it was fixed upstream and it wasn't
<infinity> Story of my life.
<jbicha> LP: #1710318 is the tracking bug for webkit
<ubot5> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
<slangasek> I'm not desperately enthusiastic about switching it to the new upstream version and being on the hook for it when I don't have time to test it myself
<slangasek> but the patches are https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790204
<ubot5> Debian bug 790204 in src:gnucash "gnucash: depends on libwebkitgtk-1.0-0 which is deprecated" [Serious,Open]
<infinity> Thank you, yet another opaque build system, for not showing me your compiler commandlines.
<infinity> Oh lord, and this is Yet Another Copy of Webkit.
<infinity> WHY.
<slangasek> whatnow?
<infinity> openjfx
<infinity> Embedded webkit.
<infinity> Because of course it is.
<slangasek> ah
<jbicha> Fedora 27 bundles the old webkit in their gnucash pkg
<infinity> Which means the icu transition is, I think, reduced to nothing but webkit failures.  Across 4 packages.
<infinity> Good thing none of these take 6 hours per build iteration or anything.
<infinity> OH WAIT.
<jbicha> Debian is also killing qtwebengine-opensource-src so hopefully we can get rid of that this cycle too
<infinity> qtwebkit-opensource-src went from 5.9.1 to 5.212.0?
<infinity> I wonder what the 212 represents.
<LocutusOfBorg> represents... ehi 5.10 is out now, lets bump EPOCH!
<mitya57> LocutusOfBorg, infinity: it is a maintained semi-official fork of qtwebkit
<mitya57> See https://github.com/annulen/webkit/releases/
<LocutusOfBorg> 5.9.212 was so bad?
<infinity> mitya57: That didn't really answer "why 212", but also don't care. :)
<LocutusOfBorg> we are discussing the fact that 212 is >> of 10
<mitya57> I think 212 means that it matches webkitgtk 2.12. But I am not really sure :)
<infinity> And the webkitgtk build log is 649MB.  This can't be good.
<mitya57> And it is >> 10 on purpose, because until the last release Qt provided their own mostly-no-change releases.
<dax> every other web-related software is increasing version quickly, maybe they decided to go up all at once so they wouldn't need to play catchup for a few years :)
<infinity> Heh.
<mitya57> jbicha: Debian is not killing qtwebengine-opensource-src. We are killing src:qtwebkit which is src:qtwebkit-source in Ubuntu.
<infinity> "Firefox 56?  Chrome 62?  AMATEURS.  We're 212!"
<nacc> not confusing at all, mitya57 :)
<LocutusOfBorg> :)
<infinity> Okay, I think the hack I used for firebird3.0 will also fix openjfx and webkitgtk, I just have to figure out where to inject it in the ludicrous webkit build process.
<mitya57> In Qt world, there are qtwebkit, qtwebengine, qtwebchannel, qtwebsockets and qtwebview. Sometimes it is difficult to not confuse them :)
<jbicha> mitya57: thanks
-queuebot:#ubuntu-release- New: accepted fwupd [amd64] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted fwupd [armhf] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted fwupd [ppc64el] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted fwupd [arm64] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted fwupd [s390x] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted fwupd [i386] (bionic-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [amd64] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [armhf] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [ppc64el] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [arm64] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [s390x] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted libgit2-glib [i386] (bionic-proposed) [0.26.0-3]
-queuebot:#ubuntu-release- New: accepted fontforge [amd64] (bionic-proposed) [1:20170731~dfsg-1]
-queuebot:#ubuntu-release- New: accepted opencv [arm64] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [i386] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [s390x] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [amd64] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [ppc64el] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [armhf] (bionic-proposed) [3.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [sync] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- Unapproved: accountsservice (artful-proposed/main) [0.6.42-0ubuntu3 => 0.6.42-0ubuntu3.1] (personal-gunnarhj, ubuntu-desktop)
<slangasek> should I expect to see new packages auto-syncing now from Debian?  AIUI this should be step 30 on https://wiki.ubuntu.com/NewReleaseCycleProcess
<slangasek> infinity: ^^ I see an uncommented cronjob, but I also see the word '--dry-run'
<slangasek> is that fix-the-instructions territory?
<infinity> slangasek: Are we ready to enable it?  I thought we wanted to migrate icu first, before it gets tangled up in whatever auto-sync might pull into the mess.
<infinity> slangasek: But yes, disabling/enabling is adding and removing "--dry-run".
<slangasek> infinity: I don't know if we are ready; I know you've had me do steps much further down this list and I have no visibility on a checklist of what's considered done or not
<slangasek> infinity: and I thought I saw doko comment that we were ready
<infinity> Well, he said "maybe". :)
<infinity> I think I want to push icu through, since it's only a few packages off.
<slangasek> ok
<tsimonq2> Any objections to kicking off the Qt 5.9.2 transition within the next 24-48 hours?
<slangasek> is gnucash critical path on that?
<infinity> slangasek: And yeah, the checklist "order" gets fuzzy after the first 15 or 20, and the rest is really "do in parallel as people have time".
<infinity> slangasek: No, gnucash shouldn't be critical path (if my webkitgtk fix works, which is testbuilding right now).
<slangasek> right, parallelizing is cool, I just wish we had an actual checklist
<slangasek> it's not a checklist if I can't check things off it ;)
<infinity> tsimonq2: No objections to qt 5.9.2 immediately after icu migrates.  That's one that definitely entangles.
<infinity> slangasek: I agree with that.  I'd love a simple way to take the wiki as a template into a checklisty thing where we can sign-off on steps.
<tsimonq2> infinity: Ack, I'll hold off until then.
<infinity> slangasek: Which would also make it easier to record "this step is obsolete", and batch edit them all at once at the end.
<slangasek> infinity: I bet we have folks on the team who could automate turning it into a checklist on a trello card
<infinity> slangasek: I'd prefer something public.
<infinity> And not Trello.
<infinity> But whatever. :P
<slangasek> there are public trello boards around
<slangasek> anyway, creating a private trello card to request automatic creation of public trello cards
<slangasek> enjoy
<infinity> Hahaha.
-queuebot:#ubuntu-release- Unapproved: websockify (xenial-proposed/universe) [0.6.1+dfsg1-1 => 0.6.1+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New sync: ocaml-gen (bionic-proposed/primary) [0.4.0.1-2]
<nacc> slangasek: infinity: i had uploaded a MRE of php7.1 to artful last week, but given that it's not accepted yet, would it be better to reject it from https://launchpad.net/ubuntu/artful/+queue?queue_state=1&queue_text= and let me reupload with a proper SRU version (and upload to bionic at the same time)? Or is it appropriate to wait for that upload to be accepted and the copy-forward? There appears to
<nacc> have been a bionic-only no change rebuild now, so perhaps the copy-forward would be wrong for that reason as well
<slangasek> nacc: yes, copy-forward over a no-change rebuild would be naughty
<nacc> slangasek: yeah
<nacc> slangasek: ok, can you reject it from artful then?
<nacc> (unapproved queue)
<slangasek> nacc: done
<nacc> slangasek: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected php7.1 [source] (artful-proposed) [7.1.10-0ubuntu1]
<LocutusOfBorg> who wants to do some ocaml gaming? I did some bits
-queuebot:#ubuntu-release- New binary: capnproto [s390x] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: capnproto [amd64] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: capnproto [ppc64el] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: capnproto [i386] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: capnproto [arm64] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: capnproto [armhf] (bionic-proposed/main) [0.6.1-1] (desktop-core, ubuntu-server)
<bdmurray> slangasek, infinity: My kid just reminded about the lock screen shortcut change. Where are the release notes would that belong? "Known Issue" that we won't fix?
<slangasek> bdmurray: perhaps https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes#Ubuntu_Desktop
<slangasek> I wouldn't call a deliberate behavior change a 'known issue'
-queuebot:#ubuntu-release- New: accepted capnproto [amd64] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted capnproto [armhf] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted capnproto [ppc64el] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted capnproto [arm64] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted capnproto [i386] (bionic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted capnproto [s390x] (bionic-proposed) [0.6.1-1]
<jbicha> bdmurray: I believe the Ubuntu Desktop team considers that a bug as we'd like to support both keyboard shortcuts for the lock screen, you can use LP: #1389650
<ubot5> Launchpad bug 1389650 in gnome-shell (Ubuntu) "Ctrl+Alt+L fails to lock the screen in the default setup of Gnome 3 (gnome shell)" [Medium,Triaged] https://launchpad.net/bugs/1389650
<bdmurray> Ah, so known issue then
<jbicha> GNOME currently only supports having one keyboard shortcut for that action
<bdmurray> Well, it doesn't seem like it'd get SRU'ed though
<jbicha> it can still be a known bug even if it's not sru'd :)
-queuebot:#ubuntu-release- Unapproved: php7.1 (artful-proposed/main) [7.1.8-1ubuntu1 => 7.1.10-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: flatpak-builder [amd64] (bionic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flatpak-builder [s390x] (bionic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flatpak-builder [ppc64el] (bionic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New source: fscrypt (bionic-proposed/primary) [0.2.2-0ubuntu1]
<tyhicks> doko: hi - I removed the explicit architecture list from fscrypt and uploaded it to bionic ^
-queuebot:#ubuntu-release- New binary: flatpak-builder [i386] (bionic-proposed/universe) [0.10.1-1] (no packageset)
<tyhicks> doko: I never heard any details on what was wrong with the "missing copyright holders" issue that you listed when rejecting it for artful so I didn't make any changes there
<tyhicks> doko: also, infi nity gave it a quick look and didn't spot anything wrong with debian/copyright
-queuebot:#ubuntu-release- New sync: postgresql-10 (bionic-proposed/primary) [10.0-1]
-queuebot:#ubuntu-release- New binary: flatpak-builder [armhf] (bionic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flatpak-builder [arm64] (bionic-proposed/universe) [0.10.1-1] (no packageset)
#ubuntu-release 2017-10-28
-queuebot:#ubuntu-release- New binary: uhd [s390x] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [ppc64el] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [i386] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [amd64] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [arm64] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [armhf] (bionic-proposed/universe) [3.10.2.0-2] (no packageset)
<slangasek> xnox: so what's the deal with systemd/xenial/s390x failing every time in the past 2 days?
<acheronuk> slangasek or anyone else; is it possible to get existing qtwebkit 5.9.1+dfsg-5ubuntu1 rebuilt against the new qtdeclarative 5.9.1-6ubuntu1 upload? even though there is a qtwebkit 5.212.0~alpha2-4 dep waiting in proposed against Qt 5.9.2?
<acheronuk> the ABI bump in that qtdeclarative upload has left a lot of KDE/Qt build and test dependencies unsatisfiable
<infinity> acheronuk: Yeah, I was looking at removing that 5.212.0 upload for other reasons.
<infinity> acheronuk: But the real question is if 5.9.1 will build against icu95 (guessing not without patching, but we'll see)
<infinity> s/95/59/
<infinity> On the flipside, it seems I've just fixed one webkit variant for that, so what's three moe?
<acheronuk> aha. if that can work, good. at the moment I can't even test build our most basic frameworks dependency, extra-cmake-modules :/
 * infinity grabs a build log from 5.9.1+dfsg-5ubuntu2 to see why it failed.
<infinity> Oh, FFS, it just failed due to symbols issues (likely relating to that ABI bump you were talking about).
<infinity> If that's true on all 6 arches, I'll just pull in the symbols changes and reupload.
 * acheronuk hopes so
<infinity> Hrm.  Except it built against an old qtdeclarative, so that's not what caused the change.
<infinity> God, I hate trying to decipher C++ symbols.
<infinity> acheronuk: Kay, going to throw this at my staging PPA, and if it actually works, copy it over.
<infinity> Confidence++
<acheronuk> cool. hoping
<infinity> s390x builds pretty quickly, so I'll know soonish.
<infinity> Unless I fall asleep. :P
<acheronuk> qttools5-dev-tools : Depends: libqt5webkit5 (>= 5.6.0~rc) but it is not going to be installed
<acheronuk> libqt5webkit5 : Depends: qtdeclarative-abi-5-9-0
 * acheronuk rolls eyes
<infinity> Oh, FFS, it can't build?
<infinity> The qtdeclarative upload seems to have been poorly thought out.
<acheronuk> plus maybe a bit pointless as a Qt 5.9.2 transition is imminent
<infinity> Yeah, I think I'll just delete this.
<infinity> The 5.9.2 transition will overwrite it.
<infinity> Alternately, it could be replaced with a version that provides both those virtual packages.
<infinity> But it still needs to be deleted in order to build that new upload.
<infinity> Because lol circular deps.
<acheronuk> that circular dep issue is likely resolved with bootstrapping more Qt builds with 'nodoc' builds 1st, as will likely happen with the full transition
<infinity> Probably.  Right now, I'm in no mood to have this random broken package holding up my ICU transition and the archive opening.
<infinity> So deleted.
<acheronuk> ok. thanks for sorting :)
<infinity> s/archive opening/auto-sync enabling/
<infinity> It should go poof from ftpmaster in half an hour or so.
 * acheronuk goes to make more coffee (morning here)
<infinity> Erm, and I should kill all these builds.
<infinity> Before they get a dep on the wrong thing.
<infinity> My local webkitgtk build is 2.5 hours in, which is 50 minutes longer than I've managed before, that must be a good sign.
<infinity> Or it's a sign that my laptop is dying and going half as slow as it was this morning.
-queuebot:#ubuntu-release- New: accepted flatpak-builder [amd64] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [armhf] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [ppc64el] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted uhd [amd64] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [armhf] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [ppc64el] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [arm64] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [s390x] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted uhd [i386] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New: accepted flatpak-builder [i386] (bionic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted uhd [s390x] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [arm64] (bionic-proposed) [3.10.2.0-2]
-queuebot:#ubuntu-release- New binary: boinc [amd64] (bionic-proposed/universe) [7.8.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: boinc [i386] (bionic-proposed/universe) [7.8.3+dfsg-2] (no packageset)
<infinity> slangasek: Deleting your postgresql-common from -proposed for now.  It sort of depends on a new psql.
<infinity> slangasek: Which doesn't exist yet.
<infinity> slangasek: Feel free to copy --force-same-destination over itself when it's actually sane to do so.
-queuebot:#ubuntu-release- New binary: gnuradio [ppc64el] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [s390x] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [i386] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [amd64] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: remmina [amd64] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [ppc64el] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [i386] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [s390x] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [armhf] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [arm64] (bionic-proposed/main) [1.2.0-rcgit.24-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnuradio [armhf] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: casablanca [ppc64el] (bionic-proposed/universe) [2.10.0-1~build2] (no packageset)
-queuebot:#ubuntu-release- New: rejected casablanca [amd64] (bionic-proposed) [2.10.0-1~build1]
-queuebot:#ubuntu-release- New: rejected casablanca [i386] (bionic-proposed) [2.10.0-1~build1]
-queuebot:#ubuntu-release- New: rejected casablanca [armhf] (bionic-proposed) [2.10.0-1~build1]
-queuebot:#ubuntu-release- New binary: casablanca [amd64] (bionic-proposed/universe) [2.10.0-1~build2] (no packageset)
-queuebot:#ubuntu-release- New binary: casablanca [i386] (bionic-proposed/universe) [2.10.0-1~build2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [arm64] (bionic-proposed/universe) [3.7.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: casablanca [armhf] (bionic-proposed/universe) [2.10.0-1~build2] (no packageset)
-queuebot:#ubuntu-release- New binary: casablanca [arm64] (bionic-proposed/universe) [2.10.0-1~build2] (no packageset)
<teward> is Bionic open for uploads and such yet?
<LocutusOfBorg> infinity, ^^ ready to go (casablanca)
 * LocutusOfBorg does some syncs before the world explodes
-queuebot:#ubuntu-release- New binary: plplot [s390x] (bionic-proposed/universe) [5.13.0+dfsg-6] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [amd64] (bionic-proposed/universe) [5.13.0+dfsg-6] (no packageset)
<slangasek> teward: yes: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html
-queuebot:#ubuntu-release- New binary: plplot [i386] (bionic-proposed/universe) [5.13.0+dfsg-6] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [arm64] (bionic-proposed/universe) [5.13.0+dfsg-6] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [armhf] (bionic-proposed/universe) [5.13.0+dfsg-6] (no packageset)
<tsimonq2> infinity: Question with your AA hat on. Let's say package foo needs to go through NEW, but has some upstream copyright issues. If those were solved in upstream, but upstream won't tag for months if not years from now, is it acceptable to cherry pick the commit changing the license to one that can go in the archive, or do I have to use a whole Git snapshot?
<jbicha> slangasek: (or anyone) please bump the flatpak badtest for ppc64el
<infinity> tsimonq2: Copyright is very much about intent and will of the authors, so if they say the new license covers things retroactively (which is implied if they change the license without otherwise changing the content), cherry-pick away.
<infinity> tsimonq2: If they "fix" the license by, say, removing problematic code/files, you'll need to repack to follow suit.
<infinity> tsimonq2: I can't think of many situations where you'd need a whole new snapshot just to fix the license.
<tsimonq2> infinity: No, they just do a license change to make it more permissive (no removing of files), so I'll cherry pick and go from there then.
<tsimonq2> infinity: Thank you for the clarification.
-queuebot:#ubuntu-release- New binary: debian-science [amd64] (bionic-proposed/universe) [1.7ubuntu1] (no packageset)
<tsimonq2> infi/win 44
<tsimonq2> Whoooooooops
 * tsimonq2 plans on doing an LXQt transition immediately following the Qt transition, fwiw
 * tsimonq2 also wonders how long it will take src:icu to migrate, but won't complain
<infinity> tsimonq2: icu is tied up with netcdf, so any help you want to lend there won't go amiss.
<infinity> tsimonq2: Also, I had to delete an upload of yours that made pretty much all things Qt uninstallible.
<infinity> tsimonq2: qtdeclarative-opensource-src changed the provides, which broke all the rdeps.  Need to be a bit more careful on merges like that.
<infinity> (But I imagine it all becomes moot with 5.9.2 anyway)
<tsimonq2> infinity: Yes, Rik pinged me on Telegram this morning and I realized that the qtdeclarative upload was probably a bad idea.
<tsimonq2> infinity: And you're right.
<tsimonq2> infinity: I'll see what I can do to poke that, if there is anything I CAN do.
 * tsimonq2 shakes head at src:blender
<tsimonq2> "Build killed with signal TERM after 150 minutes of inactivity"
#ubuntu-release 2017-10-29
-queuebot:#ubuntu-release- New source: peruse (bionic-proposed/primary) [1.2-0ubuntu1]
<tsimonq2> infinity: For the record, src:peruse is that package with the interesting copyright we discussed earlier.
<tsimonq2> I personally did a copyright review after applying the patch and it looks sane.
<tsimonq2> For whoever does the review, I'm eager to see how I did (irt copyright review).
<slangasek> jbicha: done
<slangasek> jbicha: why syncing postgresql-10 in advance of autosyncs being enabled?
-queuebot:#ubuntu-release- New: accepted boinc [amd64] (bionic-proposed) [7.8.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [amd64] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [armhf] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [ppc64el] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New: accepted plplot [amd64] (bionic-proposed) [5.13.0+dfsg-6]
-queuebot:#ubuntu-release- New: accepted plplot [armhf] (bionic-proposed) [5.13.0+dfsg-6]
-queuebot:#ubuntu-release- New: accepted plplot [s390x] (bionic-proposed) [5.13.0+dfsg-6]
-queuebot:#ubuntu-release- New: accepted boinc [i386] (bionic-proposed) [7.8.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [i386] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New: accepted plplot [arm64] (bionic-proposed) [5.13.0+dfsg-6]
-queuebot:#ubuntu-release- New: accepted gnuradio [arm64] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New: accepted plplot [i386] (bionic-proposed) [5.13.0+dfsg-6]
-queuebot:#ubuntu-release- New: accepted gnuradio [s390x] (bionic-proposed) [3.7.11-2]
-queuebot:#ubuntu-release- New binary: gearmand [s390x] (bionic-proposed/universe) [1.1.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gearmand [ppc64el] (bionic-proposed/universe) [1.1.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gearmand [i386] (bionic-proposed/universe) [1.1.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gearmand [amd64] (bionic-proposed/universe) [1.1.17-2] (no packageset)
<jbicha> slangasek: why sync postgresql-common 187 without postgresql-10 ? ;)
-queuebot:#ubuntu-release- New binary: gearmand [arm64] (bionic-proposed/universe) [1.1.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gearmand [armhf] (bionic-proposed/universe) [1.1.17-2] (no packageset)
<jbicha> pg-common was removed but at the time, it was one way to fix pg-common being uninstallable
<slangasek> jbicha: because that was a merge->forcesync, and frankly I didn't look at the installability until after it was in... makes sense that it was causing problems though
<slangasek> shall I go ahead and reject the manual sync in favor of the impending autosync?
<jbicha> if you want, it's not too important to me either way
<slangasek> infinity: I see icu isn't done yet; does that block turning on autosyncing still?
-queuebot:#ubuntu-release- New: rejected postgresql-10 [sync] (bionic-proposed) [10.0-1]
<slangasek> xnox: boost1.65 is blocked by component-mismatches because libboost1.65-doc depends on libjs-mathjax; MIR, or demote the docs?
<infinity> slangasek: We already have:
<infinity> supported: * Extra-Exclude: libboost-*-dev libboost*-all-dev
<infinity> Adding libboost-doc to that wouldn't seem too awful.
<infinity> slangasek: As for the autosync versus icu, the last ICU build is almost done.  If we enable autosync, we'll entangle ICU in a half dozen other transitions.
<infinity> So, eh.
<slangasek> infinity: right
<slangasek> I've demoted libboost1.65-doc to unblock the transition; it'll spring back up in c-m
<slangasek> then we can decide whether to Extra-Excludes it
<infinity> slangasek: Did you demote the meta too?
<slangasek> y (just now)
<infinity> Kay.  Then I shan't. :)
<slangasek> xnox: I see unity-scopes-api (used by url-dispatcher) ftbfs (in artful also) and will block boost; do you have any insight on that one?  There's LP: #1718254 but that hasn't moved
<ubot5> Launchpad bug 1718254 in unity-scopes-api (Ubuntu Artful) "please drop url-dispatcher dependencies" [Critical,New] https://launchpad.net/bugs/1718254
-queuebot:#ubuntu-release- New sync: jbuilder (bionic-proposed/primary) [1.0~beta14-1]
<LocutusOfBorg> ^^ I need it for ocaml transition
-queuebot:#ubuntu-release- New: accepted gearmand [amd64] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New: accepted gearmand [armhf] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New: accepted gearmand [ppc64el] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New: accepted jbuilder [sync] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted gearmand [arm64] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New: accepted gearmand [s390x] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New: accepted gearmand [i386] (bionic-proposed) [1.1.17-2]
-queuebot:#ubuntu-release- New binary: jbuilder [amd64] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jbuilder [armhf] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jbuilder [ppc64el] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jbuilder [arm64] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jbuilder [s390x] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jbuilder [i386] (bionic-proposed/universe) [1.0~beta14-1] (no packageset)
<LocutusOfBorg> and also casablanca please, so I can no change rebuild poedit
-queuebot:#ubuntu-release- New: accepted casablanca [amd64] (bionic-proposed) [2.10.0-1~build2]
-queuebot:#ubuntu-release- New: accepted casablanca [armhf] (bionic-proposed) [2.10.0-1~build2]
-queuebot:#ubuntu-release- New: accepted casablanca [ppc64el] (bionic-proposed) [2.10.0-1~build2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [sync] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted remmina [arm64] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [i386] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [s390x] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted casablanca [arm64] (bionic-proposed) [2.10.0-1~build2]
-queuebot:#ubuntu-release- New: accepted debian-science [amd64] (bionic-proposed) [1.7ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [armhf] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted casablanca [i386] (bionic-proposed) [2.10.0-1~build2]
-queuebot:#ubuntu-release- New: accepted remmina [ppc64el] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [amd64] (bionic-proposed) [1.2.0-rcgit.24-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted jbuilder [amd64] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted jbuilder [armhf] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted jbuilder [ppc64el] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted jbuilder [arm64] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted jbuilder [s390x] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New: accepted jbuilder [i386] (bionic-proposed) [1.0~beta14-1]
-queuebot:#ubuntu-release- New binary: ocaml-gen [ppc64el] (bionic-proposed/none) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-gen [s390x] (bionic-proposed/none) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-gen [amd64] (bionic-proposed/none) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-gen [i386] (bionic-proposed/none) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-gen [armhf] (bionic-proposed/universe) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-gen [arm64] (bionic-proposed/universe) [0.4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-gen [amd64] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [armhf] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [ppc64el] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [arm64] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [s390x] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-gen [i386] (bionic-proposed) [0.4.0.1-2]
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [i386] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [amd64] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [ppc64el] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [ppc64el] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [i386] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [s390x] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [amd64] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [i386] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [arm64] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [armhf] (bionic-proposed/universe) [3.7.25.4b6464b-5] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [s390x] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [arm64] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [armhf] (bionic-proposed/universe) [0.37.2-10] (no packageset)
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (bionic-proposed) [2017.1.0-4]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [arm64] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [ppc64el] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [amd64] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [armhf] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [ppc64el] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New binary: dolfin [armhf] (bionic-proposed/universe) [2017.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [amd64] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [s390x] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [i386] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [armhf] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [s390x] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [arm64] (bionic-proposed) [0.37.2-10]
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (bionic-proposed) [2017.1.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (bionic-proposed) [2017.1.0-4]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [i386] (bionic-proposed) [3.7.25.4b6464b-5]
-queuebot:#ubuntu-release- New: accepted dolfin [i386] (bionic-proposed) [2017.1.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (bionic-proposed) [2017.1.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [armhf] (bionic-proposed) [2017.1.0-4]
<infinity> slangasek, xnox: Managed a stay of execution on unity-scopes-api by building with g++-6, but we definitely want to get some movement on fixing that dep chain sooner rather than later in the cycle.
-queuebot:#ubuntu-release- New binary: gr-hpsdr [ppc64el] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [amd64] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [s390x] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-hpsdr [i386] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [ppc64el] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-hpsdr [s390x] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-hpsdr [amd64] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [i386] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-hpsdr [armhf] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-hpsdr [arm64] (bionic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [arm64] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [armhf] (bionic-proposed/universe) [3.7.0.2.7b6b996-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [ppc64el] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [s390x] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [amd64] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [i386] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [armhf] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [arm64] (bionic-proposed/universe) [3.7.0.2.a542331-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-fosphor [amd64] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [armhf] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [ppc64el] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [amd64] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [armhf] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [ppc64el] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-rds [amd64] (bionic-proposed) [3.7.0.2.a542331-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [armhf] (bionic-proposed) [3.7.0.2.a542331-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [ppc64el] (bionic-proposed) [3.7.0.2.a542331-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [arm64] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [s390x] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [i386] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-rds [arm64] (bionic-proposed) [3.7.0.2.a542331-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [s390x] (bionic-proposed) [3.7.0.2.a542331-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [i386] (bionic-proposed) [3.7.0.2.7b6b996-2]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [s390x] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-hpsdr [arm64] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted gr-rds [i386] (bionic-proposed) [3.7.0.2.a542331-2]
<LocutusOfBorg> slangasek, did you accept boinc? can you please move the boinc-virtualbox package to multiverse so it can find virtualbox?
<LocutusOfBorg> or any other AA :)
<infinity> LocutusOfBorg: You have a package whose only purpose is to add a user to a group?
<LocutusOfBorg> and to force installation of virtualbox
<LocutusOfBorg> from oracle or ubuntu
<LocutusOfBorg> it has been requested by CERN people, for LHC@home
<LocutusOfBorg> boinc talks with virtualbox, downloads a pre-built image with the custom software, and runs scientific apps inside
<LocutusOfBorg> automagically
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- New binary: etcd [ppc64el] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: etcd [s390x] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: etcd [i386] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: etcd [armhf] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: etcd [arm64] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: etcd [amd64] (bionic-proposed/universe) [3.2.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [amd64] (bionic-proposed/universe) [2.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [ppc64el] (bionic-proposed/universe) [2.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [i386] (bionic-proposed/universe) [2.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [s390x] (bionic-proposed/universe) [2.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [arm64] (bionic-proposed/universe) [2.11.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypre [armhf] (bionic-proposed/universe) [2.11.2-2] (no packageset)
<acheronuk> infinity: would me uploading KDE frameworks and the few days of shepherding that through proposed mess with anything crucial? ICU say?
-queuebot:#ubuntu-release- New: accepted etcd [amd64] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted etcd [armhf] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted etcd [ppc64el] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hypre [amd64] (bionic-proposed) [2.11.2-2]
-queuebot:#ubuntu-release- New: accepted hypre [armhf] (bionic-proposed) [2.11.2-2]
-queuebot:#ubuntu-release- New: accepted hypre [ppc64el] (bionic-proposed) [2.11.2-2]
-queuebot:#ubuntu-release- New: accepted etcd [arm64] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted etcd [s390x] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hypre [i386] (bionic-proposed) [2.11.2-2]
-queuebot:#ubuntu-release- New: accepted etcd [i386] (bionic-proposed) [3.2.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hypre [s390x] (bionic-proposed) [2.11.2-2]
-queuebot:#ubuntu-release- New: accepted hypre [arm64] (bionic-proposed) [2.11.2-2]
#ubuntu-release 2018-10-22
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.6-2 => 1.0.9-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (bionic-proposed/main) [4.18.0-1003.3~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (bionic-proposed) [4.18.0-1003.3~18.04.1]
<sil2100> Laney: hey! If anything, I'm looking into the spamming ADT cloud-worker-maintenance script
<Laney> sil2100: didn't see that yet (been avoiding email), but merci!
<Laney> good trip back?
<sil2100> Laney: yeah, wasn't bad, Luton was just really really crowded
<sil2100> Laney: how was the beer festival?
<sil2100> ;)
<sil2100> Trevinho: https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1743373/comments/7 <- re: ubuntu-themes SRU
<ubot5> Ubuntu bug 1743373 in ubuntu-themes (Ubuntu Bionic) "Combobox arrow and color are inverted" [Undecided,Fix committed]
<Laney> NO IDEA!
<sil2100> Trevinho: (this concerns many of the bugs marked in the upload)
<sil2100> Laney: oh? I thought you were supposed to a beer festival after release
<sil2100> Did I mix it up?
<Laney> sil2100: was joking about the beer :P
<Laney> nah, I did go and it was good fun
<sil2100> Phew
<sil2100> coreycb: hey! Could you look at the verification of LP: #1751396 and LP: #1783654 as per Brian's request?
<ubot5> Launchpad bug 1751396 in neutron (Ubuntu Bionic) "DVR: Inter Tenant Traffic between two networks and connected through a shared network not reachable with DVR routers" [Critical,Fix committed] https://launchpad.net/bugs/1751396
<ubot5> Launchpad bug 1783654 in neutron (Ubuntu Bionic) "DVR process flow not installed on physical bridge for shared tenant network" [Critical,Fix committed] https://launchpad.net/bugs/1783654
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (xenial-proposed) [0.2.31ubuntu2]
<sil2100> juliank: hey! Regarding the networkd-dispatcher SRU: the contents itself look good, but one thing I'd need from the formal SRU POV is a bit more about the impact of the 'bug
<sil2100> juliank: since basically this SRU introduces a new feature from what I see, as it's adding the feature of allowing overriding of /usr/lib/networkd-dispatcher scripts, right?
<juliank> sil2100: yes, since we quickly hacked together /usr support before the release
<juliank> it was /etc first, we quickly patched it to /usr to be able to release with hooks, now we're patching /etc back in
<sil2100> juliank: so for things like this, we'd like to see a rationale why it's needed, what is 'busted' right now without it, you know, rationale why this feature is needed as an SRU
<sil2100> juliank: oh, this is exactly the rationale I need
<sil2100> Can you include the mention of this in the impact field?
<juliank> sil2100: updated
<sil2100> juliank: accepted, thanks o/
<juliank> sil2100: thx
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: magnum (bionic-proposed/universe) [6.1.0-0ubuntu1 => 6.1.1-0ubuntu0.18.04.1] (no packageset)
<juliank> Oj, I just noticed the bug title had curly braces and brackets mixed {SRU]
<juliank> silly title typo
 * juliank goes verify
<sil2100> It's fiiiine
<Trevinho> sil2100: ouch, sorry for the verifications -_-
<Trevinho> sil2100: I was using the bileto ppa version probably...
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (bionic-proposed) [2.56.3-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (cosmic-proposed/main) [3.6.6-1 => 3.6.7-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (bionic-proposed/main) [3.6.5-3 => 3.6.7-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.1~rc2-1 => 3.7.1-1~18.10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.0-1~18.04 => 3.7.1-1~18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python3.6 (cosmic-proposed/main) [3.6.7~rc1-1 => 3.6.7-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.18-dfsg-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.6-1~18.04 => 3.6.7-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.18-dfsg-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (bionic-proposed) [5.2.18-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (bionic-proposed) [5.2.18-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu3 => 2.3.0-0ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.7 => 1.34.0-0ubuntu8.8] (no packageset)
<coreycb> sil2100: yes will do
-queuebot:#ubuntu-release- Unapproved: valgrind (bionic-proposed/main) [1:3.13.0-2ubuntu2 => 1:3.13.0-2ubuntu2.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: yaru-theme (cosmic-proposed/main) [18.10.6 => 18.10.7] (ubuntu-desktop)
<ddstreet> are all autopkgtests blocked by freeze right now?
<Laney> no
<Laney> but there is no non-frozen release atm
<Laney> (for uploads)
<ddstreet> all releases are frozen?
<apw> all stable releases are always frozen, and we have no development release
<ddstreet> what i meant is that all release autopkgtest excuses are showing "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<Laney> that is better plain english, thanks
<ddstreet> which i'm surprised to see
<apw> ddstreet, which is normal for a status in a stable release
<Laney> that means there is a block in the hint file, not related to testing
<apw> ddstreet, it is saying it won't consider releaseing it, nothing more
<Laney> it doesn't actually matter since SRUs aren't released with proposed-migration anyway
<ddstreet> ok guess i never noticed that before
<Laney> actually, even if they were you'd still see that message and there would be a corresponding unblock
<apw> that indeed
<Laney> usually you don't see it because https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html points to the development release and that is rarely frozen at this level
<ddstreet> yep, i'll stick to using the pending sru summary :)
<oSoMoN> hello release team, https://launchpad.net/ubuntu/+source/chromium-browser/70.0.3538.67-0ubuntu1 went into cosmic-proposed after final freeze but before release, is it going to migrate to cosmic-updates once it's open, or should it be re-uploaded by the security team to -security as is normally done for chromium updates?
<teward> so I have a basic question, is i386 essentially dead now after 18.04?  I.E. 18.10 and such won't have upgrade paths for it?
<mdeslaur> teward: you can dist-upgrade to it
<mdeslaur> and you can still install from the mini iso
<teward> mdeslaur: hmm, that's what i thought
<teward> (I'm tracking Lubuntu stuff since I"m sorta helping with their infra, so some things i saw there made me head-scratch :P)
<teward> thanks
<bdmurray> mdeslaur: You can't dist upgrade to 18.10 if you are on i386 with ubuntu-release-upgrader.
<bdmurray> teward: ^^
<bdmurray> infinity: I don't have SRU queue powers for cosmic yet.
<mdeslaur> bdmurray: that's good to know, thanks
<teward> bdmurray: that's what i thought.
<teward> bdmurray: so the upgrade path then from 18.04 -> 18.10 for i386 was disabled then, and that includes d-r-u?
<teward> which then begs the question: have we killed off i386 yet :p
<wxl> for everyone except xubuntu and lubuntu
<wxl> but if we keep making decisions like that without telling anyone, then probably yes for them too :/
<bdmurray> teward: We haven't decided about killing off i386 yet but if we do decide to we didn't want to leave these users on a short term release like 18.10. Its in the release notes.
<acheronuk> ^ that makes sense, and I think was discussed in here at some point
<teward> anyone know if snapd is now part of all the images?
<teward> not just Ubuntu but everything?
<jbicha> teward: it's in all *desktop* images: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/desktop-common#n120
<teward> jbicha: 'all' Desktop images for all flavors?
<teward> or just Ubuntu desktop images?
<jbicha> it wasn't in Lubuntu 18.04 LTS because Lubuntu was special and didn't install recommends
<teward> what about 18.10?
<jbicha> in the seed at least
<jbicha> snapd is in Lubuntu 18.10
<teward> wxl: ^
<teward> you can go tell simon to start whining while you're at it wxl
<teward> ... but in here :P
<teward> (not really but still)
<jbicha> Lubuntu has shifted its focus a bit so maybe snapd being pre-installed isn't as worrying for the devs as it was a few months ago
<teward> yeah... given the info I have about their latest discovery of it on the ISOs... not as 'worrying' as you'd think
<teward> not as 'not worrying'
<teward> but I'll let wxl explain that one :P
<teward> i have enoug hwork to do hardening their infra >.>
<jbicha> there was an attempt to blacklist it but that was pre-cosmic: https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/commit/?id=28a4a97461
<wxl> it's still there https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/tree/blacklist
<wxl> did that not work?
<wxl> i mean
<wxl> it obviously didn't XD
<wxl> but we should probably get rid of that if it's not actually possible
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.22-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.40.1~18.04.1 => 0.40.1~18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.40.2 => 0.40.2.1] (core)
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.2-0ubuntu0.18.04.1 => 2.9.2-0ubuntu0.18.04.2] (ubuntu-server)
#ubuntu-release 2018-10-23
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1028.29~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1028.29~14.04.1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.8 => 18.04.14.9] (core)
<seb128> soo, http://people.canonical.com/~ubuntu-archive/pending-sru.html has a big stack of "old" SRUs for cosmic, what's going on there. Was it because proposed was cleaned out before release? (does that usually happens?)
<apw> seb128, i assume you mean "was not cleaned out"
<apw> seb128, and it is normal that we open DD and then copy everything up, and then prune the non-sru things
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (xenial-proposed) [1.34.0-0ubuntu8.8]
<seb128> apw, indeed :/
<apw> seb128, which cannot happen without a DD to do it to
<seb128> ah ok
<seb128> so it's going to clear itself out
<seb128> good
<seb128> apw, thx
<Laney> yeah
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: oath-toolkit (cosmic-proposed/universe) [2.6.1-1.2 => 2.6.1-1.2ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (bionic-proposed/main) [3.28.1-0ubuntu1 => 3.28.1-0ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.2-0ubuntu7 => 3.30.2-0ubuntu8] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted secureboot-db [source] (bionic-proposed) [1.4~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted secureboot-db [source] (xenial-proposed) [1.4~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.9]
-queuebot:#ubuntu-release- Unapproved: accepted secureboot-db [source] (trusty-proposed) [1.4~ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.9]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (bionic-proposed) [2.9.2-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (bionic-proposed) [1:3.13.0-2ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.1-1~18.10]
<superm1> bdmurray, regarding the SRU bug 1791999 is there anything else missing to at least get this into proposed?  I'm getting daily reports on the problems fixed by this release.
<ubot5> bug 1791999 in fwupd (Ubuntu) "Update to the 1.0.9 release" [Undecided,In progress] https://launchpad.net/bugs/1791999
<bdmurray> superm1: The bugs seem okay, I'll review it now.
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (cosmic-proposed/main) [5.11.1+dfsg-7ubuntu1 => 5.11.1+dfsg-7ubuntu2] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.7-1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (bionic-proposed) [1.0.9-0ubuntu1]
<superm1> thanks
<superm1> blah. it's depwait on !x86
<superm1> fix incoming
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.9-0ubuntu1 => 1.0.9-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (bionic-proposed) [3.7.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (bionic-proposed) [3.6.7-1~18.04]
<superm1> bdmurray, sorry it went to depwait on ppc64el, s390x arm64, armhf due to a mistake when debian/control was regenerated.  I've just uploaded a fixed binary.  I'll test it after that's accepted
<bdmurray> superm1: for the sru tools / process to work you'll need the LaunchpadBugsFixed line in the .changes file
<superm1> bdmurray, Ah wasn't aware, OK i'll redo it again. sorry for the trouble
<infinity> bdmurray: Speaking of, I fixed ubuntu-sru queue permissions for cosmic.
<infinity> bdmurray: (Had to get my own permissions fixed first so I could use edit-acl...)
<bdmurray> infinity: great, thanks!
 * infinity goes back to not being here today.
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.9-0ubuntu1 => 1.0.9-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (bionic-proposed) [1.0.9-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (bionic-proposed) [1.0.9-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (cosmic-proposed) [3.2-21ubuntu2]
<superm1_> bdmurray, one of the bug reports has two uploads that contribute to fixing the bug (gnome-software and fwupd).  I marked verification-done since I tested the fwupd half of it, but it will require releasing the gnome-software half to fully validate, let me know if you want me to switch it back as a result
-queuebot:#ubuntu-release- Unapproved: accepted elfutils [source] (cosmic-proposed) [0.170-0.5.0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (cosmic-proposed) [3.0.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (cosmic-proposed) [4:5.13.5-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (bionic-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.40.1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (cosmic-proposed) [5.212.0~alpha2-12ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.40.2.1]
-queuebot:#ubuntu-release- Unapproved: accepted oath-toolkit [source] (cosmic-proposed) [2.6.1-1.2ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (bionic-proposed) [3.2-20ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (bionic-proposed) [1:1.5.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu6.16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (bionic-proposed) [3.3.0-1ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: rejected samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (bionic-proposed) [2.4.29-1ubuntu4.5]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (bionic-proposed) [3.28.0-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted exim4 [source] (bionic-proposed) [4.90.1-1ubuntu1.1]
<RAOF> Hah. I guess the cosmic-proposed report is not very useful for the moment :)
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-ext2 [source] (bionic-proposed) [0.4-1.1ubuntu0.18.04.1]
<xnox> RAOF, well, use your senses ;-)
<RAOF> :P
<valorie> so when do we start speculating on DD name?
<valorie> hard to top "cosmic"
<xnox> valorie, my bets are on Devout Doplhin or a Dirty Dog
<xnox> valorie, my bets are on Devout Dolphin or a Dirty Dog
<valorie> hmm
<valorie> dirty dingo is more exotic
<Bashing-om> Guess Dusty Dingbat is not even considered :P
<valorie> ha!
<valorie> does it have to be an animal? because Dirigible would be cool
<RAOF> Dirty Dauphin!
<RAOF> Hm. Is today the day that I process KDE out of the bionic-proposed queueâ¦
#ubuntu-release 2018-10-24
-queuebot:#ubuntu-release- Unapproved: kmod (cosmic-proposed/main) [25-1ubuntu1 => 25-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: kmod (bionic-proposed/main) [24-1ubuntu3 => 24-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: kmod (xenial-proposed/main) [22-1ubuntu5 => 22-1ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted breeze-gtk [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted drkonqi [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<mwhudson> RAOF: not sure if this makes you a saviour or a sucker
<RAOF> Hey, I never said I'd accept them out of -proposed :P
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected kmenuedit [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-pam [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<RAOF> There are so many kde packagesâ¦
<RAOF> â¦and some of them literally only change the version in CMakeLists.txt?
<teward> RAOF: welcome to KDE, population 5000000 inter-related and interdependent packages :P
<teward> and the tiniest change messes with EVERYTHING :P
-queuebot:#ubuntu-release- Unapproved: rejected libkscreen [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<mwhudson> i have wondered why there is not one enormous source package before now
-queuebot:#ubuntu-release- Unapproved: rejected plasma-desktop [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
<valorie> mwhudson: would that be preferable?
<mwhudson> i don't know tbh
<valorie> because our devels want to upload packages that *will* be accepted
<valorie> and it would have been great to have them in 18.10 of course
<valorie> we always got slammed for kde-libs that was a big ball
<valorie> so the devels spent over a year as I recall splitting them out
<RAOF> It's reasonable to have a whole bunch.
<RAOF> It's somewhat less reasonable to have some which are literal no-change rebuilds except for changing the version number in CMakeLists.
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
 * RAOF also questions the value of uploading a package for which the changes are â<commit: Foo>â followed by âRevert: <commit: Foo>â âº
<valorie> well, acheronuk should be here for this bit of the conversation
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth-kcm [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<mwhudson> <valorie> we always got slammed for kde-libs that was a big ball
<mwhudson> <valorie> so the devels spent over a year as I recall splitting them out
<mwhudson> heh oh well you can't win i guess
<mwhudson> ignore me :)
<valorie> well, slammed by users because pretty much every KDE package needed kde-libs
<valorie> now users only need the libs that the application actually needs
<valorie> but yeah, hard to win when we have a huge bunch of software to package and upload
 * RAOF looks sideways at some translation updates that appear to be replacing a translated string with English.
-queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<valorie> that doesn't sound right!
<RAOF> It's possible that the existing translation is just plain wrong, and English would be an improvementâ¦
<valorie> true
<RAOF> Hm.
<RAOF> It seems that for a couple of the packages quite a lot of Indonesian strings have been replaced with English.
<RAOF> acheronuk: It looks like a bunch of the KDE packages in bionic-unapproved have translation changes which replace Indonesian strings with English, and at least some of them look to me with my very old, highschool Indonesian to have been vaguely right translations.
<RAOF> acheronuk: I'll stop processing those packages untill I've got confirmation that's expected.
<RAOF> (Also I'll have a rather late lunch)
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [17.03.2-0ubuntu2~16.04.1 => 18.06.1-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libssh (cosmic-proposed/main) [0.8.1-1ubuntu0.1 => 0.8.1-1ubuntu0.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-39.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-39.42] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-39.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-39.42]
-queuebot:#ubuntu-release- Unapproved: figtree (bionic-proposed/universe) [1.4.3+dfsg-5 => 1.4.3+dfsg-5ubuntu0.1] (no packageset)
<oSoMoN> can an AA please delete chromium-browser 70.0.3538.67-0ubuntu1 from cosmic-proposed? version 70.0.3538.67-0ubuntu0.18.10.1, which is effectively the same, was already published to cosmic-updates and cosmic-security
-queuebot:#ubuntu-release- Unapproved: backuppc (trusty-proposed/main) [3.3.0-1ubuntu1 => 3.3.0-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: breeze (cosmic-proposed/universe) [4:5.13.5-0ubuntu2.1 => 4:5.13.5-0ubuntu2.2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: backuppc (xenial-proposed/main) [3.3.1-2ubuntu3.3 => 3.3.1-2ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (cosmic-proposed) [3.6.7-1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (bionic-proposed) [3.6.7-1~18.04]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-11.12]
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu2.2 => 2:4.7.6+dfsg~ubuntu-0ubuntu2.3] (core)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (cosmic-proposed/multiverse) [5.2.20-dfsg-1ubuntu18.10.1 => 5.2.20-dfsg-2ubuntu18.10.1] (no packageset)
<oSoMoN> sil2100, can you help with my earlier request to delete chromium-browser 70.0.3538.67-0ubuntu1 from cosmic-proposed?
<sil2100> oSoMoN: hey!
<sil2100> Ah, I see the rationale
<sil2100> Sure
<sil2100> oSoMoN: done
<oSoMoN> sil2100, thanks a bunch!
<sil2100> yw!
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1004.4] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.15]
-queuebot:#ubuntu-release- Unapproved: python3-defaults (cosmic-proposed/main) [3.6.6-1 => 3.6.7-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: python3-defaults (cosmic-proposed/main) [3.6.6-1 => 3.6.7-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected python3-defaults [source] (cosmic-proposed) [3.6.7-1~18.04]
-queuebot:#ubuntu-release- Unapproved: python3-defaults (bionic-proposed/main) [3.6.5-3ubuntu1 => 3.6.7-1~18.04] (core)
<vorlon> anyone know why bionic images are failing to build due to failure to resolve ubuntu-image dep of livecd-rootfs?
<vorlon> (I can't reproduce this problem locally)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (cosmic-proposed/multiverse) [5.2.20-dfsg-1ubuntu18.10.1 => 5.2.20-dfsg-2ubuntu18.10.1] (no packageset)
<xnox> vorlon, log?
<vorlon> xnox: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/lubuntu/+build/148328
<xnox> vorlon, i seem to be able to reproduce this in a bionic chroot.
<xnox> vorlon, sed 's/restricted universe multiverse//' -i /etc/apt/sources.list
<xnox> vorlon, apt update; apt install ubuntu-image
<vorlon> xnox: did that too already
<vorlon> wfm
<vorlon> did it fail for you?
<xnox> yes
<xnox> vorlon, which mirror are you using?
<xnox> vorlon, and is it related to an unreleased sru that doko mentioned this morning?!
<vorlon> oh, I didn't enable -proposed
 * sil2100 didn't break anything
<sil2100> Just saying
<vorlon> xnox: still can't trigger the failure here, with the roadmap sprint's proxy
<xnox> vorlon, ssh somewhere useful.
<vorlon> xnox: pastebin me
<xnox> vorlon, https://paste.ubuntu.com/p/3N2BqGBPqs/ somehow new python3 from updates is not installable, or something?!
<vorlon> ok
<xnox> vorlon, is lubuntu with or without proposed?
<vorlon> xnox: all with -proposed currently
<vorlon> except when we're in milestone prep
<xnox> vorlon, i declare python3-defaults have not been updated for the python point release.
<vorlon> ok
<vorlon> so this is doko's bug?
<xnox> vorlon, or python3-distutils and python3-lib2to3 should have lower deps.
<xnox> vorlon, probably
<xnox> vorlon, shouldn't like britney be telling us these things?
<vorlon> xnox: you mean like http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#python3-stdlib ?
<vorlon> sorry, you mean like http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#python3-stdlib-extensions ?
<xnox> vorlon, yes =)
<xnox> vorlon, doko, https://bugs.launchpad.net/ubuntu/+source/python3-stdlib-extensions/+bug/1799764
<ubot5> Ubuntu bug 1799764 in python3-stdlib-extensions (Ubuntu) "python3-lib2to3 is not installable with python3" [Undecided,New]
<xnox> vorlon, does germinate know how to use -updates pocket?
<xnox> vorlon, nevermind, it does, found it.
<xnox> vorlon, infinity - were there ever plans to make debootstrap support our "pockets"?
<xnox> and use them, when doing debootstrap similar to how it can deal with components?
<jbicha> xnox: are you familiar with sbuild-launchpad-chroot? those scripts may already sort of offer what you want (depending on what it is you are trying to do)
<xnox> jbicha, hhhmmm let me look.
<xnox> jbicha, nope no good.
<xnox> jbicha, this is for germinate.
<jbicha> well it's got an alias thing
<jbicha> oh, this is for schroot
<xnox> jbicha, germinate -> deboostrap, is my code path atm =) nothing to do with schroot/sbuild/etc.
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2018e-0ubuntu0.18.04 => 2018f-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2018e-0ubuntu0.14.04 => 2018f-0ubuntu0.14.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (cosmic-proposed/main) [2018e-1 => 2018f-0ubuntu0.18.10] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2018e-0ubuntu0.16.04 => 2018f-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (cosmic-proposed) [2018f-0ubuntu0.18.10]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2018f-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2018f-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2018f-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: cinder (cosmic-proposed/main) [2:13.0.0-0ubuntu3 => 2:13.0.0-0ubuntu4] (openstack, ubuntu-server)
<doko> vorlon, xnox: it's in unapproved
<acheronuk> RAOF: yes, those translations in plasma have gone. a deliberate decision by the l10n maintainer for that language it seems.
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (cosmic-proposed/multiverse) [5.2.20-dfsg-1ubuntu18.10.1 => 5.2.20-dfsg-3ubuntu18.10.1] (no packageset)
<acheronuk> RAOF: I also went through the plasma tars and weeded out any that were just version bumps. hence why there are 33 (ish) rather than 44, which is the full plasma compliment
<acheronuk> valorie: ^^^
<valorie> <3
<valorie> you rock, sir
<acheronuk> 20 contained a bugfix or other code change
<RAOF> acheronuk: ah, ok. Thanks. You missed one version bump only, but that's ok ð
<valorie> thanks for your work, RAOF
<acheronuk> RAOF: could have been one which is required by an internal dep of another to be bumped. there are one or 2 in the plasma stack which do that
<acheronuk> but ye, thank you :)
<acheronuk> or could have been brain fade reviewing diffs of 44 tars ;)
<acheronuk> RAOF: you may also be relieved that 5.12.8 is not due until March 2019 https://community.kde.org/Schedules/Plasma_5
<acheronuk> I am!
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1024.25] (kernel)
#ubuntu-release 2018-10-25
<vorlon> doko: I haven't been able to convince myself that this python3-defaults update in bionic-proposed is obviously safe; it's a wholesale update of a lot of things that look entirely unrelated to making python3-stdlib-extensions installable, and the only SRU bug linked doesn't even mention the python3-defaults package, let alone a test case for it
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1025.30] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1024.25]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1025.30]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: virtualbox (cosmic-proposed/multiverse) [5.2.20-dfsg-1 => 5.2.20-dfsg-3] (ubuntu-cloud) (sync)
<LocutusOfBorg> please accept vbox and vbox-hwe, you can keep it in proposed for DD, I care about it being built :)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-139.165] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-139.165]
<acheronuk> sil2100: could you perhaps let the remaining plasma 5.12.7 as discussed last night? if KDE want to revert the changes made by an l10n maintainer, they will have to do a new plasma release
<acheronuk> I would like to put out a call for testing of LP: #1794494 as a whole on our website
<ubot5> Launchpad bug 1794494 in xdg-desktop-portal-kde (Ubuntu) "SRU tracking bug for KDE's Plasma 5.12.7 for bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1794494
<acheronuk> *plasma 5.12.7 in bionic queue
<sil2100> acheronuk: ok
 * sil2100 checks backlog
 * Laney eyes the bionic livefs builds
<sil2100> acheronuk: ok, so the 'id' translations getting reverted to English is expected, right?
<sil2100> acheronuk: in the .desktop files of systemsettings?
<Laney> I guess we need the python3-defaults in the SRU queue for that?
<Laney> comes down to:
<Laney> The following packages have unmet dependencies:
<Laney>  python3-distutils : Depends: python3 (>= 3.6.6-1~) but 3.6.5-3ubuntu1 is to be installed
<Laney>                      Depends: python3-lib2to3 (>= 3.6.4) but it is not going to be installed
<Laney> E: Unable to correct problems, you have held broken packages.
<sil2100> Laney: let me take a look at that one in the queue
<Laney> ta
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
<sil2100> Laney: (ignore the just failed ubuntu-core builds, those failed for a now-known reason)
 * Laney was just ð¤ at those
<acheronuk> sil2100: it from upstream. not a mispacked tar. I am querying, but as said if they want to change that now they will need to do a new release
<Laney> sil2100: just saw a msg from vorlon above about that pkg btw
<sil2100> Laney: I think doko needs to re-upload it since the changelog bug is wrong, but I guess I could do that too
<sil2100> Laney: what did Steve say about it?
 * sil2100 has no backlog
<Laney> 25/10 01:00:21 <vorlon> doko: I haven't been able to convince myself that this python3-defaults update in bionic-proposed is obviously safe; it's a wholesale update of a lot of things that look entirely unrelated to making
<Laney>                         python3-stdlib-extensions installable, and the only SRU bug linked doesn't even mention the python3-defaults package, let alone a test case for it
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1003.4] (kernel)
<sil2100> Yeah, he linked the wrong bug for that
<sil2100> I'll re-upload it myself if he won't pop up soon
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.1 => 1.361.2] (core)
<xnox> infinity, vorlon - http://paste.ubuntu.com/p/ynT6xbYN8t/ i think when we were seeding ubuntu-advantage-tools into precise, something like this also happened (inclusion of xorg-lts) and we chose to not take those updates.
<xnox> I guess for this trusty update, i should too, only take the ubuntu-advantage-tools change, right?
<xnox> (and specify bug #1686183 in the right changelog line)
<ubot5> bug 1686183 in ubuntu-meta (Ubuntu Xenial) "Ship ubuntu-advantage in ubuntu-minimal" [High,Confirmed] https://launchpad.net/bugs/1686183
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.35.5+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.35.5]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.35.5~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-kde [source] (bionic-proposed) [5.12.7-0ubuntu0.1]
<sil2100> acheronuk: ok, I think those are all - I see that Chris rejected the plasma-desktop package because of some cruft in it
<sil2100> acheronuk: I guess you'd want to re-upload that?
<acheronuk> he did? what cruft?
<acheronuk> gotta go. back later
<sil2100> Seeing his rejection comment:
<sil2100> "An upload of plasma-desktop to bionic-proposed has been rejected from the upload queue for the following reason: "Package appears to have some binary cruft (eg /tmp/tmpixkYbi/UwMNumLrtq/plasma-desktop-5.12.7/po/sr/scripts/kfontinst/.svn/wc.db )"."
<sil2100> acheronuk: ^ once you're back
-queuebot:#ubuntu-release- Unapproved: python3-defaults (bionic-proposed/main) [3.6.5-3ubuntu1 => 3.6.7-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: rejected python3-defaults [source] (bionic-proposed) [3.6.7-1~18.04]
-queuebot:#ubuntu-release- Unapproved: python3-defaults (cosmic-proposed/main) [3.6.6-1 => 3.6.7-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected python3-defaults [source] (cosmic-proposed) [3.6.7-1~18.10]
-queuebot:#ubuntu-release- Unapproved: upower (cosmic-proposed/main) [0.99.8-2 => 0.99.8-2ubuntu0.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected upower [source] (cosmic-proposed) [0.99.8-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: upower (cosmic-proposed/main) [0.99.8-2 => 0.99.8-2ubuntu0.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected upower [source] (cosmic-proposed) [0.99.8-2ubuntu0.1]
<seb128> (sorry, screwed up that upower upload and rejected, the most recent one is good now/in the queue)
-queuebot:#ubuntu-release- Unapproved: upower (cosmic-proposed/main) [0.99.8-2 => 0.99.8-2ubuntu0.1] (kubuntu, ubuntu-desktop)
<infinity> xnox: Indeed, adding the hwe xorg to desktop is problematic, as it breaks switching back and forth.
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (bionic-proposed) [3.6.7-1~18.04]
-queuebot:#ubuntu-release- Unapproved: xkeyboard-config (cosmic-proposed/main) [2.23.1-1ubuntu1 => 2.23.1-1ubuntu1.18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: xkeyboard-config (bionic-proposed/main) [2.23.1-1ubuntu1 => 2.23.1-1ubuntu1.18.04.1] (core)
<xnox> infinity, and about debootstrap.... do you care for it to know how to debootstrap with -updates|-security from the initial set of debs downloaded and unpacked, or not?
<acheronuk> sil2100: those 'binary' file exist in the 5.12.4 and 5.12.6 tarballs in the archive at the very least. so not sure what you expect me to do
<xnox> cause it should be possible to extend "components" to support pockets too
<infinity> xnox: It's a long-standing feature request that might be neat.  I don't care today, no.
<xnox> infinity, right, so it's not that crazy, and to be fair only has a limited usage. And really is not needed to hack ubuntu-meta by hand to include non-release-pocket-package
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (trusty-proposed/main) [1.325 => 1.325.1] (core)
<infinity> xnox: Are you going to do xenial as well, instead of waiting 2 years to revisit the same bug all over? :P
<xnox> infinity, i did xenial already thank you very much ;-)
<xnox> it's in unapproved
<xnox> or at least, i'm under such impression
<xnox> infinity, and yes, i'm actioning the acient distro column card from the backlog
 * xnox is trying to do all the SRUs until we get a new codename
<xnox> yeap, it is there https://bugs.launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=ubuntu-meta
<acheronuk> slashd: in fact, tars back to plasma-desktop 5.10.0 have them
<acheronuk> sil2100 I mean ^^^
<infinity> xnox: Oh, shiny.  Thanks.
<infinity> Speaking of all the SRUs, making all of py3 uninstallable in xenial for hours sure caused a lot of vomit in my inbox.
<infinity> Err, bionic.
<xnox> hahahahhahhahahaha
<xnox> infinity, he did mention in the morning standup that he is bored without a new codename. I guess that is his subconscious way of not being bored =)
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (cosmic-proposed) [3.6.7-1~18.10]
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
<acheronuk> sil2100: ^^^ please accept. I can maybe poke KDE about what they are doing with their tarball generation script, but since it's been like that for many releases I can't see why need to mess with it right now
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-39.42~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-39.42~16.04.1] (kernel)
<acheronuk> sil2100: FYI https://bugs.kde.org/show_bug.cgi?id=400292
<ubot5> KDE bug 400292 in general "cruft in plasma-desktop tars" [Normal,Unconfirmed]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-39.42~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-39.42~16.04.1]
<sil2100> acheronuk: ok, thanks! I'll pick up the old upload from Rejected then
<sil2100> Ah, you reuploaded
<sil2100> Good
<sil2100> Thanks o/
<sil2100> acheronuk: that's not a blocker and probably not a problem, but I see in the CMakeLists.txt you bumped the version of AppStreamQt but the libappstreamqt-dev dep is unversioned
<sil2100> Anyway, it's otherwise good, accepting
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:5.12.7-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu3]
<acheronuk> sil2100: thanks :)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (xenial-proposed) [1.361.2]
<vorlon> sil2100, doko: what to do about python3-defaults> IMHO we should fix the versioned deps in python3-stdlib-extensions and reupload that instead
<doko> vorlon: I disagree. we should have the autopkg tests run this time. didn't do that for 3.6.6. now already running
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (trusty-proposed) [1.325.1]
<vorlon> doko: what do autopkgtests have to do with python3-defaults being forklifted in with a bunch of unrelated changes just to satisfy a version constraint?
<doko> what do you mean by unrelated changes? the Policy update? There is nothing more
<vorlon> doko: the policy update and the pile of other changes to versioned dependencies
<xnox> vorlon, maybe join the meeting, eh?!
<vorlon> nope
<doko> the versioned dependencies are part of the update, yes
<xnox> vorlon, then stop distracting doko from the meeting =))))))))
 * vorlon checks who has been sending whom PMs during the meeting
<sil2100> I thought that the python3-defaults version bumps were part of the overall 3.6.7 update, part of the usual process for new minor releases
<doko> they are
-queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.33.1~14.04.2 => 1.33.1~14.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: totem (cosmic-proposed/main) [3.26.2-1ubuntu1 => 3.26.2-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (trusty-proposed) [1.33.1~14.04.3]
<bdmurray> Where did the lubuntu-core package go?
<xnox> vorlon, would it help reviewing ubuntu-keyring if I dput upload it, rather than sync it?
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~beta4-7354-g3de074967-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~beta4-7358-g703416782-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~beta4-7355-g629adfda8-0ubuntu1~18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~beta4-7355-g629adfda8-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~beta4-7358-g703416782-0ubuntu1~18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~beta4-7354-g3de074967-0ubuntu1~18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.2-7034-g2f5deb8b8-0ubuntu1 => 2.5.0~beta4-7359-g1f94845ac-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (cosmic-proposed/main) [2.5.0~beta2-7291-gd0345ced5-0ubuntu1 => 2.5.0~beta4-7359-g1f94845ac-0ubuntu1~18.10.1] (ubuntu-server)
<vorlon> xnox: it would help reviewing ubuntu-keyring if the internal documentation about key rotation had any relation at all to what you're doing
<vorlon> xnox: that's what's slowing it down
<vorlon> xnox: (and I also don't mean just going and changing the wiki page, I mean getting sign-off from both juliank and cjwatson that the changes to the documentation are correct)
<xnox> vorlon, i'm not sure which pages you are refering to.
<xnox> vorlon, last time the key rotation was done wrong; and i had to finish up incomplete rotations for upgrade tarballs; cd signing; etc.
<xnox> vorlon, also the format of keys was changed, and locations of where they are stored on disk.
<xnox> vorlon, also the remote update of trusted keys was disabled long time ago, because it is CVE buggy.
<xnox> vorlon, and the new one that juliank and I drafted was never implemented.
<xnox> vorlon, as in to have a signed gpg blob that is validated and piped into a /etc/apt/trusted.gpg.d/remote-updated-key.gpg
<xnox> vorlon, and i have no idea where the idea of signing the new signing key with master key came, from, because as far as i can tell previous keys were not signed like that, and it's fine, cause gpg web of trust is not used.
<xnox> vorlon, what i'm proposing is trivial.... start trusting new key in addition to the old key, which is obviously correct thing to do, and is the same thing that was done with the previous key migration to the 2012 key.
<xnox> vorlon, i'm currious which documentation you are reviewing. Also note that cjwatson did +1 the launchpad signing cod merge proposal.
-queuebot:#ubuntu-release- Unapproved: accepted sendmail [source] (cosmic-proposed) [8.15.2-11ubuntu1]
<xnox> vorlon, see https://code.launchpad.net/~xnox/ubuntu-archive-publishing/dual-sign-2018/+merge/356919
<vorlon> xnox: https://wiki.canonical.com/UbuntuArchiveKeyDisasterRecovery is the documented key rotation process
<vorlon> xnox: for that particular branch, not merged yet because I haven't put the key in place
#ubuntu-release 2018-10-26
<tsimonq2> (I'm back on IRC, yay.)
<tsimonq2> bdmurray: It's been gone since ~ the opening of Cosmic.
<tsimonq2> I didn't realize it was hardcoded where it was or I would have fixed it, sorry.
<bdmurray> tsimonq2: updating ubuntu-release-upgrader to reflect that, it has a list of meta packages, would have been good
<infinity> vorlon: Re: "Not merging because you haven't put the key in place", I verified the key was there before xnox did the MP.
<infinity> vorlon: So if you didn't do it, who did? :)
<vorlon> hmm did I?
<vorlon> well I don't remember doing it :)
<infinity> lp_publish@pepo:~$ gpg --no-default-keyring --keyring /srv/launchpad.net/ubuntu-archive/gnupg-home/pubring.gpg --fingerprint 991BC93C | grep finger
<infinity>       Key fingerprint = F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
<infinity> Looks there to me.
<infinity> Secret keyring last modified Sept 17.
<infinity> Which sounds suspiciously like "the day you generated it".
<infinity> Because it is. :)
<vorlon> right, ok
<infinity> (Ignore the above being pugring, I checked both)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1003.4]
<xnox> vorlon, so yeah, that page has certain things out of date; and certain things not implemented.
<xnox> vorlon, so this is the reference https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1013639
<ubot5> Ubuntu bug 1013639 in apt (Ubuntu Hardy) "net-update verifcation checking is still insecure (aka gpg key shadowing, again)" [Critical,Fix released]
 * xnox ponders if i should correct the bug title typo
<xnox> vorlon, and I still agree with my last comment on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1013681
<ubot5> Ubuntu bug 1013681 in apt (Ubuntu) "make apt-key net-update secure" [High,Triaged]
<xnox> however, unlike the original proposal, this only will solve the "trust a new signing key" it will not solve "revoke compromised keys" as at the moment, we do not handle revocations at all.
<xnox> (no gpg web of trust, or revocation testing)
<xnox> vorlon, also whilst signing the new singing key with master key is not strictly needed; have you signed a new ubuntu-archive-keyring.gpg? =) to be updated at http://archive.ubuntu.com/ubuntu/project/
<xnox> (despite that not used)
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~beta4-7354-g3de074967-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~beta4-7358-g703416782-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~beta4-7355-g629adfda8-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [4.18.0-11.12~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [4.18.0-11.12~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [4.18.0-11.12~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [4.18.0-11.12~18.04.1]
-queuebot:#ubuntu-release- Unapproved: gcc-6 (cosmic-proposed/universe) [6.4.0-22ubuntu1 => 6.5.0-1ubuntu1~18.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6 (bionic-proposed/universe) [6.4.0-17ubuntu1 => 6.5.0-1ubuntu1~18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (cosmic-proposed/universe) [30ubuntu4 => 30ubuntu4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (bionic-proposed/universe) [30ubuntu3 => 30ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (cosmic-proposed/universe) [28ubuntu5 => 28ubuntu5.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (bionic-proposed/universe) [28ubuntu3 => 28ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.2 => 1.37~18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: nginx (cosmic-proposed/main) [1.15.5-0ubuntu1 => 1.15.5-0ubuntu2] (ubuntu-server)
#ubuntu-release 2018-10-27
<nabcore> When will Java 11 be released for 18.04? (https://dzone.com/articles/installing-openjdk-11-on-ubuntu-1804-for-real)
<nabcore> (also see https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html )
#ubuntu-release 2019-10-21
-queuebot:#ubuntu-release- Unapproved: cracklib2 (focal-proposed/main) [2.9.6-2build1 => 2.9.6-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: subvertpy (focal-proposed/universe) [0.10.1-2build2 => 0.10.1-2ubuntu1] (no packageset)
<vorlon> infinity: something seems broken in ~/extra-germinate on snakefruit, the component-mismatches-proposed run is failing (it's succeeded now, but it's wrong, because I manually reran without the --germinate-path argument and it unexpectedly worked :P
<vorlon> )
<infinity> vorlon: "seems broken" doesn't mean a lot.  It was working a day or two ago.  Hrmph.
<vorlon> infinity: last successful run of the -proposed instance was on the 17th (17:51)
<vorlon> and now it fails with https://paste.ubuntu.com/p/5GkMcStZwg/
<infinity> Yeahp, just saw that here in a manual run.  Fun.
-queuebot:#ubuntu-release- Unapproved: accepted cracklib2 [source] (focal-proposed) [2.9.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted subvertpy [source] (focal-proposed) [0.10.1-2ubuntu1]
<infinity> The seeds haven't changed at all since they were branched.
<infinity> I can't fathom why anything would be broken.
<infinity> Unless it's finding something without a date_published?
<infinity> Except it's supposed to skip those.
<infinity> vorlon: I'm mirroring dists locally so I can fiddle with this in the morning, but trying to be a good boy (to myself) and get to sleep at a "normal hour", so won't look much more right now.
<infinity> vorlon: Based on where it explodes, it seems it's tripping over a publishing record of $something, but I didn't want to litter production with debug print()s.
<infinity> Oh, but I could just copy a debug copy elsewhere.  Derp.
<infinity> vorlon: Well, isn't that just swell...
<infinity> vorlon: So, in production, it falls over sorting the very first pub.  Doing exactly the same thing in lp-shell works fine: https://paste.ubuntu.com/p/WW7JzvxtSB/
<infinity> So, I dunno.
<infinity> lp-shell is py2, not py3, but I can't see that making a big difference here.  I hope.
<infinity> And component-mismatches hasn't changed in a while.
<infinity> Yeah, really going to sleep.
<infinity> cjwatson: Not sure how much of component-mismatches is yours, as opposed to pitti's and elmo's, but if you have any time when you wake up, it would be nice to have someone more pythony and germinatey explain why the c-m-proposed run in production is producing backtraces instead of reports.
<infinity> cjwatson: If not, I'll muddle through in the morning.
<infinity> cjwatson: Traceback is https://paste.ubuntu.com/p/5GkMcStZwg/ ... As noted above, cannot reproduce in lp-shell following essentially the same logic step-by-step, so WTF.
<mitya57> doko: Ok, I'll look later today. Suddenly the Qt 5.12 transition began in Debian, so I spent all yesterday's evening on itâ¦
-queuebot:#ubuntu-release- Unapproved: python-persistent (focal-proposed/universe) [4.2.2-2build1 => 4.4.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-persistent [source] (focal-proposed) [4.4.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-tornado (focal-proposed/universe) [5.1.1-4ubuntu2 => 5.1.1-4ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (focal-proposed) [5.1.1-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-tornado (focal-proposed/universe) [5.1.1-4ubuntu3 => 5.1.1-4ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: basemap (focal-proposed/universe) [1.2.0+dfsg-2build1 => 1.2.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted basemap [sync] (focal-proposed) [1.2.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (focal-proposed) [5.1.1-4ubuntu4]
<cjwatson> infinity: That's totally a py3 thing.  Will dig
<doko> infinity: could you have a look, gettid: https://launchpadlibrarian.net/447769548/buildlog_ubuntu-focal-amd64.grpc_1.16.1-1build1_BUILDING.txt.gz
<cjwatson> infinity,vorlon: It'll happen when two publications have identical date_published (haven't bothered working out why but there are various plausible reasons); py3 is stricter about not allowing comparability of random objects that have no comparison defined on them.  Fixed blindly in https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1247, let me know if it's still ...
<cjwatson> ... a problem
<cjwatson> (and this bit was actually bdmurray's code, so have a highlight just in case I did something stupid)
<cjwatson> https://docs.python.org/3/whatsnew/3.0.html#ordering-comparisons is the py3 change that this tripped over
-queuebot:#ubuntu-release- Unapproved: matplotlib (focal-proposed/universe) [3.0.2-2build1 => 3.0.2-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (focal-proposed) [3.0.2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xorg-hwe-18.04 (bionic-proposed/main) [1:7.7+19ubuntu8~18.04.2 => 1:7.7+19ubuntu8~18.04.3] (no packageset)
<LocutusOfBorg> doko, hello, https://launchpad.net/ubuntu/+source/vmdk-stream-converter/0.2-4ubuntu2/+build/17930452
<LocutusOfBorg> isn't this a python3-defaults bug?
<LocutusOfBorg> or dh-python, whatever
-queuebot:#ubuntu-release- Unapproved: pytables (focal-proposed/universe) [3.5.2-3build1 => 3.5.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pytables [source] (focal-proposed) [3.5.2-3ubuntu1]
<doko> Build-Depends: debhelper (>= 11), dh-python, python3 | python3-all | python3-dev | python3-all-dev
<LocutusOfBorg> doko, you mean, remove python3-all?
<LocutusOfBorg> I don't get the deps...
<LocutusOfBorg> if python3 is installed, dh-python should run only against the default python, right?
<cjwatson> That set of alternatives is totally pointless
<cjwatson> Only the first will ever be picked
<LocutusOfBorg> yes, but dh-python should look at what is actually installed, not the alternate dependencies...
<cjwatson> Does seem a bit odd, not sure
<LocutusOfBorg> removing the alternate deps "fixes" the build, and using DH_VERBOSE shows that dh-python is trying to iterate during configure with an array made of "3.7 3.8"
-queuebot:#ubuntu-release- Unapproved: bpfcc (focal-proposed/universe) [0.8.0-4build1 => 0.8.0-4ubuntu1] (no packageset)
<LocutusOfBorg> ^^ build fix
-queuebot:#ubuntu-release- Unapproved: vmdk-stream-converter (focal-proposed/main) [0.2-4ubuntu2 => 0.2-4ubuntu3] (desktop-core)
<LocutusOfBorg> ^^ build fix
-queuebot:#ubuntu-release- Unapproved: gdal (focal-proposed/universe) [2.4.2+dfsg-1build3 => 2.4.2+dfsg-1build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: magics++ (focal-proposed/universe) [4.1.2-2build1 => 4.1.2-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mapserver (focal-proposed/universe) [7.4.1-1build2 => 7.4.1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-mapnik (focal-proposed/universe) [1:0.0~20180723-588fc9062-3build1 => 1:0.0~20180723-588fc9062-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bpfcc [source] (focal-proposed) [0.8.0-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted magics++ [source] (focal-proposed) [4.1.2-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted python-mapnik [source] (focal-proposed) [1:0.0~20180723-588fc9062-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted gdal [source] (focal-proposed) [2.4.2+dfsg-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted vmdk-stream-converter [source] (focal-proposed) [0.2-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mapserver [source] (focal-proposed) [7.4.1-1build3]
<doko> LocutusOfBorg: forwarded to Debian?
<LocutusOfBorg> doko, what? vmdk-streaming-converter? yes I updated the bug report
<LocutusOfBorg> for bpfcc not needed, the Debian new release should just build fine, but needs to be removed on i386, so lets upload this one and sync once focal opens
<doko> LocutusOfBorg: removed proj in -proposed
<LocutusOfBorg> i saw already
<LocutusOfBorg> we have lots of regression on perl, is anybody retrying them? they should work now that reverse-deps are installable again
<doko> please not yet, the queues are still loaded
<LocutusOfBorg> s390x is empty, we can reschedule only them to see how we get further?
-queuebot:#ubuntu-release- Unapproved: accepted python3.8 [source] (disco-proposed) [3.8.0-1~19.04]
<rbalint> doko, from https://people.canonical.com/~ubuntu-archive/transitions/html/libevent-2.1.html i'm fixing qtwebengine-opensource-src and suricata, just waiting for the test builds
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (disco-proposed) [3.7.5-1~19.04]
-queuebot:#ubuntu-release- Unapproved: python-datrie (focal-proposed/universe) [0.7.1-3build1 => 0.7.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-datrie [source] (focal-proposed) [0.7.1-3ubuntu1]
<tomreyn> hmm, so would you say that maybe someone should edit the 19.10 release notes (which have recommended upgrading servers and desktops using -d since release) without waiting for bdmurray to respond (since people keep running those yet unsupported upgrades, and you may enable dev upgrades to docal soon)?
<tomreyn> *focal
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1003.3] (core, kernel)
<LocutusOfBorg> doko, meshio is fixed upstream, can I upload?
<doko> LocutusOfBorg: could you do a test rebuild first? the package tests seem to hang for me
<LocutusOfBorg> doko, ongoing
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> sigh, I fixed odb-api because a typo in changelog prevented your debian bug being closed... nice to loose time twice
-queuebot:#ubuntu-release- Unapproved: odb-api (focal-proposed/universe) [0.18.1-7build1 => 0.18.1-8] (no packageset) (sync)
<LocutusOfBorg> doko, ^^
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: moonshot-trust-router (focal-proposed/universe) [3.5.0+1build1 => 3.5.0+1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted moonshot-trust-router [source] (focal-proposed) [3.5.0+1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted odb-api [sync] (focal-proposed) [0.18.1-8]
-queuebot:#ubuntu-release- New sync: eckit (focal-proposed/primary) [1.4.2-2]
<LocutusOfBorg> doko, ^^ this unblocks odb-api, sigh
 * LocutusOfBorg triggers tests on s390x in a few minutes, since the queue is empty
-queuebot:#ubuntu-release- Unapproved: thunderbird (focal-proposed/main) [1:68.1.2+build1-0ubuntu1 => 1:68.1.2+build1-0ubuntu2] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pymssql (focal-proposed/universe) [2.1.4+dfsg-2build1 => 2.1.4+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: firefox (focal-proposed/main) [69.0.3+build1-0ubuntu1 => 70.0+build2-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted pymssql [source] (focal-proposed) [2.1.4+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New sync: eckit (focal-proposed/primary) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted eckit [sync] (focal-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: rejected eckit [sync] (focal-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (focal-proposed/universe) [7906-0ubuntu1 => 7906-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: eckit [s390x] (focal-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eckit [amd64] (focal-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eckit [ppc64el] (focal-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted eckit [amd64] (focal-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted eckit [s390x] (focal-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted eckit [ppc64el] (focal-proposed) [1.4.2-2]
<LocutusOfBorg> doko, meshio builds fine with newer h5py, otherwise it fails on testsuite
<LocutusOfBorg> but newer h5py from Debian drops python2 package
<doko> LocutusOfBorg: if the new h5py is compatible with the hdf5 in focal, we should update it, but still building the py2 package. sorry for being overcautious
-queuebot:#ubuntu-release- Unapproved: h5py (focal-proposed/universe) [2.9.0-7 => 2.10.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-meshio (focal-proposed/universe) [3.1.6-1 => 3.1.6-1ubuntu1] (no packageset)
<LocutusOfBorg> doko, ^^ I manually grabbed 2.10.0-1 that still has python2 package
<LocutusOfBorg> you can see in my ppa both building fine
<LocutusOfBorg> btw *thanks* for being overcautious :)
<mfo> Someone grub/tpm/secureboot'ish might want to check LP#1848892; it seems "error: Unknown TPM error." is being hit  by some users after do-release-upgrade from D to E.
-queuebot:#ubuntu-release- Unapproved: accepted h5py [source] (focal-proposed) [2.10.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-meshio [source] (focal-proposed) [3.1.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (focal-proposed) [70.0+build2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (focal-proposed) [1:68.1.2+build1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-scipy (focal-proposed/universe) [1.2.2-4build1 => 1.2.2-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted python-scipy [source] (focal-proposed) [1.2.2-4ubuntu1]
<Laney> I think the autopkgtest controller machine has crashed or something, trying to restart it but it's not coming back up immediately
<Laney> stand by
-queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.22.2-1ubuntu0.1~16.04.1 => 0.31.0-2~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: imagemagick (focal-proposed/main) [8:6.9.10.23+dfsg-2.1ubuntu7 => 8:6.9.10.23+dfsg-2.1ubuntu8] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted imagemagick [source] (focal-proposed) [8:6.9.10.23+dfsg-2.1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.2-2ubuntu2 => 1:4.1.2-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-acme (bionic-proposed/universe) [0.22.2-1ubuntu0.1 => 0.31.0-2~ubuntu18.04.1] (no packageset)
<Laney> systemd-tmpfiles-setup is not finishing
<rbalint> doko, ^suricata
-queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (focal-proposed) [1:4.1.2-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-acme (disco-proposed/universe) [0.31.0-1 => 0.31.0-2~ubuntu19.04.1] (no packageset)
<Laney> ok it's back
-queuebot:#ubuntu-release- Unapproved: python-certbot (xenial-proposed/universe) [0.23.0-1~ubuntu16.04.1 => 0.27.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot (bionic-proposed/universe) [0.23.0-1 => 0.27.0-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: odb-api (focal-proposed/universe) [0.18.1-8 => 0.18.1-8ubuntu1] (no packageset)
<LocutusOfBorg> doko ^^ reopening bug report on Debian
-queuebot:#ubuntu-release- Unapproved: carla (focal-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu4] (ubuntustudio)
<Eickmeyer> ^bugfix for a missing build-dep.
-queuebot:#ubuntu-release- Unapproved: accepted odb-api [source] (focal-proposed) [0.18.1-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: carla (eoan-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu4] (ubuntustudio)
<Eickmeyer> Same bug fix as an SRU, bug 1849168 ^
<ubot5> bug 1849168 in carla (Ubuntu) "[SRU] Missing build dep libsndfile1-dev discovered" [Undecided,New] https://launchpad.net/bugs/1849168
<infinity> cjwatson: Ahh, so I would have been able to repro that in lp-shell if it used python3.  Maybe it's time to switch that?
<cjwatson> I have no particular objection
<vorlon> Laney: well, I enjoy that deleting EOL releases has freed up more than half of autopkgtest's swift usage.  But now I see that there are a lot of per-ppa buckets.  I can go garbage-collect those for EOL releases, but I'm unclear on how these are being created in the first place or how we should manage these over time
<Laney> vorlon: Probably expire them after some number of days
<Laney> that's the kind of thing I was expecting to talk about on the card :-)
<Laney> but a cleanup job feels quite reasonable to me
<vorlon> Laney: ah, so you have in mind to do a more generic cleanup job, not bileto-specific?
<Laney> vorlon: that was my first thought; open to other arguments
<Laney> we could plumb through a way for bileto to get its stuff deleted too, I guess
<Laney> cleaning up all the things would help for the systemd containers too
<Laney> took some baby steps forward with the staging environment today, btw
<Laney> now 3/4 of the clouds work there (in theory)
<Eickmeyer> Could I get both of my uploads for carla rejected? I screwed up somewhere and they're failing to build. Working with upstream to get that corrected.
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (disco-proposed) [0.31.0-2~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (bionic-proposed) [0.31.0-2~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected carla [source] (focal-proposed) [2.0.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (xenial-proposed) [0.31.0-2~ubuntu16.04.1]
<infinity> tomreyn: bdmurray is the person who will both be enabling eoan upgrades and enabling focal upgrades, I trust him to not do it in the wrong order. :P
<infinity> tomreyn: Also, -d won't skip releases, by design.
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot [source] (bionic-proposed) [0.27.0-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: pandas (focal-proposed/universe) [0.23.3+dfsg-4ubuntu2 => 0.23.3+dfsg-4ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot [source] (xenial-proposed) [0.27.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (focal-proposed) [0.23.3+dfsg-4ubuntu3]
<RikMills> infinity: so it is intentional policy that main Ubuntu has -d in their release notes upgrade instructions from the 'get go'?
<RikMills> not objecting. just not what I expected
<infinity> RikMills: No.  It's something Brian did on a whim because we hadn't updated meta-release yet and, I imagine, he wanted to prompt people reading release notes with how to upgrade so we could have results to decide if we should enable it for people who don't read release notes.
<infinity> RikMills: Not that I should speak for him, I just note that he's the one who committed the temporary change to the wiki.
-queuebot:#ubuntu-release- Unapproved: nml (focal-proposed/universe) [0.4.5-1build2 => 0.4.5-1ubuntu1] (no packageset)
<RikMills> infinity: yeah, I saw he did it, so I ruled it our as being unintentional. that argument is ok on that basis, but it does generate some confusion online between people saying upgrade is available or not, and flavours who do not follow that train of thought
<RikMills> not the biggest deal ever, just seeking to clarify :)
<vorlon> Laney: (sorry if repeat) so, I think time-based expiry from non-distro autopkgtest buckets is a reasonable default policy, but that for buckets related to some sort of external management service (github PRs for systemd; bileto tickets) the ideal is to be able to ensure there's a stay of execution for test results related to a change that's not yet closed
-queuebot:#ubuntu-release- Unapproved: grpc (focal-proposed/universe) [1.16.1-1build1 => 1.16.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjpeg2 (focal-proposed/universe) [2.3.0-2 => 2.3.0-2build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted grpc [source] (focal-proposed) [1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openjpeg2 [source] (focal-proposed) [2.3.0-2build1]
<doko> pandas, why do you hate me ...
-queuebot:#ubuntu-release- Unapproved: accepted nml [source] (focal-proposed) [0.4.5-1ubuntu1]
<Eickmeyer> vorlon: Thanks for the reject on focal, could I also get it rejected for eoan? I'm working on an SRU for it, but apparently there's a problem with wine.
<vorlon> Eickmeyer: ah, hadn't realized "both" referred to a different series.  Done
-queuebot:#ubuntu-release- Unapproved: rejected carla [source] (eoan-proposed) [2.0.0-0ubuntu4]
<Eickmeyer> vorlon: Thanks. :)
-queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.7-0ubuntu2 => 2:12.0.9-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.11-0ubuntu1 => 2:17.0.12-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pandas (focal-proposed/universe) [0.23.3+dfsg-4ubuntu3 => 0.23.3+dfsg-4ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (focal-proposed) [0.23.3+dfsg-4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (focal-proposed/universe) [5.12.4+dfsg-1ubuntu2 => 5.12.4+dfsg-1ubuntu3] (kubuntu)
<rbalint> doko, ^qtwebengine-opensource-src
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [source] (focal-proposed) [5.12.4+dfsg-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: cinder (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.1-0ubuntu2.1 => 2:19.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected backport-iwlwifi-dkms [source] (focal-proposed) [7906-0ubuntu2]
<infinity> vorlon, cjwatson: Does either of you own the auto-sync cowboy on snakefruit and want to either commit or revert it as appropriate?
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1.1 => 3:15.1.0-0ubuntu1.2] (openstack, ubuntu-server)
<cjwatson> infinity: Not it
<cjwatson> I think
<cjwatson> Hm, not sure.  I *think* that was vorlon
<cjwatson> But I don't quite remember for sure, sorry
<infinity> Unless I'm not pythoning correctly, it looks backwards?
<infinity> But I dunno.
<infinity> It reads as a redirect of stdout to stderr to me.
 * infinity shrugs.
<infinity> Maybe vorlon has context.
<cjwatson> You're reading it backwards.  C is the same way round as this.
<cjwatson> dup2(oldfd, newfd) -> make newfd act as a copy of oldfd
<cjwatson> Dunno why it isn't just done as sys.stderr = sys.stdout though
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.2-0ubuntu1 => 3:13.0.2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: slepc4py (focal-proposed/universe) [3.11.0-2 => 3.11.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted slepc4py [source] (focal-proposed) [3.11.0-2build1]
-queuebot:#ubuntu-release- Unapproved: klibc (eoan-proposed/main) [2.0.6-1ubuntu1 => 2.0.6-1ubuntu2] (core)
<infinity> bdmurray: ^-- As for focal, I'll copy this one forward once it builds, then merge 2.0.7 $later.
<doko> infinity: did you see my glibc issue?
<infinity> doko: Which one?
<infinity> doko: If you mean grpc, I uploaded a fix already.
<doko> ta, an ack would be appreciated
<infinity> doko: Sorry, I figured the upload would speak for itself, but maybe not in the middle of that massive transition tracker. :P
<infinity> doko: Are you stuck on any other particularly nasty ones in the python tracker that you want help with?
<doko> infinity: please coordinate with mwhudson about https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html
<doko> working on autopkg tests now isn't reliable
<infinity> doko: mwhudson is (mostly) not around today, due to sick kid.
<doko> that was yesterday
<infinity> I assure you it's today, as I just spoke to him. :P
<doko> well, fix things
<infinity> (At least, my today)
<jbicha> infinity: what "timezone" are you in today? :)
<infinity> jbicha: Some of them.
-queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (eoan-proposed) [2.0.6-1ubuntu2]
#ubuntu-release 2019-10-22
<vorlon> infinity, cjwatson: sorry, I don't have any context for that auto-sync cowboy; I don't remember making the change and I don't see any discussion about auto-sync in IRC logs from that time
<infinity> vorlon: Exciting.
<infinity> Well, it's been like that long enough that maybe the answer is just to commit it without context. :P
<vorlon> infinity: or revert it, because in all this time there have been no emails indicating output from auto-sync to stdout
-queuebot:#ubuntu-release- Unapproved: carla (eoan-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu4+gitde67dcb] (ubuntustudio)
<Eickmeyer> ^ For an SRU (bug 1849168)
<ubot5> bug 1849168 in carla (Ubuntu) "[SRU] Missing build dep libsndfile1-dev discovered" [Undecided,Fix committed] https://launchpad.net/bugs/1849168
-queuebot:#ubuntu-release- Unapproved: carla (focal-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu4+gitde67dcb] (ubuntustudio)
<Eickmeyer> ^ Same package, but for focal.
<infinity> Eickmeyer: You can't upload the same version to both.
<infinity> Eickmeyer: Which one do you want me to reject?
<Eickmeyer> infinity: reject focal then. I can bump the verison for focal upload (a no-change upload).
<infinity> Eickmeyer: Rejected.
-queuebot:#ubuntu-release- Unapproved: rejected carla [source] (focal-proposed) [2.0.0-0ubuntu4+gitde67dcb]
<Eickmeyer> infinity: thanks
-queuebot:#ubuntu-release- Unapproved: carla (focal-proposed/universe) [2.0.0-0ubuntu3 => 2.0.0-0ubuntu5+gitde67dcb] (ubuntustudio)
<Eickmeyer> infinity: There's the different version ^
<LocutusOfBorg> hello, i'm retrying amd64 and ppc64el autopkgests, since queues are empty
<Laney> vorlon: I mean if someone wants to implement an explicit expiry procedure, that's fine - but otherwise I think that saying that you get your results for (strawman) 90 days is also totally acceptable.
-queuebot:#ubuntu-release- Unapproved: casper (focal-proposed/main) [1.427 => 1.428] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (eoan-proposed/main) [3.34.0-1ubuntu2 => 3.34.2-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: pytables (focal-proposed/universe) [3.5.2-3ubuntu1 => 3.5.2-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pytables [source] (focal-proposed) [3.5.2-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.8-0ubuntu1 => 0.40.17-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu3.3 => 2.3.0-0ubuntu3.4] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-67.76] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-67.76] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (eoan-proposed/main) [1.183 => 1.183.1] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-67.76]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-67.76]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-33.35] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-33.35] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-33.35] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-33.35]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-33.35]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-33.35]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (focal-proposed) [1.428]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1062.67] (kernel)
-queuebot:#ubuntu-release- Packageset: Added ibus-avro to personal-gunnarhj in bionic
-queuebot:#ubuntu-release- Packageset: Added ibus-avro to personal-gunnarhj in disco
-queuebot:#ubuntu-release- Packageset: Added ibus-avro to personal-gunnarhj in eoan
-queuebot:#ubuntu-release- Packageset: Added ibus-avro to personal-gunnarhj in focal
-queuebot:#ubuntu-release- Packageset: Added ibus-avro to personal-gunnarhj in xenial
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1062.67]
<tkamppeter> Can you have a look at bug 1754671?
<ubot5> bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,In progress] https://launchpad.net/bugs/1754671
-queuebot:#ubuntu-release- Unapproved: python-importlib-metadata (focal-proposed/universe) [0.23-0ubuntu1 => 0.23-2] (no packageset) (sync)
<tkamppeter> Here there was originally uploaded network-manager 1.10.14 as SRU to fix this (and other) bugs in Bionic's 1.10.6. Regressions were reported and so an alternative SRU backporting upstream fixes into 1.10.6 was suggested.
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-167.196] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (eoan-proposed/universe) [77.0.3865.120-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu1~snap2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-167.196]
<tkamppeter> How to proceed to replace the 1.10.14 currently in bionic-proposed by the new 1.10.6-2ubuntu1.2 SRU?
<oSoMoN> release team:Â can you please reject chromium-browser from the eoan-proposed queue? I got the version number wrong, will re-upload later with it fixed
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [77.0.3865.120-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu1~snap2] (ubuntu-desktop)
<seb128> oSoMoN, rejected
<oSoMoN> thanks!
-queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (eoan-proposed) [77.0.3865.120-0ubuntu1~snap2]
<oSoMoN> seb128, mind rejecting my chromium-browser upload for focal, too? that ~snap2 suffix is not gonna fly :/
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [77.0.3865.120-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (eoan-proposed/universe) [77.0.3865.120-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu1.19.10.1] (ubuntu-desktop)
<didrocks> oSoMoN: flushed
<oSoMoN> didrocks, thanks
-queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (focal-proposed) [77.0.3865.120-0ubuntu1~snap2]
-queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (focal-proposed) [77.0.3865.120-0ubuntu2]
<seb128> oSoMoN, sorry, looks like we conflicted action with Didier and the non snap version got rejected as a result as well
<oSoMoN> seb128, no worries, if IÂ upload again it will be picked up, right?
<oSoMoN> or do IÂ need to bump again the version
<oSoMoN> ?
<seb128> no, just dput again the same
<seb128> or I think it could be archive copied back to accepted, but not be put to unapproved
<oSoMoN> ok, done
<oSoMoN> feel free to accept :)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [77.0.3865.120-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [77.0.3865.120-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-importlib-metadata [sync] (focal-proposed) [0.23-2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (eoan-proposed) [1.183.1]
-queuebot:#ubuntu-release- Unapproved: opencryptoki (focal-proposed/universe) [3.11.1+dfsg-0ubuntu2 => 3.11.1+dfsg-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opencryptoki (eoan-proposed/universe) [3.11.1+dfsg-0ubuntu2 => 3.11.1+dfsg-0ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opencryptoki (disco-proposed/universe) [3.11.0+dfsg-0ubuntu2 => 3.11.0+dfsg-0ubuntu2.1] (no packageset)
<dax> What's the timeline for do-release-upgrade offering eoan? Trying to figure out how to word some IRC support factoids.
<dax> (as per usual, people are being impatient in #ubuntu, so trying to standardize the response a bit)
-queuebot:#ubuntu-release- Unapproved: pandas (focal-proposed/universe) [0.23.3+dfsg-4ubuntu4 => 0.23.3+dfsg-4ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (focal-proposed) [0.23.3+dfsg-4ubuntu5]
-queuebot:#ubuntu-release- Unapproved: adios (focal-proposed/universe) [1.13.1-19 => 1.13.1-19build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fiona (focal-proposed/universe) [1.8.6-2 => 1.8.6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gpyfft (focal-proposed/universe) [0.7.0-1build2 => 0.7.0-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lqa (focal-proposed/universe) [20180702.0-1build1 => 20180702.0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cypari2 (focal-proposed/universe) [2.1.1-1 => 2.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: htseq (focal-proposed/universe) [0.11.2-1 => 0.11.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fpylll (focal-proposed/universe) [0.4.1+ds1-5 => 0.4.1+ds1-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mpi4py-fft (focal-proposed/universe) [2.0.3-3 => 2.0.3-3build1] (no packageset)
<dax> oh, meta-release looks different. guess that answers that :)
-queuebot:#ubuntu-release- Unapproved: pdal (focal-proposed/universe) [1.9.1+ds-2 => 1.9.1+ds-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyosmium (focal-proposed/universe) [2.15.3-1 => 2.15.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pytango (focal-proposed/universe) [9.2.5-1 => 9.2.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-falcon (focal-proposed/universe) [1.4.1-1 => 1.4.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-pybedtools (focal-proposed/universe) [0.8.0-2 => 0.8.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qgis (focal-proposed/universe) [3.4.10+dfsg-1build1 => 3.4.10+dfsg-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: reprozip (focal-proposed/universe) [1.0.14-2 => 1.0.14-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: scikit-learn (focal-proposed/universe) [0.20.3+dfsg-0ubuntu2 => 0.20.3+dfsg-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: spglib (focal-proposed/universe) [1.14.1-2 => 1.14.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pplpy (focal-proposed/universe) [0.8.4-2 => 0.8.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-cobra (focal-proposed/universe) [0.14.2-2 => 0.14.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyzmq (focal-proposed/universe) [17.1.2-3ubuntu1 => 17.1.2-3ubuntu2] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: samba (focal-proposed/main) [2:4.10.7+dfsg-0ubuntu2 => 2:4.10.7+dfsg-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: yarl (focal-proposed/universe) [1.3.0-1 => 1.3.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyside (focal-proposed/universe) [1.2.2+source1-3build3 => 1.2.2+source1-3build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rasterio (focal-proposed/universe) [1.0.25-1 => 1.0.25-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-preshed (focal-proposed/universe) [2.0.1-1 => 2.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: skimage (focal-proposed/universe) [0.14.2-2 => 0.14.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adios [source] (focal-proposed) [1.13.1-19build1]
-queuebot:#ubuntu-release- Unapproved: accepted fiona [source] (focal-proposed) [1.8.6-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted gpyfft [source] (focal-proposed) [0.7.0-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted lqa [source] (focal-proposed) [20180702.0-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted pdal [source] (focal-proposed) [1.9.1+ds-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyosmium [source] (focal-proposed) [2.15.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pytango [source] (focal-proposed) [9.2.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-falcon [source] (focal-proposed) [1.4.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pybedtools [source] (focal-proposed) [0.8.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted qgis [source] (focal-proposed) [3.4.10+dfsg-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted cypari2 [source] (focal-proposed) [2.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted htseq [source] (focal-proposed) [0.11.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pplpy [source] (focal-proposed) [0.8.4-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-cobra [source] (focal-proposed) [0.14.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyzmq [source] (focal-proposed) [17.1.2-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted reprozip [source] (focal-proposed) [1.0.14-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [source] (focal-proposed) [0.20.3+dfsg-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted spglib [source] (focal-proposed) [1.14.1-2build1]
-queuebot:#ubuntu-release- Unapproved: cdo (focal-proposed/universe) [1.9.7.1-4 => 1.9.8~rc2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: csync2 (focal-proposed/universe) [2.0-8-g175a01c-4ubuntu2 => 2.0-22-gce67c55-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fpylll [source] (focal-proposed) [0.4.1+ds1-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyside [source] (focal-proposed) [1.2.2+source1-3build4]
-queuebot:#ubuntu-release- Unapproved: accepted rasterio [source] (focal-proposed) [1.0.25-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted skimage [source] (focal-proposed) [0.14.2-2build1]
-queuebot:#ubuntu-release- Unapproved: cron (focal-proposed/main) [3.0pl1-134ubuntu1 => 3.0pl1-135ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: freecad (focal-proposed/universe) [0.18.3+dfsg1-1 => 0.18.3+dfsg1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gdal (focal-proposed/universe) [2.4.2+dfsg-1build4 => 2.4.2+dfsg-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libgeotiff (focal-proposed/universe) [1.5.1-2 => 1.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-monasca-statsd (focal-proposed/universe) [1.10.1-0ubuntu2 => 1.11.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mpi4py-fft [source] (focal-proposed) [2.0.3-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (focal-proposed) [2:4.10.7+dfsg-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: cwltool (focal-proposed/universe) [1.0.20190815141648+dfsg-1ubuntu2 => 1.0.20190915164430+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: grass (focal-proposed/universe) [7.6.1-3build1 => 7.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-preshed [source] (focal-proposed) [2.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: gammaray (focal-proposed/universe) [2.9.0-2.1ubuntu3 => 2.11.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yarl [source] (focal-proposed) [1.3.0-1build1]
-queuebot:#ubuntu-release- Unapproved: pspp (focal-proposed/universe) [1.2.0-2ubuntu2 => 1.2.0-3ubuntu1] (no packageset)
<tomreyn> thanks for the feedback 24h ago, infin1ty (trying not to highlight). also i notice bdmurr4y is back and the 19.10 upgrade path is now enabled. :)
<dax> oh, i didn't see the conversation yesterday, thanks tomreyn
<tomreyn> dax: i didn't do anything other than talking, but if this helped, i'm happy.  ;)
-queuebot:#ubuntu-release- Unapproved: gdb (bionic-proposed/main) [8.1-0ubuntu3.1 => 8.1-0ubuntu3.2] (core)
<dax> i meant thanks for pointing it out, but that interpretation is fine too :P
 * dax scuttles back into the shadows to avoid being more annoying to the release folks than necessary
<vorlon> Laney: autopkgtest web results seem to not be updating for focal, e.g. http://autopkgtest.ubuntu.com/packages/3/389-ds-base/focal/armhf - there are newer test runs on the 18th that are not reflected here.  Does something else need kicked?
<Laney> oooooooooooooooooooohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<Laney> I might hve forgotten to uncomment download-results
<vorlon> ack
<Laney> #*/5 * * * * flock --nonblock /run/lock/download-result.lock sh -c 'for release in $(distro-info --supported | tac); do autopkgtest-cloud/webcontrol/download-results $release; done; autopkgtest-cloud/webcontrol/publish-db'
<Laney> whoopsie
-queuebot:#ubuntu-release- Unapproved: python-crypto (focal-proposed/main) [2.6.1-10ubuntu2 => 2.6.1-11ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-crypto [source] (focal-proposed) [2.6.1-11ubuntu2]
<ddstreet> vorlon for lp #1754671, network-manager 1.10.14-0ubuntu2 has been in bionic-proposed for a long while now, and due to regressions, we want to reject that version, and go with smaller patches to bring the version up to 1.10.6-2ubuntu1.2 (i.e. just normal version bump)...is that possible/acceptable?  anyone who got the n-m version from bionic-proposed would be stuck on the later problematic version
<ubot5> Launchpad bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,In progress] https://launchpad.net/bugs/1754671
<ddstreet> or should the versioning stick with the -proposed version but add ~really1.10.6 or something?
<vorlon> ddstreet: yes, it's acceptable. Anyone who installs from -proposed is on their own for downgrading.
<ddstreet> ack thnx, i'll upload the fixed lower version to the queue today
-queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.6-1ubuntu3 => 3.8-1ubuntu1] (ubuntu-desktop, ubuntu-server)
<ahasenack> perl in proposed-migration has many reds in arm64/armhf, and looks like they are all about missing/broken dependencies of perl itself
<ahasenack> or is the report old perhaps?
<ahasenack> I wonder why just arm
<tkamppeter> ddstreet, thank you for also mentioning this here, I have already asked earlier. Did you get any answer about this?
<tkamppeter> vorlon, how should we proceed with the network-manager SRU for Bionic?
<ddstreet> tkamppeter yep i was just following up on your request in the lp bug - i'm packaging n-m up now and will upload asap, if vorlon or another admin can reject the n-m in bionic-proposed
<vorlon> removing now
-queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.1 => 1.10.6-2ubuntu1.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-9 (focal-proposed/main) [9.2.1-9ubuntu2 => 9.2.1-12ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (focal-proposed) [9.2.1-12ubuntu1]
<tkamppeter> vorlon, ddstreet, thank you very much.
-queuebot:#ubuntu-release- Unapproved: tellico (focal-proposed/universe) [3.2.1-1ubuntu1 => 3.2.1-1ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted tellico [source] (focal-proposed) [3.2.1-1ubuntu2]
<doko> infinity, vorlon: ^^^ that was the last blocker for perl according to output_notest
<doko> ... if it would build ...
<infinity> doko: I'm merging with Debian, looks fixed there.
-queuebot:#ubuntu-release- Unapproved: tellico (focal-proposed/universe) [3.2.1-1ubuntu2 => 3.2.1-2ubuntu1] (kubuntu)
<infinity> doko: ^-- That one builds.
<infinity> (and accepted)
-queuebot:#ubuntu-release- Unapproved: accepted tellico [source] (focal-proposed) [3.2.1-2ubuntu1]
<doko> infinity, tsimonq2: please file a Debian RC issue
<tsimonq2> ...wat?
<tsimonq2> 0
<infinity> tsimonq2: About...?
<tsimonq2> I'm missing context as to why doko pinged me.
<infinity> Erm, I meant...
<infinity> doko: About...?
<doko> tellico
<infinity> doko: The fix came *from* Debian, so I think we're good. :P
<doko> no, having the ubuntu delta disabling these tests
<infinity> Ahh.
<infinity> doko: : Please forward your changes to Debian. ;)
<infinity> Changelog blames you, June last year.
<infinity> But I'm sure someone closer to the KDE team could probably just upload the delta.
<infinity> tsimonq2: Which might be where you were pinged?  I dunno
<doko> crap
 * infinity goes to bed with his illness.
<doko> tsimonq2 was the last merger
<tsimonq2> Ahh.
<tsimonq2> File the bug and I'll do the team upload.
<vorlon> AssertionError: 'aspell-doc version 1.1 required, but 0.60.7~20110707-3ubuntu0.1
<vorlon>  is available\n' not found in 'aspell-doc version 1.1 required, but 0.60.7~20110
<vorlon> 707-3build1 is available\n'
<vorlon> ... an apport test case that breaks when we publish an sru of aspell to xenial?
<doko> iz flaky, override it
<vorlon> no, it's not flaky, it's broken
<vorlon> (and you don't need to tell me to override it, already done - just kvetching here about the state of the test)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu8 => 2.20.11-0ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: subvertpy (focal-proposed/universe) [0.10.1-2ubuntu1 => 0.10.1-2ubuntu2] (no packageset)
<doko> tsimonq2: #942896
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1028.31] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1024.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1028.31~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1006.10] (core, kernel)
#ubuntu-release 2019-10-23
-queuebot:#ubuntu-release- Unapproved: joblib (focal-proposed/universe) [0.13.0-2 => 0.14.0-0ubuntu1] (no packageset)
<mwhudson> vorlon (or any other aa): can you look at my subvertpy and joblib uploads?
<mwhudson> the latter more critically as it's blocking builds of other things
-queuebot:#ubuntu-release- Unapproved: libgetdata (focal-proposed/universe) [0.10.0-6build1 => 0.10.0-6build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: numpy-stl (focal-proposed/universe) [2.9.0-1build1 => 2.9.0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libguestfs (focal-proposed/universe) [1:1.40.2-2ubuntu7 => 1:1.40.2-2ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hidapi-cffi (focal-proposed/universe) [0.2.2-1build1 => 0.2.2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted joblib [source] (focal-proposed) [0.14.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-automaton (focal-proposed/main) [1.14.0-0ubuntu2 => 1.16.0-2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted subvertpy [source] (focal-proposed) [0.10.1-2ubuntu2]
<infinity> mwhudson: What makes you think your hidapi-cffi rebuild will be any different than the previous?
<infinity> mwhudson: Actually, looking at what the build produces, seems that both rebuilds weren't needed?  I don't see any py3 versioned deps or versioned modules.
-queuebot:#ubuntu-release- Unapproved: rejected hidapi-cffi [source] (focal-proposed) [0.2.2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (focal-proposed) [1:1.40.2-2ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted libgetdata [source] (focal-proposed) [0.10.0-6build2]
-queuebot:#ubuntu-release- Unapproved: accepted numpy-stl [source] (focal-proposed) [2.9.0-1build2]
-queuebot:#ubuntu-release- Unapproved: sg3-utils (disco-proposed/main) [1.42-2ubuntu1 => 1.42-2ubuntu1.19.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: libdrm (bionic-proposed/main) [2.4.97-1ubuntu1~18.04.1 => 2.4.99-1ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1024.25]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1006.10]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1028.31]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1028.31~16.04.1]
-queuebot:#ubuntu-release- New source: llvm-toolchain-9 (bionic-proposed/primary) [1:9-2~ubuntu18.04.1]
<mitya57> Hi! When is it planned to start auto-syncs from Debian?
-queuebot:#ubuntu-release- Unapproved: rejected libdrm [source] (bionic-proposed) [2.4.97-1ubuntu1~18.04.2]
<mitya57> I wonder if I will manage to bootstrap Qt 5.12.5 in a PPA before that.
<LocutusOfBorg> mitya57, considering how far migration is, I guess a day or two is still needed to finish rebuilds...
<LocutusOfBorg> I don't know if they plan to land perl or it is "good enough" to open syncs
<mwhudson> infinity: uh i don't remember, one of them had some check that only built 3.8 extensions if numpy was built or something
<mitya57> LocutusOfBorg: ok, two days is enough for me to bootstrap Qt, but the Qt transition itself will happen after the archive is open.
<LocutusOfBorg> mitya57, but I'm not RT, so my answer might be not good
<mitya57> Ack
<LocutusOfBorg> we still have lots of arm64 tests to run, and a few failures that looks bad enough for perl to migrate
<LocutusOfBorg> I hope some more days will be used
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (focal-proposed/main) [19.0.1-1ubuntu1 => 19.1.0-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (focal-proposed/main) [1:19.0.1-1ubuntu1 => 1:19.1.0-1] (desktop-core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: python-greenlet (focal-proposed/main) [0.4.15-2ubuntu1 => 0.4.15-2ubuntu2] (ubuntu-server)
<LocutusOfBorg> doko, ^^ this fixes python-gevent builds
<LocutusOfBorg> debian bug report updated with fixed patch
-queuebot:#ubuntu-release- Unapproved: libdata-stag-perl (focal-proposed/universe) [0.14-2 => 0.14-2ubuntu1] (no packageset)
<LocutusOfBorg> ^^ debian bug opened [11:57:12] <BTS> Opened #943319 in src:libdata-stag-perl 0.14-2 by Gianfranco Costamagna (locutusofborg) Â«libdata-stag-perl: please recommend libxml-libxml-perlÂ». https://bugs.debian.org/943319
<ubot5> Debian bug 943319 in src:libdata-stag-perl "libdata-stag-perl: please recommend libxml-libxml-perl" [Normal,Open]
-queuebot:#ubuntu-release- Unapproved: xorg-server (bionic-proposed/main) [2:1.19.6-1ubuntu4.3 => 2:1.19.6-1ubuntu4.4] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted python-greenlet [source] (focal-proposed) [0.4.15-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pygac (focal-proposed/universe) [1.1.0-3 => 1.1.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyregion (focal-proposed/universe) [2.0-9 => 2.0-9build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyscanfcs (focal-proposed/universe) [0.3.2+ds-2 => 0.3.2+ds-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-cpl (focal-proposed/universe) [0.7.4-2 => 0.7.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: silx (focal-proposed/universe) [0.11.0+dfsg-1 => 0.11.0+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: specutils (focal-proposed/universe) [0.5.2-1ubuntu1 => 0.5.2-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: uvloop (focal-proposed/main) [0.11.3+ds1-2 => 0.11.3+ds1-2build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: photutils (focal-proposed/universe) [0.7-1 => 0.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyresample (focal-proposed/universe) [1.12.3-5 => 1.12.3-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-drizzle (focal-proposed/universe) [1.13.1-2 => 1.13.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sunpy (focal-proposed/universe) [1.0.3-2 => 1.0.3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyraf (focal-proposed/universe) [2.1.15-2 => 2.1.15-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: slixmpp (focal-proposed/universe) [1.4.2-1 => 1.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pysynphot (focal-proposed/universe) [0.9.13+dfsg-1 => 0.9.13+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted photutils [source] (focal-proposed) [0.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyraf [source] (focal-proposed) [2.1.15-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyresample [source] (focal-proposed) [1.12.3-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted pysynphot [source] (focal-proposed) [0.9.13+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-drizzle [source] (focal-proposed) [1.13.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted slixmpp [source] (focal-proposed) [1.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted sunpy [source] (focal-proposed) [1.0.3-2build1]
-queuebot:#ubuntu-release- Unapproved: cron (focal-proposed/main) [3.0pl1-134ubuntu1 => 3.0pl1-135ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: kmod (focal-proposed/main) [26-1ubuntu1 => 26-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: pspp (focal-proposed/universe) [1.2.0-2ubuntu2 => 1.2.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pygac [source] (focal-proposed) [1.1.0-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyscanfcs [source] (focal-proposed) [0.3.2+ds-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted silx [source] (focal-proposed) [0.11.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted uvloop [source] (focal-proposed) [0.11.3+ds1-2build1]
-queuebot:#ubuntu-release- Unapproved: polkit-qt-1 (focal-proposed/universe) [0.112.0-6 => 0.112.0-7.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pyregion [source] (focal-proposed) [2.0-9build1]
-queuebot:#ubuntu-release- Unapproved: accepted specutils [source] (focal-proposed) [0.5.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-monasca-statsd (focal-proposed/universe) [1.10.1-0ubuntu2 => 1.11.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-cpl [source] (focal-proposed) [0.7.4-2build1]
-queuebot:#ubuntu-release- Unapproved: csync2 (focal-proposed/universe) [2.0-8-g175a01c-4ubuntu2 => 2.0-22-gce67c55-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libdrm [source] (bionic-proposed) [2.4.99-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: libdrm (bionic-proposed/main) [2.4.97-1ubuntu1~18.04.1 => 2.4.97-1ubuntu1~18.04.2] (core, xorg)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1048.51] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1048.51]
-queuebot:#ubuntu-release- Unapproved: fpylll (focal-proposed/universe) [0.4.1+ds1-5build1 => 0.4.1+ds1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zbar (focal-proposed/universe) [0.23-1.1build1 => 0.23-1.2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted zbar [sync] (focal-proposed) [0.23-1.2]
-queuebot:#ubuntu-release- Unapproved: accepted fpylll [source] (focal-proposed) [0.4.1+ds1-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mutter (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1+git20191022-1ubuntu1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.3.0-19.20~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.3.0-19.20~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.3.0-19.20~18.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.3.0-19.20~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.3.0-19.20~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.3.0-19.20~18.04.2]
-queuebot:#ubuntu-release- Unapproved: astropy (focal-proposed/universe) [3.2.1-1build1 => 3.2.2-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted astropy [sync] (focal-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- Unapproved: astropy (focal-proposed/universe) [3.2.2-1 => 3.2.2-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected astropy [source] (focal-proposed) [3.2.2-1build1]
-queuebot:#ubuntu-release- Unapproved: astropy (focal-proposed/universe) [3.2.2-1 => 3.2.2-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: amp (focal-proposed/universe) [0.6.1-1 => 0.6.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dolfin (focal-proposed/universe) [2019.1.0-4 => 2019.1.0-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-aiohttp (focal-proposed/universe) [3.5.4-1 => 3.5.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bitshuffle (focal-proposed/universe) [0.3.5-1 => 0.3.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-biom-format (focal-proposed/universe) [2.1.7+dfsg-3ubuntu2 => 2.1.7+dfsg-3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pysmbc (focal-proposed/universe) [1.0.15.6-2 => 1.0.15.6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-cartopy (focal-proposed/universe) [0.17.0+dfsg-6 => 0.17.0+dfsg-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-geotiepoints (focal-proposed/universe) [1.1.8-1 => 1.1.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-skbio (focal-proposed/universe) [0.5.5-2 => 0.5.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: yt (focal-proposed/universe) [3.5.0-1 => 3.5.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-fabio (focal-proposed/universe) [0.9.0+dfsg-1 => 0.9.0+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-thinc (focal-proposed/universe) [6.12.1-1 => 6.12.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-pdal (focal-proposed/universe) [2.1.8+ds-2 => 2.1.8+ds-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted amp [source] (focal-proposed) [0.6.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted bitshuffle [source] (focal-proposed) [0.3.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libdata-stag-perl [source] (focal-proposed) [0.14-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-aiohttp [source] (focal-proposed) [3.5.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-cartopy [source] (focal-proposed) [0.17.0+dfsg-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-geotiepoints [source] (focal-proposed) [1.1.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-skbio [source] (focal-proposed) [0.5.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted yt [source] (focal-proposed) [3.5.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted astropy [source] (focal-proposed) [3.2.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pysmbc [source] (focal-proposed) [1.0.15.6-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-fabio [source] (focal-proposed) [0.9.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-thinc [source] (focal-proposed) [6.12.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted dolfin [source] (focal-proposed) [2019.1.0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pdal [source] (focal-proposed) [2.1.8+ds-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-biom-format [source] (focal-proposed) [2.1.7+dfsg-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-430 (focal-proposed/restricted) [430.50-0ubuntu2 => 430.50-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-430 (bionic-proposed/restricted) [430.50-0ubuntu0.18.04.1 => 430.50-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-435 (focal-proposed/restricted) [435.21-0ubuntu2 => 435.21-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-435 (bionic-proposed/primary) [435.21-0ubuntu0.18.04.2]
<cascardo> rbasak: could you look/approve at makedumpfile at the SRU queues for disco and bionic, please?
<rbasak> cascardo: you'll be first on the list, but I'm not planning on starting my SRU shift for another hour or two
<cascardo> rbasak: that works fine, thanks a lot!
<ahasenack> it looks like the test results in the excuses page isn't updating
<ahasenack> for example, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libfcgi-perl
<ahasenack> the apache2 arm64 regression is from 4 days ago
<ahasenack> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/a/apache2/20191019_003018_b9db3@/log.gz
<ahasenack> and http://autopkgtest.ubuntu.com/packages/a/apache2/focal/arm64 shows green runs
<ahasenack> Laney: related to a cron job you uncommented the other day?
<apw> rbasak, i am already looking at the makedumpfile ones
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (disco-proposed) [1:1.6.5-1ubuntu1.3]
<rbasak> Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (bionic-proposed) [1:1.6.5-1ubuntu1~18.04.3]
<Laney> ahasenack: no, not related. I don't see any passes with that trigger.
<ahasenack> hm
<ahasenack> Laney: I clicked on the retry button, that is green, but the test result link in the excuses page still points at the result from the 19th
<Laney> sorry, what is green?
<ahasenack> maybe I clicked retry on the perl one, actually
<ahasenack> Laney: yeah, it was perl, sorry, that is green now, and result is up-to-date
<Laney> other people like v_orlon and LocutusOfBor_g have been doing retries for perl things as well
<Laney> you might all want to coordinate together to avoid duplicating things
<ahasenack> apache2 is in our list (server)
<ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server
<Laney> sure
<ahasenack> but I can hold off, specially since the archive is still closed, and I'm not sure what is going on
<Laney> but if it's part of another migration then it makes sense to handle it with the folks coordinating that IMO
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20190910.1-0ubuntu1 => 1:20191009.1-0ubuntu1] (no packageset)
<vorlon> Laney: does this error look familiar to you?  I don't see any reason it would fail to find libparams-classify-perl http://autopkgtest.ubuntu.com/packages/b/bioperl/focal/s390x
<Laney> vorlon: It seems like an unfortunate error when the same source package is specified twice
<Laney> laney@nightingale> apt-cache showsrc glibc glibc >/dev/null                                                                                                                                                                       ~
<Laney> W: Unable to locate package glibc
-queuebot:#ubuntu-release- Unapproved: pasaffe (focal-proposed/universe) [0.51-0ubuntu1 => 0.54-0ubuntu1] (no packageset)
<vorlon> Laney: oh did I specify it twice? ok :)
<vorlon> fixed, thanks
<vorlon> (i.e. retriggered)
<Laney> well, yes, but it's still a weird failure mode
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [source] (bionic-proposed) [435.21-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-435 [i386] (bionic-proposed/multiverse) [435.21-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-435 [amd64] (bionic-proposed/multiverse) [435.21-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [amd64] (bionic-proposed) [435.21-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [i386] (bionic-proposed) [435.21-0ubuntu0.18.04.1]
<doko> Laney, vorlon: update_excuses shows "Test in progress (always failed)" for many packages, even for archs with empty queues
<LocutusOfBorg> doko, it might be because of somebody rebooting the service when lots of tests were in the queue...
<Laney> no
<LocutusOfBorg> I retried already lots of "test running" that weren't running, but not for arm64, because queue is still ongoing
<Laney> give an example?
<LocutusOfBorg> there was a lot of test in progress on s390x for example
<LocutusOfBorg> let me find two examples
<doko> Laney: the ones triggered by numpy
<Laney> restarting that machine I did does not cause tests to get lost
<Laney> it'll be much easier to wait for the queue to finish
-queuebot:#ubuntu-release- Unapproved: astropy-healpix (focal-proposed/universe) [0.4-6 => 0.4-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyfai (focal-proposed/universe) [0.18.0+dfsg1-3 => 0.18.0+dfsg1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: poezio (focal-proposed/universe) [0.12.1-3 => 0.12.1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pymca (focal-proposed/universe) [5.5.1+dfsg-2 => 5.5.1+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-430 [source] (bionic-proposed) [430.50-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted poezio [source] (focal-proposed) [0.12.1-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted pymca [source] (focal-proposed) [5.5.1+dfsg-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted astropy-healpix [source] (focal-proposed) [0.4-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyfai [source] (focal-proposed) [0.18.0+dfsg1-3build1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [source] (bionic-proposed) [435.21-0ubuntu0.18.04.2]
<tjaalton> tseliot: ^ both done
-queuebot:#ubuntu-release- Unapproved: reprozip (focal-proposed/universe) [1.0.14-2build1 => 1.0.16-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted reprozip [source] (focal-proposed) [1.0.16-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.32-1~ubuntu18.04.1 => 5.2.34-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.32-dfsg-0~ubuntu18.04.1 => 5.2.34-dfsg-0~ubuntu18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.32-dfsg-0~ubuntu18.04.1 => 5.2.34-dfsg-0~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.32-1~ubuntu18.04.2 => 5.2.34-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: usagestats (focal-proposed/universe) [0.7-5 => 0.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted usagestats [sync] (focal-proposed) [0.8-1]
<LocutusOfBorg> I still don't get why kernel updates that breaks kernel modules aren't caught before publishing the kernel...
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1847662
<ubot5> Ubuntu bug 1847662 in virtualbox-hwe (Ubuntu Bionic) "virtualbox-dkms fails to build with 18.04-hwe-edge kernel 5.3.0-12 [error: void value not ignored as it ought to be, from smp_call_function]" [Undecided,In progress]
<LocutusOfBorg> vorlon, apw ^^ you discussed about a test matrix a while ago, but nobody is looking at it before releasing a kernel?
<LocutusOfBorg> this one https://people.canonical.com/~kernel/status/adt-matrix/bionic-linux-meta-hwe.html
<LocutusOfBorg> virtualbox-hwe and virtualbox are both shown as regressions...4
<vorlon> I do not look at any test matrices before releasing.  I release kernels based on the tracking bugs having been marked as ready for release; it's the kernel team's responsibility to verify the results of testing before doing so
<LocutusOfBorg> sil2100, ^^ if you could quickly have a look at the vbox for bionic, it should fix the dkms sadness
<LocutusOfBorg> I'm trying to understand if we have a process flaw somewhere, not blaming people to be clear :)
<LocutusOfBorg> getting some sort of automated bug report might help avoiding lots of troubles... I already get for devel series, just I don't get them for stable...
<apw> LocutusOfBorg, -edges have a laxer check; is that one in -updates ?
<LocutusOfBorg> yep
<LocutusOfBorg> "virtualbox-dkms fails to build with 18.04-hwe-edge kernel 5.3.0-12
<LocutusOfBorg> so, like "if you use edge, your responsibility to fix bugs"?
<apw> vorlon, that data in theory is taken into a account before we remove the block-proposed tags for those kernels; so you should not get asked to copy things which have not passed adt etc
<LocutusOfBorg> seems legit, to be honest I receive less bugs when hwe-edge breaks dkms
<apw> LocutusOfBorg, we want people to be able to test the bits of -edge which work while we work on the issues
<apw> LocutusOfBorg, in principle dksm failures are a clear blocker for rolling foo -> foo-edge version
<LocutusOfBorg> I don't get... kernel 5.3 is in hwe edge since 4 hours, but my bug report is open since 13 days
<LocutusOfBorg> so maybe that bug report is not from an user but a kernel developer?
<LocutusOfBorg> in any case, please release the kernel together with vbox 5.2.34 so end user won't complain too much
<xnox> apw:  hm, it's hinted as good even though it isn't? can you explain what "hinted good" means?
-queuebot:#ubuntu-release- Unapproved: reprozip (focal-proposed/universe) [1.0.16-0ubuntu1 => 1.0.16-0ubuntu2] (no packageset)
<apw> xnox, hinted good would mean someone looked at the logs and determined that it was a false negative (normally)
<xnox> right
-queuebot:#ubuntu-release- Unapproved: astropy-regions (focal-proposed/universe) [0.4-1 => 0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: reproject (focal-proposed/universe) [0.5-1 => 0.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gammapy (focal-proposed/universe) [0.13-1 => 0.13-1build1] (no packageset)
<xnox> LocutusOfBorg:  it sounds that virtualbox-dkms needs to be fixed to be sensible and innert if the kernel one installs it against has newer module anyway.
<xnox> Error! Module version 5.2.32_Ubuntu for vboxguest.ko
<xnox> is not newer than what is already found in kernel 5.0.0-32-generic (6.0.6_KernelUbuntu).
<xnox> LocutusOfBorg:  thus it shouldn't fail to configure, and well, just be dead weight.
<xnox> or like maybe kernel should autogenerate Breaks: virtualbox-dkms (<< version.shipped.in.this.kernel)
-queuebot:#ubuntu-release- Unapproved: accepted astropy-regions [source] (focal-proposed) [0.4-1build1]
<xnox> such that if one installs hwe kernel, virtualbox-dkms is autoremoved.
-queuebot:#ubuntu-release- Unapproved: accepted reproject [source] (focal-proposed) [0.5-1build1]
-queuebot:#ubuntu-release- Unapproved: cdo (focal-proposed/universe) [1.9.7.1-4 => 1.9.8~rc2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-microversion-parse (focal-proposed/main) [0.2.1-0ubuntu2 => 0.2.1-3] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gammapy [source] (focal-proposed) [0.13-1build1]
-queuebot:#ubuntu-release- Unapproved: python-automaton (focal-proposed/main) [1.14.0-0ubuntu2 => 1.16.0-2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted reprozip [source] (focal-proposed) [1.0.16-0ubuntu2]
<xnox> LocutusOfBorg:  apw: am I wrong about above suggestions?
<infinity> xnox: virtualbox-dkms ships more modules than just the ones included in the kernel.
<xnox> infinity:  ah, but postinst borgs up on the first one which is younger than kernel one?!
<infinity> xnox: But it's true that there's no sane way right now to express relationships between virtualbox-dkms, virtualbox-dkms-hwe, and linux, linux-hwe.
<xnox> sounds akward
<xnox> (cause i assume the extra modules, need to be matching the other ones)
 * xnox slowly backs away
<infinity> They don't.  But you want vbox-dkms-hwe or it probably won't build. :P
<infinity> I think the more correct answer would be to bundle vbox-dkms and vbox-dkms-hwe in the same vbox-dkms package, with the dkms config file pointing at different code per kernel version.
<infinity> Which is entirely doable.
<infinity> Cause trying to express those relationships at the dpkg level in a way that would make apt do sensible things is Very Hard.
<infinity> Wouldn't be hard if we only had one kernel flavour, maybe, but...
<infinity> That ship's not only sailed, it's on its way to Mars.
<apw> xnox, i cann
<infinity> Or, if vendoring all of the source of one version into another is too icky, they could depend on each other, and each dkms.conf could be version-constrained, so you get old modules on old kernels and new on new.
<infinity> That might be better.
 * apw likes the apparent simplicity of the latter
<infinity> I have vbox-dkms installed here specifically to watch for dkms-ish breakage, but I don't run LTSes with multiple kernel tracks, so I don't see this pain first-hand.
<LocutusOfBorg> shouldn't dkms just ignore kernel modules that are already builtin and provide only what is missing?
<LocutusOfBorg> isn't this an easier solution to the problem?
<infinity> LocutusOfBorg: Well, you still want to match hwe to hwe and ga to ga, no?
<infinity> LocutusOfBorg: Since you go out of your way to provide an hwe package that builds with hwe kernels.
<LocutusOfBorg> infinity, I don't think they need to match anymore
<LocutusOfBorg> there have been host/guest breaking changes in the past, but solved since version 5.1 IIRC
<LocutusOfBorg> so, you can use the kernel module, or the vbox dkms one, as you wish, for host and guest
<LocutusOfBorg> all the combinations should be fine now
<LocutusOfBorg> this is why I say, we might build only host guest-dkms modules that are not in the kernel yet
<infinity> LocutusOfBorg: I'm not talking about combinations of vbox and modules, I'm talking about combinations of vbox-dkms and the kernel it's built for.  Do you make sure non-dkms vbox builds okay for hwe kernels?
<LocutusOfBorg> infinity, I usually don't install virtualbox-guest-dkms on my VM machines
<infinity> Err, non-hwe dkms.
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191009.1-0ubuntu1]
<LocutusOfBorg> infinity, you mean vbox-guest-dkms wrt vbox-guest-dkms-hwe
<LocutusOfBorg> ?
<infinity> LocutusOfBorg: This was virtualbox-dkms, not guest-dkms.
<infinity> Or xnox misspoke.
<infinity> Which is possible.
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu0.14.04.4 => 19.6~ubuntu14.04.1] (no packageset)
<LocutusOfBorg> can you please rephrase your question? I didn't really get it
<infinity> So maybe my arguments are all about vbox-dkms, but the vbox-guest-dkms case is indeed that we should just skip stuff that's builtin and newer.
<LocutusOfBorg> vbox-dkms is not in the kernel
<infinity> LocutusOfBorg: Do you ensure that virtualbox-dkms (non-hwe) is buildable with hwe kernels?
<infinity> Yes, I know.
<LocutusOfBorg> yes, it gets similar fixes
<LocutusOfBorg> and it is easy to test, I usually do it
<infinity> Hrm.  Okay.
<infinity> Wouldn't it be easier to just restrict hwe to hwe and ga to ga, as I proposed above?
<LocutusOfBorg> btw, the virtualbox-dkms autopkgtest is almost never failing
<infinity> Then you'd have the same version combinations in play in, say, bionic and eoan.
<infinity> (And that would also paper over the guest-already-built issue, but meh)
<teward> SRU / AA team, can you reject https://launchpadlibrarian.net/447918271/carla_2.0.0-0ubuntu4+gitde67dcb_source.changes from Eoan proposed because it has a version conflict with Focal
<teward> (cc Eickmeyer)
<infinity> teward: Uhh, it does?
<teward> infinity: Focal has -0ubuntu3
<teward> the upload to Eoan has -0ubuntu4+GITREV in it
<infinity> teward: focal has a newer one in the queue.
<teward> infinity: i didn't se that one in the pending queue
<LocutusOfBorg> infinity, but virtualbox-guest-dkms-hwe is *exactly* the same as virtualbox-guest-dkms, just built with newer mesa foo
<LocutusOfBorg> its a workaround for installability with newer xorg
<infinity> teward: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=carla
<teward> infinity: ah, there it is
<teward> nevermind :)
<teward> this is what happens when Eickmeyer asks me for an eyes-on look but doesn't tell me they uploaded to both Focal and Eoan and was only getting flak about Eoan
<teward> :P
<teward> *needs more coffee*
<teward> sorry about noise :)
<teward> infinity: do we have a tool to search all the queues for a given package and see if it's in it and report the info on it?
<teward> i don't think we do, do we?
<infinity> A for loop around 'queue'?
<infinity> (in ubuntu-archive-tools)
<teward> that'd do it
<teward> ty infinity
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190910.1-0ubuntu0.18.04.1 => 1:20191009.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190910.1-0ubuntu0.16.04.1 => 1:20191009.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190910.1-0ubuntu0.19.04.1 => 1:20191009.1-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pyscanfcs (focal-proposed/universe) [0.3.2+ds-2build1 => 0.3.5+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: skimage (focal-proposed/universe) [0.14.2-2build1 => 0.14.2-3] (no packageset) (sync)
<infinity> vorlon: Are you still triggering perly tests, or have you taken a break?
<vorlon> infinity: I'm done with all the necessary mass retriggers; the remainder I would only be triggering based on individual analysis
<infinity> vorlon: Kay.  I was going to retrigger bioperl with itself as a trigger added to your massive list, just didn't want duplicates.
<infinity> (And then going down the list)
<infinity> Honestly, I think given the freeziness of the archive, we could probably get away with just all-proposeding it all, but meh.
-queuebot:#ubuntu-release- Unapproved: accepted pyscanfcs [sync] (focal-proposed) [0.3.5+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted skimage [sync] (focal-proposed) [0.14.2-3]
<vorlon> infinity: bioperl is still falling back to all-proposed and then it's failing; I don't expect adding bioperl to the trigger will help.  I can do another round of analysis of the pkgProblemResolver output
<infinity> vorlon: Hrm?  No, the problem with bioperl is it's running the old tests against the new package.
<infinity> vorlon: The testsuite passes, but the test that looks for a file in @INC fails, cause that file's not there in the new version.
 * infinity re-runs.
<infinity> vorlon: Oh, at least, that was the problem with the perl-triggered bioperl test.  I see the bioperl-triggered one also hates life differently.  Fun.
<infinity> vorlon: Hrm.  bioperl in unstable is intentionally held out with an RC bug.  The right answer might be to punt from proposed and do a rebuild of the release pocket version instead.
<infinity> Wait... bioperl doesn't need a rebuild at all.  Now I'm even more confused.
<vorlon> infinity: right, running old tests against the new package, which happens because of the apt pin being unresolvable and pulling all binaries from -proposed; so a correct if complicated trigger sidesteps the brokenness of bioperl in -proposed.  But yeah I had yet to work out why bioperl was accepted in -proposed and if it was actually needed
<infinity> Why is the new version being pulled into tests of the old one then? >:(
<vorlon> because the autopkgtest apt pin fails
<vorlon> and the fallback is to pull all binaries from -proposed, including bioperl
<infinity> Okay, so just deleting the proposed one is the easiest thing for now.
<infinity> I can copy it back later, or we can wait for another Debian upload to sync it (cause it looks like it might need a breaks/replace or something anyway)
<infinity> Yeah, it'll need a B/R when libbio-perl-run or whatever it is is updated.
<infinity> So I'll just pull it.
<infinity> vorlon: Baleeted.  Re-testing later might actually work.
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1026.29] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1060.69] (kernel)
<vorlon> infinity: but also my latest trigger may have managed to be complete, so we'll see :)
<infinity> vorlon: Hah.
<infinity> vorlon: I'm still fine with deleting it on the basis that it's broken without the Breaks/Replaces, so all is well.
 * vorlon nods
<infinity> perl transitions really highlight the need for some sort of magical trigger resolution in autopkgtest.
<infinity> Given that perl packages almost always test green, but only after you figure out how to manually tell the system to DTRT.
<vorlon> I don't think apt has a setting for "install from -proposed only exactly those packages you need in order to resolve the dependencies", does it?
<teward> vorlon: i've had some success in the past running `apt -t VERSION-proposed install package`
<teward> which might only install those deps
<teward> but that's in a testbed system not autopkgtests, etc.
<teward> might have to hack it around to make it really obey :/
<vorlon> that definitely does not have the semantics we're talking about, no
<teward> i came in late :P
<teward> i've been looking for such a setting/mechanism for some of my automated CI tests too, for things, and haven't found one.
-queuebot:#ubuntu-release- Unapproved: skimage (focal-proposed/universe) [0.14.2-3 => 0.14.2-3ubuntu1] (no packageset)
<teward> (someone should write such a setting!)
<vorlon> the autopkgtest code to manage this is awful; and the fact that sometimes it falls back to installing everything from -proposed, but this isn't exposed in the UI, is also confusing
-queuebot:#ubuntu-release- Unapproved: accepted skimage [source] (focal-proposed) [0.14.2-3ubuntu1]
 * infinity WTFs at command-not-found not command-not-finding on only armhf.
<infinity> vorlon, Laney: Would the world expload if the download-results cronjob was */1 or */2 instead of */5?
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20191009.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20191009.1-0ubuntu0.19.04.1]
<infinity> I keep forgetting how to URL hack to find results I'm waiting on, and really, I don't think I should have to. :P
<infinity> (I'm assuming that job also rebuilds the HTML, but maybe I'm wrong?)
<vorlon> infinity: the job commonly takes >5m to finish, so I don't think that would make much difference
<infinity> vorlon: Ahh, nevermind then. :(
<infinity> We need to figure out a way to batch all that stuff up better somehow.
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20191009.1-0ubuntu0.16.04.1]
<infinity> That's the killer for britney runs too.
<LocutusOfBorg> infinity, breaking only hwe kernels or similar doesn't solve the fact that guest-dkms aims to provide 4 kernel modules, but only one is now builtin in the hwe kernel itself
<teward> infinity: ... stupid question but why're the ubuntu-archive-tools tools written in Py2?
<teward> has nobody attempted a py3 port?
<infinity> vorlon: libcpanplus-perl is fun.  We ask apt to install recommends.  It says "I dunno, that's hard", and doesn't.
<infinity> teward: There's an MP for py3 that literally just changes the shebangs.  I've not tested that this is sufficient.
<teward> it won't be
<teward> you have a LOT of NoLongerValid things in this.
<infinity> teward: As for "why", the answer is "history".
<infinity> LocutusOfBorg: Hrm?  I didn't suggest breaking anything.
<infinity> LocutusOfBorg: I suggested that the dkms.conf for vbox*dkms should version-restrict to the GA kernel, and for vbox*dkms-hwe it should restrict to >> the GA kernel.
<infinity> LocutusOfBorg: Which would end up matching the versions also builtin, assuming you backport current stable to HWE at the same time (or before) the kernel does.
-queuebot:#ubuntu-release- Unapproved: python-gevent (focal-proposed/universe) [1.3.7-1build2 => 1.3.7-1ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted python-gevent [source] (focal-proposed) [1.3.7-1ubuntu1]
<infinity> LocutusOfBorg: Your libdata-stag-perl upload was entirely unnecessary.
<LocutusOfBorg> teward, the python binding used by ubuntu-archive-tools was python2 only...
<LocutusOfBorg> python3-ubuntutools is a new thing...
-queuebot:#ubuntu-release- Unapproved: hidapi-cffi (focal-proposed/universe) [0.2.2-1build1 => 0.2.2-1build1] (no packageset)
<LocutusOfBorg> infinity, what is GA kernel?
<infinity> LocutusOfBorg: The release kernel.  The non-HWE one.  GA = General Availability, shorthand for "release time" in some software circles.
<LocutusOfBorg> oh... thanks
<LocutusOfBorg> but as I said, there is no virtualbox-dkms-hwe package at all
<infinity> LocutusOfBorg: Were there other uploads you did like this one to add unnecessary extra recommends to perl modules?
<LocutusOfBorg> the virtualbox-hwe is only providing *guest*packages
<LocutusOfBorg> infinity, I only did one perl upload
<infinity> Okay.  I'm deleting it, FYI.
<LocutusOfBorg> should I close the debian bug?
<infinity> The bug isn't missing deps, it's missing test triggers which cause apt to give up installing recommends.
<infinity> Yes, close the Debian bug.
<infinity> Adding more recommends won't change the issue.
<LocutusOfBorg> but the code is using a perl module that isn't recommended...
<infinity> It's pulled in via other recommends just fine.  Until apt says no because of goofy pinning.
<infinity> If the code directly references the module, the recommends isn't wrong.  It still won't fix this issue, though.
<LocutusOfBorg> infinity, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943319
<ubot5> Debian bug 943319 in src:libdata-stag-perl "libdata-stag-perl: please recommend libxml-perl" [Normal,Open]
<LocutusOfBorg> they looks like caring about the bug...
<LocutusOfBorg> should I really close it in your opinion?
<infinity> Yes.  And note that in the log you linked, it DOES try to install lixml-perl.
<infinity> And then gives up.
<infinity> Due to pinning.
<infinity> Investigating (0) libxml-perl:amd64 < none -> 0.08-3 @un uN Ib >
<infinity> Broken libxml-perl:amd64 Depends on libxml-parser-perl:amd64 < none | 2.44-4 @un uH >
<LocutusOfBorg> yep, got it :D
<infinity>   Considering libxml-parser-perl:amd64 1 as a solution to libxml-perl:amd64 0
<infinity>   Holding Back libxml-perl:amd64 rather than change libxml-parser-perl:amd64
<infinity> Done
<LocutusOfBorg> with the retitle it is now clear
<LocutusOfBorg> closed
-queuebot:#ubuntu-release- Unapproved: hidapi-cffi (focal-proposed/universe) [0.2.2-1build1 => 0.2.2-1build3] (no packageset)
<infinity> doko: hidapi-cffi already had a python3.8 rebuild (that appeared to do nothing, cause there are no py3.x deps or versioned modules that I can see)... How is this one different?
<doko> I just looked at mwhudson's notes ...
<doko> ahh, that's a package which wants to run the tests on all archs, but really could be a binary all package
-queuebot:#ubuntu-release- Unapproved: rejected hidapi-cffi [source] (focal-proposed) [0.2.2-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected hidapi-cffi [source] (focal-proposed) [0.2.2-1build3]
<LocutusOfBorg> is it possible to bump firewalld hint please?
<LocutusOfBorg> pleeeeeeeease
<LocutusOfBorg> at least we go back in sync with that
<infinity> LocutusOfBorg: Looking.
-queuebot:#ubuntu-release- Unapproved: python-libdiscid (focal-proposed/universe) [1.0-5build1 => 1.0-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-libdiscid [source] (focal-proposed) [1.0-5ubuntu1]
<infinity> LocutusOfBorg: Looks like it's exactly the same test failing so yeah, I can bump the hint but, also, it's exactly one test failing, could we maybe look into why?
-queuebot:#ubuntu-release- Unapproved: pytango (focal-proposed/universe) [9.2.5-1build1 => 9.2.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pytango [source] (focal-proposed) [9.2.5-1ubuntu1]
<vorlon> infinity: still never got the bioperl trigger right, but your unpublish happened, so the last test result is clean ;)
<vorlon> infinity: libsyntax-highlight-engine-kate-perl is similarly a "missing recommends because pinning" situation.  Do we want to do a --all-proposed retry of the lot?
<vorlon> runtests             FAIL stderr: supported-versions: WARNING: Unknown Ubuntu release: 20.04
<vorlon> well aren't you special
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20191009.1-0ubuntu1 => 1:20191009.1-0ubuntu2] (no packageset)
<vorlon> infinity: perhaps you've already done this. perhaps you've also done it in a way that lies to the system and lists no requestor?
-queuebot:#ubuntu-release- Unapproved: veusz (focal-proposed/universe) [3.0.1-1ubuntu2 => 3.0.1-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted veusz [source] (focal-proposed) [3.0.1-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1026.29]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1060.69]
-queuebot:#ubuntu-release- Unapproved: sunpy (focal-proposed/universe) [1.0.3-2build1 => 1.0.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sunpy [source] (focal-proposed) [1.0.3-2ubuntu1]
<infinity> vorlon: Oh, yeah, I've been triggering from snakefruit, so no requestor.  I'm a bad nan.
<infinity> Also a bad man.
<infinity> vorlon: I wonder if there's an apt option to treat failure to install recommends the same as failure to install depends.
<infinity> vorlon: That would make those auto-dep8-recommends passes fail in the apt bit, which would auto-trigger all-proposed.
<infinity> vorlon: Okay, I think everything <= lintian should be good now.  Will check >= lintian after I lunch a bit.
<infinity> Err, <<, not <=
<mwhudson> good morning
<teward> um... anyone know how to get past an issue (daily) with "Release file for [mirror]/ubuntu/dists/focal/InRelease is not valid yet (invalid for another 2h7m11s) Updates will not be applied"?
<teward> looked at it, it seems like it SHOULD be valid by timestamp
<teward> (testing the dailies right now for Lubuntu and can't even apt update)
<Bashing-om> teward: dumb thought from me: system time is correct?
<teward> its a VM and has time set to etc/utc, time LOOKS right let me do some tests
<teward> ... WOW okay so it looks like this is a problem with how it was parsing the system time (it's in a VM).  I'll have to dig into that one, interesting little bug...
<teward> manually set the time and timezone and it's working now
<teward> it's almost like it's ignoring RTCClock
<teward> i'll dig later
-queuebot:#ubuntu-release- Unapproved: python-msgpack (focal-proposed/main) [0.5.6-1build3 => 0.5.6-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-msgpack [source] (focal-proposed) [0.5.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191009.1-0ubuntu2]
<LocutusOfBorg> infinity, in my merge request for the hint I think I explained why
<LocutusOfBorg> the failure is actually a regression in nftables, that is already worked on by upstream
<LocutusOfBorg> the -2 nftables upload fixed 3 out of 4 failures
<LocutusOfBorg> we still have one left (I already proposed to use firewalld as nftables personal regression testsuite since it catches a lot of regressions!)
<LocutusOfBorg> infinity, btw you (IIRC) dropped alt-ergo permanent hint on armhf... can you please restore it (NBS)
<LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/373867
-queuebot:#ubuntu-release- Unapproved: python-apt (focal-proposed/main) [1.9.0ubuntu2 => 1.9.0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (focal-proposed) [1.9.0ubuntu3]
<infinity> LocutusOfBorg: I did?
<LocutusOfBorg> sorry, vorlon did
<LocutusOfBorg>     Restore alt-ergo hint, dropped by mistake on
<LocutusOfBorg>     revno: 3795
<LocutusOfBorg>     committer: Steve Langasek <steve.langasek@canonical.com>
<LocutusOfBorg> https://bazaar.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/revision/3795
<LocutusOfBorg> it was probably a mistake I would say...
<infinity> He probably dropped it cause the syntax was wrong, assuming that it couldn't possibly have ever worked. :P
<LocutusOfBorg> it did work...
<LocutusOfBorg> don't ask me why, but I'm pretty sure it worked
<infinity> LocutusOfBorg: Anyhow, hint restored.
<LocutusOfBorg> I wish with the "all" keyword :) lovely thanks
<doko> infinity, vorlon: please update the hint to the new version of python-scipy
<infinity> doko: Done.
-queuebot:#ubuntu-release- Unapproved: lintian (focal-proposed/main) [2.28.0 => 2.29.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lintian [sync] (focal-proposed) [2.29.0]
<infinity> Did we need another lintian?
<LocutusOfBorg> according to libclone-perl yes...
<infinity> That was testing 2.22.0
<infinity> I was already re-running tests for 2.28.0
<infinity> Oh well.
<LocutusOfBorg> 2.29 mentions a python fix... maybe the person who syncd it needed it
<infinity> The person was doko, so maybe.
<doko> sorry, yes
<vorlon> LocutusOfBorg: so what is triggering the alt-ergo autopkgtests on armhf given that it builds only arch-dep packages and there is no armhf binary?
<infinity> vorlon: Huh.  perl's failure to pass its own tests is a total mystery to me.  That version passes in unstable, but fails the same way in testing and focal-proposed.  Diffing artifacts between testing and unstable shows no diffefrences other than a slightly newer python and slightly newer gcc, both of which we have.
<LocutusOfBorg> vorlon, please don't ask me, I don't know... I'm just trying to make the package migrate
<LocutusOfBorg> After this operation, 4,133 kB of additional disk space will be used.
<LocutusOfBorg> Get:1 http://ftpmaster.internal/ubuntu eoan/universe armhf alt-ergo armhf 1.30+dfsg1-2 [1,283 kB]
<LocutusOfBorg> interesting...
<LocutusOfBorg> vorlon, maybe the old cruft package has been around in eoan for a while?
<LocutusOfBorg> rmadison doesn't show it
<infinity> Oh, that's fun.
<LocutusOfBorg> I'm thinking to just no change rebuild it, just to see what happens
<infinity> Huh?
<infinity> No.
<infinity> Don't.
<infinity> That's not even the source version in eoan.  What on earth do you think a rebuild would do?
<LocutusOfBorg> oh... got it
<LocutusOfBorg>  	2019-07-30 14:03:18 CEST	Superseded	Eoan	release	universe	math	1.30+dfsg1-2
<LocutusOfBorg> eoan had for a little time the old version on armhf...
<infinity> Anyhow, that weird oops doesn't appear to have duplicated itself to focal.
<LocutusOfBorg> so, a no change rebuild should not even start for armhf the autopkgtests
<LocutusOfBorg> so, it should not "need" the hint...
<infinity> I mean, it needs the hint currently.
<infinity> But yes, maybe not once this version migrates.
<LocutusOfBorg> this version migrated some seconds ago
<LocutusOfBorg> this is why I was thinking to no-change rebuild and see what happens
<infinity> Yeah, please don't?
<LocutusOfBorg> ok so I remove the directory
<infinity> the... what?
<LocutusOfBorg> I had the dput of the no change rebuild ready to go, and I dropped it :)
<LocutusOfBorg> Laney, can you please look at boost1.67 autopkgtests on arm64? they all look test in progress... (maybe this is something like what doko mentioned some hours ago)
#ubuntu-release 2019-10-24
-queuebot:#ubuntu-release- Unapproved: numpy (focal-proposed/main) [1:1.17.3-0ubuntu1 => 1:1.17.3-0ubuntu2] (no packageset)
<mwhudson> vorlon, infinity: can one of you approve that pls?
-queuebot:#ubuntu-release- Unapproved: silo-llnl (focal-proposed/universe) [4.10.2.real-6build1 => 4.10.2.real-6ubuntu1] (no packageset)
<vorlon> mwhudson: humpty numpy accepted
-queuebot:#ubuntu-release- Unapproved: accepted numpy [source] (focal-proposed) [1:1.17.3-0ubuntu2]
<vorlon> infinity: looks to me like profphd is simply broken with new perl and should be removed along with predictprotein revdep (Debian bug #942064)
<ubot5> Debian bug 942064 in src:profphd "profphd: autopkgtest failure" [Important,Open] http://bugs.debian.org/942064
-queuebot:#ubuntu-release- Unapproved: accepted silo-llnl [source] (focal-proposed) [4.10.2.real-6ubuntu1]
<vorlon> infinity: libextutils-parsexs-perl is present in Debian unstable; it is not present in Ubuntu or in testing (removed because it's the old version which is broken by new perl).  The package's test uses upstream source data which lists which versions are broken/replaced/provided by perl.  The upstream source data lists the version as '3.40'.
<vorlon>         # the number of digits is a pain
<vorlon>         #  we use the current version in the Debian archive to determine
<vorlon>         #  how many we need
<vorlon> infinity: ^^ so the test relies on there being an available version of this package in the archive which can be compared against, in order to figure out how many 0s to stick at the end of the upstream version number when comparing with what's in debian/control. :P
<vorlon> so it's a bad test and I'm hinting it through for now
<vorlon> doko: hamlib autopkgtest broken on no-change rebuild by the dh-python move from python to python2
-queuebot:#ubuntu-release- Unapproved: hamlib (focal-proposed/universe) [3.3-5build1 => 3.3-5ubuntu1] (no packageset)
<LocutusOfBorg> vorlon, ^^ this fixes, but the last debian upload dropped the python2 library... it seems to be with no rdeps, so feel free to do the sync instead!
<LocutusOfBorg> (this is why I can't open a Debian bug report)
<infinity> vorlon: That test is fixed in (unreleased) 5.30-9, FWIW.
<infinity> vorlon: https://salsa.debian.org/perl-team/interpreter/perl/commit/afc9c66ad31ca747d618d3109e94d54e55567bac
<infinity> vorlon: Wow, that profphd bug is a rollercoaster.
<infinity> vorlon: My favourite part is upstream deeming the bug so "hard" that pulling in a local copy of an 11-year old perl is a better option.
<LocutusOfBorg> infinity, you mentioned a submittodebian crash, is it on which ubuntu-dev-tools version and ubuntu system?
<LocutusOfBorg> I can reproduce with latest ubuntu-dev-tools version on bionic, but seems not in Debian
<LocutusOfBorg> before opening I would like to know your opinion
<LocutusOfBorg>     fp.write(bug_body.encode('utf-8'))
<LocutusOfBorg> TypeError: write() argument must be str, not bytes
<LocutusOfBorg> I get this
<infinity> LocutusOfBorg: Same thing here, running focal.
<LocutusOfBorg> interestingly I opened a sid pbuilder environment and it works... :/
<infinity> LocutusOfBorg: locale-sensitive?  Your pbuilder might be LANG=C
<infinity> Hrm, nope, running under LANG=C doesn't help. :P
<infinity> LocutusOfBorg: https://paste.ubuntu.com/p/sGZb6b8C45/ seems to fix it.
<infinity> (I imagine dropping the .encode() would also fix it, but is less desirable)
-queuebot:#ubuntu-release- Unapproved: firefox (focal-proposed/main) [70.0+build2-0ubuntu1 => 70.0+build2-0ubuntu2] (mozilla, ubuntu-desktop)
<mwhudson> hm so perl is going to migrate on this britney run?
<infinity> mwhudson: Not quite.  There are still some tests to sort out, I think.
<infinity> mwhudson: Close, though.
<infinity> mwhudson: When the set that I've retried get done, I'll diff the block from output and output_notest to see what's missing, cause I'm going cross-eyed trying to read all of excuses. :P
<mwhudson> infinity: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses_by_team.html#foundations-bugs sez candidate
<infinity> mwhudson: Yes, but not everything else that needs to migrate with it is a candidate.
<mwhudson> ah
<mwhudson> right
<infinity> Like I said, iz close though.
<mwhudson> almost time to start bouncing on retry for the python3-defaults things maybe
<infinity> nginx is one of the ones I haven't poke yet.  Might just need --all-proposed, or a well-crafted trigger.
<infinity> And there's the usual "docker tests never work right at the opening of a series".
<infinity> Which I'd like fixed, TBH.  Could the docker tests maybe not rely on current series goodness all being in place?
<infinity> Though it's a good checklist of things that need doing, since I think it relies on debootstrap, lxd, and lxd images all being sorted.
<infinity> Maybe other bits too.
<LocutusOfBorg> infinity, please accept hamlib so the testsuite is happy again and perl goes a little bit further?
<LocutusOfBorg> btw opened debian bug 943385 with your patch
<ubot5> Debian bug 943385 in src:ubuntu-dev-tools "submittodebian: crash on startup [PATCH]" [Normal,Open] http://bugs.debian.org/943385
<mwhudson> infinity: there are lxd images now
<mwhudson> error: requested a non-existing branch on 3.0/stable for snap "lxd":
<mwhudson>        ubuntu-20.04
-queuebot:#ubuntu-release- Unapproved: accepted hamlib [source] (focal-proposed) [3.3-5ubuntu1]
<infinity> mwhudson: Yeah, not sure if that's by design (and the deb needs updating) or an oops.  Needs stgraber's input.
<mwhudson> right
<mwhudson> isn't that going to break making images too?
<infinity> mwhudson: Nope, images seed from a different branch.
<mwhudson> or is there a ubuntu-20.04 branch on other tracks
<mwhudson> ok
<infinity> Which isn't confusing at all.
<mwhudson> it's bad enough on snaps where i can see all the branches :)
<RikMills> infinity: ok to upload a focal version of a fix I want for a eoan SRU at this stage? I don't believe it will entangle anything. If there was an issue, I would have no prob it being taken out of -proposed
<infinity> RikMills: Or yuo can upload it and it'll just sit in the queue until we're ready to flush it.  *shrug*
<RikMills> fair enough. just thought I better ask :)
-queuebot:#ubuntu-release- Unapproved: kate (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.04.3-0ubuntu3] (kubuntu)
<RikMills> aha. the queue is NOT small. ok ;)
-queuebot:#ubuntu-release- Unapproved: libxml2 (focal-proposed/main) [2.9.4+dfsg1-7ubuntu4 => 2.9.4+dfsg1-7ubuntu5] (core)
<LocutusOfBorg> sigh ^^ libxml2 failed its own autopkgtests because of python->python2 move (I opened a bug report already)
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [source] (focal-proposed) [2.9.4+dfsg1-7ubuntu5]
<LocutusOfBorg> there are a few boost1.67 arm64 tests that are "running" but not really "running"
<Laney> example
<LocutusOfBorg> I would say all of them, according to update_excuses
<LocutusOfBorg> aevol anbox aqsis autodock-vina
<LocutusOfBorg> and so on
<LocutusOfBorg> even its own autopkgtests autopkgtest for boost1.67/1.67.0-13ubuntu2: amd64: Pass, arm64: Test in progress (always failed), armhf: Test in progress (always failed), i386: Test in progress (always failed), ppc64el: Test in progress (always failed), s390x: Test in progress (always failed)
<Laney> anbox {"triggers": ["boost1.67/1.67.0-13ubuntu2"]}
<LocutusOfBorg> ok and what for other architectures? http://autopkgtest.ubuntu.com/packages/b/boost1.67/focal/i386
<LocutusOfBorg> it never run tests against itself...
<infinity> The /running page shows it running on all arches.
<infinity> Make that 4 arches.
<Laney> basically - refresh ;-)
<LocutusOfBorg> oh since 46 minutes, 12 hours ago when I looked, it was not on queue, neither on running...
<LocutusOfBorg> did somebody use a stick in the meanwhile?
-queuebot:#ubuntu-release- Unapproved: gpgme1.0 (focal-proposed/main) [1.12.0-6ubuntu2 => 1.12.0-6ubuntu3] (core)
<LocutusOfBorg> ^^ python->python2 move
-queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.2-2ubuntu3 => 1:4.1.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpgme1.0 [source] (focal-proposed) [1.12.0-6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted suricata [sync] (focal-proposed) [1:4.1.5-2]
<LocutusOfBorg> bad linux kernel not providing libbpf-dev ^^ and making this sync fail...
<LocutusOfBorg> apw, ^^ any reason for this?
<apw> LocutusOfBorg, off the top of my head, no
-queuebot:#ubuntu-release- Unapproved: kate (eoan-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.04.3-0ubuntu2.1] (kubuntu)
<tjaalton> apw: could you move nvidia 435 from multiverse to restriced (bionic)?
<tjaalton> it's a new pkg
<tjaalton> there
<tjaalton> or any AA, really
<LocutusOfBorg> apw, should I file a bug?
<apw> LocutusOfBorg, sure
<apw> tjaalton, sure
-queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.5-2 => 1:4.1.5-2ubuntu1] (no packageset)
<LocutusOfBorg> infinity, ^^ since you did the sync...
-queuebot:#ubuntu-release- Unapproved: postgresql-common (focal-proposed/main) [204 => 204ubuntu1] (ubuntu-server)
<infinity> LocutusOfBorg: Ta.
<infinity> apw: Should we look into our kernel package producing some of the libraries that debian's does?
<apw> infinity, we should yes
<infinity> apw: I guess it's just two, libbpf and libcpupower.
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [source] (focal-proposed) [204ubuntu1]
<apw> we produce the second badly, and the first not at all iirc
-queuebot:#ubuntu-release- Unapproved: cdo (focal-proposed/universe) [1.9.7.1-4 => 1.9.8~rc2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (focal-proposed) [1:4.1.5-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-microversion-parse (focal-proposed/main) [0.2.1-0ubuntu2 => 0.2.1-3] (ubuntu-server) (sync)
<infinity> apw: Yeah, I feel like we've had bits of this conversation before.  Just came up again rigfht now causew we stumbled on something with a libbpf dep in Debian.
<infinity> In fact, the only thing with a libbpf dep in Debian, according to reverse-depends.
<infinity> So hardly critical.
<infinity> cpupower has a few more.
<apw> infinity, and i suspect from the way they are expressed that they ought to be buildable by a package outside the kernel consuming the -sources kind of thing
<infinity> apw: Maybe, but I'm not sure where the value is in that.  We'd want to bump that external package any time any source involved in those libs changes.
<infinity> apw: So makes more sense to just produce them from master, like linux-libc-dev.
<tjaalton> apw: thanks!
<apw> do we though, given they have abis and should only move forward slowly
<apw> anyhow, you are right we should think about it and do something in focal
<infinity> apw: I mean, you're right that they probably don't NEED to be built on every master upload, but then we'd need a complicated thing to make sure that all the source (random internal headers, libbpf code itself, etc) hasn't changed and, if it has, force a rebuild of external package foo.
<infinity> apw: That's a lot of effort to go to to avoid just building it on every kernel upload.
<infinity> apw: And given the library's sizes compared to the kernel itself, I don't think it's a big deal to force it down the pipe when master updates.
<infinity> (Honestly, I think the libs should ship WITH kernels, because upstream doesn't actually guarantee ABI stability, because of course they don't, but then how one even attempts to link to them is a mystery I can't solve)
<infinity> (So, best to ship from master, have an ABI break checker in place, and bump SOVER when upstream breaks ABI, IMO)
<infinity> Ish.
<infinity> Ben's bumped SOVER on libcpupower a couple of times, it looks like, unless upstream's actually started behaving and has done that for him.
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849642
<ubot5> Ubuntu bug 1849642 in linux (Ubuntu) "please provide a libbpf-dev library as debian does" [Undecided,New]
<apw> sforshee, ^^
<infinity> apw: Looks like Ben's doing the ABI tracking and SOVER mangling himself (maybe after I pointed out the problem to him a couple of years ago, I dunno).
<infinity> apw: So probably want to look into what he's doing and be in sync.
<infinity> apw: Or use our own ABI checking stuff to a similar end.
<LocutusOfBorg> I tried to move the discussion on #ubuntu-kernel some minutes ago, sorry for not adding the bug there too
<infinity> apw: Thankfully, names of the shared library packages are meaningless, it's only the dev packages that need to match, so we can go our own way on SONAMEs, even calling them libcpupowerubuntuisdifferent0master if we so choose. :P
<infinity> LocutusOfBorg: Evidently, I fell out of #ubuntu-kernel at some point.
-queuebot:#ubuntu-release- Unapproved: python-msgpack (focal-proposed/main) [0.5.6-1ubuntu1 => 0.5.6-2] (ubuntu-desktop, ubuntu-server) (sync)
<LocutusOfBorg> infinity, please to let suricata migrate hint on ppc64el and s390x the testsuite.
<LocutusOfBorg> both smb and ikev2 tests are new in the release that started failing, and not available on ppc64el and s390x as features (kernel?)
<LocutusOfBorg> :q
<LocutusOfBorg> debdiffing 3.2-2ubuntu6 and 1:4.1.2-2ubuntu3 gives a clear picture about the new stuff that started making the test look sad
<LocutusOfBorg> or maybe the two new features are broken on powerpc and s390x, not sure why
<LocutusOfBorg> I don't know where is the upstream bug tracker
 * apw idly wonders if :q got given emoji status just so people who use vi could cover their errors
 * LocutusOfBorg would add also :w to that list!
-queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.5-2ubuntu1 => 1:4.1.5-2ubuntu2] (no packageset)
<LocutusOfBorg> ^^ sigh, dropping the delta was premature, even if I don't understand why Debian doesn't fail...
<stgraber> infinity: oh right also need to open the branch on 3.0. We're going to want to switch that logic to 4.0 before the 20.04 release too but we need LXD 4.0 to happen first :)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1024.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1047.50] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1024.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1024.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1047.50]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-33.35~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1024.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-33.35~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-33.35~18.04.1]
<infinity> LocutusOfBorg: Have you confirmed that delta fixes it?  The previous version (with that change) was failing in the same way.
-queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (focal-proposed) [1:4.1.5-2ubuntu2]
<infinity> LocutusOfBorg: If this upload of yours doesn't work, I'm tempted to revert to the release pocket version and rebuild that for libevent.
<LocutusOfBorg> feel free to do it now
<infinity> Because you're sure yours won't work? :P
<LocutusOfBorg> I don't think it works, I looked at your change, it seemed good, but indeed there is a failed version in amd64 history
<LocutusOfBorg> I thought our autopkgtest didn't have systemd installed
<LocutusOfBorg> so moving it was healing the system
<LocutusOfBorg> unfortunately old suricata fails with new python
<LocutusOfBorg> :/ sad sadness here... I'm discussing on #suricata-dev the ppc64el and s390x failures, they seems to be related to cargo
<infinity> suricata has no rdeps, the easy solution here for today might be just to delete it from the release pocket.
<LocutusOfBorg> considering how many days I already spent over there, +1 :)
<infinity> Always puzzling when autopkgtests pass in Debian and not Ubuntu, though. :/
<LocutusOfBorg> will you let archive open but no autosync for some days, or you will enable it when you open? any ETA?
<LocutusOfBorg> infinity, I'm already having a look at that...
<infinity> LocutusOfBorg: auto-sync will be turned on when it's open.  There'd be no point in delaying, certain people would just play manual auto-sync instead.
<infinity> Which is not efficient.
<LocutusOfBorg> the reason is to avoid a ton of useless rebuilds...
<LocutusOfBorg> like proj and entangling too much stuff
<infinity> sil2100: ubuntu-image fails its tests due to there being no ubuntu-20.04 track for snapcraft.  Want to hunt down the right people to fix that?
<LocutusOfBorg> there is a transition stat started yesterday in debian, like opencvc
<infinity> LocutusOfBorg: If we allow a week for every transition, we'll be nowhere by feature freeze.
<infinity> LocutusOfBorg: perl's a bit of a special snowflake, cause it reverberates so deeply through the archive (and cause it generally mostly works :P)
<LocutusOfBorg> yes but opencv will make the archive sad since rdeps are not ready yet
<infinity> LocutusOfBorg: "rdeps aren't ready yet" sound like you meant to say "can you blacklist opencv" not "can you not auto-sync".
<LocutusOfBorg> if that works better yes please :D
<sergiusens> infinity, sil2100: I was hunted down and created the ubuntu-20.04 channel branch
<infinity> sergiusens: Yay.
<sil2100> sergiusens: yay \o/
<sil2100> Thanks guys
 * ogra praises the hunters
<LocutusOfBorg> infinity, we might have suricata patches, please let the ubuntu1 in proposed if possible
<LocutusOfBorg> meh also the ubuntu2 is fine, whatever
<rbalint> infinity, +1 for dropping suricata from release, also fever, the reverse recommends
<rbalint> LocutusOfBorg, we can fix suricata later, but thanks!
<infinity> rbalint: No need to drop reverse-recommends, generally.  Why would this one be special?
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1024.24] (core, kernel)
<infinity> Looks like fever can do things without suricata being local.  Also, if I artificially punted it out to proposed, it would just migrate back in anyway.  So, leaving it where it is.
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1024.24]
-queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (disco-proposed) [3.5.1-1ubuntu3.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (bionic-proposed) [3.5.1-1ubuntu3.18.04.1]
<infinity> LocutusOfBorg: So my take is that the suricata test is just cracktastic, and it's a regression in the testsuite, not the software.
<infinity> LocutusOfBorg: On the other hand, the new suricata causing suricata-update's tests to explode on ppc64el and s390x actually is a regression, so that should be looked at if anyone wants it to migrate again.
<infinity> Weird combination of arches that.  The only thing they really have in common is ibm-longdouble, which doesn't seem like a thing that would matter there.
<sil2100> jamespage: hey! Was looking at cinder for disco right now - I see two uploads of that, one sync with 2 bug fixes and a new upstream version
<sil2100> jamespage: should I reject the bileto sync and only consider the new upstream release?
<rbalint> infinity, ack, i thought dropping reverse recommends is preferred
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (disco-proposed) [2:10.3.10-1ubuntu0.19.04.1]
<Odd_Bloke> apw: as you know from having met me, i have two noses :wq
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.3.10-1~ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-20.21] (core, kernel)
<infinity> Odd_Bloke: Do you IRC from vi now?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-20.21]
<LocutusOfBorg> [15:43:25] <infinity> LocutusOfBorg: On the other hand, the new suricata causing suricata-update's tests to explode on ppc64el and s390x actually is a regression, so that should be looked at if anyone wants it to migrate again.
<LocutusOfBorg> this is what I wrote above
<LocutusOfBorg> there are new tests and a failure in detecting rust capabilities
<Odd_Bloke> infinity: I wish
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20191009.1-0ubuntu2 => 1:20191009.1-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (bionic-proposed) [1.0.9-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: pysvn (focal-proposed/universe) [1.9.9-1build1 => 1.9.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pysvn [source] (focal-proposed) [1.9.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xapian-bindings (focal-proposed/universe) [1.4.11-2build1 => 1.4.11-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted xapian-bindings [source] (focal-proposed) [1.4.11-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-microversion-parse (focal-proposed/main) [0.2.1-0ubuntu2 => 0.2.1-3] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [242-7ubuntu3 => 243-2ubuntu1] (core)
<jamespage> sil2100: corey and I may have clashed on that one
<jamespage> lemme peek
<jamespage> sil2100: ignore the sync, use the uploaded version
<jamespage> ignore/reject
<sil2100> jamespage: will do, thanks! ;)
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3 => 242-7ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1.10]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: python-xlrd (focal-proposed/universe) [1.1.0-1 => 1.1.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-xlrd [source] (focal-proposed) [1.1.0-1ubuntu1]
<infinity> Looks like perl is 3 packages away from migrating.  I think.  Will drill to the bottom of that over the next hour.
<vorlon> infinity: do you think the lxd stuff is sorted to where the current docker.io retries will work?
<infinity> vorlon: I sure hope so, cause I retried it.
<infinity> vorlon: If stgraber didn't lie to us, it should be good. :)
<vorlon> ok
<infinity> If he did, at least we know it was a little lie?
<infinity> *rimshot*
<infinity> Actually, to be fair, he didn't say he had opened the 3.0 channel, just that he needed to.  But I took that as an "I'll do that now" thing.
<infinity> stgraber: ^-- Confirm/deny?
<vorlon> infinity: and the third package (after vim and nginx) is postgresql-11.  I've just retried psqlodbc/armhf and will look a bit deeper at psycopg2 right now
<vorlon> /usr/bin/pg_virtualenv: line 235: python3.8: command not found
<vorlon> cute
<stgraber> infinity: yeah, I ran a loop over 2.0, 3.0, latest on 16.04, 18.04, 19.04, 19.10 and 20.04 earlier today, so that should ensure everything is open
<stgraber> since there's no real way to tell :)
<infinity> stgraber: Because of course there isn't.
<doko> why does the command-not-found autopkg test fail just on armhf?
<Laney> it's missing a dependency and that happens to be satisfied on the lxd containers
<Laney> (guess)
<Laney> s/lxd containers/VMs/
<Laney> why everybody has decided to repeatedly retry it is also an interesting question
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-67.76~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-67.76~16.04.1] (kernel)
<infinity> Laney: Any idea what dependency that might be? :P
<Laney> Not in the slightest
<Laney> Makes much more sense for a maintainer to look into it, IMO
<infinity> stgraber: If you're still around, next hurdle: lxc autopkgtests no like focal.
<infinity> stgraber: A lot of "ERROR: Couldn't find a matching image"
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191009.1-0ubuntu3]
<infinity> stgraber: Is that a fixable thing in the short term, or should I just skip that mess for now?
<stgraber> infinity: I added focal to our images about an hour ago
<infinity> stgraber: Hah, so I re-ran this test maybe a few minutes too early. ;)
<stgraber> infinity: just kicked a new image build now, will likely take a couple of hours before they're available on the image servers: https://jenkins.linuxcontainers.org/job/image-ubuntu/987/
<infinity> Oh.
<infinity> Let's just pretend I didn't re-run that test just now.
<vorlon> postgresql-11 sorted with the next run
<infinity> \o/
<vorlon> still waiting for a successful nova run to unblock nginx
<RikMills> could a release team member perhaps summarise the state of play? e.g. is it likely that the archive will open before the weekend?
<RikMills> I am not in a great hurry FWIIW
<infinity> I'd *like* to open it after perl migrates (which is very soon), but doko might object strongly to that until a few more python3.8 things are settled.
<RikMills> ok. if that is as much as can be said, fair enough :)
<infinity> vorlon: You haz nova success.
<infinity> Well, I haz.
<doko> yep, at least autopkg tests itself shouldn't be broken, and having python3-defaults in -proposed is not much fun
<vorlon> infinity: \o/
<infinity> Tempted to stop the publisher and see if britney can dump this all in in one pass.
<infinity> Though I guess it doesn't deeply matter with a mostly closed archive.
<vorlon> infinity, Laney: the issue is that for whatever reason, the armhf lxd containers are missing /var/lib/apt/lists/*Commands-*, so the database generation fails
<Laney> http://archive.ubuntu.com/ubuntu/dists/focal/main/
<Laney> Not generated
<vorlon> ah
<Laney> anyone who knows how that works should raise their hand now
<infinity> That doesn't really explain why the other arches work?
<vorlon> but this doesn't affect the other archs?  are we still using eoan copy-forward images?
<infinity> Are they upgraded from eoan VMs that happen to have the bits?
<Laney> Are there cloud images for focal now?
<vorlon> http://cloud-images.ubuntu.com/focal/ yes
<vorlon> but are they imported into scalingstack
<Laney> Dunno
<vorlon> (is making sure of that on the release opening checklist)
<Laney> If you think it'll be fruitful to dig into the two image build processes, feel free :-)
<Laney> personally I'm not bothered about finding out exactly where the difference is on this fine point
<vorlon> well, how about we sort out the missing cnf databases first
<Laney> yes
<Laney> that's what I'd do
<vorlon> bdmurray: ^^ how do we get the Commands lists into the archive for focal?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-67.76~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-67.76~16.04.1]
<infinity> $ rsync cnf-extractor.internal::cnf-data
<infinity> drwxr-xr-x          4,096 2019/04/24 07:55:38 .
<infinity> drwxr-xr-x          4,096 2018/11/21 10:10:50 disco-backports
<infinity> drwxr-xr-x          4,096 2018/11/21 12:06:43 disco-proposed
<infinity> drwxr-xr-x          4,096 2018/11/21 12:12:56 disco-security
<infinity> drwxr-xr-x          4,096 2018/11/21 12:11:54 disco-updates
<infinity> drwxr-xr-x          4,096 2018/11/22 03:55:27 disco
<infinity> drwxr-xr-x          4,096 2019/04/24 07:30:01 eoan-backports
<infinity> drwxr-xr-x          4,096 2019/04/24 07:51:49 eoan-proposed
<infinity> drwxr-xr-x          4,096 2019/04/24 07:52:28 eoan-security
<infinity> drwxr-xr-x          4,096 2019/04/24 07:52:09 eoan-updates
<infinity> drwxr-xr-x          4,096 2019/04/24 12:03:02 eoan
<infinity> So, yeah, no focal.
<infinity> Now, what host is that really?
<infinity> Some canonistack thing?
<Laney> it's probably generated from a service on wendigo
<Laney> Yes
<Laney> Looks like only mvo has access to that
<infinity> Methinks we should fix that.
<infinity> And then get the fixing up process into NewReleaseCycleProcess.
<infinity> Or it should be made to not need fixing up, ideally.
<vorlon> this is why I tagged bdmurray, there was a conversation about Foundations having access to this and not just mvo, I don't know if that got done yet
<vorlon> but I guess someone's checked the groups on wendigo and found that it hasn't
<infinity> wendigo:~$ getent group prod-cnf-extractor
<infinity> prod-cnf-extractor:x:3294:mvo
<Laney> thanks for the confirmation ;-)
-queuebot:#ubuntu-release- Unapproved: fast5 (focal-proposed/universe) [0.6.5-2build2 => 0.6.5-2ubuntu1] (no packageset)
<Laney> ok, night
<infinity> vorlon: I imagine the group bit can be solved with a strongly-worded ticket, but I also suspect it might be nice to get a quick HOWTO from mvo. :P
<infinity> (Or maybe it's super simple and obvious to dive into)
<infinity> Actually, from what I remember of the code, it probably is rather obvious once you see it.
<bdmurray> How urgent is this? Is mvo not around?
<doko> getting spammed with migration emails
<Laney> This is not an emergency, so I think we can be polite and wait for Michael to be around tomorrow
<infinity> ^
<bdmurray> Probably worth submitting an RT anyway
<infinity> An RT CCed to mvo is a decent compromise between polite and getting stuff done.
<infinity> Who are you going to nominate to get added to that group?  adconrad,vorlon,laney,bdmurray?
-queuebot:#ubuntu-release- Unapproved: pygobject (focal-proposed/main) [3.34.0-1ubuntu1 => 3.34.0-1ubuntu2] (core)
<bdmurray> I'll choose the first of those names based on alphabetical order
<infinity> Maybe an LP person or two, if cjwatson or wgrant consent.
-queuebot:#ubuntu-release- Unapproved: accepted fast5 [source] (focal-proposed) [0.6.5-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pygobject [source] (focal-proposed) [3.34.0-1ubuntu2]
<infinity> But fine, it can just be me for now. :P
<cjwatson> infinity: I don't mind either way
<infinity> bdmurray: There you go.  Colin desperately wants to be a member of the group.
<cjwatson> Bluff
<vorlon> infinity: I was going to suggest that it be some subset of ~ubuntu-archive given where the data is ultimately published
<infinity> vorlon: Right, it should be people who have access to pepo (and occasionally use it).
<infinity> vorlon: Hence my suggestion of LP folks who also happen to be AAs.
<vorlon> ah
<vorlon> so, I was going to suggest adconrad,doko,sil2100,vorlon based on union(foundations,ubuntu-archive) and see after a cycle if anyone complained at being blocked
<vorlon> I would rate "access to pepo" as less relevant here than ubuntu-archive
-queuebot:#ubuntu-release- Unapproved: gexiv2 (focal-proposed/main) [0.10.9-1 => 0.10.9-1ubuntu1] (ubuntu-desktop)
<infinity> vorlon: Perhaps, though it's impossible to debug without.
<vorlon> impossible to debug the last mile, but you could hit the rsync endpoint from anywhere I suppose?
<vorlon> "anywhere"
<infinity> vorlon: That said, we're working to get shells off of pepo entirely, so a fair point.
<vorlon> oh hey look, perl
<infinity> vorlon: I'd smear it around so it's not just FOundations, but if you're asserting ownership...
<infinity> vorlon: I'd prefer a set like adconrad,cjwatson,mvo,laney,vorlon (and a couple more, if you like)
<vorlon> infinity: foundations owns the client, and based on the discussion we already had with mvo, should also own the service
<infinity> But it's not really a critical service that needs OMG RIGHT NOW response either, so I'm not super opinionated on the matter.
<infinity> Alrighty.
<vorlon> I don't mind laney and cjwatson being in the list, but I also don't think it's their responsibility
 * infinity nods.
<infinity> vorlon, doko: More pressing matter, now that perl is migrat{ed,ing}, do we want to argue about what the go point is for thawing the archive and turning on auto-sync?  python3-defaults migrated?  Earlier?  Later?
<vorlon> infinity: from what I can see, python3-defaults isn't entangled in a transition so I don't see any reason to hold up the archive opening until it migrates.  doko?
-queuebot:#ubuntu-release- Unapproved: wslu (bionic-proposed/main) [2.0.0-0ubuntu2~18.04.1 => 2.3.2-0ubuntu2~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wslu (eoan-proposed/main) [2.3.2-0ubuntu1 => 2.3.2-0ubuntu2~19.10.0] (core)
-queuebot:#ubuntu-release- Unapproved: wslu (disco-proposed/main) [2.0.0-0ubuntu2.19.04.0 => 2.3.2-0ubuntu2~19.04] (core)
-queuebot:#ubuntu-release- Unapproved: wslu (xenial-proposed/main) [2.0.0-0ubuntu2~16.04.1 => 2.3.2-0ubuntu2~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wslu (focal-proposed/main) [2.3.2-0ubuntu1 => 2.3.2-0ubuntu2] (core)
<doko> infinity, vorlon: I'm fine with that, but I'd like to get some packages migrated. it's ugly to see stuff like the one I just pointed out on #u-d. so can we delay that until tomorrow?
<infinity> "some packages" doesn't give us a goal to work toward.
<infinity> Do you have specifics? :)
<doko> those from the lower tracker levels that are now built, and didn't yet migrate.
-queuebot:#ubuntu-release- Unapproved: last-align (focal-proposed/universe) [983-1 => 983-1ubuntu1] (no packageset)
<doko> infinity: distro-info maybe
<infinity> distro-info will migrate in an hour or two when the lxc images are built.
<doko> good
-queuebot:#ubuntu-release- Unapproved: accepted gexiv2 [source] (focal-proposed) [0.10.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted last-align [source] (focal-proposed) [983-1ubuntu1]
<bdmurray> doko: are there any other packages then?
<infinity> stgraber: Your i386/default build seems to have eaten itself near the end.
<doko> bdmurray: "those from the lower tracker levels that are now built, and didn't yet migrate"
<vorlon> link to the tracker in question?
<infinity> https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html
<doko> https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html
<stgraber> infinity: yeah, looks like the kernel didn't like living much anymore, it's being retried now
<doko> infinity: what about libevent?
<infinity> doko: libevent was entangled with perl, they should both have migrated together.
<infinity> And indeed they did.
<infinity> stgraber: I'm in first-round funding for my new startup whose mission statement is "we'll do literally anything you want us to do for money, as long as it doesn't involve a computer in any way", if you ever get sick of saying things like "the kernel didn't like living anymore".
<stgraber> :)
<stgraber> infinity: looks like it doesn't like the archive much now: https://jenkins.linuxcontainers.org/job/image-ubuntu/architecture=i386,release=focal,restrict=lxc-priv,variant=default/990/console
<infinity> stgraber: Oh, the archive is probably broken for a publisher cycle or two, perl migration got split across runs.
<stgraber> yeah, looks like it, that package was just published as part of the perl migration
<infinity> Maybe I should have stopped the publisher after all.  Oh well.
<stgraber> so I guess I got lucky with the first round of images hitting just before those packages got published :)
<infinity> Yep.
<vorlon> infinity: I know a guy looking to build walipini greenhouses in Portland, come on down
<bdmurray> if we delay the archive opening until tomorrow and infinity is out, who can ensure that it gets opened?
<infinity> Ping me, ping a GSA in #is if I'm not around, win.
<infinity> stgraber: Looks like the publisher's settled down.  I'm validating no copies got lost, but you're likely good to go to try again.
<infinity> Oh look, we didn't lose any copies.  perl migration complete.
-queuebot:#ubuntu-release- Unapproved: debhelper (focal-proposed/main) [12.6.1ubuntu2 => 12.7ubuntu1] (core)
<doko> who is usually looking at aptdaemon ?
<doko> 1 test failure
<infinity> doko: The guy with all the broken arms.
<doko> ahh
-queuebot:#ubuntu-release- Unapproved: collectd (focal-proposed/universe) [5.8.1-1.3ubuntu1 => 5.8.1-1.3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted collectd [source] (focal-proposed) [5.8.1-1.3ubuntu2]
<vorlon> doko: beets autopkgtests look like a genuine regression with python3.8.  What do you expect to happen with such things?  (But also, why is the autopkgtest for an application testing against py3versions -s  instead of py3versions -d)
<doko> vorlon: I saw this just in odil
<doko> at least in odil it's triggered by Testsuite: autopkgtest-pkg-python
<vorlon> Argument "2ubuntu1" isn't numeric in numeric eq (==) at /usr/share/lintian/checks/debian/changelog.pm line 160.
<vorlon> >_<
-queuebot:#ubuntu-release- Unapproved: python-fann2 (focal-proposed/universe) [1:1.1.2+ds-1build1 => 1:1.1.2+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tlsh (focal-proposed/universe) [3.4.4+20151206-1.1build1 => 3.4.4+20151206-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-fann2 [source] (focal-proposed) [1:1.1.2+ds-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: polkit-qt-1 (focal-proposed/universe) [0.112.0-6 => 0.112.0-7.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tlsh [source] (focal-proposed) [3.4.4+20151206-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-rjsmin (focal-proposed/main) [1.0.12+dfsg1-4ubuntu2 => 1.0.12+dfsg1-5ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (focal-proposed) [12.7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
<mwhudson> omg perl migrated
<mwhudson> <infinity> stgraber: I'm in first-round funding for my new startup whose mission statement is "we'll do literally anything you want us to do for money, as long as it doesn't involve a computer in any way", if you ever get sick of saying things like "the kernel didn't like living anymore".
<mwhudson> you might be 20 years or so too late for this to be practical, sadly
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu5.2]
-queuebot:#ubuntu-release- Unapproved: beets (focal-proposed/universe) [1.4.7-2 => 1.4.7-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.12]
-queuebot:#ubuntu-release- Unapproved: rygel (eoan-proposed/main) [0.38.1-2ubuntu3 => 0.38.1-2ubuntu3.1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted beets [source] (focal-proposed) [1.4.7-2ubuntu1]
<doko> vorlon, infinity: distroinfo/i386 still fails. is this expected?
<doko> lxc
<vorlon> doko: I thought I saw some further comment from infinity about that in scrollback, but I don't really know.  From my POV probably nobody should be building i386 container images for 20.04
<doko> so I'd like to see the following packages to migrate before the archive opening: pygobject, gpgme1.0, libxml2, disto-info, dbus-python, boost1.67, libselinux, pillow
-queuebot:#ubuntu-release- Unapproved: mu-editor (focal-proposed/universe) [1.0.2+dfsg-3 => 1.0.2+dfsg-3ubuntu1] (no packageset)
<doko> - pygobject and pillow will migrate
<doko> - gpgme1.0, libxml2, boost1.67, libselinux are blocked by a failing libreoffice autopkg test
<doko> - dbus-python is blocked by aptdaemon
<doko> - distro-info is blocked by lxc/i386
<vorlon> aptdaemon should be a trivial rerun with --all-proposed (triggering this now)
<doko> ahh, libselinux is blocked by lxc, not libreoffice
<vorlon> from an archive and release POV I don't follow why it's appropriate to block the archive opening on these since they are not transitions
<doko> like python-apt?
<vorlon> ?
<doko> see #u-d
<vorlon> that doesn't explain
<vorlon> you gave a list of packages, which are not transitions; I posit that we should not block archive opening on their migration because they are not transitions; you name another unrelated package
<doko> how not? was the hinting premature?
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (focal-proposed/universe) [5.12.4+dfsg-4ubuntu1 => 5.12.5+dfsg-2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-3] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtlocation-opensource-src (focal-proposed/universe) [5.12.4+dfsg-1 => 5.12.5+dfsg-2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtsensors-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebchannel-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebsockets-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (focal-proposed/universe) [5.212.0~alpha3-3 => 5.212.0~alpha3-5] (kubuntu, qt5) (sync)
<RikMills> mitya57: ooooh :)
<mitya57> â: this is the part of Qt 5.12.5 that needed to be bootstrapped. The rest will be auto-synced when auto syncs are turned on.
<doko> mitya57: did that migrate in debian?
<mitya57> not yet
<mitya57> We are blocked on slow buildds, libreoffice autopkgtest failure and pyqt5 hitting NEW.
<doko> do we have the new pyqt5?
<doko> we are blocked on libreoffice anyway
<doko> mitya57: ^^^
<mitya57> doko: what do you mean by new pyqt5?
<mitya57> 5.13?
<doko> mitya57: "... and pyqt5 hitting NEW"
<mitya57> It hit NEW for some unknown reason, only on mips64el.
<doko> ahh, so not in focal
<mitya57> So that doesn't affect us.
<doko> ok, and the current pyqt5 migrated for the python3.8 upload
<mitya57> I added python3.8 compatibility in a bit different way in Debian, but there is no need to sync it now.
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (focal-proposed) [5.12.5+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted qtlocation-opensource-src [sync] (focal-proposed) [5.12.5+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted qttools-opensource-src [sync] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [sync] (focal-proposed) [5.212.0~alpha3-5]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (focal-proposed) [5.12.5-3]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebchannel-opensource-src [sync] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted qtsensors-opensource-src [sync] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebsockets-opensource-src [sync] (focal-proposed) [5.12.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted mu-editor [source] (focal-proposed) [1.0.2+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
<doko> mitya57: ^^^
<mitya57> thanks!
<mitya57> doko: I will do rebuilds when the rest of Qt 5.12.5 is auto-synced.
<vorlon> mwhudson: do you happen to have looked at the gyoto misbuild with python3.8? (/usr/lib/x86_64-linux-gnu/gyoto/7/libgyoto-python3.8.so not linked to libpython3.8)
<mwhudson> vorlon: no
<vorlon> do you want to
<vorlon> :)
<mwhudson> vorlon: i really need to do the cargo update for firefox but it can go on the list after that
<vorlon> ack
<vorlon> is there a python3.8-compatible django somewhere?
<mwhudson> nfi
<vorlon> mwhudson: and psautohint appears to have entirely sensible packaging (it builds an extension only for the current python3 using a python3-dev build-dep), but autodep8 generates an autopkgtest that tries to test against python3.8.  any thoughts?
<mwhudson> vorlon: sounds like autodep8 shouldn't do that?
<mwhudson> vorlon: but i don't know how it works in the slightest
<vorlon> right :)
<vorlon> the existing autogenerated test is correct for non-C modules
<vorlon> and I don't know how autodep8 should detect the difference between compiled extensions and not
<vorlon> (currently it calculates the test based only on the source package, it doesn't look at the binaries in the archive)
<mwhudson> vorlon: X-Python3-Versions? but that's discouraged
<mwhudson> iirc
<vorlon> mwhudson: X-Python3-Versions: current is unsupported, and hard-coding X-Python3-Versions: 3.7 in the source would be wrong
<mwhudson> vorlon: i guess thinking about this a little more, packages that only build for default python are kind of the snowflakes and should declare themselves somehow
<vorlon> I don't think they are snowflakes
<mwhudson> X-Python3-Versions: default-only would be nice but as you say i don't think it is supported
<vorlon> but maybe autodep8 should introspect and look for python3-dev vs python3-all-dev in build-deps
<vorlon> (vs. no python3*-dev)
<mwhudson> vorlon: eh but pure python things have no reason to depend on python3-all-dev iiuc
<vorlon> right, thus the delayed parenthetical
<vorlon> so if build-depends python3-dev && ! build-depends python3-all-dev then: py3versions -d else py3versions -r
<mwhudson> hm i guess the build really should run for all supported python
<mwhudson> oh i don't know
 * mwhudson goes back to updating cargo patches
-queuebot:#ubuntu-release- Unapproved: psycopg2 (focal-proposed/main) [2.8.3-2 => 2.8.3-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted psycopg2 [source] (focal-proposed) [2.8.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: python-jellyfish (focal-proposed/universe) [0.6.1-1build1 => 0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected python-jellyfish [source] (focal-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-jellyfish (focal-proposed/universe) [0.6.1-1build1 => 0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-jellyfish [source] (focal-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-murmurhash (focal-proposed/universe) [1.0.1-2build1 => 1.0.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-murmurhash [source] (focal-proposed) [1.0.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
<vorlon> ImportError: cannot import name 'clock' from 'time' (unknown location)
<vorlon> obviously
-queuebot:#ubuntu-release- Unapproved: python-redis (focal-proposed/main) [3.2.1-3 => 3.2.1-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-redis [source] (focal-proposed) [3.2.1-3ubuntu1]
<mwhudson> vorlon: it's gone in python 3.8
#ubuntu-release 2019-10-25
<vorlon> sure, clocks are overrated
<mwhudson> vorlon: it's time.perf_counter or some such now, but annoying that's not in 2.7
<vorlon> doko: your python-pluggy upload is broken, missing a runtime dep on python3-importlib-metadata
<vorlon> doko: (seen in the tox autopkgtest results on armhf)
-queuebot:#ubuntu-release- Unapproved: psycopg2 (focal-proposed/main) [2.8.3-2ubuntu1 => 2.8.3-2ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted psycopg2 [source] (focal-proposed) [2.8.3-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [19.6~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: thunderbird (focal-proposed/main) [1:68.1.2+build1-0ubuntu2 => 1:68.2.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (bionic-proposed) [4.3.8.12175.20140902+dfsg-0ubuntu12~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [amd64] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [armhf] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [ppc64el] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [arm64] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [s390x] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted libxmlb [i386] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
<Laney> I added c-n-f to NRCP and EOLP
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [12-3bionic2 => 12-7~ubuntu18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (bionic-proposed) [1.2.5-1ubuntu1~ubuntu18.04.1]
<Laney> And retried it on lxd, which passed
<Laney> Gude tymes
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (bionic-proposed) [2:13.0.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: cargo (focal-proposed/universe) [0.37.0-3ubuntu2 => 0.38.0-0ubuntu1] (no packageset)
<mwhudson> oops didn't mean to upload cargo to the main archive
<mwhudson> ah well, not harmful
<Laney> can reject it if you want
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1006.6] (core, kernel)
<mwhudson> Laney: if it's annoying clutter, go for it, if it can just sit there until opening that's also fine
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.9-0ubuntu2 => 1.2.10-1ubuntu2~ubuntu18.04.1] (desktop-core)
<Laney> mwhudson: nae bother to me
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (bionic-proposed) [2018.07~rc3+dfsg1-0ubuntu3~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1006.6]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1024.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1005.5] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1024.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1005.5]
-queuebot:#ubuntu-release- Unapproved: odil (focal-proposed/universe) [0.10.0-3 => 0.10.0-3ubuntu1] (no packageset)
<rbalint> disco's update_excuses did not refresh since 2019.10.18, is it a known issue?
-queuebot:#ubuntu-release- Unapproved: accepted geary [source] (bionic-proposed) [0.12.4-4~ubuntu18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (bionic-proposed) [1.8.10-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (bionic-proposed) [1.10.6-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted rygel [source] (eoan-proposed) [0.38.1-2ubuntu3.1]
<tjaalton> rbalint: hi, the correct version for wslu eoan sru would IMO be -0ubuntu1.1
<tjaalton> and reuse the original bug
<tjaalton> rbalint: I see, it's backported for all, not just eoan
<xnox> sil2100:  i'm sure you will like the FTBFS fix for s390-tools bionic sru
 * xnox *shame* *shame* *shame*
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu3.4 => 2.3.0-0ubuntu3.5] (core)
<doko> mitya57: you might want to give back at the qt5 autopkg tests, with correct triggers
<mitya57> doko: it won't migrate anyway without the rest of 5.12.5 and rebuilds.
-queuebot:#ubuntu-release- Unapproved: python-pluggy (focal-proposed/universe) [0.13.0-0ubuntu1 => 0.13.0-2] (kubuntu) (sync)
<mitya57> If you want I can request the rest of syncs today, but I wanted to wait for autosyncs.
<doko> ok
-queuebot:#ubuntu-release- Unapproved: accepted cargo [source] (focal-proposed) [0.38.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pluggy [sync] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- Unapproved: polkit-qt-1 (focal-proposed/universe) [0.112.0-6 => 0.112.0-7.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted odil [source] (focal-proposed) [0.10.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-rjsmin (focal-proposed/main) [1.0.12+dfsg1-4ubuntu2 => 1.0.12+dfsg1-5ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: kmod (focal-proposed/main) [26-1ubuntu1 => 26-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (focal-proposed) [1:68.2.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
<rbalint> tjaalton, assuming 2.3.2-0ubuntu2 gets accepted to focal what is wrong with the ..~1x.yy.0 ?
-queuebot:#ubuntu-release- Unapproved: glib2.0 (eoan-proposed/main) [2.62.1-1 => 2.62.2-1~ubuntu19.10.1] (core)
<tjaalton> rbalint: first i thought it was just for eoan
<Laney> rbalint: I think someone over-eagerly dropped disco from the list series to run proposed-migration for
<Laney> infinity: please review my ubuntu-archive-scripts cowboy
<Laney> or add me to that bloody team already :-)
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (focal-proposed) [70.0+build2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: sysvinit (focal-proposed/main) [2.95-5ubuntu2 => 2.96~beta-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python-evdev (focal-proposed/universe) [1.2.0+dfsg-1build1 => 1.2.0+dfsg-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-evdev [source] (focal-proposed) [1.2.0+dfsg-1build2]
-queuebot:#ubuntu-release- Unapproved: sysvinit (focal-proposed/main) [2.95-5ubuntu2 => 2.96~beta-3ubuntu1] (core)
<rbalint> Laney, thanks cowboy! :-)
<Laney> ð¤ 
<sil2100> xnox: uh oh!
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.31 => 2.525.32] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.5]
<sil2100> xnox: hah, was wondering why the patches for bionic were causing s390-tools to fail, but it seems like the reason was that bionic is on 2.3.0, right?
<xnox> yes
<infinity> Laney: Huh, did I accidentally drop disco while dropping cosmic?
<infinity> Laney: I sure did.  I guess that was wishful thinking.
-queuebot:#ubuntu-release- Unapproved: pytango (focal-proposed/universe) [9.2.5-1ubuntu1 => 9.2.5-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pytango [source] (focal-proposed) [9.2.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: sysvinit (focal-proposed/main) [2.95-5ubuntu2 => 2.96~beta-3ubuntu1] (core)
<infinity> Laney: Just making sure I didn't make the same stupid mistake anywhere else.
<Laney> Ayeeeeeeee
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [77.0.3865.120-0ubuntu2 => 78.0.3904.70-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fiona (focal-proposed/universe) [1.8.6-2build1 => 1.8.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [78.0.3904.70-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fiona [sync] (focal-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- Unapproved: sysvinit (focal-proposed/main) [2.95-5ubuntu2 => 2.96~beta-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (focal-proposed/main) [1.14ubuntu1.1 => 1.15] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: pyzmq (focal-proposed/universe) [17.1.2-3ubuntu2 => 17.1.2-3ubuntu3] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted pyzmq [source] (focal-proposed) [17.1.2-3ubuntu3]
<infinity> Laney: Committed.
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [19.6~ubuntu14.04.1 => 19.6~ubuntu14.04.2] (no packageset)
<Laney> Ta duck
 * infinity glances up and notes that trusty is doing a really bad job of being EOL.
<infinity> ahasenack: When vorlon accepted the last upload of u-a-t, did he also mention that the trusty version is higher than literally every release after? :/
<vorlon> I did not
<vorlon> infinity: however that's the correct "upstream" version number, and the intent is that it will be SRUed into later series after, but publishing to trusty is the priority
<vorlon> (and the SRU bug mentions wanting to NOT change it yet in later series, because there are other UA services on those releases that are not ready to be migrated to the new client)
<infinity> Fun, fun.
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.34.1-1ubuntu1 => 3.34.1+git20191024-1ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [19.6~ubuntu14.04.2]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1+git20191024-1ubuntu1~19.04.1] (desktop-extra, mozilla, ubuntu-desktop)
<vorlon> doko: so from your list yesterday, the packages that haven't migrated are gpgme1.0, libxml2, and boost1.67, none of which are transitions and all of which are blocked by libreoffice test failures (not quick to iterate on).  Are you ready for us to open the archive now?
<vorlon> infinity, Laney: http://archive.ubuntu.com/ubuntu/dists/focal/main/cnf/ populated now btw
<Laney> Yeah, I retried the test earlier
<doko> vorlon: yes, although I would like to see those migrating too. there's nothing in LO using these 3.8 extensions
-queuebot:#ubuntu-release- Unapproved: fiona (focal-proposed/universe) [1.8.9-1 => 1.8.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pkg-kde-tools (focal-proposed/universe) [0.15.30ubuntu1 => 0.15.31ubuntu1] (kubuntu)
<vorlon> infinity: ^^ ready to open the archive (and some non-blocking stuff to follow through on)
-queuebot:#ubuntu-release- Unapproved: accepted fiona [source] (focal-proposed) [1.8.9-1ubuntu1]
<doko> and I'm just told by the debian libreoffice maintainer that the recent gcc-9 uploads breaks LO
<Laney> maybe we shouldn't have swapped libreoffice out as one of the tests triggered by gcc uploads :-)
<doko> that would be the first issue that LO would trigger ...
<Laney> awesome, tests finding bugs!
<doko> Laney: if that is a code generation bug, then no. then you have to rebuild before autopkg testing
<infinity> vorlon: Mmkay.  I can make it so.
<infinity> doko: Do you have The Email prepped?
<ahasenack> infinity: yeah, this u-a-t is breaking all the rules, carefully
<infinity> ahasenack: I don't approve.  If you're going to break the rules, do it with reckless abandon.
<doko> infinity: yes, I can do that. autosyncs before the weekend?
<infinity> doko: If we open right now, I see no reason we wouldn't turn on autosync too.
<doko> ok, just to know for the email
 * infinity nods.
<infinity> Alright, I'm going to flip the switch and accept the queue backlog.
 * Eickmeyer here we go...
-queuebot:#ubuntu-release- Unapproved: rejected cdo [sync] (focal-proposed) [1.9.8~rc2-1]
-queuebot:#ubuntu-release- New: accepted scribus-ng [sync] (focal-proposed) [1.5.5+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted cdo [sync] (focal-proposed) [1.9.8~rc2-1]
-queuebot:#ubuntu-release- Unapproved: accepted csync2 [source] (focal-proposed) [2.0-22-gce67c55-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx [sync] (focal-proposed) [1:4.2.9.6-6]
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (focal-proposed) [26-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pspp [source] (focal-proposed) [1.2.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-microversion-parse [sync] (focal-proposed) [0.2.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-rjsmin [source] (focal-proposed) [1.0.12+dfsg1-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cron [source] (focal-proposed) [3.0pl1-135ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted freecad [sync] (focal-proposed) [0.18.3+dfsg1-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-automaton [sync] (focal-proposed) [1.16.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted sysvinit [source] (focal-proposed) [2.96~beta-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cwltool [sync] (focal-proposed) [1.0.20190915164430+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-monasca-statsd [sync] (focal-proposed) [1.11.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-qt-1 [sync] (focal-proposed) [0.112.0-7.1]
<infinity> doko: Do be sure to mention in the email that people syncing things that autosync will get to anyway is a complete waste of time and they should learn patience. :P
<infinity> And there's the queue emptied.
<infinity> vorlon: I'll let you enable autosync, so you can babysit it if it seems explodey.
-queuebot:#ubuntu-release- Unapproved: accepted assaultcube [sync] (focal-proposed) [1.2.0.2.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted datalad [sync] (focal-proposed) [0.11.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted doxygen [source] (focal-proposed) [1.8.13-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gammaray [sync] (focal-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keysign [source] (focal-proposed) [1.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gwenview [sync] (focal-proposed) [4:19.08.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted knack [source] (focal-proposed) [0.6.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted magics++ [sync] (focal-proposed) [4.2.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mapserver [sync] (focal-proposed) [7.4.2-1]
-queuebot:#ubuntu-release- Unapproved: rejected mshr [sync] (focal-proposed) [2019.1.0+dfsg1-4]
-queuebot:#ubuntu-release- Unapproved: accepted consul [sync] (focal-proposed) [1.4.4~dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-takao [source] (focal-proposed) [00303.01-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grass [sync] (focal-proposed) [7.8.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libgeotiff [sync] (focal-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted metview [sync] (focal-proposed) [5.7.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted nbconvert [sync] (focal-proposed) [5.6.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted octave-octproj [sync] (focal-proposed) [1.1.5-5]
-queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (focal-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted osm2pgsql [sync] (focal-proposed) [1.0.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted postgis [sync] (focal-proposed) [2.5.3+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted dde-qt-dbus-factory [sync] (focal-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ipykernel [sync] (focal-proposed) [4.9.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted munin [source] (focal-proposed) [2.0.51-1ubuntu1]
<infinity> (It's generally well-behaved ever since Colin implemented the hackish bisection backoff thing, though)
-queuebot:#ubuntu-release- Unapproved: accepted octave [sync] (focal-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted pdal [sync] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [sync] (focal-proposed) [2.2.10-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pyproj [sync] (focal-proposed) [2.4.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted qgis [sync] (focal-proposed) [3.4.12+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted saga [sync] (focal-proposed) [7.3.0+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: accepted sip4 [sync] (focal-proposed) [4.19.19+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted gdal [sync] (focal-proposed) [2.4.2+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: rejected ncl [sync] (focal-proposed) [6.6.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted pynwb [sync] (focal-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted pywps [sync] (focal-proposed) [4.2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted sbcl [sync] (focal-proposed) [2:1.5.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted sphinx-gallery [source] (focal-proposed) [0.2.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sumo [sync] (focal-proposed) [1.3.1-4]
-queuebot:#ubuntu-release- Unapproved: accepted therion [sync] (focal-proposed) [5.4.4ds1-2]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-panel [sync] (focal-proposed) [4.14.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted yodl [sync] (focal-proposed) [4.02.01-3]
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [sync] (focal-proposed) [3.0.22+ds1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pymzml [sync] (focal-proposed) [0.7.6-dfsg-5.1]
-queuebot:#ubuntu-release- Unapproved: accepted spatialite-gui [sync] (focal-proposed) [2.1.0~beta0+really2.0.0~devel2-5]
-queuebot:#ubuntu-release- Unapproved: accepted survex [sync] (focal-proposed) [1.2.42-1]
-queuebot:#ubuntu-release- Unapproved: accepted xygrib [sync] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted yowsup [sync] (focal-proposed) [3.2.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted openvdb [sync] (focal-proposed) [5.2.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted spyder-kernels [sync] (focal-proposed) [1.5.0~really0.5.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted yosys [sync] (focal-proposed) [0.9-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.34.1+git20191024-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-430 [source] (focal-proposed) [430.50-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (focal-proposed) [3.11.1+dfsg-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pkg-kde-tools [source] (focal-proposed) [0.15.31ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (focal-proposed) [3.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (focal-proposed) [1.15]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [sync] (focal-proposed) [19.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted qmapshack [sync] (focal-proposed) [1.13.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted carla [source] (focal-proposed) [2.0.0-0ubuntu5+gitde67dcb]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-435 [source] (focal-proposed) [435.21-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-msgpack [sync] (focal-proposed) [0.5.6-2]
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (focal-proposed) [2.3.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vtk6 [sync] (focal-proposed) [6.3.0+dfsg2-4]
-queuebot:#ubuntu-release- Unapproved: accepted pasaffe [source] (focal-proposed) [0.54-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [sync] (focal-proposed) [1:19.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted kate [source] (focal-proposed) [4:19.04.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (focal-proposed) [243-2ubuntu1]
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Eoan 19.10 | Archive: Open | Focal 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, cheque or gin | melius malum quod cognoscis
<bdmurray> infinity: is the freezes bit in the topic still needed?
<infinity> bdmurray: Lots of people use it as a reference.  But also, if you're looking to weed out inefficiencies, this might not be the place to start. ;)
<bdmurray> infinity: it just caught my eye, I'll go back to something else
<infinity> bdmurray: Or do you mean the silly bit about uploading during freezes?
<infinity> (I assumed you meant the archive state)
<bdmurray> infinity: yes the "Please don't upload"
<infinity> Ahh, yeah.  I didn't write that bit.  It can die.
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Eoan 19.10 | Archive: Open | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<Laney> woohoo, no more freezes!
<infinity> bdmurray: Sorry, I thought you were question the archive state process, not the silly finger-wagging. :P
 * infinity might be slightly over-sensitive to people questioning process lately.
-queuebot:#ubuntu-release- New: accepted lubuntu-update-notifier [source] (focal-proposed) [0.1]
<infinity> That was a quick review.
<infinity> Or someone pre-reviewed it and was just waiting for the opening?
<doko> there was not much to review
<infinity> Fir enough.
<infinity> Fair, too.
<infinity> Or fir.
<infinity> Whatever.
<infinity> I'm off for the weekend.  Happy hacking.
<doko> well, when autosyncs?
<infinity> When vorlon changes the crontab.  I'm leaving it to him.
<infinity> (but it should be basically now)
<infinity> Next run would be at 2300 UTC if it uncronned now anyway.
<infinity> So, I guess not quite now. :)
-queuebot:#ubuntu-release- Unapproved: mutter (eoan-proposed/main) [3.34.1-1ubuntu1 => 3.34.1+git20191022-2ubuntu1~19.10.1] (desktop-core, desktop-extra)
<infinity> Meh, screw it.  I'll uncron it, and we can both look at logs later.
<infinity> ^-- vorlon
<infinity> And maybe I'll squeeze in a run at 1800 just to get the show on the road.
<infinity> Done and done.
<infinity> auto-sync should start grinding away in ~40m.
<infinity> Oh, but the current dry-run looks like it'll take more than an hour.  Bother.  I shall kill that.
<Eickmeyer> infinity: Got a ftbfs on Carla... looks like it's upset about pyqt5-dev-tools.
<Eickmeyer> Strange.
<infinity> Eickmeyer: Given a new qt5 in proposed, that seems entirely plausible.  Not sure why you're telling me. ;)
<doko> mitya57 said qt5 would need more syncs
<Eickmeyer> infinity: You answered the question I was going to ask before I could ask it. Thanks! lol
<Eickmeyer> I'll just try a rebuild in a few hours then.
<infinity> s/hours/days/ ?
<infinity> auto-sync takes a while to grind through the backlog. :P
<Eickmeyer> Or that. XD
<infinity> I assume mitya57 will also try to force some qt5 love in the middle of it all.
<infinity> But, for the most part, people should not worry too much about the horror that will befall the archive over the weekend until after most of it's happened.
<infinity> Cause there's not a lot you can do mid-sync.
<Eickmeyer> Ok. Good to know.
-queuebot:#ubuntu-release- New binary: lubuntu-update-notifier [amd64] (focal-proposed/universe) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdal [ppc64el] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdal [s390x] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scribus-ng [i386] (focal-proposed/universe) [1.5.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scribus-ng [ppc64el] (focal-proposed/universe) [1.5.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scribus-ng [amd64] (focal-proposed/universe) [1.5.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scribus-ng [s390x] (focal-proposed/universe) [1.5.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lubuntu-update-notifier [amd64] (focal-proposed) [0.1]
-queuebot:#ubuntu-release- New binary: pdal [amd64] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdal [i386] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvdb [s390x] (focal-proposed/universe) [5.2.0-7] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: octave [s390x] (focal-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: openvdb [amd64] (focal-proposed/universe) [5.2.0-7] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: octave [i386] (focal-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pdal [armhf] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdal [arm64] (focal-proposed/universe) [2.0.1+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [ppc64el] (focal-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted pdal [amd64] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted pdal [armhf] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted pdal [ppc64el] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New binary: openvdb [i386] (focal-proposed/universe) [5.2.0-7] (ubuntustudio)
-queuebot:#ubuntu-release- New: accepted pdal [arm64] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted pdal [s390x] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted pdal [i386] (focal-proposed) [2.0.1+ds-1]
-queuebot:#ubuntu-release- New: accepted scribus-ng [amd64] (focal-proposed) [1.5.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scribus-ng [ppc64el] (focal-proposed) [1.5.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scribus-ng [i386] (focal-proposed) [1.5.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted scribus-ng [s390x] (focal-proposed) [1.5.5+dfsg-1]
<infinity> stgraber: Could you maybe mute queuebot for the weekend?  auto-sync spam is pretty meaningless for IRC and just makes the channel unreadable.
<bdmurray> vorlon: Can you review the following? https://code.launchpad.net/~brian-murray/apport/ep-and-focal/+merge/374745
<vorlon> bdmurray: why is LP showing me a lot of non-focal/eoan stuff in the delta?
<stgraber> queuebot: mute queue focal-proposed
<stgraber> mute queue focal-proposed
<infinity> stgraber: Oh, that's a thing?  Did I know that was a thing and forgot?
<queuebot> Added mute entry: ['#ubuntu-release', 'queue', 'focal-proposed']
<infinity> Anyhow, neat.
<stgraber> infinity: I remembered it being a thing, just couldn't remember the syntax :)
<infinity> stgraber: Reverse == unmute?
<stgraber> yep
<infinity> Yay.  Thanks.
<infinity> Odd that I remember this for more than a week?
<bdmurray> vorlon: wow, I've no idea
<stgraber> just hoping that the feature actually works :) we'll know soon enough
<bdmurray> vorlon: Oh, its the wrong target branch.
<stgraber> infinity: well, queuebot crashes pretty often, if you don't remember to unmute, it will unmute itself the next time it's sad
<infinity> stgraber: Hahaha.
<bdmurray> vorlon: sorted - https://code.launchpad.net/~brian-murray/apport/ep-and-focal/+merge/374746
<vorlon> bdmurray: cool, landed
<infinity> bdmurray: Why do we not enable proposed from archive opening?  Is it that we consider anything in proposed effectively garbage until release, or...?
<infinity> It would seem like if someone filed a bug on a crash in a proposed version, that might still be useful info before it migrates.
<infinity> Oh, but I guess you're using it as a source to pull deps from and such too, which would go poorly.
<infinity> Nevermind.
<bdmurray> infinity: some time in the past it didn't exist
<doko> python-scipy/amd64 test timing out after 77% of the testsuite, can we try to move it to a big instance?
<bdmurray> I mean -proposed wasn't available on ddebs.ubuntu.com until after release
<bdmurray> for some previous release
<bdmurray> infinity: Actually here's the right answer https://code.launchpad.net/~brian-murray/apport/no-devel-proposed/+merge/363629
<infinity> bdmurray: Right, that was my assumption that led to my "nevermind".
<mitya57> infinity: if you want Qt 5 to migrate earlier, I can do manual syncs today
<vorlon> mitya57: what manual syncs would you be doing when the autosync is turned back on now?
<mitya57> You said that the backlog is huge so I thought maybe I can jump ahead of queue this way. But I don't really want this :)
-queuebot:#ubuntu-release- Unapproved: mdadm (eoan-proposed/main) [4.1-2ubuntu3 => 4.1-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (disco-proposed/main) [4.1-1ubuntu1 => 4.1-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.2 => 4.1~rc1-3~ubuntu18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5.7 => 240-6ubuntu5.8] (core)
#ubuntu-release 2019-10-26
<vorlon> rabbitmq was unhappy (request.cgi hanging); restarted
-queuebot:#ubuntu-release- Unapproved: remmina (eoan-proposed/main) [1.3.4+dfsg-3ubuntu1 => 1.3.6+dfsg-2ubuntu1] (ubuntu-desktop)
<LocutusOfBorg> please KILL remmina with fire! I prepared the merge in my ppa and didn't sed eoan/focal :/
-queuebot:#ubuntu-release- Unapproved: rejected remmina [source] (eoan-proposed) [1.3.6+dfsg-2ubuntu1]
<LocutusOfBorg> hello, what is the django fate for focal? I think we should aim to 2.* right?
<LocutusOfBorg> infinity, cjwatson, I got a dkms build failure on focal, due to debhelper...
<LocutusOfBorg> can I please do a quick merge?
<infinity> LocutusOfBorg: a debhelper merge?  I'll pick it up.
<LocutusOfBorg> thanks!
<LocutusOfBorg> thanks to whoever retried dkms
<infinity> LocutusOfBorg: I retried all of -proposed. :P
<LocutusOfBorg> lovely thanks^2!
<LocutusOfBorg> I'm pretty sure it wasn't the only one failing because of that
<infinity> cjwatson: Does https://launchpad.net/ubuntu/+source/rumur/2019.02.04-1/+build/17974910 look like another manifestation of that same dh bug, but slightly different (note this was built with the new debhelper that supposedly solves this)
<LocutusOfBorg> and cleaning up python-genpy now NBS in proposed would be awesome
<infinity> Weirdly, i386 worked...
#ubuntu-release 2019-10-27
<LocutusOfBorg> hello, opencv fails with ENOSPACE on amd64... cp: error writing 'debian/libopencv-imgproc-dev//usr/lib/x86_64-linux-gnu/libopencv_imgproc.a': No space left on device
<LocutusOfBorg> can we do something to increase the space?
