#ubuntu-release 2010-05-17
<lamont> slangasek: when the need arises, you have maverick-live chroots
<slangasek> yay
<ScottK> slangasek: Is it possible to remove images from the Kubuntu ports releases page?
<slangasek> ScottK: I'm a little uncomfortable removing them after the fact - are they completely unusable?
<ScottK> slangasek: I think it's reasonable to say the sparc one is.
<ScottK> Our status is: powerpc - somewhat tested and believed to work, ia64 - untested, but may work, sparc - the entire port is broken, so no point in testing.
<slangasek> howso?  I heard that the conclusion last week was that sparc is busted and not going to get better, but I don't have details
<ScottK> I didn't hear details beyond the kernel doesn't work.
<ScottK> That was enough for me.
<ScottK> Maybe lamont knows.
<slangasek> lamont: do you know?
<ScottK> perhaps more relevant, perhaps lamont will admit to knowing....
<lamont> heh
<lamont> so... the conclusion of the "what about ia64/sparc (and ppc)?" session:  keybuk to go to tech board for ratification and mailing under their from address that sparc is clearly (1) broken and (2) not being loved, therefore all y'all have until feature freeze to make it work, or it'll be removed and lucid will be the last sparc release until such time as revived.
<slangasek> lamont: clearly broken how?
<lamont> re: ia64:  clearly neglected, but basically working.  Needs a new toolchain champion (as does sparc), doko won't be spending time on it other than vetting patches and uploading for the champion(s).
<lamont> slangasek: upgrading from jaunty to karmic causes a reboot in a state where the machine is unbootable.  lucid lacks a kernel, I'm not sure of the state of installability from media in even karmic.
<slangasek> "lacks a kernel"?
<slangasek> there is one in the archive
<lamont> ppc: has a strong community, seems to be doing ok, we'll address that one sometime between now and whatever will expire after the next LTS
<lamont> slangasek: if only it booted
<slangasek> why doesn't it boot, what range of hardware has this been verified on, is there a bug #?
<lamont> slangasek: nfc here.  pure hearsay
<slangasek> well, hmm.  Hearsay from whom?
<slangasek> I'm not willing to nuke images from the release that we won't be able to get back afterwards, based on hearsay alone
<lamont> my sparc box is not very happy (at least according to the guy I loaned it to last), and I haven't played with it in forever
<slangasek> (well, ok, we can get those back afterwards by rebuilding from the release pocket, but)
<lamont> slangasek: I don't see any reason to nuke them, given that they're clearly not supported in any case
<slangasek> the reason to nuke them is that they're kubuntu images and the kubuntu folks (in person of ScottK) are asking for the nukage
<ScottK> It's not essential to have it removed, but if we're going to point people at the ports directory, it would seem CoC friendly not to point them at known broken stuff.
<ScottK> OTOH, the odds of anyone caring about sparc and a desktop are low enough, meh.
<lamont> at least add a header to the html in the directory saying "known broken, fixes welcome"???  dunno
#ubuntu-release 2010-05-18
<Riddell> hmm, mass-sync is broken :(
<Riddell> (or the launchpad lib it uses)
<cjwatson> broken?
<Riddell> cjwatson: http://paste.ubuntu.com/435516/
<cjwatson> doesn't look particularly specific to mass-sync
<Riddell> right
<doko> ubuntu-archive: please promote libgraph4 libpathplan4 libxdot4 libgvc5 libgvpr1 (assume all of this are doxygen/graphviz deps)
<cjwatson> doko: done
<doko> cjwatson: libcdt4 libcgraph5 as well please
<cjwatson> doko: done
<cjwatson> doko: (feel free to do binary promotions yourself when the source package is already in main)
<doko> ok
<lamont> slangasek: btw, fdupes takes like 20 seconds
<slangasek> lamont: this is in the context of cjwatson suggesting that should be omitted because it's an expensive no-op?
<lamont> oh. thought that was you.
<lamont> yeah
<lamont> manifest building is a bit more
<lamont> 19:10:27	301	19:05:37	68	19:11:10	201	start livefs_squash
<lamont> that's a bit more interesting
<lamont> king, kapok, terranova
#ubuntu-release 2010-05-19
<ScottK> slangasek: We've got a new project this cycle for Kubuntu that may or may not get mature enough for ISOs in this cycle.  Would you rather get images started early and get a "nevermind, not mature enough - stop" or wait and see and potentially get a request later in the cycle for new images?
<slangasek> ScottK: IMHO it's better to start the images early
<ScottK> slangasek: Thanks.  I'll work on that.
<cjwatson> could somebody who isn't me review openssh in lucid-proposed?
<slangasek> cjwatson: looking
<lamont> doko: your gnat-4.4 build is live on vernadsky, should succeed
<lamont> doko: btw, does it make sense to let the gnat-4.4 build on buttercup finish?
<lamont> (and do wait for i386 to finish before you upload a new gnat-4.4, right...)
<doko> lamont: yes: still building with the older gcc-4.4
<doko> no need to upload a new gnat-4.4, just need the new gcc-4.4 to build it
<lamont> ah, ok
<charlie-tca> slangasek: I hate to be the bearer of bad news. The abiword-proposed fails in 64bit
<slangasek> charlie-tca: fails how?
<slangasek> (I tested it on 64-bit, myself)
<charlie-tca> freezes the same way
<slangasek> after upgrading all of the related binary packages from lucid-proposed?
<slangasek> er
<slangasek> it's not even *built* yet on 64-bit
<charlie-tca> I only had abiword-common in proposed. The plugins were not there on 64bit
<slangasek> so you can't have tested it :)
<charlie-tca> well
<charlie-tca> That is a great explanation! Thanks
<slangasek> charlie-tca: abiword/amd64 is published now
<charlie-tca> tested good, too. Thank you very much!
#ubuntu-release 2010-05-20
<doko> ubuntu-archive: please could somebody accept the gnat-4.4 binaries in NEW?
<cjwatson> doko: done
#ubuntu-release 2010-05-21
<Riddell> cjwatson: I added one more into (presumably) your syncs
<cjwatson> I was just extracting my syncs individually so that you could flush
<cjwatson> go ahead
<Riddell> ok
<lamont> btw, new buildd rollout, hence the manual world
#ubuntu-release 2011-05-16
<cjwatson> Laney: flushed another pile of Haskell stuff through NEW
<Laney> cjwatson: cheers, http://orangesquash.org.uk/~laney/transitions/ghc.html doesn't look so bad
<Laney> although...
<Laney> just noticed that https://launchpad.net/ubuntu/+source/haskell-hlist didn't get process-removals removed
<Laney> did the buildX mess it up?
<cjwatson> not sure, slangasek was handling process-removals
<cjwatson> I think only an 'ubuntu' substring is meant to inhibit p-r
 * Laney goes blind at the p-r code :-)
<Laney> http://ftp-master.debian.org/removals.822 does exist now
<cjwatson> Laney: removed now
<cjwatson> and haskell-hgl
<cjwatson> how come stuff isn't going green on the ghc tracker, but only to unknown?
<cjwatson> oh, wait, it is, I'm stupid
<cjwatson> lamont: so, I'm looking at converting livecd-rootfs to live-build, and trying to figure out what would be involved
 * lamont has no knowledge on live-build
<cjwatson> lamont: from your POV, would it be an acceptable interface for buildlive to call ssh $buildd BuildLiveCD <arguments to lb config>, and then BuildLiveCD could call lb config <args> then lb build?
<cjwatson> (which is AIUI basically the normal sequence)
<cjwatson> lb config has vast swathes of possible options
<lamont> where does the chroot command live in that pile?
<cjwatson> so we should be able to add options until it's equivalent to livecd-rootfs
<cjwatson> I assume we'd have BuildLiveCD call lb * within a chroot, much as it currently calls livecd.sh
<cjwatson> lb can optionally do its own chrooting, but I don't think that's useful for us
<cjwatson> since we'll need to pick the right version of live-build anyway
<cjwatson> Laney: I guess the ghc tracker is failing to update - do you know why?
<Laney> cjwatson: I haven't cronned it yet
<cjwatson> aha :-)
<Laney> shamefully it was just a big && line
<Laney> I'll write a proper script now that there's more than one thing to track
<cjwatson> is any assistance needed with uploads, or is it all just in a giant dep-wait stack?
<cjwatson> (NEW activity suggests the latter ...)
<Laney> hopefully it should just be dep-waits
<Laney> i'll need to do some merges/sync requests
<Laney> and then if my account gets created soon I'll upload the remaining packages to debian
<Laney> so from your side just keeping an eye on NEW should be enough
<cjwatson> ok
<cjwatson> removing haskell-network-bytestring
<cjwatson> hmm, actually maybe I should leave that until haskell-network has built everywhere
<cjwatson> which is ultimately down to haskell-transformers failing, which looks transient - I see you just retried that?
<Laney> yep
<cjwatson> any idea why haskell-transformers didn't show up on the tracker, though?  it looks as though it should have done
<Laney> perhaps it looked for binaries which matched the source version
<Laney> it showed up as 'good' â could be a bit of a hole
<cjwatson> 43 sync requests outstanding, sigh
<Laney> uds hangover?
<cjwatson> yeah
<lamont> cjwatson: I suspect that BuildLiveCD wants to take a distroname, which it converts to a chroot name, and then chroots into that to do everything thereafter
<lamont> but yeah, sounds about as sane as anything else
<cjwatson> lamont: I guess I didn't want to have significant amounts of configuration encoded in BuildLiveCD, because then I either have to create a package for it (or keep livecd-rootfs around indefinitely), or we end up with the configuration hard to access by platform
<cjwatson> which is why I'd rather have the lb config args passed in from somewhere else
<cjwatson> if that makes sense
<lamont> yeah
<lamont> I concur with having a trivially simple BuildLiveCD script - possibly even thrown into live-build, 'tever
<cjwatson> we'll probably want our own for a while because it'll need to handle both livecd-rootfs and live-build
<lamont> yeah
<cjwatson> I could make such a change in livecd-rootfs and then keep it around until we stop needing livefs builds for <oneiric
<cjwatson> I guess
<lamont> BuildLiveCD is actually delivered outside of the package these days
<cjwatson> yeah, though copied from the package, right?
<lamont> yes
<lamont> copied from the package into $magicplace, from whence it is blatted out to all the builders
<lamont> so as it sits, you get exactly one version of BuildLiveCD, consistently, within about 10 minutes from when I push the change live
<lamont> zomg arm might catch up this week
<NCommander> lamont: yay
 * ScottK wonders if he should upload KDE then.
<slangasek> cjwatson, Laney: no clue why haskell-hlist didn't get caught in my last p-r run
<cjwatson> Laney: in ghc.ben, shouldn't several of the * characters in your regexes be .* ?
<SudoKing> are there any pre-alpha builds available?
<cjwatson> no CD image-type builds, no
<cjwatson> that's probably one of the tasks for this week
<SudoKing> k
<Laney> cjwatson: yes :-)
#ubuntu-release 2011-05-17
<cjwatson> Laney: I'm not seeing much else in the way of Haskell stuff coming through NEW now, BTW, so I think the rest will need uploads/syncs
<cjwatson> the Debian equivalent of the ghc tracker is less than 100% useful due to the lack of the .package test in is_bad
<Laney> I think that haskell-dummy might be messing it up there
<Laney> but I'm not sure
<Laney> anyway, will look in more detail in the next few days
<cjwatson> http://qa.ubuntuwire.com/ftbfs/ down about 200 from when I started attacking it earlier :-)
<cjwatson> (mostly judicious retries and the odd rebuild)
<cjwatson> and ocaml transition well underway
<cjwatson> I think that's about two good days' work and I should go to bed
<cjwatson> Laney: discussing hosting for the transition tracker with IS
<Laney> cjwatson: cool. Will they want to build it (and therefore install an ocaml stack) or will shipping in a binary be ok?
<cjwatson> *I'd* rather not ship in a binary :-)
<cjwatson> I pushed a bzr-git clone of your branch to lp:~ubuntu-release/+junk/transition-tracker as a starting point
<Laney> fair
<cjwatson> not sure how we want to handle that branch - we could keep merging from your git branch, or we could move it to some team that includes at least ~ubuntu-release plus you, or we could do something else I haven't thought of ...
<Laney> I'm not particularly wed to maintaining it, so if someone else wants to :-)
<Laney> as in I can just do merge requests if need be
<cjwatson> right, contrariwise I'm not a fan of the general approach of taking something that somebody was maintaining and putting it somewhere central where they no longer have access to it
<cjwatson> maybe just an ubuntu-transition-tracker team
<Laney> that works
<Laney> I've heard there can be IS bureaucracy/lag around merging stuff from branches onto websites, so it'd be good to avoid that
<Laney> thinking mainly of the .ben files themselves
<cjwatson> it varies, most of the stuff I operate I have shell access to as well
<cjwatson> though, well, maybe that's non-standard
 * Laney shrugs
<Laney> best would be if it were automated
<cjwatson> right
<cjwatson> https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker now, then
 * Laney wonders how well bzr-git works
<cjwatson> it's pretty smooth nowadays
<cjwatson> that was just bzr branch; bzr push
 * ogra_ sees https://launchpad.net/ubuntu/+source/highlighting-kate/0.2.9-1/+build/2467254 and wonders if skaet knows that we have a package for that :)
<highvoltage> lol
#ubuntu-release 2011-05-18
<Laney> cjwatson: I got around to writing that script so it's easy to add new transitions now. We can add pages for the other transitions if you want.
<cjwatson> Laney: oh, yes, please do.  I'm using http://paste.ubuntu.com/609451/ and http://paste.ubuntu.com/609452/
<Laney> up now
<doko> Laney: could you setup a page for libffi5/libffi6 too?
<Laney> doko: yes, can you provide the is_affected/good/bad lines?
<doko> and then there's libobjc2/libobjc3, but that can wait
<doko> Laney: is there any docs for these?
<Laney> not really i'm afraid
<Laney> should be easy to figure out from the existing transitions
<Laney> .field ~ /regexp/ | ... basically
<doko> Laney: what does the .package mean?
<Laney> doko: it means that there's a binary package matching regexp
<Laney> usually you'll just want .build-depends and .depends
<Laney> openssl is probably a good one to look at
<cjwatson> Laney: yay, thanks
<Laney> :-)
<Laney> we'll probably want a separate branch for the .ben files i suppose
<doko> Laney: http://paste.ubuntu.com/609501/
<Laney> ty
<Laney> added, should show up at the next cron run
<Laney> doko: http://orangesquash.org.uk/~laney/transitions/libffi.html does that look right?
<doko> $ apt-cache rdepends libffi5|wc -l
<doko> 205
<doko> strange ...
<Laney> look at grep-dctrl -FBuild-Depends -sPackage libffi-dev ...
<doko> interesting ... :-/
<Laney> haskell stuff seems to get a binary dep without BDing
<doko> wondering if we can do with an empty b-d field
<cjwatson> you could do  is_affected = .depends ~ /libffi/;  maybe
<cjwatson> I assume is_affected is basically just a performance optimisation
<cjwatson> or .build-depends ~ /libffi/ | .depends ~ /libffi/
<doko> interesting syntax
<Laney> it's so you don't see a list of every source package
<Laney> not sure if is_affected looks at binaries though
<Laney> might as well try
<cjwatson> you know your implementation language is too obscure when it's easier for *somebody who works on a functional language* to just try it and see what happens
<Laney> the problem is more that I'm trying to do real work concurrently ;)
<ScottK> What is this 'real work' you speak of?
<ScottK> Oh.  Right.  Better get some of that done myself.
<Laney> that seemed to help :-)
<Laney> although you can ignore the haskell ones
#ubuntu-release 2011-05-19
<doko> skaet, cjwatson: just reading allison's email; didn't we move the DebianImportFreeze?
 * ScottK thought we did.
<cjwatson> I thought so too
<cjwatson> Laney: could you change the ocaml-[a-z-] bits in the ocaml transition regexes to (ocaml-[a-z-]|camlp4-) please?
<cjwatson> Laney: I think the current version actually does catch everything, but better safe than sorry
<Laney> cjwatson: sure. If you want to commit it to the branch then I can just pull that.
<cjwatson> Laney: which branch, the ~ubuntu-transition-trackers one?
<cjwatson> or are you using git?
<Laney> cjwatson: yeah, that's the one I'm using now
<cjwatson> Laney: ok, cool - done
<Laney> pulled, thanks
<micahg> skaet: ping
<skaet> hi micahg
<micahg> hi skaet
<micahg> I was wondering would it make sense to make alpha 2 after the platform rally?
<micahg> or was it made the week of on purpose?
<skaet> micahg,  I was talking to jibel about it as well.
<skaet> was planning on starting a discussion off on the subject after get off vacation next week.
<micahg> skaet: ok, also, I was wondering why DIF was so early
<skaet> key is going to make sure we have image build and testing over july holiday weekend.
<skaet> micahg,  it was brought up at UDS,  and after looking at the back scroll, I see cjwatson, ScottK, and doko commenting as well.
<micahg> ah, I must have missed that discussion
<skaet> I'll take another pass at the schedule on Monday, and see if these two issues can get sorted.
<micahg> skaet: I'm just curious why, if there's a good reason for DIF being so early, it's obviously fine
<skaet> micahg,  in maverick (https://wiki.ubuntu.com/MaverickReleaseSchedule ) it was between alpha 1 and alpha 2.  Same story with Natty (its just that Natty had Christmas breaks, etc. in it so it seemed longer).  Oneiric is following the same pattern as both of those (between Alpha1 and Alpha 2).   I'll go back through the notes from UDS, and see what options might work.
<cjwatson> I think raw elapsed time is more important to DIF than alignment with milestones
<micahg> +1
<micahg> that's what I was noticing, natty was week 11, oneiric week 7
<cjwatson> since our milestones have very little effect on Debian development
<micahg> on the other hand, maverick was week 8
<cjwatson> we stop autosyncing for a few days around milestones anyway
<skaet> ok,  this cycle is closer to maverick in terms of timing.   If we push Alpha 2 out to July 7th,  we can move DIF to week 8.  We'd then have the rally week, to settle things down, before pushing out an image.
<cjwatson> skaet: I don't see why it needs to be dependent on Alpha 2 at al
<cjwatson> *all
<skaet> cjwatson,  desire to minimize the surprises the week before, and not have to ask folk to work the weekends to get things sorted.
<cjwatson> it doesn't affect that
<cjwatson> people just switch to filing big slews of manual sync requests instead
<cjwatson> it really isn't a work-weekends kind of thing IMO
<cjwatson> most of the worst surprises are internally generated :-)
 * skaet bows to your experience on that ;)
<cjwatson> we quite happily do autosyncs around Alpha 1, for instance
<cjwatson> and I know A1 is a bit more free-and-easy but it still isn't generally a problem - we just stop autosyncing for a few days to let things settle down
<skaet> yeah, but expectations are a bit lower.
<cjwatson> mostly just to free up build time
 * skaet nods
<cjwatson> right, but I'm having a hard time thinking of problems caused by autosyncing for an A1
<Laney> related: could DIF for universe be later than for main?
<cjwatson> Laney: I wouldn't recommend it
<cjwatson> Laney: you'll get all sorts of awkward skew
<Laney> I can see how it could cause problems
<Laney> right
<cjwatson> it's technically possible (if fiddly) - but I think I'd rather have manual sync requests for that
<Laney> I just tend to think that on balance Universe benefits from having autosync rather than DIF
<Laney> because fewer people are looking specifically at most of the packages
<Laney> maybe that's true for main too..
<skaet> cjwatson, do you remember what the options/preference for DIF was from UDS?
<cjwatson> Laney: it does, but there are enough subsystems spread across main+universe that it gets painful
<cjwatson> skaet: I remember my opinion, but I can't remember whether it carried ... :-)
<cjwatson> skaet: there are hopefully recordings?
 * skaet looking for them now...
<skaet> cjwatson: when did you want to see it?
<cjwatson> the other problem with having DIF too early is that nominally, before DIF is when most merges are supposed to happen (and it's good for the bulk of merges to happen in a period when we're autosyncing, for similar reasons of avoiding skew)
<cjwatson> and I think seven weeks is too short a time to get most merges done in, especially if the argument is trying to reduce the amount people have to work weekends
<Laney> of course, it's not possible to determine statically which syncs are going to cause problems
<Laney> maybe I'm in favour of DIF=FF :-)
 * Laney ponders some more
<micahg> Laney: sure, anything with lots of rdepends :)
<Laney> micahg: heh, there are definitely some heuristics, but you're never going to be able to predict accurately
<Laney> not that blanket autosyncing is without its problems
<cjwatson> skaet: we went between weeks 8 and 9 for quite a few releases, and I think that generally worked out OK from the point of view of having just enough time to get merges done in
<skaet> How about Alpha 2 July 7,  DIF  July 14,  10.04.3 July 21 ?  Alpha 3 is on Aug 4, and FF is on Aug 11th.   Any concerns?
<cjwatson> alternatively, Alpha 2 June 30, DIF July 7, and leave the rest where it is
<cjwatson> or DIF June 30, Alpha 2 July 7
<cjwatson> I'm not looking for *that* much extra time on DIF, just a couple of weeks - week 11 when we've done that was unusually late, I think
<skaet> ok,
<cjwatson> (and December is weird)
 * skaet nods
<doko> DIF June 30 sounds better
 * micahg thought week 11 for natty was early, but it was a long cycle :)
<skaet> doko,   are we getting any toolchain changes around then?
<cjwatson> Lucid was week 15, but that was because of a combination of it being an LTS and Squeeze being frozen, so we wanted as much time as possible to sync fixes in from Debian testing
<cjwatson> aside from that week 11 was definitely later than normal
<skaet> how does DIF interact with the Rally?
<cjwatson> the other thing I often say about DIF is that it's much more when you *stop* doing something than many of the other dates on the calendar
<cjwatson> it doesn't
<skaet> do we want it before or at the end?
<doko> Linaro has releases planned for Jun 16 and Jul 21
<micahg> cjwatson: the cycle was 2 weeks longer than normal though
<cjwatson> it really doesn't matter IMO
<cjwatson> micahg: even comparing with other 28-week cycles, it was late
<cjwatson> I think, anyway
<cjwatson> hm, maybe we haven't been doing 28-week cycles for long enough that I can say that
 * micahg thought it was the first
<cjwatson> LTSes do tend to throw things off
<cjwatson> you may be right
<skaet> cjwatson,  June 30 DIF, July 7 Alpha 2,   July 21 10.04.3 , then rest the same.
<micahg> based on this discussion, june 30 seems just right :)
<cjwatson> (also, I expect the dynamics around DIF to change in the future, since people will be able to do syncs themselves in the near future rather than having to go through archive admins)
<cjwatson> that's OK with me - that puts DIF at the end of the rally, right?
<cjwatson> if anything that's probably better, it means we don't need to spend quite as much time processing manual sync requests through the rally
<skaet> ok,  lets see if anyone can spot flaws over next couple of days,  and if not will send out email early next week, and adjust the schedule appropriately.
#ubuntu-release 2011-05-20
<cjwatson> Laney: the data in http://orangesquash.org.uk/~laney/transitions/ocaml.html seems oddly out of date - for instance coq built everywhere hours ago
<cjwatson> Laney: ah, never mind, sounds like there were publisher issues overnight
<pitti> cjwatson: see #is topic -- mirroring has been broken for the last 12 hours, but ETA was said to be in 15 mins now
<cjwatson> yeah, I caught up
<Laney> looks like my transition tracking machine at home has packed up, sorry
<Laney> will kick it tonight
<Laney> oh wait, er, it's inexplicably back alive
<ogra_> is there a release team meeting today ?
<skaet> ogra,  no release team meeting today.   They'll resume next week.
<ogra_> awesome !
 * ogra_ will go to mow the lawn then :)
<skaet> :)
 * charlie-tca going to put down the weed killer while it is calm outside
<highvoltage> hmm, I wonder if I joined the ubuntu-release list yet...
<highvoltage> skaet: ah I see it still needs the description too
 * skaet adds to list of things to look into on monday...
#ubuntu-release 2011-05-21
<cjwatson> Laney: please pull the transition-tracker branch
<Laney> cjwatson: righto
<cjwatson> ta
<Laney> looks easy ;-)
<cjwatson> yeah
<cjwatson> I may be turning into a slight NBS obsessive
<Laney> there are worse things to be obsessed with than archive health
<Laney> currently i'm obsessed with f5ing nm.d.o
<cjwatson> meant to be RSN, eh?
 * cjwatson remembers that phase ...
<cjwatson> (actually, *that* bit was short in my case, it was the two AMs who vanished on me that slowed things down)
<cjwatson> the DAM approval stage was 10 hours or so ;-)
<Laney> it's "how soon can you get enrico involved"
<cjwatson> it was tbm in my day
<cjwatson> https://nm.debian.org/nmstatus.php?email=cjw44@flatline.org.uk
 * cjwatson tries to work out why dvbstreamer is missing its shlibdeps
<cjwatson> ... also missing its binaries, well that explains that part ...
<Laney> your tin anniversary has passed :-)
<Laney> alioth being down is irritating, maybe i'll join the nbs-fest
<cjwatson> heh, yeah
 * cjwatson fixes dvbstreamer
<cjwatson> poked the Debian bug for multiwatch to see if I can help with sponsorship
<cjwatson> and uploaded everything else for libev
<cjwatson> ocaml is done aside from the llvms
#ubuntu-release 2011-05-22
<cjwatson> doko: you seem to have synced python-reportlab and tokyocabinet, but forgotten to flush them?
<cjwatson> doko_: I tried to move your python-reportlab and tokyocabinet syncs aside while I did an autosync run, but flush-syncs doesn't work quite the way I remembered so I accidentally flushed them.  I hope that's OK.
<cjwatson> (They won't have got -changes announcements, because I was trying to autosync ...)
<cjwatson> doko_: should llvm-snapshot be removed from oneiric to match Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626083)?
<ubot4> Debian bug 626083 in ftp.debian.org "RM: llvm-snapshot -- ROM; Deprecated and unmaintained" [Normal,Open]
<doko_> cjwatson: nothing wrong with the syncs. yes, llvm-snapshot can be removed. asked for it in debian
<cjwatson> excellent, doing that now then
<cjwatson> done
#ubuntu-release 2012-05-14
<ScottK> infinity: Were any decisions about the future of armel made at UDS?
<infinity> ScottK: Nope.
<Laney> Are you ready for us (backporters) to start uploading ourselves now?
<stgraber> slangasek: there you go ^
<slangasek> stgraber: have you by chance tested that the debconf prompt shows?
<stgraber> slangasek: yeah, I tested it in the same test environment as the previous sru and confirmed that I get the debconf prompt with it
<slangasek> ok, great
<slangasek> hmm; normally we would want db_go to be guarded with '|| true'
<slangasek> because it returns non-zero if the question isn't shown
<slangasek> however, in this case it's critical so it should never not be shown anyway
<stgraber> do you want me to re-upload just to be safe?
<slangasek> nah, I've accepted it as-is
<slangasek> just recording my thoughts here :)
<stgraber> ok, I'll push with "|| :" for the quantal one
<broder> Laney: if you do upload backports yourself, be sure to at least get the u-d-t from the daily ppa
<broder> i pushed some changes this weekend or something (forget exactly when)
<micahg> are we supposed to be uploading our own backports now?
<broder> i think we're close to making it standard operating procedure
<broder> colin asked for a tool to make sure that a backport in the queue is actually no-change
<broder> but other than that all the pieces are in place
<broder> (Laney and i have done a couple of backports our selves)
<micahg> I noticed :)
<Laney> just making sure that it is law
<highvoltage> Laney Lays down the Law
<RAOF> infinity: You want the -proposed d-shlibs to get released into preciseupdates and
<RAOF> -security, right?  That looks like the right thing to do.
<infinity> RAOF: Yeah, ideally.
#ubuntu-release 2012-05-15
<cjwatson> slangasek: "however, in this case it's critical so it should never not be shown anyway" - except in the noninteractive case ... is that relevant here?
<cjwatson> Laney: once broder is ready based on my test run with him, please do go ahead and make that SOP
<infinity> RAOF: Cheers.  I'll go back to my flu now.
<RAOF> Good luck with that :)
<slangasek> cjwatson: dunno... what does db_go return for critical+noninteractive?
<cjwatson> slangasek: oh, db_go - sorry, it's db_input that returns 30 for critical+noninteractive, db_go returns 0 unless the last operation was a backup (unlikely in that circumstance)
<cjwatson> micahg: I'd like to use your bug 998103 as a test of compatibility glue in ubuntu-archive-tools; would that be OK?
<ubot2> Launchpad bug 998103 in precise-backports "Please backport unknown-horizons 2012.1+dfsg1-1 (universe) from quantal" [Undecided,In progress] https://launchpad.net/bugs/998103
<cjwatson> similar to the code I already have there to deal with cases where people forget about the new world order and ask archive admins to process syncs for them
<Laney> cjwatson: If you're blocking on that, there's another one I can approve
<cjwatson> Laney: sounds good, especially if you can confirm whether the backportpackage command my code produces is correct
<slangasek> cjwatson: db_go> ok, great :)
<Laney> cjwatson: hrm, possibly, but Evan would be better placed. He made some recent changes that I've not fully caught up with.
<Laney> bug #999132
<ubot2> Launchpad bug 999132 in precise-backports "Please backport widelands 1:17-2 (universe) from quantal" [Undecided,In progress] https://launchpad.net/bugs/999132
<cjwatson> DEBEMAIL="iain@orangesquash.org.uk" DEBFULLNAME="Iain Lane" backportpackage -u ubuntu -c 999132 -d precise -s quantal widelands
<Laney> LGTM
<cjwatson> yeesh, I'd test it but the orig is 167 MiB
<Laney> hm, looks like -v isn't hooked up to anything
<Laney> I thought it might be safer to pass that too, but clearly not if it does nothing
<cjwatson> my current u-a-t diff is http://paste.ubuntu.com/989007/
<Laney> I wonder why we treat the backporter as requestor
<cjwatson> Laney: I think because they were rather more likely to have a sense of development ownership than your average user requesting a backport is
<Laney> It feels a bit more like sponsorship, since we expect others to do the testing now. Maybe that's just me though.
<slangasek> Laney: well, I've seen backport requests in the past from people whose launchpad "real name" fields were inappropriate to list in a changelog ;)
<slangasek> infinity, stgraber: ad hoc bug report - getaddrinfo() appears to not be doing name resolution of non-FQDNs correctly in precise for IPv6 hosts
<infinity> slangasek: Do you mean "not at all", or "incorrectly", as in it returns garbage?
 * infinity suspects it might be time to upgrade his home network to v6...
<slangasek> skaet: can you send out some announcement to ubuntu-devel this week about how we're supposed to handle release notes in the blueprints this cycle?  It's best to get that announced ASAP since everyone's drafting this week
<skaet> slangasek, will do.
<slangasek> infinity: "not at all" - I have to stick a . on the end of every hostname to get ping6 to return anything useful
<slangasek> skaet: ta :)
<stgraber> slangasek: do you have any more detail? looks fine here
<stgraber> >>> socket.getaddrinfo("shell01.dmz.dcnue", 22)
<stgraber> [(10, 1, 6, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (10, 2, 17, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (10, 3, 0, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (2, 1, 6, '', ('172.22.25.30', 22)), (2, 2, 17, '', ('172.22.25.30', 22)), (2, 3, 0, '', ('172.22.25.30', 22))]
<stgraber> >>> socket.getaddrinfo("dnsr05.dmz", 22)
<stgraber> [(10, 1, 6, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (10, 2, 17, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (10, 3, 0, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (2, 1, 6, '', ('172.17.25.30', 22)), (2, 2, 17, '', ('172.17.25.30', 22)), (2, 3, 0, '', ('172.17.25.30', 22))]
<stgraber> right, looks good here (with lan.sherb.stgraber.net sherb.stgraber.net stgraber.net in my search path)
<infinity> slangasek: I'm taking another sick day, my flu seems to be intent on trying to kill me, but if you and stgraber figure out a way to blame glibc for your issues, let me know.
<slangasek> infinity: bah and ack - throw me a canonicaladmin request?
<infinity> slangasek: Done.
<stgraber> skaet: http://iso.qa.dev.stgraber.org/qatracker/milestones/216/builds <-- see the (ready) next to Edubuntu and the big "Mark ready" button
<skaet> stgraber,  not seeing... permissions?
<skaet> (but happy that I should be seeing it... ;) )
<stgraber> skaet: are you logged in?
<skaet> yup.  :)
<stgraber> skaet: in all cases, you should see the (ready) next to Edubuntu
<stgraber> cjwatson: I just saw https://launchpad.net/ubuntu/precise/+source/lxc/0.7.5-3ubuntu55 which looks wrong. -ubuntu54 was moved to updates but AFAIK -ubuntu55 still needs testing
<stgraber> cjwatson: hallyn will upload a new ubuntu55 to -proposed to fix that and include an extra change
<stgraber> (adding a fix for bug 999187)
<ubot2> Launchpad bug 999187 in lxc "lxc-create for armhf fails with error "failed to execute template 'ubuntu'"" [High,New] https://launchpad.net/bugs/999187
<cjwatson> stgraber: hm, I guess pending-sru is a bit overenthusiastic there
<cjwatson> stgraber: it may have to be ubuntu56 now, sorry
<stgraber> yeah, I'll upload ubuntu56 using -v to include ubuntu55
<cjwatson> there must have been a race, as pending-sru would only have printed that if -updates were >= -proposed
<cjwatson> yeah, published 00:34:39 UTC, removal requested 00:35:06 UTC
<cjwatson> so just rotten luck
<stgraber> skaet: thanks for the screenshot. So at least the user part of the change "(ready)" is visible there. I can't easily check but it looks like the website doesn't know you're in ubuntu-release. Maybe logging out and back in will fix it (making sure ubuntu-release is ticked on the SSO page)
<skaet> stgraber, will do and let you know if that changes anything.
<stgraber> skaet: whenever I update to a new DB snapshot from production the SSO is acting a bit weird in Drupal. Sometimes logging me out randomly (that's why I asked) or just not mapping the roles properly, I guess I should be doing something a bit more clever than simply dumping the whole DB (like remove the existing SSO tickets :))
<stgraber> the good thing is that it only affects the development/staging environment, not production deployments
<skaet> :)
<stgraber> cjwatson: can you let that one in? it contains the old -ubuntu55 and adds a cherry-pick from quantal (one line, trivial bug/fix)
<stgraber> skaet: I'm working on the ISO tracker blueprint, do you know the LP username for timrc? (LP tells me timrc doesn't exist)
<slangasek> stgraber: http://paste.ubuntu.com/989151/
<stgraber> skaet: nevermind, found him
<slangasek> stgraber: /etc/gai.conf is unmodified
<slangasek> mdns is enabled for hosts
<stgraber> slangasek: http://paste.ubuntu.com/989160/
<slangasek> I do have an IPv4 /etc/hosts entry for this particular host which shadows the DNS, but that has not previously been a problem
<stgraber> I'd blame the /etc/hosts entry, I seem to remember seeing a similar behaviour here (and wanted it). Basically putting an IPv4 entry in /etc/hosts will make getaddrinfo() return it and not do any further resolving (so no IPv6 record returned)
<slangasek> stgraber: confirmed that this is not a problem with oneiric eglibc
<slangasek> hmm
<slangasek> well, yuck
<slangasek> why do you want this behavior?
<stgraber> I use it sometimes when I want to avoid using IPv6 for a specific host (where the IPv6 address doesn't respond)
<slangasek> hmm
<slangasek> it's definitely a regression for me
<slangasek> my /etc/hosts entries are there as a guard against DNS resolution failing so I can still get around the local network during a network outage
<slangasek> but I don't want to hard-code IPv6 addresses there
<stgraber> slangasek: then you should move "files" after "dns" in /etc/nssswitch.conf?
<slangasek> well, I won't do that :)
<slangasek> I would sooner remove the entries from /etc/hosts
<slangasek> but I would like to know the upstream justification for this behavior change
<stgraber> slangasek: http://paste.ubuntu.com/989173/
 * slangasek nods
<slangasek> doesn't it seem a little odd that the behavior should be dependent on whether an fqdn is used?
<stgraber> I don't have Oneiric around but at least Lucid had the same behaviour as Precise
<slangasek> oh, you're seeing this with lucid, interesting
<slangasek> would a (Canonical) archive admin care to review the fluendo packages in partner/precise/unapproved?
<stgraber> I'm not familar with the files nss module but it might be that it simply won't match the fqdn syntax (with the final dot)
<slangasek> heh, funny
<stgraber> so my guess is that the bug is that it worked at all for you ;)
<slangasek> blah
<cjwatson> stgraber: ok, done
<stgraber> cjwatson: thanks
<slangasek> cjwatson: hmm.  bug #863741 became un-fixed in precise; rpcbind dropped back to priority: optional (was priority: standard in precise).
<ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix released] https://launchpad.net/bugs/863741
<slangasek> cjwatson: thoughts on how to fix this?  null SRU + priority override? :/
<stgraber> skaet: so I tried to get the full changelog in the build notes of the tracker but it's really quite ugly (http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/16074/testcases), I think it'd be best just to give a link (http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/16075/testcases)
<stgraber> an alternative is to parse the changes file and only extract the changelog entry which should be quite a bit shorter than the whole changes entry
<skaet> stgraber,  link will work for now.   However,  maybe you can reuse the changelog extraction code in: http://people.canonical.com/~cjwatson/lucid-updates.py?
<stgraber> skaet: oh yeah, that'd work
<skaet> :)
<micahg> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html doesn't seem to be getting updated, is this known?
<cjwatson> slangasek: hmph; if it's meant to be priority standard, shouldn't it be seeded or something?
<slangasek> cjwatson: it probably should've been :/
<cjwatson> slangasek: I have a feeling that if we ran change-override.py -s precise-updates or whatever it is, that might result in a new publication to precise-updates ...
<cjwatson> ICBW
<cjwatson> micahg: looking
<slangasek> I don't know that it needs to be standard for quantal anyway, it was entirely to try to force the issue with apt not wanting to replace portmap with rpcbind on upgrades
<slangasek> 2012-05-15 23:55:25 ERROR   Could not find binaries for 'rpcbind/None' in Primary Archive for Ubuntu: precise-UPDATES
<slangasek> looks like I should pocket-copy first
<slangasek> cjwatson: ^^ think I should do it?
<cjwatson> I think that would make sense, yes
<cjwatson> least-bad
<slangasek> done
#ubuntu-release 2012-05-16
<cjwatson> micahg: Should be happier now.  outdate-report takes forever at the moment, though - need to work on that
<micahg> cjwatson: thanks
<micahg> cjwatson: I noticed component-mismatches also isn't running
<cjwatson> (it was all stuck on a stale lock - I'll check again once this finishes to make sure it's really gone this time)
<cjwatson> hm, that'd be different I'm guessing
<micahg> probably, only stopped 5 days ago
<cjwatson> haha, /me <- idiot
<cjwatson> I think that was a manual run, must have been
<cjwatson> oh, or not, what's going on
<cjwatson> well, I bodged the bodge a bit harder, next attempt should work I think
<cjwatson> wet string and sticky tape
<cjwatson> outdate-report should be a bit faster now too
<cjwatson> Could somebody review the pyicu binaries?  Then I can upload py3 ubiquity
<cjwatson> (There's a Launchpad fastdowntime coming up, so it may bounce you temporarily)
<cjwatson> jamespage: I rejected samba due to a botched package split in Debian that would break upgrades, which I reported as http://bugs.debian.org/673122; I don't know whether you want to fix that in advance in Ubuntu, or wait for a fresh merge
<jamespage> cjwatson, I think I'll fix it in advance (working on SRU for bug 970679) - thanks for letting me know
<ubot2> Launchpad bug 970679 in samba "[SRU] winbind coredumps when encountering a group with over 1000 members" [High,In progress] https://launchpad.net/bugs/970679
<cjwatson> Laney: testing this new backportpackage glue code in u-a-t now
<Laney> nice
 * Laney hopes opening a window for queuebot will reduce the noise
<Laney> well, redirect it away from my attention
<mdeslaur> can someone please denew transmission-remote-cli? (I assume that's needed...)
<cjwatson> mdeslaur: done
<mdeslaur> cjwatson: thanks
<Laney> bah, didn't work
<cjwatson> Laney: I used unknown-horizons as my test case, and it seems to have worked fine
<cjwatson> Laney: feel free to do widelands directly with backportpackage from ubuntu-dev-tools - I don't really fancy the download :)
<cjwatson> Could anyone review pyicu in binary NEW for me, please?
<pitti> cjwatson: looking
<pitti> LGTM
<pitti> (while I was looking at binNMU anyway..)
<cjwatson> pitti: did that fix the missing Replaces trouble from earlier then?
<pitti> cjwatson: sorry, which replaces trouble?
<cjwatson> 11:34 <cjwatson> jamespage: I rejected samba due to a botched package split in Debian that would break upgrades, which I reported as http://bugs.debian.org/673122; I don't know whether you want to fix that in
<cjwatson>                  advance in Ubuntu, or wait for a fresh merge
<cjwatson> 11:39 <jamespage> cjwatson, I think I'll fix it in advance (working on SRU for bug 970679) - thanks for letting me know
<ubot2> Launchpad bug 970679 in samba "[SRU] winbind coredumps when encountering a group with over 1000 members" [High,In progress] https://launchpad.net/bugs/970679
<jamespage> cjwatson, it does yes
<pitti> cjwatson: ah, for samba
<pitti> cjwatson: the changelog said so
<cjwatson> ok, cool
<cjwatson> hadn't had time to look yet
 * pitti removes the stale .run-britney.lock to get quantal_probs working again
<cjwatson> oh not again
<cjwatson> clearly my locking code is wrong
<cjwatson> will look after this meeting ...
<mvo> could someone please look at the software-center SRU ? it should fix some of the top bugs in errors.ubuntu.com
<ev> mvo: yay, it's proving useful then?
<skaet> :)
<mvo> ev: yes, *very* much so, its excellent
<seb128> ev, it's very useful indeed ;-) (speaking as someone working on .1)
<infinity> ev: Yeah, don't let it go to your head, but it's something we've needed for 8 years.
 * cjwatson gets down to a single call to synclib.request in ubuntu-archive-tools
<cjwatson> unfortunately the last one requires exposing removals on the webservice before I can nuke it
<cjwatson> so close
<ev> mvo, seb128, infinity: thanks! I just want to keep soliciting input so it's best mapping to what people need without getting overwhelmed with feature creep
<seb128> ev, if you want to improve things, my first request would be to fix the python matching, it still wrongly merge issues and launchpad bug reports
<seb128> ev, i.e the "look at the signature but not the exception"
<seb128> ev, it's quite misleading for some of the python issues listed there
<ev> seb128: it only matches on the signature generated by apport - is that not ideal?
<ev> it's definitely not hashing the python stacktrace or anything like that
<seb128> ev, https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/989819
<ubot2> Launchpad bug 989819 in whoopsie-daisy "the signatures match code should probably consider the exception for python errors" [Undecided,New]
<infinity> ev: You can get the same trace of methods leading to different exceptions.
<seb128> ev, did that get fixed?
<seb128> DBusException: org.freedesktop.Accounts.Error.PermissionDenied: Not authorized"
<seb128> DBusException: org.freedesktop.Accounts.Error.Failed: 'bg_BG.UTF-8' is not a valid locale name"
<seb128>  
<seb128> those boths bugs are merged because they have the exact same functions in their signature
<seb128> but they are different issues
<ev> right, this is why I raised the issue of whether or not the current signature generation was enough
<seb128> well I guess it's not ;-)
<ev> hm
<ev> indeed
<ev> okay
<ev> I'll have a think
<seb128> thanks
<seb128> sorry if that was unclear when opened the bug
<seb128> I though it was on your list
<ev> it definitely is on my list. It just landed on the list during release prep
<ev> so I didn't have a lot of time to dig at it then
<ev> I've given it a milestone and assigned it to myself
<ev> so it will definitely get handled
<seb128> great, thank you
<stgraber> skaet: http://iso.qa.dev.stgraber.org/qatracker/milestones/219/builds/16088/testcases <-- does that look better?
 * skaet looks
<skaet> :)  yup looks good.
<stgraber> script updated, needed a minor Drupal config change for it to render properly but that's already done on production
<skaet> stgraber,  goodness.   Lets stick with this for now, and see how it works in practice.  :)
<stgraber> skaet: looking at status.ubuntu.com, should I register a topic blueprint for Edubuntu or are you creating them all?
<skaet> stgraber,  go ahead and register the topic for Edubuntu.  I'll take a pass next week at adding them for the flavors that don't have one already.
<stgraber> k
<skaet> syntax to use is topic-quantal-flavor-edubuntu for the name,  so it will sort correctly. :)
<stgraber> skaet: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-edubuntu
<skaet> \o/
<dobey> is adding ui/strings for additional error handling in an app, reasonably SRU-able?
<slangasek> dobey: how is the error handled today, without the addition of the string?
<slangasek> (it's a gray area, really - and ideally if we're going to add them, we give translators time to catch up
<dobey> it's not
<slangasek> meaning what, exactly? :)
<slangasek> does the app crash?
<dobey> potentially, it crashes at a point where it would normally exit
<slangasek> hmm
<dobey> https://errors.ubuntu.com/bucket/?id=/usr/bin/ubuntuone-installer:GError:finished:function
<dobey> i'm fixing this, and trying to decide what the best way to handle the few error conditions that aren't currently handled, is
 * slangasek nods
<slangasek> is there a bug # for that one?  hard to interpret the very-short backtrace
<dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/853060
<ubot2> Launchpad bug 853060 in ubuntuone-installer "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [High,Confirmed]
<slangasek> ta
<dobey> but same very short backtrace :)
<slangasek> :)
<slangasek> anyway, sorry to be wishy-washy, but I think it depends on what the error is... we might want to say that it's better to silently ignore the error than to add a new message
<slangasek> so a sample diff might help
<dobey> well there isn't really any way to silently ignore the errors. one of them is if the apt cache updating fails. we can't then just ignore it and try to install, because installing will also almost certainly fail, and result in a secondary error. which if we ignore will result in the app just going away, or the current crash (which is arguably better, since it actually says something went wrong)
<dobey> but i don't know of any good solution to the error other than to say to the user there was an error, and to try again later, with a button that just closes the app
<slangasek> hmmm, and there's no existing string for "apt-cache update failed" that could be copied over with all translations intact?
<slangasek> aptdaemon uses 'Refreshing the software list failed'
<dobey> i'm sure we can get translated strinsg out of aptdaemon, but perhaps may be too technical (i haven't looked at those strings directly yet)
<dobey> and we still need to integrate it into the UI
 * slangasek nods
<slangasek> I think the UI integration should be ok, SRU-wise
<dobey> ok
<dobey> i'll poke at it a bit deeper and see what we can do with that, then
<slangasek> ok
<slangasek> man, that software-center SRU is something massive
#ubuntu-release 2012-05-17
 * cjwatson fixes the broken lock file handling for quantal_probs et al
<slangasek> cjwatson, SpamapS: could I trouble one of you for an expedited SRU review of ia32-libs?
<slangasek> (installing the fluendo package from partner is currently broken if you have ia32-libs installed)
<cjwatson> slangasek: yep, where is it?
<slangasek> cjwatson: precise-proposed unapproved
<cjwatson> slangasek: accepted; do you want to go ahead and copy that to quantal once it's built?
<slangasek> will do, thanks
<slangasek> which reminds me that there are a couple that RAOF processed this morning that are in the same boat (e.g., software-center) - copying
<slangasek> cjwatson: do we have any report for "packages in -proposed newer than packages in devel"?
<slangasek> er, correction, I processed software-center last night ;p
<slangasek> I think I meant update-notifier
<cjwatson> slangasek: No report, but you can work it out easily with suite-diff.py
<cjwatson> for x in main restricted universe multiverse; do suite-diff.py ubuntu/dists/{precise-proposed,quantal}/$x/source/Sources.gz gt; done
<cjwatson> Quite a few there that could do with copying up
<cjwatson> Well, some of those are unverified updates, in general I actually only copy from -updates except on request
<cjwatson> for x in main restricted universe multiverse; do suite-diff.py ubuntu/dists/{precise-updates,quantal}/$x/source/Sources.gz gt; done  ->  6
<slangasek> looks like it, doesn't it
<slangasek> update-manager contains Arch: any packages... ought we require a re-upload?
<cjwatson> slangasek: perhaps a good idea, yes
<cjwatson> though it's bound to be rebuilt at some point :)
<slangasek> + [cjwatson] Port ubiquity: DONE
<slangasek> !
<cjwatson> s'in the archive and everything
<slangasek> wow
<cjwatson> whether it works for *other people* ;-)
 * slangasek grins
 * cjwatson sends an RT ticket: "Please remove archive admin access to lp_queue@cocoplum"
<cjwatson> Speak now or forever etc.
<slangasek> :)
<micahg> ls
<micahg> oops :)
 * skaet_ watching to see what surprises pop up from that RT ticket
<slangasek> it's the low-hanging fruit
<slangasek> the only reason I ever access ~lp_queue is to steal back my rejected uploads and reupload them ;)
<cjwatson> yeah, I'm fairly sure lp_queue is easy, just asking for the sake of paranoia
<cjwatson> in several months nobody came up with anything substantial except for syncs and backports, and those are migrated
<cjwatson> I cleaned up most of the old junk in its home directory today
<micahg> cjwatson: what about overrides
<cjwatson> lp_queue is not involved in those
<cjwatson> almost all the ordinary administrative operations (that aren't API/UI) are lp_archive
<cjwatson> lp_queue is just the user that runs the upload processor
<infinity> slangasek: I use lp_queue to catch and reject uploads I'm to embarassed to let through. ;)
<infinity> Somehow, I don't think anyone will see that as a valid use-case. :P
<infinity> s/to/too/
<cjwatson> afraid not really :)
<infinity> ;)
<stgraber> any sru team member around? I'd love to see lxc 0.7.4-0ubuntu7.3 currently in natty-proposed be moved to natty-updates. It's currently preventing a natty container from starting console/tty jobs, basically preventing the user from using it at all.
<stgraber> the fix was confirmed around a month ago but nobody changed the verification state on the bug. I confirmed the fix here too and changed the tag this afternoon.
<slangasek> peeking
<slangasek> doing
 * infinity is too late.
<slangasek> you can have the next one :)
<infinity> I'll do some binary new to make up for it.
<infinity> And then go drown myself in chicken soup.
<RAOF> Bah.  I thought I checked for all the SRUs I approved yesterday that their version was less than that in quantal.  I should add an automated check to queuediff.
<slangasek> RAOF: no harm done, it was on my radar anyway :)
#ubuntu-release 2012-05-18
<cjwatson> skaet: do you think foundations-q-replace-archive-admin-shell-access should be added to topic-quantal-release-management, perhaps?
<cjwatson> skaet: possibly also foundations-q-livefs-in-soyuz
<cjwatson> tumbleweed: so, your sync-blacklist scripts - can I stick a copyright notice for you and a GPLv3 licence at the top?
<cjwatson> tumbleweed: I was thinking of putting them in ubuntu-archive-tools
 * ogra_ wonders if someone could update the debootstrap on the arm livefs builders ...
<ogra_> P: Running debootstrap (download-only)...
<ogra_> E: No such script: /usr/share/debootstrap/scripts/quantal
<ogra_> ...
<cjwatson> err.  shouldn't they be doing quantal builds in a quantal chroot, which should already be upgraded to a current debootstrap that supports that?
<ogra_> well, i would have thought so
<ogra_> the errror somehow indicates differently though
<ogra_> -r
<cjwatson> sure, just saying, not clear a simple upgrade will help as they already auto-upgrade at the start of the build
<ogra_> thats -core only, for the other failed builds i havent looked deeper yet
<ogra_> nusakan doesnt send me logs for these and i havent looked at people.c.c yet
<cjwatson> it's only core/armel, core/armhf works fine
<cjwatson> so, uh, wibble
<ogra_> heh
<cjwatson> maybe there's something that prevents the chroots auto-upgrading for some reason, and so they're effectively stuck on precise
<cjwatson> attempting to upgrade the chroots might reveal what that is, I guess
<ogra_> well, its not like we urgently need building images right now ... should suffice if infinity takes a look once he is back
<cjwatson> but that's my best guess
<cjwatson> fixing quantal/armel so that it auto-upgrades cleanly would suffice too, at least temporarily
<cjwatson> though http://people.canonical.com/~ubuntu-archive/testing-ports/quantal_probs.html doesn't seem to have anything that obviously matters here
<ogra_> well, local dist-upgrades precise->quantal work fine on armel ...
<ogra_> at least they did before UDS
<ogra_> must be something in quantal armel itself ... i dont think anyone paid much attention to that port anyway yet though
<cjwatson> mm, upgrading successfully once should've been sufficient, though bear in mind we weren't doing daily builds before UDS, IIRC
<cjwatson> so it matters what they were doing as of the point when I turned on daily builds, not so much what they were doing before
<cjwatson> anyway, it's only my best working theory, not actually proven
<Daviey> ogra_: you can download the chroot that LP is using from LP, then chroot in and have a poke, if that helps.
<cjwatson> Daviey: No, that gets you the package build chroot, not the livefs build chroot.
<ogra_> right
<cjwatson> Until such time as livefses are built in LP, then they might be the same.
<ogra_> all i can do to the livefs builders is get http access to the local webserver instance to read the logs
<ogra_> (and indeed trigger builds from nusakan without any direct access)
<Daviey> cjwatson: Ah, sorry.. i thought that was what ogra_ was talking about.
<skaet> ScottK,  we need to do some cleanup on cdimage,  who should I work with to double check on some of the kubuntu parts of the cleanup?
<pitti> darn, we are so close now.. http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<pitti> I *just* thought I had it down to zero after that publisher run, when samba got broken
<pitti> no beer on a Friday evening :(
<skaet> :(
<cjwatson> skaet: oh, which reminds me, can I enable purging of old images again?  I think we've released everything for precise that we're going to release
<skaet> cjwatson,  yes definitely
 * skaet thought it had been done already - should have checked.  sorry.
<cjwatson> done now
<skaet> :)
<cjwatson> I'd left it that way pending the Chinese edition being sorted out, but that's done
 * skaet nods
<cjwatson> what Kubuntu cleanup is required?
<skaet> Spads was noting they're taking up 100s of Gigs,  so a scrub/check seemed in order
<cjwatson> practically all of that is going to be purge-old-images being left off
<skaet> that would indeed explain it.
<cjwatson> so the most economic approach might well be just to let the automatic code do its stuff
<skaet> yuppers
<bjf> can someone copy the Precise kernel package (3.2.0-24.38) from -proposed to -updates? (not a high priority)
<cjwatson> incidentally I just fixed a bunch of the daily CD builds (anything that was trying to include dist-upgrader images)
<cjwatson> and arranged that purge-old-images will never nuke the target of the 'current' symlink (might have been related ...)
 * skaet likes!!  Thanks cjwatson.  :)
<tumbleweed> cjwatson: sure, although I just picked up where laney left off. he holds copyright on them too
<cjwatson> Laney: ^- ?
<cjwatson> 11:39 <cjwatson> tumbleweed: so, your sync-blacklist scripts - can I stick a copyright notice for you and a GPLv3 licence at the top?
<cjwatson> 11:39 <cjwatson> tumbleweed: I was thinking of putting them in ubuntu-archive-tools
<slangasek> um
<slangasek> so the work items handling in launchpad
<slangasek> is randomly corrupting my input
<slangasek> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates - I noticed jdstrand's latest change included some seemingly extraneous changes to unrelated work items, so I tried to clean it up... and LP apparently completely replaced *my* intended change with something else
<jdstrand> slangasek: weird. all I did was add a comment in the whiteboard, then do s/TODO/DONE/ on something
<slangasek> I know
<slangasek> the server is clearly doing broken things with the input
<jdstrand> that's... suboptimal
<jdstrand> I haven't noticed that with the blueprints I have been working on, but will keep an eye out for it
<stgraber> skaet: hmm, that Precise 10.04.1 Daily milestone looks weird :)
<slangasek> - [mlankhorst] Review the rename script: TODO
<slangasek> + [tjaalton] Review the rename script: TODO
<slangasek>   [tjaalton] Review the rename script: TODO
<slangasek>   [tjaalton] Review the rename script: TODO
<stgraber> skaet: first, I think it should be called Precise 12.04.1 Daily :)
<slangasek> not cool
 * slangasek tries a fourth time to fix up these WIs
<stgraber> skaet: and it also had notifications enabled which I turned off to avoid spamming people when we actually get builds pushed daily
<stgraber> skaet: actually, is there any reason to use a separate daily milestone for post-release? (wondering if we can't just use the existing Precise Daily for that, then switch to Precise 12.04.1 when we're in freeze like usual)
<slangasek> + [mlankhorst] Also review the rename script: TODO
<slangasek>   [tjaalton] Review the rename script: TODO
<slangasek>   [tjaalton] Review the rename script: TODO
<slangasek>   [tjaalton] Review the rename script: TODO
<slangasek> that is *also* not what I typed, Launchpad
<slangasek> so I think LP can't cope with two work items with the same description but different assignees
 * skaet headslams
<skaet> stgraber,  yup should have been 12.04.1 *sigh*,  and we could go back to using the precise daily instead.
 * skaet goes to fix
<stgraber> skaet: ok, let me kill 12.04.1 from the DB then, we'll create it when we're in freeze
<stgraber> skaet: gone
<skaet> stgraber, or we can just mark it closed for now, and reopen it then?
<skaet> hehe
<skaet> too late
<skaet> no worries.
<stgraber> it didn't contain anything so it was still possible to completely remove without causing inconsistencies in the DB
<stgraber> I also moved Precise Daily back to testing
<stgraber> and will patch my scripts to deal properly with two daily milestones (the auto d-i publishing script just complained by e-mail ;))
<skaet> stgraber, sounds good.
<skaet> any problem with me just removing the images that aren't part of the LTS?
<stgraber> nope, go ahead
<skaet> coolio.
 * cjwatson sets ~cdimage/.isotracker.conf back to Precise Daily
<stgraber> fixed the cronjob, we'll now have d-i images published on all active daily milestones
<stgraber> cjwatson: do you already have a way to make it use the right milestone depending on what release it's building?
<cjwatson> stgraber: no
<cjwatson> though good point
 * skaet nods
<cjwatson> I'll see about beefing up isotracker_xmlrpc.py to support that
<cjwatson> maybe [precise] [quantal] etc. sections
<cjwatson> falling back to [general]
<stgraber> cjwatson: sounds good for now. In the next release of the ISO tracker, all milestones will have to be linked to a series (required for the new testcase management code) so I'll have the series exported over the API too, should make this easier
<cjwatson> I'll bodge for now :)
<cjwatson> http://paste.ubuntu.com/994637/
<cjwatson> done, I think, let me know if it breaks :)
<stgraber> right, and API extended to export the series, so we should have that on production at some point (it's in the testcase management branch, so not expecting this to land real soon)
<stgraber> at some point I'll also want to rebase the tools in lp:ubuntu-archive-tools on the "official" python-qatracker at lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker/
 * cjwatson tests - oops, that broke
<cjwatson> there you go, some quantal images now
<stgraber> yeah!
<stgraber> hmm, someone will have to create all the download links or re-design that feature to be less of a pain to maintain (having to create/update 4 entries per image per series quickly gets annoying)
<skaet> :)
<Laney> cjwatson: no worries
<stgraber> cjwatson: are the precise dailies fully setup? I'm drafting the 12.04.1 spec now and I see that you have a work item for it, wondering if I should mark it done already ;)
<slangasek> I didn't see them running yet
<cjwatson> stgraber: not yet, will try to sort that out asap
<cjwatson> Laney: great, thanks
<Laney> so you're planning on moving it over?
<cjwatson> Laney: yep - out of time this week now, but more or less next on the archive hit list at last
<cjwatson> sorry it's taken quite so long
<Laney> never mind :-)
<Laney> in other news, update-sources.py in mom is intense
#ubuntu-release 2012-05-19
 * cjwatson wonders why there are packages in wheezy+sid and not in quantal with no DSDs
<cjwatson> Laney,tumbleweed: I think we may have to keep the text file after all, at least in part; there are too many packages that don't have DSDs despite still being in Debian and I don't see how to blacklist them
<cjwatson> maybe if I at least switch it out to an externally-accessible bzr branch somewhere
<cjwatson> I fear that I cannot think of any better approach right now, short of even more LP hacking that I don't think I'll have time for
<mdeslaur> someone might want to look into bug 990740
<ubot2> Launchpad bug 990740 in python-defaults "upgrading from lucid to precise fails" [Undecided,Confirmed] https://launchpad.net/bugs/990740
<slangasek> mdeslaur: key phrase there is 'Trying to "apt-get dist-upgrade"'
<slangasek> so they're not using the release-upgrader apt
<tumbleweed> cjwatson: hrm, if there are packages without DSDs, does that mean the autosyncer is going to miss things?
<cjwatson> No, they're ones that have been removed from Ubuntu
<tumbleweed> ah
<slangasek> mdeslaur: ah, though I see comments further on claiming it still occurs with do-release-upgrade; looking further
<slangasek> also, yay: Brian J. Murrell, the friendliest Ubuntu bug reporter
 * cjwatson notes that nobody responded to my request for apport-collect information on that bug
<cjwatson> ... as you just said
<slangasek> ;)
<slangasek> it might be that we need to fix this by making python2.7-minimal Conflicts: with the right version of python-minimal after all, instead of having a circular dep
<slangasek> but we'll want to know why it's failing for others and not on jenkins
<cjwatson> I was about to point Brian J. Murrell at jenkins and then noticed it was failing
<slangasek> hmm
<cjwatson> but I think that's a separate problem and one mvo knows about
<slangasek> ok
<cjwatson> induced by my attempts at python 3 porting I think
<slangasek> dear firefox, if you insist on writing to disk every 30 seconds, the least you could do is remember to write the data that lets me use the awesome bar
 * cjwatson gives quantal a shiny new ubuntu-keyring
<cjwatson> at some point I may get around to all the SRUs and actually installing the keys ...
<slangasek> :)
<slangasek> still need to figure out why gpg won't let me sign the new cdimage key
<slangasek> even though I've signed several other keys since then
<cjwatson> ... you did and you mailed the signature to me
<cjwatson> well, to cdimage@ubuntu.com
<slangasek> orly
<slangasek> well then
<cjwatson> I imported it, the keyservers should have it; failing that, the new ubuntu-keyring does
<slangasek> apparently that means something's broken in my main gpg config that's not broken in my caff config
<cjwatson> I've lobbed it at keyserver.u.c again just in case
<slangasek> just pulled it down from pgp.mit.edu... yeah, that's clearly me :)
<cjwatson> you haven't signed the archive key AFAICS, not sure if you want to
<slangasek> hmm - I intended to do that one too
<cjwatson> if you used caff for it, I don't know if James got round to getting ftpmaster@ubuntu.com fixed to go somewhere
<slangasek> aha, figured out the problem
<slangasek> secret-keyring w/o no-default-keyring
<slangasek> when the default keyring contains a signing subkey, you get an opaque "secret key parts are not available" error :P
<slangasek> ok, archive key signed and pushed
<cjwatson> [this is NOT encouragement for anyone who wasn't present when it was generated and/or has access to the master machines where they reside to go signing the new keys without appropriate knowledge]
<cjwatson> cool, thanks
<infinity> cjwatson: You know a bunch of randoms will anyway, they always do.
<infinity> cjwatson: As for external-bzr-branch-for-blacklists, it's not like there isn't already precedence for LP pulling in a text file from bzr on a cron job (P-a-s), though I'm not sure precedence makes it a good idea. :P
<cjwatson> infinity: it's not like LP needs to know about this anyway :-)
<cjwatson> the main consumer is auto-sync
<Laney> It was some time ago, but I think I was interested in this for syncpackage. If the blacklist can't be universally represented in LP then it's less useful for that kind of purpose.
<Laney> It might still be good to have it in there as much as possible though, in case people do use localpackagediffs
<cjwatson> True, but syncpackage is already doing well enough with the text file
<cjwatson> But yeah, you may be right on that.  Getting people to edit it consistently might be tricky, though.
<Laney> Probably be best to just keep the text file as primary and have a script mirror it into LP.
<cjwatson> Yeah.  Another case for the ubuntu-archive bot account.
<Laney> Or I suppose the other option is to have the blacklist management script write to a text file when it can't commit to LP and then have the sync-blacklist.txt maintenance script we already have merge this one in too
<Laney> either way consumers will have to still look at the text file
#ubuntu-release 2012-05-20
<jtaylor> can the eggdrop update be rejected please? I found another bug in precise which I might as well fix too
<ScottK> jtaylor: Done.
<jtaylor> thx
#ubuntu-release 2013-05-13
<cjwatson> ogra_: FYI, proposed-migration only cares about regressions in installability.  Since I forced ubuntu-touch-meta to be uninstallable (by proposed-migration's definition) once, it won't require further forcing unless it becomes installable again at some point in the meantime.
<ogra_> ah, perfect, thanks !
<cjwatson> (And indeed AFAICS it didn't require forcing at the weekend.)
<ogra_> sigh, seems cadejo is dead again
<ogra_> this is getting old :/
<cjwatson> I've added stgraber to ~ubuntu-archive, mainly on the basis that everyone already thinks he is and I'm quite confident he knows his way around.
<Laney> nice
<blitzkrieg3> hi, I've verified bug 887446, would someone please move it over to -updates?
<ubot2> Launchpad bug 887446 in mtools (Ubuntu Precise) "mlabel: renaming USB stick appends "nA" to name" [Medium,Fix committed] https://launchpad.net/bugs/887446
<stgraber> blitzkrieg3: any reason to rush it to -updates? packages are typically moved 7 days after they get into -proposed (assuming the fix is confirmed and no regression found)
<stgraber> so in the case of this package, it'd likely be released to -updates on Wednesday
<blitzkrieg3> stgraber: oh I didn't know it was automatic...
<blitzkrieg3> stgraber: thanks for the clarification, Wed is fine
<stgraber> it's not automatic, but there's still a default 7 days waiting period
<stgraber> so SRU members don't usually look at copying things that are less than 7 days old
<blitzkrieg3> okay, that works for me
<phillw> hi good people, would the fix for bug 880493 be sitting in the 7 day queue, or does it need a nudge? (Obviously not for me, I'm asking on behalf of a tester).
<ubot2> Launchpad bug 880493 in synaptic (Ubuntu Raring) "Synaptic crashes in vfprintf() with Norwegian locale" [Medium,Confirmed] https://launchpad.net/bugs/880493
<cjwatson> No, it's waiting for manual review by ~ubuntu-sru before entering -proposed
<cjwatson> The 7-day queue is during the verification step after it's in -proposed
<phillw> cjwatson: so, I should ask the OP to wait 7 days and then check to see if it has arrived in proposed? (my first translations bug, as you can tell!).
<stgraber> phillw: there's no fixed amount of time before something gets into -proposed, it'll get in there when someone has the time to review it
<cjwatson> 7 days is irrelevamt
<cjwatson> s/m/n/
<phillw> ah, so it could take some time for a manual review. Sorry, I mis-read what you wrote.
<stgraber> once it's in there, a comment will be posted to the bug report asking you to test the fix, and it's 7 days after THAT, that it'll be copied to -updates
<cjwatson> ... if it's verified
<stgraber> right
<phillw> stgraber: cjwatson do you have any sort of idea of a bug with that many dupes and heat may get reviewed (obviously after vUDS!) ?
<cjwatson> No idea sorry
<stgraber> sorry, can't really parse that sentence, assuming the missing word is "when", then no
<cjwatson> The SRU queue is rarely processed in any kind of order relating to dupes or heat
<phillw> okies, thanks. at least I can tell the OP to subscribe to 'master' bug, as he quoted me one of the dupes.
<cjwatson> Not least because we have no way to see it in that order
<phillw> I can imagine... and translation bugs must a royal pain to check out!
<cjwatson> Not usually
<cjwatson> But I'm not going to look now since bed
<infinity> Gah.
<infinity> cjwatson: Since when do we allow people to upload directly to *-updates? :/
<infinity> wgrant: ^
 * infinity is kicking himself for not noticing the wrong target in the unity-tweak-tool upload.
<wgrant> infinity: Always AFAIK
<infinity> wgrant: Huh.  A bit odd, given that we don't let people upload to devel-release. :P
<infinity> (I could have sworn direct uploads to -updates used to get rejected)
<wgrant> Back in the old days you could upload to just release, or you could upload to all the pockets except release, depending on series status.
<infinity> Yeah, but when we brought in -proposed, -updates should have been locked off.
<wgrant> Certainly
<infinity> If it hasn't been, we've just been remarkably good about people not uploading to the wrong target most of the time.
<wgrant> But "should" is very very broad :)
<infinity> I'm suspicious that this might be a regression since the mapping magic landed.
<infinity> But maybe not.  Maybe people really have been that well-behaved.
<infinity> Anyhow, now I get to decide if I copy/delete that from updates to proposed, or just handwave and not care.
<wgrant> It's not a regression.
<infinity> Fair enough.  People are better behaved than I give them credit for.
<wgrant> infinity: Yeah, not a regression. There've been about 100 -updates uploads since 2009, spread over all the years since then.
<infinity> wgrant: Kay.  Guess I just wasn't the one who accepted any of them.  Or I didn't notice until today. :P
<infinity> wgrant: I'm guessing it would be trivial to rewrite s/updates/proposed/ the same as release is done (with the same ACL check for bypassing)?
<wgrant> infinity: Probably.
<wgrant> Though in this case I'd just reject...
<infinity> I see no reason to hard reject, when a rewrite would DTRT.  But today's behaviour is clearly wrong one way or the other, since it relies on a human to be able to read. ;)
<wgrant> There's no backward compat issue.
<infinity> Rejecting works too, not picky.
<wgrant> We should look for reasons *to* not do what people say, not reason not to not do it :)
<infinity> Rejecting still needs the ACL check, of course.
<infinity> (The argument for the rewrite is that it's a DWIM sort of thing, I don't really care about teaching uploaders about what magic they need in their changelog)
<infinity> If I cared about said magic, I'd insist they always write "series" unqualified, and have the upload email tell them so. :P
#ubuntu-release 2013-05-14
<ScottK> infinity: I've uploaded to updates accidentally before.  Long before the britney changes and studd.
<ScottK> studd/stuff
<infinity> ScottK: Yeah, wgrant dug up stats to prove that it was never disallowed, with some 100ish uploads to *-updates over the last 4 years.
<infinity> ScottK: No reason not to fix that now.  I'd rather have Soyuz catch it than rely on me doing so (where I clearly wasn't up to the task earlier) :P
<slangasek> it was allowed on the grounds that we thought sometimes it would be urgent to get uploads straight into -updates without the -proposed indirection
<infinity> slangasek: Has there ever been such an update where the ~30m delay would have been an issue?
<slangasek> I don't know, I'm just saying why it was never blocked
 * infinity nods.
<jamespage> infinity, thanks for fixing up the section in the eucalyptus packaging
<Laney> please reject ^ - forgot -v
<cjwatson> Laney: done
<Laney> ta
<chrisccoulson> jdstrand, (or any other AA), could you please approve the flash upload for raring? :)
<jdstrand> sure, I'll do it
<jdstrand> chrisccoulson: done
<infinity> chrisccoulson: Do we get a new flashplugin-nonfree that picks up that version?
<chrisccoulson> infinity, yes
<stgraber-uds> infinity, cjwatson: FYI I just finished testing the new rebuild feature for the ISO tracker. python3-qatracker has been updated to match and I've filed an RT ticket. Still need to write a client tool for nusakan to query the rebuild list, trigger and update the status on the tracker.
<stgraber> infinity, cjwatson, balloons: self-service rebuild code is now in production. I'll start poking at the nusakan side of things later this week.
<infinity> stgraber: Shiny.
<Laney> nice
<stgraber> I'm not really happy with the way those are visible in the UI though (just "(re-building)" being appended to the product title) but I didn't feel like doing icon design so if someone wants something shinier, patches are welcome.
<cjwatson> stgraber: awesome.  next step I guess is to write something to do the inverse of qa_product ...
<stgraber> cjwatson: right, the get_list function exported over the API will give us the series name and the product title, so we need to do the inverse of qa_product using that and then trigger the build
<stgraber> nusakan will also need to call an update_status function when it starts building (indicating that the rebuild is in-progress and can't be canceled) and then again once it's done
<infinity> chrisccoulson: ^^ All your flash uploads have been bounced to partner/release.
<jdstrand> infinity: re flash> thanks! :)
<stgraber> cjwatson: hey, so I'm looking at doing that reverse qa_product function. It looks to me like we're almost to the point where we could just list all the possiblities into a separate text file (similar to default-arches) and end up with something that's as readable (if not more).
<stgraber> do you think that's reasonable or do you really want to keep that as code?
<stgraber> thinking of having something like: <qatracker name> <project> <image type> <publish type> <architecture>
<stgraber> with the possible addition of a <series> field if we ever need one
<cjwatson> stgraber: be my guest
<cjwatson> Clearly ought to be table-driven
<stgraber> ogra_: around?
<stgraber> I'm finishing to port qa_product() from a bunch of if statements to a table in a text file. I'm a bit confused by the Ubuntu Touch entries though
<stgraber> do we actually have two different projects being currently built and published under the same name on the tracker?
<stgraber> (one apparently using armhf+<codename> as the architecture and the other just using <codename>)
#ubuntu-release 2013-05-15
<rustx> hi all
<rustx> any update concerning https://bugs.launchpad.net/bugs/1173265 ?
<ubot2> Launchpad bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged]
<rustx> relied to https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325 ?
<ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
<rustx> ?
<Mirv> hello. please accept the following raring unapproved syncs: unity-lens-video nux compiz unity-lens-applications unity bamf
<Mirv> this is the first time I'm asking for these daily-build syncs so I'm unsure how it works, but to be sure I've checked also the latest builds, not only the ones mentioned in the queue (13.05.08)
<infinity> I'm not sure that asking will make it happen much faster.  They're a pain to review. :/
<infinity> In fact, they're impossible to review, since they're no longer in the PPA.
<infinity> \o/
<Mirv> ok, no problem there. mentioning just in case there is any questions about those.
<Mirv> ok, so that's why it was useful to ask :) didrocks ^ any idea on how we should handle those in general, ie. stuff getting removed before the syncs are removed?
<Mirv> s/removed/reviewed/ to the last one
<infinity> I'm not sure that syncs are going to be the best way to do your SRUs...
<Mirv> leveraging the daily build system has been a goal, but it needs to be in a way that works best for everyone
<infinity> Or works at all.
<Mirv> that's the first step :)
<infinity> wgrant: Are these old versions still cleverly hidden in LP somewhere where I can get at them?
<didrocks> Mirv: infinity: it's still in the ppa
<didrocks> if you search for the superseeded ones
<infinity> didrocks: Oh, right.
<Mirv> they are, for example in https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4559066 , but I'm not sure what's the best way to fetch them
<infinity> This is about the most annoying workflow ever.
<infinity> Not shocking that I haven't reviewed any of these. :/
<didrocks> infinity: I thought that cjwatson exposed a new API to be able to review them in a easier way
<didrocks> infinity: btw, you should have the same issue with the new kernels? how is it handled?
<cjwatson> Doesn't 'queue fetch
<infinity> didrocks: I review new kernels in their PPA, but they don't land a new build every day to obscure old ones.
<infinity> cjwatson: Oh, did you make queue fetch actually follow all of this?
<cjwatson> ' work?  Make sure you have a current queue.
<cjwatson> Laney did.
 * infinity tries.
<infinity> Hey, that works.
<infinity> Okay, still more annoying than my kernel workflow, but not world-endingly so.
<infinity> Oh dear lord, but it's downloading all the binaries too.
<infinity> Of course.
<infinity> Cause the queue item is a binary copy.
 * infinity head->desk.
<infinity> That's going to really hurt when it includes ddebs in a few weeks.
 * infinity goes back to reviewing kernels.
<didrocks> yeah, would be good to find something easier, but still getting the same sustainability in term of quality that brings of testing the stack before pushing even for SRUs
<StevenK> infinity: You're welcome.
<infinity> If there's an easy (or even remotely possible) way to trace from a PCJ to an SPR, we could just grab the source with queue.
<infinity> That might be nice. :P
<wgrant> infinity: You can get old versions from a PPA by switching the Published filter on +packages to Superseded
<infinity> wgrant: Yeah, didrocks covered that.
<StevenK> infinity: We talked about linking a PCJ to a SPR at the sprint
<infinity> wgrant: Not that that's convenient for this particular usecase.  queue fetch is a bit better, except that it's getting the whole PCJ.
<cjwatson> infinity: On my list, but needs a DB change.
<StevenK> Then we got distracted by ev wanting ddebs two weeks ago.
<infinity> StevenK: I'm sure we did.  That was ages ago.  I can't brain that long. :)
<cjwatson> queue show-urls or whatever might help for now.
<cjwatson> Or hack fetch to igmore binaroes.
<wgrant> infinity: Grab dsc URL, then get
<wgrant> dget
<cjwatson> With spelling.
<infinity> Or that.
<infinity> I just need the URL to feed to dget and I'm happy.
<cjwatson> That's why queue has a subcommand for that ...
<infinity> Ah-ha.
<infinity> Wait, it does? :P
<infinity> I guess it doesn't work on PCJs.
<cjwatson> Leave an example in the queue and I'll have a look in a bit.
<infinity> cjwatson: Leaving them all there right now, I'm busy with emergency kernel SRUs.
<StevenK> cjwatson: I've got one -- http://pastebin.ubuntu.com/5666760/
<rustx> hi all
<rustx> do you have any update concerning https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325 ? relied to https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1173265 ?
<ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
<ubot2> Launchpad bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged]
<infinity> rustx: You might want to talk to rbasak (who is posting patches to the bugs).  This channel isn't for bringing up your pet bugs.
<infinity> rbasak: PS, if you need a sponsor for things like that, you know where to find me. :P
<rustx> infinity : pet bugs ?
<rustx> if you call a SRU update a pet bugs .. well, maybe I don't exactly get what you mean
<infinity> rustx: Perhaps that was a bit too harsh, but the sentiment stands.  This channel is for release co-ordination, and occasionally severely critical bugs come into that, but most bugs (SRU bugs or otherwise) are just noise here.  If every bug had someone championing it in this channel, we'd not be able to speak.
<rustx> ok. good way to make people help fixing bugs
<rustx> doesn't matter
<rustx> on my side, everything was fixed. We are just using LTS on production .. huhuhu
<rustx> be sure i won't track any bug with you guy, and will fix those on my sides at the end.
<infinity> rustx: My message opened with suggesting who you might want to talk to.
<rustx> infinity
<rustx> infinity: yes i got it, but the way you reply does not sounds like a 'Open Source community'. You should go and work with russians at mandriva
<rustx> anyway, doesnt matter; rbasak is sometimes here, and this is thanks to this channel i icould go on with that bug
<infinity> rbasak is also in #ubuntu-devel, which would be a better place to discuss bugfixes.
<cjwatson> Bug tracking is gteat, but it does get tough when everythimg'smirrored onto IRC in coordonation channels
<rustx> no trouble
<rustx> i will quit the channel, and will not disturb you any more
<rustx> thank you !
<cjwatson> sigh, apparently not so good at typing in connectbot
<infinity> And, to be fair, the reason I knew he was involved in the bugs was because I looked them up the last time you asked about them.
<infinity> cjwatson: Nobody is.
<rustx> infinity: thank you anyway, i don't get upset for this. sorry for disturbing
<rustx> it's just when you have LTs on production, and when it's not stable, it's not good. That's all
<rustx> bye bye
<rbasak> rustx: I can update you in #ubuntu-devel. This channel is not the appropriate place.
<rbasak> rustx: but I can only do that if you actually join #ubuntu-devel :)
<rbasak> Do we run dep8 tests during rebuild tests, OOI?
<cjwatson> No.
<cjwatson> They're just package rebuilds.
<cjwatson> But DEP-8 tests often involve partial rebuilds anyway ...
<Laney> queue fetch downloading binaries> easy to turn this off or make it a flag - it's a separate API call anyway
<rbasak> This facter bug is an example where if we'd had a dep8 test and it had run during a rebuild test then we'd have picked it up. But it only causes a delay fixing the issue in an SRU, rather than causing an actual regression in the archive.
<Daviey> rbasak: Separately, i've been interested in running dep-8 tests accusingly
<Daviey> occasionally
<rbasak> fixing other issues in SRUs, rather
<cjwatson> In this case wouldn't it have been sufficient to have a suitable package-build-time test?  Doesn't seem to require autopkgtest.
<cjwatson> autopkgtest also often winds up rebuilding the package anyway, depending on configuration, so a rebuild test might well be redundant.
<infinity> cjwatson: Actually, in this case, a build-time test wouldn't show the issue.
<infinity> cjwatson: Cause build-deps allow it to work, but run-time deps are wrong.
<rbasak> That may work, but I'm not confident in the general case. There seems to be some Ruby voodoo with generating the shebang that I don't like. I'm not confident that the generated (or supplied) Depends: line will match (or not match) with the shebang the same way in the build environment and after the package is properly installed.
<Daviey> cjwatson: Unless i am mistaken, there isn't an upstream unit test on this package - which would mean introducing one - and dep8 seems to be a reasonable test for this issue?
<infinity> Anyhow, doing dep-8 with our rebuild tests could prove difficult, since we don't publish the binary results of rebuild tests anywhere.
<infinity> But I'm sure it could be done by someone sufficiently interested enough in making it happen.
<Daviey> cjwatson: Generally, we were lookng to get greater dep8 coverage this cycle.. With some things being a simple "$binary --help" to check it exists 0 and didn't have an error starting.
<rbasak> Just a thought for the future. It sounds like it's too much effort to be worth doing right now.
<ogra_> stgraber, the current saucy image doesnt have the android bits (armel+$subarch), so it only advertises the rootfs (armhf) ... "ubuntu-touch" is what we will go with, "*-preview" will die when we stop rolling raring
<cjwatson> Well, OK.  But AIUI a DEP-8 test that rebuilt the package would do the job here.
<infinity> cjwatson: Not if the build-deps remain installed when the test is run.
<infinity> cjwatson: The problem is that it ends up build-depending on ruby1.9.1 but runtime depending on ruby1.8 (oops).
<cjwatson> They don't.  autopkgtest uses different chroots.
<infinity> Maybe I'm misunderstandig what sort of test you meant.
<ogra_> hmm, does britney have a hiccup ?
<ogra_> The following packages have unmet dependencies:
<ogra_>  unity-webapps-common : Depends: gjs but it is not installable
<ogra_> E: Unable to correct problems, you have held broken packages.
<infinity> ogra_: That's not britney's fault.
<ogra_> broken dependency ?
<seb128> ogra_, gjs is in universe, we just got an upload in to fix that
<infinity> ogra_: That's just you only having main in sources.list and unity-webapps-common growing a universe dep.  It's being fixed.
<ogra_> (in any case it breaks all desktop images today)
<infinity> (Well, it's sort of britney's fault, in that it doesn't take components into account, but that's a known misfeature)
<ogra_> k
<cjwatson> infinity: I'd have thought a simple DEP-8 --help test or similar would do it, as long as it's run/restricted/whatever such that it builds the package first and then tests the rebuilt one.  When autopkgtest tests a package, regardless of whether it's rebuilt it first, it takes care to install it in a chroot with only declared dependencies and to run the tests there.
<infinity> cjwatson: Ahh, kay.
<infinity> cjwatson: That last bit was the missing piece for me.
<Daviey> nothing currently autopkgtest's suitable SRU's right?
<infinity> There's very little automated anything for SRUs.  This is on the TODO list.
<infinity> First step is sorting out how to bring britney into play for SRUs, then it can tie into autopkgtest the same way we plan to for development releases.
<Daviey> infinity: sounds good
<tkamppeter> Someone around who is in charge of SRUs? When will the proposed CUPS package for Quantal, bug 1086019, get approved?
<ubot2> Launchpad bug 1086019 in cups (Ubuntu Quantal) "cupsd crashes regularly (daily)" [High,In progress] https://launchpad.net/bugs/1086019
<tkamppeter> infinity, RAOF, SpamapS, bdmurray, slangasek, ScottK: ^^
<tkamppeter> Thanks.
<infinity> NP.
<chrisccoulson> jdstrand, or anyone else, could you please approve that? ^^
<jdstrand> sure
<jdstrand> chrisccoulson: done. it will build in -proposed now. ping me when it is ready and I'll copy to partner release
<chrisccoulson> jdstrand, cool, thanks. i've got uploads for the other 2 releases too. i'll upload those now
<chrisccoulson> ok, those should appear any second now
<chrisccoulson> jdstrand ^^ :)
<jdstrand> chrisccoulson: done
<chrisccoulson> jdstrand, cool, thanks
<stgraber> ogra_: ok, any ETA on that (stop building raring)?
<ogra_> stgraber, i am still researching the container flip
<ogra_> we want to have that done before switching to saucy (though it doesnt look good atm)
<stgraber> ok
<stgraber> I'll just support both project names for now then and we'll drop -preview once we're done switching to saucy
<davmor2> cjwatson: hey dude.  I just hit an interesting issue upgrading my Raring box to Saucy.  From UEFI/Secureboot comes the message Ubuntu has been blocked by the current security policy :(
<cjwatson> davmor2: unlikely to be able to look during UDS sorry
<davmor2> cjwatson: yeap no worries I disabled secure boot for now and it is working and I can easily reinstall a secure booted raring on it and upgrade again next week, I just thought I would highlight it as it just happened.
<cjwatson> infinity: 'queue show-urls' now works on copies, and you can use the --source or --binary options to limit which items the 'fetch' and 'show-urls' subcommands operate on
<cjwatson> infinity: so e.g. 'queue fetch -s raring-proposed -Q unapproved --source nux'
<tumbleweed> apologies. got a friend's birthday do, I'll miss the release-ish sessions
<tumbleweed> don't decide anything too crazy :)
<stgraber> tumbleweed: will try to be reasonable, we'll just assign all the work items to you ;)
<tumbleweed> good
<Laney> seems perfectly reasonable to me
 * iulian nods.
<Laney> so I can't really make this session but my opinion is that the later feature freeze worked well and we should stick with it
<Laney> bonne nuit
<stgraber> Laney: ok, we'll share the work items with tumbleweed then ;) have a good evening
<stgraber> infinity: ping
<cjwatson> infinity: are you around for the release schedule discussion?
<cjwatson> ah, snap
<infinity> stgraber / cjwatson: Gah.  Late night kernels broke me.  Just woke up.
<cjwatson> infinity: 20:51 <knome> can you also mail the flavor devel lists?
<infinity> knome: Sure.
<knome> infinity, thanks
<knome> infinity, hmm, only now i connected your nick and name. did you use to use some other nick previously?
<infinity> knome: I've been infinity for decades. ;)
<knome> infinity, okay.. i thought adconrad or something.
<knome> oh wait, that's your username - that makes sense :)
<infinity> knome: Oh, I'm adconrad in launchpad, and generally as a UNIX login.
<infinity> knome: Yeah.
#ubuntu-release 2013-05-16
<infinity> Daviey: So... You just subscribed the SRU team to a private bug that appears to have nothing to do with the changelog that linked it.
<infinity> Daviey: Might be nice to look at the bugs in an SRU before accepting it. ;)
<Daviey> infinity: Yes, that is something I am resolving.  I dropped the last digit, but did resolve it.
<infinity> Daviey: Oh, the changelog was fine, it was you typoing it for sru-accept. :P
<Daviey> Yes. :(
<infinity> You can re-run sru-accept, at least.
<Daviey> i did
<infinity> And I cleaned up the private bug.
<Daviey> ta
<Daviey> infinity: Do you think this SRU candidate should be doing deluser on purge? http://launchpadlibrarian.net/134943143/qemu-kvm_1.2.0%2Bnoroms-0ubuntu2.12.10.3_1.2.0%2Bnoroms-0ubuntu2.12.10.4.diff.gz
<Daviey> infinity: http://wiki.debian.org/AccountHandlingInMaintainerScripts .. never got closed/agreed AIUI
<infinity> Daviey: I'm firmly in the "don't delete on purge" camp.
<infinity> Daviey: Especially since the adduser/group there is guarded with a getent, it's somewhat assuming you may have already had a local one and using that.
<infinity> Daviey: So, deleting someone's local group is a bit rude. :P
<Daviey> infinity: wfm
<brendand> join #ubuntu-uds-foundations-1
<brendand>  / ahem
<ogra_> doit ... we know you can !
<ogra_> infinity, awake ?
<ogra_> or doko
<doko> ogra_, ?
<ogra_> doko, can you come to the android packagin session ?
<ogra_> http://summit.ubuntu.com/uds-1305/meeting/21807/foundations-1305-android-builds-revisited/
<jdstrand> infinity: hey, so bug #1089488 completed verification today. it has another 12 hours to go before it has been in proposed for 7 days. I have security updates built on top of those proposed packages that I'd like to get out today (ie, not a friday update)
<ubot2> Launchpad bug 1089488 in nova (Ubuntu Precise) "Meta bug for tracking Openstack Stable Updates" [Undecided,Fix committed] https://launchpad.net/bugs/1089488
<jdstrand> infinity: I'd like some advice. I'm fine with honoring the 12 hours, but I'm afraid I won't have someone from ubuntu-sru around to do the pocket copy when I need it done
<jdstrand> (ie, 12 hours from now)
<jdstrand> infinity: so, we could wait a few more hours and do it after UDS, or we could approve the pocket copy and I can do it myself
<jdstrand> (later)
<jdstrand> or someone can promise to be around in 12 hours
<ScottK> jdstrand: Let's do it now.
<ScottK> What needs releasing?
<jdstrand> ScottK: cool, thanks
<jdstrand> ScottK: glance, horizon, keystone and nova
<jdstrand> for precise
<ScottK> jdstrand: Just on precise?
<ScottK> OK.
<jdstrand> they are all green on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<ScottK> jdstrand: Done.
<jdstrand> \o/
<jdstrand> ScottK: thanks :)
<ScottK> You're welcom.
<cjwatson> ftpmaster@debian did a NEW run, I see ...
<cjwatson> wg 29
<cjwatson> oops
<Ursinha> infinity, are we meeting in 30 mins or would that be too cruel to wgrant and StevenK?
<infinity> Ursinha: Pete cancelled the meeting this week.
<infinity> Ursinha: And I have an action item to move the meeting time for next week.  Thanks for the reminder. :)
<Ursinha> infinity, I wonder why it's still showing for me
<Ursinha> hah, np :)
<infinity> Ursinha: He cancelled it via email (which you weren't CCed on, apparently), but probably didn't bother on the calendar. :)
<Ursinha> infinity, okay, thanks for letting me know :)
#ubuntu-release 2013-05-17
<jamespage> if there are any archive admins around; I just added armhf to google-perftools in Packages-arch-specific after it had build in proposed with the associated packaging changes;
<jamespage> its now building for armhf direct for the release pocket so it will look a bit odd
<jamespage> Daviey, ^^ as you are in my tz
<Daviey> jamespage: Hmm, sorry.. I'm not understanding
<infinity> jamespage: That doesn't need an AA...
<cjwatson> jamespage: not a problem
<Laney> He made the change and is just informing AFAICT
<jamespage> Laney, you got it
<jamespage> normally the NEW packages would appear in -proposed
<jamespage> but not in this case
<infinity> Nothing new here.
<cjwatson> Yeah, it won't count as NEW.  That's based on name.
<Daviey> Ah, you mean it will show as binNEW for the release pocket.  I see.
<infinity> And it won't get caught in proposed because britney finds no regression in armhf not being built yet.
<infinity> No big deal.
<infinity> Daviey: It won't.
<cjwatson> Once a binary name has been NEWed for >=1 architecture and published, it won't thereafter count as NEW for other architectures.
<jamespage> cjwatson, I did not know that
 * jamespage learns something new again
<Daviey> cjwatson: arch all to separate does show, right?
<infinity> all to any, you mean?
<Daviey> yes
<infinity> Neither all->any or any->all should count as NEW.
<Daviey> Hmm, i thought i had seen that. I guess not.
<infinity> Note that I said "shouldn't", it's possible there's a bug where it does, but I don't recall ever seeing such behaviour. :P
<cjwatson> Daviey: like infinity, I'm not aware that it does, no.
<cjwatson> And it would irritate me if it did so I think I'd notice.
<infinity> In other news, it's probably about time for us to retire P-a-s.
<cjwatson> I had a brief look at importing it into the LP DB a while back in order to be able to fix some of the outstanding bugs where certain kinds of source operations don't honour P-a-s
<cjwatson> But never got very far
<infinity> I might go through it and see if I can find any valid arguments for us keeping it, push packaging changes back to Debian for things that are obviously arch-restricted but not in control, and call it done.
<infinity> cjwatson: I meant retire it entirely, not remodel it.
<infinity> cjwatson: It's nowhere near as useful as it used to be.
<cjwatson> That would certainly be more fun
<cjwatson> I suspect there are cases where architecture restrictions need to be synced across many packages due to some bit of foundational code not being ported, which tends to be non-fun to put in all the packages in question
<cjwatson> I can see an argument for centralising such things
<infinity> cjwatson: Yeah, but I also don't mind the inverse argument that, if you have the resources to take a few build failures, it's nice to just have the FTBFS logs there as a reminder to effin' port the code.
<infinity> cjwatson: And for obviously arch-restricted stuff (things that depend on binary drivers, etc), it really should be arch-restricted down the chain, IMO.
<infinity> I'm not sure I'm a fan of the "it's not ported, so put it in P-a-s" use case.  It just buries the list of things that need porting.
<infinity> (I was a much bigger fan of that use-case when I was an m68k buildd admin, but...)
<cjwatson> I don't think things that aren't ported themselves should be in P-a-s, but collateral damage is a bit different
<cjwatson> Perhaps
<infinity> Collateral damage often just ends up in perpetual dep-wait, which isn't so bad.
<cjwatson> It at least makes no sense to me that google-perftools is in P-a-s at all
<infinity> (Like all the rdeps of V8 on powerpc)
<cjwatson> Actually the way that LP doesn't quite consistently honour P-a-s in all cases (e.g. copies) is one of the reasons people have ended up overdoing things there, I think
<Daviey> it does urk me that there isn't a tool i can say $ what-ya-wanna-build-for *.changes
<cjwatson> Hm, no, that makes no sense.  Maybe it failed to honour Architecture or something
<infinity> Daviey: Misspelling irk irks me.
<Daviey> infinity: urks me more.
<infinity> *flinch*
<cjwatson> ogra_: Given the legal debacle over the last thing called "utouch", I don't think it's a good idea to abbreviate Ubuntu Touch to utouch.
<ogra_> oh
<ogra_> there was a legal debacle ?
<ogra_> i can indeed rename it to just -touch or -ubuntu-touch (the latter feels a bit longish)
<cjwatson> We had to go through everything called utouch in the archive and rename it ...
<cjwatson> Trademark dispute
<cjwatson> So rejected, please call it something else, don't mind exactly what :)
<cjwatson> This is why the touch-as-in-touchscreen stuff is called OIF nowadays
<ogra_> ah
<stgraber> cjwatson: is it just a local setup issue or are the cdimage unittests failing on saucy?
<stgraber> I've been trying to figure out how I broke some random bits with my qa_product rework just to notice that the tests failed even without my changes ;)
<stgraber> cjwatson: nevermind, it's just a missing test dependency (zsync)
<cjwatson> stgraber: Hmm, not totally sure I intended that to be a dependency.  Let me look
<stgraber> cjwatson: ah, ok. I already added it as a dependency in run-tests, so if you can somehow make it unnecessary for the tests, remove it from there
<cjwatson> stgraber: done
<stgraber> nice, finding a few problems in the current set of tests for qa_product, we were testing for products that don't exist in reality, so now that I check against a fixed list all of those are showing up as failures ;)
<stgraber> cjwatson: hey, there's one bit I'm a bit unclear on, are the paths in the images parameter of post_qa supposed to include the .iso or not?
<stgraber> cjwatson: hmm, looking at some of the other tests, it looks like the answer is no and test_post_qa_wrong_date is just buggy
<stgraber> and testsuite passes!
<cjwatson> I believe they should not contain .iso
<cjwatson> Indeed that test is wrong, sorry
<stgraber> alright, I'll do one more pass through the tracker to make sure my updated tests don't regress in test coverage, then push that and the new etc/qa-products file+parser
<stgraber> cjwatson: is there a magic way to have a file copied from the real etc/ into the temporary etc/ used to run the tests? (I want etc/qa-products to be copied over)
<stgraber> cjwatson: went with a rather ugly workaround in setup() for now, we can always move to something cleaner later on.
<stgraber> cjwatson: and I just pushed the changes now to production including the new cdimage_project function (opposite of qa_product). All tests pass and I triple-checked the product list so I think we're good, I'll still do a bit of grepping in the logs to make sure we don't fail to publish something.
<stgraber> cjwatson: qa_product also now returns a tuple instead of just a string, the second value is the name of the tracker instance (iso or localized-iso). I'll push another update to actually use that properly (only zh_CN should be affected).
<cjwatson> stgraber: Copying it wouldn't be very unit-testy; better to write out temporary files with just the features you're trying to test
<cjwatson> stgraber: Thanks; will have a look later :)
<stgraber> cjwatson: well, our existing unit tests cover every single line of etc/qa-products, though I suppose we could change that to use a temporary input file with a smaller subset of tests that actually test the corner cases
<cjwatson> The latter is my preferred approach for unit testing, indeed
<phillw> cjwatson:  ubuntu server 12.04.2 has been moved from http://cdimage.ubuntu.com/ubuntu-server/precise/daily/20130214/precise-server-amd64.iso on the QA tracker... any idea where it is now?
<infinity> phillw: Given that 12.04.2 was released quite a while ago, I'd expect it to be at http://releases.ubuntu.com/12.04.2/
<infinity> (Not sure that the ISO tracker is meant to be all that useful post-release)
<stgraber> it's useful to grab bug information and statistics, we indeed don't expect the URLs to be of much use though
<phillw> infinity: point taken but maybe http://iso.qa.ubuntu.com/qatracker should be updated to a correct link. As a tester, I am used to heading there and grab the link for an install :)
<infinity> Definitely not the write place to get "golden" install images, IMO.
<infinity> Wow, fingers, did you really just type "write" instead of "right"?
 * infinity smacks his fingers around a bit.
<phillw> stgraber: In that case, what is the point of having the entries on that page? Just a thought... please do not shout at me.
<stgraber> phillw: as a tester you're not supposed to test something that's released ;)
<phillw> stgraber: I am supposed to check for regressions :D
<phillw> 12.04 is an LTS :P
<stgraber> however we're supposed to have a flag that tells you the links won't work but I guess the scanner doesn't run against release milestones (I can probably change that)
<phillw> stgraber: thanks, it is the first time I've come across this. I wanted to zsync up a 12.04.1 to 12.04.2 and it failed with the "Oh, it's gone" (404) errors
<phillw> -s
<phillw> I know server is a pain to track! I'll just do a 'get' on it.
<infinity> phillw: You can zsync from the above URL, where it's released...
<phillw> infinity: okies :) I did rename it back from 12.04.1 to the expected name. Sadly, I only use the server install for people who request it. I did try to install an 10.04 one for xnox but I could not get it to talk to the world (They are on KVM system).
<phillw> infinity: I have http://cdimage.ubuntu.com/ubuntu-server/precise/daily/current/ where should I be heading?
<infinity> phillw: releases.ubuntu.com?
<infinity> phillw: Expecting released images to be in a directory marked "daily" seems a bit of a disconnect. :)
<phillw> infinity: have a look at http://releases.ubuntu.com/ Ubuntu server is not mentioned?
<infinity> phillw: If you read scrollback, I pointed you at http://releases.ubuntu.com/12.04.2/
<infinity> phillw: ubuntu-server is just another Ubuntu image.
<infinity> (releases.ubuntu.com/precise also works, lands you in the same place)
<phillw> infinity: and as some one looking for a system... http://releases.ubuntu.com/ it says to head to cdimage server?
<infinity> phillw: It tells you to go to cdimage for other flavours (which it then lists).  Ubuntu isn't a flavor, and is linked at the top before that blurb.
<phillw> Ah.. thanks, scrolling down I found it :)
<cjwatson> It should qualify its mention of Ubuntu there.  I'll fix that.  Otherwise, most people have no trouble finding server images given they're linked from the website and other prominent places
<cjwatson> (done)
<phillw> sorry for annoying, I'm a tester and get asked away from here, to grab an iso / update an iso not and again. Having a simple link to zsync is what I ask for when people have a problem installing. I know that this is not a release team issue, thank-you for your understanding :)
<phillw> s/not/now
<phillw> cjwatson infinity: I have the link of http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-server-amd64.iso.zsync and I get the error :
<phillw>  http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-server-amd64.iso.zsync
<phillw> -bash: http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-server-amd64.iso.zsync: No such file or directory
<cjwatson> You might like to try a command in front of that.
<cjwatson> Like zsync ...
<phillw> cjwatson: there are times I hate you :D As  I said, I'm used to qa-tracker which does include it when copying and pasting :D
<phillw> 3:04 mins to go :)
<phillw> cjwatson: not that people ever bother, but http://phillw.net/isos/ubuntu-server/precise/ has been updated.
#ubuntu-release 2013-05-18
<kotux> Hello, can somebody on Ubuntu 13.10 confirm this bug?
<kotux> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1181442
<ubot2> Ubuntu bug 1181442 in gnome-control-center (Ubuntu) "gnome-control-center reads 'Ubuntu 13.04' on Saucy" [Undecided,New]
<infinity> kotux: Yeah, the image needs updating.
<kotux> infinity, so that string is an image?
<infinity> kotux: It's not a string at all, no.
<infinity> If it was, I would have fixed it. :P
<kotux> well, for my untrained eyes, it looked like one.  :S
<kotux> How difficult is it update images?
<infinity> Probably not very, I'm just not sure who has the original working copy.
<infinity> I was considering going MS-Paint style with a spray can over it, but I'm not sure people appreciate "fun" updates anymore.
<infinity> We've all gotten too stuffy and professional. :(
<kotux> haha, well, do you think the bug is a manageable task for a starter?
 * kotux updated the bug report.
<infinity> Probably not a bitesize bug, no.  Well, not in the "anyone can do it" sense.
<infinity> Needs someone from the design team to dig up the original logo and make it go.
<infinity> But I might do the spray can thing as incentive for the desktop team to do it right. :P
<kotux> Interesting. For the report, should I say the ticket affects the design team?
<infinity> kotux: I just went ahead and assigned it to the designer who updated the image for 13.04
<kotux> Oh great, thanks!
<ScottK> infinity: Surely gnome-control-center isn't failing to ship things in the preferred form for modification?
<infinity> ScottK: Yeah, I'm going to follow up with Seb and Rosie about that too. :P
<infinity> ScottK: (That said, there are hundreds of packages in the archive that ship PNGs instead of some sort of source file)
<infinity> And, I could edit the PNG, I just prefer not to if there's a shinier master somewhere.
<ScottK> Sure, but in theory Canonical should know better.
<kotux> ScottK, yeah.
<infinity> So should GNOME and KDE, but I bet they both fail on that front too.
<ScottK> Possible.  I know for Oxygen icons all the scalable variants are shipped (and that is the preferred form for modification)
<kotux> infinity, say I wanted to branch gnome-control-center for scrutiny.
<kotux> https://code.launchpad.net/ubuntu/+source/gnome-control-center
<infinity> pull-lp-source gnome-control-center or bzr co lp:ubuntu/gnome-control-center should get you similar results.
<kotux> on Saucy (active development), there are two branches, both in development.  Which one should I pull?
<infinity> The former being the authoritative source package, the latter being whatever the heck LP thinks is the packaging branch. :P
<kotux> and sometimes, LP isn't so smart?
<infinity> Oh, the saucy/saucy-proposed branches are probably identical.
<infinity> Just the importer being silly.
<infinity> Yeah, they're the same.
<infinity> And they both match the archive source too.  So, whatever.
<kotux> in time, which one should I choose?
<kotux> when things get more complicated
<infinity> ScottK: Anyhow, I'm not arguing that it's ideal, and I would prefer a non-lossy version of the image in the source package, but I also know it's common to not care about sources for images. :/
<infinity> kotux: The archive is the only thing that's ever authoritative, however if you want to play well with others, follow the Vcs-Bzr field from the package's debian/control.
<infinity> kotux: Which points to a place you've not looked yet. ;)
<infinity> http://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu
<kotux> wow, three places!
<jbicha> it would be much nicer if the version number there was dynamic text (like it is upstream) instead of as an image
<infinity> That too.
<jbicha> the version number listed is usually wrong half the release cycle and creates more work for backports
<infinity> Given that it's in an Ubuntu font that ships on the system anyway, I imagine turning that into a GTK text box that populates with something that looks exactly the same wouldn't be too hard.
<infinity> Patches welcome, etc. :)
<infinity> For bonus point, you might even be able to get it to swap logos and text based on which *-desktop packages are installed, but that sounds a bit more ambitious.
<infinity> (And probably not worth the effort)
<jbicha> I guess Fedora also patches that spot but they don't include the version number https://bugzilla.gnome.org/show_bug.cgi?id=695691
<ubot2> jbicha: Error: Could not parse XML returned by Gnome: The read operation timed out (http://bugzilla.gnome.org/show_bug.cgi?id=695691&ctype=xml)
<infinity> They do, actually.
<phillw> bdmurray: as it is your bot, the patch for bug 1078820 is being installed into saucy for lubuntu.
<ubot2> Launchpad bug 1078820 in lubuntu-software-center (Ubuntu) "The lubuntu software centre is not showing any other software execpt the ones already installed on my computer." [Undecided,Confirmed] https://launchpad.net/bugs/1078820
<phillw> It already fixes the issue in 13.04, so I guess there will be an SRU at some point :)
<TheLordOfTime> phillw:  someone has to prep the SRU if I'm not mistaken
#ubuntu-release 2013-05-19
<cjwatson> stgraber: queuebot seems to have gone silent again
<cjwatson> should've been some NEW activity
<stgraber> that should fix it (had some network problems which probably made the LP plugin hang)
<cjwatson> ta
#ubuntu-release 2014-05-12
<seb128> could somebody review some of the trusty SRUs? the unapproved queue is over 30 items with some waiting for over 15 days
<seb128> slangasek, bdmurray, arges, stgraber: ^
<mlankhorst> infinity: are you doing the 12.04.5 updates?
<bdmurray> seb128: I can have a look later today
<seb128> bdmurray, thanks, nautilus should be an easy one if you want to start somewhere ;-)
#ubuntu-release 2014-05-13
<slangasek> bdmurray: update-manager -d on trusty fails for me with 'Failed to download repository information' - any idea why?
<bdmurray> slangasek: try with DEBUG_UPDATE_MANAGER=1 set
<slangasek> bdmurray: seems fairly nondescript: http://paste.ubuntu.com/7455113/
<bdmurray> slangasek: edit /etc/update-manager/release-upgrades.conf from lts to normal
<slangasek> bdmurray: hmm; surely -d should override that?
<slangasek> (so I think that's a bug, even if editing it works around it)
<bdmurray> lts sets lts in the url, so -d with lts just means you want the devel version of the next lts
<slangasek> ah, that's nonintuitive
<slangasek> anyway, same error
<slangasek> (assuming that /etc/update-manager/release-upgrades is the right file, since that's the one that exists / is owned by the package)
<slangasek> http://paste.ubuntu.com/7455126/
<bdmurray> new dist: <UpdateManager.Core.MetaRelease.Dist object at 0x7f68e3e369b0>
<bdmurray> so that looks right to me
<slangasek> yeah... still gives the error about failing to download repo info
<slangasek> and does not offer me an upgrade
<slangasek> so that seems to be because I have some repos in sources.list that are not currently accessible
<bdmurray> ah yeah that sounds familiar
<bdmurray> I can't find the bug right away though
<slangasek> hmm
<slangasek> but after disabling them, I no longer get the error but I also don't get offered to upgrade
<slangasek> possibly because it doesn't like me for continuing to postpone the "you must reboot NOW" dialog :)
<cjwatson> doko: Are the powerpc builders just on manual in order to schedule gcc-4.9 on sagari?  If so can they be re-autoed now?  (Guessing as to somebody who might know ...)
<doko> cjwatson, yes, reenabled
<cjwatson> Thanks
<doko> would take 24+h else
<cjwatson> Sure, I have no problem with shoving stuff on sagari, just wanted the rest of the queue to clear :)
<mlankhorst> so who's going to work on 12.04.5?
<Mirv> hi. out of the trusty's unapproved GStreamer updates, if you can work only on one of them, please try to get gst-libav approved which alone fixes a very visible crasher when seeking h.264 files (including any totem thumbnailer usage since it seeks first)
<seb128> infinity, SpamapS, Daviey, slangasek, arges: hey, is there any chance some of you could spend some time on the trusty SRU queue this week? We have some important fixes waiting for 3 weeks :/
<arges> seb128: sure i'll spend some time today
<seb128> arges, thanks!
<arges> seb128: so bug 1312305 bumps gst* packages to 1.2.4 from 1.2.3. some of these haven't landed in utopic yet. should we wait until these land there and get some testing before updating trusty?
<seb128> arges, well, we can do that, I was expecting those to be approved to proposed and pocket copied to utopic
<seb128> which we often do early in the cycle
<seb128> Laney, ^ I think the ones with changes are yours
<seb128> (gst and base are synced to utopic already)
<dpm> hi all, also following up on the previous comment, could someone help with approving the Qt upload in the Unapproved queue? It fixes a Qt regression that affects running and developing the Reminders app on the desktop. https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= - ScottK, perhaps?
<Laney> arges: I thought they would be copied up when I did them
<Laney> (IIRC)
<Laney> I can upload them too at the same time, would appreciate simultaneous verification in proposed though if possible
<arges> Laney: I'm just not 100% sure how to handle these, so I'd like to get input from infinity, slangasek, bdmurray, etc about reviewing the gst* packages
<Laney> wait
<seb128> arges, just because of the utopic upload thing?
<seb128> arges, because e.g gstreamer1.0 has 1.2.4-1 in utopics
<seb128> same for -base
<Laney> didn't I upload them all already?
<Laney> to U, that is
<arges> Laney: there are some that are fix committed in 1312305
<seb128> seems you did
<seb128> Laney, you probably didn't update the bug status
<Laney> oh I guess because sync
<Laney> yep
<seb128> those are mine :p
<seb128> arges, sorry about the confusion, everything is in utopic, I just failed to set to "fix released" the one that got autosynced from Debian
<Laney> done now
<seb128> thanks
<arges> Laney: seb128 so has any testing been done, or that will be done after it lands in -proposed?
<arges> in trusty for 1.2.4
<seb128> well, I'm running it locally since it got uploaded
<seb128> which is as much testing as we do before sending things to proposed
<Laney> not for SRU purposes, that'll be done by people when they test proposed and give feedback to the bug
<seb128> that's why we have the "1 week in proposed" to get things tested
<rtg> infinity, whats the story on -Werror=cast-align ? libnice started using it, but glib-2.0 is definitely not alignment safe for armhf (and perhaps for other arches I don't care about). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743233 - Is it OK to just turn it off and continue take the performance hit for alignment traps ?
<infinity> rtg: For arches that do alignment fixups (like armhf), it's just a performance penalty, so safe enough, but still bugs worth fixing.
<rtg> infinity, I can fix some, but the glib-2.0 stuff requires deeper thought then I can give it.
<rtg> plus, the fixes are probably less performant then just taking the trap
<jamespage> bdmurray, just after you accepted my ceph upload for 14.04 upstream released a 0.80.1
<jamespage> bdmurry: I'm doing some testing via PPA and I'd like to upload that version in the next day or so if that's OK with you
<bdmurray> jamespage: sure, just let me know
<jamespage> bdmurray, ta
<infinity> rtg: Yeah, if the "fix" is wasting a few hundred thousand cycles on mangling things in C to not misalign, you've lost the game.  But sometimes, it's as simple as padding a struct correctly or something, and you're done.
<infinity> rtg: Of course, for libraries, fixing alignment on public structs also breaks ABI, so sometimes it's pretty much unfixable without upstream buy-in and an SOVER bump.
<rtg> infinity, thats what I'm thinking is the case for glib-2.0
<rtg> infinity, it looks like upstream added tihs test, and then never built with a compiler that implements it.
<infinity> rtg: Of course. :P
<rtg> doh!
<infinity> bdmurray: Hrm.  Why doesn't sru-release have an option to set phasing?  Do I just need to do it manually and hope to avoid override races?
<infinity> bdmurray: (Have a tzdata upload to do that's critical because the changed timezone takes effect in two days, so phasing it to 100% pretty much will have to happen)
<robru> hey guys, we have another unity8 release that needs a version bump. thanks!
<infinity> robru: On it.
<robru> infinity, thanks!
<infinity> Man, the new colourful adt results in excuses are distracting.
<ogra_> haha
<robru> infinity, hey. so looking at excuses, we have 4 different things that are blocked by a regression in ubuntu-purchase-service. I just published the fix for that though, so once it lands do I need to do anything special to get those tests to re-run? or will it see he new release, re-run, and then allow those 4 blocked things to migrate?
<infinity> robru: The latter, modulo potential bugs in the system.
<robru> infinity, sweet, ok thanks, will keep an eye
<cjwatson> Yeah, I believe that should work.
<michagogo|cloud> infinity: tz change with 2 days notice? o_O
<infinity> michagogo|cloud: It's possible I've cursed a little bit this morning.
<michagogo|cloud> infinity: reminds me: have you seen https://www.youtube.com/watch?v=-5wpm-gesOY yet?
<michagogo|cloud> This specific point seems relevant: https://www.youtube.com/watch?v=-5wpm-gesOY&t=4m18s
<infinity> michagogo|cloud: Nope.  But given that (a) he's English, and (b) it's about timezones, I can only assume it'll be full of colourful language. ;)
<michagogo|cloud> infinity: nah
<infinity> Shame.
<michagogo|cloud> Tom's videos are mostly pretty clean
<Laney> Be glad that it's not about something which has already happened
<michagogo|cloud> He's done a few for Computerphile, but he also does his own videos on his own channel
<michagogo|cloud> Laney: hmm?
<jpds> infinity: Got the OpenSSL exception in. â :)
<infinity> jpds: Snazzy.
<infinity> jpds: Did you have problems explaining why that was necessary, or was it a low drama thing?
<jpds> infinity: A little bit. Apparently libpam-mount doesn't have the exception.
<seb128> infinity, hey, you don't want to do some trusty SRU reviews by any chance? ;-)
<infinity> jpds: Fun.  That should be fixed.
<seb128> infinity, I guess it's a no? :-(
<infinity> seb128: I'll do some, yeah.
<seb128> thanks
<seb128> sorry for being nagging, but we have important fixes in the queue for almost 3 weeks
<infinity> seb128: If this is specifically about gst and webkit, we've been chatting about those internally.
<seb128> those are indeed the oldest one
<seb128> but gst-libav fixes some of the most reported e.u.c issues
<seb128> (totem thumbnailer hitting segfaults on building image for mkv files in nautilus)
<infinity> seb128: Right, will have a poke today.
<seb128> thanks
<infinity> michagogo|cloud: Oh man, I didn't know about the West Bank split timezone.  That's utter madness.
<arges> infinity: is it normal to have versions like "1.2.4-1~ubuntu1" (looking at the gst* stuff for trusty) I see 1.2.4-1 is already in utopic...
<infinity> arges: Normal?  No.  But it sorts correctly, so it's certainly accetable from the archive's POV.
<infinity> acceptable, too.
<arges> infinity: ok yea I understand that... wasn't sure if we normally have versions with ~
<infinity> The security team (and I) would probably argue that ~ubuntu0.14.04 is easier to understand, but meh.
<infinity> arges: We use ~ all over the place.  It literally means "just before the preceding version atom".
<michagogo|cloud> infinity: yeah, there's a related darwin award
<michagogo|cloud> one sec
<infinity> arges: So, -1 is >> -1~ but -0whee is << -1~
<arges> infinity: cool. yup I use it as well.. just didn't want ot get the archive all dirty
<michagogo|cloud> infinity: http://darwinawards.com/darwin/darwin1999-38.html
<infinity> seb128: And when I said "I will look at it", clearly what I meant was "Chris will beat me to it".  But I'll look at more of the queue later to see if we can empty it (or close).
<seb128> infinity, thanks ;-)
<cyphermox> infinity: could you please look at urfkill in proposed? I'd like to fix the version number if possible ;)
<infinity> cyphermox: Which series?
<cyphermox> utopic, sorry
<cyphermox> I should just upload a new version on top without the tilda
<infinity> cyphermox: Erm, kay.  Nothing for me to look at there, there's no queue involved.
<cyphermox> no, there isn't, sorry
<rsalveti> trying to understand why dbus-cpp is still not promoted from proposed, and I see a failure at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt but don't really know what that means
<rsalveti> robru: any idea?
<slangasek> rsalveti: well, there's an soname change; have the reverse-dependencies been rebuilt?
<rsalveti> slangasek: not the entire rev-dep, no
<rsalveti> is that needed for promotion?
<slangasek> right, all the revdeps need to be rebuilt first so the packages can transition together
<infinity> rsalveti: What's needed is that upgrading it doesn't cause those other packages to become uninstallable.
<slangasek> looks like libconnectivity-cpp0 is the only one missing
<slangasek> (based on the last error, at the bottom of the file)
<rsalveti> right, but would libdbus-cpp2 be removed from the archive after the update?
<slangasek> yes
<rsalveti> right, got it
<rsalveti> thought it'd stay until nobody is depending on it anymore
<infinity> It does stay.
<slangasek> mmm?  I thought we dealt with NBS in -proposed these days
<slangasek> did cjwatson hack britney to do something different?
<infinity> Britney assumes it'll be deleted.
<infinity> It's still removed manually.
<rsalveti> right
<infinity> This makes things less painful in some cases.
<infinity> But the transitions should mostly still happen in -proposed due to britney testing as if the binary was removed.
<infinity> Which is good.
<slangasek> ah; yet britney calculates the migrations using the assumption that it will be deleted
 * slangasek nods
<rsalveti> cool, thanks guys
<infinity> Anyhow, just looks like a straight rebuild of connectivity-api is needed.
<infinity> Or whatever that was.
<rsalveti> yeah, checking that
<infinity> rsalveti: In future, the easiest way to read update_output is to search for the source you care about, and then search backwards (so you get the last mention in the file).
<rsalveti> yeah, I saw the failure in there, but thought that having the old package around would already be enough
<infinity> rsalveti: That'll show the autohinter attempts which, in this case, shows:
<infinity> leading: dbus-cpp,media-hub,location-service,platform-api
<infinity>     * i386: libconnectivity-cpp-dev, libconnectivity-cpp0
<infinity> Much less scary than the first hit you see, that tells you half the distro is broken because of dbus-cpp. ;)
<rsalveti> right :-)
<cjwatson> slangasek: right, partly this is because -proposed being a partial suite makes it tremendously painful to do anything else; but fortunately we get constrained into something that's roughly sane.  ish
<bdmurray> infinity: I could add a phased_update_percentage switch if you want
<infinity> bdmurray: Well, for today, I just hacked it for my needs.
<bdmurray> slangasek: what do you think about release apport early? It'll mean slightly less database reapir work
<infinity> bdmurray: But a switch for either initial-phase or just phased-on/off toggle would work.
<bdmurray> slangasek: from trusty-proposed
<infinity> bdmurray: That logic could be reused so that when calling with --security, we also don't phase.
<infinity> bdmurray: (Since I assume we don't phase security, so it doesn't make sense to phase the updates copy)
<bdmurray> infinity: we don't phased when called with security
<infinity> bdmurray: Oh, no?  Kay.
<infinity> bdmurray: That's not how I read the code.
<infinity> bdmurray: The way I read it, it'll phase to -updates, but not -security, which makes less sense.
<infinity> Oh, no.
<infinity> I missed that if.
<bdmurray>                 if (release not in ['lucid', 'precise', 'quantal'] and
<bdmurray>                         not options.security):
<infinity> Yeah.
<infinity> Derp.
<infinity> I missed that cause it was also the series check.
<slangasek> bdmurray: how well exercised is the fix for bug #1282349?  That's the only one that looks intrusive enough to make me worry about early release
<bdmurray> well its been in utopic for a couple of weeks now and the fixed package version doesn't appear in the errors bucket - https://errors.ubuntu.com/bucket/?id=/usr/share/apport/apport-gtk%3AEOFError%3A%3Clambda%3E%3Acollect_info%3Aexc_raise%3Arun%3Athread_collect_info%3Aadd_gdb_info%3Agdb_command%3Awrite%3Aread%3A_read%3A_read_eof%3A_read_exact
<slangasek> bdmurray: ok, +1
<bdmurray> infinity: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/set-phased-update-percentage/+merge/219444
<darkxst> can bijiben and gnome-boxes be dropped from -proposed? they auto-synced but require gtk 3.12
#ubuntu-release 2014-05-14
<infinity> darkxst: Do we not intend to get 3.12 into utopic?
<darkxst> infinity, yes, but will likely be a while
<infinity> darkxst: Sure, but does it do any harm to have those packages sitting there in dep-wait until then?
<darkxst> infinity, it will block tracker transisition won't it?
<infinity> darkxst: Ahh, yeah, that would be a valid reason.
<infinity> darkxst: Alright, I can punt 'em out so you can upload the 3.8/3.10ish versions for the transition.
<infinity> darkxst: Done.
<infinity> darkxst: When you want them back, if the versions haven't revved in Debian by then, we may need to be clever using "copy-package -e <exact_version> -s utopic-proposed --to-suite=utopic-proposed' to resurrect the old ones.
<infinity> Or something.
<infinity> But we'll cross that bridge when we get to it.
<darkxst> infinity, thanks!
<ScottK> Is there a way to review the diff on CI train based syncs that doesn't involve manually downloading old package, new package, and debdiffing them?
<RAOF> ScottK: Only by improving cjwatson's recent improvements to sru-review.
<ScottK> Just tried that.
<ScottK> ./sru-review -b -v  qtdeclarative-opensource-src
<ScottK> ERROR: queue does not have a debdiff
<ScottK> Maybe I need to update.
<ScottK> Nope.  Was already current.
<RAOF> ScottK: Oh, Colin's improvements to sru-review explicitly do not include getting a debdiff.
<RAOF> ScottK: You can pass --no-diff to it and get the bugs, accept/reject options, and bug twiddling stuff, though.
<tjaalton> what's blocking mesa transition from utopic-proposed?
<tjaalton> it was successfully built on all archs
<tjaalton> on monday
<apw> tjaalton, autopkgtest on libgtkada failure by my reading
<tjaalton> ok
<tjaalton> where should I be looking for those?
<apw> tjaalton, i am looking at the info in update_excuses in the proposed-migration output
<tjaalton> ok so some thing run on the servers?
<tjaalton> got it
<apw> looking at that libgtkada log i think (and stressing think here) that there is something gnat-4.9 related going on
<tjaalton> right
<tjaalton> libgtkada2.24.1-dev depends on gnat & gnat-4.6, how clever..
<tjaalton> so should libgtkada2.24.1-dev drop gnat or gnat-4.6?, or migrate to gnat-4.9
<tjaalton> looks like there are others too with similar dependencies.. wonder what the point was, maybe to break on transition
<apw> yeah i guess it would ensure that it no longer works when gnat changes meaning
<tjaalton> doko: any opinion on that ^, should packages depending on "gnat, gnat-4.6" migrate to -4.9?
<doko> tjaalton, migrate to 4.9. this is in progress in Debian. I didn't watch
<tjaalton> okay
<tjaalton> there should be a new gtkada "soon" as of Apr 24, wonder what happened to it
<tjaalton> oh it's in NEW
<tjaalton> can we sync from it? :)
<cjwatson> ScottK: It really needs https://bugs.launchpad.net/launchpad/+bug/851562 to be fixed before we can do any better.
<cjwatson> tjaalton: Can't sync from NEW; NEW hasn't been reviewed for legal-to-distribute, so the files in it aren't published.
<tjaalton> alright
<doko> pitti, did you need further hinting for python-defaults?
<pitti> doko: no; bzr-builddeb got fixed for the changed quilt behaviour (see my #u-devel ping this morning), and I fixed kazoo yesterday
<pitti> doko: the rest was pass or "always failed"
<jamespage> bdmurray, ^^ new ceph point release :-)
#ubuntu-release 2014-05-15
<robru> is there a problem with the bot that syncs packages from ci train silos to the archive? I published some stuff hours ago but it's not in -proposed or even UNAPPROVED
<robru> or rather "not in the upload queue"
<Mirv> I wonder the same as robru, no sight of qtcreator-plugin-go, nuntium webbrowser-app, unity-weappa-qml anywhere
<infinity> Mirv: I assume this bot has logs or something?  This isn't the place to ask about it.
<Mirv> infinity: from what we can see the copy to archives should have happened. I'm not sure if didrocks can check anything more, but cjwatson has sometimes digged logs from somewhere deeper on what has happened regarding the copy when it doesn't appear anywhere (like rejection because no binaries found or such)
<didrocks> Mirv: I'm looking at the logs of the copy machine which was asked to be on snakefruit
<didrocks> so not you or robru have access to those logs (same for launchpad logs)
<infinity> Mirv: If the bot doing the copy had an email address anyone checked...
<Mirv> ok
<didrocks> infinity: well, we can say the same when the copy to launchpad doesn't work
<didrocks> infinity: there is no central logs for them
<didrocks> and I don't keep ranting about it, being quite rare
<infinity> We can go digging in LP logs, but that's not the right answer when a copy fails and WE TELL YOU ABOUT IT, but you don't read it.
<didrocks> infinity: exactly the same in that case
<infinity> didrocks: When copies fail, the uploader is sent an email.
<didrocks> infinity: not when they fail, I'm telling when they go to limbo
<infinity> didrocks: (ie: the bot)
<infinity> didrocks: There's no such place as "limbo".
<didrocks> which already happened more than once, but rarely, as told
<didrocks> infinity: ah, definitively there was
<infinity> didrocks: Either the API call failed (immediate response from the API), or the copy job failed (you get an email with an OOPS)
<didrocks> Mirv: the rsync progress didn't timeout
<didrocks> infinity: not with asynchronous copy
<infinity> didrocks: Yes, really.
<infinity> didrocks: I do this all the time.
<infinity> didrocks: And get emails occasionally.
<didrocks> never saw the OOPSS with the bot's emails
<didrocks> in that case which happened twice in 2 years and half, so acceptable
<didrocks> Mirv: ok, next run should copy it now
<didrocks> Mirv: not sure why --timeout didn't work in that case for rsync to exit
<Mirv> \o/
<cjwatson> didrocks: There's definitely a problem if the bot has a working e-mail address but you aren't getting mails about async copy job failures.  As infinity says, normally the person who requested a copy gets a mail if the async copy fails.
<cjwatson> didrocks: Do I infer correctly from what you said above that the bot has a real mailbox somewhere and occasionally somebody checks it?
<Laney> 2
<didrocks> cjwatson: the CI team did. But I remember twice when apart from the launchpad logs, there was no trace of the copy being rejected (and it wasn't) you had to look at launchpad logs
<cjwatson> didrocks: And that's what I'm saying, *all* such cases should also have been mailed to the copier
<didrocks> cjwatson: but in that case, as told, it's the rsync progress being stuck which caused the issue on snakefruit (even with the --timeout, which is weird)
<cjwatson> didrocks: I remember those cases as well, and I just assumed that there wasn't a real mailbox behind the bot
<cjwatson> didrocks: Ah, I didn't gather that, OK
<cjwatson> didrocks: I only had to look at Launchpad logs in those cases because nobody seemed to know how to find the bot's incoming mail
<didrocks> cjwatson: I remember about the first time, we were at a sprint and we had nothing in the email logs (sitting next to each other at a meeting)
<cjwatson> Hm, that's obviously escaped my memory
<didrocks> but as told, those cases were rare (2 times in 2 years and half), so more than acceptable IMHO
<didrocks> but yeah, the bot has a valid email address. Unfortunately, only the CI team has access to it AFAIK
<cjwatson> Still, I'd like to chase down the cause if possible ...
<cjwatson> didrocks: Would it be possible for the train to declare that it's sponsoring the real human requester in its copy requests?
<cjwatson> if you see what I mean
<infinity> That would be nice.  I'd love to have better blame mechanics than "a bot did it".
<didrocks> cjwatson: yeah, would be completely possible, (I guess the person pushing the publish button)
<didrocks> that was discussed some months ago with stgraber, but he told that some changes on LP side was needed
<cjwatson> He's right, but they're trivial
<didrocks> (at the core sprint in january/february)
<infinity> Hrm.  Why am I still voiced?
<cjwatson> didrocks: So, if the bot used sponsored=, then it's at least possible for LP to know whom to mail
<apw> you have been since release
<didrocks> cjwatson: however, not sure how much the CI team would be willing to work on it apart if this becomes a top priority, they are supposed to move to the airline in a matter of weeks now
<didrocks> (and as you probably know, I can work on it on the train, still, even if I'm moving to other duties)
<infinity> apw: Yeah, I'm obviously just oblivious to little plus signs.
<cjwatson> didrocks: Well, the airline ought to do the same thing, I assume it's not desperately hard to fix in either place?
<cjwatson> (possibly incorrectly ...)
<apw> they have been annyoing me for ages :) as they are yellow for me
<cjwatson> And the Launchpad fix is the same in either place
<didrocks> cjwatson: yeah, I guess the longest is just to get the right info from the jenkins env from the job runner
<didrocks> so if you think the launchpad changes can be done easily, I can work with sil2100 on the train side
<cjwatson> It's just this method: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/packagecopyjob.py#L247
<cjwatson> I'll prepare a fix this morning
<infinity> There.
<didrocks> cjwatson: sponsored would be a launchpad login?
<cjwatson> You pass a Person object
<didrocks> ah ok
<didrocks> good
<sil2100> uh oh?
<bzoltan1> seb128: ping
<seb128> bzoltan1, hey
<didrocks> cjwatson: of course, it doesn't seem that jenkins is sending the user running the job info in its envâ¦ :/
<bzoltan1> seb128: yo man ... I would like to ask your help and time :)
<didrocks> cjwatson: will try to dig a little bit in that whenever I have some time for that
<bzoltan1> seb128: In the https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= the qtcreator-plugin-go package needs an eye
<cjwatson> didrocks: Ah, always a hitch
<bzoltan1> seb128:  this is the QtCreator plugin to support Go and Go-QML app development.
<infinity> Ahh, such patience people have these days.
<cjwatson> didrocks: I'm filing an LP bug for this, so shall I add an ubuntu-ci-services-itself task?
<cjwatson> Or is it cupstream2distro?
<didrocks> cjwatson: yeah, and cupstream2distro as well
<didrocks> one for the airline, one for the train
<cjwatson> Both?  OK.
<didrocks> thanks :)
<seb128> bzoltan1, let me have a look
<bzoltan1> seb128: thanks
<seb128> yw!
<cjwatson> didrocks: The other bonus is that the sponsored person will be tracked and show up in the LP UI, so it'll be easy to see who published something
<cjwatson> (well, in theory, I think that works ...)
<infinity> Not sure how true that is for copies.
<infinity> For example, https://launchpad.net/ubuntu/+source/systemd-ui/3-2 was copied by ~adconrad, sponsored for ~logan, but neither of us shows up on the page.
<cjwatson> ubuntu -> ubuntu/trusty
<cjwatson> and I think it shows up then
<cjwatson> err, utopic
<infinity> Ahh, so it does.
<infinity> I hate that page.
<cjwatson> probably in the publishing history too
<didrocks> cjwatson: yeah, so, there is a plugin (of course)â¦ However, of course, it will say "Didier Roche" for instance in this env var. So, people.find(text=) can find it, not sure about duplication thenâ¦
<cjwatson> so unnecessarily hard to find, but it's there
<seb128> those ubuntu ubuntu/<series> difference are confusing
<infinity> Or, rather, I hate that there are two pages with differing but similar info, and one has a crap layout. :P
<seb128> it's annoying that the serie-specific one doesn't have the diffs (especially that it's the one in the -changes emails)
<didrocks> I guess an additional field in case there are multiple matches (and so, we fail by default)â¦
<cjwatson> mm, I guess this requires Jenkins hacking to pass through the Launchpad user name then
<cjwatson> Searching on a person's full name isn't sensible :)
<cjwatson> didrocks: https://bugs.launchpad.net/launchpad/+bug/1319704
<didrocks> cjwatson: thanks, will see if sil2100 wants to be tutored on that one
<didrocks> cjwatson: yeah, jenkins hackingâ¦ we can add a mandatory field as a first step, but needs people to be aware of it
<infinity> Well, all the Jenkins instances have been switch to SSO, right?  So it should, in theory, not be crazy hard to determine the LP ID of the requestor and pass it through.
<infinity> (In theory... I realise this is Jenkins, and nothing about that screams "easy")
<cjwatson> didrocks: Yeah, certainly shouldn't need an extra user-visible field since it (in theory) has that information
<didrocks> infinity: right, the question is how much time we should investigate into this knowing that: 1. I'm transitioning to other duties 2. the CI team is supposed to deliver something equivalent to CI Train in less than a month
<didrocks> so not sure if the jenkins part needs to be heavily invested in
<infinity> Yeah, that's fair.
<cjwatson> If the result ends up being that we transition to the airline before this is fixed and wontfix it in the train, I don't mind
<cjwatson> Presumably it's a trade-off against potential time spent investigating confusion before then
<cjwatson> didrocks: I think your estimate of number of times this has come up is a bit low, FWIW - there have been a few times when you weren't around
<didrocks> cjwatson: it would have been good to have it raised a little bit more at the CI (even daily-release) UDS sessions so that I prioritized it or on the ML
<didrocks> anyway, I'll see what I can do
<cjwatson> Well, can't prioritise *everything* :)
<didrocks> the real issue is only this jenkins -> cu2d part
<cjwatson> Thanks
<sil2100> cjwatson, infinity: hi guys! Can I just quickly ask you for something? We have released a new unity8 yesterday and the faux package needs bumping for it to move out of -proposed :)
<cjwatson> sil2100: Laney said in #ubuntu-ci-eng that he'd already done so
<sil2100> Ah :) Thanks Laney! /me was in a hangout
<didrocks> cjwatson: ok, I've done the support for it in cu2d. (was able to find in some way through jenkins what should be the launchpad username). However, will need testing and sil2100 to convince webops to install that plugin
<sil2100> didrocks: the RT is filled, now I poke webops
<didrocks> in addition, there will be an additional field, like if I sponsor for sil2100 for instance
<didrocks> so that people can collect names, will make MOTU approval and tracking easier
<cjwatson> didrocks: OK, but you can only pass one sponsored person to Launchpad
<didrocks> right
<didrocks> that sounds good to me, one packager is supposed to look at the silo
<cjwatson> So I assume you're resolving to the most relevant person
<cjwatson> I've filed an MP for the Launchpad part, anyhow
<didrocks> yeah
<didrocks> sil2100: changes in trunk
<didrocks> don't deploy before the plugin is there
<sil2100> didrocks: \o/ thanks! No answer from webops, they seem to be busy with something else right now
<didrocks> (it will need the jenkins template to be deployed as well for the record)
<didrocks> sil2100: well, actually, we can deploy, but the field will then be mandatory
<cjwatson> sil2100: There's no EMEA webops vanguard coverage this week
<mlankhorst> can any archive admin remove xorg-lts-transitional from utopic?
<infinity> mlankhorst: Sure.
<Saviq> hey all, is there anything we could do in unity8 to lift the need for manual approval of each unity8 migration?
<cjwatson> Saviq: I've been thinking about it, but it's tricky
<cjwatson> (other than "port unity8 to all architectures", which is mostly blocked on platform-api ...)
<cjwatson> Saviq: I do still consider this my problem to fix though, since our current solution is crap
<cjwatson> I might be able to come up with something that at least doesn't put the crap quite so much on the surface
<Saviq> cjwatson, I thought it was possible to have a package only on a certain set of architectures, would that not be good enough for now?
<cjwatson> unity8 *is* only on a certain set of architectures, but the problem is that indicator-network depends on it and indicator-network has a festering mess of reverse-dependencies which are hard to disentangle
<cjwatson> The alternative to this is a hideous pile of architecture limitations everywhere
<cjwatson> (manually)
<Saviq> heh :|
<cjwatson> So we pretend that unity8 is actually available on all architectures to make the problem go away at least somewhat gracefully
<cjwatson> And this is the result
<Saviq> cjwatson, ok, please let me know if we can do anything to help
<xnox> make src:unity8 build an empty unity8 package on unsupported arches?!
<cjwatson> xnox: I think I prefer fixing proposed-migration.
<cjwatson> It actually shouldn't be *too* hard, as it has the existing Packages files as input
<cjwatson> Saviq: OK, I believe it's fixed now - shouldn't require manual bumps on unity8 uploads any more
<cjwatson> Just took me a while to figure out which angle to approach it from, but easy enough in the end
<Saviq> cjwatson, awesome, thanks!
<infinity> cjwatson: Do we not want to use that substitution for all the entries in FauxPackages?
<cjwatson> Probably, it was just less urgent for the others
<cjwatson> Be my guest if you're feeling keen :)
<infinity> Oh, I guess some don't appear to really have the issue.
<cjwatson> Indeed
<infinity> Like wine seems to not care about the version.
<infinity> Or maybe it only doesn't care about the 1.4 version. :P
 * infinity shrugs.
<infinity> I'll care if it causes an issue later.
<infinity> I'm sort of a zombie right now.
<bzoltan1> seb128: do you have any news about the qtcreator-plugin-go?
<seb128> bzoltan1, no, still on my list
<bzoltan1> seb128: OK
<robru> hey guys, another poke about that snakefruit rsync thing. seems to be off again, can somebody take a look at it?
<bdmurray> slangasek: Could you merge this? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/set-phased-update-percentage/+merge/219444
<cjwatson> robru: it *seems* current; incoming/ has one file (packagelist_rsync_landing-014-utopic) timestamped less than a minute ago
<cjwatson> I can only guess here though
<infinity> cjwatson: I assumed impatience, based on "New source: golang-udm" appearing right after he asked. :)
<infinity> Oh, except that's not a sync.
<cjwatson> he asked about it on #ubuntu-ci-eng 15 minutes later too, so I'm guessing not that one
<cjwatson> I don't know how often this is supposed to run, which syncs are expected to arrive and are missing, nor where the logs are, though, so flying pretty blind :)
<cjwatson> didrocks just said this morning that rsync was getting stuck rather than honouring its --timeout, so I'm guessing that he fixed it by killing a stale rsync process
<cjwatson> but there are no such on snakefruit right now - so hopefully it timed out by itself and is resolved now
<robru> cjwatson, nah -- http://people.canonical.com/~rbpark/citrain/ I've got 9 packages in "no known space and time", published as early as 2 hours ago. typically I see these things get into -proposed within minutes of publishing, it's very strange and bad for it to be this stuck. something is definitely wrong
<cjwatson> robru: I think it needs somebody who knows more about how our end of it is supposed to work than I do, I'm afraid
<robru> cjwatson, do you have any idea who? this issue is extremely opaque to me
<cjwatson> robru: didrocks
<cjwatson> (I'm afraid)
<cjwatson> robru: FWIW there's no mention of address-book-app in the relevant LP logs, so it's not that the copy failed, at least not in that case
<cjwatson> (or rather no relevant mention - there are some MPs that show up in the same logs)
<robru> cjwatson, yeah, that's what I'm trying to get at. it's not that the copy failed... it's that whatever component is responsible for the copying isn't doing them
<cjwatson> hmm
<cjwatson> ./incoming/packagelist_rsync_landing-001-utopic:ci-train-ppa-service/landing-001        Release utopic  Proposed        utopic  address-book-app        0.2+14.10.20140514-0ubuntu1     0.2+14.10.20140512-0ubuntu1     mathieu-tl
<robru> cjwatson, that's one of the ones I'm expecting to see uploaded...
<cjwatson> oh, it's a regression from didrocks' patch earlier today
<cjwatson> 2014-05-15 20:21:23,967 INFO Found packagelist_rsync_landing-017-utopic
<cjwatson> Traceback (most recent call last):
<cjwatson>   File "/home/ubuntu-archive/cu2d/cupstream2distro//copy2distro", line 51, in <module>
<cjwatson>     sponsored = launchpadmanager.get_person(sponsored_name)
<cjwatson> AttributeError: 'module' object has no attribute 'get_person'
<slangasek> bdmurray: merged
<cjwatson>  looks like it's fixed in cupstream2distro trunk, so I've pulled
<robru> cjwatson, ugh, any way to just revert that until didrocks gets back to fix it? literally all citrain publishing are blocked on this
<cjwatson> like I say, I pulled what should've been the fix
<cjwatson> give it a few minutes for the next run
<robru> cjwatson, ok thanks
<cjwatson> (my son demands attention)
<cjwatson> robru: looks good now
<robru> cjwatson, thanks
<bdmurray> arges: Does Tuesday work for you for SRU duty?
<bdmurray> arges: if so maybe you could update https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
#ubuntu-release 2014-05-16
<didrocks> infinity: not sure if you noticed, but: https://lists.canonical.com/archives/utopic-changes/2014-May/002158.html
<didrocks> so now, you have attribution to the guy pushing the "publish" button or for who the packaging/integration ack was sponsored for
<infinity> didrocks: \o/
<seb128> infinity, you see that as an improvement?
<infinity> seb128: How is it not?  Having thousands of uploads attributed to a bot that can't be harassed when there are problems is worthless.
<xnox> seb128: yes, it used to be "robot uploads" not it's "Timo uploaded, sponsored by robot"
<xnox> s/not/now/
<seb128> infinity, because seeing the landing from today have all the wrong owners
<seb128> they have the CI team guy who did push buttons
<seb128> not the people who put the landing/tested it/asked it to land
<infinity> The "uploader" is the responsible person for an upload.
<seb128> it's stealing credit and pointing the blame to the wrong person
<infinity> They shouldn't push the button if they don't want the responsibility.
<xnox> seb128: well, infinity get's a person to chase down and receive reject emails from the queue =)
<infinity> This is no different than sponsoring patches, which you do a lot.
<seb128> I often keep the name in the changelog
<seb128> and design with my key
<seb128> I don't rename the changelog to steal credit
<seb128> you have changed-by and signed-by
<infinity> There's no "stealing credit" here.
<seb128> there is
<seb128> when I sponsor something, the -changes email has the name of the person who did the work/own the changelog entry
<seb128> I'm only the signer
<seb128> it would make more sense to use the name of who is listed as "lander" for the corresponding line in the CI table
<infinity> Okay, so that's a process fail in the CI stuff.  The person requesting the upload should actually relate to the changes.
<seb128> stgraber, ^ I've been told you are the one against doing that, why?
<didrocks> infinity: but they are not the one acking the pakaging change though
<cjwatson> seb128: didrocks had been planning to have it attribute to the correct person; I don't know why that isn't happening
<didrocks> packaging*
<cjwatson> (Or I misunderstood)
<didrocks> cjwatson: with the discussion we had with stgraber, it was clear it needed to be the guy publishing the package
<didrocks> not the lander
<didrocks> as they took responsability with the packaging ack
<didrocks> and they are the ones on the road to get motu/more packaging upload access
<didrocks> so, I really don't care
<didrocks> just be in agreement
<cjwatson> I don't feel that strongly either way; having any contact at all is better than none
<infinity> Anyone is better than the bot, as long as there's a blame trail.
<didrocks> but don't turn around on criterias please
<infinity> But it would be nice if the blame was going to an appropriate place, whatever that place is.
<infinity> I'm in no position to say, really, who that should be.
<cjwatson> (criteria; the singular is criterion)
<cjwatson> infinity: right, that's exactly my position
<didrocks> (cjwatson: ok, at least that discussion will teach me that :))
<xnox> infinity: seb128: -changes emails are wrong for all syncs, no?!
<xnox> infinity: seb128: https://launchpad.net/ubuntu/utopic/+source/qtcreator-plugin-ubuntu/3.0.1+14.10.20140516-0ubuntu1 clearly has Timo as uploader, sponsored by robot, copied from -proposed -> -release by robot.
<seb128> xnox, no, autosync don't end up on -changes, and syncpackage has a -s argument
<didrocks> soâ¦ I just want you guys to come to a conclusion, it's either:
<didrocks> - the guy pushing the publish button
<didrocks> - the first lander listed for a request
<didrocks> I don't care either way, just take a decision, I'll implement the change if it's the second
<seb128> didrocks, thanks, and sorry for the discussion
<didrocks> I just don't want that to be turn in and back
<xnox> seb128: the -s argument was used here, as far as i can tell.
<didrocks> (both are easily to switch to now)
<seb128> xnox, right, it's just that stgraber requested that the name to be used is the one who push the publish button
<seb128> not to lander/owner of the landing
<xnox> didrocks: it should be the person who has upload rights, thus it should be the person who pushes the publish button.
<xnox> didrocks: this is me talking as an DMB.
<seb128> ok, wfm
<didrocks> xnox: well, you still sponsor for someone elseâ¦ like we want sil2100 to get some credits of his reviewing and packaging work for instance
<seb128> I'm just going to tell the CI team to stop pushing the publish button for me
<seb128> :p
<didrocks> like when seb128 is sponsoring any community member
<seb128> (some of them are eager to do that)
<cjwatson> it's better to get to the point where people are doing that themselves anyway
<infinity> seb128: Arguably, the button should be pushed by non-CI people anyway.
<seb128> yeah, it's just that some CI lander jump on anything "ready to publish"
<infinity> And if we start coming to CI people and blaming them for uploads, they'll learn that. :P
<cjwatson> I had the general understanding that having a team of people whose job is to push buttons on things isn't ideal :)
<seb128> right
<seb128> well, the process works fine
<cjwatson> (yeah, I know it's rather more than that ...)
<infinity> Sponsors should always be prepared to be responsible for 100% of the changes they upload.
<seb128> as said, just some people are eager to click on anything
<xnox> didrocks: so, in the changelog i see who made the changes, robot did the upload, the reviewer/publisher (person with upload rights) is the one pushing the button. so i have all the information as to who did what, no?!
<didrocks> xnox: not about the guy taking the test responsability
<didrocks> who is the lander
<seb128> xnox, well, I would like to be the one owning/be pinged for things I land
<xnox> didrocks: true, but that's a ci-train type of role, for which there is no mapping in an soyuz upload record.
<seb128> even if e.g sil2100 pressed publish for me
<seb128> because I was not around and they wanted to get things moving
<xnox> didrocks: but i presume the push-the-button person to know who the lander was.
<didrocks> seb128: they can push the button, but attribute it to you, I added a field for that
<xnox> didrocks: or add a changelog entry "Lander: mark"
<didrocks> xnox: yeah, that's recorded
<sil2100> Indeed o/
<didrocks> not in the changelog
<seb128> didrocks, ok, seemed easier to take the lander in my view, but I guess that works too ;-)
<xnox> didrocks: yeah, if it's recorded anywhere, that's sufficient.
<xnox> didrocks: no need to duplicate it anywhere else.
<didrocks> anyway, I don't want to jump to that discussion, just be in agreement with some plan, I'll do whatever changes are needed if you feel so
<xnox> didrocks: everything looks good at the moment, no changes needed, let's gather more feedback.
<seb128> +1
<cjwatson> xnox: (can't go in the changelog because the packages are already built at the time somebody pushes the publish button)
<cjwatson> didrocks: Oh, I forgot to send e-mail - I deployed r594 of cupstream2distro last night (was r592) because the citrain publisher was crashing due to the lack of the get_person implementation that you did in r594
<didrocks> cjwatson: oh, I didn't pull it? sorry, I thought I did
<didrocks> cjwatson: yeah, I stupidely forgot to save the file during the checkingâ¦
<cjwatson> didrocks: Is there a way to see the logs other than just running it by hand (which is what I did in the end)?  The crontab says MAILTO=ubuntu-unity@lists.launchpad.net, but https://lists.launchpad.net/ubuntu-unity/ is empty
<cjwatson> Maybe I'm looking in the wrong place ...
<didrocks> cjwatson: unfortunately, I never took the time to look at why it was never published to the ML list
<didrocks> cjwatson: but anyway, should be in somewhere more central now than ubuntu-unity
<didrocks> oh right, I forgot to pull on the publisher-side :/
<cjwatson> We could just do what proposed-migration does: write out timestamped log files visible on http://people.canonical.com/~ubuntu-archive/somewhere
<didrocks> cjwatson: yeah, sounds sane, I can add that to my backlog and do it
<cjwatson> great, thanks
<didrocks> thanks for pulling yesterday :)
<xnox> hm, is britney not running, even though there are ADT test results, because there is no archive movements at the moment?
<cjwatson> That would probably be usual, but I can run it manually if that would help
<xnox> can we just cron britney to e.g. run at least every hour, if it hasn't otherwise run?
<xnox> cjwatson: please trigger it, i think sysvinit should migrate.
<cjwatson> Maybe but I'm not going to engage in major refactoring just before going on leave for the afternoon :)
<cjwatson> running
<xnox> =)))))
<cjwatson> Apparently not quite; linux and mysql-5.6 still running
<cjwatson> Hopefully close though.  I'll watch those and re-run when they're done
<xnox> cjwatson: hm, mysql-5.6 should be in "always-failed" state now? even though it's currently-running, because it is "always-failed" the outcome of the currently running test is irrelevant.
<xnox> linux however, has started to pass, so we'd need to wait for that one.
<cjwatson> For something like sysvinit I'd really rather let the tools get to the point where they're happy
<xnox> true.
<cjwatson> Opportunity to test my livefs building setup against -proposed ...
<infinity> xnox: cronning britney isn't the answer, triggering it is, it's on my TODO.
<infinity> xnox: As for ignoring "always failed" while it's still running, that's just you being impatient.  If it started succeeding, we wouldn't ignore it anymore, right? :)
<cjwatson> Neither the linux nor the mysql-5.6 test has moved in a while ...
<cjwatson> pitti: ^- can you tell if those two are actually doing anything?
<pitti> checking
<pitti> linux is at copying the source tree (which is just effing big); there's visible progress on albali
<pitti> albali's disks aren't the fastest on earth; but linux only started 2 hours 10 mins ago, the previous one took 2:55
<cjwatson> OK
<cjwatson> As long as it's moving
<pitti> mysql> yeah, we really need live output; it's quite tricky to do through qemu, but it's on my list
<pitti> logging into the VM
<pitti> cjwatson: and there's also visible progress on mysql
<arges> bdmurray: sure I'll update the wiki.
<ogra_> stgraber, help ! ... do you know where cdimage sets a lock file ? i get an error for build_image_set_locked when trying to build a touch image ... looks like some stale file from failed builds tonight
<ogra_> or infinity ^^^
<doko> cjwatson, infinity: do you know why fonts-indic is not in Ubuntu?
<stgraber> ogra_: there are a few, the most annoying one is on the actual builder and requires IS to clean it up, let me take a quick look
<ogra_> thanks
<ogra_> looks like the builders finished fine
<ogra_> ubuntu-touch-i386 on cardamom.buildd finished at 2014-05-16 13:26:48 (success)
<ogra_> ubuntu-touch-armhf on kishi00.buildd finished at 2014-05-16 13:58:32 (success)
<ogra_> Traceback (most recent call last):
<ogra_> ,,,,
<ogra_>   File "/usr/lib/python2.7/xmlrpclib.py", line 793, in close
<ogra_>     raise Fault(**self._stack[0])
<ogra_> Fault: <Fault -32601: 'Server error. Requested method qatracker.get_access not specified.'>
<ogra_> thats what i got
<ogra_> oh, wait ... you too :P
 * ogra_ sees the CC list
<stgraber> right, that's the qatracker causing a build failure
<stgraber> looks like the tracker database is down or something...
 * stgraber investigates
<Laney> doko: ttf-indic-fonts?
<ogra_> stgraber, well, we had all builds failing tonight (and throughout the day) i assume thats some fallout
<ogra_> (all arches, all flavours)
<stgraber> wtf, all drupal plugins got disabled somehow
<ogra_> lovely
<stgraber> I suspect IS tried to apply some updates without contacting me and blew up the drupal setup
<doko> Laney, http://packages.qa.debian.org/t/ttf-indic-fonts.html is a dummy package, and http://packages.qa.debian.org/f/fonts-indic.html is not in Ubuntu
<ogra_> i started the build via the qa tracker ...
<ogra_> just FYI
<ogra_> back then it worked fine
<stgraber> so the tracker is sort of back online (modules re-enabled but read-only fs so it's pretty ugly)
<ogra_> stgraber, think a build would survive ?
 * ogra_ doesnt want to start one if it will fail anyway
<stgraber> ogra_: the API seems fine, so probably worth a shot, I'm working IS to fix whatever broke
<ogra_> ok, starting a touch build (again)
<ogra_> hmm, i wonder where that 14:29 build failure came from ...
<ogra_> i surely started my build later
 * ogra_ guesses the ttracker had some state cached or so
<stgraber> the tracker should now be back to its usual state, a code+DB security upgrade from IS + a broken apparmor profile caused quite a bit of trouble but it looks like we've figured it all out now
<ogra_> stgraber, thanks a lot
<ogra_> build worked btw
<rtg> infinity, please guide new utopic 3.15 kernel packages to the appropriate place in main when they are done building.
<Laney> Oops I should have had an arch restriction
<xnox> i need help with seeds. I'm failing to figure out why ubuntu-touch armhf has libmirplatformgraphics-mesa & libmirclientplatform-mesa installed, when libmirclientplatform-android & libmirplatformgraphics-android are seeded
<xnox> and the -android once should be sufficient.
<slangasek> xnox: possibly a question of dependency traversal ordering
<slangasek> what depends on libmirclientplatform-mesa, and is it something that's listed in the seed earlier than libmirclientplatform-android?
<ogra_> xnox, iirc tasks resolve deps in reverse order to apt-get ...
<ogra_> we had such an issue with java a while ago
<xnox> slangasek: yes. shall i move libmir*-mesa to the top or to the bottom of the seed then?
<slangasek> xnox: you mean -android?
<ogra_> if you switch the | dep in the package it will obey to the seed
<xnox> slangasek: yes.
<slangasek> xnox: top
<xnox> slangasek: ack.
<slangasek> (or at least, "above the thing whose dep order you need to override")
<xnox> slangasek: next we have on libqt5gui5:armhf depending on "libegl1-mesa (>= 7.8.1) | libegl1-x11"
<ogra_> xnox, please be very very careful what changes you make right now we are all working after hours to get a wroking image with build 34 again after two days of total breakage
<xnox> slangasek: as far as i can see libegl1-x11 has only one provider, which is libegl1-mesa -> any clue as to why we have such a dep on a core qt library?
<xnox> it pulls in llvm3.4 on to touch images =)
<slangasek> xnox: we have that dep because that's what the shlibdeps of libegl1 say?
<slangasek> is there another package installed as part of the image that should satisfy the dep without pulling in the mesa version?
<slangasek> IIRC the trick here was that the alternative provider was part of the device image, not the rootfs
<xnox> slangasek: is libhybris a reasonable provider of libgl1 & libegl1-x11 =)?
 * xnox will build a test dummy-package and check if the image is still functional.
 * ogra_ bets a monthly loan that if you make "libmirclientplatform-mesa | libmirclientplatform-android" to be  "libmirclientplatform-android | libmirclientplatform-mesa" in libmirclient the mesa deps will be gone from the touch image ... 
<xnox> ogra_: i don't want to flip that. we have far more mesa based mir installations then android.
<ogra_> we had this issue before ... more than once
<slangasek> ogra_: yes, and then you would break the other unity8 image instead
<xnox> ogra_: bubbling up -android in the seed is the cleanest way, instead of playing a whack-a-mole.
<ogra_> iirc for the case where you cant flip there are/were hacks in livecd-rootfs
<slangasek> the right way to specify which provider of a dep you want is to explicitly seed it first
<ogra_> hmm, all gone from the code nowadays ... there is a way to specify extra packages per flavour
<ogra_> i know we used that for a bunch of arm builds
<slangasek> livecd-rootfs is the wrong place to specify that for official builds; it belongs in the seed
<ogra_> ah, right it was add_package() ... in live-build/auto/config
<ogra_> right, as i said, hacks :)
<infinity> doko: Looks like it was blacklisted long ago.  Probably not required anymore.  I'll go through the blacklisted fonts and see what's bogus.
<arges> stgraber: infinity : hey i'm trying to review open-vm-tools-hwe , bug 1275656. it introduces the new package for precise and a patch for trusty that transitions the package out. should i sponsor this for trusty even though it will be copied to utopic as well?
<infinity> doko: Oh.  Those blacklists aren't bogus.  We're carrying a hefty delta to the source package that used to build those fonts (ttf-indic-fonts) that includes udebs.  Someone needs to put the time into porting that over to all the split packages.
<infinity> arges: trusty is where it's needed.  That delta can be dropped in utopic again.
<arges> infinity: so should i make a note of that somewhere? or just wait until utopic gets synced over
<infinity> arges: The idea is that if they're giving people a fancy HWE version in precise, precise+trusty -> trusty upgrades need to work.
<arges> or merged over rather
<arges> infinity: yup i checked this, but then I just realized that utopic/trusty were at the same version and didn't want to mess up utopic
<infinity> arges: It can be synced to utopic.  There's no harm in the cruft being there.  But the end result should be a utopic version that's higher and has that transitional package removed again.
<arges> infinity: ok i'll note that in the bug. thanks
<cjwatson> doko: yeah, exactly what infinity said - I tried once or twice to port the delta over but it was a multi-hour job
<bdmurray> slangasek: could you have a look at apport in the trusty -proposed queue?
<slangasek> bdmurray: looking
<bdmurray> thanks
#ubuntu-release 2015-05-11
<cjwatson> re-enabled Haskell stuff in auto-sync - we're far enough up the stack now that stuff should generally fail rather than building against old ABIs, and it's time-consuming to babysit
<jamespage> arges, we're pretty much done on the kilo release verification
<jamespage> just fixing one issue with designate due to older distro builder kernel versions
<jamespage> arges, bug 1451691
<ubot93> bug 1451691 in designate (Ubuntu) "linux <3.9 doesn't support socket option SO_REUSEPORT" [High,In progress] https://launchpad.net/bugs/1451691
#ubuntu-release 2015-05-12
<tjaalton> is everyone on ~ubuntu-archive able to ack packages from NEW?
<apw> they have the priviledge (afaik) but they would be expected to only ack thinks they feel confident reviewing
<tjaalton> ok
<jamespage> arges, hey the kilo stable update for vivid is ready to go apart from https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1451691
<ubot93> Launchpad bug 1451691 in designate (Ubuntu) "linux <3.9 doesn't support socket option SO_REUSEPORT" [High,In progress]
<jamespage> I'd really like to get it out today if possible
<arges> jamespage: k i'll take a look
<arges> jamespage: did you verify bug 1381450 ?
<ubot93> bug 1381450 in libnetfilter-queue (Ubuntu) "[MIR] conntrack, libnetfilter-queue, libnetfilter-cttimeout, libnetfilter-cthelper" [Medium,Fix committed] https://launchpad.net/bugs/1381450
<jamespage> arges, lemme check
<jamespage> arges, yeah - that's good as well
<arges> jamespage: cool.
<jamespage> arges, urh - I just noticed that build failure on trove
<arges> jamespage: yikes, did you just re-upload/rebuild?
<jamespage> arges, i think it was a racey test - I hit rebuild to check
<jamespage> arges, tbh we can hold back on designate and trove if you want
<jamespage> arges, https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1451691 will fixup the ftbfs for designate
<ubot93> Launchpad bug 1451691 in designate (Ubuntu) "linux <3.9 doesn't support socket option SO_REUSEPORT" [High,In progress]
<arges> jamespage: ok. plus trove has only been in -proposed for 4 days.
<arges> jamespage: can you check through bug 1449744. openstack-trove/designate were skipped
<ubot93> bug 1449744 in openstack-trove (Ubuntu Vivid) "[SRU] OpenStack Kilo 2015.1 release" [Undecided,Fix committed] https://launchpad.net/bugs/1449744
<arges> jamespage: can you ensure manila, neutron-vpnaas are released in wily too?
<jamespage> arges, yes - I'll get zul todo whatever he did with the others
<sil2100> Hello release team! I temporarily disabled the image importer, I want to release a new ubuntu-touch image
#ubuntu-release 2015-05-13
<tjaalton> infinity: meh, the rename script had a special case to just continue if there is no unrenamed orig tarball to rename
<infinity> How has thierry-ibm not been k-lined/g-lined yet?
<infinity> thierry-ibm: Fix your internets.
<Ukikie> /mode +b *!*@195.154.164.92$##fix_your_connection
<tjaalton> infinity: xorg-server-lts-vivid reuploaded, with a real tarball
<infinity> tjaalton: Is it a real good one?
<infinity> tjaalton: Accepted.
<tjaalton> yay
<tjaalton> I'll get the drivers uploaded today
<tjaalton> infinity: ^ that leaves the metapackage
<tjaalton> though I could push that too now
<tjaalton> yeah
<cyphermox> arges: could you please review SRU bug 1435663, see if we can release it? I'd have another SRU for grub to do for trusty
<ubot93> bug 1435663 in partman-efi (Ubuntu Utopic) "arm64/efi support" [Undecided,Fix committed] https://launchpad.net/bugs/1435663
<arges> cyphermox: yea let me take a look
<arges> cyphermox: ok done
<cyphermox> arges: thanks!
<lamont> dear release team: simplestreams interests me greatly
<lamont> arges: ^??
<arges> lamont: sure i'll take a look
<lamont> ta
<cyphermox> arges: hey, sorry to be picking at you, but would you have time to also review grub2 ^^ from the trusty queue? :)
<arges> lamont: versioning is messed up in the patch. should be 0.1.0~bzr341-0ubuntu2.1, plus looks like it was patched against ubuntu1 as it removed another patch
<arges> lamont: did you or scott upload?
<lamont> smoser: ^^
<arges> also assuming the simplestreams fix will be uploaded for U/V as well
<lamont> arges: wily and vivid have it
<lamont> U? *shrug*
<arges> lamont: ok i'll mark those fixed released in the bug then
<lamont> [11:52:32] <smoser> Subject: [ubuntu/vivid-proposed] simplestreams 0.1.0~bzr354-0ubuntu1.15.04 (Waiting for approval)
<lamont> there's another one waiting for you
<arges> ok
<arges> cyphermox: ok grub2 done
<cyphermox> muchas gracias.
<arges> smoser: also wonder why vivid has version string 0.1.0~bzr354-0ubuntu1.15.04 instead of just ubuntu1.1? (either way works, one is just longer to type)
<arges> for simplestreams
<smoser> arges, no reason. i'm fine to re-upload.
<smoser> i just followed https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<smoser> yeah, you're right. that was not necessary
<arges> smoser: ah i see cause its in utopic/vivid I guess if you're patching both then I see how that makes sense
<smoser> you want to reject and me fix versions
<arges> smoser: trusty was already rejected, so you can re-up that whenever.
<smoser> rejected due to funny version?
<smoser> yeah. ok. thanks.
<arges> smoser: no. it looked like trusty was patched against -0ubuntu1 instead of -0ubuntu2
<arges> as it removed a patch and changelog entry
<arges> smoser: for vivid its your call. if you are fixing it in utopic/vivid then leave it as is, and then you can upload 0.1.0~bzr354-0ubuntu1.14.10.1 whenever
<arges> (for utopic that is)
<smoser> arges, yeah. thats my fault. i just assumed bzr importer was right.
<smoser> i think ishould leave it as is.
<smoser> to allow for utopic upload
<smoser> although i do not plan on it.
<arges> smoser: agree.
<smoser> i will fix trusty. thank you for catching that.
<arges> its my job : )
<smoser> i just assumed that lp:ubuntu/trusty/simplestreams got updated, but it did not.
<smoser> arges, re-uploaded. simplestreams_0.1.0~bzr341-0ubuntu2.1
<arges> smoser: ok reviewing
<tjaalton> infinity: the rest of the lts-vivid stack is now uploaded, x-x-v-qxl-l-v is with the proper tarball, though main one is native
#ubuntu-release 2015-05-14
<jamespage> if there are any sru team members around, i'd like to get the juno stable update out (https://bugs.launchpad.net/bugs/1443429) today prior to next weeks openstack summit if possible
<ubot93> Launchpad bug 1443429 in nova (Ubuntu) " [SRU] juno 2014.2.3 point release" [Undecided,New]
<jamespage> please :-)
<bdmurray> ScottK: Are you not using sru-review which would include the package name and version in the SRU comment? https://bugs.launchpad.net/ubuntu/+source/libqapt/+bug/1448929/comments/4
<ubot93> Launchpad bug 1448929 in libqapt (Ubuntu Wily) "fix apt states" [Undecided,New]
<ScottK> bdmurray: I used sru-accept.
<bdmurray> Right and if you used sru-review it would automatically add extra arguments when calling sru-accept that would make the bug comment more informative.
<rbasak> bdmurray: thank you for processing bug 1448533. This also needs copying forward to Wily now. Is this something I'm supposed to do?
<ubot93> bug 1448533 in percona-xtradb-cluster-5.6 (Ubuntu) "Packaging bug prevents install of PXC 5.6" [High,In progress] https://launchpad.net/bugs/1448533
<bdmurray> rbasak: I'm not an AA so actually don't know.
<rbasak> slangasek: ^^ halp. Is "copy-package --dry-run -b --from-suite vivid-updates --to-suite wily-proposed percona-xtradb-cluster-5.6" what I want? I think I'm allowed to do it?
<slangasek> rbasak: without the --dry-run probably?  but yes, you can do that, it's ok-ish right now
<bdmurray> Should we put that on the SRU page?
<rbasak> Done, thanks!
<slangasek> bdmurray: probably not, it's only allowed during the first weeks of the cycle and I don't really want to encourage it
 * rbasak looks guilty
<bdmurray> rbasak: I think its more a result of W opening a little late and wanting to get SRUs in quickly
<rbasak> bdmurray: yeah at the time I uploaded that SRU Wily wasn't yet open (or named)
 * slangasek nods
<bdmurray> cjwatson: A lot of utopic tests show up as "Test in progress" but they don't really seem to be - http://people.canonical.com/~ubuntu-archive/proposed-migration/utopic/update_excuses.html. For example, cinder, account-plugins.
<cjwatson> bdmurray: Usually jibel or pitti are best at investigating that kind of thing
<bdmurray> cjwatson: okay, for future reference do you know what update-excuses is connecting to?
<cjwatson> bdmurray: adt-britney talks to tachash.ubuntu-ci; I don't know exactly where things go behind that
<cjwatson> I believe it was recently moved to a juju-deployed thing
<cjwatson> but usually things stuck in "test in progress" mean that something in the stack is confused about which versions it's testing, or similar
<cjwatson> (it's also possible I'm wrong and that responsibility for this has transitioned to CI; and it's furthermore possible that the transition itself is the cause of problems.  I haven't been paying close attention to that
<cjwatson> )
#ubuntu-release 2015-05-15
<slangasek> cjwatson, bdmurray: yes, AIUI the CI team has migrated proposed-migration into a cloudy thing, so it could be a byproduct of the migration
<cyphermox> arges: do you have time to review ? ^ :)
<arges> cyphermox: assuming network-manager
<cyphermox> yes, please
<arges> cyphermox: oh its a sync
<arges> cyphermox: done
<cyphermox> ta
<sbeattie> So with pitti and jibel gone, is there anyone who looks for bogus test failures that block migrations from wily-proposed?
#ubuntu-release 2015-05-17
<ari-tczew> can someone with main upload permission to retry a build of https://launchpad.net/ubuntu/+source/python-eventlet/0.17.3-2ubuntu1/+build/7410743 ?
<ScottK> It would be better to ask on -devel. It's not a release team issue.
#ubuntu-release 2016-05-16
<jamespage> if there are any sru team folk around, I shoved a minor update to dh-python into the xenial queue over the weekend; would be nice to get that accepted and processed as the bug will block mitaka point releases until resolved (we have some in the pipeline)
<rcj> philroche, o/
#ubuntu-release 2016-05-17
<yofel> hi, could someone please either accept networkmanager-qt in x-proposed or at least delete ubuntu1.2 in there? I misread the symbol diff and that package has a broken ABI (fixed in ubuntu1.3 by fixing the ABI break)
<apw> yofel, i can only see the ubuntu1.3 in there so i assume someone did so, though why queuebot never mentioned it is a mystery
<knome> apw, https://www.youtube.com/watch?v=__DrJI7mTHQ
<yofel> apw: LP still tells me that 1.2 is in proposed and shows 1.3 in unapproved
<apw> yofel, oh in -proposed, derp
<yofel> RAOF: hi, as you seem to be SRU person of the day, could you please delete networkmanager-qt 5.18.0-0ubuntu1.2 from xenial-proposed until someone has the time to review 1.3?
<infinity> yofel: Nitpick, when you restored those symbols, you should have restored them as they appeared in -0ubuntu1 (ie: tagged with "5.1.1+git20141203.0020+15.04")
<infinity> yofel: Much harder to review it with the new version.
<infinity> yofel: (And things that build against it will suddenly get unnecessary deps on the new version)
<infinity> yofel: In fact, that's more than a nitpick, I'll probably reject for the latter reason.
<infinity> yofel: Also, when reuploading an SRU over an SRU, you should use dpkg-genchanges -S -v(version-in-updates/release) to get all the changelog entries from previous proposed uploads.
<infinity> yofel: Also, removed the broken one from proposed.
<clivejo> how do I find someone to sponsor uploads to the yakkety archive?
<nacc> clivejo: subscribe ubuntu-sponsors to the bug?
<apw> clivejo, there are lots of people who do that sort of thing ... though normally one would put what you want sponsored in a bug and subscribe the ubuntu-sponsors team
<clivejo> the problem is its not just one package, its a suite of packages for KDE Plasma Desktop
<apw> clivejo, doesn't kde normally prep all that lot in a PPA, they could be copied from there instead
<clivejo> apw: yes
<clivejo> apw: just need someone who knows what we are up to and can do the uploads
<clivejo> the kubuntu team is very low on people power at the moment and needs a bit of help getting the packages uploaded
<clivejo> anyone suggest how I could get a sponsor?
<Logan> clivejo: sgclark maybe?
<clivejo> sgclark is having to step back a bit from kubuntu due to personal reasons
<Logan> oh :(
<Logan> I mean, I'm a MOTU
<sgclark> ehm wait what. What about the release manager yofel?
<clivejo> yofel isnt MOTU?
<sgclark> neither am I lol
<sgclark> but we can upload KDE seed
<sgclark> so he should be able to...
<stgraber> oh, let me re-upload that lxcfs one with a prettier version number, that one's kinda ugly
<clivejo> sgclark: yofel is bit stressed out too at the moment, was looking for someone to sponsor me and see if I can develop the skills needed
<sgclark> clivejo: I see. I doubt you will find someone to sponser such a massive amount of packages at once. I will do it, lets take this back to kubuntu-devel
<clivejo> sgclark: I dont like pestering you or Phil, you both have other stuff going on
<sgclark> this is very true. but it needs done no?
<clivejo> well yes, you need frameworks 5.22 for apps 16.04
<clivejo> would be nice to get them uploaded instead of copying between PPA's
<sgclark> I said I would. Please answer me in kubuntu channel :)
<Trevinho> hello, anyone from the SRU team? We'd need to move this silo to the process: https://requests.ci-train.ubuntu.com/#/ticket/1316
#ubuntu-release 2016-05-18
<infinity> diff from 2.0.0-0ubuntu4 to 2.0.1-0ubuntu1~16.04.1 (8.1 MiB)
<infinity> stgraber: ^-- orly?
<stgraber> is that lxd?
<infinity> Yeah.
<stgraber> yeah, blame go
<infinity> lxc and lxcfs look saner.
<stgraber> I'm guessing 8MB of that is in dist/
<stgraber> which isn't used in Ubuntu since we've got our own copies of that stuff from -dev packages
<infinity> Oh, bleh.
<infinity> Kay, filterdiff to the rescue, I guess.
<stgraber>  50 files changed, 1709 insertions(+), 1104 deletions(-)
<stgraber> upstream diffstat for 2.0.0 to 2.0.1
<infinity> You know what I think would be awesome?  If every software project in the world bundled all their dependencies.
<stgraber> :)
<infinity> (Ironically, if they all did it together, I think the result would be called "Debian")
<yofel> infinity: good point, symbols fixed. And thanks for the -v reminder, I keep forgetting that
<apw> yofel, you can reuse numbers if they got rejected btw
<yofel> apw: hm... I didn't do that because that would've required me retagging git. But now I realize that I could actually do that now (when our repositories were on alioth the debian team didn't allow that)
<yofel> I'll do that next time
<apw> yofel, some people do it for their own sanity, it was just an observation
<yofel> right, I did that in the pre-git era as well, or when I immediately realize a mistake. Policy just prevented me from doing that lately
<Odd_Bloke> infinity: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/enable-backports/+merge/295059 <-- this is the backports change we talked about a few days ago
<estan> arges: hi. i'd like to ask for an SRU nomination of https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128 , are you the one to talk to? it's the first time i do this. i attached a debdiff against the source package to the bug.
<ubot5> Launchpad bug 1583128 in octave (Ubuntu) "HDF5 I/O broken with integer variables" [Undecided,New]
<arges> estan: hi. i can take a look
<estan> arges: thanks a lot. much appreciated.
<arges> estan: no problem. Did this already get fixed in Yakkety?
<arges> estan: ok i see it hasn't Ill upload to yakkety first, then once its fixed there we can do the SRU for xenial
<estan> arges: okay great.
<estan> nacc: hi. i got help from arges in #ubuntu-release :) it's not in yakkety, so he said he'd upload to yakkety first, before doing an SRU.
<estan> err, sorry. wrong channel.
<arges> estan: just uploaded into yakkety fyi
<estan> arges: excellent. btw, we wouldn't mind having this fix in wily as well.. but i don't know what the policy is here (i'm such a packaging noob :p).
<arges> estan: hmm looks like a new version of octave just landed in yakkety before i was able to upload... i need to rebase on that (or just check if your patch is in it already)
<arges> estan: for wily we can sru to that too. the policy is to fix it in development first, then any newer stable versions it affects. so Yakkety then Xenial and Wily
<estan> arges: ah alright. the fix is in 4.0.1 upstream already.
<arges> estan: ok well that makes it easier : )
<estan> arges: so if yakkety now has 4.0.2, that's good. but there were a lot of changes in 4.0.1 and 4.0.2, so maybe it's not all SRU-worthy..?
<arges> estan: if you can make a debdiff against wily i can sponsor that too. In addition be sure to add (LP: #XXXXX) in teh comments to indicate which bug the changelog closes
<estan> (that's why i went with making a patched 4.0.0).
<arges> estan: i will just sponsor your fix patched against the version in xenial
<estan> arges: yep, alright.
<estan> hm. add LP: #XXXXX in which comments? in the changelog itself?
<arges> estan: yea look through the existing entries to see how its done. I'll add it into the xenial changes for you
<arges> estan: here is an example: http://pastebin.ubuntu.com/16493609/
<estan> arges: ah. thanks! i'll see about making a debdiff for wily then.
<lamont> RAOF: aroudn?
<estan> arges: sorry for the questions, but.. should i create a bug separately for wily, just so that i have something to close with LP: #NNNN in the changelog?
<nacc> estan: no, a bug can have tasks for multiple releases
<nacc> estan: and the auto-closer will dtrt
<estan> ah. neat.
<estan> thanks.
<nacc> estan: so presuming wily task has been opened in that bug (requested in #ubuntu-bugs, etc)
<arges> yea what nacc said : )
<estan> ah. i see. at the moment there is no wily task (https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128). not sure i have the bits to open one.
<ubot5> Launchpad bug 1583128 in octave (Ubuntu Xenial) "HDF5 I/O broken with integer variables" [Undecided,New]
<nacc> estan: so looks like fixed in yakkety and sru opened to xenial?
<nacc> estan: you'd request in #ubuntu-bugs (or from arges, who maybe already helped you here) to open tasks for other target series
<arges> yea targeted against wily
<arges> so just add the wily debdiff to that same bug,  and i'd be happy to sponsor that
<estan> excellent.
<estan> arges: https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/comments/5
<ubot5> Launchpad bug 1583128 in octave (Ubuntu Xenial) "HDF5 I/O broken with integer variables" [Undecided,New]
<arges> estan: thanks
<estan> you too :)
<LocutusOfBorg> please accept octave from new, I plan to transition it tonight if you accept it
<LocutusOfBorg> BTW libpng12 can be removed now, I fixed the latest blocker this morning
<LocutusOfBorg> faumachine is broken and will be removed in Debian too probably
<LocutusOfBorg> (also vtk and insighttoolkit can be removed almost easily, but I have no dak on Ubuntu)
<mapreri> (all of them are already gone from debian)
<RAOF> lamont: I am now, but not at 3am :)
<knome> but it is practically almost 3am now!
<knome> :)=
<lamont> RAOF: heh
<lamont> RAOF: turns out that there's another bit of python that matters far more than the others: apparmor :/
<lamont> RAOF: but the two scripts affected by the change are pretty much don't care, and known to work with both python2 and 3 in any case
<RAOF> What do the scripts do?
<cjwatson> s390x builders will be going down in about 25 minutes for maintenance; expected downtime about an hour
#ubuntu-release 2016-05-19
<cjwatson> s390x builders back up; took a bit longer than expected, but there were no builds to be delayed
<flexiondotorg> Laney I need some education please.
<flexiondotorg> I uploaded ubuntu-mate-artwork to Yakkety yesterday, I see it here - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<flexiondotorg> And the build here - https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/16.10.0/+build/9765659
<flexiondotorg> I don't understand why it is held up :-(
<Laney> Click the "16.10.0" link
<flexiondotorg> This one? https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/16.10.0
<Laney> Yep
<Laney> Do you see it? :)
<Laney> "amd64 (New)"
<flexiondotorg> I don't.
<Laney> You uploaded new binaries
<Laney> https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=ubuntu-mate-artwork
<flexiondotorg> Ahh, for the ubuntu-mate-wallpapers-yakkety
<flexiondotorg> Right, got it. Thanks.
<flexiondotorg> So someone will ack that at some point and it will move along :-)
<Laney> That's the idea
<flexiondotorg> Thanks.
<xnox> Trevinho, ^
<Trevinho> xnox: great, thanks
<LocutusOfBorg> please accept octave from new
<LocutusOfBorg> and remove pepperflashplugin-nonfree[i386] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824706
<ubot5> Debian bug 824706 in ftp.debian.org "RM: pepperflashplugin-nonfree [i386] -- RoQA; ANAIS" [Normal,Open]
<sil2100> Hello release team! I will be performing a batch copy of ubuntu-touch packages we have in the xenial-overlay PPA to yakkety
<sil2100> We want to enable triple-landings for touch in the CI Train (yakkety+xenial-overlay+vivid-overlay) and this is the point where we want to sync the work we have held back till now
<sil2100> Any objections for the mass binary copy from xenial-overlay PPA to yakkety for touch packages?
<cjwatson> sil2100: https://launchpad.net/ubuntu/+source/click/+publishinghistory implies that you didn't check whether the packages in the overlay were older than yakkety before copying
<cjwatson> (hopefully p-m will just ignore it, but it may cause some cruft)
<sil2100> cjwatson: hm, I did check that, a bit differently but I did
<sil2100> I mean, this should show up after my check
<sil2100> So the thing that I checked was if yakkety had newer versions than xenial primary archive, since I didn't want to overwrite any no-change rebuilds for transitions
<sil2100> http://paste.ubuntu.com/16507351/ <- this was my list
<sil2100> Didn't see click on it, sorry about that
<sil2100> Hope it gets rejected simply in that case
 * sil2100 proceeds with source-uploads for those that had no-change rebuilds
<cjwatson> sil2100: ah I think the relevant change was actually in xenial too
<cjwatson> there was some reason I had to use the overlay there
<cjwatson> anyway, EOW, have fun
<sil2100> Thanks, and again sorry for that
<infinity> jibel: Do we still have automated upgrade testing running somewhere?
<jibel> infinity, yes but they all stopped working a week ago
<infinity> jibel: Due to upgrade bugs, or infra bugs?
<jibel> infinity, Max told me it was a problem with the infra but he hadn't been able to trace it down yet.
<infinity> jibel: Mmkay.
<infinity> jibel: Would be nice to get that going again Soon(tm), so we can shake out remaining LTS->LTS upgrade bugs before 16.04.1
<jibel> infinity, it is on his list of priorities.
<jibel> infinity, actually he fixed it this week and lts -> lts tests are running
<infinity> jibel: Lovely.  Have a pointer to where I can find results?
<bdmurray> slangasek: given that you added the snapd special case, how do you feel about the description in bug 1583085?  I'd feel better if they were more verbose about the QA process.
<ubot5> bug 1583085 in snapd (Ubuntu Xenial) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085
<sinzui> hi bdmurray juju-core is in the wily and trusty upload queues Can you help get the packages into their respective proposed pockets?
<estan> hi. anyone feeling up for verifying https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128 so it can go into xenial-updates? i did some quick testing and it looks good (it's dead simple fix).
<ubot5> Launchpad bug 1583128 in octave (Ubuntu Wily) "HDF5 I/O broken with integer variables" [Undecided,New]
<estan> *it's a.
<nacc> estan: hrm? it's fix committed already?
<nacc> and you've done the verification, afaict?
<estan> nacc: yes, i verified it shortly after Martin made his comment there about it going into xenial-proposed.
<estan> but Fix Commited, does that really mean it has landed in xenial-updates? (sorry, i'm a little new to all things packaging).
<nacc> no, that would be "Fix Released"
<estan> ah.
<nacc> "The SRU team will evaluate the testing feedback and they will move the package into -updates after it has passed a minimum aging period of 7 days."
<nacc> from https://wiki.ubuntu.com/StableReleaseUpdates
<estan> aha, i see. well then i guess i'm just kindly asking if someone else could test as well :) but maybe someone will just drop by.
<estan> (since i'm the reporter, i found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#How_to_perform_the_test that if a bug reporter does the verifying, it will be considered verified if at least two positive testimonials in the bug report.)
<estan> it's a little wonky to test unfortunately, since you need access to octave 3.x.
<nacc> estan: some crazy folks run with -proposed (not me)
<estan> or well, that's the easiest way to test, i guess you could look at the HDF5 data in some other viewer to make sure it's correct.
<estan> nacc: fair enough :)
<nacc> estan: but hopefully someone else affected by the same bug will see it
<bdmurray> I wouldn't worry too much about the words "two positive"
<estan> i could always ask my collegue tomorrow :)
<bdmurray> sinzui: where did 1.25.5-0ubuntu2~15.10.1 go?
<nacc> estan: yeah, i don't think that's a hard and fast rule, since you did file the bug, you gave a reasonable test case (i think), you ran w/ and without the fix and can confirm the testcase is fixed, and the fix is fairly trivial
<sinzui> bdmurray: this is a backport of https://launchpad.net/ubuntu/+source/juju-core-1 ... the package was renamed in xenial so teh backport appears to come out of nowhere
<bdmurray> sinzui: okay, I see the 1.25.0 vs 1.25.5 now
<sinzui> bdmurray: bug1556981 explains ti oddness of the backport
<sinzui> bug 1556981
<ubot5> bug 1556981 in juju-core (Ubuntu Wily) "[needs-packaging] Juju 1.25.5 is not in wily and trusty" [Wishlist,In progress] https://launchpad.net/bugs/1556981
<bdmurray> sinzui: Right, I was looking at the diff and just didn't notice the change from 0 to 5
<sinzui> bdmurray: juju has a sad history of delaying requests for backports because a stakeholder as some issue they want in the *next* release. There is optimism that the next release is just a few days away...not weeks
<bdmurray> sinzui: fwiw the MicroReleaseException link is obsolete now
<sinzui> :/
<estan> nacc: yea. can't really see what could go wrong.
<estan> btw, is there something blocking uploading it to wily-proposed now? or must it first be released in xenial?
<nacc> estan: i think it can go into wily-proposed once it's in <devel>
<nacc> (yakkety currently that is)
<estan> ah okay. then it should be good to go now (yakkety already has 4.0.2).
<nacc> estan: right, just need a sponsor to do it, i think :)
<slangasek> bdmurray: more verbose about the qa process in the wiki page, or on the bug?
<slangasek> bdmurray: I don't think the bug description needs to be very detailed, as long as the process it points to is appropriate and is followed
<bdmurray> slangasek: on the bug like this juju-core one - bug 1556981
<ubot5> bug 1556981 in juju-core (Ubuntu Wily) "[needs-packaging] Juju 1.25.5 is not in wily and trusty" [Wishlist,In progress] https://launchpad.net/bugs/1556981
<slangasek> bdmurray: ok. I don't feel strongly about this, but if we want there to be particular information included in the SRU bug let's communicate that to them, and ASAP as the snappy team's goal right now given their rapid dev cycle and aggressive deadlines is weekly SRUs with a 2-day publication cycle (i.e. waive the default 7-day waiting period because the testing is all coordinated so no aging is
<slangasek> needed/wanted)
<estan> arges: will you do the upload of LP: 9773353 to wily as well? (thanks a lot for the help btw).
<ubot5> Error: Launchpad bug 9773353 could not be found
<estan> arges: err, LP: 1583128
<ubot5> Launchpad bug 1583128 in octave (Ubuntu Wily) "HDF5 I/O broken with integer variables" [Undecided,New] https://launchpad.net/bugs/1583128
<arges> estan: I uploaded it yesterday actually. An sru-team member needs to do the review so it gets into proposed.
<estan> arges: aha. i see. great.
<arges> https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=octave
<flocculant> arges: thanks for the super quick libvirt fix :)
<arges> flocculant: glad it fixed it for you!
<flocculant> so was I :)
#ubuntu-release 2016-05-20
<xnox> no change rebuilds to fix s390x miscompiles start
<xnox> no change rebuilds to fix s390x miscompiles stop
<flocculant> arges: well it worked till I got a virtinst and virt-manager update this morning ;) now getting the same thing as yesterday
<estan> hm. does https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712 really need a 7 day grace period? CPUs are burning around the world :)
<ubot5> Launchpad bug 1579712 in appstream (Ubuntu Xenial) "Refresh hangs indefinitely, appstreamcli using 100% CPU" [High,Fix released]
<Laney> It's released.
<estan> bah. right you are. for some reason i thought it was only in -proposed still.
<seb128> estan, it was released like 10 minutes ago
<estan> i'm so behind :p
<estan> hm, but wait. i'm on 0.9.4-1ubuntu1 now, which is the fixed one (right?), and i still suffer from it :/
<estan> or wait. if works if i take the debs. some sort of chicken-egg-ish problem.. oh well. all good now.
<seb128> estan, works or not?
<estan> seb128: if i take the debs and install with dpkg -i it works. when i tried aptitude remove appstream && aptitude update && aptitude install appstream (which got the same version as the debs), i got a 100% CPU hang in appstreamcli during the installation.
<seb128> k
<Laney> because you need libappstream3
<estan> which i find strange. i tried disabling appstream during the whole procedure by moving /etc/apt/apt.conf.d/50appstream.
<estan> aha.
<Odd_Bloke> Is there a core-dev around who could review this livecd-rootfs change, please?  https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/enable-backports/+merge/295059
<infinity> Odd_Bloke: Reviewed, but also, I'm not really here.
<Odd_Bloke> Thanks, ghostfinity.
<mapreri> LocutusOfBorg asks for a transition tracker for hunspell, octave , glpk, suitesparse, can we haz them? :) /cc doko
<ginggs> infinity, doko: ^ whomever sets these up, we need one for gdal as well, please
<Laney> mapreri / ginggs: It's much easier if someone supplies the file
<yofel> talking about transitions: if you have a use for this: http://people.ubuntu.com/~yofel/ben/auto-libkscreen.ben (lxqt-config should be the only package left to do)
<ginggs> Laney: anything wrong with just copying Debian's https://release.debian.org/transitions/config/ongoing/gdal-2.1.0.ben ?
<Laney> Probably not
<Laney> but if you want us to hunt for them then it's going to slow things down :)
<shadeslayer> could someone review those please :)
<Laney> ginggs: pushed
<ginggs> Laney: ta!
<Laney> ginggs: lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs is the branch to do MPs against, FYI
<ginggs> Laney: can I get write access to that branch please?
<Laney> I wonder if we couldn't just add ~ubuntu-dev to it
<mapreri> Laney: gianfranco sent you the files via email
<Laney> haha
<Laney> are you his secretary? :P
<mapreri> and indeed I can't understand why ~ubuntu-transition-trackers is so limited.  transition handling ain't that restricted
<mapreri> Laney: he just can't connect to IRC from his job place, so I act as a IRC <-> telegram relay ;D
<Laney> ok, relay this - his files are wrong! https://release.debian.org/transitions/config/ would be a better place to find them
<mapreri> (done)
<Laney> :)
<Laney> I invited ~ubuntu-dev
<Laney> can't add it directly, needs to be a team admin (DMB)
<mapreri> and, uh, I didn't know the things were http-accessible.  I have a git clone of that to access the conf files here
<mapreri> https://release.debian.org/transitions/.git/
<Laney> hax
<LocutusOfBorg> hi, is it possible to blacklist import of texlive*^
<LocutusOfBorg> wrt #824835
<LocutusOfBorg> debian bug #824835
<ubot5> Debian bug 824835 in texlive-base "tex-common: fmtutil fails" [Serious,Open] http://bugs.debian.org/824835
<LocutusOfBorg> it breaks every build-depends on latex*
<LocutusOfBorg> also, please accept virtualbox/amd64 on yakkety/new :)
<LocutusOfBorg> so I can see it migrate before the next import from Debian
<LocutusOfBorg> cjwatson, ^^ please :)
<cjwatson> LocutusOfBorg: I'm not working today and am nowhere near the necessary auth tokens.
<LocutusOfBorg> ooh have fun then :)
<LocutusOfBorg> sorry for disturbing, I hope another archive admin can help me
<cyphermox> pitti: will you also update grub2-signed?
<jhobbs> hello, i've completed the verification for this bug so it can be SRU'd into xenial https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1547060
<ubot5> Launchpad bug 1547060 in tgt (Debian) "cant use -d switch" [Unknown,New]
<jhobbs> what needs to happen to get it landed in xenial from here?
<slangasek> jhobbs: needs to wait until Monday, we don't release SRUs on Fridays
<jhobbs> slangasek: ok
<jhobbs> slangasek: do i need to ping someone on monday or will it happen as part of some process?
<slangasek> jhobbs: should happen as part of the process, but doesn't hurt to nudge here Monday morning to be sure
<jhobbs> ok thanks
#ubuntu-release 2016-05-21
<estan> hm, how hard is the "minimum aging period of 7 days" rule wrt to verification-done -> -updates when the bug+fix is quite obvious? i would love to see https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128 uploaded to -updates.
<ubot5> Launchpad bug 1583128 in octave (Ubuntu Xenial) "HDF5 I/O broken with integer variables" [Undecided,Fix committed]
<slangasek> estan: it's not a hard, fast rule, but a) we don't release updates on Fridays, b) we waive the aging period only when we have some other means of being sure there's adequate regression testing
<estan> slangasek: alrighty.
<estan> though it is saturday here :p
<slangasek> we release even fewer updates on Saturdays ;)
<LocutusOfBorg> uff I have 4 ben files to share, can anybody please commit them?
<LocutusOfBorg> http://paste.ubuntu.com/16548259/
<LocutusOfBorg> the whole borg community will thank a lot whoever commits them :)
<apw> LocutusOfBorg, hopefully done
<LocutusOfBorg> thanks!
<LocutusOfBorg> apw, sorry! octave has the tracker reversed :( my bad! bad is liboctave3 good is liboctave3v5
<apw> LocutusOfBorg, doh ... fixed
<LocutusOfBorg> thanks! and sorry again
<apw> LocutusOfBorg, looks to be updated the other way round
#ubuntu-release 2016-05-22
<Logan> LocutusOfBorg: FYI, the branch for configs is here, so you can do a merge proposal in the future: https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs
<LocutusOfBorg> Logan, I read about developers being added to that team :)
<Logan> LocutusOfBorg: you'll have to talk to one of the team administrators about that!
<Logan> they added me a number of months ago :P
<Logan> (they'll probably want a decent number of solid merge proposals first)
<LocutusOfBorg> maybe I wasn't clear enough
<LocutusOfBorg> one sec
<LocutusOfBorg> https://launchpad.net/~ubuntu-transition-trackers/+members#invited
<LocutusOfBorg> one link is better than a thousand words :)
<Logan> ohhh
#ubuntu-release 2017-05-15
<mwhudson> RAOF: around? fancy deleting kombu from artful-proposed? :)
<mwhudson> RAOF: it breaks celery
<mwhudson> i guess i should file an archive admin bug
 * RAOF has Mondays off for the next month-and-a-half. Please see you regularly scheduled archive admin ð
<mwhudson> ha, as if
<mwhudson> i filed a bug anyway
<jbicha> SRU Team, please reject the May 13 gnome-shell SRU candidates for xenial, yakkety, zesty; I'll re-upload with another fix
<slangasek> jbicha: done
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (xenial-proposed) [3.18.5-0ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (yakkety-proposed) [3.20.4-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: sphinx (xenial-proposed/main) [1.3.6-2ubuntu1 => 1.3.6-2ubuntu1.1] (edubuntu, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: sphinx (yakkety-proposed/main) [1.4.8-1 => 1.4.8-1ubuntu0.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.6]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie [source] (trusty-proposed) [0.2.24.6ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (trusty-proposed) [2.14.1-0ubuntu3.24]
-queuebot:#ubuntu-release- Unapproved: strongswan (xenial-proposed/main) [5.3.5-1ubuntu3.1 => 5.3.5-1ubuntu3.2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: strongswan (yakkety-proposed/main) [5.3.5-1ubuntu4.1 => 5.3.5-1ubuntu4.2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- New: accepted python-ncclient [amd64] (artful-proposed) [0.5.3-1]
<LocutusOfBorg> hello, can any AA please remove open-infrastructure-locales-c.utf-8?  debian bug #862343 has the rationale for the removal
<ubot5> Debian bug 862343 in ftp.debian.org "RM: open-infrastructure-locales-c.utf-8 -- RoQA; Provides 'locales' and 'locales-all', breaks package builds when installed, appears unnecessary" [Normal,Open] http://bugs.debian.org/862343
<LocutusOfBorg> thanks
<LocutusOfBorg> reverse-depends seems happy
 * apw looks
<apw> LocutusOfBorg, put out of our misery
<apw> Laney, ^
<Laney> thanks apw, LocutusOfBorg
<Laney> I thought I checked if we had that in Ubuntu
<Laney> must have typoed the package name
<apw> Laney, or it came in afterwards
<Laney> that was this morning :P
<Laney> I think I typed .c-utf-8 instaed of -c.utf-8
<infinity> I shouldn't have even had to guess who uploaded that.
<LocutusOfBorg> I still think "provides" and "epoch bumps" should go in new queue neverthless
<LocutusOfBorg> thanks apw
 * apw likes the idea of epoch's getting jammed
<LocutusOfBorg> debian bug: #860797 opened by me
<ubot5> Debian bug 860797 in ftp.debian.org "please make packages with epochs bump go in new queue" [Normal,Open] http://bugs.debian.org/860797
<mwhudson> what the heck
<mwhudson> (that package)
<infinity> It makes perfect sense locally, for dba's own infrastructure.  It makes zero sense to ship in a distro.
<rbalint1> cjwatson, infinity,slangasek: what do you think about hardlinking duplicated files together in Ubuntu images?
<rbalint1> setuid files should be skipped, but otherwise it seems to work https://lists.debian.org/debian-devel/2009/03/msg01499.html
<rbalint1> i think this is the only way of deduplicating copyright files across packages, but it found some other duplicates, too
<rbalint1> it there is no obvious problem with that i give a try to  something like "hardlink -n chroot/usr/"  in livecd-rootfs
 * cjwatson has no opinion
<cjwatson> just be careful to test what ubiquity does, and whether things work well if there are hardlinks in the image but the user has requested partitioning such that they need to be split across multiple partitions, etc.
<cjwatson> in fact ubiquity probably won't preserve the hardlinking, which is probably fine
<cjwatson> you might also find that it doesn't actually save much useful space; squashfs compression might well already notice the duplication
<cjwatson> but anyway, I only have random thoughts
<rbalint> cjwatson: yes, the compression will decrease the gains
<cjwatson> but will it decrease them or nullify them?
<cjwatson> needs data.
<cjwatson> if the size gain on images is in practice epsilon then we shouldn't waste time on it at image build time
<rbalint> cjwatson: some memory can be saved when squashfs is extracted
<cjwatson> *shrug* I'm not going to argue
<rbalint> cjwatson: sure, i did not want to argue, just to add something to consider and maybe measure :-)
<slashd> For SRU vanguard, Good Monday! Could you please have a look at this UA bug (LP: #1689854) and prioritize it if possible ? The pkg can be found in the Trusty upload queue ==> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=isc-dhcp
<ubot5> Launchpad bug 1689854 in isc-dhcp (Ubuntu Trusty) "Multiple DHCPv6 client interfaces fail to receive some server responses" [Medium,In progress] https://launchpad.net/bugs/1689854
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.4-0ubuntu1.2 => 2:14.0.5-0ubuntu1] (openstack, ubuntu-server)
<rbalint> cjwatson: squashfs already supports deduplication, but ext4 images may shrink a bit
<rbalint> cjwatson: i give it a try and see what the data says
 * LocutusOfBorg would appreciate a review of virtualbox-* yakkety queue
-queuebot:#ubuntu-release- New binary: reprozip [amd64] (artful-proposed/universe) [1.0.9-4~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: reprozip [i386] (artful-proposed/universe) [1.0.9-4~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [source] (zesty-proposed) [1.5.3-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [source] (yakkety-proposed) [1.4.8-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [sync] (xenial-proposed) [1.3.6-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [sync] (yakkety-proposed) [5.3.5-1ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [sync] (xenial-proposed) [5.3.5-1ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (yakkety-proposed) [2:14.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: borgbackup (xenial-proposed/universe) [1.0.7-0ubuntu1.16.04.1 => 1.0.10-2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: borgbackup (yakkety-proposed/universe) [1.0.7-1 => 1.0.10-2~16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: reprozip [amd64] (artful-proposed/universe) [1.0.9-4] (no packageset)
-queuebot:#ubuntu-release- New binary: reprozip [i386] (artful-proposed/universe) [1.0.9-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nagios3 (trusty-proposed/main) [3.5.1-1ubuntu1.1 => 3.5.1-1ubuntu1.2] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: nagios3 (xenial-proposed/main) [3.5.1.dfsg-2.1ubuntu1.1 => 3.5.1.dfsg-2.1ubuntu1.2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: nagios3 (yakkety-proposed/main) [3.5.1.dfsg-2.1ubuntu3.1 => 3.5.1.dfsg-2.1ubuntu3.2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: nagios3 (zesty-proposed/main) [3.5.1.dfsg-2.1ubuntu5 => 3.5.1.dfsg-2.1ubuntu5.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.3 (trusty-proposed/main) [9.3.16-0ubuntu0.14.04 => 9.3.17-0ubuntu0.14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.6-0ubuntu0.16.04 => 9.5.7-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (yakkety-proposed/main) [9.5.6-0ubuntu0.16.10 => 9.5.7-0ubuntu0.16.10] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.6 (zesty-proposed/main) [9.6.2-1 => 9.6.3-0ubuntu0.17.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.9]
-queuebot:#ubuntu-release- New source: launchpad-buildd (xenial-proposed/primary) [144]
<cjwatson> er what
<cjwatson> $ debrelease -S ppa:launchpad/ubuntu/ppa
<cjwatson> oh I guess I did both by accident
-queuebot:#ubuntu-release- New: rejected launchpad-buildd [source] (xenial-proposed) [144]
<ahasenack> why is mysql-server-5.7 in xenial-updates ahead of artful?
<ahasenack>  mysql-server-5.7 | 5.7.18-0ubuntu0.16.04.1 | xenial-updates   | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<ahasenack>  mysql-server-5.7 | 5.7.17-0ubuntu1         | artful           | amd64, arm64, armhf, i386, ppc64el, s390x
<infinity> ahasenack: Because whoever did the security update didn't think to copy it forward.
 * infinity copies.
<slangasek> ah, a security update, that explains
<ahasenack> when a sec update is done, the package is uploaded to both security and updates?
<slangasek> yes
<slangasek> security updates are always copied to -updates because it better distributes mirror network load
<infinity> Which is why the default sources.list lists updates before security.
<slangasek> (and because we don't want confusion about SRUs of things that have a newer version in -security but not in -updates)
<infinity> So, if your local mirror is lagging, you'll get the update in a timely fashion from -security.  If your local mirror is up to date, you'll get the local copy.
<ahasenack> ok
-queuebot:#ubuntu-release- Unapproved: gnome-shell (zesty-proposed/universe) [3.24.1-0ubuntu1 => 3.24.2-0ubuntu0.1] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (yakkety-proposed/universe) [3.20.4-0ubuntu2 => 3.20.4-0ubuntu3] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (xenial-proposed/universe) [3.18.5-0ubuntu0.2 => 3.18.5-0ubuntu0.3] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- New binary: golang-github-dlclark-regexp2 [amd64] (artful-proposed/universe) [1.1.4+git20170331.0.902a5ce-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-rules [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pkg-profile [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [s390x] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [ppc64el] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-dlclark-regexp2 [amd64] (artful-proposed) [1.1.4+git20170331.0.902a5ce-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [ppc64el] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted python-django-rules [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted reprozip [i386] (artful-proposed) [1.0.9-4]
-queuebot:#ubuntu-release- New: accepted reprozip [i386] (artful-proposed) [1.0.9-4~build1]
-queuebot:#ubuntu-release- New: accepted golang-github-pkg-profile [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted reprozip [amd64] (artful-proposed) [1.0.9-4]
-queuebot:#ubuntu-release- New: accepted petsc4py [s390x] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted reprozip [amd64] (artful-proposed) [1.0.9-4~build1]
-queuebot:#ubuntu-release- New binary: petsc4py [amd64] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted petsc4py [amd64] (artful-proposed) [3.7.0-3]
#ubuntu-release 2017-05-16
-queuebot:#ubuntu-release- New binary: golang-github-dop251-goja [amd64] (artful-proposed/universe) [0.0~git20170430.0.d382686-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: network-manager (zesty-proposed/main) [1.4.4-1ubuntu3 => 1.4.4-1ubuntu3.1] (kubuntu, ubuntu-desktop)
<tjaalton> infinity: is there a release schedule for 16.04.3?
-queuebot:#ubuntu-release- New: accepted kaddressbook [source] (artful-proposed) [4:16.12.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kontact [source] (artful-proposed) [4:16.12.3-0ubuntu1]
<slangasek> infinity: second opinion on text at top of http://releases.ubuntu.com/12.04/ ? (LP: #1690565)
<ubot5> Launchpad bug 1690565 in Ubuntu CD Images "Remove EOL 12.04 from supported list" [Undecided,Won't fix] https://launchpad.net/bugs/1690565
<apw> slangasek, i would also make the "Extended Security Support" link to the same place as "here".
-queuebot:#ubuntu-release- New: accepted golang-github-dop251-goja [amd64] (artful-proposed) [0.0~git20170430.0.d382686-1]
<tjaalton> looks like noone on the sru team wants to review/ack mesa uploads :P
<sil2100> ;)
<sil2100> On which queue?
<tjaalton> zesty, though there's a new stable release now that I probably should prepare instead
<tjaalton> 17.0.5 -> .6
<sil2100> hmmm, I didn't see it yesterday, is it old?
<sil2100> Oh god
<tjaalton> the oldest of the bunch, there's two pages
<sil2100> It's on the other page
<tjaalton> yeah :)
<tjaalton> let me prep it after this call
<sil2100> tjaalton: you still want that reviewed? I could take a look in a moment if anything
<sil2100> (or if you have a newer one then we can just skip to that)
<tjaalton> sil2100: right, I'll prep the new one, won't take long
<sil2100> Sorry about that, I guess I missed the 'next page' button yesterday
<tjaalton> no problem
<tjaalton> another thing is the xenial backport stack components
<sil2100> Yeah, can't help with that yet, but I signed up for some backporter team training
<tjaalton> no these are normal sru's
<tjaalton> first wave is on the xenial queue
<apw> sil2100, i will probabally volunteer to do those kde point release reviews on the zesty queue as a batch -- everything with a version 5.9.5
<apw> sil2100, as it was me who rejected the whole lot en-mass last week :)
<sil2100> apw: ok, thanks! I wanted some additional feedback from the uploader as per my bug comment anyway, I suppose you might have more context
<sil2100> apw: oh, and just a question for future things like this - we need all of those components marked on the bug, right? For the SRU infra?
<sil2100> e.g. all those gazillion packages marked as affecting the bug
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (zesty-proposed) [17.0.5-0ubuntu1~17.04.1]
<tjaalton> sil2100: rejected old mesa, new one uploaded
<sil2100> tjaalton: thanks, looking o/
-queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.3-1ubuntu1 => 17.0.6-0ubuntu0.17.04.1] (core, xorg)
<apw> sil2100, right it needs all the packages adding, i'll get that sorted and i agree we need some testing feedback
<sil2100> Oh my, ok, then good luck! That'll be an awful task I suppose :|
<apw> sil2100, less awful than the new reviews for kde in artful, so :/
<sil2100> heh
<sil2100> tjaalton: will review as soon as the debdiff is generated
<tjaalton> sil2100: cool ,thx
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.6-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-pam [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwrited [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
<cpaelzer> hi, I was verifying an libvirt SRU but I need some help on x-proposed
<cpaelzer> Y and Z verified well, but for X I need a fixup
<cpaelzer> I already have that fixup built in a ppa and tested
<cpaelzer> Now I need some help to replace the current in proposed with the newer fixed one
<apw> cpaelzer, just upload it, and we can accpet it over the current proposed
<cpaelzer> ok, if that is working that is good
<apw> needs an incremented version of course
<cpaelzer> wasn't sure if we'd need to reject the former one
<cpaelzer> it already has the incremented version and is created with -v<oldver-in-updates>
<cpaelzer> so that the update picks up all that is needed
<apw> sounds right to me
<cpaelzer> pushing to x-unapproved then and will ping here
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
<cpaelzer> apw: libvirt 1.3.1-1ubuntu10.10 is no in x-unapproved
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.9 => 1.3.1-1ubuntu10.10] (ubuntu-server, virt)
<cpaelzer> here it is, thanks queuebot :-)
<cpaelzer> could one take a look and accept it over the current libvirt in x-p so I can verify that as well - thanks in advance
<apw> cpaelzer, that drops two patches adding lines and only adds one line ... is that what you are expecting ?
<cpaelzer> yes it drops the two patches form 10.9 and adds into debian/apparmo/libvirt-qemu two lines (one commend and one rule about vfio)
<apw> cpaelzer, to confirm we do not need "/proc/*/cmdline r," in the old world
<cpaelzer> yes not in the libvirt version in xenial
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.10]
<cpaelzer> thank you, and to explain the noise I'm only kind of in a hurry as the kernel Team (hi apw :-) ) will soon steal my testbed (to have a working ppc64el box themselfe again) and verifying without that is possible but so much harder :-)
<cpaelzer> hope that now verifies as it did from the ppa once it built in x-p later on
<apw> cpaelzer, those pesky kernel-team people
<tjaalton> sil2100: thanks for acking mesa :)
-queuebot:#ubuntu-release- Unapproved: accepted breeze-grub [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
<slashd> rbasak, morning I see you talked with dragan about this LP: #1645324. From now on, I'm taking care of this bug, I see that some ppls suggest Dragan to submit in the upstream project first, but in this case it seems that ebtables "dead" last commits were made in 2015. Nowadays, all the development happen in nft.
<ubot5> Launchpad bug 1645324 in ebtables (Ubuntu Artful) "ebtables: Lock file handling has races" [Medium,In progress] https://launchpad.net/bugs/1645324
-queuebot:#ubuntu-release- Unapproved: accepted breeze-gtk [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
<slashd> Do you think it could be eligilble for SRu anyway ? considering that Dragan already submitted the same patch to Debian ebtables
-queuebot:#ubuntu-release- Unapproved: accepted breeze-plymouth [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdecoration [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksshaskpass [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwayland-integration [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libkscreen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (zesty-proposed) [4:5.9.5.1-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace-wallpapers [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.26.1+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.26.1+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.26.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.26.1~14.04]
<ahasenack> hi, could someone please remove these two packages from proposed: https://launchpad.net/ubuntu/+source/pam-mysql/0.7~RC1-4.1ubuntu1.1 and https://launchpad.net/ubuntu/+source/pam-mysql/0.7~RC1-4ubuntu2.1
<ahasenack> they introduce a buffer overflow: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1574911
<ubot5> Ubuntu bug 1574911 in pam-mysql (Ubuntu) "vsftpd 500 oops stack smashing detected - Ubuntu 16.04" [Undecided,Confirmed]
<apw> nacc, ^^ these are your SRUs
<ahasenack> essentially my_make_scrambled_password() is not a replacement for the missing make_scrambled_password()
<mdeslaur> rbasak: good morning! I would like to release the qemu security updates that supersede the qemu package in xenial-proposed. Looks like it's got the required verification-done tags and has waited more than a week. Could you release it?
<apw> ahasenack, ok i've marked that up as failing so it cannot get released, and will wait on nacc's input
<ahasenack> apw: thx
<apw> mdeslaur, that qemu upload in xenial is a security update too by the looks of it, most confusing
<apw> or did i miss
<apw> mdeslaur, ignore me, i missed, stupid report
<mdeslaur> apw: could you release it?
<apw> mdeslaur, it looks releasable to me, so yes
<rbasak> mdeslaur: o/
<rbasak> I guess apw is taking care of it? Happy to look otherwise.
<mdeslaur> looks like it
<mdeslaur> thanks apw, rbasak
<apw> mdeslaur, done
<rbasak> Thanks apw!
<mdeslaur> thanks!
<ahasenack> artful still has an older mysql than xenial-updates, is an update stuck somewhere?
<ahasenack> 5.7.17-0ubuntu1         | artful
<ahasenack> 5.7.18-0ubuntu0.16.04.1 | xenial-security
<mdeslaur> ahasenack: yeah, it's stuck in artful-proposed
<rbasak> I've asked upstream to take a look
<mdeslaur> ah, cool, thanks rbasak
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
<nacc> apw: thanks
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
<slangasek> apw: done
<apw> slangasek, esm ?  not changed if so
<slangasek> apw: shift reload?  mirroring delay
<apw> slangasek, better now indeed
<nacc> jbicha: any thoughts on https://bugs.launchpad.net/bugs/1686257 possibly regressiong 16.04 users?
<ubot5> Ubuntu bug 1686257 in Ubuntu GNOME "gdm3 fails to start when default session-name=ubuntu" [High,In progress]
<nacc> jbicha: we have one person in #ubuntu now
<nacc> jbicha: thanks!
<slangasek> infinity: feedback requested on https://code.launchpad.net/~vorlon/ubuntu-cdimage/public-info-out-of-private-production/+merge/324120 - if you're +1 I'll make a corresponding change to drop this file from our private production/ branch
<jbicha> nacc: it's unlikely to be that bug, it's likely the 3.24.1 upgrade instead
<nacc> jbicha: ah
<nacc> jbicha: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1685500 then?
<ubot5> Ubuntu bug 1685500 in gdm3 (Ubuntu Zesty) "Update gdm3 to 3.24.1" [Low,Fix released]
<nacc> heh, the "Regression Potential" section does seem rather accurate
<jbicha> nacc: yes; the other bug is more worrying since that was SRU'd to 16.04 too
<nacc> why is that an acceptable regression potential
<jbicha> because otherwise we could never upgrade any key packages?
<jbicha> so far we have 1 report of that upgrade not working, which we can't duplicate yet
<nacc> jbicha: sure, it just seems like basically saying the regression potential is infinite
<nacc> which doesn't seem like a rational statement
<jbicha> it's a bit unclear what exactly I'm supposed to put in the Regression Potential section, but users can have a lot more problems if a gdm update is bad than a gnome-maps update
<jbicha> it's not clear if the affected user is going to bother filing a bug :(
<nacc> jbicha: yeah, i don't know
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: designate (yakkety-proposed/main) [1:3.0.0-0ubuntu1 => 1:3.0.1-0ubuntu1] (openstack)
<slangasek> apw: any reason for copy-proposed-kernel to take an --esm arg instead of this being implicit based on the release?
<slangasek> apw: (this feeds into whether/how we would patch kernel-sru-review)
<infinity>     if args.series == 'precise' and not args.esm:
<infinity>         print("NOTE: directing copy from and to ESM for precise")
<infinity>         args.esm = True
<infinity> slangasek: It is implicit, I expect --esm is for people who like to be explicit and/or for testing.
<slangasek> oho
<infinity> slangasek: See also --no-auto
<slangasek> apw, infinity: https://code.launchpad.net/~vorlon/ubuntu-archive-tools/sru-release-esm/+merge/324132 for the sru-release side of things
<infinity> slangasek: Switching on precise repeatedly seems ugly.  Would be better to switch on it once to select an "ESM mode", then switch on ESM throughout.  More readable when precise becomes precise|trusty (or is replaced by trusty).
<slangasek> fair
<slangasek> infinity: btw did you see my rfr on https://code.launchpad.net/~vorlon/ubuntu-cdimage/match-series-for-current-triggers/+merge/324123 ?
<infinity> slangasek: I'd also like to see the tooling treat ESM as a fourth pocket, even if that's a lie.  So:
<infinity> --- Releasing openssl ---
<infinity> Proposed: 1.0.2g-1ubuntu4.7
<infinity> Security: 1.0.2g-1ubuntu4.6
<infinity> Would also show me an "ESM:" version.
<infinity> Updates:  1.0.2g-1ubuntu4.6
<infinity> And tell me it's copying to Precise ESM.
<slangasek> ah; that will require a bit of fiddling, but I'll have a look
<infinity> slangasek: Yeah, it would be a very different patch, I grant you.  Just seems like, from a UI perspective, that might be more pleasant.  From an "only 3 people will run this command" perspective, I'm less fussed if it DTRT.
<infinity> It's not like everything in u-a-t has a stellar UI to start with. :P
<slangasek> yeah, not like we have two different ways to specify releases on the commandline, within a single tool repo
<infinity> Within a single toolset, even.
<slangasek> and at the moment we have no use case for sru-release on ESM outside of the kernels, so ideally everyone's invoking kernel-sru-release for the workflow management? :)
<infinity> Well, you and sil2100 might be.
<slangasek> infinity: if you prefer managing workflow bug tasks by hand, I won't stop you ;)
<infinity> It's never really bugged me.  But, also, shankbot could be filling in assignee based on the owner of the copies, if I deeply cared.
<infinity> (Honestly, I just didn't know that particular one existed until I just read it)
<slangasek> by the time shankbot has confirmed seeing the copy, the assignee mostly doesn't matter
<infinity> And kernel-sru-review is the one that desperately needs a polling loop with an upper bound to actually wait properly for the copies.
<slangasek> yeah, so what's a sensible upper bound? :/
<infinity>         # Arbitrary 10 second delay, maybe enough to let uefi binaries hit
<infinity>         # the unapproved queue.
<infinity>         time.sleep(10)
<infinity> Not that. ;)
<infinity> copy jobs are async, with two different potential queues.
<infinity> There an almost-sync-but-not-quite queue, and when that one overflows, the losers end up in a queue that runs every 5m.
<slangasek> ah ugh
<infinity> Which is a behaviour you see a lot if doing mass copies (like releasing 20 kernels).  The first half will be near-instant, the next chunk will trickle in at a */5 mark.
<slangasek> alright, new rev pushed to fix the precise hard-coding
<slangasek> afk for a bit
<infinity> slangasek: Was that ubuntustudio failure that just happened a bug in your code, or a race where the build started between you pulling the new revision and not having configs in place yet?
<infinity> slangasek: Ahh, kylin just completed successfully, so I'll assume the race thing and just retry studio for them.
<sil2100> While we're at kernel-sru-release - could anyone take another look at the tarball management bits?
<sil2100> :)
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.6-0ubuntu1~16.04.1 => 2.0.7-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.6-0ubuntu1~16.10.1 => 2.0.7-0ubuntu1~16.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (zesty-proposed/main) [2.0.6-1 => 2.0.7-0ubuntu1~17.04.1] (edubuntu, ubuntu-server)
<slangasek> infinity: ah yeah, I think the problem was I made the file on the production branch disappear out from underneath an already-running process
<sbeattie> is there any additional kernel publishing going on, or are things blocked on the kernel team's end (trying to figure out why most of the derived kernels didn't get published)
#ubuntu-release 2017-05-17
<doko> who is running packages.ubuntu.com? no artful yet ...
<nacc> doko: i filed a bug, iirc
<nacc> doko: LP: #1689679
<ubot5> Launchpad bug 1689679 in pkg-website "artful not listed, zesty needs -updates" [Undecided,New] https://launchpad.net/bugs/1689679
<doko> nacc: ok, but I think this package owner doesn't know about this website ...
<nacc> heh
<doko> infinity: ^^^
<nacc> doko: well, it's the explicit link from that page to 'file a bug' (at the bottom)
-queuebot:#ubuntu-release- Unapproved: mir (xenial-proposed/main) [0.21.0+16.04.20160330-0ubuntu1 => 0.26.3+16.04.20170510-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<nacc> so i'd hope they do
<nacc> or the page should be rewritten :)
<tumbleweed> rhonda IIRC
<doko> ohh, I see
<doko> ok, notified Rhonda as well
<RAOF> All the verification-done bugs! WOOO
<jbicha> RAOF: we were saving them for you!
-queuebot:#ubuntu-release- Unapproved: libepoxy (xenial-proposed/main) [1.3.1-1 => 1.3.1-1ubuntu0.16.04.1] (desktop-core)
<jamespage> o/
<jamespage> hi SRU team - there is a bileto sync for ceph in the trusty UNAPRROVED queue for bug 1636322
<ubot5> bug 1636322 in ceph (Ubuntu Trusty) "[SRU] upstart: ceph-all service starts before networks up" [High,In progress] https://launchpad.net/bugs/1636322
<jamespage> I'd not spotted it had not been accepted - newer series are all tested and fix released - if that could be accepted that would be marvelous
<sil2100> jamespage: hello!
<sil2100> jamespage: let me take a look
<jamespage> sil2100: ta - I know that syncs from bileto appear to blackhole in reporting for SRU's somewhere
<sil2100> They're not as bad when one gets used to them, they're just a bit confusing at first
<sil2100> I'd say it's even more convenient due to the fact I have an inside look into autopkgtests always
<sil2100> ;)
<sil2100> jamespage: done, I still remember the change from xenial, approved
-queuebot:#ubuntu-release- Unapproved: accepted ceph [sync] (trusty-proposed) [0.80.11-0ubuntu1.14.04.2]
<jamespage> sil2100: thanks!
<apw> jamespage, it is more that syncs are hard to review in general, so they get left to last
<apw> (because launchpad does not help at all with them)
<jamespage> apw: right I see
<apw> jamespage, that is not your fault of course ...
<jamespage> apw: slangasek and I discussed this; agreed we're re-upload source packages to UNAPPROVED, rather than doing syncs from now on
<apw> jamespage, you will cirtainly find you get reviews more easily ... sadly
<tjaalton> how should lp sync sru's be handled? check the packaging diff and open the bugs and check they've got everything ready?
<apw> tjaalton, i use queue fetch to get something to diff then when happy use sru-review --no-diff
<tjaalton> ah, didn't know of --no-diff
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (xenial-proposed) [0.26.3+16.04.20170510-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova-lxd (yakkety-proposed/main) [14.2.2-0ubuntu0.16.10.1 => 14.2.2-0ubuntu0.16.10.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova-lxd (zesty-proposed/main) [15.0.1-0ubuntu1 => 15.0.1-0ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [138-1 => 140-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: cockpit (yakkety-backports/primary) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New source: cockpit (xenial-backports/primary) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New source: python-deprecation (artful-proposed/primary) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [140-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [source] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [source] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/none) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (yakkety-backports/none) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (xenial-backports/none) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (yakkety-backports/none) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (xenial-backports/none) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (yakkety-backports/none) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (xenial-backports/none) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (yakkety-backports/none) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [powerpc] (yakkety-backports/universe) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [powerpc] (xenial-backports/universe) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (yakkety-backports/universe) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (xenial-backports/universe) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (yakkety-backports/universe) [140-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [powerpc] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (yakkety-backports) [140-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (xenial-backports/universe) [140-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: python-ovsdbapp (artful-proposed/primary) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [powerpc] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (xenial-backports) [140-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Packageset: Added gnome-getting-started-docs to personal-gunnarhj in artful
-queuebot:#ubuntu-release- Packageset: Added gnome-user-docs to personal-gunnarhj in artful
-queuebot:#ubuntu-release- Packageset: Added gnome-getting-started-docs to personal-gunnarhj in xenial
-queuebot:#ubuntu-release- Packageset: Added gnome-user-docs to personal-gunnarhj in xenial
-queuebot:#ubuntu-release- Packageset: Added gnome-getting-started-docs to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added gnome-user-docs to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added gnome-getting-started-docs to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added gnome-user-docs to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- New binary: writegood-mode [amd64] (artful-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nebulouslabs-fastrand [amd64] (artful-proposed/none) [0.0~git20170420.0.5a1a312-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sinon-chai [amd64] (artful-proposed/none) [2.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-glob2 [amd64] (artful-proposed/none) [0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [amd64] (artful-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [ppc64el] (artful-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-set-immediate-shim [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [ppc64el] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [s390x] (artful-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purl [amd64] (artful-proposed/universe) [1.3.1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [i386] (artful-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: maven-resolver [amd64] (artful-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [amd64] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [s390x] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [armhf] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [i386] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: trabucco [arm64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [armhf] (artful-proposed/universe) [3.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [arm64] (artful-proposed/universe) [3.7.0-3] (no packageset)
<bdmurray> infinity: I'm setting the 16.04.2 milestone to inactive since it is in the past.
<slangasek> bdmurray, infinity: do we have a date we can set for 16.04.3?
<bdmurray> I didn't see one in the XX Release Schedule
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-53.56] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-53.56~16.04.1] (kernel)
<infinity> slangasek: I'll toss one up today.
<slangasek> infinity: shiny
<infinity> And maybe a few others too, since we planned a few releases ahead a while ago.
-queuebot:#ubuntu-release- New: accepted golang-github-nebulouslabs-fastrand [amd64] (artful-proposed) [0.0~git20170420.0.5a1a312-1]
-queuebot:#ubuntu-release- New: accepted node-set-immediate-shim [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted purl [amd64] (artful-proposed) [1.3.1-1~exp1]
-queuebot:#ubuntu-release- New: accepted slepc4py [amd64] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted slepc4py [armhf] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted slepc4py [ppc64el] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted trabucco [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted trabucco [armhf] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted trabucco [ppc64el] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted writegood-mode [amd64] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted maven-resolver [amd64] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted python-glob2 [amd64] (artful-proposed) [0.5-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [i386] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted trabucco [arm64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted trabucco [s390x] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted node-sinon-chai [amd64] (artful-proposed) [2.10.0-1]
-queuebot:#ubuntu-release- New: accepted slepc4py [s390x] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted slepc4py [arm64] (artful-proposed) [3.7.0-3]
-queuebot:#ubuntu-release- New: accepted trabucco [i386] (artful-proposed) [1.0-1]
<slangasek> infinity, bdmurray: who's in charge of the ddeb importer these days?
<slangasek> we should maybe do something about http://ddebs.ubuntu.com//pool/universe/libs/libspiro/libspiro-dev-dbgsym_0.5.20150702-4_i386.ddeb and http://ddebs.ubuntu.com//pool/main/libv/libvdpau/libvdpau-dev-dbgsym_1.1.1-3ubuntu1_i386.ddeb
<bdmurray> slangasek: Martin didn't talk about it with me in December
<infinity> slangasek: You are?
<infinity> slangasek: Honestly, I'm not sure there was a formal handoff, but I think you, me, and Colin sort of own it, ish.
<infinity> slangasek: Colin stepped up recently for another thing involving it.
<infinity> slangasek: Also, "do something about" them in what sense?
<slangasek> infinity: download those files and see
<slangasek> :)
<slangasek> infinity: I don't think I know which machine ddebs.u.c runs from
<infinity> slangasek: germanium.
<slangasek> ah yes
<infinity> Oh, I see.  LP timeout.  Pretty.
<slangasek> infinity: so the two things here are a) fix importer to notice launchpad is erroring and not import an error page instead of a ddeb, 2) reimport those bogus files
<infinity> Reimporting them will be fun.
<infinity> You'll have to clean the cache in between.
<slangasek> that cache is where?
<infinity> A fine question.
<infinity> Also, when I say "clean cache", I mean carefully clean it with apt-ftparchive, not delete it.
<infinity> Cause regenerating a-f caches from scratch is very unfun.
<slangasek> right
<slangasek> $ du -sh www/.cache/db
<slangasek> 6.5G	www/.cache/db
<slangasek> $
<infinity> That'd be it.
<slangasek> what's not to love about regenerating that
<infinity> So, ddeb-retriever does a-f cleans occasionally, I think.
<infinity> Or maybe he never got around to writing that bit.
<infinity> Possibly that bit was never written.
<infinity> Which would mean those caches are probably a bit chubby.
<infinity> The fun never ends.
<infinity> There's a clean.conf in www though, maybe it was being run by hand.
<infinity> I'm beginning to understand why there might be a local copy of db5.1-utils in ~/bin/
<cjwatson> Probably need to fix ddeb-retriever to urlretrieve to a tempfile and only move into place if it succeeds.  Or use an interface less crap than urllib.urlretrieve.
#ubuntu-release 2017-05-18
<slangasek> blah, any reason not to bump ddeb-retriever to python3 at the same time?
-queuebot:#ubuntu-release- Unapproved: dogtag-pki (zesty-proposed/universe) [10.3.5+12-3ubuntu1 => 10.3.5+12-3ubuntu2] (no packageset)
<acheronuk> apw or other release team member: could you please force-badtest kcalutils/4:16.04.3-0ubuntu1, kdepimlibs/4:16.04.3-0ubuntu1, kdepim-runtime/4:16.04.3-0ubuntu3 and libkf5libkdepim/4:16.04.3-0ubuntu1
<acheronuk> those 16.04 sources are being replaced and are never intended to build again, ever
<acheronuk> and are blocking KDE frameworks currently http://gpul.grupos.udc.es/ka-iron-hand_reports/frameworks_archive/5.34_artful_proposed_migration.pdf
<apw> acheronuk, looking
<apw> acheronuk, done
<acheronuk> apw: thanks :)
<acheronuk> apw: apologies. libkf5pimcommon/4:16.04.3-0ubuntu1 got missed on that list :/
<acheronuk> too many things with similar names!
<apw> acheronuk, done
<acheronuk> TY
<ginggs> hi, would someone please remove 64-bit binaries of pixbros and pixfrogger from artful? packages have been changed from arch:all to only 32-bit
<ginggs> also, please update force-badtest from r-cran-dplyr/0.5.0-1 to r-cran-dplyr/0.5.0-1ubuntu2/armhf in p.ittie's hints file
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-79.100] (core, kernel)
<slangasek> xnox: LP: #1691727> tedious
<ubot5> Launchpad bug 1691727 in language-pack-touch-zh-hant (Ubuntu) "[RM] Remove touch language-packs, obsolete product" [Undecided,Triaged] https://launchpad.net/bugs/1691727
<xnox> slangasek, i provided copy and paste command, no?
<slangasek> xnox: yes, but I don't run those and I have a policy of recording the removal output in the bug for each removal
<xnox> ah
<xnox> ok
<slangasek> and closing the bug tasks would alone have been tedious :)
 * xnox opened the bug tasks with lp-shell
<xnox> slangasek, can we not script all that?
<slangasek> probably, but we haven't
<slangasek> by rights, remove-package probably wants an --lp option or something
<xnox> --fixes lp:1 ?
<xnox> i think --lp picks which launchpad instance to operate on (dogfood, beta, production)
<slangasek> sure, maybe
-queuebot:#ubuntu-release- New binary: node-builtin-status-codes [amd64] (artful-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-parse-type [amd64] (artful-proposed/universe) [0.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-vinyl-sourcemaps-apply [amd64] (artful-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: traildb [amd64] (artful-proposed/universe) [0.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quorum [amd64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (yakkety-proposed) [1:3.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-builtin-status-codes [amd64] (artful-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-parse-type [amd64] (artful-proposed) [0.3.4-2]
-queuebot:#ubuntu-release- New: accepted traildb [amd64] (artful-proposed) [0.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted node-vinyl-sourcemaps-apply [amd64] (artful-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted quorum [amd64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.10 => 1.157.11] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (zesty-proposed) [15.0.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (yakkety-proposed) [14.2.2-0ubuntu0.16.10.2]
<bdmurray> slangasek: Is the test case for bug 1690992 forthcoming?
<ubot5> bug 1690992 in network-manager (Ubuntu) "fix for bug #1569649 left NetworkManager-wait-online disabled on some systems" [Undecided,Fix released] https://launchpad.net/bugs/1690992
<slangasek> bdmurray: yes but probably not today
<slangasek> bdmurray: also it won't be a very good test case since I don't have any specific reproducer for the knock-on problems in zesty
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (zesty-proposed) [2.0.7-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (yakkety-proposed) [2.0.7-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-proposed) [2.0.7-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (zesty-proposed) [2.16.2-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (yakkety-proposed) [2.16.2-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (xenial-proposed) [2.16.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.6 [source] (zesty-proposed) [9.6.3-0ubuntu0.17.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (yakkety-proposed) [9.5.7-0ubuntu0.16.10]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.7-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: rejected dogtag-pki [source] (zesty-proposed) [10.3.5+12-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (xenial-proposed) [3.18.5.2-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.21~16.04.1]
#ubuntu-release 2017-05-19
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.7-0ubuntu1~16.04.2 => 2.0.8-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.7-0ubuntu1~16.10.2 => 2.0.8-0ubuntu1~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (zesty-proposed/main) [2.0.7-0ubuntu2 => 2.0.8-0ubuntu1~17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: pglogical [amd64] (artful-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [ppc64el] (artful-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [i386] (artful-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [s390x] (artful-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [armhf] (artful-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [arm64] (artful-proposed/universe) [2.0.0-1] (no packageset)
<LocutusOfBorg> Laney, question: I see a lot of "test in progress" on i386, but nothing on running, should I retry all of them?
<LocutusOfBorg> stuff 8 days old
<LocutusOfBorg> hello btw :)
<Laney> hello
<Laney> LocutusOfBorg: do you have an example?
<LocutusOfBorg> looking at artful excuses, search for "i386: test in progress" and start from the end
<LocutusOfBorg> "autopkgtest for magnum/4.1.1-0ubuntu1: amd64: Pass, i386: Test in progress"
<LocutusOfBorg> 7 days ago, sqlalchemy (1.0.14+ds1-1ubuntu1 to 1.1.9+ds1-0ubuntu2)
<Laney> magnum {"triggers": ["sqlalchemy/1.1.9+ds1-0ubuntu2"]}
<Laney> it's being ground through afaics
<LocutusOfBorg> yes, actually the one 8 days old mentioned above was not on i386, my bad
<LocutusOfBorg> autopkgtest for konqueror/4:16.12.3-0ubuntu1: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Test in progress (always failed), s390x: Test in progress (always failed)
<LocutusOfBorg> for xorg-server
<LocutusOfBorg> seems to have been removed, or something like that?
<Laney> doesn't exist on those arches
<Laney> probably shouldn't be requested, but not causing a problem in this case
<LocutusOfBorg> thanks
<Laney> that didn't happen for other konqueror requests in excuses
<Laney> so something did go wrong
<Laney> weird!
<Laney>  konqueror      | 4:16.04.3-0ubuntu1 | artful/universe | arm64, ppc64el, s390x
<Laney> it's built from kde-baseapps
-queuebot:#ubuntu-release- Unapproved: apt (zesty-proposed/main) [1.4 => 1.4.4~17.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.20 => 1.2.23] (core)
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3.5 => 1.3.8] (core)
<apw> Laney, some of that kde stuff is being split from older sources into smaller multiple ones, no idea if that is one of them
<Laney> looks like it
<Laney> I don't quite understand why some of the requests in excuses have s390x/ppc64el and some don't
<LocutusOfBorg> maybe they have been built/failed and then never picked up again?
<Laney> If there was a request created you'd see it on excuses
<apw> Laney, some of the newer packages don't build on some arches because tey gained new build-deps upstream which are limited arches
<apw> dunno if that relates ... perhaps acheronuk can shed some light
<Laney> apw: See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kbookmarks vs http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kinit
<Laney> konqueror, same version, second one has s390x/ppc64el requests
<apw> Laney, that indeed does seem to be anomolous
<Laney> dem cosmic rays
<ginggs> morning! would someone please remove 64-bit binaries of pixbros and pixfrogger from artful? packages have changed from arch:all to 32-bit only
<ginggs> also, please update force-badtest from r-cran-dplyr/0.5.0-1 to r-cran-dplyr/0.5.0-1ubuntu2/armhf in p.itti's hints file
<acheronuk> apw: at the moment no light to shed. that as Laney says, is just 'weird'
<wgrant> sil2100: For https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1674399, am I OK to upload the -proposed regression fix to xenial/yakkety/zesty?
<ubot5> Ubuntu bug 1674399 in openssl (Ubuntu Zesty) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,Fix committed]
<sil2100> wgrant: hey! You mean uploading a new one that's fixing the issues the previous upload introduced?
<sil2100> wgrant: yes, that should be fine, just give me a poke once those land in the queues
<wgrant> sil2100: Yep, just the two line patch that I've tested on the affected hardware.
<wgrant> Thanks, will do.
-queuebot:#ubuntu-release- Unapproved: openssl (xenial-proposed/main) [1.0.2g-1ubuntu4.7 => 1.0.2g-1ubuntu4.8] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (yakkety-proposed/main) [1.0.2g-1ubuntu9.2 => 1.0.2g-1ubuntu9.3] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (zesty-proposed/main) [1.0.2g-1ubuntu11.1 => 1.0.2g-1ubuntu11.2] (core)
<wgrant> sil2100: All three are there with diffs.
<sil2100> wgrant: excellent, let me take a look at those
<wgrant> sil2100: To be clear, I've run the test suite on i386 and amd64 on Ryzen, and verified that OpenVPN (which exercises the broken code path) works again.
<wgrant> The other codepaths that are newly enabled on Ryzen are well-tested. This one's only broken because Intel went all weird and still haven't added sha-ni to their big cores for some reason.
<wgrant> So due to the combination of Intel being silly and the feature check not working on AMD CPUs, the code only operated on Intel Apollo Lake.
<wgrant> Which like nobody uses.
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (zesty-proposed) [1.0.2g-1ubuntu11.2]
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (yakkety-proposed) [1.0.2g-1ubuntu9.3]
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (xenial-proposed) [1.0.2g-1ubuntu4.8]
-queuebot:#ubuntu-release- Unapproved: python-os-brick (yakkety-proposed/main) [1.6.1-0ubuntu1.2 => 1.6.1-0ubuntu1.3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gnome-software [ppc64el] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-software [i386] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-software [s390x] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-software [amd64] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-software [arm64] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-software [armhf] (artful-proposed/main) [3.24.3-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: linux-caracalla (xenial-proposed/primary) [4.4.0-2002.2]
-queuebot:#ubuntu-release- New: accepted linux-caracalla [sync] (xenial-proposed) [4.4.0-2002.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-53.56~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-79.100]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-53.56]
-queuebot:#ubuntu-release- New: accepted gnome-software [amd64] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-software [armhf] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-software [ppc64el] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted pglogical [amd64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical [armhf] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical [ppc64el] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-software [arm64] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-software [s390x] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted pglogical [i386] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-software [i386] (artful-proposed) [3.24.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted pglogical [s390x] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical [arm64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (xenial-proposed) [1.2.22]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20170509.0.8292905-0ubuntu1~xenial1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20170509.0.8292905-0ubuntu1]
<slangasek> cyphermox: LP: #1684341> does this change drop installation of fb.efi entirely?  Are you planning to reintroduce fb installation later?
<ubot5> Launchpad bug 1684341 in grub2 (Ubuntu Zesty) "EFI fallback binary should not be installed in --removable mode" [Critical,In progress] https://launchpad.net/bugs/1684341
<cyphermox> not reintroducing for SRUs, no
<slangasek> ah
<cyphermox> or at least, not yet, needs more brainpower.
<slangasek> well, ok
<cyphermox> but yeah, right now, just dropping the fallback, it would have been missing boot.csv anyway
<slangasek> if it were going to be reintroduced, I would ask for a smaller diff because it seems we'd just be reverting most of these changes later
<cyphermox> it was an addition to begin with
<slangasek> yeah, but smaller SRU diffs later would tend to go more easily
<cyphermox> yes
<cyphermox> it would be a tiny diff to reintroduce if done properly
<slangasek> do we need to worry about any cleanup on upgrade for users who *did* get fb.efi installed?
<cyphermox> but I do not think reintroducing it is worth the trouble
<slangasek> I think the situation now is that users who had the previous SRU installed will wind up with a stale fb.efi on disk
<cyphermox> slangasek: zesty at least handles that removal/migration
<slangasek> which will therefore not be signed with the right ephemeral key?
<slangasek> zesty handles> but the SRU to xenial doesn't
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (zesty-proposed/main) [1:17.04.7 => 1:17.04.8] (core)
<cyphermox> I wasn't sure
<cyphermox> we don't care about the key, since that fb is not in the right location anyway
<cyphermox> so, in that case, yeah it should include the removal in the xenial SRU too
<slangasek> ok, shall I reject this and let you reupload?
<cyphermox> yes please.
<cyphermox> please leave grub2-signed; no sense in rejecting that since it will remain the same
<slangasek> indeed
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
<slangasek> tjaalton: libxfont, thanks for the changes, accepting now - will we get build tests of the packages in xenial that currently build-depend ond libxfont-dev but aren't being updated? (mtools, xfonts-utils)
<tjaalton> slangasek: yeah that's missing from the sru bug
<tjaalton> and thanks
<tjaalton> I'll add a note
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.9 => 2.02~beta2-36ubuntu3.10] (core)
<tjaalton> slangasek: actually, xfonts-utils needs to build-depend on libxfont1-dev then
<slangasek> tjaalton: perfect, I trust you'll add that to the SRU
-queuebot:#ubuntu-release- Unapproved: accepted libxfont [source] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
<tjaalton> done
-queuebot:#ubuntu-release- New binary: libxfont [s390x] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [amd64] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [ppc64el] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [i386] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [powerpc] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [arm64] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxfont [armhf] (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted libxfont [amd64] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [armhf] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [powerpc] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [s390x] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [arm64] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [ppc64el] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont [i386] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (artful-proposed/main) [3.24.2-0ubuntu2] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (artful-proposed) [3.24.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libxfont2 [source] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: libxfont2 [ppc64el] (xenial-proposed/none) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [s390x] (xenial-proposed/none) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [amd64] (xenial-proposed/none) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [i386] (xenial-proposed/none) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [arm64] (xenial-proposed/main) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [powerpc] (xenial-proposed/main) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxfont2 [armhf] (xenial-proposed/main) [1:2.0.1-3~ubuntu16.04.1] (no packageset)
<flocculant> infinity: earlier this week I saw you and slang asek talking about 16.04 point releases and wiki - are they actually listed somewhere - cos all the wikis ... :(
<slangasek> flocculant: https://wiki.ubuntu.com/<FullReleaseName>/ReleaseSchedule
<slangasek> e.g. https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
<flocculant> slangasek: ack - so no dates going forward yet then - which was what I was trying to get a handle on, I assume there'll be a .3 soonish
 * flocculant wishes for a big release wiki :)
<slangasek> right; the milestone dates should be set there and in https://launchpad.net/ubuntu/xenial, I guess infinity hasn't gotten that done yet
<flocculant> slangasek: okey doke that's cool actually - hadn't really caught on to the dates being there on lp
-queuebot:#ubuntu-release- New: accepted libxfont2 [i386] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [s390x] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [ppc64el] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [amd64] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [armhf] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [arm64] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted libxfont2 [powerpc] (xenial-proposed) [1:2.0.1-3~ubuntu16.04.1]
#ubuntu-release 2017-05-20
<slangasek> cyphermox: this hard-codes fbx64.efi, is that correct?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.10]
<slangasek> cyphermox: seems grub2 also needs a reupload for yakkety, same reason?
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.3]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.9 => 2.02~beta2-36ubuntu3.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.10 => 2.02~beta2-36ubuntu3.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
 * apw hopes that is a double burp by queuebot rather than a race
<slangasek> cyphermox: LP: #1692181; fixing up shortly
<ubot5> Launchpad bug 1692181 in grub2 (Ubuntu) "bash syntax error in the postinst script" [Critical,Confirmed] https://launchpad.net/bugs/1692181
<Bashing-om> slangasek: :) seen it twice in #ubuntu channel .
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.10 => 2.02~beta2-36ubuntu3.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.10 => 1.66.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.11]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.11 => 2.02~beta2-36ubuntu3.11] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.11 => 2.02~beta2-36ubuntu3.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
<xnox> snapd regressed, but i can't even tell what the failure is from the log. Can anybody help?
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
<xnox> and scroll down to snapd
<infinity> xnox: "Error executing autopkgtest:ubuntu-17.10-amd64:tests/main/listing"
<infinity> xnox: Then it dumps a bunch of state.
<infinity> Which, to be fair, isn't super informative to me.
-queuebot:#ubuntu-release- New binary: libgit2 [s390x] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [i386] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [ppc64el] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [amd64] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [arm64] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [armhf] (artful-proposed/universe) [0.25.1-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libgit2 [amd64] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [armhf] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [ppc64el] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [arm64] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [s390x] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [i386] (artful-proposed) [0.25.1-2]
#ubuntu-release 2017-05-21
<apw> xnox, i think that implies that in the test environment that snap list is not listing anything ... didn't they move something recently so perhaps firewall issues
<wgrant> apw, xnox: That's because the core snapd version has changed, and the test match is too strict.
<wgrant> apw, xnox: Pretty sure that's fixed in master, but let me check.
<wgrant> s/core snapd/core snap/
<wgrant>   latest/stable:    16-2                             (1689) 83MB -
<wgrant>   latest/candidate: 16-2                             (1804) 83MB -
<wgrant>   latest/beta:      16-2.26.3                        (1961) 83MB -
<wgrant>   latest/edge:      16-2.26.3+201705191509.git.f8926 (1986) 83MB -
<wgrant> It tries to match 16-2, but that's not going to work for edge any ore.
<wgrant> Backporting 2284f51d should be sufficient.
<apw> "yay"
<wgrant> Indeed.
<wgrant> I wonder what breaks if we just upload a .1 to artful.
<apw> i am sure we throw their entire build process into kaos
-queuebot:#ubuntu-release- New binary: node-concat-with-sourcemaps [amd64] (artful-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-gulp-coffee [amd64] (artful-proposed/universe) [2.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [s390x] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [amd64] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [ppc64el] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [i386] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [arm64] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [armhf] (artful-proposed/universe) [0.4.1~git20170517.2ed5a50-1] (no packageset)
<infinity> xnox: I badtested that snapd version.
<infinity> xnox: Any ideas about docker.io hating life, since you seem to have touched the tests recently? :P
-queuebot:#ubuntu-release- Unapproved: xfonts-utils (xenial-proposed/main) [1:7.7+3 => 1:7.7+3ubuntu0.16.04.1] (core)
<xnox> yeah for systemd
<xnox> infinity, docker.io seems to be systemd fallout which now creates hybrid cgroups (both v1 and v2 mounted)
<xnox> https://github.com/opencontainers/runc/issues/1175
<xnox> there might be more k8s fixes to do as well....
-queuebot:#ubuntu-release- New binary: fdroidcl [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fdroidcl [ppc64el] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fdroidcl [arm64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fdroidcl [i386] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fdroidcl [armhf] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fdroidcl [s390x] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iannix [ppc64el] (artful-proposed/universe) [0.9.17~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iannix [s390x] (artful-proposed/universe) [0.9.17~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iannix [amd64] (artful-proposed/universe) [0.9.17~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iannix [i386] (artful-proposed/universe) [0.9.17~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iannix [arm64] (artful-proposed/universe) [0.9.17~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fdroidcl [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fdroidcl [armhf] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fdroidcl [ppc64el] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted iannix [amd64] (artful-proposed) [0.9.17~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted iannix [i386] (artful-proposed) [0.9.17~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted iannix [s390x] (artful-proposed) [0.9.17~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [arm64] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [i386] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [s390x] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
-queuebot:#ubuntu-release- New: accepted node-gulp-coffee [amd64] (artful-proposed) [2.3.4-1]
-queuebot:#ubuntu-release- New: accepted fdroidcl [arm64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fdroidcl [s390x] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted iannix [ppc64el] (artful-proposed) [0.9.17~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [armhf] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
-queuebot:#ubuntu-release- New: accepted node-concat-with-sourcemaps [amd64] (artful-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted fdroidcl [i386] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [amd64] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
-queuebot:#ubuntu-release- New: accepted iannix [arm64] (artful-proposed) [0.9.17~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libtgvoip [ppc64el] (artful-proposed) [0.4.1~git20170517.2ed5a50-1]
#ubuntu-release 2018-05-14
<tsimonq2> infinity, slangasek: One last little cleanup bit for Lubuntu Next I think: bug 1771048
<ubot5> bug 1771048 in Ubuntu CD Images "Please remove all Lubuntu Next ISOs from cdimage.u.c" [Undecided,New] https://launchpad.net/bugs/1771048
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [s390x] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [ppc64el] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [s390x] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [s390x] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chromimpute [amd64] (cosmic-proposed/universe) [1.0.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-policyfile [amd64] (cosmic-proposed/universe) [0.0.6+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [ppc64el] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [ppc64el] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [i386] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chromhmm [amd64] (cosmic-proposed/universe) [1.14+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [amd64] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feature-check [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [i386] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [i386] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [amd64] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [amd64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [arm64] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [armhf] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhubctl [arm64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: maven-jaxb2-plugin [amd64] (cosmic-proposed/universe) [0.13.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcmod [armhf] (cosmic-proposed/universe) [1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [arm64] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudsql-proxy [armhf] (cosmic-proposed/universe) [1.11+git20180420.74e2f41-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chromhmm [amd64] (cosmic-proposed) [1.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted chromimpute [amd64] (cosmic-proposed) [1.0.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [arm64] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [i386] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [s390x] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted jameica-util [amd64] (cosmic-proposed) [2.8-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [amd64] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [ppc64el] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted cloudsql-proxy [armhf] (cosmic-proposed) [1.11+git20180420.74e2f41-1]
-queuebot:#ubuntu-release- New: accepted feature-check [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted keepass2-plugin-keepasshttp [amd64] (cosmic-proposed) [1.8.4.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted maven-jaxb2-plugin [amd64] (cosmic-proposed) [0.13.3-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [armhf] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [ppc64el] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [amd64] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [armhf] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [ppc64el] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted soapaligner [amd64] (cosmic-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [amd64] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted libdata-hexdump-perl [amd64] (cosmic-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [arm64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [s390x] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [i386] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted soapaligner [i386] (cosmic-proposed) [2.20-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [armhf] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [ppc64el] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted node-policyfile [amd64] (cosmic-proposed) [0.0.6+ds-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [arm64] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [arm64] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [s390x] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted pscan-chip [i386] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted soapsnp [i386] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted python-crcmod [s390x] (cosmic-proposed) [1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted super-csv [amd64] (cosmic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted toot [amd64] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [arm64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [s390x] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted tempest-horizon [amd64] (cosmic-proposed) [0.0.1+git.2018.01.24.a23f4074fd-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted uhubctl [ppc64el] (cosmic-proposed) [2.0.0-1]
<sil2100> apw: hey! So we have that old snapd available for -updates in a/x/t - other SRU members had some doubts about if the package is ready for release or not
<sil2100> apw: could you take a look and act on it? Seeing that you're often the 'snapd SRU guy' ;)
<apw> sil2100, yeah i have my instructions on what should be done with snapd :)
<apw> sil2100, so feel free to leave that mess to me
<sil2100> apw: thanks o/
<ginggs> doko's no-change rebuild of gpaw 1.3.0-2 went to bionic instead of cosmic, can that be rejected please?
<apw> ginggs, rejected ...
 * apw wonders where queuebot is
-queuebot:#ubuntu-release- Unapproved: rejected gpaw [source] (bionic-proposed) [1.3.0-2ubuntu2]
<ginggs> apw: ta!  can i just upload the same version again now?
<apw> ginggs, yep it was only in a queue so the version is free still
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1005.8] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1005.8]
<LocutusOfBorg> libterm-filter-perl is regressed in release
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/libt/libterm-filter-perl/cosmic/arm64
<LocutusOfBorg> can we please ignore so perl becomes candidate?
<LocutusOfBorg> we have also a bug in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843052
<ubot5> Debian bug 843052 in src:libterm-filter-perl "libterm-filter-perl: FTBFS randomly (failing tests)" [Important,Open]
<slangasek> LocutusOfBorg: I see other failed tests blocking perl, what of those?  (and hint added for libterm-filter-perl)
<doko> LocutusOfBorg: are you looking at the python-numpy ftbfs?
<ginggs> slangasek: python-numpy looks like another armhf unalignmend memory access on arm64 kernel, your kind of thing? :)  I would love to know where to even start with debugging those
<slangasek> ginggs: generally the place to start on those is on a machine where you can run gdb and reproduce it
<slangasek> also, numpy hnngh
<slangasek> ginggs: if I get you a backtrace, do you want to try to take it from there? :)
<ginggs> slangasek: sure, I'll give it a go
<slangasek> doko, infinity: did someone take care of requesting the porter box chroots for cosmic?
<doko> slangasek: hmm, no, I didn't. I always was uncertain about where in the list we were for the archive opening
<slangasek> doko, infinity: RT filed.
<doko> ginggs: did you already give back the openmi triggered autopkg test failures?
<ginggs> doko: no
<ginggs> doko: i'm waiting for petsc-dev to publish then will do openmpi dependency level 6
-queuebot:#ubuntu-release- Unapproved: postgresql-9.6 (artful-proposed/main) [9.6.8-0ubuntu0.17.10 => 9.6.9-0ubuntu0.17.10] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.3 (trusty-proposed/main) [9.3.22-0ubuntu0.14.04 => 9.3.23-0ubuntu0.14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: postgresql-10 (bionic-proposed/main) [10.3-1 => 10.4-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.12-0ubuntu0.16.04 => 9.5.13-0ubuntu0.16.04] (core)
<slangasek> ginggs: I can't reproduce that particular python-numpy build failure on bionic (I get a different failure related to sphinx), so a backtrace will have to wait until I have a cosmic chroot at my disposal
-queuebot:#ubuntu-release- New binary: seafile [amd64] (cosmic-proposed/universe) [6.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libterm-readline-ttytter-perl [amd64] (cosmic-proposed/none) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-turbolinks [amd64] (cosmic-proposed/none) [5.1.1+dfsg-1] (no packageset)
<ginggs> slangasek: ok, thanks anyway
-queuebot:#ubuntu-release- New: accepted libterm-readline-ttytter-perl [amd64] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted seafile [amd64] (cosmic-proposed) [6.1.7-1]
-queuebot:#ubuntu-release- New: accepted node-turbolinks [amd64] (cosmic-proposed) [5.1.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.5]
-queuebot:#ubuntu-release- Unapproved: rejected tomcat8 [source] (bionic-proposed) [8.5.30-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (bionic-proposed) [3.28.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.30 => 2.408.31] (desktop-core)
<tsimonq2> infinity, slangasek: Could falkon please be added to the sync blacklist? Lubuntu and Kubuntu agree to jointly maintain it in Ubuntu and keep a delta until the Debian maintainer ... stops doing ... questionable things with the package that we ... disagree with.
<slangasek> tsimonq2: why does that need a sync blacklist entry though, when it's not currently in sync?
<slangasek> you can just audit the Debian changes as you merge
<infinity> ^
<jbicha> speaking of sync blacklist, is bug 1770792 useful?
<ubot5> bug 1770792 in ubuntu-meta (Ubuntu) "Clean up sync blacklist" [Wishlist,New] https://launchpad.net/bugs/1770792
<infinity> tsimonq2: It only needs to be blacklisted if we either (a) don't want the package at all, or (b) insist on maintaining it without an XubuntuX version.
<tsimonq2> I don't want anybody to mistakenly sunc it.
<tsimonq2> *sync
<tsimonq2> Perhaps publicly stating here that people should *not* sync it is enough, but sync blacklist prevents it in a technical sense (syncpackage throws it back).
<tsimonq2> I can look into merging, but Ubuntu's src:falkon was created from scratch while src:falkon in Debian is continued from src:qupzilla.
<tsimonq2> So there's no common point.
<slangasek> tsimonq2: people should not be syncing over Ubuntu deltas without knowing what they're doing anyway
<tsimonq2> slangasek: "should" and what happens isn't always the same.
<tsimonq2> I totally agree with you.
<slangasek> and I don't think the sync blacklist is the right solution for such social issues
<tsimonq2> OK.
<tsimonq2> Fair enough; thanks.
<LocutusOfBorg> doko, I asked for help on debian
<LocutusOfBorg> slangasek, I missed libio-async-loop-mojo-perl, but it is also regressed in release
-queuebot:#ubuntu-release- Unapproved: rasdaemon (artful-proposed/universe) [0.5.8-1ubuntu2 => 0.5.8-1ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rasdaemon (xenial-proposed/universe) [0.5.6-2ubuntu1 => 0.5.6-2ubuntu1.1] (no packageset)
#ubuntu-release 2018-05-15
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (bionic-proposed/main) [3.28.1-1ubuntu1 => 3.28.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.1-3build1 => 3.0.2-0ubuntu0.1] (kubuntu, mozilla)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [s390x] (cosmic-proposed/none) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [ppc64el] (cosmic-proposed/none) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [armhf] (cosmic-proposed/none) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [i386] (cosmic-proposed/none) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [arm64] (cosmic-proposed/none) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtksourceview4 [amd64] (cosmic-proposed/none) [4.0.1-1] (no packageset)
<ginggs> morning! would someone kick this along please? 'force-badtest node-chokidar/1.7.0-2/s390x' in adconrad's hints
<ginggs> and add 'force-badtest node-cache-base/0.8.4-1' I believe it has regressed in release
<apw> ginggs, how did you test it has regressed in release ?
<ginggs> apw: I triggered node-cache-base test with node-cache-base/0.8.4-1 and checked the log to make sure nothing unexpected from -proposed crept in
<ginggs> http://autopkgtest.ubuntu.com/packages/n/node-cache-base/cosmic/amd64
<ginggs> apw: also kick 'force-badtest node-platform/1.3.5-1/s390x' in adconrad
<apw> ginggs, ok done
<ginggs> apw: thanks!
 * ginggs goes to check for typos :p
<apw> i am sure there will be a number; seems there alaways is
-queuebot:#ubuntu-release- Unapproved: simbody (artful-proposed/universe) [3.5.4+dfsg-1ubuntu1 => 3.5.4+dfsg-1ubuntu1.1] (no packageset)
<sil2100> tsimonq2: all looks good with the vlc upload - I might have one small request though
<sil2100> tsimonq2: or actually, nvm
<sil2100> I wanted to ask for a version change for consistency, but I see there's actually no consistency with vlc
<sil2100> So all is good
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (bionic-proposed) [3.0.2-0ubuntu0.1]
<tsimonq2> \o/
<tsimonq2> Thanks sil2100!
 * Laney eyes sil2100 
<sil2100> W-what?!
<sil2100> Did I do some faux pas?
-queuebot:#ubuntu-release- New binary: btrfs-progs [amd64] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: python-pyalsa [ppc64el] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: btrfs-progs [s390x] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: python-pyalsa [s390x] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: btrfs-progs [ppc64el] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: btrfs-progs [arm64] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: btrfs-progs [i386] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: btrfs-progs [armhf] (cosmic-proposed/main) [4.16.1-2] (core)
-queuebot:#ubuntu-release- New binary: libtest-more-utf8-perl [amd64] (cosmic-proposed/none) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyalsa [i386] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: obantoo [amd64] (cosmic-proposed/none) [2.1.12+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jameica-datasource [amd64] (cosmic-proposed/none) [2.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyalsa [amd64] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyalsa [arm64] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyalsa [armhf] (cosmic-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bluedevil (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-grub (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-plymouth (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivitymanagerd (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-gtk-config (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-gtk (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-cli-tools (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kgamma5 (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: drkonqi (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdecoration (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khotkeys (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmenuedit (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreenlocker (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.4-0ubuntu2 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkscreen (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-integration (bionic-proposed/universe) [5.12.4-0ubuntu2 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksshaskpass (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwrited (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: oxygen (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-nm (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-vault (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreen (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libksysguard (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwayland-integration (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.4-0ubuntu3 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace-wallpapers (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: polkit-kde-agent-1 (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sddm-kcm (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: user-manager (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plymouth-kcm (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemsettings (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: powerdevil (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.5-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-kde (bionic-proposed/universe) [5.12.4-0ubuntu2 => 5.12.5-0ubuntu0.1] (kubuntu)
<acheronuk> sil2100: I feel like I should hide after doing that ^^^
<apw> acheronuk, what did you do ... /me does a sad
<tsimonq2> apw: KDE Plasma 5.12.5 point release.
<tsimonq2> MRE
<apw> shoudl be call a SME (sad-making-event)
<tsimonq2> hahahaha
<tsimonq2> I did an MRE myself today for VLC. ;)
<acheronuk> you haven't got to try to get the things validated! :P
<tsimonq2> Laney still hasn't said why he's unhappy with it. :P
<jbicha> acheronuk: don't feel sad. It's good that Kubuntu is participating in the SRU process
<jbicha> acheronuk: on the other hand, the plasma-workspace-wallpapers diff looks like a waste of timeâ¦
<jbicha> (and plymouth-kcm)
<acheronuk> jbicha: some of them are there to make the plasma release complete and less confusing for users with version numbers, and could be dropped if too much trouble
<acheronuk> as is said in the bug report
<jbicha> why would it be confusing to users?
<acheronuk> jbicha: because plasma users expect to see plasma upgrade as a full release, because of the way KDE have historically done them
<jbicha> so GNOME has some stuff at 3.28.0, some at 3.28.1, some at 3.28.2, evolution will probably get to 3.28.6â¦
-queuebot:#ubuntu-release- New binary: poco [s390x] (cosmic-proposed/universe) [1.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [ppc64el] (cosmic-proposed/universe) [1.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [arm64] (cosmic-proposed/universe) [1.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [armhf] (cosmic-proposed/universe) [1.9.0-3] (no packageset)
<tsimonq2> infinity, slangasek: Can I please get some ANAIS cleanup (on aisle 9...) for src:fallkon?
<tsimonq2> src:falkon too. :P
-queuebot:#ubuntu-release- New binary: poco [i386] (cosmic-proposed/universe) [1.9.0-3] (no packageset)
<ahasenack> hello, could someone please bring brotli from universe into main, as per MIR https://bugs.launchpad.net/ubuntu/+source/brotli/+bug/1737053 and the current apache 2.4.33 upload in cosmic-proposed?
<ubot5> Ubuntu bug 1737053 in brotli (Ubuntu) "[MIR] brotli" [Low,Fix committed]
<ahasenack> apache2-bin/amd64 unsatisfiable Depends: libbrotli1 (>= 0.6.0)
<apw> ahasenack, looking
<ahasenack> apw: thanks
<apw> ahasenack, done
<ahasenack> apw: thanks a lot
<sil2100> acheronuk: as for the kde-bits for bionic, I can get a look at those tomorrow or Thursday if no one gets to those earlier
<acheronuk> sil2100: no problem. likely to be a bit busy tomorrow, so was parking them in the queue tonight for whenever
<wxl> are the "Upgrade Ubuntu GNOME" testcases actually Ubuntu Desktop or are they just deprecated?
<jbicha> wxl: those are for Ubuntu GNOME but there is still one final point release scheduled for UG 16.04
<wxl> oh right! forgot about that jbicha.
<slangasek> tsimonq2: that doesn't look to me like it needs ANAIS cleanup, but a force hint to handle the arch:any->arch:all transition
-queuebot:#ubuntu-release- New: accepted btrfs-progs [amd64] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted btrfs-progs [armhf] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted btrfs-progs [ppc64el] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [amd64] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [armhf] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [ppc64el] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted jameica-datasource [amd64] (cosmic-proposed) [2.8.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted obantoo [amd64] (cosmic-proposed) [2.1.12+ds1-1]
-queuebot:#ubuntu-release- New: accepted poco [armhf] (cosmic-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- New: accepted poco [ppc64el] (cosmic-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- New: accepted btrfs-progs [arm64] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted btrfs-progs [s390x] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [i386] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted libtest-more-utf8-perl [amd64] (cosmic-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted poco [i386] (cosmic-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [amd64] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [armhf] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [ppc64el] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted btrfs-progs [i386] (cosmic-proposed) [4.16.1-2]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [s390x] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted poco [s390x] (cosmic-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [i386] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted gtksourceview4 [arm64] (cosmic-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [arm64] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted poco [arm64] (cosmic-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- New: accepted python-pyalsa [s390x] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New binary: astropy-regions [s390x] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [s390x] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [s390x] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [s390x] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [s390x] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [ppc64el] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [ppc64el] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [ppc64el] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [ppc64el] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-regions [ppc64el] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [ppc64el] (cosmic-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pallets-sphinx-themes [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [amd64] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-normalize.css [amd64] (cosmic-proposed/none) [8.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [amd64] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [i386] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-base58 [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-regions [i386] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-dpac [amd64] (cosmic-proposed/none) [1.0+2018.03.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [i386] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tmux-themepack-jimeh [amd64] (cosmic-proposed/none) [0+git20170413-748b16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-regions [amd64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [i386] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [amd64] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volatildap [amd64] (cosmic-proposed/none) [1.1.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [i386] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [arm64] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [amd64] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [arm64] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smenu [armhf] (cosmic-proposed/none) [0.9.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [i386] (cosmic-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [amd64] (cosmic-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goodvibes [armhf] (cosmic-proposed/none) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [arm64] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stlink [armhf] (cosmic-proposed/none) [1.5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-regions [arm64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [armhf] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cftime [arm64] (cosmic-proposed/none) [1.0.0~b1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-regions [armhf] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [arm64] (cosmic-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-abrmd [armhf] (cosmic-proposed/none) [1.3.1-1] (no packageset)
#ubuntu-release 2018-05-16
<tsimonq2> slangasek: Ah. Thanks.
-queuebot:#ubuntu-release- New: accepted astropy-regions [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted astropy-regions [armhf] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted astropy-regions [ppc64el] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted cftime [arm64] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted cftime [i386] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [amd64] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [armhf] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted node-normalize.css [amd64] (cosmic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-pallets-sphinx-themes [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted smenu [arm64] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted astropy-regions [arm64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted cftime [amd64] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted cftime [ppc64el] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [i386] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted smenu [amd64] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted smenu [i386] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted stlink [amd64] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted stlink [armhf] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted tmux-themepack-jimeh [amd64] (cosmic-proposed) [0+git20170413-748b16-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [arm64] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted astropy-regions [i386] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [arm64] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted smenu [armhf] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted stlink [arm64] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [amd64] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [i386] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted volatildap [amd64] (cosmic-proposed) [1.1.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted cftime [armhf] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted starjava-dpac [amd64] (cosmic-proposed) [1.0+2018.03.22-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [armhf] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted python-base58 [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-abrmd [ppc64el] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted stlink [i386] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted astropy-regions [s390x] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [ppc64el] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted smenu [ppc64el] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted stlink [ppc64el] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted cftime [s390x] (cosmic-proposed) [1.0.0~b1-1]
-queuebot:#ubuntu-release- New: accepted smenu [s390x] (cosmic-proposed) [0.9.12-1]
-queuebot:#ubuntu-release- New: accepted goodvibes [s390x] (cosmic-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted stlink [s390x] (cosmic-proposed) [1.5.0+ds-2]
-queuebot:#ubuntu-release- New binary: oca-core [amd64] (cosmic-proposed/universe) [11.0.20180420-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (bionic-proposed/universe) [0.94 => 0.94.1] (lubuntu)
<tsimonq2> infinity, slangasek: Can I get some help with that lubuntu-meta upload? ^
<tsimonq2> We missed a dep in the metapackage before release.
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (bionic-proposed) [0.94.1]
<tsimonq2> One additional note: I would argue for waiving the seven day aging period.
<tsimonq2> People can't use apport at the moment to report bugs.
<tsimonq2> (Not with the default suite of packages, anyway.)
<tsimonq2> Either wxl or myself can test soonish.
<wxl> thx infinity
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.32.5 => 2.32.9] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.32.5+17.10 => 2.32.9+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32.8+18.04 => 2.32.9+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.32.5~14.04 => 2.32.9~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: util-linux (artful-proposed/main) [2.30.1-0ubuntu4.1 => 2.30.1-0ubuntu4.2] (core)
-queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.5 => 2.27.1-6ubuntu3.6] (core)
-queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3 => 2.31.1-0.4ubuntu3.1] (core)
<juliank> ^ these 3 are to fix bug 1771345 so we can hopefully get bug 1732865 working
<ubot5> bug 1771345 in util-linux (Ubuntu Bionic) "lscpu possible crash in min/max frequency" [High,Triaged] https://launchpad.net/bugs/1771345
<ubot5> bug 1732865 in The Ubuntu-power-systems project "[LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies" [High,Fix committed] https://launchpad.net/bugs/1732865
<sil2100> juliank: if the vanguard doesn't take care of those today, I'll pick them up tomorrow for sure
<rbasak> juliank: how do you intend to perform SRU verification on that?
<ginggs> doko: re openmpi, see debian #896886 - and armhf doesn't look good in debian either, maintainers are doing this: https://packages.qa.debian.org/l/lammps/news/20180515T163856Z.html - fortunately there's a 3.1.0 bugfix release
<ubot5> Debian bug 896886 in src:openmpi "openmpi: upstream version 3.0.1 makes lots of autopkgtests flaky" [Normal,Open] http://bugs.debian.org/896886
<juliank> rbasak: That's a good question, I'm not sure we can actually verify anything there. But if IBM can verify 1732865, we would know it's enough. I'd treat this more as a "make code more defensive" rather than "fix concrete bug"
<juliank> Unless you have an AMD system where you can disable a CPU that produces the bug, then you're lucky
<doko> ginggs: is this disabled for the autopkg tests as well?
<juliank> or the POWER8 which apparently also does on some systems
-queuebot:#ubuntu-release- New: accepted oca-core [amd64] (cosmic-proposed) [11.0.20180420-1]
<juliank> rbasak: I guess we can also produce test cpuinfo files that trigger it, but I'm not sure how that all works
<juliank> I just thought about that now, that would have been a good way to get the other bug reproducable
<juliank> Got it
<ginggs> doko: well the ones that run tests during the build FTBFS, and the ones that run tests during autopkgtest fail there :(
<ginggs> doko: in the case of lammps, I guess it is going to fail autopkgtests once it builds
<rbasak> juliank: OK. Let me know once you've updated everything then, and I'll take another look?
<juliank> rbasak: done
<juliank> I wonder why upstream did not add a test for that to their testsuite...
<ginggs> doko: mckinstry responded on the openmpi bug
<doko> ginggs: which one?
-queuebot:#ubuntu-release- Unapproved: gnutls28 (trusty-proposed/universe) [3.2.11-2ubuntu1.1 => 3.2.11-2ubuntu1.2] (no packageset)
<juliank> um, we now have two gnutls28 3.2.11-2ubuntu1.2 in the queue for trusty, the older one should probably go away
<Odd_Bloke> rbasak: arges: The cloud-init in bionic-proposed has been verified and waiting around for a while; would one of you be able to release it?
<Odd_Bloke> dpb1: ^, FYI
<arges> Odd_Bloke: sure
<Odd_Bloke> Thanks!
<arges> Odd_Bloke: done
<Odd_Bloke> \o/
 * rbasak is still trying to figure out juliank's util-linux SRUs
<juliank> rbasak: but they're so tiny!
<juliank> :)
<rbasak> There are rather a large number of bug comments, uploads and patches for something so tiny :)
<rbasak> I like your segvtest case
<juliank> rbasak: Oh, on the IBM one, yes, but that one is just carried over from the one currently in proposed.
<rbasak> dep3 origin headers would have been nice :-/
<juliank> rbasak: Um, yeah, but I just git formatted them from the upstream repo, and quilt imported them
<juliank> and did quilt refresh
<rbasak> You can do that but still add dep3 headers
<rbasak> dep3 was designed with that use case in mind
<rbasak> Do you have a pointer to the upstream VCS please?
<juliank> it's https://github.com/karelzak/util-linux
<rbasak> Thanks
<mdeslaur> is there a publisher problem? I publish three packages 3 hours ago, and half the binary packages are still missing...
<mdeslaur> ie: http://security.ubuntu.com/ubuntu/pool/main/d/dpdk/librte-eal17.05_17.05.2-0ubuntu1.1_i386.deb
<apw> mdeslaur, half of them missing?  that seems unexpected
<cjwatson> The weekly publisher DB vacuuming has cycled round to this time of the week
<cjwatson> So it'll sort itself out once that's done
<cjwatson> half> presumably those for whichever architectures built later
<mdeslaur> thanks cjwatson
<apw> cjwatson, can we not control when that thing happens?  make it happen more and at a consistent time or something
<cjwatson> apw: infinity was going to work on that
<apw> ahh ok :)
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.6]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (artful-proposed) [2.30.1-0ubuntu4.2]
<rbasak> juliank: that was rather complicated because of the previous SRU in Xenial and the other subtle differences between the releases. Looks like you've done it all correctly though, thanks.
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.1]
<slangasek> Laney, sil2100, juliank: so now that I'm receiving emails, I notice a pattern that s390x nodes are failing much more than other architectures.  Do we know why?  Do we think this is a priority to fix?
<Laney> slangasek: I didn't look into it yet. Seems to be mostly bos01 which is new, and bos02 is working fine, so this isn't a top priority for me. Feel free to have a look though. If it were me I'd run a manual job through bos01 and see what happens.
<Laney> Congratulations on your emailhood.
<slangasek> Laney: confirmed, all the ones I'm seeing over the past 24h are bos01.  Do you think I should escalate it to axino?
<juliank> slangasek: I see a lot of instance quota exceeded
<juliank> So we should lower our number of instances or get the quota raised
<Laney> Dunno, I would find out what the problem is first.
<juliank> Apparently the quota limit is 10
<Laney> If it's quota, give that ticket a score bump
<slangasek> juliank: you don't see that in the emails, do you?  I'm not finding anything about quotas there
<juliank> and we configure 16?
<juliank> in journalctl
<slangasek> it's not clear to me that 'raise the quota' is correct here, this is bos01 that we're still doing burn-in testing on
<slangasek> and has less compute available
<Laney> We set our limits based on the compute that IS told us was there
<slangasek> ah
<juliank> but there was some miscommunication on #instances
<slangasek> ...what is this channel
<juliank> s/#/number of/
<juliank> :)
<slangasek> oh :)
<Laney> what miscommunication is that?
<Laney> there's some miscommunication if there is miscommunication that is not being communicated to the team
<juliank> Laney: with them thinking we had lower number of workers on bos02, and giving us lower limits?
<juliank> which you suggested we go higher, I don't think they actually replied to that
<Laney> oh right, I think the quota is just not set up properly yet
<Laney> that's why I suggest a score bump to get that done rather than fiddling on our side
<ginggs> doko: debian #896886
<ubot5> Debian bug 896886 in src:openmpi "openmpi: upstream version 3.0.1 makes lots of autopkgtests flaky" [Normal,Open] http://bugs.debian.org/896886
<slangasek> Laney: RT#?
<Laney> 1stuff
<Laney> slangasek: 111085
<slangasek> ticket nudged
<Laney> neat
<doko> ginggs: does 3.1 have another soname bump?
<ginggs> doko: I haven't checked, but I believe it is just bug fixes
-queuebot:#ubuntu-release- Unapproved: llvm-defaults (bionic-proposed/universe) [0.41~exp4 => 0.41~exp5~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-pip (bionic-proposed/universe) [9.0.1-2 => 9.0.1-2.3~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-os-service-types [amd64] (cosmic-proposed/main) [1.2.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.31]
<ahasenack> hi, I need some help with my apache2 migration. It's a valid candidate, but failing because of:
<ahasenack> trying: apache2
<ahasenack> skipped: apache2 (0, 56, 7)
<ahasenack>     got: 15+0: a-8:a-1:a-1:i-1:p-3:s-1
<ahasenack>     * ppc64el: libapache2-mod-proxy-uwsgi-dbg, libapache2-mod-shib2
<ahasenack> it's not ppc64 specific, I can see that in an amd64 container
<ahasenack> thing is, that problem is already the case in current cosmic
<ahasenack> libapache2-mod-shib2 wants libxmltooling7 which pulls in libcurl3
<ahasenack> instead of libcurl4
<ahasenack> and I think it's because it has to be be built against openssl1.0, not 1.1, and libcurl-openssl1.0-dev pulls in libcurl3
-queuebot:#ubuntu-release- Unapproved: clamfs (bionic-proposed/universe) [1.0.1-3build2 => 1.0.1-3build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gpsshogi (bionic-proposed/universe) [0.7.0-2build4 => 0.7.0-2build5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-class-loader (bionic-proposed/universe) [0.3.8-1build2 => 0.3.8-1build3] (no packageset)
<ahasenack> xmltooling has this as its last changelog entry:
<ahasenack>   * Switch back to openssl1.0 via newly-added libcurl-openssl1.0-dev, since
<ahasenack>     libxml-security is not ported to openssl1.1.
-queuebot:#ubuntu-release- Unapproved: sitplus (bionic-proposed/universe) [1.0.3-5.1build5 => 1.0.3-5.1build6] (no packageset)
<slangasek> ahasenack: so, what has changed in apache that would cause this to be incompatible now?  Was apache2 not already linked against openssl 1.1 in bionic?
<ahasenack> I'm seeing that in cosmic's apache, 2.4.29-1ubuntu4.1, which is the same as in bionic-updates
<ahasenack> I think what changed is libxmltooling7 being build with openssl1.0 after apache was uploaded
<ahasenack> libapache2-mod-shib2 -> libxmltooling7 -> libcurl3
<slangasek> ahasenack: that would not increase the count of uninstallable packages, which is what proposed-migration cares about
<ahasenack> xmltooling was built with openssl1.1 for a while
<ahasenack> slangasek: you mean, if this was the case before, proposed-migration would have ignored this error?
<slangasek> ahasenack: correct
<ahasenack> what is the diff now, is it exactly libapache2-mod-proxy-uwsgi-dbg and libapache2-mod-shib2?
<ahasenack> and apache didn't change, I'm seeing libapache2-mod-shib2 not being installable in normal cosmic. I think what changed is xmltooling7, as that would not try to install apache to test
<ahasenack> I mean, would the xmltooling7 migration test that libapache2-mod-shib2 is installable?
<slangasek> it would, yes
<ahasenack> well, it isn't
<slangasek> ahasenack: in cosmic, libapache2-mod-shib2 is installable (though not coinstallable with other things)
<ahasenack> like apache itself :)
<slangasek> ahasenack: in cosmic-proposed, it is not installable because apache2-bin now depends on libcurl4 where it did not previously
<ahasenack> oh, hm
<ahasenack> ok, that gives me enough to go on
<ahasenack> thanks
-queuebot:#ubuntu-release- Unapproved: rejected clamfs [source] (bionic-proposed) [1.0.1-3build3]
-queuebot:#ubuntu-release- Unapproved: rejected ros-class-loader [source] (bionic-proposed) [0.3.8-1build3]
-queuebot:#ubuntu-release- Unapproved: rejected gpsshogi [source] (bionic-proposed) [0.7.0-2build5]
-queuebot:#ubuntu-release- Unapproved: rejected sitplus [source] (bionic-proposed) [1.0.3-5.1build6]
<ahasenack> slangasek: ok, it's this new experimental module that is enabled by default: https://httpd.apache.org/docs/2.4/mod/mod_md.html
<ahasenack> slangasek: so my choices are disabling it (adding a delta with debian) or getting libxmltooling7 to use libcurl4 instead of libcurl3, I think
<ahasenack> or something more complicated
<ahasenack> and we have libapache2-mod-md in the archive already, from somewhere else
 * ahasenack will think about this
<slangasek> ahasenack: nothing is more complicated than getting libxmltooling7 to use libcurl4
<ahasenack> I see
<slangasek> what about splitting mod_md out into a separate binary package?  I don't see why a new experimental module should cause the apache core packages to depend on libcurl
<ahasenack> it's a module we have already in the archive at an older version, as a source package, just like debian
<ahasenack> so maybe to that, split it out (as it's already like this in a way)
<ahasenack> and obsolete the old mod-md source
<ahasenack> it will just add to the debian delta, though
<ahasenack> I was about to check what debian does with libxmltooling7
<ahasenack> oh, wait a sec
<slangasek> libxmltooling7 has a horrible dependency tree of xmlsec stuff that needs upstream porting to openss1.1 before that stack can be switched
<ahasenack> huh, in debian libcurl.so.4 is in the libcurl3 package
<ahasenack> lrwxrwxrwx 1 root root 12 Jan 24 20:27 /usr/lib/x86_64-linux-gnu/libcurl.so.3 -> libcurl.so.4
<ahasenack>  weirddd...
<slangasek> it's because a determination was made that it shouldn't be considered an ABI break for Debian even though upstream considered it one
<ahasenack> in or case, we can't install libcurl3 simultaneously with libcurl4, we have an explicit conflicts
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
<slangasek> yes
<slangasek> basically the same thing that Debian is meant to have soonish
<ahasenack> hm, in ubuntu we do something similar in libcurl3-gnutls. It includes this symlink: libcurl-gnutls.so.3 -> libcurl-gnutls.so.4
<ahasenack> curl sounds like a complicated package
<infinity> "Complicated" is a very kind description.
<tsimonq2> infinity, slangasek: Moar Lubuntu Classic cleanup:  https://code.launchpad.net/~wxl/ubiquity-slideshow-ubuntu/delete-lubuntu/+merge/345637
-queuebot:#ubuntu-release- Unapproved: x11-xkb-utils (bionic-proposed/main) [7.7+3 => 7.7+3ubuntu1] (desktop-core)
<slangasek> tsimonq2: merged
<slangasek> and uploaded
<tsimonq2> Thanks!
<tsimonq2> wxl: ^
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
<slangasek> Laney, sil2100, juliank: hmmm, mininet/i386 autopkgtests are failing with timeouts; that's irritating and I'm investigating, but what's surprising is they're allowed to take 6h to time out instead of 10000s, has anything changed in configs?  http://autopkgtest.ubuntu.com/packages/m/mininet/cosmic/i386
<juliank> slangasek: hmm
<slangasek> juliank: probably not a recent config change, looking at bionic history I see a similar timeout from 17Apr
<juliank> slangasek: it timed out properly after 10k seconds, but it took 3 hours to clean up the instance
<juliank> autopkgtest [13:47:34]:  test simpe: [
<juliank> autopkgtest [16:34:14]: ERROR: timed out
<slangasek> oh fun
<juliank> autopkgtest-virt-ssh [19:54:14]: ERROR: Removing temporary files on testbed timed out
<slangasek> so where does that timeout need to be lowered? ;)
<juliank> slangasek: It's supposed to be a 300s timeout in AUTOPKGTEST_VIRT_COPY_TIMEOUT in VirtSubproc.p
<juliank> y
<juliank>         if cleanup_paths:
<juliank>             VirtSubproc.check_exec(['rm', '-rf'] + cleanup_paths, downp=True,
<juliank>                                    timeout=VirtSubproc.copy_timeout)
<juliank> though for that only
<juliank> it also calls VirtSubproc.downtmp_remove() before that
<juliank> but that should have the same timeout
<juliank> Maybe we increased AUTOPKGTEST_VIRT_COPY_TIMEOUT somewhere?
<juliank> ok, that one is set from --timeout-copy apparently
<juliank> which is nuts, because we pass --timeout-copy=6000
<slangasek> 6000s seems a bit excessive :)
<juliank> so we have 1.6 hours to remove downtmp, and then 1.6 hours to remove cleanup_paths
<slangasek> dates to the origin of the git repo, so no particular rationale there
<juliank> my suggestion: https://paste.ubuntu.com/p/j7fWRBmZzY/
<slangasek> I think the copy timeout should also be lowered, though certainly we should have a different timeout value for removal vs copying
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.10 => 0.103ubuntu4.11] (core)
<slangasek> ototh why is 'ssh rm -rf [...]' hanging for 1h?  do we have some terrible retry handling in there?
<juliank> does not seem like it
<juliank> but there's some weird wrapper that kills processes
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20180129+dfsg1-0ubuntu1~17.10.0 => 20180510+dfsg1-0ubuntu2~17.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180129+dfsg1-0ubuntu1~16.04.0 => 20180510+dfsg1-0ubuntu2~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180129+dfsg1-0ubuntu3 => 20180510+dfsg1-0ubuntu2~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
<slangasek> jbicha: it appears network-manager-gnome has now migrated from libappindicator to libayatana-appindicator.  The libappindicator package in main was owned by ~dx-packages, which is effectively no more; do you know if ubuntu-desktop means to own ayatana-appindicator?
<jbicha> slangasek: I pinged seb128 about that this week and it's on his todo list to look into that MIR
<slangasek> jbicha: I wouldn't expect to need an MIR since this is effectively a package rename and a straight swap in main, but I do need to know what team will own maintenance
<jbicha> could you follow up with Seb about that?
<slangasek> provided I catch him on IRC :)
<xnox> slangasek, there is s390x in bos01?! news to me.
<slangasek> xnox: yes; it's the new bos01
<xnox> cool.
<wxl> infinity et al are multiple verifications required for https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1764399 or are we good to go? i've changed verification-needed-bionic per the instructions but did not change verification-needed.
<ubot5> Ubuntu bug 1764399 in lubuntu-meta (Ubuntu Cosmic) "running apport in terminal doesn't work, as python3-launchpadlib is not installed by default in Lubuntu Bionic" [Critical,Fix committed]
<bdmurray> wxl: verification-needed doesn't actually do anything
<wxl> bdmurray: okie dokie. do i need to round up additional testers?
<bdmurray> the description talks about crash reports but apport-collect is for bug reports
<bdmurray> Anyway, enough being pedantic. It seems straight forward no additional testing is needed.
<wxl> i blame tsimonq2 :)
-queuebot:#ubuntu-release- New binary: rustc [i386] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
<slangasek> ginggs: if you would like a SIGBUS to diagnose, seqan2's current build failure /is/ reproducible with bionic: https://paste.ubuntu.com/p/NVHbJhfstC/
-queuebot:#ubuntu-release- New binary: rustc [armhf] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: gitless [amd64] (cosmic-proposed/universe) [0.8.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hbci4java [amd64] (cosmic-proposed/universe) [3.0.15+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gitless [amd64] (cosmic-proposed) [0.8.6-1]
-queuebot:#ubuntu-release- New: accepted hbci4java [amd64] (cosmic-proposed) [3.0.15+dfsg-2]
#ubuntu-release 2018-05-17
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-os-service-types [amd64] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
-queuebot:#ubuntu-release- New binary: python-zunclient [amd64] (cosmic-proposed/universe) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ssh-import-id (bionic-proposed/main) [5.7-0ubuntu1 => 5.7-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180129+dfsg1-0ubuntu1~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.0] (ubuntu-cloud)
<tsimonq2> cjwatson, slangasek: So, I want to make a change (well, propose one) to debian-cd for some adjustments in Lubuntu's image. However, I don't see tools/boot/cosmic to be able to edit... can I get a hand please? (Probably needs copying over or something.)
<tsimonq2> Namely, I want to add Lubuntu to the conditionals on lines 422 and 453.
<tsimonq2> (of "bionic/boot-amd64")
<tsimonq2> ((soon to be "cosmic/boot-amd64"))
<slangasek> tsimonq2: pushed the prod branch to the public branch now
<tsimonq2> slangasek: Thanks!
<tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/+merge/345717
<tsimonq2> slangasek: It's unclear to me if doing an MP that way is the right workflow, but feel free to grab my diff nonetheless.
<tsimonq2> slangasek: (Assuming it looks sane to you, ofc.)
<tsimonq2> Uhh, that looks messy.
<tsimonq2> This: https://bazaar.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/revision/1993
<tsimonq2> For future ref, what's the Right Thing here?
<krytarik> tsimonq2: Wrong MP target, should be "debian-cd/ubuntu" instead.
-queuebot:#ubuntu-release- Unapproved: ssh-import-id (bionic-proposed/main) [5.7-0ubuntu1 => 5.7-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
<slangasek> cjwatson: is it time to unblacklist ghc/haskell?
<ginggs> slangasek: thanks, I'll look at seqan2
 * sil2100 is reviewing the KDE stack for bionic now
<wxl> sil2100: any chance of waiving the minimum aging on https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1764399 ?
<ubot5> Ubuntu bug 1764399 in lubuntu-meta (Ubuntu Cosmic) "running apport in terminal doesn't work, as python3-launchpadlib is not installed by default in Lubuntu Bionic" [Critical,Fix committed]
<sil2100> wxl: looking
<wxl> sil2100: thx
<sil2100> wxl: what about cosmic? Has the dependency been added there already?
<wxl> sil2100: yes, cosmic was already resolved. we did some drastic changes to our cosmic seed as a result of switching from lxde to lxqt and managed to resolve that in the process.
<sil2100> Ok
<sil2100> wxl: I don't see any direct dependency for launchpadlib there, I assume it's pulled in through dependencies though? Anyway, just make sure the same issue doesn't appear in cosmic - I'll release the bionic SRU now
<wxl> sil2100: yeah, if you check the manifest it's on there. one of the "drastic changes" is also not excluding recommends, so that kind of helps. thank you!
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<sil2100> acheronuk[m]: hey! You around?
<sil2100> acheronuk[m]: I'm reviewing the KDE bionic SRUs now - there's a lot of packages that have only a version bump and/or only translation fixes in them
<sil2100> acheronuk[m]: since those are basically governed by your team - do you want those to all go in with the update?
<sil2100> acheronuk[m]: I'm asking since there's no real blocker for getting those in and I guess that's what we did for zesty (and all is super fine with that), but accepting even those no-change uploads does always generate an update for the user in the end
<sil2100> acheronuk[m]: not a big deal, but users will have to download packages and update even if the actual contents did not change
<sil2100> acheronuk[m]: so question: is that something you're concerned about as a flavour or not?
<acheronuk> sil2100: I would prefer users to see Plasma as a whole update, rather than just some packages and not others. especially where they have had version updates from us in the past via our PPAs, that is what they expect to see, and what tends to happen elsewhere
<sil2100> acheronuk: that's fine with me then
<sil2100> Thanks!
<acheronuk> thank you!
<seb128> acheronuk, do you get each package to go through testing/SRU verification?
<seb128> because even no change rebuild can contain issues, sometime toolchain or something else changed since the previous build
<seb128> it seems tedious to test a stack of packages just to bump a changelog :/
-queuebot:#ubuntu-release- Unapproved: accepted drkonqi [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
<sil2100> Yeah, every package needs to be tested, I guess that's one of the reason why verification of KDE updates always takes so long
<sil2100> I remember the zesty one hanging around for quite a while
<acheronuk> hopefully will be quicker this time
<sil2100> acheronuk: ok, so the decision to accept them all still stands, right? Just making sure ;)
<seb128> (seems a waste of mirrors/user data/testing resources from here, just to bump a changelog version :/)
<acheronuk> sil2100: yeah. dependencies (build and otherwise) have been set so we could abandon the not strictly bug fix updates should that become the better option
<sil2100> acheronuk: so maybe let's do it like this for now, some middle grounds - I'll be accepting those that have only translation updates but not those that just bump the changelog, we can decide later how many of those are there and if it really makes sense to have those
<sil2100> Translation updates are anyway something we'd like before .1
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<acheronuk> sil2100: sounds reasonable.
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<cjwatson> slangasek: I blacklisted ghc/haskell on request; LocutusOfBorg, can you comment on whether it can be unblacklisted now?  (presumably it'd want to be "controlled sync of at least the first few layers and then unblacklist", to avoid unnecessary rebuilds)
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<LocutusOfBorg> cjwatson, I asked if I could manually sync ghc few days ago
<Laney> juliank / sil2100: either of you got any spare time to look into bos01/s390x?
<LocutusOfBorg> so, I agree with you, please let me manually do this stuff
<Laney> things seem to be dying in weird ways
<juliank> they are?
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ tail -1 /tmp/autopkgtest-work.kevt6uoh/out/log
<LocutusOfBorg> [10:11:40] <LocutusOfBorg> Release Team, the Debian haskell transition should be mostly over, and I would like to drop llvm 3.7 from our world...
<LocutusOfBorg> [10:12:09] <LocutusOfBorg> can you please tell me when it is convenient to do my manual syncs? (please don't whitelist it right now, I prefer to sync in the right order to avoid useless rebuilds and infra time)
<Laney> tar: ./debian/.debhelper/libkf5kiofilewidgets5/dbgsym-root/usr/lib/debug/.build-id/f1/e44922cfe0fa00af06436c65a97c5403912ac0.debug: Wrote only 2560 of 10240 bytes
<Laney> or just hanging or whatever
<LocutusOfBorg> this was my request, so let me sync it *now*
<LocutusOfBorg> (you will need to process some haskell new queue, new packages might be around 10~15
<cjwatson> LocutusOfBorg: this sounds like consensus that you can go ahead, to me :)
<LocutusOfBorg> syncpackage: Error: Source package ghc is blacklisted.
<LocutusOfBorg> can you pleeeeeeeeeeeeeeease :) ?
<cjwatson> that's what copy-package is for
<LocutusOfBorg> ack
<LocutusOfBorg> sounds good to me
<sil2100> Laney: I could take a look after my sru shift
<sil2100> Laney: ah, it's the thing Steve mentioned, right?
<cjwatson> just remember that you need to explicitly copy to cosmic-proposed
<Laney> dunno
<cjwatson> or you could locally hack the blacklist check out of syncpackage if you prefer
<LocutusOfBorg> 	ghc 8.2.2-3 in sid
<LocutusOfBorg> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
<LocutusOfBorg> Copy [y|N]? y
<LocutusOfBorg> 1 copy requested.
<LocutusOfBorg> nah, done! thanks!
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/ghc/8.2.2-3
<LocutusOfBorg> it is there...
 * LocutusOfBorg hides in a cave
<Laney> juliank / sil2100: filed https://trello.com/c/WnlpdF4t/16-investigate-bos01-s390x-instances-not-working-properly
 * Laney goes back to meson.build :-)
<seb128> looks like the gnome-software bionic SRU was missing the SRU info on one of the bugs and that has been fixed now, should be good to re-review/let in
<juliank> odd
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<sil2100> seb128: thanks! I'll look at it once I go through those KDE packages
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<juliank> Laney, sil2100 I'm rerunning the kio test in debug, and I can notice that the open takes about 20 seconds, but it does not hang indefinitely.
<juliank> Let's wait for it to finish
<Laney> look in the journal
<Laney> you can see tons of bos01-s390x-* dying
<juliank> yes
<juliank> Well no, i don't see them dying
<juliank> but i might be missing the lines where they do
<sil2100> acheronuk: looking at plasma-desktop, a bit curious why the build-dependency to breeze-dev has been bumped, since actually the breeze package had only translation updates
<sil2100> acheronuk: do you know?
<juliank> oh I see, there are no error messages inside the testbed, they just stop
<Laney> you don't always get the end of the log for some reason
<juliank> Should we systemctl stop autopkgtest@bos01-s390x-*.service them for now?
<sil2100> acheronuk: hope nothing went missing from the breeze upload in that case? Since build-depends are usually bumped if we're actually depending on something from the newer version
<Laney> juliank: can do, & disable or the script will bring them back
<acheronuk> sil2100: because the cmake in plasma-desktop looks for an internally versioned breeze build dep of the same version
<Laney> if it ends up being disabled for a while, I'd document that cowboy in the local config-changed copy on the node
<seb128> thx Lucasz :)
<acheronuk> sil2100: if it doesn't find it, it doesn't set the breeze window deco as the default for the build
<sil2100> acheronuk: ah, good to know!
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<acheronuk> sil2100: the build deps I did bump were as a result of seeing what went missing in my staging builds, and correcting those
<juliank> Laney: done that. we also might want to try just starting less workers and see if that helps things, maybe it's overloaded somehow
<Laney> could be, that short write looks suspicious
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<sil2100> acheronuk: ok, I guess I approved all that mattered - could you take a look at the list of packages that have been left unapproved and see if you want those approved or rejected?
<sil2100> acheronuk: there's like around 11 of those
<acheronuk> sil2100: looks sensible to me. thanks
<sil2100> acheronuk: I'm leaving the decision up to you - we're trying not to rebuild stuff if not needed as seb mentioned, since it's counter-productive - but I think we didn't care about that last time
<acheronuk> sil2100: I think I'm happy with this middle ground at the moment. I just 'aimed high' preparing them all, but practicalities here say that was a bit much
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.1]
<sil2100> It's better this way than missing something, I'll reject them now - we can always bring them back from the rejected queue easily
<acheronuk> ok
-queuebot:#ubuntu-release- Unapproved: rejected breeze-grub [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected breeze-plymouth [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected ksshaskpass [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected kwrited [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected plasma-workspace-wallpapers [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected xdg-desktop-portal-kde [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected breeze-gtk [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected kwayland-integration [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected plymouth-kcm [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected kdecoration [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected libkscreen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
<sil2100> apw: you shephearding those snapd updates, yes? Like, the ones in -proposed as well?
<apw> sil2100, yes ... i have a .9 coming to replace the .5s because the testing is broken, but the testing is sick for that too
<sil2100> apw: ouch
<apw> sil2100, it is becoming "fun" that is for sure
-queuebot:#ubuntu-release- Unapproved: accepted python-pyvmomi [source] (xenial-proposed) [6.5.0.2017.5-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.0-0ubuntu1 => 3.28.0-0ubuntu1.1] (ubuntu-desktop)
<slashd> o/ sil2100, could you please approve the Trusty upload for 'initramfs-tools' ?
<slashd> For LP: #1771557 ^
<ubot5> Launchpad bug 1771557 in initramfs-tools (Ubuntu Trusty) "NVMe boot drives not supported - failing in generating initramfs" [High,In progress] https://launchpad.net/bugs/1771557
<juliank> rbasak: In bug 1771345, the script did not add the verification-needed-* tags when you accepted the packages, odd. Adding -done-* tags now
<ubot5> bug 1771345 in util-linux (Ubuntu Bionic) "lscpu possible crash in min/max frequency" [High,Fix committed] https://launchpad.net/bugs/1771345
<ahasenack> hi, could an archive admin please reject my apache2 upload that is in cosmic-proposed?
<acheronuk> sil2100: typical. sigh. https://community.kde.org/Plasma/5.12_Errata
<acheronuk> "Plasma Discover in 5.12.5 was updated on 17 May 2018 with a 5.12.5.1 version. 5.12.5.1 includes a fix for https://bugs.kde.org/show_bug.cgi?id=394048"
<ubot5> KDE bug 394048 in discover "Software Centre Discover crashed three times out of three when searching for "latte" after hiting return" [Normal,Resolved: fixed]
<acheronuk> sil2100: do you want to replace 5.12.5 with that as if it didn't happen in updates?
<acheronuk> I have an additional changelog item on the current upload which would need to be appended to the new one if done like that
<sil2100> bdmurray: hey! If anything I'm still doing some SRU work for the nearest 1.5 hour, working on gce-compute-image-packages now
<bdmurray> sil2100: okay
<acheronuk> how do we persuade britney not to see removing autotests as a regression? e.g. if we want to follow debian and remove some that are too broken
<slangasek> acheronuk: force-badtest hints
<acheronuk> slangasek: thanks.will they need to keep being updated, or would britney 'forget' after a few times
<Laney> no, this is supposed to be handled
<Laney> which package?
<acheronuk> Laney: kdepim-runtime is one: https://salsa.debian.org/qt-kde-team/kde/kdepim-runtime/commit/6bfa589c1d0982048b3588e184416e3b2f2101e1
<acheronuk> there are some others I saw in debian changes emails
<acheronuk> some just removed. some set to run at build time instead
<Laney> acheronuk: Can you point me to a specific upload that ran its tests after dropping debian/tests/*?
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180510+dfsg1-0ubuntu2~18.04.0]
<acheronuk> Laney: not seen any recently. if britney has been changed so that no longer flags as a regression, then that will help me when I merge these debian changes properly :)
<Laney> I think we did that quite a while ago
<acheronuk> I must have missed the memo
<Laney> commit 41d51369f54d695153fcd71043b511883392a5bf (dropped-tests)
<Laney> Author: Iain Lane <iain.lane@canonical.com>
<Laney> Date:   Wed Jan 11 10:43:30 2017 +0000
<Laney>     autopkgtest: Accept packages which have dropped their tests in unstable
<acheronuk> oooh
<Laney> I mean, it could be broken, that's why I ask for a link
<Laney> So let me know after you've uploaded one if it doesn't work
<acheronuk> well, I don't have one. I was just assuming the old behaviour would stand. if it does not, then great. thank you
<sil2100> rbalint: regarding the gce packages - I see you pushed ubuntu3 to cosmic that was removing the Breaks/Replaces of irqbalance to cosmic, does that also apply for the other series like bionic?
<rbalint> sil2100, yes, none of them should break/replace
<sil2100> rbalint: hm, ok, so I guess we'll need new uploads for b/a/x/t?
<sil2100> rbalint: I accepted the bionic one already sadly so it'll have to be overriden
<sil2100> rbalint: since I saw bionic and artful at least break/replace still
<rbalint> sil2100, hm
<rbalint> sil2100, let me check
<sil2100> rbalint: they're all based on ubuntu2 and there was no added changes for that, at least per the debdiffs I see
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20180129+dfsg1-0ubuntu1~17.10.0 => 20180510+dfsg1-0ubuntu3~17.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180129+dfsg1-0ubuntu1~16.04.0 => 20180510+dfsg1-0ubuntu3~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180129+dfsg1-0ubuntu1~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180510+dfsg1-0ubuntu2~18.04.0 => 20180510+dfsg1-0ubuntu3~18.04.0] (ubuntu-cloud)
<sil2100> rbalint: thanks! Rejecting the old ones and handling those
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (artful-proposed) [20180510+dfsg1-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20180510+dfsg1-0ubuntu2~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180510+dfsg1-0ubuntu3~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (artful-proposed) [20180510+dfsg1-0ubuntu3~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20180510+dfsg1-0ubuntu3~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.0]
<rbalint> sil2100, thanks, i had the earlier ones prepared for upload then during testing I decided to update them but accidentally uploaded the earlier ones at late night
<sil2100> yw!
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
<slangasek> seb128: hi, network-manager-gnome now depends on ayatana-appindicator instead of libappindicator.  ~dx-packages is defunct; should desktop own ayatana-appindicator in main?  This shouldn't need an MIR since it's a straight swap of the same code under a new source package name
<slangasek> curious how autopkgtest sees instances that are stalled for 12h+, but the moment the cronjob goes to delete them, they've disappeared
<jbicha> slangasek: seb128: (same for libindicator > libayatana-indicator)
<tsimonq2> slangasek: bug 1770146
<ubot5> bug 1770146 in libayatana-appindicator (Ubuntu) "[MIR] libayatana-appindicator" [Undecided,New] https://launchpad.net/bugs/1770146
<slangasek> "appindicator is dead, we should move it to universe" yeah that's not how universe works ;)
<slangasek> as I said, we don't need an MIR, we need a team subscriber
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> Just thought I'd link it.
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [i386] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [arm64] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [armhf] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
-queuebot:#ubuntu-release- New binary: libsfml [s390x] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsfml [ppc64el] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: autopep8 [amd64] (cosmic-proposed/universe) [1.3.5-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New: accepted uwsgi [i386] (cosmic-proposed) [2.0.15-11]
-queuebot:#ubuntu-release- New binary: libsfml [amd64] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsfml [i386] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-transliterate [amd64] (cosmic-proposed/none) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sexpdata [amd64] (cosmic-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsfml [arm64] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsfml [armhf] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [s390x] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [ppc64el] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [amd64] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [i386] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [arm64] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfixposix [armhf] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted autopep8 [amd64] (cosmic-proposed) [1.3.5-2]
-queuebot:#ubuntu-release- New: accepted libfixposix [arm64] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libfixposix [i386] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libfixposix [s390x] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libsfml [arm64] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libsfml [i386] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libsfml [s390x] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-transliterate [amd64] (cosmic-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted libfixposix [amd64] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libfixposix [ppc64el] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libsfml [armhf] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-sexpdata [amd64] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted libfixposix [armhf] (cosmic-proposed) [1:0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libsfml [ppc64el] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libsfml [amd64] (cosmic-proposed) [2.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-zunclient [amd64] (cosmic-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ssh-import-id [source] (bionic-proposed) [5.7-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: x11-xkb-utils (bionic-proposed/main) [7.7+3 => 7.7+3ubuntu0.18.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected x11-xkb-utils [source] (bionic-proposed) [7.7+3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted x11-xkb-utils [source] (bionic-proposed) [7.7+3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [source] (bionic-proposed) [3.28.2-0ubuntu1]
<seb128> slangasek, whoever did that change should revert it, we want to check that the ayatana- components are indeed better codebases and see if we need a coordinated transition or if we can mix apps using both the old and new libraries
<seb128> LocutusOfBorg, ^ that would be you
<slangasek> seb128: ok, thanks
<slangasek> seb128: to be fair, I think it's probably better to migrate to it just to not be islanded on a dead-upstream branch, and deal with any issues along the way; but I'll sit on my hands for now
<seb128> slangasek, I've little visibility on the roadmap/direction that ayatana-* want to take at this point and I'm not confident it's compatible with what we do/want to do
<seb128> it's probably fine but I don't want to handwave accept it without checking
 * slangasek nods
<seb128> (and I still find how that project has been handled pretty stupid, they should have taken over the existing projects but that's another topic)
<slangasek> ok; I haven't followed the politics there
<tsimonq2> seb128: Please do correct me if I'm wrong, but I wouldn't be quick to blame LocutusOfBorg . There are some Debian packages, notably transmission, who switched themselves.
<tsimonq2> This doesn't seem to be a delta we're carrying.
<tsimonq2> (For all the packages I've been dealing with, personally.)
<tsimonq2> I won't take a side on the politics, but people are adopting it.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (bionic-proposed) [3.28.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.0-0ubuntu1.1]
<seb128> tsimonq2, I don't blame him, but he uploaded a package in main making it use a package in universe without an approved MIR
<seb128> tsimonq2, well they can if they want, we just didn't say we wanted to replace our solution by the new one
<seb128> so until we do it's wrong to assume we are going to
-queuebot:#ubuntu-release- Unapproved: accepted ssh-import-id [source] (bionic-proposed) [5.7-0ubuntu1.1]
<tsimonq2> seb128: Ah. So if it's required for one package (and needs a MIR anyway),, why not convert other packages?
<tsimonq2> s/,,/,/
<seb128> tsimonq2, it's not "required" afaik
<seb128> our solution is libappindicator atm
<tsimonq2> seb128: Well, transmission needs it.
<seb128> or needs to be patched to use the library Ubuntu support
<tsimonq2> So unless you want a delta (not up to me), oi's required.
<tsimonq2> *it's
<seb128> we want a delta
<seb128> our main packages need to use components in main
<tsimonq2> OK; like I said, not up to me.
<tsimonq2> In that case, on the other side of it, why not adopt it?
<seb128> read t he backlog of this channel? I stated the reason earlier
<tsimonq2> Let me rephrase: why not do the review?
<tsimonq2> Of course, it has to go through e.g. a security review.
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.32.9+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.32.8+17.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.32.8]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.32.8~14.04]
<apw> bdmurray, oh are we clashing ?
<bdmurray> apw: I don't know. What are you doing?
<apw> bdmurray, i was just clearing up some pending snapd uploads i was intending to review
<apw> bdmurray, but you had just accepted bionic i think, so was checking if i should do the rest
<apw> bdmurray, in the sense i know the background with mvo
<bdmurray> apw: Have at it.
<apw> bdmurray, ack
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.32.9+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.32.9]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.32.9~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted simbody [source] (artful-proposed) [3.5.4+dfsg-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (artful-proposed) [0.5.8-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (xenial-proposed) [0.5.6-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.11]
<tsimonq2> cjwatson, slangasek: There, this looks right now, could I please get a review? https://code.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/+merge/345792
-queuebot:#ubuntu-release- New binary: grabix [ppc64el] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [ppc64el] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [ppc64el] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libocxl [ppc64el] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [s390x] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [s390x] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grabix [s390x] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dd-plist [amd64] (cosmic-proposed/none) [1.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libb-debug-perl [amd64] (cosmic-proposed/none) [1.26-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grabix [amd64] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-infinite-chest [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grabix [i386] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [i386] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-sugar [amd64] (cosmic-proposed/none) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [amd64] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [i386] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [amd64] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grabix [arm64] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [armhf] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grabix [armhf] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [arm64] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: listserialportsc [arm64] (cosmic-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-obuild [armhf] (cosmic-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dd-plist [amd64] (cosmic-proposed) [1.20-1]
-queuebot:#ubuntu-release- New: accepted grabix [arm64] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted grabix [i386] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted grabix [s390x] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [amd64] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [armhf] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-infinite-chest [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [arm64] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [i386] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted grabix [amd64] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted grabix [ppc64el] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [arm64] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [amd64] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted pytest-sugar [amd64] (cosmic-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted grabix [armhf] (cosmic-proposed) [0.1.6+git20171023-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [i386] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted libb-debug-perl [amd64] (cosmic-proposed) [1.26-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [armhf] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted libocxl [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [s390x] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [s390x] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted listserialportsc [ppc64el] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-obuild [ppc64el] (cosmic-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New binary: obsidian-icon-theme [amd64] (cosmic-proposed/universe) [3.5-1] (no packageset)
#ubuntu-release 2018-05-18
-queuebot:#ubuntu-release- Unapproved: openbox (bionic-proposed/universe) [3.6.1-7 => 3.6.1-7ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: heat (bionic-proposed/main) [1:10.0.0-0ubuntu1.1 => 1:10.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.1-0ubuntu1.1 => 2:12.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.3-0ubuntu1 => 2:17.0.4-0ubuntu1] (openstack, ubuntu-server)
<slangasek> huh. nodejs.  Guess we're not zeroing those queues any time soon.
-queuebot:#ubuntu-release- New binary: reactphp-cache [amd64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [s390x] (cosmic-proposed/universe) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-promise-timer [amd64] (cosmic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-event-loop [amd64] (cosmic-proposed/none) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-stream [amd64] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [ppc64el] (cosmic-proposed/universe) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [amd64] (cosmic-proposed/universe) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [arm64] (cosmic-proposed/universe) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted obsidian-icon-theme [amd64] (cosmic-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted reactphp-event-loop [amd64] (cosmic-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted reactphp-stream [amd64] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted reactphp-cache [amd64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted reactphp-promise-timer [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- Unapproved: haproxy (trusty-proposed/main) [1.5.14-1ubuntu0.15.10.1~ubuntu14.04.1 => 1.4.24-2ubuntu0.5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180510+dfsg1-0ubuntu3~18.04.0 => 20180510+dfsg1-0ubuntu4~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: astropy-healpix [s390x] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180510+dfsg1-0ubuntu4~18.04.0]
-queuebot:#ubuntu-release- New binary: astropy-healpix [i386] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [ppc64el] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [armhf] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [amd64] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: astropy-healpix [arm64] (cosmic-proposed/universe) [0.2-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.3.0-6434-gd354690-0ubuntu1~16.04.1 => 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (artful-proposed/main) [2.3.0-6434-gd354690-0ubuntu1~17.10.1 => 2.3.3-6498-ge4db91d-0ubuntu1~17.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- New sync: haskell-bsb-http-chunked (cosmic-proposed/primary) [0.0.0.2-1]
-queuebot:#ubuntu-release- New sync: haskell-cabal (cosmic-proposed/primary) [2.0.1.1-1]
-queuebot:#ubuntu-release- New sync: haskell-multimap (cosmic-proposed/primary) [1.2.1-1]
-queuebot:#ubuntu-release- New sync: haskell-onetuple (cosmic-proposed/primary) [0.2.1-1]
-queuebot:#ubuntu-release- New sync: haskell-only (cosmic-proposed/primary) [0.1-1]
-queuebot:#ubuntu-release- New sync: haskell-parser-combinators (cosmic-proposed/primary) [0.4.0-1]
-queuebot:#ubuntu-release- New sync: haskell-singleton-bool (cosmic-proposed/primary) [0.1.4-1]
-queuebot:#ubuntu-release- New sync: haskell-time-units (cosmic-proposed/primary) [1.0.0-1]
-queuebot:#ubuntu-release- New sync: haskell-validity (cosmic-proposed/primary) [0.4.0.4-1]
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.10 => 1.13.4-1ubuntu1.11] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnustep-base (bionic-proposed/universe) [1.25.1-2ubuntu3 => 1.25.1-3ubuntu1] (no packageset)
<LocutusOfBorg> any AA please accept haskell-*
<LocutusOfBorg> and reject gnustep-base, I have reuploaded to cosmic (damn me)
-queuebot:#ubuntu-release- Unapproved: rejected gnustep-base [source] (bionic-proposed) [1.25.1-3ubuntu1]
<cjwatson> done the former; somebody else had already done the latter
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [sync] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [sync] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [sync] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [sync] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [sync] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [sync] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [sync] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [sync] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [sync] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [amd64] (cosmic-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [ppc64el] (cosmic-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [arm64] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [arm64] (cosmic-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [s390x] (cosmic-proposed) [0.2-2]
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- New: accepted astropy-healpix [amd64] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [i386] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [s390x] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [armhf] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New: accepted astropy-healpix [ppc64el] (cosmic-proposed) [0.2-3]
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [ppc64el] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [s390x] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-only [s390x] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [s390x] (cosmic-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [s390x] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [s390x] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multimap [s390x] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [i386] (cosmic-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [ppc64el] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-only [ppc64el] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [ppc64el] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [s390x] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [i386] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [ppc64el] (cosmic-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [s390x] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multimap [ppc64el] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [ppc64el] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [ppc64el] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multimap [amd64] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-only [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [amd64] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [amd64] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [i386] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [amd64] (cosmic-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [i386] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [i386] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [amd64] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multimap [i386] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [i386] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-only [i386] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [amd64] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [arm64] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [arm64] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
<LocutusOfBorg> cjwatson, if you can setup some *haskell* auto-accept it would speed up my weekend workflow :)
-queuebot:#ubuntu-release- New binary: haskell-only [arm64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [arm64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
<cjwatson> not easily
-queuebot:#ubuntu-release- New binary: haskell-only [armhf] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-singleton-bool [armhf] (cosmic-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity [armhf] (cosmic-proposed/none) [0.4.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [arm64] (cosmic-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-units [armhf] (cosmic-proposed/none) [1.0.0-1] (no packageset)
<LocutusOfBorg> do I have some way to avoid the queue? I might setup a bileto to do the transition at this point
<LocutusOfBorg> or copy-package?
<cjwatson> it'll only be a problem for new package
<cjwatson> s
<cjwatson> of which I don't expect a huge number
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [arm64] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [arm64] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bsb-http-chunked [armhf] (cosmic-proposed/none) [0.0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-parser-combinators [armhf] (cosmic-proposed/none) [0.4.0-1] (no packageset)
<LocutusOfBorg> 34 might be the number (according to "is NEW" grep in debian-haskell mail list)
<cjwatson> using bileto deliberately to work around NEW is abuse (and I think bileto even prevents you from doing so nowadays though I don't quite remember), so please don't
<cjwatson> I can run new-binary-debian-universe occasionally up to early tomorrow afternoon
<LocutusOfBorg> is abuse also to bother AA :) I'm just asking what is the best one
<cjwatson> and I'm sure other folks will be around for lightweight stuff like that
<LocutusOfBorg> ack
<cjwatson> (I'm running it at the moment, it's just being slow)(
-queuebot:#ubuntu-release- New binary: haskell-multimap [arm64] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-onetuple [armhf] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multimap [armhf] (cosmic-proposed/none) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [arm64] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [arm64] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [arm64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [arm64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [armhf] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [armhf] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [armhf] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [armhf] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [armhf] (cosmic-proposed) [0.4.0-1]
<cjwatson> oh, apparently somebody else is doing so, oh well
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [amd64] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [ppc64el] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [amd64] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [ppc64el] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [ppc64el] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [armhf] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [ppc64el] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [amd64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [i386] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [i386] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [i386] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [arm64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [s390x] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [ppc64el] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [armhf] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [ppc64el] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-bsb-http-chunked [s390x] (cosmic-proposed) [0.0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-onetuple [s390x] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [i386] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [arm64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [s390x] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [arm64] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [ppc64el] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-multimap [s390x] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-parser-combinators [s390x] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [amd64] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-only [i386] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-units [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [s390x] (cosmic-proposed) [0.4.0.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-singleton-bool [i386] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity [i386] (cosmic-proposed) [0.4.0.4-1]
 * slangasek waves to cjwatson :)
-queuebot:#ubuntu-release- New binary: haskell-cabal [amd64] (cosmic-proposed/none) [2.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal [i386] (cosmic-proposed/universe) [2.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal [ppc64el] (cosmic-proposed/universe) [2.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cabal [s390x] (cosmic-proposed/universe) [2.0.1.1-1] (no packageset)
<bdmurray> slangasek: Could you have a look at my u-r-u upload for Bionic? its bug 1768620
<ubot5> bug 1768620 in ubuntu-release-upgrader (Ubuntu Bionic) "removal_blacklist.cfg updates" [Undecided,Confirmed] https://launchpad.net/bugs/1768620
-queuebot:#ubuntu-release- New sync: haskell-prettyprinter (cosmic-proposed/primary) [1.2.0.1-1]
-queuebot:#ubuntu-release- New sync: haskell-product-isomorphic (cosmic-proposed/primary) [0.0.3.2-1]
-queuebot:#ubuntu-release- New sync: haskell-rate-limit (cosmic-proposed/primary) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [sync] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [sync] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [sync] (cosmic-proposed) [0.0.3.2-1]
<tsimonq2> Could I please get some eyes on bug 1771696 so that we can test over theb weekend?
<ubot5> bug 1771696 in openbox (Ubuntu Cosmic) "Openbox Apps menu causes error in obamenu" [Medium,In progress] https://launchpad.net/bugs/1771696
<tsimonq2> *the
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.18]
<slangasek> bdmurray: done
<slangasek> tsimonq2: 'in progress' on cosmic, not 'fix committed'?
<tsimonq2> slangasek: Ah, let me fix that.
<slangasek> tsimonq2: so it is fixed in 3.6.1-7ubuntu1?
<tsimonq2> Yes.
<tsimonq2> Blocked on flaky KDE autopkgtests last time I checked.
<tsimonq2> (Why are those rdeps of openbox? sigh)
<wxl> cuz no one likes kwin? j/k XD
 * tsimonq2 kicks wxl.
<tsimonq2> (Although, true... :P)
<wxl> oh come on, i was kidding. kwin's decent. openbox is just better :)
<tsimonq2> hah
<slangasek> tsimonq2: "start a pure openbox session" - please provide steps that are followable by someone who knows nothing about openbox
<wxl> unfortunately that will vary based on display manager, slangasek
<slangasek> then tell me in the test case what display manager to use, or what image to boot in a VM as a starting point
-queuebot:#ubuntu-release- New binary: haskell-cabal [arm64] (cosmic-proposed/universe) [2.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.7 (bionic-proposed/universe) [5.7.20-29.24-0ubuntu2 => 5.7.20-29.24-0ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-cmark-gfm (cosmic-proposed/primary) [0.1.3-1]
<slangasek> tsimonq2, wxl: ^^ clean test case blocks accept of openbox into -proposed
<tsimonq2> Roger
<tsimonq2> slangasek: .
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [sync] (cosmic-proposed) [0.1.3-1]
<wxl> it doesn't work?
<tsimonq2> wxl: huh?
-queuebot:#ubuntu-release- Unapproved: accepted openbox [source] (bionic-proposed) [3.6.1-7ubuntu0.1]
<wxl> i may be confused about the verbage here. what's the deal?
<tsimonq2> wxl: desc needed to be more verbose, .
<tsimonq2> (. = done)
<wxl> ah ok
<tsimonq2> Thanks slangasek
<slangasek> n/p
-queuebot:#ubuntu-release- New binary: haskell-cabal [armhf] (cosmic-proposed/universe) [2.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [s390x] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [s390x] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [s390x] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [ppc64el] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [ppc64el] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [ppc64el] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [amd64] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [i386] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [amd64] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [amd64] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [i386] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [i386] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
<ginggs> would someone please 'force-badtest node-external-editor/2.0.4+dfsg-1' ? it has regressed in release
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173 => 1.173.1] (core, kernel)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [arm64] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [arm64] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rate-limit [armhf] (cosmic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-product-isomorphic [armhf] (cosmic-proposed/universe) [0.0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-cabal [arm64] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [s390x] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [armhf] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [amd64] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [ppc64el] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-cabal [i386] (cosmic-proposed) [2.0.1.1-1]
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [arm64] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter [armhf] (cosmic-proposed/universe) [1.2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [armhf] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [arm64] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [amd64] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [armhf] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [ppc64el] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [arm64] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [s390x] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter [i386] (cosmic-proposed) [1.2.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [amd64] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [ppc64el] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [amd64] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [armhf] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [ppc64el] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [i386] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [arm64] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [s390x] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-product-isomorphic [s390x] (cosmic-proposed) [0.0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-rate-limit [i386] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.18 => 1.157.19] (core, kernel)
<tsimonq2> Infra-ish question. If I throw a script in /lib/live/config that's ran on boot of a live image right?
-queuebot:#ubuntu-release- New binary: haskell-cmark-gfm [ppc64el] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: curtin (artful-proposed/main) [18.1-1-g45564eef-0ubuntu1~17.10.1 => 18.1-17-gae48e86f-0ubuntu1~17.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.1-5-g572ae5d6-0ubuntu1 => 18.1-17-gae48e86f-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.1-1-g45564eef-0ubuntu1~16.04.1 => 18.1-17-gae48e86f-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: haskell-cmark-gfm [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cmark-gfm [i386] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cmark-gfm [arm64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cmark-gfm [armhf] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
<coreycb> hello, can an archive admin please reject sqlalchemy 1.2.5+ds1-1ubuntu1 from cosmic-proposed?
<slangasek> coreycb: I guess that's s/reject/remove/; can you elaborate why?
<coreycb> slangasek: hi, yes. from an openstack perspective it needs more testing. having issues at the moment building cinder with it.
<coreycb> slangasek: i'm not sure that upstream supports it yet
<slangasek> coreycb: can you point to a build log, or maybe just file a bug report on the sqlalchemy package with details?
<coreycb> slangasek: ok just checked and they support SQLAlchemy===1.2.7 so it should be supported. let's just leave it as is and i'll figure it out.
<slangasek> coreycb: ok
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.3]
-queuebot:#ubuntu-release- Unapproved: budgie-extras (bionic-proposed/universe) [0.4.4-0ubuntu1 => 0.4.4-0ubuntu1.1] (personal-fossfreedom, ubuntu-budgie)
#ubuntu-release 2018-05-19
-queuebot:#ubuntu-release- New binary: calamares-settings-debian [amd64] (cosmic-proposed/universe) [10.0.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pikopixel.app (bionic-proposed/universe) [1.0-b9b-1 => 1.0-b9b-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted calamares-settings-debian [amd64] (cosmic-proposed) [10.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [arm64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [i386] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [ppc64el] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-cmark-gfm [armhf] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New binary: libmygpo-qt [s390x] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libmygpo-qt [amd64] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libmygpo-qt [ppc64el] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libmygpo-qt [i386] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libmygpo-qt [arm64] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libmygpo-qt [armhf] (cosmic-proposed/universe) [1.1.0-2] (kubuntu)
<gopal_> when cfcadfaad7251d8b640713724b388164d75465b2 will be added in ubuntu 18.04 lts ?
<gopal_> bug 1745646 is committed in artful and bionic
<ubot5> bug 1745646 in linux (Ubuntu Cosmic) "Battery drains when laptop is off (shutdown)" [Medium,In progress] https://launchpad.net/bugs/1745646
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [amd64] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [armhf] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [ppc64el] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [arm64] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [s390x] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted libmygpo-qt [i386] (cosmic-proposed) [1.1.0-2]
<LocutusOfBorg> gopal_, I think in a week or two
<gopal_> LocutusOfBorg, if testing is required , can i test it now ?
<LocutusOfBorg> I presume once it lands in proposed pocket somebody will ask you to test it
<LocutusOfBorg> but not before the current proposed kernel goes in release, for sure
-queuebot:#ubuntu-release- New sync: haskell-genvalidity (cosmic-proposed/primary) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [sync] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [s390x] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [amd64] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [ppc64el] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [i386] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-text-short (cosmic-proposed/primary) [0.1.2-2]
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [arm64] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-word-wrap (cosmic-proposed/primary) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: haskell-genvalidity [armhf] (cosmic-proposed/none) [0.4.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-tasty-expected-failure (cosmic-proposed/primary) [0.11.1.1-1]
-queuebot:#ubuntu-release- New sync: haskell-genvalidity-property (cosmic-proposed/primary) [0.1.0.0-1]
-queuebot:#ubuntu-release- New sync: haskell-prettyprinter-convert-ansi-wl-pprint (cosmic-proposed/primary) [1.1-1]
-queuebot:#ubuntu-release- New sync: haskell-prettyprinter-ansi-terminal (cosmic-proposed/primary) [1.1.1.2-1]
-queuebot:#ubuntu-release- New sync: haskell-vector-builder (cosmic-proposed/primary) [0.3.4.1-1]
-queuebot:#ubuntu-release- New sync: haskell-wl-pprint-annotated (cosmic-proposed/primary) [0.1.0.0-1]
<LocutusOfBorg> pleeeeeeeeeeeeeeeease process the above haskell syncs/binaries :)
 * LocutusOfBorg goes to sleep
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [amd64] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [armhf] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [ppc64el] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [arm64] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [s390x] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity [i386] (cosmic-proposed) [0.4.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity-property [sync] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [sync] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-short [sync] (cosmic-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-wl-pprint-annotated [sync] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-ansi-terminal [sync] (cosmic-proposed) [1.1.1.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-vector-builder [sync] (cosmic-proposed) [0.3.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-expected-failure [sync] (cosmic-proposed) [0.11.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-word-wrap [sync] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: haskell-tasty-expected-failure [s390x] (cosmic-proposed/universe) [0.11.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity-property [amd64] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity-property [s390x] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-expected-failure [amd64] (cosmic-proposed/universe) [0.11.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-expected-failure [ppc64el] (cosmic-proposed/universe) [0.11.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-short [s390x] (cosmic-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-vector-builder [s390x] (cosmic-proposed/universe) [0.3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-wl-pprint-annotated [ppc64el] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-word-wrap [i386] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-word-wrap [s390x] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity-property [ppc64el] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-expected-failure [i386] (cosmic-proposed/universe) [0.11.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-vector-builder [ppc64el] (cosmic-proposed/universe) [0.3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-word-wrap [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-ansi-terminal [ppc64el] (cosmic-proposed/universe) [1.1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-wl-pprint-annotated [amd64] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-short [ppc64el] (cosmic-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-word-wrap [ppc64el] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-genvalidity-property [i386] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-ansi-terminal [amd64] (cosmic-proposed/universe) [1.1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-ansi-terminal [i386] (cosmic-proposed/universe) [1.1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-short [i386] (cosmic-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-short [amd64] (cosmic-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-vector-builder [amd64] (cosmic-proposed/universe) [0.3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-vector-builder [i386] (cosmic-proposed/universe) [0.3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-wl-pprint-annotated [i386] (cosmic-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-ansi-terminal [amd64] (cosmic-proposed) [1.1.1.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-short [amd64] (cosmic-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-vector-builder [amd64] (cosmic-proposed) [0.3.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-wl-pprint-annotated [i386] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-ansi-terminal [i386] (cosmic-proposed) [1.1.1.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-vector-builder [i386] (cosmic-proposed) [0.3.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-short [i386] (cosmic-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity-property [amd64] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity-property [ppc64el] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-ansi-terminal [ppc64el] (cosmic-proposed) [1.1.1.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-expected-failure [i386] (cosmic-proposed) [0.11.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-expected-failure [s390x] (cosmic-proposed) [0.11.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-short [s390x] (cosmic-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-vector-builder [s390x] (cosmic-proposed) [0.3.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-wl-pprint-annotated [ppc64el] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-word-wrap [i386] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-word-wrap [s390x] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity-property [i386] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-expected-failure [amd64] (cosmic-proposed) [0.11.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-short [ppc64el] (cosmic-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-wl-pprint-annotated [amd64] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-word-wrap [ppc64el] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-genvalidity-property [s390x] (cosmic-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-vector-builder [ppc64el] (cosmic-proposed) [0.3.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-expected-failure [ppc64el] (cosmic-proposed) [0.11.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-word-wrap [amd64] (cosmic-proposed) [0.4.1-1]
#ubuntu-release 2018-05-20
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-convert-ansi-wl-pprint [ppc64el] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-convert-ansi-wl-pprint [amd64] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-convert-ansi-wl-pprint [i386] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wine [amd64] (cosmic-proposed/universe) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-convert-ansi-wl-pprint [arm64] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-prettyprinter-convert-ansi-wl-pprint [armhf] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [armhf] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [ppc64el] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [arm64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted wine [amd64] (cosmic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-prettyprinter-convert-ansi-wl-pprint [i386] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New sync: haskell-hedgehog (cosmic-proposed/primary) [0.5.3-1]
-queuebot:#ubuntu-release- New binary: php-cocur-slugify [amd64] (cosmic-proposed/universe) [3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-dflydev-fig-cookies [amd64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-fabiang-sasl [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-defuse-php-encryption [amd64] (cosmic-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-embed [amd64] (cosmic-proposed/universe) [3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: django-ldapdb [amd64] (cosmic-proposed/universe) [1.0.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-react-zmq [amd64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-nesbot-carbon [amd64] (cosmic-proposed/universe) [1.27.0-1] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-config-ini (cosmic-proposed/primary) [0.2.2.0-1]
-queuebot:#ubuntu-release- New sync: haskell-ini (cosmic-proposed/primary) [0.3.5-1]
-queuebot:#ubuntu-release- New sync: haskell-tasty-hedgehog (cosmic-proposed/primary) [0.1.0.2-1]
-queuebot:#ubuntu-release- Unapproved: language-selector (bionic-proposed/main) [0.188 => 0.188.1] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- New sync: haskell-hslua-module-text (cosmic-proposed/primary) [0.1.2.1-1]
-queuebot:#ubuntu-release- New sync: haskell-microstache (cosmic-proposed/primary) [1.0.1.1-1]
-queuebot:#ubuntu-release- New sync: haskell-thyme (cosmic-proposed/primary) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted django-ldapdb [amd64] (cosmic-proposed) [1.0.0+ds-1]
-queuebot:#ubuntu-release- New: accepted php-defuse-php-encryption [amd64] (cosmic-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted php-embed [amd64] (cosmic-proposed) [3.3.1-1]
-queuebot:#ubuntu-release- New: accepted php-nesbot-carbon [amd64] (cosmic-proposed) [1.27.0-1]
-queuebot:#ubuntu-release- New: accepted php-cocur-slugify [amd64] (cosmic-proposed) [3.1-1]
-queuebot:#ubuntu-release- New: accepted php-fabiang-sasl [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted php-dflydev-fig-cookies [amd64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted php-react-zmq [amd64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [sync] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [sync] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [sync] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [sync] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-hedgehog [sync] (cosmic-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-hedgehog [sync] (cosmic-proposed) [0.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [sync] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [s390x] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [amd64] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [ppc64el] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [s390x] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [i386] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [amd64] (cosmic-proposed/none) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [ppc64el] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [s390x] (cosmic-proposed/none) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [amd64] (cosmic-proposed/none) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [ppc64el] (cosmic-proposed/none) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [amd64] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [ppc64el] (cosmic-proposed/none) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [i386] (cosmic-proposed/none) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [i386] (cosmic-proposed/none) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [arm64] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [s390x] (cosmic-proposed/none) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hedgehog [ppc64el] (cosmic-proposed/none) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [arm64] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hslua-module-text [armhf] (cosmic-proposed/none) [0.1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [armhf] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hedgehog [amd64] (cosmic-proposed/none) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [arm64] (cosmic-proposed/universe) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [arm64] (cosmic-proposed/universe) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-config-ini [armhf] (cosmic-proposed/universe) [0.2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ini [i386] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microstache [armhf] (cosmic-proposed/universe) [1.0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-thyme [i386] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-thyme [s390x] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-thyme [ppc64el] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hedgehog [arm64] (cosmic-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-thyme [amd64] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
#ubuntu-release 2019-05-13
<mwhudson> RAOF: would it be possible for you to release livecd-rootfs today?
-queuebot:#ubuntu-release- New binary: rustc [s390x] (eoan-proposed/universe) [1.33.0+dfsg1+llvm-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (eoan-proposed/universe) [1.33.0+dfsg1+llvm-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [i386] (eoan-proposed/universe) [1.33.0+dfsg1+llvm-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (eoan-proposed/universe) [1.33.0+dfsg1+llvm-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (eoan-proposed) [1.33.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (eoan-proposed) [1.33.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (eoan-proposed) [1.33.0+dfsg1+llvm-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (eoan-proposed) [1.33.0+dfsg1+llvm-1~exp1ubuntu1]
<RAOF> mwhudson: Oooh, thanks for the reminder. I'll do that once I get back to my machine with the LP keys.
<RAOF> mwhudson: sorry, I appear to have been rather waylaid by children.
<mwhudson> RAOF: that happens
<oSoMoN> I sponsored marcustomlinson's upload of libreoffice{,-l10n} 6.1.6-0ubuntu0.18.10.2 to cosmic-proposed about an hour ago, and the upload was successful, but it hasn't appeared in the unapproved queue yet, should I wait longer or upload again?
<oSoMoN> (haven't gotten an e-mail to notify that the upload was rejected, either)
<cjwatson> 2019-05-13 08:40:54 INFO        GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20190513-084005-016192/ubuntu/libreoffice_6.1.6-0ubuntu0.18.10.2_source.changes failed: Verification failed 3 times: ['GPG key D328D72318ACE6C7 not found due to a server or network failure.', 'GPG key D328D72318ACE6C7 not found due to a server or network failure.', 'GPG key D328D72318ACE6C7 ...
<cjwatson> ... not found due to a server or network failure.']
<cjwatson> oSoMoN: keyserver flakiness, reupload.  (Also you probably wanted #launchpad for this kind of thing)
<oSoMoN> cjwatson, thanks
<LocutusOfBorg> can we please kick dleyna-server out from release pocket to see if we can move further with upnp transition?
<LocutusOfBorg> (this has been discussed on -devel channel some minutes ago)
<seb128> LocutusOfBorg, server is for sure good?
<seb128> LocutusOfBorg, also I'm archive admin I was going to handle renderer...
<vorlon> seb128: demoting dleyna-renderer to -proposed doesn't exactly work, britney pushed it right back in
<seb128> vorlon, unless you block-proposed it?
<vorlon> seb128: you could block-proposed it... but it did already migrate
<seb128> vorlon, I was proposed to demote-to-proposed with a block bug
<vorlon> the block bug doesn't appear to have taken effect
<seb128> proposing
<seb128> vorlon, that was not done yet?
<seb128> arg
<seb128> sorry, was looking at the wrong place
<seb128> I think I opened the bug too late :/
 * seb128 tries again
<LocutusOfBorg> he tried to hard that he quit...
<cpaelzer> thanks sil2100 for releasing the qemu SRU
<cpaelzer> ddstreet: ^^
<sil2100> o/
<sil2100> yw
-queuebot:#ubuntu-release- Unapproved: accepted kbd [source] (disco-proposed) [2.0.4-4ubuntu1.19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted kbd [source] (cosmic-proposed) [2.0.4-2ubuntu1.18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted kbd [source] (bionic-proposed) [2.0.4-2ubuntu1.18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted kbd [source] (xenial-proposed) [1.15.5-1ubuntu5.16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (disco-proposed) [3.32.2-1~ubuntu19.04.1]
<tkamppeter> infinity, sil2100, on Friday I have added an autopkg test fix to the network-manager Bionic SRU for bug 1809132, bug  942856, bug 1754671 and tjaalton told me that he accepts this addition without full re-testing. He had accepted it to -proposed on Friday and asked me to ask the Monday's SRU team to pass it through to -updates after it having built. Could you check? Thanks.
<ubot5`> bug 1809132 in network-manager (Ubuntu Bionic) "Updated bionic to the current 1.10 stable version" [Low,Fix committed] https://launchpad.net/bugs/1809132
<ubot5`> bug 942856 in NetworkManager "NetworkManager does not support AES-encrypted private keys for WPA 802.1x authentication" [Wishlist,Confirmed] https://launchpad.net/bugs/942856
<ubot5`> bug 1754671 in systemd (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Triaged] https://launchpad.net/bugs/1754671
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.6-0ubuntu0.18.10.1 => 1:6.1.6-0ubuntu0.18.10.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.6-0ubuntu0.18.10.1 => 1:6.1.6-0ubuntu0.18.10.2] (ubuntu-desktop)
<sil2100> tkamppeter: looking
<ddstreet> tkamppeter looks like you added test fix to n-m for lp #1825946 but there is no LP: # reference in the changelog to that bug, i can handle marking the bug for bionic, can you add the test fix to xenial as well please?
<ubot5`> Launchpad bug 1825946 in network-manager (Ubuntu Bionic) "'nm' autopkgtest fails due to GI stderr output" [Low,In progress] https://launchpad.net/bugs/1825946
<ddstreet> tkamppeter i put you on the 'assigned to' for Xenial for that bug, but feel free to remove yourself if you dont have time to apply the test fix to x
<tkamppeter> ddstreet, when discussing this on Friday with tjaalton and Laney on #ubuntu-devel, he did not tell me that this bug report exists about this problem. I got simply a proposed fix and made a debdiff from it.
<tkamppeter> ddstreet, I can generally only create a debdiff, not actually upload nm.
<ddstreet> tkamppeter ah ok, i can upload to x then
<tkamppeter> OK.
<sil2100> tkamppeter: what about LP: #1754671 ? You mention this needs an additional systemd change - does having it without the additional systemd fix cause any issues?
<ubot5`> Launchpad bug 1754671 in systemd (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Triaged] https://launchpad.net/bugs/1754671
<tkamppeter> sil2100, with the systemd fix missing bug 1754671 is simply not fixed, still showing the described issue, but this should not stop us from already putting network-manager into -updates, as the NM SRU fixes the two other bugs and does not cause any known regressions.
<ubot5`> bug 1754671 in systemd (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Triaged] https://launchpad.net/bugs/1754671
<tkamppeter> So we need not to wait for systemd to be able to land nm in -updates.
<sil2100> tkamppeter: ok
<bdmurray> sil2100: I'm hoping we could release ubuntu-release-upgrader a bit early
<bdmurray> sil2100: I've verified all the bugs and fixing the snap refresh one soonest would be good
<bdmurray> I've also another SRU in the queue to help with automatic upgrade testing.
<sil2100> bdmurray: ok, let me look at it, but releasing early seems like a good choice
<bdmurray> thanks for looking!
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.5-0ubuntu4 => 2:12.0.5-0ubuntu5] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-software (disco-proposed/main) [3.30.6-2ubuntu4 => 3.30.6-2ubuntu4.19.04.1] (ubuntu-desktop)
#ubuntu-release 2019-05-14
<vorlon> Laney: seems there's a spike in autopkgtest runner testbed failures on arm64
<vorlon> juliank: ^^
<juliank> vorlon: ack
<juliank> I see a lot of logs ending at login prompt
<juliank> which confuses me as I'd hope to get some errors
<Laney> network failed to come up?
<Laney> none of the overnight failure emails mentioned arm64, so workers seem to be recovering
<Laney> could be one compute node is wonky
<juliank> Ah yes
<juliank> Failed to sart: Waiting for network to be configured
<juliank> Also, why it thinks it saw a kernel panic, I don't know, seems like some regex is a bit wrong
<juliank> Laney: Latest failure was 3 mins ago
<Laney> it's not failing *workers* though, so seems like the retries are working
<Laney> you get 3 tries before they fall over
<juliank> yes
<juliank> only tmpfail
<Laney> is there an instance ID in there somewhere?
<Laney> IS might be able to grep logs to see if it's related to the compute node
<cpaelzer> I yesterday added dpdk-doc in the seeds to an Extra-Exclude
<cpaelzer> and I see it is gone from https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.eoan/all
<cpaelzer> while formerly it had the usual line there for auto-includes like "... Rescued from dpdk"
<cpaelzer> But in a eoan container it still is listed to be in main
<cpaelzer> I wondere if there is just time until this is effective, or if I miss another action that has to be taken
<vorlon> cpaelzer: "listed in main" is a manual processing of component-mismatches by the archive admins
<vorlon> cpaelzer: i.e. https://people.canonical.com/~ubuntu-archive/component-mismatches
<vorlon> cpaelzer: but why do you specifically want to demote these docs?
<vorlon> cpaelzer: this doesn't appear to have been required based on dependencies.  Reading https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1814060/comments/9 doesn't seem like a good reason to me to demote the docs just because the examples might be poor
<ubot5`> Ubuntu bug 1814060 in dpdk (Ubuntu) "Disco: Please remove old version 17.11 binaries that are left" [Undecided,Fix released]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.12]
<cpaelzer> vorlon: yes it is not dependencies, you think having those examples declared to be supported while not being particularly great or reliable is not an issue
<cpaelzer> I really think that puts too much expectations on them wich they might not hold
<vorlon> cpaelzer: I don't think code examples in docs are ever "supported" and I have never had a bug report from someone who assumed they were
<vorlon> I think you're trying to hold this package to a much different standard than the rest of the docs packages in main
<cpaelzer> I was cleaning up dpdk depedencies in general, mostly focussed on the binaries - many of the awkward/experimental ones are now in universe which is great. cleaning up dpdk-doc was just a tail end cleanup
<cpaelzer> but your experience on these cases clearly beats mine, so I'm ok following you
<cpaelzer> I'll remove the Extra-exclude then
<cpaelzer> I may quote you on the bug so that anyone coming by later (including myself) remembers then
<cpaelzer> thanks vorlon
<vorlon> that's fine, quote away :)
<cpaelzer> vorlon: to complete my mindset on this, that "standard" we hold these packages to only applies to -doc and not to all packages that deliver an uncompiled source - so a -dev that wants to be in main would still have to be "better" right?
<vorlon> cpaelzer: well, -dev in main we would certainly expect to be usable for compilation :)
<cpaelzer> hehe, that even the examples in said -doc might have been :-)
<cpaelzer> vorlon: I hope you can enjoy the sprint (location) - not further distracting you for now
<vorlon> :)
<mwhudson> hmm anyone around to release livecd-rootfs?
<tkamppeter> bdmurray, RAOF, hi
<tkamppeter>  bdmurray, RAOF, on the Bionic modemmanager SRU for bug 1819615 the autopkg tests have passed now, so it should be ready for -updates.
<ubot5`> bug 1819615 in OEM Priority Project "For additional hardware support, modemmanager needs to be upgraded to 1.10 on Bionic" [Critical,In progress] https://launchpad.net/bugs/1819615
<vorlon> mwhudson: done
<mwhudson> vorlon: yay
<mwhudson> vorlon: thanks
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (disco-proposed/main) [1.6+19.04ubuntu1 => 1.7+19.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (bionic-proposed/main) [1.6+18.04ubuntu1 => 1.7+18.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/main) [1.6+16.04ubuntu1 => 1.7+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (cosmic-proposed/main) [1.6+18.10ubuntu1 => 1.7+18.10ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190409.1-0ubuntu0.18.04.1 => 1:20190514.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190409.1-0ubuntu1 => 1:20190514.1-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190409.1-0ubuntu0.18.10.1 => 1:20190514.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190409.1-0ubuntu0.16.04.1 => 1:20190514.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20190514.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190514.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190514.1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190514.1-0ubuntu0.16.04.1]
<vorlon> seb128: so you closed your block-proposed bug again?  Do you want to reopen it and redemote, so that we can clean up the NBS old library versions? :)
<seb128> bah, let me fix that. I expected that the old binaries would have stopped being available when the new version migrated and such those demoted packages would have stayed in eoan-proposed without the blocking bug
-queuebot:#ubuntu-release- Unapproved: biosdevname (bionic-proposed/universe) [0.4.1-0ubuntu10 => 0.4.1-0ubuntu10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: biosdevname (xenial-proposed/universe) [0.4.1-0ubuntu9 => 0.4.1-0ubuntu9.1] (no packageset)
<LocutusOfBorg> rmadison -u ubuntu libllvm8
<LocutusOfBorg>  libllvm8 | 1:8~svn342638-1     | cosmic-proposed/universe | i386, s390x
<LocutusOfBorg> what does this mean? the cosmic proposed archive cleanup and copy to disco failed for that library?
 * LocutusOfBorg is happy that llvm-toolchain-snapshot is now gone for good
<ddstreet> bdmurray apw can you push out debootstrap for cosmic for lp #1825250?  it will fix pbuilder autopkgtest regressions for my upload of debconf
<ubot5`> Launchpad bug 1825250 in resource-agents (Debian) "ethmonitor does not list interfaces without assigned IP address" [Unknown,New] https://launchpad.net/bugs/1825250
<ddstreet> sorry wrong bug, i meant lp #1825994 is the bug for debootstrap
<ubot5`> Launchpad bug 1825994 in debootstrap (Ubuntu Cosmic) "Add Ubuntu Eoan as a known release" [High,Fix committed] https://launchpad.net/bugs/1825994
<bdmurray> ddstreet: Have you looked at the lxc ppc64el autopkgtest regression?
<ddstreet> bdmurray yes, the test is flaky; i'm re-running it now
<ddstreet> but i'll add a comment indicating that the test is flaky
<bdmurray> ddstreet: great, thanks
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.5-45-g3554ffe8-0ubuntu1~18.10.1 => 19.1-1-gbaa47854-0ubuntu1~18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.5-45-g3554ffe8-0ubuntu1~18.04.1 => 19.1-1-gbaa47854-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.5-45-g3554ffe8-0ubuntu1~16.04.1 => 19.1-1-gbaa47854-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11.8]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-50.54] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1018.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-50.54] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1011.12~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1032.34] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-15.16~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1032.34] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-20.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-15.16~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1038.43] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-20.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.0.0-15.16~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1013.15] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1007.8] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1011.12] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1018.18] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1006.6] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1006.6] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-148.174] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1045.49] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-50.54~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1032.34~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-50.54~16.04.1] (kernel)
<cascardo> bdmurray: is there anything pending for cosmic and bionic SRUs of initramfs-tools ?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-50.54]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1013.15~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-50.54]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1018.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1011.12~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1032.34~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-50.54~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-148.174]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1045.49]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1013.15~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-50.54~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1032.34]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1032.34]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-15.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-15.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-15.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-20.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-20.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1038.43]
<bdmurray> cascardo: I'm sorry I don't understand what you mean by "anything pending".
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1007.8]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1013.15]
<cascardo> bdmurray: the upload has been in the queue for a while, I wanted to know if there is anything that has prevented it from being accepted into -proposed
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1018.18]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1011.12]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1006.6]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1006.6]
<bdmurray> cascardo: I'm not aware of anything. Frequently around release team, end of April and October, the SRU review queues develop a backlog as the SRU team is also busy with the development release.
<bdmurray> release time not release team
<bdmurray> cascardo: If you'd like it reviewed quickly ping the SRU person on duty for the day, which I guess is me!
<bdmurray> cascardo: Do you want me to review it today?
<cascardo> bdmurray: sure, please!
<bdmurray> sil2100: bug 1828827 is missing an Ubuntu package task.
<ubot5`> bug 1828827 in Ubuntu Image "SRU 1.7 tracking bug" [High,In progress] https://launchpad.net/bugs/1828827
<bdmurray> sil2100: s/is/was/
<bdmurray> Oh, no wait LP hates me.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (disco-proposed) [1.7+19.04ubuntu1]
-queuebot:#ubuntu-release- New source: hy (eoan-proposed/primary) [0.16.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: dmarc-cat [i386] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [s390x] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [amd64] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [arm64] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [ppc64el] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [armhf] (eoan-proposed/universe) [0.9.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-170.220] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-148.174~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1045.49~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-170.220]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1045.49~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-148.174~14.04.1]
<LocutusOfBorg> please reject hy from queue, needs some more fixes...
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (cosmic-proposed) [1.7+18.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.7+18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.7+16.04ubuntu1]
<blackboxsw> bdmurray: not sure if it's getting too close to EOD (or already passed ;) )  if there is a chance today to peek at cloud-init's queued SRU into xenial, bionic, cosmic and disco we have a couple of things in the queue for a 19.1.1 SRU.    https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1828637
<ubot5`> Ubuntu bug 1828637 in cloud-init (Ubuntu) "sru cloud-init (18.5-45 to 19.1.1) Xenial, Bionic, Cosmic, Disco" [Undecided,In progress]
<blackboxsw> otherwise I can pick it up tomorrow with the SRU-team vanguards
<bdmurray> blackboxsw: I'm UTC -7 or so, so I've a bit to go.
 * blackboxsw wasn't sure if you were @ home or @ sprint     for the above cloud-int SRU disco is straight forward.  The  xenial,bionic and cosmic SRU contains a single additional patch to revert changes in tip for cc_ubuntu_advantage.py because ubuntu-advantage-tools has not SRU'd yet for Xenial, Bionic or Cosmic.
<blackboxsw> bdmurray: thanks for peeking if there is time
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (cosmic-proposed) [0.131ubuntu15.2]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.8]
<bdmurray> blackboxsw: bug 1828479 has no ubuntu tasks which is awkward / more work for the SRU team
<ubot5`> bug 1828479 in cloud-init "Release 19.1" [Undecided,Fix released] https://launchpad.net/bugs/1828479
<bdmurray> same with bug 1825596
<ubot5`> bug 1825596 in cloud-init "Azure reboot with unformatted ephemeral drive won't mount reformatted volume" [High,Fix released] https://launchpad.net/bugs/1825596
<bdmurray> and bug 1825253
<ubot5`> bug 1825253 in cloud-init "Unit tests with filesystem-related mocks fail in SeLinuxGuard when run on RHEL or CentOS" [Undecided,Fix released] https://launchpad.net/bugs/1825253
<bdmurray> and bug 1645824
<ubot5`> bug 1645824 in cloud-init "NoCloud source doesn't work on FreeBSD" [Medium,Fix released] https://launchpad.net/bugs/1645824
<bdmurray> and a bunch of those are missing SRU bug template information
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (cosmic-proposed) [3:14.0.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.2-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu6]
#ubuntu-release 2019-05-15
<LocutusOfBorg> hello please reject hy from queue, needs some more fixes...
-queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (xenial-proposed) [7.0.33-0ubuntu0.16.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-settings-daemon [source] (xenial-proposed) [3.18.2-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: rejected udisks2 [source] (xenial-proposed) [2.1.7-1ubuntu2]
<slashd> sil2100, o/ by curiosity did you notice the following : http://autopkgtest.ubuntu.com/packages/r/resource-agents/bionic/armhf it showing 'code 14' instead of passed or fails
<slashd> ddstreet, ^
<ddstreet> yeah it's a real failure, halves is working on fixing it in lp #1828258
<ubot5`> Launchpad bug 1828258 in resource-agents (Ubuntu Eoan) "ldirectord systemd service fails if no /var/lock/subsys dir" [Medium,In progress] https://launchpad.net/bugs/1828258
<ddstreet> i think 'code 14' means it couldn't install all test deps
<slashd> ddstreet, thanks
<halves> slashd ddstreet currently waiting on upstream for the ldirectord one https://github.com/ClusterLabs/resource-agents/pull/1328
<gitbot> ClusterLabs issue (Pull request) 1328 in resource-agents "ldirectord: Remove /var/lock from systemd unit" [Open]
<acheronuk> 14 erroneous package and at least one test skipped
 * acheronuk just learned something ^
<slashd>      14   erroneous package and at least one test skipped
<slashd> right ^
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu7]
<vorlon> how are the ubuntu and ubuntu-mate bionic dailies oversized by exactly the same amount >_<
-queuebot:#ubuntu-release- Unapproved: accepted metaphlan2 [source] (bionic-proposed) [2.7.5-1ubuntu1]
<rbasak> Could an SRU team member please review lexicon in Bionic and Cosmic? I can't do it as I sponsored.
<vorlon> rbasak: my rule of thumb is that if I didn't modify the package as part of sponsorship, I can wear both hats
<rbasak> vorlon: I'm reluctant to do that. I sponsored for a non-uploader, and I don't think I want to be the only barrier to introducing a mistake (as the sponsoree supposedly isn't qualified; otherwise they'd be an uploader)
<vorlon> right, I disagree, but I can't force you to self-review ;)
<Laney> desktop-icons incoming with a wrong version, please reject it :|
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (disco-proposed/main) [19.01.1-1 => 19.01.3-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (disco-proposed/main) [19.01.1-1 => 19.01.3-1~ubuntu19.04.1] (ubuntu-desktop)
<Laney> second one there is better
<Laney> also, retrying all arm64 failures
<Laney> one of the clouds is having a bad day and I've taken it out of rotation
<Laney> done
<blackboxsw> bdmurray: sorry for the lack of response yesterday, I got pulled away.   Cloud-init follows an SRU exception @ https://wiki.ubuntu.com/CloudinitUpdates  where we only provide a single SRU process bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1828637, We have an exception do to extensive CI plus manual cloud-testing during verification
<ubot5`> Ubuntu bug 1828637 in cloud-init (Ubuntu) "sru cloud-init (18.5-45 to 19.1.1) Xenial, Bionic, Cosmic, Disco" [Undecided,In progress]
<blackboxsw> so none of the other 'bugs' related to that SRU will carry SRU templates anymore
<bdmurray> blackboxsw: then don't reference them in Launchpad-Bugs-Fixed
<blackboxsw> we additionally still perform some level of manual verification on those bugs, which we track over in https://github.com/cloud-init/ubuntu-sru/tree/master/20190514
 * blackboxsw checks, I maybe botched the sru proposal.
<bdmurray> blackboxsw: Launchpad-Bugs-Fixed is created from the LP: # entries in the debian/changelog file.
<blackboxsw> bdmurray: ubuntu/xenial, bionic, cosmic  debian/changelog only carries two bugs LP: #1828641 and LP: #1828637.....
<ubot5`> Launchpad bug 1828641 in cloud-init "Xenial, Bionic, Cosmic revert ubuntu-advantage-tools config module changes from tip" [Undecided,In progress] https://launchpad.net/bugs/1828641
<ubot5`> Launchpad bug 1828637 in cloud-init (Ubuntu) "sru cloud-init (18.5-45 to 19.1.1) Xenial, Bionic, Cosmic, Disco" [Undecided,In progress] https://launchpad.net/bugs/1828637
<blackboxsw> bdmurray: ahh the disco proposal is broken... our publishing scripts didn't recognize it as a 'release/sru' distro series
<bdmurray> blackboxsw: The disco one has a whole bunch - https://launchpadlibrarian.net/423221370/cloud-init_18.5-62-g6322c2dd-0ubuntu1_19.1-1-gbaa47854-0ubuntu1~19.04.1.diff.gz
<blackboxsw> thanks for catching that, I'll fix that and re-push disco
<blackboxsw> xenial/bionic/cosmic should be sane disco I'll fix now
<bdmurray> blackboxsw: ah yeah, cosmic looks good. I just didn't pass GO after seeing disco
<blackboxsw> thanks again bdmurray
<blackboxsw> makes sense to me
<bdmurray> blackboxsw: Okay, I'll reject disco and feel free to ping me when its ready for rereview
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (disco-proposed) [19.1-1-gbaa47854-0ubuntu1~19.04.1]
<blackboxsw> bdmurray: do I need to also change the version on disco from 19.1-1-gbaa47854-0ubuntu1~19.04.1 to 19.1-1-gbaa47854-0ubuntu1~19.04.2 so I can re-upload with fixed changelog. or can I re-use 19.1-1-gbaa47854-0ubuntu1~19.04.1 now that it's rejected
<blackboxsw> since it never officially got into -proposed
<bdmurray> blackboxsw: You can reuse it since it never appeared in the archive but you'll need to upload with dput -f
<blackboxsw> excellent thanks, just fixed disco
-queuebot:#ubuntu-release- Unapproved: accepted lexicon [source] (cosmic-proposed) [2.7.0-1ubuntu0.1]
<blackboxsw> bdmurray: I haven't seen arges in a while . is he still SRU publishing vanguard on wednesdays? per https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<bdmurray> blackboxsw: I haven't seen him in a while either
<blackboxsw> or should we generally try rbasak on wednesdays
<blackboxsw> and/or update the table in the wiki?
 * blackboxsw isn't sure how that SRU vanguard process is sorted
<bdmurray> blackboxsw: The SRU team should probably check in with him.
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.8 => 0.96.24.32.9] (desktop-core, ubuntu-server)
<bdmurray> blackboxsw: what did "just fixed disco" mean? I don't see it in the queue.
<blackboxsw> bdmurray: /me checks  if the upload got rejected due to lints etc.....
<blackboxsw> I uploaded a new disco release afaict....verifying
<blackboxsw> hrm. .. looked ok from my cli .... https://pastebin.ubuntu.com/p/2j2bxQVwyK/  will re-attempt (I also see nothing in the queue)
<blackboxsw> hrm Package has already been uploaded to ubuntu on upload.ubuntu.com
<blackboxsw> ok removing the stock upload file that blocked me
<blackboxsw> from the first upload
<blackboxsw> bdmurray: I manually dput the package again after removing the corresponding cloud-init_19.1-1-gbaa47854-0ubuntu1~19.04.1_source.ubuntu.upload. My dput CLI claims it successfully uploaded packages.  Yet I don't see cloud-init in any state in the New or Unapproved queues @ https://launchpad.net/ubuntu/disco/+queue?queue_state=0&queue_text=cloud-init.   Is it possible that my reusing the same version string as is
<blackboxsw> currently 'Rejected' upload causes a hiccup here?
<bdmurray> blackboxsw: can I see you source.changes file?
<blackboxsw> bdmurray: https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=cloud-init
<blackboxsw> oops
<blackboxsw> bdmurray: https://paste.ubuntu.com/p/qcqDRtgtZz/
<bdmurray> That looks sane to me.
<bdmurray> Have you gotten an email about the upload?
<blackboxsw> ahh just did, I hadn't earlier
<blackboxsw> Files specified in DSC are broken or missing, skipping package unpack verification.
<blackboxsw> ok
<blackboxsw> File cloud-init_19.1-1-gbaa47854.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<blackboxsw> ok I've referenced an invalid orig tar.
<blackboxsw> will really fix it. I had a cached file locally that was referenced incorrectly.
<blackboxsw> once sorted and in the queue properly I'll ping or I can table this for next SRU vanguard tomorrow if preferred.
<bdmurray> I'm here all day.
<blackboxsw> heh, excellent
<blackboxsw> ok bdmurray, let's try this song again. unapproved queue shows the upload for disco now v
<blackboxsw> https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=cloud-init
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [18.5-62-g6322c2dd-0ubuntu1 => 19.1-1-gbaa47854-0ubuntu1~19.04.1] (core, edubuntu, ubuntu-cloud)
<blackboxsw> thx queuebot
<blackboxsw> :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.32 => 1:18.04.33] (core)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.1-1-gbaa47854-0ubuntu1~19.04.1]
<bdmurray> blackboxsw: Hey there again. Can you explain the plan regarding bug 1828641 a bit more to me? It seems to me like there is going to be a cloud-init upload, then an u-a upload, then another cloud-init upload. Is that right?
<ubot5`> bug 1828641 in cloud-init "Xenial, Bionic, Cosmic revert ubuntu-advantage-tools config module changes from tip" [Undecided,In progress] https://launchpad.net/bugs/1828641
<blackboxsw> bdmurray: correct, there is active development that my squad owns that will ultimately result in an SRU of ubuntu-advantage-tools 19.1 or later into Trusty, Xenial, Bionic, and Disco... It will ultimately change the ubuntu-advantage-tools CLI to match what cloud-init tip(Disco and Eoan) currently supports in the ubuntu_advantage.py cloud-config module
<blackboxsw> likely we will need to SRU ubuntu-advantage-tools 19.1 into cosmic too, so we don't carry different versions of the ubuntu-advantage-tools CLI around
<blackboxsw> so when ubuntu-advantage-tools 19.1 SRUs, we'll drop the debian/patch from cloud-init for each series
<blackboxsw> so basically we'll have to tightly couple  the cloud-init (xenial/bionic/cosmic) and ubuntu-advantage-tools 19.1 SRU
<bdmurray> blackboxsw: there isn't a way to make cloud-init handle either ubuntu-advantage?
<blackboxsw> bdmurray: there is not a away because the 'old' ubuntu-advantage-tools (v <= 18) expects a user to have specific tokens for the related support services (livepatch, esm, fips) in order to enable services. The new ubuntu-advantage-tools  is able to obtain those tokens credentials from the backend service and doesn't require the use of those tokens on the commandline. The cloud-init team decided that because
<blackboxsw> ubuntu-advantage-tools was breaking cli compatibility and because ua-tools decided explicitly to not to support an upgrade path from old ua-tools to new ua-tools that cloud-init would not try to support both old and new. The expectation is that for specific ubuntu-advantage-tools customer with support agreements, there will be some hand-holding to migrate supported users from old version to new version of
<blackboxsw> ubuntu-advantage-tools.
<blackboxsw> bdmurray: .... well there is a 'way' for cloud-init to support both syntaxes in the ubuntu-advantage cloud-config, since the config directive keys are different in cloud-init. cloud-init *could* carry the burden of supporting both, but it was suggested that it wasn't worth it for this use case
<bdmurray> blackboxsw: its up you y'all since you'll be doing the extra upload of cloud-init.
<bdmurray> anyway it'll be important to get the debian/control changes right for the next uploads
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [19.1-1-gbaa47854-0ubuntu1~18.10.1]
<blackboxsw> bdmurray: for this case during the SRU of ubuntu-advantage-tools 19.1 (new) SRU. I'm wondering how best to express the minimum version requirement of an optional package dependency...... maybe Conflicts: ubuntu-advantage-tools < 19?
<blackboxsw> the conflicts would be in cloud-init's debian/control.
<blackboxsw> we'll make sure we call that out in our SRU process for next release.
<Eickmeyer> vorlon: Where did we land on lsp-plugins? Would it help if I created a separate package (named something like, liblsp) that contained only the shared object that gets installed into /usr/lib? I understand your reluctance, but there's many other packages that install items directly to that directory.
<bdmurray> blackboxsw: Your bionic changelog references u-a 19.1 and xenial. I'm willing to overlook it but thought I should mention it. https://launchpadlibrarian.net/423714836/cloud-init_18.5-45-g3554ffe8-0ubuntu1~18.04.1_19.1-1-gbaa47854-0ubuntu1~18.04.1.diff.gz
<blackboxsw> bah +1. can repush if that's easier (then we don't have to worry about cleanup or referencing the wrong distro in a changelog
<blackboxsw> bdmurray: ok for me to rebuild-push and get that up in 10 mins?
<bdmurray> blackboxsw: sure
<blackboxsw> s/xenial/bionic in the changelog
<blackboxsw> ok
<blackboxsw> working it
<blackboxsw> bdmurray: will you be rejecting bioinic queue?
<blackboxsw> so I can reuse the same changelog ver
<bdmurray> blackboxsw: You can still reuse it but yes
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [19.1-1-gbaa47854-0ubuntu1~18.04.1]
<blackboxsw> thanks bdmurray new dput is up for bionic
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.5-45-g3554ffe8-0ubuntu1~18.04.1 => 19.1-1-gbaa47854-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> thank you sire
<blackboxsw> *sir
 * infinity prefers sire.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.1-1-gbaa47854-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.1-1-gbaa47854-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.7]
<vorlon> Eickmeyer: a separate liblsp package definitely does not help.  As far as I'm concerned, the path lookup code needs to be cleaned up, and the file which is not a shared library (because it has no soname) needs to be moved into a subdirectory
<Eickmeyer> vorlon: I can't clean up the code, I lack the know-how. What if it was in a subdirectory and then a symbollic link was created in the /usr/lib directory?
<vorlon> no
<vorlon>  /usr/lib needs to be kept clean
<Eickmeyer> Then why are there other non-shared libraries there?
-queuebot:#ubuntu-release- New binary: dhcpoptinj [s390x] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblopsub [s390x] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [s390x] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-neotree [amd64] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [s390x] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpoptinj [amd64] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpoptinj [ppc64el] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblopsub [ppc64el] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fontbitstreamvera [amd64] (eoan-proposed/universe) [0.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpoptinj [i386] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rhdf5 [s390x] (eoan-proposed/universe) [2.26.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblopsub [amd64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [amd64] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblopsub [i386] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rhdf5 [ppc64el] (eoan-proposed/universe) [2.26.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [amd64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [ppc64el] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggthemes [amd64] (eoan-proposed/universe) [4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [ppc64el] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rhdf5 [amd64] (eoan-proposed/universe) [2.26.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [i386] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-venndiagram [amd64] (eoan-proposed/universe) [1.6.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [s390x] (eoan-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fontliberation [amd64] (eoan-proposed/universe) [0.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpoptinj [arm64] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [amd64] (eoan-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [ppc64el] (eoan-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [i386] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dhcpoptinj [armhf] (eoan-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [arm64] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [i386] (eoan-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblopsub [arm64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rhdf5 [armhf] (eoan-proposed/universe) [2.26.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [armhf] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rhdf5 [arm64] (eoan-proposed/universe) [2.26.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [armhf] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diffobj [arm64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
<Eickmeyer> vorlon: Filed an issue on Github, hopefully it'll get somewhere: https://github.com/sadko4u/lsp-plugins/issues/49
<gitbot> sadko4u issue 49 in lsp-plugins "lsp-plugins-jack-core-1.1.9.so installs to /usr/lib" [Open]
-queuebot:#ubuntu-release- New binary: liblopsub [armhf] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [arm64] (eoan-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-apcluster [armhf] (eoan-proposed/universe) [1.4.7-1] (no packageset)
#ubuntu-release 2019-05-16
<Eickmeyer> vorlon: Good news! Upon inspection, I discovered that the standalone jack clients in /usr/bin are not required to run the plugins in LV2/LADSPA/VST formats. I'm removing the standalone plugins until upstream fixes the bug. Should be good as soon as I push the commit.
<Eickmeyer> That removes the /usr/lib/*.so file.
<mwhudson> so i have a runc SRU for xenial that does not and is never going to build on powerpc
<mwhudson> we've handled cases like this before but i can't remember how
-queuebot:#ubuntu-release- Unapproved: containerd (xenial-proposed/universe) [1.2.6-0ubuntu1~16.04.1 => 1.2.6-0ubuntu1~16.04.2] (no packageset)
<mwhudson> RAOF: any chance you could whisk that containerd upload through? the diff is very tiny
<RAOF> mwhudson: Sure. Enjoy!
<mwhudson> RAOF: thanks!!
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (xenial-proposed) [1.2.6-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lexicon [source] (bionic-proposed) [2.2.1-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell-extension-desktop-icons [source] (disco-proposed) [19.01.3-1ubuntu1]
<ddstreet> sil2100 do you know of any problems going on with autopkgtest.u.c?  all the i386/amd64 systemd autopkgtests have been failing in a weird way since a few days ago (may 13)
<ddstreet> it seems to be only i386/amd64 arch though...maybe something going on with scalingstack only for that arch?
<ddstreet> like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20190515_050445_eecd2@/log.gz
<ddstreet> <VirtSubproc>: failure: Timed out on waiting for ssh connection
<ddstreet> autopkgtest [05:04:45]: ERROR: testbed failure: cannot send to testbed: [Errno 32] Broken pipe
<ddstreet> xnox maybe you know? ^
<ddstreet> sil2100 cpaelzer for lp #1829245, do you think we should release qemu for x with a reverted patch immediately to fix the regression?  since it has a security patch on top of it, we can't just revert to pre-my patch
<ubot5`> Launchpad bug 1829245 in qemu (Ubuntu) "Networking issues after upgrade to 1:2.5+dfsg-5ubuntu10.37" [Undecided,New] https://launchpad.net/bugs/1829245
<ddstreet> i do have the patch to fix it though, so i can upload that immediately, if we want to just fix it instead of reverting
<cpaelzer> I have seen the PPA with the fix
<cpaelzer> you could ask security to push a revert of just your change
<cpaelzer> as this went to -security the fix needs to go there as well
<cpaelzer> and then take time to re-eval your fix + the fixup that you now have
<ddstreet> cpaelzer sure; sbeattie i believe you pushed the qemu security release for xenial, right?  can you push another with my patches removed to fix this regression?
<cpaelzer> he might be off atm, lets ping mdeslaur
<cpaelzer> hmm might also not be here yet
<cpaelzer> leosilva: ^^
<cpaelzer> not sure if you want/can take over for the others
<leosilva> let me check.
<leosilva> ewww qemu
<ddstreet> coreycb fyi ^ qemu in mitaka and ocata will need another patch
<cpaelzer> I'm holding back my change that I have queued up (xenial) ...
<cpaelzer> ddstreet: once you are about to enter another normal SRU phase let me know
<cpaelzer> I'd like to bundle another fix there then
<ddstreet> cpaelzer once the security regression fix drops, i can provide a debdiff for you to bundle in your upload, if you want
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-149.175] (core, kernel)
<cpaelzer> ddstreet: just grab the fix in 1828288 to be tested and pushed with yours then
<ddstreet> ack will do
<cpaelzer> now lets revert and sort the current issue first, and for that I'll shut up and let you coordinate that
<leosilva> cpaelzer: Marc is around, so you guys can coordinate with him :)
<mdeslaur> cpaelzer, ddstreet: I'll do the qemu revert
<mdeslaur> cpaelzer, ddstreet: just xenial?
<cpaelzer> yep the fix of ddstreet was only part of xenial
<cpaelzer> and UCA-mitaka afterwards I guess
<ddstreet> UCA mitaka/ocata also
<ddstreet> i assume coreycb can handle those
<ddstreet> if he's in
<mdeslaur> ddstreet: which patch do you want me to revert?
<ddstreet> mdeslaur just to be safe, drop both of them
<ddstreet>   * d/p/lp1823458/add-VirtIONet-vhost_stopped-flag-to-prevent-multiple.patch,
<ddstreet>     d/p/lp1823458/do-not-call-vhost_net_cleanup-on-running-net-from-ch.patch:
<ddstreet> i'll reupload with the third patch to fix the regression
<mdeslaur> ddstreet: ok, thanks
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-149.175]
<mdeslaur> ddstreet: are you not confident in your new one-line fix enough for me to simply push that instead?
<ddstreet> mdeslaur i am confident, but i defer to cpaelzer on wanting more testing for it
<mdeslaur> ok, will revert, thanks
<cpaelzer> mdeslaur: it was broken once, while it will be extra delay giving it an extra round of testing seems right
<sil2100> ddstreet: hm, I did notice some strangeness recently, but I didn't look into that yet
<coreycb> ddstreet: ok dropping d/p/lp1823458/* from qemu in ocata correct?
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (disco-proposed) [2.0.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: openvpn (bionic-proposed/main) [2.4.4-2ubuntu1.2 => 2.4.4-2ubuntu1.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openvpn (cosmic-proposed/main) [2.4.6-1ubuntu2.1 => 2.4.6-1ubuntu2.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openvpn (disco-proposed/main) [2.4.6-1ubuntu3 => 2.4.6-1ubuntu3.1] (ubuntu-desktop, ubuntu-server)
<ddstreet> coreycb yep that is correct, thanks - i opened a new bug lp #1829380 to re-add those 2 patches plus another to fix the regression
<ubot5`> Launchpad bug 1829380 in qemu (Ubuntu Xenial) "race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu (fix regression)" [Undecided,New] https://launchpad.net/bugs/1829380
<coreycb> ddstreet: ok will the new patch be available soon?
<ddstreet> coreycb yep, i have it ready
<coreycb> ddstreet: ok cool, in that case i won't revert the 2 other patches. i also have some CVEs going into ocata that I can pair it up with.
<ddstreet> ok great, i'll add just the regression-fix patch to the new lp bug, you can pick it up from there
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (cosmic-proposed) [1:6.1.6-0ubuntu0.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.6-0ubuntu0.18.10.2]
<coreycb> ddstreet: great thanks
<ddstreet> for mitaka it can go thru the normal xenial->mitaka process i assume
<coreycb> ddstreet: yep
<cpaelzer> sil2100: I have looked at diaspora-installer @ ppc64 - no low hanging fruits there unfortunately
<cpaelzer> sil2100: is it ok to release the SRU to unbreak all other arches at least?
<sil2100> cpaelzer: yeah, thanks for looking at it!
<sil2100> (now released)
<cpaelzer> thank you
<LocutusOfBorg> cpaelzer, thanks for the kronosnet review! awesome! do you know which team might be subscribed to it?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-51.55] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-51.55] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-51.55]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-51.55]
<cpaelzer> LocutusOfBorg: since it is out of the HA stack I guess "us"
<cpaelzer> powersj would be the one to ping
<cpaelzer> LocutusOfBorg: but you wait for security review anyway atm
<cpaelzer> our usual steps are MIR review -> Security Review -> subscribe -> promote
<cpaelzer> an easlier subscription messes up our triage tools
<cpaelzer> s/easlier/earlier/
<cyphermox> sil2100: there's a netplan.io SRU for bionic and above currently in progress; I believe we could (and should) waive the 7 day period (it's 6 days old anyway) to provide this important fix for compat with openstack. bug 1828299
<ubot5`> bug 1828299 in netplan.io (Ubuntu Disco) "update to netplan.io 0.97" [Undecided,Fix committed] https://launchpad.net/bugs/1828299
<cyphermox> jamespage: ^
<jamespage> cyphermox: +1 yes please :)
<cyphermox> sil2100: vorlon is aware of this; he just might be a little hard to reach right now.
<vorlon> sil2100: and I do +1 this on principle but shouldn't do the release myself
<coreycb> ddstreet: can i use that patch that's appended to the bug for ocata?
<ddstreet> coreycb yep, it should apply with only offset
<coreycb> ddstreet: cool
<coreycb> ddstreet: and did that land upstream?
<ddstreet> coreycb no, the original patch, and this regression fix, are a minimal workaround, as bionic and later handle the problem differently
<coreycb> ddstreet: ok
<LocutusOfBorg> cpaelzer, sure!
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu2.2 => 2:19.0.0-0ubuntu2.3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.1.0-0ubuntu2 => 2:18.1.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu2.2 => 2:19.0.0-0ubuntu2.3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.1.0-0ubuntu2 => 2:18.1.0-0ubuntu3] (openstack, ubuntu-server)
<Eickmeyer> vorlon: upstream on lsp-plugins got back to me and made the change.
<Eickmeyer> vorlon: Added the patch, should be good. Can't do much testing until later, but if you'd like to re-review the package I'd appreciate it.
<bdmurray> sil2100: Could you look at the SRU queue for bionic for ubuntu-release-upgrader?
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.3]
<sil2100> bdmurray: ACK
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (disco-proposed) [2:19.0.0-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: octavia (disco-proposed/universe) [4.0.0-0ubuntu1 => 4.0.0-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu2.2 => 2:19.0.0-0ubuntu2.3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (disco-proposed) [2:19.0.0-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.0-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (cosmic-proposed) [2:18.1.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.1.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.33]
-queuebot:#ubuntu-release- New binary: libpmemobj-cpp [amd64] (eoan-proposed/universe) [1.5.1-1ubuntu1] (no packageset)
<ahasenack> hi archive admins, libpmemobj-cpp was originally a sync from debian, stuck because of missing dependencies
<ahasenack> I fixed those dependencies, and had to add delta
<ahasenack> and that became 1.5.1-1ubuntu1 above
<ahasenack> the missing dependency was pmdk 1.5.1, which I also uploaded
<ahasenack> (we had 1.4.1-0ubuntu1 before)
<ahasenack> https://launchpad.net/ubuntu/+source/libpmemobj-cpp/+publishinghistory
-queuebot:#ubuntu-release- New: accepted libpmemobj-cpp [amd64] (eoan-proposed) [1.5.1-1ubuntu1]
<ahasenack> thanks!
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.39 => 1:2.5+dfsg-5ubuntu10.40] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [arm64] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [arm64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rhdf5 [arm64] (eoan-proposed) [2.26.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [arm64] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [ppc64el] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [armhf] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted umis [armhf] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [armhf] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rhdf5 [armhf] (eoan-proposed) [2.26.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [arm64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [armhf] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted umis [arm64] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [armhf] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [amd64] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [ppc64el] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted emacs-neotree [amd64] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [i386] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [s390x] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rhdf5 [ppc64el] (eoan-proposed) [2.26.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [amd64] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [s390x] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [i386] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [s390x] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [i386] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [amd64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rhdf5 [amd64] (eoan-proposed) [2.26.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-apcluster [i386] (eoan-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [ppc64el] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fontliberation [amd64] (eoan-proposed) [0.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-venndiagram [amd64] (eoan-proposed) [1.6.20-1]
-queuebot:#ubuntu-release- New: accepted umis [i386] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted umis [s390x] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted dhcpoptinj [s390x] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rhdf5 [s390x] (eoan-proposed) [2.26.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fontbitstreamvera [amd64] (eoan-proposed) [0.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umis [amd64] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted liblopsub [ppc64el] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggthemes [amd64] (eoan-proposed) [4.1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diffobj [amd64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted umis [ppc64el] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New binary: r-cran-fontquiver [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-other-wasabi [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: upass [amd64] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-remyoudompheng-go-liblzma [amd64] (eoan-proposed/none) [0.0~git20190506.81bf2d4-1] (no packageset)
#ubuntu-release 2019-05-17
-queuebot:#ubuntu-release- New binary: rustc [s390x] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [i386] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (disco-proposed/main) [5.0.0-1ubuntu2.1 => 5.0.0-1ubuntu2.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.5-7~ubuntu0.18.04.1 => 2:10.3.10-1~ubuntu0.18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (cosmic-proposed/main) [2:10.3.5-7~ubuntu0.18.10.1 => 2:10.3.10-1~ubuntu0.18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [193-1~ubuntu19.04.1 => 194-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [194-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- New binary: rustc [armhf] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [193-1~ubuntu18.10.1 => 194-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [194-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- New binary: rustc [arm64] (eoan-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [193-1~ubuntu18.04.1 => 194-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [194-1~ubuntu18.04.1]
<vorlon> Eickmeyer: can you resend me the link for the lsp-plugins repo?
<Eickmeyer[m]> vorlon: https://launchpad.net/lap-plugins
<Eickmeyer[m]> Ignore that.
<Eickmeyer[m]> vorlon: https://launchpad.net/lsp-plugins
 * Eickmeyer[m] is on an away trip
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-16.17]
<vorlon> Eickmeyer[m]: 'lsp-plusins-jack' looks spelled wrong in your debian/control
<vorlon> Eickmeyer[m]: fixed that and uploaded to the NEW queue now, cheers!
-queuebot:#ubuntu-release- New source: lsp-plugins (eoan-proposed/primary) [1.1.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-remyoudompheng-go-liblzma [amd64] (eoan-proposed) [0.0~git20190506.81bf2d4-1]
-queuebot:#ubuntu-release- New: accepted r-other-wasabi [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fontquiver [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted upass [amd64] (eoan-proposed) [0.3.0-1]
<infinity> ?win 165
-queuebot:#ubuntu-release- Unapproved: dkms (disco-proposed/main) [2.6.1-4ubuntu2 => 2.6.1-4ubuntu2.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dkms (cosmic-proposed/main) [2.3-3ubuntu11 => 2.3-3ubuntu11.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9.2 => 2.3-3ubuntu9.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.6 => 2.2.0.3-2ubuntu11.7] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: apt-setup (bionic-proposed/main) [1:0.104ubuntu5 => 1:0.104ubuntu5.1] (core)
<LocutusOfBorg> xnox, there are some curl test failures e.g. apache2 that might be related to openssl uploads... do you think you can take another round on them?
<LocutusOfBorg> also systemd on i386 needs fixes or an hint, not sure which one is better...
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.23 => 2.525.24] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.45 => 2.408.46] (desktop-core)
<rbalint> tjaalton, vorlon could you please accept livecd-rootfs to bionic and xenial?
<tjaalton> rbalint: looking
<tjaalton> rbalint: how come cosmic/disco aren't reviewed yet?
<rbalint> tjaalton, i added a note to the bug
<rbalint> tjaalton, it is under discussion, cosmic may be skipped totally
<tjaalton> ok
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.24]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.46]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-21.22~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-21.22~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5 => 240-6ubuntu5.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1019.19] (kernel)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.9-0ubuntu2 => 2:17.0.9-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-21.22~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-21.22~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cryfs [source] (bionic-proposed) [0.9.10-1~ubuntu0.18.04.1]
<Eickmeyer> vorlon: Awesome! Thanks. And, yes, typos will be typos. :)
<Eickmeyer> vorlon: If you're up for it, I have another one that should be relatively painless. bug 1829562, lintian --pedantic run against binaries and .dsc, returned no errors.  A bit of a long copyright file, but I was very careful with this one.
<ubot5`> bug 1829562 in DPF Plugins "[Needs Packaging] DPF-Plugins for Eoan" [Undecided,New] https://launchpad.net/bugs/1829562
 * Eickmeyer is trying to build his package numbers
<Eickmeyer> Really, any MOTU or AA can feel free to check that one out. ^
<vorlon> Eickmeyer: I'm traveling now post work sprint, I'm unlikely to get to it in the near future
<Eickmeyer> vorlon: No worries. I'll spam all of the usual channels. :)
-queuebot:#ubuntu-release- New binary: simdjson [amd64] (eoan-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1019.19~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.13 => 239-7ubuntu10.14] (core)
-queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (bionic-proposed) [4.3.8.12175.20140902+dfsg-0ubuntu8.1]
#ubuntu-release 2019-05-18
<vorlon> Laney: well, the systemd/arm64 test logs are showing something unexpected, I guess the way we're ensuring up-to-date base systems in the face of not having eoan base images means the systemd journal of the testbed is growing without bounds
#ubuntu-release 2019-05-19
-queuebot:#ubuntu-release- Unapproved: deepin-qt5dxcb-plugin (disco-proposed/universe) [1.1.22-1ubuntu1 => 1.1.22-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (disco-proposed/universe) [1.7 => 1.7.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: kraken2 [s390x] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [ppc64el] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [s390x] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [s390x] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-envpprof [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-pointer [amd64] (eoan-proposed/universe) [0.0~git20180825.49522c3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kraken2 [i386] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [i386] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: modernize [amd64] (eoan-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [amd64] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [armhf] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: q2cli [amd64] (eoan-proposed/universe) [2019.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [s390x] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bradfitz-iter [amd64] (eoan-proposed/universe) [0.0~git20190303.33e6a98-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [amd64] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netctl [amd64] (eoan-proposed/universe) [1.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [i386] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-textobj-user [amd64] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kraken2 [amd64] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmars [arm64] (eoan-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [ppc64el] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [ppc64el] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kraken2 [arm64] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [arm64] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kraken2 [armhf] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [i386] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: laszip [armhf] (eoan-proposed/universe) [3.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kraken2 [ppc64el] (eoan-proposed/universe) [2.0.7~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [arm64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: termshark [armhf] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kraken2 [armhf] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted laszip [arm64] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted termshark [armhf] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted kraken2 [ppc64el] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted termshark [i386] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted termshark [arm64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted kraken2 [amd64] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted laszip [amd64] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted laszip [i386] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted pmars [armhf] (eoan-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted termshark [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted termshark [s390x] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted kraken2 [arm64] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted pmars [arm64] (eoan-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted termshark [ppc64el] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted laszip [armhf] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted q2cli [amd64] (eoan-proposed) [2019.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-envpprof [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-pointer [amd64] (eoan-proposed) [0.0~git20180825.49522c3-1]
-queuebot:#ubuntu-release- New: accepted laszip [ppc64el] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted netctl [amd64] (eoan-proposed) [1.20-1]
-queuebot:#ubuntu-release- New: accepted pmars [i386] (eoan-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-bradfitz-iter [amd64] (eoan-proposed) [0.0~git20190303.33e6a98-1]
-queuebot:#ubuntu-release- New: accepted modernize [amd64] (eoan-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted vim-textobj-user [amd64] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted kraken2 [i386] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted pmars [amd64] (eoan-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted kraken2 [s390x] (eoan-proposed) [2.0.7~beta-1]
-queuebot:#ubuntu-release- New: accepted pmars [ppc64el] (eoan-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted simdjson [amd64] (eoan-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted laszip [s390x] (eoan-proposed) [3.4.1-1]
-queuebot:#ubuntu-release- New: accepted pmars [s390x] (eoan-proposed) [0.9.2-1]
#ubuntu-release 2020-05-11
-queuebot:#ubuntu-release- New binary: haskell-stm-delay [ppc64el] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-discover [ppc64el] (groovy-proposed/universe) [4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-discover [riscv64] (groovy-proposed/universe) [4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: murano-tempest-plugin [amd64] (groovy-proposed/none) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: telemetry-tempest-plugin [amd64] (groovy-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: watcher-tempest-plugin [amd64] (groovy-proposed/none) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted telemetry-tempest-plugin [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted watcher-tempest-plugin [amd64] (groovy-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [ppc64el] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [arm64] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [ppc64el] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted murano-tempest-plugin [amd64] (groovy-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [riscv64] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [riscv64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [riscv64] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [armhf] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [ppc64el] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [amd64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [armhf] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [amd64] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [amd64] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [armhf] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [arm64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-discover [s390x] (groovy-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [s390x] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-stm-delay [s390x] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-categories [arm64] (groovy-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.2-0ubuntu1 => 2:15.0.2-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: haskell-fold-debounce [amd64] (groovy-proposed/universe) [0.2.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-fold-debounce [ppc64el] (groovy-proposed/universe) [0.2.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-fold-debounce [arm64] (groovy-proposed/universe) [0.2.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-fold-debounce [s390x] (groovy-proposed/universe) [0.2.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-fold-debounce [armhf] (groovy-proposed/universe) [0.2.0.9-1] (no packageset)
<jamespage> sil2100: if youre about any chance you could peek at the neutron upload in the eoan UNAPPROVED queue - its fairly urgent due to a regression in some previous upstream point releases
<sil2100> jamespage: ok, let me take a quick look now
<jamespage> sil2100: thankyou much appreciated
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (eoan-proposed) [2:15.0.2-0ubuntu1.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418-server (groovy-proposed/primary) [418.126.02-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-fold-debounce [armhf] (groovy-proposed) [0.2.0.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-fold-debounce [amd64] (groovy-proposed) [0.2.0.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-fold-debounce [ppc64el] (groovy-proposed) [0.2.0.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-fold-debounce [arm64] (groovy-proposed) [0.2.0.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-fold-debounce [s390x] (groovy-proposed) [0.2.0.9-1]
-queuebot:#ubuntu-release- New binary: haskell-taskell [amd64] (groovy-proposed/universe) [1.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-taskell [ppc64el] (groovy-proposed/universe) [1.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-taskell [arm64] (groovy-proposed/universe) [1.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-taskell [armhf] (groovy-proposed/universe) [1.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tilda (focal-proposed/universe) [1.5.0-1.1 => 1.5.2-0ubuntu1] (ubuntu-mate)
<tjaalton> sil2100: hi, are you handling 18.04.5?
<tjaalton> "release managing" I mean
-queuebot:#ubuntu-release- Unapproved: libdrm (bionic-proposed/main) [2.4.99-1ubuntu1~18.04.2 => 2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu3 => 245.4-4ubuntu3.1] (core, i386-whitelist)
<RikMills> Laney: in curiosity, did you get a response on the ppc64el testing yet? I can't decide if it is moving faster of not
<xnox> it's a bit early, no? 18.04.5 is in august.
 * xnox thought we'd first want to get 20.04.1 out
<tjaalton> the hwe stack is needed in proposed much sooner
-queuebot:#ubuntu-release- Unapproved: python-apt (eoan-proposed/main) [1.9.0ubuntu1.3 => 1.9.0ubuntu1.4] (core)
<RikMills> sil2100: FYI I am preparing a KDE Plasma stack SRU for focal which should be uploaded this week. you will be please to know that as translations updates are minor, I'm only doing bugfix packages which is 11 out of the 45!
-queuebot:#ubuntu-release- Unapproved: live-build (focal-proposed/main) [3.0~a57-1ubuntu38 => 3.0~a57-1ubuntu38.1] (desktop-core)
<RikMills> sil2100: would you prefer I direct upload that or use bileto? I would prefer bileto, but if that makes even 11 sources hard to review I don't mind direct
<Laney> RikMills: being worked
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.5ubuntu0.2 => 1.6.5ubuntu0.3] (core)
* Laney changed the topic of #ubuntu-release to: ppc64el tests not being processed currently, under investigation | Released: Focal 20.04, Bionic 18.04.4 | Archive: Open | Highlight ubuntu-archive for archive admin help | Groovy Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<juliank> Looking at that python-apt proposed upload, it seems as if launchpad wrongly excludes security updates (that is, stuff synced to -updates) when calculating proposed diff
<juliank> Which I guess sort of makes sense since they never hit proposed
<juliank> but I suppose it's a bit inconvenient
<juliank> <insert question mark here
<sil2100> RikMills: bileto is fine - reviewing bileto SRUs is actually quite pleasant
<RikMills> Laney + sil2100 thanks :)
-queuebot:#ubuntu-release- Unapproved: python-apt (xenial-proposed/main) [1.1.0~beta1ubuntu0.16.04.8 => 1.1.0~beta1ubuntu0.16.04.9] (core)
-queuebot:#ubuntu-release- New: accepted haskell-taskell [amd64] (groovy-proposed) [1.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-taskell [armhf] (groovy-proposed) [1.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-taskell [arm64] (groovy-proposed) [1.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-taskell [ppc64el] (groovy-proposed) [1.4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.9-1ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (focal-proposed/main) [1.450 => 1.450.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-barbicanclient [source] (bionic-proposed) [4.6.0-0ubuntu1.1]
<xnox> vorlon:  sil2100: can you please respin 20/edge images please? hopefully it will fix arm64 pi4 boot issue?
<vorlon> xnox: running
<xnox> tah
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (xenial-proposed) [1.1.14-2ubuntu1.8]
<vorlon> xnox: build finished
<xnox> tah
-queuebot:#ubuntu-release- New binary: ffcx [amd64] (groovy-proposed/universe) [2019.2.0~git20200416.db6793b-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gpsd [s390x] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: gpsd [ppc64el] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: libx86emu [amd64] (groovy-proposed/universe) [3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpsd [amd64] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [s390x] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [s390x] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [amd64] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [amd64] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: lingot [s390x] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guava-libraries [amd64] (groovy-proposed/universe) [29.0-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: opensubdiv [amd64] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lingot [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensubdiv [s390x] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-alarm [amd64] (groovy-proposed/universe) [2.2.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-browser [amd64] (groovy-proposed/universe) [2.0.16-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-compress [amd64] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-crypt-blowfish [amd64] (groovy-proposed/universe) [1.1.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-auth [amd64] (groovy-proposed/universe) [2.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-constraint [amd64] (groovy-proposed/universe) [2.0.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-compress-fast [amd64] (groovy-proposed/universe) [1.1.1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-cssminify [amd64] (groovy-proposed/universe) [1.0.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [amd64] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-autoloader [amd64] (groovy-proposed/universe) [2.1.2-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-cli [amd64] (groovy-proposed/universe) [2.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-data [amd64] (groovy-proposed/universe) [2.1.4-7] (no packageset)
-queuebot:#ubuntu-release- New binary: xfonts-terminus [amd64] (groovy-proposed/universe) [4.48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: instead [amd64] (groovy-proposed/universe) [3.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-controller [amd64] (groovy-proposed/universe) [2.0.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-cache [amd64] (groovy-proposed/universe) [2.5.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxnat [amd64] (groovy-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [s390x] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libx86emu [armhf] (groovy-proposed/universe) [3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpsd [arm64] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: lingot [arm64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpsd [armhf] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: lingot [armhf] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (focal-proposed/universe) [0.16 => 0.16ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [arm64] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [arm64] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [armhf] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [armhf] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: lingot [ppc64el] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [ppc64el] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [ppc64el] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: opensubdiv [ppc64el] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios-plugins-contrib [riscv64] (groovy-proposed/universe) [26.20200508] (no packageset)
-queuebot:#ubuntu-release- New binary: opensubdiv [arm64] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [riscv64] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensubdiv [armhf] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nordugrid-arc [s390x] (groovy-proposed/universe) [6.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [arm64] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [ppc64el] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cryptominisat [armhf] (groovy-proposed/universe) [5.7.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opensubdiv [riscv64] (groovy-proposed/universe) [3.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lingot [riscv64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nordugrid-arc [amd64] (groovy-proposed/universe) [6.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrpt [s390x] (groovy-proposed/universe) [1:2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsolv [riscv64] (groovy-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nordugrid-arc [ppc64el] (groovy-proposed/universe) [6.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrpt [ppc64el] (groovy-proposed/universe) [1:2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpsd [riscv64] (groovy-proposed/main) [3.20-10] (kubuntu)
-queuebot:#ubuntu-release- New binary: mrpt [amd64] (groovy-proposed/universe) [1:2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nordugrid-arc [arm64] (groovy-proposed/universe) [6.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nordugrid-arc [armhf] (groovy-proposed/universe) [6.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrpt [arm64] (groovy-proposed/universe) [1:2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrpt [armhf] (groovy-proposed/universe) [1:2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [amd64] (groovy-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [s390x] (groovy-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ffcx [amd64] (groovy-proposed) [2019.2.0~git20200416.db6793b-2]
-queuebot:#ubuntu-release- New: accepted instead [amd64] (groovy-proposed) [3.3.2-1]
-queuebot:#ubuntu-release- New: accepted guava-libraries [amd64] (groovy-proposed) [29.0-2]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [amd64] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [armhf] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [riscv64] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted php-horde-alarm [amd64] (groovy-proposed) [2.2.10-5]
-queuebot:#ubuntu-release- New: accepted php-horde-autoloader [amd64] (groovy-proposed) [2.1.2-7]
-queuebot:#ubuntu-release- New: accepted php-horde-cache [amd64] (groovy-proposed) [2.5.5-5]
-queuebot:#ubuntu-release- New: accepted php-horde-compress-fast [amd64] (groovy-proposed) [1.1.1-7]
-queuebot:#ubuntu-release- New: accepted php-horde-constraint [amd64] (groovy-proposed) [2.0.3-7]
-queuebot:#ubuntu-release- New: accepted php-horde-crypt-blowfish [amd64] (groovy-proposed) [1.1.2-5]
-queuebot:#ubuntu-release- New: accepted php-horde-data [amd64] (groovy-proposed) [2.1.4-7]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [arm64] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [s390x] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted php-horde-browser [amd64] (groovy-proposed) [2.0.16-2]
-queuebot:#ubuntu-release- New: accepted php-horde-compress [amd64] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted php-horde-cssminify [amd64] (groovy-proposed) [1.0.4-5]
-queuebot:#ubuntu-release- New: accepted nagios-plugins-contrib [ppc64el] (groovy-proposed) [26.20200508]
-queuebot:#ubuntu-release- New: accepted php-horde-cli [amd64] (groovy-proposed) [2.3.0-4]
-queuebot:#ubuntu-release- New: accepted pyxnat [amd64] (groovy-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted php-horde-auth [amd64] (groovy-proposed) [2.2.2-5]
-queuebot:#ubuntu-release- New: accepted php-horde-controller [amd64] (groovy-proposed) [2.0.5-3]
-queuebot:#ubuntu-release- New: accepted xfonts-terminus [amd64] (groovy-proposed) [4.48-1]
-queuebot:#ubuntu-release- New binary: volk [arm64] (groovy-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [armhf] (groovy-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [ppc64el] (groovy-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1012.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1011.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1011.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1012.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1011.11]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1011.11]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [amd64] (groovy-proposed) [7ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross [amd64] (groovy-proposed) [8ubuntu1]
-queuebot:#ubuntu-release- New: accepted opensubdiv [amd64] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted opensubdiv [armhf] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted opensubdiv [riscv64] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted opensubdiv [arm64] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted opensubdiv [s390x] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted opensubdiv [ppc64el] (groovy-proposed) [3.4.3-2]
-queuebot:#ubuntu-release- New: accepted gpsd [amd64] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted gpsd [armhf] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted gpsd [riscv64] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted gpsd [arm64] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted gpsd [s390x] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted gpsd [ppc64el] (groovy-proposed) [3.20-10]
-queuebot:#ubuntu-release- New: accepted libsolv [amd64] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted libsolv [armhf] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted libsolv [riscv64] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted libsolv [arm64] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted libsolv [s390x] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted libsolv [ppc64el] (groovy-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [amd64] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [armhf] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [riscv64] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [arm64] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [s390x] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted cryptominisat [ppc64el] (groovy-proposed) [5.7.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted lingot [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted lingot [armhf] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted lingot [riscv64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted lingot [arm64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted lingot [s390x] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted lingot [ppc64el] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libx86emu [amd64] (groovy-proposed) [3.1-1]
-queuebot:#ubuntu-release- New: accepted libx86emu [armhf] (groovy-proposed) [3.1-1]
-queuebot:#ubuntu-release- New binary: playonlinux [amd64] (groovy-proposed/multiverse) [4.3.4-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2019c-3ubuntu1 => 2020a-0ubuntu0.20.04] (core)
-queuebot:#ubuntu-release- Unapproved: rejected tzdata [source] (focal-proposed) [2020a-0ubuntu0.20.04]
-queuebot:#ubuntu-release- Unapproved: tzdata (eoan-proposed/main) [2019c-3 => 2020a-0ubuntu0.19.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected tzdata [source] (eoan-proposed) [2020a-0ubuntu0.19.10]
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2019c-0ubuntu0.18.04 => 2020a-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: rejected tzdata [source] (bionic-proposed) [2020a-0ubuntu0.18.04]
#ubuntu-release 2020-05-12
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2019c-0ubuntu0.16.04 => 2020a-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1022.23] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1020.22] (core, kernel)
<Eickmeyer> Can I get some SRU love for bug 1867705?
<ubot5> bug 1867705 in ubuntustudio-controls (Ubuntu Focal) "[SRU] ubuntustudio-controls crashed with TypeError in __init__(): Argument 1 does not allow None as a value" [Critical,In progress] https://launchpad.net/bugs/1867705
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1022.23]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1020.22]
-queuebot:#ubuntu-release- New binary: hdf5 [s390x] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hdf5 [amd64] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hdf5 [ppc64el] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hdf5 [arm64] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: hdf5 [armhf] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.99-0ubuntu3~18.04.1 => 0.99-0ubuntu3~18.04.2] (core)
<RikMills> Laney: morning. does it look likely ppc64el will be fixed today? not crucial, but will be good when some things migrate to fix a crash in Kubuntu and studio systemsettings
<Laney> I think it's partially back
<Laney> Just checking now
<wgrant> bos01 is fixed
<wgrant> bos02 we're investigating.
<RikMills> thanks! :)
<ackk> hi, do I need to take any action for this to progress https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1877973 or will it just picked up at some point?
<ubot5> Ubuntu bug 1877973 in maas (Ubuntu) "RM request - removal from archive" [Undecided,Triaged]
-queuebot:#ubuntu-release- New: accepted mrpt [amd64] (groovy-proposed) [1:2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mrpt [armhf] (groovy-proposed) [1:2.0.2-1]
-queuebot:#ubuntu-release- New: accepted mrpt [s390x] (groovy-proposed) [1:2.0.2-1]
-queuebot:#ubuntu-release- New: accepted nordugrid-arc [arm64] (groovy-proposed) [6.6.0-1]
-queuebot:#ubuntu-release- New: accepted nordugrid-arc [ppc64el] (groovy-proposed) [6.6.0-1]
-queuebot:#ubuntu-release- New: accepted playonlinux [amd64] (groovy-proposed) [4.3.4-2]
-queuebot:#ubuntu-release- New: accepted mrpt [arm64] (groovy-proposed) [1:2.0.2-1]
-queuebot:#ubuntu-release- New: accepted nordugrid-arc [amd64] (groovy-proposed) [6.6.0-1]
-queuebot:#ubuntu-release- New: accepted nordugrid-arc [s390x] (groovy-proposed) [6.6.0-1]
-queuebot:#ubuntu-release- New: accepted mrpt [ppc64el] (groovy-proposed) [1:2.0.2-1]
-queuebot:#ubuntu-release- New: accepted nordugrid-arc [armhf] (groovy-proposed) [6.6.0-1]
<doko> whoever accepted norduggrid-arc, the riscv64 build failed, just given back. and mrpt riscv64 didn't finish to build
<cjwatson> doko: Yes, I'm not going to wait for failed builds when accepting from new
<doko> even not checking to retry when the build doesn't have a build log?
<cjwatson> And mrpt did finish the build and failed
<cjwatson> I checked
<cjwatson> Oh stop it
<cjwatson> This is not necessary
<doko> well, if you think so
<cjwatson> Fed up of being harassewd
-queuebot:#ubuntu-release- New binary: metacity [s390x] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: metacity [amd64] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: metacity [ppc64el] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: metacity [arm64] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: metacity [armhf] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
<cpaelzer> vorlon: since yu added the current Ubuntu delta here as FYI https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960401 to get dnsmasq in sync again
<ubot5> Debian bug 960401 in dnsmasq "runit not supported on Ubuntu" [Normal,Open]
-queuebot:#ubuntu-release- New binary: metacity [riscv64] (groovy-proposed/universe) [1:3.37.1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted metacity [amd64] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New: accepted metacity [armhf] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New: accepted metacity [riscv64] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New: accepted metacity [arm64] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New: accepted metacity [s390x] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New: accepted metacity [ppc64el] (groovy-proposed) [1:3.37.1-1]
-queuebot:#ubuntu-release- New binary: git-big-picture [amd64] (groovy-proposed/universe) [0.10.1-1] (no packageset)
<Laney> ok, ppc64el should be back to normal
* Laney changed the topic of #ubuntu-release to: Released: Focal 20.04, Bionic 18.04.4 | Archive: Open | Highlight ubuntu-archive for archive admin help | Groovy Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<Laney> tsimonq2: regarding sqlite3, it would be a good idea to do some profiling of the page to see if that's the case and which queries are hot, if so
-queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (eoan-proposed/universe) [0.15 => 0.15ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (bionic-proposed/universe) [0.14ubuntu0.18.04.1 => 0.14ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (focal-proposed/universe) [0.16 => 0.16ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: hdf5 [riscv64] (groovy-proposed/universe) [1.10.6+repack-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1022.23~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1020.22~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1020.22~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1018.20] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1022.23~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1020.22~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1020.22~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1018.20]
-queuebot:#ubuntu-release- Unapproved: net-snmp (bionic-proposed/main) [5.7.3+dfsg-1.8ubuntu3.3 => 5.7.3+dfsg-1.8ubuntu3.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: yaru-theme (focal-proposed/main) [20.04.6 => 20.04.7] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: adwaita-icon-theme (focal-proposed/main) [3.36.0-1ubuntu1 => 3.36.1-2ubuntu0.20.04.1] (core, i386-whitelist)
<rbasak> RAOF, bdmurray: FYI, I'm looking at the python-certbot-nginx SRU for Focal
<Eickmeyer> Can I get some SRU love for bug 1867705?
<ubot5> bug 1867705 in ubuntustudio-controls (Ubuntu Focal) "[SRU] ubuntustudio-controls crashed with TypeError in __init__(): Argument 1 does not allow None as a value" [Critical,In progress] https://launchpad.net/bugs/1867705
-queuebot:#ubuntu-release- New: accepted git-big-picture [amd64] (groovy-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted hdf5 [arm64] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [ppc64el] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [s390x] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [amd64] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [riscv64] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- New: accepted hdf5 [armhf] (groovy-proposed) [1.10.6+repack-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot-nginx [source] (focal-proposed) [0.40.0-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (eoan-proposed/universe) [0.15 => 0.15ubuntu0.19.10.1] (no packageset)
<teward> AA / SRU / Release Team: Can we release nginx 1.18.0-0ubuntu1 from Proposed in Focal to Updates, and then copy that up to Groovy?  (nginx 1.18.0-0ubuntu2 is slated to land in Groovy "soon" once I get testers for the version uploaded to a PPA for testing)
<teward> (not sure if we can even do that...)
<Eickmeyer> SRU Team: apw bdmurray RAOF rbasak vorlon stgraber tjaalton sil2100: The Ubuntu Studio team would really like SRU bug 1867705 to get looked at so we can move on. Upload is in the queue, has been tested, it's good to go but just needs an ack. Please?
<ubot5> bug 1867705 in ubuntustudio-controls (Ubuntu Focal) "[SRU] ubuntustudio-controls crashed with TypeError in __init__(): Argument 1 does not allow None as a value" [Critical,In progress] https://launchpad.net/bugs/1867705
<RikMills> vorlon et al : can we add md4c to the i386 whitelist please? it is now required build dep for qtbase being prepared in bileto
-queuebot:#ubuntu-release- New source: adobe-flashplugin (groovy-proposed/partner) [1:20200512.1-0ubuntu1]
<bdmurray> Eickmeyer: Pinging the on-duty SRU team member is the preferred way to escalate things unless its really critical.
<rbasak> I just took a glance at this
<rbasak> "In order to fix this, some elements of a future UI for wacom tablet config had to be removed" -> usually dropping functionality isn't OK, unless it's definitely never worked in a given release.
<Eickmeyer> rbasak: It never worked, and was just code with no access to the interface.
<rbasak> Eickmeyer: does this package work at all in Focal? Will any user be impacted?
<rbasak> Eickmeyer: OK - please could you confirm that in the bug?
<Eickmeyer> rbasak: This package works as expected in Focal.
<Eickmeyer> rbasak: Changed it: "In order to fix this, some non-functioning and inaccessible elements of a future UI for wacom tablet config had to be removed."
<rbasak> Thanks
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (focal-proposed) [2020a-0ubuntu0.20.04]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-controls [source] (focal-proposed) [1.12.6~20.04.1]
<rbasak> Eickmeyer: ^
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2020a-0ubuntu0.18.04]
<Eickmeyer> rbasak: Thanks. :)
-queuebot:#ubuntu-release- New: accepted adobe-flashplugin [source] (groovy-proposed) [1:20200512.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (eoan-proposed) [2020a-0ubuntu0.19.10]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2020a-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20200414.1-0ubuntu2 => 1:20200512.1-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200414.1-0ubuntu0.19.10.1 => 1:20200512.1-0ubuntu0.19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200414.1-0ubuntu0.18.04.1 => 1:20200512.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200414.1-0ubuntu0.16.04.1 => 1:20200512.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200512.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20200512.1-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20200512.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- New binary: adobe-flashplugin [amd64] (groovy-proposed/none) [1:20200512.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1018.20~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: h5py [s390x] (groovy-proposed/universe) [2.10.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-101.102] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-101.102] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1083.93~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: h5py [ppc64el] (groovy-proposed/universe) [2.10.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: h5py [amd64] (groovy-proposed/universe) [2.10.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-idna [amd64] (groovy-proposed/universe) [1.1.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [s390x] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-javascriptminify [amd64] (groovy-proposed/universe) [1.1.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-logintasks [amd64] (groovy-proposed/universe) [2.0.7-6] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [ppc64el] (groovy-proposed/universe) [1.4.0-2] (no packageset)
<bdmurray> seb128: Is bug 1873077 fixed in groovy?
<ubot5> bug 1873077 in gnome-clocks (Ubuntu) "gnome-clocks crashed with SIGSEGV in g_date_time_to_timezone()" [High,Fix committed] https://launchpad.net/bugs/1873077
-queuebot:#ubuntu-release- New binary: php-horde-lock [amd64] (groovy-proposed/universe) [2.1.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-log [amd64] (groovy-proposed/universe) [2.3.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-css-parser [amd64] (groovy-proposed/universe) [1.0.11-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-icalendar [amd64] (groovy-proposed/universe) [2.1.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-perms [amd64] (groovy-proposed/universe) [2.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-history [amd64] (groovy-proposed/universe) [2.3.6-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mail [amd64] (groovy-proposed/universe) [2.6.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-date [amd64] (groovy-proposed/universe) [2.4.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-nls [amd64] (groovy-proposed/universe) [2.2.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-injector [amd64] (groovy-proposed/universe) [2.0.5-8] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-prefs [amd64] (groovy-proposed/universe) [2.9.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: celery [amd64] (groovy-proposed/universe) [4.4.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-role [amd64] (groovy-proposed/universe) [1.0.1-16] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-share [amd64] (groovy-proposed/universe) [2.2.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-stream [amd64] (groovy-proposed/universe) [1.6.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-group [amd64] (groovy-proposed/universe) [2.1.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-stream-wrapper [amd64] (groovy-proposed/universe) [2.1.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-serialize [amd64] (groovy-proposed/universe) [2.0.5-7] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [amd64] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-exception [amd64] (groovy-proposed/universe) [2.0.8-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-sessionhandler [amd64] (groovy-proposed/universe) [2.2.9-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-text-filter [amd64] (groovy-proposed/universe) [2.3.6-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-token [amd64] (groovy-proposed/universe) [2.0.9-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-notification [amd64] (groovy-proposed/universe) [2.0.4-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-text-flowed [amd64] (groovy-proposed/universe) [2.0.3-8] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-support [amd64] (groovy-proposed/universe) [2.2.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-db [amd64] (groovy-proposed/universe) [2.4.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-url [amd64] (groovy-proposed/universe) [2.2.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-view [amd64] (groovy-proposed/universe) [2.0.6-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-secret [amd64] (groovy-proposed/universe) [2.0.6-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-util [amd64] (groovy-proposed/universe) [2.5.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-stream-filter [amd64] (groovy-proposed/universe) [2.0.4-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-translation [amd64] (groovy-proposed/universe) [2.2.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: h5py [arm64] (groovy-proposed/universe) [2.10.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: h5py [armhf] (groovy-proposed/universe) [2.10.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [arm64] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [riscv64] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: schroedinger-coordgenlibs [armhf] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200512.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1018.20~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-101.102]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-101.102]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (focal-proposed/main) [1.1.1+bzr982-0ubuntu32 => 1.1.1+bzr982-0ubuntu32.1] (desktop-core)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1083.93~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (focal-proposed) [1.64.2-1ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (eoan-proposed/main) [1.1.1+bzr982-0ubuntu28.1 => 1.1.1+bzr982-0ubuntu28.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (focal-proposed) [2.0.3]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (bionic-proposed/main) [1.1.1+bzr982-0ubuntu19.2 => 1.1.1+bzr982-0ubuntu19.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (focal-proposed) [2:4.11.6+dfsg-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (focal-proposed) [2.0.4ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (eoan-proposed) [2.0.4ubuntu1.19.10.1]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (xenial-proposed/main) [1.1.1+bzr982-0ubuntu14.2 => 1.1.1+bzr982-0ubuntu14.3] (kubuntu, ubuntu-desktop)
<vorlon> RikMills: https://launchpad.net/ubuntu/+source/md4c/0.4.3-1/+build/19294405
-queuebot:#ubuntu-release- Unapproved: accepted gnucash [source] (focal-proposed) [1:3.8b-1ubuntu1]
-queuebot:#ubuntu-release- Packageset: Removed configparser from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed contextlib2 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed llvm-toolchain-9 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed pycparser from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed pypy from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed python-funcsigs from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed python-pathlib2 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed python-scandir from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libconfig-autoconf-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libfile-slurper-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added md4c to i386-whitelist in groovy
<RikMills> vorlon: thank you!
-queuebot:#ubuntu-release- New binary: h5py [riscv64] (groovy-proposed/universe) [2.10.0-7] (no packageset)
<vorlon> wgrant: we have livefs builds across multiple series and multiple architectures which have returned success but have no image, only a manifest; is something wrong on the builder side? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core/+build/215448 https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/groovy/cpc/+build/215425
<vorlon> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/cpc/+build/215433
<vorlon> sil2100, waveform: ^^
<sil2100> vorlon: interesting... logs look correct-ish, no breaking changes in livecd-rootfs, weird
<sil2100> vorlon: also, what is this weird build?
<vorlon> and not consistent across all builds for a series / flavor, or confined to a single arch
<vorlon> which weird build?
<sil2100> vorlon: yeah, since it's just armhf, a single started build
<sil2100> The last 'daily' was 12 hours ago
<sil2100> So maybe it's an armhf build triggered by xnox via the isotracker?
<vorlon> er wait
<vorlon> these are showing as from 2 days ago?  why did I *just* get email about them
<vorlon> ah there's the problem
<sil2100> vorlon: oh, so images from 2 days ago won't probably have the .img files anymore
<vorlon> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/groovy/cpc/+build/215424 was stuck building for 3 days
<vorlon> Finished 2 hours ago (took 2 days, 10 hours, 15 minutes, 31.1 seconds)
<sil2100> oh shit
<sil2100> hah
<vorlon> so the corresponding arm64 image expired out of lp before it was downloaded
-queuebot:#ubuntu-release- New: accepted adobe-flashplugin [amd64] (groovy-proposed) [1:20200512.1-0ubuntu1]
<ddstreet> bdmurray if you have time during sru shift, systemd in focal upload queue contains patch for lp #1860926
<ubot5> Launchpad bug 1860926 in systemd (Ubuntu Focal) "Ubuntu 20.04 Systemd fails to configure bridged network" [Critical,In progress] https://launchpad.net/bugs/1860926
-queuebot:#ubuntu-release- Unapproved: python-ironic-lib (focal-proposed/universe) [4.0.0-0ubuntu1 => 4.2.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (focal-proposed) [3.36.2-1ubuntu1~20.04.1]
<Kamilion> hey, where's the mini.iso? I have a VM I need to install
 * vorlon is triggered
<xnox> Kamilion:  use a preinstalled cloud-image which needs no installation step, simply import and boot in place.
<Kamilion> And that supports xen?
<xnox> Kamilion: good question. I think some of them do. But i don't know how to provide cloud-init metadata with ssh-key or password (it will boot but not give access) over at http://cloud-images.ubuntu.com/releases/focal/release/ does anythiing make sense? like the .img or the .vmdk images?
<vorlon> Kamilion: longer discussion: https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631 including link to the mini.iso if you actually need it http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
<xnox> Kamilion: so yeah, we do have the last build of mini.iso. But i want to engage with you about your usecases. Cause we want to kill it, hence we change the location of where it is, such that we can talk to you about why/how you use mini.iso =)
<vorlon> I don't know whether any of the preinstalled cloud images support xen
<vorlon> exactly
<xnox> Kamilion:  when you say xen => is it some kind of biggest software in front of it that you use?
<Kamilion> huh?
<Kamilion> xen-hypervisor-amd64, that's all we've ever shipped, as far as I know.
<xnox> Like Xen Cloud Platform
<xnox> Kamilion:  oh, you are testing us as guest only.
<Kamilion> no, just normal xl
<xnox> right
<Kamilion> not testing anything
<Kamilion> need to deploy a new game VM
<Kamilion> focal support was just added; so I have to roll a VM for them to use.
<Kamilion> normally I use mini.iso
<Kamilion> since I don't want to waste 1.6GB to download a bunch of packages and snaps I'll never touch
<xnox> Kamilion: right, but like no Openstack / CloudStack / Nebula, etc. Just xen vms. I think our stock .img cloud images should be able to boot in the pv-hvm mode i think.
<Kamilion> i don't even *want* snapd or cloudinit
<xnox> Kamilion:  right, we have the tiny minimal cloud images too => they are smaller than anything mini.iso ever produced.
<Kamilion> alright, where are those? I'll give one a shot right now.
<xnox> http://cloud-images.ubuntu.com/minimal/releases/focal/release/
<Kamilion> ah, thanks.
<Kamilion> uhhh... these are still hundreds of megabytes?
<vorlon> still needs to be driven by cloud-init for configuration
<xnox> but i fear it does have cloud-init and at least needs you to specify (via xen cloud init data source) a password or ssh key for login.
<Kamilion> I thought you said they were smaller than mini.iso? LMFAO
<vorlon> no
<vorlon> they're smaller than anything you could install /using/ mini.iso
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.2-1ubuntu1~20.04.1]
<xnox> Kamilion:  but mini.iso by the end of install dynamically pulls in hundreds of the megabytes at runtime.
<Kamilion> oh, okay, misunderstood the distinction.
<Kamilion> yeah, but i have control over that with --no-install-recommends usually
<xnox> oh yes, sorry, i talked about the _installed_ system size, at the end.
<Kamilion> yeah, i gotcha now.
<xnox> (i.e. the size used for your xen VM disk at the end)
<Kamilion> oh, fudge
<Kamilion> I already used qemu-image to generate xvda.img
<Kamilion> ... how the heck do I get the cloud image into the partition layout I need to use qemu-image to expand this ext4 volume?
<xnox> Kamilion:  it will self expand on first boot anyway.
<Kamilion> ... so I have to do some dd foolishness instead now?
<xnox> Kamilion:  and you can use qemu-img to convert it from qcow2 to raw, if that's what you need.
<xnox> Kamilion:  and you can use qemu-img to "grow it" to +10G or whatever you need.
<vorlon> right it only self-expands to the size that's exposed to it by the hypervisor for the full disk
<vorlon> it can't pick its own disk size from inside the vm
<Kamilion> right.
<Kamilion> and I'm just using raw files on btrfs subvolumes.
<Kamilion> it's worked fine since 2012
<vorlon> so you can use qemu-img to resize; or for raw files you can just use dd to extend the file (dd seek=[...] count=0)
<Kamilion> yeah, i'll have to figure out how to convert that to dc3dd's parlance
<Kamilion> why's mini.iso so difficult to build now anyway?
<Kamilion> or is it more of a 'supporting mini.iso installs' like folks like me that have prexisting expectations?
<xnox> Kamilion:  because it's a forked distribution of Ubuntu, which uses alternative builds of every single binary in a subset of main archive. Not a single thing you load in mini.iso came from .debs it came from a parallel build of distribuiton based on udebs with udpkg / anna / different build of systemd  etc.
<xnox> Kamilion:  thus we have to fix bugs twice to keep mini.iso going.
<xnox> Kamilion:  because every single thing you fix in "ubuntu" used by (desktop/server/cloud/lxd/Pi/preinstalled) is not used at all by d-i/mini.iso
<Kamilion> Okay, that makes sense, and I can see why you'd want to axe it. But is there any way to release something similar? I used to base my ISO remixes off of Ubuntu mini remix, which was pretty much just casper and ubuntu-minimal in the squashfs.
<xnox> Kamilion:  as everything in d-i/mini.iso is standalone binaries, with different configs, different compile options, busybox has different config and like grep options don't work, etc.
<Kamilion> linux-firmware is honestly pissing me off the most
<xnox> Kamilion:  one can download live-server.iso, extract initrd & kenrel, and netboot those. Which is quite small. It does download the full iso at runtime, mount and install that.
<Kamilion> when i respin ISOs I have to trim out about 200MB of firmware for 10Gbit SmartNICs I'll never see
<xnox> Kamilion:  however, we expect that people who install VMs should not need to suffer of downling installer; installing stuff; rebooting; configuring things.
<Kamilion> it grabs the ISO?? not the squashfs?
<xnox> Kamilion:  because we provide prebuilt ubuntu-server images for that.
<Kamilion> yeah, I was working on similar HTTP booting support in the past.
<xnox> Kamilion:  yes, cause you can't verify things otherwise. And we do need /pool/ from the iso and the metadata off it as well. Otherwise, network airgapped installs wouldn't work.
<xnox> Kamilion:  the live-server.iso cna be netbooted / without access to ubuntu.com (no public internet) and complete the install.
<Kamilion> https://github.com/kamilion/kamikazi-core/tree/master/resources/xenial/mods/usr/share/initramfs-tools/scripts/casper-premount
<xnox> live-server.iso is self-consistent.
<Kamilion> guess I'll have to take a look at what you guys have decided to go with.
<Kamilion> yea, I need the airgapped (from internet) support myself. Good looking out there.
<xnox> Kamilion:  we have some code to make subiquity install alternative squashfs and we did have "install MAAS rack & MAAS region" overlays before, but not anymore.
<Kamilion> yeah, i saw lubuntu also removed everything but lubuntu-desktop
<Kamilion> no more -minimal
<xnox> Kamilion:  because live-server is more or less: subiquity.snap (intaller) + cloud-image squashfs (used as live environment & that's what is installed into target) + a few more optional .debs in the /pool (which can be accessed over the network, ie. grub-pc for bios; grub-efi for efi; weird fs tools, etc)
<Kamilion> oh! so that's why I broke the liveserver iso by removing snapd, lmfao
<xnox> Kamilion:  but ideally one shouldn't need any of htat crap, if one is "installing" the VM, just boot the cloud-image squashfs in place (the cloud image)
<Kamilion> i was wondering how i managed to screw that one up
<Kamilion> guess i should stick an extra check in https://github.com/kamilion/customizer for live-server
<xnox> Kamilion:  installer.squashfs is the the ovelay, which seeds subiquity => it's the same subiqutiy snap isntalling _any_ ubuntu release. The same snap is used on Bionic, Focal, Eoan, Groovy, and it can even live-self updated. Cause we fix bugs and release the new installer snap
<xnox> and magically people can install stuff, without redownloading the whole iso.
<Eickmeyer> vorlon, wgrant: Looks like the Focal dailies for Studio have been completely broken. Looks like it's trying to install two versions of the same kernel?
<xnox> (most fixes are one liners)
<Kamilion> yeah, I have tried to avoid propritary stuff like snaps and flatpaks though
<Kamilion> I just want normal .deb packages, thank you
<xnox> Kamilion:  i am a sceptic. But when i managed to fix one character typo, and a user was able to "refresh& continue install" and unbreak installation of their whole data center it felt nice.
<Kamilion> https://www.plasticscm.com/plastic-for-linux  I still don't see anyone shipping snaps, to be honest.
<Kamilion> yeah, I'm not complaining that it exists; it's great for others
<xnox> Kamilion:  because normally, a full new iso is very heavyweight process for just a typpo fix. Because of all of the qa one has to do, for physical media.
<Kamilion> yeah, don't I know it.
<Kamilion> I have to have a 40 core dual E5 to reroll the squashfs every time I invoke customizer to generate a fresh kamikazi ISO.
<xnox> Kamilion:  so why have customizer, if you can boot in place any cloud image, and have cloud-config dynamically customize things on first boot?
<Kamilion> (which is lubuntu, minus the office apps, plus xen and tools)
<xnox> because it really than blooms from a smalish thing to anything you want.
<Kamilion> because all my HOSTs run from the livecd image, not an ondisk installation.
<xnox> ephemerally?
<Kamilion> https://github.com/kamilion/kamikazi-core/blob/master/resources/xenial/mods/usr/share/initramfs-tools/scripts/casper-bottom/18kamikazi_restore
<Kamilion> yes.
<xnox> like thin clients?
<xnox> "sort of"
<xnox> kind of full-fat, but i guess not persistent.
<Kamilion> they have a USB stick with the ISO on it. Grub loopback mounts it for the kernel and initrd, and then casper discovers it from iso-scan.
<Kamilion> yeah, only certain services are persistantly configured at boot from a casper script.
<Kamilion> everything else is TORAM and thrown away on each reboot.
<Kamilion> sometimes we'll grab the journals before a reboot. mostly not.
<xnox> Kamilion:  cause we publish maas images => which really are sets of "grub+kernel+initrd" which have cloud-initramfs-tools installed, and those things can do stuff like rooturl= which will download that squashfs, and setup overlayfs on top of it, to boot ephemeral envrionment.
<Kamilion> is it documented anywhere yet? *grins*
<xnox> and it does neat stuff liek "all kernel moduels are in the initrd, and are copied into the squashfs rootfs"
<Kamilion> i mean, more, the overlays you speak of
<xnox> Kamilion:  meaning the squashfs can be _without_ kernel; and yet, one has all the moduels, and everything works / latest kernel is booted
<Kamilion> i tried multisquash mounts from ISO but it was generally more trouble than it was worth
<Kamilion> ah yeah, in my spins, /boot in squash is emptied before squashing
<xnox> Kamilion:  lately kernels have multilowerdir support for overlayfs that's how the ubuntu-server iso boots the filesystem.squashfs (as bottom layer), installer.squashfs (as middle layer), and tmpfs as top layer.
<Kamilion> my workflow is generally spin a new ISO when an important kernel update arrives, rsync the iso to all the VM hosts, and schedule a reboot.
<xnox> Kamilion:  and then in-target we install the bottom layer
<Kamilion> do keep in mind, I am mostly hosting gameservers and the like, that have no enterprise requirements
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.2-1ubuntu1~20.04.1]
<xnox> Kamilion:  the maas workflow is to sync simplestream images (which are those kernel+initrd pairs), and netboot those to give ephemeral environment (default ubuntu-server, but can be centos/rhel/etc, and it can be bare-metal/VM/contanier)
<xnox> Kamilion:  all of this stuff is free and opensource and well documented.
<Kamilion> the individual components may be documented, but an integration document?
<Kamilion> and the ubuntu stackoverflow doesn't count :P
<Kamilion> well, thanks for the heads up, I just dumped it into a .log on my desktop and I'll go back over it a couple times this evening
<xnox> Kamilion: so like Canonical Distribution of Openstack i thought even has the image syncing thing => where it's a pipeline on top of our simplestreams of images, which continiously consumes new ubuntu images and applies whatever customizations one needs on top of them.
<xnox> Kamilion:  note that MAAS deploys the same squashfs to baremetal/VM/containers => because all of them are the same identical squashfs that one launches with lxc launch ubuntu:focal
<Kamilion> yeah, reminds me, i have to look at the openstack stuff again
<Kamilion> since i need their openvswitch stuff
<xnox> Kamilion:  so like, if you can customzie lxd container, you can create squashfs that is suitable for your workloads
<Kamilion> IIRC it's the openstack team maintaining that, right?
<Kamilion> absolutely unsuitable.
<xnox> talk to you later
 * xnox dinner tiem
<Kamilion> we require isolation between VMs; containers aren't enough of a boundary.
<Kamilion> hence kvm/xen.
<xnox> sure
<Kamilion> enjoy your foodings!
<Kamilion> info's much appreciated.
<xnox> but just because it's kvm/xen, doesn't mean that the "rootfs" should be much different from a lxd squashfs (with more packges added / others removed / config file here and there)
<Kamilion> yeah.
<Kamilion> as long as the kernel still has pvops support, it should 'just work'
<Kamilion> hm, that's actually not a bad idea... Didn't think about using containers for *generation*, predeployment.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (focal-proposed) [68ubuntu1~20.04.1]
<Kamilion> also, whoever promoted x2goserver into universe out of the PPA-hell, thank you ever so much.
<seb128> bdmurray, yes, it's the same fix in https://launchpad.net/ubuntu/+source/gnome-clocks/3.36.0-2
 * Kamilion returns to lurk mode once again
<seb128> bdmurray, I've updated the bug now
<tsimonq2> Laney: sqlite3> Sure, that makes sense. I wonder how we'd go about doing that though.
-queuebot:#ubuntu-release- New: accepted php-horde-db [amd64] (groovy-proposed) [2.4.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-notification [amd64] (groovy-proposed) [2.0.4-7]
-queuebot:#ubuntu-release- New: accepted php-horde-sessionhandler [amd64] (groovy-proposed) [2.2.9-5]
-queuebot:#ubuntu-release- New: accepted php-horde-stream-wrapper [amd64] (groovy-proposed) [2.1.4-4]
-queuebot:#ubuntu-release- New: accepted php-horde-text-filter [amd64] (groovy-proposed) [2.3.6-4]
-queuebot:#ubuntu-release- New: accepted php-horde-token [amd64] (groovy-proposed) [2.0.9-6]
-queuebot:#ubuntu-release- New: accepted php-horde-url [amd64] (groovy-proposed) [2.2.6-5]
-queuebot:#ubuntu-release- New: accepted php-horde-view [amd64] (groovy-proposed) [2.0.6-7]
-queuebot:#ubuntu-release- New: accepted php-horde-exception [amd64] (groovy-proposed) [2.0.8-6]
-queuebot:#ubuntu-release- New: accepted php-horde-stream-filter [amd64] (groovy-proposed) [2.0.4-7]
-queuebot:#ubuntu-release- New: accepted php-horde-text-flowed [amd64] (groovy-proposed) [2.0.3-8]
-queuebot:#ubuntu-release- New: accepted php-horde-util [amd64] (groovy-proposed) [2.5.8-5]
-queuebot:#ubuntu-release- New: accepted php-horde-secret [amd64] (groovy-proposed) [2.0.6-7]
-queuebot:#ubuntu-release- New: accepted php-horde-translation [amd64] (groovy-proposed) [2.2.2-5]
-queuebot:#ubuntu-release- New: accepted php-horde-support [amd64] (groovy-proposed) [2.2.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-css-parser [amd64] (groovy-proposed) [1.0.11-6]
-queuebot:#ubuntu-release- New: accepted php-horde-group [amd64] (groovy-proposed) [2.1.1-6]
-queuebot:#ubuntu-release- New: accepted php-horde-injector [amd64] (groovy-proposed) [2.0.5-8]
-queuebot:#ubuntu-release- New: accepted php-horde-perms [amd64] (groovy-proposed) [2.1.8-2]
-queuebot:#ubuntu-release- New: accepted php-horde-role [amd64] (groovy-proposed) [1.0.1-16]
-queuebot:#ubuntu-release- New: accepted php-horde-share [amd64] (groovy-proposed) [2.2.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-date [amd64] (groovy-proposed) [2.4.1-5]
-queuebot:#ubuntu-release- New: accepted php-horde-nls [amd64] (groovy-proposed) [2.2.1-5]
-queuebot:#ubuntu-release- New: accepted php-horde-serialize [amd64] (groovy-proposed) [2.0.5-7]
-queuebot:#ubuntu-release- New: accepted php-horde-history [amd64] (groovy-proposed) [2.3.6-7]
-queuebot:#ubuntu-release- New: accepted php-horde-stream [amd64] (groovy-proposed) [1.6.3-7]
-queuebot:#ubuntu-release- New: accepted php-horde-prefs [amd64] (groovy-proposed) [2.9.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-icalendar [amd64] (groovy-proposed) [2.1.8-3]
-queuebot:#ubuntu-release- New: accepted php-horde-javascriptminify [amd64] (groovy-proposed) [1.1.5-5]
-queuebot:#ubuntu-release- New: accepted php-horde-log [amd64] (groovy-proposed) [2.3.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-mail [amd64] (groovy-proposed) [2.6.5-3]
-queuebot:#ubuntu-release- New: accepted php-horde-idna [amd64] (groovy-proposed) [1.1.1-5]
-queuebot:#ubuntu-release- New: accepted php-horde-logintasks [amd64] (groovy-proposed) [2.0.7-6]
-queuebot:#ubuntu-release- New: accepted php-horde-lock [amd64] (groovy-proposed) [2.1.4-5]
-queuebot:#ubuntu-release- New: accepted celery [amd64] (groovy-proposed) [4.4.2-4]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [amd64] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [armhf] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [riscv64] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [arm64] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [s390x] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted schroedinger-coordgenlibs [ppc64el] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted h5py [amd64] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New: accepted h5py [armhf] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New: accepted h5py [riscv64] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-101.102~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted h5py [arm64] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New: accepted h5py [s390x] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New: accepted h5py [ppc64el] (groovy-proposed) [2.10.0-7]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-101.102~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-101.102~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-101.102~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (focal-proposed) [245.4-4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.7 [source] (focal-proposed) [2.7.0-5ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted at-spi2-atk [source] (focal-proposed) [2.34.2-0ubuntu2~20.04.1]
<vorlon> Eickmeyer: are you talking about focal or groovy dailies? groovy seems to be building fine, focal is unhappy but I thought was something xnox might have been working on fixing already
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (focal-proposed) [245.4-4ubuntu3.1]
<xnox> vorlon: hm? I am not looking into anything. What's up?
<Eickmeyer> vorlon: I mean the focal dailies, presumably for 20.04.1.
<vorlon> xnox: I thought there was a regression in focal wrt kernel selection into the livecd-rootfs build due to multiple versions being available in release vs proposed/updates and introduced by the oem work; didn't you have an SRU in flight that addressed that?
<vorlon> seems to not be part of the current SRU
<vorlon> but I thought I saw someone mutter here about that.  If it wasn't you, then perhaps Laney
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (eoan-proposed) [0.31-5-gef42f6b5-0ubuntu1.1]
<xnox> vorlon: at one point I heard kernel in proposed was busted.
<xnox> But don't know details
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (eoan-proposed) [0.44ubuntu1.1]
<xnox> vorlon: hmmmm I did "fix" kernel detection to allow accepting more kernel flavours.... Cause it only knew about 2.6 xen and omap flavours in addition to generic.
<xnox> But that was in focal GA. Before all the flavours got updated.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1071.81] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1071.81~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27 => 2.20.11-0ubuntu27.2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.1]
#ubuntu-release 2020-05-13
-queuebot:#ubuntu-release- New binary: wp2latex [s390x] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wp2latex [ppc64el] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wp2latex [amd64] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wp2latex [armhf] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wp2latex [arm64] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wp2latex [riscv64] (groovy-proposed/universe) [3.90-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1071.81]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1071.81~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gpsd (focal-proposed/main) [3.20-8 => 3.20-8ubuntu0.1] (kubuntu)
<mwhudson> why are there focal isos in http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ ?
-queuebot:#ubuntu-release- Unapproved: drkonqi (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: milou (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kwin (focal-proposed/universe) [4:5.18.4.1-0ubuntu2 => 4:5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-kde (focal-proposed/universe) [5.18.4.1-0ubuntu2 => 5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-browser-integration (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.5-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-vault (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.5-0ubuntu0.1] (kubuntu) (sync)
<RikMills> sil2100: ^^^ LP: #1876876
<ubot5> Launchpad bug 1876876 in xdg-desktop-portal-kde (Ubuntu) "SRU tracking bug for plasma 5.18.5 in Focal" [Undecided,New] https://launchpad.net/bugs/1876876
<RikMills> https://bileto.ubuntu.com/#/ticket/4059
<sil2100> RikMills: thanks! Will take care of it during my tomorrow's shift
<RikMills> sil2100: thanks
<LocutusOfBorg> good morning vorlon , please some i386 cleanup? missing build on i386: hevea, why3, python3-ijson, libberkeleydb-perl, libmsnumpress-dev-doc and other, thanks :)
<RikMills> sil2100: I want to fix a UI bug in Plasma's network config dialogue. the upstream patch was not included in the plasma bugfix as technically it makes a new runtime dep needed. the runtime dep required is also one for plasma-desktop and plasma-workspace, so in practice it will not add anything to a plasma system. in that case, would that be acceptable as a SRU?
<sil2100> RikMills: what is the overall impact of the UI bug in the network config that you are trying to fix?
 * RikMills gets screenshot
<RikMills> sil2100: https://i.postimg.cc/c0cBb1vL/pic1.png
<RikMills> buttons hardly or not visible in the black area
<RikMills> https://bugs.kde.org/show_bug.cgi?id=418416
<ubot5> KDE bug 418416 in general "Bad theming/colors network manager (connections)" [Normal,Resolved: fixed]
<sil2100> RikMills: hm, right, so this is one of these gray SRU areas - with my sru-hat that would be fine, if the only reason that this was not included in the bugfix upstream release is that they didn't want to introduce a new dependency (but otherwise they have accepted the fix).
<sil2100> Since even though this is just a visual fix, I feel this might be important for people with limited visibility as well
<RikMills> sil2100: yes. the opensuse devs confirm that it applies ok and fixes the issue
<RikMills> indeed. it is hard for me to see them, and my sight is 20-20
<RikMills> sil2100: ok. I will prepare an additional SRU sometime in the next week. thanks
<sil2100> RikMills: yeah, so +1 from me if anything
<RikMills> ty
<sil2100> I assume the new dep would be qml-module-org-kde-kirigami2 ?
<RikMills> yes
-queuebot:#ubuntu-release- New binary: apertium-ind-zlm [amd64] (groovy-proposed/universe) [0.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarcts-report-parser [amd64] (groovy-proposed/universe) [1.0+git20190809.1.bb5dd8b6-3] (no packageset)
-queuebot:#ubuntu-release- New source: libfprint-2-tod1-goodix (focal-proposed/primary) [0.0.4ubuntu1]
<tjaalton> libfprint-2-tod1-goodix probably should've been uploaded for groovy, but it can be forward-copied there from focal..
-queuebot:#ubuntu-release- New: accepted apertium-ind-zlm [amd64] (groovy-proposed) [0.1.2-2]
-queuebot:#ubuntu-release- New: accepted wp2latex [amd64] (groovy-proposed) [3.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wp2latex [armhf] (groovy-proposed) [3.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wp2latex [riscv64] (groovy-proposed) [3.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dmarcts-report-parser [amd64] (groovy-proposed) [1.0+git20190809.1.bb5dd8b6-3]
-queuebot:#ubuntu-release- New: accepted wp2latex [ppc64el] (groovy-proposed) [3.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wp2latex [arm64] (groovy-proposed) [3.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wp2latex [s390x] (groovy-proposed) [3.90-1ubuntu1]
<rbalint> sil2100, Laney could you please merge https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383862 for systemd?
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (xenial-proposed) [8.1.1-2ubuntu0.5]
-queuebot:#ubuntu-release- Unapproved: rejected dpkg [source] (xenial-proposed) [1.18.4ubuntu1.7]
<LocutusOfBorg> ubuntu-archive: r-base 4 has been uploaded in sid, starting a 1k packages transition. would it be possible to turn off autosync or blacklist r-* for now?
<LocutusOfBorg> 1017 packages and the transition will entangle with everything
<rbalint> is suggest bumping the priority of LP: #1878225 because it prevents creating lxd autpkgtest images on affected architectures
<ubot5> Launchpad bug 1878225 in snapd (Ubuntu) "snapd.seeded.service waits forever (?) to have snaps seeded in LXD on s390x and arm64 " [Undecided,New] https://launchpad.net/bugs/1878225
-queuebot:#ubuntu-release- Unapproved: rejected gpsd [source] (focal-proposed) [3.20-8ubuntu0.1]
<Laney> rbalint: ok, will merge that
<Laney> it's ok on arm64?
-queuebot:#ubuntu-release- Unapproved: gpsd (focal-proposed/main) [3.20-8 => 3.20-8ubuntu0.1] (kubuntu)
<paride> bdmurray, hey! do we have a date for the release sprint retrospective?
<paride> I saw your "moving next week" message but I don't have it on my calendar
<rbalint> Laney, yes, arm64 does not tend to time out
<Laney> interesting
-queuebot:#ubuntu-release- Unapproved: accepted gpsd [source] (focal-proposed) [3.20-8ubuntu0.1]
<ahasenack> hi release team, looks like src:fish in groovy partially migrated
<ahasenack> we have fish 3.1.2-1 in groovy-proposed for s390x
<ahasenack> that is the binary, I mean
<ahasenack> but fish-common, binary from the same src:fish, is only at 3.1.0-1.2 and is not in proposed
<ahasenack> let me correct something, it hasn't migrated, but the proposed pocket doesn't have all the binaries
<ahasenack> https://pastebin.ubuntu.com/p/Ym4Z364hYH/
<ahasenack> ubuntu-archive ^
<ahasenack> hm, https://launchpad.net/ubuntu/+source/fish/3.1.2-1/+build/19290794 doesn't show fish-common built
 * ahasenack investigates a bit more what happened in that build
<wgrant> ahasenack: Is it not just because amd64 ftbfsed?
<ahasenack> maybe, but s390x didn't, and is missing a binary deb
<ahasenack> and I just retried a build in an s390x vm, and the build failed there
<cjwatson> ahasenack: fish-common is Architecture: all, so it's only built on amd64
<wgrant> ahasenack: Why would s390x build -common?
<wgrant> That.
<ahasenack> ah
<ahasenack> and amd64 failed
<cjwatson> Architecture: all â built on the nominated arch-indep building architecture (amd64 for anything vaguely recent), published on all architectures
<wgrant> (Though a very small handful of packages override the arch-indep build architecture using a control field, e.g. because they are a firmware package that is useful for qemu but needs native build tools.)
<ahasenack> I Äºl focus on the amd64 failure, it should fix all of this
<ahasenack> not my upload, but blocking a migration of mine
<tumbleweed> LocutusOfBorg, tsimonq2: have you tried the ABI-breakage-reversion patch in https://bugs.debian.org/959201 ?
<ubot5> Debian bug 959201 in libyaml-cpp0.6 "jami-daemon: dring does not start due to a symbol lookup error" [Grave,Open]
<tumbleweed> seems that got caught up in the protobuf migration here
<tumbleweed> transition, I mean
<tumbleweed> well, I tried, and it gets one of the mongodb autopkgtests to pass, but not the other
-queuebot:#ubuntu-release- Unapproved: ironic (focal-proposed/universe) [1:14.0.1~git2020041013.af9e6ba90-0ubuntu2 => 1:15.0.0-0ubuntu0.20.04.1] (openstack)
-queuebot:#ubuntu-release- New binary: volk [riscv64] (groovy-proposed/universe) [2.3.0-2] (no packageset)
<LocutusOfBorg> can anybody please NBS-proposed cleanup prooftree on armhf riscv64 s390x?
<LocutusOfBorg> tumbleweed, uploaded
<LocutusOfBorg> will be autosyncd
<LocutusOfBorg> ubuntu-archive: r-base 4 has been uploaded in sid, starting a 1k packages transition. would it be possible to turn off autosync or blacklist r-* for now?
<tumbleweed> LocutusOfBorg: it looks like there may be more to do there (see what I said about mongodb above)
<tumbleweed> LocutusOfBorg: also, once you've sorted this out, everything built against the broken versions probably needs to be rebuilt (in debian an Ubuntu)
-queuebot:#ubuntu-release- Unapproved: aodh (focal-proposed/main) [10.0.0~b3~git2020041012.6ae7f90a-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
<LocutusOfBorg> tumbleweed, lets see when it syncs
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0~b3~git2020041012.d5a0ce18-0ubuntu1 => 2:20.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.2.1~git2020041013.754804667-0ubuntu3 => 3:18.3.2-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.0.0~b3~git2020041013.57ff308d6d-0ubuntu2 => 2:21.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat-dashboard (focal-proposed/universe) [2.1.0~git2020032615.7842190-0ubuntu1 => 3.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (focal-proposed/universe) [10.0.0~b3~git2020032617.f4cf36e-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: manila-ui (focal-proposed/universe) [1:2.19.2~git2020041511.a2dcb0e-0ubuntu1 => 1:3.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: watcher-dashboard (focal-proposed/universe) [2.0.1~git2020012214.0e1c0e0-0ubuntu1 => 3.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (focal-proposed/universe) [14.0.0~b3~git2020041315.a92ba65-0ubuntu1 => 14.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (focal-proposed/universe) [1:2.1.1~git2020041315.d49e7ef-0ubuntu1 => 1:3.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: octavia-dashboard (focal-proposed/universe) [5.0.0~b3~git2020041315.761408e-0ubuntu1 => 5.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (focal-proposed/universe) [12.0.0~b3~git2020041315.b4f7dcd-0ubuntu1 => 12.0.0-0ubuntu0.20.04.1] (no packageset)
<vorlon> LocutusOfBorg: why3 doesn't need cleanup, it just needed built on amd64 (and has already migrated).  hevea, python-ijson, libmsnumpress, cleaned up. libberkelydb-perl, needs more investigation to see why it has an i386 binary in groovy.
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (focal-proposed/universe) [1:9.0.0~b3~git2020041315.b9ed51cb-0ubuntu1 => 1:9.0.0-0ubuntu0.20.04.1] (openstack)
<LocutusOfBorg> and for the r-* blacklist?
<tumbleweed> looks like hdf5 is joining the probuf+re2 transition :)
<LocutusOfBorg> btw why3 doesn't need cleanup, but prooftree does
<vorlon> LocutusOfBorg: r blacklist set, but is there analysis about what it would entangle, so we know when to drop the blacklist?
<vorlon> LocutusOfBorg: and prooftree cleaned up
<ddstreet> rbalint Laney re: systemd ppc64el test length, it's most likely not timing out on arm64 because it can't find (or figure out how to use) qemu there, while on ppc64el it does, so lots of tests are skipped or only run under nspawn
<vorlon> wgrant: also seeing a reproducible failure of mir on riscv64, holding up the protobuf transition
<LocutusOfBorg> vorlon, I guess protobuf and re2 is what we need to land
<vorlon> ok
<tumbleweed> I think hdf5 is along for the ride now, the caffe in proposed (that FTBFS) was rebuilt for it
<LocutusOfBorg> I'll have a deeper look tomorrow
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3.8 => 242-7ubuntu3.9] (core)
<RAOF> vorlon: what's the easiest way to have access to a riscv64 box to fix the Mir build? Qemu?
<vorlon> RAOF: https://people.ubuntu.com/~wgrant/riscv64/
<vorlon> RAOF: but also, this may be a regression on the qemu builder, which is why I've pinged wgrant about it first
<RAOF> Ok
-queuebot:#ubuntu-release- New source: studio-controls (groovy-proposed/primary) [1.99.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.14 => 2.20.9-0ubuntu7.15] (core)
<Eickmeyer> ubuntu-archive: ^ studio-controls is the continuation of ubuntustudio-controls. development of the tool will continue in that package, and is identical to ubuntustudio-controls code-wise. Would love an Ack ASAP since I have a few other things to upload after it for the transition.
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu8.8 => 2.20.11-0ubuntu8.9] (core)
<tumbleweed> I don't know enough about our autpkgtest stack to know why usbauth's tests are failing: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#usbauth
<tumbleweed> they're trying to start dbus and being told that they can't
-queuebot:#ubuntu-release- New binary: php-horde-argv [amd64] (groovy-proposed/universe) [2.1.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-date-parser [amd64] (groovy-proposed/universe) [2.0.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-crypt [amd64] (groovy-proposed/universe) [2.7.12-3] (no packageset)
<tumbleweed> for some reason that used to work on some archs, but not others
-queuebot:#ubuntu-release- New binary: php-horde-editor [amd64] (groovy-proposed/universe) [2.0.5+debian0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-spellchecker [amd64] (groovy-proposed/universe) [2.1.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-image [amd64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-http [amd64] (groovy-proposed/universe) [2.1.7-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-itip [amd64] (groovy-proposed/universe) [2.1.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-queue [amd64] (groovy-proposed/universe) [1.1.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-routes [amd64] (groovy-proposed/universe) [2.0.5-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-socket-client [amd64] (groovy-proposed/universe) [2.1.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-rdo [amd64] (groovy-proposed/universe) [2.1.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-rpc [amd64] (groovy-proposed/universe) [2.1.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-listheaders [amd64] (groovy-proposed/universe) [1.2.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-text-diff [amd64] (groovy-proposed/universe) [2.2.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-tree [amd64] (groovy-proposed/universe) [2.0.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-xml-element [amd64] (groovy-proposed/universe) [2.0.4-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mime-viewer [amd64] (groovy-proposed/universe) [2.2.2+debian0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-vfs [amd64] (groovy-proposed/universe) [2.4.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-timezone [amd64] (groovy-proposed/universe) [1.1.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mail-autoconfig [amd64] (groovy-proposed/universe) [1.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-smtp [amd64] (groovy-proposed/universe) [1.9.5-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-pack [amd64] (groovy-proposed/universe) [1.0.7-5] (no packageset)
<vorlon> tumbleweed: well according to the error message, you're /never/ supposed to be able to start/stop the dbus service
<tumbleweed> it works in the Debian CI
<tumbleweed> we have the same dbus version
<tumbleweed> I know dbus doesn't ever want to be stopped/started
<tumbleweed> but I'm not sure where this policy difference is coming from
<vorlon> tumbleweed: what's the behavior if you test locally?  (in a container or vm)
<tumbleweed> stopping / starting dbus in a container is a no-go too
<tumbleweed> I mean, I can't really test in one
<tumbleweed> I could test in a VM
<tumbleweed> but what's ubuntu actually using here? LXD?
<vorlon> tumbleweed: no, we use VMs
<tumbleweed> on the topic of what is Ubuntu using: According to trash-cli autopkgtest, there is no /proc/mounts or /etc/mtab in the s390x autopkgtset environment
<Eickmeyer> ubuntu-archive: studio-controls, a NEW source, is the continuation of and is code-identical ubuntustudio-controls with the exception of filename and icon changes. Need an Ack ASAP since I have a few other things to upload after it for the transition, such as ubuntustudio-controls becoming a dummy package.
<tumbleweed> vorlon: works for me under qemu (using autopkgtest-buildvm-ubuntu-cloud)
<vorlon> curious
<tumbleweed> oops, that wasn't the -proposed version.
<tumbleweed> however, 1.0.1+git20190123.5004f7d-2 didn't previously pass on ubuntu ci
#ubuntu-release 2020-05-14
<RAOF> Eickmeyer: I know it's preexisting, but that postinst looks suspicious. Unconditionally deleting configuration files seems bad?
<Eickmeyer> RAOF: That service file is meant for non-Ubuntu distros, such as Fedora.
<RAOF> Are we both talking about `/etc/xdg/autostart/autojack.desktop`?
<RAOF> Because that's a configuration file you're deleting in postinst.
<Eickmeyer> RAOF: Oh, no. That has to be deleted because we don't want it running in xdg/autostart, but rather as a user systemd service.
<tumbleweed> ah, that dbus issue is part of Ubuntu's dbus delta
<RAOF> (Deleting `/lib/systemd/system/studio-system.service` in the postinst *also* seems suspicious, but is at least not in an usually-preserved path)
<vorlon> Eickmeyer: so why is that file present such that it needs to be deleted in postinst?
<RAOF> Eickmeyer: Why might that file exist in `xdg/autostart`?
<Eickmeyer> Previous versions of Ubuntu Studio had it.
<Eickmeyer> er... ubuntustudio-controls.
<Eickmeyer> And it wasn't autodeleting during upgrade.
-queuebot:#ubuntu-release- New: accepted php-horde-mail-autoconfig [amd64] (groovy-proposed) [1.0.3-6]
-queuebot:#ubuntu-release- New: accepted php-horde-pack [amd64] (groovy-proposed) [1.0.7-5]
-queuebot:#ubuntu-release- New: accepted php-horde-timezone [amd64] (groovy-proposed) [1.1.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-vfs [amd64] (groovy-proposed) [2.4.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-mime-viewer [amd64] (groovy-proposed) [2.2.2+debian0-1]
-queuebot:#ubuntu-release- New: accepted php-horde-tree [amd64] (groovy-proposed) [2.0.5-5]
<RAOF> Eickmeyer: https://manpages.debian.org/wheezy/dpkg/dpkg-maintscript-helper.1.en.html
-queuebot:#ubuntu-release- New: accepted php-horde-smtp [amd64] (groovy-proposed) [1.9.5-5]
-queuebot:#ubuntu-release- New: accepted php-horde-xml-element [amd64] (groovy-proposed) [2.0.4-7]
<vorlon> right
<vorlon> should be using dh_maintscript for this, not a hard-coded delet
<vorlon> e
-queuebot:#ubuntu-release- New: accepted php-horde-editor [amd64] (groovy-proposed) [2.0.5+debian0-4]
-queuebot:#ubuntu-release- New: accepted php-horde-itip [amd64] (groovy-proposed) [2.1.2-6]
-queuebot:#ubuntu-release- New: accepted php-horde-queue [amd64] (groovy-proposed) [1.1.5-5]
-queuebot:#ubuntu-release- New: accepted php-horde-routes [amd64] (groovy-proposed) [2.0.5-7]
-queuebot:#ubuntu-release- New: accepted php-horde-socket-client [amd64] (groovy-proposed) [2.1.2-3]
-queuebot:#ubuntu-release- New: accepted php-horde-text-diff [amd64] (groovy-proposed) [2.2.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-http [amd64] (groovy-proposed) [2.1.7-5]
-queuebot:#ubuntu-release- New: accepted php-horde-rdo [amd64] (groovy-proposed) [2.1.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-spellchecker [amd64] (groovy-proposed) [2.1.3-7]
-queuebot:#ubuntu-release- New: accepted php-horde-listheaders [amd64] (groovy-proposed) [1.2.5-5]
-queuebot:#ubuntu-release- New: accepted php-horde-rpc [amd64] (groovy-proposed) [2.1.8-5]
<RAOF> Likewise, why would `/lib/systemd/system/studio-system.service` exist?
-queuebot:#ubuntu-release- New: accepted php-horde-argv [amd64] (groovy-proposed) [2.1.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-date-parser [amd64] (groovy-proposed) [2.0.6-5]
-queuebot:#ubuntu-release- New: accepted volk [amd64] (groovy-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New: accepted volk [armhf] (groovy-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New: accepted volk [riscv64] (groovy-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New: accepted php-horde-crypt [amd64] (groovy-proposed) [2.7.12-3]
-queuebot:#ubuntu-release- New: accepted volk [arm64] (groovy-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New: accepted volk [s390x] (groovy-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New: accepted php-horde-image [amd64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted volk [ppc64el] (groovy-proposed) [2.3.0-2]
<Eickmeyer> RAOF: In other distributions, ondemand.service does not exist. That service file is required every boot for studio-controls to function.
<Eickmeyer> ondemand.service is an Ubuntu-only thing.
<RAOF> But why are you manually `rm`ing `studio-system.service` in the postinst?
<Eickmeyer> To prevent people from enabling it. I could not convince the developer that it can exist without doing anything.
<Eickmeyer> Mostly to make him happy.
<xnox> RAOF:  Eickmeyer: what package are you discussing? i'm curious to review it.
<Eickmeyer> xnox: studio-controls, it's identical to ubuntustudio-controls, but we're de-ubuntuifying it and making it distro-agnostic.
<Eickmeyer> So, it's literally a file rename of what already exists.
<xnox> ok
<RAOF> And hence has the good fortune to be subject to AA review ð
<xnox> Eickmeyer:  why are you de-ubuntuifying it?
<xnox> Eickmeyer:  are you..... leaving us?
<Eickmeyer> xnox: I'
<Eickmeyer> oops
<Eickmeyer> xnox: I'm not leaving, but other distros want the tool. I also lead Fedora Jam.
<Eickmeyer> And my developer, Len Ovens (OvenWerks) doesn't want to have to develop in two places, and I don't blame him.
<xnox> i see. cool.
<RAOF> Yeah, it's perfectly reasonable to change it from a native to a real upstream package.
<RAOF> But I still don't see why the Ubuntu postinst has â#Remove systemd service file for non-Ubuntu systemsâ :)
<Eickmeyer> RAOF: Because the functionality already exists in lib/systemd/ondemand.service.d
<Eickmeyer> There's a studio.conf file there that does the same thing.
<Eickmeyer> We wouldn't want that function to double-up, causing two processes to start.
<RAOF> Oh! You mean to say that the package *installs* `/lib/systemd/system/studio-system.service` and then you delete it in the postinst?
<Eickmeyer> RAOF: Correct.
<RAOF> Um, no.
<RAOF> Just don't install it in the package!
<Eickmeyer> I tried that, and debhelper threw an error, iirc.
<Eickmeyer> But, I suppose I might be able to manipulate studio-controls.install.
<RAOF> `dh_missing` may have warned about upstream files existing but not being installed?
<Eickmeyer> Yes, I think I remember that.
<RAOF> If so, `debian/not-installed` is the file you want to list them in.
<xnox> Eickmeyer:  we have many packages that install only a subset of things.
<xnox> based on distro
<xnox> e.g. cloud-init
<xnox> (a very versatile per-distro thing)
<Eickmeyer> This also may have been when the package was native.
<RAOF> There seems to be even less for a native package to install a file, only to delete it in its own postinst :)
<RAOF> s/less/less reason/
 * Eickmeyer feels as though he's about to get hit upside the head with a Nack
<Eickmeyer> RAOF: I've made the changes, including the maintscript, changed debian/studio-controls.install to not install studio-system.service, and added not-installed to list that file.
<RAOF> Sounds good. I'll reject what's there and the new upload a review?
<Eickmeyer> Yeah, sounds good.
<Eickmeyer> teward: ^
<Eickmeyer> RAOF: https://launchpad.net/studio-controls is where it's located, FYI.
-queuebot:#ubuntu-release- New: rejected studio-controls [source] (groovy-proposed) [1.99.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: keystone (focal-proposed/main) [2:17.0.0~b3~git2020041013.7bb6314e4-0ubuntu1 => 2:17.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (focal-proposed/main) [1:14.0.0~b3~git2020041012.2ef9f4bf3-0ubuntu1 => 1:14.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: designate (focal-proposed/main) [1:10.0.0~b3~git2020041012.9ed2623a-0ubuntu1 => 1:10.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu2 => 2:16.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New source: studio-controls (groovy-proposed/primary) [1.99.1-0ubuntu1]
<teward> RAOF: studio-controls now in New should meet with better approval
<RAOF> Ta. I'll get onto that next.
-queuebot:#ubuntu-release- New binary: vlfeat [s390x] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vlfeat [ppc64el] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vlfeat [arm64] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vlfeat [amd64] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: vlfeat [armhf] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted studio-controls [source] (groovy-proposed) [1.99.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: studio-controls [amd64] (groovy-proposed/none) [1.99.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.9 => 1:7.2p2-4ubuntu2.10] (core)
-queuebot:#ubuntu-release- New binary: vlfeat [riscv64] (groovy-proposed/universe) [0.9.21+dfsg0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted studio-controls [amd64] (groovy-proposed) [1.99.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [arm64] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [ppc64el] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [s390x] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [amd64] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [riscv64] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vlfeat [armhf] (groovy-proposed) [0.9.21+dfsg0-6ubuntu1]
<mitya57> Can someone please reject tilda in focal SRU queue? Then I will upload a version with a different changelog entry, addressing bdmurray's comment.
<sil2100> RikMills: hey! You around?
<sil2100> RikMills: I'm looking at the plasma SRUs right now, and just wanted to make sure this is not an error - for two packages already I saw that debian/control has been modified and some dependencies being changed from >= 4:5.18.4.1~ to >= 4:5.18.4~ (for example the libkf5sysguard-dev dependency in plasma-vault)
<sil2100> RikMills: it's weird that the dependency is now smaller, is this intentional, or a typo for something that was supposed to be 4:5.18.5~ ?
<sil2100> Since this is .5 basically
<sil2100> mitya57: done
-queuebot:#ubuntu-release- Unapproved: rejected tilda [source] (focal-proposed) [1.5.2-0ubuntu1]
<RikMills> sil2100: sorta intentional or sorta not. let me explain. the packaging was taken from 5.18.5 in groovy where the interneral stack build deps were bumped from 5.18.4.1 to 5.18.5, where I then lowered some in debian/control to allow things to build sice we are not doing the whole stack for the SRU. in this case I forgot that Plasma people made a snafu so had to release 5.18.4.1 so just pout 5.18.4. In the end it doesn't matter at all as
<RikMills> the build deps in the archive are fine, but that is why
<mitya57> sil2100: thanks!
 * RikMills glares at mistypes
<sil2100> RikMills: ok, so what's important is that those that were downgraded to .4 from .4.1 don't really require .5 - thanks!
<RikMills> sil2100: yep. exactly.
<sil2100> Ok, was also worried about the new build requirement of KF5 CoreAddons in plasma-browser-integration without a new build-dep, but then I see almost all libkf5*-dev packages actually pull it in ;p
<RikMills> sil2100: yes, much of kf5 frameworks is like that. I should probably add it explicitly though. I'll do that in groovy packaging
-queuebot:#ubuntu-release- Unapproved: accepted drkonqi [sync] (focal-proposed) [5.18.5-0ubuntu0.1]
<sil2100> RikMills: thanks o/
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-browser-integration [sync] (focal-proposed) [5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [sync] (focal-proposed) [5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [sync] (focal-proposed) [5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [sync] (focal-proposed) [4:5.18.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-kde [sync] (focal-proposed) [5.18.5-0ubuntu0.1]
<RikMills> \o/
-queuebot:#ubuntu-release- Unapproved: rejected live-build [source] (focal-proposed) [3.0~a57-1ubuntu38.1]
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.24 => 1:2.11+dfsg-1ubuntu7.25] (ubuntu-server, virt)
<cpaelzer> the qemu that showed up in bionic-unapproved fixes an issue in an ongoing SRU verification
<cpaelzer> the actual change vs what is already reviewed and in -proposed comes down to just https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/commit/?id=47a2da2f474b81bb2ba033b9facf21c16194e3eb
<cpaelzer> sil2100: you did the initial accept - since this is also blockign some coming CVE fixes I wante to ask if you (or someone else of the SRU Team) could check and accept that qemu
<cpaelzer> it also builds quite some time, so accepting it soon would allow to re-verify it today
-queuebot:#ubuntu-release- Unapproved: rejected sbuild-launchpad-chroot [source] (focal-proposed) [0.16ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected sbuild-launchpad-chroot [source] (eoan-proposed) [0.15ubuntu0.19.04.1]
<sil2100> cpaelzer: ok, looking good o/
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.25]
<cpaelzer> thank you
<rbalint> ddstreet, true qemu is not found on arm64, i've updated LP: #1684588 with ppc64el finding it now
<ubot5> Launchpad bug 1684588 in systemd (Ubuntu) "ADT upstream tests should run with QEMU on more architectures" [Medium,Confirmed] https://launchpad.net/bugs/1684588
<rbalint> Laney, systemd/ppc64el still times out :-(, is there anything else to make the change to adding it to long_tests take effect?
-queuebot:#ubuntu-release- New binary: tinyxml2 [amd64] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tinyxml2 [s390x] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tinyxml2 [ppc64el] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tinyxml2 [i386] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
<rbalint> Laney, ahh, it  is bos02, not bos01
-queuebot:#ubuntu-release- New binary: tinyxml2 [arm64] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tinyxml2 [armhf] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: tinyxml2 [riscv64] (groovy-proposed/universe) [8.0.0+dfsg-2] (i386-whitelist, kubuntu)
<Laney> ah
-queuebot:#ubuntu-release- Unapproved: tilda (focal-proposed/universe) [1.5.0-1.1 => 1.5.2-0ubuntu1] (ubuntu-mate)
<rbalint> Laney, fixing it ...
<Laney> yeah forgot we had separate configs there
<Laney> annoying system
<rbalint> Laney, agreed :-)
<Laney> it's going to be gone with the New DeploymentÂ®â¢â¸
<Laney> that looks more like https://git.launchpad.net/autopkgtest-cloud/tree/mojo/service-bundle?h=wip/mojo-juju-2
<rbalint> Laney, could you please update the config? https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383943
<rbalint> ddstreet, Laney ^ sneaking systemd-upstream in
<ddstreet> sweet!
<Laney> rbalint: it needs to be in both configs
<rbalint> Laney, ah, even more confusing, fixing it
<Laney> we have two cloud regions that can run ppc64el tests
<Laney> not sure if systemd-upstream will work there
<Laney> rbalint: also  long_test not big?
<rbalint> Laney, i'd like to try in on big, to see the gain, it runs qemu
<Laney> what gain?
<Laney> big reduces the capacity available for all other tests
<Laney> and we frequently get many systemd tests running at once
<Laney> (yeah systemd-upstream should work there I think)
<rbalint> Laney, i thought ppc64el was doing relatively well regarding capacity
<rbalint> Laney, also the shorter run time may make up for some of the kept resources
<rbalint> Laney, we can revert to long if big makes too much trouble
<rbalint> Laney, i think it would make sense to give it a try
<rbalint> Laney,'ve updated the mr
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (focal-proposed) [3.8.2-0ubuntu1.1]
<Laney> rbalint: sorry went to lunch. m1.large uses 5 1/3 Ã as much RAM and 4 Ã as many vCPUs as the autopkgtest policy and so I don't really want to do this 'on spec' without more consideration
<Laney> I'll give you long_tests for now
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (bionic-proposed) [3.6.10-1ubuntu0.2]
<rbalint> Laney, please check the comments on ddstreet's previous mr, it seems vorlon finally approved the big change
<Laney> which one is that?
<rbalint> Laney, https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/369620/comments/974133
<rbalint> Laney, also linked from current mr
<Laney> thanks, I'll refer to my previous arguments then
<Laney> basically that if we want to do this, we need to work on improving our own support
<rbalint> Laney, is there a bug/ticket to track that?\
<rbalint> Laney, also trying and reverting does not seem too much hassle if it turns out to be too heavy on the infra
<Laney> rbalint: There's https://bugs.launchpad.net/auto-package-testing/+bug/1654761 for at least part of it
<ubot5> Ubuntu bug 1654761 in Auto Package Testing "Make sure duplicate tests cannot be queued" [Undecided,In progress]
<Laney> I think we're missing a bug for 'limit the number of concurrent big tests'
<rbalint> Laney, ok, thanks for merging the long bump, i'm opening a new mr for 'big' to let the discussion be documented around the change
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (xenial-proposed) [3.5.7-1ubuntu0.16.04.3]
<Laney> FYI I killed the current systemd/groovy/ppc64el run
<Laney> it sneaked in before I had deployed the change
<Laney> should restart in a few minutes
<rbalint> Laney, ok, thanks
<rbalint> Laney, i've filed the new mr and invited you, too, to the review/discussion
-queuebot:#ubuntu-release- Unapproved: barbican (focal-proposed/main) [1:10.0.0~b2~git2020020508.7b14d983-0ubuntu3 => 1:10.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (focal-proposed/main) [1:14.0.0~b3~git2020041012.75b9d4e9-0ubuntu1 => 1:14.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (focal-proposed/universe) [1:10.0.1~git2020041316.14b425e-0ubuntu1 => 1:10.1.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: magnum (focal-proposed/universe) [10.0.0~b3~git2020041013.01629398-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: manila (focal-proposed/universe) [1:10.0.0~b3~git2020041013.ea90fd17-0ubuntu1 => 1:10.0.0-0ubuntu0.20.04.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: masakari-monitors (focal-proposed/main) [9.0.0~b3~git2020041013.e225e6d-0ubuntu1 => 9.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: panko (focal-proposed/universe) [7.0.0-0ubuntu1 => 8.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zaqar (focal-proposed/universe) [10.0.0~b3~git2020041014.22c457a5-0ubuntu1 => 10.0.0-0ubuntu0.20.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: masakari (focal-proposed/main) [9.0.0~b3~git2020041013.94ec959-0ubuntu1 => 9.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-os-ken (focal-proposed/main) [1.0.0-0ubuntu1 => 1.0.0-0ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.service (focal-proposed/main) [2.1.1-0ubuntu1 => 2.1.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: networking-bagpipe (focal-proposed/universe) [12.0.0~b3~git2020041013.c15d5e0-0ubuntu1 => 12.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-bgpvpn (focal-proposed/universe) [12.0.0~b3~git2020032545.9dcd5ed-0ubuntu1 => 12.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-hyperv (focal-proposed/universe) [1:7.3.2~git2020021315.1b1ee11-0ubuntu1 => 1:8.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-odl (focal-proposed/universe) [1:16.0.0~b3~git2020032509.3de47a829-0ubuntu1 => 1:16.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (focal-proposed/main) [1:16.0.0~b3~git2020032402.5e6c04885-0ubuntu1 => 1:16.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-dynamic-routing (focal-proposed/universe) [2:16.0.0~b3~git2020041013.045811b-0ubuntu1 => 2:16.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (focal-proposed/main) [2:16.0.0~b3~git2020041013.358d35202-0ubuntu1 => 2:16.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-18.04 (bionic-proposed/main) [2:1.20.5+git20191008-0ubuntu1~18.04.1 => 2:1.20.8-2ubuntu2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-sfc (focal-proposed/universe) [10.0.0~b3~git2020032510.8417568-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: placement (focal-proposed/main) [3.0.0~b3~git2020041014.0f90d197-0ubuntu1 => 3.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: octavia (focal-proposed/universe) [6.0.0~b3~git2020041014.771a5d87-0ubuntu1 => 6.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.2.8-0ubuntu0~18.04.3 => 20.0.4-2ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: swift (focal-proposed/main) [2.24.1~git2020041316.a495f1e32-0ubuntu1 => 2.25.0-0ubuntu0.20.04.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.40 => 237-3ubuntu10.41] (core)
<ddstreet> tjaalton when you get in tomorrow, for your ~ubuntu-sru shift, would be great if you could accept this systemd upload ^ has an urgent patch.  thanks!
<ddstreet> or bdmurray or vorlon if you happen to have sru review time today ^
<bdmurray> ddstreet: I reviewed some of this already right?
<ddstreet> bdmurray some of it was in the upload for focal, yes (and there is also an upload in eoan with some)
<bdmurray> okay then it might make sense for me to do it
-queuebot:#ubuntu-release- Unapproved: networking-l2gw (focal-proposed/universe) [1:16.0.0~b3~git2020032509.d57ae1a-0ubuntu1 => 1:16.0.0~git2020051415.30f4209-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (eoan-proposed) [242-7ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.41]
-queuebot:#ubuntu-release- Packageset: Added studio-controls to ubuntustudio in groovy
<Eickmeyer> ^ Thanks!
<ddstreet> Eickmeyer i replied to your dmb email, essentially all the DMB bits are done now, we just need the TB to change the packageset uploader over to the new ubuntu-studio-uploaders team
<ddstreet> if it gets urgent, you might be able to ping one of the TB members, otherwise I assume they'll get to it at their next meeting
<fo0bar> flipping through channels; IRTA "i replied to your dumb email"
<Eickmeyer> ddstreet: Thanks!
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (focal-proposed/main) [3.36.2-0ubuntu1 => 3.36.2-0ubuntu2] (ubuntu-desktop)
#ubuntu-release 2020-05-15
-queuebot:#ubuntu-release- Unapproved: php7.2 (bionic-proposed/main) [7.2.24-0ubuntu0.18.04.4 => 7.2.24-0ubuntu0.18.04.5] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: php7.3 (eoan-proposed/main) [7.3.11-0ubuntu0.19.10.4 => 7.3.11-0ubuntu0.19.10.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php7.4 (focal-proposed/main) [7.4.3-4ubuntu1.1 => 7.4.3-4ubuntu2.1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: tempest-horizon [amd64] (groovy-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted liburcu [source] (bionic-proposed) [0.10.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dahdi-linux (xenial-proposed/universe) [1:2.10.2~dfsg-1ubuntu3 => 1:2.10.2~dfsg-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (focal-proposed) [3.36.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: llvm-toolchain-10 (bionic-proposed/primary) [1:10.0.0-4ubuntu1~18.04.1]
<ahasenack>  ubuntu-archive hi, anyone around to maybe remove an update that is killing machines? https://bugs.launchpad.net/ubuntu/+source/json-c/+bug/1878723
<ubot5> Ubuntu bug 1878723 in json-c (Ubuntu) "Kernel panic when used with upstart after 0.11-4ubuntu2.1 update" [Critical,Confirmed]
 * apw looks
<Laney> raise in #ubuntu-devel already, probably keep the conversation in there
<Laney> raised*
<ackk> sil2100, hi, wrt https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1877973 was the source package also removed, or just the binaries?
<ubot5> Ubuntu bug 1877973 in maas (Ubuntu) "RM request - removal from archive" [Undecided,Fix released]
<sil2100> ackk: hey! Yes, typo on my side, this is done now *properly*
<sil2100> Sorry about that
<ackk> sil2100, thanks!
-queuebot:#ubuntu-release- Unapproved: networking-mlnx (focal-proposed/universe) [1:15.0.0~b2~git2019090509.50bbc9d-0ubuntu1 => 1:15.0.2-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: masakari (focal-proposed/main) [9.0.0~b3~git2020041013.94ec959-0ubuntu1 => 9.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: manila (focal-proposed/universe) [1:10.0.0~b3~git2020041013.ea90fd17-0ubuntu1 => 1:10.0.0-0ubuntu0.20.04.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (focal-proposed/restricted) [340.108-0ubuntu2 => 340.108-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-340 [source] (focal-proposed) [340.108-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: mistral (focal-proposed/universe) [10.0.0~b3~git2020041013.a7da00d7-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: murano-agent (focal-proposed/universe) [1:5.0.0~b3~git2020041013.b908aa8-0ubuntu1 => 1:5.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (focal-proposed/universe) [1:13.0.0~b3~git2020041014.8c3df10a-0ubuntu1 => 1:13.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: murano (focal-proposed/universe) [1:9.0.0~b3~git2020041013.564f9cf3-0ubuntu1 => 1:9.0.0-0ubuntu0.20.04.1] (openstack)
-queuebot:#ubuntu-release- Unapproved: watcher (focal-proposed/universe) [1:4.0.0~b3~git2020041014.f3c427bd-0ubuntu1 => 1:4.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: senlin (focal-proposed/universe) [9.0.0~b3~git2020041014.4627fbfb-0ubuntu1 => 9.0.0-0ubuntu0.20.04.1] (no packageset)
<cking> hi there, is it possible for the stress-ng package for bug 1853832 to be uploaded as part of the SRU process?
<ubot5> bug 1853832 in stress-ng (Ubuntu Bionic) "stress-ng --timer-slack option should be a zero arg option, it currently skips over the next arg" [Medium,Fix committed] https://launchpad.net/bugs/1853832
<cking> ^^anyone care to facilitate with getting the above SRU chugging along into the archive?
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New binary: libdrm [s390x] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libdrm [amd64] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libdrm [ppc64el] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libdrm [i386] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libdrm [arm64] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libdrm [armhf] (bionic-proposed/main) [2.4.101-2~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: restinio [s390x] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: restinio [ppc64el] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: restinio [arm64] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.0.0~b3~git2020041012.eb915e2db-0ubuntu1 => 2:16.0.0-0ubuntu0.20.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: restinio [amd64] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: restinio [armhf] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sahara (focal-proposed/universe) [1:12.0.0~b3~git2020041014.0825bdde-0ubuntu1 => 1:12.0.0-0ubuntu0.20.04.1] (openstack)
<vorlon> Laney, Wimpress: seems the bionic daily desktop images have grown again past the previously set size limit
-queuebot:#ubuntu-release- New binary: restinio [riscv64] (groovy-proposed/universe) [0.6.6-1] (no packageset)
<doko> hmm, why isn't gcc-10 not migrating?
<doko> ahh, debian/templates/control.in
-queuebot:#ubuntu-release- Unapproved: accepted python-ironic-lib [source] (focal-proposed) [4.2.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (focal-proposed) [1:15.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (focal-proposed) [2:20.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.3.2-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted heat-dashboard [source] (focal-proposed) [3.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (focal-proposed) [1:3.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted watcher-dashboard [source] (focal-proposed) [3.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (focal-proposed) [14.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (focal-proposed) [1:3.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted octavia-dashboard [source] (focal-proposed) [5.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: allelecount [amd64] (groovy-proposed/universe) [4.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: parallel-fastq-dump [amd64] (groovy-proposed/universe) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: busco [amd64] (groovy-proposed/universe) [4.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: filtlong [amd64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (focal-proposed) [12.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted allelecount [amd64] (groovy-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New: accepted filtlong [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted restinio [amd64] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted restinio [armhf] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted restinio [riscv64] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted tempest-horizon [amd64] (groovy-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted busco [amd64] (groovy-proposed) [4.0.6-1]
-queuebot:#ubuntu-release- New: accepted restinio [arm64] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted restinio [s390x] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted parallel-fastq-dump [amd64] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted restinio [ppc64el] (groovy-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [amd64] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [armhf] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [ppc64el] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [s390x] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [arm64] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [riscv64] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [i386] (groovy-proposed) [8.0.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (focal-proposed) [1:9.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (focal-proposed) [2:17.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (focal-proposed) [1:14.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (focal-proposed) [1:10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (focal-proposed) [1:10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (focal-proposed) [1:14.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [source] (focal-proposed) [1:10.1.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected manila [source] (focal-proposed) [1:10.0.0-0ubuntu0.20.04.1]
#ubuntu-release 2020-05-16
-queuebot:#ubuntu-release- New binary: cloop [amd64] (groovy-proposed/universe) [3.14.1.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (focal-proposed) [9.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: rust-gethostname [amd64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gethostname [ppc64el] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gethostname [arm64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gethostname [s390x] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gethostname [armhf] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gethostname [riscv64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cloop [amd64] (groovy-proposed) [3.14.1.3]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [arm64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [ppc64el] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [s390x] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [riscv64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gethostname [armhf] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: wrk [amd64] (groovy-proposed/none) [4.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: wrk [arm64] (groovy-proposed/universe) [4.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: wrk [armhf] (groovy-proposed/universe) [4.0.2-3] (no packageset)
<LocutusOfBorg> vorlon, python-pbcommand is arch:all, and can't be installed on s390x autopkgtest for python-pbcommand/1.1.1+git20200313.2a40099-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Ignored failure, ppc64el: Pass, s390x: Regression â»
<LocutusOfBorg> can we please get a forget-foo?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/p/python-pbcommand/groovy/s390x
<LocutusOfBorg> since version 1.1.1-1 in eoan
-queuebot:#ubuntu-release- New binary: wrk [amd64] (groovy-proposed/universe) [4.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wrk [arm64] (groovy-proposed/universe) [4.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wrk [armhf] (groovy-proposed/universe) [4.1.0-1] (no packageset)
<vorlon> LocutusOfBorg: yep, done
-queuebot:#ubuntu-release- New: accepted wrk [amd64] (groovy-proposed) [4.0.2-3]
-queuebot:#ubuntu-release- New: accepted wrk [armhf] (groovy-proposed) [4.0.2-3]
-queuebot:#ubuntu-release- New: accepted wrk [arm64] (groovy-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New: accepted wrk [arm64] (groovy-proposed) [4.0.2-3]
-queuebot:#ubuntu-release- New: accepted wrk [armhf] (groovy-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New: accepted wrk [amd64] (groovy-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New binary: yara [amd64] (groovy-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yara [ppc64el] (groovy-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yara [s390x] (groovy-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-cat-ita [amd64] (groovy-proposed/none) [0.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yara [arm64] (groovy-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yara [armhf] (groovy-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yara [riscv64] (groovy-proposed/universe) [4.0.1-1] (no packageset)
#ubuntu-release 2020-05-17
-queuebot:#ubuntu-release- New binary: libclamunrar [amd64] (groovy-proposed/multiverse) [0.102.3-1] (no packageset)
<locutus_> vorlon, hello, looks like this one should be hinted too? http://autopkgtest.ubuntu.com/packages/n/node-puka/groovy/i386
<vorlon> locutus_: it already is?
-queuebot:#ubuntu-release- New binary: purify [s390x] (groovy-proposed/universe) [2.0.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: purify [amd64] (groovy-proposed/universe) [2.0.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: purify [ppc64el] (groovy-proposed/universe) [2.0.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: purify [arm64] (groovy-proposed/universe) [2.0.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: purify [armhf] (groovy-proposed/universe) [2.0.0-5] (no packageset)
<vorlon> locutus__: I'm rolling back opencv in -proposed, there was already a version there for the protobuf transition and now it's entangling hdf5 which is apparently not ready to go
